Software Modeling & Analysis - UML Report T6 200811425 김평석 200811435 신성호 200811449 이찬희 200811454 전인서 200811462 최현빈
Contents History of UML & Rational Unified Process Construction of UML & Diagram Use Case, Sequence Diagram Class Diagram With Java UML Tools Reference
History of UML & Rational Unified Process History of UML Rational Unified Process
History of UML (Unified Modeling Language) UML 개발배경 객체지향적분석과디자인에대해다양한방면으로실험적인접근을하던 방법론자들에의해서다양한객체지향 (Object- oriented) 모델링방법이등 장하게된다. 그중에서도 Booch 의 OOD(Object-Oriented Design) 과 Ivar Jachobson 의 OOSE(Object-Oriented Software Engineering), Jim Rumbaugh 의 OMT(Object Modeling Technique) 방법론이유명하였 는데, 이렇게많은방법론이존재하다보니서로다른방법론을사용하는조 직간에모델정보를공유하기위해서는각조직에서사용하는방법론의표 현기호를익히고이해해야했다. 따라서모델을표현하기위한동일한기호, 모델링언어를사용하는것에대한필요성을느끼게된다.
History of UML (Cont.) UML 개발 UML 개발은 Booch와 Rumbaugh의방법론을통합시킨 Unified Method 0.8로시작되었고, 이듬해 OOSE와다른기능들을통합하면서 UML 0.9가탄생하였다. 1997년 9월, UML1.1이발표되었고, OMG(Object Management Group) 가표준으로채택하였다. 그후 UML은 2004년 UML 2.0 발표, 2010년 UML 2.3 발표, 2011년 UML 2.4 발표등꾸준히수정 보완되고있다.
Rational Unified Process RUP 란? UML언어를기초로정의된 Unified Process를 Rational사에서개발도구와통합하여개발한객체지향방법론이다. RUP 의특징 Use-case기반으로, 분석, 설계, 테스트로의추적성및일관성을유지한다. 또한, 아키텍쳐를중심으로복잡한프로젝트를운영하고, 시스템의무결성을유지하도록프로젝트전체에대한통제를할수있게한다. RUP는점진적인개발과정을채택하고있는데, 이러한개발단계조정과 Workflow간에적절한조정이매우중요하다. 이때적절한조합을통해개발을진행하게되며, 반복을계속해서소프트웨어개발을관리하며최종적으로완성된시스템을만들어내게된다. RUP는 4개의단계와 9개의 Workflow로구분된다.
Rational Unified Process (Cont.) RUP 의 4 단계 Inception phase( 개념화 ) : 프로젝트범위설정 Elaboration phase( 상세화 ) : 문제인식후설계및위험제거 Construction phase( 구축 ) : 반복, 점증적으로개발 Transition phase( 이행 ) : 사용자에게시스템교육및전달
Rational Unified Process 9 단계 WorkFlow Business Modelling : 시스템이사용될조직의업무모델링 Requirements : 요구사항분석 Analsys and Design : 분석및시스템설계 Implementation : 시스템구축 Test : 전체시스템검증 Deployment : 제품출시 Configuration and Change Management : 형상및제품관리 Project management : 프로젝트과정관리 Environment : 제품및개발환경관리
Construction of UML Construction of UML & Diagram UML Diagram 1. Class Diagram 2. Object Diagram 3. Use Case Diagram 4. Collaboration Diagram 5. Sequence Diagram 6. State Chart Diagram 7. Activity Diagram 8. Component Diagram 9. Deployment Diagram
Construction of UML 측면 정적 (Static) 측면 : 시간을흐름을무시하고, 모델링의대상범위에서의오브젝트의구조와관계를나타냄 기능적 (functional) 측면 : 어떠한것을주고받으며, 화면표시를언제, 어떻게바꾸는가를나타냄 동적 (Dynamic) 측면 : 시간의경과와이벤트의발생에따라오브젝트의상태가어떻게변화하는지 구조적 (Implemental) 측면 : 시스템을실행하기위해필요한컴퓨터와기억매체의공간적배치
Construction of UML (Cont.) 관점 (perspective), 레벨 개념레벨 : 문제영역 ( 도메인 ) 의해석, 구현과상관없이해당영역에서다루는개념과관계를정리함으로써문제영역의다양한사항을이해할수있게함 사양레벨 : 설계작업에대응하고문제에대한해결책을완성함. 즉, 필요기능과실현방법을고안 구현레벨 : 개발작업에대응하며, 사양레벨에서고안된실현방법을기초로하여소프트웨어를작성하는데필요한정보를덧붙임 하지만측면과관점에대한구분기준이명확하지않아서, 개발자가수행하고있 는모델링작업의목적이무엇인지를확실히아는것이중요하다
UML Diagram 다이어그램의목적은시스템을여러가지시각에서볼수있는뷰를제공 하는것이다. 구분요소에따라다이어그램을나누면, 다음과같다. 관점 / 측면정적측면구조적측면동적측면물리적측면 개념레벨 사양레벨 구현레벨 Class Diagram Object Diagram Use Case Diagram Collaboration Diagram Sequence Diagram Activity Diagram State Chart Diagram Component Diagram Deployment Diagram
Diagram 1. Class Diagram Class Diagram 은문제영역을구성하는모델요소간의관계를나타내는 다이어그램 < 도서관대여관리시스템의예 >
Diagram 2. Object Diagram 구체적인예 ( 인스턴스 ) 에의한구조를기술 Class Diagram 를이해하기쉽게한 Diagram < 도서관대여관리시스템의예 >
Diagram 3. Use Case Diagram 액터 ( 시스템과커뮤니케이션하는주체 ( 사람, 시스템등 )) 의시점에서본 시스템의기본적인행동을기술 < Use Case Diagram >
Diagram 4. Collaboration Diagram Object Diagram 에메세지의화살표로송신관계를부가한것 메시지는조작의출발점, 번호를적어메시지가전달되는순서를나타냄 < Collaboration Diagram >
Diagram 5. Sequence Diagram 그림의아래로향하여시간이흐르고, 옆으로오브젝트간을메시지가왕래함 Collaboration Diagram 과는다르게시간의흐름을표현 < Sequence Diagram >
Diagram 6. State Chart Diagram 오브젝트가가질수있는상태의변화를나타낸것 오브젝트의상태를모서리가둥근사각형으로나타내고, 전이를나타내는화살표 ( 열린화살표 ) 의방향으로그사이의전이관계를나타낸것 < State Chart Diagram > ' 도서명 ' 이라는오브젝트가취할수있는상태를나타냈다. 상태변화가시스템의행위에큰영향을미치는오브젝트에대해서이다이어그램을작성한다
Diagram 7. Activity Diagram State Diagram의특수한형태 어떤활동의동작상태가완료되면, 다음활동이동작상태로바뀌는일련의동작상태의연결을나타냄 <Activity Diagram> 책의대여및반납의 Workflow, 회원과사서의활동을구분할수있어, 보기가편하다. 다만무리한일체화는오히려문제가될수있다
Diagram 8. Component Diagram 컴포넌트들을나타내고, 의존을나타내는화살표등으로그의존관계를기술 < Component Diagram > 사서조작모듈컴포넌트가장서관리모듈컴포넌트의 'is 대여가능 ()' 이라는인터페이스를사용하고있다는것을나타낸다
Diagram 9. Deployment Diagram 시스템의실행시에필요로하는물리적인처리자원, 실행모듈, 소프트웨어컴포넌트의인스턴스를노드라고함 노드를입체로표현하고, 그사이를의존화살표와접속관계를나타내는실선으로연결, 이들의통신관계를나타냄 < Deployment Diagram > 컴퓨터나 LAN 등이어떤물리적관계로접속되어지는가를보여준다
Use Case Diagram & Sequence Diagram Use Case Diagram Sequence Diagram
Use case Diagram Use case 와 Actor, 그들간의관계를함께나타내는것으로서, 시 스템의동적인측면모형을작성한다. 시스템이나하위시스템, 클 래스의행위모형을작성하는데중심이된다. 참고사항 사용자요구분석이선행되어야한다. Forward Engineering에서실행시스템을시험할때중요 Reverse Engineering에서실행시스템을파악할때중요
Use case Diagram (Cont.) 포함되는내용 Subject( System ) Use case Actor Association, Generalization, Include, Extend관계명시 System UseCase Actor1 Actor2
Use case Diagram (Cont.) Subject 전체시스템 (Subject) 을큰사각형으로나타낸다. 사각형밖에위치할 Actor를배치하고 Subject와의교류를표시한다. Use case Diagram을이용하여 Actor의역할을명시한다. 시스템생명에필요한 Actor만포함시킨다. System Actor UseCase
Use case Diagram (Cont.) Use case 순차적으로발생하는동작 ( 시스템이제공해야하는서비스 ) 을기술하는것이며변이를가질수있고, 시스템은이러한활동을수행하여 Actor에게결과를준다. ex) ( 네이버이용시 ) 회원가입 이메일 검색 Use case 는이름으로구별하며이때 simple name 은 use case 자체의이름이고 qualified name 은 use case 가속한 group 의이름이다. simple name qualified name:: simple name < simple name 의 use case 도식의예 > < qualified name 의 use case 도식의예 >
Use case Diagram (Cont.) Collaboration Use case가하는일을명시적으로나타낸다. 대부분의경우하나의 use case는하나의 collaboration으로구현가능하기때문에이경우명시적으로작성할필요없다. 모든 use case에명시된흐름을만족시키면서최소의개수로좋은구조로된 collaboration 을찾는것이시스템아키텍처의논의대상 use case collaboration < use case 와 collaboration 의실현화관계도식의예 >
Use case Diagram (Cont.) Actor Use case와교류할때사용자가맡고있는역할을나타낸다. 사람이나하드웨어장비, 또는다른시스템이시스템과맺고있는역할을나타낸다. 시스템을제외한모든외부요소를의미한다고볼수있다. 시스템에속하는것이아니라. 시스템바깥에위치한다. 한개체가여러 Actor의역할을수행할수있다. Actor의관계에따라 Generalization, Specialization 관계를나타낼수있다. 허수아비모양으로나타낸다. 빈세모의화살표는 Generalization관계를표현한다.
Use case Diagram (Cont.) System UseCase Actor Actor < 전체적인 Diagram 에서 Actor 도식의예 > 부산시민 대한민국국민 < Actor 간의 Generalization 도식의예 >
Use case Diagram (Cont.) Association Actor는 Use case에연결되게되는데이는연결된 use case와대화한다는표시이고, 메시지를주고받을수있다. 실선으로표현되며메시지의방향을표현할수도있다. System UseCase 로그인 Actor < 양방향 > 사용자 회원가입 Actor UseCase < Actor 만메시지를보내는단방향 > < Actor 와 Use case 간의관계를표현한도식의예 >
Use case Diagram (Cont.) Use case 간의관계 Generalization 클래스의 Generalization과동일하다. 하위 Use case가상위 Use case에게기능을상속받음을표현한다. 카드결재한다 대금을결재한다 현금결재한다 < Use case 의 Generalization 도식의예 >
Use case Diagram (Cont.) Use case간의관계 Include Use case가다른 Use case를가져다쓰게될때의관계를 Include를통해표현한다. << include >> ex) 물품주문시주문정보를입력받고배송정보를입력받는것 포함되는 ( 주문정보입력, 배송정보입력 ) 은독자적으로인스턴스를생성하지못한다. <<include>> 주문정보를입력한다 물품을주문한다 <<include>> 배송정보를등록한다
Use case Diagram (Cont.) Use case간의관계 Extend 기본 Use case수행시특별한조건 ( Extension points) 을만족할때수행되는 Use case를표시 퀵서비스 <<extend>> 택배배송 extension points 배송지가출발지로부터 30km이내
Sequence Diagram 시간진행에따른메시지순서를강조하며객체간의동작을설명할필요없이잘표시되어있다. 시스템의동적구조, 즉객체와객체그룹사이, 객체와객체사이, 객체그룹과객체그룹사이의동적인행위를기술한다. 하나의 Use case에서객체간의 Interaction을확인해야하는경우에사용한다. Action의정의를표현하는데는적합하지않다.
Sequence Diagram (Cont.) 작성요령 Interaction을하는개체를가로축에배치한다. Interaction을주도하는개체를왼쪽에배치하고부속되는개체를순차적으로오른쪽에배치한다. 개체가주고받는메시지는세로축에배치시키되시간의흐름과개체의관계가일치하도록한다.
Life line Sequence Diagram (Cont.) 수직점선으로나타내며특정기간동안객체가살아있음을나타낸다. Life line은 create메시지를받은시점에서부터시작된다. 이때 Life line시작점 ( 맨위쪽 ) 에사각형을그려객체를나타낸다. destroy메시지를받으면끝난다.( 대문자 X를표시하여나타낸다. ) Create ( 이때부터 Life line 이시작 ) Life line * 빨간선은설명을위해표기함 Destroy( Delete ) * 다른객체로부터메시지 Destroy( Delete ) 를받아 Delete된다. * 자체적으로소멸된다.
Sequence Diagram (Cont.) Message 한 life line 에서다른 life line 으로화살표로나타낸다. 화살표방향은메시지를받는쪽이다. 매개변수와클래스이름을명시할수있다. name : Class Synchronous & Asynchronous Call 동기 : 호출하는객체가 return 을대기해야하는경우 ( 실선의속이찬세모화살표 ) 비동기 : 호출하는객체가 return 을대기할필요가없는경우 ( 실선의화살표 ) 첫번째메시지는확인되지않은 source 로부터발생되기때문에메시지를생성한참가자가없다. 이런메시지를 found message 라고한다. return 점선의화살표 생략할수있지만표시하는것이유리한경우도있다. Focus of control Life line 위에길이가긴직사각형으로나타내고개체가활동함을의미한다. 직접수행하든가하위프로시저를호출할때
Sequence Diagram (Cont.) Found message return message Synchronous message Asynchronous message
Sequence Diagram (Cont.) Loops, Conditionals, and the Like 각부분을사각형영역으로나타낸다. 왼쪽위의라벨형태로어떤종류인지명시한다. Optional execution : opt 로명시. 참이되는조건식을명시하며그조건이참일경우몸체 ( 사각형영역 ) 이실행된다는의미이다. Conditional execution : alt로명시. 사각형영역을복수개로나누고점선으로구분하여표시한다. 이때조건이맞는부분의영역이실행되며위쪽부터순차적으로접근한다. 모든조건이맞지않으면그영역을빠져나간다고볼수있다. Loop( iterative ) execution : loop로명시. 반복조건이참인경우계속해서사각형영역을반복하게된다. 거짓이면그영역을빠져나간다. 이밖에도많은연사자들이있다. Sequence Diagram 은 loop 나 conditional 을표현하기에는적합하지않다.
Sequence Diagram (Cont.) Loop execution 반복조건 < 소스코드예제 > Conditional execution 실행조건 실행조건 Optional execution 실행조건
Sequence Diagram (Cont.) 여러 Use case 에걸친하나의객체의 behavior 를보고싶으 면 state diagram 을사용해야한다. use case 또는 thread 에서동작하는객체의 behavior 를보 고싶으면 activity diagram 을사용해야한다.
Class Diagram With Java Java와 UML Class Diagram Class Concrete Class Abstract Class Interface Exception Relation Association Generalization Realization Dependency Package
Java 와 UML java programming 에서가장중요한것은 적절한객체지향설계를하고있는가? 이다. 자바가객체지향언어이기때문에객체지향분석설계에맞게구성되어야할것이다. 결국 Class, Use Case Component, Package 라는기본요소와 Dependency, Generalization 이라는기본관계를사용하면여러문제 를정적으로모델화할수가있다. 또한 State chart Diagram 이나 Sequence Diagram Component Diagram, 의기본적인기능을사용하면대부분의문제를동적인측면에 서모델화할수있다.
Class 클래스는객체지향의중심이되는개념으로당연히자바에서도가장중요한기능이다. UML에서는여러가지종류의클래스를적절한방법으로표현할수있게기능을제공하고있다.
Concrete Class concrete 라는것은구체화되어있다는의미로, 객체지향에있어서 Instance로실체화되어있는클래스로자바로말하면 New 키워드로생성할수있는 Class를말한다. Concrete Class Abstract Class
Concrete Class (Cont.) 왼쪽에있는부분이간략화된형태의 concrete class이다. 가운데있는것이속성과메소드를반영한것이다. 보다자세하게작성한경우가오른쪽에있는경우다. 오른쪽에있는아이콘에서메소드의왼쪽에있는기호는다음과같은의미를나타낸다. [+] : public [#] : protected [-] : private [~] : package
Abstract Class java의 abstract class는아래와같이나타낼수있다. Concrete class 이름이기울임꼴글꼴로표시되어있다. 추상화메소드도기움임꼴글꼴로표시되어있다.
Interface java에는 interface라는기능이있다. interface는메소드만을정의한클래스로객체의동작과실제구현을분리하여정의하는데사용된다.
Interface (Cont.) java interface는 UML의 interface로모델화된다. UML의 interface는기본적으로 interface의스테레오형식의클래스이다. 스테레오형식이란기존의모델엔트리로부터새로운모델엔트리를정의하기위한구조이다. 스테레오형식은그형식이름을 << 와 >> 로감싸표시한다. 인터페이스는 concrete 클래스나 abstract 클래스와동일한아이콘을사용하여표현할수있지만, 간략화한표현도준비되어있다. 간략화한표현은위의그림과같이원으로표현한다.
Exception java 에서에러처리의기술에는예외가사용된 다. java 예외는 UML 에서는 exception 이라 는스테레오타입에의해표현된다.
Relation UML 에서는객체와객체간에관계는 relation으로표현한다. 클래스다이어그램에서사용하는 relation은크게 4 종류가있다. Association Generalization Realization Dependency
객체간의관계에따른 UML 표기 Relation UML Is a has - a etc Generalization Realization Association Association Dependency Realization Aggregation Composition
Inheritance inheritance 를구현하는자바의기능은 3 개로나누어진다. extends에의한클래스상속 extends에의한인터페이스상속 implements에의한인스턴스구현
Generalization generalization 의객체지향의일반적인용어는 inheritance 이다. Java 에서는 generalization 으로 extends 키워드를사용한다.
Generalization 인터페이스를클래스로구현하는것을 UML에서는 realization으로모델화한다. 객체지향의일반적인용어에서는 inheritance, java implements라는키워드를사용한다.
Relation 중에서가장빈번하게보이게되는것이 Association이다. Association은객체와객체간에구조적, 정적인관계가있는것을나타낸다. Association은다음의 3개의종류로나눌수있다. Aggregation Composition 기타 Association 보다정확한표현을하려면 Association 중에객체의구성을나타내는연관관계가 Aggregation이고 Aggregation중에서구성되는개체와구성하는객체의관계가아주강한것이 Composition이다.
Aggregation Aggregation 은객체구성을표현하기위한 Association이다. Aggregation 구현의기본은객체변수이다. BankAccountRepository가여러개의 BankAccount를관리할수있게배열을사용하고있다.
Aggregation ( Collection ) 객체지향의강력함의하나는객체의집합의처리를할수있다는점이다. 이런집합처리를위해 java 에준비되어있는기능은 Java2 에서제공되 는 JCF (Java Collection Framework) 라는컨테이너클래스이다.
Aggregation ( Set ) Set은집합을나타내는컬렉션이다. 수학적인집합은동일한요소를중복하여갖지않기때문에, 이것과같은것을이 Set라는컬렉션으로구현할수있다. Set은형을나타내는인터페이스이기때문에, 실체를갖는클래스로 java.util.hashset 를사용한다.
Aggregation ( Map-ordered ) 맵은사전검색기능을갖는컬렉션이다. 컬렉션에보관되어있는객체가 분류되어있는지를보증하는기능동시에제공하려는경우가있다. 이러 한컨테이너를표현하도록자바에서는 SortedMap 이준비되어있다. 이와같이 java.util.collection 사용하는경우에는단순한 Aggregation 으로모델화된다.
Composition Aggregation의하나의종류로써기존의 Aggregation보다더강력한결합을나타낸다. 학교와학생이나회사와종업원의관계를구현하는각객체간의관계는시간이흐르면당연히변경될수있다. 학교에입학하거나회사입사로인원은증가되고, 인원은증가되고, 학교졸업이나퇴학, 퇴사로인원은줄어든다. 이에반해 2개의결합을고정하여객체의설정이보존되게하는관계가있다. 자동차와엔진이나사람과심장의관계에서자동차에서엔진을제거하면자동차가아닌고철에불과하고사람으로부터심장을제거하면그사람은죽게된다. 이런강한관계를 Composition이라고한다.
Dependency Dependency 는클래스다이어그램에서사용하는경우에 Use 의관계를나타낸다. Use의관계는 Association과같은정적인구조관계가아니라동적인일시적인관계이다. 메소드의인수로전달되는객체와메소드를갖고있는개체의관계가이 Use의관계이고, Dependency로표현된다.
Dependency 이 Controller 클래스를중심으로하는클래스다이어그램은 Dependency 형으로표현된다. BankController로부터 BankAccountRepository로의관계는객체변수로구현된정적구조적인관계인 Association으로표현되지만, 문제는 BankController로부터 ankaccount에의관계이다. 이관계는 deposit 메소드나 withdraw 메소드중에서동적으로나타나사라지는관계이다.
Dependency 결국 BankController 가 BankAccount 를일시적으로사용하는관계지만, 이 관계를표현하려면 Use 의의미를갖는 Dependency 를이용한다.
Package java에서패키지라는기능을사용하여여러개의클래스를그룹화하여관리할수있다. UML에서도동일한기능으로서패키지가준비되어있다. UML에서의패키지는자바의패키지보다넓은의미를갖지만, 클래스다이어그램에서사용하는경우에는자바의의패키지는 UML에서도패키지로표현된다. 그림은 Composition으로 BankSystem을패키지로분해하여본것이다.
UML Tools UML Tools StarUML
UML Tools
UML Tools - StarUML Name : StarUML Creator : Plastic Software Platform / OS : Windows First public release : 05. 11. 01. Latest stable release : 06. 08. 07 Open Source, UML 2, MDA, Templates : Yes Language generated : Java, C#, C++ Reverse engineered languages : Java Profile,C++ Profile, C# Profile Code Generator and Reverse Engineer
UML Tools - StarUML (Cont.) StarUML은빠르고, 유연하고, 확장가능하며, 풍부한기능에 Win32 플랫폼에서 UML 1/MDA 플랫폼 ( 툴 ) 을개발하기위한오픈소스프로젝트입니다. StarUML 프로젝트의목적은 IBM Rational Rose, Together와같은상업적도구를비싼돈을들여사용하지않더라도그에준하는기능을갖춘오픈소스소프트웨어모델링도구및플랫폼을개발하는것입니다. StarUML은국내소프트웨어업체인플라스틱소프트웨어에서개발된 Plastic에서유래되었습니다. 즉 StarUML은다른 tool들과달리그매뉴얼을비롯하여구성이모두한글로이루어져있어그활용도에있어서이번프로젝트에매우적합하다고생각됩니다.
Reference Wikipedia (http://en.wikipedia.org/wiki/list_of_uml_tools) The UML User Guide ( Grady Booch, James Rumbaugh, Ivar Jacobson ) [ Addision Wesley ] UML Distilled A Brief Guide To The Standard Object Modeling Language( Chapter 4. Sequence Diagram ) UML 모델링의본질 ( 아옥공신 / 성안당 / 2005) Java 객체지향언어로배우는디자인패턴 ( 신재호 / 정보문화사 ) 자바개발자를위한 UML contact J ( 송호중 / 대림 / 2001)