You may think that Components and Packages are the same. They are not. Components are the architecture equivalent to your domain concepts. Packages are how you are going to structure your code, in order to implement the components.

If you ask a software developer to describe any slightly larger piece of software, they are going to answer you in terms of components.

"So, how does a file sever work?"

"Well, you have a networked filesystem protocol, who passes on requests to a cache component. If the file is not in the cache, you would go to a filesystem component, who would use an internal map of where the files are stored on the physical medium, and then it would use a hardware access component to actually read and write to the physical media."

"What about a warehouse management system?"

"There's a user interface, connected to a warehouse component who keeps track of all the floors and what conditions each part of each floor has. You have one inventory component that deals with the actual goods. Then you have a truck management component to access the trucks in order to move stuff around. You also have an ordering system that basically does all the tedious work of finding a truck to move parts of the inventory around in the warehouse."

See? It's just as when you were looking for concepts, each noun is a potential component. The difference here is that the components represent some rather large ideas, that you are going to have to break down into much smaller concepts in order to be able to program things.

From Components to Modules

What about Modules, then? Look at the filesystem description again. You may realise that:

There are many types of networked filesystems, and you want to be able to implement each of them separately.
There are many types of filesystems, and if you are going to support this, you want to be able to implement each of them separately.
You are going to need a high-speed connection between your cache and your networked filesystem to be able to actually pass requests and files around.
Files? Why were they not mentioned as a component? Are directories the same as files? What about symbolic links or aliases?
How do you keep your SCSI and your IDE code separated?
Can you use the same type of caching for all types of filesystems? Do journalling filesystems not require a different type of cache?

(This is not an exhaustive list, it's just to give you a flavour of why you need to think about components and modules differently).

The solution to your realisations above is that there is not necessarily a one-to-one mapping between your problem domain (as expressed by your components) and your implementation. That's why you need Modules.

So what is a Module?

A module has a name and consists of a collection of classes (and their connections) dealing with a particular piece of functionality, in a particular way.

How do I express modules in UML?

I like how you think. What we are going to use is the UML Package notation. A Package has a name and consists of a collection of classes (and their connections).

Rather than talking about it, let me show you:

package example

This is a (class and) package diagram for the warehouse management system mentioned earlier (It is by no means complete, it's just to give you enough details so that I can describe some important features of it). This system is a three-layered system, even if it is a bit difficult to see because the storage layer got crunched up underneath "Truck Controls". We have the following three layers:

User Interface
Business Logic, consisting of the packages Warehouse Management, Truck Controls, and Inventory,
Storage

I don't want to spend too much time wording about the User Interface layer, since the precise classes and their relationships that are needed here depends, to some extent, on which framework (if any) I am going to use for this system. So instead, I leave it vague with a few packages that essentially tells us that there will be some form of selection between different warehouses, some form of view of a warehouse, management of trucks, and management of goods.

The business logic layer is slightly more detailed. Not the least because I have stuffed three different packages into it. I could have added a package called "Business Logic" around all three of them to make this even clearer, but it is just as ok to have them separate like this.

Do note that a package may be empty (meaning the contents will be specified later or in a separate diagram), it may contain a class diagram, and it may contain nested packages.

Also note that there is nothing prohibiting us from adding relationships between classes (and/or packages) that are not part of the same package. It is generally discouraged since it means that you tangle things together so that it is more difficult to develop, understand, or re-use.

There are exceptions to this; packages have one or several classes that acts as the interface towards the package. If I am on the outside and want to use the package in some way, I will do this through these interface classes.

For example the package "Inventory" has the interface class "InventoryManager". Some parts of the system also access the "Goods" class so that is also part of the interface. We should, however, try to avoid making all the sub-classes to "Goods" part of the interface, so that we don't require other packages to depend too much on the inner workings of our Inventory package.

Layers, Packages and the Design Process

It is in the business logic layer that you spend most of the time doing detailed UML designs. We will come back to good principles for doing this, but for the sake of the design process it is important that you understand that most of your design work will be done underneath your user interface.

Connecting back to the Use Cases and Use Case Diagrams. When the actor enters information into the system (remember the table under "main course of events" with actor on one side and system on the other), this happens in some form of user interface. But when the actor does something that initiates a response from the system, you are generating an event that is passed down to the layer below the user interface layer (in this case, the business logic layer and one of the packages there).

This event is expressed as a method call to one of the interface classes. If, in a use case, an actor "requests a list of all available warehouses" and the "system presents a list of available warehouses", this is an event. Since it is not an event that happens inside the system, but is something that happens to the system as a whole, we may call it a system event. Specifically, this system event is that a User calls the method listWarehouses() on an object of the type WarehouseManager:

This is something we will also get back to. We can, in fact, use the dynamic behaviour (who does or calls what) of the system in order to figure out what is the smallest possible product we need to build.

Again, note that the user interface is not modelled. Instead, we jump straight to the next layer.

Incidentally, this gives us a very powerful tool for splitting up our work and being able to concentrate on one package at the time. Instead of wondering "how do we get to this point", we assume that "things outside our package happens. Once they are done, they call this method in our package, and that's what we need to focus on". Then it does not matter if we are called directly from the user interface, or at the bottom of some elaborate call stack umpteen layers removed from the user.

What happened to the Components?

If you do a larger software architecture, there are some engineering concerns that are best dealt with by thinking of the system as connected components, and other engineering concerns where a module view is more appropriate. For this course, however, you can safely focus on the module/package view of things since things will not become large enough for you to worry about components.

If you must know, the trick is that you start designing your architecture on a conceptual level using components and connectors.

Once you are reasonably sure that you have components that can work together to deliver the desired functionality and they are connected so that you can meet your quality requirements, you start thinking on how to implement this system, starting with a one-to-one mapping between components and modules.

Then you start adding more modules to deal with e.g. variability (that you may have several instances of the same conceptual component (like the filesystem)), split modules in order to split or share functionality between a client and a server, and so on.