I would like to model an application architecture and the time-outs between all the application (e.g. between application A and B there is a time-out of 10 seconds and that between all applications). Which modelling language should I best use for this that it is clear? I don't think UML diagrams will do the trick...
Thanks.
It depends on the purpose of your model.
Business oriented process orchestration
For orchestration between several tasks/activities of several applications of a complex process, you could use Business Process Model and Notation (BPMN), which is a standard of the OMG.
There you can model event-based "gateways" to control flow of control or "messages" between activities. An event could be in your case a timer or a error (e.g. time-out errors) depending on the desired emphasis.
Remark: THere are several third party tools that use BPMN models to generate BPEL in order to to make the modelled process orchestration exectutable.
Technical model
If you want to show interaction between applications, but not necessarily modelled as business processes (user perspective), you could also really consider UML:
activity diagrams can present event actions and also timers
eventually, sequence diagrams could present timing constraints and conditions. But intuitively I doubt it's the best choice for your question here.
Christophe's answer is correct. However, you can show time out with basic activity diagrams by using interruptible regions and an interrupt flow like this:
Of course BPMN can do that much better.
Related
i've been trying to figure out how to deal with Business Rules in the following format:
a booking has 1 to n (n = 200) articles
problem P shall be handled by the System XYZ
a specifict data-class shall be supported in the System XYZ
the communication to the customer shall be done by the organization Z.
it is possible to change a specific value in an order
the system XYZ shall be able to evaluate if a customer is able to pay monthly rates
in addition, many rules i got explain certain things that need to be fulfilled in order to let a future system work correctly. In my eyes, these rules are technical requirements. So, what would be the best choice? Hard-coding these Business Rules in Business Processes (it just sounds so wrong) or embedding a Business Rule Management System (with a Rules Engine) next to a Business Process Management?
My guess is that a Rule Engine is not the best choice for this. There are sometimes more than one possibilities and scenarios written down in each Business Rule and the common "if-then" statement does not apply in the most cases.
So i found out that in most cases there is this "if-then" statement (literature etc.), but then the SBVR from the OMG comes in (Semantics of Business Vocabulary and Business Rules). It confuses me because there it isn't required to formulate rules with "if-then" et cetera.
I assume that these rules are not specifically meant to be built in a rules engine, but rather kept an eye on during the implementation of the software and after this process. Yet i think that these Business Rules might change. Wouldn't it be naive to hard-code them in Business Processes?
If there's anyone with a hint, i'd be very thankful.
BR
Yeah, you just need to choose the right tool for the job. You should take a look at the Drools and JBPM projects. Where the main goal is to make the rule engine to coexist with the process engine. So for some of those "Rules" you can create a business process to take care of it and for another one you can just write a proper business rule. And the third option is to mix both worlds.
I watched some videos, read some blogs about it. SO has many questions and answers on that subject but I can not find anywhere exact answer for my question.
Almost every question and answer has a lack of usage context.
I have one middle sized, asp.net-mvc, monolith application which is running in one process on IIS. I want to (refactor and) go all the way with DDD (and CQRS without separated storage for reads and writes for now) but for me it looks like impossible mission without breaking some rules/guides/etc.
Bounded Context
For example I have more than one BCs. Each should not cross their boundaries which means should not share their storage. Right?
It is not possible if you use the whole known (everywhere scattered over the web) solution to work with NHibernate session and UoW.
Aggregate Root
Only one AR should be modified in one transaction. When others ARs are involved should introduce eventual consistency (if I remember those are Eric Evans words).
I try to do it but it is not easy in app like that. Pub/Sub not working as desired because if event is published then all subscribers are take their action within one transaction (NSB/MT does that way).
If event handlers wants to modify others ARs they should be executed in separated transactions, right?
Is it possible to deal with it in monolith application (application where whole code works in one process)?
It is not possible if you use the whole known (everywhere scattered
over the web) solution
[...]
if event is published then all subscribers are take their action
within one transaction
I think you're setting yourself useless and harmful constraints by trying to stick to some "state of the art".
Migrating an entire application to DDD + CQRS is a massive undertaking. Some areas of it don't have well-documented beaten paths yet and you'll probably have a fair bit of exploration to do. My best advice would be to stay at a reasonable distance from "the way people do things". Both in traditional ASP.Net web apps because mainstream practices often don't match the way DDD+CQRS works, and in CQRS itself because the case studies out there are few and far between and most probably very domain specific, with a tendency to advocate the use of heavy tools which may not make sense in your context.
You may need to think out of the box, adopt things incrementally and refrain from goldplating everything. You'll be better off starting with very simple implementations that suit your needs exactly than throwing a ton of tools and frameworks at your codebase.
For instance, do you really need a service bus or could a simple Observer pattern suffice ?
Regarding NHibernate, most implementations out there use a (single) Session Per Request approach, but just because it's the most popular doesn't mean it's the only one. Have you tried using multiple ISessions (one for each BC) available at a more programmable level, such as per-action, or managed entirely manually ? Conversely, have you considered sharing a database between Bounded Contexts at first and see for yourself if that's bad or not ?
I'm building a rails application and I'm having trouble working out how create diagrams for the application architecture.
I've created UML class diagrams in the past, so consequently that's where I headed. I've found the railroady gem that generates UML class diagrams via a rake task, however it separates the models from the controllers - which feels fragmented to me.
What I want to know is whether there is another (preferably better) way to model an MVC (rails) web application.
I'm not necessarily looking for a gem to generate the diagram for me, I'm happy to create it manually in visio, I just don't know what type of diagram I should be using.
You may want to try the Robustness diagram, also sometimes called MVC diagram.
See for example here and there.
It is not really a UML diagram, but most UML tools manage it through stereotypes and custom icons. The tool I use, Magicdraw UML, uses a class diagram, but I think I heard of tools that use communication diagrams (not sure, though).
However, it may or may not meet your expectations, as it is a very global diagram.
There exist a metodology named UWA (Ubiquitous Web Application) that allows you to describe not only the data structure, but also the navigation, presentation and transaction models.
The UWA methodology has a user-centered approach, which improves the requirement and design definitions. Since this metodology was developed specifically for modelling web applications, it allows a clear separation of content, navigation, transaction, publishing and operational elements.
UWA begins with a goal-oriented requirements engineering that naturally arise to later design stages, revealing key features that should be implemented. This leads to reasoning about some requirements that might have not been identified beforehand, or may have been underrated.
You may find additional information about UWA here.
Even if you decide not to apply this methodology, it may provide you with some tips about adapting UML diagrams to web applications.
Have you ever come across a Use Case Diagram before? It's not strictly a diagram to outline a systems architecture, but it does provide a good visual representation of communication with other parts of the system/ external actors, during a given "use case" (or process).
For example:
User(Actor) --> Update Status(Use Case)--includes-->(Log in)
Here we have a user wanting to update their status. In order to do this, they need to be logged into the site (an included use case). Thinking about this in MVC mode, we know that "Update Status" and "Log in" would both be controller methods, which would both communicate with the attracted website database (also an actor), thus demonstrating the communication path within a system.
Actors of a system can be anything that communicates with the actual system during a process, usually externally, so users, browsers, database, clients etc.
In terms of modelling the MVC architecture, this is done best by the Class diagram, but a Use Case diagram would also aid in the visual representation.
I always draw up a Use Case and Class Diagram together before I start coding, as a way of extracting the system requirements and laying them out in a working design. UML diagrams are design tools after all- there's not really much point in creating one after you've written the system code!
Just something to think about anyway- hope this helps!
brief overview of basic use-case diagrams
That is a broad question, and I appreciate no short/dumb asnwers like: "Oh that is the model job, this quest is retarded (period)"
PROBLEM Where I work at people created a system over 2 years for managing the manufacture process over demand in the most simplified still broad as possible, involving selling, buying, assemble, The system is coded over Ruby On Rails.
The app has been changed lots of times and the result is a mess on callbacks (some are called several times), 200+ models, and fat controllers: Total bad.
The QUESTION is, if there is a gem, or pattern designed to handle Rails large app logic? The logic whould be able to fully talk to models (whose only concern would be data format handling and validation)
What I EXPECT is to reduce complexity from various controllers, and hard to track callbacks into files with the responsibility to handle a business operation logic. In some cases there is the need to wait for a response, in others, only validation of the input is enough and a bg process would take place.
ie:
--> Sell some products (need to wait the operation to finish)
1. Set a View able to get the products input
2. Controller gets the product list inputed by employee and call the logic
Logic::ExecuteWithResponse('sell', 'products', :prods => #product_list_with_qtt, :when => #date, :employee => current_user() )
This Logic would handle buying order, assemble order, machine schedule, warehouse reservation, and others.
Have in mind that a callback on SalesOrder is not enough, since it depends on where it is called (no field for that), depends on the class of the user, among other stuff not visible for the model, or in some cases it would take long for the model to process.
The inherent complexity of the business object and logic will need to be tackled with, understood, and internalized (or at least documented well) for the team. That will not go away. The recommendation I have is to grab all the logic peppered throughout the "fat" controllers and move them into either the domain objects, application services (service layer), or simply transaction scripts (see Martin Fowler's "Patterns of Enterprise Application Architecture").
Ideally all the business logic embedded in the labyrinth of callbacks can be refactored into components described above to promote understanding. This gets rid of all the incidental complexity built up over time on the controllers. But even after getting rid of all that, I suspect a certain level of inherent complexity will remain in the problem domain.
The idea of Service Layer is to incorporate high level logic which is not associated with certain model in a good way. If you develop enterprise like system with multiple services integrated and have number of data sources you should better look to Domain-Driven Design (DDD) by Eric Evans. Surely, Fowler's Enterprise patterns book is good in this case too.
Also look at DataMapper(2, the first one was similar to ActiveRecord). It has better design approach for such type of systems and have less limitation (on conceptual level) than ActiveRecord in Rails.
Truly say, that's because of dynamic nature of Ruby people so long tackling conceptual problems of ActiveRecord and try to fit it enterprise needs, IMHO.
Some people have done some work out there on service layers and callbacks Pat Maddox (especially callbacks) is one, Jay Fields (his very early works around the rails presenter pattern later to be replaced with a service layer like pattern) is another. I must admit I like the idea of adding a extra layer. To me, business logic just doesn't belong in models and models should be decoupled in complex projects. I also like the idea of an extra layer over callbacks, for me callbacks become too complex as there numbers increase
This is far from full blown DDD and at the moment I don't know how DDD would work in Rails, however ,I am sure it could and I am sure someone is working on it out there right now. For my projects, at the moment, it would be a bit of a overkill to implement, however, I would consider adding a service layer.
I know there is a lot of talk about BPM these days and I am conscious that some may see it to be a craze rather than a fundamentally important piece of software.
As someone from what most would call 'The Business', I have been doing my best to learn about BPM to ensure we continue to make decisions that not only make sense to the business, but IT as well.
I have noticed while reading that mention is made to application workflow when sometimes discussing BPM. I hadn't given this much thought until recently.
Therefore, what is the difference? When would you use one and not the other?
BPM is about the process and improving it, which takes into account users and potentially more than one application,e.g. an ERP system may have more than one application to it, though there may be other uses of the term. Note that the process could be viewed without what applications or technologies are used.
Application workflow is how an application is used to go from a to b. Here it is a specific set of code that is used and what happens over the course of an application getting from a to b. In this case, the application is front and center rather than the process.
Does that provide an answer? Another way to think of it is that multiple application workflows can make up a system which is used in a process that can have BPM applied to it.
Late to the game, but workflow is to database as BPMS is to DBMS. (Convenient how the letters line up, huh?)
IOW, BPM(S) is traditionally meant to refer to a particular framework/application that allows you to manage business processes: defining them, storing them, versioning them, measuring them, etc. This is similar to how a DBMS manages databases.
Now, a workflow is a definition, much like a database is a definition. In the former case, it is a definition of operations/work (Fufill Order), steps thereof (Send Invoice) and rules/constraints on the work (If no stock, send notice). In the latter, similar case, it is a definition of data structure (CREATE TABLE) and constraints (InvoiceTotal must be > $0.00).
I think this is a potentially confusing subject, particular as some development environments use a type of process flow model to generate user facing applications (I'm thinking about Outsystems here, for example).
But, for me, the distinction is crystal clear. Application workflow, as people talk about it, refers to a user's path through an application, i.e. the pages they complete/visit, the data they enter, etc. on their way to completing a transaction of some sort. Application orkflow is a poor term for this though, I think application flow would be more meaningful.
BPM on other hand, is about modelling and executing a workflow process. By workflow, in this context, I mean a series of discrete steps (or tasks) that have to be completed (either programmatically or via human interaction) in a certain order to complete a process. These tasks can be implemented as individual application modules (each with their own "application workflow", see above). The job of the workflow engine is to make sure that these separate steps are assigned to the right people (of groups of people) in the right sequence, and that overall the process completes in an orderly way.
I don't think there's a clear answer to this at all. These are words, as opposed to theoretical concepts. If you add the word "checklist" into the mix - that just turns out to be a linear version of a process (but you can have conditionals in checklists - making them a workflow).
I am not sure how to help in reframing this question, but it's almost as if no answer can ever be possible. My own thoughts are at https://tallyfy.com/improving-efficiency-workflow-vs-business-process-management/