ObjectOriented Analysis and Design Methods

1
Object-Oriented Analysis and Design Methods

• How to create and define objects?

2
Lecture Objectives

• To understand the process of identifying and
  creating objects for a system
• To describe a method for developing objects for
  an object-oriented system
• To describe the representations that can be used
  for objects and their relationships
• To discuss the dynamic aspects of object-oriented
  systems and how to model them

3
Too Many Methodologies!

• Booch Object-Oriented Design
• Rumbaugh Object Modeling Technique
• Shlaer and Mellor Analysis and Design
• Jacobson Objectory
• Wirfs-Brock Responsibility Driven Design
• Martin and Odell Object-Oriented Analysis and
  Design
• Others..

4
Object-Oriented Analysis

• Identify the objects and classes
• Identify the object attributes
• Identify operations on objects and classes
• Define object and class relationships
• Model dynamic concepts

5
Identify the objects and classes

• Grammatical Analysis
• Nouns are objects and attributes
• Verbs are operations or services
• Tangible entities (things), roles, events,
  interactions, etc. in application domain
• Use behavioural approach
• Participants in behaviours as objects
• Scenario-based analysis

6
Identify the object attributes

• Specify attributes (instance variables) of
  objects in problem domain
• These are to be recorded, displayed, stored,
  and/or manipulated in functions of the domain

7
Identify operations on objects and classes

• Operations that are used to interact with the
  objects and classes
• Each class has a protocol that captures the
  messages or operations that could be handled by
  the class or its instances
• Users or clients of classes and objects deal
  primarily with the external operations of the
  class

8
Example Scenario

• The Office Information Retrieval System (OIRS)
  can file documents under some name in one or more
  indexes, retrieve documents, display and maintain
  document indexes, archive documents and destroy
  documents. The system is activated by a request
  from the user and always returns a message to the
  user indicating the success or failure of the
  request.

9
Objects Identified
Document Name File Retrieve Archive
Destroy
Index Name Display Delete entry Add entry
User Get command Put message
Retrieval System User command
10
Define object and class relationships

• Capture relationship between classes. Typical
  relationships
• Inheritance
• Organisation of classes or entity types in
  problem domain
• One-to-One, One-to-Many, Many-to-Many
• relationships that exist between objects that
  reference each other

11
Example of Inheritance
Person
Student
Employee
MarketingPerson
SalesPerson
SalesManager
12
Example of Other Relationships
Has-capital
Country
City
One-to-One
Works-for
Person
Company
One-to-Many
Accessible-by
File
User
Many-to-Many
13
Model dynamic concepts

• State transition diagrams
• Specify states of the objects
• Specify events that trigger transitions
• Specify actions taken due to transitions
• Data flow diagrams
• Describe flow of objects and information
• Timing diagrams
• Illustrate object interactions over time

14
State transition diagram
checkmate
Black wins
Whites turn
Start
stalemate
Black moves
White moves
Draw
stalemate
Blacks turn
White wins
checkmate
15
Data flow diagram
Verify
Coded password
password
Customer
Password ok
Account
old balance
amount
Update
cash
new balance
16
Timing diagrams
Caller
Phone line
Callee
Caller lifts receiver
Dial tone begins
Dials number
Ringing tone
Phone rings
Answers phone
Ringing stops
Tone stops
Phones connected
Phones connected
Callee hangs up
Connection broken
Connection broken
17
Unified Modeling Language Approach OOA

• User view model system represented from the
  users perspective by developing
• use-case model
• Structural view model data and function is view
  from inside the system, static structure
  (classes, objects, relationships) is modeled

18
Use Case

• Scenario based technique for requirement
  elicitation
• Use case should achieve the following objectives
  
• Define functional and operational requirements of
  the system
• Provide clear description of how end user and the
  system will interact with one another
• Basis for validation testing

19
Use Case Diagram Elements

• Actor Entities that interact with the system
• Person, machine, another system etc
• Represent roles that a user play in the system
• Use case
• Sequence of transaction performed by the system
• Initiated by an actor to invoke certain function
  in the system

20
Use Case Diagram For The Library
21
Identify Objects and Classes

• Object
• Thing that can interact with
• Reacts when send messages
• concept, abstraction or thing that has sharp
  boundaries and meaning for an application
• Object has
• State value of property at a given time
• Behavior objects action and reaction
• Identity distinguishes from other objects

• Class
• A sets of objects with an equivalent roles in the
  system
• Every object belongs to a class
• Example
• Tangible book, copy, course
• Roles library member, student
• Events arrival, leaving, request
• Interaction meeting, intersection

22
Identify Class Attributes Operations
23
Relationship

• Why do we need Relationship
• All system encompass many classes and objects
• Objects contribute to the behavior of a system by
  collaborating with one another
• Collaboration is accomplish through relationships
• Two important type of relationship during
  analysis
• Association
• Aggregation

24
Association

• Represent relationship between objects of classes
• Multiplicity Association
• Number of instance of one class related to one
  instance of the other class
• Multiplicity indicator
• Many -
• Exactly one - 1
• Zero or more - 0 ..
• One or more - 1 ..
• Zero or one - 0 .. 1
• Specified range - m .. n Eg - 2 .. 4

25
Inheritance

• Hierarchy abstraction where subclass inherits
  from one or more superclass
• Subclass inherits attributes, operations and
  relationships
• Subclass may have additional attributes,
  operations or relationship
• How to find inheritance?
• Look for common behavior and attributes in classes

26
Aggregation

• Known as part-of relationship
• A whole class related to its parts
• Association or Aggregation ?
• If two object tightly bound by a whole part
  relationship Aggregation
• If two object considered independent even though
  they are often linked Association

27
Example of Aggregation
28
Object Interactions

• To show dynamic behavior of the system
• Also known as Sequence Diagram
• Interaction between objects is modeled using
  interaction diagram.
• Show how messages passed between objects
• Realize use cases

29
Object Interactions(Continued)
30
Changes In System State Diagram

• State of book object may change when a copy of
  book is successfully book
• borrowable not borrowable

There is a copy available in the library
All copies are out on loan or reserved
31
Deliverables from Unified Modeling Language
Approach OOA

• Use Case Diagram
• Sequence Diagram
• Class Diagram
• State Transition Diagram

32
Object-Oriented Design

• Detailed specifications of the following
• Subsystems or class categories
• Partitioning the system, providing interfaces,
  interactions, and mapping to targeted system
• Class definitions
• structure or representation
• behaviour or operations
• implementation algorithms
• additional support classes for implementation

33
Object-Oriented Design (Continued)

• Class relationships
• Containment
• Referencing
• Aggregation
• Inheritance
• Object diagrams and object relationships
• Descriptions of how objects interact
• Class interaction - what classes are used by
  another class

34
Object-Oriented Design (Continued)

• State transition
• Extends state transition diagrams in analysis
• Timing diagrams
• Extends timing diagrams in analysis
• Designing algorithms
• implementation algorithms and logic
• Physical compilation units
• Compilation modules, interface specifications

35
UML Approach to OOD
36
System Design

• Partition the Analysis Model
• Refine analysis objects using inheritance,
  pattern and encapsulation
• Package into subsystem or modules
• Can be characterized by responsibility
• Design artifact may include
• Refined class diagram
• Interaction, activity component deployment
  diagram
• State models
• Composed classes into packages. Composition can
  be done base on
• Use cases
• Unit of physical realization
• Processing

37
System Design (continued)

• Concurrency and Subsystem Allocation
• Assign concurrency if classes are active at the
  same time
• Implement on the same processor hardware
• Concurrent is defined by examining the state
  diagram
• Establish thread for active object
• Thread control continues when it sends message to
  another object and wait for responses
• Isolate these thread controls
• Consider performance, cost and overhead by
  processor when allocates the object to the
  processor

38
System Design (Continued)

• Task Management Component
• How the task initiated
• Common
• Event driven
• Interrupt from outside source (Processor, sensor
  etc)
• Clock driven
• Interrupt from system clock
• Determine the task priority and criticality
• High priority task must have immediate access to
  the resources
• High critical task must operate continually even
  if resources availability is reduced or system
  operates in degrade state.

39
System Design (continued)

• User Interface Component
• Define system menu and sub functions available
  for the menu
• Data Management Component
• Data management for critical application
• Layered design
• Creation of infrastructure for storage and
  retrieval
• Use database, files, shared memory
• Design the attribute and operation to manage data
• Resource Management Component
• Subsystem may compete to use the same resources
  at the same time

40
System Design (continued)

• User Interface Component
• Define system menu and sub functions available
  for the menu
• Data Management Component
• Data management for critical application
• Layered design
• Creation of infrastructure for storage and
  retrieval
• Use database, files, shared memory
• Design the attribute and operation to manage data
• Resource Management Component
• Subsystem may compete to use the same resources
  at the same time

41
Activity Diagram

• Activity diagram
• Activities coordination
• To show how an operation can be implemented
• Useful when an operation has to achieve a number
  of different things
• Record dependencies between activities
• Which thing can happen in parallel
• What must finished first before something else
  can start

42
Activity Diagram
43
Object Design

• Object Description
• Establish object interface
• Define message the object can receive
• Operation the object can perform when it receives
  the message
• Implementation details
• Objects private parts
• Internal details about data structure
• Details about the operation
• Algorithms and Data Structure
• Algorithm created to implements operation
  specification

44
Component Model

• Component
• Standard building unit that is used to develop an
  application
• Types of component
• Source code (e.g file containing code of the
  class)
• Has to be available when compiled
• Binary object code (e.g class library)
• Depends on any object code
• Must be linked to form an executable program
• Executable application (e.g the client/server,
  database manager)
• May depend on other executable programs to
  interact at runtime

45
A component diagram showing compile time
dependencies
46
Deployment Model

• Deployment diagram shows
• Physical communication links between hardware
  items
• Machines, printers and other resources
• Relationship between physical machines and
  processes
• What runs where

47
Deliverables from UML Approach to OOD

• Class Diagram (Refined)
• State Transition Diagram (Refined)
• Component Diagram
• Deployment Diagram

48
References

• Software Engineering A Practitioners Approach
  5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
• Object-Oriented Modeling and Design by James
  Rumbaugh et al, Prentice Hall, 1991
• Object Orientation by Setrag Khoshafian
  Razmik Abnous, John Wiley Sons, 1995
• Teach Your Self UML in 24 hours by Joseph
  Schmuller, Sams Publication, 2001
• Mastering UML with Rational Rose by Wendy Boggs
  and Michael Boggs, Sybex Inc, 2000
• Using UML Software Engineering With Objects and
  Components by Perdita Stevens, Rob Pooley,
  Addison Wesley, 2000