Bài giảng Phân tích và thiết kế hệ thống hướng đối tượng: Chương 2

ƯỜ

Ạ Ọ

Ệ

NG Đ I H C CÔNG NGHI P TP.HCM Ệ KHOA CÔNG NGH THÔNG TIN

ươ

ng II

Ệ

CÁC KHÁI NI M C B N

ƯỚ

Ơ Ả Ố ƯỢ

TRONG H

NG Đ I T

NG

Ộ

N I DUNG

ố ượ

ề

2.1. T ng quan v phân tích thi

ế ế ướ t k h

ổ ng đ i t OOAD (ObjectOriented Analysis and Design)

ươ

2.2. Ca c đăc tr ng cua ph

ng pha p h

́ ng đô i

ượ

̣ ̉

2.3. Gi

́ ng đô i t

́ ngượ ́ ươ ơ i thiêu vê h ư

̀ ng: Object va ́ ́ class, ca c đăc tr ng cua class: kê th a, đo ng ̀ go i va đa hi nh

2.4. Unified Modeling Language (UML) 2.5. Tiê n tri nh RUP

̣ ̉

Ổ

Ề

T NG QUAN V OOAD

• Mô hình h

ướ ố ượ ớ ể ệ ậ ng gi

ế ế ộ i thi u m t quan đi m l p ổ ớ ườ ng phái c ẳ t k khác h n so v i tr

ng đ i t trình và phân tích/thi ấ đi n (có c u trúc)

• B t đ u nhen nhóm vào nh ng năm cu i 60s và đ n đ u 90s

ữ ầ ố

ấ ổ ế ề ầ ể ắ ầ ở

ệ ầ ữ ng đ u tiên: Smalltalk,

ế tr nên r t ph bi n trong công nghi p ph n m m ữ ướ • Nh ng ngôn ng h ng đ i t ệ ấ

• Hình thành các ph

ố ượ Eiffel. Sau đó xu t hi n thêm: Object Pascal, C++, Java… ố ươ ng pháp phân tích/thi ế ế ướ t k h ng đ i

ượ t ng.

Ổ

Ề

T NG QUAN V OOAD

• Chi n l

ố ượ ầ ng là quan ng đ i t

• Các tính ch t c a đ i tu ng

– Ð i t

•

ự ế ượ ế ớ sát th gi ướ ng

•

ế ớ ượ ự ể ấ ự c trong th gi i th c (trong

ự ễ

ạ ế ế t k ) ủ

ề ể c phát tri n ph n m m h ố ượ ư ậ i th c nh t p các đ i t ợ ấ ủ ố ể ố ượ ng có th là th c th nhìn th y đ pha phân tích yêu c u) ầ ể ệ ố ể bi u di n th c th h th ng (trong pha thi – Ð i t ố ượ ệ ố ượ ấ ị ng có trách nhi m qu n lý tr ng thái c a mình, ầ 

ả ng khác khi có yêu c u ố ượ ng

ấ

ệ ố • Ch c năng h th ng: các d ch v đ ữ ế

ụ cung c p d ch v cho đ i t ữ ệ d li u và hàm cùng gói trong đ i t ứ ụ ượ ị ố ượ ư ế nh th nào gi a các đ i t ố ượ ổ ạ đ i tr ng thái bên trong đ i t ầ c yêu c u và cung c p ng, không quan tâm đ n thay ng

Ổ

Ề

T NG QUAN V OOAD

• Các đ i t

ng đ ố ượ ặ ộ ớ ộ ố ượ – Các đ i t ượ c phân thành class ề ng thu c cùng l p đ u có đ c tính (thu c

tính và thao tác) chung

ướ ố ượ ả ng t p trung vào c thông tin và hành vi

ệ ố ề ẻ ả

• H ng đ i t • Cho kh năng xây d ng h th ng m m d o, “co dãn” ng pháp này d a trên các nguyên t c sau • Ph

– Tính đóng gói – K th a ế ừ – Ða hình

ậ ự ự ươ ắ

Ổ

Ề

T NG QUAN V OOAD

• DataOriented

• Class Model

–

static structure

– what objects are in the

system?

– how are they related?

• ActionOriented

• Dynamic Model

– behavioral aspects – what events occur in the

system

– when do they occur and in

• Both Data and Actions

what order?

• Functional Model

– data transformations – “what” does the system do

Ổ

Ề

T NG QUAN V OOAD

Static Diagrams

Class Diagrams

Use-Case Diagrams

Object Diagrams

Sequence Diagrams

Models

Communication Diagrams

Component Diagrams

Dynamic Diagrams

Deployment Diagrams

State Machine Diagrams

Activity Diagrams

Ổ

Ề

T NG QUAN V OOAD

ướ ế ế ướ ố ượ c phân tích và thi t k theo h ng đ i t ng

•

Các b • Class Modeling • Dynamic Modeling • Functional Modeling • Add Operations to the Class Model

Iterate and refine the models – After the first iteration, steps may occur in parallel

– All models must be kept in synch as changes are made

or out of order

Ư

Ủ

ƯỚ

Ố

NG Đ I

ƯỢ

CÁC Đ C TR NG C A H T

Ặ NG

̀ ư

ượ

́ ơ

ng va l p cu thê (Abstract and Concrete

́ ơ L p tr u t Class)

̣ ̉

Review: Encapsulation Illustrated

• Professor Clark

Professor Clark

cceptC

ourse

Offering()

Name: J Clark

needs to be able to teach four classes in the next semester.

Employee ID: 567138

SubmitFinalGrades()

HireDate: 07/25/1991

Status: Tenured

Discipline: Finance

SetMaxLoad(4)

MaxLoad: 4

(

)

TakeSabbatical()

MODULARITY

• For example, break

Billing System

complex systems into smaller modules.

Course Catalog System

Course Registration System

Student Management System

HIERARCHY

Asset

Increasing abstraction

BankAccount

Security

RealEstate

Savings

Checking

Stock

Bond

Decreasing abstraction

Elements at the same level of the hierarchy should be at the same level of abstraction.

Ơ

ƯƠ

ƯỢ

I THIÊU VÊ H

NG ĐÔ I T

ớ ự ố ượ

ệ

ng, s đóng bao • L p và đ i t ụ ộ • Thu c tính, tác v , thông đi p ừ ế ộ • Bao g p, th a k • Tính đa hình, tính vĩnh c uử

Ố ƯỢ

Đ I T

NG (OBJECT)

ố ượ

ố ồ ng (Object): ố ượ i bao g m các đ i Đ i t • Mô hình đ i t

ố ế ớ ệ ng quan ni m th gi ớ ươ ng tác v i nhau. ng(object) sinh s ng và t

ồ t • Đ i t

ị

• VD:

ữ ệ ụ ấ ị ệ ự ộ ượ ố ượ ng bao g m: – D li u: mang m t giá tr nh t đ nh ộ – Tác v : th c hi n m t công vi c nào đó ệ

Ố ƯỢ

Đ I T

NG (OBJECT)

ố ượ ng (Object):

Đ i t • VD:

(Person)

Person

Joe Smith age=39 weight=158

name age weight

(Person)

Mary Wilson age=27 weight=121

Ớ

L P (CLASS)

• L p đ nh nghĩa m t t p h p các tác v và thu c tính mà đ c

ặ ộ ợ

ủ ố ượ ừ ớ ượ ụ ể ụ ộ ậ ị ớ ả ầ ủ ấ đ y đ c u trúc và hành vi c a đ i t ố ượ c c th hóa t ng(instance) đ ng l p

ộ t • Đ i t ộ • Đóng bao: g p thu c tính và tác v trong

ồ ờ ụ ớ ạ i h n cách truy

ộ ố ượ ấ ả ng ph i thông

m t đ i t ng đ ng th i gi ườ ộ xu t các thu c tính đó(th ụ qua tác v get, set)

Operations catch, throw pass, kick, hand-off

Class ball football baseball

Attributes radius, weight air pressure liveness

hit, pitch, tag

Ớ

L P (CLASS)

ể ứ ữ ệ ặ ổ ộ ơ là m t vùng có th ch a d li u (đ n ho c t

ộ ằ ả ộ

ị

ể ệ • D li u mà thu c tính th hi n n m trong m t kho ng giá ể ở ộ ượ ị ủ ấ ả ủ ố ạ ị ộ • Thu c tính: ợ ủ ớ h p) c a l p ữ ệ ị tr nào đó đ • Giá tr c a t c xác đ nh b i ki u t c các thu c tính xác đ nh tr ng thái c a đ i

ộ ố ượ ủ ngượ – VD: m t đ i t ng c a Circle có (Radius, x, y) = (2,

• Thu c tính có th b che d u ho c truy xu t đ

1.8,6.4) ộ ấ ượ ừ ể ị ấ ặ c t bên

ngoài: public, protected, private

Ớ

L P (CLASS)

Professor

name employeeID : UniqueID hireDate status discipline maxLoad

Professor J Clark

+ submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass()

Ớ

L P (CLASS)

ự ạ ầ • Có 2 lo i t m v c:

– T m v c l p: thu c tính chung cho t ộ

ự ớ ấ ả ố ượ t c đ i t ủ ng c a

– T m v c đ i t

ự ố ượ ủ ừ ố ượ ng: thu c tính c a t ng đ i t ng (có

ị

ỉ ả ữ ệ ng d li u mà b n thân

ầ 1 l pớ ầ ể ậ ủ ộ ể ắ ữ ộ th mang giá tr khác nhau) ộ • B c c a thu c tính ch ra s l thu c tính có th n m gi ố ượ : 0..1, 1..*, 10…20.

Ớ

L P (CLASS)

• Tác v (operation)

ầ ừ ụ ể phía

Là m t d ch v có th yêu c u t ệ

• D u hi u nh n d ng c a tác v (signature) xác đ nh các

ị ụ ố ượ đ i t ấ

ộ ị ng đ th c hi n hành vi ạ ệ ố ể ự ậ ề

ứ ươ ụ ả ả ề thông s truy n cũng nh k t qu tr v . ệ ụ

ấ

ừ ế bên ngoài c override trong các l p con th a k

ể ị ể ượ ự ng(abstract): không có hi n th c

• M t s ngôn ng l p trình cho phép đ nh nghĩa:

ữ ậ ệ ị

ủ ư ế ự ủ ầ • Ph ng th c (method) là ph n hi n th c c a tác v ấ ừ ặ ụ • Tác v có th b che d u ho c truy xu t t ớ ụ • Tác v có th đ – Tr u t ừ ượ ộ ố – Tác v kh i t o(constructor) ụ ở ạ – Tác v h y (destructor) ụ ủ

Ớ

L P (CLASS)

Association Aggregation Composition Generalization Dependency Realization

Class Relationships:

Ớ

Association and Links

L P (CLASS)

• Quan hê ng nghĩa gi a 2 hay nhi u l p xa c đinh kê t nô i

́ ́ ̣

́ ́ ́ ́ ̣ ữ ữ ́ ề ơ ́ ơ ữ ̉

ữ ể gi a ca c gi a ca c đi n hình cua hai l p đo . has-capital

Country

City

Class diagram

name

(Country)

has-capital

(City)

Canada

Ottawa

(Country)

has-capital

(City)

Object diagram

France

Paris

(Country)

has-capital

(City)

Austria

Vienna

Ớ

L P (CLASS)

Unspecified

Exactly One

Zero or More

0..*

Zero or More

One or More

1..*

Zero or One (optional scalar role)

0..1

Specified Range

2..4

Multiple, Disjoint Ranges

2, 4..6

Ớ

Aggregation

L P (CLASS)

̀ ̣ ạ ̣ ̉ ể ặ • Aggregation la môt d ng đ c biêt cua association dùng đ

́ ̣ mô hình mô i quan hê wholepart

• La mô i quan hê “Is a partof”.

̀ ́ ̣

Ớ

Composition

L P (CLASS)

ạ ̣

́ ̀ ợ ử • Composition là 1 d ng association ma h p t ạ ́ ư ấ ̀ ẳ ả ầ ̉

́ ỏ ụ co nhiêm v ́ qu n lý ca c tha nh ph n cua no –ch ng h n nh c p pha t hay huy b̉

Ớ

L P (CLASS) – Association, Aggregation and Composition

́ ́ ̣ ữ ơ

́ Mô i quan hê gi a ca c l p (relationship) • Liên kê t (Association)

́ – S d ng (usea) ử ụ

• H p tha nh (Composition)

• Kê t tâp (Aggregation) – Strong association – hasa/isapart ̀ ợ – Strong aggregation – Share lifetime

́ ̣

Ớ

L P (CLASS) – Association, Aggregation and Composition

• Aggregation – University and Chancellor

ưở

Chancellor)

̣ University), hiêu tr

ạ ng Đ i hoc (

ng (

ạ

́ ườ – Nê u không co tr ạ i. không thê tô n t ́ Chancellor, University vâ n co thê tô n t – Nê u không co

• Composition – University and Faculty ́ i nê u không co ca c giang viên (

Faculty) va ̀

– University không thê tô n t ạ i (share timelife)

ờ

̉ ̉

́ ặ ơ ̉ University gă n ch t v i th i gian sô ng cua

ượ ạ c l ờ • Th i gian sô ng cua Faculty

ượ

ạ

̀ c giai pho ng thi

University không thê tô n t

̀ i va

• Nê u ́ Faculties đ ượ ạ c l

̉ ̉

Tông qua t ho a (Generalization)

• Mô i quan hê gi a ca c l p trong đo môt l p chia se c u

́ ́ ̉ ấ

̀ ơ ́ ̣ ữ ̀ ̀ ơ ặ ̣

̀ ư ị ́ ́ tru c va /ho c ha nh vi v i môt ho c nhiê u l p kha c ́ ̀ ng ho a trong

́ ́ ́ ́ ́ ̣ ơ ́ ơ ượ ́ ̀ ́ ́ ặ ư ư ̣ ̣ ư ̀ môt ho c nhiê u l p cha

ơ ơ

ặ ấ ự • Xa c đ nh s phân c p vê m c đô tr u t ̀ ́ ơ đo l p con kê th a t ̀ – Đ n kê th a (Single inheritance) ư ̀ư – Đa kê th a (Multiple inheritance)

́ ́

• La mô i liên hê “la môt lo i” (“is a kind of”)

̀ ̀ ạ ̣ ̣

Tông qua t ho a (Generalization)

ấ ừ ớ

ẫ

ớ

ấ ừ ớ

ẫ

ớ

ơ ồ L p B d n xu t t

l p A, l p C d n xu t t

l p B

S đ 1:

Tông qua t ho a (Generalization)

• Ví d đ n k th a: M t l p k th a t

̀ ́ ́ ế ừ ế ư ộ ơ ụ ơ ư ̣ ơ ́ ̀ MÔT l p kha c

Tông qua t ho a (Generalization)

• Ví d đa k th a:M t l p co th k th a t

̀ ́ ́ ́ ể ế ư ế ừ ộ ơ ư ơ ̀ ̀ nhiê u l p

ụ kha c ́

ượ

́ ơ

̀ ư

ng va l p cu thê (Abstract and Concrete

́ ơ L p tr u t Class)

̣ ̉

̀ ư

́ ́ ́ ượ ng

ượ ́ ư ng th c tr u t ể ng không th co đô i t ượ ng

• L p cu th co th co đô i t

́ ́ ́ ́ ̀ ư ơ • L p tr u t ́ – Ch a ph ươ ư ̃ư – Ch nghiêng ơ ̣ ể ể ượ ng

Tông qua t ho a (Generalization)

Advantages of Inheritance • Reusability – reuse public methods of base class • Extensibility – Extend the base class • Data hiding – base class keeps some data private 

• Rapid prototyping

derive class cannot change it

ĐA HÌNH (POLYMORPHISM)

́ ́ ự ươ ộ ̉ ́ • Kha năng che giâ u ca c th c thi kha c nhau d ́ i m t giao

̣ diên duy nhâ t. ́

• Ví d đa hình (Polymorphism)

ụ

ĐA HÌNH (POLYMORPHISM)

• Ví d th c thi đa hình (Polymorphism)

ụ ự

THÔNG ĐI P – Ệ Message

ộ ố

ụ ế

ộ

ọ

• Thông đi p là m t phép g i tác v đ n m t đ i

ượ t

ầ

ệ ụ ể ng c th . ồ ệ • Thông đi p g m 3 ph n: – Đ i t ố ượ ng đích – D u hi u nh n d ng tác v mu n g i ọ ạ ệ ấ – Danh sách thông s g i ố ọ

ụ ậ ố

Class Modeling An Example

FastData Inc. wants a subsystem to process office supply orders via the Web. The user will supply via a form their name, password, account number, and a list of supplies along with an indication of the quantities desired. The subsystem will validate the input, enter the order into a database, and generate a receipt with the order number, expected ship date, and the total cost of the order. If the validation step fails, the subsystem will generate an error message describing the cause of the failure.

Class Modeling Concise Problem Definition

•Define the problem concisely – Use only a single sentence

“FastData, Inc. employees may order office supplies via the Web and receive a receipt confirming the order”

•This is the first step towards identifying the classes of the subsystem

Class Modeling Informal Strategy

•Identify the constraints governing the system

– Use only a single paragraph

“FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.” •We now have more information to be used in identifying classes for the subsystem

Class Modeling Formalize the Strategy

• Identify the nouns of the description, which serve as the basis for identifying the subsystem’s classes.

– Look for outofdomain nouns (and throw them out!) – Look for abstract nouns (use these for attributes) – The remaining nouns are good candidates!

Nouns

• OutofDomain

–

Internal Web

• Good Candidates – employee –

• Abstract

–

item (was office supplies) receipt

– order – order database – error message

–

– user name – user password – account number – order number – ship date – total cost list of supplies

– office supplies > item

• Notes We have decided not to worry about the Web in this design. Instead we focus on the inputs and outputs and defer the Web details until later.

Class Model

order DB

order

employee

name password

number account total cost

error message

receipt

item

explanation

order number ship date total cost

name quantity price

Class Model, continued

Since both receipts and error messages will be generated as output it might make sense to have them as subclasses of a more general class. We do not know enough yet to assign it attributes however.

response

error message

receipt

explanation

order number ship date total cost

Class Modeling Relationships

employee

order DB

order

name password

number account total cost

receipt

item

error message

explanation

order number ship date total cost

name quantity price

Class Diagram versus Structure Diagram

Structure Diagram

Class Diagram

Student

shared : Schedule [0..*]

0..*

comp

shared

comp : Schedule [0..*]

Schedule

ụ

Ví d Structure Diagram

Course Registration System

: StudentManagementSystem

: CourseCatalogSystem

: BillingSystem

Ủ Ầ

Ố ƯỢ Ố Ớ ƯỚ Ề Ạ CÁC GIAI ĐO N C A CHU TRÌNH PHÁT TRI N PH N M M Đ I V I MÔ HÌNH H NG Đ I T Ể NG

• Phân tích h OOA)

ướ ng đ i t ng( ố ượ Object Oriented Analysis

ng đ i t ng đ i t ng( ng ố ượ Object Oriented Design – OOD) ố ượ (Object Oriented Programming

ế ế ướ t k h • Thi ướ ậ • L p trình h OOP)

Ố ƯỢ ƯỚ NG Đ I T NG

PHÂN TÍCH H (OBJECT ORIENTED ANALYSIS – OOA)

ề

• Phát tri n mô hình chính xác và súc tích c a v n đ ể ở ế ớ th gi • Ánh x các th c th

ủ ấ ố ượ ể ạ ự ế ự đ i t i th c ng trong thi t

ộ ấ ự ự ề ể

• Ch a các th c th trong m t v n đ có th c. ề ấ • Gi

ư ủ ệ ẫ nguyên m u v c u trúc, quan h cũng nh hành vi c a

k .ế ứ ữ chúng.

ể ố ượ

ng): ?

ơ • Ví d : C a hàng bán xe h i

ự

ể

– Th c th (đ i t – T

ệ ữ ng tác và quan h gi a các th c th : ?

ụ ử ự ươ

Ế Ố ƯỢ Ế ƯỚ NG Đ I T NG

THI T K H (OBJECT ORIENTED DESIGN – OOD)

ạ ế ự ạ • T o thi

ứ

ả ủ ứ ế ế ự ứ

• Đ nh nghĩa các : ứ ộ

ề ớ

ố

ả ượ

ề

ỉ

ợ

ớ

thu c tính (attributes) – m i quan h c a m t hay nhi u l p (class) ộ ệ ủ  quy t đ nh chúng c n ph i đ ầ

c đi u ch nh sao cho phù h p v i môi

ườ

ế ị ể ng phát tri n

t k d a trên k t qu c a giai đo n OOA, d a trên ầ các yêu c u ch c năng, phi ch c năng – Yêu c u ch c năng? ứ ầ – Yêu c u phi ch c năng? ầ ị – ch c năng, th t c (operations), ủ ụ –

ộ

ớ

ươ

ạ ộ

ứ

tr ể ư ố ượ ị • Tĩnh: bi u th các l p và đ i t ữ • Đ ng: bi u th t

ng tác gi a các l p và ph

ng th c ho t đ ng

ủ

ể ể chính xác c a chúng.

ồ • Đ a ra các bi u đ : ớ ị ươ

Ậ ƯỚ Ố ƯỢ NG Đ I T NG (OBJECT ORIENTED

•

L P TRÌNH H PROGRAMMING OOP)

Java • C++ • Smalltalk

What Is an Interface?

• A declaration of a coherent set of public features and

obligations. – A contract between providers and consumers of services.

• Provided interface The interfaces that the element

Examples of interfaces are:

• Required interface The interfaces that the element

exposes to its environment.

requires from other elements in its environment in order to be able to offer its full set of provided functionality.

Example: A Provided Interface

Manufacturer A

Elided/Iconic Representation (“ball”)

Manufacturer B

Remote Sensor

Manufacturer C

Manufacturer A

<> RemoteSensor

Manufacturer B

Canonical (Class/Stereotype) Representation

Manufacturer C

What Is an Interface?

Remote Control

Elided/Iconic Representation (“socket”)

Remote Sensor

<> Remote Sensor

Remote Control

Canonical (Class/Stereotype) Representation

Example: A Required Interface

What is a Port?

• A port is a structural feature that encapsulates the interaction between the contents of a class and its environment. – Port behavior is specified by its provided and required

• Permits the internal structure to be modified without

affecting external clients – External clients have no visibility to internals

• A class may have a number of ports

– Each port has a set of provided and required interfaces

interfaces

What is a Port?

• A port is shown as a small square with the name

placed nearby.

portName

• Ports may be public, protected or private

Port Types

• Ports can have different implementation types

– Service Port Is only used for the internal

implementation of the class

– Behavior Port Requests on the port are

implemented directly by the class

– Relay Port – Requests on the port are transmitted

to internal parts for implementation

Port Types

Structured Class Name

Behavior Port

Service Port

Relay Port

partB

partA

Review: Diagram Depiction

• Each diagram has a frame, a heading

compartment in the upper left corner, and a contents area. – If the frame provides no additional value, it may be omitted and the border of the diagram area provided by the tool will be the implied frame.

What Are Notes?

• A comment that is added to include more

information on the diagram

• May be added to any UML element • A “dog eared” rectangle • May be anchored to an element with a dashed

line

MaintainScheduleForm

There can be up to one MaintainScheduleForm per user session.

Questions

• What are the four basic principles of object orientation? Provide a brief description of each.

• What is an object and what is a class? What is

the difference between the two?

• What is a class relationship? Give some

examples.

• What is polymorphism? • What is an interface?

UNIFIED MODELING LANGUAGE (UML)

́ ể ữ ̣

• La ngôn ng mô hình ho a (UML) dùng đ xa c đinh, xây ả i kê t qu (artifact) cua qua trình pha t

́ ́ ́ ́ ữ ạ ̉

ư ́ ̣ ̀ ̀ ự d ng va l u tr l ể tri n hê thô ng.

́ ̀ ̀ ́ ́ ư ơ ươ ̣ ấ • UML ra đ i nhă m ch m d t cuôc chiê n ca c ph ng

•

́ư ồ ̣

́ ́ ̃ ̀ ̀ ạ ấ

́ ữ ̉ th c (“method wars”) trong công đ ng OO. “Three Amigos”: Ivar Jacobson, Grady Booch va Jim ươ ợ Rumbaugh đa h p nh t ca c ph ng pha p OO va t o ra ngôn ng mô hình ho a chuân UML

UNIFIED MODELING LANGUAGE (UML)

ể ủ

ử

ị

L ch s phát tri n c a UML

UNIFIED MODELING LANGUAGE (UML)

• UML is an objectoriented modeling language for modern

• Pha t tri n phân m m theo h

́ ́ ượ ng (OO) la mô

ươ ́ ề ̀ ́ ̣

• Áp d ng quy trình

–

software systems. ể ́ ơ thê gi ́ ̀ ́ ng đô i t ́ ự i quyê t ba i toa n thông qua s ượ ả ươ ̉ ̀ ng (“objects”) t t

ả i thât va gi ́ ́ ng ta c cua ca c đô i t ụ Iterative

– Use casedriven – Architecturecentric ể

• Va o viêc pha t tri n mô hình thiê t kê môt ca ch thích h p

̀ ́ ́ ́ ́ ợ ̣ ̣

UNIFIED MODELING LANGUAGE (UML)

ữ ệ ố ứ ụ

ệ

ệ ố Các h th ng ng d ng UML • H th ng thông tin

ầ (Information System)

ể UML là ngôn ng dùng đ ậ ấ l p và cung c p tài li u. Tài ệ ồ li u g m có: ề • Ghi chép v các yêu c u ủ ệ ố c a h th ng

ệ ố ỹ

ủ ệ ố ậ • H th ng k thu t (Technical System)

• H th ng nhúng (Embeded

ế t kế ế

ự ệ ố System) ệ ố ố • H th ng phân b

• Ki n trúc c a h th ng • Thi • Mã ngu nồ ạ ế • K ho ch d án • Tests • Các nguyên m uẫ

ệ ố

ầ

(Distributed System) ị • H th ng giao d ch (Business System) ệ ố ề • Ph n m m h th ng (System SoftWare)

UNIFIED MODELING LANGUAGE (UML)

UML defines 13 diagrams that describe 4+1 architectural views 4+1 architectural views model was proposed by Philippe Kruchten, IBM

UNIFIED MODELING LANGUAGE (UML)

Structural Things

Class, interface, collaboration, use case, components, nodes

Interaction, State machine

Behavior things

Package

Group things

Structural Diagram

-Class diagram -Object diagram -Component diagram -Deployment diagram

Note

Annotation things

Things

Diagram

Structural Relationship

Behavioral Diagram

Dependency, Aggregation, Association, Generalization

- Use case diagram - Activity diagram - Interaction diagram - State machine diagram

Behavior Relationship

Communication, Includes, Extends, Generalizes

Relationship

UNIFIED MODELING LANGUAGE (UML)

UML defines 13 diagrams that describe 4+1 architectural views 4+1 architectural views model was proposed by Philippe Kruchten, IBM

UNIFIED MODELING LANGUAGE (UML)

ể

ồ Bi u đ Use case

UNIFIED MODELING LANGUAGE (UML)

ồ ớ

ể

Bi u đ l p (Class diagram)

UNIFIED MODELING LANGUAGE (UML)

ồ ố ượ

ể

Bi u đ đ i t

ng (Object diagram)

UNIFIED MODELING LANGUAGE (UML)

ồ ạ

ể

Bi u đ tr ng thái (State diagram)

UNIFIED MODELING LANGUAGE (UML)

ể

ự

ồ Bi u đ trình t

(Sequence diagram)

UNIFIED MODELING LANGUAGE (UML)

ồ ươ

ể

Bi u đ t

ng tác (Communication Diagram)

UNIFIED MODELING LANGUAGE (UML)

ạ ộ

ể

ồ

Bi u đ ho t đ ng (Activity Diagram)

UNIFIED MODELING LANGUAGE (UML)

ể

ầ

ồ

Bi u đ thành ph n (Component Diagram)

UNIFIED MODELING LANGUAGE (UML)

ồ ể

ể

Bi u đ tri n khai (Deployment Diagram)

RATIONAL UNIFIED PROCESS (RUP) IMPLEMENTS BEST PRACTICES

QUY TRÌNH RUP(Rational Unified Process)(1)

ấ ồ ể

• Do hãng Rational phát tri nể ợ • Là quy trình phát tri n h p nh t g m các pha (phase) và các giai đo n công vi c (workflow) mà đ i th c hi n d án c n tuân theo.

ự ự ệ ệ ầ ạ ộ

•

ượ ộ ọ đ c g i là chu ệ • Quá trình th c hi n qua toàn b các pha

ả ủ ế ể ọ c g i là các

ồ ộ ự trình phát tri nể ượ K t qu c a quá trình phát tri n các RUP đ ệ Artifact, bao g m các mô hình và các b tài li u.

QUY TRÌNH RUP(Rational Unified Process)(1)

• Các mô hình:

ố

ử ụ t kế ế

ể ử

Mô hình nghi p vệ ụ Mô hình tình hu ng s d ng Mô hình phân tích thi Mô hình tri n khai ệ Mô hình th nghi m

• Các tài li u:ệ ệ ộ

ệ ố

ề

ầ

ị B tài li u v xác đ nh yêu c u h th ng

ệ

ộ

B tài li u thi

ế ế t k

ệ ậ

ộ

B tài li u l p trình

ể

ộ

ệ B tài li u tri n khai

QUY TRÌNH RUP(Rational Unified Process)(1)

Ủ

Ạ

Ệ

CÁC GIAI ĐO N CÔNG VI C C A RUP(1)

mô

ệ ụ • Mô hình hóa nghi p v (business modeling):

ả ấ

ị

ả

ệ ụ c u trúc và quy trình nghi p v . ầ • Xác đ nh yêu c u (requirement):

mô t ử ụ

ố

ằ

ươ

ụ ệ nghi p v ng pháp “tình hu ng s d ng” (use case

ế ế

mô t

t k (analysis & design):

b ng ph base method) • Phân tích và thi ệ ố

ơ ồ

ả ế ki n trúc h th ng thông qua các s đ phân tích ế ế t k . thi ậ

ươ

ự

ệ

th c hi n các vi c xây d ng ch

• L p trình:

ệ ữ ậ

ằ

ự trình b ng ngôn ng l p trình.

Ủ

Ạ

Ệ

CÁC GIAI ĐO N CÔNG VI C C A RUP(1)

ị

ố

ả

ố

ệ

ử

ệ mô t ế

ư ệ ố

ầ

đ a h th ng ph n m m vào s d ng.

ị ấ

ả

ử ử các tình hu ng và k ch b n th • Th nghi m: ầ ệ ệ nghi m, ti n hành th nghi m h th ng ph n m m.ề ể • Tri n khai: ả • Qu n tr c u hình và qu n tr thay đ i: ấ ủ

ề ị ự ợ

ầ ự ị ự

ệ

ả

ộ

qu n lý toàn b quá trình làm vi c

ử ụ ổ ki m ể ổ soát các thay đ i và duy trì s h p nh t c a các thành ph n d án. • Qu n tr d án:

ạ ầ

ả

ầ

ế ể

ả đ m b o các h t ng c n thi

t đ có

• Môi tr ể

ng: ể ượ ệ ố

ả ủ ự c a d án. ườ th phát tri n đ

c h th ng

Ủ

CÁC PHA C A RUP(1)

ở ộ

•

ể ủ

ủ ự

ủ

ể ế ị

ế ụ

ự

ể

ị ố

• Kh i đ ng (Inception) – Tìm hi u nghi p v ệ ụ ể – Xác đ nh ph m vi c a d án ạ ụ .Cu i pha này: ki m tra các m c tiêu c a quá trình phát tri n c a d án và quy t đ nh có ti p t c quá trình phát tri n hay không

ả

ị ự

• Phác th o (Elaboration) – Phân tích nghi p vệ ụ – Xác đ nh ki n trúc phù h p ế ợ – Xây d ng k ho ch cho d án ự ế ạ – Gi

ế ủ

ạ ử

ự

ể

ố t c a ệ ố h th ng, s l a ch n v ki n trúc và cách x lý các r i ro có ế ụ ể ồ th đ ng th i quy t đ nh có ti p t c chuy n sang pha xây d ng hay không

i h n y u t ầ ự ự ờ ấ ớ ạ ế ố ủ r i ro cao nh t ể ụ • Cu i pha này c n ki m tra các m c tiêu và ph m vi chi ti ủ ề ế ọ ế ị

Ủ

CÁC PHA C A RUP(1)

ự

• Xây d ng (Construction) • Phát tri n s n ph m đ y đ

ể ả ẩ ể ớ ầ ủ  chuy n giao t i ng ườ ử i s

ấ ế ế ầ ị d ng. ụ • Hoàn t t k và hoàn

ế thành vi c l p trình ng d ng. ẵ ứ ệ ố ạ ộ ư ố t các yêu c u còn thi u, làm m n thi ệ ậ ụ ể • Cu i pha: ki m tra h th ng s n sàng ho t đ ng ch a?

ể

ể ế

– Chuy n giao (Deployment) ườ • Tri n khai h th ng đ n ng ế ể • Ghi nh n các v n đ phát sinh(n u có) và các h n ch đ

i dùng ế ậ ạ

ề ả ệ ố ệ ố ấ hoàn thi n phiên b n cu i cùng.

Ỗ Ợ

Ệ Ố

Ầ

Ề H TH NG PH N M M H TR CHO RUP

• Rational Requisite Pro • Rational Rose • Rational XDE • Rational Clear Case

Ỏ

Ậ

CÂU H I VÀ BÀI T P

• Câu 1. Ba tác gi ể

ả ầ ậ gia nh p công ty ph n M m ề Rational đ ể

• Câu 2. T ch c nào hi n nay ch u trách nhi m v chu n

phát tri n UML là ai? ổ ứ ệ ề ệ ẩ ị

UML?

ử ụ

• Câu 3. Lý do s d ng UML? • Câu 4. H ng nhìn là gì? UML bao g m nh ng h

ướ ữ ồ ướ ng nhìn

ệ ồ ủ ể t kê các bi u đ c a UML?

ệ ộ t mô hình tĩnh và mô hình đ ng trong UML? nào? • Câu 5. Li • Câu 6. Phân bi

Bài giảng Phân tích và thiết kế hệ thống hướng đối tượng: Chương 2 - ĐH Công nghiệp TP.HCM

ƯỜ

Ạ Ọ

Ệ

NG Đ I H C CÔNG NGHI P TP.HCM Ệ KHOA CÔNG NGH THÔNG TIN

ươ

Ệ

CÁC KHÁI NI M C B N

ƯỚ

Ơ Ả Ố ƯỢ

TRONG H

NG Đ I T

NG

Ộ

Ổ

Ề

Ổ

Ề

Ổ

Ề

Ổ

Ề

Ổ

Ề

Static Diagrams

Class Diagrams

Use-Case Diagrams

Object Diagrams

Sequence Diagrams

Models

Communication Diagrams

Component Diagrams

Deployment Diagrams

State Machine Diagrams

Activity Diagrams

Ổ

Ề

Ư

Ủ

ƯỚ

Ố

ƯỢ

Ặ NG

Review: Encapsulation Illustrated

Ơ

ƯƠ

ƯỢ

Ố ƯỢ

Ố ƯỢ

(Person)

Person

(Person)

Ớ

Operations catch, throw pass, kick, hand-off

Class ball football baseball

Attributes radius, weight air pressure liveness

Ớ

Ớ

Ớ

Ớ

Ớ

Ớ

Country

City

Class diagram

(Country)

(City)

(Country)

(City)

Object diagram

(Country)

(City)

Ớ

Ớ

Ớ

Ớ

Ớ

ơ ồ L p B d n xu t t

Class Modeling ­ An Example

Class Modeling ­ Concise Problem Definition

Class Modeling An Example

Class Modeling Concise Problem Definition

Class Modeling Informal Strategy

Class Modeling Formalize the Strategy

Class Modeling Relationships