COMP 405 Spring 2014	Use Case-driven System Block Diagrams

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.

Use cases give a high-level picture of the chain of processes that an application needs to perform in order to specific tasks.    Generally, use cases start from the user desiring to do something, but can also be thought of in terms of either internal or external services that are offered.   When viewed together, multiple use cases will become an graph of operations.

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.

Use Case References:

• Comp310 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  (including the PDF docs that are linked at the bottom of the page)

System Block Diagrams

("System block diagram" is the the more hardware-oriented term which emphasizes functionalities and intercommunications. For software engineering, some will call this sort of diagram a "software block diagram" or simply a "block diagram".)

A system block diagram is a high-level view of the encapsulated functional modules that compose a system.   A system block diagram may show multiple layers of encapsulation, though internal layers are often relegated to separate diagrams for clarity's sake.   In terms of system design, the modules in the system block diagram should exhibit maximal decoupling from each other.

System block diagrams help the developers understand the the parts fit into the larger whole.   They are also very useful in helping maintain the proper level of decoupling in the system because excessive crossing of module boundaries will result in a "spaghetti diagram".

A system block diagram minimally consists of the following information:

• The  functional modules in the system, indicated by colored, titled shapes 
  • Each module should have a description of exactly what it is and what it does, i.e. its roles and responsibilities in the system.
• Communications pathways between modules, indicating the directional flow of data and control information from one module to another.
• Delineations of various boundaries in the system, both physical,e.g. in hardware, or virtual, e.g. in software libraries or packages/namespaces.

The key to creating an effective system block diagram is the clear and complete articulation of the decoupled processes that compose the system.  -- You cannot develop your system if you do not completely understand the functional modules of which it is comprised.

System Block Diagram References:

• Block Diagram (Wikipedia article -- a bit more general than we are discussing)
• Software Block Diagram images:   Google,   Bing

From Use Cases to System Block Diagrams

One of the best ways to generate a system block diagram is to approach it from use cases.   By grouping use cases together, the functional modules of the system will emerge.  Excessive coupling can easily be identified in the resulting diagram and the use cases and associated modules can then be modified to be more streamlined.

1. Put all the use cases for the system into a single diagram.  
   • For large use case sets, some generalization may be needed to make the diagram more manageable, but in the end, every use case must be tested in terms of being represented by the resulting diagram.
2. Re-arrange the use case graph to group functionally and/or conceptually related operations.
3. Draw modular encapsulations around the related use case operations.
   • The lines between modules are the required communications pathways.
   • Write down the definition each module in terms of what it is and what it does (roles and responsibilities).
4.  Modify use cases to create maximal decoupling between the modules.  
   • Maximal decoupling means that for any given module, it
     • communicates with a minimum number of other modules
     • communicates in a minimum number of ways with any other module -- strive for abstract communications ("is" many things), not universal communications ("does" many things).
   • Note that this sometimes requires the creation of new modules,  e.g. facades, proxies, "managers", etc.

Examples:

• Use case-driven system block diagram
• System block diagram without use cases being shown. (Note lack of critical details)

© 2013 by Stephen Wong