1 / 35

Software Design Methodologies: UML in Action

Learn about object-oriented concepts, advanced issues about attributes, UML inheritance, and explore multiple inheritance. Understand modeling concepts such as logical forms, structure, abstraction, concepts, objects, classes, roles, and actors.

isbelll
Download Presentation

Software Design Methodologies: UML in Action

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department of Computer Science & Engineering University of Nebraska, Lincoln Ferguson Hall, P.O. Box 880115 Lincoln, NE 68588-0115 http://www.cse.unl.edu/~fayad ISISTAN Research Institute – Tandil, Argentina

  2. Lesson 10: Object-Oriented Concepts -1 2 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  3. Lesson Objectives • Overview of Previous Lecture • Understand some OO Concepts • Discuss Advanced Issues about Attributes • Understand UML- Inheritance • Explore Multiple Inheritance • The Uses & Containment Relationships 3 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  4. Modeling Concepts • Logical Forms • Structure • Abstraction • Concepts • Objects • Classes • Roles • Actors 4 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  5. Logical Forms • The same substance often take several forms. • ice, steam, water, snow, frost, fog are different forms of H2O • Some substances can be transformed from one form to another. • Not all of our studies are of material substances. • Speech, Writing, Geometry, Physics, etc. • But each area of human study acknowledges the existence of “good form”. • “Form” is thus equated with the existence of a pattern/order/consistency/regularity 5 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  6. Structure • “Structure” is the way a thing/construct/form us built up from its parts. • Changing the structure’s content can lead to new forms. • Musical notes, part of a house, etc. • A given content may exist in several different forms. • But each area of human study acknowledges the existence of “good form”. • Conversely, a form may also appear in several different contents • In fashion, dresses can be made from different materials. 6 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  7. Abstraction • “Abstraction” is the consideration of a form apart from its contents. Examples: • “roundness” is a property of a golf ball, a snow ball, a baseball, etc. • “hardness’ is a property of diamond, wood, steel, etc. • Abstraction can be improved upon by practice and study. • Abstract forms are discovered, and named, in the investigation of analogous forms. • A song ==> piano, guitar, etc. • A sphere ==> gold, steel, etc. • We teach abstraction by presenting a set of different things (physical or conceptual) and pointing out the common features that called formal properties. • formal properties are those properties that allow us to express the form of a thing. 7 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  8. Concept • “A concept” is an abstract form or an abstraction. • There is a set corresponding to each concept. • “The dress is white” means the dress is a member of the set of white things. • These sets need not to be disjoint (i.e., the same member may appear in several sets. • The white dress is short and charming. • These set are called classes or categories. • Concepts are formal properties we use to describe things. • The primitive notions of a factual scientific theory are its concepts • Biology ==> cells, bacteria, virus, animal, plant, etc. • Adjectives & adverbs usually are the names of concepts in English 8 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  9. Roles • A “role” is the part of a person or thing plays in a specific situation, operation, etc.. • Many different object can play the same role. • Many roles can be played by the same object. • The white dress is short and charming. • A description of a role involves descriptions of: • Activities to be performed • Sequences or processes • Commands to be given and received • Roles are, therefore, abstractions (i.e., abstract forms or concepts). • In fact, roles are abstract temporal forms (i.e., a certain behavior at relative points in time). 9 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  10. Actors • Roles are defined independently of the things used to play that role. • Conversely, Actors are classes that are capable of playing different roles. • They are often classes of physical things. • Man, Woman, Car, etc. • They are often capable of playing different roles in the same time • Woman ==> Doctor, Mother, Pilot • They often take-on and lose roles over time 10 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  11. Attributes are simply the information associated with the object. The data type used to hold the attributes is often a fundamental type, such as int or char. Sometimes the attribute can be a non-fundamental type, such as String type and Address type. Avoid using attributes which might be better implemented as an association to a new class. Attributes 25 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  12. x More on Attributes • For example: Using Association Using Attributes TV TV Manufacturer String model String serialNum String manName String model String serialNum • product manu- • facturer String name Address address • Why? Using an association to a Manufacturer class, the name and address of each manufacturer will be stored in one place rather than in each of the TV objects made by that manufacturer. 12 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  13. More on Attributes • If attributes only make sense in some instances of a given class but not in others. It will make sense to split the single class into two classes or more. Employee String name float salary Employee Split into two classes String name float salary long clearanceNum inheritance ClearedEmployee 13 long clearanceNum openVault() • Not all employees have clearances ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  14. When a relationship exists between classes such that lower-level classes (called subclasses) share certain attributes and behaviors which can be defined once in a higher-level class (called superclasses). Subclasses inherit properties (attributes and behaviors) of its superclass and then adds its own unique properties and modifies any inherited properties. This is called Generalization or Inheritance. Inheritance 14 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  15. More on Inheritance Window paintWindow size icon bitmaps textWindow contents 15 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  16. Generalization, Specialization (1) • Related terms: inheritance • Definition: • Inheritance is a programming language concept; an implementation mechanism for the relationship between superclasses and subclasses by means of which attributes and operations of a superclass also become accessible to its subclasses. • Generalization (or specialization) is a taxonomic relationship between a general and a special element (or vice versa), where the special element adds properties to the general one and behaves in a way that is compatible with it. 16 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  17. Generalization, Specialization (2) • Notation: • The inheritance relation is represented by means of a large empty arrow pointing from the subclass to the superclass. Superclass Subclass Subclass 17 Subclass Subclass ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  18. Generalization, Specialization (3) • Generalization relations can be provided with the following predefined constraints: • overlapping • disjoint • complete • incomplete Superclass {incomplete} Subclass1 Subclass2 18 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  19. Generalization, Specialization (4) • Example: GeomFigure {abstract} x: Integer y: Integer visible: Boolean display() {abstract} Remove() {abstract} moveTo(pX, pY) Circle Rectangle Triangle radius {radius >0) a {a>0} b {b>0} a {c-b<a<b+c} b {a-c<b<a+c} c {a-b<c<a+b} 19 setRadius(pR) display() remove() setSides(pA, pB) display() remove() setSides(pA,pB,pC) display() remove() ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  20. Multiple Inheritance • In multiple inheritance, a class can have more than one superclass. Animal Fish Habitat Mammal Terrestrial Aquatic Pig 20 Dolphin Trout ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  21. Multiple Inheritance • Example: Vehicle name manufacuturer LocomotionMedium {Overlapping} KindOfPower Water Vehicle Windpowered Vehicle Motor Vehicle draught displacement minWindForce maxWindForce fuelType power 21 SailingBoat surfaceOfSails numOfSails ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  22. Multiple Inheritance • Overlapping Versus Disjoint disjointSailingBoat overlappingSailingboat waterVehicle:name windpoweredVehicle.name waterVehicle:manufacturer windpoweredVehicle.manufacturer draught displacement surfaceOfSails numOfSails name manufacturer draught displacement surfaceOfSails numOfSails 22 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  23. The uses relationship (object-based) The containment relationship (object-based) The inheritance relationship (class-based) The association relationship (object-based) The term “object-based vs. class-based” denotes whether or not all objects of a class have to obey the relationship. Each relationship has its own characteristics and can be dangerous when used in the wrong area of design. Each relationship has its own heuristics governing its correct use. The Relationships between Classes & objects - Heuristics 23 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  24. Most common Definition: if an object of one class sends a message to an object of another class, the first class is said to have a uses relationship with the second class. Example: The Uses Relationship A person using an alarm clock APerson AnAlarmClock Name: Bob Jones Age: 30 Eyes: Blue Hair: Brown Height: 5’ 10” Weight: 170 Hour: 6 Minute: 23 AlarmHour: 10 AlarmMinute: 30 AlarmStatus: On Set_time (“10:30”) 24 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  25. Heuristic 1: Minimize the number of classes with which another class collaborates. Heuristics for the Uses Relationship Meal Melon Melon cost() cost() Restaurant Patron cost() Restaurant Patron cost() Steak cost() Steak cost() cost() Pie Pie 25 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  26. Heuristic 2: Minimize the number of messages send between a class and its collaborator. Heuristic 3: Minimize the amount of collaboration between a class and its collaborator, that is, the number of different messages sent. Heuristic 4: Minimize fanout in a class, that is, the product of the number of messages defined by the class and the messages they send. Heuristics for the Uses Relationship 26 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  27. Heuristic 1: If a class contains objects of another class, then the containing class should be sending messages to the contained objects, that is, the containment relationship should always imply a uses relationship. Heuristic 2: Most of the methods defined on a class should be using most of the data members most of the time. Heuristic 3: Classes should not contain more objects than a developer can fit in his or her short-term memory. A favorite value for this number is six. Heuristic 4: Distribute system intelligence vertically down narrow and deep containment hierarchies. (?) Heuristics for the Containment Relationship 27 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  28. Semantic constraint is an application-specific constraint imposed on an OO relationship restricting its scope or behavior, most often associated with the containment relationship. Heuristic 5: When implementing semantic constraints, it is best to implement them in terms of class definition. Often this will lead to a proliferation of classes, in which case the constraint must be implemented in the behavior of the class – usually, but not necessarily, in the constructor. Semantic Constraints Between Classes (1) 28 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  29. Heuristic 6: When implementing semantic constraints in the constructor of a class, place the constraint test in the constructor as far down a containment hierarchy as the domain allows. Heuristic 7: The semantic information on which a constraint is based is best placed in a central, third party object when that information is volatile. Heuristic 8: The semantic information on which a constraint is based is best decentralized among the classes involved in the constraint when that information is stable. Semantic Constraints Between Classes (2) 29 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  30. Heuristic 9: A class must know what is contains, but it should not know who contains it. Heuristic 10: Objects that share lexical scope – those contained in the same containing class – should not have uses relationships between them. More Containment Heuristics 30 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  31. Objects Sharing Lexical Scope Problem (1) ATM display_pin() CardReader Display get_pin() Keypad Example of objects sharing lexical scope and using each other 31 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  32. Objects Sharing Lexical Scope Problem (2) ATM have_a-card() display_pin() Display CardReader get_pin() Keypad A better solution to the objects sharing lexical scope problem 32 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  33. Class-based relationship: an OO relationship between two classes in which all objects of the classes involved obey the relationship. Container class: a class whose main purpose is the storage of other objects. Often implemented as a homogeneous-looking list of heterogeneous objects, namely, a polymorphic list. Containment by value: A containment relationship in which the contained object is directly linked to the containing class, that is, the objects involved in the relationship are born and die together. Containment by reference: A containment relationship in which the contained object is indirectly linked to the containing class, usually via a pointer or referential attribute. Summary 33 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  34. Define uses and containment relationships What is semantic constraint? What do you think “multiple inheritance” means? Define Polymorphism with examples What do we mean by saying “Model/View/Controller”? Discussion Questions 34 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  35. Define: Interactions vs. relationships Inheritance vs. aggregation Define: association, attributed association, recursive associations, Explain: association constraints, qualified associations, composition Discuss the inheritance relationship heuristics Questions for the Next Lecture 35 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

More Related