Presentation is loading. Please wait.

Presentation is loading. Please wait.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.

Similar presentations


Presentation on theme: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design."— Presentation transcript:

1 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design

2 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 2 Architectural Design l Establishing the overall structure of a software system

3 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 3 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures

4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 4 Software architecture l The design process for identifying the sub- systems making up a system and the framework for sub-system control and communication is architectural design l The output of this design process is a description of the software architecture

5 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 5 Architectural design l An early stage of the system design process l Represents the link between specification and design processes l Often carried out in parallel with some specification activities l It involves identifying major system components and their communications

6 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 6 Advantages of explicit architecture l Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders l System analysis Means that analysis of whether the system can meet its non- functional requirements is possible l Large-scale reuse The architecture may be reusable across a range of systems

7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 7 Architectural design process l System structuring The system is decomposed into several principal sub-systems and communications between these sub-systems are identified l Control modelling A model of the control relationships between the different parts of the system is established l Modular decomposition The identified sub-systems are decomposed into modules

8 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 8 Sub-systems and modules l A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. l A module is a system component that provides services to other components but would not normally be considered as a separate system

9 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 9 Architectural models l Different architectural models may be produced during the design process l Each model presents different perspectives on the architecture

10 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 10 Architectural models l Static structural model that shows the major system components l Dynamic process model that shows the process structure of the system l Interface model that defines sub-system interfaces l Relationships model such as a data-flow model

11 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 11 Architectural styles l The architectural model of a system may conform to a generic architectural model or style l An awareness of these styles can simplify the problem of defining system architectures l However, most large systems are heterogeneous and do not follow a single architectural style

12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 12 Architecture attributes l Performance Localise operations to minimise sub-system communication l Security Use a layered architecture with critical assets in inner layers l Safety Isolate safety-critical components l Availability Include redundant components in the architecture l Maintainability Use fine-grain, self-contained components

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 13 System structuring l Concerned with decomposing the system into interacting sub-systems l The architectural design is normally expressed as a block diagram presenting an overview of the system structure l More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed

14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 14 Packing robot control system

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 15 The repository model l Sub-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-systems Each sub-system maintains its own database and passes data explicitly to other sub-systems l When large amounts of data are to be shared, the repository model of sharing is most commonly used

16 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 16 CASE toolset architecture

17 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 17 Repository model characteristics l Advantages Efficient way to share large amounts of data Sub-systems need not be concerned with how data is produced Centralised management e.g. backup, security, etc. Sharing model is published as the repository schema l Disadvantages Sub-systems must agree on a repository data model. Inevitably a compromise Data evolution is difficult and expensive No scope for specific management policies Difficult to distribute efficiently

18 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 18 Client-server architecture l Distributed system model which shows how data and processing is distributed across a range of components l Set of stand-alone servers which provide specific services such as printing, data management, etc. l Set of clients which call on these services l Network which allows clients to access servers

19 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 19 Film and picture library

20 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 20 Client-server characteristics l Advantages Distribution of data is straightforward Makes effective use of networked systems. May require cheaper hardware Easy to add new servers or upgrade existing servers l Disadvantages No shared data model so sub-systems use different data organisation. data interchange may be inefficient Redundant management in each server No central register of names and services - it may be hard to find out what servers and services are available

21 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 21 Abstract machine model l Used to model the interfacing of sub-systems l Organises the system into a set of layers (or abstract machines) each of which provide a set of services l Supports the incremental development of sub- systems in different layers. When a layer interface changes, only the adjacent layer is affected l However, often difficult to structure systems in this way

22 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 22 Version management system

23 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 23 Control models l Are concerned with the control flow between sub-systems. Distinct from the system decomposition model l Centralised control One sub-system has overall responsibility for control and starts and stops other sub-systems l Event-based control Each sub-system can respond to externally generated events from other sub-systems or the systems environment

24 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 24 Centralised control l A control sub-system takes responsibility for managing the execution of other sub-systems l Call-return model Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems l Manager model Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement

25 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 25 Call-return model

26 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 26 Real-time system control

27 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 27 Event-driven systems l Driven by externally generated events where the timing of the event is outwith the control of the sub-systems which process the event l 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 so Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing l Other event driven models include spreadsheets and production systems

28 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 28 Broadcast model l Effective in integrating sub-systems on different computers in a network l Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event l Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them l However, sub-systems dont know if or when an event will be handled

29 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 29 Selective broadcasting

30 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 30 Interrupt-driven systems l Used in real-time systems where fast response to an event is essential l There are known interrupt types with a handler defined for each type l Each type is associated with a memory location and a hardware switch causes transfer to its handler l Allows fast response but complex to program and difficult to validate

31 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 31 Interrupt-driven control

32 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 32 Modular decomposition l Another structural level where sub-systems are decomposed into modules l Two modular decomposition models covered 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 l If possible, decisions about concurrency should be delayed until modules are implemented

33 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 33 Object models l Structure the system into a set of loosely coupled objects with well-defined interfaces l Object-oriented decomposition is concerned with identifying object classes, their attributes and operations l When implemented, objects are created from these classes and some control model used to coordinate object operations

34 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 34 Invoice processing system

35 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 35 Data-flow models l Functional transformations process their inputs to produce outputs l May be referred to as a pipe and filter model (as in UNIX shell) l Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems l Not really suitable for interactive systems

36 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 36 Invoice processing system

37 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 37 Domain-specific architectures l Architectural models which are specific to some application domain l Two types of domain-specific model Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems Reference models which are more abstract, idealised model. Provide a means of information about that class of system and of comparing different architectures l Generic models are usually bottom-up models; Reference models are top-down models

38 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 38 Generic models l Compiler model is a well-known example although other models exist in more specialised application domains Lexical analyser Symbol table Syntax analyser Syntax tree Semantic analyser Code generator l Generic compiler model may be organised according to different architectural models

39 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 39 Compiler model

40 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 40 Language processing system

41 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 41 Reference architectures l Reference models are derived from a study of the application domain rather than from existing systems l May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated l OSI model is a layered model for communication systems

42 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 42 OSI reference model Application

43 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 43 Key points l The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model l Large systems rarely conform to a single architectural model l System decomposition models include repository models, client-server models and abstract machine models l Control models include centralised control and event-driven models

44 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 44 Key points l Modular decomposition models include data- flow and object models l Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models

45 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 45 Distributed Systems Architectures l Architectural design for software that executes on more than one processor

46 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 46 Topics covered l Multiprocessor architectures l Client-server architectures l Distributed object architectures l CORBA

47 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 47 Distributed systems l Virtually all large computer-based systems are now distributed systems l Information processing is distributed over several computers rather than confined to a single machine l Distributed software engineering is now very important

48 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 48 System types l Personal systems that are not distributed and that are designed to run on a personal computer or workstation. l Embedded systems that run on a single processor or on an integrated group of processors. l Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network.

49 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 49 Distributed system characteristics l Resource sharing l Openness l Concurrency l Scalability l Fault tolerance l Transparency

50 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 50 Distributed system disadvantages l Complexity l Security l Manageability l Unpredictability

51 Issues in distributed system design

52 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 52 Distributed systems archiectures l Client-server architectures Distributed services which are called on by clients. Servers that provide services are treated differently from clients that use services l Distributed object architectures No distinction between clients and servers. Any object on the system may provide and use services from other objects

53 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 53 Middleware l Software that manages and supports the different components of a distributed system. In essence, it sits in the middle of the system l Middleware is usually off-the-shelf rather than specially written software l Examples Transaction processing monitors Data convertors Communication controllers

54 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 54 Multiprocessor architectures l Simplest distributed system model l System composed of multiple processes which may (but need not) execute on different processors l Architectural model of many large real-time systems l Distribution of process to processor may be pre- ordered or may be under the control of a despatcher

55 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 55 A multiprocessor traffic control system

56 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 56 Client-server architectures l The application is modelled as a set of services that are provided by servers and a set of clients that use these services l Clients know of servers but servers need not know of clients l Clients and servers are logical processes l The mapping of processors to processes is not necessarily 1 : 1

57 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 57 A client-server system

58 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 58 Computers in a C/S network

59 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 59 Layered application architecture l Presentation layer Concerned with presenting the results of a computation to system users and with collecting user inputs l Application processing layer Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc. l Data management layer Concerned with managing the system databases

60 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 60 Application layers

61 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 61 Thin and fat clients l Thin-client model In a thin-client model, all of the application processing and data management is carried out on the server. The client is simply responsible for running the presentation software. l Fat-client model In this model, the server is only responsible for data management. The software on the client implements the application logic and the interactions with the system user.

62 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 62 Thin and fat clients

63 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 63 Thin client model l Used when legacy systems are migrated to client server architectures. The legacy system acts as a server in its own right with a graphical interface implemented on a client l A major disadvantage is that it places a heavy processing load on both the server and the network

64 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 64 Fat client model l More processing is delegated to the client as the application processing is locally executed l Most suitable for new C/S systems where the capabilities of the client system are known in advance l More complex than a thin client model especially for management. New versions of the application have to be installed on all clients

65 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 65 A client-server ATM system

66 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 66 Three-tier architectures l In a three-tier architecture, each of the application architecture layers may execute on a separate processor l Allows for better performance than a thin-client approach and is simpler to manage than a fat- client approach l A more scalable architecture - as demands increase, extra servers can be added

67 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 67 A 3-tier C/S architecture

68 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 68 An internet banking system

69 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 69 Use of C/S architectures

70 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 70 Distributed object architectures l There is no distinction in a distributed object architectures between clients and servers l Each distributable entity is an object that provides services to other objects and receives services from other objects l Object communication is through a middleware system called an object request broker (software bus) l However, more complex to design than C/S systems

71 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 71 Distributed object architecture

72 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 72 Advantages of distributed object architecture l It allows the system designer to delay decisions on where and how services should be provided l It is a very open system architecture that allows new resources to be added to it as required l The system is flexible and scaleable l It is possible to reconfigure the system dynamically with objects migrating across the network as required

73 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 73 l Almost all new large systems are distributed systems l Distributed systems support resource sharing, openness, concurrency, scalability, fault tolerance and transparency l Client-server architectures involve services being delivered by servers to programs operating on clients l User interface software always runs on the client and data management on the server Key points

74 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 74 Key points l In a distributed object architecture, there is no distinction between clients and servers l Distributed object systems require middleware to handle object communications l The CORBA standards are a set of middleware standards that support distributed object architectures


Download ppt "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design."

Similar presentations


Ads by Google