งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

Www.themegallery.com CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 06: Object-Oriented Systems Analysis and Design Using UML.

งานนำเสนอที่คล้ายกัน


งานนำเสนอเรื่อง: "Www.themegallery.com CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 06: Object-Oriented Systems Analysis and Design Using UML."— ใบสำเนางานนำเสนอ:

1 CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 06: Object-Oriented Systems Analysis and Design Using UML

2 CSE323 Systems Analysis and Design 2/ Aug-14 Major Topics  Object-oriented concepts and terminology  CRC Cards  Unified Modeling Language  Use case and other UML diagrams  Relationships

3 CSE323 Systems Analysis and Design 2/ Aug-14 Object-Oriented Overview  วิธีการเชิงวัตถุ (Object-oriented techniques) ใช้ ได้ผลดีเมื่อระบบที่มีความซับซ้อนได้รับการบำรุงรักษา ปรับปรุงเปลี่ยนแปลง และออกแบบอย่างต่อเนื่อง  UML (The Unified Modeling Language) คือ มาตรฐาน (industry standard) สำหรับการจำลอง ระบบเชิงวัตถุ

4 CSE323 Systems Analysis and Design 2/ Aug-14 Goals of O-O Analysis เป้าหมายของการวิเคราะห์เชิงวัตถุ  การนำกลับมาใช้ใหม่คือเป้าหมายหลัก  ระบบการบำรุงรักษาเป็นเป้าหมายที่สำคัญ  การเปลี่ยนแปลงในออบเจ็กต์หนึ่งจะมีผลกระทบต่อ ออบเจ็กต์อื่นน้อยที่สุด

5 CSE323 Systems Analysis and Design 2/ Aug-14 Object-Oriented Concepts นิยามและแนวคิด:  ออบเจ็กต์แทนสรรพสิ่งในโลกแห่งความเป็นจริง (real- world thing) หรือเหตุการณ์ (event)  ออบเจ็กต์อาจเป็น ลูกค้า รายการ คำสั่งซื้อ ฯลฯ  ออบเจ็กต์อาจเป็น GUI displays หรือ text areas on a display  ออบเจ็กต์ถูกแทนด้วยคลาสและจัดป็นกลุ่มของคลาส  คลาสหรือกลุ่มของคลาสมีคุณสมบัติและบริการหรือฟังก์ชัน การทำงานร่วมกัน Instantiate เป็นคำที่ใช้เมื่อมีการสร้างออบเจ็กต์ขึ้นจากคลาส Attributes หรือแอททริบิวท์ คือลักษณะประจำหรือคุณสมบัติของ คลาสที่ทุกออบเจ็กต์ในคลาสนั้นมี Method หรือเมทธอด คืองานอย่างใดอย่างหนึ่งที่สามารถเรียกใช้ได้ จากออบเจ็กต์ในคลาส

6 CSE323 Systems Analysis and Design 2/ Aug-14 Class Symbol สัญลักษณ์ของคลาส

7 CSE323 Systems Analysis and Design 2/ Aug-14 Inheritance การสืบทอดคุณสมบัติ  การสืบทอดคุณสมบัติ (Inheritance) เกิดขึ้นเมื่อมีการ สร้างคลาสขึ้นใหม่จากคลาสที่มีอยู่แล้ว  คลาสเดิมจะเป็นคลาสแม่ (parent or base class)  คลาสใหม่จะเป็นคลาสลูก (child or derived class)  คลาสลูกได้รับการถ่ายทอดคุณสมบัติและบริการหรือ ฟังก์ชันการทำงานจากตลาสแม่

8 CSE323 Systems Analysis and Design 2/ Aug-14 CRC Cards การ์ด CRC การ์ด CRC (Class, responsibilities, and collaborators) ใช้สำหรับแสดงความรับผิดชอบของคลาสและปฏิสัมพันธ์ ระหว่างคลาส การสร้างการ์ด CRC  หาคำนามและคำกริยาในประโยคปัญหา  สร้างสถานการณ์จำลอง (Scenarios) โดยพิจารณาจากการทำงานตาม จริงของระบบ  ระบุและกำหนดความรับผิดชอบให้กับงานชิ้นเล็กลงและเล็กลงเรื่อยๆ เท่าที่จะทำได้  พิจาณาว่างานต่างๆทำได้โดยออบเจ็กต์หรือการโต้ตอบกับออบเจ็กต์ อื่นไอย่างไร  ระบุความรับผิดชอบที่เกี่ยวข้องเป็นเมทธอดหรือฟังก์ชันการทำงาน

9 CSE323 Systems Analysis and Design 2/ Aug-14 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)

10 CSE323 Systems Analysis and Design 2/ Aug-14 Two General Groupings of Things กลุ่มของส่งต่างๆใน UML:  Structural things  Structural things ซึ่งใช้กำหนดโครงสร้างตามแนวคิดและ โครงสร้างทางกายภาพของระบบเชิงวัตถุ และอธิบายด้วย คำนาม  Behavioral things  Behavioral things เป็นคำกริยาในแบบจำลอง UML ที่ใช้ แทนพฤติกรรมของระบบ และสถานะของระบบ ก่อน ระหว่าง และหลัง เมื่อมีพฤติกรรมดังกล่าวเกิดขึ้น

11 CSE323 Systems Analysis and Design 2/ Aug-14 Structural and Behavioral Things Structural things ได้แก่:  Classes.  Use cases.  Interfaces. Behavioral things ได้แก่:  Interactions  State machines

12 CSE323 Systems Analysis and Design 2/ Aug-14 Types of Relationships ประเภทของความสัมพันธ์:  Structural relationships  Structural relationships ผูกสิ่งต่างๆเข้าด้วกันในแผนภาพ โครงสร้าง (Structural diagram)  Behavioral relationship  Behavioral relationship ใช้ในแผนภาพเหตุการณ์ (Behavioral diagrams)

13 CSE323 Systems Analysis and Design 2/ Aug-14 Structural and Behavioral Relationships Structural relationships ได้แก่:  Dependencies.  Aggregations.  Associations.  Generalizations.  Behavioral relationships ได้แก่:  Communicates.  Includes.  Extends.  Generalizes.

14 CSE323 Systems Analysis and Design 2/ Aug-14 Structural and Behavioral Diagrams Structural things are the most common and include: 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.

15 CSE323 Systems Analysis and Design 2/ Aug-14 Commonly Used UML Diagrams แผนภาพที่ใช้กันโดยทั่วไปใน UML:  แผนภาพยูสเคส  แผนภาพยูสเคส (Use case diagram) อธิบายว่าระบบถูกใช้ อย่างไร เป็นจุดเริ่มต้นสำหรับแบบจำลอง UML  ยูสเคส  ยูสเคส (Use case - not a diagram)  แผนภาพกิจกรรม  แผนภาพกิจกรรม (Activity diagram) แต่ละยูสเคสอาจสร้างแผนภาพกิจกรรม  แผนภาพลำดับเหตุการณ์  แผนภาพลำดับเหตุการณ์ (Sequence diagram) แสดง ลำดับเหตุการณ์ของกิจกรรมต่างๆและความสัมพันธ์ชอง คลาส แต่ละยูสเคสอาจสร้างหนึ่งหรือหลายแผนภาพลำดับเหตุการณ์ A collaboration diagram is an alternative to a sequence diagram.

16 CSE323 Systems Analysis and Design 2/ Aug-14 Commonly Used UML Diagrams แผนภาพที่ใช้กันโดยทั่วไปใน UML (ต่อ):  แผนภาพคลาส  แผนภาพคลาส (Class diagram) แสดงคลาสต่างๆและ ความสัมพันธ์ของคลาส แผนภาพลำดับเหตุการณ์ (Sequence diagrams) และการ์ด CRC ใช้ในการกำหนดคลาส  แผนภาพสถานะ  แผนภาพสถานะ (Statechart diagram) แต่ละคลาสสามารถสร้างแผนภาพสถานะ ซึ่งมีประโยชน์ในการ กำหนดเมทธอดของคลาส

17 CSE323 Systems Analysis and Design 2/ Aug-14 Overview of UML Diagrams

18 CSE323 Systems Analysis and Design 2/ Aug-14 Use Case Diagram use case what the system does  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.

19 CSE323 Systems Analysis and Design 2/ Aug-14 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

20 CSE323 Systems Analysis and Design 2/ Aug-14 Actors (Cont.) Actors may be divided into two groups:  Primary actors  Primary actors supply data or receive information from the system  Secondary actors  Secondary actors help to keep the system running or provide help Help desk, analysts, programmers, etc.

21 CSE323 Systems Analysis and Design 2/ Aug-14 Use Case  Consists of three things:  An actor  An actor (user) that initiates an event.  An event  An event that triggers a use case.  The use case that performs the actions triggered by the event.

22 CSE323 Systems Analysis and Design 2/ Aug-14 Use Case (Cont.)  Better to create fewer use cases  20  20 use cases for a large system  50maximum for a large system  50 use cases would be the maximum for a large system  Can nest use cases, if needed

23 CSE323 Systems Analysis and Design 2/ Aug-14 Use Case Relationships  Communicates  Connect an actor to a use case  Includes common to more than one use case.  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  Dotted arrow points toward common use case.

24 CSE323 Systems Analysis and Design 2/ Aug-14 Use Case Relationships (Continued)  Extends handles variations or exceptions from the basic use case  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  Arrow points to the general thing.

25 CSE323 Systems Analysis and Design 2/ Aug-14 Use Case Relationships

26 CSE323 Systems Analysis and Design 2/ Aug-14 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.

27 CSE323 Systems Analysis and Design 27 Aug-14 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.

28 CSE323 Systems Analysis and Design 2/ Aug-14 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.

29 CSE323 Systems Analysis and Design 2/ Aug-14 Activity Diagram Symbols

30 CSE323 Systems Analysis and Design 2/ Aug-14 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.

31 CSE323 Systems Analysis and Design 31 Aug-14 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

32 CSE323 Systems Analysis and Design 2/ Aug-14 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.

33 CSE323 Systems Analysis and Design 2/ Aug-14 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.

34 CSE323 Systems Analysis and Design 2/ Aug-14 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.

35 CSE323 Systems Analysis and Design 2/ Aug-14 Message Name Formats Message names may be in the following formats: messageName() messageName(parameter1, parameter2, …) messageName(parameterType:parameterName)(defaultValue)

36 CSE323 Systems Analysis and Design 2/ Aug-14 Sequence Diagram Example

37 CSE323 Systems Analysis and Design 2/ Aug-14 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.

38 CSE323 Systems Analysis and Design 2/ Aug-14 Collaboration Diagram Example

39 CSE323 Systems Analysis and Design 2/ Aug-14 Class Diagrams and Class Attributes  Class diagrams  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.

40 CSE323 Systems Analysis and Design 2/ Aug-14 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.

41 CSE323 Systems Analysis and Design 2/ Aug-14 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.

42 CSE323 Systems Analysis and Design 2/ Aug-14 Entity Classes  Entity classes represent real-world items.  Attributes are those stored for the entity.  Methods work with the entity.

43 CSE323 Systems Analysis and Design 2/ Aug-14 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.

44 CSE323 Systems Analysis and Design 2/ Aug-14 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.

45 CSE323 Systems Analysis and Design 2/ Aug-14 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.

46 CSE323 Systems Analysis and Design 2/ Aug-14 Sequence Diagram for using two Web pages: one for student information, one for course information.

47 CSE323 Systems Analysis and Design 2/ Aug-14 Relationships on a Class Diagram  Relationships are the connections between classes and include:  Associationsshowing the one-to-many relationships between classes.  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  Association classes are used to break up a many-to- many association between classes.

48 CSE323 Systems Analysis and Design 2/ Aug-14 Association Class Example

49 CSE323 Systems Analysis and Design 2/ Aug-14 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.

50 CSE323 Systems Analysis and Design 2/ Aug-14 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.

51 CSE323 Systems Analysis and Design 2/ Aug-14 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

52 CSE323 Systems Analysis and Design 2/ Aug-14 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

53 CSE323 Systems Analysis and Design 2/ Aug-14 Whole/Part Example

54 CSE323 Systems Analysis and Design 2/ Aug-14 Generalization/Specialization Diagrams  Generalization/specialization  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. a car is a vehiclea truck is a vehicle  For example: a car is a vehicle, a truck is a vehicle.  Generalization relationship is used to model inheritance  Generalization relationship is used to model inheritance.  General class is a parent, base, or superclass.  Specialized class is a child, derived, or subclass.

55 CSE323 Systems Analysis and Design 2/ Aug-14 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.

56 CSE323 Systems Analysis and Design 2/ Aug-14 Gen/Spec Example

57 CSE323 Systems Analysis and Design 2/ Aug-14 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.

58 CSE323 Systems Analysis and Design 2/ Aug-14 Determining Class Methods Class methods may be determined by:  Using a CRUD matrix.  Looking at messages sent between classes  Looking at messages sent between classes. The receiving class must have the message name as a method.  Usingstatechart diagrams  Using statechart diagrams.

59 CSE323 Systems Analysis and Design 2/ Aug-14 Statechart Diagrams  Statechart diagrams show class states and the events that cause them to transition between states. also called a state transition diagram  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”

60 CSE323 Systems Analysis and Design 2/ Aug-14 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.

61 CSE323 Systems Analysis and Design 2/ Aug-14 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.

62 CSE323 Systems Analysis and Design 2/ Aug-14 Statechart Example

63 CSE323 Systems Analysis and Design 2/ Aug-14 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

64 CSE323 Systems Analysis and Design 2/ Aug-14 Package Example

65 CSE323 Systems Analysis and Design 2/ Aug-14 Steps Used in UML 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.

66 CSE323 Systems Analysis and Design 2/ Aug-14 Object Interaction and Specifying Operations Next Lecture


ดาวน์โหลด ppt Www.themegallery.com CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 06: Object-Oriented Systems Analysis and Design Using UML.

งานนำเสนอที่คล้ายกัน


Ads by Google