Chapter 2

OO Concepts and Modeling

with UML
=> Understanding OO modeling concepts in system/software
development using Unified Modeling Language
 2

Outline of topics
 Basic Concepts of Object Orientation
 Abstraction
 Hierarchy
 Encapsulation
 Modularity
 Polymorphism
 Class, Object, attribute methods(services)….
 Component, Interface…etc.
 Patterns
 OO Method Wars and the Unification Process
 UML- Unified Modeling Language
 Definition
 UML Structure( Building Blocks)
 UML- Architectural Views
 UML –Diagram types ( Structure, Behavior and Interaction)
 UML Diagram Examples
 A Modern Look at Modelling
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 3

1. OO Paradigm - Foundational Concepts( Object Model)

 Object Oriented Technology(OOT) is built up on a sound engineering
foundation, the conceptual framework of which is the– “Object Model”.
 The Object model encompasses the major elements (essential, a model
without these is not object oriented).
 Abstraction
 Encapsulation
 Modularity
 Hierarchy

 Object Model Minor Elements( useful but not essential)

 Typing
 Concurrency
 Persistence

 Other important concepts include

 Objects, Classes, Polymorphism, Message, Attributes, Methods
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 4

OO Concepts from a structured point of view

 OO concepts in the language of structured terminology

 Class is a software abstraction of an object, effectively, a template from which
objects are created.
 The definition of a class describes the layout, including both the data and the
functionality, of the objects to be created from it.
 Object is a software construct that mirrors a concept in the real-world, e.g., a
person, place, thing, event, concept, screen, or report
 If a class can be thought of as a table, an object can be thought of as a record occurrence
 Attribute. An attribute is equivalent to a data element in a record. Attribute
can be thought of as a local variable in the context of a programming
language.
 Method. A method can be thought of as either a function or procedure.
 Methods access and modify the attributes of an object.
 Better yet, methods can do a whole bunch of stuffs that has nothing to do with attributes.
( e.g. function that register students to a course.)
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 5

The UML Diagram Types ( will see more on this later)

 Behavior diagrams. This is a type of diagram that depicts behavioral

features of a system or business process.
 This includes activity, state machine, and use case diagrams as well as the four interaction
diagrams.
 Interaction diagrams. This is a subset of behavioral diagrams that
emphasize object interactions.
 This includes communication(collaboration), interaction overview, sequence, and timing
diagrams.
 Structure diagrams. This is a type of diagram that depicts the static
elements of a specification that are irrespective of time .
 This includes class, composite structure, component, deployment, object, and package
diagrams
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 6

OO Major Elements – Abstraction Cont’d…

Abstraction
 Denotes extracting essential characteristics of an object that distinguish it from all other kinds
of objects
 Same real-world object may have different abstractions depending on the problem domain ( e.g.
Abstraction of a person for a University System and a Police Investigation system are different).
Go look at the next slide.
 Segments in a system provide crisply defined conceptual boundaries, relative to the perspective
of the viewer.
 Binding the data with the code that manipulates it. It keeps the data and the code safe from
external interference.
 Abstraction meanings
 Object -> something in the world
 Class -> collection of objects
 Superclass -> collection of subclasses
 Operation -> methods( objects have methods, classes have operations)
 Attributes and relationships -> instance variables ( local variables).
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
Abstraction Cont’d… 7

 Abstraction focuses on the essential characteristics of

some object, relative to the perspective of the viewer.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 8

OO Major Elements - Encapsulation

Encapsulation
 Hiding the inner workings of object’s operations from the outside world and from other
objects
 Example : a Monitor and CPU
 Details can be hidden in classes
 For abstraction to work, implementations must be encapsulated
 This gives rise to information hiding:
 Programmers do not need to know all the details of a class
 Encapsulation deals with the issue of how you intend to modularize the features of a system.
 In the object-oriented world, you modularize systems into classes, which, in turn, are modularized into
methods and attributes.
 Encapsulation is the act of painting the box “black”. Don’t want to show how something is
defined.
 Segments in the system compartmentalize their subsystems, which provide structure and
behavior. Segments are black boxes to the other segments
 Encapsulation hides the details of the implementation of an object.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 9

OO Fundamental Concepts - Encapsulation/Hiding

The object encapsulates
both data and the logical
procedures required to
manipulate the data method
method
#1 #2
data

method
#6

method method
#5 #4

Achieves “information hiding”

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 10

OO Fundamental Concepts - Encapsulation/Hiding

 It is good engineering practice to encapsulate the state

of an object rather than expose it using operation
abstraction.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 11

Object Model- Major Elements …Modularity

Modularity
 The decomposition of a system into relatively equal sizes.
 The property of a system that has been decomposed into a
set of cohesive and loosely coupled modules
 Modularity packages abstractions into discrete units.
 Promotes understandability
 Segments are organized into a set of cohesive and loosely
coupled subsystems.
 Code can be constructed entirely of classes

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Object Model- Major Elements …Modularity 12

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 13

Object Model- Major Elements …Modularity Cont’d…

 Modules serve as the physical containers in which we

declare the classes and objects of our logical design
 In traditional structured design, modularization is
primarily concerned with the meaningful grouping of
subprograms, using the criteria of coupling and
cohesion.
 In object-oriented design, the problem is subtly
different: The task is to decide where to physically
package the classes and objects, which are distinctly
different from subprograms.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 14

OO Major Elements - Hierarchy

Hierarchy
 Is a ranking or ordering of abstractions
 Abstractions form a hierarchy.
 Segments in a system exhibit a ranking or ordering of abstractions.

 Inheritance
 The mechanism where features in a hierarchy inherit from superclasses to subclasses
 “is a”
 Aggregation
 The process of creating a new object from two or more other objects.
 “part of ”
 A car is an aggregation of engine, wheel, body...

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 OO Major Elements - Inheritance Hierarchy - An 15

Example

 Inheritance
 Simply stated, inheritance is a relationship among classes wherein one class shares the structure
and/or behavior defined in one (single inheritance) or more (multiple inheritance) other classes
 The implicit possession by all subclasses of features defined in its super classes

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 16
Class Hierarchy
furniture (superclass)

table chair desk "chable"

subclasses of the
furniture superclass

instances of chair

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 17

Single Inheritance

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Multiple Inheritance - not supported directly by many 18

programming languages( but through interfaces)

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 19

Minor elements of the Object Model

 Read about minor elements of the Object Model

 Types ( classes?)
 Concurrency

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 20

OO Important Concepts: Other Central Concepts

 Classes
 Attributes
 Objects
 Polymorphism
 Message and Methods

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 21

Classes and Objects

 Object
 A chunk of structured data in a running software system. An object has state, exhibits some well-
defined behavior, and has a unique identity.
 No two objects share the same memory space.
 Has properties
 Represent its state
 Has behavior
 How it acts and reacts
 May simulate the behavior of an object in the real world
 Has identity
 Unique features that distinguish an object from other similar objects.

 Real-world objects are not the only kinds of objects that are of interest to us
during software development.
 inventions of the design process whose collaborations with other such objects serve as the
mechanisms that provide some higher-level behavior.
 Jacobson et al. define control objects (Controller objects) as “the ones that unite courses of events and
thus will carry on communication with other objects”.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 22

Classes and Objects Cont’d…

 The structure and behavior of similar objects are defined in their common class. The
terms instance and object are interchangeable.
 The state of an object encompasses all of the static properties of the object plus the
current (dynamic) values of each of these properties.
 The state of an object represents the cumulative results of its behavior. i.e. operations can be used in altering
the object’s state.
 The Behavior- defines how an object acts and reacts, in terms of its state changes and
message passing.
 Objects are acted on and themselves act on other objects
 An object’s behavior represents its outwardly visible activity.
 The terms operation and message are interchangeable.
 An operation denotes a service that a class offers to its clients
 The Identity is that property of an object which distinguishes it from all other objects

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 23

Classes and Objects Cont’d…

 A client (calling object) typically performs five kinds

of operations on an object
 Three most common kinds of operations are the following:
 Modifier: an operation that alters the state of an object
 Selector: an operation that accesses the state of an object but does not alter the
state
 Iterator: an operation that permits all parts of an object to be accessed in some
well-defined order
 Two other kinds of operations are also common; they represent the
infrastructure necessary to create and destroy instances of a class.
 Constructor: an operation that creates an object and/or initializes its state ■
Destructor: an operation that frees the state of an object and/or destroys the
object itself

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Classes and Objects Cont’d…

Classes

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling 24

 25

Objects

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 26

Class????

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 27

Classes
 A class:
 A unit of abstraction in an object oriented (OO) program
 Starts with definition of concepts such as
 template
 generalized description
 pattern
 “blueprint” ... describing a collection of similar items.
 In the context of object-oriented analysis and design, Class is define as follows:
A class is a set of objects that share a common structure, common behavior, and common
semantics.
 A class represents a set of objects( instances) that share a common structure and a common
behavior
 A kind of software module
 Describes its instances’ structure (properties)
 Contains methods to implement their behavior

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 28

What isn’t a class?

 An object is not a class. Objects that share no common
structure and behavior cannot be grouped in a class
because, by definition, they are unrelated except by their
general nature as objects.
 Whereas an individual object is a concrete entity that
performs some role in the overall system, the class captures
the structure and behavior common to all related objects.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 29

Interface and Class Implementation

 Programming is largely a matter of “contracting”:
 The various functions of a larger problem are decomposed into smaller problems by subcontracting them
to different elements of the design.
 Nowhere is this idea more evident than in the design of classes

 Like a class, an interface can have methods and variables, but the
methods declared in interface are by default abstract (only method
signature, they have no “body”).  
 Interfaces specify what a class must do and not how it does. It is the
blueprint of the class.
 A class serves as a sort of a binding contract between an abstraction and all of
its clients.
 These contract decisions are captured in the interface of a class and a strongly typed programming
language can detect violations of this contract during compilation of the class.
 Classes implement one or more interfaces
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 30

A real world example: Interface and Classes

 Let’s consider the example of vehicles like bicycle, car,

motorbike………,
 They have common functionalities. So we make an interface and put
all these common functionalities in the interface.

 Then, let Bicycle, Bike, Car ….etc. implement all these

functionalities(what) in their own class in their own
way(how).

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Interface and Class Implementation example - java
class Bicycle implements Vehicle

interface Vehicle { {
int speed;
int gear;

//all are the abstract methods. // to change gear

@Override
public void changeGear(int newGear){

void changeGear(int a); }

gear = newGear;

// to increase speed
void speedUp(int a); @Override
public void speedUp(int increment){
speed = speed + increment;
void applyBrakes(int a); }
// to decrease speed
@Override
} public void applyBrakes(int decrement){
speed = speed - decrement;
}
public void printStates() {
System.out.println("speed: " + speed
+ " gear: " + gear);
}
}
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling 31
 32

Methods (Operations, Services)

An executable procedure that is encapsulated in

a class and is designed to operate on one or more
data attributes that are defined as part of the
class.
A method is invoked
via message passing.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 33

Messages
sender object

attributes:

receiver object

attributes:
operations:

operations:

message:
[sender, return value(s)]

message: [receiver, operation, parameters]

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 34

Methods, Operations and Polymorphism

 Operation
 A higher-level procedural abstraction ( than a method) that specifies a type of behaviour
 Independent of any code which implements that behaviour
 E.g. calculating area (in general) usually through interfaces.( or abstract classes)

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 35

Methods, Operations and Polymorphism

 Method
 A procedural abstraction used to implement the behaviour of a class.
 Several different classes can have methods with the same name
 They implement the same abstract operation in ways suitable to each class
 E.g. calculating area of a rectangle is done differently from that of a circle
 Using Interface Implementation that we have discussed already.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 36

Polymorphism
 The mechanism by which several methods can have the same name and implement
the same abstract operation.
 For example as in Interfaces?

 A property of object oriented software by which an abstract operation may be

performed in different ways in different classes.
 Requires that there be multiple methods of the same name
 The choice of which one to execute depends on the object that is in a variable.
 Reduces the need for programmers to code many if-else or switch statements

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 37

Persistence
 Abstract and Concrete Classes
 Abstract Classes cannot be instantiated while concrete class can be
 Persistence focuses on the issue of how to make objects available
for future use.
 To make an object persistent, you must save the values of its attributes to
permanent storage (such as a relational database or a file) as well as any
information needed to maintain the relationships (aggregation,
inheritance, and association) with which it is involved.
 In addition to saving objects, persistence is also concerned with their
retrieval and deletion.
 Business/domain classes are usually persistent.
 Need to store both attributes and associations
 User-interface classes are usually transitory

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 38

Interfaces ( Recap)

 As we have seen previously, an interface is the

definition of a collection of one or more methods, and
zero or more attributes.
 Interfaces ideally define a cohesive set of behaviors.
 Interfaces are implemented(realized) by classes and
components.
 To implement an interface, a class or component must
include the methods defined by the interface.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 39

Components

 A component is a modular, extensible unit, with independent

deployment that has contractually specified interface(s) and explicitly
defined dependencies, if any.
 A component represents a reusable piece of software that provides some
meaningful aggregate of functionality.
 At the lowest level, a component is a cluster of classes that are themselves cohesive but are
loosely coupled relative to other cluster
 Ideally, components should be modular, extensible, and open.
 Modularity implies a component contains everything it needs to ful fill its responsibilities;
 Extensibility implies a component can be enhanced to ful fill more responsibilities than it was originally
intended to, and
 Open implies it can operate on several platforms and interact with other components through a single
programming interface.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 40

Pattern

 A pattern is a solution to a common problem taking

relevant forces into account, effectively supporting the
reuse of proven techniques and approaches of other
developers.
 Several flavors of patterns exist (Addressed in the
respective chapters)
 Analysis patterns: describe a solution to common problems found in
the analysis/business domain analsysis of an application.
 Design patterns: describe a solution to common problems found in
the design of systems
 Process patterns: address software process model related issues.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
2. OO Modelling Methodologies- The Method-Wars and 41

Unification

 Between ’89 and ’94, OO methods increased from 10 to 50 among

them:
 Rumbaugh’s Object Modeling Technique (OMT): Class and Associations
 Shlaer-Mellor (Object-Oriented Analysis/Design (OOA/D),
 Booch Method : Categories and Subsystems decomposition
 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

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 42

Problems associated with many methods

 The existence of different OO methodologies resulted in the following problems:
 Multitude interpretation of same/similar concepts
 Encouraged confusion
 Limited the progress of methods
 Methods influenced one another

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 43

The need for standardization

 There are so 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.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 44

The Unification
 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

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 45

THE UNIFICATION…
 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
 June 1996 UML 0.9
 Sept 1996 UML 0.91
 OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) an annual ACM
research conference was created in 1996.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 46

UML- Unification History

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 47
History of OO Modelling Methodology Evolution

04/09/2023
Chapter 2 Basic OO Concepts and UML Modeling
 48

UML- Version History

Year Version
2017: UML 2.5
2011: UML 2.4
2010: UML 2.3
2009: UML 2.2
2007: UML 2.1
2003: UML 2.0
2001: UML 1.4
1999: UML 1.3

1997: UML 1.0, 1.1

1996: UML 0.9 & 0.91
1995: Unified Method 0.8

Booch ‘93 OMT - 2

Other methods

Booch ‘91
OMT - 1
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 49

3. UML- The Unified Modeling Language

 UML → “Unified Modeling Language”

Language: expresses idea, not a methodology

Modeling: Describing a software system at a high level of

abstraction

Unified: UML has become a industry standard

Object Management Group (OMG): www.omg.org

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 50

UML Cont’d…
Aims at
Unifying design languages
Being a general purpose modeling language

Lingua franca of modeling

Offers vocabulary and rules for communication
Not a process but a language
Combine the best of the best from
Data Modeling (Entity Relationship Diagrams);
Business Modeling (work flow);
Object Modeling ( structure)
Component Modeling (development and reuse)
A Language for visualizing, specifying, constructing, and documenting models
Different diagrams describe various facets of the model
The de facto industry standard for software modeling
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 51

Conceptual, Logical and Physical Models

 The models of your system may present various levels of
detail as your system development progresses and matures
over time.
 The conceptual model captures the system in terms of the domain entities
that exist (or will exist) and their association with other such entities of
your system.
 The logical view of a system takes the concepts created in the conceptual
model and establishes the existence and meaning of the key abstractions
and mechanisms that will determine the system’s architecture and overall
design. Describe sw abstractions or components with specifications and
interfaces, but no commitment to a particular language implementation.
 The physical model of a system describes the concrete software and
hardware composition of the system’s implementation- in a technology
specific manner.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 52

The 13 UML(2.5) Diagrams

Structure diagrams
1. Class diagram
2. Composite structure diagram (*)
3. Component diagram
4. Deployment diagram
5. Object diagram
6. Package diagram
Behavior diagrams
7. Use-case diagram
8. State machine diagram
9. Activity diagram
Interaction diagrams
10. Sequence diagram
11. Communication diagram
12. Interaction overview diagram (*)
13. Timing diagram (*)
(*) not existing in UML 1.x, added in UML 2.0
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 53

UML Diagrams -Clusters

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

An Overview of UML Diagrams showing how developing one leads to the other 54

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 55

What UML IS

 It is a graphical language for

 Visualizing
 Specifying – building models that are precise, unambiguous, and
complete
 Constructing – possible to map from a model in the UML to a
programming language
 Documenting

 Intended for use in software-intensive systems

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 56

UML- Purposes
 Visualizing
 explicit model facilitates communication
 some structures transcend (pass or more) what can be represented in programming language
 each symbol has well-defined semantics behind it.

 Specifying
 The UML addresses the specification of all important analysis, design, and implementation decisions.

 Constructing
 Forward engineering: generation of code from model into programming language
 Reverse engineering: reconstructing model from implementation
 Round-trip engineering: going both ways.

 Documenting
 Produce consistent models of a system for reference and communication.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 57

Three ways people apply UML are ...

 UML as sketch
 Informal and incomplete diagrams (often hand sketched on whiteboards) created to
explore difficult parts of the problem or solution space
 Agile modeling emphasizes UML as sketch.

 UML as blueprint
 relatively detailed design diagrams used either for reverse engineering to visualize and
better understand existing code,
 or for forward engineering to guide for code generation, either manually or automatically
with a tool.

 UML as a programming language

 Complete executable specification of a software system in UML. (xUML executable
UML)

Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

 58

What UML is Not

 UML is not a method or methodology (Method =
Notation (e.g. UML) + Process)
 Methodology~ the study of methods
 UML does not dictate a particular software process
 UML can be used to record the resulting domain and
design models, independent of the software process
 A project can choose an appropriate process for a
particular project, independent of the modeling
language

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 59

The UML Structure

UML

Common Architecture
Building blocks mechanisms
(Patterns)
 Architectural Views
 Building blocks  Common mechanisms  use-case view
 things  specifications  logical view
 relationships
 Diagrams
 Adornments/decoration  process view
 common divisions  implementation view
 extensibility mechanisms  deployment view

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 60

RULES OF UML
 UML’s building blocks should be put together to develop a well-formed model.-A model
that is semantically self-consistent and is in harmony with all its related models.

The UML has semantic rules for

 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.
 Avoid models that are
Elided — certain elements are hidden for simplicity.
Incomplete — certain elements may be missing.
Inconsistent — no guarantee of integrity.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 61

UML- Structure –Building Blocks

Things - important modeling concepts

Relationships - tying individual things together

Diagrams - grouping interrelated collections of things

and relationships

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 62

UML- Structure Things

 Things
 Structural — nouns/static parts of UML models (irrespective of time).

 Behavioral — verbs/dynamic parts of UML models.

 Grouping — organizational parts of UML models.

 Annotational — explanatory parts of UML models.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Structural Things in UML 63

 Nouns.
 Conceptual or physical elements.

Active Class Component Interface Node

Class (processes/threads) (replaceable part, (collection of externally (computational
realizes interfaces) Visible ops) resource at run-time,
Student Event Mgr processing power
std_id thread with memory)
grade time Course.cpp
changeLevel( ) Start IGrade
setGrade( ) suspend( ) <<interface>> UnivWebServer
getGrade( ) stop( ) IGrade

setGrade()
getGrade()

Register Manage Course

for Courses Registration

Use Case Collaboration

(a system service (chain of responsibility
-sequence of shared by a web of interacting objects,
Interactions with an actor) structural and behavioral)
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 64

Behavioral Things in UML

 Verbs.
 Dynamic parts of UML models: “behavior over time”
 Usually connected to structural things.

Two primary kinds of behavioral things:

 Interaction
a set of objects exchanging messages, to accomplish a specific purpose.

harry: ask-for-an-A katie:

Student Professor
name = “Harry Kid” name = “Katie Holmes”

 State Machine
specifies the sequence of states an object
or
an interaction goes through during its
lifetime in response to events.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Grouping Things in UML: Packages 65

- For organizing elements (structural/behavioral) into groups.

- Purely conceptual; only exists at development time.
- Can be nested.
- Variations of packages are: Frameworks, models, & subsystems.

University Administration

Course Manager Course Manager

Student Admission

-Student
+Department

Annotational Things in UML: Note

- Explanatory/Comment parts of UML models - usually called adornments(Common mechanisms)
- Expressed in informal or formal text.

operation()
flexible {for all g in children
drop-out dates }
g.operation()

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 66

Basic building blocks of UML Cont’d… - Relationships

Student University
attends
1. Associations
Structural relationship that describes a set of links, a link being a connection between objects.
(UML2.0: The semantic relationship between two or more classifiers that involves connections among their instances .)
variants: aggregation & composition
Student Person
2. Generalization
A specialized element (the child) is more specific than the generalized element.

Student
3. Realization IGrade
One element guarantees to carry out what is expected by the other element.
(e.g, interfaces and classes/components; use cases and collaborations)

harry: Student Student

<<instanceOf>>
4. Dependency
A change to one thing (independent) may affect the semantics of the other thing (dependent).
04/09/2023 (direction, label are optional) Chapter 2 Basic OO Concepts and UML Modeling
 67

Basic building blocks of UML Cont’d… - Diagram

 A connected graph: Vertices are Things; Arcs are
relationships/behaviors.
Interaction Diagrams
Structural Diagrams
 Sequence
 Class;
Behavioral Diagrams  Communication(
 Object
 Use case Collaboration)
 Component  Interaction
 Statechart
 Deployment Overview
 Activity
 Composite  Timing
Structure
 Package

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 68

Common Mechanisms in UML

Systems development using UML can be made simpler by the presence
of common mechanisms:
1. Specifications – Behind every part of UML’s graphical notation there is a
specification that provides a textual statement of the syntax and semantics of
that building block.
 Specification are used to state the system’s details.
 Provides a semantic backplane that contain all the parts of all the models of
the system.
 Example – a class diagram
2. Adornments( decorations) – Most elements in the UML have a unique and
direct graphical notation that provides a visual representation of the most
important aspects of the element.
 Every element in the UML’s notation starts with a basic symbol, on which we
can be add a variety of adornments.
 Examples: Multiplicity, Role names on association lines

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 69

Common Mechanisms in UML Cont’d…

3. Common divisions
Class and Object

4. Extensibility mechanisms
UML can be extended using the following mechanisms
 Stereotypes: Extends the vocabulary of UML, allowing you to create new kinds of building blocks that are
derived from existing ones but that are specific to your problem.
 Stereotypes (<< >>) can be used to extend the UML notational elements
 Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components
 Examples:
 Class stereotypes: boundary, control, entity, utility, exception
 Inheritance stereotypes: uses and extends
 Component stereotypes: subsystem

 Constraints: Extends the semantics of a UML building block, allowing you to add new rules or modify
existing ones.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 70

Architectural View
Architecture is a set of significant decisions about
 The organization of a software system
 The selection of the structural elements and their interfaces
by which the system is composed
 Their behavior, as specified in the collaborations among those
elements
 The composition of these structural and behavioral elements
into progressively larger subsystems
 The architectural style(pattern) that guide this organization of
components: the static and dynamic elements and their
interfaces, their collaborations, and their composition.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 71

Architectural View
 Software architecture is not only concerned with architecture and
behavior, but also with usage, functionality, performance, resilience
(elasticity), reuse, comprehensibility, economic and technology
constraints and trade-offs, and aesthetic concerns.
 Architecture of a system can be described by a view from a particular
viewpoint.
 A view is simply a subset of UML modeling constructs that represent
one aspect of the system
 UML is used for visualizing, specifying, constructing, and documenting
with emphasis on system architectures (things in the system and
relationships among the things) from five different views ( 4+1 view)
 Each of the views involve Structural and behavioural models.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
Architectural Views (Representing Architecture: The 4+1 View Model 72

Logical View Implementation

View
Functional requirements Programmers
Analysts/ End-user
Functionality Software management
Designers
Structure Use-Case
(scenario) View
Process View Deployment
View
System Integrators System Engineering
Performance System topology
Scalability, Concurrency, Delivery, installation
Throughput, Parallelism… Communication

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 73

UML –Viewpoints

Use case view

 Focuses on scenarios executed by human users and
external systems
 Expresses what the new system will do without
specifying how it will do it
 End-product: use case diagrams

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 74

UML - Viewpoints Cont’d…

 Logical/Design views
 Supports the functional requirements of the system
 Focuses on the things (classes, interfaces and collaborations) that
form the vocabulary of the problem that the system is trying to solve
and the elements of the solution to that problem.
 The view encompasses the static and dynamic aspects of the system
 End-product: class and object diagram (static),
sequence/collaboration, activity and statechart diagram (dynamic)

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 75

UML - Viewpoints Cont’d…

 Process view
 Focuses on the aspects of the system that involves timing and the
flow of program control.
 Addresses the performance, scalability and throughput of the system
 End product: Activity diagrams

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 76

UML -Viewpoints Cont’d…

 Implementation view
 Encompasses the components and files that are used to assemble and
release the physical system
 End-product: component diagrams
 Deployment view
 Encompasses the nodes that form the system’s hardware topology on
which the system components executes
 End-product: deployment diagram

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 Architectural Views with UML - Summary 77

Use Case View

 Use Case Analysis is a technique to capture business process from user’s perspective.
 Encompasses the behavior as seen by users, analysts and testers.
 Specifies forces that shape the architecture.
 Static aspects in use case diagrams; Dynamic aspects in interaction (statechart and activity) diagrams.

Design View
 Encompasses classes, interfaces, and collaborations that define the vocabulary of a system.
 Supports functional requirements of the system.
 Static aspects in class and object diagrams; Dynamic aspects in interaction (Collaboration/Communication diagram) diagrams.

Process View
 Encompasses the threads and processes defining concurrency and synchronization.
 Addresses performance, scalability, and throughput.
 Static and dynamic aspects captured as in design view; emphasis on active classes.

Implementation View
 Encompasses components and files used to assemble and release a physical system.
 Addresses configuration management.
 Static aspects in component diagrams.

Deployment View
 Encompasses the nodes that form the system hardware topology.
 Addresses distribution, delivery, and installation.
 Static aspects in deployment diagrams;
Chapter 2 Basic OO Concepts and UML
04/09/2023
Modeling
 78

Outline of a Software Architecture Document

 What outline is best for documenting Software

Architecture ??

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 79

UML- All Notations?

 The fact that the UML is a detailed specification does not mean that
every aspect of it must be used at all time.
 In fact, a proper subset of this notation is sufficient to express the
semantics of a large percentage of analysis and design issues

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 80

Agile Modeling Principles and Values (Ambler, 2002)

 Adopting an agile method does not mean avoiding any modeling.

 The purpose of modeling and models is primarily to support
understanding and communication, not documentation.
 Don’t model or apply the UML to all or most of the software
design. Apply UML for the smaller percentage of unusual,
difficult, tricky parts of design space.
 Use the simplest tool possible. “Prefer” sketching UML on
whiteboards, and capturing the diagrams with a digital camera.
 Don’t model alone, model in pairs (or triads) at the whiteboard, in
the awareness that the purpose is to discover, understand, and
share that understanding.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 81

Agile Modeling Principles and Values Cont’d…

 Create models in parallel: Dynamic-view vs. static view.

 Use “good enough” simple notation while sketching
with a pen on whiteboards. Exact UML details aren’t
important.
 Know that all models will be inaccurate, and the final
code or design different – than the model. Only tested
code demonstrates the true design.
 Developers themselves should do the OO design
modeling, for themselves.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
How to use UML diagrams to design software 82

system

Types of UML Diagrams:

Use Case Diagram
Class Diagram
Sequence Diagram
Collaboration Diagram
State Diagram
This is only a subset of diagrams … but are the most widely used

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Five diagram types that could effectively 83

represent the essentials of a system

1. Activity diagrams, which show the activities involved in a

process or in data processing.
2. Use case diagrams, which show the interactions between a
system and its environment.
3. Sequence diagrams, which show interactions between actors
and the system and between system components.
4. Class diagrams, which show the object classes in the system
and the associations between these classes.
5. State diagrams, which show how the system reacts to
internal and external events.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 84

Use-Case Diagrams
 A use-case diagram is a set of use cases
 A use case is a model of the interaction between
External users of a software product (actors) and
The software product itself
More precisely, an actor is a user playing a specific role
 Use case describes a set of user scenarios
 Used in capturing user requirements
 Also acts as contract between end user and software developers

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Use-Case Diagrams - Components
System

Boundary Use Case

Actor
Library System

Borrow Employee
Client

Order Title

Fine Remittance

Supervisor

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling 85

Use-Case Diagrams
 Actors: A role that a user plays with respect to the system, including human users and
other systems. e.g., inanimate physical objects (e.g. robot); an external system that needs
some information from the current system.

 Use case: A set of scenarios that describing an interaction between a user and a
system, including alternatives.

 System boundary: rectangle diagram representing the boundary between the actors
and the system.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling 86

 Use-Case Diagrams 87

 An actor is someone or some thing that must interact with the

system under development

The “UTD” wants to computerize its registration system

 The Registrar sets up the curriculum for a semester

Registrar
 Students select 3 core courses and 2 electives
Student
 Once a student registers for a semester, the billing system is
notified so the student may be billed for the semester
Billing System
 Students may use the system to add/drop courses
for a period of time after registration

 Professors use the system to set their preferred course offerings

and receive their course offering rosters after students register

 Users of the registration system are assigned passwords Professor

which are used at logon validation
04/09/2023
Chapter 2 Basic OO Concepts and UML Modeling
Use case Diagram 88

 A use case is a sequence of interactions between an actor and the system

Maintain
The UTD wants to computerize its registration system Curriculum

 The Registrar sets up the curriculum for a semester Register

for Courses
Registrar
 Students select 3 core courses and 2 electives
Student
 Once a student registers for a semester, the billing system is
notified so the student may be billed for the semester
Billing System
 Students may use the system to add/drop courses
for a period of time after registration
Request
Course Roster
 Professors use the system to set their preferred course offerings
and receive their course offering rosters after students register
Set
 Users of the registration system are assigned passwords Professor Course Offerings
which are used at logon validation

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 89

Use-Case Diagrams
 Association:
Communication between an actor and a use case; Represented by
a solid line.

 Generalization: relationship between one general use case and a

special use case (used for defining special alternatives)
Represented by a line with a triangular arrow head towards the
parent use case.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 90

Use-Case Diagrams

Include: A dotted line labeled <<include>> beginning at base use case and ending with an arrows
pointing to the included use case. The include relationship occurs when a chunk of behavior
is similar across more than one use case. Use “include” in stead of copying the description of
that behavior in multiple places.
<<include>>

Extend: A dotted line labeled <<extend>> with an arrow toward the base case. The
extending use case may add behavior to the base use case. The base use case
declares “extension points”.

<<extend>>

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 91

Use-Case Diagrams

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 92

Use-Case Diagrams
 Both Make Appointment and
Request Medication include
Check Patient Record as a
subtask (include)

 The extension point is written

inside the base use case Pay
bill; the extending class Defer
payment adds the behavior of
this extension point. (extend)

 Pay Bill is a parent use case

and Bill Insurance is the child
use case. (generalization)

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 93

Class Diagram
 A class diagram depicts classes and their
interrelationships
 Used for describing structure and behavior in the
use cases
 Provide a conceptual model of the system in terms
of entities and their relationships
 Used for requirement capture, end-user interaction
 Detailed class diagrams are used for developers
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 94

Class diagram
 Each class is represented by a rectangle subdivided into
three compartments
Name
Attributes
Operations
 Modifiers are used to indicate visibility of attributes and
operations.
‘+’ is used to denote Public visibility (everyone)
‘#’ is used to denote Protected visibility (friends and derived)
‘-’ is used to denote Private visibility (no one)
 By default, attributes are hidden and operations are visible.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

Class diagram
95

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 96

OO Relationships
 There are two kinds of Relationships
 Generalization (parent-child relationship)
 Association (student enrolls in course) – weak relationship.
 Associations can be further classified as
 Aggregation
 An aggregation expresses a part-of relationship between a component object and an
aggregate object. It is a stronger form of an association relationship (with the added
“part-of” semantics) and is represented with a hollow diamond at the aggregate end
( analysis decision)
 Composition
 A whole/part relationship where one object is composed of one or more other objects,
each of which is considered a part of the whole. This relationship is a strong form of
aggregation in that the lifetimes of the whole and its parts are dependent(physical
design issue).
 The choice of aggregation is usually an analysis or architectural design decision; the
choice of composition (physical containment) is usually a detailed, tactical issue.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 OO Relationships: Generalization
97

Example:
Supertype Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
-Inheritance is a required feature of object orientation
-Generalization expresses a parent/child relationship among related classes.
-Used for abstracting details in several layers

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 98

OO Relationships: Association
 Represent relationship between instances of
classes
 Student enrolls in a course
 Courses have students
 Courses have exams
 Etc.

 Association has two ends

 Role names (e.g. enrolls)
 Multiplicity (e.g. One course can have many students)
 Navigability (unidirectional, bidirectional)

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 99

Association: Multiplicity and Roles

student
1 *
University Person

0..1 *
employer teacher

Multiplicity
Symbol Meaning Role
1 One and only one Role
0..1 Zero or one
“A given university groups many
M..N From M to N (natural language) people; some act as students, others
* From zero to any positive integer as teachers. A given student belongs
0..* From zero to any positive integer to a single university; a given teacher
1..* From one to any positive integer may or may not be working for the
university at a particular time.”
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 100

Class Diagram - an Example

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 101

UML –Class Diagram –an Example

CurriculumManager

ScheduleAlgorithm 1
RegistrationForm

0..*
1 RegistrationManager 0..*
addStudent(student, course)
1 Course
name
0..* numberCredits
User
name Student
open()
addStudent(StudentInfo)
major

1
1..10
Professor 1..*
4 CourseOffering
tenureStatus
1 location
0..4
open()
addStudent(StudentInfo)

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 102

Diagrams in UML – Object Diagrams

harry: Student ooad06S: Course
 Shows a set of objects and their relationships. name = “OOAD”
 As a static snapshot. name = “Harry Kid”

katie: Professor ooado: CourseOffering

name = “Katie Holmes” location = “Fujitsu”

Anything wrong? Lookback on the class diagram in the previous slide!

arch06F: Course
tom: Student
name = “Sw Architecture”
harry1: Professor
name = “Tom Cruise”
name = “Harry William”

alg06F: Course
surie: Professor arch: CourseOffering name = “Adv Algorithms”
name = “Surie Holmes” location = “UTD”

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 103

Aggregation vs. Composition

 Aggregations - is a stronger form of Association
 May form a "part of" type of association, but may
not be essential to it. They may also exist
independent of the aggregate. e.g. Apples may
exist independent of the bag.
 Composition is a strong form of Aggregation
 components have only one owner
 components cannot exist independent of their owner
 components live or die with their owner
 e.g. Each car has an engine that can not be shared with other cars.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 104

OO Relationships: Aggregation

Container Class
Aggregation:
Class C expresses a relationship among instances of
related classes. It is a specific kind of Container-
AGGREGATION
Containee relationship.

Class E1 Class E2 Express a more informal relationship than

composition expresses.

Containee Classes Aggregation is appropriate when Container and

Containees have no special access privileges to
each other.
Example
Bag

Apples Milk

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

OO Relationships: Composition
105

Whole Class
Class W Association
is a link between classes that indicates that there is
a relationship between these classes.
Model denotes some semantic dependency among
Class P1 Class P2 otherwise unrelated classes. Very weak
relationship.
Composition
Part Classes Models the “part–whole” relationship but, in addition,
Every part may belong to only one whole, and If the
Example whole is deleted, so are the parts ( physical
containment)- existence dependency.

Example:
A number of different chess boards: Each square belongs to
only one board. If a chess board is thrown away, all 64
squares on that board go as well.
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 106

Good Practice: CRC Card

Class Responsibility Collaborator

 Easy to describe how classes work by moving cards around; allows to quickly consider
alternatives.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 107

Interaction Diagrams
 Show how objects interact with one another
 UML supports two types of interaction diagrams
Sequence diagrams
Collaboration diagrams

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 108

Sequence Diagrams- Message Acctions

 There are 5 kinds of actions that the UML explicitly

supports: -
 Call and Return
 Create and Destroy
 Send
 109

Sequence--Diagram Call Action

 Call action
 A call action invokes an operation on an object
 It is synchronous, meaning that
 the sender assumes that the receiver is ready to accept the message,
 and the sender waits for a response from the receiver before proceeding
 The UML represents a call action as an arrow from the calling object to the receiving object

: Class Object: Class

A call action that involves
action name two objects

A lifeline
action name
A call action from an object
to itself
 110

Sequence Diagram – Return Value

 Return action
 A return action is the return of a value to the caller, in response to a call action
 The UML represents a return action as a dashed arrow from the object
returning the value to the object receiving the value

: Class Object: Class

return value
 111

Example :- Call and Return action

: Customer : CustomerReview
assignRating()

computeAvgRating()

average rating
 112

Sequence Diagram- Alternate Create Action

 Create action
 A create action creates an object
 It tells a class to create an instance of itself
 In the UML, create action is represented as an arrow with the stereotype <<create>> from the
object that invokes the create action to the created object

Object: Class : Class Object: Class

<<create>> <<create>>
: Class

Alternate Create Action notation

 113

Sequence Diagram
 Destroy action
 A destroy action destroys an object
 It tells an object to destroy itself
 An object can perform a destroy action on another object, or on itself
 In the UML, a destroy action is represented as an arrow with the
stereotype <<destroy>> from the object that invokes the action to the
destroyed object. A large X is also added at the end of the destroy
arrow to denote that the object’s lifeline has been terminated
Object: Class : Class

<<destroy>>
X
 114

Sequence Diagram - Send Action

 Send action
 A send action sends a signal to an object
 A signal is an asynchronous communication between objects
 One object “throws” a signal to another object that “catches” the signal
 The sender of the signal does not expect a response from the receiver (unlike the sender of a call
action)
 Exceptions are the most common type of signals
 In the UML, a send action is represented as an arrow with a half arrowhead at the
lifeline of the receiving object

: Class Object: Class

action name
 115

Sequence Diagram- Example (make a phone call)

Caller Phone Recipient

Picks up

Dial tone

Dial

Ring notification Ring

Picks up

Hello

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 116

Sequence Diagram: Object interaction

Self-Call: A message that an A B

Object sends to itself.
Synchronous
Condition: indicates when a message is
sent. The message is sent only if the Asynchronous
condition is true.
Transmission
delayed

[condition] remove()
Condition
*[for each] remove()
Iteration

Self-Call
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 117

Sequence Diagrams – Object Life Spans

 Creation
 Create message A
 Object life starts at that point
 Activation Create
B
 Symbolized by rectangular stripes
 Place on the lifeline where object is
activated.
 Rectangle also denotes when object
is deactivated( the end of the
rectangle).
Activation bar
X
 Deletion Return
Deletion
 Placing an ‘X’ on lifeline
 Object’s life ends at that point Lifeline

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 118

Sequence Diagram- Sequence Number

 A sequence diagram displays object interactions
Us er
arranged in a time sequence Catalog Res ervations

Message
1: look up ()
•Sequence diagrams demonstrate the
behavior of objects in a use case by 2: title data ()

describing the objects and the messages 3: [not available] res erve title ()
they pass.
4 : title returned ()

•The horizontal dimension shows the 5: hold title ()

objects participating in the interaction. 5 : title available ()

6 : borrow title ()

•The vertical arrangement of messages

6 : rem ove res ervation ()
indicates their order.
• The labels may contain the seq. #
to indicate concurrency.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 119

Interaction Diagrams: Collaboration (Communication) diagrams

start

6: remove reservation

3 : [not available] reserve title

User Reservations

5: title available
6 : borrow title
1: look up
2: title data

4 : title returned
Catalog

5 : hold title

Collaboration diagrams are equivalent to sequence diagrams. All the features of sequence
diagrams are equally applicable to collaboration diagrams
Interaction diagrams describe how use cases are realized in terms of interacting objects.
 Use a sequence diagram when the transfer of information(messages) is the focus of attention
 Use a collaboration diagram when concentrating on the objects involved

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 120

Interaction Diagrams in UML - Sequence

 A sequence diagram displays object interactions arranged in a time
sequence

course form : theManager :

Registrar Create Course
: Registrar CourseForm CurriculumManager
This use case begins
after the Registrar
logs onto the 1: set course info
Registration
System with a valid 2: request processing
password.
The registrar fills in the 3: add course
course form with
the appropriate
4: <<create>> aCourse :
semester and
course related info.
The Registrar requests Course
the system to
process the course
form.
The system creates a
new course, and
this use case ends
Chapter 2 Basic OO Concepts and UML Modeling
Traceability!
04/09/2023
 121
Interaction Diagrams- Collaboration (Communication)

 Displays object interactions organized around objects and their direct links to one another.
 Emphasizes the structural organization of objects that send and receive messages.

1: set course info course form:

course form : theManager : 2: request processing CourseForm
: Registrar CourseForm CurriculumManager

1: set course info

2: request processing
: Registrar 3: add course
3: add course

4: <<create>> aCourse:
Course
theManager :
aCourse: CurriculumManager
Course 4: <<create>>

Traceability!
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 State Diagrams (Billing Example)
122

State Diagrams show the sequences of states an object goes through during its life cycle in
response to stimuli, together with its responses and actions; an abstraction of all possible
behaviors. A state machine diagram expresses behavior as a progression through a series of
states, triggered by events, and the related actions that may occur.
Initial state happens when object is created, Final state happens when an object ceases to exist.
The transition diagrams of permanent entity types do not have final states, because, by
definition, instances of these types never cease to exist.
State Diagram is also known as
• State Transition Diagram
• (Statechart) Diagram)

Start End
Unpaid Paid
Invoice created payin Invoice destroying
g

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 123

State Chart Diagrams Cont’d…

 Event-driven models, such as statechart diagram, are particularly
appropriate for real-time systems.
 used to model the behavior of active classes that use call events and
signal events to implement their operations.
 The two essential elements of a state machine diagram are
 States and state transitions.
 States can be
 Initial, Final, and (Intermediate)Simple States.
 When an object is in a given state, it can do the following:
 Execute an activity (Action that will trigger a transition)
 Wait for an event( that will trigger an action)
 Fulfill a condition( that will trigger a transition)
 Do some or all of the above (combination)
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 124

State Chart Diagrams Cont’d…

 The movements between states are called transitions
 (Labeled or otherwise) directed arrows between states indicate transitions.
 A transition is a relationship between two states which is triggered by some event,
which performs certain actions or evaluations, and which results in a specific end-
state
 Transitions will be triggered by an event that is either internal or external to the
object.
 Event types can be signal events, call events, the passing of time, or a change in
state.
 signal event (the system receives a signal from an external agent)
 call event (a system operation is invoked)
 timing event (a timeout occurs)
 change event (a system property is changed by an external agent
 An action is an executable atomic computation, meaning that it cannot be
interrupted by an event and therefore runs to completion.
 Conditions can be used to control transitions. aka [guards]
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 125

State machine Diagram notations

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 126

State Activities—Entry, Do, and Exit Activities

 Activities may be associated with states.

 In particular, we may specify some activity that is to
be carried out at certain points in time with respect to
a state.
 Perform an activity upon entry of the state.
 Do an activity while in the state.
 Perform an activity upon exit of the state.

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

State Activities—Entry, Do, and Exit Activities
 Here, we see that;
 upon entering the Timing state, we
start the timer (indicated by the icon
of an arrow next to two parallel lines),
and
 upon exiting this state (indicated by
the icon of an arrow between two
parallel lines), we stop the timer (note
that these icons are tool specific).
 While in this state, we measure the
time duration (indicated by the
circular arrow).

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling 127

 128

State Diagrams (Traffic light example using timer event type)- no final state

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 129

UML- State Transition Diagram – another example

initial (internal)
condition
event/action Add student [count < 10]
Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]
Canceled
do: Notify registered students
Closed
Cancel do: Finalize course

final

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 UML- Behavioral Diagram-Activity Diagram 130

• A special kind of statechart diagram that shows the flow from activity to activity.
initial

Initialize course activity

Activity Diagram is a Data driven
modeling equivalent to DFD,
where as state chart is Event driven
Add student modeling

fork/spawn

Notify Registrar Notify Billing

Synchronization(join)
[else]

[ count < 10 ]
guard
Close course final
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
 131

UML- Component Diagram

 In UML 2.0, a component is a replaceable/reusable, architecture /
design-time construct with interfaces
Register.exe
Billing.exe
Billing What is this lollipop
thing?

User
Course People.dll
Course.dll

Student Professor
Course Course
Offering

Student Professor

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 132

UML Deployment Diagram

Shows the configuration of run-time processing elements and the software processes
living on them.
Visualizes the distribution of components across the enterprise.

Registrar Webserver Course Oracle Server

Register.exe Course
Course Offering
RMI, sockets TCP/IP

wireless
Library Server Main Building Solaris
People.dll Billing.exe

Dorm PC

People Database
Student
Professor

04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling

 133

Tools with UML Support

 Rational Rose(IBM)
 MS-Visio –(Microsoft)
 Conceptdraw
 Lucidchart
 ArgoUML
 Eclipse UML2 Tools
 UCEd
 …….
04/09/2023 Chapter 2 Basic OO Concepts and UML Modeling
4. A Modern Look at Modelling. 134

Chapter 2 Basic OO Concepts and UML

Modeling
04/09/2023
 135

End of Chapter 2

04/09/2023 Chapter 2 OO Concepts and UML Modeling