자유 배치
괄호 다이어그램
UML(Unified Modeling Language)은 소프트웨어 시스템 아티팩트를 설명, 시각화, 구성 및 문서화하는 데 사용되는 범용 시각적 모델링 언어 표준입니다.
언어에 관해서라면 많은 친구들이 두려움을 느끼기 시작합니다. SQL, Java, C#, PHP 등의 언어가 마음속에 떠다니기도 하고 , 많은 사람들을 겁나게 할 수도 있습니다 .
다양한 프로그래밍 언어
그러나 UML은 프로그래밍 언어가 아니라 시각적 모델링 언어입니다. 언어라고 부르는 이유는 UML이 의사소통을 위한 어휘와 규칙을 제공하기 때문입니다. 사용자는 이러한 어휘와 규칙의 틀 안에서 동일한 소프트웨어로 의사소통을 할 수 있어 다양한 사용자가 동일한 것을 동일하게 이해할 수 있습니다.
1960년대 후반 이후 컴퓨터 기술의 지속적인 대중화와 함께 소프트웨어에 대한 사람들의 수요는 나날이 증가하고 있으며, 소프트웨어의 규모도 확대되고, 소프트웨어의 복잡성도 증가하고 있다. 과학적 이론적 지침이 부족하여 소프트웨어 개발의 진행을 보장하기 어렵고, 소프트웨어 개발 비용은 지속적으로 상승하며, 품질을 보장할 수 없는 소프트웨어의 경우 더욱 악화됩니다. 소프트웨어 유지 관리를 매우 번거롭게 만듭니다. 사람들은 이를 소프트웨어 위기라고 생생하게 부릅니다.
무엇을 해야 할까요? 그러면 소프트웨어 개발 작업은 프로젝트로 이루어져야 합니다. 따라서 소프트웨어 공학이라는 개념도 등장했습니다. 소프트웨어 공학은 소프트웨어 생산의 객관적인 법칙을 연구하고 소프트웨어 생산 활동을 안내하는 소프트웨어 생산에 대한 관련 개념, 원칙, 방법, 기술 및 도구를 확립하는 것을 목표로 합니다. 물론 결과는 만족스러웠습니다.
소프트웨어 공학에 대한 사람들의 연구가 지속적으로 심화됨에 따라 객체 지향 프로그래밍이 사람들의 시야에 들어왔습니다. 1980년대부터 1990년대 초반까지 수많은 객체지향 분석과 설계 방법이 탄생했고, 객체지향 방법을 소개하는 책도 대거 등장했다. 이것은 마치 수백 개의 학파가 경쟁하는 것처럼 느껴집니다. 각 저자는 실무자 그룹을 이끌고 있으며 방법은 유사점이 많지만 미묘한 차이점도 있습니다.
이는 같은 분야에 종사하는 실무자들에게도 혼란을 가져오며, 같은 것을 이야기할 때 객체지향적인 표현 방식이 다르기 때문에 같은 것에 대한 이해와 소통을 심각하게 방해하게 됩니다.
이때 누군가가 동일한 기준을 통일하여 사용하자고 제안했습니다. 아무도 그의 부름을 듣지 못하고 그를 무시하는 것 같았습니다. OMG(Object Management Group)라는 조직도 객체 지향 표준화를 시도했지만 모든 방법론자들로부터 단 한 건의 공개 항의 서한만 받았습니다.
Martin Fowler가 이 상황에 대해 이야기할 때 그는 자신의 저서 "UML Essentials: A Concise Guide to the Standard Object Modeling Language"에서 다음과 같은 농담을 했습니다.
A: 방법론자와 테러리스트의 차이점은 무엇입니까?
B: 테러리스트들은 협상할 수 있어요.
객체지향 표현 방법에는 큰 차이가 있습니다.
1995년 OOPSLA(객체 지향 프로그래밍 시스템, 언어 및 응용 프로그램) 연례 회의에서 Grady Booch와 Jim Rumbaugh는 통합 접근 방식인 통합 방법 문서 0.8(United Method)을 처음으로 공개적으로 설명했습니다.
여러 당사자 간의 일련의 경쟁 끝에 1997년 1월 모든 조직이 방법 표준에 대한 제안서를 제출했습니다. Rational은 다른 조직과 협력하여 UML 문서 버전 1.0을 출시했습니다. 이는 통합 모델링이라고 불리는 최초의 사례이기도 합니다. 언어.
경쟁 과정을 거쳐 OMG는 버전 1.1을 공식 OMG 표준으로 채택했습니다. 일련의 수정을 거쳐 UML1.4와 UML1.5는 상대적으로 성숙해졌습니다. 예를 들어 Rational Rose 2003은 이러한 표준을 기반으로 개발되었습니다.
많은 사람들이 UML에 대해 이야기할 때 주로 Grady Booch, Ivar Jacobson 및 Jim Rumbaugh를 제작자의 공로로 여기며 그들을 "세 명의 친구"라고 부릅니다.
물론 초기에는 자신들이 어느 정도 공헌을 했다고 반대를 표하고 믿는 사람들도 있었지만 후반에는 OMG 위원들이 많은 공헌을 했고, 그 세 사람 중 유일하게 공헌을 한 사람이 짐 럼보뿐이었다. 나중 단계에서.
방법 및 표현 측면
과거에 등장한 방법 및 표현 측면에서 UML은 객체 지향 방법에서 일반적으로 수용되는 많은 개념을 통합합니다. 각 개념에 대해 UML은 명확한 정의, 표현 및 관련 용어를 제공합니다. UML은 기존의 다양한 방법으로 구축된 모델을 설명하고 원래 방법보다 더 잘 설명하는 데 사용할 수 있습니다.
소프트웨어 사이클
소프트웨어 개발 수명주기 측면에서 UML은 개발에 대한 완벽한 요구 사항을 가지고 있습니다. 개발 프로세스의 여러 단계에서는 동일한 개념과 표현 세트를 사용할 수 있으며 동일한 모델 내에서 개념과 표현을 변환하지 않고도 혼합할 수 있습니다. 이러한 원활함은 반복적이고 점진적인 소프트웨어 개발에 매우 중요합니다.
응용분야로는
응용 분야 측면에서 UML은 대규모, 복합, 실시간, 분산, 중앙 집중식 데이터 또는 컴퓨팅, 임베디드 시스템 등 다양한 분야의 모델링에 적합합니다.
프로그래밍 언어 및 개발 플랫폼
구현 프로그래밍 언어 및 개발 플랫폼 측면에서 UML은 다양한 프로그래밍 구현 언어 및 개발 플랫폼을 실행하는 시스템에 적용될 수 있습니다.
개발 과정
개발 프로세스 측면에서 UML은 개발 프로세스의 세부 사항을 설명하는 도구가 아니라 모델링 언어입니다. 범용 프로그래밍 언어와 마찬가지로 다양한 스타일의 프로그래밍이 가능합니다.
내부 개념적 측면
내부 개념 측면에서 UML은 다양한 개념 간의 내부 연결을 드러내고 표현하는 데 특별한 관심을 기울입니다. 알려진 상황과 알려지지 않은 상황에 적용되는 다양한 방식으로 모델링의 개념을 파악하려고 노력하는 과정을 통해 개념과 적용 가능성에 대한 이해가 향상됩니다. 이는 다양한 표준을 통일하려는 본래 의도는 아니지만, 다양한 표준을 통일한 가장 중요한 결과 중 하나이다.
UML의 구성은 다음 다이어그램을 사용하여 설명할 수 있습니다.
UML 기본 빌딩 블록 및 그래픽 분류
현재 UML 최신 버전은 UML 버전 2.5로 발전했으며, 다이어그램 수도 9개에서 13개로 늘어났다. 어떤 사람들은 UML 자체의 복잡성이 소프트웨어 모델링 자체를 초과할 수 있다고 생각합니다.
위 내용은 소프트웨어 엔지니어링에 없어서는 안 될 모델링 언어인 UML의 개발 역사를 통해 소프트웨어 설계 개념의 발전을 확인할 수 있을 뿐만 아니라 팀 커뮤니케이션을 촉진하고 시스템 설계를 최적화하며 개발 프로세스를 가속화하는 역할을 강조합니다. . 핵심 역할. 이 기사의 기본 소개를 통해 여러분은 UML의 역사적 맥락을 깊이 이해할 수 있을 뿐만 아니라 요구 사항 분석, 시스템 설계 및 문서화에 대한 광범위한 응용 프로그램을 마스터할 수 있을 것이라고 믿습니다.
관련 자료:
무료 온라인 협업 마인드 맵 및 순서도 
