대학에있을 때 UML의 이점과 코드 개발의 미래에 대해 교육 받았습니다.

그러나 업계 경험을 바탕으로 ER 다이어그램, 클래스 다이어그램, 상태 다이어그램에서 작업 흐름 다이어그램에 이르는 다이어그램을 사용하는 것은 모두 커뮤니케이션을위한 것임을 알았습니다.

즉, 다이어그램에서 코드를 자동으로 생성 한 적이 없으며 통신 관점에서 일반적으로 다이어그램을 가능한 한 간단하고 이해하기 쉽게 유지하려고 노력합니다.

그러나 Visio와 Enterprise Architect를 살펴보면 사용하지 않는 여러 유형의 그래프, 모양, 속성 개체가있는 것 같습니다.

사람들은 UML을 사용하여 코드 나 데이터베이스 생성과 같은 더 복잡한 작업을 수행합니까?

예, UML CASE 도구는 90 년대의 가장 인기있는 품목 중 하나였으며 그 후에는 납품에 실패했습니다.

이것의 근본적인 이유는 UML (또는 대부분의 다른 종류의) 다이어그램이 문제를 이해하는 데 도움이되고 / 또는 다이어그램이 실제 코드 의 구현 세부 사항 을 추상화 하는 한에만 문제를 해결하는 프로그램에 도움이되기 때문 입니다. 따라서 (사소한 코드 조각의 경우) 이해하기 쉬운 다이어그램은 본질적으로 필요한 세부 사항이 없기 때문에 코드 생성에 쓸모 가 없습니다. 또한 코드 생성에 직접 사용할 수있는 다이어그램은 코드 자체보다 프로그램을 더 잘 이해하는 데 도움이되지 않습니다 . 프로덕션 코드에서 리버스 엔지니어링 된 UML 클래스 다이어그램을 본 적이 있다면 아마도 무슨 뜻인지 알 것입니다.

내가 아는 유일한 예외는 Entity-Relationship 다이어그램이며, 이는 코드 자체를 포함하지 않으며 (이름에서 알 수 있듯이) 데이터 조각과 관계 만 포함합니다. 하지만 실제 코드 생성을위한 UML 다이어그램의 모든 종류의 사용할 수있는 성공적인 시도의 들어 본 적이없는 [업데이트] 등의 증언, ORM 같은 특수 목적의 도구 / 지역을 제외하고 - 즉, 더 클래스 해골 및 게터 / 세터와 같은 사소한 코드보다가 - Doc Brown이 [/ Update] 아래 에 있으며 이것이 우연이 아니라고 생각합니다.

저는 개인적으로 UML을 싫어하지 않습니다. UML 다이어그램은 훌륭한 의사 소통 수단이 될 수 있습니다. 디자인 토론 중에 의도와 아이디어를 보여 주거나 앱 아키텍처를 시각화합니다. 그러나 이것을 유지하는 것이 가장 좋으며, 좋지 않은 것에 사용하지 마십시오.

그래서 내가 (지금 얼마 전에) uni에있을 때 UML이 미래라고 들었습니다 .UML은 프로그래밍을 대체 할 것이고 다이어그램 등에서 코드를 생성 할 것입니다.

그들은 틀렸다. 사람들이 연설을 포기하고 동굴 그림으로 돌아가는 시간에 일어날 것입니다.

실제 문제와이를 해결하는 프로그램은 줄일 수없는 본질적인 복잡성을 가지고 있습니다. 작동하는 프로그램을 만들려면 이러한 복잡성을 캡처하고 일부 실행 가능한 언어로 표현해야합니다. 문제는 일부 다이어그램 프로그래밍 언어가 텍스트 프로그래밍 언어보다 효과적인지 여부입니다. 우리는 약 30 년 동안 다이어그램 프로그래밍을 실험 해 왔으며, 지금까지는 텍스트 프로그래밍에 대한 증거가 압도적으로 많았습니다. 다이어그램에서 코드를 생성하여 생성 된 중요한 응용 프로그램을 알지 못합니다.

아니

범례는 다음과 같이 쓰지 않았다는 가정에 근거합니다.

class ClassName extends SomeThing
{

}

... 그건 하드 와 요구 자동화 .

당신은 여전히 ​​가끔 신자 나 많은 신자들을 찾을 수 있습니다 .
그러나 그것이 종교와 숭배와 함께 진행되는 방식입니다.

거기에 있었으므로 너무 유용하지 않았습니다.

일반적으로 클래스 다이어그램과 같이 일부 코드를 생성하기에 충분한 다이어그램은 실제로 프로그램을 이해하는 방법을 많이 추가하지 않으며 사용 사례 또는 개요 수준 활동과 같은 개요 다이어그램에서 코드를 생성 할 수 없습니다 문서화에 중요합니다. 이해하는 데 유용하고 코드를 생성 할 수있는 다이어그램 중 하나는 상태 차트로, 상태 머신이 실제로 필요할 때 유용합니다. 그러나 일반적으로 오류가 발생하기 쉽기 때문에 피해야합니다.

한 프로젝트에서 UML 모델러 (Rhapsody)로 코드를 디자인하고 코드를 생성해야했습니다. 그것은 작동했고 헤더 (C ++)와 프로토 타입을 직접 입력하는 것보다 약간 더 쉬웠을 것입니다. 이 두 가지를 자동으로 일관성있게 유지하는 기능은 다소 편리했습니다.

다이어그램은 상태 머신 스켈레톤을 제외하고는 실제로이를 나타낼 수 없기 때문에 메소드 본문은 여전히 ​​손으로 채워 져야했습니다.

반면에 그것은 다소 복잡하기 때문에 많은 추가 자료를 배워야하며 더 중요한 것은 병합하는 것이 고통 스럽습니다. 병합은 텍스트 파일에 대해 잘 연구되어 함께 작동하지만 아무도 변경 사항을 다이어그램에 쉽게 병합 할 수있는 방법을 발명하지 못했습니다. 랩소디는 실제로 생성 된 코드에서 정보의 일부를 유지하고 다시 구문 분석하므로 완전히 사용할 수는 없었지만 여전히 심각한 합병증이었습니다.

UML 모델에서 직접 코드 (및 전체 시스템)를 생성 할 수는 있지만 이런 식으로 사용 된 적이 없습니다.

내 경험상 대부분의 회사는이 도구를 요구 사항을위한 통신 도구 또는 "도면을 그리기위한 MS Paint"로 사용하는 것 같습니다.

내가 만들고 싶은 중요한 차이점 중 하나는 대부분의 UML 모델링 도구를 사용하여 단일 시스템 모델을 만들 수 있다는 것입니다. 예를 들어 Visio는 UML의 작동 방식을 상당히 잘 이해하고 있으며 다이어그램과 직접 관련이없는 추가 할 수있는 항목이 많이 있습니다. 실제 다이어그램은 모델의 일부에 대한 관점이 다르기 때문에 시스템의 다양한 측면을 강조 할 수 있습니다.

모든 것 (모델링 다이어그램)은 커뮤니케이션 목적입니다

모델링은 소프트웨어 개발 프로세스에서 4 가지 중요한 사용법이 있습니다.

1. 통합 디자인 툴

2. 커뮤니케이션 도구

3. 소프트웨어 생성에 도움

4. 실제 문제의 복잡성을 줄이는 방법 (위의 @kevin cline의 답변에서 이것을 배웠습니다)

5. 모델링 프로세스를 통해 일부 디자이너는 코딩하는 동안 고려되지 않은 세부 사항 (및 그 반대)에 대해 생각할 수 있습니다. 디자인 타임에 모델링하면 언어로 메서드 나 클래스를 코딩하는 것보다 더 큰 그림을 고려할 수 있습니다.

제 생각에는 모델링은 데이터베이스 (ER 다이어그램)를 구축하고, 프로세스 흐름 (활동 다이어그램)을 이해하고 사용자 시스템 상호 작용 (사용 사례 다이어그램)을 이해하는 데 필수적입니다.

사람들은 UML을 사용하여 코드 나 데이터베이스 생성과 같은 더 복잡한 작업을 수행합니까?

네 확실합니다. ERD (UML 다이어그램 아님) 및 클래스 다이어그램 (도구 기능에 따라 다름)을 사용하여 다음을 생성 할 수 있습니다.

1-데이터 정의 언어 (DDL)

2-선호 언어로 CRUD 및 클래스 다이어그램에 대한 저장 프로 시저 (ORM 도구가 이에 대해 더 많은 것을 수행하므로 덜 유용합니다)

모델링 도구의 가장 유용한 기능은 다음과 같습니다.

1-모델의 무결성을 유지하는 기능. 변경하면 모델에서 전파됩니다.

2-어디에 사용되는 질문에 답할 수있는 능력

3-동시 사용자가 모델 작업을 수행 할 수있는 기능

4-그래픽 표현 내에서 검색

5-인쇄 제어

6-한 번에 한 레이어에 집중할 수 있도록 레이어링 (다이어그램 요소를 레이어로 구성)

7-여러 데이터베이스 시스템에 대한 데이터베이스 코드 생성

8-모델 유효성 검사 (일관성 검사, 누락 된 키,주기 등)

따라서 모델링 도구, 특히 좋은 도구는 그림판보다 훨씬 더 많은 작업을 수행합니다.

우리는 Software Architect를 사용하여 높은 수준의 디자인을 수행하고 우리의 물건에서 더 복잡한 구성 요소 상호 작용을 문서화합니다. 우리는 때때로 다이어그램에서 앱의 골격을 생성하지만 일단 완료되면 둘 다 별도로 유지 관리하며 코드가 완성 된 후에 코드를 다시 다이어그램으로 리버스 엔지니어링하지 않습니다. 소규모 프로그램에서 잘 작동하는 Rational XDE라는 도구를 사용했지만 Swing 이벤트 핸들러에서 추가를 시작하거나 Struts 작업을 시도 할 때 손실됩니다.

사람들이 UML로 작성하지 않는 이유의 큰 부분은 UML의 모든 것을 완전히 지정하고 다이어그램에서 코드를 생성하는 데 훨씬 많은 작업이 필요하기 때문이라고 생각합니다. 미국 국방부가 OMG와 협력하여 올바른 것으로 확인 된 다이어그램에서 "증명 된"코드를 생성하는 일부 도구를 개발하고 있음을 알고 있지만 실제 코드보다 메타 데이터가 훨씬 더 많아 질 것입니다. 어느 쪽이 좋을까요 (결국 문서 임), 메타 데이터를 생성하는 것이 코드를 작성하는 것보다 빠르지 않으므로 비례 적으로 더 많은 시간을 소비하게됩니다.

UML 자체는 표기법 시스템이므로 통신 및 문서화의 원인이됩니다. UML 모델에서 코드를 생성하는 경우는 드물지만, 그렇게하는 사람들이 있습니다. 랩소디 사용자는 Rose보다 더 자주 사용합니다. 어려운 부분은 모델과 코드를 동기화 된 상태로 유지하는 것입니다. 대부분의 실제 프로젝트에서는 비용이 너무 높습니다.

내 최신 프로젝트에서 UML-Lab (https://www.uml-lab.com)을 사용하고 있습니다. 이것은 모델을 리버스 엔지니어링 할 수있는 훌륭한 도구입니다. 이 도구는 Java 코드 및 심지어 정확한 JPA 주석을 생성합니다.

이에 대한 도전은 팀에서 일할 때입니다. 이 모델은 정적이며 단일 리소스에 있으므로 여러 개발자 변경 사항과 동기화하기가 약간 어렵습니다. 1 개월 동안 사용할 수있는 평가판이 있으며, 조사중인 경우 다른 버전을 탐색하고 비교하기에 좋은 시간입니다.

코드 생성과 함께 한 번에 객체 모델링 및 데이터 모델링을 수행하는 제품을 본 것은 이번이 처음입니다.

그렇지 않으면 과거 프로젝트에서 항상 부정확하거나 너무 상세한 오래된 모델을 보았습니다.

과거 프로젝트에서 때로는 리버스 엔지니어링으로 다이어그램을 생성했습니다. 대부분의 경우 다이어그램이 복잡하다는 것을 알았으며 모든 노이즈를 수동으로 필터링하여 다이어그램을 그리는 것이 좋습니다.

UML을 사용하여 코드를 생성 할 수 있다고 생각합니다. 비즈니스 로직은 표준이 아니므로 응용 프로그램에 따라 응용 프로그램이 다양하므로 비즈니스 로직이 아닙니다. ER 다이어그램과 함께 클래스 다이어그램은 인터페이스, 클래스, 최대 절전 모드 엔티티, 기본 dao 메소드 등을 생성하는 데 사용할 수 있습니다. 외관 구현, 데이터 유형 변환기 (예 : 오브젝트를 전송하는 엔티티)와 같은 다른 상용구 코드는 오브젝트 다이어그램을 사용하여 생성 할 수도 있습니다. .

또한 이전 주석에서 언급했듯이 데이터베이스 스키마, DDL 스크립트 등은 모델을 사용하여 생성 할 수 있습니다.

OAW와 Enterprise Architect와 같은 모델링 도구를 사용하여 구성 파일 생성, 스테레오 타입 및 태그 값을 사용한 팩토리 코드 생성에 도움이되는 강력한 코드 생성기를 작성할 수 있습니다.

Business Object와 같은 도구를 사용하여 비즈니스 인텔리전스가 모든 회사 정보를 분석하고 활용할 수있는 이유를 여전히 이해하지 못합니다. 기술 수준에서 우리는 여전히 코드 수준에서만 또는 UML에서 추상 수준으로 작업하고 있습니다!

문제는 UML이 아니라 UML과 MOF 간의 모델 변환 및 템플릿을 사용하는 clas 다이어그램 또는 xmi에서 코드 생성입니다. UML은 실제 세계에 대한 추상적 인 견해를 제공한다고 말하므로 실제로 중요한 것을 볼 수 있습니다. UML 다이어그램이 실제 세계의 관점이라면 정확한 코드를 생성하는 방법은 무엇입니까? 불가능하기 때문에 모델에서 코드를 생성하는 모델 중심 개발이 실패했습니다.

해결책은 현실 세계와 모든 프로젝트 코드를 단일 UML 모델에 매핑하도록 변환하는 것입니다. 단일 모델과 프로젝트 전체 로직을 사용하면 매번 코드가 아닌 모델에서 뷰를 생성 할 수 있습니다. Java / Jee 기술 내에서 Omondo의 용기있는 이니셔티브가 있습니다. 이 개념은 코드 및 ORM과 직접 동기화 된 MOF 및 UML입니다. UML 다이어그램은 이제 전체 프로젝트를 매핑하는 모델의 상위 뷰일뿐입니다. 프로젝트를 더 잘 이해하기 위해 수백 개의 뷰를 만들고 수백 개의 노트를 추가 할 수 있습니다. 코드는 요소가 변경되거나 생성 된 경우에만 생성됩니다. Java ID가 MOF와 UML 간의 기존 변환 브리지없이 UML ID에 매핑되는 놀라운 기술입니다.

환상적인 점은 UML 수준에서 도메인을 모델링하고 코드에서 ORM 주석을 직접 얻을 수 있으므로 Hibernate를 사용하여 영구적 인 지속적인 통합으로 데이터베이스를 생성, 삭제, 생성, 배포 등을 할 수 있다는 것입니다. UML은 프로젝트의 아키텍처 자체가 아니라 모든 아키텍처의 일부입니다.

UML은 코드와의 실시간 동기화로 고수준 뷰어로 실망하지 않았지만 모델 기반 개발 템플릿 코드 생성과 함께 MDA를 사용하는 전통적인 방법에 의해 절대적으로 파괴되었습니다. 모델에서 코드를 생성하는 것은 단어 문서에서 나오는 HTML 페이지와 같습니다. 일단 생성되면 어떻게 변경합니까? 업데이트는 불가능하며 처음부터 작성하는 것보다 코드를 정리하는 데 더 많은 시간을 소비합니다!