Sie sind auf Seite 1von 46

Software system modelling

Requirements Analysis
Requirement analysis
Specifies sws operational characteristics Indicates sws interface with the other system elements Establishes constraints that sw must meet

Requirements analysis allow the sw engineer (called analyst or modeler in his role) to
Elaborate on basic requirements established during earlier requirement engineering tasks Build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.

System Modelling
Used in two development phases Analysis (what)
High level of abstraction

Design (what and how)


In more detail terms low level of abstraction

System Modeling Methods


Process Oriented methods (process-driven systems):
Flowcharts Data Flow Diagrams (DFD)

Data oriented methods( data- driven system)


Entity relationship diagram(ERD) Data Dictionary (DD)

System models weaknesses


They do not model non-functional system requirements They do not usually include information about whether a method is appropriate for a given problem They may produce too much documentation The system models are sometimes too detailed and difficult for users to understand

Model types
Data processing model showing how the data is processed at different stages Composition model showing how entities are composed of other entities

Architectural model showing principal sub-systems


Classification model showing how entities have common characteristics

Stimulus/response model showing the systems reaction to events

Context models
Context models are used to illustrate the boundaries of a system Social and organisational concerns may affect the decision on where to position system boundaries Architectural models show the a system and its relationship with other systems

The context of an ATM system


Security sy stem Branch accounting sy stem Auto-teller sy stem Branch counter sy stem Maintenance sy stem Usage database Account da tabase

ATM stakeholders
Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators

Process models
Process models show the overall process and the processes that are supported by the system Data flow models may be used to show the processes and the flow of information from one process to another

Equipment procurement process


Delivery note Equipment spec. Checked spec. Delivery note Specify equipment requir ed Validate specification Get cost estimates Spec. + supplier + estima te Choose supplier Accept delivery of equipment Order notification Place equipment order Check delivered items Installation instructions Install equipment Installation acceptance Accept delivered equipment Equipment details Equipment database

Equipment spec. Supplier database Find suppliers

Supplier list

Order details + Blank order form

Checked and signed order form

Behavioural models
Behavioural models are used to describe the overall behaviour of a system Two types of behavioural model
Data processing models that show how data is processed as it moves through the system State machine models that show the systems response to events

Both of these models are required for a description of the systems behaviour

Data-processing models
Data flow diagrams are used to model the systems data processing These show the processing steps as data flows through a system IMPORTANT part of many analysis methods Simple and intuitive notation that customers can understand Show end-to-end processing of data

DFD
A traditional way of system requirement structuring DFD is a picture of the movement of data between external entities and the processes and data stores within a system In particular, analysing and designing e IPOSC requirements of a system Input Processing Output Storage Control

Data flow diagrams


DFDs model the system from a functional perspective Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment

Order processing DFD


Or der details + blank order form Completed order form Complete order form Valida te order Signed order form Signed order form Record order Order details Signed order form Adjust available budget Order amount + account details Orders file Budget file Send to supplier Checked and signed order + order notification

DFD Shapes from Visio


Visio 5.x
From Flow Chart / Data Flow Diagram From Software Diagram / Gane-Sarson DFD
ID #

Visio 2000
From Flow Chart / Data Flow Diagram

Process
Process Process

Data Store
Data Store 1 Data Store

ID #

External Entity

External Entity

External Entity

Slide 17

Insulin pump DFD

Context Diagram
Highest level view of the system Contains ONLY one process which represents the ENTIRE system Also contains external data soures/sinks Plus data flows between external entities and processes It contains NO data storage

DFD Guidelines
Always begin with a context level diagram ( also called level 0) Always show external entities at level 0 Always label data flow arrows Do not represent procedural logic DFD evolves through a number of levels in detail

Rules for Using DFD Symbols


Data Flow That Connects
YES NO
A process to another process A process to an external entity A process to a data store An external entity to another external entity An external entity to a data store A data store to another data store

Relationship Among DFD levels

Slide 22

Decomposition Diagram

Example of DFD
Precision Tools sells a line of high-quality woodworking tools. When customers place orders on the companys Web site, the system checks to see if the items are in stock, issues a status message to the customer, and generates a shipping order to the warehouse, which fills the order. When the order is shipped, the customer is billed. The system also produces various reports. Draw a context diagram for the order system Draw DFD diagram 0 and 1 for the order system

Context Diagram of Order System


Order CUSTOMER Payment In-Stock Request WAREHOUSE

Status Message

Shipping Order

Invoice

Order System

Shipping Confirmation

Inventory Reports

ACCOUNTING

Lower-Level Diagrams
Functional Decomposition
An iterative process of breaking a system description down into finer and finer detail Uses a series of increasingly detailed DFDs to describe an IS

Balancing
The conservation of inputs and outputs to a data flow process when that process is decomposed to a lower level Ensures that the input and output data flows of the parent DFD are maintained on the child DFD

Order
CUSTOMER WAREHOUSE

Order Reject Notice Payment Invoice

Picking List

Completed Order

Level-0 DFD of Order System

Order System

Commission

Bank Deposit

Cash Receipts Entry

SALES REP

ACCOUNTING

BANK

Order CUSTOMER 1.0

Picking List WAREHOUSE

Order Reject Notice

Fill Order

Invoice 2.0 Payment Invoice Accounts Receivable Create Invoice Completed Order

D1

Level-1 DFD of Order System


3.0

Payment Detail

Invoice Detail

Apply Payment Commission Bank Deposit Cash Receipts Entry

SALES REP

BANK

ACCOUNTING

Entity Relationship Diagram (ERD)

DFD and ERD


DFD
Process/ Relationship

ERD

Data store/ Attribute


External Entity/ Entity

Data Dictionary
It is the repository of various data flows defined in DFD. The DD states precisely the structure of each data flow in DFD. DD stores details description of all elements that compose the DFD such as data flows, data stores, processes.

Why DD is important
To manage details in large system To communicate common meaning for all system elements To document features of the system To analyse the system characteristics To locate errors and omissions in the system

Data dictionary entries


Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included
Description 1:N relation between entities of type Node or has-labels Link and entities of type Label. Holds structured or unstructured information Label about nodes or links. Labels are represented by an icon (which can be a transparent box) and associated text. A 1:1 relation between design entities Link represented as nodes. Links are typed and may be named. Each label has a name which identifies the type name (label) of label. The name must be unique within the set of label types used in a design. Each node has a name which must be unique name (node) within a design. The name may be up to 64 characters long. Name Type Relation Entity Date 5.10.1998 8.12.1998

Relation Attribute Attribute

8.12.1998 8.12.1998 15.11.1998

State machine models


State Machine models the behaviour of the system in response to external and internal events They show the systems responses to stimuli so are often used for modelling real-time systems State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another Statecharts are an integral part of the UML

Full power

Microwave oven model


Full power do: set power = 600 Timer Number Full power Half power Set time do: get number exit: set time Door closed Door open Half power do: set power = 300 Door closed Disabled do: display 'Waiting' Start Enabled do: display 'Ready' Door open Waiting do: display time

State machine model does not show flow of data within the system
Operation do: operate oven Cancel

Waiting do: display time

Half power

Timer

Microwave oven stimuli


Stimulus Half power Full power Timer Number Door open Door closed Start Cancel Description The user has pressed the half power button The user has pressed the full power button The user has pressed one of the timer buttons The user has pressed a numeric key The oven door switch is not closed The oven door switch is closed The user has pressed the start button The user has pressed the cancel button

Microwave oven state description


State Waiting Half power Full power Set time Disabled Enabled Operation Description The oven is waiting for input. The display shows the current time. The oven power is set to 300 watts. The display shows H power alf . The oven power is set to 600 watts. The display shows F power ull . The cooking time is set to the user input value. The display shows the cooking time s selected and is updated as the time is set. Oven operation is disabled for safety. Interior oven light is on. Display shows N ot ready . Oven operation is enabled. Interior oven light is off . Display shows Ready to cook . Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for 5 s econds. Oven light is on. Display shows Cooking complete w buzzer is sounding. hile

Statecharts
Allow the decomposition of a model into sub-models (see a figure) A brief description of the actions is included following the do in each state Can be complemented by tables describing the states and the stimuli
Operation Checking do: check status Turntable fault Alarm do: display event OK Cook do: run generator Timeout Done do: buzzer on for 5 secs. Time

Emitter fault

Door open Disabled W aiting

Cancel

Finite state machines


Finite State Machines (FSM), also known as

Finite State Automata (FSA)


are models of the behaviours of a system or a complex object, with a limited number of defined conditions or modes, where mode transitions change with circumstance.

Finite state machines - Definition


A model of computation consisting of a set of states, a start state, an input alphabet, and a transition function that maps input symbols and current states to a next
state

Computation begins in the start state with an input string. It changes to new states depending on the transition function.
states define behaviour and may produce actions state transitions are movement from one state to another rules or conditions must be met to allow a state transition input events are either externally or internally generated, which may
possibly trigger rules and lead to state transitions

Variants of FSMs
There are many variants, for instance, machines having actions (outputs) associated with transitions (Mealy machine) or states (Moore machine), multiple start states, transitions conditioned on no input symbol (a null) or more than one transition for a given symbol and state (nondeterministic finite state machine), one or more states designated as accepting states (recognizer), etc.

Finite State Machines with Output (Mealy and Moore Machines) Finite automata are like computers in that they receive input and process the input by changing states. The only output that we have seen finite automata produce so far is a yes/no at the end of processing. We will now look at two models of finite automata that produce more output than a yes/no.

Moore machine
Basically a Moore machine is just a FA with two extras. 1. It has TWO alphabets, an input and output alphabet. 2. It has an output letter associated with each state. The machine writes the appropriate output letter as it enters each state.
This machine might be considered as a "counting" machine.

The output produced by the machine contains a 1 for each occurrence of the substring aab found in the input string.

Mealy machine
Mealy Machines are exactly as powerful as Moore machines
(we can implement any Mealy machine using a Moore machine, and vice versa).

However, Mealy machines move the output function from the state to the transition. This turns out to be easier to deal with in practice, making Mealy machines more practical.

A Mealy machine produces output on a transition instead of on entry into a state.


Transitions are labelled i/o where
i is a character in the input alphabet and o is a character in the output alphabet.

The following Mealy machine takes the one's complement of its binary input. In other words, it flips each digit from a 0 to a 1 or from a 1 to a 0.

Mealy machine are complete in the sense that there is a transition for each character in the input alphabet leaving every state. There are no accept states in a Mealy machine because it is not a language recogniser, it is an output producer. Its output will be the same length as its input.

Thank You

Das könnte Ihnen auch gefallen