Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Paolo F Cantoni

Pages: 1 ... 349 350 [351] 352 353 ... 395
5251
Uml Process / Re: Manifestation as Realization
« on: September 19, 2005, 10:11:04 pm »
Quote
Hmm,  bruce definition of component is something deployable.  IOW on my planet the only components are Not Source.

Seriously (don't call me Shirley) I have never considered the deployable source before  - but in your (MDG) case, I suppose it is!  

This opens up a new world of mind bending possibilities.  Is UML capable?  Never mind, as long as the intent and message of the model is correct, bugger the grammar.

bruce
I agree that components should be deployable, but as you concede, that doesn't restrict them to physical components.  I may deploy a configuration directory, etc etc...  If they aren't Components (using the Bjelke-Petersen Duck Test ;D) then what are they?

Paolo

5252
Uml Process / Re: Manifestation as Realization
« on: September 19, 2005, 08:50:10 pm »
Quote
I thought it was "the code in file 'xyz' manifests the model element 'class abc' " ???

cf object 'Mike' realises class 'person'

then "the code representing classes Ahab, Bhab and Chab are realised in the (deployable) component 'pf_magic' which is manifested on Win as pf_magic.dll and on Lin as pfmagic.so


 ???

bruce
Yes, this is true for physical components (dlls, assemblies, SOs), but I'm talking about logical (source) components.

Or perhaps source components don't exit?  (Serious question).

Paolo

5253
Uml Process / Re: Manifestation as Realization
« on: September 19, 2005, 04:21:34 am »
Quote
I too struggled with the manifestation link in UML 2.0 for, oh, minutes I guess.   ;D
Me too, that's the problem! ;D  When the rubber hit the road, it slipped!
Quote
Actually, I did finally guess that it has something more to do  with poltergeists than realizations.  IOW rather than the forward looking realization, "This begat that begat the_other", it is more to do with "this left that behind".
Now that's interesting!  I view both Generalization and Realization as backward looking... "I came from there..."  Which, I think, is in line with Client to Supplier direction...
Quote
Anyway, it all became too ethereal for me at that point so I forgot all about them.  Looking forward to more viewpoints though.

bruce
I now have the problem of formally emitting code that represents classes.  If I make the manifestation a Realization then I can narratively say:  "This ComponentInstance includes this ArtifactInstance which manifests this realization of that Class."

If I make it a dependency, the equivalent verbalisation doesn't make sense...

Cheerz,
Paolo

5254
Uml Process / Manifestation as Realization
« on: September 18, 2005, 08:41:59 pm »
This one is a bit heavy...  I think the UML 2 Superstructure Specification is self inconsistent.

In 7.3.45 is states: Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc

In 10.3.10 Manifestation (from Artifacts) A manifestation is notated in the same way as an abstraction dependency.

This would imply it is denoted as (or similar to a Realization).

The specification then goes on to say... i.e. as a general dashed line with an open arrow-head
labelled with the keyword «manifest».


I would have thought it would be more appropriate to show it as a Realization with stereotype «manifest».

What do others think?

EA follows the specification.

Paolo

5255
Uml Process / Re: Composite vs Component
« on: September 19, 2005, 07:13:56 am »
[
Quote
Quote
Also, the Interface type is only for containment purposes.  That is, they exhibit the Item Interface with the required policy implementations to implement the policies attached to this particular Container...  (Hopefully that makes sense?)

I think I understand. But surely, you don't mean that the item interface is exclusive to a particular Container?
Yes and No..  I'm saying that the Container will accept as items only those Objects that provide the item Interface it requires.
Quote
Besides, I specified very carefully, the ONLY interface they need to be consistent on is the Item (in container) Interface...

Quote
But then again, perhaps you do mean that...
See above...
Quote
This interests me...it gets at a thought-seed I've been nurturing in my head.  At the Java level, implementation of an Interface only requires a class to provide methods (and perhaps attributes) that have names identical to those in the interface declaration.  There are no restrictions on the behavior exhibited by those methods.
This is where Design by Contract comes in...  If your implementation of the Interface violates one of the conditions of the contract - then it's not much good and the requrier of the interface has every right to Exception at that point.  This is the essence of Eiffel's power.  Both sides specify their expectations of the contract and the Interface will Exception when the contract is violated!
Quote
Does your use of the term "policy" imply that there may be Container specific behavior specifications that must also be realized in the Java code?
Effectively yes..
Quote
My thought-seed is that a model in UML goes beyond what is to be coded in a language to how it is to be coded to achieve a complete realization.  Many students don't understand this! And that lack of understanding leads to their confusion on drawing and reading UML diagrams.  For example;  At the Java level, navigable associations are implemented in code with an attribute containing a reference to the associated class.  However, the nature of the UML association (aggregate, composition, dependency, etc.) places restrictions on how the programmer may use that reference.  Those restrictions (policies?) are not enforced by the Java translator, but by the  quality control team reviewing the code for compliance with the specifications expressed in the UML model.  My postulate is that I may extend this concept to a more general abstraction that covers a global relationship between UML models and their realization in code.  Since this is obvious to experienced UML modellers, this concept is rarely expressed to students; and they just don't get it for a long time.
I believe my use of Policies and the use of Design By Contract conditions makes these things explicit.  In my experience there's no such thing as the "bleeding obvious".  Everything should be explicit!
For example, You can only apply Collection specific policies to a Collection.  A Collection requires a shared aggregation and so on... You can define these kinds of rules and validate the model against them.
Quote
My observation is that UML diagrams prepared by programmers are more code centric and those prepared by Architects are more business centric.  This is the fundamental problem of "round-trip" code generation that will take better minds than I to resolve.
As an Architect who actually codes I can attest to the dichotomy - but I resolve it by saying that, in principle, one can get from a CIM (Computationally Independent Model - that should be business (and environment - world) focused) to a PSM (Platform Specific Model - that is focused on a particular deployment model) ONLY by a defined series of transformations.

HTH,
Paolo

5256
Uml Process / Re: Composite vs Component
« on: September 19, 2005, 06:32:17 am »
Quote
Paolo;

Should this read...

Surely an item can be a sibling of another item which happens to be a logically nested container...
Yes, it should read

The item can only be inside its innermost container

A slip of the mind ;)

Paolo

5257
Uml Process / Re: Composite vs Component
« on: September 19, 2005, 01:57:53 am »
Quote
Does this mean I cant put loose screws in the fruit bowl, or use my toolbox to hold my lunch?  And what about those things my son puts in his posckets?

Methinks even interface homogeneity may impose unwarranted restriction.

JM2CW

bruce
Not if de guys wid de violin cases say youse can't...  ;D

Besides, I specified very carefully, the ONLY interface they need to be consistent on is the Item (in container) Interface...

Cheerz,
Paolo

5258
Uml Process / Re: Composite vs Component
« on: September 18, 2005, 10:17:49 pm »
Quote
Agreed, but for clarification I would also add that: "Containers may hold either a homogeneous or a heterogeneous set of object types."  Should I also add the constraint:  "as long as they all implement a common Interface type?"
Yes, Agreed!

I'd forgotten that - I think I have policies that govern the homogeneity of contents.

Also, the Interface type is only for containment purposes.  That is, they exhibit the Item Interface with the required policy implementations to implement the policies attached to this particular Container...  (Hopefully that makes sense?)

Cheerz,
Paolo

5259
Uml Process / Re: Composite vs Component
« on: September 17, 2005, 08:06:25 pm »
Quote
So, Component Is-A Container.  This would be a significant differentiation feature...
Yes Jim, I think we need to find "differentiation features" between the different constructs to enable us to create better models.  I don't have the attributed quote with me at present, but it goes along the lines of: "All models are wrong, but some are useful..."  We should therefore strive to produce more useful models.
Quote
Container objects are designed to hold other objects, including other containers, without concern for the types of objects being contained.
Just so... In general at least, but there are some conditions, from time to time... A colander isn't much use for holding liquids.  Sometimes the nature of what you wish to hold imposes constraints on the container.  For example, a Source (logical) Component doesn't hold binaries.  I have found a way to handle these constraints between the container and contained by means of Policies and Policy Implementations that act as "enforcers" of stereotypical behaviour.
Quote
Other objects may access the contained objects freely.  Contained objects are not hidden.
Here, my view is that both these behavioural aspects are managed by the types of policies that may be applied to the container and contained.  One could certainly argue that (by default) contained objects are public, but I don't think there is a requirement of it to be so.
Quote
A composite is composed of other objects, but the typing of those objects is restricted specific types and outside objects normally do not have access to them.  Component objects are normally private.
Now this is where things get interesting, in my view.  From meronymy we learn that the "composition" works both ways... The set of types of the composition is governed by the composed object (parent).  But also the type of the composed object is determined by the types of the composing objects.  In my recent musing on this subject, when we look at a composed objects, we need to distinguish between those components that are essential to the composition and those that are just optional adornments.  Over twenty years ago I created the problem of the yellow Rolls Royce:  "I have before me a red Mini, I change one panel/part.  Do I still have a Mini?  I keep changing panels/parts until I have before me what looks like a yellow Rolls Royce.  At what point did I stop being a Mini and become a Roller?"  Answering that question often provides an insight into what is actually going on.
In other words, look at what is essential and what is adornment, for determining the composition.
Quote
Containers (ergo, components) hold collections, composites own their parts.

Am I getting closer?
Since you seem to like my shorthand, here's some ideas:

Containers hold things.  They have to be able to hold the kinds of items you need to put in them.
The types of things held in containers are usually (but certainly not exclusively) not of the same type as the container.
The types of the contained items do not define the container.
Each item can be on only one container at a time. (The item can only be inside the innermost container)
The item needs to know which container it's in.
The container may hide (some or all) the items.
Destroying the container doesn't necessarily destroy the contained items (but often may).
Destroying the contained items never destroys the container.

All containers define collections (even if only implicitly  - the objects contained)
Not all collections are containers.
Collections collect(group) things.  They have to be able to collect the kinds of items you need to add to them.
The types of things held in collections are not of the same type as the collection.
The types of the collected items do not define the collection.
An item can be in more than one collection at the same time.
Often the item knows which collections it's in, but sometimes it doesn't.
The collection can never hide the item.
Destroying the collection never destroys the items.
Destroying the items doesn't necessarily destroy the collection, but may.

Composite objects define the types of the components.
The types of the components define the composite (some types are there for adornment and are not intrinsically part of the composite).
A component can only be in one composition at a time.
The composite may hide (some or all) the components.
Destroying the composite always destroys the components.
Destroying the components destroys the composite.

NOTE: in all cases, the items can be removed from the container/collection/composite.  It may be a policy to allow an item to self-remove.

Does that help things?  You should find a clear set of differentiators to allow you to work out which kind of thing you are dealing with.

NOTE; this is still a work-in-progress.  Feedback most welcome - especially where mistakes have been made.  I'm just as eager to get this right as the next...

Cheerz,
Paolo
[size=0]©2005 Paolo Cantoni, -Semantica-[/size]

5260
Uml Process / Re: Composite vs Component
« on: September 16, 2005, 09:29:31 pm »
Quote
Paolo;
 Can you elaborate on this?  What do you mean by "others"?  Structured Classes can, at least in Java, implement multiple interfaces too.
I just mean the other container types I'd listed...  Not a general comment.

Should have been more precise...  :-[

Paolo

5261
Uml Process / Re: Composite vs Component
« on: September 16, 2005, 07:36:56 pm »
Well,

FWIW, I'm emitting a Component as a Container with Interfaces.  That is, its primary Inheritance is as a Container (such as Model (EA Repository), Subject (EA Project), Package etc.  It (unlike the others) also has one or more Interfaces.  

From my quick overview of the two chapters, it seems to me that Components are a subset of Structured Classes (that is, of Composite Structures).

So, in that sense, I'm agreeing with both Jim:
Quote
I postulate that the subject two concepts had their genesis in two different areas of applied computer science and are now, perhaps, merging.
and Thomas:
Quote
I'd say that Components are related to things which at last execute something (containing classes) while Composites are more generally looked at as any construction of UML Elements.
 ;D

Paolo

BTW: the emitted Component is also a Namespace.

5262
Uml Process / Re: Dependencys
« on: September 15, 2005, 03:16:50 am »
Quote
So for my pastime I thought I'd post a bit in German since these Aussies started also a cryptic post I could not understand :'(
Let's be clear, the post is unlikely to have been started by an Aussie,  more likely a POM (Englishman)! ;D

If PhilB will identify his nationality, we can put this one away...
Paolo

5263
Uml Process / Re: Dependencys
« on: September 14, 2005, 10:15:49 pm »
Quote
[size=13][SNIP][/size]
Also, inherited dependencies could become very unwieldy if automatically created.  Consider the .NET collection class dependencies, which not only go back several levels, but could if inserted automatically inserted into models, create false impressions of circular dependencies.  Even worse would be the dependencies created by interface items.
bruce you are, of course, quite right.  Thinking back on what I said (I haven't searched) I think I actually said, that I'd like to pick two classifiers and ask the system to show me any actual/derived linkages.  Then you could pick the ones to show.  That way, the modeller would control the combinatorial explosion but with automated assistance. 8)

Any chance of this Sparx?

Paolo

5264
Uml Process / Re: Dependencys
« on: September 14, 2005, 07:27:54 pm »
Andreas,

Formally, B has a derived dependency on C.

Elsewhere I have stated my opinion that it would be good to have the modelling tool create these derived relationships and then leave it up to the modeller to display them or not on any arbitrary diagram.

As Jim says, the objective is to communicate.  If it's useful, show it - but differentiate it.  Otherwise, suppress it.

On my diagrams, derived relationships are marked with a pukey olive colour and have the "/" derivation marker shown in the appropriate names.  That way, they stand out.

HTH,
Paolo

5265
Uml Process / Re: How to model details of requirements
« on: September 06, 2005, 06:24:55 pm »
Quote
I tend to put tabular or configuration data of this nature in a separate document and leave the system requirements focused on functionality and business rules.

For example, from what you have stated, my first questions would be along the line of
Do the rates change? How often?
Do the structures change? How often?
Does the system need to cope with this?


bruce
Colin,
I agree with bruce on this.  If you think about it in "Design by Contract" terms, what bruce is describing are the "Schedules" that normally attach to the "Contract".  The Contract clauses focus on the responsibilities of each party with respect to some activity or condition.

HTH,
Paolo

Pages: 1 ... 349 350 [351] 352 353 ... 395