정처기 소프트웨어 설계 - 1.1 요구사항 확인

<소프트웨어 생명주기> ★★★★

: 소프트웨어 개발 단계, 각 단계별 주요 활동, 활동의 결과에 대한 산출물로 표현

소프트웨어 생명주기 표현하는 형태 
= 소프트웨어 생명 주기 모형 = 소프트웨어 프로세스 모형 = 소프트웨어 공학 페러다임

(1) 폭포수 모형(Waterfall Model) 
- 이전 단계로 돌아갈 수 x 전제. 
- 각 단계를 확실히 매듭짓고, 결과를 철저하게 검토하여 승인과정을 거친 후, 다음 단계 진행
- 소프트웨어 공학에서 가장 오래되고, 폭넓게 사용도는 전통적인 소프트웨어 생명주기 모형
- 고전적 생명주기 모형
- 선형적 순차적 모형 : 한 단계가 끝나야만 다음 단계로 넘어갈 수 o. 결과물이 명확하게 산출되어야 넘어갈 수 o
- 제품의 일부가 될 메뉴얼을 작성해야 함. (계획, 문서(메뉴얼) 개발 중심)
- 두 개 이상 과정 병행 수행x
- 단점 : 개발이 완료된 시점에서 오류 발견 (마지막에 모든 기능 테스트)

(2) 프로토타입 모형(Prototype Model)
- 사용자의 요구사항을 정확히 파악하기 위해 견본품(Prototype)을 만들어 최종 결과물 예측하는 모형
- 견본품(시제품)은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
- 폭포수 모형 단점 보완

(3) 나선형 모델(Spiral Model, 점진형 모형)
- 보헴(Boehm)이 제안
- 폭포수 모형 장점 + 프로토타입 모형 장점 + 위험 분석 기능
- 여러번의 소프트웨어 개발 과정 --> 점진적으로 완벽한 최종 소프트웨어 개발하는 것
- 위험을 관리하고 최소화 하는 것 목적. 위험성 평가 의존
- 누락되거나 추가된 요구사항 첨가할 수 o
- 정밀, 유지보수 과정 필요 x
- 대규모 시스템, 소프트웨어 개발 적용

(4) 애자일 모형(Agile Model)
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 것
- 고객과의 소통에 초점을 맞춘 방법론 통칭
- 스프린트(Sprint), 이터레이션(Iteration) 짧은 개발 주기 반복. ( 반복되는 일정주기 끝날 때 마다 테스트)
- 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구 적극 수용
- 각 개발 주기에서 고객의 요구사항에 우선순위를 부여, 개발
- 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스털(Crystal), 
  ASD(Adaptive Software Development), FDD(Feature Driven Development), 
  DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery).. 

---

<스크럼(Scrum) 기법> ★★★★

(1) 스크럼의 개요
- 팀이 중심이 되어 개발의 효울성을 높인다는 의미
- 임원 스스로가 스크럼 팀을 구성해야 함. 개발 작업에 관한 모든 것을 스스로 해결 할 수 있어야 함.

(1.1) 제품 책임자(PO, Product Owner)
- 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사결정할 사람으로 선정
- 개발 의뢰자, 사용자가 담당
- 이해관계자들의 의견 종합하여 제품에 대한 요구사항을 작성하는 주체
- 백로그(제품개발에 필요한 요구사항 모아 우선순위 부여 목록) 작성, 백로그에 대한 우선순위 지정
- 팀원들 : 우선순위 지정 x, 백로그에 우선순위 추가 o
- 테스트 수행하면서 주기적으로 요구사항 우선순위 갱신

(1.2) 스크럼 마스터(SM, Scrum Master)
- 객관적인 시각에서 조언을 해주는 가이드 역할
- 팀원 통제 목표 x
- 일일 스크럼 회의 주관, 진행 사항 점검
- 개발 과정에서 발생된 장애 요소를 공론화, 처리

(1.3) 개발팀(DT, Development Team)
- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
- 보통 최대 인원 7~8명

(2) 스크럼 개발 프로세스

(2.1) 제품 백로그(Product Backlog)
- 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
- 지속적으로 업데이트
- 사용자 스토리를 기반으로 전체일정 계획인 릴리즈 계획을 수립

(2.2) 스프린트 계획 회의(Sprint Planning Meeting)
- 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
- 요구사항을 태스크라는 작업단위로 분할 후, 개발자별로 수행할 작업 목록인 스프린트 백로그 작성

(2.3) 스프린트(Sprint)
- 실제 개발을 진행하는 과정. 보통 2~4주 내에 진행
- 태스크를 대상으로 작업시간(양) 추정 후 개발 담당자에게 할당
- 개발자가 원하는 태스크를 직접 선별하여 담당할 수 있도록 하는 것이 좋음
- 할당된 태스크는 할 일(To Do), 진행 중(In Progress), 완료(Done) 상태 가짐

(2.4) 일일 스크럼 회의(Daily Scrum Meeting)
- 매일 약속된 시간에 모든 팀원이 약 15분정도 짧은 시간동안 진행상황 점검
- 남은 작업시가는 소멸 차트(Burn-down Chart)에 표시
- 스크럼 마스터는 발견된 장애 요소르 해결할 수 있도록 도와줌

(2.5) 스프린트 검토 회의(Sprint Review)
- 사용자가 포함된 참석자 앞에서 테스팅 수행
- 스프린트의 한 주당 한 시간 내에서 진행
- 제품 책임자는 개선할 사항에 대한 피드백 정리, 다음 스프린트에 반영될 수 있도록 제품 백로그 업데이트

(2.6) 스프린트 회고(Sprint Retrospective)
- 스프린트 주기를 되돌아 보며, 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 확인, 기록
- 해당 스프린트가 끝난 시점에서 수행 or 일정 주기로 수행

---

<XP(eXtreme Programming) 기법> ★★★★

(1) XP(eXtreme Programming)
- 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화, 
  개발 생산성 향상시키는 방법
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여 --> 소프트웨어 빠르게 개발하는 것 목적
- 릴리즈 기간 짧게 반복, 고객의 요구사항 반영에 대한 가시성 높임
- 릴리즈 테스트마다 고객 직접 참여, 요구한 기능이 제대로 작동하는지 고객이 직접 확인 가능
- 비교적 소규모 인원의 개발 프로젝트에 효과적
- XP의 5가지 핵심 가치    X의단용존피
  : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

(2) XP 개발 프로세스

(2.1) 사용자 스토리(User Story)
- 고객의 요구사항 간단한 시나리오로 표현
- 내용은 기능 단위로 구성, 필요한 경우 간단한 테스트 사항도 기재

(2.2) 릴리즈 계획 수립(Release Planning)
- 릴리즈 : 몇 개의 요구사항이 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것
- 부분, 전체 개발 완료 시점에 대한 일정을 수립

(2.3) 스프이크(Spike)
- 요구사항 신뢰성 높이고, 기술문제에 대한 위험 감소시키기 위해 별도로 만드는 간단한 프로그램
- 처리할 문제만 작성

(2.4) 이터레이션(Iteration)
- 이터레이션(Iteration) : 하나의 릴리즈를 더 세분화한 단위
- 1~3주 정도의 기간으로 진행
- 새로운 스토리 작성 가능, 작성된 스토리는 진행중 or 다음 이터레이션에 포함될 수 o

(2.5) 승인 검사(Acceptance Test, 인수 테스트)
- 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
- 사용자 스토리 작성 시 함께 깆한 테스트 사항에 대하 고객이 직접 수행한다.
- 테스트 이후 새로운 요구사항이 작성 될 수 o
- 요구사항의 상대적 우선순위가 변경될 수 o
- 테스트가 완료되면 다음 이터레이션 진행

(2.6) 소규모 릴리즈(Small Release)
- 고객의 반응을 기능별로 확인 가능 --> 요구사항에 보다 유연하게 대응 가능
- 계획된 릴리즈 기간 동안 진행된 이터레이션 모두 완료 
  --> 고객에 의한 최종 테스트 수행 --> 최종 결과물 고객에게 전달
- 최종 완제품이 아닌 경우, 다음 릴리즈 일정에 맞게 개발 계속 진행

---

<현행 시스템 파악> ★★☆☆ 

(1) 현행 시스템 파악 절차
- 개발하려는 시스템의 개발 범위를 명확히 설정하기 위함
- 1단계 : 시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악
- 2단계 : 아키텍처 구성 파악, 소프트웨어 구성 파악
- 3단계 : 하드웨어 구성 파악, 네트워크 구성 파악

(2) 시스템 구성 파악
- 기간 업무 : 조직의 주요 업무 담당
- 지원 업무 : 이를 지원
- 조직 내에 있는 모든 정보 시스템의 현황을 파악할 수 있도록 
  각 업무에 속하는 단위 업무 정보시스템의 명칭, 주요 기능들을 명시

(3) 시스템 기능 파악
- 단위 업무 시스템이 제공하는 기능들을 주요 기능과 하부기능, 세부기능으로 구분하여 계층형으로 표시

(4) 시스템 인터페이스 파악
- 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계유형, 주기 등 명시
- 데이터를 어떤 형식으로 주고받는지, 통신 규약은 무엇을 사용하는지, 연계 유형은 무엇인지 등을 반드시 고려

(5) 아키텍처 구성 파악
- 기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성
- 단위 업무 시스템별로 다를 경우, 기간 업무 처리 시스템을 기준으로 표현

(6) 소프트웨어 구성 파악
- 단위 업무 시스템별로 업무 처리를 위해 설치되어있는 소프트웨어들의 제품명, 
  용도, 라이선스 적용 방식, 라이선스 수 등을 명시
- 소프트웨어 비용이 시스템 구축비용 면에서 많은 비중 차지.
  --> 상용 소프트웨어의 경우 라이선스 적용 방식의 기준과 보유한 라이선스의 파악이 중요

(7) 하드웨어 구성 파악
- 단위 업무 시스템들이 운용되는 서버의 중요 사양, 수량, 이중화의 적용 여부 명시
- 서버의 이중화 : 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부가 결정됨
- 현행 시스템에 이중화가 적용된 경우 : 대부분 새로 구성된 시스템에도 이중화가 필요하므로 
  비용 증가와 시스템 구축 난이도가 높아질 가능성을 고려해야 함

(8) 네트워크 구성 파악
- 업무 시스템들의 네트워크 구성을 파악할 수 있도록 
  서버의 위치, 서버간의 네트워크 연결 방식을 네트워크 구성도로 작성
- 네트워크 구성도 : 서버들의 물리적인 위치 관계를 파악 가능, 보안 취약성을 분석 --> 적절한 대응 가능
- 네트워크 장애 발생 --> 발생 원인을 찾아 복구하기 위한 용도로 활용 가능

---

<개발 기술 환경 개발> ★★☆☆

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

(2) 운영체제(OS, Operating System)
- 컴퓨터 시스템의 자원들을 효율적으로 관리
- 사용자가 컴퓨터릴 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
- 컴퓨터 사용자와 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종
- 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공해줌
- 컴퓨터 운영체제 : Window, UNIX, Linux, Mac OS
- 모바일 운영체제 : iOS, Android

(3) 운영체제 관련 요구사항 식별 시 고려사항
 - 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

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

(5) DBMS 관련 요구사항 식별 시 고려사항
- 가용성, 성능, 기술 지원, 상호 호한성, 구축 비용

(6) 웹 어플리케이션 서버(WAS, Web Application Server)
- 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
- 데이터 접근, 세션 관리, 트랜젝션 관리 등을 위한 라이브러리를 제공함
- 데이터베이스 서버와 주로 연동해서 사용함
- Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere

(7) 웹 어플리케이션 서버(WAS) 관련 요구사항 식별 시 고려사항
- 가용성, 성능, 기술 지원, 구축 비용

(8) 오픈 소스 사용에 따른 고려사항
- 누구나 별다른 제한 x 사용할 수 있도록 소스코드를 공개한 것
- 오픈 소스 라이선스를 만족하는 소프트웨어
- 오픈 소스를 사용하는 경우에는 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야 함

---

<요구 사항 정리> ★★★☆

(1) 요구사항의 개념 및 특징
- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명,
  정상적으로 운영되는데 필요한 제약조건 등을 나타냄
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공함
- 개발하려는 소프트웨어의 전반적인 내용을 확인 가능
  --> 개발에 참여하는 이해관계자들의 의사소통을 원할하게 하는데 도움
- 요구사항이 제대로 정립되어야만, 이를 토대로 이후 과정의 목표와 계획 수립 가능

(2) 요구사항의 유형
- 기능 요구 사항 : 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
- 비기능 요구 사항 : 시스템 장비 구성, 성능, 인터페이스, 데이터, 테스트, 보안, 품질 요구사항
                           제약사항, 프로젝트 관리, 프로젝트 지원 요구사항
- 사용자 요구사항 : 사용자 관점, 친숙한 표현 쉽게 작성
- 시스템 요구사항 : 개발자 관점, 전문적, 기술적인 용어로 표현.
                         = 소프트웨어 요구사항   

(3) 요구사항 개발 프로세스
- 도출 --> 분석 --> 명세 --> 확인
- 요구사항 개발 프로세스가 진행되기 전, 타당성 조사(Feasibility Study)가 선행되어야 함
- 요구사항 개발은 요구 공학의 한 요소

(4) 요구사항 도출(Requirement Elication, 요구사항 수집)
- 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환, 
  요구사항이 어디있는지 어떠헤 수집할 것인지를 식별하고 이해하는 과정
- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
- 개발자와 고객 사이의 관계가 만들어지고, 이해관계자(Stakeholder)가 식별됨
- 소프트에어개발 생명주기(SDLC : Software Development Life Cycle) 동안 지속적으로 반복됨
- 요구사항 도출 주요 기법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토티이핑, 유스케이스

(5) 요구사항 분석(Requirement Analysis)
- 명확하지 않거나 모호하여 이해되지 x 부분 발견, 걸러내기 위한 과정

(6) 요구사항 명시(Requirement Specification)
- 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것 
- 기능 요구사항 , 비기능 요구사항

(7) 요구사항 확인(Requirement Validation, 요구사항 검증)
- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

 

---

<요구사항 분석 기법> ★★☆☆

(1) 요구사항 분석 기법
- 개발 대상에 대한 사용자의 요구사항 중 명확하지 x, 모호한 부분을 걸러내기 위한 방법

(2) 요구사항 분류(Requirement Classification)
- 기능 / 비기능
- 우선순위
- 범위
- 변경 가능성 여부

(3) 개념 모델링(Conceptual Modeling)
- 모델 : 요구사항을 보다 쉽게 이해할 수 있도록 현실세계의 상황을 단순화하여 개념적으로 표현한 것
- 실세계 문제에 대한 모델링은 소프트웨어 요구사항 분석의 핵심
- 개체들과 그들간의 관계 및 종속성 반영
- 개념 모델 다양하게 표현됨
- 모델링 표기는 주로 UML 사용한다.

(4) 요구사항 할당(Requirement Allocation)
- 요구사항을 만족시키기 위한 구성 요소를 식별함

(5) 요구사항 협상(Requirement Negotiation)
- 요구사항이 서로 충돌 될 경우 이를 적절히 해결하는 과정

(6) 정형 분석(Formal Analysis)
- 구문과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정

 

---

 

<요구사항 확인 기법> ★★☆☆

(1) 요구사항 확인 기법
- 요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법

(2) 요구사항 검토(Requirement Reviews)
- 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법

(3) 프로토타이핑(Prototyping)
- 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상시스템의 개발이 진행되는 동안
  도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정
- 장점 : 빠르고 반복되는 제작을 통해 발전된 결과물을 얻을 수 있음
          최종 시스템을 완성하기 전에 추가/변경 요구사항이나 아이디어 등에 대한 피드백이 가능함
- 단점 : 사용자의 관심이 핵심에서 벗어나 프로토타입 제작에만 집중할 수 있음

(4) 모델 검증(Model Verification)
- 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것

(5) 인수 테스트(Acceptance Tests)
- 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정

---

<요구 사항 정리> ★★★★

(1) UML(Unified Modeling Language)의 개요
- 시스템 개발자와 고객, 개발자 상호간의 의사소통이 원활하게 이뤄지도록 표준화한 대표적인 객체지향 모델링 언어
- 객체지향 방법론의 장점을 통합
- 객체 기술 국제표준화기구인 OMG(Object Management Group)에서 표준으로 지정
- 구성요소 : 사물, 관계, 다이어그램

(2) 사물(Things)
- 모델을 구성하는 가장 중요한 기본 요소
- 다이어그램안에서 관계가 형성될 수 있는 대상들을 말함
- 구조 사물 : 시스템의 개념적 물리적 요소 표현
- 행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현
- 그룹 사물 : 요소들을 그룹으로 묶어서 표현 (= 패키지)
- 주해 사물 : 부가적인 설명이나 제약조건 등을 표현

(3) 관계(Relationships)
- 사물과 사물사이의 연관성을 표현하는것

- 연관 관계(Association) : 2개 이상의 사물이 서로 관련되어 있음 표현
     - 사물 사이 : 실선으로 표현
     - 방향성 : 화살표로 표현
     - 양방향 관계 : 화살표를 생략, 실선으로만 연결
     - 다중도 : 연관에 참여하는 객체의 개수. 선 위에 표기

- 집합 관계(Aggregation) : 하나의 사물이 다른 사물에 포함되어 있는 관계
     - 포함하는 쪽과 포함되는 쪽은 서로 독립. 속이 빈 마름모를 연결하여 표현

- 포함 관계(Composition) : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
     - 포함하는 쪽과 포함되는 쪽은 서로 독립 x, 생명주기를 함께함. 속이 채워진 마름모를 연결하여 표현

- 일반화 관계(Generation) : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
     - 상위(부모) : 보다 일반적인 개념
     - 하위(자식) : 보다 구체적인 개념
     - 하위인 사물에서 상위인 사물쪽으로 속이 빈 화살표를 연결하여 표현

- 의존 관계(Dependency) : 서로 연관 o, 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
     - 소유관계 x, 사물의 변화가 다른 사물에도 영향을 미치는 관계
     - 이용자 : 영향을 주는 사물
     - 제공자 : 영향을 받는 사물
     - 이용자에서 제공자쪽으로 점선 화살표를 연결하여 표현

-실체화 관계(Realization) : 사물이 할 수 o, 해야하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계 표현
     - 사물에서 기능쪽으로 속이 빈 점선 화살표를 연결하여 표현

(4) 다이어그램(Diagram)
- 사물과 관계를 도형으로 표현한 것
- 정적 모델링 : 구조적 다이어그램 사용
- 구조적 다이어그램
     - 클래스 다이어그램 : 클래스, 클래스 사이의 속성, 클래스 사이의 관계 표현
     - 객체 다이어그램 : 클래스에 속한 사물(객체)들, 인스턴스를 특정 시점의 객체와 객체사이의 관계로 표현
     - 컴포넌트 다이어그램 : 실제 구현 모듈인 컴포넌트 간의 관계, 컴포넌트 간의 인터페이스 표현
     - 배치 다이어그램 : 물리적 요소들의 위치를 표현
     - 복합체 구조 다이어그램 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
     - 패키지 다이어그램 : 모델 요소들을 그룹화한 패키지들의 관계를 표현함

- 동적 모델링 : 행위적 다이어그램 사용
- 행위 다이어그램
     - 유스케이스 다이어그램 : 사용자의 요구를 분석하는것. 기능 모델링 작업에 사용
     - 시퀀스 다이어그램 : 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
     - 커뮤니케이션 다이어그램 : 동작에 참여하는 객체들이 주고받는 메시지, 객체들 간의 연관까지 표현
     - 상태 다이어그램 : 자신이 속한 클래스의 상태 변화, 다른 객체와의 상호작용에 따른 변화 표현     
     - 활동 다이어그램 : 객체의 처리 로직, 조건에 따른 처리 흐름을 순서에 따라 표현
     - 상호작용 개요 다이어그램 : 상호작용 다이어그램 간의 제어 흐름을 표현
     - 타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현
 

www.yes24.com/Product/Goods/82838724?OzSrank=6

2020 시나공 정보처리기사 필기

* 2020 시나공 정보처리기사 필기 요약한 내용입니다.