계약에 의한 설계

Design by contract
계약 방식에 의한 설계

계약에 의한 설계(Design by contract)는 계약 프로그래밍, 계약에 의한 프로그래밍계약별 설계 프로그래밍이라고도 하며 소프트웨어를 설계하기 위한 접근법입니다.

소프트웨어 설계자는 소프트웨어 컴포넌트에 대해 형식적이고 정밀하며 검증 가능한 인터페이스 규격을 정의해야 한다고 규정하고 있으며, 이는 전제조건, 사후조건불변성함께 추상 데이터 유형의 일반적인 정의를 확장한다.이러한 사양은 사업 계약의 조건과 의무에 대한 개념적 비유에 따라 "계약"이라고 한다.

DbC 접근법서버 구성요소에서 작업을 호출하는 모든 클라이언트 구성요소가 해당 작업에 필요한 전제 조건을 충족한다고 가정합니다.

이 가정이 너무 위험하다고 생각되는 경우(멀티채널 또는 분산 컴퓨팅과 마찬가지로)에는 역접근법이 사용됩니다.즉, 서버 컴포넌트는 관련된 모든 전제조건이 참임을 테스트하고(클라이언트컴포넌트의 요구를 처리하기 전 또는 처리하는 동안), 그렇지 않은 경우 적절한 오류 메시지로 응답합니다.

역사

이 용어는 베르트랑 마이어가 에펠 프로그래밍 언어의 설계와 관련하여 만든 것으로 1986년부터[1][2][3] 시작된 다양한 기사와 그의 책 객체 지향 소프트웨어 구축의 두 연속판(1988, 1997년)에서 처음 설명되었습니다.에펠소프트웨어는 2003년 12월 도급설계 상표등록을 출원해 2004년 [4][5]12월 허가를 받았다.이 상표의 현재 소유자는 에펠 소프트웨어입니다.[6][7]

계약에 의한 설계는 공식 검증, 공식 사양Hoare 로직 작업에 뿌리를 두고 있습니다.최초 기여는 다음과 같습니다.

묘사

DbC의 중심 아이디어는 소프트웨어 시스템의 요소들이 상호 의무이익을 기반으로 서로 어떻게 협업하는지에 대한 비유입니다.이 비유는 "고객"과 "공급업체"가 다음을 정의하는 "계약"에 동의하는 비즈니스 라이프에서 유래합니다.

  • 공급업체는 특정 제품(의무)을 제공해야 하며 고객이 수수료(혜택)를 지불했다고 기대할 수 있습니다.
  • 고객은 수수료(의무)를 지불해야 하며, 제품을 받을 수 있는 권리(혜택)가 있습니다.
  • 양 당사자는 모든 계약에 적용되는 법률 및 규정 등의 특정 의무를 충족해야 합니다.

마찬가지로 객체 지향 프로그래밍에서 클래스의 메서드가 특정 기능을 제공하는 경우 다음과 같이 할 수 있습니다.

  • 어떤 조건을 호출하는 클라이언트 모듈에 의해 입력 시 보증될 것으로 예상합니다.즉, 클라이언트에 대한 의무와 공급업체(방법 자체)에 대한 이점입니다.이러한 조건을 호출하면 전제 조건 이외의 사례를 처리할 필요가 없어지기 때문입니다.
  • 종료 시 특정 자산 보증: 방법의 사후 조건, 즉 공급업체에 대한 의무, 그리고 분명히 클라이언트에 대한 이점(메서드를 호출함으로써 얻는 주요 이점)
  • 입력 시 가정하고 종료 시 보장되는 특정 속성(클래스 불변)을 유지합니다.

그 계약은 의무를 공식화하는 호어 트리플과 의미상 동등하다.이는 설계자가 계약에서 반복적으로 답변해야 하는 "세 가지 질문"으로 요약할 수 있습니다.

  • 계약서에는 어떤 내용이 있습니까?
  • 그 계약은 무엇을 보장합니까?
  • 그 계약은 무엇을 유지합니까?

많은 프로그래밍 언어에는 다음과 같은 주장을 할 수 있는 기능이 있습니다.그러나 DBC는 이러한 계약이 소프트웨어의 정확성에 매우 중요하기 때문에 설계 프로세스의 일부가 되어야 한다고 생각합니다.실제로 DbC는 먼저 [citation needed]어설션을 작성하는 것을 지지합니다.계약에 대한 특별한 언어 지원이 없는 경우에도 계약은 코드 코멘트로 작성하거나 테스트 스위트에 의해 시행하거나 둘 다 작성할 수 있습니다.

계약의 개념은 방법/절차 수준까지 확장된다. 각 방법에 대한 계약은 일반적으로 다음과 [citation needed]같은 정보를 포함한다.

  • 허용 가능한 입력값 또는 유형 및 그 의미
  • 값 또는 유형 및 그 의미를 반환합니다.
  • 발생할 수 있는 오류 및 예외 조건 값 또는 유형 및 그 의미
  • 부작용
  • 전제 조건
  • 사후 조건
  • 불변량
  • (더 드물게) 퍼포먼스 보증(사용시간이나 공간 등)

상속 계층의 하위 계층은 전제 조건을 약화시키고(강화하지 않음), 사후 조건과 불변성을 강화하도록 허용된다(그러나 약화시키지 않음).이러한 규칙은 행동 서브타이핑에 가깝습니다.

모든 클래스 관계는 클라이언트 클래스와 공급업체 클래스 사이에 있습니다.클라이언트 클래스는 공급자의 상태가 클라이언트 콜에 의해 위반되지 않는 경우 공급자의 기능에 콜을 발신할 의무가 있습니다.이후 공급업체는 고객의 상태 요구사항을 위반하지 않는 반품 상태와 데이터를 제공할 의무가 있습니다.

예를 들어, 공급업체 데이터 버퍼는 삭제 기능이 호출될 때 버퍼에 데이터가 존재하도록 요구할 수 있습니다.그 후 공급업체는 삭제 기능이 작업을 완료하면 데이터 항목이 실제로 버퍼에서 삭제됨을 클라이언트에 보증합니다.다른 설계계약은 클래스 불변성의 개념이다.클래스 불변성은 각 기능 실행 종료 시 클래스 상태가 지정된 허용 범위 내에서 유지됨을 보증합니다.

계약을 사용할 때 공급업체는 계약 조건이 충족되는지(공격적 프로그래밍으로 알려진 관행) 확인하려고 해서는 안 된다. 일반적으로 코드는 "고장"되어야 하며 계약 검증은 안전망이다.

DbC의 "fail hard" 속성은 각 메서드의 의도된 동작이 명확하게 지정되므로 계약 동작의 디버깅을 단순화합니다.

이 접근방식은 공급자가 전제조건이 깨졌을 때 무엇을 해야 할지를 결정하는 방어적 프로그래밍의 접근방식과는 크게 다릅니다.공급업체는 대부분의 경우 고객에게 전제 조건이 깨졌음을 알리기 위해 예외를 발생시킵니다. 두 경우 모두(DbC와 방어 프로그래밍 모두) 클라이언트는 이에 대응하는 방법을 찾아야 합니다.이러한 경우, DbC는 공급업체의 작업을 더 쉽게 합니다.

계약에 의한 설계에서는 소프트웨어 모듈의 정확성 기준도 정의합니다.

  • 공급업체가 클라이언트에 의해 호출되기 전에 클래스 불변 AND 전제 조건이 참이면 서비스가 완료된 후 불변 AND 전제 조건이 참이 됩니다.
  • 공급업체에 문의할 때 소프트웨어 모듈은 공급업체의 전제 조건을 위반해서는 안 됩니다.

각 코드에 대한 계약이 완전히 문서화되어 있기 때문에 계약에 따른 코드 재사용도 용이합니다.모듈 계약은 모듈 동작에 관한 소프트웨어 문서의 한 형태로 간주할 수 있습니다.

퍼포먼스에 미치는 영향

버그 프리 프로그램을 실행하는 동안 계약 조건을 위반해서는 안 됩니다.따라서 일반적으로 계약은 소프트웨어 개발 중에 디버깅모드로만 체크됩니다.나중에 출시될 때 성능을 최대화하기 위해 계약 체크를 사용할 수 없습니다.

많은 프로그래밍 언어에서 계약은 단언과 함께 구현됩니다.Assert는 디폴트로 C/C++ 릴리스 모드로 컴파일되어 C#[8] 및 Java에서 마찬가지로 비활성화됩니다.

인수로 "-O"("최적화")를 사용하여 Python 인터프리터를 실행해도 마찬가지로 [9]Python 코드 생성기가 Assert의 바이트 코드를 내보내지 않습니다.

이것은 개발에서 사용된 어설트의 수와 계산 비용에 관계 없이 생산 코드에서 어설트의 런타임 비용을 효과적으로 제거하는데, 이는 그러한 명령이 컴파일러에 의해 생산에 포함되지 않기 때문이다.

소프트웨어 테스트와의 관계

계약에 의한 설계는 유닛 테스트, 통합 테스트, 시스템 테스트 등의 정기적인 테스트 전략을 대체하는 것은 아닙니다.오히려 격리 테스트와 테스트 단계 중 프로덕션 코드 모두에서 활성화될 수 있는 내부 자가 테스트로 외부 테스트를 보완합니다.

내부 자가 테스트의 장점은 클라이언트가 관찰한 잘못된 결과로 나타나기 전에 오류를 감지할 수 있다는 것입니다.이것에 의해, 보다 빠르고 구체적인 에러 검출이 가능하게 됩니다.

어설션의 사용은 계약 이행에 의한 설계 테스트 방법인 테스트 오라클의 한 형태로 간주할 수 있다.

언어 지원

네이티브 지원 언어

대부분의 DbC 기능을 기본적으로 구현하는 언어는 다음과 같습니다.

또한 Common Lisp Object System의 표준 메서드 조합에는 메서드 한정자가 있습니다.:before,:after그리고.:around계약서 작성을 보조적인 방법으로 허용한다.

서드파티를 지원하는 언어

다양한 라이브러리, 프리프로세서 및 기타 툴이 계약 지원에 의해 네이티브 설계 없이 기존 프로그래밍 언어용으로 개발되었습니다.

「 」를 참조해 주세요.

메모들

  1. ^ 마이어, 베르트랑:계약에 의한 설계, 기술 보고서 TR-EI-12/CO, Interactive Software Engineering Inc, 1986.
  2. ^ 마이어, 베르트랑:계약에 의한 설계, 객체 지향 소프트웨어 엔지니어링의 진보, eds.D. 만드리올리와 B.마이어, 프렌티스 홀, 1991, 1~50페이지
  3. ^ 마이어, 베르트랑:컴퓨터(IEEE), 25, 10, 1992년 10월, 페이지 40-51의 "계약에 의한 설계" 적용, 온라인에서도 이용 가능
  4. ^ "United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"". Archived from the original on 2016-12-21. Retrieved 2009-06-22.
  5. ^ "United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"". Archived from the original on 2016-12-21. Retrieved 2009-06-22.
  6. ^ "Trademark Status & Document Retrieval". tarr.uspto.gov.
  7. ^ "Trademark Status & Document Retrieval". tarr.uspto.gov.
  8. ^ "Assertions in Managed Code". msdn.microsoft.com.
  9. ^ 공식 Python Docs, assert 스테이트먼트
  10. ^ Bright, Walter (2014-11-01). "D Programming Language, Contract Programming". Digital Mars. Retrieved 2014-11-10.
  11. ^ Hodges, Nick. "Write Cleaner, Higher Quality Code with Class Contracts in Delphi Prism". Embarcadero Technologies. Retrieved 20 January 2016.
  12. ^ Findler, Felleisen 고차 기능 계약
  13. ^ "Scala Standard Library Docs - Assertions". EPFL. Retrieved 2019-05-24.
  14. ^ Scala의 또 다른 "계약 강제"로서의 강력한 입력 scala-lang.org/에서 논의하십시오.
  15. ^ "Code Contracts". msdn.microsoft.com.
  16. ^ "Bean Validation specification". beanvalidation.org.
  17. ^ "Software Testing Help from the Experts Parasoft Resources" (PDF).
  18. ^ "Archived copy" (PDF). Archived from the original (PDF) on 2016-03-28. Retrieved 2016-03-25.{{cite web}}: CS1 maint: 타이틀로서의 아카이브 카피(링크) 페이지 2
  19. ^ "No chance of releasing under Apache/Eclipse/MIT/BSD license? · Issue #5 · nhatminhle/cofoja". GitHub.

참고 문헌

  • Mitchell, Richard 및 McKim, Jim: Design by Contract: 예를 들어 Addison-Wesley, 2002
  • DBC를 원래 모델에 가깝게 기술한 위키북입니다.
  • McNeile, Ashley: 행동 계약의미에 대한 프레임워크.행동 모델링에 관한 제2차 국제 워크숍의 진행 상황:기초 및 응용 프로그램(BM-FA '10).ACM, 뉴욕, 뉴욕, 미국, 2010.이 문서에서는 계약과 대체 가능성에 대한 일반적인 개념을 설명합니다.

외부 링크