BRPI0909274A2 - process for automated software generation - Google Patents

Abstract

<B> PROCESS FOR AUTOMATED SOFTWARE GENERATION. <D> A process of automatic generation of source programs based on MDA is proposed. To guide the code generation process, standard markup rules are used, inserted into UML models through lagged values, extensions, and annotations. These rules indicate the architectural interest and design pattern that should be used when generating the source programs. PROGERAS is proposed as an extension to MDA, applying the concepts of ODA and POA to generate source programs automatically from a class diagram (PIM). With this proposal, it is believed that it is possible not only to achieve a high level of automation in the software production process, to enforce the use of standards, to increase quality and consistency, but also to gain productivity.

Description

"PROCESS FOR AUTOMATED SOFTWARE GENERATION" TECHNICAL INTRODUCTION / STATUS

This application proposes a process for generating programs from UML models, as suggested in the MDA (Model-Driven Architecture). MDA is a software development process created and published by OMG (ObjectManagement Group) in 2001 and is based on a set of software development practices and standards through model transformation. The MDA is based on other standards also defined by OMG: Unified ModelingLanguage (UML) for modeling, Meta-Object Facility (MOF) for definition of modeling languages, XML Metadata Interchange (XMI) for model storage, and Query View Transformation (QVT) for model transformation (Mellor et alli., 2005).

MDA is a specialization of Model-Driven Development (MDD), an approach in which analysis and design models are considered to be on a par with source programs, seeking to shift programming work to model building (Stahl et alli. 2006). The goal of MDA and MDD is to develop complete systems in an automated way by linking and transforming models and ultimately generating source programs. The MDA approach defines four categories of models, namely Computer Indepent Model (CIM), Platform Indepent Model (PIM), Platform Specific Model (PSM), and source programs. CIM is used to model business processes and information structure. PIM is a model used to describe the system structure without regard to the platform on which it will be implemented. This model can consist of class, state, sequence, and other diagrams. The PSM consists of a PIM refinement, which is considered a platform specific and deals with the operating system, programming language, platform technology (.NET, J2EE, CORBA, etc.), distribution, among other technical details. In MDA the source program is also considered to be a model, which is the refinement of PSM. The following MDA contributions are highlighted in Biffl etalli. (2007): Productivity improvement combined with time and cost reduction, due to the automation of the generation of models and source programs.

Increased focus on the business as a result of a change in developer focus, working mainly at CIM and PIM to build conceptual models, rather than having to go deeper into logical and technical details.

Increased portability as the same PIM can be transformed into PSM models for different platforms and languages.

Simplifying the change process, as these only need to be done in CIM and PIM, and then propagated to PSM models and programs automatically.

Increased reuse through the reuse of routines and rules of transformation and generation of source programs.

It is known that the use of MDA may result in several improvements, such as: (i) improvements in the portability requirement due to the separation of business knowledge from its implementation in a specific technology; (ii) increased quality due to the use of well-tested standards and practices in the transformation process; (iii) improved ease of maintenance due to separation of interests and greater consistency and generation of trails between models and source programs. However, MDA has a major shortcoming because it does not provide adequate support for the design of the technical architecture project, since the design of the software architecture is not considered in the MDA view. The absence of this feature has been a fertile field for research, which is in the field of Architecture-Centric MDA (ACMDA) and Aspect-Oriented MDA, and that propose the use of POA (.Pattern-Oriented) (Aspeet-Oriented Design). Arehiteeture) and AOP (.Aspeet-Oriented Programming) as a means to extend MDA.

In the Pattern-Oriented Arehiteeture (POA) philosophy, software architecture can be built by reusing ready-made structural solutions, which are the design patterns. The POA can make a number of contributions to increased quality and productivity, such as: • Providing well-known and tested solutions for architectural design, reducing effort and specification risks.

• Provide means for documenting architectural decisions.

• Facilitate communication between project participants through a standardized vocabulary.

• Describe the quality attributes associated with each solution.

According to Aspect-Oriented Design (AOD), software architecture can be designed and implemented based on specification of iarchitectural concerns such as persistence, presentation, auditing, among others. These interests can be specified and implemented by applying design patterns. AOD is derived from Aspect-Oriented Programming (AOP), which is a programming technique that addresses one of the main limitations of object-oriented programming, which is the modularization of architectural interests that cross various elements of software structure (crosscutting concerns), such as persistence. , error handling, security, among others. ODA provides mechanisms for identifying and projecting these interests and then combining them with the rest of the programs. The main benefits of ODA include:

Centralize the location of code associated with implementing a specific feature by one aspect. For example, in the AOP persistence-relevant program is focused on one aspect, which is then combined with the rest of the programs at compile time. This increases action and reduces coupling between architectural elements.

• Automate the program generation process by combining multiple aspects to generate the software. This can result in increased productivity and quality as well as cost savings.

The MDA approach has to address the technical design issue of architecture, which includes addressing non-functional requirements. Some research proposes combining MDA with ODA as a means to deal with cross-cutting interests, and others propose combining MDA with POA to deal with architectural decisions. PROGERAS can be used as an extension to MDA, adding the benefits associated with ODA and POA.

Although MDA has a gap in architectural design, tools that use it provide many benefits to software developers. There is a discussion about the adoption of MDA as a means of increasing productivity and an evaluation based on the use of OptimalJ is also presented. There is an extensive list of source program generation tools compatible with MDA eMDD. Some of them, such as CodeSmith, .netTiers, AndroMDA, MyGeneration, among others, were tested during the design of the process for automated generation of source programs, object of the present application, hereafter called PROGERAS, starting to automate process steps. But all of them run into the limitation of not explicitly leaving architectural choices made by generators when creating source programs and provide limited support for the architect to influence those choices.

This type of approach lacks a formal, standardized and flexible mechanism that allows the architect to indicate what should be generated, as each software has specific needs and should not be generated any more or less program lines and routines than needed.

BRIEF DESCRIPTION OF THE FIGURES.

Figure 1 shows schematically the flowchart of the source program generation process, object of the present application, with the detailing and marking of the code generation model;

Figure 2 shows the process of generating software source programs using a generator;

Figure 3 shows context diagram of the combase code generation tool in PROGERAS Figure 4 shows domain model projections by architectural interest;

Figure 5 shows Templates implemented in the prototype Source Generation Tool (named Genesys) created to demonstrate PROGERAS;

Figure 6 shows an example of the Expense Refund System Domain Model;

Figure 7 shows an example of the Refund System Component Diagram;

Figure 8 shows a Package Diagram depicting the layers of the Refund System;

DETAILED DESCRIPTION OF THE INVENTION

Process for Automated Software Generation

Software architecture consists of a system structure or structures that, in turn, are formed by the software elements, the externally visible properties of these elements, and the relationships between them. Business needs will determine the quality attributes that the system architecture will need to present. In addition to other technical requirements (operating system, language, among others) will guide the architect in identifying relevant architectural interests and in selecting the technical approaches that will be used (design patterns, algorithms, data structures, among others). These technical characteristics are transversal to the functional requirements, which describe the capabilities, services and behavior of the software. Mapping system functionality within the software framework will determine the architecture's support for quality requirements.

The architecture of a software stems from multiple interests, some associated with infrastructure functions (persistence, logging, exception handling, among others) and others associated with business functions, the former being built to support the latter. The way architectural interests are specified vary depending on the quality attributes that the software needs to meet. Each interest can be implemented through the use of well-known architectural tactics (design patterns) that allow you to maximize certain quality attributes. A design pattern may be associated with various tactics, and vice versa. A design pattern may also be associated with more than one interest, and vice versa. For example, in a developer implementation you can create a mechanism to generate Yog track (to support security) or test track (to support ease of being tested).

In the analysis process the architect will have to understand the requirements involved in an implementation and make choices of which combinations of tactics should be applied in order for the system to achieve its quality and functionality goals. In PROGERAS the design patterns selected for implementation of each architectural interest are indicated in the model itself by means of a marking mechanism. The method of choosing tactics is beyond the scope of this process, where only marking and model transformation is considered. Subsequently a tool (a source program generator) will read the marked PIM models and transform them to source programs using the aspectual matching mechanisms.

Process Requirements

As for the model marking and program generation engine, the process is designed to meet the following requirements:

• Use a standardized framework for tagging models based on UML tagged value recurses, stereotypes, and annotations.

• Use tools to automate the process of generating source programs.

• Design the software structure to be generated based on architectural interests and design patterns. The standards are chosen to meet certain quality attributes that the software needs to respect.

• Implement each architectural interest by applying one or more design patterns. • Architectural interests can cross each other, so the process must have mechanisms for combining two or more interests and therefore two or more design patterns, in the process of generating source programs.

• For each design pattern there are one or more templates, which are activated as a function of the tags inserted in the input template. Each mark indicates a joint interest and a design pattern.

• Templates can be input parameters to direct the source program management tool, for example, a connection string, a flag indicating whether or not a given attribute of a class is persistent, among others. The markup rule should allow to indicate the architectural interest, the design pattern as well as the parameters. Together, these elements make up an aspect that will be applied to the model for generating the relevant programs.

• The process is not limited to a specific architectural style, such as LAYER or FILTERS AND PIPES or BLACKBOARD, for example. The architectural style is imposed through the design patterns that the architect applies to the models through the markings.

• The process should not be limited to a specific language, platform or framework.

• The process must be able to be used in conjunction with different methodologies such as RUP, XP, Scrum, among others.

A software development process defines a framework for the tasks required to build a system. The process provides a roadmap, made up of a series of predictable steps, that helps the developer create, within the specified time, an expected quality software product. Developers adapt the process to the specific needs of each project. Typically a process consists of the following types of activities: • Communication: activities associated with customer communication and requirements gathering. For example, identification and meetings with project stakeholders, documentation of desired features and functionality, prioritization of requirements, investigation of constraints and limitations that will be placed on the system, among others.

• Planning: Activities to establish a work plan that describes tasks, risks, resources, work products, and more.

• Modeling: activities relevant to the creation of models. Basically there are two activities of modeling, analysis and technical design. The analysis tasks involve, among others, survey, elaboration, negotiation, specification and validation of requirements for the creation of analysis models. Technical tasks involve, among others, data model creation, architectural design and decomposition.

• Construction: code generation activities (manual or automatic) and the necessary tests.

• Deployment: Activities associated with delivering software to the customer, which assesses and provides feedback.

At PROGERAS the activities focus on technical engineering work, relevant to modeling and construction. Thus, to get a better result this process can be combined with a complementing process, such as SCRUM or PMMI / PMBook, which focuses on management and communication activities - both would complete.

Process Steps

The PROGERAS process consists of a sequence of steps to automatically obtain source programs by using a tool from a UML class diagram. The basic steps of the process are illustrated in figure 1.

Step 1 - Raise Requirements. The first task is to identify the software requirements that will be developed: functional, non-functional and technical requirements. NoPROGERAS is not defined how these requirements should be raised. The work can be done through use cases, scenarios, stories, or any other mechanism. This work is usually performed by a Business Analyst.

Step 2 - Create the Domain Model. The next step is to elaborate the Domain Model, through a UML class diagram, in which the business entities and the relationships between them are indicated. This work is performed manually by a Systems Analyst.

Step 3 - Design Architecture. The architectural design is elaborated by identifying and specifying the architectural interests. For each architectural interest, a design pattern must be associated that enables the software to achieve the specified quality objectives. In PROGERAS, for each project / interest pattern there will be a template for generating source programs. The Architecture Project is run by a Software Architect.

Step 4 - Mark the Domain Model. The next step is to mark the Domain Model. Class diagram elements (domains, classes, attributes, and operations) must be marked based on the architecture design and the PROGERAS Markup Rules standard. Markings indicate the architectural interest and design pattern selected for your implementation. Together, this two information will allow the tool to select and execute the corresponding template. This work is also performed by the Software Architect.

Step 5 - Generate Source Programs. Once the diagrams are marked, they will be processed by a tool, which will receive as input one or more declining diagrams (with markings) corresponding to the PIM model and, as output, will generate as many source programs in a specific language as other more detailed models that show the system architecture after applying the design standards. The tool will process the models and create new, interest-specific models that detail the software architecture. A PIM template will be created for each architectural interest (persistence, presentation, etc.). These models show the structure of the architecture, not considering the technology that will be used in the implementation. This work is also performed by the Software Architect. These inputs and outputs are illustrated in Figure 2, which shows the context diagram of a PROGERAS compatible code generation tool.

When processing the tags associated with PROGERAS, the indicated architectural interest and design pattern will guide the tool in selecting and executing the relevant template. An element, such as a class, can contain multiple tags, each associated with a different template. For example, one class may have a markup for the source program associated with the business layer class (business interest), another for persistence (persistence interest), and another for generating search and editing screens (presentation interest).

Thus the tool, through the templates, will generate the programs from the application infrastructure and then the business rules must be entered manually by a programmer. For this, the programmer must insert new lines of program, in protected areas, in the files generated by the tool or create new classes to inherit those generated by the tool. When the source program is regenerated, the tool preserves the manually entered content demarcated by these areas.

Step 6 - Add program lines manually. The tool may not generate all the source program and a programmer will have to complete the work manually. In this step it is necessary to ensure that the manually added code is not replaced by the regenerated code. For this the new program lines must be added in protected areas, demarcated in the files generated by the tool.

Step 7 - Generate the executable software. Finally, the programs generated by the tool, plus those built manually by a programmer, must be combined into a project and compiled to give the executable application.

Through the PROGERAS process, a complement to the MDA vision is proposed, which focuses on defining standards for modeling and model transformation. In this process a standardized structure of markup rules is suggested to indicate the standards that will be used in the implementation of each architectural interest and a sequence of steps to be followed to mark the model and turn it into source programs. Source Program Generation Tool (robots )

In PROGERAS the source program generation tools are also called robots. These tools receive as input UML marked diagrams and as output generate source programs.

Some architectural concerns, such as persistence and auditing, may intersect. For example, it may be necessary to generate Audit Iog whenever class-determined objects are persisted. In this case the interests of persistence and log generation are being crossed. The tool will need mechanisms to combine two or more project patterns by combining the relevant templates. AOD provides a mechanism for this purpose, which is the use of junction points and addendums. In PROGERAS templates are treated as addenda, and within each template, junction points must be defined. The tool will do the aspectual matching by matching the templates.

Figure 2.2 shows the structure of a generator. The tool will read the class diagram with the markings, saved in XMI format (as defined in the MDA standard), and store it internally through a graph of objects. This model will be processed and converted, also through a transformation module, into a new model. To accomplish this task, the tool will traverse all tagged values of each element (domains, classes, attributes, relationships, and operations) to identify those pertaining to PROGERAS. The tool will apply the indicated design pattern to each interest. By applying the design pattern, new classes and domains will be created, giving rise to a new template. Later this new model will be processed by the code generator that will produce the source programs for a specific platform and language. Then the automatically generated and manually created programs by the developer will be combined and compiled to generate the complete application.

A PROGERAS-compliant source program generation tool will work with multiple templates, one for each design pattern and architecturally interesting. For example, for the sake of persistence, there will be a template that implements the DAO design standard with database access via ODBC and another for DAO that uses the native driver API. The same approach can apply to other architectural interests such as auditing and presentation. The template can generate audit source programs for writing Yog to TXT or XML file. Presentation interest can be implemented with MVC, but there may be a web template and another for desktop applications. Each template is associated with a different design pattern. These elements are represented in figure 2.3.

Marking Rules

In PROGERAS, the marks indicate an architectural interest, as proposed by AOD, and the design pattern that will be used in its implementation, as proposed in POA. Tags are inserted into the model through tagged values or annotations and have the form Variable: = Expression. The variable indicates interest (architectural aspect) and the expression indicates the implementation mechanism that can be an atomic value or can contain a set of one or more parameters, separated by semicolons. Each parameter has the form Parameter = Value, representing the name of the parameter and the corresponding value. A tag has the following structure:

aspAspect: = {Pattern = NAME; [other pattern parameters]}

Here are some examples of PROGERAS brands:

aspPresentation: = {Pattern = MVCWEB; Operations = CRUD;

Screen = Form)

aspPersistency: = {Pattern = DAODB}

aspAuditity: = {Pattern = LOGTXT; Layer = DAL}

In the first example, the tag is associated with the presentation interest and indicates that for this interest the MVCWEB (MVC html) design pattern should be applied. This tag, which should be applied to classes, has two parameters: oOperations, which indicates the CRUD (Create, Read, Update, and Delete) operations that should be enabled on the screen, and the Screen, which indicates the screen format (Screen = Form for form and Screen = Grid for table).

The next example is a persistence interest tag, which will be implemented through the DAO design pattern using relational databases. In this pattern, for each class marked persistent in the Domain Model, a class responsible for reading and writing the data will be created. corresponding objects in the database from the persistence layer. The example indicates that the DAO design pattern will be applied to relational databases (Pattern = DAODB), but other patterns could be used by applying DAO to XML, to CSV, among others. The DAO template can have multiple parameters, as shown in table 2.1.

In the Domain Model marks are inserted to indicate the relevant architectural interests in the application design and the design patterns applied in the implementation of each one. When a tool processes the Domain Model and creates new models, one for each architectural interest, one model entity appears one or more models. An entity can be marked with more than one interest, as shown in figure 4, for example:

• Business interest, to indicate that it is a business entity.

• Persistence interest, to indicate that it will be persisted in the database.

• Presentation interest, to indicate that it will be viewed and updated through

of screens (user interface).

• Monitoring interest, to indicate that object construction and destruction operations will be monitored.

• Among others.

When a template is built, in its definitions it should be indicated the

name of the associated project pattern, the name of the architectural interest, the list of allowed parameters, and the relationship of the files to the source program templates.

Figure 5 shows some examples of architectural interests and design patterns. For each architectural interest there may be one or more implementations of design patterns. Each implementation is associated with a template, which will be used by the source program generation tool. For example, there are three persistence implementations: DAODB, DAOXML, and DAOCSV. The DAODB template generates code for relational database persistence using the Data Access Objects (DAO) design standard, DAOXML generates code for persisting objects in XML files, and CSV in Coma-Separated Values (CSV) files.

The name of the architectural interest will be arbitrarily assigned by the developer who builds the template. However, the structure of the names should be standardized to facilitate their memorization and model marking work. Two different names should be avoided for the same architectural interest, as this would generate ambiguity and make it difficult to use the process and the program generation tool. sources.

In figure 5 there are some name suggestions, which are composed of the prefix "asp" ("aspect") followed by the name of interest. Below, the English language has been used so that the process can be more easily understood by developers from other countries.

<table> table see original document page 15 </column> </row> <table>

Table 1

- Example parameters of a template to generate persistence code.

PROGERAS addresses the transformation of PIM models marked for source programs by applying a direct transformation (no intermediate versions of models are generated). The process consists of a sequence of steps to automatically obtain programs by using a tool from a marked UML class diagram.

In PROGERAS, development begins with the elaboration of the Domain Model and the next task is the creation of the software structure. This framework will be designed by reference to relevant architectural interests, which can be identified and designed based on the non-functional requirements that the application needs to meet, which can be done through scenarios.

Class diagram elements (domains, classes, attributes, and operations) are marked to indicate the design patterns that you want to use in the architecture design. Markings indicate the architectural interest and design pattern that will be used. Together, these two pieces of information will allow a tool to select and run the corresponding template.

A PROGERAS-compliant source program generation tool can work with multiple templates, one for each design pattern. For example, for the architectural interest of persistence, there will be a template for implementing the DAO project standard with database access via ODBC, and another for DAO that uses the native driver API. The following chapter shows an example of using the process and marking rules.

EXAMPLES

Example of Using the Automated Program Generation Process Source

The following description shows an example of applying the PROGERAS process. This example consists of real software that was built for Compugraf® Corporate Communications to automate the process of reimbursing employee expenses. At this company employees can make reimbursements for expenses and study. Reimbursed expenses are those that employees incur in attending a customer or supplier, such as travel, lodging, meals, among others. The company also reimburses university courses, languages and technical courses.

The example presented here has been simplified (due to the size restriction of this text), the original project also deals with reimbursement to third parties (service providers), reimbursement of trips with own vehicle, debit notes between companies, multiple approval levels, among other functions. The original system has about 40 business entities.

1.1. Context

The company has approximately 200 employees, which are spread across four branches, geographically dispersed. Three of them are in the state of São Paulo and one in Rio de Janeiro. Employees at all branches can make refunds.

1.1.1. Expenses

After paying an expense for a customer or supplier, the employee must be accountable to the company to get back the amount spent. For this it is necessary to present the "Expense Reporting Report" with the following data:

• Employee Identification

• Customer or supplier identification

• Project ID (optional)

• Description of expenditure purpose

• List of associated vouchers (personal coupons, invoices, receipts, etc.)

The employee must present this report, plus the accompanying vouchers, to his manager for approval by means of a signature. In the absence of a manager a company director can also approve. Once approved, the report should be forwarded to the financial area, which will account for expenses (by type: meal, fuel, parking, etc.) and accrue the payment. If any proof is not valid, the report may be rejected by the finance department and the employee will have to redo it. Payments occur twice a week, on Tuesdays and Thursdays.

If the employee knows in advance the amount of the expense, he may request a cash advance. This request is made by a manager or director using a specific form, which provides the following information:

• Employee Identification

• Description of the reason for the expense

• Value

The form must be sent to the finance department, which will provide the payment. Then the employee will have to be accountable through the "Expense Reporting Report". If the employee is still a creditor, he will give the amount of the difference, if he is a debtor he will have to return the balance.

1.1.2. Studies

The company has a policy of reimbursing study expenses to all employees who have at least six months of registration. The standard is to reimburse two-thirds of the course fee, and the sum of one-month reimbursements cannot exceed 20% of the employee's gross salary. At the discretion of the manager, the course can be fully refunded and the amount will not be deducted from the scholarship (20% of salary).

Only certain types of courses can be reimbursed, which are those associated with the role the employee plays in the company. These can be university courses, language courses and technical courses. It is up to the employee's manager to evaluate the course and authorize reimbursement, in the absence of the manager a principal may approve. To be entitled to reimbursement, when the employee plans to take a course he / she must complete a "Study Reimbursement Request Form", in which you must enter the following data:

• Employee Identification • Course Description

• Institution

• Duration of the course

• Dates and values of installments

• Refund percentage

• Amount to be deducted from scholarship

The employee must present this form to his / her manager for approval, by signature. In the absence of a manager a company director may also approve. When approving the manager you must indicate on the form whether the refund should be deducted from the scholarship and whether the refund is full (not two-thirds). After the form should be sent to the personnel department. Only previously approved courses may be refunded.

Subsequently, the employee must pay each installment with their own resources and then request reimbursement. In order to receive the refund, the employee will need to complete the "Study Refund Request Report" stating the following information:

• Employee Identification

• Course Description

• Institution

• Date and amount of installment

The form should be sent to the personnel department, which will calculate the reimbursement amount, considering the monthly scholarship and the amounts previously approved by the employee's manager (or a director). The personnel department will forward to the financial department a request for payment to be accounted for and provisioned.1.2. Requirements

The PROGERAS process begins with the survey of functional, non-functional and technological requirements, which will guide the architect in the specification of the architecture and, therefore, in the marking of the model.

1.2.1. Functional Requirements

Considering the refund system, the software should have the following features:

• Consult the employee database (identification, department, manager, salary, hiring date, checking account).

• Provide mechanism for a manager or director to request an advance for the employee.

• Provide mechanism for the finance department to account for and accrue the advance payment to the employee.

• Provide mechanism for the employee to account for expenses.

• Provide mechanism for the employee manager, or a company director, to approve an accountability report.

• Provide mechanism for the finance department to account for and accrue employee expense compensation.

• Provide mechanism for staff to apply for course approval.

• Provide mechanism for the employee's manager, or a director, to approve the course, the reimbursement amount (two thirds or full) and to indicate whether or not the course will be discounted.

• Provide mechanism for staff department to control staff use of scholarship.

• Provide mechanism for the employee to request reimbursement of a course • Provide mechanism for the finance department to account for and accrue a course payment to the employee.

• Provide mechanism for parameterization of reimbursements: percentage of the installment, percentage of salary, payment dates, among others.

1.2.2. Nonfunctional Requirements

The system must meet the following requirements:

• Functionality:

o Accuracy - Refund amounts must be accurately calculated to two decimal places.

o Interoperability - the system should be integrated with the accounting and payroll system, without degrading the performance or security of these systems, for data consultation and updating.

o Security - there must be a configurable security control so that only authorized persons can approve refunds and

payments. Only authorized users will be able to view company employee salaries and change system parameters.

• Reliability:

o Recoverability - In the event of a failure, the system cannot be out of service for more than 24 hours.

• Ease of Use (Understanding, Learning, Operation):

o The system will be used by all employees of the company, spread out geographically. Employees cannot be individually trained in the use of the system, so it must be user-friendly and learned.

• Ease of Maintenance: o Ease of Analysis - the system will be installed on the terminals of geographically dispersed users. In the event of any error it will not be possible to send a developer to the site to analyze and solve the problem. Thus the system will need to generate Yogs that can be sent to IT area so that they can be analyzed, indicating the operations performed by the system plus associated data.

Ease of change - At Compugraf® software factory there are approximately 30 developers (as of the date of writing) and any of them should be able to maintain this system.

1.2.3. Technology Requirements

The company already has other systems in production, and the refund system should be compatible with the existing platform:

• MS-SQL Server® 2005 Database.

• Be programmed in C # with .NET 3.5.

• Use WPF technology to build screens and respect the company's color, font, and other standards (in .NET it's called a theme).

• Be distributed via intranet using ClickOnce technology.

• Can run on Windows XP® workstations, 2MB of memory and use up to 2M hard disk.

• Make access control through the data registered in Active Direetory.

1.3. Domain Model

The domain model, shown in Figure 3.1, is composed of the "Employee", "Repayment" and "Financial" domains. In the "Employee" domain are the entities associated with the data of the reimbursing employees and the bosses who approve: • Employee: A company employee, may or may not be a boss. In this table there are the attributes. name, department, position, salary, date of hire, department manager.

• Company: Company data where the employee is registered. Compugraf® is composed of five different social reasons.

• EmployeeData: Employee data specific to the reimbursement process for expenses and studies, such as monthly scholarship fees, percentage of tuition reimbursement per course, and whether the employee is entitled to reimbursement of studies.

• FunctionalCourse: registration of an employee's course, so that he can make reimbursement for studies.

• CoursePayment: Course installments for the employee to request reimbursement

In the "Refund" domain are the entities associated with the refund requests and approvals:

• TypeExpense: types of expenses for reimbursement request, such as fuel, lodging, taxi, meal, among others.

• Project: Projects executed by the company, which may be associated with more or more employee expenses.

• Expense Voucher: Record of an expense voucher, such as a tax coupon or invoice. Each voucher must be associated with a specific type of expense.

• Reimbursement: Requests for reimbursement of expenses, which must be associated with one or more vouchers when reimbursing expenses or an ongoing portion, when reimbursement of studies. When it is an expense it may be associated with a project.

• Advance: Record of an advance given to an employee. Finally there is the domain "Parameters", where are the entities associated with the system parameterization:

• Calculation Parameters: parameters for the calculation of refund amounts for studies and payment dates, and for accounting for refunds.

1.4. Architecture Project

The Refund System shall be integrated with three other systems described in Figure 3.2:

• Accounting: Integration through a WebService, in which there is a service to send the data of a refund or advance request to accounting.

• Payroll: this system contains, among others, the employee entities and departments. The integration must be done through a DLL, which contains the business objects of this system. The Refund System will instantiate objects and call the relevant methods.

• Projects: In this system are the project entities, project items, payment conditions and others. Integration will be done in the same way as with Payroll.

The Refund System will be layered through the LAYERS design pattern. This architectural pattern is used to divide the architecture into layers to facilitate system deployment and maintenance. Creating loosely coupled blocks with high cohesion. Layers are implemented to communicate with each other respecting a specific sequence of messages. In a well-constructed project, layer A uses layer B services, but layer B does not use A-communication services flowing in one direction. The Refund System will consist of the following layers:

• User Interface Layer (UIL) - In this layer are encapsulated the system screens used by users • Application Layer (APL) - In this layer are the objects and application specific services as mechanisms for report generation, user login function, among others.

• Business Rule Layer (BRL) (also known as Business Services Layer) - this layer provides administrative and operational functionality that the system needs to support. For example, creation of reimbursement, approval, granting of advances, among others.

• Business Entitties Layer (BEL) - In this layer resides the business entities with which business services operate. For example Refund, Voucher, Employee, among others.

• Data Access Layer (DAL) or Object Persistence Layer - in this layer are implemented the read and write functions of business objects, which are implemented in the BEL layer.

• Infrastructure Layer (IFL) - In this layer are implemented services such as error handling, log generation, access control (security) among others that are used by the other layers.

• Data Base Layer (DBL) - Database-associated layer, which in the Refund System will be implemented through MS-SQL Server®.

In order to reduce the coupling between the layers, each layer will be accessed by the others through a facade, applying the FACADE design standard. This pattern causes a single access point to exist, reducing coupling between parts of the system.

Based on the requirements presented (functional and non-functional) the following architectural interests can be identified: presentation, persistence, access control, logging and error handling. In PROGERAS there is no imposition of a standard set of steps to identify architectural interests, in this project an approach to aspect selection was used in programming with AspectJ. Each interest should be specified and constructed as a separate aspect of architecture, which should be implemented through a design pattern. Each design standard is defined to maximize or minimize some application characteristics, such as maximizing performance, minimizing resource usage, facilitating maintenance, among others, which are non-functional requirements. In PROGERAS neither is there a roadmap for selection of standards, in the design of the Refund System was used an approach that proposes the creation of scenarios of quality attributes, to choose the mechanisms that will be used in the construction of the software (implementation of architectural interests).

The submission interest applies to all entities that may be registered by users, such as refunds and vouchers, for example. For each entity presenting this interest, one or more screens should be created, as needed. Screens, which will be encapsulated in the User Interface Layer, must be constructed using a specific design pattern, MODEL-VIEW-CONTROLER or MVC. In this pattern the screen mask (VIEW), the control functions (CONTROLER) and the business entities (MODEL) are clearly separated. OMYC simplifies look-and-feel skins, customizing user preferences, and structural changes. Through this standard these goals can be achieved without having to make changes to the system's core functions and business rules.

The persistence concern applies to entities that will be persisted against database. In this project the persistence mechanism that will be implemented through the DATA ACCESS LAYER (DAL) and DATA ACCESS OBJECTS (DAO) design pattern. The classes that will be generated for this purpose will be implemented in the Persistence Layer. The persistence layer (DAL design pattern) has the function of deabstring the database technology that will be used for the objects persistence function. The DAO design pattern provides an abstract interface to some kind of database (in this example MS-SQL Server®) or persistence mechanism, without exposing the associated technical details. For each persistent business object is created one or more classes in which persistence functions are implemented. The biggest advantage of this standard is that it provides a clear and simple separation of the layers of business and persistence that can evolve independently. Through DAO changes in one layer usually result in little impact on the other.

Through the architectural interest of access control, which is associated with the security requirement, it should be possible to indicate which users can access each entity. This interest applies only to critical entities, such as the employee, for example, where confidential information such as the salary of each employee is recorded. For this purpose the FIREWALLPROXY design pattern should be used. By this standard access permission can be checked each time a service is requested, such as the services provided by the persistence and presentation layers, for example. The generated classes will be contained in the Infrastructure Layer.

Monitoring interest can be applied to the most accessed classes to monitor the volume of query accesses, updates, and additions. In this way it will be possible to evaluate, at runtime, the amount of resource and processing consumed. Monitoring should be done using the HEART BEAT standard. By default, you can monitor a specific task to see if and how it is working. The generated classes will be contained in the Infrastructure Layer.

Error handling interest will be used throughout the system to standardize the mechanism used to handle error situations. The error-handling function will be implemented through the RECOVERYBLOCKS, MINIMIZE HUMAN INTERVENTION, MAINTENACE INTERFACE, SOMEONE IN CHARGE, ESCALATION, and FAULT OBSERVER design standards. These standards provide ways to detect errors, generate Iog and notify someone of their occurrence. The generated classes will be contained in the Infrastructure Layer.

Finally, the logging interest will be used by the mechanisms associated with the other interests to generate logs for future analysis by the system administrator. They may generate logs, for example, of error handling and monitoring functions. The logging function should be implemented through the LEADER / FOLLOWERS design pattern, which allows you to generate low impact Yogs on system performance. These functions will be implemented in the Infrastructure Layer.

1.5. Model Marking

Domain Model artifacts (domains, classes, attributes, and relationships) will be marked to indicate the patterns that will be used in the implementation of each architectural interest. Some examples of tags associated with the "Refund" class are shown in table 2.

All business classes will be marked with the "aspBusinessEntity" aspect, plus the "BEL" standard, to generate the business entity layer (BEL) source programs. This pattern has an additional parameter which is the class label (Iabel), this label will be used as screen title and in error and log messages. For the checked attributes there are also other parameters to indicate if the accept value is null (Null = true), label, validation rules and field size (size). Associated with the "BEL" pattern and "aspBusinessEntity" interest should be a set of templates that will be processed by a tool to generate the source programs.

By parameterizing the persistence interest the architect will indicate the mechanism that should be used for persistence of objects. To use the DAOcom relational database standard, the DAODB standard with the "Write = true" parameter is indicated to indicate that this class allows updating. To indicate that mechanisms should be created to load objects based on the "RefundType" attribute, this attribute is marked with the "ReadBy = true" parameter. To indicate the data storage layer mechanisms that will be encapsulated in the database, the architectural interest of data storage is indicated. The standard "DDL + DML" is used to parade the scripts for creating tables and indexes (DDL - Data Definition Language) plus the scripts for creating the stored procedures to make INSERT, DELETE and UPDATE nestables.

The access control mechanism is generated at the infrastructure layer (IFL) through the architectural interest tag "aspUserAccessControl", which will be built using the FIREWALL PROXY design standard. In the persistence layer of all classes marked with this pattern, a user access permission check will be inserted in all read, update, delete, and include functions.

<table> table see original document page 29 </column> </row> <table>

Table 2 - Examples of brands associated with the "Refund" class

The mechanism for generating Yog is specified through the "aspTracking" interest. The "LOGCG" standard has been defined in Compugraf® to indicate, in each database table's record, the data of the last update made in the registry: username, date and time, system identification used and reason for updating.

1.6. Generation of Source Programs

Associated with each pattern are one or more templates, which will be processed by a tool to generate the source programs. For example, for the sake of persistence, default DAODB, the following templates were created: • DAO.cs - This template is processed once for each persistent entity to create the class responsible for persistence functions. The generated class name will have the prefix "dao", such as "daoReimbursement.es".

• DaoFacade.cs - This template is processed only once to generate a fake, through the FACADE design pattern, for the persistence layer (DAL). The facade will generate methods for loading, updating, deleting and adding objects such as "Refund_ReadObject (long id)" and "Refund_WriteObject (beRefund or Refund)".

• Repository.cs - This template is processed only once to generate a class of database access methods. It has methods to connect, disconnect, initiate a transaction, among others.

The source program generation tool will receive as input the project definitions (programming language, directories where the files will be stored, among other information) and the UML class diagram. Then it will process the diagram and internally assemble a graph with the specified classes and interests. For each interest the tool will list the parameterized patterns and will process the associated templates. The structure of a tool is represented in figures 2.2 and 2.3.

When it is necessary to use a pattern for which ostemplates do not yet exist, they will need to be created before the source programs are generated. It may even be necessary to define a new architectural interest, for example, the interest of distribution, serialization of objects, among others.

1.7. Manual Programming

Business rules will need to be programmed because PROGERAS allows you to specify and generate only infrastructure routines. For example, to create an object for study reimbursement, you need to calculate the reimbursement amount (typically two-thirds of the installment) and the sum of the repayments already paid in the month. In this project parts of the program will be built manually: some screens, reports and some SQL scripts (eg backup scripts) .1.8. Conclusion

Above, an example of PROGERAS application was presented, and it was demonstrated how the process should be used. However, it is implicit to those of skill in the art that the above example does not constitute a limitation of the invention, since it is noted that the process for generating source programs, here called PROGERAS, makes it possible to specify business processes, so that associated routines can also be automatically generated and limited solely in accordance with the appended claims.

The PROGERAS process proposes a process of automatic generation of source programs based on the MDA. To guide the code generation process, standard markup rules are used, inserted into UML models by means of tagged values, extensions, and annotations. These rules indicate the architectural interest and design pattern that should be used when generating the source programs. PROGERAS is proposed to extend to MDA by applying the concepts of ODA and POA to generate source programs automatically from a class diagram (PIM). With this proposal, it is believed that it is possible not only to achieve a high level of automation in the software production process, to enforce the use of standards, to increase quality and advice, but also to gain productivity. List of Abbreviations and Acronyms

ACMDA Architecture-Centric Model-Driven Arehiteeture

ADL Arehiteeture Deseription Language

AOAD Aspeet-Oriented Arehiteeture Design

AOD Aspeet-Oriented Design

AOM Aspeet-Oriented Modeling

AORE Aspeet-Oriented Requirements

AOP Aspeet-Oriented Programing

AOSD Aspeet-Oriented Software Development

CIM Computer-Independent Model

CSV Comma Separated Value

CTI Computer Telephony Integration

IDE Integrated Development Environment,

GUI Graphie User Interface

LOC Lines Of Code

MDA Model-Driven Arehitecture

MDD Model-Driven Development

MDE Model-Driven Engineering

MOF Meta-Objeet Faeility

PIM Platform-Independent Model

OMG Objeet Management Group

POA Patter-Oriented Arehiteeture

PSM Platform-Specific Model

PROGERAS Process for automated software generationUML Un ified Model ing Language

XMI XML Metadata Interchange

FIELDS of Figure 6:

Field A

- Sequence: int = 1

- Expiration Date: Date

- Amount: float = O- Refund Amount: float: = O

- FlagAbaterAuxilioStudy: boolean = true

- DateApprovalBoss: Date

Field B

- Course: String

- Institution: String

- DateStart: Date

- DurationMonths: int

C field

- MaxAuxilioStudy: float

- PercentageRefundCourses: float

- Make RefundStudy: boolean

- UserId: String

Field D

-DateOrder: Date

- DateApprovalBoss: Date

- DateApprovalDirector: Date

- DateApprovalFinanc: Date

- DatePayment: Date- Purpose: String

- Refund Amount: Float

- DateAccounting: Date

- RefundType: String

Field E

- Number: String

- DateEmission: Date

- Value: float

- Vendor: String- Itinerary: String

- Mileage: float = 0

- Note: String

Field F

- Date: Date

- Value: float

- Purpose: String

- Expiration Date: Date

- DateAccounting: Date

CampoG

- PercenbtualRefundStudy: float = 0.66F

- PercenbtualMaxRefundAbout Salary: float = 0.2F

--DayPaymentRefundStudy: int = 20

--DayWeekPaymentRepaymentExpense: int = 3

--PeriodMonthsParalStart RepaymentStudy: int = 6

- AccountingInterval: int

- Advance EventCLT: int

- Advance EventKFD: int

- EventRepaymentExpenditureCLT: int

- EventRepaymentExpenseKFD: int

- LeafRecovery EventCLT: int

- EventRecoverinfoKFD: int

--Refund EventStudyCLT: int

--Refund EventStudyKFD: int

--EvoitNote Event: int

- LimitApprovalDirector: float

- DaysForRequest RefundStudy: int

Claims (7)

1.) "PROCESS FOR AUTOMATED SOFTWARE GENERATION", characterized by the steps of: a) requirements gathering; b) creation of domain models; c) architecture design; d) domain model marking; e) generation (f) manual addition of program lines; and g) generation of executable software. 2. "PROCESS" according to claim 1, characterized in that the architecture project comprises the use of templates for generating the source program. 3. "PROCESS" according to claim 2, characterized in that the templates consist of addendums in which architectural junction points are defined. 4.) "PROCESS" according to claim 1, characterized in that the domain model marking uses marked class diagram elements based on the architectural design and the selected process marking rules pattern for its implementation allowing the tool to select and run the corresponding templat. 5.) "PROCESS" according to claim 4, characterized in that tags are inserted into the model by means of tagged values or annotations having the form Variable = Expression. 6.) "PROCESS" according to claim 1, characterized in that the program generation comprises the use of a tool that receives the class-class diagrams, generating source programs in a specific language, and new models that demonstrate the system architecture. 7.) "PROCESS" according to claim 1, characterized in that the executable software generation is performed by the font generation tool (robots) which receive input UML diagrams and generate the source programs.