UML 언어의 일반적인 특성. UML 다이어그램의 유형 uml 다이어그램의 유형

주석: 이 과정의 주제는 UML - 통합 모델링 언어입니다. 이전 강의에서 우리는 UML이 무엇인지, 그 역사, 목적, 언어 사용 방식, 정의의 구조, 용어 및 표기법에 대해 이야기했습니다. UML 모델은 다이어그램의 집합입니다. 이 강의에서는 다음과 같은 질문을 고려할 것입니다. 여러 유형의 다이어그램이 필요한 이유는 무엇입니까? 다이어그램 유형; OOP 및 시퀀스 다이어그램 작성

이 강의의 주요 내용에 대한 논의로 넘어가기 전에 왜 다이어그램을 만드는지에 대해 이야기해 보겠습니다. 모든 시스템(소프트웨어뿐만 아니라)의 모델 개발은 항상 생성 또는 업데이트보다 선행됩니다. 이것은 적어도 해결되고 있는 문제를 보다 명확하게 상상하기 위해 필요합니다. 사려 깊은 모델은 개발 팀 내 상호 작용과 고객과의 상호 이해 모두에 매우 중요합니다. 결국 코드로 구현되기 전에 프로젝트가 "구조적으로 일관성"이 있는지 확인할 수 있습니다.

우리는 "한눈에 살펴보기"와 같이 완전히 설명할 수 없기 때문에 복잡한 시스템의 모델을 만듭니다. 따라서 우리는 특정 작업에 필수적인 시스템의 속성만 골라내고 이러한 속성을 반영하는 모델을 구축합니다. 객체 지향 분석 방법은 실제 복잡한 시스템을 가장 적절하게 기술하는 것을 가능하게 합니다. 그러나 시스템이 복잡해짐에 따라 우수한 시뮬레이션 기술이 필요합니다. 이전 강의에서 말했듯이 통합 시스템은 이러한 "표준" 기술로 사용됩니다. 모델링 언어(Unified Modeling Language, UML)은 시스템의 사양, 시각화, 설계 및 문서화를 위한 그래픽 언어입니다. UML을 사용하면 개념뿐만 아니라 특정 구현 기능을 반영하여 생성 중인 시스템의 세부 모델을 개발할 수 있습니다. UML 모델의 프레임워크 내에서 시스템에 대한 모든 표현은 다이어그램이라는 특수 그래픽 구성의 형태로 고정됩니다.

메모. 우리는 모든 유형을 고려하지 않고 일부 유형의 차트만 고려할 것입니다. 예를 들어 구성 요소 다이어그램은 이 강의에서 다루지 않으며 다이어그램 유형에 대한 간략한 개요일 뿐입니다. 특정 애플리케이션 모델에 대한 차트 유형의 수는 어떤 식으로든 제한되지 않습니다. 간단한 애플리케이션의 경우 예외 없이 모든 유형의 다이어그램을 작성할 필요가 없습니다. 그 중 일부는 단순히 누락되었을 수 있으며 이 사실은 오류로 간주되지 않습니다. 특정 유형의 다이어그램의 가용성은 특정 프로젝트의 특성에 따라 다르다는 것을 이해하는 것이 중요합니다. 다른 유형의 다이어그램(여기서 논의되지 않음)에 대한 정보는 UML 표준에서 찾을 수 있습니다.

여러 유형의 차트가 필요한 이유

먼저 용어를 정의하겠습니다. 이 강의의 서문에서 우리는 시스템, 모델, 다이어그램의 개념을 반복적으로 사용했습니다. 저자는 우리 각자가 이러한 개념의 의미를 직관적으로 이해하고 있다고 확신하지만 완전히 명확하게하기 위해 용어집을 다시보고 다음을 읽어 보겠습니다.

체계- 기능이라는 공통의 목표에 의해 통합된 상호 연결된 제어 하위 시스템의 집합입니다.

예, 그다지 유익하지 않습니다. 그렇다면 서브시스템이란 무엇인가? 상황을 명확히 하기 위해 고전을 살펴보겠습니다.

체계특정 목표를 달성하기 위해 구성되고 여러 가지 관점에서 모델 세트를 사용하여 설명된 서브시스템 세트를 호출합니다.

당신이 할 수 있는 일은 아무것도 없습니다. 하위 시스템의 정의를 찾아야 합니다. 거기에서도 말한다. 하위 시스템요소의 집합이며, 그 중 일부는 다른 요소의 동작을 지정합니다. Ian Sommerville은 이 개념을 다음과 같이 설명합니다.

서브시스템기능이 다른 하위 시스템의 서비스에 의존하지 않는 시스템입니다. 소프트웨어 시스템은 비교적 독립적인 하위 시스템 세트로 구성됩니다. 하위 시스템 간의 상호 작용도 정의됩니다.

또한 매우 명확하지는 않지만 더 좋습니다. "인간" 언어로 말하면 시스템은 비교적 자급자족할 수 있는 단순한 개체 집합으로 표시됩니다. 이것은 프로그램을 개발하는 과정에서 시각적 구성 요소인 표준 "큐브"에서 그래픽 인터페이스를 구축하는 방법 또는 프로그램 텍스트 자체가 기능에 따라 결합되는 서브루틴을 포함하는 모듈로 분할되는 방법과 비교할 수 있습니다. 기능이며 다음 프로그램에서 재사용할 수 있습니다.

시스템의 개념을 이해합니다. 설계 과정에서 시스템이 고려됩니다. 다른 관점에서모델의 도움으로 다양한 표현이 다이어그램 형태로 나타납니다. 다시 말하지만, 독자는 개념의 의미에 대해 질문할 수 있습니다. 모델그리고 도표. 우리는 아름답다고 생각하지만 명확하지 않은 정의 의미적으로 닫힌 시스템 추상화로서의 모델상황을 명확히 할 가능성이 낮으므로 "우리 자신의 말로" 설명하려고 합니다.

모델- 이것은 이 작업에 대한 시스템의 가장 중요한 특성만 표시하는 특정(중요 여부) 개체입니다. 유형 및 무형, 인공 및 자연, 장식 및 수학적 모델이 다릅니다.

몇 가지 예를 들어보겠습니다. 어린 시절 열정을 가지고 놀았던 우리 모두에게 친숙한 플라스틱 장난감 자동차에 지나지 않습니다. 재료 인공 장식실제 자동차 모델. 물론 그러한 "자동차"에는 엔진이 없으며 탱크에 가솔린을 채우지 않고 기어 박스가 작동하지 않지만 (또한 전혀 없습니다) 모델로서이 장난감은 완전히 충족됩니다. 기능: 4개의 바퀴, 차체, 문, 창문, 운전 능력 등의 특징적인 특징을 표시하기 때문에 어린이에게 자동차에 대한 아이디어를 제공합니다.

의학 연구에서 동물 실험은 종종 인간을 대상으로 한 약물의 임상 실험에 선행합니다. 이 경우 동물은 다음과 같이 행동합니다. 소재 천연인간 모델.

위의 식도 모형이지만 이것은 수학적 모형으로서 중력의 작용에 따른 물질점의 움직임을 기술한 것이다.

다이어그램이 무엇인지 말하는 것만 남아 있습니다. 도표요소 집합의 그래픽 표현입니다. 일반적으로 꼭짓점(엔티티)과 모서리(관계)가 있는 그래프로 표시됩니다. 다이어그램의 예는 많습니다. 이것은 학창 시절 우리 모두에게 친숙한 블록 다이어그램이며 사용자 매뉴얼에서 볼 수있는 다양한 장비의 설치 다이어그램이며 트리 명령을 실행하여 볼 수있는 디스크의 파일 및 디렉토리 트리입니다. Windows 콘솔, 그리고 훨씬 더 많은 것들이 있습니다. 일상 생활에서 도표는 우리를 사방에서 둘러싸고 있습니다. 왜냐하면 그림은 텍스트보다 우리가 더 쉽게 인지할 수 있기 때문입니다...

그러나 소프트웨어 설계로 돌아가십시오(뿐만 아니라). 이후 이 업계에서 다이어그램을 사용하여 다양한 관점에서 시스템을 시각화할 수 있습니다.. 예를 들어, 다이어그램 중 하나는 시스템과 사용자의 상호 작용을 설명할 수 있고, 다른 하나는 작동 중 시스템 상태의 변화, 세 번째는 시스템 요소 간의 상호 작용 등을 설명할 수 있습니다. 시스템은 작고 거의 독립적인 일련의 모델(다이어그램)로 표현될 수 있고 표현되어야 하며, 각각이 시스템 기능의 특정 측면에 초점을 맞추기 때문에 시스템을 설명하고 완전한 그림을 얻는 데 충분하지 않습니다. 시스템과 다른 표현 추상화 수준. 즉, 각 모델은 설계 중인 시스템에 대한 특정 특정 관점에 해당합니다.

이전 단락에서 우리가 모델의 개념에 대해 매우 느슨했다는 사실에도 불구하고, 위의 정의의 맥락에서 이해해야 합니다. 어떤 단일 다이어그램도 모델이 아닙니다.. 다이어그램은 모델을 시각화하는 수단일 뿐이므로 두 가지를 구분해야 합니다. 뿐 일련의 다이어그램은 시스템 모델을 구성합니다.가장 완벽하게 설명하지만 컨텍스트에서 가져온 다이어그램은 하나도 없습니다.

차트 유형

UML 1.5 정의 12가지 유형의 차트세 그룹으로 나뉩니다.

• 네 가지 유형의 다이어그램은 애플리케이션의 정적 구조를 나타냅니다.
• 5는 시스템의 행동 측면을 나타냅니다.
• 세 가지는 시스템 작동의 물리적 측면을 나타냅니다(구현 다이어그램).

UML 2.1의 현재 버전은 너무 많은 변경을 가하지 않았습니다. 다이어그램의 모양이 약간 변경되었으며(프레임 및 기타 시각적 개선 사항이 나타남) 표기법이 약간 개선되었으며 일부 다이어그램은 새 이름을 받았습니다.

그러나 정확한 수치는 표준 다이어그램그것은 우리에게 절대적으로 중요하지 않습니다. 왜냐하면 우리는 그들 모두를 고려하지 않고 일부만 고려할 것입니다. 왜냐하면 특정 애플리케이션의 특정 모델에 대한 다이어그램 유형의 수가 엄격하게 고정되어 있지 않기 때문입니다. 간단한 응용 프로그램의 경우 예외 없이 모든 다이어그램을 작성할 필요가 없습니다. 예를 들어, 로컬 애플리케이션의 경우 배포 다이어그램을 작성할 필요가 없습니다. 다이어그램 목록은 개발 중인 프로젝트의 특성에 따라 달라지며 개발자가 직접 결정한다는 점을 이해하는 것이 중요합니다. 호기심 많은 독자가 여전히 모든 UML 다이어그램에 대해 알고 싶어한다면 UML 표준(http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML)을 참조하도록 하겠습니다. 이 과정의 목적은 UML의 모든 가능성을 절대적으로 설명하는 것이 아니라 이 언어를 소개하고 이 기술에 대한 초기 아이디어를 제공하는 것임을 기억하십시오.

따라서 다음과 같은 유형의 차트를 간략하게 살펴보겠습니다.

• 사용 사례 다이어그램;
• 클래스 다이어그램;
• 개체 다이어그램;
• 시퀀스 다이어그램;
• 상호 작용 다이어그램;
• 상태 다이어그램;
• 활동도;
• 배포 다이어그램.

다음 강의에서 이러한 다이어그램 중 일부에 대해 더 자세히 이야기할 것입니다. 지금은 세부 사항에 중점을 두지 않고 독자가 다이어그램 유형을 시각적으로 구별하여 주요 유형의 목적에 대한 초기 아이디어를 제공하는 것을 목표로 설정합니다. 시작하겠습니다.

사용 사례 다이어그램

모든 (소프트웨어 포함) 시스템은 작업 과정에서 사람들이 사용하거나 다른 시스템과 상호 작용할 것이라는 사실을 고려하여 설계되었습니다. 시스템이 작업 과정에서 상호 작용하는 개체를 배우들, 그리고 각 행위자는 시스템이 엄격하게 정의되고 예측 가능한 방식으로 작동하기를 기대합니다. 엑터에 대해 좀 더 엄격하게 정의해 보겠습니다. 이를 위해 UML에 대한 멋진 시각적 어휘를 사용합니다. 지콤 멘토:

헥토르(배우)- 이것은 선례 또는 엔터티(시스템, 하위 시스템 또는 클래스)와 상호 작용할 때 수행되는 논리적으로 관련된 역할 집합입니다. 행위자는 엔터티 외부의 무언가를 나타내는 사람 또는 다른 시스템, 하위 시스템 또는 클래스일 수 있습니다.

그래픽으로 벡터는 " 작은 사람", 우리가 어린 시절에 그렸던 것과 유사하게 우리 가족을 묘사하거나 해당 스테레오타입이 있는 클래스 기호, 그림에 표시된 대로. 두 가지 형태의 표현은 같은 의미를 가지며 다이어그램에서 사용할 수 있습니다. "고정형" 형식은 시스템 액터를 나타내거나 액터에 표시해야 하는 속성이 있는 경우에 더 자주 사용됩니다(그림 2.1).

주의 깊은 독자는 즉시 다음과 같은 질문을 할 수 있습니다. 왜 헥터는 배우가 아니고?? 우리는 "ektor"라는 단어가 러시아 사람의 귀를 약간 자른다는 데 동의합니다. 우리가 이것을 말하는 이유는 간단합니다 - ector는 단어에서 형성됩니다 동작, 번역에서 의미 동작. "ektor"라는 단어의 직역 - 배우- 너무 길고 사용하기 불편합니다. 그러므로 우리는 계속 그렇게 말할 것입니다.

쌀. 2.1.

주의 깊은 독자는 ector의 정의에서 "선례"라는 단어가 번쩍임을 알 수 있습니다. 그것은 무엇입니까? 우리가 지금 이야기하고 있다는 것을 기억한다면 이 질문은 우리에게 더욱 흥미로울 것입니다. 사용 사례 다이어그램. 그래서,

전례(사용 사례)- 사용자의 관점에서 본 시스템 동작의 특정 측면에 대한 설명(Butch).

정의는 매우 이해하기 쉽고 철저하지만 동일한 것을 사용하여 더 세분화할 수 있습니다. 지콤 멘토"옴:

사용 사례- 행위자가 관찰한 결과로 이어지는 시스템에 의해 수행된 일련의 연속적인 이벤트(변형 포함)에 대한 설명. 사용 사례는 행위자와 시스템 간의 상호 작용을 설명하여 엔터티의 동작을 나타냅니다. 판례는 특정 결과가 "어떻게" 달성되는지가 아니라 "무엇"인지를 보여줍니다.

전례는 이름이 표시된 타원 형태로 매우 간단한 방식으로 표시됩니다. 유스 케이스와 액터는 라인으로 연결됩니다.. 종종 선의 한쪽 끝에는 쌀이 그려져 있습니다. 2.3

설계 중인 시스템의 동작에 대한 일반 요구 사항의 형성;

후속 세부 사항을 위한 시스템의 개념적 모델 개발;

고객 및 시스템 사용자와의 상호 작용을 위한 문서 준비.

UML은 이제 1997년 가을 OMG(Object Managing Group)에서 채택하고 많은 객체 지향 CASE 제품에서 지원하는 소프트웨어 시스템의 시각적 모델링을 위한 표준 표기법입니다.

UML 표준은 모델링을 위해 다음과 같은 다이어그램 세트를 제공합니다.

사용 사례 다이어그램(사용 사례 다이어그램) - 조직 또는 기업의 비즈니스 프로세스를 모델링하고 생성 중인 정보 시스템에 대한 요구 사항을 결정합니다.

클래스 다이어그램(클래스 다이어그램) - 시스템 클래스의 정적 구조와 이들 간의 관계를 모델링하기 위한 것입니다.

시스템 동작 다이어그램(동작 다이어그램);

상호작용 다이어그램;

시퀀스 다이어그램 - 하나의 사용 사례 내에서 개체 간의 메시징 프로세스를 모델링하기 위한 것입니다.

협업 다이어그램(협업 다이어그램) - 동일한 사용 사례 내에서 개체 간의 메시징 프로세스를 모델링하기 위한 것입니다.

statechart 다이어그램 - 한 상태에서 다른 상태로 전환하는 동안 시스템 개체의 동작을 모델링합니다.

활동 다이어그램 - 다양한 사용 사례의 프레임워크 내에서 시스템의 동작을 모델링하거나 활동을 모델링합니다.

구현 다이어그램(구현 다이어그램):

구성 요소 다이어그램(구성 요소 다이어그램) - 정보 시스템의 구성 요소(하위 시스템) 계층 구조를 모델링합니다.

배포 다이어그램(배포 다이어그램) - 설계된 정보 시스템의 물리적 아키텍처를 모델링하기 위한 것입니다.

무화과에. 1.1은 이 과정 프로젝트에서 개발될 주요 다이어그램을 포함하여 정보 시스템의 통합 모델을 제시합니다.

쌀. 1. UML 언어 표기법의 정보 시스템 통합 모델

4.2. 사용 사례 다이어그램

사용 사례는 외부 개체(액터)에 의해 트리거된 이벤트에 대한 응답으로 시스템이 수행하는 일련의 작업입니다. 사용 사례는 사용자와 시스템 간의 일반적인 상호 작용을 설명합니다. 가장 간단한 경우, 이 정보 시스템에서 구현하고자 하는 기능을 사용자와 논의하는 과정에서 유스 케이스가 결정됩니다. UML에서 사용 사례는 다음과 같이 묘사됩니다.

그림 2. 사용 사례

액터는 시스템과 관련하여 사용자가 수행하는 역할입니다. 액터는 특정 인물이나 직함이 아닌 역할을 나타냅니다. 유스 케이스 다이어그램에서는 양식화된 사람으로 묘사되지만 액터는 시스템에서 일부 정보를 필요로 하는 외부 정보 시스템일 수도 있습니다. 실제로 사용 사례가 필요한 경우에만 액터를 다이어그램에 표시해야 합니다. UML에서 액터는 모양으로 표현됩니다.

그림 3. 캐릭터(배우)

액터는 세 가지 주요 유형으로 나뉩니다.

사용자

시스템;

이 시스템과 상호 작용하는 다른 시스템

시스템의 이벤트 트리거가 시간에 따라 달라지면 시간이 액터가 됩니다.

4.2.1. 사용 사례와 행위자 간의 관계

UML에서 사용 사례 다이어그램은 다이어그램 요소 간의 여러 유형의 관계를 지원합니다.

커뮤니케이션(커뮤니케이션),

포함(포함),

확장(연장),

일반화.

커뮤니케이션 커뮤니케이션유스 케이스와 액터 간의 관계입니다. UML에서 통신 링크는 단방향 연결(실선)을 사용하여 표시됩니다.

그림 4. 통신 링크 예

포함 연결둘 이상의 사용 사례에서 반복되는 일부 시스템 동작이 있는 상황에서 사용됩니다. 이러한 링크의 도움으로 재사용 가능한 기능이 일반적으로 모델링됩니다.

확장 연결시스템의 정상적인 동작의 변화를 설명하는 데 사용됩니다. 이를 통해 한 유스 케이스에서 필요할 때 다른 유스 케이스의 기능을 사용할 수 있습니다.

그림 5. 포함 및 확장 관계의 예

통신 일반화여러 액터 또는 클래스가 공통 속성을 가지고 있음을 나타냅니다.

그림 6. 일반화 관계의 예

4.3.

상호 작용 다이어그램상호 작용하는 개체 그룹의 동작을 설명합니다. 일반적으로 상호 작용 다이어그램은 단일 사용 사례 내에서만 개체의 동작을 다룹니다. 이러한 다이어그램은 여러 개체와 이들이 서로 교환하는 메시지를 표시합니다.

메시지송신자 객체가 수신자 객체에게 작업 중 하나를 수행하도록 요청하는 수단입니다.

정보(정보) 메시지수신 객체에 상태를 업데이트하기 위한 일부 정보를 제공하는 메시지입니다.

요청 메시지(의문)수신자 객체에 대한 일부 정보의 출력을 요청하는 메시지입니다.

명령 메시지수신자에게 어떤 작업을 수행하도록 요청하는 메시지입니다.

상호작용 다이어그램에는 시퀀스 다이어그램과 협업 다이어그램의 두 가지 유형이 있습니다.

4.3.1. 시퀀스 다이어그램

시퀀스 다이어그램단일 사용 사례 내에서 발생하는 이벤트의 흐름을 반영합니다.

주어진 시나리오(사용 사례)와 관련된 모든 행위자(행위자, 클래스 또는 객체)는 다이어그램 상단에 표시됩니다. 화살표는 액터와 객체 사이 또는 필요한 기능을 수행하기 위해 객체 간에 전달되는 메시지에 해당합니다.

시퀀스 다이어그램에서 객체는 수직 점선이 아래쪽으로 그려지는 직사각형으로 표시됩니다. 이 라인은 물건의 생명선 . 그것은 상호 작용 과정에서 객체의 수명주기의 단편입니다.

각 메시지는 두 개체의 수명선 사이에 화살표로 표시됩니다. 메시지는 페이지에 나타나는 순서대로 위에서 아래로 나타납니다. 각 메시지에는 최소한 메시지 이름으로 태그가 지정됩니다. 선택적으로 인수와 일부 제어 정보를 추가할 수도 있습니다. 동일한 수명선을 가리키는 메시지 화살표를 사용하여 개체가 자신에게 보내는 메시지인 자체 위임을 표시할 수 있습니다.

쌀. 7. 시퀀스 다이어그램 예

4.3.2. 협업 다이어그램

협력 다이어그램특정 시나리오(사용 사례) 내에서 이벤트의 흐름을 표시합니다. 메시지는 시간순으로 정렬되지만 협업 다이어그램은 개체 간의 관계에 더 중점을 둡니다. 협업 다이어그램은 시퀀스 다이어그램에 있는 모든 정보를 보여주지만 협업 다이어그램은 이벤트의 흐름을 다른 방식으로 설명합니다. 이를 통해 객체 사이에 존재하는 연결을 이해하는 것이 더 쉽습니다.

시퀀스 다이어그램과 마찬가지로 협업 다이어그램에서 화살표는 주어진 사용 사례 내에서 교환되는 메시지를 나타냅니다. 시간 순서는 메시지 번호로 표시됩니다.

쌀. 8. 협력 다이어그램의 예

4.4. 클래스 다이어그램

4.4.1. 일반 정보

클래스 다이어그램시스템 클래스의 유형과 이들 사이에 존재하는 다양한 유형의 정적 링크를 정의합니다. 클래스 다이어그램은 클래스 간 관계에 배치되는 클래스 속성, 클래스 작업 및 제약 조건도 보여줍니다.

UML에서 클래스 다이어그램은 노드가 프로젝트의 정적 구조(클래스, 인터페이스)의 요소이고 호는 노드 간의 관계(연관, 상속, 종속성)인 그래프입니다.

클래스 다이어그램은 다음 요소를 보여줍니다.

· 패키지(패키지) - 논리적으로 서로 관련된 모델의 요소 집합입니다.

· 클래스(클래스) - 유사한 개체 그룹의 공통 속성에 대한 설명.

· 인터페이스(인터페이스) - 주어진 인터페이스와 관련된 임의의 클래스의 개체가 다른 개체에 제공하는 일련의 작업을 정의하는 추상 클래스입니다.

4.4.2. 수업

수업유사한 속성, 즉 데이터와 동작을 가진 엔터티(객체)의 그룹입니다. 클래스의 개별 구성원을 클래스의 개체 또는 간단히 개체라고 합니다.

UML에서 개체의 동작은 개체와 외부 세계 및 개체 자체의 데이터와의 상호 작용에 대한 모든 규칙을 나타냅니다.

다이어그램에서 클래스는 3개의 섹션으로 수평선으로 나누어진 실선 테두리가 있는 직사각형으로 표시됩니다.

상단 섹션(이름 섹션)에는 클래스의 이름 및 기타 일반 속성(특히 스테레오타입)이 포함됩니다.

중간 섹션에는 속성 목록이 포함되어 있습니다.

맨 아래에는 해당 동작(클래스에서 수행한 작업)을 반영하는 클래스 작업 목록이 있습니다.

속성 및 작업 섹션 중 어느 것도 표시되지 않을 수 있습니다(또는 둘 다). 누락 된 섹션의 경우 구분선을 그릴 필요가 없으며 어떻게 든 요소의 유무를 나타낼 수 있습니다.

예외와 같은 추가 섹션은 특정 구현의 재량에 따라 도입될 수 있습니다.

쌀. 9. 클래스 다이어그램 예제

4.4.2.1.계급 고정 관념

클래스 고정 관념은 클래스를 범주로 분류하는 메커니즘입니다.

UML은 세 가지 주요 클래스 스테레오타입을 정의합니다.

경계(경계);

엔티티(entity);

제어(관리).

4.4.2.2.경계 클래스

경계 클래스는 시스템과 전체 환경의 경계에 있는 클래스입니다. 이들은 디스플레이, 보고서, 하드웨어와의 인터페이스(예: 프린터 또는 스캐너) 및 다른 시스템과의 인터페이스입니다.

경계 클래스를 찾으려면 사용 사례 다이어그램을 탐색해야 합니다. 액터와 사용 사례 간의 모든 상호 작용에는 최소한 하나의 경계 클래스가 있어야 합니다. 액터가 시스템과 상호 작용할 수 있도록 하는 것은 이 클래스입니다.

4.4.2.3.엔티티 클래스

엔티티 클래스에는 저장된 정보가 포함됩니다. 그들은 사용자에게 가장 큰 의미를 가지므로 이름은 종종 주제 영역의 용어를 사용합니다. 일반적으로 각 엔터티 클래스에 대해 데이터베이스에 테이블이 생성됩니다.

4.4.2.4.제어 클래스

제어 클래스는 다른 클래스의 작업을 조정할 책임이 있습니다. 일반적으로 각 사용 사례에는 해당 사용 사례에 대한 이벤트 시퀀스를 제어하는 ​​하나의 제어 클래스가 있습니다. 제어 클래스는 조정을 담당하지만 다른 클래스가 많은 메시지를 보내지 않기 때문에 그 자체로는 기능을 수행하지 않습니다. 대신 그 자신이 많은 메시지를 보낸다. 관리자 클래스는 단순히 다른 클래스에 책임을 위임하므로 종종 관리자 클래스라고 합니다.

시스템에는 여러 사용 사례에 공통적인 다른 제어 클래스가 있을 수 있습니다. 예를 들어 보안 관련 이벤트를 모니터링하는 SecurityManager 클래스가 있을 수 있습니다. TransactionManager 클래스는 데이터베이스 트랜잭션과 관련된 메시지 조정을 처리합니다. 자원 공유, 분산 데이터 처리 또는 오류 처리와 같은 시스템 작동의 다른 요소를 처리하는 다른 관리자가 있을 수 있습니다.

위에서 언급한 고정 관념 외에도 자신의 고정 관념을 만들 수 있습니다.

4.4.2.5.속성

속성은 클래스와 관련된 정보입니다. 속성은 캡슐화된 클래스 데이터를 저장합니다.

속성은 클래스 내에 포함되어 있기 때문에 다른 클래스에서 숨겨집니다. 이 때문에 속성을 읽고 수정할 수 있는 권한이 있는 클래스를 지정해야 할 수 있습니다. 이 속성을 속성 가시성이라고 합니다.

속성은 이 매개변수에 대해 네 가지 가능한 값을 가질 수 있습니다.

공개(일반, 공개). 이 가시성 값은 속성이 다른 모든 클래스에 표시될 것이라고 가정합니다. 모든 클래스는 속성 값을 보거나 변경할 수 있습니다. UML 표기법에 따라 공통 속성 앞에 "+" 기호가 옵니다.

비공개(폐쇄, 비밀). 해당 속성은 다른 클래스에서 볼 수 없습니다. private 속성은 UML 표기법에 따라 "-" 기호로 표시됩니다.

보호(보호). 이러한 속성은 클래스 자체와 해당 하위 항목에만 사용할 수 있습니다. 보호된 속성에 대한 UML 표기법은 "#" 기호입니다.

패키지 또는 구현(일괄 처리). 주어진 속성이 공유되지만 패키지 내에서만 공유된다고 가정합니다. 이러한 유형의 가시성은 특별한 아이콘으로 표시되지 않습니다.

폐쇄성 또는 보안의 도움으로 시스템의 모든 클래스에서 속성 값이 변경되는 상황을 피할 수 있습니다. 대신 속성 수정 논리는 속성 자체와 동일한 클래스로 래핑됩니다. 설정한 가시성 옵션은 생성된 코드에 영향을 미칩니다.

4.4.2.6.운영

작업은 클래스 관련 동작을 구현합니다. 작업은 이름, 매개변수 및 반환 유형의 세 부분으로 구성됩니다.

매개변수는 작업이 입력으로 받는 인수입니다. 반환 유형은 작업 작업의 결과를 나타냅니다.

클래스 다이어그램에서 매개변수 및 반환 유형과 함께 작업 이름과 작업 이름을 모두 표시할 수 있습니다. 다이어그램의 부하를 줄이려면 일부 작업에는 작업 이름만 표시하고 다른 작업에는 전체 서명을 표시하는 것이 좋습니다.

UML에서 작업에는 다음 표기법이 있습니다.

연산 이름(인수: 인수 데이터 유형, 인수2: 인수2 데이터 유형,...): 반환 유형

고려해야 할 4가지 작업 유형이 있습니다.

구현 작업;

관리 작업;

액세스 작업;

보조 작업.

구현 작업

구현자 작업은 일부 비즈니스 기능을 구현합니다. 이러한 작업은 상호 작용 다이어그램을 검사하여 찾을 수 있습니다. 이 유형의 다이어그램은 비즈니스 기능에 중점을 두고 있으며 다이어그램의 각 메시지는 구현 작업과 연결될 가능성이 큽니다.

각 구현 작업은 해당 요구 사항을 쉽게 추적할 수 있어야 합니다. 이것은 시뮬레이션의 다양한 단계에서 달성됩니다. 작업은 상호 작용 다이어그램의 메시지에서 파생되고 메시지는 사용 사례를 기반으로 생성되는 이벤트 흐름에 대한 자세한 설명에서 파생되며 후자는 요구 사항을 기반으로 합니다. 이 전체 체인을 추적할 수 있으면 각 요구 사항이 코드에서 구현되고 각 코드 조각이 일부 요구 사항을 구현하는 데 도움이 됩니다.

관리 작업

관리자 작업은 개체의 생성 및 소멸을 관리합니다. 클래스 생성자와 소멸자가 이 범주에 속합니다.

액세스 작업

속성은 일반적으로 비공개이거나 보호됩니다. 그러나 다른 클래스에서 값을 보거나 변경해야 하는 경우가 있습니다. 이를 위한 액세스 작업이 있습니다. 이 접근 방식을 사용하면 속성을 클래스 내에서 안전하게 캡슐화하여 다른 클래스로부터 속성을 보호하면서도 여전히 액세스를 제어할 수 있습니다. 클래스의 각 속성에 대한 Get 및 Set 작업 생성(값 가져오기 및 변경)은 표준입니다.

보조 작업

보조(도우미 작업)는 책임을 수행하는 데 필요한 클래스의 작업이지만 다른 클래스는 이에 대해 알 수 없습니다. 이는 private 및 protected 클래스 작업입니다.

트랜잭션을 식별하려면 다음을 수행하십시오.

1. 시퀀스 다이어그램과 협력 다이어그램을 연구합니다. 이 다이어그램에 있는 대부분의 메시지는 구현 작업입니다. 반사 메시지는 보조 작업이 됩니다.

2. 제어 작업을 고려하십시오. 생성자와 소멸자를 추가해야 할 수도 있습니다.

3. 액세스 작업을 고려하십시오. 다른 클래스가 작업해야 하는 각 클래스 속성에 대해 Get 및 Set 작업을 생성해야 합니다.

4.4.2.7.사이

관계는 클래스 간의 의미론적 관계입니다. 클래스는 다른 클래스의 속성, 작업 및 관계에 대해 학습할 수 있습니다. 즉, 시퀀스나 협력 다이어그램에서 한 클래스가 다른 클래스로 메시지를 보내려면 이들 사이에 연결이 있어야 합니다.

클래스 간에 설정할 수 있는 관계에는 연관, 종속성, 집계 및 일반화의 네 가지 유형이 있습니다.

통신협회

연관은 클래스 간의 의미론적 관계입니다. 클래스 다이어그램에 일반 선으로 그려집니다.

쌀. 10. 통신협회

연결은 예제와 같이 양방향이거나 단방향일 수 있습니다. UML에서 양방향 연결은 화살표가 없는 단순한 선이나 선의 양쪽에 화살표가 있는 선으로 그려집니다. 단방향 연결에는 방향을 나타내는 화살표가 하나만 있습니다.

연관 방향은 시퀀스 다이어그램과 협력 다이어그램을 검토하여 결정할 수 있습니다. 모든 메시지가 한 클래스에서만 전송되고 다른 클래스에서만 수신되고 그 반대는 아닌 경우 이러한 클래스 간에 단방향 통신이 있습니다. 적어도 하나의 메시지가 반대 방향으로 보내지면 연결은 양방향이어야 합니다.

연관은 반사적일 수 있습니다. 재귀 연결은 클래스의 한 인스턴스가 같은 클래스의 다른 인스턴스와 상호 작용하는 것을 의미합니다.

커뮤니케이션 중독

종속 관계도 클래스 간의 관계를 반영하지만 항상 단방향이며 한 클래스가 다른 클래스에서 정의된 것에 의존한다는 것을 보여줍니다. 예를 들어 클래스 A는 클래스 B의 메소드를 사용합니다. 그런 다음 클래스 B가 변경되면 클래스 A에서 해당 변경을 수행해야 합니다.

종속성은 두 개의 다이어그램 요소 사이에 그려진 점선으로 표시되며 화살표 끝에 고정된 요소는 해당 화살표의 시작 부분에 고정된 요소에 종속된다고 합니다.

쌀. 11. 커뮤니케이션 중독

이러한 클래스에 대한 코드를 생성할 때 새 속성이 추가되지 않습니다. 단, 커뮤니케이션 지원에 필요한 언어별 연산자가 생성됩니다.

통신 집계

집계는 보다 긴밀한 연결 형태입니다. 집합은 전체와 부분 사이의 연결입니다. 예를 들어, 자동차 클래스와 엔진, 타이어 클래스 및 기타 자동차 부품에 대한 클래스가 있을 수 있습니다. 결과적으로 Car 클래스의 객체는 Engine 클래스의 객체, Tires의 4개 객체 등으로 구성됩니다. 집계는 정수인 클래스에 대한 마름모가 있는 선으로 시각화됩니다.

쌀. 11. 통신 집계

단순한 집계 외에도 UML은 구성이라는 더 강력한 집계 형식을 도입합니다. 구성에 따르면 대상-부분은 단일 전체에만 속할 수 있으며, 또한 원칙적으로 부분의 수명 주기는 전체의 주기와 일치합니다. 전체의 제거는 부분으로 확장됩니다.

이 계단식 삭제는 종종 집계 정의의 일부로 간주되지만 역할 다중성이 1..1인 경우 항상 암시됩니다. 예를 들어 고객을 삭제해야 하는 경우 해당 삭제가 주문(그리고 차례로 주문 라인)으로 전파되어야 합니다.

UML은 소프트웨어 시스템 개발에서 생성된 모든 아티팩트의 사양, 시각화, 디자인 및 문서화를 위한 범용 그래픽 모델링 언어입니다.

UML에 대해 자세히 설명하는 좋은 책이 많이 있습니다(때로는 매우 상세하기도 합니다). 다이어그램, 엔터티 및 이들 간의 관계에 대한 기본 개념을 한 곳에서 모아서 치트 시트와 같은 빠른 회상을 하고 싶습니다.

메모는 책의 자료를 사용합니다. Ivanov D. Yu., Novikov F. A. 통합 모델링 언어 UML그리고 레오넨코프. UML 튜토리얼.

편집기부터 시작하겠습니다. Linux에서 다양한 UML 편집기를 사용해 보았는데, 무엇보다도 UMLet이 마음에 들었습니다. 비록 Java로 작성되었지만 매우 빠르게 이동하고 대부분의 엔터티 공백이 그 안에 있습니다. 또한 Java로 작성된 교차 플랫폼 UML 편집기인 ArgoUML이 있습니다. 기능은 풍부하지만 속도가 더 느려집니다.

나는 에서 멈췄다 UMLet, 아래에 설치 아치 리눅스그리고 우분투:

# Arch Linux에서 yaourt -S umlet # Ubuntu에서 sudo apt-get install umlet

UML에서 모든 엔터티는 다음 유형으로 나눌 수 있습니다.

• 구조적;
• 행동적;
• 그룹화;
• 주석;

UML은 네 가지 주요 유형의 관계를 사용합니다.

의존- 독립 엔터티를 변경하면 종속 엔터티에 어떤 식으로든 영향을 미친다는 것을 나타냅니다. 그래픽으로 종속 관계는 종속 엔터티에서 독립 엔터티를 가리키는 화살표가 있는 점선으로 표시됩니다.

협회- 한 엔터티가 다른 엔터티(또는 다른 엔터티와 직접 관련이 있는 경우)가 발생합니다. 연관은 바이너리일 뿐만 아니라 가능합니다. 그래픽으로 연결은 관련 엔터티를 연결하는 다양한 추가 기능이 있는 실선으로 표시됩니다.

일반화는 두 엔티티 간의 관계이며, 그 중 하나는 다른 하나의 특정(특수한) 경우입니다. 그래픽으로 일반화는 특정(하위 클래스)에서 일반(수퍼 클래스)으로 향하는 끝부분에 채워지지 않은 삼각형 화살표가 있는 선으로 표시됩니다.

구현- 구현 관계는 한 엔터티가 다른 엔터티의 구현임을 나타냅니다. 그래픽으로 구현은 구현 엔터티에서 구현 엔터티로 향하는 끝 부분에 채워지지 않은 삼각형 화살표가 있는 점선으로 표시됩니다.

에 UML 2한정된 13 차트 유형. 표준에 따라 각 차트에는 차트 ID(태그) 및 제목을 나타내는 왼쪽 상단 모서리에 직사각형(오른쪽 하단 모서리가 비스듬한 모양)이 있는 프레임이 있어야 합니다.

시스템 구조를 나타내는 다이어그램:

• 컴포넌트 다이어그램(컴포넌트 다이어그램, 태그 요소);
• 배포 다이어그램(배포 다이어그램, 태그 전개);
• 클래스 다이어그램(클래스 다이어그램, 태그 수업);
• 오브젝트 다이어그램(오브젝트 다이어그램, 태그 물체);
• 내부구조도(복합구조도, 태그 수업);

시스템 동작을 나타내는 다이어그램:

• 동기화 다이어그램(상호작용 다이어그램, 태그 타이밍);
• 활동도(활동도, 태그 활동);
• 시퀀스 다이어그램(시퀀스 다이어그램, 태그 SD);
• 통신도(통신도, 태그 통신);
• Automaton 다이어그램(상태 머신 다이어그램, 태그 상태 머신);
• 상호 작용 개요 다이어그램, 태그 상호 작용);

차트가 눈에 띕니다.

• 유스 케이스 다이어그램(유스 케이스 다이어그램, 유스 케이스 태그);
• 패키지 다이어그램(패키지 다이어그램, 태그 패키지);

사용 다이어그램

사용 다이어그램(사용 사례 다이어그램)은 시스템의 기능적 목적을 가장 일반적으로 표현한 것입니다.

유스 케이스 다이어그램을 시스템 모델로 고려하면 블랙박스 모델과 연관시킬 수 있습니다. 각 사용 사례는 해당 액터와 상호 작용할 때 설계된 시스템에서 수행해야 하는 일련의 작업을 정의합니다.

사용 다이어그램은 두 가지 유형의 기본 엔터티인 사용 사례와 행위자를 사용하며, 그 사이에 다음과 같은 기본 유형의 관계가 설정됩니다.

연관 관계- 이 관계는 사용 사례의 인스턴스와 상호 작용할 때 액터가 수행하는 특정 역할을 설정합니다. 연관 관계는 액터와 사용 사례 사이의 실선으로 표시됩니다. 이 줄에는 이름 및 다중도와 같은 추가 기호가 있을 수 있습니다.

확장 관계- 단일 사용 사례의 인스턴스와 보다 일반적인 사용 사례의 관계를 정의하며, 속성은 이러한 인스턴스가 함께 결합되는 방식에 따라 결정됩니다. 따라서 유스 케이스 A에서 유스 케이스 B로의 확장 관계가 있는 경우, 이는 유스 케이스 B의 인스턴스 속성이 확장된 유스 케이스 A의 속성으로 인해 보완될 수 있음을 의미합니다.

유스 케이스 간의 확장 관계는 원래 유스 케이스의 확장인 유스 케이스를 가리키는 화살표(종속성 관계 케이스)가 있는 파선으로 표시됩니다.

일반화 관계어떤 유스케이스 A는 유스케이스 B로 일반화될 수 있다는 사실을 나타내는 역할을 한다. 이 경우 유스케이스 A는 유스케이스 B의 특화일 것이다. 이 경우 B는 A의 조상 또는 부모라고 하며, A는 V의 유스 케이스 사용의 후손입니다.

그래픽으로 이 관계는 상위 사용 사례를 가리키는 열린 삼각형 화살표가 있는 실선으로 표시됩니다.

유스 케이스 간의 일반화 관계는 하위 유스 케이스가 상위 유스 케이스의 모든 속성과 동작을 갖는다는 점에 유의해야 할 때 사용됩니다.

포함 관계두 사용 사례 사이는 한 사용 사례에 대해 지정된 일부 동작이 다른 사용 사례의 동작 순서에 구성 요소로 포함되어 있음을 나타냅니다.

유스 케이스 A에서 유스 케이스 B로의 포함 관계는 유스 케이스 A의 각 인스턴스가 유스 케이스 B에 대해 지정된 기능적 속성을 포함한다는 것을 나타냅니다.

그래픽으로 이 관계는 기본 사용 사례에서 포함된 사용 사례를 가리키는 화살표(종속성 관계 변형)가 있는 점선으로 표시됩니다.

클래스 다이어그램

클래스 다이어그램(클래스 다이어그램) - 시스템의 정적 구조를 설명하는 주요 방법.

클래스 다이어그램은 하나의 주요 엔터티 유형인 클래스(인터페이스, 기본 유형, 연관 클래스 등의 다양한 특수 클래스 포함)를 사용하며, 이들 사이에는 종속성, 연관, 일반화, 구현과 같은 주요 유형의 관계가 설정됩니다.

종속 관계일반적으로 연관, 일반화 또는 구현 관계가 아닌 두 모델 요소 또는 이러한 요소의 두 세트 간의 의미론적 관계를 나타냅니다. 종속 관계는 한 모델 요소의 일부 변경이 다른 종속 모델 요소의 변경을 요구할 수 있는 상황에서 사용됩니다.

종속성 관계는 한쪽 끝에 화살표가 있는 해당 요소 사이의 점선으로 그래픽으로 표시되며 화살표는 종속성의 클라이언트 클래스에서 독립 또는 소스 클래스를 가리킵니다.

특수 키워드(고정관념)는 화살표 위에 배치할 수 있습니다.

• "액세스" - 클라이언트 클래스에 대한 소스 클래스의 작업 및 공개 속성의 가용성을 나타내는 역할을 합니다.
• "bind" - 클라이언트 클래스는 후속 매개변수화를 위해 일부 템플릿을 사용할 수 있습니다.
• "파생" ​​- 클라이언트 클래스의 속성은 소스 클래스의 속성에서 계산할 수 있습니다.
• "가져오기" - 소스 클래스의 공개 속성 및 작업은 마치 직접 선언된 것처럼 클라이언트 클래스의 일부가 됩니다.
• "refine" - 프로젝트 작업 과정에서 추가 정보를 사용할 수 있게 되면 클라이언트 클래스가 역사적 이유로 소스 클래스를 개선하는 역할을 함을 나타냅니다.

연관 관계클래스 간의 일부 관계의 존재에 해당합니다. 이 관계는 특정 연결의 개별 속성을 특징짓는 추가 특수 기호가 있는 실선으로 표시됩니다. 추가 특수 문자로 연관 이름과 연관 역할 클래스의 이름 및 다중성을 사용할 수 있습니다. 연관 이름은 지정의 선택적 요소입니다.

집계 관계클래스 중 하나가 다른 엔터티를 구성 요소로 포함하는 엔터티인 경우 여러 클래스 간에 발생합니다. "부분-전체" 유형의 시스템 관계를 나타내는 데 사용됩니다.

구성 관계집계 관계의 특별한 경우입니다. 이 관계는 구성 부분이 어떤 의미에서 전체 안에 있는 부분-전체 관계의 특별한 형태를 강조하는 역할을 합니다. 그들 사이의 관계의 특수성은 부분이 전체와 분리되어 작용할 수 없다는 사실에 있습니다. 즉, 전체가 파괴되면 구성 요소도 모두 파괴됩니다.

일반화 관계보다 일반적인 요소(부모 또는 조상)와 보다 구체적이거나 특별한 요소(자식 또는 후손) 간의 관계입니다. 클래스 다이어그램에 적용되는 이 관계는 클래스의 계층 구조와 해당 속성 및 동작의 상속을 설명합니다. 이것은 자손 클래스가 조상 클래스의 모든 속성과 동작을 가지고 있으며 또한 조상 클래스에는 없는 고유한 속성과 동작을 가지고 있다고 가정합니다.

오토마톤 다이어그램

오토마톤 다이어그램(상태 머신 다이어그램) 또는 상태 다이어그램 UML 1(상태 차트 다이어그램)에서 UML에서 동작을 자세히 설명하는 방법 중 하나입니다. 본질적으로 오토마톤 다이어그램은 이름에서 알 수 있듯이 많은 추가 세부 정보와 세부 정보가 포함된 유한 오토마톤의 상태 및 전환 그래프입니다.

상태 다이어그램은 하나의 클래스 또는 특정 클래스의 한 인스턴스의 상태를 변경하는 프로세스를 설명합니다. 즉, 특정 개체의 상태에서 가능한 모든 변경을 모델링합니다. 이 경우 물체의 상태 변화는 다른 물체나 외부로부터의 외부 영향에 의해 발생할 수 있습니다. 상태도를 사용하는 것과 같은 외부 영향에 대한 개체의 반응을 설명하는 것입니다.

자동 다이어그램에서 하나의 주요 유형의 엔터티(상태 및 한 가지 유형의 관계)가 사용되지만 둘 모두에 대해 많은 종류, 특별한 경우 및 추가 지정이 정의됩니다. 자동 장치는 방향 그래프의 형태로 시뮬레이션된 시스템의 동적 측면을 나타내며, 정점은 상태에 해당하고 호는 전환에 해당합니다.

초기 상태내부 작업(의사 상태)을 포함하지 않는 상태의 특수한 경우입니다. 개체는 초기 시간에 기본적으로 이 상태에 있습니다. 상태 변경 프로세스가 시작되는 그래픽 영역의 상태 다이어그램을 나타내는 역할을 합니다.

결승(최종)상태는 내부 작업(의사 상태)도 포함하지 않는 상태의 특수한 경우입니다. 개체는 종료 시간에 자동 장치가 완료된 후 기본적으로 이 상태가 됩니다.

활동도

설계되거나 분석된 시스템의 동작을 모델링할 때 상태를 변경하는 프로세스를 제시할 뿐만 아니라 시스템에서 수행되는 작업의 알고리즘 및 논리적 구현의 기능을 자세히 설명해야 합니다.

활동도(활동 다이어그램)은 알고리즘의 오래된 흐름도와 시각적으로 유사한 동작을 설명하는 또 다른 방법입니다. 작업 수행 프로세스를 시뮬레이션하는 데 사용됩니다.

활동 다이어그램을 사용하는 주요 방향은 실행을 위한 알고리즘을 제시해야 할 때 클래스 작업 구현의 기능을 시각화하는 것입니다.

활동 다이어그램에서는 한 가지 주요 유형의 엔터티인 작업과 한 가지 유형의 관계인 전환(제어 이전)이 사용됩니다. 포크, 합병, 연결, 분기와 같은 구성도 사용됩니다. 단순동작의 명칭은 설명어가 있는 동사를 사용하는 것이 좋습니다.

시퀀스 다이어그램

시퀀스 다이어그램(시퀀스 다이어그램)은 "예를 통해" 시스템의 동작을 설명하는 방법입니다.

사실, 시퀀스 다이어그램은 시스템의 특정 세션(또는 그러한 프로토콜의 단편)의 프로토콜에 대한 기록입니다. 객체 지향 프로그래밍에서 런타임에 가장 중요한 것은 협력하는 객체 간에 메시지를 전달하는 것입니다. 이 다이어그램에 표시되는 메시지 전송 순서이므로 이름이 표시됩니다.

시퀀스 다이어그램에서는 상호 작용하는 분류기의 인스턴스(주로 클래스, 구성 요소 및 행위자)와 한 가지 유형의 관계(메시지가 교환되는 링크)와 같은 엔터티의 한 가지 주요 유형이 사용됩니다.

가능한 메시지 유형(larin.in에서 가져온 이미지):

커뮤니케이션 다이어그램

커뮤니케이션 다이어그램(통신 다이어그램) - 시퀀스 다이어그램과 의미적으로 동일한 동작을 설명하는 방법입니다. 사실 이것은 다른 그래픽 수단으로만 표현되는 분류기의 상호 작용 인스턴스의 메시지 교환 순서에 대한 동일한 설명입니다.

따라서 통신 다이어그램과 시퀀스 다이어그램에서는 상호 작용하는 분류기의 인스턴스와 한 가지 유형의 관계인 연결이라는 한 가지 주요 유형의 엔터티가 사용됩니다. 그러나 여기서 강조점은 시간이 아니라 특정 사례 간의 관계 구조에 있습니다.

구성 요소 다이어그램

구성 요소 다이어그램(구성 요소 다이어그램) - 시뮬레이션된 시스템을 구성하는 모듈(논리적 또는 물리적) 간의 관계를 보여줍니다.

구성 요소 다이어그램의 주요 엔터티 유형은 구성 요소 자체와 구성 요소 간의 관계를 나타내는 인터페이스입니다. 구성 요소 다이어그램에는 다음 관계가 적용됩니다.

• 구성 요소와 인터페이스 간의 구현(구성 요소가 인터페이스를 구현함)
• 구성 요소와 인터페이스 간의 종속성(구성 요소는 인터페이스를 사용함)

배치 다이어그램

배치 다이어그램(배포 다이어그램)은 시스템 요소의 구성 및 관계를 표시하는 것과 함께 실행 중에 컴퓨팅 리소스에 물리적으로 배치되는 방식을 보여줍니다.

배치 다이어그램에는 컴포넌트 다이어그램과 비교하여 두 가지 유형의 엔티티가 추가됩니다. 컴포넌트의 구현인 아티팩트와 노드(노드 유형을 설명하는 분류자 또는 특정 인스턴스일 수 있음) , 뿐만 아니라 노드 간의 연관 관계는 런타임에 노드가 물리적으로 연결되었음을 보여줍니다.

개체 다이어그램

개체 다이어그램(객체 다이어그램) - 클래스 다이어그램의 인스턴스입니다.

개체 다이어그램에서는 엔터티의 한 가지 주요 유형인 개체(클래스 인스턴스)가 사용되며, 그 사이에 특정 관계가 표시됩니다(대부분의 경우 연결 인스턴스). 개체 다이어그램은 보조적 성격을 띠고 있습니다. 사실, 이것은 시스템 작동의 특정 순간에 존재하는 개체와 개체 간의 관계를 보여주는 예(메모리 덤프라고 할 수 있음)입니다.

내부 구조도(복합 구조 다이어그램)은 구조적 분류기, 주로 클래스와 구성 요소를 보다 자세히 표현하는 데 사용됩니다.

구조적 분류기는 상단에 분류기의 이름이 있는 직사각형으로 표시됩니다. 내부는 부품입니다. 여러 부분이 있을 수 있습니다. 부품은 서로 상호 작용할 수 있습니다. 이것은 다양한 종류의 커넥터로 표시됩니다. 커넥터가 부착되는 부분의 바깥쪽 가장자리에 있는 곳을 포트라고 합니다. 포트는 또한 구조적 분류기의 외부 경계에 있습니다.

상호 작용 개요 다이어그램(상호작용 개요 다이어그램)은 확장된 구문이 있는 일종의 활동 다이어그램입니다. 시퀀스 다이어그램에 의해 정의된 상호작용(상호작용 사용)에 대한 링크는 개요 상호작용 다이어그램의 요소로 작동할 수 있습니다.

타이밍 다이어그램

타이밍 다이어그램(타이밍 다이어그램)은 다양한 분류기 인스턴스의 상태 변화와 시간 동기화에 특별한 주의를 기울이는 시퀀스 다이어그램의 특별한 형태입니다.

패키지 다이어그램

패키지 다이어그램(패키지 다이어그램)은 모델 자체의 복잡성을 관리할 수 있는 유일한 도구입니다.

표기법의 주요 요소는 다양한 스테레오타입의 패키지 및 종속성입니다.

엔터티-관계 모델(ER-모델)

비슷한 물건 클래스 다이어그램(UML)은 응급실 모델, 데이터베이스(관계형 모델) 설계에 사용됩니다.

ER-모델(Entity-Relationship Model)은 주제 영역의 개념적 스키마를 설명할 수 있는 데이터 모델입니다. ER 모델은 고급(개념적) 데이터베이스 설계에 사용됩니다. 도움을 받아 주요 엔터티를 강조 표시하고 이러한 엔터티 간에 설정할 수 있는 관계를 지정할 수 있습니다. 위키피디아

주제 영역의 모든 조각은 엔터티 집합으로 표시될 수 있으며 그 사이에는 몇 가지 관계 집합이 있습니다.

기본 컨셉:

본질(엔티티)는 다른 엔터티와 구별되는 어떤 방식으로든 식별할 수 있는 엔터티입니다. 예를 들면 다음과 같습니다. 클라이언트 777. 엔터티는 실제로 속성 집합입니다.

엔티티 세트(엔티티 세트) - 동일한 유형의 엔티티 세트(동일한 속성을 가짐).

연결(관계)는 여러 엔터티 간에 설정된 연결입니다.

도메인(도메인) - 속성의 값 집합(도메인).

바이너리 링크에는 세 가지 유형이 있습니다.

• 1-1- 한 클래스 엔티티의 단일 인스턴스는 다른 클래스 엔티티의 단일 인스턴스와 연관됩니다(예: HEAD - DEPARTMENT).
• 1 ~ N또는 일대다- 한 클래스 엔티티의 단일 인스턴스는 다른 클래스 엔티티의 여러 인스턴스와 연관됩니다(예: DEPARTMENT - EMPLOYEE).
• N에서 M또는 많은- 한 클래스 엔티티의 많은 인스턴스가 다른 클래스 엔티티의 많은 인스턴스와 연관됩니다(예: EMPLOYEE - PROJECT).
UML의 기본 개념 용어집

물체- 고유성을 갖고 상태와 행동을 캡슐화하는 엔터티.

수업- 상태를 정의하는 공통 속성과 동작을 정의하는 작업을 가진 객체 세트에 대한 설명.

상호 작용- 소비자가 요청할 수 있고 서비스 공급자가 제공할 수 있는 서비스 집합을 정의하는 명명된 작업 집합입니다.

협력- 어떤 목표를 달성하기 위해 상호 작용하는 일련의 객체.

배우- 모델링된 시스템 외부에 있고 직접 상호 작용하는 개체입니다.

요소- 잘 정의된 필수 및 제공 인터페이스 세트가 있는 시스템의 모듈식 부분.

인공물- 소프트웨어 개발 프로세스에서 사용되거나 생성되는 정보 요소. 즉, 아티팩트는 모델 요소(예: 클래스 또는 구성 요소)에서 파생된 물리적 구현 단위입니다.

마디- 아티팩트가 배치되고 필요한 경우 실행되는 컴퓨팅 리소스.

행동 엔터티는 행동을 설명하기 위한 것입니다. 상태와 행동이라는 두 가지 기본 행동 엔터티만 있습니다.

상태- 개체의 수명 주기 중 개체가 특정 조건을 만족하고 자체 활동을 수행하거나 어떤 이벤트가 발생하기를 기다리는 기간입니다.

동작- 원시 원자 계산.

기계유한한 수의 상태와 전환을 가진 이산 공간으로 모델링된 엔터티의 동작을 나타내는 데 필요한 개념 집합을 정의하는 패키지입니다.

분류기같은 유형의 개체 집합에 대한 설명자입니다.

추가 읽기

• 파울러 M. UML. 기초, 3판
• Butch G., Rambo D., Jacobson I. UML 언어. 사용 설명서

UML은 Unified Modeling Language의 약자입니다. 사실, 이것은 가장 널리 사용되는 비즈니스 프로세스 모델링 기술 중 하나이며 소프트웨어 개발을 지정, 시각화 및 문서화하기 위한 국제 표준 표기법입니다. 개체 관리 그룹에서 정의한 몇 가지 추가 UML 표기법 시스템의 결과로 등장했으며 이제 시각적 모델링의 사실상 표준이 되었습니다. 모든 객체 지향 프로그래밍의 기본 원칙은 모델 구축에서 시작됩니다.

UML은 소프트웨어 개발 및 문서화를 둘러싼 혼란 속에서 만들어졌습니다. 1990년대에는 소프트웨어 시스템을 나타내는 몇 가지 다른 방법이 있었습니다. 이러한 시스템을 표현하는 보다 통합된 시각적 UML 방식이 필요했으며, 그 결과 1994년에서 ​​1996년 사이에 Rational Software에서 일하는 세 명의 소프트웨어 엔지니어에 의해 개발되었습니다. 나중에 1997년에 표준으로 채택되었으며 몇 가지 업데이트만으로 오늘날까지 유지되고 있습니다.

기본적으로 UML은 소프트웨어 개발 분야의 범용 모델링 언어입니다. 그러나 이제 활동 다이어그램과 같은 여러 비즈니스 프로세스 또는 워크플로의 문서화에 사용되었습니다. UML 다이어그램 유형은 순서도를 대체하는 데 사용할 수 있습니다. 워크플로를 모델링하는 보다 표준화된 방법과 가독성 및 효율성을 향상시키는 광범위한 기능을 모두 제공합니다.

아키텍처는 UML 언어 생성을 위한 기반을 정의하는 메타 객체를 기반으로 합니다. 전체 애플리케이션을 생성할 수 있을 만큼 정확합니다. 완전히 실행 가능한 UML은 전체 소프트웨어 개발 주기에 걸쳐 모든 프로세스와 함께 서로 다른 기술을 사용하여 여러 플랫폼에 배포할 수 있습니다.

UML은 사용자가 시각적 모델링 언어를 개발하도록 설계되었습니다. 구조, 패턴 및 협업과 같은 높은 수준의 개발 개념을 지원합니다. UML은 다음과 같은 요소 모음입니다.

1. 프로그래밍 언어 문.
2. 액터는 사용자 또는 개체와 상호 작용하는 다른 시스템이 수행하는 역할을 설명합니다.
3. 작업 계약 실행을 위해 수행할 활동 및 다이어그램으로 표시됩니다.
4. 고객을 위한 특정 서비스를 생성하는 일련의 작업을 포함하는 비즈니스 프로세스로, 순차적 작업의 플로차트로 시각화됩니다.
5. 논리 및 재사용 가능한 소프트웨어 구성 요소.

UML 다이어그램은 두 가지 범주로 나뉩니다. 첫 번째 유형은 구조 정보를 나타내는 7가지 유형의 다이어그램을 포함하고, 두 번째 유형은 일반적인 행동 유형을 나타내는 나머지 7가지 유형을 포함합니다. 이 다이어그램은 시스템 아키텍처를 문서화하는 데 사용되며 시스템의 UML 모델링에 직접 관련됩니다.

UML 다이어그램은 시스템 모델의 정적 및 동적 표현으로 제공됩니다. 정적 보기에는 정적 구조를 강조하는 클래스 및 복합 구조 다이어그램이 포함됩니다. 동적 뷰는 시퀀스, 활동 및 상태 다이어그램을 사용하여 개체 간의 상호 작용과 개체의 내부 상태 변경을 나타냅니다.

IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner 및 Dia를 비롯한 다양한 UML 모델링 도구를 사용하여 모델링을 단순화할 수 있습니다.

UML의 사용은 소프트웨어 개발 문서와 비즈니스 프로세스 모두에서 다양한 형태를 가집니다.

1. 스케치. 이 경우 UML 다이어그램은 시스템의 다양한 측면과 특성을 전달하는 데 사용됩니다. 그러나 이것은 시스템의 최상위 보기일 뿐이며 프로젝트를 끝까지 수행하는 데 필요한 모든 세부 정보를 포함하지 않을 가능성이 큽니다.
2. 포워드 디자인 - 애플리케이션이 코딩되기 전에 스케치 디자인이 완료됩니다. 이는 사용자가 만들려는 시스템 또는 워크플로에 대한 더 나은 개요를 위해 수행됩니다. 많은 설계 문제 또는 결함이 식별될 수 있으며, 이는 프로젝트의 전반적인 상태와 웰빙을 향상시킬 것입니다.
3. 리버스 디자인. 코드가 작성되면 UML 다이어그램은 다양한 활동, 역할, 기여자 및 워크플로에 대한 문서 형식으로 나타납니다.
4. 청사진. 이 경우 다이어그램은 시스템 또는 소프트웨어의 실제 구현만 필요한 완전한 구성의 역할을 합니다. 이는 종종 CASE(Computer Aided Software Engineering Tools) 도구를 사용하여 수행됩니다. CASE 도구 사용의 주요 단점은 일정 수준의 지식, 사용자 교육, 관리 및 인력이 필요하다는 것입니다.

UML은 Java, C++ 또는 Python과 같은 독립형 프로그래밍 언어가 아니지만 올바른 도구를 사용하면 UML 의사 프로그래밍 언어로 전환할 수 있습니다. 이 목표를 달성하려면 전체 시스템을 다른 다이어그램으로 문서화해야 하며 올바른 소프트웨어를 사용하여 다이어그램을 코드로 직접 변환할 수 있습니다. 이 방법은 다이어그램을 그리는 데 소요되는 시간이 실제 코드를 작성하는 것보다 적은 시간이 소요되는 경우에만 유용할 수 있습니다. UML은 시스템 모델링을 위해 만들어졌지만 비즈니스 영역에서 여러 용도를 발견했습니다.

다음은 비즈니스 모델링을 위한 UML 다이어그램의 예입니다.

한 가지 실용적인 솔루션은 활동 다이어그램을 통해 텔레세일을 위한 프로세스 흐름을 시각적으로 나타내는 것입니다. 주문이 입력되는 순간부터 주문이 완료되어 특정 출력이 나오는 순간까지.

UML 다이어그램에는 여러 유형이 있으며 구현 전이나 후에 문서의 일부로 개발되었는지 여부에 관계없이 각각은 서로 다른 작업을 수행합니다. 다른 모든 유형을 다루는 가장 광범위한 두 가지 범주는 행동 다이어그램과 구조 다이어그램입니다. 이름에서 알 수 있듯이 일부 UML 다이어그램은 시스템이나 프로세스의 구조를 분석하고 묘사하려고 시도하는 반면 다른 UML 다이어그램은 시스템, 참가자 및 구성 요소의 동작을 설명합니다.

다양한 유형은 다음과 같이 분류됩니다.

1. 시스템과 아키텍처를 문서화할 때 14가지 다른 유형의 UML 다이어그램이 모두 정기적으로 사용되는 것은 아닙니다.
2. 파레토 원칙은 UML 다이어그램 사용에도 적용됩니다.
3. 다이어그램의 20%는 시간의 80%가 개발자에 의해 사용됩니다.

소프트웨어 개발에서 가장 일반적으로 사용되는 요소는 다음과 같습니다.

• 사용 다이어그램;
• 클래스 다이어그램;
• 시퀀스.

활동 다이어그램 - 비즈니스 프로세스 모델을 생성하기 위한 가장 중요한 UML 다이어그램입니다. 소프트웨어 개발에서 다양한 활동의 ​​흐름을 설명하는 데 사용됩니다. 직렬 또는 병렬이 될 수 있습니다. 그들은 활동에 의해 사용, 소비 또는 생산된 객체와 다른 활동 간의 관계를 설명합니다.

위의 모든 것은 명확한 시작과 끝으로 상호 연결되어 있기 때문에 서로 연결되는 비즈니스 프로세스를 모델링하는 데 필수적입니다. 비즈니스 환경에서는 이를 비즈니스 프로세스 매핑이라고도 합니다. 주요 행위자는 저자, 편집자 및 발행인입니다. UML의 예는 다음과 같습니다. 검토자가 프로젝트를 검토하고 일부 변경이 필요하다고 결정할 때. 그런 다음 작성자는 초안을 검토하고 검토를 분석하기 위해 다시 반환합니다.

사용 다이어그램

시스템의 초석 - 시스템 수준에 대한 요구 사항을 분석하는 데 사용됩니다. 이러한 요구 사항은 다양한 사용 사례로 표현됩니다. UML 다이어그램의 세 가지 주요 구성 요소는 다음과 같습니다.

1. 기능적 - 사용 사례로 제시됩니다.
2. 동작을 설명하는 동사.
3. 액터 - 시스템과 상호 작용합니다. 행위자는 사용자, 조직 또는 외부 클레임일 수 있습니다. 참가자 간의 관계는 직선 화살표로 표시됩니다.

예를 들어, 재고 관리 다이어그램의 경우. 이 경우 소유자, 공급자, 관리자, 재고 전문가 및 재고 검사원이 있습니다. 둥근 컨테이너는 액터가 수행하는 작업을 나타냅니다. 가능한 조치: 주식 구매 및 지불, 주식 품질 확인, 주식 반환 또는 주식 배포.

이 유형의 다이어그램은 시스템 참가자 간의 동적 동작을 표시하는 데 적합하므로 구현 세부 정보를 표시하지 않고도 쉽게 나타낼 수 있습니다.

일시적인

UML 타이밍 다이어그램은 포커스가 시간 종속적일 때 개체 관계를 나타내는 데 사용됩니다. 이 경우 객체가 어떻게 상호 작용하거나 서로 변경되는지는 흥미롭지 않지만 사용자는 객체와 주체가 선형 시간 축을 따라 어떻게 작용하는지 상상하기를 원합니다.

각 개별 참가자는 라이프라인을 통해 표현되며, 이는 개별 참가자가 한 단계에서 다른 단계로 이동할 때 본질적으로 단계를 형성하는 선입니다. 이벤트 기간과 그에 따라 발생하는 변경 사항에 주요주의를 기울입니다.

타이밍 다이어그램의 주요 구성 요소는 다음과 같습니다.

1. 라이프라인은 개인회원입니다.
2. 상태 타임라인 - 유일한 수명 경로는 프로세스 내에서 다른 상태를 통과할 수 있습니다.
3. 기간 제약 - 충족해야 하는 제약의 기간을 나타내는 시간 간격 제약입니다.
4. 시간 제한 - 참가자가 수행해야 하는 시간 간격을 제한합니다.
5. 파괴 출현 - 개별 구성원을 파괴하고 해당 구성원의 수명 주기의 끝을 나타내는 메시지의 출현.

상태 차트라고도 하는 수평 다이어그램은 시스템 내 구성 요소의 다양한 상태를 설명하는 데 사용됩니다. 다이어그램은 본질적으로 개체의 여러 상태와 내부 및 외부 이벤트를 기반으로 변경되는 방식을 설명하는 기계이기 때문에 최종 이름 형식을 사용합니다.

매우 간단한 기계 상태 다이어그램은 체스 게임에 있을 것입니다. 전형적인 체스 게임은 백이 하는 움직임과 흑이 하는 움직임으로 구성됩니다. 흰색이 첫 번째 이동을 갖고 게임을 시작합니다. 게임의 끝은 백인이 이기든 흑인이 이기든 상관없이 일어날 수 있습니다. 게임은 경기, 사임 또는 무승부(자동차의 다른 상태)로 끝날 수 있습니다. Statechart는 주로 다양한 시스템의 정방향 및 역방향 UML 설계에 사용됩니다.

잇달아 일어나는

이러한 유형의 다이어그램은 컴퓨터 과학 커뮤니티뿐만 아니라 비즈니스 응용 프로그램 개발을 위한 디자인 수준 모델로서 가장 중요한 UML 다이어그램입니다. 시각적으로 자명한 특성으로 인해 비즈니스 프로세스를 설명하는 데 널리 사용됩니다. 이름에서 알 수 있듯이 다이어그램은 주제와 개체 간에 발생하는 메시지 및 상호 작용의 순서를 설명합니다. 액터 또는 오브젝트는 필요할 때 또는 다른 오브젝트가 그들과 통신하기를 원할 때만 활성화될 수 있습니다. 모든 통신은 시간순으로 표시됩니다.

자세한 내용은 아래 UML 시퀀스 다이어그램 예제를 참조하십시오.

다음 예에서와 같이 구조 다이어그램을 사용하여 시스템의 구조를 표시합니다. 보다 구체적으로 말하면, 언어는 소프트웨어 개발에서 시스템의 아키텍처와 다양한 구성 요소가 관련되는 방식을 나타내는 데 사용됩니다.

UML 클래스 다이어그램은 소프트웨어 문서화를 위한 가장 일반적인 유형의 다이어그램입니다. 현재 작성 중인 대부분의 소프트웨어는 여전히 객체 지향 프로그래밍 패러다임을 기반으로 하기 때문에 클래스 다이어그램을 사용하여 소프트웨어를 문서화하는 것은 상식입니다. OOP는 UML 클래스와 이들 간의 관계를 기반으로 하기 때문입니다. 간단히 말해서 차트에는 데이터 필드라고도 하는 속성과 멤버 함수라고 하는 해당 동작과 함께 클래스가 포함됩니다.

보다 구체적으로, 각 클래스에는 3개의 필드가 있습니다. 맨 위에는 이름, 이름 바로 아래에는 속성, 맨 아래에는 작업/동작이 있습니다. 서로 다른 클래스 간의 관계(연결선으로 표시됨)는 클래스 다이어그램을 구성합니다. 위의 예는 기본 클래스 다이어그램을 보여줍니다.

사물

UML 구조 다이어그램을 논의할 때 컴퓨터 과학과 관련된 개념을 깊이 파고들 필요가 있습니다. 소프트웨어 공학에서 클래스는 추상 데이터 유형으로 간주되고 객체는 인스턴스로 간주됩니다.예를 들어 일반 추상 유형인 "Car"가 있는 경우 클래스 "Car"의 인스턴스는 "Audi"가 됩니다.

UML 객체 다이어그램은 생성된 추상 구조가 실제로 구현될 때, 즉 객체가 생성될 때 실행 가능한 구조인지 여부를 소프트웨어 개발자가 확인할 수 있도록 도와줍니다. 일부 개발자는 이것을 2차 수준의 정확도 검사로 간주합니다. 클래스 인스턴스를 표시합니다. 더 정확하게 말하면, 제네릭 클래스 "Client"에는 이제 "James"라는 이름의 실제 클라이언트가 있습니다. James는 보다 일반적인 클래스의 인스턴스이며 주어진 값과 동일한 속성을 갖습니다. 계정 및 저축 계정도 마찬가지였습니다. 둘 다 해당 클래스의 객체입니다.

배포

배포 다이어그램은 소프트웨어와 하드웨어 간의 관계를 시각화하는 데 사용됩니다. 더 구체적으로 말하면 배포 다이어그램을 사용하여 소프트웨어 구성 요소(아티팩트)가 노드라고 하는 하드웨어 구성 요소에 배포되는 방식에 대한 물리적 모델을 구축할 수 있습니다.

웹 응용 프로그램에 대한 일반적인 단순화된 배포 체계는 다음과 같습니다.

1. 노드(응용 프로그램 서버 및 데이터베이스 서버).
2. 클라이언트 애플리케이션 및 데이터베이스의 아티팩트 다이어그램.

패키지 다이어그램은 위에서 설명한 배포 UML 다이어그램의 매크로와 유사합니다. 다양한 패키지에는 노드와 아티팩트가 포함됩니다. 네임스페이스가 다소 관련이 있는 다른 이름을 캡슐화하는 것처럼 다이어그램과 모델 구성 요소를 그룹으로 그룹화합니다. 궁극적으로 패키지는 더 복잡한 시스템과 동작을 나타내기 위해 여러 다른 패키지에 의해 생성될 수도 있습니다.

패키지 다이어그램의 주요 목적은 복잡한 시스템을 구성하는 다양한 대형 구성 요소 간의 관계를 보여주는 것입니다. 프로그래머는 이 추상화가 패키지 다이어그램을 사용할 때 특히 일부 세부 정보가 그림에서 제외될 수 있는 경우에 좋은 이점이라는 것을 알게 됩니다.

인생의 다른 모든 일과 마찬가지로 올바른 일을 하려면 올바른 도구가 필요합니다. 소프트웨어, 프로세스 또는 시스템을 문서화하려면 UML 주석 및 다이어그램 템플릿을 제공하는 도구를 사용하십시오. 다이어그램을 그리는 데 도움이 되는 다양한 소프트웨어 문서 도구가 있습니다.

일반적으로 다음과 같은 주요 범주에 속합니다.

1. 종이와 펜은 쉽습니다. 종이와 펜을 잡고 웹에서 UML 구문 코드를 열고 원하는 유형의 다이어그램을 그립니다.
2. 온라인 도구 - 차트를 만드는 데 사용할 수 있는 여러 온라인 응용 프로그램이 있습니다. 대부분은 유료 구독을 제공하거나 프리 티어에서 제한된 수의 다이어그램을 제공합니다.
3. 무료 온라인 도구는 유료 도구와 거의 동일합니다. 주요 차이점은 유료 서비스는 특정 다이어그램에 대한 자습서 및 기성 템플릿도 제공한다는 것입니다.
4. 데스크톱 응용 프로그램 - 다이어그램 및 거의 모든 다른 다이어그램에 사용하는 일반적인 데스크톱 응용 프로그램은 Microsoft Visio입니다. 고급 기능을 제공합니다. 유일한 단점은 비용을 지불해야 한다는 것입니다.

따라서 UML이 객체지향 소프트웨어 개발과 관련된 중요한 측면임은 분명하다. 그래픽 표기법을 사용하여 시스템 프로그램의 시각적 모델을 만듭니다.

UML 다이어그램은 다양한 소프트웨어 개발에서 객체 모델링을 위해 설계된 특수 그래픽 기술 언어입니다. 이 언어는 광범위한 프로필을 가지고 있으며 다양한 그래픽 표기법을 사용하여 시스템의 추상 모델을 생성하는 개방형 표준입니다. UML은 모든 종류의 소프트웨어 시스템의 정의, 시각화, 문서화 및 설계를 가능하게 하기 위해 만들어졌습니다. UML 다이어그램 자체는 프로그래밍 언어가 아니지만 이를 기반으로 별도의 코드를 생성할 수 있는 가능성을 제공한다는 점은 주목할 가치가 있습니다.

그녀가 필요한 이유는 무엇입니까?

UML의 사용은 모든 종류의 소프트웨어를 모델링하는 것으로 끝나지 않습니다. 또한 이 언어는 오늘날 다양한 비즈니스 프로세스를 모델링하고 시스템 설계를 수행하며 조직 구조를 표시하는 데 적극적으로 사용됩니다.

UML의 도움으로 소프트웨어 개발자는 구성 요소, 일반화, 클래스, 동작 및 집계와 같은 일반적인 개념을 나타내는 데 사용되는 그래픽 표기법에서 완전한 동의를 보장할 수 있습니다. 이를 통해 아키텍처와 디자인에 대한 집중도를 높일 수 있습니다.

이러한 차트에는 여러 유형이 있다는 점도 주목할 가치가 있습니다.

클래스 다이어그램

UML 클래스 다이어그램은 시스템 구조를 설명하고 여러 클래스 간의 속성, 메서드 및 종속성을 보여주기 위해 설계된 정적 구조 다이어그램입니다.

사용 방법에 따라 이러한 다이어그램의 구성에 대한 몇 가지 관점이 있다는 사실은 주목할 가치가 있습니다.

• 개념적. 이 경우 UML 클래스 다이어그램은 특정 주제 영역의 모델을 기술하며, 애플리케이션 객체의 클래스만을 제공한다.
• 특정한. 다이어그램은 다양한 정보 시스템을 설계하는 과정에서 사용됩니다.
• 구현. 클래스 다이어그램에는 프로그램 코드에서 직접 사용되는 모든 종류의 클래스가 포함됩니다.

구성 요소 다이어그램

UML 구성 요소 다이어그램은 완전히 정적 구조 다이어그램입니다. 특정 소프트웨어 시스템을 다양한 구조적 구성 요소로 분해하고 이들 간의 관계를 설명하기 위한 것입니다. UML 구성 요소 다이어그램은 모든 종류의 모델, 라이브러리, 파일, 패키지, 실행 파일 및 기타 여러 요소를 사용할 수 있습니다.

복합/복합 구조도

UML 복합/복합 구조 다이어그램도 정적 구조 다이어그램이지만 클래스의 내부 구조를 표시하는 데 사용됩니다. 가능하다면 이 다이어그램은 클래스의 내부 구조에 있는 요소의 상호 작용을 보여줄 수도 있습니다.

이들의 하위 종은 UML 협업 다이어그램으로 협업 범위 내에서 다양한 클래스의 역할과 상호 작용을 시연하는 데 사용됩니다. 디자인 패턴을 모델링해야 하는 경우 매우 편리합니다.

UML 클래스 다이어그램과 복합 구조 다이어그램을 동시에 사용할 수 있다는 점은 주목할 가치가 있습니다.

배포 다이어그램

이 다이어그램은 실행 중인 노드와 해당 노드에 배포된 모든 종류의 아티팩트를 모델링하는 데 사용됩니다. UML 2에서는 아티팩트가 다양한 노드에 배포되지만 첫 번째 버전에서는 구성 요소만 배포되었습니다. 따라서 UML 배포 다이어그램은 주로 두 번째 버전에 사용됩니다.

아티팩트와 아티팩트가 구현하는 구성 요소 간에 표현 종속성이 형성됩니다.

개체 다이어그램

이 보기를 사용하면 특정 시점에 생성되는 시스템의 전체 또는 부분 스냅샷을 볼 수 있습니다. 특정 시스템 클래스의 모든 인스턴스를 완전히 표시하여 해당 매개변수의 현재 값과 이들 간의 관계를 나타냅니다.

패키지 다이어그램

이 다이어그램은 본질적으로 구조적이며 주요 내용은 모든 종류의 패키지와 패키지 간의 관계입니다. 이 경우 여러 구조 다이어그램 사이에 엄격한 분리가 없으므로 그 사용은 편의상 가장 자주 사용되며 의미 론적 의미를 갖지 않습니다. 다른 요소가 다른 UML 다이어그램을 제공할 수 있다는 점은 주목할 가치가 있습니다(예: 패키지 및 패키지 다이어그램 자체).

구조를 단순화하고이 시스템 모델로 작업을 구성하기 위해 특정 속성에 따라 여러 요소를 그룹으로 구성하기 위해 사용합니다.

활동도

UML 활동 다이어그램은 특정 활동을 여러 구성 요소 부분으로 분해한 것을 표시합니다. 이 경우 "활동"의 개념은 병렬 형태의 특정 실행 가능한 동작의 사양을 의미하며, 다음에서 이동하는 흐름으로 통합되는 중첩된 유형의 활동 및 다양한 작업과 같은 다양한 하위 요소의 조정된 순차적 실행을 나타냅니다. 특정 노드의 출력을 다른 노드의 입력으로.

UML 활동 다이어그램은 다양한 비즈니스 프로세스, 병렬 및 순차 컴퓨팅을 모델링하는 데 자주 사용됩니다. 무엇보다도 그들은 모든 종류의 기술 절차를 모델링합니다.

오토마톤 다이어그램

이 보기는 UML 상태 다이어그램이라고 하며 약간 다릅니다. 단순 및 복합 상태와 전환이 있는 상태 머신을 제공합니다.

상태 기계는 특정 개체가 통과하는 일련의 다른 상태 또는 수명의 일부 이벤트에 대한 응답으로 상호 작용 및 이러한 이벤트에 대한 개체의 응답에 대한 사양입니다. UML 상태 다이어그램이 사용하는 상태 머신은 원래 요소에 연결되어 해당 인스턴스의 동작을 정의하는 데 사용됩니다.

소위 드래곤 다이어그램은 그러한 다이어그램의 유사체로 사용될 수 있습니다.

사용 사례 다이어그램

UML 유스 케이스 다이어그램은 액터와 다양한 유스 케이스 사이에서 발생하는 모든 관계를 표시합니다. 주요 임무는 고객, 최종 사용자 또는 일부 개발자가 특정 시스템의 동작과 기능에 대해 공동으로 논의할 수 있는 본격적인 수단을 제공하는 것입니다.

UML 사용 사례 다이어그램이 시스템 모델링 프로세스에서 사용되는 경우 분석가는 다음을 수행합니다.

• 모델링 중인 시스템을 환경과 명확하게 분리합니다.
• 행위자, 이 시스템과의 상호 작용 방식 및 예상 기능을 식별합니다.
• 이 시스템의 기능에 대한 자세한 설명과 관련된 다양한 개념을 주제 영역으로 용어집에 설정합니다.

UML에서 사용 다이어그램이 개발 중인 경우 절차는 고객과 작업할 때 얻은 텍스트 설명으로 시작됩니다. 동시에 유스케이스 모델을 컴파일하는 과정에서 다양한 비기능적 요구사항이 완전히 생략되고 이에 대한 별도의 문서가 이미 형성되어 있다는 점에 유의할 필요가 있다.

연락

커뮤니케이션 다이어그램은 UML 시퀀스 다이어그램과 마찬가지로 전이적입니다. 즉, 상호 작용을 표현하지만 동시에 다른 방식으로 보여주며 필요한 경우 필요한 정확도로 다음으로 변환할 수 있습니다. 또 다른.

커뮤니케이션 다이어그램은 복합 구조의 다양한 요소 사이에서 발생하는 상호 작용과 협력의 역할을 반영합니다. 시퀀스 다이어그램과의 가장 큰 차이점은 여러 요소 간의 관계를 명확하게 나타내고 시간을 별도의 차원으로 사용하지 않는다는 것입니다.

이 유형은 개체 다이어그램에서 수행되는 것과 동일한 방식으로 여러 개체 및 관계를 정렬하는 절대적으로 자유로운 형식으로 구별됩니다. 이 자유 형식으로 메시지 순서를 유지해야 하는 경우 시간순으로 번호가 매겨집니다. 이 다이어그램의 읽기는 초기 메시지 1.0에서 시작하여 한 개체에서 다른 개체로 메시지가 전송되는 방향으로 계속됩니다.

대부분의 경우 그러한 다이어그램은 시퀀스 다이어그램이 우리에게 제공하는 것과 정확히 동일한 정보를 보여주지만 정보를 표시하는 다른 방법을 사용하기 때문에 한 다이어그램의 특정 항목이 다른 다이어그램보다 훨씬 더 쉽게 결정할 수 있습니다. 또한 커뮤니케이션 다이어그램은 각 개별 요소가 상호 작용하는 요소를 보다 명확하게 보여 주는 반면 시퀀스 다이어그램은 상호 작용이 수행되는 순서를 보다 명확하게 보여줍니다.

시퀀스 다이어그램

UML 시퀀스 다이어그램은 발생 시간에 따라 정렬된 여러 개체 간의 상호 작용을 보여줍니다. 이러한 다이어그램은 여러 개체 간의 시간 순서 상호 작용을 보여줍니다. 특히 상호 작용에 참여하는 모든 개체와 교환된 메시지의 전체 순서를 표시합니다.

이 경우 주요 요소는 다양한 대상의 지정뿐만 아니라 시간의 흐름을 나타내는 세로선과 특정 대상의 활동 또는 특정 대상에 의한 일부 기능의 성능을 나타내는 직사각형입니다.

협력도

이 유형의 다이어그램을 사용하면 메시지 번역 시퀀스에서 추상화하여 여러 개체 간의 상호 작용을 표시할 수 있습니다. 압축된 형식의 이러한 유형의 다이어그램은 특정 개체의 전송 및 수신된 모든 메시지와 이러한 메시지의 형식을 절대적으로 표시합니다.

시퀀스 다이어그램과 통신 다이어그램은 단순히 동일한 절차의 다른 보기이기 때문에 Rational Rose는 시퀀스 다이어그램에서 또는 그 반대로 통신 시퀀스 다이어그램을 생성하는 기능을 제공하고 완전히 자동으로 동기화합니다.

상호 작용 개요 다이어그램

이들은 활동 다이어그램 유형에 속하며 시퀀스 요소와 제어 흐름 구성을 모두 포함하는 UML 다이어그램입니다.

이 형식은 서로 다른 관점에서 형성되는 시스템의 여러 개체 간의 상호 작용을 고려할 수 있는 기회를 제공하는 협업 및 시퀀스 다이어그램을 결합한다는 사실에 주목할 가치가 있습니다.

타이밍 다이어그램

특정 시간 척도로 수명선의 상태 변화를 명시적으로 보여주는 시퀀스 다이어그램의 대체 버전을 나타냅니다. 다양한 실시간 애플리케이션에서 매우 유용할 수 있습니다.

혜택은 무엇입니까?

UML 사용 다이어그램과 다른 것들을 구별하는 몇 가지 장점은 주목할 가치가 있습니다.

• 언어는 객체 지향적이며, 그 결과 수행된 분석 및 설계 결과를 설명하는 기술이 모든 종류의 현대적 객체 지향 언어의 프로그래밍 방법에 의미적으로 가깝습니다.
• 이 언어를 사용하면 거의 모든 가능한 관점에서 시스템을 설명할 수 있으며 동작의 다양한 측면도 같은 방식으로 설명합니다.
• 모든 다이어그램은 구문에 비교적 빨리 익숙해진 후에도 비교적 읽기 쉽습니다.
• UML을 사용하면 확장할 수 있을 뿐만 아니라 자신의 그래픽 및 텍스트 스테레오타입을 도입할 수 있으므로 소프트웨어 엔지니어링뿐만 아니라 UML의 사용에 기여합니다.
• 이 언어는 상당히 널리 보급되었으며 상당히 활발하게 발전하고 있습니다.

결점

UML 다이어그램의 구성에는 많은 장점이 있음에도 불구하고 다음과 같은 단점으로 인해 종종 비판을 받습니다.

• 중복성. 대부분의 경우 비평가들은 UML이 너무 크고 복잡하며 종종 이것이 정당하지 않다고 말합니다. 여기에는 중복되거나 거의 쓸모없는 구성과 다이어그램이 많이 포함되어 있으며, 이러한 비판은 첫 번째 버전이 아닌 두 번째 버전으로 가는 경우가 가장 많습니다. 왜냐하면 최신 개정판에는 "위원회가 설계한" 절충안이 더 많기 때문입니다.
• 의미론의 다양한 부정확성. UML은 그 자체와 영어, OCL의 조합으로 정의되기 때문에 형식적 서술기법으로 정확하게 정의되는 언어 고유의 강성이 부족하다. 특정 상황에서 OCL, UML 및 영어의 추상 구문은 서로 모순되기 시작하지만 다른 경우에는 불완전합니다. 언어 자체에 대한 설명의 부정확성은 사용자와 도구 제공자 모두에게 영향을 미치고 결국 다른 사양이 처리되는 고유한 방식으로 인해 도구 비호환성을 초래합니다.
• 구현 및 연구 과정의 문제. 위의 모든 문제는 UML을 구현하고 학습하는 과정에서 특정 어려움을 야기하며, 특히 경영진이 엔지니어에게 사전 기술이 부족할 때 UML을 사용하도록 강요할 때 그렇습니다.
• 코드는 코드를 반영합니다. 또 다른 의견은 아름답고 매력적인 모델이 중요한 것이 아니라 직접 작동하는 시스템, 즉 코드가 프로젝트라는 것입니다. 이 견해에 따르면 소프트웨어를 작성하는 보다 효율적인 방법을 개발할 필요가 있습니다. UML은 실행 파일 또는 소스 코드를 재생성하기 위해 모델을 컴파일하는 접근 방식에서 가치가 있습니다. 그러나 실제로는 언어가 Turing 완전성 속성이 부족하고 생성된 각 코드가 결국 UML 해석 도구가 가정하거나 결정할 수 있는 것에 의해 제한되기 때문에 이것이 충분하지 않을 수 있습니다.
• 로드 불일치. 이 용어는 특정 시스템의 입력이 다른 시스템의 출력을 인식할 수 없음을 결정하기 위한 시스템 분석 이론에서 유래했습니다. 다른 표준 표기법과 마찬가지로 UML은 특정 시스템을 다른 것보다 더 효율적이고 간결하게 나타낼 수 있습니다. 따라서 개발자는 다른 프로그래밍 언어뿐만 아니라 UML의 모든 장점을 짜기에 더 편안한 솔루션을 선호합니다. 이 문제는 개발 언어가 객체 지향 정통 교리의 주요 원칙에 부합하지 않는 경우, 즉 OOP의 원칙에 따라 작동하려고 하지 않는 경우 더욱 분명합니다.
• 보편성을 추구합니다. UML은 현재 존재하는 모든 처리 언어와 호환되는 범용 모델링 언어입니다. 특정 프로젝트의 맥락에서 디자인 팀이 최종 목표를 달성하기 위해서는 이 언어의 적용 가능한 기능을 선택하는 것이 필요합니다. 또한 특정 영역에서 UML의 사용 범위를 제한하는 가능한 방법은 완전히 공식화되지는 않았지만 그 자체가 비판의 대상이 되는 형식주의를 거칩니다.

따라서 이 언어의 사용이 모든 상황과 관련이 있는 것은 아닙니다.