Glossary

Glossary abstract An element that cannot be instantiated. actor 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. advice (AOP) An extension to an existing method. analysis 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. analysis model An abstraction of the system from a platform-independent perspective. It contains the results of analysis. architectural view 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. architecturally significant element 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. architecture The architecture of a system encompasses the major decisions about the system. architecture baseline An early version of the system that exercises the important parts of the system. It is also known as the skinny system. architecture description An architecture description describes the architecture baseline. aspect (AOP) 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. aspect (English) A facet of the system. aspect (stereotyped classifier) A classifier that contains class extensions and instructions on how these class extensions will be overlaid to their respective classes. aspect orientation A set of techniques to separate crosscutting concerns about a system in terms of aspects (or modularity units that can be composed into classes). aspect-oriented programming (AOP) 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. AspectJ A Java language extension that implements AOP. attribute-oriented programming 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. base use case 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. basic flow 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. class A class is a categorization of objects that share the same attributes, operations, relationships, and semantics. class extension 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. classifier 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. code fragment A small sequence of a few statements (in some programming language) that achieves some task. collaboration The description (or view) of a set of interacting elements required to fulfill a particular task, usually a use-case realization or a mechanism. composition The process of combining one or more slices (use case or non-use-case-specific) into the element structure. concern Anything that is of interest to some stakeholder, whether an end user, a project sponsor, or even a developer. concrete An element that can be instantiated. crosscutting concern A concern that affects more than one class. Since use cases are realized by multiple classes, use cases are considered crosscutting concerns. design The translation of a system's requirement specification into a platform-specific implementation of the system. design model An abstraction of the implementation (i.e., code in any formsource files, scripts, configuration files). element under test (EUT) The class or set of classes or a use-case slice that will be tested against some test cases. existion An existing software unit (class, component, system, etc.) on top of which you add additional capabilities. extend relationship 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. extension An extension represents additional behavior that executes in the context of an existing element. You can have extensions for operations, classes, and so on. extension flow 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). extension point A named point in the execution path of a use-case instance. feature A high-level requirement normally used to justify the needs and benefits of a system. feature (UML) A property, such as an operation or attribute, that characterizes the instances of a classifier. flow 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. functional requirement A requirement that involves user interactions. identification Giving something a name and possibly its location in some namespace. implementation The implementation refers to code. An implementation model contains the code and other artifacts needed by the runtime environment. include A relationship between two use casesan including and included use case. The including use case specifies a location within itself in which the included use case is inserted. infrastructure mechanism The technique of using infrastructure service. infrastructure service A software unit within a system that provides nonfunctional capabilities of the system. infrastructure use case The specification of the sequence of events that emerges when an infrastructure service is being used. instance An instance of a class refers to a specific example of that class. interface A named set of operations that characterize the behavior of an element. iteration 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. join point A point in the execution of a system. layer 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. mechanism 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. merge When two elements are merged, their contents are superimposed on one another, and the result is their mathematical union. See package merge. method A realization of an operation. minimal use-case design slice Part of a use-case design slice that has minimal platform specifics. mock element 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. model A complete description of a system from a particular perspective. It contains one or more hierarchical structures of model elements. model structure See structure. modularity The localization of all artifacts, including specification, realization, and implementation of a concern or a set of concern(s). module A software unit that can be developed independently from other software units. nonfunctional requirements Requirements such as performance, reliability, usability, and supportability. They normally affect multiple use cases. non-use-case-specific slice 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. object An instance of a class. object model A model that contains classes. The analysis model and the design model are examples of object models. object orientation A set of techniques to separate concerns about a system in terms of classes. operation 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. operation extension The additional behavior that executes in the context of an existing operation. package A UML element that contains other UML elements. package merge A package merge defines how one package extends another package by merging their contents. pattern A solution to a recurring problem. Peer use-cases Use-cases that have no explicit relationship between them and neither one depend on the other. They can, however, depend on something else. phase 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. pointcut An expression that identifies a specific point or a set of points in the execution of a system. provided interface A provided interface of a component is one that is implemented directly by the component. required interface A required interface of a component is one that the component needs to use. requirement A description of what the system must do or a condition that the system must conform to. responsibility 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. role Each instance in a collaboration plays a particular role, and from the role, the instance's responsibilities and operations are identified. scattering The effect of having design of a concern spread across multiple design elements. separation of concerns 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. structure 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. subflow A self-contained, labeled section of a flow. Subflows can be reused in many places within the flow of events where they are defined. tangling The effect whereby a particular design element or an operation needs to do more than its allocated requirements. template 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. test case 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). test driver A program or tool that allows a tester to exercise/examine in a controlled manner the unit of software being tested. test stub A program unit that stands in for another (more complex) program unit that is directly referenced by the unit being tested. testing The evaluation of the behavior of a software element against its desired behavior. trace A stereotyped dependency that relates how a model element from one model is derived from a model element in another model. use case 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. use-case model A model that describes the use of the system in terms of actors and use cases. use-case module The localization of everything about a use case within a single package. It contains many use-case slices. use-case slice 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. use-case specification 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 systemwhat information is manipulated, presented, and persisted. use-case structure 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. user experience model The user experience model captures the interaction between the user and the user experience (i.e., user interface) elements. utility-extension use case A use case that contains only extension flows and is meant only to extend other use cases. utility use case A case that contains only subflows and is meant to be included by other use cases. view 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.