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

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

편집 : 내 경험은 10 개 미만의 개발자 프로젝트로 제한됩니다.

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

충분히 복잡한 시스템 에는 일부 UML가 유용하다고 간주 되는 곳 이 있습니다.

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

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

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

너무 과도하지 않고 현재 진행중인 프로젝트에 가장 적합한 것이 무엇인지 생각하고 적용 가능하고 의미가있는 것을 선택하는 것이 가장 좋습니다.

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

하지만 당신이하는 일에 관한 것이 아닙니다. 지금부터 6 개월 뒤에 온 신입 사원은 어떨까요? 현재 프로젝트에 참여하고있는 모든 사람이 떠난 지금으로부터 약 5 년 후에는 어떻습니까?

나중에 프로젝트에 참여하는 모든 사람이 사용할 수있는 몇 가지 기본적인 최신 문서가 있으면 매우 유용합니다. 나는 메소드 이름과 매개 변수가 포함 된 완전한 UML 다이어그램을 옹호하지는 않지만 (유지하기가 너무 어렵습니다), 시스템 구성 요소의 관계와 기본 동작이 포함 된 기본 다이어그램이 매우 중요하다고 생각합니다. 시스템의 디자인이 크게 변경되지 않는 한, 구현이 조정 되더라도이 정보는 많이 변경되지 않아야합니다.

문서화의 핵심은 적당 함을 발견했습니다. 아무도 잠들지 않고 디자인 문서가 포함 된 50 페이지의 전체 UML 다이어그램을 읽지 않을 것입니다. 반면에 대부분의 사람들은 5-10 페이지의 간단한 클래스 다이어그램과 몇 가지 기본적인 설명을 원합니다. 시스템이 결합됩니다.

UML이 유용하다는 것을 알게 된 또 다른 경우는 시니어 개발자가 구성 요소 설계를 담당하지만 그 디자인을 후배 개발자에게 넘겨 구현할 때입니다.

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

예외는 당신이 밤에 횃불없이 숲속에있는 자신을 발견하고 비가 내리기 시작하는 이유입니다. 그러면 넘어지지 않도록 발을 살펴 봐야합니다. 수행 한 작업이 직감으로 처리 할 수있는 것보다 더 복잡 할 때가 있으며 프로그램의 구조를 명시 적으로 명시하고 속도를 늦춰야합니다. 그러면 UML은 사용할 수있는 많은 도구 중 하나입니다. 다른 것에는 의사 코드, 고수준 아키텍처 다이어그램 및 이상한 은유가 포함됩니다.

일반 작업 흐름 및 DFD는 복잡한 프로세스에 매우 유용 할 수 있습니다. 다른 모든 다이어그램 (특히 UML)은 내 경험상 예외없이 고통스러운 시간과 노력의 낭비였습니다.

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

이제 잘 사용되고 있는지 여부 는 또 다른 문제입니다.

Stu가 말했듯이, 개발자 관점에서 유스 케이스 (유스 케이스 설명과 함께)와 활동 다이어그램이 가장 도움이된다고 생각합니다.

클래스 다이어그램은 지속성과 같은 객체 속성뿐만 아니라 관계를 표시하려고 할 때 매우 유용 할 수 있습니다. 단일 속성 또는 속성을 추가하는 경우 일반적으로 과도합니다. 특히 코드가 작성되면 빠르게 구식이되는 경우가 많습니다.

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

대규모 (IBM과 유사한) 기업 개발 환경에 대한 경험이 없다는 점을 언급함으로써 제 답변을 검증하겠습니다.

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

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

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

저는 지난 두 학기 학교에서 시니어 개발 프로젝트 과정을 공동으로 가르쳤습니다. 이 프로젝트는 지역 비영리 단체가 유료 고객 인 프로덕션 환경에서 사용하기위한 것입니다. 우리는 코드가 우리가 기대 한대로 작동하고 학생들이 고객의 요구를 충족하는 데 필요한 모든 데이터를 캡처하고 있는지 확인해야했습니다.

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

다이어그램은 많은 정보를 매우 빠르게 전달했습니다. 학생들의 설계에 대한 빠른 개요를 통해 코드에서 문제 영역을 신속하게 분리하고 그 자리에서보다 자세한 검토를 수행 할 수 있습니다.

다이어그램을 사용하지 않았다면 학생들의 코드 파일을 하나씩 살펴보고 문제를 찾는 데 시간을 투자해야했을 것입니다.

나는이 주제에 대해 조금 늦게 왔으며 몇 가지 사소한 요점을 명확히하려고 노력할 것입니다. UML이 너무 광범위하게 유용한 지 묻습니다. 대부분의 사람들은 드로잉 / 커뮤니케이션 도구 관점에서 일반적인 / 인기있는 UML의 질문에 답하는 것처럼 보였습니다. 참고 : Martin Fowler와 다른 UML 서적 저자들은 UML이 커뮤니케이션에만 가장 적합하다고 생각합니다. 그러나 UML에는 다른 많은 용도가 있습니다. 무엇보다 UML은 논리적 개념에 매핑 된 표기법과 다이어그램이있는 모델링 언어입니다. 다음은 UML의 몇 가지 용도입니다.

• 통신
• 표준화 된 설계 / 솔루션 문서
• DSL (도메인 특정 언어) 정의
• 모델 정의 (UML 프로파일)
• 패턴 / 자산 사용
• 코드 생성
• 모델 대 모델 변환

Pascal이 게시 한 위의 사용 목록을 감안할 때 다이어그램 생성에만 적용되므로 충분하지 않습니다. 위 중 하나가 중요한 성공 요인이거나 표준화 된 솔루션이 필요한 문제 영역 인 경우 프로젝트는 UML의 이점을 누릴 수 있습니다.

논의는 UML이 과도하게 죽이거나 작은 프로젝트에 적용될 수있는 방법에서 확장되어 UML이 의미가 있거나 실제로 UML을 사용해야 할 때 제품 / 솔루션을 개선 할 것인지 논의해야합니다. 패턴 애플리케이션이나 코드 생성과 같이 한 개발자의 UML도 감지 할 수있는 상황이 있습니다.

UML은 수년간 저를 위해 일했습니다. 내가 시작했을 때 나는 Fowler의 UML Distilled 에서 "모델링 / 아키텍처 / 등을 충분히해라"라고 말하는 것을 읽었습니다 . 필요한 것을 사용하십시오 !

QA 엔지니어의 관점에서 UML 다이어그램은 논리와 사고의 잠재적 인 결함을 지적합니다. 내 일을 더 쉽게 만듭니다 :)

나는 UML이 유용하다고 생각한다. 나는 2.0 스펙이 한때 명확한 스펙이었던 것을 다소 부풀리고 번거롭게 만들었다 고 생각한다. 나는 타이밍 다이어그램 등의 편집에 동의합니다.

UML을 효과적으로 사용하는 방법을 배우려면 약간의 연습이 필요합니다. 가장 중요한 점은 명확하게 소통하고, 필요할 때 모델을 만들고, 팀으로서 모델을 만드는 것입니다. 화이트 보드는 제가 찾은 최고의 도구입니다. 실제 화이트 보드의 유용성을 캡처 한 "디지털 화이트 보드 소프트웨어"를 본 적이 없습니다.

나는 다음 UML 도구를 좋아한다고 말합니다.

1. 바이올렛-더 간단하다면 종이 한 장

2. Altova UModel-Java 및 C # 모델링을위한 좋은 도구

3. MagicDraw-내가 가장 좋아하는 모델링 용 상용 도구

4. 포세이돈-벅에 좋은 강타를 가진 괜찮은 도구

5. StarUML-최고의 오픈 소스 모델링 도구

UML 다이어그램은 요구 사항을 캡처 및 전달하고 시스템이 이러한 요구 사항을 충족하는지 확인하는 데 유용합니다. 계획, 설계, 개발 및 테스트의 다양한 단계에서 반복적으로 사용할 수 있습니다.

: 주제에서 개발 프로세스에서 모델 사용 에 http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

모델은 시스템이 작동하는 세계를 시각화하고, 사용자의 요구 사항을 명확히하고, 시스템 아키텍처를 정의하고, 코드를 분석하고, 코드가 요구 사항을 충족하는지 확인하는 데 도움이 될 수 있습니다.

다음 게시물에 대한 내 응답을 읽을 수도 있습니다.

"좋은 소프트웨어 디자인 / 아키텍처"를 배우는 방법? 에서 /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

이 토론은 오랫동안 비활성 상태 였지만 추가해야 할 몇 가지 중요한 사항이 있습니다.

버기 코드는 한 가지입니다. 하류로 떠난 디자인 실수는 실제로 매우 부풀어 오르고 추악 해질 수 있습니다 . 그러나 UML은 자체 검증합니다. 즉, 수학적으로 폐쇄되고 상호 확인되는 여러 차원에서 모델을 탐색 할 수있게함으로써 견고한 설계를 생성합니다.

UML에는 또 다른 중요한 측면이 있습니다. 즉, 가장 강력한 기능인 시각화 기능과 직접 "대화"합니다. 예를 들어 ITIL V3 (심지어 간단하게)가 UML 다이어그램의 형태로 전달 되었 더라면 수십 개의 A3 폴더에 게시되었을 수 있습니다. 대신, 그것은 진정한 성경적 비율의 몇 가지 책으로 나왔고, 전체 산업, 엄청난 비용과 광범위한 긴장성 쇼크를 낳았습니다.

꽤 자주 사용되는 시퀀스 다이어그램과 활동 다이어그램을 봅니다. 다른 시스템과 상호 작용하는 "실시간"및 임베디드 시스템으로 많은 작업을 수행하며 시퀀스 다이어그램은 모든 상호 작용을 시각화하는 데 매우 유용합니다.

나는 유스 케이스 다이어그램을 좋아하지만 그것이 가치 있다고 생각하는 사람들을 너무 많이 만나지 않았습니다.

저는 종종 Rational Rose가 UML 모델 기반 디자인에서 얻을 수있는 애플리케이션 종류의 좋은 예인지 궁금했습니다. 부풀고, 버그가 있고, 느리고, 못 생겼습니다.

UML은 아주 작은 프로젝트에는 유용하지 않지만 큰 프로젝트에는 적합합니다.

기본적으로 무엇을 사용하는지는 중요하지 않으며 다음 두 가지를 염두에두면됩니다.

• 일종의 아키텍처 계획을 원합니다.
• 팀의 모든 구성원이 실제로 프로젝트 계획에 동일한 기술을 사용하고 있는지 확인하고 싶습니다.

따라서 UML은 바로 프로젝트를 계획하는 방법에 대한 표준입니다. 새로운 사람을 고용하면 기존의 사내 물건보다는 UML, Flowchard, Nassi-Schneiderman 등 기존 표준을 알 가능성이 더 큽니다.

단일 개발자 및 / 또는 간단한 소프트웨어 프로젝트를 위해 UML을 사용하는 것은 과한 것처럼 보이지만 더 큰 팀에서 작업 할 때는 소프트웨어 계획을위한 표준이 필요합니다.

UML은 유용합니다. 내가 만든 주요 용도는 다음과 같습니다.

• 소프트웨어의 작동 방식에 대해 브레인 스토밍합니다. 당신이 생각하는 것을 쉽게 전달할 수 있습니다.
• 시스템의 아키텍처, 패턴 및 클래스의 주요 관계를 문서화합니다. 누군가가 당신의 팀에 들어 왔을 때, 당신이 떠날 때 당신의 후임자가 그것을 이해하도록하고 싶을 때, 그리고 당신이 결국 그 작은 수업이 무슨 뜻인지 잊었을 때 도움이됩니다.
• 위의 점과 동일한 이유로 모든 시스템에서 사용하는 아키텍처 패턴을 문서화합니다.

난 단지에 동의 마이클 그는 말한다 때 하나의 개발자 및 / 또는 간단한 소프트웨어 프로젝트에 대한 UML을 사용하는 것은 지나친 것 같다 그에게. 저는 작은 개인 프로젝트에서 그것을 사용했고, UML을 사용하여 문서화함으로써 7 개월 후 다시 돌아와서 모든 수업을 어떻게 만들고 모았는지 완전히 잊었을 때 많은 시간을 절약했습니다.

Fowler가 그의 저서 "UML Distilled"에서 설명한대로 Cockburn 스타일 UML 물고기, 연, 해수면 사용 사례를 활용하는 방법이있을 수 있다고 생각합니다. 내 생각은 코드 가독성을 위해 Cockburn 사용 사례를 사용하는 것이 었습니다.

그래서 저는 실험을했고 여기에 "UML"또는 "FOWLER"태그가 포함 된 게시물이 있습니다. C #에 대한 간단한 아이디어였습니다. Cockburn 사용 사례를 프로그래밍 구문의 네임 스페이스에 포함하는 방법을 찾습니다 (예 : 클래스 및 내부 클래스 네임 스페이스 또는 열거를위한 네임 스페이스 사용). 나는 이것이 실행 가능하고 간단한 기술이 될 수 있다고 믿지만 여전히 질문이 있고 그것을 확인하기 위해 다른 사람들이 필요합니다. 언어 확장없이 C # 코드 중간에 존재할 수있는 일종의 의사 도메인 특정 언어가 필요한 간단한 프로그램에 유용 할 수 있습니다.

관심이 있으시면 게시물을 확인하십시오. 여기로 가십시오 .

UML에 대한 문제 중 하나는 사양의 이해 가능성입니다. 특정 다이어그램의 의미를 실제로 이해하려고 할 때 메타 모델과 메타 메타 모델의 미로에서 금방 길을 잃습니다. UML의 판매 포인트 중 하나는 자연어보다 덜 모호하다는 것입니다. 그러나 두 명 이상의 엔지니어가 다이어그램을 다르게 해석하면 목표에 도달하지 못합니다.

또한 여러 UML 포럼에서 상부 구조 문서에 대한 구체적인 질문과 OMG 자체의 회원에게 결과가 거의 또는 전혀없이 질문 해 보았습니다. 나는 UML 커뮤니티가 아직 스스로를 지원할만큼 충분히 성숙하다고 생각하지 않습니다.

학생에게서 왔기 때문에 UML은 거의 사용하지 않습니다. PROGAMERS가 당신이 필요하다고 말한 것을 자동으로 생성하는 프로그램을 아직 개발하지 않았다는 것이 아이러니합니다. 데이터의 일부를 가져오고 정의를 찾고 제품 응답을 충분히 찾을 수있는 기능을 Visual Studio에 설계하는 것은 매우 간단하여 누구나 크건 작건보고 프로그램을 이해할 수 있습니다. 또한 정보를 생성하기 위해 코드에서 직접 정보를 가져 오기 때문에 최신 상태로 유지됩니다.

UML은 일종의 UML 다이어그램이지만 필드와 메서드로 클래스를 표현하자마자 사용됩니다.

UML의 문제점은 창립자 책이 너무 모호하다는 것입니다.

UML은 언어 일 뿐이며 실제로는 방법이 아닙니다.

저에게는 오픈 소스 프로젝트를위한 UML 스키마가 없다는 사실이 정말 짜증납니다. Wordpress와 같은 것을 취하면 데이터베이스 스키마 만 있으면됩니다. 큰 그림을 얻으려면 코덱스 API를 돌아다녀야합니다.

UML에는 그 자리가 있습니다. 프로젝트의 규모가 커짐에 따라 점점 더 중요해집니다. 장기 실행 프로젝트가있는 경우 모든 것을 UML로 문서화하는 것이 가장 좋습니다.

UML은 대규모 팀이있는 대규모 프로젝트에 적합합니다. 그러나 나는 의사 소통이 더 좋은 소규모 팀에서 일했습니다.

UML과 유사한 다이어그램을 사용하는 것은 특히 계획 단계에서 좋습니다. 저는 코드로 생각하는 경향이 있으므로 큰 사양을 작성하기가 어렵습니다. 나는 입력과 출력을 적고 개발자가 중간에 비트를 디자인하도록하는 것을 선호합니다.

저는 UML이 사람들이 클래스 간의 관계에 대해 생각하게한다는 사실에만 유용하다고 생각합니다. 그러한 관계에 대해 생각하기 시작하는 것이 좋은 출발점이지만, 확실히 모든 사람을위한 해결책은 아닙니다.

내 생각에 UML의 사용은 개발 팀이 작업하는 상황에 따라 달라집니다.

내 경험상 :

의미있는 코드 다이어그램을 만들고 전달하는 기능은 새 코드를 개발하거나 기존 코드를 이해하려는 모든 소프트웨어 엔지니어에게 필요한 기술입니다.

UML의 세부 사항 (점선 또는 원 끝점 사용시기)을 아는 것은 꼭 필요한 것은 아니지만 여전히 가지고있는 것이 좋습니다.

UML은 두 가지 방법으로 유용합니다.

• 기술적 측면 : 많은 사람들 (관리자 및 일부 기능 분석가)은 코드가 문서 이기 때문에 UML이 고급 기능이라고 생각합니다 . 디버깅 및 수정 후 코딩을 시작 합니다. UML 다이어그램을 코드 및 분석과 동기화하면 고객의 요청을 잘 이해할 수 있습니다.

• 관리 측면 : UMl 다이어그램은 부정확 한 고객의 요구 사항을 반영합니다. UML없이 코딩하면 많은 시간을 작업 한 후 require에서 버그를 찾을 수 있습니다. 다이어그램 UML을 사용하면 가능한 논란의 여지가있는 지점을 찾고 코딩 전에 해결 => 계획을 도울 수 있습니다.

일반적으로 UML 다이어그램이없는 모든 프로젝트는 표면적 분석이 있거나 크기가 짧습니다.

링크드 인 그룹 SYSTEMS ENGINEERS 에있는 경우 내 이전 토론을 참조하십시오 .

결국 UML은 RUP 때문에 존재합니다. Java / .Net을 사용하려면 UML 또는 관련 항목이 필요합니까? 실질적인 대답은 그들 자신의 문서 (javadoc 등)가있어서 충분하고 우리가 우리의 일을 끝낼 수 있다는 것입니다!

UML은 고맙습니다.

UML은 junit이 필수적인 것처럼 확실히 도움이됩니다. 그것은 모두 당신이 아이디어를 판매하는 방법에 달려 있습니다. 프로그램은 단위 테스트없이 작동하는 것처럼 UML없이 작동합니다. 즉, 코드에 연결되어 있으므로 do UML을 만들어야합니다. 즉, UML 다이어그램을 업데이트하면 코드가 업데이트되거나 코드를 업데이트하면 UML이 자동으로 생성됩니다. 단지 그것을하기 위해하지 마십시오.

UML은 분명히 업계에서 그 자리를 차지하고 있습니다. Boing 항공기 또는 기타 복잡한 시스템을위한 소프트웨어를 구축한다고 가정 해보십시오. UML과 RUP는 여기서 큰 도움이 될 것입니다.

UML은 사람들과 소통하는 방법 중 하나 일뿐입니다. 화이트 보드가 더 좋습니다.