Chapter 4 UML Class Diagrams PDF

Virtually all newer approaches to system development begin the requirements modelling process with the concept of a use case. A use case is an activity the system performs, usually in response to a request by a user. The term use case originated with the object-oriented approach, but today it is als...

Virtually all newer approaches to system development begin the requirements modelling process with the concept of a use case. A use case is an activity the system performs, usually in response to a request by a user. The term use case originated with the object-oriented approach, but today it is also used when modelling functional requirements in the traditional approach. If you are focusing on the traditional approach in your studies, remember that a use case is the same as an activity or process. Note that each use case occurs in response to a business event. An event occurs at a specific time and place, can be described, and should be remembered by the system. Events drive or trigger all processing that a system does, so listing events and analysing them makes sense when you need to define system requirements by identifying use cases. An external event is an event that occurs outside the system—usually initiated by an external agent or actor. An external agent (or actor) is a person or organizational unit that supplies or receives data from the system. To identify the key external events, the analyst first tries to identify all the external agents that might want something from the system. A classic example of an external agent is a customer. The customer may want to place an order for one or more products. All approaches to system development include identifying and modelling domain classes or data entities as an important task in the analysis activity of defining functional requirements. Domain classes or data entities are what end users deal with when they do their work—for example, products, sales, shippers, shipments, and customers. These are often referred to as “things” in the context of a system’s problem domain. The problem domain is the specific area of the user’s business that is included within the scope of the new system. The new system involves working with and remembering these things. For example, some information systems need to store information about customers and products, so it is important for the analyst to identify all the essential information about them. Often, things are related to the people who interact with the system or to other stakeholders. For example, a customer is a person who places an order, but the system needs to store information about that customer, so a customer is also a thing in the problem domain. There are many techniques for identifying the important things in the problem domain that the system needs to remember. The UML class diagram is used to show classes of objects for a system. One type of UML class diagram that shows the things in the users’ problem domain is called the domain model class diagram. Another type of UML class diagram is called the design class diagram, and it is used when designing software classes. On a class diagram, rectangles represent classes, and the lines connecting the rectangles show the associations among classes. Figure 4-1 shows such a symbol for a single domain class: Customer. The domain class symbol is a rectangle with two sections. The top section contains the name of the class, and the bottom section lists the attributes of the class. Later, you will learn that the design class symbol includes a third section at the bottom for listing methods of the class; methods do not apply to problem domain classes. Class names and attribute names use camelback (sometimes called camelcase) notation, in which the words run together without a space or underscore. Class names begin with a capital letter; attribute names begin with a lowercase letter. Class diagrams are drawn by showing classes and associations among classes. With class diagrams, there are three types of relationships among classes of objects: association relationships (discussed previously), generalization/specialization relationships, and whole- part relationships. This section discusses generalization/specialization relationships and whole- part relationships and shows how they are represented in UML class diagrams. Generalization/specialization relationships are based on the idea that people classify things in terms of similarities and differences. Generalizations are judgments that group similar types of things. For example, there are several types of motor vehicles: cars, trucks, and tractors. All motor vehicles share certain general characteristics, so a motor vehicle is a more general class. Specializations are judgments that group different types of things. For example, special types of cars include sports cars, sedans, and sport utility vehicles. These types of cars are similar in some ways yet different in other ways. Therefore, a sports car is a special type of car. A generalization/specialization relationship is used to structure or rank these things from the more general to the more special. As discussed previously, classification refers to defining classes of things. Each class of things in the hierarchy might have a more general class above it, called a superclass. At the same time, a class might have a more specialized class below it, called a subclass. Inheritance allows subclasses to share characteristics of their superclass. It is a concept where specialization classes inherit characteristics of the generalization class. An abstract class is a class that only exists so subclasses can inherit from it. There is never an actual object simply called a Sale. Each sale must be one of the three subclasses. A concrete class is a class that does have actual objects. Sometimes, a superclass is abstract; sometimes, it is concrete depending on the intention of the analyst. Whole-part relationships Another way that people structure information about things is by defining them in terms of their parts. For example, learning about a computer system might involve recognizing that the computer is a collection of parts: processor, main memory, keyboard, disk storage, and monitor. A keyboard is not a special type of computer; it is part of a computer, but it is also something separate. Whole-part relationships are used to show an association between one class and other classes that are parts of that class. The whole acts as a container for the parts. These relationships are shown on a class diagram by a line with a diamond on one end. There are two types of whole-part relationships: aggregation and composition. Aggregation is a type of whole-part relationship in which the component parts also exist as individual objects apart from the aggregate. An aggregation is often described as a “has a” relationship. Aggregation provides a means of showing that the whole object is composed of the sum of its parts (other objects). In the student enrolment example (see Figure 4-9), the department has a course, and the course is for a department. This is a weaker relationship, because a department may be changed or removed, and the course may still exist. The diamond at the end of the relationship line is not filled in. Composition is a type of whole-part relationship in which the component parts cannot exist as individual objects apart from the total composition. Composition, a whole/part relationship in which the whole has a responsibility for the part, is a stronger relationship, and is usually shown with a filled-in diamond. If the whole is deleted, all parts are deleted. Attribute visibility: Visibility denotes whether other objects can directly access the attribute. (A + sign indicates that an attribute is visible, or public, and a – sign means that it is not visible, or private.)