ObjectOriented Analysis

1
Object-OrientedAnalysis Design

• Session 2

2
ANALYSIS

• The goal of analysis
• General Design Specification for New System

3
Analysis Process

• Understanding the Existing System
• Identify Changes in User Requirements
• Specify One or More Possible Solutions
• Evaluate the Feasibility of the Proposed Solution

4
Object-Oriented Methodology

• OO views Information Systems as collection of
  interacting objects.

5
Object

• An object represents an entity, either physical
  (car), conceptual (chemical process), or
  software.
• An object is a concept, abstraction, or thing
  with sharp boundaries and meaning for an
  application.
• An object is something that has State, Behavior,
  and Identity.

6
Data Entities Compared with Objects
7
An object has state

• The state of an object is one of the possible
  conditions in which an object may exist.
• The state of an object normally changes over
  time.
• The state of an object is usually implemented by
  a set of properties called attributes, with the
  values of the properties, plus the links the
  object may have with other objects.

8
An object has behavior

• Behavior determines how an object acts and
  reacts.
• Behavior defines how an object reacts to requests
  from other objects.
• The visible behavior of an object is modeled by
  the set of messages it can respond to (the
  operations the object can perform).

9
An object has identity

• Each object has a unique identity, even if its
  state is identical to that of another object.
• Mr. A teaches SYS466
• Ms. B teaches ESL
• Mr. C teaches history
•       

10
Class

• A class is a description of a group of objects
  with common properties (attributes), common
  behavior (operations), common relationships to
  other objects (associations and aggregations),
  and common semantics.
• An object is an instance of a class.
• A class is an abstraction in that it
• Emphasizes relevant characteristics.
• Suppresses other characteristics.

11
Example

• Class course
• Structure
• name,
• location,
• days offered,
• credit hours,
• Start time, end-time.
• Behavior
• add a student,
• delete a student,
• get course roster,
• determine if it is full.

12
Representing classes

• A class is represented using a compartmented
  rectangular.

The second and third sections may be suppressed
if they need not be visible on the diagram.
13
Sample Class
14
Stereotypes

• A stereotype is a new type of modeling element
  that extends the semantics of the metamodel. They
  must be based on existing types or classes in the
  metamodel.
• Every class may have at most one stereotype.
• Common stereotypes
• Boundary class, Entity class, Control class
• Exception class, Metaclass, Utility class
• Stereotypes are shown in the class name
  compartment enclosed in ltltgtgt.

15
Boundary class

• A boundary class models communication between the
  systems surroundings and its inner workings.
• Typical boundary classes
• Windows (user interface)
• Communication protocol (system interface)
• Printer interface
• Sensors
• Example in the register for course scenario, a
  SheduleForm is created to accept information from
  the user.

16
Entity class

• An entity class models information and associated
  behavior that is generally long-lived
  (persistent).
• It can reflect a real-life phenomenon.
• It may also be needed for the internal tasks of
  the system.
• The values of its attributes are often provided
  by an actor.
• The behavior is surroundings-independent.
• Entity classes in the register for courses
  use-case
• Course, Schedule, Catalogue, CourseRoster

17
Control class

• A control class models control behavior specific
  to one or more use-cases.
• A control class
• Creates, initializes and deletes controlled
  objects.
• Controls the sequencing or coordination of
  execution of controlled objects.
• Controls concurrency issues for controlled
  classes.
• Is, most of the time, the implementation of an
  intangible object.
• In the register of courses scenario, a
  RegisterationManager class controls the
  registration process.

18
Object Interaction

• Objects interaction could be demonstrated by
  diagrams.
• Interaction diagram is a graphical representation
  of interactions between objects.

19
Interactions Diagrams

• Collaboration diagram
• Emphasizes the objects that interact together to
  support a use case diagram
• May be used alone or with sequence diagram
• Sequence diagram
• Focuses on message details
• Bottom-up approach
• More complex
• Used more frequently in industry

20
Sequence diagram

• A sequence diagram shows object interactions
  arranged in time sequence.
• The diagram shows
• the objects participating in the interaction
• the sequence of message exchanged
• A sequence diagram contains
• objects with their lifelines
• messages exchanged between objects in ordered
  sequence
• focus of control (optional)
• Consists of four basic symbols

21
Sample Sequence Diagram
22
Focus of Control

• Focus of Control represents the relative time
  that the flow of control is focused in an object.
• It represents the time an object is directing
  messages.
• Focus of control may be shown on a sequence
  diagram.

23
Collaboration Diagrams

• A collaboration diagram is an alternate way to
  represent the messages exchanged by a set of
  objects.
• The diagram shows object interactions organized
  around the object and their links to each other.
• A collaboration diagram contains
• objects
• links between objects
• messages exchanged between objects
• data flowing between objects, if any.

24
Sample Collaboration Diagram
25
Collaboration Diagram
26
Relationships Among OO Models