A Survey of Modern Software Design Methodologies Spring 2002 EEL5881 University of Central Florida...
-
Upload
randolf-mathews -
Category
Documents
-
view
216 -
download
2
Transcript of A Survey of Modern Software Design Methodologies Spring 2002 EEL5881 University of Central Florida...
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