Giáo trình UML - OOAD - Phân tích thiết kế phần mềm (Hướng đối tượng và hướng thành phần)

. Association th−ờng gặp là quan hệ kết hợp có hai AssociationEnd (mối kết hợp). Mỗi mối kết hợp gắn với một Classifier. Association mô tả sự liên hệ về ngữ nghĩa giữa các Classifier. AssociationClass (Lớp kết hợp), Thừa kế từ Class và Association, AssociationClass vừa có tính chất của một Class vừa có tính chất của một Association. AssociationClass nối một tập các classifier với nhau và có các thuộc tính riêng đặc tr−ng cho quan hệ giữa các classifier này. Nhân sự Tiền l−ơng Nhân sự 1..* Công ty 0..* Hình 2.11. Ví dụ lớp kết hợp 2.4.1.3. Mô hình Classifiers (các đặc biệt hóa của classifiers) Mô hình Classifiers mô tả các đặc biệt hóa của Classifier bao gồm các phần tử Class (lớp), Interface (giao diện), DataType (kiểu dữ liệu), Node (nút) và Component (thành phần) 14 isActive: Boolean Class DataType Interface Node Component visibility: VisibilityKind Element ModelElement +resident +deploymentLocation * * * * +resident +ImplementationLocation Classifier Hình 2.12. Các lớp đặc biệt của Classifier Class (lớp) Class là tập hợp các đối t−ợng có cùng các thuộc tính, hành động và ngữ nghĩa. Một Class có thể là trừu t−ợng (abstract) nghĩa là không có thể hiện (đối t−ợng) nào đ−ợc tạo ra trực tiếp từ nó. Class là phần tử cụ thể có biểu diễn ký hiệu trên Mô hình UML. Là đặc biệt hóa của Classifier, Class bao gồm các Attribute (thuộc tính), Operation (mô tả ph−ơng thức) và Method. Giữa các Class có quan hệ tổng quát hóa, quan hệ kết hợp. Th− ký Kế toán viênCông việc Phòng ban Tên nhân viên Nhân viên Lấy thông tin nhân viên() Thực hiện Trực thuộc Quan hệ kết hợp Tổng quát hoá Thuộc tính Ph−ơng thức Hình 2.13. Ví dụ về lớp và quan hệ giữa các lớp 15 Interface (giao diện) Interface là tập các operation (ph−ơng thức) của một Classifier. Mỗi Interface cung cấp một dịch vụ của Classifier bao gồm một nhóm các operation có quan hệ với Interface đó. Mỗi Classifier có thể cung cấp nhiều dịch vụ khác nhau qua các Interface khác nhau. DataType (kiểu dữ liệu) DataType mô tả kiểu dữ liệu của ng−ời sử dụng. UML không định nghĩa các kiểu dữ liệu cụ thể. Việc định nghĩa các kiểu dữ liệu của ng−ời sử dụng tùy thuộc vào môi tr−ờng phát triển phần mềm nên th−ờng các CASE tool đảm nhận chức năng định nghĩa các kiểu dữ liệu này. Node (nút) Node là phần tử đại diện cho một tài nguyên vật lý có bộ nhớ và khả năng xử lý tính toán. Các node th−ờng đại diện cho các máy tính và mô tả việc phân bố các máy tính trên mạng. Component (thành phần) Component là một phần riêng biệt ở mức vật lý của hệ thống. Component đóng gói các ph−ơng thức xử lý và cung cấp tập các dịch vụ xử lý này qua một tập interface (giao diện) khác nhau. Mỗi giao diện bao gồm nhiều ph−ơng thức khác nhau để phục vụ cho một mục đích cụ thể. Các ph−ơng thức có thể là các đoạn mã thi hành đ−ợc, các script hay lệnh. Một component th−ờng cung cấp nhiều loại dịch vụ khác nhau liên quan đến một đối t−ợng cụ thể. > MSBind DBindingColectionEvents Giao diện Component DBindingColection DBinding Một MSBind là một component nối một control của Window với một recordset. MSBind cung cấp nhiều dịch vụ, trong đó dịch vụ gắn control vào recordset là Bindding Hình 2.14. Ví dụ về component và interface 16 2.4.1.4. Mô hình Dependencies (các quan hệ phụ thuộc) Dependency mô tả sự phụ thuộc chức năng giữa hai thành phần cho và thành phần nhận. Thành phần cho đóng vai trò cung cấp dịch vụ cho thành phần nhận. Dependency định nghĩa phụ thuộc giữa hai phần tử ModelElement nên hầu nh− tất cả các phần tử cụ thể thừa kế ModelElement đều có thể có quan hệ phụ thuộc. Quan hệ phụ thuộc có các đặc biệt hóa là Binding (gắn), Abstraction (trừu t−ợng hóa), Usage (sử dụng) và Permisson (cho phép). Relation name: Name ModelElement Dependency Binding 1..* 1..* * * + supplier + client + clientDependency + supplierDependency Usage mapping: MappingExpression Abstraction Permission + argument {ordered} 1..* 0..1 Hình 2.15. Mô hình Dependence Binding (gắn) Binding định nghĩa quan hệ giữa một Template (mẫu) là thành phần cho của Dependency với một thành phần đ−ợc tạo từ Template đó là thành phần nhận của Dependency. Binding bao gồm các đối số phù hợp với các tham số của Template. Abstraction (trừu t−ợng hóa) Abstraction mô tả mối liên hệ giữa các phần tử ở các mức trừu t−ợng hóa khác nhau. Ví dụ nh− chuyển một khái niệm ở mức phân tích sang mức thiết kế bằng quan hệ Abstraction. 17 Usage (sử dụng) Usage là quan hệ giữa một phần tử ModelElement có sử dụng ph−ơng thức của một phần tử ModelElement khác. Permisson (cho phép) Permisson cung cấp quyền hạn cho một phần tử ngoài Namespace (không gian các phần tử) tham chiếu các phần tử khác trong Namespace. Phần tử nhận là một ModelElement phần tử cho bắt buộc là một Namespace. 2.4.1.5. Mô hình AuxiliaryElements (các phần tử bổ sung) TemplateParameter name:Name ModelElement Element PresentationElement + defaultElement 1..* 0..1 + subject {ordered} + templateParameter +presentation + annotatedElement * * Element +argument {ordered} 0..1 * * Comment * * Hình 2.16. Mô hình AuxiliaryElements Template Parameter (tham số cho mẫu) Tham số cho mẫu là tham số cho các phần tử Template. Ví dụ nh− trong một môi tr−ờng ngôn ngữ lập trình hỗ trợ Template, ta có thể xây dựng lớp mới bằng cách cung cấp các lớp tham số cho Template. TemplateParameter định nghĩa quan 18 hệ giữa một phần tử ModelElement với các tham số (các tham số này là các phần tử ModelElement). ModelElement là một Template khi sử dụng ít nhất một TemplateParameter. Presentation Element (phần tử biểu diễn trực quan) PresentationElement mô tả thông tin cho việc biểu diễn các ModelElement. UML không định nghĩa cụ thể các thông tin này mà để cho các CASE tool tự do định nghĩa. 2.4.2. Package Extension Mechanisms (gói kỹ thuật mở rộng) 2.4.2.1. Khái quát Extension Mechanisms định nghĩa cách thức mở rộng ngôn ngữ UML bằng cách đ−a ra cơ chế bổ sung các phần tử với ngữ nghĩa mới. Package này định nghĩa Stereotypes, Constraint (ràng buộc) và Tagged Value (thẻ giá trị) là ba cơ chế mở rộng của UML. UML cung cấp cơ chế mở rộng để thêm các phần tử mới cho các lĩnh vực đặc biệt mà UML chuẩn không định nghĩa. Các lĩnh vực cần các khái niệm mới có thể tự định nghĩa các khái niệm này qua cơ chế mở rộng UML. Việc mở rộng này không đơn giản là gắn tên Stereotypes vào phần tử và quy định ngữ nghĩa mới do đôi khi còn có các ràng buộc ngữ nghĩa trong thế giới thực. Do đó các stereotype th−ờng chứa các ràng buộc và các giá trị thẻ. Mỗi StereoType quy định loại phần tử ModelElement mà stereotype này có thể tác động. Phần tử đ−ợc tác động này là các phần tử trong siêu mô hình UML ví dụ nh− Class, Association, Component... Khi gắn stereotype vào các phần tử này thì đ−ợc phần tử mới thừa kế phần tử cũ và có tên của stereotype. Ví dụ nh− Component có các stereotype là "document”,"executable”,"table”. Các stereotype này bản chất cũng là component nh−ng "document" là một thành phần (component) chứa các s−u liệu, "executable" là thành phần chứa các dịch vụ xử lý còn "table" chứa các bảng trong một cơ sở dữ liệu. 19 ModelElement (from Core) Constraint (from Core) + constraint {ordered} + constrainedElement 1 0..1 + taggedValue GeneralizableElement (from Core) + stereotype icon:Geometry baseClass:Name Stereotype 1..* * * + constrainedElement 0..1 0..1 + requiredTag * * + extendedElement {xor} Element * + stereotypeConstraint Hình 2.17. Mô hình Extension Mechanisms 2.4.2.2. Constraint (ràng buộc) Là các ràng buộc ngữ nghĩa đ−ợc gắn với một phần tử cần mở rộng để áp đặt các điều kiện lên phần tử này và có tác dụng thay đổi hay giới hạn ngữ nghĩa. Phần tử mở rộng phải thỏa mãn các ràng buộc này để đảm bảo sự chính xác về ngữ nghĩa. Constraint cũng có thể đ−ợc gắn với stereotypes để tác động lên các phần tử có quan hệ với stereotypes này. 2.4.2.3. Stereotype Là cơ chế phân loại một phần tử theo quan hệ kết hợp của phần tử này với các stereotype. Mỗi stereotype gắn một phần tử sẽ cho một phần tử mới thừa kế phần tử cũ ngoài ra có thêm các thông riêng. Stereotype chính là sự khác nhau về ngữ nghĩa của hai phần tử cùng cấu trúc. Ví dụ nh− trong quy trình phát triển phần mềm Rational Unified Process, các stereotype cho phần tử Class đ−ợc định nghĩa thêm trong đó có stereotype "boundary”. Stereotype này là một Class đóng vai trò giao tiếp với các t−ơng tác bên ngoài hệ thống. Mục đích của mở rộng này là phân loại các Class theo chức năng phục vụ cho quá trình phân tích. 20 Class với stereotype là "boundary" Giao diện ng−ời sử dụng Giao diện ng−ời sử dụng Phân tích Hình 2.18. Ví dụ Stereotype 2.4.2.4. Tagged Value (thẻ giá trị) Là các thuộc tính đính kèm cho một phần tử mở rộng. Tagged Value có thể chứa những thông tin bất kỳ cần thiết bổ sung cho một phần tử mới. 2.4.3. Các kiểu dữ liệu trong siêu mô hình UML (Data Types) 2.4.3.1. Khái quát DataTypes định nghĩa các kiểu dữ kiệu dùng riêng trong siêu mô hình UML nghĩa là thuộc tính của các phần tử trong siêu mô hình UML có các kiểu dữ liệu trong Data Types. Data Types cần thiết cho sự tham khảo sâu hơn về các thuộc tính và ý nghĩa mỗi thuộc tính của một phần tử trong siêu mô hình UML. Data Types không phải là kiểu dữ liệu của ng−ời sử dụng. Kiểu dữ liệu của ng−ời sử dụng UML đ−ợc định nghĩa bởi DataType là đặc biệt hóa của Classifiers trong Core. Data Types không định nghĩa cú pháp nào cho ng−ời sử dụng. 2.4.3.2. Các kiểu dữ liệu trong Data Types ActionExpression : biểu thức cho kết quả là sự thi hành một Action. AggregationKind : kiểu liệt kê bao gồm các giá trị none, aggregate, composite. Các giá trị này xác định loại Association. ArgListsExpression :biểu thức trả về một danh sách các đối t−ợng (object). Boolean : kiểu liệt kê bao gồm hai giá trị false và true. BooleanExpression : biểu thức logic trả về kiểu Boolean. CallConcurrencyKind : kiểu liệt kê bao gồm các giá trị sequential, guarded, concurrent. ChangeableKind : kiểu liệt kê quy định giá trị một AttributeLink hay một LinkEnd có thể thay đổi bao gồm các none, frozen và addOnly. Enumeration : định nghĩa kiểu liệt kê. 21 EnumerationLiteral : định nghĩa một giá trị thuộc một kiểu liệt kê. Expression : biểu thức trả về một kiểu thuộc package DataType. Integer : kiểu nguyên. IterationExpression : chuỗi trả về cấu trúc kiểm soát lặp. LocationReference : vị trí cho việc chèn một use case vào một use case khác. Mapping : biểu thức chuyển đổi các ModelElement. MappingExpression : biểu thức trả về kiểu Mapping. MessageDirectionKind : kiểu liệt kê bao gồm các giá trị activation và return. Muliplicity : tập các số nguyên không âm. MultiplicityRange : miền giá trị số nguyên không âm. Name : định danh cho một ModelElement. ObjectSetExpression : biểu thức trả về danh sách các đối t−ợng. OperationDirectionKind : kiểu liệt kê quy định một Operation là đ−ợc yêu cầu hay đ−ợc cung cấp bởi một Classifier bao gồm các giá trị provide và require. ParameterDirectionKind : kiểu liệt kê bao gồm các giá trị in, inout, out và return. Primitive : định nghĩa kiểu dữ liệu đơn. ProcedureExpression : biểu thức trả về một Procedure. ProgrammingLanguageType : kiểu dữ liệu trong một ngôn ngữ lập trình. PseudostateKind : kiểu liệt kê bao gồm các giá trị initial, deepHistory, shallowHistory, join, fork, branch, junction và final. ScopeKind : kiểu liệt kê bao gồm các giá trị classifier và instance. String : chuỗi văn bản. Structure : kiểu dữ liệu có cấu trúc. Time : kiểu giờ. TimeExpression : biểu thức kiểu Time. UnlimitedInteger : kiểu nguyên không giới hạn. Uninterpreted : kiểu không xác định. VisibilityKind : kiểu liệt kê bao gồm các giá trị public, protected và private. 2.5. Behavioural Elements Package (gói phần tử hành vi) Behavioral Elements bao gồm các phần tử cùng với các cú pháp cho mô hình hóa hành vi và t−ơng tác. BehavioralElements bao gồm năm gói là Common Behavior (hành vi tổng quát), Collaborations (mô hình cộng tác), Use Cases (mô hình chức năng), State Machines (mô hình trạng thái) và Activity Graphs (mô hình hành động). 22 Activity Graphs State MachinesUse CasesCollaboration Common Behavior Hình 2.19 Behavioural Elements Package CommonBehavior định nghĩa các phần tử hành vi cơ bản. Collaboration định nghĩa các phần tử và cú pháp cho biểu đồ Collaboration và Sequence ở Mô hình UML. Collaboration mô tả t−ơng tác giữa các phần tử để thực hiện một tác vụ cụ thể. Use Cases bao gồm các phần tử mô hình hóa chức năng hệ thống cho từng loại ng−ời sử dụng. Use Cases giữ vai trò định nghĩa cho biểu đồ Use Case ở Mô hình UML. StateMachine bao gồm các khái niệm cho mô hình hóa quá trình thay đổi trạng thái của một phần tử. StateMachine định nghĩa biểu đồ StateChart trong Mô hình UML. Activity Graphs là dạng đặc biệt của StateMachine, đ−ợc định nghĩa dựa trên StateMachine, mô tả quá trình hành động của một hay nhiều phần tử. Activity Graphs định nghĩa biểu đồ Activity Graph trong Mô hình UML. 2.5.1. Package Common Behavior (gói hành vi tổng quát) Common Behavior định nghĩa các phần tử cơ bản cho mô hình hóa t−ơng tác. Common Behiavior đ−ợc mô tả bằng các mô hình Signals (tín hiệu), Actions (hành động), Instances and Links (thể hiện và liên kết). 23 Classifier (from Core) Signal Exception BehavioralFeature (from Core) specification:String isRoot:Boolean isLeaf:Boolean isAbstract:Boolean Stereotype +signal 0..* +reception * +context+raisedSignal 1 * Hình 2.20. Mô hình Signals 2.5.1.1. Mô hình Signals (tín hiệu) Mô hình này chủ yếu định nghĩa phần tử Signal (tín hiệu). Tín hiệu đ−ợc tạo ra từ một BehavioralFeature (đặc điểm hành vi) của classifier này và gủi đến một phần tử Reception (nhận tín hiệu)của một classifier khác. Reception (phần tử nhận tín hiệu) Reception là phần tử nhận tín hiệu từ một classifier và giữ chức năng mô tả các hành động (bằng chuỗi văn bản) của tín hiệu đến classifier nhận. Signal (tín hiệu) Signal là các tác t−ơng tác không đồng bộ giữa các classifier và là phần tử độc lập với các classifier. Signal đ−ợc tạo ra do các BehavioralFeature (đặc điểm hành vi) của các classifier này và gửi đến các classifier khác. Do BehavioralFeature là phần tử hành vi trừu t−ợng nên tất cả các phần tử hành vi thừa kế BehavioralFeature nh− các operation (mô tả ph−ơng thức) đều có thể tạo và gửi các signal. 24 Exception (lỗi ngoại lệ) Thừa kế signal, exception là tín hiệu đ−ợc gửi đi khi có một lỗi trong quá trình thi hành một hành vi. 2.5.1.2. Mô hình Actions (hành động) Action đ−ợc mô tả bằng mô hình Actions của siêu mô hình UML. Action là các chỉ thị thi hành có gây ảnh h−ởng đến trạng thái của hệ thống Model (from Core) recurrence:IterationExpression target:ObjectSetExpression isAsynchronous:Boolean script:ActionExpression Action value:Expression Argument ActionSequence CallAction SendAction UninterpretedAction ReturnAction TerminateAction Operation (from Core) Signal DestroyAction * 1 * 1 +instantiation CreateAction Class (from Core) 0..* 1 +operation +signal 0..1 0..* +actualArgument {ordered} {ordered} +action 0..1 Hình 2.21. Mô hình Action Argument (đối số) Argument là đối số cho một Action, cung cấp giá trị tham số cho một Action. Action (hành động) Action là các chỉ thị thi hành trong một quy trình tính toán có ảnh h−ởng đến trạng thái của hệ thống. Action bao gồm các đặc biệt hóa sau AssignmentAction : gán cho thuộc tính một giá trị mới. 25 CallAction : kích hoạt một hành động. CreateAction : tạo thể hiện của một Classifier. DestroyAction : hủy một đối t−ợng ReturnAction : trả về giá trị cho đối t−ợng gọi. SendAction : gửi tín hiệu (Signal ). TerminateAction : hành động tự hủy của một đối t−ợng. UninterpretedAction : hành động không xác định. ActionSequence (hành động phức) ActionSequence là một hành động chứa một tập các Action con theo thứ tự xác định. 2.5.1.3. Mô hình Instances và Links (thể hiện và liên kết) Instance và Link đ−ợc định nghĩa trong mô hình Instances và Links của siêu mô hình UML. Instance định nghĩa thể hiện của một classifier, các thể hiện này liên kết với nhau qua các Link. Stimulus (tác nhân) Stimulus là một giao tiếp cụ thể giữa hai instance qua một liên kết (link) đ−ợc gửi đi bởi sự thi hành một Action, có thể là một tín hiệu gửi đến instance hay việc kích hoạt một ph−ơng thức. Hay nói cách khác, các thể hiện t−ơng tác với nhau qua stimulus. AttributeLink (thẻ thuộc tính) AttributeLink chứa tập các giá trị của Attribute trong một instance do đó thể hiện trạng thái của instance. LinkEnd (mối liên kết) LinkEnd là các mối liên kết của một Link. Mỗi LinkEnd t−ơng ứng với một AssociationEnd (mối kết hợp) để xác định LinkEnd. LinkEnd trong siêu mô hình UML là thể hiện của AssociationEnd trong siêu mô hình UML. Các instance liên kết với nhau qua các LinkEnd. Link (liên kết) Link là liên kết giữa các instance. Link t−ơng ứng với một Association có vai trò xác định Link. Link trong siêu mô hình UML là thể hiện Association trong siêu mô hình UML. Link chỉ có vai trò liên kết các instance với nhau, các hành động 26 giữa các instance thực hiện qua các stimulus. Một Link có thể t−ơng ứng với nhiều stimulus. Instance (thể hiện) Instance là thể hiện của một Classifier. Instance là một thực thể có các thông tin về trạng thái và chịu tác động của các Operation (mô tả ph−ơng thức) để thay đổi trạng thái. Instance đ−ợc xác định cấu trúc và hành động qua Classifier có quan hệ kết hợp với nó. Instance có các đặc biệt hóa sau DataValue (giá trị dữ liệu): giá trị của một thuộc tính là thể hiện của kiểu dữ liệu của thuộc tính đó. ComponentInstance (thể hiện thành phần): thể hiện của một Component. NodeInstance (thể hiện nút) : thể hiện của một Node. Object (đối t−ợng) : thể hiện của một Class. 27 28 ModelElement (from Core)recurrence:IterationExpression target:ObjectSetExpression isAsynchronous:Boolean script:ActionExpression Action Attribute (from Core) Classifier (from Core) AttributeLink Link LinkEnd Asscociatio n (from Core) AsscociationEnd (from Core)Instance +classifie r DataValue ComponentInstance NodeInstance Object LinkObject +attribute +slot +value {orderd} +argument +receiver +sender +communicationLin k +connection {ordered } +linkEn d +asscociatio n +asscociationEn d +connection +instance +resident +dispatchAction 1 2..* 0..* 1 Simulus * * 1 * 1 * 0..1* * 1 1 * 1 * 1 * 1 +resident * 0..1 0..1 Hình 2.22. Mô hình Instances và Links 29 2.5.2. Collaborations Package (gói cộng tác) Collaborations định nghĩa phần tử Collaboration và cú pháp cho mô hình hóa t−ơng tác giữa các phần tử để thi hành một tác vụ cụ thể. Mô hình cộng tác mô tả quan hệ giữa instance và link thông qua các message (thông điệp). Phần tử Collaboration đ−ợc định nghĩa là quá trình trao đổi các message (thông điệp) giữa các role (vai) của các phần tử trong Collaboration. Một phần tử classifier có thể tham gia vào Collaboration thông qua nhiều vai của phần tử đó. GeneralizableElement {from Core} NameSpace {from Core} NameSpace Operatio {from Cor Classifie {from Cor * * 0..1 0..1 + represented Operation + represented Classifier AsosicationRole multiplic ity: Multiplicity + ownedElement InteractionModel Element {from Core} Message Asosication {from Core} AsosicationEnd {from Core} AsosicationEndRole collaborationMultiplic ity: Multiplic ity ClassifierRole multiplic ity: Multiplicity Attribute {from Core} Feature {from Core} Action {from Core} 1 + context1 * 1 * + interaction + message + predecssor * *+ activation + action * * 0..1 1 ** 1 1+ receive+ sender +/ ownedElement1..* * +/type 1* * * +avaiable Feature +avaiableQualifier * * 1 2..* +/connection *0..1 + base +connection 1 2..* 1 * * * + constrainingElement +avaiable contents * * {xor} Hình 2.23. Gói Collaborations AssociationEndRole (vai của mối kết hợp) AssociationEndRole là mối liên kết của một vai Association (AssociationRole) trong Collaboration. Một Association có thể tham gia nhiều vai vào Collaboration nên cũng có nhiều vai của mối liên kết t−ơng ứng. 31 AssociationRole (vai của quan hệ kết hợp) Một Association có thể tham gia vào Collaboration qua nhiều AssociationRole. AssociationRole là một vai của Association trong Collaboration. ClassifierRole (vai của Classifier) Một Collaboration bao gồm các ClassifierRole và các liên kết giữa các ClassifierRole này. Một Classifier có thể tham gia vào Collaboration qua nhiều ClassifierRole. Collaboration (hợp tác) Collaboration mô tả quá trình t−ơng tác giữa các phần tử classifier (qua các ClassifierRole của nó) để thực hiện một operation (mô tả ph−ơng thức). Các classifier này trao đổi các thông điệp với nhau theo một thứ tự xác định. Mỗi thông điệp gây ra một hành động lên phần tử classifier nhận. Collaboration chính là mô tả cho cơ chế vận hành của một hệ thống Giao diện sửa đổi thông tin sinh viên :SVUI Xử lý sửa đổi thông tin sinh viên:SV control Xử lý sửa đổi thông tin sinh viên:SV control Dữ liệu sinh viên : SV Data 1.Sửa đổi thông tin sinh viên :Phòng đào tạo 4.Chọn sinh viên và sửa đổi 5.Cập nhật thông tin đã sửa đổi 5. Cập nhật thông tin sinh viên 2. Hiển thị các sinh viên 3.lấy dữ liệu sinh viên 7. Cập nhật dữ liệu lên CSDL AsociationRole Thông điệp với classifier gửi và nhận Hai vai trò của cùng m ột classifier "SVControl" tham gia vào Collaboration Hình 2.24. Ví dụ sự hợp tác 32 Message (thông điệp) Message là thông điệp giữa các ClassifierRole. Message định nghĩa vai trò của ClassifierRole gửi và ClassifierRole nhận cùng với một Action (hành động) lên Classifier nhận thông điệp. 2.5.3. Use Cases Package (gói Use Cases) Use Cases định nghĩa các phần tử và cú pháp cho mô hình hóa chức năng của hệ thống cung cấp cho từng loại ng−ời sử dụng. Các phần tử trong Use Cases chủ yếu để mô tả các hành vi trong hệ thống trong khi vẫn ch−a xác định cấu trúc hệ thống. Use Cases định nghĩa hai phần tử cơ bản là Actor và UseCase. Actor là các tác nhân bên ngoài hệ thống có t−ơng tác với hệ thống (có thể là ng−ời sử dụng hay một hệ thống khác). Trong khi đó, mỗi UseCase mô tả một chức năng của hệ thống và chức năng này đ−ợc kích hoạt khi có tác động của Actor lên UseCase. Association nối Actor với các UseCase cho biết các chức năng mà hệ thống cung cấp cho Actor. Classifier {from Core} Instance {from Common Behavior} UseCaseInstance UseCaseActor Include Extend condition : BooleanExpression Relationship {from Core} Model Element {from Core} ExtensionPoint location :LocationRefence +extensionPoint *1..* +classifier 1 * 1..* +extensionPoint {ordered} * + base + base +extension 11 1 +include** +addition 1 * * Hình 2.25. gói Use Cases Actor (tác nhân) Actor là tác nhân tác động lên hệ thống thông qua các Use Case của hệ thống. Một Actor có thể t−ơng tác với nhiều Use Case khác nhau. 33 ExtensionPoint (điểm mở rộng) ExtensionPoint là vị trí trong một UseCase có thể mở rộng hành vi bằng cách chèn thêm các hành vi cho Use Case đó. Extend (mở rộng) Extend định nghĩa quan hệ giữa các Use Case với ý nghĩa một Use Case này có thể đ−ợc mở rộng thêm các hành vi trong Use Case khác bằng cách thêm vào mô tả của Use Case gốc các biểu thức và điều kiện mở rộng tại những vị trí xác định trong một dãy các hành vi của Use Case. Include (bao gồm) Include định nghĩa quan hệ giữa các Use Case với ý nghĩa UseCase này sử dụng các hành vi đ−ợc định nghĩa trong UseCase khác. UseCase UseCase là các chức năng của hệ thống d−ới góc độ của ng−ời sử dụng. UseCase không quan tâm đến cấu trúc bên trong của hệ thống. Mỗi UseCase bao gồm một dãy các hành động nguyên tố có thứ tự (không bị ngắt bởi các hành động nào khác)mà hệ thống sẽ thực hiện khi có t−ơng tác của Actor lên UseCase đó. Mỗi UseCase có thể đ−ợc mô tả rõ hơn thông qua một Collaboration chứa các thành phần của hệ thống và t−ơng tác giữa chúng để thực hiện Use Case. :Phòng đào tạo Quản lý sinh viên Đăng nhập hệ thống > actor (tác nhân) Usecase (tr−ờng hợp sử dụng) Hình 2.26. Ví dụ UseCase 34 2.5.4. Package State Machines (gói mô hình trạng thái) State Machines cung cấp các phần tử và cú pháp cho mô hình hóa hành động và biến đổi trạng thái của một phần tử trong chu kỳ sống d−ới các sự kiện tác động lên nó. Một một phần tử (nh− các Classifiers, Operation, Attribute...) có thể có một quá trình biến đổi trạng thái. Quá trình này đ−ợc định ngh