Diagrams in Modeling Spaces

"The Three Modeling Spaces in Software Engineering

Different areas of a software system need to be modeled. These areas are called modeling spaces. Each modeling space has roles that are responsible for carrying out modeling in that space. Roles within respective modeling spaces create as well as utilize the models.

This segregation of modeling spaces and corresponding responsibilities is crucial for the success of a software project. The analysis and design work in developing a software solution benefits from the segregation of responsibilities and use of the UML. Without such a delineation of modeling spaces, the use of UML can degenerate into incorrect or excessive modeling.

The modeling spaces as shown in Figure 3.3 are as follows:

1.The problem space

2.The solution space

3.The architectural space

Figure 3.3Software engineering uses three main modeling spaces and corresponding roles: model of problem space (in identifying the requirements and analyzing them), model of solution space (in creating the solution design), and model of architectural space (in applying constraints).

Each modeling space is discussed in greater detail next.

Modeling of the Problem Space

The modeling in the problem space is meant to shed light on “what” the business problem of the user is. The problem space thus models the business requirement whose solution is yet to be developed. Main activities that take place in the problem space include investigating the business problem in detail, understanding the requirements, documenting them, analyzing them, optionally creating a conceptual prototype, and understanding the flow of the business process.

UML diagrams in the problem space explain the problem without going into the specifics of the solution. These UML diagrams are primarily a use case diagram and activity diagrams, followed by high-level use of class and sequence diagrams, and optionally state machine diagrams.

Key roles in creating the MOPS are the business analyst and the user. Apart from prototyping in the problem space, where some code may be written, there is no programming effort required in developing the MOPS.

Modeling of Solution Space

Figure 3.3 shows an MOSS that contains the design for the system. The solution space describes “how” the solution will be implemented to handle the problem described in the problem space. The creation of a solution model requires knowledge of the capabilities of the programming languages, corresponding databases, Web services, Web application solutions, and similar technical issues.

The MOSS contains solution-level designs expressed by technical or lower-level class diagrams. These design-level class diagrams contain the lowermost details, including attributes, types of attributes, their initial values, operations, and their signatures. With a parameter list and return values, sequence diagrams, together with their messages and protocols, are also used in MOSS. State machine diagrams and object diagrams can be used sparingly here. Key roles in the solution space are the system designer and the programmer, as shown in Figure 3.3.

Modeling of Architectural Space

The architectural space (also occasionally called the background space) deals with two major aspects of software development not covered by either the problem space or solution space: architecture and management. Figure 3.3 shows the architectural space in the third dimension—orthogonal to the problem and solution spaces.

Architectural models deal with a large amount of technical background work that must consider key issues of the architecture of the solution, existing architecture, technical environment of the organization, and the operational requirements of the system (e.g., stress, volume, and bandwidth needs of the system).

Architectural issues include aspects of reusability of programs, designs, services, and Cloud hosting. These activities require knowledge of how the organizational environment works and industrial knowledge of the availability of reusable architectures and designs. The MOAS presents organizational-level constraints by the architects and designers on both the problem and the solution models.

The architectural space uses the UML in modeling the deployment environment as well as in reusing both the architecture and the design. Therefore, deployment and component diagrams play an important role here. The component diagrams represent the executable chunks of code or libraries (e.g. .exe or.dll and service-oriented components), which are finally incorporated into the software solution. The UML domain also provides material, such as analysis patterns by Fowler (1997),5 design patterns by the Gang of Four (Gamma et al., 1995),6 cognitive patterns (Gardner et al., 1998),7 and anti patterns (Brown et al., 19988), that supports architectural work in MOAS.

Management in the background architectural space deals with the planning of the entire project and does not necessarily form part of the problem or the solution space. The project manager undertakes planning and resourcing the project hardware, software, and people, budgeting and performing cost-benefit analysis, tracking the project as it progresses as per the iteration plans, and providing the checkpoints that yield quality results for the roles in the problem and solution spaces. Thus, the quality manager is equally involved in the planning and execution of the project from a quality perspective.

Mapping UML to Modeling Spaces

With this understanding of the three modeling spaces, it is now easier to understand how each of the 14 UML diagrams can play a role in these different modeling spaces with varying degrees of importance and relevance. Some UML diagrams are more important and relevant in understanding problems and documenting and prioritizing requirements; other UML diagrams add more value in modeling the design in the solution space; whereas some UML diagrams can be used in modeling and applying architectural constraints as well as testing systems.

Table 3.2 summarizes the relative importance of each diagram in the three modeling spaces of problem, solution, and architecture. Additionally, this table also maps the UML diagrams to the major modeling roles within projects. Each diagram has a particular nuance that makes it relevant to a particular role within a software project. The UML is treated here as a toolbox of modeling notations and diagrams. Diagrams relevant to a role in a corresponding modeling space are then chosen from this toolbox.

While project team members can work in any of these modeling spaces using any of the UML diagrams, good-quality models result from understanding the importance of the diagrams with respect to the roles played by the modelers and in each of the modeling spaces. Selecting the appropriate diagrams from this toolbox of UML techniques is a crucial step in good-quality SE.

A subset of the UML diagrams can be created in the problem, solution, and architectural spaces. UML diagrams that have received three or more “*” in each of the columns in Table 3.2 ideally form part of that particular modeling space. For example, the following diagrams are relevant in building the MOPS.

■Use case diagrams—used as a primary means to interact with users and in understanding their business problem. Hence, use case diagrams are ideal in the problem space.

■Activity diagrams—as sophisticated flowcharts, they can be used in the problem space to model flows and dependencies. Users and business analysts are particularly keen to use them to describe business workflows.

■Package diagrams—as a “grouping mechanism” for a subsystem, package diagrams are invaluable in the problem space, especially for project managers and project sponsors in organizing, evaluating, and scheduling projects.

■Class diagrams—represent the key business entities and their relationships and, as such, help create the “business domain model” in the problem space.

■Sequence diagrams—model the dynamic aspect of the requirements by showing interactions among business objects or interactions described directly by business users in the problem space.

■Interaction overview diagrams—provide an overview of dependencies between interaction diagrams, thereby enabling users and analysts to show relationships between sequences and use cases in the problem space.

■State machine diagrams—enable modeling of states of important business objects, providing a visual means of communicating the attribute values and their meanings in the problem space.

Similarly, Table 3.2 shows UML diagrams with three or more “*” to indicate their corresponding importance in MOSS and MOAS. These diagrams are as follows:

■Class diagrams—represent detailed designs and programming constructs; these diagrams can also model relational database tables.

■Sequence diagrams—in the solution space represent detailed technical models of interactions within a system; the objects in a sequence diagram in the solution space represent instances of entity, interface, controller, and database tables.

■Object diagrams—represent the multiplicities of class relationships in the memory.

■State machine diagrams—provide a more detailed, technical model of changes to the states of an object in the solution space; these diagrams also model the guard conditions and nesting to help design precise solutions.

■Composite structure diagrams—represent the runtime architecture of a group of objects and components, including their interfaces and realizations.

■Component diagrams—represent the structural as well as executable components; they provide excellent mechanisms to model the architecture of the solution.

■Deployment diagrams—represent the architectural organization of the hardware (nodes and links) of the solution.

■Timing diagrams—undertake detailed comparison of multiple states of more than one object in the solution space.

■Profile diagrams—create profiles that can be commonly applied across a system to ensure uniformity of constraints and, thereby, improvement of quality.

The preceding list of diagrams corresponding to the modeling spaces creates a subset of the UML that is relevant to a given modeling effort. Thus, apart from the type and size of project, the UML also needs to be selectively used by individuals within software projects. This selective use of the UML is important for success within SE. The extensive availability of modeling techniques within the UML can occasionally lead to the use of all modeling constructs by all roles—leading to chaos and lost value from modeling. Instead, selectively using the UML provides necessary value for a given role within the modeling space.

Package Diagrams

What Is a Package in UML?

A package in UML represents a logical collection of artifacts and models. Therefore, a package is going to contain classes, components, use cases, and all other related constructs belonging to that particular subsystem.

In the MOAS, a package can map to a component. Yet, in most practical modeling exercises it is better to treat it differently from a component. This is because a package, as discussed here, is not treated as an executable entity. Instead, it is treated as an organizational element representing a subsystem—as against, say, a Java package, which is an implementation entity.

A domain expert is always involved together with the architect and the project manager in creating and naming packages. Packages are named after the subsystems or large area of work they represent, using singular common nouns.

Once packages for the system are identified, they are then prioritized. After prioritization, the activity task list for the project is created. The assignment of priorities to the packages provides a basis for scheduling their development. Modeling and prioritization of packages and the modeling work within those packages are all carried out in iterations. These iterations can occur initially at two levels:

1.Iteration for the entire project.

2.Iteration for packages.

Increments are then superimposed on the iterations, with each business-level package representing an increment."