04/22/2002, DWO	Semantic Dictionary - Concept Model, Draft #4		08/14/02 S. Friedenthal Proposed Update
Current Name	Current Definition		Propsed Name	Proposed Definition
Universe	Everything that exists and that may be conceived of		Domain of Interest	Set of entities which are of interest to the system modeler. (Refer to definition for "Environment" below)
SE_Thing	That which is discernable by reproducible measurement of its characteristics.		Entity	A generalization which represents anything of interest with a defined set of properties
Personally Experienced Stuff	All that is not yet discernable by reproducible measurement		Deleted
System	An assembly of interacting, active SE_Things with a well defined interface, both static and dynamic, with respect to the universe. Explanation: A system is composed of interacting components and the emergent behaviors and properties of the system are the result of the properties and behaviors of the components and their interactions. these interactions may be highly nonlinear. Note systems decompose hierarchically; they are systems of systems.		System	A composite of components which interact with one another to exhibit observable properties and behaviors.
				(Note: I believe we need a more generalized behavioral entity, which can be subclassed as system is a sub class along, with logical and physical or distribution entities. This needs much more discussion.).
			I/O Entity	An entity which flows between systems/components.(May include signals, mass flow, etc)
System Boundary	The static and dynamic interface that separates what parts of the universe are within System and what parts are outside of System		Boundary	The set of all physical connections (I.e. ports) which separates a system and/or component from its external environment. (Note: (Refer to definition for "Physical Connection" below. Not shown in the top level model)
Environment	This is the universe minus the system. It is often possible to limit the parts of the environment needed for development purposes to those external systems that are neighbors to the system. Note that the environment includes not only the external systems that couple with it for useful purposes, but they also include all external systems that may interact in a manner that causes failure.		Environment	The set of all entities which impact or are impacted by the system of interest. External environment is all entities external to the system, and the internal environment is all entities internal to the system. Environment includes both the system/components and the I/O entities which flow between them.  (NOTE: Environment is similar to Domain of Interest by this definition)
Subclasses of SE_Thing based on	Matter: That which exhibits mass and dimensional extent with units of mass and length^3		Mass	A type of physical property which represents the magnitude of the gravitational field associated with an entity (Note: Not shown in the top level model)
their measurable characteristics	Energy: The ability to do work with units of mass*length^2/time^2		Energy	A type of physical property which represents the ability of an entity to do work, which includes both kinetic and potential energy. (Note: Not shown in the top level model)
	Information: Knowledge about SE_Things expressed in an interpretable language.		Data	A logical abstraction of an encoded physical signal or store, which can be processed by a system and/or component.(Note: Not shown in the top level model)
Property	Any measurable characteristic of an SE_Thing. A STEP definition.		Property	A measurable characteristic, or characteristic which can be derived from other measurable characteristics.
Requirement	A statement of properties that a system shall exhibit or shall not exhibit when completed. Note: requirements are derived from requirements in a many-to-many relationship.		Requirement	A declarative which specifies expectations of a system, component, and/or the environment, and may include functional, interface, control, performance, physical, verification, other types of non-functional requirements, and design constraints. (NOTE: The model shows that a requirement specifies an entity versus the system to give more flexibility).
Property Measurement	A quantified value with units and variance resulting from measurement of the property of an SE_Thing or a set of SE_Things using measurement infrastructure		Property value	The values of a property, which may be continuous or discrete and deterministic or probabilistic.
			Property relationship	Relationship between properties and values, which is generally expressed in terms of mathematical equations.  (Note: sets of equations which are typically used in an analysis model)
Stakeholders	These are the people and institutions that have an interest in the system. They include, for example, the producers, owners, operators, users, and maintainers of the system.		Stakeholder	Individuals, groups, and/or institutions which may be impacted by the system throughout its life cycle, including acquisition, development, production, deployment, operations, support, and disposal.
Needs	Stakeholders have needs, or uses for the system. These become expressed as requirements.		Need	A type of requirement, which is intended to address a problem or inadequacy.as preceived by a stakeholder.
Verification	Confirmation and provision of objective evidence that the requirements for a specific intended use or application have been fulfilled by comparison against properties		Verification result	Assessment of compliance with requirements, by comparing requirements and observations using a prescribed method of observation.
Validation	Confirmation and provision of objective evidence that the requirements met the needs of stakeholders		Validation result	Assessment of the extent that the requirements satisfy the stakeholder needs
Validation Status	Data that defines the status of a requirement with regard validation/Verification		Defer to management
System View	A collection of information SE_Things about the system that are useful and defined for a particular purpose in a particular context.		View	Relationship between a subset of the entities in the domain of interest..
Subclasses of System View	There are an extremely large number of possible views of a system for particular development or use reasons. Systems engineering recognizes views associated with specification, design, manufacture, and maintenance as a minimum representative set. This corresponds to a life cycle viewpoint.		View subclass	(NOTE: Did not try to represent view subclasses, since there are many different views, and will required more detailed discussions.
Subclasses of Property based on			Property subclass	Subclasses of properties include performance, physical, etc, and can be further classified depending on the domain of interest.
what is measured
System Behavior	What an SE_Thing is to do or is not to do in response to excitations it receives from the external SE_Things in its context.		Behavior	A description of the stimulus/response of a system/component in terms of its functions, I/O entities, and control. (Note:represents a top level package for the System Domain Model, which includes the various constructs needed to describe behavior).
	Rationale: Property is usefully decomposed into several categories – the measurable characteristics in normal use and the measurable characteristics that require
Physical Property	What an SE_Thing exhibits or does not exhibit in response to excitation and stimulation from auxiliary measurement entities that are not part of its context.		Refer to property above
System Static Structure	The decomposition and other static relationship among the components of the system.		Structure	The composition, interconnection, deployment, and geometric/spatial relationships between systems and/or components. (Note:represents a top level package for the System Domain Model, which includes the various constructs needed to describe structure).
Categories	The grouping of SE_Things into a set based on defined properties that serve as selection criteria for which SE_Things of all those in the universe belong in that set.		Generalization/specialization	Refer to UML definition for generalization/specialization and possibly packages.
Sub-categories of Category			Generalization/specialization	Refer to UML definiiton. (NOTE: May need to expand to address Dave's input)
Inclusive/Complete Category	Any SE_Thing of the super category may reside in any number of the sub-categories and all members of the super-category are members of at least one of the sub-categories.
Inclusive/Incomplete Category	Any SE_Thing of the super category may reside in any number of the sub-categories and only some members of the super-category are members of the sub-categories.
Exclusive/Complete Category	Any SE_Thing of the super-category may reside in one and only one of the sub-categories and all members of the super-category are members of at least one of the sub-categories.
Exclusive/ Incomplete Category	Any SE_Thing of the super-category may reside in one and only one of the sub-categories and only some members of the super-category are members of the sub-categories.
System Assembly	A whole System is built from, assembled from its constituent components or sub-systems and the part list is complete.		Component	A physically replaceable part of a system, which is implemented by hardware, software, data, personnel/user/operator, procedure, facility, etc. (modified from UML definition).
	Rationale: Modeling the AP233 Part Hierarchy following PDM style will likely cause the appearance of relationships such as this in the ARM model. This consequence is fortunate because these relationships are important modeling primitives. There exist subtle differences in the way such relationships are defined in different engineering disciplines. The assumptions of mechanical engineering are not the same as those of software engineering.
Port	A port is a connection point on a system in the system decomposition hierarchy, Explanation: systems interconnect with one another port-to-port.		Physical connection (alias: port)	The physical surface which connects systems/components to one another (including the physical environment) to enable the flow of inputs and outputs. A connector may represent a set of connections.(Refer to definition of boundary).
Interfaces	An interface is the port to port interconnection between two systems. Examples: Parts interact physically through direct physical contact, exchange of SE_Things, and through forces they exert such as gravity. Thus I/O is bound to ports and interfaces. The interface may consist of more than the two ports and may involve an assembly of parts as in the case of two flanges that are assembled with six bolts and an O-ring. The interface may also require detailed description to define what occurs there or how it is maintained.		Not used.	NOTE: We need to be very careful in defining the term interfaces. It means many different things within the SE community (e.g. the I/O, transport medium, physical connection, etc), and clearly has a different meaning within the software community.
Subclasses of Interconnection (page 6)
Assembly	The relationships that exist among all of the parts of a whole such that they may be assembled to constitute the whole and result in the desired properties of the whole.		Composition	The relationships that exist among all of the parts of a whole such that they may be assembled to constitute the whole and result in the desired properties of the whole.(No change to current definition)
Context (Nearest Neighbors)	The relationships that exist among some of the parts of a whole such that the next nearest neighbor connection to one of the parts is defined.
System Behavior	Behavior is built from Input/Output (I/O), Function, and Function Ordering
Function	The entity in the context of modeling that transforms an input set of SE_Things into a set of output SE_Things that may be the same or measurably different from the input set.		Behaviroal function (alias: function, activity)	A transformation of input/ouptut entities that a system/component or the environment perform.
Input/Output (page 2 and 4)	SE_Things consumed by a function are Inputs and those generated by a function are Outputs
Comment	A given SE_T+C20hing that is an output of one function is an input to another function, hence Input/Output
Function Ordering (page 2, 4, and 5)	Functions may be sequential, concurrent, traversed iteratively, or lie on separate alternative paths		Control flow	Enabling/disabling of functions resulting from triggering events and conditions. (NOTE: This results in temporal ordering such as in an activity flow in an activity diagram, functional flow in a functional flow block diagram, and the state transitions in a state transition diagram).
Note	Function ordering may be represented by ordering operations or with state, events, and state transitions
Time (18)	The succession of events measured with repetitive phenomena from a sand glass to a cesium clock		Time	Property, which all other properties are dependent on. Time can be represented by continuous or discrete values as can all other properties..
Note	Time allocates to function and is categorized on page 6.
Physical Property and its Attributes (page 18)	Physical Properties are measured characteristics of SE_things that require auxiliary infrastructure for the measurement because they cannot be observed based on response to excitation or as components. Physical Property has attributes of measured mean value, variance, and probability distribution using particular infrastructure and specified measurement method.			Note: (Note:Refer to definition of "Property" and "Property Subclass")