[SysML Forum] Source for Terminology

[Alan]

In systems engineering, we often use the following terms to talk
about how we go about it or implement it: methodology, method,
technique, process, tool, modeling notation. However, we often mean
different things. For example, someone may talk about the [general]
"object-oriented" methodology, or SysML notation, or Structured
Analysis and Design Technique, or the CMMI process.

Does anyone know of a good source for precise definitions for
these terms, or similar, in an SE or MBSE context?

Thanks, Alan

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

[Pete Kirkham]

Apart from 'object-oriented', which has no universally agreed meaning
[1], and many associated methodologies, the authoritative sources can
be usually be found referenced from the respective wikipedia articles.
Wikipedia isn't itself authoritative, but its technical articles are
usually a good starting point. C2, the original software wiki, is less
formal.

[1] http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

[Alberto Sampaio]

Method or technique are used more or less indistinctly, and are used as a way of doing something, but in a restricted scope.

Methodology is used at an all lifecycle level approach, and, possibly, indicating which methods/techniques should be used. Example: RUP. Methodology should be well defined. If it is something vague, it is better to use the term "lifecycle model."

CMMI is a process evaluation model. When software agile methodologies appeared, as it was the case of SCRUM, in the 90's many of its defenders spoke of CMM as a methodology. It was incorrect. Unfortunately some people still do that!

You can consult CMMI glossary.

regards
alberto

[Robert Halligan]

Hello Alan

You will find about 3000 definitions, and growing, of mainly SE terms at:
http://segoldmine.ppi-int.com/

The definitions are searchable, as is an archive of a couple of thousand
(also growing) mainly SE-related documents, with extensive searchable
metadata. This is a free service to the engineering community.

Cheers
Robert

[David Oliver]

Robert,

The problem with a set of definitions is to ensure that they are consistent and non-circular. Each word, once defined, is special for that particular discipline. Thus each special word must be defined before it can be used in the definition of another special word. they are ordered and have relationships. there is an ISO standard for this. It was followed in AP233 and a semantic dictionary and accompanying information model were created. these were published 0n the INCOSE web site and the AP233 standard and in part in the handbook of Systems Engineering and Management edited by Andy Sage, chapter 33. They constitute a crude ontology.

Most of the definitions that we have in our standards do not meet the modest ISO standard for definitions. They can support an intuitive understanding, but not a language or information transfer model or a tool.

Dave Oliver

[Michael Jesse Chonoles]

Dave (are you the Dave, that I've worked with....) I've always thought that correct definitions are exceptionally important, but,I find that the restriction on circularity as overly restrictive. There are circular or self-defining definitions that are completely acceptable -- for example, consider the recursive definition of factorial. Unfortunately, I've not been able to reformulate the restriction Michael --- On Fri, 5/21/10, David Oliver <doli...@tampabay.rr.com> wrote:

> To unsubscribe from this group, send email to sysmlforum+unsub...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en. > -- You received this message because you are subscribed to the Google Groups "SysML Forum" group. To post to this group, send email to sysml...@googlegroups.com.

To unsubscribe from this group, send email to sysmlforum+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

[Jack Ring]

Please give an example. The dozen definitions of factorial I have found do not involve circularity.

Perhaps we should start with the definition of circular descriptions. 

The winner so far can be found in the U.S Tax Code --- "The Internal Revenue Code Title 26 offers perhaps the cleverest example of circumlocution ever created. Begin withtaxable income which is defined as gross income or adjusted gross income which is defined as all income from whatever source derived. However, understanding that taxable income is gross income or adjusted gross incomeearned in a taxable year it is necessary to define taxable year which is a taxpayers annual accounting period. Ataxpayer is defined as anyone subject to any tax under the revenue laws. Who is subject to the tax? In terms of revenue laws one would have to look at the sections that inform where a tax has been imposed. The beginning of Title 26 begins with a tax imposed which imposes a tax on...you guessed it taxable income."  A horse is a horse, of course, of course.

[Michael Jesse Chonoles]

A typical recursive definition of factorial goes as follows:

!(0)=1
!(n)=n*!(n-1)

A circular definition of a term is one that directly or indirectly depends on itself.

---

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM

[Jack Ring]

Seems to me he only ambiguity here is the meaning of the symbol n. Unless n signifies factorial then there is nothing circular in this definition of 'factorial'  

Procedural, yes, circular, no.

Make sense?

Good thing you didn't say FRACTAL

Jack Ring

[Michael Jesse Chonoles]

Yes, it is procedural, however, the definition of Factorial (that is, !)

points the reader to the definition of Factorial, which make it depend on itself, i.e., circular.  However, as you say, this case is acceptable.

Unless you think that circular is equivalent to non-acceptable?

Michael

---

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com

Sent: Sat, May 22, 2010 11:44:54 PM

[Pete Kirkham]

It's a recursive definition that doesn't define n! in terms of n!, but in terms of (n-1)!

So it's a spiral rather than a circle - you don't go round forever, but hit the base value.

[Jack Ring]

Good. 

Although many SE practitioners are aware of iteration they do not remember that successful iteration involves a convergence method and stopping rule. Some iterations do not converge. Circular definitions of words are like this. The definition of Factorial, as you say, is not circular. It this procedure converges on a result.  

OBTW, one should also state that it is valid only for n equal to or greater than 1 else all results = zero. FWIW, I always thought that n! - n(n+1).

Jack Ring

[Michael Jesse Chonoles]

Jack,
I'm afraid it appears that you are saying,

A circular definition is refers to itself and is not good, unless it has a convergence method/stopping rule, and then we don't call it circular.

I have no real problem with this, though I wonder if there are other exceptions.

How about this
A directory can contain files and other directories.

I think this is both circular and acceptable.

Michael

---

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com

Sent: Mon, May 24, 2010 11:02:56 PM

[Jack Ring]

I am not saying a circular definition refers to itself. I am saying that a statement that is claimed to be a definition but uses terms that are defined using the originating term does not define the original term. 

I see a distinction between a description of X vs. a definition of X. 

In all cases goodness is in the eye of the beer holder. 

cheers,

Jack Ring

[asage]

The meaning of the term “complexity” is context dependent. If you look, for example, at the 2^nd Edition of the Handbook of Systems Engineering and Management That Bill Rouse and I edited in 2009, you will find the term “complexity” and “complex adaptive systems” appearing 11 times in the index. I don’t believe you can have a single definition of this term. The term “complex adaptive system” is defined by Sarah Sheard on page 1295.  There are, on the other hand, three “levels of complexity” defined on page 126.  I don’t see how it could be any different.

 

Andy Sage

 

From: Scott Jackson [mailto:jacke...@cox.net]
Sent: Thursday, May 27, 2010 8:34 PM
To: David W Oliver; Jack Ring; Jack Ring; INCOSE Fellows Discussion; David M. Oliver work; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

Is there an approved definition of the word "complexity."  Most of the def er from three problems:

 

(1) they are intuitive instead of definitive.

 

(2) they focus on the effects of complexity (e.g. the butterfly effect) and not characteristics of complex systems

 

(3) they focus on human perceptions rather than scientific qualities, for example, anything hard to understand is complex (wrong).

 

I have f and documents that discuss complexity at length without ever defining it.  The Handbook is one of those documents.

 

If you can provide such a definition, please give me a reference.

 

Scott

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

From: .0pt;font-family:"Arial","sans-serif"'> David W Oliver

To: Jack Ring ; Jack Ring ; INCOSE Fellows Discussion ; David M. Oliver work ; sysml...@googlegroups.com

Sent: Thursday, May 27, 2010 5:09 PM

Subject: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

 

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

From: Michael Jesse Chonoles < oNormal>To: sysml...@googlegroups.com

Sent: Saturday, May 22, 2010 10:38 PM

Subject: Re: [SysML Forum] Source for Terminology

 

A typical recursive definition of factorial goes as follows:

!(0) r>A circular definition of a term is one that directly or indirectly depends on itself.

 

---

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM
Subject: Re: [SysML Forum] Source for Terminology

Please give an example. The dozen definitions of factorial I have found do not involve circularity.

Perhaps we should start with the definition of circular descriptions. 

 

The winner so far can be found in the U.S Tax Code --- "The Internal Revenue Code Title 26 offers perhaps the cleverest example of circumlocution ever created. Begin withtaxable income which is defined as gross income or adjusted gross income which is defined as all income from whatever source derived. However, understanding that taxable income is gross income or adjusted gross incomeearned in a taxable year it is necessary to define taxable year which is a taxpayers annual accounting period. Ataxpayer is defined as anyone subject to  laws. Who is subject to the tax? In terms of revenue laws one would have to look at the sections that inform where a tax has been imposed. The beginning of Title 26 begins with a tax imposed which imposes a tax on...you guessed it taxable income."  A horse is a horse, of course, of course.

 

On May 22, 2010, at 6:18 AM, Michael Jesse Chonoles wrote:

Dave (are you the Dave, that I've worked with....)

I've always thought that correct definitions are exceptionally important, but,I find that the restriction on circularity as overly restrictive. There are circular or self-defining definitions that -- for example, consider the recursive definition of factorial.

Unfortunately, I've not been able to reformulate the restriction Michael --- On Fri, 5/21/10, David Oliver <doli...@tampabay.rr.com> wrote:

From: David Oliver <doli...@tampabay.rr.com> Subject: Re: [SysML Forum] Source for Terminology To: sysml...@googlegroups.com, "Robert Halligan" <rhal...@ppi-int.com>, "Jack Ring" <jr...@amug.org> Date: Friday, May 21, 2010, 6:31 AM

Robert, The problem w is to ensure that they are consistent and non-circular. Each word, once defined, is special for that particular discipline. Thus each special word must be defined before it can be used in the definition of another special word. they are ordered and have relationships. there is an ISO standard for this. It was followed in AP233 and a semantic dictionary and accompanying information model were created. these were published 0n the INCOSE web site and the AP233 standard and in part in the handbook of Systems Engineering and Management edited by Andy Sage, chapter 33. They constitute a crude ontology.

Most of the definitions that we have in our standards do not meet the modest ISO standard for definitions. They can support an intuitive understanding, but not a language or information transfer model or a tool. Dave Oliver On May 21, 2010, at 12:37 AM, Robert Halligan wrote: > Hello Alan >

> You will find about 3000 definitions, and growing, of mainly href="http://segoldmine.ppi-int.com/" target="_blank">http://segoldmine.ppi-int.com/

> > The definitions are searchable, as is an archive of a couple of thousand > (also growing) mainly SE-related documents, with extensive searchable > metadata. This is a free service to the engineering community. > > Cheers > Robert > > > On 19/05/10 10:26 PM, "Alan" <jalan...@verizon.net> wrote: > >>   In systems engineering, we often use the following terms to talk >> about how we go about it or implement it: methodology, method, >> technique, process, tool, modeling notation.  However, we often mean >> different things.  For example, someone may talk about the [general] >> "object-oriented" methodology, or SysML notation, or Structured >> Analysis and Design Technique, or the CMMI process. >>

>>&nb yone know of a good source for precise definitions for

>> these terms, or similar, in an SE or MBSE context? >> >>           Thanks, Alan > > > -- > You received this message because you are subscribed to the Google Groups "SysML Forum" group. > To post to this group, send email to sysml...@googlegroups.com.

> To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en. > -- You received this message because you are subscribed to the Google Groups "SysML Forum" group. To post to this group, send email to sysml...@googlegroups.com. To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.

For more options, visi http://groups.google.com/group/sysmlforum?hl=en" target="_blank">http://groups.google.com/group/sysmlforum?hl=en.

 

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

 

--
You received this message because you are subscribed to the Google Gr ot; group.

To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

-----

For assistance with this reflector, send an email to lists...@incose.org

with HELP in the subject line.

-----

For assistance with this reflector, send an email to lists...@incose.org

with HELP in the subject line.

[Robert Halligan]

Hello Dave

I share your view. My own philosophy regarding definitions can be summarized as:

a. never use terms inconsistently with Oxford and Mirriam Webster’s dictionaries
b. subject to a., use and define terms for engineering use within a group with greater precision and/or with only one of several meanings
d. establish and maintain a lexicon for use within the group (Division, IPT, project, community, etc.)
e. include the lexicon in induction training of new staff.

The most basic of stuff, but you would be surprised at how much loss is caused through departure from these very simple principles (or maybe you wouldn’t be)

Regards
Robert Halligan

[Philip Oakley]

Surely, mathematically speaking (that is 'within a formalism'), there is nothing that is per se 'complex'. Rather there are axioms and the consequents. One follows from the other, sometimes reversibly (you can swap certain axioms and consequents and get the same overall structure).

 

Natural systems are designed by 'ameoba', so why is designing human systems apparently so complex.  I would suggest that the problem is the person in the mirror - Mr/Mrs/Ms Homo Sapiens, with our bounded rationality and many other limitations. With a few notable exceptions, most Human Factors considerations consider only the 'worker bees' and their inability to follow orders, rather than considering how Human factors applies to the design factory, and then re-applies that to the very systems engineering that created it [Is your local design group actually designed using rigourous systems engineering principles?].

 

So, in answer to Scott, I think that there are no true definitions of complexity because they all attempt to present the problem as being 'out there', rather than 'in here', thus passing the buck. 

 

Just my two pence worth.

 

Philip

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[David W Oliver]

Robert,

 

Amen.  Dave

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

From: Robert Halligan

To: David Oliver ; sysml...@googlegroups.com ; Jack Ring

Sent: Friday, May 28, 2010 12:25 AM

Subject: Re: [SysML Forum] Source for Terminology

[David W Oliver]

Sarah,

 

I believe  that It is essential to expect and support consistent usage of words from other people, especially in a new field. There are OMG working groups that are developing such uniform usage in several new fields. Consistency reduces ambiguity and renders databases and publications intelligible. In 1992 the organization Engineering Computer Based Systems met with representatives from many nations. As experienced engineers began describing the processes they used, all speaking in English, it became apparent that the words used had different meanings for everyone. The first day was a wreck for information transfer. At that time Object Modeling Technique, OMT, a precursor of UML, was in use for data base definition as well as for programing. On the second day we began transcribng the ppt charts into simple information models using entities, aggregation, generalization/specialization, and relationships - just four simple semantic principles. As we proceeded we resolved the questions of ambiguity as we went by quickly providing a graphic view of what was being said in vernacular text. Misunderstandings were exposed quickly and eliminated.

 

These are the same basic elements that are the basis of the ISO standards for definitions. They are inherent in the EXPRESS language that has been used to write ISO standards since the 1970's. The graphic model is not enough; it must be accompanied by text that records definitions in english used in accord with an identified dictionary and preferably with examples. This procedure was used in the AP233 and SysML developments and was esswential for their success.

 

INCOSE has a serious problem of never having adopted a model based procedure of this kind - hopefully they may adopt one superior. Most of the conversations, such as this one on complexity, die because of ambiguity and sophistry.  The INCOSE standards have never adopted the use of models; rather they rely on text and pictures. One generates agreement through ambiguity. This does not happen in other engineering disciplines in which mass, inductance, a phase diagram have well defined meanings. The authority for definitions is the group using them. In some cases overworked words like "state" may need an expansion of the single word with designators so that it may hold several definitions. It is not hard work. It is disciplined work. Definitions are not supposed to be perfect; they are useful in a particular domain. This is also true of decompositions and taxonomies. There is no one that is correct. They can be useful if handled with discipline.

 

It is important for INCOSE and the Fellows to come to grips with the need for definitions and the standards for writing them in text and models. An Ontology would be more rigorous.

 

Dave Oliver

 

 

 

 

 

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

From: Sarah Sheard

To: 'Scott Jackson' ; 'David W Oliver' ; 'Jack Ring' ; 'Jack Ring' ; 'INCOSE Fellows Discussion' ; 'David M. Oliver work' ; sysml...@googlegroups.com

Sent: Friday, May 28, 2010 9:32 AM

Subject: RE: [fellows discuss] Re: [SysML Forum] Source for Terminology

Hello, Scott,

 

You have been very active lately, nibbling around the edges of this “what is complexity” cookie and making some important inroads into the field.

 

Regarding your question of complexity definition, my question is what will you accomplish by coming up with the perfect definition?  I wager that even if you do, other documents will remain out there with “wrong” definitions. And who judges a definition as right or wrong, or for that matter who is an “approval authority” for definitions?

 

I guess what I’m trying to say is that the perfect system can only be designed if one understands well its intended use. I see your criteria for what you’re looking for (definitive rather than intuitive, focuses on complex system characteristics rather than on what you call the effects of complexity, and focuses on scientific qualities rather than human perceptions.) With those criteria and alternatives from a quick Google search and a bookcase book-index-search, one can perform a trade study. Even a simple scheme -- 9 pts for highly meets criteria, 3 points for moderately and 1 point for slightly, for example --should allow you to throw out all but a few definitions, which then can be combined.

 

But an important question is *why* are those criteria important to you? What do you plan to do with a perfect definition? Write a paper on it? Put it on a web site? Make everyone stop using all other definitions? (I just listened to a self-help discussion where the speaker basically urges one to go beyond one’s comfort zone in order to take advantages of “life’s complexity”...I doubt this speaker is reading systems engineering standards...)

 

A well-expressed intended use should help you improve your criteria. Then the above trade study should give you a close-to-perfect definition for your use.

 

It is folly to expect consistent usage of words from other people, especially in a new field.

 

Sarah Sheard

---

From: Scott Jackson [mailto:jacke...@cox.net]
Sent: Thursday, May 27, 2010 8:34 PM
To: David W Oliver; Jack Ring; Jack Ring; INCOSE Fellows Discussion; David M. Oliver work; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

Is there an approved definition of the word "complexity."  Most of the definitions I have seen suffer from three problems:

 

(1) they are intuitive instead of definitive.

 

(2) they focus on the effects of complexity (e.g. the butterfly effect) and not characteristics of complex systems

 

(3) they focus on human perceptions rather than scientific qualities, for example, anything hard to understand is complex (wrong).

 

I have found many INCOSE articles and documents that discuss complexity at length without ever defining it.  The Handbook is one of those documents.

 

If you can provide such a definition, please give me a reference.

 

Scott

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

From: David W Oliver

To: Jack Ring ; Jack Ring ; INCOSE Fellows Discussion ; David M. Oliver work ; sysml...@googlegroups.com

Sent: Thursday, May 27, 2010 5:09 PM

Subject: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

 

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

From: Michael Jesse Chonoles

To: sysml...@googlegroups.com

Sent: Saturday, May 22, 2010 10:38 PM

> To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en. > -- You received this message because you are subscribed to the Google Groups "SysML Forum" group. To post to this group, send email to sysml...@googlegroups.com. To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

 

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

-----

For assistance with this reflector, send an email to lists...@incose.org

with HELP in the subject line.

[Patrice Micouin]

I agree with Scott when he asks for an "approved" definition of the word "complexity" and with Dave when he states that the systems engineering community has to agree on common definitions for the main constructs our discipline relies on (a community needs to share a common living language to live and to grow). Relativism does not allow such positive evolution.

I am also not sure that references to Oxford and Mirriam Webster�s dictionaries are mandatory: with common sense definitions, only common sense theories may be built!

As said Mario A. Bunge, definitions deal with constructs (concepts, predicates, propositions, ..), not with truth, and shall provide an identity between a "definiens" and a "definiendum" in the context of a body of knowledge (for instance in the context of the number theory, "one"=_def "successor of zero" is a definition, this definition is not true, but the statement �one is the successor of zero" is a true statement by definition). Homonyms are allowed.

So, in the system theory (man-made systems theory) addressed by the systems engineering community, the concept of "complexity" should be defined, if necessary, in a consistent way with the definition of the predicate "complex" that applies to "systems", for instance.

Such a definition is to be built using concepts previously defined in the same theory.
All of these terms should be defined with the same rigor and should not introduce cycles
Example :
�Process"=_def "series of state changes in a system�,
�Complex system"=_def "system which is the place of complex processes�,
�Complex process"=_def "process which outcomes are uncertain�,
�Complexity"=_def "measure of the uncertainty in achieving a system purpose�).
Other definition: �Complexity"=_def "measure associated to the composition and the structure of system�.
(Note that these two definitions of complexity are homonymous).
�

Other scientific or technical fields may define, in relevant ways, the same words with other "definienda", for instance with respect to concepts coming from Kolmogorv computation theory, Shannon information theory, Mandelbrot fractal theory or Thom catastrophe theory or Chaos theory and other exciting theories.

Importing such concepts in the system engineering area may be really beneficial.
However, despite their very suggestion power, wild translations of concepts coming from other fields will generate only confusion.

The question is twofold
1/ the imported concept is it truly applicable to the systems engineering area? For instance, the Shannon complexity concept is it really relevant in our area?
2/ what kind of problems this importation allows to solve? For instance, if the McCabe software cyclomatic complexity is imported, does it permit to address a particular system engineering problem?

This is same when we consider the complexity definition provided by Nam P. Suh in his book "Complexity" (Oxford Press, 2005):
(�Complexity"=_def "measure of uncertainty in understanding what it is we want to know or in achieving a functional requirement�).
I utilized this definition due to Suh� in� a chapter untitled "Emergence and complexity of Systems of systems"
in the book� "Systems of� systems " edited by� D. Luzeaux and� J-R Ruault this year (Wiley & ISTE, 2010).
In my opinion, this definition has an real epistemological interest.

Patrice Micouin
David W Oliver a �crit�:

Sarah,

�

I believe� that It is�essential to expect and support consistent usage of words from other people, especially in a new field. There are OMG working groups that are developing such uniform usage in several new fields. Consistency reduces ambiguity and renders databases and publications intelligible. In 1992 the organization Engineering Computer Based Systems met with representatives from many nations. As experienced engineers began describing the processes they used, all speaking in English, it became apparent that the words used had different meanings for everyone. The first day was a wreck for information transfer. At that time Object Modeling Technique, OMT, a precursor of UML, was in use for data base definition as well as for programing. On the second day we began transcribng the ppt charts into simple information models using entities, aggregation, generalization/specialization, and relationships - just�four simple semantic principles. As we proceeded we resolved the questions of ambiguity as we went by quickly providing a graphic view of what was being said in vernacular text. Misunderstandings were exposed quickly and eliminated.

�

These are the same basic elements that are the basis of the ISO standards for definitions. They are inherent in the EXPRESS language that has been used to write ISO standards since the 1970's. The graphic model is not enough; it must be accompanied by text that records definitions in english used in accord with an identified dictionary and preferably with examples. This procedure was used in the AP233 and SysML developments and was esswential for their success.

�

INCOSE has a serious problem of never having adopted a model based procedure of this kind - hopefully they may adopt one superior. Most of the conversations, such as this one on complexity, die because of ambiguity and sophistry. �The INCOSE standards have never adopted the use of models; rather they rely on text and pictures. One generates agreement through ambiguity. This does not happen in other engineering disciplines in which mass, inductance, a phase diagram have well defined meanings. The authority for definitions is the group using them. In some cases overworked words like "state" may need an expansion of the single word with designators so that it may hold several definitions. It is not hard work. It is disciplined work. Definitions are not supposed to be perfect; they are useful in a particular domain. This is also true of decompositions and taxonomies. There is no one that is correct. They can be useful if handled with discipline.

�

It is important for INCOSE and the Fellows to come to grips with the need for definitions and the standards for writing them in text and models. An Ontology would be more rigorous.

�

Dave Oliver

�

�

�

�

�

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

From: Sarah Sheard

To: 'Scott Jackson' ; 'David W Oliver' ; 'Jack Ring' ; 'Jack Ring' ; 'INCOSE Fellows Discussion' ; 'David M. Oliver work' ; sysml...@googlegroups.com

Sent: Friday, May 28, 2010 9:32 AM

Subject: RE: [fellows discuss] Re: [SysML Forum] Source for Terminology

Hello, Scott,

�

You have been very active lately, nibbling around the edges of this �what is complexity� cookie and making some important inroads into the field.

�

Regarding your question of complexity definition, my question is what will you accomplish by coming up with the perfect definition?� I wager that even if you do, other documents will remain out there with �wrong� definitions. And who judges a definition as right or wrong, or for that matter who is an �approval authority� for definitions?

�

I guess what I�m trying to say is that the perfect system can only be designed if one understands well its intended use. I see your criteria for what you�re looking for (definitive rather than intuitive, focuses on complex system characteristics rather than on what you call the effects of complexity, and focuses on scientific qualities rather than human perceptions.) With those criteria and alternatives from a quick Google search and a bookcase book-index-search, one can perform a trade study. Even a simple scheme -- 9 pts for highly meets criteria, 3 points for moderately and 1 point for slightly, for example --should allow you to throw out all but a few definitions, which then can be combined.

�

But an important question is *why* are those criteria important to you? What do you plan to do with a perfect definition? Write a paper on it? Put it on a web site? Make everyone stop using all other definitions? (I just listened to a self-help discussion where the speaker basically urges one to go beyond one�s comfort zone in order to take advantages of �life�s complexity�...I doubt this speaker is reading systems engineering standards...)

�

A well-expressed intended use should help you improve your criteria. Then the above trade study should give you a close-to-perfect definition for your use.

�

It is folly to expect consistent usage of words from other people, especially in a new field.

�

Sarah Sheard

---

From: Scott Jackson [mailto:jacke...@cox.net]
Sent: Thursday, May 27, 2010 8:34 PM
To: David W Oliver; Jack Ring; Jack Ring; INCOSE Fellows Discussion; David M. Oliver work; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

�

Is there an approved definition of the word "complexity."� Most of the definitions I have seen suffer from three problems:

�

(1) they are intuitive instead of definitive.

�

(2) they focus on the effects of complexity (e.g. the�butterfly effect)�and not characteristics of complex systems

�

(3) they focus on human perceptions rather than scientific qualities, for example, anything hard to understand is complex (wrong).

�

I have found many INCOSE articles and documents�that discuss complexity at length without ever defining it.� The Handbook is one of those documents.

�

If you can provide such a definition, please give me a reference.

�

Scott

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

From: David W Oliver

To: Jack Ring ; Jack Ring ; INCOSE Fellows Discussion ; David M. Oliver work ; sysml...@googlegroups.com

Sent: Thursday, May 27, 2010 5:09 PM

Subject: [fellows discuss] Re: [SysML Forum] Source for Terminology

�

�

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

From: Michael Jesse Chonoles

To: sysml...@googlegroups.com

Sent: Saturday, May 22, 2010 10:38 PM

Subject: Re: [SysML Forum] Source for Terminology

�

A typical recursive definition of factorial goes as follows:

!(0)=1
!(n)=n*!(n-1)

A circular definition of a term is one that directly or indirectly depends on itself.

�

---

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM
Subject: Re: [SysML Forum] Source for Terminology

Please give an example. The dozen definitions of factorial I have found do not involve circularity.

�

Perhaps we should start with the definition of circular descriptions.�

�

The winner so far can be found in the U.S Tax Code --- "The Internal Revenue Code Title 26 offers perhaps the cleverest example of circumlocution ever created. Begin withtaxable income�which is defined as�gross income�or�adjusted gross income�which is defined as all income from whatever source derived. However, understanding that�taxable income�is�gross income�or�adjusted gross incomeearned in a�taxable year�it is necessary to define�taxable year�which is a�taxpayers�annual accounting period. Ataxpayer�is defined as anyone�subject to�any tax under the revenue laws. Who is�subject to�the tax? In terms of revenue laws one would have to look at the sections that inform where a�tax�has been imposed.�The beginning of Title 26 begins with a�tax imposed�which imposes a tax on...you guessed it�taxable income."��A horse is a horse, of course, of course.

�

>>���In systems engineering, we often use the following terms to talk

>> about how we go about it or implement it: methodology, method,

>> technique, process, tool, modeling notation.� However, we often mean >> different things.� For example, someone may talk about the [general]

>> "object-oriented" methodology, or SysML notation, or Structured >> Analysis and Design Technique, or the CMMI process. >>

>>� � � Does anyone know of a good source for precise definitions for

>> these terms, or similar, in an SE or MBSE context? >>

>>� � � � ���Thanks, Alan

> > > -- > You received this message because you are subscribed to the Google Groups "SysML Forum" group. > To post to this group, send email to sysml...@googlegroups.com. > To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en. > -- You received this message because you are subscribed to the Google Groups "SysML Forum" group. To post to this group, send email to sysml...@googlegroups.com. To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

�

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

�

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

-----

For assistance with this reflector, send an email to lists...@incose.org

with HELP in the subject line.

-----
For assistance with this reflector, send an email to lists...@incose.org
with HELP in the subject line.
    

--

[David W Oliver]

Sarah,

 

My first career job work my way through college was at the US bureau of standards, first in the electrical instruments section, and subsequently in the van de graff accelerator department where we made measeurements on neutron transport in water essential for reactor design. As a GE manager in the 1970's I supported two of our research scientists in ISO work on CAD standards because we could not automate our engineering design, manufacture, quality and maintenance work on products without the ability to transfer geometric data precisely among tools. Our people invented the EXPRESS language in the 1970's to provide a single representation for the work with each discipline writing its particular concepts and their relationships in that language. This has worked. The AP 233 and SysML developments and meetings led by MDSD-WG followed those standaards principles - to remove ambiguity as it arises by creating text/model based defeinitions of the artifacts involved. It is straightforward, by disciplined work.

 

Most often in a discipline there is a well accepted set of measurement and calculation artifacts. Tool developers capture these same entities in different schemas, and those who teach process use different symbols and words for the same artifacts. It can be a tower of babel, but does not have to be.

 

If you compare the progress in systems engineering with that of chip design, manufacture, and test the results are startling. The discipline developed a design language VHDL and design rules for carrying the design into an extremely complex process of 1500 to 2000 precisely controlled steps. The software and hardware infrastructure for automating the work through the whole life cycle was developed by a number of suppliers. The march to higher and higher resolution required R&D over a fifty year period. The goals and tasks were laid out by the industry in the form of a coherent development plan.

 

First, there are always going to be potential applications of a good piece of knowledge into other arenas (in fact, this should be encouraged), and when this happens, the meanings must change.

 

 “Who are you to tell us how to define an important word like that within our own halls?

 

I personally view these two concerns as unimportant. It is the concepts that are unique, and the actuality is that many different symbols and names are used for a single concept in systems engineering. The problem for INCOSE is that it has always tolerated the redundancy in naming and representation for a single concept and held all its discussions and written all its standards in vernacular text with pictures that are ambiguous. I was in the third CMMI class taught and in the team that applied it to GE aerospace. It is not a stnadard in the sense I am discussing here. It mandates that you create a consistent and reproducible process for your work without dealing with the semantic issues I am discussing. Mass, length, time are well defined and velocity, acceleration, energy, power, etc. You can work in metric or English units and transform between them. in the current state of systems engineering the culture rejects and objects to this proven approach, thus staying with ambiguity and redundancy that inhibits both discussion and automation. If someone does not like a word or symbol they are free to use any other. in communication they need to know if others are making the sasme assumptions and if not how to transform.

 

NASA lost a Mars shot because one team used metric and another used English standards without realizing the need to transform.

 

This is not hard. We have the basis. It is detailed. It does require an INCOSE culture shift that embraces the need with urgency, and ceases objecting. The evergoing government non-standards for procurement and proposals are not helpful. It is a case of nailing down the concepts and their relationships. Information models as applied in database work are helpful and can accomplish most of what is needed. A thorough well constructed and documented ontology would be superior. More people can contribute effectively using information models because only a modest number of semantic representations are needed in the development. There are fewer people well versed in ontological languages and developments and they are likely to lack the needed systems engineering practical real life experience required.

 

Dave Oliver

 

 

 

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

From: Sarah Sheard

To: 'David W Oliver' ; 'Scott Jackson' ; 'Jack Ring' ; 'Jack Ring' ; 'INCOSE Fellows Discussion' ; 'David M. Oliver work' ; sysml...@googlegroups.com

Sent: Saturday, May 29, 2010 5:24 PM

Subject: RE: [fellows discuss] Re: [SysML Forum] Source for Terminology

David, I don’t think we’re actually as far apart as you think. I’m talking about what IS (i.e. descriptive) and you are talking about what SHOULD BE (i.e. prescriptive). You yourself made my point below about what IS...see between the ***s.

 

I agree that because this IS true, the remedy for it is to have a lot of discussions and indeed modeling, whether paper and pencil or drawing on white boards (to start; more sophisticated simulations come later), to help define the vocabulary to be used for the project.

 

I appreciate that modeling can set a standard but am less optimistic about others, particularly in different fields, picking up on the vocabulary. I don’t believe any effort will define once and for all what a word shall mean. 

 

First, there are always going to be potential applications of a good piece of knowledge into other arenas (in fact, this should be encouraged), and when this happens, the meanings must change.

 

Second, all the people who came in to the meeting with different concepts will go out of the meeting (with presumably the same concept) and back to their enclaves, where the majority of their colleagues will be in the process of using the delegate’s pre-meeting meaning of the word. The delegate saying, “Look, at this meeting we all agreed not to use the word “metric” for anything but XXX” will be met with refusals like, “Who are you to tell us how to define an important word like that within our own halls? There are 99 of us and one of you. We don’t care what some meeting you went to came up with! “

 

I agree that over time it is possible to get standards to agree on some things; CMMI and the measurement standards are two examples of rationalizing varying vocabulary between two fields that grew up differently, namely systems engineering (aerospace and defense heritage) and software (computer science heritage).

Yet by the time that agreement has happened, certainly you too agree that there is no longer a new field involved?

 

Sarah Sheard
Principal, Third Millennium Systems LLC
GWU and Stevens Institute of Technology
INCOSE Fellow and Founder's Award Recipient
(703) 757-7644...cell (703) 994-7284...sheard@3MilSys.com

---

From: David W Oliver [mailto:doliv...@cox.net]
Sent: Friday, May 28, 2010 6:09 PM
To: Sarah Sheard; 'Scott Jackson'; 'Jack Ring'; 'Jack Ring'; 'INCOSE Fellows Discussion'; 'David M. Oliver work'; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

Sarah,

 

I believe  that It is essential to expect and support consistent usage of words from other people, especially in a new field. There are OMG working groups that are developing such uniform usage in several new fields. Consistency reduces ambiguity and renders databases and publications intelligible. In 1992 the organization Engineering Computer Based Systems met with representatives from many nations. As experienced engineers began describing the processes they used, all speaking in English,

 

***it became apparent that the words used had different meanings for everyone. The first day was a wreck for information transfer.***

 

 At that time Object Modeling Technique, OMT, a precursor of UML, was in use for data base definition as well as for programing. On the second day we began transcribng the ppt charts into simple information models using entities, aggregation, generalization/specialization, and relationships - just four simple semantic principles. As we proceeded we resolved the questions of ambiguity as we went by quickly providing a graphic view of what was being said in vernacular text. Misunderstandings were exposed quickly and eliminated.

 

These are the same basic elements that are the basis of the ISO standards for definitions. They are inherent in the EXPRESS language that has been used to write ISO standards since the 1970's. The graphic model is not enough; it must be accompanied by text that records definitions in english used in accord with an identified dictionary and preferably with examples. This procedure was used in the AP233 and SysML developments and was esswential for their success.

 

INCOSE has a serious problem of never having adopted a model based procedure of this kind - hopefully they may adopt one superior. Most of the conversations, such as this one on complexity, die because of ambiguity and sophistry.  The INCOSE standards have never adopted the use of models; rather they rely on text and pictures. One generates agreement through ambiguity. This does not happen in other engineering disciplines in which mass, inductance, a phase diagram have well defined meanings. The authority for definitions is the group using them. In some cases overworked words like "state" may need an expansion of the single word with designators so that it may hold several definitions. It is not hard work. It is disciplined work. Definitions are not supposed to be perfect; they are useful in a particular domain. This is also true of decompositions and taxonomies. There is no one that is correct. They can be useful if handled with discipline.

 

It is important for INCOSE and the Fellows to come to grips with the need for definitions and the standards for writing them in text and models. An Ontology would be more rigorous.

 

Dave Oliver

 

 

-----
For assistance with this reflector, send an email to lists...@incose.org

[Kevin Durand]

Thanks Patrice,

Well done.

Thank You,

Kevin Durand
216-433-2594-office
216-225-4287-cell
Sent via BlackBerry

---

From: Patrice Micouin <patrice...@ieee.org>

Date: Sun, 30 May 2010 10:17:42 -0500

To: sysml...@googlegroups.com<sysml...@googlegroups.com>

Cc: 'INCOSE Fellows Discussion'<fellows...@incose.org>

Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

I agree with Scott when he asks for an "approved" definition of the word "complexity" and with Dave when he states that the systems engineering community has to agree on common definitions for the main constructs our discipline relies on (a community needs to share a common living language to live and to grow). Relativism does not allow such positive evolution.

I am also not sure that references to Oxford and Mirriam Webster’s dictionaries are mandatory: with common sense definitions, only common sense theories may be built!

As said Mario A. Bunge, definitions deal with constructs (concepts, predicates, propositions, ..), not with truth, and shall provide an identity between a "definiens" and a "definiendum" in the context of a body of knowledge (for instance in the context of the number theory, "one"=_def "successor of zero" is a definition, this definition is not true, but the statement “one is the successor of zero" is a true statement by definition). Homonyms are allowed.

So, in the system theory (man-made systems theory) addressed by the systems engineering community, the concept of "complexity" should be defined, if necessary, in a consistent way with the definition of the predicate "complex" that applies to "systems", for instance.

Such a definition is to be built using concepts previously defined in the same theory.
All of these terms should be defined with the same rigor and should not introduce cycles
Example :

“Process"=_def "series of state changes in a system”,
“Complex system"=_def "system which is the place of complex processes”,
“Complex process"=_def "process which outcomes are uncertain”,
“Complexity"=_def "measure of the uncertainty in achieving a system purpose”).
Other definition: “Complexity"=_def "measure associated to the composition and the structure of system”.

(Note that these two definitions of complexity are homonymous).
 

Other scientific or technical fields may define, in relevant ways, the same words with other "definienda", for instance with respect to concepts coming from Kolmogorv computation theory, Shannon information theory, Mandelbrot fractal theory or Thom catastrophe theory or Chaos theory and other exciting theories.

Importing such concepts in the system engineering area may be really beneficial.
However, despite their very suggestion power, wild translations of concepts coming from other fields will generate only confusion.

The question is twofold
1/ the imported concept is it truly applicable to the systems engineering area? For instance, the Shannon complexity concept is it really relevant in our area?
2/ what kind of problems this importation allows to solve? For instance, if the McCabe software cyclomatic complexity is imported, does it permit to address a particular system engineering problem?

This is same when we consider the complexity definition provided by Nam P. Suh in his book "Complexity" (Oxford Press, 2005):

(“Complexity"=_def "measure of uncertainty in understanding what it is we want to know or in achieving a functional requirement”).
I utilized this definition due to Suh  in  a chapter untitled "Emergence and complexity of Systems of systems"
in the book  "Systems of  systems " edited by  D. Luzeaux and  J-R Ruault this year (Wiley & ISTE, 2010).

In my opinion, this definition has an real epistemological interest.

Patrice Micouin
David W Oliver a écrit :

Sarah,

 

I believe  that It is essential to expect and support consistent usage of words from other people, especially in a new field. There are OMG working groups that are developing such uniform usage in several new fields. Consistency reduces ambiguity and renders databases and publications intelligible. In 1992 the organization Engineering Computer Based Systems met with representatives from many nations. As experienced engineers began describing the processes they used, all speaking in English, it became apparent that the words used had different meanings for everyone. The first day was a wreck for information transfer. At that time Object Modeling Technique, OMT, a precursor of UML, was in use for data base definition as well as for programing. On the second day we began transcribng the ppt charts into simple information models using entities, aggregation, generalization/specialization, and relationships - just four simple semantic principles. As we proceeded we resolved the questions of ambiguity as we went by quickly providing a graphic view of what was being said in vernacular text. Misunderstandings were exposed quickly and eliminated.

 

These are the same basic elements that are the basis of the ISO standards for definitions. They are inherent in the EXPRESS language that has been used to write ISO standards since the 1970's. The graphic model is not enough; it must be accompanied by text that records definitions in english used in accord with an identified dictionary and preferably with examples. This procedure was used in the AP233 and SysML developments and was esswential for their success.

 

INCOSE has a serious problem of never having adopted a model based procedure of this kind - hopefully they may adopt one superior. Most of the conversations, such as this one on complexity, die because of ambiguity and sophistry.  The INCOSE standards have never adopted the use of models; rather they rely on text and pictures. One generates agreement through ambiguity. This does not happen in other engineering disciplines in which mass, inductance, a phase diagram have well defined meanings. The authority for definitions is the group using them. In some cases overworked words like "state" may need an expansion of the single word with designators so that it may hold several definitions. It is not hard work. It is disciplined work. Definitions are not supposed to be perfect; they are useful in a particular domain. This is also true of decompositions and taxonomies. There is no one that is correct. They can be useful if handled with discipline.

 

It is important for INCOSE and the Fellows to come to grips with the need for definitions and the standards for writing them in text and models. An Ontology would be more rigorous.

 

Dave Oliver

 

 

 

 

 

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

From: Sarah Sheard

To: 'Scott Jackson' ; 'David W Oliver' ; 'Jack Ring' ; 'Jack Ring' ; 'INCOSE Fellows Discussion' ; 'David M. Oliver work' ; sysml...@googlegroups.com

Sent: Friday, May 28, 2010 9:32 AM

Subject: RE: [fellows discuss] Re: [SysML Forum] Source for Terminology

Hello, Scott,

 

You have been very active lately, nibbling around the edges of this “what is complexity” cookie and making some important inroads into the field.

 

Regarding your question of complexity definition, my question is what will you accomplish by coming up with the perfect definition?  I wager that even if you do, other documents will remain out there with “wrong” definitions. And who judges a definition as right or wrong, or for that matter who is an “approval authority” for definitions?

 

I guess what I’m trying to say is that the perfect system can only be designed if one understands well its intended use. I see your criteria for what you’re looking for (definitive rather than intuitive, focuses on complex system characteristics rather than on what you call the effects of complexity, and focuses on scientific qualities rather than human perceptions.) With those criteria and alternatives from a quick Google search and a bookcase book-index-search, one can perform a trade study. Even a simple scheme -- 9 pts for highly meets criteria, 3 points for moderately and 1 point for slightly, for example --should allow you to throw out all but a few definitions, which then can be combined.

 

But an important question is *why* are those criteria important to you? What do you plan to do with a perfect definition? Write a paper on it? Put it on a web site? Make everyone stop using all other definitions? (I just listened to a self-help discussion where the speaker basically urges one to go beyond one’s comfort zone in order to take advantages of “life’s complexity”...I doubt this speaker is reading systems engineering standards...)

 

A well-expressed intended use should help you improve your criteria. Then the above trade study should give you a close-to-perfect definition for your use.

 

It is folly to expect consistent usage of words from other people, especially in a new field.

 

Sarah Sheard

---

From: Scott Jackson [mailto:jacke...@cox.net]
Sent: Thursday, May 27, 2010 8:34 PM
To: David W Oliver; Jack Ring; Jack Ring; INCOSE Fellows Discussion; David M. Oliver work; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

Is there an approved definition of the word "complexity."  Most of the definitions I have seen suffer from three problems:

 

(1) they are intuitive instead of definitive.

 

(2) they focus on the effects of complexity (e.g. the butterfly effect) and not characteristics of complex systems

 

(3) they focus on human perceptions rather than scientific qualities, for example, anything hard to understand is complex (wrong).

 

I have found many INCOSE articles and documents that discuss complexity at length without ever defining it.  The Handbook is one of those documents.

 

If you can provide such a definition, please give me a reference.

 

Scott

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

From: David W Oliver

To: Jack Ring ; Jack Ring ; INCOSE Fellows Discussion ; David M. Oliver work ; sysml...@googlegroups.com

Sent: Thursday, May 27, 2010 5:09 PM

Subject: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

 

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

From: Michael Jesse Chonoles

To: sysml...@googlegroups.com

Sent: Saturday, May 22, 2010 10:38 PM

Subject: Re: [SysML Forum] Source for Terminology

 

A typical recursive definition of factorial goes as follows:

!(0)=1
!(n)=n*!(n-1)

A circular definition of a term is one that directly or indirectly depends on itself.

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM
Subject: Re: [SysML Forum] Source for Terminology

Please give an example. The dozen definitions of factorial I have found do not involve circularity.

 

Perhaps we should start with the definition of circular descriptions. 

 

The winner so far can be found in the U.S Tax Code --- "The Internal Revenue Code Title 26 offers perhaps the cleverest example of circumlocution ever created. Begin withtaxable income which is defined as gross income or adjusted gross income which is defined as all income from whatever source derived. However, understanding that taxable income is gross income or adjusted gross incomeearned in a taxable year it is necessary to define taxable year which is a taxpayers annual accounting period. Ataxpayer is defined as anyone subject to any tax under the revenue laws. Who is subject to the tax? In terms of revenue laws one would have to look at the sections that inform where a tax has been imposed. The beginning of Title 26 begins with a tax imposed which imposes a tax on...you guessed it taxable income."  A horse is a horse, of course, of course.

 

>> technique, process, tool, modeling notation.  However, we often mean >> different things.  For example, someone may talk about the [general]

>> "object-oriented" methodology, or SysML notation, or Structured >> Analysis and Design Technique, or the CMMI process. >>

>>      Does anyone know of a good source for precise definitions for >> these terms, or similar, in an SE or MBSE context? >>

>>           Thanks, Alan > > > -- > You received this message because you are subscribed to the Google Groups "SysML Forum" group. > To post to this group, send email to sysml...@googlegroups.com. > To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en. > -- You received this message because you are subscribed to the Google Groups "SysML Forum" group. To post to this group, send email to sysml...@googlegroups.com. To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

 

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

-----

For assistance with this reflector, send an email to lists...@incose.org

with HELP in the subject line.

-----
For assistance with this reflector, send an email to lists...@incose.org
with HELP in the subject line.
    

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

[Jack Ring]

Patrice,

I think you were doing well until you equated complex with uncertainty. If you use complex to signify uncertain it seems that the uncertainty is in the eye of the beholder, not in the content and structure of the system. Also, what will you do with ambiguity?

TKU,

Jack Ring

On May 30, 2010, at 8:17 AM, Patrice Micouin wrote:

I agree with Scott when he asks for an "approved" definition of the word "complexity" and with Dave when he states that the systems engineering community has to agree on common definitions for the main constructs our discipline relies on (a community needs to share a common living language to live and to grow). Relativism does not allow such positive evolution.

I am also not sure that references to Oxford and Mirriam Webster’s dictionaries are mandatory: with common sense definitions, only common sense theories may be built!

As said Mario A. Bunge, definitions deal with constructs (concepts, predicates, propositions, ..), not with truth, and shall provide an identity between a "definiens" and a "definiendum" in the context of a body of knowledge (for instance in the context of the number theory, "one"=_def "successor of zero" is a definition, this definition is not true, but the statement “one is the successor of zero" is a true statement by definition). Homonyms are allowed.

So, in the system theory (man-made systems theory) addressed by the systems engineering community, the concept of "complexity" should be defined, if necessary, in a consistent way with the definition of the predicate "complex" that applies to "systems", for instance.

Such a definition is to be built using concepts previously defined in the same theory.
All of these terms should be defined with the same rigor and should not introduce cycles
Example :

“Process"=_def "series of state changes in a system”,
“Complex system"=_def "system which is the place of complex processes”,
“Complex process"=_def "process which outcomes are uncertain”,
“Complexity"=_def "measure of the uncertainty in achieving a system purpose”).
Other definition: “Complexity"=_def "measure associated to the composition and the structure of system”.

(Note that these two definitions of complexity are homonymous).
 

Other scientific or technical fields may define, in relevant ways, the same words with other "definienda", for instance with respect to concepts coming from Kolmogorv computation theory, Shannon information theory, Mandelbrot fractal theory or Thom catastrophe theory or Chaos theory and other exciting theories.

Importing such concepts in the system engineering area may be really beneficial.
However, despite their very suggestion power, wild translations of concepts coming from other fields will generate only confusion.

The question is twofold
1/ the imported concept is it truly applicable to the systems engineering area? For instance, the Shannon complexity concept is it really relevant in our area?
2/ what kind of problems this importation allows to solve? For instance, if the McCabe software cyclomatic complexity is imported, does it permit to address a particular system engineering problem?

This is same when we consider the complexity definition provided by Nam P. Suh in his book "Complexity" (Oxford Press, 2005):

(“Complexity"=_def "measure of uncertainty in understanding what it is we want to know or in achieving a functional requirement”).

I utilized this definition due to Suh  in  a chapter untitled "Emergence and complexity of Systems of systems"

in the book  "Systems of  systems " edited by  D. Luzeaux and  J-R Ruault this year (Wiley & ISTE, 2010).

In my opinion, this definition has an real epistemological interest.

Patrice Micouin
David W Oliver a écrit :

Sarah,

 

I believe  that It is essential to expect and support consistent usage of words from other people, especially in a new field. There are OMG working groups that are developing such uniform usage in several new fields. Consistency reduces ambiguity and renders databases and publications intelligible. In 1992 the organization Engineering Computer Based Systems met with representatives from many nations. As experienced engineers began describing the processes they used, all speaking in English, it became apparent that the words used had different meanings for everyone. The first day was a wreck for information transfer. At that time Object Modeling Technique, OMT, a precursor of UML, was in use for data base definition as well as for programing. On the second day we began transcribng the ppt charts into simple information models using entities, aggregation, generalization/specialization, and relationships - just four simple semantic principles. As we proceeded we resolved the questions of ambiguity as we went by quickly providing a graphic view of what was being said in vernacular text. Misunderstandings were exposed quickly and eliminated.

 

These are the same basic elements that are the basis of the ISO standards for definitions. They are inherent in the EXPRESS language that has been used to write ISO standards since the 1970's. The graphic model is not enough; it must be accompanied by text that records definitions in english used in accord with an identified dictionary and preferably with examples. This procedure was used in the AP233 and SysML developments and was esswential for their success.

 

INCOSE has a serious problem of never having adopted a model based procedure of this kind - hopefully they may adopt one superior. Most of the conversations, such as this one on complexity, die because of ambiguity and sophistry.  The INCOSE standards have never adopted the use of models; rather they rely on text and pictures. One generates agreement through ambiguity. This does not happen in other engineering disciplines in which mass, inductance, a phase diagram have well defined meanings. The authority for definitions is the group using them. In some cases overworked words like "state" may need an expansion of the single word with designators so that it may hold several definitions. It is not hard work. It is disciplined work. Definitions are not supposed to be perfect; they are useful in a particular domain. This is also true of decompositions and taxonomies. There is no one that is correct. They can be useful if handled with discipline.

 

It is important for INCOSE and the Fellows to come to grips with the need for definitions and the standards for writing them in text and models. An Ontology would be more rigorous.

 

Dave Oliver

 

 

 

 

 

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

From: Sarah Sheard

To: 'Scott Jackson' ; 'David W Oliver' ; 'Jack Ring' ; 'Jack Ring' ; 'INCOSE Fellows Discussion' ; 'David M. Oliver work' ; sysml...@googlegroups.com

Sent: Friday, May 28, 2010 9:32 AM

Subject: RE: [fellows discuss] Re: [SysML Forum] Source for Terminology

Hello, Scott,

 

You have been very active lately, nibbling around the edges of this “what is complexity” cookie and making some important inroads into the field.

 

Regarding your question of complexity definition, my question is what will you accomplish by coming up with the perfect definition?  I wager that even if you do, other documents will remain out there with “wrong” definitions. And who judges a definition as right or wrong, or for that matter who is an “approval authority” for definitions?

 

I guess what I’m trying to say is that the perfect system can only be designed if one understands well its intended use. I see your criteria for what you’re looking for (definitive rather than intuitive, focuses on complex system characteristics rather than on what you call the effects of complexity, and focuses on scientific qualities rather than human perceptions.) With those criteria and alternatives from a quick Google search and a bookcase book-index-search, one can perform a trade study. Even a simple scheme -- 9 pts for highly meets criteria, 3 points for moderately and 1 point for slightly, for example --should allow you to throw out all but a few definitions, which then can be combined.

 

But an important question is *why* are those criteria important to you? What do you plan to do with a perfect definition? Write a paper on it? Put it on a web site? Make everyone stop using all other definitions? (I just listened to a self-help discussion where the speaker basically urges one to go beyond one’s comfort zone in order to take advantages of “life’s complexity”...I doubt this speaker is reading systems engineering standards...)

 

A well-expressed intended use should help you improve your criteria. Then the above trade study should give you a close-to-perfect definition for your use.

 

It is folly to expect consistent usage of words from other people, especially in a new field.

 

Sarah Sheard

---

From: Scott Jackson [mailto:jacke...@cox.net]
Sent: Thursday, May 27, 2010 8:34 PM
To: David W Oliver; Jack Ring; Jack Ring; INCOSE Fellows Discussion; David M. Oliver work; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

Is there an approved definition of the word "complexity."  Most of the definitions I have seen suffer from three problems:

 

(1) they are intuitive instead of definitive.

 

(2) they focus on the effects of complexity (e.g. the butterfly effect) and not characteristics of complex systems

 

(3) they focus on human perceptions rather than scientific qualities, for example, anything hard to understand is complex (wrong).

 

I have found many INCOSE articles and documents that discuss complexity at length without ever defining it.  The Handbook is one of those documents.

 

If you can provide such a definition, please give me a reference.

 

Scott

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

From: David W Oliver

To: Jack Ring ; Jack Ring ; INCOSE Fellows Discussion ; David M. Oliver work ; sysml...@googlegroups.com

Sent: Thursday, May 27, 2010 5:09 PM

Subject: [fellows discuss] Re: [SysML Forum] Source for Terminology

 

 

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

From: Michael Jesse Chonoles

To: sysml...@googlegroups.com

Sent: Saturday, May 22, 2010 10:38 PM

Subject: Re: [SysML Forum] Source for Terminology

 

A typical recursive definition of factorial goes as follows:

!(0)=1
!(n)=n*!(n-1)

A circular definition of a term is one that directly or indirectly depends on itself.

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM
Subject: Re: [SysML Forum] Source for Terminology

Please give an example. The dozen definitions of factorial I have found do not involve circularity.

 

Perhaps we should start with the definition of circular descriptions. 

 

The winner so far can be found in the U.S Tax Code --- "The Internal Revenue Code Title 26 offers perhaps the cleverest example of circumlocution ever created. Begin withtaxable income which is defined as gross income or adjusted gross income which is defined as all income from whatever source derived. However, understanding that taxable income is gross income or adjusted gross incomeearned in a taxable year it is necessary to define taxable year which is a taxpayers annual accounting period. Ataxpayer is defined as anyone subject to any tax under the revenue laws. Who is subject to the tax? In terms of revenue laws one would have to look at the sections that inform where a tax has been imposed. The beginning of Title 26 begins with a tax imposed which imposes a tax on...you guessed it taxable income."  A horse is a horse, of course, of course.

 

>> technique, process, tool, modeling notation.  However, we often mean >> different things.  For example, someone may talk about the [general]

>> "object-oriented" methodology, or SysML notation, or Structured >> Analysis and Design Technique, or the CMMI process. >>

>>      Does anyone know of a good source for precise definitions for >> these terms, or similar, in an SE or MBSE context? >>

>>           Thanks, Alan > > > -- > You received this message because you are subscribed to the Google Groups "SysML Forum" group. > To post to this group, send email to sysml...@googlegroups.com. > To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en. > -- You received this message because you are subscribed to the Google Groups "SysML Forum" group. To post to this group, send email to sysml...@googlegroups.com. To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

 

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

-----

For assistance with this reflector, send an email to lists...@incose.org

with HELP in the subject line.

-----
For assistance with this reflector, send an email to lists...@incose.org
with HELP in the subject line.
    

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.

[David W Oliver]

Folks,

 

A few comments on the list from Patrice. These are put here to indicate that it is extremely difficult to deal with these issues in a set of text sentences. The reason is that one needs an ordered set of definitions with many relationships interconnedting them. To depict this requires an information model with a text data dictionary. The first versions will be straw men for discussion, change, and evolution. The models need a defined language - not English. There are a number of defined languages to do this, EXPRESS, entity-relationship diagrams, OMT, UML. All can be used to define a schema for artifacts of engineering. UML is the most widely know and is identical to SysML for these purposes. Only a few UML symbols need to be learned and used.

 

Dave Oliver

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

From: Jack Ring

To: sysml...@googlegroups.com

Cc: 'INCOSE Fellows Discussion'

Sent: Sunday, May 30, 2010 9:59 PM

Subject: Re: [fellows discuss] Re: [SysML Forum] Source for Terminology

Patrice,

I think you were doing well until you equated complex with uncertainty. If you use complex to signify uncertain it seems that the uncertainty is in the eye of the beholder, not in the content and structure of the system. Also, what will you do with ambiguity?

TKU,

Jack Ring

On May 30, 2010, at 8:17 AM, Patrice Micouin wrote:

I agree with Scott when he asks for an "approved" definition of the word "complexity" and with Dave when he states that the systems engineering community has to agree on common definitions for the main constructs our discipline relies on (a community needs to share a common living language to live and to grow). Relativism does not allow such positive evolution.

I am also not sure that references to Oxford and Mirriam Webster’s dictionaries are mandatory: with common sense definitions, only common sense theories may be built!

As said Mario A. Bunge, definitions deal with constructs (concepts, predicates, propositions, ..), not with truth, and shall provide an identity between a "definiens" and a "definiendum" in the context of a body of knowledge (for instance in the context of the number theory, "one"=_def "successor of zero" is a definition, this definition is not true, but the statement “one is the successor of zero" is a true statement by definition). Homonyms are allowed.

So, in the system theory (man-made systems theory) addressed by the systems engineering community, the concept of "complexity" should be defined, if necessary, in a consistent way with the definition of the predicate "complex" that applies to "systems", for instance.

Such a definition is to be built using concepts previously defined in the same theory.
All of these terms should be defined with the same rigor and should not introduce cycles
Example :

“Process"=_def "series of state changes in a system”, All of science and engineering performance calcilations use functions (transformations) rather than state. Behavior (process) can be represented and defined with either or both. However, transformations of a set of inputs to a set of outputs under defined conditions is the common description used in science and ebgineering performance and process calculations.

“Complex system"=_def "system which is the place of complex processes

”,
“Complex process"=_def "process which outcomes are uncertain”, There is never certainty in science and engineering; always uncertainty. To make this work it would be necessary to quantify uncertainty and provide a threshold value. Note that uncertainty might be related to risk or to probability of failure.
“Complexity"=_def "measure of the uncertainty in achieving a system purpose”).
Other definition: “Complexity"=_def "measure associated to the composition and the structure of system”. Invariant over time?  The complexity of an integrated circuit chip with 100 million transistors is the same today as it was in 1970? Is that the useful way to relate complexity to astructure.

(Note that these two definitions of complexity are homonymous).
 

Other scientific or technical fields may define, in relevant ways, the same words with other "definienda", for instance with respect to concepts coming from Kolmogorv computation theory, Shannon information theory, Mandelbrot fractal theory or Thom catastrophe theory or Chaos theory and other exciting theories.

Importing such concepts in the system engineering area may be really beneficial.
However, despite their very suggestion power, wild translations of concepts coming from other fields will generate only confusion.

The question is twofold
1/ the imported concept is it truly applicable to the systems engineering area? For instance, the Shannon complexity concept is it really relevant in our area?
2/ what kind of problems this importation allows to solve? For instance, if the McCabe software cyclomatic complexity is imported, does it permit to address a particular system engineering problem?

This is same when we consider the complexity definition provided by Nam P. Suh in his book "Complexity" (Oxford Press, 2005):
(“Complexity

"=_def "measure of uncertainty in understanding what it is we want to know or in achieving a functional requirement”).
I utilized this definition due to Suh  in  a chapter untitled "Emergence and complexity of Systems of systems"
in the book  "Systems of  systems " edited by  D. Luzeaux and  J-R Ruault this year (Wiley & ISTE, 2010).
In my opinion, this definition has an real epistemological interest.

The issue is usefulness in the work that we do - performing the work and communicationg about it.

Patrice Micouin
David W Oliver a écrit :

Sarah,

 

I believe  that It is essential to expect and support consistent usage of words from other people, especially in a new field. There are OMG working groups that are developing such uniform usage in several new fields. Consistency reduces ambiguity and renders databases and publications intelligible. In 1992 the organization Engineering Computer Based Systems met with representatives from many nations. As experienced engineers began describing the processes they used, all speaking in English, it became apparent that the words used had different meanings for everyone. The first day was a wreck for information transfer. At that time Object Modeling Technique, OMT, a precursor of UML, was in use for data base definition as well as for programing. On the second day we began transcribng the ppt charts into simple information models using entities, aggregation, generalization/specialization, and relationships - just four simple semantic principles. As we proceeded we resolved the questions of ambiguity as we went by quickly providing a graphic view of what was being said in vernacular text. Misunderstandings were exposed quickly and eliminated.

 

These are the same basic elements that are the basis of the ISO standards for definitions. They are inherent in the EXPRESS language that has been used to write ISO standards since the 1970's. The graphic model is not enough; it must be accompanied by text that records definitions in english used in accord with an identified dictionary and preferably with examples. This procedure was used in the AP233 and SysML developments and was esswential for their success.

 

INCOSE has a serious problem of never having adopted a model based procedure of this kind - hopefully they may adopt one superior. Most of the conversations, such as this one on complexity, die because of ambiguity and sophistry.  The INCOSE standards have never adopted the use of models; rather they rely on text and pictures. One generates agreement through ambiguity. This does not happen in other engineering disciplines in which mass, inductance, a phase diagram have well defined meanings. The authority for definitions is the group using them. In some cases overworked words like "state" may need an expansion of the single word with designators so that it may hold several definitions. It is not hard work. It is disciplined work. Definitions are not supposed to be perfect; they are useful in a particular domain. This is also true of decompositions and taxonomies. There is no one that is correct. They can be useful if handled with discipline.

 

It is important for INCOSE and the Fellows to come to grips with the need for definitions and the standards for writing them in text and models. An Ontology would be more rigorous.

 

Dave Oliver

 

 

 

 

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

From: Sarah Sheard

To: 'Scott Jackson' ; 'David W Oliver' ; 'Jack Ring' ; 'Jack Ring' ; 'INCOSE Fellows Discussion' ; 'David M. Oliver work' ; sysml...@googlegroups.com

Sent: Friday, May 28, 2010 9:32 AM

Subject: RE: [fellows discuss] Re: [SysML Forum] Source for Terminology

Hello, Scott,

You have been very active lately, nibbling around the edges of this “what is complexity” cookie and making some important inroads into the field.

Regarding your question of complexity definition, my question is what will you accomplish by coming up with the perfect definition?  I wager that even if you do, other documents will remain out there with “wrong” definitions. And who judges a definition as right or wrong, or for that matter who is an “approval authority” for definitions?

I guess what I’m trying to say is that the perfect system can only be designed if one understands well its intended use. I see your criteria for what you’re looking for (definitive rather than intuitive, focuses on complex system characteristics rather than on what you call the effects of complexity, and focuses on scientific qualities rather than human perceptions.) With those criteria and alternatives from a quick Google search and a bookcase book-index-search, one can perform a trade study. Even a simple scheme -- 9 pts for highly meets criteria, 3 points for moderately and 1 point for slightly, for example --should allow you to throw out all but a few definitions, which then can be combined.

But an important question is *why* are those criteria important to you? What do you plan to do with a perfect definition? Write a paper on it? Put it on a web site? Make everyone stop using all other definitions? (I just listened to a self-help discussion where the speaker basically urges one to go beyond one’s comfort zone in order to take advantages of “life’s complexity”...I doubt this speaker is reading systems engineering standards...)

A well-expressed intended use should help you improve your criteria. Then the above trade study should give you a close-to-perfect definition for your use.

It is folly to expect consistent usage of words from other people, especially in a new field.

Sarah Sheard
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

---

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM
Subject: Re: [SysML Forum] Source for Terminology

Please give an example. The dozen definitions of factorial I have found do not involve circularity.

Perhaps we should start with the definition of circular descriptions. 

The winner so far can be found in the U.S Tax Code --- "The Internal Revenue Code Title 26 offers perhaps the cleverest example of circumlocution ever created. Begin withtaxable income which is defined as gross income or adjusted gross income which is defined as all income from whatever source derived. However, understanding that taxable income is gross income or adjusted gross incomeearned in a taxable year it is necessary to define taxable year which is a taxpayers annual accounting period. Ataxpayer is defined as anyone subject to any tax under the revenue laws. Who is subject to the tax? In terms of revenue laws one would have to look at the sections that inform where a tax has been imposed. The beginning of Title 26 begins with a tax imposed which imposes a tax on...you guessed it taxable income."  A horse is a horse, of course, of course.

On May 22, 2010, at 6:18 AM, Michael Jesse Chonoles wrote:

<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

[Jack Ring]

On May 31, 2010, at 8:44 PM, Jack Ring wrote:

Scott,

The properties of a system that make it difficult to understand were noted by W. Ross Ashby 50 years ago.  Properties signify endogenous attributes such as the color of your eyes or the volume of an elephant.

The characteristics of a system that make it difficult to understand were noted by Korsybski 80 years ago and quantitatively modeled by Halstead 40 years ago. Characteristics signify exogenous attributes such as your time for a 10K run or the reason Hannibal's army wouldn't make it over the Alps.  

You did not ask about the properties of a human that makes it difficult for them to understand a system (perhaps knowledge, intuition, ladder of inference, levels of consciousness that enables Janusian or Hegelian thinking or not, having been extruded through a graduate program in a Western Hemisphere university, a restricted corpus collosum, etc.)

You did not ask about the characteristics of a human that makes it difficult for them to understand a system (perhaps short term memory limitations,  preoccupation with 'is' or form instead of 'does' or function, inability to compile POSIWID, fear, etc.).

OBTW, regarding the pupua - larva - caterpillar - butterfly do you consider this as one system or one system with four distinct modes of operation or four systems or what? 

If you decide this first then much of the 'literature' on complex, adaptive systems (which aren't) will be easier to comprehend.

in the fourth grade you learned the distinction between a simple sentence, a compound sentence, and a complex sentence.  Remember?

Then you learned about solving 2X = 6 for X, then solving 2X = Y-6 for X given a value of Y, then solving 2X+ Y = 8 for both X and Y given X+Y = 6. Also you learned a rule that solving a set of equations involving n variables required n equations.

Then dx/dt, then dx/dy then partialX/partialY, etc.

So what if X is a system?

Onward,

Jack Ring

On May 31, 2010, at 7:22 PM, Sarah Sheard wrote:

Scott Jackson asked:

Yes, but what properties of the system make it difficult to understand and verify?

 

 

Scott, that’s the subject of my doctoral work. The answer varies,

 

1) The domain...how many factors in the domain (environment) need to be considered at once?

 

2) The number of elements, tasks, components, or number of types of these things...although some consider large numbers of things to be “mere complicatedness,” not complexity.

 

3) The connectivity of the elements/tasks, expressed in various ways including number of links, density of links, number of feedback loops, or even expressed in things like the nonlinearity of behavior (often caused by those same feedback loops).

 

4) The sensitivity of the dynamics of the system to small changes...same as the second half of 3

 

5) Self-organization, adaptation of agents, and evolution of the system into a new state or new system. These are useful, as you well know, for adapting as a system to small changes, but can create unpredictability

 

6) Unpredictable emergent behaviors, usually in systems that one would describe by saying that the properties of the system are more a result of interactions among the elements than they are a result of element properties. While we have many more ways of simulating things like ant hills, bird flocks, crowds, and computer attacks, we still are regularly finding more ways of understanding, conceiving of, and possibly predicting and exploiting such emergent properties.

 

7) Cognitive complexity...the number of things an analyst or a manager has to keep in his/her head at once overwhelms a single individual’s ability.

 

8) Sociopolitical complexity...how people work, for example when in groups, in stressful situations, when given incentives of a certain sort, etc. We engineers just assume this is known by someone, or we assume we know it, yet there is a whole body of knowledge that’s been studying that forever, it’s just the stuff we skipped in school so we could do Fourier and Laplace transforms!

 

I’m sorry, I don’t have anything more concrete for you at this point...ask again in a year...

 

Sarah

 

oh and by the way, I *believe* (but have not yet convinced myself this is real) that the properties of technological systems, the systems we engineers are charged with building, may have somewhat different complexity properties than the socio-political systems (e.g. the development programs, aka the enterprises) that we use to build them.

 

[fabrice....@mpsa.com]

Hello Patrice,

I agree with you to consider an epistemological solution, so you can find
an illustrated example about MCR epistemological theory application :

http://www.admiroutes.asso.fr/larevue/2010/105/mrcecology.pdf


The Method of Relativized Conceptualization (MCR), initially proposed in
the field of Quantum Mechanics by the physicist Mioara Mugur-Schächter then
extended in other domains of science, give an universal formal model to
guide the built of thought.

You will find all information on web site :

http://www.mugur-schachter.net/index.html



Best Regards,

Fabrice FLEUCHEY
Member of adMCR






Patrice Micouin
<patrice.micouin
@ieee.org> Pour
Envoyé par : sysml...@googlegroups.com
sysmlforum@googl cc
egroups.com 'INCOSE Fellows Discussion'
<fellows...@incose.org>
Objet
30/05/2010 17:43 Re: [fellows discuss] Re: [SysML
Forum] Source for Terminology

Veuillez
répondre à
sysmlforum@googl
egroups.com

I agree with Scott when he asks for an "approved" definition of the word
"complexity" and with Dave when he states that the systems engineering
community has to agree on common definitions for the main constructs our
discipline relies on (a community needs to share a common living language
to live and to grow). Relativism does not allow such positive evolution.

I am also not sure that references to Oxford and Mirriam Webster’s

dictionaries are mandatory: with common sense definitions, only common
sense theories may be built!



As said Mario A. Bunge, definitions deal with constructs (concepts,
predicates, propositions, ..), not with truth, and shall provide an
identity between a "definiens" and a "definiendum" in the context of a body
of knowledge (for instance in the context of the number theory, "one"=def
"successor of zero" is a definition, this definition is not true, but the

statement “one is the successor of zero" is a true statement by

definition). Homonyms are allowed.





So, in the system theory (man-made systems theory) addressed by the systems
engineering community, the concept of "complexity" should be defined, if
necessary, in a consistent way with the definition of the predicate
"complex" that applies to "systems", for instance.



Such a definition is to be built using concepts previously defined in the
same theory.
All of these terms should be defined with the same rigor and should not
introduce cycles
Example :

“Process"=def "series of state changes in a system”,
“Complex system"=def "system which is the place of complex processes”,
“Complex process"=def "process which outcomes are uncertain”,
“Complexity"=def "measure of the uncertainty in achieving a system
purpose”).
Other definition: “Complexity"=def "measure associated to the composition
and the structure of system”.

(Note that these two definitions of complexity are homonymous).

Other scientific or technical fields may define, in relevant ways, the same
words with other "definienda", for instance with respect to concepts coming
from Kolmogorv computation theory, Shannon information theory, Mandelbrot
fractal theory or Thom catastrophe theory or Chaos theory and other
exciting theories.





Importing such concepts in the system engineering area may be really
beneficial.
However, despite their very suggestion power, wild translations of concepts
coming from other fields will generate only confusion.



The question is twofold
1/ the imported concept is it truly applicable to the systems engineering
area? For instance, the Shannon complexity concept is it really relevant in
our area?
2/ what kind of problems this importation allows to solve? For instance, if
the McCabe software cyclomatic complexity is imported, does it permit to
address a particular system engineering problem?



This is same when we consider the complexity definition provided by Nam P.
Suh in his book "Complexity" (Oxford Press, 2005):

(“Complexity"=def "measure of uncertainty in understanding what it is we
want to know or in achieving a functional requirement”).
I utilized this definition due to Suh  in  a chapter untitled "Emergence

and complexity of Systems of systems"

in the book  "Systems of  systems " edited by  D. Luzeaux and  J-R Ruault

this year (Wiley & ISTE, 2010).
In my opinion, this definition has an real epistemological interest.





Patrice Micouin

David W Oliver a écrit :
Sarah,

I believe  that It is essential to expect and support consistent

usage of words from other people, especially in a new field. There
are OMG working groups that are developing such uniform usage in
several new fields. Consistency reduces ambiguity and renders
databases and publications intelligible. In 1992 the organization
Engineering Computer Based Systems met with representatives from many
nations. As experienced engineers began describing the processes they
used, all speaking in English, it became apparent that the words used
had different meanings for everyone. The first day was a wreck for
information transfer. At that time Object Modeling Technique, OMT, a
precursor of UML, was in use for data base definition as well as for
programing. On the second day we began transcribng the ppt charts
into simple information models using entities, aggregation,

generalization/specialization, and relationships - just four simple

semantic principles. As we proceeded we resolved the questions of
ambiguity as we went by quickly providing a graphic view of what was
being said in vernacular text. Misunderstandings were exposed quickly
and eliminated.

These are the same basic elements that are the basis of the ISO
standards for definitions. They are inherent in the EXPRESS language
that has been used to write ISO standards since the 1970's. The
graphic model is not enough; it must be accompanied by text that
records definitions in english used in accord with an identified
dictionary and preferably with examples. This procedure was used in
the AP233 and SysML developments and was esswential for their
success.

INCOSE has a serious problem of never having adopted a model based
procedure of this kind - hopefully they may adopt one superior. Most
of the conversations, such as this one on complexity, die because of

ambiguity and sophistry.  The INCOSE standards have never adopted the

use of models; rather they rely on text and pictures. One generates
agreement through ambiguity. This does not happen in other
engineering disciplines in which mass, inductance, a phase diagram
have well defined meanings. The authority for definitions is the
group using them. In some cases overworked words like "state" may
need an expansion of the single word with designators so that it may
hold several definitions. It is not hard work. It is disciplined
work. Definitions are not supposed to be perfect; they are useful in
a particular domain. This is also true of decompositions and
taxonomies. There is no one that is correct. They can be useful if
handled with discipline.

It is important for INCOSE and the Fellows to come to grips with the
need for definitions and the standards for writing them in text and
models. An Ontology would be more rigorous.

Dave Oliver

----- Original Message -----
From: Sarah Sheard
To: 'Scott Jackson' ; 'David W Oliver' ; 'Jack Ring' ; 'Jack Ring' ;
'INCOSE Fellows Discussion' ; 'David M. Oliver work' ;
sysml...@googlegroups.com
Sent: Friday, May 28, 2010 9:32 AM
Subject: RE: [fellows discuss] Re: [SysML Forum] Source for
Terminology



Hello, Scott,

You have been very active lately, nibbling around the edges of this

“what is complexity” cookie and making some important inroads into
the field.

Regarding your question of complexity definition, my question is
what will you accomplish by coming up with the perfect definition?

I wager that even if you do, other documents will remain out there

with “wrong” definitions. And who judges a definition as right or
wrong, or for that matter who is an “approval authority” for
definitions?

I guess what I’m trying to say is that the perfect system can only

be designed if one understands well its intended use. I see your

criteria for what you’re looking for (definitive rather than

intuitive, focuses on complex system characteristics rather than on
what you call the effects of complexity, and focuses on scientific
qualities rather than human perceptions.) With those criteria and
alternatives from a quick Google search and a bookcase
book-index-search, one can perform a trade study. Even a simple
scheme -- 9 pts for highly meets criteria, 3 points for moderately
and 1 point for slightly, for example --should allow you to throw
out all but a few definitions, which then can be combined.

But an important question is *why* are those criteria important to
you? What do you plan to do with a perfect definition? Write a paper
on it? Put it on a web site? Make everyone stop using all other
definitions? (I just listened to a self-help discussion where the

speaker basically urges one to go beyond one’s comfort zone in order
to take advantages of “life’s complexity”...I doubt this speaker is
reading systems engineering standards...)

A well-expressed intended use should help you improve your criteria.
Then the above trade study should give you a close-to-perfect
definition for your use.

It is folly to expect consistent usage of words from other people,
especially in a new field.

Sarah Sheard

From: Scott Jackson [mailto:jacke...@cox.net]
Sent: Thursday, May 27, 2010 8:34 PM
To: David W Oliver; Jack Ring; Jack Ring; INCOSE Fellows Discussion;
David M. Oliver work; sysml...@googlegroups.com
Subject: Re: [fellows discuss] Re: [SysML Forum] Source for
Terminology

Is there an approved definition of the word "complexity."  Most of

the definitions I have seen suffer from three problems:

(1) they are intuitive instead of definitive.

(2) they focus on the effects of complexity (e.g. the butterfly
effect) and not characteristics of complex systems

(3) they focus on human perceptions rather than scientific
qualities, for example, anything hard to understand is complex
(wrong).

I have found many INCOSE articles and documents that discuss
complexity at length without ever defining it.  The Handbook is one
of those documents.

If you can provide such a definition, please give me a reference.

Scott


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


From: David W Oliver


To: Jack Ring ; Jack Ring ; INCOSE Fellows Discussion ; David
M. Oliver work ; sysml...@googlegroups.com


Sent: Thursday, May 27, 2010 5:09 PM


Subject: [fellows discuss] Re: [SysML Forum] Source for
Terminology

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


From: Michael Jesse Chonoles


To: sysml...@googlegroups.com


Sent: Saturday, May 22, 2010 10:38 PM


Subject: Re: [SysML Forum] Source for Terminology

A typical recursive definition of factorial goes as
follows:

!(0)=1
!(n)=n*!(n-1)

A circular definition of a term is one that directly or
indirectly depends on itself.

From: Jack Ring <jri...@gmail.com>
To: sysml...@googlegroups.com
Sent: Sat, May 22, 2010 2:10:15 PM
Subject: Re: [SysML Forum] Source for Terminology

Please give an example. The dozen definitions of
factorial I have found do not involve circularity.

Perhaps we should start with the definition of circular
descriptions.

The winner so far can be found in the U.S Tax Code --- "
The Internal Revenue Code Title 26 offers perhaps the
cleverest example of circumlocution ever created. Begin

withtaxable income which is defined as gross income or

adjusted gross income which is defined as all income

from whatever source derived. However, understanding

that taxable income is gross income or adjusted gross
incomeearned in a taxable year it is necessary to
define taxable year which is a taxpayers annual
accounting period. Ataxpayer is defined as anyone

subject to any tax under the revenue laws. Who is

subject to the tax? In terms of revenue laws one would
have to look at the sections that inform where a tax has

been imposed. The beginning of Title 26 begins with a
tax imposed which imposes a tax on...you guessed it
taxable income."  A horse is a horse, of course, of
course.

>> technique, process, tool, modeling notation.  However, we often mean
>> different things.  For example, someone may talk about the [general]

>> "object-oriented" methodology, or SysML notation, or Structured
>> Analysis and Design Technique, or the CMMI process.
>>

>>      Does anyone know of a good source for precise definitions for
>> these terms, or similar, in an SE or MBSE context?
>>

>>           Thanks, Alan
>
>
> --
> You received this message because you are subscribed to the Google Groups "SysML Forum" group.
> To post to this group, send email to sysml...@googlegroups.com.
> To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sysmlforum?hl=en.








--
You received this message because you are subscribed to
the Google Groups "SysML Forum" group.
To post to this group, send email to
sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum

+unsub...@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en.





--
You received this message because you are subscribed to
the Google Groups "SysML Forum" group.
To post to this group, send email to
sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum

+unsub...@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en.
-----
For assistance with this reflector, send an email to
lists...@incose.org
with HELP in the subject line.
-----
For assistance with this reflector, send an email to
lists...@incose.org
with HELP in the subject line.

--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum

+unsub...@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en.



--
You received this message because you are subscribed to the Google Groups
"SysML Forum" group.
To post to this group, send email to sysml...@googlegroups.com.
To unsubscribe from this group, send email to sysmlforum

+unsub...@googlegroups.com.