728x90
반응형

https://youtu.be/Ee1DJ3HQjHM?si=muCxbkeFdKa3N0jw

1. 소프트웨어 설계를 위한 공통 모듈 설계

1-1. 공통 모듈 설계의 개요
- 공통 모듈 설계란 시스템 구축 시 공통으로 사용되는 모듈을 묶은 소프트웨어를 의미함
- (중요) 재사용성과 표준화를 위해 공통 모듈 설계를 이용함
- 공통 모듈은 클래스, 라이브러리, 컴포넌트, 프레임워크 네 가지 종류가 있음
- 공통 모듈 설계에는 하향식과 상향식 공통 모듈 도출 방식이 있음

1-2. 공통 모듈 도출의 과정
- 공통 모듈 도출은 요구사항을 중심으로 기능 목록을 선별해 공통 모듈을 도출함
- 이는 요구사항을 기술한 기술서를 바탕으로 모델링을 진행함
- 유즈 케이스 다이어그램을 그린 후 정적 모델링으로 클래스 다이어그램, 컴포넌트 다이어그램, 동적 모델링으로 시퀀스 다이어그램과 액티비티 다이어그램을 만듦
- (중요) 공통 모듈 도출의 핵심은 요구사항 정의와 기능 목록 선별임

1-3. 공통 모듈 도출의 필요성과 적용
- 공통 모듈 도출을 통해 중복 개발을 방지하고 개발비용을 절감 가능함
- 모듈 간의 표준화를 통해 소프트웨어 품질을 높일 수 있음
- (중요) 공통 모듈 도출은 다양한 부서에서 사용하는 기능을 공통으로 사용하는 추세를 반영함
- 이에 따라, 기존의 개발 프레임워크에서 공통 기능을 도출해 사용하는 추세임

2. 유즈 케이스 명세서와 공통 모듈 평가

2-1. 유즈 케이스 명세서의 필요성과 형식
- 유즈 케이스 명세서는 시스템 유즈 케이스를 정의하고 관리하는 도구임
- (중요) 유즈 케이스 명세서의 각 항목은 유즈 케이스의 이름, 목적, 유지 케이스를 이용하는 액터, 필요 조건 등을 포함함
- 유즈 케이스의 정상적인 흐름, 대체 흐름, 예외 흐름 등을 설명하고 있음
- 이 명세서는 유즈 케이스의 특성에 따라 대응하는 시스템이 구성되어야 함

2-2. 클래스 다이어그램과 시퀀스 다이어그램
- 유즈 케이스 명세서에서 클래스 다이어그램과 시퀀스 다이어그램을 활용하여 시스템을 표현함
- 클래스 다이어그램은 클래스의 모양과 동작을 바탕으로, 시퀀스 다이어그램은 시간적 순서에 따라 객체 간의 관계를 나타냄
- 시스템이 생성하는 오류 메시지를 처리하고, 유즈 케이스 명세서를 통해 대응하는 방식을 설명함
- (중요) 각각의 클래스나 인터페이스를 이용하여 클래스 다이어그램을 그려야 함

2-3. 공통 모듈의 응집도와 결합도
- 공통 모듈의 응집도는 클래스 간의 연계 정도를 의미하며, 응집도가 높을수록 설계가 잘 됐다고 판단됨
- (중요) 결합도는 모듈 간의 연계 정도를 의미하며, 결합도가 높을수록 모듈 간에 서로 다시 호출하는 경우가 많음
- 응집도와 결합도는 모듈의 품질을 평가하는 중요한 지표로, 이 두 가지 요소를 고려하여 모듈을 설계하고 평가해야 함

3. 소프트웨어 설계

3-1. 객체 지향 방법론
- 객체 지향 방법은 실 세계의 객체를 속성과 메소드로 나누어 객체로 정의함
- 객체는 클래스로 묶인 꾸러미이고, 클래스 간의 관계는 인스턴스로 표현됨
- 객체 지향 방법의 특징은 객체 인스턴스, 객체 속성, 객체 메소드로 구성됨
- 디자인 패턴은 개발자들의 경험을 추상화, 일반화시킨 템플릿임
- 디자인 패턴을 활용하면 효율성과 재사용성을 높일 수 있음

3-2. 디자인 패턴의 이해
- 디자인 패턴은 객체 지향 방법의 개념과 특징을 정리한 것임
- 디자인 패턴은 개발자들이 프로그램 모델을 경험적으로 체득한 것에서 나온 템플릿임
- 디자인 패턴을 활용하면 효율성과 재사용성을 높일 수 있음
- 디자인 패턴의 종류는 다형, 중첩, 연결, 단순, 복합, 다층, 복합 다형이 있음
- (중요) 디자인 패턴은 객체 지향 방법의 핵심 요소이니 숙지해야 함

3-3. 객체 간 관계와 설계 원칙
- 객체 지향 설계는 객체, 객체, 클래스 간의 관계를 모델링함
- 클래스 간의 관계는 인스턴스로 표현되며, 객체 간의 관계는 클래스 간의 관계로 이어짐
- 객체 지향 설계의 특징은 개별 객체, 객체 간의 관계 모델링, 중첩과 순서 정의임
- 객체 지향 설계의 핵심은 재사용성과 개별 객체의 독립성임
- 객체 지향 설계는 객체, 객체 간의 관계에 대한 다양한 테마를 제공함

4. 객체지향 개념

4-1. 객체와 객체지향 특징
- 객체를 모델링해 클래스와 객체명을 정의함
- 객체의 특징을 나타내 속성과 동작을 추상화, 상속, 다형성, 캡슐화, 정보 은닉으로 정의함
- (중요) 추상화는 객체 모델링 시 필요로 하는 부분만 추출해 속성과 동작을 정의함
- 상속은 부모의 형질을 자식에게 물려주어 코딩이 수월해지고 유지보수가 용이함
- 다형성은 상속을 통해 자식이 부모의 동작을 이용하면서도 각자의 특징을 유지함

4-2. 객체의 관계와 설계 원칙
- 객체는 서로 연관되어 있으며, 이를 관계(어소시에이션)로 표현함
- 관계는 상호 의존적이면서도 별개의 존재로, 타 객체와의 연관을 가짐
- 상호 의존적인 관계는 '집합 연관'이라고도 불림
- 집합 연관은 상위 클래스와 연결할 때 '인터페이스 연결점'을 통해 비어 있는 삼각형을 표시함

4-3. 클래스 간의 관계와 설계 원칙
- 클래스 간의 관계는 연관되거나, 추상화(상속)로 인해 연결될 수 있음
- 연관은 상호 의존적이면서도 별개의 존재로, 일례로 '사람-티비' 관계가 있음
- 추상화(상속)는 관계를 통해 더 높은 계층에서 더 일반적인 개념을 가진 클래스로 관계를 이어가며, 이는 '집합 연관'이라고도 불림
- 상위 클래스와 연결할 때는 인터페이스 연결점을 통해 연결을 명확히 함

5. 객체지향 디자인

5-1. 객체의 관계형성과 관련 패턴
- 객체 관계 형성 시엔 다형제와 복합형제가 존재함
- 다형제는 동일한 클래스에서 구분되며, 복합형제는 객체들이 실제로 같이 연결되어야 함
- 복합연관은 해당 관계가 기능적으로 서로 연관되어야 함
- 집합과 복합의 차이는 연결되어야 하는 클래스가 따로 떼어져도 기능적으로 동작할 수 없을 때 나타남
- (중요) 관계형성 시엔 리스코프 교체의 원칙에 따라 상위 클래스가 하위 클래스로 대체되어야 함

5-2. 클래스 설계 원칙과 디자인 패턴
- 클래스 설계 시 단일 책임, 개방 폐쇄, 상속, 변경 시 안 됨을 원칙으로 함
- (중요) 상속 관계에서는 개방되어야 하고, 변경 시 닫혀 있어야 함
- 의존 관계 역전 원칙에 따라 추상 클래스에 실제 클래스 의존 필요
- (중요) 법령적 목적의 단일 인터페이스보다 다형제를 많이 갖도록 설계
- 디자인 패턴은 다양한 개발자 경험에서 검증된 설계 지식의 추상화로, 객체 지향 설계에서 주목받기 시작함

5-3. 디자인 패턴의 분류와 적용
- 디자인 패턴은 목적에 따라 생성 패턴, 구조 패턴, 행위 패턴으로 나뉨
- 목적에 따라 패턴의 종류를 나누고, 이 중 생성 패턴이 가장 많음
- (중요) 생성 패턴 중 팩토리 메소드, 앱스트랙션, 팩토리 빌드, 프로토타입, 싱글톤 패턴은 기억해야 함
- 구조 패턴은 어댑터 패턴, 브릿지 컴파워지 데코에이션, 페케이드 플라이어 웨이트 프렉시, 7개 패턴으로 기억
- 행위 패턴은 11개 패턴으로 기억, 그중 가장 적은 것이 어댑터 패턴임

6. 객체지향 프로그래밍의 이해

6-1. 객체지향 프로그래밍의 개요
- 객체 지향 프로그래밍은 캡슐화, 다형성, 상호작용, 추상화, 복합관계 등을 활용함
- 객체 지향 프로그래밍을 통해 개발 프로세스가 효율적이고 재사용 가능해짐
- (중요) 객체 지향 프로그래밍을 통해 모델링이 가능해져 시스템의 재사용성이 높아짐
- 객체의 특징은 추상화, 물려받는다, 상수, 다형성, 그리고 묶음이며, 이들을 통해 객체의 특성을 표현함

6-2. 객체지향 프로그래밍의 장점
- 객체지향 프로그래밍을 통해 개발 프로세스가 효율적이고 재사용 가능해짐
- (중요) 이는 소프트웨어의 품질 향상, 개발자 간의 의사소통 원활, 그리고 소프트웨어의 생산성을 높여줌
- 또한, 객체 지향 프로그래밍은 설계 지식의 일반화를 가능하게 함
- 이는 효율성과 재사용성을 높이고, 개발자의 작업 부담을 줄여줌

6-3. 객체지향 설계의 구체적 이해
- 객체 지향 설계는 속성과 메서드를 결합해 하나의 객체를 생성함
- 객체 간의 관계는 모델링을 통해 표현되며, 이는 객체 지향의 주요 특징임
- 디자인 패턴은 객체 지향 설계의 효율성과 재사용성을 높이는 방법임
- (중요) 디자인 패턴은 생성패턴, 구조패턴, 행위패턴 등 5가지로 나뉘며, 각각의 패턴은 목적이 다름

00:02
네 소프트웨어 설계 세 번째 과목인 애플리케이션 설계 애플리케이션 설계는 두 파트로 나눠집니다. 그중에서 첫 번째 공통 모듈 설계하기 살펴보도록 하겠습니다. 학습목표입니다. 공동 모듈의 개념을 설명하고 공통 모듈을 도출하고 분리해낼 수 있다. 둘째, 공통 모듈 설계를 위한 모듈화 원리를 이해할 수 있다. 셋째, 모듈화 지표인 결합도를 이해하고 결합도를 줄일 수 있는 낮출 수 있는 방법을 적용한다. 할 수 있다. 마지막 모듈화 지표인 응집도를 이해하고 응집도를 최대화 높일 수 있는 방법을 적용할 수 있다. 입니다. 학습 내용은 공통 모듈 개요 공통 모듈 도출 설계 평가 순으로 살펴보도록 하겠습니다.

01:01
용어사진입니다. 공통 모듈이란 시스템을 구축할 때 여러 하위 즉 서브 시스템에서 공통으로 사용되는 모듈을 모아놓은 소프트웨어 묶음으로써 소프트웨어의 중복 구현을 줄여주고 재사용성을 높이기 위한 소프트웨어가 되겠습니다. 둘째, 응집도입니다. 응집도는 인터페이스 요청을 처리함에 있어서 공통 모듈 내에 있는 클래스들 간에 얼마나 유기적으로 서로 간에 협업하여 처리하는가에 관한 정도가 되겠고 마지막으로, 결합도는 어떤 모듈이 다른 모듈에 의존하는 정도가 되겠습니다. 공통 모듈 개념입니다. 공통 모듈이란 시스템을 구축할 때 여러 하위 시스템 즉 서브 시스템에서 공통으로 사용하는 공통으로 사용되는 모듈을 뜻한다.

02:02
자 표준 플랫폼이 있고 공통 모듈 이렇게 모아놓은 것들 있죠. 일단 이 공통 모듈은 다른 쪽에서도 같이 사용할 수 있다. 이렇게 이해하시면 될 것 같고요. 다음 공통 모듈의 사용 목적입니다. 공통 모듈을 만드는 이유는 주 목적이 재사용입니다. 재사용 새로운 서버 시스템이 만들어지면 공통 모듈에서 다른 쪽에서도 재활용이 가능하다는 거죠. 같이 사용하니까 한쪽에서 만들면 다른 쪽에서 안 만들어도 돼요. 그러다 보니까 중복 개발을 방지할 수 있어요. 그래서 개발비용 절감에 도움이 되고 또한 이제 이러한 과정을 통해서 모듈 간의 표준화를 추가할 수가 있습니다. 그래서 궁극적으로 소프트웨어의 품질을 높일 수가 있겠습니다. 공통 모듈의 종류입니다. 공통 모듈의 종류는 클래스 라이브러리 컴포넌트 프레임워크 네 가지가 있습니다.

03:02
세부적으로는 클래스는 공통 모듈을 실제로 구현하는 객체인데 공통 모듈이 존재할 수 있는 가장 기본적인 형태가 되겠습니다. 지금 화면에 보이는 부분은 해당 자바 클래스에 대한 소스입니다. 말자바 클래스다 나중에 저희가 프로그램 언어 파트에서는 자바를 주로 살펴볼 거고요. 그리고 특히 실기 파트에서 해당 소스에 대한 분석을 반복해서 저희가 익힐 겁니다. 개괄적인 툴로만 우선은 어 처음 접하는데요. 이거 다 알아야 되나요? 몰라도 됩니다. 퍼블 클래스 익셉션 클래스에 대한 해당 메인 메소드에 대한 정의 등등 넘어가겠습니다. 라이브러리나 라이브러리는 여러 개의 클래스가 합쳐진 묶음을 뜻합니다.

03:54
마이퍼스트 자바 클래스 이렇게 세컨드 서드 이렇게 이름이 안 바뀌어 있는데, 이렇게 여러 개의 클래스를 묶어서 배포 파일이 확장자가 자르 파일이거든요. a.0로 묶어 놓은 거다 하나의 자바 클래스로 쓰이기보다는 여러 개의 자바 클래스가 묶인 형태인 라이브러리 형태로 재사용이 될 수 있다. 컴포넌트입니다. 컴포넌트는 라이브러리가 좀 더 체계화된 형태의 소프트웨어다 규모적인 측면에서 순차적으로 범위 규모가 커진다 이렇게 이해하셔도 될 것 같습니다. 컴포넌트는 독립적으로 동작하고 또 구현할 수 있고 영세와 패키지와 배포가 가능합니다. 내 외부 인터페이스를 통해서만 접근할 수 있다라는 특징이 있습니다. 그림 자체는 uml로 나타낸 해당 컴포넌트 다이어그램이 되겠습니다.

04:51
컴포넌트는 사각형에 이렇게 조그마한 직사각형이 두 개가 붙어 있는 모양을 가집니다. 네 번째 프레임워크입니다. 여러 가지 기능을 하는 클래스들이 서로 유기적 관계를 맺으면서 어떠한 기능을 수행하는 클래스 혹은 컴포넌트들의 집합이 됩니다. 프레임워크의 종류는 스프링 프레임워크라든지 단내 프레임워크라든지 전자 정보 프레임워크 등이 있고요. 라이브러리와 프레임워크는 어떻게 차이가 있나요? 라이브러리는 클라이언트 소프트웨어가 일방적으로 호출만 하고 끝인데 프레임워크는 클라이언트 소프트웨어가 호출을 하기도 하고 또 호출을 당하기도 하고 서로 간의 상호 유기적인 관계 그런 차이점이 있습니다.

05:44
관련되어진 해당 퀴즈 문제 보도록 하면 다음 중 소프트웨어 공통 모듈의 종류가 아닌 것은 클래스 라이브러리 컴포넌트 프레임워크 cpu가 아니죠. 틀린 것은 3번 cpu입니다. 공통모듈도출입니다. 공통 모듈 도출을 하는 기준으로서 방식을 하향식 공통 모듈 도출과 상향식 공통 모듈 도출 살펴보도록 하겠습니다. 하향식이라는 것은 위에서부터 아래로 이미 만들어진 개발 프레임워크에서 제공을 하는 공통 기능을 공통 모듈로 정해서 재사용하는 것을 이야기합니다. 계정관리 로그인 관리 시스템 관리 공통 기능으로 써요 이러한 것들이 있는데, 우리는 개발 프레임워크에 있는 계정관리를 그대로 따와서 우리가 이용할 거야.

06:43
이렇게 위에서부터 아래로 뽑아서 사용하는 방식이고 상향식 공통 모델 도출이라는 부분은 밑에 실제적으로 해당 요구사항들을 중심으로 만들어진 기능 목록 중에서 공통적인 기능을 뽑아가지고, 즉 여러 부서에서 공통으로 사용하는 기능들을 뽑아서 선택하는 방식이다 라고 보면 되겠습니다. 인사부서에서도 또는 영업부서에서도 직원 조회나 이러한 것들을 사용하더라 그런 경우에는 뽑아가지고, 공통 모듈로 선택할 수 있겠습니다. 공통적인 도출과 관련되어진 퀴즈 문제입니다. 다음 중 공통 모듈의 대상으로 적합하지 않은 것은 문제를 잘 보셔야 돼요.

07:31
맞는 거냐 틀린 거냐 라는 부분 아는 거 틀린 거 전 부서 모든 부서에서 사용하는 직원 조회 기능이야 전체적으로 사용하니까 공통으로 뽑는 게 좋겠고 개발 프레임워크에서 공통으로 제공하는 시스템 관리 기능이야 이건 하향식이겠죠. 모든 부서에서 사용하는 전표 정리야 모든 부서 생산부서에서만 사용하는 생산지식 기능이야 특정 부서에서만 사용하니까 얘는 공통 모듈로 대상으로 뽑는 것은 부적합하겠습니다. 공통 모듈 설계입니다. 네 공통 모듈 설계 순서 모델링 제의문에 대한 uml로 어떻게 모델링하는지 그 과정 질문을 설명하고 있는 부분이 되겠고요. 먼저 요구사항들을 뽑아서 나열해놓은 정리해놓은 요구사항 기술서를 베이스로 해서 먼저 유즈 케이스 다이어그램을 그립니다.

08:27
유즈케이스 다이어그램은 시스템이 담당해야 될 기능적인 부분을 정리하는 부분이거든요. 이 유지케이스 다이어그램을 바탕으로 다시 정적 모델링으로서 클래스 다이어그램과 컴포넌트 다이어그램 그리고 동적 모델링으로서 시퀀스 다이어그램과 액티비티 다이어그램을 순차적으로 만들어 갑니다. 유스케이스 다이어그램 작성은 보는 예제처럼 이렇게 그려져 있는데, 막대 인형이 액터입니다. 액터 사용자 사람이 될 수도 있고요. 시스템이 될 수도 있습니다. 그 다음에 동그라미 타원형으로 되어있는 부분들이 유즈 케이스 하나의 유즈 케이스에는 하나의 업무만 담당하도록 설계를 하고요. 그리고 액터는 그 유즈 케이스를 수행하는 당사자가 되겠다. 해당 이 액터가 이용하는 유즈 케이스에 대해서는 이렇게 관계를 설정을 하면 되겠고요.

09:24
유즈 케이스와 유즈 케이스 간의 관계는 다시 포함하는 인클루드 관계와 그러니까 인클루드는 일반적으로 필수관계라고 생각하시면 될 것 같고요. 쉽게 구분할 수 있는 방법은요, 회원가입하기 위해서는 반드시 주소 입력이 필수야 그러면 얘를 이용을 해야 되는 거고, 익스텐드라고 하는 부분은 확장입니다. 얘는 옵션입니다. 주문 결제를 하는데 결제방식으로서 포인트 결제만 해야 되는 게 아니라 현금결제도 할 수 있고 신용카드 결제도 할 수 있죠. 인클루드와 익스텐드 구분할 수 있으면 되겠고 다음 유즈 케이스가 유즈 케이스 다이어그램이 작성되어지면 그다음에 하는 부분은 뭐냐 하면 유즈 케이스 명세서를 기술합니다. 유즈 케이스 명세서 양식의 일반적인 양식인데요. 제일 상단에 유즈 케이스 이름이 들어가지고요.

10:19
그리고 목적 그리고 해당 이 유지 케이스를 이용하는 액터 그리고 이 유지 케이스를 이용하기 위해서는 사전에 어떤 조건이 갖춰져야 돼 일례로 회원가입을 한다고 되어 있으면 시스템이 켜져 있어야 돼요. 시스템은 켜져 있고 로인 대기 상태가 되어져야지 회원 가입을 할 수 있다. 그리고 사후 조건은 회원가입을 하고 난 다음에 해야 되는 반드시 해야 되는 거 여기서는 없음으로 돼 있고 포함 확정 유지 케이스는 없어 정상적인 흐름이 있고요. 일반적인 흐름이 있고 그다음에 이 흐름상에서 선택적으로 해야 되는 경우가 있는 경우를 대체 흐름에 기술을 합니다. 올터너티브 정상적인 회원가입 절차는 이 절차로 쭉 수행을 하는데 그런데 대체어렴에서는 여기 보면 저희 ex적인 부분은 여기 ex라고 되어 있는 부분은 예외어램입니다. 예외어렴이라는 건 어떤 오류라든지 이러한 것들 자 순서상에서요 간단히 살펴보겠습니다.

11:18
너무 깊게 안 들어갈게요 이 파트도 마찬가지로 저희 실기 파트 첫 번째 세부 과목인 요구사항 확인 파트에서요 uml은요, 작성 방법 종류 이런 것들 다 정리할 테니까. 실기에서 좀 더 세부적으로 다루겠습니다. 그래서 개괄적으로 정상 흐름이 있고 대체 얼음이 있고 예외 흐름이 있다. 예외 흐름이라는 건 옳으라는 말입니다. 시스템에 중독번호가 유효한지 확인하는데 중독번호 잘못됐어 그런 경우에 오류 메시지를 띄워라 이 말이고요. 아이디 중복 체크를 했는데 중복된 경우가 생겼어 그럼 이거 사용 못해 다른 거 사용해 라고 알림을 띄운다든지 이렇게 보시면 되겠습니다. 유즈케이스명세서 자 그 다음에 클래스 다이어그램 작성입니다. 네 클래스 다이어그램 설계 클래스 다이어그램을 그려놓은 예시가 되겠는데요. 클래스 타이그램은 종류가 세 가지가 있습니다.

12:14
세 가지를 라디오 타입으로 해서 위에 단에다가 이렇게 표기를 해서 이렇게 꺾쇠 꺾쇠 이렇게 해서 표기를 해서 바운더리 화면 그다음에 컨트롤 그다음에 나중에 테이블로 저장되어지는 엔터티 이렇게 세 가지가 있는데, 표시를 이렇게 해가지고 하고요. 기본적으로는 사각김박스로 그립니다. 그다음에 3등분 해가지고요. 상단이 해당 클래스 이름값 그다음에 여기가 속성 중간단 마지막으로, 여기가 동작적인 부분에 대한 오퍼레이션 또는 메소드를 세 번째로, 메소드는 반드시 갈록 구름을 가집니다. 유즈케이스 명세서에서 사용되어진 명사에서 정리한 문구 중에 명사를 클래스 후보로 선정할 수 있고요. 그리고 유즈케이스에 사용되어진 동사 행위를 나타내는 동사 중에서 클래스의 동작을 나타내는 오퍼레이션으로 선정할 수 있고요.

13:13
그리고 유스케이스에서 사용되는 명사의 특징에서 속성 나중에 변수가 되는 거죠. 속성으로 선정할 수도 있다. 마찬가지 실기파트의 요구사항 분석 uml 파트에서 더 세부적으로 다루겠습니다. 시퀀스 다이어그램을 그립니다. 시퀀스 다이어그램은 시간적 순서에 따라서 해당 객체가 어떤 객체한테 어떤 메시지를 주고요. 순차적으로 어떻게 수행되어지는지 순차적 흐름적인 부분을 그려놓은 다이어그램입니다. 액터 유즈 케이스 다이어그램에 있는 액터를 그대로 사용하고요. 그다음에 시스템은 시스템 클래스에 있는 클래스 다이어그램에 있는 클래스 혹은 인터페이스를 사용하고요. 그리고 시퀀스는 해당 유스켓이 정해져 있는 행위의 흐름을 시퀀스 순차적으로 이렇게 회원가입 고객이요. 로그인 화면이 있고요.

14:12
클래스에 대한 표시 방식은 두 번째 표시 방식은 얘가 화면이에요. 이게 바운더리 화면 그다음에 동그라미에 화살표 되어 있는 부분은 얘가 컨트롤입니다. 제어 그다음에 동그라미 밑줄 그어져 있는 부분이 얘가 엔터티 두 가지 방식이 있습니다. 표현이 해당 순차적으로요 순번에 맞춰가지고 1 회원가입 요청해 로그인하면서요 해당 입력해야 될 회원가입 폼 양식을 작성하겠고 그다음에 로그인 화면에서 회원가입을 요청하게 되면 회원가입 폼이 나타나야 되죠. 회원가입 화면이 나타나고 그다음에 회원가입에 필요한 이름이나 주민번호번호를 입력을 하고 그다음에 실명인증을 요청하게 되면 회원가입을 처리하는 처리 페이지에서 처리를 하고요.

15:09
확인한 다음에 순차적으로 이렇게 진행되어진다 이렇게 보면 되겠습니다. 다음 공통 모듈 평가입니다. 공통 모듈의 평가 지표로서는 크게 똑같이 시험에 자주 나옵니다. 응집도 개념과 결합도 개념 정리하도록 할 건데 응집도라고 하는 부분은 인터페이스의 요청을 철회함에 있어서 공통 모듈 내에 클래스들 간의 인터뷰의 요청을 처리함에 있어서 공통 모듈 내에 있는 안에 있는 클래스들 간에 얼마적으로 내부적으로 이렇게 유기적으로 협업해서 처리하는가를 나타내는 정도가 응집도고요. 응집도는 높아야지 잘 설계되어진 모듈이 됩니다. 그래서 엄집도는 높여야 됩니다. 그리고 결합도는 모듈과 모듈 간에 다시 얘가 a라는 모듈의 b라는 모듈이 많이 종속적이다. 이러면 별로 설계가 바람직하지 못합니다.

16:08
그래서 오히려 결합도는 커플링을 낮춰야 됩니다. 세부적인 언집도 공통 모듈레이의 클래스들이 외부 기능을 수행함에 있어서 얼마나 서로 클래스들끼리 내부적으로 연계되어서 수행하는지를 나타낸다 그림상에서 보게 되면 왼쪽보다 오른쪽이 해당 공통 모듈 내의 엄집도가 훨씬 더 높습니다. 내부에 있는 클래스들 간의 서로 간의 연계 정도가 더 높게 나오죠. 오른쪽이 보다 바람직하게 설계된 부분이다. 이렇게 보면 되겠고요. 응집자의 종류 둘 넷 여섯 일곱 가지 있어요. 일곱 가지 있는데, 세부적으로 물을 때는 간혹 해당 응집자에 대한 설명 문구를 제시해 놓고요.

17:02
여기에 해당되는 응집도는 뭔데 라고 묻는 케이스로 출제가 시험 문제가 출제될 수도 있습니다. 응집도는 7개가 있는데, 7개 중에 기능적 응집도가 응집도가 제일 높아요. 네 기능적 응집도가 응집도가 제일 높습니다. 기능적 응집도라는 부분은 모듈 내부의 모든 기능이 단일한 목적을 위해서 수행하는 경우가 되겠다. 순차적 응집도 모듈 내에 한 활동에서부터 나온 출력값을 다른 활동에 사용하는 경우 통신적 응집도 동일한 입력과 출력을 사용해서 다른 기능을 수행하는 활동들이 모여 있는 경우 절차적 응집도 시간적 응집도 논리적 응집도 우연적 응집도는 모듈 내부의 각 구성요소들이 연관이 없는 경우다 응집도가 제일 낮은 게 우연적 응집도입니다.

17:57
자 해당 정도적인 부분에 대한 문제를 물을 때 조금 복잡하게 변별력적인 부분을 갖고 난이도 있게 하는 경우에는 순서를 따지는 경우도 있단 말이에요. 그런 경우에는 해당 이 머릿걸을 위주로 해서 익혀 놓으시면 네 기순 여러분들이 나름대로 연상할 수 있는 어떠한 문구적인 부분과 매칭시켜가지고, 해당 기순통 절시 노누 네 여기에 해당 나름대로 쉽게 암기할 수 있는 문장을 만들어 가지고 해 놓으시면 나중에 여러분들이 당장은 이제 안 된다 하더라도 시험장 가시기 전에 한번 이렇게 문장을 이렇게 만들어서 정리해 놓으면 혹시나 순서적인 측면으로 난이도 있게 이렇게 이렇게 나오면 풀 수 있게끔 준비를 하시면 좋을 것 같습니다. 결합도입니다. 결합도는 프로세스를 철회함에 있어서 각각의 공통 모듈이 서로 연계되어 있는 정도를 이야기한다.

18:54
근데 이 결합도는 높아야 좋은 게 아니라 낮아야 좋습니다. 낮다 라는 부분은 결합도가 낮다 라는 부분은 모듈 내에서의 응집도가 높다는 말이거든요. 그래서 다른 공통 모드를 호출해야 되는 경우가 많다 그런 경우에는 그 공통 모드는 결합도는 높지만, 품질도는 높지가 않다 라는 부분입니다. 이렇게 정리하겠습니다. 결합도도 종류가 지금 6개씩 쓰여져 있는데요. 내용 결합도 공통 결합도 외부 결합도 제어 결합도 스탠드 결합도 자료 결합도가 제일 높은 것은 내용 결합도가 제일 높습니다. 이 결합도가 높다라는 말은 모듈 간에 서로 다시 호출하는 경우가 많다 이 말입니다. 근데 소프트웨어적인 측면에서는 이게 바람직하냐? 바람직하지 않다 라는 부분입니다. 그래서 결합도는 낮아야 좋습니다.

19:50
자료결합도는 모듈 간 인터페이스로 전달하는 파라미터를 통해서만 모듈 간의 상호작용이 일어나 모듈 간 인터페이스를 통해 전달되는 파라미터를 통해서만 서로 간에 호출의 경우의 수가 많지 않다 이 말입니다. 마찬가지 케이스로요 해당 결합될 정도적인 부분을 묻는 문제가 혹시나 나올 수 있다면 앞에 있는 머릿걸 따내 가지고요. 여러분들이 이렇게 문장화해서 암기해 놓으시면 네 수월할 것 같습니다. 내공이 외제가 스자야 이런 식으로 나름대로의 문장을 만드셔가지고, 정리해 놓으시면 좋을 것 같습니다. 자 마지막으로, 문제 풀이하면서 정리하겠습니다. 첫 번째 다음 중 공통 모듈의 종류가 아닌 건 뭔데 공통 모듈의 종류 클래스 라이브러리 메모리 프레임어 이렇게 돼 있습니다. 공통 모듈의 종류는 클래스 라이브러리 프레임워크는 맞고 메모리는 하드웨어의 장치명이죠.

20:48
메모리가 엉뚱한 보기로 제시되었기 때문에 고를 수 있겠죠. 다음 두 번째 공통 모듈의 품질 기준에 대한 설명으로 틀린 것을 골라라니 맞는 게 아니라 틀린 겁니다. 응집도는 높을수록 품질이 좋다. 맞죠. 결합도는 낮을수록 품질이 좋아 맞습니다. 결합도는 하나의 공통 모듈이 타 모듈과의 연관관계에 관한 정도를 이야기해 그렇죠. 모듈 간에 서로 호출정도 이것도 맞아요. 응집도는 낮아야 결합도는 높아야 품질이 좋아 이게 틀렸습니다. 반대죠 응집도는 높아야 되고요. 결합도는 낮아야 품질이 좋습니다. 다음 세 번째 공통 모듈을 설계할 때 정적 모델링에 활용되는 uml 다이어그램에 해당하는 건 뭔데 정적이라는 말은 시간적 순서에 따라서 크게 바뀌지 않는 걸 이야기하는 거고요.

21:46
동적이라는 건 시간적 흐름에 따라서 변화가 있는 것을 이야기합니다. 유스케이트 다이어그램 클러스 다이어그램 시퀀스 액티비티 중에 정적 다이어그램에 해당되는 것은 대표적으로 클러스 다이어그램에 해당되어집니다. 네 번째 응집도의 종류 중에 서로 간에 어떠한 의미 있는 연관 관계가 지니지 않는 기능 요소로 구성되어 있는 경우에 해당하는 건 뭔데 자 응집자 종류 중에 서로 간에 어떤 의미가 없는 의미가 있는 연관 관계도 없다. 이 말입니다. 연관관계가 서로 없으니까 이 응집도가 제일 낮은 것을 이야기하는 거예요. 함수 순차 논리 우연 그중에서는 우연적 응집이 해당되어지겠습니다.

22:31
다섯 번째 어떤 모듈이 서로 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어 신호를 이용해서 통신의 이용하여 통신에 해당하는 결합도는 뭔데 해당 설명 문구 내에서요 반복적으로 나오는 단어는 제어입니다. 이렇게 유추해서 보기 항목에서 제어 결합도를 이야기하는구나 이렇게 고를 수 있어도 됩니다. 문제의 난이도가요 굉장히 까다롭게 다 어렵게는 나오지 않습니다. 그렇기 때문에 문제가 상중하 이렇게 돼 있기 때문에 웬만하면 1분 30초 내에 쉽게 고를 수 있게끔 사직 쓴답표가 나옵니다. 개념 정리만 잘 하시면 돼요. 마지막으로, 핵심 정리하고 마치겠습니다. 공통 모듈이란 시스템을 구축할 때 여러 하위 시스템에서 공통으로 서로 사용하는 모듈을 모아놓은 소프트웨어 꾸러미를 이야기한다.

23:27
재사용성을 높일 수 있다. 공통 모듈의 종류는 클래스 라이브러리 컴포넌트 프레임워크가 있다. 네 두 번째로, 공통 모듈 도출입니다. 공통 모듈 도출은 하향식 기법은 상단의 상위의 개발 프레임워크에서 공통적인 모듈을 뽑아서 가져오는 게 하향식 기법이고요. 상향식 기법은 기능 목록을 기준으로 여러 부서에서 똑같이 사용하는 기능들 중에서 뽑는 게 상향식 기법입니다. 세번째 공통 모듈 설계입니다. 공통 모듈 설계는 요구사항을 분석할 때는 유지케이스 다이어그램 정적분석적인 측면의 대표는 클래스 다이어그램 그리고 동적분석의 대표는 시퀀스 다이어그램이 있습니다. 말로 공통 모듈 평가입니다.

24:15
공통 모듈 평가 기준으로서는 응집도 응집도는 모듈 내에 있는 클래스들 간의 상호 유기적인 관계 정도를 나타내는데 상호 유기적 관계가 높아야지 품질도가 높습니다. 반대로 결합도는 모듈과 모듈 간에 서로 간의 연관 관계인데 이 연관 관계는 오히려 낮아야지 품질도가 높다 이렇게 정리를 했고요. 이상으로 공통 모듈 설계 마치도록 하겠습니다. 소프트웨어 설계 세 번째 과목인 애플리케이션 설계 두 번째 파트 시험 출제 기준에서는 객체 지향 설계를 네 다루고 있는데, 저희 ncs 학습 모듈에서는 약간 혼동스러울 수 있는데, ncs 학습 모듈에서는 타 시스템 연동 설계로 되어 있습니다. 그래서 내용이 상이한 부분입니다. 시험 출제 기준에 맞춰서 제가 별도로 정리한 부분이니까.

25:06
고려하셔 가지고 수강하시길 권해드리고 이 부분은 시험 출제에서 자주 출제가 되는 파트예요. 학습 목표 객체 지향의 개념과 특징 그리고 클래스 간의 관계 설계 원칙에 대해 이해한다. 두 번째 디자인 패턴의 개념과 활용 목적 및 고프 디자인 패턴 종류를 이해한다. 학습 내용은 객체 지향 개념 특징 그리고 클래스 간 관계와 설계 원칙 마지막으로, 디자인 패턴 순서로 살펴보도록 하겠습니다. 용어 사전으로서 객체 지향 방법은 실 세계의 개체를 엔터티를 속성과 메소드가 서로 결합을 시켜 하나의 어떤 객체로 보고 구현 대상을 객체와 객체 간 관계로 모델링하는 방법이 객체 지향 방법이고요.

26:03
디자인 패턴이라고 하는 부분은 많은 개발자들이 프로그램 모델이 오랜 시간 동안 대가들이 많이 있잖아요. 많은 개발자들이 경험으로 체득한 설계 지식을 검증하고 이를 추상화해서 일반화시킨 템플릿이 디자인 패턴이고 디자인 패턴을 활용하게 되면 효율성과 재사용성을 높일 수가 있습니다. 객체지향의 개념과 특징입니다. 객체지향이란 오브젝트 오리엔티드 실세계의 객체 속성 메소드가 결합된 형태의 객체로 보고 구현 대상을 객체와 객체 간 관계로 모델링한 방법이다. 객체는 공통 객체대로 묶어놓은 꾸러미인 클래스에서 실체화시킨 거 인스턴스 한 게 객체가 됩니다.

26:55
밑에 보면 제가 uml 다이어그램으로 객체를 표현하는 다이어그램 그려놓았는데요. 왼쪽 부분은 얘는 클래스입니다. 클래스이고요. 오른쪽 부분이 객체입니다. 자 사각형 박스로 그려 놓았고요. 3등분을 했고 객체 이름 그리고 여기 속성 그 다음에 동작을 나타내는 메소드들이 이렇게 돼 있고요. 객체는 클래스하고 약간 차이 나는 부분은 해당 밑줄을 이렇게 쫙 그어놨어요. 그리고 오른쪽이 클래스명이고요. 왼쪽이 객체명이 되겠습니다. 객체의 지향은 특징으로서 다섯 가지 특징이 있습니다. 시험에 자주 나옵니다. 추상화상속 다형성 캡슐화 정보 원닉의 특징을 가지는데 이 다섯 가지 특징 세부적으로 살펴보도록 하겠습니다.

27:53
먼저 추상화란 앱스트랙션 뽑아낸단 말이에요. 뭘 뽑아내는데 객체 모델링을 할 때 해당 그 객체에서 필요로 하는 부분만 뽑아요. 속성과 동작을 객체를 모델링할 때 필요한 만큼의 속성과 오퍼레이션을 추출해내는 것을 이야기하는데 모델에서 뭘 이용할 건지에 따라서 포함시킬 거 또는 불필요한 구분이 될 수 있겠죠. 예를 들어 세탁기다 세탁기를 모델링 할 때 세탁기에서 꼭 필요한 것만 세탁기의 이름 브랜드명 모델명 시리얼 넘버 그리고 용량 용량이 얼마짜리 세탁기야 이렇게만 뽑아도 될 것 같아 그 외에 사이즈는 어떻고 크기는 어떻고 무게는 어떻고 이러한 것들은 굳이 필요 없어 그러면 뽑지 않은 거죠. 세탁기의 동작적인 부분 또 네 가지만 이렇게 뽑아가지고요.

28:48
except 클로즈 옷을 넣는다 또는 세제를 넣는다 또 전원기를 켠다 끈다 이 정도로만 해서 표현할 수도 있겠습니다. 두 번째 특징은 상속입니다. 상속은 상위 클래스에 정의해 놓은 속성과 행위 동작을 하위 클래스에서 그대로 이어받아서 이용할 수 있어요. 부모의 형질을 자식들은 그대로 물려받죠. 그리고 자식은 자식만의 또 특징을 가지죠 자 그래서 상속을 이용하게 되면 해당 구현 자체가 코딩이나 이러한 부분들이 좀 많이 수월해지고요. 그리고 유지보수가 용이하다는 특징이 있습니다. 상속을 관계를 그려놓은 다이어그램은 다음과 같습니다.

29:36
상속 간의 관계는요 라인으로 연결하고 이렇게 비어있는 삼각형으로 이렇게 인터페이스 연결점을 이렇게 표시를 합니다. 자동차라는 클래스가 있는데, 자동차 클래스의 종류로서 트럭이나 승용차나 트레일러와 승합차로 이렇게 나눌 수 있겠죠. 자동차의 속성으로 제조사와 시동 골절이라는 게 있다면 해당 트럭도 이 속성의 정의를 제조사라고 별도로 하지 않았지만 자동차 의 속성을 물려받기 때문에 트럭은 제조사라는 속성을 그대로 이용할 수가 있습니다. 시어링 골드라는 동작도 그대로 이용할 수 있고요. 추가적으로 얘가 주차하다 라는 부분을 종이해 가지고 이용할 수도 있고 다음 다형성입니다. 다형성이라고 하는 부분 자체는 상속을 받은 클래스가 상위 클래스에서 선언했던 행위예요.

30:28
동작적인 부분은요, 오퍼레이션을 하위 클래스도 이용할 수 있는데, 똑같은 이름으로 이용할 수가 있다라는 특징입니다. 그런데 똑같은 이름으로 이용을 하되 동작적인 부분은 하위 클래스의 특징에 맞춰가지고 달리 할 수 있다. 그게 메소드 오버 라이딩이라는 기법이고요. 해당 똑같은 동작을 수행하는데 어떤 동작을 수행할 때 소스 상에서 보게 되면 갈록 구름 안에 해당 얘가 메서드예요. 스타트 카 이렇게 돼 있습니다. 스타트 카인데 갈록 구르미 안에 스트링 a라고 하는 매개 변수의 값을 넘겨받아 가지고 저 a라는 값을 받았을 때는 어떤 게 시동이 걸리게끔 해 이런 식으로 달리 하는 부분이 메소드 오브 로딩이 되겠습니다.

31:17
그래서 메소드 오브 라이딩과 메소드 오브 로딩을 구분할 수 있어야 되는데 오버라이딩은요, 똑같은 이름인데 동작만 달리 수행하는 거예요. 로직을 수행했다. 이 말이고요. 오버로딩은요, 갈록꾸러미 안에 추가적인 매개변수를 넘겨받아요. 그 넘겨받는 매개변수의 종류에 따라서 실행 자체가 달라지게끔 그렇게 구현할 수가 있습니다. 다음 캡슐라인입니다. 인캡슐레이션 객체는 자신의 동작 원리를 클래스라고 하는 하나의 껍데기로 캡슐로 묶는다는 말이죠. 묶어가지고요. 처리를 하는데 그렇게 하게 되면 그 객체만이 자신의 operation 내부적인 동작이 어떻게 된다. 라는 것을 알고 외부에서는 알 수 없게 할 수 있죠.

32:15
캡슐화와 특징인 정보 은닉은 관련성이 있습니다. 정보 은닉이라고 하는 부분은 캡슐화되어진 항목의 인터페이스와 구현을 명확하게 분리해서 각 클래스의 내부 항목에 대한 부분을 오픈 안 시키는 거예요. 내부 항목에 대한 정보를 다른 객체로부터 숨긴다 메시지 전달을 통해서요. 메시지 전달에 의해서 다른 클래스에서 메소드를 호출해서 그냥 사용만 할 수 있게끔 그렇게 한 부분을 이야기합니다. 이렇게 해서 5가지 특징 살펴봤었고요. 관련해서요. 퀴즈 문제 한번 풀어보도록 하겠습니다. 네 시험 문제 요렇게 유형으로 나올 수 있습니다. 다음 중 다양성의 설명이 틀린 것을 골라라 이렇게 요구하고 있습니다. 자 다양성은요, 첫 번째 보기 상위 클래스에서 정의한 메소드를 하위 클래스에서 재정의할 수 있어 네 맞죠.

33:11
이게 밑에 메소드 오버라이딩 구체적으로는 뜻합니다. 다양성의 종류는 메소드 오버라이딩이 있고 메소드 오브 로딩이 있어 맞고요. 다양성은 상속을 기본으로 해 네 다양성은 상속을 기본으로 합니다. 상속관계 다양성은 상속을 전혀 사용하지 않아 엉뚱한 보기입니다. 4번이 틀렸습니다. 다음 클래스 간의 관계와 설계 원칙에서 클래스 관계 자 클래스는요 다른 클래스와 어떤 의미에서요 서로 간의 관계를 가질 수 있어요. 연관되어 있다라고 이야기를 하고요. 어소시에이션으로 표현을 합니다. 일례로 사람이요. 행위자가요 티비로 본다 사람이 티비로 본다 그런 경우에 사람과 티비 간의 관계 그래서 일단 이 사람이 tv를 일례로 켜다라고 하는 행위를 해당 이 tv에 유발한다. 그런 경우에 관계에 대한 부분에 대한 세부 내용을 여기다 표시할 수 있습니다.

34:02
여러분의 tv를 켜면 여러분의 tv와 단방향 관계를 가진다 사람이 tv를 볼 때만 tv를 켜니까 자 하나의 객체는 다른 객체와 두 개 이상의 연관을 가질 수도 있습니다. a라는 사람이 있고요. b라는 사람이 있는데, a라는 사람과 b라는 사람은요, 사업적인 측면에서 서로 동업자 관계예요. 그렇지만 개인적인 친분으로 서로 간에 친구예요. 그런 경우에는 동업자 관계도 있고 친구라는 관계도 두 개 이상의 연관을 가질 수도 있다. 네 그다음에 일반화와 특수화라는 관계인데 상속관계에서요 관점을 위에서부터 아래로 본다고 한다면, 위에서부터 아래로 본다고 한다면, 특수와 스페셜리제이션 관계라고 볼 수 있고요.

34:54
아래쪽에서 위로 본다면 제너럴리제이션 일반화라고 볼 수가 있습니다. 즉 도형이라고 하는 클래스가 있는데, 도형 클래스의 종류로는 다시 삼각형도 있고 사각형도 있고 원도 있어요. 근데 동일하게 에어리어라고 하는 면적을 구하는 메소드가 근데 해당 수행하는 메스워드의 결과치는 틀려요 삼각형은 면적을 구해 라고 하게 되면 밑변 곱하기 높이를 구하겠죠. 2분의 1 곱하기 밑변 곱하기 높이 곱하기 2분의 1로 이렇게 구하겠죠. 근데 사각형은 밑변 곱하기 높이로만으로도 뚝딱 구해지겠죠. 두 클래스 간의 상습관계가 있을 때 아래에서 위로 추상화하면 일반화고 위에서 아래로 구체화하면 특수화가 된다. 집합관계입니다. 집합연관이라고도 합니다.

35:46
하나의 클래스가 여러 개의 컴포넌트로 구성되어 있는 경우 예를 들어 밑에 보면 다이어그램은 해당 홈컴퓨터라고 하는 클래스가요 우리 이러한 하위에 어 가까이 여러 클래스테롤로 모여가지고 구성이 되어진다 컴퓨터는 스피커도 있죠. cpu 박스도 있고 키보드도 있고 모니터도 있고 마우스 등등이 있다. 집합 연관인 경우에는요 상속인 경우에는 해당 상위 클래스와 연결을 할 때 인터페이스 연결점을 비어있는 삼각형을 표시를 했어요. 상속은 근데 집합 연관은 비어 있는 마름모로 이렇게 표시를 해서 구분합니다.

36:30
그리고 뒤에 마지막에 있는 해당 관계 복합 연관은 컴파짓 릴레이션십으로 되어 있는데, 복합 연관은 해당 기호 자체가 채워있는 마름모로 표시가 되어집니다. 그럼 집합과 복합은 어떤 차이가 있느냐 집합과 복합의 차이는요 같이 연결되어진 해당 클래스가 따로 떼 놓았을 때 전혀 동작적 기능적인 부분을 수행할 수 없는 경우는 복합 연관입니다. 일례로 커피 테이블이 있는데, 커피 테이블은 몸체와 다리로 구성되어 있는데, 다리 4개만 뚝딱 떼내가지고 뭔가 동작을 할 수 있느냐 못해요. 얘는 반드시 몸체하고 이렇게 연결되어 가지고요. 해당 어떤 테이블로서의 역할을 할 수 있어요. 그래서 복합관계와 집합관계 구분할 때는 집합 같은 경우 스피커 마우스 이런 거 별도로 동작을 한단 말이에요.

37:26
어쨌든 나름대로 의미를 가진다 가지지 못한다. 이렇게 구분할 수 있겠습니다. 네 클래스 설계 원칙입니다. 네 5가지 원칙이 있는데, 5가지 원칙을 그냥 구분할 수 있게끔만 익혀 놓을게요 단일 책임이다. 책임이 하나야 이 말입니다. 클래스는 한 가지 책임 한 가지 기능을 갖도록 설계하자 개방 폐쇄 열고 닫는다 이 말이죠. 확장 상속에서는 열려있어야 되구요. 상속에서는 열려있어야 되고요. 그 다음 변경에서는 닫혀 있어야 된다. 해당 상위 클래스가 가지고 있는 속성과 메소드는 하이 클래스에서는 그대로 물려받게끔 오픈 근데 하이 클래스에서 상위 클래스의 뭐를 바꾸려고 해 안 되죠. 그렇게 하면 안 되겠죠. 개방 폐쇄 원칙 그리고 리스코프 교체의 원칙이란 리스코프 교체 원칙은 상속 관계에 있는 상위 클래스가 있는데, 상위 클래스는 하위 클래스로 대체할 수도 있어야 한다.

38:26
라는 개념이 리스코프 교체의 원칙입니다. 자 의존 관계 역전의 원칙이다. 하니 의존 관계 역전은 클라이언트가 구체적인 클래스 클래스가 아닌 추상 추상 클래스 앱스트랙트 클래스에 대해서는 의존해야 한다. 의존 관계 역전 추상 클래스에 부채 클래스는 의존해야 된다. 인터페이스 본리의 원칙 하나의 일반적인 인터페이스보다는 구체적으로 여러 개의 인터페이스가 낫다 자 문제 바로 보도록 하겠습니다. 문제 어떻게 나오냐면요 이렇게 나올 수 있어요. 일례로 리스코프 교체 원칙으로 옳은 걸 골라 이렇게 리스코프 교체 원칙은 상위 클래스를 하위 클래스가 대체할 수 있어야 된다. 라는 개념이었어요. 그 개념을 설명하고 있는 문구를 골라보도록 하겠습니다.

39:22
첫 번째 모듈의 설계는 확장에 대해서는 열려 있어야 하고 수정에 대해서는 닫혀 있어야 해 이거는 개방 폐쇄의 원칙이었습니다. 개방 폐쇄의 원칙 두 번째 b가 클래스 a의 자식이야 a가 그러면 상위라는 거죠. b가 하위 자식이라는 말입니다. a 클래스가 요구되는 곳에서 b 클래스의 인스턴스가 사용될 수 있도록 a가 상위 b가 하위일 때 a를 b가 대체할 수 있어야 돼 라는 설명이니까. 두 번째가 리스코프 교체 원칙을 설명하고 있는 문구입니다.

40:11
세 번째 구체적인 클래스보다 인터페이스나 추상 클래스에 대해서 의존 되도록 설계해야 해 보는 의존 관계 역전의 원칙 마지막으로, 법령적 목적의 단일한 인터베이스보다 클라이언트별 인터베이스를 다수 갖는 게 좋아 라고 하는 부분은 인터베이스 분류의 원칙을 설명하고 있는 문구가 되겠습니다. 자 마지막 파트입니다. 디자인 패턴입니다. 디자인 패턴 개념으로서 디자인 패턴이 뭔데 디자인 패턴은 많은 개발자들이 경험으로 체득한 누적되어진 설계 지식을 검증해서요. 이를 추상화해서 일반화하는 템플릿이다. 나름대로 하나의 모델화시켰다는 말입니다. 그걸 패턴이라는 용어를 사용을 하는데 객체지향 설계에서 해당 패턴이라는 부분 자체가 디자인 패턴이라는 부분 자체가 주목받기 시작한 것은 사람 이름입니다.

41:08
에릭 감마 리처드 헬롬 라이프 존슨 존 블리시지데스가 제안한 고프의 디자인 패턴이라는 책이 95년도에 출간되면서였는데 고프라는 부분은 갱 오브 포의 약어예요. 고프디자인패턴 자 뒤에 세부적으로 고프 디자인 패턴 23가지 23개 3가지 패턴을 제시하는 게 있는데, 살펴보도록 하겠고 디자인 패턴의 장단점입니다. 디자인 패턴을 사용하게 되면 장점적인 부분에서는요 서로 간에 개발자들이 패턴을 알고 있으면요 의사소통이 수월해요. 그래서 개발자 간의 원활한 의사소통 우리는 이 패턴을 이용했어. 아 그래 바로 이해할 수 있으니까 그리고 또 알고 있는 패턴으로 만들었으면 소프트웨어 구조 파악도 용이해요.

41:57
그리고 재사형성 네 재사형성을 통해서 개발 시간도 단축시킬 수 있고 설계 변경 요청에 대한 것도 유연하게 대처할 수가 있다는 게 장점이고요. 단점은 객체 지향 설계 중심적인 구현이어야 가능하고 그리고 초기에 예를 또 적용하기 위해서 시간이라든지. 비용 같은 것들이 투자가 될 수 있다는 게 단점입니다. 고프의 디자인 패턴 분류입니다. 크게 두 가지 목적과 범위에 따라서 분류할 수가 있고요. 목적은 다시 세 가지 생성패턴이냐 구조패턴이냐 행위패턴이냐 생성패턴을 만든다는 말입니다. 객체의 생성과정과 관련 관여 생성 과정에 관여하는 패턴이 생성패턴이 되겠고요. 구조패턴은 클래스나 객체 합성과 관련되어진 패턴이 되겠고 마지막이 행위패턴입니다. 어떤 동작적인 부분이겠죠.

42:56
클래스나 객체들 간의 상호작용이라든지. 책임을 분산하는 방법을 방법과 관련되어진 부분이다. 그래서 이렇게 세 가지로요 생성 패턴 구조 패턴 행위 패턴으로 나누는데 해당 적용되어진 범위에 따라서 클래스에 적용되어지는 패턴 네 개가 있고요. 나머지가 객체에 적용되는 패턴인데 이 클래스하고 객체하고 공통으로 적용되어지는 패턴이 하나 있어요. 어댑터 패턴이라고 자 종류별 이 목적에 따른 분류의 개수를 한번 따져보도록 하겠습니다. 생산패턴은 몇 개인데 생산패턴은 하나 둘 셋 이거는 같이 묶이는 거예요. 두 줄이 그래서 팩토리 메소드 패턴 앱스트랙션 팩토리 패턴 빌드 패턴 프로토타입 패턴 싱글톤 패턴 이렇게 다섯 가지입니다.

43:53
구조 패턴은 몇 개인데 구조 패턴은 어댑터 이거 같은 거예요. 적용 범위가 클래스냐 객체냐로 구분한 거고, 어댑터 패턴 브릿지 컴파워지 데크로에이션 페케이드 플라이어 웨이트 프렉시 7개입니다. 전체 몇 개인데 23개입니다. 23개에서요 네 5개하고요. 7개를 빼게 되면요 남는 것은요, 11개죠 행위패턴이 11개입니다. 제일 개수가 적은 걸 익혀야겠죠. 암기한다면, 많은 걸 암기하기보다는 그래서 생성 패턴 5가지만 알아놓으시면 좋을 것 같아요. 패턴의 목적에 따른 분류 다음 중 패턴의 종류가 틀린 걸 골라 제시되어진 보기 항목 중에 23개 중에 5가지는 쉽게 이해할 수 있겠죠. 그리고 생성이에요. 이름값 자체도 만드는 것과 관련되어져 있어요.

44:50
그래서 5개 팩토리 메서드 그다음에 앱스트랙션 팩터드 팩토리 빌드 프로토타입 그리고 싱글톤 이 5개는 알아놓으시면 좋을 것 같고, 세부 설명들이 쭉 있는데, 생성 팩토리 위주로만 명확하게 좀 익히면 좋을 것 같고요. 제가 색깔로 좀 구분을 했는데 시험에 좀 자주 나왔던 게 5개 정도 범위가 시험에 좀 자주 나오고 있어요.

45:11
생성패턴 앱스트랙트 팩토리 패턴은 공장과 같이 부품을 조합해서 인스턴스 생성을 실행하는 패턴이야 빌더라는 부분 자체는 해당 복잡한 인스턴트를 조립하여 만드는 구조로 객체를 생성하는데 객체를 객체를 생성하는 방법과 객체를 표현하는 방법을 분리하는 패턴이 빌더 그리고 팩토리 메소드 패턴은 상위 클래스에서 인스턴스 작성법의 뼈대를 세우고 구체적 작성은 하위 클래스에서 실행하는 패턴이야 프로토타입 자주 접했던 용어입니다. 모형이 되는 인스턴스를 복사해서 인스턴스를 만드는 패턴 싱글톤 싱글이란 말이에요. 하나란 말이에요. 인스턴스가 하나만 존재하게끔 한다.

46:03
클래스의 객체로서 한 개의 객체만 만들어지게끔 하는 패턴 이렇게 다섯 가지 그다음에 구조 패턴 이름만 빨간 것만 위주로 살펴보고 나머지 이름만 보겠습니다. 어댑터는 서로 다른 인터페이스를 갖는 클래스들을 연결하는 패턴이야 서로 다른 인터페이스를 갖는 클래스들을 연결하는 패턴 빨간 거 패케이드 복잡하게 핀 클래스를 개별적으로 제어하는 게 아니라 창부 역할을 한인 클래스를 하나 배치해서 시스템 전체적인 조작을 좋게 하는 패턴이야 은행에 갔을 때 여러분들이 언행 업무를 수행하기 위해서 지점장 나오세요. 저하고 이야기 좀 합시다. 직접적으로 컨택 안 되죠. 언행에 창고에 있는 언행원하고 내가 뭐 하러 왔어요. 이렇게 되겠죠.

46:50
개념적으로 그래서 팩케이드는 창고 역할을 하는 클래스를 하나 배치해서 시스템 전체 조작을 좋게 하는 패턴이야 나머지는 이름만 브릿지 컴파지 데크로에이션 플라이웨이트 프락시 다음 행위패턴 11개 있습니다. 이 중에서 빨갛게 되어 있는 부분 스트레티지 전략이라는 말이잖아요. 스트레티지의 주 키워드는 알고리즘을 주 키워드로 해서 익혀 놓으실 필요가 있어요. 알고리즘이라는 단어가 들어가면 스트레티지입니다. 스트레치지는 알고리즘을 전부 교체해서 수정하기 쉽도록 하는 패턴이야 나머지는 이름만 체인 오브 리스폰시빌리티 컴맨드 인터프리트 이터레이터 미디어터 네일 메멘토 오브즈 오브 스케이트 네일 템퍼드 메소드 비지트 암기할 필요 없습니다. 제가 말씀드렸죠 빨간 거 위주 그리고 생성 패턴 위주로만 익혀도 문제 푸는데 크게 어려움은 없습니다. 싱글톤 패턴의 규칙의 예입니다.

47:48
패턴을 이용하게 되면 장점은 기존에 해당 이러이러한 패턴을 정의해놨단 말이에요. 이 경우에는 이렇게 사용하는 게 좋아요. 그리고 그때 어떻게 사용하는지 라는 부분에 대한 예시 소스도 제시를 하거든요. 그래서 싱글톤 같은 경우에는 특정 클래스의 객체가 한 개가 존재하도록 제한하는 것을 이야기하는데 경우가 예를 들어 컴퓨터가 프린터를 공유해서 이용할 때 해당 프린터는 공유가 되어 있다 하더라도 a라는 사람이 프린팅 요청한 부분을 다 프린팅하기 전에 b라는 사람이 요청하더라도 얘는 얘는 프린팅되지 않고 a가 다 출력되고 난 다음에 그와 같이 어떠한 작업을 수행하는 특정 클래스의 객체가 하나만 존재하도록 하는 경우 같은 경우에는 어떻게 소스 코딩을 하는 게 낫다고 이렇게 견본 예시가 제시되어 있다 보니까 이들을 활용해 가지고 하면 돼요. 이름값만 바꿔가지고 자바 소스의 코딩 예제이고 uml에 해당하는 클래스 예제입니다.

48:47
넘어가겠습니다. 자 디자인 패턴에 대한 퀴즈입니다. 다음 중 성격이 다른 디자인 패턴은 뭐야? 브릿지 패턴 팩토리 메스워드 패턴 프로타입 패턴 싱글 톤 패턴 생성패턴 다섯 가지 기억만 하라 말씀드렸죠 이 세 개는 생성패턴이고요. 브릿지 패턴은 종류가 다릅니다. 자 모의평가 네 문제 풀어볼게요 객체에 대한 기법에서 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 게 무엇이라고 하는가? 클래스 함수 메소드 메시지 메소드 클래스입니다. 기존에 정보처리기사 기출문제에서 자주 나왔던 문제 유형입니다.

49:36
다음 객체의 제한 시스템에서 자료 부분과 연산 부분 등 정보 처리에 필요한 기능을 하나의 테두리로 묶었다 하나를 꾸러미로 묶었다 이게 뭔데 정보 은닉이라고 생각할 수도 있는데, 정보 은닉은 얘를 숨겼다는 게 포커스를 두고 이야기하는 특징이고요. 묶었다라고 하는 부분은 캡슐레이션 캡슐라를 뜻하는 문제가 되겠습니다. 객체 지향 특성 5개 구분할 수 있어야 됩니다. 디자인 패턴을 이용한 소프트웨어의 재사용으로 얻어지는 장점이 아닌 건 뭔가 틀린 것을 이야기하는 겁니다. 재사용으로 얻어지는 장점이 아닌 거 개발 프로세스를 무시할 수 있어 설명이 아니고요. 소프트웨어 코드의 품질 향상 개발자 간의 의사소통 원활 그리고 소프트웨어 품질 및 생산성을 높일 수 있어 이 세 가지는 장점이 되겠습니다.

50:35
디자인패턴 네 번째 다음 중 전략 패턴요 스트레치지 패턴에 대한 설명으로 올바른 거 골라 아까 제가 스트레치지 할 때는 주 키워드를 하나만 기억하세요. 알고리즘이라고 말씀드렸습니다. 알고리즘이라는 키워드가 들어가 있는 보기 항목을 고르면 되겠습니다. 다양한 알고리즘이 존재할 때 이들 각각을 하나의 클래스로 캡슐화해서 알고리즘 대체가 가능해 1번이 정답입니다. 23개나 되는 패턴을 저희가 다 구분할 수는 없잖아요. 그렇기 때문에 생성패턴 5개 위주 빨갛게 표시되어져 있는 거 정도만 위주로 하시면 되겠습니다. 핵심 정리 정리하고 마치겠습니다. 객체 지향 실생의 개체를 속성과 메서드를 결합해서 하나의 객체라는 단위로 만들고 그 객체와 객체 간의 관계로 모델링하는 방법이다. 객체자의 특징은 다섯 가지가 있다. 뽑아낸다 추상화 물려받는다.

51:32
상수 그다음에 똑같은 이름인데도 다양하게 동작시킬 수 있어 다형성 그다음에 묶는다 캡슐과 그리고 묶어서 안 보이게 해 정보는 클래스 간의 관계 클래스들은 서로 한 개 이상이 서로 관계를 가질 수 있는 그 관계 종류는 서로 연관되어 있어 연관 관계 그리고 일반화 특수와는 상속 관계에 있을 때 위에서 아래로 특수화 아래에서 위로 일반화 그리고 집합관계 복합관계가 있는데, 해당 구성요소들을 따로 떼어 놓았을 때 나름대로 기능을 수행하면 집합관계 그렇지 못하면 복합 연관이라고 말씀드렸습니다. 마지막으로, 디자인 패턴입니다.

52:16
많은 개발자들이 오랫동안 체험으로 경험으로 체득한 설계 지식들을 이제는 어떤 어떤 부분에 대해서는 저 사람이 사용하는 방식을 표준으로 써도 될 것 같아 일반화한 템플릿이고 디자인 패턴을 사용하면 효율성과 재사용성을 높일 수 있다. 고프의 디자인 패턴 종류 생성패턴 목적에 따라서 구조 패턴 행위패턴 그중에 생성패턴 다섯 가지만 기억하시면 좋을 것 같고, 빨갛게 표시했던 부분만 추가적으로 더 알아놓으면 좋을 것 같습니다. 네 이상으로 객체지향 설계하기 살펴봤습니다.

728x90
반응형
posted by 아이윤맨
: