06UML - Unified Modeling Language (UML) for OO domain...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Unified Modeling Language (UML) for OO domain analysis CSE432 Prof Glenn Blank Notation wars Early 90's: 6-10 different notations Bertrand Meyer: circles and arrows Distinguishes inheritance and client/supplier relationships Grady Booch: clouds, lines and decorations GardeningPlan Association- Environmental Controller Heater and Cooler Generalization/Specialization-> Actuator Environmental Controller -"has a"- Heater (Cooler, Light) Actuator o "using" Temperature (client/supplier) Actuator is an abstract class (`A' in a triangle) Peter Coad, Ed Yourdon & Jill Nicola: Rounded boxes and annotated lines Line bisected by semi-circle represents generalization (inheritance) Line bisected by triangle represents whole/part So, what's your reaction to all these (and more) notations? "Can't we all get along?" Hence three amigos create UML in mid-90's Closer look at Coad & Nicola Two different boxes grouping classes: HIC (Human Interaction Component) PDC (Problem Domain Components) Why is "Separation of Concerns principle" a good idea? Coad & Nicola call this the "I'm alive principle": Objects can be better understood by thinking about them and talking about them in the first person: "I know my own ____ and I can ___ myself." First person scenarios What goes in the blanks? Attributes and behaviors Why is putting these scenarios in the first person a good idea? Promotes "object-think": objects are autonomous, performing behaviors Similarly, Kent Beck talks about the need for anthropomorphism in responsibility-driven design Class diagrams in UML Classes are boxes, lines are associations Add decorations to lines to refine them But before we study the decorations.... A heuristic for class diagram design Don't put any decorations on the associations at first Semantics of relations tends to be vague "Is a" relationship can mean SUBTYPE ("a square is a polygon") or INSTANCEOF ("George is a square") or IDENTICALTO ("The morning star is the evening star") or PROPERTYOF ("A circle is a round object") or ROLEOF ("George is a President") or MADEOF ("My house is a brick one") or simply EXISTS ("To be or not to be..."). In many languages, there is no verb "is" at all, or it's rarely used. Vagueness is natural: start off vague, get more specific gradually Let the meaning of relations emerge from what they relate UML supports this heuristic by starting with simple undirected lines (associations) Later, add detail to your relationship structures Two basic relationships of O-O OOA typically distinguishes two relations: isa and hasa Why two? That's what O-O programming languages implement: Smalltalk and Java: instance variables and inheritance C++: data members and class derivation Meyer calls these inheritance and client/supplier Booch: generalization/specialization and association or aggregation or composition Coad and Yourdon: gen/spec and whole/part UML calls these generalization and association or aggregation or composition Generalizations (inheritance) Extract commonality among specializations UML uses arrow Generalizations form a hierarchy Multiple inheritance forms a lattice Associations Client-supplier/association/wholepart Typically parts or members of a class Manager -1* -> Employee Denotes 1 to many (*) relationships 0 to many, 1 to 1 relationships also common From Extended EntityRelation models (EER) Manager sales rep -> Employee Employee's role is sales rep Multiplicity: numbers at connection ends Role names at one connection end: Five activities of OOA Coad, Yourdon and Nicola: 1) Class&object: describe problem domain in terms of classes of objects 2) Structure: describe relationships between classes 3) Subject: organize classes into clusters or packages 4) Attributes: describe data held by objects 5) Services: describe behaviors that objects can perform Which of these five activities are analysis and which are design? Class & Object analysis Another look at Coad & Nicola notation Why do all the classes except Count have extra grey boxes? An abstract class has one or more operations that must be implemented by subclasses UML represents an abstract class by italicizing the class name or adding the constraint label {abstract} Structure (association) analysis Lines connecting classes In UML, simple line is an association Decorations for multiplicity, role names, constraints What does {ordered} constraint mean? Arrow denotes navigability e.g., Polygon and Circle refer to Point but not vice versa A black-filled diamond denotes a composition a part, unique to this whole See example from Fowler Aggregations and composition: A white-empty diamond denotes an aggregation a part, but not unique to this whole E.g., A Point may appear in only one Polygon or Circle but a Style could appear in both An alternative notation for composition in boxes Attributes and operations A class box may have three parts Class name, attributes and operations Typically attributes are built-in types UML lets you include information about default values and visibility (+,-,#) E.g., - name: String private Attributes in middle section [1] = "Untitled" {readonly} : type multiplicity default {property} (unmodifiable) I recommend you hold off on these details until design Operations in bottom section of class box Represent services, functions or methods Again, UML has a bit more notation, for information about parameters, default values and visibility E.g., + balanceOn(date:Date): Money Again, I recommend you hold off on these details until design Your next assignments http://www.cse.lehigh.edu/~glennb/oose/afruit.htm Note that there are two problems: fruit and undo Due Sunday, February 19 Project analysis due Monday, February 27 Eclipse with plug-ins Open Source IDE for O-O and Java Plug-ins add more features DrJava plug-in provides Java interpreter Omondo plug-in adds UML class diagrams Available on campus by running "eclips" http://www.lehigh.edu/~sgh2/ (version 2.1) or http:// www.lehigh.edu/stem/teams/dieruff (3.0) Dynamic behaviors Class diagrams represent static relationships. Why? What about modeling dynamic behavior? Interaction diagrams model how groups of object collaborate to perform some behavior Typically captures the behavior of a single use case Use Case: Order Entry 1) An Order Entry window sends a "prepare" message to an Order 2) The Order sends "prepare" to each Order Line on the Order 3) Each Order Line checks the given Stock Item 4) Remove appropriate quantity of Stock Item from stock 5) Create a deliver item Alternative: Insufficient Stock 3a) if Stock Item falls below reorder level then Stock Item requests reorder Sequence diagram Vertical line is called an object's lifeline Represents an object's life during interaction Horizontal arrow is a message between two objects Object deletion denoted by X, ending a lifeline Order of messages sequences top to bottom Messages labeled with message name, optionally arguments and control information Control information, in brackets, may express conditions, such as [hasStock], or iteration Returns (dashed lines) are optional; use them to add clarity Sequence diagrams can also represent concurrent processes: UML 1 models asynchronous messages as horizontal lines with half arrow heads UML 2 makes this distinction by not filling an arrowhead Fowler prefers older notation. Why? Which do you prefer? If a check fails, kill all the Transaction Checker processes After setting up Transaction Coordinator, invoke concurrent Transaction Checkers Note use of comments in margin When is this a good idea? Collaboration diagrams Objects are rectangular icons e.g., Order Entry Window, Order, etc. e.g., prepare() Also spatial layout helps show flow Messages are arrows between icons Numbers on messages indicate sequence Which do you prefer: sequence or collaboration diagrams? Fowler now admits he doesn't use collaboration diagrams Interaction diagrams show flow clearly, but are awkward when modeling alternatives UML notation for control logic has changed in UML 2 but Fowler isn't impressed CRC cards (See multimedia from The Universal Machine on CRC cards) Developed by Beck and Cunningham at Tektronix See http://c2.com/doc/oopsla89/paper.html This is the same Kent Beck that later wrote the book pioneering Extreme Programming. Fowler introduces CRC and end of chapter 4 CRC cards are now part of XP. Responsibilities Key idea: objects have responsibilities As if they were simple agents (or actors in scenarios) Anthropomorphism of class responsibilities gets away from thinking about classes as just data holders "Object think" focuses on their active behaviors Client can expect predictable behaviors To trust an object to behave as expected is to rely upon its autonomy and modularity Harder to trust objects easily caught up in dependencies caused by global variables and side effects. Each object is responsible for specific actions Responsibility also implies independence: Low-tech Ordinary index cards Each card represents a class of objects. 3x5 is preferable to 4x6 at least early on Why? Name, Responsibilities, Collaborators Each card has three components Class names Class Name creates the vocabulary of our analysis Use nouns as class names, think of them as simple agents Even classes that you think of verbs or actions can be made into nouns E.g., "reading a card" becomes CardReader, a class of object (agent) that manages bank cards If you cannot read aloud, it is not a good name such as CardReader rather than CARDREADER or card_reader. Why do most OO developers prefer this convention? E.g., is TermProcess something that terminates or something that runs on a terminal? Better for instances than classes of objects Use pronounceable names Use capitalization (or underscores) to initialize class names and to demarcate multi-word names Avoid obscure, ambiguous abbreviations Try not to use digits within a name, such as CardReader2 Responsibilities section Describes a class's behaviors Describe what is to be done, not how! E.g.: "reads card" or "look up words" Use short verb phrases How do constraints of index cards guide class analysis? A good measure of appropriate complexity If you cannot fit enough tasks on a card, maybe you need to divide tasks between classes, on different cards? Collaborators Lists important suppliers and possibly clients of a class Why are classes that supply services more important here? Suppliers are necessary for the description of responsibilities As you write down responsibilities for a class, add any suppliers needed for them For example "read dictionary" obviously implies that a "dictionary" as a collaborator Developing CRC cards is first a process of discovering classes and their responsibilities People naturally cut up the world in terms of categories of objects In objectoriented analysis, one discovers new categories relevant to a problem domain CRC card simulations Designing for responsibility involves simulation Objects model a world interacting behaviors Once you've developed a set of CRC cards, you're ready to run simulations or structured walkthrough scenarios -Play "what if" to simulate scenarios that illustrate use of a system Let each person be responsible for simulating one or more classes Start a simulation with the construction of an object of a class, then run one of its behaviors (a responsibility of that class) This behavior may pass control to some collaborator another class Simulation becomes visible as an exchange of behavior and control from one card to another You may discover missing or incompletely described responsibilities Why? When is activity most useful? An analyst can prototype a system by running a simulation of objects and their behaviors "Execute" a scenario by having each object, run at the right time IMO, it really should be called responsibility-driven analysis, rather than design. From CRC cards to Interaction diagrams Fowler recommends first using CRC cards to begin modeling scenarios Then document with UML sequence (or collaboration) diagrams Why might this be a good approach? Sequence diagrams show collaborations among many objects in a single use case State diagrams show the behavior of a single object across many use cases We'll examine state diagrams when we get to design Addendum for your team project assignment In addition to a class diagram for your project's problem domain, Create one or more interaction (either sequence or collaboration) diagrams showing dynamic behavior of your classes Use a UML tool such as Eclipse with Omondo or Rational Rose or google for a free one CRC cards are optional though recommended Project analysis due Monday, February 27 ...
View Full Document

Ask a homework question - tutors are online