An introduction to UML 과목명 : 소프트웨어모델링및분석 교수명 : 유준범교수님 제출일 : 2016.03.16. ( 수 ) 팀 원 : 201211341 김태현 201411269 고수창 200911411 이상규
1. UML 개요 a. UML 이란무엇인가? b. UML 을정의하게된동기 i. 모델링을하는이유 ii. 소프트웨어산업의경향 iii. 산업표준이생기기전 2. UML 의목표 3. UML 의범위 a. UML 산출물 b. UML 의범위바깥 4. UML 의과거, 현재그리고미래 a. UML 0.8 0.91 b. UML 1.0 1.1 c. UML 의현재와미래 5. 유스케이스 (Use case) 6. 관계 (Relationship) 7. 상태 (State) 8. 배치 (Deployment) 9. 컬레보레이션 (Collaboration) 10. 인터렉션 (Interection) 11. 클래스다이어그램 (Class Diagram) a. 연관 (Association) b. 속성 (Attribute) c. 연산 (Operation) d. 일반화 (Generalization) e. 제약규칙 (Constraint Rule) 12. 상호작용다이어그램 (Interaction Diagram) a. 순차다이어그램 (Sequence diagram) b. 협동다이어그램 (Collaboration Diagram) c. 순차다이어그램과협동다이어그램의비교 d. 언제상호작용다이어그램을사용하는가? 13. 상태다이어그램 (State Diagram) 14. 활동다이어그램 (Activity Diagram) 15. 컴포넌트다이어그램 (Component Diagram)
1.UML 개요 a. UML 이란무엇인가? Unified Modeling Language (UML) 은소프트웨어시스템, 더나아가업무모델링, 기타소프트웨어가아닌시스템의산출물을규정하고시각화하며구현하고문서화하는언어이다 (The UML is a language for specifying, visualizing, constructing, and documenting the artifacts of a software systems, as well as for business modeling and other non software systems). UML 은복잡한대형시스템을모델링하는데성공적으로증명된공학적기법들을모아제시한것이다. UML 은 80 년대후반에서 90 년대에이르는기간동안나타난객체지향분석설계방법론의흐름을이어받은객체지향모델링언어이다. 가장영향력이있던 Booch 와 Rumbaugh, Jacobson 의방법론을직접적으로통합하였으며이외방법론의장점들을모아서표준화시킨것이다. 99 년 3 월현재 UML 은 OMG(Object Management Group) 에의해서표준으로확정되었으며개정된 1.1 판이제시된상태이고 1.3 판의개정작업이이루어지고있다. UML 은모델링언어로서방법론의일부이다. 방법론의다른부분인공정 (process) 은표준화되어있지않으나어떠한방법론을사용하든지간에통일된표기법을제시하는것이 UML 의역할이다. b. UML 을정의하게된동기 모델링을하는이유 소프트웨어시스템을구축하거나혁신하기전에모델을개발하는것은건물을지을때청사진을그리는것과마찬가지로필수적인일이다. 좋은모델은아키텍처를건전하게하고프로젝트팀의의사소통을원활히하는데에있어서필수적이다. 복잡한시스템의모델을만드는이유는그러한시스템을한번에통째로이해할수없기때문이다. 시스템의복잡성이커질수록좋은모델링기법의중요성도커지게마련이다. 프로젝트의성공을위한요소들이많이있지만엄격한모델링언어의표준화는그중필수적인요소이다. 모델링언어는다음과같은사항을포함해야한다. 소프트웨어산업의경향많은회사에서소프트웨어의전략적가치가증가함에따라산업계는소프트웨어의생산을자동화할수있는기법을찾게되었다. 그기법은품질을향상시키고비용과시간을절감할수있는기법들로서컴포넌트기술, 시각적프로그래밍, 패턴, 프레임웍등을포함한다. 또한시스템이범위나스케일이증가하는경우에도그복잡성을다루어낼수있는기법이필요했다. 특히, 반복해서나타나는아키텍처에관련된문제, 예를들어, 물리적인분산, 동시성, 복제, 보안, 로드밸런싱, 고장방지능력 (fault tolerance) 등을해결하기위한필요성을인식하게되었다. 최근의월드와이드웹을위한개발경향은몇가지를단순화시켰지만아키텍처문제는더욱심화되었다. 복잡성은응용프로그램의영역과공정의단계에따라다르게마련이다. UML 개발자들에게다가온핵심적인동기부여중의하나는모든영역에걸쳐모든규모의복잡한아키텍처를적절하게처리할수있는의미와표기법을창조해내는것이었다. 산업표준이생기기전 UML 이전에는뚜렷이선도하는모델링언어가없었다. 사용자들은대동소이한많은모델링언어중에서하나를선택해야만하였다. 대부분의모델링언어들은많은개념들을공통적으로사용하면서도그것을약간씩다른의미와표기법을통해표현
하였다. 이러한통일성의부족은새로운사용자들이객체지향모델링을선택하는데꺼리는요소가되었다. 사용자들은일반적으로사용되기에적합한산업계의표준이등장하기를기다려왔다. 즉모델링을위한공통어를원했던것이다. 업체들역시비슷하면서약간씩다른여러모델링언어를지원해야할필요성때문에객체모델링분야에서어려움을느끼고있었다. 따라서많은업체들이통일된모형화언어로서의 UML 의개발을지지하게되었다. UML 은프로젝트의성공을보장하는것은아니지만많은일들을개선시킨다. 예를들어, 프로젝트나조직을바꿀때에새로교육하는비용을감소시킨다. 또한여러가지도구나공정, 영역사이의통합을이끌어낼수있다. 가장중요한것은, UML 이개발자들로하여금업무가치를생산하는데집중할수있게하고, 그것을성취할수있는패러다임을제공한다는데있다. c. UML의목표 UML의저자들이 UML을설계하면서주안점을두었던목표는다음과같다. 1. 사용자들이의미있는모델을만들고교환할수있도록사용하기쉽고표현이 풍부한시각적모형화언어를제공한다. 2. 핵심개념을확장하기위한메커니즘을제공한다. 3. 특정프로그래밍언어나개발공정에종속되지않아야한다. 4. 모델링언어를이해하기위한공식적기준을제공한다. 5. 객체지향도구시장의성장을장려해야한다. 6. 고수준의개발개념들, 예를들어협동 (collaboration), 프레임웍, 패턴, 컴포넌트 등의개념들을지원한다. 7. 산업계의검증된최상의경험들을통합한다. d. UML 의범위 Unified Modeling Language (UML) 은소프트웨어시스템의산출물을규정하고시각화하며구현하고문서화하는언어이다. 첫째로, UML 은 Booch, OMT, OOSE 의개념을융합하여널리사용될수있는공통된단일모델링언어를만든것이다. 둘째로, UML 은기존방법론들로할수있었던일의영역을확장시켰다. 예를들어, UML 의저자들은분산병렬시스템의모델링을목표로삼았다. 셋째로, UML 은표준공정이아니라표준모델링언어에초점을맞추었다. 물론 UML 은어떤공정의문맥안에서적용되어야하겠지만경험상으로보면조직과문제영역의차이에따라다른공정이요구되기때문이다. 그러므로, 의미를통일시키는공통메타모델과그의미를표현할수있게하는공통표기법을개발하는데집중하였다. UML 의저자들은사용사례중심, 아키텍처중심, 점진반복적인개발공정을권장한다. UML 은객체지향공동체의일치된의견을핵심모델링개념에통합한모델링언어이다. 그확장메커니즘에따라문제영역에맞게재단하여사용할수있다. i. UML 산출물 모델링은관련된부분에집중하고나머지는무시하는추상화를통해이루어진다. 모델의특성에는다음과같은것이있다. 복잡한시스템은모델의독립적인뷰의집합으로표현될수있다. 하나의뷰만으로는충분하지않다. 모든모델은상세함의정도가다른여러차원으로표현될수있다. 좋은모델은실재를잘반영한다. UML 은모델의뷰라는용어를사용하여다음의그래픽다이어그램을정의한다. 다음중밑줄친 8 개의다이어그램이실제산출물의이름이다.
사용사례다이어그램 use case diagram : 사용사례와사용자의관계를표현하는다이어그램 클래스다이어그램 class diagram : 클래스의관계를표현하는다이어그램 행위다이어그램 behavior diagrams 상태차트다이어그램 statechart diagram : 객체의생명주기를나타내며, 이벤트에의해변화하는객체의상태를표현하는다이어그램 활동다이어그램 activity diagram : 객체에작용하는활동의흐름을표현하는다이어그램 상호작용다이어그램 interactiondiagrams 순차다이어그램 sequence diagram : 객체들간의상호작용을시간적순서를강조하여표현하는다이어그램 협동다이어그램 collaboration diagram : 객체들간의상호작용을공간적협조체계를강조하여표현하는다이어그램 구현다이어그램 implementation diagrams 컴포넌트다이어그램 component diagram : 컴포넌트들의관계를표현하는다이어그램 배치다이어그램 deployment diagram : 시스템을구성하는물리적객체나장치들의관계를표현하는다이어그램 위다이어그램들은분석또는개발중인시스템에복합적인관점을제공한다. 모델은이러한관점들을통합하여일관성있는시스템이개발될수있게한다. 이다이어그램들과설명적인문서들이주된산출물이된다. ii. UML의범위바깥 프로그래밍언어 UML 은모델링언어로서프로그래밍언어는아니다. 복잡한알고리즘같은것은프로그래밍언어로표현하는것이나을것이다. UML 은객체지향언어와긴밀하게연결되어있으므로둘을동시에활용할수있어야한다. 도구 언어의표준화는필연적으로도구와공정을위한기반이된다. UML 이제공하는의미와표기법은도구의개발과호환성에도움이된다. 공정 UML 은공정에독립되어공통어로사용된다. 공정은프로젝트의성공을좌우하는중요한요소이지만조직과문화, 그리고주어진문제영역에맞추어재단되어야한다. Booch, OMT, OOSE 등많은방법론들은잘정의된공정을가지고있으며 UML 은대부분의방법론을지원할수있다. 개발공정에대한상당한수렴이있었지만아직표준화에대한합의에는이르지못했다. 아마도최상의경험들을융합하여개별적인공정을만들어낼수있는공정프레임웍이도출될가능성이있다. UML 은특정한공정을지정하지는않지만사용사례중심, 아키텍처중심, 점진반복적인공정을권장한다. e. UML 의과거, 현재그리고미래 UML 은 Rational 과그협력사들에의해개발되었다. 이는 Booch, OOSE/Jacobson, OMT 와그외의방법론에서제시하던모델링언어를계승
발전시킨것이다. 많은회사들이 UML 을표준으로받아들여업무모델링, 요구사항관리, 분석설계, 프로그래밍, 시험에걸친모든범위에서사용하고있다. UML 이전 1970 년대중반부터 1980 년대후반에걸쳐몇개의객체지향모델링언어가개발되어객체지향분석과설계에관한다양한접근방식을제시하였다. 1994 년에이르러서는모델링언어가 50 개가넘게되었다. 이들은어느하나만을가지고는완전한만족감을줄수가없었으며 방법론전쟁 이라는말이나돌정도였다. 그와중에서 Booch 93, OMT, Fusion 의방법론이주목을끌기시작했고이들은서로상대방의기법을융합하여 OOSE, OMT 2, Booch 93 의이름으로두드러지기시작했다. 이들각각은나름대로완전성을갖추고특정한영역에장점을가진것으로인식되었다. 간단히말하면, OOSE 는사용사례를중심으로하여업무엔지니어링과요구분석에탁월하였고, OMT 2 는분석과자료중심적인정보시스템에특히풍부한표현력을가지고있었다. Booch 93 은설계와구현단계에특히유용하고공학중심적인응용프로그램쪽에서많이사용되었다 Booch, Rumbaugh, Jacobson 이힘을합치다 UML 의개발이시작된것은 1994 년 10 월, Grady Booch 와 Jim Rumbaugh 가 Rational 사에서자신들의두방법론을통합하는작업을시작한때이다. 이미두방법론이세계적으로가장선도적인위치에있었기때문에이작업은통일의큰가능성을보여주었다. 1995 년 10 월에이작업의초안 0.8 이발표되었다. 1995 년가을에 Ivar Jacobson 과그의회사가 Rational 에합류하여 UML 은 OOSE(Object Oriented Software Engineering) 까지통합하게되었다. 이들은다른사람들의피드백을받아들이며 1996 년 6 월과 10 월에 UML 0.9 와 0.91 을발표하였다. UML 1.0 1.1 1996 년에 Object Management Group(OMG) 는객체지향모델링언어의표준화를위한제안요청서를발행하였다. 이에따라 Rational 은컨소시엄을결성해 UML 1.0 을생산하고이를 1997 년 1 월에 OMG 에제출하였다. 이때 IBM & ObjecTime 을중심으로한다른컨소시엄에서따로제안된것이있었으며이제안이역시 UML 에통합되어 1997 년 UML 1.1 로개정되었다. OMG 에서는 1997 년 11 월에 UML 1.1 을표준으로승인하였다.
UML 의현재와미래 OMG 는현재 UML 1.3 을확정하기위해노력하고있으며 1999 년중반에발표될예정이다. UML 은독점되지않으며모두에게개방되어있다. 이미전반적차원에서산업계의표준으로받아들여지고있다. 비록 UML 이정밀한언어를정의하고있지만그렇다고해서추후개선의여지가없는것은아니다. 새로운기법들이차후버전에추가될수있을것이며현재의 UML 은그핵심을기반으로확장해나갈수있도록되어있다. 많은도구들이 UML 을기반으로함으로써도구의통합이쉬어지고구현을위한표준들이가능해질것이다. UML 은많은개념들을통합시켜왔으며이에따라객체지향의사용이더욱가속화될것이다. 컴포넌트기반의개발은객체지향기술과맞물려있다. 최근컴포넌트기반의재사용이널리확산되고있지만그렇다고객체지향기술을대체하는것은아니다. 컴포넌트와클래스는의미에있어서단지미세한차이만을갖고있을뿐이다. 2. 사용사례 a. 액터와사용사례 시스템의요구사항은누가어떤용도로시스템을사용하는지에대한명세서이고이를간단하게액터와사용사례의관계로표현할수있다.
액터는개발하려고하는시스템과상호작용하는사용자또는외부시스템, 장치등을의미한다. 사용사례란사용자와컴퓨터시스템간의전형적인상호작용을의미하며시스템의기능을분류해주는역할을한다. b. 사용사례다이어그램 (Use case diagram) 사용사례다이어그램은시스템의요구사항을엑터와사용사례의관계로시각적으로표현한것이다.
3. 클래스다이어그램 클래스다이어그램은시스템을구성하는객체들의타입들과그들간에존재하는다양한정적관계들을기술한다. 정적인관계에는연관 (association) 과하위타입 (subtype) 이주로사용된다. 연관이란두클래스가관련이있다는것으로서예를들어수강관리시스템에서학생이강좌를신청할수있음을의미한다. 하위타입이란클래스간에상속을받는다는것으로서예를들어학생이등록사용자의일종임을의미한다. 또한클래스다이어그램은클래스의속성과연산및객체들의연결방법에적용되는제약조건들을기술한다. a. 연관 (Association) 연관은클래스간에관계가있음을나타낸다. 수강관리시스템에서학생이강좌를신청한다거나강좌에따른일정이존재한다는등의예를들수있다. 연관에는관계에참여하는객체의수를멀티플리시티로표시한다. 그림 4.1 에서보면, RegistrationUser 는여러개의 CourseOffering 을신청할수있으며한 CourseOffering 에는 3 명에서 10 명까지의 RegistrationUser 가등록할수있음을의미한다 b. 속성 (Attribute) 클래스의속성은클래스가어떤요소를가지고있음을의미한다. 그림 4.1 에서, RegistrationUser 의 name 속성은 RegistrationUser 가 name 을가지고있음을의미한다.
UML 에서는 visibility name: type = defaultvalue 와같이표기한다. 속성은 int 나 real 같은기본자료형일수도있고 string, date 등과같은작고단순한클래스일수도있다. 드물게는크고복잡한클래스를속성으로가질수도있다. c. 연산 (Operation) 연산이란클래스가수행하는처리로서메소드라고도한다. UML 에서는 visibility name (parameter list) : return type expression { property string } 과같이표기한다. visibility 에는 + (public), # (protected), (private) 의세종류가있다. d. 일반화 (Generalization) 일반화는공통된속성또는연산을가진클래스들에서공통요소들을추출하여상위클래스를만들어내는것을의미한다. 학생, 교수등의클래스에서등록사용자라는클래스를추출해내는것과같다. 이때등록사용자에대한모든사항은학생에게도똑같이적용된다고볼수있다. 공통요소를추출하는것과반대방향으로새로운요소를추가하여하위클래스를만들어내는것은특수화라고한다. 명세관점에서보면일반화란하위타입의인터페이스가상위타입의인터페이스로부터모든요소를포함한다는것을의미한다. 구현관점에서보면일반화는프로그래밍언어의상속과연관되어있다. 하위클래스는상위클래스의모든메소드와속성을상속받고상속된메소드를재정의 (override) 할수있다. e. 제약규칙 (Constraint Rule) 클래스다이어그램에는많은제약사항을기록한다. 그림 4.1 은한 CourseOffering 에는 3 명에서 10 명까지의 RegistrationUser 가등록할수있음을나타내고있다. 연관, 속성, 일반화등을통해서위와같은중요한제약조건들을규정할수있다. 그외의제약조건들은중괄호 {} 사이에기술한다. 특별한문법은정해져있지않으며읽기쉬운자연어를쓰든가좀더명확한논리적기술또는단편적인프로그램코드를사용해도좋다.
4. 상호작용다이어그램 (Interaction Diagram) 상호작용다이어그램은여러객체들이어떤일을처리하기위해서협동하는행동양식을기술하는모델요소이다. 전형적으로하나의상호작용다이어그램은사용사례하나의행동양식을포착하여나타낸다. 다이어그램에는사용사례에관련된객체들과그들간에주고받는메시지가표현된다. 상호작용다이어그램에는순차다이어그램 (sequence diagram) 과협동다이어그램 (collaboration diagram) 의두종류가있다. a. 순차다이어그램 (Sequence diagram) 순차다이어그램에서는객체를수직쇄선위에상자모양으로표시한다. 이수직선을객체의생존선 (lifeline) 이라고하며상호작용동안의객체의생존을나타낸다. 각메시지는두객체생존선간의화살표로표현한다. 이메시지가발생하는순서는위에서아래로순차적으로표시한다. 그림에서보듯이순차다이어그램은무척단순하고즉각적인시각적매력을갖고있으며따라서자주사용된다. b. 협동다이어그램 (Collaboration Diagram) 협동다이어그램은순차다이어그램과같이상호작용을나타내는또다른표현기법이다. 순차다이어그램에서와같이객체들은상자모양아이콘으로표시한다. 객체들이주고받는메시지역시객체간의화살표로표시한다. 사용사례를구현하기위한메시지의순서는메시지에번호를매겨표시한다. 다음그림은앞의순차다이어그램과같은내용을협동다이어그램으로다시표현한것이다.
메시지에번호를매기는것은순차다이어그램보다순서를보기에불편한점이있다. 반면에객체들을공간적으로배치시킴으로써아키텍처등다른중요한정보를강조할수있다. c. 순차다이어그램과협동다이어그램의비교 순차다이어그램과협동다이어그램은같은내용을다르게표현하는기법이다. 엄밀히말하면협동다이어그램은자료의반환흐름 (data return flow) 을표현할수있다는점이다르다. 두그림은상황에맞추어, 개인적인취향에따라, 바꾸어사용할수있다. d. 언제상호작용다이어그램을사용하는가? 상호작용다이어그램은하나의사용사례안에서객체들의행동양식을표현할때에사용한다. 행동양식의정밀한정의를표현하기에는적절하지않다. 여러사용사례에걸친한객체의행동양식을표현할때에는상태전이다이어그램을사용한다. 여러사용사례에걸쳐있거나쓰레드가많은행동양식을표현할때에는활동다이어그램을사용한다.
5. 유스케이스 (Use Case) UML 에서는사용자의목적달성을위해시스템이제공해야하는서비스와서비스를제공하기위한과정을유스케이스로표현한다. a. Use Case 의정의 유스케이스란개발될시스템의개개액터가시스템사용목적을잘달성할수있도록개발될시스템이제공해야하는서비스이다. 유스케이스는타원아이콘의아래에유스케이스이름을작성한다. b. Use Case 이름 유스케이스정의를통해우리는유스케이스가액터의시스템사용목적단위로작성되어야함을알수있다. 따라서유스케이스는액터의시스템사용목적으로식별하고, 이름은액터의시스템사용목적에서비스를붙여서작성한다. c. Use Case 와시나리오 개발될시스템이액터에게제공해야하는유스케이스를찾고난후우리는어떻게하면그유스케이스를액터에게가장효율적으로제공할것인가를고민해야한다. 액터가시스템을사용하면서벌어질여러가지상황들을가정해서일련의시나리오들을작성해야한다. d. 이벤트플로어 액터의시스템사용시나리오를잘작성하기위해서는시나리오작성방법에대해알아야하며그러기위해서는액터와시스템의역할과책임에대해서알아야한다. 액터의책임 시스템에게서비스수행을시작하도록요청해야한다. 시스템이요구하는정보를제공해야한다. 시스템과의상호작용과관련된의사결정을한다. 시스템의책임 액터로부터제공받은정보나시스템의서비스수행상태를기록해야한다. 서비스를시작하거나시스템이요청한행위를수행하는데액터가필요로하는정보를제공해야한다. 서비스를제공해야한다. 액터의시스템사용목적을달성하기위해액터와시스템에의해수행되는행위들의흐름은결국사건의흐름에따라진행된다. 사건의흐름을영어로는이벤트플로어 (Event Flow) 라고한다.
6. 관계 (Relationship) 액터와시스템같이목적달성을위해고안되고시도되는커뮤니케이션을목적지향적인커뮤니케이션이라고한다. 즉액터와시스템은목적지향적인커뮤니케이션을하고있는것이다. a. 엑터와유스케이스의관계 액터와유스케이스사이에작성되는연관 (association) 은액터가시스템의어떤기능을사용하기위해서시스템과상호작용하는가를나타낸다. 액터와유스케이스사이에실선으로작성된다. b. 엑터와엑터의관계 액터들사이에는단지일반화관계만이존재한다. 액터의일반화관계가의미하는것은하위액터가상위액터의모든역할과책임을상속받는것을의미한다. c. 유스케이스와유스케이스의관계 유스케이스와유스케이스사이에는추가적으로포함 (include) 과확장 (extend) 이작성된다. 공통부분에해당하는유스케이스와이를포함하는유스케이스의관계에는 include, 확장되는유스케이스와확장하는유스케이스의관계에는 extend 키워드를갖는의존관계기호로표현한다. d. 엑터와관련된문제들 액터가없는유스케이스 시스템이존재하는이유는액터의시스템사용목적을달성하도록하기위해서다. 따라서액터가없는유스케이스는존재할수없다. 잘못된유스케이스이름 유스케이스를찾을떄중요하게거론되는것이액터에게측정가능한 가치 (value) 를제공해야한다는것이다여기서가치라는단어를잘못이해하게되면유스케이스이름이너무추상적으로작성된다. 가치 라는단어를생각할때는반드시잊지말아야할것이시스템을사용해서얻는가치라는것이다. e. 관계와관련된문제들 일방향연관으로표현된액터와유스케이스 액터와유스케이스의상호작용은항상액터의요청에의해시작된다고하였기때문에커뮤니케이션의시작을표현하기위한액터에서유스케이스로의화살표표시는무의미하다. 단일유스케이스에포함되는유스케이스 포함관계는유스케이스의이벤트플로어들에공통된부분이발견되었을때작성하는관계이고, 공통된부분이발견되었다는것은두개이상의유스케이스들에서공통부분을갖고있다는것을의미한다.
7. 상태 (State) 포함관계가나타나면항상두개이상의유스케이스들이공통부분에해당하는유스케이스를포함해야한다. a. 이벤트 (Event) 객체의서비스수행을요청하는일들과시간의경과, 조건의변경 b. 이벤트종류 오퍼레이션을직접적으로호출하는이벤트를오퍼레이션호출이벤트라고하고, 시그널을전송하는이벤트를시그널전송이벤트라고한다. 시간경과를나타내는이벤트를시간이벤트 (Time Event) 라고하고, 외부조건의변경을변경이벤트 (Change Event) 라고한다. c. 오퍼레이션호출이벤트 오퍼레이션호출이벤트는직접적으로객체의오퍼레이션을호출할때발생하는이벤트이다. 오퍼레이션호출이벤트는객체의상태를변화시킬수도있고, 상태를변화시키지않을수도있다. 객체의상태를변화시키는이벤트가상태머신에표현된다. 이벤트이름은오퍼레이션이름과오퍼레이션의매개변수들을사용해서작성한다. d. 시그널전송이벤트 시그널전송이벤트에의해송신객체에시그널이보내진다. 시그널은화재경보장치등에서보내는경보음과같이비동기적으로전달되는신호를나타낸다. 시그널은 <<signal>> 키워드를갖는분류자기호로표현한다. 그림은외부침입이발생했다는신호를표현한것으로속성으로침입자의이동속도를갖는다. 시그널전송이벤트는시그널이름을이벤트이름으로사용하고, 시그널속성을이벤트의매개변수로사용해서 attack(10) 과같이작성한다. 객체의행위는오퍼레이션으로명세되고, 객체는오퍼레이션호출이벤트에대응하는오퍼레이션을수행한다. 시그널전송이벤트에대응하는행위는 <<signal>> 키워드를갖는오퍼레이션기호로나타낸다. e. 변경이벤트 변경이벤트는하나이상의속성들이나링크들의변화로서불린식이참이될때발생하는이벤트를명세합니다. 변경이벤트는일반적으로 when 현재날짜 > 주문일자 +14 와같이키워드 when 을사용해서표현할수있습니다. f. 시간이벤트 시간이벤트는설정된시간만큼시간이경과하거나설정한시간이되면발생하는이벤트입니다. 시간의경과는시간측정을시작했을때를기준으로경과되는시간을나타내기위해 after(5 초 ) 와같이 after 라는키워드를사용합니다. 특정시간을설정할때는 2003 년 11 월 5 일오후 와같이일반적인시간표현방법을사용합니다
g. 상태머신 (State Machine) 상태머신다이어그램은상태머신을명세하는다이어그램입니다. 상태머신은객체의상태를명세하기위해서도사용되지만객체가수행하는역할들을명세하는인터페이스의상태를명세하기위해서도사용될수있습니다. h. 프로토콜상태머신 (Protocol State Machine) 인터페이스의상태머신을객체의상태머신이지켜야하는규약 ( 계약 ) 이라는의미에서프로토콜상태머신이라고합니다. 인터페이스는명세로서내부구현을갖지않기때문에구현부분에해당하는액션들을표현할수없습니다. 따라서프로토콜상태머신에표현되는상태들은진입액션과탈출액션과액티비티를갖지않습니다. 또한상태를저장할수없기때문에얕은이력과깊은이력을가질수없습니다. i. Protocol Conformance 관계. Protocol Conformance 는일반화관계나실현관계에사용되는프로토콜상태머신들사이의관계로상위프로토콜상태머신의명세내용을하위프로토콜상태머신이따라야합니다. j. 상태머신확장 상태머신은일반화가능하고, 하위상태머신은상태나전이를추가하거나재정의함으로서상위상태머신을확장합니다. 상태머신은확장을고려해서상태나전이가확장될수있는지의여부를명세해야합니다. 다른상태머신에서상태나전이가확장되지않는다는것을표현하기위해서그림과같이 {final} 이라는키워드를사용합니다. 확장하는상태머신은 {extended} 라는키워드를사용한다. 확장관계나실현관계를표현하기위해서상태머신은 <> 키워드를갖는분류자로표현할수있습니다.
k. 상태 상태란? 몇몇불변조건 (invariant condition) 들이유지되는동안의상황을모델링하는것이다. 객체는대응해야하는이벤트가발생되기를기다리는정적인상태와액티비티를수행하고있는동적인상태를가질수있다. 일반적으로정적인상태는 Connect 나 Connected 와같이표현한다. 자신의상태를수동적으로표현할때는과거형을사용한다. 동적인상태는 Connecting 과같이액티비티가수행하고있음을나타내기위해서진행형으로표현한다. l. 상태종류 객체의상태는다른상태를포함하는지의여부에따라단순상태와복합상태로구분됩니다. 단순상태는다른상태를포함하지못하는것이고, 복합상태는다른상태를포함하는것으로포함되는상태를하위상태라고부릅니다. 상태는액티비티기호와동일하게모서리가둥근사각형기호를사용합니다. 그림에서냉방중이라는진행형으로작성된상태이름을통해냉방을위한어떤액티비티가계속적으로수행되고있다는것을알수있습니다. 의사상태 의사상태는전이에대한제어구조를표현하는것. 상태들의전이에대한제어를위해 entrypoint, exitpoint, initial, deephistory, shallowhistory, join, fork, junction, terminate, choice 와같은의사상태 (PseudoState) 가존재합니다. 사용자들은의사상태를상태전이에대한제어구조로생각하면됩니다. 종료상태 (Final State) 종료상태는상태머신의모든전이가완료되었다는것을의미합니다. 복합상태에서종료상태가사용되고, 종료상태로전이가되었다는것은자신이포함하는모든상태들의전이가완료되었다는것을의미하고, 해당상태에서빠져나오게됩니다. 종료상태는액티비티다이어그램의종료점과동일한기호를사용합니다. m. 전이 (Transitions) 객체의한상태에서이벤트에의해다른상태로이동하는것을전이라고합니다. 객체는상태를변화시킬수있는이벤트가발생하고, 명세된경계조건변화를만족시킬때전이이전의상태에서명세된액션들을수행하고, 전이되는상태로들어갑니다. 전이는 이벤트이름 ( 인자리스트 )[ 경계조건 ]/ 액션리스트 와같은형식으로작성됩니다.
n. 복합상태 복합상태는다른상태를포함하는상태이다. 그림에서전진이상위상태이고, 1 단과 2 단과 3 단은하위상태입니다. 하위상태는상위상태의전이와액션들을상속받기때문에전진의하위상태들은모두중립버튼누름이벤트에의해중립으로전이됩니다. 중립에서전진버튼누림이벤트가발생하면전진의시작상태인 1 단이됩니다. 멈춤에의한이벤트에의한전이는전진상태와연결되어있기때문에 1 단과 2 단과 3 단모두가이전이를상속받습니다. 따라서전진의어느단계에있든지멈춤이라는이벤트에의해 1 단상태가될수있다. 전진상태는추상의의미를갖고, 실제구체적인상태는 1 단과 2 단과 3 단이됩니다. o. 서브머신상태 컴포넌트기반개발과같이부분들에해당하는상태머신. 서브머신상태는다른많은서브머신에서참조되어재사용될수있기때문에특정서브머신에종속되도록표현하면안됩니다. 컴포넌트의인터페이스와같이외부상태에서전이될수있는통로만을제공하면된다. 서브머신상태는서브머신상태로들어올수있도록진입점 (entry point) 을제공하고, 서브머신상태에서나갈수있도록탈출점 (exit point) 을제공합니다. 그림은서브머신상태가상태머신에서참조되는방법을설명합니다. 서브머신상태가상태머신에서사용될때의역할은에러를처리하는것이기때문에 HandleFailure 로이름이작성되었다.
8. 배치 (Deployment) a. 액티브클래스 (Active Class) 액티브클래스의객체들은능동적인객체들로서객체가생성되면서자신의행위를시작하고, 행위가완료되거나자신의제어흐름을가지고있는외부적객체에의해중단될때까지멈추지않고실행합니다. 액티브클래스의객체를액티브객체라고합니다. 적합한의미를갖는우리말로는 활성클래스 와 활성객체 가있습니다. 액티브클래스는그림과같이양쪽에수직선을갖는분류자기호로표현합니다. 액티브클래스를사용해서프로세스와쓰레드를모델링할수있습니다. 병행처리를계획해야하는시스템의경우액티브클래스를사용해서제어흐름에대한이름을작성할수있기때문에프로세스와쓰레드의계획과관리를용이하게합니다. b. 배치 (Deployment) 시스템개발에있어배치에대한모델을작성하는것은시스템이실행에대한요구사항에따라의사결정을하는것으로시스템의실행아키텍처라고할수있습니다. 요구사항과 강하게결합된컴포넌트들은어떤것인지?, 많은자원을요구하는컴포넌트는어떤것인지? 변화가예상되는것들은어떤것인지? 등의질문에따라구현된컴포넌트를배치하기위한계획을세웁니다. 잘못된배치계획은필요로하는공간보다적은공간안에서자신의역량만큼책임을수행하지못하는컴포넌트를만들거나, 필요하지않는공간을차지하면서시스템자원을낭비하는컴포넌트를만들수있습니다. 시스템배치모델은노드들과노드들을연결하는커뮤니케이션경로와노드에배치되는아티팩트들로구성되어있으며배치다이어그램에작성됩니다. c. 아티팩트 (Artifact) 아티팩트는시스템개발에관련된물리적인형태를갖는모든정보들을의미합니다. 아티팩트의예로는모델파일, 소스파일, 스크립트와바이너리의실행파일과 데이터베이스의테이블과개발산출물들과, 워드프로세스문서나메일메시지등이있다. 아티팩트는그림 11.2 와같이 <> 라는키워드를갖는분류자기호로표현합니다. 오른쪽상단에선택적으로노트기호와같은아이콘을사용할수있습니다. d. Manifestation 관계 Manifestation 은추상 (Abstraction) 관계의특수한형태로, 목록이라는의미를가지고있으며, 아티팩트에포함되는모델요소들을나타내기위한관계입니다. Manifestation 관계는그림과같이 <> 라는키워드를갖는의존관계로표현합니다.
e. 표준스테레오타입 아티팩트는개발되는시스템범위와관련된물리적파일을나타내는 <> 과파일의특수한형태들을나타내는 <<document>>, <<source>>, <<library>>, <<executable>> 을스테레오타입으로갖습니다. <<document>> : 문서와같은일반적인파일을나타낸다. <<source>> : 실행가능한파일로컴파일될수있는파일 <<library>> : 정적또는동적라이브러리를나타낸다 <<executable>> : 컴퓨터시스템에서실행되어질수있는프로그램파일을나타낸다. f. 노드 노드는실행시간에존재하고, 컴퓨터자원 (computational resource) 을나타내는물리적인요소이다. 노드는일반적으로컴포넌트가배치되어지는프로세서나장치를나타낸다. 노드들은네트워크구조를정의하기위한커뮤니케이션경로를통해서상호연결되어질수있다. 노드는육각형기호로표현합니다. 그림은 AppServer 라는노드의인스턴스를표현하고있습니다. g. 커뮤니테이션경로 (Communication Paths) 노드들사이의연결은커뮤니케이션경로라는특별한연관관계에의해서표현됩니다. 그림은 DBServer 가여러개의 AppServer 와메시지를교환한다는것을표현하고있습니다.
h. 장치 (Devices) 아티팩트가실행되기위해배치될수있는프로세싱기능을갖는물리적컴퓨터자원이다. 장치는특별한형태의노드로, 다른장치들을포함할수있으며 <> 라는키워드를갖는노드기호로표현할수있습니다. i. 배치관계 배치는의존관계의특수한형태로, 배치대상 ( 노드 ) 에아티팩트를할당하는관계입니다. 노드와아티팩트는분류자의특수한형태이기때문에배치관계는분류자의범위에서작성될수도있고, 인스턴스범위에서작성될수도있습니다. 배치관계는그림과같이노드에아티팩트를직접포함하는것과아래그림과같이노드에아티팩트이름을리스트하는방법이있습니다.
9. 컬레보레이션 (Collaboration) a. 기호 컬레모레이션의표현은그림과같이컬레보레이션이름을포함하는점선으로된타원기호를사용한다. 컬레보레이션내부에는컬레보레이션에참여하는역할과역할을연결하는커넥터가작성된다. 그럼에는판매가이루어지기위해서는구매자라는역할과판매자라는역할이필요하고, 그들사이에협력이요구됨을보여주기위해서구매자와판매자를커넥터로연결한다. 역할을구현하는클래스를명시하고자할때는역할이름뒤에 : 와클래스이름을작성한다. 아래그림은구성요소의클래스가 TaskQueue 와 SlidingBar 이고, 이들의구성요소들이수행하는역할이 Subject 와 Observer 임을보여주고있다. b. 어커런스 컬레보레이션에대한특별한상황에대한적용을컬레보레이션어커런스라고한다. 컬레보레이션어커런스는특수한상황에서의협력을나타내기때문에이것또한컬레보레이션이다. 쉽게말해서구체화된컬레보레이션이다. 예를들어, 특정항로를따라대상물들을목적지까지데려가야하는운항에는이동수단을조종하는역할과대상물들을보호하는역할과대상물의역할이있다. 운항은대상물을목적지까지데려가야하는목적을가지고있고, 그목적을달성하기위해서는여러역할들이필요하고, 그역할들의협력이요구되는컬레보레이션이다. 운항의특수한예로는항공기운항, 선박운항과같은것들이있습니다. 항공기운항의경우이동수단을조종하는역할은조종사이고, 대상물들은승객과화물이며, 대상물을보호하는역할은승무원이다. 항공기운항은운항이라는컬레보레이션의특수한사용에해당하는컬레보레이션어커런스이다. 또한항공기운항은조종사와승객과화물과승무원역할들의협력을나타내는컬레보레이션이다. 컬레보레이션은여러가지구체적인상황에서발생하는협력들을추상화한것으로행위의재사용을위한매우중요한요소다. 만약여러분이대부분의전자상거래에서필요한예약이나주문에대한컬레보레이션을잘명세한다면, 이컬레보레이션은많은시스템개발에서컬레보레이션어커런스로재사용될것이다. 컬레보레이션을정확히표현하기위해서는구조적인부분과행위적인부분을모두표현해야한다. 어떤요소들이협력하는가는구조적인부분으로,
협력을위해어떻게상호작용하는가는행위적인부분으로표현되어야한다. 일반적으로컬레보레이션의구조적인부분은컴포지트스트럭처다이어그램 (Composite Structure Diagram) 과같은스트럭처다이어그램 (Structure Diagram) 으로, 행위적인부분은시퀀스다이어그램 (Sequence Diagram) 과커뮤니케이션다이어그램 (Communication Diagram) 와같은인터렉션다이어그램 (Interaction Diagram) 들로표현한다. 컬레보레이션어커런스는그림과같이표현된다. 대안적인표현으로아래그림과같이나타낼수도있다. 개념에대한실체표현과같이컬레보레이션어커런스는이름다음에 ':' 을작성하고, 어커런스되는컬레보레이션이름을작성한다. 아래그림판매컬레보레이션의두개의컬레보레이션어커런스들로중개인에의한판매컬레보레이션을구성한것을설명하고있다. 중개인이라는역할은구매자의역할과판매자역할둘을모두수행하고있다.
10. 인터렉션 (Interaction) a. 메시지표현 메시지의이름은서비스요청내용을, 입출력매개변수들은책임과권한들로구성된다. 서비스를찾는단계에서작성되는메시지는어떤정보들이입력, 출력또는리턴으로사용되는지에대한의미만을표현하면된다. 요청메시지는 'Multiply(n1, n2)', 응답메시지는 'Multiply(_):resultValue' 로표현된다. 시뮬레이션이나테스트단계에서는요청메시지로 'Multiply(3, 5)', 응답메시지는 'Multiply(_):15' 와같이표현된다. b. 메시지분류 메시지들은수행하는일의성격에따라서비스를요청하는요청메시지, 요청에대한결과를리턴해주는응답메시지, 구성요소를생성하는생성메시지, 구성요소를소멸하는소멸메시지로나눠진다. 또한, 메시지를보낸이벤트와받은이벤트가알려졌는지에따라 Complete Message, Lost Message, Found Message 로나눠진다. 동기적인방법에서는서비스요청자가서비스를요청하고나면제어가서비스제공자로넘어간다. 서비스제공자가서비스수행을완료한후에야다시제어가서비스요청자에게넘어와서다음작업을수행하게된다. 비동기적인방법으로는서비스수행여부에상관없이제어권을잃지않고바로다음작업을수행할수있다. 전자와같은방법으로서비스요청을전달하는메시지를 Synchronous Message 후자와같은방법으로서비스요청을전달하는메시지를 Asynchronous Message 라한다. 동기적인방법에서요청된결과가있을때결과를넘겨주는메시지를응답메시지라한다. 시스템개발초기에는인터렉션에작성되는메시지가동기인지비동기인지정확하게결정하기가어려우므로간단한메시지표현으로비동기메시지의표현과같은머리부분이열려있는화살표를사용한다. 오퍼레이션호출은서비스요청자가직접적으로서비스제공자에게서비스를요청하는것이고, 시그널송신은서비스요청자가특정한신호를보내어간접적으로요청하는것응답메시지는결과를제공해주기를원하는서비스요청메시지에대응되는것으로특별한이름을사용해야하는경우를제외하고는서비스요청메시지의이름을따른다. 예를들어 foo(3) 에대한응답메시지는 foo(_):15 와같이작성된다. Complete Message 는보낸이벤트와받는이벤트모두알려진경우, Lost Message 는보낸이벤트는알려져있으나받는이벤트는알려지지않은경우, Found Message 는받는이벤트는알려졌으나보낸이벤트가알려지지않은경우이다. Lost Message 는메시지가목적지에도착되지않았다는것을의미하고, Found Message 는메시지의시작이메시지를기술하는범위밖에있다는것을의미한다. c. 생명선 참여자의이름은 ' 구성요소 / 역할이름 : 구성요소클래스 ' 와같은형태로작성된다. 컬렉션에서포함된부분을찾는표현식을 Selector 라한다. d. 인터렉션다이어그램 인터렉션다이어그램은인터렉션에대한그래픽표현입니다. 인터렉션은매우복잡한모델요소이고, 다양한관점을가지고작성할수있습니다. UML 2 는인터렉션의다양한관점에따른다이어그램들을제공합니다. 인터렉션다이어그램에는구성요소들의상호작용에있어시간제약을중요시하는
시퀀스다이어그램, 관계제약을중요시하는커뮤니케이션다이어그램, 시간제약을중요시하는타이밍다이어그램, 전체적인개괄을보고자하는인터렉션오버뷰다이어그램이있습니다. 모든인터렉션다이어그램은시퀀스다이어그램과같이 sd 라는키워드를갖습니다. 지금까지는인터렉션에대해서시퀀스다이어그램을주로사용해서설명하였습니다. e. 커뮤니케이션다이어그램 커뮤니케이션다이어그램은구성요소들이상호작용하는데있어어떻게관계를맺는지에중점을둔다이어그램입니다. 따라서커뮤니케이션다이어그램에는구성요소들을표현할수있는생명선과그들의연결과메시지로표현됩니다. 시퀀스다이어그램은시간적인순서로메시지들의전송순서를작성하기때문에메시지전송순서를분명하게표현하지않아도되지만, 커뮤니케이션다이어그램은하나의생명선에서여러개의메시지들을주고받기때문에메시지전송의선후행관계를알기어렵습니다. 따라서커뮤니케이션다이어그램에표현되는메시지는 1.1:myMessage 와같이메시지전송순서를명확히표현해야합니다. 번호의작성은제어의계층으로작성됩니다. 한제어안에서동시적으로처리되어야하는메시지들을포함하고있다면, '1.1.a:myMessage1, 1.1.b:myMessage2' 와같이일반적으로알파벳을사용하여작성합니다. 어떤메시지는반복적으로전송되거나, 또는조건에따라전송여부가결정되거나, 병행처리될수있습니다. 반복표현은 '*[i:=1..n]' 과같이별표다음에반복횟수를대괄호안에작성합니다. 조건표현은 [a>b] 와같이대괄호안에조건식을작성합니다. 병행처리는 * 와같이별표다음에두개의수직선으로작성합니다. UML2.0 에서는반복이나조건의표현식에대해서는표식형식을제시하지않고있기때문에, 가상코드나프로그래밍코드를사용할수있습니다. 그림은주문관리자가주문에게주문처리를요청하면, 주문은모든주문항목들에게주문처리를요청합니다. 모든주문항목에대해서반복하는메시지이기때문에반복기호별표를하고대괄호안에반복조건을작성하였습니다. 각각의주문항목은재고관리자에게해당하는물품이있는지확인을요청합니다. 재고관리자는재고가없으면구매항목에해당물품을추가하고, 재고가있으면해당물품을배송항목에추가합니다. 이메시지들은조건에의해처리되기때문에대괄호안에조건을작성하였습니다. 메시지에작성된화살표는메시지의방향을나타냅니다. 만약주문항목들에대해서병행처리를하고싶다면 1.1* [ 모든주문항목반복 ]: 주문처리 와같이작성할수있습니다.
f. 인터렉션오버뷰다이어그램 UML 이전버전에서의시퀀스다이어그램은시나리오의제어흐름을표현하기가어려웠습니다. UML 2.0 에서여러가지연산자들이추가되었지만여전히제어흐름을표현하기는어렵습니다. 제어흐름을가장잘표현할수있는것은액티비티다이어그램입니다. 하지만액티비티다이어그램은액티비티들을중요시하기때문에어떻게구성요소들이상호작용하는지는표현하기가힘듭니다. UML 2.0 에서두다이어그램의장점들을취합해서만든것이인터렉션오버뷰다이어그램입니다. g. 타이밍다이어그램 타이밍다이어그램은리얼타임시스템과같이시간에대한제약이중요하게다루어져야할때사용되는다이어그램입니다. 타이밍다이어그램은가로축에시간을표시하고, 세로축에상태를표시하여시간이지남에따라구성요소들의상태의변화를보여줄수있습니다. 상태다이어그램이개개의구성요소에대한상태를표현하는반면, 타이밍다이어그램은구성요소들사이의상호작용과상태변화를동시에보여줄수있습니다.
그림은사용자가이동전화를이용하여전화통화에대한타이밍다이어그램입니다. 생명선인 : 사용자 와 : 이동전화기시스템 은다이어그램의가장왼쪽에작성되며, 생명선은서로다른구획으로분리됩니다. 사용자는대기중상태에서이동전화기의플립열기버튼을누르면이동전화기는플립을자동으로엽니다. 이때플립열기라는메시지의전달로플립이열리기시작하는시점까지의시간은최소 0.1 초, 최대 0.5 초안에이루어져야합니다. 또한플립이완전히개폐되는시간은최소 0.5 초, 최대 1 초의시간이걸려야합니다. 플립이다열리고나면이동전화기시스템은플립열림상태가되고, 플립이다열렸다는메시지를사용자에게보냅니다. 사용자는플립열림메시지를받고전화번호를입력합니다. 사용자가전화번호를다입력하고난후에는연결버튼을눌러, 이동전화기에연결요청메시지를보냅니다. 연결요청을받은이동전화기는해당하는번호로연결을시도합니다. 이때소요되는시간은최소 5 초, 최대 20 초여야합니다. 연결이완료되면이동전화기는연결메시지를사용자에게보냅니다. 연결메시지를받은사용자는통화를시작합니다. 통화가완료된후에는사용자와이동전화기는모두대기상태가됩니다.
11. 상태다이어그램 (State diagram) 사용사례와시나리오는시스템의행동양식즉객체들의상호작용을기술하는기법이다. 때로는한객체의행동양식을기술할필요가있다. 상태전이다이어그램은한객체가자신의생명주기안에서취할수있는상태들과그상태간전이를일으키는이벤트들, 그리고상태간변화에서발생하는작용들을표현한다. 상태다이어그램은시스템의모든클래스에대해그릴필요는없으며의미있는행동양식을보여주는주요클래스들에대해서그린다. 가능한상태나이벤트역시필요에따라간단하거나복잡한수준으로표현한다.
12. 활동다이어그램 (Activity Diagram) 활동다이어그램은작업흐름과연계되어병행처리가많은행동양식을기술하기에특히유용한여러기법들을조합한것이다.
13. 컴포넌트다이어그램 (Component Diagram) 컴포넌트다이어그램은시스템을구성하는실제소프트웨어컴포넌트간의구성체계를기술하므로아키텍처를표현하기에좋다. 컴포넌트란용어는시스템의물리적구조를구성하는소스코드단위로부터부시스템같은실행프로그램에이르기까지다양하게지칭한다. 예를들어개별클래스의헤더와구현파일로부터그들을조합하여만들어진 EXE, DLL 등까지컴포넌트로표시할수있다. 이러한다양한수준의컴포넌트를사용하여시스템의아키텍처를표현한다. 컴포넌트다이어그램에는각컴포넌트를그리고컴포넌트간의의존성관계를화살표로나타낸다.