[정보처리기사 실기 요약]#3 요구공학(요구사항), UI 요구사항 확인, UI 설계

내가 외우려고 쓰는 정처기 실기 요약 #3
(영어도 꼭 같이 암기하기!!)

1. 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세 확인 및 검증하는
구조화된 활동으로 이해관계자 사이에 효과적인 의사소통 수단 제공, 시스템 개발의 요구사항에 대한 공통된 이해 설정,
개발 비용과 시간 절약, 요구사항 변경 추적을 가능하게 하는 등의 목적을 갖는 것
▶ 요구공학

2. 요구사항의 분류
▶ 기능적 요구사항, 비기능적 요구사항

구분	기능적 요구사항	비기능적 요구사항
개념	시스템이 제공하는 기능, 서비스에 대한 요구사항	시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
도출 방법	- 특정 입력에 대해 시스템이 어떻게 반응 해야하는지에 대한 기술 - 특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술	- 품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술 - 시스템이 준수해야 할 제한 조건에 관한 기술
특성	기능성, 완전성, 일관성	신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항
사례	- 온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장할 수 있는 장바구니 기능을 제공해야 함 - 상품의 결제수단은 신용카드, 무통장 입금, 포인트 결제가 가능해야 함	- 특정 함수의 호출시간은 3초를 넘지 않아야 함 - 시스템은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야 함 - 시스템은 운영되는 중에 패치 및 업그레이드를 할 수 있어야 함

3. 요구사항 개발 단계(프로세스)
▶ 요구사항 도출 → 분석 → 명세 → 확인(도분명확)

4. 이해관계자가 식별되고, 개발팀과 고객사이의 관계가 형성되며 소프트웨어가 해결해야 할 문제를 이해하고,
고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을
구체적으로 표현하는 요구사항 개발 단계
▶ 요구사항 도출(Elicitation) 단계

※ 요구사항 도출 단계 주요 기법

주요 기법	설명
인터뷰 (Interview)	이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법
브레인스토밍 (Brainstorming)	말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할 수 있도록 하는 회의
델파이 기법 (Delphi Method)	전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법
롤 플레잉 (Role Playing)	현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
워크숍 (Workshop)	- 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법 - 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요 - 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구
설문 조사 (Survey)	- 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법 - 개발될 시스템의 사용자가 다수일 때 의견 수렴에 용이

5. 도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계로,
요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위을 파악하며,
소프트웨어가 환경과 어떻게 상호작용하는지 이해하는 요구사항 개발 단계
▶ 요구사항 분석(Analysis) 단계

※ 요구사항 분석 단계 절차
요구사항 분류 → 개념 모델링 생성 및 분석 → 요구사항 할당 → 요구사항 협상 → 정형 분석

※ 요구사항 분석 단계 기법
① 자료 흐름 지향 분석 : 데이터 흐름도 및 자료 사전으로부터 소프트웨어 구조를 유도하는 방법
② 객체 지향 분석 : 시스템의 기능과 데이터를 함께 분석, UML로 표준화

※ 요구사항 분석 기술
- 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성 기술

6. 동의한 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항을 생성하는 활동을 수행하며 체계적으로
검토, 평가, 승인될 수 있는 문서를 작성하는 요구사항 개발 단계
▶ 요구사항 명세(Specification) 단계

※ 요구사항 명세 단계 주요 기법

주요 기법	설명
비정형 명세 기법	- 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법 - 사용자와 개발자의 이해가 용이 - 명확성 및 검증에 문제
정형 명세 기법	- 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법 - 정형 명세 언어인 Z-스키마, Petri Nets, 상태차트 활용 - 표현이 간결, 명확성 및 검증이 용이 - 기법의 이해가 어려움

※ 요구사항 명세 원리 및 검증 항목
- 명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성

7. 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토와 베이스라인을 설정하는 활동으로
분석가가 요구사항을 이해했는지 확인(Validation)하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며,
일관성이 있고, 완전한지 검증(Verification)하는 요구사항 개발 단계
▶요구사항 확인 및 검증(Validation & Verification) 단계

※ 요구사항 확인 및 검증 절차
요구사항 목록 확인 → 요구사항 정의서 작성 여부 확인 → 비기능적 요구사항의 확인 → 타 시스템 연계 및 인터페이스
요구사항 확인

※ 요구사항 확인 및 검증 단계의 주요 기법/산출물
- 요구사항 검토, 정형 기술 검토 활용, 프로토타이핑 활용, 모델 검증, 테스트 케이스 및 테스트를 통한 확인,
CASE 도구 활용 검증, 베이스라인을 통한 검증, 요구사항 추적표(RTM)를 통한 검증

※ 상세 정형 기술 검토 기법

기법	설명
관리 리뷰 (Management Review)	프로젝트 진행 상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰
기술 리뷰 (Technical Review)	- 정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰 - 변경 사항이 적절하게 구현되었는지를 평가하고, 여러 대안을 추천하거나 대안을 검토 - 대표 엔지니어가 주재하며 경우에 따라서 관리자도 참가 가능
인스펙션 (Inspection)	동료 검토(Peer Review)라고도 하며, 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법
워크 스루 (Walk Through)	가장 비형식적인 검토 기법으로, 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 기법
감사 (Audit)	- 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법 - 감사는 소프트웨어 제품의 제공자, 소비자, 제3기관이 수행

8. 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을
구체적으로 명시하는 사전
▶ 자료 사전(DD : Data Dictionary)

9. 입출력장치를 매개로 디지털 시스템과 사람이 주고받는 일련의 의사소통 과정
▶ 인터렉션(interaction)

10. 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림으로, 시스템 분석과 설계에서 매우 유용하게
사용되는 다이어그램
▶ 데이터 흐름도(DFD : Data Flow Diagram)

11. 소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물
▶ 요구사항 명세서(= 요구사항 정의서)

12. 소프트웨어 생명주기 동안 발생하는 변경사항을 체계적으로 관리하여 소프트웨어의 품질보증을 향상시키는 관리적 활동
▶ 형상 관리

13. 형상 관리에 대한 주요 방침을 정하고 산출물을 검토하며, 단계별 의사결정을 수행하는 조직
▶ 형상통제위원회(CCB : Configuration Control Board)

14. 시스템의 외부에 있고, 시스템과 상호 작용을 하는 사람 또는 시스템
▶ 액터(Actor)

15. 시스템이 액터에게 제공해야 하는 기능으로 시스템 요구사항이자, 사용자 입장에서 바라본 시스템의 기능
▶ 유스케이스(Usecase)

16. 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 요두사항 분석을 위한 자동화 도구
▶ 분석 자동화 도구

---

17. 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적, 가상의 매개체로, 정보 기기나 소프트웨어의 화면 등에서 사람이 접하게 되는 화면
▶ UI(User Interface, 사용자 인터페이스)

18. 제품과 시스템, 서비스 등을 사용자가 직/간접적으로 경험하면서 느끼고 생각하는 총체적 경험
▶ UX(User Experience, 사용자 경험)

19. 정적인 텍스트 기반의 인터페이스로, 명령어를 텍스트로 입력하여 조작하는 사용자 인터페이스(UI) 유형
▶ CLI(Command Line Interface)

20. 그래픽 반응 기반의 인터페이스로, 그래픽 환경을 기반으로 한 마우스나 전자펜을 이용하는
사용자 인터페이스(UI) 유형
▶ GUI(Graphical User Interface)

21. 직관적 사용자 반응 기반의 인터페이스로, 키보드나 마우스 없이 신체 부위를 이용(터치, 음성 포함)하는
사용자 인터페이스(UI) 유형
▶ NUI(Natural User Interface)

22. 유기적 상호 작용 기반의 인터페이스로, 현실에 존재하는 모든 사물이 입출력장치로 변화할 수 있는
사용자 인터페이스(UI) 유형
▶ OUI(Organic User Interface)

23. UI 설계 원칙
▶ 직관성, 유효성, 학습성, 유연성(직유학유)

설계 원칙	설명	부특성
직관성 (Intuitiveness)	누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 함	- 쉬운 검색 - 쉬운 사용성 - 일관성
유효성 (Effciency)	정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작	쉬운 오류 처리 및 복구
학습성 (Learnability)	초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작	- 쉽게 접근 - 쉬운 접근 - 쉽게 기억
유연성 (Flexibility)	사용자의 요구사항을 최대한 수용하고, 실수를 방지할 수 있도록 제작	- 오류 예방 - 실수포용 - 오류 감지

24. UI 설계 지침
▶ 사용자 중심, 일관성, 단순성, 결과 예측 가능, 가시성, 표준화, 접근성, 명확성, 오류 발생 해결

25. UI 품질 요구사항
▶ 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성(기신사효유이)

① 기능성(Functionality)
기능성 = 실제 수행 결과와 품질 요구사항과의 차이를 분석하고, 실제 사용 시 정확하지 않은 결과가 발생할 확률과
관련하여 시스템의 동작을 관찰하기 위한 품질 기준
기능성 상세 품질 요구사항 = 적절성, 정밀성, 상호 운용성, 보안성, 호환성

② 신뢰성(Reliability)
신뢰성 = 시스템이 일정한 시간 또는 작동되는 시간 동안 의도하는 기능을 수행함을 보증하는 품질 기준
신뢰성 상세 품질 요구사항 = 성숙성, 고장 허용성, 회복성

③ 사용성(Usability)
사용성 = 사용자와 컴퓨터 사이에 발생하는 어떠한 행위를 정확하고 쉽게 인지할 수 있는 품질 기준
사용성 상세 품질 요구사항 = 이해성, 학습성, 운용성

④ 효율성(Efficiency)
효율성 = 할당된 시간에 한정된 자원으로 얼마나 빨리 처리할 수 있는가에 대한 품질 기준
효율성 상세 품질 요구사항 = 시간 효율성, 자원 효율성

⑤ 유지보수성(Maintainability)
유지보수성 = 요구사항을 개선하고 확장하는 데 있어 얼마나 용이한가에 대한 품질 기준
유지보수성 상세 품질 요구사항 = 분석성, 변경성, 안정성, 시험성

⑥ 이식성(Portability)
이식성 = 다른 플랫폼(운영체제)에서도 많은 추가 작업 없이 얼마나 쉽게 적용이 가능한가에 대한 품질 기준
이식성 상세 품질 요구사항 = 적용성, 설치성, 대체성

---

26. 디자인 철학과 원칙 기반 하에 전체 시스템에 공통으로 적용되는 화면 간 이동, 화면구성 등에 관한 규약
▶ UI 표준

27. 여러 옵션 중 1개 이상의 옵션을 선택할 때 사용하는 요소
▶ 체크박스(Checkbox)

28. 여러 옵션 중 1개의 옵션을 선택할 때 사용하는 요소
▶ 라디오 버튼(Radio Button)

29. 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신),
Delete(삭제)를 묶어서 일컫는 말
▶ CRUD 방식

30. 한 번의 로그인을 통해 여러 다른 사이트들을 자동적으로 접속하여 이용하는 방법(통합 로그인)
▶ SSO(Single Sign On)

31. SW의 실행을 클라이언트에서 책임지는 기술로, 서버는 클라이언트에서 요청한 SW의 실행 코드를 스트림 형태로
제공하고, 클라이언트는 서버로부터 스트리밍되는 SW 코드를 클라이언트 PC의 자원을 이용하여 실행하는 기술
▶ 리치 클라이언트(Rich Client)

32. SW의 실행을 전적으로 서버에서 책임지는 기술로, 서버에서 가상 머신을 이용하여
클라이언트의 데이터와 SW를 관리 및 실행하는 기술
▶ 씬 클라이언트(Thin Client)

---

33. UI 표준에 따라 사용자 인터페이스 설계, 개발 시 지켜야할 세부사항을 규정하는 가이드라인
▶ UI 지침(Guideline)

34. 고객(Customer), 경쟁하고 있는 자사(Company)와 경쟁사(Competitor)를 비교하고 분석하여
자사를 어떻게 차별화해서 이길 것인가를 분석하는 기법
▶ 3C 분석

35. 기법의 내부 환경과 외부 환경을 분석하여 Strength(강점), Weakness(약점), Opportunity(기회), Threat(위협) 요인을
규정하고 이를 토대로 경영 전략을 수립하는 방법
▶ SWOT분석

36. 불확실성이 높은 상황 변화를 사전에 예측하고 다양한 시나리오를 설계하는 방법으로 불확실성을 제거해나가는
경영 전략의 한 방법
▶ 시나리오 플래닝(Scenario Planning)

37. 사용자가 직접 제품을 사용하면서 미리 작성된 시나리오에 맞추어 과제를 수행한 후, 질문에 답하도록 하는 테스트
▶ 사용성 테스트(Usability Test)

38. 소집단 정도의 인원으로 특정 문제나 과제에 대한 새로운 지식, 기술, 아이디어, 방법들을 서로 교환하고 검토하는
연구회 및 세미나
▶ 워크숍(Workshop)

39. 지식에 대한 탐구를 기반으로 한 인간 활동이며, 이미 존재하던 지식의 발견, 해석, 정정, 재확인 등에 초점을 맞추는
체계적인 조사
▶ 리서치(Research)

40. 사용자 요구사항 도출
▶ 페르소나 정의, 콘셉트 모델 정의, 사용자 요구사항 정의, UI 컨셉션

세부 수행 활동	설명	세부 수행 활동
페르소나 (persona) 정의	잠재적 사용자의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 가상의 사용자	- 페르소나 분류 및 정의 - 페르소나 작성 - 페르소나 활용
콘셉트 모델 정의	- 여러 가지 추상적인 콘셉트들 사이의 관계를 보여주는 다이어그램 - 다양한 아이디어들을 간편하게 시각화하여 표현할 수 있는 유용한 방법으로 아이디어를 잘 전달하고 생각의 과정을 효율적으로 이끌어 줌	- 콘셉트 모델 정의 - *브레인스토밍 활동
사용자 요구사항 정의	리서치 및 페르소나 결과물을 토대로 요구사항을 도출하고, 우선순위를 정함	- *요구사항 매트릭스 작성 - *정황 시나리오 제작 - 정황 시나리오로부터 요구사항 도출
UI 컨셉션	정리된 요구사항을 구체화하는 단계로 디자인 단계 전에 대표 화면 설계를 진행하는 단계	- 정보 구조 설계 - 대표 화면 와이어프레임 스케치 - 페이퍼 프로토타입을 통한 스토리보드 설계

*브레인스토밍(Brain Storming)
집단적 창의적 발상 기법으로 집단에 소속된 인원들이 자발적으로 자연스럽게 제시된 아이디어 목록을 통해서
특정한 문제에 대한 해답을 찾고자 하는 회의 기법

*요구사항 매트릭스(Requirement Matrix)
다양한 경로를 통해 수집된 직접적인 요구사항을 검토하여, 페르소나의 목적을 기준으로
데이터 요구, 기능 요구, 제품 품질, 제약 요인 기반으로 만든 요구사항 표

*정황 시나리오(Contextual Scenario)
요구사항 정의에 사용되는 초기 시나리오를 말하며, 높은 수준, 낙관적이면서도 발생 상황에서의 이상적인 시스템 동작에
초점을 맞추는 시나리오

---

41. 이해 관계자들과의 화면구성을 협의하거나 서비스의 간략한 흐름을 공유하기 위해
화면 단위의 레이아웃을 설계하는 작업
▶ 와이어프레임(Wireframe)

42. UI 화면 설계를 위해서 정책이나 프로세스 및 콘텐츠의 구성, 와이어프레임(UI, UX), 기능에 대한 정의, 데이터베이스의
연동 등 구축하는 서비스를 위한 대부분의 정보가 수록된 문서로 디자이너와 개발자가 최종적으로 참고하는 산출 문서
▶ 스토리보드(StoryBoard)

43. 정적인 화면으로 설계된 와이어프레임 또는 스토리보드에 동적 효과를 적용하여 실제 구현된 것처럼
시뮬레이션할 수 있는 모형
▶ 프로토타입(Prototype)

※ 프로토타입 추가 내용
프로토타입은 사전에 프로토타입을 먼저 제작하고 이를 기반으로 UI의 적정성을 평가, 수정 보완함으로써 추후
발생 가능한 오류들을 사전에 방지하는 효과가 있으며, 시스템 설계 및 개발에 소요되는 총비용과 노력을 절감할 수 있음.

44. 스토리보드 작성 절차
▶ 전체 개요 작성 → 서비스 흐름 작성 → 스타일 확정 → 메뉴별 화면 설계도 작성 및 상세 설명 → 추가 관련 정보 작성

45. 스토리보드 작성 시 유의사항
▶ 일관된 기호의 표시, 공통 영역의 정의, 영역별 세부 설계, 버전 업 관리

---

46. 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 시 사용되는 모델링 기술과 방법론을 통합해
만든 표준화된 범용 모델링 언어
▶ UML(Unified Modeling Language)

47. UML의 특징
▶ 가시화, 구축, 명세화, 문서화 언어

48. UML의 구성요소
▶ 사물, 관계, 다이어그램(사관다)

49. UML 스테레오 타입
▶ UML 스테레오 타입은 UML의 기본적 요소 이외의 새로운 요소를 만들어 내기 위한 확장 메커니즘이며,
형태는 기존의 UML의 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장함.
UML의 스테레오 타입은 '<<>>'(길러멧) 기호를 사용하여 표현함.

※ UML 스테레오 타입의 유형

유형	설명
<<include>>	하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계
<<extend>>	하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지 않을 수도 있는 확장 관계
<<interface>>	모든 메서드가 추상 메서드이며 바로 인스턴슬르 만들 수 없는 클래스로 추상 메서드와 상수만으로 구성된 클래스
<<entity>>	일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스
<<boundary>>	시스템과 외부 액터와의 상호 작용을 담당하는 클래스
<<control>>	시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

50. UML 다이어그램
▶ 구조적(정적) 다이어그램 : 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지
행위적(동적) 다이어그램 : 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 타이밍

51. 구조적(정적) 다이어그램 : 클래스 다이어그램
▶ 개념 : 객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램
구성요소 : 클래스 이름, 속성, 연산, 접근 제어자, 관계
클래스 간의 관계 : 연관, 집합, 포함(복합), 일반화, 의존, 실체화 관계

※ 클래스 다이어그램 구성요소

구성요소	설명
클래스 (Class)	공통의 속성, 연산(메서드), 관계, 의미를 공유하는 객체들의 집합
속성 (Attribute)	클래스의 구조적 특성에 이름을 붙인 것으로 특성에 해당하는 인스턴스가 보유할 수 있는 값의 범위를 기술
연산(Operation), 메서드	이름, 타입, 매개변수들과 연관된 행위를 호출하는데 요구되는 제약사항들을 명시하는 클래스의 행위적 특징으로, 객체에 요청하여 행동에 영향을 줄 수 있는 서비스
접근 제어자 (Access Modifier)	클래스에 접근할 수 있는 정도를 표현 하이픈(-) : 클래스 내부 접근만 허용(private) 플러스(+) : 클래스 외부 접근을 허용(public) 샵(#) : 동일 패키지/파생 클래스에서 접근 가능(protected) 물결(~) : 동일 패키지 클래스에서 접근 가능(default)

※ 클래스 간의 관계

구분	설명
연관 관계 (Association)	- 클래스가 서로 개념적으로 연결된 선임. - 2개 이상의 사물이 서로 관련되어 있는 상태를 표현함. - 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현함. - 서로에게 영향을 주는 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결함. (ex. 축구팀 ↔ 공격수, 수비수, 골키퍼)
의존 관계 (Dependency)	- 하나의 클래스가 또 다른 클래스를 사용하는 관계임. - 다른 클래스의 멤버 함수를 사용함. - 사물 사이에 서로 연관은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현함. - 하나의 클래스에 있는 멤버 함수의 인자가 변함에 따라 다른 클래스에 영향을 미칠 때의 관계임. - 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하려 표현함. (ex. 교수 ← 수업)
일반화 관계 (Generalization)	- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현함. - 일반적인 개념을 부모(상위)라고 하고, 구체적인 개념을 자식(하위)라고 함. - 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현함. - 다른 의미로 상속 관계라고도 함. (ex. 차 ← 자가용, 택시, 버스)
실체화 관계 (Realization)	- 추상 클래스나 인터페이스를 상속받아 자식클래스가 추상 메서드를 구현할 때 사용함. - 사물이 할 수 있거나, 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현함. (ex. 아래에 있는 *추상 클래스, 인터페이스 관계 표 확인)
포함 관계 (Composition)	- 영구적이고, 집합 관계보다 더 강한 관계로 구성됨. - 포함되는 쪽(part : 부분)에서 포함하는 쪽(whole : 전체)으로 속이 채워진 마름모를 연결하여 표현함. - 포함 관계는 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현함. - 포함 관계는 복합 관계라고도 함. (ex. 엔진 ← 피스톤, 플러그)
집합 관계 (Aggregation)	- 하나의 객체에 여러 개의 독립적인 객체들이 구성되는 관계임. - 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현함. - 포함되는 쪽(part : 부분)에서 포함하는 쪽(whole : 전체)으로 속이 빈 마름모를 연결하여 표현함. (ex. 차 ← 엔진, 바퀴, 운전대)

※ 실체화 관계에서 *추상 클래스와 인터페이스 관계

구분	설명
추상 클래스	- 객체 인스턴스를 생성하지 않고, 단지 유사 클래스들의 공통된 특징을 정의하고, 하나 이상의 추상 메서드와 일반 필드 및 일반 메서드를 포함하는 클래스임. - 동일한 부모를 가지는 클래스를 묶는 개념으로 상속을 받아서 기능을 확장시키는 것이 목적임. - 이탤릭체로 클래스명을 표시하며, 스테레오타입을 이용하여 <<adstract>>로 표기함. (ex. <<adstract>> Dog ←(extends) Dalmatian, Collie, Shepherd)
인터페이스	- 기능을 모아놓은 클래스로 추상 메서드와 상수만을 포함하는 추상 클래스임. - 구현하는 모든 클래스에 대해 특정한 메서드가 반드시 존재하도록 강제하는 역할을 함. - 스테레오타입을 이용하여 <<interface>>로 표기하고, 이탤릭체로 인터페이스명을 표기함. (ex. <<interface>> Dog ←(implements) Car, Train, Plane)

※ 연관 관계의 다중성

다중성 표현	의미
1	한 객체와 연관, 표시하지 않아도 기본값임.
0..1	0개 또는 1개의 객체와 연관
0..*	0개 또는 많은 수의 객체가 연관
*	0..*와 동일
1..*	1개 이상의 객체와 연관
1..12	1개에서 12개까지 객체가 연관
1..2, 4, 6	1개에서 2개까지 또는 4개 또는 6개의 객체가 연관

52. 구조적(정적) 다이어그램 : 패키지 다이어그램
▶ 개념 : 시스템의 서로 다른 패키지들 사이의 의존 관계를 표현하기 위한 다이어그램
구성요소 : 패키지, 의존관계

※ 패키지 다이어그램 구성요소

구성요소	설명
패키지	- 요소들을 그룹으로 조직하기 위한 요소
의존관계	- 하나의 패키지가 다른 패키지를 사용하는 관계 - 의존성의 성질을 나타내기 위해 스테레오 타입을 붙일 수 있음. - 스테레오 타입에는 <<import>>, <<access>>가 있음.

53. 구조적(정적) 다이어그램 : 컴포넌트 다이어그램
▶ 개념 : 시스템을 구성하는 물리적인 컴포넌트와 그들 사이의 의존 관계를 나타내는 다이어그램으로,
코드 컴포넌트 기반의 물리적 구조로 표현되며, 실질적 프로그래밍 작업에 사용함.
구성요소 : 컴포넌트, 인터페이스, 의존 관계

※ 컴포넌트 다이어그램 구성요소

구성요소	설명
컴포넌트	- 탭이 달린 직사각형으로 표현함. - 모든 컴포넌트는 반드시 이름을 가지고 있어야 함. - 컴포넌트가 패키지에 포함되어 있다면 컴포넌트의 이름 앞에 패키지 이름을 붙일 수 있으며, 클래스처럼 컴포넌트에 꼬리표 값을 달아주거나 컴포넌트 내부의 오퍼레이션을 보여줄 수도 있음.
인터페이스	- 인터페이스를 실체화한다는 의미는 실제로 동작하는 인터페이스를 적용한다는 뜻임. - 컴포넌트와 인터페이스는 화살표 모양의 점선(의존 관계)으로 연결함.
의존 관계	- 컴포넌트 사이의 의존하는 관계를 표현함. - 컴포넌트 사이의 의존 관계는 한 컴포넌트에 변경이 발생한 경우, 변경 범위 추적에 유용함.

54. 행위적(동적) 다이어그램 : 유스케이스 다이어그램
▶ 개념 : 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
구성요소 : 유스케이스, 액터, 시스템, 시나리오, 이벤트의 흐름
관계 : 포함, 확장, 일반화 관계

※ 유스케이스 다이어그램 구성요소

구성요소	설명
유스케이스 (Usecase)	- 시스템이 제공해야 하는 서비스, 기능 - 액터가 시스템을 통해 수행하는 일련의 행위
액터 (Actor)	- 사용자가 시스템에 대해 수행하는 역할 - 시스템과 상호 작용하는 사람 또는 사물 - 이벤트 흐름을 시작하게 하는 객체
시스템 (System)	- 전체 시스템의 영역을 표현
시나리오	- 발생되는 이벤트의 흐름
이벤트의 흐름	- 사람, 시스템, 하드웨어, 시간의 흐름에 의해 시작

※ 유스케이스 다이어그램의 관계

관계	설명
포함 관계 (Include)	- 유스케이스를 수행할 때 다른 유스케이스가 반드시 수행되는 관계임. - 다른 유스케이스가 나타내는 이벤트 흐름을 포함하는 관계를 유스케이스 간에 표현함. - 여러 유스케이스에서 공통적으로 발견되는 기능을 표현함. - 2개 이상의 유스케이스 이벤트 흐름에서 중복적인 부분이 발생하는 경우 유스케이스 간 포함 관계를 설정하여 해결함. - <<include>>로 표현함.
확장 관계 (Extend)	- 특정 조건에서 한 유스케이스로만 확장되는 관계임. - 특정 조건이 만족되는 상황에서만 확장 유스케이스의 이벤트 흐름이 수행 됨. - 한 유스케이스에서 추가되거나 확장된 기능을 표현함. - <<extend>>로 표현함.
일반화 관계 (Generalization)	- 추상적인 액터와 좀 더 구체적인 액터 사이에 맺어주는 관계임. - 일반화 관계를 액터에 적용하면 유스케이스 다이어그램에서 사용되는 여러 액터들의 의미를 좀 더 명확하게 하고 다이어그램도 보다 간결하게 작성 함. - 하위 액터나 유스케이스에서 상위 액터, 유스케이스 쪽으로 속이 빈 삼각항 화살표를 실선으로 연결함.

55. 행위적(동적) 다이어그램 : 시퀸스 다이어그램
▶ 개념 : 시퀸스 다이어그램은 객체 간 상호 작용을 메시지 흐름으로 표현한 다이어그램으로,
객체 간의 동적 상호 작용을 시간적 개념을 중심으로 모델링하는 과정임.
또한 시퀸스 다이어그램에서는 객체의 오퍼레이션과 속성을 상세히 정의해야 하며,
시퀸스 다이어그램은 유스케이스를 실현 함.
구성요소 : 객체, 생명선, 실행(활성화), 메시지

※ 시퀸스 다이어그램 구성요소

구성요소	설명
객체 (Object)	- 객체는 위쪽에 표시되며 아래로 생명선을 가짐. - 객체는 사각형 안에 밑줄 친 이름으로 명시함.
생명선 (Lifeline)	- 객체로부터 뻗어 나가는 점선임. - 실제 시간이 흐름에 따라 객체의 생명주기 동안 발생하는 이벤트를 명시함.
실행 (Activation)	- 직사각형은 오퍼레이션(함수)이 실행되는 시간을 의미함. - 직사각형이 길어질수록 오퍼레이션 수행시간이 긺.
메시지 (Message)	- 객체 간의 상호 작용은 메시지 교환으로 이루어짐. - 한 객체에서 다른 객체로의 메시지를 전달하여 전달받은 객체의 오퍼레이션을 수행함.

56. 행위적(동적) 다이어그램 : 활동 다이어그램
▶ 개념 : 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름을
순서대로 표현하는 다이어그램으로, 오퍼레이션이나 처리과정이 수행되는 동안 일어나는 일들을
단계적으로 표현하며, 하나의 유스케이스 안이나 유스케이스 사이에서 발생하는 복잡한 처리의 흐름을
명확하게 표현할 수 있음.
구성요소 : 시작점, 전이, 액션/액티비티, 조건(판단) 노드, 병합 노드, 포크 노드, 조인 노드, 구획면

※ 활동 다이어그램 구성요소

구성요소	설명
시작점 (Initial Node)	- 활동의 시작(액션이나 액티비티 시작)을 의미함. - 하나의 다이어그램 안에는 하나의 시작점만 존재함. - 검은색 동그라미로 표현함.
전이 (Transition)	- 실행의 흐름을 나타냄. - 화살표로 표현함.
액션(Action)/ 액티비티(Activity)	- 어떠한 일들의 처리와 실행을 의미함. - 액션은 더 이상 분해할 수 없는 단일 작업이고, 액티비티는 몇 개의 액션으로 분리될 수 있는 작업임. - 모서리가 둥근 사각형으로 표현하고, 둥근 사각형 안에 액션이나 액티비티 명칭을 기술함.
종료점 (Final Node)	- 처리의 종료를 의미함. - 하나의 다이어그램 안에는 여러 개의 종료 노드가 있을 수 있음. - 검은색 동그라미를 포함한 원으로 표현함.
조건(판단) 노드 (Decision Node)	- 조건에 따른 제어 흐름의 분리를 표현함. - 마름모로 표현함. - 들어오는 제어 흐름은 한 개이고, 나가는 제어 흐름은 여러개로 표현함.
병합 노드 (Merge Node)	- 여러 경로의 흐름이 하나로 합쳐진 것을 표현함. - 마름모로 표현함. - 들어오는 제어 흐름은 여러 개이고, 나가는 제어 흐름은 한 개로 표현함.
포크 노드 (Fork Node)	- 평행적으로 수행되는 흐름을 나누는 노드임. - 굵은 가로선으로 표현함. - 들어오는 액티비티 흐름은 한 개이고, 나가는 액티비티 흐름은 여러개임.
조인 노드 (Join Node)	- Fork Node로 나눠진 흐름을 다시 하나로 합치는 노드임. - 굵은 가로선으로 표현함. - 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 한 개임.
구획면 (Swim Lane)	- 액티비티 수행을 담당하는 주체를 구분하는 면임. - 가로 또는 세로 실선을 그어 구분함.

57. 행위적(동적) 다이어그램 : 상태 다이어그램
▶ 개념 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라
상태가 어떻게 변화하는지 표현하는 다이어그램으로, 어떤 이벤트에 의해 객체 자신이 속한 클래스의
상태 변화나 객체 간 상호 작용하는 과정에서의 상태 변화를 표현함.
객체는 파악된 상태들 이외의 상태는 가질 수 없고, 특정 순간에는 오직 한 상태로만 존재할 수 있음.
여기서 객체의 상태란 객체가 갖는 속성값의 변화임.
구성요소 : 상태, 시작 상태, 종료 상태, 전이, 이벤트, 전이 조건

※ 상태 다이어그램 구성요소

구성요소	설명
상태 (State)	- 객체가 존재할 수 있는 조건 중의 하나임. - 둥근 사각형 안에 객체의 상태를 기술함.
시작 상태	- 객체의 시작 상태임. - 속이 채워진 원으로 표현함.
종료 상태	- 객체의 종료 상태임. - 원 안에 속이 채워진 원으로 표현함.
전이	- 객체의 상태가 다른 상태로 변경되는 상태임. - 상태 사이의 흐름, 변화를 나타냄. - 화살표로 표현함.
이벤트 (Event)	- 객체의 전이를 유발하는 자극임. - 상태의 변화를 주는 현상임. - 상태의 전이를 유발하는 이벤트는 전이 위에 이벤트 이름을 표시함. - 이벤트 : 시간의 흐름, 조건, 외부 신호 등
전이 조건	- 특정 조건 만족 시 전이가 발생하도록 하기 위해 사용되는 속성값의 불리언 식임.

58. 행위적(동적) 다이어그램 : 커뮤니케이션 다이어그램
▶ 개념 : 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하고,
메시지뿐만 아니라 객체 간의 연관까지 표현하는 다이어그램으로,
시스템이나 객체들이 메시지를 주고받으며시간의 흐름에 따라 상호 작용하는 과정을 표현한 다이어그램임.
구성요소 : 액터, 객체, 링크, 메시지

※ 커뮤니케이션 다이어그램 구성요소

구성요소	설명
액터 (Actor)	- 시스템으로부터 서비스를 요청하는 외부 요소(사람, 외부 시스템)임.
객체 (Object)	- 메시지를 주고 받은 주체임. - 콜론(:)을 기준으로 앞쪽에는 객체명, 뒤쪽에는 클래스명을 기술함.
링크 (Link)	- 객체들 간의 관계를 표현함. - 클래스가 아닌 실제 객체와의 관계를 직접적으로 보여주는 객체들 사이의 링크임. - 액터와 객체, 객체 간 실선으로 표현함. - 링크에 메시지를 표현함.
메시지 (Message)	- 객체가 상호 작용을 위해 주고받는 메시지임. - 메시지는 상대 객체별로 여러 개의 정의가 이루어지므로, 하나의 동일한 링크에서 여러 개의 메시지가 전달됨. - 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현함.

---