2. 소프트웨어 개발 https://bit-b-bit.tistory.com/221
3. 데이터베이스 구축 https://bit-b-bit.tistory.com/220
4. 프로그래밍 언어 활용 https://bit-b-bit.tistory.com/218
5. 정보시스템 구축 https://bit-b-bit.tistory.com/217
<요구사항공학>
https://powerdev.tistory.com/36
<GoF 디자인 패턴>
https://itwiki.kr/w/GoF_%EB%94%94%EC%9E%90%EC%9D%B8_%ED%8C%A8%ED%84%B4
디자인 패턴이란?
https://www.devkuma.com/docs/design-pattern/intro-basic/
소프트웨어를 설계할 때 특정 맥락에서 자주 발생하는 고질적인 문제들이 또 발생했을 때 재사용할 할 수 있는 훌륭한 해결책이다.
“바퀴를 다시 발명하지 마라(Don’t reinvent the wheel)” 이미 만들어져서 잘 되는 것을 처음부터 다시 만들 필요가 없다는 의미이다.
패턴이란?
- 각기 다른 소프트웨어 모듈이나 기능을 가진 다양한 응용 소프트웨어 시스템들을 개발할 때도 서로 간에 공통되는 설계 문제가 존재하며 이를 처리하는 해결책 사이에도 공통점이 있다. 이러한 유사점을 패턴이라 한다.
- 패턴은 공통의 언어를 만들어주며 팀원 사이의 의사 소통을 원활하게 해주는 아주 중요한 역할을 한다.
디자인 패턴의 종류
이미 알려진 디자인 패턴은 다음과 같이 23개로 나누어져 있다. 크게 생성(Creational), 구조(Structural), 행위(Behavioral) 3가지로 분류된다. 이는 GoF(Gang of Four) 디자인 패턴이라고 불리며, 에리히 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vissides) 4명의 유명한 개발자들에 의해 고안되었다. 4명의 개발자는 ‘경험’이나 ‘내적인 축적’을 <디자인 패턴>이라는 형태로 정리하였다. 이 4명을 the Gang of Four 또는 GoF라고 부른다.
생성 패턴 (Creational Pattern)
객체 생성에 관련된 패턴으로, 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.
- 추상 팩토리 메서드 (Abstract Factory Methods) : 관련된 부품을 조립해서 제품을 만든다.
인터페이스를 이용하여 서로 연관된 객체를 구상클래스를 지정하지 않고도 생성
- 팩토리 메서드 (Factory Methods) : 인스턴스 작성을 하위 클래스에게 맡긴다.
객체 생성을 직접하지 않고, 팩토리라는 클래스에 위임하여 팩토리 클래스가 객체를 생성하도록 하는 방식이며 객체를 만들어 반환하는 함수를 생성자 대신 제공하여 초기화 과정을 외부에서 보지 못하게 숨기고 반환 타입을 제어하는 방법
- 빌더 (Builder) : 잡한 인스턴스를 조립한다.
- 프로토타입 (Prototype) : 복사해서 인스턴스를 만든다.
- 싱글톤 (Singleton) : 단 하나의 인스턴스.
구조 패턴 (Structural Pattern)
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴으로 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.
- 어댑터 (Adapter) : 한 꺼풀 덧씌워 재사용.
- 브리지 (Bridge) : 기능의 계층과 구현의 계층을 분리한다.
- 컴퍼지트 (Composite) : 그릇과 내용물의 동일시.
- 데코레이터 (Decorator) : 장식과 내용물의 동일시.
- 퍼사드 (Facade) : 간단한 창구.
- 플라이웨이트 (Flyweight) : 동일한 것을 공유해서 낭비를 없앤다.
- 프록시 (Proxy) : 필요해지면 만든다.
행위 패턴 (Behavioral Pattern)
객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴으로, 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.
- 책임 연쇄 (Chain of Responsibility) : 책임 떠넘기기.
- 커맨드 (Command) : 명령을 클래스로 만든다.
- 인터프리터 (Interpreter) : 문법 규칙을 클래스로 표현한다.
- 이터레이터 (Iterator) : 하나씩 세다.
- 미디에이터 (Mediator) : 상대는 카운셀러 한사람뿐.
- 메멘토 (Memento) : 상태를 보존한다.
- 옵저버 (Observer) : 상태의 변화를 통지한다.
- 스테이트 (State) : 상태를 클래스로서 표현한다.
- 스트레티지 (Strategy) : 알고리즘을 모두 교체한다.
- 템플릿 메서드 (Template Meothods) : 체적인 처리를 하위 클래스에게 맡긴다.
- 비지터 (Visitor) : 구조 안을 돌아다니면서 일을 한다.
<어플리케이션 설계- 시스템 구조도>
릴리즈노트
https://m.blog.naver.com/hann726/222026606910
RAD
애자일 방법론의 한 유형인 RAD는 실시간으로 결과를 제시하며 제품을 신속하게 제공하고 필요에 따라 기능을 업데이트하는 경우에 효과적으로 작동합니다. 속도를 중요하게 여기지만 특정 기간을 기준으로 삼지는 않습니다. RAD 프로세스의 특징은 프로세스 중심으로 진행하면서 프로토타입 테스트와 신속한 변경에 초점을 맞추어 단시간 내에 균형 잡힌 제품을 제공한다는 것입니다.
RAD와 애자일 방식은 서로 유사한 단계도 있고 차이점도 있습니다. RAD가 프로토타입에 초점을 맞추는 반면, 애자일은 프로젝트를 기능으로 분할하여 개발 주기 동안 다양한 스프린트를 제공하는 것을 목표로 합니다.
**프로토타입(prototype)은 원래의 형태 또는 전형적인 예, 기초 또는 표준이다. 시제품이 나오기 전의 제품의 원형으로 개발 검증과 양산 검증을 거쳐야 시제품이 될 수 있다. 프로토타입은 '정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델'이다.
<소프트웨어 아키텍처 원리>
소프트웨어 아키텍처 설계의 기본 원리에는 모듈화, 추상화, 단계적 분해, 정보은닉이 있습니다.
- 모듈화 : 소프트웨어 성능 향상 및 유지관리 등이 용이하도록 시스템의 기능을 모듈단위로 나누는 것
- 추상화 : 전체적이고 포괄적인 개념을 설계한 후에 구체화시켜 나가는 것
- 단계적 분해 : 상위 개념부터 하위 개념으로 구체화 시키는 분할 기법 하향식 설계 전략
- 정보은닉 : 모듈 내부에 정보와 자료들을 숨겨서 다른 모듈이 접근하거나 수정 못하도록 하는 기법
<아키텍처 설계과정>
설계 목표 설정 > 시스템 타입 결정 > 스타일 적용 및 커스터마이즈 > 서브시스템의 기능, 인터페이스 동작 작성
> 아키텍쳐 설계 검토
상속- 기존의 클래스를 재활용하여 새로운 클래스를 작성
다형성- 어떤 객체의 속성이나 기능이 상황에 따라 여러 가지 형태를 가질 수 있는 성질
캡슐화- 속성과 메소드를 하나로 묶어서 객체로 구성된다.
추상화- 공통성질을 추출하여 수퍼클래스로 구성한다.
집단화 - is part of 클래스A는 클래스 B와 클래스 C로 구성된다.
일반화 - is a 자식클래스A는 부모클래스B의 일종이다.
**메서드 오버로딩 - 하나의 클래스 내에서 같은 이름의 메서드를 여러 개 중복하여 정의하는 것을 의미
메서드 오버라이딩- 각각의 클래스의 맥락에 맞게 재정의하여 사용.같은 이름의 메서드가 상황에 따라 다른 역할을 수행
객체지향 분석 방법론
- Coad와 Yourdon 방법 : E-R다이어그램 사용 객체 행위 모델링 및 객체 구조 식별 및 주체 속성 및 관계 서비스 정의
- Booch 방법 : 클래스와 객체 식별 및 의미 관계 식별, 미시적개발/거시적 개발프로세스 모두 사용
- Rumbaugh : 소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델링 (OMT object modeling technique)
(객체 모델링 Object Modeling, 동적모델링 Dynamic , 기능 모델링 Function )
- Jacobson : Use Case사용
- Wirfs-Brock :분석과 설계간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행
UML
https://seulhee030.tistory.com/56
https://hyun-am-coding.tistory.com/entry/Chapter-14-UML-%EB%AA%A8%EB%8D%B8%EB%A7%81
- 구조 :클래스, 객체, 패키지, 컴포넌트, 배치
- 행위: 유스케이스, 활동, 상태, 순서(순차),커뮤니케이션(메시지 및 객체간 관계)
UML 관계 https://itproda.tistory.com/101
UseCase https://googry.tistory.com/2
연관 (액터와 상호작용,기능)
의존 ( 포함(반드시), 확장(특별한조건))
일반화 (추상화)
<요구사항 명세기법>
<객체지향 설계원칙>
SOLID 원칙
객체지향 설계5대 원칙이라 부르는데 SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙), LSP(리스코프 치환 원칙), ISP(인터페이스 분리 원칙), DIP(의존 역전 원칙)을 말하고 앞자를 따서 SOILD 원칙이라고 부른다.
1. 단일 책임 원칙 (Single Responsiblity Principle)
모든 클래스는 각각 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 함을 말한다.
- 사칙연산 함수를 가지고 있는 계산 클래스가 있다고 치자. 이 상태의 계산 클래스는 오직 사칙연산 기능만을 책임진다. 이 클래스를 수정한다고 한다면 그 이유는 사직연산 함수와 관련된 문제일 뿐이다.
2. 개방-폐쇄 원칙 (Open Closed Principle)
확장에는 열려있고 수정에는 닫혀있는. 기존의 코드를 변경하지 않으면서( Closed), 기능을 추가할 수 있도록(Open) 설계가 되어야 한다는 원칙을 말한다.
- 캐릭터를 하나 생성한다고 할때, 각각의 캐릭터가 움직임이 다를 경우 움직임의 패턴 구현을 하위 클래스에 맡긴다면 캐릭터 클래스의 수정은 필요가없고(Closed) 움직임의 패턴만 재정의 하면 된다.(Open)
3. 리스코프 치환 원칙 (Liskov Substitution Principle)
자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있다는 원칙이다. 즉 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 잘 작동해야 한다.
자식클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 LSP를 만족한다.
4. 인터페이스 분리 원칙 (Interface Segregation Principle)
한 클래스는 자신이 사용하지않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다 여러개의 구체적인 인터페이스가 낫다.
5. 의존 역전 원칙 (Dependency Inversion Principle)
의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것이다. 한마디로 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺으라는 것이다.
구분
- CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이루어지는 인터페이스
- GUI(Graphic User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 인터페이스
- NUI(Natural User Interface) : 말이나 행동으로 조작하는 인터페이스
기본 원칙
- 직관성: 누구나 쉽게 이해하고 사용할 수 있어야 한다.
- 유효성: 사용자의 목적을 정확하게 달성하여야 한다.
- 학습성: 누구나 쉽게 배우고 익힐 수 있어야 한다.
- 유연성: 사용자의 요구사항을 최대한 수용하며, 오류를 최소화하여야 한다.
UI 설계
설계 지침
- 사용자 중심
- 일관성
- 단순성
- 결과 예측 가능
- 가시성
- 표준화
- 접근성
- 명확성
- 오류 발생 해결
UI 설계 도구
- 와이어프레임
- 기획 초기 단계에서 제작하는 것으로 페이지에 대한 대략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계
- 관련 도구 : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등
- 목업
- 와이어프레임보다 좀 더 실제 화면과 유사하게 만드는 정적인 형태의 모형
- 관련 도구 : 파워 목업, 발사믹 목업 등
- 스토리보드
- 와이어프레임에 콘텐츠에 대한 설명이나 페이지 간 이동 흐름 등을 추가한 문서
- 디자이너와 개발자가 최종적으로 참고하는 작업 지침서
- 서비스 구축을 위한 모든 정보가 담겨 있어야 함
- 관련 도구 : 파워포인트, 키노트, 스케치, Axure 등
- 프로토타입
- 와이어프레임이나 스토리보드 등에 인터랙션을 적용해 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
- 작성 방법에 따라 페이퍼/디지털 프로토타입으로 나눔
- 관련 도구 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등
- 유스케이스
- 사용자 측면에서의 요구사항으로 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술하는 표준 방법
- 관련 도구: UML 다이어그램
UX와의 차이
UX는 사용자의 경험을 기반으로 사용자의 편의성과 몰입도를 높이는 관점
- UI의 주요 평가항목: 사용성/접근성/편의성
- UX의 주요 평가항목: 몰입도/만족도/재접근률
<리팩토링>
- 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 개선함
- 결과의 변경없이 코드의 구조를 재조정하는 것으로 가독성을 높이고, 유지보수를 쉽게하기 위한 목적
- 코드의 외부 행위는 바꾸지 않고 내부 구조를 개선시켜 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 만드는 것
'공부 > 정보처리기사' 카테고리의 다른 글
| 2023 정보처리기사 - 소프트웨어 개발 (2과목) (0) | 2023.02.06 |
|---|---|
| 2023 정보처리기사 - 데이터베이스 구축(3과목) (0) | 2023.02.06 |
| 2023 정보처리기사 -프로그래밍 언어 활용 (0) | 2023.02.05 |
| 2023 정보처리기사 -정보시스템 구축관리(5과목) (0) | 2023.02.04 |
