Transcript Document 7280341

CS 432 Object-Oriented
Analysis and Design
Week 3
The Design Model
1
Primary Unified Process Models
Requirements
Use Case Model
specified by
<<trace>>
Analysis
Analysis Model
realized by
<<trace>>
distributed by
Design
Design Model
<<trace>>
Deployment
Deployment
Model
implemented by
<<trace>>
Implementation
Implementation
verified by
<<trace>>
Test
Test Model
2
What is Object-Oriented Design?

The bridge between a user’s requirements
and programming for the new system


“Blueprints”, or design models, are necessary
to build systems
An adaptive approach to development


Requirements and design are done
incrementally within an iteration
A complete set of designs may not be
developed at one time
3
Overview of Object-Oriented
Programs

Object-oriented programs consist of a set of
computing objects that cooperate to accomplish
a result




Each object has program logic and data encapsulated
within it
Objects send each other messages to collaborate
Most object-oriented programs are event-driven
Instantiation of a class creates an object based
on the template provided by the class definition
4
Object-Oriented Design
Models



Identify all objects that must work together to
carry out a use case
Divide objects into groups for a multilayer
design
Interaction diagrams describe the messages
that are sent between objects


Includes sequence and communication diagrams
Design class diagrams document and describe
the programming classes
5
Object-Oriented Design Models
(continued)



Statecharts capture information about the
valid states and transitions of an object
Package diagrams denote which classes
work together as a subsystem
Design information is primarily derived
from

Domain model class diagrams

Interaction diagrams
6
Object-Oriented Design Process



Create a first-cut model of the design class
diagrams
Develop interaction diagrams for each use case
or scenario (communication or sequence)
Update the design class diagrams


Method names, method parameters, attributes,
attribute data types, and relationship multiplicity
Partition the design class diagrams into related
functions using package diagrams
7
Design Classes and Design Class
Diagrams

Design class diagrams are extensions of domain
or analysis class model diagrams





Elaborate on attribute details
Define parameters and return values of methods
Define the internal logic of methods
A first-cut design class diagram is based on the
domain model and engineering design principles
Interaction diagrams are used to refine a design
class diagram as development progresses
8
Design Workflow
Use-Case
Model
Architectural Supplementary
Description
Requirements
(analysis view)
Deployment
Model
Analysis
Model
Subsystem
(complete)
Design a
Use Case
[Use-Case Engineer]
Architectural
Design
Design a
Subsystem
Use Case
Realization
(Design)
[Architect]
[Component Engineer]
Design a
Class
[Component Engineer]
Subsystem Architectural
(outlined) Description
(design view)
Interface
(outlined)
Interface
(complete)
Design Class
(complete)
Design Class
(outlined)
Analysis Class
(complete)
The Design Workflow

The input to the design workflow is the set of
analysis workflow artifacts


These artifacts are iterated and incremented until
they can be used by the programmers
A major aspect of this iteration and
incrementation is





The identification of operations or methods
The identification of method parameters and
parameter data types
The identification of attribute types, and
Their allocation to the appropriate classes
Relationships between classes – type and multiplicity
10
The Design Workflow (contd)

Many other decisions have to be made
as part of the design workflow, including




Choice of programming language
Deciding how much of existing information
systems to reuse in the new information
system
Level of portability
The allocation of each software component
to its hardware component
11
The Design Workflow (contd)

The case studies in this class are small-scale
information systems


The Unified Process was designed for
developing large-scale information systems



Under 5,000 lines of Java or C++ code in length
500,000 lines of code or more
These information systems are at least 100 times
larger than the case studies presented in this class
Therefore, some aspects of the Unified Process
are inapplicable to our case studies
12
The Design Workflow (contd)

During the analysis workflow, a large
information system is partitioned into analysis
packages


Each analysis package consists of a set of related
classes that can be implemented as a single unit
Example:


Accounts payable, accounts receivable, and general ledger
are typical analysis packages
The concept underlying analysis packages is:


It is easier to develop smaller information systems
than larger information systems
A large information system will be easier to develop if
it can be decomposed into independent packages 13
The Design Workflow (contd)


The idea of decomposing a large workflow
into independent smaller workflows is
carried forward to the design workflow
The objective is to break up the upcoming
implementation workflow into
manageable pieces

Subsystems
14
The Design Workflow (contd)

Reasons why subsystems are utilized
It is easier to implement a number of
smaller subsystems than one large
system
 If the subsystems are independent,
they can be implemented by
programming teams working in parallel


The information system as a whole can
then be delivered sooner
15
The Design Workflow (contd)

The architecture of an information system
includes




The various component modules
How they fit together
The allocation of components to subsystems
The task of designing the architecture is
specialized

It is performed by an information system
architect
16
The Design Workflow (contd)

The architect needs to make trade-offs


Every information system must satisfy its
functional requirements (the use cases)
It also must satisfy its nonfunctional
requirements, including



Portability, reliability, robustness, maintainability,
and security
It must do all these things within budget and
within the time constraint
The architect must assist the client by
laying out the trade-offs
17
The Design Workflow (contd)

It is usually impossible to satisfy all the
requirements, functional and
nonfunctional, within the cost and time
constraints


Some sort of compromises have to be made
The client has to



Relax some of the requirements;
Increase the budget; and/or
Move the delivery deadline
18
The Design Workflow (contd)

The architecture of an information system is
critical




The requirements workflow can be fixed during the
analysis workflow
The analysis workflow can be fixed during the design
workflow
The design workflow can be fixed during the
implementation workflow
But there is no way to recover from suboptimal
architecture

The architecture must immediately be redesigned
19
Traditional versus ObjectOriented Design

In the traditional paradigm, the design
phase consists of

Architectural design


The information system is decomposed into
modules
followed by
Detailed design

Algorithms and data structures are designed for
each module
20
Traditional versus ObjectOriented Design (contd)

Classes are modules

Much of traditional architectural design is performed as part of
class extraction in the object-oriented analysis workflow
21
Some Fundamental Design
Principles

Encapsulation


Object reuse


Each object is a self-contained unit containing
both data and program logic
Standard objects can be used over and over
again within a system
Information hiding


Data associated with an object is not visible
Methods provide access to data
22
Some Fundamental Design
Principles (contd)

Navigation visibility


Coupling



Measures how closely classes are linked
Want LOW coupling
Cohesion



Describes which objects can interact with each other
Measures the consistency of functions in a class
Want HIGH cohesion
Separation of responsibilities

Divides a class into several highly cohesive classes
23
University System
Use Case Diagram
24
Analysis Class Diagram
25
How to Create Design-Level
Class Diagrams

To create and evolve a design class
diagram, you need to iteratively model:







Classes
Responsibilities
Associations
Inheritance relationships
Composition associations
Association classes
Interfaces
26
Classes





An object is any person, place, thing, concept, event,
screen, or report applicable to your system.
Objects both know things (they have attributes) and
they do things (they have methods).
A class is a representation of an object and, in many
ways, it is simply a template from which objects are
created.
Classes form the main building blocks of an objectoriented application.
Although thousands of students attend the university,
you would only model one class, called Student, which
would represent the entire collection of students.
27
Classes

Classes are typically modeled as rectangles
with three sections:



the top section for the name of the class,
the middle section for the attributes of the class,
and the bottom section for the methods of the
class.
Three sections:
Name:
Attributes:
Methods:
UML Class
ReferenceBook
Class Name
Begins with a capital letter
Every other word is capitalized.
No blanks
28
Attributes & Methods

Attributes are the information stored about
an object (or at least information temporarily
maintained about an object)


Students have student numbers, names,
addresses, and phone numbers.
Methods are the things an object or class do.


Students also enroll in courses, drop courses, and
request transcripts.
You should think of methods as the objectoriented equivalent of functions and procedures.
29
Responsibilities or Methods


How to find responsibilities which are
methods?
Ask these questions:






How am I going to be used?
How am I going to collaborate with other
classes?
How am I described in the context of this
system's responsibility?
What do I need to know?
What state information do I need to
remember over time?
What states can I be in?
30
Identifying Responsibilities
or Methods


Methods usually correspond to queries
about attributes (and sometimes
association) of the objects.
Methods are responsible for managing the
value of attributes such as query,
updating, reading and writing.
31
Level of Detail






An important consideration the appropriate level of detail.
Consider the Student class modeled which has an attribute called Address.
Notice how the Address class has been modeled to include an attribute for
each piece of data it comprises and two methods have been added: one to
verify it is a valid address and one to output it as a label (perhaps for an
envelope).
By introducing the Address class, the Student class has become more
cohesive.
The Address class could now be reused in other places, such as the
Professor class, reducing your overall development costs.
A student may live in a different location than his permanent mailing
address, such as a dorm¾information the system may need to track.
Having a separate class to implement addresses should make the addition
of this behavior easier to implement.
32
Level of Detail in a Design-Level
Class Diagram
Class information: visibility and scope
33
Constructors




Constructor methods provide a way of initializing an
object.
A constructor method has the same name as its class
and is automatically invoked by the object-oriented
programming environment (e.g., the Java Virtual
Machine) when new instance objects of a class are
created.
As the return type of the constructor is always the same
as the class and the constructor’s name, the return type
is often omitted from the UML visual representation of
the constructor.
Since a constructor may also have parameters like any
method, the parameters of a constructor can be used to
assign initial values to the attributes of the object.
34
Constructor Example

In programming source code, new instance objects are
created by using the new command, which executes
any code in the constructor, and returns the new object.
// Create a new account object with id 12 and
// assign it to the acct variable.
Account acct = new Account(12);
// Get the id of the new account object.
int id = acct.getId();
35
Refactoring or
Class Normalization



A process in which you refactor the behavior of classes
to increase their cohesion and/or to reduce the coupling
between classes.
A seminar is an offering of a course, for example, there
could be five seminar offerings of the course "CS 208
Introduction to Computer Science."
The attributes name and fees were moved to the Course
class and courseNumber was introduced.
36
Course with Accessor and
Mutator Methods

Depicts Course as it would appear with its
getter and setter methods modeled
37
Associations
(Binary Relationships)


Objects are often associated with, or related to, other
objects.
Several associations exist:







Students are ON WAITING LIST for seminars
Professors INSTRUCT seminars
Seminars are an OFFERING OF courses
A professor LIVES AT an address
Associations are modeled as lines connecting the two
classes whose instances (objects) are involved in the
relationship.
When you model associations in UML class diagrams,
you show them as a thin line connecting two classes
The label, which is optional, although highly
recommended, is typically one or two words describing
the association.

For example, professors instruct seminars.
38
Associations (contd)



UML Notation:
You also need to identify the multiplicity
of an association.
The multiplicity of the association is
labeled on either end of the line, one
multiplicity indicator for each direction
39
Multiplicity Indicators
Indicator
Meaning
0..1
1
Zero or one
One only
0..*
1..*
n
Zero or more
One or more
Only n (where n > 1)
0..n
Zero to n (where n > 1)
1..n
One to n (where n > 1)
40
Multiplicity: 1-to-1
(Bank Example)

This multiplicity simply indicates that one
Customer object owns exactly one Account
Object, and the Account is owned by exactly
one customer object.
41
Multiplicity: Many-to-1
(University Example)
42
Inheritance Relationships






Similarities often exist between different classes.
Very often two or more classes will share the same
attributes and/or the same methods.
Because you don’t want to have to write the same code
repeatedly, you want a mechanism that takes advantage
of these similarities.
Inheritance models “is a” and “is like” relationships,
enabling you to reuse existing data and code easily.
When A inherits from B, we say A is the subclass of B
and B is the superclass of A.
The UML modeling notation for inheritance is a line with
a closed arrowhead pointing from the subclass to the
superclass.
43
Inheritance hierarchy
44
Guidelines For Identifying Supersub Relationships: Top-down



Look for noun phrases composed of
various adjectives on class name.
Example, Military Aircraft and Civilian
Aircraft.
Only specialize when the sub classes have
significant behavior.
45
Guidelines For Identifying Supersub Relationships: Bottom-up



Look for classes with
similar attributes or
methods.
Group them by
moving the common
attributes and
methods to super
class.
Do not force classes
to fit a preconceived
generalization
structure.
46
Guidelines For Identifying Supersub Relationships: Reusability



Move attributes and
methods as high as
possible in the
hierarchy.
At the same time do
not create very
specialized classes at
the top of hierarchy.
This balancing act
can be achieved
through several
iterations.
47
Guidelines For Identifying Super-sub
Relationships:
Multiple inheritance



Avoid use of multiple
inheritance.
It is also more
difficult to understand
programs written in
multiple inheritance
system.
Java does not support
multiple inheritance
but C++ does.
48
Multiple Inheritance


One way to achieve the
benefits of multiple inheritance
is to inherit from the most
appropriate class and add an
object of other class as an
attribute.
In essence, a multiple
inheritance can be
represented as an aggregation
of a single inheritance and
aggregation. This meta model
reflects this
situation
Single Inheritance
Multiple Inheritance
Aggregation
49
Abstract Classes
& Inheritance






The Person class is abstract: objects are not created
directly from it, and it captures the similarities
between the students and professors.
Abstract classes are modeled with their names in italics,
as opposed to concrete classes, classes from which
objects are instantiated, whose names are in normal
text.
Both classes had a name, e-mail address, and phone
number, so these attributes were moved into Person.
The Purchase Parking Pass method is also common
between the two classes.
By introducing this inheritance relationship to the model,
the amount of work to be performed was reduced.
Instead of implementing these responsibilities twice,
they are implemented once, in the Person class, and
50
reused by Student and Professor.
Aggregation Relation


An aggregation is an association that supports a
loose relation between objects in which one object is
considered a “part of” the other object in the relation.
Consider the relation between a Computer and a Printer.





“a Computer may be attached to 0 or more Printers;
at any one point in time a Printer is connected to 0 or 1
Computer;
over time, many Computers may use a given Printer;
the Printer may exist even if there are not attached
Computers
the Printer is, in a very real sense, independent of the
Computer.”
51
Composition Relation


A composition relation is a stronger form of
aggregation that should be used when the part class
has no independent existence from the whole.
For example, since a customer’s account would not exist
in a system without the customer, it qualifies as a
composite relation. In this capacity an Account should
be though of as being part-of a customer.
52
Composition Relation (contd)

Another example:

A building is composed of one or more
rooms, and then, in turn, that a room may be
composed of several subrooms (you can have
recursive composition)
53
Customer Order from a Retail Catalog
Video Store Example
Multiplicity
Customer
Simple
1
Aggregation
Class
Rental Invoice
Abstract
Class
Rental Item
1..*
1
0..1
Composition
Simple
Generalization
Association
Checkout Screen
DVD Movie
VHS Movie
Video Game
Association Classes


The association between the two classes may be
modeled as a class
You use this when you have many-to-many
relationships like the association class in an ERD
56
Interfaces




The C# and Java programming languages allow for the creation of
interface entities that capture a collection of methods
representing a public interface. (C++ uses abstract classes)
An interface is similar to an abstract class that does not have any
concrete methods at all.
An interface is simply a collection of method signatures.
A List interface provides a nice example of the benefits of using
interfaces.
57
Interfaces (contd)
58
Interfaces (contd)

Interfaces are implemented, “realized” in UML parlance,
by classes and components


To realize an interface a class or component must implement
the operations.
Any given class or component may implement zero or more
interfaces and one or more classes or components can
implement the same interface.
«interface»
ChocAn
*
*
Report
*
ServiceCatalog
MemberReport
1
DBMgr
1
1
ManagerReport
*
59
Polymorphism



Polymorphism means many forms and
concerns the ability of an object to dynamically
take on a different form depending on the
runtime context.
Although technically correct, this definition is a
bit misleading since the object does not exactly
change form, but instead the way in which it’s
viewed by other objects changes.
We should also note that polymorphism involves
the behavior of objects.
60
Polymorphism (contd)



Consider the following three class fragments taken from
a graphical user interface application.
The abstract Component class represents a generic
component that captures the common functionality of
graphical widgets that can be displayed on a
canvas/window.
The Button and TextField classes share the common
functionality, having an (x, y) position in the window
and responding to messages requesting them to paint
themselves on the canvas, erase themselves, and move
themselves from one location to another.
61
Polymorphism (contd)
62
Polymorphism (contd)

Assume we are given a List of component objects which
we wish to draw on the screen. The following pseudocode would accomplish this desire:




ForEach component In the list Do
Send the component a paint() message;
Polymorphism concerns the fact that although we are
sending messages to Component objects, the actual
method that handles the message will be executed as
part of a Button or TextField object.
When an object receives a message, the most specific
method of it’s parent class or it’s ancestors will execute.
However, the key point isn’t what method executes, but
what the type of object is receiving the message.
63
Signatures and Method
Overloading



A significant difference between procedural functions and objectoriented methods concerns method overloading, which is based on
the concept of signatures.
A method signature is the combination of its visibility, name,
parameter cardinality (number of parameters), the types of these
parameters, and its return type.
For example, all of the methods in the following list have different
signatures:






+getId():int OR -getId():int
// Visibility differs
+getBalance():int
// Different name
+withdraw(amount:int):void
// Different name
+withdraw(amount:float):void
// Parameter type
differs
+withdraw(id: int,amount:float):void// Different
parameter cardinality
Note that current object-oriented programming languages require
that all methods in the same class and with the same name have
the same return type.
64
Overloading




An overloaded method occurs when two or more methods with
the same name in the same class have different signatures.
For example, the Withdraw method in the following example class
is overloaded.
In this example the withdraw method is overloaded since the
parameter type of the single parameter is different in each method.
When an object of this Account class receives a withdraw method,
the object-oriented execution environment (e.g., the Java Virtual
Machine) will dynamically select and execute the withdraw method
65
with the corresponding parameter type.