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.
Related
hello, my first question is how I can place cases to better readability? I want to make this diagram fit on a A4-sized paper.
But I am aware that this diagram may be badly made, so I ask you to advice, maybe I should share on the smaller part?
You need to to connect a use case only to its primary actor. So eventually you have to create a common role where the UC is used by this common actor role. Then your specific actors inherit from this common one. Like in #Amir's example International Student inherits from Student.
I'd simply up-vote the latter example but it has <<include>>/<<extend>> which is no favorable with use case synthesis. Moreover it uses a generalization which is very bad practice with UCs since a UC represent an individual added value and inheritance from added value does not make sense (unlike in a class context).
I don't understood your language (In your use-cases). Generally most of time we have some common feature so You can use inheritance in UML diagram. For example if you have different kinds of students (or Actors) that have some common feature you can do something like below picture:
I think there is too many of use cases. I had the same problem. Try using CRUD - https://books.google.co.uk/books?id=gKHfVZn1CkgC&pg=PA367&lpg=PA367&dq=crud+use+cases&source=bl&ots=g7C2qnzunP&sig=F3OtpNWT29NFyqFvmO-MBtTG98k&hl=en&sa=X&ved=0ahUKEwjAmKifh9_OAhWpCsAKHV9pA344ChDoAQg4MAU#v=onepage&q&f=false
Also, you can divide your diagram into few use case diagrams for each actor. Or put all actors on the one side of the diagram and use cases on other. Hope this helps.
I completely agree with the given suggestions (CRUD, inheritance and responsibility by roles) and I additionally recommend not to try to create an overview about the whole universe. Instead, try to separate your use cases into groups based on similarities, differences etc. and explain your modeling on smaller pieces.
Avoid too complex structures and mutual/cyclic dependencies - they are almost always a sign of poor design. Remember, you have to implement and test every connection in your diagram somehow. Less connections, less effort, less errors.
Is the diagram correct? Can more use cases be added in this diagram? Is there a need for include and extend functionalities?
The diagrams look ok and you can add more use cases at your wish. But for clarity sake it's advisable to split them into sub-domains where you can focus on a couple of somehow related use cases. Do this by creating different diagrams or using boundaries to split the sub-domains.
Avoid <<include>> and <<extend>>. Use cases undergo a synthesis an not an analysis. There are only very rare cases where one could use those relations in a useful way.
Can more use cases be added in this diagram?
This should not be your goal, therefore I daresay you don't want to ask this question. At least not anyone!
Instead, try to model the fewest possible UML entities without losing valuable information. Simplifying and splitting up diagrams into simpler parts is often way more challenging than modeling new entities.
The question is: Which information is required? You'll need to work that out with your stakeholders. Remember: YAGNI.
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.
I have an Access db I wrote that I've used for my checkbook and budgeting for the last 3 years. I've never written a program before, but I've decided to write the db into a stand alone program. My only experience, besides the simple VBA in the db itself, is an Intro to C++ class and an OO Logic class.
Even though I know what I want the program to do (because it's what my db does now) I want to approach the planning and design as properly as possible, so I can write the program as properly as possible, so that feature additions and maintenance are easier.
I need help planning. I guess UML diagrams should be first. What UML diagrams do I need to do? And in what order? I tried to do a use-case but since the program only involves me, my money, the bank, and the stores, it seemed pointless. Or was I thinking about it wrongly? Do I need to diagram my money and my budget inside my account? I don't know. I need help on how to proceed. Thanks.
It's good to have a set of UML diagrams to keep track of what is happening, but to remember in the end that documentation decays - your code is your design. That said, UML are good for planning and recalling bits and parts. There's a large dose of personal experience involved here, so feel free to take what you want and leave out what you think don't applies.
Use Case Diagrams
Skip this, and just write use cases instead.
Class Diagrams
I find them useful for planning the big picture view of an architecture, but I usually would leave out all the method names, or only leave in the relevant . I use it to illustrate the logical model of your classes
Sequence Diagrams
One of the more useful diagrams especially for business logic, and flow of data. I always find myself sketching sequence diagrams for complicated data-flow and especially when there are events being dispatched.
Object Diagrams
Shows the interaction of objects at run-time. I usually draw those for complex object interactions, and not the 'academically correct' ones. I think it is less useful than sequence diagrams.
Flow diagrams
Good for websites if you have complicate flow
State Transitions
Important if your application has many states. Again, just sketch out the most complex system, there is no need to have one for every sub-system.
ER Diagram
I know this is not UML, but a good database design upfront is important, and an ER diagram would help you to organise and plan how different tables relate with each other
Since your application is for personal use, I think you only really need two diagrams, maybe three. You can use a Use Case diagram if you want, but you will probably be better off with just a list of use cases. Since no one else has stated it, a use case is a requirement where you state something you're going to use it for. These help you define what features you need.
Next you need the class diagrams for how you're going to organize your program. A class diagram shows which classes you have and how they're connected. This is useful for figuring out if your program is too complicated or if you're using the antipattern known as the blob. If you have a lot of lines connecting classes to each other, you might want to reorganize to see if you can make each class more cohesive and if you see very few classes, you might want to check for a blob antipattern. An antipattern is a common occurrence which is bad for readability or maintainability. Class cohesiveness is defined by if each class has exactly what it needs. For example, if you decide to have a class for your account, it doesn't need to know information which isn't related to your account, like the street address or name of your bank.
The last UML diagram I think you'll need is a sequence diagram which shows how different objects in your program will interact. This will help you better understand the interactions your classes are doing and decide if you need to better organize them if they're getting too complex.
Those are the UML diagrams you might need. You might also want a network diagram to understand how your database is going to connect to the bank's website and get the information you need.
The diagrams are there just to make you understand what you are doing and keep you on track. I guess you already know that. In your case, i Believe a detailed use case will suffice, just to make sure you handle all the features and dont forget anything. (Reminder: Use case is not a diagram. it is text)
I'm fond of using UML diagrams to describe my software. In the majority of cases the diagrams are for my own use and I use them for more involved pieces of code, interactions etc. where I'll benefit from being able to look back over them in the future.
One thing I've found myself doing a few different ways is diagramming threads. Threads by their nature tend to pop up in the more involved pieces of code and keeping track of them is often a primary purpose of my design documents.
In the past I've used a symbol in a sequence diagram to show the creation of a new thread but looking back at some diagrams doing that it's sometimes ambiguous between an object's lifetime - which sequence diagrams are for - and a thread's lifetime. Is there a better approach for incorporating threads into UML?
I managed to produce a diagram that makes sense to me at the time of drawing it. The basic premise is that I've overlaid grey boxes representing class instances with blue boxes representing thread lifetimes. The main thing it lets me keep track of is knowing which thread I will be executing on when I call certain methods.
No doubt there's better and more intuitive ways to do thread and class modeling. The measure of success for me is whether my own diagram still gives me the same level of understanding 6 months down the track.
Activity, Sequence, and State Diagrams are all correct ways of showing thread behavior.
1st: (To vs's comments) There are two sets of diagrams or modeling elements in UML, static structure, as you put it, and behavioral. Any book will help you understand the split, typically in the contents/TOC, additionally it can be seen on page 11 of Martin Fowler's UML Distilled a near defacto standard for beginning UML in my opinion.
2nd: (To sipwiz's question and comment) Activity diagrams are not commonly understood to model business process, they can be used for that however, and most examples or simple tutorial would approach it from a business standpoint.
Discussion on your options to model threads:
Activity diagrams - Allows for forking and specifying concurrency by using a BAR and usage lines. Note the example at the bottom is no a business process, example. Most people can read these, business, management, and developers, though sometimes they can lack detail or get messy.
Sequence Interaction diagrams - In the same post, example, you will see sequence diagrams allow you to specify parallel behavior within a sequence by boxing parallelizable behavior with a label "par", this is useful to show the reader what methods can or should be called in parallel, ie, by different threads. This is the method I would use for detailed developer like discussions around building an object.
State diagram - The state chart just like the activity allows for concurrency by using a BAR and usage lines.
NOTE: These will not model a specific thread and it's exact lift cycle, as that is part of the instance/run-time level of modeling, if this what you want clarify your question and I will respond. I would just model it using one of the above as no one other than a MDA/UML expert will call you out, and you are not generating a running system.
Also: Please note that further details can be found in most UML books.
Also leveraged: http://www.jguru.com/faq/view.jsp?EID=56322
Traditionally threading has been depicted diagramatically using Petri Nets. Rob Martin has an article on multithreading in UML which you may find useful.
Update- just remembered you can represent threads with forks in activity diagrams- I've managed to find something that explains this.
It is very hard to find any free tutorials for Petri Nets, however I know Petri Nets are good for modeling concurrency, so I Google'd "producer-consumer Petri Nets" (my favourite threading thing) and found this.
I've also found some slides that show Petri Nets modeling a Semaphore.
UML activity diagrams have fork and join elements to show parallel flow of logic.
I don't know of a way, but using a sequence diagram does not seem entirely inappropriate, considering that a thread is in many languages implemented as a Thread (or similar) class.
The most UML-compatible way would probably be to add an annotation of some sort indicating that the 'object' represents a thread.
The UML is defined by the UML Superstructure, you can find it here http://www.omg.org/spec/UML.
If you read the specification you find that a UML class can be active. An Active Class is a class with the meta-attribute isActive set to true. It is also depicted differently.
An object instances of an active class automatically executes a "classifier behavior". As for any behavior you can define it by means of an activity in which you wait for asynchronous signals (AcceptEventActions) and invokes methods (CallOperationAction) or other behaviors (CallBehaviorActions). That is how active objects are modeled in UML. You just have to read the UML specification.
Activity diagrams will model the internal workings of your software with forks and joins to represent threads. To find out exactly how to model this properly, please see Conrad Bock's excellent series of articles. Here is the article that covers forks and joins, but you should follow the links back to the first article in the series to learn how to properly model using "Colored Petri Nets". It's not how you think (and it's pretty easy)!
There is a new, in-process standard at the OMG for a language called Alf that provides a more convenient surface notation for activity diagrams and is intended for representing code. From the spec:
A primary goal of an action language is to act as the surface notation for specifying executable
behaviors within a wider model that is primarily represented using the usual graphical notations of
UML. For example, this might include methods on the operations of classes or transition effect
behaviors on state machines.
For a programmer, you probably can't get more intuitive than Alf. And it will convert perfectly into UML activity diagrams.
UML strongest point is depicting the static structure. If you use short-lived threads, I also don't see any easy way of diagramming them. Maybe you can find a solution by turning things around a bit: why do you use/need threads? What's the functionality they provide? If they interact with each other and follow some (message passing) API, drawing them as components might make sense.