Chapter 4: Object Oriented Analysis

❖ OO Analysis Overview
❖Entity, boundary and control objects
❖Use case Modeling
❖ Sequence diagrams
❖Class diagrams
❖Activity diagrams
❖ Evaluating your supplementary specifications
❖ Apply Analysis patterns effectively
❖ User Documentation
1
Object Oriented Analysis Overview
❖ Systems analysis : a problem-solving
technique that decomposes a system into its
component pieces for the purpose of
studying how well those component parts
work and interact to accomplish their
purpose.

2
 An Overview of Analysis

➢Analysis focuses on producing a model of the

system, called the analysis model, which is
complete, consistent, and verifiable.

➢Analysis(requirement) is different from

requirements elicitation in that developers focus
on structuring and formalizing the requirements
elicited from users.
3
Cont’d…
➢Analysis emphasizes on an investigation of the
problem and requirements, rather than a solution.
➢In software development, we are primarily concerned
with two forms of analysis.
➢Requirements Analysis: is discovering the
requirements that a system must meet in order to be
successful.
➢Object-Oriented Analysis: is investigating the objects
in a domain to discover information important to meet
the requirements.

4
Cont’d…
➢In software engineering, analysis is the process of
converting the user requirements to system
specification(developers view of the system).
➢system means the software to be developed.
➢system specification is the developers view of the
system.

5
 Cont’d…
➢ The goal of Analysis is to understand the
problem ,and to begin to develop a visual model of
what you are trying to build, independent of
implementation and technology concerns.
➢ Analysis focuses on translating the functional and
non functional requirements into software concepts.
➢The idea is to get a rough cut at the objects that
comprise our system, but focusing on behavior.
➢We then move very quickly, nearly seamlessly into
“design” and the other concerns.
6
 Analysis Vs Design
Analysis Design
➢Focus on understanding ➢Focus on understanding
the problem the solution
➢Idealized design ➢Actual design
➢Behavior ➢System structure
➢Close to real code
➢Object lifecycles

7
 Analysis Concepts
➢entity, boundary, and control objects
➢association multiplicity
➢qualified associations

8
 Entity, Boundary, and Control Objects

The analysis object model consists of entity, boundary, and

control objects.
➢Entity objects(model): represent the persistent
information tracked by the system.
✓Objects representing system data, often from the domain
model.
➢Boundaries (view):Objects that interface with system
actors (e.g. a user or external service). Windows, screens
and menus are examples of boundaries that interface with
users.
✓represent the interactions between the actors and the
system. 9
 Entity, Boundary, and Control Objects

➢Controls (controller):Objects that mediate

between boundaries and entities.
✓These serve as the glue between boundary
elements and entity elements, implementing the
logic required to manage the various elements and
their interactions.
✓represent the tasks that are performed by the
user and supported by the system.

10
Entity, Boundary, and Control Objects
The 2Bwatch example:
✓entity objects: Year, Month, Day
✓Boundary objects: ButtonBoundary and
LCDDisplayBoundary
✓ control object: ChangeDateControl represents
the activity of changing the date by pressing
combinations of buttons.

11
What is UML?
➢The UML is a visual modeling language that enables
system builders to create blueprints that capture their
visions in a standard, easy-to-understand way, and provides
a mechanism to effectively share and communicate these
visions with others.
➢UML is standard language to specify, visualize, construct,
and document the artifacts of software systems, as well as
other non-software systems.
➢It uses graphical notations to express the design of
software projects. You can choose to use UML tool for
establishing requirement.

12
Why we model?
➢To develop software rapidly, efficiently, and effectively,
with a minimum of software scrap and rework, you need to
have the right people, the right tools, and the right focus.
➢Modeling is a central part of all the activities that lead up
to the deployment of good software.
➢We build models to communicate the desired structure
and behavior of our system.
➢We build models
✓to visualize and control the system's architecture.
✓to better understand the system
✓for simplification and reuse.
✓to manage risk
13
Naming of Object Types in UML

World or system?
<<Entity>> <<Boundary>>
Year <<Control>> Button
ChangeDate
<<Entitity>>
Month <<Boundary>>
LCDDisplay
<<Entity>>
Day

Entity Objects Control Objects Boundary Objects

14
Recommended Naming Convention for Object Types
➢To distinguish the different object types on a syntactical basis,
we recommend suffixes:
➢Objects ending with the “_Boundary” suffix are boundary
objects
➢Objects ending with the “_Control” suffix are control objects
➢Entity objects do not have any suffix appended to their name.
Year
ChangeDate_ Button_Boundary
Month Control

Day LCDDisplay_Boundary

15
Association Multiplicity Revisited

➢In relationship establishment the end of an

association can be labeled by a set of integers
called multiplicity.

➢The multiplicity indicates the number of links .

➢For example, in a 2Bwatch has exactly two
Buttons and one LCDDisplay.

16
Association Multiplicity Revisited

17
Cont’d…
❖three types

➢A one-to-one association :has a multiplicity 1 on

each end. A one-to-one association between two
classes (e.g., Teacher and BadgeNumber), means that
exactly one link exists between instances of each class
(e.g., a Teacher has exactly one BadgeNumber, and a
BadgeNumber denotes exactly one Teacher).
18
Cont’d…
➢A one-to-many association has a multiplicity 1 on
one end and 0.... n (also represented by a star) or 1...
n on the other

(e.g. a FireUnit owns one or more FireTrucks, a

FireTruck is owned exactly by one FireUnit).

19
 Cont’d…

➢A many-to-many association has a multiplicity 0...n or

1...n on both ends. A many-to- many association
between two classes. (e.g., a FieldOfficer can write for
many IncidentReport, an IncidentReport can be written
by many FieldOfficer).

20
 Qualified Associations

➢Qualification is a technique for reducing multiplicity by

using keys. Associations with a 0...1 or 1 multiplicity are
easier to understand than associations with a 0...n or
1...n multiplicity.
➢the association between Directory and File has a one
multiplicity on the Directory side and many multiplicity
on the File side.
➢We reduce the multiplicity on the File side by using the
filename attribute as a key, also called a qualifier. The
relationship between Directory and File is called a
qualified association.
21
Qualified Associations
➢A qualified association associates two objects
using a qualifier to select objects at the other end
of the association.

➢A qualifier is an attribute or set of attributes

which has a unique value for each object in the
class.

9-22
Qualified Associations

9-23
24
25
Use case modelling
❖ In software and systems engineering, a use case
is a list of actions or event steps, typically defining
the interactions between a role (known in the
Unified Modeling Language as an actor) and a
system, to achieve a goal.
❖ The actor can be a human or other external
system
❖ A use case is a sequence of transactions
performed by a system that yields a measurable
result of values for a particular actor

26
Use case modelling
❖ Use cases model: a dialogue between an actor
and the system.
❖ A use-case model is a model of the system's
intended functions and its surroundings, and serves
as a contract between the customer and the
developers
❖ They represent the functionality provided by the
system; that is,
➢ what capabilities will be provided to an actor by the
system.

27
 Use case modeling
➢use case is also constructed incrementally; don’t be
worried that your initial use case looks to simple, and
don’t be afraid to add things to your use case.
➢Write up high level use cases first.
– Concentrate on name, actors, and overview.
– Big, end-to-end use cases first; then additional use cases
with the include, generalize and extend relationships.

28
Use case relationships
➢Use cases can be generalized or specialized (gen-
spec) much like a class.
➢One Use Case may include the functionality of
another as part of its normal processing.
➢Generally, it is assumed that the included Use
Case will be called every time the basic path is run.
An example may be to list a set of customer orders
to choose from before modifying a selected order -
in this case the <list orders> Use Case may be
included every time the <modify order> Use Case is
run.
29
Use case relationships
➢One Use Case may extend the behavior of another
typically when exceptional circumstances are
encountered.
◦For example, if before modifying a particular
type of customer order, a user must get
approval from some higher authority, then the
<get approval> Use Case may optionally
extend the regular <modify order> Use Case.
➢The arrow always points at use case that is being
included or extended.
30
 Use case diagrams
➢ The representation of the user’s interaction with the system that
shows the relationship between the user and different use cases in
which the user is involved.
➢ Describe the functional behavior of the system as seen by the user.
➢ Use-cases are a scenario based technique in the UML which identify
the actors in an interaction and which describe the interaction itself
➢ A set of use cases should describe all possible interactions with the
system
➢ Sequence diagrams may be used to add detail to use-cases by
showing the sequence of event processing in the system

31
Guidelines for Formulation of Use
Cases
➢Name
✓Use a verb phrase to name use case.
✓Name should indicate what user is trying to accomplish.
✓Examples:
◦“Request Meeting”, “Schedule Meeting”, “Propose
Alternate Date”
➢Length
✓A use case description should not exceed 1-2 pages. If
longer, use include relationships.
✓A use case should describe a complete set of interactions.

32
Guidelines for Formulation of Use
Cases
➢Flow of events:
▪ Use active voice. Steps should start either with “The Actor
…” or “The System ”.
▪ Causal relationship between steps should be clear.
▪ All flow of events should be described (not only main flow
of event).
▪ Boundaries of the system should be clear. Components
external to the system should be described as such(scope).
❖Steps to make usecase:Identify scope, Identify Actors,
Identify use cases, use links, Construct use case diagram

33
Cont’d…

Actor: person, system….

:anything that exchanges data with
the system, usually
:external to the system.
Use Use case: what the actors want your system to
case
do for them.
:a complete course of events
Communication link: links the actor and use case.
Careful: Lines between Actors and Use Cases are NOT data flows!
34
Cont’d…

35
 Cont’d…
➢.

Reg.
patient

Unreg.
patient

View
patient info

Medical Transfer
Recip. data

Contact
patient
Fig: use case involving medical receptionist
36
Cont’d…

37
Scenario
➢A synthetic description of an event or series of actions and
events.
➢A textual description of the usage of a system. The description is
written from an end user’s point of view.
➢A scenario can include text, video, pictures and story boards
➢A scenario is an instance of a use case
➢It expresses a specific occurrence of the use case (a specific path
through the use case):
✓A specific actor ,At a specific time ,With specific data …
➢Many scenarios may be generated from a single use case
description
➢Each scenario may require many test cases

38
Modeling Interactions between Objects:
Sequence Diagrams

➢A sequence diagram ties use cases with objects. It

shows how the behavior of a use case (or scenario)
is distributed among its participating objects.
➢Sequence diagrams are derived from flows of
events of use cases
➢An event always has a sender and a receiver

39
Sequence Diagrams
➢Shows the objects participating in the interaction
by their life lines and the messages they exchange
➢Illustrates how objects interacts with each other.
➢Emphasizes time ordering of messages.
➢Can model simple sequential flow, branching,
iteration, recursion and concurrency.

40
Interactions, Lifelines, and Messages
❖An interaction is a behavior that focuses on the
observable exchange of information between
objects.
❖A lifeline represents the participation of a given
object in a particular interaction.
❖A lifeline in a sequence diagram is displayed with
its name and type in a rectangle, which is called the
head.
❖The head is located on top of a vertical dashed
line, called the stem, which represents the timeline
for the instance of the object.
41
 Interactions, Lifelines, and Messages

❖ Objects communicate via messages between lifelines.

❖ The notation for a message is always an arrow, but the
nature of the arrow and the arrowhead varies based
on the type of message, as follows:

42
Interactions, Lifelines, and Messages
1. A synchronous call or signal message appears as a solid
line with a solid arrowhead.
A message is sent from the source lifeline to the target
lifeline. The source lifeline is blocked from other operations
until it receives a response from the target lifeline.
2. An asynchronous call or signal message appears as a
solid line with a half-arrowhead.
In contrast to a synchronous message, the source lifeline is
not blocked from receiving or sending other messages.
3. A reply message appears as a dashed line with an
arrowhead.

43
Interactions, Lifelines, and Messages
4. A "lost" message (one in which the sender is known but
the receiver is not known) has a small black circle next to
the arrowhead.
Activation: the time period during which an object performs
an operation.

44
 Objects/Classes

:Client :ATMMachine :SavingAccount

Insert ATM card

Request PIN

Enter PIN code

Verify PIN code

PIN valid

Request amount activation

Enter amount

Process transaction

Transaction successful

Dispense cash

Print receipt

lifeline
45
46
Example
These four objects participate in an interaction in
the following way:
-- the person kicks the cat,
--the cat reports to the inspector what the person
did to him,
--the inspector reports to the policeman what the
person did to the cat,
--the policeman arrests the person.

47
Note: RSPCA stands for Royal Society for the Prevention of Cruelty to Animals

48
Sequence diagram
➢A combined fragment is a combination of one or more
interaction operands, each of which contains one or more
interaction fragments, and an interaction operator, which
operates on those operands.
➢The most useful combined fragments are:
– Alternative fragment (denoted “alt”) models if…then…else
constructs.
The interaction operator alt means that the combined
fragment represents a choice or alternatives of behavior.
Divides fragment into groups and defines condition for each
group - only the one whose condition is true will execute .

49
 Cont’d….

– Option fragment (denoted “opt”) defines a choice between a

single defined set of traces occurring or no traces.
represents a choice of behavior where either the (sole) operand
happens or nothing happens.

50
Cont’d…
Defines condition to a single call - the call will execute only if the
supplied condition is true . Equivalent to an alt with only one trace.

51
Optional
fragment

52
You can read the preceding diagram as
follows:
1. The medical receptionist triggers the ViewInfo method in
an instance P of the PatientInfo object class, supplying the
patient’s identifier, PID. P is a user interface object, which is
displayed as a form showing patient information.
2. The instance P calls the database to return the
information required, supplying the receptionist’s identifier
to allow security checking (at this stage, we do not care
where this UID comes from).
3. The database checks with an authorization system that
the user is authorized for this action.
4. If authorized, the patient information is returned and a
form on the user’s screen is filled in. If authorization fails,
then an error message is returned.
53
– Loop
fragment
encloses a
series of
messages
which are
repeated.

Loop
fragment

54
Cont’d…
Break fragment:- The interaction operator break represents
a breaking or exceptional scenario that is performed instead of the
remainder of the enclosing interaction fragment.
A combined fragment with the operator break should cover all lifelines
of the enclosing interaction fragment.

55
 Sequence Diagrams Summary

➢Sequence diagrams represent behavior in terms of

interactions .
➢Complement the class diagrams (which represent
structure(spatial connectivity )).
➢Time consuming to build

56
Communication Diagrams
➢A communication diagram focuses on the
interaction between lifelines, where the
architecture of the internal structure and how this
corresponds with the message passing is central.
➢The messages are usually notated with sequence
numbers, which indicate the relative execution
order of the associated messages.
➢a communication diagram (formerly collaboration
diagram) for the fun example

57
58
Communication diagram.
Communication Diagrams
➢Communication diagrams and sequence diagrams are
semantically equivalent, which means that you can convert
one type of diagram to the other without losing any
information.
➢A sequence diagram does not have sequence numbers, but
it has a number of features that communication diagrams
do not offer.

60
Activity Diagrams
➢Based on data flow models – a graphical
representation (with a Directed Graph) of how
data move around an information system
➢Focus on flow of activity of internal process in
object
➢similar to flowchart/DFD
➢describe changes in activity in a procedure

61
Activity Diagrams
➢Activity diagrams do not give detail about how
objects behave or how objects collaborate.
➢Action is the fundamental unit of executable
functionality in an activity.
➢The notation for an action is a rectangle with
rounded corners.

Activity Nodes
➢There are several types of activity nodes
62
Activity Diagrams
1. An initial node is where the flow of control starts
when an activity is invoked.

shows the notation for an initial node.

2. A final node is a control node at which one or
more flows within the given activity stop.
There are two types of final nodes:
-flow final nodes
-and activity final nodes.
63
 Activity Diagrams
A flow final node terminates a particular flow.

Flow final node

An activity final node terminates all flows within the
activity and thus terminates the activity itself.

Activity final node

3. A decision node offers a choice among two or more
outgoing activity edges, each of which has a guard,
which is a Boolean expression that must resolve to True
before the associated path can be taken. 64
Activity Diagrams
➢A decision node appears as a diamond, as shown in Figure

➢Merge node also the same as decision node

4. A fork node splits/joins flow into/from multiple concurrent
flows.
➢the notation for a fork node, which is a long, thin black
rectangle. 65
Activity Diagram: General skeleton

66
Example:Activity Diagram for Register Course
start

Fill form Select course

[No]

Submit
approve?

[Yes]

Register
course end

67
Example: Activity Diagram for ATM Authorization

Enter card Read card

Enter PIN Request PIN

[No]

Verify PIN valid?

[Yes]

Select other
service

68
When to use Activity Diagram?
➢to model the workflow behind the system being
designed.
➢analyzing a use case by describing what actions
need to take place and when they should occur.
➢describing a complicated sequential algorithm.
and modeling applications with parallel processes.
➢documenting existing process
➢analyzing new Process Concepts
➢finding reengineering opportunities

69
Activity Diagram limitation
➢A disadvantage of activity diagrams is that they
do not explicitly present which objects execute
which activities, and the way that the messaging
works between them.

70
Class diagram
➢A class is a collection of things or concepts that have the
same characteristics. Each of these things or concepts is
called an object.
➢The most important characteristics that classes share are
captured as attributes and operations.
➢The standard UML notation for a class is a box with three
compartments. The top compartment contains the name of
the class, in boldface type; the middle compartment
contains the attributes that belong to the class; and the
bottom compartment contains the class's operations.

71
 Class diagram

➢ You can, however, show a class without its attributes or its

operations, or the name of the class can appear by itself

Alternate Class Notation

72
Class diagram
➢Class names are simple nouns or noun phrases. Each Word
is capitalized.
➢Attribute names are also simple nouns or noun phrases.
The first word is not capitalized, but subsequent words are.
Acronyms tend to appear in all upper case letters.
➢Operation names are simple verbs. As with attributes, the
first word is not capitalized and subsequent words are;
acronyms tend to appear in all uppercase letters here as
well.

73
 Class Relationships
The following sections explore how UML can be used to
illustrate various kinds of class relationships.
1. Associations
➢ An association is a simple structural connection between
classes.

74
Class relationship
➢You can add several kinds of details, or adornments, to an
association.
---An association can have a name that indicates the nature
of the relationship.
---An association can contain roles, which are the faces that
classes present to other classes.
---An association can show multiplicity.
2. Aggregation
➢An aggregation is a special kind(stronger form) of
association—a "whole/part" relationship within which one
or more classes are parts of a larger whole.
75
Class relationship
➢An aggregation appears as a line with an open diamond at
one end. The class next to the diamond is the whole class;
the class at the other end of the line is the part class.

Aggregation notation
3. Composition
➢is a "strong" form of aggregation.
76
Class relationship
➢There are two differences between composition and
regular aggregation, as follows:
•Within a composition relationship, “the whole” and “the
parts” have coincident lifetimes.
•A class can only belong to one composition relationship
at a time as a part.
➢Composition is shown using a closed, or filled, diamond
arrowhead,

77
Class relationship

a Sample composition
with multiplicity

78
Class relationship
4. Generalization (Otherwise Known as Inheritance)
➢Generalization and inheritance are used to describe a class
that is a type of another class.
➢A generalization appears as a line with an open triangle at
one end. The class next to the triangle is the
parent/superclass; the class at the other end of the line is
the child/subclass.

Generalization notation
79
Class relationship
5. Dependencies.
➢A dependency is a "using" relationship within which a
change in one thing (such as a class) may affect another
thing (for instance, another class).
--the dependent element is called the client or source;
--the independent element is called the supplier or target.
➢A dependency involving two classes appears as a dashed
line with a feathered arrow pointing at the supplier.

80
Class Diagram
➢A class diagram in the Unified Modeling Language (UML) is
a type of static structure diagram that describes the
structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships
among the classes.
➢Class diagrams play a central role in object-oriented
analysis and design.
Note:
Component diagrams and deployment diagrams are similar
to class diagrams, except that instead of containing classes
they contain components and nodes, respectively.

81
Class Diagram
➢Class diagrams are great for:
– discovering related data and attributes.
– getting a quick picture of the important entities in a system.
– seeing whether you have too few/many classes.
– seeing whether the relationships between objects are too
complex, too many in number, simple enough, etc.
– spotting dependencies between one class/object and another
• Not so great for:
– discovering algorithmic (not data-driven) behavior.
– finding the flow of steps for objects to solve a given problem.
– understanding the app's overall control flow (event-driven? web-
based? sequential? etc.)

82
Class Diagram
➢Class diagrams involve three stages of a typical
software development project:
--requirements,
-- analysis,
-- and design.
Domain-Level Class Diagrams
➢A domain-level class diagram shows just the
names of classes only.

83
Domain-level class diagram
84
Class Diagram
Analysis-Level Class Diagrams
➢An analysis-level class diagram typically shows attributes; it
may show other adornments such as multiplicity and role
names as well.
➢An analysis-level diagram, though, shouldn't have
operations, because deciding where to put what operations
definitely falls into the design arena.

85
an example of an analysis-level class diagram.

86
Class Diagram
Design-Level Class Diagrams
➢You can expand your classes using the full UML notation,
or you can explore classes at a lower level of abstraction and
continue to suppress the details (perhaps because those
details are well-defined elsewhere).
➢One form of design-level class diagram is simply a more
expansive version of an analysis-level diagram.
➢In Figure below is shown an example of a design level
class diagram

87
88
User Interface Prototyping
➢User interface prototyping is an iterative analysis
technique in which users are actively involved in the
mocking-up of the UI for a system.
➢It has two purposes:
✓First, it is an analysis technique because it enables you to
explore the problem space your system addresses.
✓Second, enables you to explore the solution space of your
system at least from the point-of-view of its users, and
provides the possible UI design(s) of your system.
➢ There are four high level steps are in the UI
prototyping process:
89
User Interface Prototyping
1. Determine the needs of your users
2. Build the prototype
3. Evaluating the prototype
4. Determine if you are finished
User Interface Prototyping Tips and Techniques
➢Work with the real users
➢Get your stakeholders to work with the prototype
➢Understand the underlying business
➢You should only prototype features that you can actually
build
➢You cannot make everything simple
➢It's about what you need
90
Con’t…
➢Get an interface expert to help you design it
➢Explain what a prototype is
➢Consistency is critical
➢Avoid implementation decisions as long as possible
➢Small details can make or break your user interface

91
Reviewing the Analysis Model

➢The analysis model is built incrementally and

iteratively.
➢The analysis model is seldom correct or even
complete on the first pass.
➢Several iterations with the user are necessary
before the analysis model converges toward a
correct specification usable by the developers for
proceeding to design and implementation.

92
Reviewing the Analysis Model

➢Once the analysis model becomes stable (i.e.,

when the number of changes to the model are
minimal and the scope of the changes localized),
the analysis model is reviewed,
✓first by the developers (i.e., internal reviews),
then
✓jointly by the developers and the client.
➢The goal of the review is to make sure that the
system specification is correct, complete,
consistent, and realistic.

93
Questions to be asked to ensure that the model is correct:
❖Is the glossary of entity objects understandable
by the user?
❖Are all descriptions in accordance with the
users’ definitions?
❖Do all entity and boundary objects have
meaningful noun phrases as names?
❖Are all error cases described and handled?

94
Questions should to be asked to ensure that the model is complete
❖For each object:
✓ Is it needed by any use case?
✓In which use case is it created? modified? destroyed?
❖For each attribute:
✓When is it set?
✓What is its type?
✓Should it be a qualifier?

95
Questions should to be asked to ensure that the model is complete
❖For each association:
✓When is it traversed?
✓Why was the specific multiplicity chosen?
✓ Can associations with 1...1 and *…* multiplicities be
qualified?
❖For each control object:
✓ Does it have the necessary associations to access the
objects participating in its corresponding use case?

96
 Questions to be asked to ensure that the model is
consistent:

❖Are there multiple classes or use cases with the

same name?
❖Do entities (e.g., use cases, classes, attributes)
with similar names denote similar phenomena?
❖Are all entities described at the same level of
detail?

97
Questions to be asked to ensure that the system described by
the analysis model is realistic:
❖Are there any novel features in the system?
❖Were there any studies or prototypes built to
ensure their feasibility?
❖Can the performance and reliability
requirements be met? Were these requirements
verified by any prototypes running on the
selected hardware?

98
 Object Oriented Analysis
➢Identifying objects: Using concepts, CRC cards, stereotypes, etc.
➢Organising the objects: classifying the objects identified, so
similar objects can later be defined in the same class.
➢Identifying relationships between objects: this helps to
determine inputs and outputs of an object.
➢Defining operations of the objects: the way of processing data
within an object.
✓By using methods
➢Defining objects internally: information held within the objects.
✓By using attributes

99
 Basic ways to do Object Oriented Analysis
❖Conceptual model :Produce a “light” class diagram.
➢is a representation of a system made of the composition of
concepts which are used to help people know, understand or
simulate a subject the model represents.
❖Analysis model with stereotypes: Boundaries, entities, control.
➢Allow designers to extend UML in order to create a new model
elements derived from the existing ones, but have specific
properties that are suitable for a particular domain.

100
End of chapter three!!!

101