1 / 22

공학적 측면에서의 프로그래밍 교육

공학적 측면에서의 프로그래밍 교육. July, 2002. 박 수 용 서강 대학교 컴퓨터학과 sypark@ccs.sogang.ac.kr. 목차. 서론 학생들의 프로그래밍 기술 발달 과정 공학 기반의 프로그래밍 교육 Software Development Process Design Pattern 해외의 패턴 교육 가상 시나리오. Program Vs. Software. Program = Software ?. Program = Set of executable computer instructions.

fabiano-knight
Download Presentation

공학적 측면에서의 프로그래밍 교육

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 공학적 측면에서의 프로그래밍 교육 July, 2002 박 수 용 서강 대학교 컴퓨터학과 sypark@ccs.sogang.ac.kr

  2. 목차 • 서론 • 학생들의 프로그래밍 기술 발달 과정 • 공학 기반의 프로그래밍 교육 • Software Development Process • Design Pattern • 해외의 패턴 교육 • 가상 시나리오 Software System Engineering Lab

  3. Program Vs. Software • Program = Software ? • Program = Set of executable computer instructions • Software = Computer program and related documents including analysis, design, project planning etc. • Programming 교육 • Software 개발 교육 Software System Engineering Lab

  4. Engineering 학문의 발전 과정 Science Ad-hoc practice ProfessionalEngineering Production Commercial Craft • 교육된 전문가들 • 분석과 이론 • 과학에 의한 진전 • 전문 클래스에 의한 교육 • 분석을 통하여 새로운 응용이 가능 • 제품의 다양화에 의한 시장 분할 • 대가(Virtuoso)와 재능있는 아마츄어들 • 직관과 맹목적인 압력(Force) • 우연에 의한 진전 • 계획없는 전파 • 가능한 자원의 지나친 사용 • 판매 보다는 사용을 위한 생산 • 숙련된 기술자들 • 절차가 수립되어 있음 • 실용적인 정제 작업 • 기계적인 훈련 • 자원의 공급과 비용에 대한 경제적인 고려 • 판매를 위한 생산 Software System Engineering Lab

  5. 학생들의 프로그래밍 기술 발달 과정 Engineering 교육 Ad-hoc practice Programmer 코드예제 Art 자신만의 기법 숙제용 코드 • 학생 벤처, 프로그래밍 아르바이트, 삼성 멤버십 등으로 용돈 충당(일부 3 ,4학년) • 1000-5000 라인의 코드 • 코드 가독성에 대해 인식 • 소프트웨어 생명주기에 대해 인식 • 자신만의 분야 구축 • 미래에 대한 뚜렷한 비전 • 대부분의 학생(1-2학년) • 100-500 라인의 코드 • 시행 착오에 의한 코드 작성 • 주위의 도움에 의한 완성 • 책의 샘플코드 따라하기 • 맹목적인 압력(Force): 학점 • 우연에 의한 진전 • 코딩 잘하는 학생(2, 3학년) • 500-1000 라인의 코드 • 나름대로의 기법 수립 • 절차가 수립되어 있음 • 60년대의 방식 • 숙제완성에 대한 • 예측력 확보 • 코드 작성에 대한 자신감 • 코드 이상의 것에 대해 무지 Software System Engineering Lab

  6. 공학 기반의 프로그래밍 교육 • Software Development Process and Technology • Software development planning • Software architecture • Analysis & design • Implementation & Testing • Design Pattern Software System Engineering Lab

  7. 시나리오 주어진 상황 반응/대응 인지하고 적용할 수 있는 학생 인지 못한 학생 1. 개발 공정 2. 디자인 패턴 Software System Engineering Lab

  8. 예제 시나리오: 채팅 프로그래밍 숙제 • 인터넷 프로그래밍 과목의 숙제로 자바 애플릿을 이용해서 채팅 프로그래밍을 4명이 프로그래밍해야 합니다. • 기간은 중간고사 이후부터 성적제출일까지 약 2개월입니다. • 실제로 프리챌 같은 커뮤니티 사이트에 판다고 가정하고, 학생들은 잘 팔릴 것 같은 소프트웨어를 구축해야 합니다. Software System Engineering Lab

  9. 개발 공정을 인지 못 한 팀 • 시작: 일단 코딩부터! • 대략적인 UI 구성 후, 한 명에게 UI 전담 • 한 명에게 클라이언트(자바 애플릿) 전담 • 두 명이 서버 담당 • 3주 후: 1차 통합시도 • 통합 불가능 • 서로간의 불화 시작 • 잘 팔릴 것 같은 아이디어는 도출 되었으나, 현재 코드에 그러한 내용을 추가하는 것이 불가능 • 4주 후: 야합 성립 • 서버를 담당했던 두 명이 전체 코드를 담당하고, 나머지 두 명은 간식 조달 및 보고서 작성 • 7주 후: 밤샘 작업 돌입 • 완성 여부 불확실 • 잘 팔릴 것 같은 소프트웨어 보다는, 일단 작동하는 소프트웨어의 작성에 치중. • 8주 후: ? Software System Engineering Lab

  10. 개발 공정을 인지하고 적용할 수 있는 팀 • 시작: 요구사항 수립 • 벤치마킹을 통해 잘 팔릴 것 같은 채팅 소프트웨어의 특성에 대해 회의(1일) • 요구사항 정의(1일) • 1주 후: Risk Analysis • 평범한 애플릿으로는 화려한 UI가 불가능 • 웹 브라우저에서 애플릿 로딩 속도가 매우 느림 • 일반적인 서버에서는 많은 동시 사용자를 수용할 수 없음 • 2주 후: Risk 해결 • 애플릿에서 사용할 수 있는 무료 UI Component를 찾아서 1명이 전담 • IE 4.0 이후부터는 애플릿 로딩 속도 빠름 • ulimit으로 파일 디스크립터 한계를 높인 후, 많은 동시 사용자를 수용할 수 있는 프로토타입 제작 • 3주 후: 작업 분담 • 위험요소가 해결되었고, 3주간의 작업을 통해 팀워크 향상 • 서로간의 스킬라인에 따라 작업을 분배 • 1주 간격으로 계속적인 통합 • 6주 후: 개발 완료 • 피자 파티 Software System Engineering Lab

  11. 두 팀의 차이 개발 공정을 인지 못한 팀 개발 공정을 인지하고 적용할 수 있는 팀 • 팀원의 실수 가능성 존재 • 코드의 작동에 중심 • Waterfall • 성공했다면 그것은 슈퍼프로그래머의 노력에 의한 우연적 성공 • 실패했을 경우 그에 대한 해결책을 하루만에 수행해야 함 • 팀원의 실수 가능성 원천 봉쇄 • 코드의 품질에 중심 • 짧은 반복의 소중함을 인식 • 2주차의 관문을 통과하면 성공 • 혹은 2주차에 이미 실패를 예견하고 다른 방법을 모색. 남은 시간은 6주 대부분의 팀 약 1, 2 개 팀 Software System Engineering Lab

  12. 디자인 패턴을 인지 못 한 팀 public class 대기실 extends Thread { private 대기실리스너스레드[] 대기실리스너 = null; public static final LISTENER_PORT = 2000; public 대기실() { for (int i=0; i<20; i++) { 대기실리스너[i] = new 대기실리스너스레드(LISTENER_PORT + i); } … } } 팀장: 이 클래스의 인스턴스는 하나야!!!! Software System Engineering Lab

  13. 디자인 패턴을 인지하고 적용할 수 있는 팀 public class 대기실 extends Thread { private 대기실 instance; private 대기실리스너스레드[] 대기실리스너 = null; public static final LISTENER_PORT = 2000; static { instance = new 대기실(); } public 대기실 getInstance() { return instance; } protected대기실() { for (int i=0; i<20; i++) { 대기실리스너[i] = new 대기실리스너스레드(LISTENER_PORT + i); } … } } Singleton 패턴 Software System Engineering Lab

  14. 두 팀의 차이 디자인 패턴을 인지 못한 팀 디자인패턴을 인지하고 적용할 수 있는 팀 • 팀원의 실수 가능성 존재 • 코드의 작동에 중심 • 자신의 코드에 대한 자부심 결여 • 코딩을 ‘노가다’ 에 비유 • 팀원의 실수 가능성 원천 봉쇄 • 코드의 품질에 중심 • 자신의 코드에 대해 자랑하고 싶어하고, 아름다운 코드에 대해 인식 • 코딩을 ‘Art’에 비유 대부분의 팀 약 1, 2 개 팀 Software System Engineering Lab

  15. 패턴의 정의 패턴이란 특정 설계 컨텍스트에서 반복해서 발생하는 특정한 문제를 기술하고, 그 해결책으로서 검증된 방법을 제시한다. 그 해결책은 그 구성 컴포넌트들, 그들의 역할과 관계, 그리고 그들간의 상호작용을 기술함으로 구성된다. [POSA Volume I] • 일반적으로 패턴은 다음의 네 부분으로 구성된다. • 패턴 이름 • 문제점 • 해결책 • 결과 • [GoF] Software System Engineering Lab

  16. 소프트웨어 패턴의 종류 • Design patterns • architecture • design • idiom • Analysis patterns • Organization patterns • Process patterns • Domain-specific patterns Software System Engineering Lab

  17. 왜 패턴을 익혀야 하는가? • Becoming Chess Master • Becoming a Software Design Master • 패턴의 묘용 Software System Engineering Lab

  18. Becoming Chess Master • 먼저 체스의 규칙을 익힌다. • 예를 들어 킹, 비숍 등의 움직이는 방법 • 그리고 원칙들을 익힌다. • 예를 들어, 각 기물들의 상대적 가치(킹은 나이트보다 중요하다), 각 기물들의 전략(나이트는 중앙에서 보다 강하다) • 그러나 체스 마스터가 되기 위해서는 다른 마스터들의 게임을 복기해야 한다. • 이러한 다른 마스터들의 게임에는 반드시 이해하고 외우고 반복해서 적용해봐야 하는 패턴들을 담고 있다. • 이러한 패턴은 수백가지가 존재한다. Software System Engineering Lab

  19. Becoming a Software Design Master • 먼저 기본적인 규칙을 익힌다. • 프로그래밍 언어, 알고리즘, 자료 구조 등 • 그리고 원칙들을 익힌다. • 구조적 프로그래밍, 모듈, 객체지향 등 • 그러나 진정한 소프트웨어 설계의 마스터가 되기 위해선 다른 마스터들의 설계를 공부해야 한다. • 이러한 다른 마스터들의 설계에는 반드시 이해하고 외우고 반복해서 적용해봐야 하는 패턴들을 담고 있다. • 이러한 패턴은 수백가지가 존재한다. Software System Engineering Lab

  20. 패턴의 효용 • 소프트웨어 패턴은 다음과 같은 효용이 있다: • 실세계의 문제를 해결한다. • 문제영역의 전문지식을 전달해준다. • 설계의 결정과 이론적 근거를 문서화해준다. • 마스터들의 지혜와 경험을 재사용할 수 있다. • 전문가의 통찰력을 초심자에게 전달한다. • 문제를 해결하는 토의에서 공통의 어휘로서 사용할 수 있다. • 단순한 해결책 이상의 것을 제공한다: • 컨텍스트(언제 그리고 어디에 패턴을 적용할 것인가) • forces (상충되는 대안들, 부적합한 상황, 목표+제약사항) • 스펙트럼 (그 해결책이 force에 따라 그리는 균형의 함수) Software System Engineering Lab

  21. 패턴을 교육하는 대학 • http://www-2.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1998/ CMU • http://theory.lcs.mit.edu/~dnj/6898/index.html MIT • http://www.cs.lth.se/Education/Courses/96.Dokt.Patterns/LectSchedule.html Lunds Universitet • http://www.eli.sdsu.edu/courses/spring98/cs635/notes/ San Diego State University • http://sern.ucalgary.ca/courses/SENG/609.04/W99/ University of Calgary • 그 외 다수 존재 Software System Engineering Lab

  22. 결론 • 프로그래밍 위주의 교육의 위험 • 프로그래밍 교육 시 어떻게 하여야 하는가의 제시가 필요 • 소프트웨어 개발 절차 • 분석 및 설계 원칙 • 각종 유용한 패턴들 • 이러한 것들을 실제 응용하고 실습 할 수 있는 교육이 필요함 Software System Engineering Lab

More Related