컨커런트하게 할수도 있다는 것이죠. 그리고 만일 UML을 쓰신다면 여러번 생각해보셔야 합니다. UML자체가 웹쪽 프로그래밍에 최적화 되어있는 방법론이다 보니 다른 쪽에서도 효율적일수는 없습니다. 방법론은 부치나 럼보도 여러가지 방법론을 제시하고 있고, XP도 있고, 하여간 많습니다만, 세부설계는 사실상 이런 방법론과는 크게 동떨어져 있습니다.
보통 설계의 방법론도입은 문서화와 여러사람의 작업의 일관성을 가져오기 위함입니다. 하지만, 이것도 모든 사람이 잘 이해하고 제대로 할경우라는 가정일뿐, 실무에서 이런 완벽한 퍼펙트 팀을 본적이 없는게 아쉽군요.
제 생각에는 전체적인 그림은 그냥 DFD로 그리시고, 레벨을 적당하게 조절하여 세분화 하는 작업정도만 하셔도 될듯 합니다.
========================================
* The truth will set you free.
컨커런트하게 할수도 있다는 것이죠. 그리고 만일 UML을 쓰신다면 여러번 생각해보셔야 합니다. UML자체가 웹쪽 프로그래밍에 최적화 되어있는 방법론이다 보니 다른 쪽에서도 효율적일수는 없습니다. 방법론은 부치나 럼보도 여러가지 방법론을 제시하고 있고, XP도 있고, 하여간 많습니다만, 세부설계는 사실상 이런 방법론과는 크게 동떨어져 있습니다.
우선, UML 은 방법론이 아닙니다 . RUP (Rational Unified Process) 나 ICONIX (Rosenberg 나 Kendall Scott 이 사용하는) 가 방법론이고 UML 은 이 방법론에 사용되는 모델링언어입니다 .
일단 원론적인 것을 따져가다보면 UML이란 럼보의 OMT 메서드가 먼저 나오겠군요. 하지만 객체지향적인 부분을 따져보고, 환경의 변화에 유연하게 대처할 수 있도록 보는 시각은 웹쪽이 맞습니다.
UML이 웹쪽에 최적화 되어있다는 것은 개인적인 사견이 아니라 예전에 UML 관련 세미나던가? 에 참석했을때 rational rose 판매에 관련된 문서에서 보았습니다. 그리고 윗분들이 시스템쪽에 사용을 더 한다고 하는데 그건 제가 사용하는 것을 한번도 본적이 없군요. 실제로 OS개발이나 시스템쪽 프로젝트에 보면(실례로 샌프랜시스코 프로젝트와 같은 대형 프로젝트에서도) 휴리스틱 접근법을 많이 사용합니다. 정확한 것보다 대충 이미지를 맞춰놓고 거기서 출발하여 다시 수정하고 결국에 근사값을 찾아가는 쪽을 선호하죠.
그리고 UML은 언어이지만, 그전에 하나의 방법론에 더 가깝다고 생각합니다. 실제로 럼보도 UML은 철학이 담긴 메서드라고 말하니까요. 그리고 철학도 담겨있고요. 하지만, UML이 모든지 가능하다는 것은 오히려 위험한 생각이라고 생각됩니다. 어떤 부분에서 어떤 방법론이나 디자인패턴을 적용하는것은 경험이 우선되어야지 맹목적으로 어떤것을 따르는 것은 잘못된 디자인을 낳는 결과가 아닐까 생각됩니다. 그런면에서 요새 CBD를 너무 옹호하는 것도 불안해 보이네요. 너무 패션에 치중하는 것이 아닐까 생각되서요.
========================================
* The truth will set you free.
UML이 웹쪽에 최적화 되어있다는 것은 개인적인 사견이 아니라 예전에 UML 관련 세미나던가? 에 참석했을때 rational rose 판매에 관련된 문서에서 보았습니다.
여전히 동의할수 없습니다 . 아마도 IBM 의 선전용 문구 같군요 :(
게임발표회때는 UML 이 게임에 최적화 되었다고 말하겠지요 ?
Quote:
그리고 UML은 언어이지만, 그전에 하나의 방법론에 더 가깝다고 생각합니다. 실제로 럼보도 UML은 철학이 담긴 메서드라고 말하니까요. 그리고 철학도 담겨있고요. 하지만, UML이 모든지 가능하다는 것은 오히려 위험한 생각이라고 생각됩니다. 어떤 부분에서 어떤 방법론이나 디자인패턴을 적용하는것은 경험이 우선되어야지 맹목적으로 어떤것을 따르는 것은 잘못된 디자인을 낳는 결과가 아닐까 생각됩니다. 그런면에서 요새 CBD를 너무 옹호하는 것도 불안해 보이네요. 너무 패션에 치중하는 것이 아닐까 생각되서요.
동의합니다 . UML 이 언어이긴 하지만 이미 그것에 모든것이 포함되어있다고 볼수 있지요 . 어느덧 CBD 까지 언급되었는데 저역시도 후반부는 님의 의견과 같은 생각입니다 . 허울좋은 CBD 보다는 잘 돌아가는 2-tier 에 점수를 더 주고 싶네요 . 아직 s/w 의 성능과 기술이 완벽한 객체지향적인 CBD 를 추구하기엔 무리가 있어보입니다 .
다시 범위를 좁혀 처음 질문자의 질문에 응답하자면 ..
UML 이 너무 부담스러우시다면 그중 Use Case Diagram 만 써보시길 추천합니다 . 첫단계의 diagram 이면서 가장 중요하고 가장 핵심이 되는 diagram 입니다 . 시작이 반이랬던가요 ? 이것만 잘 그려도 이미 50%는 끝냈다고 생각됩니다 ;)
질문 문장이 조금 애매모호 한 것 같습니다. ㅡ0-);소스를 문서
질문 문장이 조금 애매모호 한 것 같습니다. ㅡ0-);
소스를 문서화 하는 것은 doxygen 이란 녀석이 유명합니다.
http://www.doxygen.org
그런게 아니라 소스를 짜기 전에 설계하는 것은 UML을 이용한 툴을
다뤄보시는게 좋으실 듯...
검색에서 UML을 치면 될 겁니다.
_____________________________
언제나 맑고픈 샘이가...
http://purewell.biz
물론 설계가 중요합니다만...
모든 프로그램에 있어서 설계가 우선하는 것만은 아닙니다.
컨커런트하게 할수도 있다는 것이죠. 그리고 만일 UML을 쓰신다면 여러번 생각해보셔야 합니다. UML자체가 웹쪽 프로그래밍에 최적화 되어있는 방법론이다 보니 다른 쪽에서도 효율적일수는 없습니다. 방법론은 부치나 럼보도 여러가지 방법론을 제시하고 있고, XP도 있고, 하여간 많습니다만, 세부설계는 사실상 이런 방법론과는 크게 동떨어져 있습니다.
보통 설계의 방법론도입은 문서화와 여러사람의 작업의 일관성을 가져오기 위함입니다. 하지만, 이것도 모든 사람이 잘 이해하고 제대로 할경우라는 가정일뿐, 실무에서 이런 완벽한 퍼펙트 팀을 본적이 없는게 아쉽군요.
제 생각에는 전체적인 그림은 그냥 DFD로 그리시고, 레벨을 적당하게 조절하여 세분화 하는 작업정도만 하셔도 될듯 합니다.
========================================
* The truth will set you free.
Re: 물론 설계가 중요합니다만...
uml이 웹쪽 프로그래밍에 최적화 되어 있는건 아닙니다. 전 게임쪽에 잘 쓰고 있는데요...^^;
UML이 웹쪽에 최적화 되었다는 이야기는 처음들어보는데 , UML은 어
UML이 웹쪽에 최적화 되었다는 이야기는 처음들어보는데 , UML은 어디에도 쓰일수 있는거 아닌가요?
내용을 보더라도 객체로 볼수 있는건 다 쓰일수 있는거 같은데...
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
[quote]컨커런트하게 할수도 있다는 것이죠. 그리고 만일 UML을 쓰
우선, UML 은 방법론이 아닙니다 . RUP (Rational Unified Process) 나 ICONIX (Rosenberg 나 Kendall Scott 이 사용하는) 가 방법론이고 UML 은 이 방법론에 사용되는 모델링언어입니다 .
부치나 럼버를 별도로 언급하셨는데 UML 을 사용하지않는 부치, 럼버는 생각할수 없을것같네요 . 부치 + 야곱슨 + 럼버 => UML 이니까요 .
질문하신분은 방법론이 아닌 모델링을 언급하셨으므로 XP 를 추천하는것도 잘못된 답변같네요 . XP 는 그 어떤 Notification 도 포함하지 않는 방법론이니까요, 단순히 Planning Game 에서도 어떤 noti 를 사용하라는 규정은 없지요 .
개인적으로 UML 은 웹과는 오히려 어울리지 않는것 같습니다 . 게임을 포함한 Win32 Application 혹은 그 서버군 Unix Application 쪽에 더 잘 어울리는것 같네요 .
--
Sang-Kil Park
부연~
일단 원론적인 것을 따져가다보면 UML이란 럼보의 OMT 메서드가 먼저 나오겠군요. 하지만 객체지향적인 부분을 따져보고, 환경의 변화에 유연하게 대처할 수 있도록 보는 시각은 웹쪽이 맞습니다.
UML이 웹쪽에 최적화 되어있다는 것은 개인적인 사견이 아니라 예전에 UML 관련 세미나던가? 에 참석했을때 rational rose 판매에 관련된 문서에서 보았습니다. 그리고 윗분들이 시스템쪽에 사용을 더 한다고 하는데 그건 제가 사용하는 것을 한번도 본적이 없군요. 실제로 OS개발이나 시스템쪽 프로젝트에 보면(실례로 샌프랜시스코 프로젝트와 같은 대형 프로젝트에서도) 휴리스틱 접근법을 많이 사용합니다. 정확한 것보다 대충 이미지를 맞춰놓고 거기서 출발하여 다시 수정하고 결국에 근사값을 찾아가는 쪽을 선호하죠.
그리고 UML은 언어이지만, 그전에 하나의 방법론에 더 가깝다고 생각합니다. 실제로 럼보도 UML은 철학이 담긴 메서드라고 말하니까요. 그리고 철학도 담겨있고요. 하지만, UML이 모든지 가능하다는 것은 오히려 위험한 생각이라고 생각됩니다. 어떤 부분에서 어떤 방법론이나 디자인패턴을 적용하는것은 경험이 우선되어야지 맹목적으로 어떤것을 따르는 것은 잘못된 디자인을 낳는 결과가 아닐까 생각됩니다. 그런면에서 요새 CBD를 너무 옹호하는 것도 불안해 보이네요. 너무 패션에 치중하는 것이 아닐까 생각되서요.
========================================
* The truth will set you free.
[quote]UML이 웹쪽에 최적화 되어있다는 것은 개인적인 사견이 아니
여전히 동의할수 없습니다 . 아마도 IBM 의 선전용 문구 같군요 :(
게임발표회때는 UML 이 게임에 최적화 되었다고 말하겠지요 ?
동의합니다 . UML 이 언어이긴 하지만 이미 그것에 모든것이 포함되어있다고 볼수 있지요 . 어느덧 CBD 까지 언급되었는데 저역시도 후반부는 님의 의견과 같은 생각입니다 . 허울좋은 CBD 보다는 잘 돌아가는 2-tier 에 점수를 더 주고 싶네요 . 아직 s/w 의 성능과 기술이 완벽한 객체지향적인 CBD 를 추구하기엔 무리가 있어보입니다 .
다시 범위를 좁혀 처음 질문자의 질문에 응답하자면 ..
UML 이 너무 부담스러우시다면 그중 Use Case Diagram 만 써보시길 추천합니다 . 첫단계의 diagram 이면서 가장 중요하고 가장 핵심이 되는 diagram 입니다 . 시작이 반이랬던가요 ? 이것만 잘 그려도 이미 50%는 끝냈다고 생각됩니다 ;)
--
Sang-Kil Park
UML
UML 이 웹에 최적화 되어 있다는 얘기는 저도 금시초문일뿐 아니라
오히려 저는 웹분야에는 UML이 덜 적합하다고 생각합니다.
원래 UML은 방법론상의 전통적인 Formalist 들인 람바우, 부치, 야콥슨등이
주축이 되어 각자 제각각이던 방법론들을 하나로 통합시키고자 했던 시도의
결과물입니다. 처음의 의도는 방법론 자체를 통일시키고자 했던것인데..
결과적으로 Notation 만 통일된것이 UML 이라고 볼 수 있습니다.
이후 개별적으로 존재하던 객체지향 프로세스가 또 RUP 라는것으로 통합이
되었고..
이제는 많은 사람들이 RUP+UML 을 객체지향 방법론의 대표적인 사실상의
표준으로 인정하게 된거죠.
UML을 탄생시킨 사람들이 Formal 한 성향을 가진 사람이고...
또 학자들이기 때문에 UML역시 상당히 Formal 한 방법론의
냄새를 갖고 있다고 봐야 되지 않을까 합니다.
그래서 환경의 변화에 유연하게 대처하는 웹분야 프로젝트는
UML과 좀 어울리지 않는다는 생각이 드는군요.
그러한 분야는 오히려 말씀하셨던 XP가 잘 어울리죠.
댓글 달기