1. Best Practices

2. 2 How to design a Software Solution The plans or designs: –Represent the agreed upon needs of the user (“contract”) –Communicate what the programmers need to implement –Assist future programmers in maintaining or enhancing code

3. 3 Design Tools Design methods –Describe how to design a solution (specify design practices and strategies) Design patterns –Offer generic solutions to a problem by describing a problem and a strategy for addressing the problem Representation –Assists in modeling the intended system –Assists in evaluating its behavior

4. 4 Designs will include descriptions such as: The static structure of the system The data objects The algorithms The system packaging The component interactions The process being designed

5. 5 Levels of design detail Level 1: The software system –High level design of the entire system Level 2: Division into subsystem or packages –Business Rules, User Interface, Database Access, System Dependencies Level 3: Division into classes within packages Level 4: Division into data and routines within classes Level 5: Internal routine design

6. 6 Elements of good system architectures Program organization Major classes Data design Business rules User interface design Resource management Security Performance Scalability Interoperability

7. 7 Elements of good system architectures Internationalization/localization Input/output Error processing Fault tolerance Architectural feasibility Robustness Buy-versus-build decisions Reuse decisions Change strategy General architectural quality

8. 8 Good architecture looks natural and easy Objectives should be clearly stated Motivations for all decisions clearly stated Machine and language independent Parts of the architecture should not receive more attention than deserved Identify & explain risk areas, indicate steps taken to minimize risks Architecture should contain multiple views of system Programmer should be comfortable with architecture

9. 9 Design errors occur if The design is not self-consistent The design and the specification are not consistent The design and the requirements are not consistent

10. 10 Avoiding design errors Detect inconsistencies early –Late detection = more difficult and costly to correct errors Verify –Design checked against the specification –“Are we building the product right” Validate –Design checked against the user requirements –“Are we building the right product”

11. 11 Fundamental Design Principles Simplicity Modularity Information hiding

12. 12 Simplicity “A design should be as simple as possible, but no simpler” Albert Einstein Added extras & fancy trimmings might detract from the design’s purpose A simple design supports –Maintainability –Testability –Reliability –efficiency

13. 13 Modularity Divide system into smaller modules –grouping functionality –Minimize interdependence –Disadvantage of interdependency = one change can have many repercussions Orthogonal system –components highly independent (decoupled) –Easier to design, build, test & extend –Can improve reliability & efficiency

14. 14 Benefits of Modularity Increased Productivity Reduced Risk

15. 15 Modularity: - Increased productivity - Changes are localized –change one component without affecting another –Reduces development time & testing time Easy module replacement –Modules easily replaced with another, if necessary Easier development –Easier to write smaller, self-contained components –Each module captures one feature of a problem Promotes reuse –Components with specific, well-defined responsibilities can be reused

16. 16 Modularity: - Reduced risk - Problem code is isolated –If code in module faulty – problem less likely to spread –Also easier to replace module with new one Reduced fragility – system less fragile –Any problems caused by small changes made to area will be restricted to that area Increased testability –Easier to run tests on each component Increased flexibility

17. 17 Typical Layer Diagram Each layer hiding unnecessary detail

18. 18 Assessing modular structuring in SW Coupling –A measure of inter-module connectivity (the “form” and “strength” of the connection –E.g. more desirable to have modules A & B communicating using parameters than sharing common data area (global variables) Cohesion –A measure of how “functionally related” the components of the module are. –PrintReceipt module –code for printing the receipt NOT code for recording the receipt of money

19. 19 Guidelines for creating software components (libraries of classes) Functionality –Component must have well-defined role Interfaces –Component must have well-defined interface Dependencies –Component should not have any context specific dependencies –Existing dependencies should be clearly specified

20. 20 Information hiding Data structures within module to be concealed from other software components Direct access to data prevented Data can be made accessible via procedures, functions etc. Stack class – data structure (stack) – hidden Class methods Push & Pop allows stack to be accessed

21. 21 Example designs NOT consistent with Fundamental Design Principles Many copies of “state” information - may lead to inconsistencies in system behavior Interface too complex – procedures or methods with too many parameters Excessively complex control structures Unnecessary replication of information, duplicate copies of information – passing complete record as parameter when only one field relevant Modules lacking functional strength – not well focused i.t.o focus

22. 22 Further Fundamental Design Principles Find real-world objects Form consistent abstractions Encapsulate implementation details Inherit – when inheritance simplifies the design Identify areas likely to change Look for common design patterns

23. 23 Find Real-World Objects Identify the objects (Employee & Client) and their attributes (data & methods: Name & UpdateAddress) Determine what operations can be performed on each object –Changing an employee’s title or billing rate Determine the parts of each object that will be visible to other objects –Public vs Private Define each object’s interface –Public & Protected

24. 24 Form Consistent Abstraction Abstraction –The ability to engage with a concept while safely ignoring some of its irrelevant details –Allows developer to focus on interface without having to worry about class’s internal workings The real world “door” example –Rectangular piece of material with hinges and a doorknob / door handle –When using the door – not concerned with individual fibers or workings of hinges or doorknob / door handle

25. 25 Encapsulate Implementation Details Abstraction allows you to look at the object at high level of detail Encapsulation prohibits you from looking at the object at any other level of detail –Hides the details of the complex concept

26. 26 Allows a new class to be defined as a specialization of another class. –New class automatically inherits the features of the class it is created from –Can add additional features or change or suppress inherited features Employee PartTimeEmployee FullTimeEmployee Inherit -When inheritance simplifies the design

27. 27 Identify areas likely to change Isolate areas likely to change to limit the effect of the change to one routine / class –Change thus confined to small area

28. 28 Common design patterns for a GOOD DESIGN Most problems similar to past problems Thus, can be solved using similar solution/patterns Simplicity –“as simple as possible, but no simpler” design System Structure –Well structured design, consistent with modularity and information hiding –Simplified using abstraction, encapsulation & inheritance Quality factors –Adhere to quality assessment criteria (Chapter 1)

29. 29 Design Practices Iterate Divide and conquer Top-down and bottom-up design approaches –composition strategy & decomposition strategy Collaborative design Capturing your design work (see next slide)

30. 30 Capturing your design work Insert design documentation into the code itself Capture design discussions and decisions on Web pages Write e-mail summaries Use a digital camera Save design flip charts Use CRC (Class, Responsibility, Collaborator) cards Create UML diagrams at appropriate levels of detail

31. 31 Design Representations Help with the process of modeling the intended system and with evaluating its behavior. “black box” – describes what a system does “white box” – describes how it is to do it.

32. 32 Black Box representation - what

33. 33 White box representations - how

34. 34 Design Methods and Patterns Provide strategic guidance for the designer –Suggesting how to generate design solutions by describing tasks to be performed and ordering sequence

35. 35 Design Methods and Patterns

36. 36 Design Methods and Patterns Standard ways of combining objects and classes to solve common design problems Offer generic solutions to a problem –By describing particular problem and –A strategy for addressing problem –Allowing designers to use solution repeatedly Example: The development of the arched bridge –Once basic idea established, model can be adapted and extended to create variety of bridges: large, small, single or multiple arches.

37. 37 Design Methods and Patterns The proxy design pattern

38. 38 Design Methods and Patterns The proxy design pattern – Class Diagram

39. 39 Design Methods and Patterns The proxy design pattern – Sequence Diagram

40. 40 Using a catalogue of Design Patterns Specify the problem Select the category of pattern that is appropriate to the design activity involved Select the problem category appropriate to the problem Compare the problem description with the available set of patterns taken from the selected category Compare benefits and liabilities Select the pattern variant that most fits the problem

41. 41 Prototyping Experimental, exploratory or evolutionary role You can typically prototype: –Architecture –New functionality in an existing system –Structure or contents of external data –Third party tools or components –Performance issues –User interface designs

42. 42 Experimental & Exploratory (Disposable) Prototypes You can ignore: –Correctness – use dummy data –Completeness – limited functionality of prototype –Robustness – error checking incomplete / missing –Style – little documentation besides details of learning experience

43. 43 Evolutionary Prototypes Forms skeleton of final system Helps to get from a requirement to some aspect of final system quickly and visibly Not fully functional, but contains all error- checking, structuring, documentation etc. Allows for “fit for purpose” evaluation & easy adding of functionality

44. 44 Advantages of Evolutionary Prototypes Users get to see something working quickly Developers build a structure to work in You have an integration platform You have something to demonstrate You have a better feel for the program.

45. 45 Prototyping guidelines Dispose of disposable prototypes Prototyping for the client will demand the client’s time Choose appropriate tools Make sure everyone knows that the prototype is not the real deal

46. 46 The Specification Trap Specification will never capture every detail of a system or its requirements – users not 100% certain of their needs Diagramming techniques and formal methods are not always able to convey details in a natural way An overly descriptive design restricts the programmer

47. 47 Flexibility and Adaptability Scenario 1 During test phase, decided database system too slow – need to be changed to one from another vendor. How easily will this be to do? Is database access code entangled – will it be a nightmare to make the change.

48. 48 Flexibility and Adaptability Scenario 2 Project begins as client-server model. Later decided that servers are too expensive for some clients, they want a stand-alone version. How hard will it be for you to oblige?

49. 49 Duplicating Knowledge Follow the “don’t duplicate” principle Categories of duplication: Imposed duplication –Environment seems to make duplication unavoidable Inadvertent duplication –Developers introduce duplication without realising it Impatient duplication –Developers get lazy and duplicate as it seems easier. Inter-developer duplication –Information duplicated by multiple team members

50. 50 Gently exceeding your user’s expectations Balloon or ToolTip help Keyboard shortcuts A quick reference guide as a supplement to the user’s manual Colourisation Log file analysers Automated installation Tools for checking the integrity of the system The ability to run multiple versions of the system for training A splash screen customized for their organization

51. 51 Further Principles and Practices Design and plan carefully Avoid complexity Make appropriate technology choices Etc.