모듈화 설계에서 결합도(coupling)를 가장 낮게, 응집도(cohesion)를 가장 높게 가져가야 하는 이유를 "영향 범위" 관점에서 한 문장으로 서술하시오.
응집도를 높여 변경 시 영향 범위를 해당 모듈 내로 한정하고, 결합도를 낮춰 그 영향이 시스템 전체로 확산되는 것을 최소화하기 위해서이다.
공유 결합력(Common Coupling)은 2개의 모듈이 광역 변수(Global Variable)를 공유할 때 발생한다. 공유 변수의 사용은 메모리 사용량을 줄이는 장점이 있지만, 모듈의 독립성을 보장하기 위해 주의해야 할 가장 큰 문제점은 무엇인지 서술하시오.
모듈 간의 의존성을 높이는 문제 발생
응집력(Cohesion)은 모듈을 구성하는 내적 요소 간의 기능적 관련성 강도를 측정하는 척도
교환 응집력은 모듈을 구성하는 모든 요소가 동일한 입력 또는 출력을 사용함
외부 결합력(External Coupling) 관계에서 2개의 모듈이 외부에 존재하는 파일, 디바이스 인터페이스, 프로토콜 등의 정보를 공유할 때, 다른 모듈의 변수 변경이나 동시 접근으로 인해 발생할 수 있는 대표적인 문제점： 데드락
내용 결합력(Content Coupling)은 한 모듈이 다른 모듈의 내부를 직접 참조하여 발생하는 가장 나쁜 형태의 결합력입니다. 현재는 거의 발생하지 않지만, 기존의 절차적 언어에서 내용 결합을 유발하는 대표적인 명령어를 영어로 서술하시오.
goto
기능 응집력(Functional Cohesion)의 예시
- 수학의 코사인각 계산
- 승객의 좌석 배치
- 미사일 타격 지점 계산
- 문장의 알파벳 오류 체크
순차 응집력이 서로 입출력 관계에 있는 문장으로 구성되었다 하더라도 마지막 문장이 기능 응집력을 충족하지 못한다면 응집력의 효과는 저하됩니다. 따라서 모든 문장이 기능 응집력을 만족하도록 정의하는 것이 중요합니다.
절차 응집력(Procedural Cohesion)은 모듈을 구성하는 문장들이 의미상 서로 관련이 없지만 제어 흐름의 순서가 있는 경우에 발생한다.
스탬프 결합력(Stamp Coupling)은 구조체와 같은 복합 데이터를 이용해 상호작용하지만, 호출 모듈이 구조체의 모든 멤버 정보를 사용하지 않을 경우 불필요한 데이터까지 모두 전달하게 됩니다. 이로 인해 발생하는 주요 손실 측면 두 가지를 서술하시오.
실행 시간과 메모리 사용 측면에서 손실
구조 모델링의 대표적인 결과물: 클래스 다이어그램
시스템을 구성하는 클래스들과 그들 간의 관계(연관, 일반화, 집합 등)를 보여주는 정적인 구조 다이어그램
일반화 관계(상속)에서의 관계는 kind of (추상 클래스 - 구체 클래스)
집합 관계에서는 part of (전체(집합체 클래스) - 부분(구성 클래스))
UML 다이어그램: 설계 단계로 넘어가기 전, 분석 과정에서 생성된 기능 모델, 구조 모델, 행위 모델 등의 산출물들이 서로 모순되지 않고 일관되게 정의되었는지 확인하는 작업
- 기능 모델의 유스 케이스 설명서에 나타난 모든 클래스 이름은 반드시 CRC 카드나 클래스 다이어그램에 정의되어야 합니다.
- 기능 모델의 각 유스 케이스는 각각 하나의 순차 다이어그램으로 표현되어야 합니다.
- 유스 케이스 다이어그램의 액터(Actor)는 순차 다이어그램의 액터로 나타나야 합니다.
CRC 카드의 전면부에는 Type, Associated Use Cases, Responsibilities, Collaborators가 명세됩니다. Attributes(속성)와 Operations(연산)는 CRC 카드의 뒷면에 정의됩니다.
구조 모델링이 설계 단계에서 사용될 때, 비즈니스에서 사용되는 용어들을 이용하여 객체들을 정의함으로써 달성하고자 하는 주요 목표: 실세계와 소프트웨어의 의미적 차이를 줄이는 작업
기능 모델(유스 케이스 설명서)과 구조 모델(CRC 카드) 간의 일관성 점검 대상 중 하나는 모든 클래스의 이름이 유스 케이스 설명서의 어딘가에 반드시 나타나야 한다.
브레인스토밍의 유의할 점: 기능 모델의 산출물(ex. 유스 케이스 설명서)을 사전에 검토하지 않아야 함. 선입견 없이 누락된 객체를 식별하기 위함.
클래스 심볼에서 추상 클래스는 이탤릭체로, 인터페이스 클래스는 <<interface>>로 표현함
클래스 다이어그램에 표현되는 추가 정보 중 관계 기수성(Multiplicity) 0..5가 의미하는 바를 서술하시오. (예시: Employee 1 — 0..5 Family_Member)
서로 연관을 맺은 두 클래스 간에 발생할 수 있는 객체의 인스턴스 수가 최소 0개에서 최대 5개임을 나타낸다.
의존 관계는 한 메소드가 실행하는 동안 등의 짧은 시간 동안만 존재하며, 연관 관계는 지속적인 기능 사용을 나타낸다.
클래스 다이어그램에 메소드를 명시할 때는 시퀀스 다이어그램의 메시지를 기반으로 하며, 메시지를 받은 객체의 클래스에 해당 메시지를 처리하는 메소드를 명시해야 한다.
클래스 다이어그램 관계 중, 클래스들 간에 전체와 부분의 관계이면서 부분 객체가 전체 객체 없이는 존재할 수 없는 필수 불가결한 관계는 합성(Composition), 단순히 전체와 부분의 관계는 집합(Aggregation)으로 나타낸다.
사용성 요소의 우선순위 피라미드는 하위부터 '효과적', '사용하기 쉬움', '즐거움'의 순서로 구성되어 있습니다.
설계(Design): 도메인 중심의 요구사항 분석 결과를 소프트웨어 관점의 산출물로 전환하는 과정
단순성: 유지보수성에 영향 simple is the best
효율성: 사용하는 자원이 적정하고 효과적이도록
분할/계층화: 다루기 쉬운 덩어리로 분리하여 계층화 - 정보 은닉
추상화: 사물의 대표적 특성에 집중하여 대상물을 나타냄 - 관심사의 분할
모듈화: 고응저결, 문제를 sw 구성 요소 수준으로 분리
추상화: 사물의 대표적 특징에 집중하여 대상물을 나타내는 것. 시스템의 핵심 특성에 초점을 두어 큰 시스템을 분할하는 원리.
모듈화: 고응저결, 문제를 소프트웨어 구성 요소(패키지 또는 클래스) 수준으로 분할하는 과정. 재사용 가능성과 사용 용이성 간의 균형이 중요
캡슐화 (Encapsulation): 분할된 핵심 정보만을 외부에 노출시키고, 내부 구현을 숨기는 정보 은닉 (Information Hiding) 개념.
모듈화 - 크게 쪼개진 모듈은 사용 용이성이 높고, 잘게 쪼개진 모듈은 재사용 가능성이 높다.
클래서 다이어그램: 시스템을 구성하는 클래스, 속성, 연산 및 클래스 간의 정적이고 상세한 논리적 관계(일반화, 연관, 집합 등)를 정의
패키지 다이어그램: 시스템의 클래스들을 관련성 및 응집도에 따라 논리적인 그룹(패키지 또는 서브시스템)으로 묶어 상위 수준의 구조를 표현하고, 패키지 간의 의존 관계를 보여줌
배치 다이어그램: 시스템의 논리적 구성 요소(패키지 또는 클래스)를 실제로 운영될 물리적 환경(하드웨어 플랫폼, 노드)에 할당(Deployment)하고, 이 노드들 간의 통신 경로를 정의함
프로토타입을 단시간에 개발하고자 할 때, 본 시스템을 개발하는 과정에서 코드 구조를 개선하기 위해 리팩토링 적용 가능
캡슐화, 독립적
오픈소스 기반 개발의 베스트 프랙티스 중 '투명성(Transparency)'을 도입하기 위해 활용할 수 있는 세 가지 요소를 제시하시오.
오픈소스 코드 트리, 버그 추적 데이터베이스, 메일링 리스트
완벽한 테스트는 불가능하며, 현실적인 테스트를 위해 입력 데이터의 샘플을 적절히 선택해야 한다.
화이트박스 코드를 실제로 실행하지 않고 구현된 코드의 구조만 고려하여 테스트 케이스를 생성하는 방법 (구조적 테스트)
화이트박스 테스트를 수행하려면 제어 흐름 그래프를 먼저 작성해야 합니다. (Flow 차트) - 소스 코드를 입력으로 하여 코드의 실행 시작부터 종료 지점까지의 제어 흐름을 플로우 차트()로 표현한 것
검증 (Verification): "제품을 올바르게 구축하고 있는가?" (Are we building the product right?) - V 모델의 왼쪽 하강 단계
확인 (Validation): "올바른 제품을 만들고 있는가?" (Are we building the right product?) - V 모델의 오른쪽 상승 단계
사분설구 - 인시통단
사랑해 분수야 설구가 - 인시가 통단햇다
사용자 요구사항, 분석, 설계, 구현 - 인수 테스트(데모), 시스템 테스트(실제 운영될 환경(하드웨어 포함)에서 테스트), 통합 테스트 (단위 테스트가 완료된 모듈을 통합하여 테스트) , 단위 테스트(단위 중심 테스트)
회귀 테스트: 소프트웨어에 결함을 수정하거나 기능을 개선하여 코드가 변경된 후, 이 변경이 기존에 잘 작동하던 부분에 새로운 오류를 발생시키지는 않았는지 확인하기 위해 수행하는 테스트
테스트 지원 프로그램
- 상위 모듈 역할은 테스트 트라이버, 하위 모듈 역할은 테스트 스텁
경로 기반 테스트 케이스 생성 시, 커버리지 고려해야 함
- 문장 커버리지: 코드를 구성하는 모든 문장을 최소 한 번씩 거쳐 가도록 Path 선택
- 분기 커버리지: 모든 분기를 최소 한 번씩 거쳐가도록 Path 선택
- if 문의 경우 참(True)과 거짓(False)의 두 경로가 각각 한 번씩 선정되어야 합니다.
- switch 문에서는 모든 case 문과 default 문이 선정되어야 합니다.
- for 문이나 while 문에서는 적어도 한 번 루프의 내부가 실행되어야 합니다.
- 데이터 흐름 커버리지: 소스 코드에 나타나는 변수 선언(Definition, D)과 변수 사용(Use, U)에 의존하여 테스트 데이터를 선정하는 방법
- : 노드에서 변수 가 선언되거나 값이 할당됨.
- USE={i}: 노드에서 변수 의 값이 사용됨.
데이터 흐름 커버리지 결정 기준
All-Defs: 선언된 모든 변수를 적어도 한 번 사용하는 경로까지 테스트.
All-Uses: 선언된 하나의 변수를 사용하는 모든 지점까지 테스트.
All-Du: 선언된 모든 변수를 사용하는 모든 지점까지 커버.
- 조건 커버리지: 조건문에 대하여 모든 가능한 결과(True/False)가 적어도 한 번씩 나타날 수 있도록 데이터 케이스를 준비하는 방법
- 다수 조건 분기 커버리지: 조건식을 판단하기 위한 모든 조건에 대하여 최소한 한 번씩 참과 거짓이 고려되어야 하며, 각 조건이 전체 진리 값의 결정에 영향을 미친다는 것(Independent Influence)을 보여야 함
블랙박스 테스트: 소프트웨어의 내부 구조(소스 코드)나 작동 원리를 알지 못하는 상태에서, 오직 외부에서 보이는 기능(Functionality)과 요구사항 명세만을 기반으로 시스템의 동작과 성능을 검사 - 기능적 테스트
=> 소프트웨어가 사용자의 관점에서 '무엇을 해야 하는가?'
동치 분할: 입력 데이터의 도메인을 동치 클래스로 분할 -> 각 클래스에서 대표 값 선정하여 테스트 케이스로 사용
경계치 커버리지: 경계값에서 오류 빈번히 발생 - 그래서 경계값을 테스트 입력 값으로 사용 - min-1, min, min+1, max-1, max, max+1
(위 둘은 보완 관계)
특수치 커버리지: 특정 변수를 중심으로 테스트 케이스 선정 - 특수한 함수, 특별한 의미를 갖는 값(0, null 등)
의사결정 테이블은 '조건(Condition)'과 '액션(Action)'으로 구성되며, 각 컬럼은 하나의 독립적인 테스트 케이스를 의미함
원인에 따른 결과 식별
시나리오 기반 테스트
테스트 시나리오 생성 방법:
- 아웃라인 방법 (Outline Method): 기능의 연계성을 고려하여, 사용자가 시스템 사용을 시작하는 입력으로부터 서비스 종료까지의 순차적인 과정을 식별하여 시나리오를 구성합니다. (사용자 입력에 따른 순차적인 흐름)
- 유스케이스 방법 (Use Case Method): 시스템의 액터(사용자)를 중심으로, 분석 단계의 산출물인 유스케이스 설명서(Success scenario, Extensions)에서 사용 사례를 얻어 시나리오를 생성합니다.
DevOps에서 발생하는 기술 부채
- 개발 팀이 소프트웨어 개발 과정에서 내린 차선책(suboptimal decision) 결정으로 인해 발생.
- 해결: 기술 부채를 해결하려는 팀의 동기부여, 마이크로서비스 모델 채택, API 중심 모델 구축
DevOps: 개발(Development)과 운영(Operations) 팀이 상호 협력하여 소프트웨어 시스템을 개발하고 배포함 - 사일로 타파
린(Lean) 및 애자일(Agile) 원칙에 기반함
린: 낭비 요소를 제거하여 사회에 더 많은 혜택을 제공
- 낭비 제거, 학습 확대, 늦게 결정, 빠른 배포, 팀에 권한 위임, 통합 체계, 전체 최적화
- 크게 생각하고, 작게 행동하고, 빨리 실패하고, 빠르게 배워라.
애자일: 신속하게 소프트웨어 모듈을 개발하고 사용자에게 배포하는 것이 목표
객체지향 설계에서 분석 모델을 설계 모델로 변환할 때 사용하는 계층화 기법을 설명하고, 이 기법이 만들어내는 대표적인 아키텍처를 쓰시오.
계층화 기법: 시스템을 역할과 책임에 따라 여러 계층으로 분리 -> 분석 모델을 구조화된 설계 모델로 변환하는 방법
3-Tier(계층) 아키텍처 HCI, PD, DM
패키지 다이어그램이 설계에서 필요한 이유를 한 줄로 설명하시오.
시스템을 논리적으로 관련 있는 클래스들의 집합으로 묶어 구조를 이해하기 쉽게 하고, 의존성을 관리하기 위해 필요함.
DevOps의 정의와 긍정적 효과가 무엇인지 서술하시오. 그리고, DevOps의 변형을 두 가지 이상 설명하시오.
DevOps: 개발과 운영을 통합하여 소프트웨어의 개발, 배포, 운영을 자동화하고 협업을 강화하는 개발 문화 및 방법론
변형
- DevSecOps: DevOps 프로세스에 보안 관련 활동을 통합 - SW 엔지니어가 DevOps 프로세스의 오른쪽(운영 단계)에서 왼쪽(계획 및 코딩 단계)으로 이동하면서 보안 관련 이슈를 처리하도록 권장. -> 보안을 개발 초기 단계부터 통합하여 문제를 조기에 발견하고 해결.
- BizDevOps: 팀 간 협업을 통해 SW를 더 빠르게 개발하고 사용자 요구에 잘 대응하여 수입을 극대화할 수 있도록 유도하는 개발 접근 방식. 비즈니스 가치에 직접적으로 초점을 맞춥니다.
산출물 간 일관성 점검과정에서 수행할 수 있는 작업을 2가지 이상 서술하시오.
요구사항 명세서와 설계 산출물 간의 추적성 확인
변경 사항이 다른 산출물에 반영되었는지 확인
블랙박스 테스트 설계 기법 중 동치 분할(Equivalence Partitioning)을 사용하는 주된 목적을 “입력 도메인” 관점에서 한 문장으로 서술하시오.
동치 분할의 주된 목적은 입력 도메인을 동일하게 처리하는 동치 클래스들의 부분집합으로 분할하여, 각 부분집합의 대표값만으로 입력 도메인을 효율적으로 테스트함.
모듈화 설계에서 결합도(coupling)를 가장 낮게, 응집도(cohesion)를 가장 높게 가져가야 하는 이유를 "영향 범위" 관점에서 한 문장으로 서술하시오.
응집도를 높여 변경 시 영향 범위를 해당 모듈 내로 한정하고, 결합도를 낮춰 그 영향이 시스템 전체로 확산되는 것을 최소화하기 위해서이다.