OOSE - Analysis Req

8/9/2019 OOSE - Analysis Req

1/18

30/09/2006 SE6161 Analisis Rekayasa Perangkat Lunak Slide 1

OOSEOOSE AnalysisAnalysis

Requirement ModelRequirement Model


2/18

SE6161 Analisis Rekayasa Perangkat Lunak Slide 230/09/2006

Analysis The aim is to analyze, specify, and define the system

to be built

The models developed will describe what the system is to do

will make it easier for us to understand the system

are fully application- oriented (no consideration is paid tothe real implementation environment)

can be used without changing even if the implementationenvironment changed

Two models are yielded: the requirements model

the analysis model.


3/18


Requirement Model

Requirement model:describes all the functional requirements

from user perspective

describes the way the system is to beused by end users

structured from a logical perspective into a

robust and maintainable system.based on the requirement specification

and discussions with the prospectiveusers


4/18


Requirement Model (2)

Consists of:Use case model

Interface description

Problem domain object model


5/18


Use Case Model

Uses actors and use cases

Actor are not part of the system, they represent roles a user of

the system can play.

may actively interchange information with the system.

may be a passive recipient of information.

can represent a human, a machine or another system.

Use case models a dialogue between actors and the system.

is initiated by an actor to invoke a certain functionality inthe system.

models a dialogue between one or more actors and thesystem that returns a result of measurable value to atleast one actor.

is a complete and meaningful flow of events.

represents a major system usage goal for one or more

of the actors that interact with the use case.

Actor

Use-Case


6/18


Use Case Model (2) Activity:

Identify actors (by identifying the users of the system)

Identify use cases through actors by asking a number of questions: What are the main tasks of each actor?

Will the actor hate to read/write/change any of the system information?

Will the actor have to inform the system about outside changes?

Does the actor wish to be informed about unexpected changes?

Draw the use case diagram to show relationships between actors anduse cases

Use extension association between use case to specify how one use casedescription may be inserted into another use case description

Describe the use cases Describe the basic flow

Describe alternative flows


7/18


Use Case Diagram - Extension

Extends; defines alternative courseof events:

optional parts of use cases

complex and alternative courseswhich seldom occur

separate sub-courses which are

executed only in certain casessituation where several different use

case can be inserted into a specialuse case


8/18


Interface Description The interface has to capture the user's logical view of the

system

the main interest is the consistency of this logical view and the actualbehavior of the system.

Techniques:

Use sketches of what the user will see on the screen when performing

the use case

Simulations using a User Interface Management System (UIMS)

Such a technique will eliminate several possibilities for

misunderstandings It is important that users are involved in making detailed

interface descriptions.


9/18


Problem Domain Object Model

The model is the identification of the objects that have adirect counterpart in the application environment and that

the system must know about.

The refinement of the problem domain objects can be

obtained in different possible degrees: object name

logical attributes

static instances associations

inheritance

dynamic instance associations

operations


10/18


Problem Domain Object Model (2)


11/18


Discussions How complete the use cases should be? Generally, it is better to have longer and more extensive use cases than

several smaller ones.

The arguments in favor of having the sequence as one complete use case are:

When specifying the use case, we may follow a complete flow through the entiresystem

From the orderers point of view, it is a logical cohesive flow of events in the system

It may be more effective when testing the use case since it covers more logicalcohesive events in the system

It is easier to synchronize the use case since it is one sequence that starts diffeentevents in chronological order

The arguments in favor of separating the use case into several different usecases are: It may be troublesome to find the right instance of a use case

From a potential actors view, it is more logical to have use cases that the actorstarts

It may be easier to test the use case since every use case starts from externalevents and not from internal system events


12/18


Example - Recycling Machine System

Crates

Bottles

Cans

Receipt


13/18


ExampleRecyling Machine System

The system controls a recyling machine forreturnable bottles, cans, and crates. Each customercan return all three types of item on the sameoccasions. Since there may be different types and

sizes of bottle and can, the system has to check, foreach item, what type has been returned.

The system will register how many items each

customer returns and, when the customer ask for areceipt, the system will print out what he/shedeposited, the value of the returned items and thetotal return sum that will be paid to the customer.


14/18


ExampleRecyling Machine System

The system is also used by an operator. Theoperator wants to know how many items of eachtype have been returned during the day. At the endof the day, the operator asks for print out of the total

number of items that have been deposited in themachine on that particular day. The operator shouldalso be able to change information in the system,

such as deposit values of the item. If there issomething amiss, for instance if a can gets stuck or ifthe receipt roll is finished, the operator will be calledby a special alarm signal


15/18


Use Case Diagram ExampleRecycling Machine System

Returning Item

Generate Daily Report

Change Item

Customer Operator


16/18


Use Case Diagram Example - Extends

Returning Item

Generate Daily Report

Change Item

Customer Operator

Item Stuck

extends


17/18


Example - Recycling Machine System

Deposit Item

Bottles CratesCans

inheritsinheritsinherits

Receipt Customer

Returned items My receipt


18/18


Refinement of the Requirement Model

Print

Returning Item Generate Daily Report

usesusesReceipt Receiver

Customer Operator

inherits inherits

OOSE - Analysis Req

Documents

Transcript of OOSE - Analysis Req