Text of Design - Architecture CS-300 Fall 2005 Supreeth Venkataraman
Design - Architecture CS-300 Fall 2005 Supreeth Venkataraman
CS-300 Fall 2005 Supreeth Venkataraman 2 Outline Introduction From Requirements to Design Iterative Enhancement Stepwise Refinement The Design and the Test Plan The Design Process Architectural Design
CS-300 Fall 2005 Supreeth Venkataraman 3 Introduction Design is the process of turning the requirements into a form ready to be implemented Technical expertise of developers come to the fore Primary creative activity in software development How are we going to solve the problem
CS-300 Fall 2005 Supreeth Venkataraman 4 Introduction Design IS problem solving The requirements phase helps analyze the problem The design phase is when a solution is developed for the problem Coding is merely the implementation of this solution. Designers must be well versed in what the problem is and also in how to solve that problem Designers begin by visualizing the architecture of the system Some requirements constrain design. If high speed searches are required, a linked list is not a viable data structure. Hash tables might be used instead
CS-300 Fall 2005 Supreeth Venkataraman 5 From Requirements to Design Design is written by engineers for engineers From requirements to design Become intimately familiar with each requirement Derive functions that must be provided for the system to work Decide upon data structures Identify algorithms needed
CS-300 Fall 2005 Supreeth Venkataraman 6 Identify Functionalities Common, needed functions This is the set of functions that will be implemented Any statement in the requirements that begins with the software will or the software must is very likely a function that needs to be implemented Or for that matter, use-cases lend themselves to function identification
CS-300 Fall 2005 Supreeth Venkataraman 7 Identify data structures Major data structures Examination of the requirements leads to data structure decisions Permanent data structures More thought and care Temporary data structures Sometimes data structure decisions can be forced because the system may get inputs from another system
CS-300 Fall 2005 Supreeth Venkataraman 8 Update test plan Adding to the test plan in design As design decisions are made, ideas about testing them come up Record these ideas immediately When modules are specified and designed, ideas about testing arise too These are unit tests (verify that the modules do what they are supposed to) In the design phase, system level functional tests can be refined We know how to implement the system. Embellish the initial test plan with this information. Eg: The SSN will be stored in a buffer occupying a maximum of 11 characters. Suitable test cases would be to Check with 11 and 13 character strings Hyphen positions etc
CS-300 Fall 2005 Supreeth Venkataraman 9 At a bare minimum, Decomposition into intellectually controllable subproblems Further decompose into modules Specify the modules (what does this module do?) Decide how to implement the modules Intellectual control Decomposes programming parts uniquely in the ideal case
CS-300 Fall 2005 Supreeth Venkataraman 10 Problems of Design All the problems associated with system requirements Requirements can change The urge to code first, and then design Knowing when to stop.
CS-300 Fall 2005 Supreeth Venkataraman 11 Iterative Enhancement Identify the core problem and work with it i.e what is the essence of the problem? Eg: What is the core of E-LIB? Design and implement the repository mechanism and build everything else around this First iteration will have a repository capable of storing user data, files etc. In the second iteration, we design and add update and retrieve capabilities, and integrate it with the repository And so on Iteratively enhance the functionalities
CS-300 Fall 2005 Supreeth Venkataraman 12 Iterative Enhancement Iterative enhancement is a good design technique, but problems exist If we get the core wrong (bad design) what happens? It might be after enhancing the core that problems come to light Might need to change both the enhancements as well as the core Mistakes will be more and more expensive to correct as we progress (sound familiar?)
CS-300 Fall 2005 Supreeth Venkataraman 13 Stepwise Refinement This is essentially decomposition into a hierarchy Start at the top where you have the entire system that has to be solved Break this system into a small group of subsystems that will solve the system Select each subsystem and further break down into components until each component is simple enough to be solved on its own. The leaves of the hierarchy are essentially modules.
CS-300 Fall 2005 Supreeth Venkataraman 14 Stepwise Refinement When the level of detail is fine enough, functional specifications must be written for each component These must specify the interfaces and communication data structures. Test cases must be recorded for each component Global data structure decisions can be made in the beginning itself What is the global data structure for E-LIB in concept?
CS-300 Fall 2005 Supreeth Venkataraman 15 The Design Process
CS-300 Fall 2005 Supreeth Venkataraman 16 Architectural Design The main purpose of this step is to transform the requirements into a high-level architecture. All requirements must be allocated to subsystems and modules. Defines an approach for implementation Serves to lay down the foundation for detailed design. Architectural design effectively is a high-level solution that is further refined in detailed design.
CS-300 Fall 2005 Supreeth Venkataraman 17 Architectural Design Architectural design involves Breaking down the system into subsystems Deciding on communication details Deciding an interface for each subsystem Deciding global data structures Handling exceptional situations Traceability is maintained to the requirements (traceability mappings/matrices) Architecture diagrams and the traceability mappings are the blueprints of the system
CS-300 Fall 2005 Supreeth Venkataraman 18 Decomposition Breaking down the system into components Identify all major subsystems Decompose the system into subsystems Identify further subsystems and decompose Decompose till all modules have been identified. Many, many ways of decomposing systems
CS-300 Fall 2005 Supreeth Venkataraman 19 Rules for decomposition Subsystems should be independent of each other Connectivity should be at a minimum between subsystems Clearly define the subsystems that handle errors.
CS-300 Fall 2005 Supreeth Venkataraman 20 Example A simple calculator We wish to design a simple calculator 1. The calculator must be capable of accepting user input 2. The calculator must be able to compute simple arithmetic. 3. The calculator must perform 3a. Addition 3b. Subtraction 3c. Multiplication 3d. Division 4. The calculator must validate all inputs before operation and will work on integers. 5. A simple error message will be displayed by the validating unit if the inputs are erroneous 6. The calculator must be able to display computed results to the user
CS-300 Fall 2005 Supreeth Venkataraman 22 Functional Decomposition What about functional decomposition? Hierarchical Much more presentable Abstract off communication details Intellectual control can be achieved We may not know when to stop Additional documentation for communication details (at least, more than the temporal version)
CS-300 Fall 2005 Supreeth Venkataraman 23 Temporal Decomposition Input AcceptValidate Process AddSubtractMultiplyDivide Output Display
CS-300 Fall 2005 Supreeth Venkataraman 24 Temporal Decomposition What is the advantage of using temporal decomposition? Communication details can be embedded in the architecture Easy to model architecture into pseudocode Disadvantage is that the architectural diagram could easily get messy. Hard to achieve intellectual control What lends itself directly to temporal decomposition? Sequences of use-cases
CS-300 Fall 2005 Supreeth Venkataraman 25 Alternatives The very fact that design can be approached in many ways suggests alternatives Usually architecture styles are chosen based on the type of application, but styles can be imposed on the process as well. It is wise to investigate many architectural alternatives and choose the best one. Might turn out to be more costly
CS-300 Fall 2005 Supreeth Venkataraman 26 Hey, what about traceability? The architecture diagram is an abstract view of the system Useful for visualization The traceability mappings are derived separately. What is the traceability mapping for the block labeled calculator ?
CS-300 Fall 2005 Supreeth Venkataraman 27 Traceability Matrices Traceability matrices map subsystems and modules back to the requirements docu