lecture 6 requirement analysis functional modeling object modeling dynamical modeling non-functional...

Lecture 6

Requirement analysis Functional Modeling Object Modeling Dynamical Modeling Non-functional requirements

Slides adopted from the book and lecture material for the “Object oriented software engineering” by Bruegge & Dutroit

SW Development Process Requirement analysis

Describes what the system is supposed to do. System Analysis

Identifies the structure of the system. Design

Describes how the system is realized. Implementation

Implements the system and performs unit testing Testing

Verifies system

Requirement Analysis: Overview

Three types of modeling Functional modeling Object modeling Dynamic modeling

Functional Modeling: What are the transformations? Create scenarios and use case diagrams

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

Requirement Analysis: Overview

Object Modeling: 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?

Dynamic Modeling: What is its control structure? 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.

How to do Analysis Analyze the problem statement

Identify functional requirements Identify non-functional requirements Identify constraints (pseudo requirements)

Build the functional model: Develop use cases to illustrate functionality requirements

Build the dynamic model: Develop sequence diagrams to illustrate the interaction

between objects Develop state diagrams for objects with interesting behavior

Build the object model: Develop class diagrams showing the structure of the system

Power is turned on Car moves forward and car

headlight shines Power is turned off

Car stops and headlight goes out.

Power is turned on Headlight shines

Power is turned off Headlight goes out.

Power is turned on Car runs backward with its

headlight shining.

Power is turned on Car moves forward and car

headlight shines Power is turned off

Car stops and headlight goes out.


Power is turned off Headlight goes out.

Power is turned on Car runs backward with its

headlight shining.

Problem Statement: Direction Control for a Toy Car

Power is turned off Car stops and

headlight goes out.


Power is turned off Headlight goes

out. Power is turned on

Car runs forward with its headlight shining.

Power is turned off Car stops and

headlight goes out.


Power is turned off Headlight goes

out. Power is turned on


Find the Functional Model: Do Use Case Modeling

Use case 1: System Initialization Entry condition: Power is off, car is not moving Flow of events:

Driver turns power on Exit condition: Car moves forward, headlight is on

Use case 2: Turn headlight off Entry condition: Car moves forward with headlights on Flow of events:

Driver turns power off, car stops and headlight goes out.

Driver turns power on, headlight shines and car does not move.

Driver turns power off, headlight goes out Exit condition: Car does not move, headlight is out

Use Cases continued Use case 3: Move car backward

Entry condition: Car is stationary, headlights off Flow of events:

Driver turns power on Exit condition: Car moves backward, headlight on

Use case 4: Stop backward moving car Entry condition: Car moves backward, headlights on Flow of events:

Driver turns power off, car stops, headlight goes out. Power is turned on, headlight shines and car does

not move. Power is turned off, headlight goes out.

Exit condition: Car does not move, headlight is out.

Use cases continued

Use case 5: Move car forward Entry condition: Car does not move,

headlight is out Flow of events

Driver turns power on Exit condition:


Use Case Pruning

Do we need use case 5?

Use case 1: System Initialization Entry condition: Power is off, car is not moving Flow of events:

Driver turns power on Exit condition: Car moves forward, headlight is on

Use case 5: Move car forward Entry condition: Car does not move, headlight is out Flow of events

Driver turns power on Exit condition:


Find the Dynamic Model: Create sequence diagram

Name: Drive Car Sequence of events:

Billy turns power on Headlight goes on Wheels starts moving forward Wheels keeps moving forward Billy turns power off Headlight goes off Wheels stops moving . . .

Sequence Diagram for Drive Car Scenario

Power(on)

:Headlight Billy:Driver :Wheel

Power(off)

Power(on)

Power(on)

Power(off)

Power(on)

Toy Car: Dynamic ModelState-Chart Diagram

Wheel

Forward

Backward

Stationary Stationary

poweron

poweroff

poweroff

poweron

Headlight

poweron

poweroff

Off

On

Toy Car: Object Model

Wheel

Motion:( ForwardBackward,Stationary)

Start_Moving()Stop_Moving()

Headlight

Status: (On, Off)

Switch_On()Switch_Off()

Power

Status: (On, Off)

TurnOn()TurnOff()

Car

For which system is a particular model most relevant?

Object model: The system has non-trivial data structures.

Dynamic model: The model has many different types of events: Input, output, exceptions, errors, etc.

Functional model: The model performs complicated transformations such as difficult computations consisting of many steps.

For which system is a particular model most relevant?

Examples: Compiler: Functional model most important.

Dynamic model is trivial because there is only one type input and only a few outputs.

Database systems: Object model most important. Functional model is trivial, because their purpose is usually only to store, organize and retrieve data.

Spreadsheet program: Functional model most important. Object model is trivial, because the spreadsheet values are trivial and cannot be structured further. The only interesting object is the cell.

Why Scenarios and Use Cases?

Comprehensible by the user Use cases model a system from the users’ point of

view (functional requirements) Define every possible event flow through the

system Description of interaction between objects

Use cases can form basis for whole development process

User manual System design and object design Implementation Test specification Client acceptance test

Identifying Use Cases

Engage in a dialog, use an evolutionary, incremental approach You help the client to formulate the

requirements The client helps you to understand

the requirements The requirements evolve while the

use cases are being developed

How to Specify a Use Case Name of Use Case Actors

Description of actors involved in use case Precondition

Use a phrase such as “This use case starts when…” Flow of Events

Free form, informal natural language Exceptions

Describe what happens if things go wrong Special Requirements

List nonfunctional requirements and constraints

From Use Cases to Requirement Analysis Model

Both focus on the requirements from the user point of view.

Use cases use natural language (derived from problem statement) Written scenarios

Requirements analysis model uses formal or semi-formal notation (UML) System sequence diagrams Domain model

Identify Conceptual Classes

Candidate classes are possible class names that are being considered as candidates for inclusion in the system.Techniques: noun phrase identification from use

case model or documentation Brainstorming CRC cards Design patterns

Noun Phrase Identification

Read and understand the use case scenarios. Look for noun phrases, mark the nouns Divide into three categories

Definite object Possible object Nonsense object

Discuss “possible objects” and assign them to either of the two other categories

Example

Computer system for library: Books and Journals: The library contains books and

journals. There can be multiple copies a particular book. Books can be borrowed by a library user for a period of six weeks.

Loans: The system needs to keep track of which books are on loan and when they are due.

Possible candidates for conceptual classes: library, system, book, journal, copy, user, period, week, loan

Nonsense objects: week, system Possible objects: library, period Definite objects: book, journal, copy, loan, user

Definition: Object Modeling

Main goal: Find the important abstractions 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

Class Identification

Identify the boundaries of the system Identify the important entities in the

system Class identification is crucial to object-

oriented modeling Basic assumption:

1. We can find the classes for a new software system (Forward Engineering)

2. We can identify the classes in an existing system (Reverse Engineering)

Class Identification

Objects are not just found by taking a picture of a scene or domain

The application domain has to be analyzed. Depending on the purpose of the system

different objects might be found How can we identify the purpose of a system? Scenarios and use cases

Another important problem: Define system boundary. What object is inside, what object is outside?

Pieces of an Object Model

Classes Associations (Relations)

Part of- Hierarchy (Aggregation) Kind of-Hierarchy (Generalization)

Attributes Detection of attributes Is something an attribute or a class (e.g. money)

Methods Detection of methods Generic methods: General world knowledge, design

patterns Domain Methods: Dynamic model, Functional model

Object vs Class Object (instance): Exactly one thing

The lecture on Wednesday 19/9 from 8-10 on Analysis

A class describes a group of objects with similar properties Sale, Customer, Item, Lecture…

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

Class and Instance Diagrams

Inspector

joe:Inspector

mary:Inspector

anonymous:Inspector

Class Diagram

Instance Diagram

Attributes and Values

name:stringage: integer

Inspector

name = “Joe”age = 24

joe:Inspector

name = “Mary”age = 18

mary: Inspector

Links and Associations

Links and associations establish relationships among objects and classes.

Link: A connection between two object instances.

A link is like a tuple. A link is an instance of an association

Association: Basically a bidirectional mapping. One-to-one, many-to-one, one-to-many, An association describes a set of links like a

class describes a set of objects.

1-to-1 and 1-to-N Associations

has-capital

1-1 association

1-N association

City

name

OrderItem

priceproductID

*

Country

name

date

contains

Object Instance Diagram

Example for 1-to-N

:Item

Price:9,90ItemID : 105

:Order

:Item


:Item


Many-to-Many Associations

places **Customer Order

Aggregation

Models "part of" hierarchy Useful for modeling the breakdown of a

product into its component parts UML notation: Like an association but with

a small diamond indicating the assembly end of the relationship.

weight

Automobile

serial numberyearmanufacturermodelcolor

drivepurchase

Aggregation

Engine

horsepowervolume

onoff

3,4,5

Wheel

diameternumber of bolts

2,4

Door

openclose

Battery

ampsvolts

chargedischarge

*

Brakelight

onoff

Inheritance Models "kind of" hierarchy Powerful notation for sharing similarities among

classes while preserving their differences UML Notation: An arrow with a triangle

Cell

MuscleCellBloodCell NerveCell

StriateSmoothRed White PyramidalCortical

Aggregation vs Inheritance

Both associations describe trees (hierarchies) Aggregation tree describes “a-part-of

“relationships (also called and-relationship) Inheritance tree describes "kind-of"

relationships (also called or-relationship) Aggregation relates instances (involves two

or more different objects) Inheritance relates classes (a way to

structure the description of a single object)

Other Associations Uses:

An object uses another object : Player moves Token Contains:

Sometimes called “spatial aggregation” ... contains ... Example: an order contains items

Parent/child relationship: ... is father of ... ... is mother of ...

Seniority: ... is older than ... ... is more experienced than ...

Requirement Analysis Challenging activity Requires collaboration of people with

different backgrounds User with application domain knowledge Developer with implementation domain knowledge

Bridging the gap between user and developer: Scenarios: Example of the use of the system in

terms of a series of interactions with between the user and the system

Use cases: Abstraction that describes a class of scenarios

System Model Scenarios

- As-is scenarios, visionary scenarios Use case model

- Actors and use cases Object model

- Data dictionary- Class diagrams (classes, associations, attributes and

behaviors) Dynamic model

- State diagrams for classes with significant dynamic behavior

- Sequence diagrams for collaborating objects (protocol)

System Identification

Development of a system is not just done by taking a snapshot of a scene (domain)

Definition of the system boundary What is inside, what is outside?

How can we identify the purpose of a system? Requirement Process:

Requirements Elicitation: Definition of the system in terms understood by the customer (use cases)

Analysis: Technical specification of the system in terms understood by the developer (sequence diagrams, class diagrams)

Why different kinds of models?

Use case model (user oriented view of the domain) Domain model (analysis model, analyst oriented

view of the domain) Design model (view of software concepts in the

domain) Each type of model describes the same system but

from a different perspective and at a different level of abstraction.

They provide different kinds of information (e.g. dynamic, static view of the system, or functionality oriented vs. solution oriented)

Types of Requirements

Functional requirements: Describe the interactions between the system and its environment independent from implementation The system must record sales.

Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. The response time must be less than 5 second The display should be readable from 1 meter.

Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate The implementation language must be JAVA.

Nonfunctional Requirements

Usability Reliability Performance Supportability Implementation Interface Operations


Usability: 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?


Usability : Documentation What kind of documentation is required? What audience is to be addressed by each

document?

Implemenation: 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?


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? Reliability: Error handling and extreme

conditions How should the system respond to input

errors? How should the system respond to extreme

conditions?


Interface 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?

Supportability : System Modifications What parts of the system are likely

candidates for later modification?


Reliability : Quality issues What are the requirements for reliability? Must the system trap faults? Is there a maximum acceptable 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)?

What sorts of modifications are expected?


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


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

controlled? Is physical security an issue?

Operation : 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?

Pseudo Requirements

Pseudo requirement: Any client restriction on the solution domain

Examples: The target platform must be a SUN/SPARC The implementation language must be JAVA The documentation standard X must be used A data-glove must be used ActiveX must be used The system must interface to a barcode reader

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

Requirements Validation

Requirements validation criteria: Correctness:

The requirements represent the client’s view.

Completeness: All possible scenarios through the system

are described, including exceptional behavior by the user or the system

Consistency: There are functional or nonfunctional

requirements that contradict each other

Requirements Validation

Clarity: There are no ambiguities in the

requirements. Realism:

Requirements can be implemented and delivered

Traceability: Each system function can be traced to a

corresponding set of functional requirements

lecture 6 requirement analysis functional modeling object modeling dynamical modeling non-functional...

Documents

car headlight shinespower

power onexit condition

headlight offentry condition

headlight onuse case

car backwardentry condition

case diagrams

case modelinguse case

outexit condition