Posted on July 4, 2010
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.
a connected subset of a set, not contained in any other connected subset of the set.
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:
- Someone needs to be able to administer and look after the system.
- CVs must be able to be sent to a Recruiter. We shall store them as files.
- Users need to be able to log in and register.
- Recruiters can search for candidates based on their CV information
- People must be able to interact with the system.
- We need a place to store data, we shall use a database.
- This application will be on the internet.
- At the moment, we shall only be serving computers. Not other devices.
- The database needs to be accessed by multiple components.
- 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:
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.