รายงานการฝกอบรม

Object-Oriented Software Development with UML

จดโดย

เขตอตสาหกรรมซอฟตแวรประเทศไทย (Software Park Thailand)

ณ อาคาร Software Park นนทบร

วนท 18-22 มถนายน 2555

ผจดท า

รองศาสตราจารยณฐพร เหนเจรญเลศ

อาจารย ดร.ขจตพรรณ มกระธช

สาขาวชาวทยาศาสตรและเทคโนโลย

โครงการนไดรบการสนบสนนจากทนพฒนาบคลากร 2555

2

1. ชอ นางสาวณฐพร .นามสกล เหนเจรญเลศ .อาย 45 .ป

ต าแหนง รองศาสตราจารย .ระดบ 9 และ.

ชอ นางสาวขจตพรรณ .นามสกล มกระธช .อาย 35 .ป

ต าแหนง อาจารย ดร. .ระดบ 6 .

สงกด สาขาวชาวทยาศาสตรและเทคโนโลย .โทร 025048191-3 .

ไป เขารวมฝกอบรมทางวชาการ .

เรอง Object-Oriented Software Development with UML .

ณ. Software park นนทบร .ตงแตวนท 18-22 มถนายน พ.ศ. 2555 .

รวมระยะเวลา 5 วน .

2. รายงานการฝกอบรม

(1) วธการฝกอบรม มการเรยนภาคทฤษฎและฝกปฏบตไปพรอมๆกน มการแบงกลมท า work shop กรณศกษาทวทยากรก าหนดให โดยท าการดาวนโหลดและตดตงซอฟตแวร

STARUML ซงเปนโอเพนซอรส เปนซอฟตแวรในการฝกอบรม

(2) สาระส าคญของการฝกอบรม เปนการอบรมทงภาคทฤษฎและภาคปฏบต เกยวกบการพฒนาระบบแบบ OOA โดยซอฟตแวร UML โดยเนอหาของการฝกอบรมแสดงไวในเอกสารรายงานทแนบดานทาย

(3) มผ เขารวมฝกอบรม ประมาณ 20 คน สวนใหญเปนผท างานบรษทเอกชนทเกยวของกบงานดานไอท และอาจารยจากมหาวทยาลย

(4) ประโยชนทไดรบ

(4.1) ประโยชนทผ รบทนไดรบ

3

- ไดรบความรใหมเกยวกบการพฒนาระบบเชงวตถ

- สามารถฝกหดใชซอฟตแวรและท ากรณศกษาตามทวทยากรก าหนดได

(4.2) ประโยชนทมหาวทยาลยไดรบ

- สามารถน าความรทไดไปใชกบการเรยนการสอนชดวชา 99702 การพฒนาระบบสารสนเทศ การบรหารโครงการและการประยกต ได

- สามารถน าโจทยกรณศกษาไปปรบใชเปนแบบฝกปฏบตส าหรบนกศกษาได

(5) ขอเสนอแนะ

เนองจากมหลกสตรประยกตดานเทคโนโลยสารสนเทศและการสอสารจ านวนหลายหลกสตรทจดขนโดยองคกรภายนอก ทางมหาวทยาลยควรพจารณาอนมตใหสาขาวชาวทยาศาสตรและเทคโนโลยสามารถเชญผทรงคณวฒภายนอกมาเปนวทยากรใหความรแกคณาจารยและบคลากรทสนใจในวชาการดงกลาว เพอการประหยดคาใชจายการลงทะเบยนทคอนขางสง และเปดโอกาสใหบคลากรอนๆ สามารถเขาฝกอบรมดวยได เนองจากการขออนมตไปฝกอบรมในปจจบนอนญาตใหเฉพาะบคลากร

ของแตละสาขาฯ สามารถลงทะเบยนและเขาฝกอบรมเดยวกนไดไมเกน 2 คน ท าใหขาดโอกาสในการแสวงหาความรใหมๆ โดยเฉพาะดานเทคโนโลยสารสนเทศและการสอสารทมการปรบเปลยนอยางรวดเรวตลอดเวลา

4

Object-Oriented Software Development with UML

ความเปนมาของUML

UML มาจากค าเตมวา “Unified Modeling Language” เปนการน าสญลกษณมาใชในยคท3 ของ

Object Oriented ในชวงป1994 – 1996 จม รมบอ (Jim Rumbaugh) น าทมวจยทบรษท General Electric

พฒนาแนวคดเรอง Object Modeling Technique (OMT) และในป 1994 ไอวาร จาคอบสน(Ivar Jacobson )

จากบรษท Ericsson ไดน าเสนอแนวความคดในเรองของ Use case เปนคนแรก ซงชวงนนมระเบยบวธทม

ลกษณะคลายคลงกนดงกลาวเกดขนมากมาย และในขณะเดยวกนกมรายละเอยดปลกยอยทแตกตางกน

ออกไป แนวความคดพนฐาน ทเหมอนกนถกแสดงดวยสญลกษณทตางกน ซงท าใหเกดความสบสนในการ

สอความหมาย องคการ OMG พยายามทจะสราง มาตรฐานขนมา เกรด บช (Grady Booch) พยายาม

ประสานงานอยางไมเปนทางการ ซงกไมประสบผลส าเรจแตอยางใด ตอมามการประชม OOPSLA ในป

1994 โดยมการประกาศวา Jim Rumbuagh ไดรวมกบ Grady Booch ท Rational Software เพอรวมกนพฒนา

ระเบยบวธของทตางคนตางคดขนดวยกน ในการประชม OOPSLA

ป 1995 Grady และ Jim ไดเตรยมการเผยแพรเปนครงแรกเกยวกบระเบยบวธทรวมกนพฒนา ในรป

เอกสาร Unified Method version 0.8 ทไดรบความสนใจเปนอยางมาก ในชวงนน Rational Software ไดเขา

ซอกจการของ Objectory และท าให Ivar Jacobson เขารวมใน Unified team ของ Grady และ Jim ดวย

ดงนน ในป 1996 Grady, Jim และ Ivar ไดด าเนนการพฒนาระเบยบวธในชอใหมวา Unified

Modeling Language (UML) ในเดอนมกราคมป 1997 หลายๆองคกรได เสนอขอเสนอ (Proposal) ทระบถง

มาตรฐานส าหรบการแลกเปลยนแบบจ าลองในระหวางแตละระเบยบวธ (Methods standard to facilitate the

interchange of models) ขอเสนอเหลานใหความส าคญกบ Meta-model และสญลกษณประกอบ (Optional

notations) บรษทRational Software กไดออกเอกสาร UML version 1.0 เพอเปนขอเสนอตอ OMG เชนกน

ขอเสนอตางๆ จงถกรวมเขาดวยกน และ OMG (Object Management Group) ไดพฒนามาตรฐาน OMG

อยางเปนท างการใน version 1.1 (Official OMG standard) นบแตนนเปนตนมา กลมงาน Revision Task

Force (RTF) น าโดย Cris Kobryn กไดด าเนนการพจารณาปรบปรงมาเปนล าดบ โดย version 1.2 นนเปน

การปรบปรงเพยงเลกนอย จนถง version 1.3 ซงไดน าเสนอสสาธารณะในป 1999 และนบวาเปนการ

ปรบปรงครงส าคญ

5

การวเคราะหและออกแบบระบบ

การวเคราะหระบบคอ การระบปญหาทเกดขน (what) เปนการวเคราะหโมเดลของหลกการทจะ

อ านวยความสะดวกในการท าความเขาใจกบระบบงานเดม โดยจะยงไมพจารณาเรองซอฟตแวรหรอ

โปรแกรมทจะน ามาใช และยงไมค านงถงสมรรถนะของระบบ การวเคราะหเปรยบไดกบเครองมอทชวยให

เขาใจปญหาและการท างานของระบบเดม

การออกแบบระบบ คอการอธบายวาการแกปญหาของระบบเดมจะท าอยางไร (how) เปนการจดท า

โมเดลเพอสนบสนนการพฒนาและตดตงระบบงานคอมพวเตอร หรออาจเปนการปรบปรงซอฟตแวรใน

ระบบเดม และการปรบปรงสมรรถนะของระบบงานเดมหรอซอฟตแวรระบบงานเดม การออกแบบเปน

กระบวนการทเปลยนการวเคราะหใหเปนคณลกษณะของซอฟตแวร ในการพฒนาซอฟตแวรไมควรใช

SDLC ควรน าหลกการ แนวปฏบตทดของวธวศวกรรมซอฟตแวร ทง 6 ขอมาประยกต

แนวปฏบตทดของวธวศวกรรมซอฟตแวร(Best Practices of Software Engineering) ประกอบดวย 6 ขอ ดงน

1. พฒนาแบบวนซ า (Develop Iterative) เปนการพฒนาซอฟตแวรทท าขนตอนทกขนตอนยอยซ า ๆ กนตงแตการเกบรวบรวมความตองการ การออกแบบ การเขยนโปรแกรมการทดสอบโปรแกรม และการบรณาการโปรแกรมเขาดวยกน ซงในการวนซ าแตละรอบจะชวยลดความเสยงทระบบจะลมเหลวลงไดมากกวาแบบวงจรพฒนาระบบ (SDLC) สามารถจดท ารายการสาเหตหลก (root causes) และค าตอบในการแกปญหา (solutions) ได เชน

Root Causes Solutions Insufficient requirement Enables and encourages user feedback Ambiguous Communications Serious misunderstandings evident early in the life

cycle Overwhelming Complexity Develop focuses on critical issues Subjective Assessment Objective Assessment thru testing

6

Undetected inconsistencies Inconsistencies detected early Poor testing Testing stars earlier Waterfall development Risks identified and addressed early

2. จดการความตองการของผใช (Manage User Requirements) เปนการรวบรวมความตองการของผใชจากการสมภาษณ และเอกสารทเกยวของ น ามาจดล าดบความส าคญและวเคราะหหนาทและขอจ ากด ประเมนการเปลยนแปลงและก าหนดผลกระทบทเกดจากการเปลยนแปลงนน ๆ ความตองการของผใชเปนสงทมการเปลยนแปลงไดตลอดเวลาในระหวางทพฒนาซอฟตแวร ความตองการเปนศนยกลางและเปนสงส าคญตอการพฒนาและองคประกอบหลาย ๆ องคประกอบของโครงการพฒนาฯ

3. ใชสถาปตยกรรมแยกเปนองคประกอบยอย ๆ (Use Component-Based Architectures) เปนการพฒนาซอฟตแวรโดยแยกระบบออกเปนองคประกอบยอย ๆ โดยองคประกอบดงกลาวสามารถท างานประสานรวมกนได โครงสรางซอฟตแวรทออกแบบตองค านงถง การใช หนาทการท างาน สมรรถนะการท างาน ความยดหยน การน ามาใชซ า ความสามารถในการท าความเขาใจ ประหยดคาใชจายและขอจ ากดของเทคโนโลยและสนทรยศาสตร

ซอฟตแวรรปแบบการมองเหน (Visually Model Software) หมายถง สถาปตยกรรมทออกแบบตอง

สามารถแสดงใหเหนถงการเขากนไดขององคประกอบยอยตาง ๆ ซอนหรอเปดเผยรายละเอยดไดตามความ

เหมาะสมกบงานแตละงาน(task) รกษาความสม าเสมอระหวางการออกแบบกบการพฒนาและตดตงใชงาน

ลดความคลมเครอและชวยเพมความสามารถในการจดการความซบซอนของซอฟตแวร มการใชภาษายเอม

Design & Implementation

Project Management

Change Management

Quality Assurance & Test

Requirement

7

แอล (UML- Unified Modeling Language) ซงเปนภาษาส าหรบก าหนดคณลกษณะเฉพาะ สามารถมองเหน

ไดเพราะเปนภาษาทสอดวยภาพ และยงเปนภาษาทใชในการสรางและจดท าเอกสารประกอบการพฒนา

ซอฟตแวรดวย การพฒนาระบบสารสนเทศจะใชเพยงทกษะดานภาษายอมไมเพยงพอ ทมงานพฒนาระบบ

นอกจากจะตองมทกษะพนฐานความรเกยวกบฮารดแวร ซอฟตแวรแลว ยงตองใช Modeling Language และ

Process ในการพฒนาระบบดวย

The Unified Modeling Language (UML) ภาษามาตรฐานส าหรบการจ าลองระบบสารสนเทศ ดวยภาพ

UML เปนภาษาในการวาดแบบจ าลองเพอจดประสงค 4 ประการ

- จ าลองดวยภาพ (visualizing)

- แสดงขอก าหนด (specifying)

- ชวยสรางระบบ (constructing)

- ชวยบนทก (documenting) ชนงานในขนตอนตางๆ ของการพฒนาระบบสารสนเทศ

4. ตรวจสอบคณภาพซอฟตแวร (Verify Software Quality) เปนการตรวจสอบคณภาพในดานตาง ๆ ของซอฟตแวรกอนทจะน าไปตดตงใชงาน เนองจากการน าซอฟตแวรทไมมคณภาพไปใชนนมกจะท าใหตองเสยคาใชจายและเวลาในการปรบปรงภายหลง ซงสงผลกระทบอยางมากตอการด าเนนงานของหนวยงานดวย

5. ควบคมการเปลยนแปลงของซอฟตแวร (Control Changes to Software) ซอฟตแวรมการเปลยนแปลงเนองจากสาเหตตาง ๆ เชน มผพฒนาหลายคน มทมพฒนาหลายทม มหนวยงานทตองตดตงใชงานหลายแหง มการพฒนาวนซ าหลายรอบ มหลายแพลตฟอรม ฯลฯ การจดการการเปลยนแปลงม 3ดานหลก ไดแก การจดการการค ารองขอของผใชทเปลยนแปลง (Change Request Management) การจดการองคประกอบ (Configuration Management) การวด (Measurement)

Change Request Management (CRM)

Configuration Management (CM)

Management

8

Introduction to Unified Process

การสรางระบบสารสนเทศจะใชเพยงทกษะดานภาษายอมไมเพยงพอ ทมงานพฒนาระบบนอกจาก

จะตองมทกษะพนฐานความรเกยวกบฮารดแวร ซอฟตแวรแลว ยงตองใช Modeling Language และ Process

ในการพฒนาระบบดวย

The Unified Modeling Language (UML) ภาษามาตรฐานส าหรบการจ าลองระบบสารสนเทศ ดวย

ภาพ UML เปนภาษาในการวาดแบบจ าลองเพอจดประสงค 4 ประการ

- จ าลองดวยภาพ (visualizing)

- แสดงขอก าหนด (specifying)

- ชวยสรางระบบ (constructing)

- ชวยบนทก (documenting)

ชนงานในขนตอนตางๆ ของการพฒนาระบบสารสนเทศ

ประวต UML พฒนาโดย Booch และ Rumbaugh เปน Unified Method 0.8 ในป 1997 และม

Jacobson มารวมพฒนาดวย เปน UML 0.9 -> UML 1.0 จนในปจจบนเปน UML 2.0 UML

UML ประกอบดวย 9 แผนภาพดงน

9

กระบวนการในการท า Software Engineering นนคอ สามารถบอกไดวาใครท าอะไร ท าเมอใดและ

ท าไดอยางไร หนงในกระบวนการคอ Rational Unified Process ซงเปน Best Practices ทประกอบดวย 6

ขนตอนคอ

1. Manage Requirement การจดการความตองการ

2. Develop Iteratively แบงแยกการพฒนาออกเปนสวนยอยๆ

3. Model Visually มรปแบบ

4. Verify Quality การตรวจสอบคณภาพ

5. Use Component Architecture มองคประกอบในเชงสถาปตยกรรม

6. Control Changes การควบคมการเปลยนแปลง

Rational Unified Process จะใชวธการของ Use-Case Driven คอแสดงดวยแผนภาพเหตการณ 5 มมมองหลก

ของ UML

1.Use-case view : หนาทการท างานของระบบซอฟตแวร โดยพจารณาจากมมมองของผใช

ภายนอก หรอ ระบบภายนอก

- use-case diagram

2. Design View : หนาทการท างานของระบบมโครงสรางอยางไร มองในรปของ static structure

และdynamic behavior

- class diagram, object diagram, state, sequence, collaboration, activity diagrams

3. Implementation View: องคประกอบยอยในการ implement ทประกอบเปนระบบ และ

dependency ระหวางองคประกอบเหลานน

- component diagram

4. Process view: การแบงแยก process และ processors โดยพจารณาทง communication และ

synchronization

-dynamic diagrams (state, sequence, collaboration activity)

-implementation diagrams (component และ deployment)

10

5.Deployment view : โครงสรางทางกายภาพเกยวกบ การตดตง และใชงานระบบ

- deployment diagram

- Use Case Diagram ใชเพอแสดงขอบเขตของระบบ และ ฟงกชนการท างานหลกของ

ระบบ

ตวอยางแผนภาพของ UML ทแสดงดวย USE-CASE Diagram

ทงนแผนภาพทใชในการอธบายระบบสวนใหญมดงตอไปน

1. Use Case Diagram ใชเพอแสดงขอบเขตของระบบ และ ฟงกชนการท างานหลกของระบบ

สญลกษณทใชใน Use Case แสดงดงตาราง

11

การพฒนา Use Case แสดงถงการวเคราะหระบบแบบ logical โดยไมตองระบถงอปกรณ หรอ อนเทอรเฟส

ตางๆ โดยแสดงถงสงทตองการจากระบบโดยไมตองสนใจวาจะท าไดอยางไร

ตวอยางระบบลงทะเบยนทแสดงดวย Use Case diagram

12

2. Activity Diagram ใชเพออธบายกระบวนการท างานในภาพรวม หรอ กระบวนการในรายละเอยด

ตวอยาง Activity Diagram

13

3. Class diagram ใชเพออธบายโครงสรางคงทของระบบสารสนเทศทงดานขอมล และกจกรรมหลก

ทกระท ากบขอมลนน

สญลกษณ Class diagram เปนรปสเหลยมประกอบดวย 3 สวน คอสวนทเปนชอ (name) สวนทเปน

รายละเอยด (attribute) และสวนทเปนการท างาน (operation) ในสญลกษณไมจ าเปนตองแสดงหมดทง 3

สวน

ตวอยาง Class diagram ของระบบลงทะเบยน

เมอสราง Class diagram ของระบบไดครบถวนแลวจงสราง Data dictionary เพอเปนทเกบค าศพทและ

ค าอธบายของระบบทงหมด เพออธบายความหมายของค าตางๆ ทใชในระบบใหชดเจนเปนทเขาใจทง 2

ฝายคอ ฝายผพฒนาระบบ และผใชระบบ

4. Sequence diagram เปนแผนภาพแสดงเหตการณ (scenarios) ทเกยวของของแตละ use case และ

แสดงใหเหนถงการปฏสมพนธระหวาง Object ณ เวลาตางๆ ทงน use case หนงๆ สามารถมหลาย

เหตการณได และเมอพจารณาระดบความส าคญของแตละแผนภาพ พบวา แผนภาพ use case แสดงกรอบ

งาน (framework) แผนภาพ class diagram ระบธรกรรมตางๆทเกยวของ

Sequence diagram ประกอบดวย

- Class/Object

14

- เสนเพอใชแสดงลาดบเวลา

- เสนเพอแสดงกจกรรมทเกดขนจาก Object/Class

- มการใชสเหลยมแทน Class/Object ภายในกรอบสเหลยมมชอของ Object/Class ประกอบ

อยในรปแบบ {Object}:Class

- กจกรรมทเกดขนแทนดวยลกศรแนวนอนจาก Class/Object หนงไปยงอก Class/Object ตว

ตอไป ระบชอกจกรรมในรปแบบ {[Conditional]} Operation

- ชอของกจกรรมตองเปน Operation ทอยใน Class/Object ทลกศรชไป

การปฏสมพนธระหวาง object ผาน Sequence diagram มองคประกอบดงตอไปน

- Object name บอกชอของออบเจกต ออบเจกตทอยทางซายมอจะท างานกอนออบเจกตทอยทางขวามอ

- Lifeline เสนประทลากในแนวดงจากออบเจกต

- Activation สเหลยมเลกๆ ทอยบนเสน lifeline แทนการท างานตางๆ ของออบเจกตของ activation นน

การสง message หรอ ขอความ ระหวางออบเจกต มลกษณะดงตอไปน - Synchronous เปนการสงขอความหรอตดตอแบบรอคอยค าตอบ หรอการตอบกลบกอนท

จะท างานอนๆ ตอไป - Asynchronous เปนการสงขอความหรอตดตอแบบไมรอคอยค าตอบ ไมมการหยดท างาน

ของผสง ผสงสามารถท างานตอได - Return เปนขอความทเกดขนในกรณทตนทางเรมการตดตอแลวปลายทางตองมการตดตอ

กลบดวย โดยการสงขอความจะเขยนขอความก ากบไวดวย - Time หรอชวงเวลา เปนการแสดงเวลาในลกษณะแนวตง หรอจากบนลงลาง ขอความทอย

ดานบนจะเปนสวนทเกดขนกอนขอความทอยดานลาง

- ถาหากเปนขอความเงอนไข จะเขยนเงอนไขไวในวงเลบกามป [ ] โดยขอความจะถกสงกตอเมอเงอนไขนนเปนจรง

ประโยชนของ Sequence diagram - ชวยใหรวา ม Function ขาดหายไปจาก Class Diagram หรอไม - ชวยใหพจาณาไดวาควรเพมเตม Function ใน Class Diagram อกหรอไม

15

- ชวยใหปรบปรง Class Diagram ไดสมบรณยงขน

สญลกษณทใชแทนขอความทง 3 แบบ มลกษณะดงตอไปน

สญลกษณมาตรฐานของ Sequence Diagram แสดงไดดงน

16

เทคนคการสราง Sequence Diagramจาก Use Case และ Class Diagram 1. พจารณาทละ Use Case โดยยงไมตองค านงถงความสมพนธทแตละ Use Case มตอกน 2. 2.พจารณาแตละ Use Case วาม Class/Object ใดรวมท าใหเกดกจกรรมใน Use Case นนๆ บาง 3. น าเอา Class/Object ตางๆ มาเรยงตอกนในแนวนอน โดยน า Actor (ในกรณท Use Case นนม

Actor ดวย) ไวทดานซ ายมอสดเสมอ แลวน า Class/Object ตางๆ เรยงตอกนจากซ ายไปขวาตามความเหมาะสม

4. หาก Use Case นนม Actor โดยปกตแลวกจกรรมแรกทถกเรยกมกจะเกดจาก Actor กอนเสมอ ดงนนเมอเกดกจกรรมทไปยง Class/Object ใด ใหยาย Class/Object นนมาท างซ าย ท าเชนนไปเรอยๆ จนกระทงกจกรรมทงหมดครบถวน

5. กรณทมกจกรรมเกดขนใหม แต Operation ทเกดขนไมมใน Class/Object ทลกศรชไป ใหเขาไปเพม Operation นนๆ ลงไปท Class นนใน Class Diagram

6. หากตองการเพม Class ใหมเขาไปใน Sequence Diagram ตองเขาไปเพมเตม Class นน และ Relationship ทมทงหมดใน Class Diagram ดวย (แต Class ทเพมเขาไปนนเปน Class เพอจ าลองกจกรรมทเกดขนจรงๆ ของระบบเทานน ไมใช Class ทเพมเขาไปเพอการ Implement เชน User Interface ตางๆ)

7. ท าขนตอน 1 –6 จนครบทก Use Case 8. การสรางความสมพนธของ Sequence Diagram จาก Use Case ทมการ Uses/Extends ท าไดโดยการ

น า Class และกจกรรมทเกดขนใน Use Case ทถก Uses/Extends มาแทรกเขาไปใน Use Case ทเรยกใช และใชกจกรรมเพอเชอมโยง Sequence Diagram ทงสอง

17

ตวอยาง Sequence diagram ของการคยโทรศพท Sequence Diagram ของการคยโทรศพท ประกอบดวย Use Case ตางๆ ดงน

- การตอโทรศพท

- การคยโทรศพท

- การมสายซอน (เปนUse Case ท Extends การคยโทรศพท) ประกอบดวย Class ตางๆ ดงน

- ผตดตอโทรศพท (Actor)

- ผรบโทรศพท (Actor)

- เครองโทรศพท

Sequence diagram ของการตอโทรศพท

18

Sequence diagram ของสายเรยกซอน

Communication Diagram - เนนทการแสดงการท างานของขอความตางๆ ในระบบ อธบายการโตตอบในระบบ

- เปนไดอะแกรมทนามาแทน Collaboration Diagram ใน UML 1.x

19

ตวอยาง Communication Diagram การก าหนดล าดบการท างานของขอความควรเรมตนดวยการสรางลงคระหวางออบเจกตกอน จากนนท าการระบขอความตางๆ ของระบบทเราก าลงสนใจ ระบล าดบใหกบขอความเหลานนโดยการใชตวเลขจ านวนเตม เชน 1.1, 3.2, 3.2.4 เปนตน นอกจากนมการใชตวอกษรรวมดวย เพอแสดงระดบการท างานทเทากนของขอความมากวา 1 ขอความ เชน 1.1a และ 1.1b เปนขอความทอยระดบเดยวกน

- ในกรณตองการระบวาขอความใดมการท าซ า (ภายใตเงอนไข) ใหใชสญลกษณดอกจน (*) ตามดวยเงอนไขการท าซ า และขอความทตองการใหท าซ า

- การก าหนดใหขอความทมการท าซ าใหท างานไปพรอมๆ กนแบบคขนาน ใหใชสญลกษณ | | ตามหลงเครองหมายดอกจน

- กรณตองการก าหนดเงอนไขการท างานใหกบขอความ ดวย Guard-Condition ซงเปนเงอนไขทเปนจรงหรอเทจชวยเราในการก าหนดเงอนไขดงกลาว

- สญลกษณทใช จะเหมอนสญลกษณการวนซ าแตไมมเครองหมายดอกจนน าหนา

20

ดงนนสรปไดดงน แผนภาพยเอมแอลทอยในกลมพฤตกรรม ประกอบดวย 4 แผนภาพ ดงน

(1) แผนภาพยสเคส (Use Case Diagrams) แสดงการปฏสมพนธ (interact) ในสองรปแบบคอระหวาง (1) ระบบกบผใช หรอ (2) ระบบกบระบบภายนอก (External Systems) กลาวคอ ยสเคสจะแสดงวาใครบางทเปนผใชระบบ และผใชเหลานนมการตดตอกบระบบในลกษณะใด ยสเคสมจดเดนคอเปนแผนภาพทสามารถท าความเขาใจไดงาย นกวเคราะหระบบมกจะใชยสเคสในชวงการรวบรวมความตองการของระบบ (System Requirement) ซงจะชวยใหนกวเคราะหสามารถก าหนดขอบเขตของระบบไดอยางถกตองครบถวน

(2) แผนภาพกจกรรม (Activity Diagrams) แสดงใหเหนกลมของการกระท า หรอการปฏบตงานทเรยกวา แอกชน (action) ซงประกอบขนตามล าดบขนรวมกนเปนกจกรรม (activity) ของงาน แผนภาพกจกรรมจะแสดงใหเหนถงขนตอนการปฏบตงาน ทางเลอกและเงอนไขของทางเลอกทมในแตละกจกรรม

(3) แผนภาพสเตจแมชน (State Machine Diagrams) แสดงสถานะของระบบตามชวงชวต รวมทงแสดงเหตการณใด ๆ ทสามารถเปลยนสถานะของระบบเพอการเสรมสรางความเขาใจโดยเฉพาะในการอธบายการท างานทซบซอน แผนภาพนสามารถใชในการอธบายพฤตกรรม

21

ระบบทงหมด หนวยยอยของระบบ (Subsystem) หรอแมแตเพยงวตถเดยว (Single Object) ในระบบ

(4) แผนภาพปฏสมพนธ (Interaction Diagrams) แผนภาพทจดในกลมนออกเปน 4 แบบดงน แผนภาพล าดบ (Sequence Diagrams) แสดงการปฏสมพนธระหวางออบเจกต

ตามล าดบของเหตการณทเกดขน แผนภาพล าดบมลกษณะทงายตอการท าความเขาใจ จงมกน ามาชวยใหผใชงานสามารถเหนภาพการท างานของระบบ และมกจะถกน ามาใชเสรมกบแผนภาพกจกรรม เนองจากแผนภาพกจกรรมอาจจะประกอบไปดวยเงอนไขจ านวนมาก ท าใหมทางเลอกในการท างานไดหลายเสนทาง เราจงน าแผนภาพล าดบมาใชในเฉพาะเสนทางทเลอกบางเสนทตองการอธบายขยายความ

แผนภาพการสอสาร (Communication Diagrams) แสดงวธทออบเจกตใชในการปฏสมพนธ รวมทงการเชอมโยง (connections) ทใชในการสนบสนนการปฏสมพนธน น ในยเอมแอลเวอรชนแรกเรยกแผนภาพแบบนวา แผนภาพการรวมมอ (Collaboration Diagrams)

แผนภาพเวลา (Timing Diagrams) แสดงการเปลยนแปลงสถานะ (state) เงอนไข (condition) หรอบทบาท (role) ของออบเจกตตามล าดบของเวลา โดยปกตสถานะทเปลยนแปลงไปนนมสาเหตเนองมาจากการตอบสนองตอเหตการณใด ๆ ทเกดขน

แผนภาพแสดงการปฏสมพนธอยางหยาบ (Interaction Overview Diagrams) ใชในการรวบรวมแผนภาพล าดบ แผนภาพการสอสาร และแผนภาพเวลา เขาดวยกนเพอแสดงการปฏสมพนธทส าคญทเกดขนในระบบ

การพฒนาซอฟตแวร

การพฒนาซอฟตแวรใหประสบความส าเรจ ควรใหความส าคญตอ 4 ดาน คอ 1. บคลากรในทมงาน ผบรหารโครงการพฒนาซอฟตแวรควรใหความส าคญตอบคลากรในทมงานฯ

มากกวากระบวนการและเครองมอ 2. เนนการมระบบซอฟตแวรทใชงานไดดมากกวาเอกสารคมอการใชงานซอฟตแวร 3. ความรวมมอของผใชส าคญกวาขอตกลงในสญญา ทงนเนองจากความตองการของผใชในระหวาง

ทพฒนาซอฟตแวรทอาจแตกตางจากทระบในสญญาทงหมด ทมงานพฒนาฯควรรบฟงความตองการดงกลาว หากไมแตกตางจากทระบในสญญามากกควรด าเนนการตามทผใชรองขอมา

4. ซอฟตแวรสามารถตอบสนองตอความตองการทเปลยนแปลงมความส าคญมากกวาการด าเนนการตามแผนอยางเครงครด แตซอฟตแวรทพฒนาไมสามารถตอบสนองตอความตองการของผใช

22

การปรบปรงรปแบบของซอฟตแวรทออกแบบไวในภาพรวม ตองยดหลกทท าใหซอฟตแวรมความสามารถดง ตอไปน

ยดหยนสามารถปรบขนาดได (scalable)

มความแขงแรงในการท างาน (robust) ไมลม (shutdown)

สามารถน ากลบมาใชไดอก (reusable)

ในระยะการออกแบบ (Design Phase) ควรใชหลกการ 5 ขอ ตอไปน ไดแก

1. ครบถวนสมบรณ (Completeness) การออกแบบทดจะตองครอบคลมชดของ operation ทครบถวน

ในคลาสแตละคลาส

2. ความเพยงพอ (sufficiency) การออกแบบทดจะตองไมรวม operation ทไมจ าเปนในคลาสแตละ

คลาส มเฉพาะเทาทตองม

3. ความเรยบงาย (primitive) การออกแบบ operation ควรเปนแบบเรยบงายไมซบซอน

4. มความเปนอนหนงอนเดยวกนสง (high cohesion) บางครงเรยกวา Single Responsibility Principle

(SRP) หมายความวา operation แตละ operation ควรสนบสนนหลกการท างานเดยว ไมควรท างาน

หลาย ๆ งานโดยใช operation เดยว

5.

6. มความเกยวของหรอขนตอกนนอย (low coupling) ระบบตาง ๆ ไมควรท างานเกนขอบเขตของ

ตวเองและเขาไปท างานในระบบอนมากเกนไป ควรเปนลกษณะการท างานทสงตอคาพารามเตอร

ระหวางกนเทานน

List

+add() +delete() +length() +printElement()

เปน conceptของdata structure

ไมใช conceptของdata structure

แตเปนinterface ควรตดออก

23

การออกแบบออปเจกต(object design)

ในการออกแบบออปเจกต ควรทบทวนรายละเอยดการวเคราะห เนนหวขอการออกแบบทส าคญ ๆ แยกความแตกตางระหวางการวเคราะหกบการออกแบบใหชดเจน

สรปขนตอนการวเคราะห ดงแสดงในภาพขางลางน

1. การก าหนดขอบเขต ควรเขยนแผนภาพuse case เพอระบ Actors System behavior System boundary

2. การก าหนดหลกการโดเมนส าคญ โดยสรางclass diagram ประกอบดวย data dictionary ระบclass และนยาม class เพอเปนกรอบงานส าหรบรายละเอยดความตองการของผใช สรางทจดเกบขอมลรายละเอยดของระบบทงหมด

3. สรางscenarios และsequence diagram เพอระบ Logical system Interaction Attributes & Operations Associations

4. ตรวจสอบobject behavior state diagram เพอระบ Operation definition Attributes

Identifying Scope

Identifying Key Domain Concepts

Specifying Detailed Requirements

Examining Object Behavior

24

ท าการส ารวจความสมบรณครบถวน (completeness) ความสม าเสมอ (consistency) สรปขนตอนการออกแบบ เปนการมงเนนโครงสรางซอฟตแวร แทนทจะเปนการท าความเขาใจ

เกยวกบความตองการของผใชทมตอซอฟตแวร การออกแบบซอฟตแวรทดสามารถลดทรพยากรทตองใชในการดแลบ ารงรกษาซอฟตแวรในอนาคตลงได ในการออกแบบจะมการน าขอจ ากดตาง ๆ มาพจารณา เชน เนอทหนวยความจ าทใชในการประมวลผล เวลา ความซบซอนของซอฟตแวร เปนตน ท าการเกบรายละเอยดทอาจละเลยไป ด าเนนการประยกตหลกการออกแบบ เชน encapsulation reuse inheritance เปนตน และท าการออกแบบสถาปตยกรรมของซอฟตแวร ดงแสดงในภาพขางลางน

การระบรายละเอยดขอ งsystem behavior เปนการระบวา object มการรบสงขอมลอะไรบาง

ระหวางกน ซงนยมใช Collaboration Diagram เปนแผนภาพแสดงการตดตอสอสารระหวางกน และมลกษณะคลายกบ Sequence Diagram วตถประสงคของการเขยนแผนภาพ Collaboration Diagram คอ

ท าความเขาใจการท างานรวมกนระหวาง objectในระบบ สงเกตการท างานของ object ทงหมดในระบบและ methods ทมสามารถท างานเขากน

ไดมากนอยเพยงใด ออกแบบรายละเอยดใหมมากขน เชน การปฏสมพนธกนระหวางคลาส กลไกของ

association การใส qualifiers สงส าคญของการพฒนาซอฟตแวรคอ การสอสารทด (well communication) ระหวางผใช

กบทมงานพฒนาฯ ตองมการยนยนรายละเอยดเปนระยะ ๆ แมแตในทมงานเองกตองเขาใจตรงกน ซงสามารถท าไดโดยการประชมรวมกน ท าเอกสารรวมกน โดยเฉพาะกรณทซบซอนมาก ๆ ควรน าโมเดลมาชวยในการสอสาร การออกแบบซอฟตแวรจะมการใช

Classes Attributes & Operations

Associations

Interfaces

Detailed Bahavior

Architecture

25

Collaboration Diagram เพอแสดงรายละเอยด behavior ของซอฟตแวร เปนแผนภาพทสรางคลายกบSequence Diagram บางครงเรยกวา Communication Diagram แสดงการรบสงขอมลระหวาง object ใชตรวจสอบวา objectและ method ทงหมดมความเหมาะสม จะใชสญลกษณคลายกนกบ Sequence Diagram แตจะมเสนลกศรก ากบบนเสน association และมตวเลขก ากบโดยใชระบบดวอคอเรยงตามล าดบและระดบ พรอมค าอธบาย operation ทเกดระหวาง object ดงภาพ

แผนภาพการสอสาร(communication diagram) กรณทตองท างานกบหลายobjectจะใชสญลกษณภาพสเหลยมซอนกน ดงภาพตอไปน

Customer

notifyPromotion()

นะรน๖๗

Promotion() notify

Company Customer

26

จากภาพบรษทจะสงขาวสารการสงเสรมการขายใหแกลกคาหลาย ๆ คน ซงลกคา(Customer) เปน class หนงและม notify promotion() เปน operation อยแลว กรณทตองการระบวา object 2 object ท างานรวมกนอยางไร อางองผานอะไรจะใช Qualifier ซงสญลกษณของ Qualifier คอกลองสเหลยมขนาดเลกตดกบสญลกษณผสงและอยทปลายเสน association ภายในกลองประกอบดวยคย (key) ดงภาพ

การใช Collaboration Diagram จะท าใหเหน association((link) ทชดเจนระหวาง object เพราะobject ตองม link กนกอนจงจะรบสง message กนได การรบสง message กคอ การ call functionกนนนเอง การระบประเภทของ link จะชวยในการตรวจสมพนธ ซงประเภทของ linkมดวยกน 5 ประเภท คอ

Association จะใชแอตทรบวทถาวร Parameter เปนการสงผานการเรยก procedure Global เปนการอางองไปย งobjectททกคนรจกและอางองไปยง class หรออางองไปยง

classของผทรองขอมา Local เปนแอตทรบวสชวคราว (ภายในกระบวนการทมการเรยก) Self เปนการ link กบตวเอง

โดยทวไป tools ทใชเขยน UML จะสามารถแปลง (convert) Sequence Diagram ไปเปน Collaboration Diagram ได แตใน Star UML เรยกวา Interaction Instance

การออกแบบ interface เปนการออกแบบการท างานประสานกนระหวางระบบยอยๆของซอฟตแวร เปนคณลกษณะเฉพาะของชด object และ behavior การออกแบบ Interface ท าใหไดคณลกษณะเฉพาะทสามารถน าไปประยกตในการพฒนาและตดตงระบบซอฟตแวรอน ๆ ได และท าใหผใชเกดความเขาใจในการท างานกบซอฟตแวรไดดยงขน ชวยปรบปรงการออกแบบและการพฒนาซอฟตแวรใหมคณภาพมากขน

Customer Coordinator customerID

1

0. .1