A Survey of Modern
Software Design
Methodologies
Spring 2002
EEL5881
University of Central Florida
College of Electrical Engineering & Computer Science
ArgoUML Team
 Dawid Trawczynski
 Chi-Hwa John Marcos
 Pete Lorins
 Leticia Izquierdo
Overview
 Methodology defined
 General representation of methodologies
 Determining factors
 Methodologies Survey
– Key points
– Strengths & Weaknesses
 Application to ArgoUML
What Is a Methodology?
 Methodology = model + techniques
 Set of procedures that one follows from
beginning to end of software development
process
 Principles or practices of an orderly
procedure
Design Methodologies
Systematic
•JSD
•DFD
•OOD
•SADT
Formal
•Z notation
•B-method
•VDM
•ACL-2
Determining Factors
 Development environment
 Organization’s practices
 Nature/type of software
 User requirements
 Qualification & training of development team
 Availability of hardware & software resources
 Availability of existing design modules
 Budget & time schedule
Major Software Life-cycle
Models
 Waterfall
 Rapid Prototyping
 Incremental
 Extreme Programming
 Object-Oriented
Methodologies Survey
Methodologies Discussed
 Top-down Method
 Bottom-up Method
 Jackson System Development Method
 Formal Methods
 Object-Oriented Methods
 Data Flow-Oriented Method
Top-down & Bottom-up Design
Methods
 Applicable to all methodologies
 Top-Down
– Top-level description decomposed to lowerlevel, small modules
 Bottom-Up
– Basic set of modules and interrelationships
formulated to higher-level concepts
Top-down
 Level-oriented design
 Iterative process of decomposition
 Allows for early evaluation of functional
capabilities
 Best suited when problem & environment
are well-defined
– Ex: designing a compiler
Bottom-up
 Yields smaller and more agile programs
 Promotes code re-use
 Permits assessment of sub-modules
 Best suited when problem is ill-defined or
missing
Jackson Systems Development
Method
 Data structure-oriented design
 Based on a set of entities and their actions,
and of the attributes associated with these
actions
 Models specifications of I/O data structures
using tree structured diagrams
 Developed by Michael Jackson (1989)
– Extension of Jackson Structured Programming
method (1975)
JSD Steps
 Entity Action
 Entity Structure
 Initial model
 Function
 System timing
 Implementation
JSD Strengths
 Well-defined framework
 Best suited for large systems
 Best suited for real-time system
development
JSD Weaknesses
 Structure clashes
– Arises when correspondence of nodes in I/O
data structures can’t be determined
– Resolved by creating producer/consumer
routine
 Need for look-ahead
– Arises when processing data depends on yet-tobe processed data
– Resolved by backtracking, or saving the state of
the program before each processing sequence
JSD Applications
 Sequential programs
– Inventory, finance, banking, insurance
 Large systems where events need to be
scheduled according to time
– Process control, data processing
Formal Method
 “Formal methods provide a rigorous,
mathematical based framework for
specifying, defining, and verifying
systems”
 Provides precise definition of
– Consistency
– Completeness
– Specification
– Implementation
– Correctness
Common Characteristics
 Mathematically intensive
 Precise language
 Verifiable through proofs
 Consistency
Formal Languages
 Z notation
 B-method
 VDM (Vienna Development Method)
 PVS (Prototype Verification System)
 ACL-2
Example of ACL2
ACL2 !>(thm (implies (and (not (endp x))
(endp (cdr x))
(integerp n)
(<= 0 n)
(rationalp u))
(< (* (len x) u) (+ u n 3))))
Formal Strengths
 Suitable for defense related and NASA
software (missile, rockets, etc)
 Suitable for medical and real time
 Precise language
 Consistency
 Verification through proofs
 Reuse
Formal Weaknesses
 Mathematically intensive
 Time consuming
 Verification through proofs on idealize
abstract machines
 Drastic change in adoption
Weaknesses Cont’d
 May require hiring of experts
 Not suitable at this time for large complex
systems
 Costly retraining
OOD Method
 “Object-oriented design (OOD) is
concerned with developing an objectoriented model of a software system to
implement the identified requirements.”
 OO Programming started with the
development of Simula language in Norway
in 1967 - based on ALGO and the earlier
discrete event simulation language Simula
OOD Terms and Concepts
 Objects - Basic units of construction.
– Attributes
– Procedures or Methods
– Rules (Specifies how the features of the object
are related or under what conditions the object
is viable.)
 Identity
– Objects have unique identity throughout their
lives in conceptual level.
– Arguable in the program level.
OOD Terms and Concepts Cont.
 Encapsulation - Information hiding.
– Attributes are only accessible through well
defined interface.
– Implementation hidden from outside of the
object.
 Messages - method of communication
between objects.
OOD Terms and Concepts Cont.
 Inheritance - Implements the idea of
specialization and generalization.
 Polymorphism - “The ability to use the
same expression to denote different
operations.”
 Substitutability - The ability to substitute
subclasses for their parent classes.
OOD Terms and Concepts Cont.
 Delegation - Classless inheritance (The
ability of objects to delegate to other objects
the permission to perform operations on
their behalf.
OO Design (UML).
 Package Diagrams - Relationship between
packages.
 Class Diagrams - Relationship between
classes.
 Use Case Diagrams - Relationship between
system and actors.
 State Diagrams - Sequences of states.
 Sequence Diagrams - Sequence of events.
Package Diagram Example
Class Diagram Example
Use Case Diagram Example
State Diagram Example
Sequence Diagram Example
OOD Methods
 UML
 Booch
 Coad and Yurdon
 Fusion
 Jacobson: Objectory and OOSE
 LBMS SEOO
 Rumbaugh OMT
OOD Strengths
 Reduction of complexity
 Reuse
 Long term lower cost and schedule time
 Abundance of CASE tools
 Availability of inexpensive hardware and
software tools
 Suitable for large complex projects
 Design encompasses entire process
OOD Weaknesses
 Commitment to formal training
 High learning curve
 Costly training
 Not suitable for small projects
The Data Flow-Oriented Design (DFD)
Methodology
The Data Flow-Oriented design approach is often
called “Structured Design.”... Why?
It is an approach that uses information flow
characteristic to design program structure. In other
words, emphasis is placed on the processing or the
operations performed by the data. Thus, design
in this approach is information driven.
The above implies that information can be
represented as a continuous flow, that is
transformed as it is processed from node to node in
the input-output stream.
The Data Flow-Oriented Design (DFD) Means
Of Mapping into The Design Structure
A DFD can be mapped into the design structure by two means:
1)
Transform Analysis:
Applied when the data flow in the input-output stream has
clear boundaries. The DFD is mapped into a structure that
allocates control to 3 basic modules:
Input – Process – Output
2)
Transaction Analysis:
Applied when a single information item causes flow to
branch along one of many paths. The DFD is mapped to a
substructure that acquires and evaluates a transaction
while another substructure controls all the data processing
actions based on a transaction.
Examples of DFD Design Methodologies

Structured Analysis & Design Technique (SADT):
The structured analysis and structured design methodology is
used to explore systems and software at a higher conceptual
level and help to identify elements that are critical to success.
The many tools of SASD include context diagrams, event
lists, data dictionary, entity relationship diagrams, structure
charts and state transition diagrams.

System Design (SD) Methodology:
In this methodology, we use Data Flow Diagrams and Charts
as graphical techniques that depicts information flow and the
transforms that are applied as data moves from input to
output.
Software Design Methodology Classification
As a measure of recapitulation, the following are the
methodologies that my group decided to focus on... My
focus was on the SD method of DFD.
Method
Design Type
Concept
SD
DFD
Data Flow Diagrams and Charts -Myself
JSD
Data structureoriented design
Data Structures and Process Network
-- Leticia
OOD
Object-oriented
Object Encapsulation -- John
Data Flow Diagram Notation
Basic Data Flow Notation

Rectangle (external entity) - a producer or consumer of
information that resides outside the bounds of the system to be
modeled

Circle (process) - a transformer of information that resides within
the bounds of the system to be modeled

Line with an arrow ( data item) - a single item, or a collection of
data items. Arrow head represents the direction of the data

4) Two parallel lines (data store) - a repository of data that is to
be stored for use by one or more processes; may be as simple as a
buffer or a queue or as sophisticated as a relational data base
Simple Example Of A Data Flow Diagram
The Following Depicts an Online Ordering System:
UML Design Methodology
UML what is it?




Unified Modeling Language
Allows for Abstract Level Programming
Avoids programming details
UML specifies, visualizes, constructs, and
documents system-intensive process
 Contains and expresses knowledge about a system
in an easy to interpret fashion thru diagram
descriptions
 Gives a standard way of communicating system
designs and details
UML is not:
 A visual programming language
 A tool or repository specification
 A process
 UML enables processes and designs
UML – Process Independence
UML itself is only a standardized notation
We still need formal processes or methods
Design processes that may implement UML are:






Generic Process
Cleanroom Process
Booch Process
Objectory Process
Shaller-Mellor Process
Object Modeling Technique (OMT) Process
OMT Process Overview
 Creation of analysis models that
characterize requirements for the proposed
system
 Design of frameworks, architecture and
strategies for the system
 Detailed object design in a target language
(ArgoUML = Java )
OMT Process Flow Diagram
OMT Models
In order to realize analysis, system design,
and object design OMT developed models.
 Object Model – defines system structure
 Dynamic Model – temporal evolution of
system objects and behavior of those
 Functional Model – operations of system’s
objects
UML and OMT
 OMT models are often realized in UML due to
UML’s natural way of implementing these models
 Goal: Construct a diagram that depicts a model.
It will contain all concepts and knowledge from
“real world” that are important to an application
 UML provides diagram structures- these
structures allows for clear representation of
object, dynamic, and functional models
OMT Modeling Steps





Identify object classes
Prepare a data dictionary
Identify associations between objects
Identify attributes of objects and links
Organize and simplify object classes using
inheritance
 Verify access paths
 Iterate and refine model
 Group classes in modules
UML Structure Diagrams
To implement or visualize models we need to
create UML structure diagrams.
 Class diagram
 Use case diagram
 Message trace diagram
 Object message diagram
 State diagram
 Module diagram
 Platform diagram
 Operational specification
UML Notation Examples
Class Diagram – Static System
Structure
Shows classes of the system and relationships
Object Message Diagram
Used to describe logic for a case scenario
Other Diagrams I
 Use case depicts external users of the
system and how the system interacts with
the user
 The message trace diagram depicts a single
scenario of stimulus and response
interchanges between a specific object and
its external users
Other UML Diagrams II
 The state diagram describes aspects of the
behavior of a system and serve as formal
specifications of the behavior of a class
 The module diagram provides a
visualization of the elements of the object
model in terms of their allocation to
physical modules
Other UML Diagrams III
 The platform diagram provides a
visualization of the physical topology upon
which a software system is designed to
execute
 An operation specification is a template for
use in describing an operation of an object
Conclusion
 UML makes complex process designs
simpler, easier to understand, organize and
modify
 Currently Java, C++, and Smalltalk versions
of UML exist
ArgoUML Project
UML Design Methodology
Dependencies
 Software development environment
• Waterfall model
• Team with flexible hierarchy
 Organization's practices
• Use whatever design that gets the job done
 Nature or type of software being developed
• ArgoUML
Dependencies
 Users’ requirements
• Well understood and precise
 Qualification and training of the S/W
development team
• Java and C++
• Some Ada and Fortran
Dependencies
 Availability of hardware and software resources
• ArgoUML
• Servers and workstations
• Home PCs
Dependencies
 Budget and time schedule
• No budget (free software)
• One semester time constraint
References
 http://www.csam.iit.edu/~cs561/dataflow/dataflow.html
 http://userpages.umbc.edu/~khoo/survey1.html
 http://www.smartdraw.com/resources/centers/software/ssadm.htm
 http://dspace.dial.pipex.com/jacksonma/
 http://www.smartdraw.com/resources/centers/software/jsd.htm
 http://cisx2.uma.maine.edu/NickTemp/JSP&JSDLec/jsd.html
 http://www.paulgraham.com/progbot.html
 http://userpages.umbc.edu/~khoo/survey2.html
References
 Formal methods
http://shemesh.larc.nasa.gov/fm/index.html
http://www.afm.sbu.ac.uk/
http://www.cs.ubc.ca/spider/kwong/se.html#formal
http://wwwsel.iit.nrc.ca/favs/FMfavs.html
 Object-Oriented Design
Graham, Ian. Object-Oriented Methods Principle & Practice Third Edition. Great
Britain: Addison-Wesley, 1991.
http://www.kb.nl/coop/elag/elag95/papers/183.html
http://www.well.com/user/ritchie/oo.html
http://www.cetus-links.org/
http://catalog.com/softinfo/objects.html
http://www.rational.com/uml/index.jsp