object-oriented analysis and design ngssc object-oriented scientific programming, june 2012
TRANSCRIPT
Object-Oriented Analysis and Design
NGSSC Object-Oriented Scientific Programming,
June 2012
Object-Oriented Software Construction
Program = Data + Algorithm Constructing a software program can be
seen as building a model. Structured programming (the 70s)
focused on modelling algorithms, whereas OOP has its focus on modeling data.
Data is often more stable than algorithms, which makes OO models easier to change.
Data is more tangible, which makes OO models easier to understand.
History of the Object-Oriented Approach
Languages:
1969 Simula
1972 Smalltalk
1985 C++
1990 Python
1995 Java
Methods and notation:
1991 Booch
1991 OMT Rumbaugh et al
1992 OOSE Jacobsen
Unified Modeling Language:
1995 UML 0.9
2002 UML 1.4
Example: Matrix addition
Traditional version:
a and b are a two-dimensional arrays
for i = 0, lines for j = 0, cols a(i, j) = a(i, j) + b(i, j) end forend for
Example: Leap-Frog
ADT version
a and b are variables of type Matrix
a = a.add(b)
Traditional vs. Object-Oriented Software
Data structures visible Data structures hidden
Focus on a problem Focus on a problem domain
Traditional Object-oriented
Key concepts
Object Class Encapsulation Operation Inheritance Polymorphism Method
Some advantages
Faster code development (due to reusable components)
Easier to maintain and modify (due to encapsulation and inheritance)
Easier to scale programs (due to modelling and inheritance)
Easier communication with non-computer scientists
Object-Oriented Modeling
Two phases: Analysis Design
Two views: Structural/static Behavioural/dynamic
Structural/Static Modeling
Structural model: a view of a system that emphasizes the
structure of the objects, including their classifiers, relationships, attributes and operations.
No temporal information!!
We will use class diagrams to express the structural model
Building a class diagram
Identify classes Begin a data dictionary Add associations between classes Add attributes Look for inheritance relations Test the model via scenarios, and
iterate the above steps as necessary
Finding classes
Phase 1: brain stormingList concepts in the problem domainInclude anything that comes to your
mind
Phase 2: selectionRemove candidates that are:
redundant, irrelevant, vague, attributes, operations, associations, roles, implementation constructs, et cetera
Class
Fig. 3-20, UML Notation Guide
Window
display ()
size: Areavisibility: Boolean
hide ()
Window
Window
+default-size: Rectangle#maximum-size: Rectangle
+create ()
+display ()
+size: Area = (100,100)#visibility: Boolean = true
+hide ()
-xptr: XWindow*
-attachXWindow(xwin:Xwindow*)
{abstract,author=Joe,status=tested}
Class and objects
Point
x: Realy: Real
rotate (angle:Real)scale (factor:Real)
p1:Point
x = 3.5y = 2.7
:Point
x = 1y = -1
Associations
Fig. 3-40, UML Notation Guide
Person
Manages
JobCompany
boss
worker
employeeemployer
0..1
Job
Account
Person
Corporation
{Xor}
salary
Special Associations: Aggregations and Composites
Fig. 3-41, UML Notation Guide
Polygon PointContains
{ordered}
3..1
GraphicsBundle
colortexturedensity
1
1
-bundle
+vertex
Inheritance
Fig. 3-47, UML Notation Guide
Shape
SplineEllipsePolygon
Shape
SplineEllipsePolygon
Shared Target Style
Separate Target Style
. . .
. . .
Constraints and Comments
Fig. 3-17, UML Notation Guide
Member-of
Chair-of
{subset}Person Committee
Person Company
boss
{Person.employer =Person.boss.employer}
employeremployee
0..1
0..1
1
Representsan incorporated entity.
Structural Modeling Tips
Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain.
Focus on using basic constructs well; add advanced constructs and/or notation only as required.
Defer implementation concerns until late in the modeling process.
When to model use cases
Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven
method:start with use cases and derive your
structural and behavioral models from it.
If you are not using a use-case driven method:make sure that your use cases are
consistent with your structural and behavioral models.
Behavioral/Dynamic Modeling with UML
x y z
Sequence Diagram
a
b
c
Collaboration Diagram
x y
z
1.1: a1.2: c
1.1.1: b
Use Case: Change Flight Itinerary
Actors: traveler, client account data base, airline reservation system
Preconditions: Traveler has logged inBasic course:
– Traveler selects ‘change flight itinerary’ option– System retrieves traveler’s account and flight itinerary from client
account database– System asks traveler to select itinerary segment she wants to change;
traveler selects itinerary segment.– System asks traveler for new departure and destination information;
traveler provides information.– If flights are available then …– …– System displays transaction summary.
Alternative course:– If no flights are available then…
Sequence Diagram: Change Flight Itinerary
: Booking SystemTraveler Airline Reservation System
change flight itinerary
get customer account
get itinerarypresent itinerary
select segment
present detailed info
update informationavailable flight
::
Client Account DBMSClient Account DBMS
Collaboration Diagram: Change Flight Itinerary
Traveler Client Account DBMS
Airline Reservation System
: Booking System
7: update information
2: get customer account3: get itinerary
4: present itinerary
8: available flight
1: change flight itinerary5: select segment
6: present detailed info
Design patterns
A systematic way of describing a solution to a modeling problem
Four key elements:1. Pattern name2. Problem description3. Solution4. Consequences