나는 우리 회사 소프트웨어 중 하나에서 파일 로딩 프로세스를 조사하는 작업을 가지고 있는데, 메인 클래스와 메소드를 대표해야하고 어떤 작업이 이루어 졌는지 그리고 마지막으로 어떤 종류의 다이어그램으로 그 사실을보고하십시오.소프트웨어 제품에서 워크 플로우를 표현하는 방법
텍스트 문서를 작성하거나 UML을 사용하여이 워크 플로를 설명하고 어떤 종류의 다이어그램을 사용해야하는지 가장 좋은 방법은 무엇입니까?
높은 수준의 프로세스 흐름을 위해 UML 활동 다이어그램 (http://www.agilemodeling.com/style/activityDiagram.htm)을 사용하십시오.
그런 다음 자세한 내용을 보증 할 정도로 복잡한 부분은 UML 시퀀스 다이어그램 (http://www.agilemodeling.com/artifacts/sequenceDiagram.htm)을 사용하십시오.
모든 문서에 가장 적합한 형식은 전달하는 정보뿐만 아니라 대상 독자에 따라 다릅니다. 잠재 고객이 소프트웨어 엔지니어로 구성된 경우 UML을 선택하는 것이 좋습니다. 즉, 표준화되어 있습니다. 즉, 자신의 표기법을 설명하거나 설명 할 필요가 없으며 다이어그램을 합리적으로 단순하게 유지하면 확률이 높습니다. 잠재 고객이 UML 전문가가 충분하지 않더라도 잠재 고객이이를 읽을 수 있습니다.
당신은 문서가 무엇인지 말을하지 않지만, 최소한 내가 보고서에 다음 섹션 제안 :
소스보기 : 클래스 다이어그램을, 아마도 몇 가지 패키지 다이어그램뿐만 아니라에 따라 구현 언어 및 패키지의 수와 유형. (패키지가 Java로 할 수있는 것처럼 기능상의 추상화를 제공한다면, 그것들을 기술하는 것을 고려해보십시오. 그렇지 않으면 그다지 중요하지 않습니다.)
런타임 뷰 : 적어도 주요 기능에 대한 제어 흐름을 설명하는 시퀀스 다이어그램.
당신은 하나 또는 이들의 이상을 고려할 수 있습니다 :
전체 디자인 : 소프트웨어의 주요 부분 설명 구성 요소 다이어그램 : DLL에와 API는 사용자의 코드에 의해 호출되는 예를 들어를 (나는 우리 가정 일종의 라이브러리 루틴에 대해 이야기하고 있습니다). 이것은 특정 메소드 호출 또는 구현 클래스와 관련되어서는 안되며, 소프트웨어를 높은 수준에서 설명해야합니다.
개념보기 : 이것은 일반적으로 매우 간단한 클래스 다이어그램을 사용하여 주요 개념을 설명해야합니다. 파일은 아마도 그 중 하나 일 것이므로 파일의 다른 상태 (열린 상태, 닫힌 상태, eof ...)를 설명하는 상태 차트를 포함시켜야합니다.
항상 UML을 사용하여 코드를 생성하는 대신 문서화 할 때 각 다이어그램의 노트가 풍부하고 요소 (클래스 등)가 부족합니다. 텍스트 문서에 붙여 넣기위한 다이어그램의 경우 각 다이어그램에 6 개 이상의 요소를 넣지 않으려 고합니다.