CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

CHAPTER II STRUCTURAL MODELING

1. UML - STANDARD DIAGRAMS

In the previous chapters, we have discussed about the building blocks and other necessary elements of
UML. Now we need to understand where to use those elements.

The elements are like components which can be associated in different ways to make a complete UML
picture, which is known as diagram. Thus, it is very important to understand the different diagrams to
implement the knowledge in real-life systems.

Any complex system is best understood by making some kind of diagrams or pictures. These diagrams
have a better impact on our understanding. If we look around, we will realize that the diagrams are not a
new concept but it is used widely in different forms in different industries.

We prepare UML diagrams to understand the system in a better and simple way. A single diagram is not
enough to cover all the aspects of the system. UML defines various kinds of diagrams to cover most of
the aspects of a system.

You can also create your own set of diagrams to meet your requirements. Diagrams are generally made in
an incremental and iterative way.

There are two broad categories of diagrams and they are again divided into subcategories −

• Structural Diagrams

• Behavioral Diagrams

1.1. Structural Diagrams

The structural diagrams represent the static aspect of the system. These static aspects represent those parts
of a diagram, which forms the main structure and are therefore stable.
These static parts are represented by classes, interfaces, objects, components, and nodes. The four
structural diagrams are:

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Class Diagram

Class diagrams are the most common diagrams used in UML. Class diagram consists of classes, interfaces,
associations, and collaboration. Class diagrams basically represent the object-oriented view of a system,
which is static in nature.

Active class is used in a class diagram to represent the concurrency of the system.

Class diagram represents the object orientation of a system. Hence, it is generally used for development
purpose. This is the most widely used diagram at the time of system construction.

Object Diagram

Object diagrams can be described as an instance of class diagram. Thus, these diagrams are more close to
real-life scenarios where we implement a system.

Object diagrams are a set of objects and their relationship is just like class diagrams. They also represent
the static view of the system.

The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system
from a practical perspective.

Component Diagram

Component diagrams represent a set of components and their relationships. These components consist of
classes, interfaces, or collaborations. Component diagrams represent the implementation view of a system.

During the design phase, software artifacts (classes, interfaces, etc.) of a system are arranged in different
groups depending upon their relationship. Now, these groups are known as components.

Finally, it can be said component diagrams are used to visualize the implementation.

Deployment Diagram

Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where
the components are deployed.

Deployment diagrams are used for visualizing the deployment view of a system. This is generally used by
the deployment team.
Note − If the above descriptions and usages are observed carefully then it is very clear that all the diagrams
have some relationship with one another. Component diagrams are dependent upon the classes, interfaces,
etc. which are part of class/object diagram. Again, the deployment diagram is dependent upon the
components, which are used to make component diagrams.

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

2.2. Behavioral Diagrams

Any system can have two aspects, static and dynamic. So, a model is considered as complete when both
the aspects are fully covered.

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further
described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams:

• Use case diagram(to know how the users are going to interact with the system)
• Sequence diagram (interaction diagrams)
• Collaboration diagram
• Statechart diagram
• Activity diagram

Use Case Diagram

Use case diagrams are a set of use cases, actors, and their relationships. They represent the use case view
of a system. ‘

A use case represents a particular functionality of a system. Hence, use case diagram is used to describe
the relationships among the functionalities and their internal/external controllers. These controllers are
known as actors.

Sequence Diagram

A sequence diagram is an interaction diagram. From the name, it is clear that the diagram deals with some
sequences, which are the sequence of messages flowing from one object to another.

Interaction among the components of a system is very important from implementation and execution
perspective. Sequence diagram is used to visualize the sequence of calls in a system to perform a specific
functionality.

Collaboration Diagram

Collaboration diagram is another form of interaction diagram. It represents the structural organization of
a system and the messages sent/received. Structural organization consists of objects and links.

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

The purpose of collaboration diagram is similar to sequence diagram. However, the specific purpose of
collaboration diagram is to visualize the organization of objects and their interaction.

Statechart Diagram

Any real-time system is expected to be reacted by some kind of internal/external events. These events are
responsible for state change of the system.

Statechart diagram is used to represent the event driven state change of a system. It basically describes the
state change of a class, interface, etc.

State chart diagram is used to visualize the reaction of a system by internal/external factors.

Activity Diagram

Activity diagram describes the flow of control in a system. It consists of activities and links. The flow can
be sequential, concurrent, or branched.

Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to capture
the entire flow in a system.

Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an idea
of how the system will work when executed.

Note: Dynamic nature of a system is very difficult to capture. UML has provided features to capture the
dynamics of a system from different angles. Sequence diagrams and collaboration diagrams are
isomorphic, hence they can be converted from one another without losing any information. This is also
true for Statechart and activity diagram.

All the diagrams in UML can be summarized as shown below:

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Diagram Elements Purpose View
Class Diagram Class, Interface, To model the Static design view
Collaboration and structure/skeleton of the Static process view (active
Relationships software system classes)
Object Diagram Objects and To model the structure of Static design view
Relationships the software system Static process view (active
classes)
Component Components and To model the components Implementation view
Diagram Relationships in the software system
Deployment Nodes and To model the runtime Deployment view
Diagram Relationships structure of the software
system
Use Case Use cases, actors To model the behavior of Static use case view
Diagram and relationships the system

Sequence Objects and To model the time Dynamic view

Diagram messages ordering of messages

Collaboration Objects and To model the structural Dynamic view

Diagram messages organization of the
objects
Statechart States, transitions, To model the behavior as Dynamic view
Diagram events and a sequence of state
activities changes

Activity Activities, To model the behavior Dynamic view

Diagram transitions and as a set of activities
other control
flow symbols

2. MODELING UML CLASS DIAGRAM

Class Notation
UML class is represented by the following figure. The diagram is divided into four parts.

• The top section is used to name the class.

• The second one is used to show the attributes of the class.
• The third section is used to describe the operations performed by the class.
• The fourth section is optional to show any additional components.

Page 5
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Visibility:
One of the important features that can be applied to the classifier’s attributes and operations is the
visibility. The visibility feature specifies whether a classifier can be used or accessed by the other
classifiers. The four access specifiers in UML are as shown below:

Symbol Name Description

+ Public Accessible by all other classifiers
# Protected Accessible only by the descendents and the classifier itself
~ Package Accessible by all the classifiers with the same package
- Private Accessible only by the classifier in which they are available

Attributes:
While modeling classes, it is reasonable to write only the attribute name. Along with the name,
you can also specify multiplicity, visibility and scope. Apart from these features, we can also specify the
type, initial value and changeability of each attribute. The syntax of an attribute in UML is:

[visibility] name [multiplicity] [: type] [=initial value] [{property string}]

Examples:

origin Name only

+ origin Name and visibility
origin : Point Name and type
head : *Item Name and complex type
name [0..1] : String Name, multiplicity and type
origin : Point = {0,0} Name, type and initial value
id : Integer {frozen} Name and property

The three predefined properties that can be used with attributes in UML are :

Page 6
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

changeable No restrictions on modifying the attributes value

addOnly For attributes with multiplicity greater than one, values may be added but not
removed or altered once it is created
frozen Once created the value of an attribute cannot be changed

Operations:
While modeling classes, it is simple to write only the operation name. Along with the name we can
also mention the visibility and scope. Apart from these basic details, we can also specify the return type,
parameters, concurrency semantics and other features. The syntax of an operation in UML is:
[visibility] name [(parameters-list)] [: return-type] [{property-string}]
Examples:
display Name only
+ display Name and visibility
set(n : Name, s : String) Name and parameters
getID() : Integer Name and return type
restart() {guarded} Name and property

The signature of parameter in the parameters list of an operation is as follows:

[direction] name :type [=initial value]

Direction may be anyone of the following values:

in An input parameter, may not be modified

out An output parameter, may be modified
inout An input parameter, may be modified

The operation name, parameters list and its return type is collectively known as the signature of the
operation.
There are four predefined properties (stereotypes) that can be applied to operations, in UML. They are:

Page 7
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

isQuery Execution of the operation does not change the state of the system.
sequential Denotes that the operation is suitable for sequential access only.
guarded Indicates that the operation guarantees integrity in case of concurrent access.
Concurrent calls will be performed in a sequential manner.
concurrent Denotes that the operation can be called concurrently and the integrity of the
object will be preserved. Operation executes on the object concurrently.

Relationships :
When we are modeling the system first of all we start is identifying things. These things will not
stay alone. They collaborate with each other means they are connected with others in some way. These
connections between the things are known as relationships.
In object-oriented modeling, there are three main relationships between the things:
1) Dependency,
2) Associations
3) Generalization.

Dependency:
A semantic relationship, in which a change in one thing (the independent thing) may cause changes in the
other thing (the dependent thing). A dependency is a using relationship. In this relationship one thing
depends on the other thing. The change in independent thing will affect the dependent thing. Dependency
is graphically represented as a dashed directed line. The arrow head points towards the independent thing.

Generalization:
The generalization relationship also known as the is-a relationship is between two things where one thing
is general (superclass) and the other is specific thing (subclass) of the general thing. Graphically,
generalization is represented as a solid line with a hollow arrow head pointing towards the general thing

Page 8
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

A class with no parents and having one or more child classes is called root class. A class with no
child’s is called a leaf class. A class with exactly one parent is known as single inheritance and a class
having multiple parents is known as multiple inheritance.

Association:
An association is a structural relationship which connects one thing with another. Given an
association between two things, we can navigate from one thing to the other thing and vice versa. It is also
common for a thing to have a self association.
An association which connects exactly two classes is known as binary association. An association
which connects n number of classes is known as n-nary association. Graphically association is represented
as a solid line. Apart from this basic representation, an association has four adornments:

Name: An association can have a name which let’s you represent the meaning of the association. The
name is written on top of the association. We can also represent the direction in which the name is read.

Role: A thing participating in an association will have a specific role. This role can be represented by
writing it outside, near to the thing and below or above the association.

Multiplicity: The multiplicity is an indication of how many objects may participate in the given
relationship, or the allowable number of instances of the element.When connecting things with
association, we are concerned about how many objects of one class can connect across an instance of the
association. This “how many” is known as multiplicity of an association’s role and is written as an
expression.

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Aggregation: In some cases we might come across “whole-part” relationships between two things, in
which one thing is a part of another thing. Such relationship is known as an aggregation or also known as
“has-a” relationship. Aggregation is a special case of the association relationship. Aggregation is
represented as a solid line with a hollow diamond head towards the whole thing.

Composition:
The composition is a flavor of association relationship. Composition as well as aggregation
relationships represent whole-part relationships, in which one thing is a part of the other thing. There is a
simple difference between the association and composition relationships. In composition, the lifetime of
the part is dependent of the lifetime of the whole thing. Where as in aggregation, the lifetime of the part is
independent of the whole thing.
Composition is graphically represented by adorning the association relationship with a filled
diamond head near the whole end. (There are dependent to each other in composition on while in
agregation it doesn’t depends on the whole things.Another name for composition is called containement)

Association Class :
Sometimes in an association relationship, the association might have attributes or properties like a
class does. In such cases, it is modeled as an association class. An association class in UML is represented
with a class icon attached to the association with a dashed line.

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application. Class diagrams are the only
diagrams which can be directly mapped with object-oriented languages and thus widely used at the time
of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application,
however class diagram is a bit different. It is the most popular UML diagram in the coder community.
The purpose of the class diagram can be summarized as :
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
How to Draw a Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software applications.
It is very important to learn the drawing procedure of class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram will be considered
from a top level view.
Class diagram is basically a graphical representation of the static view of the system and represents
different aspects of the application. A collection of class diagrams represent the whole system.
The following points should be remembered while drawing a class diagram :

• The name of the class diagram should be meaningful to describe the aspect of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly identified
• For each class, minimum number of properties should be specified, as unnecessary properties
will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the end of the
drawing it should be understandable to the developer/coder.

[email protected] www.cameroonhnd.com 678866022 | 671633180

 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

• Finally, before making the final version, the diagram should be drawn on plain paper and
reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a particular aspect
of the entire application.

• First of all, Order and Customer are identified as the two elements of the system. They have a one-
to-many relationship because a customer can have multiple orders.
• Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
• The two inherited classes have all the properties as the Order class. In addition, they have additional
functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.

Where to Use Class Diagrams ?

Class diagram is a static diagram and it is used to model the static view of a system. The static view
describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams. Class
diagrams are not only used to visualize the static view of the system but they are also used to construct the
executable code for forward and reverse engineering of any system.

Page 12
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Generally, UML diagrams are not directly mapped with any object-oriented programming languages but
the class diagram is an exception.
Class diagram clearly shows the mapping with object-oriented languages such as Java, C++, etc. From
practical experience, class diagram is generally used for construction purpose.
In a nutshell it can be said, class diagrams are used for :

• Describing the static view of the system.

• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object oriented languages.
EXAMPLE :

Page 13
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Set of Operations for the Classes:

Page 14
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Exercise: University Teams Scenario

• In the project analysis course at ISTAMA, students are members of teams.
• Each team has 2 or 3 members.
• Each team completes 0 to 3 assignments.
• Each student takes exactly one midterm test.
• Computer Science students have a single account on the CSC facility, while each engineering
student has an account on the Engineering facility.
• Each assignment and midterm is assigned a mark
Design a Class Diagram for the scenario

Exercise: University 2 Scenario

• A university offers degrees to students.
• The university consists of faculties each of which consists of one or more departments.
• Each degree is administered by a single department.
• Each student is studying towards a single degree.
• Each degree requires one to 20 courses.
• A student enrolls in 1-5 courses (per term.)
• A course can be either graduate or undergraduate, but not both.
• Likewise, students are graduates or undergraduates but not both.

Page 15
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Draw a class diagram, which represents the generic objects and relationships, described above. Make
sure to specify multiplicities for all associations shown in your diagrams.

Exercise: Organization Scenario

• Consider the world of companies:
• Companies employ employees (who can only work for one company), and consist of one or more
departments.
• Each company has a single president, who is an employee.
• Departments have employees as members and run projects (one or more.)
• Employees can work in 1 to 3 projects, while a project can have 2 to 50 assigned employees.
• You may assume that companies have a name and address, while employees have a emp# and a
salary
Design a Class Diagram

Forward and Reverse Engineering

Forward engineering is the process of transforming a model into code through a mapping to an
implementation language
➢ Forward engineering results in a loss of information, because models written in the UML are
semantically richer than any current object-oriented programming language.
➢ To forward engineer a class diagram,
• Identify the rules for mapping to your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
• Depending on the semantics of the languages you choose, you may have to constrain your use of
certain UML features. For example, the UML permits you to model multiple inheritance, but
Smalltalk permits only single inheritance. You can either choose to prohibit developers from
modeling with multiple inheritance (which makes your models language-dependent) or develop
idioms that transform these richer features into the implementation language (which makes the
mapping more complex).
• Use tagged values to specify your target language. You can do this at the level of individual classes
if you need precise control. You can also do so at a higher level, such as with collaborations or
packages.
• Use tools to forward engineer your models.

Reverse engineering is the process of transforming code into a model through a mapping from a specific
implementation language.

Page 16
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

➢ Reverse engineering results in a flood of information, some of which is at a lower level of detail than
you'll need to build useful models.
➢ Reverse engineering is incomplete. There is a loss of information when forward engineering models
into code, and so you can't completely recreate a model from code unless your tools encode information
in the source comments that goes beyond the semantics of the implementation language.
➢ To reverse engineer a class diagram,
• Identify the rules for mapping from your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
• Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new
model or modify an existing one that was previously forward engineered.
• Using your tool, create a class diagram by querying the model. For example, you might start with
one or more classes, then expand the diagram by following specific relationships or other
neighboring classes. Expose or hide details of the contents of this class diagram as necessary to
communicate your intent.

3. MODELING UML OBJECT DIAGRAM

An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects have been
instantiated, we are able to study the behavior of the system at a particular instant. Object diagrams are
vital to portray and understand functional requirements of a system.
In other words, “An object diagram in the Unified Modeling Language (UML), is a diagram that
shows a complete or partial view of the structure of a modeled system at a specific time.”

Difference between an Object and a Class Diagram :

An object diagram is similar to a class diagram except it shows the instances of classes in the system.
We depict actual classifiers and their relationships making the use of class diagrams. On the other hand,
an Object Diagram represents specific instances of classes and relationships between them at a point of
time.
An Object Diagram is a structural diagram which uses notation similar to that of class diagrams.
Object Diagrams use real world examples to depict the nature and structure of the system at a
particular point in time. Since we are able to use data available within objects, Object diagrams provide
a clearer view of the relationships that exist between objects.

How to draw an Object Diagram ?

Page 17
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

1. Draw all the necessary class diagrams for the system.
2. Identify the crucial points in time where a system snapshot is needed.
3. Identify the objects which cover crucial functionality of the system.
4. Identify the relationship between objects drawn

Basic Object Diagram Symbols and Notations

Object Names :
Every object is actually symbolized like a rectangle, that offers the name from the object and its class
underlined as well as divided with a colon

Object Attributes :
Similar to classes, you are able to list object attributes inside a separate compartment. However, unlike
classes, object attributes should have values assigned for them

Links :
Links tend to be instances associated with associations. You can draw a link while using the lines
utilized in class diagrams

Example :
The following diagram is an example of an object diagram. It represents the Order management system
which we have discussed in the chapter Class Diagram. The following diagram is an instance of the system
at a particular time of purchase. It has the following objects.
• Customer

• Order

• SpecialOrder

• NormalOrder

Page 18
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Now the customer object (C) is associated with three order objects (O1, O2, and O3). These order objects
are associated with special order and normal order objects (S1, S2, and N1). The customer has the
following three orders with different numbers (12, 32 and 40) for the particular time considered.
The customer can increase the number of orders in future and in that scenario the object diagram will
reflect that. If order, special order, and normal order objects are observed then you will find that they have
some values.
For orders, the values are 12, 32, and 40 which implies that the objects have these values for a particular
moment (here the particular time when the purchase is made is considered as the moment) when the
instance is captured
The same is true for special order and normal order objects which have number of orders as 20, 30, and
60. If a different time of purchase is considered, then these values will change accordingly.
The following object diagram has been drawn considering all the points mentioned above

Class to Object Diagram Example - Order System

Page 19
[email protected] www.cameroonhnd.com 678866022 | 671633180
 CMR HND PLATFORM LEARN TODAY, LEAD TOMORROW HND E-LEARNING PLATFORM

INTRODUCTION TO OBJECT ORIENTED MODELING

Uses of an Object Diagram :

• Model the static design (similar to class diagrams) or structure of a system using prototypical
instances and real data.
• Helps us to understand the functionalities that the system should deliver to the users.
• Understand relationships between objects.
• Visualise, document, construct and design a static frame showing instances of objects and
their relationships in the dynamic story of life of a system.
• Verify the class diagrams for completeness and accuracy by using Object Diagrams as
specific test cases.
• Discover facts and dependencies between specific instances and depicting specific examples of
classifiers.

Page 20
[email protected] www.cameroonhnd.com 678866022 | 671633180