analysis pattern systems and OO (Object Oriented) models. (a UML notation). Architectural and Design patterns systems and Domain Applications architectures ...
A Reuse Infrastructure Based on Domain Models Regina M. M. Braga Cláudia M. L. Werner Marta Mattoso {regina, werner, marta}@cos.ufrj.br Computer Science Department- COPPE/UFRJ Federal University of Rio de Janeiro – Brazil
Abstract Reuse is a key component in the software development process, specifically when it is applied in the early phases of the process. One of the most encouraging reuse techniques available is the component-based software development. Based on this assumption, this work presents a reuse infrastructure to help the component-based development of applications in a given domain, named RIDOM. Object-oriented frameworks, software architectures, artificial intelligence techniques, domain analysis and OODBMS are technologies that RIDOM1 uses to make component-based reuse feasible in a specific domain. The innovative approach of RIDOM reduces the semantic gap between the specification and the software development. Key Words: Reuse Infrastructure, Component-based development, Domain Analysis, Object-Orientation, Software Architecture, Frameworks, Patterns, OODBMS.
1. Introduction Reuse is a promising way to help improving software development. One of the most encouraging reuse techniques available is the component-based software development. The component-based software development employs interrelations between preexisting components and the reuse of components that have been exhaustively tested to reduce complexity and costs of software development. When the aspect of productivity in software development is considered, the efficiency of a certain reuse technique can be measured in terms of the cognitive distance between the 1
This infrastructure is an integrant part of two research projects of COPPE/UFRJ, sponsored by the CNPq agency. One of these projects involves the research on Domain Oriented Software Development Environments, and the other deals with distribution and parallelism in OO databases.
initial concept of a system and its final implementation. Thus, in the context of a component-based software development process, the application of reuse techniques in the early steps of the development must result in the reuse of components when the application is implemented. To meet this requirement, reuse must be applied to all phases during the development process. Therefore, the domain concepts that were considered as reusable in the initial development phases must be closely related to the code components that will be used during application implementation. A reuse infrastructure based on abstract domain concepts can help in the effective application of reuse during software development, since it can provide methods, tools and procedures for the specification of domain models and applications. There is no infrastructure to our knowledge that is capable of addressing all these aspects together. The works found in the technical literature [9], [10], [14], [15], generally concentrate on one aspect or another (see section 7 for details). In order to increase the productivity and reduce the cost of software development, we propose a reuse infrastructure, named RIDOM (Reuse Infrastructure based on DOmain Models). The main feature of RIDOM is its ability to encompass the whole cycle from conceptual models to component implementation. The key RIDOM technologies are: • domain models that are representations of the different domain concepts found in various abstraction levels. These domain models comprise three model types: 1) conceptual models that represent the domain concepts in a high level of abstraction; 2) design models, or Domain Specific Software Architecture (DSSA), that represent the way the domain concepts are composed to allow specification of applications. These architectures also represent the way in which operational requirements, such as distribution, performance requirements, and others, will be further aggregated to the domain concepts; and 3) implementational models, such as frameworks [5], that represent the domain reusable components and their mutual relationships, as well as the way in which these components will be aggregated to the applications that will be further developed;
• Domain Engineering (DE) [4]: utilization of a suitable process for the specification and evolution of the domain models; • adoption of a method to systematize the DE process, allowing the creation and utilization of domain models according to the development paradigm (i.e., objectoriented, structured, event-based, etc.); • an object manager, providing a direct representation, storage and management of information from the domain models. In this work, we present the main aspects involved in the specification of RIDOM. This infrastructure has been conceived as a framework where conceptual models, DSSA and implementation models are specified for previously selected application domains, using: model representations that are suitable for the context; a consistent DE process; a DE method; and a set of services that allow the direct representation, storage and management of the RIDOM components. Our main contribution in this paper is to present the specification of the RIDOM infrastructure, that combines concepts found in component-based development and domain engineering. The remainder of this work is organized as follows. Section 2 presents an overview of the infrastructure; Section 3 presents the technologies involved in the representation of the domain models; Section 4 describes some of the technologies involved in the process of creation and utilization of the domain models; Section 5 deals with the technologies and concepts used in the specification of a DE method that suits RIDOM; Section 6 discusses the current object management technology, presenting the requirements for representation, storage and manipulation of RIDOM components; in Section 7, we discuss some related works; and, in Section 8, we present our final considerations.
2. An Overview of the Reuse Infrastructure The main goal of RIDOM is to provide mechanisms for software development based on the concept of reuse. To attain this goal, RIDOM has been conceived as a framework where conceptual models, software architectures and implementation models are specified for previously selected application domains, as shown in Figure 1. The conceptual models are represented by the analysis pattern systems and OO (Object Oriented) models (a UML notation). Architectural and Design patterns systems and Domain Applications architectures are used to represent the Domain Specific Software Architecture (DSSA) models. The implementation model is represented
by the reuse components set. These domain models are specified and further modified according to the activities defined by a DE method, based on the DE process. To accomplish this, we use domain agent tools and domain models specification and evolution tools for specification and knowledge evolution of domains. The domain models are presented to users using a hypermedia interface. This choice is based on the premise, pointed by some authors in the KBS (Knowledge-Based System) community, that one of the most largely used forms of presentation of domain knowledge is through hypermedia interfaces [6][14][23]. Also, all domain models are stored in an object manager. The main users of the infrastructure are the domain engineer, the domain specialist and the software engineer responsible for the development of applications within that domain. The domain engineer and the specialist use the infrastructure mainly to specify and enlarge the concepts of the domain. The software engineer uses it to gain an understanding of the application domain and to reuse this understanding in the specification of his/her application. The software engineer interacts with RIDOM through the Information Agent − that aids the engineer while getting familiar with the domain − and through the Architectural Transformation Agent − which allows the transformation of the initial domain concepts, selected by the information agent, to a specific architectural model. These tools use the services of the object manager to access the domain models stored at the domain object database. The object manager plays a key feature in this infrastructure since it provides a uniform representation and manipulation for all the domains, therefore facilitating the encompassment of the whole development cycle. Another advantage of using an object manager lies in its inherent features such as concurrent access, redundancy control, information consistence, and others. In this aspect, RIDOM presents an advantage when compared to similar structures, such as Knowledge-Based Systems (KBSs), that generally use file systems to store data, resulting in redundant information storage and poor performance.
3. Representation of Domain Models The use of OO concepts in the representation of RIDOM domain models offers the following advantages: verification of the consistence of the model; transition from one model to another through a common basis; evolution mechanisms - through inheritance and composition, new domain concepts may be easily defined. However, when the domain concepts require representations such as hypermedia, patterns [8] and Artificial Intelligence (AI) representations (e.g. neural
networks, fuzzy logic, among others) [19], the OO model lacks adequate semantics. Therefore, extensions must be
made on the basic OO RIDOM model to accomplish the semantics associated to the domain model components.
Reuse Infrastructure Based on Domain Models Domain Engineer
• •
•
Software Engineer
Domain Expert
Domain Models Specification and Evolution Tools Tool Requirements Elicitation
Domain Agent Tools Information Architectural Agent Transformation Tool
Pattern Management Component Management
Hypermedia Interface
Domain Models
Conceptual Models
Conceptual Models Analysis Patterns System
OO Models
Models Domain Specific Software Architecture Architectural and Design Patterns System
Developed Domain Applications Architectures
Framework Reuse Components Set
Application Reuse Components
Domain Object Manager
Domain Objects Data Base
Figure 1 - Reuse Infrastructure Diagrammatic View
3.1 - Representation of conceptual models In the representation of conceptual models, we must pay special attention to the ease of understanding and recognition of concepts by RIDOM users. Thus, the form of expressing the domain concepts is important. The basic form that we propose to use is a structure similar to analysis patterns2 [7]. Moreover, to infer new information and to choose the domain concepts that will be used in a certain context, we should represent knowledge in a form that allows the inference and the selection mechanisms to act. Therefore, we use AI techniques to facilitate the search for domain concepts. One possible way of doing this is to 2
Analysis patterns are groups of concepts that represent a common description in a particular domain modeling. Analysis patterns supply directions on how to model concepts of a certain domain using the OO paradigm.
use AI techniques such as Case Based Reasoning techniques (CBR) and Artificial Neural Networks (ANN). These techniques permit the action of inference and intelligent selection mechanisms.
3.2 - Representation of DSSAs We also use the concept of patterns in the representation of the domain specific software architecture. The generic architectures − the architectural styles that are relevant for the domain − are represented by structures similar to Bushmann’s [2] architectural patterns and also by Gamma’s design patterns [8]. In terms of the architectural representations, what are effectively stored as models are (Figure 1): i) the architectural and design patterns, which describe the architectural styles; ii) the analysis patterns, which represent the domain concepts; and iii) a set of
software architectures of domain applications, already specified. 3.3 - Representation of frameworks The implementational model, i.e., a framework in the context of RIDOM, is a set of classes/objects coded in a programming language, according to the “white box” [5] framework approach. Thus, the framework can be extended by adding classes/objects other than the elements of the reusable component set in order to accomplish the final application.
4. Specification and Use of Domain Models (Domain Engineering)
of combining the concepts embedded not only in the analysis patterns − where the domain concepts reside − but also in the architectural patterns − which contain information about architectural styles that are more suitable to that particular domain. One possible way to accomplish this combination of concepts is to use an intelligent agent that applies Case Based Reasoning techniques (CBR) (using the base of application architectures already developed - former experiences) together with Artificial Neural Networks (ANN) (using the structures of architectural, design and analysis patterns) [19]. These techniques permits a new understanding that enables to decide which is the most adequate software architecture for the new application.
5. Specification of a DE Method Along with the representation of domain models, RIDOM must provide tools that allow users to specify and use these domain models. In this sense, tools for eliciting requirements, pattern management, reusable components management and others should be specified. We can observe, as pointed out in section 2, that one of the most largely used forms of domain knowledge representation is through hypermedia interfaces [6] [14] [23]. However, we believe that the use of hypermedia alone does not guarantee that the user will be really capable of assimilating the domain concepts, nor does it assure that hypermedia navigation will lead the user to relevant concepts. Thus, besides using a hypermedia interface, we argue that there should be a way to dynamically guide the navigation. This guidance should show the best paths for navigating and the type of knowledge that better suits the needs of the user. It should be based on the initial requirements of the user3. In fact, this guide is an intelligent agent [19], similar to the information agents or information robots used to guide navigation on the Internet. This intelligent agent uses the concept of intelligent link, where invoking the link causes additional knowledge (as in rule-based expert systems or a set of related cases) embedded within the information space to guide the selection of destination data. New data can be added to the domain repository and the intelligent link will be capable of referencing the new data. In addition, the intelligent links can be invoked based on the user objectives. Another important issue, that we consider being crucial for the success of the infrastructure, is the capability of the user to define which elements of the DSSA are adequate for the application that he/she is developing. This definition should use the knowledge represented by the conceptual models. Therefore, RIDOM must provide ways 3
Since this kind of guidance is directed to application developers.
Surveying the main DE methods found in the technical literature [4], [13], [21], [10], in the light of the RIDOM requirements, we can observe that none of these methods is completely adequate. Therefore, we found it necessary to specify a method that could retain the best features of the main DE methods and avoid their shortcomings. Some of the deficiencies found in preexisting methods, regarding the RIDOM requirements, are listed bellow: • none of the methods covers every phase of DE, with equal emphasis; • none of the methods provides a domain risk analysis phase. The concept of risk analysis is important, since the development of domain models for a certain application domain can be very costly; • Concerning the transition from conceptual models to architectural models, some DE methods propose certain heuristics to accomplish this task [13]. Nevertheless, no systematic approach − i.e., the adoption of a semiautomatic transition between the models − has been proposed. This automatic transition is important, since the main goal of RIDOM is to allow reuse in high levels of abstraction and provide the means to propagate this reuse to the lowest levels. Besides covering the deficiencies found in other methods, the use of OO paradigm eases the transitions from one model to another. This is due to the fact that OO has some modeling features (e.g. encapsulation, inheritance, and composition, among others) that can be used in several abstraction levels. However, as we have pointed out in Section 3, in spite of using OO as the base for domain modeling, the use of conventional OO methods, such as OMT [18] and OOSE [12], alone does not automatically guarantee the adequate definition of these models. Thus, we need to provide an adaptation of some of the techniques
used by DE methods to support the use of the OO paradigm. Although there are methods, such as EDLC [10], that use OO already, they do not support, in terms of OO constructs, all the semantics that is necessary to model the domain. The basic OO constructs provide some principles and directions for OO development. Nevertheless, these constructs do not precisely express how to specify good models in specific contexts [20]. The pattern technology is one way to specify this kind of mechanism, mainly due to the need of providing structures that represent abstractions in both the conceptual and architectural models. We consider that the specification of a DE method must be based on concepts that have already been recognized by other DE methods. Some structures and concepts used by FODA [4] and ODM [13] are adequate to RIDOM. The feature model of FODA allows for the capture of similarities and differences between domain concepts. The differentiation of descriptive and prescriptive models supported by ODM eases the transition from conceptual models to DSSA. Moreover, to assume the OO paradigm as the basic paradigm of our DE method, we must adopt an OO notation that applies to the basic constructs of the paradigm. We have chosen to use UML (Unified Modeling Language) [17] to specify OO constructs for our DE method. The most important reasons for our choice include: • UML is the standard notation for OO modeling adopted by the OMG (Object Management Group) [17]; • Some features used in UML are adequate for the specification of domain models, in different abstraction levels. Some that are noticing: the class diagram that, from a conceptual perspective, has demonstrated to be adequate to capture the domain concepts; activity diagrams, that complement the class diagrams and describe the workflow within the domain; and use cases, that help the domain engineer to describe, with the aid of a specialist, anything that can have an impact on the domain models; • Constructs like the packing diagrams, along with the class diagram, allow the specification of architectural considerations in the conceptual model and the further specification of the domain specific software architecture. Moreover, our DE method provides a risk analysis phase, through the use of selection criteria for the domain, such as, number of developed applications that already exists in the domain, number of potential applications that could be developed in the domain, reuse possibilities that exists in the domain, domain stability, accessibility to domain concepts, among others. These criteria receive different
weights and some are specific for a given domain. In the present stage of our work on RIDOM, the definition of a DE method with such characteristics is under development.
6. Using an Object Manager to Store Domain Models One of the key questions in our project is how to enable the management of domain models, according to the activities defined in the DE method, in an integrated and efficient way. There is no use in defining domain models by the use of UML notation and AI mechanisms, and them use a programming language that is non-compatible with the notation, or else, to store the domain models in files or RDBMSs (Relational Database Management Systems). The implementation effort is significative and there is no guarantee that the semantics will not be lost. Therefore, for the effective implementation of the technologies involved in the specification of RIDOM, we need a component that allows for this integration of concepts, preserving the semantics. The provision of a set of basic services, following a standardization that is compatible with the OO paradigm, is one of the alternatives for solving this problem. This set of basic services plays the role of a component that unifies and eases the manipulation and transition of models. Some of these basic services are: • a structural representation for RIDOM models that supports an adequate expression of all domain concepts; • manipulation operations that allow for the specification of queries according to the structures used for the representation of domain models; • a set of basic mechanisms that guarantees the consistence of both the definition and the manipulation of the represented domain models. These components include mechanisms for the evolution of the structure of the domain models, for concurrent access control, and other control operations. By examining how RIDOM is based on these services, one could think of implementing such services from scratch, as just another module of RIDOM. However, the implementation of these basic services implies in the development of a management module that is as complex as the RIDOM itself. Therefore, we have considered the possibility of reusing a management module that already provides those services. This is the case of Database Management Systems (DBMS), which offer a powerful representation model, as well as access mechanisms that are adequate to the needed model and management services.
The state of the art of DBMSs allows us to consider that the use of OODBMS to support the data management of RIDOM is an adequate choice, since they combine a powerful representation model (that uses the objectoriented paradigm) with the availability of data access and management that are adequate to the OO model. Nevertheless, in spite of the functionality supplied by OODBMSs, performance requirements sometimes impose a very high price for its use. One of the points that may degrade the efficiency and performance in OODBMSs is their bulky structure. Their structure often provides many functionalities such as sophisticated version mechanisms, configurable concurrent control, and others, which compromises the OODBMS performance, as well as its portability. Besides, features such as distribution and parallelism have not yet been well studied in these systems. These features are very important for improving OODBMSs performance [22]. Therefore, one could try to reduce these problems through the use of an open object manager that might be configured with only those features that are necessary in its context of use. An example of this is the Shore system[24]. Based on this premise, we decided to use the structure of a flexible object manager, namely GOA ++, which can comprise only those services that really meet RIDOM’s needs, making the latter more efficient and portable. The basic services that this manager provides to RIDOM are: •
Representation Model: the representation of domain models requires the implementation of a set of sophisticated representation techniques, such as: classes/objects models, pattern structures, hypermedia networks, rules, and others. Analyzing ODMG (Object Database Management Group) [3] standard for object models, we can consider that, an object manager that meets ODMG standard relative to its model, will also meet our requirements, since ODMG standard applies to all the basic and advanced constructs of the OO model, such as: the use of a unique object identifier, multiple inheritance, the key concept, persistence by class extension, inverse relationships, etc. ODMG standard is also compatible with the OMG model and, consequently, with the UML notation. Moreover, the use of an object model based on ODMG standard adds an extra advantage to the representation structure as a whole, namely its portability, since it is the standard used by most OODBMSs. This eases the exchange of one object manager to another one that meets the same standard. GOA++ fulfills ODMG specifications relatively to these items. Nonetheless, besides the object model, we should aggregate AI concepts to the representation model as a whole, so as to fulfill the need for inference mechanisms, like those used by tools that are based on
intelligent agents. Therefore, it is necessary to define some specific services that allow for the aggregation of AI concepts into ODMG object model. These concepts must be inserted into the data definition language (DDL) of GOA++, thus providing an adequate mechanism for the specification of domain models. •
Object Manipulation: Since the representation model is based on the concepts of OO and AI models, the DML must also be based on these concepts, providing mechanisms that allow the retrieval of components represented through OO and rules. The use of the DML standard, defined by ODMG through the basic structures of the OQL (Object Query Language), meets the requirements for the retrieval of components represented according to the object model. Nevertheless, it should be necessary to extend the language so as to allow for the retrieval of information represented in the form of rules, much like the work of data mining described in [16], that extends the object manager OQL of GOA++ to deal with inference rules. Besides, we should point out that the knowledge grouped by domains is generally distributed. Thus, the use of a distributed object manager is a natural option that brings more efficiency to RIDOM as a whole. On the other hand, this knowledge must be available to the RIDOM in a unified way.
7. Related Works Related works can be found in the technical literature having something in common with our work. Nonetheless, most of them deals with only a few aspects of RIDOM. None of them treats with the same emphasis each one of the several activities and technologies that are important for the development of component-based software, as we do in our work. As for the specification of infrastructures to support component-based software development, there are some interesting approaches. The domain modeling in [6] uses AI techniques. By comparing this work with RIDOM, we observe that it is mostly concerned with the representation of conceptual models. However, no attention is paid to the description of a detailed method for structuring its knowledge base. Moreover, all the design environments reported until now are specific to predefined domains, and cannot be used to store knowledge about other application domains. The work of Gomaa et al [10] focus on the creation of a reuse infrastructure based on the automation of its DE method, the EDLC (Evolutionary Domain Life Cycle), thus creating a generic environment named KBSEE
(Knowledge Based Software Engineering Environment). This environment is still a prototype [10] and its main goal is to be independent of a specific domain. KBSEE has some points in common with our work, such as: the adoption of a method to systematize the domain engineering; and the specification of domain models in various abstraction levels, using mainly the object-oriented paradigm. However, when we consider the aspect of data storage, KBSEE requires transformations between different representations and databases. This results in redundant information storage and poor performance. Moreover, the semantic gap is increased. In this aspect, our proposal differs from Gomaa’s, since it is based on the use of a generic and standard model to store domain models. This standard is compatible with UML, using the structure of a DBMS, that leads to a better performance. Works that are more closely connected with the specification of DSSA can also be found in the technical literature, such as the NASA’s space project, the AMPHION environment [14], a domain-oriented environment based on formal specifications and on the deductive synthesis of domain applications. The main advantage of AMPHION lies in its formal specification, which provides a non-ambiguous abstract representation of the user’s requirements. Garlan and Shaw’s group [9] has also developed an environment for the specification of architectural descriptions, named AESOP. AESOP is an architectural environment in the sense that it provides support for the representation, customization and analysis of software architectures. Our work is similar to the ones reported in [9] and [14], since it specifies software architectures for specific domains. However, both projects base their architectural descriptions on formal approaches, using ADLs (Architectural Description Languages) − in the case of the AESOP [9] − and mathematical theorems − in the case of AMPHION [14]. The architectural description using ADLs has many followers. Nevertheless, some authors, such as Bosh [1], believe that the use of constructs like patterns eases the transition from architectural constructs to structures coded in programming languages, mainly OO programming languages. Since our work is based mainly on the use of the OO paradigm, we decided to use architectural constructs that have already been largely used in objectoriented specifications, such as patterns [2] and frameworks [5]. Therefore, in spite of the intersections with the works cited above, our work presents a differential that includes: the specification of patterns based on both architectural styles and specific information from the application domain [7]; the specification of a complete reuse infrastructure which specifies software architectures and conceptual model representations of a higher level of abstraction. Moreover,
our proposal is also concerned with the specification of the operations that will be performed on the models, as well as with the systematization of these operations, in order to allow the consistent creation of models.
8. Final Considerations In this work, we have presented some of the requirements to support component-based application development, through the specification of a reuse infrastructure based on domain models (RIDOM). There are three basic approaches to the component-based development to date: the use of interoperation techniques, such as CORBA and DCOM; knowledge based techniques [6]; and software architecture based development [9]. Our work can be seen as a composition of these three approaches, with a special emphasis on the software architecture based development and knowledge based techniques. The combination of these three approaches may improve the reuse technique in the process of software development. Knowledge based techniques help the reuse of abstract domain concepts, and the software architecture based development supports the transition between the abstract domain concepts and reuse components. Interoperation techniques provide support to the reuse process through services of an object manager, the GOA++, encapsulated in the CORBA protocol, and also by supporting the distribution of the domain knowledge. The integration of these approaches in a reuse infrastructure, such as RIDOM, will certainly bring benefits to reuse research. The RIDOM infrastructure brings some interesting contributions, mainly in the following points: • identification of technologies and specification of components capable of addressing the various stages involved in the component-based software development; • a domain engineering method to support all the phases in the process, including a risk analysis stage, the purpose of which is to validate the viability of applying model oriented reuse in that domain; • systematic use of OO constructs of a higher level, such as patterns, and its insertion into a DE method; • systematization of the transition between conceptual and architectural models. Approaches that are similar to ours [6] [10] [9] [14], although presenting concrete results, do not specify all the aspects addressed by RIDOM when supporting the component-based development. Such proposals present
results in certain aspects of the component-based development, but these results are isolated from a wider context. The innovative approach of RIDOM reduces the semantic gap between the specification and the software development. Therefore, with the help of RIDOM, the software developer will be able to apply reuse techniques from the early stages of the application development process. The other approaches instead, generally put emphasis on just one of the phases of the process. As our final remark, we should point out that the component-based software development is adequately systematized by the use of RIDOM, improving the software developer productivity and reducing the overall process overhead.
References [1]
Bosh, J. - Reusable Specification of Architectural Fragments - University of Karlskrona/Ronneby, Sweden, 1997- at http://www.pt.hk-r.se/~bosh
[2]
Buschmann F. et al - Pattern-Oriented Software Architecture - A system of patterns - John Wiley, 1996
[3]
Cattell R.G.G., Douglas B., Bartels D., Berler M., Eastman J., Gamerman S., Jordan D., Springer A., Strickland H.,Wade - Editors - ODMG - The Object Database Standard: ODMG 2.0, The Morgan Kaufmann Series in Data Management Systems, Jim Gray Series Editor, 1997
[4]
Cohen, S; ”Feature-Oriented Domain Analysis: Domain Modeling”, Tutorial Notes; 3rd Int. Conference on Software Reuse, Rio de Janeiro, November 1994.
[5]
Fayad, F., Douglas Schmidt, Object-Oriented Application Frameworks, Communications of the ACM, Special Issue on Object-Oriented Application Frameworks, Vol. 40, No. 10, October 1997.
[6]
Fischer, G. - "Seeding, Evolutionary Growth and Reseeding: Constructing, Capturing and Evolving Knowledge in Domain-Oriented Design Environments", IFIP WG 8.1/13.2 Joint Working Conference, A. Sutcliffe, D. Benyon and F. van Assche (eds): "Domain Knowledge for Interactive System Design", Chapman & Hall, pp 1-16, May 1996.
[7]
Fowler, M. - Analysis Patterns - Reusable Object Models - Addison Wesley, 1997
[8]
Gamma E. et al - Design Patterns: Reuse of Object Oriented Design Addison Wesley, 1994
[9]
Garlan, D.,Kompanek, A., Melton R., and Monroe R., Architectural Style: An Object-Oriented Approach, February, 1996 at http://www.cs.cmu.edu/afs/ cs/project/able/www/able/papers_bib.html
[10]
Gomaa, H et al - A Knowledge-Based Software Engineering Environment for Reusable Software Requirements and Architectures - Automated Software Engineering 3(3/4): 285-307, August 1996
[11]
Hayes-Roth, F. - Architecture-Based Acquisition and Development of Software: Guidelines and Recommendations from the ARPA DSSA Program, Teknowledge Technical Document, February, 1994
[12]
Jacobson I., Object-Oriented Software Engineering: A use case driven approach, Addison-Wesley, 1994
[13]
Klingler, C. D.,Schwarting, D. - A Practical Approach to Process Definition, Proceedings of the Seventh Annual Software Technology Conference, Utah, April 1995
[14]
Lowry, M., Van Baalen J., "Meta-Amphion: Synthesis of Efficient Domain-Specific Program Synthesis Systems", Automated Software Engineering, 4, pp. 199-241, 1997.
[15]
Euzenat J., Corporate Memory through cooperative creation of knowledge based and hyper-documents, Proocedings of KAW’96, 1996
[16]
Mauro R C et al - GOA++: tecnology, implementation and extensions on the Object Manager - proceedings of SBBD, Fortaleza, Brazil, October, 1997 (in portuguese)
[17]
Object Management Group Adopts Unified Modeling Language and Meta Object Facility Specifications at http://www.omg.org/news/pr97/umlpr.htm
[18]
Rumbaugh, J. et all - Object-Oriented Modeling and Design, Prentice Hall, 1991
[19]
Russell, S., Norvig P., Artificial Intelligence: A Modern Approach, Prentice Hall, 1995
[20]
Shu X.- Fitting Design Patterns into Object-Oriented Methods, Doctoral Thesis, University of Illinois, Chicago, 1996
[21]
Tracz, W., Batory, D. David McAllester, Lou Coglianese, Domain Modeling in Engineering of Computer-Based Systems. In Proceedings of the 1995 International Symposium and Workshop on Systems Engineering of Computer Based Systems, Tucson, Arizona, February 1995.
[22]
Ezeife, C.; Barker, K. - A comprehensive approach to horizontal class fragmentation in distributed object base system - Distributed and Parallel Databases, Kluwer Academic Publishers, 1995
[23]
Studer, R.; Angele J. Fensel D.: Domain and Task Modeling in MIKE. In: A. Sutcliffe, D. Benyon, F. van Assche (Eds.): Domain Knowledge for Interactive System Design, Proceedings of IFIP 8.1/13.2 Joint Working Conference, Geneva, May 1996.
[24]
DeWitt, D. Naughton, J. Shafer, J. Shivakumar, V. “Parallelizing OODBMS traversals: a performance evaluation” TheVLDB Journal, Springer Verlag, v.5(1), January 1996, pp.3-18.
