Prev: sequence diagram for observer pattern
Next: polymorphism
From: Nananana on 4 Jun 2006 03:08
Hi.
What I have: All the Use cases of a future system.
What I need: A context diagram of the system.
Questions: would each actor be an external entity in the context
diagram?
TIA

From: Davor on 8 Jun 2006 19:59

Nananana wrote:
> Hi.
> What I have: All the Use cases of a future system.
> What I need: A context diagram of the system.
> Questions: would each actor be an external entity in the context
> diagram?

Yes. You should also have a number of other entities that are
communicating with actors and not necessarily with the system. If you
do not have these other entities, you can just rely upon the use case
*diagram* instead of having to draw a context diagram to show the
information you want to show. I'm not sure though why you need context
diagram at this point if you already have *all* the use cases. Context
diagram is typically made before trying to capture and specify use
cases in order to find all possible actors, what is really needed,
system boundary, etc. But, by any means, build it at this point too as
it will help you find missing actors and use cases, and refine system
boundary, which is very important for a non-trivial system...

Davor

From: Nananana on 9 Jun 2006 10:51
Thanks.
Let me re-phrase.. "suppose I have all the use cases.."
You made me re-think about the people who don't use the system, but
send or receive data.
1. What about a customer who sends documents by mail or fax?
2. What about a customer who receives a letter?
Are they external entities?

Davor wrote:
> Nananana wrote:
> > Hi.
> > What I have: All the Use cases of a future system.
> > What I need: A context diagram of the system.
> > Questions: would each actor be an external entity in the context
> > diagram?
>
> Yes. You should also have a number of other entities that are
> communicating with actors and not necessarily with the system. If you
> do not have these other entities, you can just rely upon the use case
> *diagram* instead of having to draw a context diagram to show the
> information you want to show. I'm not sure though why you need context
> diagram at this point if you already have *all* the use cases. Context
> diagram is typically made before trying to capture and specify use
> cases in order to find all possible actors, what is really needed,
> system boundary, etc. But, by any means, build it at this point too as
> it will help you find missing actors and use cases, and refine system
> boundary, which is very important for a non-trivial system...
>
> Davor

From: Davor on 9 Jun 2006 12:27
Nananana wrote:
> Thanks.
> Let me re-phrase.. "suppose I have all the use cases.."

Yes, it appears that you are in the requirements elicitation phase, and
as such I would expect system boundary to get refined, new use cases
and actors discovered, and maybe some even removed... and don't
hesitate to change... I sometimes build even several different models,
with different system boundaries for example or making some
hypothetical changes to business processes too, and try to estimate
costs and benefits and get as much insight as I can - this also
prevents me from making early design decisions and allows me to purely
focus on analysis...

> You made me re-think about the people who don't use the system, but
> send or receive data.
> 1. What about a customer who sends documents by mail or fax?
> 2. What about a customer who receives a letter?
> Are they external entities?

Certainly! Include as many external entities as you can and try to
explore your system's external world in as much detail as the system
itself... and nothing says that you cannot cut out something that you
*really* don't need later, when you are sure that it has no impact
whatsoever on the system...

Another, more systematic way that you might want to choose to work
with, especially if you are dealing with a very large system is to
ignore context diagrams completely, and to work only with use cases and
use case diagrams but for several system boundaries. You would start
with the system boundary for the largest "business" system that your
software system will be part of and specify use cases and actors. Then
you consider what is the next smaller subsystem of that system and
specify actors and use cases... and so on until you end up at the
boundary of your software system that you are planning to build. This
way the same indirect external entities that are appearing in your
original context diagram, will appear as the actors that participate in
use cases of the system that your software system is part of... This
will also help you understand how use cases decompose and fit together
to fulfill overall business processes, and how all actors relate to
each other independent of the system boundary definitions. Of course,
you might still want to build a context diagram even in this case, or
to make even some kind of "intersection" diagram between use case
diagrams and context diagrams which help you visualize all the
information - do not hesitate to find the optimal solution which will
increase the chance that you did not miss any requirements and that you
have optimally defined your systems boundary and any changes on the
business processes that should be made.

Davor

 | 
Pages: 1
Prev: sequence diagram for observer pattern
Next: polymorphism