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