1 / 24

Software Engineering

Software Engineering. Design (Concepts and Principles) James Gain ( jgain@cs.uct.ac.za ) http://people.cs.uct.ac.za/~jgain/courses/SoftEng/. Objectives. Outline the concepts and principles underpinning design Abstraction and Refinement Modularity Cohesion and Coupling

geraldinek
Download Presentation

Software Engineering

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. Software Engineering Design (Concepts and Principles) James Gain (jgain@cs.uct.ac.za) http://people.cs.uct.ac.za/~jgain/courses/SoftEng/

  2. Objectives • Outline the concepts and principles underpinning design • Abstraction and Refinement • Modularity • Cohesion and Coupling • Information Hiding • Present some criteria for good design analysis design code code test test

  3. Overview of Design • What is it? A meaningful engineering representation of something that is to be built. • Who does it? Software engineers with a variety of skills, ranging from human ergonomics to computer architecture • Why is it important? A house would never be built without a blueprint. Why should software? Without design the system may fail with small changes, is difficult to test and cannot be assessed for quality • What is the work product? A design specification

  4. Designing Quality Software • Design is the stage where quality is instilled • Design is assessed by formal review or walkthrough • Characteristics of a good design: • Must implement explicit requirements and accommodate implicit requirements • Must be a readable and understandable guide for coding and testing • Should provide a complete picture of the software from an implementation perspective

  5. Generic Design Process • The design process involves: • Diversification (acquisition of alternatives) • Followed By • Convergence (elimination of all but one particular configuration) • All design methods have the following characteristics: • A mechanism for the translation of the analysis model into a design representation • A notation for representing functional components and their interfaces • Heuristics for refinement and partitioning • Guidelines for quality assessment

  6. Where Do We Begin? modelling Prototype Spec Design

  7. Design Principles • The Design process and spec should: • Avoid ‘tunnel vision’ • Be traceable back to analysis • Not reinvent the wheel • “Minimize the intellectual distance” between the problem and the solution • Exhibit uniformity and integration (look like the work of a single designer) • Accommodate change • Degrade gently • Be assessed for quality as it is being created, not after the fact • Not miss the forest (not focus too much on minutiae) • Recognize that design is not coding, coding is not design

  8. Abstraction and Refinement • Abstraction: • “Abstraction permits one to concentrate on a problem at some level of generalization without regard to irrelevant low level details..” • Software Engineering is a process of refining abstractions • Modern programming languages allow for abstraction, e.g. abstract data types • Types: data, procedural and control • Stepwise refinement • gradual top-down elaboration of detail • Abstraction and refinement are complementary. Abstraction suppresses low-level detail while refinement gradually reveals it.

  9. Data Abstraction door • A named collection of data that describes a data object manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

  10. Procedural Abstraction • A named sequence of instructions with a specific and limited function open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter

  11. Stepwise Refinement • Process of elaboration, proposed by Niklaus Wirth, that decomposes a high-level statement of function until low-level programming language statements are reached open walk to door; reach for knob; repeat until door opens turn knob clockwise; open door; if knob doesn't turn, then take key out; walk through; find correct key; close door. insert in lock; endif pull/push door move out of way; end repeat

  12. Modularity • Beware the Monolith • Software should be split into separately named and addressable components • A Module is “a lexically contiguous sequence of program statements, bounded by boundary elements, having an aggregate identifier” [Yourdon and Constantine 1979] • Procedures, functions and objects are all modules

  13. Benefits of Modularity • Easier to build; easier to change; easier to fix • “Modularity is the single attribute of software that allows a program to be intellectually manageable” • Don’t overdo it. Too many modules makes integration complicated • Sometimes the code must be monolithic (e.g. real-time and embedded software) but the design still shouldn’t be • Effective modular design is achieved by developing “single minded” (highly cohesive) modules with an “aversion” to excessive interaction (low coupling)

  14. Modularity: Trade-offs What is the "right" number of modules for a specific software design ? module development cost cost of software module integration cost optimal number number of modules of modules

  15. Modularity Support • A design method supports effective modularity if it evidences: • Decomposability - a systematic mechanism for decomposing the problem • Composability - able to reuse modules in a new system • Understandability - the module can be understood as a standalone unit • Continuity - minimizes change-induced side effects • Protection - minimizes error-induced side effects

  16. Cohesion • Def: the degree of interaction within a module • A measure of functional strength; strive for high cohesion • Terminology: • Action = the behaviour of a module (e.g. compute square root) • Logic = how the module performs its action (e.g. using Newton’s method) • Context = specific usage of the module (e.g. find square root of a double precision integer)

  17. Types of Cohesion “Scatter-brained” • Worst to Best • Coincidental Cohesion • Performs multiple unrelated actions • Can happen if an organization enforces rigid rules on module size - modules are hacked apart and glued together • Worse than no modularity at all • Logical Cohesion • Module tasks related logically • Example: an object that performs all input and output • Interface can be difficult to understand (e.g. printf) and code for several actions may be intertwined • Temporal Cohesion • Tasks executed within the same span of time • Example: initialization of data structures Low Moderate

  18. More Types of Cohesion • Procedural • Actions are related and must be executed in a certain order • Communication • Actions are performed in series and on the same data • Example: CalculateTrajectoryAndPrint • Damages Reusability • Functional or informational cohesion • Performs exactly one action OR • Performs a number of actions, with separate entry points, all performed on the same data structure • Equivalent to a well-designed abstract data type or object Moderate High “Single-minded”

  19. Coupling • Def: the degree of interaction between modules • A measure of relative interdependence; strive for low coupling since this reduces the “ripple effect” • Types of Coupling (Worst to Best): • Content Coupling • One module directly references the internals of another • Example: module p branches to a local label of module q • Almost any change in one requires a change in the other • Common Coupling • Both modules have access to the same global data area • Example: module p and q have read and write access to the same database element • Suffers from all the disadvantages of global variables High Coupling Moderate Coupling

  20. Types of Coupling • Control Coupling • Element of control is transferred between modules • Example: Module q not only passes information but also informs module p as to what action to take • These kinds of modules often have logical cohesion • Stamp Coupling • Whole data structures (records, arrays, object) transferred • BUT the called module only operates on part of the data structure • Security Risk: allows uncontrolled data access • Data Coupling • Every argument is either a simple type or a data structure • AND all elements are used by the called module • Maintenance is easier because regression faults less likely Moderate Coupling High Coupling

  21. Exercise: Classify the Couplings p 1 2 q 3 4 r s 5 6 t u p, t, u access the same database in update mode

  22. Information Hiding module • algorithm controlled • data structure interface • details of external interface • resource allocation policy clients "secret" a specific design decision

  23. Benefits of Information Hiding • A more accurate term would be “details hiding” • Supported by public and private specifiers in C++ • Benefits of Information Hiding: • Leads to low coupling • Reduces the likelihood of “side effects” • Limits the global impact of local design decisions • Emphasizes communication through controlled interfaces • Discourages the use of global data • Results in higher quality software

  24. Summary of Design Concepts • Abstraction: Enables a problem to be addressed at a high-level of generalization without worrying about low-level details. • Refinement: Process of gradual top-down elaboration of detail. • Abstraction andrefinement are complementary. • Modularity: Software subdivided into separately named and addressable components. • Coupling: The degree to which a module is connected to other modules in the system. • Cohesion: The degree to which a module performs one and only one function. • Information Hiding: Portions of the internal structure of a component are hidden and inaccessible from outside.

More Related