Detail (mid-level part) Design:
Mid-Level OO Design – Designing Classes
• Detailed Design starts with Software Architecture
Design (SAD) and fill in the details of the architectural
components - - - may cause re-work on SAD, too.
• There is no “fixed” boundary between SAD and Detailed
Design - - - it is not strictly sequential & we may iterate
back and forth.
• Detailed Design has 2 levels:
– Mid-level (this lecture set)
– Low-level (later lecture)
• Detailed Design may be:
– Static: non-execution oriented (mostly this lecture set)
– Dynamic: execution oriented (next lecture set)
Detailed Design
Detailed Design Process
Analyzed
SRS
Analyze SRS and SAD
Swft Engr. Design
SAD
SRS
Design
Analysis
Evaluate Detailed
Design Alternatives
Architectural
Design
Detail
Design
Generate/Improve Detailed
Design Alternatives
Design
Doc.
Select Detailed
Resolution
[else ]
[selected ]
Finalize Detailed
Design
Detailed
Design
Doc
Relative “Levels” of Mid-Level to
Detailed-Level Design
1. Conceptual Level :
–
the class or subcomponent should express the
“responsibilities” and “attributes” of the
subcomponents or Classes
2. Specification Level:
–
The subcomponent’s or Class’ precise “interface”
and associations between/among classes or
subcomponents are specified
3. Implementation Level:
–
The concrete class or subcomponent that
“implements” the interface, with instance variables
and algorithms for the code, are described
Mid-Level Detailed Design
The unit of design is at the Compiled
•
–
–
–
•
Unit or at a Class level:
Properties
Responsibilities
Relationships
The mid-level design specifications include (DeSCRIPTR):
1.
2.
3.
4.
5.
6.
7.
8.
Decomposed mid-level components
States of these components
Collaboration among these mid-level components
Responsibilities of each of these mid-level components to perform some task
or maintain data
Interfaces that these mid-level components use to communicate with each other
Properties (such as security, reliability, performance) of these components must
be specified.
Transition of states and state behavior of these components are described
Relationships (inheritance, aggregation, composition, etc.) among the
components
Low-Level Detailed Design
•
In contrast to mid-level, low level detailed design
fills in the details for later programming purpose
(PAID):
1.
2.
3.
4.
Packaging of the code into compilation unit and libraries
is decided
Algorithms are described in detail steps
Implementation issues such as visibility and accessibility
of entities and low level relationships among entities are
described
Data structures and data types are specified
Sample: Detailed Design Document Content
1.
Mid-Level Design Models (in the form of Class diagrams,
sequence diagrams, state transition diagrams, etc.)
2.
Low-Level Design Models (specific algorithms, data
structures, implementation guidelines for non-functional
attributes such as security or performance, packaging)
3.
Mapping between Models (showing how the models
are related)
4.
Description of Design Rationale (describing the
design decisions made and factors that contributed
to the decision) very important
5.
Glossary of terms and acronyms used
average importance
Static Descriptions (Design)
(based on text book & thus OO Biased )
Rest of this lesson lecture notes will focus on the following:
• Associations Among Classes
–
–
–
–
Generalization and inheritance (“is a” relationship)
Interfaces of classes
Aggregation (“part-whole” relationship) & Composition
Adornments for more complex association
• Classes
– More properties about attributes and operations may be
specified:
• With { } to indicate constraint
• Visibility and Accessibility indicator
• Class or Instance variables
Class Generalization/Inheritance & Association
•
Generalization is a “parent-child” or “sub-typing” relation between
classes ---- close to the notion of abstraction
– e.g. dog “is a” animal
•
Association represents a more general relationships between
instances of classes
– A person “works” for a company; company “has” a number of buildings
fish
person
whale
salmon
Generalization
1-- *
Works for
Association
0..2
company
Multiple Inheritance
salmon
fish
mammal
size:int
breathe( )
move( )
size:int
breathe( )
move( )
whale
dog
Consider: Whale really “is a” fish at the same time “is a” mammal?
Which “move ( )” or breathe( ) operation should be inherited ?
Abstract Class for mid-level design
• In design we May Not fill in all the details of a design.
– Abstract class is an example of such a situation.
– An Abstract Class is a class that can not be instantiated
because it contains a method or operation without the body.
• It is useful as a parent-class which is inherited by some childclass that has “implemented” the method that has no body.
<<abstract>>
animal
If we do not use
stereotype descriptors,
then we must italicize
to show abstract class
weight: int
origin: string
move ( ) {abstract}
fish
dog
Each of the sub-classes:
- fish
- dog
- bird
will have a different move( )
operation that needs to be
“implemented” differently
bird
We use abstract class as a design for the purpose of enforcing a certain
set of common attributes and operations that must be inherited by all descendants
( You may think of this as a “restricted or controlled” polymorphism )
Interfaces for mid-level design
• Interfaces are important in design because it shows the
relationship of dependencies (of features - attributes or/and
operations)
• Earlier we have discussed the provided and the required interfaces,
along with the “ball” and the “cup” to indicate the provider of the
feature versus the dependent of that feature.
• Here we show another notational approach
temperature
gauge
temperature
gauge
temperature
gauge
Provided
interface
<<interface>>
temperature
temp: object
Required
interface
thermostat
UpdateTemp (temp: object)
GetTemp ( ): object
thermostat
thermostat
Further notes on Interface
• In Java programming, “Interface” contains:
– constants and
– abstract methods
• abstract method is just a signature that has no implementation
• Interfaces in Java programming provides a certain
amount of polymorphism through different classes
that “implement” the interface
• Also note that we can use interface to perform
“information encapsulation” by making the data only
accessible through the interface method.
More “Specifications” for Mid-Level design
• More properties may be “specified” for the
attributes and operations using { }, constraint
Department
DepName: string {constant}
Person: employee:
Memlist: employee[*] {ordered}
addEmpl (person:employee)
delEmpl (person:employee) {synchro}
Department name is a string constant.
Memlist is an ordered list.
delEmpl is an operation that must be
synchronized.
Recall from (p. 202-203 of your textbook):
Attribute format name : type [multiplicity] = initial value
Operation format - name (parameter list) : return-type-list
“Visibility” Characterization for Mid-Level Design
• Visibility or accessibility constraints on attributes and
operations should be thought of at mid-level design:
visible
– Public (+): visible and accessible anywhere by everyone
– Package (~): visible and accessible within the package where
the class appears
– Protected (#): visible and accessible within the class and all
its sub-classes
– Private (-): visible and accessible only within the class
hidden
Department
+ Name: string {constant}
:
+ Memlist: Employee[*]
(ordered}
# address: string
Also, go back to the interface diagram
and see if you would make the attribute,
temp, to have a “private” designation --why ?
Class (global) and Instance (local) notions for
mid-level -design
• During mid-level design, we need to specify which
attribute and/or operation should be “global” in nature
versus “local” in nature.
– Class level : one copy and sharable among all instances of the
class. (sometimes called “static” variable and is underlined)
• A constant such as Pi may be a class variable that is shared by all
objects
figure
+pi : double {constant}
– Instance level: a separate copy for each instance of the class
(or object) and the value of the copy is specific to only that
instance.
• An employeeName may be an instance variable that is read in by
different objects and varies depends on which employee record is
read by which object.
Differentiating “Part-Whole” Relationship Concepts
following has always been a tough distinction to remember:
• Aggregation is a “part-whole” association.
• Composition is a “special kind” of aggregation where
the part may only belong to one whole at any time.
subdivision
Replenish-list
Sold-item
list
house
1…*
item
1…*
kitchen
An item may belong to the
replenish-list and may
also be on the sold-item
list.
Is the aggregation symbol
A kitchen belongs to only one house,
which in-turn sits in only one
subdivision.
is the composition symbol.
Transitivity Property
• Note that some relationship may look like an
aggregation, but not. Aggregation should be
transitive.
1. Person Z is biologically-related to father y; father y is biologically
related to family x. The person Z is biologically related to the family x.
(this is a transitive relationship --- thus an aggregation)
2. Joe is a member of a church y; church y is a member of entities that
don’t pay taxes. Is Joe a member of entities that don’t pay taxes? --- but
Joe may pay tax! (be careful with is “a member of” versus “possess the
characteristics” of )
Complex Association
• Sometimes association itself may be
complex and needs a class, which has
attributes and operations pertinent to the
association.
– We can use an Association Class to provide the
information pertinent to the association that does
not belong to either of the associated objects.
<< sold to >>
Items
customer
Sales
date
Item-list
sales-person
Further describes the sold-to association
More adornments for association
• Qualifiers : one or more association attributes, which
together with an instance of the qualified class,
picks out the instances of the other class that
participate in the association.
• Navigability: indicates if an instance of a class can
access (one way or two ways) an instance of the
associated class.
• Visibility: indicates the attribute that is used for
accessing (association) between the two instances
of classes is public, private or protected.
Association Qualification adornment
Univ. Directories
student name
student id#
0..*
1. Note that given a university
directory, with the qualifier of
student name and id#, there is
either such a student or none
2
0..1
Student
Given a student there may be
no entry in any of the university
directories (error) or one or more
entries in different university
directories
Association Navigation &Visibility adornments
Navigation of student accesses classes, but not vise versa
Student
Class
X
0..*
Navigation of
Class and Building
are bi-directional and
are done through
accessing the public
attribute
1
+ class_id
class_id and
building_id are
publicly visible
+ building_id
Building
“Coming Up with” or Drafting the Mid-Level
Design
• This discussion is primarily OO-based; thus the aim is
to come up with mid-level design of classes
– Creational technique :
• Decomposition/Composition based on functionality, “quality”
(non-functional) attributes, or both (just as we did for High Level
Design)
– Transformational technique:
• Converting the conceptual (problem) model to a draft design
model (much as what was done with High Level Design)
• Requires a good SRS and SAD or
• Transforming a previously completed, similar design
For experienced people, they usually have some previous, similar design in
their brain and would draw upon that first--- and then create more
Creational Technique
1.
2.
Generate a Design Story (based on what you think are the most important
aspects of the solution); list the key “themes” in the story.
Use the themes and “brainstorm.” For each theme identify and list: Generating
•
Entities in charge or involved in the theme
Classes from
•
Things that interact with the solution part of theme
Themes
•
•
From the list in step 2, generate “candidate” classes.
3.
•
•
4.
List their names
List their responsibilities
Evaluate the list of classes:
•
Discard those that seem to be unclear in name or responsibilities
•
Rework those classes that have overlapping responsibilities
•
Discard those that seem to be “out of scope”
5.
Draft an initial Class diagram showing
•
•
6.
Things whose data needs to be stored
Any structure or collections of entities
Classes, each with attributes and operations
Associations among classes
Developing
a list of
classes and
the class
diagram
Review and
Check the Class Diagram:
improve the
•
Check each class for missing/inaccurate attributes and operations class
•
Combine common attributes and operations into a super-class, if diagram
necessary
•
Look for “required’ and “provided” components (using design patterns)
Transformational Technique
1.
2.
3.
4.
5.
6.
7.
Start with the conceptual model (requirements and high level
design) and convert the actors in the conceptual model to
interface classes.
Add data collection classes for all those actors whose data
needs to be recorded
Add a start-up class to start the execution of the solution.
Convert controllers and coordinators in the conceptual
model into classes and add any that needs to be included as
control and coordination classes.
Data types with complex structure in the conceptual model
needs to be converted to classes
Decide on whether container classes (abstract data structure)
are needed, include them if necessary
Add Associations and interfaces; draft the class diagram
Some Static Modeling Heuristics
for mid-level design
1. Responsibility driven decomposition
2. Inheritance
3. Delegation
Responsibilities Driven Decomposition
•
Responsibility (functionality) is an obligation to:
– Perform a task (operational responsibility)
– Maintain some data and non-functional information (data responsibility)
•
Responsibility driven decomposition
– Generating lower level operational responsibility components based on
decomposing the high-level operational responsibilities
– Generating lower level data responsibility components based on
decomposing the high-level data responsibilities.
•
Responsibility and design principles (cohesion and coupling):
– Assign a module (class) with at most one operational responsibility and one
data responsibility - - - cohesion ----practical ?
– Assign complementary data and operational responsibilities together- - cohesion
– Make sure module responsibilities do not overlap - - - cohesion and
coupling
– Do not place extra operational and data elements into a module - - cohesion and coupling
– Make sure that all needed operational and data elements are included in the
module to fulfill the responsibilities - - - cohesion and coupling
Starting a Design (used for discussion of “inheritance” and
“delegation” --- later)
Consider designing a component dealing with a bank account.
A bank account handles the deposit and withdrawal of that account.
Each bank account is owned by one to three people. Information about a
bank account such as owner, open date, account type must be kept and
maintained.
Account
amt : real
total_amt:real
act_num: int
Deposit (amt :real, act:int )
Wdraw (amt :real, act :int)
Note: What should we do with account information
such as account type or owner ?
Capture the Ownership Information &
Relationship
Owner_Info
Account
amt : real
total_amt:real
act_num: int
1..3
*
addr : string
Tel : int
ss_num: int
B-date: date
Act_num : int
.
Deposit (amt : real, act:int )
Wdraw (amt : real, act ;int)
setaddr ( )
getaddr ( )
Account_info
.
.
Discussion on Cohesion and Coupling
Consider designing a component dealing with bank account and
account information
Account
amt : real
total_amt:real
a_num: int
deposit(amt : real, a_num:int )
wdraw (amt : real, a_num ;int)
Account_Info
0..1
owner: string
1 co-owner: string
act_type:integer
act_st_date: date
act_num: int
getOwner (act_num: int) string
setOwner (act_num:int, owner:string)
.
.
Should these be combined as one Class or left separately?
(cohesion and coupling trade-off ?)
More Discussion on Cohesion and Coupling
(cont.)
How should these Classes be combined, if at all?
Account
amt : real
total_amt:real
a_num: int
deposit(amt : real, a_num:int )
wdraw (amt : real, a_num ;int)
Account_Info
owner_name: string
act_type: int
act_st_date: date
act_num: int
Owner_Info
name: string
addr : string
tel : int
ss_num: int
b-date: date
getOwner (act_num: int) string
.
setOwner (act_num:int, owner:string) setaddr ( )
.
.
.
getaddr ( )
Should these be somehow combined or left separately?
(cohesion and coupling trade-off ? – and db performance ?)
.
.
Inheritance
• Remember:
– Inheritance is a generalization relationship
between a super-class and its sub-classes.
– Inheritance provides a mechanism for re-use in
mid-level designs.
1. Combine common attributes and operations in similar classes into a
super-class
2. Use inheritance only when there is a generalization relationship
between the super-class and its sub-classes.
Generalized Account_Info (from earlier
example) for Inheritance?
• Instead of act_type attribute in the Account_Info
Class to differentiate the different accounts, should
we have designed a “generalized” Account_Info class
and have each account type inherit from the
generalized class:
– Personal checking account with all kinds of rules such as
free checking for 6 months, overdraft fee, etc.
– Personal money market account with no minimum deposit,
but gives only regular interest
– Personal money market account with minimum of $50,000
deposit gets regular interest plus .25% more.
– Small Business account
.
.
Delegation
• Delegation is a mechanism to decompose
the responsibilities and assign some of the
responsibilities to different classes.
• This allows classes to re-use a class that has
been given a set of responsibilities that is
needed by other classes.
So ---- based on delegation, should we keep
Account and Account_Info separately ?