파생개발에 있어서의 변경 지시를 모델로 표현한다(문제편)
파생 개발에 있어서의 「변경 지시」
일본의 임베디드 개발에 자주 사용되는 기법인 시미즈씨의 파생 개발(XDDP) 입니다만, 파생 전의 상태에 대해서 「변경 지시」 를 문서화합니다.
소스 코드 레벨이라면 문제는 적습니다만, 구조에 대한 수정은 전역적으로 되어, 잘 표현하기 어렵게 됩니다. 이것을 모델로 취급하고 싶다는 것이 문제입니다.
Before/After 문제
가장 중요한 것은 Before와 After를 보여주는 방법입니다.
여기에서 실제 변경을 실시하는 것은 매우 관찰력이 필요! 예를 들어, 실수를 찾아 버립니다.
예를 들면 astah 등에서는 diff를 취하는 기능도 있습니다 하지만, 더 좋은 방법은 없습니까? 보통은 "빨간 펜"을 넣고 싶은 곳.
한층 더 말하면, 모처럼이므로, 「변경을 표현하는 모델」이 있으면 좋은데! 변경을 표현하는 것이 목적의 모델과 그것을 사용한 뷰.
이 표현의 필요성을 아키텍처 관점에서 말해 보자.
「아키텍처 기술」이라고 하는 무엇인가, 라고 하는 이야기로, 2000 IEEE1471( ISO/IEC42010 )라고 하는 표준 모델이 있습니다. 거기에는, 「뷰」와 「뷰 포인트」가 정의되고 있어 ( 『소프트웨어 시스템 아키텍쳐 구축의 원리(제2판)』 읽었다 참조)
가장 중요한 것은 Before와 After를 보여주는 방법입니다.
여기에서 실제 변경을 실시하는 것은 매우 관찰력이 필요! 예를 들어, 실수를 찾아 버립니다.
예를 들면 astah 등에서는 diff를 취하는 기능도 있습니다 하지만, 더 좋은 방법은 없습니까? 보통은 "빨간 펜"을 넣고 싶은 곳.
한층 더 말하면, 모처럼이므로, 「변경을 표현하는 모델」이 있으면 좋은데! 변경을 표현하는 것이 목적의 모델과 그것을 사용한 뷰.
이 표현의 필요성을 아키텍처 관점에서 말해 보자.
「아키텍처 기술」이라고 하는 무엇인가, 라고 하는 이야기로, 2000 IEEE1471( ISO/IEC42010 )라고 하는 표준 모델이 있습니다. 거기에는, 「뷰」와 「뷰 포인트」가 정의되고 있어 ( 『소프트웨어 시스템 아키텍쳐 구축의 원리(제2판)』 읽었다 참조)
이해 관계자마다 관심사가 있습니다.
"뷰포인트"는 하나 이상의 "관심사"를 커버한다.
되어 있습니다. 요컨대, 모델은 누군가의 관심사마다 뷰포인트에 따라 기술된다. 파생 개발에 있어서 「변경」은 분명히 관심사이기 때문에, 「변경을 나타내는 뷰」, 그리고 그 모델 표현은 필요하다고 할 수 있다.
해결안
그러나, 현재, 이 「변경을 나타내는 모델」을 정면에서 취급한 것을, 나는 모른다. . . . 빨간 펜으로 쓰는 것도 좋습니다. 그리고 Before/After를 보여주는 것도 좋습니다. 그러나, 좀 더 공식적으로 (UML 정도의 세미 공식적으로) 취급할 수 있으면 좋겠다. 「변경을 표현하는 모델」이 있으면 좋은데.
라는 것이 문제입니다. 그럼, 다음 해의 시안입니다.
(보기 1:클래스도를 예로 했습니다만, 상태 천이도나 액티비티도, 순서도 등, 보다 여러가지 그림으로 사용할 수 있으면 좋다고 생각합니다.또, 파생 개발의 현장에서는 C언어가 많이 사용되는지도 여기서는 예제로 UML 클래스를 사용한 객체 지향적 표현이지만 클래스를 '파일', 조작을 '함수', 속성을 '변수'로 읽어 C 언어에서도 사용할 수있는 것이 좋다. 라고 생각합니다.)
(보기 2: 올해의 파생 개발 컨퍼런스에 기조 강연이라는 대역을 받았습니다. .일본의 민첩한 이야기를 하려고 합니다.)
Reference
이 문제에 관하여(파생개발에 있어서의 변경 지시를 모델로 표현한다(문제편)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/kenjihiranabe/items/293f42ef8b42f437c05e텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)