그런데, 파생 개발의 「변경」을 어떻게 모델화할까. . . 전회까지의 개요는 이쪽.

파생개발에 있어서의 변경 지시를 모델로 표현한다(문제편)

델타 도입

원하는 것은 "수정"자체를 똑바로 표현하는 것입니다. 그래서 클래스의 "수정"을 나타내는 스테레오 타입, "델타"를 도입합니다. 이것은 클래스에 대한 변경 지시 그 자체를 나타내는 클래스입니다. 빨간 펜으로 쓰는 것을 조금 포멀하게 하고, 이 클래스 안에 정보로서 써 갑니다. 게다가, 서브가 되는 스테레오 타입,《add》,《delete》,《modify》도 도입.

델타: 델타

추가: 《add》

삭제: delete

변경: "modify"

이 세 가지로 나누어 변경을 표현합니다. 변경을 「클래스」로서 갇을 수 있는 분할입니다. 또한 이 변경 지시는 상위 변경 요청에 해당해야 합니다. 이 변경 요구를 「요구」(UML에서는《requirement》, SysML의 요구도로 사용하는「요구 요소」)와 묶으면, 한층 더 트레이서빌리티를 알기 쉬워질 것입니다.

설명 예

간단한 예입니다.

빨간 펜으로 표현한 경우

델타 기법

더 큰 모델이라면, 외형은 이런 느낌이 된다.



이렇게 생각하면, 델타의 영역에 중심의 설계 모델과는 「별로」, 패턴이나 아키텍쳐를 찾을 수 없을까,라고 생각하고 있다.

예를 들어,

변경 사항이 변경 전의 아키텍처를 가로 지르는 "레이어 종단 델타"패턴

국부적 인 변경으로 맞는 "Encapslated Delta"패턴

등등 상상하고 있다.

고찰

델타라고 하는 요소를 정의하는 것으로, 「변경」을 다이렉트에 모델화해 보았다. 또한, 요청 요소와의 관계를 표시함으로써 변경 의도를 추적 할 수 있습니다.

astah 를 사용해 쓰고 있습니다만, 이 쓰는 방법은 클래스 다이어그램 밖에 사용할 수 없다(「《delta》 클래스」는 클래스 다이어그램 밖에 둘 수 없다). 가능하면 다른 다이어그램, 예를 들어 상태 천이 다이어그램, 활동 다이어그램 등에서도 사용하고 싶을 것입니다. 그 경우, 《델타》상태, 《델타》활동 등 모델 요소를 만들어가는 것일까?

실무적으로는, 클래스가 아니고 조작이나 속성 (함수나 변수)에 직접, 변경 지시를 쓰고 싶다고 생각한다. 그 경우, 《델타》클래스가 아니고 더욱 세세한 입도에 대응하지 않으면 안 된다. 그러나 클래스 다이어그램의 종속성 화살표는 직접 조작으로 끌 수 없습니다. . . .

대응 방법으로서, 「노트」요소를 사용해 버리는 손도 있다고 생각한다. 이것이 실천적일지도 모른다. 상기 1, 2의 양쪽 모두의 문제를 단번에 해결할 수 있다.





그러나 형식화에서 벗어나 버린다. . .

후기

오늘은 "파생 개발 컨퍼런스"가 열립니다. (나, 기조 강연을 말씀 드렸습니다). 나는 파생 개발에 관해서는 아마추어입니다만, 어떻게든 이 안을 두드려 주는 것으로 실용적인 모델을 사용한 파생 개발의 한 걸음이 된다고 생각합니다.

(※ 5/16 추기: 패턴을 고찰해 보았다.)