Object Oriented Analysis

and Design
SE 321
Dr. Jibran Mir
Marks Distribution
• General Criteria
 Assignments 10%
Quizzes 10%
Midterm 20%
Terminal Exam 60%
Course Objectives
• Understand the importance and basic concepts and of object
oriented modelling
1. Specify, analyse and design the use case driven requirements for a
particular system.
2. Model the event driven state of object and transform them into
implementation specific layouts.
3. Identify, Analyse the subsystems, various components and collaborate
them interchangeably.
Course Learning Outcomes
• Analyse, design, document the requirements through use case driven
approach.
• Identify, analyse, and model structural and behavioural concepts of
the system.
• Develop, explore the conceptual model into various scenarios and
applications.
• Apply the concepts of architectural design for deploying the code for
software.
Reference Books
1) Applying UML and patterns: An introduction to Object-Oriented
Analysis and Design and Iterative Development by Craig Larman,
Prentice Hall; 3rd Edition (October 30, 2004). ISBN-10: 0131489062
2) Using UML: Software Engineering with Objects and Components by
Perdita Stevens, Addison-Wesley; 2nd Edition (February 13, 2006).
ISBN-10: 0321269675
3) Fundamental of Object-Oriented Design in UML by Meiler Page-Jones,
Addison Wesley, 2000. ISBN: 020169946X.
4) The Unified Modeling Language User Guide by G. Booch, J. Rambaugh
and I. Jakobson, Addison-Wesley Professional; 2nd Edition (2005).
ISBN- 10: 0321267974.
OBJECT-ORIENTED ANALYSIS
AND
DESIGN
Chapter 1
“The shift of focus (to patterns) will have a profound
and enduring effect on the way we write programs.”

—Ward Cunningham and Ralph Johnson

Objectives

• Compare and contrast analysis and design.

• Define object-oriented analysis and design (OOA/D).
• Illustrate a brief example.
Applying UML and Pattern in OOA/D
What is the purpose of OOA/D?
• To learn core skills in object-oriented analysis and design (OOA/D). These
skills are essential for the creation of well-designed, robust, and maintainable
software using object technologies and languages such as Java, C++,
Smalltalk, and C#.
What is a pattern
• In object-oriented analysis and design, patterns are a repetition of
design elements that work together. A seamless pattern is when every
element in a design combines to form a whole, even if it's repeated
many times.
"owning a hammer doesn't make one an architect"
• The above proverb is especially true with respect to object
technology.
• Knowing an object-oriented language (such as Java) is a necessary but
insufficient first step to create object systems. Knowing how to "think
in objects" is also critical.
Following are the essential skills
and topic for OOAD
Apply UML
• OOAD is not just about the UML. The UML is a standard diagramming
notation.
• As useful as it is to learn notation, there are more critical object-
oriented things to learn; specifically, how to think in objects—how to
design object-oriented systems.
• The UML is not OOA/D or a method, it is simply notation. It is not so
helpful to learn syntactically correct UML diagramming and perhaps a
UML CASE tool, but then not be able to create an excellent design, or
evaluate and improve an existing one.
• Yet, one needs a language for OOA/D and "software blueprints," both
as a tool of thought and as a form of communication with others.
Applying patterns and assigning
responsibilities
• How should responsibilities be allocated to classes of objects? How
should objects interact? What classes should do what? These are
critical questions in the design of a system.
• Certain tried-and-true solutions to design problems can be (and have
been) expressed as best-practice principles, heuristics, or patterns.
One case study
• This introduction to OOA/D is illustrated in a single case study that is
followed throughout the book, going deep enough into the analysis
and design so that some of the glory details of what must be
considered and solved in a realistic problem are considered, and
solved.
An example iterative process— the Unified
Process
• 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 in the
context of some development process.
• In this case, the well-known Unified Process is used as the sample
iterative development process within which these topics are
introduced.
• However, the analysis and design topics that are covered are common
to many approaches, and learning them in the context of the Unified
Process does not invalidate their applicability to other methods.
• In conclusion, this course helps a student or developer:
• Apply principles and patterns to create better object designs.
• Follow a set of common activities in analysis and design, based on the Unified
Process as an example.
• Create frequently used diagrams in the UML notation.
• It illustrates this in the context of a single case study.
Assigning Responsibilities
• There are many possible activities and artifacts in introductory
OOA/D, and a wealth of principles and guidelines.
• A critical, fundamental ability in OOA/D is to skilfully assign
responsibilities to software components.
Why?
• Because it is one activity that must be performed—either while
drawing a UML diagram or programming—and it strongly influences
the robustness, maintainability, and reusability of software
components.
• Importance of assigning responsibilities
• Of course, there are other necessary skills in OOA/D, but responsibility
assignment is emphasized in this introduction because it tends to be a
challenging skill to master, and yet vitally important.
• On a real project, a developer might not have the opportunity to perform any
other analysis or design activities—the "rush to code" development process.
Yet even in this situation, assigning responsibilities is inevitable.
• Nine fundamental principles in object design and responsibility
assignment are presented and applied. They are organized in a
learning aid called the GRASP (General Responsibility Assignment
Software Patterns) patterns.
What Is Analysis and Design?
• Analysis emphasizes an investigation of the problem and
requirements, rather than a solution. For example, if a new
computerized library information system is desired, how will it be
used?
• "Analysis" is a broad term, best qualified, as in requirements analysis
(an investigation of the requirements) or object analysis (an
investigation of the domain objects).
What Is Analysis and Design?
• Design emphasizes a conceptual solution that fulfils the
requirements, rather than its implementation. For example, a
description of a database schema and software objects. Ultimately,
designs can be implemented.
• As with analysis, the term is best qualified, as in object design or
database design.
• Analysis and design have been summarized in the phase do the right
thing (analysis), and do the thing right (design).
What Is Object-Oriented Analysis and
Design?
• During object-oriented analysis, there is an emphasis on finding and
describing the objects—or concepts—in the problem domain. For
example, in the case of the library information system, some of the
concepts include Book, Library, and Patron.
• During object-oriented design, there is an emphasis on defining
software objects and how they collaborate to fulfil the requirements.
For example, in the library system, a Book software object may have a
title attribute and a getChapter(int) method (see Figure 1.2).
An Example
• Before diving into the details of requirements analysis and OOA/D,
this section presents a birds-eye view of a few key steps and
diagrams, using a simple example—a "dice game" in which a player
rolls two die. If the total is seven, they win; otherwise, they lose.
Define Use Cases
• Requirements analysis may include a description of related domain
processes; 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 and
are an important part of the Unified Process
For example, here is a brief version of the Play a Dice Game use
case:

• Play a Dice Game: A player picks up and rolls the

dice. If the dice face value total seven, they win;
otherwise, they lose.
Define a Domain Model
• Object-oriented analysis is concerned with creating a description of
the domain from the perspective of classification by objects.
• A decomposition of the domain involves an identification of the
concepts, attributes, and associations that are considered
noteworthy.
• The result can be expressed in a domain model, which is illustrated in
a set of diagrams that show domain concepts or objects.
• This model illustrates the noteworthy concepts Player, Die, and
DiceGame, with their associations and attributes.
• Note that a domain model is not a description of software objects; it
is a visualization of concepts in the real-world domain.
Define Interaction Diagrams
• Object-oriented design is concerned with defining software objects
and their collaborations. A common notation to illustrate these
collaborations is the interaction diagram. It shows the flow of
messages between software objects, and thus the invocation of
methods.
• For example, assume that a software implementation of the dice
game is desired. The interaction diagram in Figure 1.4 illustrates the
essential step of playing, by sending messages to instances of the
DiceGame and Die classes.
Notice that although in the real world a player rolls the dice, in the
software design the DiceGame object "rolls" the dice (that is, sends
messages to Die objects). Software object designs and programs do
take some inspiration from real-world domains, but they are not direct
models or simulations of the real world.
Define Design Class Diagrams
• In addition to a dynamic view of collaborating objects shown in
interaction diagrams, it is useful to create a static view of the class
definitions with a design class diagram. This illustrates the attributes
and methods of the classes.
• For example, in the dice game, an inspection of the interaction
diagram leads to the partial design class diagram shown in Figure 1.5.
Since a play message is sent to a DiceGame object, the DiceGame
class requires a play method, while class Die requires a roll and
getFaceValue method.
• In contrast to the domain model, this diagram does not illustrate real-
world concepts; rather, it shows software classes.
Partial design class diagram
• A partial design class diagram (DCD) is a diagram that shows the static
structure of a system by describing the classes of objects that make
up the software solution.
The UML
“The Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting the
artifacts of software systems, as well as for business modeling
and other non-software systems [OMG01].”
UML background
• The UML has emerged as the de facto and de jure standard
diagramming notation for object-oriented modeling.
• It started as an effort by Grady Booch and Jim Rumbaugh in 1994 to
combine the diagramming notations from their two popular methods
—the Booch and OMT (Object Modeling Technique) methods.
• They were later joined by Ivar Jacobson, the creator of the Objectory
method, and as a group came to be known as the three amigos. Many
others contributed to the UML, perhaps most notably Cris Kobryn, a
leader in its ongoing refinement.