Software Design

1
Software Design

• a process that adds implementation details to the
  requirements
• produces a design specification that can be
  mapped onto a program
• may take several iterations to produce a good
  design specification
• may also produce several design specifications
  that correspond to different views of the same
  software product

2
Requirements vs. Design

• Requirements describe WHAT the system is
  supposed to do while design describes HOW the
  requirements will be implemented
• Add implementation oriented details without
  changing the functionality in a requirement
• Often, beginners get confused between a
  requirement and a design
• Must be resolved right at the beginning
  otherwise, the requirements themselves will be
  narrow and biased towards a particular
  implementation

3
Requirements vs. Design an example (informal)

• In the automated ticketing system in a parking
  lot example,
• Requirement Issue ticket
• When a vehicle enters, print a ticket with date
  and time record date and time issue the ticket
  to the vehicle.
• Design ticket ? issueTicket()
• ticket ? createTicket()
• ticket.date ? getCurrentDate()
• ticket.time ? getCurrentTime()
• updateTickets (ticket)
• Format of ticket, date and time must have
  been defined already.

4
Requirements vs. Design another example
(informal)

• In the phone book example,
• Requirement Select phone diary
• Make the phone diary active.
• Design selectPhoneDiary()
• if ((fp open (phFile)) ! null)
• for i 1 to numberOfPhoneEntries
• phEntriesi ? read (fp)
• else throw FileOpenErrorException

5
Design vs. Implementation

• Design adds implementation oriented details but
  may not be (most likely, will not be) the final
  implementation
• See the design example in the previous slide
• The choice of File and its format, and the
  choice of read procedure are left to the
  implementer.

6
Design Principles by Alan Davis

• a design process should not have a tunnel vision
• should consider all possible solutions and make
  use of all available resources
• a design specification should have mechanisms to
  trace back to requirements
• easy to identify mistakes later on and is also
  easy to add more features to the software product

7
Design principles (continued)

• a design process should not reinvent the wheel
• should try to make use of previous design
  patterns, resources and experiences as much as
  possible
• a design specification should be structured to
  accommodate changes
• easier if it follows some standards such as IEEE,
  ANSI, ISO, etc.

8
Design principles (continued)

• a design specification is not code, and code is
  not design
• a design specification should be somewhat
  abstract so that it is easier to understand and
  easier to change at the same time, it is
  sufficiently concrete so that its implementation
  is fairly straightforward
• use of algorithmic languages and diagrammatic
  notations is highly recommended for a design
  process
• some programming languages (e.g., Ada) can be
  used for both design and programming

9
Design principles (continued)

• a design process must provide mechanisms to check
  quality during the design process and not after
  the design specification is developed
• indirectly, it implies that the design process
  must be iterative
• also, it implies that if quality errors are found
  after the design specification is developed, it
  may be hard to retract

10
Design Evaluation

• a software design must include all explicit and
  implicit requirements given in the requirements
  document
• nothing should be left out from the requirements
  document
• a design specification must be readable,
  understandable by the implementation team, and
  should be verifiable for consistency and
  correctness
• a design specification must be implementable
• mapping to a program must be straightforward
• a design must support modular structures

11
Measures of Module Strength

• the relative independence of a module is
  considered to be the strength of a module
• fairly independent modules are easier to
  implement and easier to maintain
• two qualitative measures
• coupling
• cohesion

12
Coupling

• a measure of interconnection among the modules of
  a software product
• there must be at least two modules involved
• measures the complexity of interface between
  modules
• example
• how many parameters are passed
• how many parameters are composite
• how many parameters are shared values
• .

13
Coupling

• a measure of the interdependence among components
  in a software system
• describes the nature and the extend of the
  connections between the elements in the system
• Motivation predicting and controlling the scope
  of changes to a system (dependencies follow lines
  of coupling)
• Example change in one class causes changes to
  ripple through the design like shock waves in
  earthquake, with much the same effect

14
Types of coupling

• data coupling
• data passed through arguments
• generally, one argument list is used
• relatively, low-level coupling
• example print (a, b)
• stamp coupling
• data structures passed as arguments
• generally, passed via module interface
• coupling measure is higher than data coupling
• example .h files in C/C
• example rich library classes/package in Java

15
Types of coupling (continued)

• control coupling
• a control variable is passed to coordinate or
  synchronize executions between modules
• similar to data coupling but limited to one or
  two control variables
• relatively low-level coupling
• example return values from procedures
• external coupling
• relatively high-level coupling
• example I/O connections involve specific
  formats and protocols

16
Types of coupling (continued)

• common coupling
• sharing data that is stored in a common place,
  called global data area
• both data and data structures may be shared
• high-level coupling because the effect of failure
  of one module is propagated to all the other
  modules that use the same data
• example files in disks/secondary storage

17
Types of coupling (continued)

• content coupling
• one module can access the data and control
  information (possibly the code) of another module
• highest level of coupling
• example two procedures in an assembly language
  program

18
Coupling

• Goal - to limit any form of coupling to two
  kinds
• A) which is inherent in the problem domain
• B) which limits the type and scope of changes to
  as small a portion of the design as possible
• Tightly coupled components cannot be reused
  separately!

19
Effect of coupling on software design

• a good design process should aim at reducing
  coupling
• reduction of coupling ? reduction of dependence
  of one module over another ? increase the
  independence of module ? increase the ability to
  change or maintain the modules

20
Cohesion

• A module is cohesive, or has high cohesion, if
  its internal parts are closely related towards
  the achievement of a clear purpose.
• measures how a single module is related to a
  particular functionality in the system
• only one module is involved
• ideally, a highly cohesive module should do only
  one task/activity/function
• example
• a sorting module that contains only one sorting
  function and this function sorts integers only
• a sorting module that contains several sorting
  functions that implement various sorting
  techniques but all sort integers only
• a sorting module that contains several sorting
  functions that implement various sorting
  techniques but sort integers and floats

21
Types of cohesion

• coincidental cohesion
• functions that are not at all related to each
  other but are placed in a single module (happen
  to be a coincidence)
• example a function that performs sorting and a
  printer driver, both in the same module
• functions that are somewhat related but do not
  have much in common also fall in this category
• example a function that computes an average of a
  sequence and a function that sorts a sequence,
  both being placed in the same module
• low-level cohesion

22
Coincidental Cohesion - Example

• Procedure sum1_and_ sum2(in n1,n2int
  arr1,arr2int array out sum1, sum2 int)
• var i int
• begin
• sum1 0
• sum2 0
• for i 1 to n1 do
• sum1 sum1 arr1i
• for i 1 to n2 do
• sum2 sum2 arr2i
• end

23
Types of cohesion (continued)

• logical cohesion
• functions that are logically related to each
  other, all placed in the same module
• example a set of functions that output a given
  data in various formats (bar chart, graph,
  pie-chart, )
• moderate level of cohesion
• temporal cohesion
• functions that are related by time, all placed in
  the same module
• example the alarm system, automatic telephone
  dialing unit of a security system both placed in
  the same module these two must be activated at
  the same time
• moderate level of cohesion

24
Types of cohesion (continued)

• procedural cohesion
• functions that are related by a sequence of
  procedure calls, all placed in the same module
• example an input function receiving a data, a
  function that processes the data, and a function
  that outputs the result of that computation, all
  placed in the same module
• moderate level of cohesion

25
Types of cohesion (continued)

• communication cohesion
• all functions in a module concentrate on one area
  of a data structure or use the same data
  structure
• example a shared file and a set of functions
  acting on that shared file
• low to moderate level of cohesion, mostly lower

26
Communication Cohesion

• Example 1
• book inventory is used for managing orders and
  producing bills.
• Example 2
• procedure sum_and_prod (in nint, arrint array,
• out sum, prodint, avgfloat)
• var i int
• begin
• sum 0
• prod 0
• for i 1 to n do
• sum sum arri
• prod prod arri
• avg sum/n
• end

27
Sequential Cohesion

• Sequential
• the output from one part of a component is input
  to the next part.
• Example 1 compilers.
• Example 2
• procedure fibo_avg( in nint
• out fib_arrint array,
  avgfloat)
• var sum, iint
• begin
• fib_arr1 1
• fib_arr2 2
• for i 3 to n
• fib_arrI fib_arri-1 fib_arri-2
• sum(n, fib_arr, sum)
• avg sum/n
• end

28
Functional Cohesion

• Functional
• every processing element is essential to the
  performance of a single functionality, and all
  essential elements are contained in one
  component.
• A functionally cohesive component not only
  performs the functionality for which it is
  designed, but also performs only that
  functionality and nothing else.
• It is thus more likely that changing this
  particular functionality will affect only one
  component.
• Example procedure sum( in nint arrint array
  out sumint)
• var iint
• begin
• sum 0
• For i 1 to n
• sum sum arri
• end

29
Effect of cohesion on software design

• a good design process should try to maximize
  cohesion of each module
• maximizing cohesion ? maximizing the use of the
  module towards particular functionality ?
  appropriate modularization of the design

30
Methods to evaluate coupling and cohesion

• coupling can be evaluated using metrics tools
• cohesion is generally evaluated manually by
  experts / software engineers
• walk through the design documents and iterate the
  design until cohesion is improved to a
  satisfactory level

31
Four design models

• Data design
• Architectural design
• Interface design
• Component-level design

32
Data Design

• concerned with design aspects of the data objects
  produced during analysis
• adding data types and data structures
• often produced in conjunction with architecture
  design
• iterated throughout the design process until an
  implementable data design model is achieved

33
Data design (continued)

• at the business level,
• data is considered in a group that is meaningful
  to the business or organization
• example customer data, corporate data, stocks,
  
• decision on whether or not an external database
  or data warehouse is necessary, is taken at this
  level
• if decided, details on databases, data warehouses
  and data mining are further considered
• interoperability among data elements are also
  considered at this level
• often, uses an E-R model for representation

34
Data design (continued)

• at the application level
• business level data groups are divided into small
  groups that are meaningful in the application
  domain
• example customer profiles, customer preferences,
  customer transactions, organizational policies,
• the relationships among the data elements in the
  business level are still maintained in the
  application level ? ensures consistency
• may use E-R model or object model for
  representation

35
Data design (continued)

• at the component level,
• data from application level is mapped onto
  detailed, programming data types
• example structures, records, tables, index
  files,
• multiple choices are considered and evaluated
• once again, consistency is maintained i.e.,
  relationships among data elements from
  application level are still maintained
• will use the representation supported by the
  chosen programming language and paradigm
• DFD for procedural and object model for OO
  approaches

36
Principles for data design at the component level

• data representation should be consistently
  refined (transformed from abstract to concrete)
  along with procedural refinement
• often, both refinements are done concurrently
• all data structures and the operations on them,
  are completely identified at each level of
  refinement
• even if certain operations are not needed at that
  level, or for that application, they are still
  included in the refinement to make the refinement
  complete

37
Principles for data design (continued)

• use a data dictionary at all times, separated
  from the program design
• useful in designing operations on the data
  structures at the component level
• include authenticity with data elements so that
  only those procedures / methods that need the
  data, will actually see the complete data others
  do not know anything about this data
• similar to encapsulation in OO approaches (to be
  discussed later)

38
Architectural Design

• describes the structural relationships among the
  major elements of the software design such as
  databases, modules, subsystems, etc.
• similar to components and their relationships of
  a building
• an architectural design specification also
  indicates the types and characteristics of each
  relationship among its data elements
• an architectural design specification is static
  (and so is not dynamic) in the sense that it
  does not describe the operational behavior of the
  system rather, describes the static structures
  and the permanent relationships (such as
  associations and aggregations) among them

39
Architectural design (continued)

• may use design patterns
• templates of data elements and their
  interconnections
• generally represented using diagrammatic
  notations
• E-R diagrams
• Structure charts
• UML (for OO models)

40
Advantages of explicit architecture

• Stakeholder communication
• Architecture may be used as a focus of discussion
  by system stakeholders
• System analysis
• Means that analysis of whether the system can
  meet its non-functional requirements is possible
• Large-scale reuse
• The architecture may be reusable across a range
  of systems

41
Architectural design process

• System structuring
• The system is decomposed into several principal
  sub-systems and communications between these
  sub-systems are identified
• Control modelling
• A model of the control relationships between the
  different parts of the system is established
• Modular decomposition
• The identified sub-systems are decomposed into
  modules

42
Sub-systems and modules

• A sub-system is a system in its own right whose
  operation is independent of the services provided
  by other sub-systems
• A module is a system component that provides
  services to other components but would not
  normally be considered as a separate system

43
Architectural styles

• The architectural model of a system may conform
  to a generic architectural model or style
• An awareness of these styles can simplify the
  problem of defining system architectures
• However, most large systems are heterogeneous and
  do not follow a single architectural style

44
Types (Styles) of software architectures

• Data-centered architecture
• a data stored (database or data warehouse) is
  modeled as the centerpiece of the architecture
• all modules, subsystems, procedures etc. are
  described in terms of their operational
  characteristics on the data store (add, delete,
  modify, etc.)
• useful for database-oriented applications
• example reservation system

45
(No Transcript)
46
The repository model

• Sub-systems must exchange data. This may be done
  in two ways
• Shared data is held in a central database or
  repository and may be accessed by all sub-systems
• Each sub-system maintains its own database and
  passes data explicitly to other sub-systems
• When large amounts of data are to be shared, the
  repository model of sharing is most commonly used

47
Repository model characteristics

• Advantages
• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data
  is produced Centralised management e.g. backup,
  security, etc.
• Sharing model is published as the repository
  schema
• Disadvantages
• Sub-systems must agree on a repository data
  model. Inevitably a compromise
• Data evolution is difficult and expensive
• No scope for specific management policies
• Difficult to distribute efficiently

48
Types (Styles) of software architectures

• data-flow architecture
• a set of software components called filters
  connected by a set of connectors called pipes
• data flows through the pipes and processed (or
  filtered) by the filters
• data transformation occurs at each filter
• traditional and most common architecture
• represented by data flow diagrams

49
(No Transcript)
50
Data Flow Architecture
51
Pipes and Filters

• Advantages
• No intermediate files necessary.
• Flexibility by filter exchange.
• Flexibility by recombination
• Reuse of filter components
• Rapid Prototyping of pipelines
• Efficiency by parallel processing
• System evolution is simple
• Drawbacks
• Sharing state information is expensive /
  inflexible
• Efficiency gain through parallel processing is
  often an illusion
• Data transformation overhead
• Error handling The major problem
• Encourages batch processing
• Not good for handling interactive applications

52
Types (Styles) of software architectures

• control architecture
• programming modules (or subsystems) are divided
  into sub-modules (or modules)
• relationships among sub-modules (or modules)
  indicate procedure calls and return mechanisms
• execution thread can be easily identified
• concurrency and multiple threads of control can
  be explored
• represented using structure charts

53
(No Transcript)
54
Control Architecture

• Are concerned with the control flow between
  sub-systems. Distinct from the system
  decomposition model
• Centralised control
• One sub-system has overall responsibility for
  control and starts and stops other sub-systems
• Event-based control
• Each sub-system can respond to externally
  generated events from other sub-systems or the
  systems environment

55
Centralised control

• A control sub-system takes responsibility for
  managing the execution of other sub-systems
• Call-return model
• Top-down subroutine model where control starts at
  the top of a subroutine hierarchy and moves
  downwards. Applicable to sequential systems
• Manager model
• Applicable to concurrent systems. One system
  component controls the stopping, starting and
  coordination of other system processes. Can be
  implemented in sequential systems as a case
  statement

56
Call and Return
57
Call-return model
58
Real-time system control
59
Event-driven systems

• Driven by externally generated events where the
  timing of the event is outwit the control of the
  sub-systems which process the event
• Two principal event-driven models
• Broadcast models. An event is broadcast to all
  sub-systems. Any sub-system which can handle the
  event may do so
• Interrupt-driven models. Used in real-time
  systems where interrupts are detected by an
  interrupt handler and passed to some other
  component for processing

60
Broadcast model

• Effective in integrating sub-systems on different
  computers in a network
• Sub-systems register an interest in specific
  events. When these occur, control is transferred
  to the sub-system which can handle the event
• Control policy is not embedded in the event and
  message handler. Sub-systems decide on events of
  interest to them
• However, sub-systems dont know if or when an
  event will be handled

61
Selective broadcasting
62
Interrupt-driven systems

• Used in real-time systems where fast response to
  an event is essential
• There are known interrupt types with a handler
  defined for each type
• Allows fast response but complex to program and
  difficult to validate

63
Interrupt-driven control
64
Types (styles) of software architectures

• layered architecture
• applicable to complex systems that are divided
  into several layers
• example ISO network architecture (7 layers)
• example UNIX operating system
• outer layers are more abstract than the inner
  layer(s)
• each layer can be modeled using any of the other
  architectural styles

65


66
Reference Models

• Reference models are derived from a study of the
  application domain rather than from existing
  systems
• May be used as a basis for system implementation
  or to compare different systems. It acts as a
  standard against which systems can be evaluated
• OSI model is a layered model for communication
  systems

67
OSI reference model
Application
68
Types (styles) of software architectures

• Client-Server Architecture
• A client system issues a request that is handled
  by a server system that provides services to its
  clients
• Suitable for most transaction-oriented systems.
• Example The server might provide a simple
  service, such as storing files for a community of
  users, or a more complex service, such as booking
  airlines seats for customers.

69
Client-Server Architecture

• Server Implements objects that expose their
  functionality through interfaces that consist of
  operations and attributes
• Broker A messenger that is responsible for the
  transmission of requests from clients to servers,
  as well as the transmission of responses and
  exceptions back to the client.
• Client side proxy represents a layer between
  clients and the broker . The additional layer
  provides transparency in that a remote object
  appears to the client as a local one.
• Server side proxy are generally analogous to
  client-side proxies, except they are responsible
  for receiving requests.

70
Client-Server Architecture

• Advantages
• Location Transparency, broker is responsible for
  locating a server by using a unique identifier,
  clients do not need to know where servers are
  located.
• Changeability and extensibility If servers
  changes but their interface remain the same, it
  has no functional impact on the clients.
• For reusing design components from other systems.
  Hides the operating system
• Components can register for an event from any
  service
• Interoperability between different Broker
  systems (as long as they have a common protocol)
• Disadvantages
• Lack of assurance that a component will respond
  to an event.
• Restricted efficiency applications using a
  broker are usually slow.

71
A client-server system
72
Computers in a network
73
Interface design

• describes communication links between elements of
  the system, and between the system and the
  environment (external to the system) the latter
  is called user-interface
• flow of data and control between each pair of
  elements as well as between the system and the
  external environment are identified
• diagrammatic notations such as data flow diagrams
  and state transition diagrams may be used
• often developed in conjunction with data design
  and data refinement

74
Component-level design

• detailed description of each element of the
  system such as procedures, algorithms, packages,
  modules, subsystems and the system as a whole
• each data element is now mapped to data types in
  the underlying programming language
• the last level of refinement of data design and
  architectural design
• flow charts, low-level design languages (e.g.,
  Ada) may be used