Given
I have the following BPMN process (collaboration), where three actors are involved. Two of them (Actor 1 and Actor 3) represent a single instance. While Actor 2 represents n instances (open the image in new tab to enlarge).
Background
The basic idea is that Actor 1 initiates a task, which should make ALL instances of Actor 2 create data and send it back to Actor 1. In the end Actor 1's activity collect results should collect all the data of all Actor 2 instances.
Question
My question is: Is this even possible and executable to model in one monolithic diagram (while the engine execution manages the instances part), or should I split this into two processes, using signal events?
In the literature, the multi-instance participant (here Actor 2) is usually marked with three vertical lines, but I am not sure, if the engine supports this.
Is there otherwise a better approach to model a 1 to n relation?
Note: I am still learning BPMN, tell me if I am totally in the wrong here. Thanks a lot.
Related
Hello I have the following situation:
I have a product instance table that is nothing more than a product already assigned to a department and employee.
Well, but I have the following business logic: the product can be an equipment, or a component, that is, a product can have children.
thinking how a computer case is a device that has patrimony_code, and has child products (components) such as:
motherboard,
memoirs,
vga
etc etc
and all of these components are connected to the equipment.
I arrived at this with less table:
But I encountered some problems:
my components would not need departament_id, as they do not belong to the department but to the equipment that there belongs to the department.
So I came to this modeling, but I don't know if it is a good thing to do this relationship, could someone help me if there is a more clean / solid solution for this?
if I have understood your description correctly, only a piece of equipment can be assigned directly to a department, not the individual components that make up the piece of equipment?
Assuming this is the case then I suggest you split this problem into 2 separate tasks as they are, in reality, unrelated and trying to treat them as a single model is causing confusion:
Model the relationship between an instance of a piece of equipment and a department
Model the hierarchy of components (and their instances) that make up a piece of equipment
Once you have these two models you can then relate them if you need to but logically they are separate and you can change one without affecting the other
Hope this helps?
UPDATE 1
(in response to your questions)
You construct 1 sub-model that covers your Equipment entity and the Component entity (plus any other relevant entities) that describe how your products are modelled.
Your construct a second sub-model that describes how equipment is assigned to a department.
The only entity that would be (necessarily) common to the 2 sub-models is the Equipment entity; though, obviously, you can display both sub-models on the same diagram if that is required - even though they are logically separate (apart from the one common entity: Equipment)
I am about to create a database to track weight-lifting exercises.
Which approach would you prefer?
Solution A:
Two tables
Exercise (with ID, Name etc.)
Set (with ID, Set_Number, Date, FK_Exercise)
Here, one Exercise and Set have a one-to-many relationship.
Set_Number is supposed to track which set it is on a given date (1st set, 2nd set, 3rd set etc.)
Advantage: One table less to deal with.
Solution B:
Three tables:
Exercise (with ID, Name etc.)
Session (with ID, Date, FK_Exercise)
Set (with ID, Set_Number, FK_Session)
Here, a Session would be something like a connector between Exercise and Set. So basically a sequence of sets on a given day for a given exercise will be pooled in one Session instance.
In this case, Exercise and Session have a one-to-many relationship and Session and Set also have a one-to-many relationship.
Advantage: The Date property will not be redundant for any given day. And logically it makes sense to bundle sets.
A good data model falls out of a proper understanding of the domain. Your domain has three entities:
EXERCISE: particular type of weightlifting move (name and weight)
SET: number of reps of a given EXERCISE (depending on training goal - strength, muscle, endurance?)
SESSION: number of SETs undertaken on a given date
So you need at least three tables. At least, because EXERCISE has two levels of detail: one is the exercise name and the other is the exercise weight . It's quite likely you will need to store SETs of different combination of names and weights (Bicep curl / 10kg, Bicep curl / 15kg, etc) in which case you need a look-up table EXERCISE name and a fourth table SET_EXERCISE to store the weight used for a particular SET of reps.
Having gone through this exercise (o ho!) we can see that your foreign keys are wrong. A SESSION comprises a number of SETs; a SET comprises a number of EXERCISEs (SET_EXERCISEs).
Hence the logical data model should look something like:
EXERCISE (ID, Name, Weight, etc)
SET (ID, FK_Exercise, Reps, etc)
SESSION (ID, FK_Set, Date, etc)
Although this is not quite accurate: SET:SESSION is in fact a many-to- many relationship, as a SESSION will normally comprise more than one SET and a SET can be done in more than one SESSION.
When it comes to a physical data model i.e. tables you should have five tables:
EXERCISE (ID, Name, etc)
SET_EXERCISE (ID, FK_Exercise, FK_Set, Weight, etc)
SET (ID, FK_Set_Exercise, Reps, etc)
SESSION_SET (FK_Set, FK_Session, Set_Number, etc)
SESSION (ID, Date, etc)
The SESSION_SET table is necessary to resolve the many-to-many relationship between SET and SESSION .
The final model has five tables: three tables for the original entities and two intersection tables which join those entities. It so happens that all the relations between the logical entities (EXERCISE, SET, SESSION) have been implemented as intersection tables rather than foreign keys. This doesn't always happen when transforming from a Logical to a Physical data model.
This is not the only way of modelling the domain. As a design activity data modelling is about interpreting the rules to fit the data you need to record. The data is the starting point.
"it seems I didn't make myself clear regarding the Session entity...he naming is probably bad and misleading"
This is why I said the data model follows from a proper understanding of the domain. EXERCISE, SET and SESSION are domain terms. You are of course welcome to make your own definitions of things for your private projects, but in real life data models are a mechanism for communication between Development and Business: the meaning of things is crucial, and must conform to a common understanding. We cannot build a data model where SESSION means something different from what the business understands by "session".
"I also don't understand how a Set can be done in more than one Session?"
A SET is a pattern of EXERCISE for a number of reps. So #1 / benchpress / 130KG / 8 reps is a SET and #2 / benchpress / 100KG / 12 reps is a different SET. If you benchpressed 130KG eight times on Monday and Wednesday then that's the same SET in two different SESSIONs. Maybe it's a layer of detail too far; but if you're going to build a database app to track your workouts instead of using a spreadsheet like most people you might as well build the best data model you can :-)
Again, data modelling is an exercise with a large dose of opinion: if your data model is good enough for your current needs then it is good enough. The thing is, a more rigorous data model is paradoxically more flexible (because enforcing data integrity rules makes it easier to write queries and be sure that the results are correct). What might be good enough now might be a terrible brake on innovation in the future.
we are using Optaplanner 7.0 beta + Graphhopper for a calculation of shortest paths in a warehouse, where goods have to be collected into boxes by workers (vrptw). Since the business is about collecting online-ordered goods approx. 70% of the items to collect are added to the problem during the day. We use ProblemFactChange to add the incoming order items and already completed order items in the chain are set to immovable (these 'restarts' are performed each full hour). So far everything works.
The question now is about changing restrictions/conditions, that can occur due to unbalanced workload over warehouse-zones. The warehouse is logically divided into areas, to avoid that all workers have to serve all areas (I know your opinion about segmentation of planning problems, but this is, how the work currently is organised). The limited assignment of items to available workers within one zone is currently defined by a hard-constraint.
The new requirement that we are confronted with is, that a worker should be temporary assigned to a different zone, if the workload there is higher compared to his actual zone. Afterwards he can switch back to his original zone. To my understanding an update of the constraint condition would result in hard constraint violations for the previous assigned, locked items, which should be avoided. Are there mechanisms to support temporary changing restrictions or would a SelectionFilter for items help ? (btw: we are using drools).
Hints are welcome, Thank you
Michael
If there are 2 different tenants, each with their own set of employees, tasks, etc and each in their own Solver, then the Borrow Pattern can be used, especially if the employee borrowing involves some human interaction (usually paperwork or a phone call between managers):
Suppose tenant A has an employee called John and tenant B wants to borrow him. Then assign one or more entities from B to John and make them immovable (usually a boolean borrowLocked). Then add the same entities to tenant A. Neither the solver of A nor B will be able to move them (so they won't change), but both of them will take them into account: tenant A won't give John work when he's working for tenant B and tenant B will agree that those entities are assigned (and it won't try to assign John to other entities as it's no in it's value range).
I am new to object oriented design. I am looking forward to some tips on how to model the below mentioned requirement using objects.
Requirement: A program has many Students. A program logs in to the application. First page displays a table of all the Students belonging to the program (Table Columns - Id, First name, last name, age, sex, etc. ). The Id is a link. By clicking the Id, the individual student page is displayed. In this page, an individual student related activities can be done - for eg. edit address, change name, add comments etc.
My Solution: Two Classes
Program - Will model a single program, perform all activities related to it and encapsulate all program related db tables.
Student - Will model a single student and perform all activities related to it and encapsulate all student specific db tables.
So far, so good.
In order to fetch details of all students related to a program, from Program object I need to call a method called 'fetch_student_details'.
The Question is where should this method be written? Should it be a Student Class method or Program Class method.
If I write this method in program class, how will the Program class handle it?
(a) First identify the list of student_ids that belong to it and for each id, instantiate a Student Class and get the specific student related information from it. DB: Each instantiated student object will run a query to fetch its information. So 100 students, 100 queries.
OR
(b) Fetch the list of student ids related to the program and fetch the student information directly for all the students. Db: Single query to fetch all the needed information.
In this case, if you can, go for solution (b). Students and Programs, in fact, are two differet entities that can exist independently, and you don't break encapsulation.
With solution (a) you need to pollute Program's interface by adding a method for each possible information that you want to get from the Students.
As final suggestion, if you want to learn OO Design, start by reading the book "Design patterns - Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (AKA "The gang of four").
I have some confusion with applying Larman's system operation contracts (OO Analysis from book Applying UML and Patterns) on CRUD-like operations. More precisely, I'm confused with postcondition part.
For example, if I have CRUD system operations looking as follows:
createEmployee(employee:Employee),
readEmployee(employeeId:int),
updateEmployee(employee:Employee),
deleteEmployee(employeeId:int)
what would be postcondition on, for example, readEmployee system operation, or some other operation like searchEmployees etc?
For example: for read operation, system needs to read record from database, instantiate domain object, set attribute values on domain object (set relations also) and that's it. Does it means that postconditions are above mentioned - instance creation, changes on attributes, etc. Or, read operation does not have any postcondition. None of this does sound logical to me.
My confusion is about relation between domain model (state) and database (state). I just don't get implications which above operations will have on domain model. I always think in way that the database is a place that preserves the state of the system. After I create employee, its object's state will be persisted in database... But what happens with domain model state?
The post-condition defines what the state of your application (or object, depending on the level of abstraction) should be after the operation for it to be considered as successful. For the readEmployee operation, for example, the post-condition would be that:
a new Employee instance is created.
the Employee instance contains attributes matching the database values.
the database connection is closed.
I like to think of "pre-condition" and "post-condition" as the "state of mind" of your application before and after an operation has executed, respectively. As you can imagine, it's more a thought process than a coding exercise when you do DbC.
(If you do unit-testing, states make it clear what needs to be covered by your tests. Basically, you end up testing the "state of mind" of your application.)
Interestingly, if you consider the reverse of DbC, you realise that to identify what operations your application (or object) should expose, it is simply a matter of listing what states it can have and how it transitions between these states. The actions that you need to take to make these transitions then become your operations, and you do not have to bother with implementing operations that do not lead to any desired states. So, for example, you probably want the following states for your application.
Employee details added (S1)
Employee details loaded (S2)
Employee details updated (S3)
Employee details deleted (S4)
The following state transitions are possible.
S1 -> S3 (add new employee, update the details)
S1 -> S4 (add new employee, delete the employee)
S2 -> S3 (load employee details, update employee details)
S2 -> S4 (load employee details, delete employee)
S4 -> S1 (delete employee, add new employee)
S2 -> S1 (load employee details, add new employee)
S3 -> S1 (update employee details, add new employee)
S3 -> S2 (update employee details, load employee details)
Based on the above, you can write your operations in such a way that only valid transitions are allowed, with anything else giving rise to errors.
Impossible state transitions:
S4 -> S2 (cannot delete an employee, then load their details)
S4 -> S3 (cannot delete an employee, then update their details)
State modeling is probably the most important part of designing objects, so you're asking the right questions. If you want a good resource on state modeling, get Object Lifecycles Modeling the World in States from Sally Shlaer / Stephen Mellor. It is quite an old book and costs almost nothing on Amazon, but the principles it introduces form the basis of modern UML -- incidentally, the notation used in the book looks nothing like UML.
I realise I did not touch on database state, but at the conceptual level, the database layer is just another system of states and the same principles apply.
I hope this was useful.
My interpretation of Larman's contracts is always with respect to the domain model. Larman clearly states there are only 5 types of post conditions:
Instance creation
Instance deletion
Attribute change of value.
Associations formed.
Associations broken.
Therefore, a Read (or search) operation would have no post conditions, at least not on the elements that are being read or searched. For example, if 10,000 users performed reads/searches in one day, but never did any of the other operations (C, U, D), there would be no change to the objects in the domain.
There is an exception to this, however, in domains where searches/reads are remembered. For example, Google surely keeps track of searches. In this case, doing a search has the postcondition of creating a new object in their domain model, e.g., A Search instance s was created (instance creation).
The confusing comes form mentioning data model relation within the contract template that Larman provided as in :
Contract CO2: enterItem
Operation: enterItem(itemID : ItemID, quantity : integer)
...
sli was associated with a ProductSpecification, based on itemID match (association formed).
The detail referential properties of the database should not be mentioned in the operation contract. It is better to leave it as: "sli was associated with a ProductSpecification".
In fact, it is one of the things that Larman's operation contracts does not talk about in much detail. Think about a contract for an operation that calculates a total number of items and return the total ! seems that it cannot be written as an operation contract.