지난 정리에 이어 Class-Based Modeling에 대해 서술한다.
Defining Attributes
- 클래스 다이어그램에서 클래스를 정의하고, Attributes를 정의하는 단계
- 클래스가 모델에 필요한 이유와 역할을 표현하는데 사용된다.
- 의미 있는 여러 attributes를 analysis class에 포함시켜야 하는데, 이 때 use case를 잘 구분하고 명확하게 설명할 수 있을 정도로 탐색해야 한다.
- 문제상황을 완벽하게 표현할 수 있는 attributes(composite and/or elementary)를 명시해야 한다.
Defining Operations
- Operations은 object의 행동을 정의한다.
- Operations은 크게 4가지 종류로 나뉜다.
- 데이터를 가공한다.
- 명령을 받아 작업을 수행한다. (perform a computation)
- Object의 state를 질의하고 반응한다.
- 오브젝트를 모니터링해, control이 필요한 시점을 확인한다. (이벤트 확인 및 처리)
- 이런 functions들은 여러 attribute와 그것들의 관계에 대해 operating하며 작동된다
- 결론적으로 operation은 attributes에 대해 기본적인 지식을 갖고 있고, 추가적으로 attributes간의 관계에 대한 사전지식을 바탕으로 만들어져야 한다.
- 여러 클래스의 협업간 책임관계 모델링이라 할 수 있다. 이런 CRC 모델링은 시스템 요구사항에 의거해 명시하고 조직화해야 하는 클래스를 제공한다.
- CRC 모델은 index card를 만들어야 하는데, 각 카드는 하나의 클래스를 의미한다. 이 index card를 조합해 CRC 모델을 구성한다
- 이 index card는 다음과 같이 3가지 영역을 담는다.
- 상단에 클래스 이름을 적는다.
- 왼쪽에 클래스의 목적, 업무를 적는다.
- 오른쪽에 협업자(collaborators)를 적는다.
CRC Cards
CRC Model Review Process
1. CRC 카드를 Stakeholders 모두에게 주어진다. 이 때 Collaborate관계에 있는 카드 2개를 한 사람에게 주지 않도록 한다. => 모두 독립적인 작업을 하는 카드만 갖거나, 혼자서 수행할 수 없는 상태가 됨
2. Review leader를 정하고, 그가 use case 내용을 읽는다. Use case에 맞는 object를 선택하고 그 object와 상호관계에 있는 index card를 들고 있는 다른 사람에게 token을 넘긴다.
3. Token을 넘겨 받은 사람은 카드에 적힌 responsibilities에 대해 질문을 받는다. 이 후 그룹에서 해당 responsibilities가 use case의 목적에 부합하는지에 결정한다.
4. 에러가 발생하면, 카드를 보안한다. 이 작업은 이미 존재하는 카드를 다시 정리하거나, 새로운 카드를 생성 (new class)하며 이뤄진다.
Functional Modeling
- CRC는 행동의 주체에 따른 모델링, Functional Modeling은 행동의 흐름에 다른 모델링
- Functional Model은 2개의 application processing elements가 있다.
- 유저가 충분히 관찰할 수 있는 Functionality
(app을 통해 end users에게 전달되는 기능=>유저가 관찰, 피드백 가능)
- 클래스가 해야 하는 행동이 담긴 operation(analysis classes 내 명시된 행동들)
=> 클래스의 기능 설명 가능.
- UML Activity Diagram을 통해 Functional Modeling의 Processing을 표현한다.
- UML Activity Diagram은 Use case(Scenario)를 보조하는 역할을 한다. 시각적으로 Actor와 System간의
Interaction의 흐름을 보여주기에 보조한다는 것이다.
Activity Diagram