DFD: A Basic Example

display Panel
information
commands display
Control and data
panel alarm

EEC 521: Software Home

Security
software
type
Alarm

Engineering Sensors sensor

status
telephone Telephone
tones line
Analysis Modeling - 2

External entities Data flows Processes

(squares) (directed edges) (circles)
Notice that the system is represented as a single bubble
This is known as a level 0 DFD, or a context diagram
EEC 521 EEC 521
Software Engineering Software Engineering

DFDs and Progressive

Data Flow Diagrams
Refinement
Each DFD reveals progressively more detail than
Structured Analysis Modeling Tools the DFD that preceded it
• Models data elements • Data object diagrams
– Attributes modeled • ERD diagrams Level 1 DFD:
using
– Relationships commands Configure
and data request Configure
• Models processes that • Data flow diagram Control Interact
system
…
panel with user
transform data modeled • Process narrative
Start/stop
request
using
A data flow diagram describes information flow among a Activate /
set of processes and actors. password deactivate …
1 system
Refinement continues until
* each bubble can be (easily)
A process narrative describes how a single process implemented as a program
module Process
transforms input data to output data. password
…

EEC 521 EEC 521

Software Engineering Software Engineering
Process Narrative Some Guidelines
… password
A process specification describes • Level 0 DFD should contain only a single
all of the flow processes in the
Process … final (most detailed) DFD. bubble
password
• All arrows and bubbles should be
meaningfully labeled
“The process password transform performs password validation
at the control panel for the SafeHome security function. Process
• Refinement begins by isolating next level
password receives a four-digit password from the interact with processes, data objects, and data stores
user function. The password is first compared to the master
password stored within the system …” • Refine only one bubble at a time
• Data flow continuity must be maintained
A process specification can be represented as a collection between levels
of process narratives.
EEC 521 EEC 521
Software Engineering Software Engineering

Exercise: Data Flow

DFD Construction
Scope Grammatical Level 0 Diagrams
document parse DFD
Create a level 0 data flow diagram for a
basic automated teller machine (ATM).

Develop You can ignore administrative scenarios.

process Grammatical Next level
narratives parse DFD
What would the level 1 data flow
diagram look like?

(nouns = external entities, data/control objects, data stores)

(verbs = processes)
Note that nouns and verbs are associated with one another
EEC 521 EEC 521
Software Engineering Software Engineering
A Different View Accessibility
Object-Oriented Analysis Modeling Tools • Attributes and Methods can be declared at three
• Models analysis classes • Class diagrams levels of accessibility
modeled
– Data using • Packages – Public (+)
– Processes • Visible everywhere
• Models class • CRC cards – Private (-)
modeled
collaborations using • Sequence diagrams • Visible only from inside the declaring class
– Protected (#)
• Visible only from within the declaring class and any of its
Object-oriented analysis results in an analysis model that subclasses
describes a system of collaborating objects
• We will all now swear never to declare public
Every object encapsulates a set of data elements, and attributes
exports a set of operations for working with those elements
EEC 521 EEC 521
Software Engineering Software Engineering

Classes and Objects Inheritance

• A class consists of a set of attributes and methods. A
class diagram is used to show the static structure of a • Inheritance allows a subclass to inherit the
class attributes and methods of a superclass
AnsweringMachine Class name
-greeting AnsweringMachine AnsweringMachineWithTime
-messages Attributes
-greeting -time
+setGreeting() -messages
+getMessages() Methods
+setGreeting() +setTime()
+recordMessage()
+getMessages()
“Inherits from”
+recordMessage() or
“Specializes”
• Each class is like a template that defines how instances
of the class – objects – should be created • A subclass begins with everything provided by
its superclass (or base class)
classes objects – Can add additional attributes and methods
– Can override existing public/protected methods
EEC 521 EEC 521
Software Engineering Software Engineering
Inheritance Hierarchy Other Relationships
Whole Collection
• An inheritance hierarchy (or class hierarchy)
refers to all of the classes in a system, and the
inheritance relations among them
• Depending on the type of system being
developed, the class hierarchy can be complex! PartA PartB Items

http://java.sun.com/j2se/1.3/docs/api/

Composition Aggregation
http://msdn.microsoft.com/library/default.asp?url= Defines a whole/part Defines a containment
/library/en-us/cpref/html/frlrfsystemhierarchy.asp relationship relationship
Multiplicity may be specified in either case
EEC 521 EEC 521
Software Engineering Software Engineering

Identifying Analysis
Associations
Classes
• Just like data objects, classes can be • We begin with a grammatical parse
– Nouns
related to one another. These • Candidate classes
relationships are called “associations” – External entities, events, places, structures, things, etc.
• Candidate attributes
– Entities that naturally belong to a class
Phone
direction AnsweringMachine – Verbs
-phoneNumber -greeting • Candidate methods
-messages
– Operations that manipulate data
+getPhoneNumber() * 1 +setGreeting()
+dialPhone() +getMessages() – Operations that perform a computation
+answerPhone() +recordMessage() – Operations that inquire about state
“Handles calls for”
– Operations that check for a control event

multiplicity

EEC 521 EEC 521

Software Engineering Software Engineering
 Distribution, Cohesion, and
Building the OOA Model
Encapsulation
• Use the initial set of analysis classes as the basis for • Some additional model desiderata
building the OOA model
• Identify class responsibilities
– Responsibility distribution
– What are its primary jobs? • Intelligence should be distributed across classes
• Identify class relationships and collaborations • Avoid monolithic classes
– What other classes does it need to interact with? – Class cohesion
– How will they interact? • Classes should be single minded
• Identify class commonalities and variabilities • Avoid classes with unrelated members
– Which attributes/methods do they have in common?
– Which attributes/methods vary? – Encapsulation
• The class with the data should do the work
This will be an iterative • Avoid passing state to other classes
process!
EEC 521 EEC 521
Software Engineering Software Engineering

Some Rules of Thumb Categorization

• Focus on the problem
– Identify “what” classes/attributes
– Ignore “how” classes/attributes
• Focus on core classes
– Eliminate procedural classes
– Avoid data classes
– Avoid classes with only a single attribute
• Use (don’t overuse) inheritance intelligently
– Move commonalities up the hierarchy
– Move variabilities down the hierarchy
– Avoid deep hierarchies
• Categorization is one of the most
important tools in our intellectual toolbox
• How do we manage (intellectually) a large
number of related items?
– We group the items into categories of items
that share common characteristics or satisfy
common goals
• In object-oriented analysis, we categorize
classes using analysis packages

EEC 521 EEC 521

Software Engineering Software Engineering
Analysis Packages
• An analysis package is a collection of related analysis
classes grouped under a representative name
package name

UML notation
classes

accessibility modifiers
Java, C#, and VB .NET use a similar notion for categorizing
implementation
EEC 521
classes
Software Engineering