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

Chapter Objectives System development and Models Use Cases, Scenarios, and the Use Case Diagram The Class Diagram Generalization/ Specialization Hierarchies Object Relationships Processing Specifications Packages Time-Dependent Behavior Models Object Interaction Models Requirements, System Capability, and Run- Time Behavior

A model is a representation of a real thing. Models are abstractions. For Esample: architect draws house floor plan emphasizes room size and placement floor plan does not show how house will look from outside Several types of models in OO development graphical, narrative, formulas (computational models) During systems analysis, models are produced to show what information processing is to be performed. these are called requirement models they do not specify how requirements are to be fulfilled System Development and Models

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 analysis emphasizes classes of objects and object interactions these models use specific notations as defined by UML System Development and Models

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 system Use 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

Use cases are described and documented through a use case diagram. Use case diagram has two parts. stick figure symbolizing an actor oval indicating the use case

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

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 classes shows what actions objects must perform shows what data objects must contain does not show object implementation does not show object / actor interaction

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

Exhaustive subclasses cover all possible objects. general class will not have any corresponding objects called abstract classes Generalization/ Specialization

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 in entity-relationship diagrams. Cardinality (multiplicity) of a relationship between objects: one to one one to many many to many Object Relationships

Class on left is associated with many objects in the class on right. The numbers and symbols representing cardinality / multiplicity include: “1” for one asterisk (*) for many Object Relationships

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

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

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

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

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

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

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 diagram collaboration 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

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 other which one to use is up to the developer Object Interaction Models

Sequence diagram notation Sequence Collaboration

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

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