|
|
The purpose of this book is to provide some basic knowledge of the Unified Modelling Language (UML at short) as well as to give some sort of methodology of how to use UML. UML by itself does not contain a methodology. It only provides the notation and lets the system analysts and designers the way to use it.
The history of Software Analysis and Design steps back to the early 1970s. Then, Structured Analysis and Design was perhaps the first family of software development methods to be widely used. That methodology followed the traditional software life cycle or waterfall process. The traditional software life cycle is linear, with well-defined, sequential phases. Each phase normally starts when its previous phase terminates. This methodology has some serious drawbacks, as that it is very costly to change requirements in later phases, and there is no proof that the system will run properly until late in the life cycle. It applies to the functional programming languages, such as C, Fortran or Cobol.
By the late 1980s there was a move towards the Object-Oriented paradigm. “In general, object-oriented techniques addressed issues of complexity management and were much more suited to the iterative development process” [Rosenberg, 1999]. In the iterative life cycle, a non-linear evolutionary approach to development is used. In the iterative life cycle each phase consists of analysis, design1 and implementation (see fig. 1a) and this cycle is repeated in the following phases, too. This way, changes in the requirements are anticipated throughout all phases. The iterative life cycle exposes problems early in the project schedule and there is proof that major pieces of the system will run properly throughout the life cycle. The result is better quality code. This process applies better to the object-oriented programming languages such as C++, Java and Smalltalk.
Figure 1 Iterative life cycle phases
A problem that emerged early in the object-oriented process was the focus to model the vocabulary of the problem in a way that captured the user needs and provided an accurate blueprint of the system. Some of the most famous methods developed by that time were the Booch method by Grady Booch [Booch, 1991], the Object Modeling Technique (OMT) by Jim Rumbaugh et al. [Rumbaugh et al., 1991], and Ivar Jacobson’s Object Oriented Software Engineering (OOSE) [Jacobson et al., 1992]. Each one of them had its strengths and weaknesses. In the mid 1990s the three amigos, Grady Booch, Jim Rumbaugh and Ivar Jacobson were motivated to produce a unified modeling language that combined each methods’ advantages. In January 1997 the UML 1.0 was offered for stardadisation to the Object Management Group (OMG) and was released as a standard in November 1997. Today, UML is at version 1.3.
The phases that each software project goes into are the following five [Booch, 1991; Detsis, 2000]:
Requirements capture
Analysis
Design
Implementation
Maintenance
The macro development process [Booch, 1991; Detsis, 2000] is iterative, incremented and risk-oriented. It consists of the following phases (see Figure 1b): inception, elaboration, construction, transition and evolution.
Figure 2 The macro development process
During the first phase (inception) the project scope is specified and an initial business case (including success criteria, risk assessment and estimate of required resources) is created.
During the second phase (elaboration), an analysis of the requirements, of the resources and the risks is made and an executable architecture is developed.
The third phase (construction) consists of many iterations, in each of which a subset of the requirements of the project is produced. Each iteration consists of the life cycles described above (i.e. analysis, design, implementation and testing).
In the transition phase, the final release of the product is delivered, the documentation etc.
The final phase (evolution) consists of the updates, new versions, bug fixes that were missed during transition phase etc.
The book consists of twelve chapters. In the first chapter a definition of UML is given, while in chapter 2 a general description of the methodology is provided. Then, in each chapter a specific part of this methodology is described. First, the theoretical concepts and UML notation for this part of the methodology are given. Then, we describe how to use these notions in each step to produce the deliverables for our project. A real example is used to apply the theoretical notions and the methodology.
1 Object-oriented analysis is a method of analysis in which requirements are expressed in terms of the objects found in the problem (what to model).
In object-oriented design the analysis model is transformed into a design model by refining the model, adding detail and capturing design decisions needed to implement the model (how to model).