This was a disappointing day for me.  There were many good issues raised, little resolution, and quite a bit of discussion that went something like "UML does not care about that so SysML should not either."  It is difficult to separate what my experience indicates are significant differences from those that are "methodology".  I am beginning to decide that this distinction is what has been the biggest failing of UML.  While trying to be all things to all people UML has chosen such a non-offensive route as to say very little of value about the systems being modeled.

 

There are some very fundamental differences that are even more critical in SysML than in typical software projects, that UML does not highlight, and SysML has chosen to follow the UML example.  For example there is a very big difference between something that only exists at design time (constraints, software subsystems, model packages, etc) and those things that actually exist in the real world (nuts, bolts, software bits, etc).  Things in the real world tend to have part numbers, logical design artifacts do not.  Things that exist in the real world have instances that have serial numbers or lot numbers, or version numbers with release dates, etc.  There are also things that exist in the design that have logical instances only during analysis, and those that have logical instances as part of the actual system.  For example a sub-assembly might not have a part number and so it is a logical thing, but it is part of the logical thing called the system being built.  A constraint used to analyze an instance or design of a system is not actually part of the system.  While UML chooses to "unify" these various concepts and leave the teasing apart to "methodology" this weakens the language.  Imagine a programming language that lets you create an instance of a Package?  Imagine a programming language that does not know the difference between a check performed at compile time and one at run-time.  Imagine a programming system that represents the artifacts of a static analysis tool the same as the bits that actually result in compiled binary bits.  Some programming languages choose to explicitly blur these differences and result in various engineering trade-offs from that blurring.  What I am suggesting is that the underlying language definition must deal with the differences in some way explicitly.  If the language does not differentiate between two types of computation (initializers or imperative statements) it by necessity results in a system that treats them the same.

 

One of the hot topics from today's discussion was Parametrics.  Should they extend Block or UML Class or UML Classifier or should they be Collaborations.  My argument two fold.  They are not Blocks because they do not model the same kind of things as blocks do.  Blocks model aspects of the system being designed, while Parametrics model things that are about the design of that system but not of the system itself.  A more concrete aspect of this is that Parametrics do not have Ports and Connectors like Blocks, theirs are different in nature and used to mean something different.  They are more fundamentally different than Logical/Physical differences.  It is like calling the design for a car factory the same as the design for the car, and allowing the two to be intermixed.  There are parts of the factory design that might reference the design of the car for some purpose such as specifying the stages of production, tolerances, etc.  But that does not mean the factory and car representations should be unified.

 

Another topic that came up in the call was the representation of instances.  The requirements are fairly well held as the need to represent individual instances/realizations of the components of the model.  This includes a representation of the serial number and lot numbers of physical parts, and version numbers of software components or data components.  What is not as much in consensus is the technique as a UML Profile for representing these things.  UML provides an InstanceSpecification and notation for instances of object structure, but no representation for any other instances such as behavior nodes, collaborations, interactions, use cases, etc.  So some people want a similar instance representation in SysML using InstanceSpecification and a separate diagram type.  Another suggestion was to define a notational convention that instances are specified by underlining the title and providing a name to precede the type information.  This scales better to the full diagram set than explicitly using the UML model for instances.  But, it does also require that the diagram representation for instances reuse the representation for classes with restrictions and reinterpretations.  The technically correct solution would be to model instances as true instances of the model level classes and define notation for viewing those instances.  This requires that there be flexible metamodeling which UML tools are not required to provide.  If we want to be a profile that can be used in most UML 2.0 tools then the only viable approach is to tag instances with a profile that is defined as meaning instances, explicitly modeling instances requires a metamodel equal in size to the current SysML metamodel with attendant development time.  If we go to a custom metamodel and ditch the restrictions of Profiles then we have more options, and require more development on the part of tool vendors.

 

There were several other issues discussed that did not have as much juice for me, or at least left less of an impression/bad taste.

There has been much said about executable semantics or executability.  There has also been debate about the importance of this.  Here are my thoughts on that.

 

Any language has aspects that impact execution and those that do not.  In general the aspects that do not impact execution are less formal, and serve a process role.  In other words they are documentation for humans, or they are used by tools to aid in the development of the executable portions, or serve to organize the executable portions during the development process.

 

Those portions of a language that have executable semantics are those that actually impact the final system.  While a SysML tool need not actually perform execution, the semantics should be sufficiently well defined that a tool CAN execute the semantics.  Where this is not true, the element of the language does not have a clear impact on the final system.

 

While there can be debate on what level of rigor is required in a modeling language, it is my experience that unless the semantics intended to affect the system are executable the resulting models have significant errors that are much more costly to resolve downstream.

 

My main concern with SysML to this point is that the only parts of either SysML submission that have executable semantics are those taken from UML 2.0.  This is a concern as there are many SE specific concerns that need more rigor than is represented in these specifications.  In particular the semantics of Parametrics is very loose since the meaningful part is the language for expressing the constraints, and the lack of any rigor around allocations and resource impacts on execution.

There appears to be a spectrum of complexity in various types of problems.  One way to view this complexity is as different dimensions.  Each dimension in this case is disjoint just as dimensions are disjoint in a coordinate system.

 

The simplest class of application would be basic business applications because they often only deal with one dimension.  They have a very clear sense of objects representing the real world entities such as Customers and Orders.  Furthermore the objects only exist in the computer as far as the application is concerned..

 

The next level of complexity might have 2 dimensions: the data and the real world.  If the business application above was tracking physical paper work and computer only workflow artifacts for example, there is an added dimension of complexity.  There is the dimension of the data representation of physical things, and the data representation of data only things.  You would not want to get those mixed up as their needs and the handling of these two types of objects are different.  This does not prevent them being used together, just that they must be treated separately.

 

So far only applications that involve one "meta" level have been looked at.  So to add another dimension imagine the application used a code generation framework.  The developer uses the framework to model the paperwork and workflow objects.  While the model needs to represent both the paperwork, and workflow classes, they are not the same thing.  If you only cared about the computer view of things, you might choose to treat them similarly, but if you needed to actually care about the physical paperwork you could not treat one kind of class as the same as the other kind of class.  So in this example we have 3 kinds of classes.  There are classes in the framework that are used by the model of the application.  Those classes have instances that are in fact the other 2 types of classes.  When a class has instances that are themselves classes, they are called metaclasses.  In addition to the framework metaclasses there are the paperwork classes and the workflow classes.

 

Now to add even more dimensions lets look at adding to the mix a simulator for the workflow parts of the system.  There would be classes in the simulator application, and there will be artifacts added to the model to represent the simulation aspects being applied to the workflow classes in the model.  These might include probability distributions, and parameters for typical wait or arrival times.  Now imagine this is a distributed application where workflow messages must be sent using web services where there are classes produced for the workflow activities to be visible as web services.  We now have an environment with 7different dimensions or types of classes: Framework metaclasses, paperwork classes, workflow classes, simulation model artifact classes, simulation application classes, web service interface classes, and web service software classes.

 

Modern modeling systems, and System Engineering systems in particular, have these and many more dimensions of complexity.  There are many different types of classes to be represented in the design and analysis of such systems.  The complexity is even higher when an artifact in one dimension is an instance and in another dimension is a class.  For example a common pattern is to represent states in state machines as classes.  If I was to simulate the execution of a state machine i would represent each state as a class with each instance holding simulation data about an occurrence of that state.  But, in the earlier model a state for the paperwork is not a "real" thing.  It is a conceptual thing.  There is no object attached to the paperwork to track what state it is in.  So from the application perspective the state of paperwork is not a class.  You might have a state in the description of the adjoining software to track the state of the paperwork, but that is on yet another dimension.  There exist representational relationships between dimensions, and even "physical" relationships between multiple dimensions which all have software as their "physical" representation.  This is one of the strong points of software, and one source of complexity.

 

Modeling systems like UML and SysML have this in spades, and systems that describe themselves often have this even more as in MOF or other reflective systems.  There exists the need to separate the dimensions of classes in these systems to keep things clear.  Currently UML does not make this type of distinction easy to represent.  UML has classes for all things class like.  It is possible to use stereotypes to separate different dimensions of class.  In the case of SysML I encourage the separation of such dimensions which are currently all being called "Block" for the sake of uniformity.  For visual notations like UML and SysML the visual notation should also be distinct for things that are in the application/system domain, and those that are in the simulation or analysis domain.  I also encourage that those concerns like simulation and analysis be represented in an adjoining model rather than mixed in with the application/system domain.  For example place all probability and simulation aspects into a SysMLSimulation profile where you might represent constraints and states as classes for simulation purposes, without mixing those concerns into the system model where they are model objects not classes.

I was unable to participate in the full call today, but there were several points of interest.

 

A long discussion was had comparing the traditional SE perspective of a system model and the realization of that model/design, vs. the UML inspired class/usage/instance view.  In the traditional SE perspective there is no attempt to "reuse" a definition.  If there are 4 tires on a car that happen to be the same make and model the constraints on those tires are repeated for each of the four occurances.  The added complexity of usage vs. definition is there to allow reuse.  The constraints or properties of a tire are defined once and replicated to all four positions by usage.  While intuitive to an OO type person, it is not obvious to someone that has not encountered it before.  For larger systems, and in particular software intensive systems it is an important feature of the language, but will need some clear explanation to the SE audience.

 

Another discussion was about instance diagrams.  The SST submission provides for modeling instances separate from their definition.  A new diagram type is defined for this purpose.   I need to review the details of this more, but my first reading left me with the impression that the coverage in the specification was sketchy.  The Partners described a method for representing the same information using stereotypes of the definition diagrams.  This technique could be applied to all diagram types making it more general.  But, it is a bit of a kludge in that the semantics of the diagram change without a change in the diagram itself.  In UML 1.x instances had an underlined title, while classes did not.  This convention could be applied to all SysML diagrams and represented using the Partner method to good effect.  The specification should however explicitly cover the changed semantics.  While I would prefer a separate diagram in the metamodel for instances, the problem is that instances and classes need to be mixed on some diagrams, making the Partner approach more flexible.

 

The last main discussion was about allocation.  My position on this is very strong.  Stronger than anyone else on the call.  When I look at the practice of System Engineering and the past tools in this space, the proper handling of alloation is what sets them apart from the software methods/tools.  Most of the SysML content is small tweaks to UML 2.0.  Behavior is mostly unchaged except for the addition of support for simulation and marking of continous activities. In structure a new type of port was added, with only a small core semantic difference from signals on UML 2.0 ports.  While SysML can capture requirements, all expect a real requirements management tool to do that, so it is really only the tracebility that is key here and can be done as a dependency in UML 2.0.  In other words most of the SysML specifications are "best practices" codified as extensions to UML 2.0 but not fundamentally new semantics to support the SE domain.  What is new to SE is allocations.  The semantics of allocation has been reasonably well codified in several tools for more than 20 years, so this is not new or research level stuff.  Just as you could do OO in classic C with manually preapred function tables, you can do SE type allocations in UML 2.0 or the proposed SysML.  But, the user is having to enforce, and realize the semantics on top of the UML semantics.  What I think is called for is real allocation semantics just as OO languages implement classes, inheritance and dynamic dispatch in the language level semantics.  To do this the allocation of one artifact (behavior or structure) to another artifact (behavior or structure) should cause the target of the allocation to exhibit the features of the allocated construct.  So, if I have a block with 3 properties, and allocate that to another block (logical to physical for example) the target block should exhibit the propertyes of the allocated block.  The target block may elaborate on those properties (assign physical properties to their representation), but the user should not have to manually maintain the semantic of allocation.

Today was the first 4 hour con-call for the SysML evaluation.  This call was very informative, and helpful in getting the submission teams to comment on issues and highlight their approaches to the problem.

 

While the differences between the specifications are important, some similarities are more important.  The most important thing is that they are similar in many of their omissions.

 

The key differences covered today were in Structure (Item Flows, Tunneling connectors, Instance Diagrams), and Parametrics (Collaboration vs. Constraint Blocks).  The early part of the call is a bit blurry.  While some of these differences represent strong positions, they are not insurmountable in considering a merged specification.

 

The key omissions from both specifications include any definition of what the parametric language is (precluding any interoperability in this area), full handling of requirements (a separate requirements management tool is still needed), and any final word on tool compliance or interchange.  There are even bigger issues to come with allocations, and making model semantics more than local syntax, as covered in an earlier post.  These omissions represent a far larger amount of effort than the unification of differences between the specifications.

 

My impression of the call was largely that most of the reviewers represent the end-user perspective.  In that regard both specifications are largely unintelligble, as reported by the attendees.  They did not feel comfortable dealing with metamodeling issues, and left that to the OMG review, and many of the concerns from an SE perspective was not being addressed in an obvious way.  To me this brings into question the SysML specification effort.  If the differences between these two specifications does not jump out at the reviewers, and if the reviewers are not seeing obvious omissions, will this specification be usable?  Does the review inform more about the specification content, or more about the difficulty in digesting the specification?  The format for the specifications is largely that of a reference work.  The sections group elements of similar sub-domains together.  But, this causes a fragmented specification that makes it hard to see the cross-cutting issues represented or omitted from the specification.  The review like the specification is handling each sub-domain in isolation from the others.  I hope there will be more far reaching discussions as the process moves forward and more of the specification is in scope for the discussion.

In computer science there was a turning point in early thinking about software called Structured Programming.  A key paper in this shift was "GOTO Considered Harmful" (Dijkstra 1968) [1].  In this paper it argues that the "freedom" embodied in the Goto is harmful, and more disciplined structure is called for.  Since that time no major programming language has used Gotos.  Part of the reason for this paper's success is that it offered alternatives that met the same need, but had better structure.  In current terminology the use of goto is called Spaghetti Code.

 

I would offer that while less historic, a similar argument can be made for the tunneling of connectors supported in the SST submission.  At first blush it looks OK, after all physical systems have wires that go directly to the inside of things.  Some software people talk about "breaking encapsulation", and others say that is not so horrible.

 

I would like to suggest that this is not the point of components and connectors.  The value to a systems engineer is not in modeling the physical connections, though that is needed for manufacturing and some types of mechanical engineering work.  The value to a Systems Engineer is the logical connectedness and the component interface boundary.  By this I mean that the 3D topology of the component is not the boundary of the component, but rather the logical interface of the component and its environment.  If I am looking at a component as part of a trade study for example, I would want to know all the connections in or out of a component.  Tunneling connectors make this more difficult, obscure, and problematical.  Even though the physical wire crosses the 3D boundary of the component, is is not crossing the logical boundary of the component.  The component simply exposes a port at some point on a convoluted topology.  The wire is not a part of the component, the point the wire touches is part of the component, and part of all nested components that enclose that point.  There is a port present on each level of logical component, and a connector to each nested component port.  They coincide in 3D space, but they are logically there.  The Wire may pass through holes in the surface of a part of a component, but this is merely an opening, the wire does not pass through the boundary of the component.

 

There are several benefits in modeling things this way.  By honoring the logical connections of a component with ports, all inputs and outputs are on the component itself.  This makes understanding the component easier for any reader.  This also makes trade studies, Configuration Management (the kind System Engineers do, not the software type) is more clear, and looking for changes in the connections of an element again is more clear.  All the activities of a Systems Engineer are enhanced by this use of ports and connectors to model all connections of a component, and using the logical boundary rather than the superficial 3D physical boundary.

 

We do not need Spaghetti Models for Systems Engineering.  The use of more discipline to model the boundaries of components is recommended.

 

[1] http://www.thocp.net/biographies/papers/goto_considered_harmful.htm

Unfortunately both submissions seem to follow UML 2.0 into compliance hell.  UML 2.0 started this idea of fine-grained compliance.  A tool can comply with this package or that package.  While convenient for some vendors, so they can claim compliance long before they are done, it is hell for users, and even more so for interchange.

 

The SST group has divided their submission into 3 broad levels of compliance, while the SP team has settled for 2.  Unfortunately they both go on to support compliance at the package level, and to offer various types of compliance (abstract syntax, concrete syntax, xmi interchange, etc.).

 

The result is as many as 80 different combinations of compliance are possible from these specifications.  That means that there could exist 80 different tools each claiming to be SysML compliant but none having exactly the same features of the language implemented!

 

Does it really do much good to have the concrete syntax (notation) without the abstract syntax (meaning).  Other than being able to draw pictures on a whiteboard, is that really a language?  Without the abstract syntax a flow port can aggregate a use case, or a use case can have an association with a block.  While it is probably easier to make a case for the cross-cutting type compliance levels, the package level compliance makes no sense what so ever.  Do you really want a C compiler that does everything but the switch statement?  Do you really want a C# compiler that can do everything but generics on methods?

 

The OMG is about the only standards body I am aware of that has this type of compliance.  All other standards bodies understand that the value of a standard is uniformity, not flexibility for tool vendors to implement the parts they like and ignore the rest.

 

The SST specification does not allow for diagram interchange.  I guess they do not think diagrams have much value to the user.  Does this really make sense?

 

Please stop the madness.  Do not continue with this farce into yet another specification.  It is unfortunately all too easy to read words that form sentence after sentence, that individually sound reasonable, without really getting the overall implications.  It is my understanding that the ADTF has refused to allow for revisions to the submissions before a final vote.  I guess the SysML language and UML are going to be compared to Microsoft.  Only version 3 is worth using.  The only outcome I can see at this point is that we are going to be stuck with choosing between proprietary tools, some of which claim to support a standard that does not standardize much.

 

Michael

How much is the language and how much is the tool?

 

For example if I have an activity flow between two activities allocated to different blocks, and there is no allocation of the flow; does the language say anything about
that?  If there is not even a connector on which to allocate the flow; does
the language have anything to say about that?  And, of course the path of
the flow does not need to be a direct link, it can be an indirect link
through intermediate blocks, connectors, etc.  As a user I would like the
language to specify what conditions a tool must identify as invalid.  This
would make the language semantics much stronger.  After all a programming
language defines a set of inputs that are valid, and by implication the set
of inputs that are invalid.  The problem with the SysML specs and UML specs also, is that far too many inputs are valid according to the spec, but make no sense as a model of something.  There are overall semantics that are not being specified to make the model "mean" something as a whole.

Having reviewed Part II: Structure in both submissions and doing some spot checking in other areas I have the following initial comparison points:

 

1)     SST has a large number of notational entries with no descriptive text at all.  They require notation with no defined semantics.  Even if some of the constructs are direct imports of UML 2.0 they need to define them, and at least provide reference to the UML superstructure specification.  It is totally not acceptable to assume the reader will be so familiar with UML 2.0 that they will just “know” those constructs are from UML 2.0 and what their semantics are.  As a UML 2.0 contributor and reasonably expert, there were some constructs that I was not sure of for source and semantics.

 

2)    There is a fundamental difference in approach between the two groups.  The SST submission takes the position that as much of UML 2.0 should be included as possible, and the SysML group takes the position that as little of UML 2.0 should be required as possible.  The key difference is that the SST group is thinking that anything not in the spec is unavailable, while the SysML group is aware that the SysML profile applied to a UML 2.0 tool can use any UML 2.0 feature, and have chosen to require the minimum set of UML 2.0 features to support SysML.  From an implementation point of view the SST submission requires a full UML 2.0 implementation, while the SysML allows for an implementation that is more focused on SE and omits the more exotic UML 2.0 feature set.  As a potential vendor of tools to the SE market the cost of entry for the SST spec is far too high, while the SysML spec allows a more staged entry into the market.

 

3)    The specification of the abstract syntax for the two specifications is quite different in quality and accuracy.  The SysML specification provides the full path name for metaclasses, while the SST specification in many cases omits the full path name or in some cases provides an incorrect full path name.  Because the UML 2.0 specification has many classes with the same name that only differ in full path name, this is a critical difference.  While the errors/omissions I have found in the SysML v1.0a specification are at the level treatable by errata, the errors/omissions in the SST specification not only are universal but bring the entire specification into doubt.  It is clear from review of the abstract syntax that no machine readable representation of the model exists, and no effort at rigor was made in this area.

4)    

I hI I have seen a strong bias on the part of both specifications toward Activity diagrams to represent behavior, as evidenced by the fact that both submissions extend Activities for the purpose of representing continuous/discrete systems, and to represent probabilistic simulation/analysis.  Neither submission makes any similar extensions to sequence diagrams, state machines, or use cases.  While Activities are better suited for continuous systems than the other behavior models, all behavior models should have the ability to use probabilistic simulation/analysis.

 

5)    In reading the RFP again I encountered the requirements on the submissions to provide a requirements traceability matrix.  While the SysML v1.0a specification has provided all the required information per entry, and appears to have much more specific references and content, the SST submission is missing the required reference for each requirement to the sample problem.  Such an obvious failure to meet the requirements should be embarrassing in a systems engineering specification.

 

6)    It is my understanding that to fulfill the open source license for the 0.9 SysML specification any derivative work is required to show changes from the 0.9 baseline.  While the SysML 1.0a specification team has provided this in their guidance document, the SST team has not provided such a change list.  I question if the SST specification can be submitted to the OMG until such a change list is prepared.

 

That is enough for now.  My next section is cross-cutting constructs which are the parts of the specifications that are most specific to the SE discipline: Requirements, Allocations, etc.

I will be writing about a standards review I am participating in.  The review is for the SysML standard being developed by OMG and INCOSE for the representation of Systems Engineering models.  For those that do not know, the job of a Systems Engineer is to ensure that all the parts of a system work together to meet the requirements, and that the parts are of good quality/design and meet any non-functional requirements such as performances, reliability, power consumption, or weight.  The larger the project being undertaken, the more there is a need for someone to do Systems Engineering.  In projects that are all software this is often called an “Architect” role, but in the arena of large engineering projects like aircraft or government projects this is called Systems Engineering, and is a true engineering discipline.

 

Part of the reason for this review is that there are 2 competing proposed specifications to be reviewed.  Each specification is on the order of 200 pages, and they derive from a common source specification that was called 0.9 before the two developing teams split into competing teams about 3 months ago.  It is surprising how different they have become in that time.

 

As one of the invited reviewers I have an interest in applying the Systems Engineering (SE) discipline to this process.  If this were an actual SE project the requirements would be carefully developed to ensure proper system definition.  This mostly happened in the development of the UML for Systems Engineering RFP.  The next step would be the development of the system with various stages along the way.  That is being asserted to have been done prior to this review.  In an SE effort, a large part of the process is exploration of alternative solutions (alternative sub-systems, alternative vendors, etc).  This review is supposed to perform that function.  And last, the system needs to be verified against the requirements, against the derived requirements, and verified for suitability.  Both teams have submitted matrices showing how they meet the requirements.

 

The rub in all this is not that the steps in the process are being skipped, but that they are not being done well.  For example: the reviewers are being asked to narrow their focus to the “important” parts of the specifications because it is assumed they do not have time to read the entire specification in the scheduled review period (4 weeks).  I am quite confident that this review is going to miss the majority of errors in the specifications because there just is not enough time for a complete review.  These specifications will not benefit from what is usually gained in a peer reviewed paper, let alone what should be expected of an international standard.

 

At least one team is asserting that their specification is ready for adoption (subject to minor errata), when it is clear form a cursory review that their specification has many omissions.  The problem with a rushed review is getting a good measure of the completeness of a specification.  The review should not only look at the text of the specification, but what is missing from the specification.  Ensuring the specification is complete requires looking at the entire text, checking against the requirements, checking for internal consistency, and internal completeness.  I seriously doubt this review will be able to deliver on all that.

 

Neither specification addresses some key aspects of the problem domain: interchange of notated models, and verification of implementations.  While the SE process is being roughly followed in developing the specifications, they do nothing to enforce an SE approach to implementation of the specification.  The requirements on implementations should be as clear as the requirements coming from an SE project.  The verification of implementations of the specification should be as clear as verification of an SE project.  And, the implementations should be able to interchange models and notation.  In the current draft specification each team allows for on the order of 40-50 different compliance points.  It could take 2-5 pages of text for a vendor to describe their compliance with the specification, and you basically have to take their word for it since there is no way to verify their claims or load a standardized model for verification.  The result is going to be a very fragmented market with no two tools implementing the same language.  Training costs are going to be higher, and projects will be locked into the tool they select at the start of the project.

 

My request of the submission teams is to slow down the pace.  Getting a specification submitted for the February OMG meeting is going to result in a bad specification.  Take the time to produce a good specification that can be uniformly implemented, interchanged, and verified.  Take the time to resolve your differences.  That said, if a vote is forced, based on what I have read so far (about 1/3 of each specification), the clear winner should be the SysML v1.0a specification.  I hope it does not come to that, because I consider this only the better of two unfinished specifications.

 

In following entries I will go into more detail into the differences between the specifications, aspects of the specifications, the language, and the usage of the language for doing Systems Engineering.  As I complete my personal review of each section I will summarize my findings, and start to put each capability into context.  I intend to be hard on both teams, with the goal of producing the best possible specification that politics will allow, then helping the users and vendors make the best of things going forward.

 

All statements on this blog are of course my personal perceptions and do not reflect the opinion of any organization or other individuals.  I will where possible provide reasons for my statements, but some times there are subjective assesments that can not be reduced to quoted text.  Some of the subjective statements may be personal preference, and some is the result of 30 years of working with tools and systems, I leave it up to the reader to judge my comments, as always.