백자의 블로그

기출문제

1. 재사용성과 유지보수 향상을 위한, 객체지향 설계 5대 원칙의 개요

• 소프트웨어 개발 및 유지보수성 향상을 위한 설계관점의 기본원칙
• 코드를 좀더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위한 설계
• 재 사용성, 유지 보수성, 이식성 통한 생산성 및 품질의 향상
• 모형의 적합성: 현실 세계 및 인간의 사고 방식과 유사
• 일관성, 추적성: 전체 공정에서 각 단계간의 전환과 변경이 자연스럽고 신속함

1. 객체지향 설계 원칙 ( 5대 원칙, SOLID )

구분	설명
정의	- 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 설계 원칙
특징	- 응집도 향상으로 유지보수성 향상 - 하나의 책임만을 수행하기 때문에 변화에 적응도 높음 - 두 개 이상의 책임을 가지면, 온전한 책임을 다할 수 있도록 분리
예시
예시 설명	-  (a)는 단일책임 원칙을 따르지 않은 클래스로 메서드가  DB관련 메서드들과 비즈니스 관련 메서드들로 구성되어 있음. - 단일책임의 원칙을 지키기 위해 (b)와 같이 각각의 책임을 갖는 두 개의 클래스로 분할

1. 개방 폐쇄 원칙 ( OCP : Open Closed Principle)

구분	설명
정의	- 소프트웨어 Entity(classes, Modules, Function)는 확장에는 열려있고 수정에는 닫혀있어야 한다는 설계 원칙
특징	- 기존 코드의 변경 없이 확장을 통한 코드의 변경을 허용 - 오버라이딩 - 상속을 의미하지만, 크게 유연석 확보 차원의 원리 - 기능의 상속이 아닌 설계의 유연성을 강조 Open(클래스 수직관계),   Close(클래스 수평관계) - Strategy 패턴 : 인터페이스 변경은 어려우나 구현은 열려 있음
예시
예시 설명	- 원칙을 따르지 않고 설계 시, 삼각형, 사각형, 원 등의 면적을 구하려면 (a)와 같이 각 도형의 면적을 구하는 메서드가 하나의 클래스에 모두 존재하게 됨. - 상속의 개념을 적용하여 (b)와 같이 설계하면 클라이언트가 추상클래스에 의존하므로 구체클래스의 내부 변경에 영향을 받지 않음.

1. 리스코프 치환의 원칙 (LSP :Liskov Substitution Principle)

구분	설명
정의	부모 클래스의 객체(타입과 매소드의 집합)들이 자식 클래스 사용되는 곳에 대체될 수 있어야 한다는 설계 원칙 that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
특징	- 클래스의 생성 목적에 맞게 설계하기 때문에 상/하위 클래스의 호환성 향상 - 하위 클래스는 상위 클래스의 책임을 넘지 않음 - 하위 클래스는 사용자의 요구 사항대로 설계됨.
예시
예시 설명	- LSP를 위배하는 예제 - Introduce를 상속한 DetailIntroduce 클래스가 함수 q가 요구하는 행동을 하지 않고, 엉뚱한 소리를 하고 있음 - 위의 예는 error 클래스를 만들때 주로 나타날 수 있음 - 하위 클래스의 행동 또한 상위 클래스의 책임범위 내에서 생성되어야 함

1. 인터페이스 분리의 원칙(ISP/Interface Segregation Principle)

구분	설명
정의	- 어떤 클래스가 다른 클래스에 종속될 때는 최소한의 인터페이스만을 사용해야 한다는 설계 원칙
특징	- 인터페이스의 단일 책임을 강조 - 하나의 인터페이스에 해당 인터페이스의 목적에 부합되지 않는 기능을 선언하지 않기 때문에 구현 클래스에서 불필요한 기능의 구현 방지 - 소스 레벨의 가독성 향상
예시
예시 설명	- 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다는 것. - 클래스는 사용자에게 꼭 필요한 메서드만 갖는 인터페이스를 제공 - 인터페이스 분리의 원칙은 (b)처럼 각 클라이언트에 맞는 인터페이스만 분리하여 사용

1. 의존성 역전의 원칙(DIP/Dependancy Inversion Priciple)

구분	설명
정의	- 높은 레벨의 모듈은 낮은 레벨의 모듈을 의존하면 안되며 서로 추상에 의존해야 한다는 설계 원칙 - 클라이언트 변경 최소화를 위해 클라이언트는 구체 클래스가 아닌 인터페이스나 추상 클래스에 의존한다는 설계 원칙
특징	- 구현 클래스에 의존성이 제거하여 낮은 결함도 유지 - 추상화된 클래스에 의존하기 때문에 확장성이 높아져서 유지보수성 향상
예시
예시 설명	- 의존관계 역전의 원칙은 상속 개념을 적용할 때 (a)와 같이 구체 클래스에서 상속을 받는 구조로  설계하지 말라는 것, 이유는 구체 클래스는 추상 클래스(인터페이스)보다 변하기 쉽기 때문 - 의존 관계를 구체 클래스에서 추상 클래스로 바꾸면 향후 변경에 따른 영향을 최소화할 수 있고, 느슨한 결합도를 유지할 수 있다. - (b)처럼 변화에 따른 충격에서 자유롭도록 추상 클래스를 만들고 그 추상 클래스와 상속 관계를 유지하도록 설계

1. 객체 지향 설계의 향후 전망 및 실무 적용 시 고려 되어야 될 사항

1. 객체 지향 기술 적용 시 고려 되어야 할 항목

기출문제

I. 객체지향(Object Oriented)의 개요

  가. 객체지향의 정의

- 현실 세계에서 개체(Entity)를 속성(Attribute)과 메소드(Method)를 결합된 형태의 객체(Object)로 표현하는 개념

- 구현대상을 하나의 객체로 보고, 그 객체를 객체와 객체들 간의 관계로 모델링하는 방법

  나. 객체(Object Oriented)의 구성 및 구성요소

- Class간의 Relation, Object간의 상호작용은 메시지를 통해 이루어짐.

특징	설명
클래스 (Class)	-객체의 타입을 정의하는 템플릿 -여러 객체가 공통적으로 가지고 있는 속성과 메소드를 클래스로 정의하고 클래스에 의해 객체가 재 정의 되는 구조
객체 (Object)	-클래스의 인스턴스(실제로 메모리상에 할당된 것) - 자신 고유의 데이터(Attribute)를 가지며 클래스에서 정의한 행위(Behavior)를 수행 - 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용
메소드 (Method)	- 클래스로부터 생성된 객체를 사용하는 방법 - 객체에 명령을 내리는 메시지라 할 수 있음. - 객체 간의 통신은 메시지를 통해 이루어 짐.
인스턴스 (Instance)	- 프로그램에서 클래스를 통해 만든 실제의 실행 객체, 프로그램의 실행 단계에서 나타냄.

II. 객체지향(Object Oriented) 프로그래밍의 특징(기법)

가. 캡슐화(Encapsulation)

구분	상 세 내 용
정의	- 객체의 속성(Data Fields)과 행위(메소드, Methods)를 하나로 묶고, 실제 구현 내용 일부를 일부에 감추어 은닉하는 객체지향의 특성 - 객체 정보은닉의 확장 캡슐화
특징	- 클래스를 선언하고 그 클래스를 구성하는 객체에 대하여 “public” 선언 시 외부에서 사용가능, “private” 선언 시 불가 - 메시지 통해 접근
장점	- 소프트웨어의 유지보수 생산성 증대 - 재사용성이 높은 소프트웨어 개발 - 정보은닉으로부터 내부자료에 대한 일관성 유지
Code

나. 추상화(Abstraction)

다. 다형성(Polymorphism)

- 오버라이딩과 오버로딩 특징

- 오버라이딩과 오버로딩 사례

구분	Overloading	Overriding
개념	메소드의 이름은 같으나 인자의 타입 및 개수가 다른 경우, 동일 클래스의 동일 메소드로 매개변수 다르게 하여 정의하는 기법	상속관계에 있는 두 클래스 중 하위클래스에서 상위클래스의 메소드를 재정의하여 사용하는 기법
클래스 다이어그램
샘플코드

- Java에서는 가상(virtual)을 따로 선언하지 않아도 되나 C++에서는 다형성을 구현하기 위해서는 상위 클래스에 멤버 메소드를 가상(virtual)으로 선언해야 함.

라. 정보은닉(Information Hiding)

구분	상 세 내 용
정의	- 캡슐화 방법으로 class 내부 정보를 은닉하고, 접근 제한의 단계를 두어 보안적인 구현 가능 - 클래스 내부에서 사용되는 변수(필드) 들을 private 이나 protected 등으로 선언해 줌으로, 자기 클래스, 혹은 자식 클래스 외에는 직접적으로 제어를 불가능하게 해주는 성질 - 복잡하거나 변경가능 한 부분을 캡슐 내부에 감추고 외부에는 추상화되고 변경가능성이 낮은 인터페이스만을 제공하는 객체지향의 원리
특징	- 복잡성 제거 : 외부에는 불필요한 내부적으로만 사용되는 부분을 감춰서 복잡성을 줄임 - Data 보호 : 외부로부터 데이터를 보호하기 위함
Code

- 접근제어자의 종류

마. 상속성(Inheritance)

구분	상 세 내 용
정의	- 상속은 클래스에서만 통용되는 개념으로 미리 만들어 둔 클래스를 다시 이용하는 방법
특징	- 하위 클래스가 상위 클래스를 상속 받았을 때, 하위 클래스는 상위 클래스의 모든 권한 소유 - 상속을 받는 순간 현재의 클래스는 곧 상위 클래스에서 출발 - 단일 : 부모와 자식 클래스 간의 관계가 수퍼클래스와 서브클래스로 유지 - 다중 : 하나의 클래스가 하나 이상의 클래스로부터 상속 - 반복 : 같은 조부모 클래스로부터 상속 받은 두 부모 클래스로부터 상속
Code

    - C++에서는 콜론(:)을 상속의 키워드로 사용하며, 자바에서는 extends라는 키워드를 사용

누런 원버튼이 거슬리기도 했고, 화장실에 입실시 자동으로 불이 켜지도록 하기위해 보탬 스위치를 장착을 하려고하였습니다.


그.러.나 구축 아파트여서 그런지 이전 똑딱이 스위치만큼만 콘크리트가 파져있어서, 좀 두께감이 있는 정사이즈의 보탬스위치는 2/3쯤 밖에 들어가지 않았습니다.

- 낙담하던 그때 스위치 박스를 알게되었고, 좀 튀어나오더라도 자동화에 의의를 두고 시공을 진행했습니다.

구매한 스위치박스 뒤에 전선구멍이 나있어서, 그 구멍으로 전선을 뺐습니다.

스위치 박스는 실리콘이나 접착용 실란트를 사용해서 고정하면되는데, 저는 접착용 실란트를 사용해서 테두리만 발라서 고정했습니다.

- 작동 잘됩니다. 툭 튀어나와있지만, 만족스러웠고 벽과 스위치 사이에 깔끔하게 실리콘으로 마무리할 예정입니다.

시공만족도 : 상
시공난이도 : 하
시공시각 : 5분내외
시공비용 : 3000원
준비물 : 무타공 접착제 혹은 실리콘, 스위치 박스



https://link.coupang.com/a/bttihf

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

셀프시공명 : 셀프 도배시트지
셀프시공난이도 : 하
면적 : 122cm x 122cm
시공시간 : 40분
인력 : 혼자가능
비용 : 1.4만원
준비물 : 의자, 헤라(공기 안들어가게 붙일때 필요, 없어서 책받침으로 쭉쭉 밀어줌)

- 현관은 중문과 현관사이에 있어서, 온도를 완충해 주는 구간으로  습기가 도배지에 스며들기 쉽습니다. 5년전 도배가 많이 얼룩덜룩하네요.
( 미리 현관 등은 제거해줍니다 )

- 돌돌 말려온 시트지를 제단해줍니다. 자를때 잘못잘라서 4부분을 이어붙였네요. 이것때문에 시간이 오래걸렸습니다.

- 시공 완료된 모습, 이어 붙인 모습도 그렇게 티 나지 않네요, 혼자서도 충분히 가능해서 해볼만 한거같습니다.

* Tip
1) 천정은 들고있어야 해서 좀 수평을 잡는부분이 힘드니 가장자리 부분을 처음에 잘 맞춰주는게 중요.
2) 밀어줄때 가장자리가 아닌 중앙 부분부터 가장자리로 나아가게 밀어주어야 공기와 울지 않음.

시공만족도 : 상


https://link.coupang.com/a/bts4Gv

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

기출문제

1. 대용량 웹서비스를 위한 Agile Architecture 개요

1. 모노리식 아키텍처, 마이크로 서비스 아키텍처 구성도 및 아키텍쳐 특성

1. 모노리식 아키텍처, 마이크로 서비스 아키텍처 특성

1. 모노리식 아키텍처, 마이크로 서비스 아키텍처 비교

[추가 자료: Agile Architecture 배경적 지식]

1) Agile Architecture 개념

 - S/W 개발 시, 상세함을 대체하면서 결과 verify를 용이하게 할 수 있는 Architecture.

 - Agile Manifesto 에 6원칙에 기초하여 등장하게 됨

2) Microservice 배경

 - Agile이 적용된 조직Organization이 비대 또는, 시스템 Scale이 커지면, Scrum of scrum/SAFe(Scaled Agile Framework) 등 의사소통 채널 및 시스템 Iteration(Sprint) 도 증가. 이는 Agile 사상에 벗어나는 고민에서 출발한 개념 (Microservice를 SOA 개념/등장배경에 견주어 설명하기도 함)

 - 독립적인 적용이 가능한 unit으로 구성된 Microservice-based 시스템일 경우, 기능이 명확히 분리된 단위라서 상호 서비스 영향이 없기 때문에 빠르고 쉽게 적용이 가능, 장점이라고 얘기함

[그림해설] S/W 개발을 예로 들면, Microservices 가 Agile 진행에서 하나의 구조적 단계로 볼 수 있다는 의미

[참고] Agile Working Group 과 MSA

기출문제

I. Scrum의 Sprint 일정관리 도구, 번다운차트 개요.(서론)

- Agile 프로젝트기반 조직에서 점수(Story Point)를 산정하여 Sprint 계획대비 현재진행을 파악할 수 있는 차트

- 스토리포인트(Story Point) 산정, Sprint 진척률 가시화

II. 개념도(구성도) 및 기술요소

가. Burn down(소멸차트) 개념도

- 점수(User Point)를 지정하여 Sprint 기간에 계획대비 완료한 현재의 진행을 가시화

나. Burn down(소멸차트) 상세설명

- 기울기를 통하여 작업수행 속도 판단

- Story Point 산정 및 담당 업무할당에 너무 많은 시간이 소요되면 진척에 역효과 발생. 적절한 이해관계자들간의 범위 및 일정조율 중요.

III. Burn-Down Chart와 EVM의 비교

[참고] EVM과 Burn Down Chart 프로젝트 적용 방안

기출문제

I. SW의 품질개선과 위험 완화를 위한 Agile Practice, CI (Continuous Integration)) 개요

가. CI의 정의

- 개발자 별로 소스코드를 지속적/연속적 통합하여 자동화된 빌드, 테스트 및 배포 기능을 통하여 단기간에

고품질의 SW를 획득하는 기술 (형상관리 필수적용)

나. CI 목적/필요성

II. CI 개념도 및 기술요소

가. CI 개념도

나. CI 기술요소

III. CI의 위험요소와 프렉티스를 성공적 수행하기 위한 자동화 프로세스 Tools

[CD(Continuous Delivery)]

I. SW 개발/운영 통합관리, DevOps를 위한 CD(Continuous Delivery)의 개요

- 변경된 요구사항에 대한 개발/통합/배포/테스트/릴리즈를 자동화함으로써 SW의 개발과 운영을 통합하여 DevOps를 지원하는 소프트웨어 연속적인 배포 출시 전략

II. CI와 CD 관계도

- Commit 한 코드를 CI를 수행하고 CD를 수행하여 지속적인 Deploy를 수행

[추가_2018.08.합숙풀이]

- 발전된 오픈소스를 통해 CI/CD를 넘어서 DevOps 환경 구성가능

기출문제

I. Just in Time 달성 및 낭비제거, Lean의 개요

가. Lean의 정의

 - 빠른 프로토타입과 신속한 고객 피드백을 통해 JIT(Just in Time) 달성과 함께 낭비를 제거하는 개발 방법론

나. Lean의 특징

II. Lean의 7대 원칙과 7대 낭비

1. Lean의 7대 원칙

나. Lean의 7대 낭비

III. Kanban과 Lean의 비교