intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE
 » 
 » 

Bài giảng Phân tích thiết kế phần mềm: Chương 7 - Trường ĐH Ngoại ngữ - Tin học TP.HCM

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:16

Thêm vào BST
Báo xấu
19
lượt xem 11
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng Phân tích thiết kế phần mềm: Chương 6 Sơ đồ lớp, cung cấp cho người đọc những kiến thức như: Đối tượng; lớp; thuộc tính; tác vụ; quan hệ. Mời các bạn cùng tham khảo!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Phân tích thiết kế phần mềm: Chương 7 - Trường ĐH Ngoại ngữ - Tin học TP.HCM

  1. 2/28/2019 Content  Objects (Đối tượng)  Classes (Lớp)  Attributes (Thuộc tính)  Operations (Tác vụ)  Relationships (Quan hệ)  Binary Association  N-ary Association  Association Class  Aggregation  Generalization  Creating a class diagram  Code Generation 2 1 Object Object Diagram  Individuals (cá nhân) of a system  Objects of a system and their relationships (links)  Snapshot of objects at a specific moment in time  Alternative notations: Object name Class Anonymous objects Attribute Current value = no object name Link 3 4 1
  2. 2/28/2019 Attribute Syntax Attribute Syntax - Visibility  Who is permitted to access the attribute  + ... public: everybody  - ... private: only the object itself  # ... protected: class itself and subclasses  ~ ... package: classes that are in the same package 5 6 Attribute Syntax - Derived Attribute Attribute Syntax - Name  Attribute value is derived from other attributes  Name of the attribute  age: calculated from the date of birth 7 8 2
  3. 2/28/2019 Attribute Syntax - Type Attribute Syntax - Multiplicity  Type  Number of values an attribute may contain  User-defined classes  Default value: 1  Data type  Notation: [min..max]  Primitive data type  no upper limit: [*] or [0..*]  Pre-defined: Boolean, Integer, UnlimitedNatural, String  User-defined: «primitive»  Composite data type: «datatype»  Enumerations: «enumeration» 9 10 Attribute Syntax – Default Value Attribute Syntax – Properties  Default value  Pre-defined properties  Used if the attribute value is not set explicitly by the  {readOnly} … value cannot be changed user  {unique} … no duplicates permitted  {non-unique} … duplicates permitted  {ordered} … fixed order of the values  {unordered} … no fixed order of the values  Attribute specification  Set: {unordered, unique}  Multi-set: {unordered, non-unique}  Ordered set: {ordered, unique}  List: {ordered, non-unique} 11 12 3
  4. 2/28/2019 Operation Syntax - Parameters Operation Syntax - Type  Notation similar to attributes  Type of the return value  Direction of the parameter  in … input parameter  When the operation is used, a value is expected from this parameter  out … output parameter  After the execution of the operation, the parameter has adopted a new value  inout : combined input/output parameter 13 14 Class Variable and Class Operation Specification of Classes: Different Levels of Detail  Instance variable (= instance attribute): attributes defined on instance level  Class variable (= class attribute, static attribute) (biến lớp) coarse-grained fine-grained  Defined only once per class, i.e., shared by all instances of the class  E.g. counters for the number of instances of a class, constants, etc.  Class operation (= static operation) (tác vụ lớp)  Can be used if no instance of the corresponding class was created  E.g. constructors, counting operations, math. functions (sin(x)), etc.  Notation: underlining name of class variable / class operation class Person { public String firstName; Class public String lastName; variable private Date dob; protected String[] address; private static int pNumber; Class public static int getPNumber() {…} operation public Date getDob() {…} } 15 16 4
  5. 2/28/2019 Association Binary Association  Models possible relationships between instances of classes  Connects instances of two classes with one another Navigability Association name Reading direction Multiplicity Non-navigability Visibility Role 17 18 Binary Association - Navigability Navigability – UML Standard vs. Best Practice  Navigability (khả năng truy cập): an object knows its partner objects and can therefore access their visible attributes and operations UML standard Best practice  Indicated by open arrow head  Non-navigability (không truy cập)  Indicated by cross (dấu chéo)  Example:  A can access the visible attributes and operations of B  B cannot access any attributes and operations of A  Navigability undefined  Bidirectional navigability is assumed 19 20 5
  6. 2/28/2019 Binary Association as Attribute Binary Association – Multiplicity and Role  Multiplicity (chỉ số): Number of objects that may be associated with exactly one object of the opposite side Preferable  Java-like notation:  Role (vai trò): describes the way in which an object is involved in an association relationship class Professor {…} class Student{ public Professor[] lecturer; … } 21 22 Binary Association – xor constraint Unary Association - Example  “exclusive or” constraint  An object of class A is to be associated with an object of class B or an object of class C but not with both. 23 24 6
  7. 2/28/2019 n-ary Association (1/2) n-ary Association (2/2)  More than two partner objects are involved in the relationship.  Example  No navigation directions  (Student, Exam)  (Lecturer)  One student takes one exam with one or no lecturer  (Exam, Lecturer)  (Student)  One exam with one lecturer can be taken by any number of students  (Student, Lecturer)  (Exam)  One student can be graded by one Lecturer for any number of exams Ternary association ≠ 25 26 Association Class Association Class  Assign attributes to the relationship between classes rather than to a  Necessary when modeling n:m Associations class itself Association class  With 1:1 or 1:n possible but not necessary 27 28 7
  8. 2/28/2019 Association Class vs. Regular Class Association Class – unique/non-unique (1/2)  Default: no duplicates  non-unique: duplicates allowed ≠ A Student can enroll for one A Student can have mutiple particular StudyProgram only Enrollments for one and the once same StudyProgram A student can only be granted an A student can have more than one exam meeting for a specific exam once. exam meetings for a specific exam. 29 30 Association Class – unique/non-unique (2/2) Aggregation (tổng hợp)  Special form of association  Used to express that a class is part of another class  Properties of the aggregation association:  Transitive: if B is part of A and C is part of B, C is also part of A  Asymmetric (bất đối xứng): it is not possible for A to be part of B and B to be part of A simultaneously.  Two types:  Shared aggregation  Composition 31 32 8
  9. 2/28/2019 Shared Aggregation Composition  Expresses a weak belonging of the parts to a whole  Existence dependency between the composite object and its parts = Parts also exist independently of the whole (thành phần có thể tồn tại độc  One part can only be contained in at most one composite object at one lập) specific point in time  Multiplicity at the aggregating end may be >1 Multiplicity at the aggregating end max. 1 = One element can be part of multiple other elements simultaneously -> The composite objects form a tree  Spans a directed acyclic graph  If the composite object is deleted, its parts are also deleted.  Syntax: Hollow diamond at the aggregating end  Syntax: Solid diamond at the aggregating end  Example:  Example: Beamer is part of LectureHall is part of Building  Student is part of LabClass  Course is part of StudyProgram If the Building is deleted, The Beamer can exist without the the LectureHall is also deleted LectureHall, but if it is contained in the LectureHall while it is deleted, the Beamer is also deleted 33 34 Shared Aggregation and Composition Shared Aggregation and Composition  Which model applies?  Which model applys? ----Yes--- ---------No-------- ----Yes--- A Tire can exist without a Car. A Tire belongs to one Car at most. A Tire cannot exist without a Car. A Tire can belong to multiple Cars A Car has one or two types of Tires. Several Cars may have the same Type of Tires. 35 36 9
  10. 2/28/2019 Generalization (tổng quát hóa) Generalization – Abstract Class (lớp trừu tượng)  Characteristics (attributes and operations),  Used to highlight common characteristics of their subclasses. associations, and aggregations that are Superclass  Used to ensure that there are no direct instances of the superclass. specified for a general class (superclass)  Only its non-abstract subclasses can be instantiated. are passed on to its subclasses.  Useful in the context of generalization relationships.  Every instance of a subclass is  Notation: keyword {abstract} or class name in italic font. simultaneously an indirect instance of the superclass. Subclasses …inherit characteristics,  Subclass inherits all characteristics, associations, and associations, and aggregations of the aggregations No Person-object possible superclass except private ones.  Subclass may have further characteristics, A Secretary is an Employee and associations, and aggregations. a Person  Generalizations are transitive. Two types of Person: Man and Woman 37 38 Generalization – Multiple Inheritance With and Without Generalization  UML allows multiple inheritance.  A class may have multiple superclasses.  Example: A Tutor is both an Employee and a Student 39 40 10
  11. 2/28/2019 Creating a Class Diagram Example – University Information System  Not possible to completely extract classes, attributes and associations  A university consists of multiple faculties which are composed of various institutes. Each faculty and each institute has a name. An address is known for each institute. from a natural language text automatically.  Each faculty is led by a dean, who is an employee of the university.  Guidelines  The total number of employees is known. Employees have a social security number,  Nouns often indicate classes a name, and an email address. There is a distinction between research and administrative personnel.  Adjectives indicate attribute values  Research associates are assigned to at least one institute. The field of study of  Verbs indicate operations each research associate is known. Furthermore, research associates can be  Example: The library management system stores users with their involved in projects for a certain number of hours, and the name, starting date, and end date of the projects are known. Some research associates hold courses. Then unique ID, name and address as well as books with their title, author they are called lecturers. and ISBN number. Ann Foster wants to use the library.  Courses have a unique number (ID), a name, and a weekly duration in hours. Question: What about Ann Foster? 41 42 Example – Step 1: Identifying Classes Example – Step 2: Identifying the Attributes  A university consists of multiple faculties We model the system „University“  A university consists of multiple faculties which are composed of various institutes. which are composed of various institutes. Each faculty and each institute has a name. Each faculty and each institute has a name. An address is known for each institute. An address is known for each institute.  Each faculty is led by a dean, who is an  Each faculty is led by a dean, who is an employee of the university. employee of the university.  The total number of employees is known.  The total number of employees is known. Employees have a social security number, Employees have a social security number, a name, and an email address. There is a a name, and an email address. There is a distinction between research and distinction between research and administrative personnel. administrative personnel.  Research associates are assigned to at  Research associates are assigned to at least one institute. The field of study of least one institute. The field of study of each research associate is known. each research associate is known. Furthermore, research associates can be Furthermore, research associates can be involved in projects for a certain number of involved in projects for a certain number of hours, and the name, starting date, and hours, and the name, starting date, and end date of the projects are known. Some end date of the projects are known. Some research associates hold courses. Then research associates hold courses. Then they are called lecturers. Dean has no further attributes than they are called lecturers. any other employee  Courses have a unique number (ID), a  Courses have a unique number (ID), a name, and a weekly duration in hours. 43 name, and a weekly duration in hours. 44 11
  12. 2/28/2019 Example – Step 2: Identifying Relationships (1/6) Example – Step 2: Identifying Relationships (2/6)  Three kinds of relationships: Abstract, i.e., no other types  Association of employees  “A university consists of multiple faculties which are composed of  Generalization various institutes.”  Aggregation  Indication of a generalization  “There is a distinction between research Composition to show existence and administrative personnel.” dependency  “Some research associates hold courses. Then they are called lecturers.” 45 46 Example – Step 2: Identifying Relationships (3/6) Example – Step 2: Identifying Relationships (4/6)  “Each faculty is led by a dean, who is an employee of the university”  “Research associates are assigned to at least one institute.” Shared aggregation to show that ResearchAssociates are part of an Institute, In the leads-relationship, the but there is no existence dependency Employee takes the role of a dean. 47 48 12
  13. 2/28/2019 Example – Step 2: Identifying Relationships (5/6) Example – Step 2: Identifying Relationships (6/6)  “Furthermore, research associates can be involved in projects for a  “Some research associates hold courses. Then they are called certain number of hours.” lecturers.” Lecturer inherits all characteristics, Association class enables to store associations, and aggregations from the number of hours for every ResearchAssociate. single Project of every single In addtion, a Lecturer has an association ResearchAssociate teaches to Course. 49 50 Example – Complete Class Diagram Code Generation  Class diagrams are often created with the intention of implementing the modeled elements in an object-oriented programming language.  Often, translation is semi-automatic and requires only minimal manual intervention. 51 52 13
  14. 2/28/2019 Code Generation – Example (1/6) Code Generation – Example (2/6) abstract class UniversityMember { class Course { public String firstName; public int courseNo; public String lastName; } public int ssNo; } 53 54 Code Generation – Example (3/6) Code Generation – Example (4/6) Enumeration ESemester { winter, class Student extends summer UniversityMember { UniversityMember { } public int matNo; public CourseExecution [] completedCourses; completedCourses; Enumeration ERole { } lecturer, tutor, examiner } 55 56 14
  15. 2/28/2019 Code Generation – Example (5/6) Code Generation – Example (6/6) class CourseExecution { class Employee extends UniversityMember { class Employee extends UniversityMember { public int year; private int acctNo; private int acctNo; public ESemester semester; public int getAcctNo () { public int getAcctNo { public Student [] student; return acctNo; return acctNo; public Course course; } } public Hashtable support; public CourseExecution [] courseExecutions; public CourseExecution [] courseExecution; // Key: employee } } // Value: (role, hours) } 57 58 Notation Elements (1/3) Notation Elements (2/3) Name Notation Description Name Notation Description Description of the structure and n-ary Relationship between n (here 3) Class association classes behavior of a set of objects oder More detailed description of an Abstract class Class that cannot be instantiated Association class association Relationship between classes: An object of C is in a relationship navigability unspecified, xor relationship with an object of A or with an Association navigable in both directions, object of B but not with both not navigable in one direction 59 60 15
  16. 2/28/2019 Notation Elements (3/3) Name Notation Description Shared Parts-whole relationship (A is part aggregation of B) Strong Existence-dependent parts-whole aggregation = relationship (A is part of B) composition Inheritance relationship (A Generalization inherits from B) Object Instance of a class Link Relationship between objects 61 62 16
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN
TRỢ GIÚP
HỖ TRỢ KHÁCH HÀNG
Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.

 

Đồng bộ tài khoản
3=>0