Basing Software development

on reusable technology
Lecture : 3
Course Instructor: Sajid Ullah

1
 Basing Software development on reusable
technology
• Object-oriented paradigm, an important software development technology
that can be used to construct complex software systems.
• It would be nice, however, if instead of developing an entire system from
scratch, you could simply adapt an existing system to meet your needs.
• In other words, reuse is one of the keys to successful software
development.

2
 Reuse: building on the work and experience of others

• Where feasible, 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.
• This means designing and documenting software so that it is understandable and
flexible enough be used in a variety of different systems.
• The following are some of the types of reuse practiced by software engineers, in
increasing order according to the potential amount of work that can be saved by the
reuse:
3
 Reuse: building on the work and experience of others

i. 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
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

4
 Reuse: building on the work and experience of others

ii. 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.

5
 Reuse: building on the work and experience of others

iii. 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.
• The more powerful the facilities that come with a programming language, the more powerful
and ‘high level’ the language is.
• Applications like spreadsheets, word processors and database programs have built-in languages
with commands for such things as sorting, searching and displaying dialogs.
• Using these languages, which are often called fourth-generation languages, is an important form
of reuse.
6
 Reuse: building on the work and experience of others

iv. 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.

7
 Reuse: building on the work and experience of others

v. 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.
• This type of reuse is often called reuse of commercial off-the-shelf or COTS
software, and the extra code written is often called glue code.
8
 Reuse: building on the work and experience of others

• The elements reused in the latter three types of reuse are often collectively
called components.
• Unfortunately, reuse is not as extensive in software engineering projects as
might be desirable.

9
 Incorporating reusability and reuse into
software engineering

• In order for reuse to occur, software developers must not only reuse
existing good-quality components but must also contribute to reusable
components that others can use.

10
Encouraging reuse: breaking the vicious cycle

• Reuse and design for reusability, especially of frameworks, need to be made part of
the culture of software development organizations.
• In the many organizations that do not practice reuse, software engineers tend to
start design from scratch for each new application either because there are no
reusable components available to reuse, or because they do not feel confident
about reusing whatever is available.
• Developers are often willing to reuse packages of code delivered with a
programming language, but are reluctant to develop new ones, and are especially
reluctant to develop entirely new frameworks.
11
Encouraging reuse: breaking the vicious cycle

• 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.
12
Encouraging reuse: breaking the vicious cycle

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.
• 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.
13
Encouraging reuse: breaking the vicious cycle

• This cycle can only be broken if software engineers and their managers
recognize the following points:
i. The vicious cycle exists, and costs money.
ii. In order to save money in the longer term, some investment in reusable
code is normally justified.
iii. Developers should be explicitly rewarded for developing reusable
components

14
Encouraging reuse: breaking the vicious cycle

iv. Attention to quality of reusable components is essential so that potential

reusers have confidence in them.
v. Developing reusable components will normally simplify the resulting
design, independently of whether reuse actually occurs.
vi. Developing and reusing reusable components improves reliability, and
can foster a sense of confidence in the resulting system

15
 Making it possible to find reusable
components
• Even if reusable components are available, software engineers must be able
to find them easily. An essential activity therefore is to carefully catalog and
document all the reusable components.
• This catalog must be easy to search and must be kept up to date. In
particular, it is important to drop older components that have been found to
be unreliable or have been superseded by better components. Deprecating a
component means declaring that it should not be used in subsequent designs
but remains available to support existing designs that incorporate it.

16
 Frameworks: reusable subsystems
• A framework is reusable software that implements a generic solution to a
generalized problem. It provides common facilities applicable to different
application programs.
• Developing and using frameworks is an excellent way to promote reuse
and reusability.

17
 Frameworks: reusable subsystems
• The key principle behind frameworks is as follows: applications that do different but
related things tend to have similar designs – in particular, the patterns of interaction
among the components tend to be very similar.
• This can be true even if the applications are in quite different domains.
• To develop a framework, you identify the common design elements and develop
software that implements these design elements in a reusable way.
• The key thing that distinguishes a framework from other kinds of software subsystem is
that a framework is basically incomplete. This means that there are certain classes or
methods that are used by the framework, but which are missing.
18
 Frameworks: reusable subsystems
• The missing parts are often called slots.
• The application developer fills in these slots in an application-specific way to
adapt the framework to his or her needs.
• The more slots that the application developer must fill, the more complex the
framework is to use.
• At the same time, a framework with many slots tends to be more flexible and
therefore you are more likely to be able to reuse it to create a wide range of
applications across different domains.
19
 Frameworks: reusable subsystems
• Frameworks also usually have hooks: these are like slots, except that they
are places where developers can add optional functionality of different
kinds.
• Developers using frameworks not only fill slots and hooks, but they also
use the services that the framework provides, i.e. methods that perform
useful functions.

20
 Frameworks: reusable subsystems
• A framework enables the reuse of both design and code.
• The user of a framework not only reuses the overall design planned by the
framework’s designer, but also a body of code that implements that
design.

21
 Examples of Frameworks
A framework for payroll management
• Most businesses have software that includes a payroll module.
• The rules and features needed in a payroll system will differ considerably, depending on the type
of business, the local jurisdiction and other software the company uses.
• However, basic elements such as making regular payments, and computing taxes and other
deductions, will always exist.
• Although it is possible to purchase complete payroll applications, many businesses are of
sufficient complexity that such applications do not implement all the needed features and rules.
• Instead of developing a custom payroll package from scratch, several businesses could adapt a
common framework to their individual needs.

22
 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.

23
 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.
24
 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.
25
 Frameworks and product lines
• 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.

26
 Frameworks and product lines
• For example, the software controlling a line of microwave ovens will be
based on a common framework.
• Each model in the line will then have different combinations of software
and hardware features.
• Doing this is far more economical than designing each model separately.

27
 Frameworks and product lines
• Product lines are also found in many generic software products: you can
often purchase stripped-down ‘demo’ or ‘lite’ versions of software, as well
as ‘pro’ versions with extra features.
• Sets of software versions each tailored to specific languages or countries
also represent product lines.

28
 Horizontal and vertical frameworks
• A framework can be horizontal or vertical .
• 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.

29
 Horizontal and vertical frameworks
• 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).

30
 Horizontal and vertical frameworks
• 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.

31
 Object-oriented frameworks
• In the object-oriented paradigm, a framework is composed of a library of classes.
• The set of services – the API – offered by the framework is defined by the set of
all public methods of the public classes.
• Some of the classes in an object-oriented framework should be abstract.
• To use the framework in the context of a new application, the developer creates
concrete classes that extend these abstract classes.
• The abstract methods in the abstract classes are the slots that are filled when
concrete methods are created in the concrete subclasses.
32
 Example
• Imagine you are designing a framework that different libraries (of books,
not code) would be able to adapt to meet their needs. What kind of
facilities would you want to provide if you were designing such a
framework? In what ways do libraries differ such that they would need to
use a framework rather than a complete application?

33
 Example
Answer: common facilities a library framework might provide include:
i. A user interface providing standard kinds of searches (e.g. by author,
title and subject) and the ability to browse through lists of books and
periodicals, or authors.
ii. Basic classes representing books, clients, loans etc., along with common
operations that can be done with those classes.

34
 Example
Differentiating features of library systems might include:
i. The cataloging scheme (e.g. Dewey Decimal or Library of Congress).
ii. The kind of information kept about each client and book (e.g. clients may have different privileges,
such as to be able to borrow only certain types of books).
iii. Rules for types and lengths of loans, putting items on hold, payment of fines etc.
iv. The particular types of items that can be borrowed from the library. All libraries have books, but
libraries may contain such specialized items as videos, maps or rare books that need special
treatment.
v. Specific data unique to this library such as a specific style of barcodes placed on books,
multilingual support, etc.
35
 Example
vi. Specific hardware the library possesses, such as particular types of
barcode scanners and checkout machines.
vii. The security mechanisms, such as who has authority to do what kind of
operations. Login passwords in a university library might, for example,
be integrated with login passwords for other university systems.
viii.Integration of the system with other systems such as online library
resources, existing databases of books and periodicals, accounting
systems (e.g. for fines)
36
 The client–server architecture
•Software architecture is the branch of software engineering that deals with how to organize
and connect a set of software modules so that they can work together with each other.
•There are many well-known architectures – one of the most widely used is 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.
•A server is a program that provides some service for other programs that connect to it using
a communication channel.

37
 The client–server architecture
• A client is a program 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.

38
 The client–server architecture

UML diagram for a server program communicating with two client programs
39
 The client–server architecture
In general, the components of a client–server system interact as follows:
i. The server starts running.
ii. The server waits for clients to connect. This waiting process is called listening.
iii. Clients start running and perform various operations, some of which require
connecting to the server to request a service.
iv. When a client attempts to connect, the server accepts the connection if it is
willing.

40
 The client–server architecture
v. The server waits for messages to arrive from connected clients.
vi. When a message from a client arrives, the server takes some action in response, then
resumes waiting.
vii. Clients and servers continue functioning in this manner until one of them decides to
shut down
• Normally, the action taken by the server includes sending a message back to the client.
• Most servers have to be able to handle connections from many clients and respond to
messages from all the connected clients.

41
 The client–server architecture
• It is possible for the same program to be both a client and a server at the same
time.
• For example, a database server might connect to another server in order to
obtain additional data.
• It is also possible for the client and server to be located on the same computer
and run as separate processes.
• However, it is quite typical for them to be located on separate computers,
perhaps in different geographical locations.
42
Example client–server systems

43
Example client–server systems

44
 Capabilities that must be provided when
designing a server
A server has the following main activities to perform:
1. The server must initialize itself so that it is able to provide the required
service. For example, a server that handles airline reservations might load data
describing the available flights.
2. It must start listening for clients attempting to connect. Until it starts
listening, any client that attempts to connect will not succeed.
3. It must handle the following types of events originating from clients, which
can occur at any time:
45
 Capabilities that must be provided when
designing a server
i. 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.
ii. 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
46
 Capabilities that must be provided when
designing a server
iii. 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

47
 Capabilities that must be provided when
designing a server
4. 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.

48
 Capabilities that must be provided when
designing a server
5. 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.

UML diagram
for main
activities
performed by
typical Server

49
 Capabilities that must be provided when
designing a client
A client has the following main activities to perform:
1. Like the server, a client must initialize itself so that it is able to communicate with the
server. For example, it needs to know the network address of the server.
2. 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.

50
 Capabilities that must be provided when
designing a client
3. 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; for example, to announce that some new data is available or that
the server is shutting down.
51
 Capabilities that must be provided when
designing a client
• 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.
4. It must cleanly terminate. This includes disconnecting from a server if it is
still connected.

52
 Capabilities that must be provided when
designing a client

UML diagram for main activities

performed by a typical client

53
 Thin- versus fat-client systems
• The work of a client–server system can be distributed in several different ways.
• In a thin-client system, the client is made as small as possible and most of the work is done in the
server.
• In the opposite approach, called a fat-client system, as much work as possible is delegated to the clients.
• An important advantage of a thin-client system is that it is easy to download the client program over the
network and to launch it.
• In Java, applets are usually thin clients because it is desirable for them to download rapidly.
• An advantage of fat-client systems is that since more computations are distributed to the clients, better
use is made of available computational resources; the server can therefore be smaller or can be made to
handle more clients.
54
Thin- versus fat-client systems

A thin-client system (a) and a fat-client system (b). The clients

are at the top and the servers are at the bottom
55
 Thin- versus fat-client systems
• One of the main considerations in choosing between a fat-client and a thin client 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.

56
Establishing a connection in Java

57