매우 유명한 이 저자가 포함되어 있어 안적고 갈 수가 없다..

• Grady Booch(February 27, 1955) - 객체지향 프로그래밍과 관련된 여섯 권의 베스트셀러 저자며, IBM에서 일하는 소프트웨어 엔지니어. 객체지향의 원류이자 Ivar Jacobson 와 James Rumbaugh 와 함께 UML의 창시자이다.
• Robert Maksimchuk - Unisys Chief Office의 연구 단장으로, 새로운 모델링 기술이 주 관심 분야다. "UML for Database Design"과 "UML for Mere Mortals"의 공동저자
• Michael Engle - 록히드 마틴의 기술 자문 핵심 멤버다. 다양한 도메인에 대해 프로젝트 초기 준비부터 개발과 지원까지 전체 시스템 개발 생명주기에 걸친 광범위한 기술과 관리 경험을 갖고 있다.
• Bobbi Young - Unisys Chief Office의 연구 단장. 일반 기업과 국방부 관련 IT 업체에서 오랜 경험을 갖고 있다.

2부 방법

시장에서 기술이 성공하려면 선행해야 할 일이 있다. 기술을 먼저 사용해 보고 성공을 경험한 충분한 사용자 공동체가 형성돼야 한다. 이것이 다른 사람들에게 투자 의욕을 불러일으킨다. 그런 충분한 사용자 공동체를 형성하는 데 공통 언어는 매우 효과적인 수단이다. 기술 도메인 지식을 쉽게 가르치고 전달하며 확산시킬 수 있기 때문이다.
특정 기술이 시장에서 주류가 되려면 기술을 잘 사용할 수 있는 방법(즉, 프로세스)과 어떻게 하면 그것을 효율적이고 효과적으로 활용할 수 있는지 사람들에게 잘 전달할 수 있어야 한다.

• 공통의 언어를 통해 공동체를 형성하고 성공을 확장시키는 것. 문명의 문자라는 공통의 언어를 통해 공동체를 구성하고 지식의 계승을 통해 영속적이며 발전적인 토대를 만드는 것이 왜 중요한지를 소프트웨어 세계에서도 알 수 있는 말이다.

  다이어그램을 그렸다고 해서 분석과 설계를 한 것은 아니다. 다이어그램은 단지 시스템 행위를 포착하거나(분석 행위) 아키텍처를 통해 시스템의 선견을 제시하거나 상세 내용을 작성하는(설계 행위) 수단에 불과하다. 소프트웨어, 토목, 기계, 화학, 건축 등 모든 공학 분야에서 시스템을 구상하는 유일한 공간이 있으니 바로 설계자의 머릿속이다. 설계는 일정한 시간이 흐르면서 조금씩 드러나기 때문에, 설계자는 종종 화이트보드와 같은 첨단(?) 장치에서부터 냅킨이나 편지봉투 뒷면 등에 설계하곤 한다.

• 실제로 나도 아이디어를 내거나 문제를 풀기 위한 밑그림을 그릴 때면 책상 위의 아무 흰색 종이를 찾곤한다. 실제로 편지봉투 뒷면에 끄적이면서 머릿 속의 내용을 명료하게 정리할 때가 있었는데 아무래도 당장 눈에 보이는 것에 쓰는 것은 전세계인 공통인 것 같다.

5.1 UML

개념이 명확하고 표현력이 풍부한 표기는 소프트웨어 개발에 있어 매우 중요하다. 첫째, 분석가나 개발자는 표준 표기를 통해 시나리오를 기술하고 아키텍처를 체계적으로 도출해서 다른 사람에게 명확히 전달할 수 있다. 만약 당신이 전기 회로를 그렸다고 가정할 때, 전 세계 어떤 전기 엔지니어도 트랜지스터 기호를 알아본다. 마찬가지로, 뉴욕의 건축가가 제작한 건축 설계 도면을 샌프란시스코의 시공업자가 보고, 어디에 문을 두고 창문을 달며 전기 콘센트를 뽑아야 하는지 이해하는 데 어려움이 없다.

둘쨰, 세계적인 수학자 화이트헤드(Whitehead)의 말처럼 "좋은 표기는 머릿속에서 불필요한 것을 제거하고 더 고도화된 문제에 집중할 수 있도록 도와준다."

셋째, 표현력이 풍부한 표기는 도구로 자동화 사용할 수 있기 때문에 설계 일관성과 정확성을 일일이 확인해야 하는 수고를 덜어준다. 미국방과학위원회 보고서에서 "소프트웨어 개발은 현재뿐만 아니라 미래에도 노동집약적인 기술일 것이다. (...) 아무리 기계장치들이 지루하고 단순한 작업을 대신하고 산더미 같은 결과물을 추적하는 데 도움을 주더라도, 개념을 설계하는 작업은 본질적으로 인간 활동일 수밖에 없다. (...) 소프트웨어 개발에 있어 개념을 고안하는 작업은 다른 것으로 대체될 수 없고 오로지 그것을 표현하는 작업만 도구로 대체될 수 있다.

• 2007년에 쓰인 책에서 예견하듯, 아직도 소프트웨어 업은 노동집약적인 산업으로 남아있다. 다양한 개발의 수고를 덜어주는 프로그램들이 많이 개발되었음에도 노동집약적인 이유는 다양하겠지만 한 소프트웨어를 개발함으로써 수많은 사람들의 삶에 영향을 줄 수 있는 파급력이 있으며 그 파급력을 만들기 위해선 다 수 의 사람들이 가진 관점과 능력이 필수적이기 때문이 아닐까?

먼 놈의 다이어그램이 이리도 많은지...

객체지향 개발 산출물

대체로 시스템을 분석할 때, 유스케이스 다이어그램과 활동 다이어그램(시나리오를 통해 시스템의 행위를 표현), 클래스 다이어그램(시스템 행위를 제공하는 동작주체 역할과 책임을 표현), 상호작용 다이어그램과 상태 다이어그램(이벤트 순서에 따른 동작주체 행위를 묘사)를 주로 사용한다.

---

시스템 아키텍처에는 패키지 다이어그램, 클래스, 객체, 컴포넌트, 배치 다이어그램과 각 다이어그램 별 동적 시점을 사용한다.

---

이들 다이어그램들은 서로 연결돼 있어 개발자는 요구 사항을 구현한 결과물에서부터 명세서까지 거꾸로 올라가면서 추적할 수 있다. 배치 다이어그램에서 특정 노드는 컴포넌트 다이어그램에 도식된 컴포넌트를 탑재할 수 있다. 컴포넌트 다이어그램은 도메인 개념을 정의한 일련의 클래스를 포함하며, 각 클래스 정의는 적절한 클래스 다이어그램에서 찾을 수 있다.

컴포넌트 다이어그램

컴포넌트란 분명한 목적을 갖고 시스템 기능을 모은, 재사용 가능한 소프트웨어 단위다. 가장 기술적인 관점에서 컴포넌트는 일종의 클래스 집단으로서, 내부적으로는 강하게 응집되면서도 상대적으로 다른 클래스 집단과는 느슨하게 결함된다. 시스템에서 클래스는 반드시 하나의 컴포넌트에 상주하거나, 최상위 추상화 수준인 시스템 그 자체다. 또한 컴포넌트는 다른 컴포넌트를 내포하기도 한다.

---

컴포넌트는 구조화된 분류자의 일종이며, 분류자의 협업과 내부 구조는 컴포넌트 다이어그램으로 표현한다. 명확한 인터페이스를 통해 다른 컴포넌트와 협업해 시스템 기능을 제고공하는 데 기여하는 특정 컴포넌트는 그 자체가 또 다른 컴포넌트로 구성되기도 한다. 그래서 계층적 분해가 가능한 컴포넌트를 통해 시스템 논리 아키텍처를 표현하는 것이 유용하다.

---

컴포넌트 다이어그램 필수 요소는 컴포넌트, 인터페이스, 그리고 실현관계다.

클래스 다이어그램

시스템의 논리 시점에서 클래스 다이어그램을 사용해 클래스와 클래스 관계를 표현한다.

• 하나의 클래스 다이어그램은 시스템 클래스 구조에 대한 하나의 시점이다.
• 분석과정에서 클래스 다이어그램은 시스템 행위를 제공하는 실체들의 공통 역할과 책임을 나타낸다.
• 설계 과정에서 클래스 다이어그램은 시스템 아키텍처를 구성하는 클래스 구조를 나타낸다.
• 클래스 다이어그램의 필수 요소는 클래스와 클래스 간 기본 관계다.