1. Advance Software Engineering (CEN-5011)
Requirements Analysis: Object Modeling
Fall 2004
Instructor: Masoud Sadjadi

2. Acknowledgements Dr. Bernd Bruegge Dr. Allen Dutoit Overview:
Motivation
Overview
Concepts
Activities
Management
Summary

3. Agenda Motivation Analysis Overview Analysis Concepts
Analysis Activities
Managing Analysis
Summary
Motivation
Overview
Concepts
Activities
Management
Summary

4. Motivation Ambiguity: what do you see? Overview: Motivation Overview
Concepts
Activities
Management
Summary

5. Approach From Use Cases to Objects Top Level Use Case A and B
Overview:
From Use Cases to Objects
Motivation
Overview
Top Level Use Case
A and B
are called
Participating
Objects Le v
el 1 A B
Level 3 Use Cases
el 3
Operations
el 4
Level 2 Use Cases
el 2
Concepts
Activities
Management
Summary

6. Our Focus Identification of objects Their Behavior Their Relationship
Overview:
Identification of objects
Their Behavior
Their Relationship
Their Classification
Their Organization
Motivation
Overview
Concepts
Activities
Management
Summary

7. Object vs Class Object (instance): Exactly one thing
Overview:
Object (instance): Exactly one thing
A class describes a group of objects with similar properties
Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"):
Class diagram: Template for describing many instances of data. Useful for taxonomies, patters, schemata...
Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples
Motivation
Overview
Concepts
Activities
Management
Summary

8. Agenda Motivation Analysis Overview Analysis Concepts
Analysis Activities
Managing Analysis
Summary
Motivation
Overview
Concepts
Activities
Management
Summary

9. system specification:
Analysis Overview
Overview:
Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous.
Motivation
Overview
Concepts
Activities
system specification:
Model
analysis model:
Problem
Statement
Requirements
Analysis
Elicitation
Management
Summary

10. Req. Elicitation vs. Analsis
Overview:
Developers focus on structuring and formalizing the elicited requirements.
Motivation
Overview
Concepts
Analysis
functional
model
nonfunctional
requirements
analysis object
Requirements
elicitation
dynamic model
Analysis Model
Specification
System design
Object design
Activities
Management
Summary

11. The Analysis Model
Overview:
The analysis model is composed of the functional model, the object model, and the dynamic model.
Motivation
Overview
Concepts
Activities
Management
class
diagram:View
statechart
diagram:View
sequence
diagram:View
Summary
use case
diagram:View
object
model:Model
dynamic
model:Model
functional
model:Model
analysis
model:Model

12. Agenda Motivation Analysis Overview Analysis Concepts
Analysis Activities
Managing Analysis
Summary
Motivation
Overview
Concepts
Activities
Management
Summary

13. Analysis Concepts Analysis Object Models and Dynamic Models
Overview:
Analysis Object Models and Dynamic Models
Entity, Boundary, and Control Objects
Generalization and Specifications
Motivation
Overview
Concepts
Activities
Management
Summary

14. Analysis Object and Dynamic Models
Overview:
The analysis object model
focuses on the individual concepts that are manipulated by the system, their properties, and their relationships.
depicted by class diagrams.
The dynamic model
focuses on the behavior of the system.
depicted with sequence diagrams and with statecharts.
Motivation
Overview
Concepts
Activities
Management
Summary

15. Example
Overview:
Examples and counterexamples of classes in the analysis object model of SatWatch.
Motivation
Overview
Concepts
Activities
Management
Domain concepts
Software classes
Summary
UniversalTime
TimeZoneDatabase
TimeZone
GPSLocator
Location
UserId

16. Object Types 1 Entity Objects Boundary Objects Control Objects:
Overview:
Entity Objects
Represent the persistent information tracked by the system (Application domain objects, “Business objects”).
Boundary Objects
Represent the interaction between the user and the system.
Control Objects:
Represent the control tasks performed by the system.
Motivation
Overview
Concepts
Activities
Management
Summary

17. Object Types 2
Overview:
Having three types of objects leads to models that are more resilient to change.
The interface of a system changes more likely than the control
The control of the system change more likely than the application domain
Object types originated in Smalltalk:
Model, View, Controller (MVC)
Motivation
Overview
Concepts
Activities
Management
Summary

18. Example Analysis classes for the 2Bwatch example
Overview:
Analysis classes for the 2Bwatch example
Motivation
Overview
Concepts
Activities
Management
Summary
<<entity>>
Year
<<control>>
ChangeDateControl
<<boundary>>
ButtonBoundary
<<entity>>
Month
<<boundary>>
LCDDisplayBoundary
<<entity>>
Day

19. Generalization and Specialization
Overview:
Inheritance
enables us to organize concepts.
At the top of the hierarchy is a general concept.
At the bottom are the most specialized concepts.
Generalization
is the modeling activity that identifies abstract concepts from lower-level ones.
Specialization
is the activity that identifies more specific concepts from a high-level one.
Generalization-specialization relationship is another name for inheritance relationship.
Motivation
Overview
Concepts
Activities
Management
Summary

20. Example An example of a generalization hierarchy Incident LowPriority
Overview:
An example of a generalization hierarchy
Motivation
Overview
Concepts
Activities
Incident
LowPriority
Emergency
Disaster
EarthQuake
ChemicalLeak
CatInTree
TrafficAccident
BuildingFire
Management
Summary

21. Agenda Motivation Analysis Overview Analysis Concepts
Analysis Activities
Managing Analysis
Summary
Motivation
Overview
Concepts
Activities
Management
Summary

22. Analysis Activities Main goal: Find the important abstractions
Overview:
Main goal: Find the important abstractions
What happens if we find the wrong abstractions?
Iterate and correct the model
Steps during object modeling
1. Class identification
Based on the fundamental assumption that we can find abstractions
2. Find the attributes
3. Find the methods
4. Find the associations between classes
Order of steps
Goal: get the desired abstractions
Order of steps secondary, only a heuristic
Iteration is important
Motivation
Overview
Concepts
Activities
Management
Summary

23. From Use Cases to Objects
Overview:
Identifying Entity Objects
Identifying Boundary Objects
Identifying Control Objects
Mapping Use Cases to Objects
Modeling Interactions among Objects
Identifying Associations
Identifying Aggregations
Identifying Attributes
Modeling Objects State-Dependent Behavior
Modeling Inheritance Relationship
Reviewing the Analysis Model
Motivation
Overview
Concepts
Activities
Management
Summary

24. Identifying Entity Objects
Overview:
Participating objects form the basis of the analysis model.
Natural language analysis [Abbott, 1983].
Other heuristics
Terms that developers or users need to clarify in order to understand the use case.
Recurring nouns in the use cases.
Real-world entities that the system needs to track.
Real-world activities that the system needs to track.
Data source or sinks.
Motivation
Overview
Concepts
Activities
Management
Summary

25. Identifying Boundary Objects
Overview:
Boundary objects represent the system interface with the actors.
Heuristics
Identify the user interface controls that the user needs to initiate a use case.
Identify the forms.
Identify notices and messages.
Identify actor terminals, if multiple users are involved.
Do not model the visual aspects of the interface (use mock-ups instead).
Always use the end user’s terms for describing interfaces; do not use terms from solution domain.
Motivation
Overview
Concepts
Activities
Management
Summary

26. Identifying Control Objects
Overview:
Control objects are responsible for coordinating boundary and entity objects.
Heuristics
Identify one control object per use case.
Identify one control object per actor in the use case.
The life span of a control object should cover the extent of the use case or the extent of a user session.
If difficult, then the use case is required to be refined. The entry and exit conditions are not well defined.
Motivation
Overview
Concepts
Activities
Management
Summary

27. Mapping Use Cases to Objects
Overview:
A sequence diagram
ties use cases with objects.
It shows how the behavior of a use case (or scenario) is distributed among its participating objects.
Heuristics
The first column is an actor initiating the use case.
The second column a boundary object creating a control object.
The third column is a control object managing the rest of the use case.
Boundary and control object know about each other.
Entity objects do not know about boundary and control objects (independency promotes sharing).
Motivation
Overview
Concepts
Activities
Management
Summary

28. ReportEmergency Control
Example
Overview:
Sequence diagram for the ReportEmergency use case.
Motivation
Overview
Concepts
Activities
FieldOfficer
Report
EmergencyButton
ReportEmergency Control
ReportEmergency
Form
Emergency
Manage
EmergencyControl
press()
«create»
submit()
fillContents()
submitReport()
submitReportToDispatcher()
«destroy»
Management
Summary

29. Modeling Interactions among Objects
Overview:
CRC cards
Class, Responsibilities, and Collaborators.
Initially was introduced as a tool for teaching object-oriented concepts to novices.
CRC cards vs. Sequence Diagrams
provide different representations for supporting the same type of activity.
Sequence diagrams are a better tool for single modeler.
CRC cards are better for a group of developers.
Motivation
Overview
Concepts
Activities
Management
Summary

30. Example
Overview:
Examples of CRC cards for the ReportEmergencyControl and the Incident classes.
Motivation
Overview
Concepts
Activities
Management
ReportEmer
gencyControl
Summary
Responsibilities
Collaborators
Collects input from Field-
Emer
gencyReportForm of
ficer
Emer
gencyReport
Controls sequence of
AcknowledgementNotice
forms during emer
gency
reporting
Incident
Responsibilities
rack all information
related to a single inci-
Collaborators
Resource T
dent.

31. Identifying Associations
Overview:
An association shows relationship between two or more classes.
A name (optional)
A role
A multiplicity
The associations among entity objects are the most important ones.
Heuristics
Examine verb phrases.
Name associations and roles precisely.
Eliminate any redundant association.
Do not worry about multiplicity at the beginning.
Do not define too many associations.
Motivation
Overview
Concepts
Activities
Management
Summary

32. Example
Overview:
An example of association between the EmergencyReport and the FieldOfficer classes.
Eliminating redundant association.
Motivation
Overview
Concepts
Activities * 1
writes
author
document
FieldOfficer
EmergencyReport
Management
Summary * 1
writes
author
document
triggers
reports
FieldOfficer
EmergencyReport
Incident

33. Identifying Aggregations
Overview:
Aggregation
is a special type of association denoting a whole-part relationship.
Composition aggregation
indicates that the existence of the parts depends of the whole.
Shared aggregation
indicates that the existence of the whole and the parts are independent.
If you are not sure, then start with a one-to-many association relationship until you are sure about the whole-part relationship.
Motivation
Overview
Concepts
Activities
Management
Summary

34. Example Examples of aggregations and compositions. State County
Overview:
Examples of aggregations and compositions.
Motivation
Overview
Concepts
Activities
State
County
Township
FireStation
FireFighter
FireEngine
LeadCar
Ambulance
Management
Summary

35. Identifying Attributes
Overview:
Attributes
are properties of individual objects.
Consider only the ones relevant to the system.
Properties that are represented by objects are not attributes.
A name, a brief description, and a basic type.
Heuristics
Examine possessive phrases.
Represent stored state as an attribute of the entity object.
Describe each attribute.
Objects are not attributes. Use associations.
Do not go to details, the object structure is stable.
Motivation
Overview
Concepts
Activities
Management
Summary

36. Example Attributes of the EmergencyReport class. EmergencyReport
Overview:
Attributes of the EmergencyReport class.
Motivation
Overview
Concepts
Activities
Management
Summary
EmergencyReport
emergencyType:{fire,traffic,other}
location:String
description:String

37. Modeling State-Dependent Behavior
Overview:
Sequence Diagrams
used to distribute behavior across objects and to identify operations.
represent the behavior of the system from the perspective of a single use case.
Good for identifying missing objects.
Statechart Diagrams
represent behavior from the perspective of a single object.
Only objects with an extended lifespan and state-dependent behavior are worth considering.
Good for identifying missing use cases.
Motivation
Overview
Concepts
Activities
Management
Summary

38. Example UML statechart for Incident. Overview: Active Inactive Closed
Motivation
Active
Inactive
Closed
Archived
all
when d
ate > 1yr.
resources
submitted reports
Reported
Assessment
Disengagement
Response
field officer
arrives on site
releases resources
dispatcher
allocates resources
field officer requests
additional resources
all resources
deallocated
Overview
Concepts
Activities
Management
Summary

39. Modeling Inheritance Relationship
Overview:
Generalization
is used to eliminate redundancy from the analysis model.
if two or more classes share attributes or behavior, the similarities are consolidated into a superclass.
An example of inheritance relationship.
Motivation
Overview
Concepts
Activities
Management
Summary
FieldOfficer
Dispatcher
PoliceOfficer
badgeNumber:Integer

40. Reviewing the Analysis Model
Overview:
The analysis model is built incrementally and iteratively.
We say the model is stable, when the number of changes to the model are minimal.
Review
To make sure that the model is correct, complete, consistent, unambiguous, realistic, and verifiable.
internal review
after the model is stable, it is first reviewed by the developers.
joint review
next the model is reviewed jointly by the developer and the client.
Motivation
Overview
Concepts
Activities
Management
Summary

41. Is Our Model Correct?
Overview:
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?
Motivation
Overview
Concepts
Activities
Management
Summary

42. Is Our Model Complete? For each object: For each attribute:
Overview:
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 association 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?
Motivation
Overview
Concepts
Activities
Management
Summary

43. Is Our Model Consistent?
Overview:
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?
Motivation
Overview
Concepts
Activities
Management
Summary

44. Is Our Model Realistic?
Overview:
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?
Motivation
Overview
Concepts
Activities
Management
Summary

45. Summary of the Analysis Activities
Overview:
Review
model
Consolidate
Define
interactions
associations
attributes
nontrivial
behavior
use cases
participating
objects
boundary
control
entity
Motivation
Overview
Concepts
Activities
Management
Summary

46. Agenda Motivation Analysis Overview Analysis Concepts
Analysis Activities
Managing Analysis
Summary
Motivation
Overview
Concepts
Activities
Management
Summary

47. Managing Analysis
Overview:
In the end, the requirements analysis document (RAD) should describe a single coherent system understandable to a single person.
Documenting Analysis
Assigning Responsibilities
Communicating about Analysis
Iterating over the Analysis Model
Client Sign-Off
Motivation
Overview
Concepts
Activities
Management
Summary

48. Requirements Analysis Document
Overview:
1. Introduction
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.4 Constraints (“Pseudo requirements”)
3.5 System models
Scenarios
Use case model
Object model
Data dictionary
Class diagrams
Dynamic models
User interface
4. Glossary
1. Introduction
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.4 Constraints (“Pseudo requirements”)
3.5 System models
Scenarios
Use case model
Object model
Data dictionary
Class diagrams
Dynamic models
User interface
4. Glossary
Motivation
Overview
Concepts
Activities
Management
Summary

49. Object Models and Dynamic Models
Overview:
Object Models Section
documents in detail all the objects we identified, their attributes, and, when we used sequence diagrams, operations.
As each object is described with textual definitions, relationships among objects are illustrated with class diagrams.
Dynamic Models Section
documents the behavior of the object model in terms of statechart diagrams and sequence diagrams.
Although this information is redundant with the use case model, it describes precisely more complex behaviors.
Once RAD is completed and published, it will be baselined and put under configuration management.
Motivation
Overview
Concepts
Activities
Management
Summary

50. Assigning Responsibilities
Overview:
Roles
Generation of Information
Integration
Review
Participants
The End User
The Client
The Analyst
The Architect
The Document Editor
The Configuration Manger
The Reviewer
Motivation
Overview
Concepts
Activities
Management
Summary

51. Participants 1 The End User The client
Overview:
The End User
is the application domain expert.
generates information about the current system, the environment of the future system, and the tasks it should supports.
Each user corresponds to one or more actors and helps identify their associated use cases.
The client
funds the project and coordinates the user side of the effort.
serves as an integrator of application domain info.
defines the scope of the system based on user requirements.
Different users may have different views of the system.
Motivation
Overview
Concepts
Activities
Management
Summary

52. Participants 2 The Analyst The Architect
Overview:
The Analyst
is the application domain expert.
Typically a developer with broad application domain knowledge.
models the current system and generates information about the future system.
Each analyst is initially responsible for detailing one or more use cases.
The Architect
has an integration role.
unifies the use case and object models from a system point of view.
Different analyst may have different style of modeling and different view of the parts of the systems for which they are not responsible.
provides a system philosophy and detects omissions.
Motivation
Overview
Concepts
Activities
Management
Summary

53. Participants 3 The Document Editor The Configuration Manager
Overview:
The Document Editor
is responsible for low-level integration of the document and for the overall format of the document and its index.
The Configuration Manager
is responsible for maintaining a revision history of the document as well as traceability information relating the RAD with other documents.
The Reviewer
validates the RAD for correctness, completeness, consistency, and clarity.
Users, clients, developers, or other individuals may become reviewers during requirements validations.
If an individual has not been involved with the system, s/he may provide an excellent review.
Motivation
Overview
Concepts
Activities
Management
Summary

54. Communicating about Analysis
Overview:
The information communication is one of the most challenging tasks.
Participants with different backgrounds.
Stakeholders with different expectations.
New teams.
Evolving system
Approach
Clearly define territories (define roles and responsibilities).
Clearly define objectives and success criteria.
Set up brainstorming meetings.
Motivation
Overview
Concepts
Activities
Management
Summary

55. Iterating over the Analysis Model
Overview:
Analysis occurs iteratively and incrementally.
Often in parallel with other development activities such as system design and implementation.
Steps toward a stable model:
Brainstorming
Initiated before any other activities.
Solidification
Once the client and the developers converge on a common idea.
Maturity
Changes at the higher level are still possible but more difficult, and thus, are made more carefully.
Motivation
Overview
Concepts
Activities
Management
Summary

56. Client Sign-Off
Overview:
The client sign-off represents the acceptance of the analysis model by the client.
The client and the developers agree about the functionality and features of the system
In addition they agree on
A list of priorities
A revision process
A list of criteria that will be used to accept or reject the system
A schedule and a budget
After the sign-off, the RAD is baselined and is used for refining the cost estimate of the project.
Motivation
Overview
Concepts
Activities
Management
Summary

57. Prioritizing requirements
Overview:
High priority (“Core requirements”)
Must be addressed during analysis, design, and implementation.
A high-priority feature must be demonstrated successfully during client acceptance.
Medium priority (“Optional requirements”)
Must be addressed during analysis and design.
Usually implemented and demonstrated in the second iteration of the system development.
Low priority (“Fancy requirements”)
Must be addressed during analysis (“very visionary scenarios”).
Illustrates how the system is going to be used in the future if not yet available technology enablers are available.
Motivation
Overview
Concepts
Activities
Management
Summary

58. Example An example of a revision process. Overview: Motivation
Report problem or
Design change
and
change request
estimate impact
Update
requirements
design
Update code
(if applicable)
Design
test
Execute all
relevant tests
Archive
request
[change approved]
Review proposed
change
Review actual
Client
Developer
Concepts
Activities
Management
Summary

59. Agenda Motivation Analysis Overview Analysis Concepts
Analysis Activities
Managing Analysis
Summary
Motivation
Overview
Concepts
Activities
Management
Summary

60. Summary Modeling vs. reality System modeling
Overview:
Modeling vs. reality
System modeling
Functional model
Object model
Dynamic model
Object modeling is the central activity
Class identification is a major activity of object modeling
There are some easy syntactic rules to find classes/objects
Requirements Analysis Document Structure
Different roles and responsibilities during software development
Motivation
Overview
Concepts
Activities
Management
Summary

61. Next Session We will spend the next session on your group projects.
Overview:
We will spend the next session on your group projects.
We will work on the requirement analysis document for each project.
Please bring your scenarios and use cases as the input for the meeting.
Motivation
Overview
Concepts
Activities
Management
Summary