ObjectOriented Analysis and Design:

1

• Chapter 5
• Object-Oriented Analysis and Design
• Project Management

2
Learning Objectives

• Describe the unique characteristics of an OOSAD
  project.
• Explain use cases and use case diagrams and how
  they can be used to model system functionality.
• Discuss process modeling with use cases for
  electronic commerce application.

3
Learning Objectives

• Understand how to represent system logic with
  sequence diagrams.
• Understand how to represent system logic with
  activity diagrams.

4
Learning Objectives

• Concisely define each of the following key data
  modeling terms object, state, behavior, object
  class, class diagram, operation, encapsulation,
  association role, abstract class, polymorphism,
  aggregation, and composition.
• Draw a class diagram to represent common business
  situations.

5
Object Oriented Terms And Concept

• Key terms
• Use Case
• Object
• Object class
• State
• Behavior
• Operation
• Encapsulation
• Constructor Operation
• Query Operation
• Update Operation
• Association
• Multiplicity

• Abstract Class
• Concrete Class
• Class-Scope attribute
• Abstract operation
• Method
• Polymorphism
• Overriding
• Aggregation
• Composition
• Event
• State transition
• Sequence diagram

6
Introduction

• Object-Oriented systems development life cycle
• Process of progressively developing
  representation of a system component (or object)
  through the phases of analysis, design and
  implementation
• The model is abstract in the early stages
• As the model evolves, it becomes more and more
  detailed

7
The Object-Oriented Systems Development Life Cycle

• Analysis Phase
• Model of the real-world application is developed
  showing its important properties
• Model specifies the functional behavior of the
  system independent of implementation details
• Design Phase
• Analysis model is refined and adapted to the
  environment
• Can be separated into two stages
• System design
• Concerned with overall system architecture
• Object design
• Implementation details are added to system design

8
The Object-Oriented Systems Development Life Cycle

• Implementation Phase
• Design is implemented using a programming
  language or database management system

9
Unique Characteristics of an OOSAD Project

• Uses a more iterative design approach such as
  prototyping or object-oriented analysis and
  design.
• During the OOSAD process, the system evolves
  incrementally over the life of the project.
• A portion of the final system is constructed
  during each iteration phase.

10
Unique Characteristics of an OOSAD Project (Cont.)

• Define the system as a set of components.
• Object-oriented development projects are
  developed using ongoing management and evolving
  system functionality.
• Complete hard problems first.
• The focus and ordering of system components
  change over the life of the project.

11
Unique Characteristics of an OOSAD Project (Cont.)

• Project activity focus changes over the life of a
  project.
• As the project evolves, system functionality
  evolves.

12
The Unified Modeling Language (UML)

• A notation that allows the modeler to specify,
  visualize and construct the artifacts of software
  systems, as well as business models
• Techniques and notations
• Use cases
• Class diagrams
• State diagrams
• Sequence diagrams
• Activity diagrams

13
Use Cases

• Use case is a depiction of a systems behavior or
  functionality under various conditions as the
  system responds to requests from users.
• Actor is an external entity that interacts with
  the system.

14
Use Cases (Cont.)
Figure 7-23 A use case diagram for a university
registration system.
15
Use Cases (Cont.)

• Most actors represent user roles, but actors can
  also be external systems.
• An actor is a role, not a specific user one user
  may play many roles, and an actor may represent
  many users.
• A use case model consists of actors and use cases.

16
Use Cases diagrams

• Use case diagram a picture showing system
  behavior along with the key actors that interact
  with the system.
• Abstract use case is when a use case is initiated
  by another use case.
• A use case represents completely functionality.

17
Definitions and Symbols

• Use Case
• Actor
• Boundary
• Connection
• Include relationship
• Extend relationship

18
Definitions and Symbols (Cont.)

• Actor is a role, not an individual.
• Involved with the functioning of the system at
  some basic level.
• Represented by stick figures.
• Use case represents a single system function.
• Represented as an eclipse.

19
Definitions and Symbols (Cont.)

• System boundary includes all the relevant use
  cases.
• A boundary is the dividing line between the
  system and its environment.
• Use cases are within the boundary.
• Actors are outside of the boundary.
• Represented as a box.

20
Definitions and Symbols (Cont.)

• Connection is an association between an actor and
  a use case.
• Depicts a usage relationship.
• Connection does not indicate data flow.
• Actors are connected to use cases with lines.
• Use cases are connected to each other with arrows.

21
Definitions and Symbols (Cont.)

• Extend relationship is an association between two
  use cases where one adds new behaviors or actions
  to the other.
• Extends a use case by adding new behavior or
  actions.
• Specialized use case extends the general use case.

22
Definitions and Symbols (Cont.)

• Include relationship is an association between
  two use cases where one use case uses the
  functionality contained in the other.
• Indicates a use case that is used (invoked) by
  another use case.
• Links to general purpose functions, used by many
  other use cases.

23
Definitions and Symbols (Cont.)
Figure 7-24 A use case diagram featuring an
include relationship.
24
Written Use Cases

• Document containing detailed specifications for a
  use case.
• Contents can be written as simple text or in a
  specified format.
• Step-by-step description of what must occur in a
  successful use case.

25
Electronic Commerce Application Process Modeling
using Use Cases

• Model the functionality of Pine Valley Furniture
  Webstore Application with a use case diagram.
• Six high-level functions identified to be
  included in the use case diagram.
• The functions represent the work or action
  parts of the Website.

26
Electronic Commerce Application Process Modeling
using Use Cases (Cont.)
Figure 7-26 WebStore use case diagram
27
Exercise

• Question no 2 (problems and exercises) page 247

28
Dynamic Modeling Sequence Diagrams

• Sequence diagram depicts the interactions among
  objects during a certain periods of time.
• May be presented either in a generic form or in
  an instance form.
• Generic form shows all possible sequences of
  interactions sequences corresponding to all the
  scenarios of a use case.
• Instance form shows the sequence for only one
  scenario.

29
Dynamic Modeling Sequence Diagrams (Cont.)

• Elements of a sequence diagram
• Objects represented by boxes at top of diagram.
• Lifeline the time during which an object exists.
• Messages means by which objects communicate with
  each other.

30
Dynamic Modeling Sequence Diagrams (Cont.)

• Activation the time period during which an
  object performs an operation.
• Synchronous message a type of message in which
  the caller has to wait for the receiving object
  to finish executing the called operation before
  it can resume execution itself.

31
Dynamic Modeling Sequence Diagrams (Cont.)

• Simple message a message that transfer control
  from the sender to the recipient without
  describing the details of the communication.
• Asynchronous message a message in which the
  sender does not have to wait for the recipient to
  handle the message.

32
Designing a Use Case with a Sequence Diagram
Figure 8-11 Sequence diagram for a class
registration scenario without prerequisites
33
Designing a Use Case with a Sequence Diagram
Figure 8-12 A generic sequence diagram for the
Prerequisite Courses Not Completed use case
34
A Sequence Diagram for Hoosier Burger
Figure 8-13 Sequence diagram for Hoosier Burgers
Hire Employee use case
35
Exercise

• Refer to sheet given
• Case study Library System

36
Process Modeling Activity Diagrams

• Activity Diagrams shows the conditional logic
  for the sequence of system activities needed to
  accomplish a business process.
• Clearly shows parallel and alternative behaviors.
• Can be used to show the logic of a use case.

37
Process Modeling Activity Diagrams (Cont.)
Figure 8-14 Activity diagram for a customer order
process.
38
Process Modeling Activity Diagrams (Cont.)

• Elements of Activity Diagrams
• Activity a behavior that an object carries out
  while in a particular state.
• Transition a movement from one activity or state
  to another.
• Branch a diamond symbol containing a condition
  whose results provide transitions to different
  paths of activities.

39
Process Modeling Activity Diagrams (Cont.)

• Synchronization bar horizontal or vertical bars
  denoting parallel or concurrent paths of
  activities.
• Fork the beginning of parallel activities.
• Join the end of parallel activities.
• Swimlanes columns representing different
  organizatonal units of the system.

40
Example

• Example Draw Activity Diagram for Class
  Registration

41
Basic Concept of O-O

• Object
• Class
• Attribute
• Operation
• Interface
• Package
• Subsystem

42
Object ModelingRepresenting Objects and Classes

• Object an entity with a well-defined role in an
  application domain, and has state, behavior, and
  identity characteristics.
• State encompasses an objects properties
  (attributes and relationships) and the values of
  those properties.

43
Representing Objects and Classes (Cont.)

• Behavior represents how an object acts and
  reacts.
• Identity uniqueness, no two objects are the
  same.
• Object class (class) a logical grouping of
  objects that have the same (or similar)
  attributes, relationships, and behaviors
  (methods).

44
Representing Objects and Classes (Cont.)

• Class diagram a diagram that shows the static
  structure of an object classes, their internal
  structure, and the relationships in which they
  participate.

45
Representing Objects and Classes (Cont.)
Figure 9-26 UML class diagram showing two classes
46
Representing Objects and Classes (Cont.)

• Operation a function or a service that is
  provided by all the instances of a class to
  invoke behavior in an object by passing a
  message.
• Encapsulation the technique of hiding the
  internal implementation details of an object from
  its external view.

47
Types of Operations

• Constructor an operation that creates a new
  instance of a class.
• Query an operation that accesses the state of an
  object but does not alter the state.
• Update an operation that alters the state of an
  object.
• Scope an operation that applies to a class
  rather than an object instance.

48
Representing Associations

• Association a relationship among instances of
  object classes.
• Association role the name given to the end of an
  association where it connects to a class.

49
Representing Associations

• Multiplicity indicates how many objects
  participate in a given relationship
• 0..10 means minimum of 0 and maximum of 10
• 1, 2 means can be either 1 or 2
• means any number
• UML associations are analogous to E-R
  relationships and UML multiplicities are
  analogous to E-R cardinalities.

50
Representing Associations (Cont.)
Figure 9-27 Examples of association relationships
of different degrees
51
Representing Associations (Cont.)
Figure 9-28 Examples of binary associations
52
Representing Associative Classes

• Associative class an association that has
  attributes or operations of its own or that
  participates in relationships with other classes.
• UML association classes are analogous to E-R
  associative entities.
• Generalization and inheritance implemented via
  superclass/subclasses in UML, supertypes/subtypes
  in E-R.

53
Representing Associative Classes (Cont.)
Figure 9-29 Class diagram showing associative
classes
54
Representing Stereotypes for Attributes
Figure 9-31 Stereotypes
55
Representing Generalization

• Abstract class a class that has no direct
  instances but whose descandants may have direct
  instances.
• Concrete class a class that can have direct
  instances.

56
Representing Generalization (Cont.)
Figure 9-32 Example of generalizations,
inheritance, and constraints.
57
Representing Generalization (Cont.)

• UML keywords
• Overlapping a descendant may be descended from
  more than one of the subclasses.
• Disjoint a descendant may not be descended from
  more than one of the subclasses.

58
Representing Generalization (Cont.)

• Complete all subclasses have been specified.
• Incomplete some subclasses have been specified,
  but the list is known to be incomplete.
• Class-scope attribute an attribute of a class
  that specifies a value common to an entity class,
  rather than a specific value for an instance.

59
Representing Generalization (Cont.)
Figure 9-33 Polymorphism, abstract operation,
class-scope attribute, and ordering
60
Representing Generalization (Cont.)

• Abstract operation defines the form or protocol
  of the operation, but not its implementation.
• Method the implementation of an operation.
• Polymorphism the same operation may apply to two
  or more classes in different ways.

61
Representing Aggregation

• Aggregation a part-of relationship between a
  component object and an aggregate object.
• Represented with open diamonds.
• Composition a part object that belongs to only
  one whole object and that lives and dies with the
  whole.
• Represented with filled diamonds.

62
Aggregation and Composition (Cont.)
Figure 9-34 Aggregation and composition
63
Exercise

• Refer to sheet given
• Case study Library System

64
Collaboration Diagram

• A UML diagram that shows the interactions between
  objects to perform critical pieces of the use
  case behavior
• Unlike sequence diagrams, collaboration diagrams
  have no spatial representation of time sequences
  of messages are shown by numbering.

65
(No Transcript)
66
Collaboration Diagrams Vs Sequence Diagrams

• Collaboration Diagrams
• Use in Use Case Analysis
• Show relationships in addition to interactions
• Better for visualizing patterns of collaboration
• Better for visualizing all of the effects on a
  given object
• Easier to use for brainstorming sessions
  (reordering of messages easier)

• Sequence Diagrams
• Use in Use Case Design
• Show the explicit sequence of messages
• Better for visualizing overall flow
• Better for real-time specifications and for
  complex scenarios

67
State Diagram

• State diagrams (also called State Chart diagrams)
  are used to help the developer better understand
  any complex/unusual functionalities or business
  flows of specialized areas of the system.
• It is also called a state transition diagram
• An event happens at a specific time and place.
• They cause a change of state, or the transition
  fires

68
State Diagram (cont..)

• Statechart diagrams are not created for all
  classes.
• They are created when
• A class has a complex life cycle.
• An instance of a class may update its attributes
  in a number of ways through the life cycle.
• A class has an operational life cycle.
• Two classes depend on each other.
• The objects current behavior depends on what
  happened previously.

69
(No Transcript)
70
Elements of State Diagram
71
Things to remember

• Create state diagrams when the business logic for
  a particular flow is very complex, or needs
  greater understanding by the developer to be
  coded perfectly.
• Arrange the states and transitions to ensure that
  the lines that cross each other are minimal.
  Cross-crossing lines are potential sources of
  confusion in conveying the diagram's meaning.

72
The Comparison
73
Exercise

• Case Study
• My Auto Rental Company
• Registration and Title System (Vehicles)