클래스 다이어그램(UML) 정리

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

이름

심플형태(단순명) : 클래스 이름만을 표현        예) String

패스형태(경로명) : :: 경로를 같이 표현            예) XX::String

속성(Attribute)

의미 있는 명사형으로 표현

Visibility Name : Type = Default Value

Visibility : + public, - private(생략), #protection

Name : Attribute Name

Type : Attribute Type

Default Value : Attribute Default value

예를 들어 여기까지 이름과 속성으로 완성된 클래스의 모습은

MyDate (1)

(2)   - day : int    - month : int   - year : int = 2007

(1)이 이름 클래스 이름이고 (2)가 속성 변수들이다.

그런데 day : int가 다른거랑 좀 특이하게 밑줄이네? 이건 static을 나타낸다.

동작(operation)

의미있는 동사형으로 표현

Visibility Name(Parameter - List) : Return - Type - Expression[Property - String]

1. 기본형태

Rectangle

add() grow() move() isEmpty()

2. visibility랑 인자값을 같이 표현함

MyDate

+ getDay()  + SetDay(d : int)

3. Stereotype 타입으로 표현 UML의 한정된 모델요소를 가지고 새로운 어휘를 표현하는 방법

표준에 더해서 만든것임.. 아래의 << >> 이 부분을 이야기함..사용자가 그냥 편하게 만드는것임..

MyDate

<<constructor> +MyDate() <<getter> + getDay() <<setter> + SetDay(d : int)

다양한 클래스 다이어그램 표기법

Outer

+Outer() +getInner() _setInner()

* Outer클래스에 안에 있는 Inner클래스를 표현한것

Outer::Inner

+Inner() +getInner() +setInner()

Active Class 프로그램의 실행을 주도하는 클래스(이것을 제외한 모든것들은 Passive Class이다 위에 모두 이거임)

Test

+main()

이렇게 외곽선이 두껍다!!

---

클래스들과의 관계 릴레이션쉽을 알아보자

1. 의존

2. 연관( 집합관계, 컴포지션관계)

3. 일반화

4. 실체화

1. 의존관계(Dependency)

using 관계를 나타난다.

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

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

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

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

한 클래스가 다른 클래스를 사용하는 사용관계(밑에와 비슷한 예로 프로그래머 -----> 컴퓨터 이런 관계다)

실제코드에서 적용되는 예

사용되는 클래스가 사용하는 클래스의 메소드 파라매터로 사용되는 경우

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

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

인스턴스 변수는 제외 (다른 관계로 표현을 할 수 있다.)

2. 일반화 관계(Generalization)

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

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

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

뜬금포로... 추상클래스 표현은??

클래스 이름

+ 메소드1() + 메소드2()

만약에 이름이 옆으로 누우면 추상클래스를 뜻함. 그래서 메소드1도 추상메소드임..

메소드2는 Concrete Method라고 하고 구현이 된 메소드라고 한다. ( 클래스 이름이 기울지 않은면?/ 그건 Concrete 클래스 ㅋㅋ 오우)

3. 연관관계(Association)

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

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

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

(코드상이다..??UML상에서는 표현하지 않음..구지 표현한다면..role name?이용)

방향이 있다.

단방향 : unidirectional association

양방향 : bidirectional association

두가지 인스턴스가 있는것.. Customer과 Clerk있다.

그 인스턴스들간에는 양방향임..화살표가 양방향..그리고 클래스 옆에 이름이 붙었는데..

-customer -clerk..이게 바로 롤네임이다. 이 롤네임이 뭐냐면..attribute이다 이거야..

그리고 아래 Multiplicity는 개수를 표현한다. 그리고 또 '흥정한다'이름 자체가 어쏘시널 네임이 된다. (연관관계 이름이라고..) 표시가 또는

흥정한다 ▶ 이런식으로도 표현이 되고

저 가운데 선의 방향이 없을수도 있는데 없는건 있는거랑 같은 표현이다

아래 화면처럼 연관관계가 되려면

멤버변수에 들어가야한다는것인데.. 이게 과연 자바에만 해당되는 이야기 인지..는 모르겠다 더 찾아봐야함..??엥?

아래 멤버변수가 서로 물린게 기본이라는데...

서로 멤버변수가 상태는 private 이다.

**집고 넘어가야할것 Star UML에서 어쏘시널 사용법에 대해서 알아야함..약간 다름..

3. 연관관계 - 집합 연관관계(Aggregation)

has - a 관계이다.

전체와 부분은 서로 독립적인 관계이다.(whole - part가 독립적이다....여기서 홀이 전체 부분은 파트임..)

독립적이다! 이것은 생명주기가 다르다는것이다..생명주기..소멸 생성!

전체와 부분을 나타내는 모델요소이다.

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

여기서 보면 role name도 되고 multiplicity도 되는것처럼 보인다.. 그리고 집합 연관 관계에서 중요한것..빈 마름모가 나와야한다.

3. 연관관계 - 복합 연관관계(Composition)

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

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

당연히 이것도 has - a관계이다.(위와 같음..)

그러나 전체와 부분이 동시에 생성되고 동시에 소멸된다. 즉, 생명주기가 동일하다. 위에 집합 연관관계와의 차이점이다.

속이 꽉찬 마름모 형태로 된다.

4. 실체화(Realization)

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

표현방법은 2가지이다. 위에 원이냐. 아래의 스테레오 타입으로 하느냐..

인터페이스 확장??!!

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

  - 왜 느슨해야하지? 느슨하게 하지않으면..한쪽에서 수정이 발생되면..수정된 컴퍼넌트와 연결된 컴퍼넌트들은 수정의 영향을 받게 된다.

  - 

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

5. 팩키지(Package)

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

package는 각각의 Namespace를 갖는다. 즉 그냥 패키지가 namespace 다.

주의할점..

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

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

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

이해하기 쉬울 정도의 관계만을 표현한다. 그림으로 그리는 이유는 누구라도 쉽게 이해하기 위함이다.

관련있는 클래스는 가깝게 그린다.

이 내용을 기반으로 아래의 참고 사이트를 보면 도움되더라..

http://hongjinhyeon.tistory.com/25