1. This chapter discusses conceptual modeling patterns including high cohesion, specification classes, quantity, measure, strategy, composite, organizational hierarchy, account/transaction, range, and temporal patterns.
2. High cohesion is an important principle where a concept has only attributes and operations that are closely related to its meaning rather than belonging to other concepts.
3. Specification classes are used when an object needs to be distinguished from its specification, such as differentiating a book title from a physical copy of the book.
1. This chapter discusses conceptual modeling patterns including high cohesion, specification classes, quantity, measure, strategy, composite, organizational hierarchy, account/transaction, range, and temporal patterns.
2. High cohesion is an important principle where a concept has only attributes and operations that are closely related to its meaning rather than belonging to other concepts.
3. Specification classes are used when an object needs to be distinguished from its specification, such as differentiating a book title from a physical copy of the book.
1. This chapter discusses conceptual modeling patterns including high cohesion, specification classes, quantity, measure, strategy, composite, organizational hierarchy, account/transaction, range, and temporal patterns.
2. High cohesion is an important principle where a concept has only attributes and operations that are closely related to its meaning rather than belonging to other concepts.
3. Specification classes are used when an object needs to be distinguished from its specification, such as differentiating a book title from a physical copy of the book.
KEY TOPICS IN THIS CHAPTER 1. High cohesion 2. Specification classes 3. Quantity 4. Measure 5. Strategy 6. Composite 7. Organizational hierarchy 8. Account/transaction 9. Range 10. Temporal patterns High cohesion •High cohesion is so important for object-oriented modeling that it is considered more a principle or guideline axiom than a pattern itself •A concept with high cohesion is more stable and reusable than a concept with low cohesion, which can become rapidly confusing and hard to maintain Continue •Most systems could have all their information represented in a single table •concepts should not have attributes that belong to other concepts •e.g., a car should not have the owner’s ID as one of its attributes •Attributes also must not have class names or data structures (set, list, array, etc.) as data types Low cohesion •a class with that kind of attribute is probably representing more than one single concept •For example, an instance of Order should not have an itemsList attribute because items have their own attributes and associations; they should appear related to Order by a 1 to * association Customer address •When it was discovered that a customer could have more than one address, instead of the naive solution of creating attributes like address1, address2, etc. •we created a new concept (Address), which was associated to the customer. A class with low cohesion because attributes depend on each other
A modeling solution with high-cohesion classes.
A class with low cohesion because it has attributes that repeat values in different instances.
A model for the example with high-cohesion classes.
Specification classes A special case of low cohesion happens when an object is confused with its specification. That situation is very frequent: sometimes, products or physical items share a common specification, while their exemplars may have some differences among them One example of specification already discussed in the Livir example is the difference between the concept of a book as a published title, and a book as a physical copy of a published title. A class and its specification class. •Conservation State 1. new, 2. used, 3. damaged Quantity •Frequently the team faces the need to model quantities that are not merely numbers •For example, The weight of a book could be defined as 400. But 400 what? Grams? Pounds? Kilos? One solution is to define a specific type for the weight (Pounds, for example) Definition and use of Quantity Measure •An evolution of the quantity pattern is the measure pattern, which can be used when a number of different measures over an object must be taken possibly at different times For example, a person in observation at a hospital may have many measures taken from time to time: body temperature, blood pressure, blood glucose level , etc. •Thousands of different measures could be taken, but usually just a few are actually taken for each patient Definition and use of the measure pattern. Strategy •It was mentioned that one of the great requirements challenges is to manage their change •Transitory requirements must especially be accommodated in the system design so that when they change the impact to the system, is minimized •Some cases are relatively easy to address. For example, if it is already decided that the system must operate in different countries, the quantity pattern could be used to deal with currency and other measures that may vary from country to country •But there are much more complicated situations. For example, the tax calculation procedure may vary a lot from country to country and even from state to state in some countries. •There are some taxes that are calculated in relation to the profit, others with regard to the selling price, and so on •The strategy pattern suggests that in these cases, the procedure (e.g., calculate taxes or discount) must be separated from the data to which it applies •The solution proposed by the strategy pattern is to create an abstract class associated to the order. This abstract class may have concrete subclasses that represent concrete discount policies, as shown in Figure Strategy pattern Composite •sometimes different strategies must be grouped and a combination or selection of them must be applied •The combination of different discount strategies can be obtained, for example, by the sum of the values obtained for the derived attribute amount for each individual strategy, or by choosing the highest or lowest values among them Organizational hierarchy •represent organizational hierarchies •represent the administrative organization of a company as a composition hierarchy •First fig usually do not behave well 1. this kind of organization is not followed by every company 2. the company structure may change over time 3. different views of an organization may exist at the same time •The solution consists of not considering the different levels of an organization as concepts, but •as instances of a single concept, as shown in fig 2 1. flexibility is gained related to dealing simultaneously with organizational structures from different companies 2. eventual changes in the organizational structure, such as adding more levels, or changing dependencies, may be easier to accomplish Object joining •One of the team’s assumptions that usually fails is that users will do everything right •A user could, for example, register a new publisher in the system, and later discover that it was already registered •Entering an incorrect code or the impossibility of having a unique identification for a real world object may cause this situation •The result is that two objects are registered in the system, both representing the same publisher, and each of them may possibly have its own set of books associated, some repeated, some not solution •The solution when this kind of error happens is to join the objects, usually copying one over the other •This operation can be performed directly within the database or a user feature solution •Copy and replace •Superseding •Essence/Appearance •Undoing a join Copy and replace
•The first strategy that comes to mind
when it is necessary to join two objects consists of copying the data of one object over the second (copy and replace) Superseding •Superseding is a technique that can be used when the original object must be kept and not destroyed. Superseding is applicable, for example, in the case of organizational structures that are succeeded in time. •Suppose that the departments of marketing and sales are joined into a single •department of customer contact; the original departments must be marked as no longer active, and •a new department must be added as their successor. The superseding strategy may be implemented •by a reflexive association, as shown in Figure Essence/Appearance •existence of objects that are considered equivalent but must be kept as separated objects •same book in essence: published by different publishers Essence/Appearance technique. Undoing a join •Just when you think that the real world cannot be more complex, it becomes so. Therefore, if there is a possibility of joining objects, it is also possible that joined objects must be separated again •these commands may be performed directly in the database, or system’s user interface •To allow the joins of the copy/replace technique to be undone, a backup of the original objects must be kept, because the technique destroys one of the objects and disfigures the other Account/Transaction •The account/transaction pattern is closely related to business, but it has wide applicability •The books may be cataloged, ordered, received, delivered, discarded, etc. •each one with its own attributes and associations •it is possible to identify a common core for all these concepts Definition of Account •An Account is a concept that bears quantities of something (such as items, products, or money). •An Account has a balance that usually consists of the sum of every deposit or withdrawal •deposits and withdrawals are usually just entries of goods or money from an account to another •a Transaction consists of two entries: a deposit in one account and a withdrawal of the same value in another account. Classes for the account/transaction pattern. •bookstore example could be modeled from a set of instances of class Account, such as 1. publisher Account 2. account for orders expected 3. account for stock containing the available books 4. account for sold books containing books sold but not yet delivered 5. account for delivered books containing books delivered but not yet confirmed by the customer Temporal patterns •Frequently the analyst faces the need to deal with time. 1. Effectivity 2. History 3. Temporal 4. Bitemporal Effectivity •When an object is valid for some time (for example, a temperature measure, which has a time it was taken and a time it is considered valid), then the effectivity pattern may be used. It consists of declaring an effective attribute in the class History •If historical information has to be stored about the past states of an association, then the history association pattern may be used. This kind of association may be identified by the stereotype <<history>> An example of the history association pattern.
Concrete model for the <<history>> stereotype.
Temporal •The history association pattern is not capable of answering what the job of a person was at a given date, or if a person was unemployed in the past. In order to represent that kind of information, an evolution of that pattern may be used: an association that in addition to sequential memory also has time memory A temporal association.
A possible implementation of the <<temporal>> stereotype.
Bitemporal •Time may be considered two- dimensional. There is a dimension of time in which events occur and another dimension where we acknowledge that an event occurred. A bitemporal association.