Beruflich Dokumente
Kultur Dokumente
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
Model types
Data processing model showing how the data is processed at different stages Composition model showing how entities are composed of other entities
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
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
Supplier list
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
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
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
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
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
Picking List
Completed Order
Order System
Commission
Bank Deposit
SALES REP
ACCOUNTING
BANK
Fill Order
Invoice 2.0 Payment Invoice Accounts Receivable Create Invoice Completed Order
D1
Payment Detail
Invoice Detail
SALES REP
BANK
ACCOUNTING
ERD
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
Full power
State machine model does not show flow of data within the system
Operation do: operate oven Cancel
Half power
Timer
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
Cancel
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.
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