Object-Oriented%20Analysis%20and%20Design - PowerPoint PPT Presentation

About This Presentation
Title:

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

Description:

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. ... Analysis model is refined and adapted to the environment. Can be separated into ... – PowerPoint PPT presentation

Number of Views:168
Avg rating:3.0/5.0
Slides: 72
Provided by: john1283
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com