1 / 21

Data and Actions

Data and Actions. Two aspects of a product Actions which operate on data Data on which actions operate The two basic ways of designing a product Action-oriented design Data-oriented design Third way Hybrid methods For example, object-oriented design. Design Activities.

jonah-duke
Télécharger la présentation

Data and Actions

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. Data and Actions • Two aspects of a product • Actions which operate on data • Data on which actions operate • The two basic ways of designing a product • Action-oriented design • Data-oriented design • Third way • Hybrid methods • For example, object-oriented design Lecture 8

  2. Design Activities • Architectural design • Detailed design • Design testing Lecture 8

  3. Architectural Design • Input: Specifications • Output: Modular decomposition • Abstraction Lecture 8

  4. Detailed Design • Each module is designed • Specific algorithms • Data structures Lecture 8

  5. Action-Oriented Design Methods • Data flow analysis • When to use it • With most specification methods (Structured Systems Analysis here) • Key point: Have detailed action information from DFD Lecture 8

  6. How to Perform Data Flow Analysis? • Data Flow Analysis (DFA) is a design technique for achieving modules with high cohesion • Using the points of highest abstraction of input and output, the product is decomposed into three modules: input module, transform module and output module • This procedure is continued stepwise until each module performs a single action i.e., the design consists of modules with high cohesion Lecture 8

  7. Data Flow Analysis • Product transforms input into output • Determine • “Point of highest abstraction of input” • “Point of highest abstract of output” Lecture 8

  8. Data Flow Analysis (contd) • Decompose into three modules • Repeat stepwise until each module has high cohesion • Minor modifications may be needed to lower coupling Lecture 8

  9. Data Flow Analysis (contd) • Example Design a product which takes as input a file name, and returns the number of words in that file (like UNIX wc ) Lecture 8

  10. Data Flow Analysis Example(contd) • First refinement • Refine modules of communicational cohesion Lecture 8

  11. Data Flow Analysis Example(contd) • Second refinement • All eight modules have functional cohesion Lecture 8

  12. Multiple Input and Output Streams • Point of highest abstraction for each stream • Continue until each module has high cohesion • Adjust coupling if needed Lecture 8

  13. Transaction Analysis • DFA poor for transaction processing products • Example: ATM (Automatic Teller Machine) Lecture 8

  14. Transaction Analysis (contd) • Poor design • Logical cohesion, control coupling • On the other hand it seems a waste of time and effort to have five very similar edit modules and five very similar update modules Lecture 8

  15. Corrected Design Using Transaction Analysis • Software reuse (Section 8.1) • A basic edit module should be designed, coded, documented and tested, then instantiated five times. Each version will be slightly different but the differences will be small enough to make this worthwhile. • Similarly a basic update module can be instantiated five times and slightly modified to cater to the five different update types. • The resulting design has high cohesion and low coupling Lecture 8

  16. Data-Oriented Design • Basic principle • The structure of a product must conform to the structure of its data • Three very similar methods • Warnier • Orr • Jackson • Data-oriented design • Has never been as popular as action-oriented design • With the rise of OOD, data-oriented design has largely fallen out of fashion Lecture 8

  17. Design of Real-Time Systems • Difficulties associated with real-time systems • Inputs come from real world • Software has no control over timing of inputs • Frequently implemented on distributed software • Communications implications • Timing issues • Problems of synchronization • Race conditions • Deadlock (deadly embrace) • Major difficulty in design of real-time systems • Determining whether the timing constraints are met by the design Lecture 8

  18. Real-Time Design Methods • Usually, extensions of nonreal-time methods to real-time • We have limited experience in use of any real-time methods • The state-of-the-art is not where we would like it to be Lecture 8

  19. Testing during the Design Phase • Design reviews • Design must correctly reflect specifications • Design itself must be correct • Transaction-driven inspections Lecture 8

  20. Metrics for the Design Phase • The five basic metrics • Cyclomatic complexity is problematic • Data complexity is ignored • Little use with object-oriented paradigm Lecture 8

  21. Challenges of the Design Phase • Design team should not do too much • Detailed design should not become code • Design team should not do too little • It is essential for the design team to produce a complete detailed design • Difficult to find ‘great designers’ Lecture 8

More Related