Beruflich Dokumente
Kultur Dokumente
1.1
1.2
1.3
1.4
1.5
OO Programming
Designing Programs
Software Development Solving Problem
Place Order
Inventory
Shipping
Descriptions of problem
(Human: Requirements)
Business Process
Problem
Space
Natural Language
Descriptions of solution
Computer System
4
Solution
Space
Descriptions of problem
(Human: Requirements)
Business Process
Problem
Space
Natural Language
Descriptions of solution
(Human: Designing Programs)
Execution of program
Computer System
Object Oriented Analysis and Design
Solution
Space
Procedural Programming
This programming paradigm is essentially an
abstraction of machine /assembly language.
Program is organized around procedures.
Focus on data structures, algorithms and
sequencing of steps
Struct account {
char name;
int accountId;
float balance;
float interestYTD;
char accountType;
};
or function.
Data
NJ
a gap
Hudson river
Procedure
Analysis
NY
NJ
a gap
Hudson river
Design
NY
10
11
C++ code:
Class BankAccount {
private:
float balance;
float interestYTD;char * owner;
int account_number;
public:
void Deposit (float amount) {...}
float WithDraw (float amount) {}
bool Transfer (BankAccount & to, float amount) {}
};
Object Oriented Analysis and Design
12
13
14
Data Structure
---Shape.h -------------------------------------------Enum Shape {circle, square};
struct Shape {
ShapeType itsType;
};
---Circle.h -------------------------------------------struct Circle {
Shape itsType;
double itsRadius;
Point itsCenter;
};
---square.h ------------------------------------------struct Square {
Shape itsType;
double itsSide;
Point itsTopLeft;
};
15
Function
---drawAllShapes.c -------------------------------------------typedef struct Shape *ShapePointer;
Void DrawAllShapes (ShapePointer list[], int n) {
int I;
for (i=0; i<n; i++) {
struct Shape* s = list[i];
switch (s->itsType) {
case square:
DrawSquare((struct Square*)s);
break;
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}
16
17
Not rigid
Not Fragile
Not Immobile
18
19
20
C ++
The UML
Late 1980s
1967
1991
1972
Smalltalk
1996
Java
21
2000+
???
Stability
A small change in requirements does not mean
massive changes in the system under development
Adaptive to change
22
Basic concepts of OO
23
Object
Class
Message
Basic Principles of Object Orientation
Abstraction
Encapsulation
Inheritance
Polymorphism
Interface and Abstract Class
24
What Is an Object?
Informally, an object represents an entity,
either physical, conceptual, or software.
Physical entity
Truck
Conceptual entity
Software entity
Chemical
Process
Linked List
25
Attributes
State is represented by
attributes and
relationships.
Behavior is represented
by operations, methods,
and state machines.
Object
Operations
26
Professor Clark
Name: J Clark
Employee ID: 567138
Date Hired: July 25, 1991
Status: Tenured
Discipline: Finance
Maximum Course Load: 3 classes
Object Oriented Analysis and Design
Professor Clark
27
tC
ou
rs
e
Su
bm
itF
in
alG
ra
de
s(
)
Ac
c
Professor Clark
Se
tM
ax
Lo
ad
()
TakeSabbatical()
Professor Clark
28
Of
fe
r
in
g
()
29
30
What Is a Class?
A class is a description of a set of objects that
share the same properties and behavior.
An object is an instance of a class.
Class: Professor
Objects
Professor
Attributes
Professor Smith
Professor Mellon
Professor Jones
Operations
31
- name
- employeeID : UniqueId
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()
A Sample Class
Class: Automobile
Methods:
Data Items:
manufacturers name
model name
year made
color
number of doors
size of engine
etc.
32
Objects
Professor Mellon
J Clark :
Professor
Object Oriented Analysis and Design
abstracting
instancing
Objects
To computer World
33
Class: Professor
Professor
- name
- employeeID : UniqueId
- hireDate
- status
- discipline
- maxLoad
+ submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()
What Is an Attribute?
An attribute is a named property of a class
that describes a range of values instances
of the property may hold.
A class may have any number of attributes or no
attributes at all.
Student
Attributes
- name
- address
- studentID
- dateOfBirth
34
name: M. Modano
address: 123 Main
studentID: 9
dateofBirth: 03/10/1967
Student
Objects
- name
- address
- studentID
- dateOfBirth
name: D. Hatcher
address: 456 Oak
studentID: 2
dateofBirth: 12/11/1969
35
What Is an Operation?
An operation is the implementation of a
service that can be requested from any
object of the class to affect behavior.
A class may have any number of operations
or none at all.
Student
Operations
+ get tuition()
+ add schedule()
+ get schedule()
+ delete schedule()
+ has pre-requisites()
36
Professor
37
- name : String
- age : int
- speciality : String
+getName() : String
+getAge() : int
+getSpeciality() : String
38
What is a message?
A specification of a communication between objects
that conveys information with the expectation that
activity will ensue
One object asks another object to perform an
operation.
What is your name?
Professor wang
wang.getName()
39
Ca
lc u
la t
eO
r
calculateOrderTotal()
de
r
To
ta
l()
orderID
date
salesTotal
tax
shipDate
Message
OrderEntryForm
Order
The class Order has the responsibility to calculate the total dollar
value.
Object Oriented Analysis and Design
40
41
Polymorphism
Inheritance
Encapsulation
Abstraction
Object Orientation
What Is Abstraction?
Abstraction can be defined as:
Any
Abstraction
Emphasizes relevant characteristics.
Suppresses other characteristics.
BriefCase
- Capacity
- Weight
+ open()
+ close()
Object Oriented Analysis and Design
42
Example: Abstraction
Professor
Student
43
What Is Encapsulation?
Encapsulation means to design, produce, and
describe software so that it can be easily used
without knowing the details of how it works.
Also known as information hiding
An analogy:
When you drive a car, you dont have know the
details of how many cylinders the engine has or
how the gasoline and air are mixed and ignited.
Instead you only have to know how to use the
controls.
Object Oriented Analysis and Design
44
What Is Encapsulation?
Hide implemmentation from clients
clients
depend on interface
Improves Resiliency
Object Oriented Analysis and Design
45
Encapsulation Illustrated
SetMaxLoad(4)
ra
de
s()
Su
bm
itF
in
alG
Professor Clark
needs to be able
to teach four
classes in the
next semester.
Professor Clark
Se
tM
ax
Lo
ad
(
Ac
ce
pt
Co
ur
se
Of
fe
rin
Name: J Clark
Employee ID: 567138
g()
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad:4
)
TakeSabbatical()
46
Interface
Client
Deposit()
Withdraw()
Transfer()
Deposit() {}
Withdraw() {}
Transfer() {}
Implementation details
which are unvisuable for
claent.
Object Oriented Analysis and Design
47
What Is Inheritance ?
Inheritance a way of organizing classes
Term comes from inheritance of traits like
eye color, hair color, and so on.
Classes with properties in common can be
grouped so that their common properties
are only defined once.
Is an is a kind of relationship
48
An Inheritance Hierarchy
Vehicle
Automobile
Sedan
Motorcycle
Sports Car
School Bus
Bus
Luxury Bus
49
Superclass
(parent)
+ withdraw()
+ createStatement()
Inheritance
Relationship
Subclasses
Checking
Savings
Descendents
Object Oriented Analysis and Design
50
Animal
Multiple Inheritance
Airplane
Helicopter
Bird
Wolf
51
Horse
Polymorphism
Polymorphismthe same word or phrase can
be mean different things in different contexts
Analogy: in English, bank can mean side of a
river or a place to put money
In Java, two or more classes could each have
a method called output
Each output method would do the right thing
for the class that it was in.
One output might display a number whereas
a different one might display a name.
52
What Is Polymorphism?
The ability to hide many different
implementation behind a single interface.
Manufacturer A
Manufacturer B
OO Principle:
Encapsulation
53
Manufacturer C
Example: Polymorphism
Get Current Value
get
Cu
rre
nt
get
Cu
rre
ntV
alu
e
Val
ue(
)
Stock
Bond
54
()
get
Cu
rre
ntV
alu
e
Mutual Fund
()
What is an Interface?
An interface is a collection of operations that specify
a service of a class or component.
Interfaces formalize polymorphism
Interfaces support plug-and-play architectures
<<Interface>>
Shape
What
Tube
How
Pyramid
draw()
move()
scale()
rotate()
Cube
Realization relationship
Object Oriented Analysis and Design
55
Elided/Iconic
Representation
(lollipop)
Pyramid
Shape
Cube
Canonical
(Class/Stereotype)
Representation
Tube
<<Interface>>
Shape
draw()
move()
scale()
rotate()
(stay tuned for realization
relationships)
56
Pyramid
Cube
Abstract class
{abstract}
Abstract operation
draw () {abstract}
Circle
draw ()
Object Oriented Analysis and Design
Rectangle
draw ()
57
58
What is modeling?
59
What is modeling?
A model is a simplification of reality.
What is this Thing?
Modeling a Briefcase
BriefCase
Abstracting
- Capacity
- Weight
+ open()
+ close()
60
What is modeling?
A model is an abstraction of things.
Emphasizes relevant characteristics.
Suppresses other characteristics.
What is this Thing?
BriefCase
- Capacity
- Weight
+ open()
+ close()
+ sitOnIt()
Questions:
61
More Important
Paper Airplane
62
Why Do We Model?
We build models to better understand the system
we are developing.
Modeling achieves four aims. Modeling
Helps us to visualize a system as we want it to be.
Permits us to specify the structure or behavior of a
system.
Gives us a template that guides us in constructing a
system.
Documents the decisions we have made.
63
64
Place Order
Inventory
Shipping
Business Process
Computer System
65
66
67
68
Business Logic
(C++, Java)
Database Server
(C++ & SQL)
Object Oriented Analysis and Design
69
Reusable
Components
70
71
Visualizing
Specifying
Constructing
Documenting
72
UML 1.4
UML 1.3
UML 1.1
UML 1.0
73
74
UML Semantics
Four-Layer Metamodel Architecture:
Layer
Description
meta-metamodel
MetaClass,
MetaAttribute,
MetaOperation
metamodel
An instance of a meta-metamodel.
Defines the language for specifying a
model.
Class, Attribute,
Operation,
Component
model
StockShare, askPrice,
sellLimitOrder,
StockQuoteServer
<Acme_SW_Share_98789
>,654.56, sell_limit_order,
<Stock_Quote_Svr_3223>
user objects
(user data)
Example
75
76
UML Semantics
Behavioral Elements
Collaborations
Use Cases
Common Behavior
Activity Graphs
State Machines
Foundation
Extension
Mechanisms
Core
Data Types
77
Model
Management
78
79
A Definition of Process
A process defines Who is doing What,
When and How to reach a certain goal.
New or changed
requirements
Software Engineering
Process
80
New or changed
system
Agile Process
An agile process implies a light and adaptive
81
Agile Process
predictive vs. adaptive
A predictive process is one that attempts to plan
and predict the activities and resource (people)
allocations in detail over a relatively long time span,
such as the majority of a project.
Predictive processes usually have a waterfall or
sequential lifecyclefirst, defining all the
requirements; second, defining a detailed design;
and third, implementing.
In contrast, an adaptive process is one that accepts
change as an inevitable driver and encourages
flexible adaptation; they usually have an iterative
lifecycle.
Object Oriented Analysis and Design
82
Waterfall Process
Requirements
analysis
Design
Code and unit test
Subsystem integration
System test
Delays confirmation of
critical risk resolution
Measures progress by
assessing work-products
that are poor predictors
of time-to-completion
Delays and aggregates
integration and testing
Precludes early
deployment
Frequently results in
major unplanned
iterations
83
Initial
Planning
Management
Environment
Test
Evaluation
Each iteration
results in an
executable release
Deployment
84
Risk Profiles
Risk
Waterfall Risk
Iterative Risk
Risk Reduction
Time
Object Oriented Analysis and Design
85
Best Practices
Key concepts
UP structure
Core Workflow
Appling UML in the UP
The RUP is a Process Framework
86
Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Verify Quality
Control Changes
87
Key concepts
Worker, Artifact and Activity
A role played by an individual or a
team
Activity
A unit of work
Worker
Who does
it?
Describe a
Use Case
Analyst
Artifact
responsible for
Use case
Use case
package
How does
it?
What is
produced?
88
Key concepts
Workflow (Discipline)
A workflow is
When does
it?
89
UP Structure
UP Structure
Lifecycle Phases
Major Milestones
Phases and Iterations
Iterations and Workflow
90
UP Structure
In an iteration,
you walk
through all
workflows
Workflows
group
activities
logically
91
Elaboration
Construction
Transition
time
92
Inception
Elaboration
Construction
Transition
time
Lifecycle
Objective
Milestone
Lifecycle
Architecture
Milestone
93
Initial Operational
Capability
Milestone
Product
Release
Preliminary
Iteration
Elaboration
Construction
Devel.
Iteration
Transition
Devel.
Iteration
Transition Transition
Iteration Iteration
94
Core Workflow
Core Process Workflows
1) Business Modeling
2) Requirements
3) Analysis & Design
4) Implementation
5) Test
6) Deployment
Core Supporting Workflows
7) Configuration & Change Management
8) Project Management
9) Environment
95
V is io n
S ta k e h o ld e r
R e q u e s ts
R e q u ir e m e n ts
V is io n
M anagem ent
S
u
p
p
l
e
m
e
n
t
a
r
y
( r e fin e d )
P la n
S p e c ific a tio n s
R e q u ir e m e n ts
A ttr ib u te s
D e v e lo p
V is io n
M anage
D e p e n d e n c ie s
S y s te m
A n a ly s t
R e q u ir e m e n ts
A ttr ib u te s
( r e f in e d )
C a p tu re a
C om m on
V o c a b u la r y
F in d A c to r s
and U se C ases
U s e -C a s e M o d e l
( r e fin e d )
G lo s s a r y
G lo s s a r y
( r e f in e d )
U s e -C a s e
M o d e lin g
G u id e lin e s
B u s in e s s
O b je c t M o d e l
B u s in e s s
U s e -C a s e M o d e l
U s e -C a s e M o d e l
U se C ase
( o u tlin e d )
C o re P ro c e s s
W o r k f lo w s
B u s in e s s
M o d e lin g
R e q u ir e m e n ts
A n a ly s is &
D e s ig n
Im p le m e n ta tio n
R e a liz e d B y
Im p le m e n te d
By
Te st
M o d e ls
R e a liz e d
By
B u s in e s s U s e C ase M odel
U s e -C a s e
M odel
O K
O K
B
B
B u s in e s s
O b je c t M o d e l
V e r ifie d B y
A u to m a te d
By
F a il
D e s ig n M o d e l
97
Im p le m e n ta tio n
M odel
Te st M o d e l
98
OO A&D Overview
99
100
Use-Case Model
Glossary
Design Model
Analysis and
Design
Architecture
Document
Supplementary
Specification
Data Model
101
Design
Focus on understanding
the problem
Idealized design
Behavior
System structure
Functional requirements
A small model
Focus on understanding
the solution
Operations and
Attributes
Performance
Close to real code
Object lifecycles
Non-functional
requirements
A large model
102
Use Cases
Bottom
Up
Design Classes
103
104
105
Architect
Package/
Subsystem
Design Model
Designer
Class
Software Architecture
Document
Design
Reviewer
Data Model
Database Designer
Architecture
Reviewer
106
107
Component
Definition of a (Software) Component
A non-trivial, nearly independent, and replaceable part of a
system that fulfills a clear function in the context of a welldefined architecture.
A component conforms to and provides the physical
realization of a set of interfaces.
A physical, replaceable part of a system that packages
implementation and conforms to and provides the
realization of a set of interfaces.
A component represents a physical piece of
implementation of a system, including software code
(source, binary or executable) or equivalents such as
scripts or command files.
108
Component-based
Reuse or customize components
Select from commercially-available components
Evolve existing software incrementally
Object Oriented Analysis and Design
109
Purpose of a CBSD
Basis for reuse
Component reuse
Architecture reuse
Applicationspecific
Businessspecific
Intellectual control
Middleware
Manage complexity
Maintain integrity
Component-based
Architecture with
layers
Systemsoftware
110
111
112
What is a pattern?
Part of a pattern
Some example patterns
Modeling a pattern with UML
113
What is a pattern?
What is a pattern?
A common problem
and a proven solution
in a context
A structured, packaged problem solution in literary form.
A way of recording experience, best practices
In a standard format
A repository for knowledge
Whats new is that theres nothing new here.
Patterns are about what works. Patterns give us a way to talk
about what works. Brian Foote, 1997.
114
Parts of a Pattern
Name:
a good name is essential because pattern names help designers to communicate.
Context:
where the pattern can be applied
Forces:
to be balanced in the solution
Problem:
usually describes in terms of the forces.
Solution:
a proven way of balancing the forces
Object Oriented Analysis and Design
115
116
Solution:
place the comfortable sitting place near the
window (e.g., a window seat)
Object Oriented Analysis and Design
117
118
119
Problem: how can we treat them uniformly without complicating the diagrams?
Solution: Add a party entity which unifies the two entities
120
121
122
123
124
What Is Architecture?
Software architecture encompasses the set of
significant decisions about the organization of a
software system
Selection of the structural elements and their
interfaces by which a system is composed
Behavior as specified in collaborations among those
elements
Composition of these structural and behavioral
elements into larger subsystems
Architectural style that guides this organization
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational
(derived from Mary Shaw)
125
126
128
System
architecture
Software
Architecture
is part
of
Software
Architects
are actors in
is represented by
Architecture
Design Process
produces
Software
Architecture
Description
has
Logical view
Process
view
is made of
relates to
is a
Architecture
Style guide
Architectural
view
has
Architectural style
is a
Architectural
Pattern
Use case
view
constrains
Form
Connection
Component
satisfies
Requirements
Deployment
view
is made of
has
Implementation view
constrains
129
depicts
Constraints
Architectural
Blueprint
Architectural view
An architectural view is a simplified description
(an abstraction) of a system from a particular
perspective or vantage point, covering particular
concerns, and omitting entities that are not
relevant to this perspective
130
Logical View
Implementation View
Analysts/Designers End-user
Functionality
Structure
Use-Case View
Process View
Deployment View
System integrators
Performance
Scalability
Throughput
Object Oriented Analysis and Design
Programmers
Software management
System engineering
System topology
Delivery,
installation
communication
131
Adding views:
Data view, security view
Object Oriented Analysis and Design
132
Architectural Style
An architecture style defines a family of
systems in terms of a pattern of structural
organization.
An architectural style defines
a vocabulary of components and connector
types
a set of constraints on how they can be
combined
one or more semantic models that specify how
a systems overall properties can be
determined from the properties of its parts
133
134
Architectural Focus
Although the views above could represent the
whole design of a system, the architecture
concerns itself only with some specific aspects:
135
Resilient
Simple
Approachable
Clear separation of concerns
Balanced distribution of responsibilities
Balances economic and technology
constraints
136