From: Hardy, Dwayne, CTR, OSD-ATL [mailto:Dwayne.Hardy@osd.mil]
Sent: Friday, September 06, 2002 2:12 PM
Cc: 'Friedenthal, Sanford'; 'email@example.com'; 'Michael.L.Dickerson@jpl.nasa.gov'; Rick Steiner; Regina Gonzales; Peter Denno; Julian Johnson; Joseph Skipper; James D. Baker; James A U'Ren; Harold P Frisch; Harald Eisenmann; Erik Herzog; Hardy, Dwayne, CTR, OSD-ATL; Roger Burkhart; Stan Hendryx; Moore, Alan
Subject: RE: Concept Model
Many apologies for the duplicate and incomplete messages from me on Tuesday this week. I was working remotely and it seems that there were gremlins at work in my mail system that caused erratic transmissions. So I decided to wait till I got back into the office to clear things up.
(and a duplicate) message that I sent contained my comments on
The second (but incomplete) message was in response to a follow-up message that I got from Dave. Since that one got sent before it was complete, please discard it and consider the following my complete response.
I well understand the difficulties in coordinating a conceptual exercise such as we have all undertaken and the need for sound points of reference such as baselines. However, my experience also suggests that it is sometimes useful to come at a problem from multiple perspectives to get a better understanding of it. I thought that this is what Sandy was doing and I wanted to take the time (several weeks as it turned out) to thoughtfully consider and comment on what he proposed. His approach seems to be the prudent way to get a kind of look-ahead view of how the model might appear after the 200 or so comments (that I'm aware of against the last version) are incorporated.
that the purpose of
In the interim since my previous version of this message I have taken the time to look forward by quickly reviewing the new version (7). I see that some of my concerns were resolved and some were not. I'll submit more detailed comments when time permits, but I can tell you now that most of my comments will ultimately relate to changes desired for a simpler model and one that better aligns (or identifies commonalities) with software community concepts (i.e., as expressed in UML 2.0).
community's perspective, the greatest value of the SE DSIG effort is the
opportunity to identify similarities between system and software engineering
practices, rather than the differences. In fact, the U.S. DoD is in the process of consolidating the advocacy
functions (both in my office) for system and software engineering practices
because numerous studies have shown that many of our software problems really
turn out to be deficiencies in the application of system engineering practices
to software-intensive projects, and we have very few projects that do not fall
into this category. So, I would advocate that we in the
Again thanks for your patience and indulgence.
Open Systems Joint Task Force
DoD Director, Interoperability
Office of the Secretary of Defense
Arlington, VA 22202
703-602-0851, ext 122
From: doliver106 [mailto:firstname.lastname@example.org]
To: Dwayne Hardy
Subject: Concept Model
The model that
I want to make sure that you know what baseline we are using because comments against a different model, not the baseline, dont apply to the baseline. Volunteer effort is precisous and we need to be able to use it efficiently.
Your comments to date have been very helpful as has been your consolidation of issues for us. Many thanks.
From: Hardy, Dwayne, CTR, OSD-ATL [mailto:Dwayne.Hardy@osd.mil]
To: 'Friedenthal, Sanford'; 'email@example.com'; 'Michael.L.Dickerson@jpl.nasa.gov'
Cc: Rick Steiner; Regina Gonzales; Peter Denno; Julian Johnson; Joseph Skipper; James D. Baker; James A U'Ren; Harold P Frisch; Harald Eisenmann; Erik Herzog; Roger Burkhart; Stan Hendryx; Moore, Alan
Subject: RE: Proposed Update to SE Conceptual Model Draft 6 & Definitions
Sandy and others,
These comments are on the version of the SE conceptual model
(terms, definitions and supporting diagram) that
First, I agree with
Most of my comments are attached in the Word document in a
narrative form and focused on the 'system' (or structural) aspects of the
model. I think that these concepts are
central to most SE considerations and therefore critical to the definition and
evolution of the conceptual model. Thisn document also includes a table that shows my
recommended name changes, package assignments and reference numbers. I've incorporated my suggestions into a
modified version of
I regret sending so much at once, but several recommendations are interrelated or co-dependant. Hopefully, my narrative will provide sufficient rationale and insight into my perspectives.
P.S. Most of these comments were prepared before Dave distributed his recent version and I did not attempt address it since I have not adequately reviewed.
From: Friedenthal, Sanford [mailto:firstname.lastname@example.org]
To: 'email@example.com'; 'Michael.L.Dickerson@jpl.nasa.gov'
Cc: Rick Steiner; Regina Gonzales; Peter Denno; Julian Johnson; Joseph Skipper; James D. Baker; James A U'Ren; Harold P Frisch; Harald Eisenmann; Erik Herzog; Dwayne Hardy; Roger Burkhart; Stan Hendryx; Moore, Alan
Subject: Proposed Update to SE Conceptual Model Draft 6 & Definitions
The following is a response to an action item from the SE
Conceptual Model review at INCOSE 2002 on
The attachments include:
a)The proposed update to the model (Draft 6), which I presented at the INCOSE review, is included as slide 2 in the power point charts. (I made a few minor changes including adding component back in, and changing parameter back to property).
b)Slide 3 in the power point charts reflect a possible modular packaging of the SE Technical Concepts in terms of behavior, structure, properties, requirements, and verification. The lines between the packages represent dependencies. We had briefly discussed this at the meeting, and Alan Moore had initiated a similar concept, although a different packaging. I have not tried to partition the proposed updated model explicitly into these packages, but this should be fairly straightforward if we proceed down this path.
c)The proposed updates to the semantic dictionary for Draft 6 are included in the excel spreadsheet. I have shown the mapping between the current terms and definitions from Draft 6 in the left 2 columns, and the proposed terms and definitions in the right two columns.
I have also included a brief text summary of the model below to aid in its interpretation, but the semantic dictionary includes the more complete set of definitions to address your original model. I hope this is helpful.
OMG SE DSIG Chair
Lockheed Martin Corporation
BRIEF SUMMARY OF THE PROPOSED UPDATED SE CONCEPTUAL MODEL
Note: Refer to the more complete set of definitions in the attached proposed update to the semantic dictionary.
The "Domain of Interest" is the set of entities which are of interest to the system modeler.(Replaces Universe)
A "View" is the relationship between a subset of the entities in the domain of interest. (Replaces System View)
"Domain of interest" is composed of "Entities"
"Entities" are a generalization which represents anything of interest with a defined set of properties (Replaces SE Thing)
"Entity" can be an "I/O entity" or a "System" (or component)
"I/O entities" represent an entity which flows between systems/components, and may include signals, mass flow, etc
"System" represents an entity, which is a composite of components, which interact with one another to exhibit observable properties and behaviors.
There may be multiple levels of "System" (i.e. "System" composed of
Systems are composed of "Components"
"Components" are physically replaceable part of a system, which are implemented in hardware, software, data, personnel/user/operator, procedure, facility, etc.
"Environment" os 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.
"Functions/action" is a transformation of input/ouptut entities that a system/component or the environment perform.
"Control Flow" emab;e/disable functions resulting from triggering events and conditions.
"Physical Connections" or "Ports" are the physical surfaces which connects systems/components to one another (including the physical environment) to enable the flow of inputs and outputs.
A "Boundary" is the set of all physical connections (I.e. ports) which separates a system and/or component from its external environment.
"I/O entities" flow in/our of "Ports"
" Properties" are measurable characteristics, or characteristics which can be derived from other measurable characteristics.
"Properties" have "Values", which may be continuous or discrete and deterministic or probabilistic.
"Property relationships" define relationships 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)
Time is a "Property", which all other properties are dependent on. Time can be represented by continuous or discrete values as can all other properties. (Not shown)
Time has value. (not shown)
"Requirement" is 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).
"Verification results" is an assessment of compliance with requirements, by comparing requirements and observations using a prescribed method of observation.
"Need" is a type of requirement, which is intended to address a problem or inadequacy.as preceived by a stakeholder.
"Stakeholders" are 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.
*Other concepts in the SE UML Requirements Analysis V0.3 include problem, logical/physical entities, nodes/distribution of resources, geometric relationships, problem, state, event, failure, etc, but are not included here to focus primarily on those concepts that we have already been discussing.