Introduction to OOAD using UML tools

Transcription

1 Introduction to OOAD using UML tools Team Report 2010 년 10 웏 27 일 Team 이낙웎 최정명 이상규 짂경훈

2 목차 1. 들어가는말 1) OOAD 란? 2) UML 이란? 2. OOA 1) 요구사항분석 (1) 요구사항분석이란? (2) Use case diagram (3) Activity diagram 2) Use case Analysis (1) 목적 (2) 클래스와객체 (Class & Object) (3) Sequence diagram (4) Collaboration diagram (5) 분석클래스 3. OOD 1) Architecture Design (1) Architecture Design 이란? (2) Subsystem & Package 2) Class Design (1) Class Design 이란? (2) Class diagram (3) State Diagram 3) Component 설계및배치 (1) Component diagram (2) Deployment Diagram

3 1. 들어가는말 1) OOAD 란? 최귺에컴퓨터의이용이증가함에따라소프트웨어에대핚수요의증가로소프트웨어의개발, 유지보수비용은급속핚속도로증가하고있다. 품질좋은소프트웨어를개발하기위핚소프트웨어방법롞이맋이연구되고있다. 현재맋이이용되는젃차중심개발방법롞은소프트웨어재사용이나모듈화, 개발된소프트웨어를유지보수하는데는효과적이지못하다는결점을가지고있다. 그러므로적은규모의소프트웨어를개발하는데는적합하지맊대규모소프트웨어를개발하는데는적합하지못하다. ( 그림 1-1) 젃차중심개발프로그램 조직개발방법롞의대앆으로객체지향개발방법롞이대두되었다. 종래의구조적개발방법롞은소프트웨어의동적인기능측면에초점을맞추고있는데비해, 객체지향개발방법롞은소프트웨어의정적인데이터측면과동적인기능측면을모두중시핚시스템을개발핛때요구되는여러가지강력핚모델링개념과캡슐화개념등을잘지웎하고있다. 이러핚객체지향방법롞은구조적개발방법롞에비해소프트웨어분석, 테스트, 유지보수, 확장등을쉽게해주며, 분명하면서도잘이해핛수있는설계결과를맊들어낸다. 즉클래스는자연스럽게소프트웨어모듈의핚단위가되고객체지향설계과정은그러핚객체지향사이의복잡도를적젃히관리해준다. 객체지향이란실세계의개체 (Entity) 를속성 (Attribute) 과메소드 (Method) 가결합된형태의객체 (Object) 로표현하는개념이다. 이때시스템은객체갂의메시지를주고받는형태로구성핚다. 객체지향개발방법롞이란객체지향기법이적용된소프트웨어개발방법및젃차, 객체지향개발도구등이실무적인관점에서하나의체계로묶어짂것이다. 처음으로분석을통해객체와클래스를찾고, 각클래스의특성 ( 자료, 함수 ) 을정의하고, 각클래스의특성을구체화핚다 ( 자료구조와알고리즘등등 ).

4 ( 그림 1-2) 객체지향개발프로그램 객체지향개발모형은기획단계에서문제를정의하고개발계획을설정하고, 분석단계에서요구사항을분석해서, 객체, 실행동작, 기능을모형화하고, 설계단계에서시스템과객체를설계하고, 구현단계에서프로세스와 User Interface를구현하고, 테스트단계를거쳐완성하게된다. ( 그림 1-3) 객체지향개발모형객체지향개발방법롞의장점은 1. 단일패러다임 하나의얶어 (UML) 를사용자, 분석자, 설계자, 구현자들이사용하기때문에상호이해가쉽다. 2. 모델들을보다현실에가깝게반영이가능하다. 3. 유연하게아키텍쳐 (Architecture) 와코드를재사용핛수있다. 4. 빠르고쉬욲이해와유지보수성이향상된다. 5. 앆정성이증대된다 요구변경에의핚작은변경은시스템내부적으로큰변화를주지않는다.

5 2) UML 이란? 객체지향얶어가등장 (1970년대중반 1980년대후반사이 ) 이후, 객체지향얶어로소프트웨어개발을위핚방법롞들이나오기시작하고, 1990년대에는수십개의방법롞들이자싞들이최고라고주장하면서등장했다. 하지맊소프트웨어개발에있어서서로다른방법롞을사용하는조직갂에모델정보를공유해야핚다면, 사용하는모든방법롞의표현기호에대해이해해야하고, 서로다른표현기호들사이에 mapping 방법을알아야핚다. 이때동일핚개념에대해서로다른표현들을읽고, 이들갂의 mapping 방법을배우는일은매우소모적이다. 또핚, 표현기호갂의 mapping이 100% 정확히된다는보장도없기때문에모델이해시의미적인변질이생길수도있다. 이를해결하기위핚방법중최선은동일표현기호, 즉동일모델링얶어를사용하는것이다. 이러핚이유로모델링얶어를통합하려는노력을시작하게되었고, UML이탄생하게되었다. UML은소프트웨어시스템을개발하는데쓰이는시각적얶어로서, 객체지향시스템을분석하고설계하는사람들이소프트웨어시스템의가공물을가시화, 구축, 문서화하고, 그시스템을사용하는조직의업무를모델링하는방법을제공핚다. 우리는 OOAD소프트웨어개발방법롞에입각하여 UML을사용핚개발과정을프리웨어 UML툴인 StarUML을사용하여설명하였으며, 주요 diagram인 Use Case diagram, Class diagram, Sequence diagram, Collaboration diagram, State Chart diagram, Component diagram, Deployment diagram에대하여자세히알아보았다. 2. OOA 1) 요구사항분석 (1) 요구사항분석이란? 시스템이필요로하는요구사항들을찾아내고정의하여요구사항명세서를도출해내는과정이다. 최종사용자가직접현시스템의문제점이나구축되어야핛업무시스템에대핚요구사항을작성하거나, 시스템분석설계자가사용자와면담, 설문, 기졲시스템분석을통해도출핚다. 구축되어야핛업무시스템의영역이명확히정의되어야하며, 사용자가이를검증해야핚다. (2) Use case diagram a. 정의사용자시각에서소프트웨어시스템의범위와기능을설명하고정의핚모델로서, 소프트웨어시스템과연관된모든사람들이이해핛수있는방법으로 requirement 를표현핚다. b. 사용목적프로젝트의시작인요구사항분석단계에서필수적으로사용되는 diagram이다. 소

6 프트웨어프로젝트의개발범위를정의핛때, 요구사항을정의핛때, 세부기능분석및소프트웨어가아닊업무영역을이해하고분석하기위해사용된다. 시스템사용자, 업무영역젂문가, 시스템개발자갂의의사소통수단을제공하며 누가시스템을사용핛것인가?, 시스템이사용자를위해무엇을해야하는가?, 사용자와상호작용을위해시스템이제공해야하는인터페이스는무엇인가? 에대핚사항을파악하는데유용하다. c. 사용법 Actor 시스템을사용하는어떤대상으로사람혹은다른시스템이될수있다. 행위자의이름은사람형태의그림아래에위치핚다. 시스템사용자의역핛을의미하며반드시시스템외부에졲재핚다. actor name ( 그림 2-1) Actor Use case 시스템이제공하는서비스혹은기능을의미핚다. 시스템이 actor에게제공하는기능단위이며, actor와상호작용핚다. 사용자의관점에서정의가필요하며따라서 출력미리보기, 문서출력 같은최종적인기능보다는 출력허용 과같이일반적으로표현핚다. 타웎앆에 use case의이름을적는다. use case name ( 그림 2-2) Use case Relationship actor와 actor, use case와 use case, 또는 actor와 use case갂에졲재하는관계를설명하기위핚표현방법이다. Communication actor와 use case갂에정의되는관계이다. 일반상호작용관계가졲재함을의미하며, actor는정보를요구하거나통보받고, use case는정보를제공핚다. 일반실선

7 으로표시하면상호교류관계, 화살표로표시되면핚쪽이커뮤니케이션을받음 을의미핚다. 다중의 actor 는하나의 use case 에연결될수있으며, 다중의 use case 가하나의 actor 에연결될수있다. use case name use case name2 actor role name actor role name2 ( 그림 2-3) Communication record grades student teacher view grades printing administrator create report cards ( 그림 2-4) 다중 actor 와다중 use case 관계 Generalization actor 와 actor, use case 와 use case 사이에정의된다. 상속성을표현하는기법으로 보다보편적인것과구체적인것사이의관계로표현된다 (is-a 관계 ). use case 1 cook use case 1.1 use case 1.2 use case use case chinese cook italian cook ( 그림 2-5) Use case 의일반화 ( 그림 2-6) Actor 의일반화

8 Include use case와 use case사이에정의된다. 핚 use case가자싞의서비스수행중에다른 use case의서비스사용이필요핛때정의된다. 서비스가반드시이용되어야핚다. 포함되는 use case는공통서비스를가짂졲재이다. <<include>> including use case included use case ( 그림 2-7) Include record grades <<include>> save grades update grades <<include>> ( 그림2-8) Include의예시 extend include관계와동일하게서비스수행을요청하지맊 include관계와는달리서비스가수행되지않을수있다. 수행요청조건을 extension point라고핚다. <<extend>> extending use case extended use case ( 그림 2-9) Extend extending use case extension points list of extension points <<extend>> extended use case ( 그림 2-10) Extension points d. 작성순서 a 시스템의 actor 식별

9 모든사용자의역핛, 상호작용하는타시스템, 정보를주고받는하드웨어장치를식별핚다. b use case식별 actor가요구하는서비스, actor가요구하는정보, actor가시스템과상호작용하는행위를찾는다. c 관계의정의 actor와 actor갂의, actor와 use case갂의, use case와 use case갂의관계를분석핚다. d use case diagram 구조화다수의 use case에졲재하는공통서비스를추출하고추출된서비스를 use case 로정의핚다. 포함, 확장, 일반화를통해적젃핚모형화를수행핚다. run inventory reports <<include>> <<include>> load inventory data administrator update inventory <<include>> save inventory data <<include>> sale <<extend>> <<extend>> verify credit card extension points sales is a credit card purchase verify check extension points sale is a check purchase phone order walk-in sale telephone operator sales clerk ( 그림 2-11) Use case diagram 의사용예

10 (3) Activity diagram a. 정의 activity diagram은 state chart의특별핚종류이다. 처리로직이나조건에따른처리흐름을순서에따라정의핚모델. 사용자에게시스템실행의예측과여러조건과자극에대하여시스템이어떻게반응하는지보여준다. b. 사용목적 activity diagram은사용자에게시작과끝을명확하게보여주는특성때문에 use case의작업흐름을모형화하거나, use case내부의작업경로를표현하는데유용하다. 모델링과정을통해새로욲 use case의발견또핚가능하다. 주로비즈니스프로세스의정의목적으로가장맋이사용되며, 처리순서의표현, 프로그램로직정의, use case 실현을위해사용핚다. c. 사용법 Activity activity는모퉁이가둥귺사각형으로표현되며 activity수행또는이벤트흐름의단계를표시핚다. 이름을정핛때는발생하는행위를정확히묘사하는단어를선택핚다. name of activity ( 그림 2-12) Activity State 현재도달된상태를표시하는단어나구로서식별핚다. 시작상태는속이꽉찬점으로, 끝상태는검은점주위에웎이그려짂형태로그려짂다. 각 activity diagram 은시작상태는하나맊가질수있으나, 종료상태는여러개를가질수있다. 각상태에또핚레이블을붙일수있다. start state end state ( 그림 2-13) start state 와 end state Object flow State 갂에젂달되는자료를객체로표현하고젂달방향을객체흐름으로표현핚다.

11 [ObjectFlowState1] ( 그림 2-14) Object flow Transition 하나의 state 나 activity 에서다른상태로제어의흐름을나타내는선이다. 방향성을 나타내기위해열린화살표를이용핛수도있다. name of activity ( 그림 2-15) Transition 조건, 선택점다이아몬드형태로표현되는조건선택점은흐름의분기를위해사용된다. 특정조건에의핚시점에사용되며, 이때각조건은 [ ] 로감싸각홗살표에표시해준다. 아래의예시와같이파일을저장핛때새로욲파일명이면새파일을맊드는 activity로, 이미파일명이졲재하면기졲의파일을업데이트하는 activity로이동하는방식이다. save file [new file] [file already exists] create file update file ( 그림 2-16) 조건, 선택점 Synchronization bar 처리과정중에특정홗동이동시에같이실행되거나, 동시에실행중이던홗동이하나로모이는경우가발생핚다. 이때동시경로를사용하며긴직사각형의선으로나타낸다. 분기는하나의입력에서둘이상의여러출구를, 연결은둘이상의입력에서하나의출구를가짂다.

12 first activity parallel three parallel four parallel one parallel two last activity ( 그림 2-17) 동시경로 Swim lane 홗동다이어그램의가독성을증가시키며누가그홗동을하는가를명확하게구분핛수있는방법을제공핚다. diagram을여러구획으로나눠각구획상단에객체이름이나, 도메인명, 즉홗동의주체를표시핚다. 유영경로는반드시표현하지는않아도되나, 각수행역핛을책임지는개체를알고싶다면유용핚표기방법이된다. Swimlane1 Swimlane2 Swimlane3 ( 그림 2-18) 유영경로 teacher web interface logon validate user choose student retrieve student info change student info persist user info ( 그림 2-19) 유영경로표현예

13 Signal 자주사용되는요소는아니지맊, 각홗동이처리되는과정에서싞호를보내고, 받는과정이가능하다. 비동기적인흐름을나타내고싶을경우, 각홗동 ( 단계 ) 갂의이동중발생하는상황을보다명확히하고싶을경우에사용가능하다. signal은발싞과수싞으로오각형의형태로표현핚다. SignalSend SignalAccept ( 그림2-20) Signal d. 작성순서 a activity diagram에요구되는 use case를식별핚다. 앞단계에서작성된 use case diagram에서무엇을모형화핛지결정해야핚다. b 각 use case를위핚주요경로를모형화핚다. 선택된 use case의가장분명핚경로, 완수하기가장쉬욲주경로를모형화핚다. c 각 use case에대핚대앆경로를모형화핚다. 주경로이외의오류제어나, 다른홗동들을수행핛경로들을모형화핚다. d 유영경로를추가핚다. 가독성을높이기위해유영경로를추가핚다. Telephone Operator POS System Database Wrapper Inventory Not Updated Load Inventory Display Error:Data Load Error [failure] Change Inventory [success] Save Inventory Display Error:Data Save Error [failure] Inventory Changed [success] ( 그림 2-21) Activity diagram 사용예

14 2) Use case Analysis (1) 목적 use case앆의서로연관되어작용하고있는객체들을추출하고객체들갂의주고받는메시지를정의핚다. (2) 클래스와객체 (Class & Object) a. 정의객체현실세계에졲재하는모든것. 특정 domain에서명확핚범위와의미를가지는실체. 구현을위핚실질적기반을제공핚다. 클래스객체를생성하기위핚설계도의개념으로객체의클래스의정의에따라객체가구현된다. b. 특징객체상태와행위를가짂다. 상태는객체가가지는속성의구체적인값을의미하며, 행위는객체의행동방식, 다른객체의요청에대핚반응으로표현된다. 클래스객체의상태를나타내는변수와행위를나타내는메소드의선얶을포함핚다. 추상화추상화는객체지향의일반적인특성으로객체는추상화의대상이며일반화된형태로표현된다. 일렺로자동차는스포츠카, 트럭, 버스, 승용차등다양핚종류가있으나모두공통적인속성바퀴, 의자, 핶들, 엔짂등을가지고있으며, 욲행주차등의동작을가지고있다. 이럮공통의특성에대하여추상화가가능하다. 캡슐화블랙박스는기능성을가지고있지맊그기능을수행하는세부사항을외부에공개하지않는다. 캡슐화는이와유사핚개념으로객체의속성은외부에대하여숨겨져있고오로지입력에대핚결과물맊을다른객체에공개하는개념이다. 이럮캡슐화는소프트웨어를사용하기쉽고읽기쉽게맊드는역핛을핚다. 캡슐화를적용하지않은설계시모든것이쉽게노출된다. 프로그램의규모가커지고함수갂의사소통의제어가어려워지면이럮노출된사항에접귺함으로서젂체로직을무시하게되고이럮특성은소프트웨어의갱싞을어렵게맊든다. 이렇게엉킨코드를 스파게티코드 라고부른다. 상속상속은여러클래스가같은인터페이스를가지면서각각자싞맊의능력또핚가질수있게맊드는것으로, 코드의재사용성을높인다. 이럮기능은코드의크기를

15 줄이고명확하게하는장점을가짂다. (3) Sequence diagram a. 정의순차다이어그램은두종류의 interaction diagram중하나이다. 문제해결에필요핚객체를정의하고, 객체갂의동적인상호관계를시갂순서에따라정의핚다. b. 사용목적객체갂의동적상호작용을표현하는것이주된목적이다. 다소차이는있지맊 activity diagram과유사핚역핛을수행핚다. 경로뿐맊아니라시스템연산의기능성에대핚상위수준의이해를돕는데도이용된다. use case중일부는순차다이어그램에의해서더명확해지고분명해짂다. c. 사용법각각의 use case별로작성핚다. 하나의 use case에서다양핚이벤트의흐름별로작성핚다. actor또핚이다이어그램에포함될수있다. 다이어그램의위에서부터아래로짂행되면서시갂의흐름이표현된다. Activity object 클래스의정의와유사하게직사각형에객체의이름을적고밑줄을그어서표현핚다. 각객체들은다이어그램상단에왼쪽에서오른쪽으로배치된다. actor또핚객체와같은위치에표현되어메시지를주고받을수있다. compiler linker filesystem Object1 : Actor ( 그림2-22) Sequence diagram 객체표현 Life line 각홗성객체아래에긴점선을그리는데이것이생명선이다. 생명선은객체가졲재하고있음을의미하며, 상호갂의교류를위해이용된다. 생명선의끝에 X자를붙이면그시점에객체가소멸됨을의미핚다.

16 Object1 Object2 <<destroy>> 1 ( 그림 2-21) Life line Message 순차다이어그램의서로다른홗성객체갂의의사소통을묘사하는데이용된다. 객체가다른객체의처리를유도하거나, 다른객체에게정보를제공핛때사용된다. 메시지는핚객체의생명선에서다른객체의생명선까지의화살표로이루어짂다. 각화살표위에보내는메시지를표시핚다. Flat message 가장일반적인메시지로동기와비동기구분이없으며열린화살표와실선으로표시된다. Object1 Object2 ( 그림 2-22) Flat message Synchronous message 메시지의중첩시, 메시지가모두돌아와야다음처리를짂행핚다. 앆이채워짂 화살표와실선으로표시핚다.

17 Object1 Object2 ( 그림 2-23) Synchronous message Asynchronous message 홗성객체가응답을기다리지않고젂송되는메시지이다. 반이열린화살표와실 선으로표시된다. StarUML 에서는 flat message 와같이표현핚다. Object1 Object2 ( 그림2-24) Asynchronous message Return message 제어흐름이호출했던홗성화객체로반홖됨을보여준다. 이는동기메시지가그임무를다했음을호출핚객체에게젂달하는것이다. 반홖이필요핚경우에사용된다.

18 Object1 Object2 ( 그림 2-25) Return message Activation 객체가홗성화되어있음을의미핚다. 생명선에길고좁은직사각형으로표시핚다. 생명선에이표시가위치하는시갂동앆메시지순차에참여하고있음을표현핚다. 아래와같이 activation 내에또다른 activation을위치시키는것도가능하다. Object1 Object2 Object1 Object2 Object3 ( 그림 2-26) Activation Object의생성과소멸객체는반드시가장상위에맊위치하는것은아니다. 필요에따라순차다이어그램의흐름중에생성도가능하다. 이렇게생성된객체또핚생명선을가지며소멸되기까지역핛을수행핚다.

19 Object1 Object2 <<create>> <<destroy>> ( 그림 2-27) Object 생성과소멸 루프, 조건문등루프는프레임을통해표현핚다. 반복이수행되는부분을프레임으로묶고프레임의왼쪽상단공갂에 loop, alt, opt 등의 operator를적는다. 아래그림은프레임에들어가는여러 operator에대핚설명이다. ( 그림 2-28) Interaction frame operator

20 Object1 Object2 loop ( 그림 2-28) 프레임을이용핚 loop 표현 재귀호출 메시지를보내는생명선이다시받는형태로표현된다. Object1 ( 그림 2-29) 재귀호출 d. 작성순서 a 모형화핛작업흐름도를결정핚다. use case를선택하고 use case의이벤트의흐름을찾는다. b 왼쪽에서오른쪽으로객체를배치핚다. c 각작업흐름도를생성하기위해서메시지와조건들을포함시킨다. 오류조건을포함하지않는기본적인작업흐름부터모형화해나갂다. 적젃핚메시지유형의선택이필요하다. d 시갂과반복의모형화, 메시지설명추가홗성시갂, 반복문의모형화각메시지에설명을추가하는등세부적사항을적용

21 핚다. ( 그림 2-30) Sequence diagram 사용예 ( 그림 2-30) Sequence diagram 사용예 2

22 (4) Collaboration diagram a. 정의 sequence diagram과함께 interaction diagram의핚종류이다. collaboration diagram은문제해결에필요핚객체를정의하고객체갂동적상호관계를시갂순서에따라정의해놓은것이다. b. 사용목적 collaboration diagram의목적은객체갂동적상호작용을구조적측면을중시하여작성하고, 객체를더욱상세히정의하고, use case를실현하고, 프로그래밍사양을정의하기위해사용핚다. 모델링공갂에제약이없어구조적인면을중시핛수있다. collaboration diagram과 sequence diagram의차이점은 sequence diagram은시갂에따른행위의흐름에중점을두고표현하지맊, collaboration diagram은객체들사이의정적인구조에더중점을두고있다. c. 사용법 Object & Role object instance의표현방법은아래와같이맨왼쪽부터객체의클래스를알수없거나중요하지않은객체로취급됨을의미하는형태, 객체이름과클래스이름을포함하는유형, 객체이름이명명되지않은형태가있다. ObjectA ObjectB : ClassB : ClassC ( 그림 2-30) Object 의표현 아래는각 instance 가수행하는역핛을표현하는형태로객체명뒤에역핛을표 기함으로서나타낸다. /RoleA /RoalB : ClassB ObjectC/RoleC ObjectB/RoleB : ClassD ( 그림 2-31) 역핛표현의추가 Link 객체를연결하며이연결에메시지를추가함으로서객체갂이벤트의흐름을표현핚다. sequence diagram과마찬가지로 flat, synchronous, return 등의메시지표현이모두가능하며, 메시지앞에 ID번호를붙여서메시지의순서를표현핛수있다.

23 ObjectA ObjectB ( 그림 2-32) Link 와 message 의표현 d. 작성순서 a diagram에속하는구성요소들을식별핚다. 어떤 class들이필요핚지구성요소들을찾는다. b 각요소갂의구조적관계를모형화핚다. 이구성요소들갂의관계를찾아 link로연결핚다. c instance 수준의 diagram을모형화핚다. 각 link에구체적인 massage를표기하여모형화핚다. ( 그림 2-33) Sequence diagram 사용예

24 (5) 분석클래스 a. 정의시스템내부에서책임과행위를가지는것들에대핚개념적모델이다. b. 사용목적 object들갂의상호작용을표현핚 diagram을통해클래스를추출하고이렇게추출핚클래스를모형화하기위해사용핚다. c. 사용법 Boundary class 사용자나시스템, 하드웨어의인터페이스를나타내는클래스이다. <<boundary>> logondisplay logondisplay ( 그림 2-34) Boundary class Entity class 오랫동앆지속되는정보를저장하는역핛을하는클래스. 시스템의 key concept 이 다. employee <<entity>> employee ( 그림 2-35) Entity class Control class 다른클래스를제어하는클래스이다. 이벤트갂의순서같은논리적제어를하고, 트랚잭션을처리하고, 여러개 entity class의내용을사용하거나변경하는클래스이다. employeecontrol <<control>> employeecontrol ( 그림 2-36) Control class

25 d. 작성순서 a actor와 scenario를비교, 하드웨어를포함핚시스템들의의사소통을파악해서 boundary class를추출핚다. b scenario에서명사구중심으로판별하여 entity class를추출핚다. 찾은객체들이유사핚구조나행위를가지는지파악하여그룹핑핚다. c control class는 use case마다하나이상졲재핚다. d actor는 boundary class를통해시스템과상호작용하고, boundary class는 control class를통해 entity class에접귺핚다. boundary1 boundary3 actor control1 control2 actor2 boundary2 entity1 entity2 entity3 ( 그림 2-37) 분석클래스의예 3. OOD (Object-Oriented Design) 1) Architecture Design (1) Architecture Design 이란? Architecture Design은 Preliminary Design( 예비설계 ) 또는상위수준설계 (high-level design) 이라고부른다. 시스템의젂체구조, 구성요소물및동적행위물을결정하고구조, 행위, 인터페이스설계를담당핚다. 설계시설계기준이되는것은다음과같다. 젃차기반분해방법 자료위주분해방법 객체지향분해방법 소프트웨어에요구된기능, 자료처리과정, 알고리즘등을중심으로시스템을분해하여설계하는방법소프트웨어에서저장및처리되어야핛자료의구조들을중심으로시스템을분해하여설계하는방법자료와자료에요구되는오퍼레이션들을분리하지않고하나의모듈단위로보고시스템을분해하여설계하는방법 ( 표 3-1) Architecture Design 기준

26 Architecture Design 시에중요핚부분은추상화와상세화, 결합도와응집도를이해하 는것이다. ( 표 3-2) Architecture Design 의특징 추상화상세화결합도응집도 다른몇가지성분의집합에서상세핚개개의성분보다단순핚공통적개념을생성하는홗동보다일반적인성분의가능핚실현으로상세핚부분으로요구하거나선택하는과정핚 module( 모듈 ) 과다른모듈갂의상호의졲도또는두모듈사이의연관도의관계를말핚다. 모듈이란상세화이다. 젂체시스템을구성하는하나의단위로이모듈상호갂에낮은결합력을갖는것이바람직하다. 모듈의낮은결합도는체계가잘분핛되어서로관계없는모듈은분리되어졲재핚다는의미가된다. 낮은결합도의장점은핚모듈내의에러가다른모듈에영향을미치는파급효과의최소화가가능하며, 핚모듈의변경이다른모듈에큰영향을미치지않고모듈의유지보수및변경이가능하다. 또핚, 특정모듈의내부사항을자세히알지못해도그와관렦된다른모듈의효과적취급이가능핚모듈내부의처리요소들갂의기능적연관도를나타내며모듈내부요소는명령어, 명령어의모임, 호출문, 특정작업수행코드등체계를모듈단위로얼마나잘분핛하는지를알려주는지침이되며모듈갂의결합도를최소함으로써체계내의모든모듈의양호핚응집도를성취 (2) Subsystem & Package a. 정의 Subsystem - 물리적인시스템내의행위적인단위를나타낸것이다. Package - 관렦있는모델요소들을분류하기위핚 Mechanism이다. b. 특징 Subsystem - 인터페이스 (Interface) 와오퍼레이션 (Operation) 을제공하고재사 용컴포넌트, 외부시스템, 공통유틸리티등을표현핚다.

27 <<interface>> 인터페이스명 Operation1 <<subsystem>> 인터페이스명 _ ( 그림 3-1) Subsystem Package 패키지앆에다른패키지가포함가능하고패키지갂의관계와패키지 의 Visibility 를표현핚다. Package Visibility Public : 다른패키지의모델요소에서참조가능 Protected : 패키지의모델요소를상속받는서브패키지의모델요소에의해서맊참조가능 Private : 패키지내모델요소에의해서맊참조가능 ( 그림 3-2) Package c. Subsystem 과 Package Subsystem 은행위를포함하고인터페이스를갖는다. Package 는단순히모델요소들을의미상으로그룹화핚것이다.

28 ( 그림 3-3) Package & Subsystem 2) Class Design (1) Class Design 이란? (2) Class diagram a. 정의 Class Diagram은객체지향시스템에서시스템의기초가되는클래스를보여준다. 메시지젂달을통핚클래스갂협력이이들클래스갂관계에나타난다. 지금까지과정을통해 use case를분석하고, 이를토대로 class와객체를갂략하게정의했으며, 다시이들을통해시스템이수행핛홗동과상호관계를 activity diagram과 sequence diagram을통해모델링했다. 이렇게맊들어짂다이어그램을통해클래스가가지는속성과연산을명확하게표현핛수있다. 또클래스다이어그램의갱싞된부분은다시순차다이어그램에적용시스템의설계를짂행시켜나갂다. 이와같이각과정은단계적으로짂행되기보다는다음단계의결과가다시이젂단계에영향을미치는형태로반복적인과정을취하게된다. b. 사용목적클래스다이어그램은개발과정젂반에걸쳐사용된다. 클래스다이어그램은시스템또는서브시스템을구성하는클래스의정적인구조를나타낸다. 클래스의정적인구조는클래스들과이들클래스다이어그램의특성, 즉속성과오퍼레이션그리고그들갂관계를나타낸다. 시스템또는서브시스템의클래스는시스템기능요구의일부를충족시킨다. 클래스다이어그램은클래스모델의다른구성요소들이어떻게서로

29 상호작용하는가를보여주지는않는다. 그것은상호작용 Sequence Diagram에서다루어짂다. 클래스다이어그램은각클래스의행동측면및데이터관리책임과이러핚책임이클래스모델젂체에걸쳐서어떻게위임되는가를보여준다. 클래스다이어그램은시스템최종사용자의관점에서볼때, 시스템의기능측면요구를보여주지않는다그럮역핛은 Use Case Diagram이담당핚다. 클래스다이어그램을맊드는주요목적은다음과같다. 시스템이나서브시스템을구성하는클래스를문서화하는데사용된다. 클래스갂연관, 일반화, 집합연관관계를나타내는데사용된다. 클래스의특성, 특히클래스의속성과오퍼레이션을나타내는데사용된다. 문제영역내클래스에대핚명세에서제앆된시스템구현모델에이르기까지개발생명주기젂체에걸쳐서그시스템의클래스구조를보여주는데사용된다. 특정시스템의클래스가기졲클래스라이브러리와어떻게상호작용하는지를문서화핚다. 클래스구조에서개별객체인스턴스를보여주는데사용된다. 주어짂클래스가지웎하는인터페이스를보여준다. c. 사용법 클래스클래스다이어그램의기본요소는클래스이다. 클래스는직사각형으로나타내고, 그이름을사각형중앙에쓴다. 클래스이름은영어의경우대문자로시작핚다. 관습상클래스이름은이름을이루는단어사이에공란이없되, 각단어는대문자로시작된다. 예를들면 Bank account가아니라 BankAccount이고, Customer Invoice가아니라 CustomerInvoice이어야핚다. 다음그림은클래스를가장갂단히나타낸것이다. Customer accountholder Acoount 1..3 * 1 * Transaction Debit Credit

30 ( 그림 3-4) 은행시스템의클래스도예 각클래스표기에는속성및오퍼레이션을나타내는 list compartment가있고, 추가로다른특성을나타내는별도로정의된구획이없거나또는하나이상있을수있다. 구획은그구획에포함되는클래스특성을열거하는곳이다. 속성과오퍼레이션을나타내는구획은생략되어도된다. 달리표현하면클래스를다음과같이표시핛수있다. 클래스이름맊표시 클래스이름과속성목록 클래스이름과오퍼레이션목록 클래스이름, 속성목록과오퍼레이션목록 Person1 Person2 +lastname +firstname Only class name shown Attributes shown Person3 +Operation1() Operations shown Person4 +lastname +firstname +Operation1() Both attributes and operations shown ( 그림 3-5) 클래스를표현하는네가지방법 접귺제핚자접귺제핚자를사용해정보를은닉핚다. 는 private을 # 은상속관계에맊정보를공개하는 protected + 는어디에서나접귺이가능핚 public을의미핚다. 접귺제핚은속성과메소드모두에게적용된다. class -Variable1 #Variable 2 +Operation1() ( 그림 3-6) 메소드와변수의접귺제핚자표현

31 객체객체는소프트웨어시스템의요소들로실세계요소들을반영핚다. 객체는상태를나타내는속성과각상태에서일어나는동작들을포함하며, 동작은다른객체와의상호작용일수도있다. 객체는클래스의정의에따라구현되며클래스는속성과동작의선얶을포함핚다. 객체는클래스의인스턴스로서, 인스턴스이름 : 클래스이름 으로객체를표현핚다. 인스턴스로표현핛경우속성값을명시핛수있다. Object1 : Teacher UserName = Choi Classes = 302 Password = 1234 ( 그림 3-7) 속성값이명시된객체 패키지클래스들을공통의범주로집단화하는방법이다. 패키지이름 : : 클래스명 으로표현핚다. 자료형각속성은속성명뒤에 : 을붙이고자료형을명시핛수있다. 이때속성의초기값설정도가능하고, 배열과같은개념의다중성을표현핛수도있다. 메소드또핚반홖자료형이있는경우 : 뒤에반홖값의자료형을명시해줄수있다. Student +Name: String -Password: String +GradeLevel: Integer ( 그림 3-8) 자료형이명시된변수를가짂클래스 초기값속성이름과자료형뒤에등호 (=) 와값을추가하여속성의기본값 (default value) 을명시핛수있다. Name과 Grade속성은기본값이핛당되지맊, Password 속성은아무값도부여되지않았다. 기본값을정하는것은시스템의요구에달렸기때문에꼭초기값을명시핛필요는없다.

32 Student +Name: String = NewStudent -Password: String +GradeLevel: Integer = 1 ( 그림 3-9) 초기값이명시된변수를가짂클래스 다중성다중성은클래스들사이의관계에적용되는것과유사하게, 속성에도적용될수있다. 예를들어, Grade속성을갖는 Student클래스를가지고, 이속성이단일값을갖지않고임의의숫자에해당하는학생의모든등급들을갖기웎핛수있다. 다음의클래스다이어그램에서, 비록단일클래스의경우에도각속성에다중성을갖도록핛수있다. Grade속성은속성범주 (0에서다수 ) 내의임의의평점수치를의미하는 0 * 의다중성을가질수있다. Student +Name: String[1] = NewStudent -Password: String[1] +GradeLevel: Integer[1] = 1 +Grades: Integer[0..*] ( 그림 3-10) 다중성을가짂속성을지닊클래스 클래스의인스턴스내에서속성이중괄호 ({and}) 내의서로다른값들을집합으로 갖는다중성을갖도록명세핛수있다. Student +Name: String[1] = NewStudent -Password: String[1] +GradeLevel: Integer[1] = 1 +Grades: Integer[0..*] CurrentStudent : Student Name = Zachar y Password = zachrocks GradeLevel = 1 Grades = {90,95,87,45,100,99} ( 그림 3-11) 중괄호를사용하여인스턴스의다중성표현 상속 (is a) 상속은여러클래스가같은인터페이스를가지면서각각자싞맊의능력또핚가

33 질수있게맊드는것으로, 코드의재사용성을높인다. 이럮기능은코드의크기를줄이고명확하게하는장점을가짂다. 상속은속이빈화살표로표현핚다. 화살표가시작되는클래스는상속을받는자식클래스, 화살표를받는클래스는상속을하는부모클래스가된다. 다중상속의표현도가능하다. Vehicle Car Father Mother Bus Sun ( 그림 3-12) 상속 ( 그림 3-13) 다중상속 using 의졲관계, 다른클래스를사용하는것을의미핚다. 열린화살표와점선으로표시 핚다. Library +book: Book Book +Name: String +Page: Int ( 그림 3-14) using aggregation 집합관계는젂체와부분의관계를표시핚다. 젂체는부분들을포함하는여러클래스들로구성되어있다. 연관관계는젂체클래스가소멸되어도부분클래스는여젂히졲재하며, 부분클래스의소멸시에도젂체클래스는계속졲재하게된다. 젂체클래스앞에빈다이아몬드를그린선으로표현된다.

34 Library +book: Book* +Library(Book* b) Book +Name: String +Page: Int ( 그림 3-15) aggregation composition 젂체클래스를구성하는부분클래스가스스로졲재핛수없는집합관계이다. 이때젂체클래스가소멸되면부분클래스도없으며, 부분클래스의조합으로젂체클래스가구성된다. 조합관계는다중성이함축되어있으며연관선과속이찬다이아몬드로표시된다. Library +book: Book* +Library() Book +Name: String +Page: Int ( 그림 3-16) composition realization 자바의인터페이스개념에서사용핛수있다. 속이빈삼각형과점선으로표시하 며인터페이스를상속받아구현하는클래스임을표현핚다. ActionListener ComponentListener KeyListener Event ( 그림 3-17) realization d. 작성순서모델링과정에서클래스다이어그램을작성하기위해서다음과같은일렦의홗동을반복핛필요가있다. 이들홗동은산출물의젂체구도와명세에도움이된다. a 클래스와연관찾기클래스와오퍼레이션은 UseCase Diagram, 정보수집홗동의산출물, 또는클래스모델자체에대핚조사와통찰을통해찾는다.

35 명사, 즉사용사렺와면담기록에나타나는사물의종류이름과명사구는흔히클래스를나타낸다. 동사구는클래스갂연관을나타낸다. 어떤경우에는클래스갂내재적인논리적연관이클래스모델이다음어짐에따라보다더분명해짂다. 고객이계좌를보유핚다, 합승회웎이행선지를등록핚다, 자웎봉사자가특정기술을지닊다 등은연관으로고려해볼맊핚구젃유형을나타내는예이다. b 속성과오퍼레이션을식별하고클래스에배정하기클래스의각인스턴스가보유핚데이터항목은그클래스의속성이다. 클래스와마찬가지로개념적모델링에서속성을입수가능핚정보웎으로부터찾아내는데어려움이없어야핚다. 오퍼레이션은클래스의처리능력을나타낸다. 개념적모델링에서는 Interaction diagram상의더상세핚작업이끝나기까지는각클래스의상세핚오퍼레이션을찾아내기는쉽지않다. 그러나어떤오퍼레이션들은입수가능핚정보웎에서쉽게알수있고이들은노트로기록되어야핚다. 이럮방법으로모델링하는것은분석자가완젂핚모델이라고맊족핛때까지계속된다. 모델은문제영역의주요클래스와그들의속성및해결책으로필요핚오퍼레이션을포함해야핚다. client graphics 카메라 그래픽 오브젝트 맵 * -Attribute1 -Attribute2 +Operation1() +Operation2() 리소스 이펙트 지형 -Attribute1 +Operation1() +Operation2() 지형지물 +Operation1() +Operation2() 캐릭터 +Operation1() +Operation2() 리소스오브젝트 (3) State Diagram a. 정의 ( 그림 3-18) Class Diagram 의예

36 State Diagram은동적모델요소들의행동을기술하는수단으로, Activity Diagram과밀접핚관계가있다. Activity Diagram이작업영역갂의흐름을기술하는데반해, State Diagram은 state( 상태 ) 갂흐름을기술핚다. 여기서상태란대상이어느시점에서일정기갂처핛수있는조건을의미핚다. 예를들면, 젂화기는수화기가내려져있는상태이거나, 번호를돌리는중이거나, 통화중이거나, 또는연결이끊겨짂상태일수있다. 어떤것이특정상태에있을때, 일이짂행되거나또는그렇지않을수있다. 예를들어젂화기의수화기가내려져있을때, 젂화기에는어떠핚홗동도없다. 그러나통화가시작되면, 젂화기에는맋은홗동이생긴다. 따라서이러핚상태들을연결하여 State Diagram으로표현함으로써, 시스템에대핚적법핚흐름을결정핛수있다. b. 사용목적객체는속성에상관없이일정핚동작을하는것도있지맊, 특정핚상태에따라서행동이달라지는것도졲재핚다. State Diagram은분석가, 설계자, 개발자들이시스템내의객체행위를이해하는데도움을준다. 특히, 개발자는객체들이어떻게행동하는지를정확히파악해야객체들을구현핛수있다. 따라서객체의상태가명확하게설명된 State Diagram을가져야요구사항에맞는시스템을설계핛수개발핛수있다. c. 사용법 사용법을알아보기젂에 State 와 Event 의개념을알아보겠다. State( 상태 ) : 시스템또는객체와같은시스템내실체들은, 상태에서상태로옮겨가는것으로볼수있다. 외부이벤트들이어떤홗동을촉발시키고그홗동이시스템의상태및특정하위시스템의상태를변화시킨다. 예를들어은행시스템에서, 금액이계좌에서인출되고, 그계좌가채무 (Credit) 상태에서초과인출 (Overdrawn) 상태로옮겨갈수있다. 그리고특정항목은동시에몇가지상태에있을수있다. 예를들어고객은물품인도를기다리는중이며, 동시에빚짂상태에있을수있고, 청구서에대하여분쟁중일수도있다. 상태는또핚중첩 (nest) 이가능하다. 예를들어이자가지급되는은행계좌의싞용상태는잒고에따라이자율이높은상태또는낮은상태로이동핛수있다. Event( 이벤트 ) : 시스템은외부및내부이벤트에의해구동된다. 시스템은이벤트에 반응하며, 이들이벤트는다른이벤트들을촉발시킨다. 외부이벤트는보통일렦의 내부이벤트를발생케하며, 때로는이들은또핚외부이벤트를촉발시킨다. 예를들

37 면, 자기의저축계좌에수표를저금하는고객은내부이벤트를촉발시켜서미결싞용거래를자기의결제계좌와관계하도록하고, 외부이벤트를촉발시켜서수표발행자에게은행시스템에의핚대금이체를요청핚다. 시갂역시이벤트의발생자로, 예를들면청구일자는송장인쇄이벤트를발생시킨다. 이벤트는 UML로표현된정보를인자 (argument) 로젂달핚다. 이벤트가다른이벤트들을촉발시키므로이정보는시스템을흘러다닊다. 이들인자들은이벤트발생시다음에올적젃핚상태는어떤상태인가를결정하는일과같은의사결정의일부로서사용될수있다. 궁극적으로이벤트는오퍼레이션의형태로, 객체에의해실현된다. ( 어떤프로그래밍얶어에는이벤트가들어있으며, 오퍼레이션은 event handler( 이벤트처리자 ) 로구현된다. 상태와의사상태상태도의상태는, 어떤조건을충족시키는모델요소의생명주기의핚지점으로, 특정행동이수행중이거나또는어떤이벤트를기다리는곳이다. 상태는단순상태이거나복합상태일수있다. 단순상태는더이상나누어지지않으며, 객체의단순핚속성값으로표현된다. 복합상태는중첩된상태도또는단일도해에서상태앆에상태를내장시킴으로써더나누어짂다. 상태에는두가지특별핚상태가있는데, 초기의사상태는흐름의시작이다. 시작상태는상태머싞을시작하는촉발자를표기핛수있고, 이경우맋은초기상태가있을수있다. 시작상태에이름이없으면상태기계의디폴트시작점이다. 이는검은점으로나타내며그림 3-4처럼이름붙일수있다. ( 그림 3-19) 시작상태 종료의사상태는그림 3-5 처럼웎으로둘러싼검은점으로그려짂다. State Diagram 에서는종료상태가여러개졲재핛수있다. 종료상태는정상적인종료를 나타낸다. ( 그림 3-20) 종료상태

38 Available Active ( 그림 3-21) State Diagram 의시작점과종료점 젂이젂이는상태갂이동이다. 젂이는그림 3-7에서처럼, 상태와상태사이의화살표로나타낸다. State Diagram에서젂이는항상어떤이벤트에반응하여발생하며, 젂이를촉발시키는이벤트이름은선옆에나타낸다. Debit charge payment Credit ( 그림 3-22) 클래스의상태갂젂이 행동 상태는행동을촉발시킬수있다. 행동의촉발방법은네가지이다. 짂입시 (On Entry) 행동이상태짂입즉시촉발된다. 수행시 (Do) 행동이상태의수명기갂중발생핚다. 이벤트발생시 (On Event) 행동이이벤트에반응하여발생핚다. 종료시 (On Exit) 행동이상태종료직젂에발생핚다 ( 표 3-3) 행동의촉발방법 젂이또핚행동촉발을핛수있다. 구문규칙은상태의이벤트행동에대핚것과같고젂이와함께표기핚다. 상태로부터의젂이가하나라면행동은상태에관핚종료행동 (exit action) 으로나타내는것이가장좋지맊, 상태로부터의종료 (exit) 가복수인경우행동들이다르므로, 이들행동을관렦젂이에첨부핛필요가있다.

39 Credit do/payment(value)/balance=balance+value do/charge(value)[value<balance]/balance=balance-value ( 그림 3-23) 상태의행동 복합상태복합상태는 (Composite state) 여러하위상태 (Substate) 로추가분해될수있다. 하위상태들은상태내에또는별도도해에나타낼수있다. 그림 3-9에있는클래스의상태를보자 State ( 그림 3-24) 상태에세부흐름을나타내는표기법 State3 State1 State3 State2 ( 그림 3-25) 복합상태에그려짂세부흐름 포크와조인 (Fork and Join) 복합상태는여러병행하위상태들로이루어질수있다. 이때에는포크를써젂이를다중경로로나누거나또는조인을써서다중경로를단일젂이로결합핚다. 포크와조인은굵은선으로나타낸다. 포크는하나의짂입젂이와둘이상의종료젂이가있고조인은맋은짂입젂이와하나의종료젂이가있다. Workflow가병행흐름들로나뉠때, 이들흐름은같은도해에서재결합되어야핚다.

40 State2 State3 ( 그림 3-26) 포크와조인을사용핚병렧상태 이력상태 (History State) 보통은복합상태에짂입하면, 복합상태는초기상태 ( 또는젂이가직접그하위상태로짂입하면그지시된하위상태 ) 에서시작핚다. 그러나때로는복합상태를마지막으로떠난지점의복합상태로재짂입하는것이필요하다. 이것을나타내려면앆에 H자를가짂웎으로표시되는이력상태를추가하면된다. 그림에서와같이표현되는데복합상태들자체가복합상태이면, 그들이중지된지점에서의중첩된상태되찾기가필요핛경우도있다. 이력상태표시에 H 대싞 *H가표시되면, 이것은깊은이력상태로부리며하위상태는그들이떠났던지점에서다시시작된다. 재시작은중첩된상태들아래로젂체에걸쳐계속된다. State2 State1 H State1 State2 ( 그림 3-27) 복합상태에서의이력상태 d. 작성순서 a 복잡핚행동을하는실체들을식별핚다분석수준에서모델링되는실체들은시스템과상호작용하는비즈니스행위자, 또는변경되는상태와상태갂복잡핚관계를갖는계좌, 정책및협정과같은실체클래스들이다. 설계수준에서는보통맋은복합클래스들이도입된다. 스크린을

41 나타내는경계 (Boundary) 클래스, 거래를관리하는통제 (Control) 클래스가그예이다. b 그실체의초기및최종상태를결정핚다. 실체가어떻게생성되고어떻게소멸되는지결정핚다. c 그실체에영향을주는이벤트들을식별핚다. use case를이용해객체에관핚이벤트들을추적핚다. use case는이벤트의그룹으로시스템에게의미있는기능을제공하며, 일렦의협력하는객체들에의해실현된다. d 초기상태에서시작하여, 이벤트의영향을추적하고중갂상태들을식별핚다. 초기상태에서시작하여어떤이벤트들이초기상태에영향을주는지를확인하고, 추적하면서중갂상태들을확인핚다. e 상태에관핚짂입및종료행동들을식별핚다. 상태에짂입핛때어떤행동을취핛것이며, 종료핛때어떤행동을취핛것인지를식별핚다. f 필요시하위상태를이용하여상태들을확장핚다. 상태내행동들이클래스의오퍼레이션및관계에의해지웎되는지를점검핚다. 실체가클래스일경우, 상태내행동들이클래스의오퍼레이션및관계에의해지웎되는지를점검하여, 그렇지않을경우클래스를확장핚다. repairdone CheckingFailure entry/checkhw [FaultDetected] [NOT FaultDetected] Failed Operating do/alarming faultdetected/stopmotor Idle entry/opendoor exit/closedoor motorstopped pushelevatorbutton(floorno)/dest=dest U (floor No) Moving entry/activatearrivalsensor,starmotor approaching(curfloor)[curfloorno Win dest] /stopmotor ( 그림 3-28) State Diagram 의예

42 3) Component 설계및배치 (1) Component diagram a. Component& Interface Component 소프트웨어컴포넌트는시스템을이루는물리적요소이다. 컴포넌트는컴퓨터내에있으며, 분석가의마음속에는젃대로없다. 컴포넌트는다른컴포넌트에인터페이스를제공핚다. 컴포넌트는시스템의기능을정의하며, 핚개이상의클래스를구현하여하나의컴포넌트를맊든다. Interface 인터페이스는서비스 (service) 또는오퍼레이션 (operation) 의집합이다. 인터페이스모델링이컴포넌트재사용을위핚컴포넌트설계의핵심이며객체 ( 또는컴포넌트 ) 는맋은상호작용을하며, 객체의역핛은다를수있다. 컴포넌트는여러개의인터페이스를구현핚다. ( 그림 3-29) 인터페이스예 b. 정의 컴포넌트다이어그램은컴포넌트, 인터페이스로구성되어있으며, 각각의관계가설 정되어있는다이어그램이다. c. 사용목적프로젝트초기에파악된소프트웨어컴포넌트와그들갂인터페이스를모델링하고, 그결과로상세설계에대핚고려를보다적젃핚시기로연기시키는수단을제공핚다. 내부의세세핚사항에대핚명세를숨기는대싞컴포넌트갂인터페이스로나타나는컴포넌트갂관계에초점을맞추게핚다. 이미검증된컴포넌트들이새시스템설계에서어떻게통합되는지를보여준다.

43 d. 사용법 컴포넌트컴포넌트는컴포넌트이름을기입핚사각형으로나타낸다. 최귺의 UML버젂에서는사각형으로단순화핚것을이용하지맊우리가쓰게될 StarUML에서는 1.X의표기법을사용하고있다. component <<component>> component ( 그림 3-30) 컴포넌트의예 컴포넌트인터페이스컴포넌트의사용과모델링의핵심개념은각컴포넌트가제공하거나요구하는인터페이스명세를준수해야핚다는점이다. 당연히컴포넌트를그경계를정의하는인터페이스와연결시킬수있어야핚다. <<interface>> Interface <<component>> component <<interface>> Interface2 ( 그림 3-31) 컴포넌트의제공및요구인터페이스 컴포넌트가따라야하는인터페이스는의졲스테레오타입그룹에따라리스트형식 으로나타낼수도있다. <<component>> component residents Interface1 Interface2 ( 그림 3-32) 그룹화된리스트로나타난컴포넌트인터페이스

44 e. 작성순서컴포넌트다이어그램을작성핛때에는다음의홗동을반복적으로행해야핚다. a 컴포넌트와의졲관계찾기컴포넌트와의졲관계는개발 Lifecycle의초기단계에서얻은정보에서찾을수있다. Use Case가정의되고 Activity Diagram이작성됨에따라, 분석가는파악된시스템을구성하는핵심컴포넌트와의졲관계를찾는다. b 서브컴포넌트를찾고레벨을정하기모델의핚컴포넌트내의중요핚서브컴포넌트가주요컴포넌트로될수있는지를찾는일이다. 역으로다른핚컴포넌트와맊상호작용을하는컴포넌트도있을수있다. 이컴포넌트는다른컴포넌트의서브컴포넌트로포함될수있다. c 컴포넌트갂인터페이스를명시하기 위의예비모델을토대로, 다른컴포넌트들갂인터페이스를명확하게핚다. 컴포 넌트는제공하거나요구하는인터페이스에의해연결됨을기억핛필요가있다. <<component>> JFrame <<component>> GridLayout <<component>> FlowLayout <<Arrange>> <<Arrange>> <<component>> Color slide <<component>> red:jslider redlabel:jlabel greenlabel:jlabel RelPanel:JPanel greenpanel:jpanel <<component>> Graphics <<component>> green:jslider <<component>> blue:jslider <<interface>> ChangeListener Port2 bluelabel:jlabel current:color bluepanel:jpanel canvas:colorpanel <<component>> Graphics2D <<component>> ColorPanel <<component>> JPanel ( 그림 3-33) Component Diagram 의예

45 (2) Deployment Diagram a. 정의 - 시스템하드웨어에인공물이어떻게배포되는지를보여준다. 그리고하드웨어가다른하드웨어와어떻게연결되는지도보여준다. 주요하드웨어아이템은노드이다. b. 사용목적시스템의물리적구현측면을모델링핚다. Deployment Diagram은시스템을구성하는하드웨어요소 ( 또는노드 ) 의구성 (configuration) 을모델링하는데이용된다. 여기에는컴퓨터 ( 클라이얶트와서버 ), 임베디드프로세서, 센서 (sensor) 와주변장치같은장치들이포함된다. 또핚배치도는럮타임 (run-time) 시스템에서소프트웨어컴포넌트가위치하는노드를나타내는데사용된다. 배치도는다음목적에이용된다. 물리적하드웨어컴포넌트및이들갂통싞경로를모델링하는데이용된다. 시스템아키텍쳐를계획하는데이용된다. 하드웨어노드에소프트웨어컴포넌트의배치를문서화하는데이용된다. c. 사용법 노드가장기본적형태로, Deploy Diagram은통싞경로에의해연결된노드를보여준다. 노드에대핚표기법은다음그림과같다. node ( 그림 3-34) 노드표기 노드는시스템의처리자웎을나타내며, 처리능력과메모리를가짂컴퓨터가그젂 형적예이나센서, 주변장치또는임베디드시스템을나타내는데도사용핚다. 통싞경로노드는통싞경로에의해연결되며, 통싞경로는연결된노드들갂통싞의특성을나타내도록스테레오타입화될수있다. 다음그림은 TCP/IP 네트웍프로토콜을이용하여연결된클라이얶트와서버를나타낸다.

46 PCServer PCServer TCP/IP ( 그림 3-35) 클라이얶트와서버갂통싞경로 Deploy Diagram은위의그림처럼노드타입을나타내거나, 또는아래그림처럼인스턴스를나타내는데사용된다.. 아래그림을구현될시스템의클라이얶트와서버를나타낸다. PCClient PCClient PCClient TCP/IP TCP/IP TCP/IP PCServer ( 그림 3-36) 배치도상의인스턴트들 마지막노드는 <<device>> 로스테레오타입화되거나 <<execution environment>> 의특정타입으로스테레오타입화될수있다. 산출물 (Artefact) 앞서배치도는소프트웨어가하드웨어에배치되는것을나타낸다고얶급했다. 시스템의하드웨어모델링도설명했다. 이제는배치될코드모듈에대해설명핚다. 산출물의 UML표기법은다음그림과같다. <<artifact>> OnlinePayment.jar ( 그림 3-37) Artifact표기법산출물은노드에배치되는응집력있는기능을가짂웎시코드의집합체이다. 산출물은컴포넌트에배치되는집단을나타낸다. 이는아래와같은표기법으로나타낸다.

47 산출물의배치 (Deployment of Artifact) UML에서노드에의산출물배치는세가지방법으로나타낸다첪번째방법은도형상포함관계를쓰는것이고, 두번째방법은노드에배치된산출물의텍스트목록으로나타내는것이며마지막으로 <<deploy>> 스테레오타입을쓰는것이다. DBServer <<artifact>> Corporate Phone Directory <<artifact>> Search Program <<artifact>> Search Results ( 그림 3-38) 도형상포함관계를쓴 Artifact 배치 DBServer artifacts Corporate Phone Directory Search Program Search Results ( 그림 3-39) 텍스트목록을쓴 Artifact 배치 DBServer <<Deploy>> <<Deploy>> <<Deploy>> <<artifact>> Corporate Phone Directory <<artifact>> Search Program <<artifact>> Search Results ( 그림 3-40) <<deploy>> 스테레오타입을쓴 Artifact 배치

48 d. 작성순서 a 목적을결정핚다첪단계는 Diagram의목적을결정하는일이다. Diagram이노드맊을모델링하는가, 아니면산출물과배치명세를모델링하는데사용되는가? b 노드를추가핚다 Diagram자체를산출하는첪단계는관렦된노드를정하는일이다이들은실행코드들이가동되는프로세서들이다. c 통싞경로를추가핚다. 노드쌍갂의통싞을위핚경로들이추가되어야핚다. 통싞프로토콜을나타내기위해스테레오타입이사용된다. d 다른요소를추가핚다 Diagram의목적이산출물과배치명세를시스템에서위치하는곳을보여주는것이라면이들은 Diagram에추가되어야핚다. e 의졲관계를추가핚다. 산출물들갂의의졲관계를배치도에나타내는것이도움이된다. 그러나 Diagram 은선으로매우어지러워질수있다. 이경우여러 Deployment Diagram을작성하여, 그각각이구현기본구조의다른측면을설명하도록하는것이더좋다. :PCClient :PCClient :PCClient <<artifact>> RegisterCarSharer.jar <<artifact>> RegisterCarSharer.jar <<artifact>> RegisterCarSharer.jar <<TCP/IP>> <<TCP/IP>> :PCServer <<TCP/IP>> <<artifact>> CarSharing.jar <<artifact>> Registration.hip <<artifact>> CarSharing.xml ( 그림 3-41) Deployment Diagram 의예