Components

["Brian Carroll" <BCarroll@xxxxxxxxxx>]

ALF Colleagues,

 

In the ALF SCM vocabulary discussions on May 3^rd, the group recognized the need to have a definition for “Component”.   We also touched on the notion of a Version Specification and a way to specify a collection of versions.  I had volunteered to write up Component, which turned out to be a bit thornier than one might think.

 

Also, I've been working on a data model rendering of the definitions, though not as far long as I would have liked.  I started out with the Eclipse plugin, hyperModel, because it has some nice features for converting from UML to XML Schema, though I became disappointed in the usability, help, and features. For example, the physical layout of classes seems to be determined by containment relationships - I have not found a way to override or alter the layout.  Have switched back to Visio, and have made some progress with that, keeping mind that what we need is an "external" or "interface view" of the concepts, not an "internal view" as an SCM tool would have.  My try hyperModel again once we get agreement on the Visio diagrams, as the prospect of keeping the two representations in sync by generating the XML Schema seems attractive.

 

Regards,

Brian

Components

[Definition]A component is a collection of elements that have a logical relationship to a larger unit of functionality.  

[Discussion] The elements of a component work together to provide a function, such as implementing a capability or interface.  The set of elements in the collection may vary over time, and those elements themselves may evolve over time (i.e. have different versions).  Component is a logical term that represents a unit of functionality.  Since their composition changes over time, Components are versionable objects, like files and folders.  But unlike folders, which are physical collections of objects, Components are logical collections.  Outside the SCM system, say, in a workspace on a developer’s computer, there is may be no explicit representation of the files that make up a component, other than artifacts such as build scripts or dependency files.

[Alternative 1] It might be simpler to define a Component as a enumerated list of elements that have some logical relationship to a larger unit of functionality, and then letting the Component be versionable, so that we can track the changes in the elements of the set as they change over time.

[Alternative 2] A practical approach would be to not define Component at all unless we identify user cases for it, e.g., SCM systems that support it.  I sense we all feel that Components is a useful notion, but it simply may not be well enough defined by existing SCM tools to address at this point.

Component Version

[Definition] A Component Version is a set of collection of versions that correspond to the elements of a component. That is the set of elements in a component that meet a version specification.

 

[Discussion] We can compare and contrast Component Version with the notion of ChangeSet and Baseline. All represent a collection of versions, but what differs is the rule for determining what versions participate in the set. For example:

• Baseline – an intensional description in terms of the higher-level folders or some path common to the version graphs (e.g. TIP)
• Change Set – an enumerated list of the versions associated with an Issue
• Component Version – an enumerated list of the versions associated with a larger piece of functionality

Version Specification (or Version _expression_)

[Definition] An _expression_ that defines a set of versions.

[Discussion]  There are two ways to specify a set of versions:

·        The first way is to make an explicit list of versions. This is the same as the mathematical notion of the extension of a set, that is, an explicit enumeration of the elements.  For example {}

·        The other is to define a logical _expression_, such as “1.0 PRODUCTION branch”. This like the mathematical notion of the intention of a set, a specification of characteristics that determines what is in the set. For ex

A Version Specification is a grammar that allows one to designate a set of versions based on branch, label, checkin date range, last-checked-in-by.  The use of a grammar allows more than just basic expressions to be represented, such as ‘LABEL=”PROD” AND “Last-checked-in-by’=”JOE”’

Note that an awkward aspect is that our current notion of version is not simply a revision designation, such as “1.4.PROD” but the definition ties a version to an element. 

Observations and commentary

In the process of trying to describe these concepts (especially Version Specification), I ran into some more fundamental issues with our terminology:

 

As it is currently, a version includes the element. That is a version is “foo.java, revision 1.2.3”, not simply “1.2.3”  It might be clearer if we had a term for the version designation “1.2.3” independent of the element.  For example, with might consider the following terms:

·        Element – just as we currently define it. The present definition seems fine.

·        Version – a notation of which revision of an element we are referring to, independent of the element.  For example, the “1.2. PRODUCTION”. In other words, the term version would be a version designation only, not tied to the element.

·        ElementVersion – Element + Version.  A specific revision of an element as designated by the element name plus a version. (This is what we current call version.)

 

 

 

Brian Carroll
Architect, Eclipse ALF project
www.eclipse.org/alf
Serena Fellow
Serena Software
(ofc)  (503) 617-2436
(cell)  (503) 318-2017
bcarroll@xxxxxxxxxx 

 

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.