cs3773 software engineering lecture 07 software architecture design

CS3773 Software Engineering

Lecture 07Software Architecture Design

UTSA CS37732

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

UTSA CS37733

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

UTSA CS37734

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

UTSA CS37735

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

UTSA CS37736

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

UTSA CS37737

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)

UTSA CS37738

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

UTSA CS37739

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

UTSA CS377310

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

UTSA CS377311

Other Architecture Disciplines

Look at several architectural disciplines in order to develop an intuition about software architecture

– Hardware Architecture– Network Architecture– Building Architecture

UTSA CS377312

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

UTSA CS377313

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

UTSA CS377314

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

UTSA CS377315

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

UTSA CS377316

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

UTSA CS377317


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?

UTSA CS377318


Software architectures are represented as graphs Nodes represent components:

– procedures– modules– processes– tools– databases

Edges represent connectors:– procedure calls– event broadcasts– database queries– pipes

UTSA CS377319

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

UTSA CS377320

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

UTSA CS377321

Pipe and Filter

UTSA CS377322

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

UTSA CS377323

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

UTSA CS377324

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

UTSA CS377325

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

UTSA CS377326

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

UTSA CS377327

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

UTSA CS377328

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)

UTSA CS377329

Object-Oriented Style

UTSA CS377330

Objects are responsible for preserving the integrity (e.g., some invariant) of the data representation

The data representation is hidden from other objects

Object-Oriented Invariants

UTSA CS377331

Distributed Objects Objects with Multiple Interfaces

Object-Oriented Specializations

UTSA CS377332

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

Object-Oriented Advantages

UTSA CS377333

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

Object-Oriented Disadvantages

UTSA CS377334

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

UTSA CS377335

Implicit Invocation Style (Cont’d)

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

UTSA CS377336

Implicit Invocation Style (Cont’d)

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

UTSA CS377337

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)

UTSA CS377338

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

UTSA CS377339

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

UTSA CS377340

Implicit Invocation Examples (Cont’d)

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

UTSA CS377341

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

UTSA CS377342

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

UTSA CS377343

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

UTSA CS377344

Client-Server Style

UTSA CS377345

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

UTSA CS377346

Client-Server Style Examples (Cont’d)

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

UTSA CS377347

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

UTSA CS377348

Client-Server Disadvantages

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

UTSA CS377349

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

UTSA CS377350

Layered Style (Cont’d)

Components: are typically collections of procedures Connectors: are typically procedure calls under

restricted visibility

UTSA CS377351

Layered Style (Cont’d)

UTSA CS377352

Layered Style Specializations

Often exceptions are be made to permit non-adjacent layers to communicate directly

– This is usually done for efficiency reasons

UTSA CS377353

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

UTSA CS377354

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

UTSA CS377355

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

UTSA CS377356

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

UTSA CS377357

Repository Style (Cont’d)

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

UTSA CS377358

Repository Style (Cont’d)

UTSA CS377359

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

UTSA CS377360

Repository Style Examples

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

UTSA CS377361

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

UTSA CS377362

Repository Style Disadvantages

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

UTSA CS377363

Interpreter Style

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

UTSA CS377364

Interpreter Style (Cont’d)

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

UTSA CS377365

Interpreter Style (Cont’d)

UTSA CS377366

Interpreter Style Examples

Programming Language Compilers:– Java– Smalltalk

Rule Based Systems:– Prolog– Coral

Scripting Languages:– Awk– Perl

UTSA CS377367

Interpreter Style Advantages

Simulation of non-implemented hardware

Facilitates portability of application or languages across a variety of platforms

UTSA CS377368

Interpreter Style Disadvantages

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

UTSA CS377369

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

UTSA CS377370

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

Process-Control Style

UTSA CS377371

FeedBack Control System

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

UTSA CS377372

Feedforward Control System

Information about process variables is not used to adjust the system

UTSA CS377373

Process Control Examples

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

UTSA CS377374

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.

UTSA CS377375

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

UTSA CS377376

Mobile Robotics Complications

Several factors complicate the tasks– Obstacles may block the robot’s 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

UTSA CS377377

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 robot’s 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

UTSA CS377378

Mobile Robotics Architecture Designs

Closed loop control architecture

Layered architecture

Repository/Blackboard architecture

Implicit invocation architecture

UTSA CS377379

Control Loop Architecture Style

UTSA CS377380

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.

UTSA CS377381


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.

UTSA CS377382


Accounting of dangers in the robot’s 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.

UTSA CS377383


Flexibility: support for experimentation and reconfiguration

Major components (supervisor, sensors, motors) can be easily replaced; more refined tuning must take place inside the modules.

UTSA CS377384

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

UTSA CS377385

Layered Architecture Style

UTSA CS377386

Layered Architecture Style Evaluation


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.

UTSA CS377387



Existence of abstraction layers nicely addresses need for managing uncertainty: things get more certain the higher one gets.

UTSA CS377388



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.

UTSA CS377389



Interlayer dependencies are an obstacle to easy replacement and addition of components.

UTSA CS377390

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.

UTSA CS377391

Blackboard Architecture Style

UTSA CS377392

Blackboard Architecture Style Evaluation


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.

UTSA CS377393



The blackboard helps to resolve conflicts or uncertainty in

the robot’s world view.

UTSA CS377394



The TCA exception mechanisms, wiretapping and monitoring roles can be implemented by defining separate modules that watch the database for exceptional circumstances.

UTSA CS377395



Supports concurrency and maintenance by decoupling

senders from receivers.

UTSA CS377396

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

UTSA CS377397

Reading Assignments

Sommerville’s Book, 8th Edition– Chapter 11, “Architectural design” – Chapter 12, “Distributed System Architecture”– Chapter 13, “Application Architectures”

Sommerville’s 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.

cs3773 software engineering lecture 07 software architecture design

Documents

software development

software architecture

blocksutsa cs3773utsa

explicitutsa cs3773utsa

etcsoftware design

design problem

good data structure

complexity of software