[정보처리기사 필기] 기출문제 - 001 ~ 050. 오답노트

1. 소프트웨어 설계 시 구축된 플랫폼의 성능특성 분석에 사용되는 측정 항목

• 응답시간 : 사용자 측면에서 응답시간이 성능 목표 기준, 응답시간은 업무 처리에 소요되는 시간
• 업무량/처리량 : 업무 피크 시간 동안에 시스템이 처리해야 하는 단위 시간당 최대 업무 처리 건수
• 가용성 : 시스템이 정상적으로 사용 가능한 시간
• 사용률 : CPU, 메모리, 디스크, 네트워크 등의 사용비율

2. 플랫폼의 개념

• 소프트웨어의 가동을 위해 하드웨어, 소프트웨어, 네트워크 등 다양한 주변기기 등이 결합하여 있으며 제작된 소프트웨어에 대해 언제, 어디서나 실행 시키더라도 쉽게 구동시킬 수 있음
• 응용 소프트웨어 개발과 활용 등의 생산성 향상에 많은 도움을 줌
• 대표적인 플랫폼 사례 : 클라우드 플랫폼, 앱스토어 모바일 플랫폼, 정보를 제공해주는 검색 포털, 빅데이터 플랫폼인 하둡
• 자신의 시스템을 개방하여 개인, 기업할 것 없이 모두가 참여하여 원하는 일을 자유롭게 할 수 있도록 환경을 구축하여 플랫폼 참여자들 모두에게 새로운 가치와 혜택을 제공해 줄 수 있는 시스템을 의미

7. OSI 7 Layer 

계층	설명	주요 프로토콜	단위
응용 계층	사숑자와 네트워크 간의 응용 서비스 연결, 데이터 생성	HTTP, TELNET, DHCP, DNS, FTP, SSH, SMTP, SNMP	Data
표현 계층	데이터의 형식 설정과 부호 교환, 암호화, 해독	MIME, TLS, SSL, JPEG, MPEG, SMB, AFP	Data
세션 계층	응용 프로세스 간의 연결 접속 및 동기 제어	SSH, TLS, RPC	Data
전송 계층	• 프로세스 간 논리적 통신 서비스 제공 • 패킷들의 전송유효 확인, 실패한 패킷은 재전송하여 신뢰성 있는 통신 보장	TCP (3-Way Handshaking), UDP, SCTP, RTP	Segment
네트워크 계층	단말 간 시스템끼리 Data를 전송하기 위한 최선의 통신경로 선택을 제공	IP, ARP, ICMP, IGMP, IPses	Packet
데이터링크 계층	• 인접 시스템 간의 데이터 전송, 전송 오류 제어 (Frame) • 오류검출 / 재전송 / 흐름제어	Ethernet, ATM, PPP	Frame
물리 계층	통신회선으로 Data를 나타내는 0과 1 비트의 정보를 회선에 내보내기 위한 정기적 변환이나 기계적 작업을 담당	RS-485, RS-232, X25/21	Bit

12. 트랜잭션의 성질

• 원자성
  • 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다는 성질
  • 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 함
• 일관성
  • 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다는 성질
  • 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 함
• 독립성, 격리성
  • 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션의 실행 중에 빠른 트랜잭션의 연산은 진행되지 않음
  • 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없게 되는 것
• 영속성, 지속성
  • 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다는 성질

14. 요구사항 개발 프로세스

• 요구사항 개발 프로세스의 순서 : 도출 (식별) → 분석 → 명세 → 확인
  • 도출(식별) : 요구사항 원천 도출 기법
  • 분석 : 요구사항 분류, 개념 모델링, 기술구조 설계, 요구사항 할당, 요구사항 협상
  • 명세 : 시스템 정의서, 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서
  • 확인 : 검토, 프로토타이핑, 모델 검증, 인수테스트

18. 설계 구조

• 상위 설계
  • 아키텍처 설계, 예비 설계
  • 시스템 수준에서의 소프트웨어 구성 컴포넌트들 간의 관계로 구성된 시스템의 전체적인 구조와 시스템 구조도, 외부 파일 및 DB 설계도 (레코드 레이아웃, ERD) 화면 및 출력물 레이아웃 등이 포함
• 하위 설계
  • 모듈 설계, 상세 설계
  • 시스템의 각 구성 요소들의 내부 구조, 동적 행위 등을 결정하며 각 구성 요소의 제어와 데이터들 간의 연결에 대한 구체적인 정의를 하는 것

19. XP의 12가지 실천사항 Practice

• Planning game
  • 사용자 스토리를 이용해서 다음 릴리스의 범위를 빠르게 결정
  • 비즈니스 우선순위와 기술적 평가가 결합
• Small / Short releases
  • 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈
  • 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은 (약 2주) 사이클로 볼 수 있도록 자주 새로운 버전 배포 유지
• Metaphor
  • 공통의 name system : 의사 소통 및 공통 개념 공유
  • 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것, 이해하기 쉬운 스토리로 이루어짐
• Simple design
  • 당장 필요하지 않은 디자인 배제
  • 항상 가능한 가장 간결한 디자인 상태 유지
• TDD Test Driver Development
  • 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야 하는지를 스스로 깨우침
  • 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인
• Refactoring Design Improvement
  • 프로그램 기능은 변경 없이 중복 / 복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템 재구성
• Pair programming
  • 두 사람이 함께 프로그램 Driver/Partner
  • 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업 진행
• Collective Code Ownership
  • 팀의 모든 프로그래머가 소스코드에 대하여 공동 책임을 지는 것
  • 시스템에 있는 코드는 누구든지 언제라도 수정 가능함
• CI Continuous Integration
  • 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때마다 지속적으로 통합되고 동시에 테스트
• 40-hour-week Sustainable Pace
  • 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버타임하지 않도록 함
• Whole Team
  • 개발 효율성을 위해 고객을 프로젝트에 상주시킴
  • 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할
• Coding Standard
  • 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함

21. DBC의 세 가지 유형

• 선행조건
  • 루틴(함수/메소드/모듈)이 호출되기 위해 참이어야 하는 것 (루틴의 요구사항)
  • 루틴의 선행조건이 위반된 경우 루틴이 호출되어서는 안 됨
  • 제대로 된 데이터를 전달하는 것은 호출 쪽의 책임
• 후행조건
  • 루틴이 자기가 할 것이라고 보장하는 것
  • 루틴이 수행된 후 만족하여야 하는 조건
• 클래스 불변
  • 호출자의 입장에서 볼 때는 이 조건이 언제나 참이라고 클래스가 보장
  • 루틴의 내부 처리 중에는 불변식이 참이 아닐 수도 있지만, 루틴이 종료하고 호출자로 제어권이 반환되는 때에는 불변식이 참이 되어야 함
  • 불변식에 대해서는 어떤 데이터 멤버에게도 클래스가 제한 없는 쓰기 접근권을 줄 수 없음

22. UML의 관계

• 실체화
  • 객체들 사이의 의미적 관계로서 한 객체가 다른 객체의 계약을 지정
  • 의존과 일반화의 혼합, 표기버비도 의존과 일반화에서 참고함
  • 인터페이스와 인터페이스에 오퍼레이션이나 서비스를 제공하는 클래스나 컴포넌트 사이의 관계를 지정하기 위해 사용
• 일반화
  • 일반화된 사물과 좀 더 특수화된 사물과의 관계 (is-kind-of 단계)
  • 자식 객체가 부모 객체가 사용되는 어느 곳에서나 사용될 수 있다는 것을 의미 : 그 반대는 성립하지 않음
  • 부모 자식 관계를 표현할 때 일반화를 사용
  • 주로 클래스와 인터페이스 사이에서 상속 관계를 보여주기 위해 사용
• 의존
  • 두 사물 간의 의미적 관계, 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 의미하는 개념 : 이 반대는 반드시 성립하는 것은 아님
  • 표기 : 점선으로 된 직선을 사용, 의존하고 있는 사물을 향하고 있고, 의존은 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 주로 나타남
• 연관
  • 구조적 관계로서 어느 한 사물 객체가 다른 사물 객체와 연결을 의미
  • 두 클래스가 서로 연결되어 연관이 있다면, 한쪽 객체에서 다른 쪽 객체로 이동할 수 있으며 반대도 가능
  • 한 연관의 다른 양쪽 끝이 같은 클래스를 향해 원을 그리며 순환하는 것도 가능, 쌍방 연관 (정확히 두 클래스 연관), 다수 연관 (2개 이상의 클래스 연관)
  • 이름 (방향성 가능) 과 역할을 가질 수 있으며, 객체 간 구조적 관계를 표현하기 위해 다중성을 표현하기도 함
  • 표기 : 두 클래스를 연결하는 실선

25. 요구사항 도출 기법

• 문헌조사
  • 유사 프로젝트 및 업무 문서나 양식을 조사하여 현재 시스템 정보에 대한 이해 도출
  • 그 외 산업 및 기업 표준, 관련 정부 정책, 규제 등 문서 조사
  • 개발팀은 도메인 영역 교육이나 설명서 참고
• 업무절차 및 양식조사
  • 업무 관련 문서, 절차, 양식, 운영 매뉴얼 등을 조사함으로써 업무 절차와 처리 입출력의 이해
  • 기업의 내부 표준을 검토함으로써 요구와 제한 사항을 찾아 시스템 요구 분석서의 제한 사항으로 적용
• 설문
  • 이해당사자들로부터 요구를 찾는 도구
  • 이해당사자들의 의사결정 과정에 포함하여 관심, 내부 정보, 개선 의견을 이끌어 냄
• 브레인스토밍 회의
  • 여러 명으로부터 정보를 얻는 효과적 방법
  • 인터뷰와 같이 수행하면 더 많은 정보 추출이 가능하며 훈련된 요원의 주재로 과정을 정돈하는 것이 성공의 키 포인트
  • JAD : 사용자와 개발자가 공동참여하여 프로토타입 기반의 작업을 수행함으로써 비즈니스 요구사항을 명확히 도출하고 그에 따라 시스템을 설계 및 개발

26. 요구공학의 절차

• 요구사항 도출 (식별)
  • 소프트웨어가 해결해야 할 문제를 이해하는 첫번째 단계
  • 요구사항이 어디에 있고, 어떻게 수집할 것인지와 관련된 단계
  • 이 단계에서 이해관계자가 식별되고 개발팀과 고객 사이의 관계가 만들어지며, 다양한 이해관계자와 효율적인 의사소통이 매우 중요
• 요구사항 분석
  • 요구사항들 간 상충되는 것을 해결
  • 소프트웨어 범위를 파악
  • 소프트웨어가 환경과 어떻게 상호작용하는지를 이해
  • 요구사항을 정제하여 소프트웨어 요구사항을 정리하는 업무
• 요구사항 명세
  • 요구사항을 체계적으로 검토, 평가, 승인될 수 있도록 문서를 작성하는 것을 의미
  • 시스템의 정의 및 시스템 요구사항, 소프트웨어 요구사항을 작성하는 업무
• 요구사항 확인
  • 분석가가 요구사항을 이해했는지 확인이 필요
  • 요구사항 문서가 조직의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증

27. HIPO 도표의 특징

• HIPO : 하향식 개발을 위한 시스템 분석 및 설계 문서화 도구
• 시스템 분석용 디자인 도구 및 문서화 기법
• 시스템을 표현하는 모듈들을 계층적으로 나타내고 각 모듈들을 문서화하기 위해 사용
• Input-Process-Output으로 이루어진 모듈을 계층적으로 나타낸 도표
• HIPO 도표의 유형
  • 가시적 도표 Visual Table of Contents : 시스템의 전체적인 기능과 흐름을 보여주는 Tree 형태의 구조도
  • 총체적 도표 Overview Diagram : 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
  • 새부적 도표 Detail Diagram : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

30. 요구사항 분석과 요구사항 명세서

• 요구사항 분석
  • 문제인식 : 사용자와 면담, 설문 조사 및 협조, 각종 문서 검토 등을 통행 요구사항 수집
  • 평가와 종합 : 추출된 요구사항에 대한 정보를 평가하고 여러 가지 해결책을 종합
  • 모델 제작 : 평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성
  • 문서화와 검토 : 소프트웨어의 기능, 성능, 제약 조건 등에 대하여 명세 후 검토
• 요구사항명세서
  • 요구사항 분석 단계에서 분석된 여러 결과를 바탕으로 소프트웨어의 기능, 제약 조건, 성능, 참조 자료 등을 기술한 문서
  • 요구사항 분석서와 혼용하여 사용하기도 함

31. 요구공학의 절차

• 요구사항 도출 (식별)
  • 소프트웨어가 해결해야 할 문제를 이해하는 첫번째 단계
  • 요구사항이 어디에 있고, 어떻게 수집할 것인지와 관련된 단계
  • 이 단계에서 이해관계자가 식별되고 개발팀과 고객 사이의 관계가 만들어지며, 다양한 이해관계자와 효율적인 의사소통이 매우 중요
• 요구사항 분석
  • 요구사항들 간 상충되는 것을 해결
  • 소프트웨어 범위를 파악
  • 소프트웨어가 환경과 어떻게 상호작용하는지를 이해
  • 요구사항을 정제하여 소프트웨어 요구사항을 정리하는 업무
• 요구사항 명세
  • 요구사항을 체계적으로 검토, 평가, 승인될 수 있도록 문서를 작성하는 것을 의미
  • 시스템의 정의 및 시스템 요구사항, 소프트웨어 요구사항을 작성하는 업무
• 요구사항 확인
  • 분석가가 요구사항을 이해했는지 확인이 필요
  • 요구사항 문서가 조직의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증

32. 객체지향 프로그래밍 OOP

• 객체지향 프로그래밍의 개념
  • 컴퓨터 프로그래밍의 패러다임 중 하나로 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위
  • 객체들의 모임으로 파악하고자 하는 것
  • 각각의 객체는 메시지를 주고 받고, 데이터를 처리할 수 있음
  • 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용됨
  • 소프트웨어 개발과 보수를 간편하게 하며 보다 직관적인 분석을 가능하게 하는 장점을 가짐
• 객체지향 프로그램의 구성
  • 메서드 : 객체가 수행하는 기능, 객체가 갖는 데이터(속성, 상태)를 처리하는 알고리즘
  • 객체 : 클래스의 인스턴스, 자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행
  • 클래스 : 공통된 특성과 연산을 갖는 객체의 집합, 같은 종류의 집단에 속하는 속성과 행위를 정의한 것
  • 메시지 : 객체들 간 상호작용을 하는데 사용되는 수단, 객체에게 행위 지시를 하는 명령으로 객체 간의 통신

33. 객체 지향의 특징

• 캡슐화
  • 속성(데이터)과 메서드(연산)를 하나로 묶어서 객체로 구성
  • Readability 향상 : 유지보수 용이
  • 재사용성이 높은 S/W 개발 가능
  • 내부 자료의 일관성 유지
  • 객체 간 인터페이스 이용, 종속성 최소화
• 추상화
  • 공통 성질을 추출하여 슈퍼클래스로 구성
  • 객체 중심의 안정된 모델을 구축
  • 현실 세계를 자연스럽게 표현
  • 분석의 초점이 명확해짐
• 다형성
  • 동일한 이름의 여러 오퍼레이션(메서드)을 다른 사양으로 정의 가능
  • 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분
  • 오버라이딩 : 부모클래스의 메서드를 재정의
• 정보은닉
  • 캡슐화된 항목을 다른 객체로부터 감춤
  • 메시지 전달에 의해 다른 클래스 내의 메서드가 호출
• 상속성
  • 부모클래스의 속성과 메서드를 상속받아 사용
  • 부모와 자식 클래스 간의 관계가 슈퍼클래스와 서브 클래스로 유지

34. 객체지향 분석

• 사용자의 요구사항을 분석하여 요구되는 사항과 관련된 모든 객체, 클래스와 연관된 속성, 연산, 관계 등을 정의하여 모델링하는 작업
• 객체지향 분석의 목적은 클래스를 식별하는 것
• 클래스, 객체, 속성, 연산 등을 표현해서 문제를 모형화
• 객체지향 관점은 모형화 전후 단계에서 객체의 분류, 속성들의 상속, 메시지의 통신, 연산 등을 결합한 것
• 인스턴스화 : 인스턴스는 추상화, 클래스, 객체, 프로세스 등이 실제로 구현된 것
• 객체지향 방법론 중 Coad와 Yourdon 방법은 E-R 다이어그램을 사용하여 객체의 행위를 모델링

35. 객체지향 분석 방법론

• Rumbaugh 방법 OMT
  • 객체모델링
    • 정보 모델링
    • 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정
    • 실세계 문제 영역으로부터 객체와 클래스를 추출해 그들 간의 관계를 연관화, 집단화, 일반화 중심으로 규명 
    • 클래스의 속성과 연산을 함께 표현함으로써 시스템의 정적 구조를 생성
  • 동적모델링
    • 상태 다이어그램을 사용하여 시스템의 행위를 기술하는 모델링
  • 기능모델링
    • 자료 흐름도 DFD를 이용
    • 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현
    • 어떤 데이터를 입력하면 어떤 결과를 구할 것인지 표현
• Booch 부치 방법
  • 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 포함하여 사용
  • 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의
  • 클래스와 객체의 의미를 식별, 클래스와 객체들의 관계를 식별, 클래스와 객체를 구현
  • 각 작업에 대한 다이어그램, 클래스 계층 정의, 클래스들의 클러스터링 작업을 수행
  • Use Case를 강조하여 사용하는 분석 방법
• Coad와 Yourdon 방법
  • 객체지향 분석 방법론 중 E-R 다이어그램을 사용하여 객체의 행위를 모델링
  • 객체 식별, 구조식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성
• Wirfs-Brock 워프스 브록 방법
  • 분석과 설계 간의 구분이 없고 고객 명세를 평가해서 설계 작업까지 연속적으로 수행하는 기법

36. Rumbaugh 방법의 설계 순서

• 입출력 결정
• 자료 흐름도 작성 : 기능 의존 관계를 서술
• 기능의 내용을 상세히 기술
• 제약사항을 결정하고 최소화

37. 자료사전

• 자료 사전 작성 시 고려 사항
  • 갱신하기 쉬워야 함
  • 이름으로 정의를 쉽게 찾을 수 있어야 함
  • 정의하는 방식이 명확해야 함
• 자료 사전의 기호 
  • = : 자료의 정의, A는 -로 구성되어 있다
  • + : 자료의 연결, A와 B를 연결
  • ( ) : 자료의 생략, 없어도 되는 자료
  • [ | ] : 자료의 선택, A이거나 B
  • { } : 자료의 반복
  • ** : 자료의 설명

39. 자료흐름도

구성요소	의미
처리	입력된 자료를 출력으로 변환하는 것, 프로세스라고 하고 원 안에 처리 명칭을 기술
차료 흐름	발생지, 종착지, 처리 및 저장소 사이에서 자료의 흐름을 나타냄, 화살표 위에 자료의 명칭 기술
자료 저장소	시스템 상의 자료 저장소를 나타냄, 평행선 안에 자료 저장소 명칭을 기술
단말기	시스템에 필요한 자료가 입력되는 발생지와 시스템에서 처리된 자료가 출력되는 종착지 또는 외부에 존재하는 사람이나 조직을 나타냄, 사각형 안에 발생지나 종착지 명칭 기술

40. 요구사항

요구사항 정형 및 비정형 명세 기법 요약
구분	정형명세	비정형명세
기법	수학적 기반 / 모델링 기반	상태 / 기능 / 객체 중심 명세 기법
종류	Z, VDM, Petri-Net (모형기반), CSP, CCS, LOTOS(대수적방법)	FSM, Decision Table, ER 모델링, State Chart(SADT), UseCase-사용자 기반 모델링
장점	시스템 요구특성 정확, 명세 간결, 명세 구현의 일치성	명세작성 이해 용이, 의사전달 방법 다양성
단점	낮은 이해도, 이해 관계자의 부담 가중	불충분한 명세 기능, 모호성

기법	설명
상태모형 기반 (모델 기반)	• 시스템을 상태모형으로 인식, 집합과 수열 등의 수학적 요소로 표현 • 시스템의 오퍼레이션(연산)들이 시스템 상태를 어떻게 변화시키는가에 초점 • 시스템 연산이 어떻게 시스템 모델의 상태에 영향을 미치는지를 정의
	Z	• 집합론 (Set Theory), 논리, 모델기반 명세기법 • 논리를 기반으로 한 Calculus적 표현을 사용하여 여러 특성을 VDM보다 함축적으로 표현 • 모든 특성을 스키마 안에 순서대로 기술하여 모듈화와 재사용성이 우수 • Z스키마 구조 : 스키마 이름, 스키마 시그니처, 스키마 술어 • 모듈 간의 재사용성 우수 • 스키마 간의 연산 가능
	VDM	• 시스템의 비기능적인 요구사항을 제외한 기능적인 요구사항에만 한정 • 이와 관련된 기능 요구 명세와 검증 설계에 관해 적절한 표기법인 검증 방법을 제공
	Decision Table	• 복잡한 의사결정논리를 기술하는데 사용 • 판단표는 4개의 4분원으로 구성
	Event Table	여러 사건이 상이한 조건으로 발생하였을 때 취해야 할 행위를 기술
	Transition Table	시스템 내의 상태 변화를 기술하는데 사용
	FSM	• 컴퓨터 프로그램과 전자 논리회로를 설계하는데 쓰이는 수학적 모델 • 유한한 개수의 상태로 구성된 하나의 기계를 의미 • 일종의 Flow chart로서 조금 다른 점은 닫혀있다는 것, 모든 게임은 단발로 끝나는 게 아니라 영원히 도는 프로그램
	Petri Net	그래프에 의한 표기법을 제공, 병렬 처리를 기술할 때 유한상태기계의 한계성을 극복하도록 고안
대수학적 기반	• 오퍼레이션들과 이들 사이의 관계로 시스템을 표현 • 시스템을 분할한 서브시스템들의 인터페이스로 간주 • 클래스나 추상 데이터 타입을 오퍼레이션 사이의 관계들로 정의한 것과 유사 • 대수명세는 객체 연산이 객체 상태와 독립적이면 인터페이스를 정의하는데 이용될 수 있음, 연산을 적용한 결과는 앞의 연산과 무관

44. UML 관계의 종류

클래스 간 관계	설명	표기법	예시 코드
의존 관계	• 연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 나타남 • 연관 관계와 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같은, 매우 짧은 시간만 유지된다는 점	점선 화살표 : class A의 메서드가 class B의 메서드를 호출하거나 class B를 메서드의 인자로 받는 등 사용	public class Car_A {    public void dolt(GPmp_B gp){       gp.charge();    } } public class GPmp_B {    public void charge(){ …. } }
연관 관계	• 클래스들이 개념상 서로 연결됐음을 나타냄 • 보통은 한 클래스가 다른 클래스에서 제공하는 기능을 사용하는 상황일 때 표시	실선 또는 화살표	class A가 class B를 멤버 변수로 가지고 있고 사용하는 경우 public class Person_A {    private Car_B car:    public void dolt(){car.dolt();} } public class Car_B {public void dolt(){ …. }}
일반화 관계	• 객체지향 개념에서 상속관계라고 함 • 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 이를 IS-A 관계라고 함 • UML에서는 일반화 관계로 모델링	속이 빈 화살표	class A가 Super Class class B가 Sub Class public class SuperClass_A{} public class Class_B extends SuperClass_A {}
실체화 관계	• 책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계를 나타냄	빈 삼각형과 점선	interface A가 있고, class B가 interface A를 구현한 경우 public interface Interface {    pulic void implMethod(); } public class implClass_B implements Interface {    @Override    public void implMethod() { …. } }
집합 관계	• 클래스들 사이의 전체 또는 부분 같은 관계를 나타냄 • 전체 객체의 라이프 타임과 부분 객체의 라이프 타임은 독립적 • 전체 객체가 사라져도 부분 객체는 남아 있음	속이 빈 다이아몬드	class A가 class B를 멤버 변수로 가지고 있는 경우 (new)를 하지 않음 public class Person_A {    private Addr_B addr;    public Person_A(Addr addr)    {this.addr = addr;}    …. } public class Addr_B{ … }
합성 관계	• 클래스들 사이의 전체 또는 부분과 같은 관계를 나타냄 • 전체 객체의 라이프 타임과 부분 객체의 라이프 타임과 부분 객체의 라이프 타임이 의존적 • 전체 객체가 사라지면 부분 객체도 함께 사라짐	속이 찬 다이아몬드	class A가 class B를 멤버 변수로 가지고 있는 경우 (new로 생성함) public class Car_A {    Engine_B e = new Engine_B();    …. } public class Engine_B {…}

45. 집단 관계의 구분 

• 생명 주기의 일치화 여부에 따라 집합과 합성 두 개의 관계로 구분

집합 관계	• 클래스들 사이의 전체 또는 부분 같은 관계를 나타냄 • 전체 객체의 라이프 타임과 부분 객체의 라이프 타임은 독립적 • 전체 객체가 사라져도 부분 객체는 남아 있음	속이 빈 다이아몬드	class A가 class B를 멤버 변수로 가지고 있는 경우 (new)를 하지 않음 public class Person_A {    private Addr_B addr;    public Person_A(Addr addr)    {this.addr = addr;}    …. } public class Addr_B{ … }
합성 관계	• 클래스들 사이의 전체 또는 부분과 같은 관계를 나타냄 • 전체 객체의 라이프 타임과 부분 객체의 라이프 타임과 부분 객체의 라이프 타임이 의존적 • 전체 객체가 사라지면 부분 객체도 함께 사라짐	속이 찬 다이아몬드	class A가 class B를 멤버 변수로 가지고 있는 경우 (new로 생성함) public class Car_A {    Engine_B e = new Engine_B();    …. } public class Engine_B {…}

46. 유즈케이스 다이어그램

• 포함 : 반드시 수행해야 하는 관계
• 확장 : 수행할 수도 있는 관계

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

• 액터
  • 시스템의 외부에 있고 시스템과 상호작용을 하는 사람 (시스템의 기능을 사용하는 사람)
  • 시스템(시스템에 정보를 제공하는 또 다른 시스템)을 의미
• 유즈케이스
  • 사용자 입장에서 바라본 시스템의 기능
  • 시스템이 액터에게 제공해야 하는 기능을 시스템의 요구사항으로 나타냄
• 관계
  • 포함관계
    • 하나의 유즈케이스가 다른 유즈케이스 (포함 대상)의 실행을 전제로 할 때 형성되는 관계
    • 포함 대상 유즈케이스를 반드시 실행되어야 하는 경우에 적용
    • 포함되는 유즈케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기
  • 확장관계
    • 하나의 유즈케이스와 다른 유즈케이스 (확장 대상) 사이에 형성되는 관계
    • 특정 조건에 따라 확장 대상 유즈케이스를 수행하는 경우에 적용
    • 확장 대상 유즈케이스 반대 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기

50. UML 다이어그램의 종류

• 구조적 다이어그램
  • class
    • 시스템 내 클래스들의 정적 구조를 표현
    • 클래스는 객체들의 집합으로 속성과 동작으로 구성
  • object
    • 클래스의 여러 객체 인스턴스를 나타내는 대신 실제 클래스를 사용
    • 관계 있는 모든 인스턴스를 표현
  • component
    • 코드 컴포넌트에 바탕을 둔 코드의 물리적 구조 표현
    • 컴포넌트는 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보를 포함하고 실질적인 프로그램 작업에 사용
  • depolyment
    • 시스템 하드웨어와 소프트웨어 간의 물리적 구조를 표현
    • 실질적인 컴퓨터와 디바이스 간의 관계를 표현하는데 이용
    • 컴포넌트 사이의 종속성을 표현
  • package UML 2.0
    • 시스템 계층적인 구조 표현
    • 클래스들로 이루어진 패키지와 그들 간의 의존 관계를 보여줌
  • composite Structure UML 2.0
    • 전체 클래스 안에 각 컴포넌트 클래스 표현
    • 클래스 내부 구조 파악에 용이
• 행위 다이어그램
  • use case
    • 사용자의 입장에서 본 시스템의 행동 표현
    • 유즈케이스는 시스템의 기능적인 요구를 정의
  • state
    • 클래스의 객체가 가질 수 있는 모든 가능한 상태와 상태 간의 전이를 표현
    • 진입조건, 탈출조건, 상태전이에 필요한 사건 등 자세한 사항이 기술
    • 설계단계에서 클래스 객체의 동적인 행동 방식을 표현하는데 사용
  • activity
    • 행위의 순서적 흐름을 표시
    • 순서도나 병렬적인 처리를 요하는 행위를 표현할 때 사용
• 상호작용 다이어그램
  • sequence
    • 객체와 객체 간의 상호작용을 메시지 흐름으로 표시
    • 오브젝트 사이에 메시지를 보내는 시간, 순서를 보여주기 위해 사용
  • communication
    • 상호작용에 참여하는 객체, 컴포넌트 간의 관계를 명시적으로 표현
  • interaction overview UML 2.0
    • 활동 다이어그램과 시퀀스 다이어그램 혼합
    • 상호작용에 대한 제어흐름을 표현
  • timing UML 2.0
    • 시간적 제약과 객체상태의 변화를 표현
    • 인스턴스 간의 상태 전이와 상호작용을 시간 제약으로 표현