Standard: Implementation Package

Standards: <<implementation>> Package

	A package that contains the implementation of a subsystem. The implementation package realizes one or more interfaces, which define the behavior it will implement. The interface is defined in an associated <<facade>> package. Everything contained within an implementation package is private.
Related Information:	Standards: Package Overview RUP Artifact: Design Package RUP Guideline: Design Package RUP Artifact: Design Subsystem RUP Guideline: Design Subsystem

Topics

Introduction

The documentation of subsystems falls into two categories:

External – the documentation of the subsystem required to make the subsystem usable by its clients.

Internal – the documentation of the internal design of the subsystem

Implementation subsystems do not contain any of the external documentation as everything they contain is private. What an implementation package contains is the design of a subsystem's implementation.

The interface that the implementation realizes is defined and documented by the <<facade>> package (or packages) it realizes. This contains all the necessary external documentation.

Naming Standard

The general package naming standards apply to <<implementation>> packages (See Standards: Package Overview).

Diagramming Standards

Diagram

Purpose

Use

Comment

Main

A class diagram showing the structure and layering of the implementation.

Mandatory

This diagram provides an overview of the structure of the package.

Dependencies

A class diagram showing which other packages the implementation is dependent on.

Mandatory*

*Not required if the implementation is not dependent on any other packages.

Connections

A class diagram showing the dependencies between the classes in the implementation and the classes from other packages they are dependant upon.

Optional

For implementation packages the Connections diagram is just one of the possibly required Internal Design class diagrams. All of the connections may be shown on other more significant Internal Design diagrams rendering the need for a specific Connections diagram obsolete.

Can be combined with dependencies diagram for simple implementations (i.e. Diagram named Dependencies / Connections)

Interface Design

A set of interaction diagrams showing how the operations of the realized interface's have been designed.

Naming convention:

Interface name :: operation name : optional description

Optional

These diagrams provide a dynamic model of the internals of the subsystem. They show how the implementation classes collaborate to fulfill the operation specifications.

These diagrams show internal behavior (rather than the external behavior shown on the usage diagrams of the facade).

Internal Design

Diagrams describing the internal design of the subsystem.

A package may have as many internal diagrams as the designer sees fit.

General design diagrams should have meaningful names.

Additional interaction diagrams may be required to show how the implementation classes interact internally where the starting point is one of the operations of the implementation class rather than an interface of the subsystem. These should follow the naming convention:

class Name :: operation name : optional description.

If the diagram is about the whole class and not a specific operation then the operation name should be omitted.

Mandatory

There should be at least one internal design diagram showing the internal structure of the subsystem.

These diagrams describe the structure of the design and how the structural elements collaborate to fulfill the subsystems responsibilities.

Welcome

A class diagram presenting the purpose of the implementation.

Optional

An explanatory diagram welcoming users to the package.

Constraints

All of the elements (classes and packages) owned by an implementation package are by default private / implementation.

Examples

The example below shows an <<implementation>> package with its Dependencies - Connections diagram displayed.

In the browser we can see a number of Interface Design (e.g. ITransaction::commit) and Internal Design (e.g. Structure: Record Handling) diagrams.