상세 설계에서 해 야할 작업

상세 설계는 개념 설계를 구현이 가능한 수준의 설계 산출물로 변환하는 작업이다. 다음과 같은 작업을 수행한다.

• 개념 설계의 클래스에 대한 속성 타입 설정
• 오퍼레이션의 매개변수와 반환값 설정
• 클래스의 relation을 association 클래스 등으로 구체화
• 메커니즘을 구현하기 위한 클래스 추가
• 설계 패턴이 적용되는 클래스 추가
• DB 전문가와 협의하여 엔터티 클래스의 상속 제거, 정규화
• 양 방향 association을 단 방향으로 수정
• 불필요한 association 제거
• PK와 FK 등 키 설정
• 오퍼레이션 중 DB에서 구현할 것을 표시함(stored procedure, trigger, check등)
• transaction, 보안, isolation level을 위한 stereotype 설정
• 오퍼레이션에 대한 알고리즘 작성

데이터베이스 관련 상세 설계 산출물(Database Modeling in UML)

DB와 관련한 설계 산출물 정의는 아래와 같다.

그림 Ⅴ-36. DB 설계 산출물 정의

그림 Ⅴ-37. 클래스, 속성 그리고 오퍼레이션

그림 Ⅴ-38. UML Class model notation

그림 Ⅴ-39. Aggregation Relationships

DB설계 과정 시 클래스들과의 관계(association), 상속(inheritance) 그리고 집합(aggregation)을 포함시켜 클래스 모델을 작성한다. Model-View-Control 설계 패턴을 사용하여 지속성(persistent)을 요구하는 클래스를 식별한다.

그림 Ⅴ-40. UML Relationship

식별된 지속성 클래스에 대하여 관계형 테이블 맵을 작성한다.

그림 Ⅴ-41. 클래스와 테이블의 매핑

서버 관련 상세 설계 산출물

서버 관련 엔터티빈 설계 정의는 아래와 같다.

그림 Ⅴ-34. 엔터티 빈 설계 정의 예제

서버 관련 세션 빈 설계 정의는 아래와 같다.

그림 Ⅴ-35. 세션 빈 설계 정의 예제

서버 관련 설계 산출물 정의시 세션빈에 대한 알고리즘 설계서와 시퀀스 다이어그램을 포함하여야한다.

UI 상세 설계 산출물

UI 상세 설계 산출물 구조는 아래와 같다.

그림 Ⅴ-32. UI네비게이션 모델

UI에 대한 화면 정의는 아래와 같다.

그림 Ⅴ-33. UI 화면 정의 예제

화면 구현 방법 기술

• 화면의 입력 제약 사항

이름은 20자리로 제한하시요.

주민등록번호는 14자리로 제한하시요.

생년월일은 화면에서 받은 데이터를 YYYYMMDD의 형식으로 저장하시요.

성별은 남자는 string "M", 여자는 string "F"로 저장하시요.

혈액형은 "A","B","AB","O"로 구분하시요.

RH형은 "RH+","RH-"로 구분하시요.

우편번호는 10자리로 제한하시요.

주소는 두줄이며 첫번째 줄은 집주소, 두 번째 주소는 직장 주소가 들어갑니다. 모두 50자리로 제한하시요.

집전화번호와 직장 전화번호는 20자리로 제한하고 –를 사용하여 번호를 구분하시요.(예: 02-3060-4050)

이메일은 20자리로 제한하시요.

개인 및 가족 병력은 100자리로 제한하시요.

• 알고리즘 설계서

PatientValue 객체를 생성한다.(예 PatientValue patient = new PatientValue() )

PatientValue 객체의 속성에 화면에서 입력한 값을 넣는다.
(address1: 집주소, address2: 회사주소, bloodType: 혈액형, citizenNum: 주민등록번호, dateOfBirth: 생년월일, email: 이메일, gender: 성, patientName: 이름, phoneHome: 집 전화번호, phoneOffice: 사무실 전화번호, thType: RH 타입, zipCode: 우편번호, note: 개인 및 가족 병력)

PatientControlBean.registerPatient를 호출하고 입력값은 PatientValue 객체를 넣는다.)

3을 처리할 때 화면의 로직에서 TX의 시작과 끝을 명시하지 말 것(이미 PatientControlBean에서 tx를 시작하고 끝내도록 만들어져 있습니다.)

PatentControlBean.registerPatient에서 넘어온 exception을 화면에서 잡아서 messagebox로 뿌려줄 것.(exception이 발생하면 환자 정보 화면으로 변경되지 않습니다.)

3이 정상적으로 처리되면 리턴값 PatientValue 객체를 받고 환자 정보 화면으로 바뀌도록 할 것

환자 정보 화면은 PatientValue 객체를 사용하여 화면을 보여줄 것

환자 정보에서 진찰등록증 보기를 누르면 진찰 등록증 화면이 popup으로 뜨고 등록번호는 PatientValue 객체의 patientCode 속성을 사용하여 진찰등록증 화면을 보여줄 것.

취소 버튼을 누르면 환자 등록 화면에 들어간 데이터가 삭제되고 빈 화면이 보이도록 하시요.

상세 설계 산출물

UML 표기법을 최대한 활용하고 개발자들이 상세 설계 문서를 보고 개발을 진행할 수 있도록 하는 상세 설계 산출물을 정의한다.

그림 Ⅴ-31. 설계 산출물 구조

설계 패턴 적용 방법

설계 패턴을 적용하기 전에 컨트롤러는 도메인 객체를 호출하기만 할 뿐 업무 로직을 가지고 있지 않다고 생각한다. 즉 도메인 객체가 비즈니스 로직을 나누어 가지고 있다.

도메인 객체는 Transaction Script, Table Module, Domain Model로 구별되며 가장 단순하게 구현할 수 있는 방법은 Transaction Script이다. Domain Model은 가장 익숙해지기 어려운 방식이다. 그러나 Domain Model을 사용하면 복잡한 모델도 쉽게 구현할 수 있다. 또한 Domain Model은 데이터베이스와 연결하는 부분이 복잡하다. Table Module은 이 두가지 사이에서 적절한 선택이 될 수 있다.

Data Source Layer에 대해서는 Transaction Script의 경우는 Row Data Gateway나 Table Data Gateway를 사용한다. RecordSet을 사용하고 데이터베이스와의 연결이 자주 끊어지는 경우에는 Table Data Gateway를 사용하는 것이 좋다. Table Modeul은 Record Set이나 Table Data Gateway와 함께 사용하는 것이 좋다. Domain Model의 경우에는 단순할 경우에는 Active Record를 사용하고 도메인 모델과 데이터베이스 연결을 분리할 경우에는 Table Data Gateway나 Row Data Gateway를 사용한다. 모델이 더 복잡한 경우는 Data Mapper를 사용한다.

J2EE의 경우에는 단순한 경우 Session Bean을 Transaction Script로 사용하고 entity bean은 Row Data Gateway로 사용한다. Domain Model을 사용하는 경우는 현재는 entity bean을 사용하는 것이 최상의 방법이다. 이 경우 entity bean은 Active Record로 사용된다. 이 경우 session bean은 remote façade로서 사용된다. 도메인 모델이 더 복잡하면 entity bean을 배제하고 일반 자바 클래스로 구현하면 된다. JDBC row set을 사용하는 경우는 Table Module을 사용한다.

.NET의 경우에는 가장 일반적인 패턴은 Table Module이다. 물론 Domain Model을 사용할 수도 있지만 이것이 .NET의 경우 최선의 선택이다.

Stored procedure는 remote call을 줄이는 좋은 방법이지만 이식성에 문제가 있다. 그러나 성능의 문제가 있을 경우는 도메인 로직을 제거하고 stored procedure로 옮기는 것이 좋다. Stored procedure를 사용하는 가장 좋은 방법은 Table Data Gateway를 사용하는 것이다.

Query Object 패턴의 정의

데이터베이스 쿼리를 표현하는 객체

그림 Ⅴ-30. Query Object

Metadata Mapping 패턴의 정의

메타 데이터 안에 OR 매핑에 대한 상세한 사항을 집어넣는다.

그림 Ⅴ-29. metadata mapping 패턴의 구조

OR 매핑을 취급하는 많은 코드들이 데이터베이스의 필드가 객체의 필드와 어떻게 매핑되는가를 정의한다. 결과적인 코드는 복잡하고 동일한 코드가 반복되는 경우가 많다. Metadata Mapping을 사용하면 개발자가 단순한 테이블 형태의 매핑을 정의하여 데이터를 읽고, 쓰고 업데이트하는 코드를 자동으로 생성할 수 있다.

어떻게 작동하는가?

Metadata mapping을 사용하기 위한 가장 큰 결정사항은 메타데이터의 정보를 실행중의 코드에 어떻게 반영하는가이다. 두 가지 방법이 있는데 첫 번째는 코드 자동화를 사용하는 것이고 두 번째는 reflection을 사용하는 프로그램이다.

코드 자동화를 사용하면 입력이 메타 데이터이고 출력이 매핑을 수행하는 클래스의 소스 코드이다.

Reflection을 사용하면 프로그램은 객체에게 예를 들어 setName이라는 메소드를 요청하고 적절한 파라메터를 사용하여 setName을 호출한다.

코드 자동화는 변경사항이 생기면 재컴파일하고 재배치해야 하기 때문에 덜 동적인 접근 방법이다. Reflection을 사용하면 사용자는 매핑 데이터 파일을 변경하고 이미 만들어진 클래스가 새로운 메타데이터를 사용한다. 사용자는 실행중에 이 작업을 수행할 수 있다.

Reflection에서 사용하는 메타 데이터는 XML을 사용하는 것이 좋은 방법이다.

언제 사용하는가?

Metadata mapping은 데이터베이스 매핑을 처리하는데 필요한 작업량을 줄인다. 그러나 셋업하는데 많은 시간이 소요되기 때문에 OR Mapping 툴을 사용하는 것도 좋은 방법이다. 스스로 메타데이터 매핑을 수행하려면 수작업으로 코드 생성기를 만드는데 걸리는 시간을 고려해봐야 한다. Reflection을 사용할 경우는 성능을 고려해야 한다.

단일 테이블 상속 패턴의 정의

단일 테이블 상속 패턴은 클래스들의 상속도을 다양한 클래스들의 모든 필드를 위한 컬럼을 가진 단일 테이블로 표현하는 것이다.

그림 Ⅴ-28. 단일 테이블 상속 패턴의 구조

단일 테이블 상속 패턴의 설명

관계형 데이터베이스는 다중 상속을 지원하지 않는다. 이러한 이유로 개체들을 데이터베이스에 매핑할 때 상속 구조를 관계의 테이블로 어떻게 표현할지를 고려해야한다. 관계형 테이터베이스에 매핑할 때, 다중 테이블에 있는 상속 구조를 처리할 때 최소의 조인을 할 수 있게 해야한다. 단일 테이블 상속 패턴은 상속 구조의 모든 클래스들의 모든 필드을 단일 테이블에 매핑한다.

단일 테이블 상속 패턴은 언제 사용하는가?

단일 테이블 상속은 상속구조를 관계형 데이터베이스에 있는 필드들의 매핑을 위한 선택 중에 하나이다. 이러한 매핑 패턴의 대안은 클래스 테이블 상속과 컨크리트 테이블 상속이 있다.

단일 테이블 상속의 장점은 다음과 같다.

• 데이터베이스에 대한 고민은 단지 단일 테이블만 있다.
• 추출되는 데이터에 대한 조인은 없다.

상속에 대한 필드의 추가 및 삭제은 데이터베이스에 대한 변경을 요청하지 않는다.

단일 테이블 상속의 단점

직접적으로 테이블을 이용하는 사람들에게 때때로 관련과 비관련 필드에 대하여 혼란을 준다.

몇몇 서브 클래스에 의해 사용되는 컬럼들은 데이터베이스에 대한 공간의 활용을 저하한다

시리얼라이즈 LOB(Serialized LOB) 패턴

시리얼라이즈 LOB 패턴의 정의

시리얼라이즈 LOB 패턴은 동기화된 개체들을 데이터베이스 필드에 저장된 단일 큰 개체 개체의 그래프를 저장한다.

그림 Ⅴ-27. 시리얼라이즈 LOB 패턴의 구조

시리얼라이즈 LOB 패턴의 설명

시리얼라이즈 LOB 패턴의 예제:XML에 있는 부서 계층을 시리얼라이즈

class Customer ...

private String name;

private List departments = new ArraryList();

class Department ...

private String name;

private List subsidaries = new ArraryList();

이 경우 데이터베이스는 한개 테이블만 가진다.

create table customers(ID int primary key, name varchar, departments varchar)

활동 레코드(Active Record) 패턴과 같이 고객 테이블은 다루어지고, 입력 행동을 가진 데이터 쓰기를 설명한다.

class Customer ...

public Long insert() {

PreparedStatment insertStatment = null;

try {

insertStatment = DB.prepare(insertStatementString);

setID(findNextDatabaseId();

insertStatment.setInt(1, getID().intValue());

insertStatment.setString(2, name);

insertStatment.setString(3, XmlStringer.write(deapertmentsToXmlElement());

insertStatment.execuete();

Registry.addCustomer(this);

return getID();

} catch(SQLException e) {

throw new ApplicationException(e);

} finally { DB.cleanUp(insertStatment);

}

}

public Element departmentsToXmlElement() {

Element root = new Element("departmentList");

Interator i = departments.iterator();

while (i.hasNext()) {

Department dept = (Department) i.next();

root.addContent(dep.toXmlElement());

}

return root;

}

class Department ...

Element toXmlElement() {

Element root = new Element("department");

root.setAttribute("name", name);

Interator i = subsidiaries.iterator();

while (i.hasNext()) {

Department dept = (Department) i.next();

root.addContent(dep.toXmlElement());

}

return root;

}