[정보처리기사 필기] 1과목. 소프트웨어 설계 (1)

소프트웨어 생명 주기

소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 단계별로 나눈 것, 소프트웨어 수명 주기, 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임이라고도 한다. 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있다.

폭포수 모형

가장 오래됨, 고전적 생명 주기 모형이라고도 한다. 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형이다. 성공 사례가 많다. 매뉴얼을 작성해야 한다. 결과물이 명확하게 산출되어야 한다. 두 개 이상의 과정을 병행하여 수행하지 않는다. (타당성 검토→계획→요구 분석→설계→구현(코딩)→시험(검사)→유지보수)

프로토타입 모형(원형 모형)

시제품(프로토타입)을 만들어 최종 결과물을 예측하는 모형이다. 사용자와 시스템 사이의 인터페이스에 중점을 둔다. 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점 보완(요구 수집→빠른 설계→프로토 타입 구축→고객 평가→프로토 타입 조정→구현)

나선형 모형(점진적 모형)

폭포수 모형과, 프로토타입 모형의 장점에 위험 분석 기능을 추가. 개발 과정 중 발생 할 수 있는 위험을 관리하고 최소화. 점진적으로 개발 과정이 반목되므로 정밀하며, 유지보수 과정이 필요없다.

애자일(민첩한, 기민한) 모형

고객과의 소통에 초점을 맞춘 방법론을 통칭한다. 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기(스프린트 또는 이터레이션이라고 함)를 반복하면서 개발 과정을 진행한다. 소규모 프로젝트, 고도로 숙달된 개발자, 급현하는 요구사항에 적합하다. 스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능중심개발(FDD), DSDM, DAD 등이 있다. 

스크럼(Scrum) 기법

팀원 스스로가 스크럼 팀을 구성(self-organizing) 해야 하며, 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다. 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다. 

제품 책임자(Product Owner)

개발 의뢰자나 사용자가 담당, 제품에 대한 요구사항을 작성하는 주체, 백로그를 작성하고 백로그의 우선순위를 지정한다. 팀원들이 백로그에 스토리를 추가할 수는 있지만, 우선순위 지정은 못한다. 제품 테스트를 진행하면서 우선순위를 갱신한다. 

스크럼 마스터(Scrum Master)

객관적인 시각에서 조언을 해주는 가이드 역할, 통제하는 것이 목표가 아니다. 일일 스크럼 회의를 주관하여 진행 사항을 점검, 개발 과정에서 발생된 장애 요소를 공론화하여 처리한다.

개발팀(Development Team)

제품 책임자와 스크럼 마스터를 제외한 모든 팀원, 개발자 이외에 디자이너 테스터 등 제품 개발에 참여하는 모든 사람을 지칭. 보통 최대 7~8명이 적당하다.

제품 백로그(Product Backlog)

제품 개발에 필요한 모든 요구사항(User Story)을 우선 순위에 따라 나열한 목록. 지속적으로 업데이트 되며, 작성된 사용자 스토리를 기반으로 릴리즈 계획을 수립한다.

스프린트 계획 회의(Sprint Planning Meeting)

해당 스프린트에서 수행할 단기 일정을 수립. 요구사항(User story)을 태스크 단위로 분할한 후 개발자별로 나눠서 작업(스프린트 백로그 작성)

스프린트(Sprint)

보통 2~4주 기간 내에서 진행, 개발자가 원하는 태스크를 선별하여 담당하도록 권장, 태스크는 할 일(To Do), 진행 중(In Progress), 완료(Done)의 상태를 갖는다.

일일 스크럼 회의(Daily Scrum Meeting)

매일 약속된 시간에 모든 팀원이 진행상황을 점검, 남은 작업 시간 소멸 차트에 표시, 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와준다. 

스프린트 검토 회의(Sprint Review)

사용자가 포함된 참석자 앞에서 테스팅 수행, 제품 책임자는 개선할 사항에 대한 피드백을 정리한 후 제품 백로그를 업데이트(다음 스프린트에 반영)

스프린트 회고(Sprint Retrospective)

정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 확인하고 기록, 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행한다.

(스프린트 계획 회의→스프린트→일일 스크럼 회의→스프린트 검토 회의→스프린트 회고)

XP(eXtreme Programming) 기법

고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법. 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발. 릴리즈 기간을 짧게 반복하면서 요구사항 반영에 대한 가시성을 높인다. 소규모 인원 개발 프로젝트에 효과적(5가지 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백)

사용자 스토리

고객의 요구사항을 간단한 시나리오로 표현(기능 단위 구성, 간단한 테스트 사항 기재)

릴리즈 계획 수립

부분 혹은 전체 개발 완료 시점에 대한 일정 수립

스파이크

요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 프로그램, 처리할 문제 외의 다른 조건은 모두 무시하고 작성

이터레이션

하나의 릴리즈를 더 세분화 한 단위, 1~3주 기간으로 진행, 새로운 스토리가 작성되면 진행 중인 이터레이션 혹은 다음 이터레이션에 포함

승인 검사(인수 테스트)

고객이 직접 수행하는 테스트, 발견된 오류 사항은 다음 이터레이션에 포함, 요구 사항의 우선순위가 바뀔 수 있다. 테스트가 완료되면 다음 이터레이션 진행

소규모 릴리즈

릴리즈를 소규모로 하면, 고객의 반응을 기능별로 확인하여 요구사항에 더 유연하게 대처 가능. 고객에 의한 최종 테스트 수행 후 릴리즈, 즉 최종 결과물을 고객에게 전달. 최종이 아니라면 다음 릴리즈 일정에 맞게 개발 진행

Pair Programming(짝 프로그래밍)

다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성

Collective Ownership(공동 코드 소유)

개발 코드에 대한 권한과 책임을 공동으로 소유

Test-Driven Development(테스트 주도 개발)

실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지 정확히 파악, 자동화된 테스팅 도구(구조, 프레임워크)를 사용

Whole Team(전체 팀)

개발에 참여하는 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 한다.

Continuous Integration(계속적인 통합)

모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합

Design Improvement(디자인 개선) 또는 Refactoring(리팩토링)

프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템 재구성

Small Releases(소규모 릴리즈)

릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응 가능

현행 시스템 파악

1단계(시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악)→2단계(아키텍쳐 구성 파악, 소프트웨어 구성 파악)→3단계(하드웨어 구성 파악, 네트워크 구성 파악)

시스템 구성 파악

조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분. 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시

시스템 기능 파악

단위 업무 시스템이 현재 제공하는 기능들을 주요 기능, 하부 기능, 세부 기능으로 구분하여 계층형으로 표시

시스템 인터페이스 파악

단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜(통신규약), 연계 유형, 주기 등을 명시

아키텍쳐 구성 파악

어떠한 기술 요소들이 사용되는지 계층별로 표현한 아키텍쳐 구성도로 작성, 단위 업무 시스템별로 아키텍쳐가 다른 경우에는 가장 핵심이 되는 시스템을 기준으로 표현

소프트웨어 구성 파악

업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시

하드웨어 구성 파악

운용되는 서버의 주요 사양, 수량, 이중화의 적용 여부를 명시(현행 시스템에 이중화가 적용된 경우 이후 새로 구성될 시스템들도 이중화가 필요)

네트워크 구성 파악

서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성. 서버들의 물리적인 위치 관계 파악, 보안 취약성 분석 및 대응, 장애 발생 원인을 찾아 복구하기 위한 용도로 사용

개발 기술 환경

개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야 할 사항, 오픈 소스 사용 시 주의해야 할 내용들을 기술

운영체제(OS)

사용자와 하드웨어 간의 인터페이스, 동작하는 시스템 소프트웨어의 일종. 컴퓨터 시스템의 자원들을 효율적으로 관리. 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공(Windows, UNIX, Linux, Mac OS / IOS, Android)

운영체제 관련 요구사항 식별 시 고려사항

가용성	운영체제 고유의 장애 발생 가능성 메모리 누수로 인한 성능 저하 및 재가동 패치 설치로 인한 재가동
성능	대규모 동시 사용자 요청에 대한 처리 대규모 및 대용량 파일 작업에 대한 처리 지원 가능한 메모리 크기
기술 지원	제작업체의 안정적인 기술 지원 여러 사용자들 간의 정보 공유 오픈 소스 여부
주변 기기	설치 가능한 하드웨어 여러 주변기기 지원 여부
구축 비용	지원 가능한 하드웨어 비용 응용 프로그램의 라이선스 정책 및 비용 유지관리 비용 총 소유 비용(TCO)

데이터베이스 관리 시스템(DBMS)

사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어이다. 기존의 파일 시스템이 갖는 데이터 종속성과 중복성의 문제를 해결하여 모든 응용 프로그램들이 데이터베이스를 공유한다. 데이터베이스의 구성. 접근 방법, 유지관리에 대한 모든 책임을 진다.(Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis 등)

DBMS 관련 요구사항 식별 시 고려사항

가용성	DBMS 고유의 장애 발생 가능성 패치 설치로 인한 재가동 백업이나 복구의 편의성 DBMS 이중화 및 복제 지원
성능	대규모 데이터 처리 성능(분할 테이블 지원 여부) 대용량 트랜잭션 처리 성능 튜닝 옵션의 다양한 지원 최소화된 설정과 비용 기반의 질의 최적화 지원
기술 지원	제작업체의 안정적인 기술 지원 여러 사용자들 간의 정보 공유 오픈 소스 여부
상호 호환성	설치 가능한 운영체제 종류 JDBC(자바와 DB를 연결), ODBC(응용 프로그램과 DB를 연결)와의 호환 여부
구축 비용	라이선스 정책 및 비용 유지관리 비용 총 소유 비용(TCO)

웹 애플리케이션 서버(WAS)

정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어. 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공, 데이터베이서 서버와 연동해서 사용(Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등)

WAS 관련 요구사항 식별 시 고려사항

가용성	WAS 고유의 장애 발생 가능성 패치 설치를 위의한 재가동 안정적인 트랜잭션 처리 WAS 이중화 지원
성능	대규모 트랜잭션 처리 성능 튜닝 옵션의 다양한 지원 가비지 컬렉션(Garbage Collection)의 다양한 옵션
기술 지원	제조업체의 안정적인 기술 지원 여러 사용자들 간의 정보 공유 오픈 소스 여부
구축 비용	라이선스 정책 및 비용 유지관리 비용 총 소유 비용(TCO)

오픈 소스 사용에 따른 고려사항

누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 것으로 라이선스의 종류, 사용자 수. 기술의 지속 가능성 등을 고려해야 한다.

요구사항

제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다. 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공, 개발하려는 소프트웨어의 전반적인 내용 확인. 이후 과정의 목표와 계획을 수립하는데 활용

요구사항의 유형

기능 요구사항	시스템이 어떤 기능을 하는 지에 대한 사항 시스템이 어떤 데이터를 저장하거나 연산을 수행하는 지에 대한 사항 사용자가 시스템을 통해 제공받기를 원하는 기능
비기능 요구사항	시스템 장비 구성 요구사항, 성능 요구사항, 인터페이스 요구사항, 데이터 요구사항, 테스트 요구사항, 보안 요구사항, 품질 요구사항, 제약사항, 프로젝트 관리 요구사항, 프로젝트 지원 요구사항
사용자 요구사항	사용자 관점에서 본 시스템이 제공해야 할 요구사항
시스템 요구사항	개발자 관점에서 본 시스템 천체가 사용자와 다른 시스템에 제공해야 할 요구사항 소프트웨어 요구사항이라고도 함

요구사항 개발 프로세스

요구공학의 한 요소, 개발 프로세스 진행 전에 타당성 조사가 선행되어야 한다.(도출→분석→명세→확인)

요구사항 도출(요구사항 수집)

소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계. 이해관계자가 식별되고 다양한 이해관계자 간의 효율적인 의사소통 중요. 요구사항이 어디에 있고 어떻게 수집할 것인지 식별하고 이해하는 단계. 소프트웨어 개발 생명 주기 동안 지속적으로 반복(청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등)

요구사항 분석

소프트웨어 개발의 실제적인 첫 단계. 요구사항 중 명확하지 않거나 모호한 부분을 발견하고 걸러내고 문서화(명세화)하는 과정. 타당성 조사, 비용과 일정에 대한 제약 설정. 서로 상충되는 요구사항을 중재하는 과정. 소프트웨어의 범위 파악, 주변 환경과 상호 작용하는 방법을 이해(자료 흐름도(DFD), 자료 사전(DD) 등)

구조적 분석 기법

자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법. 도형 중심의 분석용 도구와 분석 절차 이용. 하향식 방법을 사용하여 시스템 세분화하여 분석의 중복 배제. 시스템 개발의 모든 단계에서 필요한 명세서 작성 가능(자료 흐름도, 자료 사전, 소단위 명세서, 개체 관계도, 상태 전이도, 제어 명서 등)

자료 흐름도(DFD)(자료 흐름 그래프, 버블 차트)

자료의 흐름 및 변환 과정과 기능을 도형 중심으로 단계적으로 세분화하여 기술. 자료는 처리(프로세스)를 거쳐 변환될 때마다 새로운 이름이 부여, 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출

자료 흐름도에서 사용하는 기호(Yourdon/DeMacro 표기법이 주로 사용됨)

자료 사전(DD)

자료 흐름도에 있는 자료를 더 자세히 정의하고 기록(메타 데이터)

=	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
( )	자료의 생략 : 생략 가능한 자료(Optional)
[ | ]	자료의 선택 : 또는(or)
{ }	자료의 반복 : Iteration of {}n : n번 이상 반복. {}n : 최대로 n번 반복. {}nm : m이상 n이하로 반복
* *	자료의 설명 : 주석(comment)

요구사항 분석을 위한 CASE(자동화 도구)

요구사항을 자동으로 분석하고, 분석 명세서를 기술하도록 개발된 도구. 표준화와 보고를 통한 문서화 품질 개선. 결함, 생략, 불일치 등의 발견 용이성, 변경이 주는 영향 추적의 용이성. 명세에 대한 유지보수 비용의 축소. 자동화 도구의 종류에는 SADT, SREM, PSL/PSA, TAGS, EPOS 등이 있다.

SADT(Structured Analysis and Design Technique)

SoftTech 사에서 개발. 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계에 사용. 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택

SREM(Software Requirements Engineering Methodology)(RSL/REVS)

TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발. RSL과 REVS를 사용

RSL : 요소(개체와 개념), 속성(요소를 수정하거나 수식), 관계(개체들 간의 관계), 구조(정보 흐름)들을 기술하는 요구사항 기술 언어

REVS : RSL로 기술된 요구사항들을 자동으로 분석하여 명세서를 출력하는 요구사항 분석기

PSL/PSA

미시간 대학에서 개발. PSL와 PSA를 사용.

PSL : 요구사항(문제) 기술 언어

PSA : PSL로 기술된 요구사항들을 자동으로 분석하여 다양한 보고서를 출력하는 문제분석기

HIPO(Hierarchy Input Process Output)

시스템의 분석 및 설계나 문서화할 때 사용. 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타냄. 기본 시스템 모델은 입력, 처리, 출력으로 구성. 하향식 소프트웨어 개발을 위한 문서화 도구. 기호, 도표 등을 이용. 체계적인 문서 관리, 변경, 유지보수가 용이. 기능과 자료의 의존 관계를 동시에 표현.

HIPO Chart

시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것. 

가시적 도표(도식 목차) : 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree)구조도

총체적 도표(총괄도표, 개요 도표) : 프로그램을 구성하는 기능을 기술. 입력, 처리, 출력에 대한 전반적인 정보를 제공

세부적 도표(상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술

요구사항 명세

모델을 작성하고 문서화. 기능 요구사항은 빠짐없이 명확하게 기술, 비기능 요구사항은 필요한 것만 명확하게 기술. 잘못된 부분이 확인될 경우 그 내용을 추적할 수 있어야 함. 구체적 명세를 위해 소단위 명세서 사용 가능(정형 명세 기법, 비정형 명세 기법)

요구사항 확인(요구사항 검증)

개발 자원을 요구사항에 할당하기 전에 요구사항 명세서를 검토하는 과정. 이해관계자들이 검토. 개발 완료 후 문제가 생겨 재작업 비용이 발생하는 것을 방지. 모든 문제를 확인할 수 있는 것은 아님. 요구사항 정의 문서들에 대해 형상 관리 수행

UML(Unified Modeling Language)

시스템 개발 과정에서 상호간의 원할한 의사소통이 이루어지도록 표준화한 대표적인 객체지향 모델링 언어. UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있다. 구성 요소로 사물, 관계, 다이어그램 등이 있다.

사물(Things)

모델을 구성하는 가장 중요한 기본 요소. 다이어그램 안에서 관계가 형성될 수 있는 대상.

구조 사물 (Structural Things)	시스템의 개념적, 물리적 요소를 표현 클래스, 유스케이스, 컴포넌트, 노드 등
행동 사물 (Behavioral Things)	시간과 공간에 따른 요소들의 행위를 표현 상호작용, 상태 머신 등
그룹 사물 (Grouping Things)	요소들을 그룹으로 묶어서 표현 패키지
주해 사물 (Annotation Things)	부가적인 설명이나 제약조건 등을 표현 노트(note)

관계(Relationship)

사물과 사물 사이의 연관성을 표현

연관(Association) 관계

2개 이상의 사물이 서로 관련되어 있음을 표시. 사물 사이를 실선으로 연결하고, 방향성은 화살표로 표현. 양방향일 경우 화살표 없이실선으로만 연결. 연관에 참여하는 객체의 개수를 의미하는 다중도를 선 위에 표기

1	1개의 객체가 연관되어 있다.
n	n개
0..1	없거나 1개만 존재
0..* 또는 *	없거나 다수
1..*	적어도 1개 이상
n..*	적어도 n개 이상
n..m	최소 n개 ~ 최대m개

연관(Association) 관계

집합(Aggregation) 관계

하나의 사물이 다른 사물에 포함되어 있는 관계. 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적이다. 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현

집합(Aggregation) 관계

포함(Composition) 관계

포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계. 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립될 수 없고 생명주기를 함께한다. 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현

포함(Composition) 관계

일반화(Generalization) 관계

하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현. 보다 일반적인 개면을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다. 상위 항목 쪽으로 속이 빈 화실표를 연결하여 표현

일반화(Generalization) 관계

의존(Dependency) 관계

필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계. 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계. 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우. 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현

의존(Dependency) 관계

실체화(Realization) 관계

사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계. 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계. 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현

실체화(Realization) 관계

다이어그램(Diagram)

사물과 관계를 도형으로 표현. 여러 관점에서 가시화한 뷰(View)를 제공. 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용한다.

구조적(Structural) 다이어그램의 종류

클래스 다이어그램 (Class Diagram)	클래스와 클래스가 가지는 속성, 클래스 사이의 관계 표현. 시스템 구조 파악 및 구조상의 문제점 도출
객체 다이어그램 (Class Diagram)	특정 시점의 객체(클래스에 속한 사물, 인스턴스)와 객체 사이의 관계 표현. 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용
컴포넌트 다이어그램 (Class Diagram)	컴포넌트 간의 관계나 인터페이스를 표현. 구현 단계에서 사용
배치 다이어그램 (Class Diagram)	물리적 요소(결과물, 프로세스, 컴포넌트 등)들의 위치를 표현. 노드와 의사소통(통신) 경로로 표현. 구현 단계에서 사용
복합체 구조 다이어그램 (Class Diagram)	클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
패키지 다이어그램 (Class Diagram)	유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현

행위(Behavioral) 다이어그램의 종류

유스케이스 다이어그램 (Use Case Diagram)	사용자의 요구를 분석. 기능 모델링 작업에 사용. 사용자(Actor)와 사용 사례(Use Case)로 구성. 사용 사례 간에 여러 형태의 관계로 이루어짐
시퀀스 다이어그램 (Sequence Diagram)	상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
커뮤니케이션 다이어그램 (Communication Diagram)	메시지 뿐만 아니라 객체들 간의 연관까지 표현
상태 다이어그램 (State Diagram)	하나의 객체가 자신이 속한 클래스의 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현. 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용
활동 다이어그램 (Activity Diagram)	객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
상호작용 개요 다이어그램 (Interaction Overview Diagram)	상호작용 다이어그램 간의 제어 흐름을 표현
타이밍 다이어그램 (Timing Diagram)	객체 상태 변화와 시간 제약을 명시적으로 표현

스테레오 타입

UML에서 표현하는 기본 기능 외의 추가적인 기능을 표현하기 위해 사용. 길러멧(Guilemet)이라고 부르는 겹화살괄호(<<>>) 사이에 표현할 형태를 기술

<<include>>	연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
<<extend>>	연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
<<interface>>	인터페이스를 정의하는 경우
<<exception>>	예외를 정의하는 경우
<<constructor>>	생성자 역할을 수행하는 경우

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

사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을사용자의 관점에서 표현. 외부 요소와 시스템 간의 상호작용 확인. 사용자의 요구사항 분석. 시스템의 범위 파악

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

시스템(System) / 시스템 범위(System Scope)	시스템 내부 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위 표현
액터(Actor)	시스템과 상호작용하는 모든 외부 요소(사람, 외부시스템). 주액터 : 시스템을 사용함으로써 이득을 얻는 대상(주로 사람) 부액터 : 주액터에게 서비스를 제공하는 외부시스템(조직이나 기관 등)
유스케이스(Use Case)	사용자 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현
관계(Relationship)	액터와 유스케이스, 유스케이스와 유스케이스 사이의 관계를 나타냄(포함 관계, 확장 관계, 일반화 관계)

클래스(Class) 다이어그램

클래스(시스템 구성), 속성(클래스의 특성), 오퍼레이션(클래스의 특성), 제약조건, 클래스 사이의 관계를 표현. 시스템을 구성하고 있는 요소에 대해 이해할 수 있는 구조적 다이어그램. 시스템 구성 요소를 문서화. 시스템을 모델링하는 데 자주 사용

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

클래스(Class)	각각의 객체들이 갖는 속성과 오퍼레이션(함수, 메서드)을 표현 3개의 구획(Compartment)으로 나눠 클래스의 이름, 속성(클래스의 상태나 정보), 오퍼레이션 (클래스가 수행할 수 있는 동작)표기
제약조건	속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건
관계(Relationship)	클래스와 클래스 사이의 연관성(연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계)

접근제어자

속성과 오퍼레이션에 동일하게 적용

public	+	어떤 클래스에서라도 접근 가능
private	-	해당 클래스 내부에서만 접근 가능
protected	#	동일 패키지 내의 클래스 또는 해당 클래스를 상속 받은 외부 패키지의 클래스에서 접근 가능
package	~	동일 패키지 내부에 있는 클래스에서만 접근 가능

시퀀스(Sequence) 다이어그램

시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현. 각 동작에 참여하는 시스템이나 객체들의 수행 기간 확인. 클래스 내부에 있는 객체들을 기본 단위로 사용. 유스케이스 명세서를 하나의 표현 범위로 하지만, 하나의 클래스에 포함된 오퍼레이션을 하나의 범위로 표현하기도 함

시퀀스 다이어그램 구성 요소

액터(Actor)	시스템으로부터 서비스를 요청하는 외부요소(사람, 외부 시스템)
객체(Object)	메시지를 주고받는 주체
생명선(Lifeline)	객체가 메모리에 존재하는 기간, 객체 아래쪽에 점선을 그어 표현
실행 상자(Active Box)	객체가 메시지를 주고받으며 구동되고 있음을 표현
메시지(Message)	객체가 상호 작용을 위해 주고받는 메시지