Lezione 12 Architetture e Design u S 2001

Lezione 12. Architetture e Design u [S 2001, Capp. 10 -11] u 1. System structuring • • • u 2. Control policy models • • u repository-based client server abstract machines (layered architecture) centralised control event driven systems 3. Design process and techniques 1

Architectural design u Establishing the overall structure of a software system u Architects are the technical interface between the customer and the developer u A bad architectural design for a building cannot be rescued by good construction; the same is true for software. u A bad architecture may prevent the achievement of performance, robustness, distributability, maintainability requirements 2

Architectural design process u System structuring • u Control modelling • u u A model of the control relationships between the different parts of the system is established Modular decomposition • u The system is decomposed into several principal sub-systems and communications between these sub-systems are identified The identified sub-systems are decomposed into modules In pratica, queste attività non sono ordinate temporalmente, per il solito principio del rapido feedback. Anche la fase di specifica formale (concettualmente precedente) puo’ intersecarsi con la definizione dell’architettura. 3

Sub-systems and modules u u A sub-system is a system in its own right whose operation is independent of the services provided by other subsystems. A module is a system component that provides services to other components but is not considered as a separate system 4

1. System structuring u u Concerned with decomposing the system into interacting sub-systems The architectural design is normally expressed as a possibly nested block diagram More specific architectural models showing how subsystems share data, are distributed, and interface with each other may be considered (1. 1 -1. 3) Language: UML!!! (Class, Activity diagrams, subsystems, packages…) 5

Packing robot control system Valore relativo (-> stakeholders) di rappresentazioni box-diagram in cui le frecce non hanno significato preciso. . . 6

1. 1 - Repository-based architecture u Sub-systems must exchange data. This may be done in two ways: • • u 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 is convenient • Examples: Command control, CAD, CASE Toolset 7

CASE toolset architecture 8

Repository model characteristics u Advantages • • u Efficient way to share large amounts of data (write once for all to read) A sub-systems need not be concerned with how data is used/produced by every other subsystem Centralised management of backup, security, access control. . . Sharing model is published as the repository schema ==> easy to add new subsystems Disadvantages • • Sub-systems must agree on a compromise data model ==> lower performance Data evolution (adopting new data model) is difficult and expensive, because: (a) the repository is large, (b) all subsystems must be updated Different subsystem may have different reqs on backup, security… Not supported Difficult (but possible) to distribute on several machines the centralised repository efficiently 9

1. 2 - Client-server architecture u Distributed system model where data and processing are distributed across processors: • • • Set of stand-alone servers which provide specific services such as printing, file management, compiling, etc. Set of clients which call on these services (by remote procedure calls). These are typically concurrent subsystems. Network which allows clients to access servers. u Clients must know the names and nature of the Servers; Servers need not know the identity and number of Clients. u Can be used to implement a repository-based system u • • the repository is the (only) server subsystems accessing the repository are the clients 10

Film and picture library The client program is an ntegrated user-interface to the services Providing links to other servers Transmit quickly, in synchrony, low resolution High resolution, no stringent timing requirements (complementary info) 11

Client-server characteristics u Advantages • • • u Distribution of data is straightforward Makes effective use of networked systems. May require cheaper hardware, exactly sized for specific service Easy to add new servers or upgrade existing servers Disadvantages • • • No shared data model: sub-systems use different data organisation. Data interchange may be inefficient Redundant management (backup, recovery…) in each server No central register of names and services - it may be hard to find out what servers and services are available (in WAN more than in LAN) 12

1. 3 - Abstract machine (layered) architecture u Organises the system into a set of layers, called abstract machines, each of which provide a set of services, representing the abstract machine language u Typically used for compiler systems, to increase platform independency (==>portability) • • Layer 2 - Translator from Java source to Java bytecode (machine-independent) Layer 1 - Translator from Java bytecode to machine code (machine dependent) 13

Architecture of a Version Management System 14

OSI architecture (‘reference model’) 15

u Reference models are derived from a study of the application domain rather than of a single system u May be used as a basis for system implementation or to compare different systems. It acts as a standard against which individual system architectures can be evaluated 16

Layered architecture characteristics u Advantages • • u Supports the incremental development of sub-systems in different layers, by incremental delivery of services. Supports change by minimizing its impact: when a layer interface changes, only the adjacent upper layer is affected Disadvantages • • Basic facilities provided by inner layers (e. g. file management) may be required by several layers up, breaking the model. Performance is reduced by multiple levels of command interpretation. 17

2. Control policy models u u An architectural model identifies subsystems, not the way these are controlled. Control models are concerned with the control flow among subsystems. • • u Centralised control --- One sub-system has overall responsibility for controlling the other subsystems; it starts and stops them Event-based control --- Each sub-system can respond to externally generated events from other sub-systems or from the system’s environment Centralised and event-based control models can be applied to any of the previous architectural models (at least in principle……. . . ). 18

2. 1 - Centralised control u Call-return model • u Applicable to sequential systems. Analogous to Top-down subroutine model of programs, where control starts at the top of a subroutine hierarchy and moves downwards. Manager model • Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. » A process is a subsystem or module which can execute in parallel with other processes. 19

Centralised control / Call-return model (Main subsystem) Modelling system control dynamics, not structure: Subsystem 1. 1 is not necessarily part of Subsystem 1. (Other subsystems) Advantage: Easy to analyse flow of control Disadvantage: Not easy to handle exceptions 20

Centralised control / Manager model Control decisions depend on state variables Adequate for ‘soft’ real time systems. System loops continuously, polling subsystems for events or state changes 21

2. 2 - Event-driven systems u In the previous, centralised-control architectures control decisions depend on system state variables. By contrast, event driven systems are driven by events, generated by the environment or by the subsystems themselves u Broadcast models. • u An event is broadcast to possibly all sub-systems. Any sub-system which can handle the event may do so Interrupt-driven models. • Used in real-time systems where external interrupts are detected by an interrupt handler and passed to some other component for processing 22

Event-driven systems / Broadcast model u Effective in integrating sub-systems on different computers in a network u Sub-systems register an interest in specific events. When these occur, the Event and Message Handler (EMH, p. 24) checks the register and transfers the event and control to the sub-system(s) interested in handling the event (or, possibly, to all of them) u Control policy is not embedded in the EMH, as in central controller of p. 21: sub-systems decide autonomously on events of interest to them u The EMH may support also point to point communication between subsystems 23

- Used for in Softbench (Hewlett-Packard CASE, ‘ 93) - Used in distributed object communication (e. g. in CORBA) 24

Broadcast model pros and cons u Advantages • • u Evolution is simple: a newly added subsystem just informs the event handler of its interest on a subset of events Subsystems activate each other indirectly, by sending events to EMH, and do not have to know their addresses. Distribution is transparent to subsystems Disadvantages • • Subsystems don’t know if/when the events they generate will be handled Conflicts if two subsystems share interests for same event 25

Event-driven systems / Interrupt-driven u Used in real-time systems where fast response to an event is essential u Basic idea: (see figure ===>) • • • u There are known interrupt types with a handler defined for each type Each type is associated with a memory location where the corresponding handler’s address is stored. A fast hardware switch causes immediate transfer of control to the relevant handler, which may in turn activate specific processes. Can be combined with (non-reactive) centralized control model 26

27

3. Design process and techniques u u u Design is concerned with filling the empty boxes of the architecture Design addresses another structural level where subsystems are decomposed into modules Two main modular decomposition techniques (models) • • An object model where the system is decomposed into interacting objects A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model 28

Phases in the design process 29

Design phases u u u Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system interfaces Component design Decompose sub-systems into components Data structure design Design data structures to hold problem data Algorithm design Design algorithms for problem functions 30

Structured design methods u u Structured methods are sets of activities, notations, report formats, design guidelines (good practice), for expressing a software design. Many methods support several system representations and diagram types: • • u Data flow diagrams showing data transformations Entity-relation diagrams describing the logical data structures Structural diagrams showing system components and their interactions In the O-O approach, also inheritance diagrams, and diagrams showing how an object is composed by, and uses other objects. Many methods are supported by CASE tools. 31

Two fundamental design strategies u Functional design (more traditional) • • u Starts with high-level view of the system functionality and proceeds primarily top-down, by refinements (system decomposition). The system state is centralised and shared between the functions operating on that state. (But in Data Flow one can distribute data sources and sinks…) Object-oriented design (more recent) • • • O-O as programming discipline known since early 70’s, but OOA (Analysis) and OOD (Design) widespread since late 80’s. The system is viewed as a collection of interacting objects. Proceeds both top-down and bottom-up (by re-using and combining components). Does not require a single, most abstract system view at the root of the decomposition tree. The system state is de-centralised and each object manages its own state. 32

Functional and Object-Oriented methods u Functional methods • • • u Object-Oriented methods • • • u Stepwise refinement [Wirth ‘ 71, ‘ 76] Jackson Structured Programming ‘ 75 Warnier-Orr ‘ 77 Structured Design (parte di SA/SD: structured analysis, structured design) [Constantine, Yourdon’ 79] SSADM [Cutts ‘ 88, Weaver ‘ 93] Robinson ‘ 92 - Booch ‘ 94 Jacobsen et al. ‘ 93 Rumbaugh… ===> Rational Unified Process and UML Intermediate method • Jackson System Development - JSD [Jackson ‘ 83] 33

Functional view of a compiler 34

Object-oriented view of a compiler 35

Mixed-strategy design u Object-oriented and functional-oriented approach to design are complementary u Good software engineers should select the most appropriate approach for whatever sub-system is being designed u Analogamente, adottando LOTOS come linguaggio di Design, nello stesso progetto possono co-esistere gli stili constraint-oriented, resource-oriented e state -oriented. 36

Esempio: Aircraft architecture 37

Da Object-Oriented a functional a Object-Oriented u High level architecture: objects • • • u System functions (intermediate level) • • • u The navigation system The radar system The communications system The instrument display system The engine control system Display track (radar sub-system) Compensate for wind speed (navigation sub-system) Reduce power (engine sub-system) Indicate emergency (instrument sub-system) Lock onto frequency (communications sub-system) Low-level objects • • The engine status The aircraft position The altimeter The radio beacon. . . 38