UML Giới thiệu

Bài viết có 1 số phần chưa được dịch, 1 phần do kiến thức của mình chưa đủ, mình sẽ bổ sung sau.

Contents

Giới thiệu. 1

Các phiên bản của UML.. 2

Giới thiệu

The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for

UML là 1 ngôn ngữ mô hình hóa chuẩn được sử dụng với mục đích :

• modeling business and similar processes,
• mô hình hóa quá trình kinh doanh và tương tự vậy.
• analysis, design, and implementation of software-based systems
• phân tích, thiết kế, và thực thi hệ thống phần mềm.

UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.

UML là 1 ngôn ngữ thông dụng phục vụ phân tích kiến trúc kinh doanh, phần mềm và các nhà phát triển thường sử dụng nó để mô tả, đặc tả, thiết kế và viết tài liệu về các quá trình kinh doanh, cấu trúc và hành vi theo như tưởng tượng của các hệ thống phần mềm

UML can be applied to diverse application domains (e.g., banking, finance, internet, aerospace, healthcare, etc.) It can be used with all major object and component software development methods and for various implementation platforms (e.g., J2EE, .NET).

UML is a standard modeling language, not a software development process. UML 1.4.2 specification explains that process:

UML có thể được ứng dụng trong nhiều lĩnh vực khác nhau. Nó có thể được sử dụng với tất cả các quy trình phát triển phần mềm hướng thành phần và hướng đối tượng chính và cho 1 vài nền tảng thực thi ( như J2EE, .Net ). UML là 1 ngôn ngữ mô hình hóa chuẩn, không phải là 1 quá trình phát triển phần mềm. Quy định của UML 1.4.2  giải thích nhiệm vụ của UML như sau :

• provides guidance as to the order of a team’s activities,
• cung cấp chỉ dẫn trình tự hoạt động cho 1 đội,
• specifies what artifacts should be developed,
• đặc tả những gì cần phát triển,
• directs the tasks of individual developers and the team as a whole, and
• chỉ dẫn nhiệm vụ cho các nhà phát triển và đội của họ sao cho thống nhất, và
•  offers criteria for monitoring and measuring a project’s products and activities.
• cung cấp các tiêu chuẩn cho việc theo dõi, đánh giá sản phẩm và hoạt động của 1 dự án.

UML is intentionally process independent and could be applied in the context of different processes. Still, it is most suitable for use case driven, iterative and incremental development processes. An example of such process is Rational Unified Process (RUP).

UML có chủ đích không phụ thuộc công nghệ và có thể ứng dụng trong hoàn cảnh của nhiều công nghệ khác nhau. UML rất phù hợp cho việc xử lý các use case, các quá trình phát triển lặp và tăng trưởng.  Ví dụ như Rational Unified Process ( RUP ).

UML is not complete and it is not completely visual. Given some UML diagram, we can't be sure to understand depicted part or behavior of the system from the diagram alone. Some information could be intentionally omitted from the diagram, some information represented on the diagram could have different interpretations, and some concepts of UML have no graphical notation at all, so there is no way to depict those on diagrams.

UML không đầy đủ và nó không trực quan hoàn toàn. Với 1 số biểu đồ UML, chúng ta không thể chắc là sẽ hiểu hoàn toàn các phần được biểu diễn bằng mô hình hoặc hành vi của hệ thống chỉ từ các biểu đồ. Một số thông tin có thể bị lược bỏ khỏi biểu đồ 1 cách cố ý, 1 vài thông tin được miêu tả trên biểu đồ có thể có nhiều cách diễn giải khác nhau, và 1 số khái niệm của UML chưa có kí hiệu đồ họa, vậy nên chưa có cách nào để biểu diễn chúng trên biểu đồ.

For example, semantics of multiplicity of actors and multiplicity of use cases on use case diagrams is not defined precisely in the UML specification and could mean either concurrent or successive usage of use cases.

Ví dụ, ý nghĩa của tính đa dạng của các tác nhân và tính đa dạng của các use case trên biểu đồ use case chưa được khai báo 1 cách chính xác trong quy định của UML và nó còn có thể có nghĩa là sử dụng liên tiếp hoặc đồng thời các use case.

Name of an abstract classifier is shown in italics while final classifier has no specific graphical notation, so there is no way to determine whether classifier is final or not from the diagram.

Tên của phân lớp trừu trượng được hiển thị dưới dạng chữ nghiêng, trong khi phân lớp cuối cùng lại không có kí hiệu đồ họa cụ thể, vậy nên không có cách nào để xác định đâu là phân lớp cuối cùng, đâu là không cuối cùng từ biểu đồ.

Các phiên bản của UML

The current version of UML is UML 2.4.1, released in August 2011 [UML 2.4.1 Specification]. The first versions of UML were created by Three Amigos - Grady Booch (creator of Booch method), Ivar Jacobson (Object-Oriented Software Engineering, OOSE), and Jim Rumbaugh (Object-Modeling Technique, OMT). UML® specification (standard) is updated and managed by the Object Management Group (OMG™) OMG UML.

Phiên bản hiện tại của UML là UML 2.4.1, được phát hành tháng 8-2011. Phiên bản UML đầu tiên được tạo bởi 3 người bạn của nhau - Grady Booch (creator of Booch method), Ivar Jacobson (Object-Oriented Software Engineering, OOSE), and Jim Rumbaugh (Object-Modeling Technique, OMT). Quy định của UML ( chuẩn ) được cấp nhật và quản lý bởi Object Management Group (OMG™) OMG UML.

Version	Date	Description
1.1	11-1997	UML 1.1 proposal is adopted by the OMG. Đề xuất UML 1.1 được thông qua bởi OMG.
1.3	03-2000	Contains a number of changes to the UML metamodel, semantics, and notation, but should be considered a minor upgrade to the original proposal. Chứa 1 số thay đổi về metamodel ( thuộc tính trừu tượng, nổi bật của mô hình ), ngữ nghĩa và kí hiệu UML. Tuy nhiên nó chỉ được xem như 1 bản nâng cấp nhỏ so với phiên bản trước.
1.4	09-2001	Mostly "tuning" release but not completely upward compatible with the UML 1.3. Addition of profiles as UML extensions grouped together. Updated visibility of features. Stick arrowhead in interaction diagrams now denotes asynchronous call. Model element may now have multiple stereotypes. Clarified collaborations. Refined definitions of components and related concepts. Artifact was added to represent physical representations of components.
1.5	03-2003	Added actions (see Part 5 of spec) - executable actions and procedures, including their run-time semantics, defined the concept of a data flow to carry data between actions, etc.
1.4.2	01-2005	This version was accepted as ISO specification (standard) ISO/IEC 19501. UML 1.5 was released 2 years before.
2.0	08-2005	New diagrams: object diagrams, package diagrams, composite structure diagrams, interaction overview diagrams, timing diagrams, profile diagrams. Collaboration diagrams were renamed to communication diagrams. Activity diagrams and sequence diagrams were enhanced. Activities were redesigned to use a Petri-like semantics. Edges can now be contained in partitions. Partitions can be hierarchical and multidimensional. Explicitly modeled object flows are new. Classes have been extended with internal structures and ports (composite structures). Information flows were added. A collaboration now is a kind of classifier, and can have any kind of behavioral descriptions associated. Interactions are now contained within classifiers and not only within collaborations. It is now possible for use cases to be owned by classifiers in general and not just packages. New notation for concurrency and branching using combined fragments. Notation and/or semantics were updated for components, realization, deployments of artifacts. Components can no longer be directly deployed to nodes. Artifacts should be deployed instead. Implementation has been replaced by «manifest». Artifacts can now manifest any packageable element (not just components, as before). It is now possible to deploy to nodes with an internal structure. New metaclasses were added: connector, collaboration use, connector end, device, deployment specification, execution environment, accept event action, send object action, structural feature action, value pin, activity final, central buffer node, data stores, flow final, interruptible regions, loop nodes, parameter, port, behavior, behaviored classifier, duration, interval, time constraint, combined fragment, creation event, destruction event, execution event, interaction fragment, interaction use, receive signal event, send signal event, extension, etc. Many stereotypes were eliminated from the Standard UML Profile, e.g. «destroy», «facade», «friend», «profile», «requirement», «table», «thread». Integration between structural and behavioral models was improved with better support for executable models.
2.1	04-2006	Minor revision to UML 2.0 - corrections and consistency improvements.
2.1.1	02-2007	Minor revision to the UML 2.1
2.1.2	11-2007	Minor revision to the UML 2.1.1
2.2	02-2009	Fixed numerous minor consistency problems and added clarifications to UML 2.1.2
2.3	05-2010	Minor revision to the UML 2.2, clarified associations and association classes, added final classifier, updated component diagrams, composite structures, actions, etc.
2.4.1	08-2011	Current version of UML, a minor revision to the UML 2.3, with few fixes and updates to classes, packages - added URI package attribute; updated actions; removed creation event, execution event, send and receive operation events, send and receive signal events, renamed destruction event to destruction occurrence specification; profiles - changed stereotypes and applied stereotypes to have upper-case first letter - «Metaclass» and stereotype application.
2.5 FTF – Beta 1	11-2012	Work in progress, in its finalization phase. From the UML language perspective, it will be a minor revision to the UML 2.4.1, while they spent a lot of efforts reorganizing specification document. It seems that this time professors took over researchers and industry practitioners, and instead of fixing actual UML issues they re-written UML specification to make it easier to read. For example, they tried to reduce forward references as much as possible which is an obvious requirement for textbooks but not for specifications. There will be no separate UML 2.5 Infrastructure document, so that the UML 2.5 specification will be a single document. Package merge will no longer be used within the specification itself. Four UML compliance levels (L0, L1, L2, and L3) are to be eliminated, as they were not useful in practice. UML 2.5 tools will have to support complete UML specification. Information flows, models, and templates will no longer be auxiliary UML constructs. At the same time, use cases, deployments, and the information flows to become UML supplementary concepts!