chapter 5 models and uml notation for the object-oriented approach

23
Chapter 5 Models and UML Notation for The Object-Oriented Approach

Upload: bridget-ford

Post on 03-Jan-2016

241 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Chapter 5

Models and UML Notation for The Object-Oriented Approach

Page 2: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Chapter Objectives

System development and ModelsUse Cases, Scenarios, and the Use Case DiagramThe Class Diagram

Generalization/ Specialization HierarchiesObject RelationshipsProcessing SpecificationsPackages

Time-Dependent Behavior ModelsObject Interaction ModelsRequirements, System Capability, and Run-Time Behavior

Page 3: Chapter 5 Models and UML Notation for The Object-Oriented Approach

A model is a representation of a real thing.Models are abstractions.

For Esample: architect draws house floor planemphasizes room size and placementfloor plan does not show how house will look from outside

Several types of models in OO developmentgraphical, narrative, formulas (computational models)

During systems analysis, models are produced to show what information processing is to be performed.

these are called requirement modelsthey do not specify how requirements are to be fulfilled

System Development and Models

Page 4: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Graphical models have been used for quite some time to create requirements models. Structured systems analysis

data flow & entity relationship diagrams (graphical models)data dictionary is supporting document

Object-Oriented analysisemphasizes classes of objects and object interactionsthese models use specific notations as defined by UML

System Development and Models

Page 5: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Use Case is a sequence of actions a system performs

yields observable results of value to a particular actor

Actor is either a person or another interacting systemUse cases capture main system functionality from an actor’s prospective.The sequence of actions required is often referred to as a scenario.

each use case has at least one scenario

Use Cases and Scenarios

Page 6: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Use Cases and Scenarios

Use cases are described and documented through a use case diagram. Use case diagram has two parts.

stick figure symbolizing an actoroval indicating the use case

Page 7: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Use case diagram can also show relationships between use cases.

Three types of relationships:

Include relationship: collects functionality into one place

• organized as use case

• employed by other use cases

Generalization relationship: describes variation of normal behavior

Extend relationship: similar to generalization relationship

• includes nore detailed and controlled descriptions

• more specific in its description

Use Cases and Scenarios

Page 8: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Class Diagram

Class Diagram: most important model produced to capture the static features of a system. Acts as processing requirements model and data requirements model.Class diagrams are logical models.

shows required object classesshows what actions objects must performshows what data objects must containdoes not show object implementationdoes not show object / actor interaction

Page 9: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Generalization/Specialization hierarchies are core constructs in the OO approach.Class diagrams highlight these hierarchies.

Generalization / Specialization

Page 10: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Exhaustive subclasses cover all possible objects.general class will not have any corresponding objectscalled abstract classes

Generalization/ Specialization

Page 11: Chapter 5 Models and UML Notation for The Object-Oriented Approach

The class diagram also includes symbols for relationships in the entity-relationship diagram.

object in one class can be associated with objects in another class

Association relationship is similar to relationships typically shown inentity-relationship diagrams. Cardinality (multiplicity) of a relationship between objects:

one to oneone to manymany to many

Object Relationships

Page 12: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Class on left is associated with many objects in the class on right. The numbers and symbols representing cardinality / multiplicity include:

“1” for oneasterisk (*) for many

Object Relationships

Page 13: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Additional numbers and symbols indicate optional or mandatory relationships. Often these are referred to as minimum and maximum cardinality / multiplicity.

Object Relationships

Page 14: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Whole-part relationship is usually called an aggregation relationship. Depicted the same way as an association relationship.

same use of minimum and maximum cardinality / multiplicity

Whole-Part Relationships

Page 15: Chapter 5 Models and UML Notation for The Object-Oriented Approach

In the class diagram, methods are usually referred to by a verb and noun.

i.e. “calculate fee”

The procedure to be followed when performing the method has to be described in detail. This can be done using any of the process-modeling techniques that are known from traditional systems.

Pseudocode, structured English, action diagrams, flowcharts are some of the alternatives that are available.For OO, pseudocode or structured English is adequate for design phase.

Processing Specifications

Page 16: Chapter 5 Models and UML Notation for The Object-Oriented Approach

If the class diagram becomes large, it will be quite difficult to use for an overview of the system. May be necessary to create a high-level view of the system, using partitioning or clustering scheme.Clustering can be done after the initial model is produced.

facilitates presentation and further work

Can also be done beforehand.allows for division of work between teams

UML calls these clusters packages and provides a modeling notation called package diagram.

Packages

Page 17: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Statechart is often used to document object’s time-dependent behavior. A state chart shows the states an object can be in and the actions or conditions that cause an object to make a transition from one state to another.Aids understanding the possible states of an object and the allowed sequence that changes in state must follow. Statecharts are extensions to class diagrams.

could create a statechart for every class

Time-Dependent Behavior Models

Page 18: Chapter 5 Models and UML Notation for The Object-Oriented Approach

An Example:Potential student might apply, be accepted, and enroll as a regular student.Student might then graduate.A potential student cannot be changed to graduating student without first being an enrolled student. Since these transitions are related to the passing of time, the term time-dependent behavior is often used to describe what is being modeled.

Time-Dependent Behavior

Page 19: Chapter 5 Models and UML Notation for The Object-Oriented Approach

The use case and its scenarios serve as a vehicle for organizing the object interactions that take place.Each scenario involves a certain set of interactions. UML uses two different notations and models for object interaction diagrams:

sequence diagramcollaboration diagram

Sequence diagrams present object interaction arranged in time sequence. Shows the object involved in a time scenario and the sequence of message that are exchanged.

Object Interaction Models

Page 20: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Collaboration diagrams show interaction organized around the objects and their messages to each other.These two diagram types are interchangeable.

some CASE tools can generate one from the otherwhich one to use is up to the developer

Object Interaction Models

Page 21: Chapter 5 Models and UML Notation for The Object-Oriented Approach

Sequence diagram notationS

eque

nce

Collaboration

Page 22: Chapter 5 Models and UML Notation for The Object-Oriented Approach

1. What is a model?2. Why are graphical models useful?3. What is the difference between a requirements

model and a design model? 4. What are the reasons for creating logical

models?5. What is the difference between an event and

use case?6. What is the difference between a use case and

a scenario?7. What are the UML graphical models used in the

object-oriented approach?8. What items are listed in the three sections of

the symbol for a class?

Review Questions

Page 23: Chapter 5 Models and UML Notation for The Object-Oriented Approach

9. What symbol is used to indicate a generalization/ specialization?

10. How is an association relationship shown on a class diagram?

11. What symbol is used to indicate a whole-part/aggregation relationship?

12. How are maximum cardinality / multiplicity indicated?

13. What are the symbols for a state and a state transition in a statechart?

14. How might the processing details of a method be documented?

15. Which model is used to document interactions in a scenario?

Review Questions