Introduction to UML2 Component Diagrams: NoTooMi overall system design
The first thing we need to do before we do any building of anything for NoTooMi is the design — and I don’t mean how it looks – so let’s do that. That means that today we’re going to talk about UML Component Diagrams.
The Unified Modeling Language (UML) was designed to create a sort of “common vocabulary” that programmers and engineers could use to document their systems, as well as the business processes behind them. (There are also tools that will go back and forth between the diagrams and working code, but for the moment, at least, we’re going to stick with the diagrams themselves.) The current version, UML 2.1.2, defines thirteen types of diagrams, organized into two main types:
Structure diagrams: These diagrams take a static look at the system, or at pieces of the system. Class and component diagrams fall into this category.
Behavior diagrams: These diagrams look at how pieces of a system operate. For example, use case and activity diagrams fall into this category. This category gets further broken down into interaction diagrams.
For the moment, we’re going to start simply, and look at component diagrams, in order to get an overall look at how NoTooMi is going to work. This post won’t teach you everything you need to know about UML, but it will give you enough of a head start on component diagrams that if you ever need to read one, you’ll have some decent footing.
What is a component?
There’s a lot of potential for confusion when we start talking about “components”. Do we mean a COM object? A particular piece of software? A piece of hardware? No, in UML, a “component” is a logical construct that basically means a self-contained bit of functionality that can be pulled out and replaced without rewriting the rest of the software.
For example, I recently wrote a system that, as a small part of what it does, takes a directory in an SVN repository, processes the files, and drops the processed files into another directory to be displayed by another process. The way I built it, each one of those processes were independent of each other; if we want to go to Git instead of SVN, we can do that without affecting the code that processes the files or displays the results. Similarly, we can completely change how the files are processed without affecting storage or the display, and so on.
So a UML 2 “component” is a unit of self-contained functionality.
UML 2 Component Notation
The actual component notation is pretty straightforward, even if larger diagrams can get complicated. For example, the main bit of business to deal with in this first sprint is to index Twitter content in the search engine, then display the results on command. If we generalize “Twitter” to “some information item source” — after all, we know we’re going to have different types of information — we wind up with a simple diagram like this:
As you can see, we have two boxes, Search Index and Item Source, that represent components. We know this because they have the component symbol in the upper left-hand corner. (There are other ways to note this in UML, but we’ll talk about that later, when we do class diagrams.)
Each one of these diagrams has two items coming from it. The round one, known as a “lolipop”, represents interfaces that are provided by the component. Note that when I say “interface” here, I mean it in the classic sense of “a way to interact with this component”, as opposed to the object-oriented sense of a template that classes implement. So the Search Index component provides a way to GetItems that have been indexed.
The second item is called a “socket” and represents interfaces that the component needs, and that need to be provided by other components. So in this case, we can see that the Search Index component needs the ItemAddition interface of another component. That interface is provided by the Item Source component, which itself needs the ScheduleRetrieval interface of another component, so it knows when to retrieve items to feed to the Search Index.
Finally, we need to “wire the components together”. As you can see, we have a dashed arrow that represents a “dependency relationship” in UML, and shows that the Search Index requires the Item Source.
Pretty straightforward. Now let’s see how it applies to the overall NoTooMi system.
The NoTooMi Component Diagram
Now that we’ve got the basics down, let’s look at the design for NoTooMi. The diagram works out like this:
Now, that’s a bit more complicated, but the general concepts are the same. We still have the Search Index, which is still requiring the ItemAddition interface from item sources. In this diagram, however, we’re seeing the more specific sources, Twitter, Email, and so on. (For you object oriented programmers out there, ItemSource was the interface, Twitter is the class. We’ll go into all of that in more detail when we do class diagrams.) As you can see, we’re also showing the more specific names for the interface provided by each component. You’ll also notice that our item sources have more than one interface specified as required.
OK, so let’s get to the specifics.
- We have a
Search Index, which in this case will be some variant of Apache Solr. - We’ll be indexing Tweets by using the Twitter Streams API, saving tweets to a file, then indexing the file on a regular schedule, which will (if all goes well) be specified by that particular variant of Apache Solr that I think we’ll be using.
- For emails, same thing; the system will pull emails from the server into POP accounts, then index the POP accounts and delete the messages.
- Ditto for RSS feeds; we’ll pull them, write them, index them, then delete them.
- For each of those sources, we’ll take the appropriate information and store it in
User Storageusing theUser Managementcomponent.
Now, I want to say a word to all those system engineers out there who are saying, “why are you storing all that on disk instead of indexing it directly? Solr can do that, you don’t need the extra step and resources.” In the end, you may very well be right about that, but my philosophy is to decouple these components as much as possible; if the Search Index slows down for some reason, I don’t want tweets backing up, causing us to have to drop the connection, restart, etc. And again, remember; I should be able to pop one of these components out and pop in a replacement without too much trouble.
As for the overall system, I’ve decided, at least for the moment, to build this on the Grails framework. As a general rule, I’m really not a fan of frameworks — the reasons are a topic for another time — but it seems, at least on the surface, to offer some benefits, which I’ll detail in another post.
Next Steps
So now we’ve created a UML component diagram that specifies the basic pieces of the NoTooMi system, showing what they provide, and what they need. We’ve covered the basic notation, including the component icon, the lolipop and socket notations, and the use of the dependency connector.
For more information on UML Component Diagrams, check out the following resources.
UML basics: The component diagram
Hey Nick,
José here, good to meet you today. Great stuff in your blog. It strikes me though that you are following a Scrum post with a UML one.
Don’t get me wrong, I do think that whatever works best for each of us is the way to go, but It seems that you are mixing old and new, being ‘new’ agile methods for project management, and ‘old’ a full design upfront exercise. How does that work out?
i am a big fan of fleshing out the design from examples, starting with runnable specs, but as I said, whatever works best for each developer!
Best of luck with the new projects that you are working on!
Hey, Jos!
Great class, thanks! Looking forward to doing more Open Wonderland stuff in the future.
As for your question, as I said when I started this thing out, I’m sort of feeling my way around some of these things; I’m a little set in my ways.
But it seems to me that even in an agile environment, you still need documentation so everyone knows what you’re building. How do *YOU* handle it?
—- Nick
IMHO, modeling and Agile can be “friends” (see Agile and Modeling / MDE : friends or foes? http://modeling-languages.com/blog/content/agile-and-modeling-mde-friends-or-foes)
UML is just a notation so it can be perfectly used in an agile context when used appropriately. It’s just a matter of incorporating agile principles also to your modeling!
Great pointer, Jordi! Puts into words a lot of things that I’ve been thinking, but haven’t been able to articulate. Thanks…
—- Nick
Heya, sorry for the late reply!
sure modeling and agile can work together… I use UML (mainly class diagrams) when I’m unfamiliar with a code base or when I have to explain it or walk through it with someone. I sketch it in a piece of paper (and generally use the wrong notation), but when the other guy (or myself) gets it, I generally throw it away… no need to keep it of file it because it’s likely to have changed the next time you want to use it, and no one is going to update it anyway.
But for what I gathered, in this case you are working on a new project and I think that by yourself, so the communication factor is not really a ‘factor’.
I’d say the same about using scrum… you generally use agile to facilitate communication among team members. Scrum meetings are a good way to know what’s going on and if someone is stuck and who can help out. Other figures there as the customer or the product owner keeps you in contact with what you are building… but in this case, it’s just you!
I find stickies and Kanban panels very useful. Any kind of visualisation technique to talks to you about the state of your project can be very helpful. Also XP techniques such as TDD (BDD) or continuous integration are helpful even if you are the only one coding.
But as I said, whatever works for you is always better!