No older revisions available
No older revisions available
1. Aspects of Functionality ¶
UML Case 툴의 기능은 크게 다음의 3가지로 구분할 수 있다. round-trip 기능은 최근의 case tools의 발전중에 나오는 기능임. 필수적인 기능으로 보이지는 않음.
1.1. Diagramming ¶
Diagramming in this context means creating and editing UML diagrams; that is diagrams that follow the graphical notation of the Unified Modeling Language.
The diagramming part of the Unified Modeling Language seems to be a lesser debated part of the UML, compared to code generation.
The UML diagram notation evolved from elderly, previously competing notations. UML diagrams as a means to draw diagrams of - mostly - object oriented software is less debated among software developers. If developers draw diagrams of object oriented software, there is widespread consensus to use the UML notation for that task. On the other hand, it is debated, whether those diagrams are needed at all, on what stage(s) of the software development process they should be used and whether and how (if at all) they should be kept up-to date, facing continuously evolving program code.
1.2. Code generation ¶
Code generation in this context means, that the user creates UML diagrams, which have some connoted model data, from which the UML tool derives (through a conversion process) parts or all of the source code for the software system that is to be developed. Often, the user can provide some skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts, emitted by the UML tool during the code generation process.
There is some debate among software developers about how useful code generation as such is. It certainly depends on the specific problem domain and how far code generation should be applied. There are well known areas where code generation is an established practice, not limited to the field of UML. On the other hand, the idea of completely leaving the "code level" and start "programming" on the UML diagram level is quite debated among developers, and at least, not in such widespread use compared to other software development tools like compilers or software configuration management systems. An often cited criticism is that the UML diagrams just lack the detail which is needed to contain the same information as is covered with the program source. There are developers that even state that "the Code is the design" (articles http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves http://www.bleading-edge.com/).
1.3. Reverse engineering ¶
Reverse engineering in this context means, that the UML tool reads program source code as input and derives model data and corresponding graphical UML diagrams from it (as opposed to the somewhat broader meaning described in the article "Reverse engineering").
Reverse engineering encloses the problematic, that diagram data is normally not contained with the program source, such that the UML tool, at least in the initial step, has to create some random layout of the graphical symbols of the UML notation or use some automatic layout algorithm to place the symbols in a way that the user can understand the diagram. For example, the symbols should be placed at such locations on the drawing pane that they don't overlap. Usually, the user of such a functionality of an UML tool has to manually edit those automatically generated diagrams to attain some meaningfulness. It also often doesn't make sense to draw diagrams of the whole program source, as that represents just too much detail to be of interest at the level of the UML diagrams. There are also language features of some programming languages, like class- or function templates of the programming language C++, which are notoriously hard to convert automatically to UML diagrams in their full complexity.
1.4. "Round trip" engineering ¶
There are UML tools that use the attribute round trip (sometimes also denoted as round trip engineering) to connote their ability to keep the source code, the model data and the corresponding UML diagrams in sync.
This means that the user should be able to change either the model data (together with the corresponding diagrams) or the program source code and then the UML tool updates the other part automatically.
2. List Of UML Case Tool ¶
- http://en.wikipedia.org/wiki/List_of_UML_tools
현존하는 대 부분의 케이스 툴의 종류를 알 수 있다.
Rational Software Architect, Together가 유명하고, 오픈 소스로는 Argo, Violet 이 유명하다.
UML 케이스 툴과 달리 Visio 같은 경우에는 Diagramming 기능만을 제공한다. Diagramming Tool 이라고 분류하는 듯하다.
현존하는 대 부분의 케이스 툴의 종류를 알 수 있다.
Rational Software Architect, Together가 유명하고, 오픈 소스로는 Argo, Violet 이 유명하다.
UML 케이스 툴과 달리 Visio 같은 경우에는 Diagramming 기능만을 제공한다. Diagramming Tool 이라고 분류하는 듯하다.