1.3.1.2 File Sharing Architecture
The development of microprocessor, PC and LAN transformed dumb terminals
into ―smart‖ clients. This brought a complete change in the computing
environment. The client workstations or desktops, with there enhanced
capabilities were now responsible for the user interface and execution of the
application logic. The server provided access to computing resources like printers
and large hard drives for storing the files. It downloaded the file from the shared
location on the server to the client machine. The user application that worked on
the data was run on the client and the file was written back to the server. The
application had to be installed on each workstation that accessed the file.
In this architecture, resources could be added as and when necessary or desired.
Thus, it provided a low cost entry point with flexible arrangement. The drawback was that application logic was executed on the client and server typically provided Software Evolution
files to store data. It worked fine as long as the volume of data transfer was low
and shared usage and content update was low. As the number of online users
grew, the network traffic got congested and the file sharing got strained. Taking
into account the demerits of the file server architectures, the client/ server
architecture made its advent.
1.3.1.3 Client/ Server Architecture
As the capacity and power of personal computers improved, the need to share the
processing demands between the host server and the client workstation increased.
This need for greater computing control and more computing value led to the
evolution of client/server technology.
In client/server architecture, the tasks or workloads are partitioned as:
- server programs – providers of a resource or service
- client programs – requester of resource or service
Clients and servers may reside in the same machine or they typically reside in
separate pieces of hardware and communicate over a computer network. A server
machine is a host that runs one or more server programs which share their
resource with clients. A client does not share any of its resources, but requests a
server function or service. The server program fulfills the client request. Clients
initiate a communication session with the server.
The client/ server system may be two-tiered, three-tiered or n-tiered.
Two-tiered architecture: This approach basically introduced a database server to
replace the file server. The emergence of relational database management systems
and graphical user interface applications led to database server which could be
accessed through the GUI based client applications. Since, the clients query the
database over the network and only the relevant data is supplied to the client, the
network traffic is greatly reduced in comparison to the file server system.
The application or business logic in client server applications may reside on the
server (fat server – thin client) or on the client (fat client – thin server). Since, clients and server interact over the network, increases in the number of users often
lead to network congestion. Also, maintenance of the application becomes
difficult with more users. This lack of scalability (Ability of a system to support
increased demands of work, usage or service levels almost instantly, without any
change and with no significant drop in cost effectiveness or quality of service)
and flexibility gave rise to 3-tiered and n-tiered architectures.
Three-tiered architecture: A new generation of client/server implementation takes a step further and adds a middle tier in between client and server to achieve ―3-tier‖ architecture. The 3-tier architecture attempts to overcome some of the limitations of 2-tier schemes by separating presentation (user interface), processing (business functionality) and data into separate distinct entities. This leads to enhanced network performance and improved extensibility of business systems. Still, it has been found that three-tier methodology lacks some critical features such as reusability (Ability of a computer program to be used repeatedly with little or no modifications in many different applications) of application logic code and scalability. There may arise a situation whereby a collection of application logic code can not be reused and also they do not communicate with one another. Thus, there came a need for a viable architecture that mainly facilitates reusability of business logic as reusability phenomena has been found to reduce the cost of software development and the time to market and its quality is assured.
Internet-based architecture: In the late 1990‘s, the client/server trend was augmented by the internet. The users access the web servers through the web browsers on the client machines and over the internet. This led to very thin client based applications, which reside on corporate web servers.
The advantage of web based applications is that they do not have to be tailored to
run on specific platforms. But since the web applications cannot perform clientside processing, they limit the user experience by turning the client computers
into ―dumb‖ terminals. Web mails, online transactions are examples of web
applications.
1.3.1.4 Cloud Computing
As the technology has evolved from Mainframe-based large proprietary
(Computer Programs that are exclusive property of their developers or publishers,
and cannot be copied or distributed without complying with their licensing
agreements) systems to Client-Server architecture based open systems to Open
Source software based solutions, software vendor‘s business has also evolved
over the period of time. Cloud-based software services typically mean that the
consumer does not own the hardware and software, but still gets the desired
service. It is an IT delivery model that offers large-scale, shared infrastructure and
computing resources as a service through self-service pay-per use access.
Although it leverages recently developed technology, cloud computing is a
business, not a technical trend.
Here is some background for the evolution of these services. As the new software
vendors tried to establish themselves in the market, they created solution
differentiators which provide unique value to the consumers. An example is
Salesforce.com, which from the inception offered a hosted Customer Relationship
Management (CRM) solution, while its established competitors (Siebel, SAP,
PeopleSoft etc) had their traditional (also called On Premise, meaning at the
customer site in its dedicated environment) CRM solution. Another reason is that
software vendors started targeting a niche customer segment called Small &
Medium Business (SMB). SMB customers are relatively new in business, so need
to establish the core IT systems in place and also have lesser financial strength, as
a result are more open towards cloud-based solution.
An early example of cloud based computing is web-based emails (hotmail, yahoo,
gmail etc), Chat (AOL, MSN etc). Here the required computer resources are
provisioned centrally in the cloud (internet) and shared by the user pool. These
days, more often, software is bundled with the required shared infrastructure to
provide a solution stack to the consumer.
Key features of cloud computing are:
- Infrastructure sharing: Cloud computing enables dynamic sharing of resources so that demands can be met cost effectively.
- Scalability: To handle ever increasing workload demands and support the entire enterprise, cloud computing must have the flexibility to significantly scale IT resources.
- Self service: Cloud computing provides customers with access to IT resources through service-based offerings. The details of IT resources and their setup are transparent to the users.
- Pay-per-use: Because cloud resources can be added and removed according to workload demand, users pay for only what they use and are not charged when their service demands decrease.
There is another term that is associated with cloud computing:
- Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) – also referred to as On Demand software. This is a software solution delivery model where the software and the associated data are hosted centrally (in the cloud) and are accessed by the consumer through a thin client such as a web browser. Common applications for this are business applications such as – Accounting, Collaboration (Email, Messenger, Web meeting etc), Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), Human Resource Management etc.
- Lower upfront cost to get started, lower time-to-market (as it takes less time to get a customer going on a cloud solution), allows the company to focus on the core business and not worry about hiring and constantly training its staff on the new technology etc.
- On the flip side for a Cloud-based solution, certain segment of customers such as large Banks and Financial institutions, Insurance companies may have security constraints in letting their data reside outside its premises (in their own data centers).
1.3.2 Evolution of Software Design Paradigm
As the software evolved in its complexity, architecture and use, and as the
programming languages got better, styles of software programming also changed
and improved.
One of the longest standing goals of software design is reusability which leads to
increased reliability, accelerated development and easy maintenance. Over the
years, software languages and software design paradigms which have evolved, all
encourage compartmentalization of functionality to achieve this goal. Similar
functionality is grouped together into small, independent and reusable units.
These units can be used in any application for the purpose for which they were
originally intended.
The first step towards compartmentalization was moving from line by line non
structured program design to procedure-oriented program design.
1.3.2.1 Non-structured Design Paradigm
Non-structured programming is historically earliest programming paradigm. A
non structured program usually consists of sequentially ordered statements,
usually one in each line. The lines are usually numbered or labeled to allow the
flow of execution to jump to any line in program. There is no concept of
procedures in non structured program; hence there are no independent reusable units in this programming paradigm. The program flow in non-structured
programming would be as follows:
INTEGER i
The above fragment of code simulates a loop using GOTO statement for transfer
of control. Note that the lines are labeled/ numbered so that they can be used with
GOTO. The program executes the statements sequentially. The code simulates a
loop to decrease the value of variable i by 1 till it reaches zero.
i=12
1 GOTO 10
2 CONTINUE
i = i - 1
IF (i = 0) GOTO 99
10 PRINT*, "Line 10"
GOTO 2
99 CONTINUE
The initial value of i is 12. Until the value of i reaches zero, it continues to print
the text ―Line 10‖.
1.3.2.2 Structured and Modular Design Paradigm
Structured design paradigm introduced the concept of selection and repetition of
statements in code execution along with the line by line execution. It allowed
writing of procedures and functions. These are the terms used for a block of code
that is written to perform a single task. Procedures and functions were the
beginning of compartmentalization and hence reusability of program code.
Procedures and functions which were for similar purpose were grouped together
to get a module. A big software application consisted of multiple modules, each
performing a particular task.
Structural design allowed modules to be reused in the form of code libraries.
As shown in Figure 1.10, same procedure is invoked from step 3 and step 4. There is also a selection of path to be followed. The two paths would be either steps 1,2,4 or steps 1,3. The sample pseudo code for the above flow could be:
1.3.2.3 Object Oriented Design Paradigm
The next leap forward towards compartmentalization and reusability was arrival
of object oriented-design that introduced the concept of an object as an atomic
unit of functionality.
Object oriented design is built on the premise that programming problems can be
modeled in terms of the objects in the problem domain. In this design, any object
of interest in the real world is an object in the program code. This helps to
effectively model the real world and interactions of items within it. As the objects
in the real world interact with each other, similarly, the objects in the program
interact through their interfaces or messages which are very well defined and
contained in the objects. An object exposes the interface that can be called on by
other objects that need the object‘s functionality. Because an object is a self-contained entity and because its interface is well-defined it is highly reusable
across many applications.
For example, school and student are objects in real world. They would be
considered as objects in object oriented design also and they would interact with
each other through messages.
In the Figure 1.11 each object has its own properties and methods which constitute the interface of the object.
Encapsulation is one of the basic principles of object-oriented programming
(OOP) and refers to an object‘s ability to conceal its data (properties) and
methods. Encapsulated objects only publish the external interface so any user
interacting with them only needs to understand the interface and can remain
ignorant as to the internal specifications.
As the applications grew complex, code became more modular and reusable. The
applications were being broken up into pieces that were distributed across many
machines. Breaking applications into multiple parts and distributing them across
multiple platforms presented a new set of reusability problems.
1.3.2.4 Component Based Paradigm
The concepts of Object Oriented paradigm were extended to component based
programming. Component Based Development owes many concepts to object-oriented methods. It gives a more abstract view of software systems than object-oriented methods. This model prescribes that programming problems can be seen
as independently deployable black boxes (components) that communicate through
contracts.
The meaning of component or component based programming is intuitive: programs are broken down into primitive building blocks, which may be flexibly
―plugged together‖ according to well-defined protocols.
The idea behind component based programming is to develop software systems
by assembling a set of independently developed components off-the-shelf (COTS)
in a ‗plug and play‘ manner. For example, a Shopping cart website application
may use off the shelf credit card authorization component.
Components exist at different sizes varying from single objects inside a library to
whole applications. In most cases, however, components are larger entities and
contain several objects.
Components are regarded as part of the starting platform for service-orientation –
whereby a component is converted into a service.
1.3.2.5 Service Oriented Paradigm
Service-Oriented Programming builds on Object oriented programming, adding the premise that problems can be modeled in terms of the services that an object provides or uses.A service is a unit of functionality defined by a set of message exchanges that are
expressed using an implementation neutral grammar. It is a behaviour that can be
implemented or provided by any component for use by any component based on
message exchange.
A service, unlike an object, is an abstract entity whose implementation details are
left largely ambiguous. The only implementation details spelled out are the
messages the service exchanges or message exchanges. This ambiguity, coupled
with the requirement that the messages be defined by an implementation neutral
grammar make a service highly reusable and easy to integrate into a complex
system.
1.3.3 Evolution of Programming Languages
As the software architecture moved from mainframes to Internet based and design
paradigms evolved from non-structured to service oriented, Programming
languages evolved to support the architecture and the design paradigms. As
design became more and more compartmentalized so that the application could be
distributed onto multiple machines, and individual components could be reused,
more and more programming languages were designed to make support these
ideas. For example COBOL is one language that evolved from procedural to
object oriented.
1.3.3.1 Procedural Language
Procedural programming could also be called linear programming as one thing
happens and then the next. Each instruction is executed in order from the top of
the file to the bottom. It focuses on the idea that all algorithms are executed with
functions and data that the programmer has access to and is able to change. Some
languages which support procedural programming are C, FORTRAN, VB, etc.
Let us consider an example to understand how a procedural language works. You
need to create forms for online inventory system for an automobile parts
manufacturer. You are asked to design two separate forms: one to process
information about cars and other about trucks.
For cars, we will need to record the following information:
- Color
- Engine Size
- Transmission Type
- Number of doors
- Make
For trucks, the information will be similar, but slightly different. We need:
- Color
- Engine Size
- Transmission Type
- Cab Size
- Towing Capacity
- Make
We will code as follows:
/*Declare the Global variables*/
Var Color
Var EngineSize
Var Transmission Type
Var Make
MainProg()
Begin
If requested for car
Call CarProcedure()
If requested for Truck
Call TruckProcedure()
End
CarProcedure()
Begin
/*Declare the Local variables*/
Var NumberOfDoors
Process Car Information
End
TruckProcedure()
Begin
/*Declare the Local variables*/
Var CabSize
Var TowingCapacity
Process Truck Information
End
If we need to add form to process information for bus, then we need to change the
MainProg() and add code for Bus Form. But if there is a change in the processing
of all the vehicles, then we need to make changes to all the forms. If we need add
any make specific information for cars, then we need to create multiple forms,
one for each make. Also, we need to be careful about any changes to the global
variables as all the forms are accessing them.
1.3.3.2 Object Oriented Language
Object Oriented Programming is more abstract than procedural programming
because it looks for patterns and reusability. The same code can be loaded and
executed many times to accomplish a task without having to retype it.
Before we consider above example in object oriented, let us understand few terms
and concepts associated with object oriented programming. There are three main
concepts that any language needs to support to be an object oriented language.
Encapsulation: is a mechanism through which a protective wrapper is created to
hide the implementation details of the object and the only thing that remains
externally visible is the interface of the object. (i.e.: the set of all messages the
object can respond to). Encapsulation prevents code and data from being
arbitrarily accessed by other code defined outside the wrapper.
Inheritance: is the process by which a new class is created using an existing
class. It is a way to compartmentalize and reuse code since it allows classes
to inherit commonly used state and behavior from other classes. The new classes
are called the derived classed and the main class is called the parent class.
Polymorphism: Polymorphism is the characteristic of being able to assign a
different meaning specifically, to allow an entity such as a variable, a function, or
an object to have more than one form. It is the ability to process objects
differently depending on their data types and to redefine methods for derived
classes.
Following are the few terms that will help you understand object oriented
programming:
- A class is a set of functions that work together to accomplish a task. It can contain or manipulate data, but it usually does so according to a pattern rather than a specific implementation. An instance of a class is considered an object.
- An object receives all of the characteristics of a class, including all of its default data and any actions that can be performed by its functions. The object is for use with specific data or to accomplish particular tasks. To make a distinction between classes and objects, it might help to think of a class as the ability to do something and the object as the execution of that ability in a distinct setting.
- A method simply refers to a function that is encased in a class.
- A parameter is a variable that is passed into a function that instructs it how to act or gives it information to process. Parameters are also sometimes called arguments
- A property is a default set of data stored in a class. A class can have multiple properties and the properties can be changed dynamically through the methods of the class.
Smalltalk, C++, Java, C# are some of the examples of object oriented languages.
Now let us see how we create classes and use them for the automobile parts
inventory management system example.
Class Vehicle
{/*Data*/
Var Color
Var EngineSize
Var TransmissionType
Var Make
/*Methods for each data*/
Color()
{
Store and update color;
}
EngineSize()
{
Store and update EngineSize;
}
TransmissionType()
{
Store and update TransmissionType;
}
Make()
{
Store and update Make;
}
}
Class Car Inherits Vehicle
{/*Data*/
Var NumberOfDoors
/*Methods*/
NumberOfDoors()
{
Store and update NumberOfDoors;
}
}
Class Truck Inherits Vehicle
{/*Data*/
Var CabSize
Var TowingCapacity
/*Methods*/
CabSize ()
{
Store and update CabSize;
}
TowingCapacity ()
{
Store and update TowingCapacity;
}
}
Now in this case, if we need to add form to process information for bus, then we
just add one more class Bus() which is again inherited form the Vehicle class.
And if we need add any make specific information for cars, then again we can add
make specific classes which can be inherited from the Class Car() We need not
worry about mistakenly modifying any global variables. If there is change in
processing of all the vehicles, then instead of making changes at all the places, we
just modify the Vehicle() class.
1.3.4 Evolution of Software Licensing
Software licensing has kept pace with the evolution of software solutions offered
by the vendor or the solution provider community.
1.3.4.1 Introduction to Software Licensing
Until early 1970‘s, sharing of software was the accepted norm. Hardware came
bundled with software products which could be freely redistributed and the access
to source code allowed its improvement and modification.
In late 1960‘s, the situation changed after the software cost increased and
manufacturers started to unbundle the software and hardware. A growing amount
of software was now developed for sale. In late 1970‘s and early 1980‘s
companies began imposing restrictions on programmers through copyright. They
achieved financial gains by selling rights of use of software rather than giving the
source code. This led to introduction of software licensing which governed the
usage and redistribution of software. During this time most of the companies
developed proprietary software that was actually the property of the company,
came without the source code and the users basically bought the right to use it in
the way specified under the license agreement.
In early 1980‘s the seeds for free and open software were sown as a deviation
from the proprietary software. The open source software comes with source code
and a license that allows modification and free redistribution.
We will study in the following section, about different types of licenses that
evolved with software over the period of time.
1.3.4.2 Types of Software Licensing
The licensing type generally depends on whether the software is open source
software, is meant for individual use or enterprise wide commercial use:
Individual License: allows you to install the software only on a single stand
alone machine. It may be a perpetual license or Subscription based. Perpetual
license allows you to install and use the software indefinitely. Subscription based
license allows you to use the license for the specified time, after which you may
renew the subscription or remove the software.
Open Source License: It grants you the right to freely modify and redistribute the
software.
Commercial License: These are mostly for the large enterprises that use software
for commercial purposes.. Following are the main licensing models:
- Traditional model : This includes single user-single license, multi usersshared license, temporary or fixed-period licenses. This has mostly been used for large proprietary mainframe applications.
- Transaction-based model : Here, the pricing is based on providing a committed business service, for ex, processing payroll for a global company as part of HR offering and this can be priced per employee. Larger the employee base at a given location, lower the price / employee can be. This model came into existence with the evolution of software architecture from mainframes to internet based. As mentioned before, when a company provided a particular business service, its client could access the system from anywhere over the Internet and they need not bother about maintaining the database or the software system. The service provider then charges them for each transaction/ record processed through their system.
- Rental model : This has come into picture as Software as a Service (SaaS) and Platform as a Service (PaaS) models have evolved over a period of time. Here, the buyer need not need make upfront investment in hardware and software, rather these come as bundled service to them. Few examples where these are prevalent are – Finance & Accounting (Core Finance), Human Resources (Core HR), Analytics (Business Intelligence/Reporting), Procurement etc. There are also scenarios where the software vendor provides subscription of a given solution (ex. Windows Azure, Salesforce.com, Siebel On Demand, Amazon Web Services etc) on a periodic (ex. monthly, annual) basis.
- Technology Partnerships : Such agreements provide the consumer un-limited access to vendor‘s technology. Such contracts are typically multi-year in nature where the consumer pays a fixed annual fee, which can be adjusted in the subsequent years based on the actual usage. For example, a large corporate customer deciding to use Oracle suite of ERP (Finance, HR), database, CRM, Business Intelligence/ Reporting solutions can get into a long-term multi-year partnership.
0 Comments