Lecture Outlines for Com S 362 ------------------------------------------------ USE CASES Why? To discover and record functional requirements. When? Requirement Analysis, Elicitation, but definitely before we move from the problem world to the solution world. What? Text stories. Describe some actor using a system to meet some goals. ------------------------------------------------ Examples for this class: Patient Monitoring Problem - A machine for patient monitoring is required for the ICU (intensive care unit) in a hospital. Each patient is monitored by an analog device, which measures factors such as pulse, temperature, blood pressure, and skin resistance. The machine should read these factors on a periodic basis and record the factors. For each patient, medical staff also specifies safe ranges for each factor. If a factor falls outside a patient's safe range, or if an analog device fails, the nurses' station is notified. From: G J Myers and L L Constantine, Structured Design, IBM Systems Journal, Volume 13, Number 2, pages 115-139, 1974. ------------------------------------------------ Library Administration Problem - A system is needed to administer a lending library. Membership is required to borrow books, but not for reading them in the library premises. Books may be ordered and can be obtained from associated libraries. Overdue books incur fines. Various management reports are required. From: R. A. Kemmerer, Testing Formal Specifications to Detect Design Errors, IEEE Transactions on Software Engineering, Volume SE-11, Number 1, pages 32-42, January 1985. ------------------------------------------------ Example Use Cases for the Patient-Monitoring Machine: A nurse arrives at the nurses' station and specifies the safe range for the pulse rate to be between 18 and 300 pulses per minute. A patients' pulse is being monitored. The pulse reader measures the pulse rate to be 85 pulses per minute. The monitoring machine records the current time and pulse rate. The pulse reader measures the pulse rate to be 17 pulses per minute. The monitoring machine notifies the nurses' station. It also records the current time and pulse rate. ------------------------------------------------ Example Use Cases for the Library Administration Machine: A library member approaches the library administration machine with books to borrow. The librarian asks the member to enter membership information. The member enters membership information, which the machine validates. The librarian uses the library administration machine to record each borrowed book. The machine updates the library catalog. The member receives a receipt from the machine with book due dates and then leaves with the books. A library member approaches the library administration machine with books to return. The librarian uses the library administration machine to record each returned book. The machine updates the library catalog. The member receives a confirmation receipt from the machine and leaves. ------------------------------------------------ Actor: - An entity with behavior - Exercise: Identify actors in the example use cases - Often you can identify by selecting nouns Scenario: - Specific sequence of actions - Involved parties are "actors" and the "machine" - Depicts one particular usage of the system - For example, nurse specifying the range of pulse is a scenario for the patient monitoring machine. The machine checking the patients' pulse is another scenario for the same machine. Librarian checking out a book for a member is one scenario for the library administration machine. Librarian checking in a book for a member is another scenario for the same machine. - Two type of scenarios: - Success Scenario - Failure Scenario ------------------------------------------------ Three Kinds of Actors: Primary: One who uses the machine to fulfill goals Supporting Actor: Provides a service to machine so that the machine can fulfill Primary Actors' goals Offstage Actor: Has an interest in the behavior of the use case Example from Patient Monitoring System: Primary Actor: 1. Patient 2. Nurse Supporting Actor: 1. Possibly some record of safe ranges Offstage Actor: 1. FDA 2. Hospital Administration ------------------------------------------------ Example from Library Administration System Primary Actor: 1. Member 2. Librarian Supporting Actor: 1. Library Administration System of the associated libraries. Offstage Actor: 1. Title 17 of the United States Code (Copyright Law) ------------------------------------------------ How to write Use Cases? Brief: One paragraph summary, usually the main success scenario is covered. Casual: Informal paragraph format. Multiple paragraphs. More then one scenarios are covered. Fully Dressed: Detailed description. All steps, variations, etc. In this class, generally we will follow casual style of writing use cases. Although, it might be worthwhile to practice writing a fully dressed use case. ------------------------------------------------ EXAMPLE USE CASES Example # 1 Library Administration Problem - A system is needed to administer a lending library. Membership is required to borrow books, but not for reading them in the library premises. Books may be ordered and can be obtained from associated libraries. Overdue books incur fines. Various management reports are required. Use Case for the Library Administration Machine in casual format: Actors: Primary - Library member (patron), Librarian Secondary - Book record, other similar systems at different libraries Offstage - US Copyright law (title 17) Success Scenarios #1: A patron approaches the library administration machine with books to borrow. The patron enters her/his membership information. The machine verifies the membership information. The patrons enters the book information. The machine updates the library catalog to reflect that the book is checked out. The machine outputs a receipt containing the due date. The patron receives a receipt from the machine. #2: A patron approaches the library administration machine with books to return. The patrons enters the book information. The machine updates the library catalog to reflect that the book is returned. The machine outputs a receipt confirming that the book is returned. The patron receives a receipt from the machine. Alternate Scenarios #1: A patron approaches the library administration machine. The patron enters her/his membership information. The machine verifies the membership information. The machine determines that the patron has overdue books that are accumulating fines. The machine outputs this information and asks the patron to pay the fine. The patron decides to pay the fine. The machine updates patrons' record to reflect that the fines are paid. The machine outputs a confirmation of the paid fines. #2: A patron approaches the library administration machine. The patron enters her/his membership information. The machines verifies the membership information. The machine determines that the patrons' borrowing privileges have been suspended. The machine outputs this information and asks the patron to go see a librarian. The machine updates patrons' record to reflect that they have been notified. ------------------------------------------------ Example # 2 Patient Monitoring Problem - A machine for patient monitoring is required for the ICU (intensive care unit) in a hospital. Each patient is monitored by an analog device, which measures factors such as pulse, temperature, blood pressure, and skin resistance. The machine should read these factors on a periodic basis and record the factors. For each patient, medical staff also specifies safe ranges for each factor. If a factor falls outside a patient's safe range, or if an analog device fails, the nurses' station is notified. Use Case for the Patient-Monitoring Machine in casual format: Actors: Primary - Patient through Pulse Reader, Patient through temperature reader, Patient through blood pressure reader, Nurse Secondary - Record of safe ranges Offstage - FDA, Hospital Administration Success Scenarios #1: A nurse arrives at the nurses' station and specifies the safe range for the pulse rate for a patient to be between 18 and 300 pulses per minute. #2: A patients' pulse is being monitored. The pulse reader measures the pulse rate to be 85 pulses per minute. The monitoring machine records the current time and pulse rate. Alternate Scenarios #1: The pulse reader measures the pulse rate to be 17 pulses per minute. The monitoring machine notifies the nurses' station. It also records the current time and pulse rate. ------------------------------------------------- DOMAIN MODELS Why Object-orientation? Activities during the lifetime of a program - Construction - Reuse (in case of libraries) - Bug fixes - Feature addition/enhancement - Porting (across architecture, across applications, e.g. Access to MySQL, across languages, e.g. unsafe C to safe Java) ---------- Except the first activity, other activities involve understanding the behavior of a program otherwise known as "program comprehension". Program comprehension is known to consume 30-70% of software development efforts during maintenance. Therefore, it makes sense to construct programs in a way that eases maintenance activities, which in turn means that programs are constructed in a way that makes it easier to understand them. --------- Q - Where do programmers start comprehension process? --------- Q - Why do programmers try to comprehend a program? >>> Go back to the activities in the lifetime of a program. - Often comprehension starts with domain requests e.g. bug raised by users. Enhancements requests by users in domain terms - Does that mean that program comprehension is often linked to domain terms? --------- Q - Mapping between software artifacts at various levels - 1-to-1 mapping is usually easier to follow, whereas 1-to-many or many-to-1 are sometime difficult. ---------- Domain Model: illustration of noteworthy concepts in domain. When: Often constructed during object-oriented analysis Why: - Understandability: Analyst is not familiar with the domain. These models help to understand the concepts in the domain and also to document relationship between concepts. - Helps lower representational gap between domain and software What: A visual representation of conceptual classes or real-situation objects in a domain. Also, referred to as the visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain. Domain Models consists of: - Conceptual classes - Attributes of these conceptual classes - Association between these conceptual classes What is not part of a domain model? - Software objects such as GUI window, database, threads, etc > except when you are modeling software concepts - Responsibilities/methods Conceptual Classes: An idea, thing or object in the domain. Often understood in terms of its symbol, intension, and extension. Symbol: word or images representing a conceptual class. Intension: the definition of a conceptual class. Extension: the set of examples to which the conceptual class applies. Finding Conceptual Classes: - Reuse or modify existing models - Use a category list - Identify noun phrases ------------------------------------------------- RESPONSIBILITIES A responsibility is "a contract or obligation". Two basic types of responsibilities an object may have: A. doing - something by itself: creating objects, calculating - telling others to do something initiating action coordinating activities B. knowing - some private data - about related objects - about things it can calculate ------------------------------------------ Exercise: Is a responsibility the same thing as a method? ------------------------------------------ GRASP Patterns INFORMATION EXPERT ------------------ Problem: How should one assign responsibilities to objects? Solution: Assign a responsibility to the information expert -- the class that has the information necessary to fulfill the responsibility. Example: In the POS system, Who should be responsible for knowing the total of a sale? By Information Expert we should look for a class of objects that has the information needed. ------------------------------------------ Where do we look for classes that have information? What information is needed to determine the grand total? what information is needed to determine the line item subtotal? What information is needed to determine the product price? What responsibilities did we assign? ------------------------------------------ INFORMATION EXPERT (CONTINUED) Discussion: Information Expert is a frequently used guiding principle. Many partial experts that collaborate. All objects are "alive" or "smart" Should avoid having a single "god class" with many "dumb" objects doing its will. Contraindications: avoid if causes problems with coupling and cohesion. For example, who should the responsible for saving a Sale in a database? Instead design for separation of major concerns (information hiding). Benefits: - Information hiding, hence low coupling. - Behavior spread out, encouraging more cohesive lightweight classes. Related: - Low Coupling - High Cohesion A.K.A: "Place responsibilities with data", "Do it Myself", ... ------------------------------------------ what examples are there in your designs? ------------------------------------------ CREATOR Problem: who should be responsible for creating new instances of some class? Solution: Assign class B responsibility for creating an instance of class A if: - B aggregates objects of class A - B contains A objects - B records instances of A objects - B closely uses A objects - B has the initializing data needed to create A objects If more than one applies, prefer a class that aggregates or contains A objects. Example: In the POS system, who should be responsible for creating a SalesLineItem instance? ------------------------------------------ What class is like that in the domain model? ------------------------------------------ Discussion: The basic idea is to find a creator that needs to be connected to the created object anyway. This supports low coupling. Contraindications: if the creation is complex, then use the Factory pattern. Benefits: - low coupling Related Patterns: - Low Coupling - Factory - Whole-Part ------------------------------------------ what examples are there in your designs? ------------------------------------------ LOW COUPLING Problem: How to support low dependency, low change impact, and increased reuse? Solution: Assign a responsibility so that classes aren't strongly connected. "Coupling" is a measure how strongly one element is connected to, has knowledge of, or relies on other elements. High coupling causes: - changes to affect other classes - difficulty in understanding classes (in isolation) - difficulty in reuse, because more classes are needed Example: Who should create a Payment instance and associate it with a Sale? ------------------------------------------ Which design has lower coupling? ------------------------------------------ Discussion: Low Coupling is an evaluative principle that applies when considering all design decisions. Common forms of coupling X to Y include - X has an attribute of Y - X calls methods of Y objects - X has a method that uses Y e.g., as a parameter, local variable, return type - X is a subclass of Y - X implements the interface Y Low coupling reduces impact of changes. A subclass is strongly coupled to its superclass(es). There will usually be some coupling, just need to gauge it, and understand it. But don't couple strongly with unstable elements. Reusable classes should have low coupling. Contraindications: high coupling to stable elements (the programming language, libraries) is okay. Don't spend extra time "future proofing". Focus on realistic points of high instability or evolution. Benefits: - not affected by other's changes - simple to understand in isolation - convenient to reuse Related Patterns: - Protected Variation ------------------------------------------ what examples are there in your designs? ------------------------------------------ HIGH COHESION Problem: How to keep complexity manageable? Solution: Assign a responsibility so that cohesion remains high. Functional cohesion is a measure of how strongly related and focused the responsibilities of an element are. A class with low cohesion does many unrelated things, or too much work. This causes classes to be - hard to comprehend - hard to reuse - hard to maintain - delicate; often affected by change Example: Who should create a Payment instance and associate it with a Sale? ------------------------------------------ ------------------------------------------ Discussion: This also applies to methods, subsystems, etc., not just classes. It is an evaluative principle, and should be considered all the time. A rule of thumb is that a class with high cohesion has relatively few methods, with highly related functionality. ------------------------------------------ ------------------------------------------ Contraindications: - simplify maintenance for non OO folk - performance in distributed settings Benefits: - clarity and ease of comprehension - maintenance and enhancement easier - low coupling is often supported - easier to reuse ------------------------------------------ what examples are there in your designs? ------------------------------------------ CONTROLLER Problem: Who should be responsible for handling an input system event? An input system event is generated by an external actor. The UI turns these into system operations in the application layer. Solution: Assign the responsibility for receiving or handling a system event to a class that: - represents the overall system, device, or subsystem (facade controller), or - represents a use case scenario (use-case or session controller). ------------------------------------------ ------------------------------------------ A controller is a non-UI object responsible for handling a system event. Example: In the POS system, who should handle system events such as enterItem? ------------------------------------------ ------------------------------------------ Discussion: A Controller is a facade that hides details of the domain layer (from the UI layer). Use a use-case controller if - state info must be kept between system events, - to identify out-of-sequence events, - if there are not "too many" kinds of system events A controller should delegate instead of doing the work itself. ------------------------------------------ Why is it bad for the user interface to have responsibility for handling system events? ------------------------------------------ Benefits: - separates application logic from UI leading to higher reuse - allows reasoning about state of interaction in a use-case Related Patterns: - Command, for message handling systems each message is a command object - Facade, a controller is a Facade - Layers - Pure Fabrication, controllers aren't part of domain model ------------------------------------------ what examples are there in your designs? ------------------------------------------ CRC CARDS An index card for each design class: |------------------------------------| | Sale Collaborators | |------------------------------------| | Knows total SalesLineItem| | Aggregates SalesLineItems | | ... | |------------------------------------| Can use them to play out scenarios - pick up cards when active