UML was introduced in the previous slides. These slides will provide an overview to UML and introduce CRC (Class Responsibility Collaborator) cards. Basic guidelines to Object Oriented Analysis and Design are provided. In addition, an example design will be provided on-line with some of the resulting digrams. The in-class case study will be described and the Artisan Real-Time Studio software will be demonstrated.
Larman (Applying UML & Patterns, An Introduction To Object Oriented Analysis & Design) states "The most single important ability in object-oriented analysis and design is to skillfully assign responsibilities to software components".
The choice of responsibilities affects robustness, maintainability, and reusability, of software components.
Two renowned Smalltalk programmers from Tektronix in 1980 came up with a simple method to teach key ideas in object technology. The CRC cards while not specifically a part of UML are directly usable with it.
Use CRC cards to help explore an interaction between classes, typically to show how a scenario is implemented. After it is figured out, document it with a UML interaction diagram.
There are obstacles to the OO paradigm shift.
This section uses a simple case study as an example. Briefly, this case study is a next generation Point Of Sale system (POS). A POS system is a computerized application used (in part) to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as third-party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments (so that the business is not crippled).
A POS system increasingly must support multiple and varied client-side terminals and interfaces. These include a thin-client Web browser terminal, a regular personal computer with something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and so forth.
Furthermore, we are creating a commercial POS system that we will sell to different clients with disparate needs in terms of business rule processing. Each client will desire a unique set of logic to execute at certain predictable points in scenarios of using the system, such as when a new sale is initiated or when a new line item is added. Therefore, we will need a mechanism to provide this flexibility and customization.
Figure showing sample layers and objects in an object-oriented system for the case study.
A partial Domain Model is provided for reference.
Nine fundamental responsibility assignment principles (from GRASP patterns) General Responsibility Assignment Software Patterns:
Assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility. Given the following partial domain model for the POS case study, the question to ask is Who should be responsible for knowing the grand total of the sale?
Associations of Sale By Information Expert, we should look for that class of objects that has the information needed to determine the total. The above picture is the Domain Model. If a Design Model is not available, you would look here and attempt to use (or expand) the representations to inspire the creation of corresponding design classes.
What information is needed to determine the grand total? It is necessary to know about all the SalesLineItem instances of a sale and the sum of their subtotals. A Sale instance contains these; therefore, by the guideline of Information Expert, Sale is a suitable class of object for this responsibility; it is an information expert for the work. We add a getTotal() method to the Sale class. But, we defined a subtotal and now we need to ask what information is needed to determine the line item subtotal? SalesLineItem.quantity and ProductSpecification.price are needed. The SalesLineItem knows its quantity and its associated ProductSpecification; therefore, by Expert, SalesLineItem should determine the subtotal; it is the information expert. We therefore add a new method getSubtotal() to the SalesLineItem class. The following table summarizes these responsibilities.
In object-oriented software land, all software objects are "alive" or "animate", and they can take on responsibilities and do things. Some synonyms for the Information Expert are:
Assign class B the responsibility to create an instance of class A if one of the following is true:
Assign a responsibility so that coupling remains low. Choose low coupling as compared to high coupling. Sub-class inheritance is a form of strong (bad) coupling. But, too little coupling is also bad!
Assign a responsibility so that cohesion remains high. Same figures hold. If Sale creates payment, then the cohesion of all remains high.
Assign the responsibility for handling a system event message to a class representing one of the following choices:
When related alternatives or behaviors vary by type (class), assign responsibility for behavior -- using polymorphic operations -- to the types for which the behavior varies.
Corollary: Do not test for the type of an object and use conditional logic to perform varying alternatives based on type.
Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.
Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept -- something made up, to support high cohesion, low coupling, and reuse.
Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
A use case is a set of scenarios tied together by a common user goal. A scenario is a squence of steps describing an interaction between a user and a system. So if we have a Web-based on-line store, we might have a Buy a Product scenario that would say this: The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up email. The scenario is one thing that can happen. However, the credit card authorization might fail. This would be a separate scenario.
A simple format for capturing a use case involves describing its
primary scenario as a sequence of numbered steps and the
alternatives as variations on that sequence. An example follows:
Buy A Product
See the Figure.
We introduced the concept of an object previous courses. But here is a brief overview related to Artisan.
Booch (1996) identifies four major elements of Object Orientation
An object is something which you can do things to and which can do things for you! It is a package of data and functionality, that bind together to fulfill a coherent set of responsibilities. Each object has a unique identity.
An event is an asynchronous occurrence in the real world, which is or relevance to the system being built. An input event is one which the system accepts from the real world and responds to; and output event is one which the system generates in order to effect the real world. Input events are of three types:
As systems become larger and in cases where the system is being assembled from a number of smaller systems (sometimes called components), it is useful to view the system as a set of services and clients in a service-based architecture. Typical service categroies are:
Traditionally, objects have been seen as homogeneous, i.e. an object is an object and may have any types of responsibility. Current thinking has suggested that actually there are three primary stereotypes of object. Originally, this classification came from the Model/View/Controller paradigms in Smalltalk, but more recently Jacobson (Jacobson, 1992) has suggested the stereotypes entity, interface and control, and these seem to have been readily adopted.
