Index Chapter Page 1. What about OOAD 1) Definition & History 3 2) Terms 4 3) Modeling 8 4) OOA & OOD 11 5) Summary of OOAD What about UM

Transcription

1 - 1 - Software Engineering Team9 Introduction to OOAD using UML tools 박기남 조서경 조성완 조아라

2 Index Chapter Page 1. What about OOAD 1) Definition & History 3 2) Terms 4 3) Modeling 8 4) OOA & OOD 11 5) Summary of OOAD What about UML 1) Definition & History 20 2) Characteristic and Composition of UML 21 3) Summary of UML 45

3 What about OOAD 1) Definition & History ➀.,.,. ➁ ,, ,

4 - 4-2) Terms ➀ (Object) & (Class) : : 사람 ( 사람 ) 김철수 24 이름나이 공부한다식사한다 < > < > ➁ 일대일 1 대 0 (0 or 1) ' 선택 ' 1 대다 (0 or more) 1+ n 대다 ( 필수 ) 1 대정확히 n 1 대 (5 에서 10) < >

5 - 5 - ➂ (Inheritance).,. ( ) ( )... < > 동물모양무게숨쉬기 포유류자식수최적온도젖먹임 바다동물수영속도최적수온헤엄침 고양이고래상어 < >

6 - 6 - ➃ (Generalization),. 'is_a' 'kind_of' 1).. 동물모양무게숨쉬기 포유류자식수최적온도젖먹음 바다동물수영속도최적수온헤엄침 < > ➄ (Abstraction) - (process abstraction). - (data abstraction) integer, real, date,. 1) 클래스에서생성되는각객체를지칭

7 - 7 - ➅ (Aggregation) " - " " ". (has-a ).. 워크스테이션 Monitor 몸체키보드마우스 CPU 주기억장치 < > ➆ (Reusing),. Component.

8 - 8-3) Modeling ➀ (Model).. ➁ (Modeling)...,..,. ➂ ➃ - - -,, -

9 ,,. -OMT (STD) Ex) ATM System Development < > 현금카드입력요청현금카드입력비밀번호입력요청비밀번호입력 서비스입력요청 서비스선택 ( 인출 ) 금액입력요청 금액입력 카드와영수증출력 카드와영수증가져감 현금출력 현금가져감 현금카드입력요청 비밀번호조회요청비밀번호조회성공서비스처리요청 ( 인출 ) 서비스처리요청성공 비밀번호조회비밀번호수락 서비스처리 ( 인출 ) 서비스처리성공 현금카드 사용자자동지급기은행계좌 < >

10 , - (how to). - (DFD),. - (DFD). 거래종류 + 금액 + 잔액 잔액가져옴 잔액 잔액재계산 새잔액 account 새잔액 잔액갱신 잔액갱신성공 < > ➄,,,. <OMT >

11 - 11-4) OOA(Object-Oriented Analysis) & OOD(Object-Oriented Design) < > ➀ (Object-Oriented Analysis). ➁ Use Case,.. <Use Case Analysis>

12 Use Case Behavior -Use Case *. * (Self Contained). - * (Functional Requirement) :. * (Non Functional Requirement) : Functionality( ) : Usability( ) : UI Reliability( ) : MTBF Performace( ) : Supportability( ) :

13 Use Case Behavior Use Case Process Entity Class Boundary Class Control Class <boundary, entity, control class > -Boundary Class * UI(User Interface). UI UI *.

14 Entity Class * ( ) *. -Control Class * Boundary Class Entity Class Boundary Class Transaction * Boundary Class Entity Class.

15 <Use Case Analysis > < Use Case Analysis>

16 ➂ - -,, - UML class diagram, sequence diagram, collaboration diagram, state chart diagram, activity diagram, component diagram, deployment diagram.. < Process> (Architectural Design) - Packing Visible 2) Attributes (Mechanistic Design) - Packing Leveling -. 2) 속성 (=Property)

17 (Detailed Design) -, (, Private ) - 5) Summary of OOAD ➀ " ".. SW. -, - Architecture SW - SW, SW. SW,,, SW, Middleware, OS,...,.,..,. SW..

18 ➁ 객체지향은성숙된다른방식에비해아직활성화된지오래되지않았기때문에전문적인객체지향사고와기법을갖춘전문가가부족하다. 많은회사와 SW 개발관련자들이아직객체지향기술과먼거리를유지하고있는실정이고, 특히객체지향분석설계및개발능력을갖추고있으면서 Architecture 에대한전문적지식을가진전문가는드물다. 객체지향의초심자가처음객체지향기술을도입하여 SW 시스템개발을진행하려고할때도움을받을수있는전문가가아직은부족하다.. SW..,..

19 ➂. 3,. ( ),..,.,,,,.,.

20 What about UML 1) Definition & History ➀ UML(Unified Modeling Language) Booch, Rumbaugh OMT(Object Modeling Technique), Jacobson OOSE. UML.,.. UML Class Diagram, Object Diagram, Use Case Diagram Diagram. UML Paradigm Plus, ROSE, SELECT. ➁ SIMULA - ( 50 ) - Booch Booch Rumbaugh OMT - OOPSLA('95) - Jacobson OOSE UML(Unified Modeling Language) v0.9-1 : UML ver : UML ver. 1.1 OMG - 11 : OMG - UML ver UML ver UML ver. 2.0

21 - 21-2) Characteristic and Composition of UML 1 UML 의특징 가시화언어 - 개념모델 - 오류없이전달 - 의사소통의용이 - graphic 언어구축언어 - 다양한프로그램, 언어와연결 - 왕복공학가능 ( 순공학 / 역공학 ) - 실행시스템예측기능 명세화언어 - 정확한모델제시 - 완전한모델작성 - 분석, 설계의결정 - 표현문서화언어 - 시스템에대한통제, 평가, 의사소통의문서 ( 요구사항, 아키텍쳐, 설계, 소스코드, 프로젝트계획, 테스트, 프로토타입, 릴리즈 ) 가시화언어 (Language for Visualizing) UML은여러개의그래픽기호로구성되어있으며각기호들은정확한의미를가지고있다. 그러므로 UML로모델링한것은통일된의미를갖기때문에 UML로작성된문서를보는사람들은시스템에대해동일한의미를공유할수있다. 명세화언어 (Language for Specifying) 명세화란정확하고, 명백하며, 완전한모델을의미하는데, UML에서는분석, 설계, 구현에서의모든중요한결정에대한명세서를다루는것이가능하다. 구축언어 (Language for Constructing) UML 언어에서는프로그래밍코드를생성하는것이가능하고, 또한구현된코드로부터 UML 모델을다시생성할수있는역공학 (reverse engineering) 도가능하다. 문서화언어 (Language for Documenting) UML은시스템구조와그것의모든상세내역에대한문서화를다루며, 요구사항을표현하고시스템을시험하는언어와프로젝트계획과배포관리액티비티 3) 를모델링하는기능을제공한다. 3) 일련의활동

22 구성요소 <UML 을구성하는요소들 > 사물 (Things) 추상적인개념으로, 모델에서는주제를나타내는요소이다. 언어로서의 UML을생각해볼때단어에해당하며, 단어중에서도명사혹은동사의의미를가지는요소라고볼수있다. UML 을그림으로생각해볼때 Things 는도형의형식을가지는데 Things 의유형과종류가정해져있어서마음대로도형을추가할수 없으며이 Things 는사전에부여된명확한의미를가진다.

23 관계 (Relationships) Things의의미를확장하고더욱명확히하는요소이다. 즉 Relationships는 Things와 Things를연결하여그들간의관계를표현하는요소이다. 언어로서의 UML을생각해볼때 Relationships는단어에해당하며, 단어중에서도형용사나부사에해당한다. UML 을그림으로생각해볼때 Relationships 는선의형식을가진다. 마찬가지로 UML 에서는정해진선만을사용해서 Relationships 를 표현해야하고이선들은사전에부여된명확한의미를가진다. 도해 (Diagrams) Things과 Relationships을모아그림으로표현한것이다. Diagrams 에는 Things와 Relationships가어우러진한장의그림으로보는데 UML에서는그그림의형식을 9가지로정의하고, 각그림에대해용도와목적을정의하고있다. 보통 UML이라는용어는 9개의 Diagrams와동일한의미로쓰일때가많다. 언어로서의 UML을생각해볼때 Diagrams는주제를담은문장들로이루어진글월에해당하고이글월은문장 (Things와 Relationships 몇개가합쳐진형태 ) 과단어 (Things, Relationships) 들로구성된다. Diagram 한장은바로하나의모델을의미한다. 따라서 UML 은 9 가지종류의모델체계를제시하고있다고할수있다.

24 용어 사물 (Things) 의종류 용어클래스 (Class) 인터페이스 (Interface) 컬레보레이션 (Collaboration) Use Case (Use Case) 액티브클래스 (Active Class) 컴포넌트 (Component) 노드 (Node) 설명의미를공유하는객체의집합, 객체의타입 class나 component의기능중외부로가시화하는부분을정의구현관점에서어떤목적을달성하기위한일련의행위를정의시스템이제공하는서비스혹은기능클래스에서파생된객체가하나또는그이상의프로세스나스레드 4) 를갖는클래스를기술시스템에서물리적으로관리되는한묶음의소프트웨어를표현연산능력이있는물리적요소를표현. 컴퓨터나네트워크기기등을의미 관계 (Relationships) 의종류 용어의존 (Dependency) 일반화 (Generalization) 연관 (Association) 실체화 (Realization) 설명한쪽사물의변화가다른사물에영향을주는관계주로일시적으로의존함을의미객체의특성중상속을표현하는관계사물들간의일반적인참조관계구조적관계이며, 지속적으로참조함을의미정의하는사물과이를구현하는사물간에표현하는관계 4) 둘이상의프로세스가동시에진행

25 도해 (Diagrams) 의종류 용어 UseCase Diagram Class Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram Component Diagram Deployment Diagram Object Diagram 설명 - 시스템이제공하는서비스와외부환경과의관계를표현 - 시간개념과순서개념이없으므로정적인관점에서의모델 - 사용자관점에서시스템의기능을정의하고외부환경정의목적 - 클래스와클래스간의관계를나타내며 UML의모델가운데가장보편적 - 직접적으로프로그래밍과관련 - 시스템의정적인관점 - 외부의특정한처리요청을해결하기위해필요한객체들과그객체들이참여한시간적, 순서적처리흐름을표현 - 시스템의동적인관점을나타내며, 시스템의동적모델중하나 - Sequence Diagram과목적과용도가같음 - Sequence Diagram이시간순서를중시한모델인반면객체와메시지를구조적으로표현하는데유리한표현체계 - 두다이어그램은표현형태만다를뿐이어서서로의미의손실없이변환이가능 - 시스템의동적인관점을나타내며, 시스템의동적모델중하나 - 하나의객체가생성되어소멸될때까지가질수있는가능한모든상태 (state) 를분석하고, 표현 - 시스템에서복잡한역할을수행하는핵심객체에대해자세한변화를추적하여완전성을기하기위해작성 - 시스템의동적인관점을나타내며, 시스템의동적모델중하나 - 처리흐름을모델링하는범용적인다이어그램 - 대상은클래스의처리흐름일수도있고, 비즈니스측면의워크플로우일수도있으며, 기타다른다양한분야가대상이될수있음 - 논리흐름과처리순서, 프로세스플로우등에대해판단, 처리, 액티비티를사용하여분석 - 클래스로구성된물리적인배치단위인컴포넌트와컴포넌트간의구성과의존관계를나타냄 - 컴포넌트는컴퓨터장치에독립적으로배치할수있는단위 - 시스템의정적인구현관점을표현 - 시스템이실행되는환경인노드와그노드에배치된컴포넌트의구성 - 컴포넌트다이어그램과관련이있는데, 이는일반적으로하나의노드는 Component Diagram에정의된컴포넌트를수용하기때문 - 특정시점에서의객체들의상태와그들간의관계를표현 - Class Diagram에있는요소들의인스턴스에대한정적인스냅샷표현

26 Use Case Diagrams * Use Case Diagram 은다른 Diagram 보다먼저작성되어야한다. Use Case Diagram을최우선으로작성해야하는이유 - Use Case 다이어그램은대개의경우다른다이어그램들보다먼저작성됨 - Use Case 다이어그램은다른다이어그램을작성할때의기준이됨 - 다른다이어그램들은 Use Case 다이어그램에서정의한내용을보다상세하고구체적으로추가정의하는형태로작성될때가많음 * Use Case Diagram 은다음의목적으로작성된다. Use Case Diagram 작성이유 - SW 시스템의업무범위를정의 - SW 시스템을사용하게되는사용자를정의 - SW 시스템의업무기능을정의 - 사용자요구사항을정의 - 사용자와개발팀간의의사소통의도구로서의기능 - 이후수행할분석, 설계작업의기준 - 테스트의기준 * Use Case Diagram 의구성요소

27 용어 설명 - 왼쪽과같은사람모양의그림으로표기 ( 스틱맨 ) - 스틱맨아래에액터의이름을명사로표시단조직, 개인의이름이아닌역할 (Role) 을작성 - SW 사용자, SW System, 하드웨어 - 왼쪽과같은타원모양의그림으로표기 - Use Case 아래에는 Use Case 명을짧은문장혹은행위를나타내는명사형으로표시 - 경우에따라 Use Case 명을타원안에표기 * Use Case Diagram 의표기법 관계 extend include generalization communicates 모델 - Use Case와 Use Case 사이에정의되는관계 - 한 Use Case가다른 Use Case의서비스수행을요청하는관계 - 수행을의뢰하는 Use Case는조건에따라수행을의뢰할수도있고의뢰하지않을수도있음 - Use Case와 Use Case 사이에정의되는관계 - 한 Use Case 가다른 Use Case 의서비스수행을요청하는관계 - 이경우수행요청을의뢰받은서비스는반드시수행 - 액터와액터, Use Case 와 Use Case 사이에정의되는관계 - 두개체가일반화관계에있음을의미 - 상속 (inheritance) 의특성을가짐 - 액터와 Use Case 사이에정의되는관계 - 두개체가일반상호작용관계에있다는것을의미

28 * Use Case Diagram 의작성단계 활동액터식별 Use Case 식별관계정의 Use Case 구조화 (factoring) 설명 - 시스템의모든사용자의역할을식별 - 시스템과상호작용하는타시스템식별 - 시스템과정보를주고받는하드웨어나지능형장치식별 - 액터가요구하는서비스를식별합니다. - 액터가요구하는정보를식별합니다. -액터가시스템과상호작용하는행위를식별합니다. -액터와액터간의관계를분석하고정의 (generalization 관계 ) -액터와 Use Case간의관계를분석하고정의 (communicates) - Use Case와 Use Case 간의관계를분석하고정의 (include, extend, generalization) - 두개이상의 Use Case에존재하는공통서비스추출 - 추출된서비스를 Use Case로정의 - 공통서비스를사용하는 Use Case와신규 Use Case의관계를정의 (include) - 조건에따른서비스수행부분을분석하여추출 - 추출된서비스를독립 Use Case로정의 - 추출된서비스를사용하는 Use Case와관계를정의 (extend) * Use Case Diagram 의예

29 Class Diagrams * Class Diagram 은다음의목적으로작성된다. Class Diagram 작성이유 - 객체지향 SW 시스템의기본단위인클래스를식별하고그관계를정의하는유용한방식을제공 - 클래스간의정적인협력관계를정의함으로써시스템을이해하는데용이 - 클래스의오퍼레이션과속성을상세히정의함으로써 SW 시스템을설계 - 논리적인관점으로부터물리적인관점까지시종일관된형식으로 SW 시스템을분석, 설계하는방식을제공합니다. * Class Diagram 은 System Development 의분석, 설계단계에서 여러번작성된다. < 일반적인 Class Diagram 의작성시기 > * Class Diagram 의구성요소

30 * Class 의표기방법 분류 설명 일반적인표기 Icon 표기 cf) OOAD Analysis 페이지참조

31 * Class Diagram 의표기법 -1 Association - 두클래스간일반적인협력관계가있을경우정의 - 두클래스가서로 Association관계가있다면한쪽객체에서다른객체를참조가능 - 향후다른클래스에대한포인터나레퍼런스로구현표기법 화살표없는실선 ( 양방향관계 ) - 의미적인관련성만을표현 한쪽화살표를가진실선 ( 단방향 -Navigation 관계 ) - 참조의방향 상세한표현 - 역할명 > 관계명 > 관계수의순서로보편적생략

32 Aggregation - Association관계의일종 - 두클래스간에 " 전체-부분 (whole-part)" 의관계가있을경우정의 - 클래스각각이독립적인생명주기를가지는데즉전체에해당되는클래스가소멸되더라도부분에해당되는클래스는소멸하지않고계속존재할수있음표기법 속이빈 마름모가붙은 실선 - 마름모가붙은쪽이 " 전체 " 클래스, 반대쪽은 " 부분 " 클래스 Composition - Association 관계의일종 - Aggregation 관계와유사하게두클래스간에 " 부분-전체 " (part-of) 의관계가있을경우정의 - 부분의생명주기가전체의생명주기에종속적인관계인데즉전체가생성될때부분도생성되고, 전체가소멸될때부분도함께소멸표기법 속이찬마름모가 붙은실선 - Aggregation 관계와 " 전체 - 부분 " 의의미는동일

33 * Class Diagram 의표기법 -2 Generalization - 두클래스는일반화 - 특수화관계가있을때정의하는데즉보다보편적인것과 보다구체적인것사이의관계 (is-a 관계 ) - 상속 (inheritance) 의특성 표기법 삼각형화살표가붙은 실선 - 결재클래스의속성과오퍼레이션은공통적이고일반적인 것으로정의되고, 하위의 3 개의클래스는자신만의특수한 속성과오퍼레이션을정의함

34 Dependency - 한쪽클래스가실행도중다른쪽클래스의실행을요청하는경우에정의 - 클래스간의사용관계를표현 - Association 관계에비해훨씬종속적 (Association은존재하는단순히다른객체를참조하고실행을의뢰하지만, Dependency 관계는다른객체를생성하고소멸시키는등보다종속적인관계에대해정의 ) 표기법 화살표붙은점선 - 위의예는 TransactionManager 클래스의오퍼레이션에서 Course 클래스가 5) Parameter 로사용됨 *Class Diagram 의표기법 -3 유형 Many (* 또는 n ) 설명 - 클래스 B의인스턴스하나에 A 인스턴스여러개와관계 - 클래스 B 의인스턴스하나에 A 인스턴스다섯개와관계 Exactly five(5) Zero or more (0..n) - 클래스 B 의인스턴스하나에관계된 A 인스턴스가 없거나여러개 5) Method 의매개변수 (Argument)

35 One to Ten (1..10) - 클래스 B 의인스턴스하나에관계된 A 인스턴스가 1 개보다많고 10 개보다적음 Exactly two, three or five (2,3,5) - 클래스 B 의인스턴스하나에관계된 A 인스턴스가 2 개혹은 3 개혹은 5 개임 * Class Diagram 의작성단계 활동객체식별클래스를정의속성 & 오퍼레이션정의클래스간관계정의정제과정을반복 설명 - 사용자문서나 Use Case 정의서, 문제기술서등을참고하여객체를식별 - 식별된객체를바탕으로클래스를정의 - 이단계에서는클래스명정도만표현 - 클래스의속성과오퍼레이션을정의 - 한번에상세한정의를마치지못하므로여러번 정제과정을거쳐야함 - 클래스와클래스간관계를정의 - 관계의종류를결정하고, 관계명을부여 - 관계수를정의 - Class Diagram 은분석과설계과정에서지속적으로 정제되어야함 - 다른모델을작성하는과정에새로운클래스가 추가되기도하고, 관계가변경되기도함 - 이러한변화와상세화과정을 Class Diagram 에반영

36 * Class Diagram 의예

37 Sequence Diagram * Sequence Diagram 은다음의목적으로작성된다. Sequence Diagram 작성이유 - 객체간의동적상호작용을시간적개념을중시하여모델링 - 객체의오퍼레이션과속성을상세히정의합니다. - Use Case를실현 (Realization) - 프로그래밍사양을정의 * Sequence Diagram 의구성요소 분류 Things - 액터 (Actor), 객체 (Object) 성분 Relationships - 메시지 (Massage) 기타 - Life Line, Focus of control

38 * Sequence Diagram 의표기법 -1 메세지 표기법 Flat flow of control - 객체에메시지를연결할때사용 Nested flow of control - 메시지의결과가돌려지게될때까지다음처리를 진행하지않는 Synchronous 메시지 Asynchronous flow of control - 객체가보낸메시지의결과를기다리지않고다음 처리를진행 Return flow - 메시지를처리한결과 (return)

39 * Sequence Diagram 의표기법 -2 Life Line - 객체의생존기간을의미 표기법 수직방향의 점선 - 점선에 X 표시가덧붙여질경우, 이시점이객체의소멸시점 Activation - 객체가활성화되어있는기간을의미 - 객체가외부의메시지를받고, 다른객체에보낸메시지에대한 return flow를기다리는기간표기법 Life line 위에 좁고세로로긴 사각형 - 처리가끝나고대기하는시간은일반적인 life line 표기

40 * Sequence Diagram 의작성단계 활동작성대상을선정 Use Case의액터을파악하여 Sequence Diagram에위치 설명 - Use Case 다이어그램을이용하여시퀀스다이어그램의작성대상을선정한후, 하나의 Use Case를선택하고, Use Case 정의서를분석 - 액터가둘이상일경우라도모두좌측부터액터를위치시켜야합니다. 순서는중요하지않지만메시지선이적게교차하도록배치 Use Case를실현하기위해참여할클래스 ( 객체 ) 들을정해 Sequence Diagram에위치시간순서를감안하여객체간메시지를정의필요한객체를추가로정의 - 정의된클래스중에 Use Case의처리에참여하는것들을식별하고 Sequence Diagram 에위치시켜야하지만순서는중요하지않음 - Use Case를실현하기위해필요한객체들간의메시지를정의하되, 시간순서에유의 ( 시간흐름은위에서아래로 ) - 요구된처리를위해필요하지만아직정의되지않은객체를새로정의하여시퀀스다이어그램에추가해나가며또이렇게추가된객체사이의메시지도정의하여추가 * Sequence Diagram 의예

41 Collaboration Diagrams * 객체들사이의행위를나타내는것은 sequence diagram과동일하다. 둘의차이점은 sequence diagram이시간에따른행위의흐름에역점을두고표현하지만 collaboration diagram의경우객체들사이의정적인구조에더역점을두고있다. -Active Diagrams * 동적측면의 Diagram 으로시스템에서발생하는활동을강조한다. ( 순서도의일종 ) - Data의활동, 흐름, 또는과정사이사이의의사결정을표현 - 하나의사례에서일어나는활동들을분할하여표현하기위해사용 - 시스템의기능을모형화 - 객체간의제어흐름을표현 - 순서나병렬적인처리를필요로하는행동들을표현 * Active Diagram 의예 -> For( A; B; C; ) { D; } < Activity Diagram 으로표현한 For 문 ( 반복문 ) >

42 State Chart Diagrams * 시스템의동적측면의 Modeling 이다. - 어떤객체가갖는상태에초점을맞춤 - 순차적으로발생하는 ' 행동 ' 에중점을둠 - State Diagram에서객체의초기상태를나타내는 Starting-State는오직한개만존재 - 단, Ending-State는여러개로존재가능 * State Chard Diagram 의예

43 Component Diagrams * Component 에초점을두고행하는 Diagram 이다. - 실행 Node 에서실행가능한 Component 를명세 - Interface 자체적으로실행이가능한 Component 의집합을표현 - 물리적인구성단위로이루어진 Component 간의구성, 관계를표현 - 시스템의 Logical-Model 을개발자의관점에서바라본 Physical-Model 로재배치할때사용 - Class 를어떤 File 에넣어서모듈을만들어낼것인지를정의 -Deployment Diagrams * Node 들의집합과그들사이의연관관계를보여주는 Diagram 이다. * 아키텍처의정적 - 관점 (Static-View) 을표현한다. * Deployment Diagram 의예

44 Object Diagram의예 * 특정객체들이 Class Model 안에서사용되어지는방법을나타내기위해 Class Diagram에추가적으로객체들사이의관계를표현하여나타낸 Diagram이다. * 객체들의상호작용을정의한다.

45 - 45-3) Summary of UML 1 장점 장점 설명 모델에관한 공통언어 - 동일한용어로이야기하기때문에그만큼커뮤니케이션비용 ( 정보교환에드는비용 ) 을줄일수있음 - 비용을줄인다는것은프로젝트전체의품질향상과직결 전세계의표준 - 객체지향이널리퍼짐에따라사실상 UML 이전세계표준으로사용 - 그러므로전세계에존재하는정보나노하우습득용이 2 단점 단점 설명 부적절한 도입 - 개발작업에아무런영향을주지않는모델, 만든후에도참조되지않는모델링가능성존재 - 그러므로작업시간만소비 모델링이 어려움 - 모델러 ( 모델을만드는사람 ) 의모델화능력에서비롯되는문제 - 모델은작성목적을달성할수있을만큼의품질이요구되므로 숙달된모델러에게만유용할수있음

46 요약 기존에사용되던안정되고검증된표기체계들을이어받고통합한 (Unified) 언어 (Language) 이다. UML사용시다음사항을필히체크해야한다. 목적 ( 독자 ) 을확인하고있는가 명명시추상도, 정확성, 표현의통일은확인했는가 규모는일정한가 기능분할로되어있지는않는가 <<include>>, <<extend>>, 일반화관계의사용법이잘못되어있지는않은가 UML 은언어이므로단어와문법이있다. 적절한 Diagram 을선택하여작성하여야한다. 모델링은최대한실제와가깝게해야한다.