Chapter two

Modeling concept
 Modeling concept
2

Modeling (n) “A modeling language is any artificial

language that can be used to express information or
knowledge or systems in a structure that is defined by a
consistent set of rules. The rules are used for interpretation
of the meaning of components in the structure.” Wikipedia “
Modeling has been an essential part of engineering, art and
construction for centuries.Complex software designs that
would be difficult for you to describe textually can readily
be conveyed through diagrams. Modeling provides three key
benefits: visualization, complexity management and clear
communication.” IBM
 Modeling concept
3

Some development managers wonder why modeling is

important at all. After all, the code should speak for
itself… Why add an extra layer of abstraction that we
have to maintain as the project progresses? The reason is
that there are a number of clear benefits that models
provide a development organization. They are enhanced
communication, better planning, reduced risk, and
reduced costs” Software Modeling Introduction – Borland
White Paper
 Modeling concept
4

They are the blueprints for systems.

A blueprint helps you plan an addition before you build
it; a model helps you plan a system before you build it.
It can help you be sure the design is sound, the
requirements have been met, and the system can withst
and even a hurricane of requirement changes.
 UML overview
5

 During the early 90s, there were around 50 O-O

methodologies among them:
 Rumbaugh’s Object Modeling Technique (OMT): Class and
Associations
 Shlaer-Mellor (Object-Oriented Analysis/Design (OOA/D),
 Booch Method : Categories and Subsystems
 Wirfs-Brock (Responsibility-Driven
Design/Class/Responsibility/Collaboration) RDD/CRC,
 Coad/Yourdon Methodology : Class, Object, Class-&-Object
 Jacobson Object-Oriented Software Engineering (OOSE)
Use case driven
 PROBLEMS
6

The existence of different OO methodologies

resulted in the following problems:
 Resulted in multitude interpretation of same
concepts
 Encouraged confusion
 Limited the progress of methods
 Methods influenced one another
 THE NEED FOR STANDARDIZATION
7

There are many methods and notations competing with

each other that users are distracted by the decisions they
need to make.
Existing methods are already converging since these
methods pick up ideas from other sources.
A single, common language is desirable because it can be
used for all development methods, used throughout the
project lifecycle, and used for different application
technologies.
 THE UNIFICATION
8
Based on the fact that differences between the various
methods were becoming smaller.
The method wars did not move OOT any longer.
Jim Rumbaugh and Grady Booch decided at the end of
1994 to unify their work within a single method: the
Unified Method.
 Definition of a universal language for O-O modeling
 Unified Method 0.8 Oct. 1995
 THE UNIFICATION…
9

 A year later they were joined by Ivar Jacobson

 Objective: Standardization of the o-o development
process
 The Unified Method was transformed into UML- the
Unified Modeling Language
 6/96 UML 0.9
 9/96 UML 0.91
 A consortium of partners created
10
 UML
11
 UML is a modeling language, a notation used to
express and document designs
(Language = Vocabulary + Grammar)
 Language for communication.
 UML unifies the notation of Booch, Rumbaugh (OMT)
and Jacobson(OOSE)
 UML proposes a standard for technical exchange of
models and designs.
 UML tells how to create and read well-formed models.
 UML…
12
It is a graphical language for
 Visualizing
 Specifying
 Constructing
 Documenting
Intended for software-intensive systems
 UML: a Language for Visualizing
13
A picture will always be worth a thousand words!
Provides a description of the software that non
programmers can understand (e. g. Use Case Diagrams)
 Provides the facility to construct the model by
constructing the model views
Inter - relating diagrams provide a mechanism for
detecting conflicts in the design and in user requirements
UML is a graphical language
 Well-defined syntax
 Well-understood semantics
 Interpretation or meaning of symbols
 UML: a Language for Specifying
14
Build models that are
Precise – clearly and accurately defined
Unambiguous – allowing of only one
interpretation.
Complete – capturing all relevant knowledge
Capture all important analysis, design and
implementation issues in developing and deploying a
software system
 UML: a Language for Constructing
15
Possible to “map” from UML to a programming
language
Supports forward engineering from the method to
an implementation
Supports reverse engineering from
implementation to its underlying model in UML
Results in “round-trip” engineering – forward or
backward
Supports direct execution (simulation) of models
 UML: a Language for Documenting
16
Artifacts in software development
• Requirements
• Architecture
• Design
• Source code
• Project plan
• Tests
• Prototypes
• Releases
• User manuals
Artifacts are deliverables
Artifacts also help control, measure, and communicate
during system development
 WHAT UML IS NOT
17

UML is not a method or methodology (Method =

Notation (e.g.,UML) + Process)

UML does not dictate a particular process

UML can be used to record the resulting domain
and design models, independent of the process
Choose an appropriate process for a particular
project, independent of the modeling language
 WHY USE UML
18

Standardized notation without sacrificing specialized

model data
Common language that can be used from product
conception to delivery, from system to detailed design
levels
Reduced learning curve across projects
Increased domain and design model reuse
Increased customer involvement/understanding of
problem translation to product solution
 The UML - Goals
19
 Provide a visual modeling language that is
 Ready to use
 Expressive
 Independent of particular programming language
 Independent of development process
 Extensible
 Core concepts can be extended or specialized by users

 Supportive of high-level concepts

 E.g. collaborations, frameworks, patterns, components
 Provide modeling language that
 Integrate best practices
 Encourages growth of OO tools market
 Building blocks of UML
20

 UML has three building blocks:

Things: the objects.
Relationships: the glue that holds things together.

Diagrams: categorized as either structure or

behavioral.
Conceptual Model of the UML
21
 Things (Entities)
22

There are four kinds of entities available:

 Structural things
 Behavioral things
 Collections/ Grouping things
 Annotational things
 Structural Things
23
The nouns of the UML models
These are mostly static parts of a model, representing
elements that are either: Conceptual or physical
 Seven types of structures
 Classes
 Interfaces

 Collaboration

 Use Cases

 Active Classes

 Components

 Nodes
 UML Structures: Class
24
UML class is a rectangle which contains the class
name the class attributes and operations.
 Graphical Notation:
 UML Structures: Interface
25
 Represents the public or a collection of operations of a class or
component.
 May not show the complete set of public operations
 Is attached to the class or component that realises the interface
 The term realizes is a mapping between the operations referred to
in the interface and the class or component where they are
actually implemented (see later).
 Is represented by a circle and the interface name.
 Graphical Notation:
 UML Structures: Use Case
26
 Represents a coherent unit of functionality to be supported by the
system.
 Used to specify the intended behavior (the “what”) of a system
 Describe externally visible functionality
 Identify high-level services provided by the system
 A description of a set of sequence of actions that a system
performs for a particular actor
 An actor may be:
 A human (hopefully!) user
 An external software system
 A Use Case is represented in UML as a title encapsulated in an
ellipse and an Actor is represented as a stick figure
 Graphical Notation:
 UML Structures: Collaboration
27
 Defines the classes and other software components required
to implement a use case
 A Realisation is the mapping between a Use Case and its
collaboration
 Represented in UML as a title encapsulated in a dashed line
ellipse
 Graphical Notation:
 UML Structures: Active Class
28
 A class whose objects own one or more processes or threads
and therefore can initiate control activity
 Graphically an active class is rendered just like a class, but
with heavy lines.
 Graphical Notation
 UML Structures: Component
29
 A component under UML has a similar meaning as a
software component: A replaceable part of the software
system that implements one or more interfaces.
 Under UML a component is represented as a title
encapsulated by a rectangle with tabs.
 Graphical Notation:
 UML Structures: Node
30
 An element that exists at run time and represents a
computational resource, generally having at least some
memory and, often processing capability
 Represented in UML as 3D cube labeled with the device’s
name
 Graphical Notation
 Behavioral Things
31
Verbs of a model, representing behavior over time and
space
Generally connected to classes, collaboration and
objects.
Behavioral things are:
 Interactions, and
 State machines
 Behavioral Things: Interaction
32
Set of messages exchanged among objects within a
context to accomplish a purpose
An interaction is composed of:
 The set of messages
 Action sequences (caused by invoking a message).

 Links or connections between objects (relationships between

objects)
(Interaction = Messages +Action Sequences + Links)
Points to object that receives the message
 Graphical Notation:
 Behavioral Things: State Machine
33
Represents a sequences of states connected by
transitions, which together describe the life cycle of
a single object or set of objects
(State Machine = States + Transitions + Events + Activities)
State is shown as rounded rectangle
Graphical Notation:
 Grouping (Collection) Things)
34
Things into which you can
 Decompose a model, or
 With which you can combine model elements
 Grouping thing:
 Package
 Grouping (Collection) Things: Package
35
Collection entities are a mechanism for subdividing the
software model into smaller sub - models.
 These sub - models are known as packages. Unlike
components, packages exist only in the design. The
implementation of the design will not (necessarily)
contain packages
Under UML, collection entities are represented as a
tabbed box containing the title of the package
 Graphical Notation:
 Annotational Things
36
Comments to describe, illuminate, or remark about
any element in a model
Annotational thing:
 Note
 Annotational Things : Note
37
An annotation can be attached to any element in a
software model.
Used for informal or formal text
Using a CASE tool an annotation will be a link to a text
file or word processor document.
Under UML an annotation is represented by a box with
a folded corner, containing the title of the annotation
Graphical Notation
 Relationships
38
Objects contribute to the behavior of a system
by collaborating with one another
 Collaboration is accomplished through
relationships
There are four kinds of entities available:
 Dependency
 Association
 Generalization
 Realization
 Relationships: Dependency
39
Semantic relationship between two things such
that a change in one thing (the “independent”
thing) may affect the semantics of another thing
(the “dependent” thing).
May have direction, may have a label.
 Dependency means one thing “uses” another.
Graphical Notation:
 Relationships: Association
40
Structural relationship that describes a set of
links; I.e. Relationships between objects
 May have direction, may include a label, and
often containing adornments such as multiplicity
and role names
Graphical notation:
 Relationships: Generalization
41
It is a relationship between a super-class and a
child class.
A child is substitutable for a parent.
Child shares the structure and behavior of
parent.
Graphical Notation:
 Relationships: Realization
42
One element specifies a “contract” that another
element must carry out
 Open headed arrow points from the “realizer” to the element
with the contract.
The element carrying out the “contract” is said
to realize the other element.
Graphical Notation:
 Diagrams: An Overview
43
Diagram is a collection of elements and their relationships.
Diagram is a projection (“shadow”) into a system
Kinds of Diagrams:
 Use Case Diagrams
 Class Diagrams
 Object Diagrams
 Interaction Diagrams
• Sequence Diagrams
• Collaboration Diagrams
 State Diagrams
 Activity Diagrams
 Component Diagrams
 Deployment Diagrams
 Use Case Diagram
44
Shows actors, use cases
and their relationships.
Can be used to provide an
overview of
 The functionality to be
supported by the system
 The actors interacting with
the system
 Relationships between
actors and use cases
 Addresses the visible
behaviors of a system
 Class Diagram
45
Shows the relationships
between:
 classes
 interfaces
 collaborations
 Easiest to understand and
most commonly used.
Class diagrams are a static
view of the system being
designed
 Object Diagram
46
 A class diagram describes classes and
class relationships. An object diagram
shows objects and associations
between objects
 It is a static snapshot of the system but
from an implementation perspective
 Each class will only appear once in a
class diagram
 In an object diagram each object will
only appear once but many of the objects
could be instances of the same class
 A class diagram shows class hierarchies
 An object diagram shows connections
between objects
 Interaction (Event Trace) Diagram
47

Two kinds:
 Sequence diagrams, and
 Collaboration diagrams
 Addresses the dynamic view of a system
Using Rational Rose it is possible to generate one
from the other
 Interaction Diagram: Sequence Diagram
48
Addresses time ordering of
messages: message centered
Time sequence is easier to
see in the sequence diagram,
read from top to bottom
Choose sequence diagram
when only the sequence of
operations needs to be
shown
 Interaction Diagram: Collaboration Diagram
49
Addresses organization of
objects that send and receive:
object centered.
Time sequence is shown by
numbering the message label
of the links between objects
 Choose collaboration
diagram when the objects
and their links facilitate
understanding the
interaction, and sequence of
time is not as important.
 State Diagram
50
Show all the possible states
that objects of the class can
have and which events cause
them to change.
Show how the object’s state
changes as a result of events
that are handled by the
object.
Good to use when a class has
complex lifecycle behavior
 Addresses event-ordered
behavior of objects
 Activity Diagram
51
Show the sequential flow of
activities
A combination of activities
and event flows
 Used to show the flow from
one activity to the next
 Encourage discovery of
parallel processes which
helps eliminate unnecessary
sequences in business
processes
 Addresses dynamic view of a
system
 Component Diagram
52
Component diagrams illustrate
the organizations and
dependencies among software
components (the physical
world)
 A component may be
 A source code component

 A run time components or

 An executable component
 Addresses implementation
view of the system
 Deployment Diagram
53
Shows run-time processing
nodes – system architecture.
 Highlight the physical
relationships among
software and hardware
components in the delivered
system
 Rules of the UML
54
The UML's building blocks can't simply be thrown together
in a random fashion.
 Like any language, the UML has a number of rules that
specify what a well formed model should look like
 Semantic rules for a well-formed model
 Names: What you can call things, relationships, and
diagrams
 Scope: The context that gives specific meaning to a name
 Visibility: How those names can be seen and used by others
 Integrity: How things properly and consistently relate to one
another
 Execution:What it means to run or simulate a dynamic
model
 Rules of the UML (cont.)
55
During development, we can build models that are:
 Elided: Certain elements are hidden to simplify the view
 Incomplete: Certain elements may be missing
 Inconsistent: The integrity of the model is not guaranteed
 These are all necessary if we are to use the models to
develop understanding
 Rules encourage – but do not force – addressing all the
important aspects of modeling a system over time
 Common Mechanisms in the UML
56
A building can be made simpler…by using certain
architectural patterns !!!
The same is true of the UML
 It is made simpler by the presence of FOUR
mechanisms:
 Specifications
 Adornments
 Common divisions
 Extensibility mechanisms
 Specifications
57
UML is more than a graphical notation.
Every part of the graphical notation there is a
specification that provides a textual statement of the
syntax and semantics of that building block
 Example
 Class icon might only show a small part of specifications.
 Specification provides a full a set of attributes, operations, full
signatures and behaviors.
 UML graphical notation to visualize a system
 UML’s specifications to state the system’s details
 Adornments
58
Optional details rendered as graphic or text.
 Example: Transaction is an abstract class, with two
public, one protected and one private operation
 Common Divisions
59
In modeling object-oriented systems, the world gets
divided in at least a couple of ways.
Abstraction vs. manifestation
 Intention vs. extension
 "Class" vs. "object"
 Class is an abstraction
 Object is a concrete manifestation of that abstraction
 Example:
 Customer is an abstraction,
 Jan is a particular customer,
 there is an (un-named) instance of customer and
 Elyse is a real thing (object).
 Extensibility mechanisms
60
UML provides a standard language for writing software;
 But… it is not possible for one closed language to be
sufficient to express all fine distinction in the models.
 So…UML is making possible to extend the language.
 Stereotypes:
 Allows to create new kinds of building blocks that are derived from
existing ones.
 Tagged values
 Allows to create new information in the elements specifications
 Constraints:
 Allows to add new rules or modify existing ones.
 Extensibility Mechanisms - Stereotypes
61
Stereotypes allow the controlled extension of meta model
classes by UML users.
Graphically rendered as
 Name enclosed in guillemets (<< >> )
 <stereotype>
 E.g., «metaclass»
 New icon (use color to accentuate) Internet
The new building block can have
 its own special properties through a set of tagged values
 its own semantics through constraints
 Extensibility Mechanisms - Tagged Values
62
A tagged value is a (name, value) pair that describes a
property of a model element.
Properties allow the extension of meta model element
attributes.
A tagged value modifies the semantics of the element to
which it relates.
 Rendered as a text string enclosed in braces { }
Placed below the name of another element
 Extensibility Mechanisms - Constraints
63
Extension of the semantics of a UML element
 Allows new or modified rules, i.e., conditions that must
hold true
Rendered in braces {}.
 Informally as free-form text, or
 Formally in UML’s Object Constraint Language (OCL):
 E.g., {self.wife.gender = female and self.husband.gender = male}
 Can be contained also in a note.
 End
64

?
Thank you!!