I have the following problem to resolv. Given the following UML diagram:
I need to complete the diagram doing the following steps:
a) When an employee has a skill, the relationship between the employee and the skill shows years of experience.
b) A worker may have another employee as a manager and a worker who is a manager must manage five or more workers. As a manager, you can determine which workers he manages, but a worker can not determine who is his manager.
c) An activity can have a maximum activity precedent and any number of upcoming activities. Using these roles, we can show how the activities are arranged. Given an activity, you can only determine their own activities (if you have), but not what your previous activity (if any).
d) A worker is not simply associated with a set of skills, but a worker has skills. In particular, every worker should have three or more skills, and any number of employees can have the same ability.
e) A project is not simply a set of activities associated with, but contains a project activities. Specifically, a project must have one or more activities, and activity must belong to exactly one project.
f) Projects and activities are a specific type of job.
My solution is shown in the following picture, but because I am new in this I would like to check if is fine.
Thank you in advance!
Looks good in most parts. Honestly I don't understand the later parts of c)
Your -boss relation is wrong. Your Northern Koreans should not have a private known boss. Instead there's only the other way around and the boss has - let's call them - -slaves. If you put in a private -boss it actually means that the slave can navigate to its private boss which is explicitly not wanted. Only the boss shall know the one he's responsible for. So actually the object itself is the boss object. As a thought, since only the boss should have those 5 employees, it could be an idea to create a separate boss object like this:
Note that this might also have drawbacks since Boss is now actually a different object than Employee, but it seems to fit the requirements.
Point f) seems to call for a generalization. So you would need a generalization towards SpecificJob. This would be an arrow with open triangle, not the one you used:
This actually reads Project and Activity are specific kinds of Job as they both inherit from the latter.
Related
In CQRS when we need to create a custom-tailored projections for our read-models, we usually prefer a "denormalized" projections (assume we are talking about projecting onto a DB). It is not uncommon to have the information need by the application/UI come from different aggregates (possibly from different BCs).
Imagine we need a projected table to contain customer's information together with her full address and that Customer and Address are different aggregates in our system (possibly in different BCs). Meaning that, addresses are generated and maintained independently of customers. Or, in other words, when a new customer is created, there is no guarantee that there will be an AddressCreatedEvent subsequently produced by the system, this event may have already been processed prior to the creation of the customer. All we have at the time of CreateCustomerCommand is an UUID of an existing address.
We have several solutions here.
Enrich CreateCustomerCommand and the subsequent CustomerCreatedEvent to contain full address of the customer (looking up this information on the fly from the UI or the controller). This way the projection handler will just update the table directly upon receiving CustomerCreatedEvent.
Use the addrUuid provided in CustomerCreatedEvent to perform an ad-hoc query in the projection handler to get the missing part of the address information before updating the table.
These are commonly discussed solution to this problem. However, as noted by many others, there are problems with each approach. Enriching events can be difficult to justify as well described by Enrico Massone in this question, for example. Querying other views/projections (kind of JOINs) will work but introduces coupling (see the same link).
I would like describe another method here, which, as I believe, nicely addresses these concerns. I apologize beforehand for not giving a proper credit if this is a known technique. Sincerely, I have not seen it described elsewhere (at least not as explicitly).
"A picture speaks a thousand words", as they say:
The idea is that :
We keep CreateCustomerCommand and CustomerCreatedEvent simple with only addrUuid attribute (no enriching).
In API controller we send two commands to the command handler (aggregates): the first one, as usual, - CreateCustomerCommand to create customer and project customer information together with addrUuid to the table leaving other columns (full address, etc.) empty for time being. (Warning: See the update, we may have concurrency issue here and need to issue the probe command from a Saga.)
Right after this, and after we have obtained custUuid of the newly created customer, we issue a special ProbeAddrressCommand to Address aggregate triggering an AddressProbedEvent which will encapsulate the full state of the address together with the special attribute probeInitiatorUuid which is, of course our custUuid from the previous command.
The projection handler will then act upon AddressProbedEvent by simply filling in the missing pieces of the information in the table looking up the required row by matching the provided probeInitiatorUuid (i.e. custUuid) and addrUuid.
So we have two phases: create Customer and probe for the related Address. They are depicted in the diagram with (1) and (2) correspondingly.
Obviously, we can send as many such "probe" commands (in parallel) as needed by our projection: ProbeBillingCommand, ProbePreferencesCommand, etc. effectively populating or "filling in" the denormalized projection with missing data from each handled "probe" event.
The advantages of this method is that we keep the commands/events in the first phase simple (only UUIDs to other aggregates) all the while avoiding synchronous coupling (joining) of the projections. The whole approach has a nice EDA feeling about it.
My question is then: is this a known technique? Seems like I have not seen this... And what can go wrong with this approach?
I would be more then happy to update this question with any references to other sources which describe this method.
UPDATE 1:
There is one significant flaw with this approach that I can see already: command ProbeAddrressCommand cannot be issued before the projection handler had a chance to process CustomerCreatedEvent. But this is impossible to know from the API gateway (or controller).
The solution would probably involve a Saga, say CustomerAddressJoinProjectionSaga with will start upon receiving CustomerCreatedEvent and which will only then issue ProbeAddrressCommand. The Saga will end upon registering AddressProbedEvent. Or, if many other aggregates are involved in probing, when all such events have been received.
So here is the updated diagram.
UPDATE 2:
As noted by Levi Ramsey (see answer below) my example is rather convoluted with respect to the choice of aggregates. Indeed, Customer and Address are often conceptualized as belonging together (same Aggregate Root). So it is a better illustration of the problem to think of something like Student and Course instead, assuming for the sake of simplicity that there is a straightforward relation between the two: a student is taking a course. This way it is more obvious that Student and Course are independent aggregates (students and courses can be created and maintained at different times and different places in the system).
But the question still remains: how can we obtain a projection containing the full information about a student (full name, etc.) and the courses she is registered for (title, credits, the instructor's full name, prerequisites, etc.) all in the same table, if the UI requires it ?
A couple of thoughts:
I question why address needs to be a separate aggregate much less in a different bounded context, in view of the requirement that customers have an address. If in some other bounded context customer addresses are meaningful (e.g. you want to know "which addresses have more customers" etc.), then that context can subscribe to the events from the customer service.
As an alternative, if there's a particularly strong reason to model addresses separately from customers, why not have the read side prospectively listen for events from the address aggregate and store the latest address for a given address UUID in case there's a customer who ends up with that address. The reliability per unit effort of that approach is likely to be somewhat greater, I would expect.
Say, I have System1 that connect to System 2 through the adapter-microservice between them.
System1 -> rest-calls --> Adapter (converts request-response + some extra logic, like validation) -> System2
System1 is more like a monolith, exists for many countries (but it may change).
Question is: From the perspective of MicroService architecture and deployment, should the Adapter be one per country. Say Adapter-Uk, Adappter-AU, etc. Or it should be just the Adapter that could handle many countries at the same time?
I mean:
To have a single system/adapter-service :
Advantage: is having one code-base in or place, the adaptive code-logic between countries in 90 % are the same. Easy to introduce new changes.
Disadvantage: once we deploy the system, and there is a bug, it could affect many countries at the same time. Not safe.
To have a separate system:
Disadvantage: once some generic change has been introduced to one system, then it should be "copy-pasted" for all other countries/services. Repetitive, not smart.. work, from developer point of view.
Advantage:
Safer to change/deploy.
Q: what is a preferable way from the point of view of microservice architecture?
I would suggest the following:
the adapter covers all countries in order to maintain single codebase and improve code reusability
unit and/or integration tests to cope with the bugs
spawn multiple identical instances of the adapter with load balancer in front
Since Prabhat Mishra asked in the comment.
After two years.. (took some time to understand what I have asked.)
Back then, for me was quite critical to have a resilient system, i.e. if I change a code in one adapter I did not want all my countries to go down (it is SAP enterprise system, millions clients). I wanted only once country to go down (still million clients, but fewer millions :)).
So, for this case: i would create many adapters one per country, BUT, I would use some code-generated common solution to create them, like common jar - so I would would not repeat my infrastructure or communication layers. Like scaffolding thing.
country-adapter new "country-1"
add some country specific code (not changing any generated one (less code to repeat, less to support))
Otherwise, if you feel safe (like code reviewing your change, making sure you do not change other countries code), then 1 adapter is Ok.
Another solution, is to start with 1 adapter, and split to more if it is critical (feeling not safe about the potential damage / cost if fails).
In general, seems, all boils down to the same problem, which is: WHEN to split "monolith" to pieces. The answer is always: when it causes problems to be as big as it is. But, if you know your system well, you know in advance that WHEN is now (or not).
Let's say I have a collaboration diagram that models a process named CheckMessage which is quite complex and spans over few lanes and pools. Now I would like to model another process, e.g. CreateMessage which would make use of the previous process to check first if message doesn't exist already or if all its fields are valid, etc.
The thing is, that both processes make use of the same swimlanes and pools. What is the proper way to model such interactions? I was thinking to model CheckMessage as a sub-process of CreateMessage, however sub-processes can't be attached to pools or lanes - if I understand it correctly they just stay within a lane of activity which invoked them. Can a Call Activity encapsulate such beahviour (cross pools and lanes)? Or can I somehow reference the CheckMessage diagram as a whole?
Thanks in advance.
I could think of the following approaches:
Using Diagram Reference: This is used quite often when you want to switch easily to the more complex part. The disadvantage is that, unlike Fragments in SDs, you do not have ways to really connect flows in and out of referenced diagrams.
Repeating parts of the process: here you just pick those actions from the complex process which ought to interact with the other process. You can highlight that by putting a boundary around these and adding a diagram reference as described above.
Call Activity: This is another valid way. Here you have an activity which you instantiate as action. The advantage here is that you can add pins for input and output parameters.
I guess there is no silver bullet and you have to choose what is appropriate in each case.
Edit Regarding #3 it looks like that:
(this is an example and not to be used in practice)
The Action to the right is an instance of the Activity as you can see by Ctrl-L (show parent).
At my company we are currently using optaplanner to solve a vehicle routing problem with great results, we built a web app to manage vehicles, clientes, locations, depots and to show a graphic representation of the solution (including showing the locations in a map). We wrapped the solver in a spring java app with a rest interface to receive request and solve the problem. We are using Google maps to get distance-time data. Now we need to implement multirip....
To tackle the multitrip part I am following this approach:
1.- I added readyTime, endOfTrip and dueTime members to Vehicle class
2.- I created a rule to prevent arrivals at customers after vehicle->dueTime
3.- I modified the ArrivalTimeUpdateListener to consider the vehicle->readyTime when calculating the departureTime from a vehicle (using Math.max(depot->readyTime, vehicle->readyTime)
4.- At this point I started using the vehicle class as if it were a vehicle trip instead of a vehicle (I still don´t change the name but that is the idea )
5.- I created a member nextVehicle in vehicle to represent the next trip
6.- For testing purposes I manually link two vehicles (or vehicle trips) before sending it to solver->solve
7.- In the ArrivalTimeUpdatingVariableListener class I extended the method that updates the arrival times to consider updating the nextVehicle->readyTime and by consequence the arrival times of the customers that belong to the next trip (and so on when there are more than two trips)
I am sure this is not the most elegant solution, but I tried other approaches (using custom shadow variable on Vehicle for instance) but it couldn´t make it work.
The problem I am facing right now is that I don´t get to understand the state of the model when ArrivalTimeUpdatingVariableListener is called, maybe someone faced similar problem and can help me. What i found (after try and error) is:
the customer.getVehice() method not always returns a value (distinct from null value), it seems to get updated some time after the previousStandstill change triggers the listener "updateArrivalTime" method.
In construction fase when a customer get assign to a vehicle the customer.getVehice() method returns null (it came from "not assigned")
In construction fase when a customer "is freed" the customer.getVehice() method returns the "previous vehicle"
In local search fase when a customer get assign to a vehicle the customer.getVehice() method returns the "previous vehicle" (original vehicle)
In local search fase when a customer go back to the original vehicle the customer.getVehice() method returns the "previous assign vehicle"
Any thoughts on this? Am I making right assumptions? (because originally I considered customer.getVehicle() as the "actual" vehicle and the solutions were completely wrong...)
The order of triggering the previousStandstill change it´s kind of difficult to understand (for me). I mean when moving customers or swapping them between vehicles...any thoughts or hints on were to find info?
Can I access some variables from the "previous state of the model" when the solver makes a move?, because I am thinking I will need that if I continue with this approach (to update the vehicle->endOfTrip that is the nextVehicle->readyTime when the customer is the last one on the chain for instance)
and finally...am i doing something completely wrong conceptually ?
Any comments will be greatly appreciated (and sorry my grammar, I am native spanish speaker)
The chaotic triggering of shadow vars that you describe should not happen any more in optaplanner 6.3.0.Final or higher because it now gives the guarantee shown below.
But older versions (optaplanner 6.2 and earlier) suffer from that chaotic trigger behaviour (as fixed by PLANNER-252 - yes I know that issue number by heart - and yes, I am not the only one) could drive a developer (who's working on a complex model with multiple shadow variable(s)) insane and provide a one way ticket to the asylum.
Fortunately it has been fixed a few months ago, so upgrade to 6.3.0.Final or later and keep your sanity.
I've gone through a lot of intro-level tutorials on MVVM and can certainly see its merits but I'm having a hard time applying it to my LOB application. I plan on using MVVM Light, though I don't think that's going to impact the overall design structure of my VMs.
Suppose I want to write a TaxiDispatcher application where I have a service that goes out every minute and fetches the latest status of each of my taxis. I also have a list of fixed locations that people can call from and request a taxi. The dispatcher would then assign an available taxi to that location. At any given time, each taxi would either be available to the dispatcher or assigned to one of the particular locations in order to pick up a customer.
My main screen (let's call it DispatcherView) would consist of a list of available taxis on the left-side of the screen and then two additional pieces of visual content: a list of my locations (whether or not a person is there requesting service, which taxi has been assigned to that location, etc..) and a list of taxi assignments (elapsed time since they've been assigned, location, etc..).
All 3 of those views work off the same 2 sources: the taxi data service and the list of my locations that I can dispatch a taxi to. Right now, I've got separate views and view models for each of the 3 views (UnassignedTaxisVM, DispatchLocationsVM and AssignedTaxisVM), each being injected with one, or both, of the data sources. When the dispatcher assigns a taxi from the unassigned list, I use a Messenger to communicate with the other VMs to let them know that the taxi has been assigned to a location (the DispatchLocationsView and AssignedTaxisView are both updated with this new information as a result). But when I'm wiring up each VM, I'm having to inject the same datasource(s) to each of my VMs and thus having to write similar code in each VM to respond to the command when the dispatcher assigns a taxi to a location. It may just be my lack of experience with the framework but it just smells bad to me.
Does it make more sense to simply have one VM (DispatcherVM), and have the DispatcherView be responsible for rendering all 3 pieces of visual content? I envision this would involve having 3 ObservableCollections (UnassignedTaxis, Locations, AssignedTaxis) in my DispatcherVM and binding the datasource of each of the sub-views. As new data comes in from my taxi data service, I'd parse/update to the appropriate ObservableCollection and have my views respond that way.
What's the best practice here? I've got 3 distinct, but similar, "views" of the same underlying data. Should I create seperate VMs for each of the views or have one VM expose a view that essnentially consists of 3 separate lists/datagrids, etc..?
It sounds like you have reusable plumbing across ViewModels. Have you considered using inheritance (i.g. a ViewModelBase class) to reuse that plumbing? If inheritance isn't right for your solution, you could go the route of one main VM that is composed of child ViewModels that the main ViewModel coordinates.
Both patterns are equally good solutions at a high level in my opinion. It's hard to know which is more appropriate without a lot of context.