CS615 – Software
Engineering I |
Lecture
4 |
Analysis Modeling (Chapter 12)
Analysis Model
-
First technical representation of a system
-
Combination of text and diagrams to represent
software requirements (data, function, and behavior)
-
Analysis models make it easier to uncover
requirement inconsistencies and omissions.
-
Two types of analysis modeling:
-
structured analysis
-
object-oriented analysis
-
Data modeling: entity-relationship diagrams
define data objects, attributes, and relationships.
-
Functional modeling: data flow diagrams
show how data are transformed inside the system.
-
Behavioral modeling: state transition
diagrams show the impact of events.
Structured Analysis
(DeMarco)
-
Analysis products must be highly maintainable,
especially the software requirements specification.
-
Problems of size must be dealt with using
an effective method of partitioning.
-
Graphics should be used whenever possible.
-
Differentiate between the logical (essential)
and physical (implementation) considerations.
-
Find something to help with requirements partitioning
and document the partitioning before specification.
-
Devise a way to track and evaluate user interfaces.
-
Devise tools that describe logic and policy
better than narrative text.
Analysis Model Objectives
-
Describe what the customer requires.
-
Establish a basis for the creation of a software
design.
-
Devise a set of requirements that can be validated
once the software is built.
Analysis Model Elements
-
Data dictionary - contains the descriptions
of all data objects consumed or produced by the software
-
Entity relationship diagram (ERD) -
depicts relationships between data objects
-
Data flow diagram (DFD) - provides
an indication of how data are transformed as they move through the system;
also depicts functions that transform the data flow (a function is represented
in a DFD using a process specification or PSPEC)
-
State transition diagram (STD) - indicates
how the system behaves as a consequence of external events, states are
used to represent behavior modes. Arcs are labeled with the events triggering
the transitions from one state to another (control information is contained
in control specification or CSPEC)
Analysis Modeling:Where
to Begin?
-
A statement of scope
can be acquired from:
-
the FAST working document
-
A set of use-cases
-
the statement of scope
must be “parsed” to extract data, function and behavioral domain information
-
Statement of Scope
-
Relatively brief description
of the system to be built
-
indicates data that
are input and output and basic functionality
-
indicates conditional
processing (at a high level)
-
implies certain constraints
and limitations
-
Identifying Objectsand
Operations
-
define “objects” by
underlining all nouns in the written statement of scope
-
producers/consumers
of data
-
places where data are
stored
-
“composite” data items
-
define “operations”
by double underlining all active verbs
-
processes relevant to
the application
-
data transformations
-
consider other “services”
that will be required by the objects
Data Modeling Elements
(ERD)
-
Questions Answered
-
What are the primary data objects to be processed
by the system?
-
What is the composition of each data object
and what attributes describe the object?
-
Where do the the objects currently reside?
-
What are the relationships between each object
and other objects?
-
What are the relationships between the objects
and the processes that transform them?
-
Components
-
Data object - any person, organization,
device, or software product that produces or consumes information, e.g.
-
report
-
event
-
place
-
structure
-
Attributes - name a data object instance,
describe its characteristics, or make reference to another data object
-
Relationships - indicate the manner
in which data objects are connected to one another
Cardinality and Modality (ERD)
-
Cardinality - in data modeling, cardinality
specifies how the number of occurrences of one object are related to the
number of occurrences of another object (1:1, 1:N, M:N)
-
Modality - zero (0) for an optional
object relationship and one (1) for a mandatory relationship
Entity/Relationship Diagrams
-
Primary components identified for the ERD:
-
data objects
-
attributes
-
relationships
-
type indicators
-
Primary purpose: represent data objects
and their relationships
-
Iconography:
-
Data objects are represented by a labeled
rectangle
-
Relationships are indicated with a labeled
line connecting objects (Some variations: the connecting line contains
a diamond that is labeled with the relationship)
-
Connections between data objects and relationships
are established using a variety of special symbols that indicate cardinality
and modality
A simple ERD and data object table (Note: In this ERD the relationship
builds
is indicated by a diamond)
Expanded ERD
ERD representation of data object type hierarchies
Associative data object - represents the associativity between
objects
Creating Entity Relationship Diagrams
-
During requirements elicitation, customers
are asked to list the "things" that the application or business process
addresses. These "things" evolve into a list of input and output data objects
as well as external entities that produce or consume information.
-
Taking the objects one at a time, the analyst
and customer define whether or not a connection (unnamed at this stage)
exists between the data object and other objects.
-
Wherever a connection exists, the analyst
and the customer create one or more object/relationship pairs.
-
For each object/relationship pair, cardinality
and modality are explored.
-
Steps 2 through 4 are continued iteratively
until all object/relationships have been defined. It is common to discover
omissions as this process continues. New objects and relationships will
invariably be added as the number of iterations grows.
-
The attributes of each entity are defined.
-
An entity relationship diagram is formalized
and reviewed.
-
Steps 1 through 7 are repeated until data
modeling is complete.
Functional Modeling
and Information Flow (DFD)
-
Shows the relationships of external entities,
process or transforms, data items, and data stores
-
DFD's cannot show procedural detail (e.g.
conditionals or loops) only the flow of data through the software
-
Refinement from one DFD level to the next
should follow approximately a 1:5 ratio (this ratio will reduce as the
refinement proceeds)
-
To model real-time systems, structured analysis
notation must be available for time continuous data and event processing
Data Flow Diagrams (DFDs)
-
Graphical representation that depicts information
flow and the transforms that are applied as data move from input to output
-
Represents a system or software at any level
of abstraction
-
Partitioned into levels that represent increasing
information flow and functional detail - satisfies the second operational
analysis principle (i.e., creating a functional model)
-
Iconography
-
Circle (aka bubble) : a process or transform
applied to data and changes it in some way
-
Arrow : one or more data items (data objects)
-
Double line: data store — stored information
that is used by the software
-
Shadowed Rectangle : data source or sink -
where data begins or ends
-
Creating Data Flow Diagram
-
Level 0 data flow diagram should depict the
system as a single bubble
-
Primary input and output should be carefully
noted
-
Refinement should begin by consolidating candidate
processes, data objects, and data stores to be represented at the next
level
-
Label all arrows with meaningful names
-
Information flow must be maintained from one
level to level
-
Refine one bubble at a time
-
Write a PSPEC (a "mini-spec" written using
English or another natural language or a program design language) for each
bubble in the final DFD
-
Extensions for Real-Time Systems
-
Conventional data flow notation does not make
a distinction between discrete data and time-continuous data
-
Ward and Mellor Extensions - mechanism for
representing time-continuous data flow
-
Information flow is gathered or produced on
a time-continuous basis
-
Control information is passed throughout the
system and associated control processing
-
Multiple instances of the same transformation
are sometimes encountered in multitasking situations
-
Systems have states and a mechanism causes
transition between states
-
Initial Iconography
-
double headed arrow is used to represent time-continuous
flow
-
single headed arrow is used to indicate discrete
data flow
-
Revised Iconography
-
Data flow is represented using a solid arrow
-
Control flow is represented using a dashed
or shaded arrow
-
Control process - handles only control flows
- represented as a dashed bubble
-
Hatley and Pirbhai Extensions
-
Focus on the representation and specification
of the control-oriented aspects of the software
-
Dashed arrow used to represent control or
event flow
-
Dashed and solid notation be represented separately
- control flow diagram
-
Control flow diagram CFD - shows control flow,
rather than data flow
-
Notational reference (a solid bar) to a control
specification (CSPEC) is used
-
CSPEC used to indicate:
-
how the software behaves when an event or
control signal is sensed
-
which processes are invoked as a consequence
of the occurrence of the event
-
A process specification is used to describe
the inner workings of a process represented in a flow diagram
-
Hatley and Pirbhai's model of a real-time
system
-
Data flow diagrams used to represent data
and the processes that manipulate it.
-
Control flow diagrams show how events flow
among processes and illustrate those external events that cause various
processes to be activated
The relationship between data and control models
-
Creating Control Flow Diagrams
-
Begin by stripping all the data flow arrows
form the DFD
-
Events (solid arrows) and control items (dashed
arrows) are added to the diagram
-
Add a window to the CSPEC (contains an STD
that is a sequential specification of the behavior) for each bubble in
the final CFD
Behavioral Modeling
(STD)
-
State transition diagrams represent the system
states and events that trigger state transitions
-
state—a set of observable circum-stances
that characterizes the behavior of a system at a given time
-
state transition—the movement from
one state to another
-
event—an occurrence that causes the
system to exhibit some predictable form of behavior
-
action—process that occurs as a consequence
of making a transition
-
STD's indicate actions (e.g. process activation)
taken as a consequence of a particular event
-
A state is any observable mode of behavior
-
Hatley and Pirbhai control flow diagrams (CFD)
can also be used for behavioral modeling
-
Iconography
-
Rectangles represent system states
-
Arrows represent transitions between states
-
Each arrow is labeled with a ruled expression
-
Top value - the event(s) that cause the transition
to occur
-
Bottom value - the action that occurs as a
consequence of the event
Example
Level 1 CFD for photocopier software
State transition diagram for photocopier software
-
Building a Behavioral Model
-
make a list of the different states of a system
(How does the system behave?)
-
indicate how the system makes a transition
from one state to another (How does the system change state?)
-
indicate event
-
indicate action
-
draw a state transition diagram
Data Dictionary Contents
Data dictionary is an
organized listing of all data elements that are pertinent to the system,
with precise, rigorous definitions so that both user and system analyst
will have a common understanding of inputs, outputs, components of stores
and [even] intermediate calculations
-
Name - primary name for each data or control
item, data store, or external entity
-
Alias - alternate names for each data object
-
Where-used/how-used - a listing of processes
that use the data or control item and how it is used (e.g. input to process,
output from process, as a store, as an external entity)
-
Content description - notation for representing
content
-
Supplementary information - other data type
information, preset values, restrictions, limitations, etc.
Notation
Data Construct |
Notation |
Meaning |
|
= |
is composed of |
Sequence |
+ |
and |
Selection |
[ | ] |
either-or |
Repetition |
{}n |
n repetitions of |
|
( ) |
optional data |
|
* ... * |
delimits comments |
Notation enables representation of composite
data in one of the three fundamental ways that it can be constructed:
-
As a sequence of data items.
-
As a selection from among a set of data items.
-
As a repeated grouping of data items. Each
data item entry that is represented as part of a sequence, selection, or
repetition may itself be another composite data item that needs further
refinement within the dictionary.
Design Concepts and Principles (Chapter 12)
-
Software requirements model is transformed
into design models that describe the details of the data structures, system
architecture, interface, and components
-
Each design product is reviewed for quality
before moving to the next phase of software development
Translating the analysis model into a software design
Design Specification
Models
-
Data design - created by transforming
the analysis information model (data dictionary and ERD) into data structures
required to implement the software
-
Architectural design - defines
the relationships among the major structural elements of the software,
it is derived from the system specification, the analysis model, and the
subsystem interactions defined in the analysis model (DFD)
-
Interface design - describes
how the software elements communicate with each other, with other systems,
and with human users; the data flow and control flow diagrams provide much
the necessary information
-
Component-level design - created
by transforming the structural elements defined by the software architecture
into procedural descriptions of software components using information obtained
from the PSPEC, CSPEC, and STD
The Design Process
-
Good Design Characteristics
-
The design must implement all of the explicit
requirements contained in the analysis model, and it must accommodate all
of the implicit requirements desired by the customer.
-
The design must be a readable, understandable
guide for those who generate code and for those who test and subsequently
support the software.
-
The design should provide a complete picture
of the software, addressing the data, functional, and behavioral domains
from an implementation perspective.
-
Design Guidelines
-
A design should exhibit an architectural structure
that it:
(1) has been created using recognizable
design patterns
(2) is composed of components that exhibit
good design characteristics
(3) can be implemented in an evolutionary
fashion, thereby facilitating implementation and testing.
-
A design should be modular; that is, the software
should be logically partitioned into elements that perform specific functions
and subfunctions.
-
A design should contain distinct representations
of data, architecture, interfaces, and components (modules).
-
A design should lead to data structures that
are appropriate for the objects to be implemented and are drawn from recognizable
data patterns.
-
A design should lead to components that exhibit
independent functional characteristics.
-
A design should lead to interfaces that reduce
the complexity of connections between modules and with the external environment.
-
A design should be derived using a repeatable
method that is driven by information obtained during software requirements
analysis.
Design Principles
-
The design process should
not suffer from "tunnel vision."
-
The design should be
traceable to the analysis model.
-
The design should not
reinvent the wheel.
-
The structure of the
software design should mimic the structure of the problem domain.
-
The design should exhibit
uniformity and integration.
-
The design should be
structured to accommodate change.
-
The design should be
structured to degrade gently, even when aberrant data, events, or operating
conditions are encountered.
-
Design is not coding,
coding is not design.
-
The design should be
assessed for quality as it is being created, not after the fact.
-
The design should be
reviewed to minimize conceptual (semantic) errors.
Software Design Concepts
-
Abstraction - allows designers to focus
on solving a problem without being concerned about irrelevant lower level
details (procedural abstraction - named sequence of events, data abstraction
- named collection of data objects)
-
Refinement - process of elaboration
where the designer provides successively more detail for each design component
-
Modularity - the degree to which software
can be understood by examining its components independently of one another
Modularity and software cost
-
Modular Design Method Evaluation Criteria
-
Modular decomposability - provides
systematic means for breaking problem into subproblems
-
Modular composability - supports reuse
of existing modules in new systems
-
Modular understandability - module
can be understood as a stand-alone unit
-
Modular continuity - side-effects due
to module changes minimized
-
Modular protection - side-effects due
to processing errors minimized
-
Software architecture - overall structure
of the software components and the ways in which that structure provides
conceptual integrity for a system
-
Structural properties - Defines the
components of a system (e.g., modules, objects, filters) and the manner
in which those components are packaged and interact with one another.
-
Extra-functional properties - The architectural
design description should address how the design architecture achieves
requirements for performance, capacity, reliability, security, adaptability,
and other system characteristics.
-
Families of related systems - The architectural
design should draw upon repeatable patterns that are commonly encountered
in the design of families of similar systems. In essence, the design should
have the ability to reuse architectural building blocks.
-
Control hierarchy or program structure
- represents the module organization and implies a control hierarchy, but
does not represent the procedural aspects of the software (e.g. event sequences)
Typical Hierarchical Control Structure
-
Structural partitioning
-
horizontal partitioning - defines three
partitions (input, data transformations, and output)
-
Benefits:
-
software that is easier to test
-
software that is easier to maintain
-
propagation of fewer side effects
-
software that is easier to extend
-
vertical partitioning (factoring) -
distributes control in a top-down manner (control decisions in top level
modules and processing work in the lower level modules)
-
Data structure - representation of
the logical relationship among individual data elements (requires at least
as much attention as algorithm design)
-
Software procedure - precise specification
of processing (event sequences, decision points, repetitive operations,
data organization/structure)
-
Information hiding - information (data
and procedure) contained within a module is inaccessible to modules that
have no need for such information
Effective Modular Design
Functional Independence
-
Design software so that each module addresses
a specific subfunction of requirements and has a simple interface when
viewed from other parts of the program structure
-
Measured using two qualitative criteria:
-
Cohesion is a measure of the relative
functional strength of a module
-
Natural extension of the information hiding
-
Cohesive module performs a single task within
a software procedure, requiring little interaction with procedures being
performed in other parts of a program
-
Range of Cohesion - low (worse)
to high (better)
low |
coincidental cohesion |
module that performs tasks that are related
logically |
|
temporal cohesion |
module contains tasks that are related
by the fact that all must be executed with the same spanof time |
|
procedural cohesion |
processing elements of a module are related
and must be executed in a specific order |
|
communicational cohesion |
all processingelements concentrate on
one area of a data structure |
high |
|
module that performs one distinctprocedural
task. |
-
Coupling is a measure of the relative
interdependence among modules
-
Best - lowest possible coupling
low |
data coupling |
simple data are passed- a one-to-one correspondence
of items exists |
|
stamp coupling |
a portion of a datastructure (rather than
simple arguments) is passed via a module interface |
|
control coupling |
where a "control flag" is passed between
modules |
|
external coupling |
modules are tied toan environment external
to software |
|
common coupling |
when a number of modulesreference a global
data area |
high |
content coupling |
when one modulemakes use of data or control
information maintained within the boundaryof another module |
Design Heuristics for
effective Modularity
Program structure can
be manipulated according to the following set of heuristics:
-
Evaluate the "first
iteration" of the program structure to reduce coupling and improve cohesion
-
Attempt to minimize
structures with high fan-out; strive for fan-in as depth increases
-
Keep the scope of effect
of a module within the scope of control of that module
-
Evaluate module interfaces
to reduce complexity and redundancy and improve consistency
-
Define modules whose
function is predictable, but avoid modules that are overly restrictive
-
Strive for "controlled
entry" modules by avoiding "pathological connections."
Design Documentation
Software
Design Specification from:
-
System Specification
-
Software Requirements Specification