저는 많은 프로젝트에서 아키텍처 디자인을 담당했습니다. 아키텍처 디자인을 의사 소통하기 위해 주로 사용되는 도구는 클래스 다이어그램, 패키지 다이어그램, 시퀀스 다이어그램, 배포 다이어그램입니다. 그리고 어떤 경우에는 흐름 채팅이 중요한 비즈니스 프로세스 모델링에도 사용됩니다.아키텍처 설계를 전달하는 가장 좋은 방법은 무엇입니까?
지금은 괜찮다고 생각합니다. 그러나이 목적을위한 더 나은 대안이 있는지 궁금합니다. 4 + 1보기 방법을 확인했습니다. 그것은보다 전체 론적 인 접근 방법으로 보인다. 나는 다음 번에 시도 할 것이다. 그렇다면 건축 디자인을 전달하는 가장 좋은 방법은 무엇입니까?
UML!
유용한 정보 : www.sintef.no/time/UML_ArchDesign.pdf.
내 즐겨 찾기 중 하나는 Data Flow Diagrams이며, 소위 "구조화 된"분석 및 디자인을 실시한 날짜부터의 날짜입니다.
나는 이것이 아마도 당신이 생각하고있는 것이 아니라, 화이트 보드라는 것을 알고 있습니다. 진지하게, 디자인을 잘 전달하기 위해서, 다양한 움직이는 부분들 사이의 상호 작용과 디자인을 끌어 내고 필요에 따라 주석을 달 수있는 것은 없습니다. 공식적인 방법은 아니지만 비판적인 "사람과 사람 간의"토론에 적합합니다.
사람들과 대화하기. 당신이 달성하고자하는 바를 말하십시오 : 당신이 만나려고하는 비 기능적 요구 사항 (그리고 그다지 중요하지 않은); 주요한 절충점은 무엇인가? 어떤 기본 원칙과 패턴을 사용하고 있습니다.
다이어그램은 귀하의 이야기를 뒷받침 할 수 있지만 그 자체로 이야기는 아닙니다. 나는 결코 두 프로젝트에서 같은 유물 목록을 사용한 적이 없다. 나는 변덕 스럽기 때문에 그런 생각을하지 않습니다. 그러나 모든 프로젝트에는 고유 한 문제가 있습니다 (기술이 아니라면 사람들이나 프로세스에서).
그것이 필요한 경우 UML, ER 다이어그램, 프로세스 모델, 모형 또는 모형 댄스를 사용할 준비를하십시오. 이미지와 텍스트로 말하고있는 것을 보완하십시오. (그래서 더 오랜 시간 동안 더 많은 사람들에게 다가 갈 수 있습니다.) 그러나 건축가로서해야 할 일의 핵심은 가장 중요한 것을 찾아서 모든 이해 관계자에게 전달하는 것입니다 : 현재 개발자, 미래 유지 보수 담당자, 시스템 운영자, 최종 사용자, 비즈니스 스폰서 - 다양한 수준의 세부 사항 . 당신이 의미하는 바는 의 강점점과 약점을 받아 들여야합니다. 실용적인 건축 문서 형식과 같은 것은 없습니다.
화이트 보드 및 얼굴을 보면서 토론하십시오.
실제로 화이트 보드를 사용합니다. 그것은 아주 효과적입니다. 사람들은 내 그림을 통해 내 생각을 따르고 설명을 뒷받침 할 수 있습니다. – yanky
필자는 요구 사항을 결정하기 위해 화이트 보드와 얼굴을 맞대는 경향이 있습니다. 그런 다음 UML을 사용하여 이러한 아이디어를 표준화/공식화하십시오.
공동 작업 프로세스 중에 엄격한 기준을 준수하는 것이 실제 목표에서 벗어나는 것임을 알았습니다. 즉, 나는 PMP (project management cert) 훈련을 받았고 종이, 푸른 끈적 끈적 끈적한 스풀을 사용했다. (나는이 재료가 무엇인지 압니다. 화이트 보드에. 화이트 보드와 달리 거대한 종이 조각은 쉽게 움직이며 큐 카드는 쉽게 재배치, 제거 또는 교체 할 수 있습니다. 나는 이것을 시도하는 것이 좋습니다.
끝나면 거대한 종이 조각을 넘겨서 가난한 사람들이 정식 UML 다이어그램에 입력해야합니다.
문서화되지 않은 아키텍처는 배우고 유지하기가 조금 더 어려울 수 있습니다. 또한 문서화 된 아키텍처는 팀 간 의사 소통을 도와줍니다 (예 :각 구성 요소를 개발하는 팀, QA 팀 등) : 설명서가 없으면 입소문과 사람들의 기억에 의존하여 아키텍처가 변경 될 수 있습니다. – ChrisW