60-322

Object-Oriented Analysis and Design

Fall 2009
 Course Information
 Instructor:
– Dr. Dan Wu
– danwu@uwindsor.ca
 Thecourse outline
 Course website:
– TBA

2 Jan 5, 2009
  So you know how to program, at least in Java…

 You also know some useful data structures….

 Programming is fun, isn’t it ?

 Do you know how to develop quality software?

 Programming vs. software

 What do you think?

Owning a hammer doesn’t make one an architect.

3 Jan 5, 2009
 If you are given the task of developing …., how would you
start?

 Not an easy job…?

 The material in this course offers you:

– A systematic method to do OOAD, in the context of

– Software engineering process (the Unified Process , abbr. UP)

 Before you do any programming, which is more or less trivial

 Hopefully, you will at least know how to develop quality

software, which potentially to land you a job as system
analyst or alike along your career path, unless you prefer a
lifelong job as programmer.
4 Jan 5, 2009
Organization of the book and the course

 This course is about

– OOAD
– Frequently used UML notation
– Common Design Patterns
5 – Iterative software development process
Jan 5, 2009
Chapter 1. Introduction
 OOAD (and all software design) is strongly related to the
prerequisite activity of requirements analysis, which often
includes writing use cases.

 Given many possible activities from requirements through to

implementation, how should a developer or team proceed?

 Requirements analysis and OOA/D needs to be presented and

practiced in the context of some development process.

 An agile (light, flexible) approach to the well-known Unified

Process (UP) is used as the sample iterative development
process within which these topics are introduced.

 So what’s UP?

 See http://en.wikipedia.org/wiki/Unified_Process for details.

6 Jan 5, 2009
7 Jan 5, 2009
A few more notes….

 This course is *not* about UML.

 Thinkingin Objects is more important than

knowing UML.

 Thiscourse is to explore how to apply the

UML in the service of doing OOAD, and
covers frequently used UML.

8 Jan 5, 2009
 Analysis and Design
 Analysis: “build (do) the right thing”
– Analysis focuses on user requirements (functional or non-
functional)
– In other words, we want to decide exactly what system the
customer wants to have
– Investigate the problem, rather than a solution.

 Design: “build (do) the thing right”

– Design focuses on how to provide the required functionality
– In other words, we want to decide how to structure the software
that provides the (functional and non-functional) requirements
determined during analysis
– Emphasize a conceptual solution, which will ultimately lead to
concrete implementation.
9 Jan 5, 2009
 Analysis

 Usually performed by a systems analyst

– This is a person whose job it is to find out what an
organization (or person) needs in terms of a
software system
 Analysis looks at the software as a black box
of functionality
– An analyst will never care about the internals of
the system, merely how a user would interact with
it from the outside

10 Jan 5, 2009
 Design

 Usually performed by an architect or designer

– An architect looks at overall system structure (at a high
level)
 For example, an architect on a distributed system might decide
how the software components will be distributed
 An architect also looks at modularity, and non-functional
requirements (such as performance and scalability)
– A designer looks at system structure (at lower levels)
 A designer will look at the classes that make up a module, and
how they will interact to perform some function of the system

11 Jan 5, 2009
 Design Patterns

 Patterns are themes that recur in many types

of software systems
– It is common for software systems (even those
whose purpose is quite different) will share some
common challenges
 Often,the solution for the problem in one
context can also be used in another context
– Thus, the designs (and even implementations)
can often be reused from other software systems

12 Jan 5, 2009
 Object-Oriented Analysis and Design

 Object-oriented Analysis
 findingand describing the objects or concepts in
the problem domain.
– For example, in the case of the flight information system,
some of the concepts include Plane, Flight, and Pilot.
 Object-oriented Design (object design)
 defining software objects and how they collaborate
to fulfill the requirements.
– For example, a Plane software object may have a
tailNumber attribute and a getFlightHistory method

13 Jan 5, 2009
 A short Example

 We’ve talked about iterative development,

UP, requirement analysis, UML, OOAD, etc.

 Let’sput them into the perspective of OOAD

using this small example.
– A dice game:
 software simulates a player rolling two dice. If the total is
seven, they win; otherwise, they lose.

14 Jan 5, 2009
 A short Example

 Requirements analysis may include stories or

scenarios of how people use the application;
these can be written as use cases.
 Use cases are not an object-oriented artifact,
they are simply written stories. However,
they are a popular tool in requirements
analysis

15 Jan 5, 2009
 A short Example

 Object-oriented analysis is concerned with

creating a description of the domain from the
perspective of objects.
– Identification of the concepts, attributes, and
associations that are considered noteworthy.
 The result can be expressed in a domain model
that shows the noteworthy domain concepts or
objects
16 Jan 5, 2009
 A short Example

 Note that a domain model is not a description

of software objects; it is a visualization of the
concepts or mental models of a real-world
domain. Thus, it has also been called a
conceptual object model.

Note that a domain model is NOT a description of software objects; it

is a visualization of the concepts or mental models of a real-world
domain. Thus, it has also been called a conceptual object model.
17 Jan 5, 2009
 A short Example

 Object-oriented design is concerned with

defining software objects - their responsibilities
and collaborations.
 A common notation to illustrate these
collaborations is the sequence diagram (a kind
of UML interaction diagram).
 It shows the flow of messages between software
objects, and thus the invocation of methods.
18 Jan 5, 2009
 A short Example

19 Jan 5, 2009
 A short Example

 In addition to a dynamic view of collaborating

objects shown in interaction diagrams, a static
view of the class definitions is usefully shown
with a design class diagram. This illustrates the
attributes and methods of the classes.

20 Jan 5, 2009
 A short Example

21 Jan 5, 2009
  The dice game is a simple problem, presented
to focus on a few steps and artifacts in analysis
and design. To keep the introduction simple, not
all the illustrated UML notation was explained.

22 Jan 5, 2009
  This course is not primarily a UML notation course, but one that
explores the larger picture of applying the UML, patterns, and
an iterative process in the context of OOA/D and related
requirements analysis.

 OOA/D is normally preceded by requirements analysis.

 Therefore, the initial lectures introduce the important topics of

use cases and requirements analysis, which are then followed
by topics on OOA/D and more UML details.

23 Jan 5, 2009
What is the UML?
 The Unified Modeling Language is a visual language for specifying,
constructing and documenting the artifacts of systems.

 Three Ways to Apply UML

– UML as sketch
 Informal and incomplete diagrams (often hand sketched on whiteboards) created to
explore difficult parts of the problem or solution space, exploiting the power of visual
languages.
– UML as blueprint
 Relatively detailed design diagrams used either for
– 1) reverse engineering to visualize and better understanding existing code in UML diagrams, or
for

– 2) code generation (forward engineering).

 If reverse engineering, a UML tool reads the source or binaries and generates (typically)
UML package, class, and sequence diagrams. These "blueprints" can help the reader
understand the big-picture elements, structure, and collaborations.

 Before programming, some detailed diagrams can provide guidance for code generation
(e.g., in Java), either manually or automatically with a tool. It's common that the
diagrams are used for some code, and other code is filled in by a developer while
coding (perhaps also applying UML sketching).

24 Jan 5, 2009
What is the UML?
 UML as programming language
– Complete executable specification of a software system in UML.
Executable code will be automatically generated, still under
development in terms of theory, tool robustness and usability.
 Three Perspectives to Apply UML

 The UML describes raw diagram types, such as

class diagrams and sequence diagrams.

 It does not superimpose a modeling perspective

on these.
 Forexample, the same UML class diagram notation can be
used to draw pictures of concepts in the real world or
software classes in Java.

25 Jan 5, 2009
What is the UML?
 The same notation may be used for three
perspectives and types of models.
– Conceptual perspective (conceptual class)
– the diagrams are interpreted as describing things in a situation
of the real world or domain of interest.
– Specification (software) perspective (software class)
– the diagrams (using the same notation as in the conceptual
perspective) describe software abstractions or components with
specifications and interfaces, but no commitment to a particular
implementation (for example, not specifically a class in C# or
Java).
– Implementation (software) perspective
(implementation class)
– the diagrams describe software implementations in a particular
technology (such as Java).

26 Jan 5, 2009
  Thank you and See you next time.

27 Jan 5, 2009