CH-13

Design Concepts And PrinciplesSoftware Design -- An iterative process transforming requirements into a blueprint for constructing the software.

*December 22, 1997Chapter 13 -- R. A. Volz --Assistance - Sanjay Joshi*

TopicsThe Design ProcessDesign PrinciplesDesign Concepts-Abstraction & RefinementSoftware ArchitectureProgram PartitioningCoupling and Cohesion


Relation of Analysis to Design


The Design ModelData DesignTransforms information domain model into data structures required to implement softwareArchitectural DesignDefines relationship among the major structural elements of a program


The Design Model

Interface DesignDescribes how the software communicates with itself, to systems that interact with it and with humans.Procedural DesignTransforms structural elements of the architecture into a procedural description of software construction


The Design ProcessMc Glaughlins suggestions for good design:Design must enable all requirements of the analysis model and implicit needs of the customer to be metDesign must be readable and an understandable guide for coders, testers and maintainersThe design should address the data, functional and behavioral domains of implementation


Design GuidelinesA design should exhibit a hierarchical organizationA design should be modularA design should contain both data and procedural abstractionsModules should exhibit independent functional characteristicsInterfaces should reduce complexityA design should be obtained from a repeatable method, driven by analysis


Design PrinciplesDesign Process: Iterative steps that enable description of all aspects of the softwareDesign principles:The design process should consider various approaches based on requirementsThe design should be traceable to the requirements analysis modelThe design should not reinvent the wheel -- Reuse!Design should mimic the structure in the problem domain


Design PrinciplesDesign should be uniform and exhibit integrityDesign should accommodate changeDesign should minimize coupling between modulesDesign should be structured to degrade gentlyIt should terminate gracefully and not bomb suddenlyDesign and coding are not interchangeableDesign should have quality assessment during creation, not afterwardsThis is to reduce development timeDesign should be reviewed to minimize on conceptual errors -- Formal design reviews!There is a tendency to focus on the wrong thingsAll conceptual elements have to be addressed


ModuleType definitionsSubprogram profilesConstantsSpecificationEncapsulated dataSubprogram definitions

Body


Proc Main;x: tp;ax: a;p(x);ax = F;...type tp is ..type a is access tp;Proc P(z: tp);func F ret a;Y: tp;Proc P isend P;func F is end F;


type shuttle is record x: float; -- wrt to coord sys y: float; -- wrt to coord sys z: float: -- wrt to coord sys roll: float; pitch: float; yaw: float;end record;function get return shuttle;Module A specifications: A.shuttle;x_coord: float;s := A.get;display(s);x_coord := s.x;...Module B bodyBody A


type shuttle is record x: float; -- latitude y: float; -- longitude z: float: -- elevation roll: float; pitch: float; yaw: float;end record;function get return shuttle;Module A specifications: A.shuttle;x_coord: float;s := A.get;display(s);x_coord := s.x;...Module B bodyBody A


type shuttle is private;function get return shuttle;function get_lat(s) return float;function get_x(s) return float;function get_long(s) return float;procedure display(s:shuttle);privatetype shuttle is record x,y,z: float; roll, pitch,yaw: float;end record;Module A specifications: A.shuttle;x_coord: float;s := A.get;A.display(s);x_coord := A.get_x(s);...Module B body


Design Concepts-AbstractionWasserman: Abstraction permits one to concentrate on a problem at some level of abstraction without regard to low level detailsData AbstractionThis is a named collection of data that describes a data objectProcedural AbstractionInstructions are given in a named sequenceEach instruction has a limited functionControl AbstractionA program control mechanism without specifying internal details, e.g., semaphore, rendezvous


RefinementRefinement is a process where one or several instructions of the program are decomposed into more detailed instructions.Stepwise refinement is a top down strategyBasic architecture is developed iterativelyStep wise hierarchy is developedForces a designer to develop low level details as the design progresses Design decisions at each stage


ModularityIn this concept, software is divided into separately named and addressable components called modulesFollows divide and conquer concept, a complex problem is broken down into several manageable piecesLet p1 and p2 be two program parts, and E the effort to solve the problem. Then,E(p1+p2) > E(p1)+E(p2), often >>A need to divide software into optimal sized modules




Modularity & Software Cost


ModularityObjectives of modularity in a design methodModular DecomposabilityProvide a systematic mechanism to decompose a problem into sub problemsModular ComposabilityEnable reuse of existing componentsModular UnderstandabilityCan the module be understood as a stand alone unit? Then it is easier to understand and change.


ModularityModular ContinuityIf small changes to the system requirements result in changes to individual modules, rather than system-wide changes, the impact of the side effects is reduced (note implications in previous example)

Modular ProtectionIf there is an error in the module, then those errors are localized and not spread to other modules


Software ArchitectureDesired properties of an architectural designStructural PropertiesThis defines the components of a system and the manner in which these interact with one another.Extra Functional PropertiesThis addresses how the design architecture achieves requirements for performance, reliability and securityFamilies of Related SystemsThe ability to reuse architectural building blocks


Structural Diagrams


Kinds of ModelsTerminologyStructural models Organized collection of componentsFramework modelsAbstract to repeatable architectural patternsDynamic modelsBehavioral (dynamic) aspects of structureProcess modelsBusiness or technical process to be builtFunctional modelsFunctional hierarchy of the system


Program Structure PartitioningHorizontal PartitioningEasier to testEasier to maintain (questionable)Propagation of fewer side effects (questionable)Easier to add new featuresF1 (Ex: Input) F2 (Process) F3(Output)


Program Structure PartitioningVertical PartitioningControl and work modules are distributed top downTop level modules perform control functionsLower modules perform computationsLess susceptible to side effectsAlso very maintainable


Information HidingModules are characterized by design decisions that are hidden from othersModules communicate only through well defined interfacesEnforce access constraints to local entities and those visible through interfacesVery important for accommodating change and reducing coupling




Functional IndependenceCritical in dividing system into independently implementable partsMeasured by two qualitative criteriaCohesionRelative functional strength of a moduleCouplingRelative interdependence among modules


Modular Design -- CohesionA cohesive module performs a single taskDifferent levels of cohesionCoincidental, logical, temporal, procedural, communications, sequential, functional


Modular Design -- CohesionCoincidental CohesionOccurs when modules are grouped together for no reason at allLogical CohesionModules have a logical cohesion, but no actual connection in data and controlTemporal CohesionModules are bound together because they must be used at approximately the same time


Modular Design -- CohesionCommunication CohesionModules grouped together because they access the same Input/Output devicesSequential CohesionElements in a module are linked together by the necessity to be activated in a particular orderFunctional CohesionAll elements of a module relate to the performance of a single function


Modular Design -- CouplingCoupling describes the interconnection among modulesData couplingOccurs when one module passes local data values to another as parametersStamp couplingOccurs when part of a data structure is passed to another module as a parameter


Modular Design -- CouplingControl CouplingOccurs when control parameters are passed between modules Common CouplingOccurs when multiple modules access common data areas such as Fortran Common or C externContent CouplingOccurs when a module data in another moduleSubclass CouplingThe coupling that a class has with its parent class


Examples of Coupling


Design HeuristicsEvaluate 1st iteration to reduce coupling & improve cohesionMinimize structures with high fan-out; strive for depthKeep scope of effect of a module within scope of control of that moduleEvaluate interfaces to reduce complexity and improve consistency


Design HeuristicsDefine modules with predictable function & avoid being overly restrictiveAvoid static memory between calls where possibleStrive for controlled entry -- no jumps into the middle of thingsPackage software based on design constraints and portability requirements


Program Structure


Documentation


SummaryDesign is the core of software engineeringDesign concepts provide the basic criteria for design qualityModularity, abstraction and refinement enable design simplificationA design document is an essential part of the process

Note the importance of the performance aspect of things. State example of Ada compilers and time.Choice of language helps a lot here.Coupling is the relationship between two modules

Documents

CH-13