|
Sizing and Developing Software Using a Model Driven Architecture (MDA) Approach By Juan Carlos Molina, CARE Technologies Introduction The idea of generating code from models has been implemented in a variety of ways with relative success. Most commercially available tools are UML-based, but the amount of code automatically produced from UML diagrams by those tools is relatively small compared to that of a fully functional application. Consequently, with most UML-based tools, hand-coding is still the most significant phase in the process of applications development and is therefore one of the areas in which most of the effort is put by development teams. Project sizing and cost estimation are, along with the implementation itself, perhaps the two most crucial issues that a project manager has to face. Project managers have to estimate costs and allocate resources to the development of a system before it is built, so they tend to rely on their experience in having built similar systems in the past, and some even use rules of thumb (e.g. estimate the size of the system to be built based on the number of database tables it will have to deal with). This article is about an MDA-based approach that provides developers with a technology that not only lets them define and, unlike most tools, automatically produce fully functional applications but that also automatically sizes (using the International Function Point Users Group (IFPUG) functional sizing methodology) the systems to be developed even before the first line of code is generated. The resulting functional size is then used for calculating the cost of code generation. Thus, this is actually a testimony of how one software service provider has developed its business model around the “cost per delivered functional unit” construct. MDA The goal of the Model Driven Architecture (MDA), promoted by the Object Management Group (OMG), is to clearly separate the logic of applications from the software platform in which said applications are to be implemented. This separation allows reducing the impact that the evolution of implementation technologies has in the development process, thus allowing the same specification of a system to be implemented in different software platforms. MDA turns models into first-class citizens of the applications development process, and renders source code less relevant. Models become the most valuable asset because from them, by means of a set of automated transformations, the source code of the applications can be obtained. MDA does not prescribe that transformations be automated, but it is obviously a desirable feature. But more important than the transformations themselves (and the eventual automation of them) are the languages used to describe the models and transformations. The less precise these languages are, the less productive the transformations are (less code will be produced from models created with these languages). The more concrete these languages are, the more coupled to software platforms (and implementation details) models are. The choice of the words “precise” and “concrete” here is intentional. They must not be seen as synonyms because they mean different things. We can describe something with a lot of precision but that does not mean we have to be concrete. A modeling language suitable for MDA must be abstract and precise: abstract enough so that it allows developers to describe a system regardless of implementation details yet precise enough so that it allows developers to fully describe all the functionality of said system. In the next section we will discuss a technology based on a methodology which uses a specification language with such features. Implementing the MDA Approach Using OlivaNova OlivaNova the Programming Machine (hereafter called OlivaNova) is a technology, developed and maintained by CARE Technologies (www.care-t.com) and sold in the USA by Integranova USA, that enables model-driven software development in a hosted web-based environment. Figure 1 presents its main components. The process begins when the analyst gathers requirements (1) from the stakeholder(s) and uses them to create, with OlivaNova Modeler, the specification (2) of the application to build. This specification is validated by the Modeler, to ensure it is correct, complete and non-ambiguous. Any error found in the spec by the Modeler is reported to the Analyst, who must fix it. The analyst then (3) chooses a set of options (e.g.: target platform– EJB or .Net, target database – Oracle, SQLServer … etc.) to transform the validated spec into a full application. This is packaged by the Transformation Services Client (4) into a transformation request which is sent to a Transformation Services web service that selects the appropriate Model Compiler(s) (5) to perform the transformation (6) of the validated spec into the full source code of the application (7) which is packaged in zip files and sent back (8) to the requestor either directly or as a URL from which said files can be downloaded. The Modeler relies on a formal, object-oriented specification language called OASIS, the complexity of which is hidden by means of a subset of the UML graphical notation (e.g. class diagrams, state machines) coupled with an intuitive yet powerful textual syntax to define, among others, constraints, preconditions, triggers and actions. Users of the Modeler can fully define the functionality of a system from four complementary viewpoints (or models): • Object Model, to specify structural properties of the system to be developed in term of classes, attributes and relationships, as well as the services or operations to create, delete and modify the state of the system • Dynamic Model, to state the dynamic properties of a system in terms of the valid sequence of services that can be invoked on objects of a class and also in terms of the interactions among objects of the system • Functional Model, to define how the state of objects of the system is modified upon the invocation of services (operations) on them • Presentation Model, to specify in an abstract way how users of the system will interact with it
Counting Function Points on Models, not on Code While some of the functional sizing methods apply to code, and some are “guesstimates” using some reference value (such as the number of tables in a database, or the number of classes in a UML model), OlivaNova can actually get the full function point count by doing the count on the model, not on the code. Function Point (FP) is the name of the functional size unit in the IFPUG sizing methodology. Since OlivaNova produces full applications, there is no actual need for manual coding after the model compilation to implement the functionality. Therefore, because the full functionality of a system is automatically obtained from its specification – created by the developer and validated by the Modeler, as set forth in Figure 1 — an automated (repeatable) counting process can similarly be applied to the system specification to obtain its size in FPs. Although the process is quite complex, in essence it relies on the fact that it can map every construct in a system specification to the different elements that have to be taken into account to determine the number of data and transactional functions to which the FP counting rules will be applied to derive the total FP count for the system. Using “Cost per Delivered Function Point” as the Business Model The cost to the developer to use the OlivaNova services depends on the functional size of the system to be developed. Systems are sized in function points and the billing depends on the number of function points of the application delivered by the model compilation services. The good news is that the developer does not have to actually get the system built by the Model Compilers to know how much it will cost: the functional size can be determined prior to using the services. The following scenario exemplifies the implementation of this business model from the developers perspective (names of the individuals and company are fictitious). ACME Corp. develops Java applications with a JSP GUI on an EJB layer which accesses a MySQL database. They bought from Integranova two seats of the Modeler for John Doe and Jack Smith and contracted the use of the JSP and EJB Model Compilers. They were provided with a serial number and a key to register their copies of the Modeler. John and Jack were assigned two passwords to access the model compilation services through the Transformation Services Client, which is packaged with the Modeler. Jack and John are soon assigned to a project for the development of a sales application. After a series of interviews with the customer, using the Modeler, within a week they had created the first version of the specification of the application, which covers pretty much all the requested functionality. Once the spec was validated by the Modeler, they use the Transformation Services Client to get the FP count for their specification (1200 FPs) so they know beforehand how much they will be charged to transform that spec into the full source code of the application. They decide to go forward with generating the code. Jack logs on to the Transformation Services Client – using “ACME” to identify his company, ‘[email protected]’ as his personal identifier (which is also the reply address) and his password – to send a request to transform their specification into JSP source code, and into Java source code on the EJB platform, using MySql as the database. Within minutes, Jacks gets an e-mail with a URL to which he directs his browser. A logon page is presented and Jack uses “ACME” and his password to access the download page from which he gets a zip file containing the JSP code and another zip file containing the EJB code. They compile the source and deploy the application, which is delivered to the customer for rapid feedback. A couple of days later, the customer calls in. He is happy with the application, though he forgot to mention they are missing a service to calculate the expenses of salesmen. Jack and John then create a new version of their spec which includes this service and use the Model Transformation Services to get the new version of the source code for the application. They are not charged again for the functionality that was previously in the spec, only for the additional 6 FPs that resulted from the addition of the new service to the spec, which now totals 1206 FPs for the two versions of the system. Jack and John may need to go back to the model again, whenever the customer wants to refine or add new functionality to the system, but they know that, after each iteration, their will be charged only for the additions of modifications they make, but not for what they already have built. Jack and John use a powerful MDA technology that enables them to concentrate on the problem at hand, not on how it will be implemented (the OlivaNova services take care of that) and they increase their productivity. Their boss is happy to use a technology that incorporates a repeatable and sound way of sizing their developments and, better still, he did not have to buy a set of tools that might end up stored in some shelf: he only pays whenever his developers use this technology. Integranova, on the other hand, leverages FP sizing as a reliable way to know how much their services are being used and, hence, how much they have to bill their customers. Conclusions The benefits that OlivaNova provides to development teams are of two kinds: on the one hand, developers increase their productivity by leveraging an MDA approach to obtain 100% functional applications from models in an automated way. The developers focus on the model, not on code. This results in greater productivity for teams and a greater likelihood of meeting schedule demands. On the other hand, project managers can get the size of the systems to be developed at the very early stages of the project: once they have the initial version of the system specification, before a single line of code is generated or even hand-written. Thus, they know up front what the cost will be for the specified functionality.
About the Author
Author Contact Information
USA Representative for CARE Technologies and Integranova
|
|
