Artifact: Interface
| A model element which defines a set of behaviors (a set of operations) offered by a classifiermodel element (specifically, a class, subsystem or component). A classifier may realize one or more interfaces. An interface may be realized by one or more classifiers. Any classifiers which realize the same interfaces may be substituted for one another in the system. Each interface should provide an unique and well-defined set of operations. | |
| Other Relationships: | Part Of Design Model |
| Role: | Software Architect |
| Optionality/Occurrence: | Used in conjunction with Design Subsystems. Elaboration phase. |
| Templates and Reports: | |
| Examples: | |
| UML Representation: | Interface |
| More Information: | - Guideline: Interface - Guideline: Representing Interfaces to External Systems |
| Input to Activities: - Define Testability Elements - Identify Test Ideas - Subsystem Design - Use-Case Design | Output from Activities: - Identify Design Elements - Incorporate Existing Design Elements - Subsystem Design |
Purpose
An interface declares a set of operations, including their signatures and parameters, that are use to specify the services offered by a classifier model element (e.g. a class, component or subsystem).
Properties
| Property Name | Brief Description | UML Representation |
|---|---|---|
| name | the name of the interface | attribute |
| description | a short description of the interface | attribute |
| operations | the operations of the interface | operations |
Timing
Interfaces are created in the elaboration phase, and define the important ‘seams’ in the system. All interfaces are architecturally significant.
Responsibility
A Software Architect is responsible for the integrity of the Interface, ensuring that:
- it defines a unique set of operations which do not overlap with those of another interface.
- it provides a logical grouping of related operations which is easy to comprehend.
Tailoring
Interfaces are typically used in conjunction with Artifact: Design Subsystem; it is usually not necessary or desirable to use interfaces in conjunction with Artifact: Design Classes, where using public operations is usually sufficient. Interfaces are typically used in cases where there is a need to define the behavior (in the form of operation signatures) independently from the elements that realize those operations. This implies the existence of larger-grained abstractions of behavior or replaceability, modeled as design subsystems. For projects that do not have these attributes, interfaces can be omitted.