Software Architectures-Introduction to Software Engineering-Lecture 07 Slides-Computer Science, Slides of Introduction to Software Engineering

Download Software Architectures-Introduction to Software Engineering-Lecture 07 Slides-Computer Science and more Slides Introduction to Software Engineering in PDF only on Docsity! ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 1 ECE 452- Introduction to Software Engineering Lecture 7: Software Architectures (I. Sommerville) Manish Parashar parashar@ece.rutgers.edu Department of Electrical & Computer Engineering Rutgers University ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 2 Architectural Design ● Establishing the overall structure of a software system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 5 Software architecture ● The design process for identifying the sub- systems making up a system and the framework for sub-system control and communication is architectural design ● The output of this design process is a description of the software architecture ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 6 Architectural design ● An early stage of the system design process ● Represents the link between specification and design processes ● Often carried out in parallel with some specification activities ● It involves identifying major system components and their communications ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 7 Advantages of explicit architecture ● Stakeholder communication • Architecture may be used as a focus of discussion by system stakeholders ● System analysis • Means that analysis of whether the system can meet its non- functional requirements is possible ● Large-scale reuse • The architecture may be reusable across a range of systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 10 Architectural models ● Different architectural models may be produced during the design process ● Each model presents different perspectives on the architecture ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 11 Architectural models ● Static structural model that shows the major system components ● Dynamic process model that shows the process structure of the system ● Interface model that defines sub-system interfaces ● Relationships model such as a data-flow model ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 12 Architectural styles ● The architectural model of a system may conform to a generic architectural model or style ● An awareness of these styles can simplify the problem of defining system architectures ● However, most large systems are heterogeneous and do not follow a single architectural style ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 15 Packing robot control system Vision system Object identification system Arm controller Gripper controller Packaging selection system Packing system Conveyor controller ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 16 The repository model ● 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 ● When large amounts of data are to be shared, the repository model of sharing is most commonly used ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 17 CASE toolset architecture Project repository Design translator Program editor Design editor Code generator Design analyser Report generator ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 20 Film and picture library Catalogue server Catalogue Video server Film clip files Picture server Digitized photographs Hypertext server Hypertext web Client 1 Client 2 Client 3 Client 4 Wide-bandwidth network ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 21 Client-server characteristics ● 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 ● 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 22 Abstract machine model ● Used to model the interfacing of sub-systems ● Organises the system into a set of layers (or abstract machines) each of which provide a set of services ● Supports the incremental development of sub- systems in different layers. When a layer interface changes, only the adjacent layer is affected ● However, often difficult to structure systems in this way ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 25 Centralised control ● A control sub-system takes responsibility for managing the execution of other sub-systems ● Call-return model • Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems ● 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 26 Call-return model Routine 1.2Routine 1.1 Routine 3.2Routine 3.1 Routine 2 Routine 3Routine 1 Main program ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 27 Real-time system control System controller User interface Fault handler Computation processes Actuator processes Sensor processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 30 Selective broadcasting Sub-system 1 Event and message handler Sub-system 2 Sub-system 3 Sub-system 4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 31 Interrupt-driven systems ● Used in real-time systems where fast response to an event is essential ● There are known interrupt types with a handler defined for each type ● Each type is associated with a memory location and a hardware switch causes transfer to its handler ● Allows fast response but complex to program and difficult to validate ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 32 Interrupt-driven control Handler 1 Handler 2 Handler 3 Handler 4 Process 1 Process 2 Process 3 Process 4 Interrupts Interrupt vector ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 35 Invoice processing system issue () sendReminder () acceptPayment () sendReceipt () invoice# date amount customer Invoice invoice# date amount customer# Receipt invoice# date amount customer# Payment customer# name address credit period Customer ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 36 Data-flow models ● Functional transformations process their inputs to produce outputs ● May 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 systems ● Not really suitable for interactive systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 37 Invoice processing system Read issued invoices Identify payments Issue receipts Find payments due Receipts Issue payment reminder Reminders Invoices Payments ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 40 Compiler model Lexical analysis Syntactic analysis Semantic analysis Code generation Symbol table ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 41 Language processing system Syntax analyser Lexical analyser Semantic analyser Abstract syntax tree Grammar definition Symbol table Output definition Pretty- printer Editor Optimizer Code generator Repository ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 42 Reference architectures ● Reference models are derived from a study of the application domain rather than from existing systems ● 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 ● OSI model is a layered model for communication systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 45 Key points ● Modular decomposition models include data-flow and object models ● 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 46 Distributed Systems Architectures Architectural design for software that executes on more than one processor ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 47 Objectives ● To explain the advantages and disadvantages of distributed systems architectures ● To describe different approaches to the development of client-server systems ● To explain the differences between client-server and distributed object architectures ● To describe object request brokers and the principles underlying the CORBA standards ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 50 System types ● Personal systems that are not distributed and that are designed to run on a personal computer or workstation. ● Embedded systems that run on a single processor or on an integrated group of processors. ● Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 51 Distributed system characteristics ● Resource sharing ● Openness ● Concurrency ● Scalability ● Fault tolerance ● Transparency ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 52 Distributed system disadvantages ● Complexity ● Security ● Manageability ● Unpredictability ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 55 Middleware ● Software that manages and supports the different components of a distributed system. In essence, it sits in the middle of the system ● Middleware is usually off-the-shelf rather than specially written software ● Examples • Transaction processing monitors • Data convertors • Communication controllers ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 56 Multiprocessor architectures ● Simplest distributed system model ● System composed of multiple processes which may (but need not) execute on different processors ● Architectural model of many large real-time systems ● Distribution of process to processor may be pre- ordered or may be under the control of a despatcher ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 57 A multiprocessor traffic control system Traffic lights Light control process Traffic light control processor Traffic flow processor Operator consoles Traffic flow sensors and cameras Sensor processor Sensor control process Display process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 60 Computers in a C/S network Network SC1SC2 CC1 CC2 CC3 CC5 CC6CC4 Server computer Client computer s1, s2 s3, s4 c5, c6, c7 c1 c2 c3, c4 c8, c9 c10, c11, c12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 61 Layered application architecture ● Presentation layer • Concerned with presenting the results of a computation to system users and with collecting user inputs ● Application processing layer • Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc. ● Data management layer • Concerned with managing the system databases ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 62 Application layers Presentation layer Application processing layer Data management layer ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 65 Thin client model ● 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 ● A major disadvantage is that it places a heavy processing load on both the server and the network ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 66 Fat client model ● More processing is delegated to the client as the application processing is locally executed ● Most suitable for new C/S systems where the capabilities of the client system are known in advance ● More complex than a thin client model especially for management. New versions of the application have to be installed on all clients ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 67 A client-server ATM system Account server Customer account database Tele- processing monitor ATM ATM ATM ATM ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 70 An internet banking system Database server Customer account database Web server Client Client Client Client Account service provision SQL SQL query HTTP interaction ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 71 Use of C/S architectures Architecture Applications Two-tier C/S architecture with thin clients Legacy system applications where separating application processing and data management is impractical Computationally-intensive applications such as compilers with little or no data management Data-intensive applications (browsing and querying) with little or no application processing. Two-tier C/S architecture with fat clients Applications where application processing is provided by COTS (e.g. Microsoft Excel) on the client Applications where computationally-intensive processing of data (e.g. data visualisation) is required. Applications with relatively stable end-user functionality used in an environment with well-established system management Three-tier or multi-tier C/S architecture Large scale applications with hundreds or thousands of clients Applications where both the data and the application are volatile. Applications where data from multiple sources are integrated ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 72 Distributed object architectures ● There is no distinction in a distributed object architectures between clients and servers ● Each distributable entity is an object that provides services to other objects and receives services from other objects ● Object communication is through a middleware system called an object request broker (software bus) ● However, more complex to design than C/S systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 75 Uses of distributed object architecture ● As a logical model that allows you to structure and organise the system. In this case, you think about how to provide application functionality solely in terms of services and combinations of services ● As a flexible approach to the implementation of client-server systems. The logical model of the system is a client-server model but both clients and servers are realised as distributed objects communicating through a software bus ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 76 A data mining system Database 1 Database 2 Database 3 Integrator 1 Integrator 2 Visualiser Display Report gen. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 77 Data mining system ● The logical model of the system is not one of service provision where there are distinguished data management services ● It allows the number of databases that are accessed to be increased without disrupting the system ● It allows new types of relationship to be mined by adding new integrator objects ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 80 CORBA application structure CORBA services Object request broker Domain facilities Horizontal CORBA facilities Application objects ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 81 CORBA standards ● An object model for application objects • A CORBA object is an encapsulation of state with a well- defined, language-neutral interface defined in an IDL (interface definition language) ● An object request broker that manages requests for object services ● A set of general object services of use to many distributed applications ● A set of common components built on top of these services ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 82 CORBA objects ● CORBA objects are comparable, in principle, to objects in C++ and Java ● They MUST have a separate interface definition that is expressed using a common language (IDL) similar to C++ ● There is a mapping from this IDL to programming languages (C++, Java, etc.) ● Therefore, objects written in different languages can communicate with each other ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 85 Inter-ORB communications ● ORBs are not usually separate programs but are a set of objects in a library that are linked with an application when it is developed ● ORBs handle communications between objects executing on the sane machine ● Several ORBS may be available and each computer in a distributed system will have its own ORB ● Inter-ORB communications are used for distributed object calls ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 86 Inter-ORB communications o1 o2 S (o1) S (o2) IDL IDL Object Request Broker o3 o4 S (o3) S (o4) IDL IDL Object Request Broker Network ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 87 CORBA services ● Naming and trading services • These allow objects to discover and refer to other objects on the network ● Notification services • These allow objects to notify other objects that an event has occurred ● Transaction services • These support atomic transactions and rollback on failure