Transcript Slide 1

Object Oriented Methodologies

Week05/06

Jerry Kotuba SYST39409-Object Oriented Methodologies 1

Agenda

 Assignment No 1 - Due  Today    Review ICE 02 & 03 Do ICE04 & ICE05 Class Diagrams  Inheritance  Whole-to-part relationships  Mid-Term review Jerry Kotuba SYST39409-Object Oriented Methodologies 2

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 Edition 3

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 Edition 4

Brainstorming Technique: Steps

1.

2.

3.

4.

5.

Identify a user and a set of use cases 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.

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?

Continue to work with all types of users and stakeholders to expand the brainstorming list Merge the results, eliminate any duplicates, and compile an initial list Systems Analysis and Design in a Changing World, 6th Edition 5

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 6

Partial List of Nouns for RMO With notes on whether to include as domain class

Systems Analysis and Design in a Changing World, 6th Edition 7

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 Edition 8

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 Edition 9

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 10

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 11

UML Notation for Multiplicity

Systems Analysis and Design in a Changing World, 6th Edition 12

Domain Model Class Diagram

for a bank with many branches

Systems Analysis and Design in a Changing World, 6th Edition 13

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 14

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 Systems Analysis and Design in a Changing World, 6th Edition 15

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

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 Systems Analysis and Design in a Changing World, 6th Edition 19

Subclasses

 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 ”).

Jerry Kotuba SYST39409 - Object Oriented Methodologies 20

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 Kotuba SYST39409 - Object Oriented Methodologies 21

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

that word.

in the way we have used It requires a

verb

in each direction).

(one   “ isakinda ” “ canbea ” Jerry Kotuba SYST39409 - Object Oriented Methodologies 23

Object-Oriented

 To be considered truly O-O, a language, database, etc. must support:     Objects, Classes, Inheritance, and Polymorphism Jerry Kotuba SYST39409 - Object Oriented Methodologies 24

  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.

Subclasses

Exercise - Ilustration

 SLATE- Exercise No 4 Jerry Kotuba SYST39409 - Object Oriented Methodologies 26

Generalization, Inheritance &

27

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 SYST39409 - Object Oriented Methodologies Jerry Kotuba

28

Constraints on Generalization

   constraints on the subclasses overlapping subclasses : descendent may be descended from more than one of the  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 SYST39409 - Object Oriented Methodologies Jerry Kotuba

29

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 SYST39409 - Object Oriented Methodologies Jerry Kotuba

Generalization, Inheritance &

30

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 SYST39409 - Object Oriented Methodologies Jerry Kotuba

31

Constraints on Generalization

   constraints on the subclasses overlapping subclasses : descendent may be descended from more than one of the  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 SYST39409 - Object Oriented Methodologies Jerry Kotuba

32

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 SYST39409 - Object Oriented Methodologies Jerry Kotuba

Whole-to-Part Associations

The UML provides ways to model two types of whole-to-part associations – aggregation and composition.

Jerry Kotuba Object Oriented Methodologies 33

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 Kotuba Object Oriented Methodologies 34

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 Kotuba Object Oriented Methodologies 35

.

Example of an Aggregation

Jerry Kotuba Object Oriented Methodologies 36

Example of a Composition

.

Jerry Kotuba Object Oriented Methodologies 37

Aggregation and Composition

.

Jerry Kotuba Object Oriented Methodologies 38

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 Kotuba Object Oriented Methodologies 39

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 Kotuba Object Oriented Methodologies 40

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 Kotuba Object Oriented Methodologies 41

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 Kotuba Object Oriented Methodologies 42

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 Kotuba Object Oriented Methodologies 43

Your Turn…

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. Jerry Kotuba Object Oriented Methodologies 44

Your turn…ICE04 & ICE-05

 SLATE Jerry Kotuba Object Oriented Methodologies 45

Test Review

 See ICE’s on SLATE  Plus Exercises 1,2,3,&4 Jerry Kotuba Object Oriented Methodologies 46

Test Review

     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) Jerry Kotuba Object Oriented Methodologies 47