-----Original Message-----
From: Hardy, Dwayne, CTR, OSD-ATL [mailto:Dwayne.Hardy@osd.mil]
Sent: Friday, September 06, 2002 2:12 PM
To: 'doliver106'
Cc: 'Friedenthal, Sanford'; 'doliver106@cox.net'; '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.


The first (and a duplicate) message that I sent contained my comments on Sandy's conceptual model that he distributed 13 August. 


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.


You state that the purpose of Sandy's model was a way a stating his issues.  Well, then I suppose I have many of the same issues since I more readily identify with the concepts in his model than those in version 6.  My comments on his model pertain to subtle, rather than the fundamental differences that I express previously on version 6.  In fact, after recently looking back at our work, it seems to me that Sandy's version is closer to the one Julian diagram during the Anaheim meeting than version 6.


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).


From my 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 SE DSIG evaluate our conceptual model work in part based on how well it permits inspection by both communities so that we will have a better chance of influencing the work that results in UML 2.0.  IMHO, Sandy's version is closer to that end than either version 6 or 7.





Again thanks for your patience and indulgence.





Dwayne Hardy

Architecture Staff

Open Systems Joint Task Force

DoD Director, Interoperability

Office of the Secretary of Defense

1931 Jefferson Davis Highway

Crystal Mall 3, Suite 104

Arlington, VA 22202

703-602-0851, ext 122




-----Original Message-----
From: doliver106 [mailto:doliver106@cox.net]
Tuesday, September 03, 2002 3:29 PM
To: Dwayne Hardy
Subject: Concept Model




The model that Sandy distributed was presented by him to the team at the INCOSE 2002 meeting only as backup to aid in understanding his issues. Twas clearly state3d at the meeting and accepted. We took the time to go through each of his issues at the meeting and to listen to his model ideas twice. The decisions madeat INCOSE 2002 on his issues and all the others that we have recorded have been incorporated in draft 7 of the concept model that has been distributed to you. this is our current baseline. Our process, and Sandy has agreed to this in detail, is to work from interpretable issues against a baseline. that baseline is draft 7. We need to get through all the issues yet unconsideered and we need any other issues that people find with draft 7 to apply against draft 7.


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.




-----Original Message-----

From: Hardy, Dwayne, CTR, OSD-ATL [mailto:Dwayne.Hardy@osd.mil]

Sent: Tuesday, September 03, 2002 3:18 PM

To: 'Friedenthal, Sanford'; 'doliver106@cox.net'; '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 Sandy distributed on 13 August.


First, I agree with Sandy's view that this version of the SE conceptual model is somewhat simpler and more intuitive than previous versions. However, I would like to propose a few changes that I believe will better align this version of the model with SE concepts that I am familiar and tighten up its semantics.


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 Sandy's diagrams that is attached


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.


-----Original Message-----

From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com]

Sent: Tuesday, August 13, 2002 8:57 PM

To: 'doliver106@cox.net'; '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



Dave, Mike


The following is a response to an action item from the SE Conceptual Model review at INCOSE 2002 on August 1, 2002. The action was to provide definitions corresponding to the proposed update to the SE Conceptual Model draft 6 that I presented at the review. This update is intended to address the general and specific set of issues which I submitted as part of Dwayne Hardy's input to the issue log from the OMG SE DSIG meeting. This model attempts to simplify and refine some of the concepts in the current model (Draft 6).  Other concepts, along with their definitions, which are included in the SE UML Requirements Analysis *, are not included here, so as to focus primarily on those concepts that we have already been discussing. It may be appropriate to introduce some of the additional concepts after we get further along.


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.






Sanford Friedenthal


Lockheed Martin Corporation


(703) 293-5557







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.