가을의 곰의 기술사 준비

2008.12.27 여기술사 맨토노트

UML의 기초:클래스 다이어그램

UML 2의 구조 다이어그램 소개

The Rational Edge 발췌: UML 2의 새로운 구조 다이어그램 유형 중 가장 중요한 클래스 다이어그램은 소프트웨어 개발 사이클 동안 분석가, 비즈니스 모델러, 개발자, 테스터에 의해 사용됩니다.

이 글은 Unified Modeling Language(UML)에서 사용되었던 필수 다이어그램에 관한 기술자료 시리즈입니다. 시퀀스 다이어그램에 대해 설명했던 이전 기술자료에서는, UML 1.4 스팩에서OMG의 Adopted 2.0 Draft Specification of UML (UML 2)로 초점을 이동했습니다. 이 글에서는 UML 2에 도입된 새로운 다이어그램 카테고리인 Structure Diagram에 대해 설명합니다. 본 시리즈의 목적은 표기법 요소들과 이들의 의미를 설명하는 것이므로, 이 글에서는 주로 클래스 다이어그램에 초점을 맞춥니다. 이렇게 하는 이유는 곧 명확해 질 것입니다. 후속 기술자료에서는 Structure 카테고리에 포함된 기타 다이어그램을 설명합니다.

이 글을 읽는 독자들에게 다시 한번 당부하고 싶은 것은 UML 표기법 요소들에 관한 것이고, 이 글은 모델링에 대한 최상의 접근 방식에 대한 가이드나 첫 번째로 모델링 되어야 할 것을 결정하는 방법에 대해서는 설명하지 않습니다. 이 글의 목표이자 본 시리즈의 목표는 표기법 엘리먼트에 대한 기본적인 지식, 즉 신택스와 의미를 설명하는 것입니다. 이러한 지식을 기반으로 여러분은 다이어그램을 읽고 알맞은 표기법 요소들을 사용하여 자신만의 다이어그램을 만들 수 있습니다.

여러분은 객체 지향 디자인에 대한 기본적인 지식이 있을 것으로 간주하겠습니다. OO 개념에 대한 설명이 필요하다면 http://java.sun.com/docs/books/tutorial/java/concepts/ 에서 객체 지향 프로그래밍을 다룬 Sun의 튜토리얼을 보시기 바랍니다. "What Is a Class?" 와 "What Is Inheritance?" 섹션에서는 이 글을 읽을 때 도움이 될 만한 정보들이 있습니다. 또한 David Taylor의 Object-Oriented Technologies: A Manager's Guide 역시 객체 지향 디자인을 잘 설명하고 있습니다.

UML 2의 음과 양

UML 2에는 두 가지 기본적인 다이어그램 카테고리가 있다. 모든 UML 다이어그램은 이 두 개의 다이어그램 카테고리들 중 하나에 속해있다. 구조 다이어그램(structure diagram)의 목적은 모델링 되는 시스템의 정적인 구조를 보여주는 것이다. 여기에는 클래스 다이어그램, 컴포넌트 다이어그램, 객체 다이어그램이 포함된다. 작동 다이어그램(Behavioral diagram)은 시스템의 객체들 간 동적인 작동을 보여준다. 여기에는 메소드, 협업, 액티비티 등이 포함된다. 작동 다이어그램 예로는 액티비티 다이어그램, 유스 케이스 다이어그램, 시퀀스 다이어그램 등이 있다.

구조 다이어그램

이미 언급했지만, 구조 다이어그램은 모델링 되는 시스템의 정적인 구조를 보여준다. 시간에 상관 없이 시스템의 요소들에 초점을 맞춘다. 정적 구조는 시스템에 있는 유형들과 이들의 인스턴스를 나타낸다. 시스템 유형과 인스턴스를 보여주는 것 외에도, 구조 다이어그램은 이러한 요소들 간 관계를 보여주고 심지어는 내부 구조까지도 보여준다.

구조 다이어그램은 소프트웨어 라이프 사이클 동안 팀 멤버들에게 유용하게 사용된다. 일반적으로, 이러한 다이어그램은 디자인의 유효성 검사와 개인과 팀들 간 디자인 통신에 사용된다. 예를 들어, 비즈니스 분석가들은 클래스나 객체 다이어그램을 사용하여 계정 대장, 제품, 지리적 계층 같은 비즈니스의 현재 에셋(asset)과 리소스를 모델링 할 수 있다. 아키텍트는 컴포넌트와 전개 다이어그램을 사용하여 자신들의 디자인이 튼튼하다는 것을 테스트 및 입증한다. 개발자들은 클래스 다이어그램을 사용하여 시스템의 코딩 된(또는 곧 코딩 될) 클래스들을 디자인 및 문서화 한다.

클래스 다이어그램

UML 2는 구조 다이어그램을 하나의 범주로 간주한다. "Structure Diagram"이라고 하는 다이어그램은 없다. 하지만, 클래스 다이어그램은 구조 다이어그램 유형의 대표적인 예이며, 다른 모든 구조 다이어그램들이 사용하는 초기 표기법 요소들을 제공한다. 클래스 다이어그램은 너무나도 중요하기 때문에, 이 글에서는 클래스 다이어그램의 표기법 세트를 집중적으로 설명하겠다. 이 글을 다 읽고 나면 여러분은 UML 2 클래스 다이어그램을 그리는 방법을 이해하고, 다음 기술자료에서 다룰 다른 구조 다이어그램을 더욱 잘 이해하게 될 것이다.

기초

앞서 언급했던 것처럼, 클래스 다이어그램의 목표는 시스템 내에서 모델링 되는 유형을 보여주는 것이다. 대부분의 UML 모델에서는 다음과 같은 유형들이 있다.

• 클래스
  
  
• 인터페이스
  
  
• 데이터 유형
  
  
• 컴포넌트

UML은 이러한 유형들에 대해 특별한 이름을 사용한다. 바로 "classifier"이다. 일반적으로, 여러분은 classifier를 클래스로 생각할 수 있지만, 기술적으로 classifier는 위에 언급한 다른 세 가지 유형들을 언급하는 보다 포괄적인 용어이다.

클래스 이름

클래스의 UML 표현은 수직적으로 쌓인 세 개의 부분들을 포함하고 있는 직사각형이다. (그림 1) 맨 위 부분은 클래스의 이름을 나타낸다. 중간 부분은 클래스의 애트리뷰트이다. 맨 밑 부분은 클래스의 연산이다. 클래스 다이어그램에 클래스 요소를 그릴 때, 맨 위 부분은 반드시 사용해야 하고 밑에 두 개의 부분은 선택적이다. (밑에 두 부분은 Classifier들 간 관계만 보여주는 것이 목적일 경우 고급 상세를 설명하는 다이어그램에서는 불필요 하다.) 그림 1은 UML 클래스로서 모델링 된 항공 내역을 보여준다. 이름은 Flight 이고, 중간 부분에는 Flight 클래스에 세 개의 애트리뷰트, flightNumber, departureTime, flightDuration이 있다. 밑 부분에서는 Flight 클래스가 두 개의 연산, delayFlight과 getArrivalTime을 갖고 있다.

그림 1: Flight 클래스에 대한 클래스 다이어그램 클래스 애트리뷰트 리스트

한 클래스의 애트리뷰트 섹션(중간 부분)은 각 클래스의 애티리뷰트를 각 라인 별로 나열한다. 애트리뷰트 섹션은 선택적이지만, 이것이 사용된다면 하나의 리스트 포맷으로 디스플레이 된 클래스의 애트리뷰트가 포함된다. 이 라인은 다음과 같은 포맷을 사용한다.

이 Flight 클래스 예제에서, 애트리뷰트 유형 정보와 함께 클래스의 애트리뷰트를 기술할 수 있다. (표 1)

표 1: 애트리뷰트 유형 정보를 가진 Flight 클래스의 애트리뷰트 이름

비즈니스 클래스 다이어그램에서, 애트리뷰트 유형들은 다이어그램의 독자들이 이해할 수 있는 단위들에도 상응한다. (예, 분(minute), 달러(dollar) 등). 하지만, 코드를 생성하기 위해 사용될 클래스 다이어그램은 애트리뷰트 유형이 프로그래밍 언어에서 제공하는 유형 또는 시스템에 구현될 모델에 포함되는 유형으로 제한된 클래스가 필요하다.

가끔, 클래스 다이어그램에 특정 애트리뷰트가 기본 값을 갖고 있음을 보여주는 것도 유용하다. (예를 들어, 은행 계정 애플리케이션에서, 새로운 은행 계정은 잔액 0으로 시작한다.) UML 스팩은 다음과 같은 표기법을 사용함으로써, 애트리뷰트 리스트 섹션에 기본 값을 구분한다.

예를 들어:

애트리뷰트에 대한 기본 값을 보여주는 것은 선택적이다. 그림 2는 기본 값이 0인, balance 라고 하는 애트리뷰트를 가진 Bank Account 클래스를 보여준다.

그림 2: 기본 값이 0 달러인 balance 애트리뷰트의 값을 보여주는 Bank Account 클래스 다이어그램

클래스 연산 리스트

클래스의 연산은 클래스 다이어그램의 세 번째(가장 밑에 있는) 부분에 나타난다. 이것 역시 선택적이다. 애트리뷰트와 마찬가지로, 클래스의 연산은 리스트 포맷으로 디스플레이 되고, 각 라인마다 연산이 있다. 연산은 다음과 같은 표기법을 사용하여 문서화 된다.

Flight 클래스의 연산은 아래 표 2로도 매핑 될 수 있다.

표 2: 그림 2를 표로 나타낸 Flight 클래스의 연산

그림 3을 보면 delayFlight 연산이 Minutes 유형의 인풋 매개변수 numberOfMinutes를 갖고 있다는 것을 알 수 있다. 하지만 delayFlight 연산에는 리턴 값이 없다. 1 하나의 연산이 매개변수를 갖고 있을 때, 매개변수들은 연산의 괄호 안에 놓이게 된다. 각 매개변수는 "parameter name : parameter type" 포맷을 사용한다.

그림 3: Flight 클래스 연산 매개변수들에는 "in" 표시가 포함된다.

연산의 매개변수들을 문서화 할 때, 매개변수가 연산의 인풋인지 또는 아웃풋인지를 보여주기 위해 선택적인 인디케이터를 사용할 수도 있다. 이러한 선택적인 인디케이터는 그림 3의 연산 부분에 나타난 것처럼 "in" 또는 "out"으로 나타난다. 일반적으로, 이러한 인디케이터는 Fortran 같은 오래된 프로그래밍 언어가 사용되지 않는 한 불필요하다. 하지만, C++과 자바에서, 모든 매개변수들은 "in" 매개변수들이고, "in"은 UML 스팩에 따라 매개변수의 기본 유형이기 때문에 대부분의 사람들은 인풋/아웃풋 인디케이터를 생략한다.

상속(Inheritance)

객체 지향 디자인의 가장 중요한 개념인 상속( inheritance )은 하나의 클래스(자식 클래스)가 또 다른 클래스(슈퍼 클래스)의 동일한 기능을 상속 받을 수 있고 고유의 새로운 기능을 추가할 수 있다는 것을 의미한다. (기술적인 비유법은 아니지만, 필자는 어머니의 음악적 재능을 물려받았고, 우리 가족 중에서 전자 기타를 연주할 수 있는 사람은 필자뿐이다.) 클래스 다이어그램에 상속을 모델링 하려면, 속이 투명한 화살표(또는 삼각형)가 슈퍼 클래스를 향하도록 하여 자식 클래스(작동을 상속받는 클래스)로부터 직선이 그려진다. Bank Account 유형을 생각해 보자. 그림 4는 CheckingAccount와 SavingsAccount가 BankAccount 클래스에서 상속을 받는 모습이다.

그림 4: 투명 삼각형 모양의 화살표가 슈퍼 클래스를 가리키면서 직선으로 상속이 표시된다.

그림 4에서, 상속 관계는 각 하위 클래스 마다 개별 라인으로 그려지는데, 이것은 IBM Rational Rose와 IBM Rational XDE에서 사용되는 방식이다. 하지만, 트리 표기법( tree notation )으로 상속을 그리는 방법도 있다. 그림 4처럼 두 개 이상의 자식 클래스들이 있을 때 트리 표기법을 사용할 수 있다. 나무 가지처럼 상속 라인들이 합쳐지는 경우는 예외이다. 그림 5는 그림 4의 상속을 트리 표기법으로 다시 그린 것이다.

Figure 5: 트리 표기법을 사용한 상속

추상 클래스와 연산
주의력이 깊은 독자라면 그림 4와 5의 다이어그램이 BankAccount 클래스 이름과 withdrawal 연산에 이탤릭 체를 사용하고 있음을 알아챘을 것이다. BankAccount 클래스는 추상 클래스이고, withdrawal 메소드는 추상 연산이라는 것을 나타내는 것이다. 다시 말해서, BankAccount 클래스는 withdrawal의 추상 연산을 제공하고 CheckingAccount와 SavingsAccount의 두 개의 자식 클래스들은 각각의 연산 버전을 구현한다.

하지만, 슈퍼 클래스(부모 클래스)는 추상 클래스일 필요가 없다. 일반적으로 표준 클래스가 슈퍼 클래스가 된다.

제휴(Association)
시스템을 모델링 할 때, 특정 객체들은 서로 연관될 것이고, 이러한 관계들이 명확하게 모델링 되어야 한다. 다섯 가지 제휴 유형들이 있다. 이 섹션에서는 두 가지 유형-양방향(bi-directional) 제휴와 일방향(uni-directional) 제휴를 설명하고, 나머지 세 가지 제휴 유형들은 기초를 넘어서 섹션에서 설명하도록 하겠다. 각각의 제휴 유형을 사용할 시기까지는 이 섹션에서는 설명하지 않겠다. 각 제휴 유형의 목표에 초점을 맞춰, 클래스 다이어그램에 제휴를 그리는 방법을 설명하도록 하겠다.

양방향 (표준) 제휴
제휴는 두 클래스들간 연결이다. 제휴는 언제나 양방향(bi-directional)으로 간주된다. 다시 말해서, 일부 다른 유형으로 수정하지 않는 한, 두 개의 클래스들이 서로를 인식하고 있고 그 관계를 알고 있다는 의미이다. 그림 6은 Flight 클래스와 Plane 클래스 간 표준 제휴 유형이다.

그림 6: Flight 클래스와 Plane 클래스간 양방향 제휴 예제

양방향 제휴는 두 클래스들 간 일직선으로 표시된다. 각 라인의 양 끝에 역할과 값을 표시한다. 그림 6은 Flight이 특정 Plane과 연결되어 있고, Flight 클래스는 이러한 관계를 알고 있다는 것을 보여준다. Plane은 이 제휴 관계에서 "assignedPlane"의 역할을 담당하고 있다. Plane 클래스 옆에 있는 역할 이름이 이를 말해주고 있다. Plane 옆에 있는 Multiplicity 값 0..1은 Flight의 인스턴스가 있을 때, Plane의 한 인스턴스가 이것과 연결되었거나, 어떤 Plane도 이것과 연결되지 않았다(비행기가 아직 지정되지 않았을 경우)는 것을 의미한다. 그림 6에서는 Plane이 Flight 클래스와의 제휴 관계를 인식하고 있음을 보여준다. 이러한 제휴 관계에서, Flight은 "assignedFlights"의 역할을 맡는다. 그림 6의 다이어그램은 Plane 인스턴스가 어떤 비행 스케줄과도 제휴될 수 없거나(새로운 비행기일 경우) 또는 많은 비행 스케줄(이 비행기가 지난 5년 동안 사용 중일 경우)과 연결될 수 있다는 것을 나타낸다.

표 3에는 Multiplicity 값들과 이것의 의미를 정리했다.

표 3: Multiplicity 값과 인디케이터

일방향 제휴
일방향 제휴에서는, 두 개의 클래스들은 관련이 있지만, 단 하나의 클래스만 그 관계를 인식하고 있다. 그림 7은 일방향 제휴의 예제이다.

그림 7: 일방향 제휴 예제: OverdrawnAccountsReport 클래스는 BankAccount 클래스에 대해 알고 있지만, BankAccount 클래스는 제휴 관계에 대해 모른다.

일방향 제휴는 알려진 클래스를 가리키는 개방된 화살표(상속을 나타내는데 사용되었던 닫힌 또는 삼각형 화살표가 아니다.)가 있는 직선으로 그려진다. 표준 제휴와 마찬가지로, 일방향 제휴에는 역할 이름과 Multiplicity 값이 포함되지만, 표준 양방향 제휴와는 달리, 일방향 제휴에는 알려진 클래스에만 역할 이름과 Multiplicity 값이 포함된다. 그림 7의 예제를 보면, OverdrawnAccountsReport는 BankAccount 클래스에 대해 알고 있고 BankAccount 클래스는 "overdrawnAccounts"의 역할을 수행한다. 하지만, 표준 제휴와는 달리, BankAccount 클래스는 이것이 OverdrawnAccountsReport와 제휴되어 있다는 사실을 모른다. 2

패키지
대형 시스템 또는 비즈니스의 큰 유형을 모델링 한다면, 모델에 다양한 Classifier가 있을 것이다. 이 모든 클래스들을 관리하기란 매우 어렵다. 따라서, UML은 패키지( package )라고 하는 요소를 제공한다. 패키지는 모델러가 모델의 Classifier를 네임스페이스로 구성할 수 있도록 하는데, 이는 일종의 파일링 시스템의 폴더와 같은 것이다. 시스템을 다중 패키지들로 나무면 시스템은 더욱 이해하기 쉽고, 특히 각 패키지가 시스템의 특정 부분을 나타낼 때 더욱 그렇다. 3

다이어그램에 패키지들을 그리는 두 가지 방법이 있다. 어떤 표기법을 사용할 것인지 결정하는 규칙은 없다. 여러분이 그리는 클래스 다이어그램을 가장 쉽게 읽을 수 있는 방법을 기준으로 삼으면 된다. 두 가지 방법 모두 큰 직사각형이 있고 좌측 상단 코너 쪽에 작은 직사각형(탭)시작한다. (그림 8) 모델러는 패키지의 멤버쉽이 보여지는 방법을 결정해야 한다.

• 큰 직사각형 안에 패키지의 멤버들을 보여주기로 결정했다면, 모든 멤버들 4 은 직사각형 안에 놓여야 한다. 또한 패키지의 이름은 패키지의 작은 직사각형에 놓여야 한다. (그림 8)
  
  
• 모델러가 큰 직사각형 밖에 패키지의 멤버들을 보여주기로 결정했다면, 다이어그램에 나타날 모든 멤버들은 직사각형 밖에 놓여야 한다. 어떤 Classifier들이 패키지에 속했는지를 보여주려면, 각 Classifier부터 패키지에 붙은 원 안에 플러스 부호가 있는 원으로 선을 그어야 한다. (그림 9)

그림 8: 패키지의 직사각형 바운더리 안에 멤버들을 보여주는 패키지 엘리먼트 예제

그림 9: 연결된 선들을 통해 멤버쉽을 보여주는 패키지 엘리먼트 예제

기초 이해의 중요성

UML 2에서는 클래스 다이어그램의 기초를 이해하는 것이 더 중요해졌다. 클래스 다이어그램은 컴포넌트나 객체 다이어그램 등 모든 구조 다이어그램에 대한 기본 구현 블록을 제공하기 때문이다.

기초를 넘어서

지금까지 클래스 다이어그램의 기초를 설명했다. 아직 끝나지 않았으니 계속 읽어주기 바란다. 이어지는 섹션에서는 클래스 다이어그램의 더 중요한 측면들을 설명하겠다. 인터페이스와, 남아있는 세 가지 제휴 유형들, 가시성(visibility), UML 2 스팩의 추가 요소들을 설명하겠다.

인터페이스

이 글 초반에, 여러분이 classifiers 를 단순히 클래스로 간주할 것이라고 말한바 있다. 사실, Classifier는 보다 일반적인 개념이고, 여기에는 데이터 유형과 인터페이스가 포함된다.

시스템의 구조 다이어그램에서 데이터 유형과 인터페이스를 효과적으로 사용할 시기와 방법을 설명하는 것은 이 글의 범위를 벗어난다. 그렇다면, 왜 데이터 유형과 인터페이스를 언급했을까? 가끔은 구조 다이어그램에 이러한 Classifier 유형들을 모델링 해야 할 때가 있고, 이를 수행할 때 올바른 표기법을 사용하는 것이 중요하며, 적어도 Classifier 유형들에 대해서는 알고 있어야 한다. 이러한 Classifier들을 부정확하게 그리면 구조 다이어그램을 읽는 사람들이 혼란을 겪을 것이고, 시스템은 요구 사항을 채우지 못하게 된다.

클래스와 인터페이스는 다르다. 클래스는 그 유형의 실제 인스턴스를 가질 수 있지만, 인터페이스는 이를 실행할 적어도 한 개의 클래스를 가져야 한다. UML 2에서, 인터페이스는 클래스 모델링 요소를 특화 한 것으로 간주한다. 따라서, 인터페이스는 클래스처럼 그려지지만, 직사각형의 맨 위 부분에는 "«interface»" 라는 텍스트가 붙는다. 그림 10 5

그림 10: Professor와 Student 클래스들이 Person 인터페이스를 구현하는 클래스 다이어그램 예제

그림 10의 다이어그램에서, Professor와 Student 클래스들은 Person 인터페이스를 구현하는 것이지, Person 인터페이스에서 상속을 받지 않는다. 이렇게 말하는 데는 두 가지 근거가 있다. 1) Person 객체는 인터페이스로서 정의된다. 객체의 이름 영역에 "«interface»" 텍스트가 있고, Professor와 Student 객체들이 클래스 객체를 그리는 규칙에 따라 레이블링 되고 있기 때문에 이들이 클래스 객체들이라는 것을 알고 있다. (이름 영역에 추가적인 구분 텍스트가 없다.) 2) 화살표로 이어진 선이 점으로 되어있고 직선이 아니기 때문에 상속이 아니다. 그림 10에서 보듯, 속이 비어있는 폐쇄 화살표가 연결된 점선 은 구현을 의미한다. 그림 4에서 보듯, 속이 비어있는 폐쇄 화살표로 연결된 직선 은 상속을 의미한다.

기타 제휴 유형들
앞서 양방향 제휴와 일방향 제휴를 설명했다. 이제는 나머지 세 가지 제휴 유형들을 설명하도록 하겠다.

제휴 클래스
제휴를 모델링 할 때, 관계에 대한 중요한 정보를 포함하고 있기 때문에 또 다른 클래스를 포함시켜야 할 때가 있다. 이러한 이유로, 여러분은 기본 제휴에 연결할 제휴 클래스 를 사용해야 한다. 제휴 클래스는 일반 클래스처럼 표현된다. 차이점은, 기본 클래스들간 제휴 라인은 제휴 클래스로 연결된 점선을 횡단한다. 그림 11은 항공 관련 예제의 제휴 클래스 모습이다.

그림 11: 제휴 클래스 MileageCredit 추가하기

그림 11의 클래스 다이어그램에서, Flight 클래스와 FrequentFlyer 클래스간 제휴는 MileageCredit라고 하는 제휴 클래스라는 결과를 만들어 낸다. Flight 클래스의 인스턴스가 FrequentFlyer 클래스의 인스턴스와 제휴될 때, MileageCredit 클래스의 인스턴스도 생긴다.

애그리게이션(Aggregation)
애그리게이션은 "전체와 부분들(whole to its parts)" 관계를 모델링 하는데 사용되는 특별한 제휴 유형이다. 기본적인 애그리게이션 관계에서, 부분( part ) 클래스의 라이프 사이클은 전체( whole ) 클래스의 라이프 사이클과는 무관하다.

예를 들어, Car 를 전체 엔터티로, Car Wheel 을 전체 Car의 부분으로 생각할 수 있다. 바퀴는 몇 주 먼저 만들어 질 수 있고 조립하는 동안 자동차에 부착되기 전에 웨어하우스에 놓일 수 있다. 이 예제에서, Wheel 클래스의 인스턴스는 Car 클래스의 인스턴스와는 독립적으로 존재한다. 하지만, 부분 클래스의 라이프 사이클이 전체 클래스의 라이프 사이클과 무관하지 않을 때가 있다 . 이를 composition aggregation이라고 한다. 회사와 부서 의 관계를 생각해 보면 된다. 회사와 부서들은 클래스로 모델링 되고, 회사가 존재하기 전에 부서는 존재할 수 없다. 이 경우 Department 클래스의 인스턴스는 Company 클래스의 인스턴스에 종속적이다.

기본 애그리게이션과 Composition Aggregation을 자세히 살펴보도록 하자.

기본 애그리게이션
애그리게이션 관계와의 제휴는 하나의 클래스가 또 다른 클래스의 일부라는 것을 나타낸다. 애그리게이션 관계에서, 자식 클래스 인스턴스는 부모 클래스보다 오래 살아남는다. 애그리게이션 관계를 나타내려면, 부모 클래스에서 부분 클래스로 직선을 그리고, 부모 클래스의 제휴의 끝에 속이 비어있는 다이아몬드 모양을 그린다. 그림 12는 Car와 Wheel간 애그리게이션 관계 예제를 나타낸다.

그림 12: 애그리게이션 제휴 예제

Composition aggregation
Composition Aggregation 관계는 애그리게이션 관계의 한 형태이지만, 자식 클래스의 인스턴스 라이프 사이클은 부모 클래스의 인스턴스 라이프 사이클에 종속적이다. 그림 13은 Company 클래스와 Department 클래스 간 컴포지션 관계를 보여주는데, 컴포지션 관계는 애그리게이션 관계처럼 그려지지만, 이번에는 다이아몬드 속이 채워졌다.

그림 13: composition 관계 예제

그림 13에서 모델링 된 관계에서, Company 클래스 인스턴스에는 한 개 이상의 Department 클래스 인스턴스가 있다. 이 관계는 composition 관계이기 때문에, Company 인스턴스가 제거될 때, Department 인스턴스도 자동적으로 제거된다. Composition Aggregation의 또 다른 중요한 특징은 부분 클래스는 부모 클래스의 한 인스턴스와만 연결될 수 있다는 점이다. (우리 예제의 경우, Company 클래스)

반사 제휴(Reflexive association)
지금까지, 모든 제휴 유형들에 대해서 살펴보았다. 여러분도 알다시피, 이 모든 예제들은 두 개의 다른 클래스들간 관계를 보여주었다. 하지만, 반사 제휴(reflexive association)를 사용하여 하나의 클래스가 그 자체로 제휴될 수도 있다. 언뜻 이해가 되지 않지만, 클래스들이 추상적이라는 것을 기억하라. 그림 14는 Employee 클래스가 manager 역할을 통해 스스로 연결되는 방법을 보여주고 있다. 하나의 클래스가 스스로 제휴를 맺을 때, 클래스의 인스턴스도 스스로 제휴를 맺는 것이 아닌, 클래스의 인스턴스는 그 클래스의 다른 인스턴스와 연결된다는 것을 의미한다.

그림 14: 반사 제휴 관계 예제

그림 14의 관계도는 Employee의 인스턴스가 또 다른 Employee 인스턴스의 매니저가 될 수 있다는 것을 의미한다. 하지만, "manages"의 관계 역할이 0..*의 Multiplicity를 가질 수 있기 때문에 Employee는 관리할 다른 Employee가 없을 수 있다.

가시성
객체 지향 디자인에서, 애트리뷰트와 연산에 대한 가시성 표기법이 있다. UML은 네 가지 가시성 유형을 정의하고 있다: Public, Protected, Private, Package

UML 스팩에서는 클래스 다이어그램에 디스플레이 되는 애트리뷰트와 연산 가시성을 요하지 않지만, 각 애트리뷰트나 연산에 대해 정의되어야 한다고 정하고 있다. 클래스 다이어그램에 가시성을 디스플레이 하려면, 애트리뷰트 또는 연산의 이름 앞에 가시성 부호를 붙여야 한다. UML이 네 가지 가시성 유형을 정의하지만, 실제 프로그래밍 언어는 추가 가시성들을 추가하거나, UML에서 정의된 가시성은 지원하지 않을 수도 있다. 표 4는 UML에서 지원되는 가시성 유형에 대한 부호를 정리한 것이다.

표 4: UML 지원 가시성 유형에 대한 부호

이제 애트리뷰트와 연산에 대한 가시성 유형을 보여주는 클래스를 보자. 그림 15에서, 모든 애트리뷰트와 연산들은 Public이고, updateBalance 연산만 예외이다. updateBalance 연산은 Protected이다.

그림 15: 애트리뷰트와 연산의 가시성을 보여주는 BankAccount 클래스

UML 2 추가

지금까지 기본적인 내용과 고급 주제들을 다루었다. 이제 UML 1.x에 추가된 새로운 표기법에 대해 알아보자.

인스턴스
시스템의 구조를 모델링 할 때, 클래스의 예제 인스턴스를 보여주는 것이 가끔 유용하다. 이것을 모델링 하기 위해, UML 2는 엘리먼트를 제공하는데, 이것은 시스템의 예시(또는 실제) 인스턴스 를 사용하여 흥미로운 정보를 보여준다.

인스턴스의 표기법은 클래스와 같지만, 맨 위 부분에 클래스 이름 대신, 이름에는 밑줄이 생긴다.

예를 들어,

인스턴스를 보여주는 이유가 관심이 있거나 관련이 있는 정보를 보여주는 것이기 때문에, 모델 안에 전체 인스턴스의 애트리뷰트와 연산을 포함시킬 필요는 없다. 대신, 그림 16에서처럼 관심이 있는 애트리뷰트와 값들만 보여주는 것이 좋다.

그림 16: Plane 클래스의 인스턴스 예제 (관심 있는 애트리뷰트 값들만 보인다.)

하지만, 단순히 관계에 대한 설명 없이 몇 가지 인스턴스들만 보여주는 것은 쓸모가 없다. 따라서, UML 2는 인스턴스 레벨에서 관계/제휴 모델링을 적용한다. 제휴를 그리는 규칙은 일반 클래스 관계와 같지만, 제휴를 모델링 할 때 한 가지 추가 요구 사항이 있다. 제휴 관계는 클래스 다이어그램의 관계와 매치해야 하고, 제휴의 역할 이름 역시 클래스 다이어그램과 매치되어야 한다. 이것의 예제는 그림 17에 나타나 있다. 이 예제에서, 인스턴스는 그림 6의 클래스 다이어그램의 인스턴스 예제이다.

그림 17: 클래스 대신 인스턴스를 사용하는 그림 6의 예제

그림 17은 Flight 클래스의 두 개의 인스턴스를 갖고 있다. 클래스 다이어그램이, Plane 클래스와 Flight 클래스간 관계를 zero-to-many 라고 명시했기 때문이다. 따라서, 우리 예제에서는 NX0337 Plane 인스턴스가 연관된 두 개의 Flight 인스턴스를 보여주고 있다.

역할
클래스의 인스턴스를 모델링 하는 것은 기대 이상으로 상세하다. 가끔, 보다 일반적인 레벨에서 클래스의 관계를 모델링하고 싶을 때가 있다. 이 같은 경우, 역할( role ) 표기법을 사용해야 한다. 역할 표기법은 인스턴스 표기법과 매우 비슷하다. 클래스의 역할을 모델링 하려면, 박스를 그린 다음, 인스턴스 표기법에서처럼 그 안에 클래스의 역할 이름과 클래스 이름을 놓는다. 하지만, 이 경우, 단어에 밑줄을 그어서는 안된다. 그림 18은 그림 14의 다이어그램에서 설명한 Employee 클래스의 역할 예제이다. 그림 18에서, Employee 클래스가 스스로와 연결되었더라도, 그 관계는 매니저의 역할을 하는 Employee와 팀 멤버의 역할을 하는 Employee간 관계이다.

그림 18: 각자 다른 역할을 가진 그림 14의 클래스를 보여주는 클래스 다이어그램

평범한 클래스 다이어그램에서 클래스의 역할을 모델링 할 수 없다. 심지어, 그림 18은 가능한 것처럼 보여도 모델링은 불가능하다. 역할 표기법을 사용하려면, Internal Structure 표기법을 사용해야 한다.

Internal Structures
UML 2 구조 다이어그램의 유용한 기능들 중 하나는 새로운 Internal Structures 표기법이다. 클래스와 또 다른 Classifier가 내부에서 구성되는 방법을 보여주고 있다. 이것은 UML 1.x에서는 불가능 했다. 이 표기법 세트는 클래스가 가진 애그리게이션 관계만 보여주기 때문이었다. 이제, UML 2에서 Internal Structures 표기법으로 클래스의 부분들이 서로 어떻게 연관되는지를 명확히 보여줄 수 있다.

예제를 보자. 그림 18에서는 Plane 클래스가 네 개의 엔진들과 두 개의 컨트롤 소프트웨어 객체들로 구성되는 방법을 보여주는 클래스 다이어그램을 보았다. 이 다이어그램에서 빼먹은 것은 비행기의 부품들이 조립되는 방법에 대한 정보이다. 그림 18의 다이어그램에서, 컨트롤 소프트웨어 객체들이 두 개의 엔진들을 제어하는지, 하나의 컨트롤 소프트웨어 객체가 세 개의 엔진들을 제어하고 다른 컨트롤 소프트웨어가 하나의 엔진을 제어하는지를 알 수 없다.

그림 19: 객체들 간 관계만 보여주는 클래스 다이어그램

클래스의 내부 구조를 그린다면 상황은 더 나아질 것이다. 두 개의 칸을 가진 박스를 그린다. 윗칸에는 클래스 이름이, 아래칸에는 클래스의 내부 구조가 포함되어 있고, 각각의 역할에 부모 클래스의 부분 클래스들을 보여주고 있고, 각각의 특정 클래스가 그 역할에서 서로서로 연관되는 방법을 보여주고 있다. 그림 19는 Plane 클래스의 내부 구조를 보여주고 있다. 내부 구조가 혼란을 어떻게 종식시키는지 주목하라.

그림 20: Plane 클래스의 내부 구조 예제

그림 20에서, Plane은 두 개의 ControlSoftware 객체들을 갖고 잇고, 각각 두 개의 엔진들을 제어하고 있다. 이 다이어그램의 왼쪽에 있는 ControlSoftware(control1)는 엔진 1과 엔진 2를 제어한다. 오른쪽에 있는 ControlSoftware(control2)는 엔진 3과 4를 제어한다.

결론

클래스 다이어그램일 이해해야 하는 두 가지 중요한 이유가 있다. 첫 번째는 시스템에서 Classifier의 정적 구보를 보여주는 것이고, 두 번째 이유는 다이어그램이 UML에서 정한 다른 구조 다이어그램에 대한 기본적인 표기법을 제공하기 때문에다. 개발자들은 클래스 다이어그램이 자신들을 위해 특별히 만들어졌다고 생각할 것이다. 하지만 다른 팀 멤버들 역시 이것을 유용하게 사용할 수 있다. 비즈니스 분석가들은 클래스 다이어그램을 사용하여 비즈니스 관점에서 시스템을 모델링 할 수 있다. 본 시리즈의 다른 기술자료를 참조하면 알겠지만, 다른 다이어그램들(액티비티, 시퀀스, statechart 다이어그램)은 이 클래스 다이어그램에서 모델링 및 문서화 된 클래스들을 참조하고 있다.

주

1 delayFlight은 리턴 값이 없다. delay 연산이 새로운 도착 시간을 리턴 해야 하고, 이것이 그러한 경우라면, 연산 시그너처는 delayFlight(numberOfMinutes : Minutes) : Date 가 될 것이다.

2 BankAccount 클래스가 OverdrawnAccountsReport 클래스에 대해 모르고 있다는 사실이 이상할 것이다. 이 모델링은 report 클래스가 자신들이 리포팅 하는 비즈니스 클래스만 알 수 있도록 하지만, 비즈니스 클래스는 자신들이 리포팅 되고 있다는 것을 모른다. 이로써, 객체들의 커플링이 느슨해지고, 시스템은 변화에 대한 적응성이 빨라진다.

3 패키지는 모델의 클래스들을 구성하는데 탁월하지만, 클래스 다이어그램은 모델링 되는 시스템에 대한 정보와 쉽게 통신한다. 패키지에 많은 클래스가 있는 경우, 하나의 큰 클래스 다이어그램을 만드는 대신 주제 별 클래스 다이어그램을 여러 개 사용하는 것이 더 낫다.

4 필자가 "all those members"라고 말할 때, 현재 다이어그램이 보여줄 클래스만 의미한다는 것을 알아야 한다. 콘텐트가 있는 패키지를 보여주는 다이어그램은 모든 콘텐트를 보여줄 필요가 없다. 일정 기준에 따라 포함된 엘리먼트의 일부만 보여줄 수 있다.

5 클래스 다이어그램을 그릴 때, 직사각형의 맨 윗칸에 «class»라고 표기해야 한다. 하지만 UML 스팩에서는 "class" 라는 텍스트를 표기하는 것은 선택 사항이고, «class»가 디스플레이 되지 않는 것으로 간주된다.

필자소개

Donald Bell은 IBM Global Services의 IT 전문가이고, 웹 기반 기술 애플리케이션 분야에서 고객을 지원하고 있다. ( bellds@us.ibm.com )

출처 : 한국 IBM

제공 : DB포탈사이트 DBguide.net

Q] 프로그램의 성능 측정은 어떤 원리로 가능한것인가요?

프로그램의 성능이나 부하 등을 측정해주는 프로그램을 profiler라고 부른다고 알고있는데요
이러한 프로그램들은 어떤 원리에 의해서 가능한것인가요?

함수이름과 그 함수의 호출횟수와 전체적인 비율이나 메모리 사용량까지 세세하게 나오는것으로 알고있는데
이는 운영체제의 도움을 받아 스스로 돌아가는 일반적인 프로그램과는 달라보이는거 같아서요

조금 오바해서 지금 나는 돌주먹으로 나무를 패고있는데 옆에서 달나라 로켓이 하늘을 뚫고 우주로 솟아오르는 광경을 본 느낌 같은걸 받았어요;

대략적이나마 호기심을 채울수 있을 정도의 설명이라도 부탁드립니다 (__)

A] 흔히 사용되는 방법으로 instrumentation과 sampling, simulation이 있는데요,

instrumentation은 코드 사이사이에 측정을 위한 코드를 집어 넣는 것입니다.
예를 들어 함수의 호출 횟수를 측정하고 싶으면
어딘가에 카운터를 위한 공간을 잡아 놓고 함수 시작에 카운터를 증가시키는 코드를 넣어 두면 되겠지요.
그리고 요즘 cpu들에는 대개 performance monitor를 제공하기 때문에,
cpu time을 측정할 때 performance counter를 읽는 코드를 삽입하기도 합니다.

sampling은 말 그대로 주기적으로 표본을 뽑는 것인데요,
예를 들어 cpu time을 측정하려고 할 때
특정 시간 마다 interrupt를 발생시켜 현재 program counter가 어느 함수 위치에 있는지를 보는 것이지요.
그러면 전체 실행 시간 중 특정 함수가 차지하는 비율을 sample의 비율로 생각하는 것입니다.

simulation은 java vm 처럼 프로그램을 가상의 cpu, memory를 가진 virtual machine에서 수행하면서
cycle 수, 메모리 사용량 등등을 측정하는 것입니다

"괴짜사용자" 시리즈: 프로세서 성능에 대한 고찰

Peter Seebach l 프리랜스 작가

시간이 감에 따라, 컴퓨터는 점점 빨라지고 있다고 얘기를 듣곤 한다. 그러나, 사용자들의 경험은 15년전에 비해 성능이 크게 향상되었다고 느끼지 못하고 있다. 저자인 Peter는 본 글을 통해 대부분의 프로세서 시간과 메모리가 어디에 사용되고 있는지 살펴보고 있다.

10년전쯤, 사람들이 매킨토시 컴퓨터상에서 Microsoft Word 가 너무 느리게 작동한다고 불평했던 것이 기억난다. 실제로 사용자는 이와 같은 큰 어플리케이션을 이용하면서 프로세서가 처리할 수 있는 것보다 더 빠르게 타이핑을 할 수 있었다. 그런데, 최근에도 이러한 상황이 여전히 발생하고 있다는 점을 발견했을 때, 나의 실망이 얼마나 컸을지 상상할 수 있을 것이다. 하나의 하드디스크를 가지고 있었던 내 최초의 컴퓨터는 1초안에 작은 명령행 유틸리티 하나를 로드했었고, 용량이 큰 그래픽 프로그램조차도 30초정도면 로딩했었다. 이들은 모두 좋은 스펙이었지만, 과거 15년동안 상황이 그리 크게 변하지 않았다는 것은 너무 슬픈 일이 아닌가?

여기서 궁금한 점은, "도대체 CPU 파워는 어디에 쓰이고 있는가?" 이다. 어떻게 1기가가 넘는 메모리를 가진 장비가, 15년전의 6메가정도의 메모리를 가진 장비에서 실행되는 어플리케이션의 속도를 내기에도 역부족일 수 있는 것인가? 이번 "괴짜사용자(The Cranky User)" 시리즈에서는 이 커다란 미스테리를 밝여볼 것이다. 이에 앞서 오래된 금언을 되새기고, 오늘날에 어떤 의미를 갖는지 살펴보자.

Moore의 법칙

Moore의 법칙은 잘못 인용되고 있는 것들 중 하나이다. 대부분의 전문가들은 컴퓨터는 18 개월마다 속도가 두 배로 증가한다고 주장하고 싶어한다. 사실 인텔 창립자 Gordon Moore는 1965년 컴포넌트 당 가장 싼 칩의 복잡함은 매년 두배로 증가했다는 것을 관찰했고, 이러한 트랜드는 약 10년간 지속될 것이라고 예견했다. 그런데 이것은 퍼포먼스가 두 배로 증가한다는 것을 의미하는 것은 아니다. 컴포넌트의 수가 그렇다는 것을 의미한다. Moore의 예견은 데이터에 의해 합리적으로 입증되었다. 1975년 그는 18 개월로 조정했으며 이것이 바로 대부분의 사람들이 요즘 인용하는 것이다.

재미있는 것은 Moore의 법칙은 시스템 디자인의 복잡함에 대해 언급하는 것 과는 달리 클럭(clock) 스피드에 대해서 많이 언급하지 않는다. 현대 CPU는 이전의 CPU와는 달리 많은 일을 수행한다. 예를 들어, 다중의 명령어를 동시에 실행할 수 있다. 또한 프로세싱 속도가 예견할 수 있는 비율로 증가한다는 것도 알려준다. 확실히 성능이 늘어났다.

놀라운 것은 대부분의 사용자들은 퍼포먼스가 15년 전에 비해서 확실히 나아진 것이 없다고 느낀다는 점이다. 이 프로세싱 시간에 대해 컴퓨터가 무엇을 할 수 있을까? OS X의 만화처럼 그려진 무지개 비치볼 커서에 대해 Usenet은 최면 같은 돌아가는 비치볼을 보느라 바쁘다고 논평했다.

농담은 집어치우고, 사실 컴퓨터는 과거 보다는 더 많은 일을 한다. 컴퓨터가 하는 일 중 대부분이 매우 미묘하고 사용자가 인지하는 영역 외에서 발생하고 있다. 많은 기능들이 자동화 되고 지난 칼럼에서 언급했듯이 이제 컴퓨터 없이 아무 것도 할 수 없다. 그리고 여전히 많은 것이 진행중이다. 요즘 컴퓨터 프로세싱 파워가 주로 어디에 쓰이는지를 살펴보자.

그래픽 디스플레이

현대적인 많은 시스템들은 텍스트를 렌더링하기 위해 반 앤티앨리어싱(antialiasing)을 사용한다. 이로서 텍스트 읽기가 쉬워지고, 저해상 모니터와 LCD 디스플레이의 가용성도 높아졌다. 단점은 반 앤티앨리어싱이 프로세싱 파워를 많이 소모한다는 점이다. 창이나 메뉴 뒤의 드롭 쉐도우 같은 시각 효과, 투명 메뉴와 효과, 실시간 효과 또한 많은 파워를 소모한다. 컴퓨터 메이커가 중점을 둬야 할 것은 대부분 사용자들이 이를 기대한다는 점이다.

예를 들어, 오래된 시스템에서는 비트맵 폰트를 사용했다. 이는 제공된 크기로 빠르게 렌더링 되었지만, 다른 크기로 보면 얼그러져 보인다. 대부분의 현대 시스템들은 실시간으로 아웃라인 폰트를 렌더링하는데, 현재 사용자들이 이를 사용하고 있다. 심지어 캐싱이 개입되어도 폰트 랜더링은 한 개 이상의 레이어의 프로세서 오버헤드를 추가한다. 하지만 어떤 벤더도 비트맵 폰트를 가진 인터페이스를 배포 하지 않는다.

현재 Mac 운영 체계는 비디오 카드의 렌더링 하드웨어가 추가 작업을 수행하도록 함으로서 그래픽 오버헤드 문제를 해결하고 있다. 비디오 카드는 두 번째 프로세서가 되고, 이로서 그래픽 프로세싱 시간이 줄어든다. 물론, 컴퓨터 인터페이스가 느려질 때는 대책이 없다.

안전과 보안

시스템 프로세싱 파워의 일정 부분은 애플리케이션의 향상된 안전과 보안 기능을 위해 사용된다. 대부분 최초로 어플리케이션은 안전성 체크에 많은 주의를 기울이지 않은 상태에서 작성되기 마련이므로, 이러한 기능의 상당수는 중요한 보안패치의 형태로 제공된다. 이러한 패치의 문제점은 시간이 지남에 따라 패치의 수가 점점 늘어난다는 것이며, 결국 각각의 패치는 시스템 성능에 크지 않은 영향을 미치지만, 이것들이 모이게 됨으로써 성능에 상당한 영향을 미치게 된다.

바이러스 스케너는 패치보다 더 많은 영향을 준다. 사용자의 일상적인 시스템 사용에 있어 바이러스가 중요한 요소로서 여겨짐에 따라, 개발자들은 바이러스를 물리치기 위해 더 많은 에너지(그리고 프로세싱 파워)를 소모하고 있다. 대부분의 바이러스 스캐너는 정기적으로 업데이트를 진행하며, 이 업데이트 작업은 작지만 무시하지 못할 만큼의 백그라운드 작업으로 진행된다. 아울러 업데이트후에는 이전보다 더 많은 파일들을 스캐닝하게 된다.

워드 프로세서용 매크로 바이러스가 존재한다는 점은 바이러스 스캐너가 실행 파일 뿐만 아니라, 데이터 파일도 스캐닝 해야 한다는 것을 의미한다. 결과적으로, 하나의 파일이 접근되기 전에 여러 차례의 스캐닝 작업이 일어나게 된다. 예를 들어, 다운로드된 파일은 그과정에서 일단 스캐닝을 거치게 되며, 압축파일이라면 그 내부의 파일들도 스캔된다. 또한 압축유틸리티를 이용하여 압축파일을 열어보거나 압축을 해제할 때마다 스캔작업이 일어나며, 압축이 풀린 파일을 열어볼때도 다시 스캔을 하게 된다.

이 모든 스캐닝에 많은 프로세싱 시간이 걸리고, 이것 때문에 시스템에서 실행되는 모든 프로그램에 영향이 미친다. 예를 들어, 많은 그래픽 파일을 사용하고 이들을 로딩하는 비디오 게임은 1시간 플레이 동안 12번 스캔되어야 할 같은 파일이 20MB나 된다.

보안은 프로세싱 파워를 사용할 만한 가치가 있고, 또 사용해야 한다. 대안이라고 하는 것은 더 나쁜다. 스파이웨어와 바이러스는 어마어마한 양의 시간을 소비한다. 컴퓨터가 느려지는 또 다른 원인은 트래픽 상에 있는 프로그램, 팝업 광고 등이다.

복잡한 프로그램

복잡한 프로그램은 느려진 프로세스의 가장 큰 용의자일 것이다. 애플리케이션이 복잡해지면서 코드도 더 많아지게 된다. 내가 지원 코드라고 부르는 이 코드는 개발자가 프로그램을 쉽게 작성하도록 도와준다. 매우 큰 프로그램은 중첩된 레이어의 지원 코드와 결합한다. 예를 들어, Mozilla의 리눅스 구현은 30개 또는 다른 지원 코드로 연결된다. Mozilla가 직접 사용하는 지원 코드를 위한 지원 코드도 포함해서 말이다.

일반적으로 코드 자체는 자신의 임무수행에 매우 효율적이며, 규모가 큰 어플리케이션 개발을 수월하게 한다.그러나 이러한 작은 코드 조각들이 예정된 방식으로 상호작용하도록 만들기 위한 추가코드는 또 다른 실행비용을 필요로 하게 된다. 다시한번 말하지만, 이렇게 반복되는 작은 비용들이 쌓여, 시스템 성능에 중대한 영향을 미치게 된다.

Windows에서 사용하는 몇몇 프로그램들은 시스템 시작 시 특별한 프로그램을 실행한다. 이들 각 프로그램들은 각자의 공유 라이브러리를 미리 로딩해서 프로그램은 보다 빠르게 시작된다. 응답성이 높은 내 시스템의 경우 이것을 사용할 때 지연 시간은 5분이다. 이유는? 이것은 십여 개의 프로그램을 실행하여 프로그램 로딩을 빠르게 했기 때문이다. 아이러니는 그 당시에도 이상하지 않았고 지금도 마찬가지라는 점이다.

결론

어느정도의 코드 증가는 최근의 복잡한 경향을 고려하면 어쩔수 없는 것일 수 있다. 이글에서는 그중 몇가지 주요 요인에 대해 이야기했다. 실제로는 사용자에게 별로 유용하지 않은 추가작업을 하기위해 프로세서를 필요로 하는 어플리케이션들, 누구도 이해하지 못하고 시스템이 요구하지 않음에도 실행되는 지원코드들, 어플리케이션의 빠른 개발에만 치중하느라 안전성이 부족하여 발생하는 수많은 패치들이 여기에 속한다. 이러한 문제의 주요한 원인중 하나는 제때에 시장에 출시해야 한다는 지나친 강조를 들 수 있다.

다른 원인으로는 소위 Second-System 효과라는 것을 들 수 있다. 이것은 Frederick Brooks가 "The Mythical Man-Month"라는 글에서 처음 논의한 내용으로, 개발자들이 두번째 프로젝트를 수행하면서 잘 만들고자 하는 의도하에 제대로 고려되지 않은 기능들을 포함함으로써, 시스템이 쓸데없이 비대해지게 된다는 것이다. 불행하게도 오늘날 널리 사용되는 상당수의 시스템이 Second-System에 속한다. 더 심각한 것은 Second-System 디자인에 의해 비대해진 시스템이 다음 버전에서의 호환성 유지를 위해 그대로 유지되고 있다는 점이다.

다행히, 최악의 상황은 끝난 것처럼 보인다. 800-Mhz 이상의 빠른 프로세서가 세상에 나오면서, 사용자는 계속된 업그레이드의 필요성이 줄어 들었다. 오늘날 대부분의 사용자들은 컴퓨터가 수행하고 있는 작업이 완료되기를 기다리며 여러시간을 소비할 필요없이, 자신의 작업을 더 빠른시간내에 마무리 할 수 있다.

이번 주 수행 목표: 몇 개의 애플리케이션을 동시에 시작하고 시작 시간을 측정하라. 5년 동안 이를 반복하고 시간이 지나면서 이것이 나아지고 있는지를 확인하라.

참고자료

◆ Everything's automated! (developerWorks, January 2005).

◆ Usability vs. security (developerWorks, August 2002).

◆ A peek through the veil at 2005 (developerWorks, January 2005).

◆ History of chipmaking at IBM (developerWorks, March 2004).

◆ Reducing the user interface (developerWorks, June 2001).

◆ Moore's Law.

◆ second-system effect.

◆ Global Services Usability Engineering team

◆ Web Architecture zone

◆ Browse for books

제공 : DB포탈사이트 DBguide.net