-

Enterprise Architecture (EA) is a relatively new domain that is rapidly developing. "The primary reason for developing EA is to support business by providing the fundamental technology and process structure for an IT strategy" [TOGAF]. EA models have to model enterprises facets that span from marketing to IT. As a result, EA models tend to become large. Large EA models create a problem for model management. Concern-based design methods (CBDMs) aim to solve this problem by considering EA models as a composition of smaller, manageable parts-concerns. There are dozens of different CBDMs that can be used in the context of EA: from very generic methods to specific methods for business modeling or IT implementations. This variety of methods can cause two problems for those who develop and use innovative CBDMs in the field of Enterprise Architecture (EA). The first problem is to choose specific CBDMs that can be used in a given EA methodology: this is a problem for researchers who develop their own EA methodology. The second problem is to find similar methods (with the same problem domain or with similar frameworks) in order to make a comparative analysis with these methods: this is a problem of researchers who develop their own CBDMs related to a specific problem domain in EA (such as business process modeling or aspect oriented programming). We aim to address both of these problems by means about trends that we have observed in the field of concernbased design and modeling.

Enterprises need to create and maintain the fit between their business processes and their business process support (BPS) systems. This frequently requires re‐engineering of business processes. If the business processes' design rationales are made explicit, the re‐engineering of the existing business processes is easier. Making the design rationales explicit is useful to understand why things exist as they are, and to understand if and how they can be changed. The most common way to capture design rationales is to list the design decisions underlying the business process. In the method proposed in this publication, we capture design rationales through role modeling. We document the design rationales for each role in the analyzed business process. The roles are described as the compositions of ‘base functionalities’. A base functionality is the specification of a role (or of a part of a role) from the viewpoint of one of the specific specialists who designs the business process. These base functionalities are composed together to describe the roles of the participants to the business process. As a result, a business process modeler can understand who is responsible for what in the business processes. In collaboration with the specialists, the business modeler can then ensure that no important part of the business process is missing or is unnecessary. Owing to this work, the business process can be verified before being automated with the BPS system. Copyright © 2005 John Wiley & Sons, Ltd.

Abstract. In this work we consider the behavioral aspects of system modeling. In order to specify the behavior of a system, many different notations can be used. Quite often, different terms in these notations are related to the same element in a system implementation. In order to relate these terms and guarantee the consistency between different notations, a standard framework should be used. In this work we show how the Reference Model for Open Distributed Processing (RM-ODP) can be used for the purpose of the mapping of terms from different behavioral notations. RM-ODP behavior models are based on the concept of Time Specific Action. Time Specific Actions represent directly things that happen in the Universe of Discourse with explicit reference to time. However the explicit reference to time leads to a considerable loss of abstractness. To elevate the level of abstraction we have considered Time Abstracted RM-ODP models where concrete time information is omitted. We used Time Abstracted RM-ODP models to show the correspondence between terms in UML Activity Diagrams, UML Statechart Diagrams and CCS process algebra by means of relating them with RM-ODP terms. This allows us to consider RM-ODP as a possible meta-model for behavior specifications written in UML. It can help to insure the consistency of UML models.