Object Oriented Development with UML 11/17/2018 Object Oriented Development with UML 11-12, 18-19 November 2006 At Sipa Chiangmai Class Diagram โดย รศ. รังสิต ศิริรังษี อ. สายัณห์ อุ่นนันกาศ

11/17/2018 Class คุณสมบัติของออปเจค 3 ประการ ได้แก่ : state, behavior และ identity คลาสมีลักษณะเป็นพิมพ์เขียวของออปเจคที่ประกอบไปด้วยส่วนที่เป็นแอท- ทริบิวต์ (state) และเมธอด (behavior) Class Name attribute: Type = initialValue.... method(arg list): return type.... รายละเอียดที่ปรากฏอยู่ภายในคลาสไดอาแกรมจะขึ้นอยู่กับระดับของการพัฒนาระบบ เช่น หากไม่มีการระบุส่วนของเมธอดไว้จะเป็นขั้นตอนของการ analyses

Class public class Customer { private String name; 11/17/2018 Class public class Customer { private String name; private String address; private Integer Id; private String city; public Integer getCustomerId() …... } public String getCustomerName() ….. public String getAddress()

UML instance-scope / class-scope 11/17/2018 UML instance-scope / class-scope Attribute int2 and int3 are marked as class-scoped, class-scope is indicated by underlining. int3 is class-scoped, often “frozen” attributes are made class-scoped. Method getInt2 is class-scoped; it can only access class-scoped attributes and methods. MyClass - int1 : int = 10 - int2 : int = 20 - int3 : int = 30 {frozen} + method() + getInt2() : int public class MyClass{ private int int1=10; private static int int2 = 20; private static final int int3 = 30; public void method1(){ int1 = 20;}; public static int getInt2(){ return int2;}; }

The Need for Relationships 11/17/2018 The Need for Relationships ระบบเชิงวัตถุทุก ๆ ระบบประกอบไปด้วยออปเจคและคลาสต่าง ๆ การทำงานของระบบสามารถทำได้โดยการติดต่อกันระหว่างออปเจคภายในระบบ ผ่านความสัมพันธ์ระหว่างกัน เพื่อให้คลาสหนึ่งสามารถส่งแมสเสจไปยังคลาสอื่น ๆ จำเป็นจะต้องมีความสัมพันธ์ระหว่างคลาสทั้งสอง ความสัมพันธ์มีลักษณะเป็น semantic ระหว่างคลาส โดยคลาสหนึ่งสามารถทราบรายละเอียดของแอททริบิวต์และเมธอดของคลาสอื่น ชนิดความสัมพันธ์ระหว่างคลาสมีดังนี้ Association, Aggregation, Generalization และ Dependency

Association Relationship 11/17/2018 Association Relationship โดยปกติแล้วคลาส A และคลาส B จะมีความสัมพันธ์กันในกรณีดังต่อไปนี้: ออปเจคของคลาส A ทำหน้าที่ส่ง message ไปยังออปเจคของคลาส B ออปเจคของคลาส A สร้างออปเจคของคลาส B ออปเจคของคลาส A มี attribute ที่เป็นออปเจคจากคลาส B หรือกลุ่มของออปเจคจากคลาส B ออปเจคของคลาส A ทำหน้าที่รับ message จากออปเจคของคลาส B ในรูปของ argument

Specifying Relationships 11/17/2018 Specifying Relationships Association Relationships Aggregation Generalization Dependency Relationship 1 0..* Customer Orders Aircraft Engine Person Student Client Supplier

11/17/2018 Dependency เป็นความสัมพันธ์ที่เกิดขึ้นจากการทำงานของคลาสหนึ่งที่มีลักษณะขึ้นอยู่กับคลาสอื่น ๆ ความสัมพันธ์ที่เกิดขึ้นนี้จะมีระยะเวลาสั้น ๆ ใน UMLความสัมพันธ์แบบนี้อาจสรุปการทำงานได้ดังนี้ ออปเจคอาจสร้างออปเจคอื่นในลักษณะที่เป็นส่วนหนึ่งของเมธอด เพื่อร้องขอให้เกิดการกระทำสิ่งใดสิ่งหนึ่งจนกระทั่งเสร็จสิ้น และความสัมพันธ์นั้น ๆ จะสิ้นสุดลงทันที ออปเจคอาจทำการสร้างออปเจคอื่นในลักษณะที่เป็นส่วนหนึ่งของเมธอด เพื่อกระทำสิ่งใดสิ่งหนึ่งและคืนค่ากลับไปยังเมธอดที่เรียกใช้ ออปเจคอาจเรียกใช้เมธอดที่รับค่าพารามิเตอร์ในรูปของของออปเจค เพื่อใช้และแก้ไขข้อมูลภายในออปเจคนั้น ๆ จากนั้นความสัมพันธ์จะสิ้นสุดลงเมื่อการทำงานของเมธอดเสร็จสิ้น

Dependency Relationship 11/17/2018 Dependency Relationship ความสัมพันธ์แบบ Dependency Dependency เป็นความสัมพันธ์ที่มีลักษณะ weakest form ที่สุด โดยความสัมพันธ์ของคลาสหนึ่ง จะขึ้นอยู่กับอีกคลาสหนึ่งเท่านั้น การเปลี่ยนแปลงที่เกิดขึ้นภายในคลาสหนึ่งจะมีผลต่อคลาสที่มีความสัมพันธ์กัน FilmClip playOn(c:Channel) start() stop() name Channel dependency

Association Relationship 11/17/2018 Association Relationship ความสัมพันธ์แบบนี้จะคล้ายกับความสัมพันธ์แบบ Dependency แต่จะแตกต่างกันตรงที่ช่วงเวลาที่เกิดความสัมพันธ์กันจะมีระยะเวลานาน และมีลักษณะเป็นความสัมพันธ์แบบโครงสร้าง ความสัมพันธ์แบบนี้อาจสร้างขึ้นได้โดยการการกำหนดคลาสอื่นในรูปของแอททริบิวต์ภายในคลาส และสามารถเรียกใช้เมธอดจากคลาสนั้นได้ในกรณีที่ต้องการ ความสัมพันธ์แบบนี้จะยอมให้มีการกำหนดทิศทางความสัมพันธ์ระหว่างคลาสได้ทั้งแบบ bi-directional หรือ unidirectional ความสัมพันธ์แบบนี้อาจถูกมองในรูปของการมีอยู่ (has-a) ได้ เช่น ออปเจคจากคลาสหนึ่งมีค่าอ้างอิงไปยังออปเจคจากคลาสอื่นได้

Association Direction 11/17/2018 Association Direction Navigability will be re-visited in Class Design, where this slide will be repeated for ease of review. Note: Double headed arrows are also valid UML. Rose uses the straight line rather than the double arrows to model bi-directional associations. นำเสนอผ่านสัญลักษณ์ลูกศรสองทิศทาง หรือไม่มีหัวลูกศรทั้งสองด้าน .. .. Bi-directional Class 1 Class 2 ส่วนการกำหนดหัวลูกศรทางเดียวไว้จะเป็นความสัมพันธ์แบบ Uni-direction The navigability property on a role indicates that it is possible to navigate from a associating class to the target class using the association. This may be implemented in a number of ways: by direct object references, by associative arrays, hash-tables, or any other implementation technique that allows one object to reference another. Navigability is indicated by an open arrow, which is placed on the target end of the association line next to the target class (the one being navigated to). The default value of the navigability property is true (e.g., associations are bi-directional, by default). Note that usually arrows are suppressed for associations and aggregations with navigability in both directions (e.g., when no arrowheads are shown, the association is assumed to be navigable in both directions). Arrows are shown only for associations with one-way navigability. The interaction diagrams can be used to identify the needed navigation between classes. Navigability is inherently a design and implementation property, though it can be specified in analysis, with the understanding that it needs to be refined in design (Class Design, to be specific). In analysis, many associations are modeled as being bi-directional. During design, we look at whether it is really necessary to navigate in both directions. .. .. Uni-directional Class 1 Class 2

11/17/2018 Association End หมายถึง end ของการ association เมื่อมีความสัมพันธ์ระหว่างคลาสเกิดขึน ถือเป็นส่วนหนึ่งของ association แต่ไม่ใช่ส่วนหนึ่งของคลาส สัญลักษณ์ต่าง ๆ ที่สามารถนำเสนอประกอบใน association end ได้ เช่น: multiplicity navigability aggregation indicator rolename

Naming Relationships ความสัมพันธ์สามารถกำหนดชื่อได้ 11/17/2018 Naming Relationships ความสัมพันธ์สามารถกำหนดชื่อได้ โดยปกติแล้วชื่อจะถูกกำหนดด้วย active verb หรือ verb phrase ที่ใช้สื่อความหมายในการติดต่อกันของความสัมพันธ์ที่ปรากฏ เช่น a Lecturer teaches a Course ชื่อความสัมพันธ์ถือเป็น optional ชื่อจะถูกเพิ่มเข้าไปเพื่อช่วยเพิ่มความชัดเจนของความสัมพันธ์ สำหรับความสัมพันธ์แบบ Aggregation โดยปกติจะไม่มีการกำหนดชื่อไว้ แต่จะเป็นการระบุโดยใช้คำประเภท “has”, “part of” หรือ “contains” เป็นต้น

11/17/2018 Role Names บริเวณปลายเส้นความสัมพันธ์ที่ติดกับคลาสจะถูกเรียกว่า association role Role name สามารถใช้แทนชื่อความสัมพันธ์ได้ โดยอยู่ในรูปของคำนามที่แสดงถึงเหตุผลของความสัมพันธ์ที่เกิดขึ้น role name จะถูกกำหนดตำแหน่งบนความสัมพันธ์ใกล้ ๆ กับคลาสที่มีการ modifies role name อาจถูกกำหนดไว้ที่ด้านใดด้านหนึ่งหรือทั้งสองด้านของเส้นแสดงความสัมพันธ์กัน ทั้ง role name และ association name ถือเป็น Optional +Teacher Course Offering Lecturer

Basic notation for associations 11/17/2018 Basic notation for associations Name Association mult1 mult2 Class B Class A role_B role_A Example: drives Car Person company car driver person จะเป็นบทบาทของ driver และ car จะเป็นบทบาทของ company car ซึ่งจะเป็นข้อมูลของออปเจคที่ต้องกระทำ

11/17/2018 Multiplicity เป็นการระบุจำนวนของ instances จากคลาส ถัดจากสัญลักษณ์แสดงจำนวน multiplicity ปรากฏ จะเป็นการอ้างอิงโดยใช้ single instance ของคลาสซึ่งอยู่ด้านท้ายสุดของ association path อีกด้านหนึ่ง ระบุ lower และ upper bound ของจำนวน instances Book .. Copy … Is a copy of 1 1..* ทุก ๆ copy ออปเจค(จากคลาส copy) จะถูก associated โดย “is a copy of” จาก Book เพียงหนึ่งจากคลาส Book

Multiplicity สัญลักษณ์แสดงการระบุจำนวนความสัมพันธ์ 2, 4..6, 8 11/17/2018 Multiplicity สัญลักษณ์แสดงการระบุจำนวนความสัมพันธ์ 2, 4..6, 8 Multiple, disjoint ranges 2..4 Specified range 0..1 Zero or one (optional association) 1..* One or more * (0..*) Zero or more (unlimited) 1 Exactly one

11/17/2018 Navigability โดยปกติแล้วความสัมพันธ์ระหว่างออปเจคจะเป็นไปในทิศทางเดียวเป็นส่วนใหญ่ ตัวอย่างเช่น Customer ออปเจคต้องการใช้บริการจาก Account ออปเจค สัญลักษณ์ลูกศรจะเป็นการระบุว่า Customer ออปเจคส่งแมสเสจไปยัง Account ออปเจคเท่านั้น Account Customer name balance deposit() getName() getAccount() withdraw() addToAccount() getBalance()

11/17/2018 Association Class บ่อยครั้งที่การออกแบบคลาสอาจมีจำนวน Multiplicity เป็นแบบ many-to-many ดังนั้นการกำหนด association คลาสอาจมีความจำเป็นในการแก้ไขความสัมพันธ์ในรูปของ one-to-many ตัวอย่างเช่น: “Result” ออปเจคจะขึ้นอยู่กับ “Student ” ออปเจคและ “Subject” ออปเจค Student Subject Enrolment ID Name Address Telephone Code Name Credit * * Result Association class Grade

Reflexive relationships 11/17/2018 Reflexive relationships คลาสอาจมีความสัมพันธ์กับตัวเองได้ เช่น ในกรณีที่คลาสมีออปเจคที่สามารถเป็นได้หลาย roles ความสัมพันธ์แบบนี้ถือเป็น Reflexive Association ที่สร้างจากคลาสเดียวกัน ชื่อของ Role โดยปกติจะถูกใช้สำหรับ reflexive relationships Person Parent Name Address Telephone 2 Role name Child *

Reflexive relationships cont.. 11/17/2018 Reflexive relationships cont.. CourseOffering Course 0..* +Pre-requisites หนึ่ง Course ออปเจคสามารถเป็น role ของ Prerequisite ที่เกี่ยวข้องกับ Course ออปเจคตั้งแต่ 0 หรือมากกว่า หนึ่ง Course ออปเจคจะเกี่ยวข้องกับ Course ออปเจคตั้งแต่ 0 หรือมากกว่าที่มี role เป็น Prerequisite

Navigable (uni-directional) association Reflexive association 11/17/2018 Associations (cont.) Role name Association name instructor StaffMember Student 1..* instructs * Role Navigable (uni-directional) association Multiplicity * pre - requisites Courses 0..3 Reflexive association

11/17/2018 Aggregation ความสัมพันธ์แบบ Association สามารถมีได้ 2 รูปแบบ ได้แก่ Aggregation และ Composition Aggregation ออปเจคหนึ่งมีออปเจคอื่นๆ เป็นส่วนประกอบ เช่น Car มี engine และwheels เป็นส่วนประกอบ Composition ถ้า delete วัตถุที่เป็นองค์ประกอบรวม ส่วนย่อยจะต้องถูก delete ทิ้งไปด้วย

11/17/2018 What is Aggregation? There are many examples of whole-part relationships: a Library contains Books, within a company Departments are made-up of Employees, a Computer is composed of a number of Devices. However, whether you model a relationship as an association or aggregation is really dependent on the domain being modeled. This is discussed in more detail on a later slide. ความสัมพันธ์แบบ Aggregation บางครั้งจะถูกเรียกว่า Shared Aggregation เป็นความสัมพันธ์ในลักษณะที่เรียกว่า “whole-part” ซึ่งประกอบไปด้วยคำประเภทต่อไปนี้“consists of”, “contains”, “is part of” ส่วนที่เป็น parts อาจเป็นส่วนประกอบของส่วนที่เป็น wholes อื่น ๆ ได้ Team * Person * Members An aggregation is a stronger form of association which is used to model a compositional relationship between model elements. The aggregate has an aggregation association to the its constituent parts. A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation. Since aggregation is a special form of association, the use of multiplicity, roles, navigation, etc. is the same as for association. Sometimes, a class may be aggregated with itself. This does not mean that an instance of that class is composed of itself (this would be silly), it means that one instance if the class is an aggregate composed of other instances of the same class. Some situations where aggregation may be appropriate: An object is physically composed of other objects (e.g. car being physically composed of an engine and four wheels). An object is a logical collection of other objects (e.g., a family is a collection of parents and children). An object physically contains other objects (e.g., an airplane physically contains a pilot). In the above example, The relationship from Student to Schedule is modeled as an aggregation because a Schedule is inherently tied to a particular Student. A Schedule outside of the context of a Student makes no sense in a Course Registration System. The relationship from Schedule to CourseOffering is an association because CourseOfferings may appear in the context of multiple Schedules. team ประกอบไปด้วย member ภายในทีม person หนึ่งสามารถเป็น member ของทีมอื่น ๆ ได้ person จะถือเป็นส่วนของการ shared parts

Composition เป็นความสัมพันธ์แบบ aggregation ที่มีความแน่นหนามากขึ้น 11/17/2018 Composition เป็นความสัมพันธ์แบบ aggregation ที่มีความแน่นหนามากขึ้น โดยส่วนที่เป็น whole จะทำหน้าที่เป็นเจ้าของส่วนที่เป็น part ส่วนที่เป็น part อาจเป็นของส่วนที่เป็น whole ได้เพียงหนึ่งเดียว Multiplicity ของส่วนที่เป็น whole จะต้องมีค่าเป็น 0 หรือ 1 เท่านั้น ช่วงชีวิตของส่วนที่เป็น part จะขึ้นอยู่กับส่วนที่เป็น whole เสมอ นั่นคือจะเกี่ยวข้องการสร้างหรือลบส่วนที่เป็น part เสมอ Circle Point 3..* 1 Polygon Point Circle

Composite Relationship 11/17/2018 Composite Relationship สัญลักษณ์ diamond สีดำจะใช้ในการนำเสนอความสัมพันธ์แบบ composition ซึ่งจะถูกกำหนดไว้ทางด้าน Book เนื่องจาก Book จะประกอบไปด้วย Chapter สัญลักษณ์ลูกศรแสดงถึงความสัมพันธ์เป็นแบบทางเดียว นั่นคือ Chapter ไม่รู้จักส่วนที่เป็น Book ใน UML ความสัมพันธ์จะถูกตั้งสมมุติฐานไว้เป็นแบบ bidirectional เสมอ เว้นแต่ว่าจะมีการกำหนดสัญลักษณ์ลูกศรเพื่อจำกัดไว้ Book Chapter

Aggregation & Composition 11/17/2018 Aggregation & Composition เป็นความสัมพันธ์แบบ transitive ถ้าวัตถุ A เป็นส่วนหนึ่งของ B และ B เป็นส่วนหนึ่งของ C แล้ว A เป็นส่วนหนึ่งของ C ด้วย เช่น ถ้าที่จับประตูเป็นส่วนหนึ่งของประตู ประตูเป็นส่วนหนึ่งของรถยนต์ แล้ว ที่จับประตูเป็นส่วนหนึ่งของรถยนต์ เป็นความสัมพันธ์แบบ Anti-symmetric วัตถุใดๆ อาจไม่จำเป็นต้องเป็นส่วนประกอบของตัวเองทั้งทางตรงและทางอ้อม เช่น ถ้าประตูเป็นส่วนหนึ่งของรถยนต์ แต่รถยนต์ไม่จัดเป็นส่วนหนึ่งของประตู

11/17/2018 Generalization Generalization จะเป็นความสัมพันธ์ในรูปของ sub-class / super-class ซึ่งจะได้แก่ inheritance นั่นเอง ในระดับ Conceptual: จะเป็นความสัมพันธ์แบบ supertype/subtype เช่นเดียวกับที่ใช้ใน ERD ในระดับ Specification : เป็นคุณสมบัติของ subtype ที่รวบรวมเอาคุณสมบัติทั้งหมดที่ได้รับจาก supertype มาเป็นส่วนหนึ่งของตัวเองโดยอัตโนมัติ ในระดับ Implementation : จะเป็นคุณสมบัติที่เรียกว่าการสืบทอดของแอททริบิวต์และเมธอดของ subClass ที่ได้มาจาก superclass ในภาษาของการโปรแกรม

11/17/2018 Generalization Generalization จะเป็นความสัมพันธ์ในรูปของ sub-class / super-class ซึ่งจะได้แก่ inheritance นั่นเอง (ใน UML อาจอยู่ในรูปของ use case, class และ package เป็นต้น ในระดับ Conceptual: จะเป็นความสัมพันธ์แบบ supertype/subtype เช่นเดียวกับที่ใช้ใน ERD ในระดับ Specification : เป็นคุณสมบัติของ subtype ที่รวบรวมเอาคุณสมบัติทั้งหมดที่ได้รับจาก supertype มาเป็นส่วนหนึ่งของตัวเองโดยอัตโนมัติ ในระดับ Implementation : เป็นคุณสมบัติที่เรียกว่าการสืบทอดทั้งส่วนของแอททริบิวต์และเมธอดของ subClass ที่ได้มาจาก superclass ในภาษาของการโปรแกรม

11/17/2018 Generalization จาวาจะนำเสนอความสัมพันธ์แบบ generalization โดยใช้คีย์เวิร์ด: extends และ implements Extends จะถูก generated เมื่อ stereotype ของ subclass อยู่ในรูปของ << class>> Implements จะถูก generated เมื่อ stereotype ของ subclass เป็น <<type>> A B A is superclass B is subclass <<type>> A is subtype A <<type>> B is B supertype

Generalization Relationship 11/17/2018 Generalization Relationship Shape origin move ( ) resize ( ) display ( ) Base Class Generalized Relationship Rectangle corner : Point Circle radius : Float Polygon points : List display ( ) Square Leaf Class A class hierarchy for shape

<<interface>> A 11/17/2018 Realization ความสัมพันธ์แบบ realization จะเป็นการระบุว่าคลาสหนึ่งถูกสืบทอดพฤติกรรมการทำงานมาจากคลาสอื่นในรูปของ interface UML ใช้สัญลักษณ์ในการนำเสนอ interface ได้เป็น 2 รูปแบบคือ สัญลักษณ์ "lollipop" ที่ใช้ร่วมกับคลาส หรือ subsystems อื่น ๆ สัญลักษณ์ของคลาสที่ใช้ stereotype โดยระบุ <<interface>> <<interface>> A +operation1() +operation2() A +operation1() +operation2()

<<interface>> A 11/17/2018 Interfaces <<type>> stereotype จะระบุว่าคลาสอยู่ในรูปของ interface จะมีเพียงเมธอดเท่านั้น สามารถนำไปใช้ได้โดยการสืบทอด (implement) เช่น Collection type (list, map, set) และคลาสแบบ concrete (linked list, hash map, tree set). <<interface>> A +operation1() +operation2() B A +operation1() +operation2() B

Implementation and usage: alternative marking 11/17/2018 Implementation and usage: alternative marking Client Collection +add() +remove() +iterator() LinkedList คลาส LinkedList สืบทอดมาจาก interface Collection คลาส Client ใช้ interface Collection ที่ถูก implemented โดยคลาส LinkedList ConfiguredComputer ConfiguredComputer StandardComputer StandardComputer configured_price : Currency configured_price : Currency standard_price : Currency standard_price : Currency Computer Computer getConf getConf () ()

Class Diagram : Reviews (1) 11/17/2018 Class Diagram : Reviews (1) คลาส A เป็น Superclass ของคลาส B คลาส B เป็น superclass ของคลาส C และคลาส D คลาส B เป็น subclass ของคลาส A จากหลักการสืบทอดทั้งคลาส C และ D เป็น subclass ของคลาส A

Class Diagram : Reviews (2) 11/17/2018 Class Diagram : Reviews (2) สัญลักษณ์ realization มีผลดังนี้ ในจาวาคลาส B implements (realizes) มาจาก InterfaceF คลาสB เป็น (IS-A) InterfaceF คลาส C เป็น ( IS-A) คลาส B คลาส A และ InterfaceF ส่วนสัญลักษณ์ diamond ใช้ระบุ "Shared" Aggregations เป็นความสัมพันธ์แบบทิศทางเดียว เช่น ตัวแปร Java instance คลาส E ประกอบไปด้วยอย่างน้อยหนึ่ง reference ไปยังคลาส B คลาส E มี (HAS-A) คลาส B reference อยู่ภายใน

Class Diagram - Example 11/17/2018 Class Diagram - Example A zoo consists of a set of cages. Every cage is the home of at least 2 animals. Cages are located besides each other. Every cage has at most one left neighbor and at most one right neighbor. Animals can be reptiles, insects, and mammals. Mammals are elephants, monkeys, and tigers. Monkeys eat bananas. Tigers prefer meat.

Zoo Class Diagram Zoo 1 1.* Cages Animal 1 2.* Reptile Insect Mamal 11/17/2018 Zoo Class Diagram Zoo 1 1.* Cages Animal 1 2.* Reptile Insect Mamal Elephant Monkey Tiger eat prefer Banana Meat

11/17/2018 How do you find classes? การค้นหาออปเจคหรือคลาสเป็นหัวใจหลักของการพัฒนาระบบเชิงวัตถุ เรียนรู้จาก problem domain: สังเกตจาก client ประยุกต์จากความรู้ที่มีอยู่ ใช้ flow of events และค้นหาออปเจคที่ต้องการจาก use cases ตรวจสอบ syntactic analysis ของ scenario หรือ flow of events ใช้วิธีการ Abbott Textual Analysis (noun-verb analysis) Nouns ถูกใช้เป็นคลาสคู่แข่ง Verbs ถูกใช้เป็นเมธอดหรือ opeations ประยุกต์ใช้ความรู้จากการออกแบบ: จำแนกออปเจคชนิดต่าง ๆ Q: What key ideas have we covered so far? A: Patterns, analysis documentation standard, inheritance and multiple inheritance. In the last part of this lecture I would like to come back to the problem of object identification and another tool that helps you infinding objects. Patterns: A way to put your knowledge about object modeling into drawers. Analysis documentation standard: The “official” way of drawing object models. The major elements are: CASE Tool Entry: Executive summary and one subsystem per sheet. 7+-2 classes per sheet. Documentation: Each subsystem has navigational text. Difference between aggregation and inheritence Object identification: Using textual analysis Multiple Inheritance: Why it cannot be avoided, how you can deal with it. Software engineering as a special case of Epistemology: Software engineering is a join class of materialism (budget and deadline influencing your modeling (They might limit what you can achieve!). Idealism: Some of the classes do not reflect reality (that is, the customer does not know about them) and dialecticism (iteration and incremental analysis with user participatory decision making capabilities).

Generation of a class diagram from flow of events 11/17/2018 Generation of a class diagram from flow of events Customer Flow of events: The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. customer enters store store enter() ? enter() buy toy daughter less than 50 Euro videogame daughter daughter age suitable * An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buy the game and leaves the store depends toy price buy() like() toy toy buy() age type of toy boardgame videogame boardgame

Textual Analysis using Abbot‘s technique 11/17/2018 Textual Analysis using Abbot‘s technique Example Grammatical construct UML Component “toy" noun class "3 years old" Adjective Attribute “enters" verb Operation “depends on…." Intransitive verb Operation (Event) “is a" ,“either..or", “kind of…" Classifying verb Inheritance "Has a ", “consists of" Possessive Verb Aggregation “must be", “less than…" modal Verb Constraint

Order of activities in modeling 11/17/2018 Order of activities in modeling กำหนด Scenarios จากความช่วยเหลือของผู้ใช้หรือ application domain expert แยก use cases ออกจาก scenarios โดยความช่วยเหลือของ application domain expert วิเคราะห์ flow of events โดยใช้วิธีการ Abbot's textual analysis สร้างคลาสที่ประกอบไปด้วยขั้นตอนดังนี้: การกำหนดคลาส (textual analysis, domain experts). การกำหนด attributes และ operations กำหนดความสัมพันธ์ระหว่างคลาส กำหนดจำนวนความสัมพันธ์และ roles กำหนด constraints

ตัวอย่าง การสร้างคลาสไดอาแกรม 11/17/2018 ตัวอย่าง การสร้างคลาสไดอาแกรม การค้นหาคลาสจากยูสเคส สามารถทำได้โดยใช้ เทคนิคที่เรียกว่าการวิเคราะห์คำนาม (Noun Analysis) โดยมีขั้นตอนดังต่อไปนี้ สร้างรายการของคลาสคู่แข่ง ทบทวนรายการของออปเจคคู่แข่ง กำหนดขอบเขตการทำงานของคลาส กำหนดความสัมพันธ์ระหว่างคลาส นำผลลัพธ์ที่ได้มาสร้างแบบจำลองคลาสไดอาแกรม

11/17/2018 ยูสเคสไดอาแกรม

11/17/2018 ยูสเคส : Login ระบบแสดงหน้าจอลอกอินโดยอัตโนมัติเมื่อผู้ใช้เข้าสู่ระบบสั่งซื้อออนไลน์ โดยหน้าจอดังกล่าวจะประกอบด้วยฟิลด์ชื่อผู้ใช้(Username) และรหัสผ่าน(Password) ระบบจะรับค่าชื่อผู้ใช้และรหัสผ่านเพื่อตรวจสอบกับข้อมูลผู้ใช้ที่อยู่ภายในฐานข้อมูลของระบบ ในกรณีที่ผู้ใช้ใส่ค่าชื่อผู้ใช้และรหัสผ่านที่ตรวจสอบแล้วไม่มีอยู่ในระบบฐานข้อมูล(Database) ระบบจะแสดงข้อความชื่อผู้ใช้และรหัสผ่านไม่ถูกต้อง (Invalid Password and/or User ID) ในกรณีที่ผู้ใช้ยังไม่มีชื่อผู้ใช้ รหัสผ่าน และข้อมูลที่จำเป็นในการสั่งซื้อ ระบบจะยอมให้ผู้ใช้สามารถลงทะเบียนโดยผ่านฟังก์ชันลงทะเบียน (Register) ที่อยู่ด้านล่างของหน้าจอลอกอิน หลังจากขั้นตอนการลอกอินแล้วระบบจะยอมให้ผู้ใช้เข้าถึงการทำงานของการสั่งซื้อ (Place Order) การยกเลิกการสั่งซื้อ (Cancel Order) และการแก้ไขรายการสั่งซื้อ (Update Order)

ยูสเคส : Browse Product Browse Product ใช้สำหรับแสดงรายละเอียดสินค้าตามประเภทที่ผู้ใช้เลือก โดยเริ่มต้นจากระบบแสดงประเภท (Category) ของสินค้าทั้งหมด เมื่อผู้ใช้ (User) หรือลูกค้า (Customer) เลือกประเภทสินค้าที่ต้องการ รายละเอียดของรายการสินค้า (Product) ทั้งหมดจะถูกนำเสนอบนหน้าจอ โดยประกอบไปด้วย รหัสสินค้า (productId) ชื่อสินค้า (productName) ราคาต่อหน่วย (pricePerUnit) เป็นต้น

ยูสเคส : Add Shopping Cart 11/17/2018 ยูสเคส : Add Shopping Cart ขั้นตอนนี้เริ่มต้นเมื่อลูกค้าเลือกการสั่งซื้อโดยเลือกรายการสินค้า (Order Item) ที่ต้องการแล้ว ระบบจะแสดงรายละเอียดสินค้า (Product) ที่ประกอบด้วย รหัสสินค้า (ProductID) ชื่อสินค้า (ProductName) ราคาต่อหน่วย (Unit Price) โดยผู้ใช้กรอกจำนวนหน่วย (Unit) ที่ต้องการ จากนั้นระบบทำการคำนวณราคารวมทั้งหมด (Total Price) ทีละรายการ จนกว่าผู้ใช้จะเลือกการจ่ายเงิน (Payment) โดยการกรอกข้อมูลบัตรเครดิต (Credit Card) ที่ประกอบไปด้วย หมายเลขบัตร (Credit card Number) และวันหมดอายุ (Expire Date) จากนั้นลูกค้าสามารถส่งรายการสั่งซื้อ (Order) เข้าสู่ระบบ เพื่อให้ระบบทำการตรวจสอบ บันทึก และส่งข้อมูลต่อไปยังระบบบัญชี (accounting system) เพื่อยืนยันการสั่งซื้อ ระบบจะคืนค่ารหัสรายการสั่งซื้อ (OrderID) กลับไปยังลูกค้า และสิ้นสุดการทำงานของยูสเคส

ชื่อผู้ใช้(Username) 11/17/2018 ขั้นตอนที่ 1: สร้างรายการของคลาสคู่แข่ง ลอกอิน (Login) ชื่อผู้ใช้(Username) รหัสผ่าน(Password) ลูกค้า (Customer) ชื่อ (Name) นามสกุล (Lastname) วันเดือนปีเกิด (DateOfBirth) อาชีพ (Occupation) ที่อยู่ (Address) บ้านเลขที่ (Number) ถนน (Street) ตำบล (Sub-District) อำเภอ (District) จังหวัด (Province) รหัสไปรษณีย์ (ZipCode) สถานที่จัดส่งสินค้า (Delivery Address) ยืนยันการกรอกรหัสผ่าน (Confirm Password) รหัสลูกค้า (CustomerID) รายการสั่งซื้อ (Order) วันที่สั่งซื้อ (OrderDate) รายการสินค้า (Order Item) จำนวนหน่วย (Unit) สินค้า (Product) รหัสสินค้า (ProductID) ชื่อสินค้า (ProductName) ราคาต่อหน่วย (Unit Price) ราคารวมทั้งหมด (Total Price) การจ่ายเงิน (Payment) บัตรเครดิต (Credit Card) หมายเลขบัตร (Credit card Number) วันหมดอายุ (Expire Date) สถานะบัตรเครดิต (Status) ระบบบัญชี (accounting system) รหัสรายการสั่งซื้อ (OrderID) สถานะการสั่งซื้อ (OrderStatus) จัดส่ง (Deliverly)

ขั้นตอนที่ 2: ตรวจสอบรายการของคลาสคู่แข่ง 11/17/2018 ขั้นตอนที่ 2: ตรวจสอบรายการของคลาสคู่แข่ง คลาสที่มีความหมายซ้ำกัน (Redundant Classes) เช่น คลาสผู้ใช้ (User) หรือคลาสลูกค้า (Customer) คลาสที่ไม่ตรงประเด็น (Irrelevant Classes) ซึ่งจะหมายถึงคลาสที่ไม่มีอะไรเกี่ยวข้องโดยตรงกับระบบ เช่น ลูกค้าร้องเรียน (Customer complaint) คลาสที่มีความหมายคลุมเครือ (Vague Classes) เป็นคลาสที่มีความหมายไม่ชัดเจนต่อการพัฒนาระบบ เช่น system และ software เป็นต้น คำนามที่อยู่ในรูปของแอททริบิวต์ เป็นคำนามที่ไม่สามารถเป็นคลาสได้โดยตรงเนื่องจากมีลักษณะเป็นรายละเอียดประกอบในคลาสอื่น ๆ เป็นหลัก เช่น ชื่อลูกค้า (Customer’s name) คำนามที่มีลักษณะเป็นการทำงานไม่สามารถกำหนดเป็นคลาสได้โดยตรงเช่น การค้นหาสินค้า (Product Search) คลาสที่เป็นบทบาทหรือหน้าที่ (Roles) เป็นคลาสคู่แข่งที่มีลักษณะเป็นความสัมพันธ์มากกว่าที่จะเป็นคลาส

การกำหนดคลาสจากคลาสคู่แข่ง 11/17/2018 การกำหนดคลาสจากคลาสคู่แข่ง รายการคลาสคู่แข่ง คลาส เหตุผล ลอกอิน (Login) / - กำหนดเป็นคลาสสำหรับการลอกอิน ชื่อผู้ใช้(Username) - - กำหนดเป็นแอททริบิวต์ของคลาสลอกอิน รหัสผ่าน(Password) ลูกค้า (Customer) -กำหนดเป็นคลาสลูกค้า ชื่อ (Name) - กำหนดเป็นแอททริบิวต์ของคลาสลูกค้า นามสกุล (Lastname) วันเดือนปีเกิด (Date of Birth) อาชีพ (Occupation)

Class Diagram: Conceptual Level 11/17/2018 Class Diagram: Conceptual Level OrderDetail Product Category Address CheckOut Order Login Customer has place pay contains consists of refer to

Class Diagram 11/17/2018 Address - no - street - subDistrict - province - zipcode - telNo Login - username - password CheckOut - typeCreditCard - creditID - creditName - expirationDate Customer - name - lastName - gender - birthday - occupation - customerid n 1 Category - categoryId - categoryName - categoryDesc Order - orderId - totalPrice - tax - orderDate - deliveryDate - statusDelivery 1..n Product - productId - productName - pricePerUnit - qtyInStock OrderDetail - OrderDetailId - qty - sum has place contains refer to consists of pay