2012-04-23 2 views

답변

1

클래스와 그 안에있는 속성/메소드의 세부 사항 간의 관계는 시스템이 수행 할 작업과는 아무런 관련이 없습니다. 시스템이 어떻게 수행 할 것인지를 btu와 관련이 있습니다. 이런 이유로 UML 클래스 다이어그램을 디자인 스펙에 넣었습니다.

나는 또한 일반적으로 전체 클래스 다이어그램을 디자인 사양에 넣지는 않지만 특정 주제 (전체 시스템의 하위 작업)에 중점을 둔 일부 (있는 경우)도 지정합니다. 기본적으로 클래스 다이어그램 (물론 시퀀스 다이어그램)을 사용하여 응용 프로그램을 설계하여 내 마음을 명확하게 솔루션을 볼 수 있지만 문서화에는 사용하지 않습니다. 클래스 다이어그램은 종종 처음부터 변경 될 수 있습니다. 리팩토링.

+0

대단히 감사합니다. –

1

나는 이것이 더 많은 설계 명세 사항이라고 말할 수 있습니다. 기능 사양에서 소프트웨어가 무엇을해야하는지 생각하고 디자인 사양에서 코드의 사용자 인터페이스의 모형뿐만 아니라 일부 UML의 초안을 시작할 수 있습니다.

도움이 되길 바랍니다.

+0

고맙습니다. –

2

다른 답변의 논리에 동의하지 마십시오. 관련성이 있거나 다를 수있는 또 다른 관점이 있습니다.

클래스 다이어그램에서 문제 도메인 (예 : Domain-Driven Design)을 모델링 한 경우 문제 도메인의 언어 (DDD 용어로 '유비쿼터스 언어')를 정의하는 데있어 근본적인 목적을 가질 수 있습니다.

그래서 (소프트웨어) 디자인 인공물이 아니라 실제로 형식화 된 용어집입니다. 이와 같이 함수 스펙에 사용 된 용어를 정의합니다.

온라인 쇼핑 시스템의 예를 들어보십시오. 기능적 요구 사항은 '제품 구입', '장바구니에 물건 넣기', '체크 아웃'등과 같은 가능성이 있습니다. 제품, 품목, 쇼핑 바구니라는 용어는 내재적으로 정의됩니다. 그러나 그들과 관련된 규칙은 무엇입니까? 예를 들어 한 번에 장바구니에 몇 개의 제품을 담을 수 있습니까? 체크 아웃하려면 모든 항목을 한 번만 지불해야합니까? 아니면 분할 될 수 있습니까?

이러한 종류의 규칙은 클래스 다이어그램에서 공식화 할 수 있으므로 기능 요구 사항의 매우 유용한 구성 요소가 될 수 있습니다.

적용 여부는 (a) 클래스 다이어그램의 내용과 (b) & 요구 사항 이해 관계자가 가져올 수있는 용어의 명확성으로 인해 혜택을 볼 수 있는지 여부에 달려 있습니다.

내가 말한대로 : 다른 관점.

hth.