Contents Introduction Requirements Engineering Project Management Software Design

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

Software Design activities Architecture examples Modularisation and Metrics PVK-Ht 06 2

Design Activities Transform the logical model ( RE) into a physical model, in sufficient detail to permit its physical realization. Architectural design o o o 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 o Refine the (architectural) components o Choose specific data structures o Choose specific algorithms Define the logic of the implementation PVK-Ht 06 3

Architecture Example: Pipes and filters PVK-Ht 06 4

Architecture Example: Layering PVK-Ht 06 5

Architecture Example: Repository PVK-Ht 06 6

Client-server architecture Film and picture library PVK-Ht 06 7

Design Principles Abstraction Encapsulation Information Hiding Structuring Modularisation PVK-Ht 06 8

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-Ht 06 9

Measuring Module Quality Reliable and early data with significant impact on quality. Classical metrics: o LOC o Cyclomatic number (Mc. Cabe) o Control variable complexity (Mc. Clure) o Software science (Halstead) “Wrong” understanding of module Late applicability PVK-Ht 06 More useful: o o o Coupling Cohesion Fan-in/fan-out Graph-oriented metrics Weighted methods per class o Depth/width of inheritance trees o. . . 11

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

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

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 bad good Each element in a module should be a necessary and essential part of one and only task PVK-Ht 06 14

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

Depth Fan-in vs Fan-out M 1 M 2 M 5 M 10 M 3 M 6 M 12 M 11 M 17 M 4 M 8 M 13 M 18 M 9 M 15 M 14 M 16 M 19 Width M 9: Fan-in = 2, fan-out = 4 PVK-Ht 06 16

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

Object Oriented Analysis and Design Analysis Rectangle height width get. Area resize Design Rectangle {author = Joe} height: int width: int get. Area(): int resize (int, int) 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. 18

Object Model PVK-Ht 06 19

Object Oriented Design Metrics Weighted Methods Per Class (WMC) Depth of Inheritance Tree (DIT) Number of Children (NOC) Coupling between Object Classes (CBO) Response for a Class (RFC) Lack of Cohesion in Methods (LCOM) PVK-Ht 06 20

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