Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

Chapter 1

Introduction

Topics and Skills Covered

OOA/D

Patterns UML notation

Topics and Skills

Principles and Requirements


guidelines analysis

Iterative
development with
an agile Unified
Process
Analysis and Design?

• Analysis • Design

Object-Oriented Analysis and Design?

• Object-Oriented Analysis • Object-Oriented Design


Development Method

• OOA/D needs explanation in a method


context.

• We will use agile UP method


– Common, popular
– Focus is method-independent core skills, not UP
• Responsibility assignment, design patterns, …
– Just a sample

OOA/OOD

• OOA
– Examine requirements from the perspective of
classes and objects found in the vocabulary of
the problem domain
– Finding and describing objects/concepts in the
problem domain
– Investigation of domain objects
• OOD
– Defining software objects and how they
collaborate to fulfill requirements
– Concerned with their responsibilities and
collaborations
Example: Flight Information System

OO emphasizes representation of objects

Plane
visualization of
domain concept tailNumber domain concept

public class Plane


{
representation in an private String tailNumber;
object-oriented
programming language public List getFlightHistory() {...}
}

Iterative Development

• Contrasted with waterfall development


• Development organized into series of short mini-
projects (iterations)
• Each iteration includes its own requirement
analysis, design, implementation, and testing
• Outcome of each iteration
– Tested, integrated, executable partial system
• Advantages
– Accommodate shifting requirements better
– Expose risk earlier
– Increase quality
– Provide control and predictability
• Works well with OO development
Iterative Development

• Key steps
– Define use cases
– Define domain model
– Define interaction diagrams
– Define design class diagrams

Example – Dice Game

• Software simulation of a player rolling two


dice
– Win, if total is 7
– Lose, otherwise
• Use case
Play a dice game:
Player requests to role the dice. System
presents results: If the dice face value totals
7, player wins, otherwise player loses.
Example: Dice Game

• Define domain model


– Visualization of concepts or mental models of
real-world domain
– NOT description of software objects
Player Die
1 Rolls 2
name faceValue
1 2
Plays
1

DiceGame
1 Includes

Example: Dice Game

• Assign responsibilities and draw interaction


diagrams
Example: Dice Game

• Define design class diagram


– Static view of class
– Interaction diagram Æ dynamic view of object
collaboration
• Design class diagram
– Different from domain model
– But, some class names and content similar
• Lower representational gap between SW
components and mental models of domain
DiceGame Die

die1 : Die 1 2 faceValue : int


die2 : Die
getFaceValue() : int
play() roll()

Different perspectives with UML

Conceptual Perspective
DiceGame Die (domain model)
1 Includes 2
faceValue Raw UML class diagram
notation used to visualize
real-world concepts.

Specification or
DiceGame Die Implementation
Perspective
die1 : Die 2 faceValue : int (design class diagram)
die2 : Die
getFaceValue() : int Raw UML class diagram
play() roll() notation used to visualize
software elements.
Unified Modeling Language (UML)

Just a diagramming notation standard.

Trivial and relatively unimportant.

Not a method, process, or design guide.

Abstract «interface» ClassX


ClassX InterfaceX
classAttribute
... operation1() + publicAttribute
- privateAttribute
attributeWithVisibilityUnspecified
interface attribute1 : type
generalization burgers : List of VeggieBurger
implementation
AlternateUMLFor attribute2 : type = initial value
AbstractClass FinalClass ClassY finalConstantAttribute : int = 5 { frozen }
{abstract} {leaf} /derivedAttribute
operation1()
... ... ... classMethod()
+ «constructor» ClassX(int)
«signal» CaughtException1()
Whole methodWithVisibilityUnspecified()
AlternateUMLFor methodReturnsSomething() : Foo
ImplOfInterfaceX InterfaceX 1 abstractMethod()
Composition abstractMethod2() { abstract } // alternate
operation1()
* + publicMethod()
- privateMethod()
Part # protectedMethod()
Associations: ~ packageVisibleMethod()
1 Association-name  1 finalMethod() { leaf }
ClassA ClassB methodWithoutSideEffects() { query }
role-1 role-2
synchronizedMethod() { guarded }

exceptions
AssociationClass ThrownException1

Multiplicity:
zero or
1..40 one to 1..* 5 exactly
* Class more; Class
forty
Class one or
more
Class
five
"many"

Source: www.craiglarman.com

UML: What’s Important?

Harmful is knowing
how to read and
draw UML diagrams,
but not being an
expert in design and
patterns.

Important is object and


architectural design skills, not
UML diagrams, drawing, or
CASE tools.

Source: www.craiglarman.com

You might also like