Is this reasonable?

[sargasso]

I am modelling a web app for testing purposes.   The model is  very user view oriented.  There are about 22 use cases of interest in the "consumer" package, including the obvious frequent visitor membership set and thus "Log In".

The immediate problem is to come to grips with all the possible flows out of a page from the links thereon.  So we are modelling the flows as activity diagrams under each use case.  

Now I just want to get a bit of a sanity check on something.  A good example is the Log In flow, the first (and last) action in the flow is "Enter Log In Credentials".  There is a link from this action representing the click of the "Log In" button on the web page with the constraint [authentication=OK].

i.e.  (   Enter log in credentials   )  ------- Log In <<button>>  [authentication=OK] ------------->

Now here's the question.  I reckon that the next activity is the automatic invocation of the "Review IBE bookings" use case.   So in a nutshell, does it make sense to have a use case as a target on a control flow link, thus rendering the use case as an "activity".

It looks to me to be a good way to do it - and I'll have many more instance of the same thing.  Anyone see anything wrong with this approach?

tia
Bruce

[Hans]

Hi Bruce,

I dare to say, this doesn't make sense; a use case is a part of the requirement documentation which does not have functional stimulus.

Activity should come after object design.

Regards,
Detlef

[mchiuminatto]

Hi Bruce.

If I understood you have two use cases:

UC1. Login
UC2. Review IBE Bookings

How are they related?

UC1 ---- <<includes>> --> UC2?

After a first reading it seems you are invoking UC2 behavior from UC1. I see a problem there. Please confirm if that is the case.

Thanks

[thomaskilian]

Bruce,
it's probably not the use case but the according activities of the (standard) scenario you see next. If you think these are related you should think your use cases over again.

(P.S.Marcello got me by 3 minutes while editing this post  )

[sargasso]

Thanks guys!

Thomas gave me the right clue "the according activities of the (standard) scenario"!

Because I picked a simple one to start with I missed the fact that some of the use cases will have multiple scenarios and invocation points.  The sample "occurs" only once and I did not consider the alternative ways of invoking it.  When I consider the more complex instances - use cases that can be invoked in different ways from different places which involve diferent flow scenarios it would all fall apart.

Marcello, the relationship in the example is that a successful completion of UC1 automatically invokes UC2 without user interaction.  UC2 is a separate use case because it can be invoked from different points in the web app in different ways, for example one option available at the end of the "Create a booking" use case is to manually invoke UC2, other options at that point represent other use cases, such as "View Privacy Policy" etc.

Hans, "this use case begins when a) the user has successfully logged in or b) the user selects the "View my bookings" link from the booking confirmation page" sound like functional stimuli to me.

Anyway as I said, thanks guys, i am glad I posed the question before starting to implement the idea as it would have resulted in a big mess.

Bruce

[mchiuminatto]

Hans

By definition, a use case represents the system functionality  from actors point of view, it's al about functionality.

Use cases are dsecribed, in general terms, by the value the system returns to the actor as a reaction to the actor stimulus, and in detail in terms of a "dialog"  between the system and the actor. Scenarios can be described as plain text, activity diagrams or as a simple sequence diagram.

[Hans]

Marcello,

as I see it, a use case is not "all about functionality": instead, it's about goals.

It does not describe the real underlying functionality, it
summarizes the major aspects to be taken in order to fulfill the tasks.
It is not a part of design and implementation, but a preliminary:
design and implementation will need to follow and cover of the use cases.

And, looking at the EA project structure, I see that it supports just my viewpoint.

It is quite common that one or another high-level sequence diagram is included into use cases, although it's not my personal taste:
Writing steps down in a textual form is much quicker, shorter and clearer to understand.

Imho, activity diagrams in will overburden use cases. Prior to actities, I'll need to get my class design and the process flows straight, and it's there where activity diagrams begin to help.

However, the most value of activity diagrams is for documentation and above that for testing, diagnosing, and maintenance purposes.

Regards,
Detlef

[mchiuminatto]

Hans

as I see it, a use case is not "all about functionality": instead, it's about goals.  

Goals are the value the system returns as product of its behavior (functionality). In fact, of the interaction between the actors (who triggers the behavior) and the system (who offers the behavior)

<programming> Waffle for "features" or "function". The
capabilities or behaviours of a program, part of a program, or
system, seen as the sum of its features. Roughly, "the
things it can do". Generally used in a comparative sense,
e.g. "The latest update adds some useful functionality".
www.dictionary.com

It is not a part of design and implementation

I have never said that, but I should.

What you define in Desig is Use Case Realizations, that is to define how to realize the behavior (functionality) described by Use Cases at a lower abstraction level (related to technology)

Now, form the Design artifacts, derived from a use case realization ( resulting from a Use Case) you build the software that implements  all the behavior (again functionality) as was original described in use cases.

Use Cases are the conductor thread of al the development process life cycle, as I see it they are part of Requirement, Analysis, Design and Test.

And, looking at the EA project structure

That is an structural point of view, and what about the behavior (I mean the methodology?).  The methodology (at least RUP), will show you that Use Case are part of the whole development process life cycle.

It is quite common that one or another high-level sequence diagram is included into use cases, although it's not my personal taste:
Writing steps down in a textual form is much quicker, shorter and clearer to understand.

I agree with you on that

Imho, activity diagrams in will overburden use cases

If you document all use cases with Activity Diagrams, maybe will overburden the model, but you don’t have to do that, you can apply some criteria and choos the best way to document a particular use case (text, sequence, activity)

I found some other people tha believes the same:

This paper describes how to model system functionality using UML Use Cases. In the
UML, Use Cases are the primary means of capturing system functionality from the user
perspective, and often may replace a 'functional requirements' document.G. Spaks

A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all flows of events related to producing the "observable result of value", including alternate and exception flows. More formally, a use case defines a set of use-case instances or scenarios.  RUP

[Hans]

Hi Marcello,

I see that if we agreed to take the words requirement/goal and functionality as being synonyms we
pretty much mean the same thing.

The only difference is in the question whether use cases are a real constituent of design
and implementation or not.

In my eyes, they are not: It's only that in the majority of all projects I was involved in,
the requirements set up by stakeholders and agreed upon by the management were contradicting
and couldn't be met by the developers.
It is at this point where the use cases must be changed during the project's actual realization phase.

Is it reasonable that the developer himself creates his own use cases? I dare to say no.

Personally, I feel that UML is discussed far too much in terms of esoteric nebulae of what could be done
than in terms of pragmatic best practices to get the tasks actually done.
The quotes you cited don't catch me. They are too blurry, and you could likewise have said:
go to OMG.org. I'd then reply to you: read Craig Larman.

You see in our discussion the grand failure of OMG: Instead of nailing things down to the point
to their very unmistakeability, they opened the doors to eclecticism, thus giving rise to
arbitrary manifolds of interpretations of their proposed diagrams.

Regards,
Detlef

[mchiuminatto]

Detlef (or Hans).

1. Concrete Fact.

I will remind you why I did reply to you: It was for the following  phrase you wrotte:

a use case is a part of the requirement documentation (I agree)
which does not have functional stimulus. (I totally desagree)

As I Understood you was saying tha Use Cases has nothing to do with functionality.  I think exactly the contrary. And taking your advice, goto

http://www.omg.org/docs/ptc/03-08-02.pdf, page 519 of the Superstructure specification.


2. Personal Opinion (not necessarily coincident with some one else opinion)

You see in our discussion the grand failure of OMG: Instead of nailing things down to the point
to their very unmistakeability, they opened the doors to eclecticism, thus giving rise to
arbitrary manifolds of interpretations of their proposed diagrams. [/

]

Under my point of view, the OMG's UML specification, is still a generalization that needs to specialized to concrete domains and organizations  (human organizations)  and that is not the OMG mission, I think this is our mission (Users of UML).

[thomaskilian]

Hans,
as you write

The only difference is in the question whether use cases are a real constituent of design  and implementation or not.

the answer seems to be clear: as Use Cases describe the WHAT they are aparently constituent of design and implementation. Design tells you how the implementation shall be done. And the implementation itself must reflect the WHAT of the Use Cases.

One word to goals/requirements: Goals must be defined in the very beginning of each project (albeit most project don't). From these goals you then derive requirements. And these at last form the Use Cases. Most failing projects ignore these rules and begin with Use Case design (we ever worked this way, so let's nail it down) and glueing some requirements to it.

[TrtnJohn]

I completely agree Thomas.  Most companies have a hard time bridging the gap from revenue/profit goals to actual product requirements.  It is often left up to the development group to set their own goals.  Being a developer myself, I hate to admit it, but that rarely works.  Nothing beats good market research in defining requirements.  Too often, developer driven products completely miss the mark.  I like to break down my requirements stages as follows  (A little different than you said it):


Why?
  - Describes the high level goals and ties the project to corporate milestones/mission.  Clearly defines the market needs that are driving the new project.

What?
   - High level plan of attack.  Proposed solutions to satisfy market needs.  (Implementation goals).

How?
    - Detailed product requirements.  Describes the new features/products required.  (Use cases come in here).

So, in my case.  Use Cases are the realization of the Goals and plans defined to satisfy the market needs.

[Hans]

Hi Marcello,

First off, let me assure you that I perfectly accept your position, and I do appreciate that your standpoint is much more moderate and relaxed than mine.

You write:
>Under my point of view, the OMG's UML specification,
>is still a generalization that needs to specialized to
>concrete domains and organizations  (human organizations)  and
>that is not the OMG mission, I think this is our mission (Users of UML).

As fine as this is, with this you relativate the the goal of OMG, namely to promote ultimate standard tools for software architecture with the rigor of a buildings architecture plan.
As different kinds of diagrams (which we all accept upon as a standard) can deliberately combined into new ones, then we would give up common concise understanding of our design right before UML was even completed.
In the end, we'd really be foolish not to conform with Microsoft and to draw graphs deliberately with Visio, write use cases, scope, vision documents with Excel, and present with PowerPoint and Word as we for the majority did all the years before.

Regards,
Hans (Detlef)

(PS: My wife calls me Hans, my brothers Detlef, and through the powerful decision of German administration, I was by birth erroneously given an extra hyphen in between - that's life!)

[Hans]

Hi Thomas,

I guess, I can/may likewise speak for Marcello, that we both wholeheartedly agree upon your fine, well-posed words.

Regards,
Detlef

[thomaskilian]

And thanks to Bruce who started this thread