Presentation on theme: "Design Concepts and Principles"— Presentation transcript:
1 Design Concepts and Principles Lecture 6Design Concepts and Principles
2 Analysis to Design PSPEC ERD DFD STD CSPEC THE DESIGN MODEL DataObjectDescriptionPSPECcomponent(procedural)designERDDFDDataDictionaryinterfacedesignarchitecturaldesignSTDdatadesignCSPECTHE DESIGN MODELTHE ANALYSIS MODEL
4 Design Principles [Dav95] The design process should not suffer from ‘tunnel vision.’The design should be traceable to the analysis model.The design should not reinvent the wheel.The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world.The design should exhibit uniformity and integration.
5 Design Principles [Dav95] The design should be structured to accommodate change.The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.Design is not coding, coding is not design.The design should be assessed for quality as it is being created, not after the fact.The design should be reviewed to minimize conceptual (semantic) errors.
6 Fundamental Concepts abstraction—data, procedure, control refinement—elaboration of detail for all abstractionsmodularity—compartmentalization of data and functionarchitecture—overall structure of the softwareStructural propertiesExtra-structural propertiesStyles and patternsprocedure—the algorithms that achieve functionhiding—controlled interfaces
7 Data Abstraction door manufacturer model number type swing direction insertslightstypenumberweightopening mechanismimplemented as a data structure
8 Procedural Abstraction opendetails of enteralgorithmimplemented with a "knowledge" of theobject that is associated with enter
9 Stepwise Refinement open walk to door; reach for knob; open door; repeat until door opensturn knob clockwise;walk through;if knob doesn't turn, thenclose door.take key out;find correct key;insert in lock;endifpull/push doormove out of way;end repeat
10 Modularity: Trade-offs What is the "right" number of modulesfor a specific software design?module development costcost ofsoftwaremoduleintegrationcostoptimal numbernumber of modulesof modules
11 Functional Independence COHESION - the degree to which a module performs one and only one function.COUPLING - the degree to which a module is “connected” to other modules in the system.HIGHIndependentCommunication, ProceduralCoincidentally, logically, temporalCompiler/OSContentExternal, CommonControlData, StampLOW
12 Architecture“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]Structural properties: defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another.Extra-functional properties: address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.Families of related systems: draw upon repeatable patterns that are commonly encountered in the design of families of similar systems.
13 Information Hiding module clients • algorithm controlled interface• data structure• details of external interface• resource allocation policyclients"secret"a specific design decision
15 Why Architecture?The architecture is not the operational software. Rather, it is a representation that enables a software engineer to:analyze the effectiveness of the design in meeting its stated requirements,consider architectural alternatives at a stage when making design changes is still relatively easy, andreduce the risks associated with the construction of the software.
16 Data Design refine data objects and develop a set of data abstractions implement data object attributes as one or more data structuresreview data structures to ensure that appropriate relationships have been establishedsimplify data structures as required
17 Component Level Data Design Apply systematic analysis principles to function and behavior to data.Identify all data structures and the operations to be performed on themEstablish a data dictionary.Defer low level data design decisions.Reveal data structure representation only to those modules that must make direct use of its content.Develop a library of useful data structures and the operations that may be applied to themAbstract data types should be supported.
18 Architectural Styles Data-centered architectures Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.Data-centered architecturesData flow architecturesCall and return architecturesObject-oriented architecturesLayered architectures
23 Analyzing Architectural Design Collect scenarios.Elicit requirements, constraints, and environment description.Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: module, process and data flow viewsEvaluate quality attributes by considered each attribute in isolation.Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style.Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.
24 An Architectural Design Method customer requirements"four bedrooms, three baths,lots of glass ..."architectural design
26 Partitioning the Architecture “horizontal” and “vertical” partitioning are required
27 Horizontal Partitioning define separate branches of the module hierarchy for each major functionuse control modules to coordinate communication between functionsfunction 1function 3function 2
28 Vertical Partitioning: Factoring design so that decision making and work are stratifieddecision making modules should reside at the top of the architectureworkersdecision-makers
29 Why Partitioned Architecture? results in software that is easier to testleads to software that is easier to maintainresults in propagation of fewer side effectsresults in software that is easier to extend
30 Structured Designobjective: to derive a program architecture that is partitionedapproach:the DFD is mapped into a program architecturethe PSPEC and STD are used to indicate the content of each modulenotation: structure chart
32 General Mapping Approach isolate incoming and outgoing flowboundaries; for transaction flows, isolatethe transaction centerworking from the boundary outward, mapDFD transforms into corresponding modulesadd control modules as requiredrefine the resultant program structureusing effective modularity concepts
38 Transaction Example fixture fixture setting servos commands operator processfixture settingreportrobot controlfixtureservosdisplayscreenrobotcontrolsoftwarein reality, otherwould also be shownassemblyrecord
39 Refining the Analysis Model 1.write an English language processing narrativefor the level 01 flow model2.apply noun/verb parse to isolate processes, dataitems, store and entities3.develop level 02 and 03 flow models4.create corresponding data dictionary entries5.refine flow models as appropriate... now, we're ready to begin design!
40 Deriving Level 1narrative for " process operator commands“ after noun-verb parseProcess operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analysed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system.
41 Level 1 Data Flow Diagram operatorcommandsError msgstatusfixtureservosreadoperatorcommandsfixture settingvalid commandanalysefixturefixturestatusdeterminecommandselect reporttypereportgeneratecontroldisplayreportrobotscreensendcontrolassemblyvaluerecordrobotcontrolsystemrobot control
43 Transaction Mapping Principles isolate the incoming flow pathdefine each of the action paths by looking forthe "spokes of the wheel"assess the flow on each action pathdefine the dispatch and control structuremap each action path flow individually
45 Isolate Flow Paths error msg produce error msg format read commandproduceerrormsgvalidatedeterminetypefixturestatussettingformatrecordcalculateoutputvaluesreportassemblyinvalid commanderror msgrobot controlsendcontrolvaluestart /stopcombinedraw settingfixture setting
46 Map the Flow Model process operator commands command input controller readvalidateproduceerrormessagedeterminetypefixturestatusreportgenerationsendcontrolvalueeach of the action paths must be expanded further
48 Interface Design Inter-modular interface design driven by data flow between modulesExternal interface designdriven by interface between applicationsdriven by interface between software and non-human producers and/or consumers of informationHuman-computer interface designdriven by the communication between human and machine
50 Interface DesignEasy to learn?Easy to use?Easy to understand?
51 Interface Design Typical Design Errors lack of consistency too much memorizationno guidance / helpno context sensitivitypoor responseunfriendly
52 Golden Rules Place the user in control Reduce the user’s memory load Make the interface consistent
53 Place the User in Control Define interaction modes in a way that does not force a user into unnecessary or undesired actions.Provide for flexible interaction.Allow user interaction to be interruptible and undoable.Streamline interaction as skill levels advance and allow the interaction to be customized.Hide technical internals from the casual user.Design for direct interaction with objects that appear on the screen.
54 Reduce the User’s Memory Load Reduce demand on short-term memory.Establish meaningful defaults.Define shortcuts that are intuitive.The visual layout of the interface should be based on a real world metaphor.Disclose information in a progressive fashion.
55 Make the Interface Consistent Allow the user to put the current task into a meaningful context.Maintain consistency across a family of applications.If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.
56 User Interface Design Models System perception — the user’s mental image of what the interface isUser model — a profile of all end users of the systemSystem image — the “presentation” of the system projected by the complete interfaceDesign model — data, architectural, interface and procedural representations of the software
58 Task Analysis and Modeling All human tasks required to do the job (of the interface) are defined and classifiedObjects (to be manipulated) and actions (functions applied to objects) are identified for each taskTasks are refined iteratively until the job is completely defined
59 Interface Design Activities Establish the goals and intentions for each task.Map each goal/intention to a sequence of specific actions.Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level.Indicate the state of the system, i.e., What does the interface look like at the time that a user scenario is performed?Define control mechanisms, i.e., The objects and actions available to the user to alter the system state.Show how control mechanisms affect the state of the system.Indicate how the user interprets the state of the system from information provided through the interface.