A Survey of Modern Software Design Methodologies

Spring 2002 EEL5881

University of Central FloridaCollege 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 Formal

•JSD•DFD•OOD•SADT

•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 lower-level, 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-to-be 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 forspecifying, defining, and verifyingsystems”

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 object-oriented 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 structure-oriented design

Data Structures and Process Network -- Leticia

OOD Object-oriented Object Encapsulation -- John

Data Flow Diagram NotationBasic 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 notationWe still need formal processes or methodsDesign 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 ProjectUML 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