Design Activities Transform the logical model ( RE) into a physical model, in sufficient detail to permit its physical realization. • Architectural design • Identify the systems components • Structure the system components • Assign functionality to components • Assign data to components • Plan for future changes • Define the structure of the implementation • Detailed design • Refine the (architectural) components • Choose specific data structures • Choose specific algorithms • Define the logic of the implementation bella@cs.umu.se

Architecture Example: Pipes and filters bella@cs.umu.se

Architecture Example: Layering bella@cs.umu.se

Architecture Example: Repository bella@cs.umu.se

Architecture Example: Interpreter bella@cs.umu.se

Architecture Example: Process Control bella@cs.umu.se

Design Principles • Abstraction • Encapsulation • Information Hiding • Structuring • Modularisation bella@cs.umu.se

Characterisation of Modules • Logic entities which fulfil certain tasks • Simple entities, i.e. their tasks can be described clearly and briefly • Units containing data and/or operations • Provide resources usable by other modules • Their realisation is encapsulated • May use resources from other modules bella@cs.umu.se

Modules ... • ... are replaceable • ... are free of side-effects • ... can be tested separately • ... can be compiled separately • ... can be developed independently Modules are abstract/virtual machines bella@cs.umu.se

Advantages of Modular Systems • Easier to understand • Only few modules must be studied • Easier to develop and to test • Independence • More portable • System dependencies reside in a few dedicated modules • Easier to maintain • Changes can be traced to few modules • Easier to reuse • Clear dependencies bella@cs.umu.se

Classical metrics: LOC Cyclomatic number (McCabe) Control variable complexity (McClure) Software science (Halstead) “Wrong” understanding of module Late applicability More useful: Coupling Cohesion Fan-in/fan-out Graph-oriented metrics Weighted methods per class Depth/width of inheritance trees ... Measuring Module Quality Reliable and early data with significant impact on quality. bella@cs.umu.se

Coupling • Measures the degree of independence between different modules • Content coupling • Common coupling • (External coupling) • Control coupling • Stamp coupling • Data coupling • Each module should communicate with as few as possible other module • Communicating modules should exchange as few as possible data • All communication must be explicit bad good

How to Uncouple Modules • Data coupling • Exchange only necessary information • Do not pass data through several modules • Stamp coupling • Do not encapsulate unrelated data • Control coupling • Limit control information in interfaces • Common/External coupling • Pass data explicitly as parameters • Divide complex data into independent parts that can be exclusively used of different modules • Hide data • Content coupling USCH

Cohesion • Measures “relatedness” of the resources encapsulated in one module • Coincidental cohesion • Logical cohesion • Temporal cohesion • Procedural cohesion • Communicational cohesion • Sequential cohesion • Functional/informational cohesion • Each element in a module should be a necessary and essential part of one and only task bad good bella@cs.umu.se

Coupling / Cohesion Summary • The modules of a system should be highly cohesive and loosely coupled • Good modularisation bella@cs.umu.se

M18 M19 M17 M11 M12 M13 M10 M15 M16 M14 M5 M7 M8 M9 M6 M4 M1 M3 M2 Fan-in vs Fan-out Depth Width M9: Fan-in = 2, fan-out = 4 bella@cs.umu.se

Fan-in vs Fan-out Rules • Minimise structures with high fan-out • Strive for fan-in as depth increases bella@cs.umu.se

Structured Design • Evolved from top-down design, modularity, and structured programming • Stevens, Myers, Constantine (74) • Yourdon, Constantine (79) • Page-Jones (80) • Systematic development of a design (structure chart) from a DFD • Transform analysis • Transaction analysis bella@cs.umu.se

Structure Chart UpdateTransaction Account Info Transaction result transaction transaction transaction result Verify Transaction Make Transaction & Send Transaction Dispense Cashe Verify Card Bank Info Cache amount Authorization Info Transaction kind Amount Transaction result Get Transaction Info Display Result Output Cashe Verify Bank Verify Password bank Card #, Password Get Card Info Get Password bella@cs.umu.se

Main controller Structure Chart Transform flow controller Incoming flow controller Outgoing flow controller Transform Analysis • One or more inputs are transformed into one or more outputs (“and” semantics) Incoming flow Transform flow Outgoing flow DFD

Data Storage B Data Storage A Transformation Analysis Terminator A Input Function A Output Function A Terminator B K A C J D G Input Function B Transform Function A Output Function B F E Transform Function B H I B Input Function C Output Function C bella@cs.umu.se

Data Storage A Data Storage B Transformation Analysis Terminator A Input Function A Output Function A TerminatorB K A C J D G Afferent Input Function B Transform Function A Output Function B Efferent F E Transform Function B H I B Input Function C Output Function C bella@cs.umu.se

Transformation Analysis Boss J D H G E H&G D&E&F Input Function C Transform Center controller Output Function C Output Function B Input Function B D&E F C H F&G Input Function A Transform Function A Transform Function B Output Function A bella@cs.umu.se

Reception path controller Transaction Analysis • Dataflow splits into alternatives (“or” semantics) Transaction centre Reception path Alternative flows DFD Main controller Further analysis Structure Chart Dispatcher bella@cs.umu.se

Transaction centre Reception path controller Reception path Alternative flows Output Function A Input Function A Input Function B C Output Function B Output Function D Transaction Function C C C C DFD Output Function C D C Main controller c Further analysis Transaction Function C C C Output Function A Output Function B Input Function B Output Function C D Input Function A Output Function D bella@cs.umu.se

Structured Design Summary • Systematic approach to derive a design from the analysis results • DFDs as input • Transform- and transaction analysis • Factoring and refinement (rules exist) Good support for functional decomposition Systematic approach Incorporates metrics Uses design heuristics Tool support • No support for data abstraction Data spread over the whole system Only sequential systems Metrics and heuristics are mainly of syntactic nature No design “decisions” bella@cs.umu.se

Object Oriented Analysis and Design • Each entity in the system is an object. • A method or operation is an action that can be performed directly by the object or can happen to the object. • Encapsulation: the methods form a protective boundary around an object. • Class hierarchies of objects encourage inheritance. • Polymorphism: same method for different objects, each with different behaviour bella@cs.umu.se

OOAD Example Design • Analysis Rectangle height width getArea resize Rectangle {author = Joe} height: int width: int getArea(): int resize (int,int) bella@cs.umu.se

Traceability Matrix • Relates requirements to design artefacts • Shows dependencies • Supports change management • Useful for other traceability purposes bella@cs.umu.se

Contents

Contents

Presentation Transcript

Contents

Contents

Contents

Contents

Contents

Contents

Contents

CONTENTS

Contents

Contents