Universidade Federal de São Carlos – UFSCar, Departamento de Computação – DC,

This paper presents a Component -based Framework Development Process, of the Cardiology Domain. The Framework, called FrameCardio, was developed in 4 steps: 1 Problem Domain Definition, 2-Components Specifications, 3-Components Internal Design and 4 -Components Implementation. In the first step the framework requirements were identified, based on experiences in the development of a cardiology system with 320 classes. The main models specified in this step are the Use Cases, Actions and Collaborations Models. In the Component Specification step component external behaviors were defined with their responsibilities, operations and interfaces. The main models are the Types Model, that describes an object external behavior, regardless of implementation decisions, and the Component Interactions that details the behavior of each case used in the Sequence Diagrams. Right after, in the third step, the Specified Components are refined, considering the implementation technologies. Among the models of this step, the components Classes Diagram, Components and the Component Packages stand out. The modeling was supported by a CASE tool. Finally, in the Components Implementation step the components code was generated in the ObjectPascal language, using a Transformation System. FrameCardio was structured in layers and organized in components packages, available in the CASE tool, to be reused by the applications. In the same way as in the development of FrameCardio, the Transformation System is used to generate the ObjectPascal code of the applications. A Cardiology domain Application is presented to show Framework components reuse.


INTRODUCTION
The reuse is an essential principle in Software Engineering to assure the reduction of efforts and costs in the Software Development and code redundancy.Different Software Development Processes have been researched to improve the software production.Researches have been exploring different technologies, including the use of CASE tools (Computer-Aided Software Engineering), frameworks, Software Transformation System and objectoriented programming languages, to obtain high quality software with affordable cost.
Aiming to improve the Software Development Processes, this paper presents a Component-Based Framework Development, accomplished in four steps -development for reuse and development with r euse.The first three steps, responsible for modeling the framework, are accomplished supported by a CASE tool, and correspond to the three levels of the Component-Based Development Catalysis Method [1].The fourth step is responsible for the Components Implementation in ObjectPascal language [2], and it is supported by a Software Transformation System, called Draco-PUC [3,4].The framework components can be reused (development for reuse) in the Cardiology domain applications, facilitating the modeling, reducing the code redundancy and the costs of the maintenance.
To facilitate the applications development (development with reuse), reusing the framework components, the CASE tool Rational Rose 2001 [5] is also used, for modeling, and the Draco-PUC Transformation System to generate ObjectPascal code.The code in the ObjectPascal language is generated from the descriptions of the applications project specifications.The class structure and the component interface codes are generated with their atributes and methods prototypes.Based on the code, specified by the Software Engineer, for the methods behavior, we can have a more complete implementation of the applications.
To support the development of the framework FrameCardio and the Applications, different technologies are used: a) The Component-Based Software Development Catalysis Method; b) Draco-PUC Transformation System, for ObjectPascal code generation; and c) The Object-oriented language, ObjectPascal, for implementing the framework FrameCardio componentes applications, according to the Software Development Processes proposed.
This paper is organized in the following way: Section 2 presents the main technologies integrated in the development process; Section 3 presents the Component-Based framework Development Process, for a Cardiology domain; Section 4 presents a Case Study, of an application reusing FrameCardio; and, finally, Section 5 presents a conclusion of this research project.

MAIN TECHNOLOGIES OF COMPONENT-BASED SOFTWARE DEVELOPMENT PROCESSES
The Catalysis Method is presented, used in the Framework and Applications modeling, in the CASE tool Rational Rose 2001.

Catalysis Method
Catalysis is a Component-Based Software Development that integrates techniques, Patterns and Frameworks.Catalysis began in 1991 with of OMT and had influences of the methods Fusion [6] and UML [7,8].It supports the characteristics of the oriented-object technologies like Java, CORBA and DCOM and its notation is based on Unified Modeling Language (UML).
Catalysis is founded on three principles: Abstraction, Precision and Pluggable parts.The Abstraction guides the Software Engineer in search of the essential aspects of the system, deferring details that are not relevant for the system context.The Precision aims to reveal mistakes and inconsistencies in the modeling and the Pluggable parts seek the reuse of components to build other components [9].
Software Development Processes in Catalysis follow the characteristics of the Spiral model of the Software Engineering [10], a nd is divided in three logical levels: Problem Domain, Components Specification and Components Internal Design, corresponding to the traditional activities of the software lifecycle: Planning, Specification, Design and Implementation, that are executed in an incremental and evolutionary way, resulting in the generation of a new version of a prototype to each accomplished cycle.
To facilitate the modeling, according to Catalysis, the CASE tool used is Rational Rose 2001.

Draco-PUC Transformation System
In the Draco-PUC Transformation System, a domain is composed of three parts, Language, Prettyprinter and Transformers, according to Figure 1.The language is defined through its grammar and its parser, that analyze any program of the domain, and generates its internal representation in Draco-PUC.This internal representation, named Draco Abstract Sintaxe Tree (DAST), is used to apply the transformation components to generate a new DAST in the same or in another domain.The prettyprinter is responsible for showing the DAST, in the textual form, oriented by the domain language syntax.The transformers are transformation components packages that act in a DAST, to generate a new DAST, according to Figure 1.The Draco-PUC Transformation System was used as a main mechanism for the code generation of FrameCardio and their applications.To support the code generation two domains have been built: MDL (Modeling Domain Language) and ObjectPascal.The UML specifications, modeled in the CASE tool, according to Catalysis, are stored in a textual descriptions file.Based on these textual descriptions language, the MDL modeling domain has been built.To generate the ObjectPascal code from MDL descriptions, the ObjectPascal domain has also been built.The transformations that generate code, are based on the grammars of these both domains, MDL and ObjectPascal, and are partially presented in Figure 2.

ObjectPascal Language
ObjectPascal is the Delphi enviroment Component-Based development language [11].The Visual Component Library (VCL) [12] is a hierarchy of classes, written in ObjectPascal, that supports the applications development through the reuse of components and Object Inspector, using the latter for inspection and definition of objects.
Figure 3 illustrates the main screens of Delphi, where the windows with Tool Bar, Components Page, Object Inspector and Form Designer and its Source Code stand out.

Components Paletes Tool Bar
It begins with the common requirements of the Cardiology domain, to build components to be reused by the applications of this domain.The horizontal lines (blue) separate the steps of the development process, according to the levels Abstraction of the Catalysis Method: Problem Domain, Components Specification, Components Internal Design and Components Implementation using Transformations, shown to the right of Figure 4.

Define Problem Domain
In the Defining Problem Domain step the Problem Domain terminology, the business process understanding, the actors' roles and the collaborations to specify the behavior of objects group of the cardiology domain have been defined.The main interactions models used in this step were the Use Cases, Actions and Collaborations.The identified requirements are specified initially by the Businesses Rules that state the Problem Domain u nderstanding, represented in a Collaboration Model, including associations and use cases, reflecting the existent processes.Figure 5  Professionals and doctors of the cardiology area and a software system of the Heart Institute of Marília (ICM -Instituto do Coração de Marília-SP) were the main sources for requirements identification.The ICM software was developed and implanted by one of the authors that has been accomplishing its maintenance since 1997.
Meetings, interviews, legacy systems studies and observations of the system use sceneries have been used in the requirements identification.With the system in use, new requirements came along and, as time passed by, updatings have been made necessary to follow the technology changes.All these experiences were i mportant to know the Cardiology domain, facilitating the Framework development.
Through the Collaboration Model refinement, in search of a better understanding of the framework functionalities, the main actions of the system are defined specifying the use cases.The use cases represent the actors' use sceneries.
Figure 6 illustrates the Use Cases Model, obtained from the Collaborations Model refinement of Figure 5. Actions can be modified or added, as for instance, the use cases registerPatient, registerDoctor, registerAppointment and sendAppointment, identified starting from the Accomplish Appointment action.

Specify Components
In the second step, Specifying Components, the components external behaviors were defined, with their responsibilities, operations and interfaces.

Figure 7 -Types Model
The main model is the Types Model, that describes the external behavior of an object, regardless of the implementation decisions.Figure 7 illustrares the Model Types obtained from the Use Cases Model refinement.The notation < > indicates the types that can be reused by FrameCardio applications.
The types are related through associations, aggregations or inheritance, with the respective cardinality, that states the minimum and maximum occurrences of participant objects of a relationship.Another model specified in this step is the Interaction Model, represented in Sequence Diagrams witch detail the Use Cases behavior.

Design Components
Then, in the Design Components step, the Components Specified, in the Types Models and Sequence Diagram, are refined, considering the implementation technologies.
The Components Model represents the components physical architecture, with their interfaces for connection and their dependences, specified from the Classes Model refined of the Types Model.In this model we have the components interfaces, represented by little circles.An interface specifies the services accomplished by the component.A component can accomplish several interfaces, supplying a group of methods able to implement the services specified in the interface.
The connection among the components, or between a component that has access to the services of another component, occurs t hrough the interface and is represented by a dependence relationship.Figure 8   The first layer, User Services, provides component for development of graphic and visual interfaces.The second layer, Business Services, provides components of the cardiology area, in three packages: Appointment, Surgery and Decision.These packages are reused by different Cardiology domain applications.The third layer, Data Services, provides access components to relational databases, that are used by the business rules.
Other available packages, as the one of Delphi components, can be reused, as the Model of Figure 9 shows.
The three-tier architecture makes the components reuse possible, increases the independence and facilitates the applications portability, that can be written in different languages, to access different databases managers and to use the same business rules.
This organization in tiers turns the system more flexible to support the technological changes without damaging its structure, increasing its life cycle.

Implement Components
The components are implemented based on their Internal Designs.The Draco-PUC Transformation Systems was used to generate ObjectPascal Code, from the components design MDL descriptions.
Figure 10 shows the Transform 'Classes_ModeloLogic', that recognizes the specification of a class in MDL, in the control point LHS and generates the correspondent ObjectPascal code, according to the substitution pattern specified in the control point RHS.

CASE STUDY
It is about a Medical Service System to the Patients in the Cardiology Clinic.The patient is assisted in the reception of the Clinic by an employee and led to the cardiologist's room.The appointment is accomplished and the results are registered in the database.The Doctor can verify if the Patient had already been registered in the system and update his information.
A presentation of each step of the development of this application is proceeded: Model Application, Implement Application and Execute Application.

Model Application
Initially, the Software Engineer, in the CASE tool, models the application according to the first level of Catalysis.The application requirements are specified, concerning about their business rules.Figure 13 illustrates the main application use cases, with an abbreviation description, their entrances and exits.Figure 13: Use Cases -Application The use cases are modeled, in Use Cases Diagrams that show the actors interacting with the system.Figure 14 illustrates, for instance, the doctor actor interacting to accomplish an appointment.In this level of the problem, the actors' relationships with the use cases are suitable sparing details that are not relevant for the system context.

Implement Application
In this step, the application is implemented in a component-oriented language.In this case, the application specifications, stored in a MDL file, are transformed, by Draco-PUC, into the ObjectPascal language.The code is generated based on the Classes Models of the application components.Interface components, generate another file, with .DFM extension, containing the definitions of the graphic part of the interface.

Execute Application
In this step, the Software Engineer imports the generated code, in the Delphi enviroment, to execute it.In Delphi, the code is gathered in an application project to facilitate its management.The implementation in ObjectPascal, generated in the Implement System step, cannot be enough to assist all the requirements, mainly the non-funcional ones, related with the interface, safety, validation of data and access to database.Thus, the Software Engineer, using the visual resources of Delphi, can complement the project with other components that implement these requirements.The code generated by Draco-PUC, integrated to the code developed in Delphi, results in the implementation of the whole system.With the whole system implemented, it can finally be executed to verify if it suits to the specified requirements.In case of problems, or new requirements, the previous steps can be refferred to for corrections or additions of new requirements and, again, re-implement the system.
Figure 21 illustrates, to the left, an interface component generated and, to the right, FrameCardio FCValidateAppointment's method, being accessed by the IAppointment Interface of the Appointment Component.In the CASE tool, reusing the FrameCardio components, the Component-Based Application Design is obtained.The descriptions of the MDL specifications, that represent the design, are used to generate the code of the system in a Component-Based language.Draco-PUC Transformation System automated great part of the ObjectPascal code generation, of the framework and their applications.
Integrating an environment of visual programming, as Delphi, with the propose Software Development Processes, was possible execute the application to validate the specified requirements.In t he final version it can be added, in the Delphi environment, components that treat the non-functional requirements, that had not been treated in the modeling of the system.A cycle of life of the software, that generates archetypes, facilitates the purification of the components, through successive refinements.The use of software components reveals each time more important to speed and to facilitate the Software Development Processes.
Due to the capacity of Draco-PUC Transformation System, of supporting different modeling domains and application, other languages, different from Catalysis and ObjectPascal, can be used in the proposed Software Development Processes.Although the process has been instanced for the Cardiology Domain and its applications, the authors believe that the steps of the presented processes and the integrated technologies to support it, can be used for the development of frameworks and applications of other domains of applications, particularly the similars.
Software Development Processes proposed give one more step in the automation of great part of the Software Engineer tasks, which can contribute in the reduction of time and of development costs of an application of the Cardiology Domain.

Figure 1 :
Figure 1: Parts of a domain in Draco-PUC Transformation System.

Figure 3 :Figure 4 :
Figure 3: Delphi Enviroment.3 DEVELOPMENT OF FRAME CARDIOFrameCardio was developed (development for reuse) in four steps: Defining Problem Domain, Specifying Components, Designing Components and Implementing Components, according to Figure4.
Figure 5 -Collaboration Model

Figura 6 -
Figura 6 -Use Case Model illustrastes a Components Diagram, eliciting their interfaces and associations.In this case the TAppointment component is connected with the TPatient component through the IPatient interface.

Figura 10 :Figure 11 :
Figura 10: MdlToDelphi Transform Figure 11 illustrates, to the left, the TAppointment Class MDL specification, and to the right, the correspondent ObjectPascal code generated.In this case, the specification object Class "TAppointment" created Type TAppointment, that implements a derived class of the TQuery class of Delphi.The specification object Operation InsertAppointment created the procedure FCInsertAppointment.The specifications object ClassAttribute IdAppointment and

Figure 14 :
Figure 14: Use Case Model accomplishAppoint In this first level, the Types Model of the application is still specified, concerning about "what " the application should do to assist their requirements.It is a model of high level of abstraction of the Problem Domain, where the essential types of the application are searched.Figure 15 illustrates a Types Model in this level of the development.

Figure 15 :Figure 16 :
Figure 15: Model TypesThen, according to the second level of Catalysis, the models of the first level are refined, specifying the application components.In this level the Software Engineer concerns about the identification, behavior, and responsibilities of the components.Figure16illustrates the Application Model, obtained from use cases refinement, with the main types imported

Figura 17 :
Figura 17: Application Class Diagram Finally, in the third level of Catalysis, the Software Engineer specifies the Internal Designs of the C omponents, giving emphasis to their implementations and physical distributions.Figure 18 illustrates the Class Diagram of the Appointment component, obtained from the Types Model refinement, with its interface.In the IAppointment interface are the methods prototypes, implemented in the TAppointment component.In this case the validateAppointment, deleteAppointment, insertAppointment and selectAppointment methods.

Figure 18 -
Figure 18 -Component Appointment Class DiagramFigure19illustrates the application Components Model, where the components reused from FrameCardio, are indicated by the placeholders "<" and ">".We can observe that just the FormAppointment, Appointment and DSAppointment components, are specific of the application <<Application>>.The others are from FrameCardio or from Delphi itself.The stereotypes <<FrameCardio>> and <<Delphi>> illustrate the Framework components.

Figure 19 :
Figure 19: Application Component Model.4.2 Implement ApplicationIn this step, the application is implemented in a component-oriented language.In this case, the application specifications, stored in a MDL file, are transformed, by Draco-PUC, into the ObjectPascal language.The code is generated based on the Classes Models of the application components.Interface components, generate another file, with .DFM extension, containing the definitions of the graphic part of the interface.Figure 20 illustrates, to the left, part of an unitDM.pas,with the ObjectPascal code, of the Appointment component of the application and, to the right, the correspondent Diagram that shows the reuse of the FrameCardio implemented components.The Patient and Doctor components were connected with the Appointment component, demonstrating the Components "Plug-Ins" principle of the Catalysis Method.
Figure 19: Application Component Model.4.2 Implement ApplicationIn this step, the application is implemented in a component-oriented language.In this case, the application specifications, stored in a MDL file, are transformed, by Draco-PUC, into the ObjectPascal language.The code is generated based on the Classes Models of the application components.Interface components, generate another file, with .DFM extension, containing the definitions of the graphic part of the interface.Figure 20 illustrates, to the left, part of an unitDM.pas,with the ObjectPascal code, of the Appointment component of the application and, to the right, the correspondent Diagram that shows the reuse of the FrameCardio implemented components.The Patient and Doctor components were connected with the Appointment component, demonstrating the Components "Plug-Ins" principle of the Catalysis Method.unit UnitDM; interface uses SysUtils, Classes, DB, DBTables, FCDatabase, UnitDoctor, UnitPatient, UnitAppointment; type TDM = class(TDataModule) Patient: TPatient; Doctor: TDoctor; Appointment: TAppointment; FCDatabase1: TFCDatabase; DSPaciente: TDataSource; DSConsulta: TDataSource; DSMedico: TDataSource; Figure 20: ObjectPascal Code Generated