New answers tagged

1

I would like to add a different point of view. Lets say we have a product (desktop app, webapp, doesn't matter) that use logs to trace its activity. It does also with errors bc "it's a good product" and errors have been designed with codes (lets say like Oracle does). Such logs/traces were thought to be read by user instead of developers. Product also ...


4

When developers talk about "logs", they're most often referring to plain text files containing information that is meaningless outside the context of the specific code that logged them and has no intended purpose other than troubleshooting that code when something goes wrong. When developers talk about "internationalization", they most often mean "when the ...


1

In most of my projects we used a distinction between Diagram and Model in the way that a diagram always shows a view of the Use Case Model. In other words: a diagram is purposed towards the readability and per se not complete in the sense that all model elements are visible. Therefore: yes, as CandiedOrange suggested, you can show the actor (or actors) ...


2

I think you're missing the point of use case diagrams. They aren't to say, here's an actor, here's a use case. Your diagrams should be taking me through the story of a use case. That story should be more than just one oval. Whether you should be bundling multiple use cases together in one diagram has more to do with how complex the use cases are and if ...


4

You can put them anywhere - the top, the bottom, the left, the right. In most cases, if it fits neatly, I've seen them on the right. They go on the left if necessary. UML doesn't specify this level of detail, though. You should make a diagram that is readable to the intended audience.



Top 50 recent answers are included