Title: Object-Oriented%20Analysis%20and%20Design
1COSC4406 Software Engineering
- Lecture 8
- Object-Oriented Analysis and Design
20.1
2Learning 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
3Learning 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
4RoadMap 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.
5RoadMap 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.
6Types 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.
7Types 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.
8Write 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.
9Write 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.
10Ways of Organizing Detailed Requirements
- Feature
- Use case
- Class
- Function hierarchy
- State
by ...
Graphics reproduced with permission from Corel.
11Introduction
- 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)
13The 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
14The 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)
16The 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
17The 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
18Use-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
19Figure 20-2Use-case diagram for a university
registration system
20.19
20Use-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)
23Describe a user case
- By plain text
- The objective
- The actor that initiates it
- The exchange of information between the actors
24Object 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
25Object 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
26Object 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
27Object 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
28Figure 20-5UML class and object diagrams(a)
Class diagram showing two classes(b) Object
diagram with two instances
20.28
29Representing 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)
33Representing 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)
36To 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
37Representing 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)
39Representing 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)
42Representing 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
43Representing 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)
45Representing 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)
47Interpreting 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)
49Representing 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)
51Representing 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)
55Dynamic 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)
59Dynamic 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
60Build 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.
61Build 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.
62Dynamic 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
63Sequence diagram for a class registration
scenario with prerequisites
20.63
64(No Transcript)
65Process 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)
67Analysis 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)
70Summary
- Object-Oriented modeling approach
- Benefits
- Unified Modeling Language
- Use cases
- Class diagrams
- State diagrams
- Sequence diagrams
- Activity Diagrams
- Use-case modeling
20.70
71Summary
- Object Modeling Class Diagrams
- Associations
- Generalizations
- Inheritance and Overriding
- Aggregation
- Dynamic Modeling State Diagrams
- Dynamic Modeling Sequence Diagrams
- Analysis Versus Design
20.71