20

In general, RPC offers far more of a language integration than REST. As you mentioned, this comes with a number of problems in terms of scale, error handling, type safety, etc., especially when a single distributed system involves multiple hosts running code written in multiple languages. However, after having written business systems that use RPC, REST, and ...


20

Do I really have to make 24 use cases? Only if everything you write is CRUD. Refer to the diagram below: Your assertion is that you will have six different entities, and 4 methods (Create, Read, Update and Delete) for each entity. But that is only true in the yellow circle in the middle of the diagram (the Entities layer). It is pointless to create 24 ...


18

People use the terms "business rule" and "business logic" to refer to the portion of your application that is specific to your application and represents the core behavior of how things are supposed to work as opposed to generic functionality that could be useful in software written for a different client/business/customer base or code that exists to support ...


17

Requirements will grow and change. I don't think anyone could argue that. How to collect and process incoming requests. In my experience it helps when gathering requirements if there is a single or very small group of customers acting as a filter for delivering new or updated requirements to a small group of development planners. Anyone from their side ...


13

A use case is not a method. A use case is not an object. A use case is not a layer. A use case is a story about a user, using the software, in a particular case. So it should come as no surprise that different use cases can reuse the same code. But maybe you watched one of the video'spaywalled where Bob makes out like a use case is part of your ...


11

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 ...


7

who's usually responsible for use case analysis? Everyone. How usual is it to put a newbie on it? Not too unusual. You may have appropriate problem domain knowledge that makes you more valuable working with the users. The hidden fear I have is: are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...)? ...


7

This answer has been updated for UML 2.5.1 specification. First, it appears that the notation is valid. Actors (18.2.1) can only have Associations to UseCases, Components, and Classes and these Associations must be binary. The relationship between Admin and User is Generalization (defined in 9.9.7). It is a specialization of the DirectedRelationship (...


7

Your system might be performing its activities autonomously, but it will still be true that those activities are performed to achieve an objective that benefits someone. If your system doesn't provide any benefits, then nobody would use/buy it (except perhaps as a curiosity). If you can articulate those benefits and who benefits of them, then it is possible ...


7

A use case involves an actor and the flow that a particular actor takes in a given functionality or path. These often get grouped so you have a "set" of use cases to account for each scenario. A Scenario involves a situation that may have single or multiple actors that take a given functionality or path to resolve the scenario. You can see the main ...


7

A use case is an interaction between an actor (which may or may not be a human) and a system. The concept of "logging in" is authentication. Something or someone confirms their identity. When you log in, an actor presents credentials to the system and the system accepts or rejects these credentials. Logging in, or authentication, is a use case. It involves ...


6

In my opinion and in an Agile perspective: Use cases, Class diagrams, Sequences Diagrams and other UML stuff are excellent conversation tools. They are really neat when you need to sketch or explain ideas on a white board for example to make sure we get a common understanding of what need to be achieved at the moment of the conversation. After the ...


6

At a very high level, sequence diagrams can represent high-level interactions between systems or sub-systems at a high level. If they represent interactions between actual classes (or interfaces) they're nice because each message in the diagram corresponds directly to a method that class must have. You can almost write your code from the sequence diagrams by ...


6

The answers given here are too bound to the developer point of view. However, software is made to be used (and read) by humans (users) whose most of them have no idea about debugging, log patterns, standards, etc... Let's say we have a product that logs its activity at different levels. It's required the product to have a dashboard or control panel where ...


6

You don't need a one-to-one mapping of interactors and entities. I believe such a design would be harmful. DDD is all about context boundaries and the ubiquitous language within those boundaries. When you really focus on creating objects to represent the language of the business, you'll find everything begins to shape itself a bit differently. It seems ...


6

Actors should generally be people, or rather the business role the person is in. Applications can be actors, but normally this is when they are doing something like a scheduled task. Ie. behaving like a person doing a job. In your case the spreadsheet only really comes into the use case if its part of the requirements that a spreadsheet be used. for ...


5

To me, it looks like you're drawing a Class Diagram, but with fancy stick figures instead of boxes. IMO Use Case Diagrams should show how a person or other entity acts or reacts under certain conditions. I fail to see how extending a client is something an administrator does as part of his job, or something an administrator object could be capable of.


5

The database is an actor when it takes independent action -- triggers and jobs mainly. It is not a actor when it it is simply responding to CRUD commands.


5

I think you'll run into trouble as you design an application by thinking there is a strong relationship between the tasks requirements of an application and the number of screens (forms, web pages, etc). Even simple CRUD apps have that one requirement with too much complexity to handle this way. Take the example of a simple data entry grid with the ability ...


5

I would say go as high level as you can while still including all the necessary method calls, etc for your topic. My reasoning for this is that if you're including every single interaction then you might as well just write the code yourself. Personally, I have always viewed sequence diagrams more or less as "guidance" for the implementer. I've never viewed ...


5

Doing use-cases for an existing manual system is difficult because use-cases require a "system". Where are the boundaries of the "system" in the manual system? If you want your work to be relevant to your planned automated system then you should choose the part being automated as the "system". In which case, both the manual and automated systems should have ...


5

The system can display certain elements on a screen, means that an actor can "Check those elements on the screen". Try not to describe your system from the point of view of the "system", but from the "Users" point of view: what can they do with the system? I believe an example would help: Let's say I want to talk about an ATM as a system. The use cases the ...


5

I don't think that "be notified" should be something that is even on a use case diagram. Each use case is a sequence of steps or actions. What appears on a use case diagram is just a summary of what the full use case is, since it doesn't capture all of the steps, preconditions and postconditions, minimal guarantees, triggers, or any of the other information ...


5

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.


5

The system under consideration in your model seems to be your microcontroler with your driver. The actors interact with this system under consideration. They are of two kinds : primary actors: they use the system to achieve their goal. They are often represented on the left side of the diagram. Here, it's the software components that use the driver. ...


5

Use cases and user stories are both tools for gathering and expressing requirements. As you already found, a single use case has typically a broader scope than a single user story because it tries to completely describe a user interaction including errors and deviations from the normal path. A user story can be roughly compared to a single flow through a use ...


5

I would argue that UC_07 perhaps isn't needed at all if it forms part of the system overall. Also a lot of your use cases read like a sequence of steps which more properly belong in a sequence diagram. But it really depends how many UML diagrams you're using. You could also make a case for removing start and close applications as this is a given if you're ...


5

The use case diagram gives us an overview of requirements, and illustrates how various actors interact via the system. There are many ways to actually capture use cases. An important one is single-sentence user stories. For example: “As a User, I want to search ORFs”. This is a valid use case. Now you are proposing a use case like “As a User, I want to save ...


5

Use cases and user stories are one method of capturing requirements. There are other ways of capturing requirements - from "shall"-style statements to various tabular or graphical models. Getting into all the options for how to elicit, capture, analyze, and manage requirements is beyond the scope of a single answer here, so I'd check out some other questions ...


Only top voted, non community-wiki answers of a minimum length are eligible