HLD (High Level Design) 란?

HLD

HLD에서는 일반적으로 시스템을 개념적 구성 요소로 분할하고 동작을 지정합니다. 이것은 시스템의 논리적 모델을 생성해야합니다. 중요한 것은 이 수준의 디자인에서 프레임 워크를 독립적으로 유지하는 것입니다. .NET, Java 등을 생각하지 마십시오. 또한 생성 한 이러한 구성 요소에 책임을 할당하고 상호 작용을 차트로 표시합니다 (예 : API). 또한 테스트 노력의 전체 범위와 일반적인 방향을 정의하여이 수준에서 전체 테스트 전략을 수립하는 것이 일반적입니다. 또한 종종 시스템에서 들어오고 나가는 데이터를 모델링합니다. 데이터를 추상화로 모델링하는 것은 괜찮습니다. 따라서 사용자와 같은 것들이 사용자 테이블에 이름 등을 명시 적으로 정의하지 않고 들어 와서 PayOrder를 배치합니다.

​

HLD ( High-Level Design )는 소프트웨어 제품 개발에 사용될 아키텍처를 설명합니다 . 아키텍처 다이어그램은 전체 시스템의 개요를 제공하여 제품 및 해당 인터페이스 용으로 개발 될 주요 구성 요소를 식별합니다. HLD는 시스템 관리자 가 이해할 수있는 약간의 기술적 용어에서 비 기술적 용어를 사용합니다 . 반대로 저수준 설계 는 프로그래머를 위해 이러한 각 요소의 논리적 세부 설계를 추가로 노출합니다 .

​

디자인 개요

이것은 다른 개발자 / 관리자가 프로젝트 작동 방식을 배우는 첫 번째 장소입니다. 전체 디자인에 대한 포괄적 인 개요를 제공해야합니다. 디자인 책임자는 개요 작성을 담당합니다. 이 섹션을 HTML로 작성하고 javadoc 개요 파일 에 배치 하십시오.

식별 정보 : 프로젝트 이름, 팀 이름, 작성자, 버전, 날짜 등

디자인 개요. 이 중요한 섹션은 디자인에 대한 전반적인보기를 제공합니다. 최고의 기술 문서를 사용하여 다른 디자이너에게 디자인 솔루션의 프레임 워크를 전달하십시오. 디자인에 익숙하지 않은 사람에게 디자인의 본질을 명확히해야합니다. 이것을 한 페이지로 제한하십시오.

디자인 문제. 디자인에는 많은 장단점이 있으며, 그중 몇 가지는 강의에서 논의했습니다. 프로젝트에서 제기 된 주요 설계 문제, 내린 결정 (또는 절충) 및 근거를 설명하십시오. (이 섹션은 위의 개요로 이어지는 배경으로 생각할 수 있습니다.) 이 섹션은 3 페이지 이상일 수 있습니다. 디자인 문제의 예

도구 : 사용 된 컴파일러 및 기타 개발 도구와 해당 버전 번호.

라이브러리 : 설계에 사용 된 기존 라이브러리, 선택한 이유, 적용될 수있는 라이선스 제한을 표시합니다.

외부 참조 : 사양 문서, 프로토 타입, 구조도 다이어그램, 디자인 패턴, 코딩 표준 등 관련 프로젝트 문서를 찾을 수있는 위치를 표시합니다. 이러한 참조가 디지털 형식 인 경우 파일 이름 또는 URL을 제공합니다. 완성 된 결과물이 제출 될 때 이것이 정확한지 확인하십시오.

​

클래스 다이어그램 또는 구조 차트

이 다이어그램은 디자인의 핵심입니다. 소프트웨어 설계의 청사진이라고 생각하십시오. 이 다이어그램은 설계의 모든 클래스 간의 관계를 보여줍니다. GUI를 만들고 작동하는 클래스를 표시 할 필요가 없습니다. 디자인 도구 를 사용하는 것이 좋습니다. 수정의 용이성을 용이하게하는 Rational Rose와 같은 (이 차트는 디자인 단계에서 많이 변경됨). 품질 손 그림은 허용 가능한 대안입니다. 차트가 상당히 클 수 있습니다. 여러 페이지에 걸쳐있는 경우 페이지 번호 지정 체계 또는 커넥터 레이블을 통해 페이지 순서 또는 계층이 명확하게 표시되는지 확인하십시오. 원하는 경우 하나의 큰 포스터 보드에 완성 된 차트를 만들 수 있습니다. (이것의 한 가지 장점은 팀 회의 공간의 벽에 걸 수 있다는 것입니다.) 또는 팀 웹 페이지에 클래스 다이어그램의 이미지를 배치하십시오.

참고 : 코드를 재사용하는 경우 재사용 된 코드의 전체 구조를 그리지 마십시오.

참고 : 솔루션의 상당 부분이 클래스가 아닌 함수 (예 : 복잡한 메서드) 인 경우 구조 차트 를 사용하여 분해를 표시하는 것이 좋습니다 .

​

클래스 스켈레톤 또는 모듈 헤더

클래스 다이어그램의 각 클래스에 대한 클래스 정의를 구현 하고 컴파일 (실행하지 않음) 해야합니다 . (컴파일 결함을 계산하는 것을 잊지 마십시오-QA 계획 참조). 클래스의 목적과 인터페이스는 Javadoc 주석으로 문서화되며 Javadoc 스타일을 준수해야합니다 . Javadocs는 팀 웹 페이지에 배치 할 수 있습니다.

시스템의 각 클래스는 클래스를 디자인하고 클래스 정의를 작성하는 개별 작성자에게 할당됩니다. 각 팀원은 시스템에서 하나 이상의 눈에 띄는 클래스를 담당합니다.

클래스 정의는 다음으로 구성됩니다.

클래스 헤더

식별 정보 : 클래스 이름, @author, @version, 날짜 등

설명 헤더

메소드 헤더

메서드 (작업) 이름-클래스 다이어그램에 표시된 이름과 정확히 일치해야합니다.

목적-이 작업의 목적을 설명합니다. 문제 영역의 용어를 사용하는 간결하고 명확한 영어 문장이어야합니다.

매개 변수 및 반환 유형-이름, 유형 및 설명.

예외가 발생했습니다.

(계약 팀에 의한 설계) 사전 및 사후 조건 (게터 / 세터 방법 제외). 권장 : 사용자 정의 태그 사용

(오류 검사 팀) 모든 오류 처리를 문서화합니다.

노트:

Javadoc 스타일 에 대한 규칙을 읽고 준수하십시오 .

클래스 정의 및이 를 생성 한 소스에 대해서는이 javadoc 예제를 참조하십시오 .

Java 패키지 프레임 워크를 사용하여 클래스를 그룹화하는 것을 고려하십시오. 한 가지 일반적인 접근 방식은 View 클래스 (예 : GUI)를 Model 클래스와 분리하는 것입니다.

코드를 재사용하는 경우 재사용 된 코드의 헤더를 포함하지 마십시오.

ADT는 자체 지속성을 처리해야합니다 . 즉, 대상 시스템에서 제공하는 DBMS 나 파일 시스템을 사용할 수 없습니다. 질문이 있거나이 제약 조건을 협상하려면 강사에게 문의하십시오.

​

상호 작용 다이어그램 (적절한 경우)

시퀀스 다이어그램 또는 이벤트 추적 다이어그램 이라고도 합니다. 이벤트가 발생하는 순서와 클래스가 상호 작용하는 방식에 대한 구체적인 세부 정보를 제공합니다. 객체가 서로에게 메시지를 전달하는 순서를 보여줍니다. UML과 같은 표준 다이어그램 표기법을 사용하십시오. Rational Rose 또는 유사한 도구가 권장됩니다. 적절성을 어떻게 결정합니까? 상호 작용을 명확히해야 할만큼 충분히 복잡한 사용 사례를 결정하려면 판단을 사용하십시오. 지침으로 사용 사례에 두 개 이상의 개체가 관련되어 있거나 4 개 이상의 단계가있는 경우 상호 작용 다이어그램이 적절할 수 있습니다.

​

데이터 구조

​

내부의

​

데이터 추상화를 구현하기로 결정한 방법을 문서화하십시오. 솔루션의 각 복합 데이터 구조에 대한 javadoc 주석을 제공하십시오. (IE, 배열, 벡터 등). 이 구현은 개인용이어야하므로 javadoc 명령에서 -private 플래그를 사용해야합니다. 각 주요 데이터 구조에 대해 구현 선택을 설명하는 "설계 문제"에 제공된 근거가 있는지 확인하십시오.

예:

/ ** 암호 키는

알파벳의 각 문자에 해당하는 * 하나 의 26 자 배열입니다 .

* /

private char [] CipherKey;

​

외부

디자인에 외부 데이터 파일이 포함 된 경우 디자인의 적절한 클래스에서 javadoc을 사용하여 각 파일의 정확한 형식 / 내용을 표시합니다.