1 / 12

The SIPT System – Preliminary Design and Fault Tolerance

The SIPT System – Preliminary Design and Fault Tolerance. Team # 2 Joseph Ross (PM) jodross@mtu.edu Haytham Alsaghayer halsagha@mtu.edu Joe Wynia jjwynia@mtu.edu. Outline. Introduction Step 2 1. Use-Cases 2. Class Design 3. Authorization 4. Fault Tolerance Conclusion.

plong
Download Presentation

The SIPT System – Preliminary Design and Fault Tolerance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The SIPT System – Preliminary Design and Fault Tolerance • Team # 2 • Joseph Ross (PM) jodross@mtu.edu • Haytham Alsaghayer halsagha@mtu.edu • Joe Wynia jjwynia@mtu.edu

  2. Outline • Introduction • Step 2 1. Use-Cases 2. Class Design 3. Authorization 4. Fault Tolerance • Conclusion

  3. Introduction • SIPT System • Step 2 • We have made a few changes... • Assumptions added to fill in a few gaps • New assumptions v. amendments to functionality

  4. Use-Cases

  5. Use-Cases(con.)‏ • Troubles constructing the Use-Cases... • Displaying overlap conceptually • Hard to read overlapping lines / too many lines • Benefits of constructing the Use-Cases • Missing or irrelevant cases • Visualization of authorization

  6. Use Case: Generate Unique Reports Actors: Academic, Instructor, Student Type: Primary, Essential Cross Ref: 1.k, 2.c, 3.c, original Description: Every type of user can generate reports. For purpose of clarity and to make the diagram much more readable we did not include every individual type of report that is possible to generate. We believe by saying “Unique Reports” we note that every user can generate different types of reports varying in scope based on their user-type. Use Case: View Course Material and Work Actors: Instructor, Student Type: Primary, Essential Cross Ref: Assumed Description: Both instructors and students can view all the posted (visible) course material and work within a course. These elements are not viewable by academic administrators since it has no bearing on their report generating abilities. Textual Use-Cases

  7. Class Design

  8. Class Design(con.)‏ • Troubles constructing a class diagram... • Simplicity v. Complexity • Base classes v. visual and “pseudo” classes • Benefits for constructing a class diagram • Forced to start thinking about some parts of implementation • Better grasp on the scope of the project

  9. Authorization • Most of this was determined during the changes to functionality made in Step 1 • In general, if something belongs to you, you can view or change it • There are a few exceptions

  10. Fault Tolerance • New assumptions were made due to this topic • Most of the possible errors were I/O related

  11. Conclusion • Step 2 had us review almost everything we have done so far • Removed unnecessary functionality • Made new assumptions based on consideration of fault tolerance

More Related