Term
|
Definition
| Actor. Someone or something that has an external interface with the system. The name of an actor conveys a role played by a person, organization or another system when it interacts with the system of interest. Display actors on Block Definition Diagrams (bdd) to express generalizations between actors and associations between actors and blocks. Actors on use case diagrams express which use cases each actor participates in. Constraints: Cannot define a generalization between an actor and a block, and an actor cannot have parts; it can't appear at the composite end of a composite association. Always regard an actor as a black box (Delligatti, pp. 53-55). Actor of a use case, shown as a stick figure, uses the subject to achieve the actor's goals defined by the use case (Friedenthal, Moore & Steiner, p. 59). |
|
|
Term
|
Definition
| A rake symbol on an activity diagram represents a call behavior action that can refer to another activity diagram. A rake symbol on a package diagram represents a package that can refer to another package diagram (Friedenthal, Moore & Steiner, p. 95). |
|
|
Term
|
Definition
| The name of an operation is followed by two brackets, not optional, that form part of the name of the operation (Holt & Perry, p. 103). |
|
|
Term
|
Definition
| Guillemets (Friedenthal, Moore & Steiner, p. 92). Double chevrons (Holt & Perry, p. 131). Used to enclose stereotypes (OMG SysML Spec., v1.6) and keywords (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| Control flow, best expressed in a sequence diagram (Friedenthal, Moore & Steiner, p. 61). Used to specify the sequence of actions, depicted as a dashed line with an arrowhead (63). |
|
|
Term
|
Definition
| Object flows connect outputs from one action to the input of another (Friedenthal, Moore & Steiner, p. 45). Specifies the flow of inputs and outputs (63). A solid line with an arrowhead connects the output pin from one action in an activity diagram to the input pin of another action (64). |
|
|
Term
|
Definition
| Black-filled arrowheads on connectors are item flows, representing the items flowing between parts, which could include mass, energy and/or information (Friedenthal, Moore & Steiner, p. 66). |
|
|
Term
|
Definition
| Indicates direction of an association (Holt & Perry, p. 100). |
|
|
Term
|
Definition
| Designates top-level model (Friedenthal, Moore & Steiner, p. 56). |
|
|
Term
| ∇ (should have a line attached to the top) |
|
Definition
| "Is a type of" going from the subtitle to the supertype (Delligatti, p. 49). Subclasses are indicated by a hollow triangle symbol. They inherit common features from the parent. A classification can be created by specializing blocks from more generalized blocks (Friedenthal, Moore & Steiner, p. 59). |
|
|
Term
|
Definition
| Required Interface--may invoke one or more but not necessarily all of its operations or receptions at some point during system operation. Socket notation--stick with a semicircle attached to the standard port square (Friedenthal, Moore & Steiner, p. 37). |
|
|
Term
|
Definition
| Provided interface--must implement all of the interface's operations and receptions. Ball notation--lollipop symbol attached to the standard port square (Delligatti, p. 36). |
|
|
Term
|
Definition
| The line with the crosshairs symbol denotes containment (Friedenthal, Moore & Steiner, p. 57). |
|
|
Term
| ¥ (should have one bold dot in the center) |
|
Definition
| Activity final node, where the activity terminates with a bull's-eye symbol (Friedenthal, Moore & Steiner, p. 63). |
|
|
Term
|
Definition
| When an activity is initiated, it starts execution at the initial node (filled in circle) (Friedenthal, Moore & Steiner, p. 63). |
|
|
Term
|
Definition
| Black diamond on one end of a line connecting blocks indicates the comparison relationship between them (Friedenthal, Moore & Steiner, p. 45). Whole-part relationship called a composite association. The arrowhead points to the blocks that compose the whole (59). Composition is shown by the use of a solid diamond at the "whole" end of a whole/part relationship (Holt & Perry, p. 104). |
|
|
Term
|
Definition
| White diamond, aggregation relationship (Friedenthal, Moore & Steiner, p. 46). Hollow diamond; allows the block representing the part to be part of more than one owning block at the same time (Holt & Perry, p. 104). |
|
|
Term
| ¨ (should have arrow inside) |
|
Definition
| Atomic flow port, to model a single type of item that could flow in or out via that port. The symbol inside the small square is an arrow conveying direction of flow. Type must be the name of a value type, block, or signal in the model (Delligatti, p. 39). |
|
|
Term
| [image](left side should also be black framed) |
|
Definition
| A model element called a comment. Sometimes need to express information on a diagram in an unconstrained way as a block of text. A single attribute: A string of text called the body. Can attach a comment to other elements on a diagram to provide additional information. Can use comments on any of the nine kinds of Systems Modeling Language (SysML) diagrams. Notation for a comment is a note symbol: A rectangle whose upper right corner is bent. Use a dashed line to attach a comment to other elements. Can attach a comment to several model elements simultaneously by using a separate dashed line for each one. Put freestanding comments with hyperlinks on a diagram to enable readers to quickly navigate to a related diagram in the model (or to an external document). SysML defines some specialized types of comments: rationale, problem and diagram description. These appear as a note symbol with the stereotype preceding the body. Use rationale comments with requirements relationships and allocations (Delligatti, pp. 59-60). A textual description that can be associated with any other model element, shown on any diagram, using a note symbol connected to a symbol representing the model element it describes. Difference between a comment and a note symbol is that a comment is a model element that is part of the model, whereas a note symbol is a diagram annotation only (Friedenthal, Moore & Steiner, p. 97). |
|
|
Term
|
Definition
| Package Diagram (pkg). Displays the way a model is organized in the form of a containment hierarchy (Delligatti, p. 16). Allowable model element types: package, model, model library, view, profile (20). Presents the organization of a model in terms of packages that contain model elements (Friedenthal, Moore & Steiner, p. 32). Organizes the model elements contained in the model (34). Each package contains a set of model elements, and each model element is contained in only one package. The package is said to own the elements that are contained within it. The package is a namespace for the contained model elements (56). A rake symbol on a package diagram represents a package that can refer to another package diagram (95). Organizes the model (Holt & Perry, p. 96). |
|
|
Term
|
Definition
| Conjugated. A tilde in front of the type of a non-atomic flow port indicates that the directions of the flow properties in the flow specification are reversed for that flow port (Delligatti, p. 38). |
|
|
Term
|
Definition
| Ellipsis in the bottom of the parts compartment of a block diagram indicates that some entries are hidden (Friedenthal, Moore & Steiner, p. 89). Useful for reducing clutter and focusing on the diagram's purpose, to know that there is information about a model element that could be shown but is hidden. Show an ellipsis at the bottom of a compartment on a symbol to indicate that not all of the potentially visible compartment elements are shown (95). |
|
|
Term
|
Definition
| Colon. In action names, indicates a particular usage associated with a reusable definition (Friedenthal, Moore & Steiner, p. 34). Used to distinguish the part (usage) from the block (definition). Usage name begins in lower case and definitions begin with upper case (71). |
|
|
Term
|
Definition
| Separator between the path name and the model in which it is contained, in the fully qualified name (Friedenthal, Moore & Steiner, p. 56). |
|
|
Term
|
Definition
AKA 0..∗
Indicates any [positive, whole] number, including zero (Holt & Perry, p. 101). |
|
|
Term
|
Definition
AKA ∗
Indicates any [positive, whole] number, including zero (Holt & Perry, p. 101). |
|
|
Term
|
Definition
| Indicates an optional value (Holt & Perry, p. 101). |
|
|
Term
|
Definition
| Indicates [each, or] exactly one, as multiplicity on an association (Holt & Perry, p. 101). |
|
|
Term
|
Definition
| Indicates 1 or more (Holt & Perry, p. 101). |
|
|
Term
| 2 Aspects of a SysML Model |
|
Definition
- Structural.
- Behavioral (Holt & Perry).
|
|
|
Term
| 2 Basic Elements of a Block Definition Diagram (bdd). |
|
Definition
- Block.
- Relationship (Holt & Perry).
|
|
|
Term
| 3 Considerations / Aspects for Implementing Model-Based Systems Engineering (MBSE) |
|
Definition
AKA MBSE Mantra
- People (trained).
- Process.
- Tools (enablers) (Holt & Perry, pp. 11, 29).
|
|
|
Term
|
Definition
AKA Triangle of Evil
AKA Vicious Triangle
- Complexity.
- Lack of understanding.
- Poor communications (Holt & Perry, pp. 8, 87).
Unmanaged complexity will lead to lack of understanding and communications problems. Communications problems will lead to unidentified complexity and lack of understanding. A lack of understanding will lead to communication problems and complexity (91). |
|
|
Term
| 3 Key Concepts for Model-Based Systems Engineering (MBSE) Success |
|
Definition
AKA MBSE Fundamentals
- The goal.
- The approach.
- Visualization (Holt & Perry, p. 29).
|
|
|
Term
|
Definition
- Part properties.
- Reference properties.
- Value properties (Holt & Perry).
|
|
|
Term
| 3 Main Types of Relationships Between Blocks |
|
Definition
- Associations.
- Generalizations.
- Dependencies (Delligatti, p. 44).
|
|
|
Term
| 3 Pillars of Model-Based Systems Engineering (MBSE) AKA 3 Skills Needed to be a Model Builder |
|
Definition
- Modeling language.
- Modeling method.
- Modeling tool (Delligatti, p. 4) (OCSMP Accelerator, Module-0, Seg-1).
|
|
|
Term
| 3 Skills Needed to be a Model Builder AKA 3 Pillars of Model-Based Systems Engineering (MBSE) |
|
Definition
- Modeling language.
- Modeling method.
- Modeling tool (Delligatti, p. 4) (OCSMP Accelerator, Module-0, Seg-1).
|
|
|
Term
|
Definition
- Use Case Diagram (uc).
- Sequence Diagram (sd, seq).
- State Machine Diagram (stm).
- Activity Diagram (act) (Holt & Perry, pp. 97-98).
|
|
|
Term
|
Definition
- Block Definition Diagram (bdd).
- Package Diagram (pkg).
- Internal Block Diagram (ibd).
- Parametric Diagram (par).
- Requirements Diagram (req) (Holt & Perry, pp. 96-97).
|
|
|
Term
| 9 Diagrams of Systems Modeling Language (SysML) |
|
Definition
- Package Diagram (pkg).
- Requirements Diagram (req).
- Activity Diagram (act).
- Sequence Diagram (sd, seq).
- State Machine Diagram (stm).
- Use Case Diagram (uc).
- Block Definition Diagram (bdd).
- Internal Block Diagram (ibd).
- Parametric Diagram (par) (Delligatti, p. 19; Friedenthal, Moore & Steiner, p. 32).
|
|
|
Term
|
Definition
| Create generalizations to define abstractions. A supertype is an abstraction of its subtypes. It factors out those features that are common among the subtypes. Abstractions let you define a common feature in one place within the model, the supertype, and that common feature propagates down the type hierarchy to all the subtypes. If you later need to change that common feature, go back to that one place in the model to make the change and all subtypes in the model get updated instantly (Delligatti, p. 51). Designing to an abstraction creates extensibility. When the customer's requirements change later in the lifecycle and you need to add a new type, you can simply define a new subtype of the block, and that addition will be transparent to all clients that reference the block (52). The principle of designing to an abstraction, and it's consequent extensibility, applies to the practice of creating a value type hierarchy (57). |
|
|
Term
|
Definition
| A special type of system of systems that has designated management and resources, and a consensus of purpose. Each constituent system retains its own management and operation (Holt & Perry, p. 39). |
|
|
Term
|
Definition
| Activity diagram specifies a behavior, with focus on the flow of control and the transformation of inputs into outputs through a sequence of actions. Analysis tool to understand and express the desired behavior of a system (Delligatti, p. 16). Allowable model elements types: activity (20). Presents flow-based behavior indicating the order in which actions execute based upon the availability of their inputs, outputs and control, and how the actions transform the inputs to outputs. An activity diagram can include diagram elements that present actions, control flow, and input/output flow (i.e., object flow), but not diagram elements for connectors and ports (Friedenthal, Moore & Steiner, pp. 32-33). Behaviors that emphasize input and output flow as well as control flow can sometimes be more effectively expressed with activity diagrams (61). Include semantics for precisely specifying the behavior in terms of the flow of control and flow of inputs and outputs (63). A rake symbol on an activity diagram represents a call behavior action that can refer to another activity diagram (95). The sequence of actions on an activity diagram can be arranged from top to bottom or from left to right to reflect their time ordering (96). |
|
|
Term
|
Definition
| A set of actions that need to be performed in order, to successfully execute a process. Each activity must have a responsible stakeholder role associated with it and utilizes one or more resources (Holt & Perry, p. 63). |
|
|
Term
|
Definition
| Specifies a behavior, with focus on the flow of control and the transformation of inputs to outputs through a sequence of actions. Analysis tool to understand and express the desired behavior of a system (Delligatti, p. 16). Allowable model element type: activity (20). Presents flow-based behavior indicating the order in which actions execute based on the availability of their inputs, outputs and control, and how the actions transform the inputs to outputs. Can include diagram elements that present actions, control flow, and input/output flow (i.e., object flow), but not diagram elements for connectors and ports (Friedenthal, Moore & Steiner, pp. 32-33). Behaviors that emphasize input and output flow as well as control flow can sometimes be more effectively expressed with activity diagrams (61). Include semantics for precisely specifying the behavior in terms of the flow of control and flow of inputs and outputs (63). A rake symbol on an activity diagram represents a call behavior action that can refer to another activity diagram (95). May be arranged from top to bottom or from left to right to reflect time ordering (96). |
|
|
Term
|
Definition
| The activity terminates with a bull's-eye symbol (Friedenthal, Moore & Steiner, p. 63). |
|
|
Term
|
Definition
AKA Swimlane
(Friedenthal, Moore & Steiner, p. 37). In order to define an activity partition that corresponds to a particular block, the modeler opens the activity partition specification, then selects the particular block that is represented by the partition. Each action is placed within the activity partition corresponding to the block that is responsible for performing the action (45). |
|
|
Term
|
Definition
| Someone or something that has an external interface with your system. The name of an actor conveys a role played by a person, organization or another system when it interacts with your system. Display actors on Block Definition Diagrams (bdd) to express generalizations between actors and associations between actors and blocks. Actors on use case diagrams express which use cases each actor participates in. Constraints: Cannot define a generalization between an actor and a block, and an actor cannot have parts; it can't appear at the composite end of a composite association. Always regard an actor as a black box (Delligatti, pp. 53-55). Of a use-case, shown as a stick figure, uses the subject to achieve the actor's goals defined by the use case (Friedenthal, Moore & Steiner, p. 59). |
|
|
Term
|
Definition
Arrowheads and text attached to a path or edge line diagram element (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| White diamond (Friedenthal, Moore & Steiner, p. 46). Hollow diamond, allows the block representing the part to be part of more than one owning block at the same time. Shows structural hierarchies (Holt & Perry, p. 104). |
|
|
Term
|
Definition
| To assign behavioral activities to a block (Friedenthal, Moore & Steiner, p. 59). The object flow that connects an input to an output on an activity diagram can be allocated to the item flows on the connectors in an internal block diagram. A general-purpose relationship for mapping one model element to another (66). |
|
|
Term
|
Definition
| On an interaction, stands for alternative and indicates that the interaction occurs as a condition of the state shown in brackets (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| A block definition diagram used to define equations for analysis. A constraint block defines constraints in terms of reusable equations and their parameter definitions that can be used by one or more analyses (Friedenthal, Moore & Steiner, p. 72). |
|
|
Term
| Analyze Stakeholder Needs |
|
Definition
The second step in the simplified Model-Based Systems Engineering (MBSE) method. To understand the problem to be solved, the goals the system is intended to support, and the effectiveness measures needed to evaluate how well the system supports these goals and satisfies stakeholder needs.
- Identify stakeholders and the problems to be addressed.
- Define the domain model (block definition diagram) to identify the system and external systems and users.
- Define the top level use cases to represent the goals the system is intended to support.
- Define the Measures of Effectiveness (MoE) to quantify the value of a proposed solution for the stakeholders (Friedenthal, Moore & Steiner, p. 47).
|
|
|
Term
|
Definition
| Based on an architectural framework. Made up of views, with each view being a realization of a viewpoint (Holt & Perry, p. 55). Fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [ISO-15288]. Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [ISO/IEC-42010] (47). |
|
|
Term
|
Definition
| Process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system's lifecycle (Holt & Perry, p. 47). |
|
|
Term
| Architectural Framework Concern |
|
Definition
| Defines a need that an architecture framework has to address (Holt & Perry, p. 54). |
|
|
Term
| Architecture Description (AD) |
|
Definition
| Work product used to express an architecture (Holt & Perry, p. 47). |
|
|
Term
| Architecture Description Language (ADL) |
|
Definition
| Expression for use in architecture descriptions (Holt & Perry, p. 47). |
|
|
Term
| Architecture Framework (AF) |
|
Definition
| Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders (Holt & Perry, p. 47). Specification of how to organize and present architectural models. Defines a standard set of model categories (called views) which each have a specific purpose, categorized by the domain they cover, which are known as viewpoints (51). Defined set of one or more viewpoint and an ontology. Used to structure an architecture from the point of view of a specific industry, stakeholder role set, or organization. Created such that it complies with zero or more standards. Meets the needs defined by one or more architectural framework concerns (54). Made up of a number of viewpoints that define the information that can be presented (55). |
|
|
Term
|
Definition
| Work product expressing the architecture of a system from the perspective of specific system concerns (Holt & Perry, p. 47). |
|
|
Term
|
Definition
| Work product establishing the conventions for the construction, interpretation, and use of architecture views to frame specific system concerns (Holt & Perry, p. 47). |
|
|
Term
|
Definition
| Of an operation call, are the input data and return (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| Something that is produced or consumed by an activity in a process (documentation, software, hardware, systems) (Holt & Perry, p. 63). |
|
|
Term
|
Definition
| An element of definition which can serve as the type for one or more connectors. Optionally display the association name floating near the middle of the line, and optionally display a role name and multiplicity on either end of the line. The association name is modeler-defined string that describes the type of connection that can exist between instances of the two blocks (Delligatti, pp. 44-45). A general type of relationship that relates together one or more block. Represented by a line that joins two blocks with the association name written on the line and a direction marker showing which way the relationship should be read (Holt & Perry, p. 99). The direction of an association is shown by a small, filled-in triangle. The directionality of an association can be augmented through the use of role names on each end of the association. Association and role names should be chosen so that they make the diagrams as unambiguous as possible (100). |
|
|
Term
|
Definition
| The sender does not wait for a reply. Notated by an open arrowhead (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| To model a single type of an item that could flow in or out via that port. The symbol inside the small square is an arrow conveying direction of flow. Type must be the name of a value type, block or signal in the model (Delligatti, p. 39). |
|
|
Term
|
Definition
| Has an included use case via inclusion relationship (Friedenthal, Moore & Steiner, p. 60). |
|
|
Term
|
Definition
| Block Definition Diagram. Displays elements such as blocks and value types and the relationships between those elements. Used to display system hierarchy trees and classification trees (Delligatti, p. 15). Allowable model element types: package, model, model library, view, block, constraint block (20). Primary kind of diagram to communicate structural information about a system. Expresses the types of structures that can exist internally within a system and externally in a system's environment. Expresses the types of services each structure provides and requires, the types of constraints each structure must conform to, and the types of values that can exist within an operational system (61). Presents structural elements, called blocks, and their composition and classification (Friedenthal, Moore & Steiner, p. 32). Captures the relation between blocks, such as block hierarchy (58). |
|
|
Term
|
Definition
Dynamic; convey temporal relationships; passage of time (Delligatti, OCSMP Accelerator, Module-1, Part-1, Seg.-1).
- Activity diagrams.
- Sequence diagrams.
- State machine diagrams.
- Use-case diagrams (Delligatti, p. 15) (Friedenthal, Moore & Steiner, p. 96).
|
|
|
Term
|
Definition
Shows the "how" of the system. Identifies the behavior of the system at the system level, between system elements, within system elements, and within operations of system elements (Holt & Perry, p. 106). Four behavioral diagrams:
- Use-Case Diagram (uc).
- Sequence Diagram (sd, seq).
- State Machine Diagram (stm).
- Activity Diagram (act) (96-97).
|
|
|
Term
|
Definition
| Operations and receptions that a block or interface can perform (Delligatti, p. 39). Activities allocated to a block or operations of the block (Friedenthal, Moore & Steiner, p. 59). |
|
|
Term
|
Definition
- A model provides much finer control of information than is available in a document-based approach, where information may be spread across many documents and the relationships between them may not be explicitly defined.
- Integrates system requirements, design, analysis and verification information to address multiple aspects of the system in a cohesive manner, rather than dealing with a disparate collection of individuals.
- Enhanced communications with a shared understanding of the system from multiple perspectives.
- More rigorous traceability between requirements, design, analysis and testing. Enhances timeliness.
- Increased productivity: Faster and more comprehensive impact analysis of requirements and design changes.
- Reuse of existing models to support design evolution.
- Leveraging models during downstream lifecycle phases: Support operator training on the use of the system. Support diagnostics and maintenance of the system (Friedenthal, Moore & Steiner, pp. 19-20).
|
|
|
Term
|
Definition
| Absence of arrowhead on either end of a solid line connecting two blocks of a block definition diagram, to show reference association (Delligatti, p. 44). |
|
|
Term
|
Definition
| A parameter in one equation can be bound to a parameter in another equation by a binding connector (e.g., "is equal to") (Friedenthal, Moore & Steiner, p. 73). Parameters can be bound to value properties of blocks to equate the parameter of an equation to a value property of the system or environment. Binding enables values of parameters of generic equations to be set equal to values of specific value properties of the blocks. Generic equations can be reused to analyze different designs by binding the parameters of the generic equations to value properties of different designs (74). |
|
|
Term
|
Definition
| High level of abstraction (Holt & Perry, p. 95). |
|
|
Term
|
Definition
| On one end of a line connecting blocks indicates the composition relationship between them (Friedenthal, Moore & Steiner, p. 45). |
|
|
Term
|
Definition
| Basic unit of structure in Systems Modeling Language (SysML), used to model any type of entity within the system of interest or in the system external environment. Notation for a block is a rectangle with the stereotype <<block>> preceding the name in the name compartment. Required to display a block's name compartment (Delligatti, p. 26). Three main types of relationships that can exist between blocks are associations, generalizations and dependencies (44). Used to define a system or component at any level of the system hierarchy (Friedenthal, Moore & Steiner, p. 34). Used to model entities that have structure, such as systems, hardware and equipment, software or physical objects. Can represent real or abstract entity that can be conceptualized as a structural unit with one or more distinguishing features (58). A type of "thing" that exists in the system being modeled, named using nouns or noun phrases, represented by rectangles, each containing a name written inside the rectangle, and the stereotype <<block>> (Holt & Perry, p. 99). Blocks are conceptual and do not actually exist in the real world. A block represents a grouping of things that look and behave in the same way. At one level, all examples will have a common set of features and behaviors that may be represented by the block. What the block is really representing is the blueprint or essence of the thing (100). |
|
|
Term
| Block Definition Diagram (bdd) |
|
Definition
| Displays elements such as blocks and value types and the relationships between those elements. Used to display system hierarchy trees and classification trees (Delligatti, p. 15). Allowable model element types: package, model, model library, view, block, constraint block (20). Primary kind of diagram to communicate structural information about a system. Expresses the types of structures that can exist internally within a system and externally in a system's environment. Expresses the types of services each structure provides and requires, the types of constraints each structure must conform to, and the types of values that can exist within an operational system (61). Presents structural elements, called blocks, and their composition and classification (Friedenthal, Moore & Steiner, p. 32). Captures the relation between blocks, such as a block hierarchy (50). Describes the system hierarchy and system/component classifications. Properties and behavior of system elements (Holt & Perry, p. 96). |
|
|
Term
|
Definition
| The single attribute of a comment; a string of text (Delligatti, p. 59). |
|
|
Term
|
Definition
| Nonquantitative primitive value type (Delligatti, p. 55). A Boolean constraint expression must evaluate to either true or false (57). |
|
|
Term
|
Definition
| Activity final node (Friedenthal, Moore & Steiner, p. 37) where the activity terminates (63). |
|
|
Term
|
Definition
| Invokes a more detailed behavior when it executes (Friedenthal, Moore & Steiner, p. 63). |
|
|
Term
|
Definition
AKA Diagram Content
Region inside the frame where model elements and relationships can be displayed (Delligatti, p. 17). Expressed using node symbols such as rectangles, ovals and round-angles connected by line symbols. The diagram symbols can be adorned with text, icons, tool-specific features, such as font and color (Friedenthal, Moore & Steiner, p. 87). The rest of the area enclosed by the diagram frame, less the header. This is the content area where symbols are shown (90). Contains elements that graphically represent model elements. Includes the diagram elements (symbols) that present the model elements of interest (92). |
|
|
Term
|
Definition
| A special type of need, the context of which will typically represent one or more projects (as a project context) or one or more organizational unit (as an organizational context). A capability will meet one or more goal and will represent the ability of an organization or organizational unit (Holt & Perry, p. 46). |
|
|
Term
|
Definition
| When it comes time to make a change to a block in a diagram, the modeling tool will automatically make that change to all the places where that block appears (Delligatti, OCSMP Accelerator, Module-0, Seg-2). |
|
|
Term
|
Definition
| Inherits its properties and operations from its parent block, but will be different in some way in order to make it special. A child block will inherit any properties and operations that its parent block has, but may have additional properties or operations that make the child block special. A block can have additional properties and operations not found in any of its ancestor blocks. Inheritance only runs from parent blocks to child blocks (Holt & Perry, pp. 105-106). |
|
|
Term
|
Definition
| Type hierarchy created by generalization relationships of transitive inheritance between supertypes and subtypes (Delligatti, p. 49). |
|
|
Term
|
Definition
| In a dependency relationship, one element in the model, the client, depends on another element in the model, the supplier. When the supplier element changes, the client element may also have to change (Delligatti, p. 52). |
|
|
Term
|
Definition
| The extent to which a component can perform its functions without requiring access to external data. The object-oriented concept of encapsulation reflects this concept (Friedenthal, Moore & Steiner, p. 27). |
|
|
Term
|
Definition
| A special type of System-of-Systems (SoS) that lacks central management and resources, but has consensus of purpose (Holt & Perry, p. 43). |
|
|
Term
|
Definition
| Of instances, when a part property [or reference property, or value property] has a multiplicity greater than 1 (Delligatti, p. 29). |
|
|
Term
|
Definition
| A model element. Sometimes need to express information on a diagram in an unconstrained way as a block of text. A single attribute: A string of text called the body. Can attach a comment to other elements on a diagram to provide additional information. Can use comments on any of the nine kinds of Systems Modeling Language (SysML) diagrams. Notation for a comment is a note symbol: A rectangle whose upper right corner is bent. Use a dashed line to attach a comment to other elements. Can attach a comment to several model elements simultaneously by using a separate dashed line for each one. Put freestanding comments with hyperlinks on a diagram to enable readers to quickly navigate to a related diagram in the model (or to an external document). SysML defines some specialized types of comments: rationale, problem and diagram description. These appear as a note symbol with the stereotype preceding the body. Use rationale comments with requirements relationships and allocations (Delligatti, pp. 59-60). A textual description that can be associated with any other model element, shown on any diagram, using a note symbol connected to a symbol representing the model element it describes. Difference between a comment and a note symbol is that a comment is a model element that is part of the model, whereas a note symbol is a diagram annotation only (Friedenthal, Moore & Steiner, p. 97). |
|
|
Term
|
Definition
Problems may occur at any level:
- Person-to-person: May be because of language difficulties, technical background differences, clash of personalities.
- Group-to-group: May be from different technical areas, may span boundaries such as management vs. Subject Matter Experts (SME) / Systems Engineer Technical Assistants (SETA), often use language specific to themselves (stovepipes).
- Organization-to-organization: Each will have their own specific terms for concepts, as well as having industry specific terminology. When two organizations are working in a customer-supplier relationship, the onus is often on the supplier to speak the customer's language so that communication can be effective, rather than the customer having to speak the supplier's language.
- System-to-system: Technical systems must be able to communicate with each other, with financial and accountancy systems, environmental systems, etc. (Holt & Perry, p. 90).
|
|
|
Term
|
Definition
| Of a block: Parts, references, values, constraints, operations, receptions, standard ports, flow ports, full ports, proxy ports, flow properties, structure (Delligatti, p. 27). |
|
|
Term
|
Definition
| A predefined field in the optional diagram description, with a statement of the completeness of the diagram relative to its intended completeness. "In process," "draft," "complete." May include a specific description of the information that is still missing from the diagram (Friedenthal, Moore & Steiner, p. 92). |
|
|
Term
|
Definition
| Structured value type with two value properties, realPart and imaginaryPart, that are both of type Real (Delligatti, p. 56). |
|
|
Term
|
Definition
| One of the reasons it is so easy to misjudge the size and complexity of a project is that in many cases, many elements of the system will not be tangible or comprehensible (Holt & Perry, p. 86). The more relationships are added between the system elements, the higher the complexity of the overall system (87). Just because someone understands each element within a system, this does not mean that the system itself is understood. The complexity of a system manifests itself by relationships between things. The complexity may manifest itself at any point in the system. The complexity of the whole of the system is higher than the [sum of the complexity] of its parts. The perceived complexity of a project is almost always low to begin with, but balloons during the analysis of a project, as the understanding of the full impact of the requirements and the constraints is fully understood (88). there is a danger of the system being oversimplified and the complexity inherent in the system is never uncovered until it is too late. Complexity is difficult to visualize, but definitely exists in any system (89). |
|
|
Term
|
Definition
AKA Composition Relationship
Between two blocks, conveys structural decomposition. An instance of the block at the composite end is made of some number of instances of the block at the part end. Notation for a composite association on a Block Definition Diagram (bdd) is a solid line between two blocks with a solid diamond on the composite end. An open arrowhead on the part end conveys unidirectional access from the composite to its part; the absence of an arrowhead on the part end conveys bidirectional access (the part will have a reference to the composite). The role name shown on the part end of a composite association corresponds to the name of a part property--one that's owned by the block at the composite end and whose type is the block at the part end. The multiplicity on the composite end is restricted. A part--by definition--can belong to only one composite at a time. The upper bound of the multiplicity on the composite end must always be 1. The lower bound of that multiplicity can be either 0 or 1. A lower bound of 0 conveys that a part can be removed from its composite structure; a lower bound of 1 conveys that it cannot be removed (it must be attached to a composite structure at all times in a valid instance of a system). The default multiplicity on the composite end of a composite association is 0..1. On the part end, the default multiplicity is 1 (Delligatti, p. 48). Whole-part relationship with a black diamond (Friedenthal, Moore & Steiner, p. 45) at the whole side, and an arrow at the part side, connecting blocks that compose the whole (59). Allows emphasis to be placed on the "whole/part" relationships between system elements. Composition is shown by use of a solid diamond at the "whole" end of the relationship. Composition can take multiplicities and role names. Shows that the block representing the part can only be part of one owning block at a time. Shows structural hierarchies (Holt & Perry, pp. 103-104). |
|
|
Term
|
Definition
AKA Ontology
AKA Metamodel
Domain-specific vocabulary reflecting core concepts (Friedenthal, Moore & Steiner, p. 25). |
|
|
Term
|
Definition
| Interest in a system relevant to one or more of its stakeholders. Pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological, and social influences (Holt & Perry, p. 47). |
|
|
Term
|
Definition
| The functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product [SEBOK]. The possible conditions, parameters, and specifications with which an information system or system component can be described or arranged. The selection of one of the sets of possible combinations of features of a system [NIST]. Alternative configurations are evaluated to determine which configuration is the preferred solution to meet the requirements (Friedenthal, Moore & Steiner, p. 72). |
|
|
Term
|
Definition
| A tilde ~ in front of the type of a non-atomic flow port indicates that the directions of the flow properties in the flow specification are reversed for that flow port (Delligatti, p. 38). |
|
|
Term
|
Definition
| An element of usage that appears on internal block diagrams (Delligatti, p. 45). Lines connecting ports (Friedenthal, Moore & Steiner, p. 34). Define how ports connect to one another (65). |
|
|
Term
|
Definition
| Type checking can help determine whether interfaces are compatible or whether units are consistent among different properties. Example of a design inconsistency is that two modelers inadvertently give two different names to what is intended to be the same component. The model treats these as different components. The likelihood of inconsistencies increased when multiple people are working on the same model (Friedenthal, Moore & Steiner, p. 24). There is a potentially very large problem when considering things from different points of view and this is [lack of] consistency. Consistency is the key to creating a correct model. Without consistency, it is not possible to have or demonstrate any confidence in the system (Holt & Perry, p. 96). |
|
|
Term
|
Definition
| Elements are one or more system element (Holt & Perry, p. 41). [Ken's comment: not very clear what is meant here.] |
|
|
Term
|
Definition
| Encapsulates a reusable constraint expression (equation or inequality) (Delligatti, p. 33). An element of definition that defines a Boolean constraint expression (must evaluate to either true or false). Usually, the constraint expression in a constraint block is an equation, or an inequality; a mathematical relationship used to constrain value properties of blocks. This is to either specify assertions about valid system values in an operational system, or to perform engineering analysis during the design stage of the lifecycle. Variables in a constraint expression are called constraint parameters. Generally they represent quantities, typed most often by value types. Constraint parameters receive their values from the value properties they're bound to--the value properties that are being constrained. A Block Definition Diagram (bdd) by itself can't convey which constraint parameters and value properties are bound to one another--express this on a parametric diagram. Notation for a constraint block on a Block Definition Diagram (bdd) is a rectangle with the stereotype <<constraint>> preceding the name. The {constraint expression} is in curly brackets (57-58). Parameters are defined along with their units in the constraint block (Friedenthal, Moore & Steiner, p. 72). |
|
|
Term
|
Definition
| An equation, inequality or Boolean true-or-false evaluation. It's a mathematical relationship to constrain value properties of blocks (Delligatti, p. 57). |
|
|
Term
|
Definition
| Variable in a constraint expression, generally representing quantities, typed most often by value types. Receive their values from the value properties they're bound to--that are being constrained (Delligatti, p. 57). |
|
|
Term
|
Definition
| A mathematical relationship (equation or inequality) imposed on a set of value properties. <constraint name> : <type> The constraint name is modeler defined. The type must be the name of a constraint block in the model (Delligatti, p. 33). Build a more complex constraint block from a set of simpler constraint blocks, to create a more complex mathematical relationship from simpler equations and inequalities. The more complex constraint block can display its constituent parts as a list of constraint properties in the constraints compartment (58). Constraint property shape--a modeler can indicate whether the node symbol for a constraint property has rounded or square corners (Friedenthal, Moore & Steiner, p. 96). |
|
|
Term
| Constraints Compartment Notation |
|
Definition
| As an alternative to constraints compartment notation, use composite associations to convey that one constraint block is composed of other, simpler ones. Use composite associations to expose the details of the simpler constraint blocks; use the constraints compartment notation to hide those details when they're not the focus of the diagram (Delligatti, p. 59). |
|
|
Term
| Constructive Systems Engineering Cost Model (COSYSMO) |
|
Definition
Used for estimating the cost and effort of performing Systems Engineering (SE) activities. Includes sizing and productivity parameters. Size estimates the magnitude of the effort and productivity factors are applied to arrive at a labor estimate to do the work (Friedenthal, Moore & Steiner, p. 27).
- Number of requirements that are satisfied.
- Number of requirements that are verified.
- Number of use cases that are realized.
- Number of activities that are allocated to blocks.
- Complexity of a use case may be indicated by the number of actors participating in the interaction.
- Amount of re-use and modification of existing models versus creating new models (28).
|
|
|
Term
|
Definition
| The line with the crosshairs symbol (Friedenthal, Moore & Steiner, p. 57). Connects parent to child requirements (59). |
|
|
Term
|
Definition
All the folders along the left side column of the modeling page, containing the models (Delligatti, OCSMP Accelerator, Module-0, Segment-1). |
|
|
Term
|
Definition
AKA Canvas
Region inside the frame where model elements and relationships can be displayed (Delligatti, p. 17). The rest of the area enclosed by the diagram frame, less the header. This is the content area where symbols are shown (Friedenthal, Moore & Steiner, p. 90). Expressed using node symbols such as rectangles, ovals and round-angles connected by line symbols. The diagram symbols can be adorned with text, icons, tool-specific features, such as font and color (87). Contains elements that graphically represent model elements. Includes the diagram elements (symbols) that present the model elements of interest (92). |
|
|
Term
|
Definition
| A specific point of view based on, for example, stakeholder roles, system hierarchy level, lifecycle stage, etc. (Holt & Perry, p. 46). |
|
|
Term
|
Definition
| The ∆ time between arrival of the inputs [and departure of the] outputs approaches zero. Continuous flows build on the concept of streaming input and output parameters, which means that the inputs are accepted and outputs are produced while the action is executing (Friedenthal, Moore & Steiner, p. 68). |
|
|
Term
|
Definition
| Best expressed in a sequence diagram (Friedenthal, Moore & Steiner, p. 61). Used to specify the sequence of actions and is depicted as a dashed line with an arrowhead (63). Control flow style--a modeler can indicate whether the path symbol for a control flow is a dashed or solid arrow (96). |
|
|
Term
|
Definition
| A specific Model-Based Systems Engineering (MBSE) concept with relationships to other ontology elements shown on the MBSE ontology (Holt & Perry, p. 24). |
|
|
Term
|
Definition
| The interfaces or dependencies between model elements (Friedenthal, Moore & Steiner, p. 27). |
|
|
Term
|
Definition
| It is often useful in the early stages of an analysis to identify the critical parameters but defer definition of the equations until the detailed analysis is performed (Friedenthal, Moore & Steiner, p. 72). |
|
|
Term
|
Definition
| An ontology element with more complex relationships to other ontology elements than those of the core elements, and cross-cutting elements may be applied to several basic elements (Holt & Perry, p. 24). |
|
|
Term
|
Definition
| The line with crosshairs symbol denotes containment (Friedenthal, Moore & Steiner, p. 57). |
|
|
Term
|
Definition
| Systems Modeling Language (SysML) supports custom visualizations through the viewpoint mechanism (Friedenthal, Moore & Steiner, p. 99). |
|
|
Term
|
Definition
| Some kinds of model elements (blocks, value types, constraint blocks) represent definitions of types (Delligatti, p. 26). |
|
|
Term
|
Definition
| One element, the client, depends upon another element, the supplier. When the supplier element changes, the client element may also have to change. Create a dependency between two model elements to establish traceability between them. They're part of the structure of the model and not of the system that the model represents, so it's unlikely they'll be needed for Block Definition Diagrams (bdd), but they're used often in package diagrams and requirements diagrams. If depicting on a bdd, notation is a dashed line with an open arrowhead, drawn from client to supplier. The [client] block depends on the interface. If the interface changes, the block may need to change, too (Delligatti, pp. 52-53). |
|
|
Term
|
Definition
| A predefined field of the optional diagram description note. Free text description of the diagram's content and purpose (Friedenthal, Moore & Steiner, p. 92). |
|
|
Term
|
Definition
| The extent to which the system design satisfies the system requirements. The components' interfaces, behavior and properties must be sufficiently specified to assess whether the system design satisfies its requirements. The number of use-case scenarios that have been completed, and the percent of logical components that have been allocated to physical components, are metrics for assessing progress. The extent to which components have been verified and integrated into the system, and how well the system has been verified to satisfy its requirements are metrics for assessing progress. Test cases and verification status can be captured in the model and used as a basis for this assessment (Friedenthal, Moore & Steiner, p. 27). |
|
|
Term
|
Definition
| Level of cohesion and coupling of the design (Friedenthal, Moore & Steiner, p. 27). |
|
|
Term
|
Definition
| Assessing requirements satisfaction, requirements verification, and technical performance measurement. A quality model provides granularity by identifying model elements that satisfy specific requirements along with the supporting rationale. Requirements traceability can be established from mission requirements down to component requirements. Critical properties such as performance, response time, throughput, accuracy, physical properties, and cost can be monitored throughout the design process to assess technical risk and determine the impact of changes to requirements and design. The extent to which the system design satisfies the system requirements is a measure of design quality. The components' interfaces, behavior and properties must be sufficiently specified to assess whether the system design satisfies its requirements (Friedenthal, Moore & Steiner, pp. 26-27). |
|
|
Term
|
Definition
Provides views of the model (Delligatti, OCSMP Accelerator
Module-0, Segment-2). A view of a model for a particular purpose. Systems Modeling Language (SysML) includes 9 standard diagram kinds. Provides a mechanism to present a focused view of a model for a specific purpose (Friedenthal, Moore & Steiner, p. 87). A view of the model elements is presented in a diagram, where the symbols on the diagram correspond to the model elements. The diagram is a view of the model that is intended to address a particular purpose, and the modeler can choose what to present and what to hide (elide) on the diagram (88). The mechanism that we use to visualize the view, and may be graphical, text, tabular, etc. (Holt & Perry, p. 20). |
|
|
Term
|
Definition
| (Friedenthal, Moore & Steiner, p. 42). |
|
|
Term
|
Definition
AKA Canvas
Region inside the frame where model elements and relationships can be displayed (Delligatti, p. 17). Expressed using node symbols such as rectangles, ovals and round-angles connected by line symbols. The diagram symbols can be adorned with text, icons, tool-specific features, such as font and color (Friedenthal, Moore & Steiner, p. 87). The rest of the area enclosed by the diagram frame, less the header. This is the content area where symbols are shown (90). Contains elements that graphically represent model elements. Includes the diagram elements (symbols) that present the model elements of interest (92). |
|
|
Term
|
Definition
An optional note attached either inside or outside of the diagram frame, with predefined fields:
- Version: Version of the diagram.
- Completion Status: The completeness of the diagram relative to its intended completeness; "in process," "draft," "complete." May include a specific description of the information that is still missing from the diagram.
- Description: Free text description of the diagram's content or purpose.
- Reference: References to other information, hyperlinks to related diagrams to aid in navigation (Friedenthal, Moore & Steiner, p. 92).
|
|
|
Term
|
Definition
| Used to create or modify a diagram (Friedenthal, Moore & Steiner, p. 42). The modeler can drag a diagram element from the pallet onto the diagram in the diagram area and name the new element (43). Select the symbol on the diagram and find its location in the browser (44). A Systems Modeling Language (SysML) diagram contains diagram elements or symbols that correspond to model elements contained in the model (87). There are 2 kinds of diagram elements: nodes and paths (93). |
|
|
Term
|
Definition
| The border (Delligatti, OCSMP Accelerator, Module-1, Part-1, Seg.-1). Encloses the diagram header and diagram content (Friedenthal, Moore & Steiner, p. 54). Corresponds to a particular model element and sets the context for the diagram content (87). Symbols on the diagram frame connect to other elements shown within the diagram frame (90). |
|
|
Term
|
Definition
| Upper left corner: diagramKind [modelElementType] model element name [ diagram name ] (Delligatti, OCSMP Accelerator, Module-1, Part-1, Seg.-1). Information is visible and includes diagram kind, diagram name, and other information about the diagram frame (Friedenthal, Moore & Steiner, p. 43). Describes the kind of diagram, the diagram name, and additional context for the diagram information (54). Contains standard information in the top left corner. A rectangle with its lower right corner cut off (90). |
|
|
Term
|
Definition
An abbreviation in the first position of a model header, indicating the kind of diagram (Friedenthal, Moore & Steiner, p. 90). The diagram kind may take 9 values, depending on the kind of diagram:
- act: Activity Diagram.
- bdd: Block Definition Diagram.
- ibd: Internal Block Diagram.
- pkg: Package Diagram.
- par: Parametric Diagram.
- req: Requirement Diagram.
- sd: Sequence Diagram.
- stm: State Machine Diagram.
- uc: Use Case Diagram (Delligatti, p. 19; Friedenthal, Moore & Steiner, p. 32).
|
|
|
Term
|
Definition
| Conveys which aspect of the model is in focus on that diagram (Delligatti, p. 18). The name of the diagram, often used to indicate the diagram purpose (Friedenthal, Moore & Steiner, p. 91). |
|
|
Term
|
Definition
| A keyword indicating a specialized use of a diagram, centered and in guillemets <<diagram usage>> (Friedenthal, Moore & Steiner, p. 91). |
|
|
Term
|
Definition
| Creates diagrams--shapes on a page; there is no model underlying those diagrams that ensures automated consistency between them (Delligatti, p. 8). |
|
|
Term
|
Definition
| A special type of System of Systems (SoS) that has designated management and resources, and a consensus of purpose. Each constituent system retains its own operation but not management (Holt & Perry, p. 42). |
|
|
Term
|
Definition
| A system where people were hurt or the environment was damaged as a result of system failure (Holt & Perry, p. 8). |
|
|
Term
|
Definition
| Only by looking at something at high, low and intermediate levels of abstraction is it possible to gain a full understanding of a system. Any system must be able to be represented at different levels of abstraction (Holt & Perry, p. 95). |
|
|
Term
|
Definition
| A particular application area involving particular kinds of systems and particular facets of a system (Friedenthal, Moore & Steiner, p. 21). Does the model accurately reflect the domain of interest? Dependent on the quality of the source information, the validity of the assumptions regarding the applicability of the source information, and the extent to which the source information and assumptions are properly captured in the model. The quality of the source information and the validity of the assumptions are primarily assessed through subject matter [experts] review. Assessments of the extent to which the source information and assumptions are properly captured in the model is determined by further expert review (26). |
|
|
Term
|
Definition
AKA Path
A diagram element that generally appears as a line that may have additional adornments such as arrowheads and text strings (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| [Modelers can] group model elements of any kind. The members of an element group can be ordered. Model elements can appear in multiple element groups. Group membership is not transitive: If model element 1 is a member of element group A, and element group A is a member of element group B, this does not imply that model element 1 is a member of element group B. An element group is shown using a note symbol with the keyword <<elementGroup>> at the top of the symbol. Inclusion of an element in the group is indicated by a dashed line from the group to the element. The criterion for the inclusion of an element in the group is shown in the body of the comment symbol (Friedenthal, Moore & Steiner, p. 98). |
|
|
Term
|
Definition
| Appear on Block Definition Diagrams (bdd). Structural relationships (associations, generalizations, dependencies) are important (Delligatti, p. 23). Elements of definition have a name only (26). Certain kinds of model elements, such as blocks, can be defined one time, but their usage in different contexts can be uniquely identified. A block represents the generic definition of the part, and the part represents a usage of a block in a particular context. A block is the type of the part, and a part is typed by a block (Friedenthal, Moore & Steiner, p. 70). |
|
|
Term
|
Definition
| An instantiation with a name and a type, separated by a colon (Delligatti, p. 26). Certain kinds of model elements, such as blocks, can be defined one time, but their usage in different contexts can be uniquely identified. A block represents the generic definition of the part, and the part represents a usage of a block in a particular context. A block is the type of a part, and a part is typed by a block (Friedenthal, Moore & Steiner, p. 70). |
|
|
Term
|
Definition
| Hide inconsequential information and focus attention on particular notations (Delligatti, p. 17). No diagram should attempt to convey every detail; the diagram would be unreadable. Decide what you want the focus to be and elide all model information that is not within that focus (20). Hide nonessential information and display only the information relevant to the diagram purpose (Friedenthal, Moore & Steiner, p. 25). Show and hide selected details of the model on any particular diagram. The modeler only shows what is considered important to support the purpose of the diagram (44). It's common modeling practice to present only the information relevant to the purpose of the diagram even though additional information may be included in the model (66). The diagram is a view of the model that is intended to address a particular purpose, and the modeler can choose what to present and what to hide (elide) on the diagram (88). An ellipses in the parts compartment of a block diagram indicates that some entries are hidden (89). Useful for reducing clutter and focusing on the diagram's purpose, to know that there is information about a model element that could be shown but is hidden. Show an ellipsis at the bottom of a compartment on a symbol to indicate that not all of the potentially visible compartment elements are shown (95). It is very important to limit the number of general properties that are identified to only those that are relevant, as it is very easy to get carried away and over-define the amount of detail for a block (Holt & Perry, p. 101). The property and operation compartments are turned on or off for a block, allowing the block to be shown in different levels of detail on different diagrams. Only use as much detail as is necessary, rather than as much as is possible (103). |
|
|
Term
|
Definition
| ... in the bottom of the parts compartment of a block diagram indicates that some entries are hidden (Friedenthal, Moore & Steiner, p. 89). Useful for reducing clutter and focusing on the diagram's purpose, to know that there is information about a model element that could be shown but is hidden. Show an ellipsis at the bottom of a compartment on a symbol to indicate that not all of the potentially visible compartment elements are shown (95). |
|
|
Term
|
Definition
| Interacts with the System of Interest (SoI) yet sits outside the SoI's boundary (Holt & Perry, p. 42). |
|
|
Term
|
Definition
| Object-oriented concept which reflects cohesion, or the extend to which a component can perform its functions without requiring access to external data (Friedenthal, Moore & Steiner, p. 27). |
|
|
Term
|
Definition
AKA Enumeration
Defines a set of literals (legal values). If a parameter is typed by an enumeration, then the value it holds at any moment must be one of the literals in the enumeration (Delligatti, p. 56). |
|
|
Term
|
Definition
| Context determining the setting and circumstances of all influences upon a system. Includes developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological, and social influences (Holt & Perry, p. 48). |
|
|
Term
|
Definition
| Related to a base use case by an extension relationship (dashed arrow, pointing to base use case) (Friedenthal, Moore & Steiner, p. 60). |
|
|
Term
| Extensible Markup Language (XML) Metadata Interchange (XMI) |
|
Definition
| A System Modeling Language (SysML) model that is captured in a model repository can be imported and exported from a SysML compliant tool in a standard format (Friedenthal, Moore & Steiner, p. 80). |
|
|
Term
|
Definition
| Relates the extending use case to the base use case. Dashed arrow pointing at the base use case (Friedenthal, Moore & Steiner, p. 60). |
|
|
Term
|
Definition
| Modeling with standard ports and interfaces is a way to decouple clients from providers, enabling design to abstraction rather than specific implementation. This lets new providers of interfaces be added at any time without impacting existing clients of those interfaces (Delligatti, p. 37). The principle of designing to an abstraction, and its consequent extensibility, applies to the practice of creating a value type hierarchy (57). |
|
|
Term
|
Definition
| A trigger within the base use case that requires an extending use case (Friedenthal, Moore & Steiner, p. 60). |
|
|
Term
|
Definition
| A system where the project never reached delivery and where time and money were wasted because time or cost overran (Holt & Perry, p. 8). |
|
|
Term
|
Definition
| You cannot conclude that a feature doesn't exist from its absence on a diagram; it may be shown on another diagram of the model or on no diagram at all (Delligatti, p. 21). Two varieties: structural features (properties) and behavioral features (27). Include the block's value properties, behavior in terms of activities allocated to the block, or operations of the block, and its interfaces as defined by its ports (Friedenthal, Moore & Steiner, p. 59). |
|
|
Term
|
Definition
| Direction of an association (Holt & Perry, p. 100). |
|
|
Term
|
Definition
| For synchronous message (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| Models use types of matter, energy or data that can flow in or out of a block at an interaction point on its boundary. Display as a small square straddling the border of a block. The small square contains a symbol inside indicating if it is an atomic (unidirectional arrow) or nonatomic (bidirectional chevrons <>) flow port. Modeler-defined name and type, displayed as a string floating near the flow port, separated by a colon (Delligatti, p. 37). |
|
|
Term
|
Definition
| Represents a specific item that can flow in or out of a block via a flow port. Display it as <direction> <name> : <type> The direction must be in, out or inout. The name is modeler defined. The type must be the name of a value type, block or signal in the model (Delligatti, p. 38). |
|
|
Term
|
Definition
| An element of definition that defines a set of flow properties that can flow in or out of a nonatomic flow port. On a Block Definition Diagram (bdd) start with the stereotype <<flowSpecification>> preceding the name. Display its flow properties in a compartment named flowProperties (Delligatti, p. 38). |
|
|
Term
|
Definition
| A scenario that is mathematically provable (Holt & Perry, p. 46). |
|
|
Term
|
Definition
| The outer rectangle (Delligatti, p. 17). |
|
|
Term
|
Definition
| The package is a namespace for the contained model elements, giving each model element a unique name within the model. The qualified name includes the path name relative to the model in which it is contained using a double colon (::) as a separator (Friedenthal, Moore & Steiner, p. 56). |
|
|
Term
| Fundamental Precept of MBSE |
|
Definition
| A diagram of the model is never the model itself, it’s merely one view of the model (Delligatti, OCSMP Accelerator, Module-0, Segment-1). |
|
|
Term
|
Definition
| A mechanism for assessing the success or failure of the execution of a stage (Holt & Perry, p. 59). |
|
|
Term
|
Definition
| Conveys inheritance between two elements: A more generalized element, called the supertype, and a more specialized element, the subtype. Generalizations create classification trees (type hierarchies). Notation is a solid line with a hollow triangular arrowhead on the end of the supertype, read as "is a type of" going from the subtype to the supertype. Overlapping arrowheads conveys a special grouping of subtypes called a generalization set. Generalizations are transitive. Type hierarchies in a model can be arbitrarily deep. A subtype inherits all the features of its supertype; the structural features (properties) and the behavioral features (operations and receptions). A subtype may have other features that its supertype doesn't have and would then be called a specialization of its supertype. Create generalizations to define abstractions. A supertype is an abstraction of its subtypes; it factors in those features that are common among the subtypes. Abstractions let you define a common feature in one place in the model--the supertype--and that common feature propagates down the type hierarchy to all the subtypes. Later if you need to change that feature, make the change in the supertype and tall the subtypes update (Delligatti, pp. 49-51). Shown by a line with an unfilled triangular arrowhead at one end, which for a generalization reads "is a type of" (Holt & Perry, p. 105). |
|
|
Term
|
Definition
| Special grouping of subtypes conveyed by overlapping arrowheads (Delligatti, p. 49). |
|
|
Term
|
Definition
| A special type of need, the context of which will typically represent one or more organizational unit (as an organizational context). Each goal will be met by one or more capabilities (Holt & Perry, p. 46). |
|
|
Term
| Goal of Model-Based Systems Engineering (MBSE) |
|
Definition
| To produce a model that abstracts a system (Holt & Perry, p. 21). |
|
|
Term
|
Definition
| Meets its intended use (Friedenthal, Moore & Steiner, p. 29). |
|
|
Term
|
Definition
| Set of rules that determines whether a model is well-formed or ill-formed (Delligatti, p. 5). |
|
|
Term
|
Definition
| Vocabulary consists of graphical notations that have specific meanings (Delligatti, p. 12). |
|
|
Term
|
Definition
| << >> (Friedenthal, Moore & Steiner, p. 92). Double chevrons (Holt & Perry, p. 131). Indicate stereotypes (OMG SysML Spec., v1.6) and keywords (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| Upper-left corner of diagram, with its lower-right corner cut off. Contains diagram kind, model element type, model element name and diagram name (Delligatti, p. 19). |
|
|
Term
|
Definition
| Inside a block, designates the top-level model (Friedenthal, Moore & Steiner, p. 56). |
|
|
Term
| Hollow Arrowhead on End of Supertype |
|
Definition
| "Is a type of" going from the subtype to the supertype (Delligatti, p. 49). |
|
|
Term
|
Definition
| Internal Block Diagram specifies the internal structure of a single block. Shows the connections between the internal parts of a block and the interfaces between them (Delligatti, p. 15). Allowable model element type: block (20). Presents interconnections and interfaces between the parts of a block (Friedenthal, Moore & Steiner, p. 32). Small squares on the frame are ports and represent interfaces. Lines connecting ports are called connectors (34). A context diagram that shows how the ports of the block are connected (65). It represents the internal structure of a higher-level block. Enables the modeler to specify both the external and internal interfaces of a block and shows how its parts are connected (66). A rake symbol on an ibd represents that a port can refer to another ibd (95). Describes the internal structure of a system in terms of its parts, ports and connectors (Holt & Perry, p. 97). |
|
|
Term
|
Definition
| Represents a specific domain concept, such as a document, type of hardware component. A stereotype can specify an icon to be used as the symbol for the model element with the stereotype applied. If a model element symbolized by an icon has properties, these can be displayed in a text string floating near the object. Icons may be displayed inside a node symbol or as adornments on line shapes (Friedenthal, Moore & Steiner, p. 94). |
|
|
Term
|
Definition
| One of the two value properties in a complex structured value type, of type Real (Delligatti, p. 56). |
|
|
Term
|
Definition
| By using dependency relationships, perform downstream impact analysis for design changes. When changing one element, query to generate a list of the other elements that may be affected by the change (Delligatti, p. 53). |
|
|
Term
|
Definition
| Generalization relationships convey inheritance between two elements; a more generalized element called the supertype, and a more specialized element, the subtype. Generalizations are transitive and convey that a subtype inherits all the features of its supertype; the structural features (properties) and the behavioral features (operations and receptions). Each common feature of the supertype propagates down the type hierarchy to all the subtypes. If you later need to change that common feature, go back to that one place in the model to make the change, and all the subtypes get updated (Delligatti, pp. 49-51). |
|
|
Term
|
Definition
| Connected with base use case via inclusion relationship (Friedenthal, Moore & Steiner, p. 60). |
|
|
Term
|
Definition
| Child blocks inherit their properties and operations from their parent blocks. A child block will inherit any properties and operations that its parent block has. Inheritance only runs from parent blocks to child blocks. If, when modeling a type hierarchy, it was found that a property was being added into all types, then this is a sign that the property should be moved up the hierarchy so that it is defined in one place and inherited by all the descendant blocks (Holt & Perry, pp. 105-106). |
|
|
Term
|
Definition
| When an activity is initiated, it starts execution at the initial node (filled-in circle) (Friedenthal, Moore & Steiner, p. 63). |
|
|
Term
|
Definition
| <> Bidirectional non-atomic flow port (Delligatti, p. 38). |
|
|
Term
|
Definition
| The behavior of instances of blocks (Holt & Perry, p. 107). |
|
|
Term
|
Definition
| A primitive value type (Delligatti, p. 55). |
|
|
Term
|
Definition
| Does the model integrate with other models? (Friedenthal, Moore & Steiner, p. 26). |
|
|
Term
|
Definition
| What the sequence diagram specifies (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| Reference a more detailed interaction as indicated by "ref" (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| A shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics [SEBOK]. Common boundary between independent systems or modules where interactions take place. Wherever two or more logical, physical, or both system elements or software system elements meet and act on or communicate with each other [NIST]. The ports on blocks and pins on actions can have definitions that specify detailed interface information that can be reused (Friedenthal, Moore & Steiner, p. 72). |
|
|
Term
| Internal Block Diagram (ibd) |
|
Definition
| Specifies the internal structure of a single block. Shows the connections between the internal parts of a block and the interfaces between them (Delligatti, p. 15). Allowable model element type: block (20). Presents interconnections and interfaces between the parts of a block (Friedenthal, Moore & Steiner, p. 32). Small squares on the frame are ports and represent interfaces. Lines connecting ports are called connectors (34). A context diagram that shows how the parts of the block are connected (65). It represents the internal structure of a higher-level block. Enables the modeler to specify both the external and internal interfaces of a block and shows how its parts are connected (66). A rake symbol on an ibd represents a part that can refer to another ibd (95). Describes the internal structure of a system in terms of its parts, ports and connectors (Holt & Perry, p. 97). |
|
|
Term
|
Definition
| Black-filled arrowheads on connectors represent the items flowing between parts, which may include mass, energy and/or information (Friedenthal, Moore & Steiner, p. 66). Can have both a definition and a usage (71). |
|
|
Term
|
Definition
| In guillemets before the name of some model elements identifies the kind of model element to which it refers and is typically used to remove ambiguity when a particular symbol such as a rectangle or dashed line with an arrowhead can represent more than one type of model element. Eliminates ambiguity (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
AKA Understandability
A lack of understanding may occur at any stage of the system lifecycle. Uncorrected mistakes will lead to larger problems further down the development lifecycle. Mistakes made during early stages of the lifecycle cost many times more to fix during later stages of the lifecycle. A lack of understanding may occur during the conception stage of a project, during a requirement-related process. If the requirements are not stated in a concise and unambiguous fashion, then this lack of understanding will cascade throughout the whole project. A lack of understanding may occur during the development stage of a project, during an analysis-related process. There may be a lack of domain knowledge during analysis that may lead someone to state false assumptions, or to actually get something completely wrong due to insufficient knowledge. A lack of understanding may occur during the operational stage of a project, during an operation-related process. Incorrect usage of a system may lead to a system failure or disaster (Holt & Perry, p. 89). |
|
|
Term
|
Definition
| A medium for communicating ideas from one person to another. It has a grammar and a vocabulary (Delligatti, pp. 11-12). |
|
|
Term
|
Definition
| A set of one or more stages that can be used to describe the evolution of system, project, etc., over time (Holt & Perry, p. 59). Evolution of a system, product, service, project or other human-made entity from conception through retirement [ISO-15288] (56). |
|
|
Term
|
Definition
| The point during a lifecycle model at which more than one stage interact with each other (Holt & Perry, p. 59). |
|
|
Term
| Lifecycle Interface Point |
|
Definition
| The point in a lifecycle where one or more lifecycle interactions will occur (Holt & Perry, p. 59). |
|
|
Term
|
Definition
| A partitioning of the life of a product or project into phases (Holt & Perry, p. 56). The execution of a set of one or more stages that shows the behavior of a lifecycle (59). |
|
|
Term
|
Definition
| Vertical dashed line drawn through a sequence diagram to indicate actor or system performing an action (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| A modeler can specify whether they wish to see line jogs, semicircular hoops to indicate when two path symbols are crossing each other [without connection] on a diagram (Friedenthal, Moore & Steiner, p. 96). |
|
|
Term
|
Definition
| Legal value in enumerated value types (Delligatti, p. 56). |
|
|
Term
| Maintain Requirements Traceability |
|
Definition
| Step-6 of simple Model-Based Systems Engineering (MBSE) method. To ensure the proposed solution satisfies the system requirements and associated stakeholder needs (use cases, measures of effectiveness) on a requirements diagram. Show how the system design satisfies the system requirements diagram or table. Identify test cases needed to verify the system requirements on a requirements diagram or table and capture the verification results (Friedenthal, Moore & Steiner, p. 49). |
|
|
Term
|
Definition
| Allow reasoning about the system to be performed. Equations to formal specifications, using specialized formal methods, that may be used as part of a formal analysis or proof (Holt & Perry, p. 94). |
|
|
Term
|
Definition
| Identified by the diagram kind matrix. Top row and first column of the matrix represent model elements and other cells describe a relationship between the row and column elements. A satisfy dependency matrix lists requirements, the first column lists model elements, and the other cells indicate whether relationships exist between them (Friedenthal, Moore & Steiner, p. 97). |
|
|
Term
| Model-Based Systems Engineering (MBSE) Approach |
|
Definition
| The key elements that make up the approach are the process set, the framework (together comprising the ontology) and the set viewpoints (Holt & Perry, p. 29). |
|
|
Term
| Model-Based Systems Engineering (MBSE) Framework |
|
Definition
| The ontology that provides the domain-specific language, and a set of one or more viewpoints, each of which may be thought of as providing a template for a number of views (Holt & Perry, p. 21). Describes a specific use of the ontology (22). |
|
|
Term
| Model-Based Systems Engineering (MBSE) Fundamentals |
|
Definition
3 key concepts that must be understood for successful MBSE:
- The goal.
- The approach.
- Visualization (Holt & Perry, p. 29).
|
|
|
Term
| Model-Based Systems Engineering (MBSE) Mantra |
|
Definition
3 considerations / aspects for implementing MBSE:
- People (trained).
- Process.
- Tools (enablers) (Holt & Perry, pp. 11, 29).
|
|
|
Term
| Model-Based Systems Engineering (MBSE) Method |
|
Definition
A method that implements all or part of the Systems Engineering (SE) process and produces a system model as primary artifact (Friedenthal, Moore & Steiner, p. 21). Determines the modeling activities performed, the ordering of the activities, and the kinds of modeling artifacts produced (47).
- Organize the model.
- Analyze stakeholder needs.
- Specify system requirements.
- Synthesize alternative system solutions.
- Perform analysis.
- Maintain requirements traceability (47-49).
|
|
|
Term
| Model-Based Systems Engineering (MBSE) Ontology |
|
Definition
Covers 7 main themes:
- System-related concepts (systems, systems of systems, constituent systems).
- Need-related concepts (system needs, requirements, capabilities, goals).
- Architecture-related concepts (architecture using an architectural framework).
- Lifecycle-related concepts (lifecycles, lifecycle models, interactions between lifecycles).
- Process-related concepts (structure, execution and responsibility of processes).
- Competence-related concepts (ability of people associated with stakeholder needs).
- Project-related concepts (project and program management) (Holt & Perry, p. 74).
|
|
|
Term
|
Definition
AKA Ontology
AKA Conceptual Model
Domain-specific vocabulary reflecting core concepts (Friedenthal, Moore & Steiner, p. 25). Notation has predefined syntax, semantics and rules, underpinned by its own model that defines these (Holt & Perry, p. 10). A model of a model (29). |
|
|
Term
|
Definition
| A set of related activities, techniques, conventions, representations and artifacts that implement one or more processes and is generally supported by a set of tools (Friedenthal, Moore & Steiner, p. 21). |
|
|
Term
|
Definition
A set of elements and relationships between elements (Delligatti, OCSMP Accelerator, Module-0, Segment-2). A representation of one or more concepts that may be realized in the physical world (Friedenthal, Moore & Steiner, p. 21). An abstraction that does not contain all the detail of the modeled entities within the domain of interest, but only the details needed to address the intended use. Used for specifying and visualizing. Purpose for modeling a system:
- Characterize and assess an existing system, specify and design a new or modified system.
- Represent a system concept.
- Specify and validate system requirements.
- Synthesize system designs.
- Specify component requirements.
- Maintain requirements traceability.
- Evaluate the system.
- Trade-offs.
- Performance requirements and quality attributes.
- Verify that the system satisfies its requirements.
- Assess impact of requirements changes or design changes.
- Estimate system cost (development lifecycle cost).
- Train users how to operate or maintain a system.
- Support system maintenance and diagnostics (22).
One of the main goals for any MBSE endeavor is to produce a model that abstracts the system (Holt & Perry, p. 18). A set of views that are visualized using any number of diagrams from any number of notations (21). A simplification of reality (94). |
|
|
Term
|
Definition
Dependent upon:
- The quality of the source information used to generate the model.
- The validity of the assumptions regarding the applicability of the source information.
- The extent to which the source information and assumptions are properly captured in the model.
Validation is performed by domain expert review (Friedenthal, Moore & Steiner, p. 22). |
|
|
Term
|
Definition
| Measurement data collection, analysis, and reporting can be used as a management technique throughout the development process to asses design quality and progress. Used to assess technical, cost, schedule status, and risk, and to support ongoing project planning and control (Friedenthal, Moore & Steiner, p. 26). Include quality measures, progress measures, completion effort, stability of the number of requirements, design changes over time, defect rates, improvements resulting from MBSE over time (28). |
|
|
Term
| Model-Based Systems Engineering (MBSE) |
|
Definition
| Formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases (Delligatti, p. 1). Can help to manage complexity while improving design quality and cycle time, enhancing communication among a diverse development team, and facilitating knowledge capture and design evolution (Friedenthal, Moore & Steiner, p. xvii). The primary artifact of MBSE is a coherent model of the system being developed. Enhances specification and design quality, reuse of system specifications and design artifacts, and communications among the development team (15). Language, method and tool each introduce their own concepts that must be learned (50). Model-based approaches will enable understanding of complex system behavior much earlier in the product lifecycle. Models not only capture design but embody design rationale by linking design to top-level customer and programmatic concerns. An approach for realizing successful systems that is driven by a model that comprises a coherent and consistent set of views that reflect multiple viewpoints of the system. Automatic generation and maintenance of system documents, simpler document maintenance, more consistent document content, and drastically reduced documentation effort and time. Complexity control and management: Models may be measured and therefore controlled. Traceability between all system artifacts, across all lifecycle stages. Without a coherent model, knowledge of the system is spread across multiple sources (spreadsheets, documents) (Holt & Perry, pp. 7-9). |
|
|
Term
|
Definition
| Which parts of the system need to be modeled? This can be determined by the extent of the system requirements that the model must address (Friedenthal, Moore & Steiner, p. 23). |
|
|
Term
|
Definition
| Hierarchical view of model elements contained in a model. Model elements grouped into a package hierarchy. Each package appears as a folder that can be expanded to view its contents (Friedenthal, Moore & Steiner, p. 43). |
|
|
Term
| Model Builder-Fundamental |
|
Definition
| Second level of Object Management Group (OMG) Certified Systems Modeling Professional (OCSMP) certification, expected to be able to build models that use the basic feature set (Friedenthal, Moore & Steiner, p. 53). |
|
|
Term
| Model Builder-Intermediate |
|
Definition
| Third level of Object Management Group (OMG) Certified Systems Modeling Professional (OCSMP), expected to be able to build models that use the full feature set (Friedenthal, Moore & Steiner, p. 53). |
|
|
Term
|
Definition
| Routine that provides a report of any constraint violations (Friedenthal, Moore & Steiner, p. 19). |
|
|
Term
|
Definition
| Does the model's breadth, depth and fidelity match its defined scope? Are all design elements traced to a requirement? (Friedenthal, Moore & Steiner, p. 24). |
|
|
Term
|
Definition
| In order to be considered a model, all of the views must be consistent (Holt & Perry, p. 20). Consistency of the viewpoints is assured by using elements from the ontology (21). Consistency of the views is assured by using a set of viewpoints as templates (22). |
|
|
Term
|
Definition
| Determined by the level of the system design hierarchy that the model must encompass. This may change with the system lifecycle, with perhaps more detail needed for development than for initial design iteration (Friedenthal, Moore & Steiner, p. 25). |
|
|
Term
|
Definition
| Each design decision is captured as a model element or a relationship between model elements (Delligatti, p. 3). Model elements represent requirements, design, test cases, design rationale, and their interrelationships (Friedenthal, Moore & Steiner, p. 17). Appears in only one place in the browser, but may appear on zero, one, or more diagrams. Select a model element in the browser and find its location on each diagram on which it appears. If the modeler wishes to delete a model element from the diagram, the tool may prompt the modeler whether to delete the model element from the diagram only or to delete the model element from the model as well by removing it from the browser. A modeler can delete a model element directly from the browser. Select a model element on the diagram and query the modeling tool to show all of the directly related model elements that can appear on that particular kind of diagram (43-44). A model element in one package can have relationships to model elements in other packages (56). May appear on any number of diagrams. Any changes to a model element will be reflected in all the diagrams in which it appears (87). A view of the model elements is presented in a diagram, where the symbols on the diagram correspond to the model elements. The same model element kind may map to more than one symbol. Icons can be used to visualize model elements (88). |
|
|
Term
|
Definition
The kind of model element to which the element frame corresponds.
- For an activity diagram, the model element kind is activity.
- For a block definition diagram, the model element kind could be:
- Block.
- Constraint block.
- Package.
- Model.
- Model library.
- For an internal block diagram, the model element kind is block.
- For a package diagram, the model element kind can be:
- Package.
- Model.
- Model library.
- Profile.
- View.
- For a parametric diagram, the model element kind can be:
- Activity.
- Block.
- Constraint block.
- For a requirement diagram, the model element kind can be:
- Package.
- Model.
- Model library.
- Requirement.
- For a sequence diagram, the model element kind is state machine.
- For a use case diagram, the model element kind can be:
- Package.
- Model.
- Model library (Friedenthal, Moore & Steiner, pp. 91-92).
|
|
|
Term
|
Definition
| The name of the model element to which the diagram frame corresponds (Friedenthal, Moore & Steiner, p. 91). |
|
|
Term
|
Definition
| The required level of detail. Additional model details may be required to execute behavior in order to specify software requirements fully. A low-fidelity model for modeling interfaces may only represent the data definitions and source and destination of the flows, whereas a higher-fidelity model may represent the message structure, communication protocol, and detailed communication path. A low-fideltity model for modeling interface may only represent the data definitions and source and destination of the flows, whereas a higher-fideltity model may represent the message structure, communication protocol, and detailed communication path. There may be a low-fidelity model to analyze system performance versus a higher-fidelity model that includes more detailed timing information, system performance characteristics and constraints (Friedenthal, Moore & Steiner, p. 24). |
|
|
Term
|
Definition
| Facilitates understandability, access control, change management and re-use of the model (Friedenthal, Moore & Steiner, p. 55). |
|
|
Term
|
Definition
| Purpose must be clearly stated for both the near-term and long-term use of the model. Identify representative stakeholders from different disciplines involved in the development process and their intended uses of the model throughout the system lifecycle (Friedenthal, Moore & Steiner, p. 23). |
|
|
Term
|
Definition
| To assess how well a model meets its intended use. One must distinguish between a good model and a good design. A good model is judged on how well it meets its intended use. A good design is based on how well the design satisfies its requirements and the extent to which it incorporates quality design principles (Friedenthal, Moore & Steiner, p. 23). What is the quality of the design? Assessing requirements satisfaction, requirements verification, and technical performance measurement. A quality model provides granularity by identifying model elements that satisfy specific requirements along with the supporting rationale. The requirements traceability can be established from mission requirements down to component requirements. Critical properties such as performance, response time, throughput, accuracy, physical properties, cost, can be monitored throughout the design process to assess technical risk and determine the impact of changes to requirements and design (27). |
|
|
Term
|
Definition
| Stores individual model elements and their relationships. Modeler uses the symbols on the diagrams to enter the model information into the repository and to view model information from the repository (Friedenthal, Moore & Steiner, p. 19). |
|
|
Term
|
Definition
| A model's breadth, depth and fidelity, balanced with the available schedule, budget, skill level, and other resources (Friedenthal, Moore & Steiner, p. 23). |
|
|
Term
|
Definition
| First level of Object Management Group (OMG) Certified Systems Modeling Professional (OCSMP), expected to be able to interpret SysML diagrams that use the basic feature set (Friedenthal, Moore & Steiner, p. 53). |
|
|
Term
|
Definition
| Determining the extent to which the model accurately represents the domain of interest (the system and its environment) requires review of the input data and assumptions by domain experts, review of the model by domain experts, and review of analysis results by domain experts (Friedenthal, Moore & Steiner, p. 22). |
|
|
Term
|
Definition
| There is a potentially very large problem when considering things from different points of view and this is consistency (Holt & Perry, p. 22). Modeling allows identification of complexity, aids understanding and improves communication (93). By the very nature of modeling, we are simplifying reality and there is a very real danger that we may oversimplify to such a degree that the model loses all connection to reality and therefore all relevant meaning (95). It must be able to have a strong connection to reality and be meaningful to observers who, in many cases, should require no specific knowledge, other than an explanation, to understand the meaning of any model (96). |
|
|
Term
|
Definition
| Semiformal language that defines the kinds of elements you're allowed to put into your model, the allowable relationships between them and the set of notations you can use to display the elements and relationships on diagrams (Delligatti, p. 5). Imposes rules that constrain which relationships are valid. The model should not allow a requirement to contain a system component or an activity to produce inputs instead of outputs (Friedenthal, Moore & Steiner, p. 19). A semantic foundation that defines the kind of model elements and their relationships that can appear in the system model (21). Requirements for any modeling language: The choice of model, the level of abstraction, connection to reality, independent views of the same system (Holt & Perry, p. 94). |
|
|
Term
|
Definition
| Roadmap; a documented set of design tasks that a modeling team performs to create a system model (Delligatti, p. 7). |
|
|
Term
|
Definition
| Enables modelers to create, modify and delete individual model elements and their relationships. Enforce constraints at the time the model is constructed (Friedenthal, Moore & Steiner, p. 19). |
|
|
Term
|
Definition
Symbol 0..* represents an undetermined maximum number. The multiplicity symbol can also express a positive integer, or a range (Friedenthal, Moore & Steiner, p. 59). When the multiplicity is one on one side of an association, and 1..* on the other side, it does not necessarily indicate that there is only one on the side with a one, but rather that each in the system does the indicated association with one or more on the other side (Holt & Perry, p. 100).
- 0..1 indicates an optional value.
- * indicates any number, including 0, and is the same as 0..*
- 1 indicates each, or exactly one.
- 1..* indicates one or more (101).
|
|
|
Term
|
Definition
N-squared chart, captures interface information (Friedenthal, Moore & Steiner, p. 96). NxN interaction matrix to identify interactions or interfaces between major factors from a systems perspective (NASA/SP-2016-6105-SUPPL, p. 114). A functional analysis or architecting technique that can:
- Minimize connectivity (the extent and complexity of deliberate interaction between functional or physical entities within a system architecture). Minimizing connectivity has a near quadratic effect on cost and integration complexity.
- Maximize cohesion (functions with similar characteristics can often be fulfilled by common elements of a system solution using similar technology). Maximizing cohesion reduces development, production and support costs, minimizes solution footprint and minimizes effect of solution technologies on other lines of development.
- Minimize coupling (the extent and complexity of the intrinsic relationships between physical entities within the system). Minimizing coupling reduces the likelihood and extent of unwanted emergent properties, thereby reducing integration problems, costs and delays, improving fitness for purpose (INCOSE).
|
|
|
Term
|
Definition
| Stylistic aspects of the language, such as when to use uppercase versus lowercase and when to use spaces (Friedenthal, Moore & Steiner, p. 25). |
|
|
Term
|
Definition
| Model element that's allowed to contain other model elements; it can have other elements nested under it within the model hierarchy (Delligatti, p. 24). Container. Any element that can have other elements nested under it in the containment tree of the model (OCSMP Accelerator, Module-1, Part-1, Seg.-1). |
|
|
Term
|
Definition
| A generic, abstract concept that, when put into a context, represents something that is necessary or desirable for the subject of the context (Holt & Perry, p. 46). |
|
|
Term
|
Definition
| A tangible description of an abstract need that is defined according to a predefined set of attributes (Holt & Perry, p. 46). |
|
|
Term
|
Definition
| A diagram element that generally appears as a shape, such as a rectangle or oval with a text label. May contain additional text strings and/or other graphical symbols that may correspond to other model elements (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| Generally rectangular, but may also be round-angled, ellipses, and other polygons. All node symbols have a name compartment to display the name string of the represented model element, along with any applicable keywords and properties. Some have extra compartments to display details of nested elements either in textual or graphical form (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| Add to a block when you need to model multiple types of items that could flow in or out via that port. The type must be the name of a flow specification somewhere in the model (Delligatti, p. 38). |
|
|
Term
|
Definition
SysML supports:
- Matrices
- Trees.
- Tables (Friedenthal, Moore & Steiner, p. 99).
|
|
|
Term
|
Definition
| Only available prior to the start of the action execution (Friedenthal, Moore & Steiner, p. 68). |
|
|
Term
|
Definition
| Produced only at the completion of the action execution (Friedenthal, Moore & Steiner, p. 68). |
|
|
Term
|
Definition
| Notation for a comment: A rectangle whose upper-right corner is bent. Use a dashed line to attach a comment to other elements. Can attach a comment to several model elements simultaneously by using a separate dashed line for each (Delligatti, p. 59). Can be attached via a dashed line to a symbol of any model element or set of model elements. Used to annotate the model with additional textual information that may include a hyperlink to a reference document. A rectangular box with a cutoff upper right corner, containing textual information. Can be used to display user-defined tags. To display cross-cutting information such as traceability to requirements, and allocation (Friedenthal, Moore & Steiner, p. 94). Difference between a comment and a note symbol is that a comment is a model element that is part of the model, whereas a note symbol is a diagram annotation only (97). |
|
|
Term
|
Definition
N2 chart, captures interface information (Friedenthal, Moore & Steiner, p. 96). NxN interaction matrix to identify interactions or interfaces between major factors from a systems perspective (NASA/SP-2016-6105-SUPPL, p. 114). A functional analysis or architecting technique that can:
- Minimize connectivity (the extent and complexity of deliberate interaction between functional or physical entities within a system architecture). Minimizing connectivity has a near quadratic effect on cost and integration complexity.
- Maximize cohesion (functions with similar characteristics can often be fulfilled by common elements of a system solution using similar technology). Maximizing cohesion reduces development, production and support costs, minimizes solution footprint and minimizes effect of solution technologies on other lines of development.
- Minimize coupling (the extent and complexity of the intrinsic relationships between physical entities within the system). Minimizing coupling reduces the likelihood and extent of unwanted emergent properties, thereby reducing integration problems, costs and delays, improving fitness for purpose (INCOSE).
|
|
|
Term
| Object Constraint Language |
|
Definition
| (Friedenthal, Moore & Steiner, p. 24) A text-driven formal language used to formulate constraints in SysML / UML models. The language supports, among other things, navigation in object models, Boolean algebra, and set operations (Weilkiens, p. 290). |
|
|
Term
|
Definition
| Connects outputs from one action to the input of another (Friedenthal, Moore & Steiner, p. 45). Specifies the flow of inputs and outputs (63). A solid line with an arrowhead connects the output pin from one action in an activity diagram to the input pin of another action (64). |
|
|
Term
| Object Management Group (OMG) |
|
Definition
| Consortium of hundreds of computer industry companies, government agencies, academic institutions that collaborate to develop a set of enterprise integration standards and promote business technology (Delligatti, p. 12). Industry standards body which manages and configures SysML (Holt & Perry, p. 91). |
|
|
Term
| Object-Oriented Systems Engineering Method (OOSEM) |
|
Definition
| (Friedenthal, Moore & Steiner, p. xviii). To facilitate integration of systems engineering with object-oriented (OO) software engineering, and to apply OO modeling in a way that benefits the systems engineering process (INCOSE). |
|
|
Term
|
Definition
| Sometimes the diagram layout makes it difficult to connect two nodes due to their placement on the diagram. A path symbol may be represented by two symbols. Each is connected at one end to a node symbol while its other end is connected to a circle with a label inside. The combination of these two half-path symbols with a common label is equivalent to a single traditional path symbol. Can be used within a single diagram, but is often used to visualize a path that connects two nodes on different diagrams (Friedenthal, Moore & Steiner, p. 95). |
|
|
Term
| OMG Certified Systems Modeling Professional (OCSMP) |
|
Definition
| OCSMP certification exams objectively validate a candidate's knowledge and skills in System Modeling Language (SysML) and Model-Based Systems Engineering (MBSE) [Pearson VUE]. |
|
|
Term
|
Definition
AKA Conceptual Model.
AKA Metamodel.
A domain-specific vocabulary reflecting core concepts (Friedenthal, Moore & Steiner, p. 25). An underlying definition of all the relevant concepts and terms--the domain-specific language (Holt & Perry, p. 9). In order to use our language effectively we need a domain-specific language that identifies the terms for each concept and provides definitions for each (10). Provides a visualization of all the key concepts. Defines frameworks that can be used for different aspects of MBSE. Defines MBSE competencies. Many aspects of the process, such as the process model, the artifacts and the execution in lifecycles, will be based directly on the MBSE ontology (22-23). An element of an architectural framework that defines all the concepts and terms (one or more ontology element) that relate to any architecture structured according to the architectural framework (54). |
|
|
Term
|
Definition
| Concepts that make up an ontology. Each ontology element can be related to each other and is used in the definition of each viewpoint (through the corresponding viewpoint element that makes up a viewpoint). The provenance for each ontology element is provided by one or more standard (Holt & Perry, p. 54). |
|
|
Term
|
Definition
- On one end of reference association line between blocks of bdd, unidirectional access (Delligatti, p. 44).
- On dashed line of dependency relationship, arrow drawn from client to supplier on a bdd (52).
- For asynchronous message (Friedenthal, Moore & Steiner, p. 61).
|
|
|
Term
|
Definition
| Added inside a block with the operations' names within it. The compartment can appear above or below the values compartment. The name of an operation is followed by two brackets. Not optional, and forms part of the name of the operation. Extra detail can be added to operations, such as parameters and return values. The full form of an operation name is: operation name( parameter name : parameter type,...) : return type An operation can have any number of parameters (Holt & Perry, pp. 102-103). |
|
|
Term
|
Definition
| A behavior that a block performs when a client calls it, invoked by a call event. Display an operation on a Block Definition Diagram (bdd) as a string in the operations compartment with format <operation name>(<parameter list>):<return type>[<multiplicity>] Operation name is modeler defined. Parameter list is a comma-separated list of zero or more parameters. Return type (if any) must be the name of a value type or block in the model. The parameters in the parameters list are the inputs or outputs of the operation, displayed with format <direction> <parameter name>:<type>[<multiplicity>]=<default value> Direction can be in, out, or inout. Parameter name is modeler defined. Type must be a value type or block in the model. Use a verb phrase to name an operation, which represents a behavior (Delligatti, pp. 40-41). Shows what a block does, rather than what it looks like, named using verbs or verb phrases. Represented by adding an operations compartment to the block and writing the operation names within it. The compartment can appear above or below the values compartment. The name of an operation is followed by two brackets, not optional, which form part of the name of the operation. Extra detail can be added to operations such as parameters and return values. The full form of an operation name is: operation name( parameter name : parameter type,...) : return type An operation can have any number of parameters (Holt & Perry, pp. 102-103). |
|
|
Term
|
Definition
| A collection of one or more organizational unit. It runs one or more project and will have its own organizational context (Holt & Perry, p. 74). |
|
|
Term
|
Definition
| A special type of organization that itself can make up part of an organization. An organizational unit runs one or more project and will have its own organizational context (Holt & Perry, p. 74). |
|
|
Term
|
Definition
| First step in simplified Mode-Based Systems Engineering (MBSE) method. Define the package diagram to organize the system model (Friedenthal, Moore & Steiner, p. 47). |
|
|
Term
|
Definition
| Observable result of the successful achievement of the process purpose (Holt & Perry, p. 59). |
|
|
Term
|
Definition
| Most common kind of namespace for the various elements of definition that appear on Block Definition Diagrams (bdd) (Delligatti, p. 24). May contain other nested packages (Friedenthal, Moore & Steiner, p. 43). |
|
|
Term
|
Definition
| Displays the way a model is organized in the form of a containment hierarchy (Delligatti, p. 16). Allowable model element types: Package, model, model library, view and profile (20). Presents the organization of a model in terms of packages that contain model elements (Friedenthal, Moore & Steiner, p. 32). Organizes the model elements contained in the model (34). Each package contains a set of model elements, and each model element is contained in only one package. The package is said to own the elements that are contained within it. The package is a namespace for the contained model elements (56). A rake symbol on a package diagram represents a package that can refer to another package diagram (95). Organizes the model (Holt & Perry, p. 96). |
|
|
Term
|
Definition
AKA Toolbox.
Includes diagram elements used to create or modify a diagram (Friedenthal, Moore & Steiner, p. 42). Typically context-sensitive such that the diagram elements that appear in the pallet depend upon the diagram being viewed in the diagram area (43). |
|
|
Term
|
Definition
- Indicates that interactions occur in parallel (Friedenthal, Moore & Steiner, p. 61).
- Abbreviation for parametric diagram, for how one or more constraints (equations and inequalities) are bound to the properties of a system. Supports engineering analysis of performance, reliability, availability, etc., and supports trade studies (Delligatti, p. 16). Allowable model element types: Block, constraint block (20). Presents constraints on property values, used to support engineering analysis (Friedenthal, Moore & Steiner, p. 32). Describes parametric relationships in mass properties analysis (36). Shows how equations are used to analyze and satisfy requirements. Shows a network of constraints--each constraint is a usage of a constraint block defined in a Block Definition Diagram (bdd) for analysis context. The equations for the constraints may be shown on the parametric diagram. Parameters of equations are shown as small rectangles flush with the inside boundary of the constraint (73). A rake symbol on a parametric diagram represents a constraint property that can refer to another parametric diagram (95). Constraints on system property values, allowing engineering analysis models to be produced, defining complex constraint relationships that can be used in verification and validation activities (Holt & Perry, p. 97).
|
|
|
Term
|
Definition
| Each is displayed with format <parameter name>:<type> [<multiplicity>]=<default value> Parameter name is modeler defined. Type must be the name of a value type block somewhere in the model (Delligatti, p. 43). The parameters of a reception can only be inputs, and never outputs. Parametrics enable the critical value properties of the system design to be identified and integrated with parameters in the analytical models (Friedenthal, Moore & Steiner, p. 75). |
|
|
Term
|
Definition
| How one or more constraints (equations and inequalities) are bound to the properties of a system. Supports engineering analysis of performance, reliability, availability, etc., and supports trade studies (Delligatti, p. 16). Allowable model element types: Block, constraint block (20). Presents constraints on property values, used to support engineering analysis (Friedenthal, Moore & Steiner, p. 32). Describes parametric relationships in mass properties analysis (36). Shows how equations are used to analyze and satisfy requirements. Shows a network of constraints--each constraint is a usage of a constraint block defined in a Block Definition Diagram (bdd) for analysis context. The equations for the constraints may be shown on the parametric diagram. Parameters of equations are shown as small rectangles flush with the inside boundary of the constraint (73). A rake symbol on a parametric diagram represents a constraint property that can refer to another parametric diagram (95). Constraints on system property values, allowing engineering analysis models to be produced, defining complex constraint relationships that can be used in verification and validation activities (Holt & Perry, p. 97). |
|
|
Term
|
Definition
| Child blocks inherit their properties and operations from their parent blocks, but will be different in some way in order to make them special. Inheritance only runs from parent blocks to child blocks. If, when modeling a type of hierarchy, it is found that a property or operation was being added into all types, then this is a sign that the property or operation should be moved up the hierarchy so that it is defined in one place and inherited by all the descendent blocks (Holt & Perry, pp. 105-106). |
|
|
Term
|
Definition
| Structure internal to a block; a block is composed of its part properties. Because of ownership, a part property can belong to only one composite structure at a time. For an unconstrained number of instances, set multiplicity to 0..* The asterisk means that you're not specifying an upper bound. You can just use * without the 0.. (Delligatti, pp. 28-29). It's redundant to show both the parts compartment notation and composite associations on the same diagram (48). Enables the same block to be reused in different contexts and be uniquely identified by its usage. Each part may be further redefined to have behaviors, value properties and constraints that apply to its particular usage (Friedenthal, Moore & Steiner, p. 71). Owned by the block. Properties that are intrinsic to the block but which may have their own identities. A composition or aggregation relationship creates part properties between the owning block and the blocks that it is composed of (Holt & Perry, p. 102). |
|
|
Term
|
Definition
AKA Edge.
A diagram element that generally appears as a line that may have additional adornments such as arrowheads and text strings (Friedenthal, Moore & Steiner, p. 93). |
|
|
Term
|
Definition
| Some kind of line with different styles and ends depending on the modeling concept they represent. May have a text adornment that contains their name string, keywords and additional properties. Additional textual information may also be shown on the ends of the lines (Friedenthal, Moore & Steiner, pp. 93-94). |
|
|
Term
|
Definition
| A defined set of viewpoints and associated view that may be reused for a number of different applications (Holt & Perry, p. 26). |
|
|
Term
|
Definition
| Step-5 in simplified Model-Based Systems Engineering (MBSE) method. To evaluate and select a preferred system solution that satisfies the system requirements and maximizes the effectiveness measures. Capture the analysis context in a Block Definition Diagram (bdd) to identify the analysis to be performed, such as performance, mass properties, reliability, cost, critical properties. Capture each analysis as a parametric diagram. Perform the engineering analysis to determine the values of the system properties (Friedenthal, Moore & Steiner, p. 49). |
|
|
Term
|
Definition
| Collection of one or more view (and hence also one or more defining viewpoint) related by their purpose. One or more view that addresses the same architectural needs (Holt & Perry, p. 55). |
|
|
Term
|
Definition
| Mock-up to provide a picture of what the final system will look like, or used as part of a physical simulation or analysis (Holt & Perry, p. 94). |
|
|
Term
|
Definition
| Small rectangle on an action representing its inputs and outputs. Can be created by selecting an input pin or output pin from the context-sensitive menu (Friedenthal, Moore & Steiner, p. 45). |
|
|
Term
|
Definition
| Package diagram displays the way a model is organized in the form of a containment hierarchy (Delligatti, p. 16). Allowable model element types: Package, model, model library, view and profile (20). Presents the organization of a model in terms of packages that contain model elements (Friedenthal, Moore & Steiner, p. 32). Organizes the model elements contained in the model (34). Each package contains a set of model elements, and each model element is contained in only one package. The package is said to own the elements that are contained within it. The package is a namespace for the contained model elements (56). A rake symbol on a package diagram represents a package that can refer to another package diagram (95). Organizes the model (Holt & Perry, p. 96). |
|
|
Term
|
Definition
| It's legal to display a block's ports in compartments, but it's much more common to display ports as small squares that straddle the border of a block (Delligatti, p. 27). A property that represents a distinct interaction point at the boundary of a structure through which external entities can interact with that structure, to provide or request a service or to exchange matter, energy or data. Captures the interface--that services it provides and requires, the types of matter, energy or data that flow in or out. Adding a port means modeling a black box with respect to the structure's environment. The structure's internal implementation is hidden from clients. A port decouples a block's clients from any particular internal implementation (34). Small squares on the frame that represent interfaces (Friedenthal, Moore & Steiner, p. 34). Ports on the parts may not be visible on the diagram, even if they have been previously defined in the model. Many tools require the modeler to select the part and activate a menu item to display ports (46). Can specify the items that can flow in or out of a part and the services that are either required or provided by a part. The port provides a mechanism to integrate the behavior of the system with its structure by enabling access to a part's behavior and other features (66). |
|
|
Term
|
Definition
- Automated consistency when change occurs.
- Rapid, definitive answers to stakeholder questions (Delligatti, OCSMP Accelerator, Module-0, Segment-2).
|
|
|
Term
|
Definition
No internal structure--doesn't own any value properties. Notation is a rectangle with the stereotype <<valueType>> preceding the name. Four primitive value types:
- String.
- Boolean.
- Integer.
- Real.
Define your own primitive value types as specializations (subtypes) of string, boolean, integer and real (Delligatti, p. 55). |
|
|
Term
|
Definition
AKA Process Element.
The fundamental unit of a process. A process can be defined in terms of subprocesses or process elements. A subprocess can be further decomposed into subprocesses or process elements; a process element cannot. Each process element covers a closely related set of activities. Can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. A process element can be an activity or task (Holt & Perry, p. 61). |
|
|
Term
|
Definition
| Documented expression of a set of activities performed to achieve a given purpose. Provides an operational definition of the major components of a process. The description specifies, in a complete, precise and verifiable manner, the requirements, design, behavior or other characteristics of a process. May include procedures for determining whether these provisions have been satisfied. Found at the activity, project or organizational level [CMMI]. |
|
|
Term
|
Definition
AKA Process Component.
The fundamental unit of a process. A process can be defined in terms of subprocesses or process elements. A subprocess can be further decomposed into subprocesses or process elements; a process element cannot. Each process element covers a closely related set of activities. Can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. A process element can be an activity or task (Holt & Perry, p. 61). |
|
|
Term
|
Definition
| An ordered execution of one or more processes performed as part of a stage (Holt & Perry, p. 59). One or more processes that are executed for a specific purpose. May be defined based on a team, function, etc. (63). |
|
|
Term
|
Definition
| High-level objective of performing the process and the likely outcomes of effective implementation of the process (Holt & Perry, p. 59). |
|
|
Term
|
Definition
| A set of processes that enable us to implement the MBSE framework (Holt & Perry, p. 21). |
|
|
Term
|
Definition
| Something that realizes a system (Holt & Perry, p. 42). A work product that is intended for delivery to a customer or end user (70). |
|
|
Term
|
Definition
| The period of time, consisting of phases, which begins when a product is conceived and ends when the product is no longer available for use. Since an organization may be producing multiple products for multiple customers, one description of a product lifecycle may not be adequate. The organization may define a set of approved product lifecycle models, typically found in published literature, likely to be tailored for use in an organization. Phases can include concept / vision, feasibility, design / development, production and phase-out (Holt & Perry, p. 57). |
|
|
Term
|
Definition
| A project or collection of related projects and the infrastructure that supports them, including objectives, methods, activities, plans and success measures (Holt & Perry, p. 70). A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete project in the program (71). A group of related projects and change management activities that together achieve beneficial change for an organization (72). A special type of project that is itself made up of one or more projects (74). |
|
|
Term
|
Definition
| An endeavor with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements [ISO-15288] (Holt & Perry, p. 69). One or more project is run by an organizational unit in order to produce one or more system (73). A managed set of interrelated resources which delivers one or more products to a customer or end user. Has a definite beginning (i.e., project startup) and typically operates according to a plan. Such a plan is frequently documented and specifies what is to be delivered or implemented, the resources and funds to be used, the work to be done, and a schedule for doing the work. A project can be composed of projects (70). A temporary endeavor undertaken to create a unique product, service or result [PMBOK] (71). A unique, transient endeavor undertaken to achieve planned objectives (72). |
|
|
Term
|
Definition
| A higher-level collection of projects that addresses the strategic objectives of the organization (Holt & Perry, p. 69). |
|
|
Term
|
Definition
Properties of the block can be added by selecting the block on the diagram or in the browser, opening the block's specification, adding the property, and naming it (Friedenthal, Moore & Steiner, p. 46). Represent features of a block and are usually represented by nouns. They must be able to take on different values. Three different kinds of properties:
- Value.
- Part.
- Reference (Holt & Perry, p. 102).
|
|
|
Term
|
Definition
| Must implement all of the interface's operations and receptions. Ball notation--lollipop symbol attached to the standard port square (Delligatti, p. 36). |
|
|
Term
|
Definition
| Graphical, tabular or textual reports are generated by querying the model and presenting the information in the desired form (Friedenthal, p. 19). |
|
|
Term
|
Definition
Indicates the model element is described by another diagram.
- On an activity diagram, it stands for a call behavior action that can refer to another activity diagram.
- On an internal block diagram, it stands for a part that can refer to another internal block diagram.
- On a package diagram, it stands for a package that can refer to another package diagram.
- On a parametric diagram, it stands for a constraint property that can refer to another parametric diagram.
- On a requirement diagram, it represents a requirement that can refer to another requirement diagram.
- On a sequence diagram, it indicates an interaction fragment that can refer to another sequence diagram.
- On a state machine diagram, it represents a state that can refer to another state machine diagram.
- On a use case diagram, it represents a use case that is realized by other behavior diagrams:
- Activity.
- State machine.
- Sequence (Friedenthal, Moore & Steiner, p. 96).
|
|
|
Term
|
Definition
| Specialized kind of comment with a <<rationale>> stereotype preceding the body, used in conjunction with requirements relationships and allocations (Delligatti, p. 60). |
|
|
Term
|
Definition
| Primitive value type (Delligatti, p. 55). |
|
|
Term
|
Definition
| One of two value properties with type Real, that make up a structured value type (Delligatti, p. 56). |
|
|
Term
|
Definition
| A behavior a block performs when a client sends a signal that triggers it; invoked by a signal event. Key distinction between a reception and an operation is that a reception always represents an asynchronous behavior. A client sends a signal which triggers a reception upon receipt, and immediatly continues with its own (the client's) execution--it doesn't wait for the reception. To display a reception in the reception's compartment of a block, the string has format <<signal>> <reception name> ( <parameter list> ) The reception name must match the name of the signal in your model that triggers it. A reception must have a parameter with a compatible type for each property of the signal. Unlike operations, receptions cannot have return types. Receptions are asynchronous; the client that sent the signal isn't waiting for a reply (Delligatti, pp. 42-43). |
|
|
Term
|
Definition
| Indicates interaction uses, which reference a more detailed interaction (Friedenthal, Moore & Steiner, p. 61). |
|
|
Term
|
Definition
| A predefined field in the optional diagram description note, with references to other information, hyperlinks to related diagrams to aid in navigation (Friedenthal, Moore & Steiner, p. 92). |
|
|
Term
|
Definition
| A connection can exist between instances of the involved blocks in an operational system. Those instances can access each other for some purpose across the connection. Notation for a reference association is a solid line between two blocks of a Block Definition Diagram (bdd). An open arrowhead on only one end conveys unidirectional access. The absence of arrowheads on either end conveys bidirectional access (Delligatti, p. 44). |
|
|
Term
|
Definition
| Steps in a use case description can be captured as requirements and related to the use case using the refine relationship (Friedenthal, Moore & Steiner, p. 60). |
|
|
Term
|
Definition
| Relates together one or more blocks. Should have names that form sentences when read together with their associated blocks (Holt & Perry, p. 99). There can be any number of relationships between two blocks (100). |
|
|
Term
|
Definition
| Requirements diagram, displays text-based requirements, the relationships between requirements (containment, derive and copy), and the relationships between requirements and other model elements that satisfy, verify and refine them (Delligatti, p. 16). Allowable model element types: package, model, model library, view and requirement (20). Presents text-based requirements and their relationships to other requirements, deesign elements, and test cases to support requirements traceability (Friedenthal, Moore & Steiner, p. 32). Presents a simple hierarchy of text-based requirements that are typically part of a specification document (34). Diagram presents the requirements that are typically captured in a text specification. The requirements are shown in a containment hierarchy to represent their parent-child relationships. Each requirement includes a unique identification and the text of the requirement and includes user-defined properties typically associated with requirements, design elements, analysis, and test cases using derive, satisfy, verify, refine, trace and copy (57-58). A rake symbol on a requirements diagram represents that a requirement can refer to another requirement diagram (96). Captures requirements hierarchies and requirements derivation. Allows a requirement to be related to model elements that satisfy or verify the requirement (Holt & Perry, p. 97). |
|
|
Term
|
Definition
| May invoke one or more but not necessarily all of its operations or receptions at some point during system operation. Socket notation--stick with a semicircle attached to the standard port square (Friedenthal, Moore & Steiner, p. 37). |
|
|
Term
|
Definition
| A property of a system that is either needed or wanted by a stakeholder role or other context-defining element. One or more requirements are needed to deliver each capability (Holt & Perry, p. 712). Text requirements can be written to correspond to the functional, interface, performance, and physical requirements associated with each block to create traditional text specifications from the model (Friedenthal, Moore & Steiner, p. 77). Requirements are supported by multiple notation options including direct, callout, and tabular presentations (79). A property of a system that is either needed or wanted by a stakeholder role or other context-defining element. One or more requirements is needed to deliver each capability (Holt & Perry, p. 46). |
|
|
Term
|
Definition
| req: displays text-based requirements, the relationships between requirements (containment, derive and copy), and the relationships between requirements and other model elements that satisfy, verify and refine them (Delligatti, p. 16). Allowable model element types: package, model, model library, view and requirement (20). Presents text-based requirements and their relationships to other requirements, design elements, and test cases to support requirements traceability (Friedenthal, Moore & Steiner, p. 32). Presents a simple hierarchy of text-based requirements that are typically part of a specification document (34). Diagram presents the requirements that are typically captured in a text specification. The requirements are shown in a containment hierarchy to represent their parent-child relationships. Each requirement includes a unique identification and the text of the requirement, and includes user-defined properties typically associated with requirements, such as verification status, and risk. Requirements can be related to other requirements, design elements, analysis and test cases using derive, satisfy, verify, refine, trace and copy (57-58). A rake symbol on a requirements diagram represents that a requirement can refer to another requirement diagram (96). Captures requirements hierarchy and requirements derivation. Allows a requirement to be related to model elements that satisfy or verify the requirement (Holt & Perry, p. 97). |
|
|
Term
|
Definition
| Anything that is used or consumed by an activity within a process (money, locations, fuel, raw material, data, people) (Holt & Perry, p. 63). Asset that is utilized or consumed during the execution of a process [ISO-15288] (60). |
|
|
Term
|
Definition
| The name of an actor conveys a role played by a person, an organization or another system when it interacts with your system (Delligatti, p. 54). |
|
|
Term
|
Definition
| Shown on the end of a reference association corresponding to the name of a reference property--owned by the block at the opposite end and whose type is the block that it's next to (Delligatti, p. 45). The directionality of an association can be augmented through the use of role names on each end of the association (Holt & Perry, p. 100). Composition can take role names (104). |
|
|
Term
|
Definition
| Constrains the attributes of a need description. May take several forms such as equations, heuristics, reserved word lists, grammar restrictions (Holt & Perry, p. 46). A construct that constrains the architectural framework (and hence the resulting architecture) in some way (for example, by defining one or more viewpoint that are required as a minimum) (55). |
|
|
Term
|
Definition
| An ordered set of interactions between one or more stakeholder role, system or system element that represents a specific chain of events with a specific outcome. One or more scenario validates each use case (Holt & Perry, p. 46). |
|
|
Term
| Scenario-Driven Analysis Method |
|
Definition
| Derives system functionality by analyzing scenarios and interactions among the parts (Friedenthal, Moore & Steiner, p. 47). |
|
|
