객체 지향 디자인에 대한 참고 사항 | 부분--java지도 시간-php.cn

1부 - 객체 지향 분석 및 설계

1. 객체지향적 사고

객체 지향 사고는 객체 지향 모델링의 기본이며, 이는 이 게시물의 핵심 측면입니다. 문제와 개념을 구성 요소로 분해하고 이러한 부분을 객체로 간주하여 이해하는 것입니다.

정의: 객체 지향적 사고는 다양한 요소를 개별 객체로 보는 것을 의미합니다. 예를 들어 소프트웨어 시스템에서는 트윗, 사용자 또는 제품이 객체로 볼 수 있습니다.
속성 및 동작:
- 속성: 개체의 속성 또는 특성(예: 사람 이름, 나이, 키)
- 행동: 개체가 수행할 수 있는 작업(예: 장치 전원 켜기 또는 끄기, 사용자 로그인).
혜택:
- 조직: 객체는 데이터와 동작을 모두 캡슐화하고 관련 세부정보와 기능을 함께 유지합니다.
- 유연성: 개체의 속성이나 동작을 다른 개체와 독립적으로 변경할 수 있습니다.
- 재사용성: 프로그램의 여러 부분이나 심지어 다른 프로그램에서도 개체를 재사용할 수 있으므로 작성하고 유지 관리해야 하는 코드의 양이 줄어듭니다.

2. 소프트웨어 프로세스에서의 디자인

설계 단계는 소프트웨어 개발 수명주기에서 매우 중요합니다. 최종 제품이 의도한 대로 사용자 요구 사항과 기능을 충족하는지 확인합니다.

소프트웨어 개발 프로세스: 소프트웨어 개발 프로세스는 반복적이며 여러 주요 단계로 구성됩니다.
1. 요구사항 수집: 클라이언트나 사용자가 소프트웨어에서 필요한 것이 무엇인지 이해합니다.
2. 개념 디자인: 높은 수준의 디자인 개요 및 모형 개발
3. 기술적 설계: 각 구성 요소에 대한 세부 사양을 생성합니다.
4. 구현: 디자인을 바탕으로 실제 코드를 작성합니다.
5. 테스트: 소프트웨어가 올바르게 작동하고 요구 사항을 충족하는지 확인합니다.
6. 배포: 사용할 소프트웨어를 출시합니다.
7. 유지관리: 지속적인 업데이트 및 버그 수정
디자인의 중요성: 설계 단계를 건너뛰거나 부적절하게 처리하면 프로젝트가 실패할 수 있습니다. 견고한 디자인 기반은 소프트웨어 개발이 올바른 방향으로 시작되도록 보장하고 나중에 비용이 많이 드는 변경으로 인한 위험을 줄여줍니다.

3. 요구사항

요구사항 수집은 성공적인 프로젝트의 기초입니다. 여기에는 클라이언트나 사용자가 소프트웨어에서 원하는 것이 무엇인지 이해하는 것이 포함됩니다.

정의: 요구 사항은 소프트웨어가 충족해야 하는 조건이나 기능입니다.
선발:
- 고객 인터뷰: 고객의 비전과 요구 사항을 이해하기 위해 고객과 직접 토론합니다.
- 설문지 및 설문조사: 잠재 사용자 또는 이해관계자로부터 구조화된 정보를 수집합니다.
- 관찰: 사용자가 현재 시스템과 어떻게 상호작용하여 요구 사항과 불만 사항을 식별하는지 관찰합니다.
- 워크숍: 요구사항을 수집하고 우선순위를 정하기 위한 이해관계자와의 협업 세션
절충점: 고객은 다양한 요구 사항과 제약 조건 사이에서 균형을 유지해야 할 수 있습니다. 예를 들어 더 많은 기능과 더 빠른 배송 중에서 선택해야 할 수도 있습니다.

예: 집을 설계할 때 건축가는 집주인이 선호하는 방 크기, 배치 및 특정 기능에 대한 자세한 질문을 통해 요구 사항을 수집합니다. 이는 건설 중 비용이 많이 드는 변경을 방지하는 데 도움이 됩니다.

4. 디자인

소프트웨어 개발의 디자인에는 구현 단계를 안내하는 개념적 청사진과 기술 청사진이 모두 포함됩니다.

개념 설계:
- 정의: 소프트웨어의 주요 구성 요소와 해당 책임에 대한 높은 수준의 개요
- 모형 및 와이어프레임: 이해 관계자가 세부 작업을 시작하기 전에 디자인을 이해하고 승인하는 데 도움이 되는 시각적 표현입니다.
- 책임: 소프트웨어의 각 구성 요소가 수행해야 하는 작업을 정의합니다.
- 예:
- 모형: 화면의 모양과 기능을 보여주는 사용자 인터페이스의 시각적 레이아웃
- 와이어프레임: 세부적인 디자인 요소 없이 구성 요소의 레이아웃을 보여주는 간단한 스케치 또는 다이어그램.
- 중요: 모든 이해관계자가 소프트웨어의 상위 수준 구조에 대해 명확한 이해와 동의를 갖도록 합니다.

예: 집을 지을 때 개념 설계에서는 방의 일반적인 배치와 연결을 개략적으로 설명하지만 배관이나 배선은 아직 세부적으로 설명하지 않습니다.

기술적 설계:
- 정의: 구성 요소의 구성 및 상호 작용 방법을 포함한 각 구성 요소의 세부 사양
- 기술 다이어그램: 구성요소가 서로 어떻게 결합되고 데이터가 구성요소 사이에서 어떻게 흐르는지 보여주는 상세 도면입니다.
- 구성 요소 분석: 상위 수준 구성 요소를 각각 구현할 수 있을 때까지 더 작고 관리 가능한 부분으로 분해합니다.
- 예:
- 클래스 다이어그램: 클래스의 구조, 속성, 메소드 및 관계를 표시합니다.
- 시퀀스 다이어그램: 특정 이벤트 시퀀스에서 객체가 어떻게 상호 작용하는지 보여줍니다.
- 구성 요소 다이어그램: 구성 요소 간의 구성과 종속성을 묘사합니다.
- 중요: 개발자에게 코드를 효과적으로 작성하는 데 필요한 자세한 정보를 제공하고 개발팀 전체에서 일관성을 보장합니다.

예: 주택 건설의 기술 설계에서는 벽, 바닥, 지붕의 정확한 재료는 물론 배관 및 전기 시스템에 대한 세부 계획도 지정합니다.

5. 요구사항과 설계의 절충

설계 과정 전반에 걸쳐 고객의 요구와 프로젝트 제약의 균형을 맞추기 위해 절충이 필요한 경우가 많습니다.

커뮤니케이션: 디자인이 고객의 비전과 제약 조건에 맞게 유지되도록 하려면 고객과의 지속적인 피드백 루프가 필수적입니다.
- 반복 검토: 고객 의견을 반영하여 정기적으로 디자인을 검토하고 개선합니다.
- 프로토타이핑: 고객과 함께 아이디어를 테스트하고 검증하기 위한 초기 버전의 구성요소를 구축합니다.
재작업: 개념적 설계와 기술적 설계 모두 요구 사항을 충족하지 않거나 실행 불가능하다고 입증되면 수정해야 할 수도 있습니다.
- 유연성: 새로운 정보가 등장하거나 요구 사항이 발전함에 따라 변화와 조정에 개방적입니다.
- 영향 분석: 전체 프로젝트에 대한 변경의 잠재적 영향을 평가하여 정보에 입각한 결정을 내립니다.

예: 건축주가 개방형 주방을 원하지만 구조적으로 지지대가 필요한 경우 건축가와 건축주는 건축주의 미적 선호도를 충족시키면서 구조적 무결성을 유지하는 절충안을 찾아야 합니다.

6. 품질 속성을 위한 설계

소프트웨어를 설계하려면 기능적 요구사항과 비기능적 요구사항을 모두 충족하기 위해 다양한 품질 특성의 균형을 유지해야 합니다.

품질 속성: 소프트웨어의 성능, 유용성 및 유지 관리 가능성에 영향을 미치는 특성입니다.
- 성능: 소프트웨어가 작업을 얼마나 빠르고 효율적으로 수행하는지.
- 보안: 위협과 취약성으로부터 소프트웨어를 보호하기 위해 취해진 조치입니다.
- 확장성: 증가된 부하나 사용량을 처리할 수 있는 소프트웨어의 능력
- 유지관리성: 소프트웨어를 얼마나 쉽게 업데이트하거나 수정할 수 있는지.
- 사용성: 사용자가 소프트웨어를 쉽게 배우고 사용할 수 있는 정도입니다.
장단점: 한 속성을 최적화하면 다른 속성에 영향을 줄 수 있으므로 이러한 속성의 균형을 맞추는 데는 종종 장단점이 수반됩니다.
- 성능 대 보안: 보안 조치를 강화하면 성능이 저하될 수 있습니다.
- 확장성 대 유용성: 확장성을 향상시키기 위해 기능을 추가하면 사용자 인터페이스가 복잡해질 수 있습니다.
컨텍스트: 소프트웨어의 특정 컨텍스트는 이러한 속성이 균형을 이루는 방식에 영향을 미칩니다.
- 중요 시스템: 다른 속성보다 신뢰성과 보안을 우선시합니다.
- 소비자 애플리케이션: 사용성과 성능을 강조하여 사용자 만족도를 높입니다.

예: 현관문을 디자인할 때 보안(견고한 잠금 장치)과 편의성(접근 용이성)의 균형을 맞추는 것이 중요합니다. 자물쇠가 너무 많으면 문은 안전하지만 불편하고, 자물쇠가 너무 적으면 편리하지만 안전성이 떨어집니다.

7. CRC(Class Responsibility Collaborator) 카드

CRC card

CRC 카드는 디자인 과정에서 클래스, 클래스의 책임, 협력자를 식별하고 구성하는 데 사용되는 도구입니다.

정의: CRC 카드는 다양한 클래스의 책임과 클래스가 서로 상호 작용하는 방식을 시각화하고 구성하는 데 도움이 됩니다.
- 클래스: 시스템 내의 객체나 개념을 나타냅니다.
- 책임: 학급이 무엇을 알고 무엇을 하는지 정의합니다.
- 협력자: 학급이 상호 작용하는 다른 수업입니다.
사용:
- 브레인스토밍: 팀이 필요한 수업과 역할을 브레인스토밍하고 식별하는 데 도움이 됩니다.
- 디자인 세션: 수업 책임과 상호 작용에 대한 토론을 촉진합니다.
- 문서화: 설계 결정을 포착하기 위한 문서화 도구 역할을 합니다.
프로세스:
- 클래스 식별: 시스템과 관련된 모든 잠재적 클래스를 나열합니다.
- 책임 정의: 각 반의 주요 책임을 적습니다.
- 협력자 식별: 각 학급이 책임을 이행하기 위해 어떤 수업과 상호 작용해야 하는지 결정합니다.
혜택:
- 명확성: 디자인 아이디어를 정리하고 전달하는 명확하고 간결한 방법을 제공합니다.
- 유연성: 디자인이 발전함에 따라 쉽게 업데이트하고 수정할 수 있습니다.
- 협업: 디자인 결정을 쉽게 논의하고 개선하여 팀 협업을 강화합니다.

예: 은행 애플리케이션에서 "계정" 클래스에 대한 CRC 카드는 "고객" 및 "거래" 클래스와 같은 공동 작업자와 함께 "잔액 관리" 및 "거래 추적"과 같은 책임을 나열할 수 있습니다. .

8. 프로토타입 제작 및 시뮬레이션

프로토타입 제작 및 시뮬레이션 기술은 프로세스 초기에 디자인을 테스트하고 개선하는 데 사용되므로 본격적인 개발 전에 문제를 식별하고 수정하는 데 도움이 됩니다.

프로토타이핑:
- 저충실도 프로토타입: 소프트웨어 또는 특정 구성 요소의 단순하고 대략적인 버전으로, 종종 종이나 기본 디지털 도구로 생성됩니다.
- 고충실도 프로토타입: 최종 제품과 매우 유사한 더욱 상세하고 대화형 버전입니다.
- 목적: 디자인 컨셉을 검증하고, 사용자 피드백을 수집하고, 사용성 문제를 식별합니다.
- 방법:
- 종이 프로토타이핑: 손으로 그린 사용자 인터페이스 및 상호 작용 스케치 만들기
- 디지털 프로토타이핑: 소프트웨어 도구를 사용하여 대화형 모형 및 시뮬레이션을 만듭니다.
시뮬레이션:
- 정의: 다양한 조건에서 디자인의 동작과 성능을 테스트하기 위해 모델을 실행합니다.
- 사용 사례: 시스템 성능 평가, 부하 테스트, 설계 결정 검증
- 혜택:
- 조기 검증: 본격적인 개발 전에 잠재적인 문제를 식별합니다.
- 비용 효율적: 문제를 조기에 해결하여 비용이 많이 드는 변경으로 인한 위험을 줄입니다.
- 사용자 피드백: 사용자가 프로토타입과 상호 작용하고 기능 및 유용성에 대한 피드백을 제공할 수 있습니다.
- 도구: 프로토타입 제작과 시뮬레이션 실행을 위한 다양한 소프트웨어 도구와 플랫폼을 사용할 수 있습니다.