1. 요구사항 확인

플랫폼

현행 시스템 파악 3단계

오픈 API

요구사항 도출 기법

인터뷰, 관찰, 프로토타입, 벤치마킹, 사용자 스토리텔링

요구사항 프로세스 타,도,분,명,확

HIPO

CASE

요구사항 검증방법

워크스루, 동료검토, 인스펙션

기능적 요구사항, 비기능적 요구사항

객체지향 프로그래밍

객체지향 특징

캡슐화, 추상화, 다형성, 정보은닉, 상속성

자료 흐름도

프로세스(Process): 자료의 처리/변환 과정을 표현한다.

자료흐름(Data flow): 자료의 흐름을 표현한다.

자료저장소(Data store): 파일, 데이터 베이스 등 저장소의 위치를 표현한다.

단말(Terminator): 자료의 출처와 도착지를 표현한다.

자료사전(DD: Data Dictionary)

자료 흐름도의 대상이 되는 모든 자료에 대한 기본사항들을 더 자세히 정의하기 위해 사용되는 도구, 메타데이터라고도 부름.

자료 사전 작성 규칙

= 자료의 정의

• 자료의 연결

() 자료의 생략

[ | ] 자료의 선택 (A 이거나 B)

{} 자료의 반복

** 자료의 설명

클라우드 컴퓨팅

네트워크를 통해 가상화된 컴퓨터의 시스템 리소스를 요구하는 즉시 서비스 형태로 제공하는 방식으로 제공방식에 따라 IaaS, PaaS, SaaS로 구분.

럼바우(Rumbaugh) 방법의 활동단계

객체지향 분석방법론중 하나

객체모델링 - 동적모델링 - 기능모델링 (객-동-기)

객체 모델링 : 정보모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산식별 및 객체들 간의 관계를 규정

동적 모델링 : 상태 다이어그램을 사용하여 시스템의 행위를 기술하는 모델링

기능 모델링 : 자료 흐름도(DFD)를 이용, 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현.

UML(Unified Modeling Language)

객체 지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 때 사용하는 모델링 기술과 방법론을 통합하여 만든 표준화된 범용 모델링 언어.

UML 구성요소

View, Diagram, Model Element, General Mechanism.

UML 관계의 종류

의존관계: 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때

연관관계: 클래스들이 개념상 서로 연결됐음을 나타냄

일반화관계: 객체지향 개념에서 상속관계라고도 함.

실체화관계: 책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계

집합관계: 클래스들 사이의 전체 또는 부분 같은 관계를 나타냄, 전체 객체의 라이프타임과 부분 객체의 라이프 타임은 독립적이라 전체 객체가 사라져도 부분 객체는 남아있음. (new를 하지 않음)

합성관계: 클래스들 사이의 전체 또는 부분 같은 관계를 나타냄. 전체 객체의 라이프 타임과 부분 객체의 라이프 타임은 의존적이라 전체 객체가 사라지면 부분 객체도 같이 사라짐. (new로 생성함)

UML Diagram 종류

구조적 다이어그램: 시스템의 정적 구조(Static Structure)와 다양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계를 보여줍니다. ex) Class, Object, Component, Deployment

행위 다이어그램: 시스템 내의 객체들의 동적인 행위를 보여주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해 줍니다. ex) Use Case, State, Activity

상호작용 다이어그램 ex) Sequence, Communication

유즈케이스 다이어그램

시스템이 제공하는 기능과 서비스 및 관련된 외부 요소를 사용자 관점에서 표현하는 UML 다이어그램

구성요소: 액터(Actor), 유즈케이스(Use case), 관계(Relation)

애자일(Agile) 개발 프로세스

종류: XP(5가치 12가지 실천항목), SCRUM(30일 마다 스프린트, 백로그), Lean(7가지 원칙)

스크럼(Scrum)

작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어를 산출하는 대표적인 Agile 개발 방법론.

프로덕트 백로그 → 스프린트 백로그 → 계속 스프린트 반복

프로덕트 백로그(Product Backlog) : 구현할 제품의 기능과 특성, 요구사항의 우선순위 등을 나열한 리스트

스프린트 백로그(Sprint Backlog) : 해당 반복 개발기간 동안 수행해야할 Task들이다.

요구사항 추적 매트릭스(RTM: Requirement Traceability Matrix)

요구사항 추적 매트릭스는 최종 인도물에 요구사항이 반영되기까지의 프로젝트 생애주기 전 과정을 추적하는 도표(grid)입니다.

시퀀스 다이어그램(Sequence Diagram)

표현할 객체를 액터 또는 활성객체로 정의하고 객체 간의 의사소통을 메세지로 상호작용을 표현합니다.

액티비티 다이어그램(Activity Diagram)

시스템 내부에 있는 객체의 활동 간의 처리흐름을 모델링하는 범용적인 다이어그램.

사건 발생에 따른 객체들 간의 행위에 대한 상호관계를 표현.

객체지향 기법에서 접근 제한자

• • : Private → 해당 클래스 내에서만 접근 가능

• : Protected → 동일 패키지 내에서만 접근 가능

• • : Public → 어디서든 접근 가능

UML 스테레오타입(streotype)

UML 표현기능을 강화하기 위해 클래스나 관계를 나타내기 위한 확장 매커니즘.

예시

• 포함: <<include>> 유즈 케이스를 실행하기 위해 반드시 포함해서 실행되어야 하는 유즈케이스를 표현
• 확정: <<extend>> 기본 유즈 케이스 수행 시 특정 조건을 만족 할 때 수행하는 유즈 케이스 표현
• 경계: <<boundary>> 시스템과 외부 액터와의 상호작용을 담당하는 클래스 표현
• 엔티티: <<entity>> 시스템이 유지해야 하는 정보를 관리하는 기능을 전담하는 클래스 표현
• 제어: <<control>> 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스 표현

유즈케이스 분석 클래스

• 엔티티 클래스 : 시스템이 유지해야하는 정보를 관리하는 기능을 전담하는 클래스
• 경계 클래스 : 주로 시스템 외부의 액터와 상호작용하는 클래스로 사용자 인터페이스를 제어하는 역할
• 제어 클래스 : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

애자일 방법론 정의

애자일 방법론은 고객의 요구사항 변화에 유연하게 대응하기 위해 일정한 주기를 반복하면서 개발하는 방법론이다.

린(Lean) 개발방법론

애자일 방법론 중에 하나이며 개발 프로세스에 적용하여 프로세스의 낭비요소를 제거 후 결과를 측정, 성과를 분석하여 소프트웨어의 품질을 향상시키는 개발방법론이다.

칸반(Kanban)

Workflow를 가시화하고 작업 중인 항목의 제한 및 작업 소요시간을 측정할 수 있는 작업 지시서를 SW 개발에 적용한 애자일 방법론이다.

요구 공학 개발 절차

타당성 조사 → 도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인/검증(Validation/Verification)

기능적 요구사항

시스템에서 제공되어야 할 특정 기능을 정의한다.

비 기능적 요구사항

시스템의 전체적인 품질이나 기능적 요구사항을 구현시 고려해야하는 제약사항을 정의한다.

요구공학

요구 분석 단계에서 행해졌던 요구사항 분석 및 서술뿐 아니라 이들의 추출, 관리, 검증, 유지 등을 포함하여 요구사항에 관계되는 모든 활동과 원칙들에 대한 공학적인 접근방법이다.

요구사항 관리프로세스

요구사항 관리 절차

• 요구사항 협상 - 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법.
• 요구사항 기준선 - 공식적으로 검토되고 합의된 요구사항 명세서.
• 요구사항 변경관리 - 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법.
• 요구사항 확인 - 구축된 시스템이 이해관계자가 기대한 요구사항에 부합되는지 확인하기 위한 방법.

협상 - 기준선 - 변경관리 - 확인

구조적 다이어그램의 종류

• Class - 시스템 내 클래스들의 정적 구조를 표현
• Object - 클래스의 여러 객체 인스턴스를 나타내는 대신 실제 클래스를 사용
• Deployment - 시스템 하드웨어와 소프트웨어 간의 물리적 구조를 표현하며, 실질적인 컴퓨터와 디바이스 간의 관계를 표현하는데 이용
• Component - 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보를 포함하고, 실질적인 프로그래밍 작업에 사용함.

유즈케이스 다이어그램(Use Case Diagram)

시스템이 제공하고 있는 기능 및 그와 연관된 외부요소를 사용자의 관점에서 표현하는 UML 다이어그램.

객체지향 소프트웨어 설계원칙

• 단일 책임 원칙 - 객체는 단 하나의 책임만을 가져야함.
• 개방 폐쇄 원칙 - 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 함.
• 리스코프 치환의 원칙 - 일반화 관계에 대한 것으로 자식 클래스는 최소한 자신의 부모클래스에서 가능한 행위는 수행할 수 있어야 함.
• 인터페이스 분리의 원칙 - 인터페이스를 클라이언트에 특화되도록 분리하라는 설계 원칙
• 의존성 역전의 원칙 - 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어렵거나 거의 변화가 없는 것에 의존하라는 것임.

객체지향의 설계원칙은 SOLID

SRP, OCP, LSP, ISP, DIP

공통 모듈 작성 원칙

정확성, 명확성, 완전성, 일관성, 추적성

모듈화

소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 용이하게 하여 프로그램을 효율적으로 관리할 수 있도록 시스템을 분해하고 추상화하는 기법을 의미한다.

모듈 독립성 판단 지표 : 응집도, 결합도

응집도는 내부의 구성 요소간 관계의 밀접 정도로 평가

결합도는 어떤 모듈이 다른 모듈에 의존하는 정도를 척도로 독립적인 모듈이 되기 위해서 결합도가 낮아야한다.

결합도

품질 측면에서 가장 높은 품질은 자료 결합이며, 내용 결합이 가장 낮다.

유형

• 자료 결합도 - 모듈간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어난다.
• 스탬프 결합도 - 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우
• 제어 결합도 - 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우
• 외부 결합도 - 모듈에서 외부로 선언한 데이터를 다른 모듈에서 참조할 때의 경우
• 공통 결합도 - 파마리터가 아닌 모듈 밖에 선언되어있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호작용하는 경우
• 내용 결합도 - 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우.

품질 : 자료 > 스탬프 > 제어 > 외부 > 공통 > 내용

응집도

품질 측면에서 가장 낮은 품질은 우연적 응집도이며

기능적 > 순차적 > 통신적 > 절차적 > 시간적 > 논리적 > 우연적 순으로 높다. (응집도 순서는 반대)

유형

• 기능적 응집도 - 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우
• 순차적 응집도 - 모듈 내에서 한 활동으로부터 나온 출력 값을 다른 활동이 사용하는 경우
• 통신적 응집도 - 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우
• 절차적 응집도 - 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우
• 시간적 응집도 - 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
• 논리적 응집도 - 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
• 우연적 응집도 - 모듈 내부의 각 구성 요소들이 연관이 없을 경우.

우논시절통순기

소프트웨어 설계 모델 유형

• 구조 모델링 - 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 및 이들의 상호 연결 구조를 모델링한다.
• 행위 모델링 - 소프트웨어의 구성요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용 하는지를 모델링한다.

아키텍처 패턴

반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션.

SW 아키텍처 4+1 View

사용사례관점, 논리관점, 구현관점, 프로세스관점, 배치관점