UCD - 'External Use Case'
gorniakw
I create the functionality that extends the standard features of the
SAP system.
and I would like to draw use case diagram for it.
Example:
User -----> (UC1: Input Data) <- - - extend - - - ( UC2: Do additional
things )
UC1 - is the standard SAP functionality which i'm extending
UC2 - is the functionality, which i'm implementing in SAP. This use
case is used only when several conditions are met (validation is in
UC1)
How can draw UCD and show either UC1 is not implemented in my
'subsytem' or UC1 is an 'external UC'.
when i draw it (as above) this information is not visible / readable
on diagram.
Can You help me please?
P.S. sorry for my poor english,
H. S. Lahman
> Hi all,
> I create the functionality that extends the standard features of the
> SAP system.
> and I would like to draw use case diagram for it.
The UCD doesn't care where the use cases are implemented, so you just
draw that normally.
What you are interested in here is the deployment of the implementations
in SAP vs. your extensions. I think you have three choices:
(1) use the Deployment Diagram
(2) use the Package Diagram
(3) apply a <<SAP>> stereotype to the SAP uses case in the UCD.
I am not keen on (1) and I am not sure how you would do it. The reason I
am not keen is that uses cases represent requirements specification
while everything else in UML is about solution specification. [Before
the cards, letters, and death threats come rolling in, I know some
people use UML for OOR. I think that is a Really Bad Idea because there
is no way to distinguish between requirements and solution design. Every
example I have ever seen of OOR in UML has grossly over-specified the
design.]
I think (2) is the natural way to do it. That's what the Package Diagram
is for -- identifying model elements that are somehow related other than
through model semantics. In your case you would have a bunch of SAP
packages and a bunch of packages for your extensions. The problem with
this would come up if you really didn't care about organization all the
rest of the functionality into packages (e.g., you don't want to deal
with things like version control or requirements traceability in UML).
Then it becomes a lot of unnecessary work (i.e., organizing all the
other model elements into packages) or it is somewhat silly (i.e., two
packages, one with all the SAP use cases and one with all the extension
use cases where you don't worry about the mapping to other model elements).
So in your particular case, I would be inclined to do (3) because it is
simple and the demarcation semantics is already very clear. OTOH, if you
are going to use a Package Diagram for other reasons to organize the
model elements, I would just put the extension use cases in the packages
with your model elements and put the SAP use cases in a dedicated
Package or, if you also use UML to model the SAP functionality, in those
packages (unlikely since SAP is realized).
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Eran Peleg
I'm using the CBD (Component Based Development) paradigm, so there are no
internal and external UCs but external and internal components. Each
component has UCs. The external components (are light-blue) and the
internal components (are red or green) can communicate. So, UC of the
external component (let call it ExUC) can use (Include or Extend or
Generalized) UC of the internal component (let call it IntUC).
On the UCD you may have an Actor associated with ExUC which have Extend
relationship from IntUC.
The conditions of starting IntUC are its Preconditinos. The UC itself
doesn't care how they are created.
Hope it helps
Eran
======================
Eran Peleg, CEO
Metaphor Vision Ltd.
Phone: +972545346060
Fax: 151545346060
eMail: epe...@metaphor.co.il
Skype: EranPelegMetaphor
======================
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
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?hl=en
Martin
Typically, they are used to capture the requirements of a system, that
is, what a system is supposed to do." [from
omg_uml_superstructure_07-11-02.pdf]
Important is to know which system are you modelling. From this point
of view, every use case of the system has to be internal, and
functionality from the other system has to be modeled as an external
actor of use case which uses the functionality.
so, in your case, i would say, both use cases belongs to SAP, so are
internal.
you have 2 possibilities to show that UC2 is being changed:
1) using a stereotype
2) using colors (different for changed and new UCs) and adding a
legend
point 2 has 1 big advantage, the color of UC is changed only in that
1 UC model, so you still can have a global UC model (all UCs with one
color), than a UC model of changed UCS... stereotype is an attribute
of UC a applies to every UC model, at next change you would have to
remove the stereotype and set it in other UCs.
we, in our company, create a solution design document and in 1 chapter
we describe changed and new UCs. for this, we use colors.
Martin
Remy Fannader
http://caminao.wordpress.com/how-to-implement-symbolic-representations/use-cases/
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/
Remy Fannader