OOAD Introduction

OOAD With UML And Rational Rose
10/2/2001
Object-Oriented Analysis & Design

Visual Modeling with UML And Rational Rose 2000 Part I. Introduction
Jun 15, 2001
(c) 2001 24MB Software Development
Sharing Your Objectives

Individually state:
Your name Your company affiliation You job title and responsibilities What you hope to get from this course
Less than 15 minutes
Jun 15, 2001
Part I: Introduction
10/2/2001
Why This Course? (Or Design Problem)

Why This Course Course Outline Case Study Lesson Structure OO Paradigm UML Rational Rose Patterns
Everyone knows about how important design work is Very few people really do design before coding Consequence:
Messy applications Inability of maintenance and upgrades Many reworks
Jun 15, 2001
Purpose
By the end of this course, you should be able to:

Complete OO design sessions effectively Know how to start effectively in every stage of development process fully focusing on customers
Jun 15, 2001
10/2/2001
Purpose
And
Know how we should apply design & architectural patterns effectively Using Rational Rose & UML for visual modeling work
Jun 15, 2001
Contents Map
I. Introduction I. Introduction
All projects start with customers needs! Where do I Istart from? All projects start with customers needs! Where do start from?
II. Requirement Capturing II. Requirement Capturing III. Architecture III. Architecture IV. Analysis IV. Analysis V. Design V. Design
A Real- world Project Putting it all together
Think customers!
Goal-driven Use-Cases. A system view from users Goal-driven Use-Cases. A system view from users Think architecture first. All start from patterns. Subtractix approach. Think architecture first. All start from patterns. Subtractix approach. System view from the inside. What shall we have in the system. System view from the inside. What shall we have in the system. Blue-print for implementation. Howthe system will work. Patterns again. Blue-print for implementation. Howthe system will work. Patterns again.
VI. More About Patterns & Design Refinement VI. More About Patterns & Design Refinement Architectural Patterns, Design Heuristics, and so on Architectural Patterns, Design Heuristics, and so on
Jun 15, 2001 (c) 2001 24MB Software Development 6
10/2/2001
Part I. Introduction
Overview of the course:

OO Paradigm Overview UML Overview Rational Rose Overview Pattern Overview
Jun 15, 2001
Module I: OO Paradigm Overview

Why OO?
Better modeling for the real world
Goals: Understanding of
Basic concepts and elements of OO paradigm Interaction mechanism of the OO world Benefits of OO methodology
Guidelines Activities and labs Conclusion

(c) 2001 24MB Software Development 8
Jun 15, 2001
10/2/2001
Module II: UML Overview

Why UML?
Standardized, powerful language for Visual Modeling and just a language
Goals: Understanding of
Purpose of UML Basic concepts of the language Classification of UML diagrams and when to apply them during development process
Activities and labs
Jun 15, 2001
Module III: Rational Rose Overview

Why Rational Rose?

Rose is almost the best Visual Modeling tool
Goals:
Understanding and using the notations of Rose effectively Ability to use Rose for visual modeling works
Guidelines: Focus on: When the modeling work is done?
Jun 15, 2001
10
10/2/2001
Module IV: Patterns Overview

What is pattern? Why Patterns?

Patterns are, and will play a very important role in software development. However, patterns are not silver bullet.
Learning goals:
Understanding whats a pattern Ability to apply patterns in design works
Techniques:
GRASP patterns GOF patterns POSA patterns
Jun 15, 2001
11
Part II. Requirements 1/2

Why doing requirements captures?

A system view from customers
Learning Goals:
Understanding of how important requirement capturing is Understand Use-cases The modern form of requirements for a customer centric development process Ability of describing customer requirements using Use-cases
Jun 15, 2001
12
10/2/2001
Part II. Requirements 2/2

What to be done? How to capture requirements? Modeling techniques Guidelines Using use-cases patterns
Jun 15, 2001
13
Part III. Architecture 1/2

What to do with Architecture?

Think architecture first and think big. Subtraction always be easier than addition
Learning Goals:
Understand about software architecture and architectural patterns Ability to use architectural patterns and Subtractix approach in design works
Jun 15, 2001
14
10/2/2001
Part III. Architecture 2/2

How:
Architectural analysis Architectural design Refining architecture Analysis: Architecture refinement What Design: Architecture refinement How
Architectural patterns and Subtractix
Jun 15, 2001
15
Part IV. Analysis 1/2

What to be done?
Refinement of architecture focusing on WHAT
Learning goals:
Understanding and ability to do basic analysis techniques: finding analysis classes, using analysis diagram
Jun 15, 2001
16
10/2/2001
Part IV. Analysis 2/2

How to analyze system requirements? How to find analysis classes? Modeling Techniques: how to using class diagrams, state chart diagrams for visual modeling the analysis model Guidelines Using analysis patterns
Jun 15, 2001
17
Part V. Design 1/2

What to be done?
Refinement of architecture focusing on HOW. Blue-print for implementation.
Learning goals:
Understanding of design techniques and design pattern. Ability to using these techniques to complete design sessions.
Jun 15, 2001
18
10/2/2001
Part V. Design 2/2

How to design? Modeling Techniques Guidelines:

Development environment dependency Principles for design refinements
Using design patterns
Jun 15, 2001
19
Part VI. Patterns & Design Refinement

Architectural & Design patterns review Additional design principles and heuristics
Jun 15, 2001
20
10
10/2/2001
A Sample Project: POS Of Classics Inc.

During this course, you will be developing a Point of Sale (POS) application for a fictional company called Classics, Inc. Classics, Inc. is a rapidly growing chain of retail stores that sells classical music, classic movies, and classic books. Classics, Inc. has outgrown its Point of Sale application and now must create a new Order Processing and Fulfillment System (OPFS). As you progress through the course, you will develop the OPFS to help Classics Inc. better manage their stores and inventory.
Jun 15, 2001
21
Lesson Structure
Lessons start with goals Goals are divided into:

What should be done How can we achieve the What
Lessons are supported with guidelines and techniques During lessons, students have to exercise with activities and labs to reenforce learned knowledge
Jun 15, 2001
22
11
10/2/2001
Module I: OO Paradigm & Concepts
Jun 15, 2001
23
Learning Goals
By the end of this module, you will be able to understand:

Basic concepts/elements of OO Paradigm Dynamic aspect inside the OO world Benefits of OO paradigm or advantages of OO over traditional methods
Jun 15, 2001
24
12
10/2/2001
More Detailed, We Will Learn About

Static Aspect
Objects and classes Abstraction and encapsulation
Dynamic Aspect
Methods and messages Interfaces, inheritance, and polymorphism Access control
Jun 15, 2001
25
Objects and Classes

Why This Course Course Outline Case Study Lesson Structure OO Paradigm Static Aspect Dynamic Aspect UML Rational Rose Patterns
OO software development Objects Classes
Jun 15, 2001
26
13
10/2/2001
Learning Objectives
Introducing the object-oriented principles Outline the limitations associated with the traditional approach and the ways to improve Explain the concept of the object and class Describe the role of objects and classes Describe the way in which classes handle data
Jun 15, 2001
Basic Founded Concepts of OO

Abstraction and encapsulation (and data hiding) Inheritance Polymorphism and dynamic binding
Jun 15, 2001
28
14
10/2/2001
The Principles OO Aimed to

Support the principles of good programming Provide software of high-quality Fulfill user expectations Make code more portable and more reliable Reduce development costs Make code better represent real-world objects
Jun 15, 2001
29
The Principles of Good Programming

Modularity Reusability Extensibility Ease of maintenance Preservation of data integrity Efficient debugging
Jun 15, 2001
30
15
10/2/2001
Problems With Traditional Approach

Difficult or not as effective at:

Attain and maintain efficiently Interaction between modules Modeling real-world things Developing complex software
Jun 15, 2001
31
The Ways To Improve 1/2

Express all problems domain entities through the concept of objects Model the real-world better than others Focus specifically on the problems and not be mired in the details Promoting to reuse previous work Allows to extend or enhance your system without modifying or breaking existing code
Jun 15, 2001
32
16
10/2/2001
The Ways To Improve 2/2

Simplifying complex problems by:

Emphasizes "black box" functions Embraces structured development Encourages better programming design
Jun 15, 2001
33
What Is An Object?
Objects are a natural thing to model Can be identified, classified, and defined Represented in a system Has a set of attributes that describe it Attribute is something that is internal to an object
Jun 15, 2001
34
17
10/2/2001
Example
yellow circle yellow circle cyan square cyan square purple rectangle purple rectangle
Circle, rectangle, square are objects Yellow, purple, cyan are their attributes All of them belong to a group of object: shape objects
Jun 15, 2001
35
Everything Is An Object
Each objects can represent:

Entities Roles Data structures
Express all problem domain entities Comprise data and the methods work on that data
Jun 15, 2001
36
18
10/2/2001
Apply To Real-world Objects

Create an accurate representation of the problem domain Map this representation into the final program Modularizes information as well as processing
Jun 15, 2001
37
Object Relationships
Association Aggregation Specialization
Jun 15, 2001
38
19
10/2/2001
Association
Semantic connection between objects Allows one object to know about the public attributes & operations of another object
Jun 15, 2001
39
Aggregation
Stronger form of association The relationship between a whole and its parts One object may have several aggregation relationships with other objects
Jun 15, 2001
40
20
10/2/2001
Specialization
An inheritance relationship between two objects Allows one object to inherit the attributes of another
Jun 15, 2001
41
What Is a Class?
Think as simply a type that has associated methods Define both the data and the operation on that data A blueprint for objects that share a similar structure or behavior A blueprint for a given set of functionality
Jun 15, 2001
42
21
10/2/2001
How Is a Class Defined?

Its data The operations that may be performed on it The operations that it may perform on other classes
Jun 15, 2001
43
Class Characteristics 1/3

Each class is a syntactical unit Independent stand-alone modules "Decoupled" from each other
Jun 15, 2001
44
22
10/2/2001
Class Characteristics 2/3

May contain another class as its data members Containment is not confined to a single level Access to the contained classes is strictly controlled The contained class is private
Jun 15, 2001
45
Class Characteristics... 3/3

Can be organized into class hierarchies Class hierarchies show relationship between classes Class hierarchies are usually represented as an inverted tree The top of the hierarchy is known as the root Root is the source of the shared characteristics
Jun 15, 2001
46
23
10/2/2001
Example: A point class
class MyPoint { private: int x, y; public: MyPoint (); MyPoint(int x, int y); // copy constructor MyPoint(MyPoint& pt); // operators void operator =(const MyPoint& pt); void operator +=(const MyPoint& pt); void Offset(int xOfs, int yOfs); int GetX(); int GetY(); };
Example: A shape class
// a abstract base class for graphic shapes class Shape { protected: ColorType Color; MyPoint Position; public: Shape(MyPoint Pos, ColorType c) { Color = c; Position = Pos; } // method for drawing a given graphic shape void Draw(); };
Jun 15, 2001
48
24
10/2/2001
Parameterized Classes
Instances themselves are classes Also known as template Use for creating other classes based on the template Cannot directly use the instance creation mechanism Required parameters for instantiation
Jun 15, 2001
49
Example: Template
template<class T, int i> class MyStack { private: int MaxItem ; T* Top; T StackBuffer[i]; public: MyStack (); void Push(const T item); T& Pop(); }; template<class T, int i> MyStack<T, i> ::MyStack () { ... }; template<class T, int i> void MyStack<T, i>::Push(const T item) { ... }; // continue on next page...
Jun 15, 2001
50
25
10/2/2001
Example: Template Contd
template<class T, int i> T& MyStack <T, i>::Pop() { ... }; int main(int argc, char* argv[]) { MyStack <int , 5> stack; // a int stack MyStack <char, 10> stack2; // another char stack stack.Push(10); stack.Push(5); stack2.Push(s); int& n = stack.Pop(); char& c = stack2.Pop(); return 0; } // n = 5 // c = s
Jun 15, 2001
51
Classes Vs. Objects

Used to define objects Items created using the class are called instances The term instance and object are used interchangeably Each instance requires its own set of data but shares the class operations
Jun 15, 2001
52
26
10/2/2001
Abstraction and Encapsulation

Data abstraction Encapsulation
Jun 15, 2001
53
Learning Objectives
To provide a basic understanding of data abstraction Discuss the process of data encapsulation Distinguish between data encapsulation and data hiding Describe how encapsulation and data hiding can aid data protection
Jun 15, 2001
54
27
10/2/2001
What Is Abstraction?
Refers to how a given problem is represented in the system The detail implementations are hidden Dividing programs into logically separate units Breaking programs down into small ones
Jun 15, 2001
55
Data Abstraction
Implemented by the use of classes The data cannot be accessed directly Access is provided through the permitted actions Provides for both primitive and userdefined data types Consists of two concepts:
Encapsulation Data hiding
Jun 15, 2001
56
28
10/2/2001
Benefits of Good Abstraction

Can be reused many times Makes programs more modular Simplifies complex programs Makes them more comprehensible Focus on the problem domain
Jun 15, 2001
57
Example: Abstraction
// a class for position class MyPoint { private : int x, y; public: MyPoint (); MyPoint(int x, int y); // omitted . . . }; // MyPoint class implementation is abstracted from Shape class point of vi ew class Shape { protected: MyPoint Position; // omitted . . . };
Jun 15, 2001
58
29
10/2/2001
What Is Encapsulation?
The ability of an object to hide its internal data and methods The important parts of the object programmatically accessible via an interface The process of packaging an object's data together with its code
Jun 15, 2001
59
The Concept of Encapsulation

Abstract data types consist of:

The data and how it is structured The set of actions that may operate on the data
Each elements should be described together in the same syntactic unit Abstraction results in the hiding of details
Jun 15, 2001
60
30
10/2/2001
The Concept of Data Hiding

The details of data structure remain unknown The details of legal actions for manipulating data are part of the definition
Jun 15, 2001
61
More About Encapsulation

Protects the structure from random changes Ties together data and processes The data type is clearly defined Each variable is complete, stand-alone entity
Jun 15, 2001
62
31
10/2/2001
The Advantage of Encapsulation

As a result of data hiding

Programs are more reliable The integrity of data is preserved
Encapsulation
Adds to modularity Assists maintenance and debugging Makes programs more portable Produces a model that is closer to real life Facilitates data hiding and data protection
Jun 15, 2001
63
Example: Encapsulation
// information of a specific position on the screen and their op erations // are grouped (encapsulation) together in MyPoint class class MyPoint { private: int x, y; public: MyPoint (); MyPoint(int x, int y); // omitted . . . void Offset (int xOfs, int yOfs); int GetX(); int GetY(); };
Jun 15, 2001
64
32
10/2/2001
Methods and Messages

Methods Messages
Jun 15, 2001
65
Learning Objectives
Define the terms methods and messages Explain how methods and messages provide for communication Distinguish between method and message
Jun 15, 2001
66
33
10/2/2001
What Is a Method?
An operation that can be used to manipulate an object Implemented in a piece of program code Used to describe the actions Perform certain tasks Implementation is not usually available to the class user Have full access to objects data
Jun 15, 2001
67
More About Method

An object cannot directly access the methods of another object Must use a suitable message Only invoked by a message requesting It's useful to group the methods by their general task
Jun 15, 2001
68
34
10/2/2001
The Groupings of Methods

It can be useful to give names to the groupings of methods:

Object managers Data managers Implementers Helpers
Two benefits of method grouping:

Makes clear how the objects behave Ensure that the class definition is complete
Jun 15, 2001
69
What Is a Message?
Messages and methods are synonymous Equivalent to function calls in a traditional environment Used by object to interact with each others Passing messages between objects is known as "method calling" Message can contain parameters Message parameters are actually method parameters
Jun 15, 2001
35
10/2/2001
The Components of a Message

The name of the receiving object The name of the method to be performed Any values, or parameters to carry out the action Any value returned by the method
Jun 15, 2001
71
Sending Messages
Without having to know how the object works Need to know method's parameters A single message will give rise to different behaviors depending on receiving object
Jun 15, 2001
72
36
10/2/2001
Interfaces, Inheritance, and Polymorphism

Interfaces Inheritance Polymorphism
Jun 15, 2001
73
Learning Objectives
Explain the interface Describe the principles of inheritance Describe how one class can inherit the characteristics of another Define the terms "polymorphism" and "dynamic binding Explain the concept of polymorphism
Jun 15, 2001
74
37
10/2/2001
What Is an Interface?
The implementation of the abstraction The collection of messages that an object can process A binding contract between class itself and its consumer The consumer deal with an object via interfaces:
Public Inheritance Parameter
Jun 15, 2001
75
Interface Characteristics
Associated with a particular class External section of an object Acts as an object's point of communication with other objects Describes the class's behavior and how to invoke this behavior Describes what the methods do, not how they do it
Jun 15, 2001
76
38
10/2/2001
What Is Inheritance?
The ability to specify one class has a kind-of relationship with another class An object classification, which each object belong a given class Class hierarchy trees are known as inheritance trees Organized on the basis of common characteristics
Jun 15, 2001
77
How the Inheritance Tree Is Structured?

The base class is parent, each subclass is a child The child class inherits all the properties of the parent class Child classes contain other characteristics additional to those inherited Child classes are more specialized than its parent
Jun 15, 2001
78
39
10/2/2001
Support Multiple Inheritance

Child class can inherit properties from multiple parent class Used with care as problems can arise in certain cases
Jun 15, 2001
79
Summaries Benefits of Inheritance

It facilitates code reuse It facilitates code maintenance It allows extensions to existing code
Jun 15, 2001
80
40
10/2/2001
Example: Inheritance 1/3
// a class for rectangle class Rectangle : public Shape { protected: int Width, Height; public: Rectangle(MyPoint Pos, int Width, int Height, ColorType Color); void Draw(); // draw a rectange, omitted . . . }; // a class for circle class Circle : public Shape { protected: int Radius; public: Circle (MyPoint Pos, int Radius, ColorType Color); void Draw(); // draw a circle, omitted . . . };
// a class for square // Note: Square derived from Rectangle instead of Shape class Square : public Rectangle { public: Square(MyPoint Pos, int Width, ColorType Color); // omitted . . . }; // omitted . . .
Jun 15, 2001
82
41
10/2/2001

Square Rectangle Circle Shape
Class inheritance tree
Jun 15, 2001
83
What Is Polymorphism?
"Polymorphism" is meaning "having many parts The ability to extend system without modifying existing code Each class will respond in its own way to a single method The result is much the same
Jun 15, 2001
84
42
10/2/2001
Polymorphism Characteristics
Base class's method can be individually tailored in each derived classes The method's name is same The method's actual code is different for each class Objects of related classes can respond to a generic method
Jun 15, 2001
85
Polymorphism Requirements
System must support dynamic binding "Binding" describes an association between two things Dynamic binding means that message is bound to the method at runtime
Jun 15, 2001
86
43
10/2/2001
Benefits of Using Polymorphism

Less code needs to be designed and written Simply write generic code Code is more compact and cheaper to produce Code becomes more easily extendable
Jun 15, 2001
87
Example: Polymorphism 1/3
// without polymorphism // . . . // draw shapes Rectangle Rect(Point(10, 10), 50, 100, Magenta); Circle Cir(Point(200, 50), 30, Yellow); Square Squr(Point(100, 200), 75, Cyan); Rect.Draw(); Cir.Draw(); Squr.Draw (); // have to call the Draw method for individual object to // draw itshelf
Jun 15, 2001
88
44
10/2/2001
// modify classes for using polymorphism class Shape { // omitted . . . virtual void Draw() = 0; // do nothing in Shape class, draw given // shape in derived classes }; class Rectangle : public Shape { // omitted . . . virtual void Draw(); }; class Circle : public Shape { // omitted . . . virtual void Draw(); };
Jun 15, 2001
// draw a rectangle
// draw a circle
89
// . . . // draw shapes Shape* Shp[0] Shp[1] Shp[2] Shp[3]; = new Rectangle(MyPoint(10, 15), 45, 70, Magenta); = new Circle(MyPoint(100, 100), 80, Yellow); = new Square(MyPoint(200, 110), 30, Cyan);
for (int i = 0; i < 3; ++ i) Shp[i]->Draw(); // the correct version Draw method of each object // is called // result
Jun 15, 2001
90
45
10/2/2001
Access Control
To preserve data integrity:

Access must be as restricted as possible Data can defend itself against attack
Two types of access must be defined:

Access to the data Access to the actions
Jun 15, 2001
91
Types of Access Control

Two levels of data type access be defined:

Private Public
Public actions for external accessing Private actions for only internal accessing Class containment, another private level layer of data protection
Jun 15, 2001
92
46
10/2/2001
Conclusion
Relatively new approach aims to increase software development productivity Overcome many of the limitations of the procedural approach by reducing software complexity
Jun 15, 2001
93
Module II: UML Overview
A picture is worth a thousand words

47
10/2/2001
Introducing Visual Modeling & UML

What is Visual Modeling? Benefits of Visual Modeling What is UML? The Evolution of the UML UML Design Goals
Jun 15, 2001
95
What is Visual Modeling?

Modeling captures essential parts of the system Dr. James Rumbaugh Visual Modeling is modeling using standard graphical notations
Jun 15, 2001
96
48
10/2/2001
Why Visual Modeling?

Captures Business Process Communication Tool Manages Complexity Defines Software Architecture Promotes Reuse
Jun 15, 2001
97
What is UML?
Visual language for modeling a system Models for

Specification Architecture Design Implementation
Systems of several different kinds

Software systems Business processes
Jun 15, 2001
98
49
10/2/2001
The Evolution of the UML

Jun, 99 OMG Vote, Oct 97 Submission to OMG, Sept 97
UML 1.3 UML 1.1 UML 1.0 UML 0.9
public feedback
Submission to OMG, Jan 97 Beta version OOPSLA 96 WWW - June 96 OOPSLA 95
WWW Spec only Documentation Set
Unified Method 0.8
Other methods
Booch
OMT
OOSE/Objectory
Jun 15, 2001
99
UML Design Goals

Ready to use, expressive modeling language Model core concepts Be independent of particular programming languages and development processes
Jun 15, 2001
100
50
10/2/2001
UML Design Goals Contd

Provide a formal basis for understanding, but not a lot of mathematical theory Can be tailored to meet specific needs Support higher-level development concepts
Jun 15, 2001
101
Exploring the UML Notation

Static Model & Dynamic Model Stereotypes Model Elements Relationships UML Diagrams
Jun 15, 2001
102
51
10/2/2001
Static Model & Dynamic Model

Static Model
Use Case Diagram Analysis-Class Diagram Package Diagram Design-Class Diagram Code: Class Diagram Class Definition
Use Cases
Requirement Analysis Design Coding
Software System Component Diagram Deployment Diagram
Dynamic Model
Activity Diagram Sequence Diagram Collaboration Diagram State Diagram Code: Methods
Object Structure
Object Behavior
Jun 15, 2001
103
Static Model
Who acts Which Responsibilities With whom and about what Data types, data structure, relationships Who and What
Jun 15, 2001
104
52
10/2/2001
Dynamic Model
How objects interact? Sequencing of interaction How and When
Jun 15, 2001
105
Module III: Rational Rose An Overview
Jun 15, 2001
106
53
10/2/2001
What is Rational Rose?

Rational Rose is a graphical component modeling and development tool that uses the industry-standard Unified Modeling Language (UML) A Product of Rational Software Inc.
Jun 15, 2001
107
Why should I use Rational Rose?

Increase developer productivity. Improve software quality. Common standard language results in improved team communication. Reverse-engineering capabilities allow you to integrate with legacy OO systems. Models and code remain synchronized through the development cycle.
Jun 15, 2001
108
54
10/2/2001
Rational Rose Editions

Rose Modeler no language support Rose Professional support for 1 language Rose Enterprise supports multiple languages including (VC++, VB, Java, and CORBA)
Jun 15, 2001
109
Graphical User Interface

Jun 15, 2001
110
55
10/2/2001
Toolbar and Tool boxes

Jun 15, 2001
111
The Diagram Window

You can create, display or modify Rose diagrams in the diagram window.
Jun 15, 2001
112
56
10/2/2001
The Browser
The Rose browser is a hierarchical navigational tool allowing you to view the names and icons representing diagrams and model elements.
Jun 15, 2001
113
The Documentation Window

The documentation window allows you to create a self-documenting model and from that selfdocumenting model generate self-documenting code.
Jun 15, 2001
114
57
10/2/2001
Views
Rational Rose is organized around the following views of a software project: Use Case Logical Component Deployment Each of these views presents a different aspect of the model
Jun 15, 2001
115
The Use -case view UseWhy This Course Course Outline Case Study Lesson Structure OO Paradigm UML Rational Rose Use-case View Logical View Component View Deployment View Patterns
The use-case view helps you to understand and use the system. This view looks at how actors and use cases interact. The diagrams in this view are: Use-case diagrams Sequence diagrams Collaboration diagrams Activity diagrams
58
10/2/2001
The Use -Case View UseWhy This Course Course Outline Case Study Lesson Structure OO Paradigm UML Rational Rose Use-case View Logical View Component View Deployment View Patterns
The Logical View

Why This Course Course Outline Case Study Lesson Structure OO Paradigm UML Rational Rose Use-case View Logical View Component View Deployment View Patterns
The logical view addresses the functional requirements of the system. This view looks at classes and their relationships. The diagrams in this view are: Class diagrams State-chart diagrams
59
10/2/2001
The Component View

The component view addresses the software organization of the system. This view contains information about the software, executable and library components for the system. This view contains only component diagrams.
The Deployment View

The deployment view shows the mapping of processes to hardware. This type of diagram is most useful in a distributed architecture environment where you might have applications and servers at different locations This view contains only one diagram the deployment diagram.
60
10/2/2001
Module IV: Patterns
Jun 15, 2001
121
Patterns In OO - History
77 - Work of the architect Christopher Alexander 80s - Kent Beck playing with Smalltalk 91 - Gammas PhD thesis on ET++ 92 - Coads patterns paper 92 - Johnsons OOPSLA paper 93 - OOPSLA workshop Coad & Anderson 93 - Patterns discussion group on WWW 94 - First PLoP conference 95 - Gang of four book (first draft at OOPSLA 93)
61
10/2/2001
Christopher Alexander
Alexander,C., Ishikawa, S. & Silverstein, M., A Pattern Language, Oxford University Press 1977 A handbook of patterns to be used in the construction Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. 253 patterns in 35 groups
The Structure Of A Pattern

Each pattern is presented in the same format for clarity, ease of navigation etc.
Name. A Short descriptive phrase. Picture. Followed by an introductory paragraph to outline the context. Problem. An outline of the problem that the pattern aims to solve. Solution. The heart of the pattern, a description of how to solve the problem. Interconnections. The other patterns which are related to this one.
62
10/2/2001
Peter Coads Patterns

Coad, P.,Object-Oriented Patterns, Communications of the ACM Vol 35 No. 9 September 1992 "An object-oriented pattern is an abstraction of a doublet, triplet, or other small grouping of classes that is likely to be helpful again and again in objectoriented development." Coads patterns originally had a focus on OOA
Larmans GRASP patterns

Larman proposes a small set of (what he calls) patterns for assigning responsibilities to classes. General Responsibility Assignment Software Patterns. Expert, Creator, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection and Dont Talk to Strangers.
63
10/2/2001
Grasp 1
Expert - assign the responsibility to the class that has the information necessary to fulfill the responsibility Creator - Assign B the responsibility to create an A if
B aggregates or contains A objects B records instances of A objects B closely uses A objects B has the initialising data that A needs (expert)
Low coupling - Assign a responsibility so that coupling remains low High cohesion - Assign a responsibility so that cohesion remains high
Grasp 2
Polymorphism - When behaviors vary by type, assign responsibilities (using polymorphism) to the type with the variation. Pure Fabrication - Invent a cohesive class which is not in the problem domain to further low coupling. Indirection - Assign the responsibility to an intermediate object to mediate between components so that they are not directly coupled. Dont talk to strangers - The Law of Demeter
64
10/2/2001
Gang Of Four
Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley 1995. Work started with Gammas doctoral thesis and continued for a couple of years. The final published book shows signs of evolution from the earliest drafts. You should try to read chapter 2. There are 25 patterns arranged under 3 headings
Jun 15, 2001
129
Gang Of Four - Format

Pattern Name and Classification Intent Also known as Motivation Applicability Structure
Participants Collaborations Consequences Implementation Sample code Known uses Related Patterns
65
10/2/2001
Design Pattern Space

Purpose
Creational Structural Adapter (class) Adapter (object) Bridge Composite Decorator Facade Flyweight Proxy Behavioral Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
Scope
Class Object
Factory Method Abstract Factory Builder Prototype Singleton
Observer Pattern Outline

a 60 50 80 b 30 30 10 c 10 20 10
x y z
b a a b c c
a = 50% b = 30% c = 20%
Change notification requests, modifications
66
10/2/2001
Patterns And Reuse

The focus was never on component reuse but on the reuse of design ideas and insights. Patterns are increasingly becoming specialized to problem domains, apparently losing generality.
Important Message
Jun 15, 2001
134
67
10/2/2001
So What Customers Really Want?

Business users: drive revenue, improve efficiency
Find and access information needed search Understand whats important in context Tie things together relationship Get organized workflow Link to my business processes integration
Jun 15, 2001
135
What Customers Want?

Developers: reduce development cost and cycle time
Deal with expanding data sources integrated API Build application quickly objects, visual builders
Jun 15, 2001
136
68
10/2/2001
Where Should I Start From?

Never start from scratch (If its possible) Start with patterns patterns are everywhere:
Business patterns Customers needs patterns Architectural patterns Analysis patterns Design patterns Implementation patterns
Jun 15, 2001
137
Section Wrap-Up
Jun 15, 2001
138
69
10/2/2001
Section Wrap-Up
Each student will offer one comment about:
What went well today What the class struggled with What should be changed
Time: 30 minutes
Jun 15, 2001
139
70

OOAD Introduction

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOAD Introduction

Uploaded by

Copyright:

Available Formats

OOAD With UML And Rational Rose

Object-Oriented Analysis & Design

Jun 15, 2001

(c) 2001 24MB Software Development

Sharing Your Objectives

Less than 15 minutes

Jun 15, 2001

(c) 2001 24MB Software Development

OOAD With UML And Rational Rose

Why This Course? (Or Design Problem)

Jun 15, 2001

(c) 2001 24MB Software Development

By the end of this course, you should be able to:

Jun 15, 2001

(c) 2001 24MB Software Development

OOAD With UML And Rational Rose

Jun 15, 2001

(c) 2001 24MB Software Development

A Real- world Project Putting it all together

OOAD With UML And Rational Rose

Overview of the course:

Jun 15, 2001

(c) 2001 24MB Software Development

Module I: OO Paradigm Overview

Guidelines Activities and labs Conclusion

Jun 15, 2001

OOAD With UML And Rational Rose

Module II: UML Overview

Activities and labs

Jun 15, 2001

(c) 2001 24MB Software Development

Module III: Rational Rose Overview

Why Rational Rose?

Guidelines: Focus on: When the modeling work is done?

Jun 15, 2001

(c) 2001 24MB Software Development

OOAD With UML And Rational Rose

Module IV: Patterns Overview

What is pattern? Why Patterns?

Jun 15, 2001

(c) 2001 24MB Software Development

Part II. Requirements 1/2

Why doing requirements captures?

Jun 15, 2001

(c) 2001 24MB Software Development

OOAD With UML And Rational Rose

Part II. Requirements 2/2

Jun 15, 2001

(c) 2001 24MB Software Development

Part III. Architecture 1/2

What to do with Architecture?

Jun 15, 2001

(c) 2001 24MB Software Development

OOAD With UML And Rational Rose

Part III. Architecture 2/2

Architectural patterns and Subtractix

Jun 15, 2001

(c) 2001 24MB Software Development

Part IV. Analysis 1/2

Jun 15, 2001

(c) 2001 24MB Software Development

OOAD With UML And Rational Rose

Part IV. Analysis 2/2