Requirement => 요구사항 use-case => 시스템 Modeling => 설계도

1. Structured analysis e.g) 순서도

2. OO analysis
객체->interaction

{ d=f2(a);
* DFD(Data Flow Diagram)

http://pages.cpsc.ucalgary.ca/~jadalow/seng613/Group/report/SASD_2002.html

간단하게 시스템을 도시화
큰 기능과 필요한 데이터
어떤 데이터를 처리할 것인지 정의

Behavioral Modeling

* State Diagram
-user interaction
-user event
이벤트 처리

DFD는 이벤트를 처리하기 힘든데 State Diagram은 이벤트 중심
Identify event(<-> DFD(identify data))

* Sequence Diagram

event, 흐름, 객체
외부 시스템과의 interaction을 표현
시스템 전체적으로 interal한 메시지 교환을 설계 가능
시스템 설계하는데 보편화된 방법. 많이 쓰임.
가장 시스템을 이해하기 쉽다. -- 210.94.213.72 2010-03-29
----
설계

Design and Quality
디자인의 퀄러티
- 모든 요구사항을 만족시킨다.
- 읽기 편해야 한다.
- 개발자뿐만 아니라 누구나 알아 볼 수 있어야 한다.
- ... (*pdf)

Quality Guidelines

- ...
- ...
- ...
- ... (*pdf)

Patterns

Design Pattern Template

- ... (*pdf)

Separation of Concerns
feature가 있으면 각자 가능하면 분리하는 것이 좋다. 는 개념.

Modularity
가능하면 모듈화 하는 것이 좋다.
무조건 자르는 것이 아닌 특정 feature와 1:1로 맵핑

Modularity:Trade-offs
"적절한" 모듈화가 소프트웨어의 cost가 가장 낮아진다.

Information Hiding
사용자 인터페이스만 제공.

아래 사항은 은닉
- 알고리즘
- 자료 구조
- 디테일한 외부 인터페이스
- ...

Why Information Hiding? (*pdf)

Stepwise Refinement

Functional Independence
물론 설계 단계에선 중요한 내용이다.
-Cohesion
결합성. 가능한 모듈 하나가 기능 하나만.
-Coupling
의존성에 대해.

Aspects
Refactoring
(*그 뒤 pdf 그림들은 UML 도시화) -- 210.94.213.72 2010-03-29
----
8장

숙제- 수요일 이전까지 공지
제출 손으로(?) 조교에게 제출 -- 210.94.213.72 2010-03-29