Architectural Design

Software EngineeringCOMP 201Lecturer: Sebastian CoopeAshton Building, Room G.18E-mail: coopes@liverpool.ac.uk

COMP 201 web-page:http://www.csc.liv.ac.uk/~coopes/comp201

Lecture 15 Distributed System Architectures

1Architectural Design - Establishing the Overall Structure of a Software SystemTopics covered:System structuringControl modelsModular decomposition

Multiprocessor architectures Client-server architecturesDistributed object architecturesArchitectural DesignDistributed Systems Architectures2COMP201 - Software EngineeringSoftware ArchitectureThe design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural designThe output of this design process is a description of the software architecture3COMP201 - Software EngineeringArchitectural DesignArchitectural design should be an early stage of the system design processRepresents the link between specification and design processesOften carried out in parallel with some specification activitiesIt involves identifying major system components and their communications4COMP201 - Software EngineeringArchitectural Design ProcessSystem structuringThe system is decomposed into several principal sub-systems and communications between these sub-systems are identifiedControl modellingA model of the control relationships between the different parts of the system is establishedModular decompositionThe identified sub-systems are decomposed into modules5COMP201 - Software EngineeringSub-systems and ModulesA 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 system6COMP201 - Software EngineeringReal world Sub-system examplesTypically organized as Java packages/C++ libraries/C# assembliesDatabase access layerMySQL access, JDBC layerSecurity servicesEncryption classes, signature classes (modules)External Payment sub-systemEmail service sub-systemLogging sub-systemFinancial transaction sub-systemMarketing sub-system

COMP201 - Software Engineering7Architectural ModelsDifferent architectural models may be produced during the design processEach model presents different perspectives on the architecture:Static structural model Dynamic process modelInterface modelRelationships model

8COMP201 - Software EngineeringArchitectural ModelsStatic structural models show the major system componentsDynamic process models show the process structure of the systemInterface models define sub-system interfacesRelationships models such as a data-flow model9COMP201 - Software EngineeringSystem StructuringConcerned with decomposing the system into interacting sub-systemsThe architectural design is normally expressed as a block diagram presenting an overview of the system structure(More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed)10COMP201 - Software EngineeringPacking Robot Control System

11COMP201 - Software EngineeringThe Repository ModelSub-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-systemsEach 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 used12COMP201 - Software EngineeringClient-Server ArchitectureDistributed system model which shows how data and processing is distributed across a range of components:Set of stand-alone servers which provide specific services such as printing, data management, etc.Set of clients which call on these servicesNetwork which allows clients to access servers

13COMP201 - Software EngineeringFilm and Picture Library

14COMP201 - Software EngineeringClient-Server CharacteristicsAdvantagesDistribution of data is straightforwardMakes effective use of networked systems. May require cheaper hardwareEasy to add new servers or upgrade existing serversDisadvantagesNo shared data model so sub-systems use different data organisation. data interchange may be inefficientRedundant management in each serverNo central register of names and services - it may be hard to find out what servers and services are available15COMP201 - Software EngineeringAbstract Machine Model- Used to model the interfacing of sub-systemsOrganises the system into a set of layers (or abstract machines) each of which provide a set of servicesSupports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affectedHowever, it is often difficult to structure systems in this way16COMP201 - Software EngineeringISO/OSI Network Model

Application17COMP201 - Software EngineeringControl Models Control Models are concerned with the control flow between sub systems:Centralised controlOne sub-system has overall responsibility for control and starts and stops other sub-systemsEvent-based controlEach sub-system can respond to externally generated events from other sub-systems or the systems environment18COMP201 - Software EngineeringCentralised ControlA control sub-system takes responsibility for managing the execution of other sub-systems. There are two main types of centralised control models (sequential or parallel):Firstly, there is the call-return modelTop-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systemsSuch a model is embedded into familiar programming languages such as C, Java, Pascal etc.19COMP201 - Software EngineeringCall-Return Model

20COMP201 - Software EngineeringCentralised ControlIf the controlled subsystems run in parallel, then we may use the manager model of centralised control:Manager modelApplicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can also be implemented in sequential systems as a case statement.21COMP201 - Software EngineeringReal-Time System Control

22COMP201 - Software EngineeringEvent-Driven SystemsDriven by externally generated events where the timing of the event is out of the control of the sub-systems which process the eventThere are 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 soInterrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing23COMP201 - Software EngineeringBroadcast ModelEffective in integrating sub-systems on different computers in a networkSub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the eventControl policy is not embedded in the event and message handler. Sub-systems decide on events of interest to themHowever, sub-systems dont know if or when an event will be handled24COMP201 - Software EngineeringSelective Broadcasting

25COMP201 - Software EngineeringInterrupt-Driven SystemsUsed in real-time systems where fast response to an event is essentialThere are known interrupt types with a handler defined for each typeEach type is associated with a memory location and a hardware switch causes transfer to its handlerAllows fast response but complex to program and difficult to validate26COMP201 - Software EngineeringInterrupt-Driven Control

27COMP201 - Software EngineeringModular DecompositionAnother structural level where sub-systems are decomposed into modulesTwo modular decomposition models coveredAn object model where the system is decomposed into interacting objectsA data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline modelIf possible, decisions about concurrency should be delayed until modules are implemented28COMP201 - Software EngineeringObject ModelsStructure the system into a set of loosely coupled objects with well-defined interfacesObject-oriented decomposition is concerned with identifying object classes, their attributes and operationsWhen implemented, objects are created from these classes and some control model used to coordinate object operations29COMP201 - Software EngineeringInvoice Processing System

30COMP201 - Software EngineeringData-Flow ModelsFunctional transformations process their inputs to produce outputsMay be referred to as a pipe and filter model (as in UNIX shell)Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systemsNot really suitable for interactive systems31COMP201 - Software EngineeringInvoice Processing System

32COMP201 - Software Engineering