[정처기 필기] 1과목 : 소프트웨어 설계 내용정리 - 3
11. 소프트웨어 설계 모델링
(1) 소프트웨어의 설계
1️⃣ 소프트웨어 설계 모델링
"무엇을"에서 "어떻게"로 관점을 전환하면서 최종 제작할 소프트웨어의 청사진을 만드는 것
2️⃣ 소프트웨어 설계 분류
❶ 상위 설계 : 예비 설계라고 하며, 전체 뼈대를 세우는 단계
: 아키텍처(구조)설계, 데이터 설계, 인터페이스 정의, 사용자 인터페이스(UI) 설계 -- 큰 개념의 설계
❷ 하위 설계 : 모듈 설계, 상세 설계라고도 하며, 모듈 배치라고 보면 됨
: 모듈 설계, 자료 구조 설계, 알고리즘 설계 -- 구체적인 설계 (모듈들을 어떻게 배치할지 등)
3️⃣ 소프트웨어 설계 대상
| 구분 | 설명 |
| 구조 모델링 | 컴포넌트 유형, 인터페이스, 내부 설계 구조 등의 구조의 상호연결 등의 구조를 모델링 |
| 행위 모델링 | 컴포넌트들이 어떤 순서로 기능을 수행하고 상호작용하는지 모델링 |
컴포넌트는 하나의 기능을 가지고 있으나 다른 컴포넌트와 연결할 수 있는 인터페이스를 가지고 있음
모듈과 컴포넌트는 비슷하지만 차이점은 컴포넌트가 인터페이스를 가지고 있다는 점이다.
4️⃣ 소프트웨어 설계 방법
| 구분 | 설명 | 예시 |
| 구조적 설계 | 자료 처리 과정 알고리즘 등 기능 중심으로 시스템을 나누어 설계 | Coad/Yourdon |
| 자료 중심 설계 | 입 출력의 자료 구조를 파악하여 소프트웨어 자료 구조를 설계 | Jackson Warner-Orr |
| 객체 지향 설계 | 자료에 적용될 기능과 자료를 함께 묶어 추상화 하는 개념 | Rumbaugh, Booch, Yourdon |
소프트웨어 설계의 기본 원리 : 분할과 정복 / 추상화 / 모듈화
5️⃣ 소프트웨어 구조도
| 용어 | 설명 | 예시 |
| Fan-in | 주어진 한 모듈을 제어하는 상위 모듈 수 | 모듈 F로 상위에서 들어오는 것이 3개 |
| Fan-out | 주어진 한 모듈이 제어하는 하위 모듈 수 | 모듈 F로 하위로 나가는 것이 2개 |
| Depth | 최상위 모듈에서 주어진 모듈까지의 깊이 | 모듈의 층 : 4개 |
| Width | 같은 등급의 모듈 수 | 모듈의 폭 : 3개 |
| Super ordinate | 다른 모듈을 제어하는 모듈 | |
| Subordinate | 어떤 모듈에 의해 제어되는 모듈 |
| Fan-in이 높은 경우 | ❶ 재사용 측면에서 잘된 설계 ❷ 시스템 구성 요소 중 일부가 동작 하지 않으면 시스템이 중단되는 단일 장애 발생 가능성 존재 ❸ 단일 장애 발생을 방지하기 위해 중점 관리가 필요 |
| Fan-out이 높은 경우 | ❶ 불필요한 타 모듈의 호출 여부를 확인 ❷ Fan-out을 단순하게 설계할 수 있는지 검토 |
[관련 기출 문제]
(2) 코드 설계의 개요
1️⃣ 코드의 기능
| 분류 | 기능 |
| 코드의 기본적 기능 | 표준화 기능 |
| 간소화 기능 | |
| 코드의 3대 기능 | 분류 기능 |
| 식별 기능 | |
| 배열 기능 | |
| 코드의 부가적 기능 | 연상 기능 |
| 암호화 기능 | |
| 오류 검출 기능 |
(3) 코드의 종류
1️⃣ 코드의 종류
| 코드 종류 | 특징 및 설명 |
| 순차 코드 (Sequence Code) | ❶ 일정한 배열로 일련 번호를 배당하는 코드 ❷ 항목 수가 적고 변경이 적은 자료에 적합 |
| 블록코드 (BlockCode, 구분코드) | ❶ 공통의 특성에 따라 임의의 크기를 블록으로 구분하여 일련 번호를 배정하는 코드 |
| 그룹 분류식 코드 (Group Classfication Code) | ❶ 코드화 대상 항목을 기준에 따라 대분류, 중분류, 소분류로 구분 ❷ 분류 기준이 명확할 경우 사용 |
| 10진 분류 코드 (Decimal Code) | ❶ 도서 분류 코드에 사용 |
| 표의 숫자 코드 (Significant Digit Code, 유효 숫자 코드) |
❶ 의미를 가지고 있는 코드 ❷ ex) 127-890-1245 : 두께 127 폭 890 길이 1245 |
| 연상 코드 |
❶ 품목 명칭 일부를 약호 형태로 코드속에 넣음 ❷ ex) TV-39-C : TV 39인치 컬러 |
2️⃣ 코드 오류의 종류
| 오류 | 의미 | 예 (1234) |
| 필사 오류 (Transcription Error) |
한자리를 잘못 기록하여 발생 | 1237 |
| 전위 오류 (Transposition Error) |
좌우 자리를 바꾸어서 발생 | 1243 |
| 이중 오류 (Double Transposition Error) |
전위 오류가 2개 이상 발생 | 2143 |
| 생략 오류 | 한자리 빼고 기록하여 발생 | 123 |
| 추가 오류 | 한자리를 추가해서 기록하여 발생 | 12345 |
| 임의 오류 | 두 가지 이상의 오류가 결합하여 발생 | 21345 |
[관련 기출 문제]
(4) 구조적 개발 방법론
1️⃣ 구조적 분석
❶ 자료의 흐름을 통해 전체적인 시스템의 흐름을 보는 것
❷ 정형화된 분석 절차에 따라서 사용자 요구사항을 파악
❸ 문서화하는 분석 방법 ) 자료흐름도, 자료사전, 소단위 명세
❹ 시스템 분할 가능, 하향식 분석 기법 사용
(5) 구조적 분석 도구 ⭐️
1️⃣ 자료 흐름도 (DFD, Data Flow Diagram)
❶ 시스탬 내에서 자료가 어떻게 흘러가는지를 나타낸 다이어그램
❷ 다차원적이며 자료 흐름 그래프 또는 버블 차트라고도 함
❸ 그림 중심으로 표현 - 하향식 분할 원리 적용
작성 원칙
❶ 출력 자료 흐름은 입력 자료 흐름을 이용해 생성
❷ 입력 출력 자료에 대해서만 인지하고 자료의 위치나 방향은 알 필요 없음
❸ 자료 흐름 변환의 형태 : 본질 변환, 합성의 변환, 관점의 변환, 구성의 변환 등이 있음
| 자료 보존의 원칙 | 출력 자료 흐름은 입력 자료 흐름을 이용해 생성한다 |
| 최소 자료 입력의 원칙 | 출력 자료를 산출하는데 필요한 최소의 자료 흐름만 입력한다 |
| 독립성의 원칙 | 프로세스는 오직 자신의 입력 자료와 출력 자료에 대해서만 알면 된다 |
| 지속성의 원칙 | 프로세스는 항상 수행하고 있어야 한다 |
| 순차 처리의 원칙 | 입력 자료 흐름의 순서는 출력되는 자료 흐름에서도 지켜야 한다 |
⭐️ 데이터 자료 흐름도
2️⃣ 소단위 명세서 (Mini-Specification)
❶ 세분화된 자료 흐름도에서 최하위 단계 프로세스(버블)의 처리 절차를 설명
❷ 프로세스 명세서라고도 함
❸ 분석가의 문서로, DFD를 지원하기 위해 작성
3️⃣ 구조적 언어, 의사결정 나무, 의사 결정표
| 구조적 언어 | 자연어 일부분으로 제한된 구조를 사용하여 명세서를 작성하는데 사용하는 명세 언어 |
| 의사 결정 나무 | 현재 상황과 목표와의 상호 관련성을 나무의 가지를 이용해 표현 - 불확실한 상황에서 의사결정을 위한 방법 |
| 의사 결정표 | 복잡한 의사결정 논리를 기술하는데 사용, 주로 자료 처리 분야에서 이용 |
4️⃣ 자료 사전(DD, Data Dictionary) ⭐️
: 시스템과 관련된 자료의 명세와 자료 속성을 파악할 수 있도록 조직화
| 기호 | 의미 | 설 명 |
| = | 자료의 정의 | ~로 구성되어 있다 |
| + | 자료의 연결 | 그리고 |
| () | 자료의 생략 | 생략 가능 |
| [ | ] | 자료의 선택 | 다중 택일, 또는 |
| { } | 자료의 반복 | {}n : 최소 n번 이상 반복 // {}ⁿ : 최대 n번 이하 반복 |
| * * | 자료의 설명 | 주석 |
자료 사전의 역할
❶ 자료 흐름도에 기술한 자료의 정의를 기술한 문서
❷ 구조적 시스템 방법론에서 자료 흐름도, 소단위 명세서와 같이 중요한 분석 문서 중 하나
❸ 자료 사전 이해도를 높이고자 할 땐, 하향식 분할 원칙에 맞춰 구성요소를 재정의
[관련 기출 문제]
12. 모듈
(1) 모듈과 결합도, 응집도
1️⃣ 모듈
❶ 전체 프로그램에서 어떠한 기능을 수행할 수 있는 실행 코드
❷ 재사용이 가능하며 자체적으로 컴파일 가능
❸ 모듈화를 통해 개발시 기간과 노동력 절감 가능
❹ 모듈의 독립성은 결합도와 응집도에 의해 측정된다
❺ 서브 루틴 = 서브 시스템 = 작업단위
❻ 변수 선언을 효율적으로 사용하여 기억 장치를 유용하게 사용
❼ 모듈 마다 사용할 변수를 정의하지 않고 상속하여 사용 가능
❽ 기능적 독립성 : 각 모듈의 기능이 서로 다른 모듈과의 과도한 상호작용을 회피하여 이루어지는 것
2️⃣ 결합도 (coupling) ⭐️
❶ 서로 다른 두 모듈간의 상호 의존도(기능적인 연관 정도)를 나타냄
❷ 결합도가 낮을수록 좋음
❸ 모듈 간 결합도를 약하게 하면, 모듈 독립성이 향상되고 유지보수 작업 쉬워짐
순서 기억하기 : 자스제외공내
| 결합도 약함 | 자료 결합도 | ❶ 모듈 간 인터페이스가 자료 요소로만 구성 ❷ 가장 바람직한 결합도 ❸ 모듈 간 내용을 알 필요 없다 |
| 스템프 결합도 | ❶ 두 모듈이 같은 자료 구조를 조회하는 경우의 결합도 ❷ 자료 구조의 변화는 모듈 및 필드를 조회하지 않는 다른 모듈에도 영향을 준다 ❸ 배열, 레코드, 구조 등이 모듈 간 인터페이스로 전달 |
|
| 제어 결합도 | ❶ 어떤 모듈이 다른 모듈을 내부 로직을 제어 | |
| 외부 결합도 | ❶ 외부에로 선언한 변수를 다른 모듈에서 참조 | |
| 공통 결합도 | ❶ 여러 모듈이 공통 자료 영역을 사용 | |
| 결합도 강함 | 내용 결합도 | ❶ 한 모듈이 다른 모듈의 내부 기능 및 자료를 조회하도록 설계 |
3️⃣ 응집도 (Cohesion)
❶ 모듈이 독립적인 기능으로 구성되었는지 정도를 의미
❷ 응집도가 높을수록 좋은 것
순서 기억하기 :
| 응집도 강함 | 기능적 응집도 | 모듈 내의 기능 요소들이 하나의 문제와 연관 되어 있는 경우 |
| 순차적 응집도 | 한 모듈 내 한 기능 요소에 의한 출력 자료가 다음 기능 요소의 입력자료로 제공되는 경우 |
|
| 교환적 응집도 | 같은 입력과 출력을 사용하는 소 작업이 모인 경우 | |
| 절차적 응집도 | 모듈이 다수의 관련 기능을 가질 때, 내부 기능 요소들이 기능을 순차적으로 수행할 경우 | |
| 시간적 응집도 | 특정 시간에 처리되는 여러 기능을 모아 한개의 모듈로 작성하는 경우 | |
| 논리적 응집도 | 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들을 모듈로 작성한 경우 | |
| 응집도 약함 | 우연적 응집도 | 모듈 내 기능 요소들이 관련 없는 요소로만 구성된 경우 |
4️⃣ 모듈 설계의 특징 ⭐️
❶ 바람직한 소프트웨어 설계 : 결합도 약하게, 응집도 강하게
❷ 유지 보수가 수월해야 하고, 입구와 출구는 한개씩 가져야 함
❸ 모듈 간 접속 관계를 분석하여 복잡도와 중복을 줄일 것
❹ 모듈 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 함
[관련 기출 문제]
(2) 모듈과 컴포넌트
1️⃣ 모듈 vs 컴포넌트
컴포넌트는 인터페이스를 가짐
(3) 재사용과 공통 모듈
1️⃣ 재사용
❶ 검증된 기능을 파악하여 재구성 하는 것
❷ 모듈을 최적화 하여 타 시스템에 적용하면 개발 비용과 시간을 낮출 수 있다
❸ 생산성 및 소프트웨어의 품질이 향상된다
재사용 규모에 따른 구분 ⭐️
❶ 함수와 객체
❷ 컴포넌트
❸ 애플리케이션
함수와 객체 (모듈) > 모듈의 집합 = 컴포넌트 > 컴포넌트의 집합 = 애플리케이션
3️⃣ 공통 모듈
: 각 서브 시스템에서 공통으로 사용하는 기능을 묶어 하나의 공통된 모듈로 개발
공통 모듈 명세 기법 ⭐️
| 정확성 | 실제 구현시 꼭 필요한 기능인지 |
| 명확성(명료성) | 기능에 대해 일관된 이해와 하나로 해석될 수 있도록 작성 |
| 완전성 | 시스템 구현시 필요한 것, 요구되는 것을 모두 작성 |
| 일관성 | 공통 기능 간 서로 충돌하지 않도록 작성 |
| 추적성 |
모듈 명세화 도구
| 종류 | ||
| 흐름도 | N-S 도표 | 의사 코드 |
| 의사 결정표 | 의사 결정도 | PDL |
| 상태 전이도 | 행위도 | |
4️⃣ N-S 도표
❶ 구조적 프로그램의 순차 / 선택 / 반복의 구조를 사각형으로 도식화한 도형식 표현 방법
❷ 제어구조 : 순차, 선택 및 다중 선택, 반복
[관련 기출 문제]
13. Software Architecture
(1) 소프트웨어 아키텍처
1️⃣ Software Architecture 시스템 7가지 품질 속성
❶ 성능
❷ 사용성
❸ 사용 운용성
❹ 보안성
❺ 시험 용이성
❻ 가용성
❼ 변경 용이성
2️⃣ Software Architecture 특징
❶ 간략성
❷ 추상화
❸ 가시성
❹ 복잡도 관리 종류 : 과정 추상화, 데이터 추상화, 제어 추상화
3️⃣ 아키텍처 프레임워크 구성 요소
FrameWork : 복잡한 소프트웨어 문제를 해결하는 등에 필요한 기본 구조
| 요소 | 설명 |
| Architecture Description (AD) | 아키텍처를 기록하기 위한 산출물 |
| 이해관계자 (Stakeholder) | 소프트웨어 시스템 개발에 관련된 사람과 조직 |
| 관심사 (Concerns) | 같은 시스템에 대해 서로 다른 이해관계자의 의견 |
| 관점 (Viewpoint) | 서로 다른 역할이나 책임으로 시스템이나 산출물에 대한 서로 다른 관점 |
| 뷰 (View) | 이해 관계자들이 가지는 생각이나 견해로 전체 시스템을 표현 |
4️⃣ 소프트웨어 아키텍처 4+1 View Model ⭐️
아래의 5계층으로 분류한 모델
❶ Logical View : 분석 및 설계
❷ Implementation View : 프로그래머
❸ Process View : 시스템 통합자
❹ Deployment View : 시스템 엔지니어
❺ Use Case View : 사용자
5️⃣ 소프트웨어 아키텍처 설계 원리
❶ 단순성
❷ 효율성
❸ 분할, 계층화
❹ 추상화
❺ 모듈화
6️⃣ 소프트웨어 아키텍처 평가 방법론 종류
: SAAM, ATAM, CBAM, ARID
[관련 기출 문제]
14. 소프트웨어 아키텍처 패턴
(1) 소프트웨어 아키텍처 패턴
1️⃣ 계층 패턴
❶ 소프트웨어를 계층 단위로 분할
❷ N-tier 아키텍처 패턴
| 4계층 | |
| Presentation Layer | UI 계층 |
| Application Layer | 서비스 계층 |
| Business Logic Layer | 도메인 계층 |
| Data access Layer | 영속성 계층 |
2️⃣ MVC (Model View Controller) 패턴
| Model | 핵심 기능 + 데이터 |
| View | 사용자에게 정보를 표시 |
| Controller | 사용자로부터 입력을 처리 |
3️⃣ 클라이언트 서버 패턴
❶ 하나의 서버와 다수의 클라이언트로 구성
❷ 서버는 응답을 위해 항상 대기
4️⃣ 파이프 필터 (Pipe-Filters) ⭐️
❶ 데이터 흐름을 생성하고 처리하는 시스템을 위한 구조
❷ 필터는 파이프를 통해 받은 데이터를 변경 하고, 결과를 파이프로 전송
❸ 각 처리 과정은 필터 컴포넌트에서 이루어지고, 처리되는 데이터는 파이프를 통해 흐름
❹ 파이프는 버퍼링 또는 동기화 목적으로 사용
❺ 활용 : 컴파일러, 연속한 필터들은 어휘, 분석 파싱, 의미 분석 그리고 코드 생성을 수행
❻ 장점 : 필터 교환과 재조합을 통해 높은 유연성 제공
❼ 단점 : 상태 정보 공유를 위한 비용이 소요, 데이터 변환에 과부하 발생
❽ 노드와 간선으로 구성
5️⃣ Peer To Peer
❶ 분산 컴퓨팅 애플리케이션 구축시 유연성 제공 - 서버와 클라이언트 전환
❷ Peer가 하나의 컴포넌트로 대응되며 컴포넌트는 클라이언트/서버 역할을 모두 수행
6️⃣ 브로커
❶ 컴포넌트가 컴퓨터와 사용자를 연결
❷ 요청에 응답하는 컴포넌트가 여러 개 존재할 때 적합
7️⃣ 블랙보드
❶ 결정적 해결 전략이 존재하지 않는 문제 해결에 적합
❷ 음성인식, 신호해석 등에 활용
8️⃣ 이벤트 버스
❶ 소스 이벤트가 메시지를 발행하면 해당 채널 구독자가 메시지 수신 후 해당 이벤트를 처리하는 방식
❷ 이벤트를 처리하며 이벤트 생성(소스), 이벤트 수행(리스너), 이벤트 통로(채널), 이벤트 버스(채널 관리) 등 4가지 주요 컴포넌트를 갖는다
❸ 소스는 이벤트 버스를 통해 특정 채널로 메시지 발행
❹ 리스너는 구독한 채널에 발행된 메시지에 대해 알림을 받음
9️⃣ 인터프리터 (Interpreter)
❶ 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용
[관련 기출 문제]
15. 객체지향 설계
(1) 구조적 절차적 프로그래밍과 객체 지향
1️⃣ 구조적 프로그래밍과 절차적 프로그래밍
구조적 프로그래밍
❶ 프로그램의 이해가 쉽고 디버깅 작업이 쉽다
❷ GOTO(분기)문 사용하지 않는다
❸ 기본 구조 : 순차 구조, 선택 구조, 반복 구조
절차적 프로그래밍
❶ 명령어를 순서대로 나열하는 프로그래밍
❷ 함수 기반의 프로그래밍
❸ 절차형 언어의 경우 규모가 커지면 함수가 기하급수적으로 증가
❹ 함수가 타 프로그램과 문제를 일으킬 수 있음
2️⃣ 객체 지향 구성요소 ⭐️
현실 세계의 대상체를 개체(Entity)로 보고,
이 개체는 속성(Attribute)과 메소드(Method)가 결합하여 객체(Object)로 표현
| 구분 | 설명 |
| Class | ❶ 유사한 객체를 정의한 집합 ❷ 속성과 행위를 정의한 것 ❸ 구조적 기법에서 단위 테스트와 같은 개념 |
| Object | ❶ 데이터와 함수를 묶어 캡슐화한 대상 ❷ 클래스에 속한 Instance ❸ Instance : 같은 클래스에 속한 각각의 객체 ❹ Attribute : Object가 가지고 있는 데이터 값 ❺ Method : Object 행위인 함수 |
| Message | Object간에 서로 주고 받는 통신 |
(2) 객체 지향 특징 ⭐️
1️⃣ 객체 지향의 5가지 특징 ⭐️
| 구분 | 설명 |
| 캡슐화 | ❶ 관련성 높은 데이터와 관련 기능을 하나로 묶는 기법 ❷ 결합도가 낮아저 재사용성 증가 ❸ 정보 은닉을 통해 다른 객체와 메시지 교환시 인터페이스 단순 |
| 정보은닉 | ❶ 객체 내부의 속성과 메소드를 숨김 ❷ 인터페이스를 통해서만 메시지를 주고 받을 수 있도록 ❸ side effect를 줄이기 위함 |
| 추상화 | ❶ 시스템의 공통 성질을 추출한 뒤 추상 클래스 설정 ❷ 현실 세계를 자연스럽게 표현 가능 ❸ 종류 : 기능 , 제어, 자료 추상화 |
| 상속성 | ❶ 상위 클래스의 속성과 연산을 하위 클래스가 재정의 없이 물려 받아 사용 ❷ 상위 클래스는 추상적 성질, 자식 클래스는 구체적 성질을 가짐 ❸ 하위 클래스는 새로운 속성과 연산을 추가하여 사용 가능 ❹ 다중 상속 : 여러 상위 클래스에서 속성과 연산을 물려 받음 |
| 다형성 | ❶ 객체가 다양한 모양을 가지는 성질 ❷ 속성이나 변수가 서로 다른 클래스에 속하는 객체를 지칭 가능 ❸ 오버로딩(같은 이름 순서 재사용), 오버라이딩(재정의) |
2️⃣ 객체 지향 기법에의 관계성 ⭐️
| 구분 | 설명 |
| is member of | 연관성, 참조 및 이용관계 |
| is part of | 집단화, 객체 간 구조적인 집약 관계 |
| is a | 일반화, 특수화, 클래스 간의 개념적인 포함 관계 |
[관련 기출 문제]
3️⃣ 오버로딩과 오버라이딩
오버로딩(Overloading)
❶ 한 클래스 내에서 같은 이름의 메소드를 사용
❷ 매개 변수의 유형과 개수가 다름
오버라이딩(Overriding)
❶ 상속관계의 두 클래스의 상위 클래스에서 정의한 메소드를 하위 클래스에서 재정의
❷ Java에서는 static 메소드의 오버라이딩 허용하지 않음
❸ 하위 객체의 매개 변수 개수와 타입은 상위 객체와 동일해야 함
| 구분 | 오버로딩 | 오버라이딩 |
| 메소드 이름 | 한 클래스 내에서 동일 | 상속 관계의 두 클래스간 동일 |
| 매개변수 | 달라야 함 | 같아야 함 |
| 접근 제한 | 무관 | 범위가 같거나 커야 함 |
| 사용 | 같은 이름으로 메소드 중복 정의 | 자식 클래스에서 부모 클래스의 메소드 재정의 |
4️⃣ 객체지향 설계 원칙 (SOLID)
| 구분 | 설명 | |
| 단일 책임의 원칙 | SRP, Single Responsibility Principle | 모든 클래스는 하나의 책임만 가져야 한다 |
| 개방-폐쇄의 원칙 | OCP, Open Closed Priciple | 확장에 개방, 수정에는 폐쇄적이어야 한다 |
| 리스코프치환 원칙 | LSP, Liskov Substitution Principle | 부모 클래스를 자식 클래스로 대체 가능해야 한다 |
| 인터페이스 분리 원칙 | ISP, Interface Segregation Principle | 클라이언트는 사용하지 인터페이스에 영향을 받으면 안된다 |
| 의존 역전 원칙 | DIP, Dependency Inversion Principle | 변하기 어렵고 변화 빈도가 낮은 것에 의존한다 |
(3) 객체 지향 개발 방법론
| 종류 | 설명 |
| Booch | OOD(Object Oriented Design) |
| OOoSE (Jacobson) |
Object Oriented SW Engineering |
| OMT (Rum-baugh) |
Object Modeling Technology 객체 모델링 동적 모델링 기능 모델링 |
| Coad와 Yourdon 방법⭐️ | E-R 다이어그램을 이용한 객체의 행위를 모델링 |
(4) 클래스 설계
1️⃣ 클래스 설계
분석 단계중 아직 확정되지 않은 클래스 내부 부분 중
구현에 필요한 중요한 사항을 결정하는 작업
2️⃣ 클래스 인터페이스
클래스 구현 : 설계로부터 클래스를 구현하는 개발자
클래스 사용 : 구현된 클래스를 이용해 다른 클래스를 개발하는 개발자
클래스 확장 : 구현된 클래스를 확장하여 다른 클래스로 만드는 개발자
3️⃣ 협약에 의한 설계
| 구분 | 설명 | |
| 선행조건 | Precondition | 오퍼레이션이 호출되기 전에 참이 되어야할 조건 |
| 결과조건 | Postcondition | 오퍼레이션이 수행된 후 만족해야 하는 조건 |
| 불변조건 | Invariant | 클래스 내부가 실행되는 동안 항상 만족해야하는 조건 |
[관련 기출 문제]
[참고 영상]