UML이 대부분의 무료 소프트웨어 (예 : Linux)에서 사용되지 않는 이유는 무엇입니까?

UML 이 대부분의 무료 소프트웨어 프로젝트 에서 사용되지 않는 이유 를 이해하려고합니다 . 예를 들어, 데비안 / 리눅스 시스템에는 10 만 개가 넘는 무료 소프트웨어 패키지가있을 수 있으며, 명시적인 UML 프레임 워크와 방법론을 사용하여 개발 된 것조차 말할 수 없습니다 . 예를 들어 Qt , GCC , Linux 커널 , bash , GNU make , Ocaml , Gnome , Unison , lighttpd , libonion , docker 는 (AFAIK) UML을 전혀 언급하지 않는 자유 소프트웨어 프로젝트입니다.

^{(제 생각에는 UML은 개발 작업의 공식 하청 계약에 매우 적합하며 자유 소프트웨어가 개발되는 방식 이 아닙니다 )}

UML에 대한 자료를 읽었지만 그 내용을 잘 이해하고 있다고 주장하지는 않습니다.

실제로 UML이 사용 된 무료 소프트웨어의 이름을 쉽게 지정할 수 없습니다 (무료 소프트웨어로 구현 된 일부 UML 도구 제외). 아마도 openstack 은 예외입니다 (UML에 대한 언급이 있습니다).

^{(오래된 무료 소프트웨어 프로젝트조차 시작된 후에 UML을 채택했을 수도 있지만 그렇지 않은 경우)}

파피루스에서 일하는 일부 동료들은 대부분의 자유 소프트웨어 프로젝트가 처음에는 명시적이고 (충분히) 공식화 된 모델을 가지고 있지 않다고 언급했다. 또한 UML은 주장하는 것보다 Java와 훨씬 더 관련이 있습니다 (Ocaml 또는 Common Lisp 또는 Haskell 또는 Javascript에는 적합하지 않으며 C ++ 11에는 적합하지 않을 수도 있습니다.) 아마도 애자일 소프트웨어 개발은 매우 UML 친절하지 않다.

어떻게 든 관련 질문에 대한 이 답변을 참조하십시오 . M.Fowler의 블로그 는 디자인이 죽었습니까? 통찰력이 있습니다.

^{추신. 나는 그것이 주로 의견의 문제라고 생각하지 않습니다. 그 이유를 설명하는 객관적인 이유와 자유 소프트웨어의 필수 특성이 있어야합니다. UML은 공식 하청 계약에만 유용하며 독점 프로젝트에서와 같이 개발 된 소프트웨어의 일부가 숨겨져있는 경우에만 유용합니다. 이 경우 UML은 무료 소프트웨어 개발과 호환되지 않습니다 .}

^{NB : 저는 UML 팬이 아닙니다. UML을 종이 문서로만 정의하지 않고 소프트웨어 도구 의 [데이터] 데이터 형식으로도 정의 합니다.}

UML을 사용하는 방법에는 여러 가지가 있습니다. Martin Fowler는 이러한 UML 모드를 호출 하고 UML을 Notes로 , UML을 스케치로 , UML을 블루 프린트로 , UML을 프로그래밍 언어로 식별 합니다.

프로그래밍 언어로서의 UML은 실제로 이륙하지 못했습니다. 이 영역에서 Model Driven Architecture 또는 Model Based Software Engineering 과 같은 다른 이름으로 일부 작업이 수행되었습니다 . 이 방법에서는 소프트웨어 시스템의 매우 상세한 모델을 작성하고 해당 모델에서 코드를 생성합니다. 이 방법이 유용한 경우가 있지만 일반적인 소프트웨어에는 적합하지 않으며 특히이 방법을 지원하는 도구를 제공 할 수있는 대기업 외부에서는 그렇지 않을 수도 있습니다. 또한 시간이 많이 걸리는 프로세스입니다. 클래스를 구현하는 데 필요한 모든 그래픽 모델을 만드는 것보다 클래스의 코드를 더 빠르게 입력 할 수 있습니다.

블루 프린트로서의 UML은 종종 "큰 디자인 초기" 프로젝트를 나타냅니다. 물론 그럴 필요는 없습니다. 특정 증분에 대해서도 모델을 완벽하게 설명 할 수 있습니다. 그러나 아이디어는 UML 모델 형식으로 디자인을 작성하고 코드로 변환하기 위해 누군가에게 전달하는 데 시간이 걸린다는 것입니다. 모든 세부 사항을 설명하고 코드로 변환하는 것이 더 기계적인 경향이 있습니다.

스케치로서의 UML과 노트로서의 ​​UML은 본질적으로 유사하지만 언제 사용되는지에 따라 다릅니다. 스케치로 UML을 사용한다는 것은 UML 표기법을 사용하여 디자인을 스케치한다는 것을 의미하지만 다이어그램은 완전하지는 않지만 다른 디자인과 통신해야하는 디자인의 특정 측면에 초점을 맞출 것입니다. Notes와 같은 UML은 비슷하지만 모델은 코드 기반을 이해하는 데 도움이되도록 코드 다음에 작성됩니다.

이것을 고려할 때 위의 모든 것이 모든 종류의 모델링 표기법에 해당한다고 생각합니다. 엔티티 관계 다이어그램, IDEF 다이어그램, 비즈니스 프로세스 모델링 표기법 등에 적용 할 수 있습니다 . 모델링 표기법에 관계없이 적용 시점 (사양 이전, 대체 표현 후) 및 세부 사항 (핵심 측면에 대한 전체 세부 사항)을 선택할 수 있습니다.

이것의 다른 측면은 오픈 소스 문화입니다.

종종 오픈 소스 프로젝트는 개인 (또는 오늘날 회사)이 겪고있는 문제를 해결하기 위해 시작됩니다. 개인이 시작한 경우 개발자 수는 1 명입니다.이 경우 통신 오버 헤드가 매우 적으며 요구 사항과 디자인에 대해 통신 할 필요가 없습니다. 회사에서는 소규모 팀이있을 수 있습니다. 이 경우 설계 가능성을 알리고 절충에 대해 논의해야 할 것입니다. 그러나 설계 결정을 한 후에는 시간이 지남에 따라 코드 기반이 변경 될 때 모델을 유지 관리하거나 버려야합니다. 에서 애자일 모델링 용어, "문서는 계속해서" 와 유지 "단일 정보 소스를" .

간단히 말해서, 코드는 디자인이고 모델은 디자인의 대체보기라는 아이디어가 있습니다. Jack Reeves는 코드 디자인에 대한 세 가지 에세이를 작성했으며 C2 위키에도 소스 코드가 디자인 , 디자인이 소스 코드 , 소스 코드 및 모델링 이라는 아이디어에 대한 토론이 있습니다. 이 신념에 동의하면 (내가하는) 소스 코드는 현실이며 코드를 이해하기 위해 다이어그램이 존재해야하며, 더 중요한 것은 코드가 왜인지에 대한 이론적 근거입니다.

언급 한 것과 같이 성공적인 오픈 소스 프로젝트에는 전 세계에 기여자가 있습니다. 이 기고자들은 기술적으로 소프트웨어를 구동하는 기술에 능숙하며 소프트웨어 사용자이기도합니다. 기고자는 모델처럼 쉽게 소스 코드를 읽을 수 있고 도구 (IDE 및 리버스 엔지니어링 도구)를 사용하여 코드를 이해 (필요한 경우 모델 생성 포함) 할 수 있습니다. 또한 흐름을 직접 스케치 할 수도 있습니다.

Fowler가 설명하는 네 가지 모드 중에서, 모델링 언어를 프로그래밍 언어 또는 청사진으로 사용하는 오픈 소스 프로젝트 나 어디에서나 많은 프로젝트를 찾을 수 없다고 생각합니다. UML에 대한 가능한 용도로 메모와 스케치를 남깁니다. 기고자에 의해 기고자에 의해 메모가 작성되므로, 어느 곳에도 업로드 된 메모를 찾지 못할 것입니다. 코드의 완성도가 높아지면서 스케치의 가치가 떨어지고 기고자들의 노력만으로도 유지 관리되지 않을 수 있습니다.

많은 오픈 소스 프로젝트에는 가치를 추가하지 않기 때문에 사용 가능한 모델이 없습니다. 그러나 이것이 프로젝트 초기에 누군가가 모델을 만들지 않았거나 개인이 자신의 시스템 모델을 만들지 않았다는 의미는 아닙니다. 한 가지 디자인 정보 소스 인 소스 코드를 유지 관리하는 것이 훨씬 더 효과적입니다.

디자인 정보를 교환하는 사람들을 찾으려면 기고자가 사용하는 모든 종류의 포럼 또는 메일 목록을 보는 것이 좋습니다. 이러한 포럼 및 메일 링리스트는 종종 프로젝트의 디자인 문서 역할을합니다. 공식적인 UML을 찾을 수는 없지만 디자인 정보와 모델을 그래픽으로 표현할 수 있습니다. 프로젝트를위한 대화방이나 다른 커뮤니케이션 채널을 볼 수도 있습니다. 사람들이 디자인 결정에 대해 이야기하는 것을 보게되면 그래픽 모델과 통신 할 수 있습니다. 그러나 그들은 커뮤니케이션의 목적을 달성 한 후에는 가치가 없기 때문에 저장소의 일부가되지 않을 것입니다.

리눅스를 예로 들어 보자.

• VFS와 같은 일부 부분은 UML에서 모델링 될 수 있지만 다른 부분은 효과적이지 않을 수도 있습니다. 즉 기본적으로 struct관계가없는 클래스 다이어그램으로 직접 변환 하는 것입니다.
• UML은 문서를 작성하는 데 유용하며 프로젝트에 익숙하지 않은 사용자도 얻을 수 있습니다. 그것은 실제로 리눅스가 제공하는 것이 아니며 사람들은 스스로 그것을 배우게 될 것으로 기대됩니다.
• 어떤 UML 도구를 사용해야하는지 잘 모르는 경우 유지 관리하려는 경우 무언가에 동의해야합니다. 무료 Java 응용 프로그램이 있었지만 많은 사람들이 그것을 사용하고 싶지는 않습니다.
• 90 년대의 GUI는 여전히 리눅스에 대한 도전이었습니다. 메일 링리스트 아카이브를 파고 가십시오. 부팅 시간에 xpm 형식의 Linux 자체 로고 이외의 그래픽은 찾지 못할 것입니다. 일반 텍스트가 선호되는 형식입니다.
• 나는 아무도 디자인에 관심이 없다고 생각하지 않습니다. 사람들은 기능에 관심을 갖고 받아 들여지면 코드를 면밀히 조사하게됩니다. POSIX 및 SUS와 같은 표준이 작성되는 방식과 마찬가지로 사용 사례는 여전히 단어로 가장 잘 설명됩니다.
• 운영 체제 영역의 많은 개체가 커뮤니티 내에서 잘 이해되고 표준화되었습니다. 예를 들어 사람들은 struct in_addr메모리에서 어떻게 생겼는지 알 것 입니다.
• UML은 메모리 할당 자, 스케줄러, 인터럽트 핸들러 등과 같은 모델링 알고리즘에 큰 도움이되지 않습니다. 소스는 이해하기 쉬울 것입니다.

이것들은 Linux 프로젝트 설정에서 생각할 수있는 것들입니다. 실용성에 관한 것 같아요. 흥미롭게도 Tanenbaum이 그의 OS 교과서 에서 Minix를 설명하는 데 UML을 사용한 것을 기억하지 못합니다 .

아마도 언급 할 가치가 있지만 직장에서도 UML을 사용하지 않습니다. 아마도 20 %의 사람들이 UML의 일부를 알고 있습니다.

UML은 표현의 형태이므로 언어의 한 형태이며, 논증을 위해 정신 모델을 한 사람에서 다른 사람으로 전달하는 것이라고 가정 해 봅시다.

언어에서 내가 찾는 것은 자신의 정신 모델에 대한 변화를 포착하는 효율성입니다. 자신의 모델에 대한 설명을 작성한 후에 약간의 변경이 필요하다고 가정 해 봅시다. 표현을 얼마나 크게 바꿔야합니까? 텍스트 언어에서 측정 방법은 diff전후 코드 를 실행 하고 차이를 계산하는 것입니다. 그래픽 언어에서는 차이를 측정하는 비슷한 방법이 있어야합니다.

IMHO, 나는 위의 측정을 최소화 할 정도로 언어를 "DSL (Domain Specific)"이라고 부릅니다. 이는 유지 보수 비용과 버그를 줄이는 데 명백한 이점이 있습니다. DSL을 만드는 방법? 몇 가지 방법이 있습니다. 가장 간단한 방법 중 하나는 기존 프로그래밍 언어로 데이터 구조와 메소드를 정의하는 것입니다. 이렇게하면 명사와 동사가 기본 언어에 추가되어 원하는 것을 더 쉽게 말할 수 있습니다. (참고 : 학습 곡선이없는 DSL을 찾지는 않습니다. DSL을 읽는 독자는 일회성 학습 비용을 투자해야 할 수도 있습니다.)

중요한 점은 모든 경우에 DSL은 자신의 모델을 표현하는 용어와 모델을 편리하게 변경하는 용어를 포함해야합니다. 가능한 도메인 범위에는 분명한 제한이 없으므로 단일 DSL이 모든 도메인에 서비스를 제공 할 수는 없습니다.

UML에 대한 나의 인상은 그것이 시도한 것입니다.