Can anyone suggest good diagrams/modeling techniques for business process modeling? I was thinking about using activity diagram but the process includes quite a lot of forks and secondly, activity digram may be somewhat difficult to understand to non-technical users.
Sequence diagram is rather similar but what other tools are there? DFD?
For me UML activity or BPMN modelling would be the best way.
Sequence diagram is more appropriate for sequence representation not flow specially with a lot of forks.
There are also the Eriksson-Penker UML extensions. Enterprise Architect from Sparx Systems supports these as well as BPMN; I don't know what sort of support other tools provide.
Related
Programmer Types:
Do you write extensive design documents for your programs or games?
Is using UML the standard method of diagramming your use cases?
Do you run the whole gamut of diagrams or sort of pick and choose along the way depending on the scope of your software and the number of developers on the team?
First,
If you make documentation, it should have a "clear" reason/purpose.
And this purpose is identify nature of your documentation.
Secondly:
Do not think documentation just in a "written form" or word document.
It may be in any form.Even it can be a "video" in which some guy
explain your major architecture decisons and why they choose
it[motivation]
Well, suppose that you want new team members "easily grab" what you are doing,how you are doing, and why you are doing this way.[ Be carefull all depends on your problem nature]
UML use case diagram may can give overall picture of your functional
requirements. It simply states who will use your system, and what they can
do with your system.
Short memos which state the important non-functional requirements
Short memos which states your major architecture decision and why you give this decisions
Maybe a component diagrams which shows your important components and their interfaces
If application tapology is important then may be a UML deployment diagram which shows how your system will be physically deployed.
But after all you can not document evething and you should not .You can generate whole system UML class diagram automatically with a UML tool, but how can this help a novice.
But you can put class diagrams for classes that do important and tricky
parts and draw sequence diagrams for those tricky parts which show how
they collaborate with other classes while they perform important and
tricky responsibilities.
The key for documentaion is puting yourself into your "audience" [ who
will read your doc] and ask yourself
If I was this document potantial "audience" will i read this document? [ If not why you make doc]
If I read this doc, will it help me in some way? [ it is effective]
Lastly, we do not live in "ideal word"...Sometimes you may find yourself doing doc for no real audience and no real reason just because of some "politics" and you should earn money
Well, in this situation UML will help. Draw boring, with many details [ genarally auotumatically generated] diagrams which no one read or understand but say "Oh you have extensive documentaion". In our software industry, UML is overemphasized, and many guys "buy" even bad doc if there is a UML diagrams in it.
That's all folks...
Our business is planning on building a rather large business application with about 2000 or so users.
Many objects in the system require a mildly complex series of approvals, notifications, etc.
For various reasons, our company has decided to reject formal use of BPMN or BPEL. What I am looking for is a workflow engine that I can pass these objects to as a means of facilitating, tracking, and managing the state of these objects. We are implementing this project using EJB 3.1 with a WebSphere AS.
Am I correct in my understanding of a workflow engine? Everything seems tied to BPMN or BPEL...am I just missing something here as to why most solutions seem to implement BPMN or BPEL? Some advice would be wonderful!
Workflow engines typically take an active role in an enterprise architecture. They execute a declarative process model, which is basically a directed graph consisting of nodes, which represent activities or tasks and edges, which represent the control flow between these edges. Such edges can be annotated with conditions to allow for expressing conditional branching/merging. There are several modelling languages around, like YAWL, XPDL, jPDL, BPEL and BPMN 2.0, which sit on top of these abstract concepts and some syntatic, visual and functional sugar, but only the latter are official industry standards. This is important to avoid vendor locks, make models interchangeable (at least to a certain extent), supportable by experts and different tools. During runtime, process instances are created based on a process model and are executed according to the control flow defined by the model. So the engine actively navigates from one activity to the next activity and thus "orchestrates" your business logic. The main difference between BPMN 2.0 and BPEL is that BPEL is tightly coupled to Web services, i.e. business functions to be invoked by activities are supposed to be rendered as Web service. So if you want to orchestrated WS-* services, it is still the best choice since BPMN 2.0 lacks well-defined and standardized bindings to concrete service implementations. In any case, I'd strongly recommend to use one of the standardized languages since they are both broadly accepted in industry and well supported by various vendors and open source communities.
I tried to explain that in more details because I was not entirely sure about what you mean by "facilitating, tracking, and managing the state of these objects". This sounds a little bit like you are more interested in passively monitoring an object's state change as opposed to actively controlling state changes using a workflow engine. If this assumption is right, then perhaps a abstract state machine would fit your needs better.
Take a look at jBPM5, it provides a very flexible core that allows you to build your own domain specific language on top of it. Right now the language provided is BPMN2, but you can easily add your own.
Cheers
We are building a product that has a migration path for BPMN 2.0 but does not - internally, use BPMN. We believe checklists are much easier to use in real-time workflows than flowcharts. Is still however, has rules/triggers/conditionals and more - so it's a tool that effectively models processes as "checklists on steroids":
Check it out at http://tallyfy.com
There are some Topics on Stackoverflow already related on how to model different Threads in UML, for example: Is there an inituitive UML approach to depict threads.
However I still feel, that my case has not been already discussed, even though it should be pretty common:
I am creating an iPhone Application, where I am obviously have a Main-UI-Thread and I am also using Background-Threads to perform Remote-Calls, etc. I basically have 4 different aspects that I like to display within my diagramm:
The UI that is shown to the User.
The Tasks that are being performed by the Main-UI-Thread (therefore blocking the UI)
The Tasks that are performed by Background-Threads
Updates of the UI, which are performed by the UI-Thread, but can be triggered by Background-Threads. For example: new Information loaded from Server, which needs to be displayed on the UI
Has anybody ran into a similiar issue and therefore might show me an example or give me some best practises on how to solve my problem? I am not even sure if I should use a sequence-diagram, an activity-diagram or maybe even some other type.
Well Pascal,
This is not an UML question. It is a design question.
UML just helps you
To understand hard and crtical section of your program/design and to
explore alternative solutions , while writing your code. with the power of visual modeling.
So..
First, ask yourself what kind of parallelism or concurrency exist in
your problem? To investigate this:
Draw a simple activity diagram with partions in which each partions
used to represent different operating system threads or processes.The
object nodes can be used to model the shared objects and data.Forking can be used to model the creation and parallel execution of multiple threads or processes.
Then ask yourself(using that diagram)
What are my shared data? What are my active classes? (threads)What kind of "concurency" problems" may
accour? What may go wrong? What are synronization points? etc..Based on this Explore different alternatives, designs.
The last thing you should worry is UML and its sytax(symbols).
The best UML diagrams are the one that wake up the desire of "asking question" in your mind.
At first forget about Uml. Ask core questions about your problem. If you like visual modeling and your mind like visual thinking use Uml for better understand and investigate possible design solutions.
UML can not design for you...
I found this research papers while searching for same thing
M-UML: an extension to UML for the modeling of mobile
agent-based software systems
May be it can help you
I searched a bit for the differences between OODBMS and RDBMS. I pretty much know what they are. However, how I will decide which one is better for which applications. Can anyone kindly help me please?
What I meant for factory management is: there are production lines to manufacture bottled, frozen and other food stuff. The application manages from assigning staff onto the lines, to keep the production records in the system. Which dbms is better for such systems?
Thanks in advance.
Here is a nice article by Rick Grehan that describes cases where ODBMS are useful:
http://www.odbms.org/wp-content/uploads/2013/11/006.04-Grehan-When-to-Use-an-ODBMS-2005.pdf
Disclaimer: this is an "old curmudgeon" answer, from a guy who wrote plenty of perfectly functional accounting, manufacturing and other code before OOP came into the mainstream.
With that being said...
Factory management is classic relational database stuff, it's what it was invented to do. The code for classic relational apps tends to follow very predictable patterns, lots of loops over retrieved rows from tables, or straight pass-through stuff: passing data up to the UI or down to the database. If your DB is well-designed, the biz logic you code will be details in those loops or pass-throughs, but those two patterns will dominate.
An OODMS on the other hand, from the point of view of this "old curmudgeon", attempts to recast the perfectly and efficiently functional RDBMS into something that will work with classes/objects, for no discernible gain over a system that has proven itself for decades to work extremely well. Classes have little or nothing to do with the classic code patterns that sit on top of relational databases. In fact, they tend to complicate things and can easily get in the way. I'm not saying don't use OOP code to deal with the database, just that OOP was invented for a different kind of problem, a problem that database apps don't happen to have.
Decision to choose OODBMS or RDBMS does not depend upon particular application like factory management/automation.
It is depends on many criteria like
1) Programming Paradigm - If you [programmer] choose to visualize/implement in the OO programming language then the OODBMS is suitable to store the objects as directly into the database, but Most widely the type of DBMS Relational, because it is well established commercially and have a good mathematical background.
2) Application Specific - For an factory automation/management, responsiveness and fast access is important. The OODBMS are swifter than the RDBMS. If you considered for web-development then a light-weight tool like MySQL will fit a lot.
3) Trend - Now there is paradigm swift from Legacy/Structural to Object/Component Oriented programming. so therefore, in this trend the OODBMS is best suitable for the Enterprise Applications like factory management, etc.
It depends on the application layer using. If it is a simple approach more towards procedural way [which can have classes too] RDBMS is more suitable. Otherwise if you are more towards a strict object oriented system OODBMS can be used.
I usually draw the line of usefulness at the point in which they need to be integrated into enterprise systems. If your project does not necessarily need to integrate, ODBMS is usually easier or technically superior. If you can integrate via web services or "push/pull" into an enterprise system DB, then you can still use an ODBMS, but there might be political pressure against it. (newer ODBMS/RDBMS replication like dRS for db4o may be a good fit) But if you need tight integration with legacy or enterprise datastores, then you're usually forced to use the RDBMS for one reason or another.
That said, your individual production lines might benefit greatly from an ODBMS which are great at storing oft-changing complex object models and schemas while the orchestrator system could follow my previous line of thinking.
I've been using ODBMS for many years, and have been dreading the project which requires me to return to purely relational data management. Although recent improvements in ORM tooling have made relational much more pleasant to work with, the ORM+RDBMS solution still can't keep up with ODBMS systems in a few key areas (see the previously mentioned article on odbms.org).
QVT (Query View Transformation) is a OMG specification of a Model-to-Model transformation language. Some tools already implement it (Eclipse, androMDA). I'm wondering whether it is really used in real-world cases. Will it ever take off and be used to tackle real-world problems? Is anybody using the QVT language?
From observing the MDD community for our own projects, I'd guess that QVT will eventually pick up. Currently ATL and Kermeta seem to be very popular, and from looking at the postings in the groups not only in academia.
There's an implementation of Declarative QVT now (see the M2M Eclipse group for the announcement), that'll be very interesting for us. We've been using the ModelMorf prototype, but it was a prototype and had a very huge turnaround time. I hope that with the integration of dQVT into the Eclipse tool chain we'll be able to use it for our own projects (a SoftEng tool, see http://rcos.iist.unu.edu, sorry, academic of course :).
I guess the pain of doing Model-driven development by hand/with man-power is not high enough yet...once the tools really increase the order of magnitude of productivity, that'll change.
Seems like QVT is beeing used for Model Driven Security applications. It is a good choice because of clearly defined semantics and provability. This still is reasearch however. France Telecom is experimenting with QVT. They want to use it for database migrations and a generative approach for applications.
http://smartqvt.elibel.tm.fr/events/QVT%20Experimentations%20at%20France%20Telecom.pdf
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4159881