I'm using Bonita Studio and I would like to create a task which would be shared between two pools and an other shared between two pool lanes.
I'm trying to draw all processes in a web dev company to then optimize them, and a visual support is probably the best way to show the modifications. With this goal in mind I'd need to represent meetings with the different people participating to it.
Am I using the right notation model? If so how do I show these meetings? If not what is a better notation model to show a process with different people working together on different tasks with meetings?
In BPMN, pools identify processes rather than objects or subjects. You cannot split a single task between two pools.
You also cannot split it between two pool lanes. Actually, lanes have no predefined semantics; they can represent anything you want: companies, people, divisions, etc.
So, I'd propose the following. If you have "Software developer", "Designer", "Product Manager" lanes and want all of them participate in a meeting, add one more lane and name it "All project participants". And put the meeting task there.
I think that this won't violate both syntax and semantics of BPMN.
Although you're using Bonita, I'd advise you to visit http://elearning.bizagi.com for a nice online video course dedicated to BPMN diagrams design. It is based on BizAgi modeler, but 1) this modeler is a freeware and 2) There is One BPMN Standard to rule them all. :)
Task done by Many persons has no responsibility.
Just decide who is responsible for establishing, facilitating such a meeting and make task "Orgnanize Meeting" in his pool.
You can put note on whom he should invite, checklist, expected outcomes.
Related
I have to build an Use Case diagram, but one of the actors has two different scenarios, for example the actor has to either choose one laptop or some laptops.How do I represent that in my Use Case Diagram?
Welcome to Stack Overflow. From a use case perspective, it does not matter: The diagram must outline the goal(s) of the system under design. So you have to answer: Why would the actor want to choose laptops? To purchase them? To create a repair request? To send them to a recycling project?
Outline the details in another diagram, such as the various choices of the user during the selection process. Activity diagrams are great for that.
I am trying to understand the Single Responsibility principle but I have tough time in grasping the concept. I am reading the book "Design Patterns and Best Practices in Java by Lucian-Paul Torje; Adrian Ianculescu; Kamalmeet Singh ."
In this book I am reading Single responsibility principle chapter ,
where they have a car class as shown below:
They said Car has both Car logic and database operations. In future if we want to change database then we need to change database logic and might need to change also car logic. And vice versa...
The solution would be to create two classes as shown below:
My question is even if we create two classes , let’s consider we are adding a new property called ‘price’ to the class CAR [Or changing the property ‘model’ to ‘carModel’ ] then don’t you think we also need to update CarDAO class like changing the SQL or so on.
So What is the use of SRP here?
Great question.
First, keep in mind that this is a simplistic example in the book. It's up to the reader to expand on this a little and imagine more complex scenarios. In all of these scenarios, further imagine that you are not the only developer on the team; instead, you are working in a large team, and communication between developers often take the form of negotiating class interfaces i.e. APIs, public methods, public attributes, database schemas. In addition, you often will have to worry about rollbacks, backwards compatibility, and synchronizing releases and deploys.
Suppose, for example, that you want to swap out the database, say, from MySQL to PostgreSQL. With SRP, you will reimplement CarDAO, change whatever dialect-specific SQL was used, and leave the Car logic intact. However, you may have to make a small change, possibly in configuration, to tell Car to use the new PostgreSQL DAO. A reasonable DI framework would make this simple.
Suppose, in another example, that you want to delegate CarDAO to another developer to integrate with memcached, so that reads, while eventually consistent, are fast. Again, this developer would not need to know anything about the business logic in Car. Instead, they only need to operate behind the CRUD methods of CarDAO, and possibly declare a few more methods in the CarDAO API with different consistency guarantees.
Suppose, in yet another example, your team hires a database engineer specializing in compliance law. In preparation for the upcoming IPO, the database engineer is tasked with keeping an audit log of all changes across all tables in the company's 35 databases. With SRP, our intrepid DBA would not have to worry about any of the business logic using any of our tables; instead, their mutation tracking magic can be deftly injected into DAOs all over, using decorators or other aspect programming techniques. (This could also be done of the other side of the SQL interface, by the way.)
Alright one last one - suppose now that a systems engineer is brought onto the team, and is tasked with sharding this data across multiple regions (data centers) in AWS. This engineer could take SRP even further and add a component whose only role is to tell us, for each ID, the home region of each entity. Each time we do a cross-region read, the new component bumps a counter; each week, an automated tool migrates data frequently read across regions into a new home region to reduce latency.
Now, let's take our imagination even further, and assume that business is booming - suddenly, you are working for a Fortune 500 company with multiple departments spanning multiple countries. Business Analysts from the Finance Department want to use your table to plot quarterly growth in auto sales in their post-IPO investor reports. Instead of giving them access to Car (because the logic used for reporting might be different from the logic used to prepare data for rendering on a web UI), you could, potentially, create a read-only interface for CarDAO with a short list of carefully curated public attributes that you now have to maintain across department boundaries. God forbid you have to rename one of these attributes: be prepared for a 3-month sunset plan and many many sad dashboards and late-night escalations. (And please don't give them direct access to the actual SQL table, because the implicit assumption will be that the entire table is the public interface.) Oops, my scars may be showing.
A corollary is that, if you need to change the business logic in Car (say, add a method that computes the lower sale price of each Tesla after an embarrassing recall), you wouldn't touch the CarDAO, since if car.brand == 'Tesla; price = price * 0.6 has nothing to do with data access.
Additional Reading: CQRS
For adding new property you need to change both classes only if that property should be saved to database. If it is a property used in business logic then you do not need to change DAO. Also if you change your database from one vendor to another or from SQL to NoSQL you will have to make changes only in DAO class. And if you need to change some business logic then you need to change only Car class.
Single responsibility principle as stated by Robert C. Martin means that
A class should have only one reason to change.
Keeping this principle in mind will generally lead to smaller and highly cohesive classes, which in turn means that less people need to work on these classes simultaneously, and the code becomes more robust.
In your example, keeping data access and business logic (price calculation) logic separate means that you are less likely to break the other when making changes.
How can I model a task that is performed by multiple roles?
Example 1: 3 roles have to meet in order to discuss an issue
Example 2: 3 roles collaborate in order to create a concept
-
Your problem is thoroughly addressed in this excellent BPMN blog:
Activities cannot be placed common neither between pools nor lanes, and this is a common mistake. While this blog proposes possible solution I don't treat it as optimal and recommend you to check this answer on almost similar question as yours.
In my opinion you have to choose from these two options:
Either place your common activity inside separate collaborative lane which will be semantically equal to all your three roles.
As it fairly stated in the above answer, lane semantics is not strictly described in BPMN standard, so we can freely address any entities through it.
Or place your collaborative activity into separate pool. It's what BPMN collaboration diagrams are designated for.
You should choose the proper variant based on the semantics of your process.
How can I model a task that is performed by multiple roles?
Example 1: 3 roles have to meet in order to discuss an issue
Example 2: 3 roles collaborate in order to create a concept
Any activity can have only one performer. It is (your question) mean, that 3 roles (performers) do the same activity at the same time and produce "something".
As it is the same task for all users using a multiple instances parallel activity can be a solution.
In this scenario task definition is actually the same for all users: they need to meet other members to discuss an issue or collaborate.
there is a semantical difference in having the same task in separate lane as opposed to having the same task in a unique role lane. The former doesn't highlight a joined effort compared to the later. In other words, 3 people in separate rooms thinking about it, as opposed to 3 people brain-storming together in the same room.
What is the difference between CRUD and Use-cases in Object Oriented Programming?
I'm making numerous objects and I want to know which one is faster to use.
Which one is more efficient, and which one is easier to use?
CRUD is short for Create - Read - Update - Delete.
Use-cases, like it is written, are cases in which you use your system.
So CRUD may be part of an use-case.
For example, a Library Management System may have some use-cases like, Creating User, Deleting User, Update User info, Querying user's info, lending book, returning book, subscribing, unsubscribing ...
The 3 core parts of an use-case: use-case's name, use-case's participants & use-case's description. But depend on the specific organization, use-cases may be extended to contain more than just three core parts.
Below is an example of an use-case. As you can see in the description section, it is CUD.
CRUD by itself is not any use-cases at all.
Usually an use-case will perform none, one or many CRUD operations to be able to succeed in the result expected.
I'm fairly new to CRM 2013, and I've been reading and watching a lot of videos on the subject. I'm hoping someone on the interweb, can offer some tips or suggestions that will resonate with the way I interpret and comprehend this material.
I have a regular MS Access DB, with a few different tables that is used to store personnel records. From what I've learned so far CRM looks like a good candidate for moving away from Access and towards CRM.
My question is, what are some best practices when it comes to gathering requirements and expanding them for the CRM 2013 environment?
i.e. (for simplicity sake)
MS Access db has two tables.
Table A stores names of employees.
Table B stores the employee's favorite food.
Should each table have their own entity (Table_A 1:N, Table_B N:1), or are there times when you should combine multiple tables under a single entity?
Is it considered bad form to just put everything under one entity?
If it is bad form, how do you determine when to split the information
into multiple entities?
Business processes seem to remind me of SharePoint workflows. When should you rely on a BP?
I hope this makes sense, I'm still trying to make sense of it all. Any help is appreciated, thanks!
The Dynamics CRM is backed by a SQL Server, so think in terms of SQL tables and what's better. Splitting into smaller objects which have single responsibility is is better in most cases, but this might affect the performance on joining records. Honestly, we are moving away from CRM in cloud because it's not scaleable, not reliable (if it goes down you need to wait when it goes up - no second replica), no control over underlying SQL data or SQL Server instance size (DTUs), hard to test, and is just painful for a big project. And we are going to replace all Business Processes with code, because they are not testable as well - you cannot write unit tests.
Although #sergeSemenov has some good points, you have to start what CRM was is. CRM is a Customer Relationship Management suite, built on top of Xrm, a RADP, Rapid Application Development Platform.
Xrm is not designed to be the most flexible, most performant platform in the world. If speed of use and the ability to use any specific technology/sever topology to meet your demand is a requirement for your app, don't start with XRM.
If speed of development, speed to market, reduced costs by having non developers doing work that in the custom app dev world are required by developers, or even a desire to be in the cloud on day 1, are more highly valued, then Xrm, and consequently CRM is a great place to start.
As far as your questions, it all depends. The more normalized your data is, multiple entities for each relationship, the less work involved in ensuring they are all in sync, but usually the more difficult it is for your end users to work with the information. They'll have to navigate to multiple forms for data entry, and have lots of joins to configure in reports.
I generally try to keep the data as normalized as possible, but if anything is a 1:1 relationship, combine that into single entity. Or you know it's going to be a 1:2 or 1:3 relationship (See addresses on contacts and accounts for example)
Basically, it is an answer that requires a unique look at the application requirements, and personal experience. I would highly recommend seeking a consultant with CRM experience. Another advantage of a platform, is that there is a whole resource pool of developers, and BAs that already know the framework, and can provide value to the business on day one, rather than taking 2 or 3 weeks getting up to speed on your specific architecture.
Good luck!