Introduction to OOAD using UML tools Software Engineering Team Report #1 Team 김영승 성두훈 원스타 조민경

Transcription

1 Introduction to OOAD using UML tools Software Engineering Team Report #1 Team 김영승 성두훈 원스타 조민경

2 개요 OOAD란무엇일까? 그리고또 UML이란것은무엇일까? 소프트웨어공학을하는사람이라면한번쯤은접해볼수밖에없는단어들이고, 또어떤사람은앞으로사용하게될것들이다. 간단하게말하자면, UML은 OOAD를좀더효과적으로수행할수있도록그래픽으로시각화해주는 CASE의하나라고할수있다. 이글에서는먼저간단하게 OO와 OOAD, 그리고 UML에대하여알아보고, UML의구성요소, 그리고 UML의가장핵심적인아니 UML의전부라고할수있는여러다이어그램의실제사용에대하여알아본다. OO(Object-Oriented) 객체지향의목적은실제세계의일부혹은전체를본뜬것이라는점이다. 속성과행동들이좀더많이반영된클래스일수록실제세계에더가까운모델이만들어진다. 간단한예로, 우리가사용하는컴퓨터의경우, 내부 CPU, M/B, HDD등의속성을추가하면좀더정확한모델이될수있을것이다. OO을이루는몇가지개념들객체지향개념은단지속성과행동만가지고는설명할수없는객체의성질을가진다. 가장흔히사용되는원리로추상화 (Abstraction), 상속 (Inheritance), 다형성 (Polymorphism), 캡슐화 (Encapsulation) 가있으며이에못지않게다루는것으로메시지전송 (Message Sending), 연관 (Association), 집합연관 (Aggregation Association) 이있다. 추상화 - 객체를모델링할때필요로하는만큼의속성과오퍼레이션을추출해내는것이다. 상속 하나의객체는클래스의인스턴스로서그클래스의모든특성을이어받는다. 이것을상속이라고한다. 상속은슈퍼클래스-서브클래스의관계를가지게된다. 즉, 슈퍼클래스로부터상속을받는서브클래스가생성되는것이다. 일반적으로 서브클래스는슈퍼클래스이다 라는식의관계가성립한다. 다형성 다른클래스인데같은이름의오퍼레이션이존재하는것으로각각의클래스는자신의오퍼레이션의동작형태를알고있다. 캡슐화 객체는자신의오퍼레이션을수행하고결과를내놓지만, 그오퍼레이션의동작원리는가려져있다. 즉, 각각의오퍼레이션의수행의결과는알수있지만, 어떠한과정에의해서이루어지는알수없게되어있는것이다. 이를정보은닉 (Information hiding) 이라고도부른다. 메시지전송 한객체가다른객체에게메시지를보내어떤오퍼레이션을수행하도록하면, 메시지를받은객체는지시받은대로해당오퍼레이션을수행하는것이다. 연관 (Association) 한객체가다른객체와관계를맺는다. 이관계는한개이상일수도있으며, 다중성과도관계가있다. 집합연관 하나의객체가다른여러객체들의조합에의해만들어진것으로, 예를들어, 컴퓨터는 CPU, M/B, HDD, 키보드, 마우스, 모니터등다양한객체의조합에의해서만들어진것을생각할수있다.

3 OOAD(Object-Oriented Analysis Design) OOAD란? 객체지향분석설계로 OOAD는객체그룹간의상호작용으로서시스템모델을접근하는소프트웨어공학이다. 각각의객체는클래스의특성, 상태, 그리고동작들에대해나타내고, 다양한모델은정적구조와동적행위그리고이러한객체의집합에대한런타임실행을볼수있게만들수있다. UML같은모델을표현하는많은표기법이존재하고있다. 객체지향분석 (OOA) 은시스템의기능적인요구사항분석을위한객체모델링기법을제공하고, 객체지향설계 (OOD) 는명세서구현에의한분석모델을잘만들수있도록한다. OOA는시스템이무엇을할지에중점을두고, OOD는시스템이어떻게할지에중점을둔다. Object-Oriented systems 객체지향시스템은객체의구성이고, 객체들의조합으로인해생기는시스템의작용결과이다. 객체들간의동작은서로메시지를송신하는것에의해결정된다. 메시지를송신하는것은함수를호출하는것과는다르다. 함수를호출하는것은해당함수를실행한다는단순한의미이지만, 메시지를송신하는것은객체가다른객체로부터수신한메시지에의해서실행해야하는것을결정하는것을의미한다. 동일한메시지가여러개의다른함수들에서실행될수있고, 이경우어느함수가실행의주체가되느냐에대해서는, 해당객체의상태에따라결정된다. 메시지송신 의실행은모델화의대상이되는시스템의아키텍쳐에의해다양해지고, 상호작용하는객체집합이동일컴퓨터내에배치되어있는지, 아니면여러개의컴퓨터에분산되어배치되어있는지에의해서다르다. Object-Oriented analysis 객체지향분석은시스템화의대상이되는 problem domain을대상으로하여분석하고, 이 domain에존재하는다양한정보의개념모델을만드는것을목표로하는과정이다. 분석모델에서는구현단계에서생길가능성이있는다양한종류의제약들에대해서는전혀고려하지않는다. 즉, 분석모델에서는, 시스템이어떻게구축되는가하는것은전혀고려하지않는다는것이다. 구현단계에서의제약사항들에관한것은다음과정인객체지향설계단계에서다루기때문이다. 객체지향분석작업의근원이되는것은, 기술된형식의요구사양, 앞으로의발전에관한기업전략을적은서류, 이해관계자나그외의관계자와의인터뷰등이있다. 시스템은다수의 domain에의해분할된다. 이분할은시스템이여러비즈니스와기술, 그리고다양한관심분야에관여하고있을때일어난다. 이렇게분할된시스템은, 각각개별적으로분석된다. 객체지향분석의결과물은개발하는시스템이기능적으로무엇을하는것이필요한가라는것을개념적인모델의형태로기술한다이어그램이나문서이다. 객체지향분석의결과물은 Use Case 및 UML 다이어그램, 그리고여러개의 interaction 다이어그램으로나타낸다. 이결과물은, 시스템의유저인터페이스를모의작성하여기술한자료를포함하기도한다. 객체지향분석의목적은고객의요구사항들을만족하는동작을수행할수있는컴퓨터소프트웨어를묘사한모델을개발하는것이다.

4 Object-Oriented design 객체지향설계는객체지향분석으로얻은분석모델을통하여, 다양한종류의제약조건을고려한실제구현가능한모델로변환하는과정이다. 여기서말한다양한종류의제약에는선택한아키텍쳐에인한제약, 비기능적제약 ( 기술적, 환경적제약등 ) 을포함한다. 구체적으로트랜잭션 throughput, 응답시간, 실행시의플랫폼, 개발환경, 프로그래밍언어등이있다. 객체지향설계에서는분석모델로명세화된많은개념을클래스와인터페이스대응시킨다. 객체지향설계의결과물은, 문제 domain에도달해시스템이어떻게구축될까를상세하게적은모델다이어그램과문서이다. UML UML(Unified Modeling Language) 이란? Requirement, design, implementation 등의시스템개발과정에서, 개발자간의의사소통을원활하게이루어지게하기위하여표준화한모델링언어이다. UML은글로써이루어진문서가아닌그래픽표기법 (graphical notation) 의집합으로, 단일메타모델 (meta-model) 을기초로하고있으며소프트웨어시스템, 특히객체지향 (object-oriented) 방식을사용하여구축되는소프트웨어시스템을표현하고설계하는것을도와준다. 이말은 UML 은그래픽적인정보를통하여사용자들에게정보를전달한다는것과화면에정보를표시하기위해메타모델을사용한다는것이다. 또한객체지향방식을사용하는소프트웨어시스템에서 UML을사용하여설계하면좋다는것을알수있다. UML의탄생배경 UML은 Grady Booch, James Rumbaugh, Ivar Jacobson의머리에서태어났다. Tree Amigo라고도불리는이세명은원래 80년대전반과 90년대초반까지객체지향분석설계분야에서각자의영역의방법론을연구해왔었다. 그들이발표한방법론은동일한분야의다른경쟁자들보다항상탁월한위치에있었으며, 세사람은 90년대중반에이르러각자의아이디어를교환하기시작하였고결국각자의방법을하나로모아합치기에이른다. 이렇게해서탄생한것이 UML이다. UML의드래프트버전은소프트웨어업계를뒤흔들기시작하였고, 그결과로돌아온피드백은바로변경점에반영되었다. UML을지지하는회사가늘어남에따라그결과 UML 컴소시엄이발족하게되었다. UML 컴소시엄의멤버로는 DEC, HP, Microsoft, Oracle, Rational 등이있었다. 1997년 UML 컨소시엄은 UML 버전 1.0을만들어내고, 오브젝트매니지먼트그룹 (OMG) 이표준모델링언어의제안서를제출하라는요구에따라이것을제출하였다. 그후, UML 컴소시엄은계속발전하였으며, OMG에다시상정된 UML 1.1은 1997년말에표준모델링언어로채택되었다. OMG는 UML의관리기법을받아들여 1998년에새로운수정안을발표하였다. UML 1.1 이후많은버전의 UML 버전이소개되었지만, 대부분의것들은 UML 1.1과크게달라진것이아닌기존의것의버그나문제점을수정한것이었다. 하지만 UML 2.0은기존의것에비해크게발전했다. 그리고이 UML 2.0 현재의 OMG 표준이다. 그후에도꾸준히 UML은발전하고있으며, 표준안으로발표된것은아니지만, 2007년에 UML 2.1과 UML 2,1,2를발표하였으며, 2009년 2월에는 UML 2.2를 2010년 6월에는 UML 2.3 버전이

5 출시되었다. UML 의구성 UML 은크게 Things, Relationships, Diagrams 으로구성되어있다. 1. Things는추상적인개념으로 UML을이용한모델링의기본요소이다. 1.1 Structure Thing - UML 모델의명사형으로모델의정적인부분이며개념적이거나물리적인요소를표현한다. - Class : 속성 (Attribute) 과동작 (Operation) 으로구성된객체를표현한사각형의박스이다. Student - grade : String - name : String + getgrade() : String + getname() : String Student

6 - Interface : 클래스또는컴포넌트의동작을명세화한 operation 들의집합이다. SuperMan Flyer - Use Case : 시스템이수행해야하는기능을기술한것으로타원형태로표현한다. Logout Login - Component : 객체지향에서모듈화된자원이다. Student.java - Node : 실행시에존재하는물리적인요소로서, 주로컴퓨터자원을표현한다. Server Printer 1.2 Behavioral Thing - UML 모델에서의동사형이다. - 모델의동적인부분이며시간과공간에따른행위요소표현한다. - Interaction : 행위를의미하며특정문맥에속한객체들간의 Message들로구성된다. Display

7 - State Machine : 객체의시간에따른변화하는상태를표현한다. Wating 1.3 Grouping Thing 모델을그룹화하여하나의요소로표현할수있도록해준다. - Package : 요소들을그룹으로묶는방법이다. - Framework, 서브시스템표현시사용한다. Bank 1.4 Annotation Thing - UML 모델요소를설명하고, 명확히하는표현방법이다. - Note : comment로서모델요소를명확하게표현설명하기위한방법이다. - 주로제약조건이나내용을설명한다. 클래스설명 2. Ralationships은구성요소들간의의미있는연관성을표현하고, 주로클래스간의관계를표현한다. 2.1 Dependency Relationship - 한클래스가다른클래스를사용하는사용관계로, 하나의클래스의변화가다른클래스에영향을주는관계를나타낸다. - UML 표기법은점선으로된화살표로표현한다. 2.2 Generalization Relationship - 일반화 (Generalization), 특수화 (Specialization) 관계가있으며, 이것은객체지향의상속의개 념이라고생각할수있다.

8 2.3 Association Relationship - 클래스로부터생성된객체간의일반적연관관계다 Aggregation Relationship - 두클래스간의전체-부분관계 (Whole-part) 로이루어진다. - 각클래스가독립적인생명주기를갖는다. - 하나의클래스가여러개의컴포넌트클래스로구성된다.

9 2.3.2 Composition Relationship - 두클래스간의부분-전체관계를이룬다. - 부분의생명주기가전체의영향을받는다 - 하나의클래스가여러개의컴포넌트클래스로구성된다. 2.4 Realization Relationship - 인터페이스와실제구현된클래스간의관계다. 3 Diagram : Things + Relationship 3.1 Use Case Diagram - 사용자관점에서논리적인시스템의기능을정의한다. - 시스템구축초기에이시스템이어떤일을하는지에대해사용자입장에서이해할수있을정도로기술한다. - 시스템전체의개발범위를결정한다.

10 3.2 Class Diagram - 시스템내부의클래스의속성과행위를기입하고각클래스간의관계를정의한다. 3.3 Sequence Diagram - 시스템의동적인면을나타내는 Diagram이다. - 시스템실행시생성되고소멸되는객체와객체들사이에주고받는메시지를나타낸다. - 횡축은시간의흐름을나타내며메시지의순서에중점을둔다.

11 3.4 Collaboration Diagram - 메시지의흐름과객체와객체들사이의관계를나타낸다 3.5 Statechart Diagram - 한객체의상태변화를다이어그램으로나타냄

12 3.6 Activity Diagram - Activity 의수행순서와처리흐름을나타낸다. 3.7 Deployment Diagram - 실제하드웨어적인배치와연결상태를나타낸다. 3.8 Component Diagram - 소프트웨어의물리적단위의구성과연결상태를나타냄

13 3.9 Object Diagram - 클래스 Instance 간의관계를보여준다. UML 다이어그램 UML의여러가지그래픽요소는하나의큰그림, 즉다이어그램을그리는데사용된다. UML은언어이기때문에, 이들그래픽요소들을서로맞추는데에는규칙이필요하다. 이규칙은각각의다이어그램을통해자세히알아보고, 그전에다이어그램에대해서알아보자. 다이어그램의목적은시스템을여러가지시각에서볼수있는뷰를제공하는것이며, 이러한뷰의집합을모델이라고한다. 1. Use Case 다이어그램 Use Case는기능적인요구사항을수집하는데있어서매우강력한도구이며, Use Case 다이어그램은더욱강력하다. Use Case 다이어그램은 Use Case를시각화하기때문에분석가와사용자, 분석가와고객간의의사소통을원활히해준다. Use Case 다이어그램에서 Use Case나타내는기호는타원이며 Actor를나태는기호는막대인간이다. Actor와 Use Case 사이는실선으로연결

14 하며, Use Case는대개시스템경계를나타내는사각형에둘러싸여있다. Use Case 분석을하면얻을수잇는이익중하나는시스템과외부세계와의경계를효과적으로보여줄수있다는점이다. Actor는대개시스템의외부에잇는반면, Use Case는시스템의내부에있다. 이때시스템과외부세계의경계는사각형을그려서구분하며, 이사각형은시스템의쓰임새를둘러싸는상태로만든다. 이형태를 Use Case 모델이라고한다. Use Case는시나리오로진행되며, 각시나리오는진행단계로이루어진다. 하지만, 진행단계는다이어그램에나타나있지않다. 그렇다면시나리오의진행단계는어떻게작성해야할까? Use Case 다이어그램은대개의뢰인과개발팀이참조하는설계문서의한부분으로사용된다. 각다이어그램은한페이지당하나씩그려지는것이보통이며, 각 Use Case를구성하는시나리오는각각의페이지에다가텍트로적어두면된다. 시나리오는다음과같이작성한다. Use Case를시작하는 Actor Use Case가시작하는데필요한선행조건 시나리오의진행단계 Use Case가끝나는데필요한종료조건 Use Case의결과를받는행위자필요시에는가정도세울수있으며, 한문장정도의설명문도적어둘수있다. 이외에 Activity 다이어그램으로도표현이가능하다. Use Case에서중요한또하나는 Use Case 사이에도관계를가질수있다는것이다. 첫째는포함관계로서, 다른 Use Case에서기존의쓰임새를재사용하고있는관계이고, 둘째는확장관계 포함관계를나타낸 Use Case 모델

15 로서, 기존의 Use Case 에진행단계를추가하여새로운 Use Case 로만들어내는관계이다. 이 외에일반화와그룹화가있다. 일반화는한 Use Case 가다른 Use Case 를상속한관계이며, 그 룹화는여러개의 Use Case 를조직화하는단순한방법이다. - 포함아래그림을통해볼수있다. Restok과 Collect Use Case는둘다자동판매기의보안장치를해제하고앞문을열며, 앞문을닫고보안장치를거는단계를가지고있다. Expose the inside Use Case는전자의단계에, Unexpose the inside Use Case는후자의단계에해당한다. 이렇게포함된 Use Case는절대로단독으로존재할수없으며, 전체 Use Case의부분으로만존재한다. - 확장포함관계와비슷하게의존관계선을사용하여연결함으로써나타내며, <<extend>> 스테레오타입을붙여줌으로써끝맺는다. 기본 Use Case내의확장포인트는 Use Case의이름아래에위치시킨다. - 일반화클래스가다른클래스로부터상속받을수있듯 Use Case도상속이가능하다. Use Case 상속의경우, 자식 Use Case는부모 Use Case가가진모든행동과의미를물려받으며, 여기에 자신만의행동을추가할수도있다. 또한, 부모 Use Case 등장한곳에는항상자식 Use Case 를대신놓을수있다. 이것은 Use Case뿐만아니고 Actor사이에도있을수있다. - 그룹화 Use Case 다이어그램은여러개의 Use Case를가지고있는형태로나타날수있다. 이때 Use Case를조직화하는것이좋다. 시스템이여러개의서브시스템으로구성되어있거나시스템에대한요구사항을수집하기위하여사용자의의견을조사할때가조직화에알맞은경우이다.

16 조직화는하나의패키지로그룹화하는것이가장간단하방법으로, 패키지를나타내고이안 에관련된 Use Case 를넣으면된다. 2. Statechart 다이어그램 2.1 상태다이어그램이란? 시스템에일어나는변화를표현하는방법중한가지는 사건이나시간에따라시스템내의객체들이자신의상태 (state) 를바꾼다 고말하는것이다. 몇가지의예를들어보면다음과같다 스위치를누를때마다, 탁상전등의상태는켜지고꺼진다. 리모컨의버튼을누르면, 텔레비전의상태는한채널을보여주다가다른상태를보여주게된다. 얼마간의시간이흐르면, 세탁기의상태는세탁에서행굼으로바뀐다. 상태다이어그램은다른다이어그램과는근본적인차이점을보이고있다. 다른다이어그램들은시스템이나최소한한개그룹의클래스혹은객체의행동을모델링하는데사용되는것인데반해, 상태다이어그램은 단일객체 의상태를나타낸다. 2.2 상태다이어그램을구성하는기호 상태를나타내는아이콘은모서리가둥근사각형이며, 상태전이를나타내는기호는화살표머리가달린실선이다. 속을칠한원은상태흐름의시작점을나타내며, 종료점은원을둘러싼원으로나타낸다. 2.3 상태아이콘에넣는정보들상태아이콘에도클래스아이콘처럼세영역 ( 이름, 속성, 오퍼레이션 ) 으로나누어상세한정보를써넣을수있다. 가장위부분에는상태의이름이, 중간부분에는상태변수가, 가장아랫

17 부분에는활동이들어간다. 상태변수는타이머나카운터처럼상태진행에도움을주는데이터이다. 활동은사건과동작 으로이루어져있으며, 자주쓰이는세가지는잘알아두는것이좋다. 진입 (entry) 시스템이상태로들어갈때일어남 탈출 (exit) 시스템이상태에서빠져나올때일어남 활동 (do) 시스템이상태안에있는동안일어남 2.4 상태전이선에추가되는정보 : 사건과동작 GUI를예로들어보자. 일단 GUI는다음의세가지상태중하나에있을수있다. 초기화 (initializing) 작동중 (working) 끝마무리 (Shutting Down) PC를켜면, 부팅이수행된다. 따라서 PC를켜는일은 GUI가 Initializing 상태로전이되도록하는촉발사건이며, 부팅은이상태전이가수행되는도중에일어나는동작이다. Initializing 상태에설정된활동의결과로, GUI는 Working 상태로전이된다. 여기서 PC를끄게되면 Shutting Down 상태로전이되도록하는촉발사건이만들어지고, 결국 PC는꺼진다. 2.5 상태전이선에추가되는정보 : 전이조건만약 Working 상태에서사용자의입력이 15분간없을때 Screen saver가작동한다고하자. 여기서 15분 의시간간격을 UML에서는전이조건이라고한다. 즉, 이조건이만족되면연관된전이가일어나는것이다. 아래그림은 Screen saving 상태와이상태와관련한전이조건이추가된 GUI의상태다이어그램이다. 전이조건은 Bollean 수식으로표현한다.

18 2.6 하위상태 GUI가 Working 상태에있을때일어나는동작들은무척다채롭고복잡하다. GUI는사용자가키입력, 마우스이동, 마우스버튼등등어떤일을하는지를기다리고있다. 사용자의입력이들어오면 GUI는이것을등록하고적절한동작이수행한결과를화면에나타낸다. GUI는이렇게 Working 상태안에있는동안에도변화한다. 이러한변화는상태의변화이며, 주어진상태내부에서일어나는것이기때문에하위상태라는이름으로불린다. 하위상태는두가지로나뉜다. 하는순차적하위상태이며, 또하나는동시적하위상태이다. - 순차적하위상태순차적하위상태는차례차례로이어진다. GUI의 Working 상태내에서변화는다음과같은순차적인흐름으로정리할수있다. 사용자입력을대기 사용자입력을등록 사용자입력을화면에나타냄 사용자입력은사용자입력대기상태에서부터전이를촉발시킨다. 사용자입력등록상태내에서활동은해당상태를사용자입력을화면에나타내는상태로전이시킨다. - 동시적하위상태 GUI는시스템클럭도체크하고특정한시간간격이지나면애플리케이션디스플레이도갱신해야한다. 시스템클럭을체크하고디스플레이를갱신하는일은순차적하위상태이지만, 입력을대기하고갱신하는순차적하위상태와동시에진행되고있다. 이러한동신진행성은순차적하위상태사이를점선으로구분지음으로써설정할수있다.

19 2.7 이력상태 UML은어떤기호를써서복합상태로하여금주어진객체가복합상태를벗어날때활성중인하위상태를기억해두도록한다. 이기호는원으로둘러싸인 H 문자로서, 이기호로나타나는상태를이력상태라고한다. 2.8 메시지와신호 Screen saving 상태에서 Working 상태로전이하게하는촉발사건은키입력, 마우스이동, 마우스클릭이었다. 사실, 이사건들은사용자가 GUI에게보내는메시지이다. 객체들은서로메시지를주고받으며자신의행동을수행하기때문에이사실은매우중요한개념이다. 즉, 이경우촉발사건은한객체가다른객체로전송하는메시지라고할수있다. 2.9 상태다이어그램의중요성상태다이어그램은분석가, 설계자, 개발자들이시스템내의객체행동을이해하는데큰도움을준다. 클래스다이어그램과객체다이어그램은시스템의정적인모습만을보여줄뿐이다. 즉, 계층, 연관, 행동이 어떠한가 에만초점을두고있지, 각행동의동적인상황은보여주지않는다. 특히, 개발자는객체자체를소프트웨어로구현해야하기때문에객체들이어떻게행동하는지를정확히파악하여야한다. 개발자는객체를구현하는것으로충분치않으며, 그객체에게무엇인가를시켜야한다. 상태다이어그램은 객체가어떤행동을하도록되어있는지 에대해개발자들이고민할필요가없도록만든다. 객체의행동이명확하게그려져있는상태다이어그램이있기에, 개발팀이요구사항에맞는시스템을구축할가능성이더높아지는것이다.

20 3. Collaboration 다이어그램 Collaboration 다이어그램은객체다이어그램을확장한것이다. 객체사이의연관관계뿐만아니라, 각객체들이주고받는메시지들을나타낸다. 메시지는두객체사이의연관선과가깝게화살표를그려주면된다. 화살표는메시지를받는객체를향한다. 화살표에는레이블을달아이메시지가어떤메시지인지를명시해주어야한다. 이렇게설정된메시지는대개 메시지를받는객체로하여금어떤오퍼레이션을실행하라 는뜻이다. 메시지의끝에는괄호 (()) 가놓인다. 필요하면이괄호안에매개변수를써넣을수도있다. Collaboration 다이어그램은순차적인흐름정보도나타낼수있다. 이를위하여메시지에번호를매겨각메시지의처리순서를나타낸다. 번호와메시지사이는콜론 (:) 으로구분한다. 3.1 GUI의 Collaboration 다이어그램이예제는단순한경우이다. 행위자는키입력으로 GUI의동작을시작하게하며, 메시지는순차적으로발생한다. 각진행단계는다음과같을것이다. 1. GUI는키입력을운영체제에게알린다. 2. 운영체제는 CPU에게그사실을알린다 3. 운영체제는 GUI를갱신한다. 4. CPU는비디오카드에게 GUI 갱신에필요한명령을내린다. 5. 비디오카드는모니터로메시지를전송한다. 6. 모니터는화면에알파뉴메릭문자를표시하여사용자에게피드백을제공한다.

21 3.2 상태변화의추가 Collaboration 다이어그램에객체의상태변화를나타낼수있다. 객체사각형안에객체의상태를나타낸다. 다이어그램에변경된상태의객체를나타내는사각형을하나더그려넣는다. 3.3 객체의생성객체의생성을다루기위해컨설팅기업의 LAN 구축의 Create a Proposal Use Case에대해알아보자. 모델링할진행단계는다음과같다 1. 컨설턴트는기존의제안서를사용했으면하기때문에, 네트워크에물려있는중앙저장소에서적당한제안서를찾는다. 2. 만일컨설턴트가적당한제안서를찾아내면, 이파일을열고, 이과정에서오피스도구모음소프트웨어가실행된다. 컨설턴트는이파일을새로운이름으로저장하고새제안서를위한새파일을만든다. 3. 만일컨설턴트가제안서를찾아내지못했다면, 오피스도구모음소프트웨어를실행시키고제안서를위한새파일을만든다. 4. 제안서를작성하는동안, 컨설턴트는오피스도구모음소프트웨어가가진애플리케이션을사용한다. 5. 컨설턴트가제안서작업을마쳤을때, 컨설턴트는중앙저장소에이제안서를저장한다. 객체의생성을나타내기위해서는객체를생성하는메시지에 <<create>> 스테레오타입을붙여주면된다.

22 3.4 그외의개념들 - 다중객체로의메시지전송동일한클래스에서만든여러개의객체에게메시지를보내는경우가있다. 예를들어, 교수는여러학생에게숙제를내라고말할수있다. 이것을 Collaboration 다이어그램으로나타내려면객체사각형을사선방향으로쌓는다. 그리고객체로전송되는메시지에는애스터리스크가붙은대괄호조건문을붙여준다. 메시지를보내는순서가중요한때가있다. 은행원은창구에늘어선고개들을순서대로맞 아서비스를해준다. 이상황은순서 ( line position = 1 n ) 를고려한 while 조건으로나타 낼수있다.

23 - 반환된결과나타내기 오퍼레이션의결과값반환은 반환되는값의이름 := 오퍼레이션 형태의수식을써줌으로 써나타낼수있다. 이러한수식을메시지 - 시그니쳐라고한다. - 활성객체객체간의교류에있어서특정한객체가흐름을제어하는경우가있다. 흐름을제어하는이객체를활성객체라고하며, 활성객체는수동객체에게메시지를보내며다른활성객체들과교류한다. 도서관을예로들면, 사서는고객의요청을받아데이터베이스로부터참고정보를찾아알려주며, 일꾼에게책을다시꽂아두라는등의책임을할당한다. 또한, 사서는자신과동일한일을수행하는다른사서들과메시지를주고받는다. 시스템내에서두개이상의객체가동시에작동될수잇는데, 이것을동시성이라고한다. 4. Class 다이어그램클래스다이어그램 (Class Diagram) 은클래스와클래스간의관계를통해시스템의전체적인모습을보여주는 Static Structure Diagram이다. 아래클래스다이어그램은사용자의쇼핑주문에대한모델링예제이다. 여기서중심이되는클래스는 Order인데, 이것은 Customer가 Payment를지불하도록되어있다. Payment는 Cash, Check 또는 Credit의세가지중하나다.

24 UML클래스표기는사각형안에클래스명 (class name), 속성 (attributes), 오퍼레이션 (operation) 의세가지부분으로나누어진다. Payment와같이추상클래스 (abstract class) 는이탤릭체로나타내고클래스간의관계는선으로연결된다. 위의다이어그램은세가지관계를가지고있다. Association -- 두클래스의인스턴스간의관계. 한쪽클래스의인스턴스는반드시반대편클래스에대해알고있어야만재대로작동할수있다. Aggregation -- 한클래스가컬렉션으로포함되는것을나타낸다. Aggregation은다이아몬드모양의끝이포함하는클래스를향하도록나타낸다. 위의다이어그램에서는 Order클래스가 OrderDetails의컬렉션을포함하고있다. Generalization -- generalization관계는상속 (inheritance) 특성을가진다. 상속연결은한클래스가다른클래스들의상위클래스 (super class) 임을나타낸다. 일반화는삼각형모양이상위클래스 (super class) 를향하도록표현한다. 위의다이어그램에서 Payment는 Cash, Check, Credit의상위클래스 (super class) 다. 하나의관계는두개의끝점 (end point) 을가진다. 끝점은연관의형태를명확히하기위해역할명 (role name) 을가진다. 예를들어, OrderDetail은각 Order의항목 (line item) 이다. Navigability은화살표가가르키는방향에있는클래스를탐색하거나질의할수있음을나타낸다. OrderDetail은그것의 Item에대해질의 (query) 할수있지만그반대로는할수없다. 화살표는누가관계에서구현을하는 " 주체 " 인지알수있게해준다. 이경우, OrderDetail은 Item을가지고있다. 연관에서화살표를생략할경우묵시적으로양방향관계를나타낸다. Multiplicity은하나의인스턴스에연관된다른쪽클래스의가능한인스턴스의수를의미한다. Multiplicity은하나의숫자또는수의범위로나타낼수있다. 위의예제에서는각 Order에하나의 Customer만연관이되지만, Customer는다수의 Order를가질수있다.

25 아래는일반적인다중성의표현방법이다. 표기법 의미 또는하나의인스턴스. n..m 표기법은 n에서 m까지의범 위 0..* 또는 * 0을포함한무한수. 제한없음 1 명백한하나 1..* 적어도하나이상 모든클래스다이어그램은 Class, Association, 그리고 Multiplicies 을가진다. Navigability 과역할 은다이어그램내에서의위치를명확히하기위한옵션이다. 모든클래스다이어그램은 Class, Association, Multiplicies을가지지만더많은정보를보여줄수도있다. 이미 Generalization, Aggregation, 그리고 Navigability에대해알아보았다. 지금부터다음의항목들에대해더알아보겠자. Composition 클래스멤버에대한 Visibility와 Scope Dependencies와 Constraints 인터페이스 (interfaces) 4.1 Composition and aggregation 객체가특정클래스의일부로속하는관계를 Aggregation이라했다. Composition은이보다더강한관계의의미로서객체가부모 (whole) 의일부일뿐만아니라부모없이는존재할수없는것을의미한다. Composition은집합의표기에서다이아몬드를채운형태로표현된다. 아래다이어그램은 BoxOffice가반드시 MovieTheater에속함을보여준다. MovieTheater를제거하면 BoxOffice도함께제거된다. 하지만, Movie 컬렉션은이처럼 MovieTheater와밀접하게연관되어있지않다. 집합은대부분의경우연관과특별히다른점이없다. UML 은명확한집합의정의를제공하지 않는다. 그렇기때문에집합에관해많은혼란이생겼으며실제 UML 2.0 에서집합은배제되 었다. 집합에서명확한규칙은두개또는그이상의객체가자기자신의부분이될수없고서

26 로상대객체의부분이될수없다. 즉, 객체간의관계의고리를만들수없다는것이다. 합성도집합과같은규칙이적용된다. 그리고, 합성은주인이피보호자의수명전체에책임을진다. 만약, 주인이복사되면피보호자도함께복사된다. 피보호자의한인스턴스를두주인이동시에소유할수없다. 합성이사용되는경우는 deep copy이다. 즉, 복사된값이별도로변경되는경우와같이특수한경우에사용될수있다. 4.2 visibility and scope 클래스표기는클래스명 (class name), 속성 (attributes), 오퍼레이션 (operation) 의세영역으로나 눈다. attributes 과 operation 은접근성 (access) 과범위 (scope) 에따라레이블을을붙일수있다. - static 멤버는밑줄로표현한다. 반대로, 인스턴스는밑줄이없다. - 오퍼레이션은다음의형식을따른다. < 접근구분자 > < 이름 > ( < 파라미터목록 > ) : < 리턴타입 > - 파라미터목록에서각타입은콜론 (colon) 뒤에따라온다. - 접근구분자는각멤버의맨앞에위치한다. + : public - : private # : protected 4.3 Dependencies과 Constraints Dependency은두클래스간의관계에서한쪽이변경되면다른한쪽도영향을받을경우를말한다. 종속성은점선으로표현된다. 아래클래스다이어그램에서 Co_op는 Company에종속적이다. 만일 Company를변경하기로마음먹었다면 Co_op또한변경해야된다.

27 Constraints 은디자인이연관이성립되기위해만족시켜야할구현조건을명시한것이다. Constraints 은중괄호 ( { } ) 사이에쓰여진다. 위의다이어그램에서 constraint 는 Section 이 CourseSchedule 의부분이될수있음을나타낸다. 4.4 Interfaces와 Stereotypes Interface는오퍼레이션시그니처의집합이다. C++ 에서인터페이스는순수한가상멤버 (virtual members) 로만구성된추상클래스 (abstract class) 처럼구현된다. 자바에서는직접구현된다. 아래의클래스다이어그램은컨퍼런스과정을모델링한예제이다. 여기서핵심적인클래스는하나의프레젠테이션을나타내는 SessionTalk 와하루에진행되는 SessionTalk의컬렉션인 Session이다. ShuttleSchedule과그리스트인 ShuttleStops은호텔에서기다리고있는참석자들에게매우중요하다. 이다이어그램은 ShuttleStops가순서화 (ordered) 되어있다는하나의 Constraints을가진다.

28 위의다이어그램은 IDated, ILocatable, ITimed 세개의인터페이스 (interfaces) 를가지고있다. 인터페이스의이름은일반적으로 "I" 로시작한다. 인터페이스명을포함한오퍼레이션시그니처들은이탤릭 (Italic) 체로표현되어있다. ShuttleStop은 ILocatable을구현 ( 또는구체화 ) 하기위해동일한오퍼레이션 (location():string) 을구현하고있다. ShuttleStop을 <<place>> 라는스테레오타입을가지고있다. 스테레오타입 (stereotypes) 은존재하지않는새로운종류의모델을정의하여 UML을확장시키는방법을제공한다. 그런의미에서인터페이스 (Interface) 또한스테레오타입의한종류라할수있다. 스테레오타입은 guillemets라는특수문자사이에삽입되지만통상 "<" 와 ">" 을두개씩겹쳐서 "<<", ">>" 으로표현하기도한다. 인터페이스 (Interfaces) 를 UML로표현하는데는두가지방법이있다. 아래다이어그램은위의다이어그램과동일하며 Lollipop, 또는 Circle 표기법이라부른다.

29 이표기법에서, 인터페이스는원형으로표현되며구현클래스와연결되어있다. 이표기법은 다이어그램의전체적인가독성을높이고단순화한장점은있으나상세한정보는표현되지않 는다. 5. Sequence 다이어그램시퀀스다이어그램은객체들간인터랙션을발생순서대로보여줄때쓰인다. 클래스다이어그램과마찬가지로개발자들은이시퀀스다이어그램이자신들을위한것이라고생각한다. 하지만영업부서의직원들역시비즈니스가어떻게돌아가고있는지를설명할때, 시퀀스다이어그램을사용할수있다. 기업의현업을문서화하는것외에도비즈니스레벨의시퀀스다이어그램은, 앞으로의시스템구현에필요한요구사항들을기록하는문서로서사용된다. 프로젝트의요구사항을분석하는동안분석가들은사용케이스를다음레벨에적용할수있다. 사용케이스들은보다잘정리되어시퀀스다이어그램안으로들어간다. 기업의기술부사원들은앞으로의시스템이어떻게작동해야하는지를문서화할때시퀀스다이어그램을활용할수있다. 디자인단계에서, 아키텍트와개발자들은이다이어그램을사용하여시스템객체의인터랙션을실행해보고, 전체시스템디자인을완성한다. 시퀀스다이어그램은주로형식적인정련단계에서사용된다. 사용케이스들은한개이상의시퀀스다이어그램으로세분화된다. 새로운시스템을설계할때사용되기도하지만, 시퀀스다이어그램은기존 " 레거시 (legacy)" 시스템의객체들이현재는어떻게인터랙팅하는지를문서화하는데사용될수있다. 시스템을이동할때문서화는매우유용하다. 5.1 표기법이 UML 2 다이어그램의표기법에추가된프레임엘리먼트는 UML 2의다른많은다이어그램엘리먼트의기초로쓰이지만, 처음에대부분의사람들은이프레임엘리먼트를다이어그램의

30 그래픽영역이라고생각한다. 프레임엘리먼트는다이어그램의레이블을위한지정된장소를제공하고, 다이어그램의그래픽영역을제공한다. 프레임엘리먼트는 UML 다이어그램에서는선택사항이다. 그림 1과 2에서보듯, 다이어그램의레이블은프레임의 " 네임박스 (namebox)" 라고부르게될왼쪽코너의상단에놓인다. 실제 UML 다이어그램은더큰직사각형안에서정의된다. 시각적으로경계선을표시하는것외에도이프레임엘리먼트는인터랙션을설명하는다이어그램 ( 시퀀스다이어그램 ) 에서도중요한기능도한다. 시퀀스다이어그램에서시퀀스에대한인커밍메시지와아웃고잉메시지 ( 인터랙션 ) 는, 이메시지들을프레임엘리먼트의경계선에연결하여모델링된다. 다이어그램을위한프레임엘리먼트를사용할때다이어그램의레이블은다음포맷을따라야한다. 다이어그램타입 (sd) 다이어그램명 (Diagram Type Diagram Name)

31 5.2 기초시퀀스다이어그램의주요목적은어떤결과를만들어내는이벤트시퀀스를정의하는것이다. 메시지보다는메시지가발생하는순서에초점이더맞춰진다. 대부분시퀀스다이어그램은 system 객체들간어떤메시지들이보내지는지, 그리고어떤순서로발생하는지를나타낸다. 다이어그램은이정보를수직적측면과수평적측면으로전달한다. 수직측면에서는탑다운 (top down) 방식으로메시지 / 호출이발생한시간순서를나타내고, 수평측면에서는왼쪽에서오른쪽으로메시지가보내진객체인스턴스를보여준다. 5.3 Lifelines 시퀀스다이어그램을그릴때 Lifeline 표기법엘리먼트는다이어그램상단에놓인다. Lifeline 은모델링되는시퀀스에개입된역할또는개게인스턴스들을나타낸다. Lifeline은박스의아래쪽중심에서대시 (dash) 라인을그리며내려간다. 이 Lifeline의이름은박스내부에있다 Lifeline 의 UML 의네이밍표준은다음포맷은따른다. 인스턴스명 ( 객체명 ) : 클래스명 위의예제에서, Lifeline은 Student 클래스의인스턴스를나타낸다. 이것의인스턴스이름은 freshman이다. Lifeline 이름밑에그어진밑줄에주목하라. 밑줄이사용될때는 Lifeline이한시퀀스다이어그램에서클래스의특정인스턴스를나타낸다는것을의미한다. 특정종류의인스턴스 ( 예를들어, ' 역할 ') 가아니다. 구조모델링에대해서도살펴볼것이다. 지금까지누가 (Bill과 Fred) 그역할을수행하는지를지정하지않은시퀀스다이어그램에는 buyer와 seller 등의역할이포함되어있다는것을알수있다. 이런경우다이어그램은다른정황에서도재사용된다. 시퀀스다이어그램에역할이름이아닌인스턴스이름에밑줄을긋는다. 위의 Lifeline 예제는네임드객체이다. 하지만모든 Lifeline이네임드객체를나타내는것은아니다. 대신익명또는이름없는인스턴스를나타내는데도 Lifeline이사용될수있다. 시퀀스다이어그램에이름없는인스턴스를모델링할때, Lifeline의이름은네임드인스턴스와같은패턴을따른다. 그러나인스턴스이름을주는대신에, Lifeline의이름의부분이공백으로된다. 그림 3을다시보자. 만약이 Lifeline이 Student 클래스의익명인스턴스를나타낸다면, Lifeline은 " Student." 이다. 또한시퀀스다이어그램은프로젝트의디자인단계에서사용되기때문에유형이지정되지않은객체를갖고있는것이맞다. 예를들어 "freshman." 이바로그것이다.

32 5.4 메시지시퀀스다이어그램의첫번째메시지는언제나상단에서시작하고다이어그램의왼쪽에위치한다. 뒤따르는메시지들은이전메시지보다약간낮게다이어그램에추가된다. 메시지를또다른객체에보내는객체 (lifeline) 를나타내기위해서수신객체에실선화살표 ( 동기식호출일경우 ) 를긋는다. 또는 ( 비동기식일경우 ) 막대화살표를긋는다. 메시지 / 메소드이름은화살표위에놓인다. 수신객체로보내지는메시지는수신객체의클래스가구현하는작동 / 메소드를나타낸다. 그림 4의예제에서, analyst 객체는 ReportingSystem 클래스의인스턴스인 system 객체를호출한다. analyst 객체는 system 객체의 getavailablereports 메소드를호출한다. system 객체는 secsystem 객체에 userid의인자와함께 getsecurityclearance 메소드를호출한다. 이것이바로 SecuritySystem 클래스유형이다. 시퀀스다이어그램에대한메시지호출을보여주는것외에도위예제의다이어그램에는리턴메시지가포함되어있다. 이리턴메시지들은필수요소는아니다. 리턴메시지는원래 lifeline을향하도록점선화살표로그려지고그위에리턴값을배치한다. 위의예제에서, getsecurityclearance 메소드가호출될때 secsystem 객체는 system 객체에 userclearance를리턴한다. 이 system 객체는 getavailablereports 메소드가호출되면 availablereports를리턴한다. 다시말하지만, 리턴메시지는시퀀스다이어그램의선택사항이다. 리턴메시지의사용여부는모델링되는것의상세함정도에달려있다. 리턴메시지는보다상세한것을원할때유용하다. 하지만호출메시지로도충분하다. 개인적으로는값이리턴될때마다리턴메시지를삽입한다. 시퀀스다이어그램을모델링할때, 객체가자신에게메시지를보내야할때가있다. 언제객체가자기자신을호출할까? 순수주의자들은객체는메시지를객체자신에게보내서는안된다고주장한다. 하지만자신에게메시지를보내는객체를모델링하는것도어떤경우에는유용하다. 아래예제는위예제를개선한것이다. 아래예제는 determineavailablereports 메소드를호출하는 system 객체를보여준다. 그 system 객체에 "determineavailablereports," 메시지를보여줌으로써모델은이프로세스가 system 객체에서발생한다는사실에주목할수있다. 자기자신을호출하는객체를그리기위해서는정상적인방법으로메시지를그리되또다른객체로연결하는대신, 메시지를다시객체자신으로연결한다.

33 위의예제메시지는동기식메시지이다. 하지만시퀀스다이어그램에서는비동기식메시지도 모델링할수있다. 비동기식메시지는동기식메시지와비슷하게그려지지만메시지라인은 막대화살표로표시된다. 5.5 가드 (guard) 객체인터랙션을모델링할때객체로보내지는메시지조건이부합해야할때도있다. 가드 (guard) 는흐름을제어하는 UML 다이어그램에서쓰인다. UML 1.x 와 UML 2.0 모두가드를언급했다. UML 1.x에서보호는하나의메시지에만할당될수있었다. UML 1.x의시퀀스다이어그램에가드를그리려면보호되고있는메시지라인위, 메시지이름앞에 guard 엘리먼트를둔다. 아래예제는메시지 addstudent 메소드에대한가드가있는시퀀스다이어그램이다.

34 예제에서가드는텍스트 "[pastduebalance = 0]" 이다. 이메시지에가드가있기때문에 addstudent 메시지는시스템계정이 [pastduebalance = 0] 을리턴할경우에만보내진다. 5.6 대안대안은두개이상의메시지시퀀스들간상호배타적인선택을나타낼때사용된다. 대안은전통적인 "if then else" 직 ( 만일내가세개의아이템을구매하면구매금액의 20% 를할인받는다 ; 그외에는 10% 의할인을받는다.) 의모델링이가능하다. 아래그림에서보듯, 대안엘리먼트는프레임을사용하여그려진다. "alt" 라는단어는이프레임의네임박스안에놓인다. 더큰직사각형은피연산함수로나누어진다. 피연산함수는대시 (dash) 라인으로분리된다. 각피연산함수에는가드가주어지고이가드는 lifeline 상단에피연산함수의왼쪽상단부분을향해배치된다. 피연산함수의가드가 "true," 로되면그피연산함수를따라야한다.

35 대안이어떻게읽혀지는지를보여주는예제로서위의그림은상단에서시작하는시퀀스를보여준다. check amount와 account의 balance 정보가있는 bank 객체가있다. 이부분에서대안이사용된다. 가드 "[balance >= amount]" 때문에 account의 balance이보다크거나같을때시퀀스는 adddebittransaction과 storephotoofcheck 메시지를 account 객체로보내는 bank 객체를사용하여시퀀스를지속시킨다. 하지만 balance가 amount 보다작거나같을때시퀀스는 addinsuffientfundfee와 notereturnedcheck 메시지를 account 객체로보내고,

36 returncheck 메시지를자기자신에게보내는 bank 객체로처리한다. "[else]" 가드때문에 balance가 amount 보다작거나같을때두번째시퀀스가호출된다. 대안을사용하면 "[else]" 가드가필요없다. 하지만피연산함수가이것에대한명확한가드를갖고있지않다면 "[else]" 가드가필요하다. 대안은 "if then else" 에만국한되지않는다. 필요한만큼대안경로를취할수있다. 더많은대안이필요하면시퀀스의가드와메시지를포함한직사각형에피연산함수를추가하면된다. 5.7 옵션옵션 Combined Fragment는특정상황에서발생하는시퀀스를모델링할때사용된다. 다른경우, 이시퀀스는발생하지않는다. 이옵션은간단한 "if then" 문장을모델링하는데쓰인다. 옵션표기법은대안과비슷하다. 단한개의피연산함수를가져야하고, "else" 가드가전혀없다는것을제외하고는말이다. 옵션을그리려면프레임을그려야한다. "opt" 텍스트가이프레임의네임박스안에배치되고, 이프레임의콘텐트영역에옵션의가드가 lifeline의상단에, 왼쪽상단코너를향해배치된다. 그런다음옵션의메시지시퀀스가나머지영역에배치된다. 옵션 Combined Fragment 는읽기쉽다. 위의그림은이전예제의시퀀스다이어그램을재구 성한것이다. 하지만여기에서는 student 의과거해당 balance 가 0 일경우보내져야하는

37 메시지가더많기때문에옵션을사용한다. 위예제의시퀀스다이어그램을보면, student의과거 balance가 0 이면 addstudent, getcostofclass, chargeforclass 메시지들이보내진다. student의과거 balance가 0이아니라면시퀀스는어떤메시지도보내지않는다. 위예제의시퀀스다이어그램에는이옵션용가드가포함되어있다. 하지만이가드는필수엘리먼트는아니다. 추상시퀀스다이어그램에서는이옵션의조건을지정한다. 이것이옵션 fragment 라는것을가리키면된다. 5.8 루프 (loop) 가끔반복적인시퀀스를모델링해야할때도있다. UML 2에서반복되는시퀀스의모델에루프 Combined Fragment를사용한다. 루프는외형상옵션과매우흡사하다. 프레임을그리고그프레임의네임박스에 "loop" 라고쓴다. 프레임의콘텐트영역안에서루프의가드는 lifeline의상단에, 왼쪽상단코너쪽을향하여놓인다. 그런다음루프의메시지시퀀스는프레임의나머지콘텐트영역에배치된다. 루프에서가드는두가지특별한조건을가질수있다. 이특별가드조건들은 "minint = [the number]" ("minint = 1") 라고하는최소반복과 and maximum iterations written as "maxint = [the number]" ("maxint = 5") 라고하는최대반복이다. 최소반복가드를사용하여, 루프는지정된최소한의수만큼실행해야하고최대또한마찬가지이다. 이예제에서, 루프는 reportsenu 객체의 hasanotherreport 메시지가 false를리턴할때까지실행된다. 이시퀀스다이어그램의루프는루프시퀀스가실행되는지를확인할때부울테스트를사용한다. 이다이어그램은위에서부터읽어내려간다. 루프에다다르면 hasanotherreport 값이 true 인지를확인하기위해테스트가실행된다. HasAnotherReport 값

38 이 true 면시퀀스는루프로간다. 6. Activity Diagram 액티비티다이어그램은업무영역이나시스템영역에서다양하게존재하는각종처리로직이나조건에따른처리흐름을순서에입각하여정의한모델이다. 액티비티다이어그램은하나의액티비티에서다음액티비티로순서가바뀌면서처리되는과정을표현하기때문에순서와분기와처리절차의표현을필요로하는대상에대해제한없이적용이가능하다. 액티비티다이어그램을작성하는목적과용도는다음과같다. - 대상에상관없이처리순서를표현하기위해작성한다. 액티비티다이어그램은액티비티와액티비티의순서를표현할목적으로작성된다. 그대상이비즈니스영역이든시스템영역이든로직과처리순서의표현이필요할경우, 액티비티다이어그램을사용한다. 그래서그용도는무척다양하다. 시스템관점에서프로그램사양을작성하는곳, 비즈니스관점에서영업사원의영업업무프로세스를표현하는곳에도사용할수있다. - 비즈니스프로세스를정의한다. 액티비티다이어그램의적용영역에서가장훌륭하게사용되는대상중의하나는비즈니스프로세스의분석이다. 시스템화대상영역에속한현재업무분야의비즈니스처리흐름을표현 (As-Is 프로세스분석 ) 하거나향후변화된비즈니스처리흐름 (To-Be 프로세스분석 ) 을작성할수있다. - 프로그램로직을정의한다. 액티비티다이어그램은프로그램의사양을정의하는데보조적으로사용된다. 프로그램은다양한처리흐름을가지고있다. 복잡한처리흐름을자연언어로기술하는것은부적절하다. 작성하는과정도어렵거니와작성된사양을정확히이해하기도무척힘이든다. 액티비티다이어그램은처리흐름을도식화하여간단하고명료하게처리로직을표현함으로써작성과이해가용이하다. - 유즈케이스를실현 (Realization) 한다. 프로젝트초기에정의된유즈케이스는프로그램으로의해구현되기전에설계되어야한다. 유즈케이스를액티비티다이어그램을이용해실현하는경우, 객체를정의하거나객체간상호작용을분석하는형태가아니라, 유즈케이스의처리흐름을순서도처럼상세히기술하는형태로작성된다. 그러나이경우비슷한용도로작성되는유즈케이스정의서가존재하기때문에액티비티다이어그램으로유즈케이스를실현하는것은흔한사례는아니다. 6.1 작성시기액티비티다이어그램을작성하는시기는그적용영역이다양한것처럼한정되어있지않고, 다음의시기에작성될수있다. - 업무프로세스정의시점비즈니스프로세스를정의하는용도로액티비티다이어그램을작성할수있다.

39 - 유즈케이스정의서 (Use case Description) 작성시점유즈케이스정의서에서유즈케이스의처리절차를기술하는부분에액티비티다이어그램을작성할수있다. - 오퍼레이션사양정의시점클래스오퍼레이션의사양을액티비티다이어그램을적용하여작성할수있다. - 기타기타처리흐름이나처리절차가필요한시점이면언제나액티비티다이어그램이작성될수있다. 액티비티다이어그램을작성하기위해서준비물및선행과정은특별히없다. 6.2 액티비티다이어그램의구성요소 Things 혹은심볼 : 액티비티 (Activity), 시작점 (Initial State), 종료점 (Final State), 판단 (Decision,Branch), Synchronization Bar Relationships : 전이 (Transition) 기타요소 : Swim Lane 6.3 액티비티의표기 액티비티는모서리가둥근사각형으로표기하며, 액티비티명은심볼내에표기한다. 액티비티의정의및의미 - 액티비티는행위나작업을의미한다. - 액티비티의크기는작성대상에따라유동적이며, 한액티비티다이어그램에서는액티비티의크기가균일한것이바람직히다.

40 - 액티비티는최소단위가아니며내부적으로구조를가질수있는단위이다. - 액티비티는해당작업의종료시점을명확히정의하기가힘들다. - 시작점, 종료점의표기시작점과종료점은원모양으로표기하는데, 시작점은속이꽉채워진원으로, 종료점은속이채워진원에바깥의또다른원이둘러싸고있는모양으로표기한다. 표기예 ) : 시작점표기예 ) : 종료점 - 시작점, 종료점의정의시작점은처리흐름이시작하는곳을의미한다. 모든처리흐름은시작점으로부터개시되어전개된다. 종료점은처리흐름이종료하는곳을의미한다. 모든처리흐름은종료점에서처리흐름을완료한다. - 판단 (Decision) 의표기 판단은속이빈마름모꼴로표기하며, 명칭이나기타장식이붙지않는다. 표기예 ) - 판단 (Decision) 의정의판단은분기가일어나는곳이다. 논리식의결과값에따라두곳이상의흐름으로분기가일어난다. 처리흐름은논리식의결과에따라처리흐름이나누어져전개되는것은매우흔하게일어나는일이다. - Synchronization Bar 의표기 두꺼운실선으로표기하며, Synchronization Bar 는대부분수평선으로표기되나, 수직선으로 표기할수도있다. - Synchronization Bar의의미 Synchronization Bar는병렬처리절차가시작되거나모이는곳이다. 종종둘이상의처리절차가그수행순서에상관없이병렬로진행될경우가있다. Synchronization Bar로부터분기해서다음 Synchronization Bar로모일때까지의처리절차

41 는병렬로수행된다. Synchronization Bar 에이어진액티비티가수행되기위해서는병렬로 수행되는 Synchronization Bar 상의모든처리절차가끝나야한다. - 전이 (Transition) 의표기 화살표가달린실선으로표기하며, 액티비티의배치에따라수평선이나수직선으로표기한 다. - 전이 (Transition) 의의미전이 (Transition) 는하나의액티비티가행위를완료하고다른액티비티로처리순서가옮겨지는제어흐름을표현한다. 하나의액티비티에서여러개의전이 (Transition) 가나가기도하고, 들어오기도한다. - Swim Lane의표기 Swim Lain은영역으로표현을하며, 액티비티다이어그램의제일위쪽에서아래쪽까지수직방향으로공간을구분하는방식으로표현한다. 이것은그모양이마치실내수영장의트랙 ( swim lane ) 같다고해서 swim lane이라는이름이붙여졌다. - Swim lane의의미 Swim lane은여러가지용도로쓰일수있다. 업무조직의구분일수있고, 개인의역할에따른구분이기도하다. Swim lane의영역내에정의된액티비티는그 Swim lane이관장하고 ownership을가진다. Swim lane을표현함으로써누가 (swim lane) 무엇을한다 ( 액티비티 ) 라는식의표현이가능해진다.

42 6.4 작성순서 - 작성대상선정액티비티다이어그램의작성대상을선정한다. 대부분의경우액티비티다이어그램은업무프로세스를모델링하거나, 오퍼레이션사양을정의하는용도로사용된다. - Swim lane 정의대상영역에명확한역할을정의할수있을경우, 역할을식별하여 swim lane으로표현한다. swim lane은필수적으로정의해야하는것은아니다. - 처리절차모델링처리절차를모델링할경우시작점과끝점이표현되어야하고처리흐름이도중에끊겨미아상대가되지말아야한다. 6.5 주의사항 - 해당부분을이해하는데필수적인요소들만표현한다. 모델에서장황한부가요소를포함하는것은바람직하지않다. 분석대상의본질을이해하는데꼭필요한요소들만모델에정의하는것이좋다. - 추상화수준에맞는상세성을일관되게제공한다. 모든모델이마찬가지이지만, 한장의모델에는동일한상세화레벨이유지되어야한다. 서로다른추상화레벨의액티비티들이섞여있으면의미를파악하기힘들게된다. - 중요한의미를이해하기적절한단위로표현한다. 액티비티의크기는일정해야한다. 서로완전히다른단위의액티비티가섞여있을경우모델의완전성을도모할수없다. - 목적을전달할수있는명칭의부여한다. 액티비티명칭을비롯해쓰이는모든명칭들은명확한표현을사용해야한다. 모호한명칭으로정의되면혼란만야기시키는결과를초래한다. - 주흐름으로부터시작하여전이, 분기, 동시성을표현한다. - 교차선이최소화하도록요소를배치해야한다. - 중요한부분은 Note, Color 등을이용하여시각적효과를사용하면좋다. 7. Deployment Diagram 디플로이먼트다이어그램은시스템을구성하는 HW 자원간의연결관계를표현하고, HW 자원

43 에대한SW 컴포넌트의배치상태를표현한다이어그램이다. 그리고디플로이먼트다이어그램은시스템의설계단계의마지막에작성한다. 즉, 모든설계가거의마무리되어 SW 컴포넌트가정의되고, 시스템의 HW 사양도확정된후디플로이먼트다이어그램이작성될수있다. 디플로이언트다이어그램작성하는목적은다음과같다. - SW시스템이배치, 실행될 HW자원들을정의한다. 디플로이먼트다이어그램은다른 UML 다이어그램들과는달리 HW자원들을명시적으로정의하는용도로작성된다. 그러나이렇게 HW를정의하는목적이 HW 자체의사양을정의하고설명하기위한것은아니다. 오히려 SW 시스템이탑재되어동작하는매개체로서, HW자원을정의한다라는관점에서정의한다. - SW 컴포넌트가어떤 HW 자원에탑재되어실행될지정의한다. 디플로이먼트다이어그램은실행모듈 ( 컴포넌트 ) 을분산된 HW자원에적절히배치하여원하는성능과효율을낼지를정의하는목적으로작성된다. 따라서디플로이먼트다이어그램에는 SW자원과 HW자원이동시에표현된다. - HW 자원의물리적인구성을정의한다. SW컴포넌트가탑재된 HW자원들은적절한성능을내기위해물리적인연결을가지고있어야한다. 디플로이먼트다이어그램은어떤 HW자원간에연결이있는지, 그연결은어떠한성능을가진연결인지를정의한다. 7.1 구성요소디플로이먼트다이어그램의구성요소는다음과같다. Things 혹은심볼 : 노드 (Node), 컴포넌트 (Component) Relationships : Connection, Dependency

44 7.1.1 Node Node는직육면체로표기하며, Node Name은심볼내에표기한다. Node는 SW 컴포넌트가탑재되어처리되는데관련된 HW 자원을의미한다. 주로연산능력 (computing power) 이있는 HW 즉, SW를탑재하여운용할수있는능력을가진하드웨어가표현된다. 그러나표현할수있는 HW 자원의종류가제한된것은아니고, 아래와같은다양한장비들이노드로정의될수있다. [HW 장비들의예 ] Sensor, Printers,Card readers, Communication devices, Mechanical processing resources [Node의예 ] Web Server, DB Server Component Component는탭이달린직사각형으로표기하며, Component Name은심볼내에표기한다. Component는독립적으로배포되고교체되며재사용될수있는 SW조각를의미한다. 보통의경우실행모듈을말하지만, 실제통용되는 Component라는용어는항상실행모듈만을가리키지는않는다. 컴포넌트가가끔은아주광의로사용되어서소스코드나 UI(User Interface), 분석, 설계산출물들을포함한것을의미하기도한다. 컴포넌트라는용어의의미는문맥에서말하는사람의의도를생각해서받아들여야한다. [Component의예 ] 결재시스템에서결재, 사원등, 전자상거래시스템에서우편번호검색, 신용카드결재등 연결 - Connection 의표기 Node 를연결하는실선으로표기하며, 연결의물리적특성을 Stereo type 으로표기할수 있다. - Connection 의정의 두 Node 사이의물리적인연결을의미한다. 두노드사이의물리적인연결특성을설명 한다.

45 7.1.4 의존관계 - Dependency 의표기 점선화살표로표현하고필요에따라선위에설명을붙이기도한다. - Dependency의정의객체나컴포넌트가다른객체나컴포넌트의실행을요청하는경우, 즉사물간의실행혹은참조관계를표현한다. Class와 Class, Package와 package, Component와 Component에주로사용되는관계이고, 때로는 Class-Package-Component 상호간에도사용되는관계이다. 7.2 작성순서 - 노드식별및정의디플로이먼트다이어그램을작성할때시스템의운영을위한 HW자원을식별하고그사양을확인하는것을가장먼저수행한다. 일반적으로프로젝트수행초기에시스템청사진 (System Architecture) 을작성하는것이일반적인데, 이를활용하여 HW자원을식별한다. - 컴포넌트식별디플로이먼트다이어그램에등장할컴포넌트를정한다. 컴포넌트다이어그램이정의되어있을경우, 이를활용하면쉽게수행할수있다. - 노드간구성관계정의디플로이먼트다이어그램에노드를배치하고노드간의물리적연결인연결을정의한다. 연결과노드에는 Stereo type으로하드웨어적특성을표현한다. - 노드에컴포넌트배치정의된노드와연결을고려하여어떤노드에서컴포넌트를실행하게될것인가를정의한다. 디플로이먼트다이어그램에 SW컴포넌트들의배치상황을반영한다. 7.3 주의사항 - 목적을전달할수있는명확한의미의명칭을부여해야한다. 노드명과스테레오타입으로정의하는하드웨어특성등은표현방식에기준이없다. 하지만시스템과관련없는제 3 자가보더라도그의미를이해할수있게쉽고, 명확한용어를사용하여명칭을정의하야한다. 모호한명칭으로정의하면혼란만야기시키는결과를초래한다. - 문제영역의 H/W에대한명쾌한추상개념을제공하도록작성한다. SW 자원이탑재되어운영되는보조적인용도뿐아니라, 디플로이먼트다이어그램은시스템의하드웨어구성을개념적으로보여주는훌륭한도구가된다. 이러한용도를살려 HW 자원의구성에대한좋은모델이되도록정의한다. - Model을만든목적을전달하기에필요한수준까지만분해한다. 디플로이먼트다이어그램에모든 HW 장비가나타날필요는없다. 오히려이러한시도는

46 다이어그램을장황하고복잡하게만들어서의미를파악하기힘들게한다. 목적과용도에 부합하는요소들만정의하면충분하다. 8. Component Diagram 컴포넌트다이어그램은시스템의구현관점에서실행모듈 ( 컴포넌트 ) 을정의하고실행모듈간의정적상호작용을정의한모델이다. 이다이어그램은시스템이어떠한물리적구성요소들로 -실행모듈 ( 컴포넌트 )- 구성되고그들간의연관성을정의한것이다. 컴포넌트는매우광범위한의미로사용되는용어인데, SW 분야에서사용되는컴포넌트를정의하면다음과같다. Reusable application building block. : 컴포넌트는시스템의재사용가능한구성요소입니다. Physically replaceable or upgradeable parts of a system : 컴포넌트는시스템의교체단위이자업그레이드단위입니다. An independently deliverable piece of functionality providing access to its services through interfaces : 컴포넌트는인터페이스를통해그기능이사용되어지는, 독립적으로인도되는기능조각입니다. 컴포넌트다이어그램을작성하는목적은다음과같다. - 시스템의실행모듈 ( 컴포넌트 ) 들을정의한다. 컴포넌트다이어그램은시스템이구축될때, 어떤실행모듈 ( 컴포넌트 ) 들로구축될것인지를정의하는용도로사용된다. 이러한컴포넌트는독립적으로배치, 교체가가능한단위이다. 개발플랫폼에따라이러한실행모듈의특성은달라진다. - 컴포넌트간 Dependency를정의한다. 컴포넌트다이어그램은실행모듈 ( 컴포넌트 ) 간의정적인상호작용을정의하는용도로사용된다. 컴포넌트사이의종속관계를표현함으로써실행시상호참조하는연관성을표현한다. - 실행모듈뿐아니라소스코드, 데이터베이스등의상호작용을모델링한다. 컴포넌트외에소스코드나데이터베이스등조각으로나누어정의할수있는대상들에대해, 그대상들의상호작용을정의하기도한다. 그러나이런용도로사용되는경우는흔치않다. 컴포넌트다이어그램은시스템의설계단계의막바지에작성한다. 즉, 모든클래스가물리적으로완전히정의되고, 그상호관계도정의된후컴포넌트다이어그램이작성될수있다. 8.1 컴포넌트다이어그램의구성요소 Things 혹은심볼 : 컴포넌트 (Component), 인터페이스 (Interface) Relationship : Dependency, Realization

47 - 컴포넌트의표기 컴포넌트는탭이달린직사각형으로표기하며, 컴포넌트명은심볼내에표기한다. - 컴포넌트의정의컴포넌트는독립적으로배포되고교체되며재사용될수있는 SW조각를의미한다. 보통의경우실행모듈을말하지만, 실제통용되는컴포넌트라는용어는항상실행모듈만을가리키지는않는다. 컴포넌트가가끔은아주광의로사용되어서소스코드나 UI(User Interface), 분석, 설계산출물들을포함한것을의미하기도한다. 컴포넌트라는용어의의미는문맥에서말하는사람의의도를생각해서받아들여야한다. 컴포넌트의예 컴포넌트는매우다양한크기로정의되며. 아래예들은한정된컴포넌트의사례일뿐이다. 결재시스템 : 결재, 사원등전자상거래시스템 : 우편번호검색, 신용카드결제등 - 인터페이스의표기 인터페이스는두가지형태로표기가가능하다. 하나는 icon형태의표기로원으로표현하는데, 이경우인터페이스명은아래쪽에표기한다. 다른하나는보통의클래스에 <> 라는스테레오타입이부가된표기이다. - 인터페이스의정의 Interface는 Class의일종이다. interface는 class나 Component의기능을외부에공개할목적으로쓰이며, 구현은하지않는다. interface의구현은클래스나컴포넌트에서하게되며,

48 이클래스는 interface 를상속하여단지선언뿐인 interface 의구현을담당한다. Interface 는 단독으로표시되는경우는거의없으며해당 Interface 를구현하는 Class 나 Component 에 붙어다닌다. - Dependency 의표기 점선화살표로표현하고필요에따라선위에설명을붙이기도한다. - Dependency의정의객체나컴포넌트가다른객체나컴포넌트의실행을요청하는경우, 즉사물간의실행혹은참조관계를표현한다. Class와 Class, Package와 package, Component와 Component에주로사용되는관계이고, 때로는 Class-Package-Component 상호간에도사용되는관계이다. - Realization의표기속이빈삼각형의화살표가한쪽에달린점선으로표현한다. 그러나특별히컴포넌트다이어그램에서는인터페이스와컴포넌트간의실선으로표현된다. Realization의표기인터페이스와컴포넌트간표기 - Realization의정의정의하는사물과이를구현하는사물간에표현하는관계이다. Realization은인터페이스 ( 정의 ) - 컴포넌트 ( 구현 ), 유즈케이스 ( 정의 ) - 컬레버레이션 ( 구현 ) 과인터페이스 ( 정의 ) - 클래스 ( 구현 ) 사이에허용되는관계이다. 삼각형이붙은쪽이정의하는사물, 반대쪽이구현하는사물이다. 8.2 작성순서 - 컴포넌트대상정의컴포넌트다이어그램을그리기전에무엇을컴포넌트로표현할지클래스를구성요소로하는실행모듈로할지, 소스코드를정의할지기타무엇을컴포넌트로표현할지를정해야한다. - 컴포넌트식별컴포넌트다이어그램에등장할컴포넌트를정한다. 소스파일일경우그대상은쉽게식별되지만실행모듈일경우간단치않다. 여러가지가능한방법으로컴포넌트를식별해내는

49 작업을수행한다. - 컴포넌트배치및인터페이스정의컴포넌트다이어그램에컴포넌트를배치하고이름을정의한다. 그리고인터페이스를정의할필요가있을경우인터페이스를정의하고컴포넌트와 realization관계로연결한다. - Dependency 정의컴포넌트와컴포넌트간의존관계를분석하여 Dependency 관계를정의한다. 8.3 주의사항 - 컴포넌트는응집도는높고결합도는낮은단위로정의되어야한다. 실행모듈로서의컴포넌트를식별할때, 컴포넌트는다른컴포넌트와독립적이고, 기능차별성을갖추는단위로정의되어야한다. 즉, 기능측면에서컴포넌트내부는강한유사성을갖는단위들로구성되어야하고 ( 높은응집도 ), 다른컴포넌트에강하게종속되지는않는 ( 낮은결합도 ) 단위로정의되어야한다. - 컴포넌트크기 (Granularity) 의일관성을고려해야한다. 한시스템에서컴포넌트의크기에너무차이가나면바람직하지않다. 컴포넌트의크기는기술구조와시스템특성들이고려되어적절한크기로정의해야하며, 그크기도되도록많이차이나지않도록하는것이좋다. - 추상화수준에맞는상세성을일관되게제공한다. 모든모델이마찬가지지만, 한장의모델에는동일한상세화레벨이유지되어야한다. 서로다른추상화레벨의컴포넌트가섞여있으면의미를파악하기힘들게된다. 소스와실행모듈을한장에정의한컴포넌트는좋은예가아니다. - 목적을전달할수있는명칭을부여해야한다. 컴포넌트, 인터페이스를비롯해쓰이는모든명칭들은명확한표현을사용해야한다. 모호한명칭으로정의하면혼란만야기시키는결과가된다.