CS3773 Software Engineering Lecture 07 Software Architecture Design 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 2 – Functional requirements – Nonfunctional requirements Software design process is iterative UTSA CS3773 Decomposition and Modularity The essence of software design is making decisions about the logical organization of the software 3 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 CS3773 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 4 UTSA CS3773 Abstraction - I 5 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 CS3773 Abstraction - II 1950s: software was written in machine language 6 – 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 CS3773 Abstraction - III Late 1950s: the emerging of the first high-level programming languages. – 7 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 CS3773 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 – – 8 Data and related code are encapsulated into modules Interfaces to modules are made explicit UTSA CS3773 Software Architecture Design 9 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 CS3773 Software Architecture Issues 10 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 CS3773 Other Architecture Disciplines Look at several architectural disciplines in order to develop an intuition about software architecture – – – 11 Hardware Architecture Network Architecture Building Architecture UTSA CS3773 Hardware Architecture 12 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 CS3773 Software vs. Hardware Architectures Differences: – – Similarities: – 13 Relatively (to software) small number of design elements. Scale is achieved by replication of design elements. We often configure software architectures in ways analogous to hardware architectures e.g., we create multi-process software and use pipelined processing UTSA CS3773 Network Architecture Networked architectures are achieved by abstracting the design elements of a network into nodes and connections Topology is the most emphasized aspect: – – – 14 Star networks Ring networks Ethernet Unlike software architectures, in network architectures only few topologies are of interest UTSA CS3773 Building Architecture 15 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 CS3773 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: 16 The topology of the descriptions, e.g., no cycles Execution semantics, e.g., processes execute in parallel UTSA CS3773 Software Architecture Styles We can understand what a style is by answering the following questions: – – – – – – 17 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 CS3773 Software Architecture Styles – – – – – – – – – 18 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 CS3773 Pipe and Filter 19 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 CS3773 Pipe and Filter 20 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 CS3773 Pipe and Filter 21 UTSA CS3773 Pipe and Filter 22 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 CS3773 Pipe and Filter Specializations 23 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 CS3773 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: – – – – 24 Lexical analysis Parsing Semantic analysis Code generation UTSA CS3773 Pipe and Filter - Advantages 25 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 CS3773 Pipe and Filter - Advantages 26 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 CS3773 Pipe and Filter - Disadvantages 27 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 CS3773 Object-Oriented Style 28 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 CS3773 Object-Oriented Style 29 UTSA CS3773 Object-Oriented Invariants 30 Objects are responsible for preserving the integrity (e.g., some invariant) of the data representation The data representation is hidden from other objects UTSA CS3773 Object-Oriented Specializations 31 Distributed Objects Objects with Multiple Interfaces UTSA CS3773 Object-Oriented Advantages 32 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 UTSA CS3773 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 – – Objects cause side effect problems: – 33 Contrast with Pipe and Filter Style When the identity of an object changes it is necessary to modify all objects that invoke it e. g., A and B both use object C, then B's affect on C look like unexpected side effects to A UTSA CS3773 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: – – 34 Changing a service provider Enabling or disabling capabilities UTSA CS3773 Implicit Invocation Style (Cont’d) Instead of invoking a procedure directly ... – – – 35 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 CS3773 Implicit Invocation Style (Cont’d) 36 An event announcement “implicitly” causes the invocation of procedures in other modules. UTSA CS3773 Implicit Invocation Invariants 37 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 CS3773 Implicit Invocation Specializations 38 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 CS3773 Implicit Invocation Examples Used in programming environments to integrate tools: – – 39 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 CS3773 Implicit Invocation Examples (Cont’d) 40 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 CS3773 Implicit Invocation Advantages 41 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 CS3773 Implicit Invocation Disadvantages When a component announces an event: – – – 42 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 CS3773 Client-Server Style Suitable for applications that involve distributed data and processing across a range of components Components: – – 43 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 CS3773 Client-Server Style 44 UTSA CS3773 Client-Server Style Examples File Servers: – – – 45 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 CS3773 Client-Server Style Examples (Cont’d) Database Servers: – – – – – 46 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 CS3773 Client-Server Advantages 47 Distribution of data is straightforward transparency of location mix and match heterogeneous platforms easy to add new servers or upgrade existing servers UTSA CS3773 Client-Server Disadvantages 48 No central register of names and services -- it may be hard to find out what services are available UTSA CS3773 Layered Style 49 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 CS3773 Layered Style (Cont’d) 50 Components: are typically collections of procedures Connectors: are typically procedure calls under restricted visibility UTSA CS3773 Layered Style (Cont’d) 51 UTSA CS3773 Layered Style Specializations Often exceptions are be made to permit non-adjacent layers to communicate directly – 52 This is usually done for efficiency reasons UTSA CS3773 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 – 53 Unix UTSA CS3773 Layered Style Advantages 54 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 CS3773 Layered Style Disadvantages 55 Not all systems are easily structured in a layered fashion Performance requirements may force the coupling of highlevel functions to their lower-level implementations UTSA CS3773 Repository Style 56 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 CS3773 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: – 57 Typically procedure calls or direct memory accesses UTSA CS3773 Repository Style (Cont’d) 58 UTSA CS3773 Repository Style Specializations 59 Changes to the data structure trigger computations Data structure in memory (persistent option) Data structure on disk Concurrent computations and data accesses UTSA CS3773 Repository Style Examples 60 Information Systems Programming Environments Graphical Editors AI Knowledge Bases Reverse Engineering Systems UTSA CS3773 Repository Style Advantages 61 Efficient way to store large amounts of data Sharing model is published as the repository schema Centralized management: – backup – security – concurrency control UTSA CS3773 Repository Style Disadvantages 62 Must agree on a data model a prior Difficult to distribute data Data evolution is expensive UTSA CS3773 Interpreter Style 63 Suitable for applications in which the most appropriate language or machine for executing the solution is not directly available UTSA CS3773 Interpreter Style (Cont’d) 64 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 CS3773 Interpreter Style (Cont’d) 65 UTSA CS3773 Interpreter Style Examples 66 Programming Language Compilers: – Java – Smalltalk Rule Based Systems: – Prolog – Coral Scripting Languages: – Awk – Perl UTSA CS3773 Interpreter Style Advantages 67 Simulation of non-implemented hardware Facilitates portability of application or languages across a variety of platforms UTSA CS3773 Interpreter Style Disadvantages 68 Extra level of indirection slows down execution Some interpreters have an option to compile code UTSA CS3773 Process-Control Style 69 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 CS3773 Process-Control Style Connectors: are the data flow relations for: – 70 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 UTSA CS3773 FeedBack Control System 71 The controlled variable is measured and the result is used to manipulate one or more of the process variables UTSA CS3773 Feedforward Control System 72 Information about process variables is not used to adjust the system UTSA CS3773 Process Control Examples 73 Real-Time System Software to Control: – Automobile Anti-Lock Brakes – Nuclear Power Plants – Automobile Cruise-Control UTSA CS3773 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. 74 UTSA CS3773 Mobile Robotics Functional Requirements 75 Typical software functions – Acquiring and interpreting input from sensors – Controlling the motion of all moving parts – Planning future activities – Responding to current difficulties UTSA CS3773 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) 76 – Robot may manipulate hazardous materials (water) – Unpredictable events may demand a rapid response UTSA CS3773 Mobile Robotics Design Constraints 77 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 CS3773 Mobile Robotics Architecture Designs 78 Closed loop control architecture Layered architecture Repository/Blackboard architecture Implicit invocation architecture UTSA CS3773 Control Loop Architecture Style 79 UTSA CS3773 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. 80 UTSA CS3773 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. 81 UTSA CS3773 Control Loop Architecture Style Evaluation 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. 82 UTSA CS3773 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. 83 UTSA CS3773 Control Loop Architecture Style Overall Evaluation 84 Appropriate for simple robotic systems that must handle only a small number of external events and whose tasks do not require complex decompositions UTSA CS3773 Layered Architecture Style 85 UTSA CS3773 Layered Architecture Style Evaluation 86 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. UTSA CS3773 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. 87 UTSA CS3773 Layered Architecture Style Evaluation 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 passive safety are also served by abstraction mechanism. Performance and active safety issues may force the communication pattern to be short-circuited. 88 UTSA CS3773 Layered Architecture Style Evaluation Flexibility: support for experimentation and reconfiguration Interlayer dependencies are an obstacle to easy replacement and addition of components. 89 UTSA CS3773 Layered Architecture Style Overall Evaluation 90 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 CS3773 Blackboard Architecture Style 91 UTSA CS3773 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. 92 UTSA CS3773 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 robot’s world view. 93 UTSA CS3773 Blackboard Architecture Style Evaluation 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 The TCA exception mechanisms, wiretapping and monitoring roles can be implemented by defining separate modules that watch the database for exceptional circumstances. 94 UTSA CS3773 Blackboard Architecture Style Evaluation Flexibility: support for experimentation and reconfiguration Supports concurrency and maintenance by decoupling senders from receivers. 95 UTSA CS3773 Blackboard Architecture Style Overall Evaluation 96 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 CS3773 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 – – – 97 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. UTSA CS3773