소프트웨어공학

구성요소들의 graphic 표현.

-  Class Diagram ( 클래스도 )

-  Object Diagram ( 객체도 )

-  Use Case Diagram ( 쓰임새도 )

-  Sequence Diagram ( 순서도 )

-  Collaboration Diagram ( 협력도 )

-  State Diagram ( 상태도 )

-  Activity Diagram ( 활동도 )

-  Component Diagram ( 컴포넌트도 )

-  Deployment Diagram ( 배치도 )

1. Class Diagram

개요

   시스템의 논리적인 구조 ( 클래스 ) 를 표현한다.

   Class , Interface , Collaboration간의 관계를 나타낸다.

   객체지향 개발에서의 가장 공통적으로 많이 사용된다.

   Class Diagram : 시스템의 정적 설계도.

   Active Class Diagram :  시스템의 정적 Process도.

특징   

   시스템의 요구사항에 표현된 작업 즉, 시스템이 처리해야 하는

   작업에 대한 책임을 분할 한 것이다.

   모델은 점점 증가되며 관련된 클래스들끼리 패키지화 한다. 

   클래스를 너무 작게 쪼개거나 기능을 너무 많이 포함하면 

   안되며 적절한 방법으로 구현한다.

1) Class 명

   모든 Class는 다른 Class들과 구별되는 유일한 이름을 갖는다.

   단순명 ( Simple Name ) : Class 이름만을 표현.

   경로명( Path Name ) : Package명을 포함하여 표현.

동작 ( operation )

  의미 있는 동사형으로 표현.

2) 내부 클래스 

3) Dependency ( 의존 관계 )

‘using’ 관계를 나타난다.

하나의 모델요소가 다른 모델요소를 사용하는 관계.

사용되는 모델요소가 변경되면 사용하는 모델요소가 영향을 받는다. 역은 성립하지 않는다.

UML 표기법은 점선으로 된 화살표로 표현한다.

화살표의 방향은 사용하는 쪽에서 사용되는 쪽으로 향한다.

Dependency ( 의존 관계 ) 적용 예

  사용되는 클래스가 사용하는 클래스의 메소드 parameter 로 사용 되는 경우.

  사용되는 클래스가 사용하는 클래스의 메소드 로컬변수로 사용되는 경우.

  사용되는 클래스가 사용하는 클래스의 전역변수로 사용되는 경우.

4) Generalization ( 일반화 관계 )

   여러 클래스가 가진 공통적인 특징을 추출하여 공통적인 클래스로 일반화시키는 것을 의미한다.

   반드시 클래스간 ‘is a’ 관계이어야 한다.

   객체지향언어에서는 상속관계를 의미한다.

 

5) Abstract (추상화)

Abstract 는 이탤릭체로 표현

6) Association ( 연관 관계 )  

클래스로부터 생성된 인스턴스들 간의 관계를 표현한다.

Dependency 와 Generalization 관계는 단순히 클래스들간의 관계를 나타낸다.

classifier로부터 생성된 인스턴스 사이의 관계를 나타낸다.

상대방의 인스턴스를 가리킬 수 있는 attribute를 가진다.(코드상)

참조할 수 있는 attribute는 UML상에서 표현하지 않는다.  

표현하고자 할 경우 role name을 이용한다.

* Classifier : interface , Class , Component와 같이 인스턴스화 될 수 있는 요소.

7) Aggregation ( 집합 연관 관계 )

  전체와 부분을 나타내는 모델요소이다. ( Whole – part )

  전체를 나타내는 클래스와 이를 이루고 있는 부분 클래스 관계를 나타낸다.

  ‘has a’ 관계이다.

  전체와 부분은 서로 독립적인 관계이다.

  즉, 생명주기가 동일하지 않다.

8) Composition ( 복합 연관 관계 )  

  전체와 부분을 나타내는 모델요소이다. ( Whole – part )

  전체를 나타내는 클래스와 이를 이루고 있는 부분 클래스 관계를 나타낸다.

  ‘has a’ 관계이다.

  전체와 부분이 동시에 생성되고 동시에 소멸된다.

  즉, 생명주기가 동일하다.

9) Realization ( 실체화 , 실현화 )  

인터페이스와 실제 구현된 클래스간의 관계이다.

10) 인터페이스 확장 

  인터페이스는 컴포넌트간의 결합력을 느슨하게 한다.  ( loose coupling )

  인터페이스는 프로그램의 수정 없이 쉽게 소프트웨어를 확장할 수 있다.

11) Package

  UML 모델요소들을 조직화하고 계층화 한다.

  package는 각각의  Name space 를 갖는다.

   즉, package만 다르면 동일한 컴포넌트를 가질 수 있다.

※ 주의할 점  

   일반화는 ‘is a’ 관계인 경우에만 사용된다.

   일반화 관계를 균형 있게 유지한다. ( 세분화 주의 )

   가능하면 관계를 이루는 interaction이 교차되지 않도록 주의한다.

   이해하기 쉬울 정도의 관계만을 표현한다.

 ( 너무 자세한 관계표현은 오히려 복잡해질 수 있다. )

   관련 있는 클래스들을 가까운 곳에 배치한다.