Objectives

• Design Class Diagrams

• Issues in system design
• Generalization
• Review UML papers
 Design Class diagrams
• Objectives
– create design class diagrams
– identify classes, methods, associations
 Design Class diagrams
• Definition: illustrates the specifications of
software classes in an application
• dependent on the following activities
– interaction diagrams (sequence or collaboration
diagrams) are completed
– conceptual model showing the concepts
• Conceptual modeling begins the definition
of Class diagrams
 Design Class diagrams
• What is the difference between Design
Class diagrams and Conceptual model?
– Sale in a conceptual represents an abstraction of
a real world concept that we are interested in
– Sale in a class diagram represents a software
class, meaning it includes attributes, attribute
types, methods
• UML does not differentiate these two types
 Design Class diagrams
• How to make a Design Class diagram?
– Identify all the concepts (classes) by analyzing
the interaction diagrams,use cases
– identify the methods by analyzing the
“messages” being exchanged in interaction
diagrams
– state diagrams reveal more methods
– add type information for attributes
 Design Class diagrams
• How to make a Design Class diagram?
– Add method return information (attribute and
type information)
– add associations to indicate dependencies,
generalizations
– add cardinality information
 Design Class diagrams
captures Sale
POST 1 1 Date
isComplete: boolean
time
Conceptual model

POST Sale
captures Date
1 1
isComplete:boolean
Date
isComplete:boolean time
makeLineItem()
time
Software components
 Design Class diagrams
• create is a special language independent UML
message to indicate instantiation and initialization.
As this is a common operation, it is often omitted
from class diagrams.
• Access methods for class attributes are also
omitted from class diagrams to reduce clutter.
• Messages to a multiobject are not shown as
methods in the class whose objects are contained
in a multiobject.
 Design Class diagrams
• It is recommended that UML syntax be used for
method naming. This will keep naming language
independent. UML format:
methodName(parameterList)
• Should all type information be shown in a class
diagram?
– If automatic code generation is desired then YES.
– If the sole purpose is to use the diagram as a
communication aid, then all type information is not of
any significant value.
 Design Class diagrams
Navigability arrow: POST
POST will likely have an
objects are connected
attribute pointing to Sale.
uni-directionally to Sale
objects.
POST Sale
captures Date
1 1
isComplete:boolean
Date
isComplete:boolean time
makeLineItem()
time
No navigability arrow..Sale
does not have connection
to POST.
 Design Class diagrams
• It is recommended that associations be adorned
with navigability arrows.
• Navigability is determined by visibility.
– A sends a message to B.
– A creates an instance of B.
– A needs to maintain a connection to B.
• Associations also indicate “persistent” connections
 Design Class diagrams
• In UML a dependency relationship indicates that
one element has knowledge of another element.
• It is illustrated with a dashed arrow.
• Non-attribute visibility…arising from parameters,
global, or locally declared items is illustrated by
dashed arrows. (Fig 21.11 larman)
 Issues in system design
• Design a system architecture in terms of
layers and partitions
• Use UML to illustrate package diagrams
• Identify and apply common system design
principles
– Model-View separation
– Publish-Subscribe events
 Issues in system design
• Often a system is composed of multiple
subsystems.
• Example:
– An information system connects to a use interface and a
persistent storage mechanism.
• How does one show subsystems and their
interactions in UML ?
 Issues in System design
Object Store _ x
UPC Quantity
Presentation layer
Cash

Cash Balance

Enter Item End Sale Make Payment

Application logic
Record Sales Authorize payments

Storage Persistent storage

Database
 Issues in System design
• 3-tier architecture separates the application logic
into a distinct middle layer.
• Presentation layer (mostly) free of application
processing.
• Middle layer communicates with the back-end
layer.
Would you prefer a two-tier architecture? (Obtained by
placing application logic into the presentation layer.)
 Issues in System design
POSTApplet
Decomposition
Presentation

Payment Sale Domain concepts

Application logic
DBInterface ReportGenerator services

Storage
Database
 Issues in System design
• Multi-tiered architecture useful when:
– The application logic needs to be split and isolated into
multiple layers.
– The application logic needs to be distributed amongst
several computers.
– Development of components needs to be distributed
amongst various developers.
 Issues in System design
• Deployment :
– A 3-tier architecture may be deployed in various
configurations. Examples:
– Presentation and app logic on one computer, database
on a server.
– Presentation on client computer, app logic on
application server, and database on a data server.
 Issues in System design

Domain concepts

Core elements Sales

 Issues in System design
Presentation Presentation

Domain
App logic

Services

Storage
Database
 Issues in System design
• Packages guidelines
– group elements that provide a common service
– usually applicable most during class modeling
– coupling and collaboration between elements of
various packages should be low
– elements within a single package should be
strongly related.
 Issues in System design
• Layers and Partitions
– Layers of an architecture represent vertical tiers.
– Partitions represent horizontal tiers, e.g. the Services
layer may be divided into Security and Reporting.
– Upward and downward communication is feasible
across components in a vertical layer. This is also
known as a “relaxed layer” architecture.
 Issues in System design
• Model-View separation
– de-couple domain objects from window objects
– design domain classes so that there is no direct
coupling to window classes
– minimize the impact of changes to requirements to
either domain or window interfaces
• Indirect communication in a system
– design for publish-subscribe patterns (polling is to
be avoided where possible)
 Generalization
• Objectives
– create generalization-specialization hierarchies
– validate using “Is-a” tests
 Generalization
• Inheritance
– Generalization : classes with a set of similar
features and meaning
– the sharing of attributes, operations among
classes related by generalization
– for example:
 Generalization
Account
balance
interest rate

open()
close()
check balance()

CheckingAccount SavingsAccount
number of free checks Additional InterestRate
Check Fee

GetCheckFeeRate()
 Generalization
• Dependency
– A dependency exists between two items if
changes to one item causes a change to the
other item
• For example: between two classes Account and
Interest, a change in interest rate causes changes in
the account
 Generalization
• Dependency - example
Account
Interest
balance
Interest Rate
interest rate
CalculateInterestAmount()
open()
close()
check balance()
 Generalization
• Aggregation
– An association that relates a whole to its parts
Corporation Company

Department
 More on Relationships
• Polymorphism - refers to operations among
classes that are logically the same but have
more than one implementation method
 More on Relationships
Account
balance Interest
interest rate Interest Rate

open() CalculateInterestAmount()
close()
check balance()

CheckingAccount SavingsAccount
number of free checks Additional InterestRate
Check Fee
open()
GetCheckFeeRate()
open()