UC model - how to model a background process run?

[geoWRW]

Hello,

There are two use cases. One is a running process (a system function)
which performs some actions, then waits some time and performs the
same actions again. Let's say it runs all the time on and on. Let's
call it UC.1

There is also another Use Case which is an usual user performed
function - let's call it UC.2. UC.2 is a GUI function by means of
which a user simply starts UC.1 and then the UC.2 ends.

For example imagine that there is a backup monitor process which
backups files, waits and again backups if any changes occur (UC.1) and
a GUI which allows to run the backup monitor (UC.2).

The question is: what connector on a Use Case Diagram should be used
between UC.1 and UC.2?
UC.1 <--<<include>>-- UC.2?
No - because UC.2 does not wait for the result of UC.1.

UC.1 --<<extent>>--> UC.2?
No - because there is no any specific condition under which UC.2 runs.
It runs always.

There is a connector <<invokes>> In Enterprise Architect but I suppose
this is not UML compilant.

What do you think?

Thank you and regards,
Wojtek

[RJB]

(1) Use NO connection! Hope this doesn't shock too much.

(2) Use <<include>> and sort out the synchronization using
asynchronous messages in a sequence diagram.

Hope this helps.

[H. S. Lahman]

Responding to geoWRW...

> The question is: what connector on a Use Case Diagram should be used
> between UC.1 and UC.2?
> UC.1 <--<<include>>-- UC.2?
> No - because UC.2 does not wait for the result of UC.1.
>

I think you are reading too much into <<includes>>. Remember that use
cases are only in UML to provide traceability for requirements to the
model solution's elements. So all UML is doing is organizing the use
cases; it does not deal with the semantics of use case content at all.

The <<includes>> is just saying that UC.1 is relevant to UC.2 in every
situation where UC.2 is relevant and UC.1 contains steps that _for some
reason in the problem space_ are being separated from UC.2. IOW, the use
case step in UC.2 that starts UC.1 is always executed and there is a
valid freason for separating out UC.1's steps into its own use case. So
I would not have a problem with using <<includes>>. However, I agree
with RJB that probably the best solution is to not qualify the connector
at all because semantically UC.1's steps are not really part of UC.2.

> UC.1 --<<extent>>--> UC.2?
> No - because there is no any specific condition under which UC.2 runs.
> It runs always.
>

I agree.

> There is a connector <<invokes>> In Enterprise Architect but I suppose
> this is not UML compilant.
>

Not necessarily. UML is extensible so there is nothing to prevent an MDA
profile from providing additional qualifiers. The situation is analogous
to stereotypes. UML predefines some stereotypes, like <<subsystem>>, but
that does not mean one cannot add other stereotypes. Modeling tools all
have an MDA profile that governs their use and they often provide
specialized meanings of event new elements beyond OTS UML. So if you are
using EA for all your models, that might be the best solution for this
special situation. Just be sure that is what they actually mean by that
qualifier. B-)

--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html

[Gus Nkwocha]

Hi there,

I have two comments:

• I agree with RJB's suggestion about 'sorting out' the design detail in a different behavioural diagram. Much of the language in your post sounds very design oriented and the use case diagram is the wrong place for that.
• I suggest that you will need to add some text to the model and the appropriate place to document the implied  requirements in your post would be as contraints (not necessarily in OCL at this stage), in the constraints tab in the use case dialog in EA. This with an <<include>> association between the user invoked use case and the system use case would provide the level of detail that would permit the design and development to proceed. If I recall correctly EA displays named constraints on the face of use case diagrams.

 

--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.

[Thomas Mercer-Hursh, Ph.D.]

On 8/19/2010 1:31 AM, Gus Nkwocha wrote:
> Hi there, I have two comments:
>

> * I agree with RJB's suggestion about 'sorting out' the design detail

> in a different behavioural diagram. Much of the language in your post
> sounds very design oriented and the use case diagram is the wrong
> place for that.

In fact, one could say that the whole idea of "this is a background
process" and "this is a UI to start a background process" is not at all
what use cases where intended for. The UC should be talking about what
those functions will accomplish and, at most, might mention that the
function will be continuously running. I would wonder if one would even
bother mentioning that it has to get started in some way unless there
were something exceptional about the startup requirement.

Thomas Mercer-Hursh

[Ken Lloyd]

RJ,

Good advice. However, do you think that most folks are getting too detailed
and specific in their Use Cases? Shouldn't most of the Use Case analysis be
done in the decomposition to Activity Diagrams, with interruptible
activities for async, and forks and joins for synchronization? I found
sequence diagrams more straightforward for DFAs where the sequence
propagations are known.

Ken

Hope this helps.

--

[geoWRW]

Hello,

Great thanks for all of you for the advises. I must agree that doing
the Use Cases maybe I think too much "how" instead of "what" to do. :)

I have chosen <<include>> with a Note "UC2 does not wait for UC1
final". I hope this will be understandable.

I draw UC Diagrams as a map of functionality in an application and its
description - not only a model for requirements traceability (but
also). So most of my use cases are detailed by Activity Diagram
showing scenarios, constraints an rules, input and output parameters
for system functions. And I usually connect UC to an Actor or other UC
because I would like to know (or others to know) when and how this use
case can occur. Maybe this is not pure UML attitude..?

Once again thank you for you posts.

All the best,
Wojtek

[RJB]

Ken, I believe the KISS principle. As a rule I think you should use
text to describe and analyze use cases. Activity diagrams are for
complex scenarios only.

For describing the design I like sequence diagrams, as long as they
are interesting.

By the way, The old "UML in a Nutshell" - the cat book - has examples
of a systems administrator starting a bs k ground process but assume
that a special processor is involved.