DOC PREVIEW
CU-Boulder CSCI 5448 - Dealing with Change

This preview shows page 1-2-3-20-21-40-41-42 out of 42 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 42 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Dealing with ChangeKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/5448 — Lecture 7 — 09/15/20091Sad News• Computer Science lost one of its members this weekend• Michael Tuthill• He will be missed by his friends and teachers here at CU• Mary Friedericks, the director of Victim Services, contacted me to say that if you need help or need to talk about this situation, please call: (303) 492-88552Lecture Goals• Review material from Chapter 3 of the OO A&D textbook• Dealing with Change• More on Requirements and Use Cases• Use Case Styles• Discuss the Chapter 3 Example: Todd & Gina’s Dog Door, Take 2• Emphasize the OO concepts and techniques encountered in Chapter 33But first… a quiz• Not for points, but to make sure you’ve been learning the material we’ve covered so far• First Question• What is the general term for a relationship between two classes?• What do we call an instance of such a relationship?4Quiz• First Question• What is the general term for a relationship between two classes?• Association• What do we call an instance of such a relationship?• Link5Quiz• Second Question• One type of association is the “whole-part” relationship• We covered two types of this relationship, what were they called?• Define the three properties associated with this type of relationship. 6Quiz• Second Question• One type of association is the “whole-part” relationship• We covered two types of this relationship, what were they called?• Aggregation / Composition• Define the three properties associated with this type of relationship.• Transitive: A contains B and B contains C implies A contains C• Asymmetric: A contains B means B does not contain A• Existence Dependence: If A contains B and A is deleted, then B is deleted (this is true only for composition)7Quiz• Third Question (Take home, will present answer on Thursday)• Draw a UML class diagram that captures the following relationships• The world is a matrix of locations. Each location is a particular type of terrain (water, grass, forest, mountain) and may have the player on it or one or more creatures. A player can either be a warrior or a wizard. A warrior has access to one or more weapons, each that deal different amounts of damage and that have different ranges (e.g., a bow can attack a creature that is five squares or closer). A wizard has access to one or more spells, each that deal different amounts of damage, have different ranges, and that might linger for one or more turns. A creature has a description and two attacks, one melee and one ranged, that deal different amounts of damage. Both creatures and players have a certain number of hit points and know their current location in the world.• Feel free to read between the lines to find a set of classes that can model this situation as elegantly as possible; feel free to send your work to me8Things Change...• The one constant in software analysis and design is CHANGE• This is true because that’s the one constant we face in life• In software development, requirements always change!• No matter how well you design an application, things will change for you:• new techniques, new tools, new solutions• and things will change for your user:• new requirements, new ideas, new needs• Rather than fight it, you need to:•Plan for likely change and design your software to accommodate it• Document your current state with clear requirements and good use cases• When change comes, you’ll be able to identify exactly what has changed and where9Todd and Gina’s Dog Door• With respect to the example• back in chapter 2, Todd and Gina LOVED the system you designed• BUT… the real world intrudes!• They are tired of having to listen for Fido! They sometimes miss his barking and he “takes care of business” inside!• Also, they are constantly losing the remote!• So, they have a GREAT idea• What if the dog door opened automatically when Fido barked at it?10What’s the Process?• As software engineers, we would like to have a process that we follow• So, how do we deal with change?• In OO A&D, the answer typically is• find the use case that most closely matches the change request• update the use case to document the new scenario• customer focus: IF the system were changed to handle the new request, how would the user interact with it?• consider alternate paths (if needed)• update the requirements list (use use cases to validate completeness)11Initial Idea• To allow the dog door to open automatically, we will assume the existence of a “bark recognizer”• we won’t try to specify an implementation at this point• that might over-constrain our subsequent analysis and design work• but we need to introduce some new element to the system to enable the redesign of the use case• Now, lets examine how the use case changes… this will give us information on how our system’s behavior changes• and that will provide insight into how the implementation will need to change12Current Use Case13What the Door Does1. Fido barks to be let out.2. Todd or Gina hears Fido barking.3. Todd or Gina presses the button on the remote control.4. The dog door opens.5. Fido goes outside.6. Fido does his business.6.1 The door shuts automatically6.2 Fido barks to be let back inside.6.3 Todd or Gina hears Fido barking (again).6.4 Todd or Gina presses the button on the remote control.6.5 The dog door opens (again).7. Fido goes back inside.First Attempt: Wrong Approach• In the new use case, we want to allow for the possibility that the bark recognizer hears Fido and opens the door before a human does• It would be natural to take this approach at first• 2. Todd or Gina hears Fido barking• 2.1 The bark recognizer “hears” a bark• 3. Todd or Gina presses the button on the remote control• 3.1 The bark recognizer sends a request to open the door• What’s the problem with this approach?14Alternate Paths• Recall that alternate paths are meant to show steps that can be done if something goes wrong with the current step• In the original use case, steps 6.1 to 6.5 show another way in which the use case can move forward if the door closes before Fido is “done” •They, in essence, document an ADDITIONAL set of steps that can occur between step 6 and step 7 of the “main path”• The alternate path on the previous slide is different: 2.1 and 3.1 are meant to


View Full Document

CU-Boulder CSCI 5448 - Dealing with Change

Documents in this Course
Django

Django

42 pages

ENRS

ENRS

30 pages

PhoneGap

PhoneGap

22 pages

Load more
Download Dealing with Change
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Dealing with Change and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Dealing with Change 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?