현재 위치

홈 ›› Forums ›› 공부 ›› 프로그래밍 QnA

C로 개발할 프로그램을 설계할때 UML을 그리는게 도움이 될까요?

superkkt의 이미지
글쓴이: superkkt / 작성시간: 화, 2006/12/12 - 11:16오전

안녕하세요.

지금 C로 개발하려고 하는 프로그램을 대충 설계를 하고 코딩을 들어가려고 하는데요. 마땅히 사용할 줄 아는 툴이 없어서 MS-WORD에다가 그냥 적어나가고 있습니다. 일단 필요한 모듈을 분리하고, 모듈별로 들어갈 함수를 분리하고, 함수별로 pseudo code를 적어나가는 과정으로 설계를 하고 있습니다. 근데 이게 규모가 커지니까 설계한 문서 보는게 코딩하는것보다 더 복잡하게 되어버렸네요.

그래서 뭔가 좋은 툴이 없을까 살펴보다가 UML이 괜찮겠다 싶어서 좀 뒤져봤습니다. 일단 staruml을 사용해서 좀 살펴봤는데요. 근데 UML은 객체지향언어로 개발할때 사용하는것이 적절할것 같다는 생각이 드네요. 일단은 급한대로 제가 프로그램의 전체적인 흐름을 이해하기 위해서 staruml에서 대충 그림 그리면서 사용해보려고 합니다. 그런데 이것도 제대로 사용안하고 이렇게 나가다간 규모가 커지면 역시나 쓸모 없어질것 같은 느낌이 드네요.

UML로 C 프로그램을 설계하기가 까다롭다면 UML 외에 다른 좋은 방법은 뭐가 있을까요? 그냥 파워포인트로 그림 그리면서 하는게 좋을까요? ^^

Forums: 
프로그래밍 QnA
ballon8016의 이미지

글쓴이: ballon8016 / 작성시간: 화, 2006/12/12 - 11:21오전

사실 C++로 프로젝트를 한다면 문제는 없겠지만 현업에서 C로 작업하는 경우가 많은데
아무래도 설계도 없이 건물을 짓는 느낌을 지울수가 없어서 아쉽네요~
고수분들의 경험담을 들려주시면 많은 도움이 될꺼 같습니다..^^

꿈을 이룰수 있는 사람은 오직 꿈을 갖는 자만이다....

lovewar의 이미지

글쓴이: lovewar / 작성시간: 화, 2006/12/12 - 11:53오전

C 파일 구조를 하나의 클래스로 인식하여 응용하시면 도움이 될 겁니다.

클래스 다이어그램 응용

C 파일 구조 = 클래스
C 파일 변수 = attribute 영역
C 파일 함수 = operation 영역
C 파일 매크로 = attribute 영역
C 파일 매크로 함수 = operation 영역
C 파일 헤더파일 = 클래스의 연관관계
C 파일 구조체(사용자정의) = 클래스의 inner 클래스로 표현

이 정도로 응용하시면 도움이 될 것 같습니다.
C 코드들을 UML형태로 보여주는 도구(역공학)들이 존재합니다.
좀 더 찾아 보시고 응용하시면 도움이 되지 않을까 생각합니다.

superkkt의 이미지

글쓴이: superkkt / 작성시간: 화, 2006/12/12 - 11:56오전

답변 감사합니다. 저도 그 정도 범위에서 대충 대입해서 그려볼려고 합니다. 그런데 말씀하신 역공학 툴이 이미 존재하는 C 코드를 UML 형태로 변환해주는 기능인가요? 그렇다면 프로그램 이름이라도 혹시 알 수 있을까요? UML을 그리는데 참조하는 용도로 사용하면 좋을것 같군요.

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

lovewar의 이미지

글쓴이: lovewar / 작성시간: 화, 2006/12/12 - 1:18오후

기억력이 희미해서 File Diagram으로 찾아 보시면 될 것 같습니다.
그리고, rational 쪽에도 C와 OO를 매핑해 놓은 자료들이 존재하지 않을까 하는 생각을 해 봅니다.

참고로 국내에는 soft4soft사의 RESORT란 도구가 있습니다.

마잇의 이미지

글쓴이: 마잇 / 작성시간: 수, 2006/12/13 - 12:56오후

손으로 끄적거려서 부담될정도의 분량이면 안그리시는게 좋을것 같습니다.

프로젝트 전체의 큰 그림을 설명하는 짤막한 한두장의 문서
부분 부분의 사용된 기법을 설명하는 짤막한 글 내지는 그림(UML)

정도의 문서만 작성하는게 개발자 자신을 위해서나 사용자를 위해서나 좋을 것 같습니다. 사용자를 위한 도움말은 물론 별도이구요.

이삼십개 넘어가는 상자 갯수를 가진 UML을 보면 과연 이것은 누구를 위한 것인가 하는 생각이 들면서 멍해집니다.

그걸 이해할 시간에 코드를 보는게 좋고 그때 개발자의 짤막한 요약과 부분부분에 쓰여진 기법들에 대한 설명은 아주 도움이 되더군요.
--
마잇


--
마잇

superkkt의 이미지

글쓴이: superkkt / 작성시간: 수, 2006/12/13 - 1:35오후

으음.. UML이 쉽지가 않군요. 시간 날때마다 책 보면서 공부하는 중인데, 객체지향에 적합한 UML을 절차지향 언어에 맞게 사용하려니 더더욱 복잡하네요. 아~ 심플하면서도 제 머리속에 있는 소프트웨어 설계에 관한 모든 내용을 한번에 쫙 전개시킬 수 있는 툴 어디 없나요~~

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

lovewar의 이미지

글쓴이: lovewar / 작성시간: 수, 2006/12/13 - 1:56오후

어떤 소프트웨어 설계를 하고 계신지 그리고 그를 어떻게 설계도로 만들어 낼 것인지
궁금합니다.

혹시 어떤 다이어그램들이 필요한건지 알수 있나요? 아니면 어떤 행위를 하는 설계도들이 필요한지
에 대해 이야기를 들려 줄수 있나요? 간접적인 경험이 될 것 같습니다.

superkkt의 이미지

글쓴이: superkkt / 작성시간: 목, 2006/12/14 - 9:42오전

멀티쓰레드 기반의 백업 소프트웨어 엔진을 개발하려고 합니다. 네트웍 프로그래밍 프레임웍은 심플하게 자체 구현한 프로그램을 사용하고요.

이미 구현을 해서 테스트까지 진행했었는데 설계 없이 무작정 코딩부터 한 경우였습니다. 거기다 진행 중에 추가 요구사항도 반영이 되어서 코드가 제 통제 범위를 벗어났었죠. 그래서 폐기하고 다시 설계 과정부터 시작했습니다.

일단 설계 경험도 전무하고 사용할줄 아는 툴도 없어서 워드 문서에다 끄적거리기 시작했습니다. 프로그래을 기능별로 단위 모듈로 분할하고, 각 모듈별로 필요한 자료구조와 함수를 정의하고, 마지막으로 개별 함수의 pseudo code를 작성하는 식으로 진행했죠. 그런데 이렇게 설계를 진행하다보니 워드 문서의 페이지가 많아지기 시작했고 뭔가 변경하거나 추가하려면 그 과정이 꽤 복잡해졌습니다.

그리고 워드 문서다보니 프로그램에 대해 시각적으로 표현하는 부분이 없어서 저 스스로도 전체 구조에 대해 햇갈릴때도 있었구요. 이건 제가 머리가 나빠서 그런것도 있겠군요. ^^

아무튼 제가 원하는것은 전체적인 구조, 각 모듈별 자료구조와 함수에 대한 정보, 모듈 사이의 연관성 그리고 pseudo code까지 포함 할 수 있는 설계 툴 입니다. 사실 지금 말한 것들은 모두 손으로 직접 그리거나 파워포인트로 만들수도 있습니다. 하지만 저는 좀 더 쉽고 단순하게 위의 것들을 만들고 관리할 수 있는 툴이 필요한 것입니다. 그리고 그것이 UML이 아닐까 생각해서 공부하고 있고요.

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

lovewar의 이미지

글쓴이: lovewar / 작성시간: 목, 2006/12/14 - 1:04오후

사용해 본 도구는 rose나 together 그리고 starUML입니다.

이전까지는 rose(IBM)나 together(Borland)를 사용했습니다. 좋긴 하지만, 유료란
그 중압감에 무료도구(starUML)로 바꿨습니다.

사용해 보시면 rose와 together의 사상이 약간은 다른걸 느끼실 수 있을겁니다.
// 지금은 또 어떻게 변화하고 있는지는 모르지만, 함 살펴보시는 것도 좋겠습니다(미래의 방향성을 볼 수도 있을 겁니다).
// 표현하고자 하는 것이라면 rose나 together에 대부분 있을(pseudo code는 주석란 이용) 겁니다.
// 어느정도 숙지 후에 전문적인(?) 사용에 대한 UML 교육을 받아 보시는 것도 좋을 것 같습니다(있는지는 모르겠습니다).

superkkt의 이미지

글쓴이: superkkt / 작성시간: 목, 2006/12/14 - 1:07오후

회사에서 사용하려고 하는데 유료 소프트웨어 사달라고 할 처지가 아닙니다. 그래서 StarUML 사용하려고 하고요. "실용적 객체지향 분석과 설계를 위한 UML과 UP" (김정아 역 / Addison Wesley) 책을 보고 있는데 이거 용어가 좀 어렵군요. 번역서라서 그런가..

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

dormael의 이미지

글쓴이: dormael / 작성시간: 수, 2006/12/13 - 2:13오후

저도 마잇님과 같은 의견입니다.

아무리 잘 정리된 문서라 할지라도 갯수가 늘어나면 작성자 본인 조차도 그리거나 수정하는 시간, 보고 이해하는 시간에 너무 많은걸 빼앗기게 됩니다.
본인이 아닌 경우에는 더욱 문제가 심해지죠.

물론, 본인이 그때그때 해결해야할 문제에 대해 시각적으로 표현해 놓고 고민을 하기 위한 용도라면 상관이 없습니다.
이런건 그냥 어떤 그림이건 도구가 무엇이건 상관이 없죠. 자신만 잘 이해할 수 있으면 되니까요.

객체지향 언어를 사용한다고 하더라도 문서의 수나 문서내의 개체 수가 늘어난다면 비추입니다.

문서화 잘하고 프로세스가 잘 갖추어져 있다고 하는 국가나 분야의 사람들이 이런 생각을 조금씩 가지고 대안을 생각하고 있는걸 보면 어느정도는 지나친 문서화에 대해서 회의론이 일고 있는것 같습니다.

심플하면서도 머리속에 있는 소프트웨어 설계에 관한 모든 내용을 한번에 쫙 전개시킬 수 있는 툴은 없다고 봅니다.
설계를 그렇게 하는게 제일 좋은 방법 같습니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

notpig의 이미지

글쓴이: notpig / 작성시간: 수, 2006/12/13 - 10:12오후

간단히 UML 에는 행위와 구조를 모델링 할수 있습니다.

Class Diagram 은 대표적인 구조를 모델링 하기 위한 다이어 그램 입니다.
UML 의 일부일 뿐입니다.

Class Diagram 으로 C 언어의 구조를 표현하는것은
C 언어의 함수 포인터를 자유자재로 사용하는 수준의 내공이 필요합니다.

그리고 UML의 올바른 목적이 설계를 한후에 코드 구현입니다.
만들어진 코드를 Class Diagram 으로 변경하는건 UML 을 잘못 사용하는것입니다.

Class Diagram 으로 작성된 모델이있울때
그걸 C 코드로 표현하는건 따른 문제 입니다.
하지만 C 를 Class Diagram으로 표현하는것보단 훨씬 쉽습니다.

추가: 제목에 대한 답변을 하면
UML 로 C 프로그램을 설계하는건 도움이 됩니다.
다만 UML 을 효율적으로 사용 할 경우에 도움이 됩니다.
효율적으로 사용하지 못할경우엔 쓸데없는 작업일 뿐입니다.
How can I handle googol(10^100) state by SMV???

moonlit의 이미지

글쓴이: moonlit / 작성시간: 수, 2006/12/13 - 11:47오후

대부분은 UML중에서 Use Case Diagram과 Class Diagram만을 사용한다고 하더군요.

notpig의 이미지

글쓴이: notpig / 작성시간: 목, 2006/12/14 - 1:42오전

다른 다이어그램을 어떻게 사용해야할지를 아실려면

Rational Rose Realtime,
Rhapsody,
Telelogic TAU

등을 사용해보시기 바랍니다.
UML이 Class Diagram 만이 아니란걸 아실껍니다.

번역서 제목이 상당히 맘에 안들지만
http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200409100019
도 참고 할만 합니다.

How can I handle googol(10^100) state by SMV???

sunyzero의 이미지

글쓴이: sunyzero / 작성시간: 목, 2006/12/14 - 3:10오전

대부분의 경우에 데이터의 흐름 구조가 중요하기 때문에, DFD 를 잘 그려주고 파일/라이브러리들의 계층 구조만
설명을 제대로 해놓았다면 대부분의 C 프로그래머들이 어렵지 않게 이해합니다.

너무 길고 잡다한 문서는 오히려 헷갈리게 합니다. 따라서 저는 1-2 depth level 을 넘어가지 않는 범위에서
DFD를 작성하는게 제일 좋다고 봅니다.

그리고 기술적인 부분이 많은 부분은 주석문 한줄이 큰 도움이 되죠. 세세한 부분도 전부 DFD 로 그려두면 종종 변경될때마다
이 문서 업데이트하는 것도 정말 짜증날정도로 일이 많아집니다. 더군다나 co-work 하는 경우라면 문서 버전 관리도 더 복잡해지죠.

그래서 세세한 것들은 소스코드내에 주석으로 대체하는게 좋다고 봅니다.(주석도 적당하게...과유불급!!)
하지만 간혹 변수들의 의미 조차도 주석에 없으면 원래 프로그래머를 찾아서 뗏찌하고 싶어집니다.

========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.

========================================
* The truth will set you free.

superkkt의 이미지

글쓴이: superkkt / 작성시간: 목, 2006/12/14 - 9:54오전

제가 설계를 하려는 가장 큰 이유는 구현에 들어갈때 제가 보려고 만드는 것입니다. 이미 여러번 설계 없이 무작정 머리속에 있는 내용을 가지고 코딩부터 들어갔다가 규모가 점차 커지면서 일관성(?)이 없어지고 복잡도가 기하급수적으로 증가하는 경우를 경험했기 때문입니다. 프로그램이 작동은 하지만 그 내부는 제작한 저 자신도 믿음이 안가는 그런 프로그램이 만들어졌죠.

그래서 작은 규모의 프로그램도 간단하게 설계를 하고 코딩을 하기 시작했습니다. 그랬더니 훨씬 상태가 좋아지더군요. 일단 전체적으로 한번 쭉 생각을 해봤기 때문에 발생 가능한 문제들은 설계 단계에서 어느정도 처리가 되고요. 그렇다고해서 설계 단계에서 완벽한 프로그램이 나오는것은 아니고 구현하면서 실제 문제에 부딪혀서 설계가 바뀌는 경우도 많기는 합니다. 그래도 설계 없이 하는것 보다는 훨씬 더 상태가 좋은 프로그램이 나오더군요.

그런데 조금씩 프로그램의 규모가 커지고 개발기간이 길어지면서 제가 하던 설계방식(워드에 끄적거리기)에 문제가 보이기 시작했습니다. 설계가 커지니까 이것도 코드와 마찬가지로 일관성이 없어지고 복잡도가 증가한거죠. ^^ 그래서 설계 과정을 짜임새있게 할 수 있는 툴 또는 설계방법론(?)이 없을까해서 뒤져보다가 UML을 보게된거죠.

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

마잇의 이미지

글쓴이: 마잇 / 작성시간: 목, 2006/12/14 - 10:11오전

저도 프로그래밍에 입문하면서 이런 문제로 계속 고민을 하고 있습니다. 하지만 결국 코드가 아닌 '별도의 설계 방법'을 통해서는 오히려 더 안좋은 결과를 가져온다는 생각입니다. 손을 놓은지 육개월, 일년이상 지난 프로그램의 수정, 변경을 위해 어떤 종류의 '설계도'만 보고 명확히 파악할 수 있다면 그려두는 것도 도움이 되겠지만 결국 소스를 보지 않고는 아무것도 아니라는 생각이 들더군요.

코드를 쓸 때 전체 프로그램의 구조와 흐름을 머리에 넣지 않아도 되는 구조를 유지해야 되는데 이건 경험과 끊임없이 뜯어 고치려는 자세를 유지하는게 관건인 것 같습니다.
저는 쓰고 잊어버려도 되는 코드를 쓰자고 계속 생각하면서 써나갑니다.

agile, TDD, refactoring, extreme programming 같은 주제를 다루는 서적, 글들에서 공감이 가는 많은 조언을 얻었습니다.

--
마잇


--
마잇

lovewar의 이미지

글쓴이: lovewar / 작성시간: 목, 2006/12/14 - 10:01오전

설계를 어느 정도까지 할 것인가는 현실의 여건에 달려 있습니다.
// 현실의 여건이란 아마도 개발자의 설계하는 능력, 설계도를 바라볼 수 있는 힘(중요), 그것을 지원해 주는 도구, 등등
// 이 있을 수 있습니다. 능력은 단시간에 나오지는 않는것 같습니다. 그렇기 때문에 계속적인 경험이 필요로 할 것입니다.

이 부분은 알아서 판단을 해야 하며 그 결정이 쓸모없는 문서(형식에 치우치면)를 만드는 것이 될 수도 있고,
아니면 쓸모있는 문서(경험 또는 이해 정도의 표현)가 될 수도 있을 겁니다.
// 현실 여건에 시간의 중요성을 포함하지 않은것은 머리속 설계나 그것을 표현하지 못 한다면 시간의
// 중요성은 의미를 잃게 됩니다. 그외 반대로 경험이 축적된 설계는 시간의 중요성을 한층 느끼게 해 줍니다.

자신을 위해서라도 또는 미래 후배들을 위해서라도 설계도를 그리는 것(도구든 종이에든)은 좋은 습관이라 생각합니다.
// 많은 설계도들이 나온다면 그것은 구현시 복잡도가 어느정도 일지를 가늠할 수 있는 척도(Metrics)가 될 것입니다.
// 설계시에 복잡도을 이끌어 내지 못하다면 프로젝트는 실패 할 확률이 더욱 높아질 것입니다.

다시 한번 현실 여건에 따라 적절한 설계문서들을 만드는 것은 중요하다 생각합니다.
// 그래서 어떤 설계도들이 또는 그런것이 필요한지가 궁금했을 뿐입니다.
// 전, 기능(use case), 구조(class diagram -프래임웍차원), 흐름(sequence diagram-프로세스 또는
// 중요데이타의 이동경로) 만을 그립니다. 가끔가다 상태(statechart diagram)을 그리기 합니다.
// 그린다는 표현은 제가 봤을때 설계를 했다고 표현할 수 정도는 아니기에 그린다는 표현을 사용했습니다.

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.