Chapter 2: Modeling with UML
UML lets us model our problem with the intent on a solution. We can use UML to model
the system under development, which focuses on 3 type of model –
1. Functional Model – represented in UML via use case diagrams.
2. Object Models – represented in UML: via class diagrams describing the structure
of the system in terms of objects, associations and operations.
3. Dynamic Models – represented in UML via sequence diagrams (ID), state charts
and activity diagrams describing the internal behavior of the system.
Developing Functional Models:
Identify software use cases:
First, we want to specify the problem statement by using “shall” statements to indicate all
of the functionalities of the application to be developed. Translate this into an RTM. The
purpose of this activity is to extract from the RTM the “shall” statements and convert them into Use Case
format which will lead to the discovery of potential categories.
A use case is a “statement of functionality required of the software.” It is written in a
specific format and in natural language for better understanding. The format can either be
similar to that of the handout or that in the book (Pp. 45) The diagram used to express a
use case (a use case diagram) is shown on Pp. 44. These diagrams graphically represent
the functionality of the system from the user’s point of view.
The amount of use cases that should be in a project varies. Some believe that 6 per 1m
LOC is ok whereas others think that 5000 per 1m LOC is better. What is known is that
the more use cases used, the better the chance of representing all of the required
functionalities of the software. But at the same time, uses cases should be used in
moderation.
What to use to create use cases?
1. There must be the name of the use case.
2. The participating actor(s) that interact with the use case.
3. Entry conditions – conditions that need to be satisfy before the use case is initiated.
4. Flow of events – the sequence of actions of the use case.
5. Exit conditions – the conditions that are satisfied after the use case is completed.
6. Special requirements – functionality not related to the system. Includes constraints,
hardware, etc.
1
Modeling Concepts:
A system is an organized set of communicating parts designed for a specific purpose.
Often, a system could be broken down into subsystems which can themselves be further
broken down into subsystems. This process goes on until no other subsystem can be
derived. The last of these subsystems is regarded as objects. The objects are now easier to
understand and manipulate.
Owing to the complexity of a system (and subsystem), each component is better handled
by different person. To achieve this distribution, we model the system, thus breaking the
system into subsystem parts and create links between these parts to present the whole.
Different amount of models can be used for a single system. One, to model the whole
system. Another to model one subsystem, and another to model another subsystem, etc.
And another to model a subsystem of a subsystem, etc. Models usually are created to
display the interesting characteristics and to ignore the minor details. So they are used to
help us better understand the complexity of a problem and thus, maybe provide us with a
more manageable solution to that problem.
A model should be built to be simple so that a person could understand it easily. If a
model is getting to be complex, look into it carefully. Maybe the subsystem that is
represented by the model could be broken down into two subsystems.
Notations are used to create the models – notations consist of text and graphics. In UML,
a class diagram is used to give an object view of a model. This class diagram consists of
rectangles, that represents classes, and lines connecting them, that represent the
relationships between the classes. The relationship can be defined in terms of 1 to 1, 1 to
many or many to many. Try to avoid the latter case. Should this happen, break it down
into two diagrams.
Objected-oriented Modeling.
When modeling, the modeler should differentiate between the application domain and the
solution domain. The former pertains to the user’s environment – the physical
environment, the users, their work process, etc. The latter pertains to the various solutions
that could be envisioned that may be applicable to the problem. This includes
technological considerations for the development of the application, etc. The solution
domain includes system design and object design.
OOA is concerned with modeling application domain, which is also part of the system
model, whereas OOD is concerned with modeling the solution domain. Both use classes
and objects for the modeling process. (Jacobson)
The following five UML diagrams (notation) are most often used for modeling:
1. Use case diagrams.
2
2.
3.
4.
5.
Class diagrams.
Sequence diagrams.
Statechart diagrams.
Activity diagrams.
Use case diagrams:
These diagrams can include four types of relationships:
1. Communication.
2. Include.
3. Extend.
4. Generalization.
Communication:
Actors use cases to exchange information. This is depicted by the use of a solid line
between the actor and the use case symbol. (Fig 2.13 Pp. 44)
Include:
If the system is too complex, redundancy may occur when use cases are used to model
the system. To reduce this complexity and thus redundancy, “Includes” are used.
Common characteristics from different use cases are identified and a new use case is
created which would link to these other use cases. The link is depicted by the use of
dashed arrow originating from the different use cases with common characteristics to the
new use case. The word <<include>> is used to label the diagram. (Fig. 2.15 Pp. 47)
Extend:
This involves adding events to an existing use case. We use a different use case to add the
event. This often occur when there may be exceptional behavior to be accounted for,
example if connection is lost, etc.. In this case, the link is depicted with the dashed arrow,
but now originating from the use case that require the extended condition to the use cases
that model these extended conditions. The word <<extend>> is used to label this
diagram. (Fig. 2.17 & 2.18 Pp. 48)
Generalization (Inheritance relationship):
A use case can reduce the complexity by adding details to a general use case. For
example, (the book example – Fig. 2.19 Pp. 49), if a user need to have security clearance
to use a the “FRIEND” system, then the general use case may be “Authenticate”, but the
security code could come in many formats, including a password to be typed in, a smart
card to be inserted, etc. Hence, there could be specialized use case for each of these to
allow the FieldOfficers to log into the system using a password or a smart card. By
3
allowing specialized use cases to go through the general use case, it make the design
more dynamic in that in the future, we may want to have a specialized use case to allow
the user to use finger prints or voice recognition.
Scenarios:
A use case is an abstraction that describes all possible scenarios involving the described
functionality. A scenario therefore is an instance of a use case so scenarios are used as
examples for illustrating use cases focusing on understandability whereas use cases are
used to describe all possible cases – their focus is on completeness.
4