1. CSCI 3428: Software Engineering Tami Meredith Chapter 6 Designing the Modules

2. Design Not really any boundary between architecture and module-level design Generally done by senior developers Refactoring is often done when a design becomes overly complex Opportunistic – both top-down (analysis) and bottom- up (synthesis) is used Tends to increase in importance with the size of the project

3. Faking the Process (Parnas & Clements, 1986) Applies to more than just design We know that changes, unknowns, and other factors require an iterative approach But, if we TRY to follow a defined process: 1) It can provide guidance when we are unsure 2) It can help us get closer to a better result 3) It is easier to measure progress Thus, even though we know we can't apply any process perfectly, we should try our best to do so Can use placeholders (ToDo's), Refactoring as necessary

4. Principles 1. Modularity 2. Interfaces 3. Information hiding 4. Incremental development 5. Abstraction 6. Generality

5. Modularity We want to achieve Separation of Concerns A module is any programming unit, e.g., library, package, class, ADT, module, file Modules should have a single, clearly defined, purpose Measure modularity using  coupling: amount of interconnection and dependence between modules  cohesion: amount of interconnection and dependence between elements of a single module

6. Coupling Strive for LOOSE coupling Minimise the dependencies and interconnections between modules 1. Uncoupled: Modules are unrelated [LEAST] 2. Data Coupling: Pass simple (primitive) data 3. Stamp Coupling: Pass complex data structures 4. Control Coupling: One module influences the behaviour (i.e., control flow) of another 5. Common Coupling: Shared (common) data 6. Content Coupling: Module modifies another [MOST]

7. Cohesion Strive for TIGHT cohesion Want a module's components to be related and relevant to the module Informational: Functional cohesion + data abstraction [MOST] Functional: 1. All elements of a single behaviour are in the same module 2. All of the elements are essential for that behaviour Communicational: Functions get/send/manage the same data (e.g., both read same sensor) Procedural: Functions show an execution sequence Temporal: Functions execute at the same time (e.g., all the set-up code for a program) Logical: Use the same code differently Coincidental: Functions not related [LEAST]

8. Interfaces Defines the services offered by the module Usually provides the definitions in terms of (type) signatures for access functions Try to keep as small as possible Is the basis of the Design by Contract approach Specification describes the externally visible properties 1. Purpose (general description) 2. Preconditions (assumptions) 3. Protocols (usage restrictions etc.) 4. Postconditions (all external effects) 5. Quality attributes (performance etc.)

9. Information Hiding Design decisions are hidden – i.e., module can be rewritten without changing interface Structuring using ADTs Minimises coupling Increases cohesion Strive for self-containment

10. Incremental Development Recursive cycles can require large amounts of code to be produced before testing Techniques such as sandwiching or dependency inversion can be used to break cycles but lead to more complex design Incremental development leads to higher programmer morale Aim to get a working product ASAP and keep it working as its improved and/or extended Gives us something we can show customer

11. Abstraction We tend to break the system into a hierarchy of increasingly detailed abstractions Designs generally should support abstraction Somewhat like layered architecture, but smaller scale

12. Generality Try to make each module as general as possible to improve reuse E.g., a sort that works on any data type Can lead to gold-plating Helped by polymorphism How: 1. Parameterise context-specific information 2. Remove preconditions 3. Simplify postconditions (simpler parts)

13. 6.3 Objects Inheritance = implementation inheritance which need NOT be linked to sub-type hierarchy Polymorphism = inclusion (subtype) polymorphism which is NOT parametric polymorphism (or ad-hoc polymorphism) ADTs do not need objects to implement OO Implementations are slower at runtime because of the need for runtime type information to resolve over-riding Can add unneeded complexity to designs Works best for simulations

14. Using UML 1) Requirements: Use-Case diagrams, Activity diagrams 2) Architecture: Component diagrams, Deployment diagrams 3) Design: Sequence diagrams, Communication diagrams Class, Object, & Package diagrams Activity diagrams State diagrams

15. UML in Action Useful for formal settings Not usually done by entry-level programmers Generally linked to OO Implementations Good support for some Transformational development model Considered a specialised type of software engineering (OO SE) Not as general-purpose as some advocates suggest Did not solve the "Software Crisis"

16. 5 Surveys Famous Moments in Software Engineering 1. Robbins-Gioia (2001) Implementation of ERP (Enterprise Resource Planning) Package 232 Respondents: 36% had or were impl. ERP 51%: ERP Unsuccessful 46%: Did not think org. knew how to use it 56%: Had a program mgmt office in place (and of these 36% considered the ERP unsuccessful) 2. KPMG Canada (1997) 1450 Leading Public/Private Organisations (176 responses) 25 billion (CAD) spent 61% considered projects to have failed 75%+ blew schedule by 30% or more

17. 3. Conference Board Survey (2001) 117 Companies that attempted ERP 34% Very satisfied, 58% Somewhat satisfied, 8% Unhappy 40% Failed to achieve business goals in 1 year For those who achieved goals, took 6 months longer than expected 25% over budget, Support costs 20% too low 4. Chaos Report (1995) 31% of projects cancelled before they are finished 52% of projects will cost over 189% of estimate 81 billion USD spent on 80K cancelled projects (1995) 16.2% completed on time and on budget (but only 9% for large companies) Only 42% of the proposed features implemented (large companies) and 74% (small companies) 48% of IT executives believe the failure rate is rising

18. 5. OASIG (1995) 45 Expert consultants/professors 20 years avg. experience (900 total) 14k projects considered 7 out of 10 IT projects fail in some way Success rate < 30%