- UML . . . . 31 matches
== Unified Modeling Language(UML) ==
In software engineering, Unified Modeling Language (UML) is a non-proprietary, third generation modeling and specification language. However, the use of UML is not restricted to model software. It can be used for modeling hardware (engineering systems) and is commonly used for business process modeling, organizational structure, and systems engineering modeling. The UML is an open method used to specify, visualize, construct, and document the artifacts of an object-oriented software-intensive system under development. The UML represents a compilation of best engineering practices which have proven to be successful in modeling large, complex systems, especially at the architectural level.
== UML Diagram types ==
This diagram describes the structure of a simple Restaurant System. UML shows [[Inheritance_(computer_science)|Inheritance]] relationships with a [[triangle]]; and containers with [[rhombus|diamond shape]]. Additionally, the role of the relationship may be specified as well as the cardinality. The Restaurant System has any number of Food dishes(*), with one Kitchen(1), a Dining Area(contains), and any number of staff(*). All of these objects are associated to one Restaurant.
[http://upload.wikimedia.org/wikipedia/en/2/20/Restaurant-UML-SEQ.gif]
=== Collaboration Diagram /Communication Diagram (UML 2.0) ===
A Collaboration diagram models the interactions between objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from [[#UML_Class Diagram|Class]], [[#UML_Sequence_Diagram|Sequence]], and [[#UML_Use_Case_Diagram|Use Case Diagrams]] describing both the static structure and dynamic behavior of a system.
In UML 2.0, the Collaboration diagram has been simplified and renamed the Communication diagram.
== Criticisms of UML ==
Although UML is a widely recognized and used standard, it is criticized for having imprecise semantics, which causes its interpretation to be subjective and therefore difficult for the formal test phase. This means that when using UML, users should provide some form of explanation of their models.
Another problem is that UML doesn't apply well to distributed systems. In such systems, factors such as serialization, message passing and persistence are of great importance. UML lacks the ability to specify such things. For example, it is not possible to specify using UML that an object "lives" in a [[server]] process and that it is shared among various instances of a running [[process]].
At the same time, UML is often considered to have become too bloated, and fine-grained in many aspects. Details which are best captured in source code are attempted to be captured using UML notation. The [[80-20 rule]] can be safely applied to UML: a small part of UML is adequate for most of the modeling needs, while many aspects of UML cater to some specialized or esoteric usages.
(However, the comprehensive scope of UML 2.0 is appropriate for [[model-driven architecture]].)
A third problem which leads to criticism and dissatisfaction is the large-scale adoption of UML by people without the required skills, often when management forces UML upon them.
[UML서적관련추천] - [1002] 형의 OP 게시판 펌
[http://www.codeproject.com/cpp/oopuml.asp] - UML 강좌
[http://blog.empas.com/huikyun/] - UML에 대해서 잘 정리된 블로그
[http://www.sparxsystems.com.au/resources/uml2_tutorial/] - 좋은 UML 튜토리얼
- UML/CaseTool . . . . 25 matches
UML Case 툴의 기능은 크게 다음의 3가지로 구분할 수 있다. round-trip 기능은 최근의 case tools의 발전중에 나오는 기능임. 필수적인 기능으로 보이지는 않음.
''Diagramming'' in this context means ''creating'' and ''editing'' UML [[diagram]]s; 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 programming|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.
''[[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 [[compiler]]s or [[Configuration management|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/]).
''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 language]]s, like ''class-'' or ''function templates'' of the programming language [[C plus plus|C++]], which are notoriously hard to convert automatically to UML diagrams in their full complexity.
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.
== List Of UML Case Tool ==
- [http://en.wikipedia.org/wiki/List_of_UML_tools]
UML 케이스 툴과 달리 Visio 같은 경우에는 Diagramming 기능만을 제공한다. Diagramming Tool 이라고 분류하는 듯하다.
- UML서적관련추천 . . . . 8 matches
[UML]
UML 과 관련하여 '정석적'인 접근을 말씀드리면, 다음의 책을 보게 됩니다.
UML Distilled: A Brief Guide to the Standard Object Modeling Language,3rd Edition
UML 에 대한 개론서입니다. 두께도 얇고, 도서관에도 있습니다. 내용 상의 서술은 오히려 어느정도 개발을 한 사람들이 재미있게 읽을 만한 것이긴 하나, 개론서로 읽어도 괜찮을 것 같습니다.
UML 을 만든 소위 Three-Amigo 라 불리는 3명이 저자인 책입니다. Grady Booch, Ivar Jacobson, James Rumbaugh. 1판 번역서가 도서관에 있던걸로 기억하는데, 앞부분만 읽어보셔도 정말 예술인 책입니다. 처음 읽었을때, '모델' 이라는 개념에 대해서 이렇게 멋지게 서술한 책이 또 있을까 생각이 들던 책이였습니다. 그리고, UML 을 공부할때 소위 '정석적'이라고 이야기하는 것들은 아마 이 유저가이드나 Reference Manual 에서 언급된 설명을 기준으로 말할 것이라 생각이 듭니다.
참고로, 저는 Reference Manual 은 안읽어봤고, 위의 두 권은 읽어봤습니다. 그리고 UML 3일 가이드 같은 가벼운 책들을 읽었습니다. (하지만, 기억력이 나빠서.. 종종 다시 읽으면서 리프레쉬 해야 합니다;; 아마 조교 치고 다이어그램 자주 틀릴 겁니다;;;)
참고로 UML 은 'Modeling Language' 입니다. 모델링 서술을 위한 언어일 뿐, 모델링이나 디자인 방법 자체에 대한 설명을 하진 않습니다. 디자인 관련 서적은 따로 서술하겠습니다.
- ProjectZephyrus/ServerJourney . . . . 4 matches
* 0604에 의논한 내용 Server 측 UML에 추가
* ["ProjectZephyrus/Server"] 진행 상황 , UML history 추가
* Logout 클래스 작성, Rename작업, 04일에 의논한 내용 UML에 반영
* UML을 기반으로 상규에서 현재 구축해놓은 아이디어, 디자인 설명 [[BR]]
- 1002/Journal . . . . 3 matches
Python 이용. 적당히 TDD 와 중간 UP Front를 섞었다. (CRC와 UML을 이용) 거의 정규표현식이나 find 등을 이용한 스트링 파싱 노가다급이지만, 하루 작업치곤 생각보다 많이 나간 것 같다.
* SE - UML. 미리 접한 내용이라 생각되어서인지 긴장감이 떨어졌다. 80-100 여장의 PPT를 1시간정도에 다 설명하시는 교수님을 보면 PL 시간과 천지차이다. (PL는 1시간에 6~12장;)
* Simple Design 에 대해서 내가 잘못 생각한 것 같다. Up-Front Design 자체를 구체적으로 들어갔을때 얼마나 복잡할 수 있는지도 모르면서 처음부터 Simple Design 을 논할수 있을까 하는 생각도 해본다. 생각해보니, 여태껏 내가 그린 전체 UML Class Design 은 거의 다 Simple Design 이겠군. -_-; (Interface 들 Method 이름도 결정 안했으니까.)
- APlusProject . . . . 2 matches
UML, 실전에서는 이것만 쓴다. - UML 공부. PL 필독.
- ExtremeProgramming . . . . 2 matches
Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 ["Refactoring"], 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.
* [http://www.trireme.com/whitepapers/process/xp-uml/xp-uml-short_files/frame.htm eXtremeProgrammingMeetsUML] - 아직 읽어보지 않았음.
- OOP . . . . 2 matches
[UML]로 표기할수 있다.
[http://www.codeproject.com/cpp/oopuml.asp UML&OOP]
- ObjectWorld . . . . 2 matches
* http://www.freemethod.org:8080/bbs/UML1-SAintro.ppt
* http://www.freemethod.org:8080/bbs/UML1-JavaArchitectureChanges.ppt
- UseCase . . . . 2 matches
나는 Alistair Cockburn이나 KentBeck, Robert C. Martin 등의 최소 방법론 주의(barely sufficient methods)를 좋아한다. 나는 이 미니말리즘과 동시에 유연성, 빠른 변화대처성 등이 21세기 방법론의 주도적 역할을 할 것이라 믿어 의심치 않는다. Robert C. Martin이 자신의 저서 ''UML for Java Programmers''(출판예정)에서 [http://www.objectmentor.com/resources/articles/Use_Cases_UFJP.pdf Use Cases 챕터]에 쓴 다섯 페이지 글이면 대부분의 상황에서 충분하리라 본다.
그는 UseCase와 UML의 UseCase Diagram은 다른 것이라고 말하며, UseCase를 기록할 때 단순히 NoSmok:IndexCards 에 해당 UseCase의 이름만 기록해 두고, 나머지는 구두로 의견교환을 할 것을 추천한다. 그렇게 하고 시간이 지나면서 구현 내용이 점점 중요해지면 그 구체적인 내용을 카드의 여백에 채워넣으라고 한다.
- [Lovely]boy^_^/Diary/2-2-9 . . . . 2 matches
* 초보자를 위한 UML책 빌렸다. 역자가 곽용재씨군.(이 사람 번역 짱이던데.)
* I borrow the UML for beginner. Translator is Kwak Yong Jae.(His translation is very good)
- 프로그램내에서의주석 . . . . 2 matches
그리고 개인적으론 Server 쪽 이해하기로는 Class Diagram 이 JavaDoc 보는것보다 더 편했음. 그거 본 다음 소스를 보는 방법으로 (완벽하게 이해하진 않았지만.). 이건 내가 UML 에 더 익숙해서가 아닐까 함. 그리고 Java Source 가 비교적 깨끗하기에 이해하기 편하다는 점도 있겠고. (그래 소스 작성한 사람 칭찬해줄께;) --석천
좌절이다. 일단 자네 의견에 동의 정도가 아니라 같은 의도의 말이었다. 위의 자네 말에 대한 내가 의미를 불확실하게 전달한거 같아서 세단락 정도 쓴거 같은데.. 휴 일단 다시 짧게 줄이자면, "프로그래머의 낙서의 표준"인 UML과 {{{~cpp JavaDoc}}}의 출발은 아예 다르다. 자네가 바란건 디자인 단위로 프로그래밍을 이해하길 원한거 같은데, 그것을 {{{~cpp JavaDoc}}}에서 말해주는건 불가능하다고 생각한다. Sun에서 msdn에 대응하기 위해(?) {{{~cpp JavaDoc}}}이 태어난것 같은데 말이다. [[BR]]
- 5인용C++스터디/키보드및마우스의입출력 . . . . 1 match
VK_NUMLOCK / 90 / Num Lock
- Benghun/Diary . . . . 1 match
table에 대한 query가 여러 곳에 분산되어 있었다. table이 변경되자 모든 코드를 살펴야 했었다. 이 문제를 해결하기 위해 테이블에 접근하는 클래스와 쿼리를 실행하는 클래스를 추가했다. Java 웹 애플리케이션 프레임웍 분석과 설계의 노하우, Applying UML and Patterns, 마소 2003/7 고전을 찾아서4 모듈화와 정보은닉의 상관관계가 도움을 줬다.
- Eclipse . . . . 1 match
* http://www.eclipseuml.com/ UML 저작
- ExtremeBear/Plan . . . . 1 match
* UML
- GRASP . . . . 1 match
'''''이 내용은 Applying UML and Patterns CHAPTER 22 [GRASP]에서 얻어온 것입니다'''''
- GofStructureDiagramConsideredHarmful . . . . 1 match
Each GoF pattern has a section called "Structure" that contains an OMT (or for more recent works, UML) diagram. This "Structure" section title is misleading because it suggests that there is only one Structure of a Pattern, while in fact there are many structures and ways to implement each Pattern.
- HolubOnPatterns/밑줄긋기 . . . . 1 match
* 어떤 사람들은 이러한 방식으로 CRC카드를 이용해 실제 프로그램까지도 디자인하지만 이 방식은 복잡한 대규모 프로그램까지 수용할 정도로 효율적이지는 않다. 대부분의 프로그래머는 정식 프로세스를 사용하여 UML로 동적 모델과 정적 모델을 개발한다.
- KDPProject . . . . 1 match
* UML관련
* http://www.uml.co.kr/ - uml관련 지식 학술 토론 사이트
- ProjectZephyrus/ClientJourney . . . . 1 match
1002의 경우 UML을 공부한 관계로, 좀 더 구조적으로 서술 할 수 있었던 것 같다. 설명을 위해 Conceptual Model 수준의 Class Diagram 과 Sequence, 그리고 거기에 Agile Modeling 에서 잠깐 봤었던 UI 에 따른 페이지 전환 관계에 대한 그림을 하나 더 그려서 설명했다. 하나의 프로그램에 대해 여러 각도에서 바라보는 것이 프로그램을 이해하는데 더 편했던 것 같다. [[BR]]
- ProjectZephyrus/Server . . . . 1 match
=== Server UML ===
- PyIde/SketchBook . . . . 1 match
현재의 UML Case Tool들은 Beyond Literate Programming 일까?
- UnifiedModelingLanguage . . . . 1 match
#Redirect UML
- 레밍즈프로젝트 . . . . 1 match
[(zeropage)UML] : [AgoraPlastic]
- 레밍즈프로젝트/다이어그램 . . . . 1 match
== UML ==
- 레밍즈프로젝트/연락 . . . . 1 match
2. UML. GAME클래스 내부를 그려서 설명해 보았는데. 드로잉 부분에서 윈도우 핸들과 종속이 걸린대. 수정 방법에 대해서도 이야기 해 주셨는데. 현재 코드 부분에서는 CMyDouBuff 부분 이외에는 수정할 곳 이 없어. 일단 클래스 구조는 잘 짠듯 싶어!!
- 신재동/내손을거친책들 . . . . 1 match
자바 프로그래머를 위한 UML 실전에서는 이것만쓴다! - 로버트 C. 마틴
- 정모/2004.5.21 . . . . 1 match
- UML
- 정모/2011.4.4 . . . . 1 match
* 튜터링 수업은 정규 수업 진도를 꼭 따라갈 필요는 없을 듯 합니다. 작년에 튜터링 수업을 들었던 경험상, 튜터 선배님이 다들 1년동안 배운 C, C++과 공통된 문법은 넘어가고 클래스부터 설명을 하였습니다. 그리고 수업 외에 이때 내가 알았으면 좋았을거다! 싶다 생각한 것을 가르쳐 주셨습니다. map, set에 대한 간단한 설명이나, UML 사용법에 관한 프린트를 뽑아와 알아두면 좋다 하시기도 하고, MVC에 대해 예시를 들어 설명하시기도 하고, 인터페이스를 저그, 프로토스, 테란의 공통된 기능을 묶어 설명하기도 하고... 열심히 연습하며 따라가면 좋았을텐데 저의 성찰일지는 늘 공부를 했어야 했는데...로 끝났다는 게 미스지만요ㅠㅠ([강소현])
- 프로그래밍파티 . . . . 1 match
* 클래스 다이어그램(UML, CRC 카드, 혹은 어떤 종류의 일관된 다이어그램이면 가능) ''--> 이걸 그릴 수 있는 매직펜과 전지가 필요하겠네요''
Found 31 matching pages out of 7555 total pages (5000 pages are searched)
You can also click here to search title.
