객체 지향 분석 및 설계
Object-oriented analysis and design| 시리즈의 일부 |
| 소프트웨어 개발 |
|---|
객체 지향 분석 및 설계(OOAD)는 객체 지향 프로그래밍을 적용하여 애플리케이션, 시스템 또는 비즈니스를 분석 및 설계하고 소프트웨어 개발 프로세스 전체에서 시각적 모델링을 사용하여 이해관계자의 커뮤니케이션 및 제품 품질을 안내하는 기술적 접근법입니다.
현대 소프트웨어 엔지니어링의 OOAD는 일반적으로 반복적이고 증분적인 방식으로 수행됩니다.OOAD 활동의 결과는 각각 분석 모델(OOA의 경우)과 설계 모델(OOD의 경우)이다.리스크나 비즈니스 가치와 같은 주요 요소에 의해 이러한 요소가 지속적으로 개선되고 발전하는 것을 목적으로 하고 있습니다.
역사
1990년대 중반 이전의 객체 지향 기술 초기에는 소프트웨어 개발 및 객체 지향 모델링에 대해 다양한 경쟁 방법론이 존재했으며, 종종 특정 CASE(Computer Aided Software Engineering) 툴 벤더와 연계되어 있었습니다.당시에는 표준 표기법, 일관된 용어 및 프로세스 가이드가 주요 관심사였으며, 이로 인해 통신 효율성이 저하되고 학습 곡선이 길어졌습니다.
잘 알려진 초기 객체 지향 방법론 중 일부는 Grady Boch, James Rumbaugh, Ivar Jacobson (Three Amigos), Robert Martin, Peter Coad, Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock과 같은 전문가들로부터 영감을 받았습니다.
1994년 Rational Software의 Three Amigos는 통합 모델링 언어(UML)를 개발하기 위해 협력하기 시작했습니다.나중에 Philippe Kruchten, Walker Royce(윈스턴 로이스의 장남)와 함께, 그들 자신의 방법론, OMT, OOSE 및 Boch를 다양한 경험과 통합시키는 미션을 성공적으로 이끌었습니다.er 업계 선두업체는 소프트웨어 개발 및 프로젝트 [1]관리의 업계 베스트 프랙티스를 학습하기 위한 포괄적인 반복 및 증분 프로세스 가이드 및 프레임워크인 RUP(Rational Unified Process)에 참여합니다.그 이후로 Unified Process 패밀리는 객체 지향 분석 및 설계에서 가장 인기 있는 방법론 및 참조 모델이 되었습니다.
개요
소프트웨어의 라이프 사이클은 일반적으로 문제의 추상적인 설명에서 설계, 코드와 테스트, 그리고 최종적으로 도입에 이르는 단계로 나뉩니다.이 프로세스의 초기 단계는 분석과 설계입니다.분석 단계는 종종 "요구 사항 획득"이라고도 합니다.
소프트웨어 개발에 대한 일부 접근법(총칭: 폭포수 모델)에서는 각 단계 간의 경계가 상당히 엄격하고 순차적입니다."물폭포"라는 용어는 그러한 방법론에서 한 방향으로만 순차적으로 진행된다는 것을 나타내기 위해 만들어졌다. 즉, 분석이 완료되면 설계를 시작하고 그 다음에야 설계가 시작되었으며 설계 문제로 인해 분석 모델의 변경이 필요하거나 코딩 문제로 인해 데시의 변경이 필요한 경우는 드물었다(및 오류의 원천으로 간주됨).gn.
워터폴 모델의 대안은 반복 모델입니다.이러한 차이는 Barry Boehm이 반복적인 소프트웨어 개발을 위해 Spiral Model에 관한 매우 영향력 있는 논문에서 널리 알려졌습니다.반복 모델을 사용하면 모델의 다양한 단계에서 병렬로 작업을 수행할 수 있습니다.예를 들어, 분석, 설계, 심지어 코드까지 같은 날에 작업하고 한 단계에서 다른 단계에서 발생하는 영향 문제로 인한 문제가 발생할 수 있습니다.반복 모델에 중점을 두고 있는 것은 소프트웨어 개발은 지식 집약적인 프로세스이며 분석과 같은 것은 설계 문제를 이해하지 않으면 완전히 이해할 수 없다는 것, 코딩 문제가 설계에 영향을 미칠 수 있다는 것, 테스트에서 코드 또는 설계 변경 방법에 대한 정보를 얻을 수 있다는 것 [2]등입니다.
워터폴 모델을 사용하여 객체 지향 개발을 수행할 수 있지만, 실제로는 대부분의 객체 지향 시스템이 반복적인 접근 방식으로 개발됩니다.그 결과 객체 지향 프로세스에서는 "분석"과 "설계"가 동시에 고려되는 경우가 많습니다.
객체 지향 패러다임은 모듈화와 재사용 가능성을 강조합니다.객체 지향 접근법의 목표는 "개방-폐쇄 원칙"을 만족시키는 것이다.모듈이 확장을 지원하는 경우 또는 모듈이 새로운 동작을 추가하거나 새로운 상태를 설명하는 표준화된 방법을 제공하는 경우 모듈이 열립니다.객체 지향 패러다임에서 이는 종종 기존 클래스의 새로운 하위 클래스를 생성함으로써 달성됩니다.모듈은 다른 모든 모듈이 사용해야 하는 잘 정의된 안정된 인터페이스를 가지고 있으며 다른 모듈 변경으로 인해 어떤 모듈에 발생할 수 있는 상호작용 및 잠재적인 오류를 제한하면 닫힙니다.객체 지향 패러다임에서는 객체 상에서 서비스를 호출하는 메서드를 정의함으로써 이를 달성할 수 있습니다.메서드는 공개 또는 비공개일 수 있습니다. 즉, 개체에 고유한 특정 동작이 다른 개체에 노출되지 않습니다.이것은 컴퓨터 [3]프로그래밍에서 많은 일반적인 오류의 원인을 줄여줍니다.
소프트웨어의 라이프 사이클은 일반적으로 문제의 추상적인 설명에서 설계, 코드와 테스트, 그리고 최종적으로 도입에 이르는 단계로 나뉩니다.이 프로세스의 초기 단계는 분석과 설계입니다.분석과 설계의 차이는 종종 "무엇과 어떻게"로 설명됩니다.분석에서 개발자는 사용자 및 도메인 전문가와 협력하여 시스템이 수행해야 할 작업을 정의합니다.이 단계에서 구현 세부 사항은 대부분 또는 전체적으로 무시됩니다(특정 방법에 따라 다름).분석 단계의 목표는 적절한 기술 등 제약조건에 관계없이 시스템의 기능적 모델을 작성하는 것입니다.객체 지향 분석에서는 일반적으로 가장 중요한 객체의 사용 사례와 추상적 정의를 통해 이러한 작업이 수행됩니다.후속 설계 단계에서는 분석 모델을 재정비하고 필요한 기술 및 기타 구현 선택을 합니다.객체 지향 설계에서는 다양한 객체, 데이터, 동작 및 상호작용을 설명하는 데 중점을 둡니다.설계 모델은 프로그래머가 코드로 [4]설계를 구현할 수 있도록 필요한 모든 세부 사항을 포함해야 합니다.
객체 지향 분석
소프트웨어 라이프 사이클에서 분석 활동의 목적은 구현 제약과 무관한 시스템 기능 요구사항의 모델을 작성하는 것입니다.
객체지향 분석과 다른 형태의 분석의 주된 차이점은 객체지향적 접근법에 의해 우리는 객체 주위에 요구사항을 정리한다는 것입니다.이러한 요건은 시스템이 상호작용하는 실제 객체를 모델로 한 행동(프로세스)과 상태(데이터)를 모두 통합합니다.다른 분석 방법론이나 기존의 분석 방법론에서는 프로세스와 데이터의 두 가지 측면을 별도로 고려했습니다.예를 들어 데이터는 ER 다이어그램으로 모델링하고 동작은 흐름도 또는 구조도로 모델링할 수 있습니다.
OOA에서 일반적으로 사용되는 모델은 사용 사례와 객체 모델입니다.사용 사례는 시스템이 수행해야 하는 표준 도메인 기능의 시나리오를 설명합니다.객체 모델은 주 객체의 이름, 클래스 관계(예: 원이 셰이프의 하위 클래스), 작업 및 속성을 설명합니다.이해를 [5]돕기 위해 사용자 인터페이스 목업 또는 프로토타입을 만들 수도 있습니다.
객체 지향 설계
객체 지향 설계(OOD) 중에 개발자는 객체 지향 분석에서 생성된 개념 모델에 구현 제약을 적용합니다.이러한 제약에는 하드웨어 및 소프트웨어 플랫폼, 성능 요구사항, 지속적인 스토리지 및 트랜잭션, 시스템의 가용성, 예산 및 시간에 따른 제약 등이 포함될 수 있습니다.기술에 의존하지 않는 분석 모델의 개념은 구현 클래스 및 인터페이스에 매핑되어 솔루션 영역의 모델, 즉 구체적인 [6]기술을 기반으로 시스템을 구축하는 방법에 대한 자세한 설명이 생성됩니다.
OOD 기간 동안 중요한 주제에는 객체 지향 설계 원리로 건축 패턴과 설계 패턴을 적용하여 소프트웨어 아키텍처를 설계하는 것도 포함됩니다.
객체 지향 모델링
객체 지향 모델링(OOM)은 개발 수명 주기 전체에 걸쳐 객체 지향 패러다임을 사용하여 애플리케이션, 시스템 및 비즈니스 도메인을 모델링하는 일반적인 접근 방식입니다.OOM은 현대 소프트웨어 엔지니어링에서 OOD와 OOA 활동에서 많이 사용되는 주요 기술입니다.
객체 지향 모델링은 일반적으로 업무의 두 가지 측면, 즉 비즈니스 프로세스 및 사용 사례와 같은 동적 동작 모델링과 클래스 및 구성 요소 같은 정적 구조 모델링으로 나뉩니다.OOA와 OOD는 OOM 중 두 가지 뚜렷한 추상 수준(즉, 분석 수준과 설계 수준)이다.Unified Modeling Language(UML; 통합 모델링 언어)와 SysML은 객체 지향 [7]모델링에 사용되는 두 가지 일반적인 국제 표준 언어입니다.
OOM의 이점은 다음과 같습니다.
효율적이고 효과적인 커뮤니케이션
일반적으로 사용자는 포괄적인 문서를 이해하고 언어 코드를 프로그래밍하는 데 어려움을 겪습니다.시각적 모델 다이어그램은 보다 이해하기 쉽고 사용자와 이해관계자가 개발자에게 시스템의 적절한 요건과 구조에 대한 피드백을 제공할 수 있습니다.오브젝트 지향 어프로치의 주된 목표는 시스템과 실제 세계 사이의 '의미적 격차'를 줄이고 이해관계자들이 일상 업무에서 사용하는 것과 거의 동일한 용어를 사용하여 시스템을 구축하는 것입니다.객체 지향 모델링은 이를 촉진하기 위한 필수 도구입니다.
유용하고 안정적인 추상화
모델링은 코딩에 도움이 됩니다.대부분의 최신 소프트웨어 방법론의 목표는 우선 "무엇" 질문에 대처하고 "어떻게" 질문에 대처하는 것입니다.즉, 우선 구현 제약을 고려하지 않고 시스템이 제공하는 기능을 결정하고, 다음으로 이러한 추상적인 요건에 대한 특정 솔루션을 만드는 방법을 검토하여 세부 설계로 다듬는 것입니다.기술 및 예산과 같은 제약 조건에 따른 ns 및 코드.객체 지향 모델링은 시스템 요건과 설계 모두에 대한 추상적이고 접근하기 쉬운 기술, 즉 프로세스와 객체 등의 필수 구조와 동작을 정의하는 모델을 제작함으로써 이를 가능하게 합니다.이것은 구체적이고 복잡한 소스 코드보다 추상화 수준이 높은 중요하고 가치 있는 개발 자산입니다.
「 」를 참조해 주세요.
- ATLAS 변환 언어(ATL)
- Class-Responsibility-Collaboration Card(CRC 카드)
- 도메인 고유 언어(DSL)
- 도메인 중심 설계
- 도메인 고유 모델링(DSM)
- Meta-Object Facility(MOF)
- 메타모델링
- 모델 구동 엔지니어링(MDE)
- 모델 베이스 테스트(MBT)
- 객체 모델링 언어
- 객체 지향 모델링
- 객체 지향 프로그래밍
- 객체 지향 사용자 인터페이스
- QVT
- 슈라이어멜러
- 소프트웨어 분석 패턴
- 스토리 기반 모델링
- 통합 모델링 언어(UML)
- XML 메타데이터 교환(XMI)
레퍼런스
- ^ "Rational Unified Process Best Practices for Software Development Teams" (PDF). Rational Software White Paper (TP026B). 1998. Retrieved 12 December 2013.
- ^ Boehm B, "소프트웨어 개발과 확장의 나선형 모델", IEEE 컴퓨터, IEEE, 21(5):61-72, 1988년 5월
- ^ Meyer, Bertrand (1988). Object-Oriented Software Construction. Cambridge: Prentise Hall International Series in Computer Science. p. 23. ISBN 0-13-629049-3.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 15, 199. ISBN 0-201-54435-0.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 77–79. ISBN 0-201-54435-0.
- ^ Conallen, Jim (2000). Building Web Applications with UML. Addison Wesley. p. 147. ISBN 0201615770.
- ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 15, 199. ISBN 0-201-54435-0.
추가 정보
- Grady Boch. "오브젝트 지향 분석 및 설계 with Applications, 제3판" : http://www.informit.com/store/product.aspx?isbn=020189551X Adison-Wesley 2007.
- 레베카 위프스-브록, 브라이언 윌커슨, 로렌 위너입니다객체 지향 소프트웨어 설계프렌티스 홀, 1990년[객체 지향 프로그래밍 및 설계에 대한 실제 소개]
- 객체 지향 설계 이론:OOD의 구성 요소 및 이를 표현하기 위한 표기법(설계 패턴에 초점을 맞춘 것)
- 마틴 파울러.분석 패턴: 재사용 가능한 객체 모델.애디슨 웨슬리, 1997년[개념 모델을 사용한 객체 지향 분석 소개]
- 베르트랑 마이어객체 지향 소프트웨어 구축.프렌티스 홀, 1997년
- 크레이그 라먼.UML 및 패턴 적용– OOA/D 입문 및 반복 개발.프렌티스홀 PTR, 2005년 제3판, mnnm,nnn
- 세트라그 호샤피안.오브젝트 방향
- 울리히 노르비스라트, 알베르트 ü도르프, 루벤 주베스토리 기반 모델링.아마존 Createspace, 페이지 333., 2013.ISBN 9781483949253.
외부 링크
- 기사 객체 지향 분석 및 설계와 UML 및 RUP의 개요(CRC 카드에 대해서도)
- UML 적용 – 객체 지향 분석 및 설계 튜토리얼
- OOAD 및 UML 리소스 웹사이트 및 포럼– 객체 지향 분석 및 UML을 사용한 설계.
- Dhiraj Shetty의 UML 기사를 사용한 소프트웨어 요건 분석.
- 현실에서의 기사 객체 지향 분석