Modeling web applications with UML

[mariano774]

Hi

I'm modeling some ASP web applications using UML, and I'm using the Rational Propose.  Using this, you model a web page as a class for which  you define attributes and methods, but what I don't see in the paper is how to model the "#Include File".

I'm not sure if I should model it as a composition association, since the included page does becomes a part of the including page, or model it as generalization to show the attributes and methods inherits, that would be including page inherits from included page

Anybody thought of this before ??

[thomaskilian]

I would use the nesting relation. Just a thought...

[alexj]

Nesting sounds good.

I would go for Aggregation though.

Cheers

[slavko]

Typically I’ve also modeled this as an aggregation.

[Paolo F Cantoni]

FWIW,

I, too, have been struggling with the conceptual difference between nesting (containment) and composite aggregation.

Does anybody have a definitive answer?

My view is: it has to do with a form of visibility...  If you can't see the contained item without opening the container first, you have containment (nesting).  Else you have composition.

In other posts, I've noted that some other products will actually nest the nested element below the container in the browser!

What they do with multiple containment, I don't know.  It would seem that IS allowed.

Thoughts?

Paolo

[thomaskilian]

To me it seems that nesting is a relation that should be used more along with packages. Most "official" diagrams I've seen used the nesting relation only in connection with packages. Maybe to allow representing some sort of tree structure?

[slavko]

I know its not quite UML’ish but I’ve also dragged and dropped other UI diagrams into “parent” diagrams.  When you do this you get 3 options.  Show as a link, Show the actual diagram or show as a frame.  Each has its own benefits, some save space; others can in-effect model linked pages almost like an actual URL.

-Slavko

[thomaskilian]

I know its not quite UML’ish but I’ve also dragged and dropped other UI diagrams into “parent” diagrams.  When you do this you get 3 options.  Show as a link, Show the actual diagram or show as a frame.  Each has its own benefits, some save space; others can in-effect model linked pages almost like an actual URL.

-Slavko

Wrong thread, isn't it?

[Paolo F Cantoni]

To me it seems that nesting is a relation that should be used more along with packages. Most "official" diagrams I've seen used the nesting relation only in connection with packages. Maybe to allow representing some sort of tree structure?

Yes, Thomas, I agree that the UML specs only show this relation in the context of packages, but they don't (as far as I can tell) exclude it's use elsewhere, presumably so long as it is semantically valid to be used at that point.

In addition, a number of tools (including EA) allow it's use fairly universally.

As you say, it appears to be about structural containment.  So what's the difference between structural containment and composite aggregation?

I think I can use (and am using) nesting for Requirements decomposition.  I'd like to use it in other places, but first I have to understand its applicability.  To understand its applicability I need to understand its nature...  Hence my questions.

Paolo

[thomaskilian]

I do not make (much/any?) use of nesting relations. For what I'm trying to express, simple stereotyped relations seem to be good enough. Probably my kind of work is not so highly sophisticated to actually make the difference visible

OTOH it might raise the question why OMG introduced a new kind of relation. I suppose the eggheads found a hole somewhere that had to be filled with a nesting relation. Blame me, I can't see that hole

[Paolo F Cantoni]

OTOH it might raise the question why OMG introduced a new kind of relation. I suppose the eggheads found a hole somewhere that had to be filled with a nesting relation. Blame me, I can't see that hole

Hi Thomas,

Like you, I was surprised to see it there...  But on the whole I've found the eggheads on UML2 to be pretty good so far.  What about a Sparxian throwing in their view?  They've implemented it, what was their understanding?

Paolo

[sargasso]

I dont know whether this is the real reason, but I have found the following syntactical use for nesting links in any diagram between (sort of) any element pair.

In some models it is clear what the intent of association links (and aggregation links) mean within the specific context of the diagram.  For example, an association between two nodes in a deployment model adorned with the label <<TCP/IP>>  fairly easily indicates a communication link.  Now add another element - named "TCP/IP stack".  I want to show that the stack is contained within one of the nodes.  Using a nesting link clearly visually indicates to the viewer that I am talking about a different  type of connection here.  

Now, if we start to decompose the TCP/IP stack on the same diagram  into a set of TCP and IP and linked list classes, the aggregation links convey a specific semantic relationship between elements that is again very different from the nesting link between the stack and the node.

IOW, I see the nesting link as a visual highlighter, yes representing "physical containment"  but adding no other implied relationship.

By that I mean the following.  Lets start with something pretty stupid, a class with an inner class that has no logical relationship to the containing class. Say class "fruit" with an inner class of "screwdriver".  There is no logical association, or aggregation, between fruit and screwdriver.  But there is a containment relationship, and one with no implied logical relationship.

Now we wouldn't build this class structure - well no sane coder would anyway - but if we stop the sillyness and talk about a more logical example.  Consider class "tree" with an inner class of "fruit".  Now there will be a logical relationship between the two - maybe even more than one - maybe even multiplicity is involved.  These can be modelled using the appropriate association and aggregation links, each of which conveys that specific logical relationship.  Now maybe the containment is unimportant from the POV of the model, and need not be included.  Perhaps it is even implied somehow in the diagram.  But if I want to explicitly talk about this containment I can use a nesting link.

bruce

[Paolo F Cantoni]

I dont know whether this is the real reason, but I have found the following syntactical use for nesting links in any diagram between (sort of) any element pair.

[SNIP]

IOW, I see the nesting link as a visual highlighter, yes representing "physical containment"  but adding no other implied relationship.

[SNIP]

bruce

Sounds good to me, Bruce, and would be consistent   with Thomas's points.

So, if I understand you correctly, syntactically, "nesting" would only apply to those elements that are able to contain (collections of) other elements?

Back to my observation that some tools will automatically alter the browser when you "nest" one element inside another.  In your example, fruit would appear "under" tree and not be visible, until you "opened" tree.  Does that fit in with your ideas?

If so, do you see any problems with multiple containment (such as the TCP/IP stack in multiple nodes).  Would each node become a branch with a stack elements "underneath" (within) it?

Paolo

[jeshaw2]

FWIW,

I, too, have been struggling with the conceptual difference between nesting (containment) and composite aggregation.

Does anybody have a definitive answer?

I'm not a UML expert, or even a journyman, but I think the onset of nested classes in UML may be in support of a feature lately added to the Java Language.  Here is a link to the Java tutorial that talks about what a nested class and what kinds of problems it solves.

http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html

I have other similar links if anyone is interested...

Cheers
Jim

[sargasso]

problems with multiple containment (such as the TCP/IP stack in multiple nodes).

In that specific example, no. This is because the nested elements would be instances not the TCP/IP classifier.  So each node would have its own object nested beneath.  Why you would want to have that on a model is oos!

In the case of nested classifiers, I cant think of an example where you would want to have the classifier nested in two places.

bruce