모델에서 응용 프로그램 생성 및 구성
모델에서 응용 프로그램의 여러 부분을 생성하거나 구성할 수 있습니다. 모델은 UML이나 DSL에 있을 수 있습니다.
모델은 코드보다 더 직접적으로 요구 사항을 나타냅니다. 응용 프로그램 동작을 모델에서 직접적으로 파생시키면 코드를 업데이트할 때보다 훨씬 더 빠르고 안정적으로 변경된 요구 사항에 대처할 수 있습니다. 일부 초기 작업에서 파생을 설정해야 하는 수고가 있지만 나중에 요구 사항을 변경해야 하거나 제품의 여러 변형을 만들 경우 이를 유용하게 활용할 수 있습니다.
모델에서 응용 프로그램 코드 생성
코드를 생성하는 가장 쉬운 방법은 텍스트 템플릿을 사용하는 것입니다. 모델을 보관하고 있는 것과 동일한 Visual Studio 솔루션에서 코드를 생성할 수 있습니다. 자세한 내용은 다음을 참조하십시오.
이 방법은 증분식으로 쉽게 적용됩니다. 특정한 경우에만 적용되는 응용 프로그램으로 시작하고 모델에서 변경할 응용 프로그램 부분을 선택합니다. 해당 부분의 소스 파일 이름을 텍스트 템플릿 파일(.tt)로 바꿉니다. 그러면 템플릿 파일에서 소스 .cs 파일이 자동으로 생성되므로 응용 프로그램이 이전과 동일하게 작동됩니다.
코드의 한 부분을 가져옵니다. 그런 다음 모델을 읽고 소스 파일의 해당 부분을 생성하는 텍스트 템플릿 식으로 해당 코드 부분을 바꿉니다. 응용 프로그램을 실행할 수 있고 응용 프로그램이 이전처럼 작동하도록 하나 이상의 모델 값이 원래 소스를 생성해야 합니다. 다른 모델 값을 테스트한 후 코드의 다른 부분에 템플릿 식을 삽입할 수 있습니다.
이 증분식 방법은 일반적으로 위험이 적은 코드 생성 방법입니다. 결과 응용 프로그램은 대개 직접 작성한 버전과 거의 동일하게 수행됩니다.
기존 응용 프로그램으로 시작하는 경우 모델의 영향을 받는 각 동작을 구별하여 따로따로 변경할 수 있도록 많은 리팩터링 작업이 필요할 수 있습니다. 프로젝트 비용을 예측할 때 이러한 측면에서 응용 프로그램을 평가하는 것이 좋습니다.
모델에서 응용 프로그램 구성
런타임에 응용 프로그램의 동작을 변경하려는 경우 응용 프로그램이 컴파일되기 전에 소스 코드를 생성하는 코드 생성을 사용할 수 없습니다. 대신 UML 또는 DSL 모델을 읽고 동작을 적절하게 변경하도록 응용 프로그램을 디자인할 수 있습니다. 자세한 내용은 다음을 참조하십시오.
이 방법을 증분식으로 적용할 수도 있지만 처음에 많은 작업을 수행해야 합니다. 모델을 읽는 코드를 작성하고 변수 부분에서 값을 액세스할 수 있도록 하는 프레임워크를 설정해야 합니다. 가변 부분을 제네릭으로 설정하면 코드를 생성할 때보다 더 많은 비용이 듭니다.
제네릭 응용 프로그램은 대개 그에 상응하는 제네릭이 아닌 응용 프로그램보다 성능이 떨어집니다. 따라서 성능이 중요한 경우 이 위험 평가를 프로젝트 계획에 포함시켜야 합니다.
파생된 응용 프로그램 개발
다음과 같은 일반 지침을 사용하면 도움이 될 수 있습니다.
특정 버전으로 시작한 다음 일반화합니다. 먼저 특정 응용 프로그램 버전을 작성합니다. 이 버전은 하나의 조건 집합에서 작동해야 합니다. 버전이 올바르게 작동하는 경우 버전의 일부를 모델에서 파생시킬 수 있습니다. 파생되는 부분을 점차적으로 확장합니다.
예를 들어 모델에 정의된 페이지를 표시하는 웹 응용 프로그램을 디자인하기 전에 특정 웹 페이지 집합으로 구성된 웹 사이트를 디자인합니다.
가변 측면을 모델링합니다. 배포 간에 또는 시간이 경과하여 요구 사항이 바뀜에 따라 변경할 측면을 식별합니다. 이러한 측면을 모델에서 파생해야 합니다.
예를 들어 웹 페이지 집합과 웹 페이지 사이의 링크는 변경되지만 페이지의 스타일과 형식은 항상 동일한 경우 모델은 링크를 설명해야 하지만 페이지의 형식은 설명할 필요가 없습니다.
문제를 분리합니다. 가변 측면을 독립 영역으로 나눌 수 있는 경우 영역마다 별도의 모델을 사용합니다. ModelBus를 사용하여 두 모델 모두에 영향을 주는 작업과 두 모델 간의 제약 조건을 정의할 수 있습니다.
예를 들어 웹 페이지 간 탐색과 페이지의 레이아웃을 정의하는 데 각각 다른 모델을 사용할 수 있습니다. 자세한 내용은 방법: UML 모델을 다른 모델 및 도구와 통합을 참조하십시오.
솔루션 대신 요구 사항을 모델링합니다. 사용자 요구 사항을 설명하도록 UML을 적용하거나 DSL을 디자인합니다. 반대로 구현의 가변 측면에 따라 표기법을 디자인하지 마십시오.
예를 들어 웹 탐색 모델은 웹 페이지와 웹 페이지 간의 하이퍼링크를 표시해야 합니다. 웹 탐색 모델은 응용 프로그램의 클래스 또는 HTML 조작을 표시하지 않아야 합니다.
생성 또는 해석? 특정 배포에 대한 요구 사항이 거의 변경되지 않는 경우 모델에서 프로그램 코드를 생성합니다. 요구 사항이 자주 변경되거나 동일한 배포의 여러 변형에서 공존할 수 있는 경우 모델을 읽고 해석할 수 있도록 응용 프로그램을 작성합니다.
예를 들어 웹 사이트 모델을 사용하여 개별 설치되는 여러 웹 사이트를 개발할 경우 모델에서 사이트의 코드를 생성해야 합니다. 모델을 사용하여 매일 변경되는 사이트를 제어하려면 모델을 읽고 사이트를 적절하게 표시하는 웹 서버를 작성하는 것이 좋습니다.
UML 또는 DSL? 스테레오타입을 사용하여 UML을 확장하도록 모델링 표기법을 만드는 것이 좋습니다. 목적에 맞는 UML 다이어그램이 없는 경우 DSL을 정의합니다. 그러나 UML의 표준 의미를 반드시 준수해야 합니다.
예를 들어 UML 클래스 다이어그램은 상자와 화살표의 모음이며, 이론적으로는 이 표기법을 사용하여 모든 것을 정의할 수 있습니다. 하지만 실제로 형식 집합을 설명하는 경우를 제외하고 클래스 다이어그램을 사용하지 않는 것이 좋습니다. 예를 들어 클래스 다이어그램을 적용하여 여러 종류의 웹 페이지를 설명할 수 있습니다.