Use Case Extension Points vs. Generalization

[ASP]

Hey, folks. I searched the forum but was unable to locate any thread that answered my question; so, here it goes.

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).

First, here is an EA-related question as applies to extension points. I'll briefly describe the use cases I've defined.

The End User (an actor) needs to Add a CD (the use case) to the catalog. Adding a CD can be accomplished in one of three ways: manually, guided, automated.

Normally, one adds the CD details manually by completing some form. Optionally, the end user may wish to add the details via a wizard, which guides the user in the entry process. Regardless of which method of input is selected, there is another option that allows the end user to query an online music database in order to download CD details, hence automating the process as much as possible. However, this third approach is only presented once the end user chooses to enter information either manually or with the wizard.

I've added extension points to the "Add a CD" use case.

Use Case: Add a CD
Extension Points: Guided Entry, Automated Entry

Use Case: CD Input Wizard
Extension Point: Automated Entry

Use Case: Download CD Details from Online Music Database
Extension Points: n/a

The "CD Input Wizard" & "Download..." use cases extend "Add a CD", and the "Download..." use case additionally extends "CD Input Wizard".

Here's the problem. When extension points are defined in EA, they are stored in lexicographical order, and there is no option to reorder them. Therefore, one is forced to position the use cases having the extended association in a way that visually complies with that order. Is it possible to reorder extension points in a use case?

Far more important, does my description correlate to good use case design practices? For example, I could just as easily approach the problem as follows, without extension points.

Use cases:
=========
Add a CD
Manual Entry
CD Input Wizard
Download...

The "Add a CD" is a base use case than generalizes the "Manual Entry" & "CD Input Wizard" use cases. The "Download..." use case then maintains a dependency relationship with the "Manual Entry" and "CD Input Wizard" use cases. This way, we remove the extension points altogether, and the associations provide a more direct traceability to the classes implied by these use cases.

At this point I prefer the extension point route, because I don't believe this simple collection of use cases justifies the implication to define an "Add a CD" (possibly abstract) class. Naturally, the generalization associations in the use cases do not force one to create the classes I mentioned in a class diagram, but the implication is there, where there is no such implication using extension points.

Thanks for your feedback.

[peter.zrnko]

My recommendations:

Keep your Uce Case Model as simple as possible.

Generalization - don't use it at all.

Extension - use as least as possible. Originaly it was designed for the situation, where there is one completly realized UC and the analyst want to extend it with new UC without touching  the old one.
That means the extended UC completely doesn't know anything about the extending UC. Extension point has to refer to something inside the extended UC (Automated entry is not known inside Add a CD).

Inclusion - pretty simple to understand, you can use it. But don't over use it. An UC has to have a goal and bring a value to the actor. Think about it  in this way - An actor has to be happy, when the UC finished.
You can have different levels of UC model. One with UCs that bring really benefits to actors. And second with UCs decomposition using inclusions - common subfunctions are made separate UCs and are included in other UCs.

Alternate scenarios - very usefull and quite simple to understand. I use them nearly in every UC. Unfortunately there is no automatic step numbering  in EA. This made referencing basic scenario from alternate scenario very difficult. BUt nevertheless I use alternate scenarios because they are the most effective way to express an UC. With alt. scenarios you can have one UC with one goal, one actor, one precondition and yet several scenarios. It looks nice from outside - just one UC, and the complexity is inside the UC.

[ASP]

Peter,

Thanks for your reply. With respect to your last point - alternate scenarios - I am actually documenting the various scenarios within the use cases. However, I see your point. If I understand you correctly, you suggest I define a single use case - namely, "Add a CD" - and provide any precondition(s) and all scenarios in this use case. This simplifies the visual design and encompasses all "adding a CD" functionality into one use case.

As I see is, this would result in a decent number of scenarios for this use case, because there are several options available: manual, guided and automatic. For example, manual entry is the "basic path", whereas guided entry is an "alternate" path. Other "alternate" paths occur with the two aforementioned path, each with the additional option of used automated entry, since the purpose of automated entry is simply to assist filling the CD details regardless of which form of data entry is initially chosen.

Additionally, I need to account for scenarios that describe unsuccessful attempts to "add a CD" in the various scenarios described earlier. At what point would you consider breaking out use case functionality when presented with a large number of scenarios?

Continuing, I suppose each scenario can then be further described with its own activity and sequence diagrams, which provide different views.

My largest concern, however, is to eventually translate these scenarios into a PIM. Would you, for example, also create state machine views in order clearly specify the operations performed by class functions/methods?

Thanks for your feedback.

[peter.zrnko]

I don't have any exact number of alt. scenarios which I consider "too many". But you are right, there is a limit.

IMO Use Cases are something like a story and it's not a good practice to convert scenarios directly into code.
If you analyze each UC and describe it using sequence, activity and state machine diagrams, it means you are creating a PIM. Sequence and state machine diagrams are not possible without some classes (usually) and with classes, you have class diagrams.

[ASP]

> Sequence and state machine diagrams are not possible without
> some classes (usually) and with classes, you have class
> diagrams.
Well, yes. Perhaps I was unclear in my last post. I am developing this software within an object-oriented design paradigm, which is why I decided to architect the solution using a UML case tool.

I'm quite comfortable with object-oriented programming. However, since I'm a newbie to both UML and EA, the greatest learning curve is understanding (or obtaining information) for case studies that robustly implement various methodologies. As for now I am focusing exclusively on the Unified Process. While there are plenty of sources that describe the Unified Process (and its numerous derivatives) in detail, I've yet to find any sources that walk through serious case studies (of fictitious companies, mind you).

In short, my problem is not understanding UML and EA; rather, it's understanding how to effectively use UML to architect a complete software solution. Again, I'm deliberately avoiding business modeling.

In my first go-around I began my project by textually defining the features I wanted, after which I dove into designing a Use Case model for the system. However, after some additional reading, with every source having its own take on recommended procedures, I decided to start again with a requirements model. Currently, I am creating requirement diagrams that trace requirements to use cases, which I linked together in the relationship matrix.

In terms of continuing along a path to eventual class design and implementation, I figured the next step is to create communication, sequence and state machine diagrams for the various scenarios in my use cases. However, I quickly hit a wall, because these interaction diagrams would require classes and or instances of classes that I have not yet defined.

See where I'm going?... lol. Right now, I'm wading through the dark in quicksand. What I really need is a sturdy branch, so someone can drag me along the right path.

Thanks again for your feedback.

[Paolo F Cantoni]

In terms of continuing along a path to eventual class design and implementation, I figured the next step is to create communication, sequence and state machine diagrams for the various scenarios in my use cases. However, I quickly hit a wall, because these interaction diagrams would require classes and or instances of classes that I have not yet defined.

To paraphrase an Australian political slogan from 30 years ago...

"It's time!"

The domain (computationally independent, or conceptual) model is chock-full of classes.  They're just not implementation classes.  I model these in a special language defined to EA called Conceptual.

HTH,
Paolo

[ASP]

To paraphrase a Geico commercial...

"Yeah, I'd like to respond... uh, what?"

[Paolo F Cantoni]

It's time to start defining the classes...

Paolo

[ASP]

> It's time to start defining the classes...

Lol... okay.

For clarification purposes, I want to be sure I understand your response properly. Please correct me if I have misinterpreted you.

First, I have not yet completed the Use Case model for the entire system. However, I assume your response makes the assumption I would have done so already, and it is your suggestion that I next design my classes before creating sequence, state chart and other diagrams derived on the Use Case scenarios.

That sounds reasonable, but this still begs the question regarding UML. If the purpose of UML is to visually model a object-oriented application (in this case) such that one can define a system's interactions before implementing the system, don't we have a chicken vs. egg situation? Let me define the term implementation. I am not referring to code implementation of the class model. In the context of UML, I use the term implementation (perhaps not the right term) to describe the process of designing a PIM based around all the interactions within the proposed system as noted by the various structural and behavioral diagrams and the various system views.

In other words - again, maybe I'm wrong - in terms of designing an object-oriented application, I thought UML serves to architect the system in a way that helps to establish a solid class design model. Given this understanding, I would consider the PIM model (and, subsequently, any PSM models) would essentially be almost self-describing based on the rigorous work done in architecting the system (ie, application, in this case).

Back to the chicken vs. the egg. In your response it sounds like you are advocating class design well before the aforementioned rigorous architectural considerations. You may ask, how would one otherwise create a sequence diagram, for example, without the existence of a class model?

Here's my take. I'll try to lay out my explanation using one of the scenarios for my "Add a CD" Use Case, using a sequence diagram.

Use Case: Add a CD
Scenario: Manual Entry - Success

1. End User activates a command to Add a CD
2. Fills in CD details data entry form
3. Clicks the "Save" button

The corresponding Sequence Diagram...

The left-most element is the actor "End User". The next element to the right is signified by a "boundary" element called "Add a CD Data Entry Screen". The last, right-most element, is a "control" element called "Manage Completed Data Entry".

An "Add a CD" message is sent from "End User" to "Add a CD Data Entry Screen". A "Click Save" message is sent from "Add a CD Data Entry Screen" to "Manage Completed Data Entry". "Manage Completed Data Entry" returns a "Save Result" message to "Add a CD Data Entry Screen". "Add a CD Data Entry Screen" returns a "Save Result" message to "End User".

The sequence diagram clearly shows the steps for this scenario, yet it does not rely upon any predefined class model. Rather, the messages abstract the intended operations of a class model, and the elements abstract the class model classes and/or class instances. In fact, the messages themselves neither have parameters, nor do they return anything. In other words, this is an example of my understanding of UML. That is, first focus on architecting a solution (eg, this sequence diagram) without concern for implementation details (eg, sequence elements & messages abstracting classes and their operations).

My point is that a rigorous architecture will clearly suggest the class model, rather than requiring a class model as a prerequisite to the architectural design. Of course, once the class model is designed, then implementing the details for it and all the related diagrams then becomes an iterative process, but that is to be expected in the Unified Process methodology.

Again, this is new to me, so I truly appreciate constructive criticism and alternative viewpoints on this topic.

Thanks again.

[jeshaw2]

If the purpose of UML is to visually model a object-oriented application

That is not the only purpose of the UML.  The UML is also used much earlier in the SDM than modeling an O-O application.  It is, for example, initially used to model the problem/opportunity domain and for Solution Requirements modeling.  

First, I have not yet completed the Use Case model for the entire system. However, I assume your response makes the assumption I would have done so already, and it is your suggestion that I next design my classes before creating sequence, state chart and other diagrams derived on the Use Case scenarios.

I'll let Paolo speak for himself, but personally I would not make that assumption.

I'm not exactly sure of your SDM nor your position within it.  However...

Use Cases at the CIM level, model how the elements of the stakeholder's external environment interact with the stakeholder's domain; e.g., customers, suppliers, regulatory agencies interacting with a business.  I would ask if you have created the CIM model and developed class specifications for the domain level objects?  

Have you developed a Requirements Model that illuminates both the functional and non-functional requirements of the PIM?  Have you identified the business goals of the various actors?  These need to be articulated before the interactions, as you describe them, may be identified.

It would seem prudent to develop PIM level Use Cases that focus on the business goals of the stakeholders and not PSM level Use Cases that focus on CRUD activities such as your Add_A_CD.  The Use Cases are, themselves, classes that are next defined through Protocol State Charts using the attributes and behaviors of the domain level objects.

Application Use cases come into play at the start of the PIM modeling process, but are driven by the earlier CIM and requirements models.

I reserve the term Architecture for the design that forms the basis of the PSM.

Where are you?

Jim

[ASP]

> The UML is also used much earlier in the SDM...
I plead ignorance. SDM?

> I'll let Paolo speak for himself, but personally I would not
> make that assumption.
Fair enough.

> Use Cases at the CIM level, model how the elements of the
> stakeholder's external environment interact with the
> stakeholder's domain; e.g., customers, suppliers,
> regulatory agencies interacting with a business.
CIM? (content information management?) As stated elsewhere in this thread, I chose to exclude any business modeling in this project.

> Have you developed a Requirements Model that illuminates
> both the functional and non-functional requirements of the
> PIM?
I haven't yet developed a PSM, let alone any PIMs. Ultimately my target language is C++, but I will develop an PSM so I may more easily port to other languages. As for the requirements model, thus far, I've only developed the functional requirements for the system but have not worked on any non-functional requirements.

> Have you identified the business goals of the various
> actors?
(Business modeling deliberately not considered in this project)

> It would seem prudent to develop PIM level Use Cases that
> focus on the business goals of the stakeholders and not
> PSM level Use Cases that focus on CRUD activities such as
> your Add_A_CD.
Well, again there are no business goals for this app. More ignorance on my part... "CRUD"?

> I reserve the term Architecture for the design that forms
> the basis of the PSM.
Yes. That was one of my points, although I may be wrong on "how to get there", so to speak.

> Where are you?
Searching and seeking for considered answers like yours... lol.

Again, thanks to everyone for your feedback. Please keep it coming; I can use the help.

[jeshaw2]

Just a quick note as I'm on my way to bed.

CIM = Computationally Independent Model [from the MDA]

SDM = System Development Methodology

CRUD = Create, Read, Update, Delete (PSM abstraction level stuff)

(Business modeling deliberately not considered in this project)

Then I don't know what your doing and I don't think I can help you.  Watch out for scope creep.

[ASP]

Thanks for clarifying the acronyms.

> Then I don't know what your doing...
I thought I made it clear in my posts to this thread. Very simply, I'm designing a single-user music cataloging application using object-oriented programming techniques. I'm new to UML & EA; I'm not interested in including any business modeling for this project.

> ...and I don't think I can help you.
That's okay. I appreciate your contributions.

[Paolo F Cantoni]

Thanks for clarifying the acronyms.

> Then I don't know what your doing...
I thought I made it clear in my posts to this thread. Very simply, I'm designing a single-user music cataloging application using object-oriented programming techniques. I'm new to UML & EA; I'm not interested in including any business modeling for this project.

> ...and I don't think I can help you.
That's okay. I appreciate your contributions.

Hi ASP (I really prefer to converse with people rather than acronyms  ),

You're right and your wrong...

You are (absolutely) right to try and keep as much as possible as abstract as possible for as long as possible.

You are wrong in that Classes don't exist (if I understand you correctly) at other than the PIM and PSM levels.

As Jim says (and he's correct in suggesting that I, too, wouldn't have made the assumption) UML is MUCH more than a mechanism for constructing PIMs and PSMs.  The control elements you describe are classes - they're just not at the same level as code.  The actors you describe are classes...  You can use UML to provide any level of abstraction you require.  In fact I've proposed/defined two more layers of models surrounding the OMG ones:  The DIM - Domain Independent Model (one level of abstraction above the CIM) and the PSI - Platform Specific Implementation Model (a variant of the PDM) - which we use as the Design Model which we ship to our developers - then we reverse engineer the code they develop into the PSI and compare and contrast the two.

Does that clarify things for you?  If not, try the OMG MDA site - which might help.  Otherwise, like Jim there are insufficient points of commonality in our understandings of your problem that we really can't be of much further help.

TIP:  Domain (Computationally Independent) Models are NOT synonymous with Business Models.

Perhaps others can help.  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.

Paolo

[ASP]

Paolo,

> Hi ASP (I really prefer to converse with people rather than
> acronyms...)
My apologies. However, I prefer it this way, and I'd rather not get into details.

> You are wrong in that Classes don't exist (if I understand
> you correctly) at other than the PIM and PSM levels.
Yes, you understood me correctly.

> The control elements you describe are classes - they're
> just not at the same level as code.  The actors you
> describe are classes...  You can use UML to provide any
> level of abstraction you require.
Naturally. It is this level of abstraction that makes UML so attractive. Still, I fail to see the reason why it is necessary to define classes at this stage of the game. In fact as I continue to work on this project, I feel this is ever the case. For example, I've completed several sequence diagrams that reflect scenarios in a couple of different use cases. Thus far, in each diagram I have utilized the "boundary", "control" and "entity" elements. Each element represents a concept that will eventually be a class or series of classes. For example, one boundary element refers to the concept of modifying the details of a CD that exists in a database, using a windowed form. One might choose to define a class or some instance of a class for this element, but with closer analysis, this may not be the best idea. For instance, one could opt to define one or more GUI-related classes, error-handling classes, data-marshalling & serialization classes, and so on. I'd rather worry about that level of detail much later, as it clutters the design process at this early stage. Instead, why not simply use a "boundary" element and move on to the next item? Further, I deliberately chose the "boundary", "control" and "entity" elements, because they are typically used to connote an MVC design pattern, where the boundary is a "view", the control is a "control", and the entity is a "model". This is the level of abstraction that makes UML so pretty.

> Does that clarify things for you?
> ...there are insufficient points of commonality in our
> understandings of your problem that we really can't be of
> much further help...
> 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.
No. Admittedly, I am not entrenched in this technology; yet, I'm willing to learn.

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.

Perhaps the administrator(s) of this forum would consider partitioning it into levels of expertise. Those who wish to post and respond could then contribute accordingly. I will place this suggestion in the forum.