A Survey of Modern Software Design Methodologies

1. A Survey of Modern Software Design Methodologies Spring 2002 EEL5881 University of Central Florida College of Electrical Engineering & Computer Science

2. ArgoUML Team • Dawid Trawczynski • Chi-Hwa John Marcos • Pete Lorins • Leticia Izquierdo

3. Overview • Methodology defined • General representation of methodologies • Determining factors • Methodologies Survey • Key points • Strengths & Weaknesses • Application to ArgoUML

4. 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

5. Design Methodologies Systematic Formal • JSD • DFD • OOD • SADT • Z notation • B-method • VDM • ACL-2

6. 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

7. Major Software Life-cycle Models • Waterfall • Rapid Prototyping • Incremental • Extreme Programming • Object-Oriented

8. Methodologies Survey

9. Methodologies Discussed • Top-down Method • Bottom-up Method • Jackson System Development Method • Formal Methods • Object-Oriented Methods • Data Flow-Oriented Method

10. 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

11. 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

12. 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

13. 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)

14. JSD Steps • Entity Action • Entity Structure • Initial model • Function • System timing • Implementation

15. JSD Strengths • Well-defined framework • Best suited for large systems • Best suited for real-time system development

16. 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

17. JSD Applications • Sequential programs • Inventory, finance, banking, insurance • Large systems where events need to be scheduled according to time • Process control, data processing

18. 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

19. Common Characteristics • Mathematically intensive • Precise language • Verifiable through proofs • Consistency

20. Formal Languages • Z notation • B-method • VDM (Vienna Development Method) • PVS (Prototype Verification System) • ACL-2

21. 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))))

22. 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

23. Formal Weaknesses • Mathematically intensive • Time consuming • Verification through proofs on idealize abstract machines • Drastic change in adoption

24. Weaknesses Cont’d • May require hiring of experts • Not suitable at this time for large complex systems • Costly retraining

25. 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

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. Package Diagram Example

32. Class Diagram Example

33. Use Case Diagram Example

34. State Diagram Example

35. Sequence Diagram Example

36. OOD Methods • UML • Booch • Coad and Yurdon • Fusion • Jacobson: Objectory and OOSE • LBMS SEOO • Rumbaugh OMT

37. 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

38. OOD Weaknesses • Commitment to formal training • High learning curve • Costly training • Not suitable for small projects

39. 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.

40. 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: • 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 • 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.

41. 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.

42. 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.

43. 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

44. Simple Example Of A Data Flow Diagram The Following Depicts an Online Ordering System:

45. UML Design Methodology

46. 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

47. UML is not: • A visual programming language • A tool or repository specification • A process • UML enables processes and designs

48. 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

49. 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 )

50. OMT Process Flow Diagram