c언어로 프로그램 만들때 설계를 어떻게 하시나요?
글쓴이: ins878 / 작성시간: 목, 2005/05/12 - 3:03오후
평소, 혼자서 조금씩 프로그램을 만들고 있습니다. 제가 만드는 프로그램이 뭐 거대한 것은 아니여서, 플로우차트 정도로 간단하게 설계하고 프로그램을 만들었습니다. 하지만, 점점 소스코드가 늘어나며서~, 꼬인다고 해야하나~... 예상했던 기능(로직)이 나오지 않아서 수정하고 수정하면 나중에는 디죽박죽 됩니다.
원하는 출력물 중심으로 짜다보니 이것이 저것~ 저것이~이것~등 마구 서로가 호출하게 되고, 각 모듈마다 일정한 독립성이 없습니다.
그래서 요즘, 프로그램을 만들면서 설계가 참 중요하다는 생각을 하게 되었습니다.
그런데~ 보통 현재 나오는 책들을 보면 객체지향 설계가 대부분입니다. 모델링 언어도~ 다 객체지향적인 것 같고요...
c언어로 프로그램을 만들어 설계를 어떻게 하는지~ 또는 실무에서는 어떤 방법으로 하는지 알려주세요~
이곳 저곳을 돌아다녀서 확인해 보니깐, 모델링 언어로 UML을 많이 사용한다고 하던데~ 재 생각에는 이것은 구조적 프로그래밍하고는 잘 안맞는 것 같습니다. 물론 UML로 구조적 프로그램을 모델링 할 수 있다고 하는데~ 혹시 책이나~ 자료가 없는지~~
요점은, C언어로 프로그램을 설계할때 어떤 방법으로 하며, 모델링 언어는 어떤 것을 사용하는지... 자료나 책등 추천도 부탁드립니다.
Forums:
임베디드 쪽이라 씨 언어밖에 쓰지 않아서 객체에 대한 개념이 없어서 그런
임베디드 쪽이라 씨 언어밖에 쓰지 않아서 객체에 대한 개념이 없어서 그런지 저는 함수 호출 위주로 설계하게 되는군요.
프로그램 만들기 전에 전체 플로우를 그리고 중심이 되는 함수들의 인자와 리턴 값등에 대해서 미리 만들어 둡니다. 이렇게 준비가 되면 main() 함수를 만들고 그 안에서 부르는 함수들에 대한 자세한 설계는 각각 다시 합니다.
함수들 사이에 레벨을 정하는 것이 중요한데 main() 을 레벨 0이라고 하면 main()에서 부르는 함수들은 레벨 1이 됩니다. 레벨 1에서 부르는 함수들은 레벨 2가 되구요. 함수 호출 시 레벨 등을 판단해 높은 레벨에서 낮은 레벨의 함수는 가능한 호출하지 않습니다. 불러야 하는 경우에는 따로 API를 만드는 식으로 작업합니다.
저는 전산 전공은 아니라 정식 설계에 대해서는 아는바가 없고 그냥 일하면서 배운 스타일이네요.. :oops:
#kill -9 world
저도 임베디드 쪽이라...저 같은 경우는 일단 할일이 정해 지면
저도 임베디드 쪽이라...
저 같은 경우는 일단 할일이 정해 지면 기능별로 블록을 나누고, 그 블럭에 들어갈 파일들을 설정합니다. 블럭당 1~2개정도 파일(.h)로 나눕니다.
그리고 각 파일별 헤더 파일을 만들고, 헤더 파일에 함수 프로토 타이핑 하고, 인자, 리턴값, 해야 될 기능등을 기술합니다. 어느 함수가 무슨 함수를 호줄 할지도 여기에 기록합니다.
그리고 각 파일별 implemetation 파일(*.c) 만들고 각 함수를 작성합니다.
순서고 같은 건 가끔 그리는데, 모델링 언어는 사용해 본적 없고, 주로 다이어그램만 많이 그림니다.
음... 이제 부터 생각해 봐야겠다.
어떻게 해야 하느냐 하면 ...- 자알 - 해야 합니다.
어떻게 해야 하느냐 하면 ...
- 자알 - 해야 합니다.
Re: c언어로 프로그램 만들때 설계를 어떻게 하시나요?
소프트웨어 설계방법은 크게 SSAD OOAD 가 있는 것으로 알고 있습니다. SSAD 는 Structured System Analysis and Design이고, OOAD는 Object Oriented Analysis and Design 이죠.
c언어를 사용하고 처음 설계방법을 접근하기에는 SSAD 방법론이 좀 더 익히기 쉽습니다. 간략하게 설명하자면, 만들고자 하는 큰 System을 정하고, 그 시스템을 작게 분해 하면서 작은 블락들로 나누어 가면서 설계하는 것이지요, 각 블락간의 data 흐름을 같이 설계하고요. 잘게 쪼개다보면, 결국 하나의 펑션들까지 세분화가 된답니다. 더 자세한 내용들은 SSAD를 다룬 사이트나 책을 참고해보세요~
UML로 구조적 프로그래밍 설계를 하고 있습니다.정말 안맞습니다.
UML로 구조적 프로그래밍 설계를 하고 있습니다.
정말 안맞습니다. 그래서 표식을 전부다 다른 의미로 쓰고 있습니다.
뭐 예를 들면 --> 는 핵심 호출부, 연계관계..
이렇게 다시 정의해서 그냥 저 편한대로 쓰고 잇습니다.
왠만하건 워크그룹단위로 나눠버리고요.
정말 UML은 정말이지 구조적과는 전혀 맞지 않는것 같습니다.
구조적 접근을 염두해두지 않고 만들었으니 당연한거라 생각합니다.
혹시 책이나 문서르 본다면.. 꼭 알려주세요.
Chaos to Cosmos,
Chaos to Chaos,
Cosmos to Cosmos,
Cosmos to Chaos.
SSAD에 관한 글이 wiki에 있군요.여러가지가 있는데 DFD, F
SSAD에 관한 글이 wiki에 있군요.
여러가지가 있는데 DFD, FlowChart정도는 알아두면 좋을 것 같습니다.
여러 방법론들을 하나씩 보시고, 공통된 범위안에서 자신만의 스타일을 만드는 것도 좋을 듯 싶습니다. (물론 남들이 봐도 알아볼수는 있어야 겠져 ^^)
wiki 백과사전-
http://www.xasa.com/wiki/en/wikipedia/s/st/structured_systems_analysis_and_design_methodology.html
이건 대학 강의록입니다.
http://www.infosec.jmu.edu/courses/CS555infosec99/StudyUnits/Unit7/SASD/
기능을 분석하고 기능에 따른 프로세스를 설계하고뼈대(잡다한기능 모
기능을 분석하고
기능에 따른 프로세스를 설계하고
뼈대(잡다한기능 모두제외)를 구축한 후.....
살붙이기
간혹 나오는 뼈대오류.....
뼈대 약간 고치기
살붙이기......
살붙이기......
이거 뼈대가 잘되어 있어야 되요...
뼈대가 수정 안 될거라는 즐거운 상상도 버리시고....
그나저나 백수 언제 탈출하냐... ㅡㅡ; 배고파라.
좀더 생각해보니, 너무 깊게 까지 들어갈 필요는 없다고 생각되네요.지
좀더 생각해보니, 너무 깊게 까지 들어갈 필요는 없다고 생각되네요.
지금 하고 있는 프로젝트가 큰것이 아니라면 필요한 부분만 잘 정의해 놓으면 될 것 같습니다.
정말 큰 프로젝트 설계는 회사에 입사해서 경험을 쌓다 보면 알게 되겠져 ^^;
전 백수 학생이라 ㅎㅎ.
동감합니다. 단지 너무 한꺼번에 수정하려고 하지말고 필요할때 적당히 해주는 것이 중요할 것 같습니다.
설계가 중요하죠.
학생때부터 언어보다는 설계를 제대로 배우는것이 중요하다고 생각합니다.
프로그램 언어야 구현하다보면 조금씩 능숙해지고, 기능에 맞는 구현방법을 익히게 됩니다.
하지만, 설계에 대해서 정확히 파악하지 못하면 결국 전체적인 흐름과 완성도는 떨어지게 되어버립니다.
이러한 설계에 대한 것은 소프트웨어 공학등을 참고 하시면 좋습니다.
저는 지금 설계자로 일하고 있습니다. 물론 이전에는 프로그램을 작성하였었구요.
설계에는 기본적으로 다음의 문서를 필요로 하고 있습니다.
1.기능 사양서
1.1 기능#1 사양서
1.2.1 부분#1 시퀀스 사양서
1.2.2 부분#1 인터페이스 사양서
*사양서라는 것은 스펙을 말합니다.
이런것들이 만들어지고 나서 프로그램을 작성해 보시는 것이 좋은 경험이 될 것입니다.
단지 잘 설계되어있는 설계서를 보고 프로그램으로 구현하는 것보다 좋은 것은 없죠.
간단한 프로그램이라도 간단하게나마 설계서를 만들고 나면 잘 못되어있는 부분과 위험을 안고 있는 부분들이 명백하게 보여지게 됩니다.
그럼 선배님들의 조언을 기다립니다.
저도 설계를 할 수
저도 설계를 할 수 있는 회사에 다녔으면 좋겠네요..
설계해서 만들면 뭐해요.. 좀있으면 다 바뀌는데..
그냥 설계 안하고 얼른 만들고 쉬지요 뭐..바꾸라고 하면 그때 일하고요.
----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
머릿속에서 나오는대로 짜버리고
문제되는 부분은 주석처리해가면서 조금씩 수정합니다.
(고로 내 사전에 설계란 없다...?)
============================================
니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ
---------------------------------------------------------------
폐인이 되자 (/ㅂ/)
그냥 대~충 대충 합니다요
그냥 대~충 대충 합니다요
씨가 뭐 별거 있나요
설계요..? 그런거 하십니까?
학교 대닐땐 UML, 객체지향설계 니 뭐니 참 많이 배웠는데..
실제로 프로젝트 해보면..
그냥 생각나는대로..
화이트보드에 모듈그려가며 계속 고치고, 수정하고 단순화하고
뭐 그렇게 합니다.
설계 그거 어차피 하다보면 다 바꿥니다.
끝없는 리펙토링이 있을뿐..
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
집을짓거나..자동차
집을짓거나..
자동차를 만들거나..
비슷하겠죠...
집짓는데 무작정 시멘트주무르고 벽돌부터 쌓으면 될까요?
일단 필요한것부터 생각해보셔야죠.. 각종재료나 공구 장비들...
기본적인 도구들부터 구해야겠죠.. 기본적으로 제공되는 함수들이 아니라면..
미리 필요한것이 뭔가 생각해보고 이런 베이스library부터 만드셔야됩니다.
이런것이 만들어지면그다음은 대부분구조적으로 잘풀릴거라생각되네요..
꼭 만들지 않더라도 선언정도라도 해두시면 됩니다.
전체적으로 만들고 작게 나누시려면요.. 대부분 나누기힘들고 이상하게 되요..
그런경우 아예다시짜야되는경우가 있더라구요..
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
설계라고 하니깐 거창해 보이네요
거창해 보이는 만큼 뭔지 알기 어렵죠.
설계를 아주 쉬운 말로 바꾸면 "이름짓기"라고 할 수 있습니다.
즉, 프로그래밍이라는 한계내에서 좋은 설계란 적은 숫자의 이름만으로 많은 코드를 표현한 것이라 볼 수 있습니다.
이름을 붙인다는 것은 복잡한 걸 알기 쉽게 바꾼다는 의미이고, 알기 쉽다는 것은 쉽게 만들 수 있다는 말입니다.
알 수도 없는 말이 적혀있는 설계 책을 보시지 말고, 지금 짜고 있는 작은 코드에서 어떻게 하면 이름을 잘 붙일 수 있을지를 생각해보세요.
비슷한 코드/의미/개념마다 이름을 붙여서(상수, 변수, 함수, 클래스, 모듈, 패키지, 컴포넌트로 만들어서) 결과적으로 프로그램에서 중복되는 코드를 발견할 수 없다면, 방향이 틀리더라도 최소한 (다른 프로그램에서라도 써먹을 수 있을테니) 나쁜 설계는 아니고, 방향이 맞다면 훌륭한 설계가 된 프로그램일 겁니다.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
개체지향 설계를 해도 됩니다
개체지향 설계를 하고 C로 구현해도 그리 큰 문제는 없습니다.
개체를 프로그램 언어상의 class등의 문법으로만 구현하라는 법은 없습니다.
그렇다고 꼭 구조체로 만든다든지 그런 식으로 획일적으로 생각할 필요도 없고요.
역시 상속이 좀 문제긴 합니다만 일반 업무용 프로그램 등에는 설계시 상속이 사용되는 경우가 드뭅니다. 그 외에는 거의 문제될 것이 없습니다.
중요한건 설계 과정에서 데이터와 수행 흐름의 타당성과 무결성을 검증했는지,
또 그렇게 검증된 방식으로 동작하게 그대로 만들었는지 아니겠습니까?