Tag Info

Hot answers tagged

9

Yes that's not a bogus test case, it's a valid test for expected exceptions


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


5

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


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

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


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


4

Use Cases form a proper class hierarchy. Must-be-logged-in Use case can be a super-class of the rest of your use cases. Some folks like to use <<extends>> to show that a use case extends the login use case. See this diagram: http://yuml.me/diagram/scruffy/usecase/draw


4

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


3

first impressions: I'd say your include arrows are the wrong way round, it's a little odd that Validate membership isn't included in extend return date? and I'd also be tempted to split these into two or three separate diagrams (so we don't have crossing lines). However, I'd also say that take 'correct uml' with a pinch of salt, if the diagram is useful to ...


3

A few more thoughts: who's usually responsible for use case analysis? It depends. On a small team, often everyone. I've also seen cases where the answer is problem domain experts who don't write code senior engineers - so the problem is defined by someone with experienced judgement junior engineers - as a vehicle for getting their feet wet and ...


3

The two users do not interact in this use case and should both be on the left (neither are an external system that is invoked). You could say that the two users have slightly different use cases - clients can only cancel their requests, travel agents can cancel any request. You can then say they both extend the same basic use case. See approximate diagram ...


3

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


3

If the login is part of the system you are creating it should be a use case in itself that is listed as a prerequisite for other use cases. if you are using an outside system (i.e. Windows authentication) you could simply list that the user has authenticated through windows authentication or whatever system you plan to use. Its generally good practice to ...


3

Hmm...extends is normally used to describe a use case that adds further functionality to a base use case. Moreover it is also used to describe something that might be optional and/or occur only in certain circumstances. Example: In this case, "Order Food" is the base use case and "Order Wine" extends it with further functionality. Moreover "Order Wine" ...


3

To be honest it sounds like you need to simplfy your use cases drastically. Worse still, it also sounds like you have a per-conceived idea of how the system should work and are trying to get the use cases to fit. Go back and start again using the following rules. All use cases titles should be a goal statement. I.E. "User gets can of cold COKE" is good ...


3

Were you hired as a software developer? It doesn't sound like it to me. You said your role is not completely defined. This means they can ask you to do almost anything that is realistically related to IT. This includes analysis work. And, if they want to leverage your analytical skills, it sounds like you might be doing more analysis work than actually ...


3

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.


3

I think it depends on the maturity/life-cycle phase of the particular feature as to how useful the diagrams are to the process. For new features and documenting outside in intent of features that are otherwise uncovered by automated acceptance tests, diagrams are useful. After adequate tests are in place, a bit less useful. Nevertheless, they have ...


3

For a use case the Actor can easily be a: User System (self-reference) System (external reference) ... (I'm sure there's others I'm not thinking of right now) The problem that you're running into is that you are assuming that an Actor can only be a User. In reality, the Actor is just the agent that triggers some sequence of events. System to System use ...


3

Heapsort is great when you need to know just the "smallest" (or "largest") of a collection of items, without the overhead of keeping the remaining items in sorted order. For example, a PriorityQueue.


3

Quicksort isn't stable. Quicksort has a lower constant factor than heap sort, but it's worst case complexity is O(N^2), so some variant switch back to heapsort in order to avoid that behavior (for instance introsort, but I'm pretty sure I've seen the idea applied in the early 90's).


3

As there is no inherent relation between a use-case and a GUI screen, it does not really make sense to divide use-case diagrams the GUI screen they relate to. To elaborate, a use-case describes how an external actor (either a machine or a human) interacts with a system to achieve a particular goal for that external actor. If the use-case does not involve an ...


3

Mozilla Persona, that seem to be really great. I didn't have the opportunity to test it yet, but I saw some demos and it sure looks cool. The coolest part is that it's decentralized. "At Mozilla, we believe that your online identity should belong exclusively to you. With that in mind, we created Persona to improve the way you sign in to websites. Persona ...


3

These use cases look fine to me. What you may not be realizing is that use cases can differ based on "roles..." that is, some people may have the authority to review customer accounts, but others may not. The roles and responsibilities of a product manager are going to be dramatically different than those of a clerk. Consequently, writing your use cases ...


3

Much of the benefit of use cases comes from the answer to "What if?" For example, you say the system validates the information. What will your validations be? Are some fields mandatory, or is this just about the phone number or email address meeting a particular format? Let's say it's that some fields are mandatory, What happens when the data doesn't ...


3

Spend enough time developing use cases to get a reasonably complete understanding of the problem domain. There is some benefit to having a big-picture view of the system as a whole. Therefore, I recommend that you complete your use case study first, before writing any code. You can, however, begin identifying the objects from the use cases right away, as ...


3

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


2

Suppose you have a form where users can make an account. Would you prefer to manually fill in 20 text boxes, tens of times with all kinds of input that may give wrong results? Or would you rather have an automatic test do that for you in a matter of seconds? A use case by all means is some action or procedure that your application should support, for ...


2

In my understanding the usecase (or userstory) should concentrate on what is requiered. (for example a customer in a web-shop can search for a product by brandname) in your examples you concentrate on how the requirement can be implemented. (i.e. steps needed to implement the usecase). to answer you question > Writing a Killer use case for a cron job ...


2

Behind every use case there's a story or 'use case scenario'. You need to think about that first before breaking things down into steps and actors and so on. Also, don't forget that time can be an actor. To start with, it shouldn't matter if the story begins and ends at points that are outside the scope of the project, it at least sets the context and it's ...



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