OBJECT-ORIENTED
SOFTWARE ENGINEERING
UNIT 04 : Object Oriented Analysis
© 2019, PRAMOD PARAJULI
Disclaimer
These slides are part of teaching materials for Object Oriented
Software Engineering (OOSE). These slides do not cover all
aspect of learning OOSE, nor are these be taken as primary
source of information. As the core textbooks and reference
books for learning the subject has already been specified and
provided to the students, students are encouraged to learn
from the original sources.
Contents in these slides are copyrighted to the instructor and
authors of original texts where applicable.
UNIT 04: Object-oriented Analysis
REQUIREMENTS ELICITATION
References:
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 4)
Pressman, R. S., 2001, Software Engineering - A Practitioner's Approach, Fifth Ed., McGrawHill (Chapter 21)
REQUIREMENTS ELICITATION
REQUIREMENTS ELICITATION ACTIVITIES
Identify actors Source of information
Identify scenarios Client-supplied documents
Identify use cases Manuals
Refine use cases Technical documentation of
Identifying relationships legacy systems
among use cases End-user discussions
Identifying nonfunctional
requirements
TWO METHODS FOR ELICITING INFORMATION
Joint Application Design – focuses on building
consensus among developers, users, and clients by jointly
developing requirements specification
Traceability – focuses on recording, structuring,
linking, grouping, and maintaining dependencies
among requirements and between requirements.
REQUIREMENTS ELICITATION CONCEPTS
Functional requirements
Nonfunctional requirements
Completeness, consistency, clarity and correctness
Realism, verifiability, traceability
Greenfield engineering, reengineering and interface
engineering
NONFUNCTIONAL REQUIREMENTS
Broad variety of requirements that are not related to functional
behavior of the system
FURPS+ model suggests following categories of nonfunctional
requirements
– Usability
– Reliability
– Performance
– Supportability
NONFUNCTIONAL REQUIREMENTS
Other categories in FURPS+
Implementation requirements (tools, programming languages, hardware
platforms)
Interface requirements (constrains of interfaces imposed by external systems,
legacy systems, end user, data interchange formats etc.)
Operations requirements (administration, configuration, management of system
in operational setting)
Package requirements (delivery of packages, installation media etc.)
Legal requirements (accessibility, encryption and security, no-read-up no-write-
down etc.)
Completeness, consistency, clarity and correctness –
review the language, sentences, phrases etc.
Realism, verifiability, and traceability – use numbers,
specific scenarios
Greenfield engineering – build system from scratch
Reengineering – reverse engineer existing system, redesign
and re implement
Interface engineering – redesign the user interface of an
existing system
IDENTIFYING ACTORS
Nouns that initiate/trigger events
IDENTIFYING SCENARIOS
Concrete, focused, informal description of a
single feature of the system from viewpoint of a
single actor
IDENTIFYING SCENARIOS
IDENTIFYING SCENARIOS
IDENTIFYING USE CASES
Use cases represent all possible scenarios for
given piece of functionality
A use case is initiated by an actor
A use case may interact with other actors
Name of a use case – should be a verb phrase
ANOTHER EXAMPLE
REFINING USE CASES
IDENTIFYING RELATIONSHIPS BETWEEN ACTORS AND USE
CASES
Communication relationships between actors and use cases
Actor who initiates the use case should be distinguished
from other actors
IDENTIFYING INITIAL ANALYSIS OBJECTS
Identify participating objects for each use case.
Give proper name and description, build a glossary
IDENTIFYING INITIAL ANALYSIS OBJECTS
IDENTIFYING INITIAL ANALYSIS OBJECTS
IDENTIFYING NONFUNCTIONAL REQUIREMENTS
IDENTIFYING NONFUNCTIONAL REQUIREMENTS
IDENTIFYING NONFUNCTIONAL REQUIREMENTS
UNIT 04: Object-oriented Analysis
MANAGING REQUIREMENTS ELICITATION
References:
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 4)
Pressman, R. S., 2001, Software Engineering - A Practitioner's Approach, Fifth Ed., McGrawHill (Chapter 21)
MANAGING REQUIREMENTS ELICITATION
Negotiating specifications with clients (joint
application design)
Focuses on building consensus among
developers, users, and clients by jointly
developing requirements specification
MANAGING TRACEABILITY
Tracing where requirements came from (who
originated it, which client need does it address) to
which aspect of the system and the project it affects
Helps show the system is complete
Focuses on - recording, structuring, linking,
grouping, and maintaining dependencies among
requirements and between requirements.
DOCUMENTING REQUIREMENTS ELICITATION
1. Introduction 3. Proposed system
1.1 Purpose of the system 3.1 Overview
1.2 Scope of the system 3.2 Functional requirements
1.3 Objectives and success 3.3 Nonfunctional requirements
criteria of the project 3.3.1 Usability
1.4 Definitions, acronyms, and 3.3.2 Reliability
abbreviations 3.3.3 Performance
1.5 References 3.3.4 Supportability
3.3.5 Implementation
1.6 Overview
3.3.6 Interface
3.3.7 Packaging
2. Current system 3.3.8 Legal
DOCUMENTING REQUIREMENTS ELICITATION
3.4 System models
3.4.1 Scenarios
3.4.2 Use case model
3.4.3 Object model
3.4.4 Dynamic model
3.4.5 User interface—navigational paths and screen mock-ups
4. Glossary
❃ Read ‘4.6 ARENA Case Study’ from
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering
using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 4)
UNIT 04: Object-oriented Analysis
REQUIREMENTS ANALYSIS
References:
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 5)
Pressman, R. S., 2001, Software Engineering - A Practitioner's Approach, Fifth Ed., McGrawHill (Chapter 21)
DOMAIN ANALYSIS
REQUIREMENTS ELICITATION AND ANALYSIS
ANALYSIS MODEL
ANALYSIS CONCEPTS
Analysis object models and dynamic models
– Object model – system, properties and relationships (class diagram)
– Dynamic model – behavior of system (sequence diagram, state
machine)
ANALYSIS CONCEPTS
Classes
ANALYSIS CONCEPTS
Entity, boundary, and control objects
– Entity – objects
– Boundary – interactions between actors and system
– Control – realising use cases
ANALYSIS CONCEPTS
Generalisation and specialisation
– Generalisation – identify abstract concepts from lover-
level ones
– Specialisation – identify more specific concepts from
high-level one
ANALYSIS CONCEPTS
Generalisation and specialisation
ANALYSIS ACTIVITIES
1. Identifying Entity Objects 7. Identifying Aggregates
2. Identifying Boundary Objects 8. Identifying Attributes
3. Identifying Control Objects 9. Modeling State-Dependent
4. Mapping Use Cases to Objects Behavior of Individual Objects
with Sequence Diagrams 10. Modeling Inheritance
5. Modeling Interactions among Relationships
Objects with CRC Cards 11. Reviewing the Analysis Model
6. Identifying Associations
1. IDENTIFYING ENTITY OBJECTS
IDENTIFYING ENTITY OBJECTS
ReportEmergency USE CASE
2. IDENTIFYING BOUNDARY OBJECTS
ReportEmergency BOUNDARY OBJECTS
3. IDENTIFYING CONTROL OBJECTS
IDENTIFYING CONTROL OBJECTS
USE CASES
Define functional and operational requirements
of the system by defining a scenario of usage.
Provide a clear and unambiguous description of
how the end-user and system interact with one
another.
Provide a basis for validation testing.
USE CASES
USE CASES
4. MAPPING USE CASES TO OBJECTS WITH SEQUENCE
DIAGRAMS
Shows how the behavior of a use case is distributed
among its participating objects
Columns of objects
Left most column – actor that initiates the use case
Horizontal arrows – messages
Time proceeds vertically
SEQUENCE DIAGRAM FOR REPORT EMERGENCY
SEQUENCE DIAGRAM FOR REPORT EMERGENCY
SEQUENCE DIAGRAM FOR REPORT EMERGENCY
MAPPING USE CASES TO OBJECTS WITH SEQUENCE DIAGRAMS
5. MAPPING INTERACTIONS AMONG OBJECTS WITH CRC CARDS
Class-responsibility-collaborator modeling
Classes – have characteristics: retained information, needed services, multiple
attributes, common attributes, common operations, essential requirements
Class types:
device class (e.g. sensor)
property class (e.g. rating)
interaction class (e.g. purchase, license, acquisition)
MAPPING INTERACTIONS AMONG OBJECTS WITH CRC CARDS
Responsibilities (attributes and operations)
Attributes – stable features
Operations – processing narrative
Five guidelines
System intelligence should be evenly distributed
Each responsibility should be stated as generally as possible
Information and behavior related to it should reside within the same class
Information about one thing should be localised with single class, not distributed
across multiple classes.
Responsibilities should be shared among related classes, when appropriate.
MAPPING INTERACTIONS AMONG OBJECTS WITH CRC CARDS
Collaborations fulfill their responsibilities in one of two
ways;
– A class can use its own operations to manipulate its own attributes
– A class can collaborate with other classes
CRC CARDS
6. IDENTIFYING ASSOCIATIONS
An association shows relation between two or
more classes.
Have several properties;
– Name
– Role
– Multiplicity
ELIMINATING REDUNDANT ASSOCIATION
Redundant associations should be removed.
e.g.
7. IDENTIFYING AGGREGATES
Aggregation – denotes whole-part relationship
The diamond part – represents whole
Two types of aggregation
– Composition aggregation
– Shared aggregation
TWO TYPES OF AGGREGATES
8. IDENTIFYING ATTRIBUTES
Attributes – properties of individual objects, least stable part
Properties are different to attributes!
First identify as many associations as possible before
identifying attributes
Attributes have;
– Name
– Brief description
– Type
8. IDENTIFYING ATTRIBUTES
9. MODELING STATE-DEPENDENT BEHAVIOR OF
INDIVIDUAL OBJECTS
Sequence diagrams - distribute behavior across objects
Sequence diagrams - represent the behavior of the system from the
perspective of a single use case.
State machine diagrams - represent behavior from the perspective of
a single object
By modeling state change upon certain event, enables a developer to detail
use cases.
9. MODELING STATE-DEPENDENT BEHAVIOR OF
INDIVIDUAL OBJECTS
10. MODELING INHERITANCE RELATIONSHIPS BETWEEN
OBJECTS
11. REVIEWING THE ANALYSIS MODEL
Analysis model is build incrementally and iteratively.
When number of changes become minimal in iterations, then
the model is stable.
Need to look for a model that is
– Correct
– Complete
– Consistent
– Realistic
A CORRECT MODEL?
Is the glossary of entity objects understandable by the user?
Do abstract classes correspond to user-level concepts?
Are all descriptions in accordance with the users’ definitions?
Do all entity and boundary objects have meaningful noun
phrases as names?
Do all use cases and control objects have meaningful verb
phrases as names?
Are all error cases described and handled?
A COMPLETE MODEL?
For each object: Is it needed by any use case? In which use case is it created?
modified? destroyed? Can it be accessed from a boundary object?
For each attribute: When is it set? What is its type? Should it be a qualifier?
For each association: When is it traversed? Why was the specific
multiplicity chosen?
Can associations with one-to-many and many-to-many multiplicities be
qualified?
For each control object: Does it have the necessary associations to access
the objects participating in its corresponding use case?
A CONSISTENT MODEL?
Are there multiple classes or use cases with the same name?
Do entities (e.g., use cases, classes, attributes) with similar names
denote similar concepts?
Are there objects with similar attributes and associations that are
not in the same generalization hierarchy?
A REALISTIC MODEL?
Are there any novel features in the system? Were any studies or
prototypes built to ensure their feasibility?
Can the performance and reliability requirements be met? Were
these requirements verified by any prototypes running on the
selected hardware?
Analysis
activities
MANAGING ANALYSIS PROCESS
Document analysis – using object models and dynamic models
Requirements analysis document
1. Introduction
2. Current system
3. Proposed system
3.1. Overview
3.2. Functional requirements
3.3. Nonfunctional requirements
3.4. System models
3.4.1. Scenarios
3.4.2. Use case model
3.4.3. Object model
3.4.3.1 Data dictionary
3.4.3.2 Class diagrams
3.4.4. Dynamic models
3.4.5. User interface—navigational paths and screen mock-ups
4. Glossary
ASSIGNING RESPONSIBILITIES
End-user - functions, workflows, data
Client – integration role, scope of system
Analyst – application domain expert, models current system and
future system, detailed use cases
Architect – integrates use cases and object models
Document editor – documentation
Configuration manager – maintains revisions, decompositions
Reviewer – validates correctness, completeness, consistency, and
clariy
Revision
process
SELF STUDY
5.5.3. Analysis communication
5.5.4. Iterating over analysis model
5.5.5. Client sign-off
5.6. ARENA Case Study
End of Unit 04 : Object-oriented Analysis
