UML_Training.ppt

Object Oriented Analysis and Design
using the UML

Unified Software Practices v2001.03.00
Copyright © 2000 Rational Software, all rights reserved 2
Objectives
 Explain the Six Best Practices
 Present the Rational Unified Process within
the context of the Six Best Practices
 Basic UML notations
 Requirement Analysis
 Use case Realization
 Identifying Design elements
 Class Design
 Database Modeling

Symptoms of Software Development Problems
User or business needs not met
Requirements churn
Modules don’t integrate
Hard to maintain
Late discovery of flaws
Poor quality or end-user experience
Poor performance under load
No coordinated team effort
Build-and-release issues

Trace Symptoms to Root Causes
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Symptoms Root Causes Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Control Changes (UCM)

Trace Symptoms to Root Causes
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Insufficient requirements
Brittle architectures
Overwhelming complexity
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Symptoms Root Causes Best Practices
Develop Iteratively
Manage Requirements
Modules don’t fit

Rational: Software Development Best Practices
 Harvested from...
 1000’s of customers
 1000’s of projects
 Industry experts
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements

Requirements
and
Business
Models
HTML
CGI
XML
JavaScript
SQL
ER Models
C++
Java
SW Models
Multiple Languages = Communication Barriers
Software
Engineer
Database
Administrat
or
Web
Content
Creator
Business
Analyst

Software
Engineer
Database
Administrat
or
Web
Content
Creator
Business
Analyst
UML: One Language for All Practitioners
 Requirements
 Data
 Structure
 Behavior

Rational Unified Process Implements Best Practices
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements

A Team-Based Definition of Process
A process defines Who is doing What,
When and How to reach a certain goal.
New or changed
requirements
New or changed
system
Software Engineering
Process

Inception Elaboration Construction Transition
Process Structure - Lifecycle Phases
The Rational Unified Process has four
phases:
 Inception - Define the scope of project
 Elaboration - Plan project, specify features,
baseline architecture
 Construction - Build the product
 Transition - Transition the product into end
user community
time

Inception Elaboration Construction Transition
Phase Boundaries Mark Major Milestones
Lifecycle
Objective
Milestone
Lifecycle
Architecture
Milestone
Initial Operational
Capability
Milestone
Product
Release
time

Bringing It All Together: The Iterative Approach
Workflows
group
activities
logically
In an
iteration,
you walk
through all
workflows

Summary: Best Practices of Software Engineering
 Best Practices guide software engineering
by addressing root causes
 Best Practices reinforce each other
 Process guides a team on what to do, how
to do it, and when to do it
 The Rational Unified Process is a means of
achieving Best Practices

What Is a Model?
 A model is a simplification of reality.

Why Do We Model?
 We build models to better understand the system
we are developing.
 Modeling achieves four aims. Modeling:
 Helps us to visualize a system as we want it to be.
 Permits us to specify the structure or behavior of a
system.
 Gives us a template that guides us in constructing a
system.
 Documents the decisions we have made.
 We build models of complex systems because we
cannot comprehend such a system in its entirety.

Truck
Chemical Process
Linked List
What Is an Object?
 Informally, an object represents an entity,
either physical, conceptual, or software.
 Physical entity
 Conceptual entity
 Software entity

A More Formal Definition
 An object is an entity
with a well-defined
boundary and identity
that encapsulates state
and behavior.
 State is represented by
attributes and
relationships.
 Behavior is represented
by operations, methods,
and state machines. Object
Operations
Attributes

An Object Has State
 The state of an object is one of the possible
conditions in which an object may exist.
 The state of an object normally changes over
time.
Name: J Clark
Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad: 3
Name: J Clark
Employee ID: 567138
Date Hired: July 25, 1991
Status: Tenured
Discipline: Finance
Maximum Course Load: 3 classes Professor Clark

An Object Has Behavior
 Behavior determines how an object acts and
reacts.
 The visible behavior of an object is modeled by
the set of messages it can respond to (operations
the object can perform).
Professor Clark’s behavior
Submit Final Grades
Accept Course Offering
Take Sabbatical
Maximum Course Load: 3 classes
TakeSabbatical()
Professor Clark

An Object Has Identity
 Each object has a unique identity, even if
the state is identical to that of another
object.
Professor “J Clark”
teaches Biology
Professor “J Clark”
teaches Biology

Representing Objects in the UML
 An object is represented as a rectangle
with an underlined name.
J Clark :
Professor
: Professor
Named Object
Unnamed Object
Professor J Clark

Basic Principles of Object Orientation
Object Orientation
Encapsulation
Abstraction
Hierarchy
Modularity

What Is Abstraction?
 The essential characteristics of an
entity that distinguish it from all other
kinds of entities
 Defines a boundary relative to the
perspective of the viewer
 Is not a concrete manifestation,
denotes the ideal essence of
something

Example: Abstraction
Student Professor
Course Offering (9:00 AM,
Monday-Wednesday-Friday) Course (e.g. Algebra)

What Is Encapsulation?
Improves Resiliency
 Hide implementation from clients.
 Clients depend on interface.

Encapsulation Illustrated
 Professor Clark
needs to be able
to teach four
classes in the
next semester.
TakeSabbatical()
Professor Clark
Name: J Clark
Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad:4
SetMaxLoad(4)

What Is Modularity?
 Modularity is the breaking up of something
complex into manageable pieces.
 Modularity helps people to understand
complex systems.

Example: Modularity
Course Registration
System
?
Billing System
Course Catalog System
Student Management System

What Is Hierarchy?
Decreasing
abstraction
Increasing
abstraction
Asset
RealEstate
Savings
BankAccount
Checking Stock
Security
Bond
Elements at the same level of the hierarchy
should be at the same level of abstraction.

What Is a Class?
 A class is a description of a set of objects
that share the same attributes, operations,
relationships, and semantics.
 An object is an instance of a class.
 A class is an abstraction in that it
 Emphasizes relevant characteristics.
 Suppresses other characteristics.

Representing Classes in the UML
 A class is represented using a rectangle
with compartments.
Professor J Clark
Professor
- name
- employeeID : UniqueId
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()

The Relationship Between Classes and Objects
 A class is an abstract definition of an object.
 It defines the structure and behavior of each
object in the class.
 It serves as a template for creating objects
 Objects are grouped into classes.
Professor Paul Meijer
Professor Tom Allen
Professor Jane Torpie
Professor

What Is an Attribute?
 An attribute is a named property of a class
that describes a range of values that
instances of the property may hold.
 A class may have any number of attributes or no
attributes at all.
Attributes
Student
- name
- address
- studentID
- dateOfBirth

What Is an Operation?
 An operation is the implementation of a
service that can be requested from any
object of the class to affect behavior.
 A class may have any number of operations
or none at all.
Operations
Student
+ get tuition()
+ add schedule()
+ get schedule()
+ delete schedule()
+ has pre-requisites()

What Is Polymorphism?
Manufacturer A
Manufacturer B
Manufacturer C
OO Principle:
Encapsulation
 The ability to hide many different
implementations behind a single interface

Example: Polymorphism
Stock Bond Mutual Fund
Get Current Value

Realization relationship (stay tuned for realization relationships)
What is an Interface?
 Interfaces formalize polymorphism
 Interfaces support “plug-and-play”
architectures
Shape
draw()
move()
scale()
rotate()
<<Interface>>
Tube
Pyramid
Cube

Elided/Iconic
Representation
(“lollipop”)
Canonical
(Class/Stereotype)
Representation
(stay tuned for realization relationships)
How Do You Represent An Interface?
Shape
draw()
move()
scale()
rotate()
<<Interface>>
Shape
Tube
Pyramid
Cube
Tube
Pyramid
Cube

 A package is a general purpose mechanism
for organizing elements into groups.
 It is a model element that can contain other
model elements.
 A package can be used
 To organize the model under development.
 As a unit of configuration management.
What Is a Package?
University
Artifacts

 A combination of a package (can contain
other model elements) and a class (has
behavior)
 Realizes one or more interfaces which
define its behavior
OO Principles: Encapsulation and Modularity
Interface
Realization
Subsystem
(stay tuned for realization relationship)
What is a Subsystem?
Subsystem
Name
<<subsystem>>
Interface

 A non-trivial, nearly independent, and
replaceable part of a system that fulfills a
clear function in the context of a well-
defined architecture
 A component may be
 A source code component
 A run time components or
 An executable component
Source File
Name
<<EXE>>
Executable
Name
OO Principle:
Encapsulation
What is a Component?
<<DLL>>
Component
Name
Component
Interface

 Components are the physical realization of
an abstraction in the design
 Subsystems can be used to represent the
component in the design
Design Model Implementation Model
Component
Name
<<subsystem>>
Component Name
Component
Interface
Component
Interface
OO Principles: Encapsulation and Modularity
Subsystems and Components

What Is an Association?
 The semantic relationship between two
or more classifiers that specifies
connections among their instances
 A structural relationship, specifying that objects
of one thing are connected to objects of another
Course
<<entity>>
Student
<<entity>>
Schedule
<<entity>>

What Is Multiplicity?
 Multiplicity is the number of instances of one class
relates to ONE instance of another class.
 For each association, there are two multiplicity
decisions to make, one for each end of the
association.
 For each instance of Professor, many Course Offerings
may be taught.
 For each instance of Course Offering, there may be
either one or zero Professor as the instructor.
Professor
<<entity>>
CourseOffering
<<entity>>
0..1 0..*
0..1 0..*
instructor

Multiplicity Indicators
2..4
0..1
1..*
0..*
1
*
 Unspecified
 Exactly one
 Zero or more (many,
unlimited)
 One or more
 Zero or one (optional
scalar role)
 Specified range
 Multiple, disjoint
ranges 2, 4..6

What Is Aggregation?
 An aggregation is a special form of
association that models a whole-part
relationship between an aggregate (the
whole) and its parts.
 An aggregation “Is a part-of” relationship.
 Multiplicity is represented like other
associations.
Part
Whole
0..1
1
1 0..1

Package
Class
Dependency
relationship
Dependency
relationship
Component
Relationships: Dependency
 A relationship between two model elements
where a change in one may cause a
change in the other
 Non-structural, “using” relationship
Client Supplier
ClientPackage SupplierPackage
Client Supplier

What Is Generalization?
 A relationship among classes where one
class shares the structure and/or behavior
of one or more classes
 Defines a hierarchy of abstractions in which
a subclass inherits from one or more
superclasses
 Single inheritance
 Multiple inheritance
 Is an “is a kind of” relationship

Example: Single Inheritance
 One class inherits from another
Checking
Savings
Superclass
(parent)
Subclasses
Generalization
Relationship
Ancestor
Descendents
Account
- balance
- name
- number
+ withdraw()
+ createStatement()

Example: Multiple Inheritance
Use multiple inheritance only when needed and
always with caution!
 A class can inherit from several other
classes.
FlyingThing Animal
Horse
Wolf
Bird
Helicopter
Airplane
Multiple Inheritance

Inheritance leverages the similarities among classes
What Gets Inherited?
 A subclass inherits its parent’s attributes,
operations, and relationships
 A subclass may:
 Add additional attributes, operations,
relationships
 Redefine inherited operations (use caution!)
 Common attributes, operations, and/or
relationships are shown at the highest
applicable level in the hierarchy

Truck
tonnage
GroundVehicle
weight
licenseNumber
Car
owner
register( )
getTax( )
Person
0..*
Trailer
1
Superclass
(parent)
Subclass
generalization
size
Example: What Gets Inherited

Elided form
Canonical form
What Is Realization?
 One classifier serves as the contract that
the other classifier agrees to carry out
 Found between:
 Interfaces and the classifiers that realize them
Use-Case Realization Use-Case
Use cases and the collaborations that realize them
Subsystem
<<subsystem>>
Interface
Class
Interface
Component
Interface

What Are Stereotypes?
 Stereotypes define a new model element in
terms of another model element.
 Sometimes, you need to introduce new
things that speak the language of your
domain and look like primitive building
blocks.
Class
<<stereotype>> Stereotype

What Are Notes?
 A comment that can be added to include
more information on the diagram
 May be added to any UML element
 A ‘dog eared’ rectangle
 May be anchored to an element with a
dashed line
MaintainScheduleForm
There can be up to one
MaintainScheduleForm
per user session.

PersistentClass
{persistence} anObject : ClassA
{location=server}
Tagged Values
 Extensions of the properties, or specific
attributes, of a UML element
 Some properties are defined by UML
 Persistence
 Location (e.g., client, server)
 Properties can be created by UML modelers
for any purpose

Review: Concepts of Object Orientation
 What are the four basic principles of object
orientation? Provide a brief description for
each.
 What is an object and what is a class?
What is the difference between the two?
 What is an attribute?
 What is an operation?
 What is an interface? What is
polymorphism?

Requirements Overview Topics
 Introduction
 Key Concepts
 Use-Case Model
 Glossary
 Supplementary Specifications
 Checkpoints

Requirements in Context
Management
Environment
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Configuration & Change Mgmt
Requirements
Elaboration Transition
Inception Construction
The purpose of Requirements is:
To establish and maintain agreement with the customers and other
stakeholders on what the system should do.
To give system developers a better understanding of the requirements of
the system.
To delimit the system.
To provide a basis for planning the technical contents of the iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user interface of the system.

Relevant Requirements Artifacts
Supplementary
Specification
Glossary
Use-Case Specifications
...
Use-Case Model
Actors
Use Cases

Case Study: Course Registration Problem Statement
 Review the problem statement provided in
the Course Registration Requirements
Document

 Introduction
 Key Concepts
 Use-Case Model
 Glossary
 Checkpoints

What Is System Behavior?
 System behavior is how a system acts and
reacts.
 It is the outwardly visible and testable activity of
a system
 System behavior is captured in use cases.
 Use cases describe the system, its
environment, and the relationship between the
system and its environment.

Major Concepts in Use-Case Modeling
 An actor represents anything
that interacts with the system.
 A use case is a sequence of
actions a system performs
that yields an observable
result of value to a particular
actor.
Use Case
Actor

 Introduction
 Key Concepts
 Use-Case Model
 Glossary
 Checkpoints

What Is a Use-Case Model?
 A model that describes a
system’s functional
requirements in terms of
use cases
 A model of the system’s
intended functionality
(use cases) and its
environment (actors)
Student
View Report
Card
Register for
Courses
Login

What Are the Benefits of a Use-Case Model?
 Used to communicate with the end users and
domain experts
 Provides buy-in at an early stage of system
development
 Insures a mutual understanding of the requirements
 Used to identify
 Who interacts with the system and what the system
should do
 The interfaces the system should have
 Used to verify
 All requirements have been captured
 The development team understands the requirements

How Would You Read This Diagram?
Course Catalog
View Report Card
Register for Courses
Submit Grades
Select Courses to Teach
Student
Professor
Billing System
Maintain Student Information
Maintain Professor Information
Login
Close Registration
Registrar

Use-Case Specifications
 Name
 Brief description
 Flows of Events
 Relationships
 Activity diagrams
 Use-Case diagrams
 Special
requirements
 Pre-conditions
 Post-conditions
 Other diagrams Use-Case Specifications
...
Use-Case
Model
Actors
Use Cases

Use-Case Flow of Events
 Has one normal, basic flow
 Several alternative flows
 Regular variants
 Odd cases
 Exceptional flows handling error situations

What Is an Activity Diagram?
 An activity diagram in the use-case model can be
used to capture the activities in a use case.
 It is essentially a flow chart, showing flow of
control from activity to activity.
Flow of Events
This use case starts when the Registrar requests
that the system close registration.
1. The system checks to see if registration is in
progress. If it is, then a message is displayed to
the Registrar and the use case terminates. The
Close Registration processing cannot be
performed if registration is in progress.
2. For each course offering, the system checks if
a professor has signed up to teach the course
offering and at least three students have
registered. If so, the system commits the course
offering for each schedule that contains it.

Select
Course
Check
Schedule
Check
Pre-requisites
Assign to
course
Resolve
conflicts
Update
schedule
[ student added to the course ]
[ add course ]
Delete Course
[ delete course ]
[ checks completed ] [ checks failed ]
Example: Activity Diagram
Activity State
Synchronization Bar (Fork)
Guard Condition
Synchronization Bar (Join)
Decision
Concurrent threads
Transition

 Introduction
 Key Concepts
 Use-Case Model
 Glossary
 Checkpoints

Glossary
Glossary
Course Registration System Glossary
1. Introduction
This document is used to define terminology specific to the problem
domain, explaining terms, which may be unfamiliar to the reader of the
use-case descriptions or other project documents. Often, this document
can be used as an informal data dictionary, capturing data definitions so
that use-case descriptions and other project documents can focus on
what the system must do with the information.
2. Definitions
The glossary contains the working definitions for the key concepts in the
Course Registration System.
2.1 Course: A class offered by the university.
2.2 Course Offering: A specific delivery of the course for a specific
semester – you could run the same course in parallel sessions in the
semester. Includes the days of the week and times it is offered.
2.3 Course Catalog: The unabridged catalog of all courses offered by
the university.

 Introduction
 Key Concepts
 Use-Case Model
 Glossary
 Checkpoints

Supplementary
Specification
Supplementary Specification
 Functionality
 Usability
 Reliability
 Performance
 Supportability
 Design constraints

 Introduction
 Key Concepts
 Use-Case Model
 Glossary
 Checkpoints

Checkpoints: Requirements: Use-Case Model
 Is the use-case model
understandable?
 By studying the use-case model, can
you form a clear idea of the system's
functions and how they are related?
 Have all functional requirements
been met?
 Does the use-case model contain
any superfluous behavior?
 Is the division of the model into use-
case packages appropriate?

Checkpoints: Requirements: Actors
 Have all the actors been identified?
 Is each actor involved with at least
one use case?
 Is each actor really a role? Should
any be merged or split?
 Do two actors play the same role in
relation to a use case?
 Do the actors have intuitive and
descriptive names? Can both users
and customers understand the
names?

Checkpoints: Requirements: Use-Cases
 Is each use case involved with at
least one actor?
 Is each use case independent of the
others?
 Do any use cases have very similar
behaviors or flows of events?
 Do the use cases have unique,
intuitive, and explanatory names so
that they cannot be mixed up at a
later stage?
 Do customers and users alike
understand the names and
descriptions of the use cases?

Checkpoints: Requirements: Use-Case Specifications
 Is it clear who wishes to perform a
use-case?
 Is the purpose of the use-case also
clear?
 Does the brief description give a true
picture of the use-case?
 Is it clear how and when the use-
case's flow of events starts and ends?
 Does the communication sequence
between actor and use-case conform
to the user's expectations?
 Are the actor interactions and
exchanged information clear?
 Are any use-cases overly complex?

Checkpoints: Requirements: Glossary
 Does each term have a clear and
concise definition?
 Is each glossary term included
somewhere in the use-case
descriptions?
 Are terms used consistently in the brief
descriptions of actors and use cases?

Review: Requirements Overview
 What are the main artifacts of Requirements?
 What are the Requirements artifacts used for?
 What is a use-case model?
 What is an actor?
 What is a use case? List examples of use case
properties.
 What is the difference between a use-case and a
scenario?
 What is a supplementary specification and what
does it include?
 What is a glossary and what does it include?

Management
Environment
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Configuration & Change Mgmt
Requirements
Elaboration Transition
Inception Construction
The purposes of Analysis and Design are:
To transform the requirements into a design of the
system to-be.
To evolve a robust architecture for the system.
To adapt the design to match the implementation
environment, designing it for performance.
Analysis and Design in Context

Supplementary
Specification
Use-Case Model
Design Model
Data Model
Architecture
Document
Analysis
and Design
Analysis and Design Overview
Glossary

Analysis Versus Design
 Analysis
 Focus on
understanding the
problem
 Idealized design
 Behavior
 System structure
 Functional
requirements
 A small model
 Design
 Focus on
understanding the
solution
 Operations and
Attributes
 Performance
 Close to real code
 Object lifecycles
 Non-functional
requirements
 A large model

Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers
Software management
Performance
Scalability
Throughput
System integrators
System topology
Delivery, installation
communication
System engineering
Analysts/Designers
Structure
Software Architecture: The “4+1 View” Model

Architectural
Analysis
Architectural Analysis in Context
Architect

What is An Architectural Pattern?
 An architectural pattern expresses a fundamental
structural organization schema for software
systems. It provides a set of predefined
subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the
relationships between them – Buschman et al,
“Pattern-Oriented Software Architecture— A System of
Patterns””
 Layers
 Model-view-controller (M-V-C)
 Pipes and filters
 Blackboard

Typical Layering Approach
General
functionality
Specific
functionality

Architectural Pattern: Layers

Why Use Analysis Mechanisms?
Oh no! I found a group of classes that
has persistent data. How am I
supposed to design these things if I
don’t even know what database we are
going to be using?
That is why we have a
persistence analysis mechanism.
We don’t know enough yet, so we
can bookmark it and come back
to it later.
Analysis mechanisms are used during analysis to reduce the complexity of
analysis, and to improve its consistency by providing designers with a short-
hand representation for complex behavior.

Sample Analysis Mechanisms
 Persistency
 Communication (IPC and RPC)
 Message routing
 Distribution
 Transaction management
 Process control and synchronization (resource
contention)
 Information exchange, format conversion
 Security
 Error detection / handling / reporting
 Redundancy
 Legacy Interface

Examples of Analysis Mechanism Characteristics
 Persistency mechanism
 Granularity
 Volume
 Duration
 Access mechanism
 Access frequency (creation/deletion, update, read)
 Reliability
 Inter-process Communication mechanism
 Latency
 Synchronicity
 Message Size
 Protocol

Example of Analysis Mechanism Characteristics (cont.)
 Legacy interface mechanism
 Latency
 Duration
 Access mechanism
 Access frequency
 Security mechanism
 Data granularity
 User granularity
 Security rules
 Privilege types
 etc.

Use-Case Analysis in Context
Use-Case
Analysis Designer

Use-Case Analysis Overview
Supplementary
Specifications
Glossary
Use-Case Model
Use-Case
Analysis
Use-Case
Modeling Guidelines
Use-Case Realization
(identified)
Use-Case Realization
(developed)
Design Model
Analysis Classes
Analysis Model (optional)
Software Architecture
Document

 An abstraction
 Describes a group of objects with common:
 Properties (attributes)
 Behavior (operations)
 Relationships
 Semantics Class Name
Attributes
Operations
Review: Class
Professor
name
ProfessorId : UniqueId
create()
save()
delete()
change()

Review: Use-Case Realization
Class Diagrams
Sequence Diagrams
Use Case
Collaboration Diagrams
Use-Case Model Design Model
Use Case Use-Case Realization

Find Classes From Use-Case Behavior
 The complete behavior of a use case has to
be distributed to analysis classes

System
boundary Use-case
behavior
coordination
System
information
What is an Analysis Class?
<<boundary>>
<<control>>
<<entity>>

Environment Dependent
Analysis class
stereotype
What is a Boundary Class?
 Intermediates between the interface and
something outside the system
 Several Types
 User interface classes
 System interface classes
 Device interface classes
 One boundary class per actor/use case pair

Model interaction between the system and its environment
Customer
<<boundary>>
<<boundary>>
<<control>>
<<boundary>>
<<entity>> <<entity>>
The Role of a Boundary Class

Student Course Catalog System
Example: Finding Boundary Classes
 One boundary class per actor/use case pair
RegisterForCoursesForm CourseCatalogSystem

Concentrate on the responsibilities, not the details!
Guidelines: Boundary Class
 User Interface Classes
 Concentrate on what information is presented to
the user
 Do NOT concentrate on the UI details
 System and Device Interface Classes
 Concentrate on what protocols must be defined
 Do NOT concentrate on how the protocols will
be implemented

Glossary
Business-Domain Model
Environment Independent
Analysis class
stereotype
Use Case
Architectural Analysis
Abstractions
What is an Entity Class?
 Key abstractions of the system

Store and manage information in the system
Customer
<<boundary>>
<<boundary>>
<<control>>
<<boundary>>
The Role of an Entity Class

Example: Finding Entity Classes
 Use use-case flow of events as input
 Key abstractions of the use case
 Traditional, filtering nouns approach
 Underline noun clauses in the use-case flow of
events
 Remove redundant candidates
 Remove vague candidates
 Remove actors (out of scope)
 Remove implementation constructs
 Remove attributes (save for later)
 Remove operations

Example: Candidate Entity Classes
 Register for Courses (Create Schedule)
Student
Schedule
CourseOffering

Use Case
Use-case dependent, Environment independent
Analysis class
stereotype
What is a Control Class?
 Use-case behavior coordinator
 One control class per use case

The Role of a Control Class
Coordinate the use-case behavior
Customer
<<boundary>>
<<boundary>>
<<control>>
<<boundary>>

Course Catalog System
Student
Example: Finding Control Classes
 One control class per use case
RegistrationController

Student Course Catalog System
Use-Case Model
Design Model
Example: Summary: Analysis Classes
RegisterForCoursesForm CourseCatalogSystem Student Schedule
CourseOffering RegistrationController

Use Case Use-Case Realization
Sequence Diagrams Collaboration Diagrams
Distribute Use-Case Behavior to Classes
 For each use-case flow of events:
 Identify analysis classes
 Allocate use-case responsibilities to analysis
classes
 Model analysis class interactions in interaction
diagrams

Guidelines: Allocating Responsibilities to Classes
 Use analysis class stereotypes as a guide
 Boundary Classes
• Behavior that involves communication with
an actor
 Entity Classes
• Behavior that involves the data encapsulated
within the abstraction
 Control Classes
• Behavior specific to a use case or part of a
very important flow of events
(continued)

The Anatomy of Sequence Diagrams
1: PerformResponsibility
Client Object Supplier Object
Message
:Client :Supplier
Focus of Control
This is a
sample script.
Reflexive Message
Object Lifeline
1.1: PerformAnother
Responsibility
Hierarchical Message
Numbering

Example: Sequence Diagram
: Student
: RegisterForCoursesForm : RegistrationController : Schedule : Student : Course Catalog
: CourseCatalogSystem
A list of the available
course offerings for this
semester are displayed
create a new
schedule
1: // create schedule( )
5: // display course offerings( )
2: // get course offerings( )
3: // get course offerings(forSemester)
6: // display blank schedule( )
At this, point the Submit Schedule sub-flow is executed.
Sequence Diagram: Register for
Courses / Register for Courses - Basic
Flow (Submit Schedule)
7: // select 4 primary and 2 alternate offerings( )
8: // create schedule with offerings( ) 9: // create with offerings( )
A blank schedule
is displayed for the
students to select
offerings
10: // add schedule(Schedule)

Client Object
Supplier Object
Message
Link
:Client
:Supplier
The Anatomy of Collaboration Diagrams

Example: Collaboration Diagram
: Student
: RegisterForCoursesForm
: RegistrationController
:
Schedule
: Student
: CourseCatalogSystem
5: // display course offerings( )
6: // display blank schedule( )
: Course Catalog
1: // create schedule( )
7: // select 4 primary and 2 alternate offerings( )
8: // create schedule with offerings( )
9: // create with offerings( )
3: // get course offerings(forSemester)
10: // add schedule(Schedule)

Alternate Flow 4 Alternate Flow 5 Alternate Flow n
Alternate Flow 1 Alternate Flow 2 Alternate Flow 3
AF1
AF2
AF3
Basic Flow
One Interaction Diagram Is Not Good Enough

Collaboration Diagrams Vs Sequence Diagrams
 Collaboration
Diagrams
 Show relationships in
addition to interactions
 Better for visualizing
patterns of collaboration
 Better for visualizing all
of the effects on a given
object
 Easier to use for
brainstorming sessions
 Sequence Diagrams
 Show the explicit
sequence of messages
 Better for visualizing
overall flow
 Better for real-time
specifications and for
complex scenarios

// PerformResponsibility
:Client :Supplier
Supplier
// PerformResponsibility
Interaction Diagram
Class Diagram
Describe Responsibilities
 What are responsibilities?
 How do I find them?

Example: View of Participating Classes (VOPC) Class Diagram
Student
// get tuition()
// add schedule()
// get schedule()
// delete schedule()
// has pre-requisites()
<<entity>>
// get course offerings()
// get current schedule()
// delete current schedule()
// submit schedule()
// is registration open?()
// save schedule()
// create schedule with offerings()
// update schedule with new selections()
<<control>>
CourseCatalogSystem
// get course offerings()
<<boundary>>
RegisterForCoursesForm
// display course offerings()
// display blank schedule()
// update offering selections()
<<boundary>>
Schedule
// commit()
// select alternate()
// remove offering()
// level()
// cancel()
// get cost()
// delete()
// submit()
// save()
// any conflicts?()
// create with offerings()
// update with new selections()
<<entity>>

ClassName
<<stereotype>>
Attribute : Type = InitValue
attribute
In analysis, do not spend
time on attribute signatures
Review: What is an Attribute?
CourseOffering
number : String = "100"
startTime : Time
endTime : Time
days : Enum
numStudents : Int
<<entity>>

Finding Attributes
 Properties/characteristics of identified
classes
 Information retained by identified classes
 “Nouns” that did not become classes
 Information whose value is the important thing
 Information that is uniquely "owned” by an
object
 Information that has no behavior

Review: What Is an Association?
The semantic relationship between two or
more classifiers that specifies connections
among their instances
 A structural relationship, specifying that objects
of one thing are connected to objects of another
Course
<<entity>>
Student
<<entity>>
Schedule
<<entity>>

Link
Association
Collaboration
Diagram
Class
Diagram 0..*
Prime suppliers
0..*
Client Supplier
:Client :Supplier
Client Supplier
PerformResponsibility()
Relationship for every link!
Finding Relationships

Review: What is Aggregation?
 A special form of association that models a
whole-part relationship between an
aggregate (the whole) and its parts
Whole/aggregate part
0..2
0..*
CourseOffering
<<entity>>
Schedule
<<entity>>
Student
<<entity>>
1 0..*
1

When in doubt use association
 If two objects are tightly bound by a whole-part
relationship
 The relationship is an aggregation.
 If two objects are usually considered as
independent, although they are often linked
 The relationship is an association.
Association or Aggregation?
Car Door
0..2,4
1
1
Car Door
0..2,4
1

What are Roles?
 The “face” that a class plays in the
association
Role Name
CourseOffering
<<entity>>
Professor
<<entity>>
instructor
Department
<<entity>>
Department Head
Course
<<entity>>
preRequisites

Review: Multiplicity
2..4
0..1
1..*
0..*
1
*
 Unspecified
 Exactly one
 Zero or more (many,
unlimited)
 One or more
 Zero or one (optional
scalar role)
 Specified range
 Multiple, disjoint
ranges
2, 4..6

What Does Multiplicity Mean?
 Multiplicity answers two questions.
 Is the association mandatory or optional?
 What is the minimum and maximum number of
instances that can be linked to one instance?
Course
<<entity>>
0..3
0..*
preRequisites
0..3
0..*
CourseOffering
<<entity>> 0..* 1
0..* 1

CourseOffering
<<entity>>
Schedule
<<entity>>
primaryCourses
alternateCourses
CourseOffering
<<entity>>
Schedule
<<entity>>
add student to
remove student from
Multiple associations must reflect multiple roles
Example: Multiple Associations

Example: VOPC: Finding Relationships
<<boundary>>
CourseOffering
<<entity>>
Schedule
<<entity>>
0..*
primaryCourses
0..4
Student
<<entity>>
0..*
1
<<control>>
1 1
0..1
currentSchedule
0..1

Analysis Class Analysis Mechanism(s)
Describing Analysis Mechanisms
 Collect all analysis mechanisms in a list
 Draw a map of the client classes to the
analysis mechanisms
 Identify characteristics of the Analysis
Mechanisms

Analysis Class Analysis Mechanism(s)
Student
Schedule
CourseOffering
Course
Persistency, Security
Persistency, Legacy Interface
Persistency, Legacy Interface
Distribution
Persistency, Security
Example: Describing Analysis Mechanisms
 Analysis class to analysis mechanism map

(continued)
Checkpoints: Analysis Classes
 Are the classes reasonable?
 Does the name of each class
clearly reflect the role it plays?
 Does the class represent a single
well-defined abstraction?
 Are all attributes and
responsibilities functionally
coupled?
 Does the class offer the required
behavior?
 Are all specific requirements on
the class addressed?

Identify Design Elements in Context
Identify Design
Elements Architect

Supplementary
Specifications
Identify
Design
Elements
Software Architecture
Document
Design Model
Design Model
Design
Guidelines
Analysis Classes
Identify Design Elements Overview

Identify Design Elements Steps
 Identify classes and subsystems
 Identify subsystem interfaces
 Update the organization of the design
model
 Checkpoints

Analysis Classes Design Elements
Many-to-Many Mapping
From Analysis Classes to Design Elements
<<boundary>>
<<control>>
<<entity>>
<<boundary>>

Example: Registration Package
MainRegistrarForm
1
1
CloseRegistrationForm
<<boundary>>
0..1
0..1
CloseRegistrationController
<<control>>
1
1
MainStudentForm
1
1
<<boundary>>
0..1
0..1
1
1
<<control>>
1
1

FulltimeStudent
<<entity>>
ParttimeStudent
<<entity>>
PrimaryScheduleOfferingInfo
<<entity>>
ScheduleOfferingInfo
<<entity>>
Student
<<entity>>
Professor
<<entity>>
Schedule
<<entity>>
CourseOffering
<<entity>>
CourseOfferingList
1
preRequisites
0..*
Course
<<entity>>
0..*
1
instructor
0..1
0..*
0..*
0..*
0..*
0..4
primaryCourses
0..*
0..2
alternateCourses
0..*
1
Example: University Artifacts Package

IBillingSystem
<<Interface>>
ICourseCatalogSystem
<<Interface>>
Example: External System Interfaces Package

Analysis Class Design Element
CourseCatalogSystem
BillingSystem
All other analysis classes
map directly to design
classes
CourseCatalogSystem Subsystem
BillingSystem Subsystem
Example: Analysis-Class-To-Design-Element Map

Example: Subsystem Context: CourseCatalogSystem
Interface defined
ICourseCatalogSystem
getCourseOfferings(forSemester : Semester) : CourseOfferingList
initialize()
<<Interface>>
// close registration()
<<control>>
1
0..1
+courseCatalog
1
0..1
CourseCatalogSystem
getCourseOfferings(forSemester : Semester) : CourseOfferingList
initialize()
<<subsystem proxy>>
getCurrentSchedule()
deleteCurrentSchedule()
submitSchedule()
saveSchedule()
getCourseOfferings()
setSession()
<<class>> new()
getStudent()
<<control>>
CourseOfferingList
new()
add()

Example: Subsystem Context: Billing System
BillingSystem
submitBill(forStudent : Student, forTuition : double)
<<subsystem proxy>>
IBillingSystem
submitBill(forTuition : Double, forStudent : Student)
<<Interface>>
// close registration()
<<control>>
1
0..1
Biller
1
0..1
Student.
<<entity>>
0..1
1

Application
<<layer>>
Business
Services
<<layer>>
Security
Registration
GUI Framework
External System
Interfaces
University Artifacts
<<layer>>
Application
<<layer>>
Business Services
Secure Interfaces
Example: Application Layer Context

Example: Business Services Layer
BillingSystem
<<subsystem>>
CourseCatalogSystem
<<subsystem>>
External System
Interfaces
University
Artifacts
ObjectStore
Support
<<layer>>
Business Services
GUI
Framework
Secure
Interfaces
Security
<<subsystem>>
Security
Manager

Database Design in Context
Database
Design Database
Designer

Database Design Steps
 Map persistent design classes to the data
model
 Distribute class behavior to the database

The Relational Data Model
 Relational model is composed of
 Entities
 Relations
ORDER LINE ITEM
PRODUCT
Order_Id LineItem_Id
Description
Price
Quantity
Product_Id
Order_Id
Product_Id
Name
Price
lineItem order
products
lineItems
Entity
Relation
Columns

The Object Model
 The object model is composed of
 Classes(attributes)
 Associations
LineItem
- quantity : Integer
- number : Integer
1..*
+lineItems
1..*
Order
- number : Integer
+order
Product
- number : Integer
- description : String
- unitPrice : Double
1
1
Software Product
- version : Double
Hardware Product
- assembly : String

Mapping Persistent Classes to Tables
 In a relational database
 Every row is regarded as an object
 A column in a table is equivalent to a persistent
attribute of a class
Student
- name : String
- address : String
- studentID : Long
Name Student_ID
Thomas Stuart 123456
Object Instance
Attributes from object type

Mapping Associations Between Persistent Objects
 Associations between two persistent
objects are realized as foreign keys to the
associated objects.
 A foreign key is a column in one table which
contains the primary key value of associated
object
Number Course_ID
678 456789
Name Description Number
Math 101 Algebra 456789
Course Offering table
Course table
Course
- name
- description
- number
CourseOffering
- number : String
0..*
0..*
1
Primary Key
Foreign Key

Mapping Aggregation to the Data Model
 Aggregation is also modeled using foreign
key relationships
 Using composition implements a cascading
delete constraint
Student.
- studentID : int
Schedule
- semester : Semester
0..*
1
0..*
1
Student_ID Semester
123456 Spring 2001
Schedule table
Student_ID
123456
Foreign Key
Primary Key
Student table

Modeling Inheritance in the Data Model
 A data model does not support modeling
inheritance in a direct way
 Two options
 Use separate tables (normalized data)
 Duplicate all inherited associations and
attributes (de-normalized data)

What Are Stored Procedures?
 A stored procedure is executable code
which runs under the RDBMS
 Two types of stored procedures
 Procedures: Executed explicitly by an
application
 Triggers: Invoked implicitly when some
database event occurs

UML_Training.ppt

Recommended

Recommended

More Related Content

Similar to UML_Training.ppt

Similar to UML_Training.ppt (20)

Recently uploaded

Recently uploaded (20)

UML_Training.ppt

Editor's Notes