COMP 310/510
|
Lec29: Use Cases and ChatApp API Design |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
We will be working together as a class to design the ChatApp main interfaces and protocols, so class and lab attendence is mandatory!
Each student is responsible for
The staff will make the latest version of the class-designed code available through a separate svn:externals connection.
A Chat App Discussion discussion forum and chat room have been set up in Owlspace to facilitate out-of-class design discussions. And as always, one can send a message to the class at comp310f12 at owlspace-ccm.rice.edu.
For reference today and in lab, be sure to have the ChatApp specifications handy.
A use case is an example of how a user might interact with an application. To develop an application, one of the very first things that a developer must work with the customer to collect and analyze as many use cases as possible. It is from these use cases that a picture is built up that tells the developer how exactly the user (or any external entity) will interact with the system being built and thus how the sytem needs to be built.
A Use Case Diagram (a standard type of UML diagram) is used to visually represent a use case. The main components of Use Case diagrams are the "actors", the users or other external entities, and the various components of the system being built. Arrows are used to indicate interactions between components.
In class we will develop some use cases for our chat program. These will be used to design our API below.
ChatApp Use Cases:
Use Case References:
The system block diagam shows the major, maximally decoupled, encapsulated sub-systems that make up the total system. The system block diagram shows all the multiple "models" and "views" that the controller in the MVC will have to construct and connect.
We will also spend time today developing the ChatApp Application Programming Interface ("API"). An API is the set of interfaces and usage protocals that separate the various decoupled portions of a program.
Remember that at this stage, we have two distinct interaction modalities taht require well-defined interaction protocols:
© 2013 by Stephen Wong