Proceedings of ATS 2003 206 Design and Evolution of an -Based CASE System for OOAD Dong Liu, Kalaivani Subramaniam, Behrouz H. Far, and Armin Eberlein Department of Electrical and Computer Engineering University of Calgary 2500, University Drive, N.W. Calgary, Alberta, Canada, T2N 1N4 {liud, subrama, far, eberlein}@enel.ucalgary.ca Abstract -based analysis and design is a prospering area of software engineering and several methodologies have been proposed. However, how to evolve the architecture of agentbased system during development is not well addressed. This paper presents 2 kinds of design evolution using a CASE system for OOAD as an example. The first kind of evolution is due to the change of business logic, and the second is to meet the requirements of implementation and maintenance. The behavior model, the role model and the robustness model for the CASE system are presented and compared. The robustness model can also be applied to other agent-based system. 1. Introduction Software agents have been developed for various purposes since the late 1980 s. However, there is, so far, no industry-standard definition for agent or software agent. Generally, an agent may process such properties as autonomous, interactive, intelligent, adaptive, mobile, coordinative and cooperative, etc. [1]. In all the properties, autonomous behavior, communication skills and knowledge based are key characteristics for a software agent. Software agents can be regarded as design patterns for software. The software system can be designed in an agent-based pattern, and be implemented using Object-Oriented (OO) languages, tools, and environments supporting OO. There are some approaches for agent-based analysis and design [2-4]. However, some issues about agent-based system design are not well addressed in those approaches. The refactoring of agent-based system architecture is such a problem. This paper presents two kinds of evolution of agent-based system architecture, using a CASE tool as a case study. A CASE (Computer-Aided Software Engineering) tool has been developed for requirements elicitation and analysis, use-case realization and class modeling. The tool acts as an assistant for various developer roles in OO software development. Because the tool is required to be knowledge-based, interactive and automatic, we apply agent-based paradigm to analyze and design it. The evolution of the designs is presented in this paper.
Proceedings of ATS 2003 207 The architecture of an agent-based system is affected by the business logic and the requirements of implementation and maintenance. The paper consists of 5 sections. The first section introduces the background. The structure of the system in a behavior-decomposed way is discussed in Section 2. A role model is presented in Section 3. Section 4 discusses a robustness model for the system. Section 5 concludes the paper. 2. Original Model The system architecture is affected by the business logic that they will implement. At first the agent system was designed in a behavior-decomposed method to support the Object Model Creation Process (OMCP). 2.1 Object Model Creation Process The Object Model Creation Process (OMCP) is a widely applied methodology to elicit objects and build a class model from requirements [5]. The overview of OMCP is shown in Fig. 1. The stakeholder requests for the system under discussion are captured through interviews or other methods and transformed into requirements. The objects, their attributes, associations and behaviors are identified from the requirements and the object model is generated. The object model is refined with inheritance relationships added and the class model is generated. The implementation of the system under discussion can be started based on the class model. All the activities are supported by the developer s the domain knowledge and experiences. Wahono and Far developed the Object-Based Formal Specification (OBFS) to specify the requirements [6]. OBFS is composed of Description Statements (DS), Collaborative Statements (CS), Attributive Statements (AS), Behavioral Statements (BS), and Inheritance Statements (IS). Objects and the associations between them can be identified from CS; objects attributes can be identified from AS; objects behavior from BS; and Stakeholder Domain knowledge Real-world experience User Interviews Generate Requests Identifying Objects, Attributes, Associations and Behaviours Object Model Creation Process Object Model Domain knowledge Real-world experience User Interviews Refining with Inheritance Class Model Implementation the inheritances between objects from IS. Fig. 8. The Object Model Creation Process (OMCP) [6]
Proceedings of ATS 2003 208 2.2 Behavior Model The CASE system s behavior can be decomposed as follows: Acquire requirements Identify the objects Identify the objects attributes Identify the objects associations Identify the objects behaviors Refine the object model with inheritance The tasks are assigned to various agents, and a model is created as shown in Fig. 2. The system consists of six types of agents, each of which carries out one of the tasks listed above. The OMCP was modified based on the Rational Unified Process (RUP), and the agent-based system architecture needs to be evolved. The evolved architecture is discussed in the next section. Object Specifications Requirement Acquisition Attribute Association Object Refinement Class Model Behavior Fig. 2. The original architecture of the CASE tool. The input and output of the system are requirements specifications and the class model respectively 3. Evolution with the Business Logic We developed OMCP based on RUP for natural language requirements elicitation and specifying, object identification and class modeling. Various developer roles are involved in the method, and the CASE tool needs to play those roles in the process. A role model is designed and discussed in this section. 3.1 Method based on RUP RUP provides guidelines, templates and examples for requirements elicitation and specifying, object identification and class modeling [7]. OMCP is developed based on RUP. The artefacts in requirements phrase are stakeholder requests and use-case model. The artefacts in analysis phrase are robustness diagrams and collaboration diagrams, and those in design phrase are class diagrams representing the class model. The activities are
Proceedings of ATS 2003 209 to find the actors and use cases, to structure use cases, to specify the use cases, use case analysis and class design. The method is shown in Fig. 3. 3.2 Role Model A role model is designed for the tool. Roles and role models are abstraction and decomposition mechanisms in object-oriented paradigms [8]. Role models are widely used for agent-based system analysis and design [4]. A role is identified by its responsibilities and collaborations with the environment. The responsibilities define the role s activities. The collaborations define the communication between the role and the environment including the input and output messages. Stakeholder System Analyst Find Actors and Use Cases Actors and Use cases Specifier Structure Use Cases Specify Use Cases Use case Diagrams Use case specifications CheckPoint Designer Use Cases Analysis Analysis Model Analysis & Design Architect Class Design Architecture Analysis Design Model CheckPoint Fig. 3. The developed OMCP based RUP The developer roles in Fig. 3 are modeled by agent roles listed in Table 1. Besides the collaborations listed in the table, all the roles need to deal with interactions with the user. An agent role is introduced for knowledge storage and supplement. The system model with such roles is shown in Fig. 4. SystemAnalyst Specifier Analyst ClassDesigner Developer Requirement Analysismodel Knowledge Supplier Fig. 4. A role model of the CASE tool
Proceedings of ATS 2003 210 Table 1. roles for the CASE tool. Name Responsibilities Collaborations System Analyst Find actors and use cases Send messages to US (SA) Structure use cases Use-case Specifier (US) Specify use cases Get messages from SA and to RR (RR) Use-case Analyst (UA) Analysis model (AR) Class Designer (CD) Review the use-case model Realize the use cases Review the analysis model Design the class model Send messages to UA and to US Get messages from AR Get messages from US and to AR Send message to CD and to UA Get messages from UA Send information to the user 4. Evolution for Implementation and Maintenance A model is not only for analysis and design, but also for implementation, management and even maintenance. A good model will be easy to implement and convenient to manage. Moreover, the model should be robust to the changing requirements. A robustness model to meet such needs is discussed in this section. 4.1 of Implementation and Maintenance Visual modeling is an important feature of current software analysis and design tools. The diagrams generated by the CASE tool need to be visualized in UML (Unified Modeling Language). The tool is integrated with Rational Rose to visualize the diagrams. If every agent needs to implement the interface to Rose, the system will be very complex. The user needs to start and stop the system, input information, see the output and configure the system through user interfaces. The system needs to manage the data including the knowledge, the input information from the user or other systems, the generated artefacts and the messages transferred between agents. To implement user interfaces and date management in each agent will also increase the complexity of the system. The system may be modified later to meet new requirements. For those who have no Rational Rose installed in their system, diagram visualization in a general application like a web browser will be expected. The OMG UML specification has been updated, so the method and the artefacts also need to be updated according to the specification. If the tool is implemented as the model introduced in Section 3, then all the agents need to be modified for these requirements.
Proceedings of ATS 2003 211 4.2 Robustness Model In the Objectory methodology, Jacobson introduces a robust structure for OO systems [9]. The idea is to model a system in three types of objects: boundary objects for interfaces, entity objects for information and control objects for behaviors. Coad introduced a 4- layer structure for OO systems: problem domain layer for the business logic, user interface layer for user interfaces, data management layer for date storage and management and system interface layer for external interface [10]. We develop a robustness agent model for the CASE tool based on these ideas. This model can also be used for other agent systems. The model is shown in Fig. 5. The Role models the business logic; the UI is responsible for user interfaces; the Data is responsible for date storage and management; and the SI agent is responsible for interface to the support system. Role UI SI User Data Fig. 5. A robustness agent model Support System The responsibilities and collaborations of the agents introduced in Section 3 are decomposed in the robustness model. To implement the tool using OO languages, the agents can be structured by generalization relationships in a hierarchy shown in Fig. 6. If user interfaces or system interfaces are to be changed, the developer just needs to modify the corresponding UI or SI without affecting the Role. This feature can be achieved using a unique communication language, e.g. XML, which can separate the content and the representation of information. The updated agent can cooperate with the old ones side by side in the system by this means. UI Role SI Data System Analyst Analysismodel Knowledge Supplier Specifier Analyst Class Designer Fig. 6. The agent hierarchy for the CASE tool 5. Conclusion The design and evolution of a CASE tool are presented in this paper. The design of an agent-based system is affected by two factors: one is the business logic, based on which
Proceedings of ATS 2003 212 either a behavior model or a role model may be created; the other is the requirements of implementation and maintenance, for which a robustness agent model is proposed. The robustness model can reduce the couplings between agents, and the system will be robust to the changing requirements. How to build agent models for implementation and cooperation with non-agent systems are the problems that need more researches. References [1] OMG Platform Special Interest Group: Technology Green Paper. Object Management Group (2000) Available: http://www.objs.com/agent/agents_green_paper_v100.doc [2] Wooldridge, M., Jennings, N. R., Kinny, D.: The Gaia Methodology for - Oriented Analysis and Design. Journal of Autonomous s and Multi- Systems. 3(3) (2000) [3] Brazier, F., Dunin-Keplicz, B., Jennings, N. R., Treur, J.: DESIRE: Modelling Multi- Systems in a Compositional Formal Framework. International Journal of Cooperative Information Systems. 6(1) (1997) 67-94 [4] Kendall, E.A.: Role modeling for agent system analysis, design, and implementation. Concurrency, IEEE. 8 (2) (2000) 34-41 [5] Booch, G.: Object oriented design with applications. The Benjamin Cummings Publishing Company. (1991) [6] Wahono, R.S., Far, B.H.: A Framework of Object and Refinement Process in Object-Oriented Analysis and Design. Proceedings of the 1st IEEE International Conference on Cognitive Informatics. Calgary, Canada, (2002) [7] Kruchten, P.: The Rational Unified Process: An Introduction, 2 ed. Addison- Wesley. (2000) [8] Riehle, D., Gross, T.: Role Model Based Framework Design and Integration. Proc. 1998 Conf. Object-Oriented Programming Systems, Languages and Applications. ACM Press, New York, (1998) [9] Jacobson, I.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley. (1992) [10] Palmer, S. R., Felsing, J. M.: A Practical Guide to Feature-Driven Development. Prentice Hall. (2002)