코드 구성 방식을 계획하기 위해 UML 다이어그램을 사용하는 것이 부적절한 이유는 무엇입니까?

따라서 다이어그램은 때때로 부적절 할 수 있습니다. 언제 부적절한가요? 코드없이 코드를 작성하여 유효성을 검증 한 후 따르려고합니다. 아이디어를 탐색하기 위해 다이어그램을 그리는 데 아무런 문제가 없습니다.

_{민첩한 소프트웨어 개발 : 원칙, 패턴 및 실습 -Robert C. Martin}

그가 정확히 무엇을 의미합니까? UML은 "다이빙" 하기 전에 코드를 구성하는 방법을 계획하도록 설계되지 않았 습니까? 당신이 생각 해낸 다이어그램을 따르지 않으면 그것을 사용하는 요점은 무엇입니까?

맥락 :이 장에서, Uncle Bob은 Bowling 게임의 Score Keeper에 대한 UML 다이어그램을 작성합니다. 그런 다음 UML 다이어그램을 참조하지 않고 테스트 방식으로 프로그램을 개발합니다. 결과 프로그램은 UML 다이어그램과 다르며 Bob 삼촌은 위에서 인용 한 결론에 도달합니다.

— q126y
소스

밥 아저씨의 요점은 테스트 주도 개발에서 나온 아키텍처가 UML 다이어그램과 근본적으로 다를 수 있다는 것입니다.

— Robert Harvey

또한 디자인이 죽었습니까? 이 주제의 균형 잡힌 논의와 민첩한 운동 마틴 파울러

— 엘리의 Steinbock

@RobertHarvey 등의 잘못된 판단에 따라이 질문을지지하는 것은 중요하고 유용한 질문이 무엇인지에 대한 투표에서 투표합니다.

— David Arno

@DavidArno 폐쇄해야 할 것과 닫히지 않아야 할 것에 대한 강한 의견이 있으면 메타 사이트에 대한 토론에 참여하는 것이 좋습니다. 현재 저 (나를 포함하여)에 게시 한 모든 사람은 일부 SE 직원을 제외하고 "@RobertHarvey et al"에 속할 수 있으며, 다른 견해가 대표되지 않는 것에 대해 우려하고 있지만, 지금까지이를 대표하는 사람은 아무도 없습니다. .

— Ixrec

@Ixrec, 나는 이전에 메타 토론에 참여한 적이 없었습니다. 한 번의 답변으로 자신의 오픈 소스 라이브러리를 참조 할 수 있는지 확인했습니다 (그 대답은 가능했습니다). 어쩌면 나는 당신의 조언을 받아 더 참여해야합니다. 제안 해 주셔서 감사합니다.

— David Arno

답변:

이를 올바르게 설명하려면 짧은 역사 수업이 필요합니다. 소프트웨어 엔지니어링 초기에는 자주 사용되는 비유가 집을 짓고있었습니다. 건축가 및 구조 엔지니어는 고객과 계획을 논의하고 디자인을 제안합니다. 그런 다음 건축업자는 그 설계에 따라 실제 주택을 건축합니다. 코드 작성은 실제 집을 짓는 것과 동등한 것으로 여겨졌습니다. 따라서, 그 빌드가 이루어지기 전에 선행 디자인이 필요하다는 인식이있었습니다. UML을 사용하여 다양한 그래픽 디자인 도구를 만들었습니다.

원래 UML의 아이디어는 UML을 사용하여 시스템을 완전히 디자인 한 다음 해당 디자인을 코드로 변환하기 위해 코더에게 넘겨주는 것입니다. 실제로 이것은 작동하지 않으며 수년간의 프로그래머가 "디자이너"가 아닌 "구현 자"로 보였고, 프로젝트가 늦었고, 디자인이 완료된 후에 끊임없이 디자인을 변경해야했습니다.

이유는 간단합니다. 코딩은 디자인 입니다. 집의 비유와 함께, 코드는 건축가의 도면입니다. 컴파일러는 해당 디자인을 가져 와서 프로그램을 작성하는 빌더입니다. 이 실현으로 민첩한 기술, TDD 등이 탄생했습니다. 코드 디자인의 품질을 향상시키는 데 도움이되는 도구입니다.

건축가가 전체 스케치를 시각화하는 데 도움이되는 예비 스케치를 생성하는 것처럼 개발자는 UML 또는 기타 도구를 사용하여 필요한 디자인을 시각화 할 수 있습니다. 이러한 스케치를 맹목적으로 따르지 않는 것처럼 UML도 맹목적으로 따르지 않아야합니다. 코드 디자인은 민첩한 반복에서 벗어나 TDD를 사용하여 발전해야합니다. 마찬가지로 건축가가 집 모델을 만들어서 그림을 시각화하는 데 도움이되는 것처럼 UML을 사용하여 코드 구조를 시각화 할 수 있습니다.

Bob 아저씨가 말했듯이 UML의 유효성을 검사 할 수 없으며 코드의 유효성 만 검사 할 수 있습니다. 따라서이 코드는 주요 설계 문서이며 UML (사용되는 경우)은 보조 문서입니다.

— 데이비드 아르노
소스

나는 올해 초 내 집의 지붕 부분을 들었고 꽤 교육적이었습니다. 아키텍트는 더 이상 최종 제품이 어떤 모습 일지 생각하지 않았습니다. 그는 어려운 계산과 구조 설계를 건축 엔지니어에게 건네 주었다. 그런 다음 건축업자들은 이론적 설계를 집의 실제와 일치시켜야했습니다 (한 번 석고 보드가 꺼지고 빔이 약간 다른 위치에 있음). 따라서 모든 단계에서 설계가 진행되었습니다.

— Jaydee

이것은 유용한 답변이지만 그럼에도 불구하고 일부 측면을 지나치게 단순화합니다. UML이 "높은 수준의 디자인 표기법"으로 잘 작동하지 않는 주된 이유 중 하나는 IMHO가 발명가들이 데이터 흐름 다이어그램을 추가하기에 너무 고집 스러웠 기 때문입니다. 그것은 내가 도시 디자인에 적합한 유일한 종류의 표기법으로, 컴포넌트와 인터페이스 사이의 추상화를 다른 규모로 표현할 수 있으며 코드에 잘 정의 된 매핑을 가질 수도 있습니다. 대신 UML에는 실제로 필요한 사람이 많지 않습니다.

— Doc Brown

나는 모든 프로그래밍 관용구 (또는 디자인 또는 코드)가 UML에 맞는 것은 아니라고 생각합니다 (이것은 잘 알지 못한다는 것을 인정합니다. 몇 권의 책을 읽지 만 결코 사용하지 않았으며 아마도 싫어할 것입니다).

일반 C 코드 (예 : Linux 커널의 소스 코드)는 UML에 의해 정확하게 모델링 되지 않을 수 있습니다 .

Ocaml 코드 (모듈 및 펑터 포함) 또는 C ++ 11 코드 (람다 및 템플릿 포함)는 UML에 맞지 않을 수 있습니다.

MetaOcaml과 같은 다단계 프로그래밍은 아마도 UML에 맞지 않을 것입니다.

프롤로그 코드 또는 공통 Lisp 코드가 UML에 맞지 않을 수 있습니다.

참조 이 대답 & 이 내 질문을.

Scott의 Programming Language Pragmatics 와 Van Roy의 Concepts, Techniques and Models of Computer Programming 책을 읽고 모든 프로그래밍 모델이 UML에 적합한 지 자문 해보십시오.

마틴 파울러의 디자인이 죽었나? 블로그.

— 바 실레 스타 인케 비치
소스