Florida International University
School of Computing and Information Sciences
CEN 5064 Software Design
Section U01 - Spring 2008
Professor: Peter Clarke
March 25, 2008
Design Document
Rapid Realization of Communication Service Systems
RRComSSys
Team # 1
Mark Alison
Drake
Campbell
Roberto
Espinoza
Yinet
Gonzalez
Relmer Perez
Sandeep Varry
On On the web courtesy of:
CP CPC Computer Consultants, Inc. www.cpccci.com
Abstract
The purpose of this document is the design of a Rapid Realization of a Communication Service System upon which all decisions regarding the Rapid Realization of a Communication Service System shall be made. This document will show the specific methodologies and patterns used in the systematic design of such a Rapid Realization of a Communication Service System. Furthermore, this document displays the results obtained by providing a very representative view of the system from a design stand point. This document will answer, through the decomposition of the purpose, proposed architecture, and object design, all relevant questions regarding the design of a Rapid Realization of a Communication Service System.
Table of Contents
Table of Contents................................................................................................................ 3
1. Introduction.................................................................................................................... 5
1.1 Purpose of the
System............................................................................................... 5
1.2 Functional and
Nonfunctional Requirements............................................................ 5
1.2.1 Functional
Requirements............................................................................................ 5
1.2.2 Non Functional
Requirements..................................................................................... 7
1.3 Design Methodology.................................................................................................. 8
1.4 Definitions,
Acronyms, and Abbreviations................................................................ 9
1.5 Overview of
Document............................................................................................ 10
2. Proposed Software
Architecture................................................................................... 11
2.1 Package Diagram.................................................................................................... 11
Overview of the
Subsystems Used in the Rapid Realization of Communication Services System... 11
2.1.1 Package Diagram..................................................................................................... 13
2.2 Metamodel for the
DSL........................................................................................... 14
2.3 UML Profile............................................................................................................. 15
2.4 Generative
Architecture.......................................................................................... 16
2.5 Subsystems
Decomposition...................................................................................... 17
2.5.1 Model Validator
Component Diagram......................................................................... 19
2.5.2 Model Transformer
Component Diagram..................................................................... 20
2.5.3 Schema Completion
Wizard Component Diagram......................................................... 21
2.5.4 Synthesis
Mediator Component Diagram..................................................................... 22
2.5.5 Network Control
Broker Component Diagram.............................................................. 23
2.5.6 Layer Frame Work
Component Diagram...................................................................... 24
3. Object Design................................................................................................................ 25
3.1 Minimal Diagrams................................................................................................... 25
3.1.1 Model
Transformation Class Diagram......................................................................... 29
3.1.2 Synthesis Engine
Class Diagram................................................................................ 29
3.1.3 NCB Class Diagram................................................................................................ 30
3.2 Object Interaction................................................................................................... 31
3.2.1 Sequence Diagram................................................................................................... 31
3.2.2 Statechart for
one control object................................................................................. 35
3.3 Detailed Class
Design............................................................................................... 36
4. Glossary........................................................................................................................ 42
5. Appendix....................................................................................................................... 43
5.1 Appendix A.............................................................................................................. 43
Use Cases Diagram.......................................................................................................... 43
5.2 Appendix B.............................................................................................................. 44
Use Cases Detail............................................................................................................. 44
Two-Way Audio Creation
Use Case.................................................................................... 44
Two Way Video Model
Creation Use Case.......................................................................... 47
Text Model Creation........................................................................................................ 50
Use Case for Login.......................................................................................................... 53
Use Case for Log Out...................................................................................................... 55
Two-Way Audio –
Execution............................................................................................ 57
Video Model Execution.................................................................................................... 60
Text Model Execution...................................................................................................... 63
Employee Authentication.................................................................................................. 64
Attempted login to
Communication System using an existing Employeeid (Security Misuse Case) 66
Use Cases Summary........................................................................................................ 70
Nonfunctional
Requirements............................................................................................. 71
5.3 Appendix C.............................................................................................................. 73
Detailed Class Diagrams................................................................................................... 73
5.3.1 Model
Transformation Class Diagram......................................................................... 73
5.3.2 Layer Frame Work
Class Diagram.............................................................................. 74
5.3.3 NCB Frame Work
Class Diagram.............................................................................. 75
5.3.4 NCB Synthesis
Core Class Diagram........................................................................... 76
5.3.5 NCB Core Class
Diagram......................................................................................... 77
5.4 Appendix D.............................................................................................................. 78
5.5 Appendix E............................................................................................................ 148
Diary of Meetings and
Tasks........................................................................................... 148
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.
1.2 Functional and Nonfunctional Requirements
1.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.
- 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.
- 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 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.
- 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.
- 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.
1.2.2 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.
1.3 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.4 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.5 Overview of Document
The remainder of this document is comprised of several more chapters with detailed information on the development of Rapid Realization of Communication Service Systems.
Chapter 2 presents the software architecture including package diagram, meta model for the DSL and UML profile.
Chapter 3 presents the object design including class diagram, sequence diagram, and detailed class design.
Chapter 4 presents a glossary of domain specific terms
Chapter 5 presents the appendices including use case diagrams, detailed class diagrams, class interfaces, and diary of meetings
2. 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.
2.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.
2.1.1 Package Diagram
2.1 Package Diagram
2.2 Metamodel for the DSL
2.2 Metamodel Class Diagram
2.3 UML Profile
2.3 UML Profile Representing Architecture
2.4 Generative Architecture
The previous figure shows the
transformations carried out to the target platform. Essentially, the
presentation objects are paired back to the Java Swing libraries which
implement the user interface. Similarly, the model creation concepts are
transformed to classes that abstract out the communication model, for example,
the DSL metamodel is transformed to a GMF ecore definition file, which in turn
is fed to the Eclipse GMF target platform. As can also be seen on the figure,
the Data Sink is transformed to a X-CML
model, which complies with the CML language in XML format. This XML file is
later used in the execution of the model by the NCBCore to make the actual call to the Skype and
Smack Libraries, which render the
communication.
2.5 Subsystems Decomposition
The User Interface Layer is composed of two subsystems, they are the: Model Editor and Graphical User Interface. The Model Editor takes user input to produce a graphical representation of the communication model and allows the user to save and load these from disk storage. The Graphical User Interface allows the user to, among other things, pipe this information to the next layer by selecting a menu option.
The Model Transformation Layer is composed of three subsystems, they are the: Model Validator, Model Transformer, and Completion Wizard. Since each layer is an implicit pipe, these three subsystems are classified as Filters. The Model Validator takes, as input, a graphical model that has been piped from the User Interface Layer and filters it to the Model Transformer. See figure 2.5.1. The Model Transformer turns the GCML into XCML. See figure 2.5.2. If information is missing from the model the Completion Wizard takes user input and filters this to the Model Transformer, where it is added to the XCML and finally piped to the next layer. See figure 2.5.3.
The Synthesis Engine is composed of two subsystems, they are the: Synthesis Mediator and Policies. The Synthesis Mediator and the Policies subsystems are also both filters. The XCML is piped the Synthesis Mediator, which filters it using rules enforced by the Policies, into the correct event which is piped to the Network Control Broker Layer. See figure 2.5.4
The Network Control Broker Layer (NCBL) is composed of an API, the NCBFramework, which is discussed in further detail in Chapter 3. The NCBL handles these events by internally executing the, now correctly formulated, communication request using the NCBFramework. See figure 2.5.5.
A picture for the LayerFramework component diagram can be seen in figure 2.5.6. Each Layer is created using this framework as a blue print. Layers are allowed to vary behavior by inheriting, defining, and adding functionality in the derived Core object.
2.5.1 Model Validator Component Diagram
2.5.2 Model Transformer Component Diagram
2.5.3 Schema Completion Wizard Component Diagram
2.5.4 Synthesis Mediator Component Diagram
2.5.5 Network Control Broker Component Diagram
2.5.6 Layer Frame Work Component Diagram
3. Object Design
In chapter 2 we discussed the
application of architectural patterns to decompose the major parts of the
system. In this chapter we take a
closer look at these parts and apply design patterns to refine their roles and
interactions. We will explicitly
state where patterns are used and justify their uses in the context of RRComSys.
3.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 section 3.3. 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.
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.
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.
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. See figure 3.1.2. // (default
package)SynthesisEngineClassDiagram.jpg
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. See figure
3.1.3. // (default package)NCBClassDiagram.jpg
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.1.1 Model Transformation Class Diagram
3.1.2 Synthesis Engine Class Diagram
3.1.3 NCB Class Diagram
3.2 Object Interaction
3.2.1 Sequence Diagram
3.2.1 Sequence Diagram
3.2.2 Statechart for one control object
3.3 Detailed Class Design
In this section we will discuss in more detail the class designs that make up the components of each layer. We start with the LayerFramework.
The LayerFramework consists of the following: Layer, Core, Delegate, LayereEvent, Functor, Command, ThreadPool, and WorkerThread. Each of these classes plays a specific role in creating a reusable framework from which to build layers. See figure 5.3.2 and 5.4.2..
The Layer class is responsible for holding events that are waiting to be processed in addition to keeping track of the Layers above and below itself. The Layer has a reference to the Core and vise versa; however, deleting one will not delete the other. Presently each Layer may only have one Core assigned to it. The Layer uses methods provided by the Core for registration on construction. The most frequently used public method for a Layer is add(), which adds an event to the Layer�s LinkedBlockingQueue. When multiple Layers are combined they form a variation of the chain of responsibility in that adding an event to one Layer does not guarantee its execution in that Layer if at all. Moving these events is the responsibility of the Core.
The Core class spends its lifetime in a run loop, getting events from the layer and processing them. The Core itself does not do the processing. The basic steps that must be performed are the following: enter the run loop, get an event, ask the Delegate if he can respond to it, if he can respond ask him to handle it otherwise send the event up or down, check the termination condition, and finally end the run loop. Because these steps are required the run method of the Core is declared as final. We use the Template method to allow subclasses increased flexibility for injecting code into this �template� process by using call back functions that can be overridden.
The Delegate class maintains a mapping of system LayerEvents to Functors. Additionaly every Delegate contains a ThreadPool, which shares the same lifetime. Core objects contain Delegates and they share the same lifetime. Delegates provide an interface for registering LayerEvents with Functors, which the Core mimics by simply forwarding the method call to the Delegate. When the Delegate is asked to handle() an event it will create a Command object and send it to the ThreadPool.
The ThreadPool class maintains a pool of WorkerThreads. The thread pool starts at a minimum and is allowed to grow to a maximum. Growth is triggered by the number of waiting commands to be executed. The initial set of WorkerThreads are not destroyed until the ThreadPool is shutdown(). The parameters controlling the initial size, max size, and growth can be tweaked on a per-Layer basis to better optimize for short or long running processes.
The Model Transformation Layer contains the: ModelValidator, SimpleModelValidator, ModelTransformer, SimpleModelTransformer, CompletionWizard, SchemaCompletionWizard, Validatable, ValidatePanel, TeacherPanel, StudentPanel, and MediumPanel. This Layer is almost entirely defined from interfaces. See figure 5.3.1 and 5.4.1.
One benefit for doing this is that different instances of the same interface can be swapped for one another without changing the code. The relevant Interfaces are: ModelValidator, ModelTransformer, CompletionWizard, and Validatable. ModelValidatr specifies a single method interface for validating a model. ModelTransformer does the same for how to transform a model. The CompletionWizard provides several methods that the SimpleModelTransformer may need to use to retrieve missing information from the user.
The Validatable interface provides a method for validating information present on ValidatePanels. ValidatePanels are graphic displays that allow the user to enter information; they are interchangeable and know how to validate themselves. Subclasses are used for the specific types of information required and their presentations.
The three main classes that provide implementations for the above are the: SimpleModelValidator, SimpleModelTransformer, and the SchemaCompletionWizard. The ModelTransformationCore will use the SimpleModelValidator to validate a model; if the model is valid the core will then pass the model to the SimpleModelTransformer. The transformer will then proceed to transform the model to XCML. During the process of transformation it is possible to discover that information is missing. When this happened the SimpleModelTransformer will count how much and what type of information is missing, initialize the SchemaCompletionWizard accordingly and wait for completion. Upon completion the SimpleModelTransformer can finish the transformation and the core will notify the SynthesisEngineLayer via a LayerEvent.
The Synthesis Engine Layer contains the following: Synthesizable, PolicyInterface, SimplePolicyManager, and SimpleSynthesisMediator. Synthesizable and PolicyInterface are both interfaces and give this layer the same properties as the Model Transformation Layer, namely interchangeability. See figure 5.3.4 and 5.4.4.
The PolicyInterface contains one method per implemented communication service. The methods all return Strings, the name of the API to use for the service given some parameter as input. The SimplePolicyManager will implement these to make decisions based on things like number of participants or a user�s preference.
The Synthesizable interface contains a method that takes an XCML file as input. The SimpleSynthesisMediator implements this method to add the correct LayerEvents to the NCB Layer. In the true sense of the Mediator design pattern the synthesis mediator encapsulates the knowledge of the events the NCB layer will respond to and how to use the policies to connect the two. Doing this allows the SynthesisEngineCore to remain ignorant of the complex interactions required to perform this task. Additionally if changes are made to the NCB Layer or the Policies this minimizes the ripple effect by reducing it to one class. In fact this is the benefit of using the Mediator pattern.
The last step in the entire process is to execute the communication. The NCBFramework handles all the dirty work, which makes reduces the job of the NCBCore to simply using components. See figure 5.3.3 and 5.4.3.
The NCBFramework contains the following classes: 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 AbstractFactory provides an interface for creating six of the service objects. There are two implementations for the AbstractFactory, one for the Skype family of objects and one for the Smack family of objects. There is a one-to-one correspondence between AbstractFactory for an API and its APIChecker.
The APIChecker contains the methods and implementations required to determine if the particular API is installed and running. It also provides an interface from which to retrieve the corresponding AbstracFactory.
To simplify the packaging and access of these objects APICheckers are stored by a String name in the APICheckerRegistry. It now becomes possible to use the APICheckerRegistry to retrieve an APIChecer for a given API. After the CorrectAPIChecker has been retrieved we can use it to create the correct AbstractFactory. From the AbstractFactory we can create the implementations of the desired services in a piece-meal fashion.
The
largest benefit to this approach is seen by the NBCore which uses this
Framework. The NCBCore only needs
to know about the abstract classes in order to make use of them and adding
additional APIs is easy. To add an
additional API just implement the six service objects, a concrete
AbstractFactory, an APIChecker, and add it to the APICheckerRegistery. The changes stay local and are not
rippled throughout the system.
4. Glossary
Abstract Syntax –
Specifies what the language structure looks like
Concrete Syntax –
Specifies what the parser of the language accepts
Domain –
Bounded field of interest or knowledge
Formal Model –
It is a sentence formulated in the DSL
Meta Meta-Model –
It is the meta model of the metal model
Meta-Model –
Encompasses the abstract syntax and static semantic of a language
Pipe and Filter
– Provides an structure for systems that process a stream of data
Self-Configuration - automatically configuring existing system components and integrating new components
Self-Optimization - automatically tuning resources
Static Semantics –
Determines the criteria for well-formation of a language
5. Appendix
5.1 Appendix A
Use Cases Diagram
Figure A1 Use Case Model. The use cases implemented consist of model creation and execution as well as logging in and out of the system. The actors are the Teachers and Students who may create, execute, and participate in communication schemas.
5.2 Appendix B
All Use Cases have the following pre-condition: the user
needs to login into the system before using it.
Use Cases Detail
Two-Way Audio Creation Use Case
Use Case ID: MC001
Use Case Level: High-level
Scenario: Student or teacher wants to create a model for communication via phone call with two participants: A teacher and a student or two students using RRCommSSys. The developer opens a file for model creation and executes the steps listed in the description of the use case.
Details
Actor(s): Communication Model Developer
Pre-conditions: A new file must be already be opened for model creation
Description
Trigger: The user initiates an action by selecting a shape or terminal and drawing it on the canvas. The system responds by painting the selected shape or terminal on the canvas and showing the properties window.
1. Actor selects the terminal for Participant, drags it onto the canvas and enters the necessary information.
2. Actor selects the terminal for isAttached, drags it onto the canvas, enters the necessary information and connects it to the Participant terminal.
3. Actor selects the terminal for Device, drags it onto the canvas, enters the necessary information and connects it to the isAttached terminal.
4. The first three steps are repeated for the second (remote) participant.
5. Actor selects the terminal for Connection, drags it onto the canvas, enters the necessary information and connects it to both devices created earlier.
6. Actor selects the terminal for Medium, drags it onto the canvas, enters the informamtion necessary for Two-Way_Audio and connects it to the Connection terminal.
Relevant requirements: The actor has an understanding of the model creation process.
Post-conditions: After this use case is performed a communication model has been created to allow a local and remote participant to make a one to one voice connection with no errors.
Alternative Courses of Action: As an extension of this use case, an alternative course of action is to repeat steps 1 through 3 for each extra participant to make a conference call. A different medium could be filled in for the Medium terminal and a different one to one connection could be made, like video for example.
Extensions: This use case is extendend in the conference call use case.
Exceptions: No Exceptions occur in this use case if all terminals have been defined correctly and necessary information filled in by the actor is correct.
Concurrent Uses: Text Messaging, Video connection can be concurrent uses.
Related Use Cases: After the model creation use case is completed the model execution use case that corresponds it is performed.
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: This use will be performed at least once per application use. That is, everytime that that an actor wants to creates a communication model to allow two participants to make a live audio connection. One average this use case will be performed 2-5 times per application use.
Criticality: Its absence may not cause the system to crash, but it may prevent the user from ac�complishing their goal.
Risk: The risk of crashing for this use case is very low to nonexistent.
Constraints:
Each person terminal must and can only connect to (1) isAttached terminal. Each isAttached terminal can only be connected to (1) device terminal. Each device terminal must have at least (1) capability terminal connected to it, and can only connect to (1) connection terminal.
Usability: must be easy to use
Reliability: must always draw the selected terminal or connection.
Performance: must take no longer than 2 seconds to draw the terminal shape or connection selected.
Supportability: - No debug nescesary, simple.
Implementation: must be implemented with Eclipse GMF.
------------------------------------------------------------------------------------------------------------
Modification History – version-1
Owner: Mark Alison
Initiation date: February 12, 2008
Date last modified: February 12, 2008
Two Way Video Model Creation Use Case
Use Case ID: SMC002
Use Case Level: High level
Details
Actor(s): User
Pre-conditions: The User has opened the modeling environment.
Description
1. The User drags a Teacher shape on the diagram canvas by selecting Teacher from the tool box.
2. The User drags an isAttached shape on the diagram canvas by selecting isAttached from the tool box.
3. The User connects these two shapes using the Line shape from the tool box.
4. The User drags a Device shape on the diagram canvas by selecting Device from the tool box.
5. The User connects the Device shape to the isAttached shape using the Line shape from the tool box.
6. The User drags a Connection shape on the diagram canvas by selecting Connection from the tool box.
7. The User connects the Connection shape to the Device shape using the Line shape from the tool box.
8. The User drags a Medium shape on the diagram canvas using the Medium shape from the tool box.
9. The User connects the Medium shape to the Connection shape using the Line shape from the tool box.
10. The User drags a Device shape on the diagram canvas using the Device shape from the tool box.
11. The User connects the Connection shape to the Device shape using the Line shape from the tool box.
12. The User drags an isAttached shape on the diagram canvas using the isAttached shape from the tool box.
13. The User connects the Device shape to the isAttached shape using the Line shape from the tool box.
14. The User drags a Student shape on the diagram canvas using the Student shape from the tool box.
15. The User connects the isAttached shape to the Student shape using the Line shape from the tool box.
16. The User saves the diagram and gives it the name VideoMike.
Trigger: There is no explicit trigger for this Use Case.
Relevant requirements: There are no other relevant requirements.
Post-conditions: User has a complete communication schema saved as VideoMike
Alternative Course of Action: User does not fill out the information related to the Medium, Teacher or Student shapes. The problem is corrected only when User attempts to execute such a schema, by prompting User for the relevant information.
Extensions:
Exceptions: The editor will not allow User to connect shapes in an invalid way.
Concurrent Use: This Use Case can be performed concurrently with all other Use Cases.
Related Use Case: Two Way Video Model Execution Use Case
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: Once every semester
Criticality: This Use Case is 100% critical to the functionality of the system. In the event that Tom is loading schemas from a database the user who created them has completed this Use Case.
Risk: This Use Case has a medium risk level.
Constraints:
� Usability: The model should be intuitive to use for people familiar with drawing models. Drawing the model should take 5 minutes or less.
� Reliability: Mean time to failure 2%
� Performance: The model editor will draw shapes within ½ of a second.
� Supportability: Updates will be released every 6 months.
� Implementation: The model editor should be developed using MDSD
------------------------------------------------------------------------------------------------------------
Modification History – 3rd Revision
Owner: Drake Campbell
Initiation date: 02/01/2008
Date last modified: 02/24/2008
Text Model Creation
Use Case ID: MC003
Use Case Level: High level
Details:
Actor(s): The initiator of the communication, also know as the user.
Pre-conditions: The user has opened the modeling environment.
Description:
1. The user drags a Person shape on the diagram canvas by selecting Person from the tool box.
2. The user drags an isAttached shape on the diagram canvas by selecting isAttached from the tool box.
3. The user connects these two shapes using the Line shape from the tool box.
4. The user drags a Device shape on the diagram canvas by selecting Device from the tool box.
5. The user connects the Device shape to the isAttached shape using the Line shape from the tool box.
6. The user drags a Connection shape on the diagram canvas by selecting Connection from the tool box.
7. The user connects the Connection shape to the Device shape using the Line shape from the tool box.
8. The user drags a Medium shape on the diagram canvas using the Medium shape from the tool box.
9. The user connects the Medium shape to the Connection shape using the Line shape from the tool box.
10. The user drags a Device shape on the diagram canvas using the Device shape from the tool box.
11. The user connects the Connection shape to the Device shape using the Line shape from the tool box.
12. The user drags an isAttached shape on the diagram canvas using the isAttached shape from the tool box.
13. The user connects the Device shape to the isAttached shape using the Line shape from the tool box.
14. The user drags a Person shape on the diagram canvas using the Person shape from the tool box.
15. The user connects the isAttached shape to the Person shape using the Line shape from the toolbox.
16. The user saves the diagram and gives it a name.
Trigger: There is no explicit trigger for this Use Case.
Relevant requirements: There are no other relevant requirements.
Post-conditions: The user has a complete communication schema saved as a flat file.
Alternative Course of Action: The user does not fill out the information related to the Medium, or Person shapes. The problem is corrected only when the user attempts to execute such a schema, by prompting them for the relevant information.
Extensions:
Exceptions: The editor will not allow the user to connect shapes in an invalid way.
Concurrent Use: This use case can be performed concurrently with all other use cases.
Related Scenario: Model Execution
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: Once every semester
Criticality: This use case is 100% critical to the functionality of the system. In the event that the user is loading schemas from a database the person who created them has completed this Use Case.
Risk: This Use Case has a medium risk level.
Constraints:
� Usability: The model should be intuitive to use for people familiar with drawing models.
� Reliability: Mean time to failure 2%
� Performance: The model editor will draw shapes within ½ of a second.
� Supportability: Updates will be released every 6 months.
� Implementation: The model editor should be developed using MDSD
------------------------------------------------------------------------------------------------------------
Modification History – Version 2
Owner: Roberto Espinoza
Initiation date: 02/08/2008
Date last modified: 02/24/2008
Use Case for Login
Use Case ID: Team_1_Login
Use Case Level: User-System level
Details:
Actor(s): The Teacher or Student and system
Pre-conditions: The communication API�s (Skype and Smack) must be installed on the system and the Teacher/Student must have an account with each one.
Description:
Trigger: The user enters the ID and Password and clicks on the �Login� BUTTON.
Response: The response may vary depending on the API being logged in to and is outside the control of the CVM.
Relevant requirements: Both professor and Student know the ID and Password
Post-conditions: The user is logged into both Skype and Smack
Alternative Courses of Action: There is no alternative course of actions
Extensions: Logout
Exceptions: Any Exceptions are handled through the communication API�s interface
Concurrent Uses: No concurrent uses
Related Use Cases: ME001-ME003
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: This use case is performed 3 times a day on average.
Criticality: This use case has a 1% mean time to failure.
Risk: There is no risk with providing this use case.
Constraints:
Usability: Very Easy To Use
Reliability: Very High as the user is allowed only if he enters correct ID and Password
Performance: Excellent as almost 10/10 times the output is correct.
Supportability: Simple
Implementation: Must be implemented in Java.
------------------------------------------------------------------------------------------------------------
Modification History
Owner: Yinet Gonzalez
Initiation date: 02/14/2008
Date last modified: 02/25/2008
Use Case for Log Out
Use Case ID: Team _1_Logout
Use Case Level: User - System
Details:
Actor(s): Professor, student and system
Pre-conditions: The user is logged into the system
Description:
Trigger: The user clicks on the �Logout� Button provided on his screen
The system responds by... Closing the current window of the user and then displaying a good bye message
Relevant requirements: No relevant requirements
Post-conditions: The system resets the status of the user as logged out and removes the availability message.
Alternative Courses of Action: No alternative scenarios after being logged out.
Extensions:
Case 1: No connections are open
Case 2: 1 or more connections are left open
Exceptions: If one or more connections are left open and the log-out button is clicked then the system prompts the user to terminate the connection and then proceed with logon.
Concurrent Uses: No concurrent uses.
Related Use Cases: Any possible functionality can be performed before logging out.
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: Every Time the user wants to logout or during any system crash or power supply failure.
Criticality: This is highly critical as to terminate the use of system every user has to logout.
Risk: No identified risk is associated with logout.
Constraints:
Usability: Very Easy
Reliability: Highly Reliable
Performance: Excellent will succeed almost every time
Supportability: good
Implementation: in Java
------------------------------------------------------------------------------------------------------------
Modification History -- {Follow the standard corporate document versioning template}
Owner: Relmer Perez
Initiation date: 02/14/2008
Date last modified: 02/17/2008
Two-Way Audio – Execution
Use Case ID: ME001
Use Case Level: High-level.
Details:
Scenario: User Teacher or Student wants to execute a communication instance. The User loads a communication model file to be executed by the user (Student or teacher). Once the model has being loads unsuccessfully then the user can execute the model.
Actor(s): Student or Teacher
Pre-conditions: A communication model file must be already created and saved.
Description:
Trigger: The user (student or teacher) initiates an action by selecting the instance file.
1. The User selects the Open option from the File Menu of the Eclipse IDE.
2. The system asks the User for the file name containing a CVM model to be loaded into a canvas.
3. The User enters the requested file name.
4. The system opens the file specified in step 3 and loads the CVM model into the IDE canvas.
5. The system acknowledges the operation by displaying a message on the status bar of the IDE.
6. The CVM model is loaded into the canvas.
7. Appropriate profile information is entered for the local and remote user by the student or teacher.
8. The user initiates the voice communication by selecting the instance file.
9. The system responds by parsing the file and performing the required Skype and Smack API calls.
Relevant requirements: The actor has an understanding of the model execution and operation process.
Post-conditions: After this use case is performed a communication model has been executed to allow local and remote participants to make a one to one voice connection with no errors.
Alternative Courses of Action If in step 2, the User hits the Cancel button; the system cancels the action and closes the Load dialog window. The complete execution process is aborted.
Extensions: This use case is extended in the conference call use case.
Exceptions:
In step 3, if the file name specified by the User does not exist, then the system displays an error message accordingly and goes to step 2 to ask for another file name.
In step 4, if there is not enough space on the file system, the system displays an error dialog message stating so.
In step 4, if the specified file does not contain a valid model or if the file cannot be read, the system displays an error dialog message stating so.
Concurrent Uses: Text Messaging, Video connection can be concurrent uses.
Related Use Cases: Before the voice communication execution use case, a voice communication model file must have been created on during the model creation use case.
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: This use case will be performed at least once per application use. That is, every time that an actor wants to execute an audio communication model to allow two participants to make a live audio connection. On average this use case will be performed 2-5 times per application use.
Criticality: Its absence may not cause the system to crash, but it may prevent the users from establishing a voice communication.
Risk: The risk of crashing for this use case must be low; under 5% of cases.
Constraints:
An instance is a complete schema.
Usability: must be easy to use, can be mastered in less than 5 minutes.
Reliability: must always load the instance file from disk unless external conditions prevent doing so.
Performance: Must be able to establish the connection within 3 minutes of execution
Supportability: Must clearly identify the subcomponent where an error occurred in case of exceptions.
Implementation: must be implemented with Eclipse GMF.
------------------------------------------------------------------------------------------------------------
Modification History – version-2
Owner: Sandeep Varry
Initiation date: February 15, 2008
Date last modified: February 16, 2008
Video Model Execution
Use Case ID: ME002
Use Case Level: High-level.
Details:
Scenario: The Teacher or Student wants to execute a communication instance. The User load a communication model file to be executed by the user (Student or Teacher). Once the model has been loaded successfully then the user can execute the model.
Actor(s): Student or Teacher
Pre-conditions: A communication model file must already be created and saved.
Description:
Trigger: The user (student or teacher) initiates an action by selecting the instance file.
1. The user will click on the File menu and choose Execute from the UI
2. The user will select the file to execute from the pop-up dialog
3. Once the file has been selected the model is parsed to XCML.
4. If information is missing from the model the user will be notified that fields are missing and be presented with a Completion Wizard to fill out the required information.
5. The user will click the next button to cycle through the missing information.
6. If the information entered is not valid the user will be notified and will not be allowed to proceed until it is correct.
7. When all information has been entered the user will click the finish button.
8. The parsed model and the user input together will form the final XCML.
9. The XCML is interpreted into function calls
10. The function calls are executed
Trigger: The user selects a model to execute from the File Menu
Response: The system performs validation and lastly executes the model
Relevant requirements: The actor has an understanding of the model execution and operation process.
Post-conditions: After this use case is performed a communication model has been executed to allow local and remote participants to make a one to one voice connection with no errors.
Alternative Courses of Action If in step 2, the user hits the Cancel button; the system cancels the action and closes the Load dialog window. The complete execution process is aborted.
Extensions: This use case is extended in the conference call use case.
Exceptions:
In step 3, if the file name specified by the User does not exist, then the system displays an error message accordingly and goes to step 2 to ask for another file name.
In step 4, if there is not enough space on the file system, the system displays an error dialog message stating so.
In step 4, if the specified file does not contain a valid model or if the file cannot be read, the system displays an error dialog message stating so.
Concurrent Uses: Text Messaging, Video connection can be concurrently used.
Related Use Cases: Before the voice communication execution use case, a voice communication model file must have been created on during the model creation use case.
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: This use case will be performed at least once per application use. That is, every time that an actor wants to execute an audio communication model to allow two participants to make a live audio connection. On average this use case will be performed 2-5 times per application use.
Criticality: Its absence may not cause the system to crash, but it may prevent the users from establishing a voice communication.
Risk: The risk of crashing for this use case must be low; under 5% of cases.
Constraints:
An instance is a complete schema.
Usability: must be easy to use, can be mastered in less than 5 minutes.
Reliability: must always load the instance file from disk unless external conditions prevent doing so.
Performance: Must be able to establish the connection within 3 minutes of execution
Supportability: Must clearly identify the subcomponent where an error occurred in case of exceptions.
Implementation: must be implemented with Eclipse GMF.
------------------------------------------------------------------------------------------------------------
Modification History – version-2
Owner: Mark Alison
Initiation date: February 15, 2008
Date last modified: February 16, 2008
Text Model Execution
Use Case ID: ME003
Use Case Level: High Level
Details:
Actor(s): The initiator of the communication, also known as the user.
Pre-conditions: Model Creation Use Case has been completed.
Description:
1. The user will click on the File menu and choose Execute from the GUI
2. The user will select the file to execute from the pop-up dialog
3. Once the file has been selected the model is parsed into XCML.
4. If the model is not properly formulated this use case ends. i.e. shapes are missing that are required for the diagram to be complete.
5. If the model is properly formulated but information is missing, the user will be notified that fields are missing and be presented with the Completion Wizard for the required information.
6. The user will click the next button to cycle through the missing information.
7. If there is an error the user will not be allowed to proceed until it is corrected.
8. When all missing information has been filled out the user will click finish.
9. The entered information will be used to update the XCML.
10. The XCML is interpreted into function calls
11. The function calls are executed
Trigger: The user selects a model to execute from the File Menu
Response: The system performs validation and lastly executes the model
Relevant requirements:
1. There needs to be a model to execute, and it has to be created with the model editor.
2. There must be at least one communication API installed and running that supports text messaging
Post-conditions: Text messaging has been initiated as specified by the model.
Alternative Course of Action: If the model is properly formulated and not missing information then execution proceeds with no further notification.
Extensions: There are no Extensions
Exceptions: The file chosen is not a communication diagram model.
Concurrent Use: This use case can be done concurrently with all other Use Cases.
Related Use Case: This Use Case is related to the Two Way Text Message Model Creation Use Case
------------------------------------------------------------------------------------------------------------
Decision Support
Frequency: 6 times a day
Criticality: This use case is 100% critical to the functionality of the system. Without this feature there is no way to execute a model with text as the medium type.
Risk: High risk due to exception handling system integration.
Constraints:
Usability: Correcting invalid models should be intuitive.
Reliability: Mean time to failure 2%
Performance: The code will realize the communication within 3 seconds.
Supportability: Updates will be released every 6 months.
Implementation: Each step of the execution process should be delegated to a class.
------------------------------------------------------------------------------------------------------------
Modification History – Version 2
Owner: Drake Campbell
Initiation date: 02/08/2008
Date last modified: 02/24/2008
Employee Authentication (Security
Use Case)
ID: MA01
Scenario:
Actor: Employee
Pre-conditions:
1. Employee
has been assigned a UNIQUE valid EmployeeID and password.
2. Previous
Employee has logged off the terminal
Description:
1. The
use case begins when: The system provides the Employee with a template for data
entry (See appendix D).
2. The
Employee shall enter the following data: EmployeeID, name and a password which shall not echo to prevent social engineering. (The highlighted
words are the required fields.)
3. The
Employee shall then signify their intent to access the desired system by double
clicking on the submit button.
4. The
terminal shall then encrypt the employee�s data and transmit for verification.
5. The
terminal shall notify the Employee that the request for access has been
submitted.
6. When
the request is received the system shall check if the employee is authorized to
access the requested system.
7. When
authenticated the system shall issue an �authenticated� signal to the terminal
and log the user information for security auditing purposes.
8. The
terminal upon receipt of authentication shall welcome the employee
Use case ends when the system can be accessed via the
terminal.
Post-conditions:
1. The
number of Employees logged on has increased by one.
2. The
Employees Name and EmployeeID along with the current time has been logged as
active on the system.
Alternative Courses of Action:
1. In
step D.6 (step 6 of Description section) if the employee request is
unauthenticated the system shall allow the Employee a second opportunity to
authenticate. If the Employee fails a second time then the system shall lock
the account and log the misuse. (see misuse scenario 1)
2. In
step D.2 if any of the required
fields are blank the system shall request the user to make an entry in the
appropriate field.
Exceptions:
1. The
terminal is offline
2. The
server is down
Related Use
Case:
Use case MA02
refers to authentication t
Decision
Support:
Frequency:
On average 8 requests are made daily by Employees per
terminal.
Criticality: High. Only means for Employees to access either system.
Risk: Medium. Implementing this use case employs standard technology.
Constraints:
1.
Usability
1.1.
The interface is designed to be extremely user friendly,
however Employees will be required to read the companies security policy
regarding password policy and social engineering avoidance.
1.2.
The terminal shall provide feedback as to login status and any
errors encountered
1.3.
On average the user should take 1 minute to complete the
logon.
2.
Reliability
2.1.
Mean time to Failure – 2% failure for every twenty four hours of operation
is acceptable.
2.2.
Availability – The login system shall NOT be available
outside of school hours due to security concerns
3.
Performance
3.1.
Employee validation, audit log and feedback of a successful
logon should not exceed 10 secs.
3.2. System should be
able to handle 10 request in 1 minute
4.
Supportability
4.1.
System will access a local password file
4.2.
Modification History:
Owner: Mark Allison
Initiation
date: 02/10/2007
Date last modified: 03/20/2007
Attempted login to
Communication System using an existing Employeeid (Security Misuse Case)
Use Case ID: MA04 –
Scenario:
Actor: Misuser
Security Threat: The system authenticates the misuser
allowing access to the communication system
Pre-conditions:
1. Misuser
has obtained a valid EmployeeID
2. Misuser
does not have a valid Password
3. Misuser
has access to a terminal
Description:
1. The
use case begins when: The system provides the Employee with a template for data
entry (See appendix D).
2. The
misuser responds with a valid employeeid
3. The
misuser responds with an invalid password
4. The
system shall recognize the employeeid as valid
5. The
system shall recognize the password as invalid and not authenticate the
employee.
6. The
system shall assume that the first invalid entry was due to a human error
7. The
system shall notify the misuser of an authentication error and request an
additional login
8. The
misuser responds with a valid Employeeid and an incorrect password once more
9. The
system shall recognize D8 as a second attempt
10. Use case ends
when the system notifies the misuser of an authentication error
Post-conditions:
1. The
system shall not have allowed access to the system
2. The
system shall log the incident as a security breach
3. The
system shall page a manager.
Alternative Courses of Action:
1. In
step D8. should this attempt the system shall log the user normally.
Exceptions:
1. The
terminal is offline
2. The
server is down
3. The
misuser has stolen the password of an employee. This risk will be addressed by
the security policy.
Related Uses Case:
Use
case MA01 refers to authentication to the system.
Decision Support:
Frequency: On average 2 requests are made anticipated per month
Criticality: High. This misuse may lead to corporate losses
Risk: Medium.
Implementing this use case employs standard technology.
Constraints:
1.
Usability
1.1.
The interface is designed to be extremely user friendly,
however Employees shall be required to read the companies security policy
regarding password policy and social engineering avoidance.
1.2.
The terminal shall provide feedback as to login status and any
errors encountered
1.3.
On average the user shall take 1 minute to complete the logon.
2.
Reliability
2.1.
Mean time to Failure – 2% failure for every twenty four hours of operation
is acceptable.
2.2.
Availability – The login system shall NOT be available
outside of school hours due to security concerns
3.
Performance
3.1.
Employee validation, audit log and feedback of a successful
logon should not exceed 10 secs.
3.2.
System shall be able to handle 10 request in 1 minute
4.
Supportability
4.1.
Does not require additional application support.
Modification History:
Owner: Mark Allison
Initiation date: 02/10/2008
Date last modified: 3/02/2008
Use Cases Summary
- The system does not allow 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.
- The system allows 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.
- The system provides functionality for dragging and
dropping shape representations of CML Terminals onto a canvas for
composing CML Non-terminals.
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 system provides 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 allows 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 plattaform.
- The system allows 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 allows 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.
- The system allows 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.
Nonfunctional Requirements
Performance:
�
Short response time: In any case or condition response
time of application should be as short as possible.
Usability:
�
Simple to use: Rapid Realization of Communication
Service System should provide interface for user to easily access operations.
Reliability:
�
No-Crash: Rapid Realization of Communication Service
System should be crash safe in 100% of its runtime.
Supportability:
� Maintainability: The design of Rapid Realization of Communication Service System functionality should allow for easy maintenance of the system
5.3 Appendix C
Detailed Class Diagrams
5.3.1 Model Transformation Class Diagram
5.3.2 Layer Frame Work Class Diagram
5.3.3 NCB Frame Work Class Diagram
5.3.4 NCB Synthesis Core Class Diagram
5.3.5 NCB Core Class Diagram
5.4 Appendix D
LAYERFRAMEWORK
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : Core extends Thread.java
* @ Date : 3/25/2008
*
*
* Class Name: Core extends Thread
**/
/**
* This class reprents the core functionality of a layer Object. Core Objects define Functors as inner classes. Cores use Functors to define their functionality. Cores are not responsiblee for handeling events. Their delegate maintains a mapping between events and functors, and are responsible for their execution.
**/
public abstract class Core extends Thread {
private LinkedBlockingQueue refToLayerEventQueue;
private Layer refToLayer;
private Delegate coreDelegate;
private ReentrantLock coreLock;
/**
* This method is called by the Layer's constructor.
*
* @param queue
**/
protected final void registerWithLayerEventQueue(LinkedBlockingQueue<LayerEvent> queue) {
}
/**
* This method is called by the Layer's constructor.
*
* @param layer
**/
protected final void registerWithLayer(Layer layer) {
}
/**
* The constructor should not be overloaded. Instead, overload the init() and registerEvents() methods to do your domain specific work.
**/
private void Core() {
}
public void Core(int initialThreadPoolSize, int threadPoolCapacity, int threadPoolQueueLimit) {
}
/**
* This method is called before the registerEvents() method in the Core constructor.
**/
public void init() {
}
/**
* This method is called after init() in the Core's constructor.
**/
public abstract void registerEvents();
/**
* Use this method to register all your events and functors. This can be done when overriding the registerEvents() method.
*
* @param event
* @param callback
**/
public final void registerEventWithDelegate(LayerEvent event, Functor callback) {
}
/**
* Use this method to un-register an event from a Functor. Durring runtime if the event to be handled was unregistered, then the event travels in its defined direction untill it reaches a null layer and is destroyed or caught by another Layer.
*
* @param event
* @param callback
**/
public final void unregisterEventWithDelegate(LayerEvent event, Functor callback) {
}
/**
* Overload the beforeRunLoopBegins(), beforeGettingAnEvent(), afterProcessingAnEvent(), shouldIKeepRunning(), and afterRunLoopEnds() depending on the granularity of controll you want over the Core's life cycle. The default implementations for all the above are empty with the exception of ShouldIKeepRunning(), which returns true by default.
**/
public final void run() {
}
/**
* This method is called before the Core's main run loop begins. Its the perfect opprotunity to perform any initialization work before the run loop starts.
**/
public void beforeRunLoopBegins() {
}
/**
* This method is called inside the Core's run loop before getting an event from the Layer's event queue.
**/
public void beforeGettingAnEvent() {
}
/**
* This method is called in the Core's run loop after an event has been successfully handles.
**/
public void afterProcessingAnEvent() {
}
/**
* This method is called at the end of the Core's run loop before the next iteration. The value returned by this method is the value used to determine if the loop will iterate again or stop.
**/
public boolean shouldIKeepRunning() {
}
/**
* This method is called after the Core's run loop terminates but before the thread is destroyed. Its the perfect opprotunity to perform any required cleanup.
**/
public void afterRunLoopEnds() {
}
public void handleInterruptedException(InterruptedException e) {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : Command implements Runnable.java
* @ Date : 3/25/2008
*
*
* Class Name: Command implements Runnable
**/
public class Command implements Runnable {
private ArrayList<Object> arguments;
private Functor functor;
private void Command() {
}
/**
* Create a Command object to be execute the given command on the arguments.
*
* @param callback
* @param args
**/
public void Command(Functor callback, ArrayList<Object> args) {
}
public void run() {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : Delegate.java
* @ Date : 3/25/2008
*
*
* Class Name: Delegate
**/
/**
* The Delegate class is responsible for maintaining the mapping between system events and the Core's Functors. The Delegate is also responsible for handeling the events that were added to the Layer's event queue.
**/
public class Delegate {
private ReentrantLock delegateLock;
private HashMap<String,ArrayList<Functor>> eventMap;
private ThreadPool threadPool;
/**
* Create a delegate object to handle Layer events.
**/
private void Delegate() {
}
/**
* Create a Delegate instance.
*
* size represents the starting number of threads the Delegate's ThreadPool has.
*
* the capacity represetns the maximum number of threads the Delegate's ThreadPool can have.
*
* the queueLimit is used to set how many jobs can be in the queue before it spawns more threads.
*
* @param size
* @param capacity
* @param queueLimit
**/
public void Delegate(int size, int capacity, int queueLimit) {
}
/**
* This method is called by the registerEventWithDelegate() method in the Core class.
*
* @param event
* @param callback
**/
public void registerEvent(LayerEvent event, Functor callback) {
}
/**
* This method is called from the unregisterEventWithDelegate() in the Core class.
*
* @param event
* @param callback
**/
public boolean unregisterEvent(LayerEvent event, Functor callback) {
}
/**
* This method returns a true if the Delegate contains an entry tor the event.
*
* @param event
**/
public boolean respondsTo(LayerEvent event) {
}
/**
* This method creates a Command object and adds it to a thread pool.
*
* @param event
**/
public void handle(LayerEvent event) {
}
private String getTypeInformation(LayerEvent event) {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : Functor.java
* @ Date : 3/25/2008
*
*
* Class Name: Functor
**/
public abstract class Functor {
/**
* Override this method to do the work required to respond to a specific event.
*
* @param args
**/
public abstract void callback(ArrayList<Object> args);
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : Layer.java
* @ Date : 3/25/2008
*
*
* Class Name: Layer
**/
/**
* This class represents a layer in an n-tiered architecture. Use Core objects tchange the behavior of a Layer Object.
**/
public class Layer {
private Layer layerBelowMe;
private Layer layerAboveMe;
private LinkedBlockingQueue<LayerEvent> eventQueue;
private ReentrantLock layerLock;
private void Layer() {
}
/**
* Create a Layer where core describes its 'core' functionality
*
* @param Core core
**/
public void Layer(Object Core core) {
}
/**
* Return the layer above <code>this</code> in the architecture.
**/
public Layer getLayerAboveMe() {
}
/**
* Set the layer above <code>this</code> in the archtecture to 'layer'.
*
* @param layer
**/
public void setLayerAboveMe(Layer layer) {
}
/**
* Return the layer below <code>this</code> in the architecture.
**/
public Layer getLayerBelowMe() {
}
/**
* Set the layer above <code>this</code> in the archtecture to 'layer'.
*
* @param layer
**/
public void setLayerBelowMe(Layer layer) {
}
/**
* Add 'event' to the Layer's eventQueue.
*
* @param event
**/
public final void addEvent(LayerEvent event) {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : LayerEvent extends EventObject.java
* @ Date : 3/25/2008
*
*
* Class Name: LayerEvent extends EventObject
**/
public abstract class LayerEvent extends EventObject {
private ArrayList<Object> arguments;
/**
* Create an event from the given source with the arguments. Override the getDirection() method with either <code>return Layer.DIRECTION.UP;</code> or <code> return Layer.DIRECTION.DOWN;</code>.
*
* @param source
* @param args
**/
public void LayerEvent(Object source, ArrayList<Object> args) {
}
public abstract Layer.DIRECTION getDirection();
public String toString() {
}
public ArrayList<Object> getArguments() {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : LayerException.java
* @ Date : 3/25/2008
*
*
* Class Name: LayerException
**/
public class LayerException {
/**
* Create an Exception with a message.
*
* @param String message
**/
public void LayerException(Object String message) {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : ThreadPool.java
* @ Date : 3/25/2008
*
*
* Class Name: ThreadPool
**/
/**
* This class represents a set number of threads that share a common work queue.
**/
public class ThreadPool {
private LinkedBlockingQueue<Runnable> workQueue;
private ArrayList<WorkerThread> internalPool;
private ReentrantLock threadPoolLock;
private int initialSize;
private int queueLimit;
private int currentSize;
private int maxCapacity;
/**
* Create a ThreadPool instance.
*
* size represents the starting number of threads the ThreadPool has.
*
* the capacity represens the maximum number of threads the ThreadPool can have.
*
* the limit is used to set how many jobs can be in the queue before it spawns more threads.
*
* @param size
* @param capacity
* @param limit
**/
public void ThreadPool(int size, int capacity, int limit) {
}
/**
* Request that the thread pool execute the runnable command.
* Returns null if it was accepted the runnable if it was rejected.
*
* @param Runnable runnable
**/
public Runnable submit(Object Runnable runnable) {
}
/**
* This will cause the ThreadPool to stop responding to submit requests.
**/
public void shutdown() {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : LayerFramework
* @ File Name : WorkerThread extends Thread.java
* @ Date : 3/25/2008
*
*
* Class Name: WorkerThread extends Thread
**/
/**
* This class represents a worker thread of the ThreadPool.
**/
private class WorkerThread extends Thread {
/**
* The worker simply gets a command from the ThreadPool's queue and executes it.
**/
public void run() {
}
}
END LAYERFRAMEWORK
BEGIN NCBFRAMEWORK
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : VideoBroadcast.java
* @ Date : 3/25/2008
*
* Class Name: VideoBroadcast
**/
/**
* This class represents tha abstract notion
* of a video broadcast.
* Inherit this object to provide different
* implementations using a particular API.
**/
public abstract class VideoBroadcast implements Sender, Caller {
public static String callFailureReason;
/**
* This method gives other objects the ability
* to start the sending of information of
* a specific type.
**/
public void startSending();
/**
* This method gives other objects the ability
* to stop the sending of information of
* a specific type.
**/
public void stopSending();
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : TwoWayVideo.java
* @ Date : 3/25/2008
*
* Class Name: TwoWayVideo
**/
/**
* This class represents tha abstract notion
* of a two way video call.
* Inherit this object to provide different
* implementations using a particular API.
**/
public abstract class TwoWayVideo implements Sender, Receiver, Caller {
public static String callFailureReason;
/**
* This method gives other objects the ability
* to start the sending of information of
* a specific type.
**/
public void startSending();
/**
* This method gives other objects the ability
* to stop the sending of information of
* a specific type.
**/
public void stopSending();
/**
* This method gives other objects the ability
* to start the receiving of information of
* a specific type.
**/
public void startReceiving();
/**
* This method gives other objects the ability
* to stop the receiving of information of
* a specific type.
**/
public void stopReceiving();
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : TwoWayText.java
* @ Date : 3/25/2008
*
* Class Name: TwoWayText
**/
/**
* This class represents tha abstract notion
* of a two way text message.
* Inherit this object to provide different
* implementations using a particular API.
**/
public abstract class TwoWayText implements Messenger {
public static String callFailureReason;
/**
* Send or broadcast the message
*
* @param message
**/
public void sendMessage(String message);
/**
*
* @param inviteList Invite the list of people to the chat room
**/
public void invite(ArrayList<Object> inviteList);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : TwoWayCall.java
* @ Date : 3/25/2008
*
* Class Name: TwoWayCall
**/
/**
* This class represents tha abstract notion
* of a two way phone call.
* Inherit this object to provide different
* implementations using a particular API.
**/
public abstract class TwoWayCall implements Caller {
public static String callFailureReason;
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackVideoBroadcast.java
* @ Date : 3/25/2008
*
* Class Name: SmackVideoBroadcast
**/
public class SmackVideoBroadcast extends VideoBroadcast {
private static VideoBroadcast instance;
public static VideoBroadcast getInstance() {
}
private void SmackVideoBroadcast() {
}
/**
* This method gives other objects the ability
* to start the sending of information of
* a specific type.
**/
public void startSending();
/**
* This method gives other objects the ability
* to stop the sending of information of
* a specific type.
**/
public void stopSending();
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackTwoWayVideo.java
* @ Date : 3/25/2008
*
* Class Name: SmackTwoWayVideo
**/
public class SmackTwoWayVideo extends TwoWayVideo {
private static TwoWayVideo instance;
public static TwoWayVideo getInstance() {
}
private void SmackTwoWayVideo() {
}
/**
* This method gives other objects the ability
* to start the sending of information of
* a specific type.
**/
public void startSending();
/**
* This method gives other objects the ability
* to stop the sending of information of
* a specific type.
**/
public void stopSending();
/**
* This method gives other objects the ability
* to start the receiving of information of
* a specific type.
**/
public void startReceiving();
/**
* This method gives other objects the ability
* to stop the receiving of information of
* a specific type.
**/
public void stopReceiving();
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackTwoWayText.java
* @ Date : 3/25/2008
*
* Class Name: SmackTwoWayText
**/
/**
* The Smack implementation of a TwoWayText.
**/
public class SmackTwoWayText extends TwoWayText {
private static TwoWayText instance;
/**
* Get the instance of SackTwoWayText.
**/
public static TwoWayText getInstance() {
}
private void SmackTwoWayText() {
}
/**
* Send or broadcast the message
*
* @param message
**/
public void sendMessage(String message);
/**
*
* @param inviteList Invite the list of people to the chat room
**/
public void invite(ArrayList<Object> inviteList);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackTwoWayPhone.java
* @ Date : 3/25/2008
*
* Class Name: SmackTwoWayPhone
**/
public class SmackTwoWayPhone extends TwoWayCall {
private static TwoWayPhone instance;
public TwoWayPhone static getInstance() {
}
private void SmackTwoWayPhone() {
}
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackChecker.java
* @ Date : 3/25/2008
*
* Class Name: SmackChecker
**/
public class SmackChecker extends APIChecker {
private static APIChecker instance;
private void SmackChecker() {
}
public static APIChecker getInstance() {
}
/**
* This method lets you know whether or not
* a particular API is installed on the system.
**/
public boolean installed() {
}
/**
* This method lets you know whether or not
* a particular API is running on the system.
**/
public boolean isRunning() {
}
/**
* This method returns the corresponding
* instance of the AbstractFactory associated with the API.
**/
public AbstractFactory getAPIFactory() {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackConferenceCall.java
* @ Date : 3/25/2008
*
* Class Name: SmackConferenceCall
**/
public class SmackConferenceCall extends ConferenceCall {
private static ConferenceCall instance;
public ConferenceCall static getInstance() {
}
private void SmackConferenceCall() {
}
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackAbstractFactory.java
* @ Date : 3/25/2008
*
* Class Name: SmackAbstractFactory
**/
public class SmackAbstractFactory extends AbstractFactory {
private static AbstractFactory instance;
public static AbstractFactory getInstance() {
}
private void SmackAbstractFactory() {
}
/**
* Return the singleton for a
* TwoWayPhone.
**/
public TwoWayCall createTwoWayCall() {
}
/**
* Return the singleton for a
* ConferenceCall.
**/
public ConferenceCall createConferenceCall() {
}
/**
* Return the singleton for a
* VideoBroadcastl.
**/
public VideoBroadcast createVideoBroadcast() {
}
/**
* Return the singleton for a
* TwoWayVideo.
**/
public TwoWayVideo createTwoWayVideo() {
}
public TwoWayText createTwoWayText() {
}
public ChatRoom createChatRoom() {
}
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SmackChatRoom.java
* @ Date : 3/25/2008
*
* Class Name: SmackChatRoom
**/
/**
* The Smack implementation of a ChatRoom.
**/
public class SmackChatRoom extends ChatRoom {
private static ChatRoom insance;
/**
* Get the instance of SmackChatRoom.
**/
public static ChatRoom getInstance() {
}
private void SmackChatRoom() {
}
/**
* Send or broadcast the message
*
* @param message
**/
public void sendMessage(String message);
/**
*
* @param inviteList Invite the list of people to the chat room
**/
public void invite(ArrayList<Object> inviteList);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SkypeTwoWayVideo.java
* @ Date : 3/25/2008
*
* Class Name: SkypeTwoWayVideo
**/
/**
* The Sykpe implementation of a TwoWayVideo.
**/
public class SkypeTwoWayVideo extends TwoWayVideo {
private static TwoWayVideo instance;
/**
* Get the instance of SkypeTwoWayVideo.
**/
public static TwoWayVideo getInstance() {
}
private void SkypeTwoWayVideo() {
}
/**
* This method gives other objects the ability
* to start the sending of information of
* a specific type.
**/
public void startSending();
/**
* This method gives other objects the ability
* to stop the sending of information of
* a specific type.
**/
public void stopSending();
/**
* This method gives other objects the ability
* to start the receiving of information of
* a specific type.
**/
public void startReceiving();
/**
* This method gives other objects the ability
* to stop the receiving of information of
* a specific type.
**/
public void stopReceiving();
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SkypeVideoBroadcast.java
* @ Date : 3/25/2008
*
* Class Name: SkypeVideoBroadcast
**/
/**
* The Skype implementation of a VideoBroadcast.
**/
public class SkypeVideoBroadcast extends VideoBroadcast {
private static VideoBroadcast instance;
/**
* Get the instance of the SkypeVideoBroadcast.
**/
public static VideoBroadcast getInstance() {
}
private void SkypeVideoBroadcast() {
}
/**
* This method gives other objects the ability
* to start the sending of information of
* a specific type.
**/
public void startSending();
/**
* This method gives other objects the ability
* to stop the sending of information of
* a specific type.
**/
public void stopSending();
/**
* This method takes a generic array list of objects.
* It is up to the implementor to know how the objects are used
* and maintain the consistency.
*
* @param args
**/
public Object call(ArrayList<Object> args);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SkypeTwoWayText.java
* @ Date : 3/25/2008
*
* Class Name: SkypeTwoWayText
**/
/**
* The Sykpe implementation of a TwoWayText.
**/
public class SkypeTwoWayText extends TwoWayText {
private static TwoWayText instance;
/**
* Get the instance of SkypeTwoWayText.
**/
public static TwoWayText getInstace() {
}
private void SkypeTwoWayText() {
}
/**
* Send or broadcast the message
*
* @param message
**/
public void sendMessage(String message);
/**
*
* @param inviteList Invite the list of people to the chat room
**/
public void invite(ArrayList<Object> inviteList);
public void finish();
}
/**
*
* Generated by StarUML(tm) Java Add-In
*
* @ Project : NCBFramework
* @ File Name : SkypeChatRoom.java
* @ Date : 3/25/2008
*
* Class Name: SkypeChatRoom
**/
/**
* The Sykpe implementation of a ChatRoom.
**/
public class SkypeChatRoom extends ChatRoom {
private static ChatRoom instance;
/**
* Get the instance of SkypeChatRoom.
**/
public static ChatRoom getInstance() {
}
private void SkypeChatRoom() {
}
/**
* Send or broadcast the message
*
* @param message
**/
public void sendMessage(String message);
&n