Chapter 08: Design Concepts and Principles

1
Chapter 08 Design Concepts and Principles

• 8.1 Introduction
• Once the analysis phase is finished and a
  specification of the requirements is available
  (and has been validated and reviewed) the project
  can move onto the design phase.
• Be careful! When we talk about software design in
  software engineering we are not talking about the
  look of the GUI!
• A well designed software means that it is easy to
  test, debug and maintain...

2

• We recall that depending on the software
  development process used (e.g. waterfall vs.
  evolutionary approach), not all the requirements
  maybe yet documented
• For example using an iterative approach the
  entire project is basically a succession of
  mini-projects, of iterations. Each iteration
  looks at a different aspect of the final system.
  In this case we still have an analysis phase
  followed by a design and finally a construction
  phase it is however limited to the current
  requirements under consideration
• Using a waterfall approach however, the entire
  requirements must be documented prior to moving
  on to the design
• Whatever approach is used design follows
  analysis and the principles and techniques used
  are the same

3

• The design document should be sufficiently
  detailed to be given to a separate team of
  programmers for coding
• The level of details necessary in a design
  document is subjective (the code is the lowest
  level of details for a software project).
  Typically we have to abstract low level details
  and, as long as the design document is not
  ambiguous, we can rely on the programmers to fill
  in the details
• It should be the blueprint from which software is
  constructed
• It can be assessed for quality a design of poor
  quality will probably lead to a poor final
  product
• It should cover all the requirements (functional
  and non-functional requirements think in terms
  of FURPS) the design is derived from the
  specification
• It should be readable by all (Project Managers,
  Testers, Coders etc.) this implies various
  levels of details (e.g. a project manager may
  only be interested in the overview whereas the
  coders will only be interested in the details)

4

• A few things to keep in mind about design
• Design is not coding and coding should not be
  about design!
• The design must be assessed for quality as it is
  being created.
• The design should consider unexpected (aberrant)
  data, events or operating conditions.
• The design document should formally reviewed.

5

• 8.2 Design Elements
• The architectural design
• Defines the relationships amongst, and the
  contents of, the major structural elements of
  the software
• Breaks-down the future software into manageable,
  logically independent, components
• The interfaces design
• Internal interfaces (e.g. between a server and
  its clients)
• For external systems that communicate with our
  application
• For humans (GUIs, Websites, etc.)
• The data structures design
• The specification document details what
  information the application will need to maintain
  the design phase chooses the best data
  structures to hold that information (array, lists
  singly or doubly linked, trees sorted,
  balanced, hash tables etc.). Will affect greatly
  the efficiency of the software. Algorithms, see
  procedural design below, to work on these data
  structures are also specified at that time.
• The procedural design
• Complex or critical algorithms also need to be
  designed prior to coding

6

• 8.3 Architectural Design Fundamentals
• We focus on architectural design fundamentals
  because
• it is maybe the less obvious area of software
  design
• it is also an aspect of design that will impact
  maintainability the most
• 8.3.1 Modularity
• A module is a separately named, addressable code
  component.
• A soon as a project is larger than a few hundreds
  lines of code it needs to be modularised
• A monolithic software (i.e. not modularised)
  cannot be easily understood (hence developed,
  tested, debugged and maintained) because of the
  large number of potential control paths,
  variables, scope of reference and overall
  complexity
• All software (except the very small ones), need
  to be designed in a modular fashion (it should
  not be an afterthought)
• Modularity is a characteristic common to all
  engineering disciplines.

7

• What is a module exactly? It depends
  Different programming languages have different
  ways of supporting modularity
• Turbo Pascal Unit a separate collection of data
  structures, procedures and functions with a well
  defined interface
• C Include File possibly separate collection of
  data structures and functions with a loosely
  defined interface
• Ada Package a separate collection of data
  structures, procedures and functions with a well
  defined interface
• OO languages (C, C, Java) Class a separate
  collection of data structures, functions with a
  well defined interface
• Modules can be very small (e.g. a module to
  define constants only). Typically we prefer small
  modules to large ones they are easier to
  understand, test, debug and maintain.
• A modular design makes concurrent coding, by
  various programmers, easier to schedule.
• Modules may call functions within another module
  notion of module dependence.

8

• Typically, a data structure held in a module
  should only be accessed (for read or write)
  directly within that module. The module must
  provide functions (accessors for read and
  mutators for write) to work on the data
  structures of a module for, other, external
  modules to use Notion of Information Hiding.
• 8.3.2 Information Hiding
• To increase the modularity of the software and
  reduce the complexity of dependencies between
  modules we can enforce the notion of information
  hiding.
• Modules should be designed so that information
  contained within a module is inaccessible to
  other modules that have no need of this
  information.
• This way communication between modules is
  restricted and standardised particularly useful
  for data structures manipulation modules

9

• Basically, we should consider each module as a
  black box with a well defined public interface
  made up of functions that external modules can
  call
• Some functions will be private (not accessible
  from external modules) to the module
• Data structures are all private accessors and
  mutators functions are provided if necessary
• This is a strong principle that re-enforce
  modularisation it requires a little more effort
  at design and coding time but it is rewarded
  later by increased testability, maintainability,
  re-usability and easier debugging.
• We will see an example of information hiding in
  chapter 10 on coding.

10

• 8.3.3 Software Architecture
• At the highest level, the software architecture
  describes how the application will be organised
  in terms of sub-systems.
• Sub-systems of the application are fairly
  separate entities that communicate with each
  other in a well defined, restricted, way.
• The organisation of each sub-system need to be
  further detailed via a modular design.
• A number of typical software architectures are
  possible
• A monolithic architecture, no sub-systems at all
  the entire application is made of modules that
  are not grouped together in logical sub-systems.
  There is no central database. Monolithic
  architectures are best avoided for medium to
  large applications
• A database-centric architecture the application
  contains a database that many modules access via
  a well defined protocol (e.g. SQL) for read and
  write. We would tend to prefer a layered
  architecture (see below) than a database-centric
  architecture

11

• A client-server architecture a server provides a
  set of services that associated clients access
  for updating and retrieving data to, and from,
  the servers. There is no client to client
  communications with this architecture. A
  client-server architecture is suitable for many
  networked applications e.g. e-commerce,
  networked applications.
• A fully distributed architecture there maybe no
  central server at all, clients are allowed to
  communicate with each other. More difficult to
  implement can be considered if the central
  server is the bottleneck in terms of performance.
  Peer-to-peer applications use this architecture.
• A layered architecture the system is grouped
  into layers (themselves using a modular design)
  that communicate with each other in a well
  defined way. Communications can be restricted in
  a top-down fashion layers can only communicate
  to the directly below. Each layer must obviously
  be modularised. Example

12
GUIs
GUI End User
GUI Manager
Web UI
Domain
Sales
Taxes
Payments
Databases
Sales Analysis
Accounts

• Combinations of the architectures introduced
  above may be found in a single application.

13

• 8.3.4 Modular Design
• As seen, software sub-systems must be organised
  into modules that contains data structures and
  functions, that communicate via well defined
  public interfaces to enforce information hiding.
• A module that calls upon the services of another
  module (e.g. via a function call) is dependent
  from it.
• We can represent all the dependencies between
  modules to obtain a visual representation of the
  control hierarchy of the modular design.
• Example

M
Depth
A
C
B
L
E
D
G
Width
14

• The above represents a nice modular design, we
  can see the layers, with a tree-like
  representation of the control hierarchy.
• The overall number of modules in a typical
  application can be large (100s), hence the need
  to organise the architecture of the application
  by identifying sub-systems and choose an
  appropriate overall software architecture (e.g. a
  layered architecture).
• We can split a module into 2 (or more) modules
  if
• It is becoming too big
• It is logical to do so (i.e. we can really
  identify logically separate functionality
  groupings within the module)
• Typically, in a modular design
• top-level modules are controllers that direct the
  work of other modules, they perform very little
  processing themselves
• Lower-level modules are workers that perform
  heavy processing, communicate with external, non
  UI actors, (e.g. a scanner) or communicate to a
  database

15

• 8.4 The Design Document
• A suggested design document layout is
• Introduction (e.g. the role of the software
  within the entire system, major design decisions,
  changes from original specification)
• Data structures design
• Architectural Design (using diagrams, explain the
  role of each sub-system)
• Interfaces Design
• GUI
• Between sub-systems
• External, non GUI, interfaces design
• Modular Design of each sub-system
• Overview (dependencies between modules)
• Brief Responsibilities of each module
• Data structure design of each module
• Procedural design of each module
• Test Provisions (ideas on how to test the code
  later on)
• Conclusions (points to watch out for during the
  rest of the project)

16

• 8.5 Conclusions
• The software design should be the blueprint from
  which software is constructed
• Coding should be straightforward after the design
  do not leave too many important decisions at
  coding time (do not rely on programmers)
• Design is a very important phase which should be
  done properly even for seemingly simple systems
• It will save time during programming (all the
  major design decisions will already have been
  taken)
• A well designed software we be easier to code,
  test, debug and maintain
• A design document should be formally reviewed
  prior to coding
• The design documents should allow the
  implementation of all the requirements.
• The design documents should include
• Architectural design
• Interfaces design
• Data structure design
• Procedural design