What is Component-Driven Development?

Question

Component-Driven Development term is starting to get used widely, esp. in connection with Inversion of Control.

1. What is it?
2. What problems does it solve?
3. When is it appropriate and when not?

Answer 1

What is it?

I think the definition in your answer covers this question well. Although, I question why the definition includes that a component needs to explicitly define its dependencies. A canonical example of a component is an ActiveX control - do they need to explicitly define their dependencies?

What problems does it solve?

Management of complexity. It seeks to address that by allowing you to only ever think about the implementation of the component. One should only need to author components, one should not to have to think about how to combine or manage them. That is done by some framework or infrastructure external to the component, and unimportant to the component author.

When is it appropriate and when not?

Not necessarily appropriate in a trival or throw-away application. The bad smell in a component architecture, is if you are spending time on thinking or working on the infrastructure to manage and combine components, rather than the components themselves.

Answer 2

I am not sure it is a "widespread" terminology, but in VCS (Version Control System), I know of two ways to manage a set of files needed to build a program:

• system-based approach, where the all set has a common life cycle and must be tagged as a all
• component-based approach, where individual set of files have their own life cycle, and where a meta-label references all the labels of the components to designate the all system by composition and dependencies between those components.

The applicative architecture is used to identify those components:

• functional domain and applications
• third party libraries
• frameworks

That is where IoC comes in, since it is at the base of any framework. The problem it solves is allow you to better identify the part of your application:
Suppose you design a PLR (Profit and Loss) application, in charge to compute the gain and losses (position) of a trader.
You would quickly realize it is not a single application, but a composition of several:

• GUI
• launcher
• dispatcher (to dispatch the computation across several server, because one would not have enough memory to compute all!)
• and so forth

You can then identify a computation framework (Ioc) which would enable you to plug-in your different modules, which then are called at the right time by your framework.

Or you can identify purely technical frameworks (KPI, logs, exception managements) which can then be used by any of your other functional components.

In term of project management, that also allows you to develop each part independently, while assuring a global coordination through the VCS.

Answer 3

Component-Based Development is nothing really new. I don't know of Component-Driven Development, but I am going to assume it's CBD. It's how Unix is designed, bunch of substitutable small programs each doing one thing very well. In desktop arena, Delphi's VCL has been successful at using components with rich reusable components and third party market like no other. We are now seeing the revival of the CBD as some technologies are maturing. For example simple web apps are evolving to SOA and RESTful WS. All Java guys been talking about is modularity and IoC.

The answer you are looking for likely will be found in Why and what of Inversion of Control by Ke Jin.

Besides, the imperative natural of these classic OO programming languages tend to miss the forest (high-level architectures/structures) for the trees (low-level logic control procedural code). Development and maintenance engineers taking over an existing application have to rely on its out of date design/architecture documents and low level code comments/patterns.

The component-based development (CBD) paradigm tackles the two issues above by shifting plumbing logic into frameworks that manipulate components and set up applications based on users/developers provided declarative descriptions. Contrary to the common confusion, such declarative descriptions are not meant to be application setup scripts. Rather, their fundamental intention is to explicitly express application architectures/structures without mandating their imperative plumbing procedures (namely describe the what instead of the how). The goal of CBD paradigm is to support effective and flexible application compositions by these frameworks and having application developers focus on business logic and domain issues without concerning low-level plumbing complexities.

CBD frameworks that combine the declarative application descriptions and the IoC technique are referred to as IoC frameworks. Contrary to their predecessors, IoC frameworks are non-invasive and use the dependency/configuration injection/setting scenario.

According to Wikipedia, Component-Based Development is an alias for Component-based software engineering (CBSE).

[It] is a branch of software engineering, the priority of which is the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.

This is somewhat vague, so let's look at more details.

An individual component is a software package, or a module, that encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). Because of this principle, it is often said that components are modular and cohesive.

So, according to this definition, a component can be anything as long as it does one thing really well and only one thing.

With regards to system-wide co-ordination, components communicate with each other via interfaces. [...] This principle results in components referred to as encapsulated.

So this is sounding more and more like what we think of good API or SOA should look like.

The provided interfaces are represented by a lollipop and required interfaces are represented by an open socket symbol attached to the outer edge of the component in UML.

_{(source: wikimedia.org)}

Another important attribute of components is that they are substitutable, so that a component could be replaced by another (at design time or run-time), if the requirements of the initial component (expressed via the interfaces) are met by the successor component.

Reusability is an important characteristic of a high quality software component. A software component should be designed and implemented so that it can be reused in many different programs.

Substitutability and reusability is what makes a component a component. So what's the difference between this and Object-Oriented Programming?

The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. [...]

Component-based software engineering, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics.

Answer 4

Here's my definition after doing some research.

Component-Driven Development is an approach in software development in which code is fragmented into reusable and testable components that are combined together to form application foundation for delivering business functionality. The combination and management of components is usually delegated to Inversion of Control Container.

A component itself is a class that implements some service contract and explicitly defines the dependencies that it needs in order to fulfill this contract. Actual implementation is hidden from everybody else outside the component.

Related links:

• Component-Driven Development and IoC Container

Answer 5

I view Component-Based Software Engineering as an approach to developing software systems through the use of pluggable components; with a component being "a unit of composition with contractually specified interfaces and explicit context dependencies only", which "can be deployed independently and is subject to third-party composition." (Clemens Szyperski, "Component software : beyond object-oriented programming")

CBSE facilitates code reuse and rapid assembly of flexible/adaptable software systems.

There's a substantial research that has been focused on this topic for years. The flagship event (ACM SIGSOFT Symposium on Component Based Software Engineering) is in the 14th year now and there are quite a few new trends emerging.

Also, if you want a good example of reusable, pluggable and extensible components, heavily in use by industry today, take a look at MS Enterprise Library.

Answer 6

If you're interested in combining components (or other reusable assets) into applications you should also take a look at the software product lines methodology.

In a software product line the dependencies between components (or lower-level code elements) are explicitly managed outside those components. This is typically done using a feature model that contains rules such as

• These two components must not be used together (mutual exclusivity)
• If this component is used then this other component must be used or (interdependency)
• Any combination of some specified set of components may be used (optionality)

Other more complex rules are possible depending on the complexity of the dependencies you wish to model.

Another approach that is sometimes used instead of feature modelling is to use a code generator to configure the different components that are to be assembled into the finished application. It's also possible to combine feature modelling with code generation.

Aside from Code Generation, some other terms you might search for as domain-specific modelling, model-driven software development, software family.

Answer 7

You will never understand what is really Component-Driven Development, untill you try to use Unity 3D. It is not ActiveX or anything you ever seen before, what you have seen before has another Component meaning.

Component-Driven development, about every one talking lately, means, you have 2 things:

1. Object - which is just like an object in OOP programming or real world object.
2. Object's Component - which is like part of Object's functionality or one of it's Abilities.

Thus: Component - is not an Object. It is - Functionality of an Object.

So, in standard OOP programming, when you need to extend Base Object with new Functionality, you have to make new Derived Object by Inheriting Base Object.

In Component-Driven development, when you need extended Object, you just create Empty Object and fills it with different Components, without any Inheritance. In Component-Driven development there is no Classes, there is Prefabs instead - which is predefined Objects with predefined Components, with Children Objects.

As i said you will never understand untill you try. With component-drived development you dont have to always use programming, you may use graphical editors instead, and also it frees you from Inheritance Hell of typical OOP. Components itself programmed with usual programming, but higher level system, including objects, mostly only need to use and combine Components in Editor and receive customized objects behaviour.

Thus: Component-Driven Development gives you:

1. Great power to create your programm's logic, by using just an Editor, without programming.
2. Frees your mind from OOP Inheritance Hell. Makes development more simple and fast.
3. Makes your programm highly customizable and scalable without even touching code. Less errors and bugs.
4. Easier maintain your programm's code, by just reprogramming specific components, without much effecting rest system.
5. etc...

I also wanna add, that Component-based(driven) programming is not replacement for OOP programming, it is on TOP of OOP or usual programming. Usual programming still used in CBP for low level Component's implementation. I think this article also have good and short explanation of CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf