Speci cation and Documentation Techniques: Graphical

Previous LecturesInformation flows

Specification and Documentation Techniques:Graphical Notations (2)

CS/SE 3RA3

Ryszard Janicki

Department of Computing and Software, McMaster University, Hamilton,Ontario, Canada

Ryszard Janicki Graphical Notations (2) 1/20


Last lecture

Entity-relationship diagramsEE--R DiagramsR Diagrams

Rectangles represent entity sets.ec a g es ep ese e y se s

Diamonds represent relationship sets.

Lines link attributes to entity sets and entity sets to relationship sets.

Ellipses represent attributes

Double ellipses represent multivalued attributes.

Dashed ellipses denote derived attributes Dashed ellipses denote derived attributes.

Underline indicates primary key attributes



Last lecture

UML version

Entity-relationship diagram: example

I it ti M tiInvitesinvitedTo

entitybinary relationshiprolespecialization

Participant 1..* 0..*Invitation Meeting

DateLocation Name

Address

InvitesinvitedTo

constraintsFor constraintsFrom 1 *

attribute

Constraints

Address Email

excludedDatesf dD tI t t

Requesting

dateRangewithWhom

1..*

Initiator1..1

preferredDatesImportantParticipant

Preferences Email

NormalParticipant

…

withWhom

attributes ofrelationship

A meeting invites at least 1 up toan arbitrary number of participants



Context diagramsDataflow diagramsContext diagrams vs Dataflow diagramsDataflows vs Entity-relationship diagrams

Context model and context diagrams

The context model is a simple representation of functionality

It shows the flows of data entering and leaving the work (i.e.main function of the product) area

Each flow triggers some functionality or is the product ofsome functionality

The context model is represented by a context diagram,which is a simplified dataflow

Context diagrams are just level zero dataflows


Context diagrams - deicing system



Context diagrams - chemical tracking system


Example (Elevator: Context Diagram)

Q4(6+6=12)

Context Diagram

13



Information flows: dataflow diagrams

Capture system operations linked by data dependencies

Operation / process = data transformation activity

Input, output links = data flows

- operation needs data flowing in to produce data flowing out(6= control flow !)

Data transformation rule to be specified

- in annotation (structured natural language)- or in another dataflow diagram (operation refinement -

hierarchical structure, modularity)

System components, data repositories = origins, ends of flow

Consistency/completeness rules checkable by tools




Dataflow diagrams

Dataflow diagrams model information and data flows amongprocesses

Black-box processes / operations → circles (bubbles)

Components / terminators / external entities / adjacentsystems → boxes or other shapes

Data stores / depository → horizontal lines or other shapes

Data / material / information flows → arrows

Dataflows have hierarchical structure → each black box (i.e.circle/bubble) can be expanded


Dataflow diagrams: chemical tracking system



Dataflow diagrams: meeting schedule

Dataflow diagram: example

copyOf

input data flow output data

flowInitiator

copyOfconstraintsRequestmeeting

Request

Participant

ti

invalidRequest

flow

AskConstraints

t i tR tmeeting

C t i tC ll t M Determine

meetingNotificationCheck

Request

RequestvalidRequest operation

constraintRequest Constraints

individualC t i t

CollectConstraints

Participant

MergeConstraints

DetermineSchedule

Constraints participantConstraints

data repositorysystem component


Dataflow diagrams: university

Dataflow diagrams: bank

Dataflow diagrams: filling orders

Example (Elevator: Data Flow)

Data-Flow Diagram

14



Some rules (may not always be followed)Always start with context diagramProcesses communicate through system components and datastores, not by direct flows from one process to another (thisrule is not always followed, see ‘Meeting Schedule’).Similarly, data cannot flow directly from on store/componentto another; it must pass through a process bubble (this rule isalways followed).Do not attempt to imply the processing sequence usingthe dataflow diagrams.Name each process as a concise action: verb + object(generate inventory reports).Number the processes uniquely and hierarchically, for instancenext level for 3 should be 3.1, 3.2 and so on.No more that 8-10 processes on a single diagram.Avoid bubbles with only inputs and only outputs.


Contex diagrams as simplified dataflow diagrams: one“bubble”



From context diagrams to dataflow diagrams: ChemicalTracking System




From context diagrams to dataflow diagrams: FillingOrders




Relationship between Dataflows and ER diagramsEntities often correspond to data depositories of dataflows


Documents

Speci cation and Documentation Techniques: Graphical