-----Original Message-----
From:
Sent:
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
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
sanford.friedenthal@lmco.com
(703) 293-5557
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
"System")
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.