Lezione 12. Architetture e Design

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

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

3. Architectural design process • System structuring • The system is decomposed into several principal sub-systems and communications between these sub-systems are identified • Control modelling • A model of the control relationships between the different parts of the system is established • Modular decomposition • 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.

4. Sub-systems and modules • A 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 is not considered as a separate system

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

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

7. 1.1 - Repository-based architecture • Sub-systems must exchange data. This may be done in two ways: • Shared data is held in a central database orrepository 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 and control, CAD, CASE Toolset

8. CASE toolset architecture

9. Repository model characteristics • Advantages • 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

10. 1.2 - Client-server architecture • Distributed system model where data and processing are distributed across processors: • Set of stand-alone servers which provide specific services such as printing, filemanagement, 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. • Clients must know the names and nature of the Servers; • Servers need not know the identity and number of Clients. • Can be used to implement a repository-based system • the repository is the (only) server • subsystems accessing the repository are the clients

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

12. Client-server characteristics • Advantages • 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)

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

14. Architecture of a Version Management System

15. OSI architecture (‘reference model’)

16. Reference models are derived from a study of the application domain rather than of a single system • 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

17. Layered architecture characteristics • Advantages • 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.

18. 2. Control policy models • An architectural model identifies subsystems, not the way these are controlled. • Control models are concerned with the control flow among sub-systems. • 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……...).

19. 2.1 - Centralised control • Call-return model • 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.

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

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

22. 2.2 - Event-driven systems • 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 • Broadcast models. • 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

23. Event-driven systems / Broadcast model • Effective in integrating sub-systems on different computers in a network • 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) • 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 • The EMH may support also point to point communication between subsystems

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

25. Broadcast model pros and cons • Advantages • 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

26. Event-driven systems / Interrupt-driven • Used in real-time systems where fast response to an event is essential • Basic idea: (see figure ===>) • 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

28. 3. Design process and techniques • Design is concerned with filling the empty boxes of the architecture • Design addresses another structural level where sub-systems 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

29. Phases in the design process

30. Design phases • 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

31. Structured design methods • 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: • Data flowdiagrams showing data transformations • Entity-relationdiagrams 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.

32. Two fundamental design strategies • Functional design (more traditional) • Starts with high-level view of the system functionality and proceeds primarilytop-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.

33. Functional and Object-Oriented methods • Functional methods • 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] • Object-Oriented methods • Robinson ‘92 - Booch ‘94 • Jacobsen et al. ‘93 • Rumbaugh… ===> Rational Unified Process and UML • Intermediate method • Jackson System Development - JSD [Jackson ‘83]

34. Functional view of a compiler

35. Object-oriented view of a compiler

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

37. Esempio: Aircraft architecture

38. Da Object-Oriented a functional a Object-Oriented • High level architecture: objects • The navigation system • The radar system • The communications system • The instrument display system • The engine control system • System functions (intermediate level) • 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...