CS3773 Software Engineering

1
CS3773 Software Engineering

• Lecture 07
• Software Architecture Design

2
Software Design

• Software design transforms software requirements
  specification into a description of the solution
• Architecture design
• Detail design
• algorithms, data structures, etc
• Software design should satisfy all the
  requirements
• Functional requirements
• Nonfunctional requirements
• Software design process is iterative

3
Decomposition and Modularity

• The essence of software design is making
  decisions about the logical organization of the
  software
• There are different ways of software design
• Every design method involves some kind of
  decomposition
• Modular decomposition functional description
• Data-oriented decomposition external data
  structures
• Event-oriented decomposition events and states
• Outside-in design user inputs
• Object-oriented design classes and their
  interrelationships

4
Software Architecture

• Software architecture is the structure of a
  software system like the blue prints in
  building architecture
• Software components
• Details (data structure and algorithms) hidden
• Services (how they use, are used by, relate to,
  and interact with other component) displayed
• Relationships among the components
• Data flows
• Control flows

5
Abstraction - I

• One characterization of progress in software
  development has been the regular increase in
  abstraction levels, i.e., the conceptual size of
  software designer's building blocks

6
Abstraction - II

• 1950s software was written in machine language
• Instructions and data were placed individually
  and explicitly in the computer's memory
• Machine code programming problems were solved by
  adding a level of abstraction between the program
  and the machine
• Symbolic Assemblers
• Macro Processors

7
Abstraction - III

• Late 1950s the emerging of the first high-level
  programming languages.
• Well understood patterns are created from
  notations that are more like mathematics than
  machine code
• evaluation of arithmetic expressions
• procedure invocation
• loops and conditionals
• followed with higher-levels of abstraction for
  representing data (types)

8
Abstraction - IV

• Late 1960s and 1970s programmers shared an
  intuition that good data structure design will
  ease the development of a program
• This intuition was converted into theories of
  modularization and information hiding
• Data and related code are encapsulated into
  modules
• Interfaces to modules are made explicit

9
Software Architecture Design

• As the size and complexity of software systems
  increases, the design problem goes beyond
  algorithms and data structures
• Designing and specifying the overall system
  structure (Software Architecture) emerges as a
  new kind of problem
• One way to organize a software system is based on
  the theory of abstract data types

10
Software Architecture Issues

• Organization and global control structure
• Protocols of communication, synchronization, and
  data access
• Assignment of functionality to design elements
• Physical distribution
• Composition of design elements
• Scaling and performance
• Selection among design alternatives

11
Other Architecture Disciplines

• Look at several architectural disciplines in
  order to develop an intuition about software
  architecture
• Hardware Architecture
• Network Architecture
• Building Architecture

12
Hardware Architecture

• RISC (Reduced Instruction Set Computer ) machines
  emphasize the instruction set as an important
  feature
• Pipelined and multi-processor machines emphasize
  the configuration of architectural pieces of the
  hardware

13
Software vs. Hardware Architectures

• Differences
• Relatively (to software) small number of design
  elements.
• Scale is achieved by replication of design
  elements.
• Similarities
• We often configure software architectures in ways
  analogous to hardware architectures
• e.g., we create multi-process software and use
  pipelined processing

14
Network Architecture

• Networked architectures are achieved by
  abstracting the design elements of a network into
  nodes and connections
• Topology is the most emphasized aspect
• Star networks
• Ring networks
• Ethernet
• Unlike software architectures, in network
  architectures only few topologies are of interest

15
Building Architecture

• Multiple views skeleton frames, detailed views
  of electrical wiring, etc.
• Architectural styles Classical, Romanesque, and
  so on
• Materials one does not build a skyscraper using
  framing lumber and plywood

16
Software Architecture Styles

• An architectural style defines a family of
  systems in terms of a pattern of structural
  organization
• It determines
• The vocabulary of components and connectors that
  can be used in instances of that style
• A set of constraints on how they can be combined
  
• For example, one might constrain
• The topology of the descriptions, e.g., no cycles
• Execution semantics, e.g., processes execute in
  parallel

17
Software Architecture Styles

• We can understand what a style is by answering
  the following questions
• What is the structural pattern? (i.e.,
  components, connectors, constraints)
• What is the underlying computational model?
• What are the essential invariants of the style?
• What are some common examples of its use?
• What are the advantages and disadvantages of
  using that style?
• What are some of the common specializations of
  that style?

18
Software Architecture Styles

• Software architectures are represented as graphs
• Nodes represent components
• procedures
• modules
• processes
• tools
• databases
• Edges represent connectors
• procedure calls
• event broadcasts
• database queries
• pipes

19
Pipe and Filter

• Suitable for applications that require a defined
  series of independent computations to be
  performed on ordered data
• A component reads streams of data on its inputs
  and produces streams of data on its outputs

20
Pipe and Filter

• Components called filters, apply local
  transformations to their input streams and often
  do their computing incrementally so that output
  begins before all input is consumed
• Connectors called pipes, serve as conduits for
  the streams, transmitting outputs of one filter
  to inputs of another

21
Pipe and Filter
22
Pipe and Filter

• Filters do not share state with other filters
• Filters do not know the identity of their
  upstream or downstream filters
• The correctness of the output of a pipe and
  filter network shall not depend on the order in
  which their filters perform their incremental
  processing

23
Pipe and Filter Specializations

• Pipeline restricts topologies to linear
  sequences of filters
• Batch sequential a degenerate case of a pipeline
  architecture where each filter processes all of
  its input data before producing any output

24
Pipe and Filter Examples

• Unix Shell Scripts provides a notation for
  connecting Unix processes via pipes.
• e.g., cat file grep Erroll wc
• Traditional Compilers compilation phases are
  pipelined, though the phases are not always
  incremental. The phases in the pipeline include
• Lexical analysis
• Parsing
• Semantic analysis
• Code generation

25
Pipe and Filter - Advantages

• Easy to understand the overall input/output
  behavior of a system as a simple composition of
  the behaviors of the individual filters
• They support reuse, since any two filters can be
  hooked together, provided they agree on the data
  that is being transmitted between them

26
Pipe and Filter - Advantages

• Systems can be easily maintained and enhanced,
  since new filters can be added to existing
  systems and old filters can be replaced by
  improved ones
• They permit certain kinds of specialized
  analysis, such as throughput and deadlock
  analysis
• The naturally support concurrent execution

27
Pipe and Filter - Disadvantages

• Not good for handling reactive systems, because
  of their transformational character
• Excessive parsing and unparsing leads to loss of
  performance and increased complexity in writing
  the filters themselves

28
Object-Oriented Style

• Suitable for applications in which a central
  issue is identifying and protecting related
  bodies of information (data)
• Data representations and their associated
  operations are encapsulated in an abstract data
  type
• Components are objects
• Connectors are function and procedure
  invocations (methods)

29
Object-Oriented Style
30
Object-Oriented Invariants

• Objects are responsible for preserving the
  integrity (e.g., some invariant) of the data
  representation
• The data representation is hidden from other
  objects

31
Object-Oriented Specializations

• Distributed Objects
• Objects with Multiple Interfaces

32
Object-Oriented Advantages

• Because an object hides its data representation
  from its clients, it is possible to change the
  implementation without affecting those clients
• Can design systems as collections of autonomous
  interacting agents

33
Object-Oriented Disadvantages

• In order for one object to interact with another
  object (via a method invocation) the first object
  must know the identity of the second object
• Contrast with Pipe and Filter Style
• When the identity of an object changes it is
  necessary to modify all objects that invoke it
• Objects cause side effect problems
• e. g., A and B both use object C, then B's affect
  on C look like unexpected side effects to A

34
Implicit Invocation Style

• Suitable for applications that involve
  loosely-coupled collection of components, each of
  which carries out some operation and may in the
  process enable other operations
• Particularly useful for applications that must be
  reconfigured on the fly
• Changing a service provider
• Enabling or disabling capabilities

35
Implicit Invocation Style (Contd)

• Instead of invoking a procedure directly ...
• A component can announce (or broadcast) one or
  more events
• Other components in the system can register an
  interest in an event by associating a procedure
  with the event
• When an event is announced, the broadcasting
  system (connector) itself invokes all of the
  procedures that have been registered for the event

36
Implicit Invocation Style (Contd)

• An event announcement implicitly causes the
  invocation of procedures in other modules.

37
Implicit Invocation Invariants

• Announcers of events do not know which components
  will be affected by those events
• Components cannot make assumptions about the
  order of processing
• Components cannot make assumptions about what
  processing will occur as a result of their events
  (perhaps no component will respond)

38
Implicit Invocation Specializations

• Often connectors in an implicit invocation system
  also include the traditional procedure call in
  addition to the bindings between event
  announcements and procedure calls

39
Implicit Invocation Examples

• Used in programming environments to integrate
  tools
• Debugger stops at a breakpoint and makes that
  announcement
• Editor responds to the announcement by scrolling
  to the appropriate source line of the program and
  highlighting that line

40
Implicit Invocation Examples (Contd)

• Used to enforce integrity constraints in database
  management systems (called triggers)
• Used in user interfaces to separate the
  presentation of data from the applications that
  manage that data

41
Implicit Invocation Advantages

• Provides strong support for reuse since any
  component can be introduced into a system simply
  by registering it for the events of that system
• Eases system evolution since components may be
  replaced by other components without affecting
  the interfaces of other components in the system

42
Implicit Invocation Disadvantages

• When a component announces an event
• it has no idea what other components will respond
  to it
• it cannot rely on the order in which the
  responses are invoked
• it cannot know when responses are finished

43
Client-Server Style

• Suitable for applications that involve
  distributed data and processing across a range of
  components
• Components
• Servers Stand-alone components that provide
  specific services such as printing, data
  management, etc.
• Clients Components that call on the services
  provided by servers
• Connector The network, which allows clients to
  access remote servers

44
Client-Server Style
45
Client-Server Style Examples

• File Servers
• Primitive form of data service
• Useful for sharing files across a network
• The client passes request for files over the
  network to the file server

46
Client-Server Style Examples (Contd)

• Database Servers
• More efficient use of distributing power than
  file servers
• Client passes SQL requests as messages to the DB
  server results are returned over the network to
  the client
• Query processing done by the server
• No need for large data transfers
• Transaction DB servers also available

47
Client-Server Advantages

• Distribution of data is straightforward
• transparency of location
• mix and match heterogeneous platforms
• easy to add new servers or upgrade existing
  servers

48
Client-Server Disadvantages

• No central register of names and services -- it
  may be hard to find out what services are
  available

49
Layered Style

• Suitable for applications that involve distinct
  classes of services that can be organized
  hierarchically
• Each layer provides service to the layer above it
  and serves as a client to the layer below it
• Only carefully selected procedures from the inner
  layers are made available (exported) to their
  adjacent outer layer

50
Layered Style (Contd)

• Components are typically collections of
  procedures
• Connectors are typically procedure calls under
  restricted visibility

51
Layered Style (Contd)
52
Layered Style Specializations

• Often exceptions are be made to permit
  non-adjacent layers to communicate directly
• This is usually done for efficiency reasons

53
Layered Style Examples

• Layered Communication Protocols
• Each layer provides a substrate for communication
  at some level of abstraction
• Lower levels define lower levels of interaction,
  the lowest level being hardware connections
  (physical layer)
• Operating Systems
• Unix

54
Layered Style Advantages

• Design based on increasing levels of
  abstraction.
• Enhancement since changes to the function of one
  layer affects at most two other layers
• Reuse since different implementations (with
  identical interfaces) of the same layer can be
  used interchangeably

55
Layered Style Disadvantages

• Not all systems are easily structured in a
  layered fashion
• Performance requirements may force the coupling
  of high-level functions to their lower-level
  implementations

56
Repository Style

• Suitable for applications in which the central
  issue is establishing, augmenting, and
  maintaining a complex central body of information
• Typically the information must be manipulated in
  a variety of ways
• Often long-term persistence of information is
  required

57
Repository Style (Contd)

• Components
• A central data structure representing the correct
  state of the system
• A collection of independent components that
  operate on the central data structure
• Connectors
• Typically procedure calls or direct memory
  accesses

58
Repository Style (Contd)
59
Repository Style Specializations

• Changes to the data structure trigger
  computations
• Data structure in memory (persistent option)
• Data structure on disk
• Concurrent computations and data accesses

60
Repository Style Examples

• Information Systems
• Programming Environments
• Graphical Editors
• AI Knowledge Bases
• Reverse Engineering Systems

61
Repository Style Advantages

• Efficient way to store large amounts of data
• Sharing model is published as the repository
  schema
• Centralized management
• backup
• security
• concurrency control

62
Repository Style Disadvantages

• Must agree on a data model a prior
• Difficult to distribute data
• Data evolution is expensive

63
Interpreter Style

• Suitable for applications in which the most
  appropriate language or machine for executing the
  solution is not directly available

64
Interpreter Style (Contd)

• Components include one state machine for the
  execution engine and three memories
• current state of the execution engine
• program being interpreted
• current state of the program being interpreted
• Connectors
• procedure calls
• direct memory accesses

65
Interpreter Style (Contd)
66
Interpreter Style Examples

• Programming Language Compilers
• Java
• Smalltalk
• Rule Based Systems
• Prolog
• Coral
• Scripting Languages
• Awk
• Perl

67
Interpreter Style Advantages

• Simulation of non-implemented hardware
• Facilitates portability of application or
  languages across a variety of platforms

68
Interpreter Style Disadvantages

• Extra level of indirection slows down execution
• Some interpreters have an option to compile code

69
Process-Control Style

• Suitable for applications whose purpose is to
  maintain specified properties of the outputs of
  the process at (sufficiently near) given
  reference values
• Components
• Process Definition includes mechanisms for
  manipulating some process variables
• Control Algorithm for deciding how to manipulate
  process variables

70
Process-Control Style

• Connectors are the data flow relations for
• Process Variables
• Controlled variable whose value the system is
  intended to control
• Input variable that measures an input to the
  process
• Manipulated variable whose value can be changed
  by the controller
• Set Point is the desired value for a controlled
  variable
• Sensors to obtain values of process variables
  pertinent to control

71
FeedBack Control System

• The controlled variable is measured and the
  result is used to manipulate one or more of the
  process variables

72
Feedforward Control System

• Information about process variables is not used
  to adjust the system

73
Process Control Examples

• Real-Time System Software to Control
• Automobile Anti-Lock Brakes
• Nuclear Power Plants
• Automobile Cruise-Control

74
Mobile Robotics

• A mobile robotics system is one that controls
  a manned or partially
• manned vehicle, such as a car, a submarine , or a
  space vehicle. Such
• systems are finding many new uses in areas such
  as space exploration,
• hazardous waste disposal, and underwater
  exploration. A robotics system
• must deal with external sensors and actuators,
  and they must respond in
• real time at rates commensurate with the
  activities of the system in its
• environment. In particular, the software
  functions of a mobile robot
• typically include acquiring input provided by its
  sensors, controlling the
• motion of its wheels and other moveable parts,
  and planning its future
• path.

75
Mobile Robotics Functional Requirements

• Typical software functions
• Acquiring and interpreting input from sensors
• Controlling the motion of all moving parts
• Planning future activities
• Responding to current difficulties

76
Mobile Robotics Complications

• Several factors complicate the tasks
• Obstacles may block the robots path
• Sensor input may be imperfect or fail
• Robot may run out of power
• Mechanical limitations may restrict the accuracy
  with which it moves (movement may diverge from
  plans)
• Robot may manipulate hazardous materials (water)
• Unpredictable events may demand a rapid response

77
Mobile Robotics Design Constraints

• Evaluation criteria
• Accommodation of deliberate and reactive
  behavior robot must coordinate actions to
  achieve assigned objectives with the reactions
  imposed by the environment
• Allowance for uncertainty robot must function in
  the context of incomplete, unreliable and
  contradictory information
• Accounting of dangers in the robots operations
  and its environment relating to fault tolerance,
  safety and performance, problems like reduced
  power supply, unexpectedly open doors, etc.,
  should not lead to disaster
• Flexibility support for experimentation and
  reconfiguration

78
Mobile Robotics Architecture Designs

• Closed loop control architecture
• Layered architecture
• Repository/Blackboard architecture
• Implicit invocation architecture

79
Control Loop Architecture Style
80
Control Loop Architecture Style Evaluation

• Accommodation of deliberate and reactive
  behavior robot must coordinate actions to
  achieve assigned objectives with the reactions
  imposed by the environment
• Simplicity problem in more unpredictable
  environments since there is basic assumption that
  changes in environment are continuous and require
  continuous reactions. Basic changes in behavior
  may be needed when confronted with disparate
  discrete events.

81
Control Loop Architecture Style Evaluation

• Allowance for uncertainty robot must function in
  the context of incomplete, unreliable and
  contradictory information
• Uncertainty is resolved by reducing unknowns
  through iteration problem if more subtle steps
  are needed.

82
Control Loop Architecture Style Evaluation

• Accounting of dangers in the robots operations
  and its environment relating to fault tolerance,
  safety and performance, problems like reduced
  power supply, unexpectedly open doors, etc.,
  should not lead to disaster
• Fault tolerance and safety are enhanced by the
  simplicity of the architecture.

83
Control Loop Architecture Style Evaluation

• Flexibility support for experimentation and
  reconfiguration
• Major components (supervisor, sensors, motors)
  can be easily replaced more refined tuning must
  take place inside the modules.

84
Control Loop Architecture Style Overall Evaluation

• Appropriate for simple robotic systems that must
  handle only a small number of external events and
  whose tasks do not require complex decompositions

85
Layered Architecture Style
86
Layered Architecture Style Evaluation

• Accommodation of deliberate and reactive
  behavior robot must coordinate actions to
  achieve assigned objectives with the reactions
  imposed by the environment
• Nicely organizes components needed to coordinate
  operation. However, does not fit the actual data
  and control-flow patterns. Information exchange
  is less straightforward exceptional events may
  force direct communication between levels 2 and
  8, for example. Also, there are really two
  abstraction hierarchies that actually exist a
  data hierarchy and a control hierarchy.

87
Layered Architecture Style Evaluation

• Allowance for uncertainty robot must function in
  the context of incomplete, unreliable and
  contradictory information
• Existence of abstraction layers nicely addresses
  need for managing uncertainty things get more
  certain the higher one gets.

88
Layered Architecture Style Evaluation

• Accounting of dangers in the robots operations
  and its environment relating to fault tolerance,
  safety and performance, problems like reduced
  power supply, unexpectedly open doors, etc.,
  should not lead to disaster
• Fault tolerance and passive safety are also
  served by abstraction mechanism. Performance and
  active safety issues may force the communication
  pattern to be short-circuited.

89
Layered Architecture Style Evaluation

• Flexibility support for experimentation and
  reconfiguration
• Interlayer dependencies are an obstacle to easy
  replacement and addition of components.

90
Layered Architecture Style Overall Evaluation

• Nice, high-level view of robot control, but
  breaks down as an implementation view since the
  communication patterns are not likely to follow
  the orderly scheme implied by the architecture.

91
Blackboard Architecture Style
92
Blackboard Architecture Style Evaluation

• Accommodation of deliberate and reactive
  behavior robot must coordinate actions to
  achieve assigned objectives with the reactions
  imposed by the environment
• Components communicate via the shared
  repository modules indicate their interest in
  certain types of information the database
  returns relevant data either immediately or when
  some other module inserts the relevant data into
  the database.

93
Blackboard Architecture Style Evaluation

• Allowance for uncertainty robot must function in
  the context of incomplete, unreliable and
  contradictory information
• The blackboard helps to resolve conflicts or
  uncertainty in the robots world view.

94
Blackboard Architecture Style Evaluation

• Accounting of dangers in the robots operations
  and its environment relating to fault tolerance,
  safety and performance, problems like reduced
  power supply, unexpectedly open doors, etc.,
  should not lead to disaster
• The TCA exception mechanisms, wiretapping and
  monitoring roles can be implemented by defining
  separate modules that watch the database for
  exceptional circumstances.

95
Blackboard Architecture Style Evaluation

• Flexibility support for experimentation and
  reconfiguration
• Supports concurrency and maintenance by
  decoupling senders from receivers.

96
Blackboard Architecture Style Overall Evaluation

• Capable of modeling the cooperation of tasks in a
  flexible manner thanks to an implicit invocation
  mechanism based on the contents of the database

97
Reading Assignments

• Sommervilles Book, 8th Edition
• Chapter 11, Architectural design
• Chapter 12, Distributed System Architecture
• Chapter 13, Application Architectures
• Sommervilles Book, 9th Edition
• Chapter 6, Architectural design
• Chapter 18, Distributed Software Engineering
• Chapter 19, Service-Oriented Architecture
• David Garlan and Mary Shaw, An introduction to
  software
• architecture, Technical Report
  CMU-CS-94-166, School of
• Computer Science, Carnegie Mellon
  University.