Download ppt - CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 8 CS 8532: Advanced Software Engineering Dr. Hisham Haddad Class will start momentarily

CS 8532: Adv. Software Eng. – Spring 2009Dr. Hisham Haddad

Chapter 8

CS 8532: Advanced Software Engineering

Dr. Hisham Haddad

Class will

start momentarily.

Please Stand By …


Analysis Modeling

Part I

Elements and methods of analysis modeling Chapter 8


Requirements Analysis

• Requirements analysis – specifies software’s operational characteristics– indicates software's interface with other system elements – establishes constraints that software must meet

• Requirements analysis allows the software engineers to:– elaborate on basic requirements established during earlier

requirement tasks

– build models to depict user scenarios, functional activities, needed classes and their relationships, system behavior, and data flow and transformation.

– define requirements that can be validated once the system is built (bridging system description and deign model)


Modeling Rules of Thumb• The model should focus on requirements that are visible

within the problem or business domain. The level of abstraction should be relatively high.

• Each element of the model should add to the understanding of the requirements and provide insight into the information domain, functions, and behavior of the system.

• Delay consideration of infrastructure and other non-functional models until design.

• Minimize coupling throughout the system (less dependency). • The analysis model should provide value to all stakeholders

(customer, designer, QA). • Keep the model as simple as possible.


Domain Analysis - 1

““Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . . [Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks . . .”

Donald Firesmith


Domain Analysis - 2

• Define the domain to be investigated

• Collect a representative sample of applications in the domain

• Analyze each application in the sample

• Develop an analysis model for the objects


Domain Analysis - 3

Why do it? To build robust reusable components, lower cost, higher

quality, and improve time to market.

DOMAIN ANALYSIS

Sources of domain

Knowledge

Domain Analysis

Model

class taxonomies

reuse standards

functional models

domain languages

technical literature

existing applications

customer surveys

expert advice

current/future req.


Analysis Modeling Approaches - 1

What is Analysis Modeling? A set of modeling activities that result in technical

representation (using text and diagrams) of system requirements (data, functions, and behavior).

How do we conduct it? - Structured Analysis (data objects and processes) - OOA (classes and object relationships)

Note that all approaches lead to same modeling elements. The difference is in the representation.



Why do Analysis Modeling?

- to represent/express customer requirements/needs of the system

- to build groundwork/foundations for the design phase

- to define system requirements that can be validated once the application is developed



Where to begin? - Prepare statement of scope derived from the FAST meeting document and/or use-cases. - Parse the statement of scope to extract data, function, and behavioral domain information.

A scope document may include, but not limited to, the following info: - inputs and outputs (data and controls) - functions of the system - performance and reliability requirements - interface requirements - constraints and limitations that may be applicable to data and functions


How to Identify Data Objects and Functions

Define “data objects” by underlining all nouns in the statement of scope

- producers/consumers of data - places where data are stored - composite data items

Define “functions” by double underlining all active verbs - processes relevant to the application - data transformations - services that will be required by the data objects


Section 8.3: Data Modeling

What is it? - identifying data objects of the system, - defining the attributes for each data object, - identifying relationships among data objects, and - creating a model at the customer’s level of abstraction.

Purpose: To examine data objects independently of processing.

Main elements of the data model are: Data objects, Attributes, and Relationships.


Data Objects - 1

What is a data object? It is an entity of the system described by a set of attributes

(data items) and that will be manipulated by the software system.

Each instance of a data object (student) is uniquely identified by an attribute (student ID).

Each data object plays a role in the system and the system could not function without access to instances of that object.

Data objects and their attributes are stored in the data dictionary.


Data Objects - 2

Typical data objects:

- external entities (printer, user, sensor, copier, fax, car) - things (reports, displays, signals) - occurrence/event (phone call, alarm, transmission) - roles (manager, engineer, salesperson, student, faculty) - organizational units (division, team, department, college) - places (assembly line, storage, classroom, launch pad) - structures (employee record, transcript, class schedule)


Attributes

A data object has a set of attributes (data items or variables) that act as an aspect, quality, characteristic, or descriptor of the object.

Object: Student

Attributes:

Name ID Home Address Work Address Personal Info Academic Info ...

Object: Car

Attributes:

Make Model ID Color Body type Price ...


Data Dictionary View

Data dictionary information for a data item (e.g., student name)of a data object (e.g., student).

Data Item Information

NameAliasData Structure (type)DescriptionDuration (begin)AccuracyRange of valuesData flow…

Description

Identifies data itemsOther names and abbreviationsType of data (int, float, char, etc…)Indicates how and why data items is usedLife span of data item (when created)Indicates accuracy level (high, medium, low)Indicates valid valuesProcess(es) that create/receive data item…


Relationships

A relationship indicates connection between data objects.

- Relationships are not computed, they are facts that the system needs to know about.

- Several instances of a relationship can exist between data objects.

- Data objects can be related in many different ways.

e.g., John owns the car John drives the car Amy owns the van John married to Amy

See figure 8.5, page 183 for diagrammatic representation.


Cardinality and Modality Notation

Cardinality: max number of occurrences of objects in a relationship (number/symbol closer to the object) (1:1, 1:n, m:n)

Modality: indicates whether the relation is optional or required. (2nd number of the pair or the further away symbol)

(m, 0) (0, 1)

object 1 object 2relationship

relationshipobject 1 object 2(m, 1) (1, 1)

attribute


ERD Example

(1,1)

(1,1) (1,m)placesCustomer

requestfor service

generates(1,n)

(1,1)

workorder

worktasks

materials

consistsof

lists

(1,1)(1,1)

(1,1)

selectedfrom

standardtask table

(1,n)

(1,1)


Section 8.4: OO Analysis The Big Picture

Domain Level

System Level

Domain Engineering

System Engineering

OO Engineering

Software Engineering

Structured AnalysisStructured DesignImplementationProcedural TestingDeployment

OO AnalysisOO DesignImplementationOO TestingDeployment


The Big Picture


ObjectRelationship

Modeling

ClassModeling

ObjectBehaviorModeling

Structured AnalysisStructured DesignImplementationProcedural TestingDeployment

Data Modeling

Behavioral Modeling

FunctionalModeling


OO Concepts

• OO concepts must be understood to apply class-based elements of the analysis model

• Key concepts:– Classes and objects– Attributes and operations– Encapsulation and instantiation– Inheritance


Classes

• Object-oriented thinking begins with the definition of a class, often defined as:– template– generalized description– “blueprint” ... describing a collection of similar items

• A metaclass (also called a superclass) establishes a hierarchy of classes

• Once a class of items is defined, a specific instance of the class can be identified


Building Classes

class name

attributes:

operations:

attributes:

operations


What is in a Class

external entities

things

occurrences roles

organizational units

places

structures

class name

attributes:

operations:


Encapsulation

The object encapsulatesboth data and the logicalprocedures required tomanipulate the data

method # 1

data

method # 2

method # 4

method # 5

method # 6

method # 3


Class Hierarchy

ChairTable Desk ”Shelf"

PieceOfFurniture (superclass)


Methods

An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class. A method is invoked via message passing.


SA vs. OOA

SA:

Focus on functional decomposition

Input-Process-Output view

Data is separate from processes

OOA:

Focus on objects

Real-world view

Data and processes are grouped together


OOA Methods

OOA methods vary in their process steps, diagrams, notations, terminologies, but they all share an overall process and produce similar results.

Examples:

• Booch method• Rumbaugh method• Jacobson method• Coad/Yourdon method• Wirfs/Brock method

Later become the unified approach (Unified Modeling Language - UML)


The UML Approach

UML is a modeling language that can be used with any modeling method/process.

UML components: Syntax ===> the look of each symbol. Semantic ===> the meaning of each symbol. Pragmatic Rules ===> the intention/purpose of grouped symbols.

UML Views of a System: User model view (user view via use-cases) Structural model view (data and functionality view - static structure) Behavioral model view (object interactions view - dynamic structure) Implementation model view (the software details) Environment model view (the environment aspects - static/dynamic)


Key Components of OOA

Static components: - classes class attributes (to define object states) class relationships (to define object operations/messages)

Dynamic components: - interactions among objects (object communications) - control events that cause state transitions

ClassModeling


ObjectRelationship

Modeling

ObjectBehaviorModeling


OOA Process

1. Define use-cases (next few slide)2. Extract/Select candidate classes3. Identify attributes for each class4. Specify methods that service the attributes of each class5. Establish basic class relationships6. Define a class hierarchy7. Build a behavioral model

Repeat these steps for lower-level (other) use-cases.

Steps 2 -5 are done using CRC modeling approach.


8.5: Scenario-Based Modeling

“[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” Ivar Jacobson

• A scenario that describes a thread of usage for a system• Actors represent the roles entities (people or devices) play as

the system functions• An entity (user) can play a number of different roles for a

given scenario• High-level use-case may be elaborated by lower-level use-

cases• In UML, use-cases are represented by use-case diagrams,

activity diagrams, and swimlane diagrams.


Use-Cases

Developing use-cases:

- What are the main tasks (functions) that the actors performs? - What system information will the the actor acquire, produce or

change? - Will the actor have to inform the system about changes in the

external environment? - What information does the actor desire from the system? - Does the actor wish to be informed about unexpected changes?

Please read the report “Structuring Use Cases with Goals” at:

http://alistair.cockburn.us/Structuring+use+cases+with+goals


Description of Use-Cases

Textual description can be in any format. (See author’s approach on page 188)

For this class, we are following a table format. A template is given in the “SRS Components” document on the website. (compare the template to the that on page 190)

Examples of use-case descriptions are posted on the Project Page.


Use-Cases DiagramPage 191.

homeowner

Access camera surveillance via the

Internet

Configure SafeHome system parameters

Set alarm

cameras

SafeHome


Activity and Swimlane Diagrams

Activity diagram (similar to flowchart) supplements a use-case by providing a diagrammatic representation of procedural flow (flow of events in a scenario) See example page 192.

Swimlane diagram is a variation of the activity diagram. It allows the representation of the flow of activities described by the use-case and it indicates which actor (if multiple actors are involved) or analysis class has responsibility for the action described by an activity rectangle (Diamonds). See example page 193.

Read this section 8.4 for Safehome example.


Section 8.6: Flow-Oriented Modeling(for Structured Analysis)

Data Flow Diagram (DFD) represents data flow (information flow modeling) as data elements are being processed (functional modeling) in the system

DFD is a formal part of UML. However, it complements UML representation

DFD allows system representation at any level (level 0, etc…)

Elements of a DFD include: external entity, process, and data flow, and data store.


Flow Modeling Notation

external entity

process

data flow

data store


External Entity

A producer or consumer of data

Examples: a person, a device, a sensor, a computer-based system

Data must always originate somewhere and must always be sent to something (process or entity).


Process

A data transformer (changes input to output)

Examples: compute taxes, determine area, format report, display graph, print report, etc…

Data must always be processed in some way to achieve system function.


Data Flow

Data flows through a system, beginningas input and be transformed into output.

base

height

areacompute triangle

area


Data Store

Data is often stored for later use.

look-upsensordata

sensor #

report required

sensor #, type, location, age

sensor numbertype, location, age

sensor data


Building a DFD

1. Review ERD to isolate data objects and apply grammatical parse to determine operations

2. Determine external entities (producers and consumers of data objects)

3. Develop a level 0 DFD4. Write a narrative describing the transform (operations)5. Parse the narrative to determine next level operations6. Maintain data flow continuity7. Develop a level 1 DFD8. Use a 1:5 (approx.) expansion ratio9. Repeat steps 4 - 7 for other detailed levels (refinement)


DFD Guideline

• All icons must be labeled with meaningful names• The DFD evolves through a number of levels of detail• Always begin with a context level diagram (level 0)• Always show external entities at level 0• Always label data flow arrows• Do not represent procedural logic (loop and decisions)• Each process is refined until it does just one thing/task• The expansion ratio decreases as the number of levels

increase


Level 0 DFD Example

userprocessing

request

videosource video

signal

digitalvideo

processor

requestedvideosignal

monitor


Data Flow Hierarchy

See Figures 8.10 and 8.11, page 196.

Pa b

x y

p1p2

p3p4 5

a

b

c

de

f

g

level 0

level 1


DFD and Design

Maps intoMaps intoAnalysis model

Design model


Behavioral (Control Flow) Modeling(For Structured Analysis)

Behavioral (control flow) modeling is modeling how the software will interact with external entities (events and control items).

A State Transition Diagram (STD) shows system states, events that cause state transition, and actions taken in response to events.

State: observable circumstances that characterizes the behavior of a system at a given time.

Event: an occurrence that causes the system to exhibit some predictable form of behavior.

Action: process that occurs as a consequence of making a transition.


Behavioral Representation

How to begin?

- Identify a list of the different states of a system (How does the system behave?)

- indicate how the system makes a transition from one state to another (How does the system change state?) - events (clock signals, interrupt conditions, switches,

…) - actions (responses to events/requests)

- develop STD


STD Notation

STD notation is an extension to structured analysis.

event causing transition

action that occurs

state

new state


STD Example

ReadingOperator

Command

making copies

reloading paper

problem state

full and start

invoke manage-copying

copies doneinvoke read-op-input

fullinvoke read-op-input

emptyinvoke reload paperjammed

invoke problem-diagnosisnot jammed

invoke read-op-input

See another example page 199


Control Flow Diagram (CFD) - 1

- It is a main extension to structured analysis notation.

- CFD is "superimposed" on the DFD. It shows events that control the processes noted in the DFD

- Control flows (events and control items) are noted by dashed arrows

- Control specs (CSPEC) is a separate specification that describes how control events are handled

- Dashed arrow entering a vertical bar ( | ) is an input to the CSPEC



- Dashed arrow leaving a vertical bar ( | ) is an output of the CSPEC (another control event)

- A dashed arrow entering a process implies a control input read directly by the process

- A dashed arrow leaving a process is a data condition or control event

Note: the CSPEC section of a “Structured Analysis” document may include:

- state transition diagram - state transition table



Produceuser

displayStart/Stop event

Paper feed status event(jammed or empty)

Performproblem

diagnosis

Manage copying

Reloadpaper

Manage copying

Alarm event

Full Fault event


Guidelines for Building CSPEC• list all sensors that are "read" by the software • list all interrupt conditions • list all "switches" that are actuated by the operator• list all data conditions • recalling the noun-verb parse that was applied to the software

statement of scope, review all "control items" as possible CSPEC inputs/outputs

• describe the behavior of a system by identifying its states; identify how each state is reach and defines the transitions between states

• focus on possible omissions ... a very common error in specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?"


Section 8.7: Class-Based Modeling(for OO Analysis)

See Chapter 8 Slides - Part II