Project Overview - Peoplepeople.cis.ksu.edu/~ssaleh/MSEProject/MSEFinalDoc.doc · Web viewI would like to express my gratitude to the other committee members; Dr. David Gustafson

Master of Software EngineeringPortfolio

BySamer Ali Saleh

Kansas State University, 2005

A Portfolio

Submitted in partial fulfillment of the requirement for the degree

Master of Software Engineering

Department of Computing and Information SciencesCollege of Engineering

Kansas State University

Manhattan, KS2005

Major Professor Approval

Dr. William Hankley

Abstract

The sequence diagram generator is a plug-in developed for the Visual Paradigm Smart Development Environment tool. The purpose of the plug-in is to help the programmers, specially the novice ones to create a sequence diagram that is reliable and consistent with the class model. The goal is to make the creation of the sequence diagram more interactive process by allowing the user to select the different sequence diagram elements, such as. the caller object and the called messages from the classes and the operations in the class diagram. This will motivate the software engineers and programmers to think more about the design and keep the interaction between objects in sequence diagram consistent with associations in the class model, besides saving the programmers time and effort by not having to draw the sequence model manually.

2

Acknowledgement

I would like to thank the CIS Department at Kansas State University for giving me the opportunity to be in the MSE program. I also would like to express my gratitude and appreciation for the assistant ship that the CIS department and Dr. Hankley offered me during the last semesters, which without it; I wouldn’t be able to finish my degree.

I would like thank my Advisor Dr. Bill Hankley for his support & guidance through the last 2 years. He has been very helpful and supportive advisor and instructor, whom I recommend for all students.

I would like to express my gratitude to the other committee members; Dr. David Gustafson and Dr. Scott Deloach for their guidance and support in my MSE project and my study.

Finally, I would like to thank my family in Palestine and here in the US for all their mental and financial support, specially my brother Basel who did all the possible effort to bring me here and join the school.

3

Attached CD: The attacched CD at the end of the document contains the source code for the plug-in, and the Javadoc files that document all the class, attributes and operations of the plug-in compoenent. The Javadoc files are stored in html format, and you can start browsing the documenation starting from the index.html file at the root directory. For more information on how to include the plug-in into the Visual Paradigm Smart Development Environemnt, please refer to the user manual section of this documenation.

4

Table of Contents

Abstract................................................................................................................................2Acknowledgement...............................................................................................................3Project Overview...............................................................................................................81. Project Purpose................................................................................................................92. Goals................................................................................................................................93. Risks................................................................................................................................94. Constraints.......................................................................................................................9Technology Used..............................................................................................................10Quality Assurance Plan...................................................................................................111. Purpose..........................................................................................................................122. Reference Documents....................................................................................................123. Management..................................................................................................................12

3.1. Organization...........................................................................................................123.2. Responsibilities.......................................................................................................123.3. Tasks.......................................................................................................................13

4. Documentation...............................................................................................................135. Standards, Practices, Conventions, and Metrics...........................................................13

5.1 Documentation Standard.........................................................................................135.2 Coding Standard......................................................................................................135.3 Commentary Standards............................................................................................135.4 Documentation.........................................................................................................145.5 Metrics.....................................................................................................................14

6. Reviews and Audits......................................................................................................147. Test and Problem Reporting.........................................................................................148. Tools, Techniques, and Methodologies........................................................................149. Media Control...............................................................................................................1410. Records collection, maintenance and retention..........................................................1511. Deliverables...............................................................................................................15Software Requirement Spec............................................................................................151. Introduction....................................................................................................................152. Purpose..........................................................................................................................163. Scope..............................................................................................................................164. Definition, Acronyms and abbreviations.......................................................................165. References......................................................................................................................176. SRS Overview...............................................................................................................17

5

7. Overall Description........................................................................................................177.1 Product Perspective.................................................................................................17

7.1.1 System Interface...............................................................................................187.1.2 User Interface....................................................................................................18

7.2 Products Function....................................................................................................197.2.1 Start Generating sequence diagram..................................................................207.2.2 Enable / Disable Analyzer................................................................................217.2.3 Generate Sequence Diagram Elements.............................................................217.2.3.1 Select Caller...................................................................................................217.2.3.2 Select Callee..................................................................................................217.2.3.3 Select Callee from Actor...............................................................................217.2.4 Edit Generated Sequence Diagram...................................................................217.2.4.1 Undo Last Selection.......................................................................................227.2.4.2 Undo Last Sequence......................................................................................227.2.4.3 Redo Last Selection.......................................................................................227.2.4.4 Redo Last Sequence.......................................................................................227.2.5 Check for valid messages:................................................................................227.2.6 Draw Element...................................................................................................22

7.3 User Characteristics.................................................................................................237.4 Constraints...............................................................................................................237.5 Specific Requirements.............................................................................................23

7.5.1 External Interface..............................................................................................23Architecture Design.........................................................................................................261. Introduction....................................................................................................................262. Tools and References:....................................................................................................273. Architecture Design:......................................................................................................274. Static Structure:.............................................................................................................27

4.1 Package View....................................................................................................284.2 Class View.........................................................................................................29

4.2.1 Controller Domain Model..........................................................................364.2.2 Analyzer Domain Model...........................................................................46

2. Static Behavior...........................................................................................................512.1 Create New Sequence Diagram...............................................................................512.2 Create Sequence Diagram Caller.............................................................................522.3 Create Sequence Diagram Callee Message.............................................................532.4 Create Sequence Diagram Life Line Element.........................................................54

3. Dynamic Behavior.........................................................................................................553.1 Sequence Diagram Generator..............................................................................55

Project Plan......................................................................................................................561. Tasks Breakdown...........................................................................................................56

1.1 Inception Phase........................................................................................................561.2 Elaboration Phase....................................................................................................571.3. Production Phase....................................................................................................58

2. Overview........................................................................................................................603. Cost Estimation..............................................................................................................624. Gantt Chart.....................................................................................................................67

6

Software Specification Using OCL.................................................................................68Test Plan............................................................................................................................741 Test Plan Identifier.........................................................................................................742 Introduction.....................................................................................................................74

2.1 Objectives................................................................................................................742.2 Background..............................................................................................................742.3 Scope........................................................................................................................742.4 References................................................................................................................74

2.5 Definition & abbreviations..........................................................................................753 Test Items........................................................................................................................754 Approach.........................................................................................................................755 Features to be tested........................................................................................................766 Features not to be tested.................................................................................................767. Item Pass/Fail Criteria...................................................................................................768. Suspension Criteria and Resumption Requirements......................................................76

8.1. Suspension Criteria........................................................................................768.2. Resumption Requirement...........................................................................76

9. Test Deliverables...........................................................................................................769.1 Test Log...............................................................................................................76

Inspection Plan.................................................................................................................771. Introduction................................................................................................................772. Items to be inspected.....................................................................................................77

2.1. Class Diagrams.......................................................................................................772.2. Formal Specification...............................................................................................77

3. Formal Technical Inspectors..........................................................................................774. Formal Technical Inspection List..................................................................................78Assessment Evaluation......................................................................................................791. Introduction....................................................................................................................792. Testing Results:.............................................................................................................79

2.1 Sequence Diagram Creation Related Features (SRS 1.2.1).....................................792.2 Caller Selection Related Features (SRS 1.2.3.1):....................................................792.3 Callee Selection Related Features (SRS 1.2.3.2).....................................................802.4 SDG Editing Related Features (1.2.4).....................................................................832.5 Analyzer Related Features (SRS 1.2.5)...................................................................86

3. Failure Evaluation:.........................................................................................................884. Testing Summary...........................................................................................................89Project Evaluation...........................................................................................................901. Introduction....................................................................................................................902. Process Evaluation.....................................................................................................90

2.2 Expected Time vs. Actual Time..............................................................................902.2 Phases Break Down.................................................................................................912.3 Phase 1 Tasks Break Down.....................................................................................922.4 Phase 2 Tasks Break Down.....................................................................................932.5 Phase 3 Tasks Break Down.....................................................................................942.6 Estimated Development Time vs. Actual................................................................94

3. Delivered Product Evaluations..................................................................................95

7

3.1 Line of Code Evaluation..........................................................................................953.1.1 Top-Down LOC Estimate.................................................................................963.1.2 Bottom-Up LOC Estimate................................................................................963.1.3 Actual Line of Code vs. Estimate.....................................................................96

4. Project Challenges.........................................................................................................965. Lesson Learnt.................................................................................................................986. Future Work...................................................................................................................98User Manual.....................................................................................................................991. Introduction....................................................................................................................992. Software Installation & Plug-in Setup...........................................................................993. Software Requirements..................................................................................................994. Integrating the plug-in into the VP-SDE tool..............................................................1045. Using the Plug-in.....................................................................................................106

5.1 Generating sequence diagram without the analyzer tool.......................................1075.2 Generating sequence diagram using the analyzer tool..........................................1145.3 Editing the generated sequence diagram:..............................................................116

6. Plug-in Limitation....................................................................................................117References.......................................................................................................................118Appendixes.....................................................................................................................119

1. Appendix A..............................................................................................................119Analyzer Validation Rules.......................................................................................119

8

Project Overview

Sequence diagram generator is a plug-in for UML Visual Paradigm tool that help user to create UML sequence Diagram out of a given class diagram or domain model. There will be two main inputs for this tool, the first input will be providing a class diagram either by drawing it or loading from a file, and the second input will be a sequence of steps applied to the provided class diagram to generate the sequence diagram. The plug-in also will check for some constraints while drawing the sequence diagram to insure the validity of the messages in the sequence diagram. The constraints will be taken from a project that I did in the software engineering class – CIS540 – for a tool the check for the consistency between class and sequence diagram.

1. Project Purpose

1. Facilitate the process of drawing a sequence diagram by allowing the user to select classes and methods that represent objects and messages from class diagram.

2. Produce more reliable sequence diagrams by restricting the user to generate the sequence diagram through a given class diagram.

3. Insure consistency between class and sequence diagram by checking message validity through provided rules.

4. Provide a quality software engineering process and documentation that meets the software project management course – CIS748 – and IEEE standards.

2. Goals

1. Create a user friendly tool that assist user to draw a sequence diagram from a given class diagram.

2. Insure good quality and reliable generated sequence diagram.3. Satisfies the MSE Project Portfolio provided by the CIS department in Kansas

State University.4. Satisfies the software process and life cycle provided by the CIS748 – Software

Project Management Course –.5. Meeting IEEE standards for software documentation.

9

3. Risks

1. Difficulty of using the plug-in API to create an easy and user friendly tool to use, and that can lead to limitation and restriction for using the tool.

2. Founding Bugs in the some of the used API that may cause an expected results.3. Difficulty of translating the consistency constraints built for the CIS540 project to

make it adapt with the new tool.

4. Constraints

1. Project will handle Class and Sequence diagrams models only and not all UML diagram.

2. Class and Sequence Diagram will be compatible with UML version 2.0 specification.

3. The tool may not implement all the features associated with the Class and Sequence diagram, since the focus will be in facilitating the generation of reliable and consistent sequence diagram.

10

Technology Used

The Visual Paradigm SDE tool was selected to write the plug-in for generating sequence diagrams from the class diagram. The SDE (Smart Development Environment) tool is very powerful tool that support the needed functionality to fit any application, besides, its ability to be extended and integrated through different IDE, such as Eclipse, JBuilder and .NET. SDE supports different downloadable editions that varies from enterprise to free noncommercial edition. All commercial version can be downloaded as an evaluation copy for at least one month. However I would like to mention that the support for plug-in is available for all editions even the free one. I believe the SDE tool will be suitable for my MSE project for many reasons, such as, the clarity of writing plug-ins by providing readable tutorial and well organized API, besides the SDE website provide a discussion group that help to communicate with people who have more experience in using the tools and writing plug-ins.Other reason is that the given API makes it easy to control and create the graphical components needed for my tool and that makes it easer to focus on creating usable and friendly user interface -which the idea of my tool heavily depends on-, instead of wasting huge time learning how to draw the basic graphical elements from scratch.

For more information about the SDE, please check the following link:

http://www.visual-paradigm.com/product/sde/

For more information regarding writing the plug, please check the following link:

http://www.visual-paradigm.com/documentation/pluginapi.jsp?format=html.

11

http://www.visual-paradigm.com/documentation/pluginapi.jsp?format=html


Quality Assurance Plan

1. PurposeThis section describes the steps that will be taken to ensure that the Sequence Diagram Generator plug-in will achieve a high level of quality. The required documentation is also defined. This document follows the guidelines stated in the IEEE Standard for Software Quality Assurance Plans.

2. Reference Documents• Vision Document• Project Plan• IEEE Guide for Software Quality Assurance Planning• IEEE Standard for Software Quality Assurance Planning

3. Management

3.1. OrganizationSupervisory Committee

Dr. William Hankley Dr. David Gustafson Dr. Scott Deloach

Major Professor Dr. William Hankley.

Developer Samer Saleh

Formal Technical Inspectors Judy Dizon Patrick Gallagher

12

3.2. ResponsibilitiesSupervisory Committee:The supervisory committee will be responsible for attending the presentations given by the developer. After each presentation the committee members will provide feedback and suggestions regarding the software.

Major Professor:The major professor will be responsible for supervisory committee duties and also meeting with the developer on a weekly basis to evaluate progress and provide suggestions.

Developer:The developer is responsible for all documentation and software development tasks for the software. The project plan describes the tasks to be completed. The developer will also meet with the major professor on a weekly basis to report progress.

Formal Technical Inspectors:The formal technical inspectors will be responsible for a technical review of the architecture design artifacts and the formal requirements specifications. They are required to submit a report on their findings.

3.3. TasksAll tasks to be performed have been documented in the Project Plan 1.0. This will be reviewed after the first phase to incorporate any changes. A Gantt chart is included in the project plan to provide a schedule for each task.

4. Documentation

The documentation will consist of a vision document, project plan, software quality assurance plan, formal requirements specification, architecture design, test plan, formal technical inspection, prototype, user manual, component design, source code, assessment evaluation, project evaluation, references, formal technical inspection letters. All documentation will be reviewed by the committee members for final approval. All documentation will be posted on the developer’s web site at http://www.cis.ksu.edu/~ssaleh/mseproject.htm.

13

5. Standards, Practices, Conventions, and Metrics

5.1 Documentation StandardIEEE standards will be used as a guideline to follow.

5.2 Coding StandardThe project will use traditional object oriented analysis and design methods. Recommended Java style guidelines will also be followed.

5.3 Commentary Standards Comments shall be used in the project to give a brief description of the code,

focusing on the functionality and purpose of commented areas. Each block of statements shall be well commented. Each routine shall have comment consisting of one or two lines at the top of the

routine, describing the purpose and limitations of that particular routine. Each file, module and program shall contain the author’s name, date it was

written or last modified, and a description of how this code fits into the end product. This might also include external functions that are referenced within the custom code.

5.4 DocumentationJavaDoc will be used for documenting the complete API for the

project.

5.5 MetricsBasic COCOMO will be used to estimate the effort and time for the

project.

6. Reviews and AuditsThe committee members will be conducting reviews of the documentation as well as evaluating the developer’s work at each presentation. They will also comment on the software prototype demonstration to suggest changes and additions to the requirements specifications. Two MSE students will evaluate the architecture design artifacts and report on their findings.

14

7. Test and Problem ReportingAll tests, along with their results, will be recorded on a time log of the project web page.Unresolved problems will be reported directly to the committee members.

8. Tools, Techniques, and MethodologiesThe following tools will be used for coding, testing, and documentation.

Java 1.5 – for codingEclipse with Jigloo Pulg-in as the IDEMicrosoft Word – for documentationMicrosoft Software Project 2003 – Project PlanningUSE 2.3 – for formal specification.MSE Test Plan for functional testing.MS Visio and Visual Paradigm for UML modeling.

9. Media ControlThe software will be available on a CD-ROM ready for installation. The executable file will be recorded on it. A user manual soft copy will also be saved in the CD to aid with the installation process and use of the software. Documentation will be available from the developer’s website http://www.cis.ksu.edu/~ssaleh/mseproject.htm

10. Records collection, maintenance and retentionThe design documentation will be stored in the University library, the Major Professor and the developer. Entire source code, documentation and web pages for the project website will be submitted to the Major Professor in the form of a CD. This should also be stored with the developer.

11. DeliverablesThe following is a set of deliverables in each phase.

Phase IVision DocumentProject PlanSoftware Quality Assurance PlanPrototype Demonstration

Phase II

15

Vision DocumentProject PlanFormal Requirements SpecificationArchitecture DesignTest PlanFormal Technical InspectionExecutable Architecture Prototype

Phase IIIComponent DesignSource CodeAssessment EvaluationUser ManualFormal Technical Inspection LettersProject Evaluation

Software Requirement Spec.

1. Introduction

This section will aim in specifying the Sequence Diagram generator software developed for MSE project in the CIS department of Kansas State University. The document will define the project scope, purposes and the overall description. It will also contains an index for materials that can be helpful in understanding the software requirement.

2. Purpose

This section will define and specify the requirement for the sequence diagram generator and it will be intended to be used by the software developer, the project advisor Dr. Bill Hankley and the other member in the committee; Dr. Scott Deloach and Dr. David Gustafson.

3. Scope

16

The product of this project will be a UML sequence diagram generator Plug-in for the Visual Paradigm UML tool. It will be integrated as part of the VP-UML tool and uses the plug-in architecture to create a sequence diagram of the class diagram view. An Analyzer part will be working side by side with the generation process to insure that messages in the sequence diagram pass a set of constraints developed based on the provided class diagram. The user has to provide a valid class diagram with number of classes or association. The class diagram can be drawn or imported from another file as given by the VP-UML too. The sequence Diagram Generator will draw the sequence diagram based on steps performed on the class diagram by selecting objects from classes and the messages from methods. The Analyzer will be used based on consistency checking tool developed for the CIS540 class – Software Engineering – that checks for the consistency between UML class and sequence diagram.

The goal of this project is to create a tool that simplify the process of drawing the sequence diagram by having the class diagram as an interface for the generation process. This process will make it easier to trace and produce more reliable sequence diagram. On the other hand the Analyzer part will insure that the messages are valid based on a given rules, and that will assist in producing a sequence diagram that is more consistent with the class diagram.

4. Definition, Acronyms and abbreviations

- SRS: Software Requirement Specification.- JVM: Java Virtual Machine.- UML: Unified Modeling Language.- SD: Sequence Diagram.- VP-UML: Visual Paradigm UML tool.

5. References

- UML version 2 & 1.5 specification – www.uml.com – OMG group.- Class Diagram & sequence Diagram consistency checking project - CIS540

Project – Samer Saleh, David Reimer, Samir Patel – 2003.- Online Java Tutorial - http://java.sun.com/learning/tutorial/index.html.- VP-UML Plug-in Architecture.

http://www.visual-paradigm.com/documentation/pluginuserguide.jsp?format=pdf

- VP-UML Plug-in API: http://www.visual-paradigm.com/edocs.jsp?url=content/product/extend/pluginApi/html/

17

http://www.visual-paradigm.com/edocs.jsp?url=content/product/extend/pluginApi/html/index.html&resourceType=document&resourceDetail=pluginUserGuide&preferedSite=http://content.usa.visual-paradigm.com/resources



http://java.sun.com/learning/tutorial/index.html

http://www.uml.com/

index.html&resourceType=document&resourceDetail=pluginUserGuide&preferedSite=http://content.usa.visual-paradigm.com/resources

- SDE UML Visual Paradigm Software: http://www.visual-paradigm.com/product/sde/

6. SRS Overview

The rest of the SRS will be organized in the following sections and sub sections: Fist the Over all description that describe product perspectives and functions; the user characteristics; constraints; assumption and dependencies and apportioning of the requirement. The last part of the SRS will contain the Appendixes.

7. Overall Description

This section of the SRS will describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3 of the SRS, and makes them easier to understand.

7.1 Product PerspectiveThe sequence diagram generator Plug-in developed using VP-UML plug-in

architecture will interact with the UML sequence diagram and class diagram only and will not include the remaining UML diagrams. The purpose of this product is to provide a way to generate the sequence diagram through the class diagram, and that can help in producing more reliable sequence diagram since both diagrams are heavily related. The hope is that this tool will open the door for bigger and commercial tool to adapt the same methodology and extended for other diagrams too.The following sub section show how the tool is going to behave toward different interfaces:

7.1.1 System InterfaceSince the tool will be built as plug-in for the VP-UML software, it will be

required to install the software to use the tool. The software can ne downloaded from the following website: http://www.visual-paradigm.com/product/sde/The following diagram shows how the program interacts with the Plug-in architecture to be integrated with UML Visual Paradigm software:

18





Figure2

7.1.2 User Interface

Using the plug-in, the user need to interact with 3 main interfaces, defined as follows:

- Class Diagram View: Allow the user to draw a class diagram by selecting different item through Class Diagram Item panel, such as Class item or Relationship item, where each item can be edited for different attributes, such as name, attributes and methods for each Class item; multiplicity for each relationship end, and so on.The Class Diagram view will allow the user also to start generating the sequence diagram by selecting objects through classes and messages through methods. The user can also set other notations for the sequence diagrams such as guard conditions or iterations for the different messages in the sequence diagram.

- Sequence Diagram Plane: Allow the user to view the generated sequence diagram, where the user has a limited ability to edit the sequence diagram, like undoing

19

selected messages or objects, but the user can’t add/delete messages or objects directly from this plane. Its mostly a view plane.

- Code Block Plane: This plane will show pseudo code for the generated sequence diagram as a helper to understand the sequence diagram. The user won’t be able to edit the pseudo code or update the class diagram or the sequence diagram from this view.

The user will control the class diagram view from the provided drawing panels that the software itself provides. He/she can draw new class diagram and save it or import an already saved class diagram to start generating the sequence diagram. The generation process is done by using different tool bars or pop-up menu item for creating messages and objects based on the selected item on the class model. Another important part of the tool that the user have to deal with is the Analyzer part that will validate each generated message for the sequence diagram based on rules that are mentioned in Appendix A.

7.2 Products Function

Below is a Use Case model for the system with a brief description of each use case.

20

Figure 1

The following section describe in details each functionality ( use case ) found in the Use Case Model. Its important to mention that some functionalities that the user has to do, such as class diagram and creating classes with associations, besides selecting a class to be a callee or caller in the sequence diagram will not presented here since they are not part of the plug-in.

7.2.1 Start Generating sequence diagram

This operation will be initiated from a tool bar icon to start creating the sequence diagram. In order to start this operation there should be a valid class model with some classes and associations, otherwise an error message will be generated.

21

7.2.2 Enable / Disable Analyzer.

This status will be toggled each time the user click on the same tool bar icon to enable or disable the analyzer when generating the sequence diagram. To control this status there should be a valid sequence diagram created.

7.2.3 Generate Sequence Diagram Elements

Through this use case the user will be able to create sequence diagram elements by selecting classes for objects life lines and operations for messages. It can be one of the following operations:

7.2.3.1 Select Caller

In this operation the user will be able to select new caller for the sequence diagram. The selected caller class type will be decided based on the selected class in the class mode. The user will be prompted then to create new caller or select an existing caller that is already been created before in the sequence diagram.

7.2.3.2 Select Callee

In this operation the user will be able to select new callee for the sequence diagram after selecting a caller. The selected callee class type will be decided based on the selected class operation in the class mode. The user will be prompted then to create new callee or select an existing callee that is already been created before in the sequence diagram.

7.2.3.3 Select Callee from Actor

In this operation the user will be able to select new callee for the sequence diagram after in which the caller will be the actor of the sequence diagram. The selected callee class type will be decided based on the selected class operation in the class mode. The user will be prompted then to create new callee or select an existing callee that is already been created before in the sequence diagram.

7.2.4 Edit Generated Sequence Diagram

This use case will enable the user to do some editing on the generated sequence diagram. The editing capability so far is limited on undoing or redoing the last selection or sequence, but it can be extended to include all selections or sequences, and to include other editing features such as adding messages or objects in between.

22

7.2.4.1 Undo Last Selection

In this operation the user will be able to undo last selection made to create the new sequence diagram elements, for example if the user last selection was new caller then of this new caller will be deleted and the generator is set to re select the new caller again. The same thing applies to the callee, and the sequence diagram will be updated to status before the undone selection is made.

7.2.4.2 Undo Last Sequence

In this operation will be enabled after the user has completed one sequence in the sequence diagram by selecting a caller and a callee. In this case, the last sequence will be undone , and the new created message in between will be deleted for sure, however deleting the caller or callee object life line will be dependent on the case where the either or been active before by send/receiving messages, if not, they will be deleted, otherwise they will remain.

7.2.4.3 Redo Last Selection

It’s done after selecting the “Undo Last Selection” to re generate the selection that has been deleted.

7.2.4.4 Redo Last Sequence

It’s done after selecting the “Undo Last Sequence” to re generate the sequence that has been deleted.

7.2.5 Check for valid messages:

This use will be performed by the analyzer to check for valid messages that can be generated in the sequence diagram after new caller is selected. To determine the message validity, each class other than the caller class will be checked against some rule – as indicated in index A – to decide if the given class can communicate with the caller or not.

7.2.6 Draw Element

This is an abstract use case to identify that after each item selection , there will be some functions involved to draw the new sequence diagram element based on the made selection.

23

7.3 User Characteristics

User of this plug-in should be familiarized with UML, specially class and sequence diagrams. Software engineer or Designers can use this plug-in to help them generate a reliable and consistent sequence diagram.

7.4 Constraints

This tool is plug-in to show a way of inferring one diagram information – Class Diagram – into another diagram – Sequence Diagram – and its not built to implement all the attributes of the class and sequence diagrams, therefore some of the notations may not be implemented in this version of the product.

7.5 Specific Requirements

This section and the following subsection will provide an extended look to the product different interfaces and all inputs/outputs related to each interface.

7.5.1 External Interface

1) Plug-in Tool Bar Icons:

a- Start Generating Sequence Diagram: o Purpose: Used when there is a class model to start generating sequence

diagram elements off the class model elements. o Source of Input: User clicks on the tool bar icon to generate the plug-in

action.o Relations to other inputs/outputs: If there is no valid class model, an

error message will be generated, otherwise the user will be prompted to enter the sequence diagram name and actor name.

o Screen Formats/Organization: VP-UML Plug-in API format.

b- Enable/Disable Analyzer:.o Purpose: A toggling tool bar icon that is used to switch between enabling

or disabling the analyzer when generating a sequence diagram.o Source of Input: User clicks on the tool bar icon to generate the plug-in

action.o Relations to other inputs/outputs: Enabled if there is a valid sequence

24

diagram.o Screen Formats/Organization: VP-UML Plug-in API format.

2) Generate Sequence Diagram Elements Pop-up menu items:

a- Generate Sequence Diagram: Select Caller

o Purpose: Used to select the new caller element for the sequence diagram.o Source of Input: Mouse click on the select caller pop-up menu to

generate a pop-up menu action.o Relations to other inputs/outputs: If no class selected prior to the

selection, an error message will be generated, otherwise “Create Caller Element “ dialog will be shown.


b- Generate Sequence Diagram: Select Callee

o Purpose: Used to select the new callee element for the sequence diagram.o Source of Input: Mouse click on the select callee pop-up menu to

generate a pop-up menu action.o Relations to other inputs/outputs: If no class operation is selected prior

to the selection, an error message will be generated, otherwise “Create Callee Element “ dialog will be shown.


c- Generate Sequence Diagram: Create Message from Actor

o Purpose: Used to create a message to a callee from the sequence diagram actor.

o Source of Input: Mouse click on the select message from actor pop-up menu to generate a pop-up menu action.

o Relations to other inputs/outputs: If no class operation is selected prior to the selection, an error message will be generated, otherwise “Create Callee Element “ dialog will be shown.


25

3) Edit Sequence Diagram Pop-up menu items:

a- Edit Sequence Diagram: Undo Last Selection

o Purpose: Used to erase the latest selection made, either for caller or callee.

o Source of Input: Mouse click on the undo last selection pop-up menu item to generate a pop-up menu action.

o Relations to other inputs/outputs: Update the sequence diagram model to affect the changes made by this selection.


b- Edit Sequence Diagram: Undo Last Sequence

o Purpose: Used to Erase the latest sequence made, by selecting both the last selected caller and callee.

o Source of Input: Mouse click on the undo last sequence pop-up menu item to generate a pop-up menu action.


o Screen Formats/Organization: VP-UML Plug-in API format c- Edit Sequence Diagram: Redo Last Selection

o Purpose: Used to reverse the effect from selecting the “Undo Latest Selection” item.

o Source of Input: Mouse click on the redo last selection pop-up menu item to generate a pop-up menu action.


o Screen Formats/Organization: VP-UML Plug-in API format

d- Edit Sequence Diagram: Redo Last Selection

o Purpose: Used to reverse the effect from selecting the “Undo Latest Sequence” item.

o Source of Input: Mouse click on the redo last sequence pop-up menu item to generate a pop-up menu action.

26


o Screen Formats/Organization: VP-UML Plug-in API format

Architecture Design

1. Introduction

This section will contain the architecture design of the Sequence Diagram Generator plug-in using UML. The first part will describe the static structure using class diagram, with description of all classes and the important operations that distinguish each

27

class from others. The second part will show how classes interact with each other through the plug-in major operations, and finally a dynamic model represented by the state diagram will explain the behavior of main classes.

2. Tools and References:

- The tool used for drawing the UML models in this document is Visual Paradigm: http://www.visual-paradigm.com/product/sde/- UML Object Management Group:

http://www.uml.org/- UML Visual Paradigm API:


3. Architecture Design:

The architecture design will be divided into the following sections:

1- Static Structure including packages and classes views.2- Interaction behavior using sequence diagrams.3- Dynamic behavior using state diagrams

4. Static Structure:

The static structure will include a package view describing the general interaction between the different packages before going into more detailed and complex view of the class model. The class model will be divided into 3 parts representing different layers of the static model, starting from all classes layer that shows classes from VP-UML API and the sequence diagram generator plug-in, and going into domain model layer where the important classes that made the plug-in are shown.

28




http://www.uml.org/


Below each diagram will be a brief description of each class or package found in the diagram.

4.1 Package View

PluginActionController:This package contains all the actions handlers that get called from the VP-UML plug-in architecture, whenever toolbar icon is clicked or popup menu item has been selected. Each toolbar icon, menu item or popup menu item should correspond to an action handler. There are two kinds of action handlers: one for tool bar icon or menu item which implements the VPActionController class and other for popup menu item which implements VPContextActionController. For more details on these classes check the class view.

PluginSegGenDialogs:This package contains all the dialogs used by the plug-in. Generally these dialogs will get called after an action has taken place. So far there are two main dialogs used; one is called after selecting the new sequence diagram toolbar icon to set the sequence diagram name and the actor name. Another used when creating new

29

sequence diagram element ( caller / callee ) and used to either create new or select an existing if the there is any.

PluginSeqGenerator:

This package contains the controller classes responsible for tracking the current sequence and creating sequence diagram elements. The controller classes get called from either classes in the PluginActionController or PluginSeqGenDialogs. For more details on the package classes and operations, check the class diagram view.

Com.vp.plugin.diagram:This is a VP-UML API package, and its used to access the different UML diagrams and diagram elements, for this tool only class and sequence diagrams were used.

Com.vp.plugin:This is a VP-UML API package, and its used to access some controller classes that controls VP-UML tool environment, such as Diagram Manager, Application Manager and View Manager. For more details on these classes, check the classes view.

Com.vp.plugin.model:

This package contains all the model elements that will be part of the class or sequence diagrams, such as IClass, IInteractionLifeLine, and IMessage. These model elements will be created or retrieved from the diagrams for various reasons. For more details on some of the package classes used in this plug-in, check the classes view.

PluginAnalyzer:

This package contains all the classes needed for analyzing the consistency between the current class diagram and the generated sequence diagram. Most of the analysis rules check the message validity between a caller and a callee. From more information on these rules check the software requirement specification.

4.2 Class View

The class view will show different layers of class structure, the first layer will show all the classes involved in building the plug-in without adding the operations or attributes for each class, the other layer will show the classes that makes the domain

30

model of the plug-in with the main operations and attributes added. Below each diagram will description of each class and operations.The first diagram in the following page, describes the over all structure of the plug-in. Please note that some of the classes – usually Starts with litter I – are API classes, and they are added to clarify how the plug-in classes interact with the API classes.

31

32

IDialogHandler:API Interface used to create dialogs for the plug-in that is compatible with the plug-in architecture. Each created dialog must implement this interface.

IDialog:API Interface used to store the information for the plug-in created dialog, such as the content pane and the other swing components added to the content pane.

NewSeqDiagramDialog:Plug-in class used to create the dialog before start generating the sequence diagram, the purpose of this dialog is to prompt the user to enter the sequence diagram name and the actor name. Implements IDialogHandler.

NewSeqDiagElementDialog:Plug-in class used to create the dialog responsible for creating the new sequence diagram element either when selecting a caller or a callee. The dialog will provide two options, either to create new element (Caller/Callee) or select an existing one if there is any. It will also provide the user the ability to check other options such as creating new activation line or create a return message in case the element was a callee. Implements IDialogHandler.

SequenceDiagGenerator:Plug-in class serve as the controller of the plug-in , that is called by the action handlers or the dialogs for generating the sequence diagram. It keeps track of the current state in the sequence diagram to decide the following step. For more information about the class check the class operations mentioned later and check the dynamic model.

SequenceDiagramGraphics:Plug-in class used by the controller “SequenceDiagGenerator” to create the sequence diagram graphical elements, it keeps track of the current positions for different elements such messages, interaction life line and activations…etc.

IDiagramElement:API class serves as the parent class for all the graphical components on the diagram, for example when creating new IClass and adding this class to the diagram, the result of the addition operation will return an object of type IDiagramElement, which contains graphical information about the created model, besides the model element itself which is in this case the IClass model.

33

IDiagramUIModel:API class used by the SequenceDiagramGraphics to access the created sequence diagram which is type of ICommunicationDiagramUIModel that inherits from this general class.

IDiagramManager:API Interface used by the SequenceDiagramGramphics to access the current active diagram or to create new diagram. Its also use to associate diagrams with model elements to create the new diagram elements in the diagram.

ICommunicationDiagramUIModel:API Interface that represents the sequence diagram. It inherits the IDiagramUIModel class which contains operations to retrieve the different graphical elements in the diagram.

IClassDiagramUIModel:API Interface that represents the sequence diagram. It inherits the IDiagramUIModel class which contains operations to retrieve the different graphical elements in the diagram.

IModelElement:API Interface that represents the model structure for each diagram component. First create new interaction life line in the sequence diagram , it should be created as IModeElement that has an id and name, and from that the graphical component represented by the IDiagramElement can be created by adding the model element to the diagram through the diagram manager class.

IClass:API Interface that inherits the IModelELement, and represents the class diagam class model element. Operations, attributes or other class features can be added, retrieved or removed through these class operations. For more information on this class check the API link found in the references.

IRelationShip:API Interface that inherits the IModelELement. It represents the association between classes other than the aggregation/composition association. Through this class; the two ends of the relation can be set or retrieved.

IAssociationEnd:API Interface that inherits the IModelELement and IRelationShipEnd. It represents one end of the aggregation/composition association between two

34

classes. Through this class; the end class or the opposite end class can be set or retrieved.

IInteractionLifeLine:API Interface that inherits the IModelELement. It represents the object life line found in the sequence diagram.

IActivation: API Interface that inherits the IModelELement. It represents the message activation line that is created in the interaction life line whenever the object has fired new message. The activation line can be new for each message or the same for all/some messages, depending on the implementation.

IMessage:API Interface that inherits the IModelELement. It represents the messages send between a caller and a callee.

VPActionController:API Interface implemented by the toolbar/ menu item action handlers. There are two methods in this interface that need to be implemented in the action handler:“performAction” that is called whenever the toolbar icon/menu item is selected, and “update” method which is called whenever the VP-UML is refreshed or opened for initialization.

ActionEnableDiableAnalyzer:Plug-in class that implements VPActionController interface, serves as the action handler for the enable/disable analyzer tool bar icon. This one icon serves two purposes by toggling the analyzer enable/disable status.

ActionStartSeqGeneration:Plug-in class that implements the VPActionController interface. Serves as the action handler for creating new sequence diagram toolbar icon.

VPContextActionController:API Interface implemented by the popup menu items action handlers. There are two methods in this interface that need to be implemented in the action handler:“performAction” that is called whenever the popup menu item is selected, and “update” method which is called whenever the popup menu appeared when right click for initialization.

ActionActorMessage:

35

Plug-in action handler that implements the VPContextActionController. This action is called whenever the popup menu item for creating a message from actor in the sequence diagram is selected.

ActionCalleeMessageSelection:Plug-in action handler that implements the VPContextActionController. This action is called whenever the popup menu item for selecting new callee message in the sequence diagram is selected.

ActionCallerSelection:Plug-in action handler that implements the VPContextActionController. This action is called whenever the popup menu item for selecting new caller in the sequence diagram is selected.

ActionUndoLastSelection:Plug-in action handler that implements the VPContextActionController. This action is called whenever the undo last selection popup menu item is selected to undo the last selection and affect that on the sequence diagram.

ActionUndoLastSequence:Plug-in action handler that implements the VPContextActionController. This action is called whenever the undo last sequence popup menu item is selected to undo the last decided sequence. Usually this item is enabled whenever latest caller and callee message are selected, otherwise it will be disabled.

ActionRedoLastSelection:Plug-in action handler that implements the VPContextActionController. This action is called whenever the redo last selection popup menu item is selected to reverse the effect from selecting undo the last selection popup menu item.

ActionRedoLastSequence:Plug-in action handler that implements the VPContextActionController. This action is called whenever the redo last sequence popup menu item is selected to reverse the effect from selecting undo the last sequence popup menu item.

SeqDiagGeneratorAnalyzer:Plug-in class used for conducting the analysis on the message validity when selecting new caller and new callee message. For more information on the analysis rule check the software requirement specification appendix, and check to the domain model view for more details on the class operations

36

AnalyzerIndirectAssociation:Plug-in class used by the seqDiagGeneratorAnalyzer to create the indirect association for the checked caller class type. The indirect association is imposed by the transitive aggregation going from the caller class type to the other classes that is not directly connected to the caller class. This class is needed for the analysis when validating if a selected callee message has direct or indirect association form the selected caller.

VPContext:API class used by both VPContextActionController and the VPActionController to access the model element or the general diagam being active when either action has taken place.

IModelElementFactory:API class used by the sequenceDiagramGraphics to create the different model element used to draw the different diagram elements in the generated sequence diagram.

4.2.1 Controller Domain Model

In the following model the controller classes of the plug-in are shown only with operations and attributes. The purpose of this model is to zoom more into the controller package and explain the several operations that distinguish one controller class from another. Note that not all the operations or attributes are show in this model, only the important one that can define the general functionality of each class. Also Notice that the operation signature is hidden from each class to make the model looks simpler and fit in one page.Below the model there will be an explanation for all the attributes, operations and operation’s parameters mentioned in each class.

37

38

SequenceDiagGenerator:o Attributes:

- analyzer: is the analyzer class used by the sequence diagram generator to check the validity of the message and insure consistency between class and sequence Diagram.

- sequenceDiagramGraphics: used to create the graphical elements for the sequence diagram. For more details check the SequenceDiagramGraphics operations.

- selectCallerTurn: used to track the current valid sequence for generating sequence diagram element. The value ranges from true to false to switch between caller and callee turn.

- messageFromActor: Boolean value that decides if a new message is created and being initiated by the sequence diagram actor.

- analyzerEnabled: Boolean value that determines if the analyzer has been enabled or not to check for message validity while generating the sequence diagram for each caller.

o Operations:1. createNewSequenceDiagram: Called to create the new sequence

diagram before the generation process starts. Return Type: none. Parameters:

- diagramName: String that identify the sequence diagram name.

- actorName: String that identify the actor name.

2. showSeqDiagramCallerDialog: Called to show the dialog for creating new or selecting an existing caller life line object when it’s the turn to select a caller.

Return Type: none. Parameters:

- modelElement: the selected model element – class in this case – from the class diagram.

3. showSeqDiagramCalleeDialog: Called to show the dialog for

39

creating new or selecting an existing callee life line object when it’s the turn to select a callee message turn.

Return Type: none Parameters:

- modelElement: the selected model element – class operation in this case – from the class diagram.

4. modifySeqDiagramElement: Called when selecting an existing life line element whether it’s a caller or callee.


- index: the index of the life line element that is selected for the new modification. Its stored in an array of all the life lines that has a class type of the selected class.

5. createSeqDiagramElement: Called when choosing to create new life line element in the sequence diagram whether it’s a caller or callee.


- lifeLineName: String for the new created object life line name.

6. undoSeqDiagLastSelection: Called to undo the last selection whether it was for a caller or a callee. Note after calling this method the current turn for selecting caller or callee will be reset from the start will the undo operation took a place

Return Type: none Parameters: none.

.7. undoSeqDiagLastSequence Called to undo the last sequence

whenever a caller and a callee have been selected and added to the sequence diagram mode.

Return Type: none Parameters: none.

8. toggleSequenceDiagramGeneratorTurn: Called to switch

40

between caller and callee turns each time new selection is made. Return Type: none Parameters: none.

SequenceDiagramGraphics:o Operations:

1. createSeqActorElement: Called to create and draw the actor element when creating the sequence diagram


- actorName: String for the actor name.

2. createNewSeqLifeLineElement: Called to create and draw a new life element for either caller or a callee when choosing to create new. actor element when creating the sequence diagram

Return Type: - IDagramElement: graphical component of the created life

line object.

Parameters: - lifeLineName: String for the new life line name.- IModelElement: the base class type of the created object

life line.

3. createSeqDiagramNewMessage: Called to create new message going from caller to callee.

Return Type: - IDagramElement: graphical element of the new message..

Parameters: - caller: The graphical element of the caller life line object.- callee: The graphical element of the callee life line object.- Message: The model element for the new message.

41

4. cleanSequenceDiagram: This operation is added to fix a current bug in the plug-in architecture. The bug happens whenever a new element is created in the sequence diagram while the sequence diagram is open, a duplicated element will be created, so this operation is called after creating new elements to remove the duplicated elements.

Return Type: none. Parameters: none.

IDiagramElement:o Operations:

1. getModelElement: Return the model element that makes the graphical component in the diagram represented by this class.

Return Type: - modelElement: The IModelElement object that makes this graphical component for example class model, life line model…etc.

Parameters: none. 2. getCaptionUIModel: return the caption element that display the

name of the graphical element besides the element. For example a message in a sequence diagram has a caption beside the message arrow that displays the name of the message. Usually the location for the caption must be set through the program to make adjacent to the message location, otherwise it will be always in 0,0 location.

Return Type: - ICaptionUIModel: returns the caption model for the

selected diagram element if there is any.

Parameters: none.

3. getShapeType: Return the shape type that makes this diagram element, for example class shape or life line shape...etc.

Return Type: - shapeType: a string definition of the element shape.

42

Parameters: none.

4. getId: Return a unique identifier of the selected diagram element. Return Type: Sting type of the unique identifier. Parameters: none.

DiagramManager:o Operations:

1. createDiagram: create new diagram model, depending on the diagram type provided as parameter.

Return Type: - diagramModel: created model of type of IDiagramUIModel.

Parameters: - diagramType: Sting definition of the created diagram type, there is string definition for each diagram type associated with DiagramManager class.

2. getActiveDiagram: return the current open diagram. Return Type:

- IDiagramUIModel: the current open and active diagram.

Parameters: none.

3. createConnector: This method is responsible for creating elements that represent connectivity between other elements such as association , relationship in class diagram and messages in sequence diagram. In this plug-in its used to create messages in sequence diagram.

Return Type: - IDiagramElement: a graphical representation of the created

connector.

Parameters: - diagramModel: the associated diagram that the elements

must be added to. Type of IDiagarmUIModel.- connectorModel: the model representation of the created

43

connector, in this case IMessage.- Caller: the graphical representation of the current caller of

type of IDiagramELement.- Callee: the graphical representation of the current callee of

type of IDiagramELement.- connectorPoints: Point Array of size 2 , that has the starting

and ending point of the message.

4. createDiagramElement: used to create the graphical elements of the model, such as object life line element, class element. For elements that represent connectivity you have to use createConnector method mentioned above.

Return Type: - IDiagramElement: the new created element.

Parameters:- diagramModel: The diagram associated with the new

element of type IDiagraUIModel.- modelElement: the model representation of the created

diagram element for example IClass or IInteractionLifeLine.

5. openDiagram: open the provided diagram of type of IDiagramUIModel..

Return Type: none.

Parameters:

- diagramModel: the digram model that is going to be opened if valid.

IDiagramUIModel:o Operations:

1. getDiagramElementAt: return the graphical representation of the element referenced by the given index.

44

Return Type: - IDiagramElement: the graphical element referenced by the

given index.

Parameters: - index: integer value of the element index.

2. getDiagramElementById: return the graphical representation of

the diagram element referenced by the given Id. Return Type:

- IDiagramElement: the graphical element referenced by the given id.

Parameters: - id: String representing the element unique identifier.

3. diagramElementCount: return the number of element in the given diagram

Return Type: - Int: number of elements in the diagram..

4. Parameters: none.5. diagramElementIterator: return an iterator object to trace the

diagram elements in the given diagram. Return Type:

- Iterator: iterator object to trace the diagram elements.

Parameters: none.

6. removeDiagramElementAt: remove the diagram element specified by the given index..

Return Type: none.

Parameters:

- index: Integer value of the index of the removed element.

7. toDiagramElementArray: return an array representation of all

45

the diagram element in the given diagram. Return Type:

- IDiagramElement[]: an array of all diagram element in the diagram.

Parameters: none.

8. realCloseDiagram: This function is added to the plug-in API to fix a bug generated from drawing new elements while the diagram is currently open that will cause to place graphical elements in the wrong locations, so in order to fix the bug this method is used to close the diagram virtually before adding new elements and then reopen it again after adding the new element. Please note that before this method the IDiagramUIMoldel had no class to close the diagram.

Return Type: none. Parameters: none.

IModelElementFactory:o Operations:

1. instance: create a static instance of the instance of the IModelElementFactory interface.

Return Type: - Static IModeleElementFactory.

Parameters: none. 2. createInteractionActor: create the Actor Element for the

generated sequence diagram. Return Type:

- IModelElement: general model element object that will be typecast to IInteractionActor.

Parameters: none.

3. createInteractionLifeLine: create a life line model to be used in the generated sequence diagram.

Return Type:

46

- IModelElement: general model element that will be typecast to the life line class model IInteractionLifeLine.

Parameters: none

4. createMessage: create a message model to be used in the generated sequence diagram.

Return Type: - IModelElement: general model element that will be

typecast to the message class model IMessage. Parameters: none5. createActivation: create an activation model that is used by the

life line object to send or receive new message. Return Type:

- IModelElement: general model element that will be typecast to the activation class model IActivation.

Parameters: none

6. createActionTypeReturn: create action mode that will be given to message model to be specified as a return message.

Return Type: - IModelElement: general model element that will be

typecast to the action type class model IActionTypeReturn. Parameters: none

4.2.2 Analyzer Domain Model

47

48

seqDiagGeneratorAnalyzer:o Operations:

1. determinceValidCalleeClasses: This is called by the selected caller class to trace all the classes that the caller can initiate message to. It will be responsible for calling the other analyzer functions.

Return Type: none.

Parameters: none. 2. createClassIndirectAssociation: Iterate all the association from

the caller class and if the association is type of aggregation or composition, it will start looking for the transitive associations for the caller class and create new indirect association.


- allAssociations:IRelationshipEnd[]: array of all the association from the caller class.

3. generateIndirectAssociations: recursive function that is responsible for looking for all the transitive association path for the caller class. When this function exists the indirect association for the caller class would have been created.


- assocFromEnd:IModelElement: the caller class end.- assocToEnd:IModelElement: the transitive end class.

4. createNewIndirectAssociation: when new transitive association is found , this function gets called to create and store the new found indirect association.

Return Type:none. Parameters:

- fromEnd:IModelElement: the caller class end.- toEnd:IModelElement: transitive end class.

49

- intermediateClassName:String: name of the intermediate class that comes in between caller and the new found transitive end.

- intermediateClassId: a unique identified of the intermediate class that come in between caller and the new found transitive end.

5. checkIfClassHasDirectRelation: check if the caller class has direct relationship with the expected callee class.

Return Type: Boolean that indicates if there is a direct relation ( true) or not ( False).

Parameters: - calleeClass:IModelElement: the expect callee class of type

of model element.

6. colorCalleeClassBlue: Make the expected callee class color as blue, indicating either there is a direct or indirect association from caller to the expected callee.


- calleeShape: IShapeUIModel: this is the shape representation of the callee class, and through this shape model color properties can be changed.

7. colorCalleeClassBlue: Make the expected callee class color as gray, indicating no direct or indirect association found from the current caller and the expected callee class.


- calleeShape: IShapeUIModel: this is the shape representation of the callee class, and through this shape model color properties can be changed.

AnalyzerClassIndirectClass:o Operations:

1. getFromEnd: return the class model element of the caller class for the given indirect association.

Return Type:

50

- IModelElement: the model element of the caller class.

Parameters: none. 2. getFromEnd: return the class model element of the expected

callee class for the given indirect association. Return Type:

- IModelElement: the model element of the expected callee class.

Parameters: none.

IRelationshipEnd:o Operations:

1. getEndRelationShip: return the end of the current relation ship. Through this end both the from end class model element and the to end class model element can be retrieved.

Return Type: - IEndRelationship: The end of the relationship that contains

both from end class and to end class.

2. getModelElement: get the from end class model element of the current relationship.

Return Type: - IModelElement: the from end class model element.

Parameters: none.

3. getOppositeEnd: return the opposite end of the given relationship.

Return Type: - IRelationshipEnd: the new relationship end class representing the other end of the given relationship.

Parameters: none.

IAssociationEnd:o Operations:

51

1. getAggregationKind: return the aggregation kind of the current association.

Return Type: - String: Aggregation Kind.

Parameters: none.

2. Static Behavior

The following models describes the interactions through the sequence diagram for some of the major operations in the sequence diagram generator .

2.1 Create New Sequence Diagram

52

2.2 Create Sequence Diagram Caller

53

2.3 Create Sequence Diagram Callee Message

54

2.4 Create Sequence Diagram Life Line Element

55

3. Dynamic Behavior

3.1 Sequence Diagram GeneratorThe following state model describes the dynamic behavior of sequence

diagram generator class that is responsible for directing the sequence diagram generation.

56

Project Plan1. Tasks Breakdown

1.1 Inception PhaseThe inception phase focuses on defining the requirements specification. For this purpose, a vision document will be created which gives an overview of the project and elaborates the requirements for the software. The major use cases are defined and elaborated in the requirements analysis.A project plan will be developed in the inception phase that gives the schedule of all activities required to complete the project. A software quality plan is also laid out in this phase to ensure that the quality of the product is maintained throughout the development life cycle. A prototype is also developed with the motive to show the feasibility and the look and feel of the project.The inception phase completes when the prototype along with the other documents are approved by the committee.

Deliverable

The following deliverable will be result of the inception phase:

Project Vision 1st Draft:

In this document an introduction of the project will be given with mentioning general goals and risks that will surround the project development life cycle.

Project Software Requirement Specification 1st Draft:

Software Requirement Specification document will define the project scope, purposes and the overall description. It will also contain an index for materials that can be helpful in understanding the software requirement.

Project Plan 1st Draft:

The project plan will detail the phases, iterations, and milestones that will comprise the project. Each deliverable will be included in the plan with estimated dates, sign-offs and evaluation criteria. PERT or Gantt charts are appropriate inclusions in this plan.

57

Quality Assurance Plan:

This document describes the steps that will be taken to ensure that the plug-in will achieve a high level of quality. The required documentation is also defined. This document follows the guidelines stated in the IEEE Standard for Software Quality Assurance Plans.

GUI Prototype:

Simple prototype will be developed to show the basic functionality of the project and the different interfaces that the use will interact with.

1.2 Elaboration Phase

In the elaboration phase, the architecture of the software will be finalized. The documents from phase I will be reviewed and completed as desired by the committee. A test plan would be developed which will mention the complete testing process including the reporting of bugs and solving them.Formal requirements specification will be generated for a part of the project, if not for the entire system. The language used for this would be OCL. Another prototype would be developed to demonstrate more features in the tool. Two technical inspectors will review the design in this phase and report with their findings.The elaboration phase will be marked as ‘complete’ when the committee reviews the documents and approves of the prototype, with or without changes.

Deliverable

The following deliverable will be result of the elaboration phase:

Project Vision 2ed Draft:

The project vision document will be updated from the first phase to clarify the project purpose and mention complete list of the project goals, risks and constraints. .

Project Software Requirement Specification 2ed Draft:

Software Requirement Specification will update to completely define the project scope, purposes and the overall description. It will also contain a description of the functionality and the different interfaces. A Use Case model will be finalized.

Software Design Architecture:

58

This document will contain the architecture design of the Sequence Diagram Generator plug-in using UML. It will be divided into three sections; the first part will describe the static structure using class diagram, with description of all classes and the important operations that distinguish each class from each other. The second part will show how classes interact with each other through the plug-in major operations, and finally a dynamic model represented by the state diagram will explain the behavior of main classes.

Software Test Plan:

A system test plan for the Sequence Diagram Generator should support the following objectives:

- Identify which features of the system will be tested and those that will not be tested.

- Specify the testing approaches that will be used during testing- Define the pass/fail criteria for each item to be tested- Define any suspension criteria and subsequent resumption techniques- Identify the deliverables of the testing process

Formal Technical Specification:

One part of the project will be formally specified using a published, formal methodology such as OCL.

Formal Technical Inspection:

A formal checklist to be used by the inspectors will be developed. Two MSE students will be identified as the technical inspectors.

Executable Prototype:

An executable architecture prototype will be built in one or more iterations. The prototype will address all critical requirements identified in the vision document and expose the top technical risks.

1.3. Production PhaseThe production phase deals with the complete implementation and testing of the software. In this phase the user will develop the code and make sure that it is fully documented. The code will be tested entirely to check if all the requirements are met.

59

Deliverable

User Manual

A user manual will be provided. Sections will include (if appropriate) an overview and explanations of common usage, user commands, error messages, and data formats.

Component Design

The internal design of each component will be documented. The documentation required will be consistent with the complexity of the individual components. The use of model-based diagrams such as class diagrams, sequence/collaboration diagrams, and state chart/activity diagrams will be considered.

Source Code

Well-documented source code will be submitted. This code will correspond directly to the architecture and component design.

Assessment Evaluation

The documentation will include a document detailing the testing done on the project. Included will be descriptions of the testing, failures, and reliability estimates. Graphical methods will be used, e.g. error rate diagrams, etc.

Project Evaluation

The student will review the project. The process will be reviewed, including the usefulness of the methodologies used, the accuracy of the estimations, and the usefulness of the reviews. Similarly, the product will be reviewed and evaluated for whether it accomplishes the ideas presented in the initial overview and for the quality of the product.

References

The annotated bibliography will include cited references for all notations used in the portfolio.

Formal Technical Inspection Letters

The student must include two letters from other MSE students stating that the student in question successfully participated in their MSE project as an inspector and that their projects (or at least their formal technical inspection section) had successfully passed the architecture presentation.

60

2. Overview

This document will describe the different phases, iterations and milestone for the software. It will also includes plans and estimated dates, sign-offs and evaluation criteria.A Gantt chart will be provided to summarize the different phases and the plans.

Part of this document will be dedicated for the cost estimate on size, time and effort required for the project. Another part will be dedicated for architecture elaboration plan that will define the activities and the actions the must accomplished to prior to the architecture presentation. The plan must include the set of requirement the need to be formalized and the artifacts that will undergo formal technical inspection.

Deliverable Tasks Completion Criteria

Time2005

Cost

MSE Project Webpage

Creating time log for the Project over the web

Time Log is available in

the web

Jan 14th 1

Project Vision Document 1st

Draft.

Writing a project vision document

Advisor Approval

Jan 16th – Jan 18th 2

SRS 1st Draft Writing the project

requirement

Advisor Approval

Jan 19th – Jan 27th 9

WBS Draft Cost Estimates & Arch.

Elaboration.

Advisor Approval

Jan 28th – Feb. 11th 11

GUI Prototype Constructing The first prototype

Advisor Approval

Feb 18th – Feb 25th 7

First Presentation April 15Action Items First Presentation

Action Items are Identified

Advisor Approval

May 1st 1

Project Tool Proposal

Project to and technology used

is identified.

Advisor Approval

August 16th – Sep. 8th 23

Early Design Architecture.

Early class , package ,

sequence models

Advisor Approval

Sep. 9th – Sep. 18th 10

Coding the Plug-in Actions package.

Action Package Advisor Approval

Sep. 19th 1

Coding the controller package

Controller Package

Advisor Approval

Sep. 20th – Sep. 25th. 6

61

Coding the Dialogs Package

Dialogs Package Advisor Approval

Sep. 26th – Sep. 30th 5

Coding the Analyzer Package

Analyzer Package

Advisor Approval

October 1st – Oct. 7th 8

Debugging and Updating Code

Executable Prototype

Advisor Approval

Oct. 8th – Oct. 14th 7

Writing Formal Specification

OCL Specification

Advisor Approval

Oct. 20th – Oct. 22ed. 3

Creating the formal

inspection list

Inspection List Advisor Approval

Oct. 23ed 1

Creating Project Test

Plan

Test Plan Advisor Approval

Oct. 24.th – Oct. 26th 3

Update the Software

Requirement Spec.

SRS 2ed Version Advisor Approval

Oct. 27th – Oct 28th 2

Documenting Architecture

Design

Architecture Design

Advisor Approval

Oct. 29th – Oct. 31st 3

Updating Project Plan

Project Plan 2ed Version.

Advisor Approval.

Nov. 1st – Nov 2ed. 2

2ed Presentation November 7th.Action Items Implement action

ItemsAction Items

from 2nd

presentations are addressed

Nov. 8th – Nov. 10th 3

Finishing the Project

Implementation

Complete Executable.

Executable complies with

SRS.

Nov. 11th – Nov 19th 10

User Manual Document how to install and run

Advisor Approval

Nov. 20th – Nov. 21st 2

Document How to use

Advisor Approval

Nov. 22ed – Nov. 23ed

2

Component Design

Document

Finalize all the design model

documentation.

Advisor Approval

Nov. 24th – Nov. 26th 3


Run Test Cases Test cases passed

Nov. 27th – Nov 28th 2

Document Testing Result

Advisor Approval

Nov 29th – Nov 29th 1

Source Code Submit final Advisor Nov. 30th – Nov 30th 1

62

source code Approval

Project Evaluation

Document Project

Usefulness

Dec 1st – Dec. 1st 1

Document & Analyze Cost

Estimates

Dec 2ed – Dec 2ed. 1

References Document All References used for the project

- Dec 3ed – Dec 3ed 1

Formal Technical

Inspection letter

Submit review letters from the

inspectors

Dec 4th – Dec 4th 1

Final Presentation December 5th Total 141

3. Cost Estimation

In this project, Functional Point Analysis and COnstructive COst MOdel ( COCOMO ) are used for estimating the size and cost of developing the application. A function point is a rough estimate of a unit of delivered functionality of a software project. To calculate the number of function points for a software project one counts all the user inputs, outputs, inquiries, number of files and number of external interfaces, then split them up in according to the degree of their complexity like simple, average and complex.

User Inquiries

These are request response pairs that do not change the internal data. Example, a request for the address of a specified employee is an inquiry. The whole sequence of asking, supplying the name and getting the address would count as one inquiry. Also an inquiry is defined as an online input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.

I summarized the user inquiries in the following items:

- Plug-in Inquiry for the generated sequence diagram name (Simple).- Plug-in Inquiry for sequence diagram actor name (Simple).- Plug-in Inquiry for sequence diagram caller life line object (Average)- Plug-in Inquiry for sequence diagram callee message life line object

(Average)

63

User Inputs

They are each unique user data or control input that enters the application boundary and also updates (adds to changes, or deleted from) a logical internal file, data set, table or independent data item. Each input is uniquely formatted or processed portion.

I summarized the user inputs in the following items:

- New Caller Life Line Object Name (Average).- Select an existing caller life line object (Average). - New Callee Message Life Line Object Name (simple).- Return Message Option Selected (Average).- New Activation option selected (Average).- Select an existing callee message life line object (Average).

User Outputs

Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, analysis screens, error messages, and so on. Individual data items within a report are not counted separately.

I summarized the user inputs in the following items:

- Generated Caller Life Line Element (Average).- Generated Callee Life Line Element (Average).- Generated Message between caller and callee (Complex)- Generated Return Message from callee to caller (Average).

External Interfaces

The data that is shared with other programs like personal file might be used by HR for promotion & pay roll. Thus, it would be considered an interface in both the systems. All machine-readable interfaces (e.g. data files on tape or disk) that are used to transmit information to another system are counted. There are no external interfaces for this system.

The only external interface the program has to interact with UML Visual Paradigm API (Complex).

64

Files

Each major logical group of user data or control information related to application. They may be one part of a large database or a separate file. If an actual file contained 100 entries of personal data it would probably be counted as one file. However, if the file contained personal data, department summary data and other department data, it would probably be counted as 3 separate files for counting function points. For this application No File processing is required.

Function Point Unadjusted Value:

To calculate the FP unadjusted value, the total weights for each function point should be calculated according to the following table:

Note: The scale for each item is taken from the book of Software Engineering by Roger Pressman - Fig 4.5 pg 90, fifth edition.

Item Simple Average Complex TotalInputs 3*(1) 4*(5) 6*(0) 23

Outputs 4*(0) 5 *(3) 7*(1) 22Inquiries 3*(2) 4*(2) 6* (0) 14

Files 7*(0) 10 *(0) 15*(0) 0Interfaces 5*(0) 7*(0) 10(1) 10

Total 69

From the table above, we conclude the value of FP unadjusted is (UFP) = 69.

To calculate the value of function point adjusted, the value of the product complexity should be obtained from the following table, that estimates the use of the following software features in the intended application by a scale from 0 (not important) to 5 ( heavily used). The summation of all values will be the complexity factor.

Note: this table is considered after looking into several MSE project from former MSE students.

65

Features Complexity Weight

1 Is the code designed to be reusable?5 3

2 Are conversion and installation included in the design? 3 2

3 Is the system designed for multiple installations in different organizations?

2

4 Is the application designed to facilitate change for ease of use by the user?

5

5 Does the system require online data entry? 0

6 Does the online data entry require the input transactions to be built over multiple screens or operations?

0

7 Are the master files updated on-line? 0

8 Are the inputs, outputs, files, or inquiries complex? 3

9 Is the internal processing complex? 5

10 Does the system require reliable backup and recovery? 0

11 Are data communications required? 0

12 Is performance critical? 3

13 Will the system run in an existing, heavily utilized operational environment?

1

Total 24

Product Complexity Adjustment (PC) =

∑FP unadjusted *[.65 + (0.01 * Product Complexity Factor)] = 0.8

66

Total Adjustment Function Points (FP) = UFP * PC = 0.8 * 69= 55.2

To estimate the total number of lines of source code, the following formula is used:

Source Lines of Code (SLOC) = FP * Language Factor. Since Java is going to be the development language for this application, then the language factor is estimated to be = 38. Therefore:

SLOC = 55.2 * 38 = 2097

Based in Pressman book – mentioned earlier – the programmer productivity for an application program is given as follows:

Programmer Productivity (PM) = 2.4 * (KDSI) ^ 1.05, where the KDSI is determined from the value of SLOC as 2.097. Therefore:

Person Productivity (PM) = 2.4 * 2.097^1.05 = 5.2 person-month.

Also from the same source the development time can be estimated for an application program, as follows:

Development Time (TDEV) = 2.5 *(PM)^0.38 = 2.5 * 5.2 ^ 0.38 = 4.9 months

Note: The results of this cost estimation is not 100% realistic and accurate and that is due to the reason that this project is not an industrial project that is done under business environment in which the numbers provided for the cost estimation model is based on. For this project there are other considerations and limitations that come along its academical nature, such as the fact that only one student is developing the project where he or she can be occupied with other courses, projects and assignments. That is why in my cost estimation I increased the complexity of some function points that led to 5.0 months and 6.3 person-months. I believe that if this project is done under business environment the total time and effort can be cut in half.

4. Gantt Chart

67

68

Software Specification Using OCLThis following is an OCL specification for the Analyzer part of the plug-in. Check Appendix A for more information about the Analyzer and the analysis rules.

enum AggregationType{AGGREGRATIONKIND_AGGREGATION,AGGREGATIONKIND_COMPOSITED,AGGREGATIONKIND_NONE}class IModelElementend

Class Diagram Modelclass IClassDiagramUIModelend

class IClass < IModelElement

attributesclassID:StringclassName:String

operationsgetAllFromEndAggregationsAndCompositionsToClasses():Set(IClass)=self.classFromAssociationEnd-> select (a|a.type=#AGGREGRATIONKIND_AGGREGATION or a.type=#AGGREGATIONKIND_COMPOSITED).toClass->asSet

// This operation is used to generate the transitive aggregation set for a // given class For example if A aggregate to B and B Aggregate to C // then the operation for class A will generate the set {B,C}transitiveAggregation(s:Set(IClass)):Set(IClass)=if s-> includesAll (s.getAllFromEndAggregationsAndCompositionsToClasses())then selse transitiveAggregation(s-> union (s.getAllFromEndAggregationsAndCompositionsToClasses())->asSet)

endifendclass IOperation < IModelElementattributesname:StringreturnType:Stringendclass IParameter < IModelElementattributesname:Stringtype:Stringend//This Association is Used for Aggregation

69

class IAssociationEndattributestype:AggregationTypeend

class IRelationendassociation classDiagramClasses between

IClassDiagramUIModel[1] role classDiagramIClass[1..*] role classesendassociation classesOperations betweenIClass[*] role associatedClassIOperation[*] role classOperationsend

association operationsParameters between

IOperation[*] role associatedOperationIParameter[*] role operationParametersendassociation classesFromAssociationEnd between

IClass[1] role fromClassIAssociationEnd[*] role classFromAssociationEndendassociation classesToAssociationEnd between

IClass[1] role toClassIAssociationEnd[*] role classToAssociationEnd endassociation fromToAssociation between

IAssociationEnd[1] role currentAssociationEndIAssociationEnd[1] role oppisiteAssoicationEndendassociation classesFromRelationship between

IClass[1] role relationFromClassIRelation[*] role allFromClassRelationshipEndassociation classesToRelationship between

IClass[1] role relationToClassIRelation[*] role allToClassRelationship

70

end

Sequence Diagram Modelclass IMessage < IModelElementattributesname:StringId:Stringindex:Integer

operations// This operation will check if all the intermediate classes exist and there are some messages // that are going between these intermediate classes before sending the current message // ( for more details about why this operation is needed check rule 3 page 5 )./intermediateClassesDependencyFound(s:Set(IClass),aggSet:Set(IClass),currentMes:IMessage) : Boolean =

if currentMes.sequenceDiagram.associatedMessages->exists(m| (s->includes(m.fromEnd.baseClass)) and (aggSet->includes(m.toEnd.baseClass)) and (m.index < currentMes.index) and (m.toEnd.baseClass = currentMes.toEnd.baseClass) ) then true

else if aggSet.getAllFromEndAggregationsAndCompositionsToClasses()->asSet->isEmpty then false

else intermediateClassesDependencyFound(aggSet, aggSet.getAllFromEndAggregationsAndCompositionsToClasses()->asSet,currentMes)

endifendif

endclass IInteractionLifeLine < IModelElementattributesname:StringId:String

71

Endclass IInterActionDiagramUIModelendassociation seqDiagramMessages betweenIInterActionDiagramUIModel[1] role sequenceDiagramIMessage[*] role associatedMessagesendassociation seqDiagramLifeLines between

IInterActionDiagramUIModel[1] role sequenceDiagramIInteractionLifeLine[*] role associatedLifeLinesendassociation messageFromEnd between

IMessage[1] role associatedFromMessageIInteractionLifeLine[1] role fromEndendassociation messageToEnd between IMessage[1] role associatedToMessageIInteractionLifeLine[1] role toEndendassociation lifeLineBaseClass between

IInteractionLifeLine[1] role lifeLineIClass[1] role baseClassend

Constraints//1-- Message Should correspond to Direct or Indirect Association

context message:IMessage

inv messageCorrespondToDirectOrIndirectAssociation:

message.fromEnd.baseClass.classFromAssociationEnd->exists(a|a.toClass->includes(message.toEnd.baseClass))ormessage.fromEnd.baseClass.allFromClassRelationship->exists(r|r.relationToClass->includes(message.toEnd.baseClass))ormessage.fromEnd.baseClass.transitiveAggregation(message.fromEnd.baseClass.getAllFromEndAggregationsAndCompositionsToClasses())->includes(message.toEnd.baseClass)//2-- If message correspond to indirect association, then all intermediate classes //between sender and reciever must exist for at least one valid path

72

context message:IMessage

inv intermediateClassesExistForAllIndirectAssociation:

message.fromEnd.baseClass.classFromAssociationEnd->select(a|a.toClass->includes(message.toEnd.baseClass))->isEmptyandmessage.fromEnd.baseClass.allFromClassRelationship->select(r|r.relationToClass->includes(message.toEnd.baseClass))->isEmptyandmessage.fromEnd.baseClass.transitiveAggregation(message.fromEnd.baseClass. getAllFromEndAggregationsAndCompositionsToClasses())->includes(message.toEnd.baseClass)

impliesmessage.intermediateClassesDependencyFound(message.fromEnd.baseClass->asBag->asSet, message.fromEnd.baseClass.getAllFromEndAggregationsAndCompositionsToClasses(),message)//3--If Message corresponds to indirect Association and intermediate classes exist, then the sender // object / must have a reference to receiver object either by a pre outgoing message with a return // type of receiver or by an ingoing message with a parameter passes as receiver.context message:IMessage

inv senderHasReferenceOfReceiverForIndirectASsociation:

//Check if the message corresponds to indirect Associationmessage.fromEnd.baseClass.classFromAssociationEnd->select(a|a.toClass->includes(message.toEnd.baseClass))->isEmptyandmessage.fromEnd.baseClass.allFromClassRelationship->select(r|r.relationToClass->includes(message.toEnd.baseClass))->isEmptyandmessage.fromEnd.baseClass.transitiveAggregation(message.fromEnd.baseClass. .getAllFromEndAggregationsAndCompositionsToClasses())->includes(message.toEnd.baseClass)

implies// If Message corresponds to indirect association then check // if there is a pre message in which:message.sequenceDiagram.associatedMessages->exists(m| message.index<m.index and (

// 1.a pre message sender is the same as current message sender and// the return type of the message is the same as the class name

73

(m.fromEnd = message.fromEnd and

m.toEnd.baseClass.classOperations->select (op|op.name = message.name).returnType->asSet->includes(message.toEnd.name))

or//1.b pre messate receiver is the same as the current message sender and//the message has at least one parameter of type of current messate receiver. (m.toEnd = message.fromEnd and

m.toEnd.baseClass.classOperations->exists(op|op.operationParameters.type->asSet-> includes(message.toEnd.name)))))

74

Test Plan1 Test Plan Identifier

SDE_SDG_1.0

2 Introduction

This test plan is based on the standard guidelines from IEEE 829-1998.

2.1 Objectives A system test plan for the Sequence Diagram Generator should support the following objectives:

Identify which features of the system will be tested and those that will not be tested.

Specify the testing approaches that will be used during testing Define the pass/fail criteria for each item to be tested Define any suspension criteria and subsequent resumption techniques Identify the deliverables of the testing process

2.2 BackgroundSequence Diagram Generator is a plug-in application to help design engineer to

develop reliable and consistent sequence diagram by selecting sequence diagram objects and messages through the class model. The plug-in will also guide the user through the sequence diagram to make the right decision for selecting a sequence message by using some analysis based on the classes associations.

2.3 ScopeThis test plan covers a full functional test of the GPCS.

2.4 ReferencesThe following documents were used as sources of information for the test plan:

SDE Software Requirements Specification (GPCS_SRS_1.0).IEEE Standard for Software Test Documentation (IEEE Std 829-1998)

75

2.5 Definition & abbreviations

SDG: Sequence Diagram Generator. CD: Class Diagram. SD: Sequence Diagram.

The following naming convention is used when referencing a test case.

3 Test Items

This test will cover all the items that make up the SDG. Specifically, all items listed in the SRS will be tested. The following documents will provide the basis for defining correct operation:

MES Project Vision Document. SDG Software Requirement Specification. GUI Prototype.

4 Approach

Only functional black box testing will be performed to test the functionality of this plug-in. The test features describe how the user will interact with the tool, so the testing will require the tester to interact with the system in the same way a typical user would. To simulate a typical user’s actions a set of Pre Conditions will be created which describe a set of actions to take in order to achieve a desired result (Post Conditions). Each scenario will trace back to a requirement listed in the Vision Document 1.0.

CS_SDG_01

Feature Tested.(Caller/Callee Selection)

Plug-in Abbreviation

Associated Number

76

5 Features to be tested

Sequence Diagram Creation Related Features. Caller Selection Related Features. Callee Selection Related Features. Analyzer Related Features. SDG Editing Related Features.

Note: You can check the test cases in details in the Assessment Evaluation. The test cases are removed from this section to prevent redundancy.

6 Features not to be tested

SDE Visual Paradigm UML tool functionalities. SDE UML Visual Paradigm Plug-in Architecture.

7. Item Pass/Fail CriteriaTest cases executed on SDG Plug-in will pass if they meet the

specific requirements as mentioned in the Vision Document. A test case will fail if any of the test case post conditions did not satisfy, or usability of the tested functionality is not met.

8. Suspension Criteria and Resumption Requirements

8.1. Suspension CriteriaIf a test case fails, testing will be suspended for all dependent features. The failed test case will be logged into a test log along with a description of the failure.

8.2. Resumption RequirementTest cases not dependent on the case in which a bug is

reported will continue to be executed in parallel to bug fixing. Testing for the failed test case will resume after the bug has been identified and resolved.

77

9. Test Deliverables

9.1 Test LogThe Test Log will document all test cases and record if the test

case passed or failed. A test case that fails will have the reasons for failure and suggested solutions documented.

Inspection Plan

1. Introduction

The purpose of this section is to provide a checklist for the technical inspectors of Sequence Diagram Generator Plug-in. The checklist will be used to document the items which are to be inspected. The checklist will help the technical inspector to inspect the documents. The goal of the technical inspection is to aid the developer in checking for correctness and consistency with the architectural design and formal specification documents.

2. Items to be inspected

2.1. Class Diagrams

Sequence diagrams Class descriptions

2.2. Formal Specification USE model

3. Formal Technical Inspectors

Judy Dizon Patrick Gallagher

78

4. Formal Technical Inspection List

Inspection Item Pass/Fail/Partial Comments1. The symbols used in the class diagrams conform to UML standards.

2. The classes in the class diagrams have a corresponding description provided in the Architecture Design document.

3. The description of the classes in theArchitecture Design document are clear and adequate

4. The symbols used in the sequence diagrams conform to UML standards

5. The sequence diagrams are clear and understandable.

6. The multiplicities in the USE model are reflected in the Class diagram

7. Classes in the Architecture Design (Class Diagram) correspond to classes in the USE model

8. All model elements and relationships as outlined in the Requirement specification (Section 1.2 & 1.5) are addressed in the Architecture Design document as classes & operations in the class diagram.

79


1. Introduction

This section shows the testing results performed on the sequence diagram generator plug-in, based on the testing plan created in the second phase. Each test case will be applied by satisfying the given pre-conditions, and if the plug-in response match the test case post-condition, then the test will be passed, otherwise it will fail. The failed then will be addressed with reason of failure and the solution to the problem.Note that each test case or a group of test cases will correspond to requirement in the software requirement document.

2. Testing Results:

The following test cases table is based on the test plan built for the second phase, each test case consist of test ID, the test case, Pre-condition, post condition and testing result marked as passed or failed.

2.1 Sequence Diagram Creation Related Features (SRS 1.2.1)Test Case Pre Conditions Post Condition Result

SD_SDG_A Create new SD No CD Generate Error Message PassSD_SDG_B Create new SD CD with No Classes Generate Error Message FailSD_SDG_C Create new SD CD with classes Prompt user for SD name

and actor NamePass

SD_SDG_D Create SD with no SD name provided

No text provided in the SD name field

Show error message Pass

SD_SDG_E Create SD with no SD name provided

No text provided in the SD actor name field

Show error message Pass

SD_SDG_F Create SD with SD name and actor name

Text provided for SD name and actor field.

New SD created and Actor object with the provided names

Pass

SD_SDG_G Create new SD. SD diagram already Generate Error Message Fail

80

created

2.2 Caller Selection Related Features (SRS 1.2.3.1):

ID Test Case Pre Conditions Post Conditions Result

CS_SDG_1 Select Caller Menu Item

No CD & SD Select Caller Menu Item Disabled

fail


CD with no classes. No SD

Select Caller Menu Item Disabled

Pass


CD with classes but no class selected. No SD


pass


CD with classes, class selected and No SD


pass


CD with classes, no class is selected and SD is created.

Show error message pass


CD with classes, class is selected and SD is created.

Show caller Dialog Box: Existing Caller is disabled, return message is disabled.

pass

CS_SDG_7 Create New Caller

CD with classes, class is selected and SD is created. No object name is provided.

Generate Error Message Pass

CS_SDG_8 Create New Caller

CD with classes, class is selected and SD is created. Object name is provided.

Create new SD life line with the name provided.Show SD.

Pass

CS_SDG_10 Select Existing Caller

CD with classes, class is selected and SD is created. Life Line of the same selected class is already created.

The New caller is internally set to the existing life line object, and nothing visually changes.

Pass

CS_SDG_11 Select Existing Caller, New Activation is not Set.


Caller activation information is set internally. No Visual Effect.

Pass

CS_SDG_12 Select Existing Caller, New Activation is not Set.


Caller activation information is set internally. No Visual Effect.

Pass

CS_SDG_13 Select Existing Caller, New Activation is Not Set.

CD with classes, class is selected and SD is created. Life Line of the same selected class is already created.The new selected Caller has been invoked by a message sent from other life line object with a return message.

The new caller will have new activation line even if this option was not set from the caller dialog. The selected callee operation will be created as a message going from the caller to callee. The activation line of the callee and the return message will depend on the

Pass

81

Select Callee Message. options set from the callee dialog

2.3 Callee Selection Related Features (SRS 1.2.3.2)


CS_SDG_13 Select Callee Menu Item

No CD & No SD Select Callee Menu Item Disabled

Fail


CD with no classes. No SD

Select Callee Menu Item Disabled

Pass


CD with classes but no class operation selected. No SD


Pass


CD with classes, class selected and No SD


Pass


CD with classes, no class operation is selected and SD is created. Caller is not selected.


Pass


CD with classes, class operation is not selected and SD is created. Caller is already selected

Show Error Message. Pass


CD with classes, class operation is selected and SD is created. Caller is already selected

Show Callee Selection Dialog.

Pass

CS_SDG_20 Create New Callee. No New Activation. No Return Message

Callee Dialog is showing. No Existing life line object of type of the selected operation class. New object name is not given.

Show Error Message. Select Existing Callee object must be Disabled.

Pass

CS_SDG_21 Create New Callee. No New Activation. No Return Message

Callee Dialog is showing. No Existing life line object of type of the selected operation class. New object name is given.

Create New Life Line object with a given name, and a message name as the selected operation name going from the caller to the created life line. New Activation Line must be show for the created life line.

Pass

CS_SDG_22 Create New Callee. No New Activation. Return Message is Set.


Create New Life Line object with a given name, and a message name as the selected operation name going from the caller to the created life line. New Activation Line must be show for the created life. Return Message should be

Pass

82

going from the created life line back to the selected Caller.

CS_SDG_23 Create New Callee. New Activation is Set. Return Message is Set.


Create New Life Line object with a given name, and a message name as the selected operation name going from the caller to the created life line. New Activation Line must be show for the created life. Return Message should be going from the created life line back to the selected Caller.

Pass

CS_SDG_24 Select Existing Callee life line object. No Return Message or New Activation is Set.

Callee Dialog is showing. An Existing life line object of the same type of the selected operation class is listed.

New message is created between the existing callee and the selected caller. The same activation line is extended for the selected callee to include the new message. Caller Activation line will depend on the selection made in the Caller Selection Dialog.

Pass

CS_SDG_25 Select Existing Callee life line object. Return Message is Set. No New Activation is Set.


New message is created between the existing callee and the selected caller. If the message has a return value New Return Message is created going from callee to caller, otherwise no return message will be created. The same activation line is extended for the selected callee to include the new message and return message. Caller Activation line will depend on the selection made in the Caller Selection Dialog.

Pass

CS_SDG_26 Select Existing Callee life line object. Return Message is Set. New Activation is Set.


New message is created between the existing callee and the selected caller. New Return Message is created going from callee to caller. New activation line is created for the selected callee to include the new message and return message. Caller Activation line will depend on the selection made in

Pass

83

the Caller Selection Dialog.

CS_SDG_27 Select Existing Callee life line object. Return Message is Set. New Activation is Not Set.

Callee Dialog is showing. An Existing life line object of the same type of the selected operation class is listed. The selected life line object already has message invoked with a return message.

New message is created between the existing callee and the selected caller. New Return Message is created going from callee to caller. New activation line is created for the selected callee to include the new message and return message. Caller Activation line will depend on the selection made in the Caller Selection Dialog.

Pass

CS_SDG_27 Create Callee message from actor

No Caller is selected Yet. Select Class operation as a callee message. Select Create message from actor pop up menu item. Enter callee object life line name

A message from the sequence diagram actor to the callee life line object is created.

Pass

2.4 SDG Editing Related Features (1.2.4)ID Test Case Pre Conditions Post Conditions Result

CS_SDG_40 Undo Last Selection Item

No CD. No SD Menu Item Is Disabled. Pass


CD created. No SD Menu Item Is Disabled. Pass


CD created. SD created but no Caller or Callee selected.

Menu Item Is Disabled. Fail


CD created. SD created. New Caller life line object is created.

Enabled. The created life line object will be deleted. The SDG menu item is set to re select the new caller and select new callee will be disabled.

Pass


CD created. SD created. Caller is set to an existing life line object.

Enabled. Caller will be reset internally and no visual effects taking place. The SDG menu item is set to re select the new caller and select new callee will be disabled.

Pass

84


CD created. SD created. New Callee life line is created with new activation line.

Enabled. The new callee life line object is deleted. The created message is also deleted, and if there is a return message it will be also deleted. The new activation is going to be deleted.The SDG will be set to select new Callee and the select caller will be disabled.

Pass


CD created. SD created. Callee is selected using an existing life line and last activation line.

Enabled. The created message is also deleted, and if there is a return message it will be also deleted. The activation line will be shortened. The SDG will be set to select new Callee and the select caller will be disabled.

Pass

CS_SDG_47 Undo Last Sequence Item

No CD. No SD Menu Item Is Disabled. Pass


CD created. No SD Menu Item Is Disabled. Pass



Menu Item Is Disabled. Fail


CD created. SD created. Caller is Selected.

Menu Item Is Disabled. Pass


CD created. SD created. New Callee life line is created with new activation line. Caller is set to new life line object.

Enabled. The new callee life line object is deleted. The created message is also deleted, and if there is a return message it will be also deleted. The new created caller life line will also be deleted.

Pass


CD created. SD created. New Callee life line is created with new activation line. Caller is set to an existing life line object.

Enabled. The new callee life line object is deleted. The created message is also deleted, and if there is a return message it will be also deleted. If the caller is set to have new activation line, the activation will be deleted, other wise it will be shortened to the last message.

Pass


CD created. SD created. Callee is set to an existing life line with new activation line. Caller is set to an existing life line object.

Enabled. The created message is will be deleted, and if there is a return messages it will be also deleted. The new activation line will be deleted. If the

Pass

85

caller is set to have new activation line, the activation will be deleted, other wise it will be shortened to the last message.


CD created. SD created. Callee is set to an existing life line using last activation line. Caller is set to an existing life line object.

Enabled. The created message is will be deleted, and if there is a return messages it will be also deleted. Callee activation line will be shortened to last message. If the caller is set to have new activation line, the activation will be deleted, other wise it will be shortened to the last message.

Pass

CS_SDG_56 Redo Last Selection

No CD. No SD Menu Item Is Disabled. N/I


CD created. No SD Menu Item Is Disabled. N/I



Menu Item Is Disabled. N/I

CS_SDG_59 Redo Last Selection.

CD created. SD created. Caller is Selected by an existing life line object then Undo Last Selection is selected.

Enabled. The caller is internally reset. No Visual effects. The SDG menu item is set to re select the new callee and select new caller will be disabled.

N/I


CD created. SD created. Caller is Selected by creating new life line object then Undo Last Selection is selected.

Enabled. The caller life line will be redrawn with new activation line. The SDG menu item is set to re select the new callee and select new caller will be disabled.

N/I


CD created. SD created. New Callee life line is created with new activation line, and then Undo Last Selection is selected.

Enabled. The new callee life line object is redrawn. The deleted message is also redrawn, and if there is a return message it will be also redrawn. With new activation line.The SDG will be set to select new Caller and the select callee will be disabled.

N/I


CD created. SD created. Callee is selected using an existing life line and using last activation line.

Enabled. The callee is reset to the pre selected life line object. The previous activation line will be

N/I

86

Then Undo Last Selection is Selected.

extended for the new message, and the message is redrawn, and if there is a return message it will be also deleted. The SDG will be set to select new Callee and the select caller will be disabled.

CS_SDG_64 Redo Last Sequence Item

CD created. No SD Menu Item Is Disabled. N/I





CD created. SD created. Caller is Selected.



CD created. SD created. New Callee life line is created with new activation line. Caller is set to new life line object. Undo Last Selection Is Selected

Enabled. The new callee life line object will be redrawn. Caller life line will be redrawn. The message going from caller to callee will also be redrawn, and if there is a return message it will be also redrawn.

N/I


CD created. SD created. New Callee life line is created with new activation line. Caller is set to an existing life line object, and then Undo last sequence is selected.

Enabled. The new callee life line object is redrawn. The created message is also redrawn, and if there is a return message it will be also redrawn. If the caller is set to have new activation line, the activation will be redrawn, other wise it will be extended to the new message.

N/I


CD created. SD created. Callee is set to an existing life line with new activation line. Caller is set to an existing life line object, and then Undo Last Sequence is selected.

Enabled. The new message is redrawn, and if there is a return message it will be also redrawn. The new callee activation line will be redrawn. If the caller is set to have new activation line, the activation will be redrawn, other wise it will be extended to the new message.

N/I


CD created. SD created. Callee is set to an existing life line using last activation line. Caller is set to an existing life line object, and then Undo Last Sequence is selected.

Enabled. The new message is redrawn, and if there is a return message it will be also redrawn. Callee activation line will be extended to the new message. If the caller is set to have new activation line,

N/I

87

the activation will be redrawn, other wise it will be extended to the new message.

2.5 Analyzer Related Features (SRS 1.2.5)


CS_SDG_100 Enable Analyzer No CD. No SD Disabled FailCS_SDG_101 Enable Analyzer CD created, No SD Disabled FailCS_SDG_102 Enable Analyzer CD & SD created. Enabled, Reset the icon to

Disable the analyzer next time its clicked.Show information message that analyzer is activated.

Pass

CS_SDG_103 CS_SDG_8 Pre Cond.Analyzer is Enabled

CS_SDG_8 Post Cond.All Classes that the created caller can interact with are in blue and the ones that can’t, will be grayed.

Pass

CS_SDG_104 No Direct Association

Create class A. Create Class B.Create operation in Class B.Select A is a Caller.

CS_SDG_8 Post Cond.Class B will be grayed.

Pass

CS_SDG_105 Direct Association.

Create class A. Create Class B.Create operation in Class B.Create Association from A to B.Select A is a Caller

CS_SDG_8 Post Cond. Pass

CS_SDG_106 No Indirect Association

Create class A. Create Class B.Create Class CCreate operation in Class B.Create operation in Class C.Create Aggregation from A to B.Create Association from B to C.Create new caller from A.Create callee from B.Select Caller A from existing life line.

CS_SDG_8 Post Cond.CS_SDG_19 Post Cond.CS_SDG_21 Post Cond.CS_SDG_10 Post Cond.C class will be grayed.

Pass

CS_SDG_110 No Indirect Create class A. CS_SDG_8 Post Cond. Pass

88

Association Create Class B.Create Class CCreate operation in Class B.Create operation in Class C.Create Aggregation from A to B.Create Aggregation from B to C.Create new caller from A.Create callee from B.Select Caller A from existing life line.

CS_SDG_19 Post Cond.CS_SDG_21 Post Cond.CS_SDG_10 Post Cond.C class will be grayed, because there is no reference from to C in A.

CS_SDG_107 Intermediate Classes not Found

Create class A. Create Class B.Create Class CCreate operation in Class B.Create operation in Class C.Create Aggregation from A to B.Create Aggregation from B to CCreate new caller from A.

CS_SDG_8 Post Cond.CS_SDG_10 Post Cond.B will be grayed.

N/I

CS_SDG_108 No Class Reference

Create class A. Create Class B.Add new operation to B with no return type or parameters.Create Class CCreate operation in Class C.Create Aggregation from A to B.Create Aggregation from B to CCreate new caller from A.Create callee from B.Select Caller A from existing

CS_SDG_8 Post Cond.CS_SDG_19 Post CondCS_SDG_21 Post Cond.CS_SDG_10 Post Cond.C will be grayed.

Pass

CS_SDG_109 Indirect Association + Class Reference are satisfied.

Create class A. Create Class B.Create Class CAdd new operation to B with a return type of Class C.Create operation in Class C.Create Aggregation from

CS_SDG_8 Post Cond.CS_SDG_19 Post CondCS_SDG_21 Post Cond.CS_SDG_10 Post Cond.B and C will be in blue.

Pass

89

A to B.Create Aggregation from B to CCreate new caller from A.Create callee from B.Select Caller A from existing

3. Failure Evaluation:The following table will address the test cases that are failed, by trying to explain

the reason of failure, the criticality of the failure, how each failure will be resolved, besides total number of line of code required to resolve the problem. Note that some test cases are not implemented – Noted by N/I –, because the corresponding requirement has not implemented in the last plug-in release. These test cases won’t be considered failed. Note that I could not find an efficient solution for some of the failure because of some limitation in the plug-in architecture itself, these cases will be annotated with Not Resolved (N/R) under the LOC of column.

4. Testing Summary

The test preformed in the assessment evaluation is done based on the test plan proposed on the second phase of the project. Total of 78 test cases were performed, in which 8 of the test cases failed. Some of the failed test cases were fixed and the code has been updated to confirm to the fix, however total of 4 of the 8 failed test cases are not going to fixed for the current release due to time limit and plug-in architecture limitation that makes the fix time consuming besides it may cause some change in the architecture design, that is will they will remain unresolved for this release. Through the given numbers , Defect Removal Efficiency can be calculated as follows:

DRE = E/(E+D), where E total number of errors , D error that remained unfixed, so based in the numbers mentioned above DRE = 8/(8+4) = .67 = 67%.

90

Project Evaluation1. Introduction

This section will evaluate the software process and the delivered product. The software process will be evaluated using the time log to measure the productivity and time distribution between the different components. Line of code will be also measured and estimated, then compared the actual size. The delivered product will be evaluated based on its usefulness and checked if it fulfills the idea presented in the requirements and the project vision. Graphs and diagram will be provided to clarify some numbers resulted from evaluating both process and delivered product. At the end of the document there will be a list for the challenges encountered during the process and how each challenge is handles. A list of learnt things will be also provided, besides a list for what can be added to make the plug-in more practical and useful.

2. Process Evaluation

The process followed for developing this plug-in is by iteration. There were three iterations for this process, where each iteration contributed in maturing the product and the documentations that come along. The first phase was for requirement analysis and process planning. The second process is more for architecture design using UML, and providing an executable prototype the covers some features for all the requirements mentioned in the software requirement specification. The last phase is used to insure the quality in the developed product by stabling the architecture design, testing the code and finalizing the documentations with commented source code.After each phase, there will be some action items requested from the committee, where time was assigned to document each action item and the way it was addressed.

2.2 Expected Time vs. Actual TimeThe following table compares the time expected start and finishes time to the actual start and finish time with the total number of days for each phase.

The following chart summaries the data in the previous table in graphical way:

Phase Expected Start Time

Expected Finish Time

Total days

Actual Start Time

Actual Finish Time

Total days

91

1 January 14th, 2005

April 15th, 2005

91 January 14th, 2005

April 15th, 2005

91

2 May 1st, 2005 June 20th, 2005

51 August 16th, 2005

Nov. 1st, 2005

77

3 June 22ed, 2005

July 21st, 2005

29 Nov 8th, 2005

December 5th, 2005

26

From the table and the graph above, we calculate the percentage of error between the expected and actual # of days for each phase, as follows:

Phase 1 Error % = 0% (Exact Estimate). Phase 2 Error % = (77-52)/52 = 48% (Under Estimate). Phase 3 Error % = (26-29)/29 = -10% (Over Estimate).

2.2 Phases Break Down

The following Doughnut graph shows the process phases break down. This graph uses two doughnut charts, the internal chart used for the general phases break down, and the external shows tasks break down for each phase. The doughnut chart is very interesting when comparing the whole process and the different tasks in different phases.

92

2.3 Phase 1 Tasks Break Down

The following is a pie chart for the first phase tasks break down, each sector is assigned task name, number of hours and the percentage.

93

Research, 0, 0%

Documentaion, 15, 56%

Presentation, 9, 33%

Design, 3, 11%

Research

Documentaion

Design

Coding

Testing

Presentation


The following is a pie chart for the second phase tasks break down, each sector is assigned task name, number of hours and the percentage.

Coding, 156, 58%Design, 32, 12%


Research, 13, 5%


ResearchDocumentaionDesignCodingTestingPresentation

94


The following is a pie chart for the final phase tasks break down, each sector is assigned task name, number of hours and the percentage.


Design, 0, 0%Coding, 26, 17%

Testing, 41, 26%


Research, 4, 3%Research

Documentaion

Design

Coding

Testing

Presentation

2.6 Estimated Development Time vs. Actual

The COnstructive COst MOdel ( COCOMO ) model was used in the software project plan document to estimate the development for this project, and it was found to be 5 months. From the time log posted on my web page, it was found that total time calculated from summing all the days spent on each phase is close to 4 months , starting from August 16th, 2005 to December 5th, 2005. The productivity varies from each phase. The following diagram shows the productivity given in hours/day for each week during the last two phases. Note that phase one is not included because there was a big time gap between working on the first phase and the second phase, besides phase 1 was a very small phase in time and in productivity, therefore its not considered as part of this graph.

95

Note that in the August 30th week the productivity was Zero, and that because a serious bug was found in the tool plug-in architecture that might have jeopardize the whole project, therefore a contact was initiated to the developer of the VP-SDE tool to fix the bug, and It took almost a week to fix the bug and get a reply with the new release.

The increase of productivity at the end phase to almost 8 hours was reasonable compared to the estimated time, since the estimated time (close 5 months) is based on the assumption of productivity of 4 hours/day. 3 months are almost consumed by the first and the 2ed presentation, so based on the estimation 2 months are left, however 1 month is left for the fall semester, therefore to compensate for the that period of time, the productivity must be almost doubled, and that explains the 8 hours productivity at certain time in phase 3 compared to the 4 hours/day productivity in phase 1 and 2.

3. Delivered Product EvaluationsThis Section will discuss the final product of this project, which is the plug-in tool

developed for the VP-SDE software. The line of code (LOC) will be compared between the estimated and the actual value. At the end of this section, the learnt lessons from the overall software engineering project beside a future work will be addressed.

3.1 Line of Code EvaluationThere are two ways for estimating the LOC, one is top-down estimates using the

COCOMO model, and another is bottom-up using the architecture design developed for this project.

96

3.1.1 Top-Down LOC Estimate

COCOMO model was used estimate the LOC based on the function point calculation. For more information about the calculation please refer to the Software Project Plan document developed in phase 3. The estimates for LOC using this model was found to be equal to 2097 LOC

3.1.2 Bottom-Up LOC Estimate

The class diagram is used for this model, and the calculation is done by predicting each operation LOC for each class.Based on the assumption above, it was found that LOC is equal to 1643 LOCFor this model, it was expected that the estimate will be less than the estimate in the top-down model and even in the actual number, since the class model usually is not complete by not listing all the operations that is going to be part of the class when coding, the reason for this is because the class model usually exposes the important operations only, besides when estimating the operation LOC, its hard to count for all the details and exceptional cases that can sum up to considerable amount of LOC.

3.1.3 Actual Line of Code vs. Estimate

To get an accurate count for the final product line of code, a tool called LOCC is used to count the total LOC for each file, for more information about the tool, click here.Using the LOCC tool it was found that the LOC of the final product is 1905 LOC.

Given the actual LOC and the estimates above, we can calculate the Percentage of Error between the actual the estimate as follows:

- Percentage of Error for the top-down model: (2097-1905)/1907 = 10% (Over Estimate).

- Percentage of Error for the bottom-up model:(1643 – 1905)/1907 = -13% (Under Estimate).

4. Project Challenges- Choosing the suitable development tool:

That was the biggest challenge in the project, which is to find the suitable tool that support writing plug-ins and provide enough material and documentation to learn the plug-in architecture. A lot of time was spent researching and studying different tools until I decided to with Visual Paradigm Smart Development Tool,

97

http://csdl.ics.hawaii.edu/Tools/LOCC/LOCC.html

because it has a simple plug-in architecture with some documentation on how to start the process for writing plug-in.

- Learning Curve:A big time was spent on learning how to write a plug-in for the chosen tool, besides testing the different features and some of API libraries to conclude if the tool fulfills the product requirements and the vision document.

- Plug-in Architecture Limitations:It has been found that the simplicity of creating a plug-in for the VP-SDE tool comes across having a lot of limitation to interact with the tool. Such limitations made it difficult to create the anticipated user interface for the plug-in. For example the only way I found to send information from the tool to the plug-in based on the user action is by selecting menu item or clicking on tool bar icon only, and there isn’t any way to send events through other action, such as mouse actions.

- Bugs in Plug-in API:A lot of bugs where found during the development of the plug-in through using different API classes operations. Some of the bug were crucial and could have jeopardized the whole project, however the tool support people were very helpful in fixing the bugs and sending me new releases with fix after informing them with problem.

- Debugging the Plug-in:Debugging the plug-in was not possible since the VP-SDE tool doesn’t generate any messages or exceptions if there is some kind of run time error, and if that happens; the VP-SDE tool will either not upload the plug-in, or not respond to the user action. Therefore it was hard to trace the source of error.

- Coding vs. Time vs. Documentation vs. Requirements:The amount of documentation required for the MSE project, besides the amount of time available makes really hard to only focus on satisfying all the anticipated plug-in requirements and goals, therefore some of the requirements and functionality were not implemented in the final release.

Its important to mention that despite all the limitations and problems encountered by using the VP-SDE tool, still the important factor for choosing this tool was the simplicity of learning the plug-in architecture which was crucial for developing the anticipated product that achieve the given requirements with available amount of time.

98

5. Lesson Learnt

Overall, the knowledge achieved though this process was great. I have learned a lot in term of the software engineering process and in term of using different software and tools to develop the anticipated product. The three development phases taught me a lot about the software life cycle and how the software evolve through the different phases iterating through analyzing, designing and developing the prototype until the final product is delivered. Some software engineering concepts and methodologies were used to verify, measure and estimate the overall process, such as the COCOMO model, which made the process more challenging and interesting at the same time, in order to achieve the goals for the used concepts. A lot of skills were also gained from writing the different documentation for this projectA lot of tools were used to develop this plug either for coding or documentation purposes. The following is a list of some of the used tools:

- Eclipse IDE 3.1 Compiler.- Eclipse Java-doc feature.- Eclipse Jigloo plug-in for GUI Builder.- Visual Paradigm Smart Development Environment.- Visual Paradigm Plug-in Architecture and API.

6. Future Work

Despite that the sequence diagram generator is not 100% complete, still I found it very interesting way to connect different UML diagrams together and make them consistent, and this idea can be extended and applied to other diagrams, such as collaboration diagram, activity diagram…etc. There is a lot of potential to improve the current product by adding new features to make the tool more interactive, such as suggesting solutions to the user when he/she is trying to invoke a message from a class that has no association with the caller class; providing a way to add predicates or iterations for the generated messages; synchronizing the class and the sequence diagram information when changing message name or creating object of new class type….etc.The current plug-in architecture probably is not powerful enough to support such features, however this architecture is going through a lot of development and changes and hopefully later releases will be dynamic enough to support such features.

99

User Manual1. Introduction

This document will guide the user into how to install the tool and how to use it. Some images will be added to clarify the description and to give the user some feeling about how to use the tool in coincide with the Visual Paradigm Smart Development Environment (SDE) Tool.The document will be divided into two sections; the first section will explain the installation process with mentioning the software requirement needed to run the plug-in. The second section will describe how the tool itself works, and the user can take advantage of its features to generate reliable sequence diagram that is consistent with the class model.Please Note that because the plug-in is built over a community edition of the VP-SDE, some limitations will be involved, such as; the tool will only handle one class and one sequence diagram, and doesn’t support multiple of sequence diagrams generations using multiple class diagrams. It should be mentioned that the community edition only support one diagram creation of each diagram type. More limitation will be found at the end of this document.

2. Software Installation & Plug-in Setup

This section will cover the software installation and the steps to setup the plug-in as part of the VP-SDE tool.

3. Software RequirementsIn order to use this plug-in, the user has to have to following software installed:

1- VP-SDE: Visual Paradigm Smart Development Environment. This software can be downloaded from the following link:http://www.visual-paradigm.com/product/sde/Please note that SDE is not free software. However you can download a free community edition that doesn’t provide all the features and the capabilities included in the commercial one, besides user can download a time limited version for the commercial that will expires after one month. Note also when installing the SDE software the installation wizard will prompt the user to select the IDE software that the SDE will be part of , since SDE tool can be integrated with different IDEs. For example if you want to integrate the SDE will Eclipse IDE, you check the option that has eclipse IDE, if you don’t want to integrate just check the box for Visual Paradigm for UML, as in the following image:

100


Figure 2

After that, the wizard will prompt the user to select the version. If you decided to go with the free version, then select the community edition, as in the following image:

Figure 3

101

Note that if the user has selected to integrate the SDE as part of an IDE, then the wizard will prompt the user to enter the valid path for the given IDE. Also you have to have valid license key for integrating the tool with each IDE, besides the license key for the SDE tool itself, this can be obtained from the same website.

The last step before starting the installation is to prompt the user to provide the license key file. Initially the user won’t have any license key, and so you can proceed without providing any file path, as in the following image:

Figure 4

After installing the SDE tool, the user can find the installed tool under the program files. The first time the user will run the SDE tool, it will prompt the user for the license key as in the following image:

102

Figure 5

To download a valid license key, the user must click on the “Request Key” button at the top left corner of the frame at noted in the figure 4. After that the tool will open a web page under the visual paradigm link, where the user will be requested to provide an email that the license key file will be sent to.An email will be sent to you with valid license key attached. Download the license key, and re open the SDE tool. When the license key popup again click on the “Import License Key” tool bar icon located beside the “Request Key” button. After that you have to specify the location for the license key file and confirm. See figure 5. At this point you will have valid license to use the SDE tool, and you can use the tool after closing the license frame:

103

Request License Key file.

Figure 6

After installing the VP-SDE tool successfully, running the tool from the program file should look like the following image:

Figure 7

104

Project/Diagrams File structure. Diagram Pane.

Messages Pane

Import License Key File tool bar icon

After importing the license key, it must be added to this list.

The tool is straight forward easy to use for drawing different UML diagrams, for more information about how to use the tool it self and how to take advantage of the different features please review the help menu. Documenting how to use the VP-SDE tool will be out of the scope for this user manual. To learn more about the tool itself, you can view the user manual under the following link:http://www.visual-paradigm.com/documentation/sdejavauserguide.jsp?format=pdf

2- Java 1.4.2 or later version (http://java.sun.com):

The Java virtual machine may be needed to run the plug-in in the VP-SDE tool, since plug-in classes will be stored in the SDE directory - as the user manual will explain ahead – and JVM will be needed in this case to run the classes from the SDE tool.

4. Integrating the plug-in into the VP-SDE tool

To integrate the sequence diagram generation plug-in into the VP-SDE too please follow the following steps:

1- Download the plug-in Zip file called SequenceDiagGenerator.zip from the following link:www.cis.ksu.edu/~ssaleh/mseproject.htm , the file can be found under the Third Presentation section of the page. Check the source files.

2- Unzip the downloaded file. You will find a directory called “seqDiagramGenerator.plugin.id”, this the directory that contains the plug-in files and other directories needed by the plug-in. The following image describe the file structure inside the plug-in directory. This file structure should be followed for all plug-ins created for the VP-SDE tool. Please note that the image below shows the file structure for another plug-in called “sample.plugin”, but the sequence diagram generator plug-in follow the same structure:

105

http://www.cis.ksu.edu/~ssaleh/mseproject.htm

http://java.sun.com/j2se/1.4.2/download.html

http://www.visual-paradigm.com/documentation/sdejavauserguide.jsp?format=pdf

Figure 8

For more information about how to write the plug-in, and the plug-in files structure, go to the following link:http://www.visual-paradigm.com/documentation/pluginuserguide.jsp?format=pdf

3- After Unzipping the SequenceDiagGenerator.zip file, copy the seqDiagramGenerator.plugin.id to the “[home_directory]\ VP Suite 2.1\plugins\” directory, where [home_directory] is the local directory in which the VP-SDE tool is installed. Note that if there is no plug-in directory, the user has to create one.

At this point the plug-in must be setup correctly to know, and to test that, you can re open the VP-SDE tool, and it should look almost the same, however new tool bar icons and popup menu items should be created, as in the following image:

106


Figure 9

5. Using the Plug-in

The plug-in goal is to help the user to create a reliable sequence diagram, that is consistent with the given class model. To achieve this goal, the tool allow the user to create sequence diagram life line objects and messages through clicking on classes and operations inside the classes to determine the life line objects and the messages of the sequence diagram.

In order to start generating the sequence diagram by clicking on the start generating tool bar icon – as will be explained below – there should be a valid opened class diagram, otherwise an error message will pop up to indicate that you have to create or open a class model before generating the sequence diagram.The message sender life line object in the sequence diagram is referred to as the caller , and the object that the invoked by a message is called the callee. To generate the sequence diagram the user has to follow the current generation state of the plug-in to select either the caller or the callee. For example, initially the user has to select caller life line object by selecting a given class in the class model, after that the user has to select the message through selecting an operation inside a class in the same class diagram, by doing that , the message and the callee life line object will be determined, and so on.

107

Enable/Disable Analyzer tool bar icon

Start new sequence diagram generator

Sequence Diagram Generation tool Popup menu item.

Undo/Redo Sequence diagram generation step.

The following steps, describe in details how to start this process and to select the different caller/callee consequently. Please note that you have to have a class model to start generation of the sequence diagrams.

5.1 Generating sequence diagram without the analyzer tool

This section will describe in steps how to generate the sequence diagram of a given class model, without enabling the analysis tool. The class model used in the steps is built for a library system.

1- Create New Sequence Diagram: To start generating the sequence diagram, the user must click on the “Start Converting CD to SD”, where CD refers to Class Diagram and SD refers to Sequence Diagram. After clicking on this tool bar icon the user will be prompted to enter sequence diagram and actor name, as the following image shows:

Figure 10

After providing the sequence diagram name and the actor name new sequence diagram will be created with an actor life line, as in the following image:

108

Start Converting CD to SD tool bar icon

Figure 11

Note that the “Convert CD to SD” tool bar icon has changed to , and can be used to if the user has decided to delete the generated sequence diagram. If so, the plug-in will prompt the user to confirm the deletion, and if confirmed the sequence diagram will be deleted and plug-in state will go to the initial state.

2- Generating a caller life line object:To generate a caller life line object in the sequence diagram, the user has to select a class in the class model that the caller life line object will be type of, after the selection, the user has to right click on the mouse to view the popup menu. The user then must select the “Generate Sequence Diagram” popup menu item to view the submenu, in which “Select Caller” sub popup menu item can be selected, as in the following image:

109

Figure 12

Note that to select a caller a class should be selected first; otherwise the select caller sub popup menu item will generate an error message. In Figure 11 the class “LibraryUI” was selected. After selecting a class and clicking on the “Select Caller” in the popup menu, new dialog bow will appear to prompt the user to provide some information for the generated life line object. Through this dialog the user can either select to create new life line object by giving it new name, or selecting an existing one if there exist any of the same class type that has been created before. Figure 12 shows snap shot of this dialog with notes added to explain every item in the dialog.

110

Figure 13

The message activation option is used to indicate that this message is independent of the previous messages or calls. By default the activation line will be extended from the previous message to mean that both messages belong to the same functionality, except for the first message, where new activation line must be created, and for few cases such as when there is a return message before the new generated message, and that is to prevent the asynchronous behavior in the sequence diagram, which means that the same function can’t be still running even after returning a value from the previous message, by sending or receiving new message. The tool is smart enough to figure out these cases.

After selecting the new caller from the dialog box in figure 12, new life line object will be created – in this case – as in the following image:

111

Option 1: Create New Caller Life Line

Option 2: Select an existing life line object if there is any.

Create New Activation Line option

Generate Return message (Disabled for the Caller)

Life Line Object class type.

Figure 14

3- Generating Callee Message:

After selecting the new caller, its time to select the callee message by selecting an operation inside a given class in the class model, and then mouse right clock on the selected operation to generate the pop menu item, and do the same step as in selecting the caller, as Figure 11 shows. Notice that the “Select Caller” popup menu item is disabled this time, because the caller is already selected, and only the “Select Callee “ is enabled, as in Figure 14:

112

New Caller Life Line Object

Figure 15

After clicking on the “Select Callee Message” , the same dialog box in Figure 12 will show to prompt the user to either create new callee life line object by providing the new name, or re selecting pre created life line object of the same class type to invoke the message. The only difference this time is that, the “Generate Direct Return Message “check box will be enabled.The following image show the new created callee life line object – in this case – in the sequence diagram:

Figure 16

Note that if the “Generate Direct Return Message “box is checked, a return message will be created following the created message, only if the chosen

113

operation has a return type and not set as void, because if its set as void , the return message won’t be created even if the “Generate Direct Return Message “ option box is checked.

4- Generate Message from the Actor Life Line:

This step can be done parallel to selecting the caller as appear in figure 11. The user has the option to select new caller, or generate a message from the actor life line, since the caller in this case is the actor, then the user has to select the operation to be the message sent from the actor. The same thing applies in this case as in the case of selecting the callee. The user has to select an operation in class, where the operation is the message and the class is the callee life line. After selection this option, the same dialog that appears in figure 12, will be displayed to create the new callee by providing the new name, or by selecting pre existing life line object of the same class type. The new generated message will look like the following image:

Figure 17

Usually this step is done in the beginning of generating the sequence diagram, since each sequence must be invoked by an external user or system, before starting the sequence of the internal messages. The tool is also dynamic to allow this kind of message to be done even in the middle of a sequence to allow more flexibility for the user and for the generated sequence diagram.

114

This will conclude this section for using the tool without enabling the analyzer feature. The following section will describe the benefits of using the same steps mentioned in this section to generate the sequence diagram, but with enabling the analyzer feature.

5.2 Generating sequence diagram using the analyzer tool

The purpose of the analyzer in this plug-in is to analyze the available class model based on classes associations to determine for a selected caller class, which classes can be invoked from the caller. There are two main rules for deciding if a class can be invoked from a caller or not. The first rule suggests that to invoke a class, the caller class must have direct or indirect association to the invoked class. The second rule comes after passing the first rule where an indirect association is found, in this case the analyzer will check if the caller class has a reference to the invoked class or not. For more information about the analysis rules, refer to Appendix A in the Software Requirement Specification document.

To enable the analyzer feature, the user must click on the analyzer tool bar icon labeled

as , that comes beside the “Start Converting CD to SD” tool bar icon , as it appears in Figure 8.

Enabling the analyzer won’t make any difference in selecting the caller and the callee message that is covered in section 2.1. The only difference is that when selecting the new sequence diagram caller class in the class model, the analyzer will check all the remaining classes and decides based on the rules mentioned above if each class can be invoked from the caller or not. The classes that can’t be invoked then will be grayed – gray color – and the classes that can be invoked will remain blue. The following image show for an example what happen when selecting the “LibraryUI” class as caller while the analyzer is enable. See figure 17.

115

Figure 18

Notice that only “LibrarySystem” class is enabled, i.e. colored as blue, since there is a direct association between “LibraryUI” and “LibrarySystem”, however the remaining classes are in gray color, indicating that they can’t be invoked from the “LibraryUI” caller. If the user is trying to select a grayed class operation to be as the new message, the plug-in will generate an error message depending on which analysis rule failed, and since there are two analysis rule so far in the plug-in as mentioned previously, therefore there will be two kinds of error message, as shown in figure 18 and figure 19:

Figure 19

116

Figure 20

The analyzer will help the user to create reliable sequence diagram that is consistent with the given class diagram. It incorporate the associations in the sequence to decide what messages can be sent next from the selected caller. This feature in general will motivate users to think more about the software architecture and the usefulness of the class diagram structure.

5.3 Editing the generated sequence diagram:

The sequence diagram generation plug-in allows the user to edit the sequence diagram through Undo/Redo functionality. Its important to note that the plug-in does not recognize if the user has tried to edit the sequence diagram directly, by creating life line objects and messages without using the class model for that, and if that happened, it can cause an expected behavior from the plug-in if the user then try to use it for selecting the new caller/callee, such as overdrawing things, or drawing messages in the wrong location. Editing the sequence diagram directly with out using the plug-in is not allowed for the plug-in. The Undo/Redo popup menu items can be found can be found under the “Generate Sequence Diagram” pop up menu item as in Figure 8.

Due to time limitation the Redo functionality is not implemented in this version of the plug-in, so clicking the “Redo Last Selection” and “Redo Last Sequence” won’t take any action.

There are two types of Undo the user can use to edit the generated sequence diagram, as follow:

1- Undo Last SelectionWhich can used when the user has already selected the caller or the callee and the message. If the previous selection was made for the caller object, then clicking on the “Undo Last Selection” will set the plug-in state for re selecting the new caller. In case of undoing the selected caller, the life line object created for the caller in the sequence diagram will be deleted, if it was newly created, however if when selecting that caller the user decided to go with pre-existing life line object, the object won’t be deleted and there will be no effect on the sequence diagramIn case of undoing pre selected callee, the plug-in state will be reset to select the new callee with the callee message. The old message will be deleted, and if the

117

callee life line was newly created, it will be deleted too, otherwise only the message.The user is allowed only to use this undo action only one. Once its used it will be disabled.

2- Undo Last SequenceCan be used only when the user has generated a complete sequence that consist of caller life line object, callee life line object and the message in between, in other way this action will be enabled each time the user has generated new callee message, and will be disabled when selecting the caller. Clicking on this option when its enabled will delete the message, the caller life line object if new created, and the callee life line object if newly created. The state of the plug-in will be set to select the new caller.

6. Plug-in LimitationThe developed plug-in is not complete, and doesn’t support all the features and

notations of the sequence diagram. Some of the limitations are mentioned below:

- The plug-in supports generating one sequence diagram only.- The generated sequence diagram doesn’t support self sending message.- When using the Plug-in, the user should not edit the sequence diagram

directly except for changing names of the created life line objects, but other than that may create a problem when generating the next life line objects and messages.

- Plug-in Redo functionality is not implemented.- The generated sequence diagram only considers synchronous behavior and

not asynchronous.- The plug-in Works fine under VP-SDE version 2.1 and later, but does not

work properly for earlier version- The plug-in Architecture may change for the coming VP-SDE releases,

and that may not work with the plug-in.

118

References

[1] OMG Group, UML version 2 & 1.5 specification http://www.uml.org/.

[2] Simon Bennett, John Skeleton, Ken Lunn. Schaum’s Online of UML.Copyright, 2001.

[3] Visual Paradigm, Smart Development Environment. http://www.visual-paradigm.com/product/sde/

[4] Visual Paradigm, Smart Development Environment Online Tutorial.http://www.visual-paradigm.com/product/sde/sdejavauserguide.jsp?format=pdf

[5] Visual Paradigm, Smart Development Environment Plug-in Architecture Online Tutorial.http://www.visual-paradigm.com/documentation/pluginuserguide.jsp?format=pdf

[6] Visual Paradigm, Smart Development Environment Plug-in API.http://www.visual-paradigm.com/edocs.jsp?url=content/product/extend/pluginApi/html/index.html&resourceType=document&resourceDetail=pluginUserGuide&preferedSite=http://content.usa.visual-paradigm.com/resources

[7] Sun Microsystems, Java Online Tutorial.http://java.sun.com/learning/tutorial/index.html

[8] Roger S. Pressman, Software Engineering a Practitioner’s Approach. 5th Edition, 2001. http://catalogs.mhhe.com/mhhe/viewNode.do?node_type=c&descr=Computer%20Science&catid=921592 [9] Walker Royce, Software Project Management a Unified Framework.

[10] Sun Microsystems, Javadoc Online Tutorial.http://java.sun.com/j2se/javadoc/

[11] University of Hawaii, LOCC Line of Code Estimation Tool. Version 4.3, 2004http://csdl.ics.hawaii.edu/Tools/LOCC/dist/doc/userguide/userguide.html

119

http://csdl.ics.hawaii.edu/Tools/LOCC/dist/doc/userguide/userguide.html

http://java.sun.com/j2se/javadoc/

http://catalogs.mhhe.com/mhhe/viewNode.do?node_type=c&descr=Computer%20Science&catid=921592

http://catalogs.mhhe.com/mhhe/viewNode.do?node_type=c&descr=Computer%20Science&catid=921592

http://java.sun.com/learning/tutorial/index.html





http://www.visual-paradigm.com/product/sde/sdejavauserguide.jsp?format=pdf


http://www.uml.org/

Appendixes

1. Appendix A

Analyzer Validation Rules

The consistency checking between class diagram and sequence diagram is based on the validity of the send message in the sequence diagram in relative to the relations in class model and/or the predecessor messages in the same sequence.

There are four checks that the message should pass in order to be a valid message and therefore can be implemented in the generated sequence, and they are listed in order with some generic example as follows:

Message Corresponds to direct or indirect Association between Sender and receiver in the class diagram. The figure below is an example of invalid message ( zZZZZZZZ() ) sent from A to Z, since there is no direct or indirect relation in the class diagram between the two classes.

120

Message Satisfies dependency existence for indirect association in the class diagram for at least one path i.e. for all dependent class, there is at least one predecessor path going from the sender class through all dependent classes until the receiver of the current message. The figure below shows an example of class and diagram and sequence diagram, where the sequence diagram violate this rule:

121

Message Satisfies reference existence for indirect association, and that can be met in two ways:

1. For all predecessor messages going out from the sender object, there is at

122

least one message where the return type is the receiver object.

2. For all predecessor messages going in the sender object, there is at least one message where the parameter passed is type of the receiver object.

The figure below shows an example of a class diagram and sequence diagram, where the sequence diagram violates this role. The sequence diagram also show a suggested solution.

123