1 / 68

A Survey of Modern Software Design Methodologies

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

omer
Download Presentation

A Survey of Modern Software Design Methodologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related