310 likes | 319 Views
Contents. Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance. Requirements. Analysis. Specification. Require- ments. Planning. Design. Coding. Testing. Installation. Operation and Maintenance. Software Design.
E N D
Contents • Introduction • Requirements Engineering • Project Management • Software Design • Detailed Design and Coding • Quality Assurance bella@cs.umu.se
Requirements Analysis Specification Require- ments Planning Design Coding Testing Installation Operation and Maintenance Software Design • Design activities • Architecture examples • Modularisation and Metrics • Classical Design Approaches bella@cs.umu.se
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