Object-Oriented Analysis and Design

Chapter 1
Object-Oriented Analysis and Design

Chapter 1
• Chapter one covers a host of many topics central to today’s
technologies.
• These skills are essential in today’s professional community.
• We will talk about (in some detail) iterative development,
evolutionary development, the Unified Process, agile
approaches, UML,
• Later on we will advance into more complex concepts that
address framework design and architectural analysis.
• Please note that the materials are meant to be foundational.
2

Brief Introduction
• The Unified Modeling Language (UML) is a standard
diagramming notation; sometimes referred to as a blueprint.
• It is NOT OOA/OOD or a method
• Only a notation for capturing objects and the relationships
among objects (dependency; inheritance; realizes; aggregates, . .)
• UML is language-independent
• Analysis and design provide software “blueprints” captured in
UML.
• Blueprints serve as a tool for thought and as a form of
communication with others. 3

Thinking in Objects and UML – 2
• But it is far more essential to ‘think’ in terms of objects as
providing ‘services’ and accommodating ‘responsibilities.’
• Discuss: What is meant by ‘services?’ How indicated?
– How might you think these ‘services’ impact the design of classes?
– How might a client access these services?
– What is encapsulation? How does it relate to reusability? Self-
governance? Design?
• Discuss: What is meant by ‘responsibilities?’
– Encapsulation of data and services?
4

5
Thinking in Terms of Objects and UML - 3
• Object-Oriented Analysis (Overview)
– An investigation of the problem (rather than how a solution is defined)
– During OO analysis, there is an emphasis on finding and describing the
objects (or concepts) in the problem domain.
– For example, concepts in a Library Information System include Book,
and Library.
– High level views found in the application domain.
– Oftentimes called domain objects; entities.

6
Thinking in Terms of Objects and UML - 4
• Object-Oriented Design
– Emphasizes a conceptual solution that fulfills the requirements.
– Need to define software objects and how they collaborate to meet the
requirements.
– For example, in the Library Information System, a Book software object
may have a title attribute and a getChapter method.
• What are the methods needed to process the attributes?
• Designs are implemented in a programming language.
– In the example, we will have a Book class in Java.

UML Perspectives
• Conceptual perspective – the diagrams are interpreted as
describing things in a situation of the real world or domain of
interest.
• Specification (software) perspective – the diagrams describe
sw abstractions or components with specifications and
interfaces, but no commitment to a particular language
implementation.
• Implementation perspective – the diagrams describe sw
implementations in a particular technology.
7

8
Thinking in Terms of Objects and UML – 5
From Design to Implementation
Book
title
print()
public class Book {
public void print();
private String title;
}
Book
(concept)
Analysis
investigation
of the problem
Design
logical solution
Construction
code
Domain concept Representation in
analysis of concepts
Representation in an
object-oriented
programming language.
Can you see the services / responsibilities in the Book class?

Thinking in Objects and UML-6
• Then too, there are sets of proven design solutions to problems
that are considered ‘best practices.’
– Certain ‘groupings’ of classes with specific responsibilities / interfaces.
– These provide specific solutions to specific problems.
– Called Design Patterns
• We will discuss (much later) these standard patterns and how to
apply them to develop solutions to common design problems.
9

Thinking in Objects and UML-7
• Of course, design (solution to requirements) ‘assume’ a robust
requirements analysis has taken place.
• Use Cases are often used to capture stories of requirements and
are often views as ‘constituting’ the functional requirements,
but NOT the software quality factors (non-functional
requirements).
• Use Cases are not specifically designed to be object-oriented,
but rather are meant to capture how an application will be used.
• Many methods for capturing requirements.
• We will concentrate on Use Cases (ahead).
10

11
Basic Terms: Iterative, Evolutionary, and Agile
1. Introduction
• Iterative - the entire project will be composed of min-projects
and will iterate the same activities again and again (but on
different part of the project AND with different emphases) until
completion.
• Evolutionary (or incremental) - the software grows by
increments (to be opposed to the traditional, and somewhat old-
fashioned, Waterfall model of software development).
• Agile - we will use a light approach to software development
rather than a very rigid one (which may be needed for a safety-
critical system for example)
• This kind of approach seems better at treating software
development as a problem solving activity; also the use of
objects makes it amenable.

12
Our Approach:
•We need a Requirements Analysis approach with OOA/OOD
need to be practiced in a framework of a development process.
•We will adopt an agile approach (light weight, flexible) in the
context of the Unified Process, which can be used as a sample
iterative development process.
– Within this process, the principles can be discussed.
•Please note that there are several other contexts that may be used,
such as Scrum, XP, Feature-Driven Development, Lean
Development, Crystal Methods and others…and we will look at a
few of these.

13
Why the Unified Process:
•The Unified Process is a popular iterative software development
process.
•Iterative and evolutionary development involves relatively early
programming and testing of a partial system, in repeated cycles.
•It typically also means that development starts before the exact
software requirements have been specified in detail;
•Feedback (based on measurement) is used to clarify, correct and
improve the evolving specification:
•This is in complete contrast to what we usually mean by
engineering!

14
2. What is the Unified Process?
• The UP is very flexible and open and can include other practices
from other methods such as Extreme Programming (XP) or
Scrum for example.
– e.g. XP’s test-driven development, refactoring can fit within a UP
project; So can Scrum’s daily meeting.
– Being pragmatic in adapting a particular process to your needs is an
important skill : all projects are different.

We will be studying all of the topics found in Fig. 1.1
Topics and Skills
UML notation
Requirements
analysis
Principles and
guidelines
Patterns
Iterative
development with
an agile Unified
Process
OOA/D

The Rush to Code
• Critical ability to develop is to think in terms of objects and to
artfully assign responsibilities to software objects.
• Talk at great length in COP 3538 about encapsulation and
assigning methods to objects where the data is defined…
• One cannot design a solution if the requirements are not
understood.
• One cannot implement the design if the design is faulty.
• If I could only stop my students….
16

The Rush to Code
• Analysis: - investigate the problem and the requirements.
– What is needed? Required functions? Investigate domain objects.
– Problem Domain
– The Whats of a system.
– Do the right thing (analysis)
• Design:
– Conceptual solution that meets requirements.
– Not an implementation
– E.g. Describe a database schema and software objects.
– Avoid the CRUD activities and commonly understood functionality.
– The Solution Domain
– The ‘Hows’ of the system
– Do the thing right (design)
17

Analysis
• Analysis emphasizes an investigation of the problem and requirements,
rather than a solution.
• In software development, we are primarily concerned with two forms of
analysis.
• Requirements Analysis is discovering the requirements that a system must
meet in order to be successful.
• Object-Oriented Analysis is investigating the objects in a domain to
discover information important to meet the requirements.
18

What is Object-Oriented Analysis and Design
• OOA: we find and describe business objects or concepts in the
problem domain. During OOA, the emphasis is on finding and
describing the objects (or concepts) in the problem domain, i.e., domain
objects.
• OOD: we define how these software objects collaborate to
meet the requirements.
– Attributes and methods.
During OOD (or simply object design), the emphasis is on defining
software objects and how they collaborate to fulfill the requirements.
• OOP: Implementation: we implement the design objects in,
say, Java, C++, C#, etc.
19

EXAMPLE
20
Plane
tailNumber
public class Plane
{
private String tailNumber;
public List getFlightHistory() {...}
}
domain concept
visualization of
domain concept
representation in an
object-oriented
programming language

Use Case: Play a Dice Game
• The most important skill in OOA/D is assigning responsibilities
to objects.
– That determines how objects interact and what classes should perform
what operations.
• Player requests to roll the dice. System presents results. If the
dice face value totals seven, player wins; otherwise, player
loses.
21

Domain model (conceptual object model)
22
Player
name
DiceGame
Die
faceValue
Rolls
Plays
Includes
2
2
1
1
1
1
Domain model shows the noteworthy domain concepts as objects, their attributes
and associations.

Interaction Diagrams
• It shows the flow of messages between software objects, and thus the
invocation of methods.
23

Class Diagram
• 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.
24
2
Die
faceValue : int
getFaceValue() : int
roll()
DiceGame
die1 : Die
die2 : Die
play()
1

Object-Oriented Analysis and Design

More Related Content

What's hot

Viewers also liked

Similar to Object-Oriented Analysis and Design

Recently uploaded

Object-Oriented Analysis and Design

Editor's Notes