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.
Related
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).
BPMN (Business Process Modeling Notations) is used for modeling business process by visualization, thus making intangible ideas become physically concrete through the expression of BPMN diagrams. The question is, how do I organize the BPMN with the UML.
Initially, I thought of two ways to organize use cases and business process diagram:
1 to one/many: By mapping each step (step here means each node in the BPMN digram) in the business process diagram with one or several use cases. Each use case is mapped with relevant several class diagrams/component diagrams (I prefer this one, since you can encapsulate a set of classes into one component which has input and output), several sequence diagrams (optional). After you have class diagrams/sequence diagrams, code is written/generated based on the model.
Many to one: By mapping several steps into one use case. The subsequence steps are the same.
Many to many: For example, one step in the business process can be mapped with two or more use cases, and the same two or more use cases can be mapped with other steps.
The above methods can be done by the modeling tool, and in my case, I use Enterprise Architect from Sparx System. I discover it recently and I am using its trial, but I will buy it in the future. I can organize many use case diagrams with one step of the BPMN diagram, and can click to view the necessary use cases. However, I don't if it supports many to many cases.
After thinking my own method for organizing BPMN and Use Cases, I searched the Internet, and found two other papers, each suggest the following method:
Turn each use case into each step of BPMN diagrams: To visualize how refined use cases fit into the business process. I like this approach, since the business process with steps can be modeled, and later each step is turned into a use case. One step is one use case. This is the same with my one to one mapping above. Original presentation is here: Visualizing Use Case Sets as BPMN Processes
Each use case is exactly a business process: Each step in the use case is each step of the business process. Original paper is here: Describing Business Processes with Use Cases
It seems to me that there's not standardized way of gluing these artifacts (BPMN and Use Cases and other digrams) together. Maybe it's a management problem and rely more on creative usage rather than follow a formal steps. What are your opinions/experience on the usage of these diagrams in software engineering process?
I know methodology like XP which specifies its own practice in software development process. However, unlike Scrum where it focuses more on management aspects (which means you can still apply the BPMN/UML modeling into your work process), XP specifies software practices and requires you to follow, and eliminate the modeling process like BPMN/UML, and its practices if not apply properly will lead to issues like under documentation, incorporates insufficient software design....
I prefer the model driven way than XP. I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System). Another example is, people often complain about drawing diagrams consume their time. In my opinion, the solution is not to draw diagram, but the using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram). What's your opinions/experience on this issue?
Usecase should be goal oriented tasks they are not single steps. The first example is a definite variation of the standard way to utilise usecases. I suggest map each usecase onto a single business process. This Sparx EA example maps usecase onto activities diagrams but does reveal the approach to use.
My 2 cents
My suggestion is to use these tools to understand the business processes. I follow the below
End user point of view: user stories
Business Analyst perspective: use cases (with main and alternate flows) and specification by example
BPMN: Executable business process
When you start looking out for the perfect marriage of all these, you will be lost in details. ;-)
I suggest this approach: https://www.academia.edu/6750935/From_Business_Process_Models_to_Use_Case_Models_A_systematic_approach
Generally speaking, one process maps to more than one use case, only in particular cases the relationship goes one-to-one.
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
Similar diagrams would be:
information flow diagram
communication diagram
sequence diagram
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.
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.