This paper incorporates the concepts of aspects and software reuse in archetype driven architecture. The proposed work develops the software by partitioning the whole system into different independent components and aspects to facilitate component reuse. The authors illustrate the ease of modeling the components separately and emphasize concerns that the OOP paradigm has failed to address. This paper places emphasis on designing and modeling the software rather than coding. Identification of reusable components is carried out using the hybrid methodology and aspects are identified by domain experts. Along with the components, the PIM and aspects developed are stored in separate repositories to be used in development of other software of similar requirements and basic structure.
TopIntroduction
To survive the cut throat world of competition organizations have started spending most of their time in coding thereby resulting in a software that becomes less reliable, less adaptable since the actual and the hidden needs of the customer are not addressed completely. Moreover organizations are trying to develop the software in a cost effective way so they are using more of the available reusable components. The work presented in this paper describes a design methodology which will help in creating highly reliable, adaptable software products in a timely fashion.
A brief overview of the proposed methodology is as follows. It uses the concept of model driven architecture (IEEE-SA Standards Board, 2000; Jacobson, Christerson, Jonsson, & Övergaard, 1992; OMG, 2011), components (Pour, 1998; Cai, Lyu, Wong, & Ko, 2000; Wu & Offutt, 2003), aspects (Zhang, Chen, Li, & Liu, 2009; Laddad, 2009; Simmonds, Solberg, Reddy, France, & Ghosh, 2005). Firstly the whole software is investigated or analyzed so as to reveal all the details. This includes the hidden or the inferred details along with the concerns corresponding to the software. Then the modeling of PIM and aspects is done separately using UML models. The aspects are modeled as separate entity so as to avoid tangling with the business logic. After the modeling, the PIM generated is stored in the repository for reuse in other projects. Then the reusable components are identified from this optimized platform independent model (PIM) using a hybrid identification approach. After the identification of the components, a repository of the components is maintained for future use. The aspects that are modeled separately are also stored in an aspect repository for future usage. The code for the aspects and software is generated in code generation and artifact generation phase respectively. They are weaved together to provide a complete application. Figure 1 represents the whole methodology with the help of a block diagram.
Figure 1. Brief overview of the methodology
In this paper, the next section provides the literature review corresponding to integration of aspect oriented development, component based development and MDA. The following section describes the research methodology being proposed. The implementation of the methodology and the results and significance of the methodology are then presented.
TopUML Profiles
In MDA, UML profile plays a very important role in expressing the PIM models, the PSM models, and the transformation rules. This profile can also be used as a semantic profile which enables archetype to express specific information. It can also be used for tagging purpose so as to supply more information during archetype transformation and code generation (Jin, 2006; Fuentes-Fernández & Vallecillo-Moreno, 2004).
A UML profile is a combination of stereotype, tagged value and constraints. It uses stereotypes to assign special meaning to designated model elements, i.e., how an existing meta-class may be extended. Whenever a stereotype is applied to a model element, this is shown by either an icon or the stereotype name between guillemets, i.e., << >>. Figure 2 shows an example of stereotype.
When a stereotype is applied to a model element, the values of the properties may be referred to as tagged values. The profile constraints are used to specify the domain restrictions.