디자인 메커니즘은 해당 분석
메커니즘을 정제한 것입니다(개념: 분석 메커니즘
참조). 디자인 메커니즘은 구체적인 세부사항을 개념 분석 메커니즘에 추가하지만 특정 기술을 요구하지는 않습니다(예: 특정 벤더의 객체 지향 데이터베이스 관리 시스템 구현). 분석 메커니즘에서와 같이, 디자인
메커니즘은 하나 이상의 패턴을 인스턴스화할 수 있습니다(이 경우 아키텍처 또는 디자인
패턴).
마찬가지로, 구현 메커니즘은 특정 프로그래밍 언어와 기타 구현 기술(예: 특정 벤더의 미들웨어 제품)을 사용하여 해당되는 디자인 메커니즘을 정제합니다. 구현
메커니즘은 하나 이상의 관용 표현 또는 구현 패턴을 인스턴스화할 수 있습니다.
지속성에 대한 분석 메커니즘을 고려해 보십시오.
-
지속되지 않아도 단 몇 초 동안 많은(2,000) 소규모 오브젝트(각각 200바이트)를 저장해야 할 수 있습니다.
-
아주 큰 몇 개의 오브젝트를 갱신하지 않지만 정교한 검색 방법을 사용하여 몇 달 동안 영구적으로 디스크에 저장해야 할 수 있습니다.
이 오브젝트는 지속성을 위해 다른 지원을 필요로 합니다. 지속성 지원을 위한 다음의 디자인 메커니즘 특성을 식별할 수 있습니다.
-
인메모리 기억장치. 특성: 총 1Mb까지(크기 x 볼륨). 읽기, 쓰기, 갱신을 위한 액세스가 아주 빠릅니다.
-
플래시 카드, 특성: 8Mb까지. 갱신 및 쓰기 액세스는 느리고 읽기는 액세스 속도는 보통입니다.
-
2진 파일. 특성: 100Kb - 200Mb. 갱신이 느리고 읽기 및 쓰기 액세스 속도도 느립니다.
-
데이터베이스 관리 시스템(DBMS). 특성: 100Kb 이상(상한 없음). 갱신, 읽기 및 쓰기 액세스 속도가 더 느립니다.
이 속도는 인메모리 기억장치에 비교하여 단지 '느리다'는 것입니다. 명확하게 말하면 어떤 환경에서는 캐싱을 사용하면 확실하게 액세스 시간이 개선됩니다.
초기에, 디자인 메커니즘과 구현 메커니즘 사이의 맵핑은 최적의 상태보다는 덜하지만 프로젝트를 실행하고 아직 발견되지 않는 위험성을 식별하며 추가 조사 및 평가를 트리거합니다. 프로젝트가 계속되고 더 많은 지식을
얻게 되면 맵핑도 정제해야 합니다.
반복적으로 진행하여 디자인 및 구현 메커니즘 사이의 맵핑을 정제하여 "하향식" 및 "상향식" 둘 다로 작동하는 중복 경로를 제거하십시오.
하향식 작업. "하향식"으로 작업할 때 신규 및 정제된 유스 케이스 실현은 필요한 분석 메커니즘을 통해 필요한 디자인 메커니즘의 새 요구사항이 됩니다. 이와 같은 새 요구사항은 디자인 메커니즘의 추가
특성을 다루지 않을 수 있으므로 메커니즘 사이를 분할해야 합니다. 또한 다음과 같이 시스템의 복잡도와 성능 사이에 절충할 수도 있습니다.
-
서로 다른 디자인 메커니즘이 너무 많으면 시스템이 너무 복잡하게 됩니다.
-
디자인 메커니즘이 너무 적으면 일부 구현 메커니즘에 대해 타당한 특성 값 범위의 한계가 늘어나는 성능 문제가 발생할 수 있습니다.
상향식 작업. "상향식"으로 작업하여 사용 가능한 구현 메커니즘을 조사할 경우, 몇 개의 디자인 메커니즘을 충족하는 제품을 한 번에 찾을 수 있지만 사용자의 디자인 메커니즘을 적응시키거나 다시
파티션해야 합니다. 사용하는 구현 메커니즘 수를 최소화할 수 있지만 너무 적으면 성능 문제점이 발생할 수도 있습니다.
DBMS를 사용하여 클래스 A의 오브젝트를 저장할 것을 결정하면 DBMS를 사용하여 모든 오브젝트를 시스템에 저장할 것을 알려줄 수 있습니다. 이 방법은 매우 비효율적이거나 번거로운 방법일 수 있습니다. 지속성이
필요한 모든 오브젝트를 DBMS에 저장해야 하는 것은 아닙니다. 일부 오브젝트는 지속될 수 있지만 해당 응용프로그램이 자주 액세스하고 다른 응용프로그램은 아주 간혹 액세스할 수 있습니다. 오브젝트를 DBMS에서
메모리로 읽어들이고 정기적으로 동기화하는 혼성 전략이 최상의 접근 방식이 될 수 있습니다.
예제
조종법은 빠른 액세스를 위해서는 메모리에, 장기간 지속성을 위해서 DBMS에 저장할 수 있습니다. 그러나 두 가지를 동기화할 메커니즘에 대한 필요성이 발생합니다.
보통 서로 다른 특성 사이의 절충안으로 클라이언트 클래스와 연관되는 두 개 이상의 디자인 메커니즘을 갖기도 합니다.
구현 메커니즘은 종종 기존 컴포넌트(운영 체제 및 미들웨어 제품)에서 번들로 제공되므로, 비용, 임피던스 불일치 또는 스타일의 균일성을 기반으로 한 최적화가 발생해야 합니다. 또한 메커니즘은 종종 상호 종속적이어서
서비스를 디자인 메커니즘으로 명백하게 분리하는 것이 어렵습니다.
예제
정제는 전체 정제(Elaboration) 단계에서 계속되며 항상 다음 사이에서 절충됩니다.
-
예상되는 특성 측면에서, 디자인 메커니즘의 클라이언트 요구사항에 정확히 '맞는지' 여부
-
확보하고 통합해야 하는 서로 다른 구현 메커니즘이 너무 많은 경우의 비용 및 복잡도
전체 목적은 항상 대규모 시스템에 개념적 무결성, 단순성 및 정밀함을 제공하는 명백한 단순 메커니즘 세트를 갖는 것입니다.
지속성 디자인 메커니즘은 다음과 같이 구현 디자인에 맵핑할 수 있습니다.
분석 메커니즘과 디자인 메커니즘 사이의 가능한 맵핑. 점 화살표는 "다음에 의해 전문화됨"을 의미하며, 이는 디자인 메커니즘의 특성이 분석 메커니즘에서 상속되지만 전문화되고 정제됨을 의미합니다.
메커니즘 최적화를 완료하고 나면 다음 맵핑이 존재합니다.
메커니즘 사이의 맵핑 측면에서 클라이언트 클래스의 디자인 결정. 비행 클래스는 두 가지 양식의 지속성을 필요로 합니다. 이미 만들어져 있는 라이브러리 루틴에서 구현된 인메모리 기억장치와 기존
ObjectStorage 제품으로 구현된 데이터베이스에서 지속되어야 합니다.
구현 메커니즘을 변경할 때 클라이언트 클래스를 판별하는 것이 쉽도록, 맵은 두 가지 방향 모두에서 탐색 가능해야 합니다.
디자인 메커니즘과 사용에 대한 세부사항은 중간 산출물: 프로젝트 가이드라인에 문서화되어 있습니다. 분석 메커니즘과 디자인 메커니즘의 관계(맵핑)와 선택에 연관된
근거는 중간 산출물: 소프트웨어 아키텍처 문서를 참조하십시오.
분석 메커니즘에서와 같이, 디자인 메커니즘은 하나 이상의 아키텍처 또는 디자인
패턴을 인스턴스화할 수 있는 협업을 사용하여 모델링할 수 있습니다.
예제: 지속성 메커니즘
이 예제는 JDBC™(Java Data Base Connectivity)에서
나온 RDBMS 기반 지속성에 대한 패턴의 인스턴스를 사용합니다. 여기에 디자인을 표시하지만 JDBC는 클래스 중 일부에 대한 실제 코드를 제공하므로, 여기에서 구현 메커니즘에 제시되는 단계는 간단합니다.
그림 정적 보기: JDBC는 협업의 클래스(엄격하게, 클래스류 역할)를 보여줍니다.
정적 보기: JDBC
노란색으로 채워진 클래스는 제공된 클래스이고 다른 클래스(myDBClass 등)는 메커니즘을 작성하기 위해 디자이너가 바인드했습니다.
JDBC에서, 클라이언트는 지속적 데이터를 읽고 쓰기 위해 DBClass로 작업합니다. DBClass는 DriverManager 클래스를 사용하여 JDBC 데이터베이스에 액세스해야 합니다.
데이터베이스 연결이 열리면 DBClass는 근본적인 RDBMS에 송신하고 Statement 클래스를 사용하여 실행할 SQL 문을 작성할 수 있습니다. Statement 클래스는
데이터베이스에 "알리는" 대상입니다. SQL 조회 결과는 ResultSet 오브젝트로 리턴됩니다.
DBClass 클래스는 다른 클래스 인스턴스가 지속되도록 해야 합니다. 이 클래스는 OO-to-RDBMS 맵핑을 이해하고 RDBMS와 인터페이스하는 동작을 수반합니다. DBClass는 오브젝트를
평이하게 하여 RDBMS에 쓰고 RDMS로부터 오브젝트 데이터 를 읽은 후 오브젝트를 빌드합니다. 지속되는 모든 클래스에는 해당되는
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가
Connection 클래스 createStatement() 오퍼레이션을 사용하여 새 명령문을 작성합니다. 이 명령문이 실행되고 데이터가 데이터베이스에 삽입됩니다.
JDBC: 읽기
지속적 클래스를 읽을 경우, 지속성 클라이언트는 DBClass에 클래스를 읽을 것을 요청합니다. 그러면 DBClass가 Connection 클래스 createStatement() 오퍼레이션을 사용하여 새 명령문을
작성합니다. 이 명령문이 실행되고 데이터가 ResultSet 오브젝트로 리턴됩니다. 그런 다음 DBClass는 PersistentClass의 새 인스턴스를 작성하고 검색된 데이터로 이 인스턴스를 채웁니다. 데이터는
PersistentClassList 클래스의 인스턴스인 콜렉션 오브젝트로 리턴됩니다.
참고: executeQuery()로 전달된 문자열은 read()에 전달된 문자열과 정확이 같지 않아도 됩니다. DBClass는 read()에 전달된 기준을 사용하여 데이터베이스로부터 지속적 데이터를 검색할 SQL
조회를 빌드합니다. 이는 DBClass 클라이언트가 데이터베이스의 내부사항을 알지 못해도 올바른 조회를 작성할 수 있도록 하기 위해서입니다. 이 지식은 DBClass 내에서 캡슐화됩니다.
JDBC: 갱신
클래스를 갱신할 경우, 지속성 클라이언트는 DBClass에 클래스를 갱신할 것을 요청합니다. DBClass는 지정된 PersistentClass 오브젝트에서 데이터를 검색하고 Connection 클래스
createStatement() 오퍼레이션을 사용하여 새 명령문을 작성합니다. 명령문이 빌드되면 갱신이 실행되고 데이터베이스는 클래스의 새 데이터로 갱신됩니다.
기억해야 할 사항: PersistentClass를 "평이하게" 하고 데이터베이스에 쓰는 것은 DBClass의 작업입니다. SQL 문을 작성하기 전에 지정된 PersistentClass에서 검색해야 하기 때문입니다.
참고: 위의 메커니즘에서 PersistentClass는 모든 지속적 데이터에 대해 액세스 루틴을 제공해야 합니다. 그러면 DBClass가 액세스 루틴에 액세스할 수 있습니다. PersistentClass는 특정의
지속적 속성에 대해 외부 액세스를 제공합니다. 그렇지 않으면 이 지속적 속성은 개인용이 됩니다. 이는 데이터를 캡슐화하는 클래스의 외부에 지속성 관련 지식을 두는 댓가입니다.
JDBC: 삭제
클래스를 삭제할 경우, 지속성 클라이언트는 DBClass에 PersistentClass를 삭제할 것을 요청합니다. 그러면 DBClass가 Connection 클래스 createStatement() 오퍼레이션을
사용하여 새 명령문을 작성합니다. 이 명령문이 실행되고 데이터가 데이터베이스에서 제거됩니다.
이 디자인의 구현에서는 DBClass에서 지속적 클래스로의 맵핑에 대해 일부 결정하게 됩니다(예: 지속적 클래스당 하나의 DBClass를 가지며 이 클래스를 적절한 패키지에 할당하도록 함). 이 패키지는 지원
클래스인 DriverManager, Connection, Statement 및 ResultSet를 포함하는 제공된 java.sql(JDBC™ API 문서
참조) 패키지에 대한 종속성을 갖습니다.
|