Professional Documents
Culture Documents
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
BrianLewis/2010
Why Do We Need to Learn Process Modelling? 1-2 Class Objectives Key Topics Last Class COSC 2810 Projects 1-2 Project Feedback Key Topics This Class Process Modelling Glossary 1-2 Logical Process Models 1-2 Buying a Coke at Billa Context Process Model Process Modelling Buying a Coke at Billa 1st Level Data Flow Diagram Data Flow Concepts Data Flow Diagrams Advantages of Data Flow Diagrams My Data Flow Diagramming Symbols Car Purchase System 1-3 DFD - Whats Wrong Here? 1-4 Developing Data Flow Diagrams Exploding & Balancing Data Flow Diagrams Tips From an Old Modeller Functions, Events & Elementary Processes 1-2 Functional Decomposition Diagram Event-Driven Process Modelling According to the Textbook 1-3 Developing Process Models for the COSC 2810 Project 1-4 COSC 2810 Methodology Phase 4 Logical Design Biograd Passenger Handling System 1-18 Assignment 5a 1-5
* foil included in this document for reference, but not shown in class ** additional foil shown in class, but not included in this document
BrianLewis/2010
WHY?
BrianLewis/2010
1. To UNDERSTAND how an operation works 2. To UNDERSTAND what processes are involved 3. To UNDERSTAND the data they need as I/P 4. And how they TRANSFORM them to O/P 5. To COMMUNICATE with users 6. To be able to DESIGN software to perform processes in an organisation 7. To have something which can be used to SPECIFY what the software should do 8. To give to programmers in a form that they UNDERSTAND
Oh, and also to UNDERSTAND (did I mention that?)
Let me tell you a story about using Process Models to communicate & reverse-engineer a Financial Budget applicaton I knew very little about Budgeting & the User knew very little about Computing . . .
BrianLewis/2010
TAKE THE CONCEPTS FROM CHAPTER 9, LEAVE THE TRIVIA AND UNDERSTAND HOW TO MODEL PROCESSES IN PRACTICE (without getting carried away in the process )
KEY TOPICS Classes 4a & 4b/Chap 8 Entity Attribute Instance Data Type Composite Key
BrianLewis/2010
BrianLewis/2010
University Course Scheduling Decision Support System Electronic Advisor for Webster
Project leaders for the past week are single underlined. Project leaders for the next week are double underlined. They are required to report, in class 6a, on: a) the teams achievements & progress in the past week b) the teams plans for the following week
BrianLewis/2010
D
x x
D
x x
D
x
D D D
F F F F F F F
PROJECT FEEDBACK
BrianLewis/2010
needs improvement
OK
needs improvement
KEY TOPICS Classes 5a & 5b/Chap 9 Context Process Model External Agents & Data Stores Functions & Events System Diagram Elementary Process Balancing DFDs Data in Motion versus Data at Rest Structured English Data Flow Diagram
BrianLewis/2010
External, Temporal & State Events Data & Control Flows Event Diagram Primitive Diagram Data Structure Black Holes & Grey Holes Decision Tables
BrianLewis/2010
External Agent Third party outside the system that interacts with it (aka Actor)
A set of ongoing A set of tasks that must be completed activities as a whole (aka Transaction) Data Structure Set of data attributes comprising a data flow External Event An input Data Flow is initiated by an External Agent Data Flow Diagram (DFD)
A model showing data flowing between the processes of a system and the processes' interaction with External Agents & Data Stores Temporal Event State Event A Control Flow is A Control Flow is triggered by a triggered by the passing change in the state of the (real-time) of Time system
BrianLewis/2010
System Diagram
Primitive Diagram DFD of Elementary Processes, External Agents, Data Stores & Data Flows, for a single Event Grey Hole Process with insufficient inputs to produce the output CRUD Short for Create, Read, Update, Delete
DFD context diagram for a single DFD of all Event Event, with External Agents, Diagrams in a Data Stores & Data Flows system/sub-system Balancing
Black Hole
DFDs at different levels should be consistent, Process with e.g. don't add a Data Store at a lower level input but no that wasn't in a higher level DFD output Structured English English-like commands for specifying a Process's logic Decision Table Matrix of a set of conditions and corresponding actions
BrianLewis/2010
BrianLewis/2010
THE DATA MODEL HELPS US DESIGN OUR DATABASE, NOW WE NEED SOMETHING TO HELP US DESIGN OUR SOFTWARE
1. THE STEPS INVOLVED IN EACH PROCESS 2. WHAT INPUT EACH PROCESS NEEDS 3. WHAT OUTPUT EACH PROCESS PRODUCES
. . WE CAN ACHIEVE A STABLE SOFTWARE DESIGN
DATA FLOW DIAGRAMS ARE USED TO PRODUCE A PROCESS MODEL THAT PROVIDES A BLUEPRINT FOR DESIGNING PROGRAMS IN A COMPUTER SYSTEM
BrianLewis/2010
External Agent
CUSTOMER
CASHIER
record of payment
ACCOUNTS FILE
BrianLewis/2010
BrianLewis/2010
PROCESS MODELLING
A CONTEXT level DFD sets the boundaries of the system and identifies Actors outside the system The Context Diagram is then developed further by: 1. EXPLODING (BREAKING DOWN) THE SYSTEM INTO ITS SUB-SYSTEMS OR FUNCTIONS (This identifies the PROCESSES in the system) 2. ADDING TO EACH PROCESS: What INPUT it needs to perform its tasks And where it comes from What FILES (stored data) it uses What the OUTPUT (result) of the process is And where it goes to
STORAGE
BrianLewis/2010
CUSTOMER
ACCOUNTS FILE record of payment product code, amount sold INVENTORY FILE
clearance
transaction details
BrianLewis/2010
. . . and then building Process Models with Data Flow Diagrams . . . . . . we gain a significant insight into the way a Business Operation works . . . . . . and can document: a] what the existing system does b] what the proposed system should do
BrianLewis/2010
2. DOCUMENT:
the Processes in the system the Data needed by each process as Input the Data each process produces as Output the Data Stored by the system the Data Entering & Leaving the system
BrianLewis/2010
Like maps of the world, showing country, then province and then town etc.
BrianLewis/2010
DATA STORE
EXTERNAL AGENT
DATA FLOW
CONTROL FLOW
BrianLewis/2010
CAR DEALER
order+payment
BOOK SHOP
Process
Data Flow
instructions payment
CUSTOMER
models Externa l Agent CATALOGUE
BANK
Data Store
BrianLewis/2010
BOOK SHOP
confirmation
amount
P3 PAY
BANK
BrianLewis/2010
BOOK SHOP
BrianLewis/2010
BrianLewis/2010
CAR DEALER
order+payment
payment
BANK
There are EIGHT mistakes in this DFD - How many can your team find? 7 or more = A+; 6 = A; 5 = B; 4 = C; 3 = D; <3 = F
BrianLewis/2010
CONTEXT DIAGRAM
(not a process) P0 CAR PURCHASE SYSTEM car magazines BOOK SHOP
CAR DEALER
payment
CUSTOMER
models, specs, prices (physical objects cannot flow) (actions cannot flow)
BANK
BrianLewis/2010
CAR DEALER
order+payment
BOOK SHOP
instructions payment
CUSTOMER
BANK
BrianLewis/2010
DEVELOPING DFDs
DIVIDE & CONQUER
BrianLewis/2010
BrianLewis/2010
BALANCING
Maintain consistency between levels Dont add new inputs, outputs or Data stores that were not at a higher level
BrianLewis/2010
BrianLewis/2010
Logical unit of work that must be done as a whole e.g. Enrol a student, Service this car, Check in a passenger EXTERNAL EVENT Input data flow initiated by an External Agent e.g. customer changes address TEMPORAL EVENT Time is the trigger for an event e.g. end of the month arrives - start process xyz STATE EVENT Some change in the system triggers an event e.g. the Bancomat is out of cash
BrianLewis/2010
Taking a Corner Defending Passing the Ball Scoring a Goal Managing the Team Whistle for Half-Time Committing a Foul Making a Substitution Taking a Penalty Goalkeeping
Function: An Ongoing Activity Event: A Set of Tasks Completed as a Whole Elementary Process: A Basic Task
BrianLewis/2010
1. ADMISSION
2. REGISTRATION
3. ACADEMIC AFFAIRS
5. FINANCE
BrianLewis/2010
break it down into functions & events one process to deal with each event show context of each event
CONTEXT DIAGRAM DECOMPOSITION DIAGRAM EVENT-RESPONSE LIST EVENT HANDLERS EVENT DIAGRAMS
a DFD of all events in the (sub-) system
BrianLewis/2010
4 5
To show the Events interaction with External Agents & Data Stores Combine all Event Diagrams on one To show the big page picture Explode each Event into the To show in detail Processes, Data Flows, Data Stores & exactly how each External Agents needed Event is carried out
BrianLewis/2010
EVENT DIAGRAMS (lower-level DFDs showing the context for each event)
SYSTEM DIAGRAM (one page DFD of all Event Diagrams for system / sub-system)
PRIMITIVE DIAGRAMS (detailed, lower-level DFDs showing the Elementary Processes in each Event)
BrianLewis/2010
1ST LEVEL (SYSTEM) DATA FLOW DIAGRAM (identifies major system functions)
2ND LEVEL DATA FLOW DIAGRAMS (OPTIONAL) (lower-level DFDs for complex processes in the 1st level Diagram)
BrianLewis/2010
To show the big picture by showing the processing logic of system functions To understand & show in more detail how a function is carried out
BrianLewis/2010
break it down into functions & subfunctions (events) a DFD of the main functions in the system
BrianLewis/2010
5 Level the System Diagram, i.e. Partition the Event Diagrams a. either upwards, grouping related processes into higher-level DFDs b. or downwards, exploding processes into more detail
COSC 2810 PROJECTS Draw a Context DFD to establish initial system scope Draw Functional Decomposition Diagram to partition the system into its main subsystems/functions/events Explode the Context Diagram into a First Level DFD (System Diagram) of: 1. the Processes (the system functions) 2. the External Agents 3. the Data Stores 4. the Data & Control Flows between Processes, Data Stores & External Agents Compile an Event List of those actions which occur in our system and to which our system must respond (OPTIONAL) Draw lower-level DFDs for those complex events requiring further understanding (OPTIONAL)
BrianLewis/2010
LOGICAL DESIGN
CONTEXT DATA MODEL (ERD) NORMALISED KEY-BASED DATA MODEL PROCESS MODEL (DFD)
DEVELOP DETAILED
4.2
4.3
4.4
DATA DESIGN REPORT (Due by class 5b) 1. DATA MODEL (ENTITY RELATIONSHIP DIAGRAM) 2. KEY-BASED DATA MODEL PROCESS DESIGN REPORT (Due by class 6b) 1. CONTEXT PROCESS MODEL (CONTEXT DIAGRAM) 2. DETAILED PROCESS MODEL (DATA FLOW DIAGRAM)
this is our System Diagram
BrianLewis/2010
A QUESTION FROM A RECENT EXAM Consider the processes involved in an airports system for getting passengers from the point when they arrive at an airport to the point when they enter the plane. Draw a context diagram for this system and then construct the first-level data flow diagram by identifying processes and then adding relevant data flows, data stores and external agents. Concentrate on showing your understanding of constructing proper data flow diagrams rather than trying to find a perfect solution.
BrianLewis/2010
baggage list
PLANE
seat #, passport #
FLIGHT DATABASE
if this were used only within the PHS, we would not show it in the context diagram it would be part of the Process the system
BrianLewis/2010
1. CHECK-IN
2. PASSPORT CONTROL
3. SECURITY CHECK
4. BOARDING
RETRIEVE PASSENGER & FLIGHT DATA LOOKUP GATE NUMBER PRINT BOARDING PASS
BrianLewis/2010
Temporal
Event Types
EXTERNAL - process initiated by a data flow TEMPORAL process is initiated by time STATE process triggered by a change in the systems state
BrianLewis/2010
BIOGRAD AIRPORT PASSENGER HANDLING SYSTEM 1st LEVEL DATA FLOW DIAGRAM (SYSTEM DIAGRAM) EXPLODING OUR SYSTEM INTO PROCESSES
P1 CHECK-IN
P2 PASSPORT CONTROL
P3 SECURITY CHECK
P4 LOAD BAGGAGE
P5 BOARD PLANE
BrianLewis/2010
PASSENGER
P1 CHECK-IN
P2 PASSPORT CONTROL
P3 SECURITY CHECK
P4 LOAD BAGGAGE
P5 BOARD PLANE
PLANE
BrianLewis/2010
PASSENGER
P1 CHECK-IN
P2 PASSPORT CONTROL
PASSENGER
CRIMINAL
FLIGHT
PLANE SEATING
P3 SECURITY CHECK
P4 LOAD BAGGAGE
P5 BOARD PLANE
PLANE
BrianLewis/2010
take-off 15 mins
BrianLewis/2010
seat #, passport #
FLIGHT DATABASE
BrianLewis/2010
baggage PLANE
take-off 15 mins
BrianLewis/2010
SYSTEM DIAGRAM
We decomposed the system as shown in the Context Diagram into its main sub-processes its FUNCTIONS We not only achieved a deeper understanding of the system But we can use this model to communicate with users on their functional requirements And if we decide to computerise this system we have identified important & necessary components:
which will become programs
PROCESSES
DATA STORES which become tables in our database EXTERNAL AGENTS which will require interfaces DATA FLOWS which will become data structures and which the programs will need as input, or will have to produce as output
THE NEXT STEP IS TO ASK: "DO WE HAVE SUFFICIENT UNDERSTANDING OF ALL PROCESSES TO SPECIFY IN DETAIL EXACTLY WHAT EACH PROGRAM SHOULD DO?"
BrianLewis/2010
"DO WE HAVE SUFFICIENT UNDERSTANDING OF ALL PROCESSES TO SPECIFY IN DETAIL EXACTLY WHAT EACH PROGRAM SHOULD DO?"
IF NOT, OUR NEXT STEP IS TO EXPLODE THOSE PROCESSES WHERE WE LACK UNDERSTANDING INTO FURTHER SUB-PROCESSES, e.g. the EVENTS involved in the CHECK-IN FUNCTION
ticket, passport, PASSENGER boarding pass frequent flyer data PASSENGER P1 CHECK-IN
occupied seats
seat # FLIGHT
BrianLewis/2010
BIOGRAD AIRPORT PASSENGER HANDLING SYSTEM 2ND LEVEL DATA FLOW DIAGRAM CHECK-IN EXPLODING A PROCESS INTO FURTHER SUB-PROCESSES (EVENTS)
BrianLewis/2010
PASSENGER
booking FLIGHT
passenger id
endorsed ticket, boarding pass, baggage receipt P1.3 WEIGH & TAG BAGGAGE
boarding pass
seat no.
baggage id
We Would Do The Aforegoing Exercise In This Way: 1. DRAW THE CONTEXT DIAGRAM 2. COMPILE AN EVENT LIST a. List those actions which occur in our system and to which our system must respond b. The ERD may help us in identifying these 3. DRAW FUNCTIONAL DECOMPOSITION DIAGRAM a. Illustrate in a hierarchy the major functions (or sub-systems) in our system b. Add under each function the events from the event list c. Draw lower-level DFDs (event diagrams) for those events which require further understanding 4. ASSEMBLE ALL EVENT DIAGRAMS INTO A SYSTEM DIAGRAM 5. LEVEL THE SYSTEM DIAGRAM BY PARTITIONING THE EVENT DIAGRAMS
BrianLewis/2010
a.
b. Or downwards, exploding processes into further detail But since we have limited time, we will go straight from the Context Diagram to the System Diagram and then (optionally) to Event Diagrams
BrianLewis/2010
1ST LEVEL (SYSTEM) DATA FLOW DIAGRAM (identifies major system functions)
2ND LEVEL DATA FLOW DIAGRAMS (OPTIONAL) (lower-level DFDs for complex processes in the 1st level Diagram)
BrianLewis/2010
PASSENGER
verified passport frequent flyer data
PASSENGER
reserved seat
seat plan
FLIGHT
FLIGHT
PLANE SEATING
PASSENGER
baggage id, passenger # baggage id
BAGGAGE
boarding pass
PASSENGER
BAGGAGE
If we still dont understand how some processes work well enough to be able to write programs, we explode these into: PRIMITIVE DIAGRAMS of ELEMENTARY PROCESSES (basic pieces of work)
P1.4 ISSUE BOARDING PASS BAGGAGE endorsed ticket, boarding pass PASSENGER
BrianLewis/2010
P1.4.1 RETRIEVE PASSENGER & FLIGHT DATA P1.4.3 PRINT BOARDING PASS
BrianLewis/2010
MARRIAGE
The government of Analasia has commissioned you to do the Analysis & Logical Design of the data of a system for recording all important data regarding marriages in the country. Bigamy is forbidden in Analasia, but divorce is not. The government wants to be able to query a database to find, for example: when and where a marriage took place, the woman's maiden name, which persons were married, who officiated at the ceremony and whether the parties were subsequently divorced. 1. Draw an Entity Relationship Diagram of the marriage relationship between two persons. 2. Illustrate the tables with which you would build to resolve relationships in the ERD, showing important attributes, selecting Primary Keys and adding any appropriate Foreign Keys. 3. Give examples of attributes which, if added, would violate: a) First Normal Form, b) Second Normal Form c) Third Normal Form
BrianLewis/2010
Q1. PERSON
marries
is married to
This is a Recursive Relationship each person marries none, one or many persons each person is married to none, one or many
persons
In understanding a relationship, it helps greatly to read it aloud, from one direction to the other And we have to remember that we are designing a database that should record: all marriages and all divorces of all persons from the beginning of time until eternity
Q2. PERSON Table SSN (PK) Last Name First Name marries Maiden Name Address Sex Birth Date Death Date Marriage Authority (Y/N) Occupation
is married to
BrianLewis/2010
MARRIAGE Table PERSON.SSN PERSON.SSN Marriage Date (PK) Wedding Ceremony Address Divorce Date Presiding Official (FK Person.SSN)
SSN = Social Security Number Marriage Date needs to be part of the Primary Key of the Marriage associative
entity in case the same couple marry, divorce and then re-marry
BrianLewis/2010
Q3.
a.
If we were to put Marriage Date in the Person Table this would violate 1st Normal Form. Since a person can marry more than once we would need a repeating group of the marriage dates If we were to put Maiden Name in the Marriage Table this would violate 2nd Normal Form. Since the Maiden Name applies to one person only, it is dependent on just one part of the Primary Key If we were to add the attribute Age to the Person Table this would violate 3rd Normal Form. Since Age is dependent on another attribute (the Birth Date). Also, it is not good design to include attributes whose value changes with time and which can anyway be calculated (from Birth Date).
b.
c.
BrianLewis/2010
NORMAL FORMS
FIRST NORMAL FORM (1NF)
NO REPEATING GROUPS An entity whose attributes have no more than one value for a single instance of that entity
Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship
(2NF)
THE WHOLE KEY & NOTHING BUT THE KEY An entity whose attributes are dependent on all parts of the primary key
Any attributes that are dependent on only part of the primary key should be moved to any entity where that partial key is actually the full key. This may require creating a new entity and another relationship
(3NF)
NO ATTRIBUTES DEPEND ON OTHER ATTRIBUTES An entity whose attributes are not dependent on any other attributes
Any attributes that are dependent on other attributes must be moved or deleted. Again, new entities and relationships may have to be added to the data model