나는 소프트웨어 공학을 전공했다. "소프트웨어 아키텍처 및 디자인"강사는 모든 UML 다이어그램 (또는 대부분)에서 소스 코드를 생성 할 수 있다고 말했습니다. 클래스 다이어그램에서 이미 코드를 생성 할 수 있습니다. 다른 다이어그램에서 코드를 생성 할 수 없습니다. 그 다이어그램을 클래스 다이어그램과 연결해야합니까?Enterprise Architect의 Use Case, Activity 또는 Sequence Diagram에서 코드를 생성 할 수 있습니까?
나는 대답을 찾았다 고 생각합니다. 코드를 생성 할 수 있습니다. "유스 케이스"가 있다고 가정 해보십시오. 마우스 오른쪽 버튼을 클릭하십시오. "advance"로 가서 "instance classifier"를 선택하십시오. 저기서 나는 실제로 "유스 케이스", "시퀀스 다이어그램 객체"등을 이미 생성 된 클래스의 인스턴스로 만들 수 있습니다. 아니면 거기에서 클래스를 만들 수도 있습니다.
이것은 말도 안됩니다. 다이어그램에서 코드를 생성 할 수는 없습니다. 그러나 UML 모델에서 코드를 생성 할 수는 있습니다. 이것은 인간을 시각화하는 데 도움이되는 몇 가지 다이어그램을 가질 수 있습니다 (꼭 그런 것은 아닙니다).
이제 코드는 클래스와 관련됩니다. 즉, 모델에 정의 된 클래스가 적어도 필요합니다. 유스 케이스는 클래스가해야 할 일을하는 이유를 이해하는 데 도움이됩니다. 그러나 어떤 경우에도 유스 케이스에서 코드를 작성할 수는 없습니다.
자세한 코드를 작성하는 데 도움이되는 다른 모델 요소가 있습니다. 그것들은 예를 들어. 동등한 코드 섹션으로 변환 할 수있는 상태 머신
활동 및 시퀀스 다이어그램은 실행 중에 특정 코드 섹션이 실행되는 방식을 시각화하는 데 도움이됩니다. 하지만 코드를 작성하는 데 (심각하게) 사용하지 않을 것입니다.
예, 가능하지만 설명하는 것만 큼 간단하지 않습니다. Model-Driven Architecture은 현재 연구 활동 영역이지만 실제로 아직 "파악하지 못했습니다". 그것의 지지자들은 C 언어가 어셈블리 언어보다 더 높은 수준의 추상화를 제공하고 Java가 C보다 높은 추상화 수준을 제공하는 것과 같은 방식으로 더 높은 수준의 추상화를 허용한다고 주장한다. 나는이 이 일 수 있다고 생각한다. 그들이 툴링 권리를 얻을 수 있다면 미래.
실제로 이것은 완전히 새로운 아이디어는 아닙니다. 일반적으로 그래픽 프로그래밍의 개념 (생각하면 기본적으로 UML 파생 프로그래밍의 일반화입니다)은 적어도 1980 년대 이후였습니다 내가 아는 (그리고 아마도 훨씬 더 일찍).
: (원래 맨 먼스 미신을 1986 년에 출판 의 현재 판에 표시 된) 소프트웨어 엔지니어링의 본질과 사고 - 사실, 프레드릭 브룩스 주니어는 에 대해 없음 실버 총알을 이야기하지Ph.D에 대한 좋아하는 과목. 소프트웨어 공학의 논문은 그래픽 또는 시각적 인 프로그래밍으로 컴퓨터 그래픽을 소프트웨어 설계에 적용하는 것입니다. 때로는 이러한 접근법의 약속은 컴퓨터 그래픽이 유익한 역할을하는 VLSI 칩 설계와 유사하다고 가정합니다. 때로는 이러한 접근 방식은 순서도를 이상적인 프로그램 디자인 매체로 고려하고이를 구축하기위한 강력한 기능을 제공함으로써 정당화 될 수 있습니다.
설득력 있고 훨씬 덜 흥미로운 것은 아직까지 그러한 노력에서 나왔습니다. 나는 아무것도 할 수 없다는 것을 확신한다. ...
그의 주장은 쓰여졌을 때 툴링이 아직 "거기"가 아니라는 것이다. 예를 들어 화면 크기는 악명이 낮았습니다. 또한, 흐름도는 실제로 실제로 나쁜 설계 메커니즘입니다.또한,
근본적으로 내가 위에서 주장한 것처럼 소프트웨어는 시각화하기가 매우 어렵습니다. 제어 흐름, 변수 범위 중첩, 변수 상호 참조, 데이터 흐름, 계층 적 데이터 구조 등을 다이어그램으로 만들지 여부에 관계없이 복잡하게 연동 된 소프트웨어 코끼리의 한 차원 만 느낍니다. 많은 관련 뷰에서 생성 된 모든 다이어그램을 겹쳐 쓰면 모든 글로벌 개요를 추출하기가 어렵습니다. VLSI의 비유는 근본적으로 오해의 소지가 있습니다. 칩 디자인은 그 기하학이 본질을 반영하는 계층화 된 2 차원 객체입니다. 소프트웨어 시스템이 아닙니다.
나는 당신이 그에게 동의하는지 또는 이것이 여전히 적용되는지 여부를 판단하기 위해 당신에게 남겨 둘 것입니다.
요약하면 : 이론적으로는 가능하며 UML 다이어그램에서 코드를 생성하는 데 상당한 노력이 있었지만 기본 클래스 구조 및 메소드 스텁보다 훨씬 많은 것을 생성하려면 여러 다이어그램이 필요합니다. 유스 케이스 다이어그램을 작성하고 버튼을 누른 다음 마술처럼 완벽한 소프트웨어 시스템을 가질 수있는 것은 아닙니다.
사실, 코드를 생성 할 수 있습니다. "유스 케이스"가 있다고 가정 해보십시오. 마우스 오른쪽 버튼을 클릭하십시오. "advance"로 가서 "instance classifier"를 선택하십시오. 저기서 나는 실제로 "유스 케이스", "시퀀스 다이어그램 객체"등을 이미 생성 된 클래스의 인스턴스로 만들 수 있습니다. 아니면 거기에서 클래스를 만들 수도 있습니다. –
코드는 클래스와 직접 관련이 있습니다. UC는 클래스와 간접적으로 관련되어 있습니다. 요구 사항은 UC와 간접적으로 관련됩니다. 요구 사항은 누군가가 과거에 한 번 생각한 것입니다. 따라서 당신은 당신의 단순한 생각에서 코드를 만들 수 있습니다. 당신과 함께 힘을합시다. –