COMP 310
Spring 2018
|
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:
- Define what the application is supposed to do, e.g. feature list.
- Write use cases for the features -- the more detailed the better!
- Organize the use cases into maximally decoupled groups,
- The groups form the main sub-systems in the application.
- 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
- Repeat the process to design the interiors of the sub-systems.
- Code the sub-systems.
Note that coding is the LAST thing that is done!
Use cases can be created using (non-exhaustive list):
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:
Lab Procedure
- The class will be separated into a number of small working groups, each
with a whiteboard to sketch ideas.
- 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.
- Identify what use cases are actually part of other use cases and use
those relationships to create the Use Case Diagram for the system.
- Group the use cases in the Use Case Diagram into semantically related
sets -- these become the functional "modules" of the system.
- Find the use cases that cross the network boundary and use them to
express the common network API for the system.
Questions to consider:
- 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?
- Per chat room in ChatApp on a someone's computer, how many
receivers of messages are there on that computer?
- What are the fundamental groups of use cases that illustrate the most
basic differences between the types of operations/processes in ChatApp?
- 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?
© 2018 by Stephen Wong