COMP 310 Spring 2017	Lec29: Use Cases and ChatApp API Design

Let's finish our discussion on generics, especially with regards to the DataPacket design we will be using.

Student-driven ChatApp 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

•  for knowing the results of the class design discussion.   
•  for pointing out errors, ommissions and problems, both realized and potential.  
•  for suggesting solutions to those problems.

 The staff will make the latest version of the class-designed code available through a separate svn:externals connection.  

Use Piazza for design discussions where individual design group threads will be created.

For reference today and in lab, be sure to have the ChatApp specifications handy.

Use Cases

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 Case Examples (neither definitieve, complete nor sufficiently detailed!):

• Initial program start
• Initial connection
  • Creating a chat room
  • Adding oneself to a chat room (local vs. remote?)
  • Adding a new user to to the chat room
  • Notfiying all chat room participants of new user.
• Sending a message
  • Transmission status notification
  • Possible status notifications
• Disconnecting from a chat room
  • What if the user is the creator of the chat room?
• Dealing with unknown data types -- required to be able to process this as the sender intends!

Use Case References:

• Java Resources page on Use Cases
• Wikipedia articles on Use Cases and Use Case Diagrams.
• http://www.objectmentor.com/resources/articles/usecases.pdf
• http://www.parlezuml.com/tutorials/usecases.htm (read to PDF docs that are linked here)

General Process for Designing the Sub-Systems (System Block Diagram) and API's in a System

1. Create a Use Case Diagram that shows all the relevant use cases.
2. Arrange the use cases into groups of related operations
3. Adjust the use cases to better fit the groupings from #2 above and/or adjust the groupings to clarify their semantics.
4. The groupings become the sub-systems and the diagram becomes the System Block Diagram
5.  The use cases that cross from one sub-system to another (note the directionality here) create the API's to the target sub-systems. 

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.

For more detailed information, see the Java Resources page on Use Case-driven System Block Diagrams.

ChatApp API Design

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.

We will be following these Design Process Overall Guidelines.

Some general questions to ponder while creating the ChatApp use cases:

1. What is a "message"?  
   1. What sorts of information can be sent as a message?
   2. Can commands be sent as messages?
   3. Is there anything that cannot be sent as a message?
2. What is a "user"?
   1. What does a user "know"?
   2. What can a user do?
3. What is a "chat room"
   1. Does it reside locally or remotely?  What are the pros and cons each way?
   2. What can a chat room do?
   3. What happens if the person who created a chat room leaves?

© 2017 by Stephen Wong