구현 전후에 클래스 다이어그램을 작성해야합니까?

당신이 이점을 얻기 전에 하나를 만들면 내가 보는 방법 :

• 미리 계획
• 프로젝트 개요

그러나 당신은 잃습니다 :

• 시간 (작업을 수행하면 코드를 작성할 때 반복 될 수 있습니다)

반면에, 코드를 작성한 후 미래 개발자를위한 참조로 유지하기 위해 코드를 모두 만들 수 있습니다.

어느 것이 클래스 다이어그램의 목적을 제공하며 어느 것이 더 유리합니까?

이전에 작성하면 설계 단계의 일부가됩니다.

이후에 작성하면 문서화에 사용할 수 있습니다. 그러나 디자인 및 코딩 중에 문서화를 수행하면 문서화가 더 빨라집니다.

그건 그렇고, 당신은 디자인을하는 데 시간을 낭비하지 않습니다! 코딩 부분이 더 빠릅니다. 그리고 더 나은.

결국, 초고층 건물이나 다리를 설계하는 것이 단지 건축을 시작하는 대신 시간을 잃는 것이라고 생각하십니까?

디자인 단계 (클래스 / 함수의 프로토 타입)에서 더미 코드를 생성하기 시작하고이 코드 스켈레톤을 사용하여 클래스 다이어그램을 작성하는 것이 타협입니다.

코딩하기 전에 만든 후에는 "임시"문서로 간주합니다. 즉, 다이어그램을 만들고 생각을 종이에 담습니다. 그 클래스 다이어그램에서 코딩을 시작합니다. 그런 다음 버립니다. 코딩이 시작되면 유지 관리하는 데 시간을 투자 할 가치가 없습니다. 최신 클래스 모델을 원하는 경우 도구를 사용하여 코드에서 모델을 작성하십시오.

두 경우 모두 문서의 일부로 사용됩니다. 구현이 변경되면 아무도 업데이트하지 않습니다. 다이어그램에는 날짜가 없으므로 참조하는 코드 버전을 알 수 없습니다. 새 사람이 프로젝트에 추가되면 "설계 또는 구현 중 특정 시점에 작성된 일부 다이어그램이 있습니다. 최신 상태를 알 수 없습니다."라는 다이어그램을 제공합니다.

이것은 디자인의 일부이므로 구현 전에 만들어야합니다. 이는 현재 구현 상태를 반영하기 위해 구현 중 / 후에 구체화 될 수 없다고 말하는 것은 아닙니다.

구현 후 디자인을 제공하는 것을 "카우보이 코딩"이라고 부르며 와일드 와일드 웨스트에서 번성 할 수 있지만 카우보이는 대개 어느 시점에서 죽었다는 것을 기억하십시오.

디자인의 깊이에 따라 다릅니다. 어떤 사람들은 "좋은 습관"이기 때문에 가장 사소한 클래스조차도 클래스 다이어그램을 작성해야한다고 주장합니다. 구현 방법을 이미 알고 있으면 무언가를 그리는 것이 시간 낭비라고 생각합니다. 익숙하지 않은 새로운 디자인을 만들 때 먼저 다이어그램을 그리는 것이 유용합니다.

UML 도구는 절대 사용하지 않습니다. 왜냐하면 디자인을 구현하는 동안 일반적으로 디자인이 많이 변경되어 다이어그램을 다시 그려야하기 때문입니다. 좋은 양방향 도구가 이러한 변경 사항을 처리한다고 가정하지만 좋은 것을 사용한 적이 없습니다 (그러나 무료 도구 만 사용했습니다). 대신 디자인을 정리할 수 있도록 종이나 화이트 보드에 그립니다. 내가 그것을 구현하고 그것이 확실하다고 확신하면, 더 공식적인 다이어그램을 할 것입니다.

또한 다른 유형의 다이어그램을 잊지 마십시오. 나는 항상 시퀀스 다이어그램이 가장 유용한 것으로 나타 났으며, 컴포넌트간에 많은 통신이있을 때 자주 사용합니다.

구현하기 전에. 저의 이전 동료 중 한 사람이 한 번은 '코딩을 시작하기 전에 가능한 한 많은 프로그래밍을하고 싶다'고 말한 것처럼, 이것이 좋은 접근 방식이라고 생각합니다.

다이어그램을 그리는 행위는 대개 정보 누락을 경고합니다. 다이어그램을 작성하지 않고 코드 편집기로 입력하는 경우에도 발생하지만 인스턴스는 더 멀리 떨어져 있습니다 (알고리즘, 계산 및 테스트 작성에 시간을 소비하기 때문에). 따라서 더 많은 시간을 할애 할 수 있습니다 누락 된 정보를 얻기 전에 가십시오.

또한 머리에 모호한 디자인이 엉뚱한 것으로 판명되면 먼저 다이어그램을 작성하면 더 빨리 알 수 있습니다. 그러므로 나는 적어도 빠르고 비공식적 인 것을 그립니다. 다른 사람이 참조 용으로 사용할 수있는 전자 다이어그램으로 변환되는지 여부는 프로젝트에 따라 다릅니다.

모델이 코드 및 요구 사항 수정과 대화식이어야하므로 클래스 다이어그램을 생성하는 동안 및 이후에 클래스 다이어그램을 작성해야합니다. 먼저 프로젝트를 시작하기 위해 클래스 다이어그램을 만들어야합니다. 객체를 더 높은 수준의 추상화로 시각화하는 데 도움이됩니다. 안정적이고 지능적인 소프트웨어 아키텍처를 만들 수 있습니다. 그런 다음 코딩해야하며 때로는 UML에 잘 보이는 아키텍처가 코드에서 실제로 불가능하다는 것을 알 수 있습니다. 그런 다음 코드와 아키텍처를 변경하십시오. 마지막으로 코드 수정으로 모델을 업데이트하고 문서를 생성합니다.

지난 프로젝트에서 의사 결정자들은 작년에 50 번 이상 요구 사항을 변경했습니다. 정말 고통스럽고 UML은 변경 사항과 그 이유를 추적하는 데 도움이됩니다. UML을 사용하면 언제라도 반복적 인 방식으로 모델과 코드를 병합 할 수 있어야합니다 (예 : 코드에서 모델로, 모델에서 코드로, 리팩토링 후 코드에서 등으로). 이 도구. 내가 가장 좋아하는 기능은 모델 정보를 잃지 않고 언제든지 모델을 업데이트 할 수있는 모델 병합입니다. 또한 클래스 다이어그램에서 직접 엔티티 모델링을 좋아하고 스테레오 타입 및 최대 절전 모드를 사용하여 데이터베이스를 작성합니다. 객체에서 데이터베이스까지 정말 강력하고 완벽합니다!

전에 : 그것은 당신의 생각이 당신의 의도를 정리하고 전달하는 데 도움이 될 것입니다. 자세한 내용은 여기로 들어 가지 마십시오.

이후 : 분명히 빌드 프로세스의 일부로 코드에서 자동으로 생성됩니다 (uml에 너무 속하지 않기를 바랍니다)

둘 다 유용하지만 이전 항목 은 구현하자마자 버릴 수 있습니다 ...이 시점에서 이미 오래되었습니다.

함께 Topcased , 내가 설계 단계에서 내 클래스 다이어그램을 생성합니다. 그런 다음 구현 코드를 생성하기 위해 "코드 생성"버튼을 클릭하십시오. 그런 다음 자리 표시자를 코드로 채 웁니다.

답변을 위해 투표 할 것입니다. (C) 귀찮게하지 마십시오.

그것들은 크게 불필요합니다. 개인적으로, 나는 그들이 제공 될 때 그들을보고 귀찮게하지 않습니다.

디자인은 어쨌든 바뀔 것이기 때문에 개발하기 전에 불필요합니다. 그리고 수업의 디자인이 바뀌지 않을 것이라고 생각한다면 이미 수갑을 채우고 미래의 자아가 문제를 제대로 해결할 수 없게 만드는 것입니다. 기존 클래스 다이어그램을 고수해야한다고 생각하면 NASA에서 일하거나 발을 딛고있는 것입니다.

그 후, 그것들은 불필요한 문서입니다. 약간의 코드 검사로 클래스가 수행하는 작업 또는 클래스와의 관계를 파악할 수없는 경우 소프트웨어 개발자로서의 기술에 구멍이 있습니다.

물론이 답변은 정말 거만하고 의견이 많습니다. 오 잘.

Eiffel 및 관련 도구를 사용하면 동일한 기본 파일을 가리키는 시점의 차이 일뿐입니다.