Trent

Our process began by splitting up into two teams, two people worked on the Business Modeling, while the rest of us worked on the Requirements Analysis.

  1. Vision and Functional Requirement List - This was developed by the Requirements Analysis team to define the scope of the project.
  2. Business Modeling Documents - Extensive documentation of our Business Thoughts and how they should govern our project.  There was a lot of time put into these documents before the professor noted that we should spend little time on this documentation.  We were following the RUP which indicated that most of the inception phase is making sure that the project is a sound Business decisions to pursue before the project gets too far underway.
  3. Use cases - These are the use cases.  These are mostly a product of the Requirements team, but they were analyzed and the sequential flow diagrams (SFD) were created by the Analysis team at a later date. These flow diagrams were to model the flow among the different components of the system which would be necessary to enable the system to support the use case, and remain secure.
  4. Data Flow Diagram Trent - Data Flow Diagram Resource - These diagrams represent a flow of data among components of the system inside Trent.  Although Trent may seem fairly straightforward on the surface, hours of deliberation went into most of the components of these diagrams.  The Trent diagram fails to model the administrative functions necessary to support all of the use cases.  These components would be trivial additions and were left out for simplicity's sake.  The resource diagram was not analyzed much, because this would be very dependent on which type of protocol Trent was interfacing with.  In general, the right part of the diagram would always be the same, but the left part, where Trent interfaces with the existing program would be the difficult aspect to model.  These diagrams are our interpretation of the intentions of the beginning of the Analysis workflow.  We did the Architectural Analysis and Use-Case Analysis to figure out how things would fit together.  This culminated in these DFD's which would qualify as the Architectural Design.
  5. Analysis of Data Flow Diagram Trent  - This document created by the Analysis and Design team explains how the Dataflow diagram models the architecture.  This also describes the concurrency of the different modules. 
  6. Communication between Control Session Module and Translate User-Trent Module CSM->TUTM TUTM->CSM - These diagrams by the Analysis team and describe a communication method between the Control Session Module and the Translate User-Trent Module.  This was the last aspect in the design of the Architecture so that we could move on to some Subsystem Design.  We felt, and the RUP states that the method by which the modules communicate needs be established so that separate groups can design the internals of the subsystems when they already know how they interact. 
  7. Subsystem Analysis - These Documents are a flow diagaram for the subsystems of the Authentication Module, List Permissions Module, and the Verify Permissions Module.  We had to add the list permissions module so that the Control Session module could return a list of available permissions to the Translate module so that the user could choose.
  8. Class Diagrams - These are proposed class diagrams by the Analysis team for the Database Records, Message Data, and the Trent System.

We had hoped to get farther in the development of these documents.  Mainly we would have liked to make these documents complete for the entire system.  Unfortunately, the project proved to be too large to model the entire thing in detail so we resorted to specifying only the details of the server side. 

Trent Team 12/05/2000