Best Practices

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

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

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

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

Elements of good system architectures

• Program organization• Major classes• Data design• Business rules• User interface design• Resource management• Security• Performance• Scalability• Interoperability

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

General architectural quality

• 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

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

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

Fundamental Design Principles

• Simplicity

• Modularity

• Information hiding

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

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

Benefits of Modularity

• Increased Productivity

• Reduced Risk

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

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

Typical Layer Diagram

• Each layer hiding unnecessary detail

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

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

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) – hiddenClass methods Push & Pop allows stack to be

accessed

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

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

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

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

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

• 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

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

Common design patterns for a GOOD DESIGN

Most problems similar to past problemsThus, 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

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

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

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

Black Box representation - what

33

White box representations - how

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

Design Methods and Patterns

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

Design Methods and PatternsThe proxy design pattern

38

Design Methods and PatternsThe proxy design pattern – Class Diagram

39

Design Methods and Patterns

The proxy design pattern – Sequence Diagram

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

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

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

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

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

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

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

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

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

Duplicating Knowledge

• Follow the “don’t duplicate” principleCategories 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

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

Further Principles and Practices

• Design and plan carefully

• Avoid complexity

• Make appropriate technology choices

• Etc.

• Etc.

• Etc.