시스템 순차도

시스템순차도 (SSD) 1

1 소개 시스템순차도 (SSD: System Sequence Diagram) 구현하고자하는소프트웨어시스템을블랙박스로놓고액터와시스템간의행위를순차도로기술 쓰임새의한시나리오에대해서외부액터가발생하는사건및그순서그리고시스템간의사건을보여줌. 개발하고자하는시스템의입력과출력이벤트를알기쉽게표현 빠르고쉽게생성되는산출물임 유스케이스로부터 UML 순차도를이용하여정형화 시스템은하나의블랙박스로표현 ( 단하나의객체 ) 시스템과액터간의사건에중점을둠. SSD 의목적 - 정형화 시스템연산 ( 액터가시스템에요구하는연산 ) 의도출목적 유스케이스의정형화된모델 : 더나은이해및구현에근접해가는단계 2

SSD 의목적 : UP 산출물관계의예 Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use - Case Model Vision Process Sale Require - ments Cashier Process Sale Use Case Diagram use case names 1. Customer arrives... 2. Cashier makes new sale. 3.... Use Case Text system events Glossary parameters and return value details : System Operation : enteritem ( ) Post - conditions : -... system operations : Cashier make NewSale () enteritem ( id, quantity ) Supplementary Specification Operation Contracts System Sequence Diagrams starting events to design for : Register Design Model : ProductCatalog : Sale Design enteritem ( itemid, quantity ) spec = getproductspec ( itemid ) addlineitem ( spec, quantity ) 3

예 ) NextGen SSD system as black box the name could be "NextGenPOS" but "System" keeps it simple the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML external actor to system Process Sale Scenario : Cashier :System makenewsale a UML loop interaction frame, with a boolean guard expression loop [ more items ] enteritem(itemid, quantity) description, total return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned endsale total with taxes makepayment(amount) change due, receipt a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism 4

3 Why SSD? 소프트웨어시스템에대한사건 (Event) 외부액터가발생시키는사건 ( 마우스, 키보드등 ) 타이머사건 ( 자발적사건 ) 오류또는예외사건 외부에서입력되는사건을식별하기위함 시스템을하나의객체로생각 사건은곧객체가제공해야할연산임. 시스템행위를기술 시스템이어떻게동작하는지를설명하지않고무엇을하는지에초점을둔설명 5

3. UML 의적용 : 순차도 시스템을하나의객체로두고액터와시스템객체간의순차도작성 UML 순차도 : 별도설명 6

5 SSD 와 UC 의관계 UC 의한특정시나리오를정형화하여기술한것이 SSD 이다. Process Sale Scenario : Cashier :System Simple cash-only Process Sale scenario: makenewsale 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment.... loop [ more items ] enteritem(itemid, quantity) description, total endsale total with taxes makepayment(amount) change due, receipt 7

6 시스템이벤트와오퍼레이션은어떻게명명하는가? Which is better? 방법보다는의도를표현하라. (What, rather than how) 동사로표현하라. enter, add, make, better name : Cashier enteritem(itemid, quantity) :System scan(itemid, quantity) worse name 8

7 다른외부시스템과관련된 SSD 의모델링 예 ) NextGen POS 와외부의신용지불인증시스템사이의시나리오 역시 SSD로기술한다. 프로토콜기술하는것과동일하다. 정보의내용및정보의전달순서를기술 ( 복잡할경우상태도를이용 ) 9

8 SSD 로부터용어집에추가될부분은? SSD 에나타난요소들을추가 오퍼레이션이름, 매개변수, 반환데이터 예 ) change due, receipt 에대한자세한설명 10

10 SSD 작업프로세스 : 반복적이며진화적으로! 몇개의선택된시나리오에대해서만 SSD 작성 (30 분이내 ) 액터와시스템외에도기존시스템과시스템간의협력관계또는구조를이해시킬때도유용하게활용 UP 에서 SSD 를사용하는경우 SSD 는 UP 에서잘사용하지않으나실무적으로유용함이입증 대부분의 SSD 는정련단계에서작성됨 도입부에서는작성되지않음 기능점수나 COCOMO II 에서의추정을위해하지않은한! 정련단계 : SSD 작성 시스템약정작성 11

UC 구체화 : 오퍼레이션약정 (Operation Contracts)

Objectives 시스템오퍼래이션을위한 약정 (contracts) 만들기. 시스템오퍼레이션을정의한다. (= 시스템객체의메소드 ) 시스템오퍼레이션에대한약정을생성한다. 오퍼래이션의약정 (contract) 은시스템의행위를정의하는데사용된다. 약정 (contract) 은도메인오브젝트의상태변화에관하여시스템오퍼래이션수행의결과를설명한다. 13

유스케이스모델의구체화 Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use-Case Model Vision the domain objects, attributes, and associations that undergo changes Requirements Cashier Process Sale Use Case Diagram Operation: enteritem( ) Post-conditions: -... ideas for the postconditions use case names system operations : Cashier Process Sale 1. Customer arrives... 2.... 3. Cashier enters item identifier. Use Case Text system events make NewSale() enteritem (id, quantity) : System requirements that must be satisfied by the software Glossary Supplementary Specification starting events to design for, and more detailed requirements that must be satisfied by the software Design Operation Contracts enteritem (itemid, quantity) : Register System Sequence Diagrams Design Model spec = getproductspec( itemid ) : ProductCatalog : Sale addlineitem( spec, quantity ) 14

1. 예 : 판매 유스케이스에대한하나의 SSD UP 에서시스템의행위는기본적으로 Use Cases 로정의하지만, 시스템오퍼래이션이수행된후에도메인모델의상태변화와관련한시스템의행위를 Contracts 를통해서좀더자세히정의할수도있다. : Cashier Process Sale Scenario makenewsale() :System loop [ more items ] enteritem(itemid, quantity) these input system events invoke system operations description, total the system event enteritem invokes a system operation called enteritem and so forth endsale() total with taxes this is the same as in objectoriented programming when we say the message foo invokes the method (handling operation) foo makepayment(amount) change due, receipt 15

1. 시스템오퍼레이션 ( 연산 ) 및시스템인터페이스 Contracts 는시스템오퍼래이션 ( 시스템을블랙박스형태로간주했을때의오퍼래이션 ) 을정의할수있다. (OOP 의 ADT 의정의와유사 ) 시스템에대한이벤트 ( 객체지향에서는메소드, 메시지를의미 ) 시스템인터페이스라고도함. : Cashier Process Sale Scenario :System 시스템객체의연산 ( 오퍼레이션 ) makenewsale() loop [ more items ] enteritem(itemid, quantity) these input system events invoke system operations description, total the system event enteritem invokes a system operation called enteritem and so forth endsale() total with taxes this is the same as in objectoriented programming when we say the message foo invokes the method (handling operation) foo makepayment(amount) change due, receipt 16

약정 (Contract) 의예 : enteritem() 약정 CO2: enteritem Operation: enteritem(itemid: ItemID, quantity: integer) Cross References: Use Cases: Process Sale Preconditions: 판매가진행중이다. Postconditions: - 한 SalesLineItem 인스턴스 sli 가생성되었다. - sli 가현재의 Sale 인스턴스 current와연관되었다. - sli.quantity 가입력된 quantity값으로변경되었다. - sli 가 ItemID로찾아진 ProductSpecification와연관되었다. enteritem(itemid, quantity) :System current: Sale sli:saleslineitem :ProductSpecification /quanty := quantity id := itemid; 17

2. 약정 의각부분의의미 오퍼레이션 : 상호참조 : 사전조건 : 사후조건 : 오퍼래이션이름과매개변수 ( 선택적 ) 이오퍼래이션이나타나는유스케이스오퍼래이션이수행되기전에도메인모델에시스템혹은오브젝트의상태에관한주목할만한가정 (assumptions). 오퍼래이션로직내부에서는테스트되지않고, 참이라고가정한다. 오퍼래이션이수행된후에도메인모델에서오브젝트의상태. 다음섹션에서보다자세히이야기한다. 18

4. 사후조건 사후조건은도메인모델에서오브젝트의상태변화를표현한다. 사후조건은오퍼래이션수행도중의행위 (action) 이아니다. 범주 : 인스턴스생성과소멸. 속성변경. 연관관계맺기와끊기. 사후조건은도메인모델에관계가있다. 19

사전조건 : Analytical Detail 약정 (contracts) 은시스템오퍼래이션의상태변화를설명하는요구사항분석을위한효과적인도구. How 가아닌 what 을기술. 물론유스케이스에기술하는것도가능하지만, 이것은유스케이스를지저분하게만들수있으므로조심해야한다. 20

사후조건의철학 : The Stage and Curtain 과거의상태변화를설명해야하기때문에과거시제를사용한다. (better) A SalesLineItem was created. (worse) Create a SalesLineItem. 무대와커튼 1. 오퍼레이션이수행되기전무대의사진을찍음. ( 사전조건 ) 2. 무대의커튼을닫고오퍼레이션수행. 3. 커튼을열고사진을찍음.( 사후조건 ) 두사진을비교해서틀린부분이무대의상태의변화라고한다. 21

얼마나자세하고완벽하게기술할것인가? 얼만큼상세하고완벽하게기술할것인가? 지금은간단하게, 다음반복때 (design work) 상세하게. 22

Discussion enteritem Postconditions Cashier 가 item 의 itemid 와 quantity 를입력한후에, 어떤인스턴스가생성혹은소멸되는가? ( 객체의생성혹은소멸 ) A SalesLineItem instance sli was created 오브젝트의어떤속성이변경되는가? ( 속성의변경 ) sli.quantity became quantity 오브젝트간의연관관계가맺거나끊어지는가? ( 연관관계의형성과해제 ) sli was associated with the current Sale sli was associated with a PoductSpecification, based on itemid match 23

7. 약정이언제유용한가? Contract vs. Use Cases? 유스케이스가요구사항의주요한저장소역할을하지만, 유스케이스와관련한시스템오퍼레이션이수행됨으로써발생하는상태변화가많을경우에는 contracts 를적용하는것을검토한다. 즉, 우선유스케이스에기술하고, 부족하다면 contracts 를작성한다. 모두유스케이스에기술할수있지만너무복잡 = 유스케이스는시나리오수준 복잡한것은약정에서추가기술 = 약정은하나의사건에대한상세한기술 ( 설계전단계 ) 24

8. 작성지침 : Contracts 1. 시스템시퀀스다이어그램으로부터시스템오퍼래이션을찾는다. 2. 시스템오퍼래이션이복잡하거나그결과가잘포착되지않는다면, contracts 를만든다. 3. 사후조건을기술할때, 다음의범주를고려해본다 : 인스턴스생성과소멸. 속성변경. 연관관계맺기와끊기. 25

Advice on Writing Contracts 사후조건은과거시제를사용하여기술. 상태가어떻게변화하는지가아니라상태변화의결과를기술. 상태변화중에서, 연관관계맺기와끊기를기술하였는지확인할것. 26

9. NextGen POS 예제 : Contracts 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. 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). 27

NextGen POS Example: Contracts( 계속 ) Contract CO3: endsale Operation: endsale() Cross References: Use Cases: Process Sale Preconditions: There is a sale underway. Postconditions: - Sale.isComplete became true(attribute modification). 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) 28

Changes to the Domain Model 약정 (contracts) 에의해서제시된정보를설계 (design) 에반영. 관련된오퍼래이션의시험이끝난후에반영하는것이바람직. Sale iscomplete: Boolean date time 29

11. UML 의적용 : Contracts, Operations Operation is a specification of a transformation or query that an object may be called to execute Method is an implementation of an operation Signature name and parameters Operation specification describes the effects produced by executing the operation 30

Operation Contracts Expressed with the OCL UML 에서는 OCL 을사용하여모델상의제약 (constraints) 를표현한다. OCL 을사용하여사전 / 사후조건을보다정형화하여정의할수있다. OCL 을사용해야하는강제적인이유가없다면, 자연어를사용하여간단하게정의하는것도좋다. System::makeNewSale() pre: <statements in OCL> post: 31

12. Operation Contracts Within the UP 시스템레벨의 Operation specification contracts 는유스케이스모델의부분. UP 나 RUP 에서크게강조하지는않는다. Elaboration 단계에서유스케이스모델을작성하면서정의. 복잡한시스템오퍼래이션을우선적으로. 32

Artifacts Relationships Business Modeling Sample UP Artifacts Domain Model * * Partial artifacts, refined in each iteration. the domain objects, attributes, and associations that undergo state changes Use-Case Model :System Requirements Glossary... text use cases use case diagrams system sequence diagrams system operations system operation contracts Design Design Model the system operations are handled by designing software to fulfill the postconditions of the contracts Software Architecture Doc. Project Management Software Dev. Plan Test Test Plan Environment Development Case 33

Domain Model date... Sale 1 1..* Sales... LineItem... quantity domain objects the domain objects, attributes, and associations that undergo state changes Use-Case Model Process Sale 1. Customer arrives... 2.... 3. Cashier enters item identifier. 4... Use Cases system events : Cashier make NewSale() enteritem (id, quantity) endsale() makepayment (amount) : System System Sequence Diagrams system operations some ideas and inspiration for the postconditions derive from the use cases Operation: makenewsale Post-conditions: -... Operation: enteritem Post-conditions: - A SalesLineItem instance sli was created -... Contracts in addition to the use cases, requirements that must be satisfied by the design of the software requirements that must be satisfied by the design of the software : Register Design Model : ProductCatalog : Sale enteritem (itemid, quantity) spec := getproductspec( itemid ) addlineitem( spec, quantity )... 34

Further Readings Formal specification method, such as Vienna Development Method(VDM) Design By Contract by Bertrand Meyer The Object Constraint Language : Precise Modeling With Uml by Jos B. Warmer, Anneke G. Kleppe 35