1 ece 355: software engineering traditional analysis and modeling approaches lectures notes by...
Post on 16-Dec-2015
215 Views
Preview:
TRANSCRIPT
1
ECE 355: Software Engineering
Traditional Analysis and Modeling ApproachesLectures 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
• IntroductionData 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
Validate Customer
Order
<processtitle>
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
verified_order
<flow name>
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
Orders
<store name>
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
Customer
<externalagent
name>
10
Components of a DFD Put Together
Orders
order
part_numbernew_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., http://www.yourdon.com/books/msa2e/)
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...
Customer
CustomersD1
ID
Sales Clerk
Validate Customer Order
2
Location
validate_order
Process(rectangle instead a circle!)
Data flow
Data store
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.
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):
...
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 DiagramsEntity 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
Student
FName
LName
Address
Course
C#CName
CDescription
takes
Entity(or more precisely: entity set or type)
Entity attribute
Relationship
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
wife husband
Entitiesrepresentobject types
Associationsbetweenindividualobjects
1 1
36
One-To-Many Relationship
mother children1 n
37
Many-To-Many Relationship
grandparents
grandchildren
4 m
38
Partial participation
1
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– 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
+1
1-3,6
Exactly one
Many (zero or more)
Optional (zero or one)
One or more
Numerically specified
Relationship (unrary and binary only)
Entity
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 http://www.yourdon.com/books/msa2e/
• Additional diagram type in Structured Design:– Structure chart (module structure)
44
Further Reading
• Book by Ed Yourdon “Just Enough Structured Analysis”– Online version at
http://www.yourdon.com/books/msa2e/
• 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/
top related