Object-Oriented%20Analysis%20and%20Design

1
COSC4406 Software Engineering

• Lecture 8
• Object-Oriented Analysis and Design

20.1
2
Learning Objectives

• 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

20.2
3
Learning Objectives

• Discuss the concepts and principles underlying
  the object-oriented approach
• Describe the activities in the different phases
  of the object-oriented development life cycle
• State the advantages of object-oriented modeling
  versus traditional systems development approaches
• Learn to develop requirements models using
  use-case diagrams
• Learn to use class diagrams to develop object
  models of the problem domain
• Learn to develop dynamic models using state,
  interaction and activity diagrams
• Model real-world applications using UML diagrams

20.3
4
RoadMap for Detailed (D-) Requirements
1. Select organization for D-requirements
2. Create sequence diagrams from use cases --
3a. Obtain D-requirements from C-requirements
customer
In parallel ...
Apply customer feedback
3b. Outline test plans
3c. Inspect
4. Validate with customer
when unit approved by customer ...
5. Release-
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5
RoadMap for Detailed (D-) Requirements using
the OO style
1. Obtain domain classes objects from sequence
diagrams
2. Add additional essential domain classes
Inspect the resulting collection of classes
3 For each class,
specify the required attributes specify the
required functionality specify the specific
required objects specify how its objects react
to events draft test plans for each inspect the
results
4. Inspect against C-requirements
5. Verify with customer where possible
When complete
6. Release
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
Types of Requirements 1/2

• 1. Functional requirements
• the application's functionality
• 2. Non-functional requirements
• 2.1 Performance
• speed
• capacity (traffic rates)
• memory usage
• RAM
• disk
• 2.2 Reliability and availability
• 2.3 Error handling

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
Types of Requirements 2/2

• 2.4 Interface requirements
• how the application interacts with the user, and
  with other applications
• 2.5 Constraints
• accuracy
• tool and language constraints
• e.g. FORTRAN 88 must be used
• design constraints
• standards to be used
• hardware platforms to be used
• 3. Inverse requirements
• what the application does not do

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
8
Write a Detailed Requirement 1
One way to ...

• 1. Classify requirement as functional or
  non-functional
• IEEE SRS prompts for most non-functional
• select method for organizing functional
  requirements
• 2. Size carefully
• a functional requirement corresponds to a
  method
• too large hard to manage
• too small not worth tracking separately
• 3. Make trace-able if possible
• ensure suitable for tracking through design and
  implementation
• 4. Make testable
• sketch a specific test that establishes
  satisfaction

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
Write a Detailed Requirement 2
One way to ...

• 5. Make sure not ambiguous
• ensure hard to misunderstand intention
• 6. Give the requirement a priority
• e.g., highest (essential) lowest (optional)
  neither (desirable)
• 7. Check that requirement set complete
• for each requirement, ensure all other necessary
  accompanying requirements are also present
• 8. Include error conditions
• state whats specifically required for
  non-nominal situations
• include programmer errors for critical places
• 9. Check for consistency
• ensure that each requirement does not contradict
  any aspect of any other requirement

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
Ways of Organizing Detailed Requirements

• Feature
• Use case
• Class
• Function hierarchy
• State

by ...
Graphics reproduced with permission from Corel.
11
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

20.11
12
(No Transcript)
13
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

20.13
14
The Object-Oriented Systems Development Life Cycle

• Implementation Phase
• Design is implemented using a programming
  language or database management system
• Outcomes and Deliverables
• Diagrams
• Repository descriptions

20.14
15
(No Transcript)
16
The Object-Oriented Systems Development Life Cycle

• Benefits of OO modeling
• The ability to tackle more challenging problem
  domains
• Improved communication among users, analysts,
  designers and programmers
• Increased consistency among analysis, design and
  programming activities
• Explicit representation of commonality among
  system components
• Reusability of analysis, design and programming
  results
• Increased consistency among the models developed
  during object-oriented analysis, design, and
  programming

20.16
17
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

20.17
18
Use-Case Modeling

• Applied to analyze functional requirements of the
  system
• Performed during the analysis phase to help
  developers understand functional requirements of
  the system without regard for implementation
  details
• Use Case
• A complete sequence of related actions initiated
  by an actor
• Actor
• An external entity that interacts with the system

20.18
19
Figure 20-2Use-case diagram for a university
registration system
20.19
20
Use-Case Modeling

• Developing Use-Case Diagrams
• Use cases are always initiated by an actor
• Use cases represent complete functionality of the
  system
• Relationships Between Use Cases
• Use cases may participate in relationships with
  other use-cases
• Two types
• Extends
• Adds new behaviors or actions to a use case
• Include
• One use case references another use case

20.20
21
(No Transcript)
22
(No Transcript)
23
Describe a user case

• By plain text
• The objective
• The actor that initiates it
• The exchange of information between the actors

24
Object ModelingClass Diagrams

• Object
• An entity that has a well-defined role in the
  application domain, and has state, behavior, and
  identity
• State
• A condition that encompasses an objects
  properties and the values those properties have
• Behavior
• A manner that represents how an object acts and
  reacts
• Object Class
• A set of objects that share a common structure
  and a common behavior

20.24
25
Object ModelingClass Diagrams

• Class Diagram
• Class is represented as a rectangle with three
  compartments
• Objects can participate in relationships with
  objects of the same class

20.25
26
Object ModelingObject Diagrams

• Object Diagram
• A graph of instances that are compatible with a
  given class diagram also called an instance
  diagram
• Object is represented as a rectangle with two
  compartments
• Operation
• A function or service that is provided by all the
  instances of a class
• Encapsulation
• The technique of hiding the internal
  implementation details of an object from its
  external view

20.26
27
Object ModelingObject Diagrams

• Types of Operations
• 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, (No for C, Java)
• Constructor
• An operation that creates a new instance of a
  class

20.27
28
Figure 20-5UML class and object diagrams(a)
Class diagram showing two classes(b) Object
diagram with two instances
20.28
29
Representing Associations

• Association
• A relationship between object classes
• Degree may be unary, binary, ternary or higher
• Depicted as a solid line between participating
  classes
• Association Role
• The end of an association where it connects to a
  class
• Each role has multiplicity, which indicates how
  many objects participate in a given association
  relationship

20.29
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
Representing Association Classes

• Association Class
• An association that has attributes or operations
  of its own, or that participates in relationships
  with other classes
• Figure 20-9 shows one example

20.33
34
(No Transcript)
35
(No Transcript)
36
To be continued

• Representing Derived Attributes, Derived
  Associations and Derived Roles
• Representing Generalization
• Interpreting Inheritance and Overriding
• Representing Multiple Inheritance
• Representing Aggregation
• Dynamic Modeling State Diagrams
• Dynamic Modeling Sequence Diagrams
• Dynamic Modeling Activity Diagrams

37
Representing Derived Attributes, Derived
Associations and Derived Roles

• Derived attributes, associations and roles can be
  computed from other attributes, associations or
  roles
• Shown by placing a slash (/) before the name of
  the element

20.37
38
(No Transcript)
39
Representing Generalization

• Generalization
• Abstraction of common features among multiple
  classes, as well as their relationships, into a
  more general class
• Superclass
• A generalized class that is composed of several
  subclasses
• Subclass
• A class that has been specialized

20.39
40
(No Transcript)
41
(No Transcript)
42
Representing Generalization

• Discriminator
• Shows which property of an object class is being
  abstracted by a generalization relationship
• Inheritance
• A property that a subclass inherits the features
  from its superclass
• Abstract Class
• A class that has no direct instances, but whose
  descendents may have direct instances
• Concrete Class
• A class that can have direct instances

20.42
43
Representing Generalization

• Semantic Constraints among Subclasses
• 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
• Complete
• All subclasses have been specified. No
  additional subclasses are expected
• Incomplete
• Some subclasses have been specified, but the list
  is known to be incomplete

20.43
44
(No Transcript)
45
Representing Generalization

• Class-scope Attribute
• An attribute of a class which specifies a value
  common to an entire class, rather than a specific
  value for an instance.
• Abstract Operation
• Defines the form or protocol of an 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

20.45
46
(No Transcript)
47
Interpreting Inheritance and Overriding

• Overriding
• Process of replacing a method inherited from a
  superclass by a more specific implementation of
  that method in a subclass
• Three Types
• Overriding for Extension
• Operation inherited by a subclass from its
  superclass is extended by adding some behavior
• Overriding for restriction
• The protocol of the new operation in the subclass
  is restricted
• Overriding for optimization
• The new operation is implemented with improved
  code by exploiting the restrictions imposed by a
  subclass

20.47
48
(No Transcript)
49
Representing Multiple Inheritance

• Multiple Classification
• An object is an instance of more than one class
• Use is discouraged and not supported by UML
  semantics
• Multiple Inheritance
• Allows a class to inherit features from more than
  one superclass

20.49
50
(No Transcript)
51
Representing Aggregation

• Aggregation
• A part-of relationship between a component object
  and an aggregate object
• Example Personal computer
• Composed of CPU, Monitor, Keyboard, etc
• Composition
• A stronger form of aggregation
• One component belongs to only one whole object

20.51
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
Dynamic ModelingState Diagrams

• State
• A condition during the life of an object during
  which it satisfies some conditions, performs some
  actions or waits for some events
• Shown as a rectangle with rounded corners
• State Transition
• The changes in the attribute of an object or in
  the links an object has with other objects
• Shown as a solid arrow
• Diagrammed with a guard condition and action
• Event
• Something that takes place at a certain point in
  time

20.55
56
(No Transcript)
57
(No Transcript)
58
(No Transcript)
59
Dynamic ModelingSequence Diagrams

• Sequence Diagram
• A depiction of the interaction among objects
  during certain periods of time
• Activation
• The time period during which an object performs
  an operation
• Messages
• Means by which objects communicate with each
  other

20.59
60
Build a Sequence Diagram 1
One way to ...

• 1. Identify the use case whose sequence diagram
  you will build
• 2. Identify which entity initiates the use case
• the user, or
• an object of a class
• name the class
• name the object
• 3. Draw a rectangle to represent
  this object at left top
• use UML objectClass notation
• 4. Draw an elongated rectangle beneath this
  to represent the execution of an
  operation
• 5. Draw an arrow pointing right from its top

myObject MyClass
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
61
Build a Sequence Diagram 2
One way to ...
MyObject MyClass
MyObject1 MyClass1

• 6. Identify which entity handles the operation
  initiated
• an object of a class
• name the class
• name the object
• 7. Label the arrow with the name of the operation
• dont show return
• 8. Show a process beginning, using an elongated
  rectangle
• 9 Continue with each new statement of the use
  case.

My operation
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
62
Dynamic ModelingSequence Diagrams

• 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
• Simple Message
• A message that transfers control from the sender
  to the recipient without describing the details
  of the communication

20.62
63
Sequence diagram for a class registration
scenario with prerequisites
20.63
64
(No Transcript)
65
Process ModelingActivity 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

20.65
66
(No Transcript)
67
Analysis Versus Design

• Start with existing set of analysis model
• Progressively add technical details
• Design model must be more detailed than analysis
  model
• Component Diagram
• A diagram that shows the software components or
  modules and their dependencies
• Deployment Diagram
• A diagram that shows how the software components,
  process and objects are deployed into the
  physical architecture of the system

20.67
68
(No Transcript)
69
(No Transcript)
70
Summary

• Object-Oriented modeling approach
• Benefits
• Unified Modeling Language
• Use cases
• Class diagrams
• State diagrams
• Sequence diagrams
• Activity Diagrams
• Use-case modeling

20.70
71
Summary

• Object Modeling Class Diagrams
• Associations
• Generalizations
• Inheritance and Overriding
• Aggregation
• Dynamic Modeling State Diagrams
• Dynamic Modeling Sequence Diagrams
• Analysis Versus Design

20.71