PROJECT SECME

High Level Design

SOFTWARE ENGINEERING FALL 2002

 

Modification history:

Version

Date

Who

Comment

v0.0

08/15/00

G. H. Walton

Template

v1.0

10/22/02

Carthik A Sharma

Initial Version - Submitted

...

 

 

 

 

 

Team Name: TEAM SECME

Team Members:

Contents of this Document

High-Level Architecture

Design Issues

High-level Architecture:

Architecture of SECME

 


 

 

 

 

 

 

 

Details:

-          Client will interact with the system via a browser through HTTP

-          Tomcat 4.0 will host all Java Server Pages and Business and Service components

-          Presentation Layer will provide content generation services. It will use Business Layer for retrieval or updation of data

-          Business Layer will provide all business related functionality. It will use Service components to for common services.

-          Service components will provide common functionality across system.

1.        Connection Manager will provide access to database connection that will be used by business components to access database

2.        Email component will provide functionality to send emails via SMTP server

-          Database will store all information required for system operation.

 

Design Issues:

1)       Reusability

The system is designed as an open-ended system insuring easy modification, addition of new events and schools each year. This system is meant to be reused for the later years, and the modules that implement the various functions can be safely reused as such.

 

2)       Maintainability

Maintenance engineers need to be familiar with Java Technology since Java will be used to develop the system. The only required maintenance is of enhancement issues. If the client requires the system to be enhanced, she will need to contact someone with a good knowledge of Java Server Pages , SQL and web page design.

 

3)       Testability

Functionality of the system can be thoroughly tested to its limits insuring a reasonably high quality product.

 

4)       Performance

The system being developed is to be used by MECSP. Since the basic objective of the project is to make it easy for the personnel to post new events and receive manageable data of its registration, it is required that the system be efficient and user-friendly. It will be mostly a point, click and type in required fields type of interface. The system will be robust enough to perform stably under all input data conditions.

 

5)       Portability

Java is a portable language making this product portable too. This was a major design issue, and this influenced the choice of the language and the tools, since the cost of the project is to be kept minimal, we needed to use portable, free development tools and develop portable software

 

6)       Safety

The system will be reliable and robust.

The system should ensure that only authorized personnel are allowed to use the system and exploitation of the system is prevented.

 

7)       Security

To implement a security system for the product, we had to design a secure log-in log-out system to ensure that misuse of the registration procedure does not happen.

 

 

 

Issues Relevant to the Project:

 

1)       Time Issues in order to meet the product deadline.

2)       Developers are new to the Java tools such as JSP, Java Beans, and Servlets. The steep learning curve calls for more man hours from the team members.

 

 

Technical Difficulties Expected:

 

1)     Some difficulty is expected in generating the summary pages due to the inexperience of the team members in SQL.

2)       Uploading the functional website and installing the server on the UCF server will be a challenging task, due to the need for cooperation from the UCF employees, and our relative ignorance of web server implementation.

3)       The degree of complexity of the project increases with the phases

               

Solving the difficulties :

 

1)       A lot of work is required from the project team.

2)       In order to minimize the increase in complexity, the objective of the team will be to implement the functionality proposed in the requirements on a priority basis, with the optional requirements being implemented after the compulsory requirements are met.

 

Design trade-offs made in the selection of this architecture

 

1)       We decided not to use the Micosoft Technologies such as Active Server Pages, and Visual Basic to implement the various architectural modules. This is based on the fact that one of the team members is versed in Java technologies and so the steepness of the learning curve can be reduced.

2)       Most of the decisions as to the components to be used were made based on the availability of suitable development tools in the laboratories at UCF’s SEECS.

 

 

What was your rationale for selecting this architecture?

 

                This system has been developed thus to be able to successfully implement a web based registration system. This is modeled upon similar successful web based applications.

Since we use Java Technologies, we have the Presentation Layer consisting of the Java Server Pages, and the Business Layer consisting of the beans. The Service Components are used by many of the modules in the business layer, and so it is shown as a separate component in the design. A major factor in this representation of the architecture is the need for lucidity in explaining the structure of the system.

 

That technical risks are involved in this solution?

 

                There are no considerable risks involved in this solution, as far as the architecture and design are concerned. The risks to the product are external, such an non-availability of server space, and problems associated with future maintenance.

Technically, the main risk involved in the project is the evolution of Java itself. Java development keeps changing and progressing. This language evolution will cause maintenance problems. The project may need to be modified to accommodate the change of the library (Java class).

 

Template created by G. Walton (GWalton@mail.ucf.edu) on August 15, 2000

This page last modified by Carthik A Sharma (appcash@yahoo.com ) on October 21, 2002