I have a need to create a "transactional" process using an external API that does not support COM+ or .NET transactions (Sharepoint to be exact)
What I need to do is to be able to perform a number of processes in a sequence, but any failure in that sequence means that I will have to manually undo all of the previous steps. In my case there are only 2 types of step, both af which are fairly easy to undo/roll back.
Does anyony have any suggestions for design patterns or structures that could be usefull for this ?
If your changes are done to the SharePoint object model, you can use the fact that changes are not committed until you call the Update() method of the modified object, such as SPList.Update() or SPWeb.Update().
Otherwise, I would use the Command Design Pattern. Chapter 6 in Head First Design Patterns even has an example that implements the undo functionality.
The GoF Command Pattern supports undoable operations.
I think the same pattern can be used for sequential operations (sequential commands).
Another good way for rollback/undo is the Memento Pattern. It's usually used to take a snapshot of the object at a given time and let the object state to be reverted to the memento.
Next to the GOF Command Pattern you might also want to have a look at the Transaction Script pattern from P of EAA.
You should probably create a Composite Command (or Transaction Script) that executes in sequence.
You might want to have a look at the Compensating Resource Manager:
http://msdn.microsoft.com/en-us/library/8xkdw05k(VS.80).aspx
If you're using C++ (or any other language with deterministic destructor execution when scopes end) you can take a look at Scope Guards. This technique can probably also be adapted to .NET by making ScopeGuard implement IDisposable and sprinkling "using" statements as needed.
Related
Little background
I'm new to writing use cases and representing their scenarios.
I'm dealing with a complex system. In the first step of analyzing the system, I created a use case diagram where each use case represents a distinct goal or value for the system. I have tried my best to keep the use cases independent. All these use cases require the initialization and activation of the system, so I decided to take out this common part and link it to the main use cases using include relationship.
I understand that include and extend relationships need to be used only when necessary.
Now I'm lookin into defining scenarios for each use case and then developing user stories and requirements based on scenarios.
Main issue
The use cases are very complex and the easiest way to analyze it seems to be mapping it into a sequence of steps/activities where each activity contains several scenarios and each scenario is represented using a sequence diagram.
I understand that an activity cannot be a use case which is related to the main use case using include relationship; but having sequence diagrams for activities seem wrong too.
What is the best way to represent a use case where each step of the main flow is complex and can have several interactions between actors and systems as well as having error scenarios which can result in termination of the sequence at that step or possibility of the user cancelling/aborting the sequence?
I have attached a simplified version of the activity diagram for "Initialize" use case.
As I mentioned, each activity can have many scenarios. For example
"Perform Self check" has many steps and each step might result in a failure that can terminate the sequence and alert the user (via a HMI). The user then can either terminate the initialization or retry.
"Validate system configuration" include steps for obtaining the reference config versions and comparing that to the system config, then download the new config files if necessary and then update the system configs. Each step might have a failure resulting in some sort of message to user and termination of the sequence. In some cases user should be able to skip the failed steps and proceed without doing that activity.
Same goes for every other activity in the diagram; many steps with exception or alternative paths.
Can I map these on one sequence diagram for the "Initialize" Use case?
My attempt to put all these on one sequence diagram failed.
I tried putting all these interactions on an activity diagram with swimlanes but things got so complex that stakeholders have a hard time understanding what is going on.
Maybe I'm trying to put too much details at the system level. Should I leave all these interim steps and interaction for the lower level of design? Should I create a hierarchy of use cases and roll down the complexity? I'm confused. :(
What is the best way to deal with such level of complexity? Could you provide some good examples.
The only way to represent a complex use case, where every step of the main flow can have multiple scenarios, is fortunately very simple:
The complexity of the scenarios does not change anything to the simplicity of the actor's goals. And if the goals are not sufficiently simple, you'd probably looking at too much details. Or the things are not as clear as they should.
The scenarios are often represented with a set of sequence diagrams. But if it gets really complex you'd better show the flow with an activity diagram.
By the way, you do not need to create an artificial extending or included use-case for the sake of modelling common steps. You may just create a separate activity diagram for the common part. Then, in each of your use-case activity diagram, you'd insert a call action of the common activity. This also avoids to misleadingly include the common part in the description of one UC and forget it for the others.
Last but not least, you also want to develop user-stories based on the use-case scenario. This is a mixed approach that requires some more thoughts:
user-stories are generally used without use-cases. Complex erquirements are described as an epic. The epic would then successfully be refine it into user-stories, that fit in an iteration;
it is possible to structure such user-stories according to stakeholder goals and tasks. THis approach is called user-story mapping. This is closer to the use-case, but there is no term to describe the higher-level goals.
use-case driven development is generally used without user-stories: the scenarios and activity directly lead to development without intermeriate user-stories.
Fortunately, the Use-Case 2.0 approach allows to combine both ways. Read the linked whitebook: it's short, it's free, it's written by the inventor of use-cases together with leading authors of use-case methodology; it offers a reegineered appraoch that allows agile developments, using use-case for the big picture and using use-case slices to break it down dynamically into units that can be developped in one iteration.
A complex use case can remain a single use case, but it may need multiple diagrams to specify its flows.
Your activity diagram (although not 100% UML compliant) gives a good overview of the flow of the use case. Keep this as the main diagram. I would decompose the complex steps in separate diagrams. To indicate that a step is decomposed in a separate diagram, you can display a rake symbol, as follows:
See UML 2.5.1 specification, section 16.3.4.1 for more information.
I am working on a use case diagram of a fully automated system. An external system will trigger just one use case of this system. Most of the other use cases are scheduled tasks and invoked by the timer. I have a use case that is invoked by the timer and it includes and extends two other use cases.
When I write the use case discriptions, who will be the actor for UC-2 and UC-3. Can a use case exists without an actor? I have seen lot of use case diagrams which has included or extended use cases without directly conneced to an actor. Please clarify this. Thanks in advance.
EDIT:
My system is connected with a DBMS. My system will analyse the database workload time to time and check whether any tuning can be done. That's all about my system. UC-1 is Analyse DBMS, UC-2 is Check Performance statistics and UC-3 is Tune the database. So timer is the one which invoke the use case. DBMS gets the benefit.Steps in Check Performance (UC-2) are repeated in another use case. That's why I put it as a separate use case. On the other hand Tune database(UC-3) will be performed only if there is a need for tuning after analyzing the database.
Officially this is correct. An included use case is a mandatory part of the including use case and an extending use case will optionally extend some use case. As #Ister notes in the comment, the actor for the included/extending use cases will be that of the main use case.
But, and this from my experience, you best avoid the use of those include/extend relations. In most cases, people tend to use them for functional decomposition which is plain wrong. A use case shall show an added value for its actor, not how a piece of functionality is used somewhere. In most cases a structuring of added value is not present and you can well show each bubble as a stand-alone use case or integrate it into the main use case. I recommend reading Bittner/Spence to get into matters.
Edit1: I just realize the sentence
trigger just one use case of this system
This rather sounds like you mix use cases with activities. It's not a piece of functionality. A use case is added value. There is a scenario (set) for a use case which has a trigger. But saying "a use case is triggered" sounds just wrong. You trigger the activities of a use case (where it starts getting technical). Most techies have difficulties making the cut and abstract to use cases. One more reason to read Bittner/Spence.
Edit2: In your comment you are talking about technical use cases. I admit that I had intensive discussions about this in the past. But you need to differentiate between technic and business. Your business use cases are Analyse DBMS, Check Performance, and Tune database. As such they are no UCs for a Timer but for some institution that cares about performance. The only UC for Timer is Trigger task (or something like that). There is a cut. The Timer does not care about business. It will happily trigger the shutdown of the system in the same way. It does not become a business actor only for that fact that it is technically used to start some business relevant process.
And not to forget: read Bittner/Spence. For me this book was an eye opener since I also had no idea about the intention of use cases.
It is likely that UC2 and UC3 are not really use cases but in fact steps/actions within the UC1. A good way to check to see whether you have real use cases is to ask your self if there is any actor (human, system or time etc.) that would have that use case as a complete goal. In other words would any actor initiate this use case. In addition to this - Occasionally you may have a use case that has no actor initiating. This should occur only in the case that there are multiple other use cases (i.e. at least 2)that will either include or extend that use case. In this case the use case is there for the purpose of facilitating reuse in your model and simplifying the model - in particular when you write your use case narrative. Don't go out of your way to create include and extend relationships always double check - if no actor is using the use case you are including or extending and no other use case is using it then you absolutely don't need it.
Use case is always a scenario executed by actor(s). In your situation primary actor is the system under discussion.
Technically you can introduce a timer as an actor who executes first UC-1 step, but better KISS. Just add a line before UC-1 steps via common convention:
Trigger: timer according to [Link to requirements about timer schedule].
If you have to write something beyond this line (for example timer checks conditions before triggering UC-1) then timer must become an actor.
Overall your use cases structure looks very valid for me, just don't forget to connect UC-1 to some higher goal anyhow. And please remove extends/includes as already mentioned.
I'm looking for insight/ papers/ articles, etc. whether a fully declarative Domain Model (as per DDD) is possible.
For example:
Validation can be declarative (lot's of ORMs do this)
business flow logic can be declarative: having a DSL for defining a workflow / Finite State Machine / process manager / DDD Saga (whatever you want to call it) on Crud-operations, through ddd-repositories most likely
decision logic can be declarative. I.e: most of the time this boils down to simple conditionals
derived / calculated fields could be done declaratively but is as bit tricky, especially when this cascades. I.e: you'd have to keep a dependency graph on the calculated fields, etc. Still it can be done.
Any links to people having actually tried that, or some convincing couter-arguments why this can't be done?
p.s.: Please don't answer with "Yes it can be done, since a FSM is Turing-complete with enough memory bla bla"
"Everything is a nail if you hold a hammer"
Instead of asking if it is possible - ask:
What are the reasons I want to do this particular thing declaratively?
Data validation is a nice thing to do declaratively. You have a DTO, you add some attibutes, everything is clear and readable.
Business flow done declaratively... Reminds me of a great failure of Windows Workflow Foundation. Is anyone actually using it?
What is the benefit of making a behaviour-centric components in a declarative way? Imperative way seems to be well-fitted to this.
Decision logic... maybe. But again - why?
"derived / calculated fields could be done declaratively but is as bit tricky"
Why do you want to do tricky things when there is a way of achieving the same result with straightforward things?
So why?
Do you need to change the behaviour of the app in runtime by editing some config file? OK, go for it.
Do you have a generic domain that will be used by many clients and you need some reconfiguration to fit them? Ok, but you need to clearly distinguish the unchangeable core of your domain and the varying stuff. Don't try to make all the things configurable - you'll end up with Inner Platform syndrome.
Do you believe you can make a declarative language your client could use to change his domain without a need for a programmer? No. You will fail. I know a language which was supposed to be like this. An easy, declarative language that ordinary accountants would use to explore their data. It's called SQL :D
I fully concur with Bartłomiej Szypelow's remark. Regardless, I will try to answer your question.
A declarative language always depends on an imperative language for it to work. Take something as simple as arithmetic for example. When we ask for the outcome of 1+1 we first need to know how the 1 should be understood and how in that context the + operator can be calculated before the statement as a whole can be interpreted. This is one of the ways we are able to overcome complexity; you don't need to know how a plus operation is done to be able to use one.
From http://en.wikipedia.org/wiki/Imperative_programming:
Procedural programming could be considered a step towards declarative
programming. A programmer can often tell, simply by looking at the
names, arguments and return types of procedures (and related
comments), what a particular procedure is supposed to do, without
necessarily looking at the details of how it achieves its result. At
the same time, a complete program is still imperative since it 'fixes'
the statements to be executed and their order of execution to a large
extent.
In any domain the same applies. If you ask the flight attendant to reschedule your flight she knows what a flight and a passenger is and how to reschedule one. Creating a fully declarative flight scheduling domain model without describing how scheduling works is therefore impossible. Since all domain models contain operations/behavior it is therefore equally impossible to create a domain model in a declarative language unless your problem domain is not unique, for example when you have three flight companies that operate in similar fashion.
Back to why... you said:
Actually, the hypothetical reason why is actually to allow non-coders
to create a (trivial) backend by configuration
Declarative programming is not always simpler than imperative programming. Most of the time people tend to think in outcomes, but sometimes the outcomes are so varied that it is (much) simpler to think in steps. This is the reason why these different styles exist and continue to exist in the first place. The main difference between a coder and a non-coder is not that a non-coder tends to think in terms of outcomes instead of processes, but that the non-coder simply does not want to be bothered with the workings of a computer. The non-coder wants to focus on the problem. Depending on the domain a non-coder may be helped best with an imperative DSL, instead of an declarative DSL.
I'm just getting into event-driven architectures and would like to know what the convention is for naming commands and events. I know this much: Commands should be in the form DoSomething while events should be in the form SomethingHappened. What I need to clarify is if I need to append the word 'Command' to my commands and 'Event' to my events e.g. DoSomethingCommand as opposed to just DoSomething and SomethingHappenedEvent as opposed to just SomethingHappened. I would also like to know what the rationale is behind the community-preferred convention. Thanks!
The Command and Event suffixes are optional and are a matter of preference. I prefer to omit them and try to make the intent evident from the name alone. The most important aspect of naming commands and events is making sure they reflect the business domain more so than the technical domain. A lot of times terms like Create, Update, Add, Change are far too technical and have less meaning in the business domain. For example, instead of saying UpdateCustomerAddress you can say RelocateCustomer which could have a larger business context to it.
My convention is depending on namespaces and by that I mean that I never use the suffix Event nor Command.
I also organise commands and events into separate namespaces based on the aggregate type they are meant to affect.
Example:
// Commands
MyApp.Messages.Commands.Customers.Create
MyApp.Messages.Commands.Orders.Create
MyApp.Messages.Commands.Orders.AddProduct
// Events
MyApp.Messages.Events.Customers.Created
MyApp.Messages.Events.Orders.Created
MyApp.Messages.Events.Orders.ProductAdded
Depending on your requirements you might want to place your events into a separate assembly. The reason for this would be if you need to distribute events to downstream systems. In that case you probably don't want downstream systems to have to bother about your commands (because they shouldn't).
The convention that I've seen a lot and use myself is that events should be in past tense and described what happened:
UserRegistered
AccountActivated
ReplyPosted
Commands is something that you would like to do. So create names that illustrate that:
CreateUser
UppgradeUserAccount
As for organization, I usually put them together with the root aggregate that they are for. It makes it a lot easier to see what you can do and what kind of events that are generated.
That is, I create a namespace for each root aggregate and put everything under it (repository definition, events, commands).
MyApp.Core.Users
MyApp.Core.Posts
etc.
Commands and Events form a language for your application...an API. The use of terms like 'command' and 'event' are perhaps useful for system-level definitions where technical terms are meaningfully mixed into an entity's purpose, but if you are dealing with definitions for Domain behavior's, then drop the system/technical terminology and favor the business-speak. It will make your code read more naturally and lessen typing.
I started with the 'Command'/'Event' appendages but realized it was a waste of time and drew me away from the Ubiquitous Language DDD popularized.
HTH,
Mike
Appending Command and Event would be redundant information if yor commands/events are properly named. This would be noise that makes your code less readable. Remember Hungarian Notation? Most programmers (that I know of) don't use it anymore.
I am using NHibernate for persistence, but i read somewhere that NHibernate acts as unitofwork container. So do i need to create a separate UnitOfWork implementation. ?
Or continue with Nhibernate's unitofwork.
You don't need to create separate UoW implementation.
I suggest you to read this post: nhibernate.info
According to Martin Fowler, the Unit of Work pattern "maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."
Nhibernate internally already implements this pattern tracking all the objects has been modified (added,updated,deleted). You don't need to do anything because it already use this pattern itself
just to make this concept clear it is like if for each row of your resultset there is a "magic" column that says if the row has been added,updated or deleted