objectives design class diagrams issues in system design generalization review uml papers
TRANSCRIPT
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
POST
captures1 1
Sale DateisComplete: boolean
time
captures1 1
POST
DateisComplete:boolean
time
Sale
DateisComplete:boolean
time makeLineItem()
Conceptual model
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
captures1 1
POST
DateisComplete:boolean
time
Sale
DateisComplete:boolean
time makeLineItem()
POST will likely have anattribute pointing to Sale.
Navigability arrow: POSTobjects are connected
uni-directionally to Saleobjects.
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
UPC
Cash
Quantity
Balance
Enter Item End Sale Make Payment
Object Store x_
CashPresentation layer
Persistent storage
Application logicRecord Sales Authorize payments
StorageDatabase
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.)
Application logic
Presentation POSTApplet
ReportGeneratorDBInterface
SalePayment Domain concepts
services
StorageDatabase
Issues in System designDecomposition
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.
Domain concepts
Issues in System design
Core elements Sales
Issues in System design
Presentation
Domain
Services
Presentation
App logic
StorageDatabase
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:
GeneralizationAccount
balanceinterest rate
open()close()check balance()
CheckingAccount
number of free checksCheck Fee
GetCheckFeeRate()
SavingsAccount
Additional InterestRate
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
Account
balanceinterest rate
open()close()check balance()
Interest
Interest Rate
CalculateInterestAmount()
• Dependency - example
Generalization
• Aggregation– An association that relates a whole to its parts
Corporation
Department
Company
More on Relationships
• Polymorphism - refers to operations among classes that are logically the same but have more than one implementation method
More on RelationshipsAccount
balanceinterest rate
open()close()check balance()
CheckingAccount
number of free checksCheck Fee
GetCheckFeeRate()open()
SavingsAccount
Additional InterestRate
open()
Interest
Interest Rate
CalculateInterestAmount()