1.2 The UML and Process
Even though the UML is process-independent, its authors promote a process that is use-case driven, architecture-centric, iterative, and incremental. By understanding how the UML is related to process and the type of process the UML's authors promote, you can better understand how to best approach learning the UML. However, any type of processeven one without these characteristicsmay use the UML.
Generally, every system development lifecycle process involves the following types of lifecycle activities:
Requirements-gathering activities to capture requirements that define what a system should do
Analysis activities to understand the requirements
Design activities to determine how a system will satisfy its requirements
Implementation activities to build a system
Testing activities to verify that a system satisfies its requirements
Deployment activities to make a system available to its users
There are many types of approach for applying these activities to develop a system. Traditionally, a waterfall approach has been applied. Now, an iterative approach is more common.
1.2.1 Applying a Waterfall Approach
When applying a waterfall approach, lifecycle activities are performed in a single, linear sequence for all the requirements. This often results in the discovery, during testing activities when the different pieces of the system are integrated, of quality-related problems that have remained hidden during the design and implementation activities. Because such problems are discovered late in the development process, it may be too late to resolve them or they may be too costly to resolve. For example, discovering that a specific database management system's performance will be insufficient for the applications that use it after all of the applications have already been developed represents a colossal problem.
Consider a project that involves 10 requirements, perhaps the generation of 10 different types of reports where each report stems from a different requirement. Within a waterfall approach, all the requirements are captured and analyzed, and the whole system is designed, implemented, tested, and deployed in this linear sequence. Within such an approach, the UML may readily be used to communicate the requirements and description of the system. However, because activities are performed in a single linear sequence for all the requirements, the UML models must be fairly complete at each step. This level of completeness is often hard to measure or achieve, because while the UML is more precise than natural languages, it is less precise than programming languages. Therefore, rather than focusing on the system, teams using UML in a waterfall approach often struggle in trying to determine whether their UML models are complete enough.
1.2.2 Applying an Iterative Approach
When applying an iterative approach, any subsets of the lifecycle activities are performed several times to better understand the requirements and gradually develop a more robust system. Each cycle through these activities or a subset of these activities is known as an iteration, and a series of iterations in a step-wise manner eventually results in the final system. This enables you to better understand the requirements and gradually develop a more appropriate system through successive refinement and incrementally gaining more detail as you do more and more iterations. For example, you can investigate a specific database management system's performance and discover that it will be insufficient for the applications that use it before the applications have been completely developed, and thus make the appropriate modifications to the applications or investigate using another database management system before it becomes too late or too costly.
Consider a project that involves generating 10 different types of reports. Within an iterative approach, the following sequence of iterations is possible:
We identify five requirements (named R1 through R5) and analyze three of the five requirements (perhaps R1, R3, and R5).
We capture five new requirements (named R6 through R10), analyze the two requirements that were not analyzed in the previous iteration (R2 and R4), and design, implement, and test the system that satisfies the three requirements that were analyzed in the previous iteration (R1, R3, and R5) and the two requirements analyzed in this iteration (R2 and R4), but we don't deploy the system because we did not allocate enough time in the current iteration for that activity.
We deploy the system that satisfies the five requirements tested in the previous iteration (R1 through R5) and continue working on the other requirements (R6 through R10).
We continue working on the system but must address changes to one requirement that has already been deployed (perhaps R3), changes to other requirements that have not yet been deployed (perhaps R6 and R10), and other technical changes to the system.
This sequence of iterations may appear quite chaotic; however, an iterative approach is only a concept and the UML is only a language; thus, a methodology is required when using the UML on actual projects. When iterations are used by a methodology, they are not chaotic but are organized and quite dynamic within the context of the methodology.
An iterative approach to system development offers the following benefits:
We can better manage complexity by building a system in smaller increments rather than all at once.
We can better manage changing requirements by incorporating changes throughout the process and not trying to capture and address all the requirements at once.
We can provide partial solutions to users throughout the process rather than have them wait until the end of the process, at which time they receive the whole system and perhaps conclude that it is not what they expected.
We can solicit feedback from users concerning the parts of the system already developed, so we may make changes and guide our progress in providing a more robust system that meets their requirements.
An iterative process is incremental because we don't simply rework the same requirements in successive iterations, but address more and more requirements in successive iterations. Likewise, activities may occur in parallel within a single iteration when they focus on different parts of the system and don't conflict. Therefore, an iterative approach involves a series of iterations wherein the system is developed incrementally. Even though such an approach is often known as iterative and incremental, it is actually iterative, incremental, and parallel. Because such an approach gradually develops a system through successive refinement and incrementally increasing detail, we are better able to determine the appropriate level of completeness of our UML models than within a waterfall approach. For example, if we have a question or concern that needs to be addressed, and if we are unable to readily use our UML models to address that concern, perhaps we need to elaborate them further; otherwise, we can proceed without spending more time and effort elaborating our UML models.
With such a dynamic approach in which activities within iterations occur in parallel and a system is constructed incrementally, how do we keep our activities organized and driven to satisfy the requirements? How do we maintain focus on the system and avoid constructing a system that may be difficult to maintain and enhance because it is simply a collection of parts glued together without some overarching scheme? What requirements do we address first, and what pieces of the system do we implement first? Answering these questions is where use cases, architecture, and risk management are critical within an iterative approach.
1.2.2.1 Use cases
A use case is a functional requirement described from the perspective of the users of a system. For example, functional requirements for most systems include security functionality allowing users to log in and out of the system, input data, process data, generate reports, and so forth. Use cases are the subject of Chapter 4.
A use-case driven process is one wherein we are able to use use cases to plan and perform iterations. This allows us to organize our activities and focus on implementing the requirements of a system. That is, we capture and analyze use cases, design and implement a system to satisfy them, test and deploy the system, and plan future iterations. Therefore, use cases are the glue between all the activities within an iteration.
1.2.2.2 Architecture
Architecture encompasses the elements making up a system and the manner in which they work together to provide the functionality of the system. For example, most systems include elements for handling security functionality, inputting and processing data, generating reports, and so forth. The elements and their relationships are known as the system's structure. Modeling a system's structure is known as structural modeling. Structural modeling is the subject of Part II. The elements and how they interact and collaborate is known as the system's behavior. Modeling a system's behavior is known as behavioral modeling. Behavioral modeling is the subject of Part III. The different types of elements that constitute a system's architecture, both structure and behavior, are determined by the object-oriented paradigm. The principles and concepts of the object-oriented paradigm are the subject of Chapter 2.
An architecture-centric process focuses on the architecture of a system across iterations. This allows us to better ensure that the resulting system is not a hodgepodge of elements that may be difficult to integrate, maintain, and enhance. Therefore, architecture is the glue between all the elements that make up the system as the system is incrementally developed across iterations.
1.2.2.3 Risk
A risk is any obstacle or unknown that may hinder our success. For example, when developing a system, risks include such things as insufficient funding, untrained team members with critical responsibilities, and unstable technologies.
To determine what use cases ought to drive an iteration and what parts of the architecture to focus on in the iteration, we first identify project risks. We then address those use cases that confront the highest risks and those elements of the architecture that, when built, resolve the highest risks. Such an approach is often known as risk confronting.
Consider once again the project that involves generating 10 different types of reports. Say that three reports (perhaps R1, R3, and R5) require significant database access, and that four reports (perhaps R3, R6, R8, and R10) require significant user input. Perhaps there are two risks: the risk of not having an intuitive user interface (named X1) and the risk of having an inefficient database management system (named X2). From these descriptions, we know that R1, R3, and R5 are associated with risk X1, and that R3, R6, R8, and R10 are associated with X2. If X1 is more critical to our project, and has a higher possibility of occurring or a higher impact on the project, we would address R1, R3, and R5 or as many of their requirements as possible first, because they confront risk X1. If X2 is more critical to our project, and has a higher possibility of occurring or a higher impact on the project, we would address R3, R6, R8, and R10 or as many of their requirements as possible first because they confront risk X2. However, in either case, we ought to target R3 first, because it addresses both risks.
The UML provides structural and behavioral modeling techniques that may be used in a step-wise process that is driven by requirements, focuses on developing an architecturally sound system that satisfies the requirements, and enables you to confront risks throughout the system-development process.
