Diagram Work Product Set

Definition

The diagram set is the cohesive set of work products consisting of all diagrams that can be produced during an endeavor.

Work Products

The OPF repository of reusable process components contains the following set of predefined diagrams:

Requirements Diagrams

The OPF repository contains the following requirements engineering diagrams:

• Context Diagram,
  which is a top-level requirements diagram that documents the referential relationships between a blackbox business enterprise, contact center, data center, application, or component and the externals (e.g., roles, organizations, applications, systems) with which it interfaces.
• Domain Object Diagram,
  which is a bottom-level diagram that primarily documents the referential relationships between classes and types (interfaces) of business objects.
• Use Case Diagram,
  which is a mid-level requirements diagram that documents the relationships between use cases and the externals with which they interface.
• Use Case Sequence Diagram,
  which is a bottom-level sequence diagram that documents a use case or use case path in terms of the interactions between a blackbox business enterprise, contact center, data center, application, or component and the externals with which it interfaces.

The following figure illustrates the temporal relationships between the different kinds of requirements diagrams. The diagram at the end of an arrow typically precedes and drives the content of the diagram at the arrowhead.

Architecture Diagrams

The OPF repository contains the following architecture diagrams:

• Configuration Diagram,
  which is a top-level architecture diagram documents the hierarchical configuration that makes up the top-level architecture of a system.
• Content Management Architecture Diagram,
  which is a low-level architecture diagram that primarily documents the content management activity in terms of its associated databases and software components, and the dataflows between them.
• Data Architecture Diagram,
  which is a mid-level architecture diagram that primarily documents the major data components (databases, files), the major data-manipulation software components, and the dataflows between them.
• Deployment Diagram,
  which is a midlevel architecture diagram that primarily documents the deployment of the data and software components to the hardware components.
• Hardware Architecture Diagram,
  which is a mid-level architecture diagram that primarily documents the major physical (technology-dependent) hardware components within the various tiers in the tier diagram.
• Integration Architecture Diagram,
  which is a low-level architecture diagram that primarily documents the communication protocols (e.g., HTTP, TCP/IP, XML, EDI, SQL) used to communicate between the various data, hardware, and software components.
• Layer Diagram,
  which is a top-level architecture diagram that documents the logical horizontal layers (and possibly vertical partitions) that make up the overall logical architecture.
• Logical Architecture Diagram,
  which is a mid-level architecture diagram that primarily documents the major logical (technology-independent) software and data components (or functions) within the various layers and partitions in the layer diagram.
• Navigation Diagram,
  which is a low-level architecture diagram that primarily documents the presentation components (e.g., screens and webpages) and the navigation relationships between them.
• Operational Availability Architecture Diagram,
  which is a low-level architecture diagram that primarily documents the major operational availability components and mechanisms of an application and their relationships.
• Operations Architecture Diagram,
  which is a mid-level architecture diagram that primarily documents the software components (e.g., traffic monitoring, exception handling, intrusion detection, data monitoring and management, and system monitoring and management) that support the operations activity and their relationship to other components.
• Scalability Architecture Diagram,
  which is a low-level architecture diagram that primarily documents the major scalability components and mechanisms of an application and their relationships.
• Security Architecture Diagram,
  which is a low-level architecture diagram that primarily documents the major security components and mechanisms and their relationships.
• Software Architecture Diagram,
  which is a low-level architecture diagram that primarily documents the major physical (technology-dependent) software and data components (or functions) within the various layers and partitions in the logical architecture diagram.
• Tier Diagram,
  which is a top-level architecture diagram that documents the physical tiers of major components that make up the overall physical architecture.
• User Interface Architecture Diagram,
  which is a mid-level architecture diagram that primarily documents the primary flow of content between the databases and the users and the communication protocols and transformations that are used and that take place between them.

The following figure illustrates the temporal relationships between the different kinds of architecture diagrams. The diagram at the end of an arrow typically precedes and drives the content of the diagram at the arrowhead.

Design Diagrams

The OPF repository contains the following design diagrams:

• Class Diagram,
  which is a design diagram that primarily documents the relationships between classes and types (interfaces) of design objects.
• Inheritance Diagram,
  which is an object diagram that primarily documents the inheritance relationships between classes and types (interfaces) of objects.
• Aggregation Diagram,
  which is an object diagram that primarily documents the aggregation relationships between classes and types (interfaces) of objects.
• Collaboration Diagram,
  which is an object interaction diagram that primarily documents the potential interactions between classes and types (interfaces) of objects.
• Sequence Diagram,
  which is an object interaction diagram that primarily documents the actual interactions between classes and types (interfaces) of objects.
• State Transition Diagram,
  which is an diagram that documents the states of a class or type (interfaces) of objects and the state transitions between them.
• Data Design Diagram,
  which is an object or entity-relationship diagram that primarily documents the data elements (e.g., classes, tables), their component data, and the relationships between them.

The following figure illustrates the temporal relationships between the different kinds of design diagrams. The diagram at the end of a single arrow typically precedes and drives the content of the diagram at the arrowhead. The double arrow represents the inheritance relationship from a subclass of diagrams to its superclass of diagrams.

Guidelines

• Diagrams are often intermediate work products that are a part of various in models and included in various documents.
• Different endeavors require different kinds of modeling, which in turn will require different diagram work products.
• Every endeavor does not require the production of every diagram work product.
• Select only those diagram work products that are appropriate for the endeavor’s process.
• Selected diagram work products should be:
  • Relevant.
  • Useful.
  • Usable.
  • Cost-effective to both create and maintain.
• Where practical, use a industry standard, well-defined visual modeling language such as UML or OML create the diagrams.
• Use a whiteboard to create the diagrams and a visual modeling tool to digitize and maintain them.