2. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes Understand the principles of good design Ability to assess a software design Understand the process of going from OOA to OOD

3. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 2 Design strategies  Functional design o The system is designed from a functional viewpoint. Start with high level view and refine into more detail e.g. Structured Design, SSADM, step-wise refinement, Jackson Structured Programming....  Object-oriented design o The system is viewed as a collection of interacting objects. Objects may be instances of an object class and communicate by exchanging methods. e.g. UML  Which One?  Select the most appropriate approach for whatever sub-system is being designed

4. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 3 Design quality  What is a ‘good’ design? o A 'good' design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc.?  We will concern ourselves mainly with maintainability and reusability  A design should... o be modular - i.e. software partitioned into components that perform certain functions o have contain distinct and separable representation of data and procedure o should lead to modules that have independent functions o should be derived using a repeatable method driven by the requirements specification

5. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 4 Abstraction  “The psychological notion of “abstraction” permits one to concentrate on a problem at some level of generalisation without regard to irrelevant low level details” e.g. Develop software that will perform 2-D drafting (CAD) Abstraction 1 o Software will include a computer graphics interface which will enable the draftsperson to see a drawing and to communicate with it via a mouse. All line and curve drawing, geometric computations.... will be performed by the CAD software. Drawings will be stored in a drawings file. Abstraction 2 CAD software tasks: user interaction task; 2-D drawing task; graphics display task; drawing file management task; end. = Procedural Abstraction

6. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 5 Abstraction cont.  DATA ABSTRACTION = defining a data object at different levels  e.g Drawing Abstraction 1 - drawing Abstraction 2: TYPE drawing IS STRUCTURE DEFINED number IS STRING LENGTH(12) geometry DEFINED notes IS STRING LENGTH(256) BOM defined END drawing TYPE; This is an ADT Another data abstraction = Data Abstraction

7. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 6 Modularity Moral: Divide and Conquer cost per module Cost of Effort No. modules Interface cost Total cost  Software is divided into separately named, addressable components called modules  Complexity of a program depends on modularity  Let C(x) = a measure of complexity and p1 and p2 be problems, E(x) a measure of Effort to solve o If C(p1) > C(p2) then it follows by experience o E(p1) > E(p2) o Also, C(p1+p2) > C(p1) + C(p2) o Therefore E(p1+p2) >E(p1) + E(p2  How small should modules be?

8. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 7 More fundamental concepts  Data Structure o a representation of a logical relationship among individual elements of data  Software Procedure o processing details of a module  Information Hiding o “Modules should be characterised by design decisions that hides from all others” o i.e. Modules should be designed so that no other modules can access its data or procedures unless they need to. o Why? - When it comes to adapting a module or maintaining it - there is less possibility for inadvertent errors o Functional independence - abstraction + modularity lead to modules that are “single-minded”  Adaptability  Understandability

9. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 8 Cohesion  Interaction within a module i.e. a measure of how well a component 'fits together'  High cohesion - A component should implement a single logical entity or function  Cohesion is a desirable design component attribute as when a change has to be made, it is localised in a single component  Why? oEase of Maintenance oPossibility of Reuse oNaming oComplexity of Interface

10. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 9  A measure of the strength of the inter-connections between system components  Loose coupling means component changes are unlikely to affect other components  Shared variables or control information exchange lead to tight coupling  Loose coupling can be achieved by state decentralisation (as in objects) and component communication via parameters or message passing 28 Coupling

11. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 10 Levels of Coupling  Good Practice o“Data Coupling” o Data is passed from one module to another using arguments  Bad Practice oStamp Coupling  More data than necessary is passed via arguments e.g. pass the whole record instead of just the field being changed oControl Coupling  A flag is passed from one module to another affecting the functionality of the second module – modules are not independent and so reuse is limited – violates principle of ‘information hiding’ (see later) – calling module must ‘know’ how the called module works

12. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 11 Levels of Coupling  Bad Practice cont. oCommon Coupling » Two modules access the same global data. E.g. Data division in COBOL – resulting code is difficult to read – side affects e.g has another module changed a variable? – programs are costly to maintain as a change to a global variable means the whole program has to be searched to find its affect – reusability is poor – security problems. A module has access to more data than it needs

13. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 12 Levels of Coupling  Bad Practice cont. oContent Coupling » One module directly affects the working of another. Calling module can modify the called module or refer to an internally defined data element. e.g. GOTO. » makes maintenance very difficult as program will be difficult to understand.  never allow this type of coupling! B A C DE Global data area Content Coupling Common Coupling

14. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 13 OOA to OOD  OOD = Designing systems using self-contained object classes  Advantages: o Easier maintenance. Objects may be understood as stand-alone entities o Objects are appropriate reusable components o For some systems, there may be an obvious mapping from real world entities to system objects  Object-oriented analysis, design and programming are related o OOA - developing an object model of the application domain o OOD - developing an object-oriented system model to implement requirements o OOP is concerned with realising an OOD using an OO programming language such as C++

15. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 14 OO Revision  Objects are entities in a software system which represent instances of real-world and system entities  Object classes are generalised descriptions of objects  Object classes may inherit attributes and methods from other object classes  Object communication is by messages o The name of the method requested by the calling object. o In practice, messages are often implemented by procedure calls  Name = method name.  Information = argument list.

16. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 15 UML to Design  Remember - Analysis produced different models: o Class Diagram - classes in system o Dynamic Model - State diagrams, Sequence Diagrams, Use-cases  Design o Combine the models to obtain methods for the classes  State diagrams contain actions and activities, functional models contain process. These must be converted to methods associated with object classes on the object model. o Designing algorithms  defining an method (cf. recipe) - Which one?  choose cheapest to implement  choose appropriate data structures  may need to define new classes (intermediate results) & methods

17. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk )Chapter Six 16 UML to Design o Design optimisation - refine methods for efficiency o Adjustment of inheritance  rearrange and adjust classes to increase inheritance (e.g. some methods may differ only in the number of arguments but may be combined anyway)  abstract common behaviour out of groups of classes i.e inheritance opportunities missed in the object model o Information hiding  classes should be “black boxes” whose external interface is public but whose internal details are hidden  allow objects to be changed without effecting other objects  decide which attributes should be accessible by other objects {public} and which shouldn’t {private}