PowerPoint 프레젠테이션

Size: px

Start display at page:

Download "PowerPoint 프레젠테이션"

준목 연
8 years ago
Views:

1 소프트웨어 공학 Requirements Modeling 실습

2 TOC Problem Statements Use Case Modeling Use Case Modeling 시 주의사항

3 Sea Buoy System Wind Speed Sensor Problem Description Air Temperature Sensor Water Temperature Sensor Location Sensor Sea Buoy System Radio Receiver Radio Transmitter Emergency Switch Red Light

4 Problem Description There exists a collection of free-floating buoys that provide navigation data to air and ship traffic at sea or weather data for use in forecasting and climate study. The buoys collect weather data (i.e., air and water temperature, wind speed) and navigation data (i.e., location) through a variety of sensors. Each buoy may have a different number of wind and temperature sensors and may be modified to support other types of sensors in the future. Each buoy is also equipped with a radio transmitter (to broadcast weather and navigation information) and a radio receiver (to receive requests from passing vessels. Some buoys are equipped with a red light, which may be activated by a passing vessel during sea-search operations. an emergency switch, which may be flipped by a sailor to initiate an SOS broadcast.

Each buoy may have a different number of wind and temperature sensors and may be modified to support other types of sensors in the future.

5 Problem Description Software for each buoy must: maintain current wind, temperature, and location information; wind speed readings are taken every 30 seconds, temperature readings every 10 seconds and location every 10 seconds; wind and temperature values are kept as a running average. broadcast current wind, temperature, and location information every 60 seconds. broadcast wind, temperature, and location information from the past 24 hours in response to requests from passing vessels; this takes priority over the periodic broadcast activate or deactivate the red light based upon a request from a passing vessel. continuously broadcast an SOS signal after a sailor engages the emergency switch; this signal takes priority over all other broadcasts and continues until reset by a passing vessel.

broadcast wind, temperature, and location information from the past 24 hours in response to requests from passing vessels; this takes priority over the periodic broadcast activate or deactivate the

6 Problem Description Other Considerations The problem statement defines a set of separate functions with relatively little in common. The architecture under design must respect their priorities and timing constraints Clearly the system may be extended further by additional functions (e.g., more sensors) or that the priorities and timing constraints may be modified. The architecture should therefore allow modifications to the overall system parameters Finally, sea buoys deployed in deep sea must operate reliability for long periods without maintenance (replacement of battery or faulty sensors).

(e.g., more sensors) or that the priorities and timing constraints may be modified.

7 Problem Description Other Considerations The problem statement defines a set of separate functions with relatively little in common. The architecture under design must respect their priorities and timing constraints Clearly the system may be extended further by additional functions (e.g., more sensors) or that the priorities and timing constraints may be modified. The architecture should therefore allow modifications to the overall system parameters Finally, sea buoys deployed in deep sea must operate reliability for long periods without maintenance (replacement of battery or faulty sensors).

8 TOC Problem Statements Use Case Modeling Use Case Modeling 시 주의사항

9 Use Case Diagram System Broadcasting 24h History Broadcasting SOS Message RadioReceiver EmergencySwitch ActivatingRedLight DeactivatingRedLight RadioTransmitter AirTempSensor Broadcasting Weather Data WaterTempSensor AirTempReading RedLight WaterTempReading WindSpeedSensor WindSpeedReading Clock LocationSensor LocationReading

RadioTransmitter AirTempSensor Broadcasting Weather Data WaterTempSensor

10 Use Case Description Use case name: Broadcasting 24h History Summary: System broadcasts wind, temperature, and location information from the past 24 hours in response to requests from passing vessels Actor: Radio Receiver, Radio Transmitter Precondition: the system is active. Description: 1. Radio Receiver sends requests from passing vessels to system 2. System sends 24 hour weather data to the requested vessels through Radio Transmitter

Receiver, Radio Transmitter Precondition: the system is active. Description: 1.

11 Use Case Description Use case name: Broadcasting SOS Message Summary: System broadcasts a SOS signal continuously until reset by a passing vessel Actor: Emergency Switch, Radio Receiver, Radio Transmitter Precondition: the system is active. Description: 1. An emergency switch is flipped by a sailor 2. System sends an SOS signal through Radio Transmitter 3. Step 2 continues until reset

Radio Transmitter Precondition: the system is active. Description: 1.

12 Use Case Description Use case name: AirTempReading Summary: System collects air temperature data through a variety of air temperature sensors Actor: AirTempSensor, Clock Pre-condition: the system is active. Post-condition: the sensed temperature value is recorded. Description: 1. Clock sends a timer event to the system every 10 seconds 2. System collects data from a number of air temperature sensors and maintains them

Post-condition: the sensed temperature value is recorded. Description: 1.

13 TOC Problem Statements Use Case Modeling Use Case Modeling 시 주의사항

14 Use Case 단위 A use case represents interaction scenarios between actor(s) and system interaction scenarios represents a set of sequences of actions Use cases are end-user visible functionality Use Case가 interaction scenario 관점에서 기술이 어렵 다면 Use Case 단위가 적합한지 의심해 보라

sequences of actions Use cases are end-user visible functionality

15 잘못된 예

16 Post-Condition 기술 해당 Use case의 정상적인 수행 후에 시스템이 도달해야 하는 조건을 기술하라. Postconditions: Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded.

17 잘못된 기술 예

18 Scenario Description Use case 시나리오 스텝은 시간적인 순서가 있게 기술되 어야 한다. Use case 시나리오 스텝은 Actor의 시스템으로의 입력, 시스템의 출력 관점에서 기술되어야 한다. 1. 사용자는 시스템에 현재 온도를 요구한다. 2. 시스템은 현재 온도를 사용자에게 보내준다. 3.

19 잘못된 기술 예 시간적 선후 관계가 없음

20 잘못된 기술의 예 1. Use-case name 1) Turning on Red Light 2. Primary Actor 1) Red Light, RadioReceiver 3. Preconditions 1) Red Light 가 문제 없이 동작 될 수 있는 상태이어야 한다. 2) 수신 장치가 정상 동작되고 있어야 한다. 입력과 출력이 동 시에 한 스템으로 기술됨 4. Main success scenario (basic flow) 1) 지나가는 배로부터 요청에 의해서 Red Light 동작을 활성화/비활성화 한다. 1. Radio Receiver는 지나가는 배로부터 Red Light 요청을 시스템에 전달한다. 2. 시스템은 요청에 따라 Red Light 동작을 활성화/비활성화 한다

Preconditions 1) Red Light 가 문제 없이 동작 될 수 있는 상태이어야 한다. 2) 수신 장치가 정상 동작되고 있어야 한다.

21 Use Case Modeling Checklist 개요 유스케이스가 나타내는 전체적인 기능이 명확히 기술되어야 한다. 유스케이스와 상호 작용을 하는 액터를 기술한다. 유스케이스의 일부 기능만을 뜻해서는 안 된다 주요 대안 시나리오가 언급되어야 한다. 관련 액터가 언급되어야 한다. 시스템 내부의 기능과 액터와의 상호작용을 상세하게 기술해서는 안 된다. 관련 액터 관련 액터는 유스케이스 다이어그램과 일관되어야 한다. 선행조건 유스케이스가 정상적으로 수행되기 위하여 가정하고 있는 상황을 표현해야 한다. 선행 조건은 유스케이스의 수행 시작을 위하여 항상 만족이 되어야 하는 조건이다. 선행 조건은 액터와 시스템 상태에 대한 제약으로 표현된다. 후행조건 유스케이스의 수행 결과를 후행조건을 통하여 파악할 수 있어야 한다. 후행 조건은 유스케이스의 수행 완료 후에 만족이 되어야 하는 조건이다. 후행 조건은 입력과 시스템 상태의 변화에 대한 조건으로 기술된다.

22 Use Case Modeling Checklist 시나리오 유스케이스와 관련된 모든 액터와의 모든 상호작용을 기술해야 한다. 시나리오는 명확하고 이해가 용이한 문장 스타일로 기술해야 한다. 개발자의 기술적인 용어를 사용하지 않고 도메인의 용어를 사용한다. 각 스텝은 주어는 시스템 또는 액터를 주어로는 능동태의 문장으로 기술한다. 한 스텝에는 시스템 또는 하나의 액터에 의한 기능/행위를 기술한다. 시스템과 액터와의 입/출력이 명확하게 기술되어야 한다 각 스텝은 액터와 시스템간의 입/출력 및 시스템의 기능의 궁극적인 목적을 기술한다. 액터가 인식할 수 없는 시스템 내부의 동작과 액터와의 입/출력 방법을 상세하게 기술하지 않는다. 기본 시나리오와 주요 대안 시나리오 모두 기술해야 한다.

23 23

소프트웨어개발방법론

소프트웨어개발방법론 사용사례 (Use Case) Objectives 2 소개? (story) vs. 3 UC 와 UP 산출물과의관계 Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use-Case Model objects,