성공적인 프로젝트를 위해 UML 다이어그램이 얼마나 중요합니까? [닫은]

프로젝트 중간에 UML 다이어그램 (사용 사례, 클래스 다이어그램 등)을 작성하라는 요청을 받았습니다. 이 프로젝트는 그리 복잡하지 않습니다.

이것이 나의 시간 낭비인지 궁금합니다. 코드 작성과 같은 다른 재미있는 일을해야합니까? 그리고 모든 개념적 단계를 거치지 않고 무언가를 만드는 것이 언제 좋지 않은가? 복잡성에 관한 것입니까? 그렇다면 어떻게 측정합니까?

나는 얼마 전에 UML을 좋아했습니다. 나는 심지어 OMG 인증을 받았습니다. 내가 참여한 대기업 프로젝트에서 광범위하게 사용했습니다.

오늘은 UML을 거의 완전히 중단했습니다. 때로는 시스템 간의 상호 작용을 설명하는 데 매우 유용한 시퀀스 다이어그램을 사용하지만 다른 다이어그램은 사용하지 않습니다.

필자는 이제 제품 소유자 (또는 분석가)가 작성한 필수 문서와 개발 팀에 대한 그의 헌신 (필요한 경우)을 모두 지원하여 사용자 스토리를 다루는 것을 선호합니다.

UML은 사용할 수있는 도구이지만 프로젝트 성공에 중요한 요소는 아닙니다. 몇 년 후, 이제는 어떤 도구를 사용하든 중요한 요소가 개발 팀이라고 생각합니다.

계획은 중요하지만 유명한 전략가 인 Carl von Clausewitz 는 경고합니다.

적과 처음 접촉 한 후에도 캠페인 계획이 없습니다

따라서 문제를 처음에 공격하는 방법을 계획하는 데 많은 시간을 낭비하지 않습니다. 그러나 미래의 프로그래머를 위해 코드를 문서화하는 데 시간이 낭비 될 수 있습니다. 군사 은유를 사용하려면 전투 계획이 필요하지만 사후 조치 보고서로 사용할 계획을 역사가에게 제공하지는 않습니다.

보다 구체적으로,이 다이어그램을 사용하여 팀간에 의도를 알리고 프로젝트 전후에 공격 계획을 생각할 수 있습니다. 그러나 코드를 작성하고 문제에 대해 더 많이 배우면 문제를 해결해야 할 가능성이 있습니다. 모든 것을 미리 알 수 없기 때문에 거의 항상 초기 계획 / 디자인을 변경해야합니다.

UML 다이어그램은 코드보다 더 높은 추상화 수준으로 무언가를 표현하는 경우에만 유용 할 수 있다고 생각 합니다 .

UML을 작성하기위한 목적으로 UML을 작성하면 관료주의가 불필요 해져 프로젝트와 코드가 변경 사항에 덜 적응하지 않아도됩니다.

예를 들어, 패키지의 모든 클래스와 모든 속성 및 메소드 (쉽게 자동 생성 할 수있는 것)를 표시하는 UML 클래스 다이어그램은 전혀 가치를 제공하지 않습니다. 코드와 동일한 추상화 레벨에 있습니다. . 또한 코드는 항상 최신 정보이므로 해당 정보에 대한 더 나은 소스가 될 것이며, 어떤 방법 / 속성 / 사물이 더 중요한지 더 쉽게 알 수있는 방식으로 문서화되고 구성 될 것입니다.

반면에 코드에 표현할 수있는 것보다 더 높은 추상화 수준의 개념이 있다면 다이어그램에 개념을 문서화하는 것이 좋습니다.

예를 들어, 복잡한 시스템에서 상위 레벨 추상 모듈을 보여주는 다이어그램 (종속성 및 책임에 대한 약간의 설명 및 소스 코드에서 매핑 된 패키지 / 네임 스페이스)은 새로운 팀 구성원에게 실제로 유용 할 수 있습니다. 프로젝트에 도입해야하거나 새로운 클래스 / 기능을 어디에 던져야하는지 파악하는 데 사용될 수도 있습니다.

유용한 다이어그램의 다른 예는 통신 프로토콜에서 취해지는 상위 단계를 보여주는 시퀀스 다이어그램 일 수 있습니다. 어쩌면 그것들의 각 단계에는 약간의 단점과 복잡성이 있지만 아마도 코드 자체로 설명하기에 충분할 것입니다. 높은 수준의 다이어그램은 프로그래머가 각 상호 작용의 복잡성에 대해 걱정할 필요없이 사물의 "큰 그림"을 쉽게 이해하도록 도와줍니다.

어쨌든, 그것들은 몇 가지 예일뿐입니다. 간단한 다이어그램이 많은 도움을 줄 수있는 경우가 많이 있습니다. 코드 자체에서 무언가를 표현할 수없는 경우에만 수행해야한다는 것을 기억하십시오. 소스 코드 자체를 설명하기 위해 UML 다이어그램을 사용하는 경우 소스 코드를보다 자체 문서화하십시오.

마지막으로, 코드에 적용되는 일반적인 규칙 중 일부는 다이어그램에도 적용될 수 있습니다. 반복하지 말고, 단순하게 유지하고, 변경 사항을 두려워하지 마십시오 (UML 다이어그램에 문서화되어 있다고해서 이것이 불가능하다는 의미는 아닙니다 변경 될 때) 항상 다이어그램을 작성할 때 누가 미래의 다이어그램을 읽거나 유지할 것인지 생각하십시오.

UML은 팀 구성원이이를 종합적으로 이해하고 설계 결정을 요약하고 전달하는 유용한 방법으로 간주하면 가치가 있습니다. 팀이 유용하다고 생각하는 부분 집합 만 모두 알 필요는 없습니다.

또한 완벽하고 세련된 다이어그램을 그릴 필요가 없습니다. 화이트 보드의 대략적인 시퀀스 다이어그램 또는 클래스가 포스트잇 메모가 해당 화이트 보드에 붙어있는 클래스 다이어그램은 상황에 따라 충분할 수 있습니다.

한때 해외 계약 개발자 팀을 관리해야하는 공연에 대해 작업했습니다.

그들이 생산 한 것들 중 일부는 꽤 끔찍했습니다 (원격 계약 코더의 일반적인 증상-실제로 코드를 많이 신경 쓰지 않고 빨리 끝내기를 원합니다).

프로젝트를 관리하기 위해 UML 다이어그램을 작성하여 코드로 전달하는 것을 발견했습니다. 그것은 매우 성공적이었습니다. Java보다 훨씬 빠르게 UML로 프로그램을 작성하는 데 오래 걸리지 않았으며 계약자가 따라하고 측정 할 수있는 것이 었습니다.

한 가지주의 사항-때로는 창의력을 발휘하고 내 모델에서 벗어나기를 원했지만 실제로는 정확했으며 모든 UML이 최종 제품의 품질을 향상 시켰습니다.

누군가가 UML 다이어그램을 준비하도록 요청했고 누군가가 급여를 지불하고 있다면 실제로 시간 낭비가 아닙니다. 그것은 누군가의 시간 낭비 일 수도 있고 아닐 수도 있습니다.

누군가 UML 다이어그램을 읽어 프로젝트를 이해하려는 경우 시간 낭비가 아닐 수 있습니다.

초기 디자인 단계에서 종이나 화이트 보드에 아이디어를 얻는 것이 유용하다는 것을 알게되었습니다. 나는 표준을 엄격히 준수하지 않고 주로 UML 클래스 다이어그램을 사용했습니다. 프로젝트가 끝날 때와 끝날 때 UML 독창적 인 디자인을 다시 방문하는 것이 좋습니다. 코드를 통해 읽을 수있는보다 높은 수준의 추상화에서 코드베이스를 살펴 보는 데 도움이되었으며 잠재적 인 버그를 발견하는 데 도움이되었습니다.

만든 좋은 점있다 여기 에서 ragu.pattabi UML 두 종류의 구별은 ...

UML 의 민첩한 풍미 (예 : 빠른 화이트 보드 스케치)는 UML 의 폭포 풍미 보다 더 성공적 이라고 생각합니다 (예 : 문서에 정통한 관리자가 만족할 수 있도록 문서, 코드 생성 등 모든 세부 사항이 포함 된 정교한 다이어그램).

UML이 '필수품'기술 (10 년 전) 이상으로 여겨졌을 때, 아마도 당시 많은 팬들의 의견에 따라 의견이 맞지 않았을 것입니다. 그러나 이제는 그것이 유리하지 않아서, 그것이 장점인지는 알지만 소프트웨어 개발의 은총 알은 아닙니다.

우리가 할 일에 대해 친구들과 이야기 할 때 UML (또는 UML과 비슷한 sth)을 사용합니다. 아이디어를 토론합니다. 나를 위해 코드를 자동 생성하는 UML 프로젝트를 준비하지 마십시오. UML에서 클래스를 만든 다음 코드를 생성하고 나중에 조정하지 않을 것이라고 상상할 수 없습니다. 이런 일은 절대 일어나지 않습니다. 따라서 코드에서 UML로 변경 사항을 가져와야합니다. 그리고 UML을 사용할 때 화이트 보드 나 종이에 그립니다. Enterprise Architect와 같은 도구에는 절대 사용하지 마십시오.

UML로 전체 코드를 문서화하는 유일한 이유는 고객이 요구하는 계약일 것입니다. 예를 들어, 소프트웨어의 일부가 완료된 후 소프트웨어 샵을 변경할 수있는 옵션을 원할 때.

프로젝트 작업 문서는 전문 프로젝트의 기본 결과물입니다. 얼마입니까? 물론 그것은 많은 요소에 달려 있습니다. 그러나 제 생각에는 유스 케이스, 클래스 다이어그램, 프로세스 흐름도 등이 전혀 시간 낭비가 아닙니다. 다양한 프로젝트 단계에서 가치가 있습니다. 문서와 관련된 유일한 문제는 대개 리소스입니다.

일부 프로그래머는 문서화가 시간 낭비라고 생각합니다. 그러나 이것은 사실이 아닙니다. 우아하고 명확한 방식으로 문서를 디자인 및 시스템 규칙의 표시로 보는 경우 더 감사하게 생각할 수 있습니다. 또한 시스템을 유지해야하는 사람들의 입장에서 자기 자신을 배치해야합니다. 500 파일의 코드를 던져 문제를 해결하라는 요청은 다소 나쁘지만 드문 일이 아닙니다.

프로젝트에 시간을 할당하고 다이어그램을 주기적으로 생성하는 것이 좋습니다. 첫 번째는 프로젝트의 높은 수준의 측면을 다루고 후속 수준은 세부 사항에 대해 더 많이 알 수 있습니다.

특히 유스 케이스는 시스템의 다른 많은 측면과 달리 코드에서 쉽게 추론 할 수 없습니다. 그렇게해야합니다.

UML은 도구 일 뿐이며, 유용하거나 중요한지 여부는 개발 및 디자인 워크 플로우에만 달려 있습니다. 로마에는 여러 가지 방법이 있으며 그중 일부는 UML과 관련이 있지만 다른 하나는 UML과 관련이 없습니다.

워크 플로우가 UML을 사용하여 아키텍처를 문서화하거나 계획하는 경우,이를 삭제하는 것은 어리석은 일입니다. UML이 프로젝트 구조를 다른 팀 구성원들에게 (더 넓은 의미로) 전달할 수있는 가장 좋은 방법이라면 반드시 사용하십시오. 그러나 프로젝트가 UML없이 잘 작동한다면 UML 다이어그램을 만드는 것은 말도 안됩니다.

이것에 대해 몇 가지 생각이 있습니다. 언어를 사용하고 남용하고 강요하고 산만하게하고 방아쇠를 당길 수 있습니다. UML은 특정 문제 세트에 적합한 또 다른 언어이며 다른 언어와 마찬가지로 유창하게 말하고 올바르게 이해하는 법을 배우는 데 시간과 노력이 필요합니다.

의사 소통 대상에 대한 결정은 의사 소통하는 언어보다 엄청나게 중요합니다. UML은 나쁜 디자인을 마술처럼 이해할 수 없게 만들지 않습니다. 다른 언어와 마찬가지로 세부 사항을 잃어 버렸거나 상상력에 너무 많이 맡기는 것이 쉽습니다.

UML은 수많은 끔찍한 IDE 덕분에 나쁜 이름을 얻었으며 왕복 프로토 타입, 클릭 집약적 그래프 조작 및 변경이 어렵다. UML 2.0은 특정 학문을 만족시키기에 충분히 복잡 할 수 있지만 메타 모델은 많은 실제 응용 프로그램을 끌어 들이지 않는 것 같습니다.

아직도, 나는 때때로 UML을 사용합니다. 높은 수준의 디자인을 평가하려면 (좋은 디자인은 프린지가 복잡하고 중앙이 단순함) 아이디어를 동료에게 전달하고 피드백을받습니다. 숨겨진 관계, 정규화 등을 찾으려면 이미 내 머릿속에있는 것을 반영한 것입니다. 일반적으로 펜과 종이로 UML을 그립니다. 필요한 경우 디자인이 결정화 될 때 드로잉 프로그램에서 시각적으로 표현합니다.

UML은 클래스 다이어그램을 사용하여 아키텍처를 그래픽으로 볼 수 있다는 점에서 환상적입니다. 시퀀스 다이어그램을 사용한 상호 작용은 나에게 마법입니다. 따라서 문제는 UML이 아니라 MDD입니다.

UML이 코드의 뷰어 인 경우 문서화 목적에는 도움이되지만 코드 생성에는 도움이되지 않습니다. 프로젝트는 코드 중심이어야하고 모델 중심 중심이 아니어야합니다. UML은 라이브 코드와 모델 동기화를 사용하여 구현 단계에서 사용해야합니다. 요구 사항 수준뿐만 아니라 생산성과 품질의 작은 수익을 위해 너무 많은 투자가 필요하다는 것을 의미합니다.

나는 그들이 과대 평가 된 것을 발견했다. 나는 그것들이 천 단어를 그리지 않는 유일한 그림이라고 생각합니다.

UML은 시스템을 설계하는 사람들이 코드를 직접 작성할 수없는 경우에만 가치가 있습니다. 즉, UML은 아키텍처 개념을 다른 사람과 의사 소통하는 '언어'입니다. 이제 코드를 디자인하고 구현하는 사람이라면 자신이 수행 할 작업을 직접 보여 주어야하는 이유는 무엇입니까? ?! 대신 코딩을 바로 시작하십시오. 나중에 한 일을 계속 문서화해야하지만 전반적인 효율성은 더 빠릅니다.

그러나 아웃소싱 한 개발자 팀에게 원하는 것을 알리고 자하는 시스템 아키텍트라면 어떻게 든 말해야합니다. 그리고 UML이 들어오는 곳이 있습니다. 요즘이 작업은 솔직히 UML 다이어그램 작성의 복잡성으로 인해 누구나 읽을 수있는 방법을 이해해야한다는 것을 의미합니다.

나는 UML의 팬이 아니었지만 시스템이나 작업 사이의 상호 작용을 설명하기 위해 좋은 시퀀스 다이어그램을 중요하게 생각했습니다.

그러나 클래스 다이어그램은 태어나 기 전에 더 이상 사용되지 않습니다. 거친 디자인에는 UML이 필요하지 않으며 코드 기반에서 철저한 문서를 자동으로 추출 (실시간)하는 것이 좋습니다. Javadoc과 Doxygen은 수동 클래스 다이어그램의 필요성을 완전히 없애 버렸습니다.

문서에 관한 것은 두 가지 수준이 있다는 것입니다.

• 높은 수준의 (건축 적) 결정은 수동으로 문서화해야합니다
• 낮은 수준 (엔티티 관계) 사실은 자동으로 추출되어야합니다.

나는 보통 코드와 UML 다이어그램을 반복한다. 다이어그램이 큰 그림과 확실한 진전을 보여주는 데 도움이되고 문제가 발견 될 때 오히려 빠르게 변경 될 수 있습니다. 또한 다이어그램이 있으면 코딩이 사소한 경향이 있습니다.

반대로, 그림으로 코드를 그릴 때 종속성 문제가 노출되고 디자인 개선 기회가 눈에 띄게 나타납니다. 코드가 작동했을 때 눈에 띄지 않았을 것입니다. 특히, 그리는 것이 고통이라면, 코딩하는 데 고통과 유지해야 할 악몽이 될 것입니다.

그림을 그리는 것만으로도 중요한 부분이 누락되고 문제가있는 디자인 만 코딩되므로 반복이 필요하다는 것을 알았습니다.

그러나 다른 포스터가 말했듯이, 그것은 모두 사람들에게 귀결됩니다. 이들이 UML 다이어그램을 "사용하는"숙련 된 경우 UML은 매우 중요합니다. 그렇지 않은 경우 다이어그램은 가치가 없습니다.

따라서 귀하의 질문에 대한 답변은 "의존적"입니다. 이 경우 사람, 프로젝트의 복잡성 및 시스템이 올바르게 작동하는 것이 얼마나 중요한지에 달려 있습니다.

내 경험상 UML은 개발자들 간의 코드 패턴 및 응용 프로그램의 일반적인 아키텍처에 대한 커뮤니케이션에 중요합니다.

나는 다이어그램을 좋아하지만 하나 (특히 UML!)를 만들라는 요청을 받으면 두 가지 질문을합니다.

1. 누구를위한 것인가?
2. 그들은 지금 필요합니까?

다이어그램이 곧바로 만료되었습니다. 따라서 지금 누군가와 의사 소통하기 위해 사용하지 않으면 썩을 것입니다. 그리고 의사 소통하는 사람이 텍스트 설명, 전화 통화 또는 화이트 보드의 비공식 그림으로 더 나은 경우 대신 제안하십시오.

지금까지 내가 본 UML 다이어그램에 대한 주요 그립 중 하나는 주로 누군가의 벽에 "예쁜 그림"또는 바인딩 된 페이지의 접힌 페이지로만 사용되며 거의 기준선으로 사용되지 않는 경향이 있다는 것입니다 생산 코드.

이러한 유형의 시나리오에서 UML 다이어그램 (또는 사용하는 모델링 언어의 종류)은 시간이 지남에 따라 프로젝트가 진행됨에 따라 관련성이 상실되는 경향이 있기 때문에 장기적으로는 거의 유용하지 않습니다. 이 초기 그림은 몇 년 안에 대부분 쓸모없고 부정확하며 그 주위에있는 것은 대부분 해 롭습니다.

즉, 모델이 실제 실행 코드에 실제 라이브 및 관련 입력을 제공하는 경우 모델링 도구 (UML 일 필요는 없음)를 사용하는 것이 완전히 쓸모있는 것은 아닙니다. 모델 설명이 코드의 유용한 아티팩트 인 경우 코드로 처리해야합니다.

모델링 된 개념을 기반으로 동적 인 결정을 내리기 위해 메타 데이터의 직접 소스로 사용하거나 코드 생성을 사용하여 실제 작업 코드에 사용되는 정적 코드 아티팩트를 생성합니다.

UML의 장점 또는 프로그램 아키텍처 설계의 장점에 대한 질문인지 모릅니다.

UML 소개 일반적으로 유스 케이스, 클래스 다이어그램 및 시퀀스 다이어그램 만 필요합니다. 자신의 다이어그램 유형으로 확실히 할 수 있지만 간단하고 쉽습니다. 이와 관련하여 UML은 모든 사람이 이해하는 표준입니다.

프로그램 설계 정보

1. 계획하지 않아도 모든 프로그램에는 디자인이 있습니다. 코드가 작성되면 리버스 엔지니어링 만하면됩니다. 계획하지 않았다면 나쁜 디자인 일 것입니다.

2. 반복되는 문제에 대해 알려진 패턴을 사용하여 디자인하면 시간을 절약 할 수 있습니다.

3. 팀에서 일하는 경우 솔루션을 논의하고 아이디어를 전달하며 업무를 분산시키는 데 매우 실용적이지만 필수적인 디자인이 필요합니다.