Software Design. Deriving a solution which satisfies software requirements. Stages of Design. The Design Process. Problem understanding

Transcription

1 Software Design Deriving a solution which satisfies software requirements Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 1 Stages of Design Problem understanding Look at the problem from different angles to discover the design requirements. Identify one or more solutions Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. Describe solution abstractions Use graphical, formal or other descriptive notations to describe the components of the design. Repeat process for each identified abstraction until the design is expressed in primitive terms. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 2 The Design Process Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships. The system should be described at several different levels of abstraction. Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 3

2 Phases in the Design Process Requirements specification Design activities Architectural design Abstract specificatio n Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design products Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 4 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. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 5 Hierarchical Design Structure System level Sub-system level Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 6

3 Top-down Design In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level. In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 7 Design Methods Structured methods are sets of notations for expressing a software design and guidelines for creating a design. Well-known methods include Structured Design (Yourdon), and JSD (Jackson Method). Can be applied successfully because the support standard notations and ensure designs follow a standard form. Structured methods may be supported with CASE tools. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 8 Method Components Many methods support comparable views of a system. A data flow view showing data transformations. An entity-relation view describing the logical data structures. A structural view showing system components and their interactions. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 9

4 Method Deficiencies They are guidelines rather than methods in the mathematical sense. Different designers create quite different system designs. They do not help much with the early, creative phase of design. Rather, they help the designer to structure and document his or her design ideas. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 10 Design Description Graphical notations: Used to display component relationships. Informal text: Natural language description. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 11 Design Strategies Functional design The system is designed from a functional viewpoint. The system state is centralized and shared between the functions operating on that state. Object-oriented design The system is viewed as a collection of interacting objects. The system state is decentralized and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 12

5 Functional View of a Compiler Source program Scan source Tokens Tokens Syntax tree Build symbol table Analyse Generate code Object code Symbols Symbols Error indicator Symbol table Output errors Error messages Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 13 Object-oriented View of a Compiler Source program Scan Token stream Add Symbol table Check Get Syntax tree Build Grammar Print Error messages Generate Abstract code Object code Generate Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 14 Mixed-strategy Design Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary. Good software engineers should select the most appropriate approach for whatever sub-system is being designed. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 15

6 Design Quality Design quality is an elusive concept. Quality depends on specific organizational priorities. A good design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc. The attributes discussed here are concerned with the maintainability of the design. Quality characteristics are equally applicable to function-oriented and object-oriented designs. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 16 Cohesion A measure of how well a component fits together. A component should implement a single logical entity or function. Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component. Various levels of cohesion have been identified. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 17 Cohesion Levels Coincidental cohesion (weak) Parts of a component are simply bundled together. Logical association (weak) Components which perform similar functions are grouped. Temporal cohesion (weak) Components which are activated at the same time are grouped. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 18

7 Cohesion Levels Communicational cohesion (medium) All the elements of a component operate on the same input or produce the same output. Sequential cohesion (medium) The output for one part of a component is the input to another part. Functional cohesion (strong) Each part of a component is necessary for the execution of a single function. Object cohesion (strong) Each operation provides functionality which allows object attributes to be modified or inspected. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 19 Cohesion as a Design Attribute Not well-defined. Often difficult to classify cohesion. Inheriting attributes from super-classes weakens cohesion. To understand a component, the super-classes as well as the component class must be examined. Object class browsers assist with this process. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 20 Coupling A measure of the strength of the interconnections between system components. Loose coupling means component changes are unlikely to affect other components. Shared variables or control information exchange lead to tight coupling. Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing. 28 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 21

8 Tight Coupling Module A Module B Module C Module D Shared data area Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 22 Loose Coupling Module A A s data Module B B s data Module C C s data Module D D s data Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 23 Coupling and Inheritance Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing. However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 24

9 Understandability Related to several component characteristics Can the component be understood on its own? Are meaningful names used? Is the design well-documented? Are complex algorithms used? Informally, high complexity means many relationships between different parts of the design. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide Adaptability A design is adaptable if: Its components are loosely coupled. It is well-documented and the documentation is up to date. There is an obvious correspondence between design levels (design visibility). Each component is a self-contained entity (tightly cohesive). To adapt a design, it must be possible to trace the links between design components so that change consequences can be analyzed. 33 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 26 Design Traceability C A B D F Object interaction level D P O R Object decomposition level Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 27

10 Adaptability and Inheritance Inheritance dramatically improves adaptability. Components may be adapted without change by deriving a sub-class and modifying that derived class. However, as the depth of the inheritance hierarchy increases, it becomes increasingly complex. It must be periodically reviewed and restructured. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide Architectural Design Establishing the overall structure of a software system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 29 Architectural Parallels Architects are the technical interface between the customer and the contractor building the system. A bad architectural design for a building cannot be rescued by good construction; the same is true for software. There are specialist types of building and software architects. There are schools or styles of building and software architecture. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 30

11 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 would not normally be considered as a separate system. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 31 Architectural Models Structure, control and modular decomposition may be based on a particular model or architectural style. However, most systems are heterogeneous in that different parts of the system are based on different models and, in some cases, the system may follow a composite model. The architectural model used affects the performance, robustness, distributability and maintainability of the system. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 32 System Structuring Concerned with decomposing the system into interacting sub-systems. The 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. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 33

12 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 34 CASE Tool Set Architecture Design editor Code generator Design translator Project repository Program editor Design analyser Report generator Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 35 Repository Model Characteristics Advantages: Efficient way to share large amounts of data. Sub-systems need not be concerned with how data is produced. Centralized management e.g., backup, security, etc. Sharing model is published as the repository schema. Disadvantages: Sub-systems must agree on a repository data model. Data evolution is difficult and expensive. No scope for specific management policies. Difficult to distribute efficiently. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 36

13 Client-server Architecture Distributed 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 services. Network which allows clients to access servers. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 37 Film and Picture Library Client 1 Client 2 Client 3 Client 4 Wide-bandwidth network Catalogue server Catalogue Video server Film clip files Picture server Digitized photographs Hypertext server Hypertext web Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 38 Client-server Characteristics Advantages: Distribution of data is straightforward. Makes effective use of networked systems. Easy to add new servers or upgrade existing servers. Disadvantages: No shared data model so sub-systems may use different data organizations. 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 39

14 Abstract Machine Model Used to model the interfacing of sub-systems. Organizes 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 40 Version Management System Version management Object management Database system Operating system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 41 Broadcast Model Effective in integrating sub-systems on different computers in a network. Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event. Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them. However, sub-systems don t know if or when an event will be handled. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 42

15 Selective Broadcasting Sub-system 1 Sub-system 2 Sub-system 3 Sub-system 4 Event and message handler Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 43 Object Models Structure the system into a set of loosely coupled objects with well-defined interfaces. Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. When implemented, objects are created from these classes and some control model used to coordinate object operations. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 44 Invoice Processing System Customer customer # name address credit period Payment invoice # date amount customer # Invoice invoice # date amount customer Issue Send reminder Accept payment Send receipt Receipt invoice # date amount customer # Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 45

16 Pipe and Filter 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 46 Invoice Processing System Issue receipts Receipts Read issued invoices Identify payments Invoices Payments Find payments due Issue payment reminder Reminders Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 47 Domain-specific Architectures Architectural models which are specific to some application domain. 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, idealized model. Provide a means of information about that class of system and of comparing different architectures. Generic models are usually bottom-up models. Reference models are top-down models. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 48

17 Generic Models Compiler model is a well-known example although other models exist in more specialized application domains. Lexical analyzer Symbol table Syntax analyzer Syntax tree Semantic analyzer Code generator Generic compiler model may be organized according to different architectural models. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 49 Compiler Model Symbol table Lexical analysis Syntactic analysis Semantic analysis Code generation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 50 Language Processing System Lexical analyser Syntax analyser Semantic analyser Prettyprinter Abstract syntax tree Grammar definition Optimizer Editor Symbol table Output definition Code generator Repository Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 51

18 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 52 OSI Reference Model 7 Application Application 6 Presentation Presentation 5 Session Session 4 Transport Transport 3 Network Network Network 2 Data link Data link Data link 1 Physical Physical Physical Communications medium Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 53 Distributed Systems Architectures Architectural design for software that executes on more than one processor Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 54

19 Distributed systems Virtually all large computer-based systems are now distributed systems Information processing is distributed over several computers rather than confined to a single machine Distributed software engineering is now very important Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 55 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 56 Distributed system characteristics Resource sharing Openness Concurrency Scalability Fault tolerance Transparency Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 57

20 Distributed system disadvantages Complexity Security Manageability Unpredictability Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 58 Design issue Description Resource The resources in a distributed system are spread across different identification computers and a naming scheme has to be devised so that users can discover and re fer to the resources that they need. An example of such a naming scheme is the URL (Uniform Resource Locator) that is used to identify WWW pages. If a meaningful and universally understood identification scheme is not used then many of these resources will be inaccessible to system users. Communications The universal availability of the Internet and the efficient implementation of Internet TCP/IP communication protocols means that, for most distributed systems, these are the most effective way for the computers to communicate. However, where there are specific requirements for performance, reliability etc. alternative approaches to communications may be used. Quality of service The quality of service offered by a system reflects its performance, availability and reliability. It is affected by a number of factors such as the allocation of processes to processes in the system, the distribution of resources across the system, the network and the system hardware and the adaptability of the system. Software The software architecture describes how the application architectures functionality is distributed over a number of logical components and how these components are distributed across processors. Choosing the right architecture for an application is essential to achieve the desired quality of service. Issues in distributed system design Distributed systems archiectures Client-server architectures Distributed services which are called on by clients. Servers that provide services are treated differently from clients that use services Distributed object architectures No distinction between clients and servers. Any object on the system may provide and use services from other objects Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 60

21 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 converters Communication controllers Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 61 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 preordered or may be under the control of a despatcher Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 62 A multiprocessor traffic control system Sensor processor Traffic flow processor Traffic light control processor Sensor control process Display process Light control process Traffic flow sensors and cameras Operator consoles Traffic lights Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 63

22 Client-server architectures The application is modelled as a set of services that are provided by servers and a set of clients that use these services Clients know of servers but servers need not know of clients Clients and servers are logical processes The mapping of processors to processes is not necessarily 1 : 1 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 64 A client-server system c1 c2 s1 c3 c4 s4 c12 c11 Server process c5 s2 s3 c10 c9 Client process c6 c7 c8 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 65 Computers in a C/S network c1 c2 c3, c4 CC1 CC2 CC3 s1, s2 Network s3, s4 SC2 SC1 Server computer c5, c6, c7 CC4 c8, c9 c10, c11, c12 CC5 CC6 Client computer Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 66

23 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 67 Application layers Presentation layer Application processing layer Data management layer Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 68 Thin and fat clients 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. 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. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 69

24 Thin and fat clients Thin-client model Client Presentation Server Data management Application processing Fat-client model Client Presentation Application processing Server Data management Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 70 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 71 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 72

25 A client-server ATM system ATM ATM Account server ATM Teleprocessing monitor Customer account database ATM Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 73 Three-tier architectures In a three-tier architecture, each of the application architecture layers may execute on a separate processor Allows for better performance than a thin-client approach and is simpler to manage than a fatclient approach A more scalable architecture - as demands increase, extra servers can be added Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 74 A 3-tier C/S architecture Client Presentation Server Application processing Server Data management Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 75

26 An internet banking system Client HTTP interaction Client Web server Account service provision SQL query Database server SQL Customer account database Client Client Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 76 Use of C/S architectures Architecture Applications Two-tier C/S Legacy system applications where separating application architecture with processing and data management is impractical thin clients 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 Applications where application processing is provided by architecture with COTS (e.g. Microsoft Excel) on the client fat clients 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 77 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 78

27 Distributed object architecture o1 o2 o3 o4 S (o1) S (o2) S (o3) S (o4) Software bus o5 S (o5) o6 S (o6) Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 79 Advantages of distributed object architecture It allows the system designer to delay decisions on where and how services should be provided It is a very open system architecture that allows new resources to be added to it as required The system is flexible and scaleable It is possible to reconfigure the system dynamically with objects migrating across the network as required Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 80 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 81

28 A data mining system Database 1 Integrator 1 Report gen. Database 2 Visualiser Integrator 2 Database 3 Display Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 82 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 83 CORBA CORBA is an international standard for an Object Request Broker - middleware to manage communications between distributed objects Several implementations of CORBA are available DCOM is an alternative approach by Microsoft to object request brokers CORBA has been defined by the Object Management Group Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 84

29 Application structure Application objects Standard objects, defined by the OMG, for a specific domain e.g. insurance Fundamental CORBA services such as directories and security management Horizontal (i.e. cutting across applications) facilities such as user interface facilities Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 85 CORBA application structure Application objects Domain facilities Horizontal CORBA facilities Object request broker CORBA services Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 86 CORBA standards An object model for application objects A CORBA object is an encapsulation of state with a welldefined, 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 87

30 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 88 Object request broker (ORB) The ORB handles object communications. It knows of all objects in the system and their interfaces Using an ORB, the calling object binds an IDL stub that defines the interface of the called object Calling this stub results in calls to the ORB which then calls the required object through a published IDL skeleton that links the interface to the service implementation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 89 ORB-based object communications o1 o2 S (o1) S (o2) IDL stub IDL skeleton Object Request Broker Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 90

31 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 same 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 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 91 Inter-ORB communications o1 o2 o3 o4 S (o1) S (o2) S (o3) S (o4) IDL IDL IDL IDL Object Request Broker Object Request Broker Network Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 92 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 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 93

32 Example of a Simple CORBA Application Written in Java Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 94 Starting Clients, Servers, and Name Servers # Compile the IDL into a Java stub idltojava -fno-cpp Hello.idl # Compile the Java program and stub javac *.java HelloApp/*.java # Initiate the name server on king.mcs.drexel.edu on port tnameserv -ORBInitialPort ORBInitialHost king.mcs.drexel.edu # Initiate the hello server (relies on the name server being on king's 1050 port.) java HelloServer -ORBInitialPort ORBInitialHost king.mcs.drexel.edu # Initiate the hello client (relies on the name server being on king's 1050 port.) java HelloClient -ORBInitialPort ORBInitialHost king.mcs.drexel.edu Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 95 Hello World IDL Specification module HelloApp { interface Hello { string sayhello(); }; }; Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 96

33 Hello World Client Java Program import HelloApp.*; import org.omg.cosnaming.*; // package used for name service import org.omg.cosnaming.namingcontextpackage.*; import org.omg.corba.*; public class HelloClient { public static void main(string args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // args contain info. about // name server port/host // get the root naming context org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); NamingContext ncref = NamingContextHelper.narrow(objRef); // casting... // continued on next page... Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 97 Hello World Client Java Program (Cont d) // resolve the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; Hello HelloRef = HelloHelper.narrow(ncRef.resolve(path)); // call the Hello server object and print results String Hello = HelloRef.sayHello(); System.out.println(Hello); } } } catch (Exception e) { System.out.println("ERROR : " + e) ; e.printstacktrace(system.out); } Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 98 Hello World Server Java Program import HelloApp.*; import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; import org.omg.corba.*; class HelloServant extends _HelloImplBase { public String sayhello() { return "\nhello world!!\n"; } } Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 99

34 Hello World Server Java Program (Cont d) public class HelloServer { public static void main(string args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // create servant and register it with the ORB HelloServant HelloRef = new HelloServant(); orb.connect(helloref); // HelloRef will be published... // get the root naming context org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); NamingContext ncref = NamingContextHelper.narrow(objRef); // continued on next slide... Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 100 Hello World Server Java Program (Cont d) // bind the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; ncref.rebind(path, HelloRef); // clobber old binding if any... // wait for invocations from clients java.lang.object sync = new java.lang.object(); synchronized (sync) { // aquires a mutex lock on thread sync.wait(); // server sleeps... } } } } catch (Exception e) { System.err.println("ERROR: " + e); e.printstacktrace(system.out); } Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 5th edition. Chapters 10,11 Slide 101