• 검색 결과가 없습니다.

시스템

N/A
N/A
Protected

Academic year: 2022

Share "시스템"

Copied!
35
0
0

로드 중.... (전체 텍스트 보기)

전체 글

(1)

시스템 순차도 (SSD)

1

(2)

1 소개

• 시스템 순차도 (SSD: System Sequence Diagram)

– 구현하고자 하는 소프트웨어 시스템을 블랙박스로 놓고 액터와 시스 템간의 행위를 순차도로 기술

– 쓰임새의 한 시나리오에 대해서 외부 액터가 발생하는 사건 및 그 순 서 그리고 시스템간의 사건을 보여줌.

– 개발하고자 하는 시스템의 입력과 출력 이벤트를 알기 쉽게 표현 – 빠르고 쉽게 생성되는 산출물임

– 유스케이스로부터 UML 순차도를 이용하여 정형화 – 시스템은 하나의 블랙박스로 표현 (단 하나의 객체) – 시스템과 액터 간의 사건에 중점을 둠.

• SSD의 목적 - 정형화

– 시스템 연산(액터가 시스템에 요구하는 연산)의 도출 목적

– 유스케이스의 정형화된 모델 : 더 나은 이해 및 구현에 근접해 가는 단계

2

(3)

SSD의 목적: UP 산출물 관계의 예

3

Operation : enterItem ( … ) Post - conditions : - . . .

Operation Contracts Sale date . . .

Sales LineItem quantity 1 ..

*

1 . . .

. . . Domain Model

Use - Case Model

Design Model : Register

enterItem ( itemID , quantity )

: ProductCatalog

spec = getProductSpec ( itemID ) addLineItem ( spec , quantity )

: Sale Require -

ments Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem ( id , quantity ) Use Case Text

System Sequence Diagrams make

NewSale () system events

Cashier

Process Sale

: Cashier

use case names

system operations Use Case Diagram

Vision

Supplementary Specification

Glossary parameters and return value details

starting events to design for

Process Sale 1 . Customer arrives ...

2 . Cashier makes new sale . 3 . ...

(4)

예) NextGen SSD

enterItem(itemID, quantity)

:System : Cashier

endSale

makePayment(amount) a UML loop

interaction frame, with a boolean guard expression

external actor to system

Process Sale Scenario 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

a message with parameters

it is an abstraction representing the system event of entering the payment data by some mechanism 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

total with taxes

change due, receipt makeNewSale [ more items ]

loop

4

(5)

3 Why SSD?

• 소프트웨어 시스템에 대한 사건 (Event)

– 외부 액터가 발생시키는 사건 (마우스, 키보드 등) – 타이머 사건 (자발적 사건)

– 오류 또는 예외 사건

• 외부에서 입력되는 사건을 식별하기 위함

– 시스템을 하나의 객체로 생각

– 사건은 곧 객체가 제공해야 할 연산임.

• 시스템 행위를 기술

– 시스템이 어떻게 동작하는지를 설명하지 않고 무엇을 하는지에 초점 을 둔 설명

5

(6)

3. UML의 적용: 순차도

• 시스템을 하나의 객체로 두고 액터와 시스템 객체간의 순차도 작 성

• UML 순차도: 별도 설명

6

(7)

5 SSD와 UC의 관계

• UC의 한 특정 시나리오를 정형화하여 기술한 것이 SSD이다.

: Cashier :System

Simple cash-only Process Sale scenario:

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.

...

enterItem(itemID, quantity)

endSale

makePayment(amount) description, total

total with taxes

change due, receipt makeNewSale [ more items ]

loop

Process Sale Scenario

7

(8)

6 시스템 이벤트와 오퍼레이션은 어떻게 명명하는가?

Which is better? – 방법보다는 의도를 표현하라. (What, rather than how)

동사로 표현하라. – enter…, add…, make…,

enterItem(itemID, quantity)

scan(itemID, quantity) : Cashier

worse name better name

:System

8

(9)

7 다른 외부시스템과 관련된 SSD의 모델링

• 예) NextGen POS 와 외부의 신용지불인증시스템 사이의 시나리오

– 역시 SSD로 기술한다.

– 프로토콜 기술하는 것과 동일하다.

– 정보의 내용 및 정보의 전달 순서를 기술 (복잡할 경우 상태도를 이용)

9

(10)

8 SSD로부터 용어집에 추가될 부분은?

• SSD에 나타난 요소들을 추가

– 오퍼레이션 이름, 매개변수, 반환 데이터

• 예) change due, receipt 에 대한 자세한 설명

10

(11)

10 SSD 작업 프로세스: 반복적이며 진화적으로!

• 몇 개의 선택된 시나리오에 대해서만 SSD작성… (30분 이내)

– 액터와 시스템 외에도 기존 시스템과 시스템간의 협력관계 또는 구 조를 이해시킬 때도 유용하게 활용

• UP에서 SSD를 사용하는 경우

– SSD는 UP에서 잘 사용하지 않으나 실무적으로 유용함이 입증

• 대부분의 SSD는 정련단계에서 작성됨

– 도입부에서는 작성되지 않음

• 기능점수나 COCOMO II에서의 추정을 위해 하지 않은 한!

– 정련단계: SSD작성  시스템 약정 작성

11

(12)

UC 구체화: 오퍼레이션 약정

(Operation Contracts)

(13)

Objectives

• 시스템 오퍼래이션을 위한 약정(contracts) 만들기.

– 시스템 오퍼레이션을 정의한다. (=시스템 객체의 메소드) – 시스템 오퍼레이션에 대한 약정을 생성한다.

13

† 오퍼래이션의 약정(contract)은 시스템의 행위를 정의하는데 사용된

다. 약정(contract)은 도메인 오브젝트의 상태 변화에 관하여 시스템

오퍼래이션 수행의 결과를 설명한다.

(14)

유스케이스 모델의 구체화

Operation:

enterItem(…) Post-conditions:

- . . .

Operation Contracts Sale date . . .

Sales LineItem quantity 1..

*

1 . . .

. . . Domain Model

Use-Case Model

Design Model : Register

enterItem (itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID ) addLineItem( spec, quantity )

: Sale Require-

ments Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem (id, quantity) Use Case Text

System Sequence Diagrams make

NewSale() system events

Cashier

Process Sale

: Cashier

use case names

system operations Use Case Diagram

Vision

Supplementary Specification

Glossary

starting events to design for, and more detailed requirements that must be satisfied by the software

Process Sale 1. Customer arrives ...

2. ...

3. Cashier enters item identifier.

the domain objects, attributes, and associations that undergo changes

requirements that must be satisfied by the software ideas for

the post- conditions

14

(15)

1. 예: ‘판매’ 유스케이스에 대한 하나의 SSD

• UP에서 시스템의 행위는 기본적으로 Use Cases로 정의하지만, 시스템 오퍼래이션이 수행된 후에 도메인 모델의 상태 변화와 관련한 시스템의 행위를 Contracts를 통해서 좀 더 자세히 정의할 수도 있다.

: Cashier

enterItem(itemID, quantity)

endSale()

makePayment(amount) description, total

total with taxes

change due, receipt makeNewSale()

these input system events invoke system operations the system event enterItem invokes a system operation called enterItem and so forth this is the same as in object- oriented programming when we say the message foo invokes the method (handling operation) foo

[ more items ]

loop

:System Process Sale Scenario

15

(16)

1. 시스템 오퍼레이션(연산) 및 시스템 인터페이스

• Contracts는 시스템 오퍼래이션(시스템을 블랙박스 형태로 간주했을 때의 오퍼 래이션)을 정의할 수 있다. (OOP의 ADT의 정의와 유사)

• 시스템에 대한 이벤트 (객체지향에서는 메소드,메시지를 의미)

• 시스템 인터페이스라고도 함.

16

: Cashier

enterItem(itemID, quantity)

endSale()

makePayment(amount) description, total

total with taxes

change due, receipt makeNewSale()

these input system events invoke system operations the system event enterItem invokes a system operation called enterItem and so forth this is the same as in object- oriented programming when we say the message foo invokes the method (handling operation) foo

[ more items ]

loop

:System Process Sale Scenario

시스템 객체의 연산(오퍼레이션)

(17)

‘약정(Contract)’의 예: enterItem()

17

약정 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와 연관되었다.

id := itemID;

:ProductSpecification /quanty := quantity

sli:SalesLineItem

current: Sale

:System

enterItem(itemID, quantity)

(18)

2. “약정”의 각 부분의 의미

18

오퍼레이션: 오퍼래이션 이름과 매개변수

상호참조 : (선택적) 이 오퍼래이션이 나타나는 유스케이스

사전조건 : 오퍼래이션이 수행되기 전에 도메인 모델에 시스템 혹은 오브젝트

의 상태에 관한 주목할 만한 가정(assumptions). 오퍼래이션 로직 내부에서는 테스트되지 않고, 참이라고 가정한다.

사후조건 : 오퍼래이션이 수행된 후에 도메인 모델에서 오브젝트의 상태. 다 음 섹션에서 보다 자세히 이야기 한다.

(19)

4. 사후조건

• 사후조건은 도메인 모델에서 오브젝트의 상태변화를 표현한다.

• 사후조건은 오퍼래이션 수행 도중의 행위(action)이 아니다.

• 범주:

– 인스턴스 생성과 소멸.

– 속성 변경.

– 연관관계 맺기와 끊기.

• 사후조건은 도메인 모델에 관계가 있다.

19

(20)

사전조건: Analytical Detail

• 약정(contracts)은 시스템 오퍼래이션의 상태 변화를 설명하는 요구사항 분석을 위한 효과적인 도구.

• How가 아닌 what을 기술.

• 물론 유스케이스에 기술하는 것도 가능하지만, 이것은 유스케이 스를 지저분하게 만들 수 있으므로 조심해야 한다.

20

(21)

사후조건의 철학: The Stage and Curtain

• 과거의 상태 변화를 설명해야 하기 때문에 과거 시제를 사용한다.

• (better) A SalesLineItem was created.

• (worse) Create a SalesLineItem .

• 무대와 커튼

– 1. 오퍼레이션이 수행되기 전 무대의 사진을 찍음. (사전조건) – 2. 무대의 커튼을 닫고 오퍼레이션 수행.

– 3. 커튼을 열고 사진을 찍음.(사후조건)

– 두 사진을 비교해서 틀린 부분이 무대의 상태의 변화라고 한다.

21

(22)

얼마나 자세하고 완벽하게 기술할 것인가?

• 얼만큼 상세하고 완벽하게 기술할 것인가?

• 지금은 간단하게, 다음 반복 때(design work) 상세하게.

22

(23)

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

(24)

7. 약정이 언제 유용한가? Contract vs. Use Cases?

• 유스케이스가 요구사항의 주요한 저장소 역할을 하지만, 유스케 이스와 관련한 시스템 오퍼레이션이 수행됨으로써 발생하는 상태 변화가 많을 경우에는 contracts를 적용하는 것을 검토한다.

• 즉, 우선 유스케이스에 기술하고, 부족하다면 contracts를 작성한 다.

• 모두 유스케이스에 기술할 수 있지만 너무 복잡 = 유스케이스는 시나리오 수준

• 복잡한 것은 약정에서 추가 기술 = 약정은 하나의 사건에 대한 상 세한 기술 (설계 전단계)

24

(25)

8. 작성 지침: Contracts

1. 시스템 시퀀스 다이어그램으로부터 시스템 오퍼래이션을 찾는다.

2. 시스템 오퍼래이션이 복잡하거나 그 결과가 잘 포착되지 않는다면, contracts를 만든다.

3. 사후조건을 기술할 때, 다음의 범주를 고려해 본다:

– 인스턴스 생성과 소멸.

– 속성 변경.

– 연관관계 맺기와 끊기.

25

(26)

Advice on Writing Contracts

• 사후조건은 과거 시제를 사용하여 기술.

• 상태가 어떻게 변화하는 지가 아니라 상태 변화의 결과를 기술.

• 상태 변화 중에서, 연관관계 맺기와 끊기를 기술하였는지 확인할 것.

26

(27)

9. NextGen POS 예제: Contracts

27

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 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.

(28)

NextGen POS Example: Contracts(계속)

28

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)

Contract CO3: endSale

Operation: endSale()

Cross References: Use Cases: Process Sale Preconditions: There is a sale underway.

Postconditions: - Sale.isComplete became true(attribute modification).

(29)

Changes to the Domain Model

• 약정(contracts)에 의해서 제시된 정보를 설계(design)에 반영.

• 관련된 오퍼래이션의 시험이 끝난 후에 반영하는 것이 바람직.

29 Sale

isComplete: Boolean date

time

(30)

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

(31)

Operation Contracts Expressed with the OCL

• UML에서는 OCL을 사용하여 모델상의 제약(constraints)를 표현한다.

• OCL을 사용하여 사전/사후조건을 보다 정형화하여 정의할 수 있다.

• OCL을 사용해야 하는 강제적인 이유가 없다면, 자연어를 사용하여 간단하게 정 의하는 것도 좋다.

System::makeNewSale()

pre: <statements in OCL>

post: …

31

(32)

12. Operation Contracts Within the UP

• 시스템 레벨의 Operation specification contracts는 유스케이스 모델의 부분.

• UP나 RUP에서 크게 강조하지는 않는다.

• Elaboration 단계에서 유스케이스 모델을 작성하면서 정의. 복잡 한 시스템 오퍼래이션을 우선적으로.

32

(33)

Artifacts Relationships

33

Glossary

Software Architecture Doc.

Domain Model

Requirements

Project Management

Business Modeling

Design

Sample UP Artifacts Partial artifacts,

refined in each iteration.

Test

Test Plan

Software Dev. Plan

. . .

Use-Case Model

text use cases

:System

system operation contracts system

sequence diagrams

the domain objects, attributes, and associations that undergo state changes

the system operations are handled by designing software to fulfill the post- conditions of the

contracts use

case diagrams

* *

Design Model

system operations

Environment

Development

Case

(34)

34

: System

enterItem (id, quantity)

endSale()

makePayment (amount) Process Sale

1. Customer arrives ...

2. ...

3. Cashier enters item identifier.

4....

Use Cases System Sequence Diagrams

Operation: enterItem Post-conditions:

- A SalesLineItem instance sli was created

- . . .

Operation: makeNewSale Post-conditions:

- . . .

Contracts make

NewSale() : Cashier

Sale date . . .

Sales LineItem quantity 1..

*

1 . . .

. . .

domain objects

system events

system operations

the domain objects, attributes, and associations that undergo state changes Domain Model

Use-Case Model

some ideas and inspiration for the post- conditions derive from the use cases

Design Model : Register

enterItem (itemID, quantity)

: ProductCatalog

spec := getProductSpec( itemID ) addLineItem( spec, quantity )

: Sale

. . .

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

(35)

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

참조

관련 문서

저작물에 대한 이용기간은 5 년으로 하고 , 기간종료 3 개월 이내에 별도의 의사 표 시가 없을 경우에는 저작물의 이용기간을 계속 연장함.. 해당 저작물의

Accordingly, the study applies the Design Thinking process that corporations mainly and recently use in the creative idea generating process to the

Result of patients’indirect markers reflecting bone quantity and quality (CTX : C-terminal cross-linking telopeptide of type 1 collagen, FRAX : Fracture Risk

Instructor Station Instructor Station Instructor Station Operation Panel Operation Panel Operation Panel Operation Panel Hardware Interface Hardware Interface

– If the test is corrupted by noise, the frequency response may be modified significantly by noise. – The disturbance affects both the gain and phase over

– Requires a converter from resistance to electrical signal – Higher price than

INTEGER displs(*) Integer array (of length group size), entry i specifies the displacement relative to recvbuf at which to place the incoming data from process i (significant

Given a feasible solution λ 0 to the original dual problem, set up the associated restricted primal problem. Optimize the