UML은 실용적입니까?

UML은 실용적입니까? [닫은]

---

대학에서 수많은 디자인 및 UML 지향 과정을 겪었으며 UML을 사용하여 소프트웨어 프로젝트, 특히 사용 사례 매핑 에 도움이 될 수 있지만 실제로는 실용적입니까? 나는 몇 가지 협동 작업 용어를 수행했으며 UML이 업계에서 많이 사용되지 않는 것으로 보입니다. 프로젝트 중에 UML 다이어그램을 작성하는 것이 가치가 있습니까? 또한 클래스 다이어그램은 일반적으로 유용하지 않습니다. 클래스의 헤더 파일을 보는 것이 더 빠르기 때문입니다. 특히 어떤 다이어그램이 가장 유용합니까?

편집 : 내 경험은 10 가지 개발자 프로젝트에서 소규모로 제한됩니다.

편집 : 좋은 답변이 많지만 가장 장황하지는 않지만 선택한 것이 가장 균형이 맞습니다.

---

충분히 복잡한 시스템 에는 UML유용한 곳이 있습니다 .

시스템에 유용한 다이어그램은 적용 분야에 따라 다릅니다.
그러나 가장 널리 사용되는 것은 다음과 같습니다.

• 클래스 다이어그램
• 상태 다이어그램
• 활동 다이어그램
• 시퀀스 다이어그램

그들에 의해 맹세하는 많은 기업이 있으며, 많은 시간과 노력의 낭비로 완전히 거부하는 많은 기업이 있습니다.

배를 타지 말고 현재 진행중인 프로젝트에 가장 적합한 것을 생각하고 적용 할 수 있고 적합한 것을 선택하는 것이 가장 좋습니다.

---

UML을 사용하는 것은 걷는 동안 발을 보는 것과 같습니다. 그것은 당신이 무의식적으로 할 수있는 의식적이고 명백한 것을 만들고 있습니다. 초보자는 자신이하는 일에 대해 신중하게 생각해야하지만 전문 프로그래머는 자신이하는 일을 이미 알고 있습니다. 대부분의 경우, 코드 자체를 작성하는 것이 프로그래밍 직관이 작업에 맞게 조정되어 있기 때문에 코드에 대해 작성하는 것보다 빠르고 효과적입니다.

그것은 당신이하고있는 일에 관한 것이 아닙니다. 지금부터 6 개월 안에 와서 코드 속도를 높이기 위해 필요한 신입 사원은 어떻습니까? 현재 프로젝트를 진행하고있는 모든 사람이 사라진 후 5 년은 어떻습니까?

나중에 프로젝트에 참여하는 모든 사람이 사용할 수있는 기본적인 최신 문서를 보유하는 것이 매우 도움이됩니다. 나는 메소드 이름과 매개 변수를 사용하여 완전히 날려 버린 UML 다이어그램을 옹호하지는 않지만 (방법을 유지하기가 너무 어렵습니다) 관계 및 기본 동작을 가진 시스템 구성 요소의 기본 다이어그램은 매우 중요하다고 생각합니다. 시스템의 설계가 급격히 변하지 않는 한, 구현이 조정 되더라도이 정보는 크게 변하지 않아야합니다.

문서화의 핵심은 중재라는 것을 알았습니다. 아무도 잠들지 않고 디자인 문서와 함께 50 페이지 분량의 UML 다이어그램을 읽지 않을 것입니다. 반면에, 대부분의 사람들은 5-10 페이지의 간단한 클래스 다이어그램을 얻는 것을 좋아합니다. 시스템이 합쳐집니다.

UML이 유용한 것으로 밝혀진 다른 경우는 선임 개발자가 구성 요소 설계를 담당하지만 설계를 주니어 개발자에게 전달하여 구현하는 경우입니다.

---

UML을 사용하는 것은 걷는 동안 발을 보는 것과 같습니다. 그것은 당신이 무의식적으로 할 수있는 의식적이고 명백한 것을 만들고 있습니다. 초보자는 자신이하는 일에 대해 신중하게 생각해야하지만 전문 프로그래머는 자신이하는 일을 이미 알고 있습니다. 대부분의 경우, 코드 자체를 작성하는 것이 프로그래밍 직관이 작업에 맞게 조정되어 있기 때문에 코드에 대해 작성하는 것보다 빠르고 효과적입니다.

예외는 밤에 횃불없이 숲에서 자신을 발견하고 비가 내리기 시작한 이유입니다. 그러면 넘어지지 않도록 발을보아야합니다. 수행 한 작업이 직관이 처리 할 수있는 것보다 복잡한 경우가 종종 있으며 프로그램의 구조를 느리게하고 명시 적으로 명시해야합니다. 그런 다음 UML은 사용할 수있는 많은 도구 중 하나입니다. 다른 것에는 의사 코드, 고급 아키텍처 다이어그램 및 이상한 은유가 포함됩니다.

---

일반적인 작업 흐름 및 DFD는 복잡한 프로세스에 매우 유용 할 수 있습니다. 다른 모든 다이어그램 (ESPECIALLY UML)은 예외없이 시간과 노력을 낭비하는 예외가 없었습니다.

---

UML은 모든 곳에서 사용됩니다. IT 프로젝트가 설계되는 모든 곳에서 UML이 일반적으로있을 것입니다.

이제 잘 사용되는지 는 또 다른 문제입니다.

Stu가 말했듯이 유스 케이스 (유스 케이스 설명과 함께)와 활동 다이어그램이 개발자 관점에서 가장 도움이되는 것으로 나타났습니다.

클래스 다이어그램은 관계 및 지속성과 같은 객체 속성을 표시 할 때 매우 유용 할 수 있습니다. 단일 속성이나 속성을 추가 할 때 특히 코드가 작성되면 종종 빨리 만료되기 때문에 과도하게 사용됩니다.

UML의 가장 큰 문제점 중 하나는 코드에서 UML을 다시 엔지니어링 할 수있는 도구가 거의없고 여전히 잘 수행하는 도구가 없기 때문에 코드가 생성 된 후이를 최신 상태로 유지하는 데 필요한 작업량입니다.

---

대규모 (IBM과 유사한) 회사 개발 환경에 대한 경험이 없다고 언급함으로써 답변을 얻을 수 있습니다.

나는 UML과 보는 방식 합리적인 통합 프로세스 가 더 있다는 것입니다 TALKING는 당신이 실제로보다 어떻게 할것인지 뭐하는 당신이 할 거냐.

(즉, 그것은 대부분 시간 낭비입니다)

---

내 의견으로는 버리십시오. UML은 아이디어를 전달하는 데 유용한 도구입니다. 유일한 문제는 기본적으로 동일한 정보의 사본 두 개를 작성하기 때문에 아이디어를 저장하고 유지하는 경우에만 발생합니다. 초기 구현 라운드 후 대부분의 UML은 소스 코드에서 생성되어야합니다. 그렇지 않으면 매우 빨리 만료되거나 최신 상태를 유지하는 데 많은 시간 (수동 오류 포함)이 필요합니다.

---

나는 학교에서 마지막 두 학기 동안 수석 개발 프로젝트 과정을 공동 강의했습니다. 이 프로젝트는 지역 비영리 단체가 유료 고객으로 운영되는 프로덕션 환경에서 사용하도록 고안되었습니다. 우리는 코드가 예상 한대로 작동했으며 학생들이 고객의 요구를 충족시키는 데 필요한 모든 데이터를 캡처하고 있는지 확인해야했습니다.

수업 시간은 교실 밖에서의 시간과 마찬가지로 제한되었습니다. 따라서 모든 수업 회의에서 코드 검토를 수행해야했지만 25 명의 학생들이 등록한 개별 검토 시간은 매우 짧았습니다. 이러한 검토 세션에서 가장 유용한 도구는 ERD, 클래스 다이어그램 및 시퀀스 다이어그램이었습니다. ERD와 수업 다이어그램은 Visual Studio에서만 수행되었으므로 ERD와 수업 다이어그램은 학생들에게 사소한 시간이었습니다.

The diagrams communicated a great deal of information very quickly. By having a quick overview of the students' designs, we could quickly isolate problem areas in their code and perform a more detailed review on the spot.

Without using diagrams, we would have had to take the time to go one by one through the students' code files looking for problems.

---

I am coming to this topic a little late and will just try an clarify a couple minor points. Asking if UML is useful as far too broad. Most people seemed to answer the question from the typical/popular UML as a drawing/communication tool perspective. Note: Martin Fowler and other UML book authors feel UML is best used for communication only. However, there are many other uses for UML. Above all, UML is a modeling language that has notation and diagrams mapped to the logical concepts. Here are some uses for UML:

• Communication
• Standardized Design/Solution documentation
• DSL (Domain Specific Language) Definition
• Model Definition (UML Profiles)
• Pattern/Asset Usage
• Code Generation
• Model to Model transformations

Given the uses list above the posting by Pascal is not sufficient as it only speaks to diagram creation. A project could benefit from UML if any of the above are critical success factors or are problem areas that need a standardized solution.

The discussion should expanded out from how UML can be over kill or applied to small projects to discuss when UML makes sense or will actually improve the product/solution as that is when UML should be used. There are situations where UML for one developer could sense as well, such as Pattern Application or Code Generation.

---

UML has worked for me for years. When I started out I read Fowler's UML Distilled where he says "do enough modelling/architecture/etc.". Just use what you need!

---

From a QA Engineer's perspective, UML diagrams point out potential flaws in logic and thought. Makes my job easier :)

---

I think the UML is useful thought I think the 2.0 spec has made what was once a clear specification somewhat bloated and cumbersome. I do agree with the edition of timing diagrams etc since they filled a void...

Learning to use the UML effectively takes a bit of practice. The most important point is to communicate clearly, model when needed and model as a team. Whiteboards are the best tool that I've found. I have not seen any "digital whiteboard software" that has managed to capture the utility of an actual whiteboard.

That being said I do like the following UML tools:

1. Violet - If it were any more simple it would be a piece of paper

2. Altova UModel - Good tool for Java and C# Modeling

3. MagicDraw - My favorite commercial tool for Modeling

4. Poseidon - Decent tool with good bang for the buck

5. StarUML - Best open source modeling tool

---

UML diagrams are useful for capturing and communicating requirements and ensuring that the system meets those requirements. They can be used iteratively and during various stages of planning, design, development, and testing.

From the topic: Using Models within the Development Process at http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

A model can help you visualize the world in which your system works, clarify users' needs, define the architecture of your system, analyze the code, and ensure that your code meets the requirements.

You might also want to read my response to the following post:

How to learn “good software design/architecture”? at https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

---

Though this discussion has long been inactive, I have a couple of -to my mind important- points to add.

Buggy code is one thing. Left to drift downstream, design mistakes can get very bloated and ugly indeed. UML, however, is self-validating. By that I mean that in allowing you to explore your models in multiple, mathematically closed and mutually-checking dimensions, it engenders robust design.

UML has another important aspect: it "talks" directly to our strongest capability, that of visualisation. Had, for example, ITIL V3 (at heart simple enough) been communicated in the form of UML diagrams, it could have been published on a few dozen A3 foldouts. Instead, it came out in several tomes of truly biblical proportions, spawning an entire industry, breathtaking costs and widespread catatonic shock.

---

I see sequence diagrams and activity diagrams used fairly often. I do a lot of work with "real-time" and embedded systems that interact with other systems, and sequence diagrams are very helpful in visualizing all the interactions.

I like to do use-case diagrams, but I haven't met too many people who think they are valuable.

I've often wondered whether Rational Rose is a good example of the kinds of applications you get from UML-model-based design. It's bloated, buggy, slow, ugly, ...

---

I found UML not really useful for very small projects, but really suitable for larger ones.

Essentially, it does not really matter what you use, you just have to keep two things in mind:

• You want some sort of architecture planning
• You want to be sure that everyone in the team is actually using the same technology for project planning

So UML is just that: A standard on how you plan your projects. If you hire new people, there are more likely to know any existing standard - be it UML, Flowchard, Nassi-Schneiderman, whatever - rather than your exising in-house stuff.

Using UML for a single developer and/or a simple software project seems overkill to me, but when working in a larger team, I would definitely want some standard for planning software.

---

UML is useful, yes indeed! The main uses I've made of it were:

• Brainstorming about the ways a piece of software should work. It makes easy to communicate what you are thinking.
• Documenting the architecture of a system, it's patterns and the main relationships of its classes. It helps when someone enters your team, when you're leaving and want to make sure your successor will understand it, and when you eventually forget what the hell that little class was meant for.
• Documenting any architectural pattern you use on all your systems, for the same reasons of the dot above

I only disagree with Michael when he says that using UML for a single developer and/or a simple software project seems overkill to him. I've used it on my small personal projects, and having them documented using UML saved me a lot of time when I came back to them seven months later and had completely forgotten how I had built and put together all those classes.

---

I believe there may be a way to utilize Cockburn style UML fish,kite, and sea-level use cases as described by Fowler in his book "UML Distilled." My idea was to employ Cockburn use cases as an aid for code readability.

So I did an experiment and there is a post here about it with the Tag "UML" or "FOWLER." It was a simple idea for c#. Find a way to embed Cockburn use cases into the namespaces of programming constructs (such as the class and inner class namespaces or by making use of the namespaces for enumerations). I believe this could be a viable and simple technique but still have questions and need others to check it out. It could be good for simple programs that need a kind of pseudo-Domain Specific Language which can exist right in the midst of the c# code without any language extensions.

Please check out the post if you are interested. Go here.

---

One of the problems I have with UML is the understandability of the specification. When I try to really understand the semantics of a particular diagram I quickly get lost in the maze of meta-models and meta-meta-models. One of the selling points of UML is that it is less ambiguous than natural language. However, if two, or more, engineers interpret a diagram differently, it fails at the goal.

Also, I've tried asking specific questions about the super-structure document on several UML forums, and to members of the OMG itself, with little or no results. I don't think the UML community is mature enough yet to support itself.

---

Coming from a student, I find that UML has very little use. I find it ironic that PROGAMERS have yet to develop a program that will automatically generate the things that you have said are necessary. It would be extremely simple to design a feature into Visual Studio that could pull pieces of the data, seek for definitions, and product answers sufficent so that anyone could look at it, great or small, and understand the program. This would also keep it up to date because it would take the information directly from the code to produce the information.

---

UML is used as soon as you represent a class with its fields and methods though it's just a kind of UML diagram.

The problem with UML is that the founders book is too vague.

UML is just a language, it's not really a method.

As for me, I really find annoying the lack of UML schema for Opensource Projects. Take something like Wordpress, you just have a database schema, nothing else. You have to wander around the codex api to try to get the big picture.

---

UML has its place. It becomes increasingly important as the size of the project grows. If you have a long running project, then it is best to document everything in UML.

---

UML seems to good for large projects with large teams of people. However I've worked in small teams where communication is better.

Using UML-esque diagrams is good though, especially in the planning stage. I tend to think in code, so I find writing large specs hard. I prefer to write down the inputs' and outputs' and leave the developers to design the bit in the middle.

---

I believe UML is useful just for the fact that it gets people to think about the relationships between their classes. It is a good starting point to start thinking about such relationships, but it is definitely not a solution for everybody.

My belief is that the use of UML is subjective to the situation in which the development team is working.

---

In my experience:

The ability to create and communicate meaningful code diagrams is a necessary skill for any software engineer who is developing new code, or attempting to understand existing code.

Knowing the specifics of UML - when to use a dashed line, or a circle endpoint - is not quite as necessary, but is still good to have.

---

UML is useful in two ways:

• Technical side: a lot of people (manager and some functional analyst) think that UML is a luxury feature because The code is the documentation: you start coding, after you debug and fix. The sync of UML diagrams with code and analisys force you to understand well the requests of the customer;

• Management side: the UMl diagrams are a mirror of the requires of the customer who is inaccurate: if you code without UML, maybe you can find a bug in requires after a lot of hours of work. The diagrams UML allow you to find the possible controversal points and to resolve before the coding =>help your planning.

Generally, all the projects without UML diagrams have a superficial analysis or they have short size.

if you're in linkedin group SYSTEMS ENGINEERS, see my old discussion.

---

In the end UML only exist because of RUP. Do we need UML or any of its related stuff to use Java/.Net ? The practical answer is they have their own documenation (javadoc etc) which is sufficient and lets us get our job done!

UML no thanx.

---

UML is definitely helpful just as junit is essential. It all depends how you sell the idea. Your program will work without UML just as it would work without unit tests. Having said that, you should create do UML as along it is connected to your code, i.e when you update UML diagrams it updates your code, or when you update your code it auto generates the UML. Don't do just for the sake of doing it.

---

UML definetly has its place in the industry. Imagine you are building software for Boing aircraft or some other complex system. UML and RUP would be great help here.

---

UML is just one of methods for communication within people. Whiteboard is better.

참고URL : https://stackoverflow.com/questions/18803/is-uml-practical