June 03, 2004
Glossary of OO/MDA terms
The following is a glossary of terms related to OO development and MDA that I use throughout this blog. As a result, I am less interested in being precise than making sure the reader and I are on the same page when I discuss these topics.
Abstraction. This is a kernel characteristic of OO development. All OO applications begin by abstracting entities from some real problem space. (Problem spaces themselves may be conceptual, such as mathematics.) In OO development abstraction is defined in terms of two properties: responsibility for knowing something and responsibility for doing something. Abstraction applies at the level of individual properties, objects, classes of objects, relationships, and subsystems. In other words, virtually everything about OO construction. (See category on what OO is all about.)
Abstract Data Type (ADT). An abstract definition of data that describes it in symbolic terms while hiding details of the implementation. This allows type checking that is stronger than that based upon fundamental memory storage types. Thus one can prevent a Money value and a Voltage value from being used together in an arithmetic expression even though both are stored as reals. In an OOA/D context ADTs are especially important because they allow complex data structures to be abstracted to scalar values that are logically indivisible at a given level of abstraction. That is, they allow us to redefine the notion of simple domain in a flexibly manner based upon context. In OOA/D knowledge responsibilities are always expressed as ADTs. (See category on what OO is all about.)
Action. The refers to the suite of rules and policies associated with a state machine state. Typically an action is an object method. (See category on state machines.)
Ad hoc polymorphism. A form of polymorphism where behaviors are substituted (e.g., a switch statement) within a method based upon the value of an argument to the method. The substitution is based upon selection of a uniquely identified, complete behavior from among several alternatives.
Anthropomorphization. Software usually automates operations that people would execute in the equivalent manual system. Meanwhile, we tend to abstract inanimate entities during OO development. To attach behavior responsibilities to the inanimate abstractions we need to anthropomorphize. That is, we attribute the behaviors a person would use to control or manipulate the objects in a manual system to the objects themselves in an OO solution. This idea underlies the emphasis one sees in the OO literature on roles; roles are a convenient rationale for attributing human behavior to inanimate entities.
Application. A software program executed on a computer to solve some problem defined in a customer problem space. This is a somewhat broader and less precise definition than many in the computing literature, but the main characteristic I am attempting to capture in this blog is that applications usually deal with problem spaces other than the computing space
Application Partitioning. A Systems Engineering activity whereby an application is subdivided into cohesive logical units that are encapsulated as subsystems. In OO development this partitioning is defined in terms of subject matter, level of abstraction, and client/service relationships. (See category on application partitioning.)
Association. A relationship between individual classes in a UML Class Diagram that does not involve subclassing. It defines the structure of some logical connection between members of the sets represented by the participating classes. The structure is described primarily in terms of multiplicity, conditionality, and role. (See category on relationships.)
Asynchronous collaboration. Asynchronous collaboration exists when there may be an arbitrary delay between when a message is sent and when the receiving object actually responds. Note that asynchronous communications are associated with but are orthogonal to concurrent execution models.
Attribute. In OO development, a knowledge responsibility property is usually referred to as a an attribute in order to contrast it with behavior responsibility properties. (See category on what OO is all about.)
Class. A class defines a logically related set of properties that a specific group of entities all share. That sharing also makes the group of entities unique compared to other entities. Classes are about set membership based upon sets of shared properties. (See category on what OO is all about.)
Class Diagram. This is a UML diagram that describes the basic static structure of a subsystem. It identifies classes, relationships, and responsibilities for the entities abstracted in the problem solution.
Client. This word is overloaded in the context of OO software development. One meaning refers to whoever pays for the software to be produced. A second refers to the way some subsystems define requirements for other subsystems (see Client/Service relationship). A third meaning is in the context of DbC where the sender of a message is a client of the contract for the receiver's responsibility. In OOA/D this should be a generic view of client rather than the "Do This" paradigm of procedural programming where one function directs another to do something specific (i.e., the message sender understands the solution context enough to know what needs to be done next in the overall problem solution). In other words, the developer is responsible for ensuring contracts are met when defining messages, not the sender implementation.
Client/service relationship. In application partitioning this refers to a functional dependency between subsystems. That dependency is based upon a flow of requirements; the client defines requirements that the service must implement. These dependencies form a directed, acyclic graph in a UML Package Diagram. Note that this is orthogonal to communications between subsystems when they collaborate, which tend to be bidirectional. (See category on application partitioning.)
Collaboration. Collaboration refers to the ways that objects interact. Collaboration is conceptually initiated by sending a message from one object to another and the receiver <usually> responds in some predictable manner. During collaboration the properties of the receiving object are accessed. In OOA and OOD behavior collaborations are treated as always being asynchronous. In contrast, knowledge collaborations are always treated as synchronous. (See category on what OO is all about.)
Complexity Management. The basic idea behind this phrase is that many problem spaces are so complex that they defy comprehension in their totality. Therefore to provide problem solutions one must somehow manage than complexity. Software development in general has struggled with this problem almost since its inception, resulting in techniques like functional decomposition. One can argue that OO development is largely based upon providing a systematic approach to managing problem space complexity.
Computing space. This refers a collection of concepts, paradigms, policies, rules, technologies, etc., that are logically related to computing in an environment that is based upon Turing and von Neumann computational models. Today that includes much of the infrastructure (operating systems, middleware, etc.) that we associate with software development.
Collaboration Diagram. This is a UML diagram that is used to model interactions (message passing) between objects. It is particularly suited to asynchronous processing because no message sequence is implied in the diagram.
Concurrent Execution. This is an execution model that allows multiple statements from a software program to execute simultaneously on multiple processors (or in an interleaved manner on a single processor so that two program units appear to be executing simultaneously). Concurrent processing introduces significant data and referential integrity problems that must be addressed during OOP through infrastructures for message blocking, threads, etc. Those infrastructures tend to introduce arbitrary delays in message processing. That is why behavior execution is assumed to be asynchronous in OOA/D models; it is the most general model for dealing with functional requirements (i.e., it does not depend on how nonfunctional requirements are resolved).
Conditionality. This notion applies to associations in OOA/D. It describes whether the relationship is always present (unconditional) so long as both participants exist or exists only under some specific conditions (conditional). Note that an unconditional association implies that both participating objects are created at the same time when the association is 1:1. (See category on relationships.)
CRUD. An acronym for Create, Retrieve, Update, Report. The acronym is similar to USER below and dates from the days when IT was known as Data Processing. It characterizes applications that are focused primarily on data entry and reporting for a data bases. Such applications are effectively pipelines between the database and the UI and the only business rules they apply are to ensure data integrity.
Customer. Whoever defines the requirements for the software. Contrast to: client, who pays for the software, and user, who interacts with the software.
Customer space. The suite of rules, paradigms, policies, technologies, concepts, and whatnot that are logically related to the nature of the customer's environment. For example, in an accounting application where the customer is an accountant the relevant customer space includes double entry bookkeeping, policies on allocations, Account semantics, and other relevant notions for the customer's view of the problem. Note that if the customer is in the computing space (e.g., middleware), the customer space may also be a computing space.
Data integrity. When data is accessed in a software program it is important that the data be correct, consistent, and timely. Since software also modifies data as it executes, it is possible to modify data (or fail to initialize it) in a manner that results in incorrect, inconsistent, or untimely data being accessed. Data integrity is an umbrella suite of issues related to ensuring safe modification and initialization of data and synchronization with access.
Design by contract (DbC). This is a fundamental concept is OO software construction. The basic idea is that there is a contract between an object and the rest of the application that specifies what it should do when presented with a message in a collaboration. These contracts are commonly expressed as: preconditions, which are conditions that must prevail when the message is issued; postconditions, which are conditions that must prevail when the receiving object has completed its response; and invariant conditions, which are conditions that must prevail throughout the receiver's response to a message. DbC is particularly useful in rigorously ensuring correct sequencing of operations when the asynchronous model is used in OOA/D for behavior collaborations.
Elaboration. This is the traditional approach to OO software development. The developer proceeds through a succession of stages -- OOA, OOD, and OOP. At each stage a solution model is produced. At each stage the developer manually adds value to the product of the preceding stage to produce the new model. Contrast: translation
Encapsulation. encapsulation is one of the core characteristics of OO software development. The basic idea is to implement a cohesive suite of intrinsic entity responsibilities behind an interface that hides the specific implementation of how the entity actually satisfies its responsibilities. (see category on what OO is all about.)
Escape. A common term to describe a defect that is not caught during testing (i.e., it escapes to the field).
Event. An event is an incident or occurrence during the execution of a software application that indicates a change in the state of execution of the application. Events are commonly viewed in an OOA/D context as a message that announces the change in execution state and they are issued in the method where the new condition prevails as a postcondition of executing that method. (See category on state machines.)
Event-based. This notion refers to a special case of pure message-based data transfer communication during a collaboration. The message is equated to an Event that signals a change in the execution state of the application; the message identity is the same as the Event identity.
Execution model. There are various execution models that underlie OOA/D solutions. These models define a context for solution dynamics that allow unambiguous solution specifications. For example, the execution model for OOA execution is either simultaneous, where methods may execute in parallel, or interleaved, where methods execute one-at-a-time. The developer must select a model to properly define collaborations consistently during OOD and OOP. More sophisticated models are required for concurrent processing in low-level OOD or OOP. The semantics of various execution models is described in the UML Action Semantics meta model specification.
Finite state automata. This is the mathematical model that underlies the state machines employed in OOA/D development. It defines a number of rules that happen to closely align with fundamental OO notions like encapsulation and implementation hiding. For example, a state cannot know what the previous state was or what the next state is. That is the basis for separation of message and method in OOA/D where messages are viewed as announcements rather than imperatives; the sender can't know what will happen when a message is sent, which precludes hierarchical implementation dependencies.
Fourth Generation Language (4GL). It is much more difficult to distinguish particular characteristics of 4GLs than for 3GLs, but the general distinguishing characteristic is the level of abstraction. The computation models that underlie 3GLs are usually not directly discernible at the 4GL level and the 4GLs typically introduce a variety of constructs that simply do not exist at the 3GL level (e.g., encapsulation and problem space entity abstraction). Typically the 4GL languages raise the bar for symbolic representation by being predominantly graphical rather than text-based. UML, since the addition of action semantics in v1.5 and support for executable models via MDA, qualifies as a true 4GL.
Functional requirements. These are the requirements that express what a software solution should do to solve some customer problem. Traditionally functional requirements describe what tangible outputs are produced by a software solution for a given suite of inputs. Functional requirements also include behavior rules, standards, policies, and other factors from the customer problem space that affect what the software needs to do to the inputs in order to provide the specified outputs. Contrast: nonfunctional requirements that address how the application should execute.
Inclusion polymorphism. This is a form of polymorphism that is enabled by OO subclassing and inheritance. It allows substitution of different subclass behaviors through accessing the interface provided for a superclass. The substitution is transparent to the sender of the message. (See categories for what OO is all about and relationships.)
Inheritance. A set of rules that determines the specific properties of an object that is a member of a subclassing relationship. The properties of a given leaf instance will be the union of properties encountered as one traverses the direct line of ascent to the root superclass. (See categories for what OO is all about and relationships.)
Instance. An instance is the software realization of an object at run-time. It is an instantiation of an object in the execution space.
Instantiation. This is the general process of creating instances of objects and relationships during the actual execution of the application. Objects must be instantiated in order for other object to interact with them. Relationships must be instantiated prior to navigating them for collaborations. While instantiation of relationship is explicit in OOA/D, it is often implied during OOP because of the way OOPLs hide the implementation of common OO constructs. Quite commonly the rules and policies for instantiation are quite different than those for collaboration. (See category on relationships.)
Interaction Diagram. An umbrella diagram classification in UML for diagrams that describe collaborations (message passing). The three diagram types included are Collaboration Diagrams, Sequence Diagrams, and Activity Diagrams.
Invariant. There are two meanings. One is that associated with DbC whereby the invariant describes some condition that must prevail throughout execution of a class or subsystem responsibility. The other meaning refers to abstracting aspects of the problem space that do not change across a large class of problems. Linear programming, Keplar's Laws, and double entry bookkeeping all represent invariants that can be abstracted the same way across a number of particular problem contexts without change. (See the category on invariants.)
Keep It Simple, Stupid (KISS). A traditional acronym that applies to complexity management in general, but it was originally developed in a software development context. This simplistic notion tends to be surprisingly appropriate in many aspects of software development.
Level of abstraction. A problem solution can be viewed and expressed at different levels of abstraction. Generally the subsystems in an application will be "layered" in terms of differing levels of abstraction. Thus the notion of a message data packet may be significantly different depending upon whether one is thinking about a user request as a banking transaction or a TCP/IP data packet on a network. Generally the level of abstraction of an entity's properties should be consistent with the level of abstraction of other entity's properties within the scope of a particular subsystem. The level of abstraction is also very important to the flexibility of OO's notion of logical indivisibility. (see category on application partitioning.)
Logical indivisibility. Flexible logical indivisibility is one of the core characteristics of OO development. To avoid the hierarchical dependencies of functional decomposition, objects or subsystems must interact as peers. But that is only possible in practice if they can be abstracted with different views of what constitutes logical indivisibility (i.e., the inability to further subdivide). Abstraction and levels of abstraction are employed to provide this flexibility. For example, attribute ADTs allow one to view complex data structures as scalars. (See category on what OO is all about.)
Mean Time To Failure (MTTF). This is a common measure of software reliability.
Message. A unit of communication during collaborations between objects. In OOA/D the message passed between objects and the responsibility implementation, usually a method, that responds to it are kept separate. The notion of message is quite conceptual in OOA/D and supports methodological approaches for constructing OO software. In particular, messages are regarded as announcements that something has happened in the sender, rather than as an imperative to the receiver to do something specific. In OOP and the OOPLs this distinction is not made because of the compromises that the OOPLs must make with computational models. However, if the OOA/D has been done properly, this loss of detail is benign because the responsibilities and collaborations defined in the OOA/D were done properly. (See category on what OO is all about.)
Method. This is the implementation of a behavior responsibility. It is the analogue of attribute for knowledge responsibilities. A method is usually executed in response to a message during a collaboration between objects. In an OO application the <testable> results of executing a method are changes to state variables and/or the state of the execution (e.g., a step in an algorithm has been completed). (See category on what OO is all about.)
Model-Based Software Engineering (MBSE). This is a methodological approach to OOA originally based upon the Shlaer-Mellor methodology. The methodology is one of several that are especially geared to translation. It happens to be the methodology that underlies this blog.
Model-Driven Architecture (MDA). This is an initiative by the OMG to help standardize the semantics associated with different representations of software problem solutions. In particular, it is focused on supporting transformation from one model view or representation to another. (See the MDA category in this blog.)
Multiplicity. This is a property of associations that constrains the number of participants in an association. The key distinction is between exactly one and more than one because that is fundamental to the relational data model. (For example, it determines whether the relationship can be implemented with a simple pointer or requires a collection class during OOP.) UML supports more specific specifications of participation for OOD, but those are not relevant to the MDA profiles for OOA models (PIMs). (see the category on relationships.)
Nonfunctional requirements. All of the requirements that are related to how a software solution is implemented. The major categories of nonfunctional requirements are size, performance, and reliability. However, any requirement that does not determine what outputs are produced from a given suite of inputs can be regarded as a nonfunctional requirement.
Object. An abstraction of an identifiable entity in some problem space. The abstraction is expressed in terms of knowledge or behavior properties that abstract what the entity knows or does that is relevant to the problem in hand. Contrast with: a Class abstracts the suite of properties that are shared among multiple objects and an instance instantiates an object at run time. (See category on what OO is all about.)
Object Management Group (OMG). This is a standards organization that defines UML, MDA, and other technologies that are crucial to (but not restricted to) OO software development.
Object-Oriented Analysis (OOA). This is a software design activity that produces a solution for the functional requirements of some problem that the customer needs to solve. (The OOA model does not address nonfunctional requirements.) This solution is independent of any particular computing environment and should be completely portable without change between computing environments. It is expressed in the customer's terms, so it should also be implementable without change in the customer's environment as a manual system (however inefficient as that might be). In MBSE an OOA model is executable so it is exactly equivalent to an MDA PIM. (See category on what OO is all about.)
Object-Oriented Design (OOD) This is a software design activity that produces a solution to the customer's problem that elaborates an OOA solution with strategic solutions for the nonfunctional requirements. As such, it is dependent upon a specific implementation environment. (See category on what OO is all about.)
Object-Oriented Programming (OOP). This is a programming activity that produces a tactical solution to the customer's problem that elaborates an OOD model. (The OOD model may not be physically produced in the agile OOP-based processes, but the basic OOA/D design effort is still represented in various ways.) Typically OOP produces a model of the solution in OOPL source code. (See category on what OO is all about.)
Object-Oriented Programming Language (OOPL). An OOPL is a 3GL with a number of unique OO features (e.g., classes and relationships) superimposed. Most OOPLs are actually hybrids; 3GLs with a few 4GL features. Some, such a Smalltalk, do a good job of hiding some 3GL features such as procedural message passing; others, such as C++, are are thin veneers over 3GL paradigms. (See category on what OO is all about.)
Package Diagram. In UML, a Package Diagram is where one describes the logical application partitioning. (The Package Diagram is also used for configuration management, but that is not relevant to MBSE.) The primary model element is the Subsystem.
Paradigm. Literally a paradigm is simply a model or pattern. In software development it usually applies to some universal practice or large-scale approach to development. OO development, functional programming, structured programming, and relational programming all represent different large-scale paradigms for developing software. Translation and elaboration represent different OO approaches to OO development. Employing getter/setter methods is an example of a practice paradigm.
Parametric polymorphism. Parametric polymorphism is a form of behavior substitution depending upon method arguments and/or attribute values to affect behavior. It differs from ad hoc polymorphism because a single behavior is provided where individual algorithmic decisions within that behavior are made based upon data values. The substitution is analogous to the use of templates. (See the category on invariants.)
Platform-Independent Model (PIM). Under MDA this model is a solution model that is independent of a particular computing environment. It is equivalent to a translation-quality OOA model. (See the category on MDA.)
Platform Model (PM). Under MDA this is a model of a particular computing platform that can be used by a transformation engine to produce a PSM. (See the category on MDA.)
Platform-Specific Model (PSM). Under MDA this is a solution model that is specific to a particular computing environment. A PSM can be a traditional OOD model, OOPL code, or even Assembly language. (See category on MDA.)
Polymorphism. Basically polymorphism is about transparently substituting one implementation for another. There is little need for substituting data implementations, so we are mostly concerned with behavior substitution. There are several forms of polymorphism supported for OO development: ad hoc, inclusion, overload, and parametric are the main ones of interest. (See categories on what OO is all about and relationships.)
Problem space. A cohesive suite of rules, policies, practices, conventions, standards, concepts, etc. that govern the conceptual domain where a particular problem needs to be solved.
Property. A unique quality that is associated with a group of identifiable entities (a class) in some problem space. In OO development all properties are expressed exclusively in terms of knowledge and behavior responsibilities.
Referential integrity. Object instances are created and deleted routinely during execution. Meanwhile, all collaborations need to address messages to particular objects. In addition, behavior collaboration in OOA/D may have asynchronous delays. Finally, methods access attributes of other objects directly on an as-needed basis. Referential integrity is about ensuring that the right objects are available when messages are addressed and consumed or attributes are accessed. (See category on relationships.)
Relationship. This is a logical connection between two classes. There are two basic kinds of relationships: associations and subclassing relations. Unfortunately the word is often used synonymously with association. (See the category on relationships.)
Relationship instantiation. Alas, this phrase is misleading because it invariably refers to association instantiation in the literature. (Subclassing relationships are not instantiated because only a single instance of the tree is created; rather the subclassing relationship is traversed to create the instance.) Instantiation of relationships is rather unique to OO development. The rules and policies that determine what members of the classes in a association are actually connected are typically encapsulated separately from the concerns that govern association navigation. (See the category on relationships.)
Relationship navigation. Alas, this phrase is misleading because it always refers to association navigation. (Subclassing relationships are not navigable because there is only one instance representing the entire tree.) Relationship navigation effectively means addressing a message to the correct instance. Typically the rules and policies that determine what instance is the correct one are enforced by the way the association is instantiated. So one "navigates" to the target instance by tracing a path of valid relationships. (See the category on relationships.)
Responsibility. The notion of describing problem space entities in terms of responsibilities is one of the core characteristics of OO development. The notion that publicly an entity is only responsible for knowing or doing something introduces a level of conceptual indirection that is important to OO encapsulation, implementation hiding, and DbC. It allows the "client" collaborating with an object to be protected from knowing anything about the details of how the "service" object actually fulfills its contract. (See category on what OO is all about.)
Role. This word has multiple meanings in a OO context. One is the nature of participation in an association. The other has to to with abstracting behaviors for objects. One abstracts behaviors based upon the entity's role in the problem solution. A third usage is in the context of anthopomorphization. Quite often we think of people's activities as roles when we anthropomorphize those activities onto inanimate abstractions.
Sequence Diagram. A particular sort of UML Interaction Diagram that describes interactions (message passing) among the application's objects. The Sequence Diagram describes a particular sequencing of the messages. Contrast: Collaboration Diagram.
Shlaer-Mellor. This is the original translation-based OO software construction approach. It was developed by Sally Shlaer and Steve Mellor in the early '80s.
Simple domain. This is a notion from from the relational data model (known as First Normal Form) where each attribute of an n-ary relation should be a logically indivisible semantic unit. Thus an attribute for telephoneNumber is a simple domain of a pattern of numeric digits -- provided we think of it purely as an "address" of a particular telephone (e.g., in a telephone dialer module). However, if something like the area code or exchange is important to us (e.g., for allocating calls to telemarketers), then it is not a simple domain because it is further subdivided into other semantic units. (See Abtract Data Type above.)
Space. In contexts like customer space and computing space, this refers to a particular conceptual domain where a well defined and closely related suite of concepts exist. Those concepts can capture rules, policies, standards, knowledge, behaviors, practices, technologies, or anything else useful for conducting a particular business (in the broad sense that includes computing).
Specification object. An object with no behavior responsibilities whose attribute values influence a generic behavior in another object. Such objects are a very common feature when parametric polymorphism is applied -- so much so that it is essentially an analysis pattern. (See category on parametric polymorphism.)
State. In an OO context there are two notions of state. One is the persistent version represented by state variable values. These are represented by knowledge attribute values. The other notion is that of the state of the execution that is represented by the states in object state machines. [One can also think of this kind of "state" in the sense of completing a step in the overall algorithm. Alas, this view gets a bit murky when there is large scale repitition, which makes the state machine state view more versatile and unambiguous.] In this sense a state is a condition where a particular suite of rules and policies prevail. One can also refer to the overall "state" of the application, which includes both kinds of state.
State machine. In an OO context a state machine is a finite state automata that records the state of the application execution. (OO state machines differ because state actions can access and modify state variables.) In the translation methodologies each object with behavior responsibilities has its own state machine. The object's behavior responsibilities are encapsulated in actions associated with the states. When a transition occurs, the state machine executes the action associated with the state. Transitions are triggered by events that announce a change in the overall state of the application. (See category on state machines.)
State variable. A state variable preserves static state information in terms of variable values that are <usually> globally accessible. In an OO context all state variables are attributes of some object and all attributes are state variables. (See category on what OO is all about.)
subclass. A subclass represents a class of entities that have unique properties defined by the subclass. In addition, those entities also share all the properties of a superclass to whom they are related through a subclassing relationship. They do not share the specialized properties of other sibling subclasses descending from the same superclass. Thus subclassing allows us to further subdivide the entities we have grouped into a general class. (See category on relationships.)
Subclassing. Subclassing refers to an OO mechanism that allows one to collect a subset of members of a large class based upon a suite of specialized properties unique to only that subset of members. All members of the subclass also share the properties of the related superclass. Often subclassing is referred to as "generalization" or "specialization" because of the way one commonly identifies subclasses (subdividing groups already sharing properties based on other properties that they do not all share) and superclasses (grouping common properties into a superclass) in practice. It is important to note that subclassing is the paradigm followed in OOA/D, but it is implemented in OOP as subtyping. (See category on relationships.)
Subject matter. When partitioning applications one identifies cohesive subject matters for the subsystems. A subject matter is a large-scale conceptual entity or domain that represents a collection of closely related knowledge and behavior responsibilities. The entity must be identifiable in some problem space. Examples of subject matters are: General Ledger, GUI, system test, inventory control, resource allocation, memory management, etc.
Subsystem. A logical subdivision of a programming system. Subsystems represent modularization through application partitioning. They are characterized by a cohesive subject matter, consistent level of abstraction, and client/service dependencies on other subsystems. Defining subsystems is usually a systems engineering activity. (See category on application partitioning.)
superclass. A class whose members can be subdivided into additional groups based upon additional sets of specialized properties beyond those they all share. The superclass identifies the unique suite of properties that all members of the set possess. When subdivided, the subset groups are subclasses and they are related to the superclass via a subclassing relationship.
Synchronous collaboration. In synchronous collaboration the sender of the message pauses until the receiver of the message completes its response. (3GL procedure invocation is a classic example of synchronous collaboration.) In OOA/D only knowledge is accessed synchronously (the message sender pauses until the receiver provides the requested data or finishes changing the data).
Systems Engineering. A branch of software engineering devoted to large-scale system design. In the MBSE context the relevant responsibilities are defining application partitions, allocating requirements to those partitions, and defining interfaces for those partitions.
Transformation. Under MDA a transformation produces a new model from at least one original model by applying some sort of transformation rules. For translation the input models are a PIM and an TM while the output model is a PSM in the form of 3GL, Assembly, or machine language code. (See category on MDA.)
Transformation engine. A software application that executes an MDA transformation. This is commonly known as a "code generator" when the resulting model is 3GL code. It is important to note that in translation the transformation engine provides 100% code generation for the functional requirements. (See category on MDA.)
Transformation Model (TM). Under MDA, a model of a particular computing environment that is used by a transformation engine to produce another model. In translation the TM models the technologies (e.g., J2EE vs. .NET, TCP/IP, etc.), strategies (e.g., write caching, persisting state on server, in client, or in DB, etc.), and other specifications available in the entire computing environment. (See category on MDA.)
Transformation rules. Under MDA, a suite of rules and policies that control the execution of a transformation. These can be represented in many ways and in various combinations. For example, they can be tags (MDA Markings) on a PIM, a BNF specification for a target language, or a suite of code templates. (See category on MDA.)
Transition. In a finite state automata, the movement from one state to another. (see category on state machines.)
Translation. An approach to OO development that achieves design reuse by automating the resolution of nonfunctional requirements. Typically full automatic code generation is provided from an OOA model. In MDA terms translation involves a transformation from a PIM directly to a PSM that is a 3GL program. (See category on MDA.)
Third Generation Language (3GL). These are text-based languages that provide abstractions of the computational model to facilitate software construction. The characteristic abstractions are block structuring, stack-based execution, procedures, and procedural message passing.
Type. A type classifies objects in terms of their interface. That is, objects are defined in terms of how they their responsibilities can be accessed or manipulated. Type systems are employed in OOPLs to implement the class system used by OOA/D. Contrast: class
Unified Modeling Language (UML). This is a 4GL notation tailored to OO software development. It is primarily a graphical notation. The standard is managed by the OMG.
User. The person who actually interacts with the software. Contrast: customer and client
USER. An acronym for Update, Sort, Extract, Report. The acronym is similar to CRUD above and dates from the days when IT was known as Data Processing. It characterizes applications that are focused primarily on data entry and reporting for a data bases. Such applications are effectively pipelines between the database and the UI and the only business rules they apply are to ensure data integrity.