Component Based Development – Part 1

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

I make no bones about it, I adore components. I think the overheads are less, they lend themselves to efficient, simple and effective logic behind systems and most importantly, open up systems accessibility in a secure, managed and most importantly, controlled way.

So what is a component?

Well the linguistic definition is:

a constituent part; element; ingredient.
This means that the component is but one part of the whole, while being a whole itself in its own personal context. I however think that the mathematical definition of component is what lends itself most to CBD (component based development):
a connected subset of a set, not contained in any other connected subset of the set.
This in short translates in programming speak that it is a loosely coupled system that is not part of any other loosely coupled system except through interaction as part of a collaborative system. Large components in these systems will sometimes be referred to as “Focal Systems”. A focal system is a system that concentrates on only one noun or object and deal with the logic for that noun/object.
So now we know what components are, how do we go about ascertaining what makes a component, what doesn’t and how on earth do we get them working together as a whole for your system?

What makes a component?
When analysing your brief in order to find your technical specification for your system, the first thing you should do is find out what your potential objects are. The easiest way to do this is to go through your brief and identify all the nouns in that brief. For example:

I need a system that registers users and provides services in order to download cvs for recruiters. Different types of cv will then determine the type of job they can be put forward for. A widget will be available to recruiters to search for cvs.

From this short brief, we have identified the potential objects of “users”, “cv”, “recruiter” and “job”. Now we are sensible programmers and we can see that “recruiter” is actually a person and therefore a type of “user”. We can also make an assumption here that there are people sending “cvs” and receiving “cvs” thereby giving us two different types of “user”. Here you have now a parent object and two children objects of the whole object: “user”. We also know that a widget is an interface and therefore will not be an object, but something that accesses different objects.

Now we have the following object list: User, Job, CV. By ascertaining your parent objects and their children, you have your first draft list of components! The User component will deal with all types of user and recruiters and “candidates” as we shall name the other type for now, will be handled by this component.

Now we have to look beyond the brief and use our own knowledge of what other objects we shall need. We can now make the following assumptions:

  1. Someone needs to be able to administer and look after the system.
  2. CVs must be able to be sent to a Recruiter. We shall store them as files.
  3. Users need to be able to log in and register.
  4. Recruiters can search for candidates based on their CV information
  5. People must be able to interact with the system.
  6. We need a place to store data, we shall use a database.
  7. This application will be on the internet.
  8. At the moment, we shall only be serving computers. Not other devices.
  9. The database needs to be accessed by multiple components.
  10. Components will be accessed by 3rd party applications.

From this assumption list, we can add admin to the user component. We know that the database layer must be accessible to all, as well as this, I know that I am going to need functionality to generate and process files. I am therefore going to create a library full of functional activity that is not an object in the brief such as my database and file generation functionality. I am also going to create the component display so that users can interact with my system. I also know that only one type of device will be using the system so I do not have to incorporate device management into my display component. I also know that my cv component needs to interact with my user component in order to link up cvs to users. Therefore I’m going to create a services component in which the system will use to return an instance of any other component to itself. I also know that a widget from outside the system will be accessing my data, so I will also make a gateway component in order to manage 3rd party connections to my system. I also really like the Zend Framework library, so I will be using this.

So my list of components is now:

  • User
    • Recruiter
    • Candidate
    • Admin
  • Job
  • CV
  • Services
  • Gateway
  • Display
  • Library
    • Database
    • File
    • Zend

Now we have identified our components, we can start analysing each one and putting them together in a sensible fashion!! We shall begin to do this in part 2 and of course finalising and evolving our component list as we continue to analyse our system’s architecture.


One Comment on “Component Based Development – Part 1

  1. Thanks a lot for sharing this information. I’m starting a project and I’m struggling, and fearing that, at end, something goes really bad! I’m not comfortable with design patterns, at all, however, I would love to properly architect what could the programme structure will be. I have a huge database UML that it sure helps, but I was wondering how can we pass from that, to classes definitions… your post really shines on that part.

    Thanks again

Leave a Reply

Your email address will not be published. Required fields are marked *

WP Socializer Aakash Web