2010-05-11 6 views
2

오래된 Java 응용 프로그램을 C#으로 다시 작성하는 과정에서 Software Design Specification을 작성하려고합니다. 내가 만나는 문제는 방법이 시퀀스 다이어그램 (다른 개체와 상호 작용하지 않음)을 다루기에는 너무 간단하다는 것입니다.UML에서 간단한 메소드를 문서화하는 방법?

public String getCategoryKey() { 
    StringBuffer value = new StringBuffer("s-"); 
    value.append(this.getModelID()); 
    value.append("-c"); 
    return value; 
} 

목적 및 문서화 할 필요가있는 방법에 대한 알고리즘 : 예를 들어

, 나는 품목라는 간단한 POJO, 다음과 같은 방법을 포함 있습니다. 그러나 시퀀스 다이어그램은 잔인합니다. 어떻게 다른 사람들이 문서화하겠습니까?

(주어진 메소드에 대해 신용/책임을지지 않습니다. 매우 오래된 코드이고 작성자는 Javadoc에 이름을 "잊어 버렸습니다").

+2

필요한 다이어그램을 그립니다. 이 방법에 다이어그램이 필요하다고 생각하십니까? –

+0

당신의 진짜 문제는 당신이 사소한 것들을 문서화하도록 강요당하는 것 같습니다 ... – ArtB

답변

2

시퀀스 문제는 시퀀스 다이어그램을 사용하여 메시지 시퀀스를 설명하는 데 사용되지만 문제는 시퀀스 다이어그램을 사용하여 그리기에 흥미가 없다는 것입니다.

시퀀스를 설명하지 않지만 상호 작용하는 다이어그램이 있지만 상호 작용에 참여자가 많지는 않지만 중요하게 작용할 수는 없습니다. StringBuilder는 중요한 부분이 아닙니다. 나는 추측한다.

상태 시스템을 설명하는 데 유용한 상태 다이어그램을 사용할 수도 있지만 개체는 메서드를 통해 상태를 변경하지 않습니다.

내 의견으로는 CategoryKey를 획득하는 것입니다. 먼저 접두사를 작성하십시오. 메소드 이름을 추가하고 접미어를 추가하십시오. 그래서 나는 당신의 경우에 활동 다이어그램이 시퀀스 다이어그램보다 유용 할 것이라고 생각한다.

그러나 방법은 매우 간단하며 그래픽 UML 문서가 필요하지 않을 수도 있습니다. 귀하의 방법에 대한 중요한 것은 그것이 쿼리라는 것 - 아니 상태가 변경됩니다, 그리고 접두사, 주요 부분과 접미사와 문자열을 반환합니다. 이것은 사후 조건을 사용하여 쉽게 설명 될 수 있습니다. 이를 위해 반환 값에 Javadoc 설명을 쉽게 사용할 수 있습니다.보다 정확한 결과를 얻으려면 OCL 언어 (UML 스택의 일부)를 사용하여 사후 조건을 설명 할 수 있습니다.

0

API 문서와 UML 문서를 게시 하시겠습니까? UML 다이어그램은 시스템의 여러 부분 간의 상위 수준의 디자인과 상호 작용을 설명하는 데 유용합니다. 설명하는 메소드와 같은 세부 사항은 API 문서 또는 인라인 주석에 더 잘 맞는 것처럼 보입니다.

.NET으로 포팅 할 때 코드의 XML 주석에서 도움말 파일을 생성하기 위해 Sandcastle을 체크 아웃 했습니까?

UML 다이어그램에 이와 같은 작은 세부 사항을 넣으려면 클래스 다이어그램의 클래스에 메모를 추가하여이 방법의 작동 방식을 간략하게 설명하는 것이 좋습니다.

관련 문제