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

Software Design Design activities Architecture examples Modularisation and Metrics Classical Design Approaches Analysis Design Testing Coding Operation and Maintenance Installation Require- ments Requirements Specification Planning

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.

Architecture Example: Pipes and filters

Architecture Example: Layering

Architecture Example: Repository

Design Principles Abstraction Encapsulation Information Hiding Structuring Modularisation

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

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

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

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...

12 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

13 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

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

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

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

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

Structured Design Evolved from top-down design, modularity, and structured programming oStevens, Myers, Constantine (74) oYourdon, Constantine (79) oPage-Jones (80) Systematic development of a design (structure chart) from a DFD oTransform analysis oTransaction analysis

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 C     transaction

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”

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

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