Systems Analysis II OO Design principles INFO 355 Glenn Booker INFO 355 Week #4 Overview  Design takes the requirements for a system and develops the high level architecture.

Download Report

Transcript Systems Analysis II OO Design principles INFO 355 Glenn Booker INFO 355 Week #4 Overview  Design takes the requirements for a system and develops the high level architecture.

Systems Analysis II
OO Design principles
INFO 355
Glenn Booker
INFO 355
Week #4
1
Overview

Design takes the requirements for a
system and develops the high level
architecture of the system, and the
detailed design of each component


INFO 355
For the former, we’ll examine the UML
component diagram
For the latter, we’ll expand the domain
model into a design class diagram
Week #4
2
Component Diagrams


There’s much confusion on the
difference between a component
and a class
A component is a modular,
deployable, and replaceable
part of the system


INFO 355
Typically has more than one class in it
Is defined by its behavior & interfaces
Week #9
3
Component Diagrams

A component may be implemented
by one or more artifacts (scripts,
executable files, etc.)
Component1
Component2
UML 1
notation
INFO 355
UML 2
notation
Week #9
4
Component Diagrams



INFO 355
Can also denote a component with
a class symbol, and a stereotype
of <<component>> in front of
the name
Components can contain other
components
They are connected with interface
notation (lollipop or ball and socket)
Week #9
5
Component Diagrams

Components are often more a
marketing concept


Good as a high level design concept

INFO 355
Each component is independently
purchasable and upgradeable, like
parts of an entertainment system
Keep components relatively large scale
(much bigger than a DLL file), or they
are a pain to manage
Week #9
6
Component Diagrams

(p. 302)
Components can also be high level
structures of the system, such as
web servers, app servers, etc.



INFO 355
If this level of structure is too common
and/or obvious, the diagram might not
be needed
Could treat subsystems as components
Many systems are either client/server
or Internet-based architectures
Week #4
7
Design Class Diagram


OO design takes requirements (use
cases) and produces design models
The design class diagram adds more
detail to the domain model
Adds data types for attributes
 Adds methods
We’ll get methods from the sequence
diagram next week


INFO 355
Week #4
8
More Class Diagram Concepts


Beyond what was covered last
week, there are additional concepts
and corresponding notations which
may be used in class diagrams
They are grouped here into:



INFO 355
Class and Object Concepts
Association Concepts
Attribute Concepts
Week #5
9
Visibility


Visibility applies to a class, its
attributes, and methods
Options are public, private, and
protected, but their exact meaning
differs by programming language

INFO 355
Public is designated by a + sign, and
means things outside the class can
see it and use it
Week #5
10
Visibility



INFO 355
Private is shown with a – prefix, and
means that thing is only visible within
that class
Protected is shown with a # prefix, and
means something like it can be seen by
that class’ generalization hierarchy, but
not outside that
By default, attributes are private;
classes and methods are public
Week #5
11
Class and Object Concepts
INFO 355
Week #5
12
Abstract Classes

Abstract classes are used in
implementation to show a
superclass that is only used
via its subclasses

AnAbstractClass


INFO 355
The abstract superclass is never
instantiated into an object
The abstract class is shown by
putting its name in italics
In Visio, check the box IsAbstract
Week #5
13
Interface Classes

An interface is an abstract class
with all abstract features


INFO 355
A class provides an interface if it
implements that interface
A class requires an interface if it is
dependent upon an object from
that interface
Week #5
14
Interface Classes



INFO 355
This is a different sense for
interface than the model/view/
controller breakdown
There is a special element in Visio
for interface classes «interface»Interface2
Interfaces are shown in component
diagrams with a lollipop
Interfacename
Week #5
15
Interface Classes

An interface class could refer to a
connection to an external system

Have that interface class be the
gateway to that external system from
anywhere within your system
Class1
Class2
«interface»
HRInterface
<<external system>> HR System
Class3
Also called a façade pattern
System Boundary
INFO 355
Week #5
16
Interface Classes

Or they could be a connection to
somewhere else within your system,
such as an interface class


INFO 355
Treating human interfaces as an
interface objects allows data objects
to send output directly to them
Have the data object send output to an
abstract interface class, which in turn
points to the actual user interface
Week #5
17
Generalization and Classification


Generalization is often assumed to
have an implied verb phrase of ‘is a’
Beware that sometimes the intent
is really classification

Classification means the thing (object)
is an example of the “supertype”
My dog Hajime is an example of a Black
Lab; therefore, it is a classification
 Show classification with an <<instance>>
«instance»
constraint

INFO 355
Week #5
18
Generalization and Classification

Dog
Generalization means the thing is a
subtype of a supertype – they have
traits in common in the supertype, but
each subtype has unique traits
A poodle is a subtype of Dog; all Dogs
have common traits, but poodles have
certain size and shape characteristics
 Use the generalization symbol

Poodle
INFO 355
Week #5
19
Multiple Classification

Conceptually, it is possible for one
“superclass” to have many types
of classifications



INFO 355
In such cases, it is acceptable to
choose one value from each
generalization hierarchy
Hard to define all legal combinations
Difficult to implement in code,
hence only used conceptually
Week #5
20
Association Classes

An association class is a class which
depends on the existence of an
association between two other
classes
Employment
startdate : Date
salary : Currency
*
*
Company
INFO 355
Person
Week #5
21
Association Classes


Notice that there is no multiplicity
shown on the association class line
ends; it is always assumed to be 1
The association class adds a
constraint:

INFO 355
You can only have one entry (instance
of the association class) for each
combination of the other two classes
Week #5
22
Association Classes



INFO 355
Be wary of creating association
classes
Consider whether the same class
could just be a normal class, or if
the constraint adds meaning
Often helps clarify many-many
multiplicities
Week #5
23
Active Classes


AnActiveClass


INFO 355
An active class is a controller class
that manages its own threads based
on inputs
UML 2 has a double line symbol
Check the IsActive box in Visio; it
thickens the lines a little in UML 1.x
Good for an independently
operating process or daemon
Week #5
24
Object Diagrams


INFO 355
The class diagram represents all
classes which could exist in your
system
If you draw the class diagram at
one moment, and only show the
objects which exist at that moment,
you have an object diagram
Week #5
25
Object Diagrams


INFO 355
This is used to help navigate
complex use cases, when it isn’t
clear what objects have been
created or destroyed
You could consider the object
diagram like a collaboration
diagram without messages
Week #5
26
Object Diagrams


INFO 355
Make sure to note the full object
names, Ivan:Person
Actual values for attributes can be
shown
Week #5
27
Association Concepts
INFO 355
Week #5
28
Association Navigability


Now we can explicitly state whether
an association can go in only one
direction or another
Ask yourself if either class might
need to call upon a method in the
other class

INFO 355
An Invoice might add or remove
LineItem(s), but will a LineItem ever
create an Invoice?
Week #5
29
Association Navigability


If it’s a one-way association, in
Visio, check the correct box in the
line properties for IsNavigable
Leave the line with no arrows if
it’s bidirectional
-Label
Bidirectional association
*
*
-Label
One-way association
*
INFO 355
*
Week #5
30
Association End Labels


The ends of associations can be
labeled separately
Frequently helpful for hierarchical
associations
-Parent
-Manager
Person
INFO 355
Employee
*
1..*
0..1
1..*
-Child
-Subordinate
Week #5
31
Aggregation

Aggregation is used to show when
parts make up the whole of
something else



INFO 355
A Club class is made up of Member(s)
A Car is made up of Part(s)
The notation for aggregation is an
open diamond on the collective side
of the association (Club or Car)
Week #5
32
Aggregation

To get this line in Visio




Start with a Composition line
Double click on it
Change the Aggregation type
from Composite to Shared
Edit multiplicity and line ends
-Has
Club
*
INFO 355
-End3
1
*
-End4
Member
*
Week #5
33
Composition


A concept similar to aggregation
is composition
Composition is used to show
properties of a class that are
strongly owned by each object


INFO 355
The composite does not imply ALL
properties of that class, just an
important one
The diamond is filled in for composition
Week #5
34
Composition

For examples



A Polygon is defined by three or more
Point(s) in some ordered sequence
A Circle has a Point which is the center
of that circle
Hence this example
Polygon
-{ordered}
0..1
Point
1..*
3..*
1
0..1
Circle
-center
Note: the multiplicity of 1..* can
be manually overwritten to 3..*
INFO 355
Week #5
35
Aggregation and Composition


Aggregation doesn’t affect a class
diagram much, but it’s nice to show
the relationship where it applies
Composition is fairly rare, but can
show critical connections among
classes

INFO 355
What do Class A and Class B have in
common? They share a composition
with Class C.
Week #5
36
Qualified Associations

A qualified association can be used
to refine the multiplicities of an
association by specifying an
attribute through which the
association is made
ProductCatalog
itemID
1
INFO 355
ProductSpecification
1
Week #5
37
Qualified Associations

The multiplicity of the qualified
association (itemID) is always 1


INFO 355
The other multiplicity is based on one
example of the qualified association
(one itemID associates with exactly
one ProductSpecification)
Could express as ‘there is one
ProductSpecification per itemID in the
ProductCatalog’
Week #5
38
Attribute Concepts
INFO 355
Week #5
39
Static Attributes and Methods


Static means the attribute or
method applies to the class,
not its instances (objects)
Analogous to the C concept of
static, if an attribute or method is
static, its name is underlined on
the class diagram

INFO 355
I can’t find a Visio way to show this;
add a stereotype of <<static>>?
Week #5
40
Derived Attributes

In a class diagram, attributes which
are derived (calculated) from other
attributes can be shown if they are
significant


INFO 355
Normalization doesn’t have to apply to
classes!
Put a front slash ‘/’ in front of the
attribute’s name to show you are
deliberately using a derived
attribute
Week #5
41
Derived Attributes

A Note box (text box with upper
right corner dog-eared) can be used
to show how the derived attribute is
calculated (Fig 5.5)
Task
duration = enddate - startdate
-startdate : Date
-enddate : Date
-/duration : Integer
Note box
INFO 355
Week #5
42
Attribute Data Types

As shown in the example on slide
35, each attribute can show its data
type, using the format



INFO 355
attributename: datatype
startdate: Date
This is easy for primitive, or
built-in data types; how deal with
non-primitive data types?
Week #5
43
Primitive vs. Non-Primitive Data

Recall primitive data (attribute)
types are the most basic ways to
represent data in a computer


INFO 355
Boolean, Date, Number, String, Time
More elaborate data types are
considered non-primitive
Week #5
44
Attribute Types
Boolean
(T/F)
Date
Address
Zip/Postal
Code
Number (int Phone
or real)
String
SSN
(Text)
Time
Money
Color
Shape
UPC or EAN
SKU
Enumerated
The primitive data types are in bold; others are non-primitive
INFO 355
Week #5
45
Non-Primitive Data Types

Use non-primitive if any of the
following guidelines apply:





INFO 355
Data has separate sections (phone)
There are operations associated with it
(SSN)
It needs other characteristics (start and
end date, for example)
It has any units (height, $, seconds)
Or any other complex concept (UPC)
Week #5
46
Non-Primitive Data Types

So a credit card number is a
non-primitive data type, since it has




INFO 355
Type of card (Visa/MC/Discover)
Fixed length depending on type
Validation rules based on first digit
Non-primitive data can be shown as
separate conceptual classes, or just
flagged as specific data types
Week #5
47
Non-Primitive Data Types
Format:
ClassName
-attribute:Data type
Example Class is called
ProductSpecification.
ProductSpecification
One attribute is called ‘id’, which is of
the non-primitive data type ‘ItemID’.
-id:ItemID
This is the equivalent:
1
ItemID
ProductSpecification
INFO 355
1
-id
Week #5
48
Attributes with Units


INFO 355
Things with units ($, ft., lb., etc.)
need to be modeled with
non-primitive data types
This helps support internationalization and conversion to other
measurement systems (e.g. dollars
to Euros, or English to metric units)
Week #5
49
Non-Primitive Data Types


INFO 355
Non-primitive data type classes
can be shown separately from
the rest of the class diagram (to
avoid clutter)
This is the only exception to the
need for every class to be explicitly
associated with at least one
other class, since the association
is implied
Week #5
50
Enumeration Classes for Attributes


«enumeration»
Rainbow
+red
+orange
+yellow
+green
+blue
+indigo
+violet
INFO 355

A class can be defined to contain
only the elements of a list or
enumerated attribute (p. 83)
The <<enumeration>> stereotype
is added before the class name
This is like using a class to define
any other non-primitive attribute

In Visio, based on the Data Type class
Week #5
51