배경 : 저의 공동 연구자와 저는 학술지에 기사를 쓰고 있습니다. 연구 과정에서 Java로 시뮬레이션 프로그램을 작성했습니다. 우리는 다른 사람들이 사용할 수있는 시뮬레이션 프로그램을 자유롭게 만들고자합니다. 우리는 GitHub 리포지토리에서 코드를 호스팅하기로 결정했습니다. 다른 사람들이 쉽게 사용할 수 있도록 다음과 같은 프로그램에 대한 훌륭한 문서를 작성하려고합니다.

• 각 클래스 및 메소드에 대한 Javadoc
• 코드를 사용하는 방법
• 코드의 고수준 구조 설명

내 수준 높은 질문은 : 프로그램의 높은 수준의 구조를 설명하는 데 사용할 수있는 단어와 다이어그램의 좋은 예를 제공 할 수 있습니까? 여기에는 하위 질문이 포함됩니다.

1. 어떤 패키지에 어떤 클래스가 포함되어 있는지 어떻게 알 수 있습니까?
2. 어떤 패키지가 다른 패키지에 의존하는지 어떻게 표시합니까?
3. 프로그램의 객체 / 클래스가 함께 작동하는 방법을 어떻게 보여줍니까?
4. 우리는 코드 디자인에 도메인 기반 디자인 원칙 을 사용하려고 시도했습니다 . 도메인의 객체와 이러한 객체를 인코딩하는 특정 소스 코드 파일 간의 대응 관계를 어떻게 표시합니까? (아래 프로젝트에 대한 "유비쿼터스 언어"설명을 참조하십시오.)

내가 지금까지 한 일

유비쿼터스 언어

우리는 코드의 "유비쿼터스 언어"설명을 파일의 ubiquitous-language.md아래 내용에 넣습니다 .

이 프로젝트의 목적은 다양한 리드 타임 모델, 보고서 지연 및 수요 모델에 따라 단일 시설을 갖춘 단순한 공급망에서 보충 정책이 얼마나 잘 수행되는지 연구하는 것입니다.

각 기간에 다음과 같은 이벤트가 발생합니다.

1. 현재 기간에 선적 이 설비 에 도착하도록 예정된 경우 설비 의 재고 레벨이 X 단위로 증가합니다.
2. 경우 일정이 현재 기간이보고 기간을 나타냅니다, 그 시설은 제출 보고서 받는 공급 업체 . 공급 업체는 수신 할 수 있습니다 보고서 에 의해 지정된대로, 몇 주 지연 또는 즉시 일정 .
3. 경우 공급 업체는 수신 한 보고서 다음을 기반으로, 보충 정책을 , 그것은 X 단위의 보충 량을 계산합니다. 선적 제품 X 단위는 L주기의 선두 시간 이후에 도착 예정한다.
4. 고객은 시설에 도착 하여 제품의 X 단위를 요구합니다. 충족되지 않은 수요는 없어집니다.

소스 코드 구조

코드의 불완전한 "고수준"설명을 파일 ( structure.md아래 내용)에 넣습니다 .

패키지 레벨 구조

최상위 레벨에서 소스 코드는 세 가지 패키지로 구성됩니다

• com.gly.sfsmain메소드 가있는 기본 클래스 는이 패키지에 있습니다.
• com.gly.sfs.model 도메인 모델 클래스는이 패키지에 있습니다.
• com.gly.sfs.util 헬퍼 클래스는이 패키지에 있습니다.

일반적으로 설명하는 목적으로 UML을 사용합니다. UML은 기본적으로 구조 및 행동의 두 가지 유형의 다이어그램으로 분류됩니다.

구조 다이어그램에는 구성, 배포, 패키지, 클래스, 개체 및 구성 요소가 포함됩니다. 동작 다이어그램에는 시퀀스, 상태 시스템, 통신, 사용 사례, 활동 및 상호 작용 개요가 포함됩니다.

전달하려는 대상에 따라 전달하려는 대상을 가장 잘 나타내는 이러한 다이어그램 중 몇 가지를 선택하면 대화가 "수준을 높일"수 있습니다. 메서드, 매개 변수 및 코드에 대한 이야기 ​​대신 일련의 상호 작용, 정적 클래스 종속성 또는 선택한 다이어그램에 대해 이야기합니다.

시퀀스 다이어그램 (행동 다이어그램 중 하나)의 예를 첨부했습니다. 시퀀스 다이어그램은 디자인 아티팩트 프로세스의 중간에 있기 때문에 개인적으로 시퀀스 다이어그램을 좋아합니다. 대략 같은 수의 다이어그램이 입력으로 예상되는 다이어그램에 의존합니다. 입력 다이어그램이 일반적으로 어쨌든 "이해"되었거나 시퀀스 다이어그램이 이미 존재한다는 것을 알았습니다. 그러나 때로는 정적 클래스 다이어그램과 시퀀스 다이어그램 (하나의 구조적 및 하나의 행동 다이어그램)을 모두 수행합니다.

http://omarfrancisco.com/wp-content/uploads/2011/07/sequencediagram.png

내 인생에서이 다이어그램을 본 적이 없지만이 시스템에 대해 여러 가지를 말할 수 있습니다. 뷰, 컨트롤러, 데이터 프록시 및 데이터 공급자라는 네 가지 주요 구성 요소 (시스템의 명사 (일반적으로 클래스))가 있습니다. 화살표는 "동작"또는 메소드 호출입니다. 시퀀스 다이어그램은 기본적으로 여러 구성 요소간에 중요한 단일 상호 작용을 표시하는 데 적합합니다. 시스템을 통한 각 중요한 흐름에 대해 하나의 시퀀스 다이어그램이 있습니다. 이 특정 다이어그램에서 "Controller"가 "phoneIsComplete ()"라는 메소드를 노출한다는 것을 알 수 있습니다.이 메소드는 DataProviderProxy의 "lookupPhone ()"메소드에 따라 달라지며, DataProvider의 "lookupPhone ()"메소드에 의존합니다.

자, 당신은 신음하고 생각할지도 모릅니다. "이것은 저에게 시스템의 큰 그림을 제공하지는 않습니다. 그것은 시스템을 통한 개별적인 상호 작용입니다". 시스템의 정교함에 따라 이는 유효한 관심사 일 수 있습니다 (단순한 시스템은 시퀀스 다이어그램 모음만으로도 쉽게 얻을 수 있습니다). 그래서 우리는 구조 다이어그램으로 이동하여 정적 클래스 다이어그램과 같은 것을 봅니다.

http://www.f5systems.in/apnashoppe/education//img/chapters/uml_class_diagram.jpg

클래스 다이어그램은 카디널리티와 클래스 관계 유형이라는 두 가지 중요한 사항을 파악하는 데 도움이됩니다. 클래스는 서로 다른 방식으로 연관, 집계 및 구성과 관련 될 수 있습니다. 기술적으로 말하면 "정적 클래스 관계"와 "인스턴스 관계"에는 차이가 있습니다. 그러나 실제로는이 선이 흐리게 보입니다. 주요 차이점은 정적 클래스 관계에는 일반적으로 카디널리티가 포함되지 않는다는 것입니다. 위의 예를보고 우리가 볼 수있는 것을 봅시다. 먼저 "Special Order"와 "Normal Order"가 "Orders"(상속)의 하위 유형임을 알 수 있습니다. 또한 한 고객이 N 개의 주문 ( "일반 주문", "주문"또는 "특별 주문")을 가지고 있음을 알 수 있습니다. 정말 알지 또한 각 클래스 상자의 아래쪽 절반에 많은 메서드와 속성 (각 클래스 상자의 위쪽 절반)이 있습니다.

나는 오랫동안 UML 다이어그램에 대해 계속 이야기 할 수 있지만 이것이 기본입니다. 잘하면 그것은 도움이됩니다.

TLDR; 하나의 행동 및 하나의 구조적 UML 다이어그램을 선택하고 작성 방법을 배우면 달성하려는 목표를 달성 할 수 있습니다.

프로그램의 높은 수준의 구조가 작동하는 방식 및 클래스가 잘 작동하는 방식과 같은 것을 설명하는 데 어려움이 있으면 다음 최대 값을 고려하십시오.

A picture is worth a thousand words.

코드에 대한 그림을 그리는 방법 은 코드 예제 를 제공하는 것입니다. 그들 중 많은. 새로운 고객 (코드)을 만드는 방법입니다. 주문 (코드)을 처리하는 방법입니다. 이것은 코드 소비자에게 시작의 장소를 제공 할뿐만 아니라 모든 객체가 서로 연결하고 상호 작용하는 방법을 보여줍니다. 코드를 사용하는 경우 코드 샘플을 많이 제공하는 것이 가장 좋습니다.

최종 사용자를 위해 그림을 그리는 방법 은 스크린 샷 을 제공하는 것입니다. 그들 중 많은. 이 작업을 수행하려면 먼저 수행하는 작업, 다음으로 수행하는 작업 등을 보여주는 스크린 샷 뒤의 스크린 샷

UML은 소프트웨어를 작성하기 전에 소프트웨어를 모델링하는 데 자주 사용되지만 유용 할 수 있습니다. 유스 케이스, 클래스 상호 작용 등을 설명하는 여러 가지 다이어그램이 있습니다 . 여기에서 자세한 내용을 볼 수 있습니다 .

내가 찾을 수 https://www.websequencediagrams.com/ 분산 응용 프로그램에 서비스를 응용 프로그램 내에서 구성 요소 간의 상호 작용을 설명하는, 또는 사이에 매우 유용한 도구입니다. UML 시퀀스 다이어그램을 만들고 유지 관리하는 프로세스가 훨씬 쉬워집니다.

좋은 점은 각 라이프 라인을 응용 프로그램의 인터페이스 또는 클래스로 간주하는 경우 (보통 큰 플레이어를 모델링하는 경우) 해당 클래스로 흐르는 각 라인은 지원 해야하는 방법을 나타냅니다.

또한 이미지를 가져 오는 몇 가지 다운로드 옵션이 있습니다. 위키에 다이어그램을 포함시키는 쉬운 방법도 있습니다. 따라서 시스템의 구성 요소 또는 서비스 간의 상호 작용을 설명하고 팀과 의사 소통하는 것은 훌륭한 의사 소통 도구입니다.