개발 전에 최신 애플리케이션을 모델링하기위한 표준은 무엇입니까?

첫 번째 엔터프라이즈 급 응용 프로그램을 사용 하고 있으며 한 줄의 코드를 작성하기 전에 팀이 전체 ASP.NET MVC C # 응용 프로그램을 모델링하기를 원합니다.

업데이트 : 이것은 언제 응용 프로그램을 문서화 / 모델링 해야하는지에 대한 철학적 토론이 아닙니다. 문서화 / 모델화 방법에 대한 답변 만 제공하십시오.

사실 저는이 부서에서 항상 실수를 해왔으며 실제로는 응용 프로그램을 모델링 한 적이 없습니다. 이 작업을 수행하는 표준 방법은 무엇입니까? 어떤 유형의 다이어그램을 사용해야하며 설명서는 어떻게 표시됩니까? 샘플 다이어그램 및 문서에 대한 링크를 부탁드립니다.

검색 할 때 인터넷에서 수많은 것을 찾을 수 있지만이 작업을 수행하는 방법에 대한 현대의 합의가 있는지 확인하고 싶었습니다.

미리 감사드립니다!

결산 명세서

나는 이것이 끈적 끈적한 주제인지 전혀 몰랐다. 명백한 논쟁을 피하고 유용한 답변을 제공 할 수있는 여러분 모두에게 감사합니다. 가장 적게 말하는 것은 흥미로운 토론이었습니다 :)

내가 발견 한 또 다른 유용한 링크는 https : //.com/questions/61487/do-you-use-uml-in-agile-development-practices/61519#61519

현대의 합의

진실은 : 현재 현대 소프트웨어 개발에는 부족한 것입니다. 모델링에 대한 합의입니다. UML은 일종의 가장 작은 공약수 인 것처럼 보이지만 실제로는 시맨틱이 아니라 표기법에 대한 합의 만 있습니다. 코드를 작성하기 위해 UML을 해석하는 방법에 대한 수십 가지 의견이 있습니다 (아마도 팀에 적합한 하나의 해석을 찾을 수 있음).

다른 한편으로, "공식적인 모델을 만들지 말고, 작업 코드를 더 잘 작성하십시오"라고 말하는 "민첩한"사람들과 "BDUF"(큰 디자인을 앞두고) 사람들과 MDA "(모델 기반 아키텍처)가 솔루션입니다.

다른 사람들은 UML의 대안으로 최신 소프트웨어 디자인을위한 흐름 기반 프로그래밍을 다시 발견했습니다. 이에 대해 자세히 알아 보려면 여기 와 여기 를 읽으 십시오 .

한 줄의 코드를 만들기 전에 팀이 전체 ASP.NET MVC C # 응용 프로그램을 모델링하기를 원합니다.

일반적으로 그러한 접근 방식으로 발견되는 문제는 솔루션에 대한 나의 이해가 처음 에는 항상 불완전 하다는 것입니다 . 작업이 진행됨에 따라 개선을 통해서만 최종 솔루션이 나옵니다.

코드 (가장 단순한 앱을 제외한 모든 코드)가 어리석기 전에 전체 앱을 미리 디자인하려고 시도하는 것이 일반적입니다.

모든 클래스와 메소드 및 데이터 구조를 미리 자세하게 배치 할 수 있다고 생각하십니까?

좋은 모델링 솔루션을 알고 싶습니다.

실제 도구를 사용하여 모델을 만들려면 몇 가지를 시도해 보았고 항상 Microsoft Visio를 사용했습니다.

내가 시도한 모든 제품 중에서 가장 직선적이고 실제로 안정적입니다 (모델링 도구에 대한 나의 경험은 매우 버그가 많다는 것입니다). 공정하게하기 위해, 나는 모델링을 거의하지 않기 때문에이 추천을 소금 한 알갱이로 가져 가십시오.

편집 : 실제로, 나는 대부분의 모델링이 책상에 앉아있는 메모장에서 수행된다고 말해야합니다. 모델링이 적기 때문에 가벼우면서도 포인트를 유지하려고 노력합니다. 펜과 종이로 다이어그램을 스케치하는 것이 소프트웨어를 사용하는 것보다 훨씬 효율적입니다.

손으로 쓴 다이어그램은 다이어그램 소프트웨어에 배치하기 전에 아이디어를 형성하는 데 유용 할 수 있습니다.

어떤 유형의 다이어그램을 사용해야하며 설명서는 어떻게 표시됩니까?

요즘 내가 모델링하는 것은 대부분 상호 작용 다이어그램입니다. 다시 말하지만, 나는 많은 모델링을하지 않습니다. 모델을 그리는 연습이 내 이해를 강화시키는 데 도움이되는 곳입니다.

UML 다이어그램은 시작하기에 좋은 곳입니다. 무료 또는 유료 소프트웨어로이를 수행하는 쉬운 방법이 많이 있습니다. UML을 만드는 도구의 간단한 예는 Google 문서 그림과 같으며 고급 패키지는 Visio 또는 OmniGraffle입니다.

편집 : 많은 사람들이 언급했듯이 UML 경로를 따라 가면 모든 것을 완전히 모델링해야한다는 의미는 아니지만 모델링하는 내용과 모델이 필요한 세부 사항에 대한 합의에 도달 할 수 있습니다 있다. 간단한 UML 다이어그램은 코드를 작성하기 전에 코드를 작성하고 잠재적 인 문제가 발생하기 전에 정리하는 데 도움이 될 수 있습니다.

@Brett이 제안했듯이 UML 다이어그램이 가장 좋습니다. UML을 사용하면 클래스 다이어그램과 워크 플로우 다이어그램을 가질 수 있습니다. 이 두 가지는 대부분의 설계 요구를 충족시킵니다.

클래스 다이어그램을 사용하면 각 엔티티의 멤버, 보안 레벨 등을 모델링 할 수 있습니다.

작업 흐름 다이어그램을 사용하면 어떤 호출을 호출하는지, 작업 흐름의 결과 및 발생할 수있는 예외가 무엇인지 모델링 할 수 있습니다.

코드를 작성하기 전에 기본 건축 도면을 만드는 것이 중요하지만 전체 앱의 세부 도면을 작성하는 것은 너무 많은 일이라고 생각합니다.

일반적으로 Visio에서 몇 가지 개요 그림을 만들고 종종 "흐름도"빌딩 블록을 사용하여 내 뜻을 시각화합니다. UML을 사용하면 종종 공식화되고 너무 많은 세부 사항을 초대합니다. Visio 도면은 응용 프로그램의 기본 구성 요소와 기능 유형을 보여줍니다. MVC 프레임 워크를 사용하는 경우 대부분 웹에서 샘플을 가져 와서 복사하면됩니다.

다른 관점에서 몇 개의 도면을 작성하는 것이 좋습니다. 모든 것을 그리는 대신 시스템의 특정 기능을 하나 더 사용하여 다음과 같이 시각화하는 것을 선호합니다.

• 사용 사례 다이어그램 (UML)
• 순서도 또는 UML 스 lane 레인 (매우 높음)
• 건축 구성 요소 개요.

그런 다음 코딩을 시작합니다. 코딩하는 동안 도트 통합으로 doxygen을 사용하여 즉시 클래스 다이어그램, 상속 등을 얻습니다. doxygen 생성 개요를 보는 것이 종종 코드 구조를 보는 매우 좋은 방법입니다.