Design Document: Understanding Modules, Phases, and Coupling in Software Development, Study notes of Software Engineering

Download Design Document: Understanding Modules, Phases, and Coupling in Software Development and more Study notes Software Engineering in PDF only on Docsity! In software engineering, refers to the process of describing how requirements will be met. ○ Without actually doing it! The latter is implementation. ○ Design Reading: SEPA Chapter 8. Design Wednesday, October 07, 2009 11:45 AM Design Page 1 Docsity.com Top-level: identifies the main modules Refined: identifies submodules that comprise a module. Overall design: describes the pieces that can be completed independently. Detailed design: describes the inner details of each module. Phases of design Parts of design Wednesday, October 07, 2009 12:35 PM Design Page 2 Docsity.com American company creates design.○ Design is sent to outsourcing company in the third world where programmer labor is cheaper (or perhaps -- an external consultant in the US). ○ Outsourcing company returns programming product based upon design (and perhaps sells it in other countries!) ○ Unless design is complete, result will not be desirable. ○ Another reason design is important: outsourcing Outsourcing Wednesday, October 07, 2009 12:07 PM Design Page 5 Docsity.com precisely satisfies requirements as to what the product should do. leaves no doubt as to the expectations for the final product. enables parallel development of the chunks comprising the design. Employs (and creates) reusable software components. A really good design ... A really good design document... Wednesday, October 07, 2009 12:15 PM Design Page 6 Docsity.com increased communication during implementation. limits on parallel development. increased constraints on evolution of the product. in extreme cases, inability to adapt to changing needs. Coupling leads to Less to remember for programmers. Leveraging existing knowledge more effectively. Cohesion leads to Longer development time. Longer time to market. Work imbalances lead to Coupling is bad Wednesday, October 07, 2009 11:50 AM Design Page 7 Docsity.com The cost of software is proportional to the amount of communication needed to produce it.  Brooks' law: "Adding manpower to a late project makes it later."  Minimizing coupling minimizes necessary communications  Why is coupling such a problem? vendor: published whole source to operating system. • programmers: utilized completely weird entry points into the software (e.g., making subroutine calls into the middle of a subroutine). • result: effective code freeze of OS. • long-term result: death of Apple-II• A coupling horror story: Apple-II no source code. • "jump table" indicates usable system calls. • use these or else "you'll be sorry"• lesson learned: MacOS: MS-DOS BIOS: same story, different players! Coupling war stories Monday, September 17, 2012 2:41 PM Design Page 10 Docsity.com a unit of code that can be updated independently of other modules. ○ specific unit varies with programming language○ In linux C and C++, the module unit is a source code file. ○ In C# and java, the module boundary is a class. ○ What is a module? What is a module? Wednesday, October 07, 2009 11:52 AM Design Page 11 Docsity.com Unit of independent work is a file. Files can contain multiple classes and/or functions. Files are extremely difficult to co-edit at the same time. Projects are made up of individual files and libraries. In detail: modules in C++ In detail: modules in C++ Monday, September 17, 2012 11:50 AM Design Page 12 Docsity.com express coding problem as a tree or graph partition the graph so that the minimum number of edges are required between partitions. Make each partition a module (whose submodules are the nodes in the partition) Assign each module to a developer or team. Use some form of workload estimation to check fairness of assignment. First step in design: module decomposition Creating a module decomposition Wednesday, October 07, 2009 11:54 AM Design Page 15 Docsity.com modeling: description of the components of a design.  refinement: the process of adding detail to a depiction.  partitioning: the process of grouping cohesive functionality into modules.  assignment: assigning modules to people; forming programming teams.  workload estimation: determining how difficult each part will be to write.  The design process Jackson Systems Design (JSD) Data Structured Systems Design (DSSD) *  Dataflow Design (DFD) *  Object-oriented Design (OOD) * Many design methodologies Diagramming techniques Methods for transforming diagrams into decompositions.  Strengths and weaknesses.  Every design methodology has efficiency of modeling/depiction.  efficiency of refinement efficiency of compartmentalization and modularization  Which one to use? Design methodologies Thursday, November 10, 2005 12:25 PM Design Page 16 Docsity.com modularization match between design methodology and problem domain.  Design Page 17 Docsity.com In a module decomposition, often there are modules that do nothing more than to act as "glue" We call these "control modules". Control modules delegate communications to one team in a star configuration. points of the star aren't loaded down with communications. Purpose of control modules Control modules Wednesday, October 07, 2009 12:04 PM Design Page 20 Docsity.com Control modules are join points in a Jackson diagram: From whence comes control? Wednesday, October 07, 2009 12:22 PM Design Page 21 Docsity.com some commensurability between tasks we're partitioning a set of roughly equal things Every design methodology assumes that what if one process, not decomposed, is much more difficult than the others? What can go wrong? Scale and partial information Wednesday, October 07, 2009 4:09 PM Design Page 22 Docsity.com DFD example: A control program for an automated manufacturing facility has several parts whose combined task is to manufacture a part from a schematic. First, a raw schematic and a database of the properties of materials are used to create a better schematic that can be manufactured. Based upon the contents of this new schematic and a database of the capabilities of milling machines, one of three kinds of milling machines is selected to make the part. The schematic is then compiled into a control program for this kind of milling machine. Finally, the control program is used to operate the machine and make the part. Thursday, November 10, 2005 2:08 PM Design Page 25 Docsity.com Transform flow Thursday, November 10, 2005 2:08 PM Design Page 26 Docsity.com Transaction flow Thursday, November 10, 2005 2:08 PM Design Page 27 Docsity.com End of lecture 9/17/2012 Monday, September 17, 2012 5:32 PM Design Page 30 Docsity.com e.g. x = foo(y) means unbilled account ----> foo ----> billed account y----> foo---->x Transform flow: an item is moving "accounts receivable" ---> "accounts payable" "go" --> foo() ---> "done" Transaction flow Transform and Transaction flow Thursday, November 10, 2005 2:08 PM Design Page 31 Docsity.com model transform(data) and transaction(control) flow within a system  Identify transaction center = group of operations that control whole process. □ Treat this as top-level module□ Inputs and outputs of transaction center form submodules. □ Transaction flow:  Identify transform center = group of operations that control transformation process. □ Treat these as top-level module. □ Inputs and outputs form submodules. □ Transform flow: identify regions of data and/or transaction flow.  Dataflow design steps Dataflow design steps Thursday, November 10, 2005 2:08 PM Design Page 32 Docsity.com Combine CFD and DFD. Depict couplings via "Booch Diagrams" Blur distinction between data flow and control flow. Partition for maximum cohesion, minimal coupling. OOD: Object-oriented design Thursday, November 10, 2005 2:22 PM Design Page 35 Docsity.com objects in the real world their representations in a program There is a natural relationship between More conditions => subclass. More conditions => less instances. Objects in the real world obey conditions More attributes => subclass. More attributes => less instances. Objects in a program have attributes Inheritance is just another information domain Basic principle of inheritance: identifying subclass relationships maximizes code reuse. Object-oriented design (inheritance) Tuesday, October 13, 2009 2:37 PM Design Page 36 Docsity.com provides one way to diagram multiple information domains. data flow, control flow, containment, inheritance. Unified modeling language (UML) UML Tuesday, October 13, 2009 2:41 PM Design Page 37 Docsity.com transaction flow data flow inheritance (condition flow) Segregate the kinds of information flow transaction center transform center root class Seek one or more "centers" from which to decompose modules Build a basic module decomposition from the "centers" Refine that decomposition by creating submodules for the centers. General principles of module decomposition General principles of top-level design Tuesday, October 13, 2009 2:35 PM Design Page 40 Docsity.com After you have a module decomposition, you must assign it to programmers and teams. Basic issue: how "fair" is the assignment? For that matter, what is the difficulty of programming a specific module? A long story, and our next topic. But there's more to the story But there's more to the story Monday, September 17, 2012 3:04 PM Design Page 41 Docsity.com