Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Using a Software Factory Approach for Customized Modeling

To overcome the challenges of a traditional approach to software solution development, consider the software factory path.


advertisement
The traditional approach of software development faces many challenges, like a paucity of technical skills, poor product quality, and maintainability. These challenges are further aggregated by limited availability of distinctive resources having domain and technical expertise.

According to a survey, the Standish Group Chaos Report 2009, only 32 percent of the total projects are delivered on time, on budget, and with required features and functions. The rest gets cancelled or their budgets are overshot. One of the main reasons for overshooting the budget and timeline is lack of systematic approach to software development that requires an increase in reusability, bringing the manufacturing process in software development.

Software development is a labor intensive work that requires code written from scratch following a prescribed architecture, design patterns, and quality standard. Above all, in a typical development team, few have the required technical expertise and domain knowledge to execute the project. All these factors result in errors bugs in the product, shift of project deadline, more time to market, and overshooting of budget.



To overcome the challenges raised due to the traditional approach of software solution development, we introduce the concept of a software factory.

A software factory is a development approach that automates the software application artifacts generation, therefore enabling the organization to achieve higher levels of productivity by assembling reusable and well-defined components. It also enforces best practices, organizational constraints, customized framework, etc. This approach leverages the knowledge gained and assets produced during previous software application developments. This approach is analogous to an assembly line development mechanism where families of product are assembled together with augmentation of hand crafted customization.

We will deal with software factories in this article. The concept of the software factory will be realized through the Model Driven Development (MDD) approach as both are laid upon the common foundation of platform independence and model driven. Eclipse Graphical Modeling Framework will be used to achieve the same. Some advanced features of GMF like custom images, tooling group, validations, etc will be covered in the article.

As part of a software factory implementation, we will consider banking hierarchy system for better understanding and will generate a sample XML file from the model created by the user. In the real world, any type of artifact can be generated through software factories based on the requirements.

What Is a Software Factory?

A software factory is an approach which automates the software development. Software applications generated are based on end user requirements gathered through an assembly process. This approach increases the reusability, and hence the completion time for software projects gets reduced. Knowledge and assets earned during previous software projects are utilized and only new components of code require traditional way of coding. It increases the level of abstraction by using modelling or visual assembly language. As MDA, software factories also follow model driven approach.

In the following article, we will create a model file and then generate an XML file based on that model. In the real world, an XML file can be replaced by any other artefact e.g. java classes, configuration files, etc.

Let's start with a use case description.

Usecase description

Figure 1: Usecase banking model.

We will consider banking model structure (Figure 1) in our article. As in real world scenario, a bank can have multiple branches distributed across different locations and branches provide same or different services to its customer. For e.g. bank called MoneySafe has branches at New Jersey and Ohio. Consider branch at Ohio provides insurance & loans services and New Jersey branch provides deposit & demat services.

Considering the scenario explained above, model diagram will look like Figure 2.

Figure 2: Usecase description with example.

Before starting the tutorial, let's see how the final diagram editor looks and the output XML file generated from it.

Figure 3: Diagram editor.

Figure 4: XML file generated.

Keeping this model in mind, let's move forward to define our ECore model file.

Step 1: Build a Domain Model

Define domain model file (ecore file) based on model described above. Hence, we will have a node Application as the first node of the metamodel. Application node will have Bank as an EReference child which will have its own set of attributes like name, etc. Bank will have collection of Branches (another EClass) and Branches will in turn have many Services.

Generate EMF model from ECore file. Generated EMF model is then used to generate model and edit code. Right click on genmodel file to generate the same.

Step 2: Customize Graphical Definition

Launch the Simple Graphical Definition Model wizard and load the ecore file just created. Select Branch, Bank and Service as node; branchRelation and serviceRelation as links; and name of each node (except Application) as attribute.

Figure 5: Custom Figure in GMFGraph.

By default, gmfgraph shows a rectangle container for a node. We will use image for displaying nodes. To achieve this, follow the steps:
    i. Delete all children of Figure Descriptor Bank present under Figure Gallery and create a new child of type Custom Figure.

    ii. Given it a name BankFigure and Qualified Class Name as org.eclipse.gmf.runtime.draw2d.ui.render.figures.ScalableImageFigure

    iii. Do the same for Figure Descriptors Branch and Service. Give the name of Custom Figure according to the Figure Descriptor name.

    iv. Now we have to create external labels for all the nodes. Create a new Figure Descriptor BankLabelFigure. Create a child of type Label and give it a name BankLabelFigure. Text property is there to show some default text as label value. Create a child under Figure Descriptor of type childAccess and set its Figure property to BankLabelFigure.

    v. Create the labels for Branch and Service in the same way.

    vi. We will now modify Diagram Labels so that they point to external labels which we have just created. Click on Diagram Label BankName and set its Figure property to Figure Descriptor BankLabelFigure. This will automatically change the external property to true.

    vii. Modify other Diagram Labels in the same way.
This ends our modification to gmfgraph file.

Step 3: Palette Customization

Create tool definition by launching Simple Tooling Definition Model wizard. Select all nodes and connections for palette.

Figure 6: Tool grouping in GMFTool.

By default, all the tools will be created under one group. We will create different tool groups for nodes and connection. Follow the steps:
    i. Create a Tool Group under Palette and name it as Nodes. Move all nodes - Bank, Branch and Service under it.

    ii. Create a Tool Group called Connections and move all connection tools under it. Rename bankBranchRelation as Bank'Branch to give it a more meaningful name. Do the same for branchServiceRelation.

Step 4: Modify Mapping File

This step describes the creation of mapping file. Launch Guide Mapping Model Creation wizard to create the gmfmap file. Select Bank, Branch & Service as nodes and bankBranchRelation & branchServiceRelation as links. After generation of mapping file, cross check all the mappings as sometimes wizard creates erroneous mappings.

Figure 7: GMFMap file preview.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap