Best Practices

1

• 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 designs 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) hidden
• Class 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 employees title or billing rate
• Determine the parts of each object that will be
  visible to other objects
• Public vs Private
• Define each objects 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 classs 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
Inherit -When inheritance simplifies the design

• 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

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 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
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 Patterns

• The proxy design pattern

38
Design Methods and Patterns

• The 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
  clients 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 dont 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
Gently exceeding your users expectations

• Balloon or ToolTip help
• Keyboard shortcuts
• A quick reference guide as a supplement to the
  users 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.