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
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
Table of Contents Context...4 Functional View...5 Process View...5 Non-Functional View...9 Functionality... 9 Usability... 9 Reliability... 9 Performance... 10 Supportability... 10 Constraints... 11 Database... 11 Choice of Programming Language... 11 Deployment Platform... 11 Hardware Requirements... 11 Principles and Architecture Justification... 11 Logical View... 12 Interface View... 12 Design View... 13 Infrastructure View... 14 Deployment View... 14 Operational View... 14 Security View... 15 Data View... 16 Technology Selection... 17
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 Uses FSTS to create and maintain family files. Employee 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
WHM Client Uses FSTS to generate statistical reports based on Family and Event information in the system Client information is registered in the FSTS as a family file 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 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: UC1.01 Manage FSTS Client File
UC1.04 Synchronize Updated Family Information UC2.01 Manage Event
UC2.02 Manage Event Types UC2.03 Manage Category
UC3.0x Manage Appointments UC4.0x Mark Attendees UC5.0x Generate Reports
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.
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.
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
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).
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 Please find the current design view for our system enclosed below:
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,
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.
Data View Below is our current database view:
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