Giáo trình UML - Chương 8: Hiện thực hóa Use Case docx

Trang 1

CHƯƠNG 8: Hiên th c ho a Use Case ̣ ự ́

Hiên th c ho a Use Case ̣ ự ́

(Realization Use Case)

Trang 2

Nôi dung ̣

 Hiên th c ho a use case ̣ ự ́

 Mô hi nh domain va hiên th c ho a UC ̀ ̀ ̣ ự ́

 L p y niêm va l p thiê t kê ơ ́ ́ ̣ ̀ ơ ́ ́ ́

 Nhiêm vu va method ̣ ̣ ̀

 Nhiêm vu va l ̣ ̣ ̀ ượ c đô t ̀ ươ ng ta c ́

 Case study 1: Hê thô ng POS ̣ ́

◦ Thiê t kê đô i t ́ ́ ́ ượ ng makeNewSale

◦ Thiê t kê đô i t ́ ́ ́ ượ ng enterItem

◦ Thiê t kê đô i t ́ ́ ́ ượ ng endSale

◦ Thiê t kê đô i t ́ ́ ́ ượ ng makePayment

◦ Thiê t kê đô i t ́ ́ ́ ượ ng StartUp

Trang 3

Hiên th c ho a UC ̣ ự ́

UC realization

 Hiên th c ho a UC co nghi a la mô ta ̣ ự ́ ́ ̃ ̀ ̉

la m thê na o đê 1 use case đ̀ ́ ̀ ̉ ược hiên ̣

th c ho a trong mô hi nh thiê t kê theo ự ́ ̀ ́ ́nghi a la ca c đô i t̃ ̀ ́ ́ ượng công ta c nhau ̣ ́

 Chi nh xa c h n, nǵ ́ ơ ười thiê t kê co thê ́ ́ ́ ̉

mô ta viêc thiê t kê cua môt hay nhiê u ̉ ̣ ́ ́ ̉ ̣ ̀scenario cua use case, mô i thiê t kê na y ̉ ̃ ́ ́ ̀

được goi la hiên th c ho a use case ̣ ̀ ̣ ự ́

Trang 4

Hiên th c ho a UC ̣ ự ́

 Viêc hiên th c ho a use case đ̣ ̣ ự ́ ược du ng ̀

đê kê t nô i gi a ca c yêu câ u đ̉ ́ ́ ữ ́ ̀ ược

biêu diê n b i use case v i viêc thiê t kê ̉ ̃ ở ớ ̣ ́ ́

ca c đô i t́ ́ ượng thoa ma n ca c yêu câ u ̉ ̃ ́ ̀

Trang 5

Mô hi nh Domain va hiên th c ho a ̀ ̀ ̣ ự ́

UC

 Môt sô đô i ṭ ́ ́ ượng phâ n mê m ̀ ̀

(software objects ) tương ta c v i nhau ́ ớthông qua ca c thông điêp trong ĺ ̣ ược đô ̀

tương ta c đ́ ược ru t ra t mô hi nh ́ ừ ̀

domain, chăng han nh l p y niêm Sale ̉ ̣ ư ớ ́ ̣

được lâ y theo l p thiê t kê Sale ́ ớ ́ ́

 Viêc chon đê đăt nhiêm vu thi ch h p ̣ ̣ ̉ ̣ ̣ ̣ ́ ợ

va o ca c l p môt phâ n d a theo thông ̀ ́ ớ ̣ ̀ ự

tin trong mô hi nh domain.̀

Trang 6

Mô hi nh Domain va hiên th c ho a ̀ ̀ ̣ ự ́

UC

 Co thê mô hi nh domain hiên tai ch a ́ ̉ ̀ ̣ ̣ ư

đâ y đu, vâ n co n lô i va sai so t ̀ ̉ ̃ ̀ ̃ ̀ ́

 Ca c l p y niêm m i se đ́ ớ ́ ̣ ớ ̃ ược kha m ́pha trong lu c hiên th c ho a use case ́ ́ ̣ ự ́

Trang 7

L p y niêm va l p thiê t kê ơ ́ ́ ̣ ̀ ơ ́ ́ ́

(Conceptual class and design class)

 Mô hi nh Domain không mô ta l p thiê t kê ̀ ̉ ơ ́ ́ ́

nh ng đ ư ượ c du ng la m c s đê suy ra ca c l p ̀ ̀ ơ ở ̉ ́ ơ ́ thiê t kê ́ ́

 Trong lu c ve l ́ ̃ ượ c đô t ̀ ươ ng ta c, nha pha t ́ ̀ ́

triên co thê d a va o mô hi nh domain đê đăt ̉ ́ ̉ ự ̀ ̀ ̉ ̣

tên l p thiê t kê , nh đo thu hep khoang ca ch ơ ́ ́ ́ ơ ̀ ́ ̣ ̉ ́

gi a phâ n mê m va ca c kha i niêm thê gi i ư ̃ ̀ ̀ ̀ ́ ́ ̣ ́ ơ ́

th c ự

 Ca c l p thiê t kê trong mô hi nh thiê t kê ́ ơ ́ ́ ́ ̀ ́ ́

không nhâ t thiê t buôc phai tru ng tên hoa n ́ ́ ̣ ̉ ̀ ̀

toa n v i ca c l p trong mô hi nh domain ̀ ơ ́ ́ ơ ́ ̀

Trang 8

L p y niêm va l p thiê t kê ơ ́ ́ ̣ ̀ ơ ́ ́ ́

Trang 9

Thiê t kê đô i t ́ ́ ́ ượ ng

 Hai ki n th c c b n c n ph i có đ ế ứ ơ ả ầ ả ể

thi t k đ i tế ế ố ượng là:

◦ Các nguyên t c gán trách nhi m cho đ i ắ ệ ố

t ượ ng (GRASP)

◦ Các m u thi t k (design pattern)ẫ ế ế

 Thiê t kê đô i t́ ́ ́ ượng co nghi a la phai ́ ̃ ̀ ̉quyê t đinh xem method na y nên thuôc ́ ̣ ̀ ̣

l p na o, đô i tớ ̀ ́ ượng kia nên tương ta c ́

ra sao

Trang 10

ha nh vi cua no Nhiêm vu cua môt đô i ̀ ̉ ́ ̣ ̣ ̉ ̣ ́

tượng bao gô m hai loai:̀ ̣

◦ Doing (la m)̀

◦ Knowing(biê t) ́

Trang 11

◦ Biê t d liêu na o đo ng go i riêng ́ ư ̃ ̣ ̀ ́ ́

◦ Biê t đô i t́ ́ ượng na o co liên quan đê ǹ ́ ́

◦ Biê t nh ng gi co thê suy diê n hay ti nh ́ ư ̃ ̀ ́ ̉ PTTKHT bang UML - BM HTTT̃ ́ 11

Trang 12

 Vi du đô i t́ ̣ ́ ượng Sale co nhiêm vu tao ́ ̣ ̣ ̣

ra đô i t́ ượng SalesLineItems (nhiêm vu ̣ ̣

doing) hay đô i t́ ượng Sale co nhiêm vu ́ ̣ ̣cho biê t tông tri gia ba n (nhiêm vu ́ ̉ ̣ ́ ́ ̣ ̣

knowing)

Trang 13

Câ p đô cua nhiêm vu ́ ̣ ̉ ̣ ̣

 Viêc chuyên giao nhiêm vu va o ca c l p ̣ ̉ ̣ ̣ ̀ ́ ớphu thuôc va o câ p đô cua nhiêm vu ̣ ̣ ̀ ́ ̣ ̉ ̣ ̣

(granularity of the responsibility)

 Vi du: nhiêm vu “provide access to ́ ̣ ̣ ̣

relational DB” co thê liên quan đê n ́ ̉ ́

ha ng ta ca c l p va ha ng trăm method ̀ ́ ́ ớ ̀ ̀trong 1 hê thô ng con Trong khi đo ̣ ́ ́

nhiêm vu “create a Sale” co thê chi liên ̣ ̣ ́ ̉ ̉quan đê n 1 va i method ma thôi.́ ̀ ̀

Trang 14

Th c thi nhiêm vu ự ̣ ̣

 Nhiêm vu đ̣ ̣ ược th c thi thông qua hoăc ự ̣chi bă ng 1 method riêng le hoăc do ̉ ̀ ̉ ̣

nhiê u method va đô i t̀ ̀ ́ ượng cu ng công ̀ ̣

ta c.́

 Vi du, l p Sale co môt method tên ́ ̣ ớ ́ ̣

getTotal cho biê t tông tri gia ; đê hoa n ́ ̉ ̣ ́ ̉ ̀tha nh nhiêm vu na y, Sale câ n công ta c ̀ ̣ ̣ ̀ ̀ ̣ ́

v i 1 sô đô i tớ ́ ́ ượng kha c chăng han no ́ ̉ ̣ ́

se g i thông ba o agetSubtotal đê n mô i ̃ ử ́ ́ ̃

đô i t́ ượng SalesLineItem đê nhân đ̉ ̣ ược

Trang 15

Nhiêm vu va ḷ ̣ ̀ ược đô t̀ ương ta ć

(Responsibilities and interaction diagrams)

 Viêc ga n nhiêm vu tḥ ́ ̣ ̣ ường được th c ự

hiên ̣ trong lu c tao ĺ ̣ ược đô t̀ ương ta c ́

thông qua viêc chon thông ba o gi g i ̣ ̣ ́ ̀ ử

cho đô i t́ ượng

Trang 16

Nhiêm vu va ḷ ̣ ̀ ược đô t̀ ương ta ć

(Responsibilities and interaction diagrams)

 Đô i t́ ượng Sale đu c ga n nhiêm vu tao ợ ́ ̣ ̣ ̣

đô i t́ ượng Payment khi co thông ba o ́ ́

makePayment va method th c thi t̀ ự ương

ng la makePayment

ư

Trang 17

Case study 1

 T lư ượ̀ c đô tuâ n t cua kich ban chi nh ̀ ̀ ự ̉ ̣ ̉ ́

UC “Process Sale” tao ca c l p class ̣ ́ ớ

thiê t kế ́

Trang 18

“makeNewSale”

 Thao ta c hê thô ng “makeNewSale” xay ́ ̣ ́ ̉

ra khi thâu ngân bă t đâ u môt lâ n ba n ́ ̀ ̣ ̀ ́

ha ng m i (new sale) khi kha ch ha ng ̀ ớ ́ ̀

mang đê n ca c đô vât đa chon mua.́ ́ ̀ ̣ ̃ ̣

 Không co điê u kiên tiên quyê t ́ ̀ ̣ ́

 Kê t qua cua thao ta c :́ ̉ ̉ ́

◦ Môt điên hi nh Sale s đu c tao ra ̣ ̉ ̀ ợ ̣

◦ s được kê t h p v i Registeŕ ợ ơ ́

◦ Ca c thuôc ti nh cua s đu c kh i đâ u ́ ̣ ́ ̉ ợ ở ̀

Trang 19

“makeNewSale”

 Thiê t kê đâ u tiên la câ n chon l p ́ ́ ̀ ̀ ̀ ̣ ơ ́ Controller

cho thông ba o hê thô ng “makeNewSale” ́ ̣ ́

 Theo mâ u Controller thi co 2 ng viên: ̃ ̀ ́ ư ́

Nên chon l p Register vi hê thô ng không co ̣ ơ ́ ̀ ̣ ́ ́ qua nhiê u thao ta c ́ ̀ ́

Để biểu diễn cả hệ thống, thiêt bị,

hay 1 hệ thống con

Register, POSSystem

Để biểu diễn đối tượng nhận

(receiver) hay quản lý (handler)

toàn bộ sự kiện hệ thống của kịch

bản use case

ProcessSaleHandler, ProcessSaleSession

Trang 20

“makeNewSale”

 Nh vây co nghi a la trong lư ̣ ́ ̃ ̀ ược đô ̀

tương ta c se co môt thông điêp ́ ̃ ́ ̣ ̣

makeNewSale đượ ửc g i đê n đô i t́ ́ ương phâ n mê m Register̀ ̀

Trang 21

“makeNewSale

 Đô i t́ ương Sale câ n phai đ̀ ̉ ược tao, va ̣ ̀

theo Creator nên ga n tra ch nhiêm tao ́ ́ ̣ ̣

l p Sale na y cho l p na o ma co kha ớ ̀ ớ ̀ ̀ ́ ̉năng tâp h p, ch a va l u tr lai ca c ̣ ợ ứ ̀ ư ữ ̣ ́

đô i t́ ượng được tao ra ̣

 Theo mô hi nh nghiêp vu thi thâ y ră ng ̀ ̣ ̣ ̀ ́ ̀Register co thê l u tr đu c Sale, vi vây ́ ̉ ư ữ ợ ̀ ̣Register la môt ng viên (candidate) ̀ ̣ ứ

thi ch h p đê tao Sale ́ ợ ̉ ̣

Trang 22

“makeNewSale

 Khi Sale được tao ra, thi phai tao 1 tâp ̣ ̀ ̉ ̣ ̣

h p rô ng đê ch a tâ t ca ca c điên hi nh ợ ̃ ̉ ứ ́ ̉ ́ ̉ ̀cua SaleLineItem se lâ n l̉ ̃ ̀ ượ ượt đ c thêm

va o Tâp h p na y phai đ̀ ̣ ợ ̀ ̉ ược ch a va duy ứ ̀tri b i điên hi nh Sale, điê u na y cu ng co ̀ ở ̉ ̀ ̀ ̀ ̃ ́nghi a la Sale la ng viên tô t nhâ t đê ̃ ̀ ̀ ́ư ́ ́ ̉

tao tâp h p na y ̣ ̣ ợ ̀

 Register se tao Sale va Sale se tao 1 tâp ̃ ̣ ̀ ̃ ̣ ̣

h p rô ng dang biêu tợ ̃ ̣ ̉ ượng đa đô i t́ ượng

Trang 24

Thiê t kê đô i t ́ ́ ́ ượ ng enterItem

 Thao ta c hê thô ng ́ ̣ ́ enterItem xay ra khi ̉

thâu ngân đ a va o ma ha ng va sô ư ̀ ̃ ̀ ̀ ́

lượng

 Không co điê u kiên tiên quyê t́ ̀ ̣ ́

 Kê t qua cua thao ta c (postcondition):́ ̉ ̉ ́

◦ Điên hi nh SalesLineltem co tên ̉ ̀ ́ sli đ ượ c tao ̣

◦ sli đa kê t h p v i Sale hiên ha nh ̃ ́ ợ ơ ́ ̣ ̀

◦ sli.quantity đa ch a sô l̃ ư ́ ́ ượng

◦ Sli đa kê t h p v i ProductSpecification, d a ̃ ́ ợ ơ ́ ự

Trang 25

 Chon l p Controlleṛ ớ : giô ng nh s kiên ́ ư ự ̣

makeNewSale, l p Register vâ n tiê p tuc ớ ̃ ́ ̣

được chon.̣

 Đê hiên thi mô ta va gia ca ha ng ho a?̉ ̉ ̣ ̉ ̀ ́ ̉ ̀ ́

◦ Theo nguyên tă c phân chia Model- View, đô i ́ ́

t ượ ng non-GUI không co nhiêm vu gi liên ́ ̣ ̣ ̀ quan đê n output Do đo tuy UC co đê câp ́ ́ ́ ̀ ̣

đê n mô ta va gia nh ng se bi bo qua không ́ ̉ ̀ ́ ư ̃ ̣ ̉

xe t đê n tai th i điêm na y ́ ́ ̣ ơ ̀ ̉ ̀

Trang 26

 Đê tao m i SalesLineItem̉ ̣ ớ :

◦ Postcondition chi ra viêc tao, bă t đâ u va ̉ ̣ ̣ ́ ̀ ̀

kê t h p cua SaleLineItem ́ ợ ̉

◦ Theo mô hi nh nghiêp vu, Sale ch a ca c đô i ̀ ̣ ̣ ứ ́ ́

tượng SaleLineItem.

D a theo mô hi nh nghiêp vu, l p phâ n ự ̀ ̣ ̣ ớ ̀

mê m Sale cu ng t̀ ̃ ương t cu ng se ự ̃ ̃

ch a l p phâ n mê m SaleLineItem ứ ớ ̀ ̀

Theo Creator, Sale la ng viên thi ch ̀ ́ư ́

h p đê tao SalesLineItem ợ ̉ ̣

Trang 27

 Sale co thê kê t h p v i SalesLineItem ́ ̉ ́ ợ ớ

bă ng ca ch l u mô i điên hi nh cua ̀ ́ ư ̃ ̉ ̀ ̉

SalesLineItem v a đừ ược tao va o trong ̣ ̀tâp h p line item cua nọ́ ợ ̉

 Postconditions cu ng yêu câ u la ̃ ̀ ̀

SalesLineItem m i câ n co 1 sô lớ ̀ ́ ́ ượng ngay khi được tao, vi vây Register phai ̣ ̀ ̣ ̉

chuyên sô l̉ ́ ượng nh 1 tham sô va o ư ́ ̀

thông điêp tao ̣ ̣

Trang 28

 Theo Creator, thông ba o ́ makeLineItem phai đ̉ ượ ửc g i đê n Sale đê tao ́ ̉ ̣

SalesLineItem Sale khi tao SalesLineItem ̣

thi l u tr điên hi nh m i va o ̀ ư ữ ̉ ̀ ớ ̀

collection cô đinh cua mi nh ́ ̣ ̉ ̀

 Ca c thông sô trong thông ba ó ́ ́

makeLineItem phai ch a sô l̉ ứ ́ ượng

(quantity), nh vây SalesLineItem co thê ờ ̣ ́ ̉

ghi lai.̣

Trang 29

Ti m ProductSpecification:̀

 SalesLineItem câ n kê t h p v i ̀ ́ ợ ớ

ProductSpecification thông qua ma ̃

itemID đượ ửc g i đê n, nghi a la câ n khôi ́ ̃ ̀ ̀phuc môt Product-Specification d a va o ̣ ̣ ự ̀viêc so tru ng itemID.̣ ̀

Trang 30

 Trước khi khao sa t xem la m thê na o ̉ ́ ̀ ́ ̀

đê tra c u ma itemID, câ n phai xa c ̉ ứ ̃ ̀ ̉ ́

đinh ro nhiêm vu ̣ ̃ ̣ ̣ “Who should be

responsible for knowing a

ProductSpecification, based on an itemID match?”

 Ro ra ng nhiêm vu na y không phai cua ̃ ̀ ̣ ̣ ̀ ̉ ̉creator cu ng nh cua controller, no la ̃ ư ̉ ́ ̀nhiêm vu cua IE.̣ ̣ ̉

Trang 31

 Theo IE đê hoa n tha nh nhiêm vu, đô i ̉ ̀ ̀ ̣ ̣ ́

tượng câ n co đu thông tin ̀ ́ ̉ “Who knows about all the ProductSpecification objects?”

 Theo mô hi nh domain, chi nh ̀ ́

Trang 32

 Theo IE thi ̀ ProductCatalog la 1 ng ̀ ứ

viên tô t cho nhiêm vu tra ti m (lookup), ́ ̣ ̣ ̀

l p se co 1 method getSpecification.ớ ̃ ́

Trang 33

 Ai se g i thông ba o ̃ ử ́ getSpecification đê n ́ProductCatalog?

Gia s điên hi nh ̉ ử ̉ ̀ Register va ̀

ProductCatalog đa đ̃ ược tao trong UC ̣

StartUp, va Register đa co 1 kê t nô i ̀ ̃ ́ ́ ́

cô đinh v i ProductCatalog – co nghi a ́ ̣ ớ ́ ̃

la no nhi n thâ y (visibility) đ̀ ́ ̀ ́ ược

ProductCatalog Chi nh vi vây no co thê ́ ̀ ̣ ́ ́ ̉

g i thông ba o getSpecificationử ́

Trang 34

Trang 35

Thiê t kê đô i t ́ ́ ́ ượ ng endSale

 Thao ta c hê thô ng ́ ̣ ́ endSale xay ra khi ̉

thâu ngân nhâ n va o nu t kê t thu c 1 ́ ̀ ́ ́ ́

sale

 Điê u kiên tiên quyê t (precondition): ̀ ̣ ́

đang co môt sale ́ ̣

 Postcondition: Sale.isComplete chuyên ̉

tha nh true ̀

Trang 36

 Chon l p Controlleṛ ớ : vâ n tiê p tuc chon ̃ ́ ̣ ̣

Register la m controller ̀

 Xa c lâp thuôc ti nh Sale.isComplete ́ ̣ ̣ ́ :

◦ Theo Postcondtion thi Sale.isComplete phai ̀ ̉

tha nh true ̀

◦ “Who should be responsible for setting the

 Theo IE thi chi nh l p Sale co nhiêm vu na y ̀ ́ ớ ́ ̣ ̣ ̀

vi no quan ly thuôc ti nh na y Do đo ̀ ́ ̉ ́ ̣ ́ ̀ ́

Register se g i thông ba o becomeComplete ̃ ử ́

đê n Sale đê no đăt thuôc ti nh na y tha nh ́ ̉ ́ ̣ ̣ ́ ̀ ̀

Trang 37

Trang 38

 Ti nh toa n tông tha nh tiê n(sale total)́ ́ ̉ ̀ ̀

 Theo nguyên tă c ta ch r i Model-View , ́ ́ ờkhông quan tâm đê n viêc la m thê na o ́ ̣ ̀ ́ ̀

đê hiên thi tông tha nh tiê n ma chi câ n ̉ ̉ ̣ ̉ ̀ ̀ ̀ ̉ ̀biê t đ́ ược tông tha nh tiê n ̉ ̀ ̀

 Đê n lu c na y thi không co l p thiê t ́ ́ ̀ ̀ ́ ớ ́

kê na o biê t đ́ ̀ ́ ược tông tha nh tiê n.̉ ̀ ̀

Trang 39

 Who should be responsible for knowing the sale total?

 To m tă t môt sô thông tin câ n thiê t ́ ́ ̣ ́ ̀ ́

Trang 40

Trang 41

 Theo phân ti ch trên:́

◦ Sale co nhiêm vu phai biê t tông tha nh tiê n ́ ̣ ̣ ̉ ́ ̉ ̀ ̀

 no co method getTotal ́ ́

◦ SalesLineItem co nhiêm vu phai biê t subtotal ́ ̣ ̣ ̉ ́

 no phai co method getSubtotal ́ ̉ ́

◦ ProductSpecification co nhiêm vu biê t gia ́ ̣ ̣ ́ ́ 

no phai co method agetPrice ́ ̉ ́

Trang 42

 L p na o se g i thông ba o ơ ́ ̀ ̃ ử ́ getTotal đê n ́

Sale? Râ t co thê la 1 đô i t ́ ́ ̉ ̀ ́ ượng trong UI

layer chăng han nh l p ̉ ̣ ư ơ ́ Jframe cua Java.̉

Trang 43

Thiê t kê đô i t ́ ́ ́ ượ ng makePayment

 Thao ta c hê thô ng ́ ̣ ́ makePayment xay ra ̉

khi thâu ngân nhâp va o tiê n măt đê ̣ ̀ ̀ ̣ ̉

thanh toa n ́

 Điê u kiên tiên quyê t (precondition): ̀ ̣ ́

đang co môt sale câ n thanh toa ń ̣ ̀ ́

 Postcondition:

◦ Môt điên hi nh cua Payment p đ ̣ ̉ ̀ ̉ ượ c tao ra ̣

◦ p.amountTendered ch a tha nh tiê n ư ́ ̀ ̀

(amount)

◦ P kê t h p v i Sale hiên ha nh.́ ợ ơ ́ ̣ ̀

◦

Định dạng
Số trang	62
Dung lượng	1,41 MB