Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) O bject- O riented S oftware C onstruction Chapter 5, Requirements Analysis

Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho

(based on Bruegge & Dutoit)

Object-Oriented

Software

Construction

Chapter 5, Requirements Analysis (2/2)

Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2

Analysis Object Model:Identifying Participating Objects

Pick a use case and look at its flow of events Find terms that developers or users need to clarify in

order to understand the flow of events Look for recurring nouns (e.g., Incident), Identify real world entities that the system needs to

keep track of (e.g., FieldOfficer, Dispatcher, Resource), Identify real world procedures that the system needs

to keep track of (e.g., EmergencyOperationsPlan), Identify data sources or sinks (e.g., Printer)

Be prepared that some objects are still missing and need to be found:

Model the flow of events with a sequence diagram

Always use the user’s terms


Analysis Object Model:Example – Analyzing The Flow of events (1/2)

Flow of events The customer enters the store to buy a toy It has to be a toy that his daughter likes and it must

cost less than 50 Euro. An assistant helps him. The suitability of the toy depends on the age of the

child. His daughter is 8 years old The assistant recommends a type of toy, namely the

board game “Monopoly“ Not a good description, but okay as an example


Grammatical construct

UML Component

Proper noun Object

Common noun class

verb Method

Classifying verb Inheritance

Having Verb Aggregation

modal Verb Constraint

Adjective Attribute

Intransitive verb Method

Analysis Object Model:Example – Analyzing with Abbott’s (2/2)

Example

“Monopoly"

“toy“, “board game”

“enters"

“is a" ,“either..or", “type of…""Has a ", “consists of"

“must be", “less than…"

"8 years old"

“depends on…."


Analysis Object Model:Three Object Types

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

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


Analysis Object Model: Example - Breakout Game

Display

LeftButton

RightButton

GameControl Points

HighScore

Boundary Objects Control Objects Entity Objects

GameState


Analysis Object Model: Example - Breakout Game (Naming in UML)

UML provides several mechanisms to extend the language

UML provides the stereotype mechanism to present new modeling elements

<<Entity>> Display

<<Entity>> LeftButton

<<Entity>> RightButton

<<Control>>GameControl

<<Boundary>> Points

<<Boundary>> HighScore

<<Boundary>> GameState


Identifying Key Objects:Entity Objects

Represents persistent or long-lived information tracked by the system

Real-World entities (FieldOfficer) Real-World activities (EmergencyOperationsPlan)

Recurring Nouns that are used in the UCs Data Sources or Sinks

Represent the persistent information tracked by the system (Application domain objects,

“Business objects”)


Identifying Key Objects:Boundary Objects

Represent the system interface for the actors Forms, Messages, Terminals for different users

Identify Forms the user needs to enter data into the system

Identify messages the system uses to respond to the user

Identify terminals (computers) that are given to each actor

Described in End User Terms Good: EmergencyReportForm, ReportButton Bad: MenuItem, ScrollBar (too detailed)

Represent the interaction between the user and the system


Identifying Key Objects:Control Objects

Responsible for coordinating boundary and entity objects Collecting information from boundary objects Dispatching it to entity objects Control of distributed systems

One Control Object per Use Case (no counterpart in real world) Life span covers the extent of a use case (user

session)

Represent the control tasks

performed by the system


Identify dependencies:Generalization and specialization

Inheritance as the guiding concept Generalization

Abstract activity or concept out of low-level ones Specialization

Start with the general case + refinement

Button

ZoneButtonCancelButton


Identify dependencies:Associations and Aggregates

An Association consists of Name Roles (2 or more) Multiplicity

Can be derived from UC (verbs), i.e. „man has two children“

Important for entity objects Important information of the application domain

(compare with ER-Model in the database world)

Look out for Aggregations Note the difference between

Composition (Lifetime is dependent) (Shared) aggregation


Steps to Analysis (1/3)

Formulate a few scenarios with the help from the end user and/or application domain expert

Extract the use cases from the scenarios, with the help of application domain expert

Analyze the flow of events, i.e. with Abbot's textual analysis Generate the class diagrams, which includes the following

steps: Class identification (textual analysis, domain experts). Identification of attributes and operations (sometimes before

the classes are found!) Identification of associations between classes Identification of multiplicities Identification of roles Identification of constraints


Steps to Analysis – Management (2/3)

Explicitly schedule meetings for object identification

First just find objects Then try to differentiate them between entity,

interface and control objects Find associations and their multiplicity

Unusual multiplicities usually lead to new objects or categories

Identify Inheritance: Look for a Taxonomy, Categorize

Identify Aggregation

Allow time for brainstorming Iterate, iterate, iterate …


Steps to Analysis – Problems (3/3)

Missing domain know how Missing technical knowledge Disagreements between developers and users Important decisions are deferred


Dynamic Modeling

Definition of dynamic model A collection of multiple state chart diagrams, one state

chart diagram for each class with important dynamic behavior.

Purpose: Detect and supply methods for the object model

How do we do this? Start with use case or scenario Model interaction between objects sequence

diagram Model dynamic behavior of a single object state

chart diagram Entity objects normally must not have any dynamic behavior


Dynamic Modeling with UML

Sequence Diagram Can be read out of use cases Dynamic behavior of a set of objects arranged in time

sequence Good for real-time specifications and complex

scenarios Information of the life time of objects Relationships between objects (need for interfaces)

State Chart Diagram describes the dynamic behavior of a single object A state machine that describes the response of an object

of a given class to the receipt of outside stimuli (Events).


Dynamic Modeling with CRC(Classes, Responsibilities, Collaborators)

Tracking tool [Beck and Cunningham 1989]

Card Game One Card represents one class

(CoinControl) Describe the resonsibities of that

class (checkInsertedCoin) Describe the needed classes

(CoinDescription) Can be used for discussing design

ClassName

Responsibities...

Needed Classes

...


Dynamic Modeling of User Interfaces

Statechart diagrams can be used for the design of user interfaces Also called Navigation Path

States: Name of screens Graphical layout of the screens associated with the

states helps when presenting the dynamic model of a user interface

Activities/actions are shown as bullets under screen name Often only the exit action is shown

State transitions: Result of exit action Button click Menu selection Cursor movements

Good for web-based user interface design


Practical Tips for Dynamic Modeling

Construct dynamic models only for classes with significant dynamic behavior

Consider only relevant attributes Use abstraction if necessary

Look at the granularity of the application when deciding on actions and activities

Reduce notational clutter Try to put actions into state boxes (look for identical

actions on events leading to the same state)


Summary: Requirements Analysis

1. What are the transformations? Create scenarios and use case diagrams

Talk to client, observe, get historical records, do thought experiments

2. What is the structure of the system? Create class diagrams

Identify objects. What are the associations between them? What is their

multiplicity? What are the attributes of the objects? What operations are defined on the objects?

3. What is its behavior? Create sequence diagrams

Identify senders and receivers Show sequence of events exchanged between objects. Identify

event dependencies and event concurrency. Create state diagrams

Only for the dynamically interesting objects.

Dynamic Modeling

Functional Modeling

Object Modeling


Requirements Analysis Document Template

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


Section 3.5 System Model

3.5.1 Scenarios As-is scenarios, visionary scenarios

3.5.2 Use case model Actors and use cases

3.5.3 Object model Data dictionary Class diagrams (classes, associations, attributes and

operations) 3.5.4 Dynamic model

State diagrams for classes with significant dynamic behavior

Sequence diagrams for collaborating objects (protocol) 3.5.5 User Interface

Navigational Paths, Screen mockups Prototypes

Done.


Nonfunctional Requirements: Trigger Questions (1/4)

3.3.1 User interface and human factors What type of user will be using the system? Will more than one type of user be using the system? What sort of training will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from

making errors? What sort of input/output devices for the human interface

are available, and what are their characteristics? 3.3.2 Documentation

What kind of documentation is required? What audience is to be addressed by each document?

3.3.3 Hardware considerations What hardware is the proposed system to be used on? What are the characteristics of the target hardware,

including memory size and auxiliary storage space?



3.3.4 Performance characteristics Are there any speed, throughput, or response time

constraints on the system? Are there size or capacity constraints on the data to be

processed by the system? 3.3.5 Error handling and extreme conditions

How should the system respond to input errors? How should the system respond to extreme conditions?

3.3.6 System interfacing Is input coming from systems outside the proposed

system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must

be used for input or output?



3.3.7 Quality issues What are the requirements for reliability? Must the system trap faults? What is the maximum time for restarting the system after a

failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to

different hardware or operating system environments)? 3.3.8 System Modifications

What parts of the system are likely candidates for later modification?

What sorts of modifications are expected? 3.3.9 Physical Environment

Where will the target equipment operate? Will the target equipment be in one or several locations? Will the environmental conditions in any way be out of the

ordinary (for example, unusual temperatures, vibrations, magnetic fields, ...)?



3.3.10 Security Issues Must access to any data or the system itself be

controlled? Is physical security an issue?

3.3.11 Resources and Management Issues How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance?


Constraints (Pseudo Requirements)

Constraint: Any client restriction on the solution domain

Examples: The target platform must be an IBM/360 The implementation language must be COBOL The documentation standard X must be used A dataglove must be used ActiveX must be used The system must interface to a papertape reader


Modeling Checklist for the Review

Is the model correct? A model is correct if it represents the client’s view of the the

system: Everything is the model represents an aspect of reality

Is the model complete? Every scenario through the system, including exceptions, is

described. Is the model consistent?

The model does not have components that contradict themselves (for example, deliver contradicting results)

Is the model unambiguous? The model describes one system (one reality), not many

Is the model realistic? The model can be implemented without problems


Prioritizing 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


Class-diagrams have different types of „users“

According to the development activity, the developer plays different roles. User, User Advocate Analyst System-Designer, Detailed Designer Implementer

In small systems some of the roles do not exist or are played by the same person.

Each of these roles has a different view about the models

Application Domain Model

Solution Domain Model


Application domain vs. solution domain

Application domain: The problem domain (financial services, meteorology,

accident management, architecture, …). Application domain class

An abstraction in the application domain. If we model business applications, these classes are also called business objects.

Example: Board game, Tournament Solution domain

Domains that help in the solution of problems (tele-communication, data bases, compiler construction, operating systems, ….)

Solution domain class An abstraction, that is introduced for technical reasons,

because it helps in the solution of a problem. Examples: Tree, Hashtable, Scheduler


The Role of the Analyst

The analyst is interested in application classes: The associations between

classes are relationships between abstractions in the application domain.

whether the use of inheritance in the model reflect the taxonomies in the application domain.

Definition Taxonomy: A hierarchy of abstractions

The analyst is not interested in the exact signature of operations in solution classes


The User and the User Advocate

User Creates requirements (together with the Analyst) Has Application Know How

User Advocate Mediates between user and analyst Very important job

The more the user is involved into design the more the user advocate is needed (Participatory Design)

Background Technical interested user or analyst who knows the application domain very well


Summary

From use cases to class diagrams Model and Reality Activities during Object Modeling Object and Class Identification

entity, boundary and control objects Abbott’s technique helps in object identification

Users of class diagrams Dynamic modeling

Sequence diagrams State diagrams

Using dynamic modeling for the design of user interfaces Non-functional requirements analysis Requirements analysis model validation Roles within the Analysis Process

Documents

Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) O bject- O riented S oftware C onstruction Chapter 5, Requirements Analysis