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