—  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — —

Sup­port trans­la­tion:
 — —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — —

“The UML is the stand­ard lan­guage for spe­cify­ing, visu­al­iz­ing, con­struct­ing, and doc­u­ment­ing all the arti­facts of a soft­ware sys­tem.””
Activ­ity Dia­grams
The logic­al place to start walk­ing through some of the UML dia­grams is by look­ing at activ­ity dia­grams.
Fig­ure 2: Activ­ity dia­gram
Activ­ity dia­grams show the flow of con­trol. As illus­trated in Fig­ure 2, you can see activ­it­ies rep­res­en­ted as roun­ded rect­angles. Activ­it­ies are typ­ic­ally action states — states that trans­ition auto­mat­ic­ally to the next state after the action is com­plete. The filled in circle rep­res­ents the start of the activ­ity dia­gram — where the flow of con­trol starts. Trans­itions shown as arrows show how you move from activ­ity to activ­ity. Syn­chron­iz­a­tion bars show how activ­it­ies hap­pen in par­al­lel. I can guard a trans­ition that says ““I want you to go to this activ­ity only if this con­di­tion is true,”” and I can show you where it stops. Now if you’re a cer­tain age, you’ll prob­ably look at this activ­ity dia­gram and think, ““hmm … that looks like a flow chart.”” And that’s exactly what it is, except I’m not doing it down at the pro­gram­ming level. Typ­ic­ally, I use an activ­ity dia­gram fairly early on in my ana­lys­is and design pro­cess to show busi­ness work­flow. I’ll also use them to show where each of my use cases might be in an activ­ity to illus­trate what use case has to hap­pen. I also use activ­ity dia­grams to show how things flow between my use cases.
But one of the great things about the UML is its ver­sat­il­ity. So while I use activ­ity dia­grams at the begin­ning of the life­cycle, oth­ers can use them in a dif­fer­ent phase entirely. I’ve seen people use activ­ity dia­grams down at the design level where they had a very com­plic­ated set of algorithms for a par­tic­u­lar class. And many people use them to show the flow between the meth­ods of a class.
the sys­tem. Act­ors are rep­res­en­ted as stick fig­ures.
Fig­ure 4: Act­ors
The example that I worked up for this intro­duc­tion to UML is a little mod­el of a course regis­tra­tion sys­tem. So in this instance, the first thing I would do when start­ing my ana­lys­is pro­cess is to ask, ““who is going to inter­act with this sys­tem?””
For the course regis­tra­tion mod­el, I have a regis­trar, a pro­fess­or, and a stu­dent. I also have an extern­al billing sys­tem. This billing sys­tem also qual­i­fies as an act­or. (See, an act­or doesn’t have to be a per­son — it’s any­thing that inter­acts with the sys­tem but is out­side of the sys­tem.)
A use case is a sequence of related trans­ac­tions per­formed by an act­or in the sys­tem in a dia­log. Or, to put it in Eng­lish, a use case is a chunk of func­tion­al­ity. And here’s the key: it is not a soft­ware mod­ule — it is some­thing that provides value to the act­or.
Use cases are shown as ovals, and the easi­est way to find them is to look at each of your act­ors and ask your­self why do they want to use the sys­tem. In my case, my regis­trar is going to main­tain the cur­riculum, my pro­fess­or is going to request a roster, my stu­dent main­tains the sched­ule, and my billing sys­tem receives the billing inform­a­tion. So I cre­ate my use cases by look­ing at it from the cus­tom­er point of view and ask­ing, ““so, mis­ter sys­tem act­or, why do you want to use the sys­tem? What value does this sys­tem provide to you?””
The next step, once you’ve iden­ti­fied how your act­ors will be inter­act­ing with the sys­tem, is do doc­u­ment your use cases. Each use case needs to be doc­u­mented with the flow of events, and this is done from the actor’s point of view. It should detail what the sys­tem must provide to the act­or when the use case is executed. Typ­ic­ally it will show things like how the use case starts and fin­ishes. What things does that use case have to do? You’ll have the nor­mal flow of events (what I call the ““happy days”” scen­ario), where everything works. Then you’ll get the abnor­mal flow of events, the ““rainy day”” scen­ario. What hap­pens when the sys­tem doesn’t work? I’ve found by doc­u­ment­ing my flow of events that I always start with the happy days scen­ario.
Take as an example, walk­ing up to an auto­mated tell­er machine. You walk up to the ATM and insert your card. It asks for your PIN num­ber. You enter it, and you are asked what you would like to do. You say ““I want some money.”” It asks where the money should be taken from. You tell it to take it from your check­ing account. It asks how much. You say $100.00. Then magic hap­pens … it gives you $100.00. Then it asks if you want another trans­ac­tion. You say no. It gives you your card back, gives you a receipt, and the trans­ac­tion is over. That’s the happy day scen­ario.
Second scen­ario. You go up to the ATM, insert your card, and enter your PIN. The ATM tells you it’s the wrong PIN. You enter your num­ber again. Again you are told that the PIN is incor­rect. You In my course regis­tra­tion example, for instance, you can see that there are a lot of ““if X then Y”” work­flows. That’s where you want your cus­tom­er to help you out. Get­ting agree­ment early means your cus­tom­er under­stands these scen­ari­os and says ““yes, this is what we want.”” Use cases are a great way to ensure that what you’re build­ing is really what the cus­tom­er wants, because they show the act­ors, the use cases, and the rela­tion­ships between them.
Fig­ure 5: Use case dia­gram
So we have a great dia­gram that graph­ic­ally shows me what? The answer is sim­ple — it is a great dia­gram that shows a good over­view of the sys­tem. It shows what is out­side the sys­tem (act­ors) and the func­tion­al­ity that the sys­tem must provide (use cases). If there is a leg­acy sys­tem you need to take into con­sid­er­a­tion, here’s where you deal with it. For­cing me to work with these types of inter­faces very early in the pro­ject means that I won’t be faced with the pro­spect of wait­ing until cod­ing starts to fig­ure out how I’m going to talk to that black box that I can’t change.
One more thing you should know about use cases is the use case real­iz­a­tion. This is the ““how”” of the use case. It’s usu­ally a buck­et that con­tains three dif­fer­ent types of dia­grams: sequence dia­grams, col­lab­or­a­tion dia­grams, and a class dia­gram that we call a view of par­ti­cip­at­ing classes. Use case real­iz­a­tions are basic­ally a way of group­ing togeth­er a num­ber of arti­facts relat­ing to the design of a use case.
Sequence Dia­grams
Sequence dia­grams show object inter­ac­tions arranged in a time sequence. I can use the flow of events to determ­ine what objects and inter­ac­tions I will need to accom­plish the func­tion­al­ity spe­cified by the flow of events.
Fig­ure 6: Sequence dia­gram
Fig­ure 6 shows how a stu­dent suc­cess­fully gets added to a course. The stu­dent (let’s call him Joe) fills in some inform­a­tion and sub­mits the form. The form then talks to the man­ager and says ““add Joe to Math 101.”” The man­ager tells Math 101 that it has to add a stu­dent. Math 101 says to Sec­tion 1 ““are you open?”” In this case, Sec­tion 1 replies that they are open, so Math 101 tells sec­tion 1 to add this stu­dent. Again, sequence dia­grams are great tools in the begin­ning because they show you and your cus­tom­er step-by-step what has to hap­pen.
From an ana­lys­is point of view, I’ve found over the years that sequence dia­grams are very power­ful in help­ing me drive require­ments; espe­cially require­ments that are hard to find. User inter­face require­ments, for instance, are notori­ous because you always seem to get require­ments that are just not test­able. A com­mon UI require­ment like this is ““this sys­tem shall be user-friendly.”” How many of you have met a friendly com­puter? One of the bene­fits of these types of dia­grams is that every line com­ing from an act­or that rep­res­ents a per­son, tells you that some­thing in your UI has to provide a cap­ab­il­ity needed by that per­son. In oth­er words, you can use sequence dia­grams to drive out test­able user inter­face require­ments.
Sequence dia­grams are, there­fore, good for show­ing what’s going on, for driv­ing out require­ments, and for work­ing with cus­tom­ers. That usu­ally leads to the ques­tion, though, of how many do you need to cre­ate? My answer is, ““until you do enough.”” You’re going to find out when you do sequence dia­grams that you reach a point where you’re not find­ing any new objects, not find­ing any new mes­sages, and that you’re typ­ing the same thing over and over. In the example of Joe join­ing Math 101, we learn that the pro­cess would be the same if Joe wanted to join His­tory 101. So, rule of thumb, do a sequence dia­gram for every basic flow of every use case. Do a sequence dia­gram for high-level, risky scen­ari­os, and that should be enough. That’s how many sequence dia­grams I do.
to remem­ber here, is that a col­lab­or­a­tion dia­gram is just a dif­fer­ent view of a scen­ario and you can go back and forth between sequence dia­grams and col­lab­or­a­tion dia­grams to get the view that best illus­trates your point.
Occa­sion­ally, you might hear the phrase ““inter­ac­tion dia­grams.”” Some­times people will col­lect­ively refer to a col­lab­or­a­tion dia­gram and a sequence dia­gram as an inter­ac­tion dia­gram.
Class Dia­grams
A class is a col­lec­tion of objects with com­mon struc­ture, com­mon beha­vi­or, com­mon rela­tion­ships, and com­mon semantics. You find them by examin­ing the objects in sequence and col­lab­or­a­tion dia­grams, and they are rep­res­en­ted in the UML as a rect­angle with three com­part­ments.
Fig­ure 8: Classes
The first com­part­ment shows the class name, the second shows its struc­ture (attrib­utes), and the third shows its beha­vi­or (oper­a­tions). These com­part­ments can be sup­pressed, how­ever, so that you can see just the name, just the name and the attrib­utes, or all three. One thing you should also know is that it’s import­ant, when nam­ing classes, to use the vocab­u­lary of the domain and pick a stand­ard. For this instance, my classes are all sin­gu­lar nouns that begin with a cap­it­al let­ter. You may choose to do it dif­fer­ently, and that doesn’t mat­ter. What does mat­ter is that before your pro­ject you pick a stand­ard and stick with it so that everything is con­sist­ent across the pro­ject.
Class Dia­grams show you the stat­ic nature of your sys­tem. These dia­grams show the exist­ence of classes and their rela­tion­ships in the logic­al view of a sys­tem. You will have many class dia­grams in a mod­el.
The UML mod­el­ing ele­ments found in class dia­grams include:
Classes and their struc­ture and beha­vi­or.
Asso­ci­ation, aggreg­a­tion, depend­ency, and inher­it­ance rela­tion­ships.
Mul­ti­pli­city and nav­ig­a­tion indic­at­ors
Role names.
Take a look at Fig­ure 9. This dia­gram shows oper­a­tions (beha­vi­or): what an object in that class can do. I find my oper­a­tions by look­ing at my inter­ac­tions dia­grams.
Fig­ure 9: Oper­a­tions
Here I’m say­ing that I need to be able to ask the regis­tra­tion man­ager to add a stu­dent to Math
101. That’s going to trans­late into an oper­a­tion called ““addCourse.””
The struc­ture of a class is rep­res­en­ted by its attrib­utes. So how do I find my attrib­utes? By talk­ing to domain experts. By look­ing at my require­ments. In my example, I learn that each course offer­ing has a num­ber, a loc­a­tion, and a time. This trans­lates out to three attrib­utes.
classes. (Rep­res­en­ted in the UML as a line con­nect­ing the related classes with a dia­mond next to the class rep­res­ent­ing the whole.)
• Depend­ency — a weak­er form show­ing the rela­tion­ship between a cli­ent and a sup­pli­er where the cli­ent does not have semantic know­ledge of the sup­pli­er. A depend­ency says ““I need your ser­vices, but I don’t know that you exist.”” (Rep­res­en­ted in the UML as a dashed line point­ing from the cli­ent to the sup­pli­er.)
To find rela­tion­ships, once again, I go back to my sequence dia­gram. If two objects need to ““talk””, there must be a means to do so (i.e., a rela­tion­ship between their classes).
I typ­ic­ally start out and make everything an asso­ci­ation. As I’m doing more ana­lys­is, I might find I have an aggreg­a­tion because I’m going to have to take care of a par­ent-child rela­tion­ship. When I get into the design phase, I find out that I might not need an asso­ci­ation because some­body else is going to pass that object into one of my meth­ods — so I make it a depend­ency.
Fig­ure 11: Rela­tion­ships
In Fig­ure 11 you see these rela­tion­ships. As asso­ci­ation says the Pro­fess­or can talk to the Course Offer­ing, and the Course Offer­ing can talk to the Pro­fess­or. Mes­sages can be ini­ti­ated and data can flow from any dir­ec­tion. Aggreg­a­tion is shown by hav­ing the dia­mond toward the whole — in this case a Course is made up of Course Offer­ings. The reas­on for this aggreg­a­tion would be to tell my developers that if they get rid of this Course, they’ll prob­ably have to do some­thing spe­cial with the Course Offer­ings. Depend­en­cies are shown as a dashed line. It’s say­ing that the regis­tra­tion man­ager depends upon the Sched­ule Algorithm to do some­thing. The Sched­ule Algorithm is either a para­met­er to one of the meth­ods or is declared loc­ally by one of the Meth­ods of the Regis­tra­tion Man­ager.
Mul­ti­pli­city and Nav­ig­a­tion
Mul­ti­pli­city defines how many objects par­ti­cip­ate in a rela­tion­ship. It is the num­ber of instances of one class related to one instance of the oth­er class. For each asso­ci­ation and aggreg­a­tion, there are two mul­ti­pli­city decisions to make: one for each end of the rela­tion­ship. Mul­ti­pli­city is rep­res­en­ted as a num­ber and a * is used to rep­res­ent a mul­ti­pli­city of many.
Fig­ure 12: Mul­ti­pli­city and nav­ig­a­tion
One Pro­fess­or Object is related to zero-to-four Course Offer­ing Objects. One Course Offer­ing Object is related to exactly one Pro­fess­or Object. I use this to look at and ensure that this handles my require­ments. Can I be a Course Offer­ing and be team-taught by a bunch of pro­fess­ors? No, because this says I can only have one pro­fess­or. Can I be a pro­fess­or and be on sab­bat­ic­al? Yes, because this says I have a zero as pos­sible course load. I use mul­ti­pli­city quite often to help me start cap­tur­ing and imple­ment­ing my busi­ness rules. If you have, for example, a busi­ness rule that says you must have at least 3 stu­dents and no more than 10 for a course to be offered in a semester, these mul­ti­pli­city num­bers tell me I’ve incor­por­ated that busi­ness rule into this plan.
Nav­ig­a­tion is shown by an arrow, and although asso­ci­ations and aggreg­a­tions are bi-dir­ec­tion­al by default, it is often desir­able to restrict nav­ig­a­tion to one dir­ec­tion. When nav­ig­a­tion is restric­ted, an arrow­head is added to indic­ate the nav­ig­a­tion­al dir­ec­tion. One of the things I do dur­ing the ana­lys­is and design phases is look at what I want to be uni-dir­ec­tion­al. By put­ting the arrow into this dia­gram, I say that the Regis­tra­tion Man­ager can send a mes­sage to the Course, because it knows the Course exists. But the Course has no idea that the Regis­tra­tion Man­ager exists, so the Course can­not ini­ti­ate a mes­sage. Now data can flow between them; for instance the Regis­tra­tion Man­ager can ask the Course if it’s open and the Course can say that it is. But only the Regis­tra­tion Man­ager can start that con­ver­sa­tion.
Obvi­ously the goal here is to get as many arrows as you can by the time you’ve fin­ished design­ing, because it’s a much easi­er sys­tem to main­tain Inher­it­ance is shown with a tri­angle. This shows that the Pro­fess­or is a Regis­tra­tion User, as is the Stu­dent. Now, a word of warn­ing. Inher­it­ance is use­ful, how­ever, the goal is not to use as much inher­it­ance as your sys­tem will allow. I’ve seen some really bru­tal sys­tems where they had inher­it­ance 17-levels deep. If they changed one thing, it became a dis­aster. So the rule of thumb is to use inher­it­ance only when you truly do have an inher­it­ance situ­ation.
State Trans­ition Dia­grams
A state trans­ition dia­gram shows the life his­tory of a given class. It shows the events that cause a trans­ition from one state to another, and the actions that res­ult from a state change.
Fig­ure 14: State trans­ition dia­gram
I use state trans­ition dia­grams for object classes that typ­ic­ally have a lot of dynam­ic beha­vi­or. The but­ton is on … the but­ton is off; I’m not going to do a state chart for it. But object classes that have a lot of dynam­ic beha­vi­or, I’m prob­ably going to have to look into the states of the objects.
I start by show­ing a state, which is a roun­ded tri­angle. I can have start states, and I can have stop states, which are shown as bulls eyes. I can also have trans­itions between states, or guard trans­itions (things that hap­pen when only when a con­di­tion is true), or things that hap­pen when I’m inside the state. I look at this dia­gram and see the state trans­ition dia­gram for a course offer­ing. It starts in the ini­tial­iz­a­tion state, and I stay in that state until I get an ““add stu­dent”” mes­sage. When I get that mes­sage, I set my count of stu­dent to zero and I trans­ition to the Open state. You’ll see in Fig­ure 14 that I have an entry, and the reas­on why it’s there is that I have two ways of get­ting into that state. It says that no mat­ter how you come into the state, I want you to register the stu­dent. When I exit that state, the count changes to keep track of the num­ber of stu­dents in the course. I can keep adding stu­dents until I get to 10, and then I go to the Close state. Once the course is final­ized, I trans­ition to the stop state. No mat­ter where I am then, if I get the Can­cel Event trans­ition, I noti­fy my stu­dents and then trans­ition to the stop state.
For object classes that have a lot of dynam­ic beha­vi­or, it’s well worth it to do a state dia­gram to get a handle on everything that has to hap­pen. Ask your­self what hap­pens when I get a mes­sage? What do I do when I get the mes­sage? What mes­sages to I have to send? A lot of those mes­sages become oper­a­tions of the object class, as in this example where add a stu­dent is an oper­a­tion. A lot of these actions, like set­ting the count, incre­ment­ing the count, check­ing the count, these all become private oper­a­tions of that par­tic­u­lar object class and a state dia­gram is where I see that.
How do you know if you have a dynam­ic object class? Once again, go back to the sequence dia­grams. If you have an object class that’s on a lot of sequence dia­grams and it’s get­ting and send­ing a lot of mes­sages, that’s a good indic­a­tion it’s a fairly dynam­ic object class and it should prob­ably have a state chart for it. Also for aggreg­a­tions, where you have the whole of its parts, I do a state chart for every aggreg­ate whole. I do this mostly because that aggreg­ate whole is often respons­ible for man­aging the mes­saging, which makes it dynam­ic.
Com­pon­ent dia­grams
Of course no sys­tem can be built without tak­ing into account the phys­ic­al world. That’s where com­pon­ent dia­grams come in. They are used to illus­trate the organ­iz­a­tions and depend­en­cies among soft­ware com­pon­ents, includ­ing source code com­pon­ents, run time com­pon­ents, or an execut­able com­pon­ent. Com­pon­ents are shows as a large rect­angle with two smal­ler rect­angles on the side, as seen in Fig­ure 15.
Fig­ure 15: Com­pon­ents
Those round things rep­res­ent inter­faces (often called lol­li­pop nota­tion). In this case, they show that the Register.exe is depend­ent upon inter­faces to both the Course.dll and the People.dll. That means if these inter­faces change, it will impact the Register.exe. I know that there’s this rule when you’re build­ing inter­faces that says ““thou shall not change the inter­face.”” But does any­body actu­ally work where that rule is enforced? This dia­gram tells us what inter­faces are used by what execut­ables are run­ning on my pro­cessors.
Fig­ure 16: Deploy­ment dia­gram
Extend­ing UML
The last thing I want to stress about the UML is that it can be exten­ded. When they built the UML, they very wisely real­ized that there was no way they could cre­ate a nota­tion that could please all of the people all of the time. So they gave us the con­cept of a ste­reo­type. A ste­reo­type says I can take a basic mod­el­ing ele­ment and give it more mean­ing. Ste­reo­types may be used to clas­si­fy and extend asso­ci­ations, inher­it­ance rela­tion­ships, classes, and com­pon­ents.
Fig­ure 17: Web ste­reo­type example
Fig­ure 17 shows the dia­gram of our Web ste­reo­types. A Web page typ­ic­ally has stuff that runs on the server and stuff that runs on the cli­ent. If you’re build­ing Web-based applic­a­tions, what’s run­ning on the cli­ent and the server is of vital import­ance. So we have a whole set of ste­reo­types that show that. The little wheels rep­res­ent things that run on the server. So just by look­ing at this one dia­gram I can see what runs on the server, what runs on the cli­ent, and what busi­ness objects they have to deal with.

“ —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — —