TA Meeting________________________________________________

everyone present

Overview with schedule...
Problems with design documentation;
Therefore, won't start coding until Friday
Handing on Friday 6PM

Future schedule
Sat/Sun, write interfaces for ease in code integration
Fri/Sat, coding *SHOULD* be finished
March 14th, code design/review
April 8th, presentation to client

Trevor's advice:
tell Robert, if you are going to drop any major features
keep him informed so that he isn't surprised


System DESIGN CRITIQUE BY TREVOR ________________________________________________

Initial marking scheme 58/100
couple fuzzy parts in the documentation

specify whether you are referring to client or server system when saying "system"
some irrelevant material in Constraints section
- operability time is NOT a constraint since it does not have to operate 100% of the time

Architecture diagram requires a logical base diagram in addition to the written component
(smthg similar to deployment diagram...perhaps a component diagram??)

- give rationale for why you are using certain strategies (i.e. .NET)

- deployment diagram is confusing...separate the components "physically"
- as a developer, give them the ideal specifications as opposed to giving them options
- "performance would be ideal if on separate machines"

- interaction of PHP and the app is unclear
- give written explanation of the interactions

- unclear for the interaction with database system
- inconsistency with sequence diagram
- eventually needs to update with database
1. log write/view
2. pull user
3. register user
4. edit user info

most likely in JDBC

- after user logs off, the temporary strings gets written to database
- clearly ILLUSTRATE AND EXPLAIN THIS POINT

To clearly show this, this is where a general application diagram is useful

data dictionary looks pretty good

use subheadings (i.e. 5.5.1) for ease in defining the different subsystems

Sequence diagram requires revisions
- endchat sequence diagram required to show database interactions
- UI components are not relevant to the sequences
- Manager sequence diagram to editCSR (can optimize by just having one single call for each info (name, email))
- don't spend time on editing the sequence diagram to make it accurate
- spend time on coding as opposed to this section
- if CSRchat, is same as CustomerChat, is the same as ManagerChat, then can leave out redundant ones

- if using well-known design patterns, then make a note of it

- Application control section requires a description of how UI and comm subsystem works





SCHEDULE/ TASK ASSIGNMENT FOR NEXT WEEK:___________

Aaron, Yow-Hann, Andy responsible for defining commmunication interfaces
Charles is responsible for showcasing how RMI works by Friday

low level design section is pretty ok

defining parameters