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 21 Functional Decomposition Calculator InputProcessOutput AcceptValidateAddSubtractMultiplyDivideDisplay

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 document. Traceability matrices are vital to keep the design orderly. 3a Addition They can be organized by either requirements or subsystems “Assign each requirement to as few subsystems as possible. Difficult requirements can be decomposed into multiple requirements that can then be assigned to only a few subsystems.”

CS-300 Fall 2005 Supreeth Venkataraman 28 Communications We need to decide how the subsystems will communicate The medium of communications is through unique interfaces for each subsystem. How do we determine which subsystems need to communicate? The traceability matrix comes in very handy here.

CS-300 Fall 2005 Supreeth Venkataraman 29 Traceability matrix for calculator (High-Level) [1]Input [2]Input, Process [3]Input, Process [3a]Input, add … [4] Input [5]Input, Output [6]Output

CS-300 Fall 2005 Supreeth Venkataraman 30 Questions Is there any data the process subsystem needs from the input subsystem? Is there any data the output subsystem needs from the input subsystem? Is there any data the output subsystem needs from the process subsystem? Is there any data the input subsystem needs from the process and output subsystems? Is there any data the process subsystem needs from the output subsystem?

CS-300 Fall 2005 Supreeth Venkataraman 31 Which subsystems must communicate? Input – process ? Input – output ? Process – input ? Process – output ? Output – input ? Output – process ?

CS-300 Fall 2005 Supreeth Venkataraman 32 Hmmm … there are more subsystems The input subsystem is made up of Accept Validate The process subsystem is made up of Add Subtract Multiply Divide The output subsystem is made up of Display We need to know which part of the subsystem to call!!

CS-300 Fall 2005 Supreeth Venkataraman 33 Traceability Matrix (Detailed) [1]Accept, Validate [2]Accept, Validate, add/sub/mul/div [3]Accept, Validate, add/sub/mul/div [3a] Accept, Validate, Addition [3b]Accept, Validate, Subtraction [3c]Accept, Validate, Multiply [3d]Accept, Validate, Divide [4]Accept, Validate [5]Accept, Validate, Display [6]Accept, Validate, add/sub/mul/div, display

CS-300 Fall 2005 Supreeth Venkataraman 34 How do we get the subsystems talking to each other? Specify an interface for each module and subsystem What data does the “add” module require, and from which module? What type of data is needed? Specify the interface The interface to the “add” module must have the capability to accept two integers. What other questions do we need to ask? What about the environment?

CS-300 Fall 2005 Supreeth Venkataraman 35 Interfaces External Interfaces Interfaces to user Interfaces to operating system Interfaces to hardware etc. Internal Interfaces Interfaces to subsystems that are part of the system Eg: The “borrow” subsystem calls the repository

CS-300 Fall 2005 Supreeth Venkataraman 36 Environment It is vital that the environment in which the product will operate be identified early and should be considered during design. Software to read temperature sensors Assume that lowest temperature that can be read in Florida is - 10 F, and is hardcoded in the design. Then somehow, the software is hooked up with sensors in Antarctica. No matter how low the temperature is, the software might happily display -10F What if the temperature outside was -150 F, and a rescue team was to be dispatched if the temperature fell below -100 F? Never assume the environment. What happened to the “Galloping Gertie?”

CS-300 Fall 2005 Supreeth Venkataraman 37 Cohesion and Coupling Coupling and cohesion describe the interaction between subsystems and within subsystems. They give us a way to classify modules and subsystems based on their interactions. In the ideal situation we want to achieve high cohesion and low coupling. Let us now see what these terms mean exactly.

CS-300 Fall 2005 Supreeth Venkataraman 38 Cohesion Cohesion is a measure of the amount of interactions within a module. Does every component within the module work towards the achievement of a common goal? Ideally every component within a module must work towards a common goal What does this mean exactly?

CS-300 Fall 2005 Supreeth Venkataraman 39 Cohesion Let us consider the “Accept” module What is the function of the accept module? Accept integers from the user Accept operators from the user We must strive to ensure that all components within the “accept” module work only towards this purpose. If we can achieve this, then we have high cohesion

CS-300 Fall 2005 Supreeth Venkataraman 40 Cohesion Modules with high cohesion lend themselves naturally to the concept of re-use. All we need to know is the interface of the module. What happens if the module’s components work towards different goals? (multiple goals within a module) High cohesion implies simpler interfaces.

CS-300 Fall 2005 Supreeth Venkataraman 41 Coupling Coupling is a measure of interactions amongst modules. Ideally we would like to minimize the amount of interactions between modules. More interactions mean that modules are very much dependent upon each other. Means more complicated interfaces

CS-300 Fall 2005 Supreeth Venkataraman 42 Coupling More interactions also means more communication overheads. Imagine a situation where every module calls every other module. What if something inside one module has to be changed? Does it initiate a change within all other modules? Most likely given the amount of dependency

CS-300 Fall 2005 Supreeth Venkataraman 43 Cohesion and Coupling

CS-300 Fall 2005 Supreeth Venkataraman 44 Cohesion and Coupling

CS-300 Fall 2005 Supreeth Venkataraman 45 Cohesion and Coupling High cohesion and weak coupling help build modules that can be Designed independently Coded independently Tested independently Integrated with few integration errors Re-used All we need to know about is the interface to the modules.

CS-300 Fall 2005 Supreeth Venkataraman 46 Cohesion and Coupling Cohesion and coupling are essentially opposites High cohesion automatically implies low coupling and vice versa How to achieve low coupling? Minimize shared common data between modules Minimize the number of parameters Ensure that change in one module does not lead to cascading changes in the modules it communicates with.

CS-300 Fall 2005 Supreeth Venkataraman 47 Make global data structure decisions During architectural design, it is common to make decisions about global data structures Global data structures usually define the back- end of applications These data structures are usually permanent, and retain state information even after the program has terminated. So what global data structure decisions would you make for E-LIB?

CS-300 Fall 2005 Supreeth Venkataraman 48 Make decisions about algorithms This entire process we’ve been through is itself a big algorithm on its own We might need to identify specialized algorithms to be used by certain modules. For example, module A might sort a set of integers, and the decision on what sorting algorithm needs to be used has to be made in architectural design. Decisions about algorithms for modules are a task for detailed design

CS-300 Fall 2005 Supreeth Venkataraman 49 Detailed Design – A sneak peek Detailed design involves Specifying each module with a functional description Making decisions about variables, data types Representing each module in a form that can be easily implemented. We will see detailed design in great detail in the next class