1.  Repository Model  Client-Server Model  Layered Model  Modular decomposition styles  Object Models  Function Oriented Pipelining  Control Styles 1

2.  Sub-systems must exchange data so that they can work together effectively  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 2

3.  When large amounts of data are to be shared, the repository model of sharing is most commonly used  It is suited to applications where data is generated by sub-system and used by another  Example of this model is CASE tools 3

4. 4

5.  Efficient way to share large amounts of data, there is no need to transmit data explicitly from one sub-system to another  Sub-systems need not be concerned with how data is used by other sub-systems  Activities such as backup, security, and recovery are centralised management  Sharing model is published as the repository schema, which is straightforward to integrate new tools or subsystems that are compatibles with this schema. 5

6.  Sub-systems must agree on a repository data model. Inevitably a compromise between specific needs of each sub-system  Performance may be adversely affected by this compromise  It may be difficult or impossible to integrate new sub-systems if their data models do not fit the agreed schema 6

7.  Data evolution is difficult as a large volume of information is generated according to an agreed data model  So translating this model to a new model will be expensive, it may be difficult or even impossible  Different sub-systems may have different requirements for security, recovery, backup policies, the model forces the same policy on all sub-systems 7

8.  The client-server architectural model is a system model where the system is organised as a set of services and associated servers and clients that access and use the services  It is a distributed system model which shows how data and processing is distributed across a range of components.  The major components of this model are ◦ 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. 8

9. 9

10.  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; 10

11.  The layered model sometimes called an abstract machine  The layered model organises a system into layers, each of which provide a set of services  Each layer can be thought of as an abstract machine whose machine language is defined by the services provided by the layer  This language is used to implement the next level of abstract machine 11

12.  For Example ◦ To implement a programming language ◦ The first layer is high level language ◦ Second layer is the compilation layer ◦ Third layer is translation the compiled language to machine code  When a layer interface changes, only the adjacent layer is affected. 12

13.  Used to model the interfacing of sub- systems  The layered approach supports the incremental development of sub-systems in different layers  An Example of layered Model ◦ Open System Interconnections OSI reference model of network protocol 1980 ◦ ADA Programming Support Environment APSE 1980 13

14.  Information systems have a generic architecture that can be organised as a layered architecture.  Layers include: ◦ The user interface ◦ User communications ◦ Information retrieval ◦ System database

16.  The library system LIBSYS is an example of an information system.

17.  The layered model supports the incremental development of systems.  As a layer is developed, some of the services provided by the layer may be made available to users  This architecture is also changeable and portable, as long as its interface is unchanged, a layer can be replaced by another equivalent layer  A layered systems localize machine dependencies in inner layers, So only the inner, machine dependent layers need to be re-implemented to facilitate different operating system or database 17

18.  It structure the system in a way that can be difficult  Inner layers may provide basic facilities, such as file management that are required at all levels  Services required at the top level may have to punch through adjacent layers to get access to services that are provided several levels beneath it  This subverts the model, as the layer in the system does not just depend on its immediate layer 18

19.  Performance can also be a problem because of it multiple levels of command interpretation  If there are many layers, a services request from a top layer may have to be interpreted several times in different layers before it is processed  To avoid this problem applications may have to communicate directly with inner layers rather than use the services provided by the adjacent layer 19

20.  After an overall system organization has been chosen, you need to make a decision on the approach to be used in decomposition sub- systems into modules  There is not a rigid distinction between system organization and modular decomposition  All previous styles could be applied at this level  The component in modules are usually smaller than sub-systems which allows alternative decomposition styles to be used 20

21.  A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.  Subsystems are decomposed of modules and have defined interfaces which are used for communication with other subsystems  A module is a system component that provides services to other components but would not normally be considered as a separate system. 21

22.  There are two main strategies that can be used when decomposing sub- system into module ◦ Object Oriented Decomposition  Where the system is decomposed into a set of communicating object ◦ Function Oriented Pipelining  Where the system is decomposed into functional modules which transform inputs to outputs. 22

23.  Structure the system into a set of objects with well-defined interfaces  Object-oriented decomposition is concerned with identifying object classes, their attributes and operations  Objects are created from these classes and some control model used to coordinate object operations 23

24. 24  This system can issue invoices to customers, receive payment, and issue receipts for these payments and reminders for unpaid invoices  Dashed arrows indicate that an object uses the attributes or services provided by another object

25.  Objects are loosely coupled so their implementation can be modified without affecting other objects  The objects may reflect real-world entities  OO languages are widely used  However, object interface changes may cause problems and complex entities may be hard to represent as objects. 25

26.  In a function oriented pipeline or data-flow model, function process their inputs to produce outputs  Data flows from one to another and is transformed as it moves through the sequence  Each processing step is called a transform  Input data flows through these transforms until converted to output 26

27.  The transformations may execute sequentially or in parallel  When transformations are sequential, this is a batch sequential model  This model is extensively used in data processing systems such as billing systems  Data-processing systems usually generate many output reports that are derived from simple computations on a large number of input records 27

28. 28  This is an example of this type of architecture  An organization has issued invoices to customers.  Once a week, payments that have been made are reconciled with the invoices ◦ For those invoices that have been paid a receipt is issued ◦ For those invoices that have not been paid within the allowed payment time, a reminder is issued

29.  Supports transformation reuse.  Intuitive for stakeholder communication, many people think of their work in terms of input and output  Easy to add new transformations  Relatively simple to implement as either a concurrent or sequential system.  However, requires a common format for data transfer along the pipeline and difficult to support event- based interaction. 29

30.  Control models are concerned with the control flow between sub-systems.  There are two generic control styles that are used in software systems ◦ Centralised control  One sub-system has overall responsibility for control and starts and stops other sub-systems. ◦ Event-based control  Each sub-system can respond to externally generated events from other sub-systems or the system’s environment. 30

31.  A control sub-system takes responsibility for managing the execution of other sub-systems  Centralized control models fall into two classes, depending on whether the controlled subsystem execute sequentially or in parallel ◦ Call-return model ◦ Manager model 31

32. 32  Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards to the lower level of the tree through a subroutines calls  Applicable to sequential systems.

33. 33  Applicable to concurrent systems  One system component controls the stopping, starting and coordination of other system processes

34.  In centralised control models, control decisions are usually determined by the values of some system state variables  By contrast, event –driven control models are driven by externally generated events  The time of events is outside the control of the process that handles that event 34

35.  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  Other event driven models include spreadsheets and production systems. 35