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

Review: Class เป็นนามธรรม (abstraction) ที่ใช้ในการแก้ไขปัญหา 12/7/2018 Review: Class เป็นนามธรรม (abstraction) ที่ใช้ในการแก้ไขปัญหา เป็นการกำหนดรายละเอียดคุณสมบัติของออปเจค ประกอบไปด้วย คุณสมบัติ (Properties) ในรูปของแอททริบิวต์ พฤติกรรมการทำงาน (Behavior) ในรูปของเมธอด ความสัมพันธ์ระหว่างกัน Window origin size open() close() name attributes operations

Review: Use-Case Realization 12/7/2018 Review: Use-Case Realization Design Model Use case model Use case realization Use case เป็นการแสดงรายละเอียดของยูสเคสภายในแบบจำลองของการออกแบบ แสดงรายละเอียดของยูสเคสในรูปของ collaborating ออปเจค ใช้ยูสเคสร่วมกับคลาสและความสัมพันธ์ของแบบจำลองในการออกแบบ กำหนดว่าคลาสใดที่จะถูกสร้างขึ้นในขั้นตอนการพัฒนาในแต่ละยูสเคส ใน UML จะถูกนำเสนอโดยใช้ class diagrams และ collaboration / sequence diagrams

From Requirement to Design สิ่งที่เป็นปัญหามากที่สุดในการพัฒนาระบบเชิงวัตถุคือการกำหนดการทำงานของระบบให้กับคลาสที่ออกแบบไว้ การแก้ไขอาจใช้ Sequence ไดอาแกรมเข้าช่วยในการออกแบบการทำงานของคลาส

From Requirement to Design วิธีการหนึ่งที่ได้ผลดีในทางปฏิบัติคือการใช้ Analysis Class มาใช้ร่วมกับคอแลบอเรชันไดอาแกรม เพื่อใช้สำหรับการลดช่องว่างระหว่างขั้นตอนของการกำหนดความต้องการของระบบและขั้นตอนการออกแบบระบบ

What is an Analysis Class? 12/7/2018 What is an Analysis Class? เป็นคลาสที่ใช้สำหรับการนำเสนอข้อมูลเบื้องต้นและพฤติกรรมตามความต้องการของระบบ ที่ยังไม่มีการกำหนดรายละเอียดในการทำงานไว้ Analysis class diagram เป็น UML ไดอาแกรมที่ใช้สำหรับการนำเสนอคลาสจากการวิเคราะห์และความสัมพันธ์ระหว่างกัน เทคนิคที่ใช้ในการค้นหาคลาสจากการวิเคราะห์จะอาศัยมุมมองในการทำงาน 3 ลักษณะภายในระบบ: ขอบเขตการทำงานระหว่างระบบและแอคเตอร์ ข้อมูลที่ระบบใช้ กลไกควบคุมทางลอจิกของระบบ

Find Classes from Use-Case Behavior 12/7/2018 Find Classes from Use-Case Behavior พฤติกรรมการทำงานที่สมบูรณ์ของยูสเคสจะถูกกระจายออกมาในรูปของ analysis classes

การวิเคราะห์คลาส (Analysis Classes) มาจากแนวคิดของจาคอบสันที่เรียกว่า Information Space ตามแนวแกนสามมิติ ได้แก่ Information, Behavior, Presentation Information Behavior Information Space Presentation

What is an Analysis Class? 12/7/2018 What is an Analysis Class? Entity classes are derived from the domain of the system. Boundary and control classes are ideal classes that are needed to describe the use cases inside the system. Introducing the concepts of Boundary and Controller classes in analysis and utilizing their canned responsibilities has provided a little of a “cook book” approach that some customers have been asking for. However, these class stereotypes can be misused. Proper usage of these concepts will be discussed on later slides. The purpose of the distinction between the different types of analysis classes was to think about the roles objects play, and making sure the behavior is allocated according to the forces which cause objects to change. Once these forces have been considered and there is a good class decomposition, the distinction is no longer really useful. All analysis classes do not have to have a stereotype. Just use the analysis class stereotypes when they help you. Don't feel that every analysis class you identify must have a stereotype (but make sure you qualify its existence). <<boundary>> <<boundary>> <<control>> <<control>> Use-case behavior coordination System boundary Analysis classes represent an early conceptual model for ‘things in the system which have responsibilities and behavior’. Analysis classes are used to capture a ‘first-draft’, rough-cut of the object model of the system. Analysis classes handle primarily functional requirements, and model objects from the "problem" domain. Analysis classes can be used to represent "the objects we want the system to support," without taking a decision on how much of them to support with hardware and how much with software. There are three aspects of the system that are likely to change: the boundary between the system and its actors, the information the system uses, and the control logic of the system. In an effort to isolate the parts of the system that will change, different types of analysis classes are identified, each with a “canned” set of responsibilities: boundary, entity and control classes. These distinctions are used during analysis, but disappear in design. The different types of analysis classes can be represented using different icons or with the name of the stereotype in guillemets (<< >>). Each of these types of analysis classes are discussed on the following slides. System information <<entity>> <<entity>>

Class Stereotypes for Analysis 12/7/2018 Class Stereotypes for Analysis การแยกส่วนที่เป็น user interface ออกจากส่วนที่เป็น logic จะช่วยให้การวิเคราะห์และออกแบบระบบสามารถทำได้ง่ายขึ้น ในการออกแบบด้วย UML จึงมีการนำเสนอสัญลักษณ์ที่ช่วยในการออกแบบในลักษณะดังกล่าว 3 แบบ คือ Boundary classes Control classes Entity classes Boundary Control Entity

12/7/2018 Boundary Class Boundary คลาสเป็นการนำเสนอการติดต่อกันระหว่างการทำงานภายในระบบกับการทำงานที่อยู่ภายนอก ซึ่งจะรวมไปถึงการติดต่อระหว่าง graphical user interface กับ actors ของระบบ Boundary คลาสจะทำหน้าที่ในการห่อหุ้มส่วนที่เหลือของระบบทั้งหมดจากส่วนที่อยู่ภายนอก ในทางปฎิบัติแล้วการติดต่อกันระหว่าง actor และ use case จะสามารถ maps เป็น boundary คลาสได้โดยตรง สัญลักษณ์ stereotype <<boundary>> จะถูกใช้ในการกำหนดว่าคลาสทำหน้าที่เป็น interface ของระบบ โดยการติดต่อคลาสที่อยู่ภายในระบบกับคลาสที่อยู่ภายนอก ในอดีตคลาสในลักษณะนี้จะถูกเรียกว่า interface class แต่ในเวลาต่อมาได้มีการเปลี่ยนเป็น boundary เนื่องจากเพื่อป้องกันความสับสนที่เกิดขึ้นจากคลาสที่เป็น interface ไปยัง component. ต่าง ๆ

Identify — Boundary Class 12/7/2018 Identify — Boundary Class กำหนด 1 boundary class สำหรับแต่ละ human actor นำเสนอ window หลักของ UI ที่ติดต่อกับ actor กำหนด 1 central boundary class สำหรับแต่ละ external system actor นำเสนอการติดต่อของส่วนที่เป็น interface ไปยัง external system central boundary classes สามารถเป็นส่วนประกอบของ boundary classes อื่น ๆ ได้ student Register for Courses Course Catalog System RegisterForCoursesForm CourseCatalogSystem

The Role of a Boundary Class 12/7/2018 The Role of a Boundary Class This diagram represents a collaboration diagram without any messages (it just contains objects and links). Collaboration diagrams are discussed in more detail later in this module. Customer A boundary class is a class used to model interaction between the system's surroundings and its inner workings. Such interaction involves transforming and translating events and noting changes in the system presentation (such as the interface). Boundary classes model the parts of the system that depend on its surroundings. Entity classes and control classes model the parts that are independent of the system's surroundings. Thus, changing the GUI or communication protocol should mean changing only the boundary classes, not the entity and control classes. Actors can only communicate with boundary classes. Boundary classes also make it easier to understand the system because they clarify the system's boundaries. They aid design by providing a good point of departure for identifying related services. For example, if you identify a printer interface early in the design, you will soon see that you must also model the formatting of printouts. A boundary object (an instance of a boundary class) can outlive a use case instance if, for example, it must appear on a screen between the performance of two use cases. Normally, however, boundary objects live only as long as the use case instance. Model interaction between the system and its environment

12/7/2018 Entity Class Entity คลาสเป็นการนำเสนอข้อมูลที่มีนัยสำคัญสำหรับระบบ โดยปกติแล้วจะข้อมูลเหล่านี้จะยังคงอยู่ในช่วงเวลาของการทำงาน จุดประสงค์หลักก็เพื่อนำเสนอและจัดการข้อมูลภายในระบบ สัญลักษณ์ stereotype <<entity>> จะถูกใช้สำหรับการกำหนดรายละเอียดของคลาสที่ใช้ในการจัดเก็บข้อมูลที่ถูกใช้โดยคลาสอื่น ๆ ใช้สำหรับการ encapsulates และ isolate changes สำหรับข้อมูลที่ต้องการนำเสนอ ถูกนำไป implemented โดยเป็นส่วนหนึ่งของระบบฐานข้อมูล entity class name <<entity>> entity class name

What is an Entity Class? Analysis class stereotype Use-Cases Glossary 12/7/2018 What is an Entity Class? Analysis class stereotype Use-Cases Glossary Business domain model Environment Independent Architectural Analysis Abstractions

Finding Entity Classes 12/7/2018 Finding Entity Classes ใช้ flow of events ของยูสเคสในรูปของ input โดยปกติจะได้มาจากคำนามที่ได้จากเอกสารประกอบความต้องการของระบบ เลือกคำนามที่ปรากฏอยู่ในคำอธิบายยูสเคส ตัดคำนามที่ redundant candidates ตัดคำนามที่ vague candidates ตัดคำนามที่เป็น actors (out of scope) ตัดคำนามที่เป็น implementation constructs ตัดคำนามที่เป็น attributes (save for later) ตัดคำนามส่วนที่เป็น operations

The Role of an Entity Class 12/7/2018 The Role of an Entity Class This diagram represents a collaboration diagram without any messages (it just contains objects and links). Collaboration diagrams are discussed in more detail later in this module. Entity classes represent stores of information in the system; they are typically used to represent the key concepts the system manages. Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system. The main responsibilities of entity classes are to store and manage information in the system. An entity object is usually not specific to one use-case realization; sometimes, an entity object is not even specific to the system itself. The values of its attributes and relationships are often given by an actor. An entity object may also be needed to help perform internal system tasks. Entity objects can have behavior as complicated as that of other object stereotypes. However, unlike other objects, this behavior is strongly related to the phenomenon the entity object represents. Entity objects are independent of the environment (the actors). Store and manage information in the system

12/7/2018 Control Class Control คลาสจะถูกใช้เป็นแบบจำลองพฤติกรรมการทำงานภายในระบบ Control คลาสไม่จำเป็นจะต้องนำไปใช้ในการพัฒนาโปรแกรมโดยตรง แต่อาจใช้เป็นแนวทางในการทำงานร่วมกับออปเจคอื่น ๆ เพื่อให้เป็นไปตามพฤติกรรมที่กำหนดไว้ภายใน use case แนวความคิดที่แยกส่วนที่เป็นพฤติกรรมออกจากส่วนที่เป็นข้อมูลและส่วนของการติดต่อกับผู้ใช้ จะช่วยให้ระบบมีความเป็นอิสระมากขึ้น และง่ายต่อการเปลี่ยนแปลงในภายหลัง สัญลักษณ์ที่ใช้สำหรับ stereotype <<control>> จะมีลักษณะดังนี้ control class name <<control>> control class name

Control Classes Provide Behavior that 12/7/2018 Control Classes Provide Behavior that มีลักษณะไม่ขึ้นกับส่วนอื่น ๆ (ไม่มีการเปลี่ยนแปลงเมื่อส่วนอื่น ๆ เปลี่ยนแปลงไป) กำหนดส่วนที่เป็น control logic (ลำดับของเหตุการณ์) และ transactions ที่อยู่ภายในยูสเคส มีการเปลี่ยนแปลงเล็กน้อยในกรณีที่โครงสร้างภายในหรือพฤติกรรมการทำงานของ entity classes มีการเปลี่ยนแปลง ใช้สำหรับการกำหนดค่าของหลาย ๆ entity classes ดังนั้นจึงจำเป็นต้องทำงานร่วมกับ behavior ของ entity classes เหล่านี้

Analysis Class — Control Class 12/7/2018 Analysis Class — Control Class โดยปกติแล้วจะทำการกำหนด 1 control class สำหรับแต่ละคู่ของ actor/use case responsible สำหรับการไหลของ events ภายใน use case การทำงานที่มีความซับซ้อนสูงอาจจำเป็นต้องแบ่งออกเป็นหลาย ๆ control classes ในภายหลัง ในทางกลับกันอาจมีความจำเป็นในการรวมหรือกำจัดบาง control classes ออกในภายหลัง control class จะต้องผูกติดกับอย่างน้อย 1 actor ป้องกันการเปลี่ยนแปลงโดยตรงไปยัง control logic

The Role of a Control Class 12/7/2018 The Role of a Control Class This diagram represents a collaboration diagram without any messages (it just contains objects and links). Collaboration diagrams are discussed in more detail later in this module. A control class is a class used to model control behavior specific to one or a few use cases. Control objects (instances of control classes) often control other objects, so their behavior is of the coordinating type. Control classes encapsulate use-case specific behavior. The behavior of a control object is closely related to the realization of a specific use case. In many scenarios, you might even say that the control objects "run" the use-case realizations. However, some control objects can participate in more than one use-case realization if the use-case tasks are strongly related. Furthermore, several control objects of different control classes can participate in one use case. Not all use cases require a control object. For example, if the flow of events in a use case is related to one entity object, a boundary object may realize the use case in cooperation with the entity object. You can start by identifying one control class per use-case realization, and then refine this as more use-case realizations are identified and commonality is discovered. Control classes can contribute to understanding the system because they represent the dynamics of the system, handling the main tasks and control flows. When the system performs the use case, a control object is created. Control objects usually die when their corresponding use case has been performed. Coordinate the use case behavior (stay tuned for collaboration diagrams)

ข้อแนะนำในการใช้ Analysis Class 12/7/2018 ข้อแนะนำในการใช้ Analysis Class การกำหนดจำนวนของ controllers ต่อหนึ่ง use case ควรอยู่ระหว่าง 2- 5 คลาส หากมีจำนวนของ controllers ต่อ use case เกินกว่า 10 ควรพิจารณาแยก use cases ออกเพื่อให้การจัดการสามารถทำได้ง่าย การใช้สัญลักษณ์ลูกศรระหว่างคลาสต่าง ๆ รวมไปถึง Actor จะมีข้อจำกัดดังต่อไปนี้ Actor สามารถติดต่อได้เฉพาะกับ Boundary คลาส Boundary Class สามารถติดต่อได้เฉพาะกับ Controller และ Actor Entity Class สามารถติดต่อได้เฉพาะ Controller Controller Class สามารถติดต่อได้ทั้ง Boundary และ Entity Class แต่ไม่สามารถติดต่อได้กับ Actor

Rules For Analysis Class Interactions 12/7/2018 Rules For Analysis Class Interactions Allow Not-Allow The refinement of the analysis classes is discussed in the design modules. Note: This course concentrates on the development of a design model. The maintenance of a separate analysis model would require modifications to the described process and is really out of the scope of this course. More examples: A single boundary class representing a user interface may result in multiple classes, one per window A control class may become a design class directly, or become a method within a design class A single entity class may become multiple classes (e.g., a aggregate with contained classes, or a class with associated database mapping or proxy classes, etc.) Analysis classes handle primarily functional requirements, and model objects from the "problem" domain; design elements handle non-functional requirements, and model objects from the "solution" domain. Throughout the design activities, analysis classes are refined into design elements (e.g., design classes, packages, subsystems etc.). In general, there is a many-to-many mapping between analysis classes and design elements: An analysis class can become one single class in the design model. An analysis class can become a part of a class in the design model. An analysis class can become an aggregate class in the design model. (Meaning that the parts in this aggregate may not be explicitly modeled in the analysis model.) An analysis class can become a group of classes that inherits from the same class in the design model. An analysis class can become a group of functionally related classes in the design model (e.g., a package). An analysis class can become a subsystem in the design model . An analysis class can become a relationship in the design model. A relationship between analysis classes can become a class in the design model. Part of an analysis class can be realized by hardware, and not modeled in the design model at all. Any combination of the above are also possible.

Example: Analysis Classes 12/7/2018 Example: Analysis Classes Student Note: This slide is a summary of all of the other example slides for this step. Register for Courses Course Catalog System Use Case Model RegistrationController MainForm CourseCatalogSystem For each use-case realization there is one or more class diagrams depicting its participating classes, along with their relationships. These diagrams help to ensure that there is consistency in the use case implementation across subsystem boundaries. Such class diagrams have been called “View of Participating Classes” diagrams (VOPC, for short). The diagram on this slide shows the classes participating in the “Register for Courses” use case. CourseCatalog Analysis Model

Principles Of Use Case Partitioning 12/7/2018 Principles Of Use Case Partitioning ในแต่ละ use case จะถูกแบ่งออกได้ดังนี้ : boundary classes entity classes control classes การทำงานที่เกี่ยวข้องโดยตรงกับสภาวะแวดล้อมของระบบประเภทการ นำเสนอ จะถูกกำหนดไว้ใน boundary classes การทำงานที่เกี่ยวข้องกับการจัดเก็บข้อมูลซึ่งไม่สามารถกำหนดไว้ใน boundary class ใด ๆ จะถูกกำหนดไว้ใน entity class แทน การทำงานที่มีลักษณะเป็นการควบคุมการทำงานทางลอจิก จะถูกกำหนดไว้ ใน control classes

ตัวอย่าง Sequence Diagram ที่ไม่ถูกต้อง 12/7/2018 ตัวอย่าง Sequence Diagram ที่ไม่ถูกต้อง

ตัวอย่าง Sequence Diagram ที่ถูกต้อง 12/7/2018 ตัวอย่าง Sequence Diagram ที่ถูกต้อง

Order Processing Use Case 12/7/2018 Order Processing Use Case Browse Product User Register Login Add to Shopping Cart View Order Status Card Authorization Customer Check Out Check Inventory Status View Shopping Cart Update Shopping Cart <<extend>> <<include>>

ตัวอย่าง Analysis Class 12/7/2018 ตัวอย่าง Analysis Class Register Login <<extend>> Customer Login LoginPage LoginDB Customer RegisterPage LoginController RegisterController RegisterDB Register

ตัวอย่าง Analysis Class ViewShopping ViewShoppingPage ViewShoppingDB Customer AddShoppingPage ViewShoppingController AddShoppingController AddShoppingDB ViewOrderPage ViewOrderController ViewOrderDB Card Authorization AddShoppingCart UpdatePage UpdateController UpdateDB Check Inventory CheckOutPage CheckOutDB CheckOutController LoginPage LoginDB User BrowsePage LoginController BrowseController BrowseDB

ตัวอย่าง Analysis Class 12/7/2018 ตัวอย่าง Analysis Class LoginPage LoginController LoginDB RegisterPage RegisterController RegisterDB AddShoppingPage AddShoppingController AddShoppingDB ViewShoppingPage ViewShoppingController ViewShoppingDB UpdateOrderPage UpdateOrderController UpdateDB

Project: Shopping Cart Use Case Name: Browse Product Actors: User Use case Referenced - Basic Flow 1 - ยูสเคสเริ่มต้นเมื่อผู้ใช้เลือกฟังก์ชัน Browse Product 2 - ระบบรับค่าจากผู้ใช้เลือก 3 - ระบบค้นหาข้อมูลประเภทสินค้าจากฐานข้อมูล 4 - ระบบคืนค่าประเภทสินค้าจากการค้นหา 5 - ระบบแสดงประเภทสินค้าทั้งหมดบนหน้าจอ 6 - ผู้ใช้เลือกประเภทสินค้าที่ต้องการดูข้อมูลในหน้าจอหลัก 7 - ระบบรับค่าประเภทสินค้าที่ผู้ใช้เลือก 8 - ระบบค้นหาข้อมูลสินค้าตามประเภทที่ผู้ใช้เลือก 9 - ระบบคืนค่าการค้นหาข้อมูลรายละเอียดสินค้า 10 - ระบบแสดงข้อมูลรายละเอียดสินค้าทั้งหมด 11 - ยูสเคสสิ้นสุดการทำงาน Alternate Flow Pre Condition(s): Post Condition(s):

12/7/2018 1 -ยูสเคสเริ่มต้นเมื่อผู้ใช้เลือกฟังก์ชัน Browse Product : User : Browse ProductController : ProductDB : BrowseProductPage 1 -ยูสเคสเริ่มต้นเมื่อผู้ใช้เลือกฟังก์ชัน Browse Product 2 -ระบบรับค่าจากผู้ใช้เลือก 3 -ระบบค้นหาข้อมูลประเภทสินค้าจาก ฐานข้อมูล 4 -ระบบคืนค่าประเภทสินค้าจากการค้นหา 5 -ระบบแสดงประเภทสินค้าทั้งหมดบน หน้าจอ 6 -ผู้ใช้เลือกประเภทสินค้าที่ต้องการดู ข้อมูลในหน้าจอหลัก 7 -ระบบรับค่าประเภทสินค้าที่ผู้ใช้เลือก 8 -ระบบค้นหาข้อมูลสินค้าตามประเภทที่ ผู้ใช้เลือก 9 -ระบบคืนค่าการค้นหาข้อมูลราย ละเอียดสินค้า 10 -ระบบแสดงข้อมูลรายละเอียดสินค้า ทั้งหมด getCatalog return Category return Product getProduct Open Browse Product get Browse Product From Customer Select Catalog get Catalog From Customer displayCategory displayProduct Category - CategoryId - CategoryName - CategoryGroup + getCatalog() + displayCategory() 1 n Product - productId - productName - pricePerUnit - qtyInStock + getProduct() + displayProduct()

Class Diagram : Specification Level 12/7/2018 Address - no - street - subDistrict - district - province - zipcode - telNo + getAddress() + findMaxAddress() Login - username - password + verifyLogin() + findMaxLogin() CheckOut - typeCreditCard - creditID - creditName - expirationDate + isAuthorization() Customer - name - lastName - gender - birthday - occupation - customerid + getCustomer() + generateCusId() + addCustomerAddress() n 1 Category - categoryId - categoryName - categoryDesc + getCatalog() + displayCatagory() Order - orderId - totalPrice - tax - orderDate - deliveryDate - statusDelivery + getOrderDetail() + addProduct() + checkStock() + updateStock() + updateQty() + checkStatus() + calculateTotal() 1..n Product - productId - productName - pricePerUnit - qtyInStock + getProduct() + displayProduct() OrderDetail - OrderDetailId - qty - sum + isDuplicateProduct() + calculateSum()