`

UML Notation and Ilogix Rhapsody Tool

阅读更多

1 UML Notation and Ilogix Rhapsody Tool

This report has been developed in the scope of the seminar "Werkzeuggestützte Modellierung des Tamagotchi" in the winter term 98/99. The seminar has been organized by the AG Software Engineering of Professor Rombach at the University of Kaiserslautern in cooperation with the TU München.
First, we had to work out a simplified safety injection device for a nuclear power plant. The main task was to produce a specification for a Tamagotchi.
Each group had to use different software design methods and CASE-tools. Our group - Christian Becker, Steffen Glomb, and Michael Graf - used the UML notation and the UML-based CASE-tool Rhapsody. All of us study computer science at the university of Kaiserslautern, at the moment in the ninth term.
The following chapters are about the experience we gained during the seminar.
 

1.1 Introduction

In this chapter, we give a short introduction to the UML notation, the applied method and the Rhapsody CASE-tool.
The pictures in this section are taken from the specification of the safety injection device.
 

1.1.1 Notation

The development of UML (Unified Modeling Language) goes back to the year 1995 when James Rumbaugh and Grady Booch decided to put together their two Software Design approaches (OMT and Booch-method). Their attempt to create a so-called Unified Method (UM) failed because they could not agree on uniform method guidelines. Instead of giving up they decided to restrict their effort on the development of a unified notation. Ivar Jacobsen (creator of the Objectory method) joined them and soon they were called the "3 Amigos". Jacobsen introduced the idea of use cases, nowadays one of the most often cited vogue words in the SE community. In January 1997 they published the first standardized version of the UML.
The amigos claim that the UML allows to specify, to construct, to visualize, and to document models of any software system. [Oes97, p.143], [FS98, p.17ff]
In the sequel, many industrial partners like Sun, IBM, and Microsoft contributed their ideas. Therefore, version 1.1 and 1.2 followed rather quickly.

The UML contains a variety of eight different diagram types whose semantics are laid down in a complex metamodel hierarchy. They can be classified according to the three main views of a system: the structural view (class diagrams, component diagrams, deployment diagrams), the behavioral view (state diagrams, collaboration diagrams, sequence diagrams), and the functional view (use case diagrams, activity diagrams). [Atk98, "Modeling dimensions"]

1.1.1.1 Description of data

One of the basic aspects of object-oriented programming languages is that data and processes are combined to form objects. An object's behavior is defined by its methods while its structure is given through its attributes (i.e. its data). A class can be regarded as the object's type or model. Each object is an instance of its class and inherits its class' behavior and but has got its own set of attributes. The class concept reduces complexity because identical information has to be declared only once.
In the UML, class diagrams are used to show information about data. This type of diagram is well known from (the notation subset of) many object-oriented methods, like the OMT or Booch. It describes the different classes that exist in the system and the static relations between them. Classes are shown as rectangles with three subsections divided by horizontal lines. The first section contains the classname, the second lists the classes' attributes while the third section contains the existing methods. Inter-class relations - aggregations, generalizations or associations - are drawn as lines connecting the class boxes. Aggregations are characterized by little diamonds while generalizations are typified by small triangles on the end of the line.
Class diagrams can contain further details like interfaces, stereotypes or constraints. Please refer to [FS98, chapter 5] for more details.

1.1.1.2 Description of behavior

The behavior of an object is defined by its methods. They imply the different states of an object.




In the UML, the object's behavior can be visualized using a statechart diagram. Doing this is especially advisable if the object's behavior is complex or significant to the system's behavior. The statechart diagram is an adoption from Harels' statecharts.




A statechart diagram shows all possible states of an object. The above example contains the states "start", "permit_and_not_blocked", "between_and_blocked", and so on. Other important elements of a statechart diagram are activities and actions. An activity is associated with a certain state whereas an action accompanies a transition. While the former take some time to happen and can be stopped prematurely by an event on an outgoing transition, the latter are considered to be atomic and are therefore not interruptable.
A transition describes the changing of states. It can be triggered by occurring events or by the ending of an activity.
Transitions are visualized by an arrow from the source state to the destination state. In the picture, the arrow between the states "start" and "permit_and_not_blocked" represents a transition that is triggered by the event "permit".
On a transition, events can be created. The timeout event "tm(1000)" triggers a transition from the state "low_and_blocked" to the state "low_and_not_blocked". As a result of the transition, the  event "start_injection" is sent to the object named "itsDevice".

Some other important features of statechart diagrams are not shown in this simple example.
For example, a transition from one state to another can be guarded by a boolean expression. Such a transition is triggered only when at the moment of the occurrence of the appropriate event, the guard evaluates to true, too.
Another important feature is the nesting of states. Substates inherit all outgoing transitions of their superstates. Using this technique, clearer and less complex statecharts can be modeled.
If an object can be in several different states simultaneously, one can describe its behavior in a concurrent state chart.
For a deeper insight in these topics, please refer to the report of the Statechart group or to [Oes97] and [FS98]

Alternatively, activity diagrams can be used - they are especially useful to describe complex concurrent behavior (its roots are SDL and petri-nets).

1.1.1.3 Description of timing requirements

Timing requirements are an important aspect of the behavioral view. In statechart diagrams, timeout events can trigger transitions. They are however no special UML feature, but have to be implemented through user-defined objects. The Rhapsody tool supports a system timer - a convenient solution. Consider "tm(1000)" in the above example on the transition from state "between_and_blocked" to "between_and_not_blocked". This means that after staying for 1000 milliseconds in the "between_and_blocked" state, the transition to the "between_and_not-blocked" state is triggered.

Sequence and collaboration diagrams are interaction diagrams. Each of them is based on a particular section of the system's behavior - sometimes called a scenario.
A scenario is like an instance of a use case or of one step of a use case. Arrows from the sender to the destination are used in both of these diagram types to show the information flow between different objects. The arrangement of these arrows corresponds to the timing in the scenario. Again, we must refer you to the literature for further details on interaction diagrams. [Oes97, p.134f] , [FS98, p.105ff]

1.1.1.4 Mechanisms to structure the specification (into manageable pieces)

First of all, the division into the three views of a system - its behavioral, its structural and its functional aspects - allows to structure the specification. As we have already mentioned, there are own diagram types for each of these views.
Grouping coherent behavior and data into classes also helps to keep the specification clear. Classes (and their objects) provide their service by public interfaces while the actual implementation is "hidden" inside.
Besides that, logically or physically coherent model elements can be organized in a package which defines a namespace for its content. Already existing libraries, subsystems or interfaces form their own packages. The purpose of the package construct is to provide a general grouping mechanism; it can be used for element organization of any purpose. The criteria for grouping elements together into one package are not defined within UML. Packages can be arranged hierarchically - that means, a package can contain other packages. [FS98, p.115], [Oes97, p.181f]
 

1.1.2 Method

A method consists of a notation and process guidelines when and how to use the provided diagram types during the modeling process. Many methods claim to be suitable for all kind of projects. According to Fowler and Scott, this is not true. They recommend to consider certain environment parameters like the size and experience of the development team or the size, complexity and type of the problem before making a decision for one method. FS98, p.27].
The UML, however, is a mere modeling language - it contains no process guidelines. Nevertheless, it can be used to support different modeling methods. Professor Colin Atkinson showed in his lecture on "Object-oriented software design" how the Fusion process can be adapted to use the UML as its notation [Atk97].

1.1.2.1 How to create and verify a requirements specification

Both the UML and Rhapsody give no process guidelines how to produce a requirements specification.

1.1.2.2 Completion criteria

The UML gives no completion criteria, too. The same is true for the tool.
 

1.1.3 Description of the Rhapsody Tool

iLogix Rhapsody is a CASE - Tool for embedded systems software development. Rhapsody is claimed to be "The Industry's first and only UML based objectoriented analysis, design and implementation tool for embedded systems and software developers." [iLogix Website].

In our seminar we used version 2.0 of Rhapsody which is the newest.
Rhapsody supports 4 different UML diagrams:
statechart diagrams, sequence diagrams, use cases and class diagrams.
In the browser window of Rhapsody all classes, diagrams or packages of a system are hierarchically arranged in a  tree, where they can be selected for view or further development.

Rhapsody offers automatic C++ Code generation and code generation with additional simulation functionality. The integrated Simulator component allows to animate the compiled code in the Rhapsody environment with animated sequence diagrams and animated statecharts. During the Simulation the state of all instanciated objects and variables can be viewed in the browser window.
Due to the functionality of Simulation, the focus of work remains at the design level throughout debugging and verification. As a result, Rhapsody allows increased focus on software design while actually reducing cycle times.

Rhapsody offers Unique Model / Code associativety, which treats the code and model as different views of the same design, provides efficient readable code, and enables round-trip engineering of the generated code. That means the generated code can be changed by the developer on the code level and reimported into Rhapsody.
 

1.2 Our approach

This chapter contains information about how we have organized our proceeding. In particular, we describe our personal development process. A few aspects of the final specification complete this chapter.
 

1.2.1 Method

We divided the development of the tamagotchi specification into two phases - a conceptualization phase and a realization phase.
All steps of the conceptualization phase were done without using the Rhapsody tool, since it has not been ready for operation during the first weeks of the term.
We did some ordinary brainstorming to gain a first idea of the Tamagotchi. The next step was to identify the use cases - what tasks are to be done by the system. They were the starting point for the system class diagram that now began to evolve.

In the realization phase we began to use Rhapsody. During this phase, we identified appropriate increments and did the necessary extensions to the class diagram and to each affected statechart diagram. Having finished a system increment, we used the built-in simulator component to perform a series of tests. Detected errors were corrected before performing a new test. After testing, we checked whether all system requirements had already been implemented. Finally, after many iterations, we were convinced that our specification met every requirement. The system specification was handed to another team for a review. During the review, further errors were detected and afterwards corrected.

1.2.2 Teamwork

Both UML and Rhapsody support partitioning of the requirements. Classes can be seen as separate areas of responsibility with their interfaces as a contract between different developers. The ease to identify independent increments and the possibility to add additional attributes and methods to a class without side-effects for already existing methods also supports the division of labor. In addition to this, Rhapsody provides an interface to use the Revision Control  RCS. Nevertheless, we did not develop separately because of three major reasons:
  1. the tool has only been installed on one computer
  2. only one group member got a professional tutorial
  3. working together enabled a quick and direct feedback

1.2.3 Consistence of the specification

We validated our system specification through the graphical simulation of the scenarios based on all equivalence classes that came to our mind. Finally, another group reviewed our documents. This review was not a complete checking of all system requirements, but a rather quick test of several randomly chosen scenarios. Therefore, we cannot speak of a truly verified system. The tool's automatic consistency checks did a good supporting job, however.
 

1.2.4 Size of the specification

We used only slight simplifications concerning the textual interface: "A Mametchi eating a snack" was easier to implement as an animated graphic. Apart from that, we believe that we succeeded in meeting all system requirements - even the timeouts have been implemented as required. We implemented additional simulation events like "sim_night" to speed up the simulation.

The final size of our specification is as follows:

  • 2 class diagrams
  • 16 statechart diagrams
  • 5 sequence diagrams
  • approximately 16.000 line of code were generated (including code to support the graphical simulator component)
     

1.3 Specification of the functionality "playing"

To meet the requirements of the functionality "playing", we designed a class called "Game". This class controls the number of rounds played and number of rounds won, and sends appropriate events to the class "Tamagotchi" to update the happiness of the Tamagotchi and to display the necessary Tamagotchi animation (won, lost, playing).
It also turns on the beeping when the game is started and turns it off when the game ends, by sending events to the buzzer.


statechart of the class Game



Concerning the playing functionality the only requirements that are implemented in class "Buzzer", are to keep beeping during a game. On the event "start_game_buzzing" the substate "gamepeeping" is entered and the beeping is started, on the event "stop_game_buzzing" the substate "gamepeeping" is left and substate "idle" is reentered. The beeping stops.


statechart of the class buzzer

The "playing" functionality must be selected in the menu of the Tamagotchi. We designed the class "Menu" for the menu of the Tamagotchi. Only the substate "playstate" is relevant for the "playing" functionality. On the initial transition of "playstate" the game is started through the event "start" send to the class "Game".
The class "Menu" receives the events "m_pressed" or "l_pressed" whenever the middle button or the left button on the Tamagotchi is pressed. In "playstate" these events are resend to the class "Game" to enable the class to receive inputs form the user to during the game.
The "playing" ends, if the right button is pressed (event "r_pressed" received by "Menu"), the substate "playstate" is left and on the leaving transition the event "end" is send to "Game".


statechart of the substate "Tamagotchilife" of the class "Menu"

1.4 Experience

This chapter contains a summary of the experience that we gained during the seminar.

1.4.1 Time spent on the seminar

Together, we needed 40 hours to get used to the notation and the CASE-tool - both topics with an equal share of time. This number represents the sum of each person's expenditures. We decided to delimit the training phase with the completion of the Safety Injection System. Nevertheless, it is a bit difficult to draw a clear border between the training phase and the productive work, since we were far from being expert software designers. So, we kept learning and reading literature while developing the tamagotchi.
The development of the tamagotchi took us about 230 hours (again, this number represents the total sum of the whole group). The overall expense contains all activities that were necessary for the modeling: the conceptualization, the realization, the simulation, and the review. While the major share fell to the actual realization, a considerable amount of time could have been saved with a better tool documentation.
The making of the transparencies and of this report took us approximately 150 hours.

1.4.2 Experience with the UML

The UML was rather easy to learn since all three of us have already used the Object Modeling Technique (OMT), which diagram types are similar to the UML style. A good introduction were the books "Objektorientierte Softwareentwicklung mit UML" from Bernd Oestereich [Oes97] and "UML konzentriert" from Martin Fowler and Kendall Scott [FS98].
UML is a rather powerful notation, because it offers a big variety of different diagram types and the three already mentioned dimensions of modeling: the structural, the functional and the behavioral aspect. Process guidelines would have been a welcome help to master the early stages of modeling, but the UML does not provide any hint at all. Besides, it can be hard to chose between the different diagram types that are provided by the UML. We did not have to take this decision however, because the tool does only support four of the eight different types.
At the beginning we had the problem that the class "Tamagotchi" became more and more complex. At the end, it contained nearly all system functionality. All other classes were much smaller and served more or less as simple data containers. Soon, it was obvious that such a design would not share the typical benefits of a modularized object-oriented approach. The behavior of this class was so complex that is was impossible to work out a lucid statechart diagram.
Our final class distribution evolved after many inner-group discussions and some hints of our tutor. We refined the tamagotchi class into a hierarchy of an abstract superclass tamagotchi and several subclasses - one for each evolution level of the virtual chicken. Apart from that, we introduced a class "Game" to gather all behavior concerning the playing.

1.4.3 Experience with Rhapsody

The installation of the Rhapsody CASE-tool by Ilogix took a whole month. First, the necessary license key was missing. Then, the available C++-compiler was not supported by the tool - so that a new compiler had to be bought.
During the realization phase we encountered the problem how to work out the sequence of the class constructor calls and the necessary includes. Apparently silly error messages turned ot to be caused by not setting the multiplicity of associations in the class diagram. Both the online help and the printed documentation did not help us with these tricky situations.
A positive aspect was its intuitive operation: drag & drop, cut & paste and the use of icons - to mention only a few features. The arrangement of every specification object in an expandable tree (called the browser) allowed a quick and comfortable work. The easy double-click navigation made it possible to inspect every detail almost instantaneously. An automatic consistency check helped to avoid some usual sources of error. For example, every variable used in a statechart diagram was automatically tested against the relevant class declaration.
The animated simulation was important for the quick validation of design increments. All objects and their values can be inspected through the browser during a simulation. Animated statecharts and sequence diagrams are generated automatically and let the user observe the behavior of the whole system. Finally, the possibility to inspect an compile-time error by double-clicking on the actual compiler output was a good assistance.

1.4.4 Review

We had to review the specification of the SCR-group, and vice versa. We did it tool based because of the lack of time. That means, we did not learn the other notation but sat together in front of the computer and let the "expert group" simulate the scenarios we wanted to see. We had not enough time to achieve a complete coverage with the system requirements. So, what we did was not more than a random sample.

1.4.4.1 Review of the SCR specification

The main deficiency of the specification of the SCR-team was the missing linkage between their tamagotchi backend and its frontend. At the stage of the review the two main system sections did not yet fit together. This made it almost impossible to review the specification. But there more reasons that make it hard to check the completeness and the comprehension of the specification: the SCR*-tool is only a scientific prototype - its handling is rather uncomfortable and awkward, since it has been developed with significantly less manpower than our commercial tool. For example, an annoying display fault made it hard to follow the simulation: Every variable that had changed its value since the last simulation step was "highlighted" with a black box. Unfortunately, the value was also displayed with black letters. Besides, the tables that dealt with the behavior of the tamagotchi contained a huge amount of different variables. The other group claimed that this fact was because the tool demanded such a complex modeling. Consult the final report of the SCR-team for a deeper insight in this. Finally, the SCR*-tool compels the user to set most of the many variables manually during the simulation.

1.4.4.2 Review of the UML specification

Rhapsody makes it easy to observe the system's behavior through its good simulator component. One can observe every class with relevant behavioral aspects in an animated statechart. Every instance of a class and every attribute value can be viewed with the tool's browser. Animated sequence diagrams complete the set of useful utilities. Unfortunately, the tool does not support a textual review, because entry and exit events of the statechart diagrams cannot be printed out.
Since some system requirements are mapped into more than one class, it may be difficult for persons who do not take part in the development process, to survey the implementation. A data dictionary and a project wide usage list for attributes, methods and events would have been handy.
As a result of the review of our specification, we learned that our tamagotchi had problems to fall asleep. When the "Bioclock" class (the tamagotchi's timing component) sent the sleeping signal while the user was playing with the tamagotchi or about to feed it, an inconsistent behavior was triggered. Although the tamagotchi object entered the state "asleep" and refused every user signal, the game's and the menu's states remained active. The problem was solved by introducing "asleep" -states for the mentioned classes, too.
 

1.5 Conclusions

This chapter contains a judging of the utility of teamwork in general and of the used notation and tool.

1.5.1 Appraisal of the teamwork

Even though we did not work independently, we believe that we profited by the team development. Most of all, the direct inner-group feedback helped to detect many errors before they could find their way into the specification. Brainstorming sessions were a very fertile means in the conceptualization and the early realization phase. Finally, the mutual motivation helped to overcome many obstinate errors.

1.5.2 Appraisal of the UML

The UML proved to be a mighty and understandable notation. It supports an incremental development because of the modularity of the classes and the possibility to decompose complex aspects hierarchically. Besides, the various concurrent behavioral aspects of an embedded real-time system like the tamagotchi can be captured easily in the statechart diagrams. The division into reasonable classes was a bit tricky at the beginning. After the elaboration of a good class diagram however, the object-oriented view of the system meets the human way of thinking.
The fact that the UML is about to become the standard object-oriented modeling notation is likely to produce synergy effects. The designers will at last be able to concentrate on the more important facts like design patterns instead of always be forced to learn new notations.

1.5.3 Appraisal of Rhapsody

Altogether, we were content with the Rhapsody tool. Although Rhapsody does not provide all UML diagram types, all we needed for our specification was at hand.
A very positive aspect was the already mentioned intuitive usage. Automatic consistency checks helped to avoid some usual sources of error. For example, every variable used in a statechart diagram was automatically tested against the relevant class declaration. The animated simulation was important for the quick validation of design increments. Finally, the possibility to inspect an error by double-clicking on the actual compiler output was a good assistance.

But there were also some negative points. Both the online help and the printed documentation were rather fragmentary. Most tool handling problems had to be solved by trial and error. The absence of an undo-function was a source of frustration, especially because sometimes even a manual "redo" was impossible. Therefore, one should often make backups. Another weakness has already been mentioned: The fact that in a statechart diagram, all one can see from entry and exit events are ">" - signs makes it impossible to review the printed specification.
Apart from the removal of these weaknesses, it would be desirable to have some additional features: A simulator-frontend would make the simulation more comfortable. With Rhapsody, the user has to specify extern trigger signals in a textbox. Additionally, Rhapsody should provide all UML diagram types to make it fit for every UML based development method. Finally, it would be fine if the product supported a greater variety of platforms and compilers.

Nevertheless, we are convinced that using Rhapsody allowed us to produce a better specification than a simple diagram drawing program. Besides, further projects would benefit from the familiarity with the tool that we gained by now.
 

1.6 Literature references

  • [Oes97] : "Objektorientierte Softwareentwicklung mit UML", Bernd Oesterreich, Oldenbourg, ISBN 3-486-24319-5
  • [FS98] : "UML konzentriert", Martin Fowler and Kendall Scott, Addison-Wesley, ISBN 3-8273-1329-5
  • [Atk97] : "Adapting the Fusion Process to Support the UML", Colin Atkinson, Object Magazine, Sigs Publications, Nov.97
  • Reference website : www.rational.com
  • Reference website : www.ilogix.com
WS 1998/99 Christian Becker, Steffen Glomb, Michael Graf
分享到:
评论

相关推荐

    UML1.1_Notation

    ### UML 1.1 Notation Guide:统一建模语言的可视化表示 #### 文档概述 UML(Unified Modeling Language)1.1 Notation Guide 是一份详尽介绍UML符号体系的标准文档,它旨在为软件开发人员提供一套统一且标准化的...

    Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

    These case studies incrementally introduce key skills, essential OO principles and patterns, UML notation, and best practices. You won\'t just learn UML diagramsyou\'ll learn how to apply UML in the ...

    UML and the Unified Process.pdf

    modeling and designs into code and enable object-oriented visual modeling tool interoperability. There are still important issues to be solved in a satisfactory way. Techniques that currently exist in...

    Addison.Wesley.Real-Time Design Patterns.chm

    Rhapsody(TM)—a UML-compliant design automation tool that captures the analysis and design of systems and generates full behavioral code with intrinsic model-level debug capabilities RapidRMA(TM)—a...

    TRex - the TTCN-3 Refactoring and Metrics Tool

    Experience with those written in the standardised Testing and Test Control Notation (TTCN-3) has shown that the maintenance of test suites is a non-trivial task and its burden can be reduced with ...

    UML和模式应用英文第三版

    These case studies incrementally introduce key skills, essential OO principles and patterns, UML notation, and best practices. You won't just learn UML diagramsyou'll learn how to apply UML in the ...

    UML Specification 2.5.1.zip

    One of the primary goals of UML is to advance the state of the industry by enabling object visual modeling tool interoperability.However, to enable meaningful exchange of model information between ...

    UML综合经典练习题集.pdf

    本资源是关于UML(Unified Modeling Language,统一建模语言)的综合经典练习题集,包含了UML的基本概念、notation、关系、类图、用例图、状态机、活动图、顺序图等多种图表类型的知识点。 资源详细信息: 1. UML...

    UML Distilled

    Now widely adopted as the de facto industry standard and sanctioned by the Object Management Group, the Unified Modeling Language (UML) is a notation all software developers need to know and ...

    Aspect.Oriented.Software.Development.with.Use.Cases [chm]

    Addison.Wesley.Aspect.Oriented.Software.Development.with.Use.Cases ...Modeling use-cases slices and aspects using the newest extensions to the UML notation Applying use cases and aspects in projects

    1_Intro_02 Data Model Description with UML and XML.pdf

    在数据模型描述中,UML提供了多种notation,例如类图、状态机图、 sequences图等。这些notation可以用来描述系统的静态结构和动态行为。 在ODX(Open Diagnostic eXchange)规范中,UML被用来描述数据模型。ODX是...

    UML参考手册.pdf pdf版本

    Grady Booch、Ivar Jacobson 和 James Rumbaugh 等人开始开发 UML,目的是为了统一不同的开发方法和notation。1995 年,UML 0.9 版本发布,1997 年,UML 1.1 版本发布,标志着 UML 的正式诞生。 UML 的目标是提供一...

    TF1910_TC3_UML_EN.pdf

    UML 编程基础知识 UML(Unified Modeling Language,统一建模语言)是一种标准化的图形化建模语言,用于描述、设计和文档化软件系统。它提供了一种通用的语言和notation,用于描述软件系统的架构、组件和交互。 ...

    UML建模案例分析二网络教学系统UML建模

    1. 提高软件的可读性和可维护性:UML模型提供了一个通用的语言和notation,帮助开发人员快速理解和维护软件的设计和实现。 2. 改进软件的可重用性:UML模型可以帮助开发人员设计可重用的软件组件,减少软件开发的...

    Modelling.software.with.pictures.Practical.UML.diagramming.for.real-time.systems

    This book sets out to show embedded software engineers how to model their designs using diagrams in an effective, clear and useful way. A key aspect in all of...Chapter 10 - Outline guide to UML notation

    UML1.0简介及描述

    UML包括语义(Semantics)、符号(Notation)和结构与行为视图(Structural and Behavioral Views)。语义部分定义了UML的含义和规则;符号部分则是UML元素的可视化表示;而结构与行为视图则涵盖了静态结构和动态...

    UML Tutorial (English)

    在20世纪80年代至90年代期间,软件工程领域内涌现出了多种不同的设计语言和技术方法,如OMT(Object Modeling Technique)、Coad & Yourdon 方法、BON(Booch Object Notation)、SDL(Specification and ...

    UML与UML复习题与答案

    它提供了一种通用的语言和notation来描述软件系统的设计、分析和实现。 UML的三个主要特性是: 1. UML是一种语言,是一种表示法,本身不包含任何方法论的部分; 2. UML是一种建模语言,不是用于编程而是用于建模;...

    uml教程(日语版)

    - **UML Notation Guide**:定义了UML的图形表示法及其示例,这是描述UML元模型语义的图形语法。 - **Process Specialization Extension** 和 **Business Modeling Extension**:涵盖了UML的扩展机制和特定过程图标...

Global site tag (gtag.js) - Google Analytics