Component technology creates a new horizon of rapid development of robust software or system. Software architecture and software development process are quite important in both component based and non component based software development. Successful and efficient software development depends on the appropriate architecture design and right choice of software development process in a large extent. Here, we have discuss and describe on component based software architecting and software development process. Our discussion also consider component reusing which is one of the important aspect of component base software development.
Now a day's component becomes the key of robust software development. It gives the development team independence of emphasizing more on requirement analysis than coding and other basic development issues. Again, component framework helps to develop and maintain component base system rapidly and reliably. But one of the important property of component is that component should be black-box. Most of the time, the client does not know about the implementation inside the component. System only provides the requirement of the component and on the other hand it gets some services. This property of component arise some challenges.
Get your grade
or your money back
using our Essay Writing Service!
In software development, software architecture and software development process are two vital issues. System assessment and evaluation, configuration management etc. are depends on software architecture. Again, software development process describes various method and phases of developing reliable, efficient software in an efficient way. Here, we discuss on these issues in the context of component based software engineering.
In section 2, we discuss on the basic terms of component based development. In section 3, we describe component base software architecture. Later in section 4, we discuss on component development process.
Defining basic terms in component based development
For deploying a component independently, it should be clearly isolated from other components and the environment. Component communicates with the environment through the interface. That's why component should have a well defined interface. But the implementation should be encapsulated inside component which is not possible to access from the environment directly. This property makes the component a third party deployment.
Interface is separate from implementation in component that is the special feature of it. But this separation is different from other; like in some programming language declaration is kept separate from implementation. Again in object oriented programming, class definition is isolated from class implementation. So the main difference from the object oriented programming or other to component is that component requirements, component integration and component deployment is independent to component development life cycle. That is why, when we want to replace an older version of component with newer version, no need to recompile or re-link the application. The visibility of the component is exclusively through its interface. According to Aoyama, component can be composed at runtime and component detaches its interface from implementation where component detailed will be concealed. The academic concept of component is that it is often small, having understandable functional and non functional features, black-box because having explicit boundary that restricts the external access. In industry, component is a large piece of reusable having complex internal structure and does not have well-understood interface. Interface is the access point of the component. Interface does not offer any implementation of any operation. To upgrade the component only implementation has to be changed, no need to change the interface. Again, new interface can be added without modifying the preexisting interfaces. In this way, component adaptability is possible to increase.
Interface in component technology can express functional property. Functional property is consisting of signature part and behavioral part. Signature part contains the operation description perform by the component and behavioral part describes the behavior of the component. Interface Describing Language (IDL) is a language to define interface. But IDL mostly concentrates on signature part. IDL does not describe about extra functional properties like accuracy, availability, security etc.
Interface is two kinds. They are export interface and import interface. Export interface describes the service provided by a component to the environment. On the other hand, import interface describes what is required from the environment to component.
Contract describes the behavioral part of the component. Contract describes every operation in term of precondition and post condition. Pre condition is the requirements which have to fulfill by client to get output from the component. Again, post condition is the functionalities which are promised by the component to fulfill in return. Contract also describes the interaction among the components.
Always on Time
Marked to Standard
Pattern is recurring solution to the recurring problem. Pattern is three kinds. They are architectural pattern, design pattern and idioms. Architectural pattern is a high level pattern which describes on system structure, interaction between subsystem, system property, system goals etc. Design pattern is a low level pattern which describes on component, interaction between components, subsystem design etc. Idiom is low level pattern depending on the programming language and chosen paradigm.
Framework is a skeleton of application which is possible to customize. It provides the context where the component can be connected to make a system. It helps for rapid and reliable development. As an example, MVC (Model-View-Controller) is a frame work where every part is possible to develop and maintain independently. There are three kinds of framework. They are technical frameworks, industrial framework and application framework. MVC framework is an example of application framework.
Component based software architecture
Software architecture and software components are closely related. We can state that software architecture and software components are the two sides of same coin. Software architecture defines how the component will integrate, work and interact in the system. It is a structure where component and connector are comprised and interacting with each other. System functionality and behavior are the functional properties of the component.
Software architecture has three main uses. They are assessment and evaluation, configuration management and dynamic software architecture.
Assessment and evaluation is three kinds. They are stakeholders based assessment, expert based assessment and quality attribute.
In stakeholders based assessment, the requirements of the software architecture should be matched with the priority requirements of stakeholders. If the software architecture is giving more priority on requirement A over requirement B, but the stakeholder's priority more on B than A, then it is a mistake. ATAM (Architecture Trade-off Analysis Method) and SAAM (Software Architecture Analysis Method) can be used to evaluate the software architecture.
In expert based assessment, a team of expert architecture and designer determine whether the system architecture design by the project team is fulfilling the functional and quality requirement or not.
In quality attribute assessment, the target is quality assessment of quality attribute providing by the software architecture. These quality attributes are like maintainability, performance, reliability, security etc.
Configure management is the systematic process of identifying the physical attribute and functional requirement to handle the change, integration and traceability. The software architecture can be used for configuration management.
Dynamic software architecture means a software architecture which recognize and response to the dynamic requirement changes. It is dynamic because software architecture is used to aid in modifying system during operation. It is in experimental phase.
Architecture design process
We can divide the architecture process in three phases. In the beginning, full specifications of the requirements should be available. Then In the first phase, a requirement from the full requirement specification is selected to produce the functionality-based architecture design. It is consists of four stages. They are defining the boundaries and context of the system, identifying of archetypes, decomposing system in main components and first validation of architecture by describing a number of system instance.
In the next phase, the design should be assessed to determine how much the design is fulfilling the functional requirements. If the design is good enough or even better to fulfill the requirement then the designing for that requirement is complete. Otherwise, it will enter into a new phase. Various assessment techniques are available for doing the assessment in the phase. They are scenario based assessment, simulation, static analysis, metrics -based models and expert-based assessment etc.
In the third phase, the design process concentrate on selecting design solution to improve quality attribute which was traced in previous phase. For doing so, the design structure is changed a bit. This is called transformation of design. The transformation produces new software architecture. Then the new software architecture goes to the previous assessment phase for being assessed again. If it is failed repeatedly to meet the requirement then the software engineer will decide that is there any feasible solution exist or not. The architecture process is depicted in figure 1.
Figure 1: Software architecture process .
This Essay is
a Student's Work
This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.Examples of our work
Wang Chengjun  discusses on architectural driven component development for top down software reuse based on architectural based software design where the software architecture development process is similar to our above discussion. He also divides the process in three activities. They are goal decomposition, architecture defining and validating. The process is also called divide and conquer approach.
In the goal decomposition activity stage, the system goal or requirement specifications are divided into sub-goals and then assign to components. This activity creates the relationship between goal and components called Î³ relationship or "Responsibility-Assignment" relationship.
In the architecture defining activity stage, the architecture design is constructed and created relation with component. So, this activity describes the relationship between architecture and component which is called Î² relationship or "Take-Part-In".
In the validating activity stage, the system architecture design is checked to determine whether it is fulfilling the functional requirements or not by considering the relation between system goals and architecture which is called Î» relationship or "Achieved By".
The component specification, component description and behavior are also considered for architecture development process. By this process, the developer can trace which component satisfies business goal when a problem arises in maintenance phase of software product line.
Many architectural styles are available in component based software development. We will discuss on pipe and filter architecture, blackboard architecture and object oriented architecture.
In pipe and filter architecture style, the component type is filter and the connector type is pipe. Here pipe receives streams of data as input from filter and then delivers this data streams to another filter as output.
In blackboard architecture style, components types are either repository or data processing component using repositories. Here data are available in the repository locally. The data processing elements interact with repositories by scanning the repository for required input and then process it. When the data processing is finished then the output is written to the repository.
In object oriented architecture style, component type is object and connector is synchronized message passing and procedure call. The component or object has various states which are modified by methods. The methods are invoked via connectors for manipulating the object.
The component architectural style effects on the quality attribute. From table 1, we can observe how much the architectural style effects on the quality attribute. Positive and negative relationship between quality attribute and architecture style determine by the degree of concurrency supported by the style, degree of which component can directly interconnected, degree of which data shared by the component etc.
Table 1: Architectural Styles and Their Affinity to Quality Attributes .
The pipe and filter architecture style allows concurrent access of the filters. In that case the architecture has a positive effect on performance. Again for doing so, large amount of data is required which has a negative effect on performance. In blackboard architectural style, large amount of data is shared by the repository and bad data is read immediately by all components which are attached with the repository. That is why it is not good to design a safety critical part of a system by using blackboard architectural style.
Architecture driven component development and Component driven Architecture Development
When software architecture is briefly defined in terms of components and connectors, then it is the time to embody the architecture by using components and connectors. Custom build components and preexisting components are used to embody the software architecture.
The custom build component is a component which is built in the organization for specific purpose. These kinds of components are built by the organization to meet unusual, safety critical or highly secure requirements.
The organization sometimes has some preexisting components. Preexisting components can be again two categories. One is reusable components and another is commercial components. Reusable components are those components which are already developed by the organization for previous developed system. The organization can make a component without the intention of reusing but it can be reused in the new system. Again a component can be developed for reusing purpose. When a component is reusing in a new system, all the time it is not used directly. Sometimes it is required to do some mechanism for adaptation of the reusable components. In that case, adapter is needed to develop to adapt the reusable component.
Component also can be built by vendor for selling it to the market. This type of component is called commercial component. The organization can also reuse preexisting commercial components for new system. The commercial component introduces a large number of uncertainties, lack of visibility, complexity and instability due to the impact of market demand. When the market demand increases then the vendor has to expand feature, as a result complexity increase. Again, it is always unstable because pressure of the marketplace never lets up.
The framework is the skeleton of system which can be customized or a structure which provide an environment to develop system in a predefined disciplined way. It gives the facility of building system rapidly and reliably. On the other hand, it has some restrictions like it restricts direct interaction among the components.
Sometimes, we must have to use the preexisting components and components might not allow to access source code. In that case, we have to consider the reusing of preexisting components more than the system architecture design. This situation also can arise due to use of framework, availability of limited number of components and their integration nature. In that case, the system architecture is designed by considering the components and called component driven architecture development.
Component development process
Overview on software development process and life cycles
Most software engineering projects use two types of approach in their development. They always give more effort to develop their business related functions. Other functions get less attention from them like general purpose functions. For this reason, the reuses of software components from earlier projects are increasing day by day. It is less time consuming, less costly and overall development effort is increased. Reusing existent components and producing reusing components introduce a new concept in the context of software development. This section describes different software process models, component based development and component based software life cycle.
Software process models are divided into four parts. These are generic lifecycle activities, the sequential model, evolutionary development, and unified Process. All the process models are based on the generic lifecycle activities. Generic lifecycle activities are described in table 2.
Table 2 Generic Life-Cycle Activities 
Each activity is used in every software process models. Sequential model is the most widely used software development process model. In sequential model each step starts after finishing the previous step. There are lots of disadvantages of sequential model. For example if any change in requirement comes from customer in the later stage or during development then it is not possible to contain that requirement into the software. To get clear explanation of software requirements at the early stage of development is a challenging task.
Software development is completed through a repetitive process in evolutionary development. This process decreases the risk of detecting crucial and expensive difficulty at the later stage of development. Evolution development is partitioned into three parts. These are iterative approach, incremental model and prototyping model. Unified process model is designed for object oriented and component based system. It is made up of four phases. In construction phase products are developed with reuse ability. Other phases are inception, elaboration and transition.
Component based software development works with reuse technology. Component models, component frameworks and components use reuse technology which are part of component based design. The main hypothesis of reuse technologies are as follows:
All experience can be reused;
Reuse typically requires some modification of objects being reused;
Reuse must be integrated into the specific software development;
Analysis is necessary to determine when, and if, reuse is appropriate.
CBSE (Component based Software Engineering) especially concentrates upon questions related to components and in that sense it differentiates the process of Component Development from System Development with Components. Component development focuses on using well specified, easy to understand, easy to adapt, easy to deliver, easy to replace components. On the other hand system developed with component deals with identifying the reusable units and connection between them; pick out most appropriate components, testing them etc.
In the consumers point of view components should be selected by considering some questions like if a component fails who will responsible for the failure, how will changes in a component in the system affect the behavior of another component?.Consumer needs to select components by concerning to the component life cycle.
From producer point of view, producer should remember some issues while developing a component like business goal, component functionality, and maintenance policy etc. In term of component disposal policy there are two types. One type is while component doesn't support the system or the system doesn't need that particular component; another one is while producer is not capable to give component support or maintenance.
Component based software life cycle is divided into two processes one is building only components and another is building components with system. There are several steps in the component based software life cycle. These steps are described below:
Requirement analysis and definition: In CBD (Component Based Design) requirement analysis is divided into three tasks. First task is capturing system requirements and defining system boundaries. Second task is to define architecture to permit component cooperation and third task is to identify component requirements to develop component successfully.
Component Selection and Evaluation: There are several ways to select component. Technical aspects of estimation include integration, validation and verification. Non technical aspects of evaluation include market position of component supplier, maintenance support etc. There is a process to choose component, it is called procurement-oriented requirements engineering . This process selects component from a list of candidate components after a number of evaluation of them. In many cases, it is better to evaluate a set of component composed as assemble than to evaluate a component.
System Design: In term of CBD, system design depends upon the selection of component model and overall requirements. Component model states the cooperation between components and provides the infrastructure to support this cooperation.
System Implementation: In CBD process, system implementation is appraised by the effort which is given to write the glue code. If right component or component model is not selected then the cost of the glue code is increased.
System Integration: While integrating CBD system several issues should take into consideration. Component should adapt with system requirements. In some cases a wrapper that will manage the components inputs and outputs must be developed even if a new component is needed to fulfill the particular requirement of a component, then it should integrate into the system. In the case of using composite components conflict may arise because more than one composite component may use the same basic component. For this particular situation a mechanism should exist to reconfigure assemblies. Until the integration of component is executed it is essential to include a test procedure as a part of integration.
Verification Validation: In CBD, component must be verified and validated separately. Inspection and testing are the way of verifying and validating a component. Component requirement must be checked in this stage as well as component assemblies. Component integration dynamically into the system is monitored. To detect component's run time error and prevent it's propagation to the system different mechanism like wrappers  is used.
System Operation Support and Maintenance: System maintenance and support are same in component based system like non component-based System. One difference is existence of components even at run time which makes it possible to update component easily without reconstructing the whole system. Maintenance of component can be a complicated matter because sometime it is unclear that who is supporting, system vendor or component vendor.
System development and component management is a complicated process. They overlap in many stages of development. For this reason there may be another parallel process which is called component development process. It is same like system development process. Figure 2 describes component development process as well as system development process.
Figure 2: Left side shows Component development process. Right side shows System Development process .
The difference is that components are build keeping in mind of reusability. Component requirement analysis is a difficult job because component requirement may be unclear, incomplete, inconsistent or even unknown. If component requirement is stable then it is easy job to develop the component. The more reusable a component is, the more demands are put on it. To modernize with new requirements new version of components are released frequently. Designing a reusable component requires more effort because it is designed to serve in different system. Therefore reusable component is designed in a more general way. Component specification is very important to reuse component frequently. To make component reliable, producer can certify them.
Comparisons between different software development life cycles
The paper  describes three life cycle process model for CBSE. The processes are Sommerville CBSD process , Ivica Crnkovic V process model [5, 6] and Luiz Fernando Capretz Y development model . The paper  shows similar lifecycle activities among these models. It also explains the challenges solved by the different process models and the difference among the CBSD processes. Table 3 and 4 describe the difference among CBSD processes and challenges solved by the lifecycle model.
Table 3: Difference among the CBSD process .
Table 4: Challenges addressed and solved by lifecycle models .
We have discussed on various definitions and specifications of component based software development. Later, we have discussed on component based software architecture, the uses of software architecture and various kinds of architectural style. Finally, we have discussed on software engineering process. We have also discussed on some recent relative work [2, 3] on software architecture and lifecycle.
We have realized that it may be hard or impossible to adapt the existing component in a new system for reusing. Sometime, it is required to implement the functionality that can convert the effort for developing component base system like the effort to develop a non component base system. Again, component based software development is a new field of software engineering. The architecting models and software development processes in component based software development is less than non component based software development. So, a lot of research work is needed in this field.