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:
- 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.
- Completion of Design
Phase and beginning of the model driven software development
approach.
- 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
- The system shall not allow
user to create a communication out of the required context in order to
keep consistency.
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.
- The system shall allow
developers to build communication models based on the CML language in a
graphical environment.
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.
- The system shall
provide functionality for dragging and dropping shape representations of
CML Terminals onto a canvas for composing a sentence, which is a member of
the CML grammar.
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.
- The system shall
provide functionalities for connecting different CML users. But only if
connection is allowed.
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.
- The system shall allow
the following types of communication:
- Voice call
- Instant Messaging
- Video Transmission
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.
- The system shall allow
the execution of the communication model by instantiating the
communication schema.
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.
- The system shall allow
users to save and load communication models to the file system and be able
to display them in the GUI.
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.
- The system shall allow
users to fill in the properties of the terminal shapes.
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 |
|