객체지향 기술 6

04. UML 다이어그램

02. UML 다이어그램의 관계 표현

1) 클래스 표기 형식

• 접근 제어 지정자의 기호
  • ＋(public) : 누구든 접근할 수 있음
  • －(private) : 클래스 내부에서만 사용할 수 있음
  • #(protected) : 동일 패키지나 상속 관계에 있는 하위 클래스에서만 사용할 수 있음
  • ~(package) : 동일 패키지에 있는 클래스의 객체들만 접근할 수 있음

2) 클래스 간의 관계 표현(Relationship)

• 연관 관계
  • 실선이나 화살표
  • 하나의 클래스가 다른 클래스에서 제공하는 기능이 있음을 표시함
• 일반 관계
  • 빈 삼각형 실선
  • 상속 관계에 있을 때 표시함
• 집합 관계
  • 마름모 화살표
  • 한 객체가 다른 객체를 포함하는 집약 관계와 부분 객체가 전체 객체에 속하는 합성 관계를 표시함
• 의존 관계
  • 점선 화살표
  • 연관 관계와 유사하지만 기능을 사용하는 시간이 일시적일 때 표시함
• 실체 관계
  • 빈 삼각형 점선
  • 인터페이스 관계를 표시함

3) 연관(Association) 관계

1. 단방향 연관 관계
   • 단방향 연관 관계를 화살표로 표시함
   • 하나의 클래스가 다른 클래스에서 제공하는 기능이 있음을 표시함
   • studnet -> phone
     • student 클래스는 phone 클래스의 존재를 알고 있지만, phone 클래스는 student 클래스의 존재를 모름
     • student 클래스만 phone 클래스의 기능을 참조할 수 있음
2. 양방향 연관 관계
   • 양방향 여ㅕㄴ관 관계를 실선으로 표시함
   • 클래스에서 제공하는 기능이 양쪽에 있음을 표시함
   • student - phone
     • student 클래스와 phone 클래스는 서로 존재를 알고 있음
     • student 클래스와 phone 클래스는 서로의 기능을 참조할 수 있음
3. 연관 관계 표시 방법
   • 화살표나 실선에 연관 관계 이름을 사용할 수 있음
   • 화살표나 실선에 다중성을 표시하지 않으면 일대일 관계
   • 화살표나 실선에 다중성을 표시할 수 있음

4) 일반(Generalization) 관계

• 상속 관계에 있을 때 표시함
• 빈 삼각형 화살표로 표시함
• 한 클래스가 다른 클래스를 포함하는 상하 관계일 때, 일반화 관계가 존재함
• 일반화 클래스를 "is a kind of" 관계(~은 ~의 종류)라고 함
• 상위 클래스는 추상적인 개념으로 실체가 존재하지 않음
• 하위 클래스는 구체적인 개념으로 실체가 존재함

5) 집합 관계

1. 집약(Aggregation) 관계
   • 한 객체가 다른 객체를 포함하는 관계로 빈 마름모 화살표로 표시함
   • 부분 객체를 다른 전체 객체와 공유할 수 있는 경우에 사용함
   • 전체 객체가 사라져도 부분 객체는 없어지지 않으므로 라이프 타임은 독립적임
2. 합성(Composition) 관계
   • 부분 객체가 전체 객체에 속하는 관계로, 채워진 마름모 화살표로 표시함
   • 부분 객체를 다른 전체 객체와 공유할 수 없는 경우에 사용함
   • 전체 객체가 사라지면 부분 객체도 없어지므로 라이프 타임은 의존적임

6) 의존(Dependency) 관계

1. 연관 관계
   • 연관 관계는 계속적으로 관계를 유지함
   • Ex) student(학생)은 study(공부)를 지속적으로 수행해야 함
   • 점선이 아닌 화살표로 표시함
   • 클래스는 다른 클래스의 참조를 포함함
2. 의존 관계
   • 의존 관계는 일시적으로 관계를 유지함
   • Ex) student(학생)은 cold(감기)가 가끔씩 발생함
   • 점선 화살표로 표시함
   • 의존 관계이지만 클래스의 멤버는 아님

7) 실체(Realization) 관계

• 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
• 인터페이스 관계에 있을 때 표시함
• 빈 삼각형 점선 화살표로 표시함
• 실체 관계를 "can do this" 관계라고 함

---

03. 분석 모델의 기술적 타당성 검토

1) 분석 모델의 기술적 타당성 검토의 개념

• 유스케이스 모델의 개별 유스케이스에 대한 분석 모델을 작성한 이후, 해당 분석 모델로 시스템을 개발하는 경우에 어떠한 영향을 미치는지 필요한 자원, 상호 운용성, 시장 성숙도, 기술적 위험 분석 측면에서 타당성을 조사함

2) 분석 모델의 기술적 타당성 검토 순서

1. 성능 및 용량 산정 적정성
   • 요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 떄 요구되는 시스템의 자원을 식별함
   • 분석 클래스에서 불필요하고 지나치게 많은 속성들을 포함하게 되면 객체 생성 시 시스템의 메모리 자원을 많이 요구하게 됨
   • 과도한 조각 모으기(Garbage Collection)가 발생하여 전체 시스템의 성능 저하가 빈번히 발샘함
2. 시스템 간 상호 운용성
   • 분석 모델을 이용하여 보다 구체적으로, 시스템 간 상호 정보 및 서비스를 교환 가능한지 검토함
   • 분석 모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 관해서 확인함
3. IT 시장 성숙도 및 트렌드 부합성
   • 분석 모델이 과거의 문제를 해결하고 많이 사용되는 트렌드에 부합하는지 확인함
4. 기술적 위험 분석
   • 분석 모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합되는지 확인함
   • 분석 모델이 검증되지 않은 기술의 사용을 가정으로 하고 있어 추가적인 비용 발생 가능성이 있는지 확인함
   • 분석 모델을 구현하기 위해서 특정 업체 기술, 특허, 라이선스에 의존해야 하는지 확인함

3) 분석 클래스 검증

1. 분석 클래스 검증의 개념
   • 유스케이스마다 분석 클래스가 적절히 도출되었고, 제어 클래스의 도출 등이 충분하고 상세하게 도출되어 클래스의 역할, 클래스 간의 관계, 메시지 흐름 등을 확인할 수 있는지 검토함
   • 실체(Realization) 관계에 필요한 분석 클래스를 확인함
   • 하나의 유스케이스를 실현하기 위하여 3개 이상의 클래스가 역할 기준으로 도출되어야 함
   • 유스케이스별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부를 확인할 수 있음
   • 유스케이스별로 역할 기준으로 경계, 엔티티, 제어 클래스가 도출되어 스테레오 타입으로 표시되었는지 확인함
   • 유스케이스 이벤트 흐름에 따라 다르지만 일반적으로 유스케이스당 1개의 제어 클래스가 존재하고, 연결된 액터마다 1개의 경계 클래스가 존재하는지 확인함
2. 스테레오 타입(Stereotype)
   • UML의 확장 모델
   • UML의 한정된 모델 요소를 가지고 새로운 어휘를 표현하기 위한 방법
   • 스테레오 타입 객체를 표현할 때 "<< ~ >>"를 사용함