Transcript Computer Monitoring System for EE Faculty

Computer Monitoring System
for
EE Faculty
By
Yaroslav Ross
And
Denis Zakrevsky
Supervisor: Viktor Kulikov
Presentation contents
General
System Design
Website
Monitor service
Design patterns
Possible improvements and questions
Project Goals
To create computer monitoring system.
To use different web and windows OS
technologies.
To experience in software systems and
database design.
Technologies Used
MS .NET 2.0
ASP.NET 2.0
ADO.NET 2.0
MS SQL 2005
HTML
Java Script
CMS
(Computers Monitor System)
General.
The purpose of the system is to avoid PCs
"disappearing" on EE faculty.
It gives possibility to insert and store
information about faculty computers,
system users and other management
information and checks computers state
( monitoring ) every period of time.
CMS
(Computers Monitor System)
General.
The CMS contains three major sub systems:
1) Web Site.
2) Service.
3) Data Base.
System Design
Web Site Server
DB
User
End Station
Administrator
Windows Server
Service
Faculty PC
Faculty PC
Faculty PC
Faculty PC
Use Cases
A use case defines a goal-oriented set of
interactions between external actors and
the system under consideration.
Actors are parties outside the system that
interact with the system.
An actor may be a class of users, roles
users can play, or other systems
Use Cases
EE Monitoring System
Change Password
Login
«uses»
User
Monitor
Check Computer
Status
Change computer
status
Change system
settings
Update Database
Add Update-Delete user
Add Update-Delete computer
Add Update-Delete Building
Add Update-Delete Room
Administrator
Web site
All user interface (settings, data changes
and data view) of CMS is done using the
web site.
The web site consists of three layers:
- Presentation layer.
- Business logic layer.
- Data access layer.
Web site layers
Web site layers
Presentation Layer (User Interface):
- Web controls ( reuse ), all logic implemented in
C# classes, which inherits from
System.Web.UI.UserControl .Net class.
- Web pages (master page based, CSS used to
avoid duplication, Java script used for custom
controls), all logic implemented in C# classes,
which inherits from System.Web.UI.Page .Net
class.
Web site layers
Presentation
Layers
BLL
Web site layers
Business logic layerBusiness Logic Layer (BLL) serves as an intermediary for
data exchange between the presentation layer and the
DAL. In "real world" application this layer can contain
large functionality like: security constraints for data
based on user permissions, data operations and other
business logic. In CMS the main functionality of BLL is to
transfer data from Presentation Layer to DAL. Small
amount of logic and some minor data operations. This
layer created mostly as contribution to right design of
such application and it makes easier future application
development and improvement. The number of classes
in BLL is as a number of logic entities in the system.
These classes are presented in figure.
Web site layers
Business Logic Layer (BLL)
Buildings
BLL
Rooms
BLL
Computers
BLL
Settings
BLL
Configuration
BLL
Permissions
BLL
PC
Status
BLL
Users
BLL
Web site layers
Presentation
Layers
BLL
Data Access
Layer
Web site layers
Data Access Layer The MS recommended approach, for right software
architecture of Websites is to separate the data access
logic from the presentation layer. All code that is related
to data source – such as creating a connection to the
database, issuing SELECT , INSERT, UPDATE, and
DELETE commands, and so on – is located in the DAL.
The presentation layer should not contain any references
to such data access code, but should instead make calls
into the DAL (via BLL in our case) for all data requests.
Data Access Layers contains methods for accessing the
database data. The DAL is written at C# language and
strongly uses ADO.NET (2.0).
Web site layers
BLL&DAL class diagram
Web site layers
Presentation
Layers
BLL
Data Access
Layer
Database
Data base
Data base implemented on transact SQL
using MS SQL server 2005.
For each table there is a set of stored
procedures (SELECT, UPDATE, INSERT,
DELETE).
The DB is normalized, all tables contain
primary keys that used if necessary as
secondary key in other tables to prevent
data duplicating.
Data base
The data base consists of following tables:
Users: (set of available users with personal information, password,
and permissions).
Permissions (set of available users permissions).
Computers (set of all available computers with IP, place, name,
status).
Rooms (set of all available rooms).
Buildings (Set of all available buildings).
Computer Status (set of available statuses).
Connection Look up (set of all ports that will be monitored).
PC Connection Status (holds the information of monitoring results
for all monitored ports for each computer).
Configurations (set of different monitor configurations contains
repeat time, mail address etc.).
CMS Database table diagram
Monitor service
The Monitor Service is part of CMS project that
responsible of scheduled faculty PCs
monitoring. It is implemented as Windows
Service and need to be installed, on server. The
service created using ADO.NET on C#
language.
Monitor contains dataset (DAL), based on
ADO.NET, all data manipulations done through
it. The dataset contains strongly-typed data
tables and table adapters, which call the store
procedures from database, and transfer\receive
data.
Monitor service
The service activity depends on timer control that invokes monitor
run every period of time (this period of timed stored in database and
can be changed via the website). The monitor checks all existing
PCs in database, which should be online, sends pings and tries to
create socket connections on different ports that defined in system
settings. If none of connections is successful, mail about such PC
sent to system administrator (email address must be defined in
system settings via website). The mail sending procedure is quite
"expensive" in time concept, and not depends on the monitoring
itself, so this is done in separate thread, using multithreading
mechanism that .Net provides.
Test application is also added to monitor, in order to run application
without installation. The test application implemented as Windows
Form, which invokes the timer\monitor
Monitor Dataset
Monitor class diagram
Design Patterns
Design pattern is a general repeatable
solution to a commonly occurring problem
in software design. A design pattern is not
a finished design that can be transformed
directly into code. It is a description or
template for how to solve a problem that
can be used in many different situations.
Design Patterns
Singleton (Creational pattern):
The singleton pattern is implemented by creating
a class with a method that creates a new
instance of the class if one does not exist. If an
instance already exists, it simply returns a
reference to that object.
Singleton
-singleton : Singleton
-Singleton()
+getInstance() : Singleton
Singleton in the project
Class MonitorUtils (Lazy Initialization)
Table adapters in BLL
ADO.NET connection to SQL database is
built as singleton
Design Patterns
Observer (behavioral pattern):
The observer pattern is a design pattern used in
computer programming to observe the state of
an object in a program. This pattern is mainly
used to implement a distributed event handling
system. The essence of this pattern is that one
or more objects (called observers or listeners)
are registered (or register themselves) to
observe an event which may be raised by the
observed object (the subject). (The object which
may raise an event generally maintains a
collection of the observers.)
Observer pattern UML diagram
Observer in the project
Timer in Monitor service (easy to show).
Built in for many web controls and pages
(buttons, combo boxes and etc).
Observer in the project
serviceBase
*
1
Timer
+elapsedEventHandler()
+elapsed()
Monitor
+timer1_elapsed()
Possible improvements
Multithreading can be used in monitor in
order to improve performance.
The system can inform the administrator
not only by email, but also by SMS.
AJAX technology can be used to improve
site performance.
Using ASP.NET membership to receive a
built in way for validating and storing user
credentials.
Questions?