Presentation is loading. Please wait.

Presentation is loading. Please wait.

ECE 355: Software Engineering

Similar presentations

Presentation on theme: "ECE 355: Software Engineering"— Presentation transcript:

1 ECE 355: Software Engineering
Traditional Analysis and Modeling Approaches Lectures notes by Instructor: Krzysztof Czarnecki

2 Three main views of the traditional approach (Structured Analysis)
Process/functional view: Data flow diagrams Data structures: Entity-relationship diagrams Time-dependent behavior: State-transition diagrams

3 Outline for today Introduction Data Flow Diagrams
Entity Relationship Diagrams Further Reading

4 Data Flow Diagrams (DFDs)
A DFD is a graphical representation of the processes of a system, the data being transformed and stored A DFD gives a very good overview of what is happening in the system A DFD represents the process view of a system (processes are actions or sets of actions) the functional view (processes as functions) (workflow model)

5 Components of a DFD DFD is very easy to read since it is a graphical model and there are only four symbols to learn: Processes Data Flows Data Stores External Agents

6 Process Processes transform a data flow by changing its structure or by generating new information from it A process must have at least one data flow into it and one data flow out of it A process cannot exist independently <process title> Validate Customer Order

7 Data Flows A data flow is represented by an arrow and depicts the fact that some data is flowing from one process to another Data moved is sometimes called a packet of data The name of data flows should be different if the data is changed on entering the process <flow name> verified_order customer_address zip_code phone_# street_address

8 Data Stores When a process needs other data other than what it receives from another process, to perform its function, this ‘other’ data can be retrieved from data stores A data store is a collection of related information for example, a telephone book, student records held in a filing cabinet <store name> Orders

9 Sources and sinks External agents exist in the system’s environment and can: provide data to the system (i.e. a source or input) or receive data from the system (i.e. a sink or output) External entities include people like customers, managers, and include places like departments and suppliers The boundaries of a system determine what entities are external External agents are also referred to as terminators <external agent name> Customer

10 Components of a DFD Put Together
Orders order part_number new_order Customer Validate Order Stock

11 Please note... A DFD does not represent any control flow aspect in your system Therefore, no sequencing information can be read from a DFD However, this lack of control flow is not a drawback of DFD, because what we are modeling using DFDs are requirements and not how those are implemented Note: In general, a DFD is not a dependency diagram (where a process produces output whenever all inputs are available) Some extensions of DFD for real-time systems consider control flow (e.g.,

12 Direct data flow vs. data store
The analyst may decide if intermediate data needs to be stored persistently implied by the user’s needs implicates development cost

13 An alternative notation...
ID Location Sales Clerk Validate Customer Order 2 Process (rectangle instead a circle!) Data flow validate_order Data store Customers D1 Customer External agent (an oval instead of a rectangle)

14 A few comments about notation...
The modeling notation being used should be appropriate and efficient for the task at hand Beyond that it’s a matter of taste Circle, rectangle, a cloud... Use a standard whenever a standard available In any case, be consistent Underlying concepts matter Surface syntax can be learned quickly...

15 DFD Leveling DFDs allow the analyst to look at the system at different levels of detail Even quite small systems can be made up of many processes To include all processes in a single diagram can: make it look cluttered, make it difficult to see in detail what a process does To overcome this, we can ‘break down’ a single diagram, into a number of diagrams This process is known as leveling

16 Context Diagrams (Overview or Level 0)
Represents the system at the highest level of detail. Comprised of A single process representing the entire system modeled External entities The data flows that pass between the external entities and the system Purpose is to identify and examine the interfaces between the external entities and the system

17 Example of a context diagram

18 Context diagram for a telephone system

19 Guidelines for drawing a Context Diagram
List potential external entities (people, places). Look for entities that give data to the system without explaining the process that creates that data take data from the system without explaining what it does with that data Establish what flows are sent to and from the system from the external entities Draw the context diagram

20 Level 1 Diagram Show the system in more detail how data enters the system how these data items are transformed by the processes how they leave the system A level 1 diagram must have the same number of inputs and outputs as its context diagram The flows are connected to and from the actual processes which create, receive or change them Processes represent a breakdown of the activities which make up the system

21 Refinement of “Telephone System” processing element in the context diagram

22 Guidelines for drawing a Level 1 Diagram
Take one sentence at a time and try to identify potential processes (look for verbs) Group potential processes so you end up with (minimum) 3 to (maximum) 10 Identify and list the data flows (generally documents but could also be physical items). A data flow is really anything that moves around the system Identify and list the data stores Draw the level one diagram

23 Refinement of “PBX” processing element

24 DFD Fragments A DFD fragment is created for each event in the event list A DFD fragment is a self-contained model showing how the system responds to a single event As an analyst, you create DFD fragments one at a time

25 DFD fragment corresponding to the “off hook”

26 Bottom Level Continue decomposing a DFD into lower levels until the processes get so simple that you can describe them using: Process specifications in pseudocode Decision tables

27 Example of a process specification using pseudocode
1. IF the dollar amount of the invoice times the number of weeks overdue is greater than $10,000 THEN: a. Give a photocopy of the invoice to the appropriate salesperson who is to call the customer. b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done. c. Refile the invoice in the file for examination two weeks from today. 2: OTHERWISE IF more than four overdue notices have been sent THEN: a. Give a photocopy of the invoice to the appropriate salesperson to call the customer. c. Refile the invoice in the file to be examined one week from today. 3: OTHERWISE (the situation has not yet reached serious proportions): ...

28 Example of a decision table

29 Data in data flow diagrams
Data and data stores defined using Entity Relationship Diagrams and data dictionaries

30 Outline for today Introduction Data Flow Diagrams
Entity Relationship Diagrams Further Reading

31 Entity Relationship Diagrams (ERD)
ER diagrams describe things and relationships between them They were first proposed by Chen in 1976 Unify different approaches to database design (hierarchical, network and relational) Original reference: Peter Pin-Shan Chen. The entity-relationship model—toward a unified view of data . ACM Transaction on Database Systems. Vol. 1, No 1, 1976, pp 9-36 Different ERD notations in use, but basically the same underlying concepts

32 Components of ERDs Entities: Things about which we want or need to maintain information E.g., students, courses, suppliers, parts Attributes: Properties of entities E.g. student ID, Course #, course name Relationships: Associations between two or more entities Students take courses ERDs can represent real world (or even imaginary worlds) in a diagram

33 Example takes Entity (or more precisely: entity set or type) Student
Course FName takes C# CName LName Address CDescription Relationship Entity attribute

34 Relationships How two or more entities are related (if at all…)
Cardinality 1:1 (wife-husband) 1:N (mother-children) N:M (grandparents-grandchildren) Participation Total participation Every child has a mother Partial participation Not every person has a child

35 Meaning of ER diagrams 1 1 Entities represent object types wife
husband Associations between individual objects

36 One-To-Many Relationship
1 n mother children

37 Many-To-Many Relationship
4 m grand parents grand children

38 Partial participation

39 Kinds of Relationships
Mathematically, a relationship on the entities E1,..,En is a mathematical relation on E1,..,En, i.e., a subset of the Cartesian product E1 x E2 x…En. n gives rise to the arity of a relationship Binary relationship (n=2) Ternary relationship (n=3) N-ary relationships Unary relationship (n=1; basically, a predicate) Most likely represented as an Boolean attribute A recursive binary relationship is one where E1 and En is one the same set

40 Attributes Atomic: e.g. SSN
Compound: e.g. address (contain other atomic attributes: street, zip, state. Can expand it to several attributes ) Multi-valued: e.g. hobbies ( can have more than one hobby. Can expand to a relationship) Derived: e.g. age (can be derived from date of birth. You can decide whether you want to store the derived attributes in the database or not) Key: An attribute that uniquely identifies a thing

41 ERD Notation Different notations Some variations
No single standard notation Some variations Using diamond to denote relationships or not Providing cardinality or not Way of specifying cardinality

42 Notation used here Entity Relationship (unrary and binary only)
Exactly one Many (zero or more) Optional (zero or one) +1 One or more 1-3,6 Numerically specified

43 Summary of Diagrams in the Traditional Approach
Three main views: Data flow diagrams - process/functional view Entity-relationship diagrams - view of data structures State-transition diagrams - view of time-dependent behavior Two additional detailed views: Data dictionary - detailed structure of data Process specification - detailed structure of processes The above diagram types are used in Structured Analysis see Additional diagram type in Structured Design: Structure chart (module structure)

44 Further Reading Book by Ed Yourdon “Just Enough Structured Analysis”
Online version at Series of articles on ER modeling (discusses available tools): “Entity Relationship Modeling from an ORM perspective” by Terry Halpin see

Download ppt "ECE 355: Software Engineering"

Similar presentations

Ads by Google