CTIS 359 Principles of Software Engineeringcsevgi.bilkent.edu.tr/courses/ctis359/week4.pdfDiagram 0...

53
CTIS 359 Principles of Software Engineering System Models Cüneyt Sevgi CTIS 359 Fall 07-08

Transcript of CTIS 359 Principles of Software Engineeringcsevgi.bilkent.edu.tr/courses/ctis359/week4.pdfDiagram 0...

CTIS 359 Principles of

Software Engineering

System Models

Cüneyt Sevgi CTIS 359 Fall 07-08

Today’s objectives

To explain DFDs for

requirements capturing and

modeling.

To explain Use-Cases for

requirements capturing and

modeling.

Cüneyt Sevgi CTIS 359 Fall 07-08

Data Flow Diagrams (DFDs)

Notation for writing semi-formal operationalspecifications

◦ Graphical notation

◦ Well-suited for analyzing/specifying traditional

◦ information-systems problems

System modeled as collection of data, which aremanipulated by “functions”

◦ Data can be persistent (stored in data repositories)

◦ Data can flow between/among functions

◦ Each function can be systematically decomposed into a more refined DFD

Cüneyt Sevgi CTIS 359 Fall 07-08

DFDs Created by Top-Down Analysis

Create a narrative: description of system

Create a Context Diagram that contains a single process (“the system”) and all entities which share data with the system

Explode the “parent” context diagram to produce a Diagram 0 (“child”) DFD

Create Diagram 1, 2, …, n DFDs that represent “explosions” of Diagram 0, 1, …, n-1 DFDs until a diagram has only “primitive” processes

Create process descriptions to be implemented by application programs: queries, macros, reports,

programming languages

Context Diagram

Diagram 0 DFD

Diagram 1 DFDs

Diagram n DFDs

Narrative

E-R Diagram Process Descriptions

Cüneyt Sevgi CTIS 359 Fall 07-08

DFDs Created by Top-Down Analysis(Cont.)

CONTEXT DIAGRAM

1 2

43

Level 0

DFD

2.1

2.3

2.2

Level 1.2 DFD

Process

Specification

for Data Flow

Diagram 2.3

Process Spec for Level 2.3

kahgdkljhckldsajcaljscaljljakdclnh

kljclkjcl;kjcl;asjca;sjcjc;kkdj;jsa;k

ckjal;kjcalkjcal;jcaljcal;kjckljcakj

if kjc = mjclakj

then

do

ldclscknlskld

else

jhalkscjl

lnhclsncdslnc

end - specification

Cüneyt Sevgi CTIS 359 Fall 07-08

External Agents (Entity)

External agent – an outside person, organization unit, system, or organization that interacts with a system. Also called an external entity. ◦ External agents define the “boundary” or scope of

a system being modeled.

◦ As scope changes, external agents can become processes, and vice versa.

◦ Almost always one of the following: Office, department, division.

An external organization or agency.

Another business or another information system.

One of your system’s end-users or managers

◦ Named with descriptive, singular noun

Cüneyt Sevgi CTIS 359 Fall 07-08

Data Stores (Sink)Data store – stored data intended for later use. Synonyms are file and database. ◦ Frequently implemented as a file or database.

◦ A data store is “data at rest” compared to a data flow that is “data in motion.”

◦ Almost always one of the following: Persons (or groups of persons)

Places

Objects

Events (about which data is captured)

Concepts (about which data is important)

◦ Data stores depicted on a DFD store all instances of data entities (depicted on an ERD)

◦ Named with plural noun

Cüneyt Sevgi CTIS 359 Fall 07-08

Data Flows◦ Data flow – A data flow is data in motion.

◦ A data flow may also be used to represent the creation, reading, deletion, or updating of data in a file or database.

• Represent the transfer of data over time

from one “place” (entity, process, data

store) to another

• Examples: New Student Information

New Student

Information

Cüneyt Sevgi CTIS 359 Fall 07-08

Process Concepts

Process –work performed by a system in response to incoming data flows or conditions. A synonym is transform.

Cüneyt Sevgi CTIS 359 Fall 07-08

Common Process Errors on DFDs

Cüneyt Sevgi CTIS 359 Fall 07-08

Data Flow Packet Concept

Cüneyt Sevgi CTIS 359 Fall 07-08

Composite and Elementary Data

Flows

Cüneyt Sevgi CTIS 359 Fall 07-08

Data Flows to and from Data Stores

Cüneyt Sevgi CTIS 359 Fall 07-08

Illegal Data Flows

Cüneyt Sevgi CTIS 359 Fall 07-08

Diverging and Converging Data

FlowsDiverging data flow – a data flow that splits into multiple data flows.◦ Indicates data that starts out naturally as one

flow, but is routed to different destinations.

◦ Also useful to indicate multiple copies of the same output going to different destinations.

Converging data flow – the merger of multiple data flows into a single packet.◦ Indicates data from multiple sources that can

(must) come together as a single packet for subsequent processing.

Cüneyt Sevgi CTIS 359 Fall 07-08

Diverging and Converging Data

Flows

Cüneyt Sevgi CTIS 359 Fall 07-08

CASE for DFDs (Sample Screen) from System Architect 2001

Cüneyt Sevgi CTIS 359 Fall 07-08

Sample Data to Process CRUD

Matrix

Cüneyt Sevgi CTIS 359 Fall 07-08

Sample Process to Location

Association Matrix

Cüneyt Sevgi CTIS 359 Fall 07-08

Our consulting firm has just been hired by Knights Pies to develop a system to record orders for pizza and buffalo wings. When regular customers call Knights Pies on the phone, they are asked their phone number. When the number is typed into a computer, the name, address, and last order date is automatically brought up on the screen. If the customer is new, then they are added to the system. Once the order is taken, the total, including tax and delivery, is calculated. Then the order is given to the cook. A receipt is printed. Occasionally, special offers (coupons) are printed so the customer can get a discount. Drivers who make deliveries give customers a copy of the receipt and a coupon (if any). Weekly totals are kept for comparison with last year’s performance. You have the following tasks:

1. Draw the logical context level (Level 0) DFD for Knights Pies.

2. Explode the logical context level DFD for Knights Pies, creating the Level 1 DFD.

Cüneyt Sevgi CTIS 359 Fall 07-08

Context Diagram

Cüneyt Sevgi CTIS 359 Fall 07-08

Level-1 DFD

Cüneyt Sevgi CTIS 359 Fall 07-08

OBJECT-ORIENTED (OO)

SYSTEMObject-Oriented System is composed of

objects.

An Object is any person, thing, or event

about which we wish to store data or whose

behavior we wish to capture.

An Object has certain attributes and

behaviours.

Cüneyt Sevgi CTIS 359 Fall 07-08

OBJECT-ORIENTED (OO)

SYSTEM

•Object-Oriented Analysis (OOA) –

Consider the problem domain from the

perspective of objects.

•Object-Oriented Design (OOD) – Define

the solution as a collection of software

objects.

•Object-Oriented Programming (OOP) –

Implement the objects using OO

languages.

Cüneyt Sevgi CTIS 359 Fall 07-08

What is UML?

The Unified Modeling Language (UML) is a

general-purpose visual modeling language

that is used to specify, visualize, and document

the artifacts of a software system.

It captures decisions and understanding about

systems that must be constructed. Source: UML Reference Manual, By James Rumbaugh, Ivar Jacobson, Grady

Booch.

Cüneyt Sevgi CTIS 359 Fall 07-08

UML Diagrams

Use-Case diagram

Class diagram

Object diagram

State diagram

Sequence diagram

Collaboration diagram

Activity diagram

Component diagram

Deployment diagram

Cüneyt Sevgi CTIS 359 Fall 07-08

UNIFIED MODELING

LANGUAGE (UML)•UML is the industry standard language for

specifiying, visualizing, constructing, and

documenting the artifacts of OO systems.

•UML embodies a set of 9 unique object

modeling and diagramming tools to define and

model an OO System.

•UML is NOT a development methodolgy.

•UML replaces older techniques such as

DFDs and ERDs.

Cüneyt Sevgi CTIS 359 Fall 07-08

UML DYNAMIC DIAGRAMS

•Use-Case Diagram – Shows what a system does

from an external observer

•Sequence Diagram – Shows interactions that details

how operations are carried out

•Collaboration Diagram – Shows interactions also,

but focuses on object roles instead of times that

messages are sent

•Activity Diagram – Shows flow of activities in a

single process

•Statechart Diagram – Shows the possible states of

the object and the transition that causes a change in

state

Cüneyt Sevgi CTIS 359 Fall 07-08

UML STATIC DIAGRAMS•Class Diagram – Shows system’s classes and relationships

•Object Diagram – Shows instances of classes

•Component Diagram – Shows code module

•Deployment Diagram – Shows the physical deployments.

Cüneyt Sevgi CTIS 359 Fall 07-08

USE CASE DIAGRAM•Although each of the nine diagramming techniques in

the UML is important, the central building block of

the UML is the Use-Case diagram.

•It provides a high-level description of what the

system must do.

•A Use-Case diagram is created for each major

function of the system during the requirements

gathering process.

•A Use-Case diagram is concerned with interactions

between a user (human or another system) and the

system.

Cüneyt Sevgi CTIS 359 Fall 07-08

USE CASE DIAGRAM BENEFITS

•They are regarded as an excellent technique for

capturing the functional requirements.

•They serve as a basis for identifiying the relevant

objects.

•They do not use special language.

•They allow to tell stories.

•Test cases can be directly drived from them.

•They can be used for estimating and scheduling

effort.

Cüneyt Sevgi CTIS 359 Fall 07-08

USE CASE DIAGRAM

LIMITATIONS

•They cannot capture non-functional

requirements.

•They are not well-suited for safety-

critical and real-time systems where

greater degree of precision is required.

•Some customers find it hard to

understand.

Cüneyt Sevgi CTIS 359 Fall 07-08

USE CASE DIAGRAM

COMPONENTS•Use-Case diagrams consists of 3 components.

•Actors - Any person, organization, or computer system that is external but interacting with it.

•An actor does not represent a specific end user, but rather represents a role that an end user can play while interacting with the system.

•Illustrated as stick figures.

•Use-Cases – They are “scenarios” and

•A use-case represents a sequence of steps that define the completion of a single business task.

•Illustrated as ovals.

•Relationships – Associations between an actor and use-case.

Cüneyt Sevgi CTIS 359 Fall 07-08

BUILDING A USE CASE

DIAGRAM PROCESS•Identify system boundry with actors.

•Identify each actor’s goals when

interacting with the system.

•Express these goals with use-cases.

Cüneyt Sevgi CTIS 359 Fall 07-08

IDENTIFY ACTORS•Human Actors

•Who uses system?

•Who provides events and data to the system?

•Who gets information from the system?

•Non-Human Interface Points

•What other systems use this system?

•What other devices use this system?

•What other external event trigger system

response?

Cüneyt Sevgi CTIS 359 Fall 07-08

Example Application - ATM

Software will be developed for a bank’s

ATM. ATM will allow withdrawing money

from accounts, depositing money to

accounts, and transfering money between

accounts of customers who have a bank

card. ATM will get information about the

customer or customer accounts from the

central bank system when required. The

central bank system will get a summary of

the operations performed in a day from the

ATM at the end of that day.

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM Application - Actors

Question:

◦ Who/what are the users of ATM application?

Bank

CustomerCentral Bank

System

Cüneyt Sevgi CTIS 359 Fall 07-08

Actor, because Bank Clerk directly intracts with the system

Example - Small Changes

If the application to be developed is a branch application with the following requirement:

◦ “The bank customer tells the bank clerk the operation that s/he wants to perform.”

◦ Who are the actors of that system?

Bank

Customer

Bank Clerk Branch

Application

Cüneyt Sevgi CTIS 359 Fall 07-08

Actor, because Bank Customer

directly intracts with the system

Example - Small Changes

If the application to be developed is an

Internet banking application:

◦ Who is the actor of that system?

Bank

CustomerInternet Application

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM Application – Use Cases

Question: What do the actors identified

want to accomplish by using the ATM?

◦ Actor: Bank customer

Withdraw money

Deposit money

Transfer between accounts

◦ Actor: Central bank system

Taking daily summary

In addition, it will take roles in all of the use cases

above

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM Application –

Short Descriptions

Actor: Bank customer

◦ Is the person who has a bank card and who is allowed to perform operations on ATM with his/her card

Use Case:Withdraw money

◦ Defines how a bank customer withdraws money from his/her account. The bank customer should select the amount to withdraw and the customer’s funds should meet the stated amount.

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM Application –

Use Case Model

Bank Customer

Withdraw money

Deposit money

Transfer between accounts

Central Bank System

Taking daily summary

Cüneyt Sevgi CTIS 359 Fall 07-08

Use Case Model

Dynamics of a use case may be specified by

statechart diagrams

sequence diagrams

collaboration diagrams

informal text

Use-Cases diagrams accompanied by a textual documents.

The combination of two is called Use-Case model.

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM Application –

“Withdraw Money” Use Case

1. The bank customer inserts his card

2. The ATM reads the card and requests the password

3. The bank customer enters his password

4. The ATM shows the types of transactions

5. The bank customer selects “withdraw money” transaction

6. The ATM displays cash amounts to withdraw

7. The bank customer selects the cash amount to withdraw

8. The central bank system checks for sufficient funds

9. The central bank system debits the account

10. The ATM dispenses the cash

11. The ATM ejects the card

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM Application

“Withdraw Money”

Use Case Definition

Use Case No 1

Use Case Name Withdraw Money

Defined By Ali Veli Last Updated

By

Ali Veli

Defined On DD/MM/

YY

YY

Last Updated

On

DD/MM/YYYY

Actors: Bank customer, Central Bank System

Descriptions Defines how a bank customer withdraws money from his/her account

Pre-conditions The central bank is online;

ATM holds the amount of money withdrawn

Post-conditions The bank customer takes the cash dispensed and the card ejected by the ATM

Priority 1

Frequency of

Use

Very Frequent

Cüneyt Sevgi CTIS 359 Fall 07-08

ATM

Application

“Withdraw

Money”

Use Case

Definition

Basic Flow The bank customer inserts his card

1. The ATM reads the card and requests the password

2. The bank customer enters his password

3. The ATM shows the types of transactions

4. The bank customer selects “withdraw money” transaction

5. The ATM displays cash amounts to withdraw

6. The bank customer selects the cash amount to withdraw

7. The central bank system checks for sufficient funds

8. The central bank system debits the account

9. The ATM dispenses the cash

10. The ATM ejects the card

Alternative Flows A1.1 The bank customer cannot insert his/her card right

A1.2 ATM returns the card

A1.3 Continue with Step 1 in the basic flow

A2.1 The customer enters wrong password

A2.2 ATM invokes the bank customer

A2.3 Continue with Step 3 in the basic flow

A9.1 The central bank determines the fund are not sufficient

A9.2 ATM invokes the bank customer

A9.3 Continue with Step 7 in the basic flow

Referenced Use Cases

Special Requirements For “withdraw money” transaction type to be active, the ATM should hold

the minimum cash amount displayed by the ATM for witdrawal

Assumptions

Notes:Cüneyt Sevgi CTIS 359 Fall 07-08

Some other Features of Use Case

Models

Cüneyt Sevgi CTIS 359 Fall 07-08

<<include>>

An include relationship can be used to when a particular use case is included in other use cases because it encapsulates some functionality that is used at several points in the system. This avoids having to define the same sequence of actions in multiple use cases. The including use case will continue up to the point where it includes the base use case, the full sequence of activities in the base use case will be carried out, and the including use case will carry on at the point where it left off.

Cüneyt Sevgi CTIS 359 Fall 07-08

Source: UML- Schaum’s Outline Series 2nd Edition P.29

<<include>>

Factor out subfuction use cases and use

the <<include>> relationship when

◦ They are duplicated in the other use cases

◦ A use case is very complex and long, and

separating it into subunits aids comprehension

◦ To describe the handling of an asynchronous

event such as when a user able to, at any time,

select a particular window, function, etc..

Cüneyt Sevgi CTIS 359 Fall 07-08

Source: Larman P. 497

<<extend>>

There are occasions where one use case

may OPTIONALLY be extended by the

functionality in another use case. This

relationship is called extend.

Cüneyt Sevgi CTIS 359 Fall 07-08

<<extend>>

Note that <<extend>> use case is

triggered by some condition.

Cüneyt Sevgi CTIS 359 Fall 07-08

LAB

You will create a use case model for a

given example.

Cüneyt Sevgi CTIS 359 Fall 07-08

End

Any questions/suggestions?

Cüneyt Sevgi CTIS 359 Fall 07-08