대학에서 저는 수많은 디자인 및 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은 소스 코드에서 생성되어야합니다. 그렇지 않으면 매우 빨리 구식이되거나 최신 상태를 유지하는 데 많은 시간 (수동 오류 포함)이 필요합니다.
