An element that cannot be instantiated.
An element in the use-case model that represents something external to a system. It can represent the role a user plays with respect to the system. It can also represent an external system or an external device.
An extension to an existing method.
The refinement of use cases to promote a better understanding of requirements and at the same time establish a platform-independent structure for the system. Analysis packages contain analysis classes, which can be boundary, control, or entity classes. Analysis use-case slices contain aspects as well.
An abstraction of the system from a platform-independent perspective. It contains the results of analysis.
An architectural view of a model highlights the important elements of a model and presents them through a set of diagrams and other accompanying description.
A model element that is part of some key functionality/capability of the system that is affected by some critical risks and decisions about the system.
The architecture of a system encompasses the major decisions about the system.
An early version of the system that exercises the important parts of the system. It is also known as the skinny system.
An architecture description describes the architecture baseline.
A programming construct in AOP that gives the ability to add class extensions into existing classes. An aspect in AOP contains pointcuts, advices, and intertype declarations.
A facet of the system.
A classifier that contains class extensions and instructions on how these class extensions will be overlaid to their respective classes.
A set of techniques to separate crosscutting concerns about a system in terms of aspects (or modularity units that can be composed into classes).
A set of techniques that provides the means to add additional behavior into existing classes and operations during compilation or execution in an unintrusive manner.
A Java language extension that implements AOP.
A code-generation technique that uses tags on classes, operations and attributes as parameters to code templates. An example of attribute-oriented programming is XDoclet.
When discussing the «include» and «extend» relationships between use cases, the base use case refers respectively to the use case that includes another use case and the use case that is extended by another use case.
The description of the normal, expected path through the use case. This is the path taken by most of the users most of the time.
A class is a categorization of objects that share the same attributes, operations, relationships, and semantics.
A modular extension to an existing class, the purpose of which is to realize a use case. It contains the features of the extended class that are specific to the use-case realization.
From UML, a collection of instances that have something in common. A classifier can have features that characterize its instances. Classifiers include interfaces, classes, datatypes, and components.
A small sequence of a few statements (in some programming language) that achieves some task.
The description (or view) of a set of interacting elements required to fulfill a particular task, usually a use-case realization or a mechanism.
The process of combining one or more slices (use case or non-use-case-specific) into the element structure.
Anything that is of interest to some stakeholder, whether an end user, a project sponsor, or even a developer.
An element that can be instantiated.
A concern that affects more than one class. Since use cases are realized by multiple classes, use cases are considered crosscutting concerns.
The translation of a system’s requirement specification into a platform-specific implementation of the system.
An abstraction of the implementation (i.e., code in any form—source files, scripts, configuration files).
The class or set of classes or a use-case slice that will be tested against some test cases.
An existing software unit (class, component, system, etc.) on top of which you add additional capabilities.
A relationship between two use cases in which one use case adds to the behavior of another. The extend relationship is similarly defined between use-case slices and use-case modules.
An extension represents additional behavior that executes in the context of an existing element. You can have extensions for operations, classes, and so on.
A special case of an alternate flow, which executes in the context of a separate use-case instance (other than the one in which it is specified).
A named point in the execution path of a use-case instance.
A high-level requirement normally used to justify the needs and benefits of a system.
A property, such as an operation or attribute, that characterizes the instances of a classifier.
A full or partial path through a use-case description. There is always at least a basic flow, and there maybe alternate flows and subflows.
A requirement that involves user interactions.
Giving something a name and possibly its location in some namespace.
The implementation refers to code. An implementation model contains the code and other artifacts needed by the runtime environment.
A relationship between two use cases—an including and included use case. The including use case specifies a location within itself in which the included use case is inserted.
The technique of using infrastructure service.
A software unit within a system that provides nonfunctional capabilities of the system.
The specification of the sequence of events that emerges when an infrastructure service is being used.
An instance of a class refers to a specific example of that class.
A named set of operations that characterize the behavior of an element.
A time period in a project that normally has an executable release at the end to demonstrate that some functionality or some stakeholder concerns have been met.
A point in the execution of a system.
A high level of partitioning of the system through different levels of abstraction. The application-specific layer is at the highest level. The system-specific layer is at the lowest level.
A pattern that solves recurring computer science problems in a system, such as persistency and distribution. It can be specified with a use case and realized as a collaboration. In this book, a mechanism is modeled as an infrastructure use case.
When two elements are merged, their contents are superimposed on one another, and the result is their mathematical union. See package merge.
A realization of an operation.
Part of a use-case design slice that has minimal platform specifics.
During testing, an element under test (EUT) may depend on some supporting elements. A mock element is a substitution for a supporting element to simplify the testing.
A complete description of a system from a particular perspective. It contains one or more hierarchical structures of model elements.
See structure.
The localization of all artifacts, including specification, realization, and implementation of a concern or a set of concern(s).
A software unit that can be developed independently from other software units.
Requirements such as performance, reliability, usability, and supportability. They normally affect multiple use cases.
A use-case slice that adds only classes into the element structure of the system. A non-use-case-specific slice does not contain any aspects.
An instance of a class.
A model that contains classes. The analysis model and the design model are examples of object models.
A set of techniques to separate concerns about a system in terms of classes.
A service that can be requested from an object to effect behavior. An operation has a declaration, which may restrict the actual parameters that are possible.
The additional behavior that executes in the context of an existing operation.
A UML element that contains other UML elements.
A package merge defines how one package extends another package by merging their contents.
A solution to a recurring problem.
Use-cases that have no explicit relationship between them and neither one depend on the other. They can, however, depend on something else.
The time between two major project milestones during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not move into the next phase. A phase comprises one or more iterations.
An expression that identifies a specific point or a set of points in the execution of a system.
A provided interface of a component is one that is implemented directly by the component.
A required interface of a component is one that the component needs to use.
A description of what the system must do or a condition that the system must conform to.
The responsibility of a class is the description of what the class must do. Responsibilities are found during analysis and are refined into operations during design.
Each instance in a collaboration plays a particular role, and from the role, the instance’s responsibilities and operations are identified.
The effect of having design of a concern spread across multiple design elements.
The technique of breaking down a complex problem into smaller problems so that the smaller problems can be solved individually and separately. The separation criteria are in terms of stakeholder concerns.
A containment hierarchy of elements of some kind. An analysis element structure is a containment hierarchy of analysis elements (boundary, control, entity classes). A model can have more than one structure.
A self-contained, labeled section of a flow. Subflows can be reused in many places within the flow of events where they are defined.
The effect whereby a particular design element or an operation needs to do more than its allocated requirements.
A parameterized element. In UML, it is denoted by a dashed box on the top right-hand corner that lists the parameters in the template.
A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement (use case).
A program or tool that allows a tester to exercise/examine in a controlled manner the unit of software being tested.
A program unit that stands in for another (more complex) program unit that is directly referenced by the unit being tested.
The evaluation of the behavior of a software element against its desired behavior.
A stereotyped dependency that relates how a model element from one model is derived from a model element in another model.
A use case models the behavior of a system. A use case is a sequence of actions performed by a system, which yields an observable result that is typically of value for one or more actors or other stakeholders of the system.
A model that describes the use of the system in terms of actors and use cases.
The localization of everything about a use case within a single package. It contains many use-case slices.
A use-case slice contains the specifics of a model in a single package. A use-case slice of the analysis or design model contains classes and aspects of classes specific to a use case. It also contains the collaboration that describes the realization of the use case in terms of interaction, communication, class diagrams, and so on.
A use-case specification is associated with a use case. It describes the behavior of a use case by walking through the interactions between actors and the system—what information is manipulated, presented, and persisted.
The use-case structure of a model (analysis, design, and implementation models) describes the relationships between use-case slices and non-use-case-specific slices in that model.
The user experience model captures the interaction between the user and the user experience (i.e., user interface) elements.
A use case that contains only extension flows and is meant only to extend other use cases.
A case that contains only subflows and is meant to be included by other use cases.
A view presents parts of a model as seen from a given perspective or vantage point and omits elements that are not relevant to this perspective. It is normally depicted as a diagram.
18.119.106.135