aboutale. What is the arrow with a triangle
on its head between "insert card" and "type code"? why not an "include"
or "extend" relation? More or less the modelling is correct but I'm
not too crazy about most of the important actions being so removed
from the actors. There are some missing relationship that trigger the
maintenance actor: when the machine doesn't work, the customer notices
and notifies the bank (or the bank notices), which calls maintenance.
All multiplicities are missing.
ATM: can't read this file either with umbrello
or with eclipse.
batisse: more or less OK but it seems that
the subsystem "technician"-"criminal" is totally disconnected from the
main subsystem "customer"-"bank". I don't think this is correct.
ladjal: nice attempt to model the
effect of the sun, but the "sun" actor does not "confirm". Rather, it
"prevents from working the ATM correctly" or something of the kind. In
short, it increases the probability of the customer making a
mistake. You should add a relation to a "bank" action "deactivate card".
leruth: Overall, I like this model but what
are the undirected edges between action nodes (such as
"databank"-"transfer data")? I think this denotes an unclear idea of
who/what is an actor and an action.
ramadan: Graphically, this model is very
clear, and I think each subsystem has been modelled correctly. I think
however that "include" and "extend" labels are more or less random
(the concept that A "extends" B corresponds to a class A that inherits
from a class B, whereas the concept that A "includes" B corresponds
to a class including an data field of type B). Furhermore, the
subsystems are detached. Some actions should be related by logical
relation (for example: why not add an "exhaust cash" action by the
customer that is in "AND" relationship with the "cash feed" bank action?
roblero: even the most vivid imagination
cannot transform this into a valid use case diagram. There are
inter-action relations that are not include or extends or even
logical, and the arrow "banque"-"des operations bancaires" is in
in the wrong direction.
tonio: man, I said "simple"!
voillequin: more or less the same remark as
for roblero above.
zarrouati: more or less. But many "syntax
errors" like a directed arrow between an action and an actor ("send
request" to "banque"), and some wrong multiplicities (a "client" may
usually type the code 3 times if he/she gets it wrong, not just
once!). Again, some subsystems are totally disconnected.