'Java'에 해당되는 글 37건

허니몬에 관한 보고서
프로그래밍이란 것이 5개월 동안 해서 손쉽게 되는 거면, 누구나 프로그래머가 될 수 있을 겁니다.

그리고 '나 프로그래머에요.'라고 하면 '우와'하고 쳐다보는 이들은 없을 겁니다.

하지만, 그만큼 프로그래머가 되기 위해서는 많은 것을 공부해야하고 끊임없이 공부를 해야 합니다. ^^;

몇 년전, 프로그래머가 되고 싶었습니다.

잠시 다른 길을 선택했습니다. 먼 길을 돌아서 지금 다시 프로그래머로서의 꿈을 키워가고 있습니다.

누군가가 저를 보고 '프로그래밍 좀 합디다!?' 하고 말해주었으면 좋겠습니다. ㅎㅎ

그래서 일까요...ㅡㅅ-)?

전 과는 다른 마음가짐과 태도로 공부를 하게 되었습니다.

남들과 함께 하고 있지만, 그들보다 앞으로 나아가고, 다른 사람들 앞에서 당당해지고 싶습니다.

그게 내가 가지고 있는 내 자아의 목마른 자신감의 표출인 듯 합니다.

^^; 당분간은... 고리타분하고 두서없고 편향적인 이야기들이 올라올 가능성이 높습니다.

하지만, 너그러운 마음으로 이해해주세요~~ ^^*
사용자 삽입 이미지
이렇게 웃고 있잖습니까. +_+)b ㅎㅎ 웃는 얼굴에 침뱉으시면!!
그래도 웄지요. ㅋㅋ OTL.... 폭력반대!!
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'
http://xrath.com 에서 번역한 내용입니다.

Java SE 6 한글 문서 : http://xrath.com/javase/ko/6/docs/ko/
Java SE 6 한글 문서 다운로드 : http://xrath.com/files/jdk-6-docs-ko.zip

자세한 내용은 http://xrath.com/blog/entry/697 를 참고하세요. ^^
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'
JAVA 언어로 배우는 디자인 패턴 입문
카테고리 컴퓨터/IT
지은이 유키 히로시 (영진닷컴, 2008년)
상세보기

이 책의 서두에는 책의 내용에서 사용하는 UML에 대한 설명이 나와있습니다. ^^; 이 글은 그 내용을 그대로 옮겨적은 글입니다. 개인적으로 UML 을 보게 될 때 사용하려고 작성한 문서입니다. ^^; 다른 분들도 참고만 해주세요.



● UML

UML은 Unified Modeling Language의 약자로, 시스템을 시각화하거나 시스템의 사양이나 설계를 문서화하기 위한 표현방법입니다.

UML Resource page -
http://www.omg.org/uml/


● 클래스 다이어그램

UML의 클래스 다이어그램(Class Diagram)은 클래스나 인스턴스, 인터페이스 등의 정적인 관계를 표현한 것입니다. 클래스 다이어그램이라는 이름으로 불리지만, 클래스만 등장하는 것은 아닙니다.


● 클래스와 계층 관계

그림 0-1은 Java 프로그램과 대응하는 클래스 다이어그램의 예입니다.

Fig0-1.jpg

그림 0-1은 ParentClass와 ChildClass라는 두 클래스의 관계를 표시하고 있습니다. △이 붙어있는 실선의 화살표(①)는 클래스의 계층관계를 표시하고 있습니다. 화살표는 하위 클래스에서 상위 클래스로 향하고 있습니다(이를 테면, 이것은 extends의 화살표입니다).

ParentClass는 ChildClass의 상위 클래스이고, 반대로 말하면 ChildClass는 ParentClass의 하위 클래스입니다. 상위 클래스를 기저(基底) 클래스나 부모 클래스, 하위 클래스를 파생 클래스나 자식 클래스 또는 확장 클래스라고도 합니다. 각각의 클래스는 직사각형으로 표현합니다. 직사각형을 수평선으로 분할하여

- 클래스의 이름

- 필드의 이름

- 메소드의 이름

을 순서대로 적습니다. 이름뿐만 아니라 부가적인 정보(액세스 제어나 메소드의 인수나 형태 등)를 쓰는 경우도 있고, 반대로 주목할 필요가 없는 항목은 생략하는 경우도 있습니다(따라서, 클래스 다이어그램에서 소스 프로그램을 복원할 수 있는 것은 아닙니다).

abstract 클래스(추상 클래스)의 이름은 이탤릭체를 사용합니다. 예를 들어, 그림 0-1에서 ParentClass는 추상 클래스이므로 이탤릭체로 되어 있습니다.

static 필드(클래스 필드)의 이름에는 밑줄을 사용합니다. 예를 들어, field2는 클래스 필드이므로 밑줄이 그어져 있습니다.

abstract 메소드(추상 메소드)는 이탤릭체를 사용합니다. 예를 들어, ParentClass의 MethodA는 추상 메소드이므로 이탤릭체로 되어 있습니다.

static 메소드(클래스 메소드)의 이름에는 밑줄을 사용합니다. 예를 들어, ChildClass의 methodC는 클래스 메소드이므로 밑줄이 그어져 있습니다.

화살표의 방향

UML에서는 하위 클래스에서 상위 클래스를 향해 화살표가 뻗어 있습니다. 상위 클래스를 기준으로 하위 클래스를 만들기 때문에 화살표를 반대로 이해하는 것이 이해하기 쉽다고 생각할지도 모릅니다.

다음과 같이 생각하면 이해하기 쉽습니다. 하위 클래스를 정의할 때 extends로 상위 클래스를 지정합니다. 따라서 하위 클래스는 반드시 상위 클래스를 알고 있습니다. 그러나 상위 클래스는 하위 클래스를 알고 있다고 할 수 없습니다. 상대를 지목할 수 있는 것은 상대를 알고 있을 때 뿐입니다. 그래서 하위 클래스에서 상위 클래스로 화살표를 표시하는 것입니다.


인테페이스와 구현

 그림 0-2도 클래스 다이어그램의 예입니다. 이 그림은 Printable이라는 인터페이스가 있고, PrintClass라는 클래스가 Printable 인터페이스를 구현하고 있는 것을 나타내고 있습니다. 이 책에서는 추상 클래스와의 유사성을 강조하기 위해 인터페이스 이름에 이탤릭체를 사용하고 있지만, 일반적으로는 이탤릭체를 사용하지 않는 경우도 많이 있습니다.

 △가 붙은 점선의 화갈표는 인터페이스와 구현 클래스의 관계를 나타내고 있습니다. 화살표는 구현 클래스에서 인터페이스를 향하고 있습니다(말하자면, 이것은 implements의 화살표입니다. UML에서 Java의 인터페이스를 표현하는 경우에는 <<imterface>>라고 씁니다.

Fig0-2.jpg

 

집약

그림 0-3도 클래스 다이어그램의 예입니다. 이 그림에서는 Color, Fruit, Basket 이라는 세 클래스의 관계를 나타내고 있습니다. Basket 클래스의 fruit 필드는 Fruit 클래스의 배열이 되 있고, Basket 클래스의 인터페이스는 Fruit 클래스의 인스턴트를 여러 개 가집니다. 또한 Fruit 클래스의 color 필드는 Color 클래스형으로 되어 있고, Fruit 클래스의 인스턴스는 Color 클래스의 인스턴스를 1개 가집니다. 바꾸어 말하면, 바구니에 과일이 몇 개인가 들어있고, 과일은 각각의 색을 가지고 있는 관계입니다.

이와 같은 ‘갖고 있는’ 관계를 ‘집약(aggregation)’이라고 합니다. 인스턴스를 갖고 있으면 개수에 상관없이 그 관계는 집약입니다. 배열을 사용하고 있어도, java.util.Vector 클래스를 사용하고 있어도, 어떤 구현이라 해도 인스턴트를 갖고 있으면 그 관계는 집약입니다.

◇이 붙은 선은 집약을 나타냅니다. 마름모꼴 모형의 접시 위에 물건이 놓여있다고 생각하면 됩니다.


액세스 제어

 

그림 0-4도 클래스 다이어그램의 예입니다.

Fig0-3.jpg

그림 0-4에서는 메소드나 필드의 액세스 제어를 표현하고 있습니다. UML에서 액세스 제어를 표현하고 싶은 경우, 메서드나 필드의 이름 앞에 기호를 붙입니다.

▪ + 가 붙어있는 경우 : public인 메소드나 필드를 나타냄. 액세스 가능

▪ - 가 붙어있는 경우 : private인 메소드나 필드를 나타냄. 외부에서 액세스 가능

▪ # 가 붙어있는 경우 : protect인 메소드나 필드를 나타냄.

▪ ~ 가 붙어있는 경우 : 동일한 패키지 내에서만 액세스할 수 있는 메소드나 필드

클래스의 관계

클래스의 관계를 나타내기 위해 관련된 이름에 ▶ 표시를 붙여줍니다. 그림 0-5는 클래스의 관계를 나타냅니다.

Fig0-4.jpg

 

시퀀스 다이어그램

UML의 시퀀스 다이어그램(Sequence Diagram)은 프로그램이 작동할 때 어떤 메소드가 어떤 순서로 실행되는가, 어떤 추상 클래스가 어떤 순서로 실행되는가를 표현한 것입니다.

클래스 다이어그램은 ‘시간에 의해 변하지 않는 것(정적인 관계)’를 나타냅니다. 반면에 시퀀스 다이어그램은 ‘시간에 따라 변하는 것(동적인 관계)’를 나타냅니다.

 

● 처리의 흐름과 오브젝트(객체) 간의 협조 동작

그림 0-6은 시퀀스 다이어그램의 일례입니다.

Fig0-5.jpg

그림 0-6의 오른쪽이 시퀀스 다이어그램입니다. 왼쪽에는 대응하는 Java 프로그램의 일부를 표시하고 있습니다. 이 그림에는 세 개의 인스턴스가 등장하고 있습니다. 인스턴스는 각각 다이어그램의 위쪽에 있는 직사각형에 대응하고 있습니다. 직사각형 안에는 :Client, :Server, :Device와 같이 콜론(:) 뒤에 클래스 명을 표기하고 밑줄이 그어져 있습니다. 이것은 각각의 Client 클래스의 인스턴스, Server 클래스의 인스턴스, Device 클래스의 인스턴스를 표시하고 있습니다. 각각의 인스턴스에 이름이 필요할 경우에는 server:Server와 같이 콜론 앞에 이름을 적습니다.

 

각각의 인스턴스에서 아래 방향으로 뻗어있는 점섬을 라이프 라인이라고 합니다. 여기에서 시간은 아래 방향으로 흐른다고 생각하십시오. 위쪽은 과거아래쪽은 미래입니다. 라이프 라인은 인스턴스가 존재하는 동안만 존재합니다. 라이프 라인의 중간에 가늘고 긴 직사각형은 오프젝트(객체)가 이동 중인 것을 나타냅니다.

가로 방향으로 화살표가 그려져 있습니다. open 이라고 라벨이 붙은 화살표를 봅시다. 앞이 검은 화살표(─▶)의 실선은
메소드의 호출을 표시합니다. 여기서는 client 가 server의 open 메소드를 호출한 것을 나타내고 있습니다. open 메소드를 호출했기 때문에 server 인스턴스가 활동하게 되고 가늘고 긴 직사각형으로 시작되었습니다.

 

open의 화살표에서 시작한 server의 가늘고 긴 직사각형의 아래쪽에서 client 쪽으로 점선의 화살표(◅┄)가 뻗어 있습니다. 이것은
open 메소드에서의 리턴(반환)을 표시하고 있습니다. 이 그림에서는 모든 메소드의 리턴을 그리고 있지만 생략하는 경우도 있습니다. 제어가 client로 되돌아왔기 때문에 server 인스턴스가 활동 중인 사각형은 일단 종료됩니다.

 

또한 같은 방법으로 print 메소드가 호출됩니다. 이번에는 print 메소드 안에서 다시 device 인스턴스의 write 메소드를 호출하고 있습니다.

이와 같이 여러 개의 인스턴스 간의 행동을 도식화할 수 있습니다. 시퀀스 다이어그램은 라이프 라인을 따라가면서 위에서부터 순서대로 읽어 갑니다. 그리고 화살표가 있으면 그것을 따라가면서 인스턴스 간의 협조 동작을 확인해 갑니다.

이 글은 스프링노트에서 작성되었습니다.

1 ··· 4 5 6 7 8
블로그 이미지

Email : ihoneymon@gmail.com 안녕하세요, 꿀괴물 입니다. ^^ 멋진 비행을 준비 하는 블로그 입니다. 만능형 인간이 되어 많은 이들에게 인정받고, 즐겁고 행복하게 살기를 간절히 원합니다!! 달콤살벌한 꿀괴물의 좌충우돌 파란만장한 여정을 지켜봐주세요!! ^^

허니몬