Download Reusable Technologies in Software Engineering: Frameworks and Client-Server Systems and more Lecture notes Object Oriented Analysis and Design in PDF only on Docsity!
Reuse: building on the work and experience of others
Software engineers should avoid re-developing software that others have already developed; in other words, they should try to reuse others’ work. In order to facilitate reuse, software engineers should also make their designs + reusable The following are some of the types of reuse practiced by software engineers
■ Reuse of expertise: Software engineers who have many years of experience working on projects can often save considerable time when it comes to developing new systems because they do not need to re-think many issues. their past experience tells them what needs to be done. If such people write articles describing their experiences, this can help others to do better Engineering work.
■ Reuse of standard designs and algorithms : There are thousands of algorithms and other aspects of designs described in various books, standards documents and articles. These represent a tremendous wealth for the software designer, since all he or she needs to do is to implement them if they are appropriate to the current task.
■ Reuse of libraries of classes or procedures, or of powerful commands built into languages and operating systems: Libraries and commands represent implemented algorithms, data structures and other facilities. Software developers always do this kind of reuse to some extent since all programming languages come with some basic libraries.
■ Reuse of frameworks: Frameworks are libraries containing the structure of entire applications or subsystems. To complete the application or subsystem, you merely need to fill in certain missing details. A framework can be written in any programming language and can vary considerably in sophistication and detail.
■ Reuse of complete applications: You can take complete applications and add a small amount of extra software that makes the applications behave in special ways the client wants. For example, you might take a standard email application and add a feature that would always update its ‘address book’ with data from the company’s employee and client databases.
Incorporating reusability and reuse into software engineering
Reuse and design for reusability should be part of the culture of software
development organizations
Object-Oriented Software Engineering
CHAPTER TWO
Reusable Technologies as a basis for Software Engineering
There are several reasons for this reluctance:
■ Developing anything reusable is seen as not directly benefiting the
current customer – after all, the current customer only needs one application, so why take the extra time needed to develop something that will benefit other applications? This argument often seems particularly convincing when developers are under extreme deadlines.
■ If a developer has painstakingly developed a high-quality reusable
component, but management only rewards the efforts of people who
create the more visible ‘final product’ , then that developer will be reluctant to spend time on reusable components in the future.
■ Efforts at creating reusable software are often done in a hurry and without enough
attention to quality. People thus lose confidence in the resulting
components, and in the concepts of reuse and reusability.
The vicious cycle
Therefore many organizations suffer from a vicious circle: developers do not develop high-quality reusable components, therefore there is nothing good enough to reuse. Since there is nothing good enough to reuse, software developers take so much time to develop applications that they lack time to invest in reusable frameworks or libraries.
This cycle can only be broken if software engineers and their
managers recognize the following points:
■ The vicious cycle exists, and costs money. ■ In order to save money in the longer term, some investment in reusable code is normally justified. ■ Developers should be explicitly rewarded for developing reusable components. ■ Attention to quality of reusable components is essential so that potential re-users have confidence in them. ■ Developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs. ■ Developing and reusing reusable components improves reliability, and can foster a sense of confidence in the resulting system.
Frameworks: reusable subsystems
Definition: a framework is reusable software that implements a generic
solution to a generalized problem. It provides common facilities
applicable to different application programs.
Principle behind frameworks is as follows: applications that do different but related things tend to have similar The key thing that distinguishes a framework from other kinds of software subsystem is that a framework is intrinsically incomplete. This means
all have a lot in common. A company implementing a new frequent buyer club would do well to base it on a framework in order to avoid the cost of developing a system from scratch.
■ A framework for course registration. Each institution has its own academic rules, hence it is difficult to create a commercial application that can be bought off the shelf to automate student information systems. However, when software engineers are developing or replacing student information systems, they could benefit from basing their designs on a common framework.
■ A framework for e-commerce web sites. Most e-commerce web sites are built on the same general model. There is a list of products to pick from; when an item is selected it is added to a shopping cart; the site then prompts for personal information and arranges for secure payment. Individual web sites will want to have special features to differentiate themselves in the market. However, developers could save a lot of work if they had a framework that implemented the above general model.
Frameworks and product lines
A product line (or product family ) is a set of products built on a common base
of technology.
The various products in the product line have different features to satisfy
different market requirements.
Many consumer products are sold in product lines. For example, a company producing microwave ovens will likely produce a very basic model that they can sell cheaply , and successively more expensive models with increasingly sophisticated features.
The software industry is following the product-line model more and more. Underlying a software product line is a framework containing the software technology common to all the products in the line. Each product is then produced by varying the modules used to fill the hooks and slots; new product variations can be produced quickly and easily.
Horizontal and vertical frameworks
A framework can be horizontal or vertical (Figure 3.1). A
horizontal framework provides general application facilities that a large number of applications can use. For example, if many applications need to have a ‘preferences’ dialog that allows users to specify many kinds of options, then a horizontal framework could be designed that would provide general ‘preferences dialog facilities’ for many different types of applications.
A vertical framework , often also called an application framework , provides facilities that will allow easy development of a more specific class of application programs. The microwave oven, frequent-buyer and course registration frameworks are vertical in nature, while the e-commerce framework might be a hybrid – a vertical framework composed of several horizontal frameworks that perform the sub-functions (such as general secure payment facilities).
A vertical framework will have a more complete implementation , and may have fewer slots and hooks. An interface in Java can be considered an extreme example of a horizontal framework: there is no implementation, and all the specified methods represent slots that must be filled.
The client–server architecture
A distributed system is a system in which computations are performed by separate programs , normally running on separate pieces of hardware that cooperate to perform the task of the system as a whole. Server: A server is a program (system) that provides some service for other programs that connect to it using a communication channel. Client: A client is a program (system) that accesses a server. A client may access many servers to perform different functions, and a server may be accessed by many clients simultaneously. A client–server system is a distributed system involving at least one server and one client. A peer-to-peer system is a client–server system in which programs can act as both client and server for each other.
In general, the components of a client–server system interact as follows:
■ The server starts running. ■ The server waits for clients to connect. This waiting process is called listening. ■ Clients start running and perform various operations, some of which require connecting to the server to request a service. ■ When a client attempts to connect, the server accepts the connection if it is willing. ■ The server waits for messages to arrive from connected clients. ■ When a message from a client arrives, the server takes some action in response, then resumes waiting. ■ Clients and servers continue functioning in this manner until one of them decides to shut down.
Conversely, data can be distributed among many different geographically- distributed clients or servers The server can be accessed simultaneously by many clients Competing clients can be written to communicate with the same server, and vice-versa Capabilities that must be provided when designing a server
A server has the following main activities to perform:
- The server must initialize itself so that it is able to provide the required service.
- It must start listening for clients attempting to connect. Until it starts listening, any client that attempts to connect will not succeed.
- It must handle the following types of events originating from clients, which can occur at any time: ❏ It accepts connections from clients. This process will normally involve some form of validation to ensure that the client is allowed to connect. While a client is connected, the server keeps a record of the connection. ❏ It reacts to messages from connected clients. This is the most important thing the server does. In an airline server a message could be a request to book a passenger, or a query to find out who is booked. In response to a message from a client, a server can do many types of things, including performing computations and obtaining information. Normally the server will send some information back to the requesting client; it might also send a message to another client or broadcast messages to many clients at once. ❏ It handles the disconnection of clients. A client can request disconnection by sending a message to the server or by simply disconnecting itself; it might ‘disappear’ if it crashes, or if its network connection goes down; finally, the server might force a client to disconnect if the client is not ‘behaving’ well.
- The server may be required to stop listening. This means that it will no longer accept new client connections, but it will continue to serve the currently connected clients. This may happen when the number of connected clients becomes too high; in such a situation the server rejects new clients so that it does not run out of resources such as memory. When it has enough resources again, it can start listening again. The server may also choose to stop listening prior to shutting down, allowing the connected clients time to terminate their work.
- It must cleanly terminate , i.e. shut down, when necessary. Shutting down cleanly means doing such things as notifying each client before terminating its connection.
Capabilities that must be provided when designing a client
A client has the following main activities to perform:
- Like the server, a client must initialize itself so that it is able to communicate with the server.
- It performs some work, which includes: ❏ Making a decision to initiate a connection to a server. If connecting to the server fails, or the server rejects the connection, the client may try again or may give up. ❏ Sending messages to the server to request services.
- It must handle the following types of events originating from the server, which can occur at any time: ❏ It reacts to messages coming from the server. Often, messages received from the server alternate with messages sent to the server – in other words, the messages from the server are replies to the client’s requests. Sometimes,however, an unanticipated message might arrive from the server ❏ It handles the disconnection of the server. This might occur because the server crashed or the network failed. It might also occur because either the client or server requested disconnection. The important issue is that the client knows it is no longer connected and makes decisions accordingly one possible action is to attempt to reconnect.
- It must cleanly terminate. This includes disconnecting from a server if it is still connected.
One of the main considerations in choosing between a fat-client and a thinclient system is how intensively the system will use the network to communicate – making the wrong choice can sometimes result in an overloaded network.
Depending on the nature of the system, either a fat-client or a thin-client system may take the fewest network resources. In some cases, a thin-client system will need to communicate the least because it generally sends only simple user requests to the server. On the other hand, a thin client might need to communicate with the server much more frequently than a fat client and to download voluminous results of the server’s calculations.
Figure 3.6 A thin-client system (a) and a fat-client system (b). The clients are at the top and the servers are at the bottom
Communications protocols
Figure 3.5 Threads in a client–server system
The types of messages the client is allowed to send to the server form a language. The server has to be programmed to understand that language. Similarly, another language consists of the types of messages the server is allowed to send to the client. When a client and a server are communicating, they are in effect having a conversation using these two languages. As with a human conversation, there have to be rules to ensure, for example, that the communicating parties take turns to speak. The rules also describe the sequences of messages that the client and server must exchange, in order to reach agreement on something or to accomplish some other task.
The two languages and the rules of the conversation, taken together, are called the protocol. The design of protocols can be very complex; in simple systems, such as those discussed in this book; the protocol is merely a list of service requests and their responses.
Tasks of the software engineer when developing a client–server system When designing a client–server system, the software engineer should make use of a framework that provides much of the underlying mechanism. We will describe such a framework later; however, the designer still has four key things to design:
- The primary work to be performed by both client and server; i.e. the computations to be performed, data to be stored, etc.
- How the work will be distributed – thin client, fat client, or intermediate.
- The details of the set of messages that will be sent from the client to the server and vice versa in order to accomplish the main activities, i.e. the communications protocol.
- What has to happen in the client and server when they start up, handle connections, send and receive messages, and terminate.
Requirements analysis
What is a requirement?
■ Recovery from failure. Requirements in this category constrain the allowed impact of a failure. They state that if the hardware or software crashes, or the power fails, then the system will be able to recover within a certain amount of time, and with a certain minimal loss of data
■ Allowances for maintainability and enhancement. In order to ensure that the system can be adapted in the future, you should describe changes that are anticipated for subsequent releases. This constrains design and improves quality without adding explicit new functional requirements. ■ Allowances for reusability. Similarly to the previous category, it is desirable in many cases to specify that a certain percentage of the system, e.g. 40%, measured in terms of lines of code, must be designed generically so that it can be reused
Platform requirements This type of requirement constrains the environment and technology of the system:
■ Computing platform. It is normally important to make it clear what hardware and operating system the software must be able to work on. Such requirements specify the least powerful platforms and declare that it must work on anything more recent or more powerful.
■ Technology to be used. While it is wise to give the designers as much flexibility as possible in choosing how to implement the system, sometimes constraints must be imposed. Common examples are to specify the programming language or database system. Such requirements are normally stated to ensure that all systems in an organization use the same technology – this reduces the need to train people in different technologies. The company might have also spent considerable money on a certain technology and wants to get the best value for that money.
Process requirements The final type of requirements constrains the project plan and development methods: ■ Development process (methodology) to be used. In order to ensure quality, some requirements documents specify that certain processes be followed.
■ Cost and delivery date. These are important constraints. However, they are usually not placed in the requirements document, but are found in the contract for the system or are left to a separate project plan document. In most cases, the boundaries between the functional requirements and other requirements types are clear
