Jerry KotubaSYST39409-Object Oriented Methodologies1 Object Oriented Methodologies Week05/06

Agenda Assignment No 1 - Due Today Review ICE 02 & 03 Do ICE04 & ICE05 Class Diagrams Inheritance Whole-to-part relationships Mid-Term review Jerry KotubaSYST39409-Object Oriented Methodologies2

Systems Analysis and Design in a Changing World, 6th Edition 3 Things in the Problem Domain Two Techniques for Identifying them Brainstorming Technique Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type Noun Technique Identify all of the nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember

Systems Analysis and Design in a Changing World, 6th Edition4 Brainstorming Technique Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded?

Systems Analysis and Design in a Changing World, 6th Edition5 Brainstorming Technique: Steps 1. Identify a user and a set of use cases 2. Brainstorm with the user to identify things involved when carrying out the use case—that is, things about which information should be captured by the system. 3. Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember? 4. Continue to work with all types of users and stakeholders to expand the brainstorming list 5. Merge the results, eliminate any duplicates, and compile an initial list

Systems Analysis and Design in a Changing World, 6th Edition6 The Noun Technique A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents Popular technique. Systematic. Does end up with long lists and many nouns that are not things that need to be stored by the system Difficulty identifying synonyms and things that are really attributes Good place to start when there are no users available to help brainstorm

Systems Analysis and Design in a Changing World, 6th Edition 7 Partial List of Nouns for RMO With notes on whether to include as domain class

Systems Analysis and Design in a Changing World, 6th Edition8 The Noun Technique: Steps 1. Using the use cases, actors, and other information about the system— including inputs and outputs— identify all nouns. For the RMO CSMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation… 2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed. For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address.

Systems Analysis and Design in a Changing World, 6th Edition9 The Noun Technique: Steps (continued) 3. As this list of nouns builds, refine it. Ask these questions about each noun to help you decide whether you should include it: Is it a unique thing the system needs to know about? Is it inside the scope of the system I am working on? Does the system need to remember more than one of these items? Ask these questions to decide to exclude it: Is it really a synonym for some other thing I have identified? Is it really just an output of the system produced from other information I have identified? Is it really just an input that results in recording some other information I have identified? Ask these questions to research it: Is it likely to be a specific piece of information (attribute) about some other thing I have identified? Is it something I might need if assumptions change?

Systems Analysis and Design in a Changing World, 6th Edition10 The Noun Technique: Steps (continued) 4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further. 5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain.

Systems Analysis and Design in a Changing World, 6th Edition 11 A Simple Domain Model Class Diagram A customer places zero or more orders An order is placed by exactly one customer An order consists of one or more order items An order item is part of exactly one order

Systems Analysis and Design in a Changing World, 6th Edition 12 UML Notation for Multiplicity

Systems Analysis and Design in a Changing World, 6th Edition 13 Domain Model Class Diagram for a bank with many branches

Systems Analysis and Design in a Changing World, 6th Edition 14 Domain Model Class Diagram for course enrollment at a university Where is each student’s grade remembered in this model? Each section has many grades and each grade is association with a student Each student has many grades and each grade is association with a section

Systems Analysis and Design in a Changing World, 6th Edition 15 Refined Course Enrollment Model with an Association Class CourseEnrollment Association class— an association that is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade

Associations/Relationships relationship among object classes solid line connecting classes association is named i.e. “drives” where line connects to class is called “association role”

Associations/Relationships Associations with Multiplicity  shows number of objects in an association  lower..upper bound  bounds are inclusive 2..5  0..1 = optional one  0..* = optional many  1..* = many  1 = exactly one

The complexity of the Many-to-many relationships- The “Association Class” Examples

Systems Analysis and Design in a Changing World, 6th Edition 19 More Complex Issues about Classes: Generalization/Specialization Relationships Generalization/Specialization A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy Superclass the superior or more general class in a generalization/specialization hierarchy Subclass the subordinate or more specialized class in a generalization/specialization hierarchy Inheritance the concept that subclasses classes inherit characteristics of the more general superclass

Subclasses Jerry KotubaSYST Object Oriented Methodologies20 Some instances of a class (subclass) may be grouped together based on features not shared by the rest of the class. Attributes Behavior Relationships Key verb is “isakinda” (and inverse, “canbea”).

Subclasses and Inheritance A subclass is made up of selected instances from another class, the “Parent class” or “superclass.” A superclass includes all the instances of the subclass, plus possibly more as well. Jerry KotubaSYST Object Oriented Methodologies21

Subclasses and Inheritance Inheritance is when a subclass instance, in addition to the attributes and behavior it has by virtue of being in the subclass, also has all the attributes and behavior that instances of the superclass have. Each subclass then adds attributes and behaviors that it needs but the other one doesn’t.

Subclasses and Inheritance The subclass relationship actually is a relationship in the way we have used that word. It requires a verb (one in each direction). “isakinda” “canbea” Jerry KotubaSYST Object Oriented Methodologies23 isakinda canbea

Object-Oriented Jerry KotubaSYST Object Oriented Methodologies24 To be considered truly O-O, a language, database, etc. must support: Objects, Classes, Inheritance, and Polymorphism

Subclasses With subclasses, we can show more detail about relationships on our diagram. For instance, in most companies, only managers can hire and fire. In other words, only certain kindsa employees can do certain tasks. (only a baker can bake) We are able to show that some relationships affect only a subclass, not every instance.

Exercise - Ilustration Jerry KotubaSYST Object Oriented Methodologies26 SLATE- Exercise No 4

Generalization, Inheritance & Constraints generalization path solid line with hollow arrowhead pointing from subclass to superclass indicate basis of generalization name the path for the attribute being removed = called the discriminator discriminator shows which property is abstracted by a generalization relationship Jerry Kotuba 27 SYST Object Oriented Methodologies

Constraints on Generalization constraints on the subclasses overlapping: descendent may be descended from more than one of the subclasses student can be both a research and teaching assistant disjoint: descendent may not be descended from more than one of the subclasses patient can not be both out and resident Jerry Kotuba 28 SYST Object Oriented Methodologies

Constraints on Generalization complete: all subclasses are listed only have out and resident patients incomplete: all subclasses are not listed more subclasses are available can have casual, part- time employees Jerry Kotuba 29 SYST Object Oriented Methodologies

Generalization, Inheritance & Constraints generalization path solid line with hollow arrowhead pointing from subclass to superclass indicate basis of generalization name the path for the attribute being removed = called the discriminator discriminator shows which property is abstracted by a generalization relationship Jerry Kotuba 30 SYST Object Oriented Methodologies

Constraints on Generalization constraints on the subclasses overlapping: descendent may be descended from more than one of the subclasses student can be both a research and teaching assistant disjoint: descendent may not be descended from more than one of the subclasses patient can not be both out and resident Jerry Kotuba 31 SYST Object Oriented Methodologies

Constraints on Generalization complete: all subclasses are listed only have out and resident patients incomplete: all subclasses are not listed more subclasses are available can have casual, part- time employees Jerry Kotuba 32 SYST Object Oriented Methodologies

Whole-to-Part Associations The UML provides ways to model two types of whole-to-part associations – aggregation and composition. Jerry KotubaObject Oriented Methodologies33

Definitions aggregate: In an aggregation, the class representing the whole. aggregation: An association between classes representing a part-to-whole relationship in which the parts and the whole may exist independently and in which a single part may be associated with more than one whole at the same time. Jerry KotubaObject Oriented Methodologies34

Definitions…cont’d composite: In a composition, a class representing the whole. composition: An association between classes representing a whole-to-part relationship in which the parts may belong to only one whole at a time and the whole does not exist without its parts. Jerry KotubaObject Oriented Methodologies35

Example of an Aggregation. Jerry KotubaObject Oriented Methodologies36

Example of a Composition. Jerry KotubaObject Oriented Methodologies37

Aggregation and Composition. Jerry KotubaObject Oriented Methodologies38

Categories of Whole-to-Part Associations There are three relationships that sometimes occur in an object model: Assemblies of parts Members of groups Containers and their contents You may find these useful for making your model a better tool for understanding and communication. The model can always be built without these. They do not really affect its use for system design, just for talking to the users. Jerry KotubaObject Oriented Methodologies39

Assemblies of parts Taking something apart into its components is a technique we humans often use to understand how something works. Often we find it improves our understanding to model A product and its components A business consists of branches, departments, etc. A country consists of states, provinces, counties, boroughs, shires, towns, villages, cities, etc. Jerry KotubaObject Oriented Methodologies40

Containers and their contents Container-Contents is a different and less common relationship. In some situations we may find it helpful to view a relationship as one of these, e.g., Truck or Aircraft and the Products or Shipments that it carries An actual shipping container and the goods it holds A ship, bus or airplane and its passengers A building and the businesses it houses. Jerry KotubaObject Oriented Methodologies41

Assemblies of parts Vs Containers and their contents The essential difference between these relationships is that: With Assemblies of parts, if you take the component away, the assembly (whole) probably won’t work any more Take a wheel off a car Take a hand off a clock Take a leg off a table. A Container, however, is still a perfectly good Container, even without its Contents The jar is still OK even without the “hunny.” And the Contents are perfectly OK without the Container (although the “hunny” might get all over one’s paws!) Jerry KotubaObject Oriented Methodologies42

Collection-Member (members of groups) Collection-Member is also a different and relatively uncommon relationship. Sometimes we meet an actual collection: A library full of books An art gallery A stamp or jewelry collection A fleet of trucks, ships or aircraft Other times it may help to use this to describe: A church, club or regiment and its members An inventory of furniture or equipment A herd, mob, flock, school or skein of animals. Jerry KotubaObject Oriented Methodologies43

Your Turn… Jerry KotubaObject Oriented Methodologies44 Think about a book, which consists of a cover, table of contents, chapters and an index. Chapters in turn have pages, paragraphs and words. Show the special case of association between classes described here including the multiplicity.

Your turn…ICE04 & ICE-05 SLATE Jerry KotubaObject Oriented Methodologies45

Test Review Jerry KotubaObject Oriented Methodologies46 See ICE’s on SLATE Plus Exercises 1,2,3,&4

Test Review Jerry KotubaObject Oriented Methodologies47 Satzinger – Chapters 1,2,4,5,6 (Chap 6 only to page 225 –including Activity diagrams) Plus all material covered in class…check PPTs 10 modified T/F and 15 M/C questions Exercises Event table Use Case Diagram Includes (a.k.a. Uses) Activity Diagram Class Diagram Relationships ( Multiplicity) Association Classes Subclasses & Inheritance (incl. constraint & Discriminator Notation) Generalization & Specialization Abstract Classes Permitted a “cheat sheet” One 8 ½ X 11 sheet only (both Sides)