Software Architecture and Components

Len Bass defines Software Architecture as follows:

Len Bass: Software Architecture in Practice (2003)

The Software architecture of a program or computing System is the structure or structures of the System, which comprise Software components, the externally visible properties of those components and the relationships among them.

Does this help? Maybe... The above definition tells us, that the architecture of a software system comprises components. Obviously the next question is: what are components?

The word component itself is derived from the latin word componens which means something that is composed of several parts. But composed of what parts?

Using object-oriented technologies it seems obvious that components implement a specific interface. So far so good. But what about building a component? Is there a building plan or a specification to see how to create a new component?

In our opinion, the structure of a component is something domain specific. Usually, a complex software system consists of several different component types. A Service Oriented Architecture may specify components of type Service and components of type BusinessObject and the relationship between these components.


No matter how many Services or BusinessObjects our system will be built of, the conceptual component architecture shows us how components are structured and interconnected.

As you can imagine, building up new components is following specific rules. Since components are spread over several tiers in complex software systems, we do have to implement several aspects per component: GUI, persistency, business logic, etc.

Imagine a system where you could define your conceptual component architecture. And imagine a system, where you could specify specific components according the conceptual component architecture.

actifsource allows you to specify your domain-specific conceptual component architecture. Doing so, specific components may be entered along your concept.

Every element is fully type checked at real time. And of source there is a type-sensitive content assist.

But the most thrilling thing comes now: Since we know exactly how a component is structured, we can provide generic code to build up any specific component.

Due to our specification a Service always comprises ServiceCalls, while a ServiceCall comprises Parameters. Knowing these conceptual facts, we can write a class for every Service, which contains a method for every ServiceCall.

But instead of writing a method for every ServiceCall manually we let our computer do the tedious work.

The next picture shows the actifsource template editor. The orange bar on the left hand side indicates the repetition for every specific ServiceCall.



Conclusion
A software system consist of components. Defining the conceptual structure of these components and their relationship allows us to enter well defined and specific components. These component might be checked among their concept.

Since components are well defined, generic code might be written only once for every component type.

Limitations
Note that the above is only true for the structural aspects of a component. Specific algorithms have to be still coded manually. But 3rd GL like Java, C++, etc. are doing a great job for this kind of work.

In our experience, a complex software system contains up to 70% of structural component code which can be generated.