|
|
|
3.3 Types, Implementation Classes, and InterfacesThe kinds of classes discussed thus far are known as undifferentiated classes, and are commonly used during design activities within a development process. You can also differentiate between three different kinds of classes, called differentiated classes. These include:
These differentiated classes closely relate to different activities in the development process. The next few sections discuss these differentiated classes. 3.3.1 TypesA type is a class that may have attributes, associations, and operations, but does not have any methods. A type defines a role an object may play relative to other objects, similar to how a rolename indicates the role a class plays relative to other classes in an association. For example, a Worker object may play the role of a project manager, resource manager, human resource, or system administrator. A type is shown as a class marked with the type keyword. These types of workers are shown in Figure 3-25. Figure 3-25. Types Types are commonly used during analysis activities within a development process to identify the kinds of objects a system may require. You can think of types as conceptual classes, because they are ideas for possible classes. Also, because types do not have methods and represent roles only, they do not have instances. Types may be used with binary and n-ary association and link ends. A comma-separated list of one or more type names may be placed following a rolename to indicate the roles a class or object plays in the relationship. Separate the rolename from the list of types using a colon. If no rolename is used, the type names are placed following a colon. Figure 3-26 uses the types from Figure 3-25 to update Figure 3-13. It shows the various roles a worker may play relative to work products and units of work. A worker may be a project manager, resource manager, human resource, and system administrator. Figure 3-26. Types with association ends 3.3.2 Implementation ClassesAn implementation class is a class that may have attributes, associations, operations, and methods. An implementation class defines the physical implementation of objects of a class. For example, if you were to implement our classes in a database management system, the Worker class might be implemented as an employee table, the WorkProduct class might be implemented as an artifact table, and the UnitOfWork class might be implemented as work order table. An implementation class is shown as a class marked with the implementationClass keyword. The three implementation classes just mentioned are shown in Figure 3-27. Figure 3-27. Implementation classes Implementation classes are commonly used during the later part of design and during implementation activities within a development process to identify how objects are implemented for a system. You can think about implementation classes as physical "code" classes because, they are physical implementations of classes. 3.3.3 InterfacesAn interface is a class that may have operations but may not have attributes, associations, or methods. An interface defines a service or contract as a collection of public operations. For example, a project manager must be able to initiate and terminate a project, plan and manage a project while leading a team, and so forth. A resource manager must be able to assign and unassign human resources to and from a team. A work product must be producible and consumable; it is produced by being created or written, and consumed by being read or destroyed. Interfaces can be used to define these collections of operations. An interface is shown as a class marked with the interface keyword, and because interfaces don't have attributes, the second compartment is always empty and, therefore, not shown. An interface also may be shown as a small circle with the interface name placed near the symbol and the operations of the interface not shown. Examples of both interface representations are shown in Figure 3-28. Figure 3-28. Interfaces Interfaces are commonly used during analysis and design activities within a development process to identify services that classes and their objects provide. You can think of interfaces as application programming interfaces (APIs), because they define a collection of operations that are commonly used together and thus define a more general service. Because interfaces do not have methods but merely represent services, they do not have instances. Interfaces may be used with binary and n-ary association and link ends to indicate the services (or interfaces) that a class provides in the relationship. Begin with a rolename followed by a colon, then add a comma-separated list of one or more interface names, as shown in Figure 3-29. Figure 3-29 uses the interfaces from Figure 3-28 to update Figure 3-26. It shows the various services a work product provides to units of work, including an interface for consumption of the work product and an interface for production of the work product. It also shows the various interfaces a worker provides in association with work products and units of work. Interfaces and types may be listed together, but types are more commonly used during analysis activities, while interfaces are more commonly used during analysis and design activities. Because both interfaces and types may be used during analysis and design, it is very important to have a standard naming convention. For example, one convention is to prefix interfaces with an I and to prefix types with a T. Figure 3-29. Interfaces with association ends |
|
|
|