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
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
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,
ItemSource was the interface,
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 the
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.
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.
5 Responses to “Introduction to UML2 Component Diagrams: NoTooMi overall system design”
Leave a Response
You must be logged in to post a comment.