Multiple roles performing a single task - bpmn

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.

Related

How can a Use Case diagram be presented when an actor has two different scenarios?(the exact same actor)

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.

OOP - CRUD or Use-Cases?

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.

How do I create a task shared by different pools in Bonita Studio?

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.

Database design: Multiple non-identifying relationships between two tables

I'm new to database design and have some uncertainties about how best to model this particular case. I'd appreciate any suggestions for this fairly simple scenario.
When a production task begins, two people are involved at all times. One is in charge of the production, and a second is tasked with quality assurance. For any task in the database, it must be possible to identify these two people. They'll both exist in a Person table and have IDs, so I just want the best way to relate them to the production task. The following rules exist:
Either person may be swapped out for a different person at any time.
Each task always involves both people (Neither of these are null).
There are never any other people involved in the task that we want to record.
Each person may be involved in multiple tasks, or none at all.
If we had a whole host of relationships between the task and the people, I'd create some sort of convoluted relationship structure describing their relationship (As producer, quality assurance person, overseer, etc.), but here I feel as though it's sensible to just stick the IDs of the two people in the Task table, in separate columns for Production Person and Quality Assurance Person. Is this bad for some reason that I can't see?
What has really prompted my question is that I'm trying to design exactly that in DBDesigner 4, which I'm new to, and it just doesn't like it - When I try to set up a second non-identifying relationship between Task and Person, it won't give me a second field. It also won't seem to let me rename the fields in Task that refer to the persons, so it'd be impossible to differentiate between the two anyway. Since no-one else seems to share this problem, I've began to wonder whether it's a good idea at all. Is it standard to introduce additional tables as soon as there are two or more links between two entities? What would that look like if I wanted to enforce the above rules? I can't see how I'd ensure that an n:m table always has entries for both people working on the task.
If you are confident your requirements will stay this rigid forever, then just create two NOT NULL FKs:
This declaratively enforces that exactly two people are associated to the task at all times, which would not be readily achievable with just the junction table (as you already noted).
OTOH, if you anticipate your requirements might change at some point in the future, then the added flexibility of junction table might be more important than the completely declarative enforcement of your business rules.
I'm not familiar with DBDesigner, and therefore with your particular problem, but in ER modeling in general, multiple relationships with the same entity are distinguished by their "rolenames" which determine the names of migrated attributes (see the section on "Rolenames" in the chapter 3 of the ERwin Methods Guide). Try locating something along those lines in the UI of your tool.
If you want to know the current state and not who held the role previously #Branko Dimitrijevic's solution will work.
But if the statement 'Either person may be swapped out for a different person at any time' implies you need to know who previously held that role consider a 3 table design
Task; TaskID, <other details>
Assignee; TaskID, PeopleID, role, start_date, end_date
People; PeopleID, <other details>
Then in the assignee table you need constraints to ensure that for each TaskID, Role combination the dates are reasonable e.g. dates don't overlap or have gaps. That you have only 1 of each role active for each task at a time. To manage this would probably require code either in triggers or the application.

Link between use case and functional requirement

I have a list of functional requirements
FR nr 1
FR nr 2
...
And have a list of use cases that describe the requirement from the actors point of view. I mean use case nr 1 describe FR nr 1 and so on.. But do I need to create a link in the use case to the FR? Problem is that FR and use cases are located in different pages in Wiki.
Use-cases are derived from functional requirements. It's not necessary to have a 1-1 correlation between a requirement and a use-case; actually in most situations a single use-case will be based on several requirements and a requirement may appear in several use-cases. The reason for this is that a use-case doesn't describe just any activity in the system but a high-level activity triggered by an external source. On the other hand, functional requirement usually describes internal or partial activity and yields a functional block inside use-case.
It's not necessary but it can be nice from documentation perspective to have links from use-cases to relevant requirements.
While not strictly necessary given the ease of doing this with a wiki I would say yes you should just do it. It will enhance traceability. On the usecase diagram I would include an attached note with the FR reference and in the usecase document use the identifier.