CEN 5011 6 th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi sadjadi/Teaching/ Requirements Analysis:

CEN 5011 6th Lecture

Advance Software Engineering (CEN-Advance Software Engineering (CEN-5011)5011)

Instructor: Masoud Sadjadi

http://www.cs.fiu.edu/~sadjadi/Teaching/

Requirements Requirements Analysis:Analysis:

Object Modeling Object Modeling

6th LectureCEN 5011: Advanced Software Engineering 2

AcknowledgementsAcknowledgements

Dr. Bernd Bruegge

Dr. Allen Dutoit

OvervieOverview:w:Motivation

Overview

Concepts

Activities

Management

Summary


AgendaAgenda

Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary


Overview

Concepts

Activities

Management

Summary


MotivationMotivation

Ambiguity: what do you see?OvervieOverview:w:Motivation

Overview

Concepts

Activities

Management

Summary


ApproachApproach

From Use Cases to Objects

Top Level Use Case

A and Bare called

ParticipatingObjects

Level 1

A B

Level 3 Use Cases Level 3 Level 3 Level 3

Operations Level 4 Level 4

Level 2 Use Cases Level 2 Level 2


Overview

Concepts

Activities

Management

Summary


Our FocusOur Focus

Identification of objects

Their Behavior

Their Relationship

Their Classification

Their Organization


Overview

Concepts

Activities

Management

Summary


Object vs ClassObject vs Class

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


Overview

Concepts

Activities

Management

Summary


AgendaAgenda



Overview

Concepts

Activities

Management

Summary


Analysis OverviewAnalysis Overview

system specification:

Model

analysis model:

Model

Problem

Statement

Requirements Analysis

Requirements Elicitation

Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous.


Overview

Concepts

Activities

Management

Summary


Req. Elicitation vs. AnalsisReq. Elicitation vs. Analsis

Developers focus on structuring and formalizing the elicited requirements.

Analysis

functionalmodel

nonfunctionalrequirements

analysis objectmodel

Requirementselicitation

dynamic model

Requirements

Analysis Model

Specification

System design

Object design


Overview

Concepts

Activities

Management

Summary


The Analysis ModelThe Analysis Model

The analysis model is composed of the functional model, the object model, and the dynamic model.

analysismodel:Model

dynamicmodel:Model

objectmodel:Model

functionalmodel:Model

use casediagram:View

classdiagram:View

statechartdiagram:View

sequencediagram:View


Overview

Concepts

Activities

Management

Summary


AgendaAgenda



Overview

Concepts

Activities

Management

Summary


Analysis ConceptsAnalysis Concepts

Analysis Object Models and Dynamic Models

Entity, Boundary, and Control Objects

Generalization and Specifications


Overview

Concepts

Activities

Management

Summary


Analysis Object and Dynamic ModelsAnalysis Object and Dynamic Models

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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

Examples and counterexamples of classes in the analysis object model of SatWatch.

UniversalTime

TimeZone

Location

TimeZoneDatabase

GPSLocator

UserId

Software classesDomain concepts


Overview

Concepts

Activities

Management

Summary


Object Types Object Types 11

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.


Overview

Concepts

Activities

Management

Summary


Object Types Object Types 22

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)


Overview

Concepts

Activities

Management

Summary


ExampleExample

Analysis classes for the 2Bwatch example

<<entity>>Year

<<entity>>Month

<<entity>>Day

<<control>>ChangeDateControl

<<boundary>>LCDDisplayBoundary

<<boundary>>ButtonBoundary


Overview

Concepts

Activities

Management

Summary


Generalization and Generalization and SpecializationSpecialization

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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

An example of a generalization hierarchy

Incident

LowPriority Emergency Disaster

EarthQuake ChemicalLeakCatInTree

TrafficAccident BuildingFire


Overview

Concepts

Activities

Management

Summary


AgendaAgenda



Overview

Concepts

Activities

Management

Summary


Analysis ActivitiesAnalysis Activities

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


Overview

Concepts

Activities

Management

Summary


From Use Cases to ObjectsFrom Use Cases to Objects

1. Identifying Entity Objects

2. Identifying Boundary Objects

3. Identifying Control Objects

4. Mapping Use Cases to Objects

5. Modeling Interactions among Objects

6. Identifying Associations

7. Identifying Aggregations

8. Identifying Attributes

9. Modeling Objects State-Dependent Behavior

10. Modeling Inheritance Relationship

11. Reviewing the Analysis Model


Overview

Concepts

Activities

Management

Summary


Identifying Entity ObjectsIdentifying Entity Objects

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.


Overview

Concepts

Activities

Management

Summary


Identifying Boundary ObjectsIdentifying Boundary Objects

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.


Overview

Concepts

Activities

Management

Summary


Identifying Control ObjectsIdentifying Control Objects

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.


Overview

Concepts

Activities

Management

Summary


Mapping Use Cases to ObjectsMapping Use Cases to Objects

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


Overview

Concepts

Activities

Management

Summary


ExampleExample

FieldOfficer

ReportEmergencyButton

ReportEmergencyControl

ReportEmergencyForm

EmergencyReport

ManageEmergencyControl

press()

«create»

«create»

submit()

fillContents()

submitReport()

submitReportToDispatcher()

«create»

«destroy»

Sequence diagram for the ReportEmergency use case.


Overview

Concepts

Activities

Management

Summary


Modeling Interactions among Modeling Interactions among ObjectsObjects

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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

Examples of CRC cards for the ReportEmergencyControl and the Incident classes.

ReportEmergencyControl

Responsibilities

Collects input from Field-officerControls sequence of forms during emergency reporting

Collaborators

EmergencyReportFormEmergencyReportAcknowledgementNotice

Incident

Responsibilities

rack all information related to a single inci-

Collaborators

ResourceT

dent.


Overview

Concepts

Activities

Management

Summary


Identifying AssociationsIdentifying Associations

An association shows relationship between two or more classes.1. A name (optional)

2. A role

3. 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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

An example of association between the EmergencyReport and the FieldOfficer classes.

Eliminating redundant association.

* 1writes

author document

FieldOfficer EmergencyReport

* 1writesauthor document

1

11

1

triggersreports

FieldOfficer EmergencyReport

Incident


Overview

Concepts

Activities

Management

Summary


Identifying AggregationsIdentifying Aggregations

Aggregation – is a special type of association denoting a whole-

part relationship.

1. Composition aggregation– indicates that the existence of the parts depends of

the whole.

2. 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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

Examples of aggregations and compositions.

State

County

Township

FireStation

FireFighter

FireEngine

LeadCar

Ambulance


Overview

Concepts

Activities

Management

Summary


Identifying AttributesIdentifying Attributes

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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

Attributes of the EmergencyReport class.

EmergencyReport

emergencyType:{fire,traffic,other}location:Stringdescription:String


Overview

Concepts

Activities

Management

Summary


Modeling State-Dependent Modeling State-Dependent BehaviorBehavior

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.


Overview

Concepts

Activities

Management

Summary


ExampleExample

UML statechart for Incident.

Active

Inactive Closed Archived

all

when date > 1yr.

resourcessubmitted reports

Reported Assessment

DisengagementResponse

field officerarrives on site

field officerreleases resources

dispatcherallocates resources

field officer requestsadditional resources

all resourcesdeallocated


Overview

Concepts

Activities

Management

Summary


Modeling Inheritance Modeling Inheritance RelationshipRelationship

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.

FieldOfficer Dispatcher

PoliceOfficer

badgeNumber:Integer


Overview

Concepts

Activities

Management

Summary


Reviewing the Analysis ModelReviewing the Analysis Model

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.


Overview

Concepts

Activities

Management

Summary


Is Our Model Correct?Is Our Model Correct?

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?


Overview

Concepts

Activities

Management

Summary


Is Our Model Complete?Is Our Model Complete?

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?


Overview

Concepts

Activities

Management

Summary


Is Our Model Consistent?Is Our Model Consistent?

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?


Overview

Concepts

Activities

Management

Summary


Is Our Model Realistic?Is Our Model Realistic?

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?


Overview

Concepts

Activities

Management

Summary


Summary of the Analysis Summary of the Analysis ActivitiesActivities

Reviewmodel

Consolidatemodel

Defineinteractions

Defineassociations

Defineattributes

Definenontrivialbehavior

Defineuse cases

Defineparticipating

objects

Defineboundaryobjects

Definecontrolobjects

Defineentityobjects


Overview

Concepts

Activities

Management

Summary


AgendaAgenda



Overview

Concepts

Activities

Management

Summary


Managing AnalysisManaging Analysis

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


Overview

Concepts

Activities

Management

Summary


Requirements Analysis Requirements Analysis DocumentDocument

1. Introduction2. Current system3. Proposed system

3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models

3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interface

4. Glossary

1. Introduction2. Current system3. Proposed system

3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models

3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interface

4. Glossary


Overview

Concepts

Activities

Management

Summary


Object Models and Dynamic Object Models and Dynamic ModelsModels

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.


Overview

Concepts

Activities

Management

Summary


Assigning ResponsibilitiesAssigning Responsibilities

Roles– Generation of Information– Integration– Review

Participants– The End User– The Client– The Analyst– The Architect– The Document Editor– The Configuration Manger– The Reviewer


Overview

Concepts

Activities

Management

Summary


Participants Participants 11

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 support.

– 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.


Overview

Concepts

Activities

Management

Summary



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.


Overview

Concepts

Activities

Management

Summary



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.


Overview

Concepts

Activities

Management

Summary


Communicating about AnalysisCommunicating about Analysis

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.


Overview

Concepts

Activities

Management

Summary


Iterating over the Analysis Iterating over the Analysis ModelModel

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.


Overview

Concepts

Activities

Management

Summary


Client Sign-OffClient Sign-Off

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.


Overview

Concepts

Activities

Management

Summary


Prioritizing requirementsPrioritizing requirements

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.


Overview

Concepts

Activities

Management

Summary


AgendaAgenda



Overview

Concepts

Activities

Management

Summary


SummarySummary

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


Overview

Concepts

Activities

Management

Summary

Documents

CEN 5011 6 th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi sadjadi/Teaching/ Requirements Analysis: