Object Oriented Analysis

OBJECT-ORIENTED
SOFTWAREENGINEERING
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.

REQUIREMENTSELICITATION
UNIT 04: Object-oriented Analysis
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)

REQUIREMENTSELICITATIONACTIVITIES
 Identify actors
 Identify scenarios
 Identify use cases
 Refine use cases
 Identifying relationships
among use cases
 Identifying nonfunctional
requirements
Source of information
 Client-supplied documents
 Manuals
 Technical documentation of
legacy systems
 End-user discussions

TWOMETHODSFORELICITINGINFORMATION
 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.

REQUIREMENTSELICITATIONCONCEPTS
 Functional requirements
 Nonfunctional requirements
 Completeness, consistency, clarity and correctness
 Realism, verifiability, traceability
 Greenfield engineering, reengineering and interface
engineering

NONFUNCTIONALREQUIREMENTS
 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

NONFUNCTIONALREQUIREMENTS
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

IDENTIFYINGACTORS
 Nouns that initiate/trigger events

IDENTIFYINGSCENARIOS
 Concrete, focused, informal description of a
single feature of the system from viewpoint of a
single actor

IDENTIFYINGUSECASES
 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

IDENTIFYINGRELATIONSHIPSBETWEENACTORSANDUSE
CASES
 Communication relationships between actors and use cases
 Actor who initiates the use case should be distinguished
from other actors

IDENTIFYINGINITIALANALYSISOBJECTS
 Identify participating objects for each use case.
 Give proper name and description, build a glossary

IDENTIFYINGINITIALANALYSISOBJECTS

IDENTIFYINGNONFUNCTIONALREQUIREMENTS

MANAGINGREQUIREMENTSELICITATION
References:

MANAGINGREQUIREMENTSELICITATION
 Negotiating specifications with clients (joint
application design)
 Focuses on building consensus among
developers, users, and clients by jointly
developing requirements specification

MANAGINGTRACEABILITY
 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.

DOCUMENTINGREQUIREMENTSELICITATION
1. Introduction
1.1 Purpose of the system
1.2 Scope of the system
1.3 Objectives and success
criteria of the project
1.4 Definitions, acronyms, and
abbreviations
1.5 References
1.6 Overview
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.3.1 Usability
3.3.2 Reliability
3.3.3 Performance
3.3.4 Supportability
3.3.5 Implementation
3.3.6 Interface
3.3.7 Packaging
3.3.8 Legal

DOCUMENTINGREQUIREMENTSELICITATION
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)

REQUIREMENTSANALYSIS
References:

REQUIREMENTSELICITATIONANDANALYSIS

ANALYSISCONCEPTS
 Analysis object models and dynamic models
– Object model – system, properties and relationships (class diagram)
– Dynamic model – behavior of system (sequence diagram, state
machine)

ANALYSISCONCEPTS
 Entity, boundary, and control objects
– Entity – objects
– Boundary – interactions between actors and system
– Control – realising use cases

ANALYSISCONCEPTS
 Generalisation and specialisation
– Generalisation – identify abstract concepts from lover-
level ones
– Specialisation – identify more specific concepts from
high-level one

ANALYSISCONCEPTS
 Generalisation and specialisation

ANALYSISACTIVITIES
1. Identifying Entity Objects
2. Identifying Boundary Objects
3. Identifying Control Objects
4. Mapping Use Cases to Objects
with Sequence Diagrams
5. Modeling Interactions among
Objects with CRC Cards
6. Identifying Associations
7. Identifying Aggregates
8. Identifying Attributes
9. Modeling State-Dependent
Behavior of Individual Objects
10. Modeling Inheritance
Relationships
11. Reviewing the Analysis Model

ReportEmergencyBOUNDARYOBJECTS

USECASES
 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.

4.MAPPINGUSECASESTOOBJECTSWITHSEQUENCE
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

SEQUENCEDIAGRAMFORREPORTEMERGENCY

MAPPINGUSECASESTOOBJECTSWITHSEQUENCEDIAGRAMS

5.MAPPINGINTERACTIONSAMONGOBJECTSWITHCRCCARDS
 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)

MAPPINGINTERACTIONSAMONGOBJECTSWITHCRCCARDS
 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.

MAPPINGINTERACTIONSAMONGOBJECTSWITHCRCCARDS
 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

6.IDENTIFYINGASSOCIATIONS
 An association shows relation between two or
more classes.
 Have several properties;
– Name
– Role
– Multiplicity

ELIMINATINGREDUNDANTASSOCIATION
 Redundant associations should be removed.
e.g.

7.IDENTIFYINGAGGREGATES
 Aggregation – denotes whole-part relationship
 The diamond part – represents whole
 Two types of aggregation
– Composition aggregation
– Shared aggregation

8.IDENTIFYINGATTRIBUTES
 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

9.MODELINGSTATE-DEPENDENTBEHAVIOROF
INDIVIDUALOBJECTS
 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.MODELINGSTATE-DEPENDENTBEHAVIOROF
INDIVIDUALOBJECTS

10.MODELINGINHERITANCERELATIONSHIPSBETWEEN
OBJECTS

11.REVIEWINGTHEANALYSISMODEL
 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

ACORRECTMODEL?
 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?

ACOMPLETEMODEL?
 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?

ACONSISTENTMODEL?
 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?

AREALISTICMODEL?
 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?

MANAGINGANALYSISPROCESS
 Document analysis – using object modelsand dynamic models
 Requirements analysisdocument
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

ASSIGNINGRESPONSIBILITIES
 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

SELFSTUDY
 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

Object Oriented Analysis

More Related Content

What's hot (20)

Similar to Object Oriented Analysis (20)

More from Pramod Parajuli (8)

Recently uploaded (20)

Object Oriented Analysis