소프트웨어 디자인을보다 효과적으로 캡처 할 수없는 이유는 무엇입니까? [닫은]

엔지니어로서 우리 모두는 인공물 (건물, 프로그램, 회로, 분자 등)을 "설계"합니다. 그것은 일종의 결과 (디자인 명사)를 생성하는 활동 (디자인 동사)입니다.

우리는 모두 명사 디자인이 인공물 자체와 다른 실체라는 데 동의한다고 생각합니다.

소프트웨어 비즈니스 (실제로 결과 제품 아티팩트를 향상시켜야하는 비즈니스)의 주요 활동은 "디자인 (명사)"을 이해하는 것입니다. 그러나 우리는 커뮤니티로서 사람들이 자신의 코드 기반에 대한 사실을 재발견하기 위해 노력한 노력의 양에 의해 증명되는 것처럼 그것을 기록하는 데 거의 완전히 실패한 것처럼 보입니다. 누군가에게 코드의 디자인을 보여주고 당신이 얻는 것을 보도록 요청하십시오.

소프트웨어 디자인은 다음과 같은 것으로 생각합니다.

• 어떤 소프트웨어에 대한 명시 적 사양은 어떻게해야되고 그리고 그것을 얼마나 잘하는지
• 코드의 명시 적 버전 (이 부분은 간단합니다. 누구나 가지고 있음)
• 코드의 각 부분이 사양을 달성하는 방법에 대한 설명 (예 : 사양 조각과 코드 조각 간의 관계)
• 코드가 왜 그런지에 대한 이론적 근거 (예를 들어, 왜 다른 것이 아닌 특정 선택이되는지)

디자인이 아닌 것은 코드에 대한 특정 관점입니다. 예를 들어 [특별히 선택하지 말 것] UML 다이어그램은 디자인이 아닙니다. 오히려 코드에서 파생 할 수있는 속성이거나 코드에서 파생 할 수있는 속성입니다. 그러나 일반적으로 UML에서 코드를 파생시킬 수는 없습니다.

50 년 이상 소프트웨어를 구축 한 후에 왜 이것을 표현할 수있는 방법이 없습니까? (명백한 예와 저를 모순하지 마십시오!)

우리가 그렇게해도 대부분의 커뮤니티는 디자인 코드를 잃어 버릴 수 있도록 "코드"를 얻는 데 집중하는 것 같습니다. (IMHO, 디자인이 엔지니어링의 목적이 될 때까지 디자인에서 추출 된 아티팩트로이 문제를 해결하지는 않습니다).

디자인을 녹음하는 수단으로 무엇을 보았습니까 (설명한 의미에서)? 논문에 대한 언급은 좋을 것입니다. 구체적이고 일반적인 수단이 성공적이지 않다고 생각하는 이유는 무엇입니까? 이것을 어떻게 바꿀 수 있습니까?

[나는 위의 글 머리 기호 관점을 살려 내 자신의 아이디어 가 있지만 다른 사람들의 답변에 관심이 있습니다 ... 그리고 내 계획을 구현하기가 어렵습니다 [아마도 그게 진짜 문제입니다 :-]]]

2011/1/3 편집 : 답변 스레드 중 하나는 "문서"(특히 텍스트가 아닌 형식 일 수 있음)가 적절할 수 있음을 암시합니다. 나는 이것을 믿지 않는다는 것을 분명히해야한다고 생각합니다. CASE 도구는 80 년대 초반에 등장했지만 초기 도구는 주로 그린 그림에 대한 픽셀 만 캡처했습니다. 이 도구는 상업적으로 성공했지만 실제로는 큰 도움이되지 못했습니다. 추가 "디자인"아티팩트를 공식적으로 해석 할 수없는 경우 심각한 도구 도움말을 얻을 수 없다는 것이 핵심 통찰력이었습니다. 장기적으로 유용한 형태의 디자인 캡처에도 동일한 통찰력이 적용된다고 생각합니다. 공식적인 구조가 없다면 실제로는 사용되지 않습니다. 텍스트 문서는이 테스트에 거의 실패합니다.

나는 우리가 여전히 이것을 잘하지 못하는 몇 가지 이유가 있다고 생각합니다.

1. 소프트웨어는 집과 같았지만 건설 과정과 아이디어를 사용하고 있었지만 오랫동안 사람들. "소프트웨어 아키텍트"는 모든 프로그래머가 원하는 제목이었습니다. 지난 10 년 동안 소프트웨어 아키텍트는 거의 죽었다. 폭포 프로세스에 대한 아이디어는 먼저 소프트웨어가 어떻게 작동하고 보이는지를 말하는 건축가가 있고 사람들이 소프트웨어를 어떻게 구성해야하는지에 대한 다이어그램을 만들고 마지막으로이 멋진 워크 플로우 / UML 다이어그램을 구현하는 코드 원숭이를 스펙에 갖도록하는 아이디어입니다. 이제 널리 퍼졌습니다. 사실, 전체 산업은 40 년 동안 잘못된 길을 걷어차 고있었습니다.

2. 우리가 사용하는 도구는 끊임없이 변화하고 개선합니다. 프로그래밍은 논리적 인 퍼즐이며, 퍼즐을 추상화하고 이해하기 쉽게 만드는 더 나은 아이디어와 기술을 생각해냅니다. 우리가 이것을 모델링하는 방식은 같은 속도로 진화해야하지만 뒤쳐져 있습니다. 프로그래밍 퍼즐을 추상화하는 개선 된 기술은 또한 복잡성을 증가시킬 수 있음을 의미합니다. 우리도 그렇게합니다. 프로그래밍은 항상 프로그래머가 처리 할 수있는 복잡성의 가장자리에 있습니다.

3. 프로그램을 설명하는 방법은 일종의 추상화입니다. 소프트웨어를 추상화하는 좋은 방법을 생각 해낼 수 있다면 추상화를 개발 도구에 직접 넣고 프로그래밍에 또 다른 추상화 / 단순화를 추가 할 수 있습니다. 이것은 여러 번 일어났다. 이러한 추상화의 예는 함수, 클래스 및 라이브러리입니다.

4. 따라서; 소프트웨어 의 성공 적이고 정확한 모델이있는 경우 해당 모델은 소프트웨어 와 동일 합니다. 어느 정도의 노력이 무의미한가하면, 위의 1 점을 확증합니다. 소프트웨어 모델링은 이전에 생각했던 것보다 훨씬 덜 유용합니다. 대신 코드에서 소프트웨어에 대한 데이터를 추출하는 것이 좋습니다. 코드가 실제로 보이는 방식으로 UML 모델을 작성하는 것은 UML 모델을 작성하고 해당 이론적 모델을 구현하는 것보다 훨씬 더 밝습니다.

소프트웨어 추적 성 문서를 검토하는 데 관심이있을 수 있습니다. 특별한 순서는 없습니다 :

• CUBRANIC, D., MURPHY, GC, SINGER, J. 및 BOOTH KELLOGG, S. Hipikat : 소프트웨어 개발을위한 프로젝트 메모리. 소프트웨어 공학 관련 거래 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I. 및 HAN, J. 건축 설계 근거의 사용 및 문서화에 대한 조사. 소프트웨어 아키텍처에 관한 제 5 회 작업 IEEE / IFIP 컨퍼런스 (2005)의 절차.
• RAMESH, B., POWERS, T., STUBBS, C. 및 EDWARDS, M. 구현 요구 사항 추적 성 : 사례 연구. 요구 공학에 관한 국제 증상의 절차 (York, 1995).
• HORNER, J. 및 ATWOOD, ME 설계 이론적 근거 : 이론적 근거와 장벽. 인간-컴퓨터 상호 작용에 관한 제 4 차 북유럽 회의 : 역할 변경 (Progress of Changes Roles)에서 발췌 (Oslo, Norway, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B. 및 CLARK, S. 자동화 된 추적 성을위한 모범 사례. 컴퓨터 40, 6 (2007 년 6 월), 27–35.
• ASUNCION, H., FRANÇOIS, F. 및 TAYLOR, RN 엔드 투 엔드 산업 소프트웨어 추적 도구입니다. 유럽 ​​소프트웨어 Eng Conf의 6 차 공동 회의와 소프트웨어 공학 기초 (ESEC / FSE)에 관한 ACM SIGSOFT 국제 증상의 진행 (Dubrovnik, 2007).

이것은 빙산의 일각 일 뿐이며, 몇 가지 주요 논문은 생략했습니다.

별도의 메모에서, Arcum에 대한 저 자신의 작업은 프로그래머가 크로스 컷팅 디자인 관용구를 IDE에 표현하는 수단이었습니다. 일단 표현되면 프로그래머는 대체 구현을 사용하도록 소스 코드를 변환 할 수 있습니다.

• Macneil Shonle, William G. Griswold 및 Sorin Lerner. 리팩토링을 넘어서 : 크로스 컷팅 디자인 관용구의 모듈 식 유지 보수를위한 프레임 워크 . 유럽 ​​소프트웨어 엔지니어링 컨퍼런스의 6 차 공동 회의 및 소프트웨어 엔지니어링 기초에 관한 ACM SIGSOFT 심포지엄 진행 (ESEC-FSE '07; 2007 년 9 월 3-7 일). 175-184.

또한 Arcum은 DMS 작업과 관련이 있습니다.

UML은 내 계획에 따라 계획을 세우는 프로그램입니다. 계획만으로는 설계가 아닌 것이기 때문에 건물의 일반적인 견해 (GUI 디자인을 포함한 전체 소프트웨어의 개략적 인 표현), 건물이 주변에 심어진 방법에 대한 재료 사양 (사용되는 코드 도구)이 필요합니다 (소프트웨어가 다른 사람들과 상호 작용하는 방법 / OS 내에 심어 져있는 방법에 대한 명확한 계획, 소프트웨어가 기후와 토양에 어떻게 영향을 미치는지 (하드웨어와의 상호 작용)) ... 디자인에 관한 많은 책들이 그것을 정의하려고 시도하지만, 마찬가지로 과학의 많은 것들, 모든 과학자는 자신의 정의를 조금 가지고 있습니다.

이제 UML에서 코드를 파생시킬 수 없다는 관찰에도 동의하지 않습니다. 언급 된 추가 정보가있는 경우 가능합니다. 그러나 실제 코드는 더 이상 디자인이 아니라 아티팩트입니다. 계획에서 실제 석재와 콘크리트를 추출 할 수는 없지만 실제 석재와 콘크리트를 올바른 형태와 올바른 장소에 배치 할 계획이 필요합니다.

그 점에서 다음 기사가 흥미로 웠습니다 (그래프 소프트웨어를 찾을 때 다른 맥락에서 만났지만 그럼에도 불구하고 ...). 디자인을 설명하는 그래프 접근법은 나에게 의미가 있지만, 이것은 내 의견으로는 디자인의 일부일뿐입니다. 흥미로운 점은이 백서에서 다음과 같이 소프트웨어를 리팩터링하는 대신 디자인을 이해하고 리팩토링 할 수있는 프레임 워크를 제공한다는 점입니다.

• 베르 멜링 거와 피아 데이로

• Tsantalis et al

구조적 설계 (HIPO 차트) 또는 통합 프로그램 설계 , 설계 패턴 등과 같이 설계를 설명하는 다른 많은 접근 방법이 있습니다 .

그러나 업계 표준 세트가없는 한 이것을 표현하는 "일반적인"방법을 찾지 못할 것입니다. 50 년 이상이 지난 후에도 그리고 회사가 디자인을 표현할 수있는 좋은 방법을 찾으면 세상과 공유 하시겠습니까?

나는 개인적인 경험을 통해 소프트웨어 디자인을 잘 포착했다고 주장합니다. 우리는 플랫폼에서 구현 한 모든 단일 기능에 대한 요구 사항 및 설계 문서 데이터베이스를 보유하고 있습니다. 내 상황이 독특하다고 생각합니다. 다음은 몇 가지 고려해야 할 사항입니다.

우리 팀의 모든 사람은 공학 학위를 가지고 있습니다. 공학은 커리큘럼의 일부로 디자인을 가르칩니다.

CS 배경에서 온 소위 소프트웨어 엔지니어가 많이 있다고 생각합니다. 소프트웨어 디자인은 대부분의 CS 프로그램에서 없어서는 안될 부분입니다. 나는 모든 CS 전공이 디자인에 좋지 않다고 말하지는 않지만, 대부분의 CS 전공이 그것을 가르친 공식적인 교육이 없다는 것을 베풀 것입니다. 많은 사람들이 소프트웨어를 설계 할 수있는 프로그램을 작성할 수 있다면 사실이 아니라고 생각합니다. 많은 프로그래머가 엔지니어링 배경을 가지고 있지 않다는 점을 감안할 때 많은 소프트웨어 프로젝트에 디자인 캡처에 능숙한 팀이 없다는 것은 놀라운 일이 아닙니다.

두 가지 문제가 있습니다.

첫 번째는 코드와 문서를 동기화하기가 어렵습니다. 그것들이 분리되면, 그들은 갈라질 것이고 문서는 쓸모 없게 될 것입니다. 프로그래머는 도구를 사용하여 동기화를 유지하는 작업 (예 : CASE 도구)을 수행하려고 시도했지만 이러한 도구는 프로그래머와 해당 코드 사이에있어 좋은 것보다 더 많은 손상을 입었습니다. 도메인 기반 디자인 (Evans, 2004)의 주요 통찰력 중 하나는 훌륭한 디자인이 실제로 어렵다는 것입니다. 따라서 무언가를 꺼내려면 다음을 수행해야합니다.

• 좋은 디자인이 큰 이점을 제공하는 프로그램의 가장 작은 영역을 선택하십시오.
• 모든 팀원이 항상 사용하는 유비쿼터스 언어의 형태로 좋은 디자인을 얻기 위해 열심히 노력하십시오.
• 가능한 한 디자인을 코드의 일부로 만드십시오.

우리가 디자인하는 방식의 또 다른 큰 문제는 디자인 방법이 수학적으로 충분하지 않다는 것입니다. 누수가있는 추상화는 그들로부터 확실한 결론을 도출하기에 적합하지 않으며, 엄격하게 적용되는 논리와 분명한 진실의 세계를 프로그래머라고 부릅니다.

공식적인 방법과 같이 우리가 가진 몇 가지 수학적 도구는 다루기 힘들다.

맵 축소는 프로그래밍에서 수학의 좋은 예입니다. 핵심 아이디어는 다음과 같습니다. 연관 이진 연산이있을 때 실행을 매우 쉽게 배포 할 수 있습니다. 이항 연산은 두 개의 매개 변수가있는 함수입니다. 연관성은 (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99는

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) As, B 및 C는 다른 위치에 사소하게 추가 될 수 있으며 결과는 수집됩니다 그리고 곧 요약했다.

지도 축소는 말도 안되는 간단한 아이디어입니다. 한 장의 종이에 설명 할 수 있습니다. 독자가 연관성 개념에 대해 잘 알고 있다고 가정 할 수 있다면, 아주 작은 종이에 적합하다면 말입니다. 이제 연관성이라는 용어를 사용하거나 간접적으로 언급하지 않고 누군가에게 map-reduce를 설명하십시오. 감히

수학적 추상화가없는 소프트웨어 디자인은 지오메트리를 배우지 않고 아키텍처를 시도하는 것과 같습니다.

아마도 Haskell은이 문제를 시간이지나면서 해결할 수 있습니다. 프로그램을 설명하기 위해 범주 이론의 개념을 사용하는 것은 나에게 유망 해 보인다. 범주 이론은 너무 추상적이기 때문에 수학자조차도 거의 사용하지 않았지만, 인식을 넘어서 추상적 인 범주는 소프트웨어의 구조를 설명하기에 충분히 추상적 인 것 같습니다. 우리는 알아낼 것입니다. 천천히.