1 / 20

Contents

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

davidsellis
Download Presentation

Contents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Software Design • Design activities • Architecture examples • Modularisation and Metrics • Classical Design Approaches

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

  4. Architecture Example: Pipes and filters

  5. Architecture Example: Layering

  6. Architecture Example: Repository

  7. Client-server architecture Film and picture library

  8. Design Principles • Abstraction • Encapsulation • Information Hiding • Structuring • Modularisation

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

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

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

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

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

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

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

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

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

  18. Structure Chart UpdateTransaction Account Info Transaction result transaction transaction transaction result Verify Transaction Make Transaction & Send Transaction Dispense Cashe Verify Card Cache amount Bank Info 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

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

  20. Traceability Matrix • Relates requirements to design artefacts • Shows dependencies • Supports change management • Useful for other traceability purposes

More Related