I'm finally integrating xstate into my work project because I love it and I'm excited to show off what well-structured states can do for performance and reasoning, but I'm struggling with a bit of modeling. I have a weatherMachine that gets the current temperature based on lat/long and is connected to a map in my app, so when the user moves it, the weather loads. I have that all working beautifully but if the user zooms out too much, I don't want to show weather, as it's not all that useful when you're viewing a large area. My modeling question is whether or not hiding the weather belongs in the weather machine. Part of me thinks it should just get weather when asked to but the point at which I dispatch the event to load weather (onMapRegionChange) is also the place I'd check the zoom level and show/hide the weather. It'd be simplest to add some context to the weather machine for hideWeather but is that "correct?" Any feedback on the approach you all would use would be greatly appreciated.
I'm preparing the sequence diagram for a project. I made the following sequence diagram for a retailer updating his inventory
It's confusing to me because this is the first time I use this technique with a real project.i have used database as an object here and i don't know whether its right or wrong. And another thing i need to clarify is by using Updating i meant for both editing/add new item To the inventory. Is it wrong to do like that way? or else can we draw it separately?
The following image is part of the updating process, would any one take a look and correct me if I did any mistake.(UpdateUI- User interface).Thanks in Advance.
It does not look right. There are a couple of issues:
Your database will likely never issue any messages
Actions inside a DB are usually not exposed. You normally only call CRUD from outside for a DB.
You mix synch/asynch (likely unwillingly). Filled arrows are synch, unfilled ones as asynch.
Main Page is likely the V in MVC and UpdateUI the C. So the controller will act on a click from the user and interact with the DB.
So just from my guts here is a more reasonable sketch:
I need to clarify my concept.
I am making activity diagrams for different activities. for an activity titled as:
'View Profile'.... i need to make its dgm...
In 'view profile' a user can:
1- view his/her monthly bills
2- View demographics details
3- Edit his/her details
and foreach 1,2,3 there would be different steps to be followed
My question is:
how should i make an activity dgm for such a situation... here is what I am tryong to communicate.. help me how to correct it or what sort of symbol should be used in between to serve the correct purpose as its upto user whether he wants to explore all 1,2,3 or only 1 or only 2 etc
In fact I would create an activity diagram describing view profiling which would contains three CallActivities calling respectively three activities named "View details", "Edit details", and "View bills".
Now for linking these three CallActivities inside the ViewProfile Activity I would use decision/merge nodes (depending if the threes sub activities can not be performed in parallel).
Decision node corresponding to a if/else statement but if I well understood your issue you need that plus the fact that after having performed one of these subactivities you should be able to performe one of them and this is modeled by a flow coming back to these subactivities
Hoping it is clear and it helps
Please take a look at my attachment.
If only 1 option can occur at a time: a decision point (diamond shape) would be the most appropriate (annotated "user chooses option" or similar). The decision point would have 3 paths leading to the 3 possible options.
For clarity the paths should have arrows indicating direction.
To show that the user can perform another option after completing an initially chosen one, you could have another decision point that each of the 3 steps link to. That decision point could be named "User chooses to continue further steps?" or similar, with the "Yes" path leading back to the first decision point, and the "No" path leading to a final node.
Hi im not used to UML but i have to create a Use case diagram for a system.
Id Appreciate(HELP!) if some one could make an example of a use case Any of the information i provide. the system rums on windows mobile phone 7
Mobile Location based GPS
User creates account,
User Creates Profile(identy) on the account
User Chooses Region
User Chooses to partcipate, then gets Assigned A location from servers online
User gaol of Reaching loaction met, User is Assigned Points(leader board updated), If the user Fails No points Valuse of location increases.
USer Can Equip tools, User Gets new Tools if Points Goals are reached.
User Can lookup point leaderboard, See users Rank
Please wip out paint for 2-3 mins and how me how to do one of these use cases !
And does each sentance need a use case ? or is it possilbe to give a use case to each of these lines ?
THANKs!
I can't help but ask: What benefit does creating a UML use case diagram, with stick men and bubbles, give you that the simple sentences you posted do not? I simply don't understand what the fascination with UML is all about.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
How do you go about organizing user stories?
What I did was this for a web application:
Made a title for a web page like 'index', then listed all the stores the user can do on this page.
I continued on for all the pages.
Is this the most effective way?
I personally like the BDD style user stories and tasks. Generally, under BDD/Agile you will create user stories in a planning meeting along the following lines:
As a [role] I need [capability] so that [desired outcome].
A user story really shouldn't be more complex than that, as they are really just placeholders for future conversations (a key aspect of Agile that most companies misunderstand.) Once you get to the point in an iteration where you are ready to implement a user story, you'll generate one or more tasks for that story usually in the form of Concern/Context/Observations:
Concern: Some Activity
Context: When doing such and such
Observation: This thing should be added to the database
Observation: The thing should get a new unique ID
Observation: The thing should be related to that thing
Each task is now written in such a way that it can be directly translated into a BDD-style "specification" test that sets up the context, performs the action of concern, and verifies the observations. (For a great example of how this works with xUnit.NET, see this site.)
It is important when creating user stories not to think too technically. You don't really want to break down your stories to highly technical and low level things like "Create a web page with title 'xyz'. Show stores a, b, and c on this page." Thats super technical and doesn't actually portray any useful business requirements. A story should be more fluid and dynamic and represent the real business requirement: "As a customer I need to see all of the stores that contain the products I am looking for so that I may purchase what I need at a great price." From that user story, you would then end up with tasks that define the more technical aspects of creating this page (I am extrapolating a lot from what I read in your question...forgive me for any artistic license I take in expanding the concept):
Concern: Finding Stores
Context: When looking for a product with the best price
Observation: The web page should display a grid of store thumbnails that contain the users search product
Observation: The stores should be sorted such that those with the lowest price appear near the top of the page
Observation: Clicking on a store's thumbnail should take me to a page on that stores web site that contains the product the user searched for
The above story is pretty high level, and covers the expected behavior of the whole page. The above specification can be used to verify proper behavior of the resulting page, used as baseline for creating automated UI tests, etc. However, there will also be code that drives this page, and additional tasks should be created for those lower level things as well.
Concern: Retrieving Stores
Context: When searching for Store entities containing a specific Product
Observation: A collection of StoreResultDetail should be returned
Observation: The collection of stores may be empty
Observation: Each StoreResultDetail should contain the store name
Observation: Each StoreResultDetail should contain the price of the Product
Observation: Each StoreResultDetail should contain the URL of the store's web site
Observation: Each StoreResultDetail may contain the URL of the Product on that store's web site
The above task could be implemented by a service method on some service, along with any other behaviors required to implement the specification for the whole page.
Once you have your tasks, you can create visual designs to match, implement code and unit tests (or BDD specifications), and QA test your application with proper, clear, and concise documentation to verify your tests against.
Segregating user stories by "web page" seems suboptimal to me -- you should be choosing the set of your pages based on user stories, not vice versa. I would classify by "role" of the user -- in fact, in user centered design, by the "persona" in play.
In our shop, we write up Use Cases. Examples of Use Cases:
Create New Customer Account
Assign User Rights
Receive Order
Accept Payment
We have a form with two columns. The first column is the user, and the second column is the computer system. In the two columns we begin listing actions. The user does this, the system responds like this, etc. We leave gaps between the entries so that the steps flow naturally from left to right, and back again. There's a place on the form that states which roles the use case is applicable to (e.g. Project Manager, Administrator).
From the use cases, we then begin to sketch up web pages.
You can also make Use Case diagrams:
I start with identifying what scenario's the users are going to perform with the application. Normally, these are quite predicatable. A user logs in to a website with a certain task in his/her head and wants to fulfill that task.
I'd limit myself to a scenario as one list of sequential steps. For example, user logs in, user select product, user chooses quantity, user checks out, end.
Having the scenario's written down can also help you to determine what parts of the application are more important that others, and which scenario's can be easily be implemented "in-between". And finally, which scenario's could be a show stopper for the launch of the application.
We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.