Entity, Value, Property_Relationship, Composition, Time and Place

Entity, Value, Property_Relationship and Time seem to be too fine grained to be considered core SE concepts. They are no doubt needed to model most concepts, but I suggest that they be removed from the core SE conceptual model to further simplify the diagram or marked them to indicate that they are part of the infrastructure constructs required to model most concepts.

Also, I suggest that several of these concepts be renamed. I recommend the use of Instant instead of Time (listed in the dictionary) because of the different notions of time (i.e., specific point or time slice). This will allow the definition of an Interval or Period of time as the difference between two Instants. Also, I suggest a similar concept for spatial location which I call Place.

Rename Property_Relationship to Relationship, unless Property_Relationship provides some needed semantics that Relationship can’t convey or model. Also, rename Property Value to Property in the dictionary to match the diagram.

You list Composition in your dictionary of terms, but it is not shown in the diagram. Your diagram also shows that both Systems and I/O Entities can contain themselves, so does this imply that Entity is a subclass of Composition?

Last, why is it important to say in the definition of Property Value that it can be “continuous or discrete and deterministic or probabilistic”? Why not just say that a Value can hold either a constant value or one that is determined by the evaluation of a mathematical function which could be probabilistic and time dependant.

System, Component, Physical Connection and Port

What can (or should) be modeled by Component that can’t be modeled by System? The definition for Component states that it is “a physically replaceable part of a System”, but that its implementation may include “software” elements. Does this mean that Component represents an Implementation or a unit at the lowest possible level of functional decomposition, physical assembly or configuration management? Also, what does “physically” mean in this context? Would ‘structurally’ be a more generic or less confusing word?

In the dictionary you show Port as a synonym of Physical Connection, but the definition seems to focus on the connection of two systems and not the specific point of interaction. I suggest that Physical Connection be rename to just Connection since both physical and logical connections might be of interest and that Port be added as a different concept that refers to a single point of interaction on a System where it may be connected to (or interact with) another System. Based on this change, I recommend that Port be inserted in the diagram between Connection and System as I’ve shown on my update to your diagram.

I/O Entity (Flow), Control Flow

Suggest that I/O Entity be renamed as Flow. My rationale is that Flow is a more generic term and is frequently cited as a central focus of many system engineering concepts, analyses and related modeling techniques (e.g., Hitchins, INCOSE SE handbook, OMG Action Semantics). If needed, Input, Output, Control Flow, etc. can be defined to indicate specific subclasses of Flow. Note that my concept of Connection and Flow are closely related and may be redundant. I’ve use both to permit separating the interaction relationship between two Systems (Connection) from the object or subject of the interaction (Flow).

Also, I suggest changing the definition of Control Flow so that it is more declarative, succinct and straightforward. Last, consider renaming Control Flow to ControlFlow or just Control, and changing the relationship in the diagram to show Control flow as a subclass of Flow (I/O Entity).

The following graphic (from Derek Hitchins’ website http://www.hitchins.co.uk/Part%202.html) provides a good illustration of the basic concepts of Flows and Systems that I am proposing.

Element, Data, Energy and Mass

Your definition of Mass indicates that it is a property of a System or Entity. It seems to me that Mass is a property of some kind of physical compound (such as steel), which a System or Component might be composed of. If the composition has Matter, then Mass (along with energy, material, etc.) would be a property of the Matter and then inherited by the System or Component. If the System’s composition is software, then it would inherent software properties like SLOC or language, but not Mass.

According to your diagram, System and Flow may be simple (not further decomposable) or complex (composed of other similar instances). But, I don’t see anyway to indicate what basic elements (matter, data, or both) are used to construct a System or Flow.

So, I propose Element as a new concept that can be used to define the construction of Systems and the payload or content of Flows. Element could represent physical (Matter, Energy, etc.) and logical (Data, rules, instructions, procedures, knowledge, etc.) substances. This concept coupled with one for Implementation as I mentioned above are important because they permit contemplating and analyzing a System that might be realized in several alternative ways. Perhaps the Compound concept may need to defined common (hardware, software, firmware, and people-ware) or specialized compounds of Elements. In the diagram I’ve added Element as a component of an Entity.

Behavioral function (Action) and Environment

Rename the Behavioral function (alias: function, activity) item in the dictionary and the Function/Action item on the diagram to Action. I recommend Action since it is consistent with the active words like transformation that are used in the definition and is used in the OMG Action Semantics spec. Also consider modifying the diagram or the definition to reconcile the part of the definition that talks about transformations (or Actions) that the Environment can perform. The diagram does not show this, so one way to resolve this difference is to show Environment as a subclass of System. This approach would also allow the Environment to have Ports which is where it can interact with and exchange Flows with Systems.

Also, the diagram does not show any relationships with the Environment except that it may contain Entities. I suggest that this relationship be removed and replace with one that shows that a System may have ONE Environment. Given these two new relationships for Environment, a System has an Environment that itself may contain other Systems (see related mods on your diagram). So if the Universe is considered a System, then it has or provides just one Environment (Space) and could be decomposed in a manner something like the following:

Universe	>	Space	>	Star (Sun)	>	Solar System	>	Planets (Earth)	>	Atmosphere
System	>	Environment	>	System	>	Environment	>	System	>	Environment

Miscellaneous

What is the significance or purpose of including Structure, Behavior, Composition and Boundary in the dictionary since this they are not shown in the diagram? Are these (excluding Boundary) needed to define the major categories of the SE DSIG requirements specification?

Packages (as shown in the ‘high-level’ or major SE chart showing)

I propose that the package (or module) named Property be changed to Infrastructure (if semantically aligned with this part of the UML 2.0 architecture) and the package named Verification be deleted. Also, consider adding a package for Elements. Similar changes should be made to the corresponding sections in the SE Requirements specification.

My suggestions for renaming terms, package assignments and reference numbers are shown in the following table.

ID	Sandy’s Proposed Name	Dwayne’s Revision
	Infrastructure Package
1	Entity
2	Property_Relationship	Relationship
3	Property
4	Property value	Value
5 *	Time	Instant
6 *		Place
7	Composition
	Structure Package
8	Environment
9	System
10	Physical connection	Connection
11		Port
12	Component
	Behavior Package
13	I/O Entity	Flow
14	Behavioral function (alias: function, activity)	Action
15	Control flow	Control
	Requirement Package
16	Domain of Interest
17	Stakeholder
18	View
19	Need
20	Requirement
21	Verification result
22 *	Validation result
	Element Package
23		Element
24 *		Matter
25 *	Energy
26 *	Mass
27 *	Data

* Concepts not shown on the corresponding diagram