어떤 UML 다이어그램이 여전히 널리 사용되고 있습니까? [닫은]

학부 수준에서 소프트웨어 엔지니어링을 가르치고 UML 전문가에게 질문이 있습니다.

대부분의 소프트웨어 엔지니어링 교과서는 UML 다이어그램을 다루는 데 많은 노력을 기울입니다. 그러나 다른 졸업생들로부터 UML이 더 이상 참호에 사용되지 않는 것 같습니다.

어떤 UML 다이어그램이 여전히 전문적인 실무에서 널리 사용되고 있습니까? 더 이상 사용되지 않는 다이어그램이 있습니까? 왜 그렇습니까?

주의 : 의견에 근거한 토론과 토론을 피하려면 사실적이고 객관적인 요소 (가능한 경우, 검증 가능) 또는 개인적인 경험에 대한 중립적 관찰로 답변을 설명하십시오.

UML이 제안한 많은 다이어그램에서 클래스 다이어그램과 시퀀스 다이어그램이 여전히 널리 사용되며 그 다음에 상태 다이어그램이 이어집니다.

• 그들은 화이트 보드에서 쉽게 사용되어 코드를 뛰어 넘기 전에 디자인을 정교하게 논의 할 수 있습니다.
• 코드만으로는 쉽게 제공 할 수없는 개요를 매우 빠르게 전달할 수 있으며, 대체 할만한 대안이 없습니다.

실생활에서의 유스 케이스는 더 가끔 사용되는 것 같습니다. 수백 개의 사용 사례가있는 대규모 프로젝트에서는 다이어그램을 그리는 것이 고통스럽고 테이블 형식에 비해 이점이 거의 없습니다. Cockburn 스타일의 프로세스 디자인, 사용자 스토리 매핑 또는 이벤트 테이블 형식 분해를 위한 BPMN 이 훨씬 더 많이 사용됩니다. 왜 ? 비즈니스 사용자와보다 쉽게 ​​공유되므로 요구 사항을 효율적으로 해결할 수 있습니다.

UML이 여전히 많이 사용되고 체계적으로 사용되는 곳이라고 확신합니다. 항공 우주 소프트웨어 또는 원자력 발전소 제어 시스템이 UML 문서의 전체 세트없이 생산 된다고는 생각하지 않습니다 . 그러나 나는 그것이 규칙보다 더 예외라고 생각합니다.

서점을 볼 때이 진술에서 확인 된 느낌입니다. 2 년 전에 UML 2.0에 관한 많은 책을 찾을 수있었습니다. 요즘 UML 2.5를 찾고 있다면 선택이 다소 제한적입니다. 더 나쁜 것은 : 많은 저자들이 이전 책을 최신 상태로 유지하기 위해 노력하지도 않습니다 (예 : Fowler의 멋진 " UML distilled "소개는 2003 년부터 UML 2.0으로 시작되었으며 Ambler 's 요소 와 동일합니다. UML 2.0 스타일의 "!).

민첩성 의 일반화 와 "포괄적 인 문서에 대한 소프트웨어 작업"에 대한 홍보를 살펴보면서 이러한 감소 추세가 바뀌지 않을 것이라고 생각합니다 .

결국, 나는 모델링 방법이 다윈 적 체계를 따르는 것처럼 보인다고 매우 도발적으로 주장한다 : 가장 적합한 다이어그램 기법 만이 살아남을 것이다. 비공식적 인 접근 방식 (예 : 냅킨 그림)과 상세한 코드 (예 : 해당 코드가 A4 시트에 맞는 경우 A1 활동 다이어그램을 그리는 이유는 무엇입니까?) ;-)

다른 한편으로, 나는 많은 졸업생들로부터 UML이 더 이상 참호에 사용되지 않는 것 같다고 들었다.

그들은 모두 실제로 사용됩니다. 그러나 모든 사람이 사용하지는 않습니다. 어떤 사람들은 디자인을 완전히 피하고 코딩으로 바로 뛰어 들어갑니다. "모두"가 무엇을하는지 알기 위해 일화적인 증거에 의존 할 수는 없습니다.

UML과 같은 도구는 가치를 추가 할 때 가장 잘 작동 합니다 . 예 :

• 대규모 프로젝트
• 프로젝트의 복잡한 부분
• 프로젝트 디자인에 여러 사람의 입력이 필요한 경우

그렇게하기 위해 (또는 프로세스가 반드시 필요하다고 말했기 때문에) 만드는 것은 생산적이지 않습니다. 모범 사례는 다이어그램과 사용하는 종류를 선택하는 것입니다. 도움이되는시기와 장소에서 UML을 사용하십시오. 여기에는 사용하는 UML 다이어그램 종류를 선택하는 것이 포함됩니다.

또한 UML은 주로 설계 도구로 설계되었습니다. 문서화 도구로는 그다지 효과적이지 않습니다 (현재). 일반적인 IDE는 코드 기반 구조가 즉시 작동하는 경우 여러 측면을 시각화하는 데 도움이됩니다. 오래되었거나 부정확 한 UML 다이어그램을 사용하는 것보다이 방법이 더 좋습니다.

UML은 여전히 ​​참호에 사용됩니다. 그러나 항상 그렇듯이 사람들은 하위 집합을 사용합니다. 어떤 부분 집합이 현재 문제의 대상입니다.

UML은 여러 버전으로 제공됩니다. 그러나 항상 그렇듯이 사람들은이 기호를 비공식적이고 일관되게 사용합니다.

UML은 우리가 많은 패턴 책을 이해하는 방법입니다. 또한 우리가 화이트 보드에서 의사 소통하는 방법 중 하나입니다. 사라지지 않았습니다. 그러나 코드처럼 공식적으로 사용되지는 않습니다.

UML 버전 2.5 를 준수하도록 UML 다이어그램을 수정할 수있는 학생을 생성하는 대신 또는 최신 버전을 생성하는 대신 특정 UML 버전과 완전히 일치하지 않더라도 다이어그램이 통신하려는 내용을 이해할 수있는 학생을 생성하십시오. 참호에서 UML이 사용되는 방식 그것은 이상한 지역 방언으로, 다른 시스템과 혼합되어 있으며 때로는 자체 기호를 구성하기도합니다.

의미가 무엇인지 물어 보는 것이 좋다고 가르치십시오. 상상의 규칙을 어 기고있는 다른 사람들을 바로 잡으라고 가르치지 마십시오. 우리는 여기서 의사 소통을하려고합니다.

내가 uml에 넣은 것을 가장 잘 사용하는 것은 새로운 프로그래머가 문제 해결 계획을 보여 주도록하는 것입니다. 그것은 그들이 우리가 무시했거나 깨닫지 못했던 시스템의 일부를 신속하게 보여주었습니다.

또한 필요하지 않은 경우에도 UML이 필요한 장소를 작업했습니다. 우리는 항상 같은 패턴을 사용했기 때문에 형식이었습니다. 우리는 방금 새로운 이름을 오래된 다이어그램으로 사진을 찍었다는 점에 도달했습니다. 이런 종류의 사용을 장려하지 마십시오.

그러나 나는 우리 모두 정상 화살촉과 열린 화살촉 사이에 차이가 있다는 것을 알고 있다고 생각합니다. 권리?

내 경험에 따라 구체적으로 설명하겠습니다.-배포 다이어그램-시퀀스 다이어그램-클래스 다이어그램이 세 가지는 모든 프로젝트에서 가장 많이 사용되며 다른 수준의 팀과 실질적인 의사 소통 가치를 제공합니다.