04-06-2013, 01:03 PM
Object Oriented Analysis and Design Using the UML
Object Oriented Analysis.pdf (Size: 1.29 MB / Downloads: 188)
What is the UML?
The Unified Modelling Language, or the UML, is a graphical modelling language that
provides us with a syntax for describing the major elements (called artifacts in the
UML) of software systems. In this course, we will explore the main aspects of the
UML, and describe how the UML can be applied to software development projects.
Through to its core, UML leans towards object oriented software development, so in
this course, we will also explore some of the important principles of object
orientation.
In this short chapter, well look at the origins of the UML, and well discuss the need
for a common language in the software industry. Then we will start to look at how to
exploit the UML on a software project.
The UML as a Notation
The Three Amigos, when developing the UML, made a very clear decision to remove
any process based issues from the language. This was because processes are very
contentious - what works for company A might be a disaster for company B. A
defence company requires much more documentation, quality and testing than (say)
an e-commerce company. So the UML is a generic, broad language enabling the key
aspects of a software development to be captured on "paper".
In other words, the UML is simply a language, a notation, a syntax, whatever you
want to call it. Crucially, it does not tell you how to develop software.
To learn how to use the UML effectively, however, we will follow a simple process
on this course, and try to understand how the UML helps at each stage. To start with,
let’s have a look at some common software processes.
Iterative, Incremental Frameworks
The Iterative, Incremental Framework is a logical extension to the spiral model, but is
more formal and rigorous. We will be following an Iterative, Incremental Framework
through the rest of this course.
The framework is divided into four major phases: Inception; Elaboration;
Construction and Transition. These phases are performed in sequence, but the
phases must not be confused with the stages in the waterfall lifecycle. This section
describes the phases and outlines the activities performed during each one.
Elaboration
The purpose of elaboration is to analyse the problem, develop the project plan further,
and eliminate the riskier areas of the project. By the end of the elaboration phase, we
aim to have a general understanding of the entire project, even if it is not necessarily a
deep understanding (that comes later, and in small, manageable chunks).
Two of the UML models are often invaluable at this stage. The Use Case Model helps
us to understand the customers requirements, and we can also use the Class Diagram
to explore the major concepts our customer understands. More on this shortly.
Construction
At the construction phase, we build the product. This phase of the project is not
carried our in a linear fashion rather, the product is built in the same fashion as the
spiral model, by following a series of iterations. Each iteration is our old friend, the
simple waterfall.3 By keeping each iteration as short as possible, we aim to avoid the
nasty problems associated with waterfalls.
Transition
The final phase is concerned with moving the final product across to the customers.
Typical activities in this phase include:
• Beta-releases for testing by the user community
• Factory testing, or running the product in parallel with the legacy system that the
product is replacing
• Data takeon (ie converting existing databases across to new formats, importing
data, etc)
• Training the new users
• Marketing, Distribution and Sales
The Transition phase should not be confused with the traditional test phase at the end
of the waterfall model. At the start of Transition, a full, tested and running product
should be available for the users. As listed above, some projects may require a betatest
stage, but the product should be pretty much complete before this phase happens.
How Many Iterations? How Long Should They Be?
A single iteration should typically last between 2 weeks and 2 months. Any more than
two months leads to an increase in complexity and the inevitable big bang
integration stage, where many software components have to be integrated for the first
time.
A bigger and more complex project should not automatically imply the need for
longer iterations this will increase the level of complexity the developers need to
handle at any one time. Rather, a bigger project should require more iterations.
Some factors that should influence the iteration length include: (see Larman [2],
pp447-448).
Time Boxing
A radical approach to managing an iterative, incremental process is Time Boxing. This
is a rigid approach which sets a fixed time period in which a particular iteration must
be completed by.
If an iteration is not complete by the end of the timebox, the iteration ends anyway.
The crucial activity associated with timeboxing is the review at the end of iteration.
The review must explore the reasons for any delays, and must reschedule any
unfinished work into future iterations.
Larman (ref [2]) gives details on how to implement timeboxing. One of his
recommendations is that the developers be responsible for (or at least, have a large say
in) setting which requirements are covered in each iteration, as they are the ones who
will have to meet the deadlines.
Implementing timeboxing is difficult. It requires a culture of extreme discipline
through the entire project. It is extremely tempting to forgo the review and overstep
the timebox if the iteration is 99% complete when the deadline arrives. Once a
project succumbs to temptation and one review is missed, the whole concept begins to
fall apart. Many reviews are missed, future iterations planning becomes sloppy and
chaos begins to set in.