Software Saga


Since the 1960s, when there was an exponential growth in the number of mainframes, developers have been trying to get to write better and more efficient code. The 1970s saw Integrated Circuits becoming a reality and as a result the cost of hardware came down. 

This once again fuelled the growth of the number of computer users across the globe.

In the early days computers were used for just data processing and scientific calculations. The 70s saw new markets evolving and new verticals being captured. Gone were the days of the punch card, where programs were entered bit by bit. Programmers suddenly could write lines of code, and store it in alternate devices.

Meanwhile developers suddenly found out that application sizes have increased, and better ways to solve problems had to be found out to contain the huge sizes of programs. While new compilers, processors and operating systems were available the need of the hour was in structuring programs that they wrote.

The first significant step in this direction was the concept of structured programming or procedural programming, also known as top down approach, where logic inside a single program was subdivided. 
This was quite important as most of the business programs were written in COBOL during those days. With each program running into thousands of lines, a structured approach helped in solving many problems. (Fig1)
 

The 70s saw the first real software professionals in the United States. Many of today's industry icons including Bill Gates, Larry Ellison took up computers during that decade. 
There were suddenly new demands for designing, writing and maintaining code.
1. Software programs were no more written by a single professional. Programs especially in languages like COBOL and FORTRAN where written by a group of developers. Hence it became important for one programmer to read the code written by another. This brought in the concept of documentation of code in the world of computer programming. 
2. Program sizes actually became larger day by day. Hence it was important to write very efficient code so that the program sizes were maintained to an optimum.
3. 1981 saw the PC revolution, and a host of vendors started manufacturing personal computers. This meant that there was a common platform for a large user group. Hence code written for one PC had to work on another. Thus the concept of standards evolved even when designing a program.
4. Speed was the new mantra. Programs were required to run faster than the competition. Faster meant better naturally.
These new demands meant that a single application was no more built out of a single program. Multiple programs were written which worked with each other. Developers wrote programs in tandem where one program called another program.
This was a remarkable improvement for a developer. The program sizes came down considerably and since secondary storage became a reality, sharing of programs also became easier.
During the early eighties functional or procedural programming reached new heights as C and Pascal took centre stage. Developers managed to cut down the size again by storing static information in other files and dynamic information in others. Hence there was a Main program, which finally became the executable file and many other sub programs or supporting files that made up a program. (Fig 2)

 

However the new demands of programming kept on increasing. The concept of libraries came up where different static codes were kept. Yet the executable file size was huge compared to other programs. The concept of database introduced more efficient management of code, where anything that could be represented as data could be stored separately and also utilized by another program.

Though programs could be called from each other, there was little that another programmer could do as far the called program was concerned. The only way a developer could actually use this is by getting hold of code written in another program and integrating it in to the same program. Which essentially meant program sizes going up. Also, if the other developer does not document the code properly, it becomes tough to understand it. It even becomes tougher if developers sitting at remote locations try redaing or accessing it.

Moreover the headroom being occupied by one program and called by another program is substantially high. It further creates memory allocation errors too. Moreover developers noted that most of the time only a portion of code from another program is required and not the whole code. This gave rise to a new methodology in programming, called object oriented programming. In object oriented programming developers could actually use code written by another developer, by calling specific blocks of another program in to the program.
This increased code reusability, without sharing the code physically. All a developer needed to know was what a particular software program does. Object Oriented programming lets a developer call specific methods and attributes used by another program. Hence a developer could now reuse code written by another developer by basically understanding the function of a program.

Years   Methodology Skill sets 
1970-80s 
Method based development Pure programming 
1990s  Model based development  Engineering skills
2000s  Process based development Management skills 

Chunks of code in Object Oriented programming became classes, and you can create instances of classes called objects. And these objects can be used to produce the effect of hundreds of lines of code, through couple of lines of programming. Even better modifications could be made to the object, but retaining the overall functionality of the classes.

Object Oriented Designing helped developers to cut down development cycles considerably. At the same time project sizes also grew considerably as more functionality was needed for existing businesses and more vertical markets popped up.

Till the end of eighties, computer application programming was considered more of an art than pure engineering. However, with the advent of nineties, a new outlook to software development came through as general engineering ideas was applied to software development. Object Oriented Programming was the first step in that direction. 

The nineties saw a large wave in enterprise computing. Different departments of corporations started getting computerized. The challenge was to integrate such systems. And computerization became a business issue than a technical issue. This gave rise to today's ERP, MRP and Business Intelligence solutions.
With more software projects becoming more complex, the challenge moved to the boardrooms from the system terminal. Management costs of a project skyrocketed. Just like a motorcar being constructed there was a sudden need of drawing blueprints of a software project. By drawing a blueprint suddenly it was easier to write more efficient software.

The nineties saw most of the methodologies being developed for modelling a software project than purely improving the way you wrote programs. Several thinking leaders including Grady Booch, and Jim Rumbaugh developed methodologies based on object modelling. 

In 1995, Rational Software that housed pros like Booch, acquired Objectory AB, a Swedish company. With the aquisition, Ivar Jacobson came on board and together with Booch and Rumbaugh, the team developed Unified Modelling Language.

UML can best be described as syntax with graphical support that helps you to model different components of a software project easily. Through UML, one can model a software project from scratch, and build that on a computer. Rational presented UML to Object Management Group, a consortium that controls the UML standards.

Today there are number of methodologies based on UML. Vendors such as Rational, Ideogramic, Microgold, Aldean etc developed Computer Aided Design tools based on UML. (Note: We have a few of these tools in our CD). Such tools are today used to create blue print for almost all large software projects prior to the project getting implemented.

Components and Web Services

 

In late nineties the development world shifted to components. Components were similar to executable programs in many ways, but differed in functionality. One, it was a useful software by itself, and second another object could make use of it. And a large project or software product was a group of components talking to each other. Best example is the Office 2000, where different aspects of the product are actually components built according to Microsoft's COM architecture. 

Software Components truly are "ingredients of applications", and you "put together" these ingredients to get your job done. The further definition of a software component in today's world is any piece of pre-written code that defines interfaces that can be called to provide the functionality that the component encapsulates. These are typically packaged in "industry standard" ways so that they can be callable from multiple languages, or from multiple environments. 

Typically components are created as Microsoft.NET or Microsoft Component Object Model (COM) components, Java 2 Platform Enterprise Edition (J2EE) or JavaBeans components, Borland Delphi VCLs, or a number of other lesser known architectures. 

.NET/COM and J2EE/Java-based components are the most widely used as there are vast numbers of programmers who program in these compatible environments. The new paradigm of assembling components and writing code to make these components work together has a name, and of course an acronym, Component-Based Development (CBD).

Component-Based Development is truly the idea of creating software applications from components. The developer, during the design and specification phase, uses both internally developed components and open-market components to provide as much functionality as they can for their application. The developers then write the additional components needed and the glue code that hooks all the components together. 

They may put the new components they have created in a company storehouse, or repository, so that others can use the functionality that they have created. This can help lead to Software reuse which can bring down the costs of development. For example, if a developer creates a component to access a customer in the corporations' database, then no other programmer should have to write that functionality again. They can find that Customer component in their repository, and use it in their applications to do that functionality.

In short, more than code reuse all of a sudden the focus was software reuse and this is the biggest advantage of Component based development. 
The use of UML rose to a large extent, thanks to the new component based development methodologies. The reason was that the objected-oriented design rose to yet another level, rising beyond code and classes, to real time software.

Rational's Rational Unified Process is one of the new standards that have evolved out of the legacy of component development. RUP is an evolution from UML, and has structured the process of software development, not just the development.

Web Services
Web services are expected to revolutionize our life in much the same way as the Internet has during the past decade or so. Web services provide a common protocol that Web applications can use to connect to each other over the Internet. The main advantage of Web services is that they are based on industry standards. The services are described in XML and are communicated over the existing HTTP infrastructure. The union of XML and HTTP forms one of the new industry buzzwords: Simple Object Access Protocol (SOAP). Publicizing Web services is done via two standards: Universal Description, Discovery, and Integration (UDDI), and DISCO (abbreviation of Discovery).

The biggest advantage of Web Services is that software developed on an Internet server can be used by a remote desktop or by another server. This essentially represents the third stage of object-orientation.
Today when you design a Web Service project, it is impossible to design without actually modelling it.

More complex processes and the man power issue
The focus in the late nineties have shifted to the process than the project itself. While modelling to a large extent revolves around modelling around the project, the process-based methodologies are more man power oriented. It talks of teamwork, pairing, leadership and many management terms into the business of software technology. The 2000s belong to the managers.
Everchanging technology landscape is studded with new challenges to create better and more flexible software. Team sizes have become larger. Hence more than the software model, the focus is on the software process today. That is where management plays the role.

While you were developing software way back in 70s and eighties you could develop enterprise wide apps on your own. Even in nineties a single developer can use object modelling or UML and develop a product. However software processes essentially talks of managing large teams. There are now a host of processes. To name a few Vision Based methodologies, SCRUM, Extreme programming, Microsoft Solutions Framework etc are a few.




Added on April 11, 2002 Comment

Comments

Post a comment

Your name:

Comment: