CONCORDIA UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING SOEN390 SOFTWARE ENGINEERING TEAM DEVELOPMENT PROJECT ITERATION 5

(1)

CONCORDIA UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING

SOEN390 – SOFTWARE ENGINEERING TEAM DEVELOPMENT PROJECT

ITERATION 5

SOFTWARE ARCHITECTURE DOCUMENT

Dr. O. Ormandjieva

Winter 2012

Prepared by Group "Midnight Crunchers":

Austin Takam Nzokam (9465413)

Dipesh Patel (9646876)

Michael Barry-Mancuso (9472258)

Rajan Jayakumar (9607692)

Razafindramary Robson (9564748)

Roger Makram (5572819)

Serge-Antoine Naïm (9334815)

Monday, March 26

th

, 2012

(2)

Revision History

Date Rev. Description Author(s)

2012-03-25 1.1 Updated many views, refreshed certain diagrams Rajan Jayakumar 2012-03-12 1.0 Initial SAD revision Rajan Jayakumar

(3)

Context

“What is the FSTS System?”

The scope of the SOEN 390 – Software Engineering Team Development Project – is to, as the name implies, create a large-scale software system, requiring formal processes to undergo requirements elicitation, system elaboration, conception, design, testing, deployment, maintenance, all the while keeping stakeholders in the loop and satisfied with the product being built. Students undertake this project as a team endeavor, since building such a large system required individuals from various backgrounds working together to form a common product, and delegation of various system parts and aspects to different developers to increase work velocity.

For the Winter 2012 semester, our project and stakeholders were assigned to students by the professor. The primary stakeholder is the Welcome Hall Mission (WHM), a mission dedicated to providing

assistance to individuals in need, by arranging food banks, mattress distributions, lodging services and working to help people get back on track in their lives.

The WHM approached us with a project in mind – to improve and modernize their Family Services and Tracking System (FSTS) software. The current iteration of their software is a legacy of the early 1990’s, running on DOS with a dbase III database system, and providing very little room for extension.

Our mandate is to evaluate, determine the system requirements, and develop a modern version of the FSTS system for the WHM. Functionality remains close to what the current system does, namely:

• Create Family Files • Search Family Files • Create Events • Assign Appointments

• Generate Statistical and Operational Reports • Run Events

Additionally, the system must allow extension to tasks in a better, faster and “modern” manner,

allowing features such as automatic identification of data from certain sources, using mobile devices for wireless use of the system, and quicker access to data.

Below is a table of who we have determined to be our stakeholders, and reasons why we have chosen them.

Who Relationship to FSTS Reason for being a stakeholder WHM

Employee • Uses FSTS to create and maintain family files. _{• Uses FSTS to generate statistical reports based} on Family and Event information in the system.

• Relies on application to perform his or her duties.

• Relies on performance of the system (quick data entry, no system failure, etc...) WHM Director • Uses FSTS to create and manage events

• Uses FSTS to create and maintain family files.

• Relies on application to perform his or her duties

(5)

• Uses FSTS to generate statistical reports based on Family and Event information in the system

• Relies on performance of the system (quick data entry, no system failure, etc...) • Relies on maintainability of the system • Relies on extendibility of the system WHM Client • Client information is registered in the FSTS as

a family file

• Relies on application to keep track of events and appointments

Application

developer • Models new application on existing FSTS _features • Must develop the application _{• Relies on maintainability of the system} • Relies on understandability of the system

*Note that WHM in the above table refers to the Welcome Hall Mission, our client for the SOEN 390 Project.

Functional View

For a full overview of the functional view of the new FSTS system, please consult team Midnight Cruncher’s Use Case Model document.

Process View

Below is a list of Activity Diagrams illustrating the process workflow the current major Use Cases in our system:

(6)

UC1.04 Synchronize Updated Family Information

(7)

UC2.02 Manage Event Types

(8)

UC3.0x Manage Appointments

UC4.0x Mark Attendees

(9)

Non-Functional View

The following areas of Non-functional requirements were determined and documented.

Functionality

This section lists functional requirements that are common to more than one use case. Alerts

The system can alert the user in case of any problems. Access Control

The system shall provide different functionality to different types of users, namely the employee, the supervisor and the administrator.

System Error Logging

The server logs system errors. Fatal system errors shall result in saving all the user work and then shut down the system.

Information Control

The system shall allow users to manage family files, events, alerts and statistical reports.

Usability

Task Completion Time

Depending on the task performed, the time taken for its completion directly depends on the user's activity, such as the average time the user needs to spend with family for a file creation and the time it takes for a user to generate specific statistical reports.

User Training Time

Users with good computer background, as well as users familiar with the current FSTS, shall be able to learn how to use the application in a comfortable manner within a couple of hours or days as it follows the Microsoft GUI standards. For users not very familiar with such applications, further training in computer usability should be required before using the available soft copy of the application's user manual.

Reliability

Availability

We expect maintenance access to be available in times where the organization does not schedule meetings with families (average of 33.33% of weekly time for access). We expect normal usage of the system to be available at all times, which includes fetching/printing event or family information during maintenance.

(10)

Accuracy

The system shall always be accurate in providing information such as exact statistical reports on specific family information as well as providing accurate system search results.

Mean Time To Repair

The FSTS should recover within an hour of repairs if a failure occurs. Mean Time Between Failures

We expect mean time between failures to be no less than 12 months.

Performance

Response Time for a Transaction

The system shall respond to the user in less than two seconds from the time of the search and data entry request submission. Statistical reports should take less than 5 seconds to generate. In the case that any of these response times often take longer to process, the developers will look into the issue. Capacity

We expect the system to grow between 55 000 and 100 000 family entries, and therefore shall accommodate transactions for an average of 1000 families per week. We also expect the system to support between 4 to 15 concurrent users for transactional purposes.

Supportability

Browser Compatibility

According to the company’s (Welcome Hall Mission) IT Manager, Internet Explorer 8 would be the only browser used, and this would not change over an undetermined period. As such, every component of the system must adhere to meet this compatibility issue.

Database

Given that the “old” FSTS uses dBASE III, the “new” system would make use of MS SQL. This is to ensure easy transfer of data from the “old” system to the “new” one. This transfer is made possible by the existence of the compatibility between the two database as stated on the Microsoft website:

http://msdn.microsoft.com/en-us/library/aa337084.aspx

Coding Standards, Naming Conventions and Class Libraries

Given the existence of coding standards already in use, the new FSTS makes use of the Coding standards put in place by Microsoft. A complete document is available online at

http://social.msdn.microsoft.com/Forums/en/csharpgeneral/thread/f75d6cb4-084f-4f2a-95c0-6d7f1b67c978

Maintenance access and utilities

Given that the maintainers of the FSTS would not be the present developers, the system is structured using the MVC architecture. In addition to an increase in separation of concern that the architecture provides, the system becomes more maintainable, and components become more reusable.

(11)

Constraints

Database

As mentioned in section 6.2, the MS SQL database choice was because of the easiness in data transfer with the existing dBASE III databse.

Choice of Programming Language

The developers of the new system are in their 3rd year of studies in the Software Engineering program. The choice of the programming technology being the ASP.NET framework using C# is mainly for the learning purpose, thereby increasing their skills and competences.

Deployment Platform

Given that certain requirements of the FSTS requires the usage of the iPad in which the browser compatibility would be an issue as stated in section 6.1, it is required to adapt the system for the Safari browser as well.

Hardware Requirements

The iPad, being a portable touch-screen device, the user interface would differ from the common web interface. As such, a different user interface or an adaption must accommodate the iPad users.

Principles and Architecture Justification

We have chosen to use the Model-View-Controller architectural principle for the elaboration of our second FSTS system. We offer a summary of our reasoning below.

Potential Architectures: • N-tier architecture

• Layered Systems (Could be implemented using the 3-tier architectural style)

• Event-based Systems (A component does not need to announce an event to other components) • Model View Controller

Preferred Architectures: • 3-tier architecture • Model View Controller

Comparison and contrast of our preferred architectures and our choice:

Model-View-Controller 3-tier Architecture

Similarities It is an advanced form of the 3-tier

architecture in which the Model is the Data, the View is the Presentation and the

Controller is the Application

Encourages a high degree of separation of concerns, thereby increasing usability and testability

(12)

Topology Triangular: the View sends updates to the

Controller, the Controller updates the Model, and the View gets updated directly from the Model

Linear: all communication must

pass through the middleware tier

Abstraction Hides away the details of how the architecture

is implemented Refers to the physical structure of an implementation

Technology

used (ASP.NET) Offers various integration points and flexibility thereby increasing maintainability No integration points offered

For the aforementioned reasons, we have decided to use the MVC architecture principle for our product.

Logical View

Please find the current logical view of the system enclosed below:

Interface View

As we are using Microsoft’s Visual Studio, we are relying on the .NET Framework for easy interface accesses between our model (the MS SQL database), the view (our CSHTML frontend), and the controller (the C# CodeBehind files).

(13)

More information about how Microsoft implements the MVC architectural pattern in the .NET Framework version 4, which we are using, is available at the following link:

http://msdn.microsoft.com/en-us/library/dd381412.aspx.

Design View

(14)

Infrastructure View

Please find the infrastructure view of our system enclosed below:

Deployment View

The Welcome Hall Mission IT division will deploy the new FSTS onto a (Dell) multicore server, running Windows Server 2008 R2, Microsoft’s Internet Information Services (IIS), Microsoft SQL Server 2008 or 2012. This server will host the FSTS web application to a series of thin clients, running Windows 7 and accessing the system through HTTP requests, using Microsoft’s Internet Explorer 8 browser.

Mobile devices will access the application through a secured internal wireless (Wi-Fi) network, locally at the WHM. We recommend using a WPA2-standard encryption on this wireless network, either Personal with a strong passphrase, or Enterprise with user account privileges.

The above are the deployment specifications provided to us by the customer.

Operational View

IT operators can manage system operations through the Internet Information Services Console (IIS Console) on the hosting server. This includes system management, user access rights, logging, updating,

(15)

etc. The FSTS application will offer limited administrative functionality for features within the scope of the software, such as field information, reports management, event management, etc.

Security View

As the WHM deploys the FSTS system internally with no access to the external internet, security is limited to user-access privileges between WHM employees and IT administration. As such, web-based authentication and encryption is not required for our application, and we use standard Windows-based user login to identify users and assign appropriate privileges in the system.

The WHM IT department administers the security of the server and individual physical components of the system, but individuals depend on an Active Directory of users, set within the central Windows Sever 2008 R2 machine.

(16)

Data View

(17)

Technology Selection

The majority of the technologies we chose are due to client constraints; the WHM obtains licenses from Microsoft for a majority of their products, and computer systems from Dell. As they already had these resources in place, they requested we use them if possible.

Additionally, for our professional development, our team determined that learning to program in C# and using the .NET Framework for the project would provide many opportunities to learn new technologies currently in demand in the IT sector, and display our talents in our future projects, academic, personal or professional.

The above justifies our selection for most of the system. The remaining choices are due to the nature of a Web application – technologies such as JavaScript, and AJAX by extension, are the standards used in this domain, and were therefore determined by the Web domain.

Finally, within the Postal Code to City and Province mapper, the application uses a SQLite database. We downloaded the database from a free-use website on the Internet for this purpose. It is available here: https://drupal.org/node/255995

CONCORDIA UNIVERSITY DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING SOEN390 SOFTWARE ENGINEERING TEAM DEVELOPMENT PROJECT ITERATION 5