교과목명  창의공학적설계 (CED) (Creative Engineering Design) IT 대학 컴퓨터학부 Prof., NamYong Lee, Ph.D T: 010-5362-5656, e-Mail: nylee@ssu...
Creative Thinking
Creative Thinking Alfred Bernhard Novel
<ul><li>알프레드 베르나르드 노벨 (Alfred Bernhard Novel)  </li></ul><ul><li>  </li></ul><ul><li>1833. 10. 21  스웨덴 스톡홀름 ~1896. 12. 10 ...
Creative Thinking Albert Einstein
<ul><li>알베르트 아인쉬타인 ( Albert Einstein )  </li></ul><ul><li>  </li></ul><ul><li>20 세기초의 창조성이 뛰어난 대표적 지식인이었던 알베르트 아인슈타인은  20 ...
Creative Thinking A n, ByoungKwon
<ul><li>안병권 ( A n, ByoungKwon )  </li></ul><ul><li>  </li></ul><ul><li>‘ 트랜스포머’가 현실로 ,  로봇을 자유자재로 변형하고 ,  세포크기까지 줄이는 길 열려 ...
<ul><li>안병권 ( A n, ByoungKwon )  </li></ul><ul><li>안 동문이 개발한 기술의 응용분야는 무궁무진하다 .  안 동문은 “영화 ‘트랜스포머’의 범블비가 길에서는 차로 변하고 ,  하늘...
창의성 ,  공학설계의 개념
창의성의 개념 <ul><li>창의성의 개념 </li></ul><ul><ul><li>창의성이란 현상을 개선하여 부가가치를 높이는 아이디어를 창출하고 그 아이디어를 실행에 옮겨 혁신을 이루는 능력 </li></ul></ul...
창의력을 증진하기 위한 교육의 필요성 <ul><li>20 세기 공학의 접근방법 </li></ul><ul><ul><li>소품 종 대량 생산 </li></ul></ul><ul><ul><li>제조업 중심 ,  생산자 중심 <...
창의력에 도움이 되는 가치관 ,  태도 ,  행동 <ul><li>그릇된 자존심을 갖지 않는다 . </li></ul><ul><li>성공에 대한 능력을 믿는다 . </li></ul><ul><li>건설적인 불만을 갖는다 . ...
창의력을 신장하기 위한 전략 <ul><li>창의력을 신장시키기 위한 전략 </li></ul><ul><ul><li>고정관념의 틀을 벗으려고 하는가 ? </li></ul></ul><ul><ul><li>남의 이야기에 귀를 기...
창의성과 지능의 관계 <ul><li>지능 </li></ul><ul><ul><li>학습능력과 적응능력 등 추상적 능력 </li></ul></ul><ul><ul><li>배우고 이해하는 능력 ,  복잡한 상황에 대처하는 능력...
공학의 개념 <ul><li>공학은 문제해결을 위한 응용학문이다 . </li></ul><ul><ul><li>The application of scientific principles to the optimal  conver...
공학설계의 개념 <ul><li>공학설계의 정의 </li></ul><ul><ul><li>필요한 것을 만들기 위해 시스템 ,  요소 ,  프로세스를 고안하는 과정  -  미국 공학기술인증원  ( ABET: Accrediat...
공학설계프로세스의 개념 <ul><li>공학설계프로세스의 정의 </li></ul><ul><ul><li>공학설계의 단계를 설명하고 ,  체계적으로 공학설계를 수행할 수 있도록 함 </li></ul></ul><ul><ul><...
창의적공학설계의 개념 <ul><li>공학설계의 능력을 배양하기 위한 교과목 </li></ul><ul><ul><li>유능한 공학자 ( 엔지니어 ) 가 되기 위한 자질을 교육 </li></ul></ul><ul><li>공학자...
창의적공학설계의 교육목표 <ul><li>ABEEK  에서는 공학전공 졸업자들에게 다음과 같은 능력과 자질을 갖추도록 요구하고 있음  (  창의적공학설계의 목표학습성과  ) </li></ul><ul><ul><li>수학 ,...
소프트웨어공학의 개념 <ul><li>일반적인 정의 :  소프트웨어시스템 ( 제품 ) 의 개발에 대한 공학적 접근방법을 연구하는 학문 </li></ul><ul><li>IEEE 의 정의 :  소프트웨어의 개발과 운용 및 유...
소프트웨어공학과 공학설계 <ul><li>소프트웨어의 공학설계 프로세스 </li></ul><ul><ul><li>문제식별과 정의 ( Problem Identification and Definition) </li></ul><...
창의적 문제해결과 기법
창의적 문제해결 <ul><li>창의적 문제해결의 정의 </li></ul><ul><ul><li>“ Creative problem solving is -  looking at the same thing as everyone...
창의적 문제해결 <ul><li>창의적 문제해결의 예 </li></ul><ul><ul><li>4 개의 직선으로 다음  9 개의 점을 이어 보시오 . </li></ul></ul>
창의적 문제해결 <ul><li>창의적 문제해결의 예 </li></ul><ul><ul><li>4 개의 직선으로 다음  9 개의 점을 이어 보시오 . </li></ul></ul>
창의적 문제해결 <ul><li>우리는 왜 좀더 일상생활에서 창의적인 생각들을 하지 않는가 ? </li></ul><ul><li>우리가 창의적 사고를 하는 데 있어 방해요소들은 무엇인가 ? </li></ul>
창의적 문제해결 <ul><li>창의적 문제해결에 있어서의 장애요소 </li></ul><ul><ul><li>시간 </li></ul></ul><ul><ul><ul><li>창의적인 사고는 많은 시간을 필요로 함 </li></...
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul><ul><ul><li>일상적인 사고를 벗어나지 못하는 마음가짐 </li></ul></ul><ul><ul><ul><li>“ 난 ...
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>1. The  right  answer. Only  one ?    정답은 한가지가 아니다
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>2. That’s not  logical.    비논리적인 것도 논리적이 될 수 있다
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>3.  Follow  the rules.    룰을 벗어나야 새로운 생각을 가질 수 있다 . <ul><li>룰 (Rule) ...
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>4. Be  practical.    반드시 실용적인 것만이 창의적인 것은 아니다 .
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>5.  Play  is frivolous.    사소한 것도 창의적인 것이 될 수 있다 . “ When do you get ...
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>6. That’s not my  area.    창의적 사고는 자신의 영역을 벗어날 때 이루어진다 .
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>7.  Avoid  ambiguity.    사람들은 모호한 것을 볼 때 창의적인 사고를 하게 된다 . AMBIGUITY
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>8. Don’t be  foolish.    바보 같은 사고가 가장 천재적인 사고가 될 수 있다 .
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>9.  To err  is wrong.    실패는 나쁜 것이 아니다 .
창의적 문제해결 <ul><li>멘탈 블럭  ( Mental Blocks ) </li></ul>10. I’m not  creative.    자신이 창의적이지 못하다는 생각을 버려야 한다 .
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>문제의 정의 </li></ul><ul><ul><li>근본적인 문제를 기술하기 보다 ,  문제해결을 위한 시작점을 설...
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>자료의 수집 </li></ul><ul><ul><li>문제의 원인은 무었인가 ? </li></ul></ul><ul><...
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>문제의 재정의 </li></ul><ul><ul><li>수집된 자료를 통해서 정확한 문제를 정의하는 단계 </li><...
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 모색 </li></ul><ul><ul><li>아이디어를 제시하고 가능한 많은 해결방법들을 모색하는 단계 </...
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 평가 </li></ul><ul><ul><li>여러 해결방법들을 평가하고 최선의 해결방법을 찾아내는 단계 </...
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 적용 </li></ul><ul><ul><li>최종적으로 채택된 해결방법을 적용하는 단계 </li></ul><...
창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 평가 </li></ul><ul><ul><li>해결방법을 통해 원하는 결과가 수집되었는지를 평가하는 단계 </...
창의적 문제해결 기법
창의적 문제해결 기법 <ul><li>창의적 문제해결 기법은 크게  2 가지로 구분됨 </li></ul><ul><ul><li>확산적 사고  ( 생성적 사고 )  를 통한 문제해결 </li></ul></ul><ul><ul>...
창의적 문제해결 기법 <ul><li>브레인스토밍  ( Brainstorming ) </li></ul><ul><ul><li>특정한 주제에 대하여 머리 (brain) 에서 폭풍 (storming) 이 몰아치듯 생각나는 아디...
창의적 문제해결 기법 <ul><li>브레인스토밍의 진행방식 </li></ul><ul><ul><li>5~12 명 정도로 집단을 구성하고 ,  나이 ,  성별 ,  관심 ,  전공 등 되도록 다양한 측면의 사람들이 에서 동...
창의적 문제해결 기법 <ul><li>스캠퍼 ( SCAMPER ) </li></ul><ul><ul><li>특정 대상이나 문제에  7 가지의 대표적인 질문을 활용하여 사고를 자극함으로써 새로운 아이디어를 얻는 기법 </li...
창의적 문제해결 기법 <ul><li>스캠퍼 ( SCAMPER ) </li></ul><ul><ul><li>대체하기  (  S ubstitute )  </li></ul></ul><ul><ul><ul><li>제품의 본질적인 ...
창의적 문제해결 기법 <ul><li>스캠퍼 ( SCAMPER ) </li></ul><ul><ul><li>수정 - 확대 - 축소하기  (  M odify-Magnify-Minify ) </li></ul></ul><ul><...
창의적 문제해결 기법 <ul><li>스캠퍼 기법을 이용한 다기능성 자전거 아이디어  </li></ul><ul><ul><li>S :  기존의 공기 주입식 타이어 대신 바람을 넣지 않는 타이어로 대체 </li></ul></...
창의적 문제해결 기법 <ul><li>마인드맵  ( Mind Map ) </li></ul><ul><ul><li>수렴적 사고 기법 </li></ul></ul><ul><ul><li>문제에 대하여 큰 빈 종이 위에 이미지와 핵...
창의적 문제해결 기법 <ul><li>마인드 맵의 예 </li></ul>
창의적 문제해결 기법 <ul><li>PMI  기법 </li></ul><ul><ul><li>수렴적 사고 기법 </li></ul></ul><ul><ul><li>제안된 아이디어의 장점 (P),  단점 (M),  흥미로운 점 ...
창의적 문제해결 기법 <ul><li>평가행렬법 </li></ul><ul><ul><li>수렴적 사고 기법 </li></ul></ul><ul><ul><li>체계적으로 제안된 아이디어를 평가하는 방법으로서 평가하려는 아이디어...
창의적 공학설계 표기법 ( 모델링언어 )  Unified Modeling Language (UML)
목  차 <ul><li>[1] UML  개념 </li></ul><ul><li>[2]  기본 구조 모델링 </li></ul><ul><li>[3]  고급 구조 모델링 </li></ul><ul><li>[4]  기본 행동 모델...
[1] UML  개념  <ul><li>1 장 .  왜 모델을 만드는가  ? </li></ul><ul><li>2 장 . UML  소개 </li></ul><ul><li>3 장 . UML 의 기초 </li></ul>
1 장 .  왜 모델을 만드는가  ? <ul><li>모델링의 중요성 </li></ul><ul><li>모델링의 원리 </li></ul><ul><li>객체지향 모델링 </li></ul>
모델링의 중요성 <ul><li>모델링  (Modeling) </li></ul><ul><ul><li>모델을 만드는 일 ( 추상화 ) 로써 품질이 좋은 소프트웨어를 개발 및 배치할 수  있게 하는 모든 활동의 중심 </li...
모델링의 원리 <ul><li>모델링의 원리 </li></ul><ul><ul><li>생성할 모델의 신중한 선택  :  선택 모델에 따라 문제를 공략하는 방법과 해결책을 실현하는 방법에 많은 영향이 있음 </li></ul>...
객체 지향 모델링 <ul><li>소프트웨어의 모델링 관점 </li></ul><ul><ul><li>알고리즘 관점  : S/W 의 주요 구성 요소인  Procedure  와  Function 을 제어 관점에서 분할하여 시스...
2 장 . UML  소개 <ul><li>UML  개요 </li></ul><ul><li>UML  개념 모델 </li></ul><ul><li>UML  아키텍쳐 </li></ul><ul><li>UML  개발 생명주기 </li...
UML  개요 <ul><li>UML 은 언어 (Language) </li></ul><ul><ul><li>어휘와 규칙을 두어 시스템을 개념적이고 물리적으로 표현하여 의사 소통을 돕는 것을 목적으로 함 </li></ul><...
UML 가시화 언어 개념 모델 작성 오류 없이 전달 의사 소통의 용이 Graphic  언어 구축 언어 다양한  Prog.  언어와 연결 왕복 공학 가능 ( 순 공학 / 역공 학 ) 실행 시스템 예측 가능 명세화 언어 정...
UML  개념 모델 <ul><li>UML  구성 요소 </li></ul>
<ul><li>사물  (Things) :  추상적 개념으로 모형 구성의 기본 요소 </li></ul><ul><ul><li>구조 사물  (Structural Thing) : UML  모형의 명사형으로써 모형의 정적인 부분...
<ul><ul><ul><li>협력  (Collaboration) </li></ul></ul></ul><ul><ul><ul><li>교류 (Interaction) 를 정의하며 서로 다른 요소와 역할들의 집합을 표현 </li...
<ul><ul><ul><li>컴포넌트  (Component) </li></ul></ul></ul><ul><ul><ul><li>시스템의 물리적이고 대체 가능한 부분으로  Interface 를 준수하고 구현 </li></u...
<ul><ul><li>행동 사물  (Behavioral Thing) : UML  모형의 동사형으로써 모형의 동적인 부분이며 시간과 공간에 따른 행동 요소들을 표현 </li></ul></ul><ul><ul><ul><li>...
<ul><ul><li>그룹 사물  (Grouping Thing) : UML  모형을 조직하는 부분이며 모델을 분해하여 재 구성화 할 수 있는 단위 상자 </li></ul></ul><ul><ul><ul><li>패키지  (...
<ul><ul><li>주해 사물  (Annotation Thing) : UML  모형을 설명하는 부분이며  Comment 로써 모형 요소를 설명하고 ,  명확히 하는 표현 도구 </li></ul></ul><ul><ul>...
<ul><li>관계  (Relationships) :  구성 요소 간의 의미 있는 연결 </li></ul><ul><ul><li>의존 관계  (Dependency Relationship) </li></ul></ul><ul...
<ul><ul><li>일반화 관계  (Generalization Relationship) </li></ul></ul><ul><ul><ul><li>특수화 (Specialization)/ 일반화 (Generalization...
<ul><li>도해  (Diagramming) :  구성 요소 들의  Graphic  표현 </li></ul><ul><ul><li>클래스도  (Class Diagram)  </li></ul></ul><ul><ul><ul...
<ul><ul><li>상태도  (State Diagram) </li></ul></ul><ul><ul><ul><li>상태 (State),  전이 (Transition),  사건 (Event),  활동 (Activity) ...
<ul><li>UML  규칙 </li></ul><ul><ul><li>UML  규칙은 자체 일관성이 있으며 관련  Model 들과 조화를 이룸 </li></ul></ul><ul><ul><li>잘못된 모형 </li></ul...
<ul><li>UML  공통  Mechanism </li></ul><ul><ul><li>명세서  (Specification) </li></ul></ul><ul><ul><ul><li>UML 의  Graphic  표현에 구...
<ul><ul><li>공통 분할  (Common Division) </li></ul></ul><ul><ul><ul><li>객체 지향 모델링은 다시 몇 가지로 나누어 표현 가능 </li></ul></ul></ul><ul>...
<ul><ul><li>확장 메커니즘  (Extensibility Mechanism) </li></ul></ul><ul><ul><ul><li>UML 의 목적인 분석 / 설계 정보를 보다 정확하게 전달하기 위한  표준 언어...
UML  아키텍쳐 <ul><li>아키텍쳐 결정 사항 </li></ul><ul><ul><li>S/W System 의 구성 </li></ul></ul><ul><ul><li>System  구성 요소들과 요소들 간의  Inte...
<ul><li>S/W  중심 시스템의  Architecture Modeling  </li></ul>설계 뷰 (Design View) 구현 뷰 (Implementation View) 프로세스 뷰 (Process View)...
아키텍쳐 종류 내 용 정적 도해 동적 도해 쓰임새 뷰 (Use Case View) 시스템 행동을 설명 최종사용자 ,  분석가 ,  설계자 ,  테스트 담당자에게 제공 되는 뷰 시스템 아키텍쳐를 구체화하는 요인들을 명세화...
UML  개발 생명주기 <ul><li>개발  Process  고려 사항 </li></ul><ul><ul><li>UML 은 개발  Process 에 독립적 임 </li></ul></ul>프로세스 설 명 쓰임세 중심 Sys...
<ul><li>S/W  개발 생명 주기 단계 </li></ul><ul><ul><li>각 단계는 반복적으로 수행되며 반복은 별개 활동으로써 대내외적으로 배포판을 만드는 기준 계획과 평가 기준을 갖음 </li></ul></...
Process Workflow Business Modeling 요구 사항 분석  /  설계 구현 Test 배치 지원  Workflow 형상 및 변경관리 Project  관리 환경 도입 정련 구축 전이 예비 반복 반복 #...
3 장 . UML  기초 <ul><li>핵심 부분 추상화 </li></ul><ul><li>메카니즘 </li></ul><ul><li>컴포넌트 </li></ul>
핵심 부분 추상화 <ul><li>Web Browser Java Applet “Hello World ! “ 의 예제 </li></ul><ul><ul><li>import  java.awt . Graphics  ; </li>...
<ul><ul><li>HelloWorld 의 핵심 부분 추상화 </li></ul></ul><ul><ul><li>HelloWorld  주위의 인접  Class </li></ul></ul>HelloWorld paint ( ...
<ul><ul><li>HelloWorld  상속 (Inheritance)  계층도 </li></ul></ul>HelloWorld Applet Panel Container Component Object ImageObser...
<ul><ul><li>HelloWorld 의  Package 도 </li></ul></ul>Java HelloWorld applet awt lang
메카니즘 <ul><li>메커니즘 표현 </li></ul><ul><ul><li>Class 의 상속 관계의 표현이 아닌  Operation 의 실행을 표현 </li></ul></ul><ul><ul><li>각  Class 에...
컴포넌트 <ul><li>컴포넌트 표현 </li></ul><ul><ul><li>실행 가능한  Component 를 연결하여 각 메커니즘에 의해 기동 되는 것을 도식 </li></ul></ul><ul><ul><li>개발 환...
[2]  기본 구조 모델링  <ul><li>4 장 .  클래스 </li></ul><ul><li>5 장 .  관계 </li></ul><ul><li>6 장 .  공통 메카니즘 </li></ul><ul><li>7 장 .  도...
4 장 .  클래스  (Class) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>시스템 어휘 모델링 </...
시작하기 <ul><li>클래스 란  ? </li></ul><ul><ul><li>어휘의 일부가 되는 사물들을 추상화 하는 것 </li></ul></ul><ul><ul><li>클래스는 가장 중요한 구성 요소이며 동일한 속성...
용어와 개념 <ul><li>Class  명 </li></ul><ul><ul><li>모든  Class 는 다른  Class  들과 구별되는 유일한 명칭을 갖음 </li></ul></ul><ul><ul><ul><li>단순명...
<ul><li>속성  (Attribute) </li></ul><ul><ul><li>Class 의  Property 에 이를 대표하는 짧은 명사나 명사구로 이름을 붙인 것 </li></ul></ul><ul><ul><ul>...
<ul><li>오퍼레이션  (Operation) </li></ul><ul><ul><li>객체 행동에 영향을 주기 위해 특정  Class 의 객체로부터 요청할 수 있는  Service 를 표현한 것  ( 객체에서 할 수 ...
<ul><li>책임  (Responsibility) </li></ul><ul><ul><li>Class 가 행해야 하는 의무 또는 계약 </li></ul></ul><ul><ul><li>속성과 오퍼레이션 특성들로  Clas...
보편적 모델링 기법 <ul><li>시스템 어휘 모델링 </li></ul><ul><ul><li>사용자나 개발자가 문제나 해법을 설명하기 위해 사용하는 사물을 파악 (CRC Card, Use Case  중심 분석 ) </l...
<ul><li>시스템 책임 분산 모델링 </li></ul><ul><ul><li>어떤 행동을 수행하기위해 긴밀하게 연관 있는  Class  집합을 파악 </li></ul></ul><ul><ul><li>Class  각각의 ...
<ul><li>비 소프트웨어 사물 모델링 </li></ul><ul><ul><li>추상화 대상 사물을  Class 로  Modeling </li></ul></ul><ul><ul><li>이미 정의된 구성 요소들과 구분을 위...
<ul><li>원시 타입 모델링 </li></ul><ul><ul><li>추상화 대상 사물을  Type 이나 열거  Type 으로  Modeling 하고  Stereotype 과 함께  Class 로 표현 </li></u...
힌트와 조언 <ul><li>좋은 구조의  Class </li></ul><ul><ul><li>문제 영역이나 해법 영역 어휘에서 추출된  Class 에 대한 명확한 추상화 제공 </li></ul></ul><ul><ul><l...
5 장 .  관계  (Relationship) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>단순 의존 모...
시작하기 <ul><li>관계 란  ? </li></ul><ul><ul><li>UML 에서 사물 (Thing) 들이 상호 논리적 / 물리적으로 연결되는 것 </li></ul></ul><ul><ul><li>관계 종류  : ...
용어와 개념 <ul><li>의존  (Dependency) </li></ul><ul><ul><li>사용 관계로써 한 사물의 명세서가 바뀌면 이를 사용하는 다른 사물에게 영향을 미침 </li></ul></ul><ul><ul...
<ul><li>일반화  (Generalization) </li></ul><ul><ul><li>“  is-a kind-of  ”  관계 </li></ul></ul><ul><ul><li>일반화된 사물 (Super type,...
<ul><li>연관  (Association) </li></ul><ul><ul><li>“  has-a   ”  관계 </li></ul></ul><ul><ul><li>구조적인 관계로써 특정 사물 객체가 다른 사물 객체와 ...
<ul><ul><li>다중성 (Multiplicity)  표현 </li></ul></ul><ul><ul><li>집합 연관 (Aggregation)  표현  : “  part-of  ”  관계  </li></ul></ul...
보편적 모델링 기법 <ul><li>단순 의존 모델링 </li></ul><ul><ul><li>특정  Class 가 다른  Class 를  Operation 에서  Parameter 로만 사용하는 관계 </li></ul><...
<ul><li>단일 상속 모델링 </li></ul><ul><ul><li>구조적 ,  행동적 특성을 파악하여 일반화  Class 와 특수화  Class 로 구분하여 작성 </li></ul></ul><ul><ul><li>C...
<ul><li>구조적 관계 모델링 </li></ul><ul><ul><li>의존 ( 사용 관계 )/ 일반화 ( 부분 관계 )  관계와 같이 일방적인 관계가 아닌  Class  간에 대등한 관계 </li></ul></ul>...
힌트와 조언 <ul><li>UML 에서 관계를  Modeling 하려면 </li></ul><ul><ul><li>Modeling  대상 관계가 구조적이 아닌 경우에만 의존 사용 </li></ul></ul><ul><ul><...
6 장 .  공통 메카니즘  (Common Mechanism) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><l...
시작하기 <ul><li>UML Mechanism :  분석 / 설계 내용을 쉽게 이해하도록 산출물 작성 </li></ul><ul><ul><li>명세  (Specification) </li></ul></ul><ul><ul...
용어와 개념 <ul><li>장식  (Adornment) </li></ul><ul><ul><li>Note </li></ul></ul><ul><ul><ul><li>주석을 표현하는  Note 는 의미상 아무런 영향을 미치지 ...
<ul><li>스테레오 타입 (Stereotype) </li></ul><ul><ul><li>UML 에서 제공하는 구조 사물 ,  행동 사물 ,  그룹 사물 ,  주해 사물을 이용한 표현에서 새로운 원시 구성 요소처럼 나...
<ul><li>꼬리표 값  (Tagged Value) </li></ul><ul><ul><li>UML  산출물에 새로운  Property  추가할 때 사용 </li></ul></ul>Server {processors = ...
<ul><li>제약  (Constraint) </li></ul><ul><ul><li>제약을 이용하여 새로운 의미를 추가하거나 기존 규칙을 수정 </li></ul></ul><ul><ul><li>Model 이 잘 구성되도록...
보편적 모델링 기법 <ul><li>주석  (Comment) Modeling </li></ul><ul><ul><li>주석을  Model 에 둠으로써 개발 과정에서 만들어진 각종 분산 산출물 ( 관찰 기록 ,  검토 의견 ...
<ul><li>새로운 구성 요소  Modeling </li></ul><ul><ul><li>UML  구성 요소 (Class, Interface, Collaboration, Component, Node, Relation, ...
<ul><li>새로운  Property Modeling </li></ul><ul><ul><li>포괄적인  Property  보다 상세하게 새로운 구성 요소의  Property 를 꼬리표 값으로 사용 </li></ul><...
<ul><li>새로운 의미   Modeling </li></ul><ul><ul><li>UML 의 목적은 이해를 쉽게 할 수 있으며 의사 소통을 원할 하도록 하는 것이므로 새로운 부분을 표현해야 할 필요가 있을 경우에는 ...
힌트와 조언 <ul><li>Model 에  Note 를 사용하여 장식하려면 </li></ul><ul><ul><li>기존  UML  특성으로는 표현할 수 없을 때 요구 사항 ,  관찰 기록 ,  검토 의견 ,  설명 등을...
7 장 .  도해  (Diagrams) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>시스템의 다양한 뷰 ...
시작하기 <ul><li>도해  (Diagram) </li></ul><ul><ul><li>구성 요소들의 집합 ( 사물들과 그 관계 ) 을  Graphic 으로 표현한 것 </li></ul></ul><ul><ul><li>S...
용어와 개념 <ul><li>System 과  Sub System </li></ul><ul><ul><li>특정 목적을 수행하기 위하여 구성된  Sub System 들로 이루어지며 다양한 시각에서 바라본  Model 들의 ...
보편적 모델링 기법 <ul><li>System 의 다양한  View Modeling </li></ul><ul><ul><li>System 의  Architecture 를 표현하고  Project 의 기술적인 위험을 표현하...
<ul><li>다양한 추상화  Hierarchical Modeling </li></ul><ul><ul><li>추상화 계층을 달리하여 시스템을 표현할 필요가 있을 때 활용 </li></ul></ul><ul><ul><li>...
<ul><ul><li>다양한 추상화 계층  Modeling  방법 </li></ul></ul><ul><ul><ul><li>요구 사항을 고려하여 각자가 원하는 추상화 계층을 결정하고 각 계층에 맞게 별도  Model  작...
<ul><ul><li>하위 추상화 계층의 교류도  </li></ul></ul>:  OrderTaker :  CreditCardAgent :  OrderFulfillment :  BillingAgent acknowledg...
<ul><li>복잡한  View Modeling </li></ul><ul><ul><li>대단히 크고 복잡한 도해를 작성할 때 공통  Pattern 을 파악하여 상위 계층의 협력으로 도해 </li></ul></ul><ul...
힌트와 조언 <ul><li>도해를 만들 때 </li></ul><ul><ul><li>도해의 목적은 시스템의 가시화 ,  명세화 ,  구축 ,  문서화 임 </li></ul></ul><ul><ul><li>도해의 전부를 유지...
8 장 .  클래스도  (Class Diagram) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>단순 협...
시작하기 <ul><li>Class Diagram </li></ul><ul><ul><li>Class, Interface, collaboration, Relation 을 이용하여 시스템의 정적인 관점들을 가시화하고 구축을 ...
용어와 개념 <ul><li>공통  Property </li></ul><ul><ul><li>Class Diagram 은 특별 도해의 하나이지만 다른 모든  Diagram  들과 공통적인  Property 가 존재 </li...
보편적 모델링 기법 <ul><li>단순 협력 모델링 </li></ul><ul><ul><li>존재하는  Class  들 간의 협력 관계를 명세화 </li></ul></ul><ul><ul><li>협력  Modeling  방...
<ul><li>논리  Database Schema Modeling </li></ul><ul><ul><li>Modeling 의 결과로 생성해야 할  Database  구조를 설계 </li></ul></ul><ul><ul>...
School {persistent} name : Name address : String phone : Number addStudent ( ) removeStudent ( ) getStudent ( ) getAllStud...
<ul><li>순 공학과 역 공학 </li></ul><ul><ul><li>순 공학  (Forward Engineering) </li></ul></ul><ul><ul><ul><li>Model 을 대응 언어에 대응시켜  C...
<ul><ul><li>역 공학  (Reverse
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
이남용 창의공학적설계-Uml
Upcoming SlideShare
Loading in …5
×

이남용 창의공학적설계-Uml

3,289 views

Published on

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,289
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
59
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

이남용 창의공학적설계-Uml

  1. 1. 교과목명 창의공학적설계 (CED) (Creative Engineering Design) IT 대학 컴퓨터학부 Prof., NamYong Lee, Ph.D T: 010-5362-5656, e-Mail: nylee@ssu.ac.kr
  2. 2. Creative Thinking
  3. 3. Creative Thinking Alfred Bernhard Novel
  4. 4. <ul><li>알프레드 베르나르드 노벨 (Alfred Bernhard Novel)  </li></ul><ul><li>  </li></ul><ul><li>1833. 10. 21 스웨덴 스톡홀름 ~1896. 12. 10 이탈리아 산레모 . 스웨덴의 화학자 · 공학자 · 실업가 . 다이너마이트 및 그보다 더 강력한 폭발물들을 발명했으며 노벨상을 제정했다 . </li></ul><ul><li>외가 쪽의 조상으로는 림프관에 대한 논문 (1653 경 ) 으로 유명한 스웨덴 자연학자 올로프 루드베크가 있다 . 그는 아버지 이마누엘 노벨에게서 공학의 기초를 배웠으며 아버지를 닮아 발명에 재주가 있었다 . 1842 년 식구 모두 스톡홀름을 떠나 아버지가 있던 상트페테르부르크로 이사했다 . 주로 가정교사에게서 교육을 받은 노벨은 16 세에 벌써 유능한 화학자가 되었으며 , 영어 · 프랑스어 · 독일어 · 러시아어 · 스웨덴어 등에 능통했다 . 1850 년 러시아를 떠나 파리에서 1 년 동안 화학을 공부했고 , 그뒤 미국으로 가서 장갑함 모니터호 ( 號 ) 를 만든 존 에릭슨의 지도를 받으며 4 년 동안 일했다 . 상트페테르부르크로 돌아온 뒤에는 아버지가 경영하던 공장에서 일했다 ( 공장은 1859 년 파산했음 ). </li></ul><ul><li>  </li></ul><ul><li>스웨덴으로 되돌아온 노벨은 폭발성 액체 니트로글리세린을 만들기 시작했다 . 그러나 이 과정에서 1864 년 공장이 폭발하여 막내 동생 에밀을 비롯하여 5 명이 목숨을 잃었다 . ' 미치광이 과학자 ' 로 낙인찍힌 데다가 스웨덴 정부도 공장의 재건을 허락하지 않자 , 노벨은 배 위에서 니트로글리세린 취급에 따른 위험을 극소화시킬 수 있는 방법을 찾기 위해 실험을 시작했다 . 그는 니트로글리세린을 규산질 충전물질인 규조토에 스며들게 하여 건조시키면 안전하게 취급할 수 있다는 사실을 우연히 발견하고서 마침내 완벽한 다이너마이트와 그에 필요한 뇌관 ( 雷管 ) 을 만들어냈다 . 영국 (1867) 과 미국 (1868) 에서 다이너마이트 특허권을 따낸 그는 , 더 강력한 다이너마이트를 개발하기 위한 실험을 거듭한 끝에 폭발성 젤라틴을 개발하여 1876 년 특허를 땄다 . 또 약 10 년 뒤에는 최초의 니트로글리세린 무연화약이자 코르다이트 폭약의 전신인 발리스타이트 (ballistite) 를 만들었다 . 그는 코르다이트 폭약도 자신의 특허권 범위 안에 든다고 주장하여 1894~95 년 영국 정부와 격렬한 법정 소송을 벌였다 . 그러나 노벨은 결국 이 소송에서 졌다 . 그는 화약제조뿐 아니라 발사만으로는 폭발되지 않는 화약에 쓸 뇌관을 만들고 이를 완벽한 수준까지 끌어올렸다 . </li></ul><ul><li>  </li></ul><ul><li>전세계에서 그에게 지불하는 화약류에 대한 사용료와 더불어 러시아 바쿠 유전지대의 대규모 부동산 덕택에 돈을 많이 벌었지만 그때문에 늘 여기저기 돌아다녀야 했다 . 그렇지만 가능하면 은퇴하여 조용히 지내려 애썼으며 , 결혼도 하지 않았다 . 타고난 바탕이 평화주의자였던 노벨은 자기가 발명한 무기로 크고 작은 전쟁을 끝낼 수 있으리라 기대했지만 , 인류와 국가들에 대한 견해는 비관적이었다 . 그는 또한 문학에도 변함없는 관심을 기울였는데 , 젊은시절에는 영어로 시를 쓰기도 했다 . 후에 그의 서류뭉치 속에서 그가 쓴 소설의 초고들이 발견되기도 했다 . </li></ul><ul><li>인도주의적이고 과학적인 자선사업에 돈을 아끼지 않았으며 , 재산의 많은 부분을 기금으로 남겨 오늘날 세계적으로 가장 권위있는 상이 된 노벨상이 제정되었다 . </li></ul>
  5. 5. Creative Thinking Albert Einstein
  6. 6. <ul><li>알베르트 아인쉬타인 ( Albert Einstein )  </li></ul><ul><li>  </li></ul><ul><li>20 세기초의 창조성이 뛰어난 대표적 지식인이었던 알베르트 아인슈타인은 20 세기초 15 년 동안 질량과 에너지 의 등가를 단언하고 공간 · 시간 · 중력에 관한 새로운 사고방식을 제안한 일련의 이론들을 내놓았다 . 그의 상대성 원리와 중력에 관한 이론들은 뉴턴 물리학을 넘어서는 심오한 진전이었고 과학적 탐구와 철학적 탐구에 혁명을 일으켰으며 , 1921 년 노벨 물리학상을 받았다 . 그는 자신이 ' 사회 정의와 사회적 책임이라는 열정적 감각 ' 을 갖고 있음을 인정했다 . 아인슈타인은 그의 명성 덕택으로 평화주의 · 자유주의 · 시오니즘과 같은 대의를 지지하는 데 영향력이 있었다 . 그러나 아이러니컬하게도 이러한 이상주의적인 사람이 물질 입자가 엄청난 양의 에너지로 바뀔 수 있다는 에너지 - 질량 방정식 가설로 지금까지 알려진 가장 파괴적인 무기인 원자폭탄과 수소폭탄의 창조를 증명했다 . </li></ul><ul><li>아인슈타인은 통념과 달리 ' 고독한 천재 ' 가 아닌 장난꾸러기였다 . 아인슈타인은 어떻게 상대성 이론을 만들었을까 ? 알려진 이야기에 따르면 상대성 이론에 대한 아인슈타인의 탐구는 6 살 무렵 , 나침반을 선물로 받은 순간부터 시작됐다고 한다 . 아인슈타인은 상대성 이론의 근간이 되는 아이디어를 과연 어디에서 얻었고 그것을 어떻게 하나의 이론으로 발전시켜 나갔는지 최신의 연구 성과를 토대로 아인슈타인의 삶과 사색의 흔적을 따라가 본다 . </li></ul><ul><li>제작진은 아인슈타인의 출생지인 독일 울름과 , 아인슈타인이 수학한 독일 뮌헨 김나지움 , 스위스 취리히 공대 , 상대성이론을 탄생시킨 스위스 베른 특허청 , 말년을 보낸 미국 프린스턴대를 현지 취재했다 . 천재 과학자의 성적이라고 보기에는 너무나 평범했던 아인슈타인의 학교 성적과 학적부를 공개하고 , 암기 과목을 못했던 아인슈타인이 그리스어 교사로부터 ' 넌 아무것도 되지 못할 것이다 ' 라고 폭언을 들었던 일화를 소개한다 . 또한 상대성 이론이 탄생하기 전후의 미공개 문서들과 베른 특허청에 보관되어 있던 유품들을 공개한다 . </li></ul><ul><li>  이러한 아인슈타인의 흔적을 따라가면서 , 제작진은 기존에 아인슈타인이 ' 고독한 천재 ' 로 알려졌던 것과는 달리 최근에 하버드대 하워드 가드너 교수가 밝힌 것처럼 농담을 즐기며 주변 사람들을 즐겁게 했던 ' 영원한 아이 ' 였음을 보여준다 .   </li></ul>
  7. 7. Creative Thinking A n, ByoungKwon
  8. 8. <ul><li>안병권 ( A n, ByoungKwon )  </li></ul><ul><li>  </li></ul><ul><li>‘ 트랜스포머’가 현실로 , 로봇을 자유자재로 변형하고 , 세포크기까지 줄이는 길 열려 , 물리학과 졸업 안병권 동문 , 전액장학금 받고 MIT 박사과정진학 , 영화 ‘터미네이터 2’ 의 불사조 사이보그 T-1000, ‘ 트랜스포머’에서 자유자재로 변신하던 로봇 범블비 . 상상 속에서만 존재하던 그들을 이제 현실에서 만날 수 있는 길이 열렸다 . 숭실대 물리학과 졸업생인 안병권 (29 ・ MIT 컴퓨터공학과 박사과정 진학예정 ) 동문은 대학 졸업 후 3 년간 외국 원서와 논문을 참고하여 연구한 끝에 ‘자가변이로봇을 소형화 하는데 필요한 소프트웨어 알고리즘과 하드웨어 메커니즘’을 개발 , 로봇을 세포크기까지 줄여 실생활에서 활용할 수 있는 길을 열었다 .   </li></ul><ul><li>안 동문의 설명에 따르면 , 하나의 로봇 ( 개체 ) 은 세포역할을 하는 수많은 큐브 ( 모듈 ) 로 구성되어 있다 . 개체의 성격에 따라 단 몇 개 또는 몇 만 개로도 구성할 수 있다 . 큐브는 그 자체로 세포정도의 단순한 지능을 가지고 있는 모듈이자 소형로봇이다 . 사람의 몸을 수많은 세포가 구성하고 있듯 , 로봇을 수많은 큐브가 구성하고 있는 것 . 이 큐브들은 환경과 미션에 맞게 상황별로 변이하며 세포처럼 개체의 기본단위로서 어떤 물체로도 자유자재로 변이 될 수 있다 . 안 동문은 “이번에 개발한 소프트웨어 알고리즘과 , 하드웨어 메커니즘이 각각의 모듈을 더 단순하면서도 , 이상적인 기능 ( 시뮬레이션에서만 가능하던 기능 ) 을 수행 할 수 있도록 만들었다”며 “새로운 소프트웨어 알고리즘과 하드웨어 메커니즘을 통해 기존의 하드웨어를 크게 단순화 시켜서 세포크기까지 만들 수 있는 길을 열었다”고 말했다 . </li></ul><ul><li>같은 모양의 세포형 모듈로 구성된 자가변이로봇을 개발해 실생활에서 활용하려는 연구는 1980 년대부터 지금까지 미국 기업과 대학 등을 중심으로 진행되고 있다 . 하지만 인간의 세포역할을 해줄 단위모듈의 복잡도가 문제였다 . 최대한 단순하면서 다양한 기능을 수행할 수 있는 단위 모듈을 만들어야만 각각의 모듈을 세포정도의 크기로 줄일 수 있고 , 복잡한 형태의 모양도 쉽게 만들어 고차원적인 활용과 상용화를 할 수 있었던 것 . 안 동문은 “이 기술은 국내 대학에서는 연구 시도조차 못하고 있는 미지의 분야이며 , 미국에서도 인텔 등의 거대기업과 소수의 대학에서만 연구하고 있다”고 말했다 . 또 “ 1980 년대부터 MIT, 카네기멜론 등 美 명문대학에서 수백만 불을 들여 연구하고 있던 분야를 불과 3 백만 원만 투자해 결과를 얻어냈다”고 덧붙였다 . 안 동문은 “세계 최대의 반도체 제작 업체인 인텔에서 조차 현재까지 큐브의 크기를 줄이지 못하고 있다 . 인텔에서는 큐브를 동그랗게 만들어 변형을 시도하려다 실패를 맛보았다”고 말했다 . 또한 다니엘라 루스 MIT 교수는 “안병권 학생은 실제로 만들기 매우 어려운 것을 단순하고 , 이상적으로 만들 수 있게 했다”고 논문 심사평을 통해 말했다 . </li></ul>
  9. 9. <ul><li>안병권 ( A n, ByoungKwon )  </li></ul><ul><li>안 동문이 개발한 기술의 응용분야는 무궁무진하다 . 안 동문은 “영화 ‘트랜스포머’의 범블비가 길에서는 차로 변하고 , 하늘에서는 비행기로 변하듯이 로봇을 자유자재로 변형시킬 수 있다”고 말했다 . 또 “임무를 수행 중인 우주선이나 인공위성의 한 부분이 고장 나도 동작을 멈추지 않고 상황에 따라 변이하며 계속 임무를 수행할 수 있다 . 이는 개별 큐브마다 CPU 가 탑재되어 있어 이와 연동하는 소프트웨어로 처리가 가능한 것”이라고 덧붙였다 . </li></ul><ul><li>그는 또 “특히 의료분야에서 많이 활용할 수 있는데 , 심장이 뛰지 않을 때 세포 크기의 큐브가 심장으로 들어가서 심장을 압박 , 다시 심장이 뛰게 만들 수 도 있고 , 암세포를 제거하는 데도 유용하게 사용될 수 있다”고 말했다 . </li></ul><ul><li>그는 이 기술의 개발과 관련 , MIT 컴퓨터공학과 박사과정의 입학허가를 받아냈다 . 안 동문은 “학부시절 은사인 김진민・김희상 교수 ( 숭실대 물리학과 ) 로부터 물리학을 체계적으로 배웠고 , 또 학과가 다름에도 불구하고 이남용 교수 ( 숭실대 컴퓨터공학 ) 와는 2 학년 말부터 졸업할 때까지 컴퓨터공학을 함께 연구한 것이 큰 도움이 됐다”고 말했다 . </li></ul><ul><li>석사과정을 거치지 않고 박사과정에 바로 입학하는 것이 가능하냐는 질문에 “작년 10 월에 MIT 를 방문했고 담당교수인 다니엘라 루스로부터 입학을 권유받았다”고 말했다 . 하버드 등 외국명문대학을 순회하면서 교수들을 만났다는 그는 “처음에는 ‘시간이 없다’며 만날 기회도 주지 않고 거들떠도 보지 않던 교수들이 한국에서 준비한 연구물을 보여주자 180 도로 달라졌다”고 멋쩍은 듯 말했다 .  </li></ul><ul><li>그는 오는 9 월부터 연간 학비만 해도 6~7 만 불에 이르는 MIT 에서 전액장학금을 받고 공부를 시작한다 . 또 모교인 숭실대로부터 ‘글로벌인재양성’장학금도 받는다 . 그는 이공계 기피현상이 일고 있는 세태를 보며 “학부 시절 물리를 전공한 것이 이번 연구에 무척 도움이 됐다 . 기초과학을 절대 소홀히 하면 안 된다”고 말했다 . 또 “대학생들이 학부 때부터 교수님과 친해져서 논문도 쓰고 연구도 해서 외국무대에서도 당당하게 활약할 기반을 닦으면 좋겠다”고 ‘팁’을 건냈다 . 한편 , 안 동문은 오는 5 월 19 일부터 23 일까지 美 캘리포니아 파사데나에서 열리는 2008 국제전기학회 컨퍼런스 (2008 IEEE International Conference on Robotics and Automation) 에서 이 기술에 대해 발표한다 . 홍보팀 ( [email_address] ) </li></ul>
  10. 10. 창의성 , 공학설계의 개념
  11. 11. 창의성의 개념 <ul><li>창의성의 개념 </li></ul><ul><ul><li>창의성이란 현상을 개선하여 부가가치를 높이는 아이디어를 창출하고 그 아이디어를 실행에 옮겨 혁신을 이루는 능력 </li></ul></ul><ul><ul><li>창의력은 뇌의 모든 부분 (Whole Brain) 을 사용하여 문제를 해결하는 능력이며 , 학습으로 개선할 수 있음 </li></ul></ul><ul><ul><ul><li>문제해결방법 </li></ul></ul></ul><ul><li>창의성의 증진 요건 </li></ul><ul><ul><li>기존 방식의 탈피 </li></ul></ul><ul><ul><li>관심과 호기심 및 유머감각 </li></ul></ul><ul><ul><li>적극적 , 긍정적 , 다양한 사고 </li></ul></ul><ul><ul><li>유연하고 열린 사고 </li></ul></ul><ul><ul><li>칭찬과 인센티브 , 팀 워크 ( Teamwork ) </li></ul></ul>
  12. 12. 창의력을 증진하기 위한 교육의 필요성 <ul><li>20 세기 공학의 접근방법 </li></ul><ul><ul><li>소품 종 대량 생산 </li></ul></ul><ul><ul><li>제조업 중심 , 생산자 중심 </li></ul></ul><ul><ul><li>기계화된 제품 생산체제 </li></ul></ul><ul><ul><li>주어진 문제해결 중심 </li></ul></ul><ul><ul><li>하드웨어 중심의 제품을 많이 만들고 많이 팔자 ! </li></ul></ul><ul><li>21 세기 공학의 접근방법 </li></ul><ul><ul><li>다품 종 소량 생산 </li></ul></ul><ul><ul><li>서비스업 중심 , 소비자 중심 </li></ul></ul><ul><ul><li>IT 기반 지식생산 체제 </li></ul></ul><ul><ul><li>문제를 스스로 발견하고 해결하는 창의성 중심 </li></ul></ul><ul><ul><li>소프트웨어중심의 제품으로 시장을 선점하여 지배하자 ! </li></ul></ul>
  13. 13. 창의력에 도움이 되는 가치관 , 태도 , 행동 <ul><li>그릇된 자존심을 갖지 않는다 . </li></ul><ul><li>성공에 대한 능력을 믿는다 . </li></ul><ul><li>건설적인 불만을 갖는다 . </li></ul><ul><li>도덕적이고 윤리적 기준과 함께 전체적 의식을 갖는다 . </li></ul><ul><li>자제심을 갖는다 . </li></ul><ul><li>끈기 있고 , 사리사욕이 없고 , 정직하고 , 열심히 일한다 . </li></ul><ul><li>규율을 지키고 , 친절하고 , 믿을 만하고 , 편견이 없고 , 봉사적이다 . </li></ul>
  14. 14. 창의력을 신장하기 위한 전략 <ul><li>창의력을 신장시키기 위한 전략 </li></ul><ul><ul><li>고정관념의 틀을 벗으려고 하는가 ? </li></ul></ul><ul><ul><li>남의 이야기에 귀를 기울이는가 ? </li></ul></ul><ul><ul><li>도전적이며 위험을 감수하는 편인가 ? </li></ul></ul><ul><ul><li>차별성이 있는가 ? </li></ul></ul><ul><ul><li>서로 다른 것을 조합하고 연결할 수 있는가 ? </li></ul></ul><ul><ul><li>뒤집어 생각할 줄 아는가 ? </li></ul></ul><ul><ul><li>자유로운 발상을 하는가 ? </li></ul></ul><ul><ul><li>질문을 많이 하는가 ? </li></ul></ul><ul><ul><li>기록은 잘하고 있는가 ? </li></ul></ul>
  15. 15. 창의성과 지능의 관계 <ul><li>지능 </li></ul><ul><ul><li>학습능력과 적응능력 등 추상적 능력 </li></ul></ul><ul><ul><li>배우고 이해하는 능력 , 복잡한 상황에 대처하는 능력 </li></ul></ul><ul><li>창의력 </li></ul><ul><ul><li>새로운 것 , 자기만의 생각이나 가치가 있는 것을 만들어 내는 능력 </li></ul></ul><ul><ul><li>이런 능력을 뒷받침해 주는 성격상의 특성 </li></ul></ul><ul><li>창의성과 지능과의 관계 </li></ul><ul><ul><li>대단히 지적인 사람  대단히 창의적인 사람 (X) </li></ul></ul><ul><ul><li>창의성과 지능은 고유한 특성을 가지면서 부분적 공통부분 존재 </li></ul></ul><ul><ul><li>독창적인 사고 : 창의성 > 지능 </li></ul></ul><ul><ul><li>결론 </li></ul></ul><ul><ul><ul><li>지능이 높다  학습을 잘한다 (O)  창의력이 높다 ? </li></ul></ul></ul><ul><ul><ul><li>창의력이 높다  좋은 아이디어를 낸다 (O)  지능이 높다 ? </li></ul></ul></ul><ul><ul><ul><li>창의성은 계발될 수 있다 . </li></ul></ul></ul>
  16. 16. 공학의 개념 <ul><li>공학은 문제해결을 위한 응용학문이다 . </li></ul><ul><ul><li>The application of scientific principles to the optimal conversion of natural resources into structures, machines, products, systems, and processes for the benefit of mankind. (Refer: Encyclopedia Britannica ) </li></ul></ul><ul><li>문제 </li></ul><ul><ul><li>인간의 삶의 질 향상을 위한 환경개선 , 생산 , 가공 및 서비스 방법에 대한 고민 </li></ul></ul><ul><li>공학의 특성 </li></ul><ul><ul><li>수학 , 과학 , 공학 지식 </li></ul></ul><ul><ul><li>경제성 </li></ul></ul><ul><ul><li>창의성 </li></ul></ul><ul><ul><li>자연과 환경 , 사회문화와 소비자 요구 이해 </li></ul></ul><ul><ul><li>팀 활동 </li></ul></ul>
  17. 17. 공학설계의 개념 <ul><li>공학설계의 정의 </li></ul><ul><ul><li>필요한 것을 만들기 위해 시스템 , 요소 , 프로세스를 고안하는 과정 - 미국 공학기술인증원 ( ABET: Accrediation Board for Engineering and Technology), 한국공학교육인증원 (ABEEK) 에서도 위와 동일하게 정의하고 있음 (ABEEK : Accreditation Board for Engineering Education of Korea) </li></ul></ul><ul><ul><li>즉 , 공학은 기초과학 , 수학 , 공학을 응용하여 자원을 원하는 목적 또는 목표에 부합하도록 가공하는 의사결정과정 </li></ul></ul><ul><li>공학설계의 특성 </li></ul><ul><ul><li>다양한 학문을 응용하는 다학문적 프로세스 ( Interdisciplinary Process ) </li></ul></ul><ul><ul><li>복잡함 ( Complicated ) </li></ul></ul><ul><ul><li>창의적이면서 동시에 분석적 ( Creativity and Analysis ) </li></ul></ul><ul><ul><li>반복적인 프로세스 ( Iterative Process ) </li></ul></ul>
  18. 18. 공학설계프로세스의 개념 <ul><li>공학설계프로세스의 정의 </li></ul><ul><ul><li>공학설계의 단계를 설명하고 , 체계적으로 공학설계를 수행할 수 있도록 함 </li></ul></ul><ul><ul><li>공학설계 프로세스는 여러 분야에서 많은 학자들에 의해 다양하게 정의되고 있음 </li></ul></ul><ul><ul><li>일반적인 공학설계 프로세스 </li></ul></ul><ul><ul><ul><li>문제식별과 정의 ( Problem Identification and Definition) </li></ul></ul></ul><ul><ul><ul><li>기준과 제약사항의 설정 ( Establishment of Criteria and Constraints ) </li></ul></ul></ul><ul><ul><ul><li>정보 및 자료의 수집과 분석 ( Information and Data Analysis ) </li></ul></ul></ul><ul><ul><ul><li>해결방안의 도출과 검토 ( Consideration of Alternatives ) </li></ul></ul></ul><ul><ul><ul><li>해결방안의 의사결정 ( Decision ) </li></ul></ul></ul><ul><ul><ul><li>구체적으로 명세화 ( Specification ) </li></ul></ul></ul>
  19. 19. 창의적공학설계의 개념 <ul><li>공학설계의 능력을 배양하기 위한 교과목 </li></ul><ul><ul><li>유능한 공학자 ( 엔지니어 ) 가 되기 위한 자질을 교육 </li></ul></ul><ul><li>공학자 </li></ul><ul><ul><li>기술적인 문제의 경제적인 해결책을 찾기 위해 과학과 수학적 원리를 응용하는 사람 - 미국노동통계국 ( The Bureau of Labor Statistic ) </li></ul></ul><ul><ul><li>공학자의 활동은 사회적 요구 (Social Needs) 와 소비자의 요구 (Consumer Needs) 를 충족하기 위해 과학적 탐구 (Scientific Discoveries) </li></ul></ul><ul><ul><li>과학자가 새로운 지식을 발견하는 사람이라면 , 공학자는 그러한 지식을 활용하여 제품 , 신기술을 만들어내는 사람 </li></ul></ul>
  20. 20. 창의적공학설계의 교육목표 <ul><li>ABEEK 에서는 공학전공 졸업자들에게 다음과 같은 능력과 자질을 갖추도록 요구하고 있음 ( 창의적공학설계의 목표학습성과 ) </li></ul><ul><ul><li>수학 , 기초과학 , 공학의 지식과 정보기술을 응용할 수 있는 능력 </li></ul></ul><ul><ul><li>자료를 이해하고 분석할 수 있는 능력 및 실험을 계획하고 수행할 수 있는 능력 </li></ul></ul><ul><ul><li>현실적 제한조건을 반영하여 시스템 , 요소 , 공정을 설계할 수 있는 능력 </li></ul></ul><ul><ul><li>공학 문제들을 인식하며 , 이를 공식화하고 해결할 수 있는 능력 </li></ul></ul><ul><ul><li>공학 실무에 필요한 기술 , 방법 , 도구들을 사용할 수 있는 능력 </li></ul></ul><ul><ul><li>복합 학제적 팀의 한 구성원의 역할을 해낼 수 있는 능력 </li></ul></ul><ul><ul><li>효과적으로 의사를 전달할 수 있는 능력 </li></ul></ul><ul><ul><li>평생교육의 필요성에 대한 인식과 능동적으로 참여할 수 있는 능력 </li></ul></ul><ul><ul><li>공학적 해결방안이 세계적 , 경제적 , 환경적 , 사회적 상황에 끼치는 영향을 이해할 수 있는 폭넓은 지식 </li></ul></ul><ul><ul><li>시사적 논점들에 대한 기본지식 </li></ul></ul><ul><ul><li>직업적 책임과 윤리적 책임에 대한 인식 </li></ul></ul><ul><ul><li>세계문화에 대한 이해와 국제적으로 협동할 수 있는 능력 </li></ul></ul>
  21. 21. 소프트웨어공학의 개념 <ul><li>일반적인 정의 : 소프트웨어시스템 ( 제품 ) 의 개발에 대한 공학적 접근방법을 연구하는 학문 </li></ul><ul><li>IEEE 의 정의 : 소프트웨어의 개발과 운용 및 유지보수에 대한 체계적 (systematic) 이며 훈련된 (disciplined) 계량적 (quantifiable) 접근 방법 </li></ul><ul><li>Bauer 의 정의 : 컴퓨터 H/W 에서 신뢰성 있게 운영되는 S/W 를 경제성 있게 개발하기 위해 공학적 원리를 응용하는 방법 </li></ul><ul><li>Boehm 의 정의 : 컴퓨터 프로그램의 설계 , 개발 , 운영 , 유지보수와 관련하여 문서를 작성하는데 필요한 과학적 지식의 응용 </li></ul><ul><li>Fairley 의 정의 : 컴퓨터과학 , 경제학 , 경영과학 , 의사소통기술 , 문제해결을 위한 공학적 기법을 기반으로 S/W 개발과 관련된 새로운 기술체계 </li></ul>
  22. 22. 소프트웨어공학과 공학설계 <ul><li>소프트웨어의 공학설계 프로세스 </li></ul><ul><ul><li>문제식별과 정의 ( Problem Identification and Definition) </li></ul></ul><ul><ul><li>요구사항분석 ( Requirement Analysis ) </li></ul></ul><ul><ul><li>구조설계 ( Structural Design ) </li></ul></ul><ul><ul><li>동작설계 ( Behavioral Design ) </li></ul></ul><ul><li>소프트웨어의 공학설계 표기법 ( 언어 ) </li></ul><ul><ul><li>UML ( Unifiend Modeling Language ) </li></ul></ul><ul><ul><ul><li>창의적 공학설계 언어 </li></ul></ul></ul><ul><ul><ul><li>창의적 공학설계 표기법 ( 언어 ) </li></ul></ul></ul><ul><ul><ul><li>국제표준언어 </li></ul></ul></ul>
  23. 23. 창의적 문제해결과 기법
  24. 24. 창의적 문제해결 <ul><li>창의적 문제해결의 정의 </li></ul><ul><ul><li>“ Creative problem solving is - looking at the same thing as everyone else and thinking something different.” - 노벨상 수상자 , Albert Szent-Gyorgi </li></ul></ul><ul><ul><li>창의적 문제해결의 핵심은 정보를 이용하는 것이 아니라 지식을 활용하는 것 </li></ul></ul><ul><ul><li>창의적 문제해결을 위해서는 새로운 아이디어를 찾고자 하는 의지를 가지고 자신의 지식과 경험을 활용하여야 함 </li></ul></ul><ul><ul><li>사고를 전환하고 지식을 활용하여 일상적인 것에 특별함을 부여하는 것 </li></ul></ul>
  25. 25. 창의적 문제해결 <ul><li>창의적 문제해결의 예 </li></ul><ul><ul><li>4 개의 직선으로 다음 9 개의 점을 이어 보시오 . </li></ul></ul>
  26. 26. 창의적 문제해결 <ul><li>창의적 문제해결의 예 </li></ul><ul><ul><li>4 개의 직선으로 다음 9 개의 점을 이어 보시오 . </li></ul></ul>
  27. 27. 창의적 문제해결 <ul><li>우리는 왜 좀더 일상생활에서 창의적인 생각들을 하지 않는가 ? </li></ul><ul><li>우리가 창의적 사고를 하는 데 있어 방해요소들은 무엇인가 ? </li></ul>
  28. 28. 창의적 문제해결 <ul><li>창의적 문제해결에 있어서의 장애요소 </li></ul><ul><ul><li>시간 </li></ul></ul><ul><ul><ul><li>창의적인 사고는 많은 시간을 필요로 함 </li></ul></ul></ul><ul><ul><li>필요성 </li></ul></ul><ul><ul><ul><li>굳이 모든 것들을 창의적으로 해결할 필요는 없음 </li></ul></ul></ul><ul><ul><li>버릇이나 습관 </li></ul></ul><ul><ul><li>특별할 것 없는 일상 생활 </li></ul></ul><ul><ul><li>창의성에 대한 학습의 부재 </li></ul></ul>
  29. 29. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul><ul><ul><li>일상적인 사고를 벗어나지 못하는 마음가짐 </li></ul></ul><ul><ul><ul><li>“ 난 창의적이지 못하다” </li></ul></ul></ul><ul><ul><ul><li>“ 창의적 사고는 어렵다” </li></ul></ul></ul><ul><ul><li>창의적 사고를 하지 못하는 이유 멘탈블럭 10 가지 </li></ul></ul>1. The _______ answer. 2. That’s not _________. 3. __________ the rules. 4. Be ______________. 5. ________ is frivolous. 6. That’s not my _____. 7. ________ ambiguity. 8. Don’t be _________. 9. __________is wrong. 10. I’m not __________.
  30. 30. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>1. The right answer. Only one ?  정답은 한가지가 아니다
  31. 31. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>2. That’s not logical.  비논리적인 것도 논리적이 될 수 있다
  32. 32. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>3. Follow the rules.  룰을 벗어나야 새로운 생각을 가질 수 있다 . <ul><li>룰 (Rule) </li></ul><ul><li>필요성에 대한 공통된 인식을 통해 만들어진 것 </li></ul><ul><li>모든 사람들은 룰을 지킴 . </li></ul>
  33. 33. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>4. Be practical.  반드시 실용적인 것만이 창의적인 것은 아니다 .
  34. 34. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>5. Play is frivolous.  사소한 것도 창의적인 것이 될 수 있다 . “ When do you get your best ideas?”
  35. 35. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>6. That’s not my area.  창의적 사고는 자신의 영역을 벗어날 때 이루어진다 .
  36. 36. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>7. Avoid ambiguity.  사람들은 모호한 것을 볼 때 창의적인 사고를 하게 된다 . AMBIGUITY
  37. 37. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>8. Don’t be foolish.  바보 같은 사고가 가장 천재적인 사고가 될 수 있다 .
  38. 38. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>9. To err is wrong.  실패는 나쁜 것이 아니다 .
  39. 39. 창의적 문제해결 <ul><li>멘탈 블럭 ( Mental Blocks ) </li></ul>10. I’m not creative.  자신이 창의적이지 못하다는 생각을 버려야 한다 .
  40. 40. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>문제의 정의 </li></ul><ul><ul><li>근본적인 문제를 기술하기 보다 , 문제해결을 위한 시작점을 설정 </li></ul></ul><ul><ul><li>즉 , “ 어떠한 문제가 있을 것 같다” 라는 가정을 도출하는 단계 </li></ul></ul><ul><ul><li>따라서 , 여기서 정의된 문제는 추후에 변경될 수도 있음 </li></ul></ul>STEP 1. State what appears to be the problem
  41. 41. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>자료의 수집 </li></ul><ul><ul><li>문제의 원인은 무었인가 ? </li></ul></ul><ul><ul><li>언제 , 어디서 , 어떻게 발생하는가 ? </li></ul></ul><ul><ul><li>크기 , 범위 , 심각성 등은 어느 정도나 되는가 ? </li></ul></ul><ul><ul><li>누구에게 어떠한 영향을 미치는가 ? </li></ul></ul><ul><ul><li>반드시 해결되어야 하는가 ? </li></ul></ul>STEP 2. Gather facts, feelings and opinions.
  42. 42. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>문제의 재정의 </li></ul><ul><ul><li>수집된 자료를 통해서 정확한 문제를 정의하는 단계 </li></ul></ul><ul><ul><li>실제 문제는 어떠한 원인에 의해 발생되며 , 어떠한 영향을 끼치게 되는지 구체적으로 정의 </li></ul></ul>STEP 3. Restate the problem.
  43. 43. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 모색 </li></ul><ul><ul><li>아이디어를 제시하고 가능한 많은 해결방법들을 모색하는 단계 </li></ul></ul><ul><ul><li>아주 사소한 해결책까지도 간과해서는 안됨 . </li></ul></ul><ul><ul><li>다른 사람들과 가능한 많은 토론을 통해 찾아내는 것이 유용함 . </li></ul></ul>STEP 4. Identify Alternative Solutions.
  44. 44. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 평가 </li></ul><ul><ul><li>여러 해결방법들을 평가하고 최선의 해결방법을 찾아내는 단계 </li></ul></ul><ul><ul><li>효과 / 비용 측면들이 고려됨 </li></ul></ul><ul><ul><li>선택된 해결방법이 또 다른 문제의 원인이 되지 않는지 검토기 필요 </li></ul></ul>STEP 5. Evaluate Alternatives.
  45. 45. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 적용 </li></ul><ul><ul><li>최종적으로 채택된 해결방법을 적용하는 단계 </li></ul></ul><ul><ul><li>누가 , 어디서 , 언제 , 어떠한 방법으로 적용시킬 것인지를 결정 </li></ul></ul><ul><ul><li>적용결과는 어떻게 수집되고 평가될 것인지를 결정 </li></ul></ul>STEP 6. Implement the decision.
  46. 46. 창의적 문제해결 프로세스 <ul><li>창의적으로 문제를 해결하는 절차 </li></ul><ul><li>해결책 평가 </li></ul><ul><ul><li>해결방법을 통해 원하는 결과가 수집되었는지를 평가하는 단계 </li></ul></ul><ul><ul><li>원가는 결과가 수집되지 않았다면 , 해결방법을 수정하고 다시 적용하여 문제를 해결 </li></ul></ul>STEP 7. Evaluate the results.
  47. 47. 창의적 문제해결 기법
  48. 48. 창의적 문제해결 기법 <ul><li>창의적 문제해결 기법은 크게 2 가지로 구분됨 </li></ul><ul><ul><li>확산적 사고 ( 생성적 사고 ) 를 통한 문제해결 </li></ul></ul><ul><ul><ul><li>새로운 아이디어 ( 대안 , 가능성 ) 를 생성하고 , 표현하는 것 </li></ul></ul></ul><ul><ul><ul><ul><li>브레인스토밍 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>스캠퍼 </li></ul></ul></ul></ul><ul><ul><li>초점적 사고 ( 비판적 사고 ) 를 통한 문제해결 </li></ul></ul><ul><ul><ul><li>발산적 사고를 통해 제안된 아이디어를 분석하여 선택하거나 보완하여 구체적인 문제해결방법을 찾아내는 것 </li></ul></ul></ul><ul><ul><ul><ul><li>마인드맵 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>PMI 기법 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>평가행렬법 </li></ul></ul></ul></ul>
  49. 49. 창의적 문제해결 기법 <ul><li>브레인스토밍 ( Brainstorming ) </li></ul><ul><ul><li>특정한 주제에 대하여 머리 (brain) 에서 폭풍 (storming) 이 몰아치듯 생각나는 아디어를 되도록 많이 내어 놓는 방법 </li></ul></ul><ul><ul><li>짧은 시간에 많은 아이디어를 만들어 내는 것이 목적 </li></ul></ul><ul><ul><ul><li>주로 집단 토의에서 활용 </li></ul></ul></ul><ul><li>브레인스토밍 기법 활용하는 경우 </li></ul><ul><ul><li>문제의 근본 원인을 모두 찾으려 할 때 </li></ul></ul><ul><ul><li>문제의 해결책을 찾으려 할 때 </li></ul></ul><ul><ul><li>어떤 개선활동을 해야할지 결정할 때 </li></ul></ul><ul><ul><li>프로젝트의 각 단계별 계획을 세울 때 </li></ul></ul><ul><ul><li>공정 , 제품 , 서비스 등의 개선방안을 찾을 때 </li></ul></ul>
  50. 50. 창의적 문제해결 기법 <ul><li>브레인스토밍의 진행방식 </li></ul><ul><ul><li>5~12 명 정도로 집단을 구성하고 , 나이 , 성별 , 관심 , 전공 등 되도록 다양한 측면의 사람들이 에서 동일한 문제를 접근할 수 있도록 함 </li></ul></ul><ul><ul><li>진행 중에는 토의와 비판을 금지 </li></ul></ul><ul><ul><ul><li>아이디어에 새로운 아이디어를 추가하는 것은 허용 </li></ul></ul></ul><ul><ul><li>아이디어는 빠뜨리지 않도록 기록하고 스티꺼나 큰 칠판을 활용 </li></ul></ul><ul><ul><li>바보 같거나 , 미친 듯한 아이디어도 수용하고 기록 </li></ul></ul><ul><li>브레인스토밍의 4S 규칙 </li></ul><ul><ul><li>Support : 어떤 아이디어라도 절대로 비판하거나 평가하지 않는다 </li></ul></ul><ul><ul><li>Silly : 비현설적이거나 터무니없는 것이더라도 모두 수용한다 . </li></ul></ul><ul><ul><li>Speed : 가능한 한 많은 아이디어를 제안한다 . </li></ul></ul><ul><ul><li>Synergy : 두 개 이상의 다른 아이디어를 결합 , 새로운 아이디어를 이끌어 낸다 . </li></ul></ul>
  51. 51. 창의적 문제해결 기법 <ul><li>스캠퍼 ( SCAMPER ) </li></ul><ul><ul><li>특정 대상이나 문제에 7 가지의 대표적인 질문을 활용하여 사고를 자극함으로써 새로운 아이디어를 얻는 기법 </li></ul></ul><ul><ul><li>7 가지 질문 </li></ul></ul><ul><ul><ul><li>대체하기 ( S ubstitute ) </li></ul></ul></ul><ul><ul><ul><li>결합하기 ( C ombine ) </li></ul></ul></ul><ul><ul><ul><li>적용시키기 ( A dapt ) </li></ul></ul></ul><ul><ul><ul><li>수정 - 확대 - 축소하기 ( M odify-Magnify-Minify ) </li></ul></ul></ul><ul><ul><ul><li>용도변경하기 ( P ut to other uses ) </li></ul></ul></ul><ul><ul><ul><li>제거하기 ( E liminate ) </li></ul></ul></ul><ul><ul><ul><li>재정리하기 ( R earrange ) </li></ul></ul></ul>
  52. 52. 창의적 문제해결 기법 <ul><li>스캠퍼 ( SCAMPER ) </li></ul><ul><ul><li>대체하기 ( S ubstitute ) </li></ul></ul><ul><ul><ul><li>제품의 본질적인 기능을 유지하면서 다른 재료 , 부품 , 에너지 등으로 대체하는 것 </li></ul></ul></ul><ul><ul><ul><ul><li>종이컵 , 물침대 , 태양전지자동차 등 </li></ul></ul></ul></ul><ul><ul><li>결합하기 ( C ombine ) </li></ul></ul><ul><ul><ul><li>다른 기능이 가지는 두 가지 이상의 제품을 결합하기 </li></ul></ul></ul><ul><ul><ul><ul><li>지우개 달린 연필 , 핸드폰카메라 등 </li></ul></ul></ul></ul><ul><ul><li>적용시키기 ( A dapt ) </li></ul></ul><ul><ul><ul><li>다른 물건이나 제품의 기능을 적용하기 </li></ul></ul></ul><ul><ul><ul><ul><li>장미덩쿨  철조망 , 돌고래  수증음파탐지기 등 </li></ul></ul></ul></ul>
  53. 53. 창의적 문제해결 기법 <ul><li>스캠퍼 ( SCAMPER ) </li></ul><ul><ul><li>수정 - 확대 - 축소하기 ( M odify-Magnify-Minify ) </li></ul></ul><ul><ul><ul><li>기존제품을 수정 , 확대 , 축소하기 </li></ul></ul></ul><ul><ul><ul><ul><li>Post-it, 워크맨 , PMP 등 </li></ul></ul></ul></ul><ul><ul><li>용도변경하기 ( P ut to other uses ) </li></ul></ul><ul><ul><ul><li>기존 제품의 용도를 변경하기 </li></ul></ul></ul><ul><ul><ul><ul><li>페타이어  발전소원료 , 톱밥  장작 </li></ul></ul></ul></ul><ul><ul><li>제거하기 ( E liminate ) </li></ul></ul><ul><ul><ul><li>기존제품의 불필요한 부분을 제거하기 </li></ul></ul></ul><ul><ul><ul><ul><li>씨없는 수박 등 </li></ul></ul></ul></ul><ul><ul><li>재정리하기 ( R earrange ) </li></ul></ul><ul><ul><ul><li>기존 제품의 기능 또는 특성을 재정리하거나 역으로 배치하기 </li></ul></ul></ul><ul><ul><ul><ul><li>다섯발가락 양말 , 누드 김밥 등 </li></ul></ul></ul></ul>
  54. 54. 창의적 문제해결 기법 <ul><li>스캠퍼 기법을 이용한 다기능성 자전거 아이디어 </li></ul><ul><ul><li>S : 기존의 공기 주입식 타이어 대신 바람을 넣지 않는 타이어로 대체 </li></ul></ul><ul><ul><li>C : 에너지 저장장치를 장착하여 핸드폰을 충전 시킴 </li></ul></ul><ul><ul><li>A : 자전거 바퀴회전을 이용하여 솜사탕 기계로 기능을 바꾼 </li></ul></ul><ul><ul><li>M : 커플자전거 , 큰 짐을 실을 수 있는 자전거 , 어린이 자전거 </li></ul></ul><ul><ul><li>P : 우천 시 헬스 기구로 활용 </li></ul></ul><ul><ul><li>E : 외발자전거 </li></ul></ul><ul><ul><li>R : 전륜 구동 자전거 </li></ul></ul>
  55. 55. 창의적 문제해결 기법 <ul><li>마인드맵 ( Mind Map ) </li></ul><ul><ul><li>수렴적 사고 기법 </li></ul></ul><ul><ul><li>문제에 대하여 큰 빈 종이 위에 이미지와 핵심단어를 색과 부호 등을 이용하여 지도를 그려나가는 방법 </li></ul></ul><ul><ul><li>아이디어를 조직화하고 정보를 서로 연결하여 체계적으로 기억할 수 있게 하고 보다 세부적으로 아이디어를 다듬을 수 있도록 함 </li></ul></ul><ul><li>마인드 맵의 구조 </li></ul><ul><ul><li>생각의 핵심이 되는 주제는 항상 중심 이미지에서 시작 </li></ul></ul><ul><ul><li>중심 이미지에 관련된 주요 주제는 사람의 몸에 붙어있는 팔처럼 연결되어 표현 </li></ul></ul><ul><ul><li>가지들의 연결은 핵심 이미지와 핵심단어를 통해 확산 </li></ul></ul><ul><ul><li>계속 이어지는 부주제들은 나뭇가지의 마디마디가 서로 연결되어 있는 듯한 구조 </li></ul></ul>
  56. 56. 창의적 문제해결 기법 <ul><li>마인드 맵의 예 </li></ul>
  57. 57. 창의적 문제해결 기법 <ul><li>PMI 기법 </li></ul><ul><ul><li>수렴적 사고 기법 </li></ul></ul><ul><ul><li>제안된 아이디어의 장점 (P), 단점 (M), 흥미로운 점 (I) 을 따져본 후 그 아이디어를 평가하는 기법 </li></ul></ul><ul><ul><li>PMI 평가요소 </li></ul></ul><ul><ul><ul><li>Plus : 제시된 아이디어의 좋은 점 </li></ul></ul></ul><ul><ul><ul><li>Minus : 제시된 아이디어의 나쁜 점 </li></ul></ul></ul><ul><ul><ul><li>Interesting : 제시된 아이디어와 관련하여 흥미로운 점 </li></ul></ul></ul><ul><ul><li>PMI 적용사례 </li></ul></ul><ul><ul><ul><li>아이디어 : 바이오 디젤 자동차 </li></ul></ul></ul><ul><ul><ul><ul><li>P : 환경오염을 줄일 수 있다 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>M : 식량난을 초래할 수 있다 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>I : 식물성 기름도 연료로 사용될 수 있다 . </li></ul></ul></ul></ul>
  58. 58. 창의적 문제해결 기법 <ul><li>평가행렬법 </li></ul><ul><ul><li>수렴적 사고 기법 </li></ul></ul><ul><ul><li>체계적으로 제안된 아이디어를 평가하는 방법으로서 평가하려는 아이디어를 평가 기준에 따라 객관적으로 평가하는 것 </li></ul></ul><ul><ul><li>아이디어의 평가기준을 가로축으로 , 아이디어를 세로축으로 하여 행렬을 만들고 평가기준을 더하거나 곱하여 평가결과값을 산정 </li></ul></ul>아이디어 구입비용 관리비용 속도 편리성 실현 가능성 합계 버스 20 14 12 14 5 65 중형차 17 19 15 19 2 72 경차 14 10 15 19 3 61 스쿠터 10 5 13 15 18 61 자전거 5 3 10 10 32 60
  59. 59. 창의적 공학설계 표기법 ( 모델링언어 ) Unified Modeling Language (UML)
  60. 60. 목 차 <ul><li>[1] UML 개념 </li></ul><ul><li>[2] 기본 구조 모델링 </li></ul><ul><li>[3] 고급 구조 모델링 </li></ul><ul><li>[4] 기본 행동 모델링 </li></ul><ul><li>[5] 고급 행동 모델링 </li></ul><ul><li>[6] 아키텍쳐 모델링 </li></ul><ul><li>[7] UML 적용 </li></ul>
  61. 61. [1] UML 개념 <ul><li>1 장 . 왜 모델을 만드는가 ? </li></ul><ul><li>2 장 . UML 소개 </li></ul><ul><li>3 장 . UML 의 기초 </li></ul>
  62. 62. 1 장 . 왜 모델을 만드는가 ? <ul><li>모델링의 중요성 </li></ul><ul><li>모델링의 원리 </li></ul><ul><li>객체지향 모델링 </li></ul>
  63. 63. 모델링의 중요성 <ul><li>모델링 (Modeling) </li></ul><ul><ul><li>모델을 만드는 일 ( 추상화 ) 로써 품질이 좋은 소프트웨어를 개발 및 배치할 수 있게 하는 모든 활동의 중심 </li></ul></ul><ul><ul><li>모델 구축을 통해 개발 대상 시스템에 대한 이해의 증진 </li></ul></ul><ul><li>모델 (Model) </li></ul><ul><ul><li>현실을 단순화 / 가시화 시키는 것 </li></ul></ul><ul><ul><li>System 의 Blueprint 를 제공 </li></ul></ul><ul><ul><li>개발 고려 시스템의 총체적인 계획 및 상세 계획 표현 </li></ul></ul><ul><ul><li>중요 영향 요소의 파악 , 불 필요 요소의 생략 및 시스템 구축 제약 조건 표현 </li></ul></ul><ul><li>모델링의 목적 </li></ul><ul><ul><li>시스템을 현재 또는 원하는 모습으로 가시화 </li></ul></ul><ul><ul><li>시스템의 구조와 행동을 명세화 </li></ul></ul><ul><ul><li>시스템을 구축하는 기본 형태를 제공 </li></ul></ul><ul><ul><li>시스템 분석 / 설계의 문서화 </li></ul></ul>
  64. 64. 모델링의 원리 <ul><li>모델링의 원리 </li></ul><ul><ul><li>생성할 모델의 신중한 선택 : 선택 모델에 따라 문제를 공략하는 방법과 해결책을 실현하는 방법에 많은 영향이 있음 </li></ul></ul><ul><ul><li>모든 모델을 다양한 수준의 정밀도로 표현 </li></ul></ul><ul><ul><li>현실을 반영한 모델 작성 </li></ul></ul><ul><ul><li>상호 독립적인 모델들 몇 가지를 선택하여 모델링에 착수 </li></ul></ul>
  65. 65. 객체 지향 모델링 <ul><li>소프트웨어의 모델링 관점 </li></ul><ul><ul><li>알고리즘 관점 : S/W 의 주요 구성 요소인 Procedure 와 Function 을 제어 관점에서 분할하여 시스템을 모형화 </li></ul></ul><ul><ul><ul><li>요구사항 변화에 적응력이 없음 </li></ul></ul></ul><ul><ul><ul><li>대규모 시스템에서는 유지보수를 포함한 관리의 어려움 </li></ul></ul></ul><ul><ul><li>객체 지향 관점 : S/W 시스템의 기본 요소를 객체 또는 클래스로 파악하여 문제 영역과 해결 영역을 모형화 </li></ul></ul><ul><ul><li>객체 (Object) : 사물 (Thing) 을 말하며 고유성과 상태 , 행동을 갖음 </li></ul></ul><ul><ul><li>클래스 (Class) : 공통적인 객체들의 집합 </li></ul></ul><ul><li>UML(Unified Modeling Language) 의 목적 </li></ul><ul><ul><li>객체 지향 시스템을 가시화 , 명세화 , 문서화 하는 것 </li></ul></ul>
  66. 66. 2 장 . UML 소개 <ul><li>UML 개요 </li></ul><ul><li>UML 개념 모델 </li></ul><ul><li>UML 아키텍쳐 </li></ul><ul><li>UML 개발 생명주기 </li></ul>
  67. 67. UML 개요 <ul><li>UML 은 언어 (Language) </li></ul><ul><ul><li>어휘와 규칙을 두어 시스템을 개념적이고 물리적으로 표현하여 의사 소통을 돕는 것을 목적으로 함 </li></ul></ul><ul><ul><li>시스템을 이해하기 위하여 하나 이상의 모델을 서로 연결 사용하여 복합적인 모델로 이해를 도움 </li></ul></ul>가시화 명세화 구축 문서화 UML S/W 청사진 작성 표준언어 SYSTEM 산출물
  68. 68. UML 가시화 언어 개념 모델 작성 오류 없이 전달 의사 소통의 용이 Graphic 언어 구축 언어 다양한 Prog. 언어와 연결 왕복 공학 가능 ( 순 공학 / 역공 학 ) 실행 시스템 예측 가능 명세화 언어 정확한 모델 제시 완전한 모델 작성 분석 , 설계의 결정 표현 문서화 언어 시스템에 대한 통제 , 평가 , 의사소통의 문서 ( 요구사항 , Architecture, 설계 , Source Code, Project 계획 ,Test, Prototype, Release)
  69. 69. UML 개념 모델 <ul><li>UML 구성 요소 </li></ul>
  70. 70. <ul><li>사물 (Things) : 추상적 개념으로 모형 구성의 기본 요소 </li></ul><ul><ul><li>구조 사물 (Structural Thing) : UML 모형의 명사형으로써 모형의 정적인 부분이며 개념적이거나 물리적인 요소들을 표현 </li></ul></ul><ul><ul><ul><li>클래스 (Class) </li></ul></ul></ul><ul><ul><ul><li>동일한 속성 (Attribute), Operation, 관계 , 그리고 의미를 공유하는 객체를 표현 </li></ul></ul></ul><ul><ul><ul><li>인터페이스 (Interface) </li></ul></ul></ul><ul><ul><ul><li>Class 또는 Component 의 Service 를 명세화 하는 Operation 들의 집합 </li></ul></ul></ul><ul><ul><ul><li>외부적으로 가시화 할 수 있는 요소의 행동을 설명 </li></ul></ul></ul><ul><ul><ul><li>특정 Class 나 Component 의 전체 또는 일부분 만의 행동을 표현 </li></ul></ul></ul>Window origin size open ( ) close ( ) move ( ) display ( ) ISpelling
  71. 71. <ul><ul><ul><li>협력 (Collaboration) </li></ul></ul></ul><ul><ul><ul><li>교류 (Interaction) 를 정의하며 서로 다른 요소와 역할들의 집합을 표현 </li></ul></ul></ul><ul><ul><ul><li>시스템을 구성하는 Pattern 을 표현 - Class 의 행동적이고 구조적인 중요성을 도식 </li></ul></ul></ul><ul><ul><ul><li>쓰임새 (Use Case) </li></ul></ul></ul><ul><ul><ul><li>시스템이 수행하는 순차적 활동들을 기술하며 행위자 (Actor) 에게 결과치를 제공 </li></ul></ul></ul><ul><ul><ul><li>행동 사물을 구조화하기 위하여 사용하며 협력으로 실현 </li></ul></ul></ul><ul><ul><ul><li>활성 클래스 (Active Class) </li></ul></ul></ul><ul><ul><ul><li>객체가 하나 또는 그 이상의 Process 나 Tread 를 갖는 클래스 ( 제어 활동을 포함 ) </li></ul></ul></ul><ul><ul><ul><li>객체들의 행동이 다른 요소들과 함께 동시적으로 발생 </li></ul></ul></ul>Chain of responsibility Chain of responsibility use EventManager suspend ( ) flush ( )
  72. 72. <ul><ul><ul><li>컴포넌트 (Component) </li></ul></ul></ul><ul><ul><ul><li>시스템의 물리적이고 대체 가능한 부분으로 Interface 를 준수하고 구현 </li></ul></ul></ul><ul><ul><ul><li>Class, Interface, Collaboration 등 서로 다른 논리 요소를 물리적으로 Package 화 </li></ul></ul></ul><ul><ul><ul><li>Component 종류 : Application, Document, File, Library, Page, Table, ….. </li></ul></ul></ul><ul><ul><ul><li>노드 (Node) </li></ul></ul></ul><ul><ul><ul><li>실행 시에 존재하는 물리적 요소이며 Computer 자원을 나타내고 약간의 Memory 와 처리 능력을 포함 </li></ul></ul></ul>Server orderform.java
  73. 73. <ul><ul><li>행동 사물 (Behavioral Thing) : UML 모형의 동사형으로써 모형의 동적인 부분이며 시간과 공간에 따른 행동 요소들을 표현 </li></ul></ul><ul><ul><ul><li>교류 (Interaction) </li></ul></ul></ul><ul><ul><ul><li>행위이며 지정된 목적을 완성하기 위하여 특정 문맥에 속한 객체들 사이에 주고 받는 Message 들로 구성 </li></ul></ul></ul><ul><ul><ul><li>상태 머신 (State Machine) </li></ul></ul></ul><ul><ul><ul><li>상태의 순서를 지정하는 행동 </li></ul></ul></ul><ul><ul><ul><li>하나의 객체 혹은 교류에 발생하는 사건 (Event) 에 대한 대기 및 응답의 표현 </li></ul></ul></ul>Waiting Display
  74. 74. <ul><ul><li>그룹 사물 (Grouping Thing) : UML 모형을 조직하는 부분이며 모델을 분해하여 재 구성화 할 수 있는 단위 상자 </li></ul></ul><ul><ul><ul><li>패키지 (Package) </li></ul></ul></ul><ul><ul><ul><li>요소들을 Group 으로 묶는 다목적 Mechanism </li></ul></ul></ul><ul><ul><ul><li>Component 와는 다르며 개발 시에만 존재하는 개념적인 모형 </li></ul></ul></ul><ul><ul><ul><li>종류 : Frame Work, Sub System 표현 </li></ul></ul></ul>Business Rules
  75. 75. <ul><ul><li>주해 사물 (Annotation Thing) : UML 모형을 설명하는 부분이며 Comment 로써 모형 요소를 설명하고 , 명확히 하는 표현 도구 </li></ul></ul><ul><ul><ul><li>노트 (Note) </li></ul></ul></ul><ul><ul><ul><li>하나의 요소 또는 요소들로 구성된 공동체에 첨부되는 제약과 주석을 표현하는 기호 </li></ul></ul></ul>Return copy of self
  76. 76. <ul><li>관계 (Relationships) : 구성 요소 간의 의미 있는 연결 </li></ul><ul><ul><li>의존 관계 (Dependency Relationship) </li></ul></ul><ul><ul><ul><li>두 사물간의 의미적인 관계로써 한쪽 ( 독립 ) 사물의 변화가 다른 ( 종속 ) 사물에 영향을 주는 관계 </li></ul></ul></ul><ul><ul><li>연관 관계 (Association Relationship) </li></ul></ul><ul><ul><ul><li>구조적 관계로써 Link( 객체 간의 연결 ) 의 집합을 나타냄 </li></ul></ul></ul><ul><ul><ul><li>집합 (Aggregation) 연관 관계는 특별한 연관 관계로써 전체 (Whole) 와 부분 (Part) 간의 구조적 관계를 표현 </li></ul></ul></ul>Employer Employee 0 .. 1 *
  77. 77. <ul><ul><li>일반화 관계 (Generalization Relationship) </li></ul></ul><ul><ul><ul><li>특수화 (Specialization)/ 일반화 (Generalization) 관계로써 일반화 된 요소 (Parent) 의 객체를 특수화된 요소 (Child) 의 객체로 치환할 수 있는 관계 (Child 는 Parent 의 구조와 행동을 공유 ) </li></ul></ul></ul><ul><ul><li>실체화 관계 (Realization Relationship) </li></ul></ul><ul><ul><ul><li>분류자 (Classifier) 간의 의미적 관계 </li></ul></ul></ul><ul><ul><ul><li>한 쪽 분류자는 다른 쪽 분류자가 수행하기로 되어 있는 계약 (Contract) 을 명세화 </li></ul></ul></ul>
  78. 78. <ul><li>도해 (Diagramming) : 구성 요소 들의 Graphic 표현 </li></ul><ul><ul><li>클래스도 (Class Diagram) </li></ul></ul><ul><ul><ul><li>Class, Interface, Collaboration 간의 관계를 나타내며 객체 지향 시스템 모형화에서 가장 공통적으로 많이 쓰이는 Diagram </li></ul></ul></ul><ul><ul><ul><li>Class Diagram : 시스템의 정적 (Static) 설계 View </li></ul></ul></ul><ul><ul><ul><li>Active Class Diagram : 시스템의 정적 Process View </li></ul></ul></ul><ul><ul><li>객체도 (Object Diagram) </li></ul></ul><ul><ul><ul><li>객체들 사이의 관계를 표현 </li></ul></ul></ul><ul><ul><ul><li>Class Diagram 에 있는 사물들의 Instance 에 대한 정적 Snap Shut 을 표현 </li></ul></ul></ul><ul><ul><ul><li>실제 사례나 Prototype 사례의 시각에서 도해 </li></ul></ul></ul><ul><ul><li>쓰임새도 (Use Case Diagram) </li></ul></ul><ul><ul><ul><li>Use Case, Actor 간의 관계를 표현 </li></ul></ul></ul><ul><ul><ul><li>시스템 행동을 조직화하고 Modeling </li></ul></ul></ul><ul><ul><ul><li>시스템의 정적 Use Case View </li></ul></ul></ul><ul><ul><li>순차도 (Sequence Diagram), 협력도 (Collaboration Diagram) </li></ul></ul><ul><ul><ul><li>교류도 (Interaction Diagram) 의 한 종류로 객체와 객체 간의 관계 , 그리고 객체 간에 보낼 수 있는 Message 들로 구성 </li></ul></ul></ul><ul><ul><ul><li>순차도 와 협력도 는 동일 구조로써 상호 변형가능하며 순차도 는 Message 의 시간적 순서를 강조하고 협력도 는 객체의 구조적 구성을 강조 </li></ul></ul></ul><ul><ul><ul><li>시스템의 동적 (Dynamic) View </li></ul></ul></ul>
  79. 79. <ul><ul><li>상태도 (State Diagram) </li></ul></ul><ul><ul><ul><li>상태 (State), 전이 (Transition), 사건 (Event), 활동 (Activity) 로 구성 </li></ul></ul></ul><ul><ul><ul><li>사건에 따라 순차적으로 발생하는 객체 행동에 중점을 두고 작성 </li></ul></ul></ul><ul><ul><ul><li>시스템의 동적 View </li></ul></ul></ul><ul><ul><li>활동도 (Activity Diagram) </li></ul></ul><ul><ul><ul><li>특별한 종류의 상태도로써 시스템 내부에 있는 활동간의 흐름을 표현 </li></ul></ul></ul><ul><ul><ul><li>시스템의 기능을 모형화하고 객체간의 제어 흐름 표현에 유용 </li></ul></ul></ul><ul><ul><ul><li>시스템의 동적 View </li></ul></ul></ul><ul><ul><li>컴포넌트도 (Component Diagram) </li></ul></ul><ul><ul><ul><li>Component 간의 구성과 의존 관계를 표현 </li></ul></ul></ul><ul><ul><ul><li>시스템의 정적 구현 View </li></ul></ul></ul><ul><ul><li>배치도 (Deployment Diagram) </li></ul></ul><ul><ul><ul><li>실행 시 처리하는 Node 와 그 Node 에 존재하는 Component 들의 구성을 표현 </li></ul></ul></ul><ul><ul><ul><li>Architecture 의 정적 배치 View </li></ul></ul></ul>
  80. 80. <ul><li>UML 규칙 </li></ul><ul><ul><li>UML 규칙은 자체 일관성이 있으며 관련 Model 들과 조화를 이룸 </li></ul></ul><ul><ul><li>잘못된 모형 </li></ul></ul>이름 (Name) 사물 , 관계 , 도해의 호칭 범위 (Scope) 이름에 특정한 의미를 부여하는 문맥 (Context) 가시성 (Visibility) 이름을 참조하고 사용할 수 있는 방법 무결성 (Integrity) 사물 상호간에 올바르고 일관성 있는 관계를 유지시키는 방법 실행 (Execution) 동적 Model 을 실행하거나 모의 실험 하는 것 생략 (Elided) View 를 단순화 하려고 특정 요소를 감춤 불완전 (Incomplete) 특정 요소를 빼고 작성 불일치 (Inconsistent) 모델의 무결성이 보장되지 않음
  81. 81. <ul><li>UML 공통 Mechanism </li></ul><ul><ul><li>명세서 (Specification) </li></ul></ul><ul><ul><ul><li>UML 의 Graphic 표현에 구문법과 구성 요소의 의미를 포함하여 점진적으로 모델을 구성 </li></ul></ul></ul><ul><ul><li>표기 (Adornment) </li></ul></ul><ul><ul><ul><li>UML 요소의 고유하고 직접적인 Graphic 표기 등 요소의 가장 중요한 관점을 가시적으로 표현 </li></ul></ul></ul>Transaction + execute ( ) + rollback ( ) # priority ( ) - timestamp ( )
  82. 82. <ul><ul><li>공통 분할 (Common Division) </li></ul></ul><ul><ul><ul><li>객체 지향 모델링은 다시 몇 가지로 나누어 표현 가능 </li></ul></ul></ul><ul><ul><ul><li>Class 와 Object 의 분할 </li></ul></ul></ul><ul><ul><ul><li>Interface 와 구현의 분리 </li></ul></ul></ul>Customer name address phone Jan : Customer : Customer Elyse spellingwizard.dll IUnknown ISpelling
  83. 83. <ul><ul><li>확장 메커니즘 (Extensibility Mechanism) </li></ul></ul><ul><ul><ul><li>UML 의 목적인 분석 / 설계 정보를 보다 정확하게 전달하기 위한 표준 언어를 제공 </li></ul></ul></ul><ul><ul><ul><li>하나의 언어로 불가능한 모형은 통제된 방법으로 언어를 확장 </li></ul></ul></ul><ul><ul><ul><li>스테레오 타입 (Stereotypes) </li></ul></ul></ul><ul><ul><ul><li>UML 어휘를 확장하여 새로운 종류의 구성 요소를 생성 </li></ul></ul></ul><ul><ul><ul><li>기존 구성에서 파생되므로 문제 영역은 기존 구성 요소의 고유한 것 </li></ul></ul></ul><ul><ul><ul><li>꼬리표 값 (Tagged Values) </li></ul></ul></ul><ul><ul><ul><li>UML 의 구성 요소가 갖는 Property 를 확장 </li></ul></ul></ul><ul><ul><ul><li>구성 요소의 명세서에 새로운 정보를 추가 생성 가능하도록 </li></ul></ul></ul><ul><ul><ul><li>제약 (Constraints) </li></ul></ul></ul><ul><ul><ul><li>UML 구성 요소가 갖는 의미를 확장하여 새로운 규칙의 추가 및 기존 규칙 변경 </li></ul></ul></ul>EventQueue {version = 3.2 author = YL} add ( ) remove ( ) flush ( ) “ exception” Overflow { ordered} Tagged Value Constraint Stereotype
  84. 84. UML 아키텍쳐 <ul><li>아키텍쳐 결정 사항 </li></ul><ul><ul><li>S/W System 의 구성 </li></ul></ul><ul><ul><li>System 구성 요소들과 요소들 간의 Interface 선택 </li></ul></ul><ul><ul><li>요소들 간의 협력으로 명세화 되는 행동을 결정 </li></ul></ul><ul><ul><li>점진적으로 큰 시스템으로의 구조 요소와 행동 요소를 결합 </li></ul></ul><ul><ul><li>아키텍쳐 양식 ( 정적 / 동적 ) 들과 이들의 Interface, 협력 , 결합을 표현 </li></ul></ul><ul><li>S/W Architecture </li></ul><ul><ul><li>구조와 행동 </li></ul></ul><ul><ul><li>용도 , 기능성 , 성능 , 탄력성 , 재 사용성 , 경제성 </li></ul></ul><ul><ul><li>기술적 제약 및 방법 </li></ul></ul><ul><ul><li>미학적 표현 </li></ul></ul><ul><ul><li>. . . . </li></ul></ul>
  85. 85. <ul><li>S/W 중심 시스템의 Architecture Modeling </li></ul>설계 뷰 (Design View) 구현 뷰 (Implementation View) 프로세스 뷰 (Process View) 배치 뷰 (Deployment View) 쓰임새 뷰 (Use Case View) 시스템 조립 형상관리 시스템 구성 형태 분산 , 인도 , 설치 어휘 기능성 성능 확장성 처리량
  86. 86. 아키텍쳐 종류 내 용 정적 도해 동적 도해 쓰임새 뷰 (Use Case View) 시스템 행동을 설명 최종사용자 , 분석가 , 설계자 , 테스트 담당자에게 제공 되는 뷰 시스템 아키텍쳐를 구체화하는 요인들을 명세화 쓰임새도 교류도 상태도 활동도 설계 뷰 (Design View) 시스템이 최종사용자에게 제공해야 할 서비스를 표현 문제 영역과 해법의 어휘를 형성하고 있는 Class, Interface, Collaboration 으로 구성 클래스도 객체도 교류도 상태도 활동도 프로세스 뷰 (Process View) 시스템의 성능 , 신축성 , 처리 능력을 표현 시스템의 동시성과 동기화 메커니즘을 형성하고 있는 Thread 와 Process 로 구성 클래스도 객체도 활성 클래스도 교류도 상태도 활동도 구현 뷰 (Implementation View) 시스템 배포의 형상관리 표현 물리적인 시스템을 조립하고 배포하는데 사용되는 Component 와 File 들로 구성 컴포넌트도 교류도 상태도 활동도 배치 뷰 (Deployment View) 시스템을 구성하는 물리적 부분의 분산 , 인도 , 설치 표현 H/W 형태를 형성하는 Node 로 구성 배치도 교류도 상태도 활동도
  87. 87. UML 개발 생명주기 <ul><li>개발 Process 고려 사항 </li></ul><ul><ul><li>UML 은 개발 Process 에 독립적 임 </li></ul></ul>프로세스 설 명 쓰임세 중심 System 에 요구되는 행동을 파악 System Architecture 검증 , 확인 및 Test Project 관련자의 의사소통 (Use Case 관련 주요 산출물 활용 ) 아키텍쳐 중심 개발중인 System 의 개념화 , 구축 , 관리 진화 ( 변화 ) 내용을 파악하고 수행 (System Architecture 관련 주요 산출물 활용 ) 반복 / 점진적 프로세스 중심 반복 프로세스는 실행 배포판을 관리 점진적 프로세스는 System Architecture 를 지속적으로 통합하고 개정 배포판을 작성
  88. 88. <ul><li>S/W 개발 생명 주기 단계 </li></ul><ul><ul><li>각 단계는 반복적으로 수행되며 반복은 별개 활동으로써 대내외적으로 배포판을 만드는 기준 계획과 평가 기준을 갖음 </li></ul></ul>단계 설 명 도입 (Inception) 개발의 시작점으로써 대상 요소들을 정의 정련 단계로 진입할 수 있는 충분한 근거 파악 정련 (Elaboration) 제품 Vision 과 Architecture 를 정의 System 의 요구 사항의 명료화 , 우선 순위 결정 , 기준선 설정 및 Test 기준 설정 요구 사항의 기능적 행동과 비 기능적 행동을 명세화 구축 (Construction) S/W 의 작성 및 실행 Architecture 기준선으로부터 전이의 준비 단계 Project 에 대한 요구 사항과 평가 기준의 재 검사 위험 요소들을 제거하기위한 자원의 할당 전이 (Transition) S/W 의 사용자 전달 System 의 지속적인 개선 , 결함 제거 배포판에 새로운 특성 추가
  89. 89. Process Workflow Business Modeling 요구 사항 분석 / 설계 구현 Test 배치 지원 Workflow 형상 및 변경관리 Project 관리 환경 도입 정련 구축 전이 예비 반복 반복 # 1 반복 # 2 반복 # m 반복 # m+1 반복 # n 반복 # n+1 반복 # n+2
  90. 90. 3 장 . UML 기초 <ul><li>핵심 부분 추상화 </li></ul><ul><li>메카니즘 </li></ul><ul><li>컴포넌트 </li></ul>
  91. 91. 핵심 부분 추상화 <ul><li>Web Browser Java Applet “Hello World ! “ 의 예제 </li></ul><ul><ul><li>import java.awt . Graphics ; </li></ul></ul><ul><ul><li>class HelloWorld extends java.applet . Applet </li></ul></ul><ul><ul><li>{ public void paint (Graphics g ) </li></ul></ul><ul><ul><li>{ g ’. drawString (“Hello, World !”, 10 , 10); } } </li></ul></ul>Class Package Parameter 호출 OP. Operation
  92. 92. <ul><ul><li>HelloWorld 의 핵심 부분 추상화 </li></ul></ul><ul><ul><li>HelloWorld 주위의 인접 Class </li></ul></ul>HelloWorld paint ( ) G.drawString (“Hello, World !”, 10, 10) HelloWorld paint ( ) Graphics Applet 의존 관계 일반화 관계 ( 상속 관계 )
  93. 93. <ul><ul><li>HelloWorld 상속 (Inheritance) 계층도 </li></ul></ul>HelloWorld Applet Panel Container Component Object ImageObserver 구현 부분은 없으며 다른 Class 에서 Interface 를 구현할 필요가 있음 Java 에 있는 모든 Class 의 Parent Class
  94. 94. <ul><ul><li>HelloWorld 의 Package 도 </li></ul></ul>Java HelloWorld applet awt lang
  95. 95. 메카니즘 <ul><li>메커니즘 표현 </li></ul><ul><ul><li>Class 의 상속 관계의 표현이 아닌 Operation 의 실행을 표현 </li></ul></ul><ul><ul><li>각 Class 에 속하는 Instance 를 포함해서 다수의 객체들이 순서를 갖고 협력하는 것을 표현 </li></ul></ul><ul><ul><li>Painting Mechanism </li></ul></ul>: Thread : Toolkit : ComponentPeer Target : HelloWorld Run Run CallbackLoop handleExpose paint Instance Operation
  96. 96. 컴포넌트 <ul><li>컴포넌트 표현 </li></ul><ul><ul><li>실행 가능한 Component 를 연결하여 각 메커니즘에 의해 기동 되는 것을 도식 </li></ul></ul><ul><ul><li>개발 환경과 구성 관리 툴을 포함하여 표현 </li></ul></ul><ul><ul><li>HelloWorld Component </li></ul></ul>HelloWorld.class hello.html hello.jpg HelloWorld.java
  97. 97. [2] 기본 구조 모델링 <ul><li>4 장 . 클래스 </li></ul><ul><li>5 장 . 관계 </li></ul><ul><li>6 장 . 공통 메카니즘 </li></ul><ul><li>7 장 . 도해 </li></ul><ul><li>8 장 . 클래스도 </li></ul>
  98. 98. 4 장 . 클래스 (Class) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>시스템 어휘 모델링 </li></ul></ul><ul><ul><li>시스템에서 책임 분산 모델링 </li></ul></ul><ul><ul><li>비 소프트웨어 사물 모델링 </li></ul></ul><ul><ul><li>원시 타입 모델링 </li></ul></ul><ul><li>힌트와 조언 </li></ul>
  99. 99. 시작하기 <ul><li>클래스 란 ? </li></ul><ul><ul><li>어휘의 일부가 되는 사물들을 추상화 하는 것 </li></ul></ul><ul><ul><li>클래스는 가장 중요한 구성 요소이며 동일한 속성 , Operation, Relation 그리고 의미를 공유하는 객체 집합을 표현 </li></ul></ul><ul><ul><li>하나 또는 그 이상의 Interface 를 구현 </li></ul></ul>Shape origin move ( ) resize ( ) display ( ) Class 명 Attribute 명 Operation 명
  100. 100. 용어와 개념 <ul><li>Class 명 </li></ul><ul><ul><li>모든 Class 는 다른 Class 들과 구별되는 유일한 명칭을 갖음 </li></ul></ul><ul><ul><ul><li>단순명 (Simple Name) : Class 자체만을 표현 </li></ul></ul></ul><ul><ul><ul><li>경로명 (Path Name) : Class 가 소속된 Package 명을 포함 </li></ul></ul></ul>Temperature Sensor Customer Wall Business Rules :: FraudAgent Java :: awt :: Rectangle Simple Name Path Name
  101. 101. <ul><li>속성 (Attribute) </li></ul><ul><ul><li>Class 의 Property 에 이를 대표하는 짧은 명사나 명사구로 이름을 붙인 것 </li></ul></ul><ul><ul><ul><li>속성 표현 </li></ul></ul></ul><ul><ul><ul><li>속성과 타입 표현 </li></ul></ul></ul><ul><ul><ul><li>Visibility Name : Type = Default Value </li></ul></ul></ul>+ : Public - : Private # : Protection Attribute Name Signature Attribute Type Attribute Default Value Customer name address phone birthdate Wall height : float width : float thickness : float isLoadBearing : Boolean = false
  102. 102. <ul><li>오퍼레이션 (Operation) </li></ul><ul><ul><li>객체 행동에 영향을 주기 위해 특정 Class 의 객체로부터 요청할 수 있는 Service 를 표현한 것 ( 객체에서 할 수 있는 것이 무엇인가를 추상화 한 것 ) </li></ul></ul><ul><ul><ul><li>오퍼레이션 표현 </li></ul></ul></ul><ul><ul><ul><li>오퍼레이션 (Operation : Class) 과 용법 (Method : Object) 표현 </li></ul></ul></ul><ul><ul><ul><li>속성과 오퍼레이션 구성 </li></ul></ul></ul><ul><ul><ul><li>Visibility Name (Parameter-List) : Return-Type-Expression {Property-String} </li></ul></ul></ul>Rectangle add ( ) grow ( ) move ( ) isEmpty ( ) TemperatureSensor reset ( ) setAlarm (t : Temperature) value ( ) : Temperature FaudeAgent <<constructor>> new ( ) new (p : Policy) <<process>> process (o : Order) . . . <<query>> isSuspect (o : Order) isFraudulent (o : Order) <<helper>> validateOrder (o : Order) Stereotype
  103. 103. <ul><li>책임 (Responsibility) </li></ul><ul><ul><li>Class 가 행해야 하는 의무 또는 계약 </li></ul></ul><ul><ul><li>속성과 오퍼레이션 특성들로 Class 의 책임을 수행 </li></ul></ul><ul><ul><li>CRC(Class Responsibility Collaboration) Card </li></ul></ul>FraudAgent Responsibilities -- determine the risk of a customer order -- handle customer - specific criteria for fraud Event Order Check if items in stocks Determine price Check for valid payment Dispatch to delivery address Order Line “ Customer Class Responsibility Collaboration
  104. 104. 보편적 모델링 기법 <ul><li>시스템 어휘 모델링 </li></ul><ul><ul><li>사용자나 개발자가 문제나 해법을 설명하기 위해 사용하는 사물을 파악 (CRC Card, Use Case 중심 분석 ) </li></ul></ul><ul><ul><li>추상 개념에 대한 책임을 파악 </li></ul></ul><ul><ul><li>Class 의 책임을 수행하기 위하여 필요한 속성과 오퍼레이션 파악 </li></ul></ul><ul><ul><li>모델은 점점 커지게 되며 개념적 또는 의미적으로 연관 있는 것 끼리 Class 집단을 모델링 하여 Package 화 함 </li></ul></ul>Shipment Responsibilities -- maintain the information regarding products shipped against an order -- track the status and location of the shipped product Transaction actions commit ( ) rollBack ( ) wasSuccessful ( ) Order item quantity Product id name price location Warehouse Invoice Customer name address phone birthdate
  105. 105. <ul><li>시스템 책임 분산 모델링 </li></ul><ul><ul><li>어떤 행동을 수행하기위해 긴밀하게 연관 있는 Class 집합을 파악 </li></ul></ul><ul><ul><li>Class 각각의 책임 집합 파악 </li></ul></ul><ul><ul><li>Class 에 너무 많은 책임이 있으면 작게 , 너무 적은 책임이 있으면 여러 개를 모아서 하나의 역할을 수행할 수 있는 합리적 Class 로 재 할당 </li></ul></ul><ul><ul><li>서로 교류하는 것을 파악하여 적절하게 책임을 재 분배 </li></ul></ul>View Responsibilities -- render the model on the screen -- manage movement and resize of the view -- intercept user events Model Responsibilities -- manage the state of the model Controller Responsibilities -- synchronize changes in the model and its views
  106. 106. <ul><li>비 소프트웨어 사물 모델링 </li></ul><ul><ul><li>추상화 대상 사물을 Class 로 Modeling </li></ul></ul><ul><ul><li>이미 정의된 구성 요소들과 구분을 위해 Stereotype 을 사용하고 새로운 의미와 분명한 시각적 암시를 제공 </li></ul></ul><ul><ul><li>Modeling 하려는 대상이 S/W 를 포함하는 H/W 의 일종이면 Node 로 Modeling </li></ul></ul>Robot processOrder ( ) change Order ( ) status ( ) Account Receivable Agent
  107. 107. <ul><li>원시 타입 모델링 </li></ul><ul><ul><li>추상화 대상 사물을 Type 이나 열거 Type 으로 Modeling 하고 Stereotype 과 함께 Class 로 표현 </li></ul></ul><ul><ul><li>이 Type 에 값의 범위를 지정하려면 제약을 사용 </li></ul></ul><<type>> Int {values range from -2**31-1 to +2**31} <<enumeration>> Boolean false true <<enumeration>> Status idle working error
  108. 108. 힌트와 조언 <ul><li>좋은 구조의 Class </li></ul><ul><ul><li>문제 영역이나 해법 영역 어휘에서 추출된 Class 에 대한 명확한 추상화 제공 </li></ul></ul><ul><ul><li>작고도 정의가 잘된 책임 집합을 가지며 그들 모두를 매우 잘 수행 </li></ul></ul><ul><ul><li>추상 개념 명세서와 구현을 분명하게 구분 </li></ul></ul><ul><ul><li>이해하기 좋고 , 단순하며 , 확장 가능하고 , 적응이 용이 </li></ul></ul><ul><li>UML 에서 Class 를 도해 방법 </li></ul><ul><ul><li>문맥상에서 추상화를 이해하기 위해 꼭 필요한 Property 만을 표현 </li></ul></ul><ul><ul><li>속성이나 오퍼레이션 목록이 많으면 범주에 따라 Group 으로 분류하여 조직화 </li></ul></ul><ul><ul><li>관련된 Class 들은 같은 Class 도에 표현 </li></ul></ul>
  109. 109. 5 장 . 관계 (Relationship) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>단순 의존 모델링 </li></ul></ul><ul><ul><li>단일 상속 모델링 </li></ul></ul><ul><ul><li>구조적 관계 모델링 </li></ul></ul><ul><li>힌트와 조언 </li></ul>
  110. 110. 시작하기 <ul><li>관계 란 ? </li></ul><ul><ul><li>UML 에서 사물 (Thing) 들이 상호 논리적 / 물리적으로 연결되는 것 </li></ul></ul><ul><ul><li>관계 종류 : 의존 관계 , 일반화 관계 , 연관 관계 </li></ul></ul><ul><ul><ul><li>특정 프로그래밍 언어와 무관하게 관계를 도해하는 것을 가능하게 하며 관계에서 중요한 부분을 강조할 수 있도록 함 </li></ul></ul></ul><ul><ul><ul><li>관계 이름 , 연결 대상 , 관계 Property </li></ul></ul></ul>Window open ( ) close ( ) move ( ) display ( ) handleEvent ( ) Event ConsoleWindow DialogBox Control 연관 일반화 의존
  111. 111. 용어와 개념 <ul><li>의존 (Dependency) </li></ul><ul><ul><li>사용 관계로써 한 사물의 명세서가 바뀌면 이를 사용하는 다른 사물에게 영향을 미침 </li></ul></ul><ul><ul><li>Class 문맥에서 한 Class 가 다른 Class 를 Operation 용법에 Parameter 로 사용하는 경우에 주로 활용 </li></ul></ul><ul><ul><li>사용중인 Class 가 바뀌면 상대 Class 의 Operation 이 함께 영향을 받음 </li></ul></ul>Transaction name playOn (c:Channel) start ( ) stop ( ) reset ( ) Channel Dependency Relationship
  112. 112. <ul><li>일반화 (Generalization) </li></ul><ul><ul><li>“ is-a kind-of ” 관계 </li></ul></ul><ul><ul><li>일반화된 사물 (Super type, Parent type) 과 보다 특수화된 사물 (Sub type, Child type) 들 사이의 관계를 표현 </li></ul></ul><ul><ul><li>Child 객체는 Parent 객체가 사용되는 어느 곳에서나 사용될 수 있음 </li></ul></ul>Shape origin move ( ) resize ( ) display ( ) Square Rectangle corner : Point Circle radius : Float Polygon points : List display ( ) Leaf Class Base Class Generalized Relationship
  113. 113. <ul><li>연관 (Association) </li></ul><ul><ul><li>“ has-a ” 관계 </li></ul></ul><ul><ul><li>구조적인 관계로써 특정 사물 객체가 다른 사물 객체와 관계가 있음을 표현 </li></ul></ul><ul><ul><li>두 Class 가 서로 연결되어 연관이 있다면 한쪽 객체에서 다른 객체로 옮겨 갈 수 있으며 그 반대도 가능 ( 쌍방 연관 ) </li></ul></ul><ul><ul><li>역할 (Role name) 표현 </li></ul></ul>Company Person employee employer 역할명 (role name) Company Person Works for Association Relationship name name direction
  114. 114. <ul><ul><li>다중성 (Multiplicity) 표현 </li></ul></ul><ul><ul><li>집합 연관 (Aggregation) 표현 : “ part-of ” 관계 </li></ul></ul><ul><ul><ul><li>독자 운영 가능 </li></ul></ul></ul><ul><ul><li>합성 연관 (Composition) 표현 </li></ul></ul><ul><ul><ul><li>단독 사용 불가하며 반드시 Super Class(Object) 와 함께 사용 </li></ul></ul></ul>Company Person employee employer 다중성 (Multiplicity) 1 .. * * Company Department Aggregation 1 * Employee Body Composition 1 1
  115. 115. 보편적 모델링 기법 <ul><li>단순 의존 모델링 </li></ul><ul><ul><li>특정 Class 가 다른 Class 를 Operation 에서 Parameter 로만 사용하는 관계 </li></ul></ul><ul><ul><li>Operation 에서 Parameter 로 상대 Class 를 사용하려는 Class 쪽에서 의존 관계를 표현 </li></ul></ul>CourseSchedule add (c : Course) remove (c : Course) Course Iterator
  116. 116. <ul><li>단일 상속 모델링 </li></ul><ul><ul><li>구조적 , 행동적 특성을 파악하여 일반화 Class 와 특수화 Class 로 구분하여 작성 </li></ul></ul><ul><ul><li>Class 집합에서 둘 이상 다수의 Class 에 공통으로 존재하는 책임 , 속성 , Operation 을 파악 </li></ul></ul><ul><ul><li>파악된 책임 , 속성 , Operation 을 일반화 Class 로 작성 </li></ul></ul><ul><ul><li>특수화 Class 는 일반화 Class 로부터 상속되도록 관계를 설정 </li></ul></ul>Security presentValue ( ) history ( ) SmallCapStock CashAccount interestRate presentValue ( ) Stock presentValue ( ) Bond presentValue ( ) Property assesment presentValue ( ) LargeCapStock
  117. 117. <ul><li>구조적 관계 모델링 </li></ul><ul><ul><li>의존 ( 사용 관계 )/ 일반화 ( 부분 관계 ) 관계와 같이 일방적인 관계가 아닌 Class 간에 대등한 관계 </li></ul></ul><ul><ul><li>한 쌍의 Class 에 대하여 한 객체들로부터 다른 객체로의 왕래가 필요하면 두 Class 사이에 연관 관계를 지정 </li></ul></ul><ul><ul><li>한 쌍의 Class 에 대하여 한 Class 객체가 다른 Class 객체와 Operation Parameter 이외의 방법으로 교류하면 관계 설정 ( 행동 중심적 관점 ) </li></ul></ul><ul><ul><li>각 연관에 대해 다중성 , 역할 명을 표현 </li></ul></ul><ul><ul><li>한쪽 Class 가 구조적 , 조직적으로 전체가 되고 다른 쪽이 부분 관계와 같이 판단되면 집합 연관으로 표현 </li></ul></ul>Department School Student Course Instructor member 1 .. * * has 1 .. * 1 1 .. * 1 .. * 1 .. * 1 .. * * * 1 .. * 0 .. 1 0 .. 1 attends teaches assignedTo chairperson *
  118. 118. 힌트와 조언 <ul><li>UML 에서 관계를 Modeling 하려면 </li></ul><ul><ul><li>Modeling 대상 관계가 구조적이 아닌 경우에만 의존 사용 </li></ul></ul><ul><ul><li>일반화는 “ is-a-kind-of” 관계일 때만 사용하며 다중 상속은 집합 연관으로 표현 </li></ul></ul><ul><ul><li>순환하는 일반화 관계는 표현하지 않도록 유의 </li></ul></ul><ul><ul><li>일반화 관계를 전체적으로 균형 있게 유지 ( 상속 계층이 너무 깊거나 , 넓지 않도록 ) </li></ul></ul><ul><ul><li>연관은 객체간에 구조적 관계가 있을 때 사용 </li></ul></ul><ul><li>UML 의 관계 도해 </li></ul><ul><ul><li>직사각형을 이루는 직선이나 사선의 사용 금지 </li></ul></ul><ul><ul><li>가능하면 관계를 표현하는 선이 서로 교차하지 않도록 </li></ul></ul><ul><ul><li>사물의 특정한 모임을 이해하기 쉬울 정도의 필요한 만큼의 관계만 표현 </li></ul></ul>
  119. 119. 6 장 . 공통 메카니즘 (Common Mechanism) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>주석 모델링 </li></ul></ul><ul><ul><li>새로운 구성 요소 모델링 </li></ul></ul><ul><ul><li>새로운 프로퍼티 모델링 </li></ul></ul><ul><ul><li>새로운 의미 모델링 </li></ul></ul><ul><li>힌트와 조언 </li></ul>
  120. 120. 시작하기 <ul><li>UML Mechanism : 분석 / 설계 내용을 쉽게 이해하도록 산출물 작성 </li></ul><ul><ul><li>명세 (Specification) </li></ul></ul><ul><ul><li>장식 (Adornment) </li></ul></ul><ul><ul><li>공통 분할 (Common Division) </li></ul></ul><ul><ul><li>확장 (Extensibility) </li></ul></ul><ul><li>UML 확장 Mechanism : 새로운 구성 요소 추가 , 새로운 Property, 의미 지정 </li></ul><ul><ul><li>스테레오 타입 (Stereotype) </li></ul></ul><ul><ul><li>꼬리표 값 (Tagged Value) </li></ul></ul><ul><ul><li>제약 (Constraint) </li></ul></ul><ul><li>공통 Mechanism 사용 이유 </li></ul><ul><ul><li>UML 은 다양한 시스템의 산출물을 제공하지만 약간의 변형이나 확장으로 보다 나은 의사 소통이 가능 </li></ul></ul>Consider the use of the broker design patter here. egb 10/22/99 note << subsystem>> Billing {version = 3.2} Stereotype Tagged Value Server Remote Client {>56 Kbps} Constraint
  121. 121. 용어와 개념 <ul><li>장식 (Adornment) </li></ul><ul><ul><li>Note </li></ul></ul><ul><ul><ul><li>주석을 표현하는 Note 는 의미상 아무런 영향을 미치지 못 함 ( 이해를 돕는 단순 설명 ) </li></ul></ul></ul><ul><ul><li>다른 장식 </li></ul></ul>이름 있는 칸 Client bill.exe report.exe contacts.exe Transaction addAction ( ) removeAction ( ) perform ( ) rollBack ( ) exceptions emptyTransaction noSuchAction resourceLocked 이름 없는 칸 Publish this component in the project responsibility after the next design review. 단순 Text See encrypt.doc for details about this algorithm See http://www.gamelan.com for an example of this applet 삽입 URL 문서의 연결
  122. 122. <ul><li>스테레오 타입 (Stereotype) </li></ul><ul><ul><li>UML 에서 제공하는 구조 사물 , 행동 사물 , 그룹 사물 , 주해 사물을 이용한 표현에서 새로운 원시 구성 요소처럼 나타내고 할 때 사용 </li></ul></ul><< meteclass >> ModelElement << exception >> Underflow ! 이름 있는 Stereotype Icon 과 이름 있는 Stereotype HumiditySensor Icon 으로 표시한 Stereotype 요소
  123. 123. <ul><li>꼬리표 값 (Tagged Value) </li></ul><ul><ul><li>UML 산출물에 새로운 Property 추가할 때 사용 </li></ul></ul>Server {processors = 3} 꼬리표 값 << library >> flower.dll {serverOnly}
  124. 124. <ul><li>제약 (Constraint) </li></ul><ul><ul><li>제약을 이용하여 새로운 의미를 추가하거나 기존 규칙을 수정 </li></ul></ul><ul><ul><li>Model 이 잘 구성되도록 하기 위하여 반드시 지켜야 할 조건들을 지정 </li></ul></ul>Person gender : {female, male} Portfolio BankAccount Corporation { secure} 0 .. 1 단순 제약 { or} 여러 요소 간의 제약 0 .. 1 husband wife OCL 로 나타낸 정형적 제약 { self.wife.gender = female and self.husband.gender = male}
  125. 125. 보편적 모델링 기법 <ul><li>주석 (Comment) Modeling </li></ul><ul><ul><li>주석을 Model 에 둠으로써 개발 과정에서 만들어진 각종 분산 산출물 ( 관찰 기록 , 검토 의견 , 설명 , . . . ) 에 대한 공통 저장소 역할 </li></ul></ul><ul><ul><li>주석 모델링 방법 </li></ul></ul><ul><ul><ul><li>문장으로 작성하여 Note 에 담고 관련 요소를 근처에 배치하여 의존 관계를 표현 </li></ul></ul></ul><ul><ul><ul><li>해당 문맥의 정보에 관한 의사 소통의 필요가 있는 경우에만 표현 </li></ul></ul></ul><ul><ul><ul><li>주석이 길거나 단순 문장 이상인 경우 별도 문서로 작성하거나 내장 시켜 모델에 표현 </li></ul></ul></ul><ul><ul><ul><li>Model 이 진화 할 수록 중요한 결정 사항을 기록하되 추론이 불가능한 주석만 남김 </li></ul></ul></ul>Security presentValue ( ) history ( ) Mary : add two intermediate abstract classes to distinguish read/intangible securities walkthrough on 10/22/99 << requirement >> Shall conform to corporate framework for transaction logging, in compliance with federal law. CashAccount interestRate presentValue ( ) Stock presentValue ( ) Bond presentValue ( ) Property assesment presentValue ( ) See policy 8-5-96.doc for details about these algorithm
  126. 126. <ul><li>새로운 구성 요소 Modeling </li></ul><ul><ul><li>UML 구성 요소 (Class, Interface, Collaboration, Component, Node, Relation, ..) 들로 불충분한 표현의 어휘 확장 (Stereotype 사용 ) </li></ul></ul><ul><ul><li>새로운 구성 요소 모델링 방법 </li></ul></ul><ul><ul><ul><li>기본 구성 요소로 표현 불가능을 파악 </li></ul></ul></ul><ul><ul><ul><li>사용할 구성 요소가 없을 경우 스테레오 타입으로 표현 </li></ul></ul></ul><ul><ul><ul><li>표현하려는 기본 요소에 정의된 이상의 공통 Property 와 의미에 대하여 꼬리표 값과 제약들의 집합으로 정의 </li></ul></ul></ul><ul><ul><ul><li>Stereotype 요소들이 명백한 시각적 암시를 표현하도록 하기 위하여 새로운 Icon 정의 </li></ul></ul></ul>Register Team Registration Pay fees Get event materials Return event materials : Coach : Team [unregistered} : Team [registered} : Team [finished} Practice Compete Get event results Competition
  127. 127. <ul><li>새로운 Property Modeling </li></ul><ul><ul><li>포괄적인 Property 보다 상세하게 새로운 구성 요소의 Property 를 꼬리표 값으로 사용 </li></ul></ul><ul><ul><li>새로운 Property 모델링 방법 </li></ul></ul><ul><ul><ul><li>기본 Property 로 표현 불가능을 파악 </li></ul></ul></ul><ul><ul><ul><li>사용할 Property 가 없을 경우 새로운 Property 를 각 요소나 스테레오 타입으로 추가 - 일반적인 원칙이 적용되며 요소에 정의된 꼬리표 값은 하위 Class 에도 적용 됨 </li></ul></ul></ul><< subsystem >> FieldAccess {version = 2.5 status = checkedln} << subsystem >> Billing {version = 3.2 status = checkedout} << subsystem >> WorldCurrency {version = 7.5 status = checkedln} << subsystem >> AccountPayable {version = 3.2.1 status = checkedln}
  128. 128. <ul><li>새로운 의미 Modeling </li></ul><ul><ul><li>UML 의 목적은 이해를 쉽게 할 수 있으며 의사 소통을 원할 하도록 하는 것이므로 새로운 부분을 표현해야 할 필요가 있을 경우에는 제약을 사용 </li></ul></ul><ul><ul><li>새로운 의미 모델링 방법 </li></ul></ul><ul><ul><ul><li>기본적인 표현으로 표현 불가능하다는 것을 확인 </li></ul></ul></ul><ul><ul><ul><li>사용할 표현 방법이 없을 경우 의미를 제약으로 작성하고 관련 있는 요소 들을 가까이 둠 </li></ul></ul></ul><ul><ul><ul><li>의미를 보다 정확히 , 공식적으로 표현하려면 새로운 의미를 OCL(Object Constraint Language) 을 이용하여 기술 </li></ul></ul></ul>member 1 .. * Person Department 1 * * manager { subset}
  129. 129. 힌트와 조언 <ul><li>Model 에 Note 를 사용하여 장식하려면 </li></ul><ul><ul><li>기존 UML 특성으로는 표현할 수 없을 때 요구 사항 , 관찰 기록 , 검토 의견 , 설명 등을 표현 </li></ul></ul><ul><ul><li>Note 는 단지 참조로 사용하며 진행중인 일의 진척 사항을 추적하는데 사용 </li></ul></ul><ul><li>Note 를 도해 할 때 </li></ul><ul><ul><li>장문의 주석은 전체 주석을 담고 있는 문서를 연결하거나 내장하는 장소로 Note 를 활용 </li></ul></ul><ul><li>Stereotype, Tagged Value, Constraint 를 사용하여 Model 을 확장하려면 </li></ul><ul><ul><li>몇 개의 표준화 만을 설정하여 Project 에 활용 </li></ul></ul><ul><ul><li>짧고 , 의미 있는 명칭 사용 </li></ul></ul><ul><ul><li>정확성이 중요하게 요구되는 부분이면 OCL 을 사용하여 제약 표현식으로 나타내고 그렇지 않으면 자유로운 형상의 문장 사용 </li></ul></ul><ul><li>Stereotype, Tagged Value, Constraint 를 도해하려면 </li></ul><ul><ul><li>Graphic Stereotype 은 자제 </li></ul></ul><ul><ul><li>Graphic Stereotype 은 단순한 표현 , 색 또는 그림자를 활용하고 복잡한 것은 Icon 을 사용 </li></ul></ul>
  130. 130. 7 장 . 도해 (Diagrams) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>시스템의 다양한 뷰 모델링 </li></ul></ul><ul><ul><li>다양한 추상화 계층 모델링 </li></ul></ul><ul><ul><li>복잡한 뷰 모델링 </li></ul></ul><ul><li>힌트와 조언 </li></ul>
  131. 131. 시작하기 <ul><li>도해 (Diagram) </li></ul><ul><ul><li>구성 요소들의 집합 ( 사물들과 그 관계 ) 을 Graphic 으로 표현한 것 </li></ul></ul><ul><ul><li>S/W 분야의 Architecture 를 가시화 , 명세화 , 구축 , 문서화하는 뷰 </li></ul></ul><ul><ul><ul><li>쓰임새 뷰 , 설계 뷰 , 프로세스 뷰 , 구현 뷰 , 배치 뷰 </li></ul></ul></ul><ul><ul><li>뷰 모델링 </li></ul></ul><ul><ul><ul><li>구조적 모델링 : 정적인 사물 모델링 </li></ul></ul></ul><ul><ul><ul><li>행동적 모델링 : 동적인 사물 모델링 </li></ul></ul></ul><ul><ul><li>UML 도해 방식 </li></ul></ul><ul><ul><ul><li>순 공학 (Forward Engineering) 방법 : 모델을 먼저 작성하고 실행 시스템을 구현 </li></ul></ul></ul><ul><ul><ul><li>역 공학 (Reverse Engineering) 방법 : 실행 시스템으로부터 모델을 재 구축 </li></ul></ul></ul>
  132. 132. 용어와 개념 <ul><li>System 과 Sub System </li></ul><ul><ul><li>특정 목적을 수행하기 위하여 구성된 Sub System 들로 이루어지며 다양한 시각에서 바라본 Model 들의 집합으로 표현 </li></ul></ul><ul><ul><li>구성 요소들의 모임으로서 요소의 일부는 다른 요소들에게 제공할 행동에 대한 명세를 구성 </li></ul></ul><ul><ul><li>Architecture 관점에서 View 는 System Model 에 대한 조직과 구조를 투영한 것으로 도해는 요소들의 집합을 Graphic 으로 표현한 것 </li></ul></ul><ul><li>System 의 정적인 부분 도해 Model </li></ul><ul><ul><li>클래스도 (Class Diagram) </li></ul></ul><ul><ul><li>객체도 (Object Diagram) </li></ul></ul><ul><ul><li>컴포넌트도 (Component Diagram) </li></ul></ul><ul><ul><li>배치도 (Deployment Diagram) </li></ul></ul><ul><li>System 의 동적인 부분 도해 Model </li></ul><ul><ul><li>쓰임새도 (Use Case Diagram) </li></ul></ul><ul><ul><li>순차도 (Sequence Diagram) </li></ul></ul><ul><ul><li>협력도 (Collaboration Diagram) </li></ul></ul><ul><ul><li>상태도 (State chart Diagram) </li></ul></ul><ul><ul><li>활동도 (Activity Diagram) </li></ul></ul>
  133. 133. 보편적 모델링 기법 <ul><li>System 의 다양한 View Modeling </li></ul><ul><ul><li>System 의 Architecture 를 표현하고 Project 의 기술적인 위험을 표현하기에 가장 좋은 View 를 결정 </li></ul></ul><ul><ul><li>각 View 의 필수적인 상세를 파악하기위해 만들어야 할 산출물을 결정 </li></ul></ul><ul><ul><li>Project 계획 시 각 View 에 대해 어떤 도해를 어느 정도 형식적 제어하에 둘 것인가를 결정 </li></ul></ul><ul><ul><li>몇 가지 도해는 중도에 폐기 할 수 있다는 여유를 갖고 모형화 </li></ul></ul>단순 일체형의 Application Modeling 복잡한 분산 System Modeling 쓰임새 뷰 쓰임새도 설계 뷰 클래스도 , 교류도 프로세스 뷰 불 필요 구현 뷰 불 필요 배치 뷰 불 필요 쓰임새 뷰 쓰임새도 , 활동도 설계 뷰 클래스도 , 교류도 , 상태도 프로세스 뷰 클래스도 , 교류도 구현 뷰 컴포넌트도 배치 뷰 배치도
  134. 134. <ul><li>다양한 추상화 Hierarchical Modeling </li></ul><ul><ul><li>추상화 계층을 달리하여 시스템을 표현할 필요가 있을 때 활용 </li></ul></ul><ul><ul><li>추상화 계층 종류 </li></ul></ul><ul><ul><ul><li>같은 Model 에 대하여 상세한 정도를 달리하는 방법 </li></ul></ul></ul><ul><ul><ul><li>초기부터 추상화 계층을 달리하여 Model 을 작성 그러나 한 Model 에서 다른 Model 로 추적이 가능하도록 하는 방법 </li></ul></ul></ul><ul><ul><li>추상화 계층 Modeling 방법 </li></ul></ul><ul><ul><ul><li>요구 사항을 고려하면서 제시된 모델로 시작 </li></ul></ul></ul><ul><ul><ul><li>모형을 필요로 하는 사용자 ( 최종 사용자 , 분석 / 설계자 ) 수준에 맞는 계층을 설정 </li></ul></ul></ul><ul><ul><ul><li>추상화 수준 결정에 따라 각 사물들을 모델에 표현 </li></ul></ul></ul><ul><ul><ul><ul><li>구성 요소와 관계 : 도해 목적과 요구에 부합되지 않는 것은 Hide </li></ul></ul></ul></ul><ul><ul><ul><ul><li>장식 : 도해를 이해하는데 필수적 구성 요소와 관계에 관한 장식만 표현 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>흐름 : 행동적 도해의 경우 의도를 이해하는데 필수적인 Message 나 Transit 만 확장 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>스테레오 타입 : 속성이나 Operation 과 같은 것에 대해 도해의 의도를 이해하는데 필수적인 스테레오 타입 항목만 표현 </li></ul></ul></ul></ul>
  135. 135. <ul><ul><li>다양한 추상화 계층 Modeling 방법 </li></ul></ul><ul><ul><ul><li>요구 사항을 고려하여 각자가 원하는 추상화 계층을 결정하고 각 계층에 맞게 별도 Model 작성 </li></ul></ul></ul><ul><ul><ul><li>상위 계층의 추상화 Model 에는 단순한 추상화 개념들로 구성 , 하위 계층 추상화 Model 에는 상세한 추상화 개념 포함 </li></ul></ul></ul><ul><ul><ul><li>다섯 가지 View 준수 시 4 가지 고려 사항 </li></ul></ul></ul><ul><ul><ul><ul><li>Use Case 와 구현 : 쓰임새 모델의 쓰임새는 설계 모델의 협력으로 추적 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Collaboration 과 구현 : 협력을 수행하기 위해 함께 협력하는 Class 의 모임으로 추적 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Component 와 설계 : 구현 모델의 Component 들은 설계 모델의 요소 들로 추적 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Node 와 Component : 배치 모델의 Node 들은 구현 모델의 Component 들로 추적 </li></ul></ul></ul></ul><ul><ul><li>상위 추상화 계층도의 교류 </li></ul></ul>: OrderTaker : OrdeFulfillment submitOrder placeOrder acknowledgeOrder
  136. 136. <ul><ul><li>하위 추상화 계층의 교류도 </li></ul></ul>: OrderTaker : CreditCardAgent : OrderFulfillment : BillingAgent acknowledgeOrder processCard submitOrder placeOrder triggerBill See Credit Failure for a variation of this scenario
  137. 137. <ul><li>복잡한 View Modeling </li></ul><ul><ul><li>대단히 크고 복잡한 도해를 작성할 때 공통 Pattern 을 파악하여 상위 계층의 협력으로 도해 </li></ul></ul><ul><ul><li>복잡한 View Modeling 방법 </li></ul></ul><ul><ul><ul><li>도해의 일부를 감추고 다른 부분을 상세하게 드러내는 방식으로 상위 추상화 계층에서 이러한 정보를 표현할 방법이 없다는 것을 확인 </li></ul></ul></ul><ul><ul><ul><li>충분히 감추어 표현하였는데도 도해가 복잡하다면 요소들을 Package 로 묶거나 상위 계층의 협력으로 묶는 것을 고려 </li></ul></ul></ul><ul><ul><ul><li>도해가 복잡하다면 Note 나 색깔을 이용하여 강조 부분을 부각 시킴 </li></ul></ul></ul><ul><ul><ul><li>전체 도해를 확인하며 공동 Pattern 을 연구 </li></ul></ul></ul>
  138. 138. 힌트와 조언 <ul><li>도해를 만들 때 </li></ul><ul><ul><li>도해의 목적은 시스템의 가시화 , 명세화 , 구축 , 문서화 임 </li></ul></ul><ul><ul><li>도해의 전부를 유지하는 것이 아니라 시스템이 만들어질 떄 활용되고 용도를 마친 도해는 폐기 </li></ul></ul><ul><ul><li>불 필요하거나 중복된 도해는 작성하지 않음 </li></ul></ul><ul><ul><li>각 도해가 의도하는 문제를 다루기에 충분하도록 상세하게 표현 </li></ul></ul><ul><ul><li>원하는 것이 상위의 추상화 계층이 아니라면 도해를 최소한으로 만들지 말아야 </li></ul></ul><ul><ul><li>구조적 도해와 행동적 도해가 균형을 유지하도록 </li></ul></ul><ul><ul><li>너무 크거나 적지 않은 범위에서 표현 </li></ul></ul><ul><ul><li>각 도해에 의미 있는 명칭을 붙이고 의도를 명확하게 표현 </li></ul></ul><ul><ul><li>형식에 집착하지 않고 작성 </li></ul></ul><ul><li>구조가 좋은 도해 </li></ul><ul><ul><li>시스템에서 하나의 View 를 전달하는데 초점을 맞춤 </li></ul></ul><ul><ul><li>관점을 이해하는데 필수적인 요소만 표현 </li></ul></ul><ul><ul><li>추상적 계층에 맞는 상세한 정보를 제공 </li></ul></ul><ul><ul><li>중요한 의미를 사용자에게 정확히 전달될 정도로 복잡하게 구현 </li></ul></ul>
  139. 139. 8 장 . 클래스도 (Class Diagram) <ul><li>시작하기 </li></ul><ul><li>용어와 개념 </li></ul><ul><li>보편적 모델링 기법 </li></ul><ul><ul><li>단순 협력 모델링 </li></ul></ul><ul><ul><li>논리 데이타베이스 스키마 모델링 </li></ul></ul><ul><ul><li>순 공학과 역 공학 </li></ul></ul><ul><li>힌트와 조언 </li></ul>
  140. 140. 시작하기 <ul><li>Class Diagram </li></ul><ul><ul><li>Class, Interface, collaboration, Relation 을 이용하여 시스템의 정적인 관점들을 가시화하고 구축을 위한 자세한 내용을 명세화 </li></ul></ul><ul><ul><li>System 어휘와 협력 , Schema 를 Modeling 하는 것이 대부분 </li></ul></ul>Company Person name : Name employeeID : Integer title : String getPhoto (p : Photo) getSoundByte ( ) getContactInformation ( ) getPersonalRecords ( ) Department name : Name Office address : String voice : Number Headquaters ContactInformation address : String PersonalRecord taxID employmentHistory salary {subset} 집합 연관 클래스 1 * 1..* * * 1..* 0..1 1..* 1 * * 클래스 명 member manager 역할 제약 속성 Operation 일반화 의존 연관 Location ISecureInformation Interface 다중성
  141. 141. 용어와 개념 <ul><li>공통 Property </li></ul><ul><ul><li>Class Diagram 은 특별 도해의 하나이지만 다른 모든 Diagram 들과 공통적인 Property 가 존재 </li></ul></ul><ul><li>내용 </li></ul><ul><ul><li>Class </li></ul></ul><ul><ul><li>Interface </li></ul></ul><ul><ul><li>Collaboration </li></ul></ul><ul><ul><li>Relationship(Dependency, Generalization, Association) </li></ul></ul><ul><li>공통 사용 </li></ul><ul><ul><li>Class Diagram 의 정적인 설계 View 작성 방식 </li></ul></ul><ul><ul><ul><li>System 어휘 Modeling : 시스템화 대상의 추상 개념을 도출하여 추상 개념들 사이의 관계를 명세화 </li></ul></ul></ul><ul><ul><ul><li>단순 협력 Modeling : 서로 협동적인 행동을 제공하기 위하여 함께 작용하는 Class, Interface, 다른 요소들과의 관계를 가시화하고 명세화 </li></ul></ul></ul><ul><ul><ul><li>논리 Database Schema Modeling : 시스템 구현 Database Schema 를 Modeling 하기위한 설계의 청사진을 제시 </li></ul></ul></ul>
  142. 142. 보편적 모델링 기법 <ul><li>단순 협력 모델링 </li></ul><ul><ul><li>존재하는 Class 들 간의 협력 관계를 명세화 </li></ul></ul><ul><ul><li>협력 Modeling 방법 </li></ul></ul><ul><ul><ul><li>Modeling 대상 Mechanism(System 일부의 기능 / 행동 ) 을 파악 </li></ul></ul></ul><ul><ul><ul><li>각 Mechanism 에 협력을 하는 Class, Interface 등 다른 협력 관계 파악 </li></ul></ul></ul><ul><ul><ul><li>사물을 검토하기 위하여 Scenario 를 활용 </li></ul></ul></ul><ul><ul><ul><li>필요 요소들을 채움 : 균형 잡힌 책임 할당 , 구체적인 속성 , Operation 추가 </li></ul></ul></ul>* CollisionSensor PathAgent Responsibilities -- seek path -- avoid obstacles Motor move (d:Direction; s:Speed) stop ( ) resetCounter ( ) Status status ( ) Integer distance ( ) 1 1 Driver 1 MainMotor SteetingMotor 1 1
  143. 143. <ul><li>논리 Database Schema Modeling </li></ul><ul><ul><li>Modeling 의 결과로 생성해야 할 Database 구조를 설계 </li></ul></ul><ul><ul><li>자료 표현에만 초점을 두는 ERD 에 비교하여 행동 모형을 포함하는 상위 집합 </li></ul></ul><ul><ul><li>물리 Database 에 있어서 논리 Operation 은 Trigger 나 Stored Procedure 로 구현 </li></ul></ul><ul><ul><li>Schema Modeling 방법 </li></ul></ul><ul><ul><ul><li>사용된 Class 중에서 단순 Application 으로 끝나는 것이 아닌 것을 파악 </li></ul></ul></ul><ul><ul><ul><li>파악된 대상을 포함하여 Class Diagram 을 작성하고 꼬리표를 붙여 표시 </li></ul></ul></ul><ul><ul><ul><li>구조적 상세 내용 ( 속성 ) 을 확정하며 연관 관계 파악 </li></ul></ul></ul><ul><ul><ul><li>물리적 Database 설계를 복잡하게 하는 공통 Pattern 파악 ( 순화 연관 , 다수 연관 … ) </li></ul></ul></ul><ul><ul><ul><li>무결성 유지를 위한 Operation 을 확장하여 Class 의 행동으로 고려 </li></ul></ul></ul><ul><ul><ul><li>가능하면 CASE Tool 을 이용하여 논리 설계를 물리 설계로 변환 </li></ul></ul></ul>
  144. 144. School {persistent} name : Name address : String phone : Number addStudent ( ) removeStudent ( ) getStudent ( ) getAllStudent ( ) addDepartment ( ) removeDepartment ( ) getDepartment ( ) getAllDepartment ( ) Department {persistence} name : Name addInstructor ( ) removeInstructor ( ) getInstructor ( ) getAllInstructor ( ) Student {persistence} name : Name studentID : Number Course {persistence} name : Name courseID : Number Instructor {persistence} name : Name 1 1..* Has 1..* 1..* 1..* 1..* 1..* 1..* * Member * * Attends * 0 .. 1 Teaches AssignedTo 0 .. 1 Chairperson
  145. 145. <ul><li>순 공학과 역 공학 </li></ul><ul><ul><li>순 공학 (Forward Engineering) </li></ul></ul><ul><ul><ul><li>Model 을 대응 언어에 대응시켜 Code 로 옮기는 절차 </li></ul></ul></ul><ul><ul><li>순 공학 방법 </li></ul></ul><ul><ul><ul><li>구현 언어나 선택 언어에 대응 시키는 규칙 파악 </li></ul></ul></ul><ul><ul><ul><li>선택 언어의 의미에 따라 UML 특성들을 제한적으로 사용 </li></ul></ul></ul><ul><ul><ul><li>꼬리표 값을 사용하여 구현 언어를 지정 </li></ul></ul></ul><ul><ul><ul><li>도구의 활용 </li></ul></ul></ul>Public abstract class EventHandler { EventHandler successor ; private Integer currentEventID ; private String source; EventHandler ( ) { } public void handleRequest ( ) { } } 순 공학 구현 Code Client {Java} EventHandler {Java} currentEventID : Integer source : String handleRequest ( ) : void successor GUIEventHandler {Java}
  146. 146. <ul><ul><li>역 공학 (Reverse

×