SSE658.2


 * Course:** SSE658
 * Project:** 2
 * Subject:** Software Design
 * Student:** Dmitriy Slipak
 * E-mail:** dslipak@gmail.com

=Table Of Content=

Architectural Design Distributed Systems Architectures Application Architectures Object-Oriented Design Real-Time Software Design User Interface Design Service-Oriented Software Engineering References

 =1 Architectural Design=

Before diving deep into architectural design lets review on what is architecture in the software world. There are many definitions on what is software architecture coming from different books, journals, and other sources. I would avoid to represent all of them but have to mention two: first is a classic definition and second is modern definition.

Architecture in Software Systems. Classic Definition.
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization - these elements and their interfaces, their collaborations, and their composition (Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999).

Architecture in Software Systems. Modern Definition.
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

"Externally visible" properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Let us look at some of the implications of this definition in more detail.

> **First**, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements - details having to do solely with internal implementation - are not architectural.

> **Second**, the definition makes clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. For example, all non-trivial projects are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to sub-teams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system’s functionality is divided up and assigned to implementation teams. Other structures are much more focused on the way the elements interact with each other at run-time to carry out the system’s function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at run-time, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.

> **Third**, the definition implies that every software system has an architecture because every system can be shown to be composed of elements and relations among them. In the most trivial case, a system is itself a single element - an uninteresting and probably non-useful architecture, but an architecture nevertheless. Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. Unfortunately, an architecture can exist independently of its description or specification, which raises the importance of architecture documentation and architecture reconstruction.

> **Fourth**, the behavior of each element is part of the architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the architecture. This does not mean that the exact behavior and performance of every element must be documented in all circumstances; but to the extent that an element’s behavior influences how another element must be written to interact with it or influences the acceptability of the system as a whole, this behavior is part of the software architecture.

> **Fifth**, the definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that the architecture will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements. Assuming that we do not accept trial and error as the best way to choose an architecture for a system - that is, picking an architecture at random, building the system from it, and hoping for the best - this raises the importance of architecture evaluation.

(Software Architecture in Practice (2nd edition), Bass, Clements, Kazman; Addison-Wesley 2003)

Both, classic and modern definitions rely on structure or structural elements composed software system. The principal difference in definitions above is that classic definition defines software architecture as set of decisions. And this is a key in the software architecture in my opinion. Saying that, I would stay with a classic definition for software architecture.

Now, lets review what is architectural design. Large systems are always decomposed into sub-systems that provide some related set of services. The initial design process of identifying these sub-systems and establishing a framework for sub-system control and communication is called architectural design. The output of this design process is a description of the software architecture.

The architectural design process is concerned with establishing a basic structural framework that identifies the major components of a system and the communications between these components.

A sub-system design is an abstract decomposition of a system into large-grain components, each of which may be a substantial system in its own right. Block diagrams are often used to describe sub-system designs where each box in the diagram represents a sub-system. Boxes within boxes indicate that the sub-system has itself been decomposed to sub-systems. Arrows mean that data and or control signals are passed from sub-system to sub-system in the direction of the arrows. Block diagrams present a high-level picture of the system structure. Below is an example block diagram, showing the Microsoft Windows 2000 operating system architecture.

1.1 Architectural Design Decisions
Architectural design is a creative process where a software engineer try to establish a system organization that will satisfy the functional and non-functional system requirements. Because it is a creative process, the activities within the process differ radically depending on the type of system being developed, the background and experience of the system architect, and the specific requirements for the system. It is therefore more useful to think of the architectural design process from a decision perspective rather than from an activity perspective. During the architectural design process, system architects have to make a number of fundamental decisions that profoundly affect the system and its development process.

Although each software system is unique, systems in the same application domain often have similar architectures that reflect the fundamental domain concepts. These application architectures can be fairly generic, such as the architecture of information management systems, or much more specific. When designing a system architecture, we have to decide what our system and broader application classes have in common, and decide how much knowledge from these application architectures we can reuse.

The architecture of a software system may be based on a particular architectural model or style. An architectural style is a pattern of system organization such as a client-server organization or a layered architecture. An awareness of these styles, their applications, and their strengths and weaknesses is important. However, the architectures of most large systems do not conform to a single style. Different parts of the- system may be designed using different architectural styles. In some cases, the overall system architecture may be a composite architecture that is created by combining different architectural styles.

Evaluating an architectural design is difficult because the true test of an architecture is in how well it meets its functional and non-functional requirements after it has been deployed. However, in some cases, we can do some evaluation by comparing our design against reference or generic architectural models.

The product of the architectural design process is an architectural design document. This may include a number of graphical representations of the system along with associated descriptive text. It should describe how the system is structured into sub-systems, the approach adopted and how each sub-system is structured into modules. The graphical models of the system present different perspectives on the architecture. Architectural models that may be developed may include:


 * 1) A static **structural model** that shows the sub-systems or components that are to be developed as separate units.
 * 2) A **dynamic process** model that shows how the system is organized into processes at run-time. This may be different from the static model.
 * 3) An **interface model** that defines the services offered by each sub-system through its public interface.
 * 4) **Relationship models** that shows relationships, such as data flow, between the sub-systems.
 * 5) A **distribution model** that shows how sub-systems may be distributed across computers.

=1.2 System Organization=

The organization of a system reflects the basic strategy that is used to structure a system. A software engineer have to make decisions on the overall organizational model of a system early in the architectural design process. The system organization may be directly reflected in the sub-system structure. However, it is often the case that the sub-system model includes more detail than the organizational model, and there is not always a simple mapping from sub-systems to organizational structure.

There are at least three organizational styles that are widely used. These are a shared data repository style, a shared services and servers style and an abstract machine or layered style.

1.2.1 Shared Data Repository Model
There are two fundamental ways in which sub-systems that making up a system may exchange information so that they can work together.


 * 1) All shared data is held in a central database that can be accessed by all subsystems. A system model based on a shared database is sometimes called a repository model.
 * 2) Each sub-system maintains its own database. Data is interchanged with other sub-systems by passing messages to them.

In a repository style there are two quite distinct kinds of components: a central data structure represents the current state, and a collection of independent components operate on the central data store. Interactions between the repository and its external components can vary significantly between systems.

The choice of control discipline leads to major subcategories. If the types of transactions in an input stream of transactions trigger selection of processes to execute, the repository can be a traditional database. If the current state of the central data structure is the main trigger of selecting processes to execute, the repository can be a blackboard.

Figure below illustrates a simple view of a blackboard architecture. The blackboard model is usually presented with three major parts:


 * The knowledge sources: separate, independent parcels of application-dependent knowledge. Interaction among knowledge sources takes place solely through the blackboard.
 * The blackboard data structure: problem-solving state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem.
 * Control: driven entirely by state of blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable.

The advantages and disadvantages of a shared repository are as follows:


 * 1) It is an efficient way to share large amounts of data. There is no need to transmit data explicitly from one sub-system to another.
 * 2) However, sub-systems must agree on the repository data model. Inevitably, this is a compromise between the specific needs of each tool. 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.
 * 3) Sub-systems that produce data need not be concerned with how that data is used by other sub-systems.
 * 4) However, evolution may be difficult as a large volume of information is generated according to an agreed data model. Translating this to a new model will certainly be expensive; it may be difficult or even impossible.
 * 5) Activities such as backup, security, access control and recovery from error are centralized. They are the responsibility of the repository manager. Tools can focus on their principal function rather than be concerned with these issues.
 * 6) However, different sub-systems may have different requirements for security, recovery and backup policies. The repository model forces the same policy on all sub-systems.
 * 7) The model of sharing is visible through the repository schema. It is straightforward to integrate new tools given that they are compatible with the agreed data model.
 * 8) However, it may be difficult to distribute the repository over a number of machines. Although it is possible to distribute a logically centralized repository, there may be problems with data redundancy and inconsistency.

1.2.2 The Client-Server Model
The client-server architectural model is a system model where the system is organized as a set of services and associated servers and clients that access and use the services. The major components of this model are:


 * 1) A set of servers that offer services to other sub-systems. Examples of servers are print servers that offer printing services, file servers that offer file management services and a compile server, which offers programming language compilation services.
 * 2) A set of clients that call on the services offered by servers. These are normally sub-systems in their own right. There may be several instances of a client program executing concurrently.
 * 3) A network that allows the clients to access these services. This is not strictly necessary as both the clients and the servers could run on a single machine. In practice, however, most client-server systems are implemented as distributed systems.

Clients may have to know the names of the available servers and the services that they provide. However, servers need not know either the identity of clients or how many clients there are. Clients access the services provided by a server through remote procedure calls using a request-reply protocol such as the HTTP protocol used in the WWW. Essentially, a client makes a request to a server and waits until it receives a reply. Figure below shows a simple internet system with servers and clients. The most important advantage of the client-server model is that it is a distributed architecture. Effective use can be made of networked systems with many distributed processors. It is easy to add a new server and integrate it with the rest of the system or to upgrade servers transparently without affecting other parts of the system.

However, changes to existing clients and servers may be required to gain the full benefits of integrating a new server. There may be no shared data model across servers and sub-systems may organize their data in different ways. This means that specific data models may be established on each server to allow its performance to be optimized.

1.2.3 The Layered Model
A layered model is organized hierarchically, each layer providing service to the layer above it and serving as a client to the layer below. In some layered systems inner layers are hidden from all except the adjacent outer layer, except for certain functions carefully selected for export. Thus in these systems the components implement a virtual machine at some layer in the hierarchy. (In other layered systems the layers may be only partially opaque.) The connectors are defined by the protocols that determine how the layers will interact. Topological constraints include limiting interactions to adjacent layers. Figure below illustrates this style. The most widely known examples of this kind of architectural style are layered communication protocols. Layered systems have several desirable properties.


 * 1) They support design based on increasing levels of abstraction. This allows implementors to partition a complex problem into a sequence of incremental steps.
 * 2) They support enhancement. Like pipelines, because each layer interacts with at most the layers below and above, changes to the function of one layer affect at most two other layers.
 * 3) They support reuse. Like abstract data types,different implementations of the same layer can be used interchangeably, provided they support the same interfaces to their adjacent layers. This leads to the possibility of defining standard layer interfaces to which different implementors can build.

But layered systems also have disadvantages. Not all systems are easily structured in a layered fashion. And even if a system can logically be structured as layers, considerations of performance may require closer coupling between logically high-level functions and their lower-level implementations. Additionally, it can be quite difficult to find the right levels of abstraction. This is particularly true for standardized layered models. One notes that the communications community has had some difficulty mapping existing protocols into the ISO framework: many of those protocols bridge several layers.

In one sense this is similar to the benefits of implementation hiding found in abstract data types. However, here there are multiple levels of abstraction and implementation. They are also similar to pipelines, in that components communicate at most with one other component on either side. But instead of simple pipe read/write protocol of pipes, layered systems can provide much richer forms of interaction. This makes it difficult to define system-independent layers (as with filters)—since a layer must support the specific protocols at its upper and lower boundaries. But it also allows much closer interaction between layers, and permits two-way transmission of information.

=1.3 Modular Decomposition Styles=

Once the system organization was selected, its sub-systems should be decomposed into modules. There is not a rigid distinction between system organization and modular decomposition. Components in modules are usually smaller than sub-systems, which allows alternative decomposition styles to be used.

There is no clear distinction between sub-systems and modules, but I find it useful to think of them as follows:


 * 1) A sub-system is a system in its own right whose operation does not depend on the services provided by other sub-systems. Sub-systems are composed of modules and have defined interfaces, which are used for communication with other sub-systems.
 * 2) A module is normally a system component that provides one or more services to other modules. It makes use of services provided by other modules. It is not normally considered to be an independent system. Modules are usually composed from a number of other simpler system components.

There are two main strategies that can be used when decomposing a sub-system into modules:


 * 1) Object-oriented decomposition where we decompose a system into a set of communicating objects.
 * 2) Function-oriented pipelining where we decompose a system into functional modules that accept input data and transform it into output data.

In the object-oriented approach, modules are objects with private state and defined operations on that state. In the pipelining model, modules are functional transformations. In both cases, modules may be implemented as sequential components or as processes.

The advantage of avoiding a concurrent system design is that sequential programs are easier to design, implement, verify and test than parallel systems. Time dependencies between processes are hard to formalize, control and verify. It is best to decompose systems into modules, then decide during implementation whether these need to execute in sequence or in parallel.

1.3.1 Object-Oriented Decomposition
An object-oriented, architectural model structures the system into a set of loosely coupled objects with well-defined interfaces. Objects call on the services offered by other objects.

An object-oriented decomposition is concerned with object classes, their attributes and their operations. When implemented, objects are created from these classes and some control model is used to coordinate object operations.

Object-oriented systems have many nice properties, most of which are well known. Because an object hides its representation from its clients, it is possible to change the implementation without affecting those clients. Additionally, the bundling of a set of accessing routines with the data they manipulate allows designers to decompose problems into collections of interacting agents.

But object-oriented systems also have some disadvantages. The most significant is that in order for one object to interact with another (via procedure call) it must know the identity of that other object. This is in contrast, for example, to pipe and filter systems, where filters do need not know what other filters are in the system in order to interact with them. The significance of this is that whenever the identity of an object changes it is necessary to modify all other objects that explicitly invoke it. In a module-oriented language this manifests itself as the need to change the "import" list of every module that uses the changed module. Further there can be side-effect problems: if A uses object B and C also uses B, then C's effects on B look like unexpected side effects to A, and vice versa.

1.3.2 Function-Oriented Pipelining (Pipe and Filter Systems)
In a function-oriented pipeline or data-flow model, functional transformations process their inputs and produce outputs. Data flows from one to another and is transformed as it moves through the sequence. Each processing step is implemented as a transform. Input data flows through these transforms until converted to output. The transformations may execute sequentially or in parallel. The data can be processed by each transform item by item or in a single batch. Figure below illustrates a simple pipe and filter system diagram. The best known examples of pipe and filters architectures are programs written in the Unix shell. Unix supports this style by providing a notation for connecting components (represented as Unix processes) and by providing run time mechanisms for implementing pipes. As another well-known example, traditionally compilers have been viewed as a pipeline systems (though the phases are often not incremental). The stages in the pipeline include lexical analysis, parsing, semantic analysis, code generation. Other examples of pipes and filters occur in signal processing domains, functional programming, and distributed systems.

Pipe and filter systems have a number of nice properties.


 * 1) They allow the designer to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters.
 * 2) They support reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them.
 * 3) Systems can be easily maintained and enhanced: new filters can be added to existing systems and old filters can be replaced by improved ones.
 * 4) They permit certain kinds of specialized analysis, such as throughput and deadlock analysis.
 * 5) 1.They naturally support concurrent execution. Each filter can be implemented as a separate task and potentially executed in parallel with other filters.

But these systems also have their disadvantages.


 * 1) Pipe and filter systems often lead to a batch organization of processing. Although filters can process data incrementally, since filters are inherently independent, the designer is forced to think of each filter as providing a complete transformation of input data to output data. In particular, because of their transformational character, pipe and filter systems are typically not good at handling interactive applications. This problem is most severe when incremental display updates are required, because the output pattern for incremental updates is radically different from the pattern for filter output.
 * 2) They may be hampered by having to maintain correspondences between two separate, but related streams.
 * 3) Depending on the implementation, they may force a lowest common denominator on data transmission, resulting in added work for each filter to parse and unparse its data. This, in turn, can lead both to loss of performance and to increased complexity in writing the filters themselves.

=1.4 Control Styles=

The models for structuring a system are concerned with how a system is decomposed into sub-systems. To work as a system, sub-systems must be controlled so that their services are delivered to the right place at the right time. Structural models do not (and should not) include control information. Rather, the architect should organize the sub-systems according to some control model that supplements the structure model that is used. Control models at the architectural level are concerned with the control flow between sub-systems.

There are two generic control styles that are used in software systems:


 * 1) **Centralized control**. One sub-system has overall responsibility for control and starts and stops other sub-systems. It may also devolve control to another subsystem but will expect to have this control responsibility returned to it.
 * 2) **Event-based control**. Rather than control information being embedded in a subsystem, each sub-system can respond to externally generated events. These events might come from other sub-systems or from the environment of the system.

Control styles are used in conjunction with structural styles.

1.4.1 Centralized Control
In a centralized control model, one sub-system is designated as the system controller and has responsibility for managing the execution of other sub-systems. Centralized control models fall into two classes, depending on whether the controlled sub-systems execute sequentially or in parallel.


 * 1) **The call-return model**. This is the familiar top-down subroutine model where control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree. The subroutine model is only applicable to sequential systems.
 * 2) **The manager model**. This is applicable to concurrent systems. One system component is designated as a system manager and controls the starting, stopping and coordination of other system processes. A process is a sub-system or module that can execute in parallel with other processes. A form of this model may also be applied in sequential systems where a management routine calls particular sub-systems depending on the values of some state variables. This is usually implemented as a case statement.

1.4.2 Event-Driven Systems
Event-driven control models are driven by externally generated events. The term event in this context does not just mean a binary signal. It may be a signal that can take a range of values or a command input from a menu. The distinction between an event and a simple input is that the timing of the event is outside the control of the process that handles that event.

There are many types of event-driven systems. These include editors where user interface events signify editing commands, rule-based production systems as used in AI where a condition becoming true causes an action to be triggered, and active objects where changing a value of an object's attribute triggers some actions. Lets review two of the types – broadcast models and interrupt-driven models.


 * 1) **Broadcast models**. In these models, an event is broadcast to all sub-systems. Any sub-system that has been programmed to handle that event can respond to it.
 * 2) **Interrupt-driven models**. These are exclusively used in real-time systems where external interrupts are detected by an interrupt handler. They are then passed to some other component for processing.


 * //Broadcast Models//**

Broadcast models are effective in integrating sub-systems distributed across different computers on a network. Interrupt-driven models are used in real-time systems with stringent timing requirements. Here, all events could be broadcast to all sub-systems, but this imposes a great deal of processing overhead. More often, the event and message handler maintains a register of sub-systems and the events of interest to them. Sub-systems generate events indicating, perhaps, that some data is available for processing. The event handler detects the events, consults the event register and passes the event to those subsystems who have declared an interest. In simpler systems, such as PC-based systems driven by user interface events, there are explicit event-listener sub-systems that listen for events from the mouse, the keyboard, and so on, and translate these into more specific commands.

The advantage of this broadcast approach is that evolution is relatively simple. A new sub-system to handle particular classes of events can be integrated by registering its events with the event handler. Any sub-system can activate any other sub-system without knowing its name or location. The sub-systems can be implemented on distributed machines. This distribution is transparent to other subsystems.

The disadvantage of this model is that sub-systems don't know if or when events will be handled. When a sub-system generates an event it does not know which other subsystems have registered an interest in that event. It is quite possible for different sub-systems to register for the same events. This may cause conflicts when the results of handling the event are made available.


 * //Interrupt-Driven Model//**

This model is mostly used in real-time systems where an immediate response to some event is necessary. It may be combined with the centralized management model. The central manager handles the normal running of the system with interrupt-based control for emergencies. In this diagram, there are a known number of interrupt types with a handler defined for each type. Each type of interrupt is associated with the memory location where its handler's address is stored. When an interrupt of a particular type is received, a hardware switch causes control to be transferred immediately to its handler. This interrupt handler may then start or stop other processes in response to the event signaled by the interrupt.

The advantage of this approach is that it allows very fast responses to events to be implemented. Its disadvantages are that it is complex to program and difficult to validate. It may be impossible to replicate patterns of interrupt timing during system testing. It can be difficult to change systems developed using this model if the number of interrupts is limited by the hardware. Once this limit is reached, no other types of events can be handled.

=1.5 Reference Architectures=

There are architectural models that are specific to a particular application domain. Although instances of these systems differ in detail, the common architectural structure can be reused when developing new systems. These architectural models are called domain specific architectures.

There are two types of domain-specific architectural model:

Reference architectures are not normally considered a route to implementation. Rather, their principal function is a means of discussing domain-specific architectures and comparing different systems in a domain. A reference model provides a vocabulary for comparison. It acts as a base, against which systems can be evaluated.  =2 Distributed Systems Architectures=
 * 1) **Generic models** are abstractions from a number of real systems. They encapsulate the principal characteristics of these systems. For example, in real-time systems, there might be generic architectural models of different system types such as data collection systems or monitoring systems.
 * 2) **Reference models** are more abstract and describe a larger class of systems. They are a way of informing designers about the general structure of that class of system. Reference models are usually derived from a study of the application domain. They represent an idealized architecture that includes all the features that systems might incorporate.

A distributed system is a system where the information processing is distributed over several computers rather than confined to a single machine. Advantages of a distributed system the follows:


 * 1) **Resource sharing**. A distributed system allows the sharing of hardware and software resources - such as disks, printers, files and compilers - that are associated with computers on a network.
 * 2) **Openness**. Distributed systems are normally open systems, which means they are: designed around standard protocols that allow equipment and software from different vendors to be combined.
 * 3) **Concurrency**. In a distributed system, several processes may operate at the same time on separate computers on the network. These processes may (but need not) communicate with each other during their normal operation.
 * 4) **Scalability**. In principle at least, distributed systems are scalable in that the capabilities of the system can be increased by adding new resources to cope with new demands on the system. In practice, the network linking the individual computers in the system may limit the system scalability. If many new computers are added, then the network capacity may be inadequate.
 * 5) **Fault tolerance**. The availability of several computers and the potential for replicating information means that distributed systems can be tolerant of some hardware and software failures. In most distributed systems, a degraded service can be provided when failures occur; complete, loss of service only tends to occur when there is a network failure.

However, compared to systems that run on a single processor or processor cluster, distributed systems have a number of disadvantages:


 * 1) **Complexity**. Distributed systems are more complex than centralized systems. This makes it more difficult to understand their emergent properties and to test these systems.
 * 2) **Security**. The system may be accessed from several different computers, and the traffic on the network may be subject to eavesdropping. This makes it more difficult to ensure that the integrity of the data in the system is maintained and that the system services are not degraded by denial-of-service attacks.
 * 3) **Manageability**. The computers in a system may be of different types and may run different versions of the operating system. Faults in one machine may propagate to other machines with unexpected consequences. This means that more effort is required to manage and maintain the system in operation.
 * 4) **Unpredictability**. As all users of the WWW know, distributed systems are unpredictable in their response. The response depends on the overall load on the system, its organization and the network load. As all of these may change over a short period, the time taken to respond to a user request may vary dramatically from one request to another.

The components in a distributed system may be implemented in different programming languages and may execute on completely different types of processors. Models of data, information representation and protocols for communication may all be different. A distributed system therefore requires software that can manage these diverse parts, and ensure that they can communicate and exchange data.

Distributed systems are usually developed using an object-oriented approach. These systems are made up of loosely integrated, independent parts, each of which may interact directly with users or with other parts of the system. Parts of the system may have to respond to independent events. Software objects reflect these characteristics, so are natural abstractions for distributed systems components.

=2.1 Multiprocessor Architecture=

A multiprocessor system is a system, where the software system consists of a number of processes that may (but need not) execute on separate processors. This model is common in large real-time systems.

Using multiple processors improves the performance and resilience of the system. The; distribution of processes to processors may be predetermined (this is common in critical systems) or may be under the control of a dispatcher that decides which process to allocate to each processor.

Software systems composed of multiple processes are not necessarily distributed systems. If more than one processor is available, then distribution can be implemented, but the system designers need not always consider distribution issues during the design process.

=2.2 Client-Server Architectures=

In a client-server architecture, an application is modeled as a set of services that are provided by servers and a set of clients that use these services. Clients need to be aware of the servers that are available but usually do not know of the existence of other clients. Several server processes can run on a single server processor so there is not necessarily a 1:1 mapping between processes and processors in the system.

The design of client-server systems should reflect the logical structure of the application that is being developed. It may be done via splitting an application into three separate layers:


 * 1) **The presentation layer** is concerned with presenting information to the user and with all user interaction.
 * 2) **The application processing layer** is concerned with implementing the logic of the application.
 * 3) **The data management layer** is concerned with all database operations.

The simplest client-server architecture is called a two-tier client-server architecture, where an application is organized as a server (or multiple identical servers) and a set of clients. This two-tier client-server architectures can take two forms:


 * 1) **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.
 * 2) **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.

A thin-client, two-tier architecture is the simplest approach to use when centralized legacy systems, are evolved to a client-server architecture. The user interface for these systems is migrated to PCs, and the application itself acts as a server and handles all application processing and data management. A thin-client model may also be implemented when the clients are simple network devices rather than PCs or workstations. The network device runs an Internet browser and the user interface implemented through that system.

A major disadvantage of the thin-client model is that it places a heavy processing load on both the server and the network. The server is responsible for all computation, and this may involve the generation of significant network traffic between the client and the server.

The fat-client model makes use of this available processing power and distributes both the application logic processing and the presentation to the client. The server is essentially a transaction server that manages all database transactions.

While the fat-client model distributes processing more effectively than a thin-client model, system management is more complex. Application functionality is spread across many computers. When the application software has to be changed, this involves re-installation on every client computer. This can be a major cost if there are hundreds of clients in the system.

The problem with a two-tier client-server approach is that the three logical layers - presentation, application processing and data management - must be mapped onto two computer systems - the client and the server. There may either be problems with scalability and performance if the thin-client model is chosen, or problems of system management if the fat-client model is used. To avoid these issues, an alternative approach is to use a three-tier client-server architecture. In this architecture, the presentation, the application processing and the data management are logically separate processes that execute on different processors.

In some cases, it is appropriate to extend the three-tier client-server model to a multi-tier variant where additional servers are added to the system. Multi-tier systems may be used where applications need to access and use data from different databases. In this case, an integration server is positioned between the application server and the database servers. The integration server collects the distributed data and presents it to the application as if it were from a single database.

Three-tier client-server architectures and multi-tier variants that distribute the application processing across several servers are inherently more scalable than two-tier architectures. Network traffic is reduced in contrast with thin-client two-tier architectures. The application processing is the most volatile part of the system, and it can be easily updated because it is centrally located. Processing, in some cases, may be distributed between the application logic and the data management servers, thus leading to more rapid response to client requests.

=2.3 Distributed Object Architectures=

In a distributed object architecture, the fundamental system components are objects that provide an interface to a set of services that they provide. Other objects call on these services with no logical distinction between a client (a receiver of a service) and a server (a provider of a service). Objects may be distributed across a number of computers on a network and communicate through middleware. This middleware is called an object request broker. Its role is to provide a seamless interface between objects. It provides a set of services that allow objects to communicate and to be added to and removed from the system.

The advantages of the distributed object model are:


 * 1) It allows the system designer to delay decisions on where and how services should be provided. Service-providing objects may execute on any node of the network.
 * 2) It is a very open system architecture that allows new resources to be added to it as required.
 * 3) The system is flexible and scalable. Different instances of the system with the same service provided by different objects or by replicated objects can be created to cope with different system loads.
 * 4) It is possible to reconfigure the system dynamically with objects migrating across the network as required.

A distributed object architecture can be used as a logical model that allows to structure and organize the system.

The major disadvantage of distributed object architectures is that they are more complex to design than client-server systems. Client-server systems appear to be a fairly natural way to think about systems. They reflect many human transactions where people request and receive services from other people who specialize in providing these services. It is more difficult to think about general service provision, and we do not yet have a great deal of experience with the design and development of large-grain business objects.

2.3.1 CORBA
The implementation of a distributed object architecture requires middleware (object request brokers) to handle communications between the distributed objects. In principle, the objects in the system may be implemented using different programming languages, the objects may run on different platforms and their names need not be known to all other objects in the system.

Middleware to support distributed object computing is required at two levels:


 * 1) At the logical communication level, the middleware provides functionality that allows objects on different computers to exchange data and control information. Standards such as CORBA and COM have been developed to facilitate logical object communications on different platforms.
 * 2) At the component level, the middleware provides a basis for developing compatible components. Standards such as EJB, CORBA components or Active X provide a basis for implementing components with standard methods that can be queried and used by other components.

The Object Management Group (OMG) proposes that distributed application should consist of the following components:


 * Application objects that are designed and implemented for this application.
 * Standard objects that are defined by the OMG for a specific domain.
 * Fundamental CORBA services that provide basic distributed computing services such as directories and security management.
 * Horizontal CORBA facilities such as user interface facilities, system management facilities, and so on. The term horizontal facilities suggests that these facilities are common to many application domains and the facilities are therefore used in many different applications.

The CORBA standards cover all aspects of this vision. There are four major elements to these standards:


 * 1) An object model for application objects where a CORBA object is an encapsulation of state with a well-defined, language-neutral interface described in an IDL (Interface Definition Language).
 * 2) An object request broker (ORB) that manages requests for object services. The ORB locates the object providing the service, prepares it for the request, sends the service request and returns the results to the requester.
 * 3) A set of object services that are general services likely to be required by many distributed applications. Examples of services are directory services, transaction services and persistence services.
 * 4) A set of common components built on top of these basic services that may be required by applications. These may be vertical domain-specific components or horizontal, general-purpose components that are used by many applications.

The CORBA object model considers an object to be an encapsulation of attributes and services, as is normal for objects. However, CORBA objects must have a separate interface definition that defines the public attributes and operations of the object. CORBA object interfaces are defined using a standard, language-independent interface definition language. If an object wishes to use services provided by another object, then it accesses these services through the IDL interface. CORBA objects have a unique identifier called an Interoperable Object Reference (IOR). This IOR is used when one object requests services from another.

The object request broker knows about the objects that are requesting services and their interfaces. The ORB handles the communication between the objects. The communicating objects do not need to know the location of other objects nor do they need to know anything about their implementation. As the IDL interface insulates the objects from the ORB, it is possible to change the object implementation in a completely transparent way. The object location can change between invocations, which is transparent to other objects in the system.

The CORBA standards include interface definitions for a wide range of horizontal and vertical components that may be used by distributed application builders. Vertical components are components that are specific to an application domain. Horizontal components are general-purpose components such as user interface components.

=2.4 Inter-Organizational Distributed Computing=

There are some of newer models of distributed computing that allow inter-organizational rather than intra-organizational distributed computing. Peer-to-peer computing is based around computations carried out by individual network nodes. Service-oriented systems rely on distributed services rather than distributed objects, and rely on XML-based standards for data exchange.

2.4.1 Peer-to-peer Architectures
Peer-to-peer (p2p) systems are decentralized systems where computations may be carried out by any node on the network and, in principle at least, no distinctions are made between clients and servers. In peer-to-peer applications, the overall system is designed to take advantage of the computational power and storage available across a potentially huge network of computers. In a decentralized architecture, the nodes in the network are not simply functional elements but are also communications switches that can route data and control signals from one node to another.

This decentralized architecture has obvious advantages in that it is highly redundant, and so is fault-tolerant and tolerant of nodes disconnecting from the network. However, there are obvious overheads in the system in that the same search may be processed by many different nodes and there is significant overhead in replicated peer communications. An alternative p2p architectural model that departs from a pure p2p architecture is a semi-centralized architecture where, within the network, one or more nodes act as servers to facilitate node communications.

2.4.2 Service-Oriented System Architecture
A web service is a standard representation for some computational or information resource that can be used by other programs. Well-known UPS Package Tracking service is an example of web service.

The essence of a service is that the provision of the service is independent of the application using the service. Service providers can develop specialized services and offer these to a range of service users from different organizations. Applications may be constructed by linking services from various providers using either a standard programming language.

The differences between service model and the distributed object approach to distributed systems architectures are:


 * Services can be offered by any service provider inside or outside of an organization.
 * The service provider makes information about the service public so that any authorized user can use it.
 * Applications can delay the binding of services until they are deployed or until execution.
 * Opportunistic construction of new services is possible.
 * Service users can pay for services according to their use rather than their provision.
 * Applications can be made smaller (which is important if they are to be embedded in other devices) because they can implement exception handling as external services.
 * Applications can be reactive and adapt their operation according to their environment by binding to different services as their environment changes.

The three fundamental standards that enable communications between web services are:

 =3 Application Architectures=
 * 1) **SOAP** (Simple Object Access Protocol). This protocol defines an organization for structured data exchange between web services.
 * 2) **WSDL** (Web Services Description Language). This protocol defines how the interfaces of web services can be represented.
 * 3) **UDDI** (Universal Description, Discovery and Integration). This is a discovery standard that defines how service description information, used by service requestors to discover services, can be organized.

Applications Architecture is the science and art of ensuring the suite of applications being used by an organization to create the composite application is scalable, reliable, available and manageable. One not only needs to understand and manage the dynamics of the functionality the composite application is implementing but also help formulate the deployment strategy and keep an eye out for technological risks that could jeopardize the growth and/or operations of the organization.

The applications architecture is specified on the basis of business requirements. This involves defining the interaction between application packages, databases, and middleware systems in terms of functional coverage. This helps identify any integration problems or gaps in functional coverage. A migration plan can then be drawn up for systems which are at the end of the software life cycle or which have inherent technological risks.

=3.1 Data-Processing Systems=

Data-processing systems are batch-processing systems where data is input and output in batches from a file or database rather than input from and output to a user terminal. These systems select data from the input records and, depending on the value of fields in the records, take some actions specified in the program. They may then write back the result of the computation to the database and format the input and computed output for printing. The architecture of batch-processing systems has three major components:

> An input component may read some data (input) from a file or database, check the validity of that data and correct some errors (process), then queue the valid data for processing (output). > An output component may read records from a queue (input), format these according to the output form (process), then send them to a printer or write new records back to the database (output). > A processing component may take a transaction from a queue (input), perform some computations on the data and create a new data record recording the results of the computation (process), then queue this new record for printing (output). Sometimes the processing is done within the system database and sometimes it is a separate program.
 * 1) An **input component** collects inputs from one or more sources; a processing component makes computations using these inputs.
 * 1) An **output component** generates outputs to be written back to the database and printed.
 * 1) A **processing component**.

The nature of data-processing systems where records or transactions are processed serially with no need to maintain state across transactions means that these systems are naturally function-oriented rather than object-oriented. Functions are components that do not maintain internal state information from one invocation to another.

The architectural model of data-processing programs is relatively simple. However in those systems the complexity of the application is often reflected in the data being processed.

=3.2 Transaction-Processing Systems=

Transaction-processing systems are designed to process user requests for information from a database or requests to update the database. A database transaction is sequence of operations that is treated as a single unit (an atomic unit). All of the operations in a transaction have to be completed before the database changes are made permanent. This means that failure of operations within the transaction do not lead to inconsistencies in the database.

Transaction-processing systems are usually interactive systems where users make asynchronous requests for service. An example of a transaction-processing system is a banking system that allows customers to query their accounts and withdraw cash from an ATM. The system is composed of two cooperating software sub-systems -the ATM software and the account processing software in the bank's database server. The input and output sub-systems are implemented as software in the ATM, whereas the processing subsystem is in the bank's database server.

3.2.1 Information and Resource Management Systems
Any system that involve interaction with a shared database can be considered to be transaction-based information systems. An information system allows controlled access to a large base of information, such as a library catalog, a flight timetable or the records of patients in a hospital. Below is an example of simple information system.

=3.3 Event-Processing Systems=

Event-processing systems respond to events in the system s environment or user interface. The key characteristic of event-processing systems is that the timing of events is unpredictable and the system must be able to cope with these events when they occur.

Real-time systems, which take action in 'real time' in response to some external stimulus, are also event-based processing systems. However, for real-time systems, events are not usually user interface events but events associated with sensors or actuators in tide system.

As an example of event-processing system would be a simple, so-called editing system - program that run on PCs or workstations and that allow users to edit documents such as text documents, diagrams or images.

Editing systems have a number of characteristics that distinguish them from other types of system and that influence their architectural design:


 * 1) Editing systems are mostly single-user systems.
 * 2) They have to provide rapid feedback on user actions such as "select" and "delete".
 * 3) Editing sessions are normally much longer than sessions involving ordering goods, or making some other transaction.

The major architectural components of a simple editing system are:


 * 1) **Screen**. This object monitors the screen memory segment and detects events that occur.
 * 2) **Event**. This object is triggered by an event arriving from Screen.
 * 3) **Command**. This object processes a command from the event object and calls the appropriate method in the Editor data object to execute the command.
 * 4) **Editor data**. When the appropriate command method in Editor data object is called, it updates the data structure and calls the Update method in Display to display the modified data.
 * 5) **Ancillary data**. As well as the data structure itself, editors manage other data such as styles and preferences.
 * 6) **File system**. This object handles all opening and saving of files.
 * 7) **Display**. This object keeps track of the organization of the screen display.

=3.4 Language-Processing Systems=

Language-processing systems accept a natural or artificial language as an input and generate some other representation of that language as an output. A simple language-processing system can be represented by the diagram below. The instructions describe what has to be done and are translated into some internal format by a translator. The instructions correspond to the machine instructions for an abstract machine. These instructions are then interpreted by another component that fetches the instructions for execution and executes them using, if necessary, data from the environment. The output of the process is the result of interpreting the instructions on the input data. For many compilers, the interpreter is a hardware unit that processes machine instructions and the abstract machine is a real processor.

Translators in a language-processing system have a generic architecture that includes the following components:

 =4 Object-Oriented Design=
 * 1) A **lexical analyzer**, which takes input language tokens and converts them to an internal form.
 * 2) A **symbol table**, which holds information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated.
 * 3) A **syntax analyzer**, which checks the syntax of the language being translated. It uses a defined grammar of the language and builds a syntax tree.
 * 4) A **syntax tree**, which is an internal structure representing the program being compiled.
 * 5) A **semantic analyzer**, which uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text.
 * 6) A **code generator**, which "walks" the syntax tree and generates abstract machine code.

An object-oriented system is made up of interacting objects that maintain their own local state and provide operations on that state. The representation of the state is private and cannot be accessed directly from outside the object. Object-oriented design processes involve designing object classes and the relationships between these classes. These classes define the objects in the system and their interactions. When the design is realized as an executing program, the objects are created dynamically from these class definitions. Object-oriented design is part of object-oriented development where an object-oriented strategy is used throughout the development process:


 * **Object-oriented analysis** is concerned with developing an object-oriented model of the application domain.
 * **Object-oriented design** is concerned with developing an object-oriented model of a software system to implement the identified requirements.
 * **Object-oriented programming** is concerned with realizing a software design using an object-oriented programming language.

Object-oriented systems are easier to change than systems developed using other approaches because the objects are independent. They may be understood and modified as standalone entities.

Changing the implementation of an object or adding services should not affect other system objects. Because objects are associated with things, there is often a clear mapping between real-world entities (such as hardware components) and their controlling objects in the system. This improves the understandability and hence the maintainability of the design.

Objects are, potentially, reusable components because they are independent encapsulations of state and operations. Designs can be developed using objects that have been created in previous designs. This reduces design, programming and validation costs.

=4.1 Objects and Object Classes=

An object is an entity that has a state and a defined set of operations that operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) that request these services when some computation is required.

Objects are created according to an object class definition. An object class definition is both a type specification and a template for creating objects. It includes declarations of all the attributes and operations that should be associated with an object of that class. Diagram above is UML representation for a class. The object attributes are listed in the top section. The operations that are associated with the object are set out in the bottom section. The type of attributes as well as return types for class operations indicated after a colon. The “+” defines public access level for an attribute or an operation, while “-” defines private access level.

Objects communicate by requesting services (calling methods) from other objects and, if necessary, by exchanging the information required for service provision. The copies of information needed to execute the service and the results of service execution are passed as parameters.

In service-based systems, object communications are implemented directly as XML text messages that objects exchange. The receiving object parses the message, identifies the service and the associated data, and carries out the requested service.

When service requests are implemented in this way, communication between objects is synchronous. That is, the calling object waits for the service request to be completed. However, if objects are implemented as concurrent processes or threads, the object communication may be asynchronous. The calling object may continue in operation while the requested service is executing.

Object classes can be arranged in a generalization or inheritance hierarchy that shows the relationship between general and more specific object classes. The more specific object class is completely consistent with its parent class but includes further information.

In object-oriented programming languages, generalization i s implemented using inheritance. The child class inherits attributes and operations from the parent class.

4.1.1 Concurrent Objects
Conceptually, an object requests a service from another object by sending a message to that object. There is no requirement for serial execution where one object waits for completion of a requested service. Consequently, the general model of object interaction allows objects to execute concurrently as parallel processes. These objects may execute on the same computer or as distributed objects on different machines.

Most object-oriented programming languages have as their default a serial execution model where requests for object services are implemented in the same way as function calls. Languages, such as Java or C# include a very simple mechanism (threads) that lets us create objects that execute concurrently. Threads are created by using the built-in classes as a parent class in a class declaration. It is therefore easy to take an object-oriented design and produce an implementation where the objects are concurrent processes.

There are two kinds of concurrent object implementation:

> Servers are most useful in a distributed environment where the calling and the called object may execute on different computers. The response time for the service that is requested is unpredictable, so, wherever possible, we should design the system so that the object that has requested a service does not have to wait for that service to be completed. > Active objects are used when an object needs to update its own state at specified intervals. This is common in real-time systems where objects are associated with hardware devices that collect information about the system's environment. The object's methods allow other objects access to the state information.
 * 1) **Servers** where the object is realized as a parallel process with methods corresponding to the defined object operations. Methods start up in response to an external message and may execute in parallel with methods associated with other objects. When they have completed their operation, the object suspends itself and waits for further requests for service.
 * 1) **Active objects** where the state of the object may be changed by internal operations executing within the object itself. The process representing the object continually executes these operations so never suspends itself.

=4.2 An Object-Oriented Design Process=

In general the process of object-oriented design might be presented as follows:


 * 1) Understand and define the context and the modes of use of the system.
 * 2) Design the system architecture.
 * 3) Identify the principal objects in the system.
 * 4) Develop design models.
 * 5) Specify object interfaces.

Lets see the stages above in more details.

4.2.1 System Context and Models of Use
The first stage in any software design process is to develop an understanding of the relationships between the software that is being designed and its external environment.

The system context and the model of system use represent two complementary models of the relationships between a system and its environment:


 * 1) The system context is a static model that describes the other systems in that environment.
 * 2) The model of the system use is a dynamic model that describes how the system actually interacts with its environment.

When modeling the interactions of a system with its environment its important to use an abstract approach that does not include too much detail. One way to accomplish this is to develop a use-case model where each use-case represents an interaction with the system. In use-case models, each possible interaction is named in an ellipse and the external entity involved in the interaction is represented by a stick figure.

The use-case description helps to identify objects and operations in the system.

4.2.2 Architectural Design
Once the interactions between the software system that is being designed and the system's environment have been defined, we can use this information as a basis for designing the system architecture.

Simple system, and its architecture can again be represented as a layered model. For example:


 * The interface layer that is concerned with all communications with other parts of the system and with providing the external interfaces of the system.
 * The data collection layer that is concerned with managing the collection of data from the instruments and with summarizing the data before transmission to the mapping system.
 * The instruments layer that is an encapsulation of all of the instruments used to collect raw data about the system details.

In general, we should try to decompose a system so that architectures are as simple as possible. A good rule of thumb is that there should be no more than seven fundamental entities included in an architectural model.

4.2.3 Object Identification
During this stage in the design process, we should have some ideas about the essential objects in the system that we are designing. There are many proposals on how to identify object classes. Some of them defined as follows:


 * Use a grammatical analysis of a natural language description of a system. Objects and attributes are nouns; operations or services are verbs.
 * Use tangible entities (things) in the application domain such as aircraft, roles such as manager, events such as request, interactions such as meetings, locations such as offices, organizational units such as companies, and so on.
 * Use a behavioral approach where the designer first understands the overall behavior of the system. The various behaviors are assigned to different parts of the system and an understanding is derived of who initiates and participates in these behaviors. Participants who play significant roles are recognized as objects.
 * Use a scenario-based analysis where various scenarios of system use are identified and analyzed in turn. As each scenario is analyzed, the team responsible for the analysis must identify the required objects, attributes and operations. A method of analysis called CRC cards where analysts and designers take on the role of objects is effective in supporting this scenario-based approach.

These approaches help to get started with object identification. In practice, we may have to use several knowledge sources to discover object classes. Object classes, attributes and operations that are initially identified from the informal system description can be a starting point for the design. Further information from application domain knowledge or scenario analysis may then be used to refine and extend the initial objects. This information may be collected from requirements documents, from discussions with users and from an analysis of existing systems.

4.2.4 Design Models
Design models show the objects or object classes in a system and, where appropriate, the relationships between these entities. Design models essentially are the design. They are the bridge between the requirements for the system and the system implementation. This means that there are conflicting requirements on these models. They have to be abstract so that unnecessary detail doesn't hide the relationships between them and the system requirements. However, they also have to include enough detail for programmers to make implementation decisions.

An important step in the design process is to decide which design models that we need and the level of detail of these models. This depends on the type of system that is being developed. A sequential data processing system will be designed in a different way from an embedded real-time system, and different design models will therefore be used.

There are two types of design models that should normally be produced to describe an object-oriented design:


 * 1) **Static models** describe the static structure of the system using object classes and their relationships. Important relationships that may be documented at this stage are generalization relationships, uses/used-by relationships and composition relationships.
 * 2) **Dynamic models** describe the dynamic structure of the system and show the interactions between the system objects (not the object classes). Interactions that may be documented include the sequence of service requests made by objects and the way in which the state of the system is related to these object interactions.

The UML provides for many different static and dynamic models that may be produced to document a design. Most important of them are:

> A sub-system model is a useful static model as it shows how the design may be organized into logically related groups of objects. > Sequence models are dynamic models that document, for each mode of interaction, the sequence of object interactions that take place. > A state machine model shows how the object instance changes state depending on the messages that it receives.
 * 1) **Sub-system models** that show logical groupings of objects into coherent sub-systems. These are represented using a form of class diagram where each sub-system is shown as a package. Subsystem models are static models.
 * 1) **Sequence models** that show the sequence of object interactions. These are represented using a UML sequence or a collaboration diagram. Sequence models are dynamic models.
 * 1) **State machine models** that show how individual objects change their state in response to events. These are represented in the UML using statechart diagrams. State machine models are dynamic models.

4.2.5 Object Interface Specification
An important part of any design process is the specification of the interfaces between the components in the design. We need to specify interfaces so that objects and sub-systems can be designed in parallel. Once an interface has been specified, the developers of other objects may assume that interface will be implemented.

It is important to avoid including details of the interface representation in an interface design. The representation should be hidden and object operations provided to access and update the data. If the representation is hidden, it can be changed without affecting the objects that use these attributes. This leads to a design that is inherently more maintainable.

There is not necessarily a simple 1:1 relationship between objects and interfaces. The same object may have several interfaces, each of which is a viewpoint on the methods that it provides.

Object interface design is concerned with specifying the detail of the interface to an object or to a group of objects. This means defining the signatures and semantics of the services that are provided by the object or by a group of objects. Interfaces can be specified in the UML using the same notation as in a class diagram.

=4.3 Design Evolution=

Once a decision has been made to develop a system it is inevitable that proposals for system changes will be made. An important advantage of an object-oriented approach to design is that it simplifies the problem of making changes to the design. The reason for this is that object state representation does not influence the design. Changing the internal details of an object is unlikely to affect any other system objects. Furthermore, because objects are loosely coupled it is usually straightforward to introduce new objects without significant effects on the rest of the system.  =5 Real-Time Software Design=

A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced. A soft real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements. A hard real-time system is a system whose operation is incorrect if results are not produced according to the timing specification.

One way of looking at a real-time system is as a stimulus/response system. Given a particular input stimulus, the system must produce a corresponding response. In that case, behavior of a real-time system can be defined by listing the stimuli received by the system, the associated responses and the time at which the response must be produced.

Stimuli might be of two categories:

> Periodic stimuli in a real-time system are usually generated by sensors associated with the system. These provide information about the state of the system's environment. The responses are directed to a set of actuators that control some equipment, such as a pump, that then influences the system's environment. > Aperiodic stimuli may be generated either by the actuators or by sensors. They often indicate some exceptional condition, such as a hardware failure, that must be handled by the system. A real-time system has to respond to stimuli that occur at different times. Real-time systems are normally designed as a set of concurrent, cooperating processes. To support the management of these processes, the execution platform for most real-time systems includes a real-time operating system. The facilities in this operating system are accessed through the run-time support system for the real-time programming language that is used.
 * 1) **Periodic stimuli**. These occur at predictable time intervals. For example, the system may examine a sensor every 50 milliseconds and take action (respond) depending on that sensor value (the stimulus).
 * 1) **Aperiodic stimuli**. These occur irregularly. They are usually signaled using the computer's interrupt mechanism. An example of such a stimulus would be an interrupt indicating that an I/O transfer was complete and that data was available in a buffer.

=5.1 System Design=

For many real-time systems embedded in consumer products, such as the systems in cell phones, the costs and power consumption of the hardware are critical. Specific processors designed to support embedded systems may be used and, for some systems, special-purpose hardware may have to be designed and built. This means that a top-down design process - where the design starts with an abstract model that is decomposed and developed in a series of stages - is impractical for most real-time systems.

Events (the stimuli) rather than objects or functions should be central to the real-time software design process. There are several interleaved stages in this design process:


 * 1) Identify the stimuli that the system must process and the associated responses.
 * 2) For each stimulus and associated response, identify the timing constraints that apply to both stimulus and response processing.
 * 3) Choose an execution platform for the system: the hardware and the real-time operating system to be used. Factors that influence these choices include the timing constraints on the system, limitations on power available, the experience of the development team and the price target for the delivered system.
 * 4) Aggregate the stimulus and response processing into a number of concurrent processes.
 * 5) For each stimulus and response, design algorithms to carry out the required computations. Algorithm designs often have to be developed relatively early in the design process to give an indication of the amount of processing required and the time required to complete that processing.
 * 6) Design a scheduling system that will ensure that processes are started in time to meet their deadlines.

The order of these activities in the process depends on the type of system being developed and its process and platform requirements.

Processes in a real-time system have to be coordinated. Process coordination mechanisms ensure mutual exclusion to shared resources. When one process is modifying a shared resource, other processes should not be able to change that resource.

Because real-time systems must meet their timing constraints, we may not be able to use object-oriented development for hard real-time systems. Object-oriented development involves hiding data representations and accessing attribute values through operations defined with the object. This means that there is a significant performance overhead in object-oriented systems because extra code is required to mediate access to attributes and handle calls to operations. The consequent loss of performance may make it impossible to meet real-time deadlines.

5.1.1 Real-time System Modeling
Real-time systems have to respond to events occurring at irregular intervals. These events (or stimuli) often cause the system to move to a different state.

State machine models are a good, language-independent way of representing the design of a real-time system and are therefore an integral part of real-time system design methods.

A state model of a system assumes that, at any time, the system is in one of a number of possible states. When a stimulus is received, this may cause a transition to a different state.

=5.2 Real-time Operating Systems=

A real-time operating system manages processes and resource allocation in a real-time system. It starts and stops processes so that stimuli can be handled and allocates memory and processor resources.

The components of an Real-time OS depend on the size and complexity of the real-time system being developed. For all except the simplest systems, they usually include:


 * 1) **A real-time clock**. This provides information to schedule processes periodically.
 * 2) **An interrupt handler**. This manages aperiodic requests for service.
 * 3) **A scheduler**. This component is responsible for examining the processes that can be executed and choosing one of these for execution.
 * 4) **A resource manager**. Given a process that is scheduled for execution, the resource manager allocates appropriate memory and processor resources.
 * 5) **A dispatcher**. This component is responsible for starting the execution of a process.

Real-time operating systems for large systems, such as process control or telecommunication systems, may have additional facilities, such as disk storage management and fault management facilities, that detect and report system faults and a configuration manager that supports the dynamic reconfiguration of real-time applications.

5.2.1 Process Management
Real-time systems have to handle external events quickly and, in some cases, meet deadlines for processing these events. This means that the event-handling processes must be scheduled for execution in time to detect the event and must be allocated sufficient processor resources to meet their deadline. The process manager in an Real-time OS is responsible for choosing processes for execution, allocating processor and memory resources, and starting and stopping process execution on a processor.

The process manager has to manage processes with different priorities. For some stimuli, such as those associated with certain exceptional events, it is essential that their processing should be completed within the specified time limits. Other processes may be safely delayed if a more critical process requires service. Consequently, the Real-time OS has to be able to manage at least two priority levels for system processes:


 * 1) **Interrupt level**. This is the highest priority level. It is allocated to processes that need a very fast response. One of these processes will be the real-time clock process.
 * 2) **Clock level**. This level of priority is allocated to periodic processes.

There may be a further priority level allocated to background processes (such as a self-checking process) that do not need to meet real-time deadlines. These processes are scheduled for execution when processor capacity is available.

Within each of these priority levels, different classes of process may be allocated different priorities.

Periodic processes are processes that must be executed at specified time intervals for data acquisition and actuator control. In most real-time systems, there will be several types of periodic processes. These will have different periods (the time between process executions), execution times and deadlines (the time by which processing must be complete). Using the timing requirements specified in the application program, the Real-time OS arranges the execution of periodic processes so that they can all meet their deadlines.

Processes that have to respond to asynchronous events are usually interrupt-driven.

At any one time, there may be several processes, with different priorities, that could be executed. The process scheduler implements system-scheduling policies that determine the order of process execution. There are two basic scheduling strategies:


 * 1) **Non pre-emptive scheduling**. Once a process has been scheduled for execution, it runs to completion or until it is blocked for some reason, such as waiting for input. This can cause problems, however, when there are processes with different priorities and a high-priority process has to wait for a low-priority process to finish.
 * 2) **Pre-emptive scheduling**. The execution of an executing process may be stopped if a higher-priority process requires service. The higher-priority process preempts the execution of the lower-priority process and is allocated to a processor.

=5.3 Monitoring and Control System=

Monitoring and control systems are an important class of real-time system. They check sensors providing information about the system s environment and take actions depending on the sensor reading. Monitoring systems take action when some exceptional sensor value is detected. Control systems continuously control hardware actuators depending on the value of associated sensors.

=5.4 Data Acquisition Systems=

Data acquisition systems collect data from sensors for subsequent processing and analysis. These systems are used in circumstances where the sensors are collecting lots of data from the system's environment and it isn't possible or necessary to process the data collected in real-time. Data acquisition systems are commonly used in scientific experiments and process control systems where physical processes, such as a chemical reaction, happen very quickly.

In data acquisition systems, the sensors may be generating data very quickly, and the key problem is to ensure that a sensor reading is collected before the sensor value changes.

Most data acquisition systems include display and reporting processes that aggregate the collected data and carry out further processing.

In real-time systems that involve data acquisition and processing, the execution speeds and periods of the acquisition process (the producer) and the processing process (the consumer) may be out of step. When significant processing is required, the data acquisition may go faster than the data processing. If only simple computations need be carried out, the processing may be faster than the data acquisition.

To smooth out these speed differences, data acquisition systems buffer input data using a circular buffer. The process producing the data (the producer) adds information to this buffer, and the process using the data (the consumer) takes information from the buffer.  =6 User Interface Design=

Computer system design encompasses a spectrum of activities from hardware design to user interface design. Software engineers must often take responsibility for user interface design as well as for the design of the software to implement that interface.

Careful user interface design is an essential part of the overall software design process. If a software system is to achieve its full potential, it is essential that its user interface should be designed to match the skills, experience and expectations of its anticipated users. Good user interface design is critical for system dependability.

When making user interface design decisions, we should take into account the physical and mental capabilities of the people who use software. Some of those capabilities are:


 * 1) People have a limited short-term memory - we can instantaneously remember about seven items of information. Therefore, if we present users with too much information at the same time, they may not be able to take it all in.
 * 2) We all make mistakes, especially when we have to handle too much information or are under stress. When systems go wrong and issue warning messages and alarms, this often puts more stress on users, thus increasing the chances that they will make operational errors.
 * 3) We have a diverse range of physical capabilities. Some people see and hear better than others, some people are color-blind, and some are better than others at physical manipulation. We should not design for our own capabilities and assume that all other users will be able to cope.
 * 4) We have different interaction preferences. Some people like to work with pictures, others with text. Direct manipulation is natural for some people, but others prefer a style of interaction that is based on issuing commands to the system.

The principle of **user familiarity** suggests that users should not be forced to adapt to an interface because it is convenient to implement. The interface should use terms that are familiar to the user, and the objects manipulated by the system should be directly related to the user s working environment.

The principle of **user interface** consistency means that system commands and menus should have the same format, parameters should be passed to all commands in the same way, and command punctuation should be similar.

The principle of **minimal surprise** is appropriate because people get very irritated when a system behaves in an unexpected way. As a system is used, users build a mental model of how the system works. If an action in one context causes a particular type of change, it is reasonable to expect that the same action in a different context will cause a comparable change. If something completely different happens, the user is both surprised and confused. Interface designers should therefore try to ensure that comparable actions have comparable effects.

The principle of **recoverability** is important because users inevitably make mistakes when using a system. The interface design can minimize these mistakes (e.g., using menus means avoids typing mistakes), but mistakes can never be completely eliminated. Consequently, we should include interface facilities that allow users to recover from their mistakes. These can be of three kinds:


 * 1) **Confirmation of destructive actions**. If a user specifies an action that is potentially destructive, the system should ask the user to confirm that this is really what is wanted before destroying any information.
 * 2) **The provision of an undo facility**. Undo restores the system to a state before the action occurred. Multiple levels of undo are useful because users don't always recognize immediately that a mistake has been made.
 * 3) **Checkpointing**. Checkpointing involves saving the state of a system at periodic intervals and allowing the system to restart from the last checkpoint. Then, when mistakes occur, users can go back to a previous state and start again. Many systems now include checkpointing to cope with system failures but, paradoxically, they don't allow system users to use them to recover from their own mistakes.

A related principle is the principle of **user guidance**. Interfaces should have built-in user assistance or help facilities. These should be integrated with the system and should provide different levels of help and advice. Levels should range from basic information on getting started to a full description of system facilities. Help systems should be structured so that users are not overwhelmed with information when they ask for help.

The principle of **user diversity** recognizes that, for many interactive systems, there may be different types of users. Some will be casual users who interact occasionally with the system while others may be power users who use the system for several hours each day. Casual users need interfaces that provide guidance, but power users require shortcuts so that they can interact as quickly as possible. Furthermore, users may suffer from disabilities of various types and, if possible, the interface should be adaptable to cope with these. Therefore, we might include facilities to display enlarged text, to replace sound with text, to produce very large buttons and so on.

=6.1 Design Issues=

Essentially, the designer of a user interface to a computer is faced with two key questions:


 * 1) How should the user interact with the computer system?
 * 2) How should information from the computer system be presented to the user?

A coherent user interface must integrate user interaction and information presentation. This can be difficult because the designer has to find a compromise between the most appropriate styles of interaction and presentation for the application, the background and experience of the system users, and the equipment that is available.

6.1.1 User Interaction
User interaction means issuing commands and associated data to the computer system. This interaction might be represented by following forms:


 * 1) **Direct manipulation**. The user interacts directly with objects on the screen. Direct manipulation usually involves a pointing device (a mouse, a stylus, a trackball or, on touch screens, a finger) that indicates the object to be manipulated and the action, which specifies what should be done with that object.
 * 2) **Menu selection**. The user selects a command from a list of possibilities (a menu). The user may also select another screen object by direct manipulation, and the command operates on that object.
 * 3) **Form fill-in**. The user fills in the fields of a form. Some fields may have associated menus, and the form may have action "buttons" that, when pressed, cause some action to be initiated.
 * 4) **Command language**. The user issues a special command and associated parameters to instruct the system what to do. To delete a file, we would type a delete command with the file name as a parameter.
 * 5) **Natural language**. The user issues a command in natural language. This is usually a front end to a command language; the natural language is parsed and translated to system commands.

6.1.2 Information Presentation
All interactive systems have to provide some way of presenting information to users. The information presentation may simply be a direct representation of the input information (e.g., text in a word processor) or it may present the information graphically. A good design guideline is to keep the software required for information presentation separate from the information itself. Separating the presentation system from the data allows us to change the representation on the user s screen without having to change the underlying computational system. One of the effective ways to support multiple presentations of data is Model-View-Controller [@mvc|MVC] approach. I have a separate wiki page for the MVC pattern description.

When we are deciding how to present information, we should bear the following questions in mind:


 * 1) Is the user interested in precise information or in the relationships between data values?
 * 2) How quickly do the information values change? Should the change in a value be indicated immediately to the user?
 * 3) Must the user take some action in response to a change in information?
 * 4) Does the use:r need to interact with the displayed information via a direct manipulation interface?
 * 5) Is the information to be displayed textual or numeric? Are relative values of information items important?

When large amounts of information have to be presented, abstract visualizations that link related data items may be used. This can expose relationships that are not obvious from the raw data. We should be aware of the possibilities of visualization, especially when the system user interface must represent physical entities. Examples of data visualizations are:


 * Weather information, gathered from a number of sources, is shown as a weather map with isobars, weather fronts, and so on.
 * The state of a telephone network is displayed graphically as a linked set of nodes in a network management center.
 * The state of a chemical plant is visualized by showing pressures and temperatures in a linked set of tanks and pipes.
 * A model of a molecule is displayed and manipulated in three dimensions using a virtual reality system.
 * A set of web pages is displayed as a hyperbolic tree.

In addition to the style of information presentation, we should think carefully about how color is used in the interface. Color can improve user interfaces by helping users understand and manage complexity. However, it is easy to misuse color and to create user interfaces that are visually unattractive and error-prone. There are several key guidelines for the effective use of color in user interfaces. The most important of these are:


 * **Limit the number of colors employed and be conservative how these are used**. We should not use more than four or five separate colors in a window and no more than seven in a system interface.
 * **Use color change to show a change in system status**. If a display changes color, this should mean that a significant event has occurred. Thus, in a fuel gauge, we could use a change of color to indicate that fuel is running low. Color highlighting is particularly important in complex displays where hundreds of distinct entities may be displayed.
 * **Use color coding to support the task users are trying to perform**. If they have to identify anomalous instances, highlight these instances; if similarities are also to be discovered, highlight these using a different color.
 * **Use color coding in a thoughtful and consistent way**. If one part of a system displays error messages in red (say), all other parts should do likewise. Red should not be used for anything else. If it is, the user may interpret the red display as an error message.
 * **Be careful about color pairings**. Because of the physiology of the eye, people cannot focus on red and blue simultaneously. Eyestrain is a likely consequence of a red on blue display. Other color combinations may also be visually disturbing or difficult to read.

=6.2 The UI Design Process=

User interface (UI) design is an iterative process where users interact with designers and interface prototypes to decide on the features, organization and the look and feel of the system user interface. Sometimes, the interface is separately prototyped in parallel with other software engineering activities. More commonly, especially where iterative development is used, the user interface design proceeds incrementally as the software is developed.

There are three core activities in the UI design process:


 * 1) **User analysis**. In the user analysis process, we develop an understanding of the tasks that users do, their working environment, the other systems that they use, how they interact with other people in their work and so on. For products with a diverse range of users, we have to try to develop this understanding through focus groups, trials with potential users and similar exercises.
 * 2) **System prototyping**. User interface design and development is an iterative process. Although users may talk about the facilities they need from an interface, it is very difficult for them to be specific until they see something tangible. Therefore, we have to develop prototype systems and expose them to users, who can. then guide the evolution of the interface.
 * 3) **Interface evaluation**. Although we will obviously have discussions with users during the prototyping process, we should also have a more formalized evaluation activity where we collect information about the users actual experience with the interface.

=6.3 User Analysis=

A critical UI design activity is the analysis of the user activities that are to be supported by the computer system.

A challenge for engineers involved in user analysis is to find a way to describe user analysis so that they communicate the essence of the tasks to other designers and to the users themselves. Notations such as UML sequence charts may be able to describe user interactions and are ideal for communicating with software engineers.

Some of the issues during user analysis might be as follows:


 * Users might not be aware of appropriate search terms. They may need to access ways of helping them choose search terms.
 * Users have to be able to select collections to search.
 * Users need to be able to carry out searches and request copies of relevant material.

Normally, the analysis helps us understand the needs and concerns of the system users.

6.3.1 Analysis Techniques
There are three basis user analysis techniques: task analysis, interviewing and questionnaires, and ethnography. Task analysis and interviewing focus on the individual and the individual's work, whereas ethnography takes a broader perspective and looks at how people interact with each other, how they arrange their working environment and how they cooperate to solve problems.

There are various forms of task analysis, but the most commonly used is Hierarchical Task Analysis (HTA). In HTA, a high-level task is broken down into sub-tasks, and plans are identified that specify what might happen in a specific situation.

The advantage of HTA over natural language scenarios is that it forces us to consider each of the tasks and to decide whether these should be decomposed. With natural language scenarios, it is easy to miss important tasks. Scenarios also become long and boring to read if we want to add a lot of detail to them.

The disadvantage of this approach to describing user tasks is that it is best suited to tasks that are sequential processes. The notation becomes awkward when we try to model tasks that involve interleaved or concurrent activities or that involve a very large number of sub-tasks.

=6.4 User Interface Prototyping=

The aim of prototyping is to allow users to gain direct experience with the interface. Most of us find it difficult to think abstractly about a user interface and to explain exactly what we want. However, when we are presented with examples, it is easy to identify the characteristics that we like and dislike.

When we are prototyping a user interface, we should adopt a two-stage prototyping process:


 * 1) Very early in the process, we should develop paper prototypes - mock-ups of screen designs - and walk through these with end-users.
 * 2) We then refine our design and develop increasingly sophisticated automated prototypes, then make them available to users for testing and activity simulation.

There are three approaches that we can use for user interface prototyping:


 * 1) **Script-driven approach**. If we simply need to explore ideas with users, we can use a script-driven approach such as we'd find in Macromedia Director. In this approach, we create screens with visual elements, such as buttons and menus, and associate a script with these elements.
 * 2) **Visual programming languages**. Visual programming languages, such as Visual Basic, incorporate a powerful development environment, access to a range of reusable objects and a user-interface development system that allows interfaces to be created quickly, with components and scripts associated with interface objects.
 * 3) **Internet based prototyping**. These solutions, based on web browsers and languages such as Java, offer a ready-made user interface. We add functionality by associating segments of Java programs with the information to be displayed. These segments (called applets) are executed automatically when the page is loaded into the browser.

=6.5 Interface Evaluation=

Interface evaluation is the process of assessing the usability of an interface and checking that it meets user requirements. Therefore, it should be part of the normal verification and validation process for software systems.

Systematic evaluation of a user interface design can be an expensive process involving cognitive scientists and graphics designers.

There are a number of simpler, less expensive techniques of user interface evaluation that can identify particular user interface design deficiencies:

 =7 Service-Oriented Software Engineering=
 * 1) Questionnaires that collect information about what users thought of the interface.
 * 2) Observation of users at work with the system and 'thinking aloud' about how they are trying to use the system to accomplish some task.
 * 3) Video snapshots of typical system use.
 * 4) The inclusion in the software of code which collects information about the most used facilities and the most common errors.

Service-oriented architectures (SOA) are a way of developing distributed systems where the components of these systems are stand-alone services. These services may execute on geographically distributed computers. Standard protocols have been designed to support service communication and information exchange. Consequently, services are platform and implementation-language independent. Software systems can be constructed using services from different providers with seamless interaction between these services. The diagram above illustrates how web services are used. Service providers design and implement services and specify these services in a language called WSDL (discussed later). They also publish information about these services in a generally accessible registry using a publication standard called UDDI. Service sequesters (sometimes called service clients), who wish to make use of a service, search the UDDI registry to discover the specification of that service and to locate the service provider. They can then bind their application to that specific service and communicate with it, usually using a protocol called SOAP.

Web service protocols cover all aspects of service-oriented architectures from the basic mechanisms for service information exchange (SOAP) to programming language standards (WS-BPEL). These standards are all based on XML, a human and machine-readable notation that allows the definition of structured data where text is tagged with a meaningful identifier. XML has a range of supporting technologies, such as XSD for schema definition, which are used to extend and manipulate XML descriptions.

Briefly, the key standards for web service-oriented architectures are:


 * 1) **SOAP**. This is a message interchange standard that supports the communication between services. It defines the essential and optional components of messages passed between services.
 * 2) **WSDL**. The Web Service Definition Language (WSDL) standard defines the way in which service providers should define the interface to these services. Essentially, it allows the interface of a service (the service operations, parameters and their types) and its bindings to be defined in a standard way.
 * 3) **UDDI**. The UDDI (Universal Description, Discovery and Integration) standard defines the components of a service specification that may be used to discover the existence of a service. These include information about the service provider, the services provided, the location of the service description (usually expressed in WSDL) and information about business relationships. UDDI registries enable potential users of a service to discover what services are available.
 * 4) **WS-BPEL**. This standard is a standard for a work flow language that is used to define process programs involving several different services.

=7.1 Services as Reusable Components=

Services are a natural development of software components where the component model is, in essence, the set of standards associated with web services. A service can therefore be defined as:

//A loosely coupled, reusable software component that encapsulates discrete functionality, which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML-based protocols.//

A critical distinction between a service and a software component is that services should be independent and loosely coupled. That is, they should always operate in the same way, irrespective of their execution environment. Their interface is a provides' interface that provides access to the service functionality. Services are intended to be independent and usable in different contexts.

Services may also be distributed over the Internet. They communicate by exchanging messages, expressed in XML, and these messages are distributed using standard Internet transport protocols such as HTTP and TCP/IP. A service defines what it needs from another service by setting out its requirements in a message and sending it to that service. The receiving service parses the message, carries out the computation and, on completion, sends a message to the requesting service. This service then parses the reply to extract the required information. Unlike software components, services do not "call" methods associated with other services.

When we intend to use a web service, we need to know where the service is located (its URI) and the details of its interface. These are described in a service description expressed in an XML-based language called WSDL (Web Service Description Language). The WSDL specification defines three things about a Web service. It defines what the service does, how it communicates and where to find it:


 * 1) The "what" part of a WSDL document, called an interface, specifies what operations the service supports, and defines the format of the messages that are sent and received by the service.
 * 2) The "how" part of a WSDL document, called a binding, maps the abstract interface to a concrete set of protocols. The binding specifies the technical details of how to communicate with a Web service.
 * 3) The "where" part of a WSDL document, called (confusingly) a service, describes where to locate a specific Web service implementation.

The WSDL conceptual model defines the parts of a service description. Each of these is expressed in XML and may be provided in separate files. These parts are:


 * 1) An introductory part which, usually, defines the XML name-spaces used and which may include a documentation section providing additional information about the service.
 * 2) An optional description of the types used in the messages exchanged by the service.
 * 3) A description of the service interface, i.e. the operations that it provides.
 * 4) A description of the input and output messages processed by the service.
 * 5) A description of the binding used by the service, i.e. the messaging protocol that will be used to send and receive messages. The default is SOAP but other bindings may also be specified. The binding sets out how the input and output messages associated with the service should be packaged into a message, and specifies the communication protocols used. The binding may also specify how supporting information, such as security credentials or transaction identifiers, is included.
 * 6) An endpoint specification which is the physical location of the service, expressed as a Uniform Resource Identifier (URI) - the address of a resource that can be accessed over the Internet.

Complete service descriptions, written in XML, are long, detailed and tedious to read. They usually include definitions of XML name-spaces, which are qualifiers for names. A name-space identifier may precede any identifier used in the XML description. It means that it is possible to distinguish between identifiers with the same name that have been defined in different parts of an XML description.

The major problem with WSDL is that the definition of the service interface does not include any information about the semantics of the service or its non-functional characteristics, such as performance and dependability.

=7.2 Service Engineering=

Service engineering is the process of developing services for reuse in service-oriented applications. It has much in common with component engineering. There are three logical stages in the service engineering process. These are:


 * 1) Service candidate identification where we identify possible services that might be implemented and define the service requirements.
 * 2) Service design where we design the logical and WSDL service interfaces.
 * 3) Service implementation and deployment where we implement and test the service and make it available for use.

7.2.1 Service Candidate Identification
The basic notion of service-oriented computing is that services should support business processes. Service candidate identification involves understanding and analyzing the organization's business processes to decide which reusable services are required to support these processes. There are three fundamental types of service that may be identified:


 * 1) **Utility services**. These are services that implement some general functionality that may be used by different business processes.
 * 2) **Business services**. These are services that are associated with a specific business function.
 * 3) **Coordination or process services**. These are services that support a more general business process which usually involves different actors and activities.

Our goal in service candidate identification should be to identify services that are logically coherent, independent and reusable. We have to think of possible candidates then ask a series of questions about them to see if they are likely to be useful services. Possible questions that help us to identify reusable services are:


 * For an entity-oriented service, is the service associated with a single logical entity that is used in different business processes? What operations are normally performed on that entity that must be supported?
 * For a task-oriented service, is the task one that is carried out by different people in the organization? Will they be willing to accept the inevitable standardization that occurs when a single support service is provided?
 * Is the service independent, i.e. to what extent does it rely on the availability of other services?
 * For its operation, does the service have to maintain state? If so, will a database be used for state maintenance? In general, systems that rely on internal state are less reusable than those where state can be externally maintained.
 * Could the service be used by clients outside of the organization? For example, an entity-oriented service associated with a catalog may be accessed both internally and externally?
 * Are different users of the service likely to have different non-functional requirements? If they do, then this suggests that more than one version of a service should perhaps be implemented.

The output of the candidate selection process is a set of identified services and associated requirements for these services. The functional service requirements should define what the service should do. The non-functional requirements should define the security, performance and availability requirements of the service.

The catalog service is an example of an entity-oriented service that supports business operations. The functional catalog service requirements are:


 * 1) A specific version of the catalog shall be provided for each user company. This shall include the configurations and equipment that may be ordered by employees of the customer company and the agreed prices for catalog items.
 * 2) The catalog shall allow a customer employee to download a version of the catalog for off-line browsing.
 * 3) The catalog shall allow users to compare the specifications and prices of up to six catalog items.
 * 4) The catalog shall provide browsing and searching facilities for users.
 * 5) Users of the catalog shall be able to discover the predicted delivery date for a given number of specific catalog items.
 * 6) Users of the catalog shall be able to place "virtual orders" where the items required will be reserved for them for 48 hours.

In addition to these functional requirements, the catalog has a number of nonfunctional requirements:


 * 1) Access to the catalog service shall be restricted to employees of accredited organizations.
 * 2) The prices and configurations offered to one customer shall be confidential and shall not be available to employees of any other customer.
 * 3) The catalog shall be available without disruption of service from 07:00 GMT to 11:00 GMT.
 * 4) The catalog service shall be able to process up to 10 requests per second peak load.

7.2.2 Service Interface Design
There are three stages to service interface design:


 * 1) Logical interface design where we identify the operations associated with the service, the inputs and outputs of these operations and the exceptions associated with these operations.
 * 2) Message design where we design the structure of the messages that are sent and received by the service.
 * 3) WSDL development where we translate our logical and message design to an abstract interface description written in WSDL.

The first stage, logical interface design, starts with the service requirements and defines the operation names and parameters associated with the service. At this stage, we should also define the exceptions that may arise when a service operation is invoked.

The final stage of the service design process is to translate the service interface design into WSDL.

7.2.3 Service Implementation and Deployment
Once we have identified candidate services and designed their interfaces, the final stage of the service engineering process is service implementation. This implementation may involve programming the services using a standard programming language such as Java or C#. Both of these languages now include libraries with extensive support for service development.

Once a service has been implemented, it then has to be tested before it is deployed. This involves examining and partitioning the service inputs, creating input messages that reflect these input combinations and then checking that the outputs are expected.

Service deployment, the final stage of the process, involves making the service available for use on a web server. Most server software makes this very simple. We only have to install the file containing the executable service in a specific directory. It then automatically becomes available for use. If the service is intended to be publicly available, we then have to to write a UDDI description so that potential users can discover the service.

A UDDI description consists of a number of different types of information:


 * Details of the business providing the service. This is important for trust reasons. Users of a service have to be confident that it will not behave maliciously. Information about the service provider allows users to check a provider's credentials.
 * An informal description of the functionality provided by the service. This helps potential users to decide if the service is what they want. However, the functional description is in natural language, so it is not an unambiguous semantic description of what the service does.
 * Information on where to find the WSDL specification associated with the service.
 * Subscription information that allows users to register for information about updates to the service.

A potential problem with UDDI specifications is that the functional behavior of the service is specified informally as a natural language description.

7.2.4 Legacy System Services
In essence, the functionality of the legacy systems could be reused. The implementation of the component was simply concerned with providing a general interface to that system. One of the most important uses of services is to implement such "wrappers" for legacy systems. These systems can then be accessed over the web and integrated with other applications.

It is practically impossible to enhance the system to support these requirements so the company decides to provide new applications for maintenance and call center staff. These applications rely on the legacy system, which is to be used as a basis for implementing a number of services.

=7.3 Software Development With Services=

The development of software using services is based around the idea that we compose and configure services to create new, composite services. These may be integrated with a web user interface to create a web application or may be used as components in some other service composition. The services involved in the composition may be specially developed for the application, may be business services developed within a company or may be services from some external provider.

Service composition may be used to integrate separate business processes to provide an integrated process offering more extensive functionality.

The process of designing new services by composing existing services is, essentially, a process of software design with reuse. Design with reuse inevitably involves requirements compromises. The "ideal" requirements for the system have to be modified to reflect the services that are actually available, whose costs fall within budget and whose quality of service is acceptable. Below are six key stages in the process of service construction by composition:


 * 1) **Formulate outline work-flow**. In this initial stage of service design, we use the requirements for the composite service as a basis for creating an "ideal" service design.
 * 2) **Discover services**. During this stage of the process, we search service registries to discover what services exist, who provides these services and the details of the service provision.
 * 3) **Select possible services**. From the set of possible service candidates that we have discovered, we then select possible services that can implement work-flow activities.
 * 4) **Refine work-flow**. On the basis of information about the services that we have selected, we then refine the work-flow. This involves adding detail to the abstract description and, perhaps, adding or removing work-flow activities.
 * 5) **Create work-flow program**. During this stage, the abstract work-flow design is transformed to an executable program and the service interface is defined.
 * 6) **Test completed service or application**. The process of testing the completed, composite service is more complex than component testing in situations where external services are used.

7.3.1 Work-flow Design and Implementation
Work-flow design involves analyzing existing or planned business processes to understand the different stages of these processes then representing the process being designed in a work-flow design notation. This shows the stages involved in enacting the process and the information that is passed between the different process stages. However, existing processes may be informal and dependent on the skills and ability of the people involved - there may be no normal' way of working. In such cases, we have to use process knowledge to design a work-flow that achieves the same goals as current business processes.

7.3.2 Service Testing
Testing is important in all system development processes to help demonstrate that a system meets its functional and non-functional requirements and to detect defects that have been introduced during the development process.

As well as problems of understanding the operation of the service, testers may also face further difficulties when testing services and service compositions:


 * 1) External services are under the control of the service provider rather than the user of the service. The service provider may withdraw these services at any time or may make changes to them, which invalidates any previous testing experience. These problems are handled in software components by maintaining different versions of the component. Currently, however, there are no standards proposed to deal with service versions.
 * 2) The long-term vision of service-oriented architectures is for services to be bound dynamically to service-oriented applications. This means that, an application may not always use the same service each time that it is executed. Therefore, tests may be successful when an application is bound to some particular service but it cannot be guaranteed that that service will be used during an actual execution of the system.
 * As, in most cases, a service is available to different customers, the nonfunctional behavior of that service is not simply dependent on how it is used by the application that is being tested. A service may perform well during testing because it is not operating under a heavy load. In practice, the observed service behavior may be different because of the demands made by other users.
 * 1) The payment model for services could make service testing very expensive. There are different possible payment models - some services may be freely available, some paid for by subscription and others paid for on a per-use basis.

These problems are particularly acute when external services are used. They are less serious when services are used within the same company or where cooperating companies trust services offered by their partners. In such cases, source code may be available to guide the testing process and payment for services is unlikely to be a problem. Resolving these testing problems and producing guidelines, tools and techniques for testing service-oriented applications is currently an important research issue.  =References=

1. "Software Engineering 8th Edition", Ian Sommerville, Addison-Wesley - 2007. 2. "An Introduction to Software Architecture", David Garlan and Mary Shaw. 3. Wikipedia

Last revision date: {$revisiondate}