I have to create a UML activity diagrams for a searching application for a semantic database.
Easy to guess, users can search and select a file, but they can also browse and refine the retrieved results by clicking the categories the results belong to. They can even select a file just by browsing without actually entering any keyword.
Should I create one single 'large' activity diagram showing the different possible workflows or a series of smaller ones, such as "perform a search", "browse the collection" or "select a file"?
I think, what you have mentioned is more likely to be a sequence diagram ("perform a search", "browse the collection" or "select a file"), and I would recommend you to have several sequence diagrams that you listed. My argument for this is: these diagrams are consumed by testers at design stage, so they can write tests for it.
And the major activities you can put into overall activity diagram, that will show the possibilities of what user can do at a given step/stage (if I can logged in, I can perform a search, browse the collection, etc).
Personally I would create a large UML providing an "over-view" of functions that are provided by your application. I would then create smaller more detailed UML diagrams so that the application's functions can be studied in detail.
Hope that helps with your decision.
Regards,
Mike.
Edit: I find Microsoft Visio particularly useful in which to create the UML diagrams too.
Related
I’m trying to prepare UML model for my project. It’s quite complex however I focus on one of use-case. In short term, use case name is “Edit patient results” and actor “Doctor” uses it. In fact, entering results triggers always the set of following actions:
List item
Normal Ranges calculation
Related Expression calculation
Interpretation merging
Assuming that I have my use-case diagram prepared as follows:
My questions are:
How shall I draw actions that are triggered automatically? As extended use-cases like this?
How shall I draw “Edit patient results” use-case realization? Each edit operation involves several software components interactions, shall I use collaboration diagrams? (how to join my main use-case with them), maybe something else?
How to draw sequence diagrams to show actions sequence and parameters passed? How to join these diagrams with my use-case.
What is the best way to show use-case realization
I'm using Enterprice Architect.
Thank You !!!
No. These are just activities which are part of scenarios inside the use case. Trying to make the use cases is functional analysis the wrong way. A use case synthesizes a number of steps under a common goal/added value.
A use case realization is a collaboration (bubble with dashed line border; along with the UC in the toolbox). The collaboration contains diagrams which show how the single classes communicate/collaborate to realize (parts of) the use case. Use a Realization from Collaboration to Use Case.
Put the SDs inside the collaboration and group/name them reasonably.
see above
As to your comments:
Edited 2.
I never found a good use for Collaboration Use and I've done a lot of successful UC modeling. So you can probably live without it as well.
Put Actions inside an Activity representing a scenario and connect them as desired. You might look into BPMN as well.
I am on a review of a business process models. I am experienced in UML but not in BPML. The problem I have is that the process models includes user tasks which looks like user actions(from UML) e.g. user press button, user saves, etc. and some technical activities like establishing connection etc.
As far as I know the process model is high level overview and not this kind of granular actions which describes detailed user interactions.
Questions:
Is it correct that a business process model includes kind of user
actions like "Press save button"?
How granular should be the BPMN user/service tasks?
BPMN covers all aspects of the business and it is meant as a Porsche version of the Volkswagen Activity diagramming. Note: the "Press save button" is not an activity but an action.
BPMN has been developed in order to enhance the documentation of use cases (I'm taking this as synonym for the business process which is not 100% correct but gives the idea) which so far had (more or less) only support in activity diagrams. BPMN's goal is to deliver a complete set of notation which can describe everything related to business, thereby offering the possibility to even document technical aspects, such as timing constraints, exceptions and so on. If you can read activity diagrams its quite easy to read the BPMN notation. However, creating those documents on your own needs practice. It's like the difference between passive and active language.
From the BPMN specs intro:
This specification represents the amalgamation of best practices within the business modeling community to define the notation and semantics of Collaboration diagrams, Process diagrams, and Choreography diagrams.
The current document from OMG is found at BMPN Specs. It's not intended as learning document but as technical specification (mostly for tool vendors). But Google will find you some nice tutorials.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.
I would like to know:
how to convert users stories into sequence diagrams?
and what is the most easy diagram to understand (for customer)?
Traditionally, a use case is converted into sequence diagrams (through a "use case realization" collaboration for traceability). User stories are different from use cases in that the latter provide a set of distinct steps to take whereas the former concentrate on a need and reason.
If you were to to take a use case, each of the steps in the use case would be represented by messages in the sequence diagram. The use case actor (the "user" in the user story) would be the initiating timeline and a second timeline would be the "system". You could then iterate on that sequence diagram to extract various system components (thereby building a domain model for your application).
Does that make sense to you?
how to convert users stories into sequence diagrams?
There is no straightforward easy way. There is not enough information as user story is basically one or few sentences of text. Converting use cases to sequence diagrams is easier and can be partially automated
what is the most easy diagram to understand (for customer)?
it depends on who is the customer. In general, overview diagrams, e.g. BPMN style should be easy to read. See my answer to the question "UML diagram for dependency between systems" for some options and useful links
suggested readings
Enterprise Architect video - how to convert use case into a diagram -http://www.sparxsystems.com/resources/demos/use-case-analysis/structured-use-case-scenarios.htm
Enterprise Architect - various ways how to capture requirements and communicate them to stakeholders - http://www.sparxsystems.com/products/ea/requirements.html
Mike Cohn's page (defined the term "user story") about user stories - http://www.mountaingoatsoftware.com/agile/user-stories
Alistair Cockburn's page (defined the term "use case") about use cases - http://alistair.cockburn.us/Use+Cases
Some examples of tools for creation of sequence diagrams: https://www.websequencediagrams.com/, http://creately.com/diagram-type/uml-sequence-diagrams, you can Google out many more examples both free and payed both online and offline
In my opinion, what works best with the customers are not use cases. They are too abstract and complicated even for the most of developers. And when they are finally approved, you're never sure whether the customers actually understood them correctly.
I suggest the mix of UML activity diagrams and user interface prototypes (non UML) as far the best tool to work on this level of analysis with non technical business people.
Activities model their business in an intuitive, easy to understand and clear way.
UI Prototypes as well, so they can see how they business maps to screens.
Behind the curtains, I like to support activities with a formal and accurate domain class model, invisible to customers of course, but open to developers and making a nice technical backbone of the future system.
User stories fit perfectly in this modelling set, you can even make them less formal and more high-level, as the rest will fill the information gap. Sequences can now be build using domain objects, connecting 2 views - customers' and developers'.
I avoid use cases strongly, whenever possible (although I personally like them).
Can I use UML for modelling website navigation? If so someone give me some books/links for referrence (UML for websites kind of...!!!). If not so what are the tools for this?
And basically I am a programmer and when I designed my previous website I just sketched down different page design ideas on paper and opted the one that I felt suitable. Then I did implement that design using html/css from scratch.
Is this the approach generally taken by all or have tools for drawing the to be implemented website designs (Wireframe kind of..)? Is the CMS meant for this? Please guide me on this.
Thanks
From time to time, I'll (ab)use a state diagram to lay out a site. Each "state" represents a page (or group of pages), each "transition" a flow from one page (group) to another.
I don't try to capture all navigation: that becomes impractically noisy very quickly. However it can be useful for capturing primary flows, e.g:
Arrive at home page, select login, navigate to login page
Enter credentials
If credentials correct: navigate to post-login landing page
otherwise: remain on login page
etc.
It's not a 'proper' state diagram but can be useful. You might also want to look at Garrett Information Architecture. It's a bespoke notation for the same problem but has a richer set of symbols.
hth.
Maybe, you will find this article useful :
http://www.ibm.com/developerworks/rational/library/4697.html
This article detailing user interface navigation via UML Activity Diagrams.
You might want to take a look at UWE, as it is as close as possible to UML and can do the job. The only problem is that there aren't many tutorials or documentation available.
If you're using UML in other parts of the design process, it makes sense to ensure that the user interface you put together meets your use cases. However, I've never used UML to actually design the layout or flow of a site.
We use Axure to mock up user interfaces, as this helps to let the customer/user have a play with the flow before spending time crafting the actual pages.
That said, I still do my website design using a pencil and paper.
Absolutely.
UML State Diagrams works quite well for this purpose. I have worked at large companies where this was standard practice, and with great success (even when keeping within strict UML rules and practices).
The key is to keep in mind what it is what you want to communicate with your diagram, and not try to model too many aspects within a single diagram. And also, keep in mind your audience. If you have to explain UML to them how UML works, then UML is not suitable for your situation.
I strongly disagree with those who think this is an "abuse" of UML. Consider that state diagrams represents the different states of a system and the transitions between them as brought about by events. When representing UI navigation, you are presenting UI forms as state and user actions and UI events as the events that brings about a change within the context of the UI instance of the system being presented to the user.
You are welcome to disagree with me, but please provide proof or support of your argument.