2.12 소프트웨어 모델과 방법

개요와 동기

소프트웨어 모델은 특정한 질문에 답하려고 만든 시스템의 의도적인 단순화입니다. 방법은 그 과정에서 쓰는 모델을 포함해 소프트웨어를 만드는 규율 있는 방식입니다. 이 둘은 함께 소프트웨어 엔지니어링 지식체계(SWEBOK)의 한 지식 영역을 이룹니다. 시스템을 만들기 전, 만드는 동안, 만든 후에 시스템에 대해 추론하는 데 쓰는 정신적 도구이기 때문입니다. UML(통합 모델링 언어) 클래스 다이어그램, 개체-관계 다이어그램(ERD), 상태 기계, 형식 명세, 버릴 프로토타입은 모두 모델입니다. 폭포수, 프로토타이핑, 형식 개발, 애자일은 모두 방법입니다.

왜 굳이 모델을 만들까요? 인간의 작업 기억은 작고 소프트웨어 시스템은 크기 때문입니다. 누구도 10만 줄의 시스템을 머릿속에 담을 수 없으므로, 한 번에 한 측면, 즉 데이터, 제어 흐름, 상태, 상호작용을 보여 주는 그림을 그리고 추상화를 씁니다. 모델은 코드에 충실하도록 의도된 것이 아니라 결정에 적합하도록 의도된 것입니다. 좋은 모델은 무언가를 결정하는 데 필요한 것을 정확히 보여 주고 나머지는 모두 감춥니다.

큰 팀에서 진짜 이해관계는 조율과 소통입니다. 수백 명의 엔지니어, 아키텍트, 분석가, 감사자가 하나의 시스템에서 일할 때, 공유된 모델은 설계, 요구사항, 위험을 협상하는 공통 기반입니다. 그러니 모델링을 해야 할 일이 있는 도구로 생각하십시오. 모델이 막아 주는 실수보다 쌀 때 본전을 뽑습니다. 그 자체를 위해 그리거나, 낡은 지 한참 되도록 유지하거나, 돕기로 한 결정을 넘어 정교화하면 낭비가 됩니다. 모델링은 소프트웨어 요구사항(2.8장), 소프트웨어 설계 원칙(2.2장), C4와 arc42 같은 표기법을 포함한 아키텍처(3.1장), 애자일 일하는 방식(10.7장)과 긴밀히 연결됩니다.

핵심 원칙

모든 모델에는 목적이 있습니다. 모델이 정보를 주는 결정에 이름을 붙일 수 없다면 그리지 마십시오.
추상화는 모델링의 핵심 행위입니다. 목적에 중요한 것을 포함하고 나머지는 생략하십시오.
모델 안에서와 모델 사이의 일관성이 중요합니다. 모순된 모델은 없는 것보다 나쁩니다.
모델은 먼저 소통 산출물입니다. 독자가 표기법과 세부 수준을 결정합니다.
질문에 답하는 가장 가벼운 모델을 선호하십시오. 정교화에는 유지 비용이 있습니다.
모델은 분석한 만큼만 좋습니다. 검사하지 않은 모델은 시험하지 않은 가정입니다.
문제의 불확실성, 위험, 실패의 결과에 맞는 방법을 고르십시오.

권장 사항

추상화, 목적, 일관성을 갖추고 모델링한다

모든 모델을 목적과 독자에 이름을 붙이는 것으로 시작하십시오. 그다음 그 목적을 향해 가차 없이 추상화하십시오. 경쟁 상태를 해결하려는 시퀀스 다이어그램은 모든 필드가 아니라 타이밍과 메시지를 보여야 합니다. 모델을 서로 일관되게 유지해 ERD의 개체, 클래스 다이어그램의 클래스, 요구사항의 명사가 모두 일치하게 하고, 현실과 일관되게 유지하십시오. 즉 시스템이 나아가면 모델을 갱신하거나 삭제합니다. 사람들이 신뢰하는 낡은 모델은 위험입니다. 모두가 무시하는 낡은 모델은 여전히 주의를 소모하는 낭비입니다.

질문에 맞게 구조 모델이나 행위 모델을 고른다

시스템이 무엇으로 이루어져 있고 부분들이 어떻게 관련되는지 보이려면 구조 모델을 쓰십시오. 클래스 다이어그램, 컴포넌트 다이어그램, 데이터 구조를 위한 개체-관계 다이어그램입니다. 시스템이 시간에 따라 무엇을 하는지 보이려면 행위 모델을 쓰십시오. 의미 있는 수명주기를 가진 객체에는 상태 기계, 구성 요소 간 상호작용에는 시퀀스 다이어그램, 워크플로와 비즈니스 프로세스에는 액티비티 다이어그램입니다. 눈앞의 결정을 드러내는 표기법 하나를 고르십시오. 대부분의 시스템은 모든 것에 적용한 전체 UML 카탈로그가 아니라, 선택적으로 그린 몇 가지 다이어그램 유형만 필요합니다.

모델을 그리기만 하지 말고 분석한다

모델은 그리는 것만이 아니라 분석을 통해 제 몫을 합니다. 상태 기계에서 도달할 수 없는 상태, 빠진 전이, 교착 상태를 검사하십시오. ERD에서 정규화 문제와 고아 관계를 검사하십시오. 시퀀스 다이어그램을 요구사항에 비추어 걸어 보며 빠진 오류 경로를 찾으십시오. 무엇이 틀렸는지 알아챌 수 있는 도메인 전문가와 함께 모델을 검토하십시오. 그리고 실패의 비용이 높은 곳에서는 눈대중 대신 도구가 지원하는 분석(모델 검사기, 일관성 검사기, 시뮬레이션)에 손을 뻗으십시오.

휴리스틱 방법을 기본으로 적용한다

대부분의 소프트웨어는 휴리스틱 방법, 즉 모델을 비공식적으로 사용하고 증명이 아니라 기대에 비추어 결과를 판단하는 경험 기반의 반복적 접근으로 만들어집니다. 대부분의 비즈니스와 정부 시스템에서 그것은 바로 맞습니다. 요구사항이 진화하고 결함은 대개 복구 가능합니다. 휴리스틱 방법은 애자일(10.7장)과 자연스럽게 짝을 이룹니다. 팀을 정렬시키기에 딱 충분하게 모델링하고, 그다음 만들고 배웁니다.

형식 기법은 결과가 큰 핵심에 남겨 둔다

형식 기법은 명세를 수학으로 표현하고 증명이나 철저한 모델 검사 같은 검증으로 속성을 확립합니다. 실제 기술과 시간이 들며, 실패가 재앙적이거나 되돌릴 수 없는 곳에서 바로 본전을 뽑습니다. 안전 핵심 제어, 암호 프로토콜, 금융 결제 핵심 같은 곳입니다. 전체 시스템이 아니라 작은 핵심에 적용하십시오. 그리고 완전한 증명이 없더라도 형식 명세만으로 정밀해지도록 강제한다는 이유로 가치를 더하는 경우가 많음을 유념하십시오.

프로토타이핑으로 불확실성을 해소한다

요구사항이나 실현 가능성이 불분명할 때는 배우려고 프로토타입을 만들고, 그것을 발전시킬지 폐기할지 의도적으로 결정하십시오. 버릴 프로토타입은 질문을 싸게 탐색한 뒤 삭제됩니다. 발전형 프로토타입은 제품이 되므로 프로덕션 표준으로 만들어야 합니다. 고전적인 실패는 버릴 프로토타입이 우연히 프로덕션으로 미끄러져 들어가게 두는 것입니다. 그러니 만들기 전에 프로토타입의 유형에 이름을 붙이십시오.

유행이 아니라 위험에 방법을 맞춘다

문제의 불확실성과 실패의 결과로 방법을 고르십시오. 높은 불확실성은 프로토타이핑과 애자일 반복에 유리합니다. 높은 결과는 형식 분석과 엄밀한 검증에 유리합니다. 둘 다 있는 시스템은 그 외에는 애자일인 외피 안에 핵심 형식 코어가 필요합니다. 무엇을 하든, 방법이 권위 있다는 이유나 벤더가 팔고 있다는 이유로 채택하지 마십시오.

장단점

모델 또는 방법	잘 적용했을 때	실패 양상
구조 모델 (UML, ERD)	부분과 데이터의 공유된 그림	다이어그램 난립. 코드에서 표류
행위 모델 (상태, 시퀀스, 액티비티)	타이밍, 상태, 엣지 케이스를 드러냄	아무도 읽지 않는 지나치게 상세한 다이어그램
휴리스틱 방법	빠르고, 유연하고, 대부분의 시스템에 맞음	규율 없음. 숨은 가정
형식 기법	핵심에 대한 증명 가능한 속성	높은 비용. 전체 시스템에 잘못 적용
프로토타이핑	싼 학습. 위험을 일찍 해소	버릴 코드가 프로덕션으로 승격
애자일 방법	변하는 요구사항에 적응	어려운 문제에 필요한 모델링을 건너뜀

반복되는 긴장은 엄밀함과 속도 사이에 있습니다. 모델링이 너무 적으면 숨은 가정을 프로덕션으로 내보냅니다. 너무 많으면 결정에 정보를 주지 못하고 코드가 바뀌는 순간 썩는 다이어그램에 노력을 태웁니다. 이를 고치는 고정된 용량은 없고, 비례의 규칙만 있습니다. 모델이나 방법에 그것이 해소하는 불확실성과 결정을 잘못했을 때의 비용에 비례해 투자하십시오. 결제 엔진과 마케팅 마이크로사이트는 다른 대우를 받을 자격이 있습니다.

팀과 논의할 질문

우리 모델을 분석합니까, 아니면 그저 그리고 넘어갑니까? 모델은 존재해서가 아니라 분석을 통해 제 몫을 합니다. 도달할 수 없는 상태나 빠진 전이를 검사한 적 없는 상태 기계는 다이어그램으로 치장한 시험하지 않은 가정입니다. 큰 팀에서 진짜 결함이 숨는 곳이 여기입니다. 빠진 오류 경로나 고아 관계를 찾으려고 요구사항에 비추어 걸어 본 사람이 없을 때 그럴듯해 보이는 그림이 신뢰받기 때문입니다. 가장 중요한 행위 모델을 회의에 가져와 깨뜨려 보십시오. 어느 전이가 정의되지 않았는지, 어느 상태에 출구가 없는지, 어느 시퀀스에 타임아웃이 없는지입니다. 실패의 비용이 높은 곳에서는 눈대중보다 도구가 지원하는 분석(모델 검사기, 일관성 검사기, 시뮬레이션) 쪽으로 이끌어야 합니다. 핵심을 모델링하는 이유가 바로 결함을 프로덕션이 아닌 화이트보드에서 찾기 위해서이기 때문입니다.
우리 모델 중 둘이 불일치할 때 어느 쪽이 이기며, 모순을 누가 알아챕니까? 모델 안에서와 모델 사이의 일관성이 중요하며, 사람들이 양쪽에 따라 행동하기 때문에 모순된 모델은 없는 것보다 나쁩니다. 큰 시스템에서 데이터 모델의 개체, 설계의 클래스, 요구사항의 명사는 서로 다른 팀이 서로 다른 산출물을 갱신하면서 조용히 갈라지고, 첫 신호는 두 구성 요소가 어떤 것이 무엇인지에 대해 의견이 달랐던 프로덕션 버그인 경우가 많습니다. 예를 가져오십시오. 핵심 개념 하나를 골라 ERD, 코드, 요구사항이 그 모양과 수명주기에 실제로 일치하는지 확인하십시오. 그렇지 않다면 어느 산출물이 권위 있는지, 나머지를 맞추는 책임이 누구에게 있는지 정하고, 낡은 모델이 팀에 계속 거짓말하게 두느니 모델을 삭제할 의지를 가지십시오.
시스템의 어느 핵심이 틀리면 실제 돈을 잃거나 누군가를 해치며, 그것이 마땅한 엄밀함을 받고 있습니까? 이 장의 핵심 움직임은 방법을 위험에 맞추는 것입니다. 복구 가능한 다수에는 휴리스틱과 애자일 방법, 작고 결과가 큰 핵심에는 형식 명세와 검증, 진정으로 불확실한 것에는 싼 프로토타이핑입니다. 실패 양상은 대칭적이며 둘 다 비쌉니다. 마케팅 마이크로사이트에 형식 기법을 적용하면 돈을 태우고, 결제 엔진이나 자격 규칙 집합을 일반 애자일 작업으로 다루면 재앙적이고 되돌릴 수 없는 결함을 부릅니다. 시스템 지도를 가져와 오류가 재앙적인 곳과 복구 가능한 곳, 요구사항이 확실한 곳과 알려지지 않은 곳을 표시하십시오. 답은 모델링 투자를 돈과 모호함이 있는 곳에 집중하고 다른 곳에서는 명시적으로 유보해야 합니다. 그러면 핵심 형식 코어가 그 외에는 애자일인 외피 안에 있을 수 있고, 어느 방법도 다른 방법의 영역으로 새지 않습니다.
코드를 쓰기 전에 모델링을 얼마나 하며, 그 양이 눈앞의 불확실성에 따라 달라집니까? 선행 대규모 설계도 설계가 전혀 없는 것도 실패 양상이며, 알맞은 양은 그 사이에 있고 모델이 실제로 해소하는 불확실성의 양에 의해 정해집니다. 큰 팀에서 압력은 양쪽으로 작용합니다. 거버넌스 프로세스가 코드 전에 전체 다이어그램 세트를 요구해 가장 정보가 적을 때 내린 결정을 고정하는 반면, 전달 압력은 비싼 엣지 케이스를 잡았을 상태 기계 하나를 팀이 건너뛰게 몰 수 있습니다. 지난 두 프로젝트를 가져와 만든 모델을 실제 결정에 정보를 준 것과 템플릿이 요구해서 그린 것으로 분류하십시오. 단계 관문이나 승인 위원회가 문서를 앞서 의무화하는 경우가 많은 기업과 정부 프로그램에서는, 고정된 산출물 목록이 아니라 위험을 따르는 모델링을 주장할 준비를 하십시오. 그래야 결제 핵심은 엄밀함을 얻고 사내 보고 도구는 아무도 읽지 않는 다이어그램에 빠지지 않습니다.
공유된 표기법과 모델의 단일 홈에 합의했습니까, 아니면 모든 팀이 자기 것을 발명합니까? 모델은 먼저 소통 산출물이며, 한 팀의 도구로 그려진 상태 기계를 물려받은 팀이 읽거나, 찾거나, 신뢰할 수 없다면 그 가치는 무너집니다. 수백 명의 엔지니어에게 상충하는 고려는 실제입니다. 의무화된 표기법과 저장소는 일관성과 찾을 수 있음을 사지만, 학습 비용을 부과하고 사진 찍은 화이트보드로 충분할 때 사람들을 무거운 도구로 몰 수 있습니다. 모델이 실제로 산 곳의 예(위키, 다이어그램 도구, 슬라이드 덱, 누군가의 노트북)를 가져와 6개월 뒤 누가 찾아서 이해할 수 있겠는지 물으십시오. 기업과 규제 환경에서는 감사 측면이 이를 날카롭게 합니다. 현재 데이터 모델을 찾거나 결정을 문서화된 상태 기계까지 추적할 수 없는 감사자는 시스템을 문서화되지 않은 것으로 다룰 것이므로, 작은 공유 표기법과 오래가는 위치에 합의하고, 결과가 낮은 곳에서는 의식보다 가벼운 포착을 받아들이십시오.
프로토타입을 만들기 전에 버릴 것인지 발전형인지 의도적으로 결정하며, 그 선택을 지킵니까? 고전적이고 비싼 실패는 데모가 잘 되었고 아무도 처음에 유형에 이름을 붙이지 않았기 때문에 버릴 프로토타입이 조용히 프로덕션으로 미끄러지는 것입니다. 긴장은 진짜입니다. 버릴 프로토타입은 가능한 가장 싼 학습을 사고 삭제되어야 하며, 발전형 프로토타입은 제품이 되고 첫 줄부터 프로덕션 표준으로 만들어져야 하고, 둘을 혼동하면 재작업을 낭비하거나 설계되지 않은 역할에 취약한 코드를 내보냅니다. 최근 프로토타입을 가져와 만들기 전에 무엇이 결정되었는지, 승격하거나 폐기할 권한이 누구에게 있었는지, 그 결정이 전달 압력을 견뎠는지 물으십시오. 시민 대면 시스템이 투명성과 신뢰성 의무를 지는 정부와 다른 책임성 있는 환경에서는 우연한 승격을 통제의 실패로 다루십시오. 프로토타입의 운명을 미리 정하고, 성공한 버릴 프로토타입을 폐기하는 것을 피해야 할 낭비가 아니라 축하받는 성과로 만드십시오.

분야별 관점

스타트업. 화이트보드에서 모델링하고, 사진을 찍고, 넘어가십시오. 가장 희소한 자원은 엔지니어링 주의이니, 모델이 막아 주는 실수보다 쌀 때만 모델에 손을 뻗으십시오. 다음 달 방향을 바꿀 수도 있는 제품을 위한 전체 UML 카탈로그가 아니라, 청구 엣지 케이스를 코딩하기 전의 구독 상태 기계입니다. 휴리스틱하고 애자일하게 머물고, 형식 기법은 아예 논외로 하고, 의식적으로 달리 결정하지 않는 한 모든 프로토타입을 버릴 것으로 다루십시오.

소기업. 공식 모델링이 직무인 사람이 없을 가능성이 크니, 자체 모델링 실천을 세우는 대신 구매하는 도구와 프레임워크에 이미 내장된 모델에 의지하십시오. 그리는 소수의 모델을 구체적 결정을 중심으로 구성하십시오. 어떤 고객 데이터를 보유하는지 합의하는 간단한 데이터 모델 스케치, 깨지면 고객을 잃는 하나의 워크플로를 위한 상태 다이어그램입니다. 직접 만들고 문서화하는 대신 검증된 데이터 모델이 있는 구매 제품을 선호하고, 그리는 것을 한 사람이 유지할 수 있을 만큼 가볍게 하십시오.

대기업. 핵심 문제는 많은 팀에 걸친 조율이므로 공유된 모델이 공통 기반이 됩니다. 합의된 데이터 모델, 일관된 표기법, ERD, C4 다이어그램, 상태 기계를 찾고 신뢰할 수 있는 홈입니다. 작은 표기법을 표준화하고 일관성을 시행해, 요구사항, 설계, 데이터베이스의 개체가 팀 사이에서 갈라지지 않게 하십시오. 형식 명세와 모델 검사는 결과가 큰 핵심(결제, 대사, 접근 통제)에 남겨 두고, 그것이 요구하는 전문 기술에 재원을 대고, 각 문서화된 모델에서 그것이 정당화한 결정까지의 감사 추적을 유지하십시오.

정부. 법으로 정해진 규칙은 법령까지 추적 가능해야 하며, 여기서 형식 명세가 비용을 벌어 냅니다. 자격이나 평가 로직을 정밀하게 명세하고, 핵심 속성을 검증하고, 감사자가 모든 결과를 그것을 낳은 규칙까지 추적하게 하십시오. 조달은 고유한 무게를 더합니다. 문서와 모델은 계약상 산출물인 경우가 많으므로, 체크리스트를 충족하려고만 만들어진 것이 아니라 진정으로 결정을 담는 모델이 무엇인지 합의하십시오. 중대한 시스템이 어떻게 동작하는지에 대한 평이한 언어 설명을 공개하고, 프로덕션 빌드를 약속하기 전에 실제 사용자와 시민 대면 접수를 시험하려고 버릴 프로토타이핑을 쓰십시오.

사례

스타트업. 구독 청구 제품을 만드는 작은 스타트업이 코드를 쓰기 전에 구독 수명주기(체험, 활성, 연체, 취소, 재활성)를 화이트보드의 상태 기계로 스케치합니다. 다이어그램을 걸어 보다가 연체 계정의 결제가 마침내 통과하면 어떻게 되는지를 정의한 적이 없음을 알아챕니다. 실제 고객을 고립 상태에 빠뜨렸을 엣지 케이스입니다. 그 5분짜리 모델이 프로덕션 골칫거리를 아끼고, 그들은 무거운 다이어그램 도구를 유지하는 대신 사진을 찍어 둡니다. 다른 모든 곳에서는 애자일을 유지하며 정렬에 딱 충분하게 모델링합니다. 그들의 규모에서는 결함이 복구 가능하고 형식 기법은 순수한 비용이기 때문입니다.

대기업. 한 글로벌 은행이 새 결제 플랫폼을 만듭니다. 팀은 개체-관계 다이어그램으로 계정, 원장, 메시징 팀에 걸친 공유 데이터 모델에 합의하고, C4 다이어그램(3.1장)으로 서비스가 어떻게 맞물리는지 보입니다. 거래 수명주기(보류, 청산, 결제, 취소, 분쟁)를 명시적 상태 기계로 모델링하고, 분석에서 부분 취소 전이가 빠져 있음이 드러납니다. 그 간극은 프로덕션이 아닌 화이트보드에서 고쳐집니다. 시퀀스 다이어그램이 결제 흐름을 요구사항(2.8장)에 비추어 걸어 보며 빠진 타임아웃과 재시도 경로를 드러냅니다. 일상 전달은 애자일이지만, 오류가 실제 돈을 잃는 것을 뜻하는 핵심 대사 알고리즘은 형식 명세를 받고 구현 전에 모델 검사를 거칩니다. 모델링은 돈과 모호함이 있는 곳에 집중되고 다른 곳에서는 가볍게 유지됩니다.

정부. 한 국가 세무 기관이 급여 평가를 현대화합니다. 자격 규칙이 법으로 정해지고 감사를 받기 때문에, 팀은 규칙의 형식 명세를 순수 변환으로 쓰고, 청구인이 자격이 있으면서 없는 경우가 없고 모든 사건이 결정에 이른다는 것 같은 핵심 속성을 검증해, 감사자가 결과를 법령까지 추적할 수 있게 합니다. 형식 코어와 함께, 팀은 시민 대면 접수 양식의 버릴 프로토타입을 만들어 실제 사용자와 시험합니다. 다단계 마법사가 오류를 줄임을 배운 뒤 프로토타입을 폐기하고 접수를 프로덕션 표준으로 다시 만듭니다. 액티비티 다이어그램은 교육과 감사를 위해 처음부터 끝까지의 담당자 프로세스를 문서화합니다. 결과가 큰 규칙은 형식 엄밀함을, 불확실한 사용자 경험은 싼 프로토타이핑을 받으며, 어느 방법도 다른 방법이 속한 곳에 적용되지 않습니다.

비즈니스 사례: 동기, ROI, TCO

모델링의 수익은 고치는 비용이 훨씬 싼 곳에서 더 일찍 결함을 찾는 데서 옵니다. 화이트보드에서 발견한 모순은 몇 분이 듭니다. 프로덕션에서 발견한 같은 모순은 장애, 재작업 프로그램, 규제 영역에서는 법적 책임을 부를 수 있습니다. 모델은 오래가는 소통으로 쓰여 총소유비용도 낮춥니다. 기업과 정부에서 정상인 작성자보다 오래 사는 시스템은, 데이터 모델, 상태 기계, 핵심 흐름이 정확히 문서화되어 있을 때 유지보수가 훨씬 쌉니다.

비용은 실제이며 저울질해야 합니다. 모델은 만드는 데 시간이, 잘 만드는 데 기술이, 최신으로 유지하는 데 지속적인 노력이 들고, 형식 기법은 전문 인력을 더합니다. 손익분기점은 불확실성과 결과가 좌우합니다. 둘 다 낮은 곳에서 무거운 모델링은 가치를 파괴하고 애자일 휴리스틱이 이깁니다. 어느 쪽이든 높은 곳에서는 표적화된 모델링이, 핵심에는 형식 검증이 비싼 부류의 실패를 막아 몇 배로 본전을 뽑습니다. 리더십을 설득하려면 모델링 투자를 해소된 구체적 위험과 오래 사는 시스템의 유지보수성에 연결하십시오. 그리고 모델이 실제로 참조되는지 추적하십시오. 쓰이지 않는 모델은 순수한 비용이기 때문입니다.

안티패턴과 함정

그 자체를 위한 모델링: 결정에 정보를 주기 때문이 아니라 프로세스가 요구해서 다이어그램을 만드는 것.
진실로 신뢰되는 낡은 모델: 코드와 더는 맞지 않지만 여전히 의존되는 다이어그램.
선행 대규모 설계: 코드 이전에 만든 철저한 모델이 가장 정보가 적을 때 내린 결정을 고정하는 것.
다이어그램 난립: 모든 UML 유형이 획일적으로 적용되어 몇 안 되는 유용한 뷰를 잡음에 빠뜨리는 것.
어디에나 형식 기법: 실패의 결과가 정당화하지 않는 코드에 비싼 검증을 적용하는 것.
우발적 프로토타입 승격: 버릴 프로토타입이 조용히 제품으로 출시되는 것.
실질보다 표기법: 모델이 질문에 답하는지가 아니라 UML의 정확성을 두고 논쟁하는 것.

성숙도 모델

1단계(시작): 모델링이 그때그때 이루어지거나 없고 순전히 반응적입니다. 이름 붙은 방법이 없고, 모델은 그려진다 해도 일관되지 않고, 분석되지 않고, 회의가 끝나자마자 버려집니다.
2단계(발전): 일부 팀이 일반적인 다이어그램을 그리고 이름 붙은 방법을 따르지만, 관행이 조직 전반에서 고르지 않습니다. 모델은 의례적으로 생산되고, 코드에서 표류하며, 결함 분석은 거의 이루어지지 않습니다.
3단계(표준화): 공유 표기법, 문서화된 방법 선택 가이드, 일관성 규칙이 정의되어 조직 전체에서 시행됩니다. 모델은 목적에 따라 고르고, 시스템과 보조를 맞춰 유지되고, 결함에 대해 검토되며, 방법은 각 문제의 위험에 맞춰집니다.
4단계(관리): 모델링이 기준선에 대해 측정되고 통제됩니다. 팀은 분석이 구현 전에 잡는 결함 수, 모델이 코드에서 얼마나 표류하는지, 각 모델이 실제 결정에 참조되었는지, 정의된 기준선 대비 절약된 재작업과 사이클 타임을 추적합니다. 방법 선택은 측정된 불확실성과 결과에 맞춰 조정되고, 핵심은 합의된 커버리지 목표에 대해 형식 검증됩니다.
5단계(오케스트레이션): 모델링과 방법 선택이 지속적으로 개선되고 조직 전체의 전달 및 위험 계획과 통합됩니다. 투자는 불확실성과 결과가 이동함에 따라 적응하고, 모델은 증거에 따라 일상적으로 최신으로 유지되거나, 폐기되거나, 심화되며, 형식, 휴리스틱, 프로토타이핑 방법은 각각이 본전을 뽑는 정확한 자리에 놓이도록 조합됩니다.

논의를 위한 아이디어

지난 프로젝트에서 어떤 모델이 실제 결정에 정보를 주었고, 어떤 것이 프로세스가 요구해서만 그려졌습니까?
시스템의 어디에서 형식 명세가 본전을 뽑고, 어디에서 낭비이겠습니까?
프로토타입이 버릴 것인지 발전형인지 어떻게 결정하며, 그 결정을 시행합니까?
모델이 코드와 어긋나는 것을 어떻게 막으며, 아니면 일부는 삭제해야 한다고 받아들입니까?
여러분의 맥락에서 코드 이전의 알맞은 모델링의 양은 얼마이며, 불확실성에 따라 어떻게 달라집니까?
어떤 행위 모델(상태, 시퀀스, 액티비티)이 가장 최근 프로덕션 인시던트를 잡았겠습니까?

핵심 요점

모델은 목적이 있는 추상화입니다. 그것이 정보를 주는 결정에 이름을 붙일 수 없다면 그리지 마십시오.
구조 및 행위 모델을 특정한 질문에 맞추고, 일관되고 최신으로 유지하십시오.
모델을 분석하십시오. 검사하지 않은 모델은 시험하지 않은 가정입니다.
휴리스틱과 애자일 방법이 대부분의 시스템에 맞습니다. 형식 기법은 결과가 큰 핵심에 남겨 두십시오.
프로토타입으로 불확실성을 해소하고, 버릴 것인지 발전형인지 미리 결정하십시오.
모델링에는 그것이 해소하는 불확실성과 결정을 잘못했을 때의 비용에 비례해 투자하십시오.

참고 문헌과 더 읽을거리

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Version 4.0, Software Engineering Models and Methods knowledge area
Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modelling Language
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modelling Language User Guide
Frederick P. Brooks, The Mythical Man-Month and No Silver Bullet: Essence and Accident in Software Engineering
Daniel Jackson, Software Abstractions: Logic, Language, and Analysis (the Alloy modelling language)
Leslie Lamport, Specifying Systems (TLA+)
Simon Brown, Software Architecture for Developers (the C4 model)
David Harel, Statecharts: A Visual Formalism for Complex Systems