At the moment, enterprises require complex business models with an organizational structures, processes and systems that must be explicitly designed. The work designed by these business models is clearly interdisciplinary, since it requires business development knowledge, different processes enterprises, management of these processes, and technological applications. In the scope of the software engineering would be desirable to obtain a system of methods, tools and techniques that allows the reuse of the best practices during the process of software development according to each one of the processes that are implemented in each domain. This work describes a theoretical methodology proposal framework. The methodology includes from the analysis of the requirements to the monitoring of the processes, supporting the analysis stages, design, model and configuration, through the use of patterns. The methodological proposal is conformed by two macro-processes: one related to the creation of the process itself and other that corresponds to the administration, and it includes: the maintenance, administration of the process in production and the monitoring through management indicators.
The main purpose of this work is to propose a methodology that allows the Management of the Business Processes (BPM), based in the use of patterns [Alexander et. Al.77] [Gamma et al.95] [Buschmann et. Al 96]. This Work propose a taxonomy of patterns and its representation through an Architecture Definition Laguages (ADL) into an architecture of processes, services, and canon objects in the BPM domain. In addition, it opens out the pattern especifications[Acosta, Zambrano04], in order to be able to measure its quality through Attribute-Based into Architectural Styles (ABAS) [Kazman. Klein04]. ISO14-598 and ISO-9126 are used as a quality models of procesess and as the product. Considering this combination of methods, tools and techniques, it proposes a group of steps that in the BPM scope, allows to identify the key processes, to model them and to analyze them, to simulate them, to implant them in an assisted way (Such as new processes as their versions); to evaluate them, monitore them and improve them.
Construction of Software Based on Components
In literature, exists several definitions for "component" In [D' Souza, Wills99] it is understood by "component" as a coherent package of code that: (i) can be developed and distributed independently, (ii) has explicit and right specified interfaces to the service that it offers, (iii) has explicit and right specified interfaces to the services that are reliable from other components; and (iv) can be formed by other components, maybe opens out some of its properties, but without modifying the component itself [D'Souza, Wills99]. A more general definition is given by Jacobson, Griss and Jonsson[Jacobson et.al97] who defined it as an device that has been developed specifically to b e reuse (t his definition will be the one which this article will adopt). In this case a component could be as much as a case of use as any other reusable element tha t will rise during the development processes and it will be used in any activity, whenever it does not require knowledge of the software that uses it.
In the Objects Oriented (OO) approach, the objects can be seen as components, unless they satisfy a dditional guides directed to make auto-contents for them, the use of another components by means of aggregation and generally they interact with other components through the events.
The component used in the development process of software has three main targets: the reusability, the adaptation and the extension (the reusability can imply the adaptation and extension), understanding that:
Last year, we studied among others, two ways of the processes for software development: the agile and heavy methods. The fundamental difference between both of them is that while heavy methods try to obtain the common objective by means of order and documentation, the agile methods do it improving the direct and immediate communication processes between the people who are within. The development processes to consider in this proposal are: Unified Process (UP) as a method of heavy development, XP (eXtreme Programming Project) and FDD (Feature Driven Development) in representation of the agile methods.
If the project is sufficiently large to suggest the adaptation of components from previous developments, it is possible to say that UP is appropriate for the process of software development because it allows to obtain a better structure and discipline. A good possibility of reducing the work is with the reusability of models and processes already defined in a previous implementations of UP in different scopes. Referring to the architecture, XP with the system metaphors tries to determine an optimal architecture in the early stages of its development.Even though FDD is centered in the quality, it leaves all the weight of the architectural decisions to the main architect, but it does not specify how these decisions are related with the quality of the developing system.
On the other hand there is a generalized problem for the development processes UP, XP and FDD: the selection of the suitable architecture or combination of different architectural styles for a software system, is a problem that has not been solved yet and that it has been treated widely in literature. In relation to this problem, the use of components in these software development processes allows:
The growth of the systems complexity, usually constructed through the integration of components, increases the necessity to obtain more rigorous approaches than lead this process of decision. UP, XP and FDD have absence of a clear relation between the components (between these, the patterns), the architecture and the characteristics of the quality associated to the architecture. UP on the other hand, doesn't have an association of the nonfunctional requirements with the use of cases; a bad selection of the main use cases affects the architecture of the system; the model used test to evaluate the architecture doesn't have guides precise to determine this relation. In the next section, there will be a presentation of a new form to relate these concepts, to solve this deficiency.
Establishing the relationship between Patterns, Components, Applications, Processes, Methodology and Quality
In the Fowler book[Fowler97] there is an interesting generic definition: "a pattern is an idea that has been used in a practical context and probably it will be useful in others". The main idea expresses that a pattern can be any "thing". The expression in the practical context reflects the fact that it is developed (some authors prefer: discover) due to the practical experience of real projects. Considering this general definition of patterns, it is possible to affirmed that such can be expressed through components and these, as well as functions that are implemented in different applications (Figure 1).
Fig 1: Relation Patterns, Components, Applications, Processes, Methodology and Quality.
In figure 1, the notches represents a "through" expression, which means that the patterns express themselves through components, the applications through components and patterns, the processes through applications and patterns, all of these within the framework of a methodology (a system that joins the concepts) and where each element must have associated with quality.
The concept of patterns in software engineering [Gamma et al.95], was introduced with the design patterns. At the moment, the software patterns constitute a more general concept, representing applicable conceptual structures in the diverse phases of the development process. In the following section, a new taxonomy of software patterns are set out.
Taxonomy of Patterns
A pattern is a solution to a problem, accepted as correct, which has been received a name and that can be applied in other contexts [Fowler97]. A pattern captures the experience and knowledge of experts, who have produced successful solutions to problems, giving the disposition of a soclution to those with less experience; nevertheless, the patterns do not always provide the definitive solutions, sometimes, the users of patterns must have creativity to use or implement a pattern [Acosta, Zambrano04].
In todays the Software engineering, the patterns can be applied at the level of: analysis of requirements, architecture designs, detailed designs, the interaction with the users and codes. With these the following classification or taxonomy can be set out, according to the abstraction level:
From this hierarchical structuring, it is precise to notice the differences that exists between the types of patterns themselves and from the architectural styles, it is related to its level of abstraction (isolated patterns versus families - languages or catalogues - of patterns).
In general, the patterns have a limitation: they are difficult to specify and to evaluate from a model of a particular quality. For the specifying problem and the taxonomic relation, the use of ADL (Architecture Definition Language), according to the suggested hierarchic proposed and as far as the evaluation of the quality, proposes to use one of the first initiatives of quality measurement in the patterns: ABAS (Atribute-Based Architecture Styles) [Kazman, Klein04], as structures that extend the representation of the patterns, with the purpose to specify the information on themselves and the relative characteristics of quality. These subjects are considered in the next section.
Representation of Patterns and its Taxonomy, through a Language of Definition of Architectures
ADL ( Architecture Definition Language) is a descriptive language that concentrates in the structure of high level application before the details of implementation of its concrete modules [Cod, May99]. A consensual definition of ADL doesn't exist until today, but commonly it is accepted that an ADL must provide an explicit model of components, connectors and their respective configurations. It is considered desirable, in addition, that an ADL provides the support of tools for the development of solutions based on architecture and its later evolution.
A Shaw study [Shaw,Clements96] analyzes the complex influence of the theory and the practice of the patterns on the ADL. This author considers that the ADL have been own of the software architects community, while the patterns and their respective languages have prospered between the software designers, particularly among the groups joined to objects oriented in designs. Naturally, both communities overcome themselves. Concerning to the relation between architecture and design, the maintained discussions have reached a consensus in that these designers operate at abstraction levels lower than the architects, but over the programmers levels[Shaw, Clements96]. On the other hand, Buschmann has documented patterns that are used as architectonic styles governed by ADL [Buschmann et al.96]. Shaw and Clements concluded their analysis alleging that the ADL can benefit incorporating analogous type of elements to the patterns in the sections that refer about styles, groups and rules of design [Shaw, Clements96].
The representation of an architecture of processes, canonical services and objects for its subsequent administration, implies the use of a ADL or a modeled generic language as it could be UML, this would allow to make the association that is explained in figure 1: relating the taxonomy of patterns before described, with the components and the applications, through the process, according to a methodology. In this association, it is necessary to establish measures that allow studying the quality and the audit process of the software construction and its product obtained through it, which is the reason why the next section is the ABAS subject [Kazman, Klein04].
Evaluation of the Quality in the Patterns of Software
An Attribute-Based Architecture Styles, (ABAS) is an information structure, a group that contemplates the pattern descriptions with the quality attributes; it was propose by Kazman, Klein, Barbacci, Longstaff, Lipson and Carriere [Kazman et al.98]. It is defined with a three elements base : (1) the topology of the types of components, and a description of the patterns of data and control, forthe interaction between the components (as in the standard definition); (2) a specific attribute of quality in a quality model, and; (3) the reasoning resulting after applying the attributes of an specific model of quality in the interaction of the types of components.With the purpose of incorporating the concept of ABAS in the taxonomy of patterns exposed previously on this article and taking as a reference the patterns representations from interaction on the base of meta-pattern proposed by Acosta and Zambrano [Acosta, Zambrano04], the following extended representation is obtained:
Table 1 Meta-pattern adapted from [Acosta, Zambrano04] and [Kazman, Klein04]
It is important to mention that the usability of the pattern indicated in the representation of Acosta and Zambrano [Acosta, Zambrano04] is, in this case, a quality attribute. In addition, a pattern does not require, generally, all the elements mentioned before. In order to fulfill its objective, a pattern must have as a minimum the following elements: Name, Problem, Solution and Context.
Business Process Management (BPM)
Business Process Management is an ancient problem. This article tries to study it according to the new technologies, being considered to the potentialities of a model that includes re-usable components.
In the scope of the business processes, the technological solution by excellence talks about the term "workflow", which is the process through the individual tasks that is coordinated to complete a transaction (using the defined processes of the business) within an organization. Workflow is a set of mechanisms that automate the work processes. These mechanisms, related to each other aspects of the administration, establishes priorities between the diverse tasks of each employee and optimize the communications between the different operative units. To obtain this, it is necessary to define which are the different tasks that are built in an organization; who participate in their execution; who are responsible for the same ones; which is the sequence of tasks of each processes and which are the actions that initiate each process. Although the contribution of the traditional workflow (modeled by the WFMC Workflow Management Coalition), it is still remarkable that there is a new generation which perhaps a hybrid that reunites the better things of all the "workflow" systems and other technologies: Business Process Management Systems (BPMS).
The BMPS incorporates ample capacities of integration with modern Java architectures, Net and XML. Additionally, they add other technologies such as Web Services, Business Rules Motors, Business Activity Monitoring (BAM) and Business Process Optimization (BPO). In agreement with Howard Smith and Peter Fingar [Bell03], guaranteed by BPMI (Business Process Management Initiative) and the WFMC, nowadays it can be affirmed that "the BPMS allows the companies to model, implement and manage the business processes, including enterprise applications, departments, and suppliers ("partners"), but without a referential frame integrated" [Bell03].
The BPMS have evolved since the integration of business architectures, where it is contemplated to the transformation and routings of data, administration of events, automatization of processes and the use of adapters in the 90's; to the integration in the 2000 of the business processes through the basic model of the processes, the management of the suppliers, connectivity between companies through the ecommerce and formation of certain groups of processes for vertical industries; until arriving at the actual concept (since 2004) involved: applications of workflow, sophisticated model of processes, monitoring of the activities associated to the business processes (BAM), exhibition of the functions of the applications through web services, use of business rules management, support to multiple devices of access to the information in any place and from any position ("aware-contex") through the use of portals, use of management tools of the life cycle of the software application development that supports the processes, mobile support of the processes and the interfaces, extraction, transformation and load (ETL) of data that are used by the processes and the capacity of simulation on the processes and versioning of them (Bussines Process Optimization BPO).
In spite of all the characteristics before mentioned, the BPMS lacks from a global and integral framework that establishes a methodology for its implementation and use. According to its implementation, most of the software patterns are not supported in a precise form. The market of the BPM architectures tends to concentrate in system flows to system and it is emerging slowly as far as the human-human flow attended by the computer [Bell03]. Based on this, BPMI is the organization which assumes the elaboration of standards (BPA, BPMN and BPMS; analysis, notation and semantics respectively) that sustains the BPM concept focusing on the business process such as the start point between the environment of it and putting it in practice through the technology. At the moment Workflow Management Coalition is being unified with the BPMI and with OMG (Object Management Group).
All the aspects discussed and the deficiencies shown above,lead to the elaboration of the methodological proposal.
2 METHODOLOGICAL PROPOSAL
In this section, there will be a description of the methodological proposal for business process management sustained in the use of patterns, as a form to solve the problems before they appear. Initially, appears an integral theoretical framework; following it with the appearance of the methodological proposal making aspecial emphasis in the aspects of the generation of applications, through the software engineering.
Integral Theoretical Framework
In this integral theoretical framework is outlined a possible solution to the problems shown in this investigation.As shown in the taxonomy of patterns in figure 2, there is a relation between the abstraction level, the type of patterns, and the standard suggestions by BPMI, which obtains a direct relation of taxonomy of patterns with the domain where the methodology sets out (BPM). In addition, the taxonomy of patterns is also associated with its formal definition through an ADL establishing the relation between patterns, components, applications and processes through a methodology. Finally, this taxonomy of patterns is associated with the necessity to measure the quality of each pattern and to establish a mechanism of auditing in the use of the patterns, providing them of specifications of quality with the ABAS use, within the framework of a quality model (ISO9126 for the quality of the product and ISO14598 for the quality of the process).
Fig 2: Integral theoretical framework of the Methodological proposal
The specification, through an ADL, of the levels of abstraction of the BPM architecture that sustains the propose methodology, allows the representation in four layers of the same one: layer of processes where the orchestation is made of itself, layer of services (represent the canonical objects and the services as functions of the applications), application layer (applications, components and software) and layer of technology (hardware). These layers allow the identification of three specific architectures: services, components and applications architecture.
In special, the architecture of services contains the services of: infrastructure management, administration of suppliers or associate, own business applications, applications of legacy, interaction, processes of business, information and connectivity (which allow the communication between all the services mentioned). In a level of abstraction superior to these services, there are services of management indicators and software development, which had the rolls such as business analyst (modeler of the process), architect, specialist of integration, developer and analyst of tests.
The process associated to the software development services has a direct relationship with the process since it manages other one; this process, as well, is defined in the services of process and is the conductor that will allow to administer of integral form the BPMS and that defines a cycle for the management of the business processes that consist of the identification of the key tasks, the model and analysis of the tasks, the simulation and implantation of new processes, and their evaluation and monitoring.
Description of the Methodological Proposal
It can be concluded that at the moment it doesn't exist a treatment sufficiently exhaustive and consolidated of the subjects of business process management sustained in the use of patterns, according to the audit and the quality of the process and the product of the software. By means of this investigation these deficiencies are attacked, and propose the construction of:
The future pieces will orient the construction of one wikipedia for the administration of taxonomy of patterns and its quality in the BPM domain, along with the specification of the ADL and a prototype of low level that supports the implementation of the methodological proposal through a case of study in the BPM domain.
[Acosta, Zambrano04] Acosta, E. y Zambrano N.: Patterns and Objects for User Interface Construction, in Journal of Object Technology, vol. 3 no. 3 March-April 2004 pp. 75-90
[Alexander et al.77] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fidsdahl-King, I., Angel, Sh.: A Pattern Language. Oxford University Press, New York, 1977.
[Bell03] Bell, T.: A BPM Taxonomy: Creating Clarity in a Confusing Market. Gartner Research Note, Technology, T-18-9669. 2003.
[Buschmann et al.96] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., y Stal, M.: Pattern-Oriented Software Architecture: A System of Patterns. Wiley & Sons. 1996.
[Cod, May99] Coad, P., May, M.: JAVA Design: Building Better Apps and Applets. 2 nd Edition. Yourdon Press, Upper Saddle River, 1999.
[D'Souza,Wills99] D'Souza, D., y Wills, A.: Objects, Components and Frameworks with UML. The Catalysis approach. Addison-Wesley. 1999.
[Fowler97] Fowler, M.: Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.
[Gamma et al.95] Gamma, E., Helm, R., Johnson, R., y Vlissides, J.: Design Patterns. Addison Wesley. 1995.
[Jacobson et al.97] Jacobson, I., Griss, M., y Jonsson, P.: Software Reuse. Architecture, Process and Organization for Business Success. Addison-Wesley. 1997.
[Kazman, Klein04] Kazman R., y Klein, M.: Attribute-Based Architectural Styles. Carnegie Mellon Software Engineering Institute Technical Report CMU/SEI-99-TR-022, 2004.
[Kazman et al.98] Kazman R., Klein M., Barbacci M., Longstaff T., Lipson H., Carriere J.:The Architecture Tradeoff Analysis Method. CMU/SEI-98-TR-008, ESC-TR-98-008. 1998.
[Klein, Kazman99] Klein M. y Kazman R.: Attribute-Based Architectural Styles, CMU/SEI-99-TR-022, ESC-TR-99-022: 1-69. 1999.
[Leite00] Leite, J., Hadad, G., Doorn, J., Kaplan, G.: A Scenario Construction Process, Requirements Engineering Journal,Vol.5, N° 1 2000 pp. 38-61.
[Mahemoff, Johnston98] Mahemoff, M. y Johnston, L.: Pattern Language for Usability : An Investigation of Alternative Approaches. Asia-Pacific Conference on Human-Computer Interaction (APCHI'98) Proceedings, 25-31. Tanaka, 1998.
[Ridao01] Ridao, M.: Uso de Patrones en el Proceso de Construcción de Escenarios. Tesis Maestría en Ingeniería de Software, Univ. Nacional de La Plata, Noviembre 2001.
[Shaw, Clements96] Shaw M., Clements P.: How Should Patterns Influence Architectural Description Languages? A Call for Discussion. Computer Science Department and Software Engineering Institute Carnegie Mellon University. 1996.
[Van00] Van Welie, M. y Troetteberg, H. Interaction Patterns in User Interfaces. 7 th Pattern Language of Programs Conference, August 2000, Illinois, USA, 2000. URL: http://www.cs.vu.nl/~martijn/patterns/index.html
About the authors
Pedro Bonillo, Nancy Zambrano, Eleonora Acosta: "Methodologic Proposal for Business Process Management sustained in the use of Patterns", in Journal of Object Technology, vol. 7, no. 7, September - October, pp.131-145 http://www.jot.fm/issues/issue_2008_09/article4/