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