Object-Oriented Analysis and Rational Rose

Introduction

Object-Oriented is often Data Centered

Doing Object-Oriented Analysis does not mean we do not do Control Analysis

It probably means that we focus on data and their relationship first before we consider the control.

Identifying Classes and Objects

External entities (devices, people or other systems) that produce or consume information.

Things (such as reports, displays, letters, signals) that are part of the information domain of the problem.

Occurrence or events (such as essential internal events)

Roles (such as managers, engineers, students, teams) that are relevant to the application.

Places (such as physician office) that establish the context of the problem.

Structures (such as sensors, computers, disk drivers) that define a class of objects, or related classes of objects.

More Object Identification Criteria

Retained information -- the object values need to be remembered for the system to perform correctly.

Need services -- the object must have set of identification operations that can change the value of its attributes in some way.

Multiple attributes -- more attributes, more likely to be important

Common attributes -- a set of attributes can be defined for the potential objects, and these attributes apply to all occurrences of the object.

Common operations -- a set of operations can be defined for the object, and these operations apply to all occurrences of the objects.

Essential requirements -- external entities that appear in the problem space and produce or consume information that is essential to the operation of the system.

Coad and Yourdon, Object-Oriented Analysis, 2nd Edition, Prentice Hall 1991.

Completion of OOA

All classes and the class hierarchy have been defined and reviewed.

Class attributes and operations associated with a class has been defined and reviewed.

Class relationship has been established.

A Behavior model has been created and reviewed.

Reusable classes have been noted.

R. Pressman, Software Engineering, 4th Edition, McGraw-Hall, 1997.

The Booch Method

Identify classes and objects

• Propose candidate object
• Conduct behavior analysis
• Identify relevant scenarios
• Define attributes and operations for each class

Identify the semantics of classes and objects

• Select scenarios and analyze
• Assign responsibility to achieve desired behavior
• Partition responsibilities to balance behavior
• Select an object and enumerate its roles and responsibilities
• Define operations to satisfy the responsibilities
• Look for collaborations among objects

Identify relationships among classes and objects

• Define dependencies that exist between objects
• Describe the role of each participating object
• Validate by walking through scenarios

Conduct a series of refinements

• Produce appropriate diagrams for the work conducted above
• Define class hierarchies as appropriate
• Perform clustering based on class commonality

Document-Driven Analysis

Identify analysis components including objects, relationships, methods, states and attributes.

Build object models and STDs.

Cross Reference object model and STDs.

Repeat the steps for refinement.

Rational Rose/Java Overview

• Object-Oriented Modeling
• Illustration
• Team Development Tool
• Round-trip Engineering
• Download the tool from www.rational.com

Rational Rose/Java Overview

• Rational Rose/Java is an object-oriented modeling tool that offer BOOCH and OMT support for
• Object-Oriented modeling
• Team development
• Code generation
• Round-trip engineering/Reverse engineering
• Documentation generation
• Rational Rose/Java facilitates the development of applications in Java

Object-Oriented Modeling

• Supports both BOOCH and OMT methods, only OMT will be used in our notes
• Provides a model-diagram architecture that captures multiple view of one application while automatically maintaining consistency consistency between those views
• Detects and reports omissions and semantic inconsistency in the application model

Terms

• Model: Representation for the problem domain and the software system
• Components: Logical and Physical
• Logical Components - Classes, Class categories
• Objects, Operations
• Physical Components - Modules, subsystem, Processors, Device
• Classes: set of objects with a common structure and behavior
• Class Categories: groups of highly cohesive classes
• A class category: Person - Doctor
• - Patient
• - Nurse
• Objects: Class instances. State, behavior
• Operations: Services provided by a Class
• Relationships: e.g. class uses another
• Physical Model:
• Modules: Unit of Code
• Subsystems: clustor of (unit) modules subsystem and modules
• Diagrams: - Multiple views of the model
• Specifications: Textual representation
• Class Categories: Diagrams to specify various of views of the model

Object-Oriented Modeling (Cont.)

• Relational Rose/Java Step by Step
• Identify objects, attributes/operations of each object, interaction among objects
• Identify class categories, scenarios diagram for each category
• Identify class for each category, state diagram for each class (if necessary)

Object-Oriented Modeling (Cont.)

• Step by Step ...
• Identify subsystems/modules
• Associate category (class) to subsystem (module)
• Generate specification for each diagram
• Semantic checking for access violations
• Skeleton code generation
• Document generation

Example

• Admission of patients in a hospital
• there are physicans, patients, and nurses in a hospital
• a patient might have several admissions in a hospital due to different diseases
• a chart will record one admission, including patient, and all the physicians involved
• exactly one chart will be generated for each admission

Example

• Objects - Patient, Physician, and Nurse
• Attributes - base class Person might have Name, SSN, Address
• Categories - Patient, Physician, Nurse and base class Person -> People Category

Categories

• Categories are used to partition one application model into cohesive groups of collaborating classes
• a category is a application model partition
• a category contains a set of cohesive classes and their interaction (inheritance, association, and aggregation)
• different people may have different categories definition on the same application

Scenario Diagram

• Scenarios describes one application's behavior
• A category may contain serveral scenario diagrams
• The representation of a scenario diagram can be an object message diagram or a message trace diagram

Class Diagram (Object Model)

• Class diagram contain icons representing classes, their relationships, and their important characteristics
• Modify a class diagram are appropriately reflected in all other diagrams, as well as in the "specifications' of affected model components
• Each class may be associated to one model
• Sometime the highest level of class diagram is refered as Object Model
• Here is an example
• For each class, you should have a detail description with it

State-Transition Diagram (STD)

• State transition diagrams model the behavior of classes in terms of
• Events that trigger transitions between states
• Actions that take place at such transition
• State transition diagram is associated to only one class

Global State Transition Diagram (GSTD)

• You could use a STD to describe different states of your system as a whole
• The diagram is useful when trying to understand the "state" or "control flow" of the whole software system
• Here is an example

Subsystem/module Diagram

• Provide functional view of the system
• One application can be divided into several subsystems, and one subsystem can be divided into several modules
• Category (class) can be associated to one subsystem (module)

Specification

• Specification provide a textual view of the information that Rational Rose/Java maintains for each component in the application model
• Changes in the model made by modifying a component's specification are appropriated reflected in all diagrams containing an icon representing that components

Semantic Checking

• RR/Java reports any class used outside its containing category but lacking public visibility
• Any class used outside its containing category when there is no using relationship between that containing category and the category containing the client class
• Any object whose class is un-designated in scenario diagrams
• Any message not assigned to an operation in scenario diagrams

Team Development Support

• Can be used by analysts, designers and developers together
• Allows a development team to control categories and subsystems with the same configuration management system used to control Java source code
• Provide each developer with a private workspace over which he/she has exclusive control eliminating asynchronous and uncontrolled change propagation

Round-Trip Engineering

• Generating Java code as directed by fine-grained code-generation properties, carrying forward code from the previous iteration
• Reverse engineering Java code to create an as-built model of the application
• Reporting differences between the initial application model and the as-built model
• Updating the application model to reflect approved implementation changes

Other information

• Relational Software Corporation Home page http://www.rational.com