설계에 관한 자료입니다.

이거 역시 회사에서 했던 세미나 정리한 자료입니다. 이거 역시 이렇게 공유해되 되려나?

1.     객체지향 모델링 개요

-       Why don’t software Teams Model?

n  혼자 하는 작은 프로젝트 할 때는 바로 코딩 하는 게 쉽다.
그러나 그 규모가 커진다면? 재작성 해야 하는 경우가 빈번하게 생긴다.
à 그래서 모델링 하는 것이 좋다.

n  Agile은 설계서가 없는 것이 아니다.

1.      의사소통이 빠른 것이다. à 문서가 편하면 문서를 사용해야 한다.

 

-       Software Quality Attributes

n  기능성

1.      end user: 기능성, 사용성에 관심이 많다.

2.      Customer(발주자): 기능성, 신뢰성, 사용성, 효율성에 관심이 많다.

3.      Company: 기능성, 사용성, 효율성, 이식성에 관심이 많다.

l  이식성에 관심이 많은 것은 재사용성을 높여, 개발 기간을 단축하기 위함이다.

4.      Developer: 기능성, 신뢰성, 사용성

5.     

 

-       모델의 특징

n  추상화

1.     

l  Reveal: 드러내다. 보이다.

l  Indicate: 가시적으로 보여주고자 하는 것

l  Show: 여기서 Show는 Reveal과 Indicate가 가진 의미의 공통점을 나타내는 단어이다.

2.      위의 그림이 말하고자 하는 것은 프로젝트 진행 중에 작성되는 문서를 항상 Reveal, Indicate하게 하려 한다. 그럴 필요 없이 Show 만으로도 가능하다.

3.      이것이 추상화의 목적이다.

n  관점

1.      땅에서 가격의 흐름은 땅의 용도에 따라 다르다.
비싼 순서: 과수원 < 밭 < 논 < … < 상업 용지

2.      그래서 시스템을 볼 때 관점이 필요하다.

3.      모델링은 이 관점을 정리해가는 과정이다.

n  캡슐화(Encapsulation)

1.      과거 프로그램과 Data는 별개였다. à 객체지향 컨셉이 나오면서 프로그램과 Data를 하나로 보게 됨.

2.      적절한 행위 없이 상태만 변경하면 System이 죽는다(= Lifecycle 이 끝난다.).

l 

그런데, 최면을 걸어 상태만 [배가 부르다.] 로 변경하면 언젠간 죽는다.

3.      갤러그를 프로그래밍 하는 과정 중에

l  우리 눈에 보이는 것부터 먼저 캡슐화 한다.

l  우리가 만든 Data를 어떻게 UI와 연결할 것인가.
à 시작점을 정할 수 있다.

l  시작점을 정하는 것이 객체지향의 초기단계이다.

 

-       Use Case Driven

n  무엇을 할 수 있는가

1.      만드는 사람의 관점에서는 기능

2.      사용자의 관점에서는 요구사항

n  어떻게 하면 요구사항을 정의할까
à Use Case가 분석과 설계의 단위가 된다.

n  Test에서 Use Case는 Test 단위가 됨

n  Architecture(=Use Case): 분석과 설계의 단위

 

-       Interactive and Incremental

n  중요도에 따라 시간을 나누어 Use Case를 정의한다.

 

-       UML(Unified Model Language)

n  Component

1.      소스 코드가 아닌 모든 것은 Component이다.

n  Association

1.      상대방에 있는 Data를 내가 쓰겠음

 

2.     Use Case 모델링

-       Use Case Package

n  우리가 하는 프로젝트는 크기 때문에 나눈다.

1.      여기서 “나눈다”란 패키지 별로 나눈다.

n  여기서 점선 화살표의 의미는 A가 B를 알고 있어야 함을 의미한다.

n  Business 적 관점과 실제 시스템 관점은 다를 수 있다.
à 적절한 예인지는 모르겠지만,
만약 상위 10위 안의 고객의 마일리지를 2배 더 정립해줄 때 이 기능에 대한 것은
- Business 관점에서는 고객 관리에 넣어야 한다고 생각할지 모르지만,
- 시스템 관점에서는 재무 관리에 넣어야 한다.
- 자세한 것은 이 부분의 PPT 예제를 보면서 생각해보면 좋을 듯 하다.

 

-       Actor 도출

n  Actor와 Stackholder(이해관계자)의 개념은 조금 다르다.

n 

n  Actor에는 높낮이가 있다.

n  System Boundary를 결정하는 것이 Actor이다.

 

-       Use Case 도출

n  유용한 결과 à 원하는 명령에 의한 완전한 기능 단위

n  Delphi 기법(규모를 정할 때 사용한다.)

1.      규모를 정할 여러 명이 각자 감으로 크기를 정해서 그 중 최소, 최대를 뺀 나머지의 평균으로 정하는 것

n  Function Point

1.      여기서 Function의 의미는 Use Case 도출의 정의 첫 번째 라인을 말한다.

 

-       Use Case 도출방법

n  Top Down 방식과 Bottom Up 방식이 있음

 

-       Use Case 단위

n  교과서적으로 정해진 단위는 있으나, 실제 해봐야 할 수 있다.

 

-       Use Case 명세서 구성

n  선택 흐름: 어디에서 어떻게 분기할 것인지가 중요

n  어떤 상황이 발생했을 때, 어떻게 진행될 지의 범위를 정하는 것

n 

n  사전/사후 조건 à 기본 흐름에 포함되어 있어야 한다.

1.      상태에 관한 것

2.      해당되는 기능을 검증할 수 있다. à Test Case로 쓸 수 있다.

 

-       Include & Extend Relationship

n 

 

-       Storyboard 작성

n  Use Case 명세서에서 Actor가 행동하는 것을 정의하고, System이 무엇을 하는지 정의하면 된다.

n  A Interface가 Event에 의해 B Interface가 진행되는 과정을 정의

 

3장 분석 모델링

-       분석 모델의 정의

n  사용자 관점(Use Case)에서 개발자 관점(분석 모델)로 들어가는 단계

n  Logic View의 Analysis Model에 정의

n  Use Case Realization

1.      위의 그림은 Use Case의 분량에 따라, 분석, 설계 단계에서 그 분량을 나누거나 합칠 수 있다는 것을 보여주는 그림이다.

2.      분석과 설계 단계에서 나온 결과물은 Class Diagram 과 Sequence Diagram으로 나눌 수 있다.

n  요구사항에 대한 추적 관리도 가능하다.

n  Use Case Realization Diagram 예제 참고하세요.

 

-       분석 단계 Class

n  분석은 What, 설계는 How

1.      What: 알고리즘이 어디에 필요한가

2.      How: 알고리즘

n  Architecture Centric(Remind)

1.      MVC Architecture

2.     

n  Combine Use Case Realization and MVC

1.      Boundary Class 도출 기준

2.      Control Class 도출 기준

3.      Entry Class 도출 기준

4.      위의 세가지를 고려할 때 [구성요소 / 역할 / 도출규칙 / 명명규칙] 이 4가지를 기준으로 정의한다.

 

-       Interaction Diagram 의 목적

n  Sequence Diagram 의 Notation

1.      문제가 생겼을 때, 책임을 찾을 수 있다.

 

-       이건 그냥 실습에 대한 것을 적은 거임

n  Sequence Diagram을 그릴 때

1.      통신(호출)규칙이 필요하다.

2.      Function 명명 규칙

n  다 그리고 나서 이게 정말 될까라는(논리적으로) 시뮬레이션을 해봐야 한다.

 

-       Collaboration Diagram

n  시간의 흐름을 보기는 어려우나, 검증 단계로 쓰인다.
à Sequence Diagram이 완성되면, UML Tool에서 Collaboration Diagram 을 자동으로 만들어주는 기능을 기본으로 제공한다.

 

-       State Chart Diagram

n  상태 변화를 정의한다.

 

-       Stereo Type 별 Class 분류

 

4장 설계 모델링

분석 모델링과 설계 모델링의 방법은 같으나 우리 System에 적용하기 때문에 Architecture가 달라진다.

è  Architecture 가 달라진다.

n  구성 요소

n  역할

n  도출 규칙

n  명명 규칙

n  통신 규칙

n  함수 명명 규칙

☞ 여기서 중요한 것은 우리가 쓰는 설계 문서가 필요하다는 것이다.