ECE 355 Software Engineering Traditional Analysis and Modeling

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

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 2

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

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) 4

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 5

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 6

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 zip_code customer_address phone_# street_address 7

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 8

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 9

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

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 11 control flow (e. g. , http: //www. yourdon. com/books/msa 2 e/)

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 12

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

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. . . 14

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 15

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 16

Example of a context diagram 17

Context diagram for a telephone system 18

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 19

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 20

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

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 22

Refinement of “PBX” processing element 23

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 24

DFD fragment corresponding to the “off hook” 25

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 26

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. 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 to be examined one week from today. 3: OTHERWISE (the situation has not yet reached serious proportions): . . . 27

Example of a decision table 28

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

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

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 31

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 32 worlds) in a diagram

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

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

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

One-To-Many Relationship mother 1 n children 36

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

Partial participation 1 38

Kinds of Relationships • Mathematically, a relationship on the entities E 1, . . , En is a mathematical relation on E 1, . . , En, i. e. , a subset of the Cartesian product E 1 x E 2 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 E 1 and En is one the same set 39

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 40

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

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

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 http: //www. yourdon. com/books/msa 2 e/ • Additional diagram type in Structured Design: – Structure chart (module structure) 43

Further Reading • Book by Ed Yourdon “Just Enough Structured Analysis” – Online version at http: //www. yourdon. com/books/msa 2 e/ • Series of articles on ER modeling (discusses available tools): – “Entity Relationship Modeling from an ORM perspective” by Terry Halpin – see http: //www. inconcept. com/JCM/ 44