Công nghệ phần mềm
description
Transcript of Công nghệ phần mềm
BàiBài GiảGiảBàiBài GiảngGiảng
CôngCông NghệNghệ PhầnPhần MềmMềmSoftware Engineering Software Engineering
Giáo viên & Giao tiếp giảng dạy Giáo viên & Giao tiếp giảng dạy p g g ạyp g g ạy
ThS Nguyễn Cao Trí – [email protected]://www.cse.hcmut.edu.vn/~caotri
Room 109 A5 – Trung tâm Kỹ thuật Điện toánTel: 8647256 – 5370 Mobile: 091 391 6290Hobbies: Automation , Flying Modelhttp://www.rc-easy.net
•• TàiTài liệuliệu downloaddownload trêntrên websitewebsite filefile:: TailieudientuCNPMTailieudientuCNPM--PrintableVersionPrintableVersion..pptppt
•• HọcHọc thếthế nào?nào? HỏiHỏi ngayngay trêntrên lớplớp•• HọcHọc thếthế nào?nào? HỏiHỏi ngayngay trêntrên lớplớp•• BảngBảng mãmã sửsử dụngdụng làlà UnicodeUnicode dựngdựng sẵnsẵn•• CácCác bàibài tậptập nộpnộp bằngbằng email,email, dạngdạng filefile **..ZIPZIP•• EmailEmail phảiphải ghighi rõrõ nộinội dungdung filefile đínhđính kèmkèm làlà gìgì bằngbằng tiếngtiếng ViệtViệt
22Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông TinCopyright 2004 – Th.S Nguyễn Cao Trí – [email protected]
•• EmailEmail phảiphải ghighi rõrõ nộinội dungdung filefile đínhđính kèmkèm làlà gìgì bằngbằng tiếngtiếng ViệtViệt
Giới thiệu môn họcGiới thiệu môn họcệ ọệ ọ•• NộiNội dungdung mônmôn họchọc
– Giới thiệu các khái niệm cơ bản về công nghệ phần mềmấ ầ ề ầ ề– Mục tiêu của sản xuất phần mềm và công nghệ phần mềm
– Các mô hình sản xuất phần mềm– Quy trình sản xuất và quản lý dự án phần mềm
•• TàiTài liệuliệu thamtham khảokhảo– Introduction to Software Engineering – Ronald J. Leach – CRC
Press (Thư viện A2 MS: 9075802004)ess ( ư v ệ S: 907580 00 )
– Software Engineering – Ian Sommerville – Fifth edition (Thư viện A3MS: 200032)
•• HìnhHình thứcthức kiểmkiểm tratraHìnhHình thứcthức kiểmkiểm tratra– Giữa kỳ + Cuối kỳ + Bài tập– Hình thức kiểm tra: trắc nghiệm khách quan – open bookĐánh giá kêt quả: tương đối phi tuyến
33Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông TinCopyright 2004 – Th.S Nguyễn Cao Trí – [email protected]
– Đánh giá kêt quả: tương đối - phi tuyến
???????? & !!!!!!!!???????? & !!!!!!!!
•• CôngCông NghiệpNghiệp && CôngCông NghệNghệôô ệệ ầầ ềề•• CôngCông NghiệpNghiệp PhầnPhần MềmMềm (CNpPM)(CNpPM)
•• CôngCông NghệNghệ PhầnPhần MềmMềm (CNPM)(CNPM)•• CôngCông nghiệpnghiệp phầnphần mềmmềm && cáccác côngcông nghiệpnghiệp kháckhác•• CôngCông nghiệpnghiệp phầnphần mềmmềm && cáccác côngcông nghiệpnghiệp kháckhác
– Giống– Khác
CóCó hayhay khôngkhông (những)(những) côngcông nghệnghệ chocho sảnsản xuấtxuất phầnphần•• CóCó hayhay khôngkhông (những)(những) côngcông nghệnghệ chocho sảnsản xuấtxuất phầnphầnmềm?mềm?
•• CóCó cầncần thiếtthiết phảiphải cócó côngcông nghệnghệ chocho sảnsản xuấtxuất phầnphần mềmmềmôô ảả ấấ ầầ ềề àà ộộ ảả ấấ ặặkhông,không, khikhi sảnsản xuấtxuất phầnphần mềmmềm làlà hoạthoạt độngđộng sảnsản xuấtxuất ““đặcđặc
biệtbiệt”” vìvì khôngkhông thểthể nóinói làmlàm mộtmột phầnphần mềmmềm nhưnhư sảnsản xuấtxuấtmộtmột lonlon cocacoca..
44Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông TinCopyright 2004 – Th.S Nguyễn Cao Trí – [email protected]
Đặc tính của sản phẩm phần mềmĐặc tính của sản phẩm phần mềmặ p pặ p p•• SoftwareSoftware == ProgramProgram•• SoftwareSoftware productproduct == ProgramProgram ++ DocumentDocument ++ SupportSupportSoftwareSoftware productproduct ProgramProgram ++ DocumentDocument ++ SupportSupport•• LoạiLoại sảnsản phẩmphẩm phầnphần mềmmềm
– Generic Product: là sản phNm đóng gói và bán rộng rãi trên thị trường.B k P d t là ả hN đ hát t iể th ê ầ đặ thù ủ– Bespoke Product: là sản phNm được phát triển theo yêu cầu đặc thù củatừng khách hàng.
•• CácCác đặcđặc tínhtính quanquan trọngtrọng củacủa sảnsản phẩmphẩm phầnphần mềmmềmM i i bili hầ ề ó hể h đổi h ậ iệ h ê ầ ủ– Maintainability: phần mềm có thể thay đổi thuận tiện theo yêu cầu củangười dùng
– Dependability: tính ổn định, bảo mật và an toàn của phần mềm. Khônggây tổn hại về vật chất hay kinh thế cho hệ thốnggây tổn hại về vật chất hay kinh thế cho hệ thống.
– Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc– Usability: giao diện và phương thức phải phù hợp với người dùng đồng
thời đáp ứng đúng yêu cầu của người dùng
55Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
thời đáp ứng đúng yêu cầu của người dùng
Software Software -- Đủ hay Thiếu?Đủ hay Thiếu?yy
•• PhầnPhần mềmmềm đượcđược viếtviết ngayngay từtừ khikhi cócó nhữngnhững máymáy tínhtínhầầ êê ââ àà áá ềề ừừ ấấprogramableprogramable đầuđầu tiêntiên.. ĐượcĐược quanquan tâmtâm vàvà phátphát triềntriền từtừ rấtrất
sớmsớm•• CóCó rấtrất nhiềunhiều phầnphần mềmmềm đãđã đượcđược viếtviết•• CóCó rấtrất nhiềunhiều phầnphần mềmmềm đãđã đượcđược viếtviết
KhôngKhông thiếuthiếu phầnphần mềmmềm•• ThựcThực tếtế việcviệc sảnsản xuấtxuất phầnphần mềmmềm khôngkhông đápđáp ứngứng kịpkịp yêuyêuựự ệệ pp gg pp gg ịpịp yy
cầucầu củacủa ngườingười sửsử dụngdụng::– Không đủ về số lượng
Thiếu về chất lượng– Thiếu về chất lượng– Không kịp về thời gian
PhầnPhần mềmmềm khôngkhông đápđáp ứngứng đủđủ chocho ngườingười dùngdùng
66Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nguyên nhân khách quanNguyên nhân khách quang y qg y q
•• SốSố lượnglượng phầnphần mềmmềm phảiphải đượcđược hiểuhiểu làlà sốsố đầu/loạiđầu/loại phầnphần mềmmềm đượcđược sửsửdụngdụng chocho từngtừng mụcmục tiêutiêu ứngứng dụngdụngdụngdụng chocho từngtừng mụcmục tiêutiêu ứngứng dụngdụng..
•• NhuNhu cầucầu sửsử dụngdụng phầnphần mềmmềm làlà rấtrất lớnlớn– Nhiều ngành nghề cần dùng phần mềm máy tính
ỗ ề ầ ề ầ ề– Mỗi ngành nghề cần nhiều loại phần mềm khác nhau– Mội loại phần mềm cần nhiều cấp độ khác nhau theo trình độ người dùng
•• ChấtChất lượnglượng phầnphần mềmmềm cũngcũng chưachưa đápđáp ứngứng tốttốt hoànhoàn toàntoàn ngườingười sửsửdụngdụng::– Tính customize rất cao của sản phẩm phần mềm.– Trình độ sử dụng khác nhau và điều kiện hạ tầng ứng dụng khác nhau
•• NhuNhu cầucầu phầnphần mềmmềm thườngthường rấtrất cấpcấp báchbách– Tầm nhìn và chiến lược chưa đầu đủ của người sử dụng– Không có kế hoạch lâu dài
77Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
– Phải thay đổi theo từng đối tượng người dùng
Nguyên nhân chủ quanNguyên nhân chủ quang y qg y q
•• TínhTính chuyênchuyên nghiệpnghiệp trongtrong sảnsản xuấtxuất phầnphần mềmmềm chưachưa caocaoCácCác dữdữ liệuliệu quanquan sátsát đượcđược– Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ
Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt 200-– Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt 200-300%)
– Các đề án lớn dễ thất bại3/4 á hệ thố lớ ó lỗi khi th thi– 3/4 các hệ thống lớn có lỗi khi thực thi
– Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có 18 %phát hiện được
ế ế ể ỗ– Quá trình thiết kế (25 % công sức): để lại 30 % lỗi, có 10 % pháthiện được
– Quá trình mã hoá, kiểm tra và bảo trì: để lại 15 % lỗi, có 72 % phát
88Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
hiện được
Nguyên nhân chủ quan (tt)Nguyên nhân chủ quan (tt)g y q ( )g y q ( )
LýLý dodo củacủa nhữngnhững hệhệ quảquả trêntrênể ầ ề ố ộ– Phát triển phần mềm giống như một “nghệ thuật”, chưa được xem
như một ngành khoa học– Quy trình phát triển phần mềm chưa được thống nhất
Phải iết l i / ỗi khi ó th đổi ề ô ữ h/ h ặ /– Phải viết lại s/w mỗi khi có sự thay đổi về ngôn ngữ, h/w hoặc o/s– Chưa đạt được 1 chuẩn cho việc đo lường hiệu suất và sản phẩm– Độ phức tạp của phần mềm quá cao đối với 1 “kiến trúc sư”
ỹ ậ ặ ả ể i ậ ằ á ê ầ ầ ề– Kỹ thuật đặc tả để lại sự nhập nhằng trong các yêu cầu phần mềm– Làm việc nhóm không đúng kỷ luật gây ra các lỗi
Ầ Ả Ó Ộ Ề Ẩ Ì ẢẦ Ả Ó Ộ Ề Ẩ Ì ẢCẦN PHẢI CÓ MỘT/NHIỀU CHUẨN QUY TRÌNH TRONG SẢN CẦN PHẢI CÓ MỘT/NHIỀU CHUẨN QUY TRÌNH TRONG SẢN XUẤT PHẦN MỀM ĐỂ NÂNG CAO TÍNH CHUYÊN NGHIỆP CỦA XUẤT PHẦN MỀM ĐỂ NÂNG CAO TÍNH CHUYÊN NGHIỆP CỦA
NỀN SẢN XUẤT ĐẶC BIỆT NÀYNỀN SẢN XUẤT ĐẶC BIỆT NÀYCẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀMCẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀM
99Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
CẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀMCẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀM
Định nghĩa “Công nghệ phần mềm”Định nghĩa “Công nghệ phần mềm”ị g g g ệ pị g g g ệ p
•• CôngCông NghệNghệ PhầnPhần MềmMềm làlà sựsự thiếtthiết lậplập vàvà sửsử dụngdụng cáccácêê ắắ ằằ íí áá ầầnguyênnguyên tắctắc khoakhoa họchọc nhằmnhằm mụcmục đíchđích tạotạo rara cáccác phầnphần
mềmmềm mộtmột cáchcách kinhkinh tếtế màmà cáccác phầnphần mềmmềm đóđó hoạthoạt độngđộnghiệuhiệu quảquả vàvà tintin cậycậy trêntrên cáccác máymáy tínhtính..ệệ qq ậyậy yy
•• CôngCông nghệnghệ phầnphần mềmmềm làlà mộtmột quyquy trìnhtrình cócó hệhệ thốngthốngđượcđược sửsử dụngdụng trongtrong quáquá trìnhtrình phânphân tích,tích, thiếtthiết kế,kế, hiệnhiệnthực,thực, kiểmkiểm tratra vàvà bảobảo trìtrì đểđể bảobảo đảmđảm cáccác sảnsản phẩmphẩm phầnphầnmềmmềm đượcđược sảnsản xuấtxuất vàvà hoạthoạt độngđộng:: hiệuhiệu quả,quả, tintin cậy,cậy, hữuhữumềmmềm đượcđược sảnsản xuấtxuất vàvà hoạthoạt độngđộng:: hiệuhiệu quả,quả, tintin cậy,cậy, hữuhữudụng,dụng, nângnâng cấpcấp dễdễ dàngdàng (modificable),(modificable), khảkhả chuyểnchuyển(portable),(portable), khảkhả kiểmkiểm tratra (testable),(testable), cộngcộng táctác đượcđược vớivới cáccáchệhệ thốngthống kháckhác (interoperable)(interoperable) vàvà vậnvận hànhhành đúngđúng (correct)(correct)
1010Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
hệhệ thốngthống kháckhác (interoperable)(interoperable) vàvà vậnvận hànhhành đúngđúng (correct)(correct)..
Cụ thểCụ thểụụ•• EfficiencyEfficiency:: PhầnPhần mềmmềm đượcđược sảnsản xuấtxuất trongtrong thờithời giangian vàvà điềuđiều kiệnkiện vừavừa phảiphải.. PhầnPhần
mềmmềm vậnvận hànhhành đúngđúng mứcmức độđộ yêuyêu cầucầu vềvề côngcông việcviệc vàvà thờithời giangian..
•• ReliablityReliablity:: PhầnPhần mềmmềm vậnvận hànhhành ổnổn địnhđịnh vàvà tươngtương táctác đượcđược vớivới cáccác hệhệ thốngthống ứngứngdụngdụng
•• UsabilityUsability:: PhầnPhần mềmmềm cócó thểthể dùngdùng đượcđược bởibởi ngườingười sửsử dụngdụng vàvà vớivới môimôi trườngtrường màmà•• UsabilityUsability:: PhầnPhần mềmmềm cócó thểthể dùngdùng đượcđược bởibởi ngườingười sửsử dụngdụng vàvà vớivới môimôi trườngtrường màmàngườingười sửsử dụngdụng đangđang cócó.. ChúChú ýý tớitới giaogiao diện,diện, điềuđiều kiệnkiện hệhệ thống,thống,……
•• ModifiabilityModifiability:: PhầnPhần mềmmềm cócó thểthể đượcđược thaythay đổiđổi dểdể dàng,dàng, nhanhnhanh chóngchóng khikhi yêuyêu cầucầucủacủa ngườingười sửsử dụngdụng thaythay đổiđổi..củacủa ngườingười sửsử dụngdụng thaythay đổiđổi..
•• PortabilityPortability:: PhầnPhần mềmmềm cócó thểthể chuyểnchuyển đổiđổi dễdễ dàngdàng sangsang cáccác hệhệ thốngthống kháckhác màmà khôngkhôngcầncần phảiphải điềuđiều chỉnhchỉnh lớnlớn.. ChỉChỉ cầncần recompilerecompile nềunều cầncần thiếtthiết làlà tốttốt nhấtnhất..
TestabilityTestability:: PhầPhầ ề óề ó thểthể dd00ượượ kiểkiể tt dễdễ dàdà TốtTốt hấthất làlà đượđượ d ld l hóhó•• TestabilityTestability:: PhầnPhần mềmcómềmcó thểthể dd00ượcược kiểmkiểm tratra dễdễ dàngdàng.. TốtTốt nhấtnhất làlà đượcđược modulmodul hóahóa..
•• ReusabilityReusability:: PhầnPhần mềmmềm hayhay mộtmột phầnphần cócó thểthể đượcđược táitái sửsử dụngdụng chocho cáccác ứngứng dụngdụngkháckhác.. CácCác modulmodul cócó thiếtthiết kếkế tốt,tốt, độcđộc lậplập vàvà giaogiao tiếntiến đơnđơn giản,giản, cảcả vềvề tìnhtình tươngtương thíchthíchcôngcông nghệnghệ phátphát triểntriển
1111Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
côngcông nghệnghệ phátphát triểntriển
Cụ thể (tt)Cụ thể (tt)ụ ( )ụ ( )
•• MaintainabilityMaintainability:: thiếtthiết kếkế củacủa phầnphần mềmmềm cócó thểthể đượcđược hiểuhiểu dễdễ dàngdàng cũngcũng nhưnhư chuyểnchuyểnii th ậth ậ tiệtiệ hh ườiười khákhá tt áá t ì ht ì h điềđiề hỉ hhỉ h ââ ấấ hh thth đổiđổi ththgiaogiao thuậnthuận tiệntiện chocho ngườingười kháckhác trongtrong quáquá trìnhtrình điềuđiều chỉnh,chỉnh, nângnâng cấpcấp hayhay thaythay đổiđổi theotheo
yêuyêu cầucầu..
•• InteroperabilityInteroperability:: PhầnPhần mềmmềm vậnvận hànhhành ổnổn địnhđịnh vàvà đúngđúng nhưnhư mongmong đợiđợi.. TrênTrên hệhệthốngthống nhiềunhiều ngườingười dùngdùng (multi(multi users)users) phầnphần mềmmềm vẫnvẫn hoạthoạt độngđộng đượcđược vớivới cáccác vậnvận hànhhànhthốngthống nhiềunhiều ngườingười dùngdùng (multi(multi users)users) phầnphần mềmmềm vẫnvẫn hoạthoạt độngđộng đượcđược vớivới cáccác vậnvận hànhhànhkháckhác củacủa hệhệ thốngthống..
•• CorrectnessCorrectness:: PhầnPhần mềmmềm phảiphải tínhtính toántoán đúngđúng vàvà tạotạo rara kếtkết quảquả đúngđúng vàvà đúngđúng vớivớimụcmục tiêutiêu ứngứng dụngdụng củacủa ngườingười dùngdùngmụcmục tiêutiêu ứngứng dụngdụng củacủa ngườingười dùngdùng..
•• CácCác yêuyêu cầucầu kháckhác::Đúng tiến độ– Đúng tiến độ
– Sử dụng hợp lý nguồn nhân lực phát triển– Chi phí phát triển thấp nhất
1212Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nội dung công việc của Software EngineeringNội dung công việc của Software Engineeringộ g g ệ g gộ g g ệ g g
Công việc của software engineering bao gồm:Công việc của software engineering bao gồm:
•• PhânPhân tíchtích hệhệ thống/vấnthống/vấn đềđề•• XácXác địnhđịnh cáccác yêuyêu cầucầu
•• QuảnQuản lýlý chấtchất lượnglượng•• HuấnHuấn luyệnluyện
•• ThiếtThiết kếkế phầnphần mềmmềm•• ViếtViết phầnphần mềmmềm (coding)(coding)•• KiểmKiểm tratra vàvà tíchtích hợphợp hệhệ
yệyệ•• DựDự đoánđoán tàitài nguyênnguyên•• QuảnQuản trịtrị dựdự ánán
•• KiểmKiểm tratra vàvà tíchtích hợphợp hệhệthốngthống
•• CàiCài đặtđặt vàvà chuyểnchuyển giaogiaohầhầ ềềphầnphần mềmmềm
•• LậpLập tàitài liệuliệu•• BảoBảo trìtrì
1313Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
BảoBảo trìtrì
Một định nghĩa khác của CNPMMột định nghĩa khác của CNPMộ ị gộ ị g
•• CNPMCNPM làlà cáccác quyquy trìnhtrình đúngđúng kỷkỷ luậtluật vàvà cócó địnhđịnh lượnglượng đượcđượcáá áá ểể àà ảả ìì áá ệệápáp dụngdụng chocho sựsự phátphát triển,triển, thựcthực thithi vàvà bảobảo trìtrì cáccác hệhệthốngthống thiênthiên vềvề phầnphần mềmmềm
•• TậpTập trungtrung vàovào quyquy trìnhtrình sựsự đođo lườnglường sảnsản phẩmphẩm tínhtính•• TậpTập trungtrung vàovào quyquy trìnhtrình,, sựsự đođo lườnglường,, sảnsản phẩmphẩm,, tínhtínhđúngđúng thờithời giangian vàvà chấtchất lượnglượng
Qui trình Đo lườngTiê h ẩ
Thời gianQuản lý
Chất lượngDịch vụ
1414Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Tiêu chuẩn Quản lý Dịch vụ
Mô hình phát triển phần mềmMô hình phát triển phần mềmp pp p
CácCác côngcông đoạnđoạn chínhchính tổngtổng quátquát baobao gồmgồm 44 giaigiai đoạnđoạn
•• GiaiGiai đoạnđoạn đặcđặc tảtả:: xácxác địnhđịnh cáccác tínhtính năngnăng vàvà điềuđiều kiệnkiện hoạthoạtđộngđộng củacủa hệhệ thốngthống (thu(thu thậpthập yêuyêu cầucầu vàvà phânphân tích)tích)độngđộng củacủa hệhệ thốngthống.. (thu(thu thậpthập yêuyêu cầucầu vàvà phânphân tích)tích)
•• GiaiGiai đoạnđoạn phátphát triểntriển:: ThiếtThiết kếkế phầnphần mềmmềm (software(softwaredesign),design), viếtviết codecode (code(code generationgenerationg ),g ), (( gg
•• GiaiGiai đoạnđoạn kiểmkiểm tratra:: kiểmkiểm tratra phầnphần mềmmềm (software(software testing),testing),kiểmkiểm tratra tínhtính hợphợp lýlý củacủa phầnphần mềmmềm..
đđ bảbả ìì ửử lỗlỗ ( )( ) hh đổđổ ôô ờờ•• GiaiGiai đoạnđoạn bảobảo trìtrì:: SửaSửa lỗilỗi (correction),(correction), thaythay đổiđổi môimôi trườngtrườngthựcthực thithi (adaptation),(adaptation), tăngtăng cườngcường (enhancement)(enhancement)
1515Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Các mô hình sản xuất phần mềmCác mô hình sản xuất phần mềmpp
TùyTùy theotheo quyquy mômô vàvà côngcông nghệnghệ phátphát triển,triển, cócó cáccác mômô hìnhhìnhảả ấấ áásảnsản xuấtxuất kháckhác nhaunhau..
•• MôMô hìnhhình tuầntuần tựtự tuyếntuyến tínhtính-- waterfallwaterfall•• MôMô hìnhhình PrototypingPrototyping EvolutionaryEvolutionary DevelopmentDevelopment•• MôMô hìnhhình PrototypingPrototyping -- EvolutionaryEvolutionary DevelopmentDevelopment•• MôMô hìnhhình xoắnxoắn ốcốc –– Boehm’sBoehm’s SpiralSpiral ModelModel•• MôMô hìnhhình RADRAD –– RapidRapid ApplicationApplication DevelopmentDevelopmentMôMô hìnhhình RADRAD RapidRapid ApplicationApplication DevelopmentDevelopment
MÔ HÌNH NÀO TỐT HƠNMÔ HÌNH NÀO TỐT HƠNMỗiMỗi mômô hìnhhình phùphù hợphợp vớivới trìnhtrình độđộ phátphát triển,triển, quyquy mômô sảnsản
phẩmphẩm vàvà yêuyêu cầucầu ràngràng buộcbuộc cụcụ thểthể vềvề thờithời giangian vàvà tínhtínhchấtchất củacủa hệhệ thốngthống
1616Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
chấtchất củacủa hệhệ thốngthống..
Mô hình WaterFall Mô hình WaterFall –– Sequency modelSequency modelq yq y
•• MôMô hìnhhình phátphát triểntriển phầnphần mềmmềm đầuđầu tiêntiên•• CácCác côngcông việcviệc tiếptiếp nốinối nhaunhau mộtmột cáchcách tuầntuần tựtự•• ĐặtĐặt nềnnền móngmóng chocho cáccác phươngphương pháppháp phânphân tích,tích, thiếtthiết kế,kế, kiểmkiểm
tratra……tratra……
Phân tích yêu cầu
Thiết kế hệ thống ệ g& phần mềm
Hiện thức và kiểm tra moduls
Tí h hợ à kiểTích hợp và kiểm tra tổng thể
Chuyển giao và Bảo trì
1717Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Mô hình WaterFall Mô hình WaterFall –– Sequency model (tt)Sequency model (tt)q y ( )q y ( )
BộcBộc lộlộ mộtmột sốsố khuyếtkhuyết điểmđiểmảả ấấ ủủ áá ểể ầầ ềề àà áá ìì ặặ ặặ•• BảnBản chấtchất củacủa phátphát triểntriển phầnphần mềmmềm làlà quáquá trìnhtrình lặplặp điđi lặplặp
lạilại chứchứ khôngkhông phảiphải tuầntuần tựtự•• CácCác bướcbước thựcthực chấtchất khôngkhông táchtách biệtbiệt hoànhoàn toàntoàn màmà cócóựự gg ệệ
chồngchồng lấnlấn vàvà thamtham khảokhảo lạilại•• BắtBắt buộcbuộc kháchkhách hànghàng đặcđặc tảtả tấttất cảcả yêuyêu cầucầu mộtmột cáchcách chínhchính
xácxác vàvà đầyđầy đủđủ ngayngay từtừ banban đầuđầuxácxác vàvà đầyđầy đủđủ ngayngay từtừ banban đầuđầu•• KháchKhách hànghàng thườngthường phảiphải chờchờ đợiđợi rấtrất lâulâu đểđể thấythấy đượcđược
phiênphiên bảnbản đầuđầu tiêntiên củacủa sảnsản phẩmphẩmồồ “d l ”“d l ” í hí h lũlũ hóhó làlà ệệ dd áá•• TồnTồn tạitại “delay”“delay” tíchtích lũylũy trongtrong nhómnhóm làmlàm việcviệc -->> dựdự ánán
thườngthường bịbị trểtrể..•• ChỉChỉ phùphù hợphợp chocho dựdự ánán nhỏ,nhỏ, đơnđơn giảngiản..
1818Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
pp ợpợp ựự ,, gg
Mô Hình PrototypeMô Hình Prototypeypyp
Hoạt động sản xuấtHoạt động sản xuất
Bản prototypeĐặc tả
Mô tả sơ lược ủ khá h hà
Các bản trung gianPhát triểncủa khách hàng gianPhát triển
Bản cuối cùng
Kiểm thử
1919Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Mô Hình Prototype Mô Hình Prototype –– ưu & khuyếtưu & khuyếtypyp yy
•• PrototypePrototype nhưnhư làlà mộtmột cơcơ chếchế đểđể nhậnnhận diệndiện chínhchính xácxác yêuyêu cầucầu củacủakháchkhách hànghàngkháchkhách hànghàng– Bản thân khách hàng chưa hiểu rõ yêu cầu của mình, cũng như các quy
trình chưa được xác lập rõ ràng.Khách hàng chưa hiểu rõ khả năng hổ trợ của hệ thống máy tính– Khách hàng chưa hiểu rõ khả năng hổ trợ của hệ thống máy tính
•• KíchKích thíchthích sựsự thíchthích thúthú củacủa ngườingười dùngdùng vớivới dựdự ánán
óó ểể ãã íí•• PrototypePrototype cócó thểthể bịbị “throw“throw--away”away” -->> LãngLãng phíphí•• CácCác processprocess khôngkhông đượcđược phânphân địnhđịnh rõrõ ràngràng•• HệHệ thốngthống thôngthông thườngthường cócó cấucấu trúctrúc lỏnglỏng lẻolẻoệệ gg gg gg gg•• CầnCần cócó nhữngnhững kỹkỹ năngnăng đăcđăc biệtbiệt trongtrong quảnquản lýlý vàvà phátphát triểntriển•• KháchKhách hànghàng hốihối thúcthúc nhànhà phátphát triểntriển hoànhoàn thànhthành sảnsản phẩmphẩm mộtmột khikhi
thấythấy đượcđược cáccác prototypeprototype đầuđầu tiêntiên
2020Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
thấythấy đượcđược cáccác prototypeprototype đầuđầu tiêntiên
Mô Hình Prototype Mô Hình Prototype –– Ứng dụngỨng dụngypyp g ụ gg ụ g
•• DùngDùng chocho cáccác hệhệ thốngthống nhỏnhỏ.. CácCác chichi phíphí khikhi thaythay đổiđổi hệhệthốngthống làlà khôngkhông quáquá lớnlớn khiakhia cầncần phảiphải thaythay đổiđổi sausau khikhithốngthống làlà khôngkhông quáquá lớnlớn khiakhia cầncần phảiphải thaythay đổiđổi sausau khikhithựcthực hiệhiệ prototypeprototype
•• CầnCần sựsự cấpcấp báchbách vềvề thờithời giangian triểntriển khaikhai ngắnngắn.. HệHệ thốngthốngựự pp gg gg ệệ ggcầncần đượcđược đưađưa vàovào ứngứng dụngdụng từngtừng phầnphần trongtrong khoảngkhoảng thờithờigiangian nhấtnhất địnhđịnh..TrongTrong trườngtrường hợphợp nhữngnhững hệhệ thốngthống màmà việcviệc đặcđặc tảtả cáccác yêuyêu•• TrongTrong trườngtrường hợphợp nhữngnhững hệhệ thốngthống màmà việcviệc đặcđặc tảtả cáccác yêuyêucầucầu làlà rấtrất khókhó vàvà khôngkhông rõrõ ràngràng ngayngay từtừ đầuđầu..
2121Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Mô hình Xoắn Ốc Mô hình Xoắn Ốc -- Boehm’s Spiral ModelBoehm’s Spiral Modelpp
Đánh giá rủi roá ô ệ Đánh giá rủi ro
Phát triển sản phẩmHoạch định đề tài
Xác định công việc
ỗỗ ỗỗ•• ĐượcĐược thựcthực hiệnhiện theotheo mộtmột chuỗichuỗi lặplặp kiểukiểu xoắnxoắn ốc,ốc, mỗimỗi lầnlầnlặplặp cảicải thiệnthiện sảnsản phẩmphẩm
•• CóCó phươngphương pháppháp đánhđánh giágiá rủirủi roro•• CóCó phươngphương pháppháp đánhđánh giágiá rủirủi roro•• CóCó thểthể ápáp dụngdụng prototypeprototype•• MỗiMỗi lầnlần lặplặp đượcđược cảicải thiệnthiện chocho thíchthích nghinghi vớivới bảnbản chấtchất củacủa
2222Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
MỗiMỗi lầnlần lặplặp đượcđược cảicải thiệnthiện chocho thíchthích nghinghi vớivới bảnbản chấtchất củacủađềđề ánán
Mô hình RADMô hình RAD
Business modeling Data modeling
Process modeling Application generation
Testing & Turnover
•• RapidRapid ApplicationApplication DevelopmentDevelopment làlà mômô hìnhhình tuầntuần tựtự tuyếntuyếntínhtính cócó thờithời giangian phátphát triểntriển rấtrất ngắnngắn
modeling
tínhtính cócó thờithời giangian phátphát triểntriển rấtrất ngắnngắn•• SửSử dụngdụng cáccác thànhthành phầnphần cócó sẵnsẵn càngcàng nhiềunhiều càngcàng tốttốt•• SửSử dụngdụng côngcông cụcụ lậplập trìnhtrình ởở dạngdạng tựtự độngđộng sinhsinh mãmã chứchứụ gụ g gg ụụ ậpập ạ gạ g ựự ộ gộ g
khôngkhông phảiphải cáccác ngônngôn ngữngữ truyềntruyền thốngthống
PhPh h ộh ộ àà ôô hệhệ háhá iểiể óó í hí h blbl•• PhụPhụ thuộcthuộc vàovào côngcông nghệnghệ phátphát triểntriển cócó tínhtính reusablereusable caocao..•• ParttenPartten systemsystem developmentdevelopment
2323Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Các tiêu chuẩn dùng trong CNpPMCác tiêu chuẩn dùng trong CNpPMg g pg g p
•• TheThe capabilitycapability MaturityMaturity ModelModel (CMM)(CMM) củacủa SoftwareSoftware EngineeringEngineering InstitueInstitue (SEI)(SEI) --ĐạiĐại họchọc CarnegieCarnegie MellonMellonĐạiĐại họchọc CarnegieCarnegie MellonMellon..– Chú trọng đến tính hệ thống và khả năng quản trị của các công ty phần mềm
hơn là một quy trình (process) cụ thể.•• TheThe processprocess ImprovementImprovement ParadigmParadigm (PIP)(PIP) củacủa SoftwareSoftware EngineeringEngineering•• TheThe processprocess ImprovementImprovement ParadigmParadigm (PIP)(PIP) củacủa SoftwareSoftware EngineeringEngineering
LaboratoryLaboratory (SEL)(SEL) –– NASA’sNASA’s GoddardGoddard SpaceSpace FlightFlight CenterCenter– Tương tự như CMM, chú trọng đến tính hệ thống và những hướng dẫn để
tăng cường tính năng của các quá trình quản lý.•• CácCác chuẩnchuẩn kháckhác củacủa DepartmentDepartment ofof DefenseDefense
– MIL – STD 2167A ; MIL-STD 1574A ; MIL-STD 882C•• TheThe electronicelectronic IndustriesIndustries AssociationAssociation (EIA)(EIA) chuẩnchuẩn SEBSEB--66--AATheThe electronicelectronic IndustriesIndustries AssociationAssociation (EIA)(EIA) chuẩnchuẩn SEBSEB 66 AA•• TheThe EuropeanEuropean ESPRITESPRIT projectproject•• InternationalInternational StandardsStandards OrganisationOrganisation -- ISOISO 90019001
UnitedUnited KingdomKingdom MODMOD 00550055
2424Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
•• UnitedUnited KingdomKingdom MODMOD 00550055
Chuẩn CMMChuẩn CMMOptimized•Continuous Improvement
•Các hệ thống quality control và qualify đã được sử dụng hiệu quả
Managed
(Level 5)
sk
•Có khả năng dự đoán (Predictability)•Các quy trình quản lý và tiêu chuẩn đ hi iế hó
được sử dụng hiệu quả
Defined
(Level 4)Ri
•Xác lập các tiêu chuẩn quản lý•Các vấn đề documentation đã xác lập
được chi tiết hóa
Repeatable
(Level 3) Com
petiti•Bắt đầu có khả năng quản lý
Initial
(Level 2)
iveness
•Largely Ad-hoc
Bắt đầu có khả năng quản lý•Quản lý dựa vào kinh nghiệm tương tự
2525Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
(Level 1) •Phụ thuộc vào cá nhân
Chương 2Chương 2
Project ManagementProject ManagementProject ManagementProject Management
Sub-Team trong Software ProjectsP j t E ti tiProject EstimationProject SchedulingProject Management Tools
Tại sao cần Project managementTại sao cần Project management
Phát triển phần mềm hiện đại làm theo teamworksCần quản lý và kiểm soát được rủi ro (Risk) trong quá trình sảnxuấtCác dự án phần mềm đòi hỏi nhiều nguồn nhân lực với chuyên
ô khá hmôn khác nhauTính tích hợp công nghệ cao và sự thay đổi nhanh chóng củacông nghệPhải bả đả tí h h ê hiệ t hát t iể dự á hầPhải bảo đảm tính chuyên nghiệp trong phát triển dự án phầnmềm:
Bảo đảm lịch trình của dự ánĐiều phối và khai thác tối đa nguồn nhân lực hiện cóĐiều phối và khai thác tối đa nguồn nhân lực hiện cóBảo đảm chất lượng của sản phNmKhả năng khắc phục các sự cố xảy ra khách quan
Các dự án càng lớn càng cần có sự quản lý chặt chẻ và đồng bộ
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 2727
Các dự án càng lớn càng cần có sự quản lý chặt chẻ và đồng bộ
SUB-Team trong software engineeringSUB Team trong software engineering
Teamwork là mô hình hiện Công ty phần mềm
Project 1
tại cho hầu hết các dự ánphần mềm:
Khả năng chuyên nghiệp hóacao
Project 2
caoHiệu quả trong quản lý, giaotiếp và điều hành
Một software project team Team1
Team2
Team5
Team6
ộ p jđược tạo ra từ nhiều sub-teams
Các sub-team không nhất thiếtlà một nhóm người mà có thể
1 2
Team3
Team4
là một nhóm người mà có thểlà 1 ngườiCác sub-team không nhất thiếttồn tại suốt quá trình của mộtd á hầ ề
Project 3
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 2828
dự án phần mềm
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti T
Vai trò ệImplementation Team
Tesing & Intergration TeamTraining TeamDelivery & Installation Team
nhiệm vụ của các Delivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
SUB TeamMetrics TeamDocumentation TeamSystem Administration TeamReuse & Reengineering Team
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 2929
g g
Vai trò & nhiệm vụ các Sub-TeamVai trò & nhiệm vụ các Sub Team
System analysisSystem Analysis System Analysis Planning Team
Requirements TeamSystem Design TeamI l t ti T
System Analysis System Analysis Xác định tính khả thi của dự án• Phân tích chi phí (Cost analysis)• Dự đoán lợi nhận (Estimate revenues)
Tiên liệ các khó khăn ề kỹ th ậtImplementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
• Tiên liệu các khó khăn về kỹ thuậtvà công nghệ
•Sau khi nghiên cứu khả thi, nhómnày sẽ làm việc với RequirementDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
này sẽ làm việc với RequirementTeam để nhận feedbacks•Nếu dự án được phát triển theo môhình tương tác cao nhưPrototype/Spiral model thì tính tươngMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
Prototype/Spiral model thì tính tươngtác và feedback là rất quan trọng kểcả với các nhóm khác.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3030
g g
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti T
Planning TeamPlanning TeamNhóm này có nhiệm vụ xây dựng tổngthể tất cả các kế hoạch quản trị dự án
Implementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
và bảo đảm các tiến trình diển ra đúngtiến độ đã định•Xây dựng các kế hoạch thực hiện•Lập các time frame cho các tiến trìnhDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
•Kế hoạch sử dụng tài nguyên của hệthống bao gồm cả nhân lực•Các kế hoạch dự phòng và điều chỉnhkhi có sự cốMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3131
g g
Các Sub-TeamCác Sub Team
System analysisRequirement Team Requirement Team Planning Team
Requirements TeamSystem Design TeamI l t ti T
Requirement Team Requirement Team Tiếp xúc khách hàng và xác định đầyđủ, hoàn chỉnh và chính xác các yêucầu cho dự án•Dùng các phương thức gặp gở chínhImplementation Team
Tesing & Intergration TeamTraining TeamDelivery & Installation Team
•Dùng các phương thức gặp gở chínhthức và bên lề để xác định các yêucầu của hệ thống•Nếu không có khách hàng, có thểtiếp xúc với các user tiềm năngDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
tiếp xúc với các user tiềm năngSau khi xác định các yêu cầu, nhómnày sẽ làm việc với System DesignTeam để nhận các feedback.Nếu dự án được phát triển theo môMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
Nếu dự án được phát triển theo môhình tương tác cao nhưPrototype/Spiral model thì tính tươngtác và feedback là rất quan trọng kểcả với các nhóm khác
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3232
g g cả với các nhóm khác
Các Sub-TeamCác Sub Team
System analysisSystem Design TeamSystem Design TeamPlanning Team
Requirements TeamSystem Design TeamI l t ti T
System Design TeamSystem Design TeamXây dựng thiết kế chi tiết của hệthống sau khi các yêu cầu đã đượcxác định.Nếu sử dụng mô hình WaterfallImplementation Team
Tesing & Intergration TeamTraining TeamDelivery & Installation Team
Nếu sử dụng mô hình Waterfall,nhóm này phải feedback chonhóm Requirement những khókhăn nếu có.Sau khi hoàn chỉnh thiết kế nhómDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
Sau khi hoàn chỉnh thiết kế, nhómnày phải cộng tác vớiImplementation Team để nhậnfeedback.Nếu dự án được phát triển theoMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
Nếu dự án được phát triển theomô hình tương tác cao nhưPrototype/Spiral model thì tínhtương tác và feedback là rất quantrọng kể cả với các nhóm khác
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3333
g g trọng kể cả với các nhóm khác
Các Sub-TeamCác Sub Team
System analysisI l t ti T I l t ti T Planning Team
Requirements TeamSystem Design TeamI l t ti T
Implementation Team Implementation Team Phát triển hệ thống theo thiết kếđã có.• Coding
ể ấ d lImplementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
• Kiểm tra cấp ModuleSau khi hoàn tất chương trình,nhóm này sẽ cộng tác với nhómTesing & Integration để kiểm traá d lDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
các moduleNếu dự án được phát triển theomô hình tương tác cao nhưPrototype/Spiral model thì tính
á à f db k là ấMetrics TeamDocumentation TeamSystem Administration TeamReuse & Reengineering Team
tương tác và feedback là rất quantrọng kể cả với các nhóm khác
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3434
g g
Các Sub-TeamCác Sub Team
System analysis Testing & Integration TeamTesting & Integration TeamPlanning TeamRequirements TeamSystem Design TeamI l t ti T
Testing & Integration TeamTesting & Integration TeamXây dựng thiết kế chi tiết của hệ thốngsau khi các yêu cầu đã được xác định.Nếu sử dụng mô hình Waterfall, nhóm nàyphải feedback cho nhóm Requirementhữ khó khă ế óImplementation Team
Tesing & Intergration TeamTraining TeamDelivery & Installation Team
những khó khăn nếu có.Sau khi hoàn chỉnh thiết kế, nhóm nàyphải cộng tác với Implementation Team đểnhận feedback.Nhóm này có thể tiếp nhận các module rờiDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
ó ày có t ể t ếp ậ các odu e ờrạc và kiểm tra sau đó tích hợp thành hệthống hoàn chỉnh.Nếu dự án được phát triển theo mô hìnhtương tác cao như Prototype/Spiral modelthì tính tương tác và feedback là rất quanMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
thì tính tương tác và feedback là rất quantrọng kể cả với các nhóm khácNhóm này cũng có vai trò trong InterfaceControl Document để đặc tả các giao diệnvà giao tiếp giữa các thành phần trong hệ
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3535
g gthống
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti T
Trainning Team Trainning Team Implementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
ggChuẩn bị các công cụ và tài liệucho việc trainning cho ngườidùng•Kế hoạch trainningDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
•Kế hoạch trainning•Các tài liệu giảng dạy
Metrics TeamDocumentation TeamSystem Administration TeamReuse & Reengineering Team
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3636
g g
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti TImplementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation TeamDelivery & Installation TeamMaintenance TeamQuality Assurance TeamMetrics Team
Delivery & Installation Delivery & Installation TeamTeam
Nhiệm vụ là cài đặt hệ thốngcho khách hàng và các hỗ trợMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
cho khách hàng và các hỗ trợkỹ thuật trong cài đặt vận hànhhệ thống.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3737
g g
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti TImplementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
Maintenance Team Maintenance Team Bảo trì hệ thống sau khi chuyểnDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
ggiao và cài đặt•Cập nhật sửa chữa•Nâng cấp mở rộngCộng tác chặt chẻ với nhómMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
Cộng tác chặt chẻ với nhómimplementation để thực hiệnviệc maintenance
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3838
g g
Các Sub-TeamCác Sub Team
System analysisQuality Assurance TeamQuality Assurance TeamPlanning Team
Requirements TeamSystem Design TeamI l t ti T
Quality Assurance TeamQuality Assurance TeamNhóm này có 2 nhiệm vụ1. Thiết lập các tiêu chuẩn cho các
quá trình sản xuất cũng như tiêuchuẩn thực hiện của sản phẩmImplementation Team
Tesing & Intergration TeamTraining TeamDelivery & Installation Team
chuẩn thực hiện của sản phẩmphần mềm
2. Cung cấp các cơ chế kiểm tra,kiểm soát nhằm đánh giá khảnăng thỏa mãn các tiêu chuẩnDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
năng thỏa mãn các tiêu chuẩntương ứng của các nhóm làm việc.
Các tiêu chuẩn này dùng trong nội bộvà không chia sẻ với khách hàng.
Các tiêu chuẩn có thể được công bốMetrics TeamDocumentation TeamSystem Administration TeamReuse & Reengineering Team
Các tiêu chuẩn có thể được công bốkhi cần thiết, vì vậy cần được lưutrữ và báo cáo cho projectmanager để hoạt động với bộphận Q&A
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 3939
g g phận Q&A
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti T
Metrics Team Metrics Team Lưu trữ các thông tin thống kê vềcác hoạt động của các TEAmtrong dự án.Implementation Team
Tesing & Intergration TeamTraining TeamDelivery & Installation Team
trong dự án.•Số lượng các yêu cầumaintenance•Số lượng thực hiện dịch vụmaintenanceDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
maintenance•Số dòng code được viết•Thời gian thực hiện từng côngviệcNhóm này làm việc với hầu hếtMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
Nhóm này làm việc với hầu hếtcác nhóm để cung cấp báo cáo vềchất lượng, hiệu quả, đồng thờifeedback cho các nhóm đó vềhiệu quả công việc.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4040
g g hiệu quả công việc.
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti TImplementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
Documentation TeamDocumentation TeamNhóm này thực hiện các hoạtđộng thiết lập các tài liệuDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
cho hệ thống• Tài liệu về phân tích, thiết
kế, hiện thực, sourcecodeMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
code,..• Tài liệu hổ trợ : userguide,
manual, support document
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4141
g g
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti T System Administrationm System Administrationm Implementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
System Administrationm System Administrationm Team Team
Nhóm này có nhiệm vụ cungcấp và bảo đảm các hoạt độngDelivery & Installation Team
Maintenance TeamQuality Assurance TeamMetrics Team
p ạ ộ gcủa các hệ thống hạ tầng kỹthuật cần thiết cho dự ánNhóm này thông thường baogồm cả Network AdministrationMetrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering Team
gồm cả Network AdministrationTeam
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4242
g g
Các Sub-TeamCác Sub Team
System analysisPlanning TeamRequirements TeamSystem Design TeamI l t ti TImplementation TeamTesing & Intergration TeamTraining TeamDelivery & Installation Team
Reuse & Reengineering Reuse & Reengineering TeamTeam
h l à ế đ h ệDelivery & Installation TeamMaintenance TeamQuality Assurance TeamMetrics Team
• Chọn lựa và quyết định việc reuse các module đã có
• Việc reengineering cũng cần thiết khi mà việc phát triển Metrics Team
Documentation TeamSystem Administration TeamReuse & Reengineering
thiết khi mà việc phát triển đòi hỏi phải dùng đến các code cũ khi công nghệ đã thay đổi.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4343
g gTeam
Sub-Team (tt)Sub Team (tt)
Có rất nhiều việc quản lý trong từng nhóm và từngCó rất nhiều việc quản lý trong từng nhóm và từngcông đoạn.Có khá nhiều nhóm -> nhiều manager, tuy nhiên nếuá hó à hỏ thì th ờ là ột ời t hócác nhóm này nhỏ thì thường là một người trong nhóm
sẽ là manager của team.Việc scheduling giữa các team phụ thuộc vào mô hìnhViệc scheduling giữa các team phụ thuộc vào mô hìnhphát triển cụ thể là gì.Ví dụ nếu dùng mô hình Waterfall thì các công đoạn cóhể đ í h h hà h á b ớ lớ h á hóthể được tích hợp thành các bước lớn hơn, các nhóm
tham gia vào từng bước theo chức năng của mình.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4444
Các nhóm trong mô hình WaterfallCác nhóm trong mô hình Waterfall
SPECIFICATION: Planning, System Analysis, QA, Metrics, SPECIFICATION: Planning, System Analysis, QA, Metrics, Documentation, System Administration, Reuse & Reengineering
DESIGN: QA Metrics Documentation System Administration DESIGN: QA, Metrics, Documentation, System Administration, Reuse & Reengineering
CODE:QA Metrics Documentation System Administration Reuse CODE:QA, Metrics, Documentation, System Administration, Reuse & Reengineering
TESTING & INTEGRATION: QA, Metrics, Documentation, System TESTING & INTEGRATION: QA, Metrics, Documentation, System Administration, Reuse & Reengineering
MAINTENANCE: Trainning Delivery & Instalation QA Metrics
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4545
MAINTENANCE: Trainning, Delivery & Instalation,QA, Metrics, Documentation, System Administration, Reuse & Reengineering
Các nhân sự khác trong dự ánCác nhân sự khác trong dự án
Bên cạnh còn có một số nhân sự khác tham gia vào quá trình phátể ểtriển dự án nhưng có thể không được nêu tên một cách chính qui
Human-Computer Interface Evaluation: Đánh giá khả năngthích hợp của giao diện cả như người dùng cấp thấp và cấp caoT l S t P N ười ấ à bả đả á ô ầTools Support Person: Người cung cấp và bảo đảo các công cụ cầnthiết như tools, software, network vận hành theo yêu cầu của quá trìnhphát triểnSoftware Economist: Sử dụng các mô hình đánh giá cần thiết đểSoftware Economist: Sử dụng các mô hình đánh giá cần thiết đểước lượng chi phí phần mềm, phần cứng, resource và thời gian cần chodự án hoàn tấtProject Librarian: Có trách nhiệm lưu trữ và sắp xếp hệ thống tất cảcác tài liệu của dự áncác tài liệu của dự ánChuyên gia hỗ trợ: Một số dự án cần có những chuyên gia trong lĩnhvực tương ứng hổ trợ, tư vấn về mặt chuyên môn hay kỹ thuật
NHÂN SỰ CỦA CÁC TEAM CÓ THỂ THAY ĐỔI THƯỜNG XUYÊN TRONG
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4646
NHÂN SỰ CỦA CÁC TEAM CÓ THỂ THAY ĐỔI THƯỜNG XUYÊN TRONG QUÁ TRÌNH HOẠT ĐỘNG DO NHIỀU YẾU TỐ
Các yếu tố ảnh hưởng đến các teamCác yếu tố ảnh hưởng đến các team
Nhân sự cần thay đổi theo từng công đoạn: các côngNhân sự cần thay đổi theo từng công đoạn: các côngđoạn cần nhiều nhân sự và cần thời gian dài nhưcoding, testing & integration.Cá ê hâ khá h kháCác nguyên nhân khách quan khác:
N hân sự thay đổi công việc: chuyên môn thay đổi, công nghệ mớicập nhậtN hân sự nghĩ do thay đổi việc, bệnh, về hưuN hân sự mới: mang lại tư duy mới và công nghệ mới tuy nhiên phảicần thời gian tiếp cậpg p ập
Việc xây dựng các team là linh động theo từng dự ánvà cần có điều phối giữa các dự án theo từng tiến độcông việc
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4747
công việc.
Project managementProject management
Dự đoán quy mô và độ phức tạp của dự ánDự đoán quy mô và độ phức tạp của dự ánXác định các team cần thiết cho hiện thực dự ánXác định kế hoạch dự đoán thời gian hoàn thành dự ánXác định các tài nguyên cần thiết cho dự án bao gồmphần mềm, hệ thống, ….Tí h t á hi hí â dự dự áTính toán chi phí xây dựng dự ánXây dựng lô trình thực hiện dự án (smiletone)Thực hiện các công việc quản lý trong thời gian thựcThực hiện các công việc quản lý trong thời gian thựchiện dự án để bảo đảm đúng kế hoạch đã đề ra.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4848
Các công việc của Project management t thời i th hiệ d átrong thời gian thực hiện dự án
Quản trị nhân sự: điều phối, quản lý công việc,..Quản trị nhân sự: điều phối, quản lý công việc,..Phân bổ các tài nguyên của hệ thống theo kế hoạchĐiều phối nhân sự: trong công ty và bên ngoàiXữ lý các phát sinh về thời gian biểuQuản lý các thay đổi yêu cầu của dự ánGiải quyết các sự cố ngoài kế hoạch: máy móc hưhỏng, nhân sự thay đổi,..Báo cáo cho lãnh đạo về dự ánBáo cáo cho lãnh đạo về dự ánGiao tiếp với khách hàngStaffs trainning
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 4949
g
Software Project EstimationSoftware Project Estimation
Dự đoán điều gì?Dự đoán điều gì?Quy mô của sản phNm sẽ được phát triểnCác yêu cầu, resource cần thiết để có thể phát triển sản phNm thànhcôngcông
Để phát triển sản phẩm cần biết nhiều thông tinMáy tính cần cho phát triển Các công cụ cho Documentation
Size of ProjectSize of Project
y pCác phần mềm cơ bản nhưcompilerPhương thức giao tiếp giữa cácbộ phận
g ụThiết bị copy, lưu trữCông nghệ sử dụngLập trình viênểSize of ProjectSize of Projectbộ phận
CASE ToolsCác gói phần mềm mà hệ thốngcần liên kết, tương tác.
Kiểm tra viênQuản lýNhà thiết kếCác nhân sự khác
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5050
Máy tính cho tesingMáy tính cho trainning
Các nhân sự khác……….
Project SizeProject Size
Kích thước được đo bằng “lines of code”Kích thước được đo bằng lines of codeLàm thế nào để dự đoán được kích thước của một đềán phần mềm?
ằ ố ế ểKính thước đo bằng số dòng code được viết để hoàn thành dự ánDự án chưa thực hiện làm sao biết số dòng code sẽ được viết
Phương pháp Analogy và Reasoning-by-AnalogyPhương pháp Analogy và Reasoning by AnalogyPhân bố nhân lực cho dự án phần mềm trên cơ sởlines of code đã dự đoán.
Đánh giá năng xuất của mỗi người trong dự án
Metric data cho vấn đề estimated và phân bổ resource.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5151
Phương pháp AnalogyPhương pháp Analogy
Analogy là gì ? Suy luận theo analogy?gy g y ậ gyĐiều kiện để sử dụng phương pháp analogy:
Có bàibài toántoán đãđã biếtbiết có bản chất tương tựĐã có giải pháp của bàibài toántoán đãđã biếtbiếtĐã có giải pháp của bàibài toántoán đãđã biếtbiết
Cách áp dụng analogyXác định được các thông số tương ứng giữa 2 bài toánÁ d i i h b i đ biế h b i iÁp dụng giải pháp của bài toán đã biết cho bài toán mới
Với dự án phần mềmXác định các dữ liệu của những vấn đề đã làm nhờ vào metricPhân tích dự án cần dự đoán thành các thành phầnXác định kích thước tương ứng từng phần với thông tin metric đã cóloại trừ các kích thước các phần được reuse
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5252
Tổng kích thước các phần kíchkích thướcthước dựdự ánán
Dự đoán nhân lực cho dự ánDự đoán nhân lực cho dự án
Lines of new code Approximate N b f •Thực tế không thể tăng tuyến tínhNumber of Software
Enginneers
5,000 1
Thực tế không thể tăng tuyến tính một cách đơn giản như thế•Không phải tất cả nhân lực đều đồng đều.Khi dự á à lớ thì á ấ đề10,000 1
20,000 2
50,000 5
00 000 0
•Khi dự án càng lớn thì các vấn đề quản lý giao tiếp và liên kết sẽ phức tạp hơn làm giảm năng xuất.•Dự án lớn, các thay đổi ngoài dự kiến
100,000 10
200,000 20
500,000 50
1 000 000 100
ự , y g ựsẽ nhiều hơn nên năng xuất bị ảnh hưởng.•Còn nhiều khâu khác ảnh hưởng đến dự án chứ không phải chỉ có coding1,000,000 100
2,000,000 200
5,000,000 500
10 000 000 1 000
dự án chứ không phải chỉ có coding.
Tính dựa trên thông số nào?Tính dựa trên thông số nào?
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5353
10,000,000 1,000
100,000,000 10,000
Dự đoán nhân lực theo MetricDự đoán nhân lực theo Metric
Lines of new code Approximate N b f
•Thiết lập bảng dự liệu theo số liệu thống ê à ệ ừ ớNumber of
Software Enginneers
5,000 7
kê mà metric team đã thực hiện từ trước.•Số liệu này chứa đựng các yếu tố khác về quản lý và các công đoạn khác nhau của một đề án tổng thể.
10,000 14
20,000 27
50,000 77
100 000 144
•Xây dựng một hàm dự đoán nhân lực cho dự án (person-month )dạng
100,000 144
200,000 288
500,000 790
1 000 000 1 480
y = mx + by = mx + bvới m, b được xác định bằng phương pháp bình phương tối thiểu ( ô hứ í h b ở1,000,000 1,480
2,000,000 3,220
5,000,000 8,000
10 000 000 15 960
(Xem công thức tính m, b ở trang 71)Dựa vào đó ta tính được số nhân lực cần thiết cho dự án.Y hời i h hiệ (
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5454
10,000,000 15,960
100,000,000 160,027Y thời gian thực hiện (person month)X kích thước dự án
Ví dụVí dụ
Dựa vào bảng trên ta tính được y = 0.002 x + 1.84 . Dựa vào bảng trên ta tính được y = 0.002 x + 1.84 . Dựa vào bảng trên ta tính được y 0.002 x + 1.84 . Dựa vào bảng trên ta tính được y 0.002 x + 1.84 . Ví dụ với dự án kích thước 15,000 lines of code ta sẽ cần 32 personVí dụ với dự án kích thước 15,000 lines of code ta sẽ cần 32 person--month để giải quyếtmonth để giải quyết••Xây dựng bảng metric của các dự án tương tự ta tính được là cần Xây dựng bảng metric của các dự án tương tự ta tính được là cần hâ bổ b hiê ười là t b lâhâ bổ b hiê ười là t b lâ
Projects Domain Months Effort (person-month) Size
phân bổ bao nhiêu người làm trong bao lâu.phân bổ bao nhiêu người làm trong bao lâu.••Ví dụ bảng tính toán cho các dự án databaseVí dụ bảng tính toán cho các dự án database
Application 1 Graphics Utility 12 30 5000
Application 2 Graphics Utility 10 40 8000
Application 3 Graphics Utility 24 30 10000
A li ti 4 G hi Utilit 36 100 20000Application 4 Graphics Utility 36 100 20000
Application 5 Graphics Utility 12 30 5000
Application 6 Graphics Utility 24 30 10000
Application 7 Graphics Utility 48 90 25000
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5555
Application 7 Graphics Utility 48 90 25000
HẠN CHẾ CỦA PHƯƠNG PHÁP NÀYHẠN CHẾ CỦA PHƯƠNG PHÁP NÀY
COCOMO ModelCOCOMO Model
Xác định cả 2 thông số là số nhân lực và thời gian phátXác định cả 2 thông số là số nhân lực và thời gian pháttriểnTrình tự thực hiện
ầPhân tích các yêu cầu của dự ánXác định line of code của từng yêu cầu dự vào metric dataTrừ các phần đã được xác định là reuse codep ợ ịTổng các phần còn lại tính được KK line of codeÁp dựng công thức tínhE = a * K * exp(b )E = ab * K * exp(bb)D = cb * E * exp(db)
E là số nhân lực tham gia vào dự án
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5656
D là thời gian thực hiện dự án
COCOMO Model (tt)COCOMO Model (tt)
Các hệ số của công thức COCOMOệ g
Software Project type Ab Bb Cb Db
Small project, experienced team, flexiblerequirement
2.4 1.05 2.5 0.38
Hard real time rew\quirements and strict 3 6 1 2 2 5 0 32Hard real-time rew\quirements and strictinteroperability
3.6 1.2 2.5 0.32
A mixture of the other two type of projects 3.0 1.12 2.5 0.35
Các giá trị E và D tính được phụ thuộc vào khả năng estimate giátrị line of code (K) của dự án.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5757
ị ( ) ự
Project SchedulingProject Scheduling
Scheduling bao gồm:g gXác dịnh các mốc tiến trình thực hiện dự ánPhân bổ resource cho các tiến trình của dự án
Quản trị và thực hiện các điều chỉnh cần thiết cho cácQuản trị và thực hiện các điều chỉnh cần thiết cho cáctiến trình khi có sự thay đổi ngoài kế hoạch
Phân bổ lại nguồn resource (thêm người)Phân bổ lại milestone của từng tiến trìnhPhân bổ lại milestone của từng tiến trình
Mục tiêu là bảo đảm deadline không bị thay đổiPhương pháp quản trị và điều chỉnh:
FUNCTION POINTCác công cụ dùng trong scheduling : MS project,Cocomo2
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5858
Cocomo2
Activity network modelActivity network model
M 1M 1T 3T 3
15 ngày15 ngàyT 9T 9
15 ngày15 ngày
SS
T 1T 18 ngày8 ngày
M 1M 114/7/9914/7/99
M 3M 325/7/9925/7/99
T 2T 2
T 6T 65 ngày5 ngày
T 11T 117 ngày7 ngày
M 4M 404/8/9904/8/99
M 6M 625/8/9925/8/99
04/07/99Start
04/07/99
M 2M 225/7/9925/7/99
T 2T 215 ngày15 ngày
T 4T 4 T 5T 510 à10 à
T 7T 720 ngày20 ngày
T 10T 10T 12T 12
10 à10 à
M 7M 711/8/9911/8/99
M 8M 85/9/995/9/99
Thiết lậ ti it t k ồ á Mi t (M) à T k (T)
25/7/9925/7/99
M 5M 518/7/9918/7/99
10 ngày10 ngày 10 ngày10 ngày
T 8T 825 ngày25 ngày
T 10T 1015 ngày15 ngày
10 ngày10 ngày
FINISH19/09/99
FINISH19/09/99
Thiết lập activity network: gồm các Minestone (M) và Task (T)Xác định critical path: có tổng thời gian thực hiện dài nhấtĐiều chỉnh các M-i để bảo đảm deadlineề ỉ á ằ á ổ ổ â
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 5959
Điều chỉnh các T-i bằng cách thay đổi/bổ sung nhân sự (Team)
Activities Bar Chart –PERL chartActivities Bar Chart PERL chart
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
STARTSTART
T4T4
T1T1
M1M1T4T4
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 6060
Ch ơCh ơ 33ChươngChương 33
PhânPhân tíchtích hệhệ thốngthống(system analysis)(system analysis)
••NhữngNhững vấnvấn đềđề trongtrong phânphân tíchtích hệhệ thốngthống••Thu Thu thậpthập yêuyêu cầucầu từtừ ngườingười sửsử dụngdụng••PhânPhân tíchtích yêuyêu cầucầu••XácXác địnhđịnh tínhtính năngnăng hệhệ thốngthống
Mục tiêu của phân tích hệ thốngMục tiêu của phân tích hệ thốngụ p ệ gụ p ệ g
•• KháchKhách hànghàng vàvà nhànhà phátphát triểntriển gặpgặp nhaunhau đểđể thảothảo luậnluận vềvềêê ầầ ủủ ệệ ốố ầầ ềề ầầ ââyêuyêu cầucầu củacủa hệhệ thốngthống phầnphần mềmmềm cầncần xâyxây dựngdựng
•• NhàNhà phátphát triểntriển tìmtìm hiểu,hiểu, phânphân tíchtích vàvà kiểmkiểm chứngchứng lạilại(validate)(validate) yêuyêu cầucầu vàvà biểubiểu diễndiễn nónó bằngbằng mômô hìnhhình phânphân tíchtích(validate)(validate) yêuyêu cầucầu vàvà biểubiểu diễndiễn nónó bằngbằng mômô hìnhhình phânphân tíchtích
•• MôMô hìnhhình phânphân tíchtích đặcđặc tảtả toàntoàn bộbộ nộinội dungdung :: chứcchức năng,năng,dữdữ liệuliệu nhập/xuất,nhập/xuất, cáccác hoạthoạt độngđộng củacủa hệhệ thốngthống cầncần phátphátểểtriểntriển
•• XâyXây dựngdựng cáccác từtừ điểnđiển dữdữ liệuliệu địnhđịnh nghĩanghĩa cáccác kháikhái niệmniệm đặcđặcthùthù củacủa hệhệ thốngthống ýý nghĩanghĩa cấucấu trúctrúcthùthù củacủa hệhệ thống,thống, ýý nghĩa,nghĩa, cấucấu trúc,trúc,……
•• ThốngThống nhấtnhất vớivới kháchkhách hànghàng vềvề mômô hìnhhình vàvà tínhtính năngnăng củacủahệhệ thốngthống
6262Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Phân tích hệ thốngPhân tích hệ thốngệ gệ g
•• PhânPhân tíchtích hệhệ thốngthống làlà bướcbước đầuđầu tiêntiên rấtrất quanquan trọngtrọng chocho dựdự ánán phátpháttriểntriển phầnphần mềmmềmtriểntriển phầnphần mềmmềm
•• CôngCông việcviệc phânphân tíchtích hệhệ thốngthống baobao gồmgồm– Thu thập yêu cầu và quy trình nghiệp vụ hiện tại
ể ế ằ– Phân tích và xác lập các quy trình sẽ được phát triển/thay thế bằng máy tính– Xác thực các yêu cầu/tính năng của hệ thống
•• KếtKết quảquả củacủa việcviệc phânphân tíchtích hệhệ thốngthống làlà cáccác tàitài liệuliệu đặcđặc tảtả tínhtính năngnăng hệhệốố áá àà ệệ àà ôô ờờ ởở áá ồồ ểể ồồthốngthống.. CácCác tàitài liệuliệu nàynày thôngthông thườngthường ởở dạngdạng cáccác sơsơ đồ,đồ, biểubiểu đồ,đồ,....
•• KếtKết quảquả nàynày dùngdùng chocho việcviệc xácxác thựcthực cáccác tínhtính năngnăng củacủa hệhệ thốngthống vớivớikháchkhách hànghàng
•• KếtKết quảquả nàynày làlà đầuđầu vàovào củacủa quáquá trìnhtrình tiếptiếp theotheo làlà thiếtthiết kếkế hệhệ thốngthống..•• TùyTùy thuộcthuộc vàovào côngcông nghệnghệ phátphát triểntriển màmà sửsử dụngdụng cáccác phươngphương pháppháp
phânphân tíchtích phùphù hợphợp :: cấucấu trúctrúc hayhay OOPOOP
6363Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Những vấn đề trong phân tích hệ thốngNhững vấn đề trong phân tích hệ thốngg g p ệ gg g p ệ g
•• CáchCách biệtbiệt vềvề chuyênchuyên mônmôn củacủa lĩnhlĩnh vựcvực cầncần phânphân tíchtích•• SựSự hiểuhiểu biếtbiết củacủa nhữngnhững ngườingười endend useruser vềvề quyquy trìnhtrình làmlàm
việcviệc vàvà khảkhả năngnăng ứngứng dụngdụng phầnphần mềmmềm chocho côngcông việcviệc củacủahọhọhọhọ
•• NhữngNhững vấnvấn đềđề vềvề điềuđiều kiệnkiện hạhạ tầngtầng hổhổ trợtrợ hoạthoạt độngđộng củacủahệhệ thốngthống
•• TínhTính sẳnsẳn sàngsàng thôngthông tintin củacủa cáccác hệhệ thốngthống đangđang cócó sẽsẽtươngtương táctác vớivới hệhệ thốngthống cầncần xâyxây dựngdựngĐịnhĐịnh hướnghướng ứngứng dụngdụng lâulâu dàidài chưachưa có/có/ chưachưa rõrõ ràngràng•• ĐịnhĐịnh hướnghướng ứngứng dụngdụng lâulâu dàidài chưachưa có/có/ chưachưa rõrõ ràngràng
•• CôngCông cụ/ngôncụ/ngôn ngữngữ sửsử dụngdụng đểđể đặcđặc tảtả hệhệ thốngthống // kếtkết quảquảphânphân tíchtích
6464Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
pp
Quy trình phân tích hệ thốngQuy trình phân tích hệ thốngQ y p ệ gQ y p ệ g
•• CácCác bướcbước chínhchínhậ ô ệ ố ệ
Tìm hiểu và xây dựng lại ệ ệ ố– Thu thập thông tin hệ thống hiện
tại– Thu thập yêu cầu
Phâ tí h ê ầ
hiện trạng của hệ thống
•Các quy trình hoạt động/nghiệp vụ– Phân tích yêu cầu
– Xác lập tính năng hệ thống– Xác thực tính năng hệ thống
động/nghiệp vụ•Phương thức và ý nghĩa của các quá trình xử lý•Dữ liệu của hệ thốngDữ liệu của hệ thống•Điều kiện hạ tầng: thiết bị, con người
6565Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quy trình phân tích hệ thốngQuy trình phân tích hệ thốngQ y p ệ gQ y p ệ g
•• CácCác bướcbước chínhchínhậ ô ệ ố ệ– Thu thập thông tin hệ thống hiện
tại– Thu thập yêu cầu
Phâ tí h ê ầ
Xác định các yêu cầu
•Các yêu cầu về chức năng– Phân tích yêu cầu– Xác lập tính năng hệ thống– Xác thực tính năng hệ thống
Các yêu cầu về chức năng của hệ thống•Các yêu cầu về môi trường vận hành: thiết bị, con ngườig
6666Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quy trình phân tích hệ thốngQuy trình phân tích hệ thốngQ y p ệ gQ y p ệ g
•• CácCác bướcbước chínhchínhậ ô ệ ố ệ– Thu thập thông tin hệ thống hiện
tại– Thu thập yêu cầu
Phâ tí h ê ầPhân tích các yêu cầu
– Phân tích yêu cầu– Xác lập tính năng hệ thống– Xác thực tính năng hệ thống
•Phân tích các yêu cầu theo quy trình sử lý•Bổ sung các quy trình cho g q yphù hợp với máy tính•Yều cầu bổ sung các thông tin
6767Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quy trình phân tích hệ thốngQuy trình phân tích hệ thốngQ y p ệ gQ y p ệ g
•• CácCác bướcbước chínhchínhậ ô ệ ố ệ– Thu thập thông tin hệ thống hiện
tại– Thu thập yêu cầu
Phâ tí h ê ầ Xá lậ tí h ă ủ hệ– Phân tích yêu cầu– Xác lập tính năng hệ thống– Xác thực tính năng hệ thống
Xác lập tính năng của hệ thống
•Xác lập các chức năng mà•Xác lập các chức năng mà hệ thống sẽ bao gồm•Xác lập các điều kiện và môi trường hoạt độngtrường hoạt động
6868Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quy trình phân tích hệ thốngQuy trình phân tích hệ thốngQ y p ệ gQ y p ệ g
•• CácCác bướcbước chínhchínhậ ô ệ ố ệ– Thu thập thông tin hệ thống hiện
tại– Thu thập yêu cầu
Phâ tí h ê ầXác thực tính năng hệ
thố– Phân tích yêu cầu– Xác lập tính năng hệ thống– Xác thực tính năng hệ thống
thống
•Xác thực với người dùng về tính hợp lý và đầy đủ của cáctính hợp lý và đầy đủ của các tính năng•Xác thực các quy trình nghiệp vụg ệp ụ•Xác thực các ràng buộc
6969Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quy trình phân tích hệ thốngQuy trình phân tích hệ thốngQ y p ệ gQ y p ệ g
•• CácCác bướcbước chínhchínhậ ô ệ ố ệ– Thu thập thông tin hệ thống hiện
tại– Thu thập yêu cầu
Phâ tí h ê ầ– Phân tích yêu cầu– Xác lập tính năng hệ thống– Xác thực tính năng hệ thống
Phương pháp cấu trúcPhương pháp cấu trúc Phương pháp OOPPhương pháp OOPPhương pháp cấu trúcPhương pháp cấu trúcCác bước được thực hiện đồng thời và sen kẽ nhauThường sử dụng lược đồ:
Phương pháp OOPPhương pháp OOPSử dụng UML: lược đồ Use case, Class
7070Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
g ụ g ợDFD, ERD, STD
Phâ í h hệ hố h h ớ há iểPhâ í h hệ hố h h ớ há iểPhân tích hệ thống theo hướng phát triển Phân tích hệ thống theo hướng phát triển kỹ thuật lập trình cấu trúckỹ thuật lập trình cấu trúc
Tiếp cận của phương pháp phát triển cổ điển cho bước phân Tiếp cận của phương pháp phát triển cổ điển cho bước phân tích hệ thốngtích hệ thốngCác lược đồ DFD, STD, ERDCác lược đồ DFD, STD, ERD
CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHCÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHProcess Specification (PSPEC)
Lược đồ DFDLược đồ DFD
Lược đồdò hả
Lược đồ DFDLược đồ DFD•Mô hình chức năng và dòngthông tin: DFD, PSPEC•Mô tả dòng thông tin di chuyển
Từ điểndữ liệu
dòng chảydữ liệu
Lược đồ quanhệ thực thể
Mô tả dòng thông tin di chuyển(flow) xuyên qua các hệ thốngthiên về phần mềm.•Diển tả các tương tác xuất nhập
Lược đồ dịch chuyểntrạng thái
dữ liệu với con người và các hệthống khác•Lưu đồ dòng chảy dữ liệu DFD(Data Flow Diagram) cung cấp 4(Data Flow Diagram) cung cấp 4ký hiệu cơ bản để mô hình sự dichuyển của dòng thông tin•Mở rộng của Ward & Mellor;
7272Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
ộ g ;Hatley & Pirbhai cho realtime
CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHCÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHProcess Specification (PSPEC)
Lược đồdò hả
Lược đồ STDLược đồ STD•Mô hình hành vi của hệ thống•Lược đồ dịch chuyển trạng thái
Từ điểndữ liệu
dòng chảydữ liệu
Lược đồ quanhệ thực thể
Lược đồ dịch chuyển trạng thái(STD) thể hiện
• Các trạng thái khác nhaucủa hệ thống
Lược đồ dịch chuyểntrạng thái
• Sự dịch chuyển giữa cáctrạng thái đó
•Mô tả chi tiết hơn điều kiện xảy
Control Specification (CSPEC)
ra của các hành vi•Cung cấp một hình ảnh động vềhệ thống
7373Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHCÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHProcess Specification (PSPEC)Đặc tả
từ điểndữ liệu Lược đồ ERDLược đồ ERD
Lược đồdò hả
Lược đồ ERDLược đồ ERD•Đặc tả các thông tin về dữ liệucủa hệ thống•Cấu trúc dữ liệu
Từ điểndữ liệu
dòng chảydữ liệu
Lược đồ quanhệ thực thể
Cấu trúc dữ liệu•Các quan hệ và ràng buộc dữliệu
Lược đồ dịch chuyểntrạng thái
Control Specification (CSPEC)
7474Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHCÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHProcess Specification (PSPEC)Đặc tả
từ điểndữ liệu Từ điển dữ liệuTừ điển dữ liệu
Lược đồdò hả
Từ điển dữ liệuTừ điển dữ liệu•Làm rõ các khái niệm và thuậtngữ trong hệ thống•Nếu lên ý nghĩa và phạm vi sử
Từ điểndữ liệu
dòng chảydữ liệu
Lược đồ quanhệ thực thể
Nếu lên ý nghĩa và phạm vi sửdụng của các khái niệm này•Xác định các cấu trúc thông tincần thiết
Lược đồ dịch chuyểntrạng thái
Control Specification (CSPEC)
7575Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
LƯỢC ĐỒ DÒNG CHẢY DỮ LIỆU (DFD)LƯỢC ĐỒ DÒNG CHẢY DỮ LIỆU (DFD)Ợ Ệ ( )Ợ Ệ ( )
•• ĐượcĐược xâyxây dựngdựng từtừ 44 phầnphần tửtử chínhchính– ThựcThực thểthể: tạo ra hoặc tiêu thụ thông tin, nằm bên ngoài biên giới của
phạm vi thông tin hệ thống– ChứcChức năngnăng xửxử lýlý: thực hiện chức năng nào đó, tiêu thụ và tạo ra
thông tin, nằm bên trong phạm vi thông tin hệ thống– ThôngThông tintin hayhay dữdữ liệuliệu– KhoKho dữdữ liệuliệu: lưu trữ dữ liệu mà được sử dụng bởi nhiều chức năngệệ ệ ợ ụ g g
xử lý
ể Kho Dữ LiệuThực thể Chức năngxử lý Dữ liệu
Kho Dữ Liệu
7676Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
LƯỢC ĐỒ DÒNG CHẢY DỮ LIỆU (t.t)LƯỢC ĐỒ DÒNG CHẢY DỮ LIỆU (t.t)Ợ Ệ ( )Ợ Ệ ( )
•• DFDDFD đượcđược xâyxây dựngdựng quaqua nhiềunhiều mứcmức kháckhác nhaunhau:: mứcmức 00,, 11,,22……
•• DFDDFD mứcmức sausau chichi tiếttiết hơnhơn mứcmức trướctrước•• ProcessProcess SpecificationSpecification (PSPEC)(PSPEC) bổbổ sungsung chocho DFDDFD•• ProcessProcess SpecificationSpecification (PSPEC)(PSPEC) bổbổ sungsung chocho DFDDFD•• TínhTính liênliên tụctục củacủa dòngdòng dữdữ liệuliệu
7777Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Kỹ thuật phân tích hệ thốngKỹ thuật phân tích hệ thốngỹ ậ p ệ gỹ ậ p ệ g
•• TiếpTiếp xúc,xúc, phỏngphỏng vấnvấn cáccác ngườingười dùngdùng trongtrong hệhệ thốngthống thuthuậậ áá ôô ềề ệệ ủủ ờờ ùùthậpthập cáccác thôngthông tintin vềvề nghiệpnghiệp vụvụ củacủa ngườingười dùngdùng
•• ThiếtThiết lậplập đoạnđoạn vănvăn miêumiêu tảtả chứcchức năngnăng (processing(processingnarrative)narrative) chocho hệhệ thốngthống cầncần xâyxây dựngdựngnarrative)narrative) chocho hệhệ thốngthống cầncần xâyxây dựngdựng
•• XâyXây dựngdựng DFDDFD ởở cáccác mứcmức kháckhác nhaunhau– Thiết lập sơ đồ ngữ cảnh (DFD mức 0)– Phân hoạch DFD vào các mức cao hơn– Sử dụng phương pháp duyệt văn phạm.
L ô l ô t â th tí h liê t ủ dò dữ liệ– Luôn luôn tuân theo tính liên tục của dòng dữ liệu•• ViếtViết PSPECPSPEC chocho cáccác chứcchức năngnăng củacủa DFDDFD mứcmức caocao nhấtnhất
7878Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Xây dựng DFD Xây dựng DFD –– Ví dụVí dụy ự gy ự g ụụ
•• PhầnPhần mềmmềm SafeHomeSafeHome:: ThiếtThiết lậplập đoạnđoạn vănvăn miêumiêu tảtả xửxử lýlý•• DFDDFD mứcmức ngữngữ cảnhcảnh:: nhậnnhận diệndiện cáccác thựcthực thểthể vàvà dữdữ liệuliệu
input,input, outputoutputBảng điều khiểnBảng điều khiển
Màn hìnhLệnh và dữ liệu Thông tin hiển thị
SafeHomeSystem Chuông
Trạng thái cảm ứng
Kiểu báo động
Bộ cảm ứngĐ ờ điệ th i
Trạng thái cảm ứng Tần số của số điện thoại
7979Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Đường điện thoại
Xây dựng DFD Xây dựng DFD –– Ví dụVí dụy ự gy ự g ụụ
DFD mức 1: hình thành một số chức năng chính
Bảng điều khiểnCấu hìnhYêu cầu một số chức năng chính
Tương tácvới User
Lệnh và dữ liệuCấu hìnhhệ thốngcấu hình
Thông số cấu hìnhvới User
Màn hìnhCấm/Cho phép
Start/Stop
Maät maõThông báo
Xử lýmật mã Hiển thịXác nhận mật mã
Thông tin cảm ứng
Thoâng tin hieån thò
ChuôngTraïng thaùi caûm öùngKiểu báo động chuông
Tần số của điện thoại
Theo dõicảm ứng
Thông tin cảm ứng
8080Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Bộ cảm ứng Đường điện thoạiTần số của điện thoại
Mô hình hành vi STD Mô hình hành vi STD –– Ví dụVí dụụụ
Rảnh————————
Đầy giấy và sẵn sàng———————— Mô hình hành vi hệ
Đọc lệnh
Đầy giấy
Yêu cầu đọc lệnhYêu cầu copy
Copy xong————————
Mô hình hành vi hệthống máy photocopy
Thực hiện copy Nạp giấy
y g y————————Yêu cầu đọc lệnh
————————Yêu cầu đọc lệnh
ự ệ py Nạp giấyHết giấy
————————Yâu cầu nạp giấy
Kẹt giấy————————Yê ầ ử lý lỗi
Hết kẹt giấy————————Yêu cầu đọc lệnh
8181Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Xử lý lỗiYêu cầu xử lý lỗi Yêu cầu đọc lệnh
Tự điển dữ liệuTự điển dữ liệuự ệự ệ
•• NhiềuNhiều phầnphần tửtử đượcđược tạotạo rara trongtrong mômô hìnhhình phânphân tíchtích:: dữdữliệliệ hứhứ ăă điềđiề khiểkhiểliệu,liệu, chứcchức năng,năng, điềuđiều khiểnkhiển ……
•• PhảiPhải cócó mộtmột cáchcách thứcthức quảnquản lýlý cáccác phầnphần tửtử đóđó saosao chochohiệuhiệu quảquả TừTừ điểnđiển dữdữ liệuliệu
•• ĐịnhĐịnh nghĩanghĩa:: TừTừ điểnđiển dữdữ liệuliệu làlà mộtmột danhdanh sáchsách cócó tổtổ chứcchức củacủatấttất cảcả cáccác phầnphần tửtử dữdữ liệuliệu cầncần thiếtthiết chocho hệhệ thốngthống.. CácCác phầnphần tửtửđượcđược địnhđịnh nghĩanghĩa chínhchính xácxác vàvà chặtchặt chẽchẽ saosao chocho cảcả phânphân tíchtích viênviênợợ ịị gg ặặ ppvàvà kháchkhách hànghàng cùngcùng chiachia sẻsẻ mộtmột suysuy nghĩnghĩ vềvề chúngchúng..
•• TừTừ điểnđiển dữdữ liệuliệu thườngthường đượcđược hiệnhiện thựcthực nhưnhư làlà mộtmột phầnphầncủacủa côngcông cụcụ CASECASEcủacủa côngcông cụcụ CASECASE..
•• MỗiMỗi phầnphần tửtử baobao gồmgồm nhữngnhững thôngthông tintin:: tên,tên, bíbí danh,danh, đượcđượcdùngdùng ởở đâu/nhưđâu/như thếthế nào,nào, đặcđặc tảtả nộinội dungdung vàvà thôngthông tintin phụphụ trợtrợ
8282Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Tự điển dữ liệu Tự điển dữ liệu –– Ví dụVí dụự ệự ệ ụụ
•• VíVí dụdụ phầnphần tửtử dữdữ liệuliệu sốsố điệnđiện thoạithoạiố ệTên: Số điện thoại
Bí danh: KhôngĐược dùng ở đâu/như thế nào:
ế ềoutput của Thiết lập điều kiện báo độnginput của Quay số
Đặc tả nội dung:ố ốsố điện thoại = [ mở rộng địa phương | số bên ngoài ]
mở rộng địa phương = [ 2001 | 2002 … | 2009 ]số bên ngoài = 9 + [ số địa phương | số đường dài ]ố ề ố ốsố địa phương = tiền tố + <chuỗi 4 ký số>
số đường dài = (1) + mã vùng + số địa phươngtiền tố = [ 795 | 799 | 874 | 877 ]
8383Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Review Review –– Phân tích hệ thống theo cấu trúcPhân tích hệ thống theo cấu trúcệ gệ g
•• PhânPhân tíchtích yêuyêu cầucầu theotheo pppp cổcổ điểnđiển baobao gồmgồm::– Mô hình chức năng và dòng thông tin (DFD),– Mô hình dữ liệu (ERD)
à ô ì à i (S )– và Mô hình hành vi (STD)•• LượcLược đồđồ DFDDFD cơcơ bảnbản cócó 44 kýký hiệuhiệu vàvà nónó đượcđược mởmở rộngrộng đểđể
biểubiểu diễndiễn đượcđược cáccác hệhệ thốngthống thờithời giangian thựcthựcbiểubiểu diễndiễn đượcđược cáccác hệhệ thốngthống thờithời giangian thựcthực•• XâyXây dựngdựng DFDDFD mứcmức 00 rồirồi đếnđến cáccác mứcmức caocao hơnhơn;; chúchú ýý
bảobảo toàntoàn tínhtính liênliên tụctục củacủa dòngdòng dữdữ liệuliệu•• TừTừ điểnđiển dữdữ liệuliệu giúpgiúp quảnquản lýlý vàvà tratra cứucứu cáccác phầnphần tửtử dữdữ
liệuliệu
8484Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Phâ í h hệ hố h h ớ há iểPhâ í h hệ hố h h ớ há iểPhân tích hệ thống theo hướng phát triển Phân tích hệ thống theo hướng phát triển kỹ thuật lập trình OOPkỹ thuật lập trình OOP
Tiếp cận của phương pháp phát triển OOP cho bước phân tích hệ Tiếp cận của phương pháp phát triển OOP cho bước phân tích hệ thốngthống
AI / Vị trí như thế nào / Làm Gì / Khi nàoAI / Vị trí như thế nào / Làm Gì / Khi nàoCác lược đồCác lược đồCác lược đồ Các lược đồ
–Lược đồ Use-case: thu thập yêu cầu – mô hình nghiệp vụ–Lược đồ lớp: phân tích hệ yêu cầu – mô hình phân tích
Mô hình nghiệp vụ Mô hình nghiệp vụ -- Thu thập yêu cầuThu thập yêu cầug ệp ụg ệp ụ ập yập y
•• QuanQuan điểmđiểm thuthu thập/phânthập/phân tíchtích yêuyêu cầucầu củacủa mômô hìnhhìnhnghiệpnghiệp hệhệ thốngthống gồmgồm cócó AI/LàmAI/Làm nhữngnhững gì/Khigì/Khi nàonàonghiệpnghiệp vụvụ:: hệhệ thốngthống gồmgồm cócó AI/LàmAI/Làm nhữngnhững gì/Khigì/Khi nàonào
•• LượcLược đồđồ UseUse--casecase ::– Actor & Use-case– Các mối quan hệ : Actor – Actor ; Actor-Use-case, - Use-case-Usace
•• ActorActor xácxác địnhđịnh mộtmột bộbộ vaivai tròtrò màmà ngườingười hoặchoặc vậtvật sẽsẽ đóngđóngvaivai khikhi tươngtương táctác vớivới hệhệ thốngthống phầnphần mềmmềmvaivai khikhi tươngtương táctác vớivới hệhệ thốngthống phầnphần mềmmềm– Actor nằm ngoài phạm vi của hệ thống– Chỉ quan tâm các thông điệp mà actor gửi hay nhận– Không quan tâm cấu trúc bên trong của actorKhông quan tâm cấu trúc bên trong của actor
•• PhânPhân loạiloại actoractor– Chủ yếu / Thứ yếu
Tí h / Th độ
8686Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
– Tích cực / Thụ động
Nhận diện các ACTORNhận diện các ACTORậ ệậ ệ
•• TrảTrả lờilời mộtmột sốsố câucâu hỏihỏi nhưnhư– Ai là người sử dụng chức năng chính của hệ thống ?– Ai cần sự hỗ trợ từ hệ thống để thực hiện công việc
thường nhật của họ ?thường nhật của họ ?– Ai phải thực hiện công việc bảo dưỡng, quản trị và giữ
cho hệ thống hoạt động ?ệ g ạ ộ g– Hệ thống sẽ kiểm soát thiết bị phần cứng nào ?– Hệ thống đang xây dựng cần tương tác với những hệ
ốthống khác hay không ?– Ai hoặc vật thể nào quan tâm đến hay chịu ảnh hưởng
bởi kết quả mà hệ thống phần mềm tạo ra ?
8787Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
bởi kết quả mà hệ thống phần mềm tạo ra ?
Biểu diễn ACTOR trong UMLBiểu diễn ACTOR trong UMLgg
•• ActorActor đượcđược biểubiểu diễndiễn bằngbằng kýký hiệuhiệu hìnhhình ngườingười
A tA t đđ làlà ộtột lớlớ ( l )( l ) óó t tt t làlàTên Actor
•• ActorActor đượcđược xemxem làlà mộtmột lớplớp (class)(class) cócó stereotypestereotype làlà<<actor>><<actor>>
•• GiữaGiữa cáccác actoractor cócó thểthể cócó quanquan hệhệ tổngtổng quáquá hoáhoáGiữaGiữa cáccác actoractor cócó thểthể cócó quanquan hệhệ tổngtổng quáquá hoáhoá– Ví dụ: Sinh viên, giảng viên và khách đều là độc giả của hệ thống
quản lý thư viện: độc giả là actor tổng quát hóa của 2 actor sinh viênvà giảng viênvà giảng viên
•• VíVí dụdụ:: mộtmột hệhệ thốngthống đăngđăng kýký mônmôn họchọc trongtrongtrườngtrường đạiđại họchọc
8888Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
gg ạạ ọọ
Các Actor trong hệ thống đăng ký môn họcCác Actor trong hệ thống đăng ký môn họcg ệ g g ý ọg ệ g g ý ọ
Sinh viên Phòng đào tạoS ê
Hệ thống đăng Hệ thống đăng ký ô hký ô hký môn họcký môn học
Giảng viên Hệ thống quản lý học phí
8989Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Phòng tài vụ
Khái niệm UseKhái niệm Use--casecaseệệ
•• UseUse--casecase biểubiểu diễndiễn mộtmột chứcchức năngnăng củacủa hệhệ thốngthống phầnphầnmềmmềmmềmmềm
•• UseUse--casecase đượcđược biểubiểu diễndiễn bằngbằng mộtmột chuỗichuỗi cáccác thôngthông điệpđiệptraotrao đổiđổi bênbên trongtrong hệhệ thốngthống vàvà mộtmột hoặchoặc mộtmột sốsố thôngthôngệệ ổổ ớớđiệpđiệp traotrao đổiđổi vớivới actoractor
•• MộtMột sốsố quyquy ướcướcUse-case luôn luôn được bắt đầu bằng thông điệp đến từ– Use-case luôn luôn được bắt đầu bằng thông điệp đến từactor
– Use-case phải hoàn tất: chuỗi thông điệp phải kết thúcbằ kết ả thểbằng kết quả cụ thể.
•• LỗiLỗi thườngthường gặpgặp:: chiachia nhỏnhỏ useuse--casecase trởtrở thànhthành nhữngnhững chứcchứcnăngnăng vụnvụn vặtvặt
9090Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Khái niệm UseKhái niệm Use--casecaseệệ
•• UseUse--casecase đượcđược biểubiểu diễndiễn bằngbằng hìnhhình ellipseellipse::
Tên UseTên Use--casecase
•• ĐiểmĐiểm mởmở rộngrộng làlà mộtmột vịvị trítrí trongtrong useuse--casecase màmà tạitại đóđó cócóthểthể chènchèn chuỗichuỗi sựsự kiệnkiện củacủa mộtmột useuse--casecase kháckhác
Tên UseTên Use casecase
thểthể chènchèn chuỗichuỗi sựsự kiệnkiện củacủa mộtmột useuse casecase kháckhác•• UseUse--casecase cócó thểthể chứachứa điềuđiều kiệnkiện rẽrẽ nhánh,nhánh, xửxử lýlý lỗi,lỗi, ngoạingoại
lệlệ......•• MinhMinh dụdụ củacủa useuse--casecase làlà kịchkịch bảnbản (scenario)(scenario):: miêumiêu tảtả cụcụ
thểthể trìnhtrình tựtự cáccác sựsự kiệnkiện xảyxảy rara khikhi UseUse--casecase đượcđược thựcthựchiệnhiện
9191Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
hiệnhiện..
Tìm kiếm UseTìm kiếm Use--casecase
•• TrảTrả lờilời mộtmột sốsố câucâu hỏihỏi nhưnhư– Actor yêu cầu chức năng gì của hệ thống ?– Actor cần phải đọc, tạo, xoá, sửa đổi hoặc lưu trữ thông tin nào đó
của hệ thống không ?– Actor cần thiết phải được cảnh báo về những sự kiện trong hệ
thống, hay actor cần phải báo hiệu cho hệ thống về vấn đề nào đókhông ?
– Hệ thống có thể hỗ trợ một số công việc thường nhật của actor nàođó hay không ?
•• MộtMột sốsố câucâu hỏihỏi kháckhác cầncần chúchú ýý•• MộtMột sốsố câucâu hỏihỏi kháckhác cầncần chúchú ýý– Hệ thống cần dữ liệu input/ouput nào ? Dữ liệu đó đến từ đâu ?– Những khó khăn nào liên quan đến hiện thực của hệ thống hiện tại
(chẳng hạn hệ thống q ản lý bằng giấ tờ nên được tha thế bằng hệ
9292Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
(chẳng hạn hệ thống quản lý bằng giấy tờ nên được thay thế bằng hệthống quản lý trên máy tính) ?
Các quan hệ của UseCác quan hệ của Use--casecaseq ệq ệ
•• SauSau khikhi xácxác địnhđịnh cáccác ActorActor vàvà UseUse--casecase thìthì cáccác quanquan hệhệ sẽsẽếế ậậ ểể àà ỉỉ ồồđượcđược thiếtthiết lậplập đểđể hoànhoàn chỉnhchỉnh lượclược đồđồ UseUse--casecase
•• GiữaGiữa useuse--casecase vàvà actoractor thườngthường cócó quanquan hệhệ liênliên kếtkếtUse-case được Actor nào kích hoạt– Use-case được Actor nào kích hoạt
•• GiữaGiữa cáccác useuse--casecase cũngcũng cócó quanquan hệhệ liênliên kếtkết hoặchoặc tổngtổngquátquát hoáhoá– Quan hệ liên kết: extent , incluse– Quan hệ thổng quát hóa
•• VíVí dụdụ:: mộtmột hệhệ thốngthống đăngđăng kýký mônmôn họchọc theotheo tíntín chỉchỉ trongtrong•• VíVí dụdụ:: mộtmột hệhệ thốngthống đăngđăng kýký mônmôn họchọc theotheo tíntín chỉchỉ trongtrongtrườngtrường đạiđại họchọc
9393Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Ví dụ một UseVí dụ một Use--case đơn giảncase đơn giảnụ ộụ ộ gg
Phòng Đào TạoSinh Viên Q ả ý ô
<<communicate>>
Phòng Đào TạoSinh ViênĐăng Ký Học
Quản lý Môn Học
Đăng ký dạy <<extend>>
Giả Viê
Quản lý Sinh Viên Thêm Sinh Viên Mới
9494Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Giảng Viên
Quan hệ liên kếtQuan hệ liên kếtQ ệQ ệ
•• QuanQuan hệhệ liênliên kếtkết chỉchỉ rara mộtmột quanquan hệhệ cócó ýý nghĩanghĩa giữagiữa haihai bênbênTrong thực tế: hành khách với lái xe sinh viên với giáo viên giảng viên với– Trong thực tế: hành khách với lái xe, sinh viên với giáo viên, giảng viên vớimôn học …
•• MộtMột sốsố tínhtính chấtchất liênliên quanquan– Tên của liên kếtê của ê ết– Một chiều hay 2 chiều– Bậc: số lượng thực thể tham gia vào liên kết tại mỗi bên
•• UMLUML biểubiểu diễndiễn liênliên kếtkết nhưnhư làlà mộtmột đoạnđoạn thẳngthẳng (hai(hai chiều)chiều) hoặchoặc mũimũiộộ ạạ gg (( )) ặặtêntên (một(một chiều)chiều)
•• CóCó thểthể ápáp dụngdụng stereotypestereotype::
<<Stereotype>><<Stereotype>> <<Stereotype>><<Stereotype>>
– <<include>>– <<extend>>– <<communicate>>
9595Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
– ...
Quan hệ liên kết giữa Actor và UseQuan hệ liên kết giữa Actor và Use--casecaseQ ệ gQ ệ g
•• LiênLiên kếtkết làlà quanquan hệhệ duyduy hấthất giữagiữa actoractor && UseUse--casecase•• LiênLiên kếkế cócó thểthể làlà 22 chiềuchiều hayhay 11 chiềuchiều
– actor kích hoạt use-case và nhận kết quả về: liên kết 2 chiềuactor kích hoạt use-case không quan tâm kết quả về: liên kết 1 chiều– actor kích hoạt use-case, không quan tâm kết quả về: liên kết 1 chiều
•• QuanQuan hệhệ liênliên kếtkết phổphổ biếnbiến giữagiữa ActorActor && UseUse--casecase làlà giaogiaotiếptiếp:: stereotypestereotype làlà <<communicate>><<communicate>> dùngdùng liênliên kếtkết giữagiữa actoractor vàvà
àà óó ííuseuse casecase màmà nónó kíchkích hoạthoạt
1 * <<communicate>>
Người bán hàngĐặt hàng
1 * Đăng ký dạy
9696Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Giảng viên
Quan hệ gộp giữa 2 UseQuan hệ gộp giữa 2 Use--casecaseQ ệ gộp gQ ệ gộp g
•• DùngDùng đểđể liênliên kếtkết 22 UseUse--casecase:: cócó stereotypestereotype làlà <<include>><<include>>
•• TrongTrong UseUse--casecase nguồnnguồn cócó điểmđiểm mởmở rộngrộng màmà tạitại đóđó bắtbắtbuộcbuộc phảiphải chènchèn UseUse--casecase đíchđích vàovào..
Tại điểm mở rộng diễn tiến của use-case nguồn tạm thời ngừng lại– Tại điểm mở rộng, diễn tiến của use-case nguồn tạm thời ngừng lạiđể chuyển sang diễn tiến của use-case đích
– Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại tiếp tục
<<include>>
Đăng nhập
<<include>>
Tìm kiếm
9797Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quan hệ mở rộng giữa 2 UseQuan hệ mở rộng giữa 2 Use--casecaseQ ệ ộ g gQ ệ ộ g g
•• DùngDùng đểđể liênliên kếtkết 22 UseUse--casecase:: cócó stereotypestereotype làlà <<extend>><<extend>>
•• TrongTrong useuse--casecase nguồnnguồn cócó mộtmột điểmđiểm mởmở rộngrộng màmà tạitại đóđó cócóthểthể (hoặc(hoặc không)không) chènchèn useuse--casecase đíchđích vàovào tùytùy thuộcthuộc vàovàođiềuđiều kiệnkiện rẽrẽ nhánhnhánh hoặchoặc tươngtương táctác từtừ actoractorđiềuđiều kiệnkiện rẽrẽ nhánhnhánh hoặchoặc tươngtương táctác từtừ actoractor– Tại điểm mở rộng, nếu được mở rộng thì diễn tiến của use-case nguồn
tạm thời ngừng lại để chuyển sang diễn tiến của use-case đíchKhi kết thú đí h diễ tiế ủ ồ l i tiế t– Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại tiếp tục
<<Extend>>
Đăng ký đặt chỗ(nếu tìm thấy)
<<Extend>>
Tìm kiếm
9898Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quan hệ tổng quát hóaQuan hệ tổng quát hóaQ ệ g qQ ệ g q
•• LàLà mốimối quanquan hệhệ giữagiữa cáccác đốiđối tượngtượng cùngcùng nhómnhóm tạotạo nênnênmộtmột đốiđối tượngtượng mangmang nhữngnhững tínhtính chấtchất ch ngch ng củacủa cáccác đốiđốimộtmột đốiđối tượngtượng mangmang nhữngnhững tínhtính chấtchất chungchung củacủa cáccác đốiđốitượngtượng kiakia
•• QuanQuan hệhệ thốngthống quátquát hóahóa giữagiữa cáccác ActorActor:: nhiềunhiều actoractor cócóộộ ốố òò ìì ổổ áá óóchungchung mộtmột sốsố vaivai tròtrò -->> hìnhhình thanthan22hh actoractor tổngtổng quátquát hóahóa
mangmang vaivai tròtrò chungchung đóđó..– Ví dụ: sinh viên, giáo viên đều có chung use-case login và đều là user
ố ổcủa hệ thống -> tạo nên actor user là tổng quát hóa của actor sinhviên và actor giáo viên
•• QuanQuan hệhệ thổngthổng quátquát hóahóa giũagiũa cáccác UseUse--casecase:: khikhi cócó nhiềunhiềuàà ờờ ểể ộộ ừừuseuse--casecase làlà trườngtrường hợphợp cụcụ thểthể mộtmột useuse--casecase trừutrừu tượngtượng
– Vì dụ: Use-case login của sinh viên , giáo viên có thể được thực hiệntheo cơ chế khác nhau nhưng cùng mang chung ý nghĩa là đăng nhập
là á t ờ h thể ủ U t ừ t LOGIN
9999Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
là các trường hợp cụ thể của Use-case trừu trương LOGIN
Xây dựng mô hình UseXây dựng mô hình Use--casecasey ự gy ự g
•• CácCác yêuyêu cầucầu củacủa phầnphần mềmmềm đượcđược mômô tảtả trongtrong mômô hìnhhình useuse--casecaseMôMô hìnhhình useuse casecase baobao gồmgồm lượclược đồđồ useuse casecase vàvà (có(có thể)thể) mộtmột sốsố•• MôMô hìnhhình useuse--casecase baobao gồmgồm lượclược đồđồ useuse--casecase vàvà (có(có thể)thể) mộtmột sốsốpacketpacket (gom(gom mộtmột sốsố useuse--casecase thànhthành mộtmột bộbộ chứcchức năngnăng concon củacủa hệhệ thống)thống)
•• PhươngPhương pháppháp thựcthực hiệnhiện::Xác định các actor và use-case của hệ thống– Xác định các actor và use-case của hệ thống
– Xác lập các quan hệ giữa các đối tượng này• Quan hệ liên kết giữa actor và use-case: một chiều hoặc hai chiều, thường có
stereotype là <<communicate>>ế• Quan hệ mở rộng hay gộp giữa 2 use-case: quan hệ liên kết với stereotype
<<extend>> hay <<include>>• Quan hệ tổng quát hoá (generalization) giữa các actor: nhiều actor có vai trò của một
actor trừu tượngh ổ h i hiề l h hể• Quan hệ tổng quát hoá giữa các use-case: nhiều use-case là trường hợp cụ thể của một
use-case trừu tượng– Trình bày thành lược đồ use-case theo chuẩn UML– Có thể xác định các packet
100100Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
ị p
Xây dựng mô hình UseXây dựng mô hình Use--case case –– VÍ DỤVÍ DỤy ự gy ự g ỤỤ
Prints timetable Makes timetablefee summary
Financeprint request<<communicate>> timetable command
<<communicate>>Student
Registers courses
People Removes students
Administration
t dManages course<<include>>
Lecturer Reads courses
<<extend>>
Manages lecturers<<include>>
<<include>>
Adds students
Manages students
<<extend>>g
Login
<<include>>
<<include>>
<<include>>
<<include>>
101101Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Undertakescourse
Xây dựng mô hình UseXây dựng mô hình Use--case case –– VÍ DỤVÍ DỤy ự gy ự g ỤỤ<<communicate>>
Forwards
<<extend>>
Removes mailbox<<communicate>>Subcriber
AdministratorViews mail
<<extend>>
Replies
<<extend>>
<<include>>
<<extend>>
Replies
<<communicate>> <<include>>
Adds mailboxLogin
<<include>>
102102Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Xây dựng mô hình UseXây dựng mô hình Use--case case –– VÍ DỤVÍ DỤy ự gy ự g ỤỤ
models
<<extend>>
importsmodels
initializes
import command<<communicate>>
i t
model command<<communicate>>
run command
exports sets appearanceexport command
<<communicate>>
d<<communicate>>
saves model<<extend>>
toggles lightViewersave command
close command<<communicate>>
<<extend>>toggles mode
close command
103103Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
exits sets eye
Mô hình phân tích Mô hình phân tích –– Phân tích yêu cầuPhân tích yêu cầupp yy
•• MôMô hìnhhình nghiệpnghiệp vụvụ biểubiểu diễndiễn cáccác chứcchức năngnăngphầnphần mềmmềm cầncần xâyxây dựngdựng dướidưới dạngdạng cáccác useusephầnphần mềmmềm cầncần xâyxây dựngdựng dướidưới dạngdạng cáccác useuse--casecase
•• MôMô hìnhhình phânphân tíchtích sẽsẽ tìmtìm kiếmkiếm cáccác đốiđốitượngtượng “sống”“sống” trongtrong ngữngữ cảnhcảnh củacủa phầnphần mềmmềm
Đối tượng/lớp- quan hệ
tượngtượng sốngsống trongtrong ngữngữ cảnhcảnh củacủa phầnphần mềmmềm•• CácCác đốiđối tượngtượng sẽsẽ tươngtương táctác vớivới nhaunhau đểđể tạotạo
nênnên cáccác chứcchức năngnăng mômô tảtả bởibởi useuse--casecaseLượLượ đồđồ ClCl hâhâ tí htí h diễdiễ tảtả ấấ t út ú ốiối•• LượcLược đồđồ ClassClass phânphân tíchtích diễndiễn tảtả cấucấu trúc,trúc, mốimốiquanquan hệhệ giữagiữa cáccác đồiđồi tượng/lớptượng/lớp trongtrong hệhệ thốngthống
•• ChưaChưa quanquan tâmtâm đếnđến hànhhành vivi cụcụ thểthể vàvà nhiệmnhiệmhihi tiếttiết ủủ húhú tt ữữ ả hả h ủủ hệhệvụvụ chichi tiếttiết củacủa chúngchúng trongtrong ngữngữ cảnhcảnh củacủa hệhệ
thốngthống•• NguyênNguyên tắctắc:: mômô hìnhhình phânphân tíchtích phảiphải độcđộc lậplập
ớiới // ôô ữữ lậlậ t ì ht ì h ôô háthát t iểt iể
104104Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
vớivới o/s,o/s, ngônngôn ngữngữ lậplập trình,trình, côngcông cụcụ phátphát triểntriển
Xây dựng mô hình phân tíchXây dựng mô hình phân tíchy ự g py ự g p
•• MôMô hìnhhình phânphân tíchtích đượcđược diễndiễn đạtđạt trongtrong UMLUML bằngbằng lượclược đồđồ lớplớp phânphântíchtích (Class(Class diagrame)diagrame)tíchtích (Class(Class diagrame)diagrame)
•• CácCác côngcông việcviệc xâyxây dựngdựng lượclược đồđồ phânphân tíchtích baobao gồmgồm– Tìm kiếm các đối tượng / lớp trong hệ thống
• Đối tượng / lớp thực thểĐối tượng / lớp thực thể• Đối tượng / lớp biên• Đối tượng / lớp control
– Xác định các thuộc tính của đối tượng / lớpị ộ ợ g p– Xác định các tác vụ của đối tượng / lớp– Nhận diện các lớp trừu tượng qua mối quan hệ thổng quát hóa– Xác lập các mối quan hệ giữa các lớp:
ổ• Tổng quát hoá (generalization)• Liên kết (association)• Bao gộp (aggregation)
BiểBiể diễndiễn thànhthành lượlượ đồđồ lớplớp phânphân tí htí h
105105Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
•• BiểuBiểu diễndiễn thànhthành lượclược đồđồ lớplớp phânphân tíchtích
Nhập diện đối tượng / lớpNhập diện đối tượng / lớpập ệ ợ g pập ệ ợ g p
•• DựaDựa vàovào đặcđặc tảtả củacủa từngtừng useuse--casecase đểđể tìmtìm kiếmkiếm cáccác đốiđốitượngtượng
•• CácCác đốiđối tượngtượng thườngthường xuấtxuất hiệnhiện trongtrong cáccác danhdanh từtừ hayhaynhómnhóm danhdanh từtừnhómnhóm danhdanh từtừ
•• MộtMột sốsố lưulưu ýý– Không nên dùng đối tượng để biểu diễn một dữ liệu đơn (nên xem là
ốthuộc tính của đối tượng khác)– Đối tượng/lớp phải thực sự cần thiết cho sự hoạt động của hệ thống– Đối tượng/lớp >< bảng cơ sở dữ liệuợ g p g ệ– Đối tượng/lớp >< actor
106106Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nhận diện và biểu diễn đối tượng / lớpNhận diện và biểu diễn đối tượng / lớpậ ệ ợ g pậ ệ ợ g p
•• PhânPhân loạiloại đốiđối tượng/lớptượng/lớpố ể ể ễ ô ế ế ệ– Đối tượng thực thể (entity): biểu diễn các thông tin thiết yếu của hệ
thống, có thể được lưu trong cơ sở dữ liệu– Đối tượng biên (boundary): thực hiện chức năng giao tiếp với actor
Đối t điề khiể ( t l) điề khiể á đối t khá– Đối tượng điều khiển (control): điều khiển các đối tượng khác•• TrongTrong UML,UML, lớplớp đượcđược biểubiểu diễndiễn bằngbằng mộtmột hìnhhình chữchữ nhậtnhật
gồmgồm 33 phầnphần:: tên,tên, cáccác thuộcthuộc tínhtính vàvà cáccác táctác vụvụ•• CóCó thểthể ápáp dụngdụng stereotypestereotype chocho lớplớp:: <<entity>>,<<entity>>,
<<boundary>>,<<boundary>>, <<control>><<control>>......•• ĐốiĐối tượngtượng cũngcũng đượcđược biểubiểu diễndiễn bằngbằng hìnhhình chữchữ nhậtnhật•• ĐốiĐối tượngtượng cũngcũng đượcđược biểubiểu diễndiễn bằngbằng hìnhhình chữchữ nhật,nhật,
thôngthông thườngthường gồmgồm 22 phầnphần:: têntên đốiđối tượngtượng ++ têntên lớplớp (được(đượcgạchgạch chân),chân), giágiá trịtrị cáccác thuộcthuộc tínhtính (trạng(trạng tháithái củacủa đốiđốitượng)tượng)
107107Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
tượng)tượng)
Biểu diễn lớp / đối tượngBiểu diễn lớp / đối tượngp ợ gp ợ g
HTMLObjectj
# alignment: int
+ GetAlignment( ): int GetAlignment( ): int+ toHTML( ): String
HTMLDocument doc : HTMLDocument
- title: String alignment = MIDDLEtitle = “A document”
+ GetTitle( ): String+ toHTML( ): String
108108Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Đối tượng / lớp thực thểĐối tượng / lớp thực thểợ g p ựợ g p ự•• BiểuBiểu diễndiễn chocho cáccác thựcthực thểthể xuấtxuất hiệnhiện mộtmột cáchcách tựtự nhiênnhiên trongtrong
hệhệ thốngthốnghệhệ thốngthống•• ThôngThông tintin vềvề cáccác đốiđối tượngtượng thựcthực thểthể cócó thểthể phảiphải đượcđược lưulưu trữtrữ
lâulâu dàidài (database,(database, filefile......))TT UMLUML đđ áá ii•• TrongTrong UML,UML, đượcđược gángán stereotypestereotype <<entity>><<entity>>
•• DễDễ nhậnnhận diệndiện cáccác thuộcthuộc tínhtính củacủa chúngchúngVíVí dụdụ:: Messageụụ
• Đối với hệ thống đăng ký môn học hệ tínchỉ qua WEB, nhận diện các đối tượng thựcthể như: thông tin SV, thông tin GV, nhómlớp học đăng ký nhóm sổ tay sinh viên
# subject: String# sent: Date
g<<entity>>
lớp học, đăng ký nhóm, sổ tay sinh viên …• Đối với hệ thống mail, nhận diện các đốitượng thực thể như: hộp thư, thông điệpmail…
+ GetSubject( ): String+ toString( ): String
# content: String
109109Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
g( ) g
Đối tượng / lớp biênĐối tượng / lớp biênợ g pợ g p
•• ThựcThực hiệnhiện chứcchức năngnăng giaogiao tiếptiếp vớivới actoractorThườThườ hứhứ áá hầhầ tửtử h ặh ặ điềđiề khiểkhiể ii diệdiệ ườiười•• ThườngThường chứachứa cáccác phầnphần tửtử hoặchoặc điềuđiều khiểnkhiển giaogiao diệndiện ngườingười
dùngdùng (nút(nút nhấn,nhấn, hộphộp danhdanh sách,sách, tuỳtuỳ chọn,chọn, menumenu......))•• TrongTrong UML,UML, đượcđược gángán stereotypestereotype <<boundary>><<boundary>>•• KhóKhó nhậnnhận biếtbiết cáccác thuộcthuộc tínhtính vàvà táctác vụvụ trongtrong mômô hìnhhình phânphân tíchtích
VíVí dụdụ:: MailViewụụ
•Đối với hệ thống đăng ký môn học hệtín chỉ qua WEB, nhận diện các đốitượng biên như: RegisterForm
<<boundary>>
tượng biên như: RegisterForm,StudentForm…
• Đối với hệ thống mail, nhận diện các
110110Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
gđối tượng biên như: MailView,MailCompose...
Đối tượng / lớp điều khiểnĐối tượng / lớp điều khiểnợ g pợ g p
•• CóCó nhiệmnhiệm vụvụ điềuđiều khiểnkhiển cáccác lớplớpkháckhác hoặchoặc Commandkháckhác hoặchoặc
•• NhữngNhững lớplớp khôngkhông phảiphải làlà lớplớp thựcthựcthểthể vàvà lớplớp biênbiên
Command<<control>>
+ Execute( )+ Reexecute( )
•• TrongTrong UML,UML, đượcđược gángán stereotypestereotype<<control>><<control>>
•• LớpLớp biênbiên thườngthường cócó quanquan hệhệ liênliên
+ Reexecute( )+ Unexecute( )# Do( )
LớpLớp biênbiên thườngthường cócó quanquan hệhệ liênliênkếtkết hoặchoặc phụphụ thuộcthuộc vớivới cáccác lớplớpkháckhác
•• VíVí dụdụ::
PasteCommand<<control>>
+ Execute( )
BgCommand<<control>>
+ Execute( )•• VíVí dụdụ::•• ĐốiĐối tượngtượng biểubiểu diễndiễn mộtmột sốsố lệnhlệnh
thôngthông thườngthường nhưnhư cắt,cắt, dán,dán, thaythay đổiđổithôngthông sốsố nhìnnhìn trongtrong hiểnhiển thịthị đồđồ hoạhoạ
( )+ Reexecute( )+ Unexecute( )# Do( )
( )+ Reexecute( )+ Unexecute( )# Do( )
111111Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
thôngthông sốsố nhìnnhìn trongtrong hiểnhiển thịthị đồđồ hoạhoạ……
Nhận điện các thuộc tínhNhận điện các thuộc tínhậ ệ ộậ ệ ộ
•• DựaDựa vàovào đặcđặc tảtả củacủa từngtừng useuse--case,case, tìmtìm kiếmkiếm cáccác danhdanh từtừ hoặchoặchóhó d hd h từtừ liêliê đếđế đốiđối tượtượ đđ ététnhómnhóm danhdanh từtừ liênliên quanquan đếnđến đốiđối tượngtượng đangđang xétxét
•• TrảTrả lờilời câucâu hỏihỏi:: nhữngnhững thànhthành phầnphần nàonào cấucấu thànhthành đốiđối tượngtượngđangđang xétxét ??gg– Lưu ý: cùng một đối tượng trong các ngữ cảnh khác nhau chúng ta
có thể tìm được các thuộc tính khác nhau•• NênNên xácxác địnhđịnh (tuy(tuy nhiênnhiên khôngkhông bắtbắt buộc)buộc) trongtrong mômô hìnhhình phânphânNênNên xácxác địnhđịnh (tuy(tuy nhiênnhiên khôngkhông bắtbắt buộc)buộc) trongtrong mômô hìnhhình phânphân
tíchtích– Kiểu của thuộc tính: một số kiểu cơ bản– Bậc của thuộc tính: số ít hoặc số nhiều– Bậc của thuộc tính: số ít hoặc số nhiều– Visibility của thuộc tính: mức độ cho phép truy xuất thuộc tính từ bên ngoài
•• UMLUML:: thuộcthuộc tínhtính đượcđược miêumiêu tảtả tườngtường minhminh hoặchoặc thôngthông quaquaquanquan hệhệ vớivới cáccác lớplớp kháckhác
112112Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
quanquan hệhệ vớivới cáccác lớplớp kháckhác
Xác định mức độ truy cập của thuộc tínhXác định mức độ truy cập của thuộc tínhị ộ y ập ộị ộ y ập ộ
•• MứcMức độđộ truytruy cậpcập vàvà phạmphạm vivi màmà thuộcthuộc tínhtính đóđó cócó thểthể đượcđượcảả ếế ếếthamtham khảokhảo đếnđến trựctrực tiếptiếp
•• UMLUML địnhđịnh nghĩanghĩa 33 mứcmức độđộ truytruy xuấtxuất thuộcthuộc tínhtính (visibility)(visibility)public (+): có thể truy xuất thuộc tính từ tất cả các vị trí khác– public (+): có thể truy xuất thuộc tính từ tất cả các vị trí khácnhau
– protected (#): bản thân lớp đang xét và các lớp con của nó cóể ấ ộthể truy xuất thuộc tính
– private (-): chỉ có lớp đang xét có thể truy xuất thuộc tính•• ThôngThông thườngthường nênnên đặtđặt mứcmức độđộ truytruy xuấtxuất thuộcthuộc tínhtính làlà•• ThôngThông thườngthường nênnên đặtđặt mứcmức độđộ truytruy xuấtxuất thuộcthuộc tínhtính làlà
privateprivate hoặchoặc protectedprotected (cho(cho cáccác lớplớp cơcơ sở),sở), khôngkhông nênnênlàlà publicpublic..
113113Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
•• ThuộcThuộc tínhtính nênnên đượcđược truytruy xuấtxuất thôngthông quaqua táctác vụvụ get/setget/set
Ví dụ về nhận diện các thuộc tínhVí dụ về nhận diện các thuộc tínhụ ậ ệ ộụ ậ ệ ộ
•• HệHệ thốngthống đăngđăng kýký mônmônhọchọc hệhệ tíntín chỉchỉ quaqua WEBWEBhọchọc hệhệ tíntín chỉchỉ quaqua WEBWEB --NhậnNhận diệndiện cáccác thuộcthuộc tínhtínhchocho cáccác đốiđối tượngtượng::StudentInfoStudentInfo LecturerInfoLecturerInfo
StudentInfo<<entity>>
- name: String
LecturerInfo<<entity>>
- name: StringStudentInfo,StudentInfo, LecturerInfoLecturerInfo•• ChúChú ýý cáccác mứcmức độđộ truytruy
cậpcập củacủa cáccác thuộcthuộc tínhtính•• CácCác táctác vụvụ phátphát sinhsinh
name: String- code: Long- dateOfBirth: Date- addr: String
Y D
- code: String- dateOfBirth: String- addr: String- degree•• CácCác táctác vụvụ phátphát sinhsinh
trongtrong khikhi nhậnnhận diệndiện cáccácthuộcthuộc tínhtính nhưnhư Get/SetGet/Set
- acaYear: Date- department- home: String- socialAid
degree - title: String- division - healthsocialAid- experience: Date
+ GetN ame( ): String+ GetCode( ): Long
+ GetN ame( ): String+ GetCode( ): String
114114Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Ví dụ về nhận diện các thuộc tínhVí dụ về nhận diện các thuộc tínhụ ậ ệ ộụ ậ ệ ộ
•• HệHệ thốngthống đăngđăng kýkýmônmôn họchọc hệhệ tíntín chỉchỉmônmôn họchọc hệhệ tíntín chỉchỉquaqua WEBWEB
•• NhậnNhận diệndiện cáccác thuộcthuộctínhtính chocho cáccác đốiđối
CourseOfferring<<entity>>
Catalog<<entity>>
tínhtính chocho cáccác đốiđốitượngtượng::
CourseOffering,CourseOffering,
- courseN ame: String- courseCode: String- offering: int
i
- acaYear: Date- semester
CatalogCatalog- session- credit: int- prerequisite
115115Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nhận diện các tác vụNhận diện các tác vụậ ệ ụậ ệ ụ
•• DựaDựa vàovào đặcđặc tảtả củacủa từngtừng useuse--case,case, tìmtìm kiếmkiếm cáccác độngđộng từtừặặ óó ộộ ừừ êê ếế ốố ééhoặchoặc nhómnhóm độngđộng từtừ liênliên quanquan đếnđến đốiđối tượngtượng đangđang xétxét
•• ChúChú ýý xemxem đốiđối tượngtượng đượcđược tạotạo rara vàvà bịbị huỷhuỷ bỏbỏ điđi nhưnhư thếthếnàonào ?? TrongTrong thờithời giangian đóđó nónó gửi/nhậngửi/nhận thôngthông điệpđiệp rara saosao ??nàonào ?? TrongTrong thờithời giangian đóđó nónó gửi/nhậngửi/nhận thôngthông điệpđiệp rara saosao ??
•• CácCác đốiđối tượngtượng biênbiên cócó cáccác táctác vụvụ nhậnnhận lệnhlệnh từtừ actoractor..•• XemXem xétxét mứcmức độđộ truytruy xuấtxuất củacủa táctác vụvụ tươngtương tựtự nhưnhư đốiđối vớivớiộộ yy ụụ gg ựự
cáccác thuộcthuộc tínhtính;; cáccác táctác vụvụ thườngthường cócó visibilityvisibility làlà ++ hoặchoặc ##•• MộtMột sốsố táctác vụvụ khôngkhông xuấtxuất hiệnhiện mộtmột cáchcách tựtự nhiênnhiên trongtrong
mômô hìnhhình phânphân tíchtích mômô hìnhhình thiếtthiết kếkế sẽsẽ nghiênnghiên cứucứu kỹkỹmômô hìnhhình phânphân tíchtích mômô hìnhhình thiếtthiết kếkế sẽsẽ nghiênnghiên cứucứu kỹkỹtráchtrách nhiệmnhiệm vàvà hànhhành vivi củacủa từngtừng đốiđối tượngtượng
116116Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nhận diện lớp cơ sởNhận diện lớp cơ sởậ ệ pậ ệ p
•• LớpLớp cơcơ sởsở (base(base class)class) đượcđược nhậnnhận diệndiện sausau khikhi đãđã nhậnnhậnệệ áá ớớ ểểdiệndiện cáccác lớplớp cụcụ thểthể
•• SựSự xuấtxuất hiệnhiện củacủa lớplớp cơcơ sởsở làmlàm chocho mômô hìnhhình phânphân tíchtích cócótínhtính dùngdùng lạilại caocao (reusability)(reusability) vàvà dễdễ mởmở rộngrộng (scalability)(scalability)tínhtính dùngdùng lạilại caocao (reusability)(reusability) vàvà dễdễ mởmở rộngrộng (scalability)(scalability)
•• UMLUML hỗhỗ trợtrợ quanquan hệhệ tổngtổng quátquát hoáhoá (generalization)(generalization)•• LớpLớp cơcơ sởsở trừutrừu tượngtượng (không(không thểthể cụcụ thểthể hoáhoá tạotạo rara đốiđốipp ợ gợ g ( g( g ụụ ạạ
tượng)tượng) cócó têntên inin nghiêngnghiêng•• LớpLớp cơcơ sởsở đượcđược hìnhhình thànhthành bằngbằng cáchcách xácxác lậplập cáccác quanquan hệhệ
tổngtổng quátquát hóahóa củacủa cáccác lớplớp cụcụ thểthể cócó chungchung mộtmột sốsố thuộcthuộctổngtổng quátquát hóahóa củacủa cáccác lớplớp cụcụ thểthể cócó chungchung mộtmột sốsố thuộcthuộctínhtính và/hayvà/hay mộtmột sốsố táctác vụvụ
117117Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nhận diện lớp cơ sở (tt)Nhận diện lớp cơ sở (tt)ậ ệ p ( )ậ ệ p ( )
•• ĐốiĐối vớivới cáccác đốiđối tượng/lớptượng/lớp thựcthực thể,thể, tìmtìm cáccác thuộcthuộc tínhtínhểể ìì àà ớớ ởởchungchung đểđể hìnhhình thànhthành lớplớp cơcơ sởsở
•• VíVí dụdụTrong hệ thống quản lý thư viện qua WEB: các đối tượng Book– Trong hệ thống quản lý thư viện qua WEB: các đối tượng Book,Magazine có một số thuộc tính chung � hình thành lớp LibraryItem
– Đối với hệ thống đăng ký môn học tín chỉ qua WEB: lớp PeopleInfolà lớp cơ sở của StudentInfo và LecturerInfolà lớp cơ sở của StudentInfo và LecturerInfo
– Chương trình vẽ bề mặt địa hình: lớp MapCurve là lớp cơ sở củađường đồng mức Isoquant và đứt gãy Fracture
GiữGiữ lớlớ ơơ ởở àà áá lớlớ thểthể óó ốiối hệhệ thổthổ•• GiữaGiữa lớplớp cơcơ sởsở vàvà cáccác lớplớp cụcụ thểthể cócó mốimối quanquan hệhệ thổngthổngquátquát hóahóa cócó thểthể biểubiểu diễndiễn đượcđược trongtrong UMLUML
118118Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Biểu diễn lớp cơ sở và quan hệ tổng quát hóaBiểu diễn lớp cơ sở và quan hệ tổng quát hóap q ệ g qp q ệ g q
•• UMLUML địnhđịnh nghĩanghĩa quanquan hệhệ tổngtổng quátquát hoáhoáữữ ộộ ớớ ổổ áá ớớ ộộ ớớgiữagiữa mộtmột lớplớp tổngtổng quáquá hơnhơn vớivới mộtmột lớplớp
cụcụ thểthể hơnhơn:: lớplớp cụcụ thểthể hơnhơn cócó tấttất cảcảthuộcthuộc tính,tính, táctác vụvụ vàvà quanquan hệhệ củacủa lớplớp
MapCurve
ộộ ,, ụụ qq ệệ ppkiakia ++ nhữngnhững thuộcthuộc tính/táctính/tác vụvụ riêngriêngcủacủa nónóKýKý hiệhiệ ũiũi têtê óó đầđầ làlà ộtột tt
Isoquant•• KýKý hiệuhiệu:: mũimũi têntên cócó đầuđầu làlà mộtmột tamtam
giácgiác nhỏnhỏ•• LớpLớp tổngtổng quátquát hơnhơn nằmnằm vềvề phíaphía mũimũiFracture LớpLớp tổngtổng quátquát hơnhơn nằmnằm vềvề phíaphía mũimũi
têntên
119119Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Ví dụ về nhận diện lớp cơ sởVí dụ về nhận diện lớp cơ sởụ ậ ệ pụ ậ ệ p
VíVí dụdụ::T ongT ong hệhệ thốngthống # name: String•• TrongTrong hệhệ thốngthốngđăngđăng kýký mônmôn họchọctíntín chỉchỉ quaqua WEB,WEB,
# name: String# code: String# dateOfBirth: Date# addr: String
lớplớp PeopleInfoPeopleInfo làlàtổngtổng quátquát hoáhoácủacủa StudentInfoStudentInfo StudentInfo LecturerInfocủacủa StudentInfoStudentInfovàvà LecturerInfoLecturerInfo
StudentInfo<<entity>>
- acaYear: Datedepartment
LecturerInfo<<entity>>
- degree title: String- department
- home: String- socialAid
- title: String- division - health- experience: Date
120120Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Nhận diện các mối quan hệNhận diện các mối quan hệậ ệ q ệậ ệ q ệ
•• SauSau khikhi xácxác địnhđịnh cáccác lớp/đốilớp/đối tươngtương kểkể cảcả cáccác đốiđối tượngtượng cơcơởở áá ệệ ữữ áá ớớ ầầ áá ậậsở,sở, cáccác quanquan hệhệ giữagiữa cáccác lớplớp cầncần đượcđược xácxác lậplập
•• TrongTrong mômô hìnhhình phânphân tíchtích cáccác đốiđối tượng/lớptượng/lớp cócó quanquan hệhệ vớivớinhaunhaunhaunhau
•• MộtMột sốsố quanquan hệhệ màmà UMLUML hỗhỗ trợtrợ– Tổng quát hoá (generalization)– Liên kết (association)– Bao gộp (aggregation)
•• CácCác quanquan hệhệ kháckhác đượcđược ápáp dụngdụng chocho mômô hìnhhình thiếtthiết kếkế•• CácCác quanquan hệhệ kháckhác đượcđược ápáp dụngdụng chocho mômô hìnhhình thiếtthiết kếkế– Phụ thuộc (dependency)– Cụ thể hoá (realization)
121121Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quan hệ liên kếtQuan hệ liên kếtQ ệQ ệ
•• QuanQuan hệhệ liênliên kếtkết làlà mốimối quanquan hệhệ giữagiữa 22 đốiđối tượng/lớptượng/lớp•• VềVề ýý nghĩanghĩa vàvà kýký hiệuhiệu giốnggiống nhưnhư quanquan hệhệ liênliên kếtkết trongtrong
mômô hìnhhình nghiệpnghiệp vụvụ•• ÁpÁp dụngdụng chocho 22 lớplớp cócó mốimối tươngtương quanquan mangmang ýý nghĩanghĩa nhấtnhất•• ÁpÁp dụngdụng chocho 22 lớplớp cócó mốimối tươngtương quanquan mangmang ýý nghĩanghĩa nhấtnhấtđịnhđịnh
•• ChúChú ýý ghighi rõrõ (nếu(nếu cócó thểthể được)được)ýý gg (( ợ )ợ )– Bậc và tên vai trò của mỗi lớp trong quan hệ– Tên của chính quan hệ liên kết
DựaDựa vàovào mômô hìnhhình nhgiệpnhgiệp vụvụ xácxác địnhđịnh cáccác mốimối quanquan hệhệ liênliên•• DựaDựa vàovào mômô hìnhhình nhgiệpnhgiệp vụvụ xácxác địnhđịnh cáccác mốimối quanquan hệhệ liênliênkếtkết
122122Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Ví dụ Ví dụ -- mối quan hệ liên kếtmối quan hệ liên kếtụụ q ệq ệ
VíVí dụdụ::St d tI f Registrationd h Lớp Lớp RegistrationRegistration
liên kết với lớpliên kết với lớpStudentInfoStudentInfo
StudentInfo<<entity>>
Registration<<entity>>
- acaYear: Date- semester
students40..80
has
StudentInfoStudentInfoLecturerInfoLecturerInfovà và reg0..1
CourseOfferingCourseOfferingLecturerInfo<<entity>> CourseOffering
offeringlecturer
0..1<<entity>> CourseOffering
<<entity>>
123123Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quan hệ bao gộpQuan hệ bao gộpQ ệ gộpQ ệ gộp
•• UMLUML địnhđịnh nghĩanghĩa quanquan hệhệ baobao gộpgộp làlà trườngtrường hợphợp đặcđặc biệtbiệtủủ ệệ êê ếế àà ộộ ầầ ốố êê ếế ởởcủacủa quanquan hệhệ liênliên kết,kết, khikhi màmà mộtmột đầuđầu nốinối liênliên kếtkết trởtrở
thànhthành đầuđầu nốinối baobao gộpgộp (aggregation)(aggregation)•• LớpLớp ởở đầuđầu nốinối baobao gộpgộp sẽsẽ baobao hàmhàm lớplớp kiakia•• LớpLớp ởở đầuđầu nốinối baobao gộpgộp sẽsẽ baobao hàmhàm lớplớp kiakia•• KýKý hiệuhiệu củacủa đầuđầu nốinối baobao gộpgộp làlà mộtmột hìnhhình thoithoi tôtô hoặchoặc
khôngkhông tôtô đenđen•• CóCó haihai dạngdạng baobao gộpgộp
– Chia xẻ (shared): chia xẻ giữa các bao gộp khác nhauHoàn toàn (composite): sở hữu đầy đủ– Hoàn toàn (composite): sở hữu đầy đủ
•• XácXác lậplập cáccác mốimối quanquan hệhệ baobao gộmgộm vàvà biểubiểu diễndiễn chúngchúng lênlênlượclược đồđồ lớplớp
124124Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Quan hệ bao gộp Quan hệ bao gộp –– ví dụví dụQ ệ gộpQ ệ gộp ụụ
•• ĐốiĐối vớivới hệhệ thốngthống đăngđăng kýký mônmôn họchọc tíntín chỉchỉ quaqua WEB,WEB, lớplớpCatalogCatalog baobao gộpgộp lớplớp Co seOffe ingCo seOffe ingCatalogCatalog baobao gộpgộp lớplớp CourseOfferingCourseOffering
CourseOffering Catalog<< tit >><<entity>> <<entity>>
- acaYear: Date- semester
*
•• CửaCửa sổsổ giaogiao diệndiện baobao gộpgộp hoànhoàn toàntoàn thanhthanh cuộncuộn vàvà menumenu
1WindowMenu
* ScrollBar
125125Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Xây dựng lược đồ lớpXây dựng lược đồ lớpy ự g ợ py ự g ợ p
•• LượcLược đồđồ lớplớp (class(class diagram)diagram) biểubiểu diễndiễn cấucấu trúctrúc củacủa mộtmột sốsốlớplớp vàvà quanquan hệhệ giữagiữa chúngchúng mômô tảtả khíakhía cạnhcạnh tĩnhtĩnh (static)(static)lớplớp vàvà quanquan hệhệ giữagiữa chúngchúng mômô tảtả khíakhía cạnhcạnh tĩnhtĩnh (static)(static)củacủa hệhệ thốngthống
•• HệHệ thốngthống phứcphức tạptạp cócó nhiềunhiều lớplớp cầncần xâyxây dựngdựng nhiềunhiềuồồ ớớ ỗỗ ồồ ôô ảả ộộ ầầ ủủ ệệ ốốlượclược đồđồ lớp,lớp, mỗimỗi lượclược đồđồ mômô tảtả mộtmột phầnphần củacủa hệhệ thốngthống
•• LượcLược đồđồ lớplớp đượcđược bổbổ sungsung vàvà hoànhoàn thiệnthiện trongtrong mômô hìnhhìnhthiếtthiết kếkế (thêm(thêm mộtmột sốsố lớp,lớp, chichi tiếttiết cáccác thuộcthuộc tínhtính vàvà táctác vụ,vụ, làmlàm rõrõthiếtthiết kếkế (thêm(thêm mộtmột sốsố lớp,lớp, chichi tiếttiết cáccác thuộcthuộc tínhtính vàvà táctác vụ,vụ, làmlàm rõrõcáccác quanquan hệ)hệ)
•• LượcLược đồđồ lớplớp đượcđược xâyxây dựngdựng quaqua cáccác bướcbước– Xác định các lớpXác định các lớp– Xác định thuộc tính và tác vụ của các lớp– Xác định các lớp cơ sở và quan hệ tổng quát hoá– Xác định các quan hệ liên kết và bao gộp
126126Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
– Xác định các quan hệ liên kết và bao gộp
Ví dụ một lược đồ lớp phân tíchVí dụ một lược đồ lớp phân tíchụ ộ ợ p pụ ộ ợ p p
•• mộtmột lượclược đồđồ lớplớp củacủa chươngchương trìnhtrình hiểnhiển thịthị bềbề mặtmặt địađịa hìnhhình
Isoquant<<entity>>
FieldMap<<entity>>
*
isoquantsentity
- name: String*
+ wrap( ): Region- altitude: double
P i 2Dpoints
Ffractures*
MapCurve
- ID: int- open: boolean
Point2D
- x: double- y: double
*
pFracture
<<entity>>
127127Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
open: boolean
Thiết lập PACKAGEThiết lập PACKAGEậpập•• PackagePackage làlà mộtmột cơcơ chếchế đểđể tổtổ chứcchức cáccác phầnphần tửtử vàovào cáccác nhómnhóm cócó
liênliên hệhệ vềvề ngữngữ nghĩanghĩa vớivới nhaunhauệệ gg gg•• PackagePackage cócó thểthể importimport cáccác phầnphần tửtử từtừ mộtmột packagepackage kháckhác•• CóCó thểthể chỉchỉ rara quanquan hệhệ giữagiữa cáccác packagepackage
– Phụ thuộcPhụ thuộc– Tổng quát hoá
•• MứcMức độđộ truytruy xuấtxuất củacủa packagepackage– Private: chỉ nó và các package import nó có thể truy xuất nội dungPrivate: chỉ nó và các package import nó có thể truy xuất nội dung– Protected: giống như private nhưng cho phép thêm các package dẫn xuất– Public: các package khác có thể truy xuất nội dung– Implementation: không cho phép import, có thể áp dụng cho các phần tửp g p p p p ụ g p
bên trong package•• UMLUML chocho phépphép biểubiểu diễndiễn cáccác PACKAGEPACKAGE vàvà cáccác mốimối quanquan hệhệ
PACKAGEPACKAGE
128128Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Ví dụ về một PACKAGEVí dụ về một PACKAGEụ ộụ ộ
•• packagepackage UniPeopleUniPeople chứachứa cáccác lớplớp liênliên quanquan đếnđếnthôngthông tintin concon ngườingườithôngthông tintin concon ngườingười
# S iPeopleInfo
UniPeople
LecturerInfo- degree - title: String
di i i
# name: String# code: String# dateOfBirth: Date# addr: String
StudentInfo
Y D
- division - health- experience: Date
# add : St g
- acaYear: Date- department- home: String- socialAid
129129Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
socialAid
Tổng kếtTổng kếtgg
•• PhânPhân tíchtích hệhệ thốngthống chocho OOPOOP theotheo UMLUML chiachiaàà ớớlàmlàm 22 bướcbước::– Thu thập yêu cầu bằng mô hình nhgiệp vụ– Phân tích và xác định tính năng hệ thống bằng môị g ệ g g
hình phân tích
•• MôMô hìnhhình phânphân tíchtích nhậnnhận diệndiện cáccác đốiđốitượng/lớptượng/lớp:: thựcthực thểthể biênbiên điềuđiều khiểnkhiểntượng/lớptượng/lớp:: thựcthực thể,thể, biên,biên, điềuđiều khiểnkhiển
•• NhậnNhận diệndiện cáccác thuộcthuộc tínhtính vàvà mộtmột sốsố táctác vụ,vụ,tuytuy nhiênnhiên chưachưa làmlàm rõrõ hànhhành vivi củacủa chúngchúngyy gg(( mômô hìnhhình thiếtthiết kế)kế)
•• UMLUML hỗhỗ trợtrợ mộtmột sốsố phầnphần tửtử:: lớp,lớp, đốiđối tượng,tượng,lượclược đồđồ lớplớp packagepackage
130130Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
lượclược đồđồ lớp,lớp, packagepackage
Thiết kế phần mềmThiết kế phần mềm(Software Design)(Software Design)(Software Design)(Software Design)
CƠ SỞ CỦA THIẾT KẾ PHẦN MỀMÁ Ờ ÙGIAO DIỆN & TƯƠNG TÁC NGƯỜI DÙNG
PHƯƠNG PHÁP THIẾT KẾ CỔ ĐIỂNPHƯƠNG PHÁP THIẾT KẾ OOPPHƯƠNG PHÁP THIẾT KẾ OOP
Thiết kế phần mềmThiết kế phần mềm
Thiết kế phần mềm là công việc đầu tiên củaThiết kế phần mềm là công việc đầu tiên củagiai đoạn phát triểnThiết kế tạo ra các biểu diễn và dữ kiện của hệThiết kế tạo ra các biểu diễn và dữ kiện của hệthống phần mềm cần xây dựng từ kết quảphân tích yêu cầu để có thể dễ dàng hiện thựcsau đóThiết kế tạo ra phương thức và quy trình
á ờ ù ớ ệ ố ầtương tác giữa người dùng với hệ thống phầnmềm cũng như tương tác giữa các hệ thốngkhác với phần mềm
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 132132
khác với phần mềm.
Trừu tượng hóaTrừu tượng hóa
Quá trình thiết kế trải qua nhiều mức trừu tượng hoá khácQuá trình thiết kế trải qua nhiều mức trừu tượng hoá khácnhauMức cao nhất: vấn đề cần thiết kế được mô tả mộtá h tổ át ử d th ật ữ h ớ ấ đềcách tổng quát sử dụng thuật ngữ hướng vấn đềCác mức thấp hơn: hướng đến thủ tục xử lý chi tiết;kết hợp các thuật ngữ hướng đến hiện thựckết hợp các thuật ngữ hướng đến hiện thựcMức thấp nhất: vấn đề được mô tả theo cách có thểhiện thực trực tiếpPhân loại trừu tượng hoá: thủ tục và dữ liệu
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 133133
Trừu tượng hóaTrừu tượng hóa
Trừu tượng hoá thủ tục: là chuỗi các lệnh liên tiếpTrừu tượng hoá thủ tục: là chuỗi các lệnh liên tiếpthực hiện chức năng nào đó.
Ví dụ: mở cửa (bao gồm đi đến cửa, cầm lấy tay nắm, xoay tayắ ké á h ử đi à ) thê ột hầ tử à d h á hnắm, kéo cánh cửa, đi vào…); thêm một phần tử vào danh sách
có thứ tự (xác định vị trí, chèn phần tử mới)
Trừu tượng hoá dữ liệu: là tổ hợp dữ liệu mô tả mộtđối tượng dữ liệu (liên hệ tới đối tượng thực thể trongUML). Ví dụ: hàng, chồng, cánh cửa...Một số ngôn ngữ lập trình hỗ trợ kiểu ADT vàMột số ngôn ngữ lập trình hỗ trợ kiểu ADT vàtemplate
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 134134
Tinh chếTinh chế
Tinh chế là quá trình làm rõ vấn đềTinh chế là quá trình làm rõ vấn đề
Tinh chế và trừu tượng hoá là hai khái niệm bù trừnhau: càng tinh chế thì càng hạ thấp mức trừu tượnghoáThiết kế phần mềm: trừu tượng hóa rồi tinh chế hoáThiết kế phần mềm: trừu tượng hóa rồi tinh chế hoá.Tại sao?
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 135135
Thiết kế giao diện người dùngThiết kế giao diện người dùng
Phần mềm cần có giao diện thân thiện với người sửPhần mềm cần có giao diện thân thiện với người sửdụngMột số tiêu chuẩn giao diện
Thời gian đáp ứng của hệ thống: giá trị trung bình và độlệchPhương tiện trợ giúp người sử dụng: tích hợp + add onPhương tiện trợ giúp người sử dụng: tích hợp + add-onKiểm soát thông tin lỗi: hiện thị cả nguyên nhân lỗi và
cách khắc phụcĐặt tên nhãn: ngắn gọn và gợi nhớ
Thường dùng các công cụ thiết kế giao diện
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 136136
Công cụ thiết kế giao diệnCông cụ thiết kế giao diện
Công cụ thiết kế giao diện nên có những tính năng saug ụ g ệ g gQuản lý thiết bị nhập (bàn phím, chuột)Hiệu chỉnh thông tin inputKiểm soát lỗi và hiển thị thông báo lỗiKiểm soát lỗi và hiển thị thông báo lỗiCung cấp trợ giúp và hiển thị thông báo nhắc nhởCung cấp feedback (ví dụ như tự động hiển thị ký tự đánh vào)ể á ử ổ à ù ả ộKiểm soát cửa sổ và vùng, khả năng cuộn
Thiết lập giao tiếp giữa chương trình với giao diện (vd: hàm đápứng)Cách ly chương trình với các hàm quản lý giao diệnCho phép tuỳ biến giao diện: màu sắc, kích thước,..
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 137137
Một số định hướng về thiết kế giao diệnMột số định hướng về thiết kế giao diện
Một số hướng dẫn chungộ g gNên đồng nhất (menu, lệnh, hiển thị...)Nên cung cấp feedback cho người dùngYêu cầu xác nhận những tác vụ mang tính phá hoại (xoá fileYêu cầu xác nhận những tác vụ mang tính phá hoại (xoá file,account)Nên hỗ trợ UNDO, REDOH hế lượ thô ti hải hi hớ iữ 2 tá liê tiếHạn chế lượng thông tin phải ghi nhớ giữa 2 tác vụ liên tiếpTối ưu trong trình bày hộp thoại và di chuyển mouseChấp nhận lỗi từ phía người sử dụngCung cấp trợ giúp trực tuyếnDùng động từ đơn giản và ngắn gọn để đặt tên các lệnh
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 138138
Một số định hướng về thiết kế giao diệnMột số định hướng về thiết kế giao diện
Đối với thông tin hiển thịĐối với thông tin hiển thịChỉ hiển thị những thông tin phù hợp với ngữ cảnhhiện tạiDùng tên, từ viết tắt và màu gợi nhớCho phép tương tác trực quanT thô bá lỗi ó ý hĩTạo thông báo lỗi có ý nghĩaHiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổThiết lập biểu diễn tương tựThiết lập biểu diễn tương tựSử dụng không gian màn hình một cách tối ưu
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 139139
Một số định hướng về thiết kế giao diệnMột số định hướng về thiết kế giao diện
Đối với thông tin inputg pHạn chế input trực tiếp (có thể chọn lựa từ một số dữliệu có sẵn)Nên đồng nhất giữa thông tin input và hiển thịNên đồng nhất giữa thông tin input và hiển thịNên cho phép tuỳ biến inputCấm các chức năng không thích hợp trong ngữ cảnhg g ợp g ghiện tạiCho phép input ở nhiều dạng khác nhauĐể cho người sử dụng kiểm soát dòng sự kiện tươngĐể cho người sử dụng kiểm soát dòng sự kiện tươngtácTự động tính các giá trị input cho người sử dụng nếuó thể
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 140140
có thể
Thiết kế phần mềm Thiết kế phần mềm Phương pháp lập trình cấu trúcPhương pháp lập trình cấu trúcPhương pháp lập trình cấu trúcPhương pháp lập trình cấu trúc
Module hoá chương trìnhPhâ hi d lPhân chia moduleKiến trúc phần mềmThiết kế dữ liệu
Thiết kế phần mềm cổ điểnThiết kế phần mềm cổ điển
Các công đoạn trong thiết kế phần mềm cổCác công đoạn trong thiết kế phần mềm cổđiển
Phân chia moduleThiết kế dữ liệuThiết kế kiến trúcThiết kế thủ tụcThiết kế giao diện
hầ ề há ể h ô hì h ổ đ ễPhần mềm phát triển theo mô hình cổ điễn:quan tâm đến cấu trúc và giải thuật của các module
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 142142
PHÂN CHIA MODULE
Module là gì?gKhái niệm module đã xuất hiện khoảng 4 thập niên trở lạiđây.Phần mềm được â dựng bằng cách phân chia thành nhiềPhần mềm được xây dựng bằng cách phân chia thành nhiềumodule, sau đó sẽ được tích hợp lạiPhân chia module làm cho việc quản lý phần mềm khoa họchơnGiả sử C(x): độ phức tạp của x, E(x): công sức để thực hiệnx. Rõ ràng: nếu C(p1) > C(p2) thì E(p1) > E(p2).x. Rõ ràng: nếu C(p1) C(p2) thì E(p1) E(p2).Nếu phân chia p = p1 + p2 ta thấy (một cách trực quan):C(p1 + p2) > C(p1) + C(p2) E(p1 + p2) > E(p1) + E(p2)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 143143
Phân chia module như thế nào?Phân chia module như thế nào?
Số lượng ợ gmodule phụ thuộc vào độ phức tạp của Tổng công sức phát triểnhệ thống phần mềm cần xây dựứ
c bỏ
ra
Vùng tối ưu
dựngQuá ít hoặc quá nhiều mod le đề
Côn
g sứ
module đều không tốt
Tổng công sức từng moduleCông sức tích hợp
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 144144
Số lượng module
Kiến trúc phần mềmKiến trúc phần mềm
Kiến trúc phần mềm mô tả các thành phầnKiến trúc phần mềm mô tả các thành phần(component) kiến tạo nên hệ thống phần mềm và sựgiao tiếp giữa các thành phần đó
Thành phần có thể làCác module mã nguồnCác module mã nguồnCác file thực thi (*.dll, *.exe, *.class...)Các thành phần của kiến trúc hệ thống: ActiveX control,Các t à p ầ của ế t úc ệ t ố g: ct ve co t o ,bean...Các trang HTML, *.asp, *.jsp...
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 145145
Kiến trúc phần mềm- Sơ đồ phân cấpKiến trúc phần mềm Sơ đồ phân cấp
Sơ đồM Sơ đồ phân cấp được dùng để
ba c
Fan-out
dùng để miêu tả sự phân ed k l m
Depth
rã các module.f hg n o p q
i j rFan-in
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 146146
Width
Phân chia module hiệu quảPhân chia module hiệu quả
Phân chia module là bắt buộc trong giai đoạn thiết kếPhân chia module là bắt buộc trong giai đoạn thiết kếTuy nhiên: phân chia kiến trúc phần mềm thành mộtbộ các module như thế nào là tốt nhất ?
Đạt được vùng tối ưu về tổng chi phí quản lý và phát triển từng module
Tiê hí t hất tí h độ lậ hứ ă ủTiêu chí quan trọng nhất: tính độc lập chức năng củacác moduleTính độc lập chức năng được đo bằng 2 tiêu chuẩn:Tính độc lập chức năng được đo bằng 2 tiêu chuẩn:
Độ kết dính (cohesion)Sự liên kết (coupling)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 147147
Độ kết dínhĐộ kết dính
Độ kết dính dùng để đo sự phụ thuộc lẫn nhaugiữa những tác vụ (task) của một module
Module có độ kết dính cao nhất khi nó chỉđả hậ đú ột tá kết dí h hứđảm nhận đúng một tác vụ kết dính chứcnăng
Thiết kế kiến trúc phần mềm: cố gắng tăng độkết dính
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 148148
Các mức độ kết dínhCác mức độ kết dính
Có nhiều mức độ kết dính (từ thấp đến cao)Có nhiều mức độ kết dính (từ thấp đến cao)Ngẫu nhiên: các tác vụ không liên hệ với nhauLuận lý: các tác vụ liên quan logic với nhauNhất thời: các tác vụ phải được thực thi trong mộtkhoảng thời gianGi tiế á tá ó ử d h ột dữ liệGiao tiếp: các tác vụ có sử dụng chung một dữ liệunào đóThủ tục: các tác vụ phải được thực hiện theo một trậtThủ tục: các tác vụ phải được thực hiện theo một trậttự nhất địnhChức năng: chỉ có một tác vụ
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 149149
Sự liên kếtSự liên kết
Sự liên kết dùng để đo đạc quá trình giao tiếp giữa cácmodule: giao tiếp của module chứa nhiều tác vụ vàhiề thô ố i thì liê kết ànhiều thông số gọi thì sự liên kết càng cao
Thiết kế kiến trúc phần mềm: cố gắng giảm sự liênThiết kế kiến trúc phần mềm: cố gắng giảm sự liênkết
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 150150
Các mức độ liên kếtCác mức độ liên kết
Có nhiều mức độ liên kết (từ cao đến thấp)Có nhiều mức độ liên kết (từ cao đến thấp)Liên kết nội dung: sử dụng dữ liệu và điều khiển củamodule khácLiên kết chung: có sử dụng chung dữ liệu toàn cụcLiên kết ngoại vi: module phụ thuộc vào một I/O nàođóđóLiên kết điều khiển: thông số truyền ảnh hưởng đếnđiều khiểnLiên kết stamp: truyền cấu trúc dữ liệu phức tạpLiên kết dữ liệu: truyền các thông số đơn giản
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 151151
Nguyên lý che dấu thông tinNguyên lý che dấu thông tin
Che dấu thông tin là một trong những nguyên lý quantrọng của việc phân chia moduleCác module giao tiếp với nhau bằng những thông tinthật sự cần thiết
Những thông tin về thủ tục và dữ liệu cục bộ của mỗimodule phải được che dấu khỏi các module khác
Lợi ích: kiểm soát được thay đổi và sửa lỗi dễ dàng
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 152152
Các Heuristic trong phân chia moduleCác Heuristic trong phân chia module
Sửa lại thiết kế ban đầu để tăng độ kết dính và giảmSửa lại thiết kế ban đầu để tăng độ kết dính và giảmsự liên kếtKhi chiều sâu tăng, hạn chế fan-out trong khi sử dụngf ifan-inGiữ cho tầm ảnh hưởng của một module nằm bêntrong tầm điều khiển của nótrong tầm điều khiển của nóLoại bỏ dư thừa trong giao tiếp của các moduleƯu tiên các module tất định, hạn chế các modulenhiều ràng buộcĐóng gói các module để đạt được tính khả chuyển(portability)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 153153
(portability)
Thiết kế dữ liệuThiết kế dữ liệu
Tìm kiếm biểu diễn luận lý cho các phần tử dữ liệu đãTìm kiếm biểu diễn luận lý cho các phần tử dữ liệu đãđược nhận diện trong giai đoạn phân tích yêu cầuThiết kế các cấu trúc dữ liệu của chương trình và cơ sởdữ liệdữ liệuThực hiện tinh chế từng bướcCác tiêu chí thiết kế hệ cơ sở dữ liệuCác tiêu chí thiết kế hệ cơ sở dữ liệu
Không dư thừa dữ liệuTối ưu hóa không gian lưu trữố ưu óa ô g g a ưu t ữ
Chuẩn hóa cơ sở dữ liệu bằng lược đồ ERD và dạngchuẩn 3
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 154154
Cấu trúc dữ liệuCấu trúc dữ liệu
Cấu trúc dữ liệu là thiết kế cơ sở dữ liệu động tron hệCấu trúc dữ liệu là thiết kế cơ sở dữ liệu động tron hệthốngCấu trúc dữ liệu mô tả sự tổ chức, phương thức truyất ứ độ liê kết à á ử lý khá ủ thô tixuất, mức độ liên kết và các xử lý khác của thông tin
Dữ liệu đơn là dạng cấu trúc dữ liệu đơn giản nhất chỉbao gồm một phần tử thông tin mà có thể được truybao gồm một phần tử thông tin mà có thể được truyxuất bằng một danh địnhMột số dạng phức tạp hơn: vector, ma trận, mảngh ề h ề d h á h l ê kế hà hồ â hnhiều chiều, danh sách liên kết, hàng, chồng, cây nhị
phân…Được biểu diễn ở các mức trừu tượng hoá khác nhau
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 155155
Được biểu diễn ở các mức trừu tượng hoá khác nhau
Mộ số nguyên tắc thiết kế dữ liệuMộ số nguyên tắc thiết kế dữ liệu
Một số nguyên tắcMột số nguyên tắcNhận diện cả cấu trúc dữ liệu và tác vụ truy xuấtChú ý sử dụng từ điển dữ liệuTrì hoãn thiết kế dữ liệu mức thấp cho đến cuối giaiđoạn nàyCh dấ biể diễ bê t ủ ấ t ú dữ liệChe dấu biểu diễn bên trong của cấu trúc dữ liệuPhát triển một thư viện các cấu trúc dữ liệu + tác vụthường gặpthường gặpNên áp dung kiểu ADT trong thiết kế cũng như tronglập trình
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 156156
Thiết kế kiến trúcThiết kế kiến trúc
Mục tiêu là xây dựng sơ đồ phân cấp module từ DFD
Đặt ề ó để thiết kế hi tiết thủ t à dữ liệĐặt nền móng để thiết kế chi tiết thủ tục và dữ liệu
Phân biệt dòng transform và dòng transaction trongPhân biệt dòng transform và dòng transaction trongDFD
Thự hiệ á h h từ ù ủ DFD t ỳ th óThực hiện ánh xạ cho từng vùng của DFD tuỳ theo nólà dòng transform hay transaction
Xác định các module và các mối liên hệ theo DFD quá trình sử lý
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 157157
Dòng TransformDòng Transform
Dòng transform bao gồm 3 phần: dòng đi vào, dòngDòng transform bao gồm 3 phần: dòng đi vào, dòngxử lý và dòng đi ra
Doøng ñi vaøoDoøng xöû lyù
Doøng ñi ra
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 158158
Dòng TransactionDòng Transaction
DòngDò đi à Dòngtransaction baogồm: dòng đivào T center và
Dòng đi vào
vào, T-center vàcác đường xử lýđầu ra
T tT-center: Chỉcó một đườngra được kích
T-center
ra được kíchhoạt tại mộtthời điểm
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 159159
Thiết kế thủ tụcThiết kế thủ tục
Thiết lập thuật giải cho các module đã kiến tạo saocho có thể dễ dàng mã hoá bằng ngôn ngữ lập trình cóấ t úcấu trúc
Có thể biểu diễn thuât giải bằngCó thể biểu diễn thuât giải bằngLưu đồ thuật giải: FlowchartKý hiệu dạng bảngý ệu dạ g bả gN gôn ngữ PDL
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 160160
Ngôn ngữ PDLNgôn ngữ PDL
Ngôn ngữ PDL vay mượn từ vựng của ngôn ngữ tựNgôn ngữ PDL vay mượn từ vựng của ngôn ngữ tựnhiên và cú pháp của ngôn ngữ lập trình có cấu trúc.Nó có các tính chất sau:Cú há hặt hẽ ủ á từ kh á hỗ t đặ tả ấCú pháp chặt chẽ của các từ khoá hỗ trợ đặc tả cấutrúc, khai báo dữ liệu, phân chia moduleCú pháp tự do của ngôn ngữ tự nhiên giúp miêu tả xửCú pháp tự do của ngôn ngữ tự nhiên giúp miêu tả xửlýPhương tiện mô tả dữ liệu đơn cũng như dữ liệu tổhhợpCơ chế định nghĩa chương trình con và phương cáchgọi
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 161161
gọi
Ngôn ngữ PDL – Ví dụNgôn ngữ PDL Ví dụ
procedure AnalyzeTriangle( a, b, c: in real; type: out string)beginbegin
sort a, b, c so that a >= b >= c;if ( c > 0 and a < b + c )
if ( a = c )type : “Equilateral”type := “Equilateral”
elseif ( a = b or b = c )
type := “Isosceles”elseelse
if ( a*a = b*b + c*c )type := “Right”
elsetype : “Scalene”type := “Scalene”
elsetype := “Error”
end
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 162162
Thiết kế phần mềmThiết kế phần mềmUMLUMLUMLUML
Lược đồ cộng tácồ ầLược đồ tuần tự
Lược đồ trạng thái các lớp/đối tượngLược đồ hành độngLược đồ hành độngHoàn chỉnh lược đồ lớp
Giới thiệuGiới thiệu
Giai đoạn thiết kế quan tâm đến “HOW”:Giai đoạn thiết kế quan tâm đến HOW :Thứ tự các thông điệp trao đổi, thông số của thông điệpThuật giải của tác vụ đáp ứngấCấu trúc dữ liệu cho các thuộc tính
Framework (console, document/view, 3-tier...)Thiết kế cũng chịu ảnh hưởng từ:Thiết kế cũng chịu ảnh hưởng từ:N gôn ngữ lập trình và thư viện lập trình (Hỗ trợ Vector,List, Map... hay không ? Hỗ trợ template hay không ?...)Kiến trúc hệ thống (COM, CORBA hay EJB)
Thiết lập mô hình động (dynamic modeling) và chi tiếthoá mô hình tĩnh
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 164164
hoá mô hình tĩnh
Khái niệm mô hình độngKhái niệm mô hình động
Lược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ thốngLược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ thốngHành vi của hệ thống được mô tả bằng mô hình độngbao gồm
ốTương tác giữa các đối tượng: cộng tác hay trình tựTrạng thái của đối tượng/lớpQuá trình hoạt động của lớp/đối tượngQuá trình hoạt động của lớp/đối tượng
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 165165
Tương tác giữa các đối tượngTương tác giữa các đối tượng
Đối tượng tương tác với nhau (interaction) bằng cáchĐối tượng tương tác với nhau (interaction) bằng cáchgửi/nhận kích thích (stimulus)Actor cũng có thể gửi kích thích đến đối tượngKích thích khiến một tác vụ thực thi, một đối tượngđược tạo ra hay huỷ đi, hoặc gây ra một tín hiệuThông điệp (message) là đặc tả của kích thíchThông điệp (message) là đặc tả của kích thíchCác loại thông điệp
Đơn giảnĐồng bộBất đồng bộTrả về của gọi hàm
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 166166
Trả về của gọi hàm
Sự cộng tác – Lược đồ cộng tácSự cộng tác Lược đồ cộng tác
Cộng tác (collaboration) định nghĩa tập hợpCộng tác (collaboration) định nghĩa tập hợpcác thành phần tham gia và quan hệ giữachúnggCác thành phần tham gia là vai trò mà đốitượng/lớp đóng vai khi tương tác với nhauCác vai trò của đối tượng thường chỉ có nghĩađối với một mục đích nào đóLược đồ cộng tác (collaboration diagram) đượcthiết lập để cụ thể hoá một use-case hoặc mộtá
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 167167
tác vụ
Lược đồ cộng tácLược đồ cộng tác
Lược đồ cộng tác là một đồ thị liên kết các vai trò củaLược đồ cộng tác là một đồ thị liên kết các vai trò củacác đối tượng hình thành nên các chức năng của hệthống (các usecase)Mỗi h liê kết 2 i t ò đ biể diễ bằ ộtMỗi cạnh liên kết 2 vai trò được biểu diễn bằng mộtđoạn thẳngTương tác được thể hiện bằng gửi/nhận thông điệpTương tác được thể hiện bằng gửi/nhận thông điệpHai vai trò liên kết với nhau khi có trao đổi thông điệpMỗi thông điệp được thể hiện bằng mũi tên (như đãmiêu tả) cộng với phần đặc tả
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 168168
Lược đồ cộng tác (tt)Lược đồ cộng tác (tt)
Các thông điệp được đánh số theo kiểu phânCác thông điệp được đánh số theo kiểu phâncấp
3.4.2 xảy ra sau 3.4.1 và cả hai được lồng (nested) trong 3.4y ợ g ( ) g3.4.3a và 3.4.3b xảy ra đồng thời và được lồng trong 3.4
Cú pháp tổng quát của thông điệpprecedessor guard-condition sequence-expression return-
value := message-name argument-listVí d 2/ 1 3 1 p find(specs)Ví dụ: 2/ 1.3.1: p := find(specs)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 169169
Lược đồ cộng tác (tt)Lược đồ cộng tác (tt)
Lược đồ cộng tác có thể được thiết lập ở một trong 2Lược đồ cộng tác có thể được thiết lập ở một trong 2dạng:
Dạng cụ thể: mỗi vai trò được biểu diễn bằng một ký hiệuủ đối tượ thể á thô điệ đượ t đổi t ê ácủa đối tượng cụ thể, các thông điệp được trao đổi trên cácđường liên kết
Dạng đặc tả: mô tả các lớp; các đường liên kết được ánh xạạ g ặ p; g ợ ạvào các thông điệpThiết lập lược đồ cộng tác giúp cụ thể hoá (realize) cácuse case và nhận diện thêm một số tác vụ của các đốiuse-case và nhận diện thêm một số tác vụ của các đốitượng/lớp phân tích
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 170170
Lược đồ cộng tác – Ví dụLược đồ cộng tác Ví dụ
Ví dụ: lược đồ cộng tác mức cụ thể cho use caseVí dụ: lược đồ cộng tác mức cụ thể cho use-case
Login của hệ thống đăng ký môn học tín chỉ qua WEB
: People1: login(uname,pswd)
: LoginForm1.2 [succ = true]: welcome
D t b1.1: succ := Verify(uname,pswd)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 171171
: Database
Lược đồ cộng tác – ví dụ 2Lược đồ cộng tác ví dụ 2
Ví dụ: lược đồ 1: submit(uname psswd)2: register
Ví dụ: lược đồ
cộng tác mức
cụ thể cho : Student
: LoginForm1: submit(uname, psswd)
1.2 [succ = true]: welcome
3: submit(crsOffering)ụ
use-case
Registers 1.1: succ := verify(uname, psswd)
3: submit(crsOffering)
3.4: beSuccessful 2.1: create
course của hệ
thống đăng ký
regForm : RegisterForm
3.1: reg := FetchReg(crsOffering)
môn học tín
chỉ qua WEB : Database: Registration
3.3: SetReg(reg)3.2: AddStudent(code)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 172172
Miêu tả trình tựMiêu tả trình tự
Lược đồ cộng tác miêu tả sự tương tác theo khíaLược đồ cộng tác miêu tả sự tương tác theo khíacạnh không gianĐể nhấn mạnh trình tự của tương tác ・ dùng lượcg gđồ tuần tự (sequence diagram)Lược đồ tuần tự miêu tả các đối tượng tương tácới h th thời i ố ủ óvới nhau theo thời gian sống của nó
Các thông điệp được trao đổi theo trình tự thờigiangianCác mối liên kết không được thể hiện trong lượcđồ
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 173173
đồ
Lược đồ tuần tựLược đồ tuần tự
Lược đồ tuần tự có 2 dạngDạng tổng quát: thể hiện cả vòng lặp và rẽ nhánhDạng cụ thể: miêu tả một kịch bản cụ thểThời gian sống của mỗi đối tượng được mô tả theo mộtg g ợ g ợ ộđường thẳng đứngThông thường thời gian trôi theo chiều từ trên xuống dướiÍt khi quan tâm đến khoảng thời gian thường chỉ quan tâmÍt khi quan tâm đến khoảng thời gian, thường chỉ quan tâmđến trình tự mà thôiThanh hình chữ nhật mô tả sự thực thi của một tác vụ đểđáp ứng lại thông điệp gửi đến. Độ dài của thanh chữ nhậtđáp ứng lại thông điệp gửi đến. Độ dài của thanh chữ nhậtphản ánh thời gian thực thi của tác vụ và tính chất lồngnhau (nested) giữa chúngCác dòng text phụ trợ (mô tả tác vụ, ràng buộc thời
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 174174
Các dòng text phụ trợ (mô tả tác vụ, ràng buộc thờigian...) được viết ở lề trái
Lược đồ tuần tự - Ví dụLược đồ tuần tự Ví dụ
Ví dụ: lược đồ tuần tự dạng tổng quátVí dụ: lược đồ tuần tự dạng tổng quát
: Peopleob2 : C2 ob3 : C3 ob4 : C4
eop eob1 : C1new( )
[x<0] op2( )
[x>=0] op3( )
op5( ob3 )op4( y )
display( )
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 175175
Lược đồ tuần tự - Ví dụLược đồ tuần tự Ví dụ
Lược đồ tuần tự với các ghi chú ràng buộc thời gianợ ự g g ộ g
: Operator:Computer :PrinterServer :Printer
print(ps-file )print(ps-file)
print(ps-file)a{b - a < 5 seconds}{b - a < 5 seconds}
b
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 176176
Lược đồ tuần tự - Ví dụLược đồ tuần tự Ví dụ
Ví dụ: lược đồ tuần tự dạng cụ thể cho use-case LoginVí dụ: lược đồ tuần tự dạng cụ thể cho use case Logincủa hệ thống đăng ký môn học tín chỉ qua WEB
: Database: People : LoginForm
1 b it( d)1: submit(uname, psswd) 1.1: verify(uname, psswd)
1.2: welcome
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 177177
Lược đồ tuần tự - Ví dụLược đồ tuần tự Ví dụ
Lược đồ tuầnLược đồ tuần
tự dạng
cụ thể
: StudentregForm :
RegisterForm: Database: Registration: LoginForm
1: submit(uname, psswd) 1.1: verify(uname, psswd)1 2: welcome cụ thể
cho use-
case
1.2: welcome
2: register2.1: create case
Register
courses
3. submit(crsOffering) 3.1: reg := fetchReg(srcOffering)
3.2: addStudent(code) cou ses3.3: setReg(reg)
3.4: beSuccessful( )
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 178178
Trạng thái của đối tượngTrạng thái của đối tượng
Chuẩn UML đưa ra lược đồ trạng thái để biểuChuẩn UML đưa ra lược đồ trạng thái để biểudiễn hành vi của một phần tử bất kỳ bằng cáchchỉ ra đáp ứng của nó đối với các sự kiện bênp g ự ệngoàiThông thường lược đồ trạng thái được áp dụng
ể ễcho đối tượng/lớp biểu diễn hành vi của lớpTrạng thái của mỗi đối tượng (định nghĩa gốc
í ề ổ ố ỳ?) ít nhiều sẽ bị thay đổi trong suốt chu kỳsống của đối tượng
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 179179
Trạng thái của đối tượngTrạng thái của đối tượng
Trong UML ký hiệu của trạng thái là một hình chữTrong UML ký hiệu của trạng thái là một hình chữnhật tròn góc và được chia làm nhiều phần phân cáchnhau bằng các đoạn thẳng nằm ngang:
hầ êPhần tênPhần miêu tả các hành động bên trong
Typing Password
entry / set echo visibleentry / set echo visibleexit / set echo normalcharacter / handle characterhelp / display help
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 180180
Trạng thái của đối tượngTrạng thái của đối tượng
Tên trạng thái là duy nhất trong lược đồ; có thể khôngạ g y g ợ ; gcó tên (trạng thái vô danh)Các hành động bên trong: các hành động hoặc tác vụđược thực hiện khi đối tượng nằm ở trạng thái đangđược thực hiện khi đối tượng nằm ở trạng thái đangxét; có cú pháp như sau
action-label ’/’ action-expressionMộ ố hã hà h độ ( i l b l) đ ớMột số nhãn hành động (action-label) được quy ướctrước:
entry: thực hiện hành động tại thời điểm bắt đầu trạng tháiexit: thực hiện hành động tại thời điểm kết thúc trạng tháido: thực hiện hành động suốt trạng thái hoặc cho đến khi kết thúc nóinclude: triệu gọi một máy trạng thái con khác
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 181181
Trạng thái của đối tượngTrạng thái của đối tượng
Các nhãn hành động khác chỉ ra sự kiện kích hoạtCác nhãn hành động khác chỉ ra sự kiện kích hoạthành động tương ứng trong biểu thức hành động(action-expression)
Cú pháp của biểu thức hành độngevent-name ’(‘ parameter-list ’)’ ’[‘guard-condition’]’ ’/’event-name ( parameter-list ) [ guard-condition ] /
action-expression
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 182182
Lược đồ trạng tháiLược đồ trạng thái
Trạng thái bắt đầu: khi đối tượng được tạo ra hoặcTrạng thái bắt đầu: khi đối tượng được tạo ra hoặctrạng thái tổng hợp được xác định; ký hiệu
Trạng thái kết thúc: khi đối tượng bị huỷ bỏ hoặc trạngthái tổng hợp trở nên không xác định; ký hiệuthái tổng hợp trở nên không xác định; ký hiệu
Trạng thái tổng hợp (composite) được phân rã thànhnhiều trạng thái con đồng thời hoặc các trạng thái conl i t ừ h
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 183183
loại trừ nhau
Lược đồ trạng thái – trạng thái tổng hợpLược đồ trạng thái trạng thái tổng hợp
Phân rã trạng thái tổng hợp RunningPhân rã trạng thái tổng hợp Running
R nningRunning
Forward Backward
Slow Fast
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 184184
Lược đồ trạng tháiLược đồ trạng thái
Sự kiện (event) kích hoạt dịch chuyển trạng thái, cóSự kiện (event) kích hoạt dịch chuyển trạng thái, cóthể là
Một điều kiện trở nên đúng (chú ý khác với guard-condition)ố ốMột đối tượng nhận tín hiệu từ đối tượng khác
Một phép gọi tác vụMột khoảng thời gian đã trôi qua kể từ một sự kiện nào đóMột khoảng thời gian đã trôi qua kể từ một sự kiện nào đó
Cú pháp của sự kiện: event-name ’(’ parameter-list ’)’Sự kiện có tầm vực thuộc về package chứa lớp đangmô tả lược đồ trạng thái, chứ không chỉ thuộc về riênglớp đó
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 185185
Lược đồ trạng thái – Dịch chuyểnLược đồ trạng thái Dịch chuyển
Dịch chuyển trạng thái là quan hệ giữa hai trạng tháiDịch chuyển trạng thái là quan hệ giữa hai trạng tháitheo đó đối tượng đang ở trạng thái thứ nhất sẽchuyển sang trạng thái thứ hai đồng thời sẽ thực hiệnmột số hành động khi sự kiện tương ứng xảy ra vàmột số hành động khi sự kiện tương ứng xảy ra vàthoả mãn một số điều kiện nhất địnhĐược ký hiệu như một mũi tên hướng từ trạng tháiợ ý ệ ộ g ạ gnguồn đến trạng thái đích và được gán nhãnNhãn có cú pháp: event-signature ’[’ guard-condition’]’ ’/’ action expression’]’ ’/’ action-expression
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 186186
Lược đồ trạng thái – Ví dụLược đồ trạng thái Ví dụ
lược đồ trạng thái của lớp Messagelược đồ trạng thái của lớp Message
Composedcompose command
focushightlight
entry/ assign IDexit/ fill dateon char/ handle character
compose command
Read
entry/ convert to rich textre-fwd cmd / quote / append subject
unhightlight
read command / recover( id )save command
send command[ recipents != null ] / parse
Stored
entry/ save into folder
logoutSending
do/ send( repc )
sending done
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 187187
Lược đồ trạng thái – ví dụ 2Lược đồ trạng thái ví dụ 2import failed
No map
do/ load mapdo/ load image
runModeling
do/ model(map, param)map loaded[ image invalid ]
do/ load image
Saved modeling doneexit command
image loadedimport / map := create( file )
import / map := create(file)entry/ renderdo/ store
model command
import command[ file valid ]
exit command
Dirty
model command
save command
viewing command
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 188188
Dirty
entry/ renderexit command / save
Lược đồ hoạt độngLược đồ hoạt động
Lược đồ hoạt động (activity diagram) là một biến thể của lược đồợ ạ ộ g ( y g ) ộ ợtrạng thái trong đó trạng thái là sự thực thi một hành động và sựdịch chuyển được kích hoạt khi hành động hoàn tấtĐược dùng để mô tả một thủ tục hay thuật giải ・ tập trung vàoợ g ộ ụ y ậ g ập gcác hành độngMỗi hành động được ký hiệu bằng hình vẽ như sau
Q ết định ẽ nhánh hình thoi có một đường ào à nhiề nhánh
work
Quyết định rẽ nhánh: hình thoi có một đường vào và nhiều nhánhra, mỗi nhánh được gán một guard-conditionCác nhánh ra được nhập lại bằng một hình thoi khácỗ ờ ệ ộ ớ ặ ộ
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 189189
Mỗi “đường bơi” (swimlane) đại diện một lớp hoặc một actor
Lược đồ hoạt động – ví dụLược đồ hoạt động ví dụ
lược đồDatabaseLoginForm
lược đồ hoạt động cho tác
Show input for username and password
cho tác vụ submit
[ d i lid ]
Verify
của LoginForm
Reject
[ psswd invalid ]
Welcome
[ psswd valid ]
orm
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 190190
Lược đồ hoạt động – ví dụ 2Lược đồ hoạt động ví dụ 2
Lược đồ hoạtRegistrationDatabaseRegForm Lược đồ hoạtđộng cho tácvụ submitcủa
Read course offerings
submit
Look for registration
củaRegisterForm[ reg found ]
[ reg not found ]
Fetch registration
Create registration
Show success
Update registration
Add student
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 191191
Nhận diện một số lớp thiết kếNhận diện một số lớp thiết kế
Mô hình thiết kế phần nào chịu ảnh hưởng từ ngônMô hình thiết kế phần nào chịu ảnh hưởng từ ngônngữ lập trình, thư viện hỗ trợ, framework, hệ điềuhành và loại máy tínhMột ố lớ ẽ ất hiệ khi á d hữ ế tố t êMột số lớp sẽ xuất hiện khi áp dụng những yếu tố trênN gôn ngữ lập trình: template, CObject...Thư viện hỗ trợ: lớp Date Time List Map vectorThư viện hỗ trợ: lớp Date, Time, List, Map, vector,iostream…Framework: Applet, Panel, CDocument, CView,
HttpServlet…Hệ điều hành: các lớp thao tác file, mở cầu nối network,các phần tử giao diện
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 192192
các phần tử giao diện….
Nhận diện một số lớp thiết kếNhận diện một số lớp thiết kế
Một số lớp khác xuất hiện làm chức năng duyệtMột số lớp khác xuất hiện làm chức năng duyệt(iterate) một lớp khác hay thực hiện các tính toánphức tạp...Sử d t tiế á lớ d th iệ h ô ữSử dụng trực tiếp các lớp do thư viện hay ngôn ngữcung cấp, hoặcTạo ra lớp mới bằng cách thừa kế hay tích hợp các lớpTạo ra lớp mới bằng cách thừa kế hay tích hợp các lớpcó sẵn,ví dụ CArray<Isoquant, Isoquant&>Bổ sung các lớp mới vào lược đồ lớp đồng thời cậpnhật các mối quan hệ mới (bao gộp, phụ thuộc)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 193193
Đặc tả chi tiết các thuộc tínhĐặc tả chi tiết các thuộc tính
Trong mô hình phân tích Messageg pcần phải chỉ rõ kiểu(hoặc cấu trúc dữ liệu)và mức độ truy xuất của # subject: String
# content: String
Message<<entity>>
các thuộc tínhCó thể chọn một lớpcung cấp bởi thư việnậ ì ể ể á
+ GetSubject( ): String+ toString( ): String
# content: String
lập trình để cụ thể hoákiểu hay cấu trúc dữ liệu
bổ sung lớp của thưiện à q an hệ baoviện và quan hệ bao
gộp vào lược đồ lớp
CDate
sent1
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 194194
CDate
Nhận diện chính xác các tác vụNhận diện chính xác các tác vụ
Các lược đồ mô tả hành vi (cộng tác, tuần tự, trạngCác lược đồ mô tả hành vi (cộng tác, tuần tự, trạngthái, hành động) giúp nhận diện chính xác các tác vụcủa các lớpD à á thô điệ h hà h độ để á đị hDựa vào các thông điệp hay hành động để xác địnhsignature của các tác vụ
Ví dụ: nhận diện một tác vụ của lớp DatabasefetchStudent( code: Long ): StudentInfo;setReg( reg: Registration );
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 195195
Nhận diện chính xác các tác vụ (tt)Nhận diện chính xác các tác vụ (tt)
Ví dụ: nhận diện một tác vụ của lớp ChildViewVí dụ: nhận diện một tác vụ của lớp ChildViewrender( );store( );load( );model( map: FieldMap, param );
Ví dụ: nhận diện một tác vụ của lớp LoginFormb it( St i d St i )submit( uname: String; psswd: String );
makeWelcome( );
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 196196
Hoàn chỉnh lược đồ lớpHoàn chỉnh lược đồ lớp
Cập nhật các lớp mới, thuộc tính, tác vụ và các mốiCập nhật các lớp mới, thuộc tính, tác vụ và các mốiquan hệ mớiUML định nghĩa quan hệ phụ thuộc (dependency)iữ 2 lớ h ặ k th đổi ở ột lớ kgiữa 2 lớp hoặc package: thay đổi ở một lớp, package
kéo theo thay đổi ở lớp, package kiaKý hiệu của quan hệ phụ thuộc là mũi tên đứt nét:Ký hiệu của quan hệ phụ thuộc là mũi tên đứt nét:lớp, package ở phía đuôi mũi tên phụ thuộc vào lớp,package phía đầu mũi tênộ ố ớ ớ llMột số stereotype quy ước trước: <<call>>,
<<instantiate>>, <<import>>, <<refine>>,<<realize>>, <<derive>>, <<trace>>
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 197197
, ,
Hoàn chỉnh lược đồ lớp – Ví dụHoàn chỉnh lược đồ lớp Ví dụ
thêm lược đồ lớp cho hệ thống đăng ký môn họcthêm lược đồ lớp cho hệ thống đăng ký môn họcLoginForm
<<boundary>>RegisterForm
<<boundary>>
+ submit(offering: CourseOffering)
+ submit(uname: String, psswd: String)
+ beSuccessful( )+ makeWelcome( )
Database<<call>>
<<call>
+ fetchStudent(code: Long):
StudentInfo
> >
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 198198
+ setReg(reg: Registration)
Hoàn chỉnh lược đồ lớp – ví dụ 2Hoàn chỉnh lược đồ lớp ví dụ 2
FieldMapi
# map<<entity>>
f i d
MapIterator MapIterator<Isoquant*>
ItemFractureIterator
+ current( ): F *
<<friend>>
# setBound(b: int)+ current( ): Item+ operator++()
()
Fracture*
+ operator--()+ Last( )+ First( )
IsoquantIterator
+ current( ):
MapIterator<Fracture*>
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 199199
current( ): Isoquant*
Hoàn chỉnh lược đồ lớp - packageHoàn chỉnh lược đồ lớp package
Chú ý sử dụng package để tổ chức các phần tử liênChú ý sử dụng package để tổ chức các phần tử liênquan với nhau: các lớp về bản đồ địa hình, về thôngtin sinh viên/giảng viên, về cửa sổ giao diện, về cácservletservlet…Các package thể hiện kiến trúc phần mềm, thôngthường chịu ảnh hưởng từ frameworkg ị g(Document/View, 3-tiers...)Mỗi package chứa một hoặc một vài lược đồ lớp,trong đó có thể tham chiếu đến một số lớp thuộc cáctrong đó có thể tham chiếu đến một số lớp thuộc cácpackage khác
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 200200
Mô hình thiết kế bao trùm cả khíacạnh tĩnh và động của hệ thống phầnmềm cần xây dựngUML hỗ trợ một số lược đồ giúp môUML hỗ trợ một số lược đồ giúp môtả khía cạnh động: cộng tác, tuần tự,trạng thái, hành độngMiê tả hí h á th ộ tí h à tá
Các thành phầnCác thiết bị
Miêu tả chính xác thuộc tính và tácvụ, bổ sung một số lớp thiết kếhoàn thiện khía cạnh tĩnhThiết lập các package tạo thành kiến
trúc phần mềm
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 201201
HIỆN THỰC VÀ TRIỂN KHAIHIỆN THỰC VÀ TRIỂN KHAI
Các thành phầnCác thiết bị
Giới thiệuGiới thiệuệệ
•• CầnCần phảiphải xâyxây dựngdựng chươngchươngt ìnht ình chạchạ đượcđược từtừ kếtkết qủaqủa củacủatrìnhtrình chạychạy đượcđược từtừ kếtkết qủaqủa củacủagiaigiai đoạnđoạn thiếtthiết kếkế
•• CácCác lớplớp sẽsẽ đượcđược cụcụ thểthể hoáhoápp ợợ ụụvàovào cáccác thànhthành phầnphần phầnphần mềmmềmnhưnhư thếthế nàonào vàvà bằngbằng ngônngônngữngữ lậplập trìnhtrình gìgì ??ngữngữ lậplập trìnhtrình gìgì ??
•• ChươngChương trìnhtrình sẽsẽ đượcđược càicài đặtđặtrara saosao trêntrên tàitài nguyênnguyên tínhtínhggtoántoán ??
203203Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Thành phần (Component)Thành phần (Component)p ( p )p ( p )
•• ThànhThành phầnphần ((componentcomponent)) biểubiểu diễndiễn mộtmột phầnphầnhiệnhiện thựcthực nàonào đóđó củacủa hệhệ thốngthống
•• MộtMột sốsố stereotypestereotype quyquy ướcước trướctrước::– <<file>>: mã nguồn hay dữ liệu– <<executable>>: chương trình chạy được
ế– <<library>>: thư viện liên kết tĩnh hay động– <<document>>: tài liệu được thiết lập trong quá trình
phát triểnphát triển– <<table>>: bảng cơ sở dữ liệu
204204Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Thành phần (Component)Thành phần (Component)p ( p )p ( p )
•• ThànhThành phầnphần phầnphần mềmmềm ((softwaresoftware componentcomponent))baobao gồmgồm– Mã nguồn: *.cpp, *.c, *.pas, *.java, *.bas
ố– Mã đối tượng: *.obj– Mã nhị phân: *.class
Ch ơ t ì h th thi * dll *– Chương trình thực thi: *.dll, *.exe
•• ThànhThành phầnphần phầnphần mềmmềm cócó thểthể tồntồn tạitại trongtrong thờithờigiangian biênbiên dịchdịch thờithời giangian liênliên kếtkết chươngchương trìnhtrìnhgiangian biênbiên dịch,dịch, thờithời giangian liênliên kếtkết chươngchương trìnhtrìnhhoặchoặc thờithời giangian thựcthực thithi
205205Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Lược đồ thành phầnLược đồ thành phầnợ pợ p
•• LượcLược đồđồ thànhthành phầnphần làlà mộtmột đồđồ thịthị gồmgồm cáccác thànhthành phầnphầnếế ốố ớớ ởở ệệ ộộkếtkết nốinối vớivới nhaunhau bởibởi quanquan hệhệ phụphụ thuộcthuộc
•• KýKý hiệuhiệu củacủa thànhthành phầnphần cócó thểthể baobao gồmgồm mộtmột sốsố hìnhhình tròntrònbiểubiểu diễndiễn cáccác giaogiao tiếptiếp vàvà chứachứa cáccác lớplớp màmà nónó cụcụ thểthể hoáhoábiểubiểu diễndiễn cáccác giaogiao tiếptiếp vàvà chứachứa cáccác lớplớp màmà nónó cụcụ thểthể hoáhoá
Component-name Interface-name
Class-name
206206Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Lược đồ thành phần Lược đồ thành phần –– Ví dụVí dụợ pợ p ụụ
Ví dụ: lược đồ thành phần thể hiện một sốVí dụ: lược đồ thành phần thể hiện một số modulemodule mãmãVí dụ: lược đồ thành phần thể hiện một số Ví dụ: lược đồ thành phần thể hiện một số modulemodule mã mã
nguồn của chương trình hiển thị bề mặt địa hìnhnguồn của chương trình hiển thị bề mặt địa hình
GeoMap<<file>>
FieldMap<<file>><<file>>
Isoquant
FieldMap
MapCurve<<file>>
q
Fracture
207207Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
FractureMapCurve
Lược đồ thành phần Lược đồ thành phần –– Ví dụVí dụợ pợ p ụụ
Ví dụ: lược đồ thành phần thể hiện thời gian thực thi củaVí dụ: lược đồ thành phần thể hiện thời gian thực thi củaVí dụ: lược đồ thành phần thể hiện thời gian thực thi của Ví dụ: lược đồ thành phần thể hiện thời gian thực thi của
chương trình hiển thị bề mặt địa hìnhchương trình hiển thị bề mặt địa hình
cbsLoader12_dp.dll<<library>>
op12_dp.dll<<library>>
FieldVis.exe<<executable>>
IFL0.dlllib
Cosmo3D12.dll<<library>>
MFC42.dll
208208Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
<<library>> <<library>>
Lược đồ thành phần Lược đồ thành phần –– Ví dụVí dụợ pợ p ụụ
Ví dụ: lược đồ thành phần của hệ thống đăng ký môn họcVí dụ: lược đồ thành phần của hệ thống đăng ký môn họcVí dụ: lược đồ thành phần của hệ thống đăng ký môn họcVí dụ: lược đồ thành phần của hệ thống đăng ký môn học
People<<file>> DatabaseStudentInfo
Register<<file>>
<<file>> Database
RegisterForm
PeopleInfo LectureInfo
<<file>> RegisterForm
Index.shtml
Login<<file>>
209209Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
<<page>>LoginForm
Gán các lớp vào các thành phầnGán các lớp vào các thành phầnp pp p
•• KhiKhi thiếtthiết lậplập cáccác thànhthành phầnphần mãmã nguồn,nguồn, chúchú ýý gángán((bindbind)) cáccác lớplớp thiếtthiết kếkế vàvà chọnchọn ngônngôn ngữngữ lậplập trìnhtrình– Gán lớp FieldMap vào thành phần FieldMap (C++)– Gán lớp MapCurve, Isoquant và Fracture vào thành
phần MapCurve– Gán lớp PeopleInfo StudentInfo LectureInfo và– Gán lớp PeopleInfo, StudentInfo, LectureInfo và
Database vào thành phần People (Java)– Gán lớp và LoginForm vào thành phần Login (Java)
•• KýKý hiệuhiệu củacủa thànhthành phầnphần chứachứa kýký hiệuhiệu củacủa lớplớpđượcđược gángán
210210Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
•• ChúChú ýý:: componentcomponent ≠≠ packagepackage
Sinh mã nguồn Sinh mã nguồn –– Sourse code generationSourse code generationgg gg
•• DựaDựa vàovào đặcđặc tảtả lớplớp đểđể viếtviết mãmã chocho từngtừngthànhthành phầnphần mãmã nguồnnguồn theotheo ngônngôn ngữngữthànhthành phầnphần mãmã nguồnnguồn theotheo ngônngôn ngữngữlậplập trìnhtrình đãđã chọnchọn
•• ViếtViết mãmã sườnsườn làlà côngcông việcviệc hơihơi nhàmnhàmchánchán ⇒⇒ cócó thểthể đượcđược tựtự độngđộng hoáhoá bởibởichánchán ⇒⇒ cócó thểthể đượcđược tựtự độngđộng hoáhoá bởibởicáccác côngcông cụcụ CASECASE
211211Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Node triển khaiNode triển khai
•• NodeNode làlà mộtmột thiếtthiết bịbị vậtvật lýlý cócó khảkhả năngnăng tínhtính toán,toán, baobaoồồ áá íí áá ếế éégồmgồm:: máymáy tính,tính, máymáy in,in, thiếtthiết bịbị quétquét cardcard,, routerrouter……
•• NodeNode đượcđược mômô tảtả ởở cảcả 22 dạngdạng:: dạngdạng lớplớp vàvà dạngdạng instanceinstance•• NodeNode đượcđược kýký hiệuhiệu nhưnhư hìnhhình hộphộp baba chiềuchiều•• NodeNode đượcđược kýký hiệuhiệu nhưnhư hìnhhình hộphộp baba chiềuchiều•• CácCác minhminh dụdụ củacủa thànhthành phầnphần cócó thểthể sốngsống trongtrong mộtmột minhminh
dụdụ nodenodeụụ
Dell Server of 600: Pentium III 600 Dell Pentium III
600
212212Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Kết nối giữa các nodeKết nối giữa các nodegg
Có thể chỉ ra quan hệ liên kết giữa cácCó thể chỉ ra quan hệ liên kết giữa các nodenode để mô tả cấuđể mô tả cấuCó thể chỉ ra quan hệ liên kết giữa các Có thể chỉ ra quan hệ liên kết giữa các nodenode để mô tả cấu để mô tả cấu
hình kết nối (hình kết nối (connectionconnection))
:Pentium II 450
<<TCP/IP>>450
:SiliconGraphics
:Sun Ultra1
<<TCP/IP>>
:Pentium III 600
213213Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Lược đồ triển khaiLược đồ triển khaiợợ
•• LượcLược đồđồ triểntriển khaikhai chocho phépphép miêumiêu tảtả cáchcách càicài đặtđặt cáccácàà ầầ êê ááthànhthành phầnphần thựcthực thithi trêntrên cáccác nodenode
•• VíVí dụdụ:: hệhệ thốngthống đăngđăng kýký mônmôn họchọc quaqua WEBWEB
Client: Pentium MMX 200Java WEB Server: Pentium III 600
<<TCP/IP>>
Index.shtml<< >>
CheckApplet<<page>> <<applet>>
214214Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Lược đồ triển khaiLược đồ triển khaiợợ
•• VíVí dụdụ:: chươngchương trìnhtrình hiểnhiển thịthị bềbề mặtmặt địađịa hìnhhình
WindowsNT workstation: Pentium II 450
cbsLoader12_dp.dll<<library>>op12_dp.dll
Pentium II 450
FieldVis.exe<<executable>>
<<library>><<library>>
IFL0.dll<<library>>
executable
Cosmo3D12.dll<<library>>
MFC42.dll<<library>>
215215Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Tổng kếtTổng kếtgg
•• HiệnHiện thựcthực vàvà triểntriển khaikhai tậptập trungtrung vàovàoệệ ựự ậpập ggxâyxây dựngdựng cáccác thànhthành phầnphần chạychạy đượcđượchoặchoặc cáccác thưthư viện,viện, modulemodule mãmãnguồnnguồn trangtrang HTMLHTML dạngdạng nhịnhị phânphânnguồn,nguồn, trangtrang HTML,HTML, dạngdạng nhịnhị phânphân......
•• CácCác thànhthành phầnphần mãmã nguồnnguồn cụcụ thểthểhoáhoá mộtmột sốsố lớplớp thiếtthiết kếkế vàvà cócó thểthể
ằằđượcđược viếtviết bằngbằng cáccác ngônngôn ngữngữ lậplậptrìnhtrình kháckhác nhaunhau
•• CuốiCuối cùngcùng triểntriển khaikhai cáccác thànhthành phầnphần•• CuốiCuối cùngcùng triểntriển khaikhai cáccác thànhthành phầnphầnchạychạy đượcđược trêntrên cáccác thiếtthiết bịbị tínhtính toántoán
216216Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected]
Kiểm nghiệm phần mềmKiểm nghiệm phần mềm
Kỹ thuật kiểm tra phần mềmKiể t á đ ờ th thi độ lậKiểm tra các đường thực thi độc lậpChiến thuật kiểm tra phần mềmAlpha, Beta testing
Tại sao phải kiểm tra phần mềmTại sao phải kiểm tra phần mềm
Mặc dù được tự động hoá mộtặ ợ ự ộ g ộphần bởi các công cụ CASE, rấtnhiều công đoạn trong quá trìnhsản xuất phần mềm vẫn được thựchiện bởi con người
vẫn có khả năng xảy ra lỗi.Lỗi có thể xảy ra trong tất cả cácy ggiai đoạn: phân tích yêu cầu, thiếtkế, mã hoá
Do đó phải kiểm nghiệm chươngp g ệ gtrình trước khi chính thức sử dụng
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 218218
Một số quan điểm – khái niệmMột số quan điểm khái niệm
Kiểm nghiệm phần mềm là hoạt động thực thig ệ p ạ ộ g ựchương trình với mục đích tìm ra lỗi phê phán,không phải để mang tính xây dựngPhân loại:Phân loại:
Kiểm nghiệm black-box: kiểm tra các chức năng cụ thểcủa phần mềm, không quan tâm cấu trúc bên trong,thường áp d ng cho những mod le lớnthường áp dụng cho những module lớn.Kiểm nghiệm white-box: kiểm tra cấu trúc điều khiển
bên trong chương trình, thường dùng cho những nhữngmodule nhỏ.
Mỗi loại kiểm nghiệm có khả năng tìm ra những nhómlỗi khác nhau nên kết hợp cả hai
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 219219
ợp
Mục tiêu của kiệm nghiệm phần mềmMục tiêu của kiệm nghiệm phần mềm
Mục tiêu của kiểm nghiệm phần mềm là tìm ra lỗi (nếuMục tiêu của kiểm nghiệm phần mềm là tìm ra lỗi (nếucó) với chi phí thấp nhất.Kiểm nghiệm phần mềm giúp
Phát hiện được lỗi trong chương trình (nếu có).Chứng minh được phần mềm hoạt động đúng như đãthiết kếthiết kế.
Chứng minh phần mềm được viết đúngChứng minh được phần mềm đáp ứng yêu cầu của userC ứ g được p ầ ề đáp ứ g yêu cầu của use
Góp phần chứng minh chất lượng của phần mềm.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 220220
Mục tiêu của kiệm nghiệm phần mềmMục tiêu của kiệm nghiệm phần mềm
Quá trình kiểm nghiệm phần mềm là tốt khiQuá trình kiểm nghiệm phần mềm là tốt khiCó khả năng tìm ra lỗi cao.Không dư thừa.Biết chọn lọc: chỉ kiểm nghiệm những phần nào có khả
năng tìm ra lỗi đặc trưng.Khô á hứ t ũ khô á đ iảKhông quá phức tạp cũng không quá đơn giản.
Chú ý: Kiểm nghiệm phần mềm không khẳng địnhChú ý: Kiểm nghiệm phần mềm không khẳng địnhđược phần mềm không còn khiếm khuyết, chỉ khẳngđịnh được phần mềm có lỗi và giúp giảm thiểu lỗi
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 221221
Các nguyên lý kiểm nghiệm phần mềmCác nguyên lý kiểm nghiệm phần mềm
Việc kiểm nghiệm nên hướng về yêu cầu của kháchViệc kiểm nghiệm nên hướng về yêu cầu của kháchhàngNên được hoạch định trước một thời gian dài.ÁÁp dụng nguyên lý Pareto (nguyên tắc 80-20):
80% lỗi có nguyên nhân từ 20% các module cô lập vàkiểm tra những module khả nghi nhấtkiểm tra những module khả nghi nhất.Nên tiến hành từ nhỏ đến lớn: bắt đầu từ nhữngmodule riêng biệt rồi sau đó tích hợp các module lại.Không thể kiểm nghiệm triệt để một phần mềm.Nên được thực hiện bởi những đối tượng KHÔNG thami à á t ì h hát t iể hầ ề
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 222222
gia vào quá trình phát triển phần mềm.
Phương pháp kiểm nghiệm – Test casePhương pháp kiểm nghiệm Test case
Thiết lập các test case – vận hành thử - so sánh kếtThiết lập các test case vận hành thử so sánh kếtquảKhái niệm test-case
Dữ liệu inputThao tác kiểm nghiệmDữ liệ t t h đá ứ đ i ủ h t ì hDữ liệu output hay đáp ứng mong đợi của chương trình
Test-case cho kiểm nghiệm black-box: chủ yếu dựavào các yêu cầu cụ thể của chức năng phần mềm.vào các yêu cầu cụ thể của chức năng phần mềm.Test-case cho kiểm nghiệm white-box: chủ yếu dựavào cấu trúc điều khiển của phần mềm vấn đề đặt
ố lượ t t ầ thiết là á lớ
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 223223
ra: số lượng test-case cần thiết là quá lớn
Kiểm nghiệm các đường độc lập cơ bảnKiểm nghiệm các đường độc lập cơ bản
Kiểm nghiệm white-box dựa vào cấu trúc điều khiểnKiểm nghiệm white box dựa vào cấu trúc điều khiểncủa thiết kế thủ tục để sinh các test-case với tiêu chí
Kiểm nghiệm các đường độc lập cơ bản là một trongh h á h kiể hiệ hi bnhững phương cách kiểm nghiệm white-box
Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗiTất cả các đường thực thi độc lập được thử qua ít nhấtTất cả các đường thực thi độc lập được thử qua ít nhấtmột lầnThử các điều kiện rẽ nhánh ở cả 2 nhánh true và falseThử qua vòng lặp tại biên cũng như bên trongThử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 224224
Đồ thị dòng chảyĐồ thị dòng chảy
Mỗi node hình tròn biểu diễn một hoặc một vài tác vụMỗi node hình tròn biểu diễn một hoặc một vài tác vụ(hơi khác so với lưu đồ thuật giải)Cạnh có hướng miêu tả đường thực thi
Đồ thị dòng chảy được xây dựng từ lưu đồ thuật giải
sequence if while caseuntil
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 225225
Xây dựng đồ thị dòng chảy – Ví dụXây dựng đồ thị dòng chảy Ví dụ
11
11
2
2,3
2
34,5
6
7 8
4
5
6
87
9
587
10
9 10
11
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 226226
11
11
Xây dựng đồ thị dòng chảy – Ví dụXây dựng đồ thị dòng chảy Ví dụ
procedure: DoSomething 1p g1: do while x=02: if y=0 then3: z=0;
1
2
3: z=0;4: elseif k=0 then5: z=1;
34
6 56: else x=1;7: endif;
endif;7
;8: enddo9: end
8
9
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 227227
9
Xây dựng đồ thị dòng chảyXây dựng đồ thị dòng chảy
Phải phân rã tất cả các điều kiện phức trở thành cácPhải phân rã tất cả các điều kiện phức trở thành cácđiều kiện đơnMỗi node mô tả một điều kiện đơn được gọi là
di tpredicate
a a
b
x
b
y x
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 228228
if a and b then y else x while a or b do x
Xây dựng đồ thị dòng chảy – ví dụXây dựng đồ thị dòng chảy ví dụ
procedure AnalyzeTriangleprocedure AnalyzeTriangle
5
a = c
2
4
6
7a<b+c
a = c
1
6
8
9
c > 0 a = b
b = ca2=b2+c2
1012
3
911
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 229229
Các đường độc lập cơ bảnCác đường độc lập cơ bản
Đường thực thi?Đường thực thi?Đường thực thi cơ bảnCác đường thực thi độc lập cơ bảnTừ node bắt đầu đến node kết thúc, các đường thựcthi cơ bản được liệt kê theo một thứ tự nào đó để đảmbảo rằng: đường đang liệt kê ít nhất đi qua một cạnhbảo rằng: đường đang liệt kê ít nhất đi qua một cạnhchưa được duyệt qua bởi các đường đã liệt kê trước đóTổng số đường thực thi cơ bản độc lập nhau được tínhbằngV = P + 1; trong đó P là số node phân nhánh(predicate)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 230230
(predicate)
Các đường độc lập cơ bản – ví dụCác đường độc lập cơ bản ví dụ
Đối với chương trình con 1gDoSomethingTổng số đường :V = 3 + 1 = 4
1
2V 3 + 1 4Đường 1: 1-9Đường 2: 1-2-3-8-1…Đườ 3 1 2 4 5 7 8 1
34
6 5Đường 3: 1-2-4-5-7-8-1…Đường 4: 1-2-4-6-7-8-1…
Chú ý: dấu 3 chấm (…) mang ý nghĩaô â ừ ó ó ể
7
“không quan tâm”, từ đó có thể đitheo bất kỳ cạnh nào bởi vì cáccạnh sau đó đã được duyệt qua rồi
8
9
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 231231
9
Các đường độc lập cơ bản – ví dụCác đường độc lập cơ bản ví dụ
Đối với chương trình con 5gAnalyzeTriangleTổng số đường :V = 6 + 1 = 7
4
5
7a<b+
a = c
V = 6 + 1 = 7Đường 1: 1-3-12Đường 2: 1-2-3-12 1
26
7
8
c > 0
c
a = ba2=b2
1012g
Đường 3: 1-2-4-5-12Đường 4: 1-2-4-6-7-12Đườ 5 1 2 4 6 8 7 12
1
3
8
9b = c
a2=b2
+c2
11
Đường 5: 1-2-4-6-8-7-12Đường 6: 1-2-4-6-8-9-10-12Đường 7: 1-2-4-6-8-9-11-12
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 232232
Đường 7: 1 2 4 6 8 9 11 12
Thiết lập các test caseThiết lập các test case
Thiết lập một test-case cho mỗi đường thực thi cơ bảnập ộ g ựDựa vào thuật giải để tìm ra một dữ liệu input, sau đó tínhra dữ liệu output hay đáp ứng mong đợi của thuật giảiChú ý: có thể không tạo ra được test-case cho một đườngChú ý: có thể không tạo ra được test case cho một đườngthực thi nào đóVí dụ Sinh test-case cho chương trình con AnalyzeTriangleTest-case cho đường 1:
Input: a = 3, b = 2, c = 0Output mong đợi: type = “Error”
Test-case cho đường 2:Input: a = 17, b = 5, c = 4Input: a 17, b 5, c 4Output mong đợi: type = “Error”
Test-case cho đường 3:Input: a = 6, b = 6, c = 6O t t đợi t “E il t l”
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 233233
Output mong đợi: type = “Equilateral”
Tổng kếtTổng kết
Mục tiêu của kiểm nghiệm phần mềm là tìm ra lỗiMục tiêu của kiểm nghiệm phần mềm là tìm ra lỗiHai loại kiểm nghiệm: white-box và black-box.Kiểm nghiệm các đường độc lập cơ bản dùng trongkiểm nghiệm white-box, bao gồm các bước
Thiết lập đồ thị dòng chảyLiệt kê á đ ờ th thi độ lậ bảLiệt kê các đường thực thi độc lập cơ bảnSinh các test-case cho các đường thực thi đóThực hiện các test case và kiểm tra kết quảThực hiện các test case và kiểm tra kết quả
Kiểm nghiệm Black-box thường dùng trong bước kiểmnghiệm tính năng của phần mềm
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 234234
Chiến thuật kiểm nghiệmChiến thuật kiểm nghiệmphần mềmphần mềmphần mềmphần mềm
Verification & ValidationU it t t & I t ti t tUnit test & Integration testKiểm nghiệm hướng đối tượngNghệ thuật gỡ rối
Khái niệmKhái niệm
Chiến thuật kiểm tra phần mềm tích hợp các phương pháptạo ra test-case trở thành một chuỗi các bước có thứ tự để có thểkiểm nghiệm phần mềm thành công với chi phí thấp.Bao gồm các công việcBao gồm các công việc
Lập kế hoạch kiểm nghiệmSinh test-case
h hiệ kiể hiệ h hậ kế ủ à đá h iáThực hiện kiểm nghiệm, thu thập kết qủa và đánh giáVerification: các hành động để đảm bảo cho phần mềm được hiệnthực đúng theo một chức năng cụ thể nào đó “Are we buildingthe product right ?”Validation: các hành động để đảm bảo cho phần mềm được xâydựng theo đúng yêu cầu của khách hàng “Are we building the
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 236236
dựng theo đúng yêu cầu của khách hàng Are we building theright product ?”
Một chiến thuật kiểm nghiệm phổ biếnMột chiến thuật kiểm nghiệm phổ biến
Phân tích toàn bộ hệ thống Kiểm nghiệm toàn bộ hệ thống
Phân tích yêu cầu Kiểm nghiệm tính năng
Thiết kế Kiểm nghiệm tích hợp
Mã hóa Kiểm nghiệm đơn vị (module)
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 237237
Một chiến thuật kiểm nghiệm phổ biếnMột chiến thuật kiểm nghiệm phổ biến
Bắt đầu tại từng module rồi tích hợp lớn dần đến toànBắt đầu tại từng module rồi tích hợp lớn dần đến toànbộ hệ thống.Các kỹ thuật khác nhau được sử dụng thích hợp tại cáci i đ khá hgiai đoạn khác nhau.
Kiểm nghiệm có thể được tiến hành bởi người pháttriển phần mềm, nhưng đối với các dự án lớn thì việctriển phần mềm, nhưng đối với các dự án lớn thì việckiểm nghiệm phải được tiến hành bởi một nhóm độclập.ể h ệ à ử lỗ là á h độ độ lậKiểm nghiệm và sửa lỗi là các hoạt động độc lập
nhưng việc sửa lỗi phải phù hợp với các chiến thuậtkiểm nghiệm.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 238238
g ệ
Kiểm nghiệm từng moduleKiểm nghiệm từng module
Tiến hành kiểm nghiệm trên từng đơn vị nhỏ nhất củaTiến hành kiểm nghiệm trên từng đơn vị nhỏ nhất củaphần mềm, đó là module mã nguồn, sau khi đã thiếtkế, mã hoá và biên dịch thành côngTh ờ dù kỹ th ật kiể hiệ hit bThường dùng kỹ thuật kiểm nghiệm white-boxCó thể tiến hành kiểm nghiệm cùng lúc nhiều module.Một số vấn đề trong việc xây dựng các test caseMột số vấn đề trong việc xây dựng các test case
Test case nào?Dữ liệu đầu vào và đầu ra có tử đâu?ữ ệu đầu vào và đầu a có tử đâu?Tính độc lập/phụ thuộc hoạt động của các module
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 239239
Kiểm nghiệm moduleKiểm nghiệm module
interfacelocal data structures
driver
Module……….~~~~~~
local data structuresboundary conditionsindependent paths
~~~~~~~~~~~~
error handling paths
test-stub stub
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 240240
cases
Kiểm nghiệm moduleKiểm nghiệm module
Mỗi module mã nguồn không phải là một chương trìnhg g p ộ ghoàn chỉnh và đôi khi phải gọi các module chưa đượckiểm nghiệm khác có thể phải thiết lập drivervà/hoặc stub: phí tổn khá lớn (70%)/ ặ p ( )Driver là một chương trình chính có nhiệm vụ nhậndữ liệu kiểm nghiệm, chuyển dữ liệu đó xuống chomodule để kiểm tra và in ra các kết quả kiểm tramodule để kiểm tra và in ra các kết quả kiểm tratương ứng.Stub thay thế các module được gọi bởi module đangkiểm trakiểm tra.
Làm thế nào để giảm các chi phí tạo driver hay stub
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 241241
g p ạ y
Kiểm nghiệm tích hợpKiểm nghiệm tích hợp
Từng module mã nguồn đã hoạt động đúng. Liệu khiTừng module mã nguồn đã hoạt động đúng. Liệu khikết hợp chúng lại thành một nhóm lớn chúng có hoạtđộng đúng không ?Phải tiế hà h kiể hiệ tí h h để hát hiệ lỗiPhải tiến hành kiểm nghiệm tích hợp để phát hiện lỗiliên quan đến giao tiếp giữa các module.
Tránh tích hợp kiểu big-bang: tất cả các module đượckết hợp lại, và toàn bộ chương trình sẽ được kiểm
h ệ ộ lúnghiệm một lúcNên tích hợp tăng dần: từ trên xuống hoặc từ dưới lên
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 242242
Tích hợp từ trên xuốngTích hợp từ trên xuống
Module chính được dùng như là driver, và stub đượcModule chính được dùng như là driver, và stub đượcthay thế bởi các module con trực tiếp của của modulechính này.T ỳ th ộ à á h tí h h th hiề â (d thTuỳ thuộc vào cách tích hợp theo chiều sâu (depth-first) hoặc chiều ngang(breath-first), mỗi stub conđược thay thế một lần bởi module tương ứng đã kiểmợ y ộ g gnghiệm.Tiến hành kiểm nghiệm khi có sự thay thế mớiế hà h k ể h ệ hồ để há h ệ á lỗTiến hành kiểm nghiệm hồi quy để phát hiện các lỗi
khác trong từng module
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 243243
Tích hợp từ trên xuốngTích hợp từ trên xuống
M1
M MM M3 M4M2
M7M5 M6
Tích hợp kiểu từ trên xuống theo hìnhthức depth-firstTiết kiệm được chi phí tạo các driverM8
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 244244
Tiết kiệm được chi phí tạo các driver
Tích hợp từ dưới lênTích hợp từ dưới lên
Các module mức thấp nhất được kết hợp thành cácCác module mức thấp nhất được kết hợp thành cácnhóm thể hiện một chức năng con đặc biệt của phầnmềm.Một d i đ t để th tá á t tMột driver được tạo ra để thao tác các test-caseCác module được kiểm nghiệm theo từng nhóm(Cluster): là nhóm các module mà module phía trên(Cluster): là nhóm các module mà module phía trêncần đến khi kiểm nghiệmDriver được bỏ đi và các nhóm module được kết hợpdầ lê hí ê đồ hâ ấ ủ hdần lên phía trên trong sơ đồ phân cấp của chươngtrình.Tiết kiệm được chi phí tạo các stub
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 245245
Tiết kiệm được chi phí tạo các stub
Tích hợp từ dưới lênTích hợp từ dưới lên
MoMo
Ma Mb
D2D1 D3
1cluster
clus
ter
cluster 2
r 3
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 246246
Kiểm nghiệm hồi quyKiểm nghiệm hồi quy
Việc kết hợp các module lại với nhau có thể ảnh hưởngViệc kết hợp các module lại với nhau có thể ảnh hưởngđến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chiasẻ trong một số moduleĐiề đó là lộ ột ố lỗi khô thể hát hiệ đĐiều đó làm lộ ra một số lỗi không thể phát hiện đượckhi tiến hành kiểm nghiệm theo đơn vịPhải kiểm nghiệm hồi quy khi tích hợpPhải kiểm nghiệm hồi quy khi tích hợpKiểm nghiệm hồi quy có thể được tiến hành thủ côngbằng cách thực hiện lại các test-case đã tạo ra. Hoặcó hể dù ộ ô l b k để hcó thể dùng một công cụ capture-playback để thực
hiện tự động
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 247247
Kiểm nghiệm tính năngKiểm nghiệm tính năng
Kiểm nghiệm tính năng hiểu theo cách đơn giảng ệ g gnhất là: kiểm tra các chức năng của phần mềm đápứng được nhu cầu của khách hàng đã được xác địnhtrong văn bản đặc tả yêu cầu của phần mềmg ặ y p
Áp dụng kỹ thuật black-box
Kiểm nghiệm tính năng bao gồmXem xét lại cấu hình phần mềm theo lược đồ triển khaiXem xét lại cấu hình phần mềm theo lược đồ triển khaiKiểm nghiệm alphaKiểm nghiệm beta
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 248248
Kiểm nghiệm tính năngKiểm nghiệm tính năng
Kiểm nghiệm alphaKiểm nghiệm alphaĐược tiến hành ngay tại nơi sản xuất phần mềm.N hà phát triển phần mềm sẽ quan sát người sử dụngp p q g ụ gdùng sản phNm và ghi nhận lại những lỗi phát sinh để sửachữa.
Kiể hiệ b tKiểm nghiệm betaPhần mềm được kiểm tra bên ngoài phạm vi của đơn vịsản xuấtsản xuất.Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lạicho nhà phát triển sửa chữa.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 249249
Kiểm nghiệm hướng đối tượngKiểm nghiệm hướng đối tượng
Về cơ bản chiến thuật kiểm nghiệm hướng đối tượngVề cơ bản chiến thuật kiểm nghiệm hướng đối tượngcũng theo thứ tự giống như kiểm nghiệm cổ điển:
ểểKiểm nghiệm đơn vịKiểm nghiệm đơn vị
ểểKiểm nghiệm tích hợpKiểm nghiệm tích hợp
Kiểm nghiệm chức năngKiểm nghiệm chức năngKiểm nghiệm chức năngKiểm nghiệm chức năng
Kiểm nghiệm toàn bộ hệ thốngKiểm nghiệm toàn bộ hệ thống
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 250250
Kiểm nghiệm toàn bộ hệ thốngKiểm nghiệm toàn bộ hệ thống
Kiểm nghiệm hướng đối tượngKiểm nghiệm hướng đối tượng
Không thể tách rời từng tác vụ của đối tượng/lớp đểKhông thể tách rời từng tác vụ của đối tượng/lớp đểkiểm nghiệm
Tác vụ được đóng bao trong lớpCác lớp con có thể override một tác vụ nào đó
Kiể hiệ đơ ị hướ đối tượ tậ t àKiểm nghiệm đơn vị hướng đối tượng tập trung vàocác lớp kiểm nghiệm hành vi của lớp
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 251251
Kiểm nghiệm tích hợp hướng đối tượngKiểm nghiệm tích hợp hướng đối tượng
Khái niệm sơ đồ phân cấp không còn nhiều ý nghĩaKhái niệm sơ đồ phân cấp không còn nhiều ý nghĩatrong chương trình hướng đối tượng kiểm nghiệmtích hợp theo cách khác
Hai hình thức kiểm nghiệm tích hợp hướng đối tượngKiểm nghiệm trên cơ sở thread: tích hợp các lớp tạoKiểm nghiệm trên cơ sở thread: tích hợp các lớp tạothành một thread để phục vụ cho một input nào đó củachương trìnhKiểm nghiệm trên cơ sở sử dụng: các lớp client sẽ được
tích hợp để sử dụng dịch vụ nào đó cung cấp bởi các lớpserver
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 252252
server
Kiểm nghiệm theo kịch bảnKiểm nghiệm theo kịch bản
Dựa vào các use-case để soạn ra các kịch bảnDựa vào các use case để soạn ra các kịch bảnVí dụ: một kịch bản cho hệ thống đăng ký môn họcqua WEB
1. Login với username = “e59306547”, password = “6547”2. Chọn chức năng đăng ký môn học3 Ch 5 hó ô h ủ 5 ô CNPM AI XLTHS3. Chọn 5 nhóm môn học của 5 môn: CNPM, AI, XLTHS,
PTTK, XLSS trong đó có 2 nhóm trùng thời khoá biểu4. Nhấn nút Submit4. Nhấn nút SubmitChương trình phải báo lỗi và liệt kê 2 nhóm bị trùng thời
khoá biểu
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 253253
Nghệ thuật gỡ rối - DEBUGNghệ thuật gỡ rối DEBUG
Gỡ rối là một quá trình nhằm loại bỏ các lỗi được phátGỡ rối là một quá trình nhằm loại bỏ các lỗi được pháthiện trong quá trình kiểm tra.
Gỡ rối được thực hiện như là một kết quả của việckiểm tra: lỗi phát hiện được tìm kiếm nguyên nhân
sửa lỗisửa lỗi
Có 3 hình thức gỡ rối: brute force, loại trừ nguyênnhân và theo vết. Nên dùng kết hợp cả 3 hình thứcnày.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 254254
Nghệ thuật gỡ rốiNghệ thuật gỡ rối
Gỡ rối là công việc khókhăn và dễ gây tâm lýchán nản bởi nguyên
ỗg
nhân gây ra lỗi nhiều khilại mơ hồ: do timeout, dođộ chính xác, do chủộ ,quan lập trình...
Khả năng gỡ rối gần nhưKhả năng gỡ rối gần nhưlà bẩm sinh của mỗingười
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 255255
Brute ForceBrute Force
Là phương pháp phổ biến nhất nhưng lại ít hiệu quảp g p p p g ạ ệ qnhất cho việc phát hiện nguyên nhân gây lỗi phầnmềm.Triết lý của phương pháp này là: “Hãy để máy tính tìmTriết lý của phương pháp này là: Hãy để máy tính tìmra lỗi”.Có 3 cách thực hiện:
ấ d li b h đểLấy dữ liệu trong bộ nhớ để xem xét.Dùng run-time trace để tìm lỗi.Dùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra mànDùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra mànhình.
Áp dụng phương pháp này khi tất cả các phương phápkhác đều thất bại
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 256256
khác đều thất bại.
Loại trừ nguyên nhânLoại trừ nguyên nhân
Phương pháp này dựa trên nguyên tắc phân chia nhịPhương pháp này dựa trên nguyên tắc phân chia nhịphân.Cách thực hiện:
Khi một lỗi được phát hiện, cố gắng đưa ra một danhsách các nguyên nhân có thể gây ra lỗi.Danh sách này được nghiệm lại để loại bỏ dần cácDanh sách này được nghiệm lại để loại bỏ dần cácnguyên nhân không đúng cho đến khi tìm thấy mộtnguyên nhân khả nghi nhất.Khi đó dữ liệu kiểm nghiệm sẽ được tinh chế lại để tiếp
tục tìm lỗi.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 257257
Theo vếtTheo vết
Là một phương pháp gỡ lỗi khá phổ biến có thể dùngthành công trong các chương trình nhỏ nhưng khó ápd h đối ới á h t ì h ất lớdụng cho đối với các chương trình rất lớn.
Cách thực hiện: bắt đầu tại dòng mã nguồn có triệuCách thực hiện: bắt đầu tại dòng mã nguồn có triệuchứng lỗi thực hiện lần ngược trở lại từng dòng mãnguồn cho đến khi tìm thấy dòng gây ra lỗi.
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – [email protected] 258258
Kết thúc môn họcKết thúc môn họcKết thúc môn họcKết thúc môn học
Thi ối kỳ ?
Thiết
Thi cuối kỳ ?Giới thiệu-Phân tích
Thiết kế - Hiện thực/triển khaiThiếtThiết kế Hiện thực/triển khaiKiểm nghiệm - UML
Tất cả nội dung
Chúc mừng bạn đã hoàn tất môn họcChúc mừng bạn đã hoàn tất môn họcChúc mừng bạn đã hoàn tất môn học Chúc mừng bạn đã hoàn tất môn học Công Nghệ Phần Mềm !Công Nghệ Phần Mềm !