소프트웨어 시스템의 아키텍처 모델링
소프트웨어 시스템이나 응용 프로그램이 사용자의 요구를 충족하도록 하기 위해 소프트웨어 시스템 또는 응용 프로그램의 전체 구조와 동작에 대한 기술의 일부로 Visual Studio Ultimate에서 모델을 만들 수 있습니다. 또한 모델을 사용하면 디자인 전체에서 사용되는 패턴을 기술할 수도 있습니다. 이러한 모델은 기존 아키텍처를 이해하고 변경 내용을 논의하며 의도를 명확하게 전달하는 데 도움이 됩니다.
모델의 목적은 자연어를 사용하여 기술할 때 발생하는 모호성을 줄이고, 동료와 함께 디자인을 시각화하고 대체 디자인을 논의하는 데 도움을 주는 것입니다. 모델은 다른 문서 또는 토론과 함께 사용되어야 합니다. 모델 자체는 아키텍처의 완전한 사양을 나타내지 않습니다.
참고
이 항목 전체에서 "시스템"은 개발 중인 소프트웨어를 말합니다.이는 다양한 소프트웨어 및 하드웨어 구성 요소의 컬렉션이나 단일 응용 프로그램 또는 응용 프로그램의 일부일 수 있습니다.
시스템 아키텍처는 다음과 같은 두 영역으로 나눌 수 있습니다.
고급 디자인. 여기에서는 주요 구성 요소를 나타내고 이러한 구성 요소가 각 요구 사항을 수행하기 위해 다른 요소와 상호 작용하는 방식을 기술합니다. 시스템이 큰 경우 각 구성 요소는 더 작은 구성 요소로 이루어지는 방식을 보여 주는 고급 디자인을 자체적으로 가질 수 있습니다.
구성 요소의 디자인 전체에 사용되는 디자인 패턴 및 규칙. 패턴은 프로그래밍 목표를 달성하기 위한 특정한 방법을 기술합니다. 디자인 전체에 같은 패턴을 사용하면 변경 및 새 소프트웨어 개발에 필요한 비용을 줄일 수 있습니다.
고급 디자인
고급 디자인은 시스템의 주요 구성 요소를 나타내고 이러한 구성 요소가 디자인 목표를 달성하기 위해 다른 요소와 상호 작용하는 방식을 기술합니다. 다음 목록의 작업은 고급 디자인 개발과 관련이 있으며 순서는 상관이 없습니다.
기존 코드를 업데이트하는 경우에는 주요 구성 요소를 기술하는 것으로 시작할 수 있습니다. 사용자 요구 사항에 대한 변경 내용을 이해한 다음, 구성 요소 간의 상호 작용을 추가하거나 수정해야 합니다. 새 시스템을 개발하는 경우에는 먼저 사용자 요구의 주요 특징을 이해해야 합니다. 그런 다음 주요 사용 사례의 상호 작용 시퀀스를 탐색하고 구성 요소 디자인에 시퀀스를 통합할 수 있습니다.
어떤 경우에 해당하든 여러 작업을 동시에 개발하고 초기 단계에서 코드와 테스트를 개발하는 것이 좋습니다. 다른 작업을 시작하기 전에 이러한 디자인 요소 중 하나를 완료하지 마십시오. 일반적으로 코드를 작성하고 테스트하는 동안 시스템 디자인을 위한 가장 좋은 방법과 요구 사항이 모두 변경됩니다. 따라서 요구 사항과 디자인의 주요 특징을 이해하고 코딩하는 것부터 시작해야 합니다. 프로젝트 반복의 후기 단계에서 세부 사항을 나타내십시오.
요구 사항 이해. 디자인은 사용자의 요구를 명확하게 이해하는 것에서 시작됩니다.
아키텍처 패턴. 시스템의 아키텍처 요소 및 핵심 기술에 대한 선택 항목입니다.
구성 요소 및 구성 요소 인터페이스. 시스템의 주요 파트를 보여 주는 구성 요소 다이어그램을 그리고, 시스템의 파트가 서로 상호 작용할 때 사용하는 인터페이스를 나타낼 수 있습니다. 각 구성 요소의 인터페이스에는 시퀀스 다이어그램에서 식별한 모든 메시지가 포함됩니다.
구성 요소 간 상호 작용. 각 사용 사례, 이벤트 또는 들어오는 메시지에 대해 필요한 응답을 얻기 위해 시스템의 주요 구성 요소가 상호 작용하는 방식을 보여 주는 시퀀스 다이어그램을 그릴 수 있습니다.
구성 요소 및 인터페이스의 데이터 모델. 구성 요소 간에 전달되고 구성 요소 내에 저장되는 정보를 기술하기 위해 클래스 다이어그램을 그릴 수 있습니다.
요구 사항 이해
완전한 응용 프로그램의 고급 디자인은 요구 사항 모델 또는 기타 사용자 요구에 대한 기술과 함께 가장 효과적으로 개발됩니다. 요구 사항 모델에 대한 자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.
개발하는 시스템이 규모가 큰 시스템의 구성 요소인 경우에는 요구 사항의 일부 또는 전체가 프로그래밍 인터페이스에 구현될 수 있습니다.
요구 사항 모델은 다음과 같은 중요한 정보를 제공합니다.
제공된 인터페이스. 제공된 인터페이스는 시스템이나 구성 요소에서 사용자에게 제공해야 하는 서비스 또는 작업을 나열합니다. 이때 사용자는 사람일 수도 있고 다른 소프트웨어 구성 요소일 수도 있습니다.
필요한 인터페이스. 필요한 인터페이스는 시스템이나 구성 요소에서 사용할 수 있는 서비스 또는 작업을 나열합니다. 어떤 경우에는 이러한 모든 서비스를 시스템의 일부로 디자인할 수 있습니다. 다른 경우, 특히 대부분의 구성에서 다른 구성 요소와 결합할 수 있는 구성 요소를 디자인하는 경우에는 외부적 문제에 의해 필요한 인터페이스가 설정됩니다.
서비스 품질 요구 사항. 성능, 보안, 안정성 및 시스템에서 충족해야 할 기타 목표와 제약 조건입니다.
요구 사항 모델은 시스템 사용자의 관점에서 작성됩니다. 이때 사용자는 사람일 수도 있고 다른 소프트웨어 구성 요소일 수도 있습니다. 사용자는 시스템의 내부 작업에 대해 아무 것도 모릅니다. 이와 달리 아키텍처 모델의 목표는 내부 작업을 기술하고 이러한 작업이 사용자의 요구를 충족하는 방식을 보여 주는 데 있습니다.
요구 사항 모델과 아키텍처 모델을 별개로 유지하면 사용자와 요구 사항에 대해 더 쉽게 논의할 수 있으므로 유용합니다. 또한 요구 사항을 변경하지 않으면서 디자인을 리팩터링하고 대체 아키텍처를 고려할 수 있습니다.
다음과 같은 두 가지 방법으로 요구 사항 모델과 아키텍처 모델을 분리할 수 있습니다.
두 모델을 각각 같은 솔루션의 다른 프로젝트에 둡니다. 이렇게 하면 UML 모델 탐색기에 별도의 모델로 나타나고, 여러 명의 팀 멤버가 동시에 모델에서 작업할 수 있습니다. 두 모델 간에 제한된 종류의 추적을 만들 수 있습니다.
두 모델을 각각 같은 UML 모델의 다른 패키지에 둡니다. 이렇게 하면 모델 간의 종속성을 쉽게 추적할 수 있지만 두 명 이상의 사용자가 동시에 모델에서 작업할 수 없습니다. 또한 매우 큰 모델을 Visual Studio로 로드할 때 시간이 오래 걸립니다. 따라서 이 방법은 큰 프로젝트에 적합하지 않습니다.
요구 사항 모델 또는 아키텍처 모델에 나타내야 할 세부 정보의 양은 프로젝트의 규모와 팀의 크기 및 배포에 따라 다릅니다. 짧은 프로젝트의 소규모 팀 비즈니스 개념 및 일부 디자인 패턴의 클래스 다이어그램을 스케치 하는 보다 더 이동 될 수 있습니다. 통해 여러 지역에 분산 된 대규모 프로젝트 훨씬 더 자세히가 필요 합니다.
아키텍처 패턴
개발 초기 단계에서는 디자인이 의존하는 주요 기술 및 요소를 선택해야 합니다. 예를 들면 다음과 같은 요소를 선택해야 합니다.
데이터베이스와 파일 시스템 사이의 선택, 네트워크 응용 프로그램과 웹 클라이언트 사이의 선택 등과 같은 기본 기술 선택
Windows Workflow Foundation 또는 ADO.NET Entity Framework 사이의 선택과 같은 프레임워크 선택
엔터프라이즈 서비스 버스 또는 지점 간 채널 사이의 선택과 같은 통합 방식 선택
이러한 선택은 대개 규모 및 유연성과 같은 서비스 품질 요구 사항에 의해 결정되며 상세 요구 사항이 알려지기 전에 지정할 수 있습니다. 큰 시스템의 경우 하드웨어와 소프트웨어의 구성은 서로 긴밀하게 관련되어 있습니다.
이러한 선택은 아키텍처 모델을 사용하고 해석하는 방식에 영향을 줍니다. 예를 들어 데이터베이스를 사용하는 시스템에서 클래스 다이어그램의 연결은 데이터베이스의 관계 또는 외래 키를 나타내지만 XML 파일 기반 시스템의 연결은 XPath를 사용하는 상호 참조를 나타냅니다. 또한 분산 시스템에서 시퀀스 다이어그램의 메시지는 통신 메시지를 나타낼 수 있지만 완전히 독립된 응용 프로그램의 메시지는 함수 호출을 나타낼 수 있습니다.
구성 요소 및 구성 요소 인터페이스
이 단원에서는 다음과 같은 내용을 권장합니다.
구성 요소 다이어그램을 만들어 시스템의 주요 파트를 나타냅니다.
구성 요소와 해당 인터페이스 간의 종속성을 그려 시스템의 구조를 나타냅니다.
구성 요소의 인터페이스를 사용하여 각 구성 요소에서 제공하거나 필요로 하는 서비스를 나타냅니다.
규모가 큰 디자인의 경우 별도의 다이어그램을 그려 각 구성 요소를 더 작은 파트로 분해할 수 있습니다.
이 단원의 나머지 부분에서는 이러한 권장 사항에 대해 자세히 설명합니다.
구성 요소
아키텍처 모델의 중심이 되는 뷰는 시스템의 주요 파트 및 각 파트가 서로 의존하는 방식을 보여 주는 구성 요소 다이어그램입니다. 구성 요소 다이어그램에 대한 자세한 내용은 UML 구성 요소 다이어그램: 참조를 참조하십시오.
.png "파트를 보여 주는 UML 구성 요소 다이어그램")
큰 시스템의 구성 요소 다이어그램에는 대개 다음과 같은 구성 요소가 포함됩니다.
프레젠테이션. 사용자에 대한 액세스를 제공하는 구성 요소이며 일반적으로 웹 브라우저에서 실행됩니다.
웹 서비스 구성 요소. 클라이언트와 서버 간의 연결을 제공합니다.
사용 사례 컨트롤러. 각 시나리오의 단계를 통해 사용자를 안내합니다.
비즈니스 핵심. 요구 사항 모델의 클래스를 기반으로 하는 클래스를 포함하고, 핵심 작업을 구현하며, 비즈니스 제약 조건을 적용합니다.
데이터베이스. 비즈니스 개체를 저장합니다.
로깅 및 오류 처리 구성 요소
구성 요소 간의 종속성
구성 요소 자체뿐만 아니라 구성 요소 간의 종속성도 나타낼 수 있습니다. 두 구성 요소 간의 종속성 화살표는 한 구성 요소의 디자인 변경이 다른 구성 요소의 디자인에 영향을 줄 수 있음을 나타냅니다. 이는 대개 한 구성 요소가 다른 구성 요소에서 제공하는 서비스나 기능을 직접 또는 간접적으로 사용하기 때문입니다.
올바른 구조의 아키텍처에는 종속성이 명확하게 배열되어 다음과 같은 조건을 만족합니다.
종속성 그래프에 루프가 없습니다.
모든 종속성이 한 레이어의 구성 요소에서 다른 레이어의 구성 요소로 움직이도록 구성 요소를 레이어로 정렬할 수 있습니다. 두 레이어 간의 모든 종속성은 같은 방향으로 이동합니다.
구성 요소 간의 종속성을 직접 나타내거나, 구성 요소에 연결된 필요한 인터페이스와 제공된 인터페이스 간의 종속성을 나타낼 수 있습니다. 인터페이스를 사용하면 각 종속성에서 사용되는 작업을 정의할 수 있습니다. 일반적으로 다이어그램을 처음으로 그리면 구성 요소 간의 종속성이 표시되고 정보가 더 추가되면 인터페이스 간의 종속성으로 바뀝니다. 두 버전 모두 소프트웨어를 정확하게 기술하지만 인터페이스를 사용하는 버전이 첫 번째 버전보다 더 자세한 정보를 제공합니다.
종속성 관리는 유지 관리가 가능한 소프트웨어를 생성하는 데 있어서 가장 중요합니다. 구성 요소 다이어그램에는 코드의 모든 종속성이 반영되어야 합니다. 코드가 이미 있는 경우 모든 종속성이 다이어그램에 나타나는지 확인합니다. 코드가 개발 중인 경우에는 구성 요소 다이어그램에서 계획되지 않은 종속성을 포함하지 않는지 확인하십시오. 레이어 다이어그램을 생성하면 코드에서 종속성을 검색하는 데 도움이 됩니다. 계획된 종속성 제약 조건이 충족되게 하려면 레이어 다이어그램에 대해 코드의 유효성을 검사합니다. 자세한 내용은 레이어 다이어그램: 참조을 참조하십시오.
인터페이스
구성 요소에 인터페이스를 배치하면 각 구성 요소에서 제공하는 주요 작업 그룹을 구분하고 이름을 지정할 수 있습니다. 예를 들어 웹 기반 판매 시스템의 구성 요소에는 고객이 상품을 구매하는 인터페이스, 판매업체에서 카탈로그를 업데이트하는 인터페이스, 시스템을 관리하는 세 번째 인터페이스가 있을 수 있습니다.
구성 요소에 포함할 수 있는 제공된 인터페이스와 필요한 인터페이스의 수에는 제한이 없습니다. 제공된 인터페이스는 다른 구성 요소가 사용할 수 있도록 해당 구성 요소에서 제공하는 서비스를 나타내고, 필요한 인터페이스는 해당 구성 요소가 다른 구성 요소에서 사용하는 서비스를 나타냅니다.
제공된 인터페이스와 필요한 인터페이스를 둘 다 정의하면 디자인의 나머지 부분에서 구성 요소가 완벽하게 분리되므로 다음과 같은 기법을 사용할 수 있습니다.
관련 구성 요소가 테스트 도구에 의해 시뮬레이션되도록 구성 요소를 테스트 도구에 배치합니다.
구성 요소를 다른 구성 요소와 독립적으로 개발합니다.
인터페이스를 다른 구성 요소에 결합하여 다른 컨텍스트에서 구성 요소를 다시 사용합니다.
인터페이스에 작업 목록을 정의하려는 경우 UML 클래스 다이어그램에 인터페이스의 다른 뷰를 만들 수 있습니다. 이렇게 하려면 UML 모델 탐색기에서 인터페이스를 찾아 클래스 다이어그램으로 끌어 옵니다. 그런 다음 인터페이스에 작업을 추가할 수 있습니다.
UML 인터페이스의 작업은 구성 요소의 동작을 호출할 수 있는 방법을 나타낼 수 있습니다. 예를 들면 웹 서비스 요청, 일부 다른 종류의 상호 작용이나 신호 또는 일반적인 프로그램 함수 호출 등을 나타낼 수 있습니다.
추가할 작업을 결정하려면 구성 요소가 다른 구성 요소와 상호 작용하는 방식을 나타내는 시퀀스 다이어그램을 만듭니다. 자세한 내용은 구성 요소 간 상호 작용을 참조하십시오. 이러한 각 시퀀스 다이어그램은 다양한 사용 사례에서 발생하는 상호 작용을 보여 줍니다. 이런 식으로 사용 사례를 탐색하면서 각 구성 요소의 인터페이스에 작업 목록을 점차적으로 추가할 수 있습니다.
구성 요소를 파트로 분해
앞의 단원에서 설명한 절차를 각 구성 요소에 적용할 수 있습니다.
각 구성 요소 내에서 하위 구성 요소를 파트로 나타낼 수 있습니다. 사실상 파트는 부모 구성 요소의 특성이며 일종의 클래스입니다. 각 파트에는 고유한 형식이 있으며 구성 요소일 수 있습니다. 이 구성 요소를 다이어그램에 배치하고 파트를 나타낼 수 있습니다. 자세한 내용은 UML 구성 요소 다이어그램: 지침을 참조하십시오.
이 방법을 전체 시스템에 적용하면 유용합니다. 시스템을 단일 구성 요소로 그리고 주요 구성 요소를 파트로 나타냅니다. 이렇게 하면 시스템의 인터페이스를 외부 환경으로 명확히 식별할 수 있습니다.
구성 요소의 디자인에서 다른 구성 요소를 사용하는 경우에는 대개 이 구성 요소를 파트로 나타낼지 아니면 필요한 인터페이스를 통해 액세스하는 별도의 구성 요소로 나타낼지에 대해 선택해야 합니다.
다음과 같은 경우에는 파트를 사용합니다.
부모 구성 요소의 디자인에서 항상 파트의 구성 요소 형식을 사용해야 하는 경우. 따라서 파트의 디자인이 부모 구성 요소의 디자인에 반드시 필요합니다.
부모 구성 요소에 구체적인 요소가 없는 경우. 예를 들어 뷰와 사용자 상호 작용을 처리하는 실제 구성 요소의 컬렉션을 나타내는 개념적 구성 요소, 즉 프레젠테이션 레이어가 있을 수 있습니다.
다음과 같은 경우에는 필요한 인터페이스를 통해 액세스되는 별도의 구성 요소를 사용합니다.
요청하는 구성 요소가 인터페이스를 통해 런타임에 다른 제공하는 구성 요소에 결합될 수 있는 경우
한 공급자를 다른 공급자로 쉽게 바꿀 수 있는 디자인인 경우
대개 필요한 인터페이스를 사용하는 것이 파트를 사용하는 것보다 좋습니다. 이 방법은 디자인하는 데 시간이 더 걸리지만 결과 시스템의 유연성이 뛰어납니다. 또한 구성 요소를 별도로 테스트하기도 쉽습니다. 이를 통해 개발 계획에서 결합을 줄일 수 있습니다.
구성 요소 간 상호 작용
이 단원에서는 다음과 같은 내용을 권장합니다.
시스템의 사용 사례를 식별합니다.
각 사용 사례에 대해 시스템의 구성 요소가 다른 구성 요소 및 사용자와 공동으로 작업하여 필요한 결과를 달성하는 방식을 보여 주는 다이어그램을 하나 이상 그립니다. 일반적으로 시퀀스 다이어그램 또는 동작 다이어그램을 그릴 수 있습니다.
인터페이스를 사용하여 각 구성 요소가 수신하는 메시지를 지정합니다.
인터페이스에서 작업의 효과를 기술합니다.
각 구성 요소에 대해 절차를 반복하여 파트의 상호 작용 방식을 보여 줍니다.
예를 들어 웹 기반 판매 시스템의 요구 사항 모델에서 고객의 구매를 사용 사례로 정의할 수 있습니다. 이 경우 프레젠테이션 레이어의 구성 요소와 고객의 상호 작용을 나타내고, 웨어하우스 및 회계 구성 요소와 고객의 상호 작용을 나타내는 시퀀스 다이어그램을 만들 수 있습니다.
시작 이벤트 식별
대부분의 소프트웨어 시스템에서 수행되는 작업은 다양한 입력 또는 이벤트에 제공하는 응답에 의해 편리하게 나눌 수 있습니다. 시작 이벤트는 다음 이벤트 중 하나일 수 있습니다.
사용 사례의 첫 번째 동작. 이 동작은 요구 사항 모델에서 사용 사례의 단계 또는 동작 다이어그램의 동작으로 나타날 수 있습니다. 자세한 내용은 UML 사용 사례 다이어그램: 지침 및 UML 동작 다이어그램: 지침를 참조하십시오.
프로그래밍 인터페이스의 메시지. 개발하는 시스템이 규모가 큰 시스템의 구성 요소인 경우에는 구성 요소 인터페이스 중 하나에서 작업으로 기술해야 합니다. 자세한 내용은 구성 요소 및 구성 요소 인터페이스를 참조하십시오.
시스템에서 모니터링되는 특정 조건 또는 정기적인 이벤트(예: 시간).
계산 기술
구성 요소가 시작 이벤트에 응답하는 방식을 나타내는 시퀀스 다이어그램을 그립니다.
일반적인 시퀀스에 참여하는 각 구성 요소 인스턴스에 대한 수명선을 그립니다. 일부 경우에는 각 형식의 인스턴스가 두 개 이상 있을 수도 있습니다. 전체 시스템을 단일 구성 요소로 기술한 경우에는 포함된 각 파트에 대해 하나의 수명선이 있어야 합니다.
자세한 내용은 UML 시퀀스 다이어그램: 지침을 참조하십시오.
동작 다이어그램이 유용한 경우도 있습니다. 예를 들어 구성 요소에 연속 데이터 흐름이 있으면 이를 개체 흐름으로 기술할 수 있고 구성 요소에 복잡한 알고리즘이 있으면 이를 제어 흐름으로 기술할 수 있습니다. 예를 들면 주석을 사용하여 각 동작을 수행하는 구성 요소를 명확하게 나타내야 합니다. 자세한 내용은 UML 동작 다이어그램: 지침을 참조하십시오.
작업 지정
다이어그램에서는 시퀀스 다이어그램의 메시지 또는 동작 다이어그램의 동작과 같이 각 구성 요소에서 수행되는 작업을 보여 줍니다.
각 구성 요소에 대해 이러한 작업을 함께 수집합니다. 그런 다음 제공된 인터페이스를 구성 요소에 만들고 이러한 인터페이스에 작업을 추가합니다. 일반적으로 개별 인터페이스는 각 형식의 클라이언트에 사용됩니다. 작업은 UML 모델 탐색기에서 간단하게 인터페이스에 추가됩니다. 같은 방식으로 다른 구성 요소에서 각 구성 요소가 사용하는 작업을 수집하여 해당 구성 요소에 연결된 필요한 인터페이스에 추가합니다.
동작 다이어그램 또는 시퀀스 다이어그램에 주석을 추가하여 각 작업 이후에 무엇이 달성되었는지 기록해 두면 유용합니다. 또한 로컬 사후 조건 속성에 각 작업의 결과를 기록할 수도 있습니다.
구성 요소 및 인터페이스의 데이터 모델
구성 요소 인터페이스에 각 작업의 매개 변수와 반환 값을 정의합니다. 작업이 웹 서비스 요청과 같은 호출을 나타내는 경우 매개 변수는 요청의 일부로 전달되는 정보입니다. 작업에서 여러 값이 반환되는 경우에는 방향 속성이 Out으로 설정된 매개 변수를 사용할 수 있습니다.
각 매개 변수와 반환 값에는 형식이 있습니다. UML 클래스 다이어그램을 사용하여 이러한 형식을 정의할 수 있습니다. 이러한 다이어그램에 구현 정보를 나타낼 필요는 없습니다. 예를 들어 XML로 전송되는 데이터를 기술하는 경우 연결을 사용하여 XML 노드 간의 모든 상호 참조를 나타내고 클래스를 사용하여 노드를 나타낼 수 있습니다.
주석을 사용하여 연결 및 특성에 대한 비즈니스 제약 조건을 기술할 수 있습니다. 예를 들어 고객이 주문한 모든 항목의 공급자가 같아야 할 경우에는 주문 항목과 제품 카탈로그 항목 사이의 연결 및 카탈로그 항목과 공급자 사이의 연결에 대한 참조로 이를 기술할 수 있습니다.
디자인 패턴
디자인 패턴은 소프트웨어의 특정 요소, 특히 시스템의 여러 파트에서 되풀이되는 요소를 디자인하는 방법을 요약한 것입니다. 프로젝트 전체에 일정한 방법을 사용하면 디자인 비용을 줄이고 사용자 인터페이스의 일관성을 유지할 수 있으며 코드를 이해하고 변경하는 데 필요한 노력을 줄일 수 있습니다.
관찰자와 같은 몇몇 일반적인 디자인 패턴은 잘 알려져 있으며 광범위하게 적용됩니다. 또한 현재 프로젝트에만 적용할 수 있는 패턴도 있습니다. 예를 들어 웹 판매 시스템의 경우 코드에 고객의 주문을 변경하는 작업이 여러 개 있습니다. 주문 상태가 모든 단계에 정확하게 표시되도록 하려면 데이터베이스를 업데이트하도록 이러한 모든 작업이 특정 프로토콜을 따라야 합니다.
소프트웨어 아키텍처 작업의 일부는 디자인 전체에 사용해야 할 패턴을 결정하는 것입니다. 프로젝트가 진행됨에 따라 새 패턴 및 기존 패턴의 업데이트가 검색되므로 대개 이 작업은 계속됩니다. 초기 단계에서 주요 디자인 패턴을 각각 시험하도록 개발 계획을 구성하는 것이 좋습니다.
대부분의 디자인 패턴은 프레임워크 코드에 부분적으로 구현될 수 있습니다. 데이터베이스가 올바로 처리되도록 하는 데이터베이스 액세스 레이어와 같이 패턴의 일부를 축소하여 개발자가 특정 클래스 또는 구성 요소를 사용하도록 할 수 있습니다.
디자인 패턴은 문서에 기술되며 일반적으로 다음과 같은 요소를 포함합니다.
이름
패턴을 적용할 수 있는 컨텍스트에 대한 설명. 예를 들면 개발자가 패턴을 적용할 때 고려해야 할 기준을 지정합니다.
패턴으로 해결하는 문제에 대한 간단한 설명
주요 파트 및 파트 관계 모델. 클래스 또는 구성 요소와 인터페이스 및 이들 간의 종속성과 연결 등이 될 수 있습니다. 요소는 대개 다음과 같은 두 범주에 포함됩니다.
개발자가 패턴이 사용되는 코드의 모든 부분에서 복제해야 할 요소. 템플릿 형식을 사용하여 이러한 요소를 기술할 수 있습니다. 자세한 내용은 UML 사용 사례 다이어그램: 참조을 참조하십시오.
개발자가 사용해야 할 프레임워크 클래스를 기술하는 요소
시퀀스 다이어그램 또는 동작 다이어그램을 사용하는 파트 간 상호 작용 모델
명명 규칙
패턴으로 문제를 해결하는 방식에 대한 설명
개발자가 채택할 수 있는 패턴 변형에 대한 설명