object oriented analysis and design with uml 2 0 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0 PowerPoint Presentation
Download Presentation
OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0

Loading in 2 Seconds...

play fullscreen
1 / 32

OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0 - PowerPoint PPT Presentation


  • 129 Views
  • Uploaded on

Bé m«n C«ng nghÖ phÇn mÒm KHOA CÔNG NGHỆ THÔNG TIN TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI. OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0. Bài 6. Xác định các phần tử thiết kế. Nội dung. Xác định các phần tử thiết kế Hệ thống con (Subsystem) Tính tái sử dụng lại (Reusability)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0' - brian-hartman


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
object oriented analysis and design with uml 2 0

Bé m«n C«ng nghÖ phÇn mÒmKHOA CÔNG NGHỆ THÔNG TINTRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

OBJECT-ORIENTED ANALYSIS AND DESIGN WITH UML 2.0

Bài 6. Xác định các phần tử thiết kế

n i dung
Nội dung
  • Xác định các phần tử thiết kế
  • Hệ thống con (Subsystem)
  • Tính tái sử dụng lại (Reusability)
  • Mô hình phân tầng trong quá trình thiết kế
m c ch
Mục đích
  • Phân tích sự tương tác của các lớp phân tích và xác định các thành phần trong mô hình thiết kế
    • Lớp thiết kế (design class)
    • Hệ thống con (Subsystem)
    • Giao diện hệ thống con (Subsystem interface)
slide4

Mô hình thiết kế

Hướng dẫn dự án

Đặc tả phụ trợ

Mô hình phân tích

Xác định các phần tử thiết kế

Xác định

các phần tử

thiết kế

chuy n i l p ph n t ch th nh c c ph n t thi t k

<<boundary>>

<<control>>

<<entity>>

<<boundary>>

Chuyển đổi lớp phân tích thành các phần tử thiết kế

Các lớp phân tích

Các phần tử thiết kế

<<subsystem>>

Subsystem

<<subsystem>>

Subsystem

Ánh xạ nhiều – nhiều

t m ki m c c l p thi t k
Tìm kiếm các lớp thiết kế
  • Một lớp phân tích ánh xạ trực tiếp thành một lớp thiết kế nếu
    • Nó là một lớp đơn giản
    • Mức độ trừu tượng hóa đơn giản
  • Các lớp phân tích phức tạp hơn có thể
    • Tách ra thành nhiều lớp
    • Trở thành một package
    • Trở thành một hệ thống con
    • Bất kỳ hình thức kết hợp nào
nh m c c l p thi t k

Package C

Package B

Nhóm các lớp thiết kế
  • Nhóm các lớp dựa trên nhiều yếu tố:
    • Phân bổ nguồn lực trong các đội phát triển
    • Tương ứng với từng loại người dùng
    • Hệ thống con đại diện cho các sản phẩm và dịch vụ đã có mà hệ thống sử dụng
  • Việc gộp nhóm hiệu quả giúp
    • Quản lý khả năng sử dụng lại
    • Bảo dưỡng hệ thống

<<subsystem>>

Subsystem C

nh m c c l p bi n
Nhóm các lớp biên

Nếu giao diện của hệ thống sẽ chắc chắn có các thay đổi đáng kể

Nếu giao diện của hệ thống không chắc chắn có các thay đổi đáng kể

Các lớp biên được đặt

trong các package riêng biệt

Các lớp biên được gom nhóm với

các lớp liên quan về mặt chức năng

nh m c c l p li n quan v m t ch c n ng
Nhóm các lớp liên quan về mặt chức năng
  • Các tiêu chí – liên quan về mặt chức năng:
    • Thay đổi/xóa bỏ một lớp làm ảnh hưởng tới các lớp khác
    • Hai đối tượng tương tác với nhau bằng một lượng lớn thông điệp hoặc có mối giao tiếp phức tạp
    • Lớp biên có thể có liên quan về mặt chức năng đến một lớp thực thể nào đó nếu lớp biên biểu diễn lớp thực thể đó
    • Hai lớp tương tác hoặc cùng bị ảnh hưởng bởi thay đổi trong cùng một tác nhân
    • Một lớp tạo ra thể hiện của lớp khác
slide10

Nhóm các lớp liên quan về mặt chức năng

  • Các tiêu chí – KHÔNG nên đặt hai lớp vào cùng một package:
    • Hai lớp liên quan đến các tác nhân khác nhau
    • Một lớp bắt buộc và một lớp không bắt buộc
s ph thu c package element visibility
Sự phụ thuộc package: Element Visibility

PackageA

A

Chỉ có lớp public (+) có thể được tham chiếu bên ngoài package chứa nó

+ Class A1

+ Class A2

+ Class A3

Lớp protected (#) chỉ được truy cập trong gói chứa nó và gói kế thừa gói chứa nó

B

PackageB

Public visibility

+ Class B1

Lớp private (-) chỉ được truy cập trong gói chứa nó

- Class B2

Private visibility

Quy tắc của OO: Đóng gói (Encapsulation)

ph thu c gi a c c package
Phụ thuộc giữa các package

X

A

B

  • Các package không nên phụ thuộc lẫn nhau (cross-coupling)
  • Package ở tầng thấp hơn không nên phụ thuộc vào các package ở tầng trên
  • Nhìn chung, các phụ thuộc không nên bỏ qua các tầng ở giữa

A

Tầng cao hơn

X

X

Tầng thấp hơn

B

C

X= Vi phạm móc nối

v d registration package
Ví dụ: Registration Package

1

MainStudentForm

MainRegistrarForm

1

1

0..1

0..1

0..1

0..1

0..1

0..1

<<boundary>>

<<boundary>>

<<boundary>>

CourseRegistrationForm

OpenRegistrationForm

CloseRegistrationForm

1

1

1

1

1

1

1

<<control>>

<<control>>

<<control>>

CourseRegistrationController

OpenRegistrationController

CloseRegistrationController

v d university artifacts package

<<entity>>

Student

Ví dụ: University Artifacts Package

<<entity>>

CourseRegistrationInfo.

0..*

1

0..*

0..*

primaryCourses

alternateCourses

0..2

0..4

0..*

<<entity>>

<<entity>>

<<entity>>

instructor

Lecturer

CourseInfo

Subject

0..*

0..1

0..*

0..*

1

Prerequisites

0..*

1

CourseInfoList

n i dung1
Nội dung
  • Xác định các phần tử thiết kế
  • Hệ thống con (Subsystem)
  • Tính tái sử dụng lại (Reusability)
  • Mô hình phân tầng trong quá trình thiết kế
h th ng con subsystems
Hệ thống con (Subsystems)
  • Đóng gói hoàn chỉnh một hành vi nào đó
  • Thể hiện khả năng độc lập sử dụng các giao diện một cách rõ ràng
  • Có thể có nhiều

hình thức thực thi

<<subsystem>>

SubsystemA

ClassA1

ClassA2

W()

X()

<<Interface>>

InterfaceK

<<subsystem>>

X()

SubsystemB

W()

ClassB1

ClassB2

ClassB3

W()

X()

Z()

Y()

s d ng h th ng con
Sử dụng hệ thống con
  • Phân chia hệ thống thành nhiều phần hoạt động tương đối độc lập
    • Thay đổi một phần không ảnh hưởng tới các phần còn lại
  • Hệ thống con trong mô hình thiết kế sẽ trở thành thành phần trong quá trình cài đặt (components)
  • Hệ thống con có thể được sử dụng để thể hiện một sản phẩm có sẵn, hoặc một hệ thống ngoại vi trong quá trình thiết kế
t m ki m h th ng con
Tìm kiếm hệ thống con
  • Các phân tích có thể trở thành hệ thống con nếu:
    • Cung cấp chức năng phức tạp
    • Các lớp biên (giao diện với hệ thống bên ngoài)
  • Các sản phẩm có sẵn hoặc các hệ thống bên ngoài trong quá trình thiết kế (ví dụ thành phần):
    • Phần mềm giao tiếp
    • Hỗ trợ truy cập CSDL
    • Các kiểu và cấu trúc dữ liệu
    • Các tiện ích chung
    • Các sản phẩm theo ứng dụng

<<subsystem>>

Subsystem A

<<subsystem>>

Subsystem B

<<subsystem>>

Subsystem C

x c nh h th ng con

“Superman

Class”

Xác định hệ thống con

<<control>>ClassA

X()

W()

<<Interface>>

<<subsystem>>

InterfaceK

SubsystemA

ClassA1

ClassA2

X()

W()

X()

W()

giao di n cho h th ng con subsystem interface
Giao diện cho hệ thống con (Subsystem Interface)
  • Mỗi hệ thống con nên có một hoặc nhiều giao diện
  • Mô hình hóa các giao diện
    • Ánh xạ giao diện vào hệ thống con
    • Chỉ ra sự phụ thuộc của nó tới các lớp khác
    • Chỉ ra các hành động của giao diện
      • Tham số và kết quả
      • Kiểu dữ liệu
  • Đóng gói các giao diện

Một giao diện rõ ràng, ổn định

là giải pháp tốt cho việc tạo ra một kiến trúc hiệu quả

n i dung2
Nội dung
  • Xác định các phần tử thiết kế
  • Hệ thống con (Subsystem)
  • Tính tái sử dụng lại (Reusability)
  • Mô hình phân tầng trong quá trình thiết kế
3 t nh s d ng l i
3. Tính sử dụng lại
  • Mục đích
    • Sử dụng các giao diện để tìm cách sử dụng lại các hệ thống con hoặc các thành phần sẵn có trong hệ thống
  • Hướng dẫn
    • Tìm kiếm các gần giao diện giống nhau
    • Sửa giao diện cho phù hợp với giao diện sẽ sử dụng lại
    • Thay thế giao diện có khả năng sử dụng lại với giao diện sẵn có (sử dụng lại)
    • Ánh xạ hệ thống con của giao diện vừa bị thay thế vào thành phần có sẵn đó để sử dụng lại
c c kh n ng s d ng l i
Các khả năng sử dụng lại
  • Bên trong hệ thống
    • Tìm ra những điểm chung giữa các gói hoặc hệ thống con
  • Bên ngoài hệ thống
    • Sử dụng các thành phần sẵn có (thương mại, miễn phí)
    • Thành phần từ hệ thống phát triển trước đây
    • Phát triển lại một thành phần có sẵn (sử dụng lại thiết kế)
v d c c t ng ki n tr c
Ví dụ: Các tầng kiến trúc

<<layer>>

Application

Necessary because the

Application Layer must

have access to the core

distribution mechanisms

<<layer>>

provided with Java RMI.

Business

Services

<<layer>>

Middleware

Base Reuse

global

v d t ng ng d ng
Ví dụ: Tầng ứng dụng

<<layer>>

Application

Registration

v d ng c nh c a t ng ng d ng

External System

Interfaces

Security

University Artifacts

Secure Interfaces

GUI Framework

Ví dụ: Ngữ cảnh của tầng ứng dụng

<<layer>>

Application

<<layer>>

Application

Registration

<<layer>>

Business

Services

<<layer>>

Business Services

v d t ng business service
Ví dụ tầng Business Service

<<layer>>Business Services

<<subsystem>>

<<subsystem>>

BillingSystem

CourseCatalogSystem

External System

Interfaces

Security

ObjectStore

GUI

Framework

<<subsystem>>

Security

Manager

Support

Secure

Interfaces

University

Artifacts

v d ng c nh t ng business service
Ví dụ: Ngữ cảnh tầng Business Service

<<layer>>Business Services

<<subsystem>>

<<subsystem>>

CourseCatalogSystem

BillingSystem

External System

Interfaces

<<layer>>

Security

Business

Services

ObjectStore

GUI

Framework

<<subsystem>>

Security

Manager

Support

University

Secure

Interfaces

<<layer>>

Artifacts

Middleware

<<layer>>Middleware

com.odi

java.sql

v d t ng middle layer

DriverManager

(from com.odi)

Ví dụ tầng Middle Layer

<<layer>>

Middleware

com.odi

java.sql

Connection

Map

Session

(from com.odi)

(from com.odi)

(from com.odi)

Statement

ResultSet

Transaction

Database

(from com.odi)

(from com.odi)

(from com.odi)

(from com.odi)

t ng k t
Tổng kết
  • Các mô hình thiết kế được xây dựng trực tiếp từ các mô hình phân tích
    • Là hình thức chi tiết hóa từ các lớp trừu tượng hóa trong mô hình phân tích
      • Ánh xạ 1-1 cho những lớp phân tích đơn giản
    • Ánhxạ thành nhiều lớp thiết kế nếu lớp phân tích đó quá phức tạp
  • Lớp phân tích có mức độ phức tạp cao có thể được phát triển thành hệ thống con (subsystem)
    • Sử dụng các giao diện
    • Đảm bảo hệ thống con có tính độc lập tối đa với các thành phần còn lại
  • Tìm cách sử dụng lại các hệ thống con, gói hoặc các thư viện có sẵn