4. 알프레드 베르나르드 노벨 (Alfred Bernhard Novel) 1833. 10. 21 스웨덴 스톡홀름 ~1896. 12. 10 이탈리아 산레모 . 스웨덴의 화학자 · 공학자 · 실업가 . 다이너마이트 및 그보다 더 강력한 폭발물들을 발명했으며 노벨상을 제정했다 . 외가 쪽의 조상으로는 림프관에 대한 논문 (1653 경 ) 으로 유명한 스웨덴 자연학자 올로프 루드베크가 있다 . 그는 아버지 이마누엘 노벨에게서 공학의 기초를 배웠으며 아버지를 닮아 발명에 재주가 있었다 . 1842 년 식구 모두 스톡홀름을 떠나 아버지가 있던 상트페테르부르크로 이사했다 . 주로 가정교사에게서 교육을 받은 노벨은 16 세에 벌써 유능한 화학자가 되었으며 , 영어 · 프랑스어 · 독일어 · 러시아어 · 스웨덴어 등에 능통했다 . 1850 년 러시아를 떠나 파리에서 1 년 동안 화학을 공부했고 , 그뒤 미국으로 가서 장갑함 모니터호 ( 號 ) 를 만든 존 에릭슨의 지도를 받으며 4 년 동안 일했다 . 상트페테르부르크로 돌아온 뒤에는 아버지가 경영하던 공장에서 일했다 ( 공장은 1859 년 파산했음 ). 스웨덴으로 되돌아온 노벨은 폭발성 액체 니트로글리세린을 만들기 시작했다 . 그러나 이 과정에서 1864 년 공장이 폭발하여 막내 동생 에밀을 비롯하여 5 명이 목숨을 잃었다 . ' 미치광이 과학자 ' 로 낙인찍힌 데다가 스웨덴 정부도 공장의 재건을 허락하지 않자 , 노벨은 배 위에서 니트로글리세린 취급에 따른 위험을 극소화시킬 수 있는 방법을 찾기 위해 실험을 시작했다 . 그는 니트로글리세린을 규산질 충전물질인 규조토에 스며들게 하여 건조시키면 안전하게 취급할 수 있다는 사실을 우연히 발견하고서 마침내 완벽한 다이너마이트와 그에 필요한 뇌관 ( 雷管 ) 을 만들어냈다 . 영국 (1867) 과 미국 (1868) 에서 다이너마이트 특허권을 따낸 그는 , 더 강력한 다이너마이트를 개발하기 위한 실험을 거듭한 끝에 폭발성 젤라틴을 개발하여 1876 년 특허를 땄다 . 또 약 10 년 뒤에는 최초의 니트로글리세린 무연화약이자 코르다이트 폭약의 전신인 발리스타이트 (ballistite) 를 만들었다 . 그는 코르다이트 폭약도 자신의 특허권 범위 안에 든다고 주장하여 1894~95 년 영국 정부와 격렬한 법정 소송을 벌였다 . 그러나 노벨은 결국 이 소송에서 졌다 . 그는 화약제조뿐 아니라 발사만으로는 폭발되지 않는 화약에 쓸 뇌관을 만들고 이를 완벽한 수준까지 끌어올렸다 . 전세계에서 그에게 지불하는 화약류에 대한 사용료와 더불어 러시아 바쿠 유전지대의 대규모 부동산 덕택에 돈을 많이 벌었지만 그때문에 늘 여기저기 돌아다녀야 했다 . 그렇지만 가능하면 은퇴하여 조용히 지내려 애썼으며 , 결혼도 하지 않았다 . 타고난 바탕이 평화주의자였던 노벨은 자기가 발명한 무기로 크고 작은 전쟁을 끝낼 수 있으리라 기대했지만 , 인류와 국가들에 대한 견해는 비관적이었다 . 그는 또한 문학에도 변함없는 관심을 기울였는데 , 젊은시절에는 영어로 시를 쓰기도 했다 . 후에 그의 서류뭉치 속에서 그가 쓴 소설의 초고들이 발견되기도 했다 . 인도주의적이고 과학적인 자선사업에 돈을 아끼지 않았으며 , 재산의 많은 부분을 기금으로 남겨 오늘날 세계적으로 가장 권위있는 상이 된 노벨상이 제정되었다 .
6. 알베르트 아인쉬타인 ( Albert Einstein ) 20 세기초의 창조성이 뛰어난 대표적 지식인이었던 알베르트 아인슈타인은 20 세기초 15 년 동안 질량과 에너지 의 등가를 단언하고 공간 · 시간 · 중력에 관한 새로운 사고방식을 제안한 일련의 이론들을 내놓았다 . 그의 상대성 원리와 중력에 관한 이론들은 뉴턴 물리학을 넘어서는 심오한 진전이었고 과학적 탐구와 철학적 탐구에 혁명을 일으켰으며 , 1921 년 노벨 물리학상을 받았다 . 그는 자신이 ' 사회 정의와 사회적 책임이라는 열정적 감각 ' 을 갖고 있음을 인정했다 . 아인슈타인은 그의 명성 덕택으로 평화주의 · 자유주의 · 시오니즘과 같은 대의를 지지하는 데 영향력이 있었다 . 그러나 아이러니컬하게도 이러한 이상주의적인 사람이 물질 입자가 엄청난 양의 에너지로 바뀔 수 있다는 에너지 - 질량 방정식 가설로 지금까지 알려진 가장 파괴적인 무기인 원자폭탄과 수소폭탄의 창조를 증명했다 . 아인슈타인은 통념과 달리 ' 고독한 천재 ' 가 아닌 장난꾸러기였다 . 아인슈타인은 어떻게 상대성 이론을 만들었을까 ? 알려진 이야기에 따르면 상대성 이론에 대한 아인슈타인의 탐구는 6 살 무렵 , 나침반을 선물로 받은 순간부터 시작됐다고 한다 . 아인슈타인은 상대성 이론의 근간이 되는 아이디어를 과연 어디에서 얻었고 그것을 어떻게 하나의 이론으로 발전시켜 나갔는지 최신의 연구 성과를 토대로 아인슈타인의 삶과 사색의 흔적을 따라가 본다 . 제작진은 아인슈타인의 출생지인 독일 울름과 , 아인슈타인이 수학한 독일 뮌헨 김나지움 , 스위스 취리히 공대 , 상대성이론을 탄생시킨 스위스 베른 특허청 , 말년을 보낸 미국 프린스턴대를 현지 취재했다 . 천재 과학자의 성적이라고 보기에는 너무나 평범했던 아인슈타인의 학교 성적과 학적부를 공개하고 , 암기 과목을 못했던 아인슈타인이 그리스어 교사로부터 ' 넌 아무것도 되지 못할 것이다 ' 라고 폭언을 들었던 일화를 소개한다 . 또한 상대성 이론이 탄생하기 전후의 미공개 문서들과 베른 특허청에 보관되어 있던 유품들을 공개한다 . 이러한 아인슈타인의 흔적을 따라가면서 , 제작진은 기존에 아인슈타인이 ' 고독한 천재 ' 로 알려졌던 것과는 달리 최근에 하버드대 하워드 가드너 교수가 밝힌 것처럼 농담을 즐기며 주변 사람들을 즐겁게 했던 ' 영원한 아이 ' 였음을 보여준다 .
8. 안병권 ( A n, ByoungKwon ) ‘ 트랜스포머’가 현실로 , 로봇을 자유자재로 변형하고 , 세포크기까지 줄이는 길 열려 , 물리학과 졸업 안병권 동문 , 전액장학금 받고 MIT 박사과정진학 , 영화 ‘터미네이터 2’ 의 불사조 사이보그 T-1000, ‘ 트랜스포머’에서 자유자재로 변신하던 로봇 범블비 . 상상 속에서만 존재하던 그들을 이제 현실에서 만날 수 있는 길이 열렸다 . 숭실대 물리학과 졸업생인 안병권 (29 ・ MIT 컴퓨터공학과 박사과정 진학예정 ) 동문은 대학 졸업 후 3 년간 외국 원서와 논문을 참고하여 연구한 끝에 ‘자가변이로봇을 소형화 하는데 필요한 소프트웨어 알고리즘과 하드웨어 메커니즘’을 개발 , 로봇을 세포크기까지 줄여 실생활에서 활용할 수 있는 길을 열었다 . 안 동문의 설명에 따르면 , 하나의 로봇 ( 개체 ) 은 세포역할을 하는 수많은 큐브 ( 모듈 ) 로 구성되어 있다 . 개체의 성격에 따라 단 몇 개 또는 몇 만 개로도 구성할 수 있다 . 큐브는 그 자체로 세포정도의 단순한 지능을 가지고 있는 모듈이자 소형로봇이다 . 사람의 몸을 수많은 세포가 구성하고 있듯 , 로봇을 수많은 큐브가 구성하고 있는 것 . 이 큐브들은 환경과 미션에 맞게 상황별로 변이하며 세포처럼 개체의 기본단위로서 어떤 물체로도 자유자재로 변이 될 수 있다 . 안 동문은 “이번에 개발한 소프트웨어 알고리즘과 , 하드웨어 메커니즘이 각각의 모듈을 더 단순하면서도 , 이상적인 기능 ( 시뮬레이션에서만 가능하던 기능 ) 을 수행 할 수 있도록 만들었다”며 “새로운 소프트웨어 알고리즘과 하드웨어 메커니즘을 통해 기존의 하드웨어를 크게 단순화 시켜서 세포크기까지 만들 수 있는 길을 열었다”고 말했다 . 같은 모양의 세포형 모듈로 구성된 자가변이로봇을 개발해 실생활에서 활용하려는 연구는 1980 년대부터 지금까지 미국 기업과 대학 등을 중심으로 진행되고 있다 . 하지만 인간의 세포역할을 해줄 단위모듈의 복잡도가 문제였다 . 최대한 단순하면서 다양한 기능을 수행할 수 있는 단위 모듈을 만들어야만 각각의 모듈을 세포정도의 크기로 줄일 수 있고 , 복잡한 형태의 모양도 쉽게 만들어 고차원적인 활용과 상용화를 할 수 있었던 것 . 안 동문은 “이 기술은 국내 대학에서는 연구 시도조차 못하고 있는 미지의 분야이며 , 미국에서도 인텔 등의 거대기업과 소수의 대학에서만 연구하고 있다”고 말했다 . 또 “ 1980 년대부터 MIT, 카네기멜론 등 美 명문대학에서 수백만 불을 들여 연구하고 있던 분야를 불과 3 백만 원만 투자해 결과를 얻어냈다”고 덧붙였다 . 안 동문은 “세계 최대의 반도체 제작 업체인 인텔에서 조차 현재까지 큐브의 크기를 줄이지 못하고 있다 . 인텔에서는 큐브를 동그랗게 만들어 변형을 시도하려다 실패를 맛보았다”고 말했다 . 또한 다니엘라 루스 MIT 교수는 “안병권 학생은 실제로 만들기 매우 어려운 것을 단순하고 , 이상적으로 만들 수 있게 했다”고 논문 심사평을 통해 말했다 .
9. 안병권 ( A n, ByoungKwon ) 안 동문이 개발한 기술의 응용분야는 무궁무진하다 . 안 동문은 “영화 ‘트랜스포머’의 범블비가 길에서는 차로 변하고 , 하늘에서는 비행기로 변하듯이 로봇을 자유자재로 변형시킬 수 있다”고 말했다 . 또 “임무를 수행 중인 우주선이나 인공위성의 한 부분이 고장 나도 동작을 멈추지 않고 상황에 따라 변이하며 계속 임무를 수행할 수 있다 . 이는 개별 큐브마다 CPU 가 탑재되어 있어 이와 연동하는 소프트웨어로 처리가 가능한 것”이라고 덧붙였다 . 그는 또 “특히 의료분야에서 많이 활용할 수 있는데 , 심장이 뛰지 않을 때 세포 크기의 큐브가 심장으로 들어가서 심장을 압박 , 다시 심장이 뛰게 만들 수 도 있고 , 암세포를 제거하는 데도 유용하게 사용될 수 있다”고 말했다 . 그는 이 기술의 개발과 관련 , MIT 컴퓨터공학과 박사과정의 입학허가를 받아냈다 . 안 동문은 “학부시절 은사인 김진민・김희상 교수 ( 숭실대 물리학과 ) 로부터 물리학을 체계적으로 배웠고 , 또 학과가 다름에도 불구하고 이남용 교수 ( 숭실대 컴퓨터공학 ) 와는 2 학년 말부터 졸업할 때까지 컴퓨터공학을 함께 연구한 것이 큰 도움이 됐다”고 말했다 . 석사과정을 거치지 않고 박사과정에 바로 입학하는 것이 가능하냐는 질문에 “작년 10 월에 MIT 를 방문했고 담당교수인 다니엘라 루스로부터 입학을 권유받았다”고 말했다 . 하버드 등 외국명문대학을 순회하면서 교수들을 만났다는 그는 “처음에는 ‘시간이 없다’며 만날 기회도 주지 않고 거들떠도 보지 않던 교수들이 한국에서 준비한 연구물을 보여주자 180 도로 달라졌다”고 멋쩍은 듯 말했다 . 그는 오는 9 월부터 연간 학비만 해도 6~7 만 불에 이르는 MIT 에서 전액장학금을 받고 공부를 시작한다 . 또 모교인 숭실대로부터 ‘글로벌인재양성’장학금도 받는다 . 그는 이공계 기피현상이 일고 있는 세태를 보며 “학부 시절 물리를 전공한 것이 이번 연구에 무척 도움이 됐다 . 기초과학을 절대 소홀히 하면 안 된다”고 말했다 . 또 “대학생들이 학부 때부터 교수님과 친해져서 논문도 쓰고 연구도 해서 외국무대에서도 당당하게 활약할 기반을 닦으면 좋겠다”고 ‘팁’을 건냈다 . 한편 , 안 동문은 오는 5 월 19 일부터 23 일까지 美 캘리포니아 파사데나에서 열리는 2008 국제전기학회 컨퍼런스 (2008 IEEE International Conference on Robotics and Automation) 에서 이 기술에 대해 발표한다 . 홍보팀 ( [email_address] )
11. 창의성의 개념 창의성의 개념 창의성이란 현상을 개선하여 부가가치를 높이는 아이디어를 창출하고 그 아이디어를 실행에 옮겨 혁신을 이루는 능력 창의력은 뇌의 모든 부분 (Whole Brain) 을 사용하여 문제를 해결하는 능력이며 , 학습으로 개선할 수 있음 문제해결방법 창의성의 증진 요건 기존 방식의 탈피 관심과 호기심 및 유머감각 적극적 , 긍정적 , 다양한 사고 유연하고 열린 사고 칭찬과 인센티브 , 팀 워크 ( Teamwork )
12. 창의력을 증진하기 위한 교육의 필요성 20 세기 공학의 접근방법 소품 종 대량 생산 제조업 중심 , 생산자 중심 기계화된 제품 생산체제 주어진 문제해결 중심 하드웨어 중심의 제품을 많이 만들고 많이 팔자 ! 21 세기 공학의 접근방법 다품 종 소량 생산 서비스업 중심 , 소비자 중심 IT 기반 지식생산 체제 문제를 스스로 발견하고 해결하는 창의성 중심 소프트웨어중심의 제품으로 시장을 선점하여 지배하자 !
13. 창의력에 도움이 되는 가치관 , 태도 , 행동 그릇된 자존심을 갖지 않는다 . 성공에 대한 능력을 믿는다 . 건설적인 불만을 갖는다 . 도덕적이고 윤리적 기준과 함께 전체적 의식을 갖는다 . 자제심을 갖는다 . 끈기 있고 , 사리사욕이 없고 , 정직하고 , 열심히 일한다 . 규율을 지키고 , 친절하고 , 믿을 만하고 , 편견이 없고 , 봉사적이다 .
14. 창의력을 신장하기 위한 전략 창의력을 신장시키기 위한 전략 고정관념의 틀을 벗으려고 하는가 ? 남의 이야기에 귀를 기울이는가 ? 도전적이며 위험을 감수하는 편인가 ? 차별성이 있는가 ? 서로 다른 것을 조합하고 연결할 수 있는가 ? 뒤집어 생각할 줄 아는가 ? 자유로운 발상을 하는가 ? 질문을 많이 하는가 ? 기록은 잘하고 있는가 ?
15. 창의성과 지능의 관계 지능 학습능력과 적응능력 등 추상적 능력 배우고 이해하는 능력 , 복잡한 상황에 대처하는 능력 창의력 새로운 것 , 자기만의 생각이나 가치가 있는 것을 만들어 내는 능력 이런 능력을 뒷받침해 주는 성격상의 특성 창의성과 지능과의 관계 대단히 지적인 사람 대단히 창의적인 사람 (X) 창의성과 지능은 고유한 특성을 가지면서 부분적 공통부분 존재 독창적인 사고 : 창의성 > 지능 결론 지능이 높다 학습을 잘한다 (O) 창의력이 높다 ? 창의력이 높다 좋은 아이디어를 낸다 (O) 지능이 높다 ? 창의성은 계발될 수 있다 .
16. 공학의 개념 공학은 문제해결을 위한 응용학문이다 . 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 ) 문제 인간의 삶의 질 향상을 위한 환경개선 , 생산 , 가공 및 서비스 방법에 대한 고민 공학의 특성 수학 , 과학 , 공학 지식 경제성 창의성 자연과 환경 , 사회문화와 소비자 요구 이해 팀 활동
17. 공학설계의 개념 공학설계의 정의 필요한 것을 만들기 위해 시스템 , 요소 , 프로세스를 고안하는 과정 - 미국 공학기술인증원 ( ABET: Accrediation Board for Engineering and Technology), 한국공학교육인증원 (ABEEK) 에서도 위와 동일하게 정의하고 있음 (ABEEK : Accreditation Board for Engineering Education of Korea) 즉 , 공학은 기초과학 , 수학 , 공학을 응용하여 자원을 원하는 목적 또는 목표에 부합하도록 가공하는 의사결정과정 공학설계의 특성 다양한 학문을 응용하는 다학문적 프로세스 ( Interdisciplinary Process ) 복잡함 ( Complicated ) 창의적이면서 동시에 분석적 ( Creativity and Analysis ) 반복적인 프로세스 ( Iterative Process )
18. 공학설계프로세스의 개념 공학설계프로세스의 정의 공학설계의 단계를 설명하고 , 체계적으로 공학설계를 수행할 수 있도록 함 공학설계 프로세스는 여러 분야에서 많은 학자들에 의해 다양하게 정의되고 있음 일반적인 공학설계 프로세스 문제식별과 정의 ( Problem Identification and Definition) 기준과 제약사항의 설정 ( Establishment of Criteria and Constraints ) 정보 및 자료의 수집과 분석 ( Information and Data Analysis ) 해결방안의 도출과 검토 ( Consideration of Alternatives ) 해결방안의 의사결정 ( Decision ) 구체적으로 명세화 ( Specification )
19. 창의적공학설계의 개념 공학설계의 능력을 배양하기 위한 교과목 유능한 공학자 ( 엔지니어 ) 가 되기 위한 자질을 교육 공학자 기술적인 문제의 경제적인 해결책을 찾기 위해 과학과 수학적 원리를 응용하는 사람 - 미국노동통계국 ( The Bureau of Labor Statistic ) 공학자의 활동은 사회적 요구 (Social Needs) 와 소비자의 요구 (Consumer Needs) 를 충족하기 위해 과학적 탐구 (Scientific Discoveries) 과학자가 새로운 지식을 발견하는 사람이라면 , 공학자는 그러한 지식을 활용하여 제품 , 신기술을 만들어내는 사람
20. 창의적공학설계의 교육목표 ABEEK 에서는 공학전공 졸업자들에게 다음과 같은 능력과 자질을 갖추도록 요구하고 있음 ( 창의적공학설계의 목표학습성과 ) 수학 , 기초과학 , 공학의 지식과 정보기술을 응용할 수 있는 능력 자료를 이해하고 분석할 수 있는 능력 및 실험을 계획하고 수행할 수 있는 능력 현실적 제한조건을 반영하여 시스템 , 요소 , 공정을 설계할 수 있는 능력 공학 문제들을 인식하며 , 이를 공식화하고 해결할 수 있는 능력 공학 실무에 필요한 기술 , 방법 , 도구들을 사용할 수 있는 능력 복합 학제적 팀의 한 구성원의 역할을 해낼 수 있는 능력 효과적으로 의사를 전달할 수 있는 능력 평생교육의 필요성에 대한 인식과 능동적으로 참여할 수 있는 능력 공학적 해결방안이 세계적 , 경제적 , 환경적 , 사회적 상황에 끼치는 영향을 이해할 수 있는 폭넓은 지식 시사적 논점들에 대한 기본지식 직업적 책임과 윤리적 책임에 대한 인식 세계문화에 대한 이해와 국제적으로 협동할 수 있는 능력
21. 소프트웨어공학의 개념 일반적인 정의 : 소프트웨어시스템 ( 제품 ) 의 개발에 대한 공학적 접근방법을 연구하는 학문 IEEE 의 정의 : 소프트웨어의 개발과 운용 및 유지보수에 대한 체계적 (systematic) 이며 훈련된 (disciplined) 계량적 (quantifiable) 접근 방법 Bauer 의 정의 : 컴퓨터 H/W 에서 신뢰성 있게 운영되는 S/W 를 경제성 있게 개발하기 위해 공학적 원리를 응용하는 방법 Boehm 의 정의 : 컴퓨터 프로그램의 설계 , 개발 , 운영 , 유지보수와 관련하여 문서를 작성하는데 필요한 과학적 지식의 응용 Fairley 의 정의 : 컴퓨터과학 , 경제학 , 경영과학 , 의사소통기술 , 문제해결을 위한 공학적 기법을 기반으로 S/W 개발과 관련된 새로운 기술체계
22. 소프트웨어공학과 공학설계 소프트웨어의 공학설계 프로세스 문제식별과 정의 ( Problem Identification and Definition) 요구사항분석 ( Requirement Analysis ) 구조설계 ( Structural Design ) 동작설계 ( Behavioral Design ) 소프트웨어의 공학설계 표기법 ( 언어 ) UML ( Unifiend Modeling Language ) 창의적 공학설계 언어 창의적 공학설계 표기법 ( 언어 ) 국제표준언어
24. 창의적 문제해결 창의적 문제해결의 정의 “ Creative problem solving is - looking at the same thing as everyone else and thinking something different.” - 노벨상 수상자 , Albert Szent-Gyorgi 창의적 문제해결의 핵심은 정보를 이용하는 것이 아니라 지식을 활용하는 것 창의적 문제해결을 위해서는 새로운 아이디어를 찾고자 하는 의지를 가지고 자신의 지식과 경험을 활용하여야 함 사고를 전환하고 지식을 활용하여 일상적인 것에 특별함을 부여하는 것
25. 창의적 문제해결 창의적 문제해결의 예 4 개의 직선으로 다음 9 개의 점을 이어 보시오 .
26. 창의적 문제해결 창의적 문제해결의 예 4 개의 직선으로 다음 9 개의 점을 이어 보시오 .
27. 창의적 문제해결 우리는 왜 좀더 일상생활에서 창의적인 생각들을 하지 않는가 ? 우리가 창의적 사고를 하는 데 있어 방해요소들은 무엇인가 ?
28. 창의적 문제해결 창의적 문제해결에 있어서의 장애요소 시간 창의적인 사고는 많은 시간을 필요로 함 필요성 굳이 모든 것들을 창의적으로 해결할 필요는 없음 버릇이나 습관 특별할 것 없는 일상 생활 창의성에 대한 학습의 부재
29. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 일상적인 사고를 벗어나지 못하는 마음가짐 “ 난 창의적이지 못하다” “ 창의적 사고는 어렵다” 창의적 사고를 하지 못하는 이유 멘탈블럭 10 가지 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. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 1. The right answer. Only one ? 정답은 한가지가 아니다
31. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 2. That’s not logical. 비논리적인 것도 논리적이 될 수 있다
32. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 3. Follow the rules. 룰을 벗어나야 새로운 생각을 가질 수 있다 . 룰 (Rule) 필요성에 대한 공통된 인식을 통해 만들어진 것 모든 사람들은 룰을 지킴 .
33. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 4. Be practical. 반드시 실용적인 것만이 창의적인 것은 아니다 .
34. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 5. Play is frivolous. 사소한 것도 창의적인 것이 될 수 있다 . “ When do you get your best ideas?”
35. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 6. That’s not my area. 창의적 사고는 자신의 영역을 벗어날 때 이루어진다 .
36. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 7. Avoid ambiguity. 사람들은 모호한 것을 볼 때 창의적인 사고를 하게 된다 . AMBIGUITY
37. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 8. Don’t be foolish. 바보 같은 사고가 가장 천재적인 사고가 될 수 있다 .
38. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 9. To err is wrong. 실패는 나쁜 것이 아니다 .
39. 창의적 문제해결 멘탈 블럭 ( Mental Blocks ) 10. I’m not creative. 자신이 창의적이지 못하다는 생각을 버려야 한다 .
40. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 문제의 정의 근본적인 문제를 기술하기 보다 , 문제해결을 위한 시작점을 설정 즉 , “ 어떠한 문제가 있을 것 같다” 라는 가정을 도출하는 단계 따라서 , 여기서 정의된 문제는 추후에 변경될 수도 있음 STEP 1. State what appears to be the problem
41. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 자료의 수집 문제의 원인은 무었인가 ? 언제 , 어디서 , 어떻게 발생하는가 ? 크기 , 범위 , 심각성 등은 어느 정도나 되는가 ? 누구에게 어떠한 영향을 미치는가 ? 반드시 해결되어야 하는가 ? STEP 2. Gather facts, feelings and opinions.
42. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 문제의 재정의 수집된 자료를 통해서 정확한 문제를 정의하는 단계 실제 문제는 어떠한 원인에 의해 발생되며 , 어떠한 영향을 끼치게 되는지 구체적으로 정의 STEP 3. Restate the problem.
43. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 해결책 모색 아이디어를 제시하고 가능한 많은 해결방법들을 모색하는 단계 아주 사소한 해결책까지도 간과해서는 안됨 . 다른 사람들과 가능한 많은 토론을 통해 찾아내는 것이 유용함 . STEP 4. Identify Alternative Solutions.
44. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 해결책 평가 여러 해결방법들을 평가하고 최선의 해결방법을 찾아내는 단계 효과 / 비용 측면들이 고려됨 선택된 해결방법이 또 다른 문제의 원인이 되지 않는지 검토기 필요 STEP 5. Evaluate Alternatives.
45. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 해결책 적용 최종적으로 채택된 해결방법을 적용하는 단계 누가 , 어디서 , 언제 , 어떠한 방법으로 적용시킬 것인지를 결정 적용결과는 어떻게 수집되고 평가될 것인지를 결정 STEP 6. Implement the decision.
46. 창의적 문제해결 프로세스 창의적으로 문제를 해결하는 절차 해결책 평가 해결방법을 통해 원하는 결과가 수집되었는지를 평가하는 단계 원가는 결과가 수집되지 않았다면 , 해결방법을 수정하고 다시 적용하여 문제를 해결 STEP 7. Evaluate the results.
48. 창의적 문제해결 기법 창의적 문제해결 기법은 크게 2 가지로 구분됨 확산적 사고 ( 생성적 사고 ) 를 통한 문제해결 새로운 아이디어 ( 대안 , 가능성 ) 를 생성하고 , 표현하는 것 브레인스토밍 스캠퍼 초점적 사고 ( 비판적 사고 ) 를 통한 문제해결 발산적 사고를 통해 제안된 아이디어를 분석하여 선택하거나 보완하여 구체적인 문제해결방법을 찾아내는 것 마인드맵 PMI 기법 평가행렬법
49. 창의적 문제해결 기법 브레인스토밍 ( Brainstorming ) 특정한 주제에 대하여 머리 (brain) 에서 폭풍 (storming) 이 몰아치듯 생각나는 아디어를 되도록 많이 내어 놓는 방법 짧은 시간에 많은 아이디어를 만들어 내는 것이 목적 주로 집단 토의에서 활용 브레인스토밍 기법 활용하는 경우 문제의 근본 원인을 모두 찾으려 할 때 문제의 해결책을 찾으려 할 때 어떤 개선활동을 해야할지 결정할 때 프로젝트의 각 단계별 계획을 세울 때 공정 , 제품 , 서비스 등의 개선방안을 찾을 때
50. 창의적 문제해결 기법 브레인스토밍의 진행방식 5~12 명 정도로 집단을 구성하고 , 나이 , 성별 , 관심 , 전공 등 되도록 다양한 측면의 사람들이 에서 동일한 문제를 접근할 수 있도록 함 진행 중에는 토의와 비판을 금지 아이디어에 새로운 아이디어를 추가하는 것은 허용 아이디어는 빠뜨리지 않도록 기록하고 스티꺼나 큰 칠판을 활용 바보 같거나 , 미친 듯한 아이디어도 수용하고 기록 브레인스토밍의 4S 규칙 Support : 어떤 아이디어라도 절대로 비판하거나 평가하지 않는다 Silly : 비현설적이거나 터무니없는 것이더라도 모두 수용한다 . Speed : 가능한 한 많은 아이디어를 제안한다 . Synergy : 두 개 이상의 다른 아이디어를 결합 , 새로운 아이디어를 이끌어 낸다 .
51. 창의적 문제해결 기법 스캠퍼 ( SCAMPER ) 특정 대상이나 문제에 7 가지의 대표적인 질문을 활용하여 사고를 자극함으로써 새로운 아이디어를 얻는 기법 7 가지 질문 대체하기 ( S ubstitute ) 결합하기 ( C ombine ) 적용시키기 ( A dapt ) 수정 - 확대 - 축소하기 ( M odify-Magnify-Minify ) 용도변경하기 ( P ut to other uses ) 제거하기 ( E liminate ) 재정리하기 ( R earrange )
52. 창의적 문제해결 기법 스캠퍼 ( SCAMPER ) 대체하기 ( S ubstitute ) 제품의 본질적인 기능을 유지하면서 다른 재료 , 부품 , 에너지 등으로 대체하는 것 종이컵 , 물침대 , 태양전지자동차 등 결합하기 ( C ombine ) 다른 기능이 가지는 두 가지 이상의 제품을 결합하기 지우개 달린 연필 , 핸드폰카메라 등 적용시키기 ( A dapt ) 다른 물건이나 제품의 기능을 적용하기 장미덩쿨 철조망 , 돌고래 수증음파탐지기 등
53. 창의적 문제해결 기법 스캠퍼 ( SCAMPER ) 수정 - 확대 - 축소하기 ( M odify-Magnify-Minify ) 기존제품을 수정 , 확대 , 축소하기 Post-it, 워크맨 , PMP 등 용도변경하기 ( P ut to other uses ) 기존 제품의 용도를 변경하기 페타이어 발전소원료 , 톱밥 장작 제거하기 ( E liminate ) 기존제품의 불필요한 부분을 제거하기 씨없는 수박 등 재정리하기 ( R earrange ) 기존 제품의 기능 또는 특성을 재정리하거나 역으로 배치하기 다섯발가락 양말 , 누드 김밥 등
54. 창의적 문제해결 기법 스캠퍼 기법을 이용한 다기능성 자전거 아이디어 S : 기존의 공기 주입식 타이어 대신 바람을 넣지 않는 타이어로 대체 C : 에너지 저장장치를 장착하여 핸드폰을 충전 시킴 A : 자전거 바퀴회전을 이용하여 솜사탕 기계로 기능을 바꾼 M : 커플자전거 , 큰 짐을 실을 수 있는 자전거 , 어린이 자전거 P : 우천 시 헬스 기구로 활용 E : 외발자전거 R : 전륜 구동 자전거
55. 창의적 문제해결 기법 마인드맵 ( Mind Map ) 수렴적 사고 기법 문제에 대하여 큰 빈 종이 위에 이미지와 핵심단어를 색과 부호 등을 이용하여 지도를 그려나가는 방법 아이디어를 조직화하고 정보를 서로 연결하여 체계적으로 기억할 수 있게 하고 보다 세부적으로 아이디어를 다듬을 수 있도록 함 마인드 맵의 구조 생각의 핵심이 되는 주제는 항상 중심 이미지에서 시작 중심 이미지에 관련된 주요 주제는 사람의 몸에 붙어있는 팔처럼 연결되어 표현 가지들의 연결은 핵심 이미지와 핵심단어를 통해 확산 계속 이어지는 부주제들은 나뭇가지의 마디마디가 서로 연결되어 있는 듯한 구조
57. 창의적 문제해결 기법 PMI 기법 수렴적 사고 기법 제안된 아이디어의 장점 (P), 단점 (M), 흥미로운 점 (I) 을 따져본 후 그 아이디어를 평가하는 기법 PMI 평가요소 Plus : 제시된 아이디어의 좋은 점 Minus : 제시된 아이디어의 나쁜 점 Interesting : 제시된 아이디어와 관련하여 흥미로운 점 PMI 적용사례 아이디어 : 바이오 디젤 자동차 P : 환경오염을 줄일 수 있다 M : 식량난을 초래할 수 있다 I : 식물성 기름도 연료로 사용될 수 있다 .
58. 창의적 문제해결 기법 평가행렬법 수렴적 사고 기법 체계적으로 제안된 아이디어를 평가하는 방법으로서 평가하려는 아이디어를 평가 기준에 따라 객관적으로 평가하는 것 아이디어의 평가기준을 가로축으로 , 아이디어를 세로축으로 하여 행렬을 만들고 평가기준을 더하거나 곱하여 평가결과값을 산정 아이디어 구입비용 관리비용 속도 편리성 실현 가능성 합계 버스 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
63. 모델링의 중요성 모델링 (Modeling) 모델을 만드는 일 ( 추상화 ) 로써 품질이 좋은 소프트웨어를 개발 및 배치할 수 있게 하는 모든 활동의 중심 모델 구축을 통해 개발 대상 시스템에 대한 이해의 증진 모델 (Model) 현실을 단순화 / 가시화 시키는 것 System 의 Blueprint 를 제공 개발 고려 시스템의 총체적인 계획 및 상세 계획 표현 중요 영향 요소의 파악 , 불 필요 요소의 생략 및 시스템 구축 제약 조건 표현 모델링의 목적 시스템을 현재 또는 원하는 모습으로 가시화 시스템의 구조와 행동을 명세화 시스템을 구축하는 기본 형태를 제공 시스템 분석 / 설계의 문서화
64. 모델링의 원리 모델링의 원리 생성할 모델의 신중한 선택 : 선택 모델에 따라 문제를 공략하는 방법과 해결책을 실현하는 방법에 많은 영향이 있음 모든 모델을 다양한 수준의 정밀도로 표현 현실을 반영한 모델 작성 상호 독립적인 모델들 몇 가지를 선택하여 모델링에 착수
65. 객체 지향 모델링 소프트웨어의 모델링 관점 알고리즘 관점 : S/W 의 주요 구성 요소인 Procedure 와 Function 을 제어 관점에서 분할하여 시스템을 모형화 요구사항 변화에 적응력이 없음 대규모 시스템에서는 유지보수를 포함한 관리의 어려움 객체 지향 관점 : S/W 시스템의 기본 요소를 객체 또는 클래스로 파악하여 문제 영역과 해결 영역을 모형화 객체 (Object) : 사물 (Thing) 을 말하며 고유성과 상태 , 행동을 갖음 클래스 (Class) : 공통적인 객체들의 집합 UML(Unified Modeling Language) 의 목적 객체 지향 시스템을 가시화 , 명세화 , 문서화 하는 것
66. 2 장 . UML 소개 UML 개요 UML 개념 모델 UML 아키텍쳐 UML 개발 생명주기
67. UML 개요 UML 은 언어 (Language) 어휘와 규칙을 두어 시스템을 개념적이고 물리적으로 표현하여 의사 소통을 돕는 것을 목적으로 함 시스템을 이해하기 위하여 하나 이상의 모델을 서로 연결 사용하여 복합적인 모델로 이해를 도움 가시화 명세화 구축 문서화 UML S/W 청사진 작성 표준언어 SYSTEM 산출물
68. UML 가시화 언어 개념 모델 작성 오류 없이 전달 의사 소통의 용이 Graphic 언어 구축 언어 다양한 Prog. 언어와 연결 왕복 공학 가능 ( 순 공학 / 역공 학 ) 실행 시스템 예측 가능 명세화 언어 정확한 모델 제시 완전한 모델 작성 분석 , 설계의 결정 표현 문서화 언어 시스템에 대한 통제 , 평가 , 의사소통의 문서 ( 요구사항 , Architecture, 설계 , Source Code, Project 계획 ,Test, Prototype, Release)
70. 사물 (Things) : 추상적 개념으로 모형 구성의 기본 요소 구조 사물 (Structural Thing) : UML 모형의 명사형으로써 모형의 정적인 부분이며 개념적이거나 물리적인 요소들을 표현 클래스 (Class) 동일한 속성 (Attribute), Operation, 관계 , 그리고 의미를 공유하는 객체를 표현 인터페이스 (Interface) Class 또는 Component 의 Service 를 명세화 하는 Operation 들의 집합 외부적으로 가시화 할 수 있는 요소의 행동을 설명 특정 Class 나 Component 의 전체 또는 일부분 만의 행동을 표현 Window origin size open ( ) close ( ) move ( ) display ( ) ISpelling
71. 협력 (Collaboration) 교류 (Interaction) 를 정의하며 서로 다른 요소와 역할들의 집합을 표현 시스템을 구성하는 Pattern 을 표현 - Class 의 행동적이고 구조적인 중요성을 도식 쓰임새 (Use Case) 시스템이 수행하는 순차적 활동들을 기술하며 행위자 (Actor) 에게 결과치를 제공 행동 사물을 구조화하기 위하여 사용하며 협력으로 실현 활성 클래스 (Active Class) 객체가 하나 또는 그 이상의 Process 나 Tread 를 갖는 클래스 ( 제어 활동을 포함 ) 객체들의 행동이 다른 요소들과 함께 동시적으로 발생 Chain of responsibility Chain of responsibility use EventManager suspend ( ) flush ( )
72. 컴포넌트 (Component) 시스템의 물리적이고 대체 가능한 부분으로 Interface 를 준수하고 구현 Class, Interface, Collaboration 등 서로 다른 논리 요소를 물리적으로 Package 화 Component 종류 : Application, Document, File, Library, Page, Table, ….. 노드 (Node) 실행 시에 존재하는 물리적 요소이며 Computer 자원을 나타내고 약간의 Memory 와 처리 능력을 포함 Server orderform.java
73. 행동 사물 (Behavioral Thing) : UML 모형의 동사형으로써 모형의 동적인 부분이며 시간과 공간에 따른 행동 요소들을 표현 교류 (Interaction) 행위이며 지정된 목적을 완성하기 위하여 특정 문맥에 속한 객체들 사이에 주고 받는 Message 들로 구성 상태 머신 (State Machine) 상태의 순서를 지정하는 행동 하나의 객체 혹은 교류에 발생하는 사건 (Event) 에 대한 대기 및 응답의 표현 Waiting Display
74. 그룹 사물 (Grouping Thing) : UML 모형을 조직하는 부분이며 모델을 분해하여 재 구성화 할 수 있는 단위 상자 패키지 (Package) 요소들을 Group 으로 묶는 다목적 Mechanism Component 와는 다르며 개발 시에만 존재하는 개념적인 모형 종류 : Frame Work, Sub System 표현 Business Rules
75. 주해 사물 (Annotation Thing) : UML 모형을 설명하는 부분이며 Comment 로써 모형 요소를 설명하고 , 명확히 하는 표현 도구 노트 (Note) 하나의 요소 또는 요소들로 구성된 공동체에 첨부되는 제약과 주석을 표현하는 기호 Return copy of self
76. 관계 (Relationships) : 구성 요소 간의 의미 있는 연결 의존 관계 (Dependency Relationship) 두 사물간의 의미적인 관계로써 한쪽 ( 독립 ) 사물의 변화가 다른 ( 종속 ) 사물에 영향을 주는 관계 연관 관계 (Association Relationship) 구조적 관계로써 Link( 객체 간의 연결 ) 의 집합을 나타냄 집합 (Aggregation) 연관 관계는 특별한 연관 관계로써 전체 (Whole) 와 부분 (Part) 간의 구조적 관계를 표현 Employer Employee 0 .. 1 *
77. 일반화 관계 (Generalization Relationship) 특수화 (Specialization)/ 일반화 (Generalization) 관계로써 일반화 된 요소 (Parent) 의 객체를 특수화된 요소 (Child) 의 객체로 치환할 수 있는 관계 (Child 는 Parent 의 구조와 행동을 공유 ) 실체화 관계 (Realization Relationship) 분류자 (Classifier) 간의 의미적 관계 한 쪽 분류자는 다른 쪽 분류자가 수행하기로 되어 있는 계약 (Contract) 을 명세화
78. 도해 (Diagramming) : 구성 요소 들의 Graphic 표현 클래스도 (Class Diagram) Class, Interface, Collaboration 간의 관계를 나타내며 객체 지향 시스템 모형화에서 가장 공통적으로 많이 쓰이는 Diagram Class Diagram : 시스템의 정적 (Static) 설계 View Active Class Diagram : 시스템의 정적 Process View 객체도 (Object Diagram) 객체들 사이의 관계를 표현 Class Diagram 에 있는 사물들의 Instance 에 대한 정적 Snap Shut 을 표현 실제 사례나 Prototype 사례의 시각에서 도해 쓰임새도 (Use Case Diagram) Use Case, Actor 간의 관계를 표현 시스템 행동을 조직화하고 Modeling 시스템의 정적 Use Case View 순차도 (Sequence Diagram), 협력도 (Collaboration Diagram) 교류도 (Interaction Diagram) 의 한 종류로 객체와 객체 간의 관계 , 그리고 객체 간에 보낼 수 있는 Message 들로 구성 순차도 와 협력도 는 동일 구조로써 상호 변형가능하며 순차도 는 Message 의 시간적 순서를 강조하고 협력도 는 객체의 구조적 구성을 강조 시스템의 동적 (Dynamic) View
79. 상태도 (State Diagram) 상태 (State), 전이 (Transition), 사건 (Event), 활동 (Activity) 로 구성 사건에 따라 순차적으로 발생하는 객체 행동에 중점을 두고 작성 시스템의 동적 View 활동도 (Activity Diagram) 특별한 종류의 상태도로써 시스템 내부에 있는 활동간의 흐름을 표현 시스템의 기능을 모형화하고 객체간의 제어 흐름 표현에 유용 시스템의 동적 View 컴포넌트도 (Component Diagram) Component 간의 구성과 의존 관계를 표현 시스템의 정적 구현 View 배치도 (Deployment Diagram) 실행 시 처리하는 Node 와 그 Node 에 존재하는 Component 들의 구성을 표현 Architecture 의 정적 배치 View
80. UML 규칙 UML 규칙은 자체 일관성이 있으며 관련 Model 들과 조화를 이룸 잘못된 모형 이름 (Name) 사물 , 관계 , 도해의 호칭 범위 (Scope) 이름에 특정한 의미를 부여하는 문맥 (Context) 가시성 (Visibility) 이름을 참조하고 사용할 수 있는 방법 무결성 (Integrity) 사물 상호간에 올바르고 일관성 있는 관계를 유지시키는 방법 실행 (Execution) 동적 Model 을 실행하거나 모의 실험 하는 것 생략 (Elided) View 를 단순화 하려고 특정 요소를 감춤 불완전 (Incomplete) 특정 요소를 빼고 작성 불일치 (Inconsistent) 모델의 무결성이 보장되지 않음
81. UML 공통 Mechanism 명세서 (Specification) UML 의 Graphic 표현에 구문법과 구성 요소의 의미를 포함하여 점진적으로 모델을 구성 표기 (Adornment) UML 요소의 고유하고 직접적인 Graphic 표기 등 요소의 가장 중요한 관점을 가시적으로 표현 Transaction + execute ( ) + rollback ( ) # priority ( ) - timestamp ( )
82. 공통 분할 (Common Division) 객체 지향 모델링은 다시 몇 가지로 나누어 표현 가능 Class 와 Object 의 분할 Interface 와 구현의 분리 Customer name address phone Jan : Customer : Customer Elyse spellingwizard.dll IUnknown ISpelling
83. 확장 메커니즘 (Extensibility Mechanism) UML 의 목적인 분석 / 설계 정보를 보다 정확하게 전달하기 위한 표준 언어를 제공 하나의 언어로 불가능한 모형은 통제된 방법으로 언어를 확장 스테레오 타입 (Stereotypes) UML 어휘를 확장하여 새로운 종류의 구성 요소를 생성 기존 구성에서 파생되므로 문제 영역은 기존 구성 요소의 고유한 것 꼬리표 값 (Tagged Values) UML 의 구성 요소가 갖는 Property 를 확장 구성 요소의 명세서에 새로운 정보를 추가 생성 가능하도록 제약 (Constraints) UML 구성 요소가 갖는 의미를 확장하여 새로운 규칙의 추가 및 기존 규칙 변경 EventQueue {version = 3.2 author = YL} add ( ) remove ( ) flush ( ) “ exception” Overflow { ordered} Tagged Value Constraint Stereotype
84. UML 아키텍쳐 아키텍쳐 결정 사항 S/W System 의 구성 System 구성 요소들과 요소들 간의 Interface 선택 요소들 간의 협력으로 명세화 되는 행동을 결정 점진적으로 큰 시스템으로의 구조 요소와 행동 요소를 결합 아키텍쳐 양식 ( 정적 / 동적 ) 들과 이들의 Interface, 협력 , 결합을 표현 S/W Architecture 구조와 행동 용도 , 기능성 , 성능 , 탄력성 , 재 사용성 , 경제성 기술적 제약 및 방법 미학적 표현 . . . .
85. S/W 중심 시스템의 Architecture Modeling 설계 뷰 (Design View) 구현 뷰 (Implementation View) 프로세스 뷰 (Process View) 배치 뷰 (Deployment View) 쓰임새 뷰 (Use Case View) 시스템 조립 형상관리 시스템 구성 형태 분산 , 인도 , 설치 어휘 기능성 성능 확장성 처리량
86. 아키텍쳐 종류 내 용 정적 도해 동적 도해 쓰임새 뷰 (Use Case View) 시스템 행동을 설명 최종사용자 , 분석가 , 설계자 , 테스트 담당자에게 제공 되는 뷰 시스템 아키텍쳐를 구체화하는 요인들을 명세화 쓰임새도 교류도 상태도 활동도 설계 뷰 (Design View) 시스템이 최종사용자에게 제공해야 할 서비스를 표현 문제 영역과 해법의 어휘를 형성하고 있는 Class, Interface, Collaboration 으로 구성 클래스도 객체도 교류도 상태도 활동도 프로세스 뷰 (Process View) 시스템의 성능 , 신축성 , 처리 능력을 표현 시스템의 동시성과 동기화 메커니즘을 형성하고 있는 Thread 와 Process 로 구성 클래스도 객체도 활성 클래스도 교류도 상태도 활동도 구현 뷰 (Implementation View) 시스템 배포의 형상관리 표현 물리적인 시스템을 조립하고 배포하는데 사용되는 Component 와 File 들로 구성 컴포넌트도 교류도 상태도 활동도 배치 뷰 (Deployment View) 시스템을 구성하는 물리적 부분의 분산 , 인도 , 설치 표현 H/W 형태를 형성하는 Node 로 구성 배치도 교류도 상태도 활동도
87. UML 개발 생명주기 개발 Process 고려 사항 UML 은 개발 Process 에 독립적 임 프로세스 설 명 쓰임세 중심 System 에 요구되는 행동을 파악 System Architecture 검증 , 확인 및 Test Project 관련자의 의사소통 (Use Case 관련 주요 산출물 활용 ) 아키텍쳐 중심 개발중인 System 의 개념화 , 구축 , 관리 진화 ( 변화 ) 내용을 파악하고 수행 (System Architecture 관련 주요 산출물 활용 ) 반복 / 점진적 프로세스 중심 반복 프로세스는 실행 배포판을 관리 점진적 프로세스는 System Architecture 를 지속적으로 통합하고 개정 배포판을 작성
88. S/W 개발 생명 주기 단계 각 단계는 반복적으로 수행되며 반복은 별개 활동으로써 대내외적으로 배포판을 만드는 기준 계획과 평가 기준을 갖음 단계 설 명 도입 (Inception) 개발의 시작점으로써 대상 요소들을 정의 정련 단계로 진입할 수 있는 충분한 근거 파악 정련 (Elaboration) 제품 Vision 과 Architecture 를 정의 System 의 요구 사항의 명료화 , 우선 순위 결정 , 기준선 설정 및 Test 기준 설정 요구 사항의 기능적 행동과 비 기능적 행동을 명세화 구축 (Construction) S/W 의 작성 및 실행 Architecture 기준선으로부터 전이의 준비 단계 Project 에 대한 요구 사항과 평가 기준의 재 검사 위험 요소들을 제거하기위한 자원의 할당 전이 (Transition) S/W 의 사용자 전달 System 의 지속적인 개선 , 결함 제거 배포판에 새로운 특성 추가
89. Process Workflow Business Modeling 요구 사항 분석 / 설계 구현 Test 배치 지원 Workflow 형상 및 변경관리 Project 관리 환경 도입 정련 구축 전이 예비 반복 반복 # 1 반복 # 2 반복 # m 반복 # m+1 반복 # n 반복 # n+1 반복 # n+2
91. 핵심 부분 추상화 Web Browser Java Applet “Hello World ! “ 의 예제 import java.awt . Graphics ; class HelloWorld extends java.applet . Applet { public void paint (Graphics g ) { g ’. drawString (“Hello, World !”, 10 , 10); } } Class Package Parameter 호출 OP. Operation
92. HelloWorld 의 핵심 부분 추상화 HelloWorld 주위의 인접 Class HelloWorld paint ( ) G.drawString (“Hello, World !”, 10, 10) HelloWorld paint ( ) Graphics Applet 의존 관계 일반화 관계 ( 상속 관계 )
93. HelloWorld 상속 (Inheritance) 계층도 HelloWorld Applet Panel Container Component Object ImageObserver 구현 부분은 없으며 다른 Class 에서 Interface 를 구현할 필요가 있음 Java 에 있는 모든 Class 의 Parent Class
94. HelloWorld 의 Package 도 Java HelloWorld applet awt lang
95. 메카니즘 메커니즘 표현 Class 의 상속 관계의 표현이 아닌 Operation 의 실행을 표현 각 Class 에 속하는 Instance 를 포함해서 다수의 객체들이 순서를 갖고 협력하는 것을 표현 Painting Mechanism : Thread : Toolkit : ComponentPeer Target : HelloWorld Run Run CallbackLoop handleExpose paint Instance Operation
96. 컴포넌트 컴포넌트 표현 실행 가능한 Component 를 연결하여 각 메커니즘에 의해 기동 되는 것을 도식 개발 환경과 구성 관리 툴을 포함하여 표현 HelloWorld Component HelloWorld.class hello.html hello.jpg HelloWorld.java
97. [2] 기본 구조 모델링 4 장 . 클래스 5 장 . 관계 6 장 . 공통 메카니즘 7 장 . 도해 8 장 . 클래스도
98. 4 장 . 클래스 (Class) 시작하기 용어와 개념 보편적 모델링 기법 시스템 어휘 모델링 시스템에서 책임 분산 모델링 비 소프트웨어 사물 모델링 원시 타입 모델링 힌트와 조언
99. 시작하기 클래스 란 ? 어휘의 일부가 되는 사물들을 추상화 하는 것 클래스는 가장 중요한 구성 요소이며 동일한 속성 , Operation, Relation 그리고 의미를 공유하는 객체 집합을 표현 하나 또는 그 이상의 Interface 를 구현 Shape origin move ( ) resize ( ) display ( ) Class 명 Attribute 명 Operation 명
100. 용어와 개념 Class 명 모든 Class 는 다른 Class 들과 구별되는 유일한 명칭을 갖음 단순명 (Simple Name) : Class 자체만을 표현 경로명 (Path Name) : Class 가 소속된 Package 명을 포함 Temperature Sensor Customer Wall Business Rules :: FraudAgent Java :: awt :: Rectangle Simple Name Path Name
101. 속성 (Attribute) Class 의 Property 에 이를 대표하는 짧은 명사나 명사구로 이름을 붙인 것 속성 표현 속성과 타입 표현 Visibility Name : Type = Default Value + : 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. 오퍼레이션 (Operation) 객체 행동에 영향을 주기 위해 특정 Class 의 객체로부터 요청할 수 있는 Service 를 표현한 것 ( 객체에서 할 수 있는 것이 무엇인가를 추상화 한 것 ) 오퍼레이션 표현 오퍼레이션 (Operation : Class) 과 용법 (Method : Object) 표현 속성과 오퍼레이션 구성 Visibility Name (Parameter-List) : Return-Type-Expression {Property-String} 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. 책임 (Responsibility) Class 가 행해야 하는 의무 또는 계약 속성과 오퍼레이션 특성들로 Class 의 책임을 수행 CRC(Class Responsibility Collaboration) Card 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. 보편적 모델링 기법 시스템 어휘 모델링 사용자나 개발자가 문제나 해법을 설명하기 위해 사용하는 사물을 파악 (CRC Card, Use Case 중심 분석 ) 추상 개념에 대한 책임을 파악 Class 의 책임을 수행하기 위하여 필요한 속성과 오퍼레이션 파악 모델은 점점 커지게 되며 개념적 또는 의미적으로 연관 있는 것 끼리 Class 집단을 모델링 하여 Package 화 함 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. 시스템 책임 분산 모델링 어떤 행동을 수행하기위해 긴밀하게 연관 있는 Class 집합을 파악 Class 각각의 책임 집합 파악 Class 에 너무 많은 책임이 있으면 작게 , 너무 적은 책임이 있으면 여러 개를 모아서 하나의 역할을 수행할 수 있는 합리적 Class 로 재 할당 서로 교류하는 것을 파악하여 적절하게 책임을 재 분배 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. 비 소프트웨어 사물 모델링 추상화 대상 사물을 Class 로 Modeling 이미 정의된 구성 요소들과 구분을 위해 Stereotype 을 사용하고 새로운 의미와 분명한 시각적 암시를 제공 Modeling 하려는 대상이 S/W 를 포함하는 H/W 의 일종이면 Node 로 Modeling Robot processOrder ( ) change Order ( ) status ( ) Account Receivable Agent
107. 원시 타입 모델링 추상화 대상 사물을 Type 이나 열거 Type 으로 Modeling 하고 Stereotype 과 함께 Class 로 표현 이 Type 에 값의 범위를 지정하려면 제약을 사용 <<type>> Int {values range from -2**31-1 to +2**31} <<enumeration>> Boolean false true <<enumeration>> Status idle working error
108. 힌트와 조언 좋은 구조의 Class 문제 영역이나 해법 영역 어휘에서 추출된 Class 에 대한 명확한 추상화 제공 작고도 정의가 잘된 책임 집합을 가지며 그들 모두를 매우 잘 수행 추상 개념 명세서와 구현을 분명하게 구분 이해하기 좋고 , 단순하며 , 확장 가능하고 , 적응이 용이 UML 에서 Class 를 도해 방법 문맥상에서 추상화를 이해하기 위해 꼭 필요한 Property 만을 표현 속성이나 오퍼레이션 목록이 많으면 범주에 따라 Group 으로 분류하여 조직화 관련된 Class 들은 같은 Class 도에 표현
109. 5 장 . 관계 (Relationship) 시작하기 용어와 개념 보편적 모델링 기법 단순 의존 모델링 단일 상속 모델링 구조적 관계 모델링 힌트와 조언
110. 시작하기 관계 란 ? UML 에서 사물 (Thing) 들이 상호 논리적 / 물리적으로 연결되는 것 관계 종류 : 의존 관계 , 일반화 관계 , 연관 관계 특정 프로그래밍 언어와 무관하게 관계를 도해하는 것을 가능하게 하며 관계에서 중요한 부분을 강조할 수 있도록 함 관계 이름 , 연결 대상 , 관계 Property Window open ( ) close ( ) move ( ) display ( ) handleEvent ( ) Event ConsoleWindow DialogBox Control 연관 일반화 의존
111. 용어와 개념 의존 (Dependency) 사용 관계로써 한 사물의 명세서가 바뀌면 이를 사용하는 다른 사물에게 영향을 미침 Class 문맥에서 한 Class 가 다른 Class 를 Operation 용법에 Parameter 로 사용하는 경우에 주로 활용 사용중인 Class 가 바뀌면 상대 Class 의 Operation 이 함께 영향을 받음 Transaction name playOn (c:Channel) start ( ) stop ( ) reset ( ) Channel Dependency Relationship
112. 일반화 (Generalization) “ is-a kind-of ” 관계 일반화된 사물 (Super type, Parent type) 과 보다 특수화된 사물 (Sub type, Child type) 들 사이의 관계를 표현 Child 객체는 Parent 객체가 사용되는 어느 곳에서나 사용될 수 있음 Shape origin move ( ) resize ( ) display ( ) Square Rectangle corner : Point Circle radius : Float Polygon points : List display ( ) Leaf Class Base Class Generalized Relationship
113. 연관 (Association) “ has-a ” 관계 구조적인 관계로써 특정 사물 객체가 다른 사물 객체와 관계가 있음을 표현 두 Class 가 서로 연결되어 연관이 있다면 한쪽 객체에서 다른 객체로 옮겨 갈 수 있으며 그 반대도 가능 ( 쌍방 연관 ) 역할 (Role name) 표현 Company Person employee employer 역할명 (role name) Company Person Works for Association Relationship name name direction
114. 다중성 (Multiplicity) 표현 집합 연관 (Aggregation) 표현 : “ part-of ” 관계 독자 운영 가능 합성 연관 (Composition) 표현 단독 사용 불가하며 반드시 Super Class(Object) 와 함께 사용 Company Person employee employer 다중성 (Multiplicity) 1 .. * * Company Department Aggregation 1 * Employee Body Composition 1 1
115. 보편적 모델링 기법 단순 의존 모델링 특정 Class 가 다른 Class 를 Operation 에서 Parameter 로만 사용하는 관계 Operation 에서 Parameter 로 상대 Class 를 사용하려는 Class 쪽에서 의존 관계를 표현 CourseSchedule add (c : Course) remove (c : Course) Course Iterator
116. 단일 상속 모델링 구조적 , 행동적 특성을 파악하여 일반화 Class 와 특수화 Class 로 구분하여 작성 Class 집합에서 둘 이상 다수의 Class 에 공통으로 존재하는 책임 , 속성 , Operation 을 파악 파악된 책임 , 속성 , Operation 을 일반화 Class 로 작성 특수화 Class 는 일반화 Class 로부터 상속되도록 관계를 설정 Security presentValue ( ) history ( ) SmallCapStock CashAccount interestRate presentValue ( ) Stock presentValue ( ) Bond presentValue ( ) Property assesment presentValue ( ) LargeCapStock
117. 구조적 관계 모델링 의존 ( 사용 관계 )/ 일반화 ( 부분 관계 ) 관계와 같이 일방적인 관계가 아닌 Class 간에 대등한 관계 한 쌍의 Class 에 대하여 한 객체들로부터 다른 객체로의 왕래가 필요하면 두 Class 사이에 연관 관계를 지정 한 쌍의 Class 에 대하여 한 Class 객체가 다른 Class 객체와 Operation Parameter 이외의 방법으로 교류하면 관계 설정 ( 행동 중심적 관점 ) 각 연관에 대해 다중성 , 역할 명을 표현 한쪽 Class 가 구조적 , 조직적으로 전체가 되고 다른 쪽이 부분 관계와 같이 판단되면 집합 연관으로 표현 Department School Student Course Instructor member 1 .. * * has 1 .. * 1 1 .. * 1 .. * 1 .. * 1 .. * * * 1 .. * 0 .. 1 0 .. 1 attends teaches assignedTo chairperson *
118. 힌트와 조언 UML 에서 관계를 Modeling 하려면 Modeling 대상 관계가 구조적이 아닌 경우에만 의존 사용 일반화는 “ is-a-kind-of” 관계일 때만 사용하며 다중 상속은 집합 연관으로 표현 순환하는 일반화 관계는 표현하지 않도록 유의 일반화 관계를 전체적으로 균형 있게 유지 ( 상속 계층이 너무 깊거나 , 넓지 않도록 ) 연관은 객체간에 구조적 관계가 있을 때 사용 UML 의 관계 도해 직사각형을 이루는 직선이나 사선의 사용 금지 가능하면 관계를 표현하는 선이 서로 교차하지 않도록 사물의 특정한 모임을 이해하기 쉬울 정도의 필요한 만큼의 관계만 표현
119. 6 장 . 공통 메카니즘 (Common Mechanism) 시작하기 용어와 개념 보편적 모델링 기법 주석 모델링 새로운 구성 요소 모델링 새로운 프로퍼티 모델링 새로운 의미 모델링 힌트와 조언
120. 시작하기 UML Mechanism : 분석 / 설계 내용을 쉽게 이해하도록 산출물 작성 명세 (Specification) 장식 (Adornment) 공통 분할 (Common Division) 확장 (Extensibility) UML 확장 Mechanism : 새로운 구성 요소 추가 , 새로운 Property, 의미 지정 스테레오 타입 (Stereotype) 꼬리표 값 (Tagged Value) 제약 (Constraint) 공통 Mechanism 사용 이유 UML 은 다양한 시스템의 산출물을 제공하지만 약간의 변형이나 확장으로 보다 나은 의사 소통이 가능 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. 용어와 개념 장식 (Adornment) Note 주석을 표현하는 Note 는 의미상 아무런 영향을 미치지 못 함 ( 이해를 돕는 단순 설명 ) 다른 장식 이름 있는 칸 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. 스테레오 타입 (Stereotype) UML 에서 제공하는 구조 사물 , 행동 사물 , 그룹 사물 , 주해 사물을 이용한 표현에서 새로운 원시 구성 요소처럼 나타내고 할 때 사용 << meteclass >> ModelElement << exception >> Underflow ! 이름 있는 Stereotype Icon 과 이름 있는 Stereotype HumiditySensor Icon 으로 표시한 Stereotype 요소
123. 꼬리표 값 (Tagged Value) UML 산출물에 새로운 Property 추가할 때 사용 Server {processors = 3} 꼬리표 값 << library >> flower.dll {serverOnly}
124. 제약 (Constraint) 제약을 이용하여 새로운 의미를 추가하거나 기존 규칙을 수정 Model 이 잘 구성되도록 하기 위하여 반드시 지켜야 할 조건들을 지정 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. 보편적 모델링 기법 주석 (Comment) Modeling 주석을 Model 에 둠으로써 개발 과정에서 만들어진 각종 분산 산출물 ( 관찰 기록 , 검토 의견 , 설명 , . . . ) 에 대한 공통 저장소 역할 주석 모델링 방법 문장으로 작성하여 Note 에 담고 관련 요소를 근처에 배치하여 의존 관계를 표현 해당 문맥의 정보에 관한 의사 소통의 필요가 있는 경우에만 표현 주석이 길거나 단순 문장 이상인 경우 별도 문서로 작성하거나 내장 시켜 모델에 표현 Model 이 진화 할 수록 중요한 결정 사항을 기록하되 추론이 불가능한 주석만 남김 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. 새로운 구성 요소 Modeling UML 구성 요소 (Class, Interface, Collaboration, Component, Node, Relation, ..) 들로 불충분한 표현의 어휘 확장 (Stereotype 사용 ) 새로운 구성 요소 모델링 방법 기본 구성 요소로 표현 불가능을 파악 사용할 구성 요소가 없을 경우 스테레오 타입으로 표현 표현하려는 기본 요소에 정의된 이상의 공통 Property 와 의미에 대하여 꼬리표 값과 제약들의 집합으로 정의 Stereotype 요소들이 명백한 시각적 암시를 표현하도록 하기 위하여 새로운 Icon 정의 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. 새로운 Property Modeling 포괄적인 Property 보다 상세하게 새로운 구성 요소의 Property 를 꼬리표 값으로 사용 새로운 Property 모델링 방법 기본 Property 로 표현 불가능을 파악 사용할 Property 가 없을 경우 새로운 Property 를 각 요소나 스테레오 타입으로 추가 - 일반적인 원칙이 적용되며 요소에 정의된 꼬리표 값은 하위 Class 에도 적용 됨 << 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. 새로운 의미 Modeling UML 의 목적은 이해를 쉽게 할 수 있으며 의사 소통을 원할 하도록 하는 것이므로 새로운 부분을 표현해야 할 필요가 있을 경우에는 제약을 사용 새로운 의미 모델링 방법 기본적인 표현으로 표현 불가능하다는 것을 확인 사용할 표현 방법이 없을 경우 의미를 제약으로 작성하고 관련 있는 요소 들을 가까이 둠 의미를 보다 정확히 , 공식적으로 표현하려면 새로운 의미를 OCL(Object Constraint Language) 을 이용하여 기술 member 1 .. * Person Department 1 * * manager { subset}
129. 힌트와 조언 Model 에 Note 를 사용하여 장식하려면 기존 UML 특성으로는 표현할 수 없을 때 요구 사항 , 관찰 기록 , 검토 의견 , 설명 등을 표현 Note 는 단지 참조로 사용하며 진행중인 일의 진척 사항을 추적하는데 사용 Note 를 도해 할 때 장문의 주석은 전체 주석을 담고 있는 문서를 연결하거나 내장하는 장소로 Note 를 활용 Stereotype, Tagged Value, Constraint 를 사용하여 Model 을 확장하려면 몇 개의 표준화 만을 설정하여 Project 에 활용 짧고 , 의미 있는 명칭 사용 정확성이 중요하게 요구되는 부분이면 OCL 을 사용하여 제약 표현식으로 나타내고 그렇지 않으면 자유로운 형상의 문장 사용 Stereotype, Tagged Value, Constraint 를 도해하려면 Graphic Stereotype 은 자제 Graphic Stereotype 은 단순한 표현 , 색 또는 그림자를 활용하고 복잡한 것은 Icon 을 사용
130. 7 장 . 도해 (Diagrams) 시작하기 용어와 개념 보편적 모델링 기법 시스템의 다양한 뷰 모델링 다양한 추상화 계층 모델링 복잡한 뷰 모델링 힌트와 조언
131. 시작하기 도해 (Diagram) 구성 요소들의 집합 ( 사물들과 그 관계 ) 을 Graphic 으로 표현한 것 S/W 분야의 Architecture 를 가시화 , 명세화 , 구축 , 문서화하는 뷰 쓰임새 뷰 , 설계 뷰 , 프로세스 뷰 , 구현 뷰 , 배치 뷰 뷰 모델링 구조적 모델링 : 정적인 사물 모델링 행동적 모델링 : 동적인 사물 모델링 UML 도해 방식 순 공학 (Forward Engineering) 방법 : 모델을 먼저 작성하고 실행 시스템을 구현 역 공학 (Reverse Engineering) 방법 : 실행 시스템으로부터 모델을 재 구축
132. 용어와 개념 System 과 Sub System 특정 목적을 수행하기 위하여 구성된 Sub System 들로 이루어지며 다양한 시각에서 바라본 Model 들의 집합으로 표현 구성 요소들의 모임으로서 요소의 일부는 다른 요소들에게 제공할 행동에 대한 명세를 구성 Architecture 관점에서 View 는 System Model 에 대한 조직과 구조를 투영한 것으로 도해는 요소들의 집합을 Graphic 으로 표현한 것 System 의 정적인 부분 도해 Model 클래스도 (Class Diagram) 객체도 (Object Diagram) 컴포넌트도 (Component Diagram) 배치도 (Deployment Diagram) System 의 동적인 부분 도해 Model 쓰임새도 (Use Case Diagram) 순차도 (Sequence Diagram) 협력도 (Collaboration Diagram) 상태도 (State chart Diagram) 활동도 (Activity Diagram)
133. 보편적 모델링 기법 System 의 다양한 View Modeling System 의 Architecture 를 표현하고 Project 의 기술적인 위험을 표현하기에 가장 좋은 View 를 결정 각 View 의 필수적인 상세를 파악하기위해 만들어야 할 산출물을 결정 Project 계획 시 각 View 에 대해 어떤 도해를 어느 정도 형식적 제어하에 둘 것인가를 결정 몇 가지 도해는 중도에 폐기 할 수 있다는 여유를 갖고 모형화 단순 일체형의 Application Modeling 복잡한 분산 System Modeling 쓰임새 뷰 쓰임새도 설계 뷰 클래스도 , 교류도 프로세스 뷰 불 필요 구현 뷰 불 필요 배치 뷰 불 필요 쓰임새 뷰 쓰임새도 , 활동도 설계 뷰 클래스도 , 교류도 , 상태도 프로세스 뷰 클래스도 , 교류도 구현 뷰 컴포넌트도 배치 뷰 배치도
134. 다양한 추상화 Hierarchical Modeling 추상화 계층을 달리하여 시스템을 표현할 필요가 있을 때 활용 추상화 계층 종류 같은 Model 에 대하여 상세한 정도를 달리하는 방법 초기부터 추상화 계층을 달리하여 Model 을 작성 그러나 한 Model 에서 다른 Model 로 추적이 가능하도록 하는 방법 추상화 계층 Modeling 방법 요구 사항을 고려하면서 제시된 모델로 시작 모형을 필요로 하는 사용자 ( 최종 사용자 , 분석 / 설계자 ) 수준에 맞는 계층을 설정 추상화 수준 결정에 따라 각 사물들을 모델에 표현 구성 요소와 관계 : 도해 목적과 요구에 부합되지 않는 것은 Hide 장식 : 도해를 이해하는데 필수적 구성 요소와 관계에 관한 장식만 표현 흐름 : 행동적 도해의 경우 의도를 이해하는데 필수적인 Message 나 Transit 만 확장 스테레오 타입 : 속성이나 Operation 과 같은 것에 대해 도해의 의도를 이해하는데 필수적인 스테레오 타입 항목만 표현
135. 다양한 추상화 계층 Modeling 방법 요구 사항을 고려하여 각자가 원하는 추상화 계층을 결정하고 각 계층에 맞게 별도 Model 작성 상위 계층의 추상화 Model 에는 단순한 추상화 개념들로 구성 , 하위 계층 추상화 Model 에는 상세한 추상화 개념 포함 다섯 가지 View 준수 시 4 가지 고려 사항 Use Case 와 구현 : 쓰임새 모델의 쓰임새는 설계 모델의 협력으로 추적 Collaboration 과 구현 : 협력을 수행하기 위해 함께 협력하는 Class 의 모임으로 추적 Component 와 설계 : 구현 모델의 Component 들은 설계 모델의 요소 들로 추적 Node 와 Component : 배치 모델의 Node 들은 구현 모델의 Component 들로 추적 상위 추상화 계층도의 교류 : OrderTaker : OrdeFulfillment submitOrder placeOrder acknowledgeOrder
136. 하위 추상화 계층의 교류도 : OrderTaker : CreditCardAgent : OrderFulfillment : BillingAgent acknowledgeOrder processCard submitOrder placeOrder triggerBill See Credit Failure for a variation of this scenario
137. 복잡한 View Modeling 대단히 크고 복잡한 도해를 작성할 때 공통 Pattern 을 파악하여 상위 계층의 협력으로 도해 복잡한 View Modeling 방법 도해의 일부를 감추고 다른 부분을 상세하게 드러내는 방식으로 상위 추상화 계층에서 이러한 정보를 표현할 방법이 없다는 것을 확인 충분히 감추어 표현하였는데도 도해가 복잡하다면 요소들을 Package 로 묶거나 상위 계층의 협력으로 묶는 것을 고려 도해가 복잡하다면 Note 나 색깔을 이용하여 강조 부분을 부각 시킴 전체 도해를 확인하며 공동 Pattern 을 연구
138. 힌트와 조언 도해를 만들 때 도해의 목적은 시스템의 가시화 , 명세화 , 구축 , 문서화 임 도해의 전부를 유지하는 것이 아니라 시스템이 만들어질 떄 활용되고 용도를 마친 도해는 폐기 불 필요하거나 중복된 도해는 작성하지 않음 각 도해가 의도하는 문제를 다루기에 충분하도록 상세하게 표현 원하는 것이 상위의 추상화 계층이 아니라면 도해를 최소한으로 만들지 말아야 구조적 도해와 행동적 도해가 균형을 유지하도록 너무 크거나 적지 않은 범위에서 표현 각 도해에 의미 있는 명칭을 붙이고 의도를 명확하게 표현 형식에 집착하지 않고 작성 구조가 좋은 도해 시스템에서 하나의 View 를 전달하는데 초점을 맞춤 관점을 이해하는데 필수적인 요소만 표현 추상적 계층에 맞는 상세한 정보를 제공 중요한 의미를 사용자에게 정확히 전달될 정도로 복잡하게 구현
139. 8 장 . 클래스도 (Class Diagram) 시작하기 용어와 개념 보편적 모델링 기법 단순 협력 모델링 논리 데이타베이스 스키마 모델링 순 공학과 역 공학 힌트와 조언
140. 시작하기 Class Diagram Class, Interface, collaboration, Relation 을 이용하여 시스템의 정적인 관점들을 가시화하고 구축을 위한 자세한 내용을 명세화 System 어휘와 협력 , Schema 를 Modeling 하는 것이 대부분 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. 용어와 개념 공통 Property Class Diagram 은 특별 도해의 하나이지만 다른 모든 Diagram 들과 공통적인 Property 가 존재 내용 Class Interface Collaboration Relationship(Dependency, Generalization, Association) 공통 사용 Class Diagram 의 정적인 설계 View 작성 방식 System 어휘 Modeling : 시스템화 대상의 추상 개념을 도출하여 추상 개념들 사이의 관계를 명세화 단순 협력 Modeling : 서로 협동적인 행동을 제공하기 위하여 함께 작용하는 Class, Interface, 다른 요소들과의 관계를 가시화하고 명세화 논리 Database Schema Modeling : 시스템 구현 Database Schema 를 Modeling 하기위한 설계의 청사진을 제시
142. 보편적 모델링 기법 단순 협력 모델링 존재하는 Class 들 간의 협력 관계를 명세화 협력 Modeling 방법 Modeling 대상 Mechanism(System 일부의 기능 / 행동 ) 을 파악 각 Mechanism 에 협력을 하는 Class, Interface 등 다른 협력 관계 파악 사물을 검토하기 위하여 Scenario 를 활용 필요 요소들을 채움 : 균형 잡힌 책임 할당 , 구체적인 속성 , Operation 추가 * 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. 논리 Database Schema Modeling Modeling 의 결과로 생성해야 할 Database 구조를 설계 자료 표현에만 초점을 두는 ERD 에 비교하여 행동 모형을 포함하는 상위 집합 물리 Database 에 있어서 논리 Operation 은 Trigger 나 Stored Procedure 로 구현 Schema Modeling 방법 사용된 Class 중에서 단순 Application 으로 끝나는 것이 아닌 것을 파악 파악된 대상을 포함하여 Class Diagram 을 작성하고 꼬리표를 붙여 표시 구조적 상세 내용 ( 속성 ) 을 확정하며 연관 관계 파악 물리적 Database 설계를 복잡하게 하는 공통 Pattern 파악 ( 순화 연관 , 다수 연관 … ) 무결성 유지를 위한 Operation 을 확장하여 Class 의 행동으로 고려 가능하면 CASE Tool 을 이용하여 논리 설계를 물리 설계로 변환
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. 순 공학과 역 공학 순 공학 (Forward Engineering) Model 을 대응 언어에 대응시켜 Code 로 옮기는 절차 순 공학 방법 구현 언어나 선택 언어에 대응 시키는 규칙 파악 선택 언어의 의미에 따라 UML 특성들을 제한적으로 사용 꼬리표 값을 사용하여 구현 언어를 지정 도구의 활용 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. 역 공학 (Reverse Engineering) 특정 구현 언어를 대응시켜 Code 에서 Model 로 옮기는 절차 역 공학 방법 구현 언어 또는 선택 언어로부터 대응 시키는 규칙 파악 도구를 활용하여 역 공학 부분 Code 를 선택 도구를 활용하여 Model 을 질의함으로써 Class Diagram 을 작성
147. 힌트와 조언 구조가 좋은 Class Diagram System 의 정적 설계 View 의 한 관점을 전달하는데 초점 해당 관점을 이해하는데 필수적인 요소들만 표현 추상화 계층에 알맞은 정도의 상세 내용을 제공하고 이해하는데 필수적인 장식만을 사용 중요한 의미를 이해할 수 있을 정도로 복잡하게 Class Diagram 작성 규칙 목적에 맞는 명칭 사용 서로 교차하는 선 ( 관계 표현 ) 을 최소화 하도록 배치 의미적으로 관련 있는 Class 들을 가까운 위치에 배치 시각적 암시를 활용 (Note 또는 색깔 ) 너무 많은 관계를 나타내지 않도록 도해
148. [3] 응용 구조 모델링 9 장 . 응용 클래스 10 장 . 응용 관계 11 장 . 인터페이스 , 타입 , 역할 12 장 . 펙케지 13 장 . 인스턴스 14 장 . 객체도
149. 9 장 . 응용 클래스 (Advanced Classes) 시작하기 용어와 개념 보편적 모델링 기법 클래스 의미 모델링 힌트와 조언
150. 시작하기 다양한 종류의 클래스 클래스는 일반적인 구성 요소인 분류자 (Classifier) 의 한 종류 분류자 (Class) 는 속성 (Class 구조 ) 과 Operation(Class 행동 ) 이라는 Property 외에 다른 응용 특성들을 갖고 다중성 (Multiplicity), 가시성 (Visibility), 용법 (Signature), 다형성 (Polymorphism) 및 다른 특성들을 모형화 Frame header : FrameHeader uniqueID : Long + addMessage(m : Message) : Status # setCheckSum( ) - encrypt ( ) Signature ( 용법 ) 추상 개념 Type Class 범위 Public ( 공용 ) Protected ( 보호 ) Private ( 전용 )
151. 용어와 개념 분류자 (Classifier) 구조적 / 행동적 특성을 설명하기 위한 Mechanism 모형화 할 때 추상 개념의 의미를 파악하기 위해 필요한 상세 수준을 제공할 목적으로 사용 분류자 종류 Class : 동일한 속성 , Operation, Relationship, 의미를 공유하는 객체들의 집합 Interface : Class 나 Component 의 Service 를 명세화 하기 위해 사용하는 Operation 집합 Datatype : 정체성을 갖지 않는 값들의 형식 (Number, Character, Boolean, …) Signal : Instance 사이의 비 동기 자극 통신 Component : System 에서 물리적으로 교체 가능한 부품 (Interface 를 준수하고 실현 ) Node : 실행시의 물리적 요소로써 처리 능력과 다소의 Memory 능력을 갖는 전산 자원 Use Case : System 이 실행하는 일련의 행동에 대한 설명 ( 변이를 포함 ) Subsystem : 요소들의 집합으로써 다른 요소들이 제공하는 행동 명세를 구성
152. Shape origin move( ) resize( ) display( ) Class kernel32.dll IUnknown Interface Datatype Signal << type >> int {values range from -2**31-1 to +2**31 << Signal >> OffHook Component Node egb_server Use Case Subsystem Process loan << subsystem>> Customer Service subsystem
153. 가시성 (Visibility) 해당 속성 , Operation 이 다른 분류자에 의해 사용될 수 있는가의 여부를 지정 가시성 종류 Public ( 공용 ) : 모든 외부 분류자들이 사용 (+) Protected ( 보호 ) : 모든 자식들이 사용 (#) Private ( 전용 ) : 자신만이 사용 (-) Toolbar # currentSelection : Tool # toolCount : Integer + pickItem(i : Integer) + addTool(t : Tool) + removeTool(i : Integer) + getTool( ) : Tool # checkOrphans( ) - compact( ) Public Private Protection
154. 범위 (Scope) 해당 특성이 분류자의 모든 Instance 에 나타나는지 또는 분류자의 모든 Instance 에 대해서 하나의 특성 Instance 만 존재하는가를 지정 대부분의 분류자 특성은 Instance 소유자 범위이며 Classifier 범위는 해당 분류자에 속하는 일부 Instance 들이 공유해야 하는 Private 속성에 흔히 사용 Frame header : FrameHeader uniqueID : Long Class Scope Instance Scope
155. 추상 , 뿌리 , 잎 , 그리고 다형적 요소 (Abstract, Root, Leaf, and Polymorphic Elements) 일반화 관계를 이용하여 Class 계층을 모형화 특수한 것 보다는 일반화된 추상 개념을 상위에 표현 Icon {root} origin : Point display( ) getID( ) : integer{leaf} ArbitraryIcon edge : LineCollection isInside(p : Point) : Boolean RectangularIcon height : Integer width : Integer Button display( ) OKButton {leaf} display( ) 기본 Class 추상 Operation 구체 Operation 추상 Class 다형적 Operation 구체 Class 잎 Class 추상 Class
156. 다중성 (Multiplicity) 하나의 Class 가 갖을 수 있는 다수의 Instance 수 NetworkController 1 consolePort [2..*] : Port 독자 Class 다중성 ControlRod 3
157. 속성 (Attribute) 가장 높은 추상화 수준에서 Class 의 구조적 특성인 속성을 표현할 때는 명칭만을 기술 속성에도 가시성 , 범위 , 다중성 , 타입 , 초기값 , 변경 가능성 등을 지정 가능 속성을 기술하는 UML 의 완전한 문장 [visibility] name [multiplicity] [:type] [=initial-value] [{property-string}] 속성 선언 예제 origin 명칭 + origin 가시성 , 명칭 origin : Point 명칭 , Type head : *Item 명칭 , 복잡한 Type name [0 . . 1] : String 명칭 , 다중성 , Type origin : Point = (0, 0) 명칭 , Type, 초기값 id : Integer {frozen} 명칭 , Property 속성 정의 Property changeable( 변경 ) : 속성값 바꾸는 제약 없음 addOnly( 추가 ) : 하나 이상의 다중성을 가진 속성에 추가만 가능 frozen( 동결 ) : 객체가 초기화된 이후 속성값을 바꿀 수 없음
158. 오퍼레이션 (Operation) 가장 높은 추상화 수준에서는 Operation 명칭만을 기술하지만 여기에 Parameter, Return Type, 동시성 그리고 Operation Property 를 지정 - Operation 의 Signature Operation 을 기술하는 UML 의 완전한 문장 [visibility] name [(parameter-list)] [:return type] [{property-string}] Operation 선언 예제 display 명칭 + display 가시성 , 명칭 set (n : Name, s:String) 명칭 , Parameter getID ( ) : Integer 명칭 , Return Type restart ( ) {guarded} 명칭 , Property Parameter 제공 구문 [direction] name : type [ =default-value] Operation 적용 Property isQuery ( 질의 ) : Operation 실행 후 System 상태 변화 없음 sequential ( 순차 ) : 객체 외부에서 서로 협조하여 객체 안에 한번에 하나의 흐름만 존재 guarded ( 보호 ) : Operation 에 대한 모든 호출을 순차적으로 관리 ( 의미 , 무결성 보장 ) concurrent ( 동시 ) : 여러 제어흐름이 존재해도 각 Operation 을 원자적으로 처리 ( 의미 , 무결성 보장 ) direction 값 : in (input parameter 로 변경 불가 out (output parameter 로 호출자와 정보 변경 가능 ) inout (input parameter 로 변경 가능 )
159. 템플릿 클래스 (Template Class) Template : Parameter 로 된 요소 일반 Class 와 마찬가지로 사용할 수 있는 구체 Class 로써 직접 사용할 수는 없고 객체화 ( 형식 Parameter 를 실 Parameter 로 Binding) 시켜야 함 예제 - Map 이라는 Parameter Class 를 선언하는 C++ Code template <class Item, class Value, int Buckets> class Map { public : virtual Boolean bind (const Item&, const Value&) ; virtual Boolean isBound (const Item&) const ; . . . } ; ] 위 Template 을 이용한 Customer 객체의 Order 객체 대응 m : Map <Customer, Order, 3> ;
160. Template Class OrderMap Map + bind(in i : Item; in v : Value) : Boolean + isBound(in i : Item) : Boolean {isQuery} Item Value Buckets : int Map<Customer, Order, 3> <<bind>> (Customer, Order, 3) 명시적 결합 묵시적 결합 Template Parameter
161. 표준 요소 꼬리표 값을 사용하여 Class Property 를 확장하고 새로운 Component 를 지정하기 위해 Stereotype 을 활용 4 가지 표준 Stereotype metaclass : 객체가 모두 Class 인 분류자 powertype : 객체가 모두 주어진 Parent 의 Child 인 분류자 stereotype : 분류자가 stereotype 이며 다른 요소에 적용 utility : 속성과 Operation 이 모두 Class 범위를 갖는 Class
162. 보편적 모델링 기법 Class 의미 모델링 추상 개념을 파악하고 그들이 갖는 의미를 명세화 하는 것 Class 의미를 모형화 하기 위하여는 비 정형인 것부터 정형적인 것 까지 명세화 Class 의 책임을 기술 Class 의미를 구조화된 문장으로 표현하고 Semantic 으로 Stereotype 화 하여 Note 에 표현 Method 의 몸체를 구조화된 문장이나 Programming 언어로 기술하여 Note 레 표현하고 의존 관계를 사용하여 Operation 에 첨부 Operation 선행 / 종료 조건을 기술하고 구조화된 문장으로 Class 전체 불변 값 기술 Class 상태 Machine 을 기술 Class 를 대표하는 협력을 기술 각 Operation 의 선행 / 종료 조건을 기술하고 OCL 등의 정형적 언어를 사용하여 Class 의 전체적 불변 값 기술
163. 힌트와 조언 좋은 구조의 분류자 구조적인 동시에 행동적인 관점을 포함 응집도는 강하고 결합도는 약하게 Class 사용자에게 꼭 필요한 특성만 나타나도록 의도와 의미가 명확하게 과도하게 기술하여 구현의 자유를 배제하지 않도록 부족하게 기술하여 분류자의 의미가 모호하지 않게 UML 에서 분류자 도해 방법 문맥에서 추상 개념을 이해하기 위해 필요한 분류자의 Property 만 나타냄 분류자의 의도를 가장 잘 표현하는 시각적 효과를 제공하는 Stereotype Version 을 선택
164. 10 장 . 응용 관계 (Advanced Relationship) 시작하기 용어와 개념 보편적 모델링 기법 복잡한 관계 모델링 힌트와 조언
165. 시작하기 응용 관계 (Advanced Relationship) 사물들 사이의 연결 표현 ( 관계 설명의 3 가지 구성 요소 ) 의존 (Dependency) 일반화 (Generalization) 연관 (Association) Interface 와 Class, Component 그리고 Use Case 와 Collaboration 간의 연결 관계 Modeling 표현 ( 관계 설명의 4 번째 구성 요소 ) 현실화 (Realization) <<interface>> URLStreamHandler openConnection( ) parseURL( ) setURL( ) toExternalForm( ) Controller EmbeddedAgent SetTopController authorizatioLevel startUp( ) shutDown( ) connect( ) PowerManager Channellterator 다중 상속 현실화 <<friend>> Stereotype 의존 연관 운항
166. 용어와 개념 의존 (Dependency) Class 와 Object 들 사이의 의존 관계에 적용할 Stereotype bind( 결합 ) : 실 Parameter 를 이용하여 Source 가 Target Template 을 Object 화 하는 것 derive( 파생 ) : 대상으로부터 Source 를 계산 가능 friend : Source 는 대상에 대하여 특별한 가시성을 갖음 instanceOf : Source Object 가 대상 분류자인 Instance instantiate : Source 가 대상 Object 를 생성 powertype : Object 들 모두가 특정 Parent 의 분류자 refine( 정제 ) : Source 가 대상보다도 추상화 정도가 더 세밀 use( 사용 ) : Source 요소의 의미가 공용 부분이 갖는 의미에 의존 Package 사이의 의존 관계에 적용할 Stereotype Access( 접근 ) : Source Package 는 대상 Package 요소들에 대해 참조 권한을 갖음 Import ( 수입 ) : 대상 Package 의 공용 내용들이 Source 내에 정의된 것과 같이 참조 권한을 갖음 Use Case 사이의 의존 관계에 적용할 Stereotype extend( 확장 ) : 대상 Use Case 가 Source Use Case 의 행동을 확장 include( 포함 ) : Used : Source Use Case 가 명시적으로 다른 Use Case 의 행동을 Source 가 지정하는 위치에 포함
167. Object 간 교류 Modeling 을 위한 Stereotype become( 변화 ) : 대상 Object 가 Source 와 같으나 일정 시간 경과 후 다른 값 , 상태 , 역할을 갖음 call( 호출 ) : Source Operation 이 대상 Operation 을 호출 copy( 복사 ) : 대상 Object 가 똑 같으나 독립적인 복사본임을 표현 상태 Machine 문맥에서 사용하는 Stereotype send( 전송 ) : Source Operation 이 대상 사건을 전송하는 것 System 요소들을 조직화하여 Sub System 과 Model 로 만드는 문맥에서 사용하는 Stereotype Trace( 추적 ) : 대상이 Source 의 과거에는 상위 임
168. 일반화 (Generalization) 일반적인 사물 (Parent, Super-Class) 과 이것의 특수화된 사물 (Child, Sub-Class) 사이에 맺어지는 관계 상속 (inheritance) : Super-Class 의 구조와 행동을 물려 받는 것 단일 상속 : 하나의 Parent Class 로부터 상속 다중 상속 : 두개 이상의 Parent Class 로부터 상속 InterestBearingItem InsurableItem 다중 상속 단일 상속 Asset BankAccount RealEstate Security CheckingAccount SavingAccount Stock Bond 다중 상속
169. 일반화 관계의 Stereotype Implementation( 구현 ) : Child 가 Parent 의 구현을 상속하지만 이를 공용으로 지정하지 않고 Interface 를 지원하지 않아 대체 가능성을 위반 일반화 관계의 제약사항 Complete( 완전 ) : Parent 의 모든 Child 가 Model 에 지정되어 더 이상 Child 가 추가 될 수 없음 Incomplete( 불완전 ) : Parent 의 모든 Child 가 Model 에 지정되지 않아 Child 가 더 추가 될 수 있음 Disjoint( 배타적 ) : Parent Object 가 한 가지 Child Type 만 포함 Overlapping( 겹침 ) : Parent Object 가 한 가지 이상의 Child Type 을 포함
170. 연관 (Association) 한 사물의 Object 들이 다른 사물의 Object 들과 맺어지는 관계 운항 (Navigation) : 하나의 객체에서 다른 객체로의 연결 표현 가시성 (Visibility) : 연관의 외부 객체에 해당 연관의 가시성을 제한할 때 사용 수식 (Qualification) : 연관의 한쪽 객체에서 다른 쪽의 객체 ( 객체 집합 ) 를 찾는 수식자 표현 User 연관 운항 Password 1 * 연관 Owner User 연관 운항 Password 1 * 연관 + Owner UserGroup * * + User - Key WorkDesk 수식자 Password 0 .. 1 * 연관 jobID : Int
171. 인터페이스 지정자 (Interface Specifier) : Class 에 의해 구현되는 Interface 는 해당 Class 의 행동에 대한 완전한 명세서이나 연관 문맥에서 Source Class 의 일부만 표현 복합 연관 (Composition) : 일종의 집합 연관으로써 전체 쪽에서 강력한 소유권을 갖고 다른 부분들은 전체와 동시에 생성되고 소멸 Interface 지정자 Person 1 * 연관 worker : IEmployee supervisor : IManager Window 복합 연관 Frame 1 * 전체 부분
172. 연관 (Association) Class : 두 Class 의 연관에서 연관 자체가 Property 를 포함 제약 (Constraint) : 의미상 더 상세한 표현을 필요로 할 때 연관 관계에 적용하는 제약 implicit( 암시 ) : 관계가 실제적이 아닌 개념적 관계 ordered( 정렬 ) : 객체 집합이 명백한 순서를 갖음 changeable( 변경 ) : 객체 연결 Link 가 추가 , 삭제 , 변경이 가능 addOnly( 추가만 ) : 연관의 반대쪽 객체로부터 새로운 Link 연결 가능 frozen( 동결 ) : 연관의 반대쪽 객체로부터 Link 가 한번 연결도면 수정 , 삭제 불가능 Company 연관 Class Person * 1 .. * employee employer Job description dateHired salary
173. 현실화 (Realization) 분류자들 사이의 의미적 관계로써 한 분류자가 다른 분류자의 수행해야 할 계약을 지정 현실화는 Interface 와 Collaboration 에서 사용 Interface 와 이에 대한 Operation 이나 Service 를 제공하는 Class 나 Component 사이의 관계를 지정하기 위해 사용 현실화 AccountBusinessRules 정규형 <<interface>> IRuleAgent addRule( ) changeRule( ) explainAction( ) 생략형 Acctrule.dll IRuleAgent Validate user Validation
174. 보편적 모델링 기법 복잡한 관계 모델링 추상 개념들 각각의 명확한 경계를 설정한다는 것은 어려운 일이며 이들의 보다 복잡한 관계들을 설정한다는 것은 더욱 어려운 작업임 ( 응집도는 높고 결합도는 낮게 ) 복잡한 관계 Modeling 추상 개념들 사이의 관계를 발견하려 노력 구조적 관계들을 Modeling 하면서 시작 일반화 / 특수화 관계를 파악하며 다중 상속은 적게 사용 앞 단계들의 의존 관계를 확인 고급 특성을 적용 시 의도를 표현해야 할 절대적 요구가 있을 때 표현 하나의 도해나 뷰 보다는 시스템 관계들을 서로 다른 뷰 들로 분산시켜 표현
175. 힌트와 조언 구조가 좋은 관계 Client 가 관계를 사용하는데 필요한 특성만을 나타냄 의미와 의도가 모호하지 않게 표현 과도하게 지정하여 구현의 자유를 제약하지 않도록 부족하게 지정하여 관계의 의미가 모호하지 않게 관계 도해 문맥에서 추상 개념을 이해하기에 필요한 관계의 Property 만 표현 관계 의도를 잘 표현하는 시각적 암시를 제공하는 Stereotype 을 이용
176. 11 장 . 인터페이스 , 타입 , 역할 시작하기 용어와 개념 보편적 모델링 기법 시스템 이음매 모델링 정적 타입과 동적 타입 모델링 힌트와 조언
177. 시작하기 인터페이스 (Interface) System 내의 이음매를 가시화 , 명세화 , 구축 , 문서화하기 위하여 사용 Operation 들의 모임 하나의 Class 나 Component 들이 제공하는 Service 를 명세화 하기 위해 사용 타입 (Type) 과 역할 (Role) 특정한 문맥에서 Interface 에 대한 추상 개념의 정적 / 동적 일치 여부를 Modeling 할 수 있도록 하는 Mechanism 을 제공 Type 은 Class 의 Stereotype 의로써 Operation 들과 함께 객체의 영역을 지정하기 위해 사용 Role 은 특정 문맥에 포함되어 있는 실체 행동을 표현 Interface wordsmith.dll ISpelling IUnknown IThesaurus Component
178. 용어와 개념 명칭 (Name) 다른 Interface 와 구분하기 위한 고유의 문자열을 갖음 단순 명 (Simple Name) 과 경로 명 (Path Name) 오퍼레이션 (Operation) Interface 는 Class 나 Component 의 Service 를 명세화 하기 위하여 사용하는 Operation 들의 모임에 명칭을 붙이는 것 Operation 들은 가시성 Property, Stereotype, 꼬리표 값 , 제약 등으로 장식 단순 명 ISpelling IUnknown ISensor 경로 명 Networking::IRoute Isensors::ITarget Operation <<interface>> URLStreamHandler openConnection( ) parseURL( ) setURL( ) toExternalForm( ) Stereotype
179. 관계 (Relationship) Class 와 마찬가지로 일반화 , 의존 , 연관 관계가 있음 실체화 관계에도 참여하며 두 분류자 사이의 의미적 관계로 대상 분류자가 책임지고 수행 해야 할 계약을 지정 하나의 Interface 는 하나의 계약을 명세화하고 의무를 준수하는 범위에서 독자적 변경 가능 Interface <<interface>> Observer update( ) 의존 TargetTracker Tracker 현실화 ( 단순형 ) Observer Java::Util::Observable Target id currentPosition setPosition( ) setVelocity( ) expectedPosition( ) TargetTracker 현실화 ( 확장형 )
180. Interface 이해하기 각 Operation 에 대한 선행 / 종료 조건 , 그리고 Class 나 Component 에 대한 전체적인 불변 값 명시 State Machine 을 이용하여 Interface 의 Operation 들에 대한 순서를 명세화 Collaboration Diagram 을 활용하여 협력을 표현 함으로써 Interface 가 제공할 행동을 명세화 Type 과 Role Type : Class 의 Stereotype 으로써 Object 들의 영역을 명세화 하기 위하여 사용 Role : 특정 문맥에 참여하는 실체의 행동에 명칭을 붙인 것 e : Employee 연관 1 .. * * Person <<interface>> Employee getEmploymentHistory( ) getCompensation( ) getBenefits( ) Company Class Interface
181. 보편적 모델링 기법 시스템 이음매 모델링 (System Seams Modeling) System 의 이음매를 파악하는 것은 Architecture 의 명확한 경계선을 파악하는 것을 포함하여 경계선의 양쪽에 독립적으로 상대편에 영향을 미치지 않으며 변경 가능한 Component 들을 파악하는 것 System 의 이음매 Modeling 방법 Class 와 Component 들의 집단에서 다른 Class 또는 Component 와 밀접하게 결합되는 경향이 있는 것들의 주위를 선으로 둘러쌈 변경에 대한 영향을 고려하며 함께 변경될 수 있는 Class 와 Component 들을 협력으로 표현 경계를 통해 전달되는 Operation 이나 Signal 을 고려하여 표현 논리적으로 연결된 Operation 아나 Signal 들을 Interface 로 묶음 System 내의 협력들에 대하여 의존 Interface(Import) 와 제공 Interface(Export) 를 파악 각 Interface 에 대해 동적 활동을 문서화하되 Operation 들의 선행 / 종료 조건과 쓰임새와 상태 Machine 을 문서화
183. 정적 (Static) Type / 동적 (Dynamic) Type Modeling Object 의 정적 성질 Modeling 은 Class Diagram 으로 가시화하지만 Workflow 를 거치며 역할을 바꾸는 Business Object 와 같은 사물은 명시적으로 Object Type 의 동적 성질을 Modeling 하는 것이 유용할 수 있음 Dynamic Type Modeling 추상 개념의 구조와 행동을 필요로 한다면 객체의 서로 다른 형태를 Type Stereotype 을 이용하여 Class 로 지정 추상 개념이 행동만을 요구한다면 Interface 로 지정 Object 의 Class 가 취할 모든 역할들을 Modeling 교류도에서 동적으로 타입을 결정하는 Class 와 Instance 를 표현 Object 의 역할이 변하는 것을 나타내기 위해 교류 속에서 Object 가 수행하는 역할 하나에 한번씩 나타내고 become Stereotype Message 로 이 Object 들을 연결 Person <<type>> Candidate <<type>> Employee <<type>> Retiree p : Person [Candidate] p : Person [Employee] :HRDepartment 6 : << become>> 5 : hire( ) Static Type Modeling Dynamic Type Modeling
184. 힌트와 조언 구조가 좋은 Interface 모든 필요한 Operation 을 제공하되 하나의 Service 를 명세화 하기에 충분하고 단순하며 완전하게 Interface 를 사용하고 실체화 하기에 충분한 정보를 제공할 만큼 이해하기 쉽게 사용자에게 주요 Property 를 나타내는 정보를 제공하되 Operation 들의 상세한 내용이 너무 복잡하지 않고 접근이 쉽도록 Interface 를 그릴 때 단순 이음매는 Class 가 아닌 Component 에 사용 Service 자체의 상세한 내용을 가시화 하려면 확장된 형태를 사용
185. 12 장 . 패키지 (Package) 시작하기 용어와 개념 보편적 모델링 기법 요소 그룹 모델링 아키텍쳐 뷰 모델링 힌트와 조언
186. 시작하기 패키지 (Package) Modeling 의 다른 요소 (Class, Interface, Component, Node, Collaboration, Use Case, 다른 Package) 들을 Group 으로 조직화하는 범용 Mechanism 으로써 이해가 쉽게 요소들을 의미적으로 가깝게 모으고 함께 변화 가능하도록 Package 는 매우 느슨하게 결합되고 응집도는 매우 높으며 Package 내용물에 대한 접근은 제어가 매우 엄격 명칭 Sensor fusion
187. 용어와 개념 명칭 (Name) 다른 Package 와 구분하기위한 문자열의 명칭을 갖음 Class 와 마찬가지로 꼬리표 값으로 장식하거나 , 상세한 내용을 표현하기 위하여 추가 칸을 사용 소유된 요소 (Owned Element) 소유는 복합 관계로써 해당 요소가 Package 안에 선언되어야 함 서로 다른 종류의 요소들이 같은 Package 내에서 같은 명칭 사용 가능 Package 는 다른 Package 소유 가능 System 의 구성 요소들이 시간 변화에 따른 속도가 다른 진화를 가능하도록 Package 내부의 내용을 명시적으로 문자나 그림으로 표현 가능 단순명 Business Rules + OrderForm + TrackingForm - Order Client 확장 Package Sensors::Vision {version = 2.24} 경로명 포함하는 Package 명 Package 명
188. 소유된 요소 (Owned Element) 소유는 복합 관계로써 해당 요소가 Package 안에 선언되어야 함 서로 다른 종류의 요소들이 같은 Package 내에서 같은 명칭 사용 가능 Package 는 다른 Package 소유 가능 System 의 구성 요소들이 시간 변화에 따른 속도가 다른 진화를 가능하도록 Package 내부의 내용을 명시적으로 문자나 그림으로 표현 가능 Text 중첩 Client Graphic 중첩 + OrderForm + TrackingForm - Order + OrderForm + TrackingForm - Order Client
189. 가시성 (Visibility) Package 가 소유하고 있는 요소는 공용 (Public) 임 : 해당 요소가 소속된 Package 를 Import 하고 있는 Package 의 내용물들은 이 요소들을 활용할 수 있다는 것 보호 (Protected) 또는 전용 (Private) 으로 지정 가능하며 명칭 앞에 “ #” 와 “ -” 사용 수입 (Import) 과 수출 (Export) 서로 다른 Package 에 존재하는 요소들이 각 Package 에 Public 으로 선언되어 있어도 각 Package 는 서로를 활용 할 수 없음 Import 는 한 Package 에 속한 요소들이 다른 Package 의 요소들에 대해 일 방향 접근을 허용 Export 는 Package 내의 Public 부분을 지칭 + OrderForm + TrackingForm - Order Client 수입 + OrderRules - GUI::Window Policies + Window + Form # EventHandler GUI + Database + LoggingService Server 수출 <<import>> <<import>>
190. 일반화 (Generalization) Package 의 관계 종류 Import : 접근 Dependency 로써 한쪽이 수출한 것을 다른 한쪽이 수출한 것을 Package 요소로 수입 Generalization : Package 들의 계열 (Family) 을 지정하는데 사용 표준 요소 꼬리표 값을 사용하여 Class Property 를 확장 Package 에 적용하는 Stereotype façade( 겉보기 ) : 다른 Package 에게 View 를 제공하기만 함 framework : Pattern 으로 구성된 Package stub( 절단 ) : 다른 Package 의 공용 내용물에 대한 대리자 역할을 수행 subsystem : 전체 시스템의 독립적인 일부분을 대표하는 Package system : Modeling 하려는 전체 시스템을 대표하는 Package MacGUI 일반화 + GUI::Window + Form # GUI : EventHandler + VBForm WindowsGUI + Window + Form # EventHandler GUI
191. 보편적 모델링 기법 요소 그룹 (Element Group) Modeling Class 는 문제 영역이나 해법에 존재하는 사물들을 추사화 하는 반면 Package 는 Model 의 사물들을 조직화하는 Mechanism Group Element Modeling 방법 개념적으로 또는 의미적으로 가까운 요소들의 집합을 파악 이 집합을 Package 로 표현 Package 에 대해 오부의 접근을 허용하는 요소 파악 (Public, Protect, Private 지정 ) 외부 Package 에 의존하는 Package 들을 명시적으로 Import Dependency 를 표현 Package 가 Family 를 이룰 경우 Generalization 관계 표현 User Services <<import>> Business Services Data Services <<import>>
192. 아키텍쳐 뷰 (Architecture View) Modeling View 는 System 의 조직과 구조에 대한 투영이며 System 의 특별한 관점에 초점을 둔 것으로 System 의 교차 (orthogonal) 를 Package 로 분해 Architecture View Modeling 방법 문제 영역의 중요한 Architecture View 파악 : Design( 설계 ), Process( 프로세스 ), Implementation( 구현 ), Deployment( 배치 ), Use Case ( 쓰임새 ) View 의 파악 View 의미를 가시화 , 명세화 , 구축 , 문서화하기에 필요한 요소들을 Package 에 배치 필요하다면 구성 요소들을 더 작은 Package 로 구성 다른 View 에 속한 요소간의 의존 관계 표현 Design View Implementation View Process View Deployment View Use Case View
193. 힌트와 조언 구조가 좋은 Package 응집도가 높으며 관련 요소들의 경계가 명확할 것 결합도가 느슨하여 다른 Package 들로부터 꼭 필요한 요소들만 Export, Import 되게 중첩도가 복잡하지 않도록 Package 크기가 적절한 크기가 되도록 Package 작성시 단순한 Package Icon 사용 Package 내용물 표현 시 문맥에서 Package 의미를 이해하는데 필요한 요소만을 표현 형상관리 중인 사물들을 Modeling 하기위한 Package 인 경우 Version 과 관련 꼬리표 값 표현
194. 13 장 . 인스턴스 (Instance) 시작하기 용어와 개념 보편적 모델링 기법 구체 인스턴스 모델링 프로토타입 인스턴스 모델링 힌트와 조언
195. 시작하기 인스턴스 (Instance) Instance 와 Object 는 같은 개념임 추상 개념의 구체적 실상이며 Operation 집합을 적용할 수 있고 Operation 효과를 저장하고 있는 상태를 포함 실 세계에 존재하는 구체적 사물이나 Prototype 의 사물들을 Modeling keystrokes : Queue : Frame 명칭이 있는 Instance 익명 Instance
196. 용어와 개념 추상 개념과 Instance Instance 는 혼자 존재하지 않으며 항상 추상 개념과 연결 Instance 는 Object Diagram, Interaction Diagram, Activity Diagram 에 포함하여 Modeling Instance 분류자는 정적인 특성을 갖으며 추상 개념이 바뀌는 것이 가능 명칭 (Name) 다른 Instance 와 구분하기 위한 명칭을 갖음 명칭 종류 단순명 (Simple Name) 경로명 (path Name) : 추상 개념의 명칭에 그것이 존재하는 Package 명을 덧붙인 것 :Multimedia::AudioStream myCustomer 다중 Object Instance 단독 Instance t : Transaction : keyCode Agent : 익명 Instance 명칭 포함 Instance Path
197. Operation Object 는 공간적 내용을 포함하여 해야 할 Object 에 대한 실행 Operation 들은 객체의 추상 개념 안에 선언 Operation 의 상속 계층에 따른 다형적 호출 가능 상태 (State) 정적인 Property 와 동적인 각 Property 의 현재 값을 포함 객체의 속성들과 모든 집합체 부분들을 (Aggregate Parts) 포함 객체 상태를 가시화 하는 것은 특정 시간과 공간 상에 주어진 순간의 상태 값을 명세화 하는 것 객체에 대한 Operation 을 수행하면 그 상태는 변화가 발생 myCustomer Id : SSN = “432-89-1783” active = True 속성 값 포함 Instance c : Phone [WaitingForAnswer] 명시적 상태 포함 Instance
198. 다른 특성 활성 Class 선언 가능 : Process View 를 구성하는 Process 와 Thread 를 표현 링크 (Link) : 객체간 의미적 연결 Class 범위의 Attribute 와 Operation 표준 요소 Object 와 Class 사이의 의존 관계 표현 Stereotype instanceOf( 인스턴스 ) : 고객 객체가 공급 분류자인 Instance instantiate( 인스턴스화 ) : 고객 Class 가 공급 Class 의 객체를 생성 함 Message 와 상태 전이 관계의 Stereotype become( 변화 ) : 현재는 아니지만 일정 기간 ( 시간 ) 이 지난 후 공급 객체와 대상 객체가 같음 copy( 복사 ) : 공급 객체와 대상 객체가 똑 같지만 독립적인 본사 본 임 Object 에 적용할 표준 제약 transient( 일시 ) : 한 역할 Instance 가 교류 실행 중 생성되었다 소멸되는 것 r : FrameRenderThread Active Object << exception>> e : Overflow Stereotype Instance
199. 보편적 모델링 기법 구체 Instance Modeling Instance 들 사이의 구조적 관계 표현 구체 Instance Modeling 방법 Modeling 하려는 문제 영역을 가시화 , 명세화 , 구축 , 문서화하기 위한 Instance 파악 UML 객체들을 Instance 로 표현 (Object 에 명칭 부여 ) Modeling 하기에 필요 / 충분한 Instance 에 Stereotype, Tagged Value, Attribute 표현 Instance 들과 이들의 관계를 Object Diagram 으로 표현하거나 해당 instance 를 적절한 다를 Diagram 으로 표현 current : Transaction << instanceOf>> primaryAgent [working] Transaction FraudAgent
200. Prototype Instance Modeling Prototype Object : 개념적 객체 또는 실 세계에서 결과적으로 필요하게 될 대역 객체 Prototype Instance Modeling 방법 Modeling 대상 문제 영역을 가시화 , 명세화 , 구축 , 문서화하기 위한 Prototype Instance 파악 UML 객체들을 Instance 로 표현 (Object 에 명칭 부여 ) Modeling 하기에 필요 / 충분한 Instance 에 Attribute 표현 Instance 들과 이들의 관계를 Interaction Diagram 또는 Activity Diagram 으로 표현 a : CallingAgent 1 : create c : Connection t1 : Terminal t2 : Terminal 2.1 : startBilling 2 : enableConnection 1.1 : add 1.2 : add
201. 힌트와 조언 구조가 좋은 Instance 특정 추상 개념과 명시적으로 관련 문제나 해법 영역 어휘에서 추출한 고유한 명칭 Instance 그릴 때 문맥에서 명확하지 않으면 Instance 의 추상 개념에 대한 명칭을 표기 Instance 의 Stereotype, Role, State 를 표현하되 문맥에서 Object 를 이해하기에 충분한 정도를 표현 속성과 그 값의 목록이 커지면 각 분류에 따라 개별 Group 화
202. [4] 기본 행동 모델링 15 장 . 교류 16 장 . 쓰임새 17 장 . 쓰임새도 18 장 . 교류도 19 장 . 활동도
203. 15 장 . 교류 (Interaction) 시작하기 용어와 개념 보편적 모델링 기법 제어 흐름 모델링 힌트와 조언
204. 시작하기 교류 (Interaction) 어떤 목적을 달성하기 위하여 Object 간에 교환되는 Message 들로 구성 System 의 동적인 측면을 모형화 특정 Object 에서 다른 Object 로 전달되는 Message(Operation 호출 , Signal 전송 , 다른 Object 생성 / 소멸 명령 ) 를 표현 교류를 사용하여 제어 흐름을 모형화하며 제어 흐름은 Operation 내에 있거나 Class,Component, Use Case, 또는 System 전체에 표현 교류의 모형화 방법 시간 관점에서의 Message 순서를 강조하는 방법 Object 의 구조 관점에서 Message 순서를 강조하는 방법 t : AirTrafficPlanner p : FlightPlan 1 : getPositionAtTime(t) Sequence No. Message Object Link 1.1 : getLastCheckpoint( )
205. 용어와 개념 교류는 목적을 달성하기 위해 문맥 내에서 Object 집합간에 교환되는 Message 들의 집합으로 구성된 행동 Message 는 Object 들 간의 의사 소통을 위한 명세서로써 정보 전달 후 후속 활동이 있음 문맥 (Context) Object 들이 Link 되어 있는 곳에는 교류가 존재 교류 내재 문맥 System 이나 Sub System 전체 문맥에 있는 Object 들의 협력에 존재 Object 간의 교류는 Operation 구현에서 표현 됨 Class 문맥에 표현 객체와 역할 (Object & Role) 교류에 참여하는 Object 들은 구체적 사물 또는 Prototype 사물 임 교류의 정적 측면을 표현한 객체도는 함께 동작하는 모든 객체들을 표현하여 교류를 준비하며 객체를 연결한 Link 를 따라 Message 들의 순서를 동적으로 표현
206. 링크 (Link) Object 들의 의미 있는 연결 Link 는 연관의 한 Instance 이며 한 Object 가 다른 Object 또는 자신에게 Message 를 보내는 경로를 명세화 Link 에 추가되는 표준 Stereotype Association ( 연관 ) : 대응 객체가 연관으로 가시적임을 표현 Self ( 자신 ) : 대응 객체가 Operation 의 전송자로 가시적임을 표현 Global ( 전역 ) : 대응 객체가 내포 범위 내에 존재함을 표현 Local ( 지역 ) : 대응 객체가 지역 범위 내에 있음을 표현 Parameter ( 매개 변수 ) : 대응 객체가 Parameter 임을 표현 p : Person : Company Assign(development) Message Link 이름있는 객체 이름없는 객체 Person + setCompensation(s:Salary) + assign(d: Department) . . . Company Employee Employer * 1 .. * Class 연관 Operation
207. 메시지 (Message) Object 간의 대화를 명세화 (Object 가 활동을 계속 수행한다는 가정하에 정보 이동 ) Message 전달 시 결과 활동은 실행 가능한 명령문으로써 연산 Procedure 를 추상화 시킨 형태를 취함 활동의 모형화 Call ( 호출 ) : 객체 내에 있는 Operation 호출 Return ( 반환 ) : 호출자에게 값을 반환 Send ( 발송 ) : : 신호를 객체에게 보냄 Create ( 생성 ) : 객체를 생성 Destroy ( 소멸 ) : 객체를 소멸 c : Client : TicketAgent p : PlanningAssistant Object << create>> Setltinerart(i) calculateRoute( ) route << destroy>> notify( ) 생성 호출 반환 소멸 발신 실 매개변수 호출 ( 지역 호출 ) 반환 값
208. 순차화 (Sequencing) Message 의 흐름은 순차 형태 임 한 Object 가 다른 Object 에게 Message 를 보내면 수신 객체는 또 다른 객체에게 Message 를 다시 보내고 그 수신 객체는 또 다른 객체에게 Message 를 다시 보냄 System 에 있는 각 Process 와 Thread 는 제어 흐름을 구별시켜 정의하고 , 각 흐름 내에서 Message 들은 시간별로 순서가 있음 Procedural Sequence Flat Sequence : View : Cache 2 : clickAt(p) 순차 번호 c : Controller 2.2 : putRecentPick(l) 2.1 : l = findAT(p) Message 중첩 제어 흐름 c : Caller : Exchange 1: lifeHandset( ) : Telephone 2 : assertCall( ) 평면 제어 흐름
209. 생성 , 수정 , 소멸 (Creation, Modification, Destruction) Object 나 Link 가 교류 시간 동안의 변화 New ( 생성 ) : Instant 나 Link 가 교류 시간 내 실행 중에 생성 Destroyed ( 소멸 ) : Instance 나 Link 가 교류 시간 내 실행이 완료되기 전에 소멸 Transient ( 일시 ) : Instance 나 Link 가 교류 시간 내 실행 중에 생성되고 완료 전에 소멸 표현 (Representation) 교류와 Object 와 Message 를 가시화하는 방법 순차도 (Sequence Diagram) : Message 의 시간적 순서를 강조 Object Lifeline 을 Modeling 협력도 (Collaboration Diagram) : Message 를 주고 받는 Object 들의 조직 구조 표현 교류하는 Object 들 간의 Link 구조를 Modeling
210. 보편적 모델링 기법 제어 흐름 모델링 교류 사용 목적 : 전체 System 행동 특징을 제어 흐름으로 Modeling 하는 것 제어 흐름 모형화 방법 교류 문맥 설정 교류 단계 설정 연결 Link 식별 Object 간의 Message 명세화 보충 설명 추가 시간별 제어 흐름 p : StockQuotePublisher s1 : StockQuoteSubscript s2 : StockQuoteSubscript attach(s1) attach(s2) notify( ) update( ) getState( ) update( ) getState( )
212. 힌트와 조언 좋은 구조의 교류 단순하고 같이 작업하는 Object 를 모음 문맥이 분명한 Operation, Class, 전체 System Object 간의 교류를 표현 시간과 자원 간 최적 균형으로 효율적 행동을 표현 교류 요소 중 변경 가능성이 있는 고립 요소를 쉽게 수정하여 적응성이 좋음 부 적절한 부분이 없고 모호한 표현이 없는 이해성이 좋은 표현 UML 에서 교류도 도해 방법 교류에 강조를 두는 것을 선택 ( 시간에 따른 Message 순서를 강조 ) 해당 문맥에서 교류를 아는데 중요한 Object 특성만 표현 해당 문맥에서 교류를 아는데 중요한 Message 특성만 표현
213. 16 장 . 쓰임새 (Use Case) 시작하기 용어와 개념 보편적 모델링 기법 요소의 행동 모델링 힌트와 조언
214. 시작하기 쓰임새 (Use Case) System 전체나 Use Case 일부 행동을 명세화하고 순차적으로 발생하는 활동들을 기술 행동 순차 모임을 설명하며 순차는 System 외부의 행위자와 핵심 추상 개념 간의 교류를 표현 Use Case 는 대상 행동을 명세화만을 수행하고 행동 수행 방법은 규정하지는 않음 모든 행동을 Use Case 로 모형화하며 Use Case 의 실현과는 무관하게 명세화 순차적으로 발생하는 활동들을 기술하며 , 변이를 가질 수 있음 행동은 System 수준에 있는 기능들로써 요구 사항 분석 시 System 이 수행해야 할 활동을 가시화 , 명세화 , 구축 , 문서화하는 도구 Use Case 특성 Use Case 는 행위자와 System 간의 교류를 표현 가시적인 작업을 수행 전체 System 에서도 활용 LoanOffice Process loan 명칭 Actor Use Case
215. 용어와 개념 명칭 (Name) Use Case 는 명칭을 부여하여 다른 Use Case 와 구분 명칭 종류 단순명 (Simple name) 경로명 (Path name) Use Case 와 행위자 (Actor) Actor 는 Use Case 와 교류할 때 Use Case 사용자들의 역할을 표현 Actor 는 Use Case 에 연관 관계를 이용하여 연결 표현 Actor 와 Use Case 는 서로 대화하며 Message 를 주고 받음 Commercial Customer Customer Actor 일반화 Place Order 단순명 Validate User Sensors:: Caliblate location 경로명
216. Use Case 와 사건 흐름 Use Case 는 System 이 무엇을 해야 하는 가를 설명하며 , 어떻게 하는가는 명세화 하지 않음 System 의 내부 관점과 외부 관점 간의 관심사를 명백히 분리 표현 Use Case 행동을 명세화 하려면 사건 흐름을 문장으로 설명 사건 흐름 작성시 Use Case 가 언제 , 어떻게 시작 / 종료 되는지를 표현 언제 Actor 와 교류하며 , 변경 객체와 기본 행동 흐름 , 대안 행동 흐름도 표현 Use Case 와 Scenario Scenario 는 기본적인 Use Case 의 한 Instance 임 하나의 Use Case 는 하나의 Sequence 가 아닌 여러 개의 Sequence 를 한꺼번에 설명하므로 이러한 순차 집합표현을 하는 흐름을 각각의 순차로 표현하는 것
217. Use Case 와 Collaboration Use Case 는 System 이 수행 해야 할 행동만을 파악하고 구현은 고려하지 않으므로 Class 와 다른 요소들로 구성된 공동체를 생성하여 함께 표현되도록 Use Case 행동을 구현 Use Case 조직하기 Class 와 마찬가지로 Package 에 분류 조직 가능 Use Case 는 Generalization, Include, Extend 관계를 명세화 하여 조직 일반화 (Generalization) Class 일반화와 마찬가지로 Child Use Case 는 Parent Use Case 의 행동과 의미를 상속 받음 Child 는 Parent 가 갖는 행동에 추가될 수 있으며 Parent 가 표현되는 곳은 Child 로 대체 가능 포함 (Include) 기본 Use Case 가 다른 Use Case 행동을 명시적으로 수용하는 것을 의미 포함된 Use Case 는 기본 Use Case 일부로만 Instance 를 작성할 수 있음 Place Order 실체화 Order Management Collaboration Use Case
218. 포함 관계는 위임을 뜻하며 System 이 수행해야 할 책임들을 정한 후 해당 Use Case 에서만 획득 가능하며 다른 Use Case 에서도 기능이 필요하면 해당 책임 집합을 포함시킴 의존 관계로써 Stereotype “Include” 로 표현 확장 (Extend) 기본 Use Case 에서 간접적으로 명시한 곳에서 다른 Use Case 행동을 암시적으로 편입 기본 Use Case 가 확장될 수 있는 지점을 Extension Point 라 하며 미리 정해지므로 예측 가능 사용자가 선택적으로 보는 System 행동 특별한 조건에서만 수행되는 부 흐름을 별도로 모형화 의존 관계로써 Stereotype “Extent” 로 표현 Place Order Extension points set priority 확장 관계 << extend>> (set priority) Place rush order Check Password Retinal Scan Validate User Track Order << include>> << include>> 확장점 일반화 포함 관계
219. 보편적 모델링 기법 요소의 행동 모델링 행동을 모형화 하는 것은 요소가 무엇을 하는가에 초점을 맞춤 Use Case 중요 이유 Use Case 로 요소 행동을 모형화 하면 최종 사용자 , 분석가 , 개발자간의 의사 소통이 수단으로 활용 Use Case 는 개발자 들이 요소에 접근하여 사용되는 방법을 이해할 수 있는 방향을 제시 개발 기간 중에 진화하면서 각 요소를 Test 할 수 있는 기초로 활용 요소 행동 모형화 방법 요소와 교류하는 Actor 를 식별 일반화된 역할과 특수화 된 역할을 식별하여 Actor 를 조직 Actor 가 요소와 교류하는데 중요한 것을 파악 Actor 가 요소와 교류할 때 예외적 방법 파악 Use Case 로 행동을 조직하되 포함과 확장 관계를 적용하여 공통 행동은 분해하고 예외 행동을 파악
220. Ship order Extension points materials ready << extend>> Bill customer Validate customer Ship partial order Place order Track Order << include>> << include>> << include>>
221. 힌트와 조언 좋은 구조의 Use Case 행동 명칭은 단일 명칭 , 식별 가능 명칭 사용 Use Case 가 포함하고 있는 행동을 공통 행동으로 분해 변이성 행동을 구별하여 다른 Use Case 에 확장을 표현 Event 흐름을 명확히 하여 쉽게 알 수 있도록 Use Case 의미가 정상인 것과 변이적인 것을 초소한의 Scenario 로 명세화 Use Case 도해 방법 전체 System 이나 일부 System 문맥에서 행동을 파악하는데 중요한 Use Case 만을 표현 Use Case 와 관련 있는 Actor 를 표현 Use Case 와 Use Case, Use Case 와 Actor, Actor 와 Actor 사이의 관계를 명세화
222. 17 장 . 쓰임새도 (Use Case Diagram) 시작하기 용어와 개념 보편적 모델링 기법 시스템 문맥 모델링 시스템 요구사항 모델링 순공학과 역공학 힌트와 조언
223. 시작하기 Use Case Diagram System 이 해야 할 행동을 명세화 System, Sub-System, Class 의 각 요소 행동을 모형화 하는 도구로써 요소 이용법을 파악하고 , 개발자가 요소를 구현 가능하도록 하는 도구 Use Case Diagram 은 Use Case, Actor, 이들 간의 Relation 을 표현 Place phone call Receive phone call Use scheduler Place conference call Receive additional call << extend>> << extend>> Use Case System 경계 User Cellular network Actor 연관 (Association) 확장 (Extend)
224. 내용 Use Case, Actor, Relationship (Dependency, Generalization, Association) Use Case Diagram 에는 Package 가 있어 Model 에 존재하는 요소들을 더 큰 단위로 Modeling 할 수 있음 공통 사용 System 문맥을 Modeling 하는 경우 전체 System 을 큰 사각형으로 표현 System 밖에 Actor 를 배치 (Actor 의 역할도 표현 ) System 과의 교류 표현 System 요구 사항을 Modeling 하는 경우 System 이 행 해야 하는 일을 명세화 ( 방법은 표현하지 않음 ) System 의 외부에 존재하는 것과 외부에서 발생하는 일 그리고 일에 대한 반응은 볼 수 있으나 System 내부에서 작동하는 방법은 볼 수 없음 용어와 개념
225. System 문맥 Modeling System 외부에 존재하는 것 (Actor) 과 System 과의 교류를 명세화 System 문맥 Modeling 방법 System 으로부터 도움을 받아 Task 를 수행해야 할 Group 을 식별하여 Actor 를 식별 Actor 중에서 유사한 것이 존재하면 일반화 / 특수화 계층으로 조직 Actor 를 Stereotype 으로 표현하여 이해에 도움을 줌 Use Case Diagram 에 식별된 Actor 를 표현하고 Actor 로부터 Use Case 에 대화 경로 명시 보편적 모델링 기법 Perform card transaction Process customer bill Reconcile transactions Manage customer account Customer Credit Card Validation System Corporate customer Individual customer Retail institution Sponsoring financial institution
226. System 요구 사항 Modeling 요구 사항은 System 의 설계 특성 , Property, Behavior System 요구 사항 Modeling 방법 System 외부의 Actor 를 식별하여 System 문맥을 설정 Actor 별로 System 에 요구하는 내용 / 행동을 파악 공통 행동을 Use Case 로 만들고 명칭을 붙임 공통 행동을 분해하여 새로운 Use Case 를 만들고 다른 곳에서도 사용 가능하도록 확장 Use Case, Actor, Relationship 을 Modeling 하여 Use Case Diagram 작성 Perform card transaction Process customer bill Reconcile transactions Manage customer account Customer Credit Card Validation System Retail institution Sponsoring financial institution Report on account status Detect card fraud Manage network outage
227. 순공학과 역공학 Use Case Diagram 순공학 Diagram 에 있는 각 Use Case 마다 사건 흐름과 예외 사건 흐름을 식별 시험을 깊이 있게 하려면 각 흐름별 시험 Script 를 생성 Use Case 와 교류하는 각 Actor 를 대표하는 Test 기초 생성 Use Case Diagram 이 적용되는 요소를 배포할 때마다 Tool 을 사용하여 Test Use Case Diagram 역공학 System 과 교류하는 Actor 파악 Actor 별로 Actor 가 System 과 교류하는 방법을 파악 Actor 별로 관련 있는 실행 System 에서의 사건 흐름을 추적 관련되는 흐름들을 묶고 적절한 Use Case 명칭을 부여 Actor 와 Use Case 로 Use Case Diagram 을 도식하고 Relationship 을 설정
228. 구조화가 좋은 Use Case Diagram System 의 정적인 Use Case 관점에서 한 부분의 대화에만 초점을 맞춤 해당 부분을 이해하는데 필수적인 Use Case 와 Actor 만을 포함 추상화 수준별로 일관성 있게 상세 사항을 추가 중요한 의미는 적절한 정도의 크기로 분해 Use Case Diagram 작성법 목적을 알 수 있는 명칭의 사용 교차되는 Line 이 가능하면 최소화 되도록 요소를 배치 행동 , 역할 , 의미가 연관이 있는 것은 인접하여 배치 Note 등의 활용으로 가시적 효과를 이용하여 중요한 특성을 부각 시킴 관계는 너무 많이 표현하지 않고 반드시 필요한 것 만을 표현 힌트와 조언
229. 18 장 . 교류도 (Interaction Diagram) 시작하기 용어와 개념 보편적 모델링 기법 시간적 순서에 따른 제어 흐름 모델링 구조에 의한 제어 흐름 모델링 순공학과 역공학 힌트와 조언
230. 시작하기 교류도 (Interaction Diagram) Object 들과 그들 간의 관계로 구성된 교류를 표현 Object 간 전달되는 Message 를 표현 Class, Interface, Component, Node 들의 실체 Instance 나 Prototype Instance 를 Modeling 하는 것과 관련되고 , 행동을 설명하는 Scenario 문맥에서 구성 요소간에 전달되는 Message 도 포함 교류도 종류 순차도 (Sequence Diagram) 협력도 (Collaboration Diagram) 의미적 동등성 순차도와 협력도는 UML Meta Model 에 있는 같은 정보들로부터 파생된 것으로써 의미상 동등
231. 용어와 개념 내용 교류도에 포함되는 요소 : Object, Link, Message 순차도 (Sequence Diagram) 시간에 따른 Message 발생 순서를 강조 교류를 주도하는 객체를 왼쪽에 배치하여 Message 들을 시간의 흐름에 따라 위에서 아래로 세로축에 따라 배치 Lifeline : 특정 시간 ( 기간 ) 동안 객체가 존재하는 것을 표현 제어 초점 (Focus of Control) 을 두어 객체가 활동하는 시간대를 표현 순차도 한 개는 제어 흐름 한 개만을 표현 Message c : Client : Transaction p : ODBCProxy { transient} << create>> setActions(a,d,o) setValues(d, 3.4) setValues(a, “CO”) committed << destroy>> Object Lifeline Focus of Control 시간 객체
232. 협력도 (Collaboration Diagram) 교류하는 Object 들 간의 구조적인 관계를 강조 교류에 나타나는 객체들을 Graph 상의 꼭지 점으로 하여 Link 롤 연결하고 Message 를 순차 번호를 부여하여 표현 순차도와 다른점 Path 를 표현 Sequence Number 를 부여 Message c : Client : Transaction p : ODBCProxy { transient} 1 : << create>> 2 : setActions(a,d,o) 3 : <<destroy>> Object << local>> << global>> Link 2.1 : setValues(d, 3.4) 2.2 : setValues(a, “CO”) Sequence Number Path Stereotype
233. 보편적 모델링 기법 시간적 순서에 따른 제어 흐름 모델링 교류 문맥을 설정 교류에서 역할 관계를 식별하여 교류 단계 설정 객체의 생명선 설정 교류 개시 Message 를 시작으로 후속 Message 를 위에서 아래로 생명선 사이에 배치 교류 의미를 설명하는데 필요한 Property(Parameter) 를 표현 실제 연산이 발생하는 지점을 가시화하려면 제어 초점으로 객체 생명선을 장식 시간 제약이나 공간 제약을 명세화 하려면 Massage 에 시간과 공간의 제약 장식 제어 흐름을 더욱 자세히 명세화 하려면 각 Message 에 선행 조건 , 종료 조건 명시 s : Caller : Switch r : Caller liftReceiver setDialtone( ) { dialing.executionTime < 30 sec} routeCall(s,n) Ring( ) << create>> c:Conversation * dialDigit(d) dialing liftReceiver connect(s) connect(r) connect(r, s) Caller s and r may exchange information after both are connected
234. 구조에 의한 제어 흐름 모델링 교류 문맥을 설정 교류에서 객체 역할을 식별하여 교류 단계 설정 객체 각각의 초기 Property 설정 객체간 Link 의 명세화 교류 시작 Message 로부터 연속되는 Message 를 Link 에 순차 번호를 포함하여 표현 시간 Mark 로 시간 제약 , 공간 제약 표현 제어 흐름의 공식 명세화가 필요하면 선행 / 종료 조건을 각 Message 에 포함 r : RegistrarAgent s : Student registered : False : School 2 : addStudent(s) s : Student registered : False c1 : Course c2 : Course 3.4 : <<become>> 1 : <<create>> 3 : register ( ) <<local>> {self} 3.1 : getSchedule ( ) 3.2 : add(s) 3.3 : add(s) { association} { association}
235. 순공학과 역공학 Interaction Diagram 은 문맥이 Operation 이면 순공학 / 역공학에서 모두 유리 순공학 앞의 예제 ( 협력도 ) 를 자바 Code 로 생성하면 public void register ( ) { courseCollection c = getSchedule ( ) ; for (int I =0 ; I <c.size ( ) ; I ++) c.item (i) . Add(this) ; this.registered = true ; } 역공학 해당 부분이 Registration Operation 을 도구로 실행시키면 그려 낼 수 있음 배치된 System 을 실행하는 것 보다는 모델을 동작시키는 것이 역공학 Model 을 작성하는데 유리
236. 힌트와 조언 구조가 좋은 교류도를 작성 한 가지 측면에만 초점을 맞춘 동적인 면 파악 해당 부분을 이해하는데 필수적인 요소만 표현 추상화 수준에 맞으며 이해하기에 필수적인 장식만 표현 적정한 단위까지 최소화 시켜 작성 교류도 작성 방법 목적을 전달할 수 있는 명칭 부여 시간적 강조이면 순차도 , 구조적 강조이면 협력도 사용 교차 선이 최소화하는 요소 배치 Note 등을 이용한 시각 효과를 표현 분기를 최소화 표현
237. 19 장 . 활동도 (Activity Diagram) 시작하기 용어와 개념 보편적 모델링 기법 워크플로 모델링 오퍼레이션 모델링 순공학과 역공학 힌트와 조언
238. 시작하기 활동도 (Activity Diagram) 순서도의 일종으로 발생하는 활동을 강조 흐름도로써 활동으로부터 활동으로 전달되는 제어 흐름 표현 ( 발생 활동에 초점 ) 객체간 통과 제어 흐름 (Operation) 을 표현 활동은 다시 몇 개의 Action 으로 분리 Select site Commission architect Develop plan Bid plan Do site work Do trade work( ) Finish construction 초기 상태 : Certificate Of Occupancy [completed] 동작 상태 순차적 분기 동시 분할 동시 합류 종료 상태 Sub Machine 이 있는 활동 상태 객체 흐름 [else] [ not accepted]
239. 용어와 개념 동작 (Action) 상태와 활동 (Activity) 상태 동작 (Action) 상태 Object 에 있는 Operation 을 호출 , Object 에 Signal 을 전송 , Object 의 생성 , 소멸을 시키는 일 동작 상태는 더 이상 분해되지 않음 작업 실행 시간은 순간적으로 진행 활동 (Activity) 상태 제어 흐름이 다른 활동 상태들과 동작 상태들의 복합 활동 상태는 더 작은 활동과 동작으로 분해 가능 종료하는데 어느 정도의 시간이 필요 Bid plan Index := lookup(e) + 7 ; 단순 동작 표현식 동작 Do construction ( ) entry / setLock ( ) Process bill (b) 진입 동작 Sub Machine
240. 전이 (Transition) 한 동작이나 활동 상태에서 다른 동작이나 활동 상태로 가는 경로 분기 (Branching) 하나의 전이가 부울식에 근거한 경로 대안으로 두개 이상의 전이로 나뉘는 것 Select site Commission architect 촉발 없는 전이 Release work order 전이식 [ material not ready] Reschedule Assign tasks [ material ready]
241. 분할 (Forking) 과 합류 (Joining) 동기화 막대를 이용하여 동시 제어 흐름을 여러 개로 나누거나 하나로 합하는 전이 표현 Prepare for speech Synch mouth( ) Stream Audio( ) 분할 Gesture( ) Decompress Clean up 합류
242. 구획면 (Swimlanes) 활동도의 활동 상태들을 분리시켜 Group 화 하는 것 유일한 명칭을 갖으며 실세계의 실체를 대표 Request product Customer 구획면 Receive order Sale Process order Warehouse Pull material Ship order Bill customer Pay bill Close order
243. Object 흐름 활동도에 관여하는 사물들을 명세화 Request product Customer 객체 흐름 Receive order Sale Process order Warehouse Pull material Ship order Bill customer Pay bill Close order o : Order [in progress] o : Order [filled] b : Bill [paid] b : Bill [unpaid] 객체 상태
244. 보편적 모델링 기법 Workflow Modeling System 과 협력하는 행위자 관점에서 활동에 초점을 맞추어 개발 대상에 있는 업무 공정을 가시화 , 명세화 , 구축 , 문서화 Workflow Modeling 순서 Workflow 에 초점을 맞춤 전체 Workflow 의 부분들을 상위에서 책임지는 업무 Object 를 선정 초기 상태로 가기 위한 선행 조건과 종료 상태가 되기 위한 조건 식별 시간에 따라 발생하는 활동과 동작을 활동도에 표현 복잡환 활동 , 반복 활동은 활동 상태 단위로 나눈 후 각각을 별도 활동으로 표현 활동이나 동작 상태 등을 연결시켜 전이를 추가 관련 중요 Object 를 활동도에 표현
245. Request return Customer Telesales Accounting Get return No. I : Item [returned] Warehouse Ship item Receive item Restock item I : Item [available] Credit account
246. Operation Modeling 활동도의 문맥에 있는 Operation 의 Parameter 와 Local Object 의 분기 (Branch), 분할 (Fork), 합류 (Join) 등을 활용한 모형화 Operation Modeling 순서 Operation 관련 추상 개념 수집 초기 상태의 선행 조건과 종료 상태의 종료 조건 파악 시간 경과에 따라 활동과 동작 표현 Operation 이 활동 Class 에 소속된 경우 분할과 합류를 사용하여 동시 제어 흐름 명세화 return Point (0,0) [else] x = (l.delta - delta) / slope - l.slope) ; y = (slope * x) + delta return Point (x, y) [slope = l.slope]
247. 순공학과 역공학 활동도 (Operation Modeling) 의 순공학 C++ Code 예제 Point Line :: Intersection (l : Line) { if (slope == l.slope) return Point (0, 0) ; int x = (l.delta - delta) / (slope - l.slope) ; int y = (slope * x) + delta ; return Point (x, y) ; } 역공학은 Code 문맥이 Operation 의 몸체인 경우 구현 Class 로부터 생성 가능 운영 System 에서 Message 들을 전달 시키는 것과 같이 도구로 Message 를 작동 시켜 Model 동작을 관찰
248. 힌트와 조언 구조가 좋은 활동도 System 동적인 면의 한 가지 측면에만 초점을 둠 해당 부분을 이해하는데 필수적인 요소들만 표현 추상화 수준에 맞는 상세성을 일관되게 제공 중요한 의미를 이해하기 적절한 단위로 표현 활동도 작성 방법 목적을 전달할 수 있는 명칭의 부여 주 흐름으로부터 시작하여 전이 , 분기 , 동시성을 표현 ( 하위 활동도를 고려 ) 교차 선이 최소화 하도록 요소를 배치 중요한 부분은 Note, Color 등을 이용하여 시각적 효과 부각
249. [5] 응용 행동 모델링 20 장 . 사건과 신호 21 장 . 상태 머신 22 장 . 프로세스와 쓰레드 23 장 . 시간과 공간 24 장 . 상태도
250. 20 장 . 사건과 신호 (Event & Signal) 시작하기 용어와 개념 보편적 모델링 기법 신호 패밀리 모델링 예외 모델링 힌트와 조언
251. 시작하기 사건과 신호 (Events & Signals) 사건 (Event) 이란 실 세계에서 발생하는 시간과 공간을 점유하는 의미 있는 일 신호란 사건에 발생하는 자극 사건은 동기 또는 비동기로 발생하며 , 사건 Model 은 Process Model 과 Thread Model 로 완성 됨 상태 머신 (State Machine) 문맥에서는 사건을 이용하여 자극이 상태 전이를 발생 시키는 행위를 Model 로 작성 함 . 사건에는 신호 , 호출 , 시간 경과 , 상태 변경 등이 발생 Idle Active OffHook / dropConnection( ) <<signal>> OffHook 사건 사건 선언
252. 용어와 개념 사건 종류 (Kinds of Events) 내부 사건 : System 내부의 Object 간에 발생하는 사건 외부 사건 : System 과 Actor 간에 발생하는 사건 UML 의 사건 Model 종류 Signal Call Pass of Time Change in State 신호 (Signal) 한 Object 에서 비동기 로 전송하면 다른 객체에서 수신하는 것 Signal 은 Class 와 유사하며 Instance 를 만들 수 있고 일반화 관계를 이용하여 사건 계층 Model 을 갖을 수 있음 Signal MovementAgent position velocity moveTo( ) <<signal>> Collision force : Float << send>> Parameter Send Dependency
253. 호출 사건 (Call Events) Operation 이 발생되는 것 ( 동기적 ) 한 Object 가 State Machine 이 있는 다른 Object 에 속한 Operation 을 Invoke( 가동 ) 시키면 Control 은 발송자로부터 수신자로 사건 전이 촉발 Operation 이 완료되면 수신자는 새로운 상태로 전이되며 제어는 발송자로 복귀 시간 (Time) 사건과 변경 (Change) 사건 시간 사건 : 시간의 경과를 나타내는 사건 변경 사건 : 상태의 변경 즉 , 어떤 조건이 만족되는 것을 나타내는 사건 Manual Automatic startAutopilot(normal) Event Parameter Idle Active Change Event after (2 seconds) / dropConnection( ) Time Event when (11:49 PM) / selfTest( )
254. 사건 보내기와 받기 (Sending and Receiving Events) 신호 사건과 호출 사건은 적어도 두 Object 와의 관련 ( 신호를 보내거나 Operation 을 기동 시키는 Object 와 사건이 향하고 있는 Object 가 존재 ) Class 에서 나오는 모든 Instance 는 수신 Object 에게 Signal 을 보낼 수 있고 Operation 을 기동 시킬 수 있으며 Class 의 어떤 Instance 이건 호출 사건 즉 Signal 을 받을 수 있음 KeypadManager Signals pushbutton(b : button) powerUp powerDown 활성 Class Signal
255. 보편적 모델링 기법 신호 패밀리 (Family of Signal) Modeling 사건 중심 System 에서 신호 사건은 계층적 임 신호 계층을 Modeling 하면 다형성 사건을 명세화 할 수 있음 Signal Family Modeling 주어진 활동 Object 가 응답할 수 있는 모든 종류의 신호를 고려 공통으로 사용되는 신호를 파악하여 상속을 이용해서 일반화 / 특수화에 배치 활성 Object 의 State Machine 에서 다형성이 될 수 있는 것을 파악 <<signal>> Collision sensor : Integer <<signal>> RobotSignal <<signal>> HardwareFault <<signal>> BatteryFault <<signal>> MovementFault <<signal>> VisionFault <<signal>> RangingFault <<signal>> MotorStall
256. 예외 (Exception) Modeling 하나의 Operation 이 발생할 수 있는 예외 신호를 명세화 예외도 신호의 한 종류이며 Stereotype Class 로 Model 화 Exception Modeling 각 Class 와 Interface 나 요소들의 Operation 에 대해 발생할 수 있는 예외 조건을 파악 예외들을 계층적으로 배열 각 Operation 에 대하여 예외가 발생할 수 있는 것을 명세화 <<exception>> Exception setHandler( ) firstHandler( ) lastHandler( ) <<signal>> MovementFault <<signal>> VisionFault <<signal>> RangingFault Set add( ) remove( ) item << send>> << send>> << send>>
257. 힌트와 조언 Event Model 만들 때 신호 계층을 구축하여 관련된 신호들에 있는 공통 Property 를 발견 정상 제어 흐름을 대치하면서 신호를 보내거나 예외가 없도록 사건을 수신하는 각 요소마다 합당한 State Machine 이 있는가 확인 사건을 수신하는 요소들을 Modeling 하는 것 외에 사건을 발생하는 요소들을 Modeling UML 로 사건을 표현할 때 사건 계층은 명시적으로 표현하고 사용에 관한 것은 사건을 발송 / 수신하는 각 Class 또는 Operation 의 이면 (Backplane) 에서 Model 을 작성
258. 21 장 . 상태 머신 (State Machine) 시작하기 용어와 개념 보편적 모델링 기법 객체 생명 주기 모델링 힌트와 조언
259. 시작하기 State Machine State Machine 을 이용하여 개별 Object 의 행동 ( 동적인 측면 ) 을 Modeling 하며 이는 Object 가 생명주기 동안 통과하는 State 들을 발생하는 순서대로 명시한 행동이며 Object 는 사건이 도달되면 반응하고 사건에 응답 State Machine 의 두 가지 방법 활동도 (Activity Diagram) : Object 안에서 발생하는 활동에서 초점을 두어 한 활동에서 다른 활동으로 전달되는 Control Flow 를 강조 상태도 (Statechart Diagram) : 사건 요구에 따른 Object 가 취할 수 있는 행동에 초점을 두고 상태들 사이의 전이를 강조 - 반응 System 모형 작성에 유용 Idle Cooling ready / turnOn( ) tooHot(desiredTemp) atTemp Heating Activating Active tooHot(desiredTemp) tooCold(desiredTemp) tooCold(desiredTemp) atTemp Initial State Final State State Event Transition Event Parameter Action Nested State shutDown
260. 용어와 개념 State Machine : 상태가 순차적으로 발생하는 것을 명세화 한 행동이며 Object 는 생명 주기 동안 사건에 따라 상태를 변경해 가며 사건에 대한 응답 수행 State : Object 가 생명 주기 동안 가질 수 있는 조건 ( 상황 ) 이며 특정 조건이 만족된 상태에서 활동을 수행하고 사건을 기다림 Event : 시간과 공간에서 위치를 점유하고 있는 중요한 발생 명세서로써 자극이 발생되며 상태 전이를 촉발 Transition : 두 상태 간의 관계로써 특정 상태에 있던 Object 가 동작을 수행한 후 사건이 발생하고 정해진 조건이 만족되었을 때 다음 상태로 전환 Activity : State Machine 안에서 비 원자성으로 실행 Action : 실행될 수 있는 원자성 연산으로 Model 상태를 변경하거나 Return 값을 발생 문맥 (Context) Object 가 생명 주기 동안에 다른 Object 에 작용할 수 있고 , 작용 받을 수 있는 동기적인 것을 포함하며 이들 Message 들은 단순한 동기 Operation 을 호출 State Machine 은 신호를 받을 수 있는 Class 들의 Instance 와 활동 Object 도 포함 비 동기적 자극이 오면 응답해야 하는 Object 행동이나 객체의 현 행동이 과거에 의존하는 경우 State Machine 을 이용하여 명세화 하는 것이 바람직
261. 상태 (State) Object 생명 주기 동안에 가질 수 있는 특정 조건 ( 상황 ) 이며 해당 기간 동안 Object 는 조건이 만족된 상태에서 활동을 수행하고 다른 사건도 기다림 상태의 구성 명칭 (Name) : 특정 상태와 다른 상태를 구분 짓는 문자열로 구성된 이름 진입 / 탈출 동작 (Entry/Exit Action) : 상태에 들어오거나 나갈 때 수행되는 동작 내부 전이 (Internal Transition) : 상태 변경을 초래하지 않고 처리되는 상태 내의 전이 하위 상태 (Substate) : 중첩 (Nested) 구조로 된 상태이며 배타적 하위상태 ( 순차적 활성화 ) 나 동시적 하위 상태 ( 동시적 활성화 ) 지연 사건 (Deferred Event) : 사건 목록으로써 현 상태에서 처리되지 않고 다른 상태에서 처리하기 위하여 대기 Queue 에 저장되는 사건 초기 상태와 종료 상태 Idle Running 상태 명칭 shutDown keyPress finished
262. 전이 (Transition) 특정 Object 가 현 상태에서 어떤 동작을 수행한 후 지정된 상태가 발생하고 지정된 조건이 만족되었을 때 다음 상태로 들어가는 두 상태간의 관계 전이의 5 부분 원래 상태 (Source State) : 전이에 의해 바뀌는 상태 촉발 사건 (Event Trigger) : 원래 상태의 객체가 한 사건을 받았을 때 조건이 만족되어 전이를 합당하게 수행할 수 있는 조건 전이 조건 (Guard Condition) : 촉발 사건이 수신되어 전이 촉발 시에 검토되는 Boolean 식 (True 이면 수행 ) 동작 (Action) : 실행 가능한 원자성 연산 , Object 에 직접 또는 간접적으로 발생하는 작용 목표 상태 (Target State) : 전이가 완료된 후의 활성 상태 Idle Engaging 사건 Trigger shutDown After (2 seconds) / send c.isAlive contact Searching Engaging Tracking targetAt(p) [isThreat] / t.addTarget(p) noise 시간 사건 재귀 전이 매개 변수 있는 사건 Trigger 전이 조건 동작 전송 신호 Trigger 없는 전이
263. 상태와 전이의 응용 (Advanced States & Transitions) 행동 모형이 복잡해질 때 활용 고급 특성 진입 / 탈출 동작 (Entry/Exit Action) : State 에 들어갈 때 진입 동작 실행 , State 를 떠날 때 탈출 동작 실행 내부 전이 (Internal Transition) : 재귀 전이와는 차이가 있으며 상태 내부에서 접하는 사건들을 처리하되 상태를 벗어나지는 않음 활동 (Activity) : Object 가 한 상태에 있을 때 유휴 상태에서 사건 발생을 기다리거나 진행중인 행동을 Model 화 하는데 한 상태에 있는 동안은 상태에서 어떤 일을 수행하며 이는 Event 가 도달하면 Interrupt 가 발생 됨 지연 사건 (Deferred Event) : 특정 사건이 동작되기 전에는 다른 사건들이 연기 ( 대기 ) Tracking entry / setMode(onTrack) exit / setMode(offTrack) newTarget / tracker.Acquire( ) do / followTarget selfTest / defer 명칭 진입 동작 내부 전이 지연 사건 탈출 동작 활동
264. 하위 상태 (Substate) 단순 (Simple) 상태 : 하위 구조를 갖지 않는 상태 복합 (Composite) 상태 : 하위 상태를 포함하는 중첩 (Nested) 상태 복합 상태는 동시 ( 직교성 (orthogonal)) 하위 상태 또는 순차 ( 배타적 (Disjoin)) 하위 상태를 포함 순차 하위 상태 (Sequential Substate) Active 순차에 있는 모두로부터 나오는 전이를 한꺼번에 표현 순차 하위 상태들은 복합 상태의 사태 공간을 분할하여 배타적 상태가 됨 Idle Maintenance [ continue] Active Activating maintain Selecting Processing Printing cardInserted cancel [ not continue] entry / readyCard exit / ejectCard 복합 상태의 전이 복합 상태 순차 하위 상태 하위 상태로부터의 전이
265. 이력 상태 (History State) Object 가 복합 상태를 떠날 때 활동한 마지막 하위 상태를 기억하고 있는 Object Model 을 만들 필요가 있을 때 사용 Command 첫번째 진입의 초기 상태 BackingUp Collecting Copying CleaningUp query H 얕은 (Shallow) 이력 상태
266. 동시 하위 상태 (Concurrent Substate) 포함된 Object 들의 문맥에서 동시적으로 실행되는 State Machine 이 두개 이상 나타낼 때 사용 동시 하위 상태는 실행이 병렬도 진행되다 각 중첩 State Machine 이 종료 상태에 도달 Idle Maintenance Testing devices Testing Self diagnosis Testing devices Self diagnosis Commanding [ continue] [ not continue] keyPress maintain 분할 (fork) 합류 (join) 동시 하위 상태 복합 상태
267. 보편적 모델링 기법 Object 생명 주기 (Lifetime) Modeling Interaction 은 함께 작동하는 Object 들의 행동 Modeling 에 활용하며 , State Machine 은 한 Object Lifetime Modeling 으로 Class 의 Instance, Use Case, 전체 System Model 의 사용자 Interface, Controller, Device 등을 대상으로 함 Object Lifetime Modeling State Machine 의 문맥을 설정 (Class, Use Case, 전체 System 을 대상 ) Object 의 초기 / 종료 상태 설정 Object 가 응답할 수 있는 Event 파악 초기 상태에서 시작하여 종료 상태에 이르기까지의 Object 상태들을 배치 진입 동작과 탈출 방법을 식별 각 상태들을 하위 상태를 이용하여 필요한 만큼 확장 State Machine 에 표현된 각 사건들이 Object Interface 에서 예견되는 사건들과 부합되는지 확인 State Machine 에 표현된 각 Action 들이 Object 를 내포한 관계와 Method, Operation 에 의해 유지되는지를 점검 State Machine 을 Trace 하면서 예견되는 사건 순차와 응답을 보면서 확인 State Machine 을 재 배치한 후에 예견되는 순차를 보면서 다시 점검하며 Object 의미가 바뀌지 않았는지를 확인
269. 힌트와 조언 구조가 좋은 State Machine 단순하며 State 나 Transition 이 과다하지 않을 것 문맥이 분명하며 내포된 Object 에서 가시적인 모든 Object 에 접근 가능 시간과 자원을 동작 요구에 최적으로 활용되도록 System 에 존재하는 어휘로 State 나 Transition 명칭을 사용하여 이해하기 쉽도록 과다한 중첩을 피할 것 동시 하위 상태를 많이 사용하지 말 것 ( 활용 Class 사용 ) UML 로 State Machine 을 표현할 때 가능하면 Transition 이 교차하지 않도록 복합 상태를 확장할 때는 Diagram 을 이해하기 쉽게 하는 범위로 한정
270. 22 장 . 프로세스와 쓰레드 (Process & Thread) 시작하기 용어와 개념 보편적 모델링 기법 다중 제어 흐름 모델링 프로세스간 통신 모델링 힌트와 조언
271. 시작하기 Process 와 Thread System Model 의 Process View 에 해당 System 의 병렬 및 동기화 Mechanism 을 구성 시키는 Thread 와 Process 를 포함 독립된 각 제어 흐름은 활동 객체 (Active Object) 로 Modeling 하며 제어 활동을 주도할 수 있는 Process 나 Thread 로 구성 Process : 비교적 큰 흐름의 표현으로 다른 Process 와 병행으로 실행 Thread : 비교적 적은 흐름 표현으로 동일 Process 내의 다른 Thread 와 병행으로 실행 BackgroundController currentKnowledgeSource Signals blackboardIsSovned hasAHint Name Active Class Attribute Operation Signal
272. 용어와 개념 Active Object : Process 나 Thread 를 소유하고 있는 Object 로써 제어 활동을 주도 Active Class : 자신의 Instance 가 활성 객체인 Class Process : 비교적 큰 흐름의 표현으로 다른 Process 와 병행으로 실행 Thread : 비교적 적은 흐름 표현으로 동일 Process 내의 다른 Thread 와 병행으로 실행 제어 흐름 (Flow of Control) 특정 순간에 발생하는 사건의 진행 순차 System 의 제어 흐름은 한 개이며 동시 System 에서는 두 개 이상 임 Class 와 Event Active Class 도 Class 의 일종이지만 독립적인 제어 흐름을 갖는 다는 점이 다름 Active Object 는 Active Class 의 Instance 로써 Process 와 Thread 를 구현 Active Object 는 비활성 (Passive) Object 가 표현되는 곳이면 어디에서나 활용 가능하며 State Machine 에서 사건의 목표를 표현할 수 있음 표준 요소 (Standard Element) UML 확장 Mechanism 은 모두 Active Class 에 적용 (Tagged Value 활용 ) 적용 표준 Stereotype Process Thread
273. 통신 (Communication) Object 간의 협력은 그들 Message 를 서로 전달하며 교류 교류 방법 비활성 객체 비활성 객체 : Operation 이 단순히 호출되는 것 활성 객체 활성 객체 : 한 활성 객체가 다른 객체 Operation 을 동기로 호출 비동기로 신호를 보내거나 객체 Operation 을 호출 활성 객체 비활성 객체 : 두 개 이상의 활성 객체가 한 순간에 각각의 제어 흐름을 비활성 객체로 통과 시키는 경우 비활성 객체 활성 객체 : 활성 객체에서 활성 객체로 Message 를 통과시키는 것과 동일 Active Object b : Blackboard c : BlackboardController c1 : initialize( ) c2 : startSearch( ) c3 : k.evaluate( ) 1 : hasAHint(k) 2 : placePartialSolution( ) Synchronous Message Asynchronous Message Flow Sequence : KnowledgeSource
274. 동기화 (Synchronization) 흐름이 Operation 을 통과할 때 주어진 한 순간의 제어 자취는 Operation 에 있으며 Operation 이 다른 Object 의 활동을 유발 한 Operation 은 각 제어흐름을 갖을 수 있고 또한 여러 제어 흐름이 존재 가능 한 Object 내에서 여러 제어흐름이 있을 때 서로의 흐름이 방해하지 않도록 순차 (Sequential) : 호출자는 Object 외부와 조정을 하여 한 순간에 단 한 개의 흐름만 존재하도록 감시 (Guarded) : 복수 제어 흐름이 존재할 때 Object 의 감시를 받는 모든 Operation 을 순차화 하여 Object 의미와 무결성 보장 동시 (Concurrent) : 복수 제어흐름이 있을 때 Operation 을 원자성으로 취급하여 객체 의미와 무결성 보장 Process View Active Process 는 System 의 Process View 를 가시화 , 명세화 , 구축 , 문서화 System Process View 는 동시성과 동기화 Mechanism 을 형성하는 Thread 와 Process 를 포함 (System 의 성능 , 신축성 , 처리량 등을 포함 ) Buffer size : integer add( ) {concurrent} remove( ) {concurrent} Name Attribute Operation Synchronization Property
275. 보편적 모델링 기법 다중 제어 흐름 (Multiple Flow of Control) Modeling 복수 제어 흐름을 포함한 System 은 동시 활성 객체의 작업 순서를 결정해야 하며 System 의 활성 객체와 비 활성 객체와의 정확한 통신이 되도록 설계 제어의 다중 흐름 Modeling 동시 활동 가능성을 식별 후 각 흐름을 구체화하여 Active Class 로 구현 Active Class 책임을 균형 있게 분산하고 각 Class 들이 정적으로 협조하고 있는 다른 Active Class 와 Passive Class 를 조사 Active Class 들을 명시적으로 부각시키며 정적인 결정 사항을 획득 각 Class Group 들이 서로 동적으로 협력하는 방법을 파악 Active Class 간에 발생하는 Communication 을 조사 Active Class 와 협력중인 Passive Class 와의 동기화에 주의를 기울여 도식 s : StockTicker s1 : postValue( ) i : IndexWatcher m : AlertManager s : StockTicker i : IndexWatcher t : TradingManager c : CNNNewsFeed s2 : postAlert( ) c1 : postBreakingStory( ) m1 : postAlert( ) i2 : postAlert( ) i1 : postValue( )
276. 프로세스간 통신 (Interprocess Communication) Modeling System 에서 복수로 수용되는 제어 흐름을 상주하는 Object 간에 통신하는 Mechanism 도식 Process 간 통신 Modeling 복수 제어 흐름 Model 작성 활성 객체 중 Process 와 Thread 를 Stereotype 을 이용하여 구분 Message Model 을 비동기 통신으로 하고 동기 통신으로 Remote Procedure Call Model 작성 Note 를 활용하여 하부 통신 Mechanism 을 명세화 <<process>> r : ReservationAgent {location = reservation server} CORBA ORD Server Communicates across Beans messaging service <<process>> t : TripPlanner {location = client} <<process>> h : HotelAgent {location = hotel server} <<process>> t : TicketingManager {location = airline server} Client t1 : planTrip( ) r3 : postResults( ) r1 : make( ) r2 : make( )
277. 힌트와 조언 구조가 좋은 Active Class 와 Active Object 독립 제어 흐름으로 표현하여 System 동시성의 잠재력을 높임 다른 활성 요소들이 복수로 표현될 정도로 적지 않도록 활성 요소들 간의 통신은 동기식과 비동기식 Messaging 을 선택하여 표현 각 Object 를 임계 지역 (Critical Region) 으로 주의 깊게 취급 Process 와 Thread 의미를 명시적으로 구분 UML 로 Active Class 와 Active Object 를 표현할 때 문맥 내의 추상 개념을 이해하기에 충분한 정도의 Attribute, Operation, Signal 들만 표현 모든 동기 Property 를 명시적으로 표현
278. 23 장 . 시간과 공간 (Time & Scope) 시작하기 용어와 개념 보편적 모델링 기법 시간 제약 모델링 객체 분산 모델링 이주 객체 모델링 힌트와 조언
279. 시작하기 시간과 공간 (Time & Space) 시간과 공간 Model 을 만드는 일은 실시간 / 분산 System 에서는 필수 요소이며 시간 표시 , 시간 표현식 , 제약 , 꼬리표 값 등을 포함하여 System 표현 System 의 시간과 공간 특성을 필요 / 충분하게 반영 실시간 분산 System 실 시간 System 분산 System m : MapServer {location = server} a : getMap(region) c : Client {location = console} c : MapCache {location = missionserver} b : getMap(region) { a.executionTime < 10ms} 시간 제약 시간 식 시간 표시 위치
280. 용어와 개념 시간 표시 (Timing Mark) : Event 가 발생하는 시간 표시 시간 표현식 (Time Expression) : 절대 시간 / 상대 시간을 검사하는 표현식 시간 제약 (Time Constraint) : 시간과 관련된 모든 제약 시간 (Time) System 에서 시간상 규칙적 / 비 규칙적으로 발생할 내용 표현 사건에 대한 응답은 예측 가능한 절대 시간이나 사건에 상대적으로 예측 가능한 시간에 표현 c : MIDIController {every 1 ms} c1 : testKeys( ) : KeyCollection k : Key B : MIDIEventBuffer c : MIDITransmitter c2 : testKey( ) c3 : add(k) {every 1 ms} t1 : remove( ) {executionTime < 10ns} 시간 제약
281. 위치 (Location) 여러 지역에 분산되어 있는 System Node 들의 물리적인 Component 들을 표현 Location Tagged Value : LoadAgent {location = Router} <<processor>> KioskServer Deploys vision.exe log.exe selftest.exe Location by Nesting
282. 보편적 모델링 기법 시간 제약 (Timing Constraint) Modeling 시간 제약을 이용하는 실 시간 System 의 Time Critical Property 사건의 절대 시간 Modeling 사건간 상대 시간 Modeling 한 동작을 수행하는데 걸리는 시간 Modeling Timing Constraint Modeling 교류에 있는 각 사건에 대해 절대 시간에 시작되어야 할 대상을 파악 교류에서 관심 대상인 Message 의 각 순서에 대해 연관된 상대 시간을 파악 각 Class 에 존재하는 시간이 급한 Operation 에 대해 시간 복잡성을 파악 P : ServerPage S : SystemAgent C : Camera a : refresh( ) { b.executionTime < 100ns} { a : startTime every 1 ms} b : getImage( ) { getImage.executionTime is proportional to image size.}
283. 객체 분산 (Distribution of Object) Modeling 분산 System Topology 를 만들 때 고려해야 할 Component 와 Class Instance 의 물리적 배치 Object Distribution Modeling System 관심 대상 Object 들에 대해 참조의 지역성을 파악 관련 Object 집합에서 교류 Pattern 을 파악하고 교류 정도가 높은 Object 끼리 모음 Node 별 부하 균형을 고려하여 분산 보안 , 취약성 , Service 품질을 고려하여 Object 분산을 재 배치 배치도의 Node 로 Object 를 중첩 시키거나 꼬리표 값으로 Object 위치를 명시적 표기 o : Order {location = Workstation} s : Sales {location = Workstation} a : ObserverAgent {location = Server} p : Product {location = Server} p : ProductTable {location = DataWarehouse}
284. 이주 객체 (Object that Migrate) Modeling 분산 System 하에서 Class 들이 서로 다를 Node 로 이동 Object 들이 보다 좋은 결과를 산출하기 위해 Node 의 연결 실패 , Node 의 균형 잡힌 부하를 위하여 Object Migrate Modeling 물리적 Object 들을 전송할 기반 Mechanism 선택 한 Node 에 Object 를 할당 시키되 꼬리표 값으로 위치를 명시적 표시 Stereotype Message 인 Become, Copy 를 이용하여 한 Object 를 새로운 Node 에 할당 동기화 문제와 고유성 문제를 숙고 i : Itinerary {location = client server} 4 : tenderBid( ) t : TravelAgent {location = United server} t : TravelAgent {location = SAS server} t : TravelAgent {location = TWA server} t : TravelAgent {location = client server} : Auctioneer {location = United server} : Auctioneer {location = SAS server} : Auctioneer {location = TWA server} 1.1 : << become>> 2.1 : << become>> 3.1 : << become>> 1 : bid( ) 2 : bid( ) 3 : bid( )
285. 힌트와 조언 구조가 좋은 시간과 공간 Property System 행동 요구 획득에 필요 / 충분한 시간 , 공간 Property 만 표현 Property 사용을 중앙에 위치시켜 찾기 쉽고 바꾸기 쉽게 UML 로 시간과 공간 Property 를 표현할 때 시간 표시 (Message Name) 에 의미 있는 명칭 부여 상대 시간 표현식과 절대 시간 표현식을 명확히 구분 공간 Property 는 주로 꼬리표 값으로 표현
286. 24 장 . 상태도 (Statechart Diagram) 시작하기 용어와 개념 보편적 모델링 기법 반응 객체 모델링 순공학과 역공학 힌트와 조언
287. [6] 아키텍쳐 모델링 25 장 . 컴포넌트 26 장 . 배치 27 장 . 협력 28 장 . 패턴과 프레임웍 29 장 . 컴포넌트도 30 장 . 배치도 31 장 . 시스템과 모델
288. [6] 아키텍쳐 모델링 25 장 . 컴포넌트 26 장 . 배치 27 장 . 협력 28 장 . 패턴과 프레임웍 29 장 . 컴포넌트도 30 장 . 배치도 31 장 . 시스템과 모델
289. 25 장 . 컴포넌트 (Component) 시작하기 용어와 개념 보편적 모델링 기법 실행 파일과 라이브러리 모델링 테이블 , 파일 , 그리고 문서의 모델링 API 모델링 소스 코드 모델링 힌트와 조언
290. 시작하기 Component Component 와 Deployment 는 System 의 물리적 관점을 Modeling 하는 중요 요소 실행 File, Library, Table, File, document 같이 Node 에 존재하는 물리적인 요소를 Modeling 하는데 사용 물리적이며 교체 가능한 System 의 한 부분 정의가 명확한 Interface 로 추상 개념 정의하며 새롭고 호환성있는 Component 로 교체하기 쉽게 작성 명칭 kernel32.dll
291. 용어와 개념 명칭 (Name) 다른 Component 와 구분하기 위한 문자열로 된 명칭이 반드시 필요 단일명과 Component 가 속한 Package 명을 앞에 붙인 경로명 사용 Class 와 마찬가지로 Tagged Value 를 사용하며 구획을 추가 가능 Simple Name agent.java fraudagent.dll Realizes FraudAgent FraudPolicy PatternSearch Path Name system::dialog.dll {version = 2.0.1.75} 확장 Component
292. Component 와 Class Component 와 Class 는 매우 유사함 Component Class 명칭 존재 존재 Interface 실현 가능 가능 관계 표현 의존 , 연관 , 일반화 의존 , 연관 , 일반화 중첩 가능 가능 Interaction 참여 가능 참여 가능 추상화 단계 논리적 물리적 추상화 정도 상세 비교적 상세 표현 속성 , 오퍼레이션을 직접 표현 Interface 를 통한 Operation fraudagent.dll FraudAgent FraudPolicy PatternSearch Class Componet
293. Component 와 Interface Interface 는 Operation 의 모음으로써 Class 와 Component 의 Service 를 명세화 하는데 사용 Component 를 함께 묶는 수단으로 Interface 를 사용 Interface 를 통해 Service 를 호출하는 다른 Component 들과 함께 그 Interface 를 실현하는 Component 들을 준비 Interface 간의 관계 표현 생략된 Icon 형으로 표현 Operation 을 나타내는 확장된 형태로 표현 Interface 종류 Export Interface : Component 가 실현하는 Interface 를 말하며 다른 Component 들에 대한 Service 로 제공 Import Interface : Component 가 사용하는 Interface 로써 외부 Component 가 포함한 내용을 의존 사용하는 Interface
294. ImageObserver image.java <<interface>> ImageObserver abort : int{final static} error : int{final static} imageUpdate( ) : Boolean Interface component.java image.java component.java 의존 현실화 Icon 형태 확장 형태
295. 이진 교차성 (Binary Replaceability) Component 기반 Operating System 의 기본 취지는 이진 교차 가능한 부분들로 System 을 조립하게 하는 것 System 을 새로 구축하지 않고 새로운 Component 를 추가하거나 존재하는 것을 교체하여 System 을 발전 시킴 Component 는 Bit 로 된 세계에 있으며 개념적인 것이 아닌 물리적인 것 Component 는 교체 가능 ( 같은 Interface 를 준수하는 다른 것으로 ) 다른 Component 와 협력하면서 Architecture 또는 기술적 상황에서 사용될 목적으로 존재하는 System 의 한 부분 Component 는 전해진 Interface 를 준수하고 구현 Component 종류 배치 (Deployment) Component : 동적 라이브러리 (DLL), 실행 File 과 같은 것으로 실행 가능한 System 구성에 필요 / 충분 한 것 작업 결과 (Work Product) Component : 개발 Process 의 산출물로써 배치 Compo nent 를 생성하는 Source Code File 및 Data File 등이며 개발 작업에서 만들어진 산출물이며 실행 System 을 생성하는데 사용 실행 (Execution) Component : 실행 System 의 수행 결과로 생성되는 Component
296. Component 의 구성 Class 를 구성하는 것과 같은 방법으로 Component 를 Package 에 Group 화하여 구성 가능 Component 간의 의존 , 연관 , 일반화 관계 , 구체화 관계를 명기하여 구성 가능 표준 요소 5 가지 표준 Stereotype Executable( 실행 ) : Node 에서 실행될 수 있는 Component 를 명세화 Library : 정적 / 동적 객체 Library 를 명세화 Table : Database Table 을 나타내는 Component 를 명세화 File : Source Code 또는 Data 를 포함하는 문서를 나타내는 Component 를 명세화 Document( 문서 ) : 문서를 나타내는 Component 를 명세화
297. 보편적 모델링 기법 실행 File 과 Library Modeling System 에 포함되는 다수의 실행 File 과 이들에 연관된 객체 Library 로 구성 실행 File 과 Library Model 구성 방법 물리적인 System 을 어떻게 분할할 것인가를 확인 ( 기술적 , 형상관리 , 재사용 측면 ) 적합한 표준 요소를 사용하여 모든 실행 File 과 Library 를 Component 로 Modeling Component 간 중요한 연결은 Interface 로 Modeling 실행 File, Library, Interface 간의 관계를 Model 에 표현하고 의존성을 Model 에 표현 ( 변화에 대한 영향을 가시화 ) animator.exe {version = 5.0.1} dlog.dll wrfrme.dll render.dll raytrce.dll
298. Table, File, Document Modeling 부수적 배치 Component 로써 Data File, 도움말 File, Script Log File, 초기화 File, 설치 / 제거 File 등 을 Component 로 표현 Table, File, Document Model 구성 부수적 Component 확인 적합한 Stereotype 등을 이용하여 Component 로 Modeling 부수적 Component 들과 실행 File, Library, Interface 간의 관계를 Modeling 하고 의존성을 Model 에 표현 ( 변화에 대한 영향을 가시화 ) animator.exe {version = 5.0.1} dlog.dll wrfrme.dll render.dll raytrce.dll animator.ini animator.hlp Shapes.tbl
299. API(Application Programming Interface) Modeling API 는 Program 형태로 접합되는 부분을 나타내며 Interface 와 Component 를 사용하여 Modeling API Model 구성 System 내에서 Program 형태로 접합되어야 하는 부분을 확인 가시화해야 하는 중요한 Interface Property 만 남김 특정 구현 물을 표현할 때에는 각 API 의 구현 내역을 Model 화 animator.exe {version = 5.0.1} IScripts IRendering IApplication IModels
300. Source Code Modeling Source Code File 의 구성을 Modeling Source Code File 간의 Compile 의존성을 가시화 하거나 개발 경로의 분기 , 결합에 따른 File 을 분할 / 집합 등을 가시화 Source Code Model 구성 Compile 의존성과 더불어 개발 Tool 지정 방식에 따른 논리 요소들의 상세 내역을 저장하는 File 을 확인 Model 들을 형상 관리 및 Version 제어 Tool 과 접목하는 것이 중요하면 꼬리표 값을 이용 개발 Tool 이 File 들의 해당 관계를 관리하도록 하고 이들의 관계를 문서화할 떄 만 UML 이용 render.h {version = 5.3} render.cpp {version = 5.3.7} rengine.h {version = 4.6} poly.h {version = 4.1} colotab.h {version = 4.1}
301. 힌트와 조언 구조가 좋은 Component System 의 물리적인 관점에서 얻어진 것들에 대한 명쾌한 추상 개념 제공 작고 정의가 명확한 Interface 구현 Class 들을 직접 구현하며 해당 Class 들은 Interface 가 갖는 의미를 수행 Component 간의 결합도는 상대적으로 낮으므로 의존 관계와 현실화 관계만 이용 Component 를 그릴 때 Interface 가 제공하는 Operation 을 명시적으로 나타낼 필요가 없으면 Interface Icon 사용 해당 Component 의 의미를 이해하는데 필요한 Interface 만 표현 Library 나 Source Code 와 같은 것은 Version 을 표현하고 Tagged Value 활용
302. 26 장 . 배치 (Deployment) 시작하기 용어와 개념 보편적 모델링 기법 프로세스와 장치의 모델링 컴포넌트 분산 모델링 힌트와 조언
303. 시작하기 배치 (Deployment) Node 는 Component 와 같이 현실 세계의 System 의 물리적 관점을 Modeling 하는데 사용되며 어느 정도의 Memory 와 자체 처리 능력을 갖는 전산 자원을 표현 Node 는 System 이 실행되는 H/W 의 총체적 구조를 Modeling 하는데 사용하며 Component 가 배치될 수 있는 Processor 나 장치를 나타냄 S/W 중심 System 설계 논리적 측면 : Class, Interface, Collaboration, Interaction, State Machine 물리적 측면 : Component( 논리적 및 물리적 요소의 Package 화 ) Node(Component 들이 배치되고 실행되는 H/W 표현 ) egb_server 명칭
304. 용어와 개념 명칭 (Name) 다른 Node 와 구분하기 위한 문자열로 된 명칭이 반드시 필요 단일명 (Simple Name) 과 Node 가 속한 Package 명을 붙인 경로명 (Path Name) Class 와 같이 Node 에 Tagged Value 사용 가능 kiosk_7 sales Deploys pos.exe contacts.exe 단순명 확장 Node 경로명 Server::backup {remoteAdministrationOnly}
305. Node 와 Component Node 와 Component 는 매우 유사함 분산 (Distribution) Unit : 일체의 Object 나 Component 가 하나의 Group 으로 Node 에 위치할 때 sales Node pos.exe contacts.exe Component Component Node 명칭 존재 존재 관계 표현 의존 , 연관 , 일반화 의존 , 연관 , 일반화 중첩 가능 가능 Interaction 참여 참여 가능 참여 가능 실행 구분 System 실행에 참여 Component 실행 표현 서로 다른 논리적 요소들을 물리적으로 Package 화 Component 의 물리적 배치 Instance 포함 포함
306. Node 의 구성 Node 를 Package 로 Group 화 하여 구성 Node 간의 의존 , 일반화 , 연관 관계로 Node 들의 관계 표현 연결 (Connection) Node 간의 관계를 표현하며 연관 관계가 일반적 임 연관 관계는 Ethernet, Serial Line, Shared Bus 등과 같은 Node 간의 물리적 연결을 표현 server console kiosk RAID farm <<10- T Ethernet>> << RS-232>> 연결
307. 보편적 모델링 기법 Processor 와 장치의 Modeling 독립형 System, 내장 System, Client/Server System, Distribution System 등의 형태를 구성하는 Processor(Component 를 수행할 처리 능력을 갖는 Node) 와 장치 ( 처리 능력을 갖지 않는 Node) 를 Modeling Processor 와 장치를 Modeling 하려면 System 의 Deployment View 에 있는 Computing 요소들을 확인하고 각각을 Node 화 일반적인 Process 와 장치를 표현하면 Stereotype 을 적용하여 설명 각 Node 에 적용할 수 있는 Attribute 와 Operation 을 고려 << processor>> server console kiosk RAID farm <<10- T Ethernet>> << RS-232>>
308. Component Distribution Modeling System 을 구성하는 Processor 와 장치들에 설치된 Component 들의 물리적인 분산을 가시화 , 명세화 하여 System 의 전반적인 구조를 Modeling Component 분산을 Modeling 하려면 System 에 존재하는 중요한 Component 를 Node 에 배치 여러 Node 의 Component 들을 중복 배치하는 것을 고려 배치의 방법을 선택 Component 배치를 나타내지 않고 각 Node 의 명세서에만 보존 의존 관계를 사용하여 해당 Node 가 배치하는 Component 와 각 Node 를 연결 Node 를 표시하는 요소에 새로운 구획을 추가하여 배치되는 Component 를 나열 s : server processorSpeed = 300mHz memory = 128M Deploys dbadmin.exe tktmstr.exe c : console Deploys admin.exe config.exe : kiosk Deploys user.exe : RAID farm <<10- T Ethernet>> << RS-232>>
309. 힌트와 조언 구조가 좋은 Node 해결 영역의 H/W 에 나타나는 어휘에서 얻어진 것들의 명확한 추상 개념 제공 Model 을 만든 목적을 전달하기에 필요한 수준까지만 분해 Modeling 하려는 Domain 에 적합한 Attribute 와 Operation 만 표현 Node 에 위치하는 Component 들을 직접 배치 실 System 의 전체 구조를 반영하는 형태로 다른 Node 들과의 연결을 고려 UML 에서 Node 작성시 Project 나 전체 조직을 대상으로 Stereotype 들을 적합한 Icon 으로 정의 주어진 상황에서 해당 Node 의 의미를 이해하기에 적합한 Attribute 와 Operation 만을 표현
310. 27 장 . 협력 (Collaboration) 시작하기 용어와 개념 보편적 모델링 기법 쓰임새 (Use Case) 의 실체화 모델링 오퍼레이션의 실체화 모델링 메커니즘 모델링 힌트와 조언
311. 시작하기 협력 (Collaboration) 협력은 Class, Interface 그리고 다른 요소들로 이루어진 공동체를 말하며 각 부분의 모든 행동을 합한 것 보다 큰 공동의 행동을 제공하기 위하여 함께 동작 협력을 사용하여 Use Case 와 Operation 의 현실화 (Realization) 를 상세히 기술하며 , Architecture 에서 중요한 System Mechanism 을 Modeling 분류자 (Class, Interface, Component, Node, Use Case, …) 나 Operation 과 같은 요소가 실현되는 방법을 기술하는 명세서 실현은 특정 역할을 담당하는 분류자와 그들 간의 연관 관계에 의해 이루어 짐 패턴 (Pattern) : 특정 상화에서 공통적 문제에 대한 공통적 해법 Idiom : Program 을 작성하는 공통 방법 Mechanism : System Architecture 의 개념적인 Group 을 나타내는 설계 Pattern Framework : 특정 Domain 내에서 Application 작성을 위하여 확장 가능한 Template 를 제공하는 Architecture Pattern Inter-node messaging 명칭
312. 용어와 개념 명칭 (Name) 다른 협력과 구분하기 위한 문자열로 된 명칭이 반드시 필요 단일명 (Simple Name) 과 협력이 속한 Package 명을 붙인 경로명 (Path Name) 구조 (Structure) 협력의 두 가지 관점 구조적 부분 : 협력을 수행하기 위해 함께 동작하는 Class, Interface, Component, Node 등과 같은 다른 요소들과의 조합 관계를 표현 행동적 부분 : 요소들이 교류하는 방법의 동적인 관점을 명세화 Interface mailbox * IncomingQueue TransportAgent sender received sendMessage( ) IDistributed Queue addMessage( ) removeMessage( ) count( ) * Role Message ID header body * 1 다중성 연관 의존 일반화 OutgoingQueue
313. 행동 (Behavior) 협력의 행동적인 부분은 Interaction Diagram 으로 표현 교류도는 Message 들로 이루어지는 행동을 나타내고 있는 교류를 명세화하고 Message 들은 지정된 목적을 수행하기 위해 특정 상황에서 Object 들 간에 주고 받는 것 Message : Message : OutgoingQueue : TransportAgent Instance create addMessage Lifeline Focus of Control removeMessage Actor Transport agents periodically remove message from their assigned queues, according to their scheduling policies. Note
314. 협력의 구성 적당한 크기와 정상적인 개수의 협력을 구성해야 협력의 두 가지 관계 현실화 (Realization) 관계 정제 (Refinement) 관계 Place order Order Management Order Validation Collaboration Use Case << refine>> Refinement Realization
315. 보편적 모델링 기법 Use Case 의 현실화 Modeling Use Case 들의 구체적인 구조와 행동을 현실화 Use Case 현실화 Modeling Use Case 가 갖는 의미를 수행하는데 충분하면서 필요한 구조 요소 확인 구조 요소들의 구성을 파악하여 Class Diagram 으로 표현 Use Case 가 나타내는 개별적인 Scenario 를 고려 Scenario 의 동적인 활동을 파악하여 Interaction Diagram 으로 표현 구조 요소와 행동 요소들을 하나의 협력으로 구성하면서 현실화 관계를 이용하여 해당 Use Case 와 연결 Place order Order Management << include>> Validate transaction Generate bill Detect card fraud Customer << include>>
316. Operation 의 현실화 Modeling Object 들이 협조해야 하는 Operation 들에 대하여 Code 화하기 전에 협력을 통한 구현 Model 을 작성하는 것 Operation 특유의 Parameter, Return Value 그리고 Object 들은 해당 Operation 의 현실화에 필요한 상황을 제공 Operation 현실화 Modeling Operation 에 나타나는 Parameter, Return Value, Object 를 확인 일반적인 것이면 Code 형태로 구현하여 Model 과 별개로 기록 유지 또는 Note 이용 Algorithm 집약적이면 Activity Diagram 을 이용하여 현실화를 Model 에 표현 복잡하거나 상세 설계가 필요하면 구현을 협력으로 표현하고 Class Diagram 과 Interaction Diagram 을 활용하여 협력의 구조적 부분과 행동적 부분을 학장 Ray trace return (totalPolygons - renaming) / totalPolygons RenderFrame setContents render progress
317. 힌트와 조언 구조가 좋은 Collaboration 구조적 관점과 행동적 관점 모두로 구성 System 에서 식별이 가능한 교류에 대하여 명쾌한 추상 개념을 제공 다른 협력이 갖는 구조 요소들과 중복되게 표현 이해하기 쉽고 간단하게 UML 로 협력을 그릴 때 다른 협력 , 분류자 , Operation, System 전체에 대한 관계를 이해할 필요가 있을 때에만 협력을 명시 분류자나 Operation 별로 협력을 구성하거나 , System 전체와 연관되는 Package 에 포함
318. 28 장 . 패턴과 프레임웍 시작하기 용어와 개념 보편적 모델링 기법 설계 패턴 모델링 아키텍쳐 패턴 모델링 힌트와 조언
319. 시작하기 패턴과 프레임웍 (Pattern & Framework) Pattern : 주어진 상황에서 공통적으로 발생하는 문제에 대하여 공통적으로 적용할 수 있는 Solution Mechanism : 설계 Pattern 으로써 Class 들로 이루어진 공동체에 적용 Framework : Architecture Pattern 으로써 특정 Domain 의 Application 들을 위해 확장 가능한 Template 를 제공 Pattern 을 이용하여 System Architecture 를 형성하는 Mechanism 과 Framework 을 명세화 Pattern 의 사용자가 조정할 수 있는 동전 구멍 (Slot), 줄 (Tab), 손잡이 (Knob), 숫자판 (Dial) 을 사용하여 접근이 쉽게 작성 Framework <<framework>> Receivable Billing Reconciliation Mechanism
320. 용어와 개념 Pattern 과 Architecture Model-View-Controller Patter 을 사용하여 추상 개념들을 구성하는 것이 좋은 방법 설계 Pattern 은 Class 들로 이루어진 공동체가 갖는 구조와 행동을 명세화 (Mechanism) Architecture Pattern 은 전체 System 의 구조와 행동을 명세 (Framework) Mechanism 설계 Pattern 의 다른 명칭이며 Class 로 이루어진 공동체에 적용 Mechanism 의 두 가지 표현 일부 공통적이고 중요한 행동을 수행하기 위해 함께 동작하는 추상 개념들을 지정 일부 공통적이고 중요한 행동을 수행하기 위해 함께 동작하는 추상 개념들을 Template 으로 지정 Role TaskQueue Observer Subject Observer Template Collaboration Bind SliderBar Subject Observer
321. Framework Architecture Pattern 이며 Domain 에 있는 Application 들을 위한 확장 가능한 Template 을 제공 Mechanism 보다 규모가 크며 Mechanism 을 포함하는 Micro Architecture 의 일종 Framework <<framework>> CyclicExecutive CommonEvents Collaboration EventHandler Client Handler Pacemaker Bind
322. 보편적 모델링 기법 설계 Pattern Modeling 설계 Pattern 은 Parameter 협력으로 표현되며 , Pattern 은 추상 개념을 제공하고 , 추상 개념들이 갖는 구조와 행동은 함께 동작하여 일부 유용한 기능을 수행 Parameter 들은 해당 Pattern 의 사용자가 반드시 결합 시켜 주어야 하는 요소들을 지정 설계 Pattern Modeling 공통적인 문제에 대한 공통 해법을 찾고 이를 Mechanism 으로 구체화 Mechanism 을 구조적이고 행동적인 관점을 제공하는 협력으로 Model 화 지정된 상황에 있는 요소들과 반드시 결합하여야 하는 설계 Pattern 요소들을 확인하고 이들 협력의 Parameter 로 표현 Command Client Command Invoker Receiver Client Application PasteCommand OpenCommand MenuItem Document Command Command Invoker Receiver
323. 설계 Pattern 의 구조적 관점 Modeling Client Receiver action( ) receiver Command execute( ) Invoker addCommand( ) 설계 Pattern 의 행동적 관점 Modeling : Client new c : Command : Invoker : Receiver storeCommand(c) execute( ) action( )
324. Architecture Pattern Modeling Framework 은 Stereotype 으로 지정된 Package 로 표현 , 하나의 Package 로써 필요한 요소 (Class, Interface, Use Case, Component, Node, Collaboration, 다른 Framework) 들을 제공 줄 (Tab) : 요소들 중에서 일부가 공용 (Public) 타입이 되어 Client 가 의존할 수 있는 자원으로 표현 ( 추상 개념들과 Framework 을 연결 ) 동전 구멍 (Slot) : 공용 요소의 일부는 설계 Pattern 이 되고 Client 가 결합하는 자원을 표현하며 이는 설계 Pattern 과 결합할 때 채워짐 요소들 중 일부는 보호 타입 , 전용 타입으로써 Capsule 화 된 Flamework 요소들을 나타내며 이들은 외부 View 에서 접근할 수 없도록 감추어져 있음 Architecture Pattern Modeling 현존하면서 검증된 Architecture 에서 Framework 을 도출 Stereotype 으로 지정된 Package 로 Framework 의 Model 작성 Framework 을 설계 Pattern 과 협력의 형태로 변경하는데 필요한 Slot, Tab, Knob, Dial 을 표현
325. <<framework>> Blackboard Apply new knowledge source Blackboard Knowledge Source Blackboard Control Reasoning engine Knowledge Source
326. 힌트와 조언 구조가 좋은 Pattern 공통적인 방법으로 공통적인 문제를 해결 구조적 관점과 행동적 관점 모두 구성 Slot, Tab, Knob, Dial 을 나타내고 해당 관점들을 다시 표현하여 특정 상황에 적용 가능하도록 원자적 ( 더 작은 Pattern 으로 분할되지 않는 것 ) 구성 System 에 있는 개별적인 추상 내역들을 횡적으로 분할 UML 로 Pattern 을 그릴 때 해당 상황에 적용하기 위해 변경해야만 하는 Pattern 요소들을 표현 Pattern 의 변경은 물론 이를 사용하기위해 필요한 Use Case 를 제공하여 해당 Pattern 에 접근이 용이하도록
327. 29 장 . 컴포넌트도 (Component Diagram) 시작하기 용어와 개념 보편적 모델링 기법 소스 코드 모델링 실행 배포판 모델링 물리적 데이터베이스 모델링 적응력 있는 시스템 모델링 순공학과 역공학 힌트와 조언
328. 시작하기 Component Diagram Component 들 간의 구성과 의존을 정적인 Implementation View 로 Modeling 실행 File, Library, Table, File, Document 같은 Node 에 존재하는 물리적인 구성 요소들을 Modeling 본질적으로는 Class Diagram 이며 System 의 Component 에 관점을 둠 fine.exe neteng.dll dbacs.dll index.html find.html << hyperlink>> Component 실행 File Library Page
329. 용어와 개념 공통 Property 다른 Diagram 들과 동일한 공통 Property 를 공유하며 Component 의 관계를 표현하며 Graphic 으로는 꼭지점 (Vertices) 와 호 (Arc) 를 사용 내용 (Content) 공통적 포함 내용 Component Interface Relationship : Dependency, Generalization, Association, Realization Note 와 Constraint 를 포함 Package 또는 Sub-System 포함 가능 공통적 사용 System 각 부분의 Configuration Management 를 지원하는 정적인 Implementation View 작성에 활용
330. 보편적 모델링 기법 Source Code Modeling Source Code File 들과 그들의 관계를 Modeling Source Code Modeling 중요한 Source Code File 을 확인 (Stereotype 으로 지정된 Component 로 Modeling) System 이 큰 경우에는 Package 를 활용하여 Source Code File 들을 Group 화 Source Code File 의 Version No., 작성자 , 변경일자 등을 Tagged Value 로 표현 의존 관계를 사용하여 File 들 간의 Compile 의존성을 모형화 signal.h {version = 3.5} signal.h {version = 4.0} signal.h {version = 4.1} signal.cpp {version = 4.1} interp.cpp interp.cpp interp.cpp << parent>> << parent>>
331. 실행 배포판 (Executable Release) Modeling 완전하고 모순 없는 산출물을 내부 / 외부에 인도하기 위한 Modeling 고유한 각 Application 을 공유할 수 있도록 하며 분산 System 에서 흩어져 있는 많은 실행 File 들 및 구성 요소들을 적절하게 배치 (Deployment) 하기 위한 도해 실행 배포판 Modeling Model 로 작성할 Component 확인 각 Component 에 대해 Stereotype 고려 각 Component 에 대해 인접한 Component 와의 관계를 고려 path.dll collision.dll driver.dll {version = 8.1.3.2} ISelfTest IDrive
332. 물리적 (Physical) Database Modeling 논리적 (Logical) Database Schema : System 에서 보존할 Data 의 관계가 갖는 의미와 함께 그들의 어휘에서 파악되는 저장 정보를 파악 물리적 (Physical) Database Schema : 논리적 Database Schema 를 저장 자료구조의 특성을 고려하여 System 에 저장하기위한 정보 구조로 변환하는 것이며 논리적 Database Schema 에 정의된 Operation 들을 Mapping 물리적 Database Modeling 전략 각 Class 당 하나의 Table 을 별도로 지정 상속 관계를 제거하고 상속 계층에 속하는 Class 들의 모든 Instance 가 같은 상태 (State) 를 갖도록 (Instance 들에 불필요한 정보가 저장될 수 있음 ) Parent 와 Child 상태를 서로 다른 Table 로 분리 ( 교차적인 Table Join 이 많이 발생 ) 논리적 Operation 들이 구현되는 방법 단순한 CRUD Operation 의 경우는 표준 SQL 또는 ODBC 호출로 구현 복잡한 행동 ( 업무 규칙 ) 들은 Trigger 또는 Stored Procedure 로 Mapping 물리적 Database Modeling 논리적 Database Schema 를 나타내는 Class 를 확인 Class 들을 Table 로 Mapping 하기 위한 전략을 선택 Mapping 시킨 내역을 가시화 , 명세화 , 구축 , 문서화하기 위한 Stereotype 지정 가능하면 Tool 을 이용
334. 적응력 있는 System Modeling Component Diagram 은 정적인 표현만을 표현하나 경우에 따라서는 다른 UML 일부 Diagram(Object Diagram, Interaction Diagram) 들과 결합 사용하여 동적인 표현을 가능하도록 적응력 있는 System Modeling Node 에서 Node 로 이동할 수 있는 Component 들의 물리적인 분산을 고려 ( 위치를 꼬리표 값으로 표현 , Component Instance 의 위치 명세화 ) Component 의 이동을 초래하는 활동들을 Model 화 하려면 Component Instance 를 포함하는 Interaction Diagram 생성 : school.db {location = Server A } : school.db {location = Server B } The school database on Server B replicates the database on Server A. << copy>>
335. 순공학과 역공학 Component Diagram 순공학 각 Component 에 대해 해당 Component 가 구현하는 Class 나 Collaboration 을 파악 해당 Component 를 어느 것으로 순공학 처리할 것인가를 결정 가능하면 Tool 을 사용 Component Diagram 역공학 역공학 대상을 선택 Tool 을 활용하여 역공학 하려는 Code 를 지정 Tool 을 사용하여 Model 을 질의 (Query) 하는 형식으로 Component Diagram 생성 vbrun.dll ParentControls DataObject SelectedControls DataObjectFiles DataBindings AmbientProperties AsyncProperties PropertyBag ContainedControls HyperLink DataBinding
336. 힌트와 조언 구조가 좋은 Component Diagram System 의 정적 구현 View 중에서 한가지 관점에만 초점 해당 관점을 이해하는데 꼭 필요한 요소들만 포함 내용을 이해하는데 꼭 필요한 장식 (Adornment) 만을 포함하여 해당 내용 추상화 수준과 일치하는 상세 내역 제공 너무 적지 않으며 충분한 내용을 포함하고 있어서 의미를 이해하기에 부족하지 않도록 Component Diagram 을 그릴 때 목적을 잘 알 수 있는 명칭 사용 교차선이 최소화 되도록 요소를 적절히 배치 의미적으로 밀접한 것들이 서로 가까이 존재하도록 공간을 활용한 배치 시각적 효과를 충분히 나타내도록 (Note, Color, …) Stereotype 으로 지정된 요소들을 주의해서 사용
337. 30 장 . 배치도 (Deployment Diagram) 시작하기 용어와 개념 보편적 모델링 기법 내장 시스템 모델링 클라이언트 / 서버 시스템 모델링 완전 분산 시스템 모델링 순공학과 역공학 힌트와 조언
338. 시작하기 배치도 (Deployment Diagram) Component Diagram 과 함께 System 의 물리적 관점을 Modeling 하는 Diagram 실행 처리 능력을 갖는 Node 의 구성과 해당 Node 에 존재하는 Component 들을 표현 본질적으로 Class Diagram 이며 System Node( 실행되는 H/W 의 형태 Modeling) 에 초점을 두어 정적인 관점을 가시화 <<processor>> caching server <<processor>> caching server Modem bank Internet <<network>> local network <<processor>> server <<processor>> primary server <<processor>> server <<processor>> server Node Node Connection
339. 용어와 개념 공통 Property 다른 Diagram 들과 동일한 공통 Property 를 공유하며 Node 에 존재하는 Component 의 구성을 나타내며 Graphic 으로는 꼭지점 (Vertices) 와 호 (Arc) 를 사용 내용 (Content) 공통적 포함 내용 Node Relationship : Dependency, Association Note 와 Constraint 를 포함 Package 또는 Sub-System 포함 가능 공통적 사용 물리적 System 구성 부분들의 분산 , 인도 , 설치를 다루는 정적인 Deployment View 작성에 활용 다수의 Processor 에 걸쳐 분산되어 있는 장치들과 교류하는 S/W 를 개발하고자 하는 경우 S/W 를 H/W 로 Mapping 하는 것을 쉽게 표현
340. 보편적 모델링 기법 내장 (Embedded) System Modeling 물리적인 세계와 Interface 하는 H/W 와 S/W 를 집약 내장 System 을 구성하는 장치와 Processor 를 Modeling Project 에 참여하는 H/W Engineer 와 S/W 개발자간의 의사 소통을 용이하게 내장 System Modeling System 의 고유한 장치와 Node 를 확인 확장 Mechanism 을 활용하여 System 특유의 Stereotype 을 적절한 Icon 으로 정의 Processor 와 장치들 사이의 관계를 배치도에 Modeling 자체 처리 능력을 갖는 장치들에 대해 Model 을 확장하되 , 더 상세한 배치도로 구조를 Modeling <<processor>> Pentium motherboard Timer Ultrasonic sonar sensor Left position encoder Rigth position encoder M ~ M ~ Steering Motor Drive Motor Serial I/O port Digital I/O port << RS232>> 8
341. Client/Server System Modeling System 의 사용자 Interface(Client) 와 보존 Data(Server) 간의 관계를 분명하게 구분하며 Network 연결 및 Node 에 걸쳐 존재하는 S/W Component 의 물리적 분산 표현 Client/Server System Modeling System 의 Client 와 Server Processor 를 나타내는 Node 확인 System 의 행동과 밀접한 관계가 있는 장치들에 중점을 두고 배치에 중점을 둠 Stereotype 을 이용하여 해당 Processor 와 장치들을 시각적으로 가시화 Node 의 형태를 배치도에 표현 ( 배치 View 에 있는 Component 와 Node 관계 명세 ) Client console kiosk Server 2..* <<processor>> caching server Deploys http.exe rting.exe 4..* <<processor>> server Deploys dbadmin.exe tktmstr.exe logexc.exe
342. 완전 분산 System Modeling 다단계 Server 를 포함하여 광범위하게 분산되어 있는 System 을 명세화 두개 이상의 Processor 로 구성된 System 으로부터 지리적으로 널리 산개된 Node 들을 연결하는 표현 완전 분산 System Modeling System 의 장치와 Processor 를 확인 System Network 의 성능 또는 Network 변화에 따른 영향 등을 파악한 통신 장치 Model 작성 Node 들을 논리적으로 분류하기 위한 Package 의 활용 장치 들과 Processor 들을 배치도에 Model 로 표현 동적 활동에 초점을 두려면 Use Case Diagram 으로 활동을 명세화하고 Interaction Diagram 을 이용하여 상세화 console : regional server console console : regional server : regional server : country server : logging server Note : country servers are reachable to one another via the company’s private network : Internet
343. 힌트와 조언 구조가 좋은 Deployment Diagram System 의 정적인 배치 View 중에서 한가지 관점에만 초점 해당 관점을 이해하는데 꼭 필요한 요소들만 포함 내용을 이해하는데 꼭 필요한 장식 (Adornment) 만을 포함하여 해당 내용 추상화 수준과 일치하는 상세 내역 제공 너무 적지 않으며 충분한 내용을 포함하고 있어서 의미를 이해하기에 부족하지 않도록 Deployment Diagram 을 그릴 때 목적을 잘 알 수 있는 명칭 사용 교차되는 선이 최소화 되도록 요소를 적절히 배치 의미적으로 밀접한 것들이 서로 가까이 존재하도록 공간을 활용한 배치 시각적 효과를 충분히 나타내도록 (Note, Color, …) Stereotype 으로 지정된 요소들을 주의해서 사용
344. 31 장 . 시스템과 모델 (System & Model) 시작하기 용어와 개념 보편적 모델링 기법 시스템 아키텍쳐 모델링 시스템의 상위 시스템 모델링 힌트와 조언
345. 시작하기 System 과 Model UML 은 S/W 중심의 System 산출물을 가시화 , 명세화 , 구축 , 상세화 하는 것 UML 을 이용하여 System Model 을 단계적으로 작성 구조가 좋은 System : 기능적 , 논리적 , 물리적으로 응집력이 좋고 결합력이 약한 Sub-System 으로 형성 구조가 좋은 Model : 서로 다른 Model 이 상호 관계를 유지하며 복잡한 System 을 간결하고 이해하기 쉽게 표현 << system>> Retail Enterprise System << subsystem>> Customer Service Subsystem << subsystem>> In Store Management Subsystem << subsystem>> Warehouse Management Subsystem System Subsystem
346. 용어와 개념 System 과 Subsystem System : 개발 또는 Modeling 하려는 주체이며 특정 목적을 얻기 위해 구성된 요소들로 되어 있으며 서로 다른 관점을 갖고 있는 Model 들로 기술 Subsystem : System 의 한 부분이며 복잡한 System 을 상호 독립적인 부분들로 분해하는데 사용 System 과 Subsystem 간의 기본적 관계는 Aggregation 관계이며 Generalization 관계를 갖을 수도 있으며 전체 System 은 Zero 또는 그 이상의 Subsystem 을 포함 Model 과 View Model 은 현실을 단순화 한 것이며 System 을 추상화하는 것으로 System 의 범위 내에 정의 Model 은 특별한 종류의 Package 로써 구성 요소들을 소유 View 는 Model 에 대한 투영 (Projection) 이며 Model 이 갖는 것들에 대한 부분 집합으로써 Model 간의 경계를 무시하고 표현할 수는 없음 추적 (Trace) 서로 다른 Model 에 존재하는 요소들 간의 개념적 관계를 추적 관계로 Modeling
347. 보편적 모델링 기법 System Architecture Modeling System 요구 사항 , 논리적 요소 , 물리적 요소를 파악하고 결정하여 표현 System 과 Pattern 이 갖는 구조적이고 행동적인 관점을 Model 화 System Architecture Modeling Architecture 를 표현하기 위하여 어떠한 View 를 사용할 것인가를 확인 System 과 관련 있는 Actor 를 포함해서 해당 System 의 상황 (Context) 를 명세화 필요하면 System 을 Subsystem 으로 분해 설계 뷰 (Design View) 구현 뷰 (Implementation View) 프로세스 뷰 (Process View) 배치 뷰 (Deployment View) 쓰임새 뷰 (Use Case View) 시스템 조립 형상관리 시스템 구성 형태 분산 , 인도 , 설치 어휘 기능성 성능 확장성 처리량 논리적 물리적
348. System 과 Subsystem 에 대해 수행해야 할 일 System 의 Use Case View 를 명세화 : 최종 사용자 , 분석가 , Test 담당자 등이 보는 System 행동을 설명 . Use Case Diagram 을 적용하여 정적인 관점을 Modeling 하고 Interaction Diagram, Statechart Diagram, Activity Diagram 을 적용하여 동적인 관점을 Modeling System 의 Design View 를 명세화 : 문제 영역과 해법의 어휘를 형성하는 Class, Interface, Collaboration 을 포함 . Class Diagram, Object Diagram 을 적용하여 정적인 관점을 Modeling 하고 Interaction Diagram, Statechart Diagram, Activity Diagram 을 적용하여 동적인 관점을 Modeling System 의 Process View 를 명세화 : 동시성 ( Concurrency) 과 동기화 (Synchronization) Mechanism 을 형성하는 Thread 와 Process 를 포함 . Design View 와 동일한 Diagram 을 적용하되 Thread 와 Process 를 나타내는 활성 Class 와 Object 에 초점을 둠 System 의 Implementation View 를 명세화 : 물리적인 System 을 조립하고 배포하는데 사용되는 Component 를 포함 . Component Diagram 을 적용하여 정적인 관점을 Modeling 하고 Interaction Diagram, Statechart Diagram, Activity Diagram 을 적용하여 동적인 관점을 Modeling System 의 Deployment View 를 명세화 : System 이 실행되는 H/W 형태를 나타내는 Node 를 포함 . Deployment Diagram 을 적용하여 정적인 관점을 Modeling 하고 Interaction Diagram, Statechart Diagram, Activity Diagram 을 적용하여 동적인 관점을 Modeling Collaboration 을 이용하여 해당 Model 들의 Architecture Pattern 과 Design Pattern 을 Model 화 System Architecture 는 한번의 Big-Bang 으로 만들어질 수 없으며 지속적인 반복 , 점진적 발전을 통해 정제 (Refinement) 됨
349. System 의 상위 System Modeling 특정 추상화 수준에 있는 System 은 더 높은 추상화 수준에 있는 System 의 Subsystem 으로 표현 System 또는 Subsystem 의 Modeling 독립적으로 개발 , 배포 , 배치될 수 있는 System 의 주요 기능들을 확인 각 Subsystem 에 대해 해당 상황들을 명세화 각 Subsystem 에 대한 Architecture 를 Modeling
350. 힌트와 조언 구조가 좋은 Model Model 간 독립된 관점에서 현실을 단순화 자체 Model 에 필요한 모든 내용을 포함 결합도가 낮게 다른 Model 과의 추적 관계 유지 System 에서 필요로 하는 산출물들을 완전하게 표현 구조가 좋은 System 기능적 , 논리적 , 물리적으로 응집 독립적인 Subsystem 으로 분해될 수 있고 , Subsystem 들은 더 낮은 추상화 수준의 System 으로 표현 상호 연관적이면서도 중복되지 않는 Model 들에 의하여 가시화 , 명세화 , 구축 , 문서화 UML 로 System 이나 Subsystem 을 표현 할 때 System 이나 Subsystem 에 연관되는 모든 산출물들을 작성하기위한 시작점으로 각각을 서로 이용 System 과 Subsystem 간의 기본적인 집합 연관 만을 표현
353. UML 로 옮겨 가기 UML 의 사용 UML 을 사용하려 할 때 접근하는 방법은 사용자의 경험에 따라 달라질 수 있음 UML 은 단순히 정보 System 관련 Modeling 에만 적용되는 것이 아니라 사람이 생각하고 분석해야 할 것이라면 무엇이든 Model 화 할 수 있음 UML 로 옮겨 가기 Class, Attribute, Operation, Use Case, Component, Package 와 같은 기본 구조 사물들을 Dependency, Generalization, Association 과 같은 구조 관계들과 함께 사용하면 많은 종류의 문제 영역에 대한 정적인 Model 을 충분히 생성 단순 State Machine 및 Interaction 과 같은 기본 행동 사물들을 추가하면 System 에 유용한 동적 관점들을 Modeling 하며 동시성과 분산을 모형화 하는 것과 같이 보다 복잡한 상황에서는 더 진보된 UML 기능을 사용 Object Oriented 에 처음 접할 때 추상화 개념에 익숙해 지도록 (CRC Card, Use Case Analysis 등을 숙지하여 추상 개념을 찾는 능력 개발 ) 추상 개념들로 이루어진 것들을 가시화하는데 친숙해 지도록 Class, Dependency, Generalization, Association 을 사용하여 간단한 정적인 Model 작성 간단한 Sequence Diagram 이나 Collaboration Diagram 을 사용하여 문제 영역의 동적인 부분 Model 작성
354. Modeling 에 처음 접할 때 개발해 본 경험이 있는 System 의 일부를 대상으로 시작 System 에 사용했던 Programming Idiom 이나 Mechanism 의 상태 내역 중 일부에 대하여 UML 을 사용해 Model 화 복잡한 Application 의 경우에는 포함된 주요 요소를 표현하기 위하여 UML 의 Package 를 이용하여 Application 의 Architecture Model 을 다시 구축 UML 의 익숙해진 후 다른 Project 에 UML 적용 Object Oriented 경험이 있을 때 현재의 Modeling Language 를 재고하여 내재된 요소들을 UML 요소로 Mapping 시키는 방법을 모색 현재의 Modeling Language 로 구현이 힘들거나 불가능한 대상을 UML 의 진보된 기능을 적용 사용을 잘할 때 UML 개념 Model 을 개발 Component, 동시성 , 분산 , Pattern 들을 Modeling 하는데 필요한 UML 기능들을 파악 UML 확장 Mechanism 을 자세히 살피고 해당 Domain 에 직접 적용할 방법을 모색
355. UML 참고 자료 UML 참고 자료 The Unified Modeling Language User Guide : Addison Wesley The Unified Modeling Language Reference Manual : Addison Wesley The Unified Development Process : Addison Wesley Object Oriented Analysis and Design : Addison Wesley Object Oriented Software Engineering : Addison Wesley Object Oriented Modeling and Design : Addison Wesley Use Case Driven Object Modeling with UML : Addison Wesley Use Cases Combined with Booch/OMT/UML : Prentice Hall Advanced Object Oriented Analysis and Design Using UML : Cambridge University Press UML Distilled : Addison Wesley Object Oriented Analysis : Prentice Hall Object Oriented Systems Analysis : Yourdon Press Web Site www.rational.com www.omg.org . . . .
![안병권 ( A n, ByoungKwon ) 안 동문이 개발한 기술의 응용분야는 무궁무진하다 . 안 동문은 “영화 ‘트랜스포머’의 범블비가 길에서는 차로 변하고 , 하늘에서는 비행기로 변하듯이 로봇을 자유자재로 변형시킬 수 있다”고 말했다 . 또 “임무를 수행 중인 우주선이나 인공위성의 한 부분이 고장 나도 동작을 멈추지 않고 상황에 따라 변이하며 계속 임무를 수행할 수 있다 . 이는 개별 큐브마다 CPU 가 탑재되어 있어 이와 연동하는 소프트웨어로 처리가 가능한 것”이라고 덧붙였다 . 그는 또 “특히 의료분야에서 많이 활용할 수 있는데 , 심장이 뛰지 않을 때 세포 크기의 큐브가 심장으로 들어가서 심장을 압박 , 다시 심장이 뛰게 만들 수 도 있고 , 암세포를 제거하는 데도 유용하게 사용될 수 있다”고 말했다 . 그는 이 기술의 개발과 관련 , MIT 컴퓨터공학과 박사과정의 입학허가를 받아냈다 . 안 동문은 “학부시절 은사인 김진민・김희상 교수 ( 숭실대 물리학과 ) 로부터 물리학을 체계적으로 배웠고 , 또 학과가 다름에도 불구하고 이남용 교수 ( 숭실대 컴퓨터공학 ) 와는 2 학년 말부터 졸업할 때까지 컴퓨터공학을 함께 연구한 것이 큰 도움이 됐다”고 말했다 . 석사과정을 거치지 않고 박사과정에 바로 입학하는 것이 가능하냐는 질문에 “작년 10 월에 MIT 를 방문했고 담당교수인 다니엘라 루스로부터 입학을 권유받았다”고 말했다 . 하버드 등 외국명문대학을 순회하면서 교수들을 만났다는 그는 “처음에는 ‘시간이 없다’며 만날 기회도 주지 않고 거들떠도 보지 않던 교수들이 한국에서 준비한 연구물을 보여주자 180 도로 달라졌다”고 멋쩍은 듯 말했다 . 그는 오는 9 월부터 연간 학비만 해도 6~7 만 불에 이르는 MIT 에서 전액장학금을 받고 공부를 시작한다 . 또 모교인 숭실대로부터 ‘글로벌인재양성’장학금도 받는다 . 그는 이공계 기피현상이 일고 있는 세태를 보며 “학부 시절 물리를 전공한 것이 이번 연구에 무척 도움이 됐다 . 기초과학을 절대 소홀히 하면 안 된다”고 말했다 . 또 “대학생들이 학부 때부터 교수님과 친해져서 논문도 쓰고 연구도 해서 외국무대에서도 당당하게 활약할 기반을 닦으면 좋겠다”고 ‘팁’을 건냈다 . 한편 , 안 동문은 오는 5 월 19 일부터 23 일까지 美 캘리포니아 파사데나에서 열리는 2008 국제전기학회 컨퍼런스 (2008 IEEE International Conference on Robotics and Automation) 에서 이 기술에 대해 발표한다 . 홍보팀 ( [email_address] )](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-9-320.jpg)
![목 차 [1] UML 개념 [2] 기본 구조 모델링 [3] 고급 구조 모델링 [4] 기본 행동 모델링 [5] 고급 행동 모델링 [6] 아키텍쳐 모델링 [7] UML 적용](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-60-320.jpg)
![[1] UML 개념 1 장 . 왜 모델을 만드는가 ? 2 장 . UML 소개 3 장 . UML 의 기초](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-61-320.jpg)
![[2] 기본 구조 모델링 4 장 . 클래스 5 장 . 관계 6 장 . 공통 메카니즘 7 장 . 도해 8 장 . 클래스도](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-97-320.jpg)
![[3] 응용 구조 모델링 9 장 . 응용 클래스 10 장 . 응용 관계 11 장 . 인터페이스 , 타입 , 역할 12 장 . 펙케지 13 장 . 인스턴스 14 장 . 객체도](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-148-320.jpg)
![다중성 (Multiplicity) 하나의 Class 가 갖을 수 있는 다수의 Instance 수 NetworkController 1 consolePort [2..*] : Port 독자 Class 다중성 ControlRod 3](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-156-320.jpg)
![속성 (Attribute) 가장 높은 추상화 수준에서 Class 의 구조적 특성인 속성을 표현할 때는 명칭만을 기술 속성에도 가시성 , 범위 , 다중성 , 타입 , 초기값 , 변경 가능성 등을 지정 가능 속성을 기술하는 UML 의 완전한 문장 [visibility] name [multiplicity] [:type] [=initial-value] [{property-string}] 속성 선언 예제 origin 명칭 + origin 가시성 , 명칭 origin : Point 명칭 , Type head : *Item 명칭 , 복잡한 Type name [0 . . 1] : String 명칭 , 다중성 , Type origin : Point = (0, 0) 명칭 , Type, 초기값 id : Integer {frozen} 명칭 , Property 속성 정의 Property changeable( 변경 ) : 속성값 바꾸는 제약 없음 addOnly( 추가 ) : 하나 이상의 다중성을 가진 속성에 추가만 가능 frozen( 동결 ) : 객체가 초기화된 이후 속성값을 바꿀 수 없음](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-157-320.jpg)
![오퍼레이션 (Operation) 가장 높은 추상화 수준에서는 Operation 명칭만을 기술하지만 여기에 Parameter, Return Type, 동시성 그리고 Operation Property 를 지정 - Operation 의 Signature Operation 을 기술하는 UML 의 완전한 문장 [visibility] name [(parameter-list)] [:return type] [{property-string}] Operation 선언 예제 display 명칭 + display 가시성 , 명칭 set (n : Name, s:String) 명칭 , Parameter getID ( ) : Integer 명칭 , Return Type restart ( ) {guarded} 명칭 , Property Parameter 제공 구문 [direction] name : type [ =default-value] Operation 적용 Property isQuery ( 질의 ) : Operation 실행 후 System 상태 변화 없음 sequential ( 순차 ) : 객체 외부에서 서로 협조하여 객체 안에 한번에 하나의 흐름만 존재 guarded ( 보호 ) : Operation 에 대한 모든 호출을 순차적으로 관리 ( 의미 , 무결성 보장 ) concurrent ( 동시 ) : 여러 제어흐름이 존재해도 각 Operation 을 원자적으로 처리 ( 의미 , 무결성 보장 ) direction 값 : in (input parameter 로 변경 불가 out (output parameter 로 호출자와 정보 변경 가능 ) inout (input parameter 로 변경 가능 )](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-158-320.jpg)
![템플릿 클래스 (Template Class) Template : Parameter 로 된 요소 일반 Class 와 마찬가지로 사용할 수 있는 구체 Class 로써 직접 사용할 수는 없고 객체화 ( 형식 Parameter 를 실 Parameter 로 Binding) 시켜야 함 예제 - Map 이라는 Parameter Class 를 선언하는 C++ Code template <class Item, class Value, int Buckets> class Map { public : virtual Boolean bind (const Item&, const Value&) ; virtual Boolean isBound (const Item&) const ; . . . } ; ] 위 Template 을 이용한 Customer 객체의 Order 객체 대응 m : Map <Customer, Order, 3> ;](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-159-320.jpg)
![정적 (Static) Type / 동적 (Dynamic) Type Modeling Object 의 정적 성질 Modeling 은 Class Diagram 으로 가시화하지만 Workflow 를 거치며 역할을 바꾸는 Business Object 와 같은 사물은 명시적으로 Object Type 의 동적 성질을 Modeling 하는 것이 유용할 수 있음 Dynamic Type Modeling 추상 개념의 구조와 행동을 필요로 한다면 객체의 서로 다른 형태를 Type Stereotype 을 이용하여 Class 로 지정 추상 개념이 행동만을 요구한다면 Interface 로 지정 Object 의 Class 가 취할 모든 역할들을 Modeling 교류도에서 동적으로 타입을 결정하는 Class 와 Instance 를 표현 Object 의 역할이 변하는 것을 나타내기 위해 교류 속에서 Object 가 수행하는 역할 하나에 한번씩 나타내고 become Stereotype Message 로 이 Object 들을 연결 Person <<type>> Candidate <<type>> Employee <<type>> Retiree p : Person [Candidate] p : Person [Employee] :HRDepartment 6 : << become>> 5 : hire( ) Static Type Modeling Dynamic Type Modeling](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-183-320.jpg)
![Operation Object 는 공간적 내용을 포함하여 해야 할 Object 에 대한 실행 Operation 들은 객체의 추상 개념 안에 선언 Operation 의 상속 계층에 따른 다형적 호출 가능 상태 (State) 정적인 Property 와 동적인 각 Property 의 현재 값을 포함 객체의 속성들과 모든 집합체 부분들을 (Aggregate Parts) 포함 객체 상태를 가시화 하는 것은 특정 시간과 공간 상에 주어진 순간의 상태 값을 명세화 하는 것 객체에 대한 Operation 을 수행하면 그 상태는 변화가 발생 myCustomer Id : SSN = “432-89-1783” active = True 속성 값 포함 Instance c : Phone [WaitingForAnswer] 명시적 상태 포함 Instance](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-197-320.jpg)
![보편적 모델링 기법 구체 Instance Modeling Instance 들 사이의 구조적 관계 표현 구체 Instance Modeling 방법 Modeling 하려는 문제 영역을 가시화 , 명세화 , 구축 , 문서화하기 위한 Instance 파악 UML 객체들을 Instance 로 표현 (Object 에 명칭 부여 ) Modeling 하기에 필요 / 충분한 Instance 에 Stereotype, Tagged Value, Attribute 표현 Instance 들과 이들의 관계를 Object Diagram 으로 표현하거나 해당 instance 를 적절한 다를 Diagram 으로 표현 current : Transaction << instanceOf>> primaryAgent [working] Transaction FraudAgent](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-199-320.jpg)
![[4] 기본 행동 모델링 15 장 . 교류 16 장 . 쓰임새 17 장 . 쓰임새도 18 장 . 교류도 19 장 . 활동도](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-202-320.jpg)
![시작하기 활동도 (Activity Diagram) 순서도의 일종으로 발생하는 활동을 강조 흐름도로써 활동으로부터 활동으로 전달되는 제어 흐름 표현 ( 발생 활동에 초점 ) 객체간 통과 제어 흐름 (Operation) 을 표현 활동은 다시 몇 개의 Action 으로 분리 Select site Commission architect Develop plan Bid plan Do site work Do trade work( ) Finish construction 초기 상태 : Certificate Of Occupancy [completed] 동작 상태 순차적 분기 동시 분할 동시 합류 종료 상태 Sub Machine 이 있는 활동 상태 객체 흐름 [else] [ not accepted]](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-238-320.jpg)
![전이 (Transition) 한 동작이나 활동 상태에서 다른 동작이나 활동 상태로 가는 경로 분기 (Branching) 하나의 전이가 부울식에 근거한 경로 대안으로 두개 이상의 전이로 나뉘는 것 Select site Commission architect 촉발 없는 전이 Release work order 전이식 [ material not ready] Reschedule Assign tasks [ material ready]](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-240-320.jpg)
![Object 흐름 활동도에 관여하는 사물들을 명세화 Request product Customer 객체 흐름 Receive order Sale Process order Warehouse Pull material Ship order Bill customer Pay bill Close order o : Order [in progress] o : Order [filled] b : Bill [paid] b : Bill [unpaid] 객체 상태](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-243-320.jpg)
![Request return Customer Telesales Accounting Get return No. I : Item [returned] Warehouse Ship item Receive item Restock item I : Item [available] Credit account](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-245-320.jpg)
![Operation Modeling 활동도의 문맥에 있는 Operation 의 Parameter 와 Local Object 의 분기 (Branch), 분할 (Fork), 합류 (Join) 등을 활용한 모형화 Operation Modeling 순서 Operation 관련 추상 개념 수집 초기 상태의 선행 조건과 종료 상태의 종료 조건 파악 시간 경과에 따라 활동과 동작 표현 Operation 이 활동 Class 에 소속된 경우 분할과 합류를 사용하여 동시 제어 흐름 명세화 return Point (0,0) [else] x = (l.delta - delta) / slope - l.slope) ; y = (slope * x) + delta return Point (x, y) [slope = l.slope]](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-246-320.jpg)
![[5] 응용 행동 모델링 20 장 . 사건과 신호 21 장 . 상태 머신 22 장 . 프로세스와 쓰레드 23 장 . 시간과 공간 24 장 . 상태도](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-249-320.jpg)
![전이 (Transition) 특정 Object 가 현 상태에서 어떤 동작을 수행한 후 지정된 상태가 발생하고 지정된 조건이 만족되었을 때 다음 상태로 들어가는 두 상태간의 관계 전이의 5 부분 원래 상태 (Source State) : 전이에 의해 바뀌는 상태 촉발 사건 (Event Trigger) : 원래 상태의 객체가 한 사건을 받았을 때 조건이 만족되어 전이를 합당하게 수행할 수 있는 조건 전이 조건 (Guard Condition) : 촉발 사건이 수신되어 전이 촉발 시에 검토되는 Boolean 식 (True 이면 수행 ) 동작 (Action) : 실행 가능한 원자성 연산 , Object 에 직접 또는 간접적으로 발생하는 작용 목표 상태 (Target State) : 전이가 완료된 후의 활성 상태 Idle Engaging 사건 Trigger shutDown After (2 seconds) / send c.isAlive contact Searching Engaging Tracking targetAt(p) [isThreat] / t.addTarget(p) noise 시간 사건 재귀 전이 매개 변수 있는 사건 Trigger 전이 조건 동작 전송 신호 Trigger 없는 전이](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-262-320.jpg)
![하위 상태 (Substate) 단순 (Simple) 상태 : 하위 구조를 갖지 않는 상태 복합 (Composite) 상태 : 하위 상태를 포함하는 중첩 (Nested) 상태 복합 상태는 동시 ( 직교성 (orthogonal)) 하위 상태 또는 순차 ( 배타적 (Disjoin)) 하위 상태를 포함 순차 하위 상태 (Sequential Substate) Active 순차에 있는 모두로부터 나오는 전이를 한꺼번에 표현 순차 하위 상태들은 복합 상태의 사태 공간을 분할하여 배타적 상태가 됨 Idle Maintenance [ continue] Active Activating maintain Selecting Processing Printing cardInserted cancel [ not continue] entry / readyCard exit / ejectCard 복합 상태의 전이 복합 상태 순차 하위 상태 하위 상태로부터의 전이](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-264-320.jpg)
![동시 하위 상태 (Concurrent Substate) 포함된 Object 들의 문맥에서 동시적으로 실행되는 State Machine 이 두개 이상 나타낼 때 사용 동시 하위 상태는 실행이 병렬도 진행되다 각 중첩 State Machine 이 종료 상태에 도달 Idle Maintenance Testing devices Testing Self diagnosis Testing devices Self diagnosis Commanding [ continue] [ not continue] keyPress maintain 분할 (fork) 합류 (join) 동시 하위 상태 복합 상태](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-266-320.jpg)
![[6] 아키텍쳐 모델링 25 장 . 컴포넌트 26 장 . 배치 27 장 . 협력 28 장 . 패턴과 프레임웍 29 장 . 컴포넌트도 30 장 . 배치도 31 장 . 시스템과 모델](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-287-320.jpg)
![[6] 아키텍쳐 모델링 25 장 . 컴포넌트 26 장 . 배치 27 장 . 협력 28 장 . 패턴과 프레임웍 29 장 . 컴포넌트도 30 장 . 배치도 31 장 . 시스템과 모델](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-288-320.jpg)
![[7] 마무리 32 장 . UML 의 적용](https://image.slidesharecdn.com/uml-110922081016-phpapp02/85/Uml-351-320.jpg)
