UML은 실용적인가?[닫은]

https://stackoverflow.com/questions/18803

09-06-2019
|

문제

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

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

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

해결책

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

시스템에 유용한 다이어그램은 적용 가능성에 따라 다릅니다.그러나 가장 널리 사용되는 다이어그램은 상태 다이어그램, 활동 다이어그램 및 시퀀스 다이어그램입니다.

이를 맹신하는 기업도 많지만 시간과 노력의 낭비라며 노골적으로 거부하는 기업도 많습니다.

지나치게 지나치게 생각하지 말고 현재 진행 중인 프로젝트에 가장 적합한 것이 무엇인지 생각하고 적용 가능하고 합리적인 것을 선택하는 것이 가장 좋습니다.

다른 팁

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

하지만 그것은 단지 당신이 하고 있는 일에 관한 것이 아닙니다.지금부터 6개월 후에 와서 코드를 빠르게 파악해야 하는 신입 사원은 어떻습니까?현재 프로젝트에 참여하고 있는 모든 사람이 사라지는 지금으로부터 5년 후에는 어떻게 될까요?

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

저는 문서화의 핵심은 절제라는 것을 알았습니다.디자인 문서가 포함된 완전한 UML 다이어그램 50페이지를 몇 페이지 읽다가 잠들지 않고 읽을 수 있는 사람은 아무도 없습니다.반면, 대부분의 사람들은 시스템 구성 방법에 대한 기본적인 설명이 포함된 5~10페이지 분량의 간단한 클래스 다이어그램을 원합니다.

UML이 유용하다고 생각하는 또 다른 경우는 선임 개발자가 구성 요소 설계를 담당하지만 구현을 위해 후배 개발자에게 설계를 넘겨주는 경우입니다.

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

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

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

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

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

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

클래스 다이어그램은 관계뿐 아니라 지속성과 같은 개체 특성을 표시하려고 할 때 매우 유용할 수 있습니다.단일 속성이나 속성을 추가하는 경우 일반적으로 과잉입니다. 특히 코드가 작성되면 빠르게 오래된 것이 되기 때문에 더욱 그렇습니다.

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

저는 대규모(IBM과 같은) 기업 개발 환경에 대한 경험이 없다는 점을 언급함으로써 답변을 한정하겠습니다.

내가 UML을 보는 방식과 합리적인 통합 프로세스 그게 더 많다는 거야? 말하는 실제로보다 무엇을 할 것인지에 대해 행위 당신은 무엇을 할 예정입니다.

(즉, 시간 낭비가 크다)

내 생각에만 버리세요.UML은 아이디어를 전달하는 훌륭한 도구입니다. 유일한 문제는 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을 감지할 수 있는 상황도 있습니다.

UML은 수년간 나를 위해 일해왔습니다.처음 시작했을 때 나는 Fowler의 책을 읽었습니다. UML 증류 그는 "모델링/아키텍처 등을 충분히 수행하세요"라고 말합니다.그냥 당신이 무엇을 사용 필요!

QA 엔지니어의 관점에서 UML 다이어그램은 논리와 사고의 잠재적인 결함을 지적합니다.내 작업이 더 쉬워집니다 :)

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

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

나는 다음과 같은 UML 도구를 좋아합니다.

보라색 - 더 단순하다면 종이 한 장일 텐데
Altova UModel - Java 및 C# 모델링을 위한 좋은 도구
MagicDraw - 제가 가장 좋아하는 모델링용 상업용 도구입니다.
포세이돈 - 비용 대비 성능이 좋은 괜찮은 도구
StarUML - 최고의 오픈 소스 모델링 도구

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

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

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

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

"좋은 소프트웨어 디자인/아키텍처"를 배우는 방법은 무엇입니까? ~에 https://stackoverflow.com/questions/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 Style Uml Fish, Kite 및 해수면 사용 사례를 활용할 수있는 방법이 있다고 생각합니다. 저의 생각은 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 다이어그램이 없는 프로젝트는 모두 피상적인 분석을 하거나 규모가 부족합니다.

링크드인 그룹에 속해 있다면 시스템 엔지니어, 보다 내 예전 토론.

결국 UML은 RUP 때문에 존재합니다.Java/.Net을 사용하려면 UML이나 관련 항목이 필요합니까?실용적인 대답은 그들이 자체 문서(javadoc 등)를 갖고 있어 충분하며 우리가 작업을 완료할 수 있다는 것입니다!

UML 아니요.

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

UML은 확실히 업계에서 그 자리를 차지하고 있습니다.보잉 항공기나 기타 복잡한 시스템용 소프트웨어를 구축한다고 상상해 보세요.UML과 RUP는 여기서 큰 도움이 될 것입니다.

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

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow