COMP 310 Fall 2017	Lab09: ChatApp Design

In today's lab, we will be working in small groups to work out use cases and  design the interfaces and protocols for the ChatApp project.

The Design Process:

1. Define what the application is supposed to do, e.g. feature list.
2. Write use cases for the features -- the more detailed the better!
3. Organize the use cases into maximally decoupled groups,
   •  The groups form the main sub-systems in the application.
4.  Create the System Block Diagram from those sub-systems
   • Clearly define the roles and responsibilities of each sub-system.
   • Define the API's (Application Programming Interfaces) that the use cases are using to access the use cases in another sub-system 
5. Repeat the process to design the interiors of the sub-systems.
6. Code the sub-systems.

Note that coding is the LAST thing that is done!

Use cases can be created using (non-exhaustive list):

• Microsoft Visio
• http://creately.com/  -- On-line diagramming tool (sign up for free account).

What is an "API"?

An "Application Programming Interface" (API) is a common interface (or set of interfaces) that used for one part of a system, "a "module", to communicate with another part of the system, i.e. another module.   API's are related to the adapter interfaces in an MVC because the model and the view are modules in the system and the adapter interfaces define the communications between them.   API exist between all modules in a system, as one can see when the system of interconnected modules is viewed as a generalized MVC with multiple "models" and "views".

The modules, or "system blocks" in a system arise from the semantic grouping of use cases.   Each module is thus represented by a set of use cases to accomplish a related goal such as data storage, user interface, analytical computation, etc.    API's arise from the use cases that cross the boundaries between modules, that is, when the use case in one module is composed with ("uses") a use case in another module.  Those boundary-crossing use cases thus form a set of behaviors that one module expects from another and thus can be expressed as one or more interfaces in code.

For ChatApp, the API that we are most concerned with is the API at the boundary between computers, that is, the API defined by the use cases that cross the network boundary.

Nitty-gritty technical detail:  Technically, an API and an MVC adapter interfaces are not exactly the same thing.   The job of  API to a module is to decouple the module from the rest of the system such that the module can be replaced without affecting the rest of the system in any way.    An API is thus common interface that all other modules use to communicate with that type of module.    This enables module to be swapped in and out at run-time or multiple modules to be used simultaneously, e.g. for load balancing.    This is contrast to an MVC adapter interface which is specific to a particular user of a module.   Thus, in a multi-module system, each module will conform to its particular API in terms of its public interface but each module will use its own MVC adapter interface to talk to another module.   Those adapter interaces may be quite different than the API interface, so the MVC adapter implementations will translate the MVC adapter interface methods to API calls.

For reference:

• Lec29:  Use case and ChatApp design guides
• Design Process Overall Guidelines
• Java Resources page on Use Cases
• HW08: ChatApp required specifications

Lab Procedure

1. The class will be separated into a number of small working groups, each with a whiteboard to sketch ideas.
2. Each group should start by listing out use cases -- from the user's perspective -- of various operations that the groups feel would be pertinent to a "Chat App".
   • Try to be complete and find as many use cases that cover all possibilities of things a user might want to do.
   • Once a reasonable set of use cases is found, start to group the use cases together into groups that represent abstractions of the same notions.
     • It is very likely that the result may be nested groups of use cases representing more or less abstraction.  
     • Keep pushing to find the most abstract representations of the use cases that were found.
   • Be sure to include the requirements of HW08
   • Keep it simple!  Go for a complete description of a simple system rather than an incomplete description of a complex system.
     • Think in terms of the fundamental behaviors of the system.
   • In particular, focus on use cases that cross the network boundary because in the end, it is these use cases that will constitute the common API to which all ChatApp implementation must adhere.
3. Identify what use cases are actually part of other use cases and use those relationships to create the Use Case Diagram for the system.
4. Group the use cases in the Use Case Diagram into semantically related sets -- these become the functional "modules" of the system.
5. Find the use cases that cross the network boundary and use them to express the common network API for the system.

Questions to consider:

1. What is a "chat room"?    In particular, from the perspective of any given user, what are the roles of the members of a chat room in terms of sending or receiving of messages?  
2. Per chat room in ChatApp on a someone's computer, how many receivers of messages are there on that computer?
3. What are the fundamental groups of use cases that illustrate the most basic differences between the types of operations/processes in ChatApp?
4. Is there a fundamental difference between a text message, a picture message, a video message or any other kind of message?   Or are they abstractly equivalent?

© 2017 by Stephen Wong