주제

설계 및 구현 메커니즘 소개 페이지 맨 위

설계 메커니즘은 대응되는 분석 메커니즘(개념: 분석 메커니즘 참조)을 정제한 메커니즘입니다. 설계 메커니즘은 개념적 분석 메커니즘에 구체적인 세부사항을 추가하지만 특정 기술(예: 특정 벤더의 객체 지향 데이터베이스 관리 시스템 구현)을 요구하지는 않습니다. 분석 메커니즘과 같이, 설계 메커니즘은 하나 이상의 패턴, 이 경우에는 구조적 또는 설계 패턴을 인스턴스화할 수 있습니다.

마찬가지로 구현 메커니즘은 예를 들어 특정 프로그래밍 언어 및 기타 구현 기술(예: 특정 벤더의 미들웨어 제품)을 사용하여 대응되는 설계 메커니즘을 정제한 것입니다. 구현 메커니즘은 하나 이상의 관용구 또는 구현 패턴을 인스턴스화합니다.

예: 설계 메커니즘의 특성 페이지 맨 위

지속성에 대한 분석 메커니즘을 고려하십시오.

  • 여러 개의(2000개) 작은 객체(각 200바이트)는 몇 초 동안만 저장되고 남아 있을 필요가 없을 수 있습니다.
  • 몇몇 아주 큰 객체는 여러 달 동안 디스크에 영구적으로 저장되고 갱신되지 않지만, 매우 복잡한 검색 방법을 사용할 수 있습니다.

이러한 객체에는 여러 가지의 지속성 지원이 필요합니다. 지속성 지원을 위한 설계 메커니즘의 특성은 다음과 같습니다.

  • 메모리 내 기억장치; 특성: 최대 1MB용(크기 x 볼륨); 매우 빠른 읽기, 쓰기, 갱신 액세스.
  • 플래시 카드; 특성: 최대 8MB용; 느린 갱신 및 쓰기 액세스; 중간 정도의 읽기 액세스.
  • 2진 파일; 특성: 100KB - 200MB용; 느린 갱신; 느린 읽기 및 쓰기 액세스.
  • 데이터베이스 관리 시스템(DBMS); 특성: 10KB 이상용(본질적으로 상위 제한 없음); 훨씬 느린 갱신, 읽기 및 쓰기 액세스.

이러한 속도는 단지 메모리 내 기억장치에 비해 상대적으로 '느린' 속도로 평가됩니다.  일부 환경에서는 캐싱을 사용하여 눈에 보이는 액세스 시간을 향상시킬 수 있습니다.

컨텐츠에 설명된 다이어그램

 

설계 및 구현 메커니즘 간의 맵핑 정제 페이지 맨 위

초기에 설계 메커니즘과 구현 메커니즘 사이의 맵핑은 덜 최적화된 것으로 나타나지만, 실행 중인 프로젝트를 가져와서 아직 보이지 않는 위험을 식별하고 더 세부적인 조사 및 평가를 트리거합니다. 프로젝트가 계속 수행되고 더 많은 지식을 얻을수록 맵핑을 정제할 필요가 있습니다.

중복되는 경로를 제거하고 "하향식" 및 "상향식"으로 모두 작업하여 설계 및 구현 메커니즘 사이의 맵핑을 계속 반복적으로 정제하십시오.

하향식 작업. "하향식"으로 작업하는 경우 새로 작성되고 정제된 유스 케이스 구현은 필요한 분석 메커니즘을 통해 필요한 설계 메커니즘에 대한 새 요구사항을 표시합니다. 이러한 새 요구사항은 메커니즘을 강제로 서로 분리시켜 설계 메커니즘의 추가 특성을 드러낼 수 있습니다. 또한 시스템의 복잡도와 성능 사이에서 서로 절충되기도 합니다.

  • 다른 설계 메커니즘이 너무 많으면 시스템이 복잡해질 수 있습니다.
  • 설계 메커니즘이 너무 적으면 특성 값의 적절한 범위의 한계에 이르는 일부 구현 메커니즘에 대한 성능 문제가 생길 수 있습니다.

상향식 작업. "상향식"으로 작업하여 사용 가능한 구현 메커니즘을 조사하는 경우, 여러 설계 메커니즘을 한 번에 충족시키는 제품을 찾을 수 있지만 설계 메커니즘을 강제로 일부 적응하거나 재분할할 수 있습니다. 사용하는 구현 메커니즘의 수를 최소화하려고 하지만, 구현 메커니즘의 수가 너무 적으면 성능 문제를 일으킬 수도 있습니다.

클래스 A의 객체를 저장하는 데 DBMS를 사용하기로 결정한 경우 이를 사용하여 시스템의 모든 객체를 저장하는 데 사용하려 할 수 있습니다. 이는 매우 비효율적이거나 매우 성가신 일로 나타날 수 있습니다. 지속성이 필요한 모든 객체를 다 DBMS에 저장해야 하는 것은 아닙니다. 일부 객체는 지속적일 수 있지만 해당 어플리케이션에서는 자주 액세스되고 다른 어플리케이션에서는 드물게 액세스될 수 있습니다. 객체를 DBMS에서 메모리로 읽어 들이고 주기적으로 동기화하는 혼합된 전략이 최적의 방법이 될 수 있습니다.

항공편은 빠른 액세스를 위해서는 메모리에 저장되고 장기간 지속성을 위해서는 DBMS에 저장될 수 있습니다. 그러나 이 방법은 두 가지를 동기화하기 위한 메커니즘을 필요하게 만듭니다.

여러 특성 간의 절충안으로서 두 가지 이상의 설계 메커니즘을 클라이언트 클래스와 연관시키는 방법은 보기 드문 일이 아닙니다.

구현 메커니즘은 종종 상시 재고 컴포넌트(운영 체제 및 미들웨어 제품)의 번들에 제공되므로 비용, 임피던스 불일치 또는 양식의 균일성을 기반으로 한 최적화가 발생해야 합니다. 또한 메커니즘은 대개 내부 종속적이므로 설계 메커니즘으로 서비스를 명확히 분리하기 어렵게 만듭니다.

  • 공고 메커니즘은 프로세스 간의 의사소통 메커니즘을 기반으로 할 수 있습니다.

  • 오류 보고 메커니즘은 지속성 메커니즘을 기반으로 할 수 있습니다.

정제는 전체 구현 단계에 걸쳐 계속 수행되며 항상 다음 사이에서 절충됩니다.

  • 예상된 특성에 관한 설계 메커니즘의 클라이언트 요구사항을 정확히 '충족시킴'.
  • 너무 많은 서로 다른 구현 메커니즘을 획득하고 통합하는 데 드는 비용 및 복잡도.

전체적인 목표는 항상 대형 시스템에 개념적인 무결성과 단순성 및 간결성을 제공하는 단순하고 명확한 메커니즘 세트를 가지는 것입니다.

예: 설계 메커니즘을 구현 메커니즘에 맵핑 페이지 맨 위

지속성 설계 메커니즘은 다음과 같이 구현 메커니즘에 맵핑될 수 있습니다.

컨턴츠에 설명된 다이어그램

분석 메커니즘 및 설계 메커니즘 간의 가능한 맵핑. 점선으로 된 화살표는 설계 메커니즘의 특성이 분석 메커니즘으로부터 상속되지만 특수화되고 정제되는 것을 내포하는 "특수화됨"을 의미합니다.

메커니즘 최적화 작업을 완료하면 다음 맵핑이 나타납니다.

컨텐츠에 설명된 다이어그램

클라이언트 클래스에 대한 설계 결정은 메커니즘 간의 맵핑에 따라 이루어집니다. 항공편 클래스에는 두 가지 형식의 지속성, 즉, 이미 작성된 라이브러리 루틴에 의해 구현되는 메모리 내 기억장치와 재고 ObjectStorage 제품과 함께 구현되는 데이터베이스가 필요합니다.

맵은 구현 메커니즘을 변경할 때 클라이언트 클래스를 쉽게 판별할 수 있도록 양방향으로 탐색할 수 있어야 합니다.

설계 메커니즘 설명 페이지 맨 위

설계 메커니즘과 설계 메커니즘 사용에 대한 세부사항은 ../../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website결과물: 프로젝트 특정 가이드라인에 문서화되어 있습니다. 분석 메커니즘과 설계 메커니즘 그리고 구현 메커니즘의 서로에 대한 관계(또는 맵핑) 및 이러한 선택사항의 연관 원리는 결과물: 소프트웨어 구조 문서에 문서화되어 있습니다.

분석 메커니즘과 같이, 설계 메커니즘은 하나 이상의 구조적 또는 설계 패턴을 인스턴스화할 수 있는 협업을 사용하여 모델링될 수 있습니다.

예: 지속성 메커니즘

이 예에서는 JDBC™(Java Data Base Connectivity)에서 설명된 RDMS 기반 지속성에 대한 패턴의 인스턴스를 사용합니다.  여기에서 설계를 나타낼 수 있지만 JDBC는 일부 클래스에 대한 실제 코드를 제공하므로, 이 단계는 여기에 표시된 부분부터 구현 메커니즘까지 이르는 짧은 단계입니다.

정적 보기 그림: JDBC가 협업에 있는 클래스(정확히 말하면, 분류자 역할)를 표시합니다.

컨텐츠에 설명된 다이어그램

정적 보기: JDBC

노란색으로 채워진 클래스는 제공된 클래스이고 나머지 클래스(myDBClass 등)는 메커니즘을 작성하기 위해 설계자가 바인드한 것입니다.

JDBC에서 클라이언트는 지속적 데이터를 읽고 쓰기 위해 DBClass를 사용하여 작업합니다. DBClass는 DriverManager 클래스를 사용하여 JDBC 데이터베이스를 액세스하는 책임을 맡습니다. 데이터베이스 연결이 열리면, DBClass는 기본 RDBM로 전송되고 명령문 클래스를 사용하여 실행되는 SQL 문을 작성할 수 있습니다. 명령문 클래스는 데이터베이스에 "설명하는" 클래스입니다. SQL 조회의 결과는 ResultSet 객체에 리턴됩니다. 

DBClass 클래스는 다른 클래스 인스턴스를 지속시키는 책임을 맡습니다. DBClass는 OO에서 RDBMS로의 맵핑을 이해하고 RDBMS와 인터페이스하기 위한 작동을 포함합니다. DBClass는 객체를 일반화하여 그 객체를 RDBMS에 쓰고 RDBMS에서  객체 데이터를 읽고 객체를 빌드합니다. 지속적인 모든 클래스는 대응되는 DBClass를 가집니다. 

PersistentClassList는 데이터베이스 조회(예: DBClass.read())의 결과로 지속적 객체 세트를 리턴하는 데 사용됩니다.

이제 메커니즘이 실제로 작업하는 방법을 표시하기 위해 일련의 동적 보기를 표시합니다.

컨텐츠에 설명된 다이어그램

JDBC: 초기화

지속적 클래스를 액세스하려면 먼저 초기화가 수행되어야 합니다.

데이터베이스에 대한 연결을 초기화하려면 DBClass가 URL, 사용자 및 암호를 사용하여 DriverManager getConnection() 조작을 호출함으로써 적절한 드라이버를 로드해야 합니다.

getConnection() 조작은 주어진 데이터베이스 URL에 대한 연결을 구축하려고 시도합니다. DriverManager는 등록된 JDBC 드라이버 세트에서 적절한 드라이버를 선택하려고 시도합니다.

매개변수:

url: jdbc:subprotocol:subname 양식의 데이터베이스 URL. 이 URL은 실제 데이터베이스 서버를 찾는 데 사용되며 이 인스턴스에서는 웹과 관련되지 않습니다.

user: 연결을 작성 중인 데이터베이스 사용자.

pass: 사용자의 암호.

다음을 리턴합니다.

URL에 대한 연결.

컨텐츠에 설명된 다이어그램

JDBC: 작성

새 클래스를 작성하기 위해 지속 클라이언트는 DBClass에게 새 클래스를 작성하도록 요청합니다. DBClass는 기본값을 사용하여 PersistentClass의 새 인스턴스를 작성합니다. 그런 다음, DBClass는 연결 클래스 createStatement() 조작을 사용하여 새 명령문을 작성합니다. 명령문이 실행되고 데이터가 데이터베이스에 삽입됩니다.

컨텐츠에 설명된 다이어그램

JDBC: 읽기

지속적 클래스를 읽기 위해 지속 클라이언트가 DBClass에게 읽도록 요청합니다. DBClass는 연결 클래스 createStatement() 조작을 사용하여 새 명령문을 작성합니다. 명령문이 실행되고 데이터가 ResultSet 객체에 리턴됩니다. 그런 다음, DBClass는 PersistentClass의 새 인스턴스를 작성하고 검색된 데이터로 채웁니다. 데이터가 콜렉션 객체인 PersistentClassList 클래스의 인스턴스에 리턴됩니다.

참고: executeQuery()에 전달된 문자열은 read()로 전달된 문자열과 실제로 동일한 필요는 없습니다. DBClass는 데이터베이스에서 지속적 데이터를 검색하기 위해 read()로 전달된 기준을 사용하여 SQL 조회를 빌드합니다. 이는 DBClass의 클라이언트가 올바른 조회를 작성하기 위해 데이터베이스 내부에 대한 지식을 가져야 할 필요가 없기 때문입니다. 이 지식은 DBClass에 캡슐화됩니다.

컨텐츠에 설명된 다이어그램

JDBC: 갱신

클래스를 갱신하기 위해 지속 클라이언트는 DBClass에게 갱신하도록 요청합니다. DBClass는 주어진 PersistentClass 객체에서 데이터를 검색하고 연결 클래스 createStatement() 조작을 사용하여 새 명령문을 작성합니다. 명령문이 빌드되면, 갱신이 실행되고 데이터베이스가 클래스의 새 데이터로 갱신됩니다.

주의: PersistentClass를 "일반화"하여 데이터베이스에 쓰는 작업은 DBClass의 작업입니다. 이는 SQL 문을 작성하기 전에 해당 PersistentClass에서 검색되어야 하기 때문입니다.

참고: 위의 메커니즘에서 PersistentClass는 모든 지속적 데이터에 대한 액세스 루틴을 제공하여 DBClass가 이를 액세스할 수 있도록 해야 합니다. 이 방법은 개인용이었을 수 있는 특정 지속적 속성에 대한 외부 액세스를 제공합니다. 데이터를 캡슐화하는 클래스에서 지속성 지식을 끌어내기 위해서는 이러한 대가를 치러야 합니다.

컨텐츠에 설명된 다이어그램

JDBC: 삭제

클래스를 삭제하기 위해 지속 클라이언트는 DBClass에게 PersistentClass를 삭제하도록 요청합니다. DBClass는 연결 클래스 createStatement() 조작을 사용하여 새 명령문을 작성합니다. 명령문이 실행되고 데이터가 데이터베이스에서 제거됩니다.

이 설계의 구현에서 DBClass를 지속적 클래스에 맵핑하는 데 대해 몇 가지 결정을 내릴 수 있습니다(예: 지속적 클래스당 하나의 DBClass를 갖게 하고 지속적 클래스를 적절한 패키지에 할당함). 이러한 패키지는 DriverManager, 연결, 명령문 및 ResultSet와 같은 지원 클래스를 포함하는 제공된 java.sql(JDBC API 문서화 참조) 패키지에 종속됩니다.



Rational Unified Process   2003.06.15