13.

SYSTEM DESIGN
1. The major elements of system Design
The system design activity specifies the context within which detailed design will occur. A major part of system design is defining the system architecture. The meaning and scope of the term architecture for computerized information systems is much debated but it is generally accepted that it is an important feature of the delivered system. The architecture of a system is concerned with its overall structure, the relationships among its major components and their interactions. If the system being considered contains human, software and hardware elements then its architecture includes how these elements are structured and how they interact. On the other hand, if the system being considered comprises software and hardware, then its architecture only concerns these elements. It is important to consider the structure of the software elements of the system and this is termed the software architecture. The hardware architecture of a system describes computers and peripherals required for the system and how software is allocated to them.

The architecture of the information system is first considered early in the project during the requirements capture and analysis activities. This first view of the system architecture is driven significantly by the use cases and then informs the continuing requirements capture and analysis activities. This forms a useful basis from which to develop the design architecture. The detailed software architecture of a computerized information system develops as the design process continues into object design but it is important to identify an overall system architecture within which the detail can be refined. Highlevel architectural decisions that are made during system design determine how successfully the system will meet its non-functional objectives (e.g. performance, extensibility) and thus its long-term utility for the client.

Reuse is one of the much wanted benefits of object-orientation and poor software architecture usually reduces both the reusability of the components produced and the opportunity to reuse existing components.

During system design we need to consider the following activities. Sub-systems and major components are identified. Any inherent concurrency is identified. Sub-systems are allocated to processors. A data management strategy is selected. A strategy and standards for human-computer interaction are chosen. Code development standards are specified. The control aspects of the application are planned. Test plans are produced. Priorities are set for design trade-offs. Implementation requirements are identified (for example, data conversion).

2. Software Architecture
Software architecture, like system architecture has no generally agreed definition and can be interpreted differently depending upon the context. According to Booch , the architecture of a system is its class structure. He suggests that part of the architecture is the way in which classes are grouped together. Rumbaugh use the term system architecture to describe the overall organization of a system into sub-systems.

A software architecture is a description of the sub-systems and components of a software system and the relationships between them. Subsystems and components are typically specified in different views to show the relevant functional and non-functional properties of a software system. Software architecture is the result of the software design activity. According to Soni , identified the following four different aspects of software architecture as shown below. Type of architecture Conceptual Module Code Execution Examples of elements Components Sub-systems, modules Files, Directories, libraries Tasks, threads, object interactions Examples of relationships Connectors Exports, imports Includes, contains Uses, calls

The conceptual architecture is concerned with the structure of the static class model and the connections between the components of the model. The module architecture describes the way the system is divided into sub-systems or modules and how they communicate by exporting and importing data. The code architecture defines how the program code is organized into files and directories and grouped into libraries. The execution architecture focuses on the dynamic
aspects of the system and the communication between components as tasks and operations execute. There are alternative ways of giving different aspects of architecture. For example, a logical architecture might comprise the class model, while a physical architecture is concerned with mapping the software onto the hardware components. However, in all cases these different aspects combine to define a software architecture for the system. There are various architectural styles, each of which has characteristics that make it more or less suitable for certain types of application.

Sub-systems
A sub-system typically groups together elements of the system that share some common properties. An object-oriented sub-system encapsulates a coherent set of responsibilities in order to ensure that it has integrity and can be maintained. For example, the elements of one sub-system deals about human-computer interface, the elements of another may deals about data management and the elements of a third may all focus on a particular functional requirement.

The division of an information system into sub-systems has the following advantages. It produces smaller units of development. It helps to maximize reuse at the component level. It helps the developers to cope with complexity. It improves maintainability. It aids portability. Each sub-system should have a clearly specified boundary and fully defined interfaces with other sub-systems. A specification for the interface of a sub-system defines the precise nature of the sub-system's interaction with the rest of the system but does not describe its internal structure . A sub-system can be designed and constructed independently of other sub-systems, simplifying the development process. Sub-systems may correspond to increments of development that can be delivered individually as part of an incremental life cycle also.

Dividing a system into sub-systems is an effective strategy for handling complexity. Sometimes it is only feasible to model a large complex system piece by piece, with the sub-division forced on the developers by the nature of the application. Splitting a system into sub-systems can also aid reuse as each sub-system may correspond to a component that is suitable for reuse in other applications.

Each sub-system provides services for other sub-systems, and there are two different styles of communication that make this possible. These are known as client-server and peer-to-peer communication and are shown below.

Sub-system A
<< client>>

Sub-system C
<<peer>>

Sub-system B
<<server>>

Sub-system D
<<peer>>

The server sub-system does not depend on the client subsystem and is not affected by changes to the client's interface.

Each peer sub-system depends on the other and each is affected by changes in the other's interface

Client-server communication requires the client to know the interface of the server sub-system, but the communication is only in one direction. The client sub-system requests services from the server sub-system and not vice versa. Peer-to-peer communication requires each sub-system to know the interface of the other, thus coupling them more tightly. The communication is two way since either peer subsystem may request services from the other. In general client-server communication is simpler to implement and to maintain, as the sub-systems are less tightly coupled than they are when peer-to-peer communication is used. In Figure the sub-systems are represented using packages that have been stereotyped to indicate their role. Component and deployment diagrams can also be used to model the implementation of sub-systems .

Layering and partitioning

There are two general approaches to the division of a software system into sub-systems. These are known as 1. Layering - so called because the different sub-systems usually represent different levels of abstraction 2. Partitioning - which usually means that each sub-system focuses on a different aspect of the functionality of the system as a whole. In practice both approaches are often used together on one system, so that some of its sub-systems are divided by layering, while others are divided by partitioning.

1. Layered sub-systems
Layered architectures are used to specify high-level structures for a system. A schematic of the general structure is shown below.
Schematic of a layered architecture

Layer N Layer N-1

Layer N Layer N-1

Layer2 Layer1 Closed architecture messages may only be sent to the adjacent lower layer.

Layer2 Layer1 Open architecture messages can be sent to any lower layer

Each layer corresponds to one or more sub-systems, which may be differentiated from each other by differing levels of abstraction or by a different focus of their functionality. In this architecture , the top layer uses services provided by the layer immediately below it. This in turn may require the services of the next layer down. Layered architectures can be either open or closed, and each has its particular advantages. In a closed layered architecture a certain layer (say layer N) can only use the services of the layer immediately below it (layer N - 1). In an open layered architecture layer N may directly use the services of any of the layers that lie below it.

A closed architecture minimizes dependencies between the layers and reduces the impact of a change to the interface of anyone layer. An open layered architecture produces more compact code since the services of all lower level layers can be accessed directly by any layer above them without the need for extra program code to pass messages through each intervening layer. However this breaks the encapsulation of the layers, increases the dependencies between layers and increases the difficulty caused when a layer needs to be changed. \
Networking protocols provide some of the best known examples of layered architectures. Eg: The OSI (Open Systems Interconnection) 7 Layer Model was defined by the International Standardization Organization (ISO) as a standard architectural model for network protocols

Buschmann suggests that a series of issues need to be addressed when applying a layered architecture for an application. These includes: Maintaining the stability of the interfaces of each layer; The construction of other systems using some of the lower layers; Variations in the appropriate level of granularity for sub-systems; The further sub-division of complex layers; Performance reductions due to a closed layered architecture. The following steps are adapted from Buschmann , and provide an outline process for the development of a layered architecture for an application. These steps offers guidelines on the issues that need to be addressed during the development of a layered architecture. 1. Define the criteria by which the application will be grouped into layers A commonly used criteria is level of abstraction from the hardware. The lowest layer provides primitive services for direct access to the hardware while the layers above provide more complex services that are based upon these primitives. Higher layers in the architecture carry out tasks that are more complex and correspond to concepts that occur in the application domain . 2. Determine the number of layers - Too many layers will introduce unnecessary overheads while too few will result in a poor structure.

3. Name the layers and assign functionality to them - The top layer should be concerned with the main system functions as perceived by the user. The layers below should provide services and infrastructure that enable the delivery of the functional requirements. 4. Specify the services for each layer. In general it is better in the lower layers to have a small number of low-level services that are used by a larger number of services in higher layers. 5. Refine the layering by iterating through steps 1 to 4. 6. Specify interfaces for each layer. 7. Specify the structure of each layer. This may involve partitioning within the layer

8. Specify the communication between adjacent layers.

9. Reduce the coupling between adjacent layers - This effectively means that each layer should be strongly encapsulated. Where a client-server communication protocol will be used, each layer should have knowledge only of the layer immediately below it. One of the simplest application architectures has only two layersthe application layer and a database layer. Tight coupling between the user interface and the data representation would make it more difficult to modify either independently, so a middle layer is often introduced in order to separate the conceptual structure of the problem domain.

This gives the architecture shown in the following Figure , which is commonly used for business-oriented information systems. It is same as the threetier architecture (user interface, business objects and database tiers).

Presentation Business Logic Database

Three layer architecture

The following figure, four layer architecture separates the business logic layer into application logic and domain layers.

Presentation Application Logic Domain Database

The approach which is used during the analysis activity of use case realization results in the identification of boundary, control and entity classes and it is easy to map the boundary classes onto a presentation layer, the control classes onto an application logic layer and the entity classes on a domain layer. Thus from an early stage in the development of an information system some of element of layering is being introduced into the software architecture. However, it is important to appreciate that as we move through design, the allocation of responsibility amongst these types of class may be adjusted to accommodate non-functional requirements . A good design solution is one that balances competing requirements effectively.

2. Partitioned sub-systems
In the design phase , some layers within a layered architecture may have to be decomposed because of their complexity. The following figure shows a four layer architecture for part of Agate's campaign management system that also has some partitioning in the upper layers. A single Advert HCL Campaign costs Presentation Layer domain Sub-system HCL Sub-system Layer Advert Campaign costs Application Layer supports sub-system sub-system two Campaign domain application Campaign database
subsystems

In this, the application layer corresponds to the analysis class model for a single application, and is partitioned into a series of sub-systems. These subsystems are loosely coupled and each should deliver a single service or coherent group of services. The Campaign Database layer provides access to a database that contains all the details of the campaigns, their adverts and the campaign teams. The Campaign Domain layer uses the lower layer to retrieve and store data in the database and provides common domain functionality for the layers above. For example, the Advert sub-system might support individual advert costing while the Campaign Costs sub-system uses some of the same common domain functionality when costing a complete campaign. Each application sub-system has its own presentation layer to cater for the differing interface needs of different user roles. A system may be split into sub-systems during analysis because of the system's size and complexity. However, the analysis sub-systems should be reviewed during design for coherence and compatibility with the overall system architecture. The sub-systems that result from partitioning should have clearly defined boundaries and well specified interfaces, thus providing high levels of encapsulation so that the implementation of an individual sub-system may be varied without causing dependent changes in the other sub-systems.

Model-View-Controller Architecture
Many interactive systems uses the Model-View-Controller (MVC) architecture. This structure is capable of supporting user requirements that are presented through differing interface styles, and it aids maintainability and portability. The MVC architecture separates an application into three major types of component: 1.Models that comprise the main functionality, 2. Views that present the user interface, 3. Controllers that manage the updates to views. It is common for the view of an information system that is required for each user to differ according to their role. This means that the data and functionality available to any user should be customized to his or her needs. The needs of different types of users can also change at varying rates. For these reasons provide access to each user separately, only to the relevant part of the functionality of the system as a whole.

For example, in the Agate case study many users need access to information about campaigns, but their perspectives vary. The campaign manager needs to know about the current progress of a campaign and concerned with the current state of each advertisement and how this impacts on the campaign as a whole-is it prepared and ready to run, or is it still in the preparation stage? If an advert is behind schedule does this affect other aspects of the campaign? The creative artist also needs access to adverts but he is likely to need access to the contents of the advert as well as some scheduling information. A director may wish to know about the state of all live campaigns and their projected income over the next six months. This gives at least three different perspectives on campaigns and adverts, each of which might use different styles of display. The director may require charts and graphs that summarize the current position at quite a high level. The campaign manager may require lower level summaries that are both textual and graphical in form. The graphic designer may require detailed textual displays of notes with a capability to display graphical images of an adverts content. Ideally, if any information about a campaign or an advert is updated in one view then the changes should also be reflected immediately in all other views.

The following figure shows a possible architecture with multiple interfaces for the same core functionality, but some problems remain.
Changes to data in one sub-system Need to be propagated to the others.

Each sub-system contains some core functionality

Campaign Forecasting

Advert Development Campaign Management

Campaign and Advert Database Access

The following are some of the difficulties that need to be resolved for this type of application. The same information should be capable of presentation in different formats in different windows. Changes made within one view should be reflected immediately in the other views. Changes in the user interface should be easy to make. Core functionality should be independent of the interface to enable multiple interface styles to co-exist.

The MVC architecture solves this type of problems through its separation of core functionality (model) from the interface and through its incorporation of a mechanism for propagating updates to other views. The interface itself is split into two elements: the output presentation (view) and the input controller (controller). The following figure shows the basic general structure of the Model View Controller. The propagation mechanism
<<propogate>> View A <<propogate>> View B

<<access>> <<access>> Model <<access>> <<access>>

<<access>> controller A

<<access>> Controller B

The responsibilities of the components of an MVC architecture are Model - The model provides the central functionality of the application and is aware of each of its dependent view and controller components . View - Each view corresponds to a particular style and format of presentation of information to the user. The view retrieves data from the model and updates its presentations when data has been changed in one of the other views. The view creates its associated controller. Controller - The controller accepts user input in the form of events that trigger the execution of operations within the model. These may cause changes to the information and in turn trigger updates in all the views ensuring that they are all up to date. Propagation Mechanism - This enables the model to inform each view that the model data has changed and as a result the view must update itself. It is also often called the dependency mechanism.

The following figure represents the capabilities offered by the different MVC components as they might be applied to part of the campaign management system at Agate.

The operation update () in the AdvertView and AdvertController components triggers these components to request data from the CampaignModel component. This model component has no knowledge of the way that each view and controller component will use its services. It need only know that all view and controller components must be informed whenever there is a change of state. The attach () and detach () services in the CampaignModel component enable views and controllers to be added to the setOfObservers. This contains a list of all components that must be informed of any change to the model core data. Generally there would be separate views, each with its own controller, to support the requirements of the campaign manager and the director.

The following interaction sequence diagram gives the communication that is involved in the operation of an MVC architecture.

MVC component interaction

:Advertcontroller

:CampaignModel

:AdvertNew

1: Change Advert () 2: Modify Advert() 3: Notify()

4: Update() 5: display Advert() 6: getAdvertData()

7: Update()

8: getAdvertData()

An AdvertController component receives the interface event changeAdvert ( ). In response to this event the controller invokes the modifyAdvert () operation in the CampaignModel object. The execution of this operation causes a change to the model. For example, if the target completion date for an advertisement is altered. This change of state must now be propagated to all controllers and views that are currently registered with the model as active. For this, the modifyAdvert () operation invokes the notify () operation in the model that sends an update() message to the view. The view responds to the update () message by executing the displayAdvert () operation which requests the appropriate data from the model via the getAdvertData () operation. The model also sends an update () message to the AdvertController, which then requests the data it needs from the model. One of the important aspects of the MVC architecture is that each model knows only which views and controllers are registered with it, but not what they do. The notify () operation causes an update message to all the views and controllers. The change propagation mechanism can be structured so that further views and controllers can be added without causing a change to the model. Other kinds of communication may take place between the MVC components during the operation of the application. The controller may receive events from the interface that require a change in the way that some data is presented to the user but do not cause a change of state. The controller's response to such an event would be to send an appropriate message to the view. There would be no need for any communication with the model.

3. Architectures for distributed systems

Distributed information systems are becoming more common as communications technology improves and becomes more reliable. An information system may be distributed over computers at the same location or different locations. Since Agate has offices around the world, it may need information systems that use data that is distributed among different locations. If Agate grows, it may also open new offices and require new features from its information systems. An architecture that is suitable for distributed information systems needs also to be flexible so that it can cope with change. A distributed information system may be supported by software products such as distributed database management systems or object request brokers .

A simplified version of the broker architecture is shown in the following figure.

Client A
Broker

Server1 Server2

Client B Server3

A broker component increases the flexibility of the system by decoupling the client and server components. Each client sends its requests to the broker rather than communicating directly with the server component. The broker then forwards the service request to an appropriate server. A broker may offer the services of many servers and part of its task is to identify the relevant server to which a service request should be forwarded. The advantage offered by a broker architecture is that a client need not know where the server is located, and it may therefore be stored on either a local or a remote computer. Only the broker needs to know the location of the servers that it handles.

The following figure shows a sequence diagram for client-server communication using the broker architecture. Here the server sub-system is on a local computer. In addition to the broker itself, two additional proxy components have been introduced to insulate the client and server from direct access with the broker. On the client side a ClientSide Proxy receives the initial request from the client and packs the data in a format suitable for transmission. The request is then forwarded to the Broker which finds an appropriate server and invokes the required service via the ServerSideProxy.

:Client

:ClientSideProxy

:Broker

:ServerSideProxy

:Server

1: Call Server()

2: Send Request() 3: Pack Data()

4: Send request ()

5: find Server()

6: Request Service()

7: Unpack Data()

8: Service()

9: Ack

10: Pack data()

11: Send Response() 12:

13: Send Response()

14: Unpack Data()

15: reply

Possible Process boundaries

The ServerSideProxy then unpacks the data and issues the service request sending the service () message to the Server object. The service () operation then executes and on completion control returns to the ServerSideProxy. The response is then sent to the Broker which forwards it to the originating ClientSideProxy. Note that these are both new messages and not returns. The reason for this is that a broker does not wait for each response before handling another request. Once its sendRequest - activation has been completed the broker will in all probability deal with many other requests, and thus requires a new message from the ServerSideProxy object that causes it to enter a new activation. Unlike the broker, the ClientSideProxy has remained active; this then unpacks the message and the response becomes available to the client as control returns. The following figure shows a schematic broker architecture that uses bridge components to communicate between two remote processors. Each bridge converts service requests into a network specific protocol so that the message can be transmitted.
Sub-System C

Sub-System A

Broker
Sub-System B

Bridge

Bridge

Broker
Sub-System D

Possible process boundary

4. CONCUREENCY
In most systems there are many objects that do not need to operate concurrently but some may need to be active simultaneously. Object-oriented modelling captures any inherent concurrency in the application through the development of interaction diagrams and statecharts and the examination of use cases also helps with the identification of concurrency. These models can be used to identify circumstances where concurrent processing is necessary. 1. A use case may indicate a requirement that the system should be able to respond simultaneously to different events, each of which triggers a different thread of control. 2. If a statechart reveals that a class has complex nested states which themselves have concurrent substates, then the design must be able to handle this concurrency. The statechart for the class Campaign has nested concurrent states within the Active state and there may be the possibility of concurrent activity. In cases where an object is required to exhibit concurrent behaviour it is sometimes necessary to split the object into separate objects in order to avoid the need for concurrent activity within anyone object.

Concurrent processing may also be indicated if interaction diagrams reveal that a single thread of control requires that operations in two different objects should execute simultaneously, perhaps because of asynchronous invocation. This essentially means that one thread of control is split into two or more active threads. An example of this is shown below.
CLASS A :CLASS B : CLASS C : CLASS D

1:

Asynchronous Message

2: 3:

Simultaneous execution

Do not execute simultaneously

Concurrency activity in an interaction diagram

Different objects that are not active at the same time can be implemented on the same logical processor .Objects that must operate concurrently must be implemented on different logical processors. The following figure shows a possible relationship between a scheduler and the other parts of a system. Events that are detected by the I/O (input/output) sub-systems generate interrupts in the scheduler. The scheduler then invokes the appropriate thread of control. Further interrupts may invoke other threads of control and the scheduler allocates a share of physical processor time to each thread .
Sub-system 2 Sub-system 1
This thread of execution generates output

<< invoke>> << invoke >>

Thread of control invoked by scheduler and produces no output

Scheduler <<interrupt>>

<< interrupt >> I/O sub system B

I/O sub-system A

Interrupts generated in scheduler

Another way of implementing concurrency is to use a multi-threaded programming language. These permit the direct implementation of concurrency within a single processor task. Finally, a multi-processor environment allows each concurrent task to be implemented on a separate processor. Most concurrent activity in a business information system can be supported by a multi-user environment. These are designed to allow many users to perform tasks simultaneously.

5 Processor Allocation
In the case of single-user system it is almost always appropriate for the complete system to operate on a single computer. The software for a multi-user information system may be installed on many computers that all use a common file-server. More complex applications sometimes require the use of more than one type of computer, where each provides a specialized kind of processing capability for a specific sub-system. An information system may also be partitioned over several processors either because sub-systems must operate concurrently, or because some parts of the application need to operate in different locations. Information systems that use the Internet or company intranets for their communications are being built more frequently. Such distributed information systems operate on diverse computers and operating systems.

The allocation of a system to multiple processors on different platforms involves the following steps. The application should be divided into sub-systems. Processing requirements for each sub-system should be estimated. Access criteria and location requirements should be determined. Concurrency requirements for the sub-systems should be identified. Each sub-system should be allocated to an operating platform-either general purpose (PC or workstation) or specialized (embedded micro-controller or specialist server). Communication requirements between sub-systems should be determined. The communications infrastructure should be specified. The estimation of processing requirements requires careful consideration of such factors as event response times, the data throughput that is needed, the nature of the I/O that is required and any special algorithmic requirements.

6. Data Management Issues

Suitable data management approaches for an information system can vary from simple file storage and retrieval to sophisticated database management systems of various types. In some applications where data has to be accessed very rapidly, the data may be kept in main memory while the system executes. However, most data management is concerned with storing data, often large volumes, so that it may be accessed at a later stage either by the same system or by another. Database management systems (DBMS) provide the following facilities that are useful in many applications. different views of the data by different users, control of multi-user access, distribution of the data over different platforms, security, enforcement of integrity constraints, access to data by various applications, data recovery, portability across platforms, data access via query languages and query optimization.

DBMS exhibits a significant performance overhead and the standard data access mechanisms may be inappropriate for specialized systems. Relational DBMS is likely to be appropriate if there are large volumes of data with varying (perhaps ad hoc) access requirements. Object-oriented DBMS is more likely to be suitable if specific transactions require fast access or if there is a need to store complex data structures and there is not a need to support a wide range of transaction types. A third type of DBMS is emerging-the object-relational DBMS-that is similar to an objectoriented DBMS in its support for complex data structures, but that also provides effective querying facilities. In some systems there may be different data management requirements for different sub-systems and it may be best then to use a mix of DBMS types.

7. Development standards
All information systems development projects should operate with clearly defined guidelines within which all members of the development team work. Many organizations will have corporate style guides that govern the production of software development artefacts, including the delivered system. In some organizations these corporate guides may be adapted for particular development projects. From the design perspective it is important to specify guidelines for the development of I/O sub-systems and their interfaces and standards for the development of code. 1. HCl guidelines - Standards for the human-computer interface are an important aspect of the design activity, since it is with the interface that users actually interact.

2 Input/output device guidelines

Where an application interacts with mechanical or electronic devices such as temperature and pressure sensors or actuators that control heaters or motors, it is equally important to develop guidelines.

The objective is to use a standard form of interface with the devices so that hardware may be changed or updated without occasioning any changes to the core system functionality. Sensor and controller devices usually have fully specified communications protocols and standardization is probably best achieved by encapsulating all direct access with each device in a single I/O device object. An I/O device class can be sub classed so that for each particular device involved with the application there is a class that deals with its communications protocol. Since all the I/O device classes would then be subclasses of one inheritance hierarchy they can easily be constructed to provide consistent interfaces to the rest of the application. This feature can be achieved by using Polymorphism concept of OO. 3 Construction guidelines Construction guidelines will normally include advice on the naming of classes, operations and attributes, and where this is the case these guidelines are also applicable during the analysis activity. Wherever possible, consistent naming conventions should be enforced throughout the project since this makes it easier to trace an analysis class directly through to its implementation.

8. Prioritizing Design Trade-Offs

Design frequently involves choosing the most appropriate compromise. The designer is often faced with design objectives that are mutually incompatible and he or she must then decide which objective is the more important. The requirements model may indicate the relative priorities of the different objectives but, if it does not, then prepare general guidelines used for this purpose. These guidelines must be agreed with clients since they determine the nature of the system and what functionality will be delivered. Guidelines for design trade-offs ensure consistency between the decisions that are made at different stages of development. They also ensure consistency between different sub-systems . However, no guidelines can legislate for every case. Design experience and further discussions with the client will remain necessary to resolve those situations that cannot be anticipated .