I'm modelling an ontology about Pokèmon using Protègè 5.5.0 and it's reasoner Hermit (Pellet doesn't work and makes the program crash). I created some rules about pokemon types' effectiveness.
I first created a rules stating that, for example, a pokèmon of grasstype can use moves of grasstype and now I want to create a rule stating that a pokemon of ONLY one type (so, excluding those pokemon having, for example, both grass and poison types as Bulbasaur) has the same effectiveness of the moves it can use.
E.G, If water moves are supereffective against fire moves, than a water pokemon is superffective against a fire pokemon.
I created this rule: SuperEffective(?x,?y), hasType(?z,?y) -> SuperEffective(?z,?y) and the only problem is that it selects also the pokemon with two types. What is the syntax to insert this kind of restriction/exclusion from the rule? Thank you.
Related
I am trying to model a situation in which a customer is added by either sales or an administrative assistent. They both have their own lane. I think using an OR or a 'AND' (paralel) gate would not really accurately reflect the situation.
How would you model this?
It would be great if there was an optional (either or) parallel gate but I don;t know if that exists.
I assume that you mean, whoever comes first will work on this activity. Therefore, a gateway cannot be the solution. It would need to have a condition, that is evaluated before one of the two activities get enabled.
This is what I would do: Create a new lane "customer admin" and specify somewhere else, that sales and adminstrative assistants are "customer admins".
If you duplicate "add customer" to show it in both lanes, you also have to model how one activity gets revoked, as soon as the other role starts working on it. If you want to model this, it gets really complicated. Of course, maybe a simple note could be sufficient, but I guess you are looking for a solution in BPMN.
If this activity would be the first in a process with empty start event, there is a simpler solution: Just use two empty start events and let the starter of the process decide, which one is to be used.
I am new in doing an activity and currently, I am trying to draw one based on given description.
I enter into doubt on a particular section as I am unsure if it should be 'split'.
Under the "Employee", the given description is as follows:
Employee enter in details about physical damage and cleanliness on the
machine. For the cleanliness, there must be a statement to indicate
that the problem is no longer an issue.
As such, I use a foreach as a means to describe that there should be 2 checks - physical and cleanliness (see diagram in the link), before it moves on to the next activity under the System - for the system to record the checks.
Thus, am I on the right track? Thank you in advance for any replies.
Your example is no valid UML. In order to make it proper you need to enclose the fork/join in a expansion region like so:
A fork/join does not accept any sematic labels. They just split the control flow into several parallel ones which join at the end.
However, this still seems odd since you would probably have some control for the different inspections being entered. So I'd guess there's a decision which loops through multiple inspection entries. Personally I use regions only for handling interrupts. ADs are nice to a certain level. But sometimes a tabular text (like suggested by Cockburn) is just easier to write and read. Graphical programming is not the ultimate answer (unlike 42).
First, the 'NO' branch of the decision node must lead somewhere (at the end?).
After, It differs if you want to show the process for ONE or MULTIPLE inspections. But the most logical way is to represent the diagram for an inspection, because you wrote inspection without S ! If you want represent more than one inspection, you can use decision and merge node to represent loop that stop when there is no more inspection.
if CrewType is chosen on JobPlan, Maximo's default behaviour is to explicitly set Quantity to 1 and make it read-only. I have changed that behaviour in JOBLABOR, and now I can edit the Quantity on JobPlan. (This has been done via an attribute launch point automation script on JOBLABOR.AMCREWTYPE).
However, when the JobPlan is applied to a WO, it still explicitly sets the QUANTITY for CrewType as 1 on WPLABOR, thus not carrying across the quantity from JOBLABOR. Where can i override that behaviour? Could this be done via an automation script for the run action of JPNUM field?
As to why the quantity field defaults back to 1 and is made read-only if Crew Type or Crew are selected, I would expect that's because conceptually, it doesn't make sense to have a quantity other than one for these types of job plan labour. The same is true of assigning labour records to a Job Plan because it doesn't make sense to assign a quantity greater than one of the same person's labour record. In fact the only type of job plan labour you're able to adjust the quantity for in Maximo out of the box is craft because you could justifiably require multiples of a particular craft (e.g. 3 electricians) assigned to the job plan.
A crew type is a template for a crew which is itself the labour (internal or otherwise) with particular crafts, skill levels and qualifications to perform the work. Since each Crew is distinct and made up of group of individuals assigned to the positions in the crew I don't think it makes sense to say you want to assign 2 instances of the same crew, say Crew A, to a particular job plan. If, for example, two instances of the same type of team are required to perform the work you probably need to define two distinctly separate crews of the same crew type and add each crew (not Crew Type) to the Job Plan rather than customise the system to allow you to add a crew type with a quantity greater than 1.
Alternatively you could assign crafts to the job plan which you then have the option of specifying that the job plan requires, say 5 electricians, for example for 6 hours.
From Administration -> Organisations you can select an Organisation then click Crew Assignment Options to define how total work hours are calculated for Work Orders, Job Plans, Tasks and Activities associated with Crews.
I can see why you would want to plan for n crews of some type. For example, it takes a crew of a certain type to stand a pole for street lights, and if you've got a whole street to put lights on, why not have 5 of that crew type planned on this work order?
Unfortunately, it seems Maximo is pretty set against doing that. For what explanation it may yield, I recommend opening a Support Case with IBM, asking for the rationale or how to work around that limitation. And you could submit an RFE with rationale for why the limitation should not be there.
To satisfy the immediate need, maybe you could set up crew types as a service? Or create your own Quantity attributes for use with Crew Type and implement all the logic around those? I don't like reinventing the wheel, but "the juice might be worth the squeeze" if you're going to be fighting Maximo every step of the way, anyway. Or, if it really means that much to you, customize this aspect of Maximo to do what you want.
Whatever happens, I think your problem is not a programming problem but a Maximo problem. And as StackOverflow is a programming site, your problem is beyond the scope of this site. However, please come back if you have a programming problem! We love solving those!
Update
Having thought more about this, I think this is not a Maximo problem. I think Maximo is just (you could argue, forcibly) encouraging better planning. In the street light example, you wouldn't expect n crews to self-organize to stand poles. That would be poor planning. Rather, you would have a top level work order for doing the street with a lower level work order for each individual pole. So, each of those lower level work orders would only require 1 of the Crew Type. This arrangement would still flow through to scheduling as needing n of that Crew Type, but whether 1 Crew of that type was used n times or whether n crews were used once or somewhere in between is a scheduling problem, not a planning problem.
I want to sanity check myself on a view projection, in regards to if an intermediary concept can purely exist in the read model while providing a bridge between commands.
Let me use a contrived example to explain.
We place an order which raises an OrderPlaced event. The workflow then involves generating a picking slip, which is used to prepare a shipment.
A picking slip can be generated from an order (or group of orders) without any additional information being supplied from any external source or user. Is it acceptable then that the picking slip can be represented purely as a read model?
So:
PlaceOrderCommand -> OrderPlacedEvent
OrderPlacedEvent -> PickingSlipView
The warehouse manager can then view a picking slip, select the lines they would like to ship, and then perform a PrepareShipment command. A ShipmentPrepared event will then update the original order, and remove the relevant lines from the PickingSlipView.
I know it's a toy example, but I have a conceptually similar use case where a colleague believes the PickingSlip should be a domain entity/aggregate in its own right, as it's conceptually different to order. So you have PlaceOrder, GeneratePickingSlip, and PrepareShipment commands.
The GeneratePickingSlip command however simply takes an order number (identifier), transforms the order data into a picking slip entity, and persists the entity. You can't modify or remove a picking slip or perform any action on it, apart from using it to prepare a shipment.
This feels like introducing unnecessary overhead on the write model, for what is ultimately just a transformation of existing information to enable another command.
So (and without delving deeply into the problem space of warehouses and shipping)...
Is what I'm proposing a legitimate use case for a read model?
Acting as an intermediary between two commands, via transformation of some data into a different view. Or, as my colleague proposes, should every concept be represented in the write model in all cases?
I feel my approach is simpler, and avoiding unneeded complexity, but I'm new to CQRS and so perhaps missing something.
Edit - Alternative Example
Providing another example to explore:
We have a book of record for categories, where each record is information about products and their location. The book of record is populated by an external system, and contains SKU numbers, mapped to available locations:
Book of Record (Electronics)
SKU# Location1 Location2 Location3 ... Location 10
XXXX Introduce Remove Introduce ... N/A
YYYY N/A Introduce Introduce ... Remove
Each book of record is an entity, and each line is a value object.
The book of record is used to generate different Tasks (which are grouped in a TaskPlan to be assigned to a person). The plan may only cover a subset of locations.
There are different types of Tasks: One TaskPlan is for the individual who is on a location to add or remove stock from shelves. Call this an AllocateStock task. Another type of Task exists for a regional supervisor managing multiple locations, to check that shelving is properly following store guidelines, say CheckDisplay task. For allocating stock, we are interested in both introduced and removed SKUs. For checking the displays, we're only interested in newly Introduced SKUs, etc.
We are exploring two options:
Option 1
The person creating the tasks has a View (read model) that allows them to select Book of Records. Say they select Electronics and Fashion. They then select one or more locations. They could then submit a command like:
GenerateCheckDisplayTasks(TaskPlanId, List<BookOfRecordId>, List<Locations>)
The commands would then orchestrate going through the records, filtering out locations we don't need, processing only the 'Introduced' items, and creating the corresponding CheckDisplayTasks for each SKU in the TaskPlan.
Option 2
The other option is to shift the filtering to the read model before generating the tasks.
When a book of record is added a view model for each type of task is maintained. The data might be transposed, and would only include relevant info. ie. the CheckDisplayScopeView might project the book of record to:
Category SKU Location
Electronics (BookOfRecordId) XXXX Location1
Electronics (BookOfRecordId) XXXX Location3
Electronics (BookOfRecordId) YYYY Location2
Electronics (BookOfRecordId) YYYY Location3
Fashion (BookOfRecordId) ... ... etc
When generating tasks, the view enables the user to select the category and locations they want to generate the tasks for. Perhaps they select the Electronics category and Location 1 and 3.
The command is now:
GenerateCheckDisplayTasks(TaskPlanId, List<BookOfRecordId, SKU, Location>)
Where the command now no longer is responsible for the logic needed to filter out the locations, the Removed and N/A items, etc.
So the command for the first option just submits the ID of the entity that is being converted to tasks, along with the filter options, and does all the work internally, likely utilizing domain services.
The second option offloads the filtering aspect to the view model, and now the command submits values that will generate the tasks.
Note: In terms of the guidance that Aggregates shouldn't appear out of thin air, the Task Plan aggregate will create the Tasks.
I'm trying to determine if option 2 is pushing too much responsibility onto the read model, or whether this filtering behavior is more applicable there.
Sorry, I attempted to use the PickingSlip example as I thought it would be a more recognizable problem space, but realize now that there are connotations that go along with the concept that may have muddied the waters.
The answer to your question, in my opinion, very much depends on how you design your domain, not how you implement CQRS. The way you present it, it seems that all these operations and aggregates are in the same Bounded Context but at first glance, I would think that there are 3 (naming is difficult!):
Order Management or Sales, where orders are placed
Warehouse Operations, where goods are packaged to be shipped
Shipments, where packages are put in trucks and leave
When an Order is Placed in Order Management, Warehouse reacts and starts the Packaging workflow. At this point, Warehouse should have all the data required to perform its logic, without needing the Order anymore.
The warehouse manager can then view a picking slip, select the lines they would like to ship, and then perform a PrepareShipment command.
To me, this clearly indicates the need for an aggregate that will ensure the invariants are respected. You cannot select items not present in the picking slip, you cannot select more items than the quantities specified, you cannot select items that have already been packaged in a previous package and so on.
A ShipmentPrepared event will then update the original order, and remove the relevant lines from the PickingSlipView.
I don't understand why you would modify the original order. Also, removing lines from a view is not a safe operation per se. You want to guarantee that concurrency doesn't cause a single item to be placed in multiple packages, for example. You guarantee that using an aggregate that contains all the items, generates the packaging instructions, and marks the items of each package safely and transactionally.
Acting as an intermediary between two commands
Aggregates execute the commands, they are not in between.
Viewing it from another angle, an indication that you need that aggregate is that the PrepareShippingCommand needs to create an aggregate (Shipping), and according to Udi Dahan, you should not create aggregate roots (out of thin air). Instead, other aggregate roots create them. So, it seems fair to say that there needs to be some aggregate, which ensures that the policies to create shippings are applied.
As a final note, domain design is difficult and you need to know the domain very well, so it is very likely that my proposed solution is not correct, but I hope the considerations I made on each step are helpful to you to come up with the right solution.
UPDATE after question update
I read a couple of times the updated question and updated several times my answer, but ended up every time with answers very specific to your example again and I'm most likely missing a lot of details to actually be helpful (I'd be happy to discuss it on another channel though). Therefore, I want to go back to the first sentence of your question to add an important comment that I missed:
an intermediary concept can purely exist in the read model, while providing a bridge between commands.
In my opinion, read models are disposable. They are not a single source of truth. They are a representation of the data to easily fulfil the current query needs. When these query needs change, old read models are deleted and new ones are created based on the data from the write models.
So, only based on this, I would recommend to not prepare a read model to facilitate your commands operations.
I think that your solution is here:
When a book of record is added a view model for each type of task is maintained. The data might be transposed, and would only include relevant info.
If I understand it correctly, what you should do here is not create view model, but create an Aggregate (or multiple). Then this aggregate can receive the commands, apply the business rules and mutate the state. So, instead of having a domain service reading data from "clever" read models and putting it all together, you have an aggregate which encapsulates the data it needs and the business logic.
I hope it makes sense. It's a broad topic and we could talk about it for hours probably.
I'm quite new to DDD so apologies if this is well writ but I have struggled to find an answer.
In our domain we have a representation of a 'Normal Shift', e.g. Afternoon: 15.00 - 18.00. It is possible however for shifts to be modified either on specific days of the week (Mon - Sun) or for specific 'Locations'. The end result should be the same shift (Afternoon for example) but with a new time on a specific day / at a specific location.
How should we model these updated shifts? So far we've come to.
A common 'Shift' object which can be applied as a Normal Shift and also associated to a day or location.
A model to denote the change 'Shift Adjustment'.
Unique models for each shift, with some kind of relationship so they can be applied. E.g. 'Location Shift'.
We keep toggling between 1 & 3. 1 seems like a more natural language fit yet 3 feels more complete in that the business logic isn't hiding real facets of the model.
Any help would be greatly appreciated!
First, I think this initially has nothing to do with DDD. Rather it is about how you represent these concepts in your domain model.
You don't state explicitly the behavior you require. So, I'm guessing you may want to be able to send a message to an appropriate object in your model to get you a shift ... FindShift(name,[day,location]). FindShift would return either a default shift, or a custom one if it exists. Providing the day and location might be optional.
One simple way to represent this is as follows:-
A Shift has an optional day and location. This solution requires a business rule (a constraint) preventing applicable duplicates.
There are other ways to model this, especially in regards to making "default" shifts explicit. But it's hard to do so if you don't state the behavior required, rather than just a structural description.