E0 257 - Software Architecture Y. Narahari Department of Computer Science and Automation Indian Institute of Science Bangalore - 560 012 INDIA

Follows a gentle introduction to OOFWs as we'll call them for the rest of this article. I will use an informal language. Possibly that will add to the fun of going through the material.
I divide the material in three sections, apart from this introduction. The first part is devoted in trying to understand the meaning of the term OOFW. The second second talks about certain things one would like to know as a user of OOFWs. The third section deals with matters one deals in as a developer of a OOFW. This is followed by a summary, and a list of references.

1. What's an OOFW?

What is a framework, by the way? The very idea prompted me to formulate a definition of my own. I will refrain from stating it! But the exercise was rather instructive. While it gave me the impetus to define framework in its most general sense, it also gave me a taste of what happens if you don't restrict your scope. More about it in section 3.

"A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed."
So, a building will have a framework while it's being built. A society will also build upon some kind of social framework. Whatever be the 'something' which is being constructed upon a 'framework' we observe the following things :

* The framework is always in place when the thing is being built.
* The framework, even though very neatly defined, is not complete enough to serve any purpose by itself. For instance, the concept of family is a framework. However, a family will work only after it has decided certain issues like its size, its head, who's going to listen to whom, who earns bread, and who makes the home. Many families may define these rules differently, maintaining the fundamental family values, e.g. all stay together, all love one another, and all stand together in the days of crisis. In precise language, all 'families' are instances of the 'Family' framework.
* The systems built over a framework abide by the assumption made by the framework. In fact the statement of these assumptions are the precise definition of the framework. In other words a framework makes some kind of design decisions, which its instances have to follow.

That should be it about frameworks in its most general sense. Next we proceed to the main issue: that of defining 'Object Oriented Frameworks.' Perhaps I should approach that with one more step of defining 'Software Frameworks.' But believe me, there's not much to the concept of 'software frameworks' if we don't start talking about OOFWs right away. There are no significant software framework that are not object oriented! At least not any that I know of.
So, here's a definition, again from a standard source:

"A set of classes that embodies an abstract design for solutions to a number of related problems."

So, the first question to ask is : 'What makes it different from a library?'
The answer is : 'A framework 'is' a library. And it's something more than that. Let's try to see how.

A library is built to provide you with some ready made functionality. Here I am talking about libraries which we won't term as frameworks. They are essentially meant to provide you with a piece of code that you are likely to need again and again, and hence wouldn't like to do again and again. That kind of library doesn't make any kind of assumptions about what kind of program is going to use them. It doesn't give any hints to the user about how he should go about building his application in order to be able to use the library.
Put another way, such libraries don't foster reuse of design. This doesn't mean that no design goes into making the libraries. It only means that the design issues dealt with in making the libraries do not in any way pertain to the particular issues of the user. Hence such libraries are in use in the following scenarios :

* A widely used algorithm.
* A software interface to some other software or device.

On the other hand, a framework makes certain clear assumptions about its user's domain and the design of the application that the user wants to develop. The framework provides the user ways of picking from a list of gross designs that he would like to build his application upon. This facility is provided in several ways. Once this choice is made, the framework presents a partially built application that contains the essentials of that design. The user then customises this partial application to develop the complete application.
Without trying to be too precise in defining the concept, let's see some examples of frameworks. They are presented to give an idea of what all guises a framework may appear in. They also tell something about the development life-cycle of a OOFW.

Examples of OOFWs:

1. Microsoft Foundation Classes (MFC) :

This is Microsoft's very famous, publicised and successful class library that has been widely used to develop applications on MS-Windows environment. These applications are mostly GUI, but not necessarily so. MFC is a collection of classes that give the basic framework as to how the windows etc would look like and behave. This is done by providing a huge collection of classes that make calls to the Win32 APIs to provide you with the essential windows functionalities. Whatever modifications or additions we want to provide in our GUI application, we do that by deriving subclasses of the MFC classes and overriding their virtual functions.

2. C++ Standard Template Library:

STL provides a rich set of classes and functions in the form of C++ templates. It's now a part of the standard C++ specification, and is uniformly available in all implementations of C++. STL is very much like a library of the ordinary kind, but for this : It works for all types of abstract data types in C++, provided they have the operators that our STL templates require. Hence, the once you decide on using STL in your application, it provides you with a loose specification on the design of the abstract data types (classes that is) on which it operates. For example, it would expect that operators like ==, >, < etc should be defined for the classes the list of whose instances we want to sort using STL.

3. Simulation Frameworks (Mat lab, Dasylab) :

Many of the frameworks in this type let you build application without any programming at all. Pick up components from the tool kit; join them using appropriate connectors; and go. The system is up and running within minutes of its conceptualisation.
There is one valid question here : 'What's so OO about all this?' Especially the final category of OOFW. There are no classes, there is no programming. Well, frankly, I don't know. Somebody might have made the complete DasyLab system using C, without defining a single class. Then, technically Dasylab is not an OOFW. But what makes it an OOFW is the way it presents itself to its user. All members of the framework are instantiable entities with their own 'Identity', 'State' and 'Responsibility'. Irrespective of the implementation language, this qualifies Dasylab as an OOFW.
The above three classes of OOFWs represent three different stages of the life-cycle of an OOFW.
* MFC represents the most primitive stage. Its domain boundary is not well defined in the sense that a it targest a large number of possible applications which share something very abstract as common -- the fact that they are all window based, nothing more. MFC involves a major and imposing assumption regarding the structure of the programs that will be developed using them. All customisation happen through inheritance and polymorphism. In that sense it's the most object-oriented of all frameworks.
* STL's assumptions are less imposing than MFC's. It demands a minimum interface on which you want to specialise the STL templates. Other than that, you are free to design and develop your own application. STL relies more on generalisation than on polymorphism.
* The final class provides you the flexibility of composing your application with already formed components. To an extent that you don't write a single line of code. In that sense, Booch would like to call such an application as Object-Based rather than Object-Oriented. We observe that the domain knowledge about Dasylab kind of frameworks is the largest inside the framework. Hence, the domain boundaries are well defined and more or less rigid. For instance, it wouldn't be wise to try building a work flow management system with Dasylab, even though Dasylab proves terrific when it comes to building data acquisition systems.
So, the bottom line is that frameworks can be WHITE BOX type (inheritance based) or BLACK BOX type (composition based). Usually they contain properties of both. That is, as the domain that a framework intends to serve get more well-defined the framework itself tends to get more black box. Developing a program becomes easier and easier, but the design decisions the user is allowed to make are more and more higher level. The white box framework instantiation is through code addition at the so called 'hot-spots' of the skeletal code. The black box framework instantiation is through instantiation of the components in the tool kit of the library.

2. Using an OOFW

Similar to the previous section, this topic starts with a similar question : 'What's the difference between using a OOFW and a class library?'
To use a framework you would need to know much more about 'something'. That's the main difference. Let's see what this something is.
It typically takes months before one can think of using MFC to their fullest power. This is in spite of the fact that it makes no assumption about what kind of program is going to be developed (except that the platform is windows). On the other hand, you can start using Dasylab within minutes. Provided you have a fairly good idea about what all those devices mean. Meters, ADCs/DACs, filters, MUXes. A good amount of instrumentation engineering that is.
We may ask why this prior learning. The simple reason is that a lot of design goes into the building of an OOFW. And when we are using a framework based approach to develop applications, it means that we are not only making code reuse but design reuse too.

3. Making an OOFW

I know you know that this section can explode in size. But we'll restrict ourselves to the top level details. The main issues. Nothing more.

* Understanding the domain : Although this may sound much like domain analysis in the normal OOAD, it's slightly different. Remember, an OOFW has to father many applications. By 'Domain Analysis' from the OOFW perspective, we are trying to understand the fundamental nature of all the applications that may be built out of this. The framework must provide ways of doing that.

* Scoping : How big a problem space do we want to handle? The domain should be at least so big that so many applications are built that the saving that is made out of this framework based development is more than the extra cost of building the framework. On the other hand, a framework that claims to be solving all problems in the world is not much good. Framework development means some kind of generalisation of solution. In practice that comes with many overheads. Runtime, memory, framework development time, application development time. A framework for building fire-alarm systems is expectedly quite different from one for building elevator applications. If a framework is built to cater to both, it has taken much more effort to build, and hence is much more expensive. A company building fire alarm is very unlikely to change to building elevators. Why would it pay extra money for a framework which charges extra for a functionality which is of no concern to it?

* Software Architecture : How much of black-box and how much of white-box should your OOFW be? That's the next question. As hinted earlier, we should look up to the maturity of the domain we intend to serve, for an answer. If the domain we want to serve is very abstract, wide, and comprising fuzzy boundaries, better choose a white-box approach. It gives the application developer much more power to define the functionality. And it allow you, the framework developer the right to decide a apriori how the overall program structure ought to be, since the user may himself not be sure. On the other hand, if the domain is well-defined, restricted and concrete, then go for more black-box architecture.

The additional concerns while architecting the OOFW are :

+ How learned is the user of the OOFW? A domain expert with limited programming expertise would like to be given flexibility in defining domain items. A programming expert would want to be given more power to decide the design the software system.
+ How is the system data accessed? It is a well known problem in object oriented programming that data encapsulated becomes invisible to all the rest of the world. It's not always desirable. When the application programmer wants the framework to do something important with the data of objects that are passed to it, this private data thing creates a lot of confusion. No clear-cut solution. Just beware of it.
+ How control flows? Or how much control would the application programmer want to have in deciding the control flow of the program. A white box approach lets the framework decide the calling sequence etc. A black box approach does the other way. What do you want?
+ How does the framework interact with other frameworks? It's true that you want to make your program a GUI program. So you decide to use MFC. MFC takes complete control of the control sequence of the program. Now, if your program also happens to be a data-acquisition software which needs to wait in a loop for messages from various sensors, how do you propose to design the resulting application? The issue is that the framework tends to put undesirable amount of restriction on the software architecture. So much so that it prohibits use of another framework which imposes a non-complaint architecture. This has to be taken into account by the OOFW designer.

* Domain requirements : Can an instrumentation software afford to crash because of an unhandled exception from its GUI? Such questions must be considered when designing an OOFW. You must foresee to an appreciable extent who's going to use your framework. Your framework must be robust enough to cater to the domain requirements of that client.

* Development process : Frameworks are always expensive to build. The software project must be planned to include an incremental defensive development. Releases should be carefully planned. Backward compatibility should be taken care of. Documentation should be done carefully, both for the benefit of the user and the framework developer.

OOFW development is essentially a large scale industrial concept. It gets justified in presence of a family of problem which can be attacked at a more generalised abstract level. The framework then embodies the partial solution to those problems. The need of development of a framework can be detected where there is a scope of having a reusable design (and not just code). The domain of problems must be carefully defined considering various issues like generality, recurrence of problems etc. Developing a framework is a far more difficult and expensive project than developing the solution to an individual problem of the family.
Framework based application development is not a trivial process in itself. Right from choosing a framework over which the application can be built to actually building the application in a neat manner needs learning significantly about the structure of the framework, the assumptions it makes, and the restrictions it imposes.
Issues in the OOFW research mainly revolve around finding specification for frameworks so that frameworks can be derived or aggregated from other framework and also to make them collaborate with other frameworks when both of them are required in the context of a particular problem.

Object Oriented Design and Analysis by Booch: Chapter on Frameworks. This contains an example on how a STL like framework can be built from scratch.
Stroustrup : The C++ Programming Language : Chapter on Library Organisation. This talks about the practical issues of building a standard library, a problem akin to building OOFW.
D'Souza, Wills : Objects, Components, and Frameworks in UML : Chapter 9 : Talks about a framework from a different perspective. Uses preconditions and postconditions and Observers to solve a generic family of problems.
http://www.ipd.hk-r.se/michaelm/fwpages/fwbibl.html. This contains links to a large number of papers. Most of the material in the above article have been taken from these papers. PLEASE VISIT THIS PAGE.

1. What you understand by a framework? An Object-Oriented Framework?
2. About White-box and Black-box framework and their relation to the development stage of a framework?
3. Why it takes more to use a framework than to use a simple library?
4. Various issues that you must consider if you are designing an OOFW?
5. How data encapsulation in OO programming languages impedes use of OOFWs?
6. How control flow presents an issue in using framework and designing them?
7. What problems arise when we want to base our application development on more than one OOFW?
8. What is 'hollywood principle' in reference to OOFWs?
9. Some examples on how Observer pattern can model a non-trivial class of problems?
10.How STLs qualify as an OOFW?
11.How an advanced OOFW like Matlab may be internally structured?
12.Some problems in software which are open to framework based attack?

BACK TO HOME