Table of Contents. Chapter Description Page #

Transcription

1

2 Abstract agenttooliii(at3) is a Java-based graphical development environment to help users analyze, design, and implement multi-agent systems. at3 is designed to support the Multiagent Systems Engineering (MaSE) methodology. at3 was developed as an Eclipse plug-in. at3 Validation is designed to check the consistency of diagrams drawn using at3. It contains a library of 'rules' to follow and in a timely fashion, reports any discrepancies between user-drawn diagrams back to the designer. b

3 Table of Contents Chapter Description Page # Abstract... b 1 Vision Document Project Plan Software Quality Assurance Architectural Design Technical Inspection Checklist Component Design Test Plan Test Assessment Evaluation User s Manual Project Evaluation References A New Rule Tutorial... i B LOC Evaluation... xxiii c

4 1. Chapter 1 Vision Document 1.1. Introduction The introduction provides background information about agenttool III, the need for extended functionality of agenttool III, useful terms and definitions, and references used during production of this document Motivation The current version of agenttool III was introduced as an Eclipse plug-in, providing users the capability to develop agent-oriented diagrams within an IDE project workspace. However, the current version of agenttool III does not provide its users with consistency checking capability, or the ability to detect consistency between diagrams currently being developed in the same project workspace. The current motivation for this project is to provide this functionality to agenttool III agenttool III agenttool III provides agent-oriented system designers with the ability to easily create and manipulate both static and dynamic diagrams according to the Multi-agent Systems Engineering Methodology (MaSE). The current diagrams available are the activity diagram, agent diagram, goal diagram, organization diagram, role diagram, and sequence diagram. The current version of agenttool III contains independent, non-cohesive diagrams Terms and Definitions Agent An autonomous entity with an ontological commitment and agenda of its own Activity Diagram A representation of relationships of activities that have a clear input and a clear output Goal diagram a graphical depiction of the actions of an actor Multi-agent Systems Engineering Methodology (MaSE) methodology used to develop organization-based multiagent systems. Organizational diagram a graphical depiction of the attributes associated with an organization Role diagram a graphical depiction of the task for some entity Sequence Diagram the graphical representation that depicts the interactions among objects during a certain period Unified Model Language (UML) a standard notation for the modeling of real-world objects Extensible Mark-up Language (XML) a standard format for structured documents 1.2. Project Overview The project overview section contains information about agenttool III s extensions and its goals Introduction This project provides the current version of agenttool III with consistency between multiple diagram documents related to the same project workspace within Eclipse.

5 Figure 1: Project Overview Diagram Figure 1 shows the relationship between system XML files. These files will be used to compare diagrams and report inconsistencies between diagrams within an agenttool III project. System files are stored on the disk space and are updated during the save operation of agenttool III. It will be at this point that the consistency driver will perform necessary operations. agenttool III project files will be organized in a file directory. This file directory will be hierarchical. This is done because validation needs a way to determine which diagrams will be compared with other diagrams. agenttool III validation will occur between diagrams in the same project directory. 2

6 Figure 2: Directory Structure Figure 2 shows an example of how an Agent Diagram and an Organizational Diagram are organized so that they could be validated against one other. Folder1 contains AgentDiag1, OrgDiag1, and a subfolder Folder1.1. AgentDiag1 contains three components, Agent1, Org1, and Org2. OrgDiag1 contains only Org1. Within Folder1 is a subfolder, Org2. Org2 consists of OrgDiag2 and AgentDiag2. OrgDiag2 contains only Org2 and AgentDiag2 contains both Agent1 and Org1. We must not confuse Agent1 and Org1 here with the elements contained in AgentDiag1 and OrgDiag1, they are different elements, just have the same name. This is legal since the elements exist in separate diagrams, but in practice, it is not recommended. At first glance, if we look at AgentDiag1 and validate it, we would get an error. Org2 is present within AgentDiag1 but is not contained in another organization diagram. This is not the case though. Org2 is present in an organization diagram in Folder1.1, which is a sub-organization present in Folder1 through Folder1.1. On the other hand, validating AgentDiag2 does report an error because Org1 in AgentDiag2 is not present in an organization diagram in the current directory or in a sub-organization Project Goal The goal of this project is to provide the current version of agenttool III with consistency and validation between user diagrams within an agenttool III project through the development of an easily maintainable and adaptable framework. 3

7 Project Purpose The purpose of this project is to increase agenttool III s functionality and provide improved usage for agentoriented diagram design using the MaSE methodology. This will increase usability and reduce errors within agentoriented system designs. The diagram consistency framework will allow developers to easily upgrade diagram validation rules for later implementations Project Requirements The project requirements section will outline critical and customer desirable requirements for the diagram consistency and validation feature of agenttool III. Each SR sub-paragraph is labeled Critical, Non-Critical, or Future. This is a reference to the level of severity of each requirement Consistency Driver Framework Description The most important aspect of this project is to develop a maintainable and adaptable framework. The framework will be the driving factor for developers to make new additions to the current modules. The framework will provide users with the ability to update and maintain new diagrams validation rules. The validation configuration, which will contain attributes describing which rules to follow and which to ignore, is contained within the consistency driver. The driver maintains and directs the existing validation rules. Once a new validation rule is developed, it is able to plugged-in to the system and incorporated with the existing rules. This can also be considered as a library of rules. This allows us to easily add new validation rules and determine the rule s level of severity that we want to report to the user SR1. Framework Requirements SR1.1. (Critical) agenttool III Consistency Driver must be extensible. New validation rules must easily integrate with existing rules for both new and existing diagrams. This includes adding, removing, and modifying validation rules. SR1.2. (Critical) agenttool III Consistency Driver must configure validation modules based on stimulus responses from the user or system to determine diagram involvement with validation rules. The consistency driver must be adaptable to the methods that it uses to perform validation, such as determining which task to perform during a save command or which diagrams are involved with the validation. It must be able to turn-off/turn-on any one rule at discretion of the user. 4

8 Use Case 1 Validate Component (Critical Requirement) Description Figure 3: Validate Component Use Case Figure 4 describes the systems actions when a save command is initiated. It is assumed that all associated diagrams exist in the same project workspace as the component being validated Stimulus Response Sequence When a save command is initiated, the agenttool III consistency driver will validate all changed components within the project with other related components. As discrepancies are found, they are reported to the user through Eclipse markers, making the discrepancies viewable through the Problems tab in Eclipse SR2 Associated Functional Requirements SR2.1. (Critical) All modified components within the project workspace and the diagrams they are validated against are validated once a save command is initiated. SR2.2. (Critical) Discrepancies between modified components are reported to the error log. SR2.3. (Critical) The system updates the Problems tab in with the listings in the error log. SR2.4. (Critical) Previous errors that are still valid and classified as errors are still visible to the user through the Problems tab. SR2.5. (Future) The save command can be initiated by either the user or periodically by the system. 5

9 SR3 Validate Activity Diagram This use case describes the components needed for a valid activity diagram, in correlation with other agenttool III diagrams. Each requirement below is reported to Eclipse as either an error or a warning. The consistency driver must possess the ability to ensure the following attributes of all activity diagrams and associated diagrams are in existence. SR3.1. (Critical) The name of the activity diagram must be the same as a service within a role or agent diagram. This is reported as an error. SR3.2. (Critical) An incoming event within the activity diagram must be a message in a sequence diagram. This is reported as an error. SR3.3. (Critical) An outgoing event within the activity diagram must be a message in a sequence diagram. This is reported as an error. SR3.4. (Non-Critical) Swim-lanes must have an associated label tag. This is reported as an error. SR3.5. (Non-Critical) Label tags associated with each swim-lane must be named after a role in a role diagram. This is reported as an error SR4 Validate Agent Diagram This use case describes the components needed for a valid agent diagram, in correlation with other agenttool III diagrams. Each requirement below is reported to Eclipse as either an error or a warning. The consistency driver must possess the ability to ensure the following attributes of all agent diagrams and associated diagrams are in existence. SR4.1. (Critical) Each agent that is connected to a role by a plays relation must also be connected to every capability that the role is connected to by a requires relation in the role diagram by a possess relation. This is reported as an error. SR4.2. (Critical) Each role should exist in a role diagram present in the current directory. This is reported as a warning SR4.3. (Critical) A protocol must exist to at least one other agent or organization from each agent in agent diagram. This is reported as a warning. SR4.4. (Critical) Each agent must be connected to a role with the play relation or be connected to a capability with the possess relation. This is reported as an error. SR4.5. (Non-Critical) No agents may be connected with a protocol relation unless the roles they connect to with the plays relation are themselves connected by a protocol relation in a Role Diagram. This is reported as an error. SR4.6. (Non-Critical) Each organization must be connected to another organization or agent with a protocol relation. This is reported as a warning. SR4.7. (Non-Critical) Each service should be connected to at least one agent or organization with a provides relation. This is reported as a warning. SR4.8. (Non-Critical) Each service should be named after one activity diagram present in the current directory. This is reported as a warning. 6

10 SR4.9. (Future) Each capability should be connected to at least one agent in the diagram with a possess relation. This is reported as a warning. SR4.10. (Future) Each actor must be connected to some agent or organization with a protocol relation. This is reported as a warning. SR4.11. (Future) Each actor should exist in at least one role diagram. This is reported as a warning SR5 Validate Goal Diagram This use case describes the components needed for a valid goal diagram, in correlation with other agenttool III diagrams. Each requirement below is reported to Eclipse as either an error or a warning. The consistency driver must possess the ability to ensure the following attributes of all goal diagrams and associated diagrams are in existence. SR5.1. (Critical) Goals within the goal diagram must be connected to all other goals in the diagram in tree form. Tree form consists of both nodes and leaves. A node is a goal that is connected to at least one child leaf or node. A leaf has no children nodes or leaves. This is reported as an error. SR5.2. (Critical) Leaf nodes should be connected to at least one role in a role diagram by the achieved relation. This is reported as a warning. Note: It is known that additional validation requirements for the goal model are currently being developed and will most likely be implemented into this project once they are determined SR6 Validate Organization Diagram This use case describes the components needed for a valid organization diagram, in correlation with other agenttool III diagrams. Each requirement below is reported to Eclipse as either an error or a warning. The consistency driver must possess the ability to ensure the following attributes of all organization diagrams and associated diagrams are in existence. SR6.1. (Critical) Each goal must be also be in a goal diagram present in the current directory. This is reported as an error. SR6.2. (Critical) Each goal must be connected to an organization by a achieves relation. This is reported as an error. SR6.3. (Critical) Each service must be connected to the organization element by a provide relation. This is reported as a warning. SR6.4. (Critical) Each service must be associated with an activity diagram with the same name. The activity diagram must present in the current directory. This is reported as a warning. SR6.5. (Non-Critical) Can contain only one organization element. This is reported as an error. SR6.6. (Non-Critical) Each actor must be connected to another actor or organization within the same diagram by the protocol relation. This is reported as an error SR7 Validate Role Diagram This use case describes the components needed for a valid role diagram, in correlation with other agenttool III diagrams. Each requirement below is reported to Eclipse as either an error or a warning. 7

11 The consistency driver must possess the ability to ensure the following attributes of all role diagrams and associated diagrams are in existence. SR7.1. (Critical) Each role must be connected to at least one other role by the protocol relation. This is reported as a warning. SR7.2. (Critical) Each role should be connected to at least one agent in an agent diagram by the played relation. This is reported as a warning. SR7.3. (Non-Critical) Each goal is in a goal diagram present in the current directory. This is reported as an error. SR7.4. (Non-Critical) Each actor must be connected to a role by the protocol relation. This is reported as an error. SR7.5. (Non-Critical) Each role must be connected to at least one goal by the achieves relation. This is reported as a warning. SR7.6. (Non-Critical) Each service must be associated with an activity diagram with the same name. This is reported as a warning. SR7.7. (Non-Critical) Each goal must be associated with a role in by the achieved relation. This is reported as a warning SR8 Validate Sequence Diagram This use case describes the components needed for a valid sequence diagram, in correlation with other agenttool III diagrams. Each requirement below is reported to Eclipse as either an error or a warning. The consistency driver must possess the ability to ensure the following attributes of all sequence diagrams and associated diagrams are in existence. SR8.1. (Critical) There must be exactly two roles within a sequence diagram. These roles must also exist within role diagrams. This is reported as an error. SR8.2. (Non-Critical) The two roles within the sequence diagram should have a protocol relation defined between them in a role diagram. This is reported as a warning. 8

12 Use Case 2 Adjust Validation Settings (Critical Requirement) Figure 4: Adjust Validation Settings Description Figure 5 describes the user s ability to change the settings for the validation rules Stimulus Response Sequence When the user opens the preferences dialog, a set of options will be available to the user. These options will allow the user to select or deselect which validation rules are to be used. It will also allow the level of error severity that is reported to the user to be customized. As an example, user can allow only errors to be reported in the Problems tab or only warning, or perhaps neither. Adjusting the validation type can be used to exclude or include a whole set of validation rules that are related. This might include all validation rules associated with the Role Diagram, as an example SR9 Associated Functional Requirements SR9.1. (Critical) All validation rules will have the ability to be either active or inactive. SR9.2. (Critical) Only active validation rules are used in validation. SR9.3. (Critical) Only the chosen validation level errors will be reported to the user. SR9.4. (Future) Validation types are adjustable and are representative of related diagrams Assumptions a) Users are able to operate the current version of agenttool III. b) JVM or later must be installed on the system. 9

13 1.5. Constraints a) A complete list of validation rules has not yet been determined, resulting in possible validation rule severity changing later in the project. b) Java will be used in project implementation, resulting in slower execution but better availability. c) agenttool III is still in development, which could result in modification to the base tool Environment a) J2EE 5.0/ JDK 1.5 available at b) Eclipse 3.1 available at c) GEF 3.1 Eclipse plug-in available at 10

14 Chapter 2 Project Plan 2.1. Task Breakdown Inception Phase The inception phase will concentrate on the project s overview and requirements. This phase will include the production of a Vision Document, a Project Plan, a Software Quality Assurance Plan, and a simple prototype of the software. Each of the four works will have to be approved by the committee before any further progress on the project Vision Document This document will include the project s critical requirements. It gives a listing of the current requirements and labels each requirement as Critical, Non-Critical, or Future. Requirements include validation rules and the purposed framework for the project. The introduction to this project includes its goals and purpose. It include graphical models that are used to describe the framework, and use cases to illustrate the functionality Project Plan This document will include a timeline for the project and a cost estimate for completing this project. Cost estimates will be developed using the COCOMO estimating methodology. All activities involved with this project will be associated with milestones outlined within this document according to the modern software process. This process includes the following phases: Inception Phase, Elaboration Phase, Production Phase, and the Transition Phase Software Quality Assurance Plan This document will include an outline of required documents. To ensure software quality, practiced standards and conventions will be monitored and followed. This document will outline project reviews and the responsibilities of those associated with the agenttool III validation Simple Prototype A simple prototype will be developed to demonstrate at least one aspect of the software. It will demonstrate some of the critical requirements outlined in the Vision Document, such as implementation of critical validation rules. This is completed to demonstrate feasibility or to illuminate risky project requirements. This phase will be complete once the supervisory committee has approved through Elaboration Phase The elaboration phase will concentrate on the project s architecture. This phase will include the production of an Architecture Design Plan, revisions to the Project Plan and the Vision Document, a formal specification, Test Plan, and two architecture inspections Architecture Design Plan The Architecture Design plan will include appropriate UML diagrams such as class diagrams, use-case diagrams, and sequence diagrams, but is not limited to those named here Revisions of Project Plan and Vision Document Appropriate changes that were suggested by the committee at the end of phase one will be made to the Project Plan and Vision Document. 11

15 Formal Specification The formal specification will include at least one function of the software to be specified using the Alloy Constraint Language Test Plan The test plan will include a complete testing procedure for the project. This will include test suites and appropriate procedures for reporting and correcting failed test Architecture Inspections Two architecture inspections will be performed by fellow MSE students here at Kansas State University. Their feedback will be documented and presented. This phase will be complete once the supervisory committee has approved through Production Phase The production phase will include project implementation and testing. This phase includes project coding and documentation Project Coding Project coding will consist of all committee approved and designated tasks to be coded and developed. Both unit testing and integration testing will be performed throughout coding. Test cases will be developed according to the project requirements outlined in the project s Vision Document Project Documentation All aspects of this project will be documented. JavaDocs will be generated to exemplify coding structure and explanations. A post test document will be drafted with all results of the test plan. It will also include the solutions or corrections to the case of test failure. A user manual will be completed and will include a description of project installation, software usage requirements, and software usage. This phase will be completed once the supervisory committee has approved through Cost Estimate COCOMO Barry Boehm s COCOMO cost modeling method will be used to estimate the software cost and development time of adding the diagram validation functionality to agenttool III. I consider this software to be an organic mode relationship, as opposed to an embedded or semi-detached mode, because of its lack of complexity and absence of the need for a highly rigorous process. 12

16 Parameter Identifier EAF Parameter Range ACAP Analyst capability AEXP Applications experience CPLX Product complexity DATA Database size LEXP Language experience MODP Use of modern practices PCAP Programmers capability RELY Required reliability SCED Required development schedule STOR Main storage constraint TIME Execution time constraint TOOL Use of software tools TURN Computer turnaround time VEXP Virtual machine experience VIRT Virtual machine volatility Table 1: COCOMO EAF Parameters Effort will be estimated using the formula Effort = 3.2 EAF (Size) EAF is the effort adjustment factor that allows for normalization of the formula. Table 1 gives a breakdown of the fifteen parameters that make up the EAF, while Table 2 gives my setting for each parameter and a brief explanation for my choice. The Size variable is the number of delivered source lines of code, or SLOC. This project will be measured using KSLOC, or thousand source lines of code. Once this value is found, we can then find a good estimate of time needed to complete this project. Parameter My Level Reasoning Identifier Value ACAP 1.01 Moderate Moderate experience in software analysis of developer AEXP Low Low experience in major project applications development 1.27 Moderate Project contains new concept, such as Eclipse plug-in development, but is CPLX not overly complicated. DATA Very Low There is no DB access. LEXP High Developer has profound experience in Java development. MODP High Project follows modern practices closely. PCAP Moderate Developer has adequate programming experience. RELY 1.01 Low Project is not safety critical and doesn't need to be overly reliable. SCED Moderate Project is on a firm schedule but time allowed is applicable. STOR Low Only real main storage is for file I/O TIME Moderate The project must respond to the user in a timely manner. TOOL High The project will be implemented using many software tools and IDEs. TURN Very Low Results are reported to the developer very quickly. VEXP Moderate Developer has moderate experience with the most other project components, excluding software. VIRT Low The complexity of hardware and software is not great. Table 2: Project EAF Values Time will be estimated using the formula Time = 2.5 (Effort).038, where time is measured in months. 13

17 I have estimated the size variable to be 2KLOC. The best example of size for this project is the dynamic and static agenttool III diagram projects. Although these two projects differed in size, I found that the average KLOC for one diagram s project was around 1.3 KLOC. I believe that this project will be roughly the same size and a diagram project. They both are Eclipse plug-ins and are directly related to each other. I have added about.7 estimated KLOC to this project because of the framework development. Below are the calculated values for both Effort and Time. Effort = Time = Using these estimates, COCOMO concludes that it will take month of development by one developer to complete this project. MSE projects span approximately 8 months. Using COCOMO, we could say that this timeframe is not enough to complete this project. I feel that this is not the case. This project does not contain the need for complex communication channels between project members. There is not a deep hierarchy that artifacts must pass through in order to be approved. My interpretation is that COCOMO assumes there to be deeper levels of communication between team members. If this is so, it will take longer to communicate changes between project artifacts between project members. This is not the case in this project. There is only one level of separation between the project developer and the committee members, allowing less time to commit changes to the project. I believe that outlining the project according to Figure 1 shows this project is well capable of being completed in 8 months. Figure 1 represents the project timeline using the estimated time from the COCOMO formula. Each minor milestone in the timeline is a requirement for the project and will be deliverable at each major milestone, also marked by the end of one phase and the giving of a presentation. ID Task Name Duration 1 Phase One - Inception Phas 57 days 2 Vision Document days 3 Project Plan days 4 Software Quality Assuran 10 days 5 1st Prototype 35 days 6 Formal Requirements Sp 20.5 days 7 Presentation days 8 Phase Two - Elaboration Pha 47 days 9 Action Items 5 days 10 Vision Document days 11 Project Plan days 12 Architectural Design days 13 Test Pl an days 14 Inspection Checklist days 15 Formal Technical Evalua 5 days 16 Prototype days 17 Prestination Two 0 days 18 Phase Three - Production Ph 55 days 19 Action Items 5 days 20 Component Design 5 days 21 Application Code 25 days 22 Te sting 32.5 days 23 Functional Testing 25.5 days 24 Testing Evaluation 17.5 days 25 Documentation 27 days 26 Assessment Evaluat 10 days 27 User Manual 27 days 28 Project Evaluation 11.5 days 29 References 3 days 30 Presentation Three 0 days Aug '05 Sep '05 Oct '05 Nov '05 Dec '05 Jan '06 Feb '06 Mar '06 Apr '06 May '06 J /9 Figure 3: Project Gantt Chart 2/7 4/ Architecture Elaboration Plan Completion Criteria The following is a listing of artifacts and tasks that are to be completed by the end of the project s Inception phase and are to be completed before the second presentation. 14

18 Vision Document 1.0 Revision Vision Document 1.0 will be revised and compiled into Vision Document 2.0. The revisions will contain a complete listing of project requirements and contain changes suggested by the committee members following presentation one. This revision will be approved by the major professor Project Plan 1.0 Revision Project Plan 1.0 will be revised and compiled into Project Plan 2.0. The revisions will contain a complete listing of project requirements and contain changes suggested by the committee members following presentation one. This revision will be approved by the major professor Architectural Design 1.0 Architectural Design 1.0 will be documented using UML diagrams such as class, sequence, and state chart diagrams. All architectural components, including the data model, will be documented. This will be approved by the major professor Prototype 2.0 Prototype 1.0 will be enhanced to Prototype 2.0. This will include any improvements to existing functionality as recommended by the committee members. Additional functionality will also be implemented. This will be approved by the major professor Test Plan 1.0 Test Plan 1.0 will be developed. The document will follow the requirement listings found in Vision Document 2.0. It will also include evaluation criteria and testing data to complete acceptable testing methods. This will be approved by the major professor Formal Technical Inspection 1.0 Two fellow MSE students, who are yet to be determined, will provide input into the testing of this project by completing a formal technical inspection. The technical inspection will assess the project architecture and agenttool III framework. It will also include a function testing checklist so that the requirements outlined in the Vision Document may be evaluated. The formal technical inspection list will be prepared and will be approved by the major professor Formal Requirements Specification 1.0 At least one component of this project will be formally specified using Alloy 1.1. The specification will be completed by representing the formal requirements of the Agent Diagram in the Vision Document in the Alloy Constraint language. The Agent Diagram requirements are chosen because of their relationship to many different components in other diagrams and with in itself. This specification will be approved by the major professor. 15

19 Chapter 3 Software Quality Assurance Plan 3.1. Purpose This chapter is produced to outline the necessary steps to ensure the project has an acceptable level of quality. It will describe the necessary steps taken to ensure quality throughout the entire life-cycle process for this project Management Organization Below is a listing of the organization and their roles with the validation project for agenttool III. Developer: Major Professor: Supervisory Committee: Formal Technical Inspectors: Mr. Patrick Gallagher Dr. Scott DeLoach Dr. Scott DeLoach Dr. Robby Dr. David Gustafson Mr. Javier Ramos Miss Sonitha Menon Tasks All project tasks are discussed in detail in [1] Responsibilities Developer The developer is responsible for documentation, implementation, and testing of this project. Three presentations will be given detailing project progress. Bi-weekly meetings with the major professor are required; these meeting are also open to all member of the committee Major Professor The major professor is responsible for overseeing the work done by the developer. S/he must approve all artifacts of the project and is considered the end-user for agenttool III s validation. S/he will also provide guidance and advice to the developer throughout the project s lifetime Supervisory Committee The supervisory committee is responsible for preparing for and attending each of the three presentations. The committee will provide comments on the artifacts presented during the presentation and feedback is expected at these times. 16

20 Formal Technical Inspectors The formal technical inspectors are responsible for completing a formal inspection of the project framework. They will also conduct a preliminary functional walkthrough of the project Documentation All documentation will be available at Purpose The purpose of the project documentation is to provide a reference and timeline for this project. Other project documentation may be required; this is at the discretion of the project developer and major professor. The current state of the documentation will be evaluated by the major professor within each phase of the development and must be approved by all committee members at the conclusion of each phase Minimum Documentation Requirements Outline below is a list of all required documents for this project, sorted by which phase each is to be completed. Phase One Phase Two Phase Three Project Plan 1.0 Architecture Design 1.0 Component Design 1.0 SQAP 1.0 Executable Architecture Prototype Executable Project Vision Document 1.0 Formal Requirements Specification Formal Technical Inspection Letters Project Plan 2.0 Project Evaluation 1.0 Test Plan 1.0 Project Source Code Technical Inspection Checklist 1.0 User Manual 1.0 Vision Document Standards, Practices, Convention, and Metrics IEEE standards will be followed for documents when applicable throughout this project. Java naming conventions and practices will be followed for all project coding and code-generated documentation. COCOMO will be used as a cost estimate metric. 3.5 Reviews and Audits All artifacts produced will be reviewed and assess by the supervisory committee. This includes all documents and executable project code. The artifacts will be evaluated at the conclusion of each phase, which is marked by one of the three presentations Testing The Test Plan will out-line testing procedures and expected results of all test. Please refer to this document for further detail Problem Reporting and Corrective Action All problems will be reported as a result of presentations or brought about by the major professor. They will be compiled into an action document after each presentation and will be resolved prior to the next presentation Tools, Techniques, and Methodologies agenttool III validation is produced as an Eclipse plug-in. As a result, Eclipse 3.1 will be used as the integrated development environment. Alloy 1.1 will be used to formally specify a portion of the project, the Agent Diagram requirements. All documentation will be developed using Microsoft Word 2002 and after each document is 17

21 complete, Adobe Acrobat 6.0 will be used to convert the artifact into a uniform viewing file format Microsoft Excel 2002 and Microsoft Project 2002 will be used for various table and graphical creation used within most documents Code Control, Media Control, and Supplier Control Eclipse s CVS functionality will be used as project source control for agenttool III. The CVS server is available thanks to the Multi-agent and Cooperative Robotics Laboratory in the Computing and Information Sciences department at Kansas State University. All project documents and source code will also be available at when they are completed. For additional resource locations, please contact the major professor. Supplier control is not applicable to this project Records Collection, Maintenance and Retention Please contact the major professor, Dr. Scott DeLoach, for these locations Training Project training is not applicable to this project Risk Management Both the developer and major professor have primary responsibility for identifying and mitigating risks during the project. Any risks identified will be reported at each weekly meeting. 18

22 Chapter 4 Architectural Design 4.1. Introduction The architectural design document provides an outline the architectural design of agenttool III Validation. This document will contain both class diagram and sequence diagrams outlining the projects design. The class and sequence diagrams are developed according to UML standard notation. A brief explanation of each diagram components will follow each figure agenttool III Validation agenttool III (at3) Validation is an extension to the at3 Eclipse plug-ins. at3 provides its users the ability to draw agent-oriented diagrams within Eclipse. at3 Validation checks for consistency between diagrams and reports any errors or warnings to the user. The errors and warning are based on a set of rules that govern at3 diagrams PDE Architecture The PDE Architecture was developed to provide Eclipse plug-in developers an easy way to extend Eclipse s functionality. The PDE defines extensions that developers can build off of to create their own plug-ins. These include, but are not limited to, adding preference pages, property pages, builders, and wizards to an Eclipse plug-in. at3 Validation will use the PDE Architecture to implement its functionality. This architecture was designed to make it easy to build onto Eclipse. It is intended to make extending existing plugins in Eclipse fast and easy. PDE organizes the plug-in components into sections based on their extensions from Eclipse. These extensions include adding preference pages and property pages to keep plugi-n configurations and a wizard extension to act like a walkthrough or tutorial to, for example, help the user create new files Definitions 1. Document Object Mode (DOM) an object-oriented model of a structured document. javax.dom provides a standard library used to perform operations on structured documents, like XML, within the context of objectoriented designs. 2. Plug-in Development Environment (PDE) a project of Eclipse that provides Eclipse Plug-in developers with extension points and other mechanisms that help developers extend Eclipse quickly and easily. 19

23 4.2. at3 Validation Package View agenttool w3c (f rom org) at3validation file (f rom at3validation) driver (f rom at3validation) cache (f rom driv er) builder (f rom at3validation) xml (f rom org) rules (f rom at3validation) wizards (f rom at3validation) properties (f rom at3validation) preferences (f rom at3validation) At3ValidationPlugin (f rom at3validation) osgi (f rom org) Figure 4: at3 Validation Package View Figure 1 shows the package layout for at3 Validation. Many of the packages are inherent to the PDE architecture. By this I mean that these packages are consistent with the PDE architecture and they use Eclipse extensions. Extension points are used to build onto Eclipse s functionality. They are components found in Eclipse that the user can extend to personalize their plug-ins. A user can access an extension through the Eclipse library. Each extension is its own library within Eclipse. Using these extensions makes it easy for the developer to plug-in to the Eclipse framework and build onto it. The preferences, properties, builder, and wizards packages are developed as extensions to Eclipse. These provide either UI additions that build upon the existing functionality of Eclipse or by enhancing the usability of Eclipse. Missing from this diagram is the dependency of each package to the org.eclipse library. This was done for readability in the diagram. The org.eclipse.* library provides access to the extensions and interaction with other Eclipses such as access to the workspace. Every package will use this library. The other libraries referenced from the at3validation package are used by select packages within at3validation. The xml package contains files to manipulate XML files. The osgi package provides plug-in bundling files. This 20

24 registers the plug-in with Eclipse and sets up the plug-in configuration. The w3c package contains files to manipulate DOM objects while the agenttool package is used to build model object based on the XML files. These objects are used in the rule validation logic. The remaining packages provide the plug-in s functionality and are not apart of the PDE architecture. They provide the functionality to validate diagrams. Each package will be discussed in more detail below. The At3ValidationPlugin controls our plugin and registers the plug-in with Eclipse. It also initializes our cache Builder Package The builder package contains the components needed to recognize changes to a project once the user has issued a save command. This is an extension of the Eclipse builder functionality. This allows us to run at3 Validation once the system recognizes that a project resources have changed, which occurs once the resource has been save. It uses listeners to notify the validation plug-in of any changes. These changes also include new resource creation and resource deletion. ValidationDriver (from driver) starts builder (from at3validation) ToggleNatureAction isactivatedby At3ValidationBuilder +belongto 1 0..n +control At3ValidationNature Figure 5: Builder Package 21

25 Structure At3ValidationBuilder This class registers the builder with Eclipse and sets the At3ValidationNature as a nature controlled by this builder. Each builder in Eclipse can control multiple natures At3ValidationNature This class creates the project nature, which activates the listeners. It also sets the At3ValidaitonBuilder as its controller. Each nature in Eclipse can only be associated with one builder ToggleNatureAction This class manipulates the At3ValidationNature by making it either active or inactive ValidationDriver This class is discussed in the driver package Driver Package The driver package gives our plug-in a way to run its validation. It recognizes which rules to run during validation, which is determined by the user. The driver then performs the appropriate actions to validate the at3 diagram. It also updates the markers that report errors and warnings to the user. driver (from at3validation) DiagramType uses cache At3CacheableObject ValidationDriver updates +contains 0..* Cacheable 0..* +in runs uses At3CacheManager rules (from at3validation) file (from at3validation) Figure 6: Driver Package 22

26 Structure ValidationDriver This class controls which rules to run. It determines which at3 Diagram to run validation on DiagramType This class is a static class that lets us associate each type of diagram, whether it is an Agent Diagram, Goal Diagram, etc, with a globally recognizable value rules This package will be discussed later file This package will be discussed later cache This package contains our caching files. We use to the cache to increase performance during validation At3CacheManager This class manages our cache. It retrieves and places object into our caching structure. It also starts a thread to flush the cache, if needed At3CacheObject This class provides creates an object to place in our cache. This object has the diagram object created from the agenttool model. It also has a key value that allows us to retrieve the objects. The key value is equivalent to the diagrams name Cacheable This is an interface for all objects that will be used in the cache file. convert Package Each at3 diagram is available through an XML file. This file is created by the at3. This package then parses the XML file and creates a universal object, based on the model within at3. The file modifier must create objects because each diagram is based on a separate, yet related model. The objects are then used in validation to compare the components in each diagram. 23

27 file (from at3validation) convert ConvertActivityXML (from convert) ConvertAgentXML (from convert) XMLtoObject (from convert) usedby ConvertGoalXML (from convert) ConvertOrgXML (from convert) ConvertRoleXML (from convert) ConvertSeqXML (from convert) w3c (from org) xml (from org) agenttool (from Logical View) Structure Figure 7: file.convert Package XMLtoObject This class is given an at3 diagram resource, which is then used to create a DOM DOCUMENT object, a component of javax.dom. This class then determines how to convert the document and returns a the newly created diagram object Convert* This refers to the six classes in the above diagram that begin with Convert. All of these classes have the same functionality. Each of them is given a DOM DOCUMENT object and with this, creates a new at3 model object. 24

28 xml Package This is a library used to parse XML files w3c Package This is a library used to create DOM object agenttool Package This package contains the model for at3 Diagrams preferences Package This package allows the user to determine which rules to use during validation. These are separated into diagram specific rules. preferences (from at3validation) diagram.specific PreferenceInitializer At3ValidationActivityDiagramRulesPreferencePage initializedefaultpreferences() defaults PreferenceConstants read At3ValidationAgentDiagramRulesPreferencePage At3ValidationGoalDiagramRulesPreferencePage (from diag ram.specific) At3ValidationPlugin (from at3validation) iscontrolledby reads 0..n At3ValidationOrganizationalDiagramRulesPreferencePage (from diag ram.specific) At3ValidationRoleDiagramRulesPreferencePage (from diag ram.specific) At3ValidationPrimaryPreferencePage At3ValidationSequenceDiagramRulesPreferencePage (from diag ram.specific) ui (from eclipse) jface (from eclipse) Figure 5: Preferences Package Structure At3ValidationPrimaryPreferencePage This class creates a UI preference page that contains a default page for at3 preferences PreferenceConstants This class contains static references to preference options. 25

29 PreferenceInitializer This class contains the default values for the preference constants diagram.specific This package contains classes similar to the At3ValidationPrimaryPreferencePage but is designed to maintain diagram specific preferences of validation rules properties Package The properties package provides the user a way to turn on/off at3validation on a per package basis. properties (from at3validation) At3ValidationPropertyPage maintainsnature builder (from at3validation) extends PropertyPage Structure Figure 6: Properties Package At3ValidaitonPropertyPage This class creates the at3 Validation property page contents and actions rules Package This package is a collection of rules that at3validation will use to validate at3 diagrams. Each rule that is implemented will need to extend ARule and implement IRule. 26

30 agent rules (from at3validation) activity organization IRule goal sequence ARule role reads file (from at3validation) preferences (from at3validation) driver (from at3validation) Figure 7: Rules Package Structure IRule This class defines an interface to be implemented by at3 Validation rules. The interface ensures that each rule implemented will contain a run method, which executes the rule, and a active method that returns this rules active preference; whether to run the rule or not ARule This class contains abstract methods that will be shared between all at3 Validation rules. The functionality provided by ARule includes gather the other diagrams XML files for comparison and determining diagram types from the file extensions Activity, Agent, Goal, Organization, Role, Sequence Packages These packages contain individually implemented rules. Each at3 Validation rule will be located in this package and must extend ARule and implement IRule. 27

31 Example: SR4.1 is a rule taken from the Vision Document for this project. When implementing this rule, we must create a new class that extends ARule and implements IRule. This class will be placed in the Agent folder, since it pertains to the agent diagram rules. Implementing IRule ensures that this rule contains the correct methods needed in order to be run. Extending ARule gives the user access to helper methods that all of our rules need in order to work. All the developer must do is implement the business logic that it takes to run the rule; i.e., comparing roles in two diagrams wizard Package This package provides the user with an easy way to add new rules to the at3 Validation plug-in. <<Interface>> INewWizard (from ui) wizards (from at3validation) At3ValidationNewRuleWizard creates 1 At3ValidationNewRuleWizardPage WizardPage Figure 8: Wizard Package 28

32 Structure At3ValidaitonNewRuleWizard This class is responsible for creating a blank rule At3ValidaitonNewRuleWizardPage This class is responsible for showing the user a dialog to guide the user through creating a new rule Sequence Diagrams Below are two Sequence Diagrams that show the flow of events for a user changing the rule preferences and validating the Agent Diagram using rule SR Change Preferences Sequence Diagram Prerequisites 1. User has opened Eclipse Preference Page. 2. User has altered one agenttool III Preference Sequence of Events 1. User Presses OK 2. Eclipse s instance of the At3 Agent Diagram preference page get the current plugin, At3ValididationPlugin 3. The plug-in get the Eclipse preferences from the preference store, located in the super class, AbstractUIPlugin 4. The plugi-n then sets the appropriate value for all changed preferences in the preference store. 5. ScopedPreferenceStore returns if the process was successful. 6. The plugin continues with the OK command by calling the preference page s super class, FieldEditorPreferencePage. Post-Conditions 1. The Preference store s values are updated and are consistent with the users preference settings according to the preference page. 29

33 Figure 9: Change Preferences Sequence Diagram Validate at3diagrams With SR4.2 Sequence Diagram This sequence diagram contains a mixture of classes found in the above package diagrams and some classes inherent to the PDE architecture and Eclipse plug-in development. The classes explicit to PDE development are the EclipsePreferences, Plugin, and IMarker. I use the Plugin class here because our At3ValidationPlugin class is an extension of this base class. The EclipsePreferences is used by the Eclipse workspace to store preference values. The IMarker class is a class used to place Eclipse markers on resources. The SR4_2 class is an implemented rule. Prerequisites 1. The user has created both one Agent Diagram with one Role component located in the diagram. 2. The user has one empty Role Diagram 3. SR4.2 is active in the preferences. 4. Both the Agent Diagram object and the Role Diagram object are in cache. Sequence of Events 1. The user saves either the Role Diagram or the Agent Diagram 2. The ValidationDriver creates an instance of the SR4_2 rule. 3. The active state of SR4_2 is check. This is a value in the preference store. 4. SR4.2 gets the current plugin, which then gets the EclipsePreferences and gives the preferences the appropriate value to check for in the store. 5. The value is returned to the SR4.2 which is then returned to the Validation Driver. 6. Since the rule is active, SR4.2 is run. 7. SR4.2 retrieves the AgentSchema from cache. 8. SR4.2 collects all the roles in the AgentSchema. 9. SR4.2 determines other the Role Diagram is present 10. SR4.2 retrieves the RoleSchema form cache. 11. SR4.2 collects all roles in the RoleSchema. 12. SR4.2 compares all roles in the AgentSchema to roles in the RoleSchema. 13. SR4.2 updates the markers by placing an IMarker on the agent resource. 14. SR4.2 relieves control back to the driver to continue validation. 30

34 Post-Conditions 1. A new problem marker is viewable by the user to see an error. User ValidationDriver SR4_2 At3ValidationPlugin Plugin EclipsePreferences At3CacheManager IMarker Save Create Get Active Status Get Plugin Get Preferences Return Preferences GetValue Return Value Return Active Status Run Get Agent Object Return Agent Object GetOtherRoleDiagrams Get Role Object Return Role Object Determine Valitity Update Markers Delete Same Previous Markers Create Marker Continue Figure 10: Validate at3diagrams With SR4.2 Sequence Diagram 31

35 Chapter 5 Technical Inspection Checklist 5.1. Introduction This document provides a checklist that is used to perform a technical inspection of the agenttool III Validation project. It provides a guideline that is to be followed while inspectors check the integrity of artifacts associated with this project. The inspectors will use this document as an aid while inspecting the Architectural Design Document 1.0 and Alloy Model Items to be inspected Vision Document 2.0 will be referenced while completing the technical inspection UML Diagrams a) Class Diagrams b) Class Descriptions c) Sequence Diagrams Formal Specification a) Alloy Model 5.3. Formal Inspectors a) Javier Ramos Contact: javier.ramos1@gmail.com b) Sonitha Menon Contact: sgmenon@ksu.edu 5.4. Formal Inspection Checklist Part One This part of the technical inspection is devoted to checking the Architectural Design Document and the Alloy Constraint Model. It will be completed before Phase 2 of this project. Item # Inspection Item Document PASS/FAIL/PARTIAL Comments TI.1 The symbols used in the class diagrams conform to UML standards. Architectural Design Document 1.0 TI.2 TI.3 TI.4 The symbols used in the sequence diagrams conform to UML standards. The classes in the class diagrams have a corresponding description provided in Architectural Design Document 1.0. The class descriptions in Architectural Design Document 1.0 are clear and adequate. Architectural Design Document 1.0 Architectural Design Document 1.0 Architectural Design Document

36 TI.6 TI.6 TI.7 The Alloy invariants are sufficient in supporting the Agent Diagram Rules (SR4.1 - SR4.11). The Alloy assertions are understandable and guarantee correct operations according to Alloy invariants. The Alloy conditions are sufficient in reproducing appropriate operationally replicated scenarios. Alloy Model Alloy Model Alloy Model Part Two This part of the technical inspection is devoted to checking the complexity of adding a new rule to at3 Validation. It will be completed between Phase 2 and Phase 3 of this project. Item # Inspection Item Document PASS/FAIL/PARTIAL Comments TI2.1 The User Manual 1.0 contains User Manual 1.0 step by step instruction to add a new rule to at3validation. TI2.2 The User Manual 1.0 outlines User Manual 1.0 the steps needed to enable a new rule to be activated or deactivate via the project preference page. TI2.3 On a scale of 1 to 10, with 10 being the easiest and 1 being the hardest, how would you rate the overall difficulty of adding a new rule to at3 Validation? None 33

37 Chapter 6 Component Design 6.1. Introduction The component design chapter provides the implemented architectural design and component description of agenttool III Validation. This document will contain both class diagram and sequence diagrams outlining the projects design. The class and sequence diagrams are developed according to UML standard notation. An explanation of each diagram components will follow each figure agenttool III Validation agenttool III (at3) Validation is an addition to the at3 Eclipse plug-ins. at3 provides its users the ability to draw agent-oriented diagrams within Eclipse. at3 Validation checks for consistency between diagrams and reports any errors or warnings to the user. The errors and warning are based on a set of rules that govern at3 diagrams PDE Architecture The PDE Architecture was developed to provide Eclipse plug-in developers an easy way to extend Eclipse s functionality. The PDE defines extensions that developers can build off of to create their own plug-ins. These include, but are not limited to, adding preference pages, property pages, builders, and wizards to an Eclipse plug-in. at3 Validation will use the PDE Architecture to implement its functionality. This architecture was designed to make it easy to build onto Eclipse. It is intended to make extending existing plugins in Eclipse fast and easy. PDE organizes the plug-in components into sections based on their extensions from Eclipse. These extensions include adding preference pages and property pages to keep plugi-n configurations and a wizard extension to act like a walkthrough or tutorial to, for example, help the user create new files. 34

38 6.2. at3 Validation Package View Figure 8: at3 Validation Package View Figure 1 shows the package layout for at3 Validation. Many of the packages are inherent to the PDE architecture. By this I mean that these packages are consistent with the PDE architecture and they use Eclipse extensions. Extension points are used to build onto Eclipse s functionality. They are components found in Eclipse that the user can extend to personalize their plug-ins. A user can access an extension through the Eclipse library. Each extension is its own library within Eclipse. Using these extensions makes it easy for the developer to plug-in to the Eclipse framework and build onto it. The preferences, properties, builder, and wizards packages are developed as extensions to Eclipse. These provide either UI additions that build upon the existing functionality of Eclipse or by enhancing the usability of Eclipse. Missing from this diagram is the dependency of each package to the org.eclipse library. This was done for readability in the diagram. The org.eclipse.* library provides access to the extensions and interaction with other Eclipses such as access to the workspace. Every package will use this library. at3 also provides its own extension to enable developers to contribute new rules that will be used during validation. at3 Validation uses the new rule extensions to load classes dynamically. The use of extensions makes extending the rule library (rules) easy and provides an efficient way for the tool to run rules without hard coding every aspect of how the rule works. The other libraries referenced from the at3validation package are used by select packages within at3validation. The xml package contains files to manipulate XML files. The osgi package provides plug-in bundling files. This registers the plug-in with Eclipse and sets up the plug-in configuration. The w3c package contains files to manipulate DOM objects while the agenttool package is used to build model object based on the XML files. These objects are used in the rule validation logic. 35

39 The remaining packages provide the plug-ins functionality and are not apart of the PDE architecture. They provide the functionality to validate diagrams. Each package will be discussed in more detail below Structure At3ValidationPlugin The At3ValidationPlug-in controls our plug-in and registers the plug-in with Eclipse. It also initializes our cache class visibility extends implements At3ValidationPlug-in public AbstractUIPlugin none Attributes visibility Type other plugin private At3ValidationPlugin static Functions visibility parameters returns action At3ValidationPlugin public none starts cache and inits plugin startup public BundleContext void starts the plugin stop public BundleContext void stops the plugin getdefault public void At3ValidationPlugin Returns shared instance of itself getimagedescriptor public String ImageDescriptor Returns the image descriptor for the given path getworkspace public none IWorkspace Returns the ResourcesPlugin workspace At3ValidationStartup This class listens for the creation of new project and calls At3ValidationStartupListener to add the At3ValidationBuilder to the project. class visibility extends implements At3ValidationStartup public none IStartup Attributes visibility Type Other none Functions visibility parameters returns action earlystartup public none void Adds a resource change listener to the workspace so that when a new Java project is created, the At3ValidationBuilder is added to the project At3ValidationStartupListener This class adds the At3ValidationBuilder to each new project created in the workspace. class visibility extends implements At3ValidationStartup public none IResourceChangeListener Attributes visibility Type Other added private ArrayList Functions visibility parameters returns action resourcechanged public IResourceChangeEvent void Creates new thread to added at3 builder to 36

40 project description file addbuilder private IProject void Adds the at3 builder to the given project 6.3. builder Package The builder package contains the components needed to recognize changes to a project once the user has issued a save command. This is an extension of the Eclipse builder functionality. This allows us to run at3 Validation once the system recognizes that a project resources have changed, which occurs once the resource has been save. It uses listeners to notify the validation plug-in of any changes. These changes also include new resource creation and resource deletion. Figure 9: builder Package 37

41 Structure At3ValidationBuilder This class registers the builder with Eclipse and sets the At3ValidationNature as a nature controlled by this builder. Each builder in Eclipse can control multiple natures class visibility extends implements At3ValidationBuilder public IncrementalProjectBuilder none Attribute visibility Type Other BUILDER_ID public String static final MARKER_TYPE public String static final Function visibility parameter returns action addmarker private IFile, String, int, int void Adds a new marker to IFile with the given message, line number, and severity build protected int, Map, IProgressMonitor IProject[] runs the builder according to the given int type checkxml public IResource void Runs the at3driver on the given resource. fullbuild protected IProgressMonitor void Performs a full build on all projects in the resource visitor incrementalbuild protected IResourceDelta, IProgressMonitor void Performs and incremental build on the given delta class visibility extends implements class At3ValidationDeltaVisitor private none IResourceDeltaVisitor Attribute visibility type Function visibility parameter returns action visit public IResourceDelta boolean runs checkxml on all changed resources in the delta class visibility extends implements class At3ValidationResourceVisitor private none IResourceVisitor Attribute visibility type Function visibility parameter returns action visit public IResource Boolean runs checkxml on the given resource class visibility extends implements class XMLErrorHandler private DefaultHandler Attribute visibility type 38

42 file private IFile Function visibility parameter returns action XMLErrorHandeler private IFile Constructor, sets file to given parameter addmarker private SAXParseException, int void adds an error marker to the file with the exception message, line number, and the given int severity error public SAXParseException void adds an error marker with the exception and error type error fatalerror public SAXParseException void adds a fatal error marker warning public SAXParseException void adds a warning marker with the exception and error type warning At3ValidationNature This class creates the project nature, which activates the listeners. It also sets the At3ValidaitonBuilder as its controller. Each nature in Eclipse can only be associated with one builder. class visibility extends implements At3ValidationNature none IProjectNature Attribute visibility Type Other NATURE_ID public String static final project private IProject Function visibility parameter returns action configure public none void adds the at3 nature from project if it has the at3 builder deconfigure public none void removes the at3 nature from the projects that have the at3 builder getproject public none IProject returns the project associated with this nature setproject public IProject void sets project to the given IProject 39

43 ToggleNatureAction This class manipulates the At3ValidationNature by making it either active or inactive. class visibility extends implements TogglenNatureAction none IObjectActionDelegate Attribute visibility Type Other selection private ISelection Function visibility parameter returns action run public IAction void control class selectionchanged public IAction, ISelection void resets the attribute selection setactivepart public IAction, void no action IWorkbench toggle public IProject void if project has nature it removes it and vice versa addnaturetoproject public IProject void adds at3 nature to project removenaturefromproject public IProject void removes at3 nature from project ValidationDriver This class is discussed in section 4, Driver Package driver Package The driver package gives our plug-in a way to run its validation. It recognizes which rules to run during validation, which is determined by the user. The driver then performs the appropriate actions to validate the at3 diagram. It also updates the markers that report errors and warnings to the user. 40

44 Figure 10: driver Package Structure ValidationDriver This class loads the diagram.rule extensions located in the workspace extension registry and determines how to run validation on the given resource based on the type of diagram the resource represents. The driver only runs for those rules that are involved with the resources type of diagram. It is also responsible for retrieving the resource from cache, or placing the resource in cache if it is not present. class visibility extends implements ValidationDriver public Attribute visibility Type Other Function visibility parameter returns action ValidationDriver public Constructor getpageid protected String Returns the pageid needed to access the users preferences run public IResource String runs the validation on the given resource. 41

45 DetermineDiagramType public String Integer returns the diagram type according to the diagram type constants found in DiagramType based on the resources file extension This class controls which rules to run. It determines which at3 Diagram to run validation on DiagramType This class is a static class that lets us associate each type of diagram, whether it is an Agent Diagram, Goal Diagram, etc, with a globally recognizable value. class visibility extends implements DiagramType public Attribute visibility Type Other ActivityDiagram public Integer static final AgentDiagram public Integer static final GoalDiagram public Integer static final OrganizationalDiagram public Integer static final RoleDiagram public Integer static final SequenceDiagram public Integer static final rules This package will be discussed later file This package will be discussed later cache This package contains our caching files. We use to the cache to increase performance during validation At3CacheManager This class manages our cache. It retrieves and places object into our caching structure. It also starts a thread to flush the cache, if needed. class visibility extends implements At3CacheManager public Attribute visibility Type Other millisecondsleeptime public int static, 5000 cachehashmap private HashMap static lock private Object static Function visibility parameter returns action At3CacheManager public Constructor putincache public Cacheable void placed the Cacheable object into the cache 42

46 getcachedobject public ident Cacheable retrieves the Cacheable object with identifier ident from the cache At3CacheObject This class provides creates an object to place in our cache. This object has the diagram object created from the agenttool model. It also has a key value that allows us to retrieve the objects. The key value is equivalent to the diagrams name. class visibility extends implements At3CacheObject public Cacheable Attribute visibility Type Other expiredtime private Date diagramobject private Object id private String time to live Function visibility parameter returns action At3CacheableObject public String, Object, int Constructor GetDiagramObject public none Object returns diagramobject getid public none String return id isexpired public non boolean returns true if object has expired in cache Cacheable This is an interface for all objects that will be used in the cache. interface visibility extends implements Cacheable public Attribute visibility Type Other isexpired public boolean getid public String 6.5. file. convert Package Each at3 diagram is available through an XML file. This file is created by the at3. This package then parses the XML file and creates a universal object, based on the model within at3. The file modifier must create objects because each diagram is based on a separate, yet related model. The objects are then used in validation to compare 43

47 the components in each diagram Structure Figure 11: file.convert Package XMLtoObject This class is given an at3 diagram resource, which is then used to create a DOM DOCUMENT object, a component of javax.dom. This class then determines how to convert the document and returns a newly created diagram object. 44

48 class visibility extends implements XMLtoObject public Attribute visibility Type Other res private IResource document private org.w3c.dom.document Function visibility parameter returns action XMLtoObject public none Contructor convert public IResource, Integer Object Converts the dom document object into, based on the Integer parameter, the corresponding at3 diagram object Convert* This refers to the six classes in the above diagram that begin with Convert. All of these classes have the same functionality. Each of them is given a DOM DOCUMENT object and with this, creates a new at3 model object. Each of the (*) in the table below can represent any of the at3 Diagram. class visibility extends implements Convert*XML public Attribute visibility Type Other Function visibility parameter returns action Convert*XML public Document * Returns the newly create at3 Diagram object based on the Document getnodename private Node String returns the name of the given node getbounds private Node Rectangle returns Rectangle with the nodes points xml Package This is a library used to parse XML files w3c Package This is a library used to create DOM object agenttool Package This package contains the model for at3 Diagrams preferences Package This package allows the user to determine which rules to use during validation. These are separated into diagram specific rules. 45

49 Figure 12: preferences Package Structure At3ValidationPrimaryPreferencePage This class creates a UI preference page that contains a default page for at3 preferences. class visibility extends implements At3ValidationPrimaryPreferencePage public FieldEditorOverlaypage IWorkbenchPr eferencepage Attribute visibility Type Other active private BooleanFieldEditor warnings private BooleanFieldEditor errors private BooleanFieldEditor ACTIVE private String static final 46

50 WARNINGS private String static final ERROR private String static final FALSE private String static final TRUE private String static final Function visibility parameter returns action At3ValidatioinPrimaryPreferencePage public Constructor dogetpreferencestore public none IPreferenceSto re returns the workspace preference store init public IWorkbench void sets the page description field getpageid protected none String returns the string id needed to access preference createfieldeditors protected none void adds content to the page getoverlaypreferencevalue public IPreferenceStore, IResource, String, String String returns the preference value in store by determining if the project is using specific preferences useprojectsetting private IResource, String boolean returns whether or not the given resource is using project specific properties getpropery private IResource, String, String String returns the propery associated to given key performok public none boolean performs actions to complete request handlepropertyactiveselection private IProject void adds or remove project nature depending of project preferences handlewarningselection private IProject void removes all error problems from IProject is consistent with user preferences handleerrorselection private IProject void removes all error problems from IProject is consistent with user preferences performapply public none void same as performok PreferenceConstants This class contains static references to preference options. class visibility extends implements PreferenceConstants public Attribute visibility Type Other ACTIVE public String static final ERRORS public String static final WARNINGS public String static final SR3_1 public String static final SR3_2 public String static final SR3_3 public String static final SR3_4 public String static final 47

51 SR3_5 public String static final SR4_1 public String static final SR4_2 public String static final SR4_3 public String static final SR4_4 public String static final SR4_5 public String static final SR4_6 public String static final SR4_7 public String static final SR4_8 public String static final SR4_9 public String static final SR4_10 public String static final SR4_11 public String static final SR5_1 public String static final SR5_2 public String static final SR6_1 public String static final SR6_2 public String static final SR6_3 public String static final SR6_4 public String static final SR6_5 public String static final SR6_6 public String static final SR7_1 public String static final SR7_2 public String static final SR7_3 public String static final SR7_4 public String static final SR7_5 public String static final SR7_6 public String static final SR7_7 public String static final SR8_1 public String static final SR8_2 public String static final PreferenceInitializer This class contains the default values for the preference constants. class visibility extends implements At3ValidationPrimaryPreferencePage public AbstractPreferenceInitializaer Attribute visibility Type Other Function visibility parameter returns action initializedefaultpreferences public none void inits all values in preference store to true. These are the preference constant values diagram.specific This package contains classes similar to the At3ValidationPrimaryPreferencePage but is designed to maintain diagram specific preferences of validation rules. 48

52 Figure 13: diagram.specific preferences pages At3Validation *DiagramRulesPreferencePage (*) represents each of the six at3 diagrams class visibility extends implements At3Validation*ActivityDiagramRules PreferencePage public FieldEditorPreferenceP age IWorkbenchPref erencepage Attribute visibility Type Other rule preference identifier private BooleanFieldEditor one for each value in preference store rule preference description private String one for each final static value in preference store Function visibility parameter returns action At3Validation*ActivityDiagramRules public none Constructor PreferencePage createfieldeditors public none void initializes all rule BooleanFieldEditors with PreferenceConstants value and String rule preference description performok public none boolean calls setvalue for each BooleanFieldEditor init public IWorkbench void initializes the page 49

53 setvalue private BooleanFieldEditor, constant 6.7. properties Package void sets the preference values according to settings on the page and The properties package provides the user a way to turn on/off at3validation on a per package basis. Figure 14: properties package Structure FieldEditorOverlayPage This class creates the at3 Validation overlay page contents and actions. The overlay page allows us to distinguish between project specific properties and workspace properties. class visibility extends implements FieldEditorOverlayPage public FieldEditorPreferencePage IWorkbenchPr eferencepage Attribute visibility Type Other USERPROJECTSETTINGS public String static final FALSE private String static final TRUE private String static final editors private List element private IAdaptable useworkspacebutton private Button useprojectsettingbutton private Button configurebutton private Button overlaystore private IPreferenceStore image private ImageDescriptor 50

54 pageid private String Function visibility parameter returns action FieldEditorOverlayPage public String, int Constructor FieldEditorOverlayPage public String, ImageDescriptor, int Constructor getpageid protected none String returns image setelement public IAdaptable void sets element to given value getelement public none IAdaptable returns element ispropertypage public none boolean returns whether element is null or not addfield protected FieldEditor void adds a FieldEditor to editors createcontrol public Composite void creates overlaystore is project page createcontents protected Composite Control creates the contents of the page createselectiongroup private Composite void Creates the page with useworkspacebutton, useprojectsettingsbut on, and configurebutton. createradiobutton private Composite, String Button Helper method to create radio buttons getpreferencestore public none IPreferenceSto re returns overlay page if property page, otherwise returns workspace preference store updatefieldeditors protected boolean void enables or disables radio buttons performok public none boolean sets property values in store on end performdefaults protected none void resets editors to default value configureworkspacesettings protected none void sets up preference page showpreferencepage protected String, IPreferensePage void shows preference page to user PropertyStore This class is used to store property specific preferences. It models the IPreferenceStore. class visibility extends implements PropertyStore public PreferenceStore Attribute visibility Type Other resource private IResource workbenchstore private IPreferenceStore pageid private String inserting private boolean init to false Function visibility parameter returns action PropertyStore public IResource, Constructor IPreferenceStore, String save public none void calls writeproperties 51

55 save public OutputStream, String void calls writeproperties writeproperties private none void for all preferences, calls setproperty setproperty private String, String void sets persistent properties on resource with given values and key getdefaultboolean public String boolean returns default boolean value of String in workbenchstore getdefaultdouble public String double returns default double value of String in workbenchstore getdefaultfloat public String float returns default float value of String in workbenchstore getdefaultint public String int returns default int value of String in workbenchstore getdefaultlong public String long returns default long value of String in workbenchstore getdefaultstring public String String returns default String value of String in workbenchstore getboolean public String boolean inserts value String into propertystore if needed and returns value of key String getdouble public String double inserts value double into propertystore if needed and returns value of key String getfloat public String float inserts value float into propertystore if needed and returns value of key String getint public String int inserts value int into propertystore if needed and returns value of key String getlong public String long inserts value long into propertystore if needed and returns value of key String getstring public String String inserts value String into propertystore if needed and returns value of key String insertvalue private String void helper method to insert values into propertystore if needed 52

56 getproperty private String String returns resource persistent property of String contains public String boolean returns whether or not the workbenchstore contains the value String settodefault public String void calls setvalue with String, and getdefaultstring(strin g) isdefault public String boolean returns whether or not the given value is the default value rules Package This package is a collection of rules that at3validation will use to validate at3 diagrams. Each rule that is implemented will need to extend ARule and implement IRule. 53

57 Figure 15: rules Package Structure IRule This class defines an interface to be implemented by at3 Validation rules. The interface ensures that each rule implemented will contain a run method, which executes the rule, and a active method that returns this rules active preference; whether to run the rule or not. 54

58 class visibility extends implements IRule public Attribute visibility Type Other Function visibility parameter returns action run public IResource ARule This class contains abstract methods that will be shared between all at3 Validation rules. The functionality provided by ARule includes gather the other diagrams XML files for comparison and determining diagram types from the file extensions. Each of the project s preferences are set in the resources project. class visibility extends implements ARule public IRule Attribute visibility Type Other name public String static state public String static Function visibility parameter returns action ARule public none Constructor setname public String void Sets the name of the rule to String getname public noon String Returns the name of the rule getactivestate public IProject boolean Returns whether or not the rule is active according to the project s preferences setproblemstate public String void Sets the rule s problem type to either a warning or an error getproblemstate public IProject boolean Returns whether or not the rules problem preferences is true or false getproblemsetting public none String Returns the rule problem type getproblemstateint private none int Returns the rules problem type consistent with IMarker.SEVERITY getpageid protected none String returns the page id UpdateMarker public IResource, boolean, String void Places a marker on IResource with String if boolean is true and if oktomark is true. It also removes all previous markers with the given String description from IResource oktomark public IResource boolean Returns whether the current preference settings allow us to place a marker on the given IResource DetermineDiagramType public String Integer Returns an Integer value consistent with DiagramType according to the String retrievefromcache public IResource Object Gets an at3 Diagram object from cache that represents the given IResource getotherdiagrams public IResource, Integer List Returns a list of all IResources present in the same directory as IResource and that are of type Integer(DiagramType) 55

59 runassecondary public IResource, Integer void Runs the rule on the IResource Activity, Agent, Goal, Organization, Role, Sequence Packages These packages contain individually implemented rules. Each at3 Validation rule will be located in this package and must extend ARule and implement IRule. Below is an example of a rule, SR4.1. class visibility extends implements SR4_1 public ARule Attribute visibility Type Other Function visibility parameter returns action SR4_1 public none Constructor run public IResource void runs the rule on IResource and updates markers appropriately Example: SR4.1 is a rule taken from the Vision Document for this project. When implementing this rule, we must create a new class that extends ARule and implements IRule. This class will be placed in the Agent folder, since it pertains to the agent diagram rules. Implementing IRule ensures that this rule contains the correct methods needed in order to be run. Extending ARule gives the user access to helper methods that all of our rules need in order to work. All the developer must do is implements the business logic that it takes to run the rule; i.e., comparing roles in two diagrams wizards Package This package provides the user with an easy way to add new rules to the at3 Validation plug-in. 56

60 Structure NewRuleWizard Figure 16: wizards package This class is used to create a Wizard that follows NewRuleTemplate. The functions within this class have no action, but are implemented in NewRuleTemplate class visibility extends implements NewRuleWizard public Wizard IExtensionWizard Attribute visibility Type Other project private IProject pluginmodel private IPluginModel Base Function visibility parameter returns action init public IProject, void IPluginModel Base addpages public none void canfinish public none boolean createpagecontrol public Composite void dispose public none void getcontainer public none IWizardContainter getdefaultpageimage public none Image getdialogsettings public none IDialogSettings getnextpage public IWizardPage IWizardPage getpage public String IWizardPage 57

61 getpagecount public none int getpages public non IWizardPage[] getpreviouspage public IWizardPage IWizardPage gettitlebarcolor public none RGB getwindowtitle pubic none String ishelpavailable public none boolean needspreviousandnextbutto public none boolean ns needsprogressmonitor public none boolean performcancel public none boolean performfinish public none boolean setcontainer pubic IWizardContai ner void NewRuleTemplate This class is responsible for showing the user a dialog to guide the user through creating a new rule using the diagram.rule extension schema. It is needed as apart of the newextension extension. class visibility extends implements NewRuleTemplate public OptionTemplateSe ction Attribute visibility Type Other KEY_CLASS_NAME public String static final classname KEY_MESSAGE public String static final message CLASS_NAME public String static final SampleAction Function visibility parameter returns action NewRuleTemplate public none Constructor, sets total # of pages to 4 getsectionid public none String Returns the section id getnumberofworkunits public none int Returns the number of working units from the super plus 1 createoptions private none void Creates each of the options on all the pages addpages public Wizard void Adds all the pages to Wizard validateoptions public TemplateOption void Validates the choices in the TemplateOption validatecontainerpage private TemplageOption void Validates the information on a page isdependentonparentwizard public none boolean Returns whether the wizard is apart of a parent component initializefields protected IFieldData void init all of the wizards fields initializefields public IPluginModelBase void init all of the wizards fields getusedextensionpoint public none String Returns the extension point used updatemodel protected IProgressMonitor void Adds a new extension to the extension factory determinelocation private none String This gives a predetermined directory to place our new class. It ensures organization getnewfiles public none String[] Returns all new files getformattedpackagename protected String String Returns the formatted package name getinstallurl protected none URL returns the installed url 58

62 getpluginresourcebundle protected none ResourceBu ndle returns the plugin resource bundle Extension Schema Creating new rules to use during validation of at3 Diagram is simplified by using the extension schema diagram.rule. This schema contains an outline for each rule and the information needed to create new rules Structure Schema diagram.rule Field extension Attributes point id name Field rule Attributes name class problemtype primarydiagram activitydiagramdependent agentdiagramdependent goaldiagramdependent rolediagramdependent sequencediagramdependent orgdiagramdependent Description the extension point name defines the extension point The point extended by each rule in validation. This is an optional attribute that may be used as an identifier for this extension. A human readable name for this extension. This is optional. the definition of a new rule The human readable name of this extension. This is optional. The fully qualified name of the class that extends The type of problem marker this rule creates. This is an enumeration that identified the primary diagram this rule is associated with. This is required. This is true if this rule is associated with the at3 Activity Diagram. Default to false. This is true if this rule is associated with the at3 Agent Diagram. Default to false. This is true if this rule is associated with the at3 Goal Diagram. Default is false. This is true if this rule is associated with the at3 Goal Diagram. Default is false. This is true if this rule is associated with the at3 Orgainzational Diagram. Default is false. This is true if this rule is associated with the at3 Sequence Diagram. Default is false. 59

63 Chapter 7 Test Plan 7.1. Test Plan Identifier at3-validation-v Introduction This document provides the testing procedure for agenttool III Validation. This project compares agenttool III diagrams and reports rule inconsistencies to the user. The rules are provided by agenttool III developers. The first working set of rules can be found in the Vision Document v. 2.0, provided as a part of this project. These requirements will be the focus of testing Test Items The following items will be tested. Activity Diagram Rules Agent Diagram Rules Goal Diagram Rules Organizational Diagram Rules Role Diagram Rules Sequence Diagram Rules Changing preferences Activating/Deactivation of at3 Validation 7.4. Tested Features All features listed below will be tested. Theses features can also be found in the Vision Document v Activity Diagram Features SR3.1. The name of the activity diagram must be the same as a service within a role or agent diagram. This is reported as an error. SR3.2. An incoming event within the activity diagram must be a message in a sequence diagram. This is reported as an error. SR3.3. An outgoing event within the activity diagram must be a message in a sequence diagram. This is reported as an error. SR3.4. Swim-lanes must have an associated label tag. This is reported as an error. SR3.5. Label tags associated with each swim-lane must be named after a role in a role diagram. This is reported as an error Agent Diagram Features SR4.1. Each agent that is connected to a role by a plays relation must also be connected to every capability that the role is connected to by a requires relation in the role diagram by a possess relation. This is reported as an error. SR4.2. Each role should exist in a role diagram present in the current directory. This is reported as a warning SR4.3. A protocol must exist to at least one other agent or organization from each agent in agent diagram. This is reported as a warning. 60

64 SR4.4. Each agent must be connected to a role with the play relation or be connected to a capability with the possess relation. This is reported as an error. SR4.5. No agents may be connected with a protocol relation unless the roles they connect to with the plays relation are themselves connected by a protocol relation in a Role Diagram. This is reported as an error. SR4.6. Each organization must be connected to another organization or agent with a protocol relation. This is reported as a warning. SR4.7. Each service should be connected to at least one agent or organization with a provides relation. This is reported as a warning. SR4.8. Each service should be named after one activity diagram present in the current directory. This is reported as a warning. SR4.9. Each capability should be connected to at least one agent in the diagram with a possess relation. This is reported as a warning. SR4.10. Each actor must be connected to some agent or organization with a protocol relation. This is reported as a warning. SR4.11. Each actor should exist in at least one role diagram. This is reported as a warning Goal Diagram Features SR5.1. Goals within the goal diagram must be connected to all other goals in the diagram in tree form. Tree form consists of both nodes and leaves. A node is a goal that is connected to at least one child leaf or node. A leaf has no children nodes or leaves. This is reported as an error. SR5.2. Leaf nodes should be connected to at least one role in a role diagram by the achieved relation. This is reported as a warning Organizational Diagram Features SR6.1. Each goal must be also be in a goal diagram present in the current directory. This is reported as an error. SR6.2. Each goal must be connected to an organization by a achieves relation. This is reported as an error. SR6.3. Each service must be connected to the organization element by a provide relation. This is reported as a warning. SR6.4. Each service must be associated with an activity diagram with the same name. The activity diagram must present in the current directory. This is reported as a warning. SR6.5. Can contain only one organization element. This is reported as an error. SR6.6. Each actor must be connected to another actor or organization within the same diagram by the protocol relation. This is reported as an error Role Diagram Features SR7.1. Each role must be connected to at least one other role by the protocol relation. This is reported as a warning. SR7.2. Each role should be connected to at least one agent in an agent diagram by the played relation. This is reported as a warning. 61

65 SR7.3. Each goal is in a goal diagram present in the current directory. This is reported as an error. SR7.4. Each actor must be connected to a role by the protocol relation. This is reported as an error. SR7.5. Each role must be connected to at least one goal by the achieves relation. This is reported as a warning. SR7.6. Each service must be associated with an activity diagram with the same name. This is reported as a warning. SR7.7. Each goal must be associated with a role in by the achieved relation. This is reported as a warning Sequence Diagram Features SR8.1. There must be exactly two roles within a sequence diagram. These roles must also exist within role diagrams. This is reported as an error. SR8.2. The two roles within the sequence diagram should have a protocol relation defined between them in a role diagram. This is reported as a warning Activation/Deactivation of Plug-in Feature SR1.2. All validation rules will have the ability to be either active or inactive Features not to be tested The ability to add new rules will not be tested Approach For testing, a series of actions will be performed by the user. These actions will be test scenarios. The scenarios will be evaluated by the visual result of the action performed. The acceptable outcome for each scenario is listed in Section 10, Test Task. The use of TPTP Automated GUI Recorder, an extension to Eclipse s testing tools, may be used during testing. This tool allows successive execution of the test suites to be completed by the system, instead of the user, resulting in better productivity Item Pass/Fail Criteria Each test suite will be considered successful if it results in the same as mentioned in the Vision Document. The test suite will fail if this is not the case Suspension Criteria and Resumption Requirements Suspension Criteria If a test case fails, all further testing will be suspended. The failure will be logged into the Testing Log Resumption Requirements Post test case failure, testing of at3 Validation will resume once the failure has been logged and a solution has been found. Testing will continue from the beginning of the testing procedure. This is done to ensure that any changes found post failure have not negatively affected previous test cases. 62

66 7.8. Test Deliverables A Test Log will be maintained during testing and provided concluding testing. All tests will be recorded as either passed or failed. All failed test will contain a description, date, and time of the failure, along with a recommended solution Testing Tasks The user needs to save work after each Test # execution. The user will create a new Java Project in the current workspace before beginning each test Suite Test Suite 1 SR3 & Activity Active Preference Settings Test # Description Expected Outcome Actual Outcome TS1.1 The user will change the agenttool III preferences to run only Activity Diagram Rules TS1.2 The user will create a new Activity Diagram, named ActivityDiagram.activity A new ERROR problem is visible to the user through the Problems tab TS1.3 The user will create a new Agent Diagram, named AgentDiagram.agent TS1.4 The user will create one service component in TS1.5 AgentDiagram.agent The user will rename the service created in TS1.4 to ActivityDiagram The ERROR problem introduced in step TS1.1 is no longer visible in the Problems tab. TS1.6 The user will delete AgentDiagram.agent A new ERROR problem is visible to the user through the Problems tab TS1.7 TS1.8 TS1.9 The user will create a new Role Diagram, named RoleDiagram.role The user will create one service component in RoleDiagram.role The user will rename the service created in TS1.8 to ActivityDiagram. The ERROR problem introduced in step TS1.5 is no longer visible in the Problems tab TS1.10 The user will delete the service, ActivityDiagram A new ERROR problem is visible to the user through the Problems tab TS1.11 TS1.12 TS1.13 TS1.14 TS1.15 TS1.16 The user will create a new Sequence Diagram, named SequenceDiagram.sequence. The user will place one incoming event component on the activity diagram The user will rename the incoming event created in TS1.12 to incoming event 1 The user will place two new class roles in SequenceDiagram.sequence The user will create one new Synchronized Message component in SequenceDiagram.sequence. The user will rename the Message created in TS1.15 to incoming event 1 A new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS1.12 is no longer visible in the Problems tab 63

67 TS1.17 TS1.18 TS1.19 TS1.20 TS1.21 TS1.22 TS1.23 TS1.24 TS1.25 TS1.26 The user will place one outgoing event component on the activity diagram The user will rename the outgoing event create in TS1.18 to outgoing event 1 The user will create one new Synchronized Message component in the SequenceDiagram.sequence The user will rename the Message create in TS1.19 to out going event 1. The user will place one swim lane component on the activity diagram The user will place one tag component on the swim lane component that was created in step TS1.21 The user will rename the tag created in TS1.22 to SwimLane The user will create one role component in RoleDiagram.role. The user will rename the role created in step TS1.24 to SwimLane. The user will delete the tag created in step TS1.122 A new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS1.17 is no longer visible in the Problems tab A new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS1.21 is no longer visible in the Problems tab and a new ERROR problem is visible to the user through the Problems tab. ERROR problem introduced in step TS1.22 is no longer visible in the Problems tab A new ERROR problem is visible to the user through the Problems tab and error introduced in TS1.21 is no longer visible Test Suite 2 SR4 and Agent Active Preference Settings Test # Description Expected Outcome Actual Outcome TS2.1 The user will change the agenttool III preferences to run only Agent Diagram Rules. TS2.2 The user will create a new Agent Diagram named AgentDiagram.agent TS2.3 The user will create a new Activity Diagram named ActivityDiagram.activity TS2.4 The user will create a new Role Diagram named RoleDiagram.role 64

68 TS2.5 TS2.6 TS2.7 TS2.8 TS2.9 TS2.10 TS2.11 TS2.12 TS2.13 TS2.14 TS2.15 TS2.16 TS2.17 TS2.18 TS2.19 TS2.20 TS2.21 TS2.22 The user will place one agent component onto AgentDiagram.agent The user will rename the agent component created in TS2.2 to Agent1 The user will place one role component onto AgentDiagram.agent The user will rename the role component created in TS2.7 to Role1 The user will place one capability component onto AgentDiagram.agent The user will rename the capability created in step TS2.9 to Cap1 The user will place one service component onto AgentDiagram.agent The user will rename the service created in TS2.11 to Service1 The user will place one organization component onto AgentDiagram.agent The user will rename the organization created in TS2.13 to Org1 The user will place on actor component onto AgentDiagram.agent The user will rename the actor created in TS2.15 to Actor1 The user will place one role component onto RoleDiagram.role The user will rename the role component created in TS2.17 to Role1 The user will place one capability component onto RoleDiagram.role The user will rename the capability created in TS2.19 to Cap1 The user will place one actor component onto RoleDiagram.role The user will rename the actor created in TS2.21 to Actor1 One new WARNING problem is visible to the user through the Problems tab and one new ERROR problem is visible to the user through the Problems tab One new WARNING problem is visible to the user through the Problems tab One new WARNING problem is visible to the user through the Problems tab Two new WARNING problems are visible to the user through the Problems tab One new WARNING problem is visible to the user through the Problems tab Two new WARNING problems are visible to the user through the Problems tab The WARNING problem introduced in step TS2.7 is no longer visible in the Problems tab One Warning problem introduced in TS2.15 is no longer visible in the Problems tab 65

69 TS2.23 TS2.24 TS2.25 TS2.26 TS2.27 TS2.28 TS2.29 TS2.30 TS2.29 TS2.30 TS2.31 TS2.32 The user will place a requires relationship between Role1 and Cap1 in RoleDiagram.role. The user will place a plays relationship between Agent1 and Role1 in AgentDiagram.agent The user will place a possess relationship between Agent1 and Cap1 in AgentDiagram.agent The user will place one agent component onto AgentDiagram.agent The user will rename the agent component created ints2.26 to Agent2 The user will place a protocol relationship between Agent1 and Agent2 in AgentDiagram.agent. The user will place one role component onto RoleDiagram.role The user will rename the role created in TS2.29 to Role2 The user will place one role component onto AgentDiagram.agent The user will rename the role created in TS2.29 to Role2 The user will place a plays relationship between Agent2 and Role1 in AgentDiagram.agent The user will place a protocol relationship between Role1 and Role2 in RoleDiagram.role One new ERROR problem is visible to the user through the Problems tab and the Error Problem introduced in TS2.5 is no longer visible in the Problems tab The ERROR introduced by TS2.24 and the WARNING introduced by TS2.9 are no longer visible in the Problems tab One new WARNING problem is visible to the user through the Problems tab and one new ERROR problem is visible to the user through the Problems tab The WARNING problem introduced in step TS2.5 and the WARNING introduced in TS2.26 are no longer visible in the Problems tab and one new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS2.26 is no longer visible in the Problems tab and 1 new ERROR problem is no visible in the problems tab The ERROR problem introduced in step TS2.31 is no longer visible in the Problems tab 66

70 TS2.33 TS2.34 TS2.35 TS2.36 TS2.37 The user will place a protocol relationship between Org1 and Agent1 in AgentDiagram.agent The user will place a provides relationship between Service1 and Agent1 in AgentDiagram.agent The user will rename Service1 in AgentDiagram.agent to ActivityDiagram The user will place a protocol relationship between Actor1 and Org1 in AgentDiagram.agent The user will rename the actor created in TS2.37 to Actor1 The WARNING problem introduced in step TS2.13 is no longer visible in the Problems tab The WARNING problem introduced in step TS2.11 is no longer visible in the Problems tab One WARNING problem introduced in step TS2.13 is no longer visible in the Problems tab One WARNING problem introduced in step TS2.15 is no longer visible in the Problems tab Test Suite 3 SR5 & Goal Active Preference Settings Test # Description Expected Outcome Actual Outcome TS3.1 TS3.2 TS3.3 TS3.4 TS3.5 TS3.6 TS3.7 TS3.8 TS3.9 TS3.10 TS3.11 The user will change the agenttool III preferences to run only Goal Diagram Rules The user will create one new Goal Diagram named GoalDiagram.goal The user will create one new Role Diagram named RoleDiagram.role The user will place one goal component onto GoalDiagram.goal The user will rename the goal created in TS3.4 to Goal1 The user will place one goal component onto RoleDiagram.role The user will rename the goal created in TS3.6 to Goal1 The user will place one role component onto RoleDiagram.role The user will rename the role component created in h to Role1 The user will place an achieves relationship between Goal1 and Role1 in RoleDiagram.role The user will place one goal component onto GoalDiagram.goal One new WARNING problem is visible to the user through the Problems tab The WARNING problem introduced in step d is no longer visible in the Problems tab Two new ERROR problems and one new WARNING problems are visible to the user through the Problems tab 67

71 TS3.12 TS3.13 TS3.14 TS3.15 The user will rename the goal created in TS3.11 to Goal2 The user will place an and relationship from Goal1 to Goal2 in GoalDiagram.goal The user will change the name of the goal created in TS3.8 to Goal 2 in the RoleDiagram.role The user will change the name of the Goal created in TS3.11 to Goal 2 in the GoalDiagram.goal The two ERROR introduced in TS3.11 and the WARNING introduced in TS3.11 are no longer visible to the user. One new WARNING is now visible to the user. The WARNING problem introduced in step TS3.13 is no longer visible in the Problems tab Test Suite 4 SR6 & Organization Active Preference Settings Test # Description Expected Outcome Actual Outcome TS4.1 The user will change the agenttool III preferences to run only Organization Diagram Rules TS4.2 The user will create one Organization Diagram name OrgDiagram.org TS4.3 The user will create one Activity Diagram named ActivityDiagram.activity TS4.4 The user will create one Goal Diagram named GoalDiagram.goal TS4.5 The user will place one goal component onto OrgDiagram.org Two new ERROR problems are visible to the user through the Problems tab TS4.6 The user will rename the goal created in TS4.5 to Goal1 TS4.7 The user will place one goal component onto TS4.8 TS4.9 TS4.10 TS4.11 TS4.12 GoalDiagram.goal The user will rename the goal created in TS4.7 to Goal1 The user will place one organization component onto OrgDiagram.org The user will rename the organization created in TS4.9 to Org1 The user will place one service component onto OrgDiagram.role The user will rename the service created in TS4.11 to ActivityDiagram One ERROR problem introduced in step TS4.5 is no longer visible in the Problems tab Two new WARNING problems are visible to the user through the Problems tab One WARNING problem introduced in step TS4.11 is no longer visible in the Problems tab 68

72 TS4.13 The user will place one organization component onto OrgDiagram.org One new ERROR problem is visible to the user through the Problems tab TS4.14 The user will rename the organization created in TS4.13 to Org2 TS4.15 The user will delete Org2 One ERROR problem introduced in step TS4.13 is no longer visible in the Problems tab. TS4.16 TS4.17 TS4.18 TS4.19 TS4.20 The user will place one actor component onto OrgDiagram.org The user will rename the actor created in TS4.16 to Actor1 The user will place an achieves relationship between Goal1 and Org1 in OrgDiagram.org The user will place one provides relationship between ActivityDiagram (Service) and Org1 in OrgDiagram.org The user will place one protocol relationship between Actor1 and Org1 One new ERROR problem is visible to the user through the Problems tab ERROR problem introduced in step TS4.5 is no longer visible in the Problems tab One WARNING problem introduced in step TS4.11 is no longer visible in the Problems tab One ERROR problem introduced in step TS4.16 is no longer visible in the Problems tab Test Suite 5 SR7 & Role Active Preference Settings Test # Description Expected Outcome Actual Outcome TS5.1 The user will change the agenttool III preferences to run only Role Diagram Rules TS5.2 The user will create one Role Diagram named RoleDiagram.role TS5.3 The user will create one Agent Diagram named AgentDiagram.agent TS5.4 The user will create one Goal Diagram named GoalDiagram.goal TS5.5 The user will create one Activity Diagram named ActivityDiagram.activity TS5.6 The user will place one role component onto RoleDiagram.role Three new WARNING problems are visible to the user through the Problems tab TS5.7 The user will rename the role created in TS5.6 to TS5.8 Role1 The user will place one role component onto RoleDiagram.role Three new WARNING problems are visible to the user through the Problems tab 69

73 TS5.9 TS5.10 TS5.11 TS5.12 TS5.13 TS5.14 TS5.15 TS5.16 TS5.17 TS5.18 TS5.19 TS5.20 TS5.21 TS5.22 TS5.23 TS5.24 TS5.21 The user will rename the role created in TS5.8 to Role2 The user will place one agent component onto AgentDiagram.agent The user will rename the agent component created in TS5.10 to Agent1 The user will place one goal component onto RoleDiagram.role The user will rename the goal created in TS5.12 to Goal1 The user will place one goal component onto GoalDiagram.goal The user will rename the goal created in TS5.14 to Goal1 The user will place one actor component onto RoleDiagram.role The user will rename the actor created in TS5.16 to Actor1 The user will place one service component onto RoleDiagram.role The user will rename the service created in TS5.18 to ActivityDiagram The user will place one protocol relationship between Role1 and Role2 in RoleDiagram.role The user will place one role component onto AgentDiagram.agent The user will rename the role created in TS5.21 to Role1 The user will place one role component onto AgentDiagram.agent The user will rename the role created in TS5.213 to Role2 The user will place one plays relationship between Role1 and Agent1 in AgentDiagram.agent One new ERROR problem and one new WARNING are visible to the user through the Problems tab One new ERROR problem is visible to the user through the Problems tab and the ERROR introduced in TS5.12 is no longer visible to the user One new WARNING problem is visible to the user through the Problems tab The WARNING problem introduced in step TS5.18 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.6 and one WARNING problem introduced in step TS5.8 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.6 is no longer visible in the Problems tab 70

74 TS5.22 TS5.23 TS5.24 TS5.25 The user will place one plays relationship between Role2 and Agent1 in AgentDiagram.agent The user will place one protocol relationship between Actor1 and Role1 in RoleDiagram.role The user will place one achieves relationship between Goal1 and Role1 in RoleDiagram.role The user will place one achieves relationship between Goal1 and Role2 in RoleDiagram.role One WARNING problem introduced in step TS5.8 is no longer visible in the Problems tab One ERROR problem introduced in step TS5.16 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.6 is no longer visible in the Problems tab and one WARNING problem introduced in step TS5.12 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.8 is no longer visible in the Problems tab Test Suite 6 SR8 & Sequence Active Preference Settings Test # Description Expected Outcome Actual Outcome TS6.1 The user will change the agenttool III preferences to run only Sequence Diagram Rules TS6.2 The user will create one Sequence Diagram named SequenceDiagram.sequence One new ERROR problem is visible to the user through the Problems tab TS6.3 The user will create one Role Diagram named TS6.4 TS6.5 TS6.6 TS6.7 TS6.8 RoleDiagram.role The user will place one classrole component onto SequenceDiagram.sequence The user will rename the classrole component created in TS6.4 to Role1 The user will place one classrole component onto SequenceDiagram.sequence The user will rename the classrole component created in TS6.6 to Role2 The user will place one role component onto RoleDiagram.role One new ERROR problem is visible to the user through the Problems tab One new ERROR problem and one new WARNING problem are visible to the user through the Problems tab and one ERROR problem introduced in step TS6.2 is no longer visible in the Problems tab 71

75 TS6.9 TS6.10 TS6.11 TS6.12 The user will rename the role component created in TS6.8 to Role1 The user will place one role component onto RoleDiagram.role The user will rename the role component created in TS6.10 to Role2 The user will place a protocol relationship between Role1 and Role2 in RoleDiagram.role One ERROR problem introduced in step TS6.6 is no longer visible in the Problems tab One ERROR problem introduced in step TS6.6 is no longer visible in the Problems tab One WARNING problem introduced in step TS6.6 is no longer visible in the Problems tab Test Suite 7 Activation/Deactivation of at3 Validation Test # Description Expected Outcome Actual Outcome TS7.1 The user will change the agenttool III project preferences to deactivate at3 Validation TS7.2 The user will create one Agent Diagram named AgentDiagram.agent TS7.3 The user will place one agent component onto AgentDiagram.agent TS7.4 The user will change the agenttool III project preferences to activate at3 Validation One new WARNING problem is visible to the user through the Problems tab and one new ERROR problem is visible to the user through the Problems TS7.5 The user will change the agenttool III project preferences to deactivate at3 Validation tab Both the WARNING and ERROR introduced in step TS7.4 are no longer visible in the Problems tab 72

76 Chapter 8 Test Assessment Evaluation 8.1. Introduction This chapter details the test conducted on Patrick Gallagher s MSE Project. This project was an Eclipse plug-in called at3validation used to validate at3 diagrams. Functionality for this plug-in was tested based on chapter 7, Test Plan Test Result Summary Test Case Requirements Tested Pass/Fail TS.1 SR3.1, SR3.2, SR3.3, SR3.4, SR3.5 PASS TS.2 SR4.1, SR4.2, SR4.3, SR4.4, SR4.5, PASS SR4.6, SR4.7, SR4.8, SR4.9, SR4.10, SR4.11 TS.3 SR5.1, SR5.2 PASS TS.4 SR6.1, SR6.2, SR6.3, SR6.4, SR6.5, PASS SR6.6 TS.5 SR7.1, SR7.2, SR7.3, SR7.4, SR7.5, PASS SR7.6, SR7.7 TS.6 SR8.1, SR8.2 PASS TS.7 SR1.2 PASS 8.3. Test Results in Detail Test Suite 1 SR3 & Activity Active Preference Settings Test # Description Expected Outcome Actual Outcome TS1.1 The user will change the agenttool III preferences to run only Activity Diagram Rules TS1.2 The user will create a new Activity Diagram, A new ERROR problem 1 new error present named ActivityDiagram.activity is visible to the user through the Problems tab TS1.3 The user will create a new Agent Diagram, named AgentDiagram.agent TS1.4 The user will create one service component in TS1.5 AgentDiagram.agent The user will rename the service created in TS1.4 to ActivityDiagram The ERROR problem introduced in step TS1.1 is no longer visible in the Problems tab. TS1.6 The user will delete AgentDiagram.agent A new ERROR problem is visible to the user through the Problems tab TS1.7 TS1.8 TS1.9 The user will create a new Role Diagram, named RoleDiagram.role The user will create one service component in RoleDiagram.role The user will rename the service created in TS1.8 to ActivityDiagram. The ERROR problem introduced in step TS1.5 is no longer visible in the Problems tab TS1.10 The user will delete the service, ActivityDiagram A new ERROR problem is visible to the user through the Problems tab Error gone 1 new error present Error gone 1 new error 73

77 TS1.11 TS1.12 TS1.13 TS1.14 TS1.15 TS1.16 TS1.17 TS1.18 TS1.19 TS1.20 TS1.21 TS1.22 The user will create a new Sequence Diagram, named SequenceDiagram.sequence. The user will place one incoming event component on the activity diagram The user will rename the incoming event created in TS1.12 to incoming event 1 The user will place two new class roles in SequenceDiagram.sequence The user will create one new Synchronized Message component in SequenceDiagram.sequence. The user will rename the Message created in TS1.15 to incoming event 1 The user will place one outgoing event component on the activity diagram The user will rename the outgoing event create in TS1.18 to outgoing event 1 The user will create one new Synchronized Message component in the SequenceDiagram.sequence The user will rename the Message create in TS1.19 to out going event 1. The user will place one swim lane component on the activity diagram The user will place one tag component on the swim lane component that was created in step TS1.21 A new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS1.12 is no longer visible in the Problems tab A new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS1.17 is no longer visible in the Problems tab A new ERROR problem is visible to the user through the Problems tab The ERROR problem introduced in step TS1.21 is no longer visible in the Problems tab and a new ERROR problem is visible to the user through the Problems tab. 1 new error total 2 Error gone Total 1 1 new error total 2 Error gone Total 1 1 new Error 2 total Error gone 1 new Error 2 total TS1.23 TS1.24 TS1.25 The user will rename the tag created in TS1.22 to SwimLane The user will create one role component in RoleDiagram.role. The user will rename the role created in step TS1.24 to SwimLane. ERROR problem introduced in step TS1.22 is no longer visible in the Problems tab Error gone 2 total 74

78 TS1.26 The user will delete the tag created in step TS1.122 A new ERROR problem is visible to the user through the Problems tab and error introduced in TS1.21 is no longer visible 1 new error Error gone Test Suite 2 SR4 and Agent Active Preference Settings Test # Description Expected Outcome Actual Outcome TS2.1 The user will change the agenttool III preferences to run only Agent Diagram Rules. TS2.2 The user will create a new Agent Diagram named AgentDiagram.agent TS2.3 The user will create a new Activity Diagram named ActivityDiagram.activity TS2.4 The user will create a new Role Diagram named RoleDiagram.role TS2.5 The user will place one agent component onto AgentDiagram.agent One new WARNING problem is visible to the 1 new warning 1 new error user through the Problems tab and one new ERROR problem is visible to the user through the Problems tab TS2.6 The user will rename the agent component TS2.7 TS2.8 TS2.9 TS2.10 TS2.11 TS2.12 TS2.13 TS2.14 TS2.15 created in TS2.2 to Agent1 The user will place one role component onto AgentDiagram.agent The user will rename the role component created in TS2.7 to Role1 The user will place one capability component onto AgentDiagram.agent The user will rename the capability created in step TS2.9 to Cap1 The user will place one service component onto AgentDiagram.agent The user will rename the service created in TS2.11 to Service1 The user will place one organization component onto AgentDiagram.agent The user will rename the organization created in TS2.13 to Org1 The user will place on actor component onto AgentDiagram.agent One new WARNING problem is visible to the user through the Problems tab One new WARNING problem is visible to the user through the Problems tab Two new WARNING problems are visible to the user through the Problems tab One new WARNING problem is visible to the user through the Problems tab Two new WARNING problems are visible to the user through the Problems tab 1 new warning 2 total warnings 1 total errors 1 new warning 3 total warnings 1 total errors 2 new warnings 5 total warnings 1 total errors 1 new warnings 6 total warnings 1 total errors 2 new errors 6 total warnings 3 total errors 75

79 TS2.16 TS2.17 TS2.18 TS2.19 TS2.20 TS2.21 TS2.22 TS2.23 TS2.24 TS2.25 TS2.26 TS2.27 TS2.28 The user will rename the actor created in TS2.15 to Actor1 The user will place one role component onto RoleDiagram.role The user will rename the role component created in TS2.17 to Role1 The user will place one capability component onto RoleDiagram.role The user will rename the capability created in TS2.19 to Cap1 The user will place one actor component onto RoleDiagram.role The user will rename the actor created in TS2.21 to Actor1 The user will place a requires relationship between Role1 and Cap1 in RoleDiagram.role. The user will place a plays relationship between Agent1 and Role1 in AgentDiagram.agent The user will place a possess relationship between Agent1 and Cap1 in AgentDiagram.agent The user will place one agent component onto AgentDiagram.agent The user will rename the agent component created ints2.26 to Agent2 The user will place a protocol relationship between Agent1 and Agent2 in AgentDiagram.agent. The WARNING problem introduced in step TS2.7 is no longer visible in the Problems tab One Warning problem introduced in TS2.15 is no longer visible in the Problems tab One new ERROR problem is visible to the user through the Problems tab and the Error Problem introduced in TS2.5 is no longer visible in the Problems tab The ERROR introduced by TS2.24 and the WARNING introduced by TS2.9 are no longer visible in the Problems tab One new WARNING problem is visible to the user through the Problems tab and one new ERROR problem is visible to the user through the Problems tab The WARNING problem introduced in step TS2.5 and the WARNING introduced in TS2.26 are no longer visible in the Problems tab and one new ERROR problem is visible to the user through the Problems tab 1 warning gone 5 total warnings 3 total errors 1 error gone 2 total errors 5 total warnings 1 error gone 1 new error 2 total errors 5 total warnings 1 error gone 1 new error 1 total errors 4 total warnings 1 new error 1 new warning 2 total errors 5 total warnings 1 new error 2 warning gone 3 total errors 3 total warnings 76

80 TS2.29 TS2.30 TS2.29 TS2.30 TS2.31 TS2.32 TS2.33 TS2.34 TS2.35 TS2.36 TS2.37 The user will place one role component onto RoleDiagram.role The user will rename the role created in TS2.29 to Role2 The user will place one role component onto AgentDiagram.agent The user will rename the role created in TS2.29 to Role2 The user will place a plays relationship between Agent2 and Role1 in AgentDiagram.agent The user will place a protocol relationship between Role1 and Role2 in RoleDiagram.role The user will place a protocol relationship between Org1 and Agent1 in AgentDiagram.agent The user will place a provides relationship between Service1 and Agent1 in AgentDiagram.agent The user will rename Service1 in AgentDiagram.agent to ActivityDiagram The user will place a protocol relationship between Actor1 and Org1 in AgentDiagram.agent The user will rename the actor created in TS2.37 to Actor1 The ERROR problem introduced in step TS2.26 is no longer visible in the Problems tab and 1 new ERROR problem is no visible in the problems tab The ERROR problem introduced in step TS2.31 is no longer visible in the Problems tab The WARNING problem introduced in step TS2.13 is no longer visible in the Problems tab The WARNING problem introduced in step TS2.11 is no longer visible in the Problems tab One WARNING problem introduced in step TS2.13 is no longer visible in the Problems tab One WARNING problem introduced in step TS2.15 is no longer visible in the Problems tab 1 new error 1 error gone 3 total errors 3 total warnings 1 error gone 2 total errors 3 total warnings 1 warning gone 2 total errors 2 total warnings 1 warning gone 2 total errors 1 total warnings 1 warning gone 2 total errors 0 total warnings 1 error gone 1 total errors 0 total warnings 1 warning gone 0 total errors 0 total warnings Test Suite 3 SR5 & Goal Active Preference Settings Test # Description Expected Outcome Actual Outcome TS3.1 TS3.2 TS3.3 The user will change the agenttool III preferences to run only Goal Diagram Rules The user will create one new Goal Diagram named GoalDiagram.goal The user will create one new Role Diagram named RoleDiagram.role 77

81 TS3.4 TS3.5 TS3.6 TS3.7 TS3.8 TS3.9 TS3.10 TS3.11 TS3.12 TS3.13 TS3.14 TS3.15 The user will place one goal component onto GoalDiagram.goal The user will rename the goal created in TS3.4 to Goal1 The user will place one goal component onto RoleDiagram.role The user will rename the goal created in TS3.6 to Goal1 The user will place one role component onto RoleDiagram.role The user will rename the role component created in h to Role1 The user will place an achieves relationship between Goal1 and Role1 in RoleDiagram.role The user will place one goal component onto GoalDiagram.goal The user will rename the goal created in TS3.11 to Goal2 The user will place an and relationship from Goal1 to Goal2 in GoalDiagram.goal The user will change the name of the goal created in TS3.8 to Goal 2 in the RoleDiagram.role The user will change the name of the Goal created in TS3.11 to Goal 2 in the GoalDiagram.goal One new WARNING problem is visible to the user through the Problems tab The WARNING problem introduced in step d is no longer visible in the Problems tab Two new ERROR problems and one new WARNING problems are visible to the user through the Problems tab The two ERROR introduced in TS3.11 and the WARNING introduced in TS3.11 are no longer visible to the user. One new WARNING is now visible to the user. The WARNING problem introduced in step TS3.13 is no longer visible in the Problems tab 1 new warning 1 total warnings 0 total errors 1 warning gone 0 total warnings 0 total errors 2 new errors 1 new warning 2 total errors 1 total warnings 2 errors gone 1 warning gone 1 new warning 1 total warnings 0 total errors 1 warning gone 0 total warnings 0 total errors Test Suite 4 SR6 & Organization Active Preference Settings Test # Description Expected Outcome Actual Outcome TS4.1 The user will change the agenttool III preferences to run only Organization Diagram Rules TS4.2 The user will create one Organization Diagram name OrgDiagram.org TS4.3 The user will create one Activity Diagram named ActivityDiagram.activity TS4.4 The user will create one Goal Diagram named GoalDiagram.goal 78

82 TS4.5 TS4.6 TS4.7 TS4.8 TS4.9 TS4.10 TS4.11 TS4.12 TS4.13 The user will place one goal component onto OrgDiagram.org The user will rename the goal created in TS4.5 to Goal1 The user will place one goal component onto GoalDiagram.goal The user will rename the goal created in TS4.7 to Goal1 The user will place one organization component onto OrgDiagram.org The user will rename the organization created in TS4.9 to Org1 The user will place one service component onto OrgDiagram.role The user will rename the service created in TS4.11 to ActivityDiagram The user will place one organization component onto OrgDiagram.org Two new ERROR problems are visible to the user through the Problems tab One ERROR problem introduced in step TS4.5 is no longer visible in the Problems tab Two new WARNING problems are visible to the user through the Problems tab One WARNING problem introduced in step TS4.11 is no longer visible in the Problems tab One new ERROR problem is visible to the user through the Problems tab TS4.14 The user will rename the organization created in TS4.13 to Org2 TS4.15 The user will delete Org2 One ERROR problem introduced in step TS4.13 is no longer visible in the Problems tab. TS4.16 TS4.17 TS4.18 TS4.19 The user will place one actor component onto OrgDiagram.org The user will rename the actor created in TS4.16 to Actor1 The user will place an achieves relationship between Goal1 and Org1 in OrgDiagram.org The user will place one provides relationship between ActivityDiagram (Service) and Org1 in OrgDiagram.org One new ERROR problem is visible to the user through the Problems tab ERROR problem introduced in step TS4.5 is no longer visible in the Problems tab One WARNING problem introduced in step TS4.11 is no longer visible in the Problems tab 2 new errors 2 total errors 0 total warnings 1 error gone 1 total errors 0 total warnings 2 new warnings 1 total errors 2 total warnings 1 warning gone 1 total errors 1 total warnings 1 new warnings 1 total errors 2 total warnings 1 error gone 1 total errors 1 total warnings 1 new warnings 2 total errors 1 total warnings 1 error gone 1 total errors 1 total warnings 1 warning gone 1 total errors 0 total warnings 79

83 TS4.20 The user will place one protocol relationship between Actor1 and Org1 One ERROR problem introduced in step TS4.16 is no longer visible in the Problems tab 1 error removed 0 total errors 0 total warnings Test Suite 5 SR7 & Role Active Preference Settings Test # Description Expected Outcome Actual Outcome TS5.1 The user will change the agenttool III preferences to run only Role Diagram Rules TS5.2 The user will create one Role Diagram named RoleDiagram.role TS5.3 The user will create one Agent Diagram named AgentDiagram.agent TS5.4 The user will create one Goal Diagram named GoalDiagram.goal TS5.5 The user will create one Activity Diagram named ActivityDiagram.activity TS5.6 The user will place one role component onto RoleDiagram.role TS5.7 TS5.8 TS5.9 TS5.10 TS5.11 TS5.12 TS5.13 TS5.14 TS5.15 TS5.16 TS5.17 The user will rename the role created in TS5.6 to Role1 The user will place one role component onto RoleDiagram.role The user will rename the role created in TS5.8 to Role2 The user will place one agent component onto AgentDiagram.agent The user will rename the agent component created in TS5.10 to Agent1 The user will place one goal component onto RoleDiagram.role The user will rename the goal created in TS5.12 to Goal1 The user will place one goal component onto GoalDiagram.goal The user will rename the goal created in TS5.14 to Goal1 The user will place one actor component onto RoleDiagram.role The user will rename the actor created in TS5.16 to Actor1 Three new WARNING problems are visible to the user through the Problems tab Three new WARNING problems are visible to the user through the Problems tab One new ERROR problem and one new WARNING are visible to the user through the Problems tab One new ERROR problem is visible to the user through the Problems tab and the ERROR introduced in TS5.12 is no longer visible to the user 3 new warnings 0 total errors 3 total warnings 3 new warnings 0 total errors 6 total warnings 1 new error 1 new warnings 1 total errors 7 total warnings 1 new error 1 error gone 1 total errors 7 total warnings 80

84 TS5.18 TS5.19 TS5.20 TS5.21 TS5.22 TS5.23 TS5.24 TS5.21 TS5.22 TS5.23 TS5.24 TS5.25 The user will place one service component onto RoleDiagram.role The user will rename the service created in TS5.18 to ActivityDiagram The user will place one protocol relationship between Role1 and Role2 in RoleDiagram.role The user will place one role component onto AgentDiagram.agent The user will rename the role created in TS5.21 to Role1 The user will place one role component onto AgentDiagram.agent The user will rename the role created in TS5.213 to Role2 The user will place one plays relationship between Role1 and Agent1 in AgentDiagram.agent The user will place one plays relationship between Role2 and Agent1 in AgentDiagram.agent The user will place one protocol relationship between Actor1 and Role1 in RoleDiagram.role The user will place one achieves relationship between Goal1 and Role1 in RoleDiagram.role The user will place one achieves relationship between Goal1 and Role2 in RoleDiagram.role One new WARNING problem is visible to the user through the Problems tab The WARNING problem introduced in step TS5.18 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.6 and one WARNING problem introduced in step TS5.8 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.6 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.8 is no longer visible in the Problems tab One ERROR problem introduced in step TS5.16 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.6 is no longer visible in the Problems tab and one WARNING problem introduced in step TS5.12 is no longer visible in the Problems tab One WARNING problem introduced in step TS5.8 is no longer visible in the Problems tab 1 new warnings 1 total errors 8 total warnings 1 warnings gone 1 total errors 7 total warnings 2 warnings gone 1 total errors 5 total warnings 1 warning gone 1 total errors 4 total warnings 1 warning gone 1 total errors 3 total warnings 1 error gone 0total errors 3 total warnings 2 warnings gone 0 total errors 1 total warnings 1 warning gone 0 total warnings 0 total errors 81

85 Test Suite 6 SR8 & Sequence Active Preference Settings Test # Description Expected Outcome Actual Outcome TS6.1 The user will change the agenttool III preferences to run only Sequence Diagram Rules TS6.2 The user will create one Sequence Diagram named SequenceDiagram.sequence TS6.3 TS6.4 TS6.5 TS6.6 TS6.7 TS6.8 TS6.9 TS6.10 TS6.11 TS6.12 The user will create one Role Diagram named RoleDiagram.role The user will place one classrole component onto SequenceDiagram.sequence The user will rename the classrole component created in TS6.4 to Role1 The user will place one classrole component onto SequenceDiagram.sequence The user will rename the classrole component created in TS6.6 to Role2 The user will place one role component onto RoleDiagram.role The user will rename the role component created in TS6.8 to Role1 The user will place one role component onto RoleDiagram.role The user will rename the role component created in TS6.10 to Role2 The user will place a protocol relationship between Role1 and Role2 in RoleDiagram.role One new ERROR problem is visible to the user through the Problems tab One new ERROR problem is visible to the user through the Problems tab One new ERROR problem and one new WARNING problem are visible to the user through the Problems tab and one ERROR problem introduced in step TS6.2 is no longer visible in the Problems tab One ERROR problem introduced in step TS6.6 is no longer visible in the Problems tab One ERROR problem introduced in step TS6.6 is no longer visible in the Problems tab One WARNING problem introduced in step TS6.6 is no longer visible in the Problems tab 1 new error 0 total warnings 1 total errors 1 new error 0 total warnings 2 total errors 1 error gone 1 new error 1 new warning 2 total errors 1 total warnings 1 error gone 1 total errors 1 total warnings 1 error gone 0 total errors 1 total warnings 1 warning gone 0 total errors 0 total warnings Test Suite 7 Activation/Deactivation of at3 Validation Test # Description Expected Outcome Actual Outcome TS7.1 The user will change the agenttool III project preferences to deactivate at3 Validation TS7.2 The user will create one Agent Diagram named AgentDiagram.agent TS7.3 The user will place one agent component onto AgentDiagram.agent 82

86 TS7.4 TS7.5 The user will change the agenttool III project preferences to activate at3 Validation The user will change the agenttool III project preferences to deactivate at3 Validation One new WARNING problem is visible to the user through the Problems tab and one new ERROR problem is visible to the user through the Problems tab Both the WARNING and ERROR introduced in step TS7.4 are no longer visible in the Problems tab 1 new error 1 new warning 1 total errors 1 total warnings 1 error gone 1 warning gone 0 total errors 0 total warnings 8.4. Problems Encountered Outlined in the following sections are the problems encountered during testing. The action is the problem encountered while reasoning is a description of why the problem was encountered and a resolution Test Suite Activity Diagram Test Suite Action Added TS1.13 to Test Plan 1.0 Added TS1.14 to Test Plan 1.0 Added TS1.16 to Test Plan 1.0 Added TS1.18 to Test Plan 1.0 Added TS1.20 to Test Plan 1.0 Removed TS1.17 in Test Plan 1.0 Revised TS Test Suite 10.2 Agent Diagram Test Suite Action TS2.17 inaccurate TS2.21 inaccurate Fixed but in agent converter Fixed bug concerning SR4.1 Change Sr4.10, SR4.11 to error type from warning TS2.17 and TS2.18 Changed Expected Result of TS2.22 TS2.21 and TS2.22 TS2.24 Error gone TS2.25 removes 1 error and 1 warning TS2.26 ER was inaccurate TS2.28 ER was inaccurate Reasoning to rename incoming event to create new class roles for proper execution to rename message to rename outgoing event to rename message Renaming swim lanes is not allowed Expected action was incorrect Reasoning Role defaults to name Role1, eliminating TS2.18, is okay Actor defaults to name Actor1, eliminating TS2.18, is okay Org protocol wasn t added properly Didn t check if roles require any Capabilities Wrong problem types in extensions Role defaults to Role1, removing test case TS2.18 and changed expected result of TS2.17 to expected result of TS2.18 Test log contain inaccurate ER of adding an actor present in agent diagram into role diagram Actor defaults to Actor1, removing test case TS2.22 and changed expected result of TS2.21 to expected result of TS2.22 Adding a plays relationship should remove the TS2.5 error The cap is now possessed and the agent is now possessing all required cap of the role it plays This action removes now problems and introduces one new warning and one new error. This is the actual functionality. Adding the protocol relationship remove 1 warning from each agent and 83

87 Added new cases TS2.29 and TS2.30 Removed TS2.37 Removed TS2.38 Fixed but in SR Test Suite 10.3 Goal Diagram Test Suite Action TS3.11 ER result inaccurate Added cases for renaming goals Test Suite 10.4 Org Diagram Test Suite Action Add actor protocol to org converter Edited SR Test Suite 10.5 Role Diagram Test Suite Action Error in TS5.12 Changed Added TS2.21 TS Test Suite 10.6 Role Diagram Test Suite Action SR8.2 changed TS6.6 inaccurate TS6.8 and TS6.9 TS6.10 and TS6.11 Need to add plays between agent and role in agent diagram Action completed earlier in test Action completed earlier in test Protocol to work both ways Reasoning When a goal model contains two goals, we get one error for each goal not in tree form and that the new goal is not played by a role in a role diagram Goal model naming is tricky, so we needed to added cases to get the names right Reasoning Left out actor s protocols in organization diagram converter Included Actor to Actor protocols Reasoning ER is actually an ERROR and WARNING is expected. Needed to add roles to agent diagram Reasoning Changed markers reported to user to follow test guidelines We now have a warning that there is no protocol present between the class roles in a role diagram Role defaults to Role1, removing test case TS6.9 and changed expected result of TS6.8 to expected result of TS6.9 Role defaults to Role1, removing test case TS6.11 and changed expected result of TS6.10 to expected result of TS Test Suite 10.7 Activate/Deactivate at3 Validation No problems TPTP v Eclipse s TPTP plug-in suite was considered as a testing tool while testing at3 Validation, however due to the tester s judgment, efforts were seized and manual testing was performed. The tester found that the Automated GUI Recorder version located within the TPTP suite was not accurate in recording user actions. The amount of time given in the attempt to incorporate this tool into testing was too great. Although the TPTP testing suite was abandoned at this time, the idea does have some advantages. If testing was completed using this tool, then subsequent testing of at3 Validation could be less time consuming. I do recommend that if this testing tool is considered again in the future that a more stable version of TPTP used. One large flaw that 84

88 contributed to TPTP s abandonment in this project was it s inability to record actions performed on GEF framework components. It was thought that we could use point recognition within the GUI recorder but this too was troublesome. The point recorder did not always record the same location as the tester thought was to be recorded. For future reference, the TPTP s GUI Recorder can be found by going to and select the link <downloads>. This page contains a tutorial for the GUI Recorder and the required plug-ins Overall Results The plug-in was thoroughly tested and passed all test cases found in Test Plan 2.0. The plug-in is now ready for the final MSE Presentation. 85

89 Chapter 9 User s Manual 9.1. Introduction This User s Manual is intended to be used with the at3 Validation Eclipse plug-in. It outlines how to use at3 Validation within your at3 Diagrams. The second portion of this manual describes the process of adding new rules to at3 Validation. We have also included a tutorial to add a new rule. This is found in Appendix A. The following is a list of prerequisites to use at3 Validation within at3 Diagrams. 1. Eclipse 3.1 found at 2. GEF 3.1 found at 3. Java 1.5 found at 4. at3validation 1.0 available by request 5. at3diagram plug-ins available by request (6 plug-ins) Download all the appropriate versions for you machine. For the GEF plug-in, you may choose to download the package that does or doesn t include the examples. To install Eclipse, download the build and unpack the file to an appropriate file on your computer. Within the unpacked Eclipse folder is a folder called plug-ins. Unpack the GEF 3.1, at3validation 1.0, and the six at3diagram plug-ins into plug-ins folder. Start Eclipse by selecting eclipse.exe in the root Eclipse directory. Java 1.5 is required only to add rules to the validation library. For instructions on how to use the at3 Diagram plug-ins, please see the corresponding user manuals for each project How to Use at3 Validation The at3 Validation plug-in for Eclipse gives at3 users a way to maintain consistency between their at3 diagrams. A user is given many options on just how they would like to validate their diagrams. All at3 diagrams are validated against other diagrams present in their current at3 project, depending on the rules governing the type of diagram. For instructions on how to use at3 diagrams, please see the at3 Static and Dynamic User Manuals. at3 Validation comes with a variety of options to use during validation. These include whether or not to validate a project, whether or not to check error problems within diagrams, and whether or not to check warning problems within diagrams. The at3 diagrams are validated using a set of rules that have been defined by Dr. DeLoach and his OMASE Methodology. Each of the rules provides valid and invalid actions in at3 diagrams. An example of an invalid action in the Organizational Model is that each Organizational Model must contain one, and only one Organization component. If at3 Validation is turn on then we are given an error if we have an Organizational Diagram that goes against this rule. We are given an error because the rule defines that an invalid action against this rule denotes an error. We have a wide variety of errors and warnings. Eclipse uses Problem Markers to report, well Problems, to its users. We must note that validation is only performed on the current diagrams saved to the file system. This means that you must save your changed diagrams before they will be validated. In future releases we hope to change this to be more real-time and performing validation when changes are made to the diagram instantaneously. You can see this through invalid Java code in a Java project in Eclipse. If there is a syntax error in your Java code, the Problem is report to the user through the problems view. at3 Validation is no different. We use this functionality to report Problems back to the user when an invalid action is present within a diagram. The at3 Problem Marker contains a description of the problem, which diagram the problem exist in, and the type of problem, whether it be an error or a warning. It also contains the project that the invalid diagram belongs to. Now that we have a good idea what at3 Validation does, we can delve into how to use it. When we create a new at3 Diagram project, which is for now a new Java Project, the at3 Engine is registered with that project. We can start 86

90 creating our diagrams within this project and if any of the diagrams contain components that go against our library of rules, we receive problems, viewable in the Problems View. An example of how to get a Problem Marker is to create a new Activity Diagram. This will create an error problem because one of our governing rules is that all Activity Diagrams must be represented in an Agent Diagram as a Service component. In the following sections we will cover what features accompany our validation engine Workspace vs. Project Specific Preferences Within at3 Validation we are given the liberty to chose either global or project specific properties with certain preferences. We can decide if we want to follow the global settings for each project or whether we want a specific project to follow its own set of preferences. We will first discuss the preferences that pertain solely to the global workspace. In order to open a projects preference page through a resource we must first highlight the resource. With at3 Validation, the resource must be a diagram file. We filter all other out by checking the files extension and see if it is a correct file type for validation. Right-click the at3 diagram and select Properties at the bottom. This opens a preference page for us. We see at3 Primary Preferences Page in the right panel of the window. Highlight it. We now see this: We have the choice to set the preferences according to either the global workspace settings or to use project Specific Settings. If we elect to configure the workspace settings, we only are allowed to edit the three main preferences Activate Validation, Check Warnings, and Check Errors. This is because, as we discussed earlier, the other preferences are only editable by choosing the preferences through the Window Preferences path. If we select the 87

91 Use Project Settings button, the Use Workspace Setting button is now disabled. We discuss the purpose of each of these options later in section 9.5., Project Specific and Global Workspace Preferences 9.4. Workspace Preferences Only Workspace or global preferences are accessible through the Eclipse preference store. We can modify these settings by selecting Window Preferences in the Eclipse tool bar. Doing so gives us a window similar to the one below. As you can see we have a section called at3 Primary Preference Page. This contains subheading to set more specific preferences. We will discuss these subheadings first, making our way back to the primary preference page later. All of the sub preference pages have the same functionality so we will only discuss the first one, Activity Diagram Rules. The following figure shows this preference page. 88

92 As you can see, we currently have five rules primarily associated with the activity diagram. Deselecting any of these settings will turn off any reporting of this problem to the user. For example, if we don t care to see an error when an Activity Diagram is not present as a Service in an Agent Diagram within the same project, we would deselect the box next to this rule. Doing this deactivates that rule and when a diagram that contains this problem is found, it is not report to the user. These preferences are only valid in the global settings and not available as project specific settings. This means that if we chose to use the validation engine this way, we must use the global settings on our project Project Specific and Global Workspace Preferences Here we have Activate Validation, Check Warnings and Check Errors. If we have an option activated on a project but the workspace settings are deactivated, we will still perform the selected actions on the project because the project specific preferences tell us to. When checked, these options are active, meaning that if checked we will perform validation, including all warnings and errors on all projects set to the global preferences. If we uncheck Activate Validation, then all projects that are set to the global preferences will not be validated and the user will not be notified of any invalid diagrams. If we uncheck Check Warnings, then all projects that are set to the global preferences will not report warnings back to the user but all errors will be reported, so long that validation and Check Errors are active. The same goes for errors as with warnings. Deselecting Check Warnings and Check Errors has the same end result as deselecting Activate Validation, although it is advisable to deselect Activate Validation if this is wanted. 89

93 Activating/Deactivating Validation As stated above, we can choose which of our projects we wish to perform validation on. This means that if we have two at3 projects in our workspace then we chose to active validation on either project or both or neither. This value is set as a project preference. We have the choice to include a project in our global preferences. If we choose to deactivate validation within the project specific settings, that project will not be validated. If a project is set to follow the workspace settings, then it will either be active or inactive based on the global setting Checking Warnings/ Checking Errors The Check Warnings/ Check Errors option is available so that we may be able to validate our diagrams, ignoring or including certain type of problems. If we would want to ignore warnings on our project, then we simply deselect this option in our preference page. We can mix and match preferences for each project and doing so has no effect over the next, so long as the project is not set to follow workspace settings How to Create New at3 Validation Rules To make adding a new rule easy on users, we now created a diagramrule extension. Most features in Eclipse are available through extensions. This extension allows the user to provide essential information about the new rule, which is gathered through either a wizard page, which in itself is an extension point (Method 1) or through direct, manual creation (Method 2) and contribute the basic logic behind the rule. Once this is done, the rule will be apart of validation package. In the following sections we describe just how to add new rules to the at3 Validation plug-in. To create new rules we have two options. The first is referred to as Method 1 Wizard Usage and the other is Method 2 Manual Creation. Both of these require that once complete, the user sets the appropriate preferences. This is outlined in the section Setting Preference Store Values Method 1 Wizard Usage In this section we will walk through how to create a new at3 Validation rule using the extension s wizard page. Prerequisites The user must have access to the at3 Validation plug-in source code. The user must have the at3 Validation plug-in.jar file placed in the plug-ins folder in the Eclipse HOME directory. The user must have at3 Validation project open in the workspace. Once the user has satisfied all of the prerequisites, we must expand at3 Validation plug-in project. Located in the project is the plugin.xml file. Select plugin.xml and open it in the editor view. 90

94 Select the Add button next to the All Extensions box. This will bring up a list of all available extensions. 91

95 Select the Extension Wizards tab at the top of this page and then highlight at3, as shown. 92

96 The New at3 Validation Rule is now visible in the right frame. Select this and press Finish. Insert the name of your new rule in the next page and select Next. 93

97 It is recommended to follow the naming scheme XX.YY where XX is an identifier and YY is a short, one word descriptor. They are separated with a (.). You are not required to follow this format. Select whether the rule is of type error or type warning. 94

98 Select Next and select the primary diagram type. This is the diagram that the rule is associated with. 95

99 Select Next and check the boxes that correspond to the other diagram types this rule is associated with. 96

100 Select Finish. If you do not complete all pages of the wizard, you can go back and follow the steps in Method 2 of rule creation to file in the missing details. Once you click Finish, your new rule extension is placed under the at3validation.diagramrule extensions in the plugin.xml page. The figure below shows this. 97

101 Verify that the properties on the right are correct. Notice that your new rule s class is pointing to a new class located in the rules folder. The location of the rule in rule s folder depends on your type of primary diagram. In this case it is located in the at3validation.rules.agent package. This is the fully qualified location of the class that will implement your rule but in order to create the class you need to select the class*. link next to the location. Doing this brings up a new wizard that will create your class. 98

102 Notice that the Superclass is at3validation.rules.arule. This is need by all rules for validation. Everything should be correct so select Finish. Your new class will be opened for editing in Eclipse. There are four methods that Eclipse places in our definition because we extended ARule, which implements IRule. Outlined below is a description of each method. 99

103 Constructor run() getactivestate() getproblemstate() Method Description Default and nothing needs to be changed. Here is what needs to be done to validate the rule Returns whether or not our rule is actively set to be ran during validation. This is based on a property with our preference store. Returns whether or not we are validating the type of problem associated with this rule To see an example of how to implement these methods, view another rule provided with the plug-in, say SR4.1. We have now created a new rule. We now need to set up the preferences, outlined in the section 9.7, Setting Preference Store Values. To implement the rule, see the section implementing the run Method is Rules Manual Creation In this section, we will walk through how to create a new at3 Validation rule using the extension point schema. Prerequisites The user must have access to the at3 Validation plug-in source code. The user must have at3 Validation project open in the workspace Creating New Extension Point Once the user has satisfied all of the prerequisites, we must expand at3 Validation plug-in project. Located in the project is the plugin.xml file. Select plugin.xml and open it in the editor view. 100

104 Located along the bottom of the editor view is a set of tabs. Select the Extensions tab to open it in the editor view. Once this is done, expand the at3validation.diagramrule tree in the All Extensions section. All of the extension points based on the diagramrule extension are the current rules within at3validation. Right click on at3validation.diagramrule and select New->Rule. 101

105 A new extension rule is added to the end of our rules. We now have some properties for this extension point that we need to set. These properties are visible in the Extension Details section of the plugin.xml editor. 102

106 Below is a table describing the properties for an at3 Validation Diagram Rule. Property name class problemtype primarydiagram SequenceDiagramDependent rolediagramdependent orgdiagramdependent goaldiagramdependent agentdiagramdependent activitydiagramdependent Description The name of the rule The fully qualified class location the rule implements The type of problem created within Eclipse (Error, warning) The primary diagram type associated with this rule Does it involve the sequence diagrams? Does it involve the role diagrams? Does it involve the organizational diagrams? Does it involve the goal diagrams? Does it involve the agent diagrams? Does it involve the activity diagrams? The name of the rule must be the same that will be stored in Eclipse s preference store. The class is the implementing class used to perform the logic of rule validation. The problemtype gives us the Problems category that the rule will violate. This is either an error or a warning. The primary diagram is the type of at3 Diagram that corresponds to the type of at3 Diagram associated with this rule. Every rule has one type of diagram that when the diagram has changed, the rule must be run on those types of diagrams. The diagramdependent properties are those at3 Diagrams that are check for consistency with the primary diagram. All or none of these may be true or false. For example if I have a rule that states All roles in an Agent Diagram must also be in a Role Diagram. This is reported as an error., then the primary diagram would be the Agent Diagram and the rule is also dependent on Role Diagrams. The rest of the diagramdependent values are false. The problemtype would be an error. When implementing a class, change the name property of the extension point to the appropriate name. An example name would be SR.TEST. For consistency, we need to name our class after the name of our rule. So, the fully qualified class for the new rule would be at3validation.rules.agent.sr_test. Notice that we replaced the (.) with an (_). This is the only difference. Now, to create the class, select the class*. link next to the class property. This brings up a wizard to create a new class definition that extends ARule. 103

107 Use the default values and select Finish. This then opens up a new rule definition class for us to complete our rule s logic that is performed during validation. The required 104

108 There are two methods that Eclipse places in our definition because we extended ARule, which implements IRule. Section 9.8, Implementing the run() Method in Rules, gives instructions on how to implement the run() function Setting Preference Store Values Once the basic structure of the rule is completed using either Method 1 or Method 2, the user must create and set the values within the preference store. To do this open the class PreferenceConstants.java located in at3validation.preferences. This is where we create a value for our new rule in Eclipse s Preference Store. Using the name given to you new rule, find the primary diagrams section in the class and add the line public static final String <VARIABLENAME> = "name"; where VARIABLENAME is the name consistent to your rules name and name is the same value. Notice again that we replace any (.) with (_). 105

109 Next we need to provide a default value for this preference value. Open PreferenceInitializer.java located in the same package as before. Locate the appropriate place to place the initialization code and insert this line store.setdefault(preferenceconstants.<variablename>,<value>); where VARIABLENAME is the same variable name given in PreferenceConstants.java. the value a Boolean value either true or false. Typically the user would want to insert true as the value. 106

110 We now need to add the rule to its corresponding preference page. To do this open the at3validation.preferences.diagram.specific package and open the corresponding class file to your new rule. For example, if the rule s primary diagram was the Agent Diagram, you would open at3validation.preferences.diagram.specific.at3validationagentdiagramrulespreferencepage. 107

111 First we need to create a private variable for our rule. Copy/paste one of the private variables to the bottom of the variable declarations. Change the pasted statements variable name to the name of your rule Next we need to create a description for our new rule. Create a new description variable. Just copy/paste a previous description variable to the end of our DESCRIPTIONS section. 108

112 Now, go down to the CreateFieldEditors() method and copy and paste the first statement. Be sure to stay organized in doing so. Change the variable name to the one you place at the beginning of your code. Also change the PreferenceConstant and description variable appropriately. The Preference constant is the value you create in the PreferenceConstant class that distinguishes this rule. Next copy and paste an addfield( statement, changing the parameter to the variable you just created. 109

113 Now go down to the performok() method. Here you need to copy and paste one statement, changing the preferences accordingly and again, ensure organization. Save your work and that s it. Now when we create at3 Diagrams, this rule is included during validation and is set to a value in the preference store. 110

114 Next we will discuss how to implement the run(iresource res) method in at3 Validation Rules Implementing the run() Method is Rules To validate a rule with at3 Validation, our object class needs to extend ARule, which implements IRule. ARule provides us with some much needed functionality to aid in our quest while using the IRule interface enforces us to include the extra functions need to write our rules. The table below contains the functions available to us through ARule. Function ARule() setname(string) getname() getactivestate(iproject) setproblemstate(string) getproblemstate(iproject) getproblemsetting() getproblemstateint() getpageid() UpdateMarkers(IResource, boolean, String, int) oktomark(iresource) DetermineDiagramType(String) RetreiveFromCache(IResource, Integer) GetOtherDiagram(IResource, Integer) runassecondary(iresource, Integer) Description A default constructor. Has no functionality. Set the name of rule to the given name. Returns the name of the rule Tells us if this rule is active. Sets the state to either warning or error Gives us whether rules problem state is active on the given project. Helper method to get the problem state setting Gives us a value for our Problem state consistent with IMarker.SEVERITY A unique identifier used to determine if the current project uses project specific settings. Updates Problem markers on IResource. If Boolean is false, it deletes all markers on IResource without replacing them. String is the message sent back to the user while int is the type of Problem marker, either a warning or error. Checks to make sure that according to the user s preferences, it is okay to place a marker. Uses the given String(a resources file extension) to determine which type of at3 Diagram a resource is. Retrieves a resource of type Integer from our cache. If the resource is not present, it places the resource in to the cache. Gives us all the resources of type Integer present in the project that IResource is located in. Runs all rules associated with diagrams of type Integer that is located in the same project as IResource. IRule forces us to implement the function run(iresource). This controls how to validate a rule on a diagram. Now for the interesting function, run(iresource). Below is an example run(iresource) function. We will reference this throughout this section. IResource is the file that we are validating. To validate a diagram we first need to get the.xml file from our cache. To do this we use the function RetreiveFromCache, inherited from ARule. This function will convert the.xml file into a usable at3 Diagram object. We pass our IResource to this function along with the type of diagram IResource is. We use the static types in DiagramType as the types. These are just unique identifiers used to distinguish the different at3 Diagram. We must be sure that the object type of object returned from RetreiveFromCache is the same object type of the diagram we are validating. In our example we see that the object type is of AgentSchema. We must now check that we have actually retrieved a value from the cache. This is done by comparing our object to null. You must do this when implementing your rule. Now that we have a valid at3 Diagram object, we search this to validate our diagram. In our example we are checking that in each Agent Diagram a protocol exist to at least one other agent or organization from each agent in agent diagram. We first get all the agents in the Agent Diagram and then check that a protocol relationship exists with the agent to either another agent or organization. After this we need to call UpdateMarkers. This will place 111

115 any Problem Markers on our file if the diagram is invalid. The UpdateMarkers() function takes three parameters, the resource the marker is place on, whether the rule was validated, and a description of the problem. If the rule is valid for the current component then all markers with the same description on the resource are removed. If the rule is invalid, a marker with the given description and type are placed on the resource. In this example we place a marker on the resource for every agent that is invalid within the Agent Diagram. Other examples are found in the at3validation.rules package of the plug-in public void run(iresource res) { boolean found; AgentSchema agentdiagram = (AgentSchema)RetreiveFromCache(res, DiagramType.AgentDiagram); if ( agentdiagram!= null ) { List allagents = agentdiagram.getagents(); for ( int i = 0; i < allagents.size(); ++i ) { found = true; Agent a = (Agent)allAgents.get(i); if ( a.getprotocolsrcrelationships().isempty() && a.getprotocoldestrelationships().isempty() ) { found = false; } UpdateMarkers(res, found, a.getname()+ " is not connected to at least one AGENT or " + "ORGANIZATION by the PROTOCOL relationship."); } } } As a recap, there a few things all rules must do. 1. They must retrieve the diagram from the cache first and compare to null to ensure a diagram is given. 2. They must update markers, even if no problems are found. This is needed to remove any previous problems of the same type associated with the diagram. Please see the at3 Diagram Plug-ins API s for a description of valid operation to retrieve components of each diagram object. You should now be able to write your own at3 Validation rules and use them during validation of at3 Diagrams. See appendix A for a tutorial to add an example rule. 112

116 Chapter 10 Project Evaluation Introduction This document presents a summary of my experiences while working on the At3Validation project. It includes a summary of problems encountered, the time log evaluation, source code evaluation, lessons learned as a result of the project, and any future work to be done on the project Problems Encountered Existing at3 Eclipse Plug-ins Since this project was an extension to the existing at3 plug-ins, it also inherited a few problems. These consisted of discrepancies in the way at3 object were written to.xml files and when the diagrams were actually written. at3 diagrams were able to be written to disk in.xml format but they were not written when a diagram was first created. This was corrected during this project. The at3 projects also contained errors in.xml corresponding to the appropriate data present in a correct at3 diagram s.xml file. This too was corrected TPTP v Eclipse s TPTP project was initially thought to be used during the testing phase of this project. After much effort, this tool s use was abandoned. More detail into this subject can be found in the Testing Evaluation associated with the at3 Validation project Source Lines of Code The initial estimate for the size of this project in terms of lines of code was 2KLOC. This estimate off the mark, but we live and we learn. The actual size, counting blank lines and comments was KLOC. Below is a graph that outlines the break down of the lines of code. The individual break down of each component can be found in appendix B. SLOC Totals Source: Comment: Both: Blank: Total: After looking at this graph, I would consider the actual size of the project to be about 5KLOC. One notable reason for such a large gap between the estimated and actual size is the use of Eclipse Extension within this project. The extensions produce a lot of code that the developer just had to modify slightly. 113

117 10.4. Project Duration Phase Estimated End Date Actual End Date One November 8, 2005 November 8, 2005 Two February 7, 2006 February 7, 2005 Three April 26, 2006 April 18, 2006 This project has been completed to schedule and with in the estimate of 8 months worth of work. It is actually a coincidence that the exact dates coincide. Below is the total time spent on each phase of the project. Time Spent Per Phase Phase Three, 58.92, 28% Phase One, 80.27, 39% Phase One Phase Two Phase Three Phase Two, 68.55, 33% Here we can see that phase one actually took the longest. I believe this is due to the new technology that the project worker needed to learn. Below is the amount of time spent per activity throughout the project lifetime. 114

118 Total Time Spent Per Task Environment 2% Coding 46% Documentation 40% Environment Documentation Meeting Reading Webpage Coding Webpage 1% Reading 5% Meeting 6% Here we can see that a majority of the time was spent working on documentation and coding. This is expected. It is also notable that the time spent on these to activities is almost the same. Below is a breakdown of the time spent on each activity during each phase. It shows that during each phase, the time spent on each activity is proportional. Environment Documentation Meeting Reading Webpage Coding Total (hrs) Phase One Phase Two Phase Three Totals Again, following three charts show the amount of time spent on activities in each phase, this time in a graphical manor. 115

119 Time Totals Environment 4% Coding 39% Webpage Reading 1% 6% Meeting 6% Documentation 44% Environment Documentation Meeting Reading Webpage Coding Figure 17: Phase 1 Time Totals Coding 58% Documentation 31% Meeting 6% Reading 4% Webpage 1% Documentation Meeting Reading Webpage Coding Figure 18: Phase 2 116

120 Phase Three Totals Coding 41% Documentation 47% Documentation Meeting Reading Webpage Coding Webpage 3% Reading 5% Meeting 4% Figure 19: Phase Lessons Learnt Incorporation of Eclipse s Extensions Eclipse contains many extra functions that it allows developers to build off of. These are called Extensions. Many of these are used with At3Validation. Using these Extensions introduced me to a new tool and just how developers can produce their own plug-ins Dynamic Class Loading Building off of the Extensions discussion above, I incorporated this into my project on a new level. I developed my own Extension that will allow future users to easily add new rule to the validation. Eclipse s use of these Extensions allows the tool to utilize dynamic class loading, which was an added bonus to the performance of this project Future Work Further work on this project is simply to add more rules to be used during validation, once these are determined and to allow validation to run in real-time rather than on a save command only. 117

121 References [1] Arthorne, John. How You ve Changed. Eclipse Corner Article. November 23, October 5, < [2] Bolour, Azad. Notes of Eclipse Plug-in Architecture. July 3, < [3] Clayberg, Eric. Rubel, Dan. Eclipse: Building Commercial-Quality Plugins. Addison-Wesley Professional, June 17, [4] Daum, Berthold. Mutatis mutandis Using Preference Pages as Property Pages. Eclipse Corner Article. October 24, March 21, < [5] DeLoach, Scott and Matson, Eric. A Capabilities Based Theory of Artificial Organizations. DRAFT. [6] DeLoach, Scott. Multiagent Systems Engineering of Organizational-based Multiagent Systems. [7] Gamma, Erich. Beck, Kent. Contributing to Eclipse: Principles, Patterns, and Plugins. Addison-Wesley Professional, October 31, [8] Glozic, D. Melhem, W. PDE Does Plug-ins. September 8, < [9] Gupta, Deepti. Vision Document 1.0. August 26, 2005 < [10] IEEE Guide for Software Quality Assurance Plans. IEEE Std 730, (Revision of IEEE Std ). [11] IEEE Standard for Software Quality Assurance Plans. IEEE Std (Revision of IEEE Std ). [12] Lurie, Jonathan. Develop a generic caching service to improve performance. Java World. July December 12, < [13] Sepaha, Binti. Vision Document 1.0. August 26, < [14] Wikipedia, the free dictionary. August 26, < 118

122 Appendix A New Rule Tutorial This is a tutorial that walks a user through creating a new rule called SR.NEW. Many snapshots in this tutorial are the same as the snapshots found earlier in this document. Select the Extension tab just below the editor page that just opened. Also, select the Add button next to the All Extensions box. This will bring up a list of all available extensions.

123 Select the Extension Wizards tab at the top of this page and then highlight at3, as shown. ii

124 The New at3 Validation Rule is now visible in the right frame. Select this and press Finish. Insert the name of your new rule in the next page and select Next. iii

125 We can rename our rule if needed but we will just leave the default SR.NEW. On the next page select the Error radio button. iv

126 Select Next and select the primary diagram type as an Agent Diagram. This is the diagram that the rule is associated with. v

127 Select Next and check the boxes that correspond to the other diagram types this rule is associated with. For us this will be the Role Diagram only. vi

128 Select Finish. Once you click Finish, your new rule extension is placed under the at3validation.diagramrule extensions in the plugin.xml page. The figure below shows this. vii

129 Verify that the properties on the right are correct. Notice that your new rule s class is pointing to a new class located in the rules folder. The location of the rule in rule s folder depends on your type of primary diagram. In this case it is located in the at3validation.rules.agent package. This is the fully qualified location of the class that will implement your rule but in order to create the class you need to select the class*. link next to the location. Doing this brings up a new wizard that will create your class. viii

130 Notice that the Superclass is at3validation.rules.arule. This is need by all rules for validation. Everything should be correct so select Finish. Your new class will be opened for editing in Eclipse. ix

131 Right now the only method we are concerned with is the run(iresource) function. Place the line of code below into this function. System.out.println( Our test rule is running. ); Save all of your work. Now we need to set the preference values. x

132 Setting Preference Store Values Once the basic structure of the rule is completed using either Method 1 or Method 2, the user must create and set the values within the preference store. To do this open the class PreferenceConstants.java located in at3validation.preferences. This is where we create a value for our new rule in Eclipse s Preference Store. Using the name given to you new rule (in our case SR_NEW), find the primary diagrams section in the class and add the line public static final String <VARIABLENAME> = "name"; where VARIABLENAME is the name consistent to your rules name and name is the same value. Notice again that we replace any (.) with (_). For us the line of code is Public static final String SR_NEW = SR.NEW ; Next we need to provide a default value for this preference value. Open PreferenceInitializer.java located in the same package as before. Locate the appropriate place to place the initialization code and insert this line store.setdefault(preferenceconstants.<variablename>,<value>); where VARIABLENAME is the same variable name given in PreferenceConstants.java. the value a Boolean value either true or false. Typically the user would want to insert true as the value. Again, for the inspection, the line of code is: store.setdefault(preferenceconstants.sr_new, true); xi

133 We now need to add the rule to its corresponding preference page. To do this open the at3validation.preferences.diagram.specific package and open the corresponding class file to your new rule. For example, if the rule s primary diagram was the Agent Diagram, you would open at3validation.preferences.diagram.specific.at3validationagentdiagramrulespreferencepage. First we need to create a private variable for our rule. Copy/paste one of the private variables to the bottom of the variable declarations. Change the pasted statements variable name to the name of your rule xii

134 Next we need to create a description for our new rule. Create a new description variable. Just copy/paste a previous description variable to the end of our DESCRIPTIONS section. Now, go down to the CreateFieldEditors() method and copy and paste the first statement. Be sure to stay organized in doing so. Change the variable name to the one you place at the beginning of your code. Also change the PreferenceConstant and description variable appropriately. The Preference constant is the value you create in the PreferenceConstant class that distinguishes this rule. xiii

135 Next copy and paste an addfield( statement, changing the parameter to the variable you just created. Now go down to the performok() method. Here you need to copy and paste one statement, changing the preferences accordingly and again, ensure organization. xiv

136 That s it. Now when we create at3 Diagrams, this rule is included during validation. We will now run the plug-in in a runtime workbench to verify that our new rule is running. Select Run on the menu bar and then select Run xv

137 Now highlight Eclipse Application and select New. This will create a new configuration for us. xvi

138 Our screen now looks like this. Select Run located on the bottom of the page. This will open up a new runtime workbench. Select File, New, Project on the menu bar. xvii

139 This brings up a new project wizard. xviii

140 Select Next with Java Project highlighted. Name our project Test and select Finish. Now right click our Test project and select New, Other xix

141 Expand agenttool 3 and select Agent Diagram Editor. Select Next. xx

142 After this select finish with all the default values. We just created a new Agent Diagram and it was check to make sure it was valid. We see this if we switch back to the first workbench and open the console view. xxi

143 Here we see that the System.out.println statement was executed, verifying that the rule was ran. To check that the rule also has the capability to be turned off, select Window, Preferences in the runtime workbench. This brings up the following page with at3 Preferences and Agent Diagram Rules selected. You can see that the SR NEW is available to be deselected. xxii