I'm new to UML and I have crossed path with sequence diagram, and realized that there's 2 types: distributed and centralized. Can anyone explain me the differences?
centralized control, with one participant doing most of the processing and the other participants there to supply data.
Example:
Distributed control, in which the processing is split among many participants, each one doing a little bit of the algorithm
Example:
Both styles have their strengths and weaknesses. Most people, particularly those new to objects, are more used to centralized control. In many ways, it’s simpler, as all the processing is in one place; with distributed control, in contrast, you have the sensation of chasing around the objects, trying to find the program.
Despite this, object bigots like strongly prefer distributed control. One of the main goals of good design is to localize the effects of change. Data and behavior that accesses that data often change together. So putting the data and the behavior that uses it together in one place is the first rule of object-oriented design.
Furthermore, by distributing control, you create more opportunities for using polymorphism rather than using conditional logic. If the algorithms for product pricing are different for different types of product, the distributed control mechanism allows us to use subclasses of product to handle these variations.
Related
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
I have created a sequence diagram, and found it has multiple nested alt.
Is this a good or bad practice?
If it is a bad practice, what should I do instead?
The good, the bad and the ugly
It is difficult to give advice about good and bad practices without objective criteria, and these will depend on the purpose of the diagram:
If you use UML for some kind of visual programming, where a comprehensive diagram should show all the details of a specific interaction, nested alt could be a good practice if there is no alternative. Since different lifelines are driving independent alternatives (FusionAuth the outer alt, Occupations the inner one), the nesting represents the behavioral logic appropriately. But if a same lifeline would drive decision, a flattened alt could a be a more readable way, trading the more complex nesting against more but simpler branches.
If you use UML to communicate and to reason about a system, the diagrams should be easily understood: nesting would be a bad practice, since it adds a level of complexity.
We fortunately have avoided the ugly: identical nested alt in several branches.
Alternatives to nested alt
The UML secret is to have more diagrams but smaller ones, each focusing on a single aspect. You can find this advice at the end of almost every chapter of Booch, Jacobson and Rumbaugh's book The UML User guide.
Two strategies are applicable here:
Diagrams per scenario: the main success scenario would be one diagram, and the different failure scenarios would be the others. Super-easy to read.
Separation of concerns: Different concerns would be addressed in different diagrams you could for example separate the use of Occupations by its clients and the way Occupations does its business: separate Manager, Client, Occupations, and Occupations, FusionAuth and Database in two diagrams; You'd avoid nested alt, the inner one being in the second diagram and not necessarily relevant for the same audience.
Remark: I'm not a big fan of visual programming. But if you are, the second strategy is fully compatible with it, with the advantage of preventing the ugly repeating of the same nested fragments in several places.
Sort of. You can do that and it will be okay. However, once you start doing that you are in danger to fall in graphical programming. Once upon a time people dreamed of graphical programming as the solution for the future. Simply, it isn't. Code is much denser and easier to read. So don't start writing programs that way.
Now for the use of that construct. Where ever you want to show some complex collaboration a graphical overview of the participants will be most helpful. But only if you stick to the most important part of tha communication. Rather than nesting fragments it's better to have different SDs to focus. You can use message endpoints to cross between detail diagrams. Again, it depends on how you make the split. It needs some experience to find the golden ratio.
I have a small UML assignment due Monday; it doesn't seem too complicated, and I'm not asking this site to solve it for me -- I'm just asking for clarification over a couple doubts of mine.
I'm just telling parts of the assignment because its content is probably not so relevant.
We're provided a basic use case where the actors "officer" (e.g. police officer) communicates with the actor "correspondent" in order to report an emergency. The use case is expressed in the form:
Use case name: Report emergency
Participating actors: Officer, correspondent
Flow of events: ...
Preconditions: ...
Postconditions: ...
Then we're given three scenarios that "refine" the use case. I say "refine" because they turn it upside-down: they involve team leaders, respondents, incident handling -- nothing that was even mentioned in the flow of events described by the very basic use case given.
On top of these scenarios we're given ten "events" (i.e. they basically chunk the three scenarios into ten easily recognizable sentences). The assignment asks us to make one collaboration diagram for each of these events.
I know that collaboration diagrams describe the behaviour of the system, i.e. how the different parts of the systems interact with each other. So I thought that, even with these "creative" scenarios given, I could make something out of them. But then this part comes:
"Collaboration diagrams should make use of controller, boundary, domain objects and other new fabricated software objects (e.g. data structure components) necessary to completely handle each event."
And then:
"Your assignment will be evaluated in terms of the quality of your design (i.e. modularity: low coupling, high cohesion)"
My questions are:
1) Are scenarios supposed to present so much new information compared to the basic use case?
2) Do I just have to draw ten simple collaboration diagrams? Using which classes?
3) Why are things like low coupling, high cohesion, domain objects, mentioned? What do they have to do with all of this?
1) A scenario is a detailed description of a use case. There can be several scenarios based on constraints. The use case itself just describes the sunny day scenario in a condensed format. The meat is in the scenarios.
2) Classes related to the UC can be extracted when going through the scenario. You will find text parts that tell certain functions need to be performed. Take these classes and place them in the collaboration diagram and connect them with the right message.
3) These are general design rules. Low coupling/high cohesion means good design (and vice versa). The domain objects are those which are in the center of the system and the sum of all use cases will deal with the sum of all domain objects.
I am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.
I'll admit that I am still quite a newbie with DDD and even more so with CQRS. I also realize that DDD and/or CQRS might not be the right approach to every problem. Nevertheless, I like the principals but have some questions in the context of a current project.
The solution is a simulator that generates performance data based on the current configuration. Administrators can create and modify the specifications for simulations. Testers set some environmental conditions and run the simulator. The results are captured, aggregated and reported.
The solution consists of 3 component areas each with their own use-cases, domain logic and supporting data structure. As a result, a modular designed seems appealing as a way to segregate logic and separate concerns.
The first area would be the administrative aspect which allows users to create and modify the specifications. This would be a CRUD heavy 'module'.
The second area would be for executing the simulations. The domain model would be similar to the first area but optimized for executing the simulation as opposed to providing a convenient model for editing.
The third area is reporting.
From this I believe that I have three Bounding Contexts, yes? I have three clear entry points into the application, three sets of domain logic and three different data models to support the domain logic.
My first instinct is to follow these lines and create three modules (assemblies) that encapsulate the domain layer for each area. Should I also have three separate databases? Maybe more than three to support write versus read?
I gather this may be preferred for CQRS but am not sure how to go about it. It appears to me that CQRS suggests a set of back-end processes that move data around. But if that's the case, and data persistence is cross-cutting (as DDD suggests), then doesn't my data access code need awareness of all of the domain objects? If so, then is there a benefit to having separate modules?
Finally, something I failed to mention earlier is that specifications are considered 'drafts' until published, which makes then available for simulation. My PublishingService needs to have knowledge of the domain model for both the first and second areas so that when it responds to the SpecificationPublishedEvent, it can read the specification, translate the model and persist it for execution. This makes me think I don't have three bounding contexts after all. Or am I missing something in my analysis?
You may have a modular UI for this, but I don't see three separate domains in what you are describing necessarily.
First off, in CQRS reporting is not directly a domain model concern, it is a facet of the separated Read Model which takes on the responsibility of presenting the domain state optimized for reporting.
Second just because you have different things happening in the domain is not necessarily a reason to bound them away from each other. I'd take a read through the blue DDD book to get a bit better feel for what BCs look like.
I don't really understand your domain well enough but I'll try to give some general suggestions.
Start with where you talked about your PublishingService. I see a Specification aggregate root which takes a few commands that probably look like CreateNewSpecification, UpdateSpecification and PublishSpecification.
The events look similar and probably feel redundant: SpecificationCreated, SpecificationUpdated, SpecificationPublished. Which kind of sucks but a CRUD heavy model doesn't have very interesting behaviors. I'd also suggest finding an automated way to deal with model/schema changes on this aggregate which will be tedious if you don't use code generation, or handle the changes in a dynamic *emphasized text*way that doesn't require you to build new events each time.
Also you might just consider not using event sourcing for such an aggregate root since it is so CRUD heavy.
The second thing you describe seems to be about starting a simulation which will run based on a Specification and produce data during that simulation (I assume). An event driven architecture makes sense here to decouple updating the reporting data from the process that is producing the data. This has huge benefits if you are producing large amounts of data to process.
However it doesn't sound like a Simulation is necessarily the kind of AR that would benefit from Event Sourcing either. For a couple reasons:
Simulation really takes only one Command which is something like StartSimulation
Simulation then produces events over it's life-time which represent what is happening internally with the simulation
Simulation doesn't seem to ever receive any other Commands that could depend on the current state of the Simulation
Simulation is not interacted with by multiple clients/users simultaneously and as we pointed out it isn't really interacted with at all
In general, domain modeling is very specific to each individual project so it's hard to give you all the information you need to build your domain model. It will come as a result of spending a great deal of time trying to understand your user's needs and the problem they are trying to solve with the software. It likely will go through multiple refinements as you develop insights into their process.