1 / 25

Chap 11 Operation Contracts

Chap 11 Operation Contracts. Objectives. Create contracts for system operations. use cases. domain model. interaction diagrams. design class diagrams. use case diagram. use case scenario. system sequence diagram. operational contract. 소개. 유즈케이스나 시스템 피쳐만으로도 시스템의 행위를 충분히 기술할 수 있다 .

toshi
Download Presentation

Chap 11 Operation Contracts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chap 11 Operation Contracts

  2. Objectives Create contracts for system operations. use cases domain model interaction diagrams design class diagrams use case diagram use case scenario system sequence diagram operational contract 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  3. 소개 • 유즈케이스나 시스템 피쳐만으로도 시스템의 행위를 충분히 기술할 수 있다. • 시스템의 행위: 하는 방법이 아닌 해야 할 일을 의미 • 시스템이 행위를 좀더 구체적이고 정교하게 기술할 필요가 있을 때 시스템 약정을 기술한다. • 유즈케이스의 일부분 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  4. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  5. 11.1 예제: enterItem Operation: enterItem(itemID : ItemID, quantity : integer) Cross References: Use Cases: Process Sale Preconditions: There is a Sale Underway. Postconditions: -A SalesLineItem instance sli was created (instance creation)-sli was associated with the current Sale (association formed)-sli.quantity became quantity (attribute modification)-sli was associated with a ProductSpecification, based on itemID match (association formed) Contract CO2: enterItem 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  6. 11.2 약정의 명세 항목 Operation: Name Of operation, and parameters. Cross References: (optional) Use cases this can occur within. Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. Postconditions: -The state of objects in the Domain Model after completion of the operation. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  7. 11.3 System Operations and the System Interface • 약정은 시스템 오퍼레이션에 대하여 정의될 수 있다. • 시스템 오퍼레이션 • 발생되는 시스템이벤트를 처리하기 위하여 시스템을 블랙 박스로 가정하고 제공하는 오퍼레이션 • 시스템오퍼레이션은 시스템 이벤트를 찾아냄으로써 식별된다. • 시스템 인터페이스 • 모든 유즈케이스에 대하여 시스템 오퍼레이션을 모으면 그것이 시스템 인터페이스가 된다. Usecase Scenario System Sequence Diagram Usecase Diagram 1 1 1 n 1 n Operations Contracts 1 1 System Operations 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  8. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  9. 11.4 사후 조건의 정의 • The postconditions describe changes in the state of objects in the Domain Model. • Domain Model state changes include • instances created, • associations formed or broken, • and attributes changed. • Postconditions are • not actions to be performed, during the operation; • rather, they are declarations about the Domain Model objects that are true when the operation has finished. • Postconditions are related to the domain model • An advantage of Postconditions • One can focus on what must happen • More level of details about requirement 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  10. 사후 조건을 기술하는 방법 • 액션이 아니라 관찰이라는 것을 강조하기 위하여 과거 시세를 사용 • (better) A SalesLineItem was created. • (worse) Create a SalesLineItem. • The Stage and Curtain • Think about postconditions using the following image • The system and it’s objects are presented on a theatre stage. • Before the operation, take a picture of the stage. • Close the curtains on the stage, and apply the system operation • Open the curtains and take a second picture. • Compare the before and after pictures, and express as postconditions the changes in the state of the stage (A SalesLineItem was created…). 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  11. If contracts are used, how complete should Postconditions be? • Contracts may not be needed • Some contracts are desired • Even if incomplete, Early creation is better • Iterative development 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  12. 11.5 예제: EnterItem 사후조건 • instances created • SalesLineItem 인스턴스 sli의 생성 • and attributes changed. • sli.quantity가 quantity로 변경 • associations formed or broken • sli가 현재의 Sale과 연관 • sli가 자신과 itemID 값이 일치하는ProductDescription과 연관 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  13. 11.6 가이드라인: 도메인 모델의 갱신 • New conceptual classes, attributes, or associations in the Domain Model are often discovered during contract writing. • Enhance the Domain Model as you make new discoveries while thinking through the operation contracts. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  14. 11.7 가이드라인: 언제 약정이 유용한가 • 세부적인 상태의 변화를 기술로유즈케이스가 복잡해 지는 경우 • 예. addNewReservation • 유즈케이스로 앞으로 무엇을 해야 하는가를 충분이 나타낼 수 있는 경우에는 약정을 기술할 필요가 없다. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  15. 11.8 가이드라인: 약정의 작성 순서 • 작성단계 • SSD에서 시스템 오퍼레이션 식별 • 유즈케이스로 충분하지 않는 경우 오퍼레이션에 대하여 약정 작성 • 사후조건 작성법 • 인스턴스의 생성과 삭제 • 속성 변경 • 연관 형성과 해제(흔히 실수함) 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  16. 11.9 NextGen POS Example: Contracts • ProcessSale 유즈케이스의 시스템 오퍼레이션 • 만들기는 했으나 그다지 복잡하지 않으므로 이 약정은 필요 없다. • 가치가 있는 것을 약정으로 작성해야 함 Contract CO1: makeNewSale Operation: makeNewSale() Cross References: Use Cases: Process Sale Preconditions: none Postconditions: - A Sale instance s was created(instance creation). - s was associated with the Register(association formed). - Attributes of s were initialized. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  17. Contract CO2: enterItem Operation: enterItem(itemID: ItemID, quantity: integer) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway. Postconditions: - A SalesLineItem instance sli was created(instance creation). - sli was associated with the current Sale(association formed). - sli.quantity became quantity(attribute modification). - sli was associated with a ProductSpecification, based on itemID match(association formed). Contract CO3: endSale Operation: endSale() Cross References: Use Cases: Process Sale Preconditions: There is a sale underway. Postconditions: - Sale.isComplete became true(attribute modification). 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  18. Contract CO4: makePayment Operation: makePayment(amount: Money) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway. Postconditions: - A Payment instance p was created(instance creation). - p.amountTendered became amount(attribute modification). - p was associated with the current Sale(association formed). - The current Sale was associated with the Store(association formed to add it to the historical log of completed sales) 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  19. 도메인 모델의 변경 • 도메인 모델에 판매 완료에 대한 표현이 없다는 사실을 약정에서 발견 •  도메인 모델의 개선 Sale isComplete:Boolean dateTime 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  20. 11.11 UML의 적용: 오퍼레이션, 약정 및 OCL • 오퍼레이션(Operation) • 오퍼레이션이란 실행하기 위해 객체가 호출될 수 있는 변환이나 질의에 대한 명세이다. [RJB99] • An operation is an abstraction, not an implementation. • 메소드 • 메소드는 오퍼레이션에 대한 구현이다. 메소드는 오퍼레이션과 연관된 알고리즘 또는 절차를 명세한다. [OMG03a] • UML에서는 사전조건과 사후조건 형태로 명세할 수 있는 제약사항들을 이용하여 오퍼레이션의 의미를 정의 • A UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  21. OCL로 표현되는 오퍼레이션 약정 • Associated with the UML is a formal language called the Object Constraint Language (OCL) [WK99], which can be used to express constraints in models. • The OCL defines an official format for specifying pre- and postconditions for operations, as demonstrated here:System::makeNewSale() pre: <statements in OCL> post: … • Keep things simple and use natural language instead of OCL • Come from formal specification languages • Some languages, such as Eiffel, have first-class support for invariants and pre- and postconditions. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  22. 11.12 Operation Contracts Within the UP • A pre- and postcondition contract is a well-known style to specify an operation. • Phases • Inception • Contracts are not needed during inception • they are too detailed. • Elaboration • Most contracts will be written during elaboration, when most use cases are written. • Only write contracts for the most complex and subtle system operations. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  23. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  24. Summary • Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model after a system operation. • Contracts have sections of • Operations, • Cross references, • Preconditions and Postconditions. • Postconditions are the most important section. • Postconditions describe changes in the state of objects in the Domain Model. • Domain Model state changes include • instances created, • associations formed or broken, • and attributes changed. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

  25. Summary • Writing Contracts leads to Domain Model updates. • In UML, an operation is a specification of a transformation or query that an object may be called to execute. • Most contracts will be written during elaboration, when most use cases are written. Only write contracts for the most difficult to understand or complicated system operations. 금오공과대학 컴퓨터공학부 컴퓨터공학전공

More Related