PVK-Ht051 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance

PVK-Ht052 Software Design Design activities Architecture examples Modularisation and Metrics Classical Design Approaches

PVK-Ht053 Design Activities Architectural design oIdentify the systems components oStructure the system components oAssign functionality to components oAssign data to components oPlan for future changes Define the structure of the implementation Detailed design oRefine the (architectural) components oChoose specific data structures oChoose specific algorithms Define the logic of the implementation Transform the logical model (  RE) into a physical model, in sufficient detail to permit its physical realization.

PVK-Ht054 Architecture Example: Pipes and filters

PVK-Ht055 Architecture Example: Layering

PVK-Ht056 Architecture Example: Repository

PVK-Ht057 Client-server architecture Film and picture library

PVK-Ht058 Design Principles Abstraction Encapsulation Information Hiding Structuring Modularisation

PVK-Ht059 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

PVK-Ht0510 Advantages of Modular Systems Easier to understand oOnly few modules must be studied Easier to develop and to test oIndependence More portable oSystem dependencies reside in a few dedicated modules Easier to maintain oChanges can be traced to few modules Easier to reuse oClear dependencies

PVK-Ht0511 Measuring Module Quality Classical metrics: oLOC oCyclomatic number (McCabe) oControl variable complexity (McClure) oSoftware science (Halstead) “Wrong” understanding of module Late applicability Reliable and early data with significant impact on quality. More useful: oCoupling oCohesion oFan-in/fan-out oGraph-oriented metrics oWeighted methods per class oDepth/width of inheritance trees o...

PVK-Ht0512 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

PVK-Ht0513 How to Uncouple Modules Data coupling oExchange only necessary information oDo not pass data through several modules Stamp coupling oDo not encapsulate unrelated data Control coupling oLimit control information in interfaces Common/External coupling oPass data explicitly as parameters oDivide complex data into independent parts that can be exclusively used of different modules oHide data Content coupling USCH

PVK-Ht0514 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

PVK-Ht0515 Coupling / Cohesion Summary The modules of a system should be highly cohesive and loosely coupled Good modularisation

PVK-Ht0516 Fan-in vs Fan-out M1M1 M3M3 M 16 M 15 M 14 M 13 M 12 M 11 M 10 M 18 M 17 M 19 M4M4 M2M2 M9M9 M8M8 M7M7 M6M6 M5M5 M 9 : Fan-in = 2, fan-out = 4 Depth Width

PVK-Ht0517 Fan-in vs Fan-out Rules Minimise structures with high fan-out Strive for fan-in as depth increases

PVK-Ht0518 Structured Design Systematic development of a design (structure chart) from a DFD 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”

PVK-Ht0519 Structure Chart Update Transaction Verify Card Verify Bank Verify Password Get Card Info Get Password Make Transaction & Send Transaction Dispense Cashe Display Result Output Cashe transaction result bankCard #, Password Authorization Info Bank Info Verify Transaction Get Transaction Info Transaction kind Amount Account Info Transaction result Cache amount transaction

PVK-Ht0520 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. Rectangle {author = Joe} height: int width: int getArea(): int resize (int,int) Rectangle height width getArea resize Analysis Design

PVK-Ht0521 Traceability Matrix Relates requirements to design artefacts o Shows dependencies o Supports change management o Useful for other traceability purposes Module 1 Module 2 Module 3 Module 4 Module… Req 1 X X X Req 2 X X X Req 3 X X Req.. X X X