Requirement => 요구사항 use-case => 시스템 Modeling => 설계도
1. Structured analysis e.g) 순서도
2. OO analysis
객체->interaction
객체->interaction
a=f(b,c);
{ d=f2(a);e=f3(d,c,b);
* DFD(Data Flow Diagram)
간단하게 시스템을 도시화
큰 기능과 필요한 데이터
어떤 데이터를 처리할 것인지 정의
큰 기능과 필요한 데이터
어떤 데이터를 처리할 것인지 정의
Behavioral Modeling
* State Diagram
-user interaction
-user event
이벤트 처리
-user interaction
-user event
이벤트 처리
DFD는 이벤트를 처리하기 힘든데 State Diagram은 이벤트 중심
Identify event(<-> DFD(identify data))
Identify event(<-> DFD(identify data))
* Sequence Diagram
event, 흐름, 객체
외부 시스템과의 interaction을 표현
시스템 전체적으로 interal한 메시지 교환을 설계 가능
시스템 설계하는데 보편화된 방법. 많이 쓰임.
가장 시스템을 이해하기 쉽다. -- 210.94.213.72 2010-03-29
----
설계
외부 시스템과의 interaction을 표현
시스템 전체적으로 interal한 메시지 교환을 설계 가능
시스템 설계하는데 보편화된 방법. 많이 쓰임.
가장 시스템을 이해하기 쉽다. -- 210.94.213.72 2010-03-29
----
설계
Design and Quality
디자인의 퀄러티
- 모든 요구사항을 만족시킨다.
- 개발자뿐만 아니라 누구나 알아 볼 수 있어야 한다.
- ... (*pdf)
디자인의 퀄러티
- 모든 요구사항을 만족시킨다.
설계도를 보고 구현할 수 있어야 한다.
- 읽기 편해야 한다.- 개발자뿐만 아니라 누구나 알아 볼 수 있어야 한다.
- ... (*pdf)
Quality Guidelines
- ...
- ...
- ...
- ... (*pdf)
- ...
- ...
- ... (*pdf)
Patterns
Design Pattern Template- ... (*pdf)
Separation of Concerns
feature가 있으면 각자 가능하면 분리하는 것이 좋다. 는 개념.
feature가 있으면 각자 가능하면 분리하는 것이 좋다. 는 개념.
Modularity
가능하면 모듈화 하는 것이 좋다.
무조건 자르는 것이 아닌 특정 feature와 1:1로 맵핑
가능하면 모듈화 하는 것이 좋다.
무조건 자르는 것이 아닌 특정 feature와 1:1로 맵핑
Modularity:Trade-offs
"적절한" 모듈화가 소프트웨어의 cost가 가장 낮아진다.
"적절한" 모듈화가 소프트웨어의 cost가 가장 낮아진다.
Information Hiding
사용자 인터페이스만 제공.
사용자 인터페이스만 제공.
아래 사항은 은닉
- 알고리즘
- 자료 구조
- 디테일한 외부 인터페이스
- ...
- 알고리즘
- 자료 구조
- 디테일한 외부 인터페이스
- ...
Why Information Hiding? (*pdf)
Stepwise Refinement
Functional Independence
물론 설계 단계에선 중요한 내용이다.
-Cohesion
결합성. 가능한 모듈 하나가 기능 하나만.
-Coupling
의존성에 대해.
물론 설계 단계에선 중요한 내용이다.
-Cohesion
결합성. 가능한 모듈 하나가 기능 하나만.
-Coupling
의존성에 대해.
Aspects
Refactoring
(*그 뒤 pdf 그림들은 UML 도시화) -- 210.94.213.72 2010-03-29
----
8장
Refactoring
(*그 뒤 pdf 그림들은 UML 도시화) -- 210.94.213.72 2010-03-29
----
8장
숙제- 수요일 이전까지 공지
제출 손으로(?) 조교에게 제출 -- 210.94.213.72 2010-03-29
제출 손으로(?) 조교에게 제출 -- 210.94.213.72 2010-03-29
요구사항의 단계
* Inception
* Elicitation
* Elaboration
* Negotiation
* Specfication
* Validation
* Requirements management
* Inception
* Elicitation
* Elaboration
* Negotiation
* Specfication
* Validation
* Requirements management
Inception #
Identify stakeholder
누가 이 소프트웨어에 관여하고 누가 참여하고 개발할 것인가. 사용자 입장에서, 개발자 입장에서 파악.
관리. 비용 관리 등. 각자의 관여자, 참여자간의 이해관계.
Recognize multiple points of view
각 사용자들이 원하는 바 파악.
Work toward collaboration
기획자, 개발자 등들을 어떻게 모아서 일을 할 것인가.
누가 이 소프트웨어에 관여하고 누가 참여하고 개발할 것인가. 사용자 입장에서, 개발자 입장에서 파악.
관리. 비용 관리 등. 각자의 관여자, 참여자간의 이해관계.
Recognize multiple points of view
각 사용자들이 원하는 바 파악.
Work toward collaboration
기획자, 개발자 등들을 어떻게 모아서 일을 할 것인가.
Eliciting Requerements #
이 단계에서 구체화
Collaborative Requirement Gathering
각 단계의 구체적인 requrements를 구체적으로 수집.
문제가 무엇인가. 솔루션 제시.
Collaborative Requirement Gathering
각 단계의 구체적인 requrements를 구체적으로 수집.
문제가 무엇인가. 솔루션 제시.
QFD
우선순위를 정하는데 쓰는 도구. 직관적이 아닌 Formal하게.
우선순위를 정하는데 쓰는 도구. 직관적이 아닌 Formal하게.
Building the Analysis Model
Scenario-based elements
Class-based elements
Scenario-based elements
Class-based elements
Use-Cases
시나리오 단계에서 많이 사용.
기본적으로 actor를 만듬.
시나리오 단계에서 많이 사용.
기본적으로 actor를 만듬.
Use-Case Diagram
작대기 사람이 formal한 actor (-_-;)
말풍선 등으로 entity들을 표현.
작대기 사람이 formal한 actor (-_-;)
말풍선 등으로 entity들을 표현.
Class Diagram
State Diagram
class diagram이 구체적으로 어떠한 값들을 가질 것인지, state를 정의.
| Sensor |
| name/id |
| type |
| location |
| area |
| characteristics |
| identify() |
| enable() |
State Diagram
class diagram이 구체적으로 어떠한 값들을 가질 것인지, state를 정의.
Negotiating Requrements
진행된 부분을 프로젝트에 관여된 사람들에게 보여주고 부족한 부분은 없는지 수정할 부분은 없는지.
진행된 부분을 프로젝트에 관여된 사람들에게 보여주고 부족한 부분은 없는지 수정할 부분은 없는지.
Validating Requirements
Is each requirement consistent with the overall objectives?
Have all requirements been specified at the proper level?
Is the requirement really necessary or does it represent an add-on feature that may not be essential?
Is each requirement unambiguous?
요구사항이 전체적인 프로젝트 목적과 맞는지
Is each requirement consistent with the overall objectives?
Have all requirements been specified at the proper level?
Is the requirement really necessary or does it represent an add-on feature that may not be essential?
Is each requirement unambiguous?
요구사항이 전체적인 프로젝트 목적과 맞는지
'' 쓸만할 정도로 디테일하게 되었는지.
모호하거나 쓸모없는 부분은 없는지. 구현 가능한지, 테스트가 가능한지 전체적으로.| Requirements -> Scenario -> Use-case -> Class Diagram -> State Diagram -> Negotiating Requrements -> Validating Requirements |
Requirements Modeling #
Requirements Analysis
Domain Analysis
Domain Analysis
Use-case Diagram
Activity Diagram
필요한 액션 step-by-step 순서도
필요한 액션 step-by-step 순서도
Data Modeling
ERD
ERD
Class-Based Modeling
CRC Modeling
오퍼레이션을 하는데 필요한 클래스가 무엇인지 명세
오퍼레이션을 하는데 필요한 클래스가 무엇인지 명세
| Use-case Diagram -> Activity Diagram(Swimlane Diagram) -> Data Modeling(ERD) -> Class-Based Modeling -> CRC Modeling |
주제 : 알람 시스템
Single Alarm System
Single Alarm System
간단한 가정 상황을 두고 구현.
4개의 앱. 터미널. 서버. 컨트롤러(장비). 센서.
MFC 모두. 4개의 윈도우가 있다고 하고.
센서에 사용자가 값을 입력을 할 수 있게 하면 입력을 받아서.
서버에 값을 던져 주면,
서버는 터미널에. 터미널에선 센서의 값을 디스플레이.
사용자는 다시 액션을 취할 수 있다. 컨트롤러에 액션이 반영.
예) Light를 켜라. Window를 open, close 등.
4개가 각자 독립된 앱. 네트웍으로 연결. TCP/IP.
4개의 앱. 터미널. 서버. 컨트롤러(장비). 센서.
MFC 모두. 4개의 윈도우가 있다고 하고.
센서에 사용자가 값을 입력을 할 수 있게 하면 입력을 받아서.
서버에 값을 던져 주면,
서버는 터미널에. 터미널에선 센서의 값을 디스플레이.
사용자는 다시 액션을 취할 수 있다. 컨트롤러에 액션이 반영.
예) Light를 켜라. Window를 open, close 등.
4개가 각자 독립된 앱. 네트웍으로 연결. TCP/IP.
1
팀이 누구. 도구. 프로그래밍 언어. 간략하게.
2
시스템요구사항. 기능. 요구 사항.
팀이 누구. 도구. 프로그래밍 언어. 간략하게.
2
시스템요구사항. 기능. 요구 사항.