Architecture Review Presenting: Edrin Pecani (Architect) Dan Heneghan Peter Cintula

Outline Project summary Architecture Performance budgets Design considerations: –maintainability, reliability, simplicity Human interface Test plan summary and design for testability Complexity Updated function points, QFD, ICED-T, and COCOMO cost estimate Gantt chart

Project Summary The product provides a user friendly, efficient interface for students to create and modify class schedules and study plans. MOV: –Course scheduling and registration time eliminated by an average of 20 minutes per student per semester Requirements: –Visual schedule creation and editing –Schedule suggestion –Schedule comparison view –Study plan designer –Monitor closed courses

Architecture Introduction The system is an ASP.NET web application that allows students to create and edit schedules for upcoming semesters, and study plans. It offers fast data transfers without web page refreshes, an easy to use interface, and compatibility with many browsers and environments. The system is reusable, requiring only small modifications for new customers (typically, other universities). The basic architecture is “thin-server”, “fat-client” –Centralized server allows users to work from anywhere –Server is a simple data repository, without business logic. This reduces server load, by making each client browser do its own computations.

Evolution of Client Architecture –Standalone Java application –Standalone C++/GTK+ application At this point, misunderstanding with customer is realized. –Java applet –ASP.NET web application –ASP.NET web application with Javascript communication for data transfers

Logical View

Overall Process View In the following slides, we will examine each process in detail.

Process: Login

Process: Page Loading

Process: Data Transfer

Process: Data Loader

Process: Course Status Notifier

Development View

Physical View

Example Scenario

Performance Considerations: –The heaviest use of the system will be during the two weeks before registration begins. –The system will be used the least from the add/drop deadline of one semester until the time that course information for the following semester is released. –There are 3500 students at Stevens –Students take an average of 6 courses per semester –There are about 1200 different course sections during a fall or spring semester at Stevens –The size of the course data export file is about 200KB.

Performance Client The response time of the server to a client request should not exceed 10 seconds Interaction within the client that does not involve data transfers should not stall for more than 1 second Server The server should handle up to 200 simultaneous users with no performance degradation The Data Loader module should not take longer than 10 minutes to complete The Course Status Notifier module should not take longer than 10 minutes to complete

Design for Maintainability The “thin server” simplifies maintenance. Central location of all data simplifies maintenance on it, such as changing formats. High reusability: New customers need only change the Login and Data Loader modules to use the system. Modular design of ASP pages and Javascript code Integrated user documentation Detailed code documentation

Design for Reliability The stated availability allows for daily backups, service, and reboots of the system Connections to server are minimized, reducing overall activity on the server Parnas reliability checklist: –Failures in communication, secondary storage, memory, or any hardware that may interrupt a transaction: The SQL Server DBMS will not commit incomplete transactions. User will be notified of the error, and will have to redo the transaction. –Operator error: All user errors can easily be fixed by the user

Design for Simplicity The choice to do a web-based client application over a desktop application simplifies coding of presentation layer: –Easier to create user interface in HTML than by using desktop application GUI frameworks Other alternatives, such as using GTK+ or Java, would require more training of team members than for our web-based client User interface follows the existing Scheduler program used by many students, reducing the learning curve

Human Interface The user interface will –Be as similar to the existing Scheduler program as possible –Follow web interface usability standards

Usability Study Results Source: Internal Links (useful for menu features) Internal Search Engine (useful for course search) Back to Home link Help Button Login/Register

Test Plan We will begin testing when our first increment nears completion Test cases for all versions Naïve users with a range of experience with scheduling programs

Test Plan Testing Requirements IE 5.0+, Firefox 1.0+, Safari 1.2+ on user’s computer Our development and testing server –.NET – IIS – SQL Server – Windows Server 2003

Test Plan Regression Testing – All old features will still be used heavily by users Stress Testing – Many naïve users accessing at the same time – Simulate usage close to registration dates

Test Plan Compatibility testing –Test in all browsers –Use IE’s error reporting –Use Firefox’s Javascript console Cross-platform testing –Test on Windows, Mac, Unix

Design for Testability Easy, web based interface New features are added separately in different versions so all can be tested thoroughly Data loading and schedule modification can be tested separately

Sample Test Case Course Conflicts – Input User wants to add 2 courses which coincide Finds courses from list via search, adds both Program will confirm that conflicting class should be added

Sample Test Case Course Conflicts – Output User must then be able to clearly view information on both courses Must be able to tell that they are conflicting courses Must be able to remove either one of them without affecting the other

Complexity We have measured complexity by: –Calculation of coupling/cohesion for each architecture view –Amount of function point reduction –Complexity charts for server, client, and overall product

Complexity: Coupling/Cohesion As shown in each architecture view, coupling and cohesion was calculated for each view. –Logical view, Process view: Cohesion: Number of modules Coupling: Number of one-way arrows / number of modules –Development view: Cohesion: Number of packages Coupling: Number of “uses” occurrences between two packages –Physical view: Cohesion: 2 (server, client) Coupling: 2 (communication in both directions)

Complexity Chart - Server Project Type: online transaction Problem Domain: 1 Architecture Complexity: 2 Logic Design – Data: 2 Logic Design – Code: 2 Total Score: 7 Complexity = (7/18) * 5 = 1.94

Complexity Chart - Client Project Type: online transaction Problem Domain: 2 Architecture Complexity: 3 Logic Design – Data: 2 Logic Design – Code: 3 Total Score: 10 Complexity = (10/18) * 5 = 2.78

Complexity Chart - Overall Project Type: online transaction Problem Domain: 2 Architecture Complexity: 3 Logic Design – Data: 2 Logic Design – Code: 3 Total Score: 10 Complexity = (10/18) * 5 = 2.78

Function Points FunctionLowAverageHighTotal Outputs03015 Inquiries21010 Inputs43024 Internal Files22034 External Interfaces Total UFP100 AFP104

QFD Customer Goals/Program Features Class FilterAllocate non- class time Persist information between sessions Authenticate against Pipeline Make scheduling classes easier 8362 Make scheduling a semester easier 7982 Scheduling information in one place 1157 Total Scale: 1 to 10 (weak to strong)

ICED-T Version UsedIntuitiveConsistentEfficientDurableThoughtful Paper32223 Excel32333 Rob Evans Scheduler Scheduler Pro Scale: 1- Worst I’ve ever seen 2- Worse than average 3- About the same as other applications I’ve used 4- Better than average 5- The best I’ve ever seen

COCOMO Organic project: small group developing in known environment Javascript has an average of 42 lines of code per function point ~ 4300 lines code COCOMO says that’s 11.2 “staff” months of work Our usage of XMLHTTPRequest and HTML/ASP.NET will likely result in less LOC, so the above is an overestimate

Gantt Chart