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