Florida International University

School of Computing and Information Sciences

 

CEN 5064 Software Design

Section U01 - Spring 2008

Professor: Peter Clarke

April 15, 2008

 

Final Deliverable

 

Rapid Realization of Communication Service Systems

RRComSSys

Team # 1

 

Mark Alison

Drake Campbell

Roberto Espinoza

Yinet Gonzalez

Relmer Perez

Sandeep Varry

 

On

On   On the web courtesy of:

CP   CPC Computer Consultants, Inc. www.cpccci.com


Abstract

 

In this document we present a Rapid Realization of Communication Services System (RRCommSSys). RRCommSSys will be created using model driven software development techniques in an easy to use graphical modeling framework, which will eventually allow us to deploy a communications application employing the features already present in the Skype and Smack API's. In particular we aim to provide audio conversations including conference calling, real time texting and video streaming within the education domain.

We present the architecture, models and testing documentation of our system which includes a User Communication Interface, a Synthesis Engine and a Network Communications Broker. Using a Domain Specific Language (G-CML) we allow the user to create their own communication schema instances by simply dragging and dropping communication objects into a canvas. The system transforms this into executable Java Function calls which delegate the details of the specific case to the appropriate communications platform API.


Table of Contents

Table of Contents________________________________________________________ 3

1. Introduction__________________________________________________________ 6

1.1 Purpose of the System________________________________________________ 6

1.2 Scope of System_____________________________________________________ 6

1.3 Limitations of Current Systems________________________________________ 7

1.4 Design Methodology_________________________________________________ 7

1.5 Definitions, Acronyms, and Abbreviations________________________________ 8

1.6 Overview of Document_______________________________________________ 9

2.  Project Plan_________________________________________________________ 11

2.1 Project Organization_______________________________________________ 11

2.2 Hardware/Software Requirements_____________________________________ 12

2.3 Work Breakdown__________________________________________________ 12

3. Requirement Elicitation and Analysis_____________________________________ 14

3.1 Overview_________________________________________________________ 14

3.2 Functional Requirements____________________________________________ 14

3.2.1 Functional Requirements______________________________________________________ 14

3.3 Non-Functional Requirements________________________________________ 16

3.3.1 Non Functional Requirements__________________________________________________ 16

3.4 System Models_____________________________________________________ 17

3.4.1 Use Case Model_____________________________________________________________ 17

3.4.2    Object Model______________________________________________________________ 17

3.4.3 Dynamic Model_____________________________________________________________ 19

3.4.4 User Interfaces_______________________________________________________________ 20

3.5    Validation of the Analysis Model_____________________________________ 22

3.5.1 Test Cases__________________________________________________________________ 22

3.5.2 Checklist___________________________________________________________________ 37

3.5.3 Structure Use Case Walkthroughs_______________________________________________ 38

4. Proposed Software Architecture_________________________________________ 40

4.1 Package Diagram__________________________________________________ 40

Overview of the Subsystems Used in the Rapid Realization of Communication Services System__ 40

4.1.1 Package Diagram____________________________________________________________ 42

4.2 Metamodel for the DSL______________________________________________ 43

4.3 UML Profile______________________________________________________ 44

4.4 Generative Architecture_____________________________________________ 45

4.5 Subsystems Decomposition___________________________________________ 45

4.6 Validation of the System Model_______________________________________ 48

4.6.1 Check List_________________________________________________________________ 48

4.6.2 Structure Walkthrough________________________________________________________ 49

5. Object Design________________________________________________________ 51

5.1 Minimal Diagrams__________________________________________________ 51

5.1.1 Model Transformation Class Diagram____________________________________________ 55

5.1.2 Synthesis Engine Class Diagram________________________________________________ 56

5.1.3 NCB Class Diagram__________________________________________________________ 57

5.2 Object Interaction__________________________________________________ 58

5.2.1 Sequence Diagrams___________________________________________________________ 58

5.2.2 Statechart for one control object_________________________________________________ 63

5.3 Detailed Class Design__________________________________________________________ 64

5.4 Validation of the Detailed Design Model________________________________ 68

5.4.1 Check List_________________________________________________________________ 68

5.4.2 Structure Walkthrough________________________________________________________ 69

6. Implementation_______________________________________________________ 71

6.1 Description of the platform specific model used.__________________________ 71

6.2 Validation of System________________________________________________ 72

6.2.1 Check List_________________________________________________________________ 72

7. Glossary____________________________________________________________ 74

8. Appendix____________________________________________________________ 75

8.1 Appendix A – Use Case Diagram______________________________________ 75

Use Cases Diagram_______________________________________________________________ 75

8.2 Appendix B – Use cases______________________________________________ 77

Two-Way Audio Creation Use Case__________________________________________________ 77

Two Way Video Model Creation Use Case_____________________________________________ 80

Text Model Creation______________________________________________________________ 83

Use Case for Login_______________________________________________________________ 86

Use Case for Log Out_____________________________________________________________ 88

Two-Way Audio – Execution_______________________________________________________ 90

Video Model Execution____________________________________________________________ 93

Text Model Execution_____________________________________________________________ 96

Use Cases Summary_____________________________________________________________ 105

Nonfunctional Requirements_______________________________________________________ 106

8.3 Appendix C – Class Diagram for the Analysis Model______________________ 108

8.3.1 Minimal Class Diagram______________________________________________________ 108

8.3.2 Model Transformation Layer__________________________________________________ 109

8.3.3 Model Transformation Component Diagram______________________________________ 110

8.3.5 Synthesis Engine Component Diagram__________________________________________ 111

8.3.6 Architecture Diagram________________________________________________________ 112

8.4 Appendix D – Sequence Diagrams____________________________________ 113

8.4.1 System Overview Sequence Diagram____________________________________________ 113

8.5 Appendix E – User Interfaces________________________________________ 114

8.6 Appendix F – Detail Class Diagrams__________________________________ 115

8.6.1 NCB Framework Detailed Class Diagram________________________________________ 115

8.6.2 Synthesis Engine Layer Detailed Class Diagram___________________________________ 116

8.6.3 NCB Layer Detailed Class Diagram____________________________________________ 117

8.7 Appendix G – Class Interfaces_______________________________________ 118

8.8 Appendix H – Project Schedule______________________________________ 188

8.9 Appendix I – Dairy of meeting and Tasks_______________________________ 189

Diary of Meetings and Tasks_______________________________________________________ 189

 


1. Introduction

 

This chapter constitutes and introduction to the Rapid Realization of Communication Services System.  This chapter will cover the purpose of the system, functional and nonfunctional requirements, design methodology, definitions, acronyms, abbreviations, and overview of this document.

 

 

1.1 Purpose of the System

 

The purpose of the system is twofold.  First, the system will use a model-driven approach to create an application that can handle voice and video communication and chat.  All aspects of the programming and engineering of the application will be hidden to the end user; and all the implementation details will be considered only once, when the Rapid Realization of Communication Services has been created.

 

Second, the benefits of the system will be apparent once the system itself has been created and implemented. These benefits include: reduction of communication cost, increase in quality of communication, increase in productivity for all end users, reduction of bottlenecks, and the ability to offer engineers with the latest alternative in the creation of fast and effective applications.

 

The system will be used in the education domain.  It will allow professors to communicate with students, students with professors, and students with students.

1.2 Scope of System

 

The system will target developers of communication models, as well as end users executing the models and the end users interacting with the series of calls made by the first user. The system requires the existence of a Communications Virtual Machine. The program then sits over this machine and performs communication related calls to be executed by it. For the sake of this project Skype and Smack will be used as a replacement for the CVM.  This project of communication is intended to be used by an educational institution where professors can communicate with students, students with professors, and students with students.

 

1.3 Limitations of Current Systems

 

Currently there are many services that provide communication capabilities to users. But, the majority does not offer automated sequence of services. If a developer attends to his needs, he can implement this functionality. Consequently, if this user now needs something else, it becomes very inefficient to constantly change his needs. Rapid Realization of the Communication Services System provides a graphical modeling environment where the developer can implement any kind of communication schema.

 

1.4 Design Methodology

 

We have chosen Unified Software Development Process (USDP) as the model to develop this software.  The main reason for this selection is that USDP is an iterative and incremental process. That is, the current release bears added functionality compared to each prior release. Furthermore, USDP is a use-case driven process in which each iteration takes a set of use cases or scenarios along the path of requirements, implementation, and test and deployment.  Thus, USDP almost guarantees the requirements bound process.

 

Figure 1 Unified Software Development Process

 

 

The approach we are using to develop this software is Model-Driven Software Development (MDSD). MDSD attempts to find domain-specific abstractions and to make them accessible through formal modeling. This approach creates a great deal of potential for automation of software production, leading therefore to increased productivity.  MDSD requires the formulation of models, most of which are developed in the Design Phase, in the form of UML profiles meta models.  UML models represent the software design through the use of class, sequence, package, and component diagrams, and other chart and graphics.  As a result, this approach greatly reduces the complexity of designing from SRAD.

 

1.5 Definitions, Acronyms, and Abbreviations

 

Abstract Syntax – Specifies what the language structure looks like

CML – Communication Modeling Language

Concrete Syntax – Specifies what the parser of the language accepts

CVM – Communication Virtual Machine

DD – Design Document

DOM – Document Object Modeling

Domain – Bounded field of interest or knowledge

DSL – Domain Specific Languages

Formal Model – It is a sentence formulated in the DSL

GEF - Graphical Editing Framework

GMF - Graphical Modeling Framework

MDA – Model Driven Architecture

MDSD - Model Driven Software Development

Meta Meta-Model – It is the meta model of the metal model

Meta-Model – Encompasses the abstract syntax and static semantic of a language

MVC – Model View Controller

NCB – Network Communication Broker

Pipe and Filter – Provides an structure for systems that process a stream of data

RRCS - Rapid Realization of Communication Services

SE – Syntax Engine

Self-Configuration - automatically configuring existing system components and integrating new components

Self-Optimization - automatically tuning resources

SRAD - Structure of the Software Requirement and Analysis Document

Static Semantics – Determines the criteria for well-formation of a language

USDP - Unified Software Development Process

VE - Visual Environment

XML – Extensible Markup Language

XCML – Communication Modeling Language represented in XML

 

1.6 Overview of Document

 

This document presents several more chapters that contain detailed information on the development of Rapid Realization of Communication Service Systems. A brief overview of the information contained is as follows:

 

Chapter 2  details the software architecture, package diagram, meta model for the DSL and UML profile.

Chapter 3 informs on the object design, class diagram, sequence diagram, and detailed class design.

Chapter 4 includes a glossary of domain specific terms

Chapter 5 presents the appendices, use case diagrams, detailed class diagrams, class interfaces, and diary of meetings.

 


 

2.  Project Plan

 

The Project Plan will discuss the fundamental structure of the development plan for the Rapid Realization of Communication Services System (RRComSSys). Such plan outlines the different roles involved in the execution of the project, as well as the requirements for hardware and software essential for the functionality and maintenance of the system; and the milestones and deliverables produced during each stage of the project.

 

2.1 Project Organization

 

The following list displays the roles involved in the RRComSSys project throughout the first, second and third phase of development of the project:

 

Mark Alison -              GUI Design & Implementation,           Eclipse             Graphic Modeling Framework

 Drake Campbell -      Skype API & System Design

Roberto Espinoza -     Documentation & Project Scheduling

Yinet Gonzalez -         Smack API & System Testing

Relmer Perez -            UML Profile, Metamodel, Smack API & System Testing

Sandeep Varry -         System Testing, Sequence Diagram & Skype API

 

 

Leader – Drake Campbell: Responsible for overseeing all project related tasks and making sure the milestones are reached in a timely and effective manner.  The leader manages each of the meetings, and assigns tasks to each member of the group.

 

GMF Developer and Consultant – Mark Allison, Roberto Espinoza: Responsible for developing a project that is reliable, usable and efficient.  The GMF Developer and Consultant designs the Visual Environment class structure, the Eclipse modeling environment that generates the Visual Environment; and addresses any questions regarding the Eclipse GMF.

 

Parse Designer/Programmer Skype Smack Specialist – Yinet Gonzalez, Relmer Perez, Sandeep Varry: Manages the programming with the Skype, Smack API.  Handles the design of the structure of the X-CML parser, and the implementation of the parser.

 

2.2 Hardware/Software Requirements

 

Hardware required

1.     Processor: 2Ghz or faster

2.     Memory: 1GB of RAM

3.     Hard Drive: 80 GB

 

Software required

1.     Windows XP Professional

2.     Microsoft Word

3.     Microsoft PowerPoint

4.     Eclipse

5.     Graphical Editing Framework (GEF)

6.     Graphical Modeling Framework (GMF)

7.     Eclipse Modeling Framework (EMF)

8.     Smack API

9.     Skype API

2.3 Work Breakdown

 

The development of Rapid Realization of the Communication Services System was divided as follows:

 

  1. Completion of Use Case Phase and Analysis Phase: A document specifying all the software requirements by the client is generated, which also covers the Object and Dynamic models.
  2. Completion of Design Phase and beginning of the model driven software development approach. 
  3. Completion of Testing Phase and Entire Project

 

For further detail of tasks please refer to Appendix H that contans the project schedule and Appendix I for a diary of meetings and tasks.

 

 


 

3. Requirement Elicitation and Analysis

 

3.1 Overview

 

The system�s main objective is to allow the communication schemas using a Communication Modeling Language (CML), and in order to accomplish this purpose it aims at using both a user-friendly environment, and a rapid development and deployment. 

 

The CML language can be defined as the grammar that describes the allowed configurations of the communication schemas; and a communication schema, or more specifically, an instance of it, a communication scenario, is executed by a Communication Virtual Machine.  And the user that develops the communication schemas is the CVM developer.  When the CVM end-user runs the communication schema the systems creates an instance with the information provided before during the abstract modeling. It is then, that the system first validates the model ensuring it complies with the CML grammar. Second, the system requests the CVM end-user to provide any missing information before instantiation, such as the participants, capabilities of devices, etc.  Lastly, once the validation and instantiation processes are completed, the sytem executes the appropriate calls to fulfill the communication over the adequate platform.

 

3.2 Functional Requirements

3.2.1 Functional Requirements

 

Use cases: Communication Model Security and Consistency

Constraint: The user of the system must be validated and update of the active member list to check if user is already login on the first attempt.

 

Use cases: All use cases related to Model Creation

Constraint: The system must be implemented using Eclipse GMG and should be executed in less than 5 seconds.

 

Use cases: All use cases related to Create Terminals.

Constraint: The system must present a user-friendly graphical interface with a drag and drop interface for declaring terminals and non-terminals. The drag and drop should be done in less than � seconds.

 

Use cases: All use cases related to Model Creation.

Constraints: The system must implement the constraints of the CML language so that the User is allowed to build only valid CVM communication models.

 

Use cases: All communication types mentioned above. Create voice call communication, create Instant Messaging Communication and create Video Transmission Communication.

Constraints: The communication model is executed by making calls to the Skype and Smack Internet based platform. This communication should be executed in less than 5 seconds.

 

Use cases: All use cases related to Model Execution

Constraints: The validation of the communication schema must be finished in no more than 10 seconds for models having no more than 120 shapes.

 

 

Use cases: All use cases related to Model Execution

Constraints: The system shall save and retrieve data, unless there is an I/O error in the system.  If there is no I/O error in the system, it should be able to save and retrieve data 100% of the time in less than 10 seconds.

 

Use cases: All use cases related to Model Creation

Constraints: The system should not continue unless required data has been input properly.  Three times is the maximum allowed.

 

 

3.3 Non-Functional Requirements

 

3.3.1 Non Functional Requirements

 

Performance:

�       Short response time: In any case or condition response time of application should be as short as possible. On average no longer than 5 seconds.

Usability:

�       Simple to use: Rapid Realization of Communication Service System should provide interface for user to easily access operations that can be learner in 10 minutes.

Reliability:

�       No-Crash: Rapid Realization of Communication Service System should be crash safe in 94% of its runtime.

Supportability:

�       Maintainability: The design of Rapid Realization of Communication Service System functionality should allow for easy maintenance of the system. Adding API only causes the NCB to be re-compiled.

 

 

3.4 System Models

 

The System Models are represented by the Use Case Model, Dynamic Model and Object Model.

 

3.4.1 Use Case Model

 

The Use Case Model, represented by a diagram in Appendix A, shows all the possible actions that a user can perform within the system.  Likewise, both subsystems are depicted in such diagram.

 

                  Object Model

 

 

3.4.2.1 Minimal Diagrams

 

The minimal class diagrams shown will serve as a base reference and may not explicitly show the appropriate level of detail, for a more detailed look we refer the reader to diagram.            Since we are using the layered architecture we will briefly describe the classes involved and their roles. 

 

The Layer class provides a public interface to the functionality hidden inside the core and maintains references to the layers above and below itself in the system.  The Core is responsible for defining the functionality of a Layer.  The Delegate maintains a mapping from system events to function objects in the Core.  The Thread Pool is responsible for the execution of Commands.  Commands are stored and executed at a later point by the ThreadPool.

 

3.4.2.2 Layer Framework

 

There are two design patterns present in the LayerFramework, they are: Template and Command.

�       The Template pattern is used in the Core.  Since the Core is a Thread object whose run loop is final, the steps performed at each iteration are constant and not subject to change.  The user has no way to alter or inject behavior within this cycle of set steps.  The Template pattern is used to alleviate this problem.  We define several methods in the Core that are called in-between critical steps.  The user can now override these methods to perform the desired tasks at the selected times within the run loop.

 

�       The Command pattern is used in ThreadPool.  In order to increase throughput of the system we allow each function object to be executed in its own thread.  Remember that the Core simply defines what the function object does and the Delegate maps these function objects to events in the system.  We need a way to encapsulate the execution of a method to allow for storage and delayed execution.  We use the Command patter to solve this problem.  The Command pattern allows us to decouple the method execution from its invocation.   Commands are created by the Delegate and sent to the ThreadPool for execution, the ThreadPool stores them until the next available thread can execute the Command.

 

3.4.2.3 Model Transformation

 

The next set of classes is in the Model Transformation Layer, they are the: ModelValidator, ModelTransformer, and the CompletionWizard.  The ModelValidator takes as input, a GCML model from the user interface and returns true or false depending on whether or not the model is valid.  The Model Transformer takes as input, a valid GCML model and transforms it into an XCML model.  If information that is required to complete the model is missing, the transformer uses the CompletionWizard to obtain this from the user before completing the model.

 

3.4.2.4 Synthesis Engine Layer

 

The next set of classes is in the Synthesis Engine Layer, they are the: SynthesisMediator and Policies.  The SynthesisMediator takes as input, an XCML model and uses its knowledge of the NCB together with the Policies to create the correct event to execute the communication.  The Policies are simple rules for determining which API to use for which service

 

The next set of classes is in the Network Control Broker Layer, these are packaged together to form the NCBFramework.  The classes in the NCBFramework are the: TwoWayCall, ConferenceCall, TwoWayVideo, VideoBroadcast, TwoWayText, ChatRoom, AbstractFactory, APIChecker, and APIRegistry.  There are Skype and Smack implementations for all of the above classes except the APIRegistry.  The first six classes in the list represent, in an abstract way, the services offered by each API.  The AbstractFactory allows for the creation of different implementations for each service.  The APIChecker packages the factory together with the knowledge required to check if an API is installed and running on a platform.  The APIRegistry stores APICeckers by string names in a HashMap interface for unified retrieval.

 

3.4.2.5 Abstract Factory

 

The third design pattern used in the system is the Abstract Factory.  Since using multiple API�s is a requirement, we would also like to provide a mechanism for switching them at runtime.  It would also be beneficial to future changes in code if we could encapsulate the creation of these objects and hide their types from the rest of the system.  For this we use the Abstract Factor.  First we declared six abstract classes that represented the services we wished to implement and switch across multiple API�s.  By making these classes the types produced by the Abstract Factory, all code dependant on these implementations is no longer concerned with what concrete type are used.  Furthermore we can use subclasses of the Factory to specify a set of objects that must be produced together, more specifically the six services we wish to support for a given API.  This has an added benefit; the factories can now be treated in the same fashion as the services.  That is to say, the code that uses the factory does not need to be concerned with what type of factory it has since the interface remains constant.

 

 

3.4.3 Dynamic Model

 

 

Sequence For an Instance Transformation.

 

This sequence diagram shows the sequence of object involved in the execution of an instance.

 

Sequence For Voice Call.

 

This sequence diagram shows the sequence of object involved in the creation of a voice call model.

 

Sequence For Chat Message.

 

This sequence diagram shows the sequence of object involved in the creation of a chat message model

 

Sequence For Create Connection.

 

This sequence diagram shows the sequence of object involved in the creation of a connection in the modeling environment

 

Sequence For Save File GMF.

 

This sequence diagram shows the sequence of object involved in the saving of a model file

 

3.4.4 User Interfaces

 

Load Request Form

 

This is the form that will first appear when the application is first run.

 

Impute Request Form

 

This is the form that will be displayed if the schema executed is missing some information.

 

Visual Modeling Environment

 

This is what the modeling environment looks like. This is where the communication models will be created.

 


 

  Validation of the Analysis Model

 

3.5.1 Test Cases

 

Test Case Suite 1 – TC1MC001 : Purpose – To test the Two Way Audio Model Creation

 

Test Case ID

TC1MC001_1- Two-Way Audio Creation-01

Path Type

Sunny Day Scenario # 1

Preconditions

The User has opened the modeling environment.

 

Input

The User  selects a shape

The User Drags it on the  on the canvas

Expected Output

The shapes is painted on the Canvas and Properties window appears

 

Test Case ID

TC1MC001_2- Two-Way Audio Creation-02

Path Type

Sunny Day Scenario # 2

Preconditions

The User has opened the modeling environment

 

Input

Drag the teacher shape

Drag and connect a isAttached Shape to Teacher

Drag and connected a Device

 

Expected Output

The shapes appear on canvas and the connections are made.

 

Test Case ID

TC1MC001_3- Two-Way Audio Creation-03

Path Type

Rainy Day Scenario # 1

Preconditions

The User has opened the modeling environment

 

Input

Drag the teacher shape and device shape and try to connect them without using isAttached.

 

Expected Output

Both the shapes are able to attach and no error is shown

 


 

Test Case Suite 2 – TC2MC002 :Purpose – To test the Two Way Video Model Creation

 

Test Case ID

TC2MC002_1- Two-Way Video Creation-01

Path Type

Sunny Day Scenario # 1

Preconditions

The User has opened the modeling environment

The user knows the correct order to connect the shapes

Input

The User  selects a shape

The User Drags Teacher, IsAttached(2),Device(2),Connection, Student and connects them as correctly 

The medium is selected as Voice

Expected Output

The shapes is painted on the Canvas the connection is established and properties are shown to send voice

 

Test Case ID

TC2MC002_2- Two-Way Video Creation-02

Path Type

Sunny Day Scenario # 2

Preconditions

The User has opened the modeling environment

The user knows the correct order to connect the shapes

 

Input

The User  selects a shape

The User Drags Teacher, IsAttached(2),Device(2),Connection, Student and connects them as Incorrectly 

The medium is selected as �video�

Expected Output

The system shows the error message to make the connections correctly

 

Test Case ID

TC2MC002_3- Two-Way Video Creation-03

Path Type

Rainy Day Scenario # 1

Preconditions

The User has opened the modeling environment

The user knows the correct order to connect the shapes

 

Input

The user tries to specify the medium as voice

 

Expected Output

The system does not allow the �video� medium to be selected.

 


 

Test Case Suite 3 – TC3MC003 :Purpose – To test the Two Way Text Model Creation

 

Test Case ID

TC3MC003_1- Two-Way Text Creation-01

Path Type

Sunny Day Scenario # 1

Preconditions

The User has opened the modeling environment

The user knows the correct order to connect the shapes

Input

The User  selects a shape

The User Drags Teacher, IsAttached(2),Device(2),Connection, Student and connects them as correctly 

The medium is selected as Text

The User Saves the File

Expected Output

The File is saved

 

Test Case ID

TC3MC003_2- Two-Way Text Creation-02

Path Type

Sunny Day Scenario # 2

Preconditions

The User has opened the modeling environment

The user knows the correct order to connect the shapes

 

Input

The User  selects a shape

The User Drags Teacher, IsAttached(2),Device(2),Connection, Student and connects them as correctly 

The medium is selected as Text

The User Wants to Change Medium to Voice

Expected Output

The system allows  the user to change the Medium to Voice

 

Test Case ID

TC3MC003_3- Two-Way Text Creation-03

Path Type

Rainy Day Scenario # 1

Preconditions

The User has opened the modeling environment

The user knows the correct order to connect the shapes

 

Input

The user tries to specify the medium as Text

 

Expected Output

The system does not allow the �Text� medium to be selected.

 


 

Test Case Suite 4 – TC4LI004 :Purpose – To test the Login Use Case

 

Test Case ID

TC4LI004_1- Login -01

Path Type

Sunny Day Scenario # 1

Preconditions

User has been assigned a valid API usernames and passwords.

A valid XML model has been created.

API has a working connection

Input

User Enters the Correct  Id  and  Correct Password

User Clicks on the Submit Button.

Expected Output

The user is authenticated and welcome message is displayed

 

Test Case ID

TC4LI004_2- Login -02

Path Type

Sunny Day Scenario # 2

Preconditions

User has been assigned a valid API usernames and passwords.

A valid XML model has been created.

API has a working connection

Input

User Enters a Correct Id  and Wrong Password

Expected Output

The system checks the Id and Password and displays a error message saying Id and Password do not match.

 

Test Case ID

TC4LI004_3- Login -03

Path Type

Rainy Day Scenario # 1

Preconditions

User has been assigned a valid API usernames and passwords.

A valid XML model has been created.

API has a working connection

Input

The User Enters Correct User Id and Correct password

 

Expected Output

The system Checks his Id Password and shows a error message saying that they do not match.

 


 

Test Case Suite 5 – TC5LO005 :Purpose – To test the Log Out Use Case

 

Test Case ID

TC5LO005_1- Log Out -01

Path Type

Sunny Day Scenario # 1

Preconditions

The user is logged into the system

He has closed all his connections

Input

The user clicks on Logout button

Expected Output

The User window is closed and a goodbye message is displayed

 

Test Case ID

TC5LO005_2- Log Out -02

Path Type

Sunny Day Scenario # 2

Preconditions

The user is logged into the system

He has  NOT closed one or more connections

Input

The user clicks on Logout button

Expected Output

The system  prompts the user to terminate the connection and then proceed with logout.

 

Test Case ID

TC5LO005_3- Log Out -03

Path Type

Rainy Day Scenario # 1

Preconditions

The user is logged into the system

Input

The user is logged into the system

He has  NOT closed one or more connections

Expected Output

The User window is closed and goodbye message is displayed

 

 

 


 

Test Case Suite 6 – TCME001 :Purpose – To test the Two-way Audio Execution

 

Test Case ID

TC6ME001_1 - Two-way Audio Execution -01

Path Type

Sunny Day Scenario # 1

Preconditions

A communication model file must be already created and saved.

The user is logged on

Input

The User selects the Open option from the File Menu of the Eclipse IDE

The system asks the User for the file name containing a CVM model to be loaded into a canvas and user enters the File Name

 

Expected Output

The system opens the file specified and loads the CVM model into the IDE canvas and system acknowledges the operation by displaying a message on the status bar of the IDE

 

 

Test Case ID

TC6ME001_2 - Two-way Audio Execution -02

Path Type

Sunny Day Scenario # 2

Preconditions

A communication model file must be already created and saved.

The user is logged on

The Canvas is Loded

Input

After Canvas is loaded appropriate profile information is entered for the local and remote user by the student or teacher.

The user initiates the voice communication by selecting the instance file

Expected Output

The system responds by parsing the file and performing the required Skype and Smack API calls

 

 

Test Case ID

TC6ME001_3 - Two-way Audio Execution -03

Path Type

Rainy Day Scenario # 1

Preconditions

A communication model file must be already created and saved.

The user is logged on

The Canvas is Lodged

Input

After Canvas is loaded appropriate profile information is entered for the local and remote user by the student or teacher.

The user initiates the voice communication by selecting the instance file

Expected Output

The system does not respond.

 


 

Test Case Suite 7 – TCME001 : Purpose – To test the Two Way Video Execution

 

Test Case ID

TC7ME002_1 - Two Way Video Execution -01

Path Type

Sunny Day Scenario # 1

Preconditions

A communication model file must be already created and saved.

The user is logged on

Input

The user will click on the File menu and choose Execute from the UI

The user will select the file to execute from the pop-up dialog

Once the file has been selected the model is parsed to XCML

There is some information missing

Expected Output

The systems prompts the user to enter the missing information

 

Test Case ID

TC7ME002_2- Two Way Video Execution -02

Path Type

Sunny Day Scenario # 2

Preconditions

A communication model file must be already created and saved.

The user is logged on

The Canvas is Loaded

Input

The user will click on the File menu and choose Execute from the UI

The user will select the file to execute from the pop-up dialog

Once the file has been selected the model is parsed to XCML

In user enters the missing information when prompted

Expected Output

The system checks if information entered is  invalid  and the user will be notified and will not be allowed to proceed until it is correct.

 

Test Case ID

TC7ME001_3- Two Way Video Execution -03

Path Type

Rainy Day Scenario # 1

Preconditions

A communication model file must be already created and saved.

The user is logged on

The Canvas is Loaded

Input

All information has been entered and the user clicks on finish button

Expected Output

The system does not respond or make calls to underlying API�s

 


 

Test Case Suite 8 – TCME003 : Purpose – To test the Text Model Execution

 

Test Case ID

TC8ME003_1 – Text Model Execution -01

Path Type

Sunny Day Scenario # 1

Preconditions

A communication model file must be already created and saved.

The user is logged on

Input

The user will click on the File menu and choose Execute from the UI

The user will select the file to execute from the pop-up dialog

Once the file has been selected the model is parsed to XCML

There is some information missing

Expected Output

The systems prompts the user to enter the missing information

 

Test Case ID

TC8ME003_2 - Text Model Execution -02

Path Type

Sunny Day Scenario # 2

Preconditions

A communication model file must be already created and saved.

The user is logged on

The Canvas is Loaded

Input

The user will click on the File menu and choose Execute from the UI

The user will select the file to execute from the pop-up dialog

Once the file has been selected the model is parsed to XCML

In user enters the missing information when and clicks the finish button

Expected Output

The system makes calls to underlying API for text communication

 

Test Case ID

TC8ME003_3- Text Model Execution -03

Path Type

Rainy Day Scenario # 1

Preconditions

A communication model file must be already created and saved.

The user is logged on

The Canvas is Loaded

Input

All information has been entered and the user clicks on finish button

Expected Output

The system does not respond or make calls to underlying API�s

 


 

Summary of the Test Cases.

 

SYSTEM TEST CASES

Test Case ID

Purpose

TC1_MC001

To test the Two Way Audio Model Creation

TC2_MC002

To test the Two Way Video Model Creation

TC3_MC003

To test the Two Way Text Model Creation

TC4_LI001

To test the Login Use Case

TC5_LO001

To test the Log Out Use Case

TC6_ME001

To test the Two-way Audio Execution

TC7_ME002

To test the Two-way Video Execution

TC8_ME003

To test the Two-way Text Execution

 


 

3.5.2 Checklist

 

 

 

Completeness Questions

Yes

No

1

Are all of the actors defined in the model? 

(i.e. Have all other systems, hardware or human users that the system will communicate been described?

X

 

2

Has all of the functionality been described in the model? (i.e. are all of the actors goals that must be fulfilled been described in the use cases?)

 

X

3

Is the output from the system defined for every input from the actor, both for normal flow of events and variations?

X

 

4

Have all of the variants to the normal flow of events been identified in the use cases?

 

X

5

Has the include-relation been used to factor out common behavior?

X

 

 

 

 

 

Correctness Questions

Yes

No

6

Are all of the actors clearly described, and do you agree with the description?

X

 

7

Are all the actors connected to the right use cases?

X

 

8

Is expected input and output correctly defined in each use case?

X

 

9

Are the preconditions and post conditions correctly described for all use cases? 

(i.e. correct level of detail, do the preconditions and post conditions match for each of the use cases, are they testable?)

 

X

 

 

 

 

Consistency Questions

Yes

No

10

Are the descriptions of how the actor interacts with the system in the use cases consistent with the description of the actor?

X

 

11

Do the use case diagram and the textual descriptions match?

X

 

12

Are the descriptions of the use cases consistent with reaching the goals of the use cases? (i.e. Is it clear from the descriptions of the use cases how the goals are reached and do you agree with the descriptions?)

X

 

13

Are all the use cases described at the same level of detail?

 

X

14

Does the behavior of a use case conflict with the behavior of other use cases?

 

X

15

Does each event in the normal flow of events relate to the goal of its use case?

 

X

 

 

 

 

General Questions (Ambiguities, Extraneous Information)

Yes

No

16

Are there any superfluous actors in the model? 

(i.e. human users or other systems that will not provide input to or receive output from the system?)

 

X

17

Is it clear which actors are involved in which use cases? 

(i.e. can the actors involvement in the use cases be seen from the use case diagram and textual descriptions?)

 

X

 

18

Are all use cases within the system boundary?  (i.e.Do all  use cases lead to the fulfillment of a goal for an actor or

duplicate already described functionality) 

 

X

 

19

Are the triggers (i.e. starting conditions) for each use case described at the correct level of detail?

 

X

20

Is the flow of events described at a suitable level of detail without details that restrict the user interface or the design of the

system?

 

X

 

21

Do all the use cases lead to the fulfillment of exactly one goal for an actor, and is the goal clear from the use case name?

 

X

 

 

 

3.5.3 Structure Use Case Walkthroughs

 

Unique ID

Test Results

Comments

TC1MC001_1

PASS

 

TC1MC001_2

PASS

 

TC1MC001_3

PASS

 

TC2MC001_1

PASS

 

TC2MC001_2

PASS

 

TC2MC001_3

PASS

 

TC3MC001_1

PASS

 

TC3MC001_2

PASS

 

TC3MC001_3

PASS

 

TC4LI004 _ 1

PASS

 

TC4LI004  _2

PASS

 

TC4LI004  _3

PASS

 

TC5LO005_1

PASS

 

TC5LO005_2

PASS

 

TC5LO005_3

PASS

 

TC6ME001_1

PASS

 

TC6ME001_2

PASS

 

TC6ME001_3

PASS

 

TC7ME002_1

PASS

 

TC7ME002_2

PASS

 

TC7ME002_3

PASS

 

TC8ME003_1

PASS

 

TC8ME003_2

PASS

 

TC8ME003_3

PASS

 

 


 

 

4. Proposed Software Architecture

 

This chapter takes a high level view of the components in the system.  First we use architectural patterns to decompose the system into subsystems and define their relationships with each other and how they achieve the end goal.  Then we use design patterns to further decompose the subsystems, giving each one its own benefits and potential pitfalls, which we will discuss later.

 

 

4.1 Package Diagram

 

Overview of the Subsystems Used in the Rapid Realization of Communication Services System

 

The first architectural pattern we applied was the Layered architecture.  We use this in two ways.  First we use it to divide the problem statement into several subsystems, each of, which require their own levels of abstraction.  Second, by using the Layered architecture we ensure that the systems layers can be swapped out for alternate implementations and these changes do not have a ripple effect throughout the system.  The system is divided into four layers they are:  the User Interface, Model Transformation, Synthesis Engine, and Network Control Broker.  Each of their functionalities is explained throughout the chapter.  Figure 2.1 shows a package diagram, which can be used as a reference in the discussions that follow.

 

A major portion of the work done by the system is to take the graphical model and turn it into executable code at runtime.  These steps can be broken down into independent parts; we package each part into a layer.  Each layer of the processing phase can be viewed as either a pipe and/or filter.  In the traditional sense, this approach is useful for streaming data; however, the behavior of the system can be closely modeled by this abstraction whereby we replace streams with file handles. 

 

We chose the Pipe and Filter pattern for two reasons.  First we use it to encapsulate each processing step into a Filter and use Pipes to facilitate the flow from a Filter in one Layer to a Filter in another.  For the purposes of decomposition, these patterns compliment each other well.  We make our own implementation variation by allowing each layer to act as an implicit pipe.  Second, we gain a finer granularity of control over the transformation process as a whole.  We can now choose to replace individual filters, reorder them in the filtering process, swap out Layers, or any combination of the above; without changing the rest of the system. 

 

Additionally the communication mechanism between layers is asynchronous and event driven.  By using an event driven model we can gain better performance and response time in the presence of long running processes and make it easier to scale or distribute Layers across multiple servers.  This also means that we can now reduce the scripted execution of methods to the dynamic creation of the correct event; a much simpler task in by comparison and equally as flexible considering a Layer can register and un-register events at run-time.  Although we do not make use of this feature in our system, it is supported by the Layer API.

 


4.1.1 Package Diagram

 

 


4.1 Package Diagram


4.2 Metamodel for the DSL


 

4.3 UML Profile


 

4.4 Generative Architecture

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


TRANFORMATIONS

 

The previous figure presents the transformations to the target platform. Basically, the presentation objects are paired to the Java libraries, which implement the user interface.

 

 

4.5 Subsystems Decomposition

 

The Model Transformation Layer is composed of four subsystems, they are the: Simple Model Validator, Simple Model Transformer, Schema Completion Wizard, and the Transformation Core.  The Simple Model Validator takes, as input, a graphical model that has been piped from the User Interface filters it to the Simple Model Transformer.  The Simple Model Validator job is to return true or false depending on whether or not the model is grammatically correct.  In the cases where the graphical model is missing information the model transformer acts as a Data Sink for the Schema Completion Wizard; which acts as a Data Source and Filter.  The Schema Completion Wizard is classified as a Filter since it contains its own validation logic and can reject user input until it is corrected.  The Schema Completion Wizard is also a Data Source since it takes user input.  Once all the information is gathered the transformation proceeds until completed.  The Model Transformer turns the GCML into XCML and the Model Transformation Core Pipes the file handle to the Synthesis Engine.

 

The Synthesis Engine is composed of three subsystems, they are the: Simple Synthesis Mediator, Simple Policy Manager, and Synthesis Core.  The XCML is piped the Simple Synthesis Mediator from the Model Transformation Core.  The Simple Synthesis Mediator parses it and uses the Simple Policy Manager to help determine which events to add to the NCBCore.  It is called a mediator because it does just that; it knows about the events defined in the NCBCore and encapsulates this knowledge together with the knowledge of the Policies.  The Simple Policy Manager contains methods that take as input a string and the number of participants and returns a string representing the API to make the call on  The Simple Synthesis Mediator adds the correct events to the NCBCore for execution. 

 

The Network Control Broker Layer (NCBL) is composed of four main components, they are the: Abstract Factory, API Registry, API Checker, and NCBCore.  The NCBCore acts as a Pipe and a Data Sink.  It is a Data Sink for the information contained in the events that result in the execution of calls and a Pipe since it facilitates transport of information in and out of the Layer.  The other three components that the NCBCore uses come from the NCBFramework.  All calls implemented by the system are classified by six types.  There is one implementation per API for each of the six types.  We use the Abstract Factory to help manage the extra classes.  The Abstract Factory provides an interface for creating each of the six communication objects.  In turn there is a concrete factory for each API implemented.  The API Checker is used to determine if the API is installed on the system, running, and to retrieve its corresponding Abstract Factory.  That means there is also a concrete API Checker for Each API.  To simplify access all API Checkers are stored in a Registry by a string name.  We can now ask the registry for the �Skype� API Checker, check if it is installed, running, get its factory, and make call implementation objects all at runtime.

 

Each Layer is created using the Layer Framework.  The Layer Framework contains four components, they are the: Layer, Core, Delegate, and Thread Pool.  The Layer acts as a container for the Core.  It also contains references to two other Layers and an Event Queue.  The Core is responsible for defining the functionality of the Layer; which it does in the form of Function Objects (Functors).  Each Core has a Delegate.  The Delegate maintains a mapping between events and Functors.  Each Delegate contains a Thread Pool.

 


 

4.6 Validation of the System Model

 

4.6.1 Check List

 

 

 

Completeness Questions

Yes

No

1

Are all of the actors defined in the model? 

(i.e. Have all other systems, hardware or human users that the system will communicate been described?

X

 

2

Has all of the functionality been described in the model? (i.e. are all of the actors goals that must be fulfilled been described in the use cases?)

 

X

3

Is the output from the system defined for every input from the actor, both for normal flow of events and variations?

X

 

4

Have all of the variants to the normal flow of events been identified in the use cases?

 

X

5

Has the include-relation been used to factor out common behavior?

X

 

 

 

 

Correctness Questions

Yes

No

6

Are all of the actors clearly described, and do you agree with the description?

X

 

7

Are all the actors connected to the right use cases?

X

 

8

Is expected input and output correctly defined in each use case?

X

 

9

Are the preconditions and post conditions correctly described for all use cases? 

(i.e. correct level of detail, do the preconditions and post conditions match for each of the use cases, are they testable?)

 

X

 

 

 

Consistency Questions

Yes

No

10

Are the descriptions of how the actor interacts with the system in the use cases consistent with the description of the actor?

X

 

11

Do the use case diagram and the textual descriptions match?

X

 

12

Are the descriptions of the use cases consistent with reaching the goals of the use cases? (i.e. Is it clear from the descriptions of the use cases how the goals are reached and do you agree with the descriptions?)

X

 

13

Are all the use cases described at the same level of detail?

 

X

14

Does the behavior of a use case conflict with the behavior of other use cases?

 

X

15

Does each event in the normal flow of events relate to the goal of its use case?

 

X

 

 

 

 

General Questions (Ambiguities, Extraneous Information)

Yes

No

16

Are there any superfluous actors in the model? 

(i.e. human users or other systems that will not provide input to or receive output from the system?)

 

X

17

Is it clear which actors are involved in which use cases? 

(i.e. can the actors involvement in the use cases be seen from the use case diagram and textual descriptions?)

 

X

 

18

Are all use cases within the system boundary?  (i.e.Do all  use cases lead to the fulfillment of a goal for an actor or

duplicate already described functionality) 

 

X

 

19

Are the triggers (i.e. starting conditions) for each use case described at the correct level of detail?

 

X

20

Is the flow of events described at a suitable level of detail without details that restrict the user interface or the design of the

system?

 

X

 

21

Do all the use cases lead to the fulfillment of exactly one goal for an actor, and is the goal clear from the use case name?

 

X

 

 

 

4.6.2 Structure Walkthrough

 

 

Unique ID

Test Results

Comments

TC1MC001_1

PASS

 

TC1MC001_2

PASS

 

TC1MC001_3

PASS

 

TC2MC001_1

PASS

 

TC2MC001_2

PASS

 

TC2MC001_3

PASS

 

TC3MC001_1

PASS

 

TC3MC001_2

PASS

 

TC3MC001_3

PASS

 

TC4LI004 _ 1

PASS

 

TC4LI004  _2

PASS

 

TC4LI004  _3

PASS

 

TC5LO005_1

PASS

 

TC5LO005_2

PASS

 

TC5LO005_3

PASS

 

TC6ME001_1

PASS

 

TC6ME001_2

PASS