Glossary

(2) Abstract (verb) means the act of creating an abstraction; also called "generalize", "specify", and sometimes, "analyze".

A related set of changes of states in a group of objects, between two specific points in time. An action-occurrence may abstract a whole series of interactions and smaller changes.

Actions can also be localized-- in which case they are also called operations. An operation is a one-sided specification of an action, focused entirely on a single object and how it responds to a request, without regard to the initiator of that request.

The set of action-occurrences that conform to a given action-spec. A particular action occurrence may belong to many action-types.

An architectural style (or `type') is defined by a package (with nested packages) that has a consistent set of architectural elements, patterns, rules for using these, and stereotype or other notational shorthands for expressing their usage.

A model describing an architecture.

The architecture of a system consists of the structure(s) of its parts (including design-time, test-time, and run-time hardware and software parts), the nature and relevant externally visible properties of those parts (modules with interfaces, hardware units, objects), and the relationships and constraints between them (there are a great many possibly interesting such relationships).

The set of design decisions about any system (or smaller component) that keeps its implementers and maintainers from exercising needless creativity.

How each category of connector works internally, including the protocol of interactions between ports.

A pair of attributes that are inverses of each other, usually drawn as a line connecting two types.

A named property of an object, whose value describes some information about that object. An attribute's value is itself the identity of an object. In software, an attribute may represent stored or computable information. An attribute is part of a model used to help describe its object's behavior, and need not be implemented directly by a designer.

(a) A language-specific construct defining the implementation template for a set of objects, the types it implements, and the other classes or types it uses in its implementation (including by class inheritance). (b) An implementation concept which defines the stored data and associated procedures for manipulating instances of that class; the implementation construct can be mapped to OO languages, and to procedural and even assembly language.

A set of related actions between typed objects playing defined roles in that collaboration; these actions are defined in terms of a common type model of the objects involved. A collaboration is frequently a refinement of a single abstract action, or a design to maintain an invariant between some objects.

A collaboration is specified by the list of actions between the collaborators, an optional list of actions considered "outside" the collaboration, action specs, static and effect invariants that may apply to either set of actions, and an optional sequence constraint on the set of actions.

A coherent package of software artifacts that can be independently developed and delivered as a unit, and that can be composed, unchanged, with other components to build something larger.

A coherent package of software implementation that (a) can be independently developed and delivered (b) has explicit and well-specified interfaces for the services it provides; (c) has explicit and well-specified interfaces for services it expects from others; and (d) can be composed with other components, perhaps customizing some their properties, without modifying the components themselves. As a consequence of these properties, a component can be independently developed, delivered, and deployed as a unit.

What categories of connector are permitted between components, and what each of them does, and the rules and constraints on their usage. Some (unary) connector types can even be used to define standard infrastructure services that will be always provided by the environment.

The object, or set of objects, or pre-determined configuration for such a set of objects, that are the run-time manifestation of a component when composed within a particular application.

A specification of the external behavior of a component, covering the services provided, required, and underlying component technology.

The mind-set, science, and art of building with, and for, components and ensuring that the result of plugging components together has the expected effect.

An approach to software development in which all artifacts -- from executable code to interface specifications, architectures, and business models; and scaling from complete applications and systems down to individual components -- can be built by assembling, adapting, and "wiring" together existing components into a variety of different configurations.

Units of software that can be `plugged into' a wide variety of others. They range in scale from small user-interface widgets to large transaction-processing applications.

One behavioral description conforms to another if (and only if) any object(s) that behave as described by one are also behaving as described by the other (given some mapping between the two descriptions). A conformance is a relationship between the two descriptions, accompanied by a justification that includes the mapping between them and rationale for choices made. Refinement and conformance form the basis of traceability, and document the answer to the "why" question: why is this design done thus?

The connections between ports that build a collection of components into a software product (or larger component). It imposes role-specific constraints on the ports that it connects, and may be refined to particular interaction protocols that implement that joint action.

A redundant attribute (possibly parameterized), introduced to simplify the specification of actions or invariants. E.g. " age " defined as well as " birthday ".

A package which contains a useful and agreed set of mutually consistent stereotypes, together defining a particular "dialect" of the modeling language. All modeling work is done in the context of selected dialect(s).

The collected set of definitions of modeling constructs; importantly, the definitions must include not just the formal modeling and specification bits (relating the formal names and symbols to each other), but also the (usually informal) descriptions that relate the symbols and names to things in the problem domain. Dictionary definitions are scoped according to package scope rules.

A convenience postcondition introduced (and named) to factor parts of postconditions that are common across more than one action. Unlike ordinary predicates, it may contain the special postcondition operator @pre .

A generic relation on a type, where that relation must satisfy certain mathematical properties; defined as a standard framework.

A framework can abstract the description of a generic type, a family of mutually dependent types, a collaboration, a refinement pattern, the very modeling constructs themselves, and even a bundle of fundamental generic properties (associative, commutative, etc.). Frameworks are themselves built on other frameworks; at the most basic level, the structure of frameworks represents the basis for the organization of all models.

(noun) An import of a framework with substitutions; usually depicted graphically using a UML "pattern" symbol, with labeled lines for the type substitutions, and text annotations for finer-grained substitutions (attributes, actions, etc.)

Program code that conforms to some abstraction; requires no further refinement (strictly speaking, it still goes through compilation, etc.).

An "extension" import is a relation between packages, whereby all names and definitions exported by the imported package are accessible in the importer, together with any new elements and added statements about the imported elements that the importer may introduce. A package exports all introduced elements as well as all elements accessible via extension imports. Import by extension is the default rule for import.

A "usage" import is a relation between packages, whereby all names and definitions exported by the imported package are accessible in the importer, together with any new elements and added statements about the imported elements that the importer may introduce. However, elements accessible only via usage imports are not exported by a package.

A transition rule that applies to the postcondition of every action in the range of the invariant; by writing a conditional (eff1 ==> eff2 ) you can impose the rule selectively on those actions that have effect eff1. E.g. "all operations that alter x must also notify y ".

Any identifiable individual or thing. It may be a concrete, touchable, thing, like a car; or an abstract concept such as a meeting; or a relationship or a number or a computer system. Objects have individual identity, characteristic behavior, and some (perhaps mutable) state. In software, an object may be represented by some combination of stored state and executable code.

The effects of an object on the outcomes of the actions it takes part in; and their effects on it.

A named container for a unit of development work. All development artifacts are in some package -- including types, classes, compiled code, refinements, diagrams, documentation, change requests, code patches, architectural rules and patterns, tests, and other packages. A package is treated as a unit for versioning, configuration management, reuse, dependency tracking, and more. It also provide a scope for unique names of its elements.

A package whose name is itself scoped within a containing package. The contained package implicitly imports its container.

A named that informally denotes (as opposed to actually containing) some set of terms and definitions that you want to refer to from other packages. A virtual package can be "virtually" imported by a "real" package.

An attribute with parameters such as priceOf(Product) . Its value is a function from a list of parameters to an object identity. Unlike an operation, used only as an ancillary part of a behavioral description -- need not be implemented directly. A partial parameterized attribute has a precondition.

The exposed interfaces that define the `plugs' and `sockets' of the components, those places at which the component offers access to its services, and from which it accesses services of others. A plug can be coupled with any socket of a compatible type using a suitable connector.

A set of prerequisites associated with a framework; any elements substituted when applying this framework must meet those prerequisites in order for the framework to be applicable. Provisions are analogous to "design-time" preconditions.

A postcondition can refer to another action by naming it within brackets: [[action(...)]] ; this is called "quoting", and it means that the effect specified for that action is a part of this postcondition. If written as [[->action(...)]] , then the action must actually be invoked as part of the postcondition; if further prefixed with sent , it indicates an asynchronous invocation has to be made.

A specification (including invariants and pre/postconditions) that is implied by other parts of the model, but is included for emphasis or clarity. Such specs are prefixed with a "/" .

(3) Refine (verb) is the act of creating a refinement; also called "design", "implement", or "specialize".

A function which determines the value of an abstract attribute from the stored implementation data (or otherwise detailed attributes); used with a conformance to show how the attributes map to the abstraction, as a prerequisite to showing how the behavior specifications are also met.

Don't reuse implementation code unless you intend to reuse the specification as well. Otherwise you have no reason to believe that a revised version of the implementation won't break your code.

(4) If you can componentize your problem domain descriptions themselves and reuse domain models, you seriously enhance your position to reuse interface specifications and implementations downstream.

A textual representation of temporal composition of actions; some can be translated into an equivalent statechart

A depiction (usually as a drawing) of a set of objects and the values of some of their attributes at a particular point in time.

A design type, in contrast, is one that will participate directly in actions; its behaviors are of primary importance, and it is not just a means to factor the specification of some other type.

A Boolean attribute , drawn on a state chart. The structure of the states define invariants on those attributes (e.g. mutually exclusive states, inclusive states, or orthogonal sates); additionally, you should write explicit invariants relating the state attributes to other attributes in the type model.

A graphical description of a set of states and transitions.

A partial specification of an action, drawn as a directed edge on a state chart. The initial and final states are part of the pre/postcondition in the spec, and additional pre/post specs are written textually on the transition.

A set of objects defined by a predicate: unlike a true type, objects may move into and out of it during their lives. The predicate is defined within a parent true type -- e.g. "caterpillar" is a state within "lepidopter".

A predicate forming part of a type model, that should hold true on every permitted snapshot; specifically, before and after every action in the model. Some static invariants are written in text; other common ones, such as attribute types and associations as inverse attributes, have built-in notations.

A set of attributes, together with an invariant constitute the static part of a type model. The invariant says what combinations of attribute values make sense at any one time, and includes constraints on the existence, ranges, types, and combinations of individual attributes.

A shorthand syntax for applying a framework; a stereotype is used by referring to its name as «name», attached to any model element. Frameworks provide an extensibility mechanism to the modeling language; stereotypes provide a syntax for using this mechanism.

A type whose members form a subset of its supertype; all the specifications of the supertype are true of the subtype, which may add further specifications. (Note that we use "subclass" to mean inheritance of implementation.)

The activity of uncovering defects in an implementation by comparing its behavior against that of its specification, under a given set of run-time stimuli (the "test cases" or "test data").

The ability to relate elements in a detailed description with the elements in an abstraction that motivate their presence; and vice versa; the ability to relate implementation elements to requirements.

A set of objects that conform to a given type spec throughout their lives.

A named member of the type. E.g. " 7 " is a type constant of integer. Type constants can be globally referred to by type_name.member_name.

An expression denoting a type, using set-like operators -- e.g. " Women + Men ".

Type intersection -- or subtyping -- happens when a component or object must satisfy different clients. Each specification must be satisfied independently of the other. A type specification defines a set of instances -- the objects that satisfy that spec. Subtyping is about forming the intersection of two sets: those objects that happen to satisfy both specifications.

Joining happens when two views of the same type are presented in different places -- they might be in the same package or imported from different ones. Joining is about building the text and drawings of a specification from various partial descriptions.

A description of object behavior. It typically consists of a collection of action specs and a static model of attributes that help describe the effects of those actions. A type spec makes no statement about implementation.

Depicting the results of an import, possibly including substitutions, in the context of the importing package with the appropriate elements substituted.

A joint action with multiple participant objects that represents a meaningful business task, usually written in a structured narrative style. Like any joint action, a use case can be refined into a finer grained sequence of actions. Traditionally, the refined sequence is described as a part of the use case itself; we recommend it be treated as a refinement, even if the presentation be as a single template.