The Identification topic covers how the pattern
is known. There is always a distinctive name.
In the original pattern language, the other consistent feature
is the Archetype.
Ordinarily,
there is no "Identification" heading. The Identification
topic is simply expected to be addressed by the first material of the
pattern description.
1.1.1 In naming patterns, strive to provide a crisp
but distinct name that serves as the title for the pattern
description and is appropriate to the
intention (section 3) and the approach
(section 5; Meszaros & Doble 1997).
1.1.2 The name of the pattern is the minimum
identification. It may be all that appears in a summary
form of the pattern description.
1.2.1 When patterns are under development and subject to
future changes, identification of a version and the date of the
version is valuable. The relationship to earlier and later
versions, if any, can be stated. For electronic documents,
linking can be provided to other versions of the pattern
description.
1.2.2 This is an important element in supporting
accurate connection from related works and in recognizing the
configuration of dependencies that may exist among versions of
separate works.
It may be useful to supplement the name of the
pattern with a one-sentence or less descriptive summary (Trowbridge
et.al. 2003).
1.4.1 There may be other names by which the same
pattern is identified (Gamma et.al.
1995; Meszaros & Doble 1997).
It is not unusual for there to be aliases among patterns that
are found to be the same among different sources and in pattern
languages applied to different overall purposes. For
example, there are patterns arising in security and usability
that are easily applied to trustworthiness by generalizing the
applicable situations.
1.4.2 Where possible, identify sources of the other
usages with additional details under the Usage
(section 9) and Sources (section 10)
topics.
1.5.1 Patterns may be organized by types or categories
under a system of classification. It can be useful to
provide a simple indicator that differentiates between
principles, policies, and patterns in the manner of (Garfinkel
2005). Some distinguish among patterns based on
discipline or level of abstraction, as with the separation of
architecture, design, and implementation patterns (Trowbridge
et.al. 2003; PatternShare
2005).
1.5.2 Any classification system should be
straightforward and easy to distinguish. Types and
keywords are generally not the same. Keywords, with their
informal flexibility, may be preferable to a classification
system of more than three-or-four easily recognized types.
1.5.3 Where possible, defer any complex
classifications to the description of the
situation (section 2), including
perspectives (section 2.1) and context
(section 2.2). Any use of types must also be simple enough
for appearance on pattlet summaries that do not provide extensive
content below the ten main topics.
1.6.1 The employment of an archetypical illustration or
diagram can inspire a mental image of the situation and a
realization of the approach . The image can be
metaphorical and evocative. The use of a simple
title-style of pattern name along with an evocative image is
characteristic of the original application of pattern languages
(Alexander
et.al. 1977).
1.6.2 The choice of archetypical
images is a valuable way to suggest aliveness in the occurrence
of patterns in the practical world. The use of electronic
documents and web sites for pattern collections provides great
opportunity for creative expansion beyond the still images to
use of audio, video, animation, and even interactive
presentations. For TROST, the archetype must also render
usefully in print and in static electronic documents (perhaps
with links to more adventurous material).
1.7.1 Short lists of keywords may be more flexible
than reliance on a classification system and fine-grained
separation of patterns by type. The
selection of keywords should be brief and understandable to
those who may have a casual interest in the pattern.
1.7.2 In electronic documents, the keywords can also
be listed in web-page headers as hints to search engines.
The keyword list may itself consist of tag elements that are
recognized in tag-based indexes (Technorati
2005).
Commonly labeled "Context," the TROST-pattern
Situation topic describes the setting in which the pattern may
occur.
There is always the equivalent of context, whether or not
separated out in a subtopic for organization purposes. If
there is only the equivalent of context, or there is not enough
material for clearly separated Perspective, Applicability, and
Indications subtopics, the headings and/or the alternative subsections are
omitted. The Situation topic assists the reader in
understanding where the pattern comes into play.
Brevity helps the reader to quickly determine whether the pattern
applies to a situation of interest or not.
2.1.1 In many cases it is desirable to establish the
perspective in which the pattern arises. This is
generally from the perspective of an observer and practitioners
that may have some technical responsibility with regard to the
situation. Perspectives that may be important to identify
include
2.1.2 Whether perspectives are drawn from a specific
classification and singled out under the situation topic, the perspective
from which the pattern is viewed and applied must be accomplished early in the coverage of the situation.
2.2.1
If there are overall patterns to which the current one is a constituent,
those should be identified as part of the embracing context (Alexander
et.al. 1977). This
pattern may emerge in the
consequences (section 8) of patterns that live in the context of the
current pattern.
2.2.2
Other aspects of the environment and situation are provided
under this topic. It is important to
avoid bringing in the intention (section 3), a
context-independent statement. Avoid anticipating the concerns that
figure in the choice of approach. There may be important
constraints that characterize the situation, however (Meszaros & Doble 1997).
There may be specific conditions that establish
whether the pattern is or is not relevant (Garfinkel
2005). These my be covered under a separate subtopic to
emphasize their importance in the characterization of the
situation.
Likewise there may be specific indicators or
cues by which the pattern may be considered to be applicable (Meszaros & Doble 1997).
They can be singled out as confirmatory clues to the patterns
applicability.
3.0.1 Commonly labeled
"Problem," the Intention topic is for specifying the
condition to be achieved.
Here is what the pattern is intended to accomplish (Garfinkel
2005).
3.0.2 "Intention" is the TROST preference for emphasizing
that there is not a problem but an opportunity to manifest (or
recognize) and emphasize the pattern in the appropriate situation
(section 2).
3.0.3 The intention is a declaration rather than a
reaction. Intentions are stated free of the
situation-identified context. There may be many different
patterns that fulfill on the same intention in different ways:
in different situations and/or with different approaches.
There is at least a simple statement of intent:
what the pattern is designed to accomplish and, perhaps, why.
This is meant to be a brief statement and it may be all that
appears under the Intention topic (without any separate
heading).
In some cases there may be additional background
as motivation behind the intention. It may be more
appropriate to include that information under the
Situation topic (section 2).
4.1
Although the term "forces" is
frequently applied to the identification of
potentially-conflicting concerns, we here avoid the suggestion of
adversaries or contending forces in opposition. It is more important, for
TROST, to identify the concerns that (may) apply in the
situation and for which balanced accommodations must be reached.
4.2
A concern is not like a requirement or constraint which may also
be associated with the situation. A concern is an issue
that must be explicitly acknowledged and accounted for.
The concern must be addressed, but it will not necessarily be
resolved.
4.3
The principle concerns are enumerated. They are best given
via simple statements, one per concern.
4.4
An interesting case for concerns (and perspective) is with the
identification of drivers from different areas/rôles/stakeholders
that are involved in the situation (Adams
et.al. 2001). When there are concerns that
naturally arise under the responsibilities of different parties,
it may be valuable to identify those sources. The selection
will be governed by the situation and the importance seen in
singling out groups of stakeholders. Be careful to avoid
emphasis on conflict and erstwhile agendas. The emphasis
should be on identifying a foundation for reconciliation of
concerns.
5.0.1 In the problem-versus-solution view of patterns,
the Approach topic is typically
identified "Solution." "Approach" is favored here.
It serves as a reminder that focus is on realizing an intention
and that the approach is abstracted at the level of pattern. The
approach is also generic with respect to the level of the
recognized situation (section 2).
It is written in the form of instructions for achieving the
intention.
5.0.2 This is potentially the most elaborate section.
It is important to have a clear statement and a progression of
detail that is straightforward to review and to apply.
Identify any prerequisite knowledge required to comprehend and
apply the approach, possibly with recognition or expansion on
the observation in the Perspectives
topic (section 2.1).
Some pattern authors
and users favor a statement that, given the situation,
intention, and concerns, begins "therefore ... ."
Whatever the style, this is a simple declarative statement taken
as what is to be done. It should be a single sentence.
5.2.1 The rationale is a brief statement of the basis
for this approach (Meszaros & Doble 1997).
In many cases the rationale is captured in the
intention (section 3). If there
is some specific approach-level rationale that is worthy of
notice, provide it here.
5.2.2 This is a good place to summarize the basis for
the particular reconciliation of concerns
(section 4) embodied in the approach, with details covered under
consequences (section 8.3).
Technical approaches may have prerequisites for
their application. This can involve preparation and
resources and be related to the
situation perspective (section 2.1). There may
also be special requirements and preconditions if there is a
concrete realization (section 6),
especially in computer software or other specialized engineering
and manufacture.
5.4.1 Sketches are not necessarily diagrams. Here
is meant a walkthrough of typical approaches and schematic
presentations at a higher level than the details. This can
provide a prologue to the detail section. An annotated
table of contents for the details can be useful in this regard.
5.5.1 If the approach is detailed, there must be an
organized presentation. An identified subsection or
subsections for the details may assist in arranging the
progressive disclosure of details that is easier to appraise and
absorb.
5.5.2 Details can also address variations,
implementation considerations, and simple (incomplete) examples
of approaches. In order to maintain compactness of the
approach statement, the Realization topic
(section 6) will often be preferable for non-prescriptive and
illustrative detail.
5.5.3 It is important that the detail provide a
prescription for achieving the pattern and satisfying the
intention. There should be a what-to-do focus.
5.6.1 Modeling languages and notations are useful if
available and suitable to the situation. It is common to
use UML, the Unified Modeling Language (Booch,
Rumbaugh & Jacobson 1999) for software-engineering
approaches.
5.6.2 Avoid foretelling of specific realizations in
software implementations. Models that serve to document
software designs may be more appropriate under
realization (section 6).
5.6.3 Stereotypical models are appropriate here.
For TROST, navigational data models (Hamilton
2005b) and performance architecture models (Hamilton
2005a) are also used. Sometimes, a simple diagram
is enough.
5.6.4 Models that are carried in diagrams may be
particularly effective in electronic documents and on web sites
where navigation of model structure, drill-down to supporting
details, and other hyper-document techniques. For TROST,
there must always be an useful static rendition in printed
copies as well.
5.7.1 Hand-sketched diagrams figure prominently in the
approaches formulated in A Pattern Language (Alexander
et.al. 1977). They serve as capsule summaries
of an approach for achieving the intention. There can be
suggestion of relationship to the archetype
(section 1.6).
5.7.2
In software engineering, it is common to use a conceptual
diagram of some form. There can be more aliveness in using
a hand-sketched diagram and that should be considered. In
some cases, this serves as a model of the most informal kind,
with the advantage of distance from any pretensions at a
realizing implementation.
6.0.1 Realizations are
specific implementations, shown in design form or as a
template, especially for realizations in software. In
non-software cases, realizations can take quite different form.
Because there's an extensive variety of realizations in
different situations, there is no general approach here.
[As there is more experience in application of patterns for
TROSTing, commonly-encountered subtopics will be summarized
here.]
6.0.2 It can be useful to separate realizations from the
more-abstract pattern that specifies the overall approach (Trowbridge et.al.
2003). In this case, the preceding sections are sufficient
to provide context and background, as well as connection to the
patterns being realized.
6.0.3
For more-abstracted patterns, this topic is available for
carrying considerations and guidelines that apply to
realizations, the variations to consider, and sources of worked
cases.
6.0.4 It is common to employ structural diagrams and
object models for computer-based approaches (Gamma et.al.
1995; Meszaros & Doble 1997).
Although the objects and their interactions may involve
subordinate patterns (section
9), these constituent objects of a realization are not
necessarily those patterns, and vice versa.
7.0.1 There are important non-functional considerations
that apply to approaches (section 5) and
their realizations (section 6),
especially in software-engineering and information-technology
situations (Trowbridge et.al.
2003).
7.0.2 The following sub-topics are representative of the
areas that may require explicit commentary, especially if there
is an important requirement or limitation with respect to the
chosen approach. Higher-level patterns will have different
considerations including ones for environmental impact,
infrastructure demands, physical hazards, financing, permits,
certifications, etc.
7.0.3 For TROST, it is important to provide an explicit
account of considerations that are required and how they are
carried out. This is part of the achievement of
transparency and accountability.
7.0.4 Many considerations are related to
requirements that may be expressed or implied for an artifact or
system. The selection of patterns may assist in the
identification of requirements. It is not meant to be a
substitute for a requirements process which is properly part of
the context of the pattern.
7.1.1 Testing can be applied under a variety of
conditions, including the inspection, review, and authorization
of architectural and engineering designs. For
software-engineering and information technology, this topic
applies primarily to the functional verification and validation
of software artifacts and other information-system components.
7.1.2 There may be identification of particular tests,
especially ones used to assess conformance to specified
standards. This may involve replicating and confirming the test
procedures that are identified and developed as part of a
realization (section 6).
7.1.3 Testing considerations arise under other subtopics. They should be addressed
under those individual subtopics. Do not repeat those
testing accounts here. A see-also index to the
other cases may be appropriate, however.
7.2.1 Consider the failure modes and the ways that a
realization can be arranged to fail safely, or not. Are
there inspections for continuing safety status? What is
the mitigation procedure on detection of an unsafe condition?
What are the barriers with respect to this approach.
7.2.2 Dependability and reliability (apart from
performance and scale considerations) figure under here. "Safety/Failure" is used to emphasize the importance of
maintaining confidence, surety, and appropriate remedies in the
face of predictable and not-so-predictable failures and
unreliable conditions.
7.3.1 Deployment considerations apply to the
arrangements for placing a realization in place, including
transport/delivery, installation and setup, and lifecycle
arrangements out to end-of-life of the realization
(section 6).
7.3.2 Integration into an overall system and the staging
with respect to system lifecycles can be considered here or as a
separate subtopic, depending on the nature of the integration
activity.
7.3.3 Deployment includes determining whether
installation can be safely done and then confirming that installation
is successful and operational. Deployment considerations
include withdrawal of an installation, successful or not, and
reversion to a previous state of affairs.
7.4.1 Security considerations overlap with those for
functionality (testing),
safety/failure,
usability, and
support/repair.
7.4.2 Security is different than those related areas
insofar as it must deal with efforts of a determined adversary
to uncover a chain of vulnerabilities that permit an exploit against the system. It is not about accidents
and resilience in the face of failures, although those can
figure in security considerations too.
7.4.3 It is presumed that exploits will always be
possible, especially to the degree that social engineering is a
factor. Security must apply to the detection and response
in the event of a successful exploit. Threat models and
tie-ins to risk management for the system are factors here.
Disaster response and business interruption may require
consideration as part of the security subtopic.
7.4.4 Provisions for authentication, authorization, and
accounting have security aspects. It is important that
there be a way to audit all actions conducted with the system,
whether or not those actions are subsequently reversed.
7.4.5 For information technology, system-management
arrangements, properly part of operations, also raise security
considerations.
7.5.1 Operations apply to the ongoing sustaining of a
system or environment.
7.5.2 For information technology, there are operational
considerations involving infrastructure support, facilities,
interruptions, maintenance arrangements, personnel and training, etc.
7.6.1 Usability relates to the accommodation of users
who engage with the system in any way.
7.6.2 Usability considerations can be related to
safety/failure, efficiency in
conduction tasks, and the affordance that is achieved by users
and the public in their attitude toward the
approach (section 5) and its
realizations (section 6).
7.6.3 Adaptation to the changing needs and capabilities
of users and the encouragement of confident use are additional
factors for usability.
7.6.4 Training, documentation, and other aids and their
ease of development are usability considerations, as is turnover
in the user population.
7.7.1 Support/Repair involves service to the elements of
a realization over the lifecycle of their use. There may
be service and repair actions that users are expected or
permitted to conduct. There may be a service arrangement
by which support is requested and resolution (advice and
repairs) provided. Barriers to the serviceability of the
realization, especially a product, must be understood.
7.7.2 This topic includes provisions for
trouble-shooting and diagnosis, isolation and workaround of
failed components, introduction and removal of changes, tracking
of problems, and maintenance of change histories.
7.7.3 There is a relationship to configuration
management and control of dependencies at the individual
deployment level. How is this done and how reliably
is it maintained?
7.7.4 For information systems, is it safe to carry out
practice, support training, and test cases on the system as
deployed, with removal of all effects (but for logging and audit
records)? How reproducible are actions with the system?
7.8.1 There may be a region of performance (capacity,
responsiveness, demand for resources) that is supported by the
approach and its
realization (sections 5 and 6).
7.8.2
Are there configuration and migration arrangements available in
the case that demand on the system consistently exceeds or falls
short of the targeted performance envelope?
7.8.3
Are there provisions for the risk of errors in the estimation of
performance and demand for resources? If the realization
cannot be scaled upward or downward based on experience and on
changing conditions, what risk management and mitigation
provisions are considered?
7.9.1 Many of these considerations involve contribution
to the confidence placed in a system and the willingness of
people to rely on it. Positive approaches are evidence for
trustworthiness.
7.9.2 There are other aspects of trustworthiness that
might be singled out, especially for an organization that
delivers products to the public. These aspects have to do
with the relationship that the producer is out to foster.
What care is shown for the experience of adopters and users of
the product or service? What is (or will be) the response
when there are breakdowns in that experience?
7.9.3 Although trustworthiness is predicated on the
conduct of the trustworthy party, there are ways that party's
care is expressed in the realization, deployment and other
factors around delivery and support of products. As TROST
and related projects gain more experience, specific
trustworthiness considerations will be catalogued.
7.9.4 One trustworthiness consideration for
software-engineering is the degree to which a delivered
component depends on other components for reliable operation.
Accounting for minimization of such dependencies and mitigation
of potential unreliable arrangements can be a consideration.
7.9.5 At a minimum, it is valuable that trustworthiness
be considered explicitly.
Application of a pattern to a situation will
produce results (Garfinkel 2005).
This can be taken as a new context
in which additional patterns now apply (Meszaros & Doble 1997).
An useful approach to framing the consequences is in terms of
the benefits and the limitations that achievement of the pattern
brings as its consequences (Adams
et.al. 2001; Trowbridge et.al.
2003).
Enumerate the key benefits that are attributed
to achievement of the pattern with the given approach and
realization, if any.
Enumerate the key limitations that accompany
achievement of the pattern with the given approach and
realization, if any.
Identify the trade-offs that occur with this
approach and realization, if any. In general, a
chosen approach will involve a particular trade-off among the
identified concerns (section 4).
8.4.1 If there are risks associated with undertaking an
approach, more than as recognized limitations of its
achievement, they can be featured here. This can be a good
place to consolidate the key risks identified in conjunction
with various considerations
(section 7) that arise with the approach
and any realization (sections 5 and
6).
8.4.2 If there is a risk analysis methodology being
applied, the information here can be tied into a consolidated
risk identification and mitigation process.
8.5.1 It is a commonplace to assert that every solution
to a problem brings with it new problems -- additional
situations for which an approach is called for (Meszaros & Doble 1997).
These may be at a lower level and are expected to be of lesser
severity.
8.5.2 With the identification of a given pattern and
application of an approach for its achievement and realization,
open challenges will appear. This is a natural part of the
separation of concerns that pattern languages and related
methodologies support. The new challenges become part of
the new context in which further refinement and pattern
resolution can now occur.
8.5.3 The next challenges are generally tied to
suggestions of further patterns that may be applied.
With the situation identifying where, approach
identifying how and realization identifying what, it is
important to identify actual occurrences in practice.
There are some companion aspects of
usage as well, that may be important when investigating
which patterns fit a given situation the best.
Specify actual cases. It is valuable to
have contrasting cases from different domains and even levels of
scale (Gamma et.al.
1995). This can broaden the appreciation of the
pattern distinct from the finer details of situations.
Variations on this pattern, detailed approach,
or realization are important to know about. What are their
names? Where are they described?
Finally, there are other patterns related to
this one. In particular, there are patterns that usefully
accompany or complete the present pattern in some way.
These are important to identify, along with their relationship
to the present pattern.
It is important to acknowledge the sources for
the current pattern, especially when the current pattern
replicate patterns published elsewhere. In many cases, a
summary page or pattlet may serve simply to import the details
of an existing pattern into a new pattern language.
Provide references to all sources relied upon in
the formulation of the current pattern. Have references be
complete and sufficient so that a reader can locate the
material, even when a printed copy of the pattern description is
being consulted.
Many patterns arise out of collaborative efforts
and special events created solely for working on the review and
articulation of patterns. All contributors who participate
in ways not accounted for in referenced works can be identified
here. Other acknowledgments may be appropriate here.
10.3.1
Provide a specimen statement of attribution that can be used by
others in making citations to the current pattern description.
This is particularly useful if the use of the pattern by others
is contingent on making attribution to the current work.
It is also valuable to indicate citation of the specific
version (section 1) when that applies.
10.3.2 If
there are particular notices of intellectual property (such as
copyright) and any grants of license, here is an appropriate
place for it. It can also be part of the page format.
|
You are navigating