uml 다이어그램을 만드는 방법. UML 언어의 일반적인 특성

UML(Unified Modeling Language - 통합 모델링 언어) - 소프트웨어 개발 분야의 개체 모델링을 위한 그래픽 설명 언어입니다. UML은 일반 언어로, 그래픽 표기법을 사용하여 UML 모델이라고 하는 시스템의 추상 모델을 생성하는 개방형 표준입니다. UML은 대부분 소프트웨어 시스템을 정의, 시각화, 설계 및 문서화하기 위해 만들어졌습니다. UML은 프로그래밍 언어가 아니지만 해석된 코드로 UML 모델용 런타임 도구에서 코드 생성이 가능합니다.위키피디아

상업용 제품

마이크로소프트 비지오

유형: 상용 소프트웨어

UML을 포함하여 풍부한 다이어그램을 그릴 수 있는 Microsoft의 인기 있는 소프트웨어 제품:

2010 버전부터 웹(SharePoint + Visio Services)에 다이어그램을 게시할 수 있게 되었습니다.

비지오 뷰어- 이전에 만든 Visio 다이어그램을 볼 수 있는 무료 프로그램입니다. %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20에서 다운로드할 수 있습니다.

%0A

마이크로소프트%20비주얼%20스튜디오%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20익스프레스%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20모델링,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20시퀀스%20다이어그램%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20사용%20케이스%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20비주얼%20스튜디오%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20다이어그램

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20시각화%20and%20모델링%20기능%20팩%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM 합리적인 로즈

기회:

유스 케이스 다이어그램(선례의 다이어그램);
배포 다이어그램(토폴로지 다이어그램);
Statechart 다이어그램(상태 다이어그램);
활동 다이어그램(활동 다이어그램);
상호작용 다이어그램(상호작용 다이어그램);
시퀀스 다이어그램(동작 시퀀스 다이어그램);
협업 다이어그램(협업 다이어그램);
클래스 다이어그램(클래스 다이어그램);
구성 요소 다이어그램(구성 요소 다이어그램).

스크린샷:

오픈 소스 프로그램

스타UML

기회:

UML 2.0 지원
MDA(모델 기반 아키텍처)
플러그인 아키텍처(COM 호환 언어로 작성할 수 있습니다: C++, Delphi, C#, VB, ...)

StarUML은 주로 Delphi로 작성되지만 C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET과 같은 다른 언어로도 구성 요소를 추가할 수 있습니다. 아래는 일부 스크린샷입니다.

클래스 다이어그램:

사용 사례 다이어그램:

아르고UML

지원되는 차트:

등급
상태
사용 사례
활동
협동
전개
순서

기회:

9개의 UML 1.4 다이어그램 지원
플랫폼 독립적(Java 5+)
UML 1.4 표준 메타모델
XMI 지원
GIF, PNG, PS, EPS, PGML 및 SVG로 내보내기
언어: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
OCL 지원
포워드, 리버스 엔지니어링

스크린샷:

UML 모델(UML 모델)은 유한한 언어 구성 집합의 집합이며, 그 주요 집합은 엔터티와 이들 간의 관계입니다.

모델 자체의 엔터티와 관계는 메타모델의 메타클래스 인스턴스입니다.

가장 일반적인 위치에서 UML 모델을 고려하면 정점과 가장자리에 추가 정보가 로드되고 복잡한 내부 구조를 가질 수 있는 그래프(더 정확하게는 로드된 다중 의사 하이퍼 다이그래프)라고 말할 수 있습니다. . 이 그래프의 꼭짓점을 엔터티라고 하고 가장자리를 관계라고 합니다.. 섹션의 나머지 부분에서는 사용 가능한 엔터티 유형 및 관계에 대한 빠르고(예비적) 완전한 개요를 제공합니다. 운 좋게도 그 수가 너무 많지 않습니다. 이 책의 다음 장에서는 모든 엔터티와 관계를 더 자세히 그리고 예제와 함께 다시 고려합니다.

1.4.1. 에센스

개요의 편의를 위해 UML의 엔터티는 네 그룹으로 나눌 수 있습니다.

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

구조적 개체는 짐작할 수 있듯이 구조를 설명하기 위한 것입니다. 일반적으로 구조 엔티티에는 다음이 포함됩니다.

객체(객체) 1은 고유성을 가지며 상태와 행동을 캡슐화하는 개체입니다.

등급(class) 2 - 행동을 정의하는 동작과 상태를 정의하는 공통 속성을 가진 객체 세트에 대한 설명.

상호 작용(인터페이스) 3은 소비자가 요청할 수 있고 서비스 공급자가 제공할 수 있는 서비스 집합을 정의하는 명명된 작업 집합입니다.

협력(협업) 4 - 어떤 목표를 달성하기 위해 상호 작용하는 개체 집합입니다.

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

∇ 그러한 관계는 분명히 존재하며, 이는 그림 1과 같다. UML 1의 다이어그램 유형 계층"세련" 고정 관념과의 종속 관계로.

∇∇ UML 1에서는 협업 다이어그램과 동일한 이름의 엔터티 사이에 비자발적인 연관이 있었는데, 이는 완전히 사실이 아니며 때로는 오해의 소지가 있습니다.

∇∇∇ UML 2에서는 상태 다이어그램의 구문 및 의미 로드가 너무 많이 변경되어 이름에 더 이상 내용이 반영되지 않습니다.

이 책에서 채택한 새로운 다이어그램과 그 이름은 다음과 같습니다.

복합 구조 다이어그램
패키지 다이어그램
상태 머신 다이어그램
통신 다이어그램
상호 작용 개요 다이어그램
타이밍 다이어그램

무화과에. UML 2의 다이어그램 유형 계층 구조(1부 및 2부) UML 2에서 다이어그램의 관계를 보여주는 클래스 다이어그램.

이 장의 뒷부분에서 다음 내용에 대한 컨텍스트와 어휘를 확보하기 위해 13개의 모든 표준 다이어그램을 매우 간략하게 설명합니다. 자세한 내용은 책의 나머지 장에서 설명합니다.

그러나 다음 섹션으로 이동하기 전에 표준에서 차트 형식을 지정해야 하는 방법에 대해 간단히 설명하겠습니다. 일반 차트 프레젠테이션 템플릿은 다음과 같습니다.

두 가지 주요 디자인 요소가 있습니다. 외부 프레임과 차트 이름이 있는 레이블입니다. 모든 것이 프레임으로 단순하다면 다이어그램의 요소가 위치해야 하는 영역을 경계로 하는 직사각형이며 다이어그램의 이름은 그림 4에 표시된 특수 형식으로 작성됩니다. 차트 표기법.

이 복잡한 탭 모양은 일부 도구에서 지원되지 않습니다. 그러나 의미론이 1차이고 표기가 2차이기 때문에 이것은 필요하지 않습니다. 다음 내용에서는 전체적으로 차트 레이블로 직사각형을 사용하며 이로 인해 오해가 발생하지 않아야 합니다.

차트에 사용할 수 있는 태그(유형)는 다음 표에 나와 있습니다. 표준에서 제공하는 태그는 두 번째 열에 작성됩니다. 그러나 실습에서 알 수 있듯이 표준에서 제안한 규칙이 항상 편리하고 논리적으로 정당화되는 것은 아니므로 표의 세 번째 열에 합리적인 대안이 포함되어 있다고 생각합니다.

탭. 차트 유형 및 태그

차트 이름	태그(표준)	태그(권장)
사용 다이어그램	사용 사례또는 UC	사용 사례
클래스 다이어그램	등급	등급
오토마톤 다이어그램	상태 머신또는 stm	상태 머신
활동도	활동또는 행동	활동
시퀀스 다이어그램	상호 작용또는 SD	SD
커뮤니케이션 다이어그램	상호 작용또는 SD	통신
구성 요소 다이어그램	요소또는 cmp	요소
배치 다이어그램	정의되지 않은	전개
개체 다이어그램	정의되지 않은	물체
내부 구조도	등급	등급또는 요소
상호 작용 개요 다이어그램	상호 작용또는 SD	상호 작용
타이밍 차트	상호 작용또는 SD	타이밍
패키지 다이어그램	패키지또는 패키지	패키지

"라는 말은 누구나 어릴 적에 들어본 것 같다. 7회 측정 컷 1회". 프로그래밍에서는 동일합니다. 실행에 시간을 보내기 전에 구현에 대해 생각하는 것이 항상 더 좋습니다. 종종 구현 중에 클래스를 생성하고 상호 작용을 생각해 내야 합니다. 그리고 종종 이것을 시각적으로 표현하면 문제를 해결하는 데 도움이 됩니다. 가장 정확한 방법으로 문제를 해결합니다. UML.

UML이란 무엇입니까?

검색 엔진에 있는 사진을 보면 명확해집니다. UML- 이것은 계획, 화살표 및 사각형에 관한 것입니다. 중요한 것은 UML이 다음과 같이 번역된다는 것입니다. 통합 모델링 언어. 여기서 통일이라는 단어가 중요합니다. 즉, 우리 사진은 우리뿐만 아니라 UML을 아는 다른 사람들도 이해할 수 있습니다. 이것은 다이어그램을 그리기 위한 국제 언어임이 밝혀졌습니다.

위키피디아에서 말했듯이

UML은 소프트웨어 개발, 비즈니스 프로세스 모델링, 시스템 엔지니어링 및 조직 구조 매핑 분야의 개체 모델링을 위한 그래픽 설명 언어입니다.

모든 사람이 생각하거나 추측하지 않는 가장 흥미로운 점은 UML에 사양이 있다는 것입니다. 또한 UML2 사양도 있습니다. 사양에 대한 자세한 내용은 개체 관리 그룹 웹 사이트에서 찾을 수 있습니다. 실제로 이 그룹은 UML 사양 개발에 참여하고 있습니다. UML이 클래스 구조를 기술하는 데 국한되지 않는다는 점도 흥미롭습니다. UML 다이어그램에는 여러 유형이 있습니다. UML 다이어그램 유형에 대한 간략한 설명은 동일한 Wikipedia: UML 다이어그램 또는 Timur Batyrshinov의 비디오에서 볼 수 있습니다. UML 다이어그램 개요. UML은 다양한 프로세스를 설명하는 데에도 널리 사용됩니다. 예를 들면 다음과 같습니다. JWT를 사용한 싱글 사인온. UML 클래스 다이어그램의 사용으로 돌아가서 동일한 UML 다이어그램으로 패턴을 설명하는 책 Head First: Design Patterns에 주목할 가치가 있습니다. UML이 실제로 사용되고 있는 것으로 나타났습니다. 그리고 그 적용을 알고 이해하는 것은 꽤 유용한 기술이라는 것이 밝혀졌습니다.

애플리케이션

IDE에서 바로 이 UML로 작업하는 방법을 살펴보겠습니다. IDE로 IntelliJ 아이디어. 사용하는 경우 IntelliJ 아이디어 궁극, 그러면 플러그인이 "즉시" 설치됩니다. UML 지원". 아름다운 클래스 다이어그램을 자동으로 생성할 수 있습니다. 예를 들어 Ctrl + N 또는 메뉴 항목 "Navigate" -> "Class"를 통해 클래스로 이동 배열 목록. 이제 클래스 이름의 컨텍스트 메뉴를 통해 "다이어그램" -> "다이어그램 팝업 표시"를 선택합니다. 결과적으로 우리는 아름다운 차트를 얻습니다.

하지만 자신을 그리고 싶은데 Ultimate 버전의 Idea가 없는 경우에는 어떻게 하시겠습니까? IntelliJ Idea Community Edition을 사용하고 있다면 다른 선택의 여지가 없습니다. 이를 위해서는 이러한 UML 체계가 어떻게 작동하는지 이해해야 합니다. 먼저 Graphviz를 설치해야 합니다. 그래프 시각화 유틸리티 세트입니다. 우리가 사용할 플러그인에서 사용합니다. 설치 후 디렉토리를 추가해야 합니다. 큰 상자설치된 디렉토리에서 그래프비즈환경 변수에 길. 그런 다음 IntelliJ Idea의 메뉴에서 파일 -> 설정을 선택합니다. "설정" 창에서 "플러그인" 카테고리를 선택하고 "저장소 찾아보기" 버튼을 클릭하고 PlantUML 통합 플러그인을 설치합니다. 이게 왜이렇게 좋은거야 플랜트UML? "라는 그래프 설명 언어를 사용합니다. 점" 이 언어는 PlantUML 뿐만 아니라 이 언어를 사용하기 때문에 보다 보편적일 수 있습니다. 또한 아래에서 수행할 모든 작업은 IDE뿐만 아니라 planttext.com 온라인 서비스에서도 수행할 수 있습니다. 설치 후 PlantUML 플러그인을 사용하면 "File" -> "New"를 통해 UML 다이어그램을 생성할 수 있습니다. "UML 클래스" 유형의 다이어그램을 생성해 보겠습니다. 이 동안 예제가 포함된 템플릿이 자동으로 생성됩니다. 내용을 삭제하고 Habr: Class Relations - UML에서 코드까지... 그리고 이것을 텍스트에서 설명하는 방법을 이해하기 위해 PlantUML 매뉴얼: plantuml class-diagram...을 살펴보겠습니다. 아주 처음에는 관계를 설명하는 방법에 대한 표시가 있습니다.

연결 자체에 대해서는 "UML의 클래스 간 관계. 예"에서 여전히 엿볼 수 있습니다. 이 자료를 기반으로 UML 다이어그램을 작성해 보겠습니다. 두 클래스를 설명하는 다음 내용을 추가하십시오. @startuml class ArrayList ( ) class LinkedList ( ) @enduml Idea에서 결과를 보려면 "보기" -> "도구 창" -> "PlantUML"을 선택하십시오. 클래스를 나타내는 두 개의 사각형만 얻을 것입니다. 알다시피, 이 두 클래스는 모두 List 인터페이스를 구현합니다. 이러한 클래스 관계를 구현(실현)이라고 합니다. 점선이 있는 화살표는 이러한 관계를 나타내는 데 사용됩니다. 그리자: 인터페이스 목록 목록< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о 패키지 개인 element array: ~ Object elementData 이제 ArrayList에 일부 객체가 포함되어 있음을 보여주고자 합니다. 이 경우 연결 유형은 - 집합(집합). 이 경우 집계는 ArrayList 입니다. 왜냐하면 다른 개체를 포함합니다. 목록의 개체가 목록 없이도 살 수 있기 때문에 집계를 선택합니다. 목록의 필수 부분이 아닙니다. 그들의 수명은 목록의 수명과 관련이 없습니다. 라틴어의 단위는 "수집된", 즉 무언가로 구성된 것으로 번역됩니다. 예를 들어, 인생에는 펌프와 엔진으로 구성된 펌핑 장치가 있습니다. 장치 자체를 분해하여 일부 구성 요소를 남길 수 있습니다. 예를 들어, 다른 단위를 판매하거나 넣습니다. 그래서 목록에 있습니다. 그리고 이것은 단위에서 빈 마름모와 연속선의 형태로 표현됩니다. 클래스 Object ( ) ArrayList o- Object 이제 ArrayList 와 달리 LinkedList 클래스에는 저장된 데이터를 참조하는 Node 컨테이너가 포함되어 있음을 보여주고자 합니다. 이 경우 노드는 LinkedList 자체의 일부이며 별도로 존재할 수 없습니다. 노드는 직접 저장된 콘텐츠가 아니라 참조만 포함합니다. 예를 들어 LinkedList에 행을 추가할 때 이 행에 대한 링크와 이전 및 다음 Node에 대한 링크가 포함된 새 Node 를 추가합니다. 이러한 연결 유형을 구성(구성). 합성물(부분으로 구성된 합성물)을 표시하기 위해 채워진 로빅이 그려지고 연속선이 이어집니다. 이제 이것을 링크의 텍스트 표시로 작성해 보겠습니다. class Node ( ) LinkedList * -- Node 이제 또 다른 중요한 유형의 링크를 표시하는 방법을 배워야 합니다. 탐닉(종속 관계). 한 클래스가 다른 클래스를 사용할 때 사용되지만 해당 클래스는 사용된 클래스를 포함하지 않고 후속 클래스가 아닙니다. 예를 들어 LinkedList 및 ArrayList는 ListIterator를 만들 수 있습니다. 이것을 점선 화살표로 표시해 보겠습니다. class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

필요한 만큼 자세히 설명할 수 있습니다. 모든 명칭은 "PlantUML - 클래스 다이어그램"에 나열되어 있습니다. 또한 그러한 계획을 그리는 데 초자연적 인 것은 없으며 작업을 수행 할 때 손으로 빠르게 그릴 수 있습니다. 이것은 애플리케이션 아키텍처 사고 능력을 개발하고 잘못된 모델을 구현하는 데 이미 하루를 보낸 후에가 아니라 조기에 클래스 구조 결함을 발견하는 데 도움이 됩니다. 시도해 볼 좋은 이유라고 생각합니다.)

오토메이션

PlantUML 다이어그램을 자동으로 생성하는 다양한 방법이 있습니다. 예를 들어, 아이디어 SketchIT 플러그인이 있지만 올바르게 그려지지 않습니다. 예를 들어, 인터페이스 구현이 잘못 그려집니다(상속으로 표시됨). 이를 프로젝트의 빌드 라이프 사이클에 구축하는 방법에 대한 온라인 예제도 있습니다. 에 대해 말해보자 메이븐 uml-java-docklet 을 사용하는 예가 있습니다. 이것이 어떻게 수행되는지 보여주기 위해 Maven Archetype을 사용하여 Maven 프로젝트를 빠르게 생성해 보겠습니다. 다음 명령을 실행해 보겠습니다. mvn archetype:generate 필터 선택에 대한 질문( 번호 선택 또는 필터 적용) Enter 키를 눌러 기본값을 그대로 둡니다. 언제나 그럴거야" maven-archetype-빠른 시작". 최신 버전을 선택합니다. 다음으로 질문에 답하고 프로젝트 생성을 완료합니다.

Maven은 이 기사의 초점이 아니므로 Maven에 대한 질문에 대한 답변은 Maven 사용자 센터에서 찾을 수 있습니다. 생성된 프로젝트에서 편집을 위해 프로젝트 설명 파일을 열고, pom.xml. uml-java-docklet 설치 설명에서 내용을 복사합니다. 설명에 사용된 아티팩트는 Maven Central 저장소에서 찾을 수 없습니다. 그러나 그것은 나를 위해 일했습니다 : https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . 즉, 해당 설명에서 그룹 ID와 함께 " 정보.리딩라이트"에" com.chfourie"하고 버전을 넣어" 1.0.0 ". 그 후에 파일이 위치한 디렉토리에서 실행할 수 있습니다. pom.xml이러한 명령은 mvn clean install 및 mvn javadoc:javadoc 입니다. 이제 생성된 문서(탐색기 target\site\apidocs\index.html)를 열면 UML 다이어그램이 표시됩니다. 그건 그렇고, 구현은 이미 여기에 올바르게 표시됩니다)

결론

보시다시피 UML을 사용하면 애플리케이션의 구조를 시각화할 수 있습니다. 또한 UML은 이에 국한되지 않습니다. UML을 사용하여 회사 내의 다양한 프로세스를 설명하거나 작성한 기능이 작동하는 비즈니스 프로세스를 설명할 수 있습니다. UML이 얼마나 유용한지는 개인적으로 결정하는 것은 당신에게 달려 있지만, 어쨌든 시간을 찾고 더 자세히 알아가는 것이 도움이 될 것입니다. 이 게시물의 #Viacheslav 러시아어 버전: CodeGym의 UML 다이어그램 Java

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

사용 다이어그램

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

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

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

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

일시적인

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

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

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

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

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

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

잇달아 일어나는

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

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

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

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

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

사물

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

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

배포

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

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

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

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

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

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

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

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

따라서 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

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

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

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