Architecture Review

Presenting:Edrin Pecani (Architect)

Dan HeneghanPeter 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

HTML Communication Data-heavy Communication Path (Javascript)

Customer-Specific Implementation

External Systems (Customer-Provided)

Preferences

Schedule Load, Save, Import, Export

Schedule Editor

Course Search and Filter

Conflict Detector

Custom Time Blocks

Schedule Suggestion

Account Management

Schedule Management

Course Data

ASP.NET (Pre-existing framework)

Main Datastore

Login Validation, Session Creation Data Loader Service

Login and Authorization (Stevens-hosted)

Periodic export of schedule data

Ser

ver

Clie

nt

Course Status Notifier Service

Study Plan Editor

Study Plan Management

Study Plan Load, Save, Import, Export

Schedule Comparison View

Reu

sab

le

COH: 20CPL: 28/20 = 1.4

Overall Process View

Login Process

Page Loading Process

Data Transfer Process

Data Loader Process

Course Status Notifier Process

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

COH: 5CPL: 2/5 = 0.4

Process: Login

Stevens log-in web site

(external)

Login Validation,

Session Creation

(1) Token identifying logged-in user is passed to Scheduler Pro

(2) Continue with page requests from logged-in user

Process: Page Loading

Client Web Browser

Server

(1) Send HTTP request for page

(3) Return page through HTTP

(2) Perform ASP.NET server-side processing, if necessary

Process: Data Transfer

Client Web Browser

Server

(1) Open an XMLHttpRequest connection, send request

(4) Return data packaged as Javascript code Main Datastore

(2) Access requested data

(3) Return result

Process: Data Loader

Data Loader Service

File Lock

(1) Wait for file lock to be removed

Periodic export of schedule

data

(2) Read file

Main Datastore (3) Update local data

Stevens Data Updater Service

(external)

(A) Wait for file lock to be removed

(B) Lock file, update file, release lock

Process: Course Status Notifier

Course Status Notifier Service

(1) Check status of all courses being monitoredMain Datastore

(2) Send email notification to any user for whom courses have opened

Development View

Server Processing Classes (C#)

Domain-Specific Classes (C#)

ASP.NET Framework

Course, ScheduleBlock, Section, Meeting, Term, ScheduleSetting, Student, ScheduleCustomBlock, Audit, StudyPlan, etc.

Data Loader Service (C#)

Client ASP Pages (C#)

- Account Management- Schedule Management- Study Plan Management- Course Data- Login Validation

- Schedule Editor- Study Plan Editor- Schedule Comparison View- Preferences- Help Pages

Course Status Notifier Service (C#)

Javascript Files

Import

Hardware, Operating System

- Schedule L.S.I.E.- Study Plan L.S.I.E.- Course Search and Filter- Conflict Detector- Custom Time Blocks- Schedule Suggestion

COH: 7CPL: 4/7 = 0.6

Physical View

Server

Contains:- The deployed ASP.NET project- SQL Server database- Data Loader and Couse Status Notifier running as Windows Services

Software required:- .NET Framework v1.1- IIS version 5.1- SQL Server 2000- Windows 2000, XP Pro, or Server 2003

Recommended Specifications:- Pentium4 2GHz or equivalent- 1GB memory- 50GB storage

Availability:- 7am to 4:45am daily, service and backups during offtime

Scalability:- To scale up:

- Upgrade to better hardware- Use multiple web servers- Place DB on separate server

Client

Software required:- Any of these browsers:

- MS Internet Explorer 5.0+- Mozilla Firefox 1.0+- Apple Safari 1.2+

- Any OS that runs one of these browsers

Recommended Specifications:- Pentium2 200MHz or equivalent- 128MB memory- 20MB storage- Minimum resolution of 800x600 with 8-bit color

InternetCustomer’s Internal Network

Contains:The user login system and course data

Optionally, the server and client machines can also be located inside this network

COH: 2CPL: 2/2 = 1

Example Scenario

Server

Schedule Management

Course Data

ASP.NET

Client Browser

Login and Authorization

(Stevens-hosted)

Login Validation, Session Creation

1

2

3

4 5

Schedule Editor6

Course Search and Filter7

8

Main Datastore

9 10

11

13 14

Schedule Load, Save, Import, Export

16

17

1) Client browser accesses Stevens Login page2) Client is authenticated, and a token indicating client’s identity is passed3) Session is created in ASP.NET4) Client requests the Schedule Editor page5) Server returns the Schedule Editor page6) User selects “Create new schedule for Fall 05” option7) The courses for Fall 05 are requested8) Request is routed through JS Comm. Path to server’s Course Data module9) The Course Data module, through ASP.NET, requests the Fall 05 data from main datastore

10) The Fall 05 data is returned to the Course Data module11) The Fall 05 data is returned through the JS Comm. Path to client12) User filters data by “CS Dept courses, not with Prof. Bloom”13) User drags over desired courses to schedule14) User selects “Save schedule” option15) The schedule is sent to the Sched. Load/Save/Imp/Exp module for saving16) The schedule is sent to Sched. Mgmt. module through JS Comm. Path17) The schedule is saved to the main datastore

12

15

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: http://psychology.wichita.edu/optimalweb/position.htm

Internal Links Internal Links (useful for menu features)(useful for menu features)

Internal Search Engine Internal Search Engine (useful for course search)(useful for course search)

Back to Home link Back to Home link

Help ButtonHelp Button Login/RegisterLogin/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

Function Low Average High Total

Outputs 0 3 0 15

Inquiries 2 1 0 10

Inputs 4 3 0 24

Internal Files 2 2 0 34

External Interfaces

0 2 0 17

Total UFP 100

AFP 104

QFD

Customer Goals/Program

Features

Class Filter Allocate non-class time

Persist information

between sessions

Authenticate against Pipeline

Make scheduling

classes easier

8 3 6 2

Make scheduling a

semester easier

7 9 8 2

Scheduling information in

one place

1 1 5 7

Total 16 13 19 11

Scale: 1 to 10 (weak to strong)

ICED-T

Version Used Intuitive Consistent Efficient Durable Thoughtful

Paper 3 2 2 2 3

Excel 3 2 3 3 3

Rob Evans Scheduler

3 4 4 3 4

Scheduler Pro

4 4 5 4 5

Scale:1- Worst I’ve ever seen2- Worse than average3- About the same as other applications I’ve used4- Better than average5- 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