ObjectOriented Analysis and Design

1
Object-Oriented Analysis and Design

2
What is Object-Oriented Analysis?

• O-OA emphasizes finding and describing the
  objects (or concepts) in the problem domain.
• Example for a library information system, some
  of the concepts include Book, Library, and Patron

3
What is Object-Oriented Design?

• O-OD emphasizes defining software objects and how
  they collaborate to fulfill the requirements.
• Example in a library system, a Book software
  object may have a title, attribute and a
  getChapter() member function

4
Key Steps in O-OA/O-OD(based on the Unified
Model)

• Define Use Cases
• Define Domain Model
• Define Interaction Diagrams
• Define Design Class Diagrams

5
Example Play a Dice GameUse Case

• The dice game a player rolls two die. If the
  total is 7, the player wins otherwise, the
  player loses.
• This is a brief version of the Dice Game use
  case. It provides a written scenario for system
  use.

6
Domain Model

• Decomposition of the domain involves an
  identification of the concepts, attributes, and
  associations that are noteworthy. Result can be
  expressed in a domain model, which is illustrated
  as a set of diagrams that show domain concepts or
  objects.

7
Domain Model for Dice Game
8
Domain Model for Dice Game

• Model illustrates the noteworthy concepts Player,
  Die, and DiceGame, with their relationships and
  attributes.
• Note that the domain model is not a description
  of software objects it is a visualization of the
  concepts in the real-world domain.

9
Interaction Diagram

• O-OD is concerned with defining software objects
  and their collaborations.
• A common notation for illustrating these
  collaborations is the interaction diagram. This
  shows the flow of messages between software
  objects, and thus the invocation of member
  functions or messages.

10
Dice GameInteraction Diagram
11
Dice GameInteraction Diagram

• Although in the real world, a player rolls the
  dice, in the software design the DiceGame object
  rolls the dice by sending 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.
• A dynamic view of collaborating objects.

12
Design Class Diagrams

• Static view of the class definitions
• Design class diagrams illustrate software classes
  and associated data members (attributes) and
  member functions (methods)

13
Dice GameDesign Class Diagram
14
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.

15
References

• Applying UML and Patterns An Introduction to
  Object-Oriented Analysis and Design and the
  Unified Process, 2nd edition, Craig Larman,
  Prentice-Hall (2002), ISBN 0-13-092569-1
• Design Patterns Explained, Alan Shalloway and
  James Trott, Addison-Wesley (2002) , ISBN
  0-201-71594-5

16
Iterative Development and the Unified Process

• Iterative Development organizes the development
  process into a series of mini-projects called
  iterations
• Outcome of each iteration is a tested,
  integrated, and executable system (think
  prototypes)
• Resulting iterative development process is
  incremental

17
Exampletwo-week iteration half-way through a
project

• Monday devoted to distributing and clarifying the
  tasks and requirements for the iteration while
  one team member reverse-engineers the last
  iterations code into UML diagrams and prints and
  displays noteworthy diagrams

18
Exampletwo-week iteration half-way through a
project

• Tuesday spent at whiteboards doing design work
  drawing rough UML diagrams and writing some
  pseudocode and design notes
• Remaining 8 days spent on implementation, testing
  (unit, acceptance, usability), further design,
  integration, daily builds, system testing, and
  stabilization of the partial system along with
  planning the next iteration

19
Benefits of Iterative Development

• Early mitigation of high risks (technical
  challenges, requirements, objectives)
• Early visible progress
• Early feedback, user engagement, and adaptation,
  so refined system more closely meets the real
  needs of users
• Managed complexity through increasingly complex
  increments
• Learning within an iteration can improve the
  development process itself, iteration by iteration

20
Our O-O Information System

• User Interfacegraphical interface windows
• Application Logic and Domain Objectssoftware
  objects representing domain concepts that fulfill
  application requirements
• Technical Servicesgeneral purpose objects and
  subsystems that provide supporting technical
  services, such as interfacing to a database or
  error logging

21
Case Study The NextGen POS System
22
Use Case ModelingWriting Requirements in Context

• Writing use casesstories of using a systemis a
  technique to understand and describe requirements
• Definitions
• Actorsomething with behavior, such as a person
  or role, computer system, or organization
• Scenariospecific sequence of actions and
  interactions between actors and the system
• Use casecollection of related success and
  failure scenarios that describe actors using a
  system to support a goal

23
Use Cases Within the UP

• Requirements primarily recorded in use cases
• Iterations defined by choosing some use case
  scenarios
• Use case realizations drive the designthe team
  designs collaborating objects and subsystems to
  realize use cases

24
Use Case Context Diagram
25
Use Case Diagram
26
System Sequence Diagrams

• A system sequence diagram is a picture that
  shows, for a particular use case scenario, the
  events that external actors generate, their
  order, and inter-system events.
• Emphasis is on events that cross the system
  boundary from actors to systems.

27
Example SSD
28
SSD with Use-Case Text
29
Domain Modeling

• Domain model is a visual representation of
  conceptual classes or real-world objects in a
  domain of interest (also called conceptual
  models, domain object models, and analysis object
  models)

30
Domain Modeling

• Domain model is illustrated with a set of class
  diagrams in which no operations are defined
• Domain objects or conceptual classes
• Associations between conceptual classes
• Attributes of conceptual classes

31
Partial Domain Model
32
Steps for Domain Modeling

• List candidate conceptual classes
• Draw them in a domain model
• Add the associations necessary to record
  relationships for which there is a need to
  preserve memory or status
• Add attributes necessary to fulfill information
  requirements

33
From Domain Model to Design Model
34
Interaction Diagrams

• Include collaboration diagrams and sequence
  diagrams
• Collaboration diagrams illustrate object
  interactions in a graph or network format
• Sequence diagrams illustrate interactions in
  which time-ordering is inherent in the process
  design

35
Collaboration Diagram

36
Sequence Diagram

37
Example Collaboration Diagram makePayment

38
Example Sequence DiagrammakePayment

39
Designing Objects with Responsibilities

• Responsibility can be knowing or doing
• Doing
• Creating an object or doing a calculation
• Initiating action in other objects
• Controlling and coordinating activities in other
  objects
• Knowing
• Knowing about private encapsulated data
• Knowing about related objects
• Knowing about things that it can derive or
  calculate

40
Responsibilities and Interaction Diagrams

• Responsibilities and methods are related

41
Class-Responsibility-Collaborator Cards

• A Class-Responsibility-Collaborator model is a
  collection of index cards that represent
  classes, listing responsibilities and
  collaborators
• Responsibilities are the attributes and
  operations that are relevant for the class
• Collaborators are those classes that are required
  to provide a class with the information needed to
  complete a responsibility

42
CRC Modeling
43
Object Relationship Modeling

• Use the CRC model index cards to identify
  responsibilities
• Define those collaborator classes that help in
  achieving each responsibility
• This establishes the connection between classes
• A relationship exists between any two classes
  that are connected (or associated)

44
Object Behavior Modeling

• The object-behavior model indicates how an O-O
  system will respond to external events or stimuli
  (whereas the CRC model and the object-relationship
  model represent static elements of the O-O
  analysis model)
• Do the following
• Evaluate all use cases
• Identify events that drive the interaction
  sequence and understand how these events relate
  to objects
• Create an event trace for each use case
• Build a state-transition diagram for the system
• Review the object-behavior model for accuracy and
  consistency

45
Design Model Creating Design Class Diagrams

• DCDs and Interaction Diagrams are usually created
  in parallel
• Iteration do a little interaction diagramming,
  update the DCDs, extend the interaction diagrams
  some more, and so on
• Alternative, more graphical notation over CRC
  cards to record responsibilities and collaborators

46
Example DCD
47
Domain Model vs. Design Model Classes
48
NextGen POS DCD Attributes
49
NextGen POS DCD Methods
50
NextGen POS DCDType Information
51
NextGen POS DCDAssociations
52
Implementation ModelMapping Designs to Code

• Objective is to map design artifacts to code in
  an object-oriented language
• DCDs depict classes, their methods, and their
  attributes
• Can map this representation to a specific
  programming language implementation

53
DCD for SalesLineItem of POS
54
Adding Reference Attributes

• A reference attribute is an attribute that refers
  to another complex object
• The reference attributes of a class are suggested
  by the associations in a class diagram
• Reference attributes are often implied rather
  than explicit in a DCD

55
Adding Reference Attributes
56
Creating Methods from Interaction Diagrams

• Interaction diagrams show the messages that are
  sent in response to a method invocation (function
  call)
• Sequence of these messages translates to a series
  of statements in the method definition

57
enterItem Interaction Diagram
58
Register Class
59
enterItem() Method
60
SalemakeLineItem() Method
61
Possible Order of Implementation and Testing