Use Case Extension Points vs. Generalization

[Paolo F Cantoni]

An aside... Technical forums are best left for technical responses. Clever verbal snipes only serve to disrupt the spirit and good will of the online community.

Where was the clever verbal snipe?

I try to be very precise in my responses...  You are invited to observe my postings over the last couple of years.

Jim has said he's had trouble understanding where you're coming from.  I'm in the same boat...

It seems to us (and I'll speak for Jim here - he will correct me if I'm not saying what he would) that your view of how UML works and our (hopefully, more mainstream) view differ sufficiently that we can't actually align our metamodels.

Speaking for myself, now, I believe I have an inkling of why you're having problems (and thus posted in the first place), but since you don't seem to be "getting it", it's really difficult to get it across.  It sounds a bit to me like a paradigm shift problem.  There's usually a gap that has to be crossed in one step to complete the paradigm shift.  Unfortunately, the gap can't be crossed in more than one step.

As I said before, others may be able to help.  Jim and I have tried - obviously, we're not able to.

No malice intended.

Paolo

[jeshaw2]

I agree with all that Paolo has said.  I feel your "clever snipe" accusation is an affront to the honest attempts we have made to help you, so this will be my last post to this thread.

I'll leave you with the following thoughts:

• At some point, the topic of this thread changed from the UML to a methodology discussion
• I understand what you're trying to build as an application;  what I did not understand was your development methodology.
• Paolo and I model application systems that are industrial strength with issues too complex for anyone to hold in their mind at one time. Development projects for industrial strength systems have high risks that justify DIM/CIM modeling and involve hundreds of use cases.
• I suggest that the risks associated with your CD Catalog application are too low for you to see the value of that which we are recommending for inclusion in your methodology.

I wish you well.

*POOF*

[ASP]

> Where was the clever verbal snipe?
"If you don't get any other responses then (since you say you are new to UML) it may be that you are experiencing a scotoma."

Merriam-Webster: "a spot in the visual field in which vision is absent or deficient"

Surely, you could have expressed yourself more eloquently, rather than basically telling my I have a blind spot and "don't get it."

I repeat what I stated in my last post. Forums, especially technical forums, are about helping each other in earnest. I appreciate your attempts, but the fact that I still "don't get it", in your mind, is just as much a testament to my not understanding the issues as it is your not being able to effectively answer a question.

Granted, you seem to be well-versed on the subject, though I am not yet capable of ascertaining how well-versed you are, since I am new to this material.

Also, I'm impressed by your proposing/defining additional layers of models around the existing OMG models. However, that is irrelevant to my question.

I've made an honest attempt to pose a serious question, and I've done so with examples. I trust there are others who have similar questions but are hesitant to post them, because they do not wish to be embarrassed by "gurus".

I still appreciate your attempts, and I thank you for your efforts. I am sure there are members here and in other forums who are both knowledgeable and willing to provide helpful assistance that remains on point, without the condescension. Heck, I expect to fully from my scotoma, once such members respond with clear and concisely targeted answers, so that even I can see the solution. (...and I bet they'll be humble, too...)

[ASP]

jeshaw2...

> I feel your "clever snipe" accusation is an affront to the
> honest attempts we have made to help you, so this will be
> my last post to this thread.
Then you won't mind my responding. If interested read my response to Paolo regarding the snipe.

> At some point, the topic of this thread changed from the
> UML to a methodology discussion
From my initial post to this thread...

"First, I'm new to UML and EA, so bear with me. I'm working on a CD cataloging application, and I figured the project would provide me with a good opportunity to learn a subset of UML (I've eliminated any business process modeling, as this does not apply to this project)."

From that point forward, methodology (namely, the unified process) has been integral to this discussion, and you would see that if you've bothered to read my posts.

> I understand what you're trying to build as an
> application;  what I did not understand was your
> development methodology.
...which is precisely the reason for my starting this thread.

> Paolo and I model application systems that are industrial
> strength with issues too complex for anyone to hold in
> their mind at one time. Development projects for
> industrial strength systems have high risks that justify
> DIM/CIM modeling and involve hundreds of use cases.
...and I congratulate you on your achievements, but what on earth does this have to do with the price of tea in China?

> I suggest that the risks associated with your CD Catalog
> application are too low for you to see the value of that
> which we are recommending for inclusion in your
> methodology.
...and I agree completely that the risks are too low. It's a simple project for crying out loud, and I made that clear from the beginning. My point is to begin by learning a subset of UML while working on a project of manageable size using Enterprise Architect. I already have the class model in mind, but I am forcing myself to start anew and incorporate the unified process methodology, using UML and EA. I've already seen clear advantages to doing so, which I would have missed had I simply used my existing methods. Is that not the nature of learning? I welcome mistakes as I delve into UML and design methodologies so that I may learn from them, and I don't care how many times I start my project from scratch. I have absolutely no problem discarding my work and starting fresh, so long as I learn from doing so. For example, I appreciate a response to this thread early on by "peter.zrnko", which led me to discard what I was doing and redesign that part of the use case model he addressed. Guess what, not only did it clear up my model, but it was eloquently simple and addressed my concerns beautifully. Mind you "peter.zrnko" is only a "full member" and not a "guru", so maybe that played a role in his clear and concisely targeted answer to my question, but I could be wrong.

So, while I appreciate the daunting issues facing "development projects for industrial strength systems", why mention this in the context my lowly simplistic single-user project? Do you want applause? Here, I'll salute you and give you a standing ovation. Then I'll turn around, nod my head from side to side, and walk away with a smile, realizing I have just wasted my time listening to a bloated windbag.

> I wish you well.
I doubt that...

> *POOF*
See what I mean? You've let out all the air...

[thomaskilian]

Funny which people sometimes appear and disappear. If you're so thin-skinned you better should not expose yourself to a BB. Go and read a book.

My first and last post to this thread.

[ASP]

> Funny which people sometimes appear and disappear. If you're
> so thin-skinned you better should not expose yourself to a
> BB. Go and read a book.  
>
> My first and last post to this thread.
Thank you for your brilliant insight. However, you have contributed nothing to this thread. (Is this a trend here, where "gurus" are self-important and say nothing meaningful?)

[KP]

Still, I fail to see the reason why it is necessary to define classes at this stage of the game.

Just my opinion, but I actually think you could've started earlier with the classes. I would always start to build a domain model before writing use cases as a way of ensuring a consistent vocabulary. The classes in the domain model have very little to do with the classes in your C++ source files, but they are useful "nouns" to give context to all those "verbs" in the behavioural model. Don't worry that you might be committing to design decisions too early in the lifecycle - you aren't.

Have read of this: Section from book on Domain Modelling by Craig Larman.

[ASP]

Thank you for the reply.

> Have read of this: Section from book on Domain Modelling
> by Craig Larman.
Excellent. I am ALWAYS up to reading a good white paper, and I certainly appreciate your bringing it to my attention. Just a quick question about your opinion in starting earlier with classes. At what point would you begin class design; after the requirements model or elsewhere?

On a side note. I apologize for the bickering in this thread. I am here to learn, and I really do not respect the ivory tower arrogance of some in here. Yet, I believe they are the exception and not the rule. I trust I will learn from others, who are equally knowledgeable or even more so, and who will not be condescending. That is not to say that I will not learn from the arrogant ones, though it will require I separate the wheat from the irrelevant, tangential chaff; you know, the "stuff" that's said to self-promote and pat oneself on the back.

[ASP]

KP,

Once again, I want to thank you for your recommendation regarding domain modelling; it was VERY insiteful.

Important points:

1. Domain modelling is a subset of the Unified Process Business Object Model.

2. Domain modelling conceptualizes the system's features and requirements. Here's is where terminology has tripped me up in the past. I haven't seen it described this way, but that is essentially the concept. Instead, I've seen plenty of references to how domain modelling relates to business entities and business rules, even in the link you provided. However, Mr. Larman does an excellent job of clarifying this in terms understood by software developers.

3. In the unified process, implement domain modelling completely in the elaboration phase. The inception phase is suited for requirements modelling, which includes the system's use cases.

4. Avoid "analysis paralysis". Don't over-engineer the domain model, as this risks "design creep" in the elaboration phase. Domain modelling should be completed in a few hours once the requirements/features are well-understood, and it should not require very many iterations. Design should be relegated to the construction phase in UP.

Very cool indeed. This answers some of my questions. After reading Mr. Larman's work, I can safely say that I'm not too far off the mark yet. However, I will have to reconsider my current work on the project, and I will GLADLY do so. Happily, thanks to your referral, I've learned something.

My current work can be quickly summarized as follows:

1. Defined requirements (still needs work)
2. Established use cases that trace to the requirements
3. Created sequence diagrams for the use case scenarios

Based on the reading, a re-work should likely proceed as follows:

1. Define requirements
2. Establish use cases that trace to the requirements
3. Create a domain model
4. Create sequence diagrams for the use case scenarios

I suspect my sequence diagrams will change once I truly define the conceptual perspective of the system in the domain model.

Thanks again, KP.

[bioform]

I myself find I try to:

1. Understand the customer's Business Process currently and the need to for this "system". This helps me to capture both the "classes" from the business domain, and identify the use cases that trace to the proposed features of this system, and the business domain classes that those use cases make use of.. So in my mind, Business Domain Classes and Use Cases are developed iteratively together...

The BDCs help us establish that common business vocabulary (the things of the business) and the use cases the processes that the system will support (the how of the system, use within the business.)

2. Then once I have an understanding of this, the requirements (both functional and non-functional) will begin to be identified and specified. But without a UC and BDC model it is VERY difficult to SPECICFY requirements (I emphasize the word specify, because we are attempting to document the specification of the system, we are both talking about apples, not my apple, your orange.)

REMEMBER we NEVER have a full understanding of the customer’s requirements at any point in a project, as the requirements are continuously emerging and being clarified. This is where the ability to manage the requirement change is critical.


A SIDE note: PLEASE understand that it is EASY to be misunderstood in forum postings, and it is BEST to assume we are miss interpreting someone else's postings and are reading in attitudes, etc. I have found these individuals who have posted in response to your query, to be VERY helpful, and willing to take the time out of their professional life to help the EA community.

No one who posts here is required to share their knowledge, or to take the time to respond. They are doing it because they want to (for a variety of reasons), so give them the benefit of the doubt, and realize we all like to be appreciated when we give of our free time.

[bioform]

On the point of Extension Points vs. Generalizations, I think they both can be helpful, but I tend to prefer using generalization/specialization concept.

I often use a generalization to assist in the modeling, and then use a specialization of the use case, rather than having a large number of alternate scenarios.

Additionally, by keeping my use cases (when appropriate) in this style, my scenario numbers are reduced for a specific use case, more focused/specific to the use case, and I can then represent the scenario path/script using activity diagrams, which I find my customers is able to understand more clearly. Also since I use code to evaluate my activity diagrams (and generate a descriptive dialog that describes the interaction between the actor(s) and the system) I can then map these back to the UC's defined (Basic, Alternate, and Exception) scenario names.

[ASP]

bioform,

Thanks for your reply. Yes, your points make a good deal of sense, and they concur with the "Domain Models" PDF that KP, the administrator, recommended.

> A SIDE note...
I accept your constructive criticism; truly, I understand your point. However, I've been on enough forums to see the writing on the wall, and I will call a spade a spade.

[ASP]

bioform,

> I often use a generalization to assist in the modeling, and
> then use a specialization of the use case, rather than
> having a large number of alternate scenarios.
I may be wrong, but I think we are talking about two slightly different things. When "peter.zrnko" responded to my post, he advocated using <<include>> and <<extend>> stereotyped use cases as little as possible, and he stated his assertion was backed up in the UML literature. After I followed his suggestion, I reduced the spaghetti visuals that were developing in my use case diagrams. That also led me to re-evaluate each use case and its scenarios. Thus far, I have managed to reduce the number of scenarios to maximum of 3 (possibly 4) scenarios for any use case.

That said, I still have found use for what I believe you are stating. That is, I have instances of use cases that, in turn, are general use cases for specialized use cases.

Also, I still see the need for <<include>> and <<extend>> in my system, but I will use them sparingly - only when there is no other option.

Thanks again.

[Kevin G. Watson]

  Or make us chuckle (clever asides that is)

You seem to be using use case's to describe a configuration (forms, mvc. and intend to use C++)....

Boundary, Control and Entity are objects... your just not naming or classifying them yet.

Kevin

[ASP]

> You seem to be using use case's to describe a configuration
You're right, and that is premature. I did have MVC in mind at the time, but I may rework my sequence models based on the domain model. In fact, this is brought up on the PDF described earlier in the thread.