Upload
harold-patterson
View
227
Download
4
Embed Size (px)
Citation preview
1
ITEC 3010 “Systems Analysis and Design, I”
LECTURE 6:LECTURE 6:Traditional Approach to RequirementsTraditional Approach to Requirements
[Prof. Peter Khaiter]
2
Lecture OutlineLecture Outline
Traditional Approach vs. OOATraditional Approach vs. OOAData Flow Diagrams (DFDs)Data Flow Diagrams (DFDs)DFD and Levels of AbstractionDFD and Levels of AbstractionContext DiagramsContext Diagrams DFD FragmentsDFD FragmentsPhysical and Logical DFDsPhysical and Logical DFDsEvaluating DFD QualityEvaluating DFD QualityDocumentation of DFD ComponentsDocumentation of DFD ComponentsLocations and Communication Locations and Communication Through NetworksThrough Networks
3
Two approaches differ in the way the system is modeled and implemented:
• Traditional approach: – views a system as a collection of processes (like computer
programs, a set of instructions that execute in sequence) – when the process executes it interacts with data (reads data
values and then writes data values back to the data file – emphasizes processes, data, inputs/outputs• Object Oriented approach (OO): – views a system as a collection of interacting objects which are
capable of their own behavior (called methods) which allow the objects to interact with each other and with people using the system
– there are NO conventional processes and data files per se, just interacting objects
Traditional Approach vs. OOATraditional Approach vs. OOA
4
Traditional Approach vs. OO Traditional Approach vs. OO ApproachApproach
5
Requirements for the Traditional Requirements for the Traditional and OO Approachesand OO Approaches
6
Data Flow Diagrams (DFDs)Data Flow Diagrams (DFDs)
Graphical system model that shows all main requirements for an IS in one diagram
Inputs/outputs
Processes
Data storage
Easy to read and understand with minimal training (only 5 symbols used)
DFD integrates processing triggered by events (event table) with the data entities modeled by ERD
7
DFD SymbolsDFD Symbols
The square is an external agent (a person or organization, outside the boundary of a system that provides data inputs or accepts data outputs)
The rectangle with rounded corners is a process (named “Look up item available” and can be referred to by its number, 1)
A process defines rules (algorithms or procedures) for transforming inputs into outputs
The lines with arrows are data flows (represents movement of data). Slide shows two data flows between Customer and process 1: a process input “Item inquiry” and process output named “Item availability details”
The flat three-sided rectangle is a data store (a file or part of a database that stores information about data entity)
8
Data Flow Diagram Symbols
9
DFD Fragment Showing Use Case DFD Fragment Showing Use Case Look Up Item AvailabilityLook Up Item Availability from the from the RMORMO
10
DFD Integrates Event Table and DFD Integrates Event Table and ERDERD
11
DFD and Levels of AbstractionDFD and Levels of Abstraction
DFD is a modeling technique that breaks the system into a hierarchical set of increasingly more detailed models
DFD may reflect the processing at either a higher level (more general view of the system) or at lower level (a more detailed view of one process)
These different views of the system (higher level versus low level) creates the levels of abstraction
DFDs are decomposed into additional diagrams to provide multiple levels of detail
Higher-level diagrams provide general views of system
Lower-level diagrams provide detailed views of system
12
Layers of DFD Abstraction for Course Registration System
13
Context DiagramsContext Diagrams
DFD that summarizes all processing activity for the system or subsystem
Highest level (most abstract) view of system
Shows system boundaries
System scope is represented by a single process, external agents, and all data flows into and out of the system
14
Context Diagrams for a Context Diagrams for a Course Course RegistrationRegistration System System
15
• Useful for showing system boundaries (represents the system scope within the single process plus external agents)• External agents that supply or receive data from the system are outside the system scope• Data stores are not usually shown in the context diagram since they are considered to be within the system scope• It is the highest level of DFD• Context diagram does not show any details of what takes place within the system
Notes on Context DiagramsNotes on Context Diagrams
16
Context Diagrams for RMO CSSContext Diagrams for RMO CSS
17
DFD FragmentsDFD Fragments
Created for each use case in the event table
Represent system response to one event within a single process symbol
Self-contained models
Focus attention on single part of system
Show only data stores required in the use case
18
Three Separate DFD Fragments Three Separate DFD Fragments for Course Registration Systemfor Course Registration System
19
Event-Partitioned System ModelEvent-Partitioned System Model
DFD to model system requirements using single process for each use case/activity in system or subsystem
Combines all DFD fragments together to show decomposition of the context-level diagram
Shows the entire system on a single DFD (in greater detail than on the context diagram)
Sometimes called “diagram 0”
Used primarily as a presentation tool
Decomposed into more detailed DFD fragments
20
Combining Combining DFD DFD Fragments to Fragments to Create Create Event- Event- Partitioned Partitioned System System ModelModel
21
Layers of Layers of DFD DFD AbstractionAbstraction
22
RMO Subsystems and Use RMO Subsystems and Use Cases/Activities from Event TableCases/Activities from Event Table
23
Context Diagram for RMO Context Diagram for RMO Order-Entry SubsystemOrder-Entry Subsystem
24
Five Separate DFD Fragments for Five Separate DFD Fragments for RMO Order-Entry SubsystemRMO Order-Entry Subsystem
25
The event-partitioned model of the Order-Entry subsystem (diagram 0)
26
Decomposing DFD FragmentsDecomposing DFD Fragments
Most DFD fragments can be further described using structured English
Sometimes DFD fragments need to be diagrammed in more detail
Decomposed into subprocesses in a detailed DFD
DFD numbering scheme
Hierarchical decomposition
• DFD Fragment 2 is decomposed into Diagram 2
• Diagram 2 has processes 2.1, 2.2, 2.3, 2.4 –four steps to complete the activity
27
Detailed DFD for Create new order DFD fragment
28
• The top most - context diagram (entire system as one process), which breaks down to the subsystem diagram (one process per subsystem)
• The subsystem diagram is, in turn, decomposed into a set of the event-partitioned subsystem diagrams
• There is no single diagram 0. Instead, there is an event-partitioned DFD for each of the subsystems
• Each event-partitioned DFD is a diagram 0 for a single subsystem
Hierarchy of the DFDsHierarchy of the DFDs
29
Hierarchy of the DFDsHierarchy of the DFDs
30
FIGURE 6-20 Incorrect and correct way to draw DFD.
31
Physical and Logical DFDsPhysical and Logical DFDs
Logical model
Assumes implementation in perfect technology
Does not tell how system is implemented
Physical model
Describes assumptions about implementation technology
Developed in last stages of analysis or in early design
E.g., the technology assumption is embedded in the name of process 1.1 “Making copies for department chairs” – it is a manual task, which implies that the data store “Old schedule” and the data flows into and out of process 1.1 are papers, etc.
32
Physical DFD for Scheduling Courses
33
Evaluating DFD QualityEvaluating DFD Quality
Readable Internally consistent and balanced Accurately represents system requirements Reduces information overload – rule of 7
+/- 2Single DFD should not have more than 7 +/-2 processesNo more than 7 +/- 2 data flows should enter or leave a process or data store in a single DFD
Minimizes required number of interfaces
34
Data Flow Consistency ProblemsData Flow Consistency Problems
Differences in data flow content between a process and its decomposition
Data outflows without corresponding inflows
Data inflows without corresponding outflows
Results in unbalanced DFDs
35
Black Hole and MiracleBlack Hole and Miracle
black hole, i.e. a process with a data input that is never used to produce a data input. The following rules help to avoid the black holes:
- All data that flow into a process must flow out of the process or be used to generated data that flow out of the process
- All data that flow out of a process must have flowed into the process or have been generated from data that flowed into the process Miracle - a process with a data output that is created out of nothing ( “miraculously appears”)
36
Unnecessary Data Input: Black Unnecessary Data Input: Black HoleHole
37
Process with Impossible Data Process with Impossible Data Output: a MiracleOutput: a Miracle
38
Process with Unnecessary Data Process with Unnecessary Data InputInput
39
Process with Impossible Data Process with Impossible Data OutputOutput
40
Documentation of DFD Documentation of DFD ComponentsComponents
DFDs show three types of internal system component: processes, data flows and data stores
The details of each component need to be described
Lowest-level processes need to be described in detail
Data flow contents need to be described
Data stores need to be described in terms of data elements
Each data element needs to be described
41
• Each process on a DFD must be formally defined• There are several options for process definition including decomposition. In a process of decomposition, a higher-level process is formally defined by a DFD that contains lover-level processes, which, in turn, may be further decomposed into even lower-level DFDs. Eventually a point will be reached when a process becomes so simple that it can adequately be described by another process description method, i.e. without next lower-level DFD.• These description methods include: - Structured English - Decision tables - Decision trees • These models describe the process as an algorithm.
Process DescriptionsProcess Descriptions
42
Structured EnglishStructured English
Method of writing process specifications
Combines structured programming techniques with narrative English
Well-suited for lengthy sequential processes or simple control logic (single loop or if-then-else)
Ill-suited for complex decision logic or few (or no) sequential processing steps
43
Structured English ExampleStructured English Example
44
Process 2.1 and Structured Process 2.1 and Structured English Process DescriptionEnglish Process Description
45
A structured English process description for calculating shipping charges
46
Decision Tables and Decision TreesDecision Tables and Decision Trees
Can summarize complex decision logic better than structured English
Incorporate logic into the table or tree structure to make descriptions more readable
47
Decision Table for Calculating Decision Table for Calculating Shipping ChargesShipping Charges
48
Decision Tree for Calculating Decision Tree for Calculating Shipping ChargesShipping Charges
49
A Decision Table with Multiple Action A Decision Table with Multiple Action RowsRows
50
Data Flow DefinitionsData Flow Definitions
Data flow is a collection of data elements
Data flow definition is a textual description of data flow’s content and internal structure
Lists all the elements, e.g. a “New Order” data flow consists of Customer–Name, Customer-Address, Credit-Card-Information, Item-Number and Quantity
Often coincide with attributes of data entities included in ERD plus computed values
Algebraic notion is alternative to the list
Describes data elements on data flow plus data structure
51
List and Algebraic Notation for List and Algebraic Notation for Data Flow DefinitionData Flow Definition
52
RMO Products and Items Report
53
Data Flow Definition for RMO Data Flow Definition for RMO Products and Items Control Break Products and Items Control Break ReportReport
54
Data Element DefinitionsData Element Definitions
Data type description
String, integer, floating point, Boolean
Sometimes very specific written description e.g., special codes (e.g. code A means ship immediately, code B – hold for one day and code C – hold shipment pending confirmation)
Length of element (usually for strings)
Maximum and minimum values (for numeric values)
Data dictionary – repository for definitions of data flows, data stores, and data elements
55
Data Element Definition ExamplesData Element Definition Examples
56
Data Store DefinitionsData Store Definitions
A data store on the DFD represents a data entity on the ERD (so, no separate definition is needed, just a note referring to the ERD for details)
If a data store are not linked to an ERD, a definition is provided as a collection of elements (like did for data flows)
57
Components of a Traditional Components of a Traditional Analysis ModelAnalysis Model Four components of a traditional analysis model are – Data flow diagrams – Entity-relationship diagram – Process definitions – Data definitions They form an interlocking set of specifications for
system requirements DFD shows highest-level view of the system Other components describe some aspect of DFD These models were created in the 1970’s and
1980’s as a part of the structured analysis methodology
58
Components of a Traditional Components of a Traditional Analysis ModelAnalysis Model
59
Locations and Communication Locations and Communication Through NetworksThrough Networks
Physical information needed during analysisNumber of user locationsProcessing and data access requirements at various locationsVolume and timing of processing and data access requests
Needed to make initial design decisions such as
Distribution of computer systems, application software, database components, network capacity
60
Gathering Location InformationGathering Location Information
Identify locations where work is to be performed Draw location diagram – a map that identifies all of the
processing locations of a system (business offices, warehouses, manufacturing facilities)
List functions performed by users at each location Build activity-location matrix - a table that describes the
relationship between processes and the locations where they are performed
Rows are system activities from event tableColumns are physical locations
Build activity-data (CRUD) matrixis a table that describes stored data entities, the locations from which they are accessed and the nature of the access (i.e. which activities require access to the data). Source of this information is:
- the DFD fragments (traditional approach) and - sequence diagrams (OO approach)
CRUD – create, read, update, and delete
61
RMO Location diagram
62
RMO Activity-Location MatrixRMO Activity-Location Matrix
63
RMO Activity-Data Matrix (CRUD)RMO Activity-Data Matrix (CRUD)
64
ReadingsReadings
Today’s lecture: Chapter 6 – “The Traditional Approach to Requirements”
For next lecture: Chapter 7 – “The Object-Oriented Approach to Requirements”
Thank
you
!!!