On Incredible India

I just finished my second visit to India – we have two teams in Kochi (Cochin) and Bangalore. Even though the second time, some of the things that surprised me last time did surprise me again. I do not think seeing the whole family (up to four), including kids as young as months old, being on the same motor bike in the crowded streets pushing and shoving with all kinds of vehicles is a sight that one can get used to.

The streets are as crowded (may be worse) as before - pedestrian, autos (three wheelers), scooter, small cars and big cars still walk or drive aggressively. I do not understand why people are not driving orderly – even on a single lane people seem to enjoy crossing lanes in and out. I plan to watch my Indian colleagues how they walk – in a straight line or in a ziz zag. I might get the answer from there. I believe most of them are driving fast because they are in a hurry – if that is the case, their sense of urgency is understandable. There is also the noise factor – ‘driving by ears’ seems to be the necessary skill by drivers to be on the street. Drivers continuously use their horn to signal each other.

It seems everybody thinks that traffic accidents are to be seen as a risk of doing business. Accidents do happen - last time I visited, I witnessed an accident between a motor bike and a car. I did not stay long to learn about the consequence. Even in my current stay, in one of the offices I visited people were wearing the black band on their shirts. I learned later, one of their colleague’s spouse was killed in a car accident.

Apart from the ‘usual’ still India amazes me – the potential the country holds seems to be immense. Cities are full of people – all these people, what can they achieve? I believe, the current trend of utilizing the knowledge workers in the IT industry is not going to be enough to lift India to a different level. I am no economist but seeing the excesses and the poverty level tells you that India needs to do more – a lot more.

So, where to India? How fast can you move?

Are your people only aggressive on the streets? Will they take you ahead to the future the way they drive on the streets?

Do your children work to bring you to the next level with the same kind of sense of urgency they show on the streets?

The future is to be seen – I wish this country to be prosperous and lifting the beautiful, the modest yet poverty stricken lot with her. I love the people, the culture, the food, the music, and a lot more. Both of my visits were enjoyable – I continue to admire the beauty of this country.

Good Luck India!

Currently Reading: Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath and Dan Heath.

On Component Interface, Specification, and Contract

Component Interface is a collection of operations that are used to specify services of a component. It is an abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints describing when they may occur. The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions. The description of a component interface consists of a signature part, describing the services provided by a component, and a behavior part, describing the component’s external behavior. Each operation has zero or more input and output parameters and a syntactic specification associates a type with each of the parameters including a return type.

The specification of a component is different and composed of many parts. Defining which interfaces the component will offer is just part of the whole component specification. Components can implement (export) one or more interfaces, called provided interfaces, and they can also use (import) interfaces, called required interfaces, from other components. The component interface is used both to implement the services and to describe the services so that to allow clients to find suitable services and to understand their purpose, functionality, usage and restrictions. In short, the interface defines every thing the client needs to know. An interface does not specify how implementations of this interface must interact with other components to fulfill their responsibilities; that is defined in the component specification.

While an interface defines a set of behavior, a component specification defines an implementation and deployment boundary. By specifying a set of interfaces that must be supported, a component specification defines the total sum of capabilities of any component created at run time from the implementation. This component specification can also define how the implementation must interact with other components. Knowledge of such interactions does not form part of the interface specification and so cannot be known directly by the client. We define these interaction constraints somehow in the component specification. Behavior is defined as a set of interfaces and a component specification is realized as a component implementation. The basic goal of component specification is to create a set of models that collectively describe externally visible properties of the component and constraint that are applicable to the proper implementation of the component. This goal makes component specification the ultimate guide for use of the component by clients, and for proper implementation of the component by implementers. Clients will pick and choose components based on the component interface. Component implemented based on a specific component specification should exhibit the same behavior regardless of who implemented it, what language is used to implement it, and in what environment it is installed.

Since components can implement (export) one or more interfaces and they can also use (import) interfaces from other components, at a minimum, component specification should provide a contract that states both the services a component offers and the services that it requires in fulfilling its commitments. Contract is mainly composed of three aspects: pre-condition, post-condition and invariant. Pre-condition is a condition that a client must be sure is true; otherwise, it is not legal for the client to use the service. Post-condition is a condition that should become true when the service is executed. Invariant is an observable property that does not change throughout the component’s life-time. Precisely, an invariant property is a property that always has the same value whenever the property is inspected.


Related Blog: On Software Component

Currently Reading: Confessions of an Economic Hitman by Perkins John

On Software Component

The early promises of object-oriented technology to provide reusable software elements did not bear fruit as expected. One of the main reasons for the failure is that objects are too fine grained for large-scale reuse efforts. In order to be reusable optimally, objects need to be coarse-grained in the services they provide and should have a published interface of what services they provide. One of the practices that gained wide spread acceptance in the software development industry through object technology is the practice of reuse using design patterns. Patterns embody accumulated knowledge about proven reusable design elements for software development. The use of design patterns has improved the quality of software and reduced the cost of developing software in object oriented technology for more than a decade.

A business software component is a self-contained and self-deployable (could be third-party composable) software element providing a set of inter-related services described in well-defined and published interfaces. As the natural successor of objects, components are being utilized in small and large scale software developments. Developing software from components promises benefits such as reuse, complexity management, change management, and time-to-market. The idea of approaching software development using components to imitate its hardware counterpart has been around for a while. But what makes the use of components for software development more feasible at this time is the use of objects and design patterns for component development.

Component Based Software Development (CBSD) focuses on development and composition of components through their interfaces. Composition or integration of components to form a functioning system requires designing collaborative behavior of multiple components to form a system based on a specific component model and component model framework. The current component based development is different from previous approaches, even with object-oriented technology, in its separation of component specification from implementation.

I would like to further write some notes on using components. The above paragraphs can be assumed as simple definition/explanation of components and the need to use them.