The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Getting Started

It wouldn't make a lot of sense to design a house that required you to rip up the foundation every time you needed to repaint the walls. Similarly, you wouldn't want to live in a place that required you to rewire the building whenever you needed to change a light bulb. The owner of a high rise wouldn't be thrilled to have to move doors or replace all electrical and phone jacks whenever a new tenant moved in.

Centuries of building experience have provided lots of pragmatic construction-related information to help builders avoid these obviousand some not so obviousproblems that arise when a building grows and changes over time. In software terms, we call this designing with a clear separation of concerns. For example, in a well-structured building, the skin or facade of the structure can be modified or replaced without disturbing the rest of the building. Similarly, the furnishings inside a building can easily be moved about without changing the infrastructure. Services that run through the walls for electrical, heating, plumbing, and waste disposal facilities can be changed with some degree of scrap and rework, but you still don't have to rend the fabric of the building to do so.

Not only do standard building practices help you build buildings that can evolve over time, but there are many standard interfaces to which you can build, permitting you to use common, off-the-shelf components whose use ultimately helps reduce the cost of construction and maintenance. For example, there are standard sizes for lumber, making it easy to build walls that are multiples of a common size. There are standard sizes of doors and windows, which means that you don't have to hand-craft every opening in your building. There are even standards for electrical outlets and telephone plugs (although these vary from country to country) that make it easier for you to mix and match electronic equipment.

In software, it's important to build systems with a clear separation of concerns so that as the system evolves, changes in one part of the system don't ripple through, damaging other parts of the system. One important way of achieving this degree of separation is by specifying clear seams in your system, which draw a line between those parts that may change independently. Furthermore, by choosing the right interfaces, you can pick standard components, libraries, and frameworks to implement those interfaces without having to build them yourself. As you discover better implementations, you can replace the old ones without disturbing their users.

In the UML, you use interfaces to model the seams in a system. An interface is a collection of operations used to specify a service of a class or a component. By declaring an interface, you can state the desired behavior of an abstraction independent of an implementation of that abstraction. Clients can build against that interface, and you can build or buy any implementation of that interface as long as the implementation satisfies the responsibilities and the contract denoted by the interface.

Many programming languages support the concept of interfaces, including Java and CORBA IDL. Interfaces are not only important for dividing the specification and the implementation of a class or component, but as you scale up to larger systems, you can use interfaces to specify the outside view of a package or subsystem.

The UML provides a graphical representation for interfaces, as Figure 11-1 shows. This notation permits you to visualize the specification of an abstraction apart from any implementation.