ดาวน์โหลดงานนำเสนอ
งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ
1
CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design)
Lecture 06: Object-Oriented Systems Analysis and Design Using UML
2
Major Topics Object-oriented concepts and terminology CRC Cards
Unified Modeling Language Use case and other UML diagrams Relationships Apr-17 CSE323 Systems Analysis and Design 2/2549
3
Object-Oriented Overview
วิธีการเชิงวัตถุ (Object-oriented techniques) ใช้ได้ผลดีเมื่อระบบที่มีความซับซ้อนได้รับการบำรุงรักษา ปรับปรุงเปลี่ยนแปลง และออกแบบอย่างต่อเนื่อง UML (The Unified Modeling Language) คือมาตรฐาน (industry standard) สำหรับการจำลองระบบเชิงวัตถุ Apr-17 CSE323 Systems Analysis and Design 2/2549
4
Goals of O-O Analysis เป้าหมายของการวิเคราะห์เชิงวัตถุ
การนำกลับมาใช้ใหม่คือเป้าหมายหลัก ระบบการบำรุงรักษาเป็นเป้าหมายที่สำคัญ การเปลี่ยนแปลงในออบเจ็กต์หนึ่งจะมีผลกระทบต่อออบเจ็กต์อื่นน้อยที่สุด Apr-17 CSE323 Systems Analysis and Design 2/2549
5
Object-Oriented Concepts
นิยามและแนวคิด: ออบเจ็กต์แทนสรรพสิ่งในโลกแห่งความเป็นจริง (real-world thing) หรือเหตุการณ์ (event) ออบเจ็กต์อาจเป็น ลูกค้า รายการ คำสั่งซื้อ ฯลฯ ออบเจ็กต์อาจเป็น GUI displays หรือ text areas on a display ออบเจ็กต์ถูกแทนด้วยคลาสและจัดป็นกลุ่มของคลาส คลาสหรือกลุ่มของคลาสมีคุณสมบัติและบริการหรือฟังก์ชันการทำงานร่วมกัน Instantiate เป็นคำที่ใช้เมื่อมีการสร้างออบเจ็กต์ขึ้นจากคลาส Attributes หรือแอททริบิวท์ คือลักษณะประจำหรือคุณสมบัติของคลาสที่ทุกออบเจ็กต์ในคลาสนั้นมี Method หรือเมทธอด คืองานอย่างใดอย่างหนึ่งที่สามารถเรียกใช้ได้จากออบเจ็กต์ในคลาส Apr-17 CSE323 Systems Analysis and Design 2/2549
6
Class Symbol สัญลักษณ์ของคลาส Apr-17
CSE323 Systems Analysis and Design 2/2549
7
Inheritance การสืบทอดคุณสมบัติ
คลาสเดิมจะเป็นคลาสแม่ (parent or base class) คลาสใหม่จะเป็นคลาสลูก (child or derived class) คลาสลูกได้รับการถ่ายทอดคุณสมบัติและบริการหรือฟังก์ชันการทำงานจากตลาสแม่ Apr-17 CSE323 Systems Analysis and Design 2/2549
8
CRC Cards การ์ด CRC (Class, responsibilities, and collaborators) ใช้สำหรับแสดงความรับผิดชอบของคลาสและปฏิสัมพันธ์ระหว่างคลาส การสร้างการ์ด CRC หาคำนามและคำกริยาในประโยคปัญหา สร้างสถานการณ์จำลอง (Scenarios) โดยพิจารณาจากการทำงานตามจริงของระบบ ระบุและกำหนดความรับผิดชอบให้กับงานชิ้นเล็กลงและเล็กลงเรื่อยๆเท่าที่จะทำได้ พิจาณาว่างานต่างๆทำได้โดยออบเจ็กต์หรือการโต้ตอบกับออบเจ็กต์อื่นไอย่างไร ระบุความรับผิดชอบที่เกี่ยวข้องเป็นเมทธอดหรือฟังก์ชันการทำงาน Apr-17 CSE323 Systems Analysis and Design 2/2549
9
The Unified Modeling Language (UML)
UML has three categories: สิ่งต่างๆ หรือ ออบเจ็กต์ (Things, the objects) ความสัมพันธ์ (Relationships, the glue that holds things together) แผนภาพ (Diagrams, categorized as either structure or behavioral) Apr-17 CSE323 Systems Analysis and Design 2/2549
10
Two General Groupings of Things
กลุ่มของส่งต่างๆใน UML: Structural things ซึ่งใช้กำหนดโครงสร้างตามแนวคิดและโครงสร้างทางกายภาพของระบบเชิงวัตถุ และอธิบายด้วยคำนาม Behavioral things เป็นคำกริยาในแบบจำลอง UML ที่ใช้แทนพฤติกรรมของระบบ และสถานะของระบบ ก่อน ระหว่าง และหลัง เมื่อมีพฤติกรรมดังกล่าวเกิดขึ้น Apr-17 CSE323 Systems Analysis and Design 2/2549
11
Structural and Behavioral Things
Structural things ได้แก่: Classes. Use cases. Interfaces. Behavioral things ได้แก่: Interactions State machines Apr-17 CSE323 Systems Analysis and Design 2/2549
12
Types of Relationships
ประเภทของความสัมพันธ์: Structural relationships ผูกสิ่งต่างๆเข้าด้วกันในแผนภาพโครงสร้าง (Structural diagram) Behavioral relationship ใช้ในแผนภาพเหตุการณ์ (Behavioral diagrams) Apr-17 CSE323 Systems Analysis and Design 2/2549
13
Structural and Behavioral Relationships
Structural relationships ได้แก่: Dependencies. Aggregations. Associations. Generalizations. Behavioral relationships ได้แก่: Communicates. Includes. Extends. Generalizes. Apr-17 CSE323 Systems Analysis and Design 2/2549
14
Structural and Behavioral Diagrams
Structural things are the most common and include: Class and object diagrams. Use case diagrams. Component diagrams. Deployment diagrams. Behavioral things include: Use case diagrams. Sequence diagrams. Collaboration diagrams. Statechart diagrams. Activity diagrams. Apr-17 CSE323 Systems Analysis and Design 2/2549
15
Commonly Used UML Diagrams
แผนภาพยูสเคส (Use case diagram) อธิบายว่าระบบถูกใช้อย่างไร เป็นจุดเริ่มต้นสำหรับแบบจำลอง UML ยูสเคส (Use case - not a diagram) แผนภาพกิจกรรม (Activity diagram) แต่ละยูสเคสอาจสร้างแผนภาพกิจกรรม แผนภาพลำดับเหตุการณ์ (Sequence diagram) แสดงลำดับเหตุการณ์ของกิจกรรมต่างๆและความสัมพันธ์ชองคลาส แต่ละยูสเคสอาจสร้างหนึ่งหรือหลายแผนภาพลำดับเหตุการณ์ A collaboration diagram is an alternative to a sequence diagram. Apr-17 CSE323 Systems Analysis and Design 2/2549
16
Commonly Used UML Diagrams
แผนภาพคลาส (Class diagram) แสดงคลาสต่างๆและความสัมพันธ์ของคลาส แผนภาพลำดับเหตุการณ์ (Sequence diagrams) และการ์ด CRC ใช้ในการกำหนดคลาส แผนภาพสถานะ (Statechart diagram) แต่ละคลาสสามารถสร้างแผนภาพสถานะ ซึ่งมีประโยชน์ในการกำหนดเมทธอดของคลาส Apr-17 CSE323 Systems Analysis and Design 2/2549
17
Overview of UML Diagrams
Apr-17 CSE323 Systems Analysis and Design 2/2549
18
Use Case Diagram A use case describes what the system does, not how it does the work. The use case model reflects the view of the system of the user outside of the system. Symbols are: Actor, a stick figure. Use case, an oval. Connecting lines. Apr-17 CSE323 Systems Analysis and Design 2/2549
19
Actors Represent role played by one or more users
Exist outside of the system May be a person, another system, a device, such as a keyboard or Web connection Can initiate an instance of a use case May interact with one or more use cases and a use case may involve one or more actors Apr-17 CSE323 Systems Analysis and Design 2/2549
20
Actors (Cont.) Actors may be divided into two groups:
Primary actors supply data or receive information from the system Secondary actors help to keep the system running or provide help Help desk, analysts, programmers, etc. Apr-17 CSE323 Systems Analysis and Design 2/2549
21
Use Case Consists of three things:
An actor (user) that initiates an event. An event that triggers a use case. The use case that performs the actions triggered by the event. Apr-17 CSE323 Systems Analysis and Design 2/2549
22
Use Case (Cont.) Better to create fewer use cases
20 use cases for a large system 50 use cases would be the maximum for a large system Can nest use cases, if needed Apr-17 CSE323 Systems Analysis and Design 2/2549
23
Use Case Relationships
Communicates Connect an actor to a use case Includes Use case contains a behavior that is common to more than one use case. The common use case is included in other use cases. Dotted arrow points toward common use case. Apr-17 CSE323 Systems Analysis and Design 2/2549
24
Use Case Relationships (Continued)
Extends A different use case handles variations or exceptions from the basic use case. Arrow goes from extended to basic use case. Generalizes One thing is more general than another thing. Arrow points to the general thing. Apr-17 CSE323 Systems Analysis and Design 2/2549
25
Use Case Relationships
Apr-17 CSE323 Systems Analysis and Design 2/2549
26
Steps for Creating a Use Case Model
The steps required to create a use case model are: Review the business specifications and identify the actors within the problem domain. Identify the high-level events and develop the primary use cases that describe the events and how actors initiate them. Review each primary use case to determine possible variations of flow through the use case. Develop the use case documents for all primary use cases and all important use case scenarios. Apr-17 CSE323 Systems Analysis and Design 2/2549
27
Use Case Scenario A use case scenario may be created for the standard flow through the use case. Other scenarios may be created for variations on the main flow. A use case includes: Use case identifiers and initiators. Steps performed. Conditions, assumptions, and questions. Apr-17 CSE323 Systems Analysis and Design
28
Activity Diagrams Activity diagrams show the sequence of activities in a process, including sequential and parallel activities. Symbols are used for activities, decisions and so on. Arrows represent events that connect the activities. Apr-17 CSE323 Systems Analysis and Design 2/2549
29
Activity Diagram Symbols
Apr-17 CSE323 Systems Analysis and Design 2/2549
30
Creating Activity Diagrams
Ask what happens first, second, and so on. Determine if the activities happen in sequence or parallel. Examine all the scenarios for a use case. Apr-17 CSE323 Systems Analysis and Design 2/2549
31
Swimlanes Included on activity diagrams to show partitioning
Show which activities: Occur on a browser Occur on a server Happen on a mainframe Are done by external partners Help to divide tasks among team members Apr-17 CSE323 Systems Analysis and Design
32
Swimlane Boundaries When an event crosses swimlane boundaries, data must be transmitted. A Web form is sent to a server. Data are placed into middleware to transmit it between a server and a mainframe. Data are transmitted to and from an external partner. Apr-17 CSE323 Systems Analysis and Design 2/2549
33
Sequence Diagrams Sequence diagrams show a succession of interactions between classes or object instances over time. It also shows the processing described in a single scenario. The leftmost object is the starting object. Time sequence is from top to bottom. Apr-17 CSE323 Systems Analysis and Design 2/2549
34
Sequence Diagrams (Cont.)
Horizontal arrows represent messages or signals sent between classes. Solid arrowheads represent synchronous calls, the sending class waits for a response. Half or open arrowheads represent asynchronous calls, those sent without waiting for a returning signal. Apr-17 CSE323 Systems Analysis and Design 2/2549
35
Message Name Formats Message names may be in the following formats:
messageName(parameter1, parameter2, …) messageName(parameterType:parameterName)(defaultValue) Apr-17 CSE323 Systems Analysis and Design 2/2549
36
Sequence Diagram Example
Apr-17 CSE323 Systems Analysis and Design 2/2549
37
Collaboration Diagrams
Collaboration Diagrams show the same information as a sequence diagram. The emphasis is on the organization of the objects. Sequence is shown by including a sequence number on the message. Apr-17 CSE323 Systems Analysis and Design 2/2549
38
Collaboration Diagram Example
Apr-17 CSE323 Systems Analysis and Design 2/2549
39
Class Diagrams and Class Attributes
Class diagrams show classes, attributes, and operations or methods. A class is shown as a rectangle. Attributes are either: Private (the norm), indicated by a minus sign. Public, indicated by a plus sign. Protected, indicated by a pound sign (#). Attributes may include the type of data and any initial value. Methods are usually public. Apr-17 CSE323 Systems Analysis and Design 2/2549
40
Method Overloading Method overloading is including the same method several times in a class. The method signature, its name and parameters, and type of parameters, must be different. Apr-17 CSE323 Systems Analysis and Design 2/2549
41
Types of Classes Classes fall into several categories:
Entity classes. Boundary or interface classes. Abstract classes. Control classes. Each class may use a special symbol, called a UML stereotype. Apr-17 CSE323 Systems Analysis and Design 2/2549
42
Entity Classes Entity classes represent real-world items.
Attributes are those stored for the entity. Methods work with the entity. Apr-17 CSE323 Systems Analysis and Design 2/2549
43
Boundary or Interface Classes
Provide a means for users to work with the system. Display screens, windows, dialogue boxes, touch-tone telephone, external systems. Methods required to send or reset the display screen, or to produce a report. Apr-17 CSE323 Systems Analysis and Design 2/2549
44
Abstract Classes Abstract classes are the parent or general class in a generalization/specialization relationship. Abstract classes may not be directly instantiated. Only the child classes can create objects. Apr-17 CSE323 Systems Analysis and Design 2/2549
45
Control or Active Classes
Control or active classes are used to control the flow of activities. Many small control classes may be included to achieve reuse. Attributes are those needed temporarily by the control class. Methods are those used in control activities . Apr-17 CSE323 Systems Analysis and Design 2/2549
46
Sequence Diagram for using two Web pages: one for student information, one for course information.
Apr-17 CSE323 Systems Analysis and Design 2/2549
47
Relationships on a Class Diagram
Relationships are the connections between classes and include: Associations, showing the one-to-many relationships between classes. An asterisk (*) is used to represent many. Association classes are used to break up a many-to-many association between classes. Apr-17 CSE323 Systems Analysis and Design 2/2549
48
Association Class Example
Apr-17 CSE323 Systems Analysis and Design 2/2549
49
Whole/Part Relationships
One class represents the whole, other classes represent the parts contained in the whole. Three types of whole/part relationships: Aggregation. Collection. Composition. Apr-17 CSE323 Systems Analysis and Design 2/2549
50
Aggregation Aggregation is a “has a” relationship.
The whole is composed of the sum of the parts. If the whole is removed, the part may still exist. The diamond at the end of the line is not filled in. Apr-17 CSE323 Systems Analysis and Design 2/2549
51
Collection Consists of a whole and its members
Examples are a library with books or a voting district with voters If the part is removed, the whole retains its identity A weak association Apr-17 CSE323 Systems Analysis and Design 2/2549
52
Composition The whole has a responsibility for the parts, and is a stronger relationship. If the whole is removed, the parts are removed Shown with a filled-in diamond on the line Example: an insurance policy with riders Apr-17 CSE323 Systems Analysis and Design 2/2549
53
Whole/Part Example Apr-17 CSE323 Systems Analysis and Design 2/2549
54
Generalization/Specialization Diagrams
Generalization/specialization or gen/spec diagrams show the relationship between a more general thing and a specific kind of thing. This relationship is described as an “is a” relationship. For example: a car is a vehicle, a truck is a vehicle. Generalization relationship is used to model inheritance. General class is a parent, base, or superclass. Specialized class is a child, derived, or subclass. Apr-17 CSE323 Systems Analysis and Design 2/2549
55
Polymorphism Polymorphism or method overriding is when a method is defined in several classes in a gen/spec relationship. The subclass overrides the parent class attributes and/or methods. If a number of classes are involved, the most specific class is used. Apr-17 CSE323 Systems Analysis and Design 2/2549
56
Gen/Spec Example Apr-17 CSE323 Systems Analysis and Design 2/2549
57
Finding Classes Classes may be discovered:
During interviews or JAD sessions. During brainstorming sessions. By using CRC cards. By examining use cases, looking for nouns. Each noun may lead to a candidate or potential class. Apr-17 CSE323 Systems Analysis and Design 2/2549
58
Determining Class Methods
Class methods may be determined by: Using a CRUD matrix. Looking at messages sent between classes. The receiving class must have the message name as a method. Using statechart diagrams. Apr-17 CSE323 Systems Analysis and Design 2/2549
59
Statechart Diagrams Statechart diagrams show class states and the events that cause them to transition between states. It is also called a state transition diagram An event happens at a specific time and place. They cause a change of state, or the transition “fires” Apr-17 CSE323 Systems Analysis and Design 2/2549
60
Statechart Diagrams (Cont.)
Each time an object changes state, some of its attributes must change. There must be a method to change the attributes. Often there is a display screen or Web form to enter the attributes. Apr-17 CSE323 Systems Analysis and Design 2/2549
61
Statechart Diagrams (Cont.)
Statechart diagrams are not created for all classes. They are created when: A class has a complex life cycle. An instance of a class may update its attributes in a number of ways through the life cycle. A class has an operational life cycle. Two classes depend on each other. The object’s current behavior depends on what happened previously. Apr-17 CSE323 Systems Analysis and Design 2/2549
62
Statechart Example Apr-17 CSE323 Systems Analysis and Design 2/2549
63
Packages Containers for other UML things Show system partitioning
Indicate which use cases or classes are grouped into a subsystem Can show component packages Can be physical subsystems Use a folder symbol Apr-17 CSE323 Systems Analysis and Design 2/2549
64
Package Example Apr-17 CSE323 Systems Analysis and Design 2/2549
65
Steps Used in UML Define the use case model.
The steps used in UML are: Define the use case model. Continue UML diagramming to model the system. during the systems analysis phase. Develop the class diagrams. Draw statechart diagrams. Begin systems design by refining the UML diagrams. Document your system design in detail. Apr-17 CSE323 Systems Analysis and Design 2/2549
66
Next Lecture Object Interaction and Specifying Operations Apr-17
CSE323 Systems Analysis and Design 2/2549
งานนำเสนอที่คล้ายกัน
