Chapter 8 – UML Design.

งานนำเสนอเรื่อง: "Chapter 8 – UML Design."— ใบสำเนางานนำเสนอ:

1 Chapter 8 – UML Design

2 OO Analysis / Design / Programming
Definition of the problem Construction of the solution Domain Program Model OOA OOD/OOP Teaching material base on Prof.Koichiro Ochimizu,SOI: UML course

3 Modeling the Domain Problem Description of possibility Program
public class hungry-person { int state-of-hunger void eat () { } public class apple { int volume void eaten () Program Reproduction of the Domain in the main memory state-of-hunger eat() volume eaten() The world view: We can represent the domain simply by “A set of objects and their interaction h2 h1 a1 a2 Problem : hungry person : apple hungry　person state of hunger eat apple eaten satisfy hunger Description of possibility Definition of static structure and dynamic behavior 3

4 UML Very popular now and help us make and analyze:
Use-case Diagrams for defining functional requirements Collaboration Diagrams for finding analysis classes Class Diagrams for designing the static structure Sequence Diagrams for defining objects interaction State Diagrams for defining the behavior of each object Deployment Diagrams for allocating objects to machines Component Diagrams for packaging

5 The Views in UML Deployment Component View View Use-Case View
Concurrency View Logical View Use-case view หน้าที่การทำงานของระบบ Logical view การทำงานของระบบมีโครงสร้างอย่างไร Component view องค์ประกอบย่อยในการ implement และ dependency ระหว่างองค์ประกอบ Concurrency view การแบ่งแยก process และ processors Deployment view โครงสร้างทางกายภาพเกี่ยวกับ การติดตั้ง และ การใช้งานระบบ H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

6 Relationships between views and diagrams
Deployment diagram Component diagram Component View Deployment View Use-Case View State diagram Sequence diagram Collaboration diagram Activity diagram Concurrency View Collaboration diagram Class diagram Object diagram State diagram Sequence diagram Logical View 5 มุมมองหลักของ UML Use-case view : หน้าที่การทำงานของระบบซอฟต์แวร์ โดยพิจารณาจากมุมมองของผู้ใช้ภายนอก หรือ ระบบภายนอก use-case diagram Logical view : หน้าที่การทำงานของระบบมีโครงสร้างอย่างไร มองในรูปของ static structure และ dynamic behavior class diagram, object diagram, state, sequence, collaboration, activity diagrams Component view : องค์ประกอบย่อยในการ implement ที่ประกอบเป็นระบบ และ dependency ระหว่างองค์ประกอบเหล่านั้น component diagram Concurrency view: การแบ่งแยก process และ processors โดยพิจารณาทั้ง communication และ synchronization dynamic diagrams (state, sequence, collaboration activity) implementation diagrams(component และ deployment) Deployment view : โครงสร้างทางกายภาพเกี่ยวกับ การติดตั้ง และใช้งานระบบ deployment diagram Use-case diagram

7 The Unified Software Development Process
Use-Case Model Use-Case Diagram Analysis Model describe “Realization of a Use-Case” by a Collaboration Diagram and a Flow of Event Description Design Model Class Diagram, Sequence Diagram, and State Diagram Deployment Model Deployment Diagram Implementation Model Component Diagram Test Model Test Case

8 Use-Case View Deployment Component Use-Case View Concurrency Logical
H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

9 Use Case Model Use Case Model: A use case model represents the functional requirements and consists of actors and use cases. A use case model helps the customer, users, and developers agree on how to use the system. Actor: An actor is someone or something that interacts with system. System: Black box provided with use cases Use Case: A use case specifies a sequence of actions that the system can perform and that yields an observable result of value to a particular actor. I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

10 Development of Use Case Model
Defining the System Finding Actors and Uses Cases Use Case Descriptions Defining Relationships between Use Cases Verify and Validate the Model H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

11 What is an Actor ? An actor is someone or something that Interacts with the system. The actor is a type (a class), not an instance. The actor represents a role, not an individual user of the system. Actors can be ranked. A primary actor is one that uses the primary functions of the system. A secondary actor is one that uses secondary functions of the system, those functions that maintain the system, such as managing data bases, communication, backups, and other administration tasks. H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

12 Finding Actors Who will use the main functionality of the system ?
Who will need support from the system to do their daily tasks ? Who will need to maintain, administrate, and keep the system working (secondary actor) ? Which hardware devices does the system need to handle ? With which system does the system need to interact ? Who or what has an interest in the result (the value) that the system produce ? H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

13 What is a Use Case ? A use case represents a complete functionality as perceived by an actor. A use case is always initiated by an actor. A use case provides values to an actor. A use case is complete. Use cases are connected to actors through associations (communication association). A use case is a class, not an instance. A instantiation of a use case is called a scenario. Ex. Signing Insurance (Use Case) Ex. John Doe contacts the system by telephone and signs for car insurance for the car he just bought. (scenario) H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

14 Finding Use Cases Which functions does the actor require from the system ? What does the actor need to do ? Does the actor need to read, create, destroy, modify, or store some kind of information in the system ? Does the actor have to be notified about events in the system, or does the actor need to notify the system about something ? What do those events represent in terms of functionality ? Could the actor’s daily work be simplified or made more efficient through new functions in the system ? H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

15 Example: A Use-Case diagram
Bank Customer Deposit Money Withdraw Money UML Notation Use Case Actor Transfer between Accounts I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

16 Logical View Deployment Component Use-Case View Concurrency Logical
Collaboration diagram Class diagram Object diagram State diagram Sequence diagram หน้าที่การทำงานของระบบมีโครงสร้างอย่างไร มองในรูปของ static structure และ dynamic behavior H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

17 Analysis of inside of the system
Use Case Actor Collaboration แต่ละ use-case มี flow of event กำกับ (ส่วนที่เป็นสี่เหลี่ยมสีเหลือง) และ แต่ละ use-case จะมี collaboration diagram กำกับเพื่อบอกว่ามีการทำงานอย่างไร ติดต่อกับใครบ้าง หลังจากหา requirement โดยใช้ use-case เป็นตัวอธิบาย requirement แล้ว ก็ต้องมีการวิเคราะห์ระบบ ซึ่งการ วิเคราะห์ระบบ หรือที่เรียกว่า analysis model นั้น เป็นการหาภาพรวมการทำงานของระบบว่าเป็นอย่างไร ซึ่งอธิบายได้ด้วย collaboration diagram และ flow of event ของแต่ละ use-case

18 Analysis Model Use-Case Model Analysis Model <<trace>>
Withdraw Money Dispenser Cashier Interface Withdrawal Account Withdraw Money ตัวอย่างเช่น use-case เรื่องการ ถอนเงิน จาก use-case นี้เราสามารถวิเคราะห์คร่าวๆ ได้ว่าควรมี เหตุการณ์อะไรเกิดขึ้นบ้าง เช่น ส่วนของการจ่ายเงิน (dispenser) ส่วนของ interface ติดต่อกับผู้ใช้ (cashier interface) ส่วนการคำนวณการถอนเงิน (withdrawal) และส่วนของ บัญชีเงินฝาก (account) I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

19 Collaboration << trace >>
Dependency << trace >> Control Boundary Entity Three different stereotypes on classes A collaboration gives a name to the mechanism of the system It also serve as the realization of a use case It defines a group of objects and their interaction จากส่วนต่างๆที่เราวิเคราะห์ได้คร่าวๆ สามารถนำมาเขียนการติดต่อกันของส่วนต่างๆเหล่านี้ เพื่ออธิบายการทำงานของ use-case ในรูปของ collaboration diagram Collaboration diagram มีรายละเอียดสัญลักษณ์แตกต่างกันไป ตามการนิยามของแต่ละเล่ม แต่หลักจะมี ส่วนของ class และความสัมพันธ์ของคลาสตามลำดับการทำงาน ความสัมพันธ์จะใช้ลูกศรในการบอกว่าจาก class ไหนไปยัง class ไหน โดยจะมีหมายเลขกำกับ หมายเลขจะเริ่มจาก 1 เพื่อบอกว่าเป็นจุดเริ่มต้นของ use case นี้ Class ที่แสดงจะใช้สัญลักษณ์ 3 แบบตามชนิดของ class หรืออาจจะใช้เป็นแค่ สี่เหลี่ยมพร้อมชื่อ class ก็ได้ สัญลักษณ์ทั้งสามได้แก่ สัญลักษณ์ของ control class, boundary class และ entity class <<control>> classes โดยทั่วไป นำเสนอ การจัดการ การประสานงาน ของ object ต่างๆ <<boundary>> classes โดยทั่วไป สร้างเพื่อจำลองการติดต่อสื่อสารระหว่าง ระบบ และ actor <<entity>> classes โดยทั่วไปใช้จำลองข้อมูลที่ต้องการเก็บถาวรในระบบ I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

20 Analysis Model: Collaboration
3: validate and withdraw : Account : Cashier Interface :Dispenser : Withdrawal 2: request withdrawal 4: authorize dispense 5: dispense money : Bank Customer 1: identify แสดงลำดับการทำงานของ วัตถุ ผู้เกี่ยวข้อง และกิจกรรม โดยลำดับการทำงานไม่ขึ้นกับเวลา เพราะการแสดงความสัมพันธ์ของ Object กับเวลาเป็นหน้าที่ของ Sequence Diagram จากภาพจะเห็นว่า use-case การถอนเงิน จะเริ่มจาก ลูกค้า (1) แสดงตน ต่อ cashier interface และ (2) ร้องขอการถอนเงน ไปยังส่วนการถอนเงิน ระบบการถอนเงินจะ (3) ติดต่อ กับ account ว่าถูกต้องมั๊ย และทำการคำนวณ และ (4) อนุมัติการถอนเงินไปยังส่วนของการถอนเงิน ส่วนการถอนเงินจะประสานงาน (5) ส่งเงินให้ลูกค้าต่อไป I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

21 Flow of Events Description of a Use-Case Realization
A Bank Customer chooses to withdraw money and activates the Cashier Interface object. The Bank Customer identifies himself or herself and specifies how much to withdraw and from which account (1). The Cashier Interface verifies the Bank Customer’s identity and asks a Withdrawal object to perform the transaction (2). If the Bank Customer’s identity is valid, the Withdrawal object is asked to confirm that the bank customer has the right to withdraw the specified amount from the Account. The Withdrawal object confirms this by asking the Account object to validate the request and, if the request is valid, withdraw the amount (3). Then the Withdrawal object authorizes the Dispenser to dispense the amount that the Bank Customer requested (4). The Bank Customer then receives the requested amount of money (5) จาก collaboration diagram เราสามารถเขียน flow of event ได้ชัดเจนมากยิ่งขึ้น ซึ่งจะเห็นว่า ทั้งสองส่วนนี้ มีจุดมุ่งหมายเดียวกัน คืออธิบายลำดับการทำงานของ use-case หนึ่งๆในระบบ

22 Analysis of inside of the system
Use case Actor Collaboration Collaboration Diagram Event Flow Description I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

23 Transfer between Accounts
A Class Participating in Several Use-Case Realizations in Analysis Model Use-Case Model Analysis Model Bank Customer Withdraw Money Deposit Money Transfer between Accounts Dispenser Cashier Interface Account Withdrawal Money receptor Deposit Transfer Bank Customer ในระบบก็จะมีหลายๆ collaboration diagram เพื่ออธิบายการทำงานของทั้งระบบ I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

24 Analysis Class and Design Class
Analysis Classes Cashier Interface Dispenser Account Withdrawal Card Reader Sensor Cash Counter Feeder <<trace>> Display Key Pad withdrawal Transaction Manager Persistent Class Client จาก collaboration diagram คร่าวๆ เราสามารถ ออกแบบคลาสที่เกี่ยวข้องให้ละเอียดมากยิ่งขึ้น ในขั้นตอนของการ ออกแบบ ระบบ เช่น ในส่วนของ cashier interface เราอาจะมีคลาสที่เกี่ยวข้องเช่น คลาสการแสดงผล เกี่ยวกับ keypad และ เกี่ยวกับ การอ่านการ์ด หรือส่วนของการจ่ายเงิน ก็อาจเกี่ยวข้องกับ เซ็นต์เซอร์การจ่ายเงิน ตัวจ่ายเงิน หรือ counter เงินสด หรือ การจัดการลูกค้า ส่วนของการถอนเงิน ก็อาจเกี่ยวข้องกับ ส่วนการคำนวณการจ่ายเงิน การทำ transaction ให้บัญชีถูกต้อง ส่วนของ บัญชี ก็อาจมีคลาสบัญชีเงินฝาก ส่วนการเก็บข้อมูลถาวร และส่วนจัดการบัญชีเงินฝาก Design Classes

25 Group Classes into Subsystems
Withdrawal Transfers Dispensing Card Reader Dispenser Sensor Cash Counter Feeder Display Key Pad Client Manager <<subsystem>> ATM interface Transaction <<service subsystem>> Management Account Persistent Class <<sub system>> Bank Customer จากคลาส เราก็ทำการรวมกลุ่มคลาสที่ทำงานคล้ายๆกัน เข้าเป็นระบบย่อย หรือเป็น subsystem ซึ่งจากตัวอย่าง จะรวมกันได้เป็น 3 subsystem : ATM interface, Transaction Management, Account management. ซึ่งระบบย่อยจะติดต่อกันด้วย ความสัมพันธ์เช่น ATM จะติดต่อด้วยการ withdrawal ไปยัง transaction management ส่วน transaction management ส่งข้อมูลการ transfer data ไปยัง account ให้ปรับข้อมูลในบัญชี I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

26 Components that implements Design Classes
<<executable>> client.exe Client Manager <<trace>> <<file>> client.c Dispenser Feeder <<compilation>> Dispenser Sensor <<trace>> <<file>> dispenser.c Cash Counter จากคลาสต่างๆที่ออกแบบไว้ เราสามารถนำไป implement เป็น components ต่างๆที่สอดคล้องกัน I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, 1999.

27 Finding Classes Do we have information that should be stored or analyzed? It is a possible candidate for a class. The information might be concepts that must be always be registered in the system or events or transactions that occur at a specific moment. Do we have external system? If so, they are normally of interest when we model. Are there devices that system must handle ? Which roles do actors in the business play ? There roles can be seen as classes; for example, user, system operator, customer, and so on. เรากลับมาดูส่วนที่สำคัญของระบบคือ class ที่ใช้เก็บข้อมูล การหา คลาส เริ่มจาก 1 หาข้อมูลที่เราต้องการเก็บ หรือ ต้องการนำมาวิเคราะห์ 2 หาว่าเรามี ระบบภายนอกที่เกี่ยวข้องหรือไม่ โดยทั่วไปจะเป็นอะไรที่เราสนใจต่อไปในการออกแบบ 3 หาว่ามีอุปกรณ์อะไรที่ระบบเกี่ยวข้อง 4 ดูว่ามี actor อะไรบ้าง เพราะ actor เหล่านั้นอาจกลายมาเป็น class ในระบบของเรา

28 UML notation Active Class Classname Client OR Manager Class Name
Attributes Methods/ functions/ behaviors OR Active Class Has a thread and can initiate a control activity Client Manager วิธีการเขียน class diagram เริ่มต้นมี class ก่อน Class แสดงในรูปสี่เหลี่ยม 3 ชั้น ชั้นแรก เป็น ชื่อคลาส ชั้นสอง เป็น ลิสต์ของ attribute หรือคุณสมบัติ ของคลาส ชั้นสาม เป็น ลิสต์ของ methods ของคลาส บางครั้งทำเส้นทึบรอบสี่เหลี่ยมเพื่อบอกว่า คลาสนี้เป็นคอนโทรลคลาส

29 Class Diagram Card Reader Dispenser Sensor Cash Counter Feeder Display
Key Pad withdrawal Client Manager Transaction Account Persistent Class Bank Customer ตัวอย่างคลาสไดอะแกรม

30 Representation of Relationships between Classes
Dependency Navigable Association Association Generalization Aggregation: whole-part association Composition: the same life span การหาความสัมพันธ์ระหว่าง class มีหลายแบบ

31 Class Association We graphically illustrate the association (relationship) between two classes as a connecting line. Verb phrases describe the relationship. All relationships are implicitly bi-directional Multiplicity defines the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class. Because all relationships are bi-directional, multiplicity must be defined in both directions for every relationship. Association เป็นความสัมพันธ์ระหว่างคลาส 2 คลาส มีคำศัพท์อธิบายความสัมพันธ์เช่น คน กิน แอปเปิ้ล ถ้าไม่มีลูกศร แสดงว่าเป็น bi-directional บางครั้งมีจำนวนมาบอกด้วย ว่าความสัมพันธ์นี้ถ้าเป็น object จะมีได้ไม่เกินเท่าไหร่ ให้เขียนทั้งสองด้านของความสัมพันธ์ (คล้ายๆ multiplicity ใน E-R diagram)

32 Multiplicity 1 0..* 0..1 1..* Example 0..* 1..* owns owned by Car
UML Notation Example one or more one and only one zero or more zero or one Class name 1 0..* 0..1 1..* 0..* 1..* owns owned by Car Person การเขียน multiplicity ให้เขียนเป็นตัวเลขไว้หน้าสี่เหลี่ยมที่แทนคลาสได้เลย เครื่อง * หมายถึงมี ตั้งแต่ 0 ไปจนถึง infinity ... บอกว่าตั้งแต่เท่าไหร่ถึงเท่าไหร่ ถ้าไม่เขียนจะหมายถึง 1 H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

33 A class diagram: an Insurance business
1 Customer 1..* Insurance policy 0..1 contract Company 0..* ตัวอย่าง class diagram ที่มี multiplicity กำกับสำหรับความสัมพันธ์แบบ association H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

34 Aggregation objects/classes can be made up of other objects/classes. This relationship is called aggregation. It is also sometimes known as “whole-part” or “part-of” relationships. Ex., a BOOK object may contain several objects, including: COVER, TABLE OF CONTENTS, CHAPTER, and INDEX objects. The CHAPTER object contains PAGE objects, which in turn contain PARAGRAPH objects, which in turn contain WORD objects, and so forth. By identifying aggregation relationships we can partition a very complex object and assign behaviours and attributes to the individual objects within it. Multiplicity is also specified for aggregate relationships ความสัมพันธ์แบบ aggregation เป็นการย่อยคลาสใหญ่ให้ประกอบไปด้วยคลาสย่อยๆ เกิดเป็นความสัมพันธ์แบบ whole-part หรือ aggregation เช่น หนังสือประกอบไปด้วย ปก สารบัญ บทต่างๆ และ อินเด็กซ์ ส่วนมากการเขียนความสัมพันธ์แบบ aggregation จะพูดในระดับของ object หรือตัววัตถุที่ประกอบขึ้นมาเป็น วัตถุที่ซับซ้อนขึ้น

35 Aggregate Relationship
Book Cover Table of Contents Chapter Index Page Word Paragraph ตัวอย่างการเขียนความสัมพันธ์แบบ aggregation

36 Composition The ‘whole’ owns the instances of the parts. Those instances cannot belong to any other instance of the whole. Composition aggregation forms a tree structure. Aircraft Engine Wing Fuselage 2 1+ Door Landing Gear 2+ ความสัมพันธ์แบบ composition aggregation เป็นรูปแบบหนึ่งของ aggregation ที่บอกว่า object ที่เป็น parts (engine, wing, fuselage) จะมีชีวิตอยู่ระหว่างที่ whole ยังมีชีวิตอยู่ ถ้าส่วนของ whole ถูกลบออกไป object ของ part ก็จะหายไปด้วยเช่นกัน Part ไม่สามารถเป็นส่วนประกอบของ whole อื่นๆได้ ไม่เหมือนกับ aggregation แบบปกติ ที่ whole หายไปแล้วบางครั้ง part จะยังอยู่ ถ้ามันยังเป็นส่วนหนึ่งของ whole อันอื่น A part cannot belong to more than one whole

37 Generalization Inheritance implies that methods and/or attributes defined in an class can be inherited or reused by another class. Generalization / specialization attributes and behaviours that are common to several types of an object classes are grouped into their own class, called a supertype. Supertypes are generalizations of subtypes. Subtypes are specializations of supertypes. In the object class PERSON, STUDENT and PROFESSOR example, PERSON is referred to as a supertype (or generalization class) whereas STUDENT and PROFESSOR are referred to as subtypes (or specialization class). Generalization เป็นความสัมพันธ์แบบ inheritance หรือการสืบทอดคุณสมบัติระหว่าง superclass และ subclass

38 Generalization Relationship
walk talk sleep eat last name first name Person enrol Classification Student ID Student lecture rank Professor Supertype and Subtype relationship Between object classes ใช้สัญลักษณ์ สามเหลี่ยมโปร่ง ชี้จาก subclass ไปยัง superclass

39 Don’t confuse aggregation and inheritance
Aggregation relates to Instances Inheritance relates to Classes Plane Commercial Private Military 1 Engine Fuselage Wing 1+ 2 ให้สังเกตุว่า aggregation มักพูดถึง object แต่ inheritance พูดในระดับของ class

40 Class Diagram (Analysis Class + Design Class)
Use Case Actor เมื่อได้รายละเอียดของ class ก็จะทำให้ระบบของเราชัดเจนมากขึ้น

41 Dynamic Model State Diagram
Describe which states an object can have during its life cycle Sequence Diagram Describe how objects interact and communicate with each other The primary focus in sequence diagrams is time Collaboration Diagram Describe how objects interact But the focus in a collaboration diagram is space Activity Diagram But the focus in an activity diagram is work Class diagram ถือเป็นส่วนของ static model ในส่วนของ dynamic model ของระบบ สามารถอธิบายด้วย diagram ต่อไปนี้ 1 state diagram อธิบายสถานะที่เป็นไปได้ของ object ของ คลาส 1 คลาส ตั้งแต่เริ่มสร้างจนถูกทำลาย 2 sequence diagram อธิบายการติดต่อกันระหว่าง object ในระบบ โดยเน้นไปที่เวลาที่เกิดการติดต่อนั้น เวลาที่เกิดการทำงาน หรือเวลาที่ได้รับการตอบสนอง 3 collaboration diagram อธิบายการติดต่อระหว่าง object โดยเน้น ลำดับการทำงาน ไม่เน้นเวลา 4 activity diagram อธิบายการทำงานของ object ระหว่างที่เกิดเหตุการณ์ของ use-case ใดๆขึ้น ว่า object หรือ ระบบ ทำงานอะไรบ้าง ณ สถานการณ์ต่างๆ

42 State Model Represent the behavior of an object by a state transition diagram. State Diagrams chart the life-span of an object from creation to destruction and the discrete (finite) states in-between Event something that happens at a point in time. An event has no duration. For example, received messages, time-outs, error exceptions. State an abstraction of the attribute values and links of an object Activity an operation that takes time to perform closely associated with a state Action an operation performed on a state change อธิบายพฤติกรรมของ object ในการเขียน state model มีคำศัพท์ที่ควรรู้ดังนี้ Event เป็น เหตุการณ์ที่เกิดขึ้นในระบบ ณ เวลาใดเวลาหนึ่ง เกิดขึ้นจะจบไป เช่น ได้รับ message, หมดเวลา หรือการเกิด error State เป็น ค่าหรือสถานะที่เป็นไปได้ ของ attribute ของ object ณ เวลาหนึ่ง Activity เป็น การทำงาน ที่ใช้ช่วงเวลาจำนวนหนึ่งในการดำเนินการ ซึ่งเกี่ยวข้องกับ state ของ object Action เป็นการทำงานที่เกิดขึ้น เมื่อสถานะ หรือ state ของ object มีการเปลี่ยนแปลง หรือการทำงานที่ทำให้ state ของ object เกิดการเปลี่ยนแปลง

43 State diagram: notation
name of event which causes transition an action that is performed when the event occurs a pre-condition before a transition occurs State 2 . . . event [condition] /action Finish State State 1 do/activity 1 Starting point สัญลักษณ์ของ state diagram วงกลมสีดำ บอกจุดเริ่มต้นของ state diagram สี่เหลี่ยมบอก state ต่างๆ ที่เป็นไปได้ของ object หนึ่งๆ ที่เราสนใจ ณ state ใดๆ จะมี activity บอกว่า ณ state นี้ object มีพฤติกรรมอะไร หรือมีค่าอะไรเท่าไหร่ ลูกศร ชี้จาก state หนึ่งไปยังอีก state หนึ่ง บอก ทิศทางการเปลี่ยนแปลงของ state แต่ละลูกศรจะมี event หรือกิจกรรม หรือเหตุการณ์ที่ทำให้เกิดการเปลี่ยนแปลง จาก state ต้นทาง ไปยัง state ปลายทางของหัวลูกศร ใน event ที่เกิดขึ้น เราสามารถใส่ condition ไว้ได้ด้วย วงกลมไข่กบ เป็นตัวบอกจุดสิ้นสุดของ object H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

44 Example State Diagram Paid Unpaid Invoice created Invoice destroyed
Paying Unpaid Invoice created Invoice destroyed Invoice ใบส่งของ แจงรายละเอียดราคาสินค้า เกิด object invoice ขึ้นมาที่มีสถานะเป็น unpaid เมื่อเกิดเหตุการณ์ paying ขึ้น สถานะของ object invoice จะเปลียนเป็น paid และจบ object invoice นี้

45 Relationship between State Diagram and Class Diagram
A state diagram relates to ONE class within a class diagram. The received events are often messages that will have originated at one of the other classes with which the class in question has a relationship. Events are basically received messages and are therefore handled by a receiving class operation. Actions - happening upon a state transition - are usually class operations that may result in a message being sent to another object. Activities - happening within a particular class state - are usually class operations. ความสัมพันธ์ระหว่าง state diagram และ class diagram State diagram เกี่ยวข้องกับ class หนึ่งคลาส โดย Event จะเป็น message ที่คลาสนี้ได้จาก คลาสอื่นๆ Action เกิดขึ้นระหว่างการเปลี่ยนสถานะ ส่วนมากเป็น operation ของ class ที่ส่งไปยัง object อื่นๆ Activity เป็น operation ในคลาสนั้นๆ

46 A State Diagram Alarm System Passive Detected Monitor do/ ring bell
do/ check detectors access code typed in correct access code typed in Detected do/ ring bell flash lights Intruder alert/ phone police [30 seconds passed] ตัวอย่าง state diagram ระบบ alarm ระบบเริ่มที่ passive เมื่อมีการกดรหัส จะเปลี่ยนไปยัง state monitor ที่จะทำการตรวจเช็คผู้บุกรุก ถ้ามีผู้บุกรุกจะมีการ alert มีการ call police เมื่อผ่านไป 30 วินาที จะเข้าสู่ state detected ที่จะส่งสัญญานเตือนภัย และเกิด flash lights จะกลับไปสู่ state passive เมื่อมีการกดรหัสหยุดให้ถูกต้อง

47 Another Example - Digital Watch
A simple digital watch has a display and two buttons to set it, the A button and the B button. The watch has two modes of operation, display time and set time. In the display time mode, hours and minutes are displayed. The set time mode has two sub modes: set hours and set minutes. The A button is used to select modes. Each time it is pressed, it advances through the modes: display, set hours, set minutes, display ...etc. Within the sub modes, pressing B will advance the hours or minutes each time it is pressed. Buttons must be released before they generate another event. ……. Create a state diagram for the watch. ระบบ digital watch นาฬิกามี 2 ปุ่ม คือ A – B มีโหมดการทำงาน 2 โหมด คือ การแสดงเวลา และ การปรับเวลา ในโหมด การแสดงเวลา จะแสดง เวลาชั่วโมง และนาที ในโหมด การปรับเวลา มี 2 โหมดย่อย คือ ปรับชั่วโมง และ ปรับนาที ปุ่ม A ใช้ในการเปลี่ยนโหมดการทำงานของนาฬิกา จาก แสดงเวลา ไปเป็น การปรับเวลา และ วนกลับมาเป็น การแสดงเวลา เมื่ออยู่ในโหมดการปรับเวลา ไม่ว่าจะเป็น การปรับชั่วโมง หรือ ปรับนาที เมื่อกดปุ่ม B จะมีการเพิ่มเวลา ไม่ว่าชั่วโมง หรือ นาที ขึ้น 1 ค่า

48 Possible solution - State Diagram
Do:Flash hours Do:Flash minutes displaying time acquire setting hours setting minutes Pressed A Pressed B / increment hours Pressed B / increment minutes

49 Events in the state diagram correspond with operations within the class
Do:Flash hours Do:Flash minutes displaying time acquire setting hours setting minutes Pressed A Pressed B / increment hours Pressed B / increment minutes Digital-watch mode-button() inc() inc/minutes:=minutes+1 modulus 60 ตัวอย่าง การเขียนโปรแกรมจาก state diagram เช่น การปรับโหมด เป็น mode-button() inc() สำหรับการเพิ่มเวลา

50 Sequence Diagram Sequence Diagrams illustrate how objects (and actors) interact with each other - used to describe scenarios Objects communicate using messages messages are communications between objects that convey information with the expectation that something will happen Sequence diagrams have 2 axes objects along the horizontal axis lifeline (time) down the vertical axis messages represented by arrows objects lifeline (time) message Sequence diagram แสดงการติดต่อสื่อสารระหว่าง object และระหว่าง object กับ actor ด้วย message Sequence diagram มี 2 แกน Object จะอยู่ในแนวนอน เรียงตามลำดับการทำงาน แนวตั้งจะเป็นเวลา เริ่มจากบนลงล่าง เวลาจะเพิ่มขึ้นเรื่อยๆ message จะแสดงโดย ลูกศร จากต้นทางไปปลายทาง

51 Sequence Diagram: notation
function2() Self Delegation - an object sends a message to itself [condition] function() A conditional message (only sent if condition is true) Arguments go in here function() * function() Iteration - sent many times to multiple receiver objects object Object - we may also state this with its class name object: class สัญลักษณ์ สี่เหลี่ยม แทน object อาจเขียนเฉพาะชื่อ object หรือบอกชื่อ class กำกับ Message จะเป็นลูกศรพร้อมชื่อฟังก์ชันที่ใช้สื่อสารกัน ถ้ามีการเรียกซ้ำหลายๆครั้ง จะใช้เครื่องหมาย * กำกับ ถ้ามีการส่ง message ให้ตัวเอง หรือเป็นพวกฟังก์ชันเรียกตัวเอง ลูกศรจะชี้กลับมายัง object ที่เรียกได้ ถ้ามี condition กำกับ function ที่เรียก ก็สามารถเขียน condition ในวงเล็บสี่เหลี่ยมได้เลย โดยฟังก์ชันจะถูกส่งเมื่อ condition เป็นจริงเท่านั้น

52 Sequence Diagram : Card Reader : Cash Counter : Display : Key Pad
: Bank Customer : Card Reader : Cash Counter : Display : Key Pad : Client Manager : Transaction Insert card Card inserted (ID) Ask for PIN code Show request Specify PIN code PIN code (PIN) Request PIN validation (PIN) Ask for amount to withdraw Show request Specify amount Amount (A) Request cash availability ตัวอย่าง sequence diagram สำหรับการถอนเงิน วิธีการเขียน sequence diagram เริ่มจาก actor อยู่ทางซ้ายมือสุด actor ที่เป็นผู้เริ่ม use-case นั่นเอง ในตัวอย่างนี้ actor คือ bank customer Object แรกที่ actor ติดต่อด้วยจะเป็น object ที่อยู่เป็นลำดับถัดมา เช่น card reader เป็นคลาสที่ actor ติดต่อด้วย message : insert card() Request amount withdrawal (A)

53 Sequence Diagram: another example
Partial Class Diagram ReOrderItem itemnumber quantity etc… DeliveryItem deliveryadress quantity etc… Order orderNumber date etc… prepare() OrderLine check(): boolean remove() StockItem orderNumber minQuantity date etc… needsToReorder(): boolean is_for สมมติอีกตัวอย่าง ถ้าเรามี class diagram ดังภาพ เป็นบางส่วนของ class diagram เกี่ยวกับการสั่งสินค้า มี คลาส Order ซึ่งประกอบไปด้วย คลาส OrderLine โดย OrderLine แบ่งย่อยเป็น ReOrderItem และ DeliveryItem OrderLine มีความสัมพันธ์กับคลาส StockItem ที่เป็น item ที่สั่งอยู่ใน OrderLine

54 Sequence Diagram [needsToReorder=“true”] new prepare() *prepare()
check() [check=“true”] remove() needsToReorder() AReorder Item aDelivery Item anOrder Entry window anOrder anOrder Line aStock Item [check=“true”] new Sequence diagram นี้เริ่มต้นที่ an order entry window ที่เริ่มการสั่งซื้อสินค้า ด้วย message prepare() ไปยัง คลาส Order Class Order จะมี OrderLine มากกว่า 1 ครั้ง ใน OrderLine มี การติดต่อกับ StockItem ด้วย message check() ถ้า check() เป็นจริง 1 จะส่ง message remove() ไปยัง StockItem ใน StockItem มีการส่ง message needsToReOrder() ให้ตัวเอง ถ้า needsToReorder เป็นจริง จะมีการ new a reorderItem 2 ถ้า check() StockItem เป็นจริง จะ new aDeliveryItem

55 Collaboration Diagram
Collaboration diagrams focus on the interaction and the links between a set of collaborating objects. The sequence diagram focuses on time but the collaboration diagram focuses on space. Collaboration diagram ไม่เน้นเรื่องเวลา จะเน้นเรื่อง space ว่าอะไรติดต่อกับอะไรบ้าง

56 An example of a collaboration diagram
[printer free] 1.1: Print(ps-file) 1: Print(ps-file) Print(ps-file) :Computer :PrinterServer :Printer เช่น actor ติดต่อกับ class computer ด้วยคำสั่ง print (ps-file) Computer จะติดต่อกับ printerServer ด้วยคำสั่ง print (ps-file) PrinterServer ติดต่อกับ printer ด้วยคำสั่ง print (ps-file) โดยมี condition ว่า printer free จึงจะส่ง message print ไป H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

57 Activity Diagram Actions and Transitions
An activity diagram is essentially a flowchart, showing flow of control from activity to activity Actions and Transitions Show messageBox “Printing” on screen Create postscript file Send postscript file to printer Remove MessageBox Activity diagram เป็นคล้ายๆ flowchart การทำงาน โดยแสดง flow of control จาก activity หนึ่งไปยังอีก activity หนึ่ง สัญลักษณ์จะคล้ายกับ state diagram คือ เริ่มจาก วงกลมดำ และในแต่ละ activity จะแสดงอยู่ในสี่เหลี่ยม ลูกศรจะบอกลำดับการ flow ของแต่ละ activity และจบที่ วงกลมไข่กบ H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

58 Transitions are protected by guarded-conditions
CustomerWindow.PrintAllCustomer() Create postscript file Remove MessageBox ^Printer.Print(file) [disk full] Show messageBox “Disk full” on screen “Printingl” on ใน activity diagram อาจมี condition เช่น [disk full] ถ้า condition เป็นจริง จะทำ activity ที่ปลายลูกศร H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

59 Parallel Actions .Sampler.Run(channel,frequency) Initiate Updating
display Measuring บางครั้งสามารถมี activity แบบขนานได้ โดยใช้แถบ synchronize เพื่อบอกจุดเริ่มต้นและสิ้นสุดของ การทำงานแบบขนาน H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

60 Swim lanes Displayer Sampler Initiate Updating Measuring display
.Sampler.Run(channel,frequency) Initiate Updating display Measuring Displayer Sampler สังเกตได้ว่า activity diagram จะไม่ได้ระบุ object ที่แน่นอน จึงได้ทำเป็น lane บอกว่าเป็น activity ของ object ใด ถ้า activity กระทำโดย object ใดจะ อยู่ภายใน lane ของ object นั้นๆ เช่นในตัวอย่างมี object Sampler และ Displayer Activity – Initiate และ Measuring เป็นของ object Sampler ส่วน activity – Updating display เป็นของ object Displayer H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

61 Object Flow Displayer Sampler Initiate Updating Measured Measuring
.Sampler.Run(channel,frequency) Initiate Updating display Measuring Displayer Sampler Measured value บางครั้งใน activity เราสามารถใส่การส่ง message เพื่ออธิบายเพิ่มมากขึ้นได้ H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

62 Final Step of Modeling Definition of Static Structure and Dynamic Behavior Use case Actor เมื่อมีครบทุก diagram ของ Static structure และ Dynamic behavior แล้วถือว่าการออกแบบในด้านโครงสร้างได้เรียบร้อยลง

63 Concurrency View Deployment Component Use-Case View Concurrency
Logical Deployment State diagram Sequence diagram Collaboration diagram Activity diagram มาดูการออกแบบด้าน process ซึ่งจะเป็นเฉพาะ diagram ที่แสดงการทำงานของระบบเช่น State diagram, Sequence diagram, Collaboration diagram, Activity diagram H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

64 <<persistent>>
Class diagram 1 Supervisor Sound Alarm Log LCD Display Wrapper Keyboard Handler System Handler Cell Handler Sensor 1..* <<persistent>> System Configuration Information Cell H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

65 Collaboration diagram
: Supervisor : Sound Alarm : Log :Cell Handler :Photo Cell Sensor 1. Alarm :Phone :Sound 2a. Trigger 2b. Trigger 2c. Alarm 2c.1 Store (Date, Time, Cell, Sensor) 2c.2 Trigger :System Handler H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

66 Sequence diagram :System Handler :Cell :Sensor :Alarm Configuration
Information Read Configuration Config info returned Activate SelfTest ACK A B B - A < 5 sec Repeat for each installed alarm and sensor H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

67 State diagram Activation Phase Performing Alarm SelfTest Sensor
Activating sensor device Creating device list Initiating Thread loop System Activated Activation Failure / send ACK /send ACK Activate Command /Send ACK create List built success NAK Alarms Sensors Cell Handler H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

68 Control Flows Control flows are divided into concurrent threads that run in parallel and later become synchronized again. Activating Sensors Alarms Initiating Cell Handler System Inactive Activated Activation Failure “Activate System” command / Green light on H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

69 Component View Deployment Component Use-Case View Concurrency Logical
Component diagram แสดงองค์ประกอบย่อยในการ implement และ dependency ระหว่างองค์ประกอบเหล่านั้น H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

70 Example of a component diagram
Window Handler (whnd.obj) Main Class (main.cpp) (main.obj) Graphic lib (graphic.dll) Comm (comhnd.obj) Client Program (client.exe) (whnd.cpp) (comhnd.cpp) Source component Binary component Executable component แสดงองค์ประกอบย่อยในการ implement และ dependency ระหว่างองค์ประกอบเหล่านั้น ตัวอย่าง component diagram แสดงความสัมพันธ์ของ files ต่างๆ ในระบบ เราสามารถแบ่ง components โดยใช้คุณลักษณะของ components และประโยชน์ในการใช้งาน แบ่งเป็น 3 ประเภทคือ Source component: เป็นตัวแทนของเอกสารที่ใช้เก็บข้อมูลและ source code Binary component: เป็น component ที่ไม่สามารถประมวลผลได้ แต่เป็นที่เก็บของ object ต่างๆ ที่สามารถถูกนำไปใช้โดย Executable component Executable component: เป็น component ที่สามารถถูกประมวลผลได้ H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

71 Deployment View Deployment Component Use-Case View Concurrency Logical
Deployment diagram Use-Case View Concurrency Component Logical Deployment แสดงโครงสร้างทางกายภาพเกี่ยวกับ การติดตั้ง และ การใช้งานระบบ H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

72 <<Thread>>
Deployment diagram <<Thread>> Cell Handler Alarm Sensor System User Panel 1 1..* สัญลักษณ์จะแบ่งเป็นกล่องๆ และเขียนการติดต่อระหว่างกล่องเหล่านั่น H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

73 Node Device nodes and possible stereotype Bill’s Machine: Dell
node type an instance Bill’s Machine: Dell Pentium 466 MMX <<Printer>> HP LaserJet 5MP <<CarController>> SAAB 9-5 Navigator <<Router>> Cisco Router X2000 กล่องที่เห็นเรียกว่า Node ใช้แทน ชนิดของ อุปกรณ์ที่เกี่ยวข้องกับระบบที่เราพัฒนาเช่น มี node type เป็น Dell Pentium 466 แล้วมี instance เป็น คอมพิวเตอร์ Dell Pentium 466 ของ Bill และ อาจจะมี node type อื่นๆ เช่น Printer HP LaserJet, Cisco Router x2000 หรือ CarController SAAB 9-5 Navigator H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

74 Communication Association between nodes
ClientB: Compaq Pro PC ClientA: Database Server: VAX “TCP/IP” <<DecNet>> Application Silicon Graphics O2 การเชื่อมต่อระหว่าง node จะบอกชนิดของการเชื่อมต่อไว้ เช่น TCP/IP, DecNet, Serial Line , etc.. H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

75 <<library>>
Component Allocation A node type supporting a run-time component type, and a run-time component instance executing in a node instance Executable component instances may be contained within node instance symbols, showing that they reside and execute on the node instance <<library>> Transaction Client Library Bill’s Machine: Dell Pentium MMX PC Program Use the services of another component UNIX Transaction Server Program Silicon Graphics O2 <<support>> บางครั้งเราจะเขียนรายละเอียดว่า components ที่มีในระบบเก็บอยู่ใน Node ใดบ้าง

76 Object Allocation Objects are allocated to nodes. The transobj object that originally exists in the Main Server node can be distributed to the Dell PC node shown with the stereotype <<becomes>> Main Server: Quad Pentium PC Transaction Server Program transobj dlbobj callobj t1:updatethread Bill’s Machine: Dell Pentium MMX PC Client Program <<become>> และบางครั้งเราก็สามารถแสดงการทำงานของ object ว่าเกิดขึ้นที่ node ใดบ้าง H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.

77 Complex Modeling Server Backup Station NetDrv ApplClient Window95
Client PC NetDrv ApplClient Window95 Admin PC AdminPgm Backup Station Server 1 backupMedium 1..* 1..2 connected to ตัวอย่างของ complex modeling H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.