Supervisor: Professor Gabriel Wainer

Second Reader: Professor Aysegul Cuhadar

A report submitted in partial fulfillment of the requirements

Of SYSC-4907 Engineering Project

Department of Systems and Computer Engineering

Faculty of Engineering

Carleton University

April 9^th, 2008

Abstract

This report fulfills the final requirement for the fourth year final project course SYSC 4907. The project is entitled “Development of Real-time Applications with Atlantis Technology” and was completed by Kevin Philipose, Kalaimathan Mahenthiran and Ronald Amelunge Antelo under the supervision of Professor Gabriel Wainer and with the support of Mr. David Long, inventor of Atlantis Technology.

After identification of a need for a simple and affordable network alarm monitoring systems for rural areas and small scale business owners the main objective of the project was to develop a Network Alarm Monitoring System prototype that was both efficient and simple to use. Another major part of the project was to provide feedback on Atlantis Technology, which is an emerging process modelling technology.

To complete both objectives, Atlantis’ process modelling capabilities were put into use to develop a system called the “Carleton Network Alarm Monitoring System”, or CNAMS, following standard software engineering development principles. CNAMS recognizes SNMP messages, one of the most widely used network management protocols.

As a result of the work done throughout the project a working prototype of CNAMS was developed and substantial feedback was given to SAGETEA Group, developers of Atlantis technology. The CNAMS system is a great success given that it successfully serves as a prototype for a network alarm monitoring system and has the potential of being industrialized.

Acknowledgements

We would like to offer special acknowledgements to the individuals that helped us and gave us feedback throughout the course of the project. First, we would like to thank Mr. David Long, of SAGETEA Group, for his effort in providing us with continuous assistance in the usage of Atlantis Technology.

We would like to thank also Professor Aysegul Cuhadar for the objective and precise feedback given during the oral presentation and poster fair.

We would like to extend our gratitude to the Department of Systems and Computer Engineering at Carleton University, its staff and technicians for providing us with lab resources to complete this project successfully.

Finally, we would like to thank our project supervisor, Professor Gabriel Wainer for his continuous support, valuable feedback and guidance given throughout the project.

Table of Contents

List of Figures

1.0 Introduction

In today’s world, global communications has become of utmost importance to both businesses and individuals alike. Reliable communication with the global network or even with remote data is now almost taken for granted and can be critical for various applications. For our 4^th Year project we developed a Network Alarm Monitoring System with the objective of providing a solution to the overlooked rural communities and small businesses network monitoring market. The project is entitled “Development of a Real-time application using Atlantis Technology” and we used the Atlantis software suite to implement a working prototype for potential customers in the rural communities and small businesses.

1.1 Motivation

Communication networks have expanded together with technology and it has reached to a point that trying to manage the networks without a network management system would be almost impossible for the network technicians. In fact, errors in the network probably won’t be detected until the damage has already been done and the time it would take to pinpoint the location of the faulty component would prove to be deadly for several types of businesses, such as financial institutions and online merchants seeing as though if their main server goes down, the customers wouldn’t be able to use their services, equaling a huge loss for business.

To solve this problem, network monitoring systems have been developed to assist the network technicians and allow them to gather all the information required for them to maintain the network up and running. These systems gather measurements of devices within the network to perform configuration, performance, security and more importantly, fault management.

Even with these tools readily available, there are still small businesses and communities located in rural areas that are without service due to expensive current solutions aimed at higher profit customers. A local consulting company by the name of “10ConsulTech” working with SAGETEA group, inventors of Atlantis technology, have identified small telecom supplier who has expressed interest in a solution for this problem.

SAGETEA Group is interested in utilizing Atlantis technology to develop a working prototype to address this problem. Atlantis software is a process modeling technology for business applications and is in its initial stages of providing the ability to develop commercial applications. This technology has not been previously used to model real-time applications of this kind. Atlantis’ viability for creating commercial applications is not known, specifically in IP networks.

For our project we have developed a prototype using Atlantis Technology to solve this problem and expand Atlantis technology’s capabilities.

1.2 Problem Statement

We have identified two main problems which our project addresses. The first being the need of a commercial network monitoring system prototype specifically designed to meet the needs of small businesses and networks in rural areas. The second is to utilize Atlantis Technology in the development of this prototype and to test, analyze and evaluate its viability in mainstream software development.

1.3 Proposed Solution

Our solution to these problems incorporates both development and evaluation aspects of Atlantis technology. This will be accomplished by using Atlantis’ real-time and modeling capabilities to create a network alarm monitoring prototype that can be used in the industry or for further development in the future. Through this development process, we will have gained full understanding of Atlantis’s abilities and can provide an objective feedback to SAGETEA group.

1.4 Accomplishments

We have made many accomplishments throughout the course of the project. This is a new project as we are experimenting with Atlantis’ software modeling and developing capabilities which has not been previously done. Initial estimates of the amount of workload were made but were not fully understood because Atlantis is a new technology and is currently in development.

In the initial stage of development, Atlantis and its components needed to be fully understood. This was accomplished by creating test processes within Atlantis and also reading some of the documentation available. This documentation was quite limited and required us to do extensive experimentation in setting up the various components used within Atlantis, including PostgresSQL, the SNMP framework, Smalltalk and Atlantis itself.

As part of the learning process, one of our system requirements was to use the Simple Network Management Protocol (SNMP) as the primary communication protocol within the system. By the use of academic resources, we were able to complete research on the protocol, what parts we needed and various implementation configurations for our system. Atlantis is built using the Smalltalk language and therefore we successfully learned VisualWorks Smalltalk IDE for development of our application. This was accomplished by using online tutorials and academic resources to become proficient in the use of Smalltalk.

As part of our core system functionality, we needed a framework in order to be able to implement an SNMP manager. This was accomplished using an unmaintained framework preview that was last released in 2002 by VisualWorks. There was literally no documentation included with it, besides a small ‘Readme’ file. The implementation of the framework included a lot of experimentation and debugging line by line to understand its operation. There were also modifications to existing base classes since its initial release and finding bugs associated with those updates were challenging. Through the modification and the debugging process, we were successfully able to use this framework to implement an SNMP manager capable of sending and receiving encoded SNMP messages. By committing these changes to the public Smalltalk repository, we were able to contribute back to the Smalltalk community by isolating and fixing these bugs for others.

After creating our main program functionalities, we needed to integrate it with Atlantis. A major achievement was implementing the open source Atlantis Developers Kit (ADK) to develop our own controllers to create a customized process. This is the first time this has ever been done successfully. As we had found issues within the ADK we had been involved with SAGETEA Group to bring the kit up to date. Again, as this had never been done before, there was little documentation on the correct way to implement custom controllers and required multiple iterations of experimentation and correction. We were able to effectively debug and correct any issues in the controllers despite the fact that the server does not provide detailed error information and required multiple trials.

Throughout this process, we contributed to SAGETEA Group and the development of Atlantis as we provided feedback about specific bugs and possible improvements on the existing technology. This was later converted into multiple new releases of the product which could potentially reach their customer base.

We were also able to bring Atlantis’ capability to a new level by overriding the basic automatic business workflow interface and prompted SAGETEA to allow us to implement our own interactive GUI. This adds multiple dimensions to the uses of Atlantis as it can be used for commercial applications.

Another major accomplishment was that we were able to successfully create a working prototype which SAGETEA Group has considered licensing for new telecom customer projects. This demonstrates the strong commercial viability of our system and possibility for future use.

There are three major categories of accomplishments throughout this project. These include learning and developing within the Atlantis environment, understanding SNMP standards and implementation using Smalltalk and in using those to create a working prototype for a network alarm monitoring system.

Another major accomplishment in our project was to evaluate Atlantis technologies on various metrics. These include performance of executing real time controllers, rapid development of real time applications, and modeling databases. It has been demonstrated that Atlantis is an effective modeling tool for real-time applications and databases.

2.0 The Engineering Project

2.1 Health and Safety

Standard computer lab health and safety regulations were followed for the duration of the project. Given that the project is a purely software project the safety hazards are minimum. We still followed the General Health and Safety Principles and Basic Safety Procedures as outlined in section 5 and 6 of the University’s laboratory health and safety manual respectively, as well as the general rules and responsibilities for the usage of computer labs on campus (section 4).

2.2 Engineering Professionalism

Engineering is a very well respected profession which has its codes of ethics and conduct. An engineer has to be a role model in society and behave in noble ways. An engineer’s highest priority is towards the public’s well being and safety as well as striving for excellence in all aspects of his career and life. During this project we had to take several aspects of engineering professionalism into consideration. One of them was dealing with intellectual property professionally. The software tool that we used through the project, Atlantis Technology, was invented by Mr. David Long. Since Atlantis is still in development and was continuously updated we were given access to his latest software and to unrestricted product keys. We had the responsibility of maintaining Mr. Long’s IP private as the Engineering code of Ethics mandates.

The project was developed as a group, and during this project several disputes have occurred regarding different aspects of the project. These disputes, when they arose, were handled in a very professional way, without demeaning or disrespecting each other, which resulted in a positive environment for everyone to work in.

Finally, one of the most important aspects of being an engineer is the constant strive for excellence in all aspects of an engineer’s life and career. Throughout the project we have sought to achieve excellence in all aspects of the project, from the written deliverables to the actual execution and presentation of the final prototype. In all, engineering professionalism was a very important part of our project that helped us obtain the result we have aimed for.

2.3 Project Management

Coordination of a project of this scale takes careful consideration and planning. It involves a great deal of communication between the members of the group as well as with the supervisor and external contributors. Several project management skills, both technical and interpersonal have been used to manage and coordinate this project.

For the management of this project, we followed these main organizational guidelines:

1. Define project specifications

2. Project planning

3. Agree on work distribution

4. Manage and review individual and team progress

5. Complete Project

Define Project Specifications: The specifications of the project were defined. These were a large part at the beginning of the project given that this is a relatively new project; not much understanding of the project itself existed. Through several meetings with Dr. Gabriel Wainer, project supervisor, and Mr. David Long, CEO of SAGETEA group, we were able to finalize the main project requirements. With these specifications we were able to continue to the next step.

Project Planning: With the requirements in hand, the planning of the project was made. This included creating an objectives timeline, defining what resources were going to be needed for the project such as computers or personal accounts in the laboratories, software resources etc. A meeting schedule was also set amongst the team members. Finally, we decided to use the Waterfall model as a guideline for the development of our software.

Agree on work distribution. The project was distributed into different manageable tasks, such as research areas at first, software implementation and testing areas later on the project. Towards the end of the project, the writing of the final report was also divided into many sections some individual and some collaborative. The distribution of the work was constantly being communicated amongst the team members especially when a change was made.

Manage and Review individual and team progress : To manage the project at a software design level, the Waterfall Model process was followed. The following stages of development were followed:

1. Requirements

2. Design

3. Implementation

4. Testing

During the requirements stage, we met with SAGETEA Group and Dr. Wainer to gather all the requirements and to create the set of functional and non-functional requirements for this project.

The design of the software followed, during this stage, the group met with Dr. Wainer and Mr. David long of SAGETEA Group in order to finalize the design choices according to the capabilities of Atlantis Technology and the recommendations of Dr. Wainer. The design choices were made to meet the requirements laid out in the previous development stage.

During the implementation stage, several iterations of debugging along with trial and error ensued. The implementation of the application was divided according to its different functionalities and was distributed amongst the team members. The final integration of the application took place at the end of the implementation stage.

The testing stage ran almost concurrently with the development stage, since, as mentioned before, each functionality was tested individually and the final whole system integration test was done at the end of the development process.

Throughout the project, the team progress was constantly being reviewed both formally and informally. Formally, we presented a progress report document to Dr. Wainer and a formal oral presentation to Dr. Wainer and Dr. Cuhadar. Informally, the progress of each individual member was constantly gauged to ensure that the group was meeting the set deadlines. This was done also to motivate and assist each other during the process in case any difficulties may have risen.

Complete Project: This final stage of the project was achieved by coming together to prepare the final deliverables of the project. One of such was the Poster Fair, for which the group prepared a final working demo of the prototype developed throughout the year. To accompany this demo, a set of posters were prepared as well for the showcasing of the project. This final project report is the final symbol of project completion. Upon finalization of all the project requirements for the CNAMS system the team had to write a final technical document detailing all the steps taken to design and completes the system.

2.4 Individual Contributions

2.4.1 Project Contributions

2.4.2 Report Contributions

3.0 Background Information

Some background information is required for the understanding of this project. In this section, background information on network monitoring tools, the Simple Network Management Protocol (SNMP), SmallTalk and Atlantis technology are given.

3.1 Network Monitoring Tools

In today’s world, global data communications has become extremely important in the business world. Data networks are at the backbone of many of the critical services that we have come to rely on, including voice communication, the Internet, ATM banking access, corporate networks, among others. With the pervasive expansion of these networks it is crucial to be able to manage these systems. A disruption caused by a faulty network component could lead to lost business revenues, frustrated users or the loss of critical data. A solution to this problem has been the introduction of network management systems which relay information about the internal network to network technicians to spot and debug any problems.

Network management allows organizations with complex data networks to save time and improve efficiency by collecting operational data from the network and administering it to the network technicians who govern them. The basic functional model for a network management system is shown below in Figure 1.

Figure 1 General Network Monitoring System Model

The network administrator uses the network management ‘manager application’ to view the data that is relayed by the managed devices that are located within the network. These types of managed devices can include routers, switches, local hosts, gateways, printers etc. Basically any Internet Protocol (IP) based device that implements the specified management protocol can be monitored. For our system, we have implemented the Simple Network Management Protocol (SNMP), as it is very widely used in the industry.

Network management is a broad term which covers five main areas: [1]

• Fault Management (discovery of problems)

• Performance Management (measuring network device performance)

• Configuration Management (finding and setting devices in the network)

• Security Management (setting access rights)

• Accounting Management (tracking usage statistics)

The main functional area of our project focused on implementing fault and performance management. The system will be looking for fault information from the devices when they are not operating normally. This mainly includes, link up/down messages, rebooted devices and the reporting of offline or unresponsive devices. From the performance side, the system will be gathering performance statistics such as system up time, link usage and link trend data. This helps in giving the technician an overview of how the system is performing over a certain period of time.

It is critical for the system to be able to receive and process this data in real-time with a way of generating reports so the technicians can debug problems as they happen, as well as profile their network on many performance and operational levels. The system can then also have a variety of alarm notifications through the use of visual reporting, email or text messaging.

Network monitoring tools are a core tool for network technicians to ensure proper operation of the devices within their networks. By utilizing various aspects of network management, i.e. fault and performance management, it will be possible to create a system that is both compact and effective for the target markets.

3.2 SNMP

The Simple Network Management Protocol is part of protocol suite developed by the Internet Engineering Task Force. SNMP is an application level protocol and operates on top of various transport layer protocols. It is a widely used protocol in network management systems to monitor network elements such as routers, switches and computer hosts and it allows network administrators to manage performance of the network, locate and resolve network problems and plan for future network growth [2].

There are three basic components in a network that is managed using SNMP, Network Management Systems (NMS), managed devices and agents. Managed devices are the network elements being monitored using SNMP. Every managed device contains an agent. Managed devices collect information relevant to the network and make it available for the NMS to use through SNMP. Examples of managed devices can be routers, printers, computer hosts, hubs, etc.

An agent is a network management software that resides in the managed devices. Agents are usually developed by the manufacturer of the device and come as a standard feature. An agent has knowledge of all the management information collected by the devices it resides in and its job is to translate that information into a form that is standard and compatible with SNMP.

A Network Management System is a machine that runs an application that monitors the managed devices. NMS’s do most of the processing and work required for network management and therefore require the bulk of memory and processing power of the managed network.

SNMP protocol provides a standard way for the NMS to communicate with the agents in the managed device and collect all the information necessary for the end user to make sound decisions about the network.

This information can be obtained by the NMS in two different ways; polling and autonomously. In polling, the NMS continuously requests for the required information at a certain frequency. Simulataneously is when the agent sends information automatically to the NMS whenever a threshold is met or a critical alarm is detected. For example, an alarm message could be sent automatically by an agent to the manager if a router’s temperature has passed a certain threshold.

SNMP Agents store their variables in management bases and operate in reserved ports 161 and 162 [3]. SNMP itself does not define which information (which variables) a managed system should offer. Rather, SNMP uses an extensible design, where the available information is defined by management information bases (MIBs). A MIB is a collection of information that is organized hierarchically, they are made up of managed objects and said objects are identified by their unique object identifiers. A managed object can be any of the characteristics of a managed device, for example, in a router; its system up-time can be a managed object. An object identifier is the unique identifier for each managed object in the MIB hierarchy. The MIB hierarchy can be visualized as a tree as seen in Figure 2.

Figure 2 MIB Tree Structure [4]

Due to the heterogeneous nature of networks, different types of managed objects with different hardware and data representation techniques will exist, some of these incompatible with each other. SNMP takes this into account by using a subset of Abstract Syntax Notation One (ASN.1) in order to provide homogeneity in communication between the devices.

In telecommunications and computer networking, ASN.1 is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities. For further information on SNMP, please refer to the documents published by the IETF, specifically RFC 1157.

3.2.1 SNMP Message Format

A high level overview of an SNMP message as it travels through the net can be seen in the following figure:

Figure 3 SNMP packet structure

A little explanation is necessary of each of the components of an SNMP Message. An SNMP message’s Protocol Data Unit (PDU) represents the SNMP frame. The following descriptions summarize its components [5]:

• Message Length.- Defines the Length of the SNMP message

• Message Version.- Defines the version of the SNMP message

• Community String.-Defines the community to which the SNMP message belongs to. Can be used as a form of authentication.

• PDU Type.- Specifies the type of PDU Transmitted

• Request ID.- Used to associate an SNMP request with its corresponding response

• Error Status.- Indicates the type of error if there is one

• Error Index.-Used to associate an error with a particular object

• Variable Bindings.-This is where the data sent by SNMP is stored.

3.3 Smalltalk

Smalltalk is a ‘purely’ object oriented language, developed by a group of researchers led by Alan Kay at Xerox Palo Alto [6]. There are many versions of Smalltalk existing in the market today. The first version was Smalltalk-71 which was based on the simple idea of message passing [6]. Then after several revisions, Smalltalk-76 was created which included a development environment with most of the tools of current IDEs such as a class library, code browser, and editor. Finally Smalltalk-80 version 2 was the first version released to the public outside of Xerox Palo Alto [6]. This version of Smalltalk was made to be platform independent by adding Meta classes to keep everything as objects [6].

Two of the popular variants of Smalltalk are Squeak and Visualworks. Visualworks is derived from Smalltalk-80 Version 2. Smalltalk was focusing on the concept of message passing between objects and considers primitive types as objects too. This is why Smalltalk is considered a ‘pure’ object oriented language. Objects in Smalltalk can send and receive messages to other objects. Classes in object oriented language are used to describe the properties and behaviours of the instances. Smalltalk syntax uses punctuations in English like manner than a programming language manner. This makes the coding easier but there is a learning curve associated to it.

3.3.1 Role of Smalltalk within Atlantis

Atlantis Server and Client were built using Smalltalk and they can naturally execute Smalltalk code without any additional components. This makes controllers simpler and more efficient because they don’t need to add additional language support to execute a process file.

3.4 Overview of Atlantis

Atlantis is a process modeling technology which provides rapid development and deployment of real-time applications. Atlantis generates real-time controllers that can be applied to a variety of applications including business processes or other event-driven applications. Atlantis is 'event-driven' and has the ability to handle them in real-time.

Atlantis Technology was developed by Carleton University Alumni David Long. It was invented in 2001 and was filed for a US Patent. Atlantis is built entirely using Cincom Smalltalk and Smalltalk is used as the main development language within Atlantis.

3.5 Components of Atlantis

Atlantis consists of 3 components: Atlantis Developer, Server and Navigator. The sub-sections that follow will give a general background on each component and how they interact with each other in order to develop a fully functional application.

3.5.1 SAGETEA Developer

SAGETEA Developer is the primary design tool for an Atlantis Process. The Developer takes a natural language problem description of a business process and uses it to create a controller for that process. The controller created is simple and contains all the information necessary to create or connect to a user interface, a network and database for almost anything that can be expressed in words. An open source Atlantis Developers kit exists so that expert users can modify and expand the controller created by the Developer. Figure 4 below shows a screenshot of the SAGETEA Developer.

Figure 4 SAGETEA Developer

The developer follows an intuitive object oriented methodology for the storage of data. The database model can be seen below in Figure 5.

Figure 5 SAGETEA Database Model

This model follows an object-oriented approach. Every entity involved in the process is an ‘Element’. An element can be any object that you specify. These elements are contained within a ‘Group’ which is associated with an ‘Activity’. Any number of activities can be found within the current state of the process, from which there can be any number of states also.

3.5.2 Atlantis Server

The Atlantis server is the backbone of the system and it runs in the back end executing the process created by the developer. The server is event driven and takes external or internal information, treats it as events, processes the events according to the created controller and relays the result to the Atlantis navigator. The figure below shows a screenshot of the Atlantis Server.

Figure 6 Atlantis Server

3.5.3 Atlantis Navigator

The navigator is an integrated browser which serves as the front end of the system which allows the end user to view the results of the process created and interact with it in real-time. The information displayed on the navigator is obtained from the Atlantis Server and the processes it controls. The Navigator itself has been overwritten in order to generate a more custom user interface and add functionality for different applications using the Atlantis Developers Kit.

3.6 Process Controllers

Atlantis System needs two process controllers, one for the server and one for the client. Default controllers for Atlantis are made with the intent of modeling and deploying business processes. The Atlantis server runs the server controller and the Atlantis Navigator runs the client controller. Controllers define the execution of the system and the state of the system. The system changes states based on receiving external/internal events.

3.7 PostgreSQL Database

PostgreSQL database is an open source object relational database management system. The Atlantis server uses PostgreSQL database to store and access information needed by the server during running and loading of the process file. The server will do all the necessary actions such as creating and removing tables as needed by the running process, as well as storing user credentials. During execution of a new process, Atlantis Server will also create the new tables needed. When a process file needs to store persistent information, Atlantis Server will automatically store that information in a table and will correctly retrieve it later. PostgreSQL is the database used by Atlantis by default but Atlantis can support any object relational database management system.

3.8 Network Setup of Atlantis

Atlantis has the ability to be both a localized or distributed application. After the process and controllers are created in the Developer, the file is brought to the Atlantis Server where it will be deployed. Atlantis Server, being the backbone of the system, can interact with the client side processes in a distributed manner. That is, the server can be located at another location on a Local Area Network (LAN) or across the internet (see Figure 7). The IP address of the server must be known by the client in order to log into the server and view the created process. Multiple clients have the ability to login to the server simultaneously to interact with the current process and the server also manages any information that needs to be stored to the database.

Figure 7 Network Setup of Atlantis

At the server end, the SQL database is used to manage the user credentials for logging into the system, as well any database functionalities present within the created process. This SQL functionality works fully with the PostgreSQL software suite as it is an object-oriented relational database management system (ORDBMS). This database can be located at a remote location with any type of replication system in place to backup the data. The system uses the CORBA marshalling protocol to communicate between these two entities.

3.8.1 Configuration of Atlantis Server

When developing an application with Atlantis, there are predefined steps that must be followed in order to properly model and deploy a solution. The initial stage comprises of obtaining a model from the expert user. The expert user, whether it is a software developer or business professional, uses the Developer to model the problem and create a process, by selecting their own controllers and configuring any database design they will be using.

With a business application, default controllers are selected. In the case of a software developer, the controllers themselves must be programmed manually containing all transitions, events and actions that the server will perform at various stages in the process. This also includes the initializing state from where the system will start executing and recurring routines the server must execute. The controllers and the states themselves are object oriented and must be inherited from the default controllers and state classes in order for the server to understand them. This is accomplished by utilizing the open source API known as the Atlantis Developers Kit (ADK) which provides these default base classes. The programmer must also load the ADK as well as any additional VisualWorks packages (parcels) with base class changes needed at this time.

The database design model, controllers with all the states, transitions and custom functionalities are then injected into a process file. This process file must then be loaded into the server in order to run the process. The server itself is an image file which runs on a cross-platform VisualWorks virtual machine. As the server begins, it instantiates and executes the controllers from the process file. Any events which trigger transitions of the system’s state are defined within the controllers.

There are both internal and external events which can trigger the system to change states. Internal events are those created by the server itself to execute a certain function and external ones are defined by the programmer within the controller classes. When an event comes in, it is placed in the system queue where it is then serviced by the Atlantis Server. Events are processed as they come in and trigger the system to change states to execute functionality to process the event. This may involve writing/reading objects to the database or updating the client side application in some way. The server continually services the events located within the queue until there is nothing present at which point it will continue to service internal events that are generated within the system. Internal events are given higher priority than external events because internal events are used to execute functions which are critical to the execution of controller or during the processing of another event.

The server shows how many events have been processed and provides automatic email notification upon errors. If there is a critical error within the process, the server will enter an ‘Offline’ state, at which point a notification is sent out and then enters an ‘Idle’ state. From here, the server will then reboot itself and attempt to restart the process.

3.8.2 Configuration of Atlantis Navigator

The Atlantis Navigator is another key component in the Atlantis system architecture. It provides you with a browser from which you can interact with the process that you have created and deployed on the server in real time. For business workflows, a form GUI is generated and it provides you with a query tool to search documents as well as a Process Control tool to link documents. It displays the documents and information for various users with secure access. PDF reports can also be generated from stored documents.

The Navigator itself runs on a similar concept to that of the server. It is a separate system defined by use of the ADK to create controllers, states and actions that the client will execute. For the purposes of this project, it was chosen to override this feature in order to allow for a much more robust, intuitive and fully customizable GUI application from which a commercial prototype could be developed.

4.0 System Designing Process

The system designing process we took aligned strictly with the standard software developing principles. The functional system requirements were gathered along with any non functional requirements. These requirements were strictly analysed to reduce ambiguities in the design of the system. The following software development diagrams such as use cases, sequence diagrams, and class diagrams were developed. These diagrams were used to model dynamic behaviour of the use cases.

4.1 Requirements

Having clearly defined requirements are extremely important in any software design project. Through various iterations of meeting with the customer we have refined a set of requirements that would meet the academic components of the project and the prospective prototype requirements. These are organized in terms of functional and non-functional requirements as listed below.

4.1.1 Functional Requirements

This system will provide alarm and performance monitoring of the network of a small to medium sized business. The network will consist of many nodes, including, routers, switches, hubs and NICs. The monitoring system will mainly cover two areas, alarm and performance monitoring.

The network elements connected within the network will generate information based on their current state of operation and performance metrics. The type of information it will generate will be alarms and performance information. For example the types of alarms generated could be network line card failure, non-responding network element or increase of network collisions. The type of information the system will be able to collect is that of the ones defined in the Network Element agent’s Management of Information Base. The system will need to be able to operate with various types of connected elements.

Once an alarm is generated, the network element will send the alarm message to the monitoring system. The monitoring system will process the alarm. It will initially identify the node from which it originated and recognize the type of alarm error. It will then assign a priority to the alarm and prioritize it accordingly. Alarms will be displayed on screen at the end user’s interface according to its priority. If the alarm type is critical, the Network Administrator will be alerted instantly through various notification methods, such as Email and SMS. All events will be stored in a data warehouse. The data warehouse is a database storage area which will store all event information.

The network elements will be pinged periodically to ensure their livelihood. The collection of data and pinging will be done by polling. The End user should be able to select performance measurements to be collected. All data collected will be stored in the data warehouse for user report generation. Data collected can include data throughput, collision count, etc.

The end user should be able to view all the nodes in the system, their current status and performance. They will also be able to view alarms currently being displayed on screen as well as generate alarm and performance reports of data currently stored in the data warehouse.

The system will be able to generate charts of the information stored in the data warehouse at the user’s request.

4.1.2 Non-Functional Requirements

There are multiple non-functional requirements that the system should meet. As this is a monitoring system, the system should be able to be deployed independently on an existing network. It is assumed that the network the monitoring system will be deployed on will be capable of using a common management protocol, namely, the SNMP protocol. It is also assumed that the size of the network will be of limited size, simulating a small to medium sized business. The system will be written in the Smalltalk language and built using Atlantis technology and its ADK kit which is an open source development platform.

4.1.3 Use Case Diagram

The following diagram and use case descriptions were generated from the requirements specified in Section 4.1.1.

Figure 8 CNAMS use case diagram

4.1.4 Detailed Use Case Description

These are the detailed descriptions of the use cases and actor details from the use case diagram in Figure 8.

Actor Definitions:

End User

This role is defined as the user who uses the alarm information from the management system, to monitor the faults and performance of all elements within their network. This actor requests alarm report information and other network metrics. They also set the performance measurements to be collected and are capable of viewing the system’s alarms and generate charts of them.

Data Warehouse

Stores the alarm information and system logs from the system.

Network Element

These are the individual nodes being monitored by the system. The network elements update the system with alarm and performance related issues. The network elements can be routers, hubs, switches, NICs or any other network devices capable of supporting of a management protocol.

Use Case Definitions:

Use case name: Process Event Info

Use case ID: UC101

Primary Actor: Network element

Secondary Actor: None

Brief Description:

Network element generates events for the system. The types of events generated by the Network Elements are alarms and performance statistic updates. For all the events, the system will identify the type, the originating network element, date and time and any other available information. The system then assigns a priority to the event and prepares it for usage. Includes Display Network Status, Store to Database

Pre-Condition: An event must be generated from a network element.

Flow of Events:

1. An event is received.

2. The event is identified and the details are extracted.

3. If it is an alarm or performance statistic, continue processing, otherwise reject.

4. If the alarm is critical “Contact Network Admin” use case is invoked.

5. The “Stored to DB” use case is invoked, by passing the details.

6. The system notifies the use case “Display Network Status” of the new event received.

Post-Condition: The event information has been processed.

Use case name: Store to DB

Use case ID: UC102

Primary Actor: Data Warehouse

Secondary Actor: None

Brief Description:

Updates the Data Warehouse according to the type of event received from the use case “Process Event Info”.

Pre-Condition: The use case “Process Event Info” has processed a new event.

Flow of Events:

1. Event details are received.

2. Based on the event type, the event is stored in different tables of the database within the Data Warehouse.

Post Condition: The event is successfully stored in the Data Warehouse.

Use case name: Display Network Status

Use case ID: UC103

Primary Actor: End User

Secondary Actor: None

Brief Description:

This updates the end-user’s display with the most current monitoring information of the network. The end user is able to view the Alarm Information according to their severity.

Pre-Condition: User is logged in to the system, and viewing the current monitoring data.

Flow of Events:

1. Most current network event information is received from use case “Process Event Info”.

2. The new information is then updated on the display, according to the user’s set preferences.

Post Condition: The event is successfully displayed with up-to-date information.

Use case name: Send Email

Use case ID: UC104

Primary Actor: End user

Secondary Actor: None

Brief Description:

Simple emailing and SMS functionality provided by the system so that the End User can contact a network technician or anyone he/she deems appropriate from within the system in case of an alarm.

Pre-Condition: An End User needs to send an email or SMS.

Flow of Events:

1. End User enters email address or cell phone number and carrier.

2. The system sends an email or SMS informing that there is an alarm in the system.

Post Condition: The Network Admin is notified of the critical alarm that has been received.

Use case name: Contact Network Admin

Use case ID: UC105

Primary Actor: End user

Secondary Actor: None

Brief Description:

If the alarm received by the system is ‘critical’ then inform the End user separately, either by email or pager, so that it can be dealt with immediately. Includes Send Email, extends Process Event Info