컴퓨터 원격 서비스

https://youtu.be/FnoHa3LYUWM?si=CuArwpeC-bwkSkH7

1. 인터페이스 요구사항

1-1. 인터페이스 요구사항 분석
- 시스템 인터페이스란 시스템 간 연동에서 접속 방법이나 규칙을 정의한 것임
- (중요) 시스템 인터페이스 설계와 개발은 필수적임
- 인터페이스 요구사항은 기능적 요구사항과 비기능적 요구사항으로 나뉨
- 기능적 요구사항은 시스템 내외부 연계를 통해 수행할 기능과 관련된 것임
- 비기능적 요구사항은 기능과 관련되지 않은 사항들임

1-2. 요구사항 분류와 명세서
- 비기능적 요구사항은 시스템 작동의 제약 조건들을 의미함
- 요구사항 분류는 기능적 요구사항, 비기능적 요구사항, 요구사항 우선순위, 속성 도출, 정형 분석 순으로 이루어짐
- (중요) 요구사항 명세서는 기능적, 비기능적 요구사항을 분류하고 조직화한 것임
- 요구사항 분석 기법에는 요구사항 확인, 개념 모델링, 상충되는 요구사항 협상, 정형 분석이 있음
- 요구사항 명세서 작성 시, 간결함, 개발자와 사용자 모두의 동의 확정이 중요함

1-3. 요구사항 검증과 적용
- 요구사항 검정은 기능적, 비기능적 요구사항을 분석한 후, 기준선을 설정하는 활동임
- 시스템 인터페이스 요구사항 분석과 인터페이스 요구사항 검증을 통해 개발하고자 하는 응용 소프트웨어의 요구사항 정확성과 완전성을 확인함
- 인터페이스 요구사항 정의를 통해 개발한 응용 소프트웨어가 원하는 요구사항을 정확하게 구현했는지 검증할 수 있음
- 개발된 응용 소프트웨어가 특정 기능을 제대로 구현했는지, 요구사항이 모두 충족되었는지 확인하는 것이 중요함

2. 시스템 인터페이스 요구사항

2-1. 시스템 인터페이스 요구사항 명세서 작성
- 시스템 인터페이스 요구사항을 기술하고, 시스템 품질과 측정 방법도 포함시킴
- 중요도 우선순위와 요구사항 참조를 위한 고유한 식별자도 기술함
- 인터페이스 설계 시, 인터페이스별 연계 방식을 구체적으로 명시함
- 인터페이스 요구사항 명세서에 데이터 정보, 보안, 통신 환경, 업무 담당자 등도 포함시킴
- 인터페이스 명세서는 시스템 인터페이스 요구사항 종류와 관련 있음

2-2. 인터페이스 요구사항 검증
- 인터페이스 요구사항 검증은 베리피케이션 요구사항 명세서를 기반으로 기준선을 설정하는 활동임
- (중요) 인터페이스 요구사항 검증 절차는 요구사항 검토계획 수립, 요구사항 명세서 검토, 오류 수정, 베이스라인 설정 순으로 진행됨
- 인터페이스 요구사항 검증 항목은 인터페이스 목록, 과제 내용 범위, 연계 시스템, 인터페이스 명세서 또는 정의서 등이 있음
- 송수신 주기, 연계 방법, 연계 형태, 송수신 데이터 식별 가능성, 통신 구간, 데이터 암호화 등 검증해야 할 요소들이 있음
- 요구사항 검증 방법은 동료검토, 워크스루, 인스펙션, 프로토 타이핑 등이 있음

2-3. 인터페이스 요구사항 검증 방법
- 동료검토는 요구사항 명세서 작성자가 설명하며, 이해관계자와 논의하며 결함이 있는지 확인하는 방식임
- 워크스루는 소프트웨어 개발 단계마다 실시하는 비정형 검토 회의로, 전문가나 팀이 참여하여 오류를 찾아내는 공식적 방법임
- 인스펙션은 소프트웨어 요구 설계 원시 코드 등을 검토하는 사례 중심의 검토 방법임
- 프로토 타이핑은 개발할 시스템의 주요 기능이나 일부를 약식으로 개발하여 사용자에게 보여주는 방법임
- 테스트 설계는 요구사항을 테스트할 수 있도록 케이스를 생성하여, 요구사항이 현실적으로 테스트 가능한지 검토하는 과정임

3. 인터페이스 설계

3-1. 인터페이스 요구사항 분석
- 사용자 인터페이스와 시스템 인터페이스 간의 차이점을 이해함
- 시스템 인터페이스 요구사항 분석을 통해 내부와 외부 인터페이스를 식별함
- 송수신 데이터와 인터페이스 주기 등 고려 사항을 명시함
- 인터페이스 요구사항 검토 방법으로 동료 검토, 워크스루 인스펙션 케이스 도구 활용 등을 포함함
- (중요) 인터페이스 요구사항 검증을 위해 소프트웨어 요구 설계, 원시 등 전문가의 검토가 필요함

3-2. 시스템 아키텍처 소개
- 시스템의 전체적인 논리적인 기능 체계와 구성 방식을 설명함
- 시스템 아키텍처의 기본 요건으로 시스템 구성, 동작 원리, 부품 설계 지원 등을 포함함
- 시스템 아키텍처 사례로 영업점 자동화기기, 채널 통합, 전자금융 대외계 인터페이스 등을 소개함
- 시스템 아키텍처를 통해 송신 시스템, 수신 시스템, 중계 서버 등 인터페이스 구성 요소를 분석함
- 중계 서버를 통해 데이터의 송수신 현황을 모니터링하고, 오류 발생 시 조치를 수행함

3-3. 시스템 인터페이스 구성
- 송신 시스템, 수신 시스템, 중계 서버를 통한 인터페이스 구성 요소를 이해함
- 송신 시스템은 전송할 데이터를 생성하고, 연계 서버에 전달함
- 수신 시스템은 연계 서버에 받은 데이터를 저장하고, 연계 서버를 통해 송신 시스템에 전달함
- 중계 서버는 연계 서버 간의 데이터 관계를 모니터링하고, 오류 발생 시 조치를 취함
- 중계 서버를 통해 송수신 데이터의 암복호화, 데이터 변환, 매핑, 응답 처리 등을 수행함

4. 시스템 구성과 인터페이스 설계를 통한 데이터 식별

4-1. 시스템 구성과 식별번호의 이해
- 시스템 아이디는 시스템 식별체계에 따라 부여되며, 한글 이름, 영문명시스템 등이 포함됨
- (중요) 네트워크 특성, 전용회선 정보 등이 포함되어 있는 전용회선 정보가 식별에 필요
- 포트 번호는 네트워크 상에서의 통로 역할을 하며, 서비스 종류를 구분함
- 포트 번호로 웹의 경우 80번, FTP의 경우 21번 등이 있음

4-2. 시스템 아키텍처의 요구사항과 전반적인 시스템 구성
- 시스템 아키텍처의 기본 요구사항에는 시스템 구성 및 동작 원리, 시스템 요소 간의 관계, 시스템 외부 환경과의 관계 등이 포함됨
- 시스템 구성 부품에 대한 구성요소 지원은 자세히 기술되어야 함
- 시스템 아키텍처는 전체적으로 체계화를 목표로 해야 함
- 시스템 구성과 동작 원리가 잘 나타나야 하며, 시스템 요소 간의 관계를 잘 묘사해야 함

4-3. 인터페이스 데이터 식별과 관련된 데이터베이스 산출물의 종류
- 인터페이스 데이터 명세화 과정에서 개체 정의서, 테이블 정의서 등의 데이터베이스 산출물 생성
- (중요) 개체 정의서는 개체 타입의 이름, 속성, 식별자 등을 포함
- 테이블 정의서는 데이터베이스의 논리 및 물리 모델링 단계에서 작성하며, 컬럼에 대한 정보를 담음
- 각 컬럼은 저장할 데이터의 유형, 크기, 비공란 허용 여부 등을 설정함

5. 인터페이스 설계

5-1. 시스템 인터페이스 설계 개요
- 시스템 인터페이스, 시스템 아키텍처의 일부로 시스템 전체에 대한 논리적 기능 체계로 이해함
- 시스템 인터페이스 구성 요소로 송신 시스템, 수신 시스템, 중계 서버 포함됨
- 인터페이스 표준 항목은 인터페이스 전문 부와 전문 종료부 포함
- 인터페이스 시스템에서 시스템 간 연동 정보와 인터페이스별 특성 반영한 인터페이스 설계 필요
- 시스템 인터페이스 설계, 인터페이스 대상 식별 위해 테이블 정의서, 개체 정의서, 인덱스 정의서, 코드 정의서 작성함

5-2. 송수신 방법과 오류 시 처리
- 인터페이스 아키텍처에서 송수신 방법은 직접연계방식과 간접연계방식이 있음
- 직접연계방식은 송신과 수신 시스템 간 직접 연결, 장점은 연계 속도 빠르지만 결합도 높음
- (중요) 간접연계방식은 중계 서버를 활용, 장점은 시스템 변경에 민감하지만 보안성 보호 가능
- 송수신 방법 명세화, 오류 시 처리 방안 명세화를 통해 인터페이스 설계서 작성 중점
- (중요) 인터페이스 설계서, 송수신 방법과 오류 시 처리 방안을 명세화해 시스템 인터페이스 설계 기준 만족시킴

5-3. 인터페이스 설계 사례
- 인터페이스 설계 사례로 시스템 간 연동 정보와 인터페이스별 특성 반영한 인터페이스 설계서 예시 있음
- 인터페이스 설계서에서 송수신 시스템과 중계 서버를 통한 연계 시스템 구현 명시
- 시스템 아키텍처에 따라 송수신 방법을 결정하고, 송수신 시스템에서 필요한 데이터 명세화 필요
- 인터페이스 설계서 작성 시, 인터페이스 설계 기준에 따라 내부와 외부 시스템 간 인터페이스 설계서 작성 중요
- (중요) 인터페이스 설계서, 송수신 방법과 오류 시 처리 방안 명세화해 시스템 인터페이스 설계 기준 만족시킴

6. 시스템 연계 기술과 인터페이스 오류

6-1. 시스템 연계 기술의 이해
- 네트워크와 프로토콜 등 다양한 환경을 연결해서 통합 관리 가능
- 인터페이스 변경 시 유연하게 대처 가능
- 보안 및 업무 처리 로직 반영이 용이
- (중요) 단, 인터페이스 아키텍처와 연계 절차가 복잡
- 성능이 저하될 수 있으나 개발 및 테스트 기간이 적음

6-2. 인터페이스 처리 및 통신 유형
- 인터페이스 처리 유형은 실시간, 지연처리, 배치방식이 있음
- 실시간 방식은 요청한 데이터를 바로 처리, 비용이 많이 발생
- (중요) 지연처리 방식은 데이터를 일정 시간 후에 처리, 처리량이 많거나 처리 속도가 느릴 때 사용
- 배치방식은 데이터 양이 많거나 비용이 많이 들 때 사용

6-3. 인터페이스 오류 유형
- 연계 서버의 실행 여부나 송수신 형식 변환 등에 오류 발생 가능
- 연계 서버 다운, 송수신 시스템 접속 오류 등이 연계 서버 관련 오류
- (중요) 시스템 송신 보내는 쪽에서 연계 프로그램 오류 발생 가능

7. 인터페이스 오류 처리

7-1. 인터페이스 오류 개요
- 인터페이스 오류 발생 시, 연계 서버와 송수신 시스템에 로그 기록 남김
- 오류 발생 시, 오류 코드와 에러 내용에 대한 상세 기록 남김
- 오류 유형에 따라 해결 방안을 수립하고, 오류 원인 분석하여 처리함
- 오류 코드, 내용, 관련 요소 등 인터페이스 오류 처리 절차 이해가 중요함
- 오류 코드는 오류를 식별할 수 있는 코드이며, 표준화된 오류 코드를 사용함

7-2. 인터페이스 설계서
- 인터페이스 설계서는 인터페이스 목록과 인터페이스 정의서로 구성됨
- 인터페이스 목록은 연계 업무와 연계 시스템에 관련된 정보를 담고 있음
- 인터페이스 아이디, 이름, 송신/수신 시스템, 연계 방식, 통신 유형, 주기 등 포함
- 인터페이스 정의서는 데이터 저장소, 송수신 시스템 간 상세 내역을 포함함
- 인터페이스 정의서에 데이터 테이블과 필드, 식별자, 키, 타입, 사이즈 등 입력함

7-3. 인터페이스 오류 처리
- 인터페이스 오류 발생 시, 로그 파일 기록하여 오류 원인 분석하고 해결 방안 수립함
- 오류 유형에 따라 해결 방안을 수립하고, 오류 원인에 따라 재전송 처리 또는 시스템 접속 오류 해결함
- 인터페이스 오류 코드 및 내용에 대한 상세 기록이 중요함
- (중요) 오류 유형에 따라 해결 방안을 수립하고, 오류 원인에 따라 재전송 또는 시스템 접속 오류 해결함
- 인터페이스 오류 처리 절차 숙지가 필수적임

00:02
네 챕터폭 인터페이스 설계에 대해 살펴보도록 하겠습니다. 먼저 첫 번째로, 인터페이스 요구사항 확인하기에 대해 살펴보겠는데요. 학습 목표는 정의된 응용 소프트웨어 요구사항을 참조하여 개발하고자 하는 응용 소프트웨어에 인터페이스의 비기능적 요구사항을 분석할 수 있다. 두 번째는 같은 내용으로서 인터페이스의 기능적인 측면의 요구사항을 분석할 수 있다. 마지막으로, 개발하고자 하는 응용 소프트웨어의 인터페이스 요구사항의 정확성과 완전성을 확인한다. 입니다. 학습내용은 두 파트로 인터페이스 요구사항 분석과 인터페이스 요구사항 검증에 대해 알아보도록 하겠습니다.

00:49
용어 정의적인 측면에서 먼저 시스템 인터페이스는 서로 독립적인 내외부 시스템의 연동을 통해서 상호작용을 위한 접속 방법이나 규칙을 의미한다. 자 여기서 이야기하는 인터페이스는요 저희가 두 번째 챕터에서 살펴봤던 화면 인터페이스 ui 에서는 사용자적인 측면에서 시스템과의 인터페이스였고요. 지금 현재 저희가 네 번째 챕터에서 살펴보는 인터페이스적인 부분은 시스템 인터페이스입니다. 시스템과 시스템 간의 연동에서의 인터페이스를 이야기합니다. 요구사항 검정은요, 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토로 베이스라인을 설정하는 활동이 되겠다. 기준선 설정하는 활동이 되겠다. 세부내용 보도록 하겠습니다.

01:44
인터페이스 요구사항 분석 첫 번째로, 시스템 인터페이스 요구사항에 대한 개념을 정립하도록 하겠는데 시스템 인터페이스란 서로 독립적인 시스템이 서로 연결되어졌을 때 서로 상호작용하기 위한 접속 방법이나 규칙을 의미한다. 일반적으로 네트워크를 통해서 연결이 되어지죠 시스템 간 네트워크를 통해 조직의 내외부 시스템 간 접속으로 특정 기능을 수행은 시스템 인터페이스 설계와 개발이 필수적입니다. 시스템 인터페이스의 요구사항에 대한 구성입니다. 내외부 인터페이스 이름 연계 대상 시스템 연계 방법 범위 및 내용 연계 방식 송신 데이터 인터페이스 주기 기타 고려 사항들을 명시합니다.

02:35
그리고 내외부 인터페이스 대상 시스템 및 기관과 시스템 연동 방안을 사전에 협의할 필요성이 있다. 예시로 시스템의 대내외 연계 구성도에 대한 예시입니다. 네 채널로서는 홈페이지나 콜센터 영업관리 이런 파트들이 mci라고 되어 있는 부분은 얘는 모기지 크라이빗 인슈어런스 예약이라고 하는 거거든요. 주택담보에 대한 대출 자체가 제대로 수행되지 않을 때 보장성 보험을 이야기하는 부분입니다. mci가 고려돼야 될 부분들이 있나 봐요. 내부적으로 예시도에서 살펴보니까 기관계 내에서는 고객 영업 마케팅 상품 이렇게 돼 있고 개념도 측면이다.

03:16
보니까 요지는 시스템의 대내외 그리고 외 에 대한 시스템 간 연계적인 측면에 대한 구상도를 개괄적인 측면에서 하나 화면으로 표시를 해서 이해하기 쉽도록 하는 이 구상도를 또 저희가 파악해 볼 필요성이 있다. 이렇게 이해하시면 될 것 같고요. eia라고 하는 부분 자체는 엔터프라이즈 애플리케이션 인테그레이션입니다. 기업 내의 애플리케이션을 통합하는 게 eai입니다. 연계 시스템의 대표 케이스라고 보시면 될 것 같고, 채널 외 고객분석 대외 외부적인 측면에서는 대외기관 중에 금융기관이나 유관기관들과 연결을 통해가지고 이러한 mci적인 부분에 대한 데이터를 이용한다든지 그렇게 보시면 될 것 같고, 넘어가겠습니다. 자 인터페이스 요구사항에 대한 분류입니다.

04:15
크게 보면 인터페이스 시스템 인터페이스 요구사항은 기능적 요구사항과 비기능적 요구사항으로 나눌 수 있습니다. 자 이 요구사항 부분은 저희가 소프트웨어 설계 첫 번째 세부과목으로 살펴봤던 요구사항 확인하기 그 부분 내에 요구공학이라는 부분이 있었거든요. 거기에서 보다 상세하게 저희가 다뤘습니다. 기능적으로 요구사항은 시스템 내 외부 연계를 통해서 수행할 기능과 관련된 것으로서 대표적인 게 입력이나 출력 또는 그러한 부분들에 대한 처리적인 부분들과 관련되어진 기능 접속성에 대한 요구사항들이 되겠고 일 사 일례로요 시스템 인터페이스 기능 요구사항에 대한 명세서 예시를 보면 자 요구사항 명세서입니다. 시스템 인터페이스 요구사항 명세서 양식인데요.

05:05
요구사항 분류는 뭔데 시스템 인터페이스 요구사항이고 요구사항 번호 식별번호는 시스템에 대한 리콰이어먼트 이렇게 해가지고 시스템 인터페이스 리콰이먼트 약어로 sir 하이펀 001이야 요구사항 명칭은 crn 고객관계관리 이거와 voc voice of custom으로 이야기합니다. 네 소비자들이 불만사항 같은 것들을 이야기할 수 있는 통로형 그거는 뭐와 관련된 건데 고객관리와 관련된 거죠. 고객관계관리 시스템에서 해당 이 부분을 잘 고려해서 불만사항이 있는 사람들이 불만을 잘 낮춰줘야지 그 사람이 꾸준하게 계속 고객으로 유지가 되겠죠.

05:45
그래서 요상 명칭은 crm과 voc의 연계야 요구사항 속성은 필수냐 네 필수다 요구사항 세부 내용 기재시되어 있는데, 보이오시 시스템을 통해서 수집되어진 고객의 불만의 정보를 crm 시스템에 매일 한 번씩은 전달을 하라 그래서 1일 보이오시 발생 건수는 대략 500회 정도 예상된다. 고려사항은요, voc 시스템에서 crn 시스템으로 고객 정보 전송하는 프로그램은 voc 시스템 담당자가 작성할 필요성이 있겠다. 그 외 산출 정보로서는 고객 불만 정보들이 산출 정보로 데이터 테이블에 입력되어지겠고요. 데이터베이스 테이블에 그리고 전송 로그 자료들이 남겨지겠고 이렇게 요구사항 출자는 crm 업무 담당자 인터뷰를 통해서 얻을 수 있겠다. 네 두 번째 요구사항 분류로 비기능적 요구사항 비기능적 요구사항은 기능과 관련되지 않은 사항입니다.

06:40
시스템이 정상적으로 작동하기 위해 시스템 내외부 제약 조건들을 뜻합니다. 예로서는 성능이나 응답 시간에 처리량은 이만큼 돼야 돼 또 사용자의 용이성 신뢰도 보안성 운영상의 제약 안전성 등이 해당되어집니다. 마찬가지 비기능 요구사항 명세서에 대한 예시입니다. 양식은 같으니까요? 일례로 인터페이스를 위한 연계 서버와 업무 서버 사이에는 침입 차단 시스템 등 보안 장비를 활용을 해서 보안을 강화해야 해 라고 하는 요구사항은 기능적 측면이 아니라 비기능적 측면의 요구사항이다. 이를 위해서는 virtual probit 네트워크라든지 vpin 활용한다든지 민간 정보에 대해서는 암호화를 적용해야 되겠다. 다음 채널 인터페이스 요구사항 분석입니다.

07:36
요구사항 정리 단계에서 정의되어진 기능 비기능 인터페이스 요구사항을 상세하게 이해하고 요구사항을 분류하고 조직화해서 명세를 작성하는 작업이 되겠고요. 이후에 개념 모델링을 통해서 검토를 하고요. 그리고 누락된 게 있으면 추가할 수도 있고 요구사항이 상대적으로 중요도를 평가해서 우선순위를 부여하고 품질 속성을 도출할 수 있겠습니다. 요구사항 분석 기법은 첫 번째 요구사항 챕터 1에서요 요구사항 확인 파트에서 저희가 다뤘어요. 4가지가 있었어요.

08:13
거기는 5가지가 있었는데, 저기 요구사항 분류 유형별 또는 우선순위별 제품 프로세스 연관성에 따라 분류 두 번째 개념 모델링 uml을 이용해 가지고 개념 모델링 세 번째 요구사항 해당 서로 간의 반발이 있는 서로 갈등요소가 되는 상충되어지는 요구사항들은 협상 마지막은 정형분석이라고 있었는데, 여기는 네 가지만 제시되어 있습니다. 요구사항 분석 기법 이 중에서 요구사항 명세서 표준 가이드 같은 경우엔 템플릿으로 요구사항 명세서 기술할 내용은 이런 것들을 기술을 해야 돼 라는 부분을 활용을 해서 작성할 수도 있고요. 요구사항 명세서 작성할 때 고려사항으로는 간결하기 그리고 개발자와 사용자가 모두 동의하는 것을 확정하고요.

09:00
그다음에 시스템의 모든 기능과 영향을 주는 모든 제약 요건들을 다 기술하고 그리고 요구사항 검증을 위해서 원하는 시스템 품질 그리고 품질 측정 및 검증 방법 인수 테스트 기준 등도 기술하고 우선순위에 따라서 다른 중요도도 기술하고 요구사항을 쉽게 참조할 수 있도록 고유한 식별자도 기술할 필요성이 있다. 이건 보편적 측면이고 인터페이스적인 측면에서의 요구사항 명세서 작성할 때 고려 사항은 인터페이스별 연계 방식이 추가적으로 들어가야 되겠고요. 네 저희가 나중에 인터페이스 설계하면서 구체적으로 인터페이스 연계 방식은 어떤 게 있는가 이런 것도 구체적으로 살펴볼 건데 웹 서비스 방식이요. db 파일 등 그리고 연계 유형은 실시간 처리야 아니면 모아서 처리하는 거야.

09:50
배치 연계주기는 어느 정도 주기를 갖고 하는지 이러한 부분들이 인터페이스 요구사항 명세서에 추가되어집니다. 그리고 보내고 받는 데이터 정보 송수신 데이터 정보 코드 정보 등 교환되는 데이터에 대한 정보를 식별할 수 있도록 작성하고 그리고 송수진 데이터의 보안 통신 네트워크 환경 송세션 데이터의 크기 제한 등 인터페이스 구현과 관련이 되어진 환경 정보와 기술적 요구사항도 포함이 되어지고 그리고 업무 담당자에 대한 정보도 확인할 수 있게끔 나중에 저희가 양식을 보도록 할 겁니다. 인터페이스명세서 자 학습 애틀 파트에 대해서요. 네 문제로 정리하겠습니다. 시스템 인터페이스 요구사항 종류 중에 기능적이지 않은 비기능적 요구사항이 아닌 거 골라라 이렇게 되어 있습니다. 쉽게 풀 수 있는 문제죠 1번 입력과 출력 이거는 기능이죠.

10:47
그래서 1번이 틀렸고 사용의 용이성 안전성 보안성은 비기능적 요구사항이 되겠습니다. 다음으로, 인터페이스 요구사항 검증입니다. 요구사항 검증 요구사항 검증이란 뭔데 베리피케이션 요구사항 명세서에 사용자의 요구가 올바르게 기술되어 있는가에 대해 검토하고 기준선인 베이스라인을 설정하는 활동이 요구사항 검증이 되겠습니다. 자 요구사항이 검증 절차입니다. 순서적인 측면 요구사항 검토계획을 먼저 수립하고 크기만 보겠습니다. 그리고 요구사항 명세서를 검토하고 오류가 있으면 오류를 수정한다. 그리고 요구사항에 대한 베이스라인을 설정을 한다. 다음 인터페이스 요구사항 검증 항목입니다. 인터페이스 요구사항을 검증할 때 어떤 걸 대상으로 살펴봐야 되느냐 첫 번째 인터페이스 목록입니다.

11:43
인터페이스목록은 대내외 연계 시스템을 모두 식별하고 인터페이스 요구사항들을 기록해 놓은 문서가 되겠는데 그 요구사항 중에 혹시 누락되어진 것이 없는가 요구사항을 누락 없이 도출했는가 라는 것을 살펴볼 필요성이 있고 과제 내용에 대한 범위 과제 범위 업무 보면서 및 프로젝트 수행 계획서와 비교해서 범위를 벗어나는 연계 시스템의 경우는 인터페이스 방안을 검토했는지를 체킹하고 그리고 인터페이스 명세서 또는 인터페이스 정의서라고도 합니다. 송수신 주기와 연계 방법 연계 형태 등의 정보가 기술되어 있나 그리고 송수신 데이터를 식별할 수 있도록 요구사항이 기술되어 있는지 체킹합니다.

12:24
마지막으로, 기술요건적인 측면에서는 송수신 시스템이 네트워크 구간정보를 확인할 수 있는가 인터넷이 연결되어 있나 아니면 인터넷망인가 그리고 송수진 데이터의 보안 요건을 기술했는가 통신 구간이나 데이터 암호화 등 그리고 송수진 데이터의 암호화가 필요한 경우에 적용 가능한 알고리즘이 또 기술되어 있는지를 체킹을 합니다. 네 그리고 요구사항 검증 방법으로서 요구사항 검토 리카이아먼트 리뷰라고 돼 있는데, 이 부분이 좀 시험에 자주 나오지 않을까? 보기 항목이 4개 저희 필기 파트에는 객관식 43답형이니까. 4개 보기를 제시할 수 있는 건 문제 내기가 딱 좋거든요. 사용 요구사항 검토 방식입니다. 동료검토가 있어요.

13:11
feer review 요구사항 명세서 작성자가 그 내용을 설명을 하면서 이해관계자가 두세 명이 그거 설명을 들으면서 결함이 있는가를 발견하는 형태로 진행하는 게 동료검토고요. 워크스루라고 하는 부분 자체는 소프트웨어 시스템 개발 단계마다 실시하는 비정형적인 검토 회의를 뜻합니다. 인스펙션은 내부적으로 꼼꼼하게 보겠다는 부분인데 소프트웨어 요구 설계 원시 코드 등의 저작자 외에 다른 전문가 또는 팀이 검사에 참여해서 오류를 찾아내는 공식적 검토 방법이 인스펙션 말로 케이스 케이스는 사례라는 뜻하는 게 아니라 약어인데요. 컴퓨터 컴퓨터가 aded 돕는다고요. 돕는 소프트웨어 엔지니어링 약어입니다.

14:00
컴퓨터를 이용한 해당 소프트웨어 엔지니어링 2를 케이스라고 하고 케이스 도구로 활용을 하는 요구사항 검토는 구조화되어진 요구사항 명세서에 대해서 자동화되어진 일관성 분석을 제공하는 케이스 도구를 활용하는 방법이 되겠습니다. 요구사항 검증 방법 두 번째는 프로토 타이핑 방법 개발할 시스템에 대한 주요 기능이나 일부를 약식으로 개발해서 사용자한테 보여주고요.

14:35
여기에 또 추가적인 요구사항이 있는지 그러한 부분을 파악하는 그리고 테스트 설계하는데 제대로 됐는지 요구사항을 테스트할 수 있도록 케이스들을 생성해서 추후 요구사항이 현실적으로 테스트 가능한지를 검토할 필요성이 있는데, 사례적인 부분에서는 인터페이스 요구사항에 대해서는 요구사항에 대한 테스트 케이스는 송신 시스템과 수신 시스템에서 확인할 사항을 각각 도출하고 송수신 시스템에서 각각 데이터 개별 데이터에 대한 유효값을 체크하는 테스트 케이스와 송수진 간 연관 관계를 체크하는 테스트 케이스를 구분해서 작성한다. 등등 있는데, 주 타이틀만 테스트 설계가 필요하다 요구사항 검증 방법을 이렇게만 익히겠습니다. 자 문제로 정리하겠습니다.

15:22
해당 방금 살펴봤던 내용 인터페이스 요구사항 검증과 관련한 문제인데 다음 중 인터페이스 요구사항 검토 방법이 아닌 것은 방금 살펴봤던 네 가지 문제 내기 쉽다고 말씀드렸던 plc 도구 활용 맞죠. 블랙박스 텍스트 이건 테스트는 나중에 파트에서 살펴볼 건데 소스로 보지 않고 테스트하는 거예요. 요구사항 검토하고는 관련성이 없고 테스트 방식입니다. 워크스루 인스펙션 맞죠. 자 모의평가로요 해당 인터페이스 요구사항 확인하기 정리하겠습니다.

15:59
다음 중 시스템 인터페이스 요구사항을 확인하기 위한 활동으로 올바르지 않은 거 틀린 거 첫 번째 정의된 응용 소프트웨어 요구사항을 참조하여 개발하고자 하는 응용 소프트웨어의 인터페이스 비기능 요구사항을 분석한다. 학습목표를 문제화한 부분입니다. 정의된 응용 소프트웨어 요구사항을 참조해서 개발하고자 하는 응용 소프트웨어의 인터페이스의 기능적인 요구사항을 분석한다. 개발하고자 하는 응용 소프트웨어의 모든 기능에 대한 품질 보증 활동을 수행한다. 이게 틀렸고요. 인터페이스의 비기능적 요구사항 기능적 요구사항 그리고 해당 인터페이스 요구사항이 정확한지 완전한지를 확인한다. 1 2 4번이 활동으로 올바르고 3번은 틀렸습니다.

16:54
두 번째 시스템 인터페이스 요구사항의 구성에 해당하지 않는 것을 골라라 틀린 겁니다. 내 외부 시스템의 이름 네 필요하죠. 구분하기 위해서 그리고 연계 대상 시스템 네 연계 범위 및 내용 사용자의 직무 연령 성별 이건 사람이잖아요. 사람에 대한 부분이잖아요. 인터페이스는 사용자 인터페이스가 있고 시스템 인터페이스가 있다. 여기서 문제에서 묻는 건 시스템 인터페이스를 묻기 때문에 4번이 대상이 아닙니다.

17:38
다음 세 번째 요구사항의 검토 방법으로 소프트웨어의 요구 설계 원시 코워드 등의 저작자 외에 다른 전문가 또는 팀 이 검사에 참여해서 꼼꼼하게 오류를 찾아내는 공식적 검토 방법은 뭔데 워크스루 동료 검토 인스펙션 케이스 도구 활용 중에 인스펙션이 되겠습니다. 3번입니다. 네 핵심 정리 내용 정리해보면 인터페이스 요구사항 분석 파트에서는요 시스템 인터페이스 요구사항은 인터페이스의 1은 연계 대상 시스템 그리고 연계 범위 및 내용 연계 방식과 송신 데이터와 인터페이스 주기 기타 고려 사항을 명시한 건데 내외부 인터페이스 대상 시스템 및 기관과 시스템 연동 방안을 사전에 협의할 필요성이 있다.

18:34
인터페이스 요구사항 검증 방법은 인터페이스 요구사항 검토 방법으로 4가지 동료 검토가 있고 워크스루 인스펙션 케이스 도구 활용이 있었습니다. 챕터 4 인터페이스 설계 두 번째 인터페이스 대상 식별하기에 대해 살펴보도록 하겠습니다. 학습목표인데요. 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스 대상 시스템을 식별할 수 있다. 둘째, 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스를 위한 필요한 연계 시스템을 식별할 수 있다. 마지막으로, 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스를 위해 필요로 하는 송수신 데이터를 식별할 수 있다. 이렇게 세 가지 학습 목표 살펴볼 학습내용은 인터페이스 시스템 식별과 송수신 데이터 식별입니다.

19:32
관련된 용어 사전으로서는요 시스템 아키텍쳐라는 부분 자체가 해당 이 파트에 시험 출제 세부 기준에 추가되어 있습니다. 그래서 시스템 아키텍처 추가적으로 살펴보도록 할 건데 시스템의 전체 이 전체라고 하는 부분 자체는 하드웨어와 소프트웨어를 포괄한 것입니다. 시스템 전체에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식인데 시스템 전체적인 최적화를 목표로 합니다. 자 세부내용을 살펴보겠습니다. 인터페이스 시스템 식별 부분에 먼저 추가적으로 시스템 아키텍처 개념에 대해서 먼저 살펴봅니다. 시스템 아키텍처란 방금 용어 정의에 대해서 살펴봤던 것처럼 시스템의 구조 행위 더 많은 뷰를 정의하는 개념적 모형이다 라고도 정의되고요.

20:27
시스템의 목적을 달성하기 위한 시스템의 각 컴포넌트가 무엇이고 이게 어떻게 상호작용하는지 그리고 정보가 어떻게 교환되는지를 설명한다 라고 정의되기도 합니다. 시스템 아키텍처의 기본요구사항들 다섯 가지로 제시되어 있는데, 시스템 구성 및 동작 원리가 나타나야 되고 시스템 구성 요소 즉 부품에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술되어 있어야 된다. 시스템 아키텍처는 그리고 구성요소 간의 관계 밑 시스템 외부 환경에 관한 관계도 잘 묘사가 되어 있어야 된다. 요구사항 및 시스템의 전체 수명 주기도 고려해야 된다. 마지막 설명 문구가 제가 용어 정리해서 정리한 문구입니다. 시스템 전체 하드웨어뿐만 아니라 소프트웨어를 포괄해서 논리적 기능 체계와 그것을 실현하기 위한 구성 방식 시스템의 전체적인 최적화를 목표로 한다.

21:26
자 개념도 제시해 놓았는데요. 시스템 아키텍처의 사례입니다. 언행의 정보계획 파트에서 연관되어진 시스템 아키텍처 사례로서 개괄적으로 개념도라고 보시면 될 것 같고, 앞서서 저희가 시스템 구성도도 저희가 인터페이스 구성도하고, 좀 비슷하네요. 라고 볼 수도 있는데, 그것보다는 좀 더 포괄적이다 라고 보실 수 있을 것 같고요. 영업점 자동화기기 이용 대상들이 채널 내에 채널 통합이나 전자금융 대외계 인터페이스를 통해서 내부 내에 해당 업무 처리 서비스 내에 관련되어진 측면은 물리적 측면에서는 이러한 것들은 데이터베이스를 나타냅니다. 과 이쪽에 기록이 되어지고 관련되어진 단위 시스템들은 어떠한 것들이 있다. 전체적인 활용 및 소프트웨어 포괄적인 시스템 아키텍처가 되겠습니다.

22:24
인터페이스 시스템 구성은 크게요 세 가지로 구성되어집니다. 오히려 더 크게 나누면 두 가지로 구성되겠죠. 보내는 시스템 받는 시스템 그리고 세분화하게 되면 경우에 따라서는 중간 역할을 하는 중계 서버가 있을 수 있습니다. 송신 시스템 연계할 데이터를 데이터베이스와 어플리케이션으로부터 연결 테이블 또는 파일 형태로 생성해서 보내는 시스템이 송신 시스템 수신 시스템은 받는 거 그리고 중계 서버는 송신 시스템과 수신 시스템 사이에서 데이터를 송수신하고 연계 데이터의 송수신 현황을 모니터링하는 시스템이 되고 연계 데이터의 보안 강화 다중 플랫폼 지원 등이라는 장점이 있다. 좀 더 구체적으로 살펴보겠습니다.

23:18
시스템 인터페이스 시스템 처리 흐름에서 보면 밑에 개념도 나와 있죠. 송신 시스템 연계 서버 수신 시스템 간의 송신 시스템에서 전송할 데이터를 생성을 하고요. 그다음에 연계 서버단에다가 전달한 다음에 그러면 연계 서버는 다시 수신 쪽에 데이터를 연결해서 보냅니다. 이 연계 서버는 시스템 간 연계 상태와 데이터의 송수신 오류 여부를 모니터링하고 그러한 어떤 오류가 생기면 관련되어진 조치를 수행을 담당합니다. 데이터에 대한 송수신 데이터 암 복호화 데이터 변환 및 매핑 응답 처리 및 완료 처리 담당을 연계 서버가 담당합니다. 연계 서버라고도 하고요. 중계 서버라고도 하고 중계 서버를 이용한 인터페이스 단계별 수행 작업 부분에서 송신부에서는 단계별 작업이 어떤 순서로 이루어지는가?

24:17
그다음에 수신부에서는 어떻게 이루어지는가? 송신부 중심적으로 살펴보겠습니다. 송신부 중심에서 보면 먼저는 순서상으로 연계 데이터 생성 및 추출을 먼저 하고요. 그 다음에 코드 매핑 및 데이터 변환 세 번째 인터페이스 테이블 및 파일 생성 네 번째 로고 기록하고 연계 서버 및 송신 어댑터 쪽으로 보내면 해당 중간에서는 얘를 받아가지고, 보내죠 다시 수신 쪽에 그리고 수신문은 송신부의 단계별 작업과 역순으로요 역순으로 이 순서대로 진행이 되어졌는데 송신 쪽에서는요 근데 수신 쪽에서는요 반대로 연계 서버 및 송신 어댑터 다음이 인터페이스 테이블 파일 생성 코드맵핑 및 데이터 변환 로그 기록 반대 순서로 진행이 되어지고 마지막에 연계 데이터 반영 이렇게 되어 있습니다.

25:17
하나만 정확하게 이해하면 될 것 같은데, 송신부 쪽 절차적인 부분을 조금 익혀놓으면 좋을 것 같습니다. 핸드페이스 시스템 식별자 정의 시스템 식별 코드 만들기는요 해당 기업 내에서 사용되어지고 있는 업무 분류 체계를 대중 이렇게 나눠가지고요. 그게 해당 분류 단위별로 식별할 수 있는 구분할 수 있는 식별자를 부여를 하고 그 업무 분류 체계를 조합해 가지고요. 일례로 상품 조회 시스템 코드라고 한다면, 대분류 상품이라고 하는 부분에 대해서 아이디를 pd로 부여를 했다면, 그 상품과 관련되어진 다시 업무 분류상에 중분류 리스트별 또 아이디를 부여해가지고 얘를 조합해요.

26:04
그래서 씨플코드 만들기는 업무 대분류 코드와 중분류 코드를 조합하고 뒤에다가 구분할 수 있게끔 일련번호를 붙여가지고 뭐 일례로 상품 코드 시스템 코드는 pdpr0011 상품의 id를 pd로 줬고 중분류 중에 상품 조회를 pr로 줬거든요. 그다음에 일련번호 재료제로 1 이렇게 만들 수 있습니다. 네 다음 내 외부 연계 시스템의 식별 정보에 대해 살펴보도록 할 건데 자 표 단위로 제시되어져 있는데요. 내외부 연계 시스템 식별 정보는 어떠한 것들이 있느냐 먼저 내 외부 구분 정보 내부냐 기업 내부 시스템인지 외부 시스템인지 구분하는 항목이 되겠고 기관명 대외기관일 경우에 기관명을 기술합니다.

26:55
그리고 시스템 아이디 시스템 식별체계에 따라서 부여되어진 식별번호를 가지고요. 한글 이름 영문명 시스템 설명 시스템에 대한 위치 그리고 네트워크 특성 네트워크 속도나 대역폭 유의사항 등 네트워크 특성도 내외부 연계시스템 식별정보가 됩니다. 전용회선정보 그리고 ip 인터넷 주소 ip url이라는 정보 이어지는 내용으로 포트 번호 포트라고 하는 부분은 네트워크 상에서의 통로 역할인데 서비스 종류를 구분합니다. 웹 같은 경우에는 80번 ftp 같은 경우 21번 이러한 웰론 포트 잘 알려진 포트들도 있고요.

27:41
로그인 정보 시스템 로그인 아이디어와 암호 db 정보 데이터베이스 전개가 필요한 경우에는 dbms 유형과 dbms 로그인 정보 담당자 정보 등이 내외부 연계 시스템 식별 정보에 포함되어진다 인터페이스 시스템 식별과 관련해서 퀴즈 시스템 아키텍처의 기본 요구사항으로 옳지 않은 것은 틀린 것을 골라라 이렇게 돼 있습니다. 시스템 아키텍처 첫 번째 시스템 구성 및 동작 원리가 잘 나타나야 된다. 맞고요. 시스템 요소 간의 관계와 시스템 외부 환경과의 또 관계가 묘사되어져야 된다. 내외부 맞습니다. 그리고 하류어에 대한 논리적 기능 체계와 그것을 실현하기 위한 구성 방식 시스템의 체계적 전체적인 체계화를 목표로 한다.

28:31
문제를 약간 꼬아서 보기 항목으로 제시한 건데 이게 아예 틀렸다고 할 수는 없긴 한데 바람직하지는 않아요. 하드웨어만을 대상으로 하지 않고 소프트웨어도 포함을 시키죠 하드웨어와 소프트웨어 를 포괄적으로 포함한 전체적 측면에서의 논리적 기능 체계 이렇게 접근을 한다고 보고 틀린 것은 3번으로 고를 수 있겠고 4번 시스템 구성 부품에 대한 구성요소 부품에 대해 설계 및 지원을 지원하는 수준으로 자세히 기술한다. 맞습니다. 두 번째 파트로 송수신 데이터 식별에 대해 알아보도록 할 건데요. 먼저 송수신하는 전문 보내는 해당 구성적인 부분은요, 전문에 대한 구성 이렇게 돼 있는데, 인터페이스 데이터 표준과 관련해서요. 송수신 시스템 사이에서 교환되어지는 데이터는요 규격화 되어진 표준 형식에 따라서 전송돼야 됩니다. 약속 체계가 있는 거죠.

29:31
우리는 지금 현재 데이터 구성을 이렇게 해서 보낼게 받는 쪽에서는 그 규칙에 맞게끔 보내져야지 그 규칙에 맞춰서 해석을 할 수 있는 거죠. 그래서 규격화되어진 표준 형식에 따라서 전송도 수신 이렇게 합니다. 핸드페이스 설계 단계에서요 송수신 시스템 간에 전송되는 표준 항목과 업무 처리용 데이터 및 대내외 연계할 때 사용하는 공통 코드 정보 등을 누락 없이 식별하고 인터페이스 명세서에 작성할 필요성이 있습니다. 자 나중에 저희 마지막 동영상이 뭐냐면 인터페이스 설계예요. 인터페이스 설계 부분에 보면 해당 이 인터페이스 목록과 인터페이스 명세서 정의서 표준 양식이 제시되어지니까. 그때 보면 무슨 말인지 지금 현재 문구 사항으로 설명하는 게 이해가 안 되더라도 마지막 동영상에서 양식을 보면서 정리해 드리도록 하겠습니다.

30:30
해당 송수진 전문은 크게 전문공통부 전문 개별부 그리고 전문 종료부 이렇게 세 파트로 나눌 수 있는데요. 전문 공통부는 인터페이스의 표준 항목을 포함하고 있어야 되고요. 그리고 전문 개별부는 개별적이라는 말입니다. 송수신 시스템에서 업무 처리에 필요한 데이터를 포함하고 마지막 종료부는 전송 데이터의 끝을 표시하는 문자가 포함되어져야 된다. 예시입니다. 예시 네 공 전문 공통부는 전문 길이 시스템 공통부 그리고 거래 공통부 로 구성되어지고 다시 세부적으로 그리고 전문 개별부는 데이터부 전문 종료부는 전문 종료부 고정 크기 값을 가진다 이렇게 구성되어집니다.

31:18
세부적으로 시스템 공통부는 시스템 간에 연동될 때 필요한 공통 정보를 담는 부분이다. 인터페이스 아이디와 전송 시스템 정보 예를 들어서 ip 주소나 시스템 코드 포트번호 등과 같은 것을 포함하고 있고 서비스코드정보 예로 수신 시스템에서 호출할 서비스 아이디나 송신 시스템의 서비스 아이디 그리고 ai 등과 같은 서비스 아이디를 포함을 하고 응답 결과 정보나 장애 정보 등으로 구성이 되어집니다. 그리고 공통적으로 사용되어지는 코드 정보는 공통 코드로 추출해서 시스템에서 공통으로 관리할 필요성이 있는데, 뒤에 이 공통 코드에 대해서도 좀 더 살펴볼 겁니다. 네 그다음에 거래공통부는 연동처리 시 필요로 하는 직원 정보와 승인자 정보 그리고 기기 정보 매체 정보 테스트 정보 등으로 구성이 되어집니다.

32:14
이중에서요 시스템 공통부는 좀 개념을 정립해 둘 필요가 있습니다. 송출제 데이터 개별 항목입니다. 보내고 받는 시스템이 업무를 수행하는 데 있어서 사용하는 데이터를 뜻합니다. 송수진 데이터를 식별하기 위해서 인터페이스 정의서의 연계 데이터 항목과 매핑 정의나 sql문 설계 등을 진행할 수가 있다. 송수진 데이터의 식별은 요구사항 정의서에 기술되어진 주요 정보 항목들을 기반으로 테이블 정의소 칼럼 정의소 등과 같은 데이터베이스 산출물을 확인해서 식별할 수 있어요. 이 부분은 뒤에 연계 시스템과 관련되어진 데이터베이스 산출물 더 구체적으로 살펴볼 겁니다.

33:02
공통 코드 대내외 연계 시 사용하는 공통 코드로 사용하는 공통 코드와 연계 시스템 또는 연계 소프트웨어에서 사용하는 상태 코드 그리고 오류 코드 등과 같은 공통 코드 항목에 대해 코드값과 코드명 코드 설명 등 공통 코드로 관리가 되는 것을 이야기한다. 자 인터페이스 설계 산출물 데이터베이스 산출물에 대해 살펴보도록 하겠는데요. 이 파트는 인터페이스 데이터 명세화 파트에 해당되어져요 그래서 인터페이스 설계 세부 출제 기준을 보면 인터페이스 데이터 명세화라고 세 번째 과목에서 포함되어 있는데, 그 부분을 제가 당겨 가지고 여기서 그냥 ncs 학습 모듈에 포함되어 있어 가지고 여기서 그냥 바로 설명드리겠습니다. 인터페이스 설계를 위한 데이터 산출물의 종류는 어떤 게 있는가 데이터베이스 산출물은 첫째, 개체 정의서가 있습니다.

34:00
개체 정의서는 뭔데 개념 모델링 과정 데이터 데이터베이스와 관련되어진 뒤에 저희가 내용 다룰 때 계속 사용되어질 부분들이긴 한데 개념 모델링 과정에서 도출되어진 개체 타입 그와 관련되어진 속성 식별자 등에 대한 개괄적인 정보를 포함하고 있고 뭐가요 개체정의서는 개체 타입명은 데이터베이스에 저장할 개체를 대표할 수 있는 이름으로 설정을 하고 속성은 개체의 특징을 나타낼 수 있는 또는 설명할 수 있는 정보로 포함을 시키고 식별자는 해당 개체가 유일하게 구분될 수 있는 속성으로서 주식별자 또는 대체식별자를 의미한다. 개체 정의서 예시입니다. 개체 타입에서 고객이 있어요. 고객에 대한 설명입니다.

34:53
당사 고객에 대한 정보로 고객 기본 정보와 배송지 정보와 고객 성향 정보를 포함하고 있어요. 속성으로서는 고객이 가질 수 있는 속성으로서는 고객을 구분할 수 있는 고객 번호 그리고 이름 주민등록번호 사업자 번호 주소 연락처 등이 있겠고 식별자라고 하는 부분은 여러 고객들 중에 고객을 구분할 수 있는 수단으로서는 고객당 부여된 번호나 주민등록번호 사업자 번호 이러한 것들이 식별자가 됩니다. 그 외에 상품 계약 사례로 그냥 스킵하겠습니다. 네 두 번째로, 테이블 정의서가 있습니다. 인터페이스 설계 데이터베이스 산출물 두 번째 테이블 정의서 테이블 정의서는 논리 및 물리 모델링 단계에서 작성하는 산출물이 되겠고요. 테이블에 관리되는 컬럼 열을 이야기합니다. 필드라는 용어로도 쓰고 테이블에 관리되는 컬럼들에 대한 특징으로서 해당 이 컬럼은 어떤 이름이나 컬럼명 그리고 이 컬럼에는 저장할 수 있는 데이터의 타입 데이터의 유형은 뭐야?

35:52
정수 값만 저장할 수 있어 문자열만 저장할 수 있어 등등 데이터 타입 그리고 어느 정도 크기 네 길이 그리고 빈 공란을 허용 안 했냐 입력 안 해도 돼 널 허용 여부 그리고 키 설정 여부 구분할 수 있는 아까 식별자 있었죠. 키 프라이머리 키라든지 그다음에 디폴트 값 여부 디폴트 값 이러한 것들을 해당 컬럼에 설정하는 부분들이고 인덱스 업무 규칙을 문서화한 것이 되겠다. 데이터 테이블 정의서에 대한 설명입니다. 테이블 정의서의 구성 내용들입니다. 네 테이블 정의서의 구성 항목으로서는 개괄적으로 한번 보겠습니다.

36:36
주제 영역이 있는데, 네 주제 영역은 놀림 및 물리 모델링 분류할 때 주제 영역으로 테이블 목록에 주제 영역과 동일해야 되고 테이블 아이디가 있고 테이블 이름이 있고 테이블에 대한 설명이 있고 컬럼 번호 해당 컬럼의 순서를 일련번호로 기재해 놓은 게 되겠고 컬럼별 아이디 해당 컬럼을 구분할 수 있는 테이블에서 무슨 컬럼이야 테이블로 구분할 수 있는 물리적 구현되는 컬럼의 명칭이고 컬럼 이름 한글로 이렇게 구분하는 부여한 이름이 되겠고 그다음에 데이터 타입 저장되어지는 데이터 형식 그리고 길이 널 허용 여부 키 설정 여부 디폴트 값 그리고 인덱스 테이블에 생성되는 인덱스 인덱스의 키 업무 규칙 등이 테이블 정의선의 구성 내용들이 되겠습니다.

37:32
네 마지막으로, 코드 정의서요 네 코드 정의서는 코드 성 속성은 속성명 뒤에 코드를 붙여가지고 구분을 하고 알파벳과 문자열을 조합해서 일정한 길이로 구성을 합니다. 코드는 전체 데이터베이스에서 유일하게 정의해야 하는데 이러한 코드를 정의한 게 코드 정의서가 되겠습니다. 코드 정의서의 구성 내용입니다. 코드 아이디 한글 코드명 영문 코드명 그리고 기호화되어진 코드값인 코드 그리고 코드 값에 해당하는 실제 내용과 설명을 뜻하는 코드 이름 비고문에는 코드 레벨이나 구분 등 부가적인 정보를 담을 수 있습니다. 자 송서신 데이터에 대한 식별 파트의 먼저 퀴즈 문제로 다음 중 인터페이스 설계를 위해서 필요한 데이터베이스 산출물 저희가 세 가지 살펴봤었어요.

38:32
그 중에서 개념 모델링 과정에서 도출한 개체 타입과 관련되어진 속성 그리고 식별자 등에 대한 개괄적 정보를 포함하고 있는 문서는 어디에 해당되느냐 테이블 정의서 개체 정의서 인덱스 정의서 코드 정의서가 있는데, 주 키워드가 보면 개체라는 용어가 들어가 있으면 개체 정의서다 이렇게 뽑을 수 있겠습니다. 자 인터페이스 대상 식별 파트에 대한 모의평가 문제로 정리해 보도록 하겠습니다. 첫 번째 시스템 인터페이스를 구성하는 시스템의 종류로 올바르지 않은 거 틀린 걸 골라라 이렇게 돼 있습니다. 시스템 인터페이스 구성 시스템은 세 가지 있었죠. 보낸다 송신 수신 중간에서 역할을 하는 중계 서버 엉뚱한 거 등록 시스템이 틀린 겁니다.

39:29
두 번째 중계 서버 또는 연계 서버를 이용한 인터페이스 단계별 작업 중에 송신부의 단계별 작업을 올바르게 나열한 것은 가나다라 저 음 네 리스트 돼 있는데, 송신부에서 첫 번째 뭘 했느냐 하면은 연계 데이터 생성 및 추출을 먼저 했었어요. 연계 데이터 생성 및 추출 그러면 가로 시작하지 않는 건 지워요 3번 하고 4번은 아니죠. 그러면 객관식이니까. 틀린 걸 아예 지워 나가고 남는 거에서 고르는 형태도 문제풀이를 하는 하나의 팁입니다. 자 그 다음에 긴가민가 할 때 특히 이 방법을 사용하세요. 그럼 다로 시작하는 것 중에 가 여기까지 갔네 세 번째가 나냐 라 나인가 두 번째인가 네 번째인가 여기서 판가름이 납니다.

40:28
네 연계 데이터 생성 및 추출 그다음에 가는 똑같아요. 이게 두 번째가 되겠다. 코드 매핑 및 데이터 변환 그 다음에 세 번째가 로그 기록인가 인터페이스 테이블 파일 생성인가 라는 부분인데요. 로그 기록이 제일 마지막에 수행되어집니다. 그래서 순서는 연계 데이터 생성 및 추출 그리고 코드 맵핑 및 데이터 변환 인터페이스 테이블 및 파일 생성 로그 기록이 마지막에 있는 2번이 정답이 되겠습니다. 다음 3번입니다.

41:00
송수신 전문 구성 중에 해당 전문 구성 중에 다음 설명에 해당하는 건 뭔데 시스템 간 연동이 필요한 공통 정보를 말하고 인터페이스 아이디와 전송시스템 정보 서비스 코드 정보 응답 결과 정보 장애 정보 등으로 구성이 되어진다 공통적으로 사용하는 코드 정보는 공통 코드를 추출하고 시스템에 공통으로 관리할 수가 있다니 아까 제가 미리 이거는 좀 기억을 하시면 좋을 것 같다는 체크해 드렸던 시스템 공통부에 대한 설명입니다. 네 핵심 내용으로 정리 핵심 정리로 해당 이 파트 마무리하겠습니다. 인트페이스 시스템 식별 파트에서 저희가 좀 주의 깊게 봤던 거는 이 시스템 아키텍처에 대한 개념이었어요.

41:55
시스템 아키텍처는 시스템 전체 하드웨어뿐만 아니라 소프트웨어도 포괄한 시스템 전체에 대한 논리적 기능 체계로 그것을 실현하기 위한 구성 방식이었고 시스템 전체적인 최적화를 목표로 했습니다. 인터페이스 시스템 구성은 세 가지 송신시스템 수신시스템 중계 서버가 있었고요. 송수신 데이터 식별 부분에서는 송수신 정문에서 전문 공통부는 인터페이스 표준 항목을 포함하고 있었고, 전문 개별부는 송수신 시스템에서 업무 처리에 필요한 데이터가 포함되었고 마지막 전문 종료부는 데이터 끝이라고 표시하는 문자가 포함되어 있었죠. 핸드페이 설계 데이터베이스 외 산출문은 세 가지가 있었습니다. 개체 정의서 테이블 정의서 코드 정의서 네 이상으로 인트페이스 대상 식별에 대한 파트 마치겠습니다.

42:51
챕터4 인트페이스 설계 마지막 세 번째 인트페이스 상세 설계하기에 대해 살펴보도록 하겠습니다. 학습목표 4가지가 제시되어 있는데요. 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스를 위한 송수신 방법을 명세화할 수 있다. 정해가지고 기술한다는 말입니다. 그 다음에 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스를 위한 필요한 데이터를 명세화할 수 있다. 자 이 부분은요, 저희가 두 번째 파트에서 미리 다뤘어요. 해당 인터페이스 시스템과 관련되어진 데이터베이스의 산출물이라고 세 가지 다뤘던 거 그 부분입니다. 세 번째 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스의 오류 시 처리 방안을 명세화할 수 있다.

43:42
마지막 소프트웨어 아키텍처에서 정의한 인터페이스 설계 기준에 따라서 내부와 외부 시스템 간의 인터페이스 설계서를 작성할 수 있다. 주는요 송수신 방법의 명세화와 그리고 오류 시 처리방안 명세화 인티페이스 설계 작성 위주로 살펴볼 겁니다. 학습내용은 인티페이스 방법 명세화 인티페이스 설계서 작성입니다. 네 먼저 인터페이스 방법 명세화 부분에서 내외부 송수신 연계방식에 대해서 먼저 살펴보도록 하겠습니다. 크게는 직접연계방식이 있고요. 두 번째는 간접연계방식이 있다. 연결시킨다는 말입니다. 직접 연결하는 건 송신 시스템과 수신 시스템 간에 바로 연결한다는 말이에요.

44:30
중간에 연계 서버가 없이 중간자 역할을 하는 중개 서버 없이 이 케이스 중계 서버나 솔루션을 사용하지 않고 송신 시스템과 수신이 직접 연결하는 방식이야 장점은요, 일반적으로 연계 속도가 빨라요. 네 연계 처리 속도가 빨라요. 그러니까 보내고 받는 네 이 처리 속도가 빠르다 빠르게 구현이 어 빠르고 구현이 단순하고 그래서 개발 비용과 개발 기간이 짧아요. 처리 속도가 빠르고 개발 비용과 개발 기간이 짧다라는 장점이 있는 반면, 단점적인 측면에서는요 송신 시스템과 수신 시스템 간의 결합도가 높아요. 그래서 이쪽에서의 어떤 변화가 반대쪽에서 본인 쪽에서의 변화가 반대쪽에 바로 영향을 미칩니다.

45:23
시스템 변경에 민감하다 특히 보안적인 측면에서 걸러주는 역할을 하는 게 없고 바로 다이렉트 연결돼 있다 보니까 보안을 위해서는 암호 복호화하는 암 복호화 처리와 비즈니스 노직 구현을 인터페이스별로 별도로 작성을 해야 된다. 이게 필요하다 이 말입니다. 그리고 전사 시스템 인터페이스에 대해서는 통합 환경 구축이 좀 쉽지가 않다 전반적인 전체적인 측면에 전산 시스템 인터페이스로서는 직접 연결 방식은 좀 어렵다 이에 비해서 간접 연계 방식 즉 중간에 연계 서버를 두고 활용되어지는 방식을 뜻합니다. ear 엔터프라이즈 애플리케이션 인테그레이션과 같은 연계 서버를 활용하는 방식을 뜻하는데 장단점이 직접과 반대겠죠.

46:21
네 간접 연계 방식의 장점입니다. 서로 상이한 네트워크와 프로토콜 등 다양한 환경을 갖는 시스템들도 연결해서 통합 관리할 수 있다. 그리고 인터페이스 변경이 되어도 유연하게 대처가 가능하다 그리고 보안이나 업무 처리 로직 반영이 용이하다 즉 보안이 뛰어나다 이렇게 이해하시면 되겠고 반대로 단점입니다. 인터페이스 아키텍처와 연계 절차가 복잡해요. 직접 연결 안 하고 중간에 뭔가 있단 말이에요. 네 연계 서버로 인해서 네 오히려 성능이 또 낮아질 수도 있겠다. 개발 및 테스트 기간이 직접 연계보다 오래 걸립니다. 장단점이 상호 반대입니다. 그래서 하나만 명확하게 익혀 놓으시면 상반적인 부분이기 때문에 나중에 문제로 저희가 어떻게 출제될지 한번 저희가 문제로 한번 정리해 보도록 하겠습니다.

47:22
내외부 송 송수신의 연계 기술로서는요 네 시스템 연계 기술로 연계 기술의 종류가요 7개 정도 제시가 되어져 있어요. 7개까지 제시되어져 있는데, 단계별로 연계 기술에 대한 설명이 제시되어 있을 때 이게 어떤 연계 기술이야 라고 구분할 수 있는 정도만 익히면 되겠습니다. db 링크다 데이터베이스 링크 데이터베이스에서 제공을 하는 db 링크 객체를 이용해 db 링크니까 db 링크 객체 이용해 이거는 틀린 보기로 나오겠죠. 애매하겠죠. 데이터베이스 제공하는 db 링크 객체를 이용하는 방법이 연계 기술 중에 db 링크 방식입니다. db커넥션이다. 수신 시스템의 왓스 웹 애플리케이션 서버 이야기를 합니다.

48:07
수신 시스템의 왓스에서 송신 시스템 db로 연결하는 db 커넥션 풀을 생성을 하고 연계 프로그램에서 해당 db 커넥션 풀을 이용하는 방식이야 서버사이드 스크립트 프로그램 언어인 jsp나 asp 저희가 우선적으로는 정보처리 기사에서는 주 프로그램 랭귀지는 자바를 베이스로 하고 있습니다. 자바에서는 서버 사이드 스크립트 언어 웹 프로그램 언어는 jsp가 되겠죠. 네 jsp 같은 경우에 해당 웹 문서가 데이터베이스하고 연결할 때는 이 db 커넥션 방식으로 주로 이용을 합니다. 자 그다음 세 번째 api는 네이버나 다음 같은 경우에 토탈에서 만든 지도 검색이라든지.

49:01
이러한 것들을 오픈시켜가지고, api로 꼭 해당 그거를 설치 안 하더라도 외부에서 이용할 수 있게끔 하는 거죠. 송신 시스템의 db에서 데이터를 읽어와서 제공하는 애플리케이션 프로그래밍 인터페이스 뜻한다. api명과 입출력 파라미터 정보가 필요하다 jdbc는 수신 시스템의 프로그램에서 jdbc 드라이버를 이용해서 송신 시스템 db에 연결한다. 필요 정보로서는 dbms 유형과 db 서버의 ip 포트 그리고 db 인스턴스 정보가 필요하다 자바 데이터베이스 커넥션의 약어입니다. 자바 데이터베이스 커넥션 약어가 jdbc입니다. 하이퍼링크요 그냥 링크 거는 거예요. 웹 애플리케이션에서 하이퍼링크를 이용한다.

49:55
하이퍼링크 걸리면 문자나 이미지에 마우스를 올리면 손가락 모양이 바뀌죠 클릭하면 뭔가 연결된 게 뜨죠 소켓 서버는 통신을 위해서 소켓을 생성을 하고 포트를 할당을 해서 클라이언트 통신 요청할 때 클라이언트와 연결하고 통신하는 네트워크 기술 소켓 그리고 웹 서비스 웹 서비스에서 약어가 몇 가지 돼 있는데, 그 원어를 뒤에다가 갈로그램을 포함시켰기 때문에 wsdl이다. 웹 서비스 디스크립션 랭귀지 wsdl과 uddi 유니멀스 디스크립션 또는 디스커버리 앤 인테고레이션 약어 얘의 약어가 uddi입니다. 또는 소프 프로토콜 이름인데요.

50:43
심플 오브젝트 억세스 프로토콜 이러한 프로토콜을 이용해서 연계하는 방식이 웹 서비스다 설명 문구에서 해당 연계 기술을 뽑을 수 있는 정도의 문제가 사지삼답형으로 출제될 수 있는 파트입니다. 다음으로, 인터페이스 처리 및 통신 유형에 대해 살펴보도록 하겠는데요. 인터페이스를 처리하는 유형은 크게는 세 가지로 나눌 수 있습니다. 처리는 업무의 성격과 전송하는 데이터의 양을 고려해서 적합한 방식이 달라지겠는데 실시간 방식이다 라고 하는 부분 자체는 리얼타임이죠. 적시적으로 사용자가 요청한 내용을 바로바로 적시 처리하는 바로 처리해야 하는 경우는 실시간 방식 지연처리 방식이라고 하는 부분 자체는 바로 처리하고 좀 이따가 처리한다. 이 말입니다.

51:39
4건 단위로 처리할 경우에 비용이 많이 발생을 하는 경우에는 조금 모아서 처리하는 그런데 이 지연처리 방식하고 배치방식하고는 같지가 않습니다. 배치방식은 대량의 데이터 처리에 적합하다 그리고 어떤 주기적으로 정해진 시간이 수행하는 방식이에요. 그래서 연계 스케줄러에 의해서 구동되어지는 이벤트 방식과 타이머에 의한 방식이 있고 배치 방식에서의 통신 유형은 db와 파일 거래 방식입니다. 자 실시간 방식에서의 통신 유형 좀 전에 제가 마무리해서 배치 방식의 통신 유형은 db 파일 거래라고 말씀드렸고 실시간 방식의 통신 유형은 단방향 한쪽에서 일방적으로 보낸다 반대 개념은요, 보내는 것만 아니라 받기도 한다. 서로 양방향도 있고 개념이요.

52:38
단방향 데이터를 이용하고자 하는 시스템에서 거래 요청을 하고 난 다음에 데이터를 전송하는 상대 시스템 응답 필요 없이 그냥 보내는 거 대표적으로 방송 같은 경우에 단방향 방식이죠. 동기 동기 같은 경우에 동기식이다 라고 하는 부분은 얘는 양방향 개념인데 데이터를 이용하고자 하는 시스템에서 거래 요청을 하고 응답이 올 때까지 기다려요 리퀘스트 리플라이 기다리고 업무 특성상 응답을 바로 네 처리하는 거래나 거래량이 적고 상대 시스템의 처리 속도가 빠를 경우에 사용하는 게 동기식이고요. 비동기식은 이것도 이제 양방향 양쪽입니다.

53:21
이렇게 이렇게인데 데이터를 이용하고자 하는 시스템에서 거래를 요청하는 서비스와 응답을 받아서 처리하는 서비스가 분리된 구조고 요청을 보내고 다른 작업을 하고 있다가 상대 쪽에서 데이터가 준비됐다라고 하는 신호가 받아지면 다시 처리하는 방식 어떤 경우에 주문 업무와 같이 거래량이 많거나 데이터를 전송하는 시스템 처리가 오래 걸리는 업무에는 비동기 통신 유형을 사용을 합니다. 네 다음으로, 데이터 암호화 필수 항목은요, 법률적으로 정해놓은 대상들이 있어요. 이 데이터를 반드시 암호문으로 다른 사람들이 해당 내용을 바로 볼 수 없게끔 하라고 지정해 놓은 것들이 있는데, 법적인 측면에서는 정보통신망법이나 개인정보보호법이 대상이 되고요.

54:11
일례로 정보통지망 이용 촉진 및 정보 보호 등에 관한 법률에 의한 대통령령에서는 필수 암호화할 대상은 중등록번호 반드시 암호화 시켜야 되고 패스워드 비밀번호 그다음에 공개 동의하지 않는 개인정보들은 암호화하라 그리고 전자금융거래법이라든지. 신용정보 이용 및 보호에 관한 법률 등에서는요 주민번호하고 패스워드 계좌번호를 꼭 암호화하라 라고 정해져 있습니다. 네 다음으로, 인터페이스 오류 파트로 넘어가서요 인터페이스 오류 유형에 대해 살펴보도록 하겠는데 자 연계 서버 에서의 오류 송신 시스템 연계 프로그램에서 연계 데이터에서 수신 프로그램 연계 프로그램에서의 오류 한번 보도록 하겠습니다.

54:53
연계 사업에서는 어떤 오류들이 있는가 하면 연계 서버의 실행 여부나 송수신 전송 형식 변환 등 연계 서버의 기능과 관련된 장애 또는 오류가 있을 수 있겠고 연계 서버가 다운된다든지 송수신 시스템에 접속 오류가 발생한다든지 이러한 것들이 연계 서버와 관련된 오류가 되겠고요. 시스템 송신 보내는 쪽 시스템에서의 연계 프로그램과 관련되어진 오류는 연계 프로그램 추출 연계 데이터 추출을 위한 데이터베이스 접근 권한 오류나 데이터 변환 시 예외 상황 미처리 등으로 인한 연계 프로그램 오류가 있을 수 있겠고요. 미등록 코드로 인한 코드맵핑 오류도 송신 시스템 연계 프로그램과 관련된 오류가 되겠습니다.

55:39
그리고 연계 데이터는 연계 데이터 값이 유효하지 않은 경우에 발생하는 오류 일자 데이터 값이 유효하지 않은 경우는 일자 값 입력에 따른 오류가 발생할 수도 있겠고 그리고 수신 받는 쪽 시스템에서의 연계 프로그램과 관련된 오류로는 수신받은 데이터를 운영 데이터베이스에 반영하는 과정에서 접근 권한에 관련된 문제가 발생했다든지 또는 데이터 변환이 되어질 때 예외상 미처리로 인한 연계 프로그램 오류가 생길 수도 있겠고 데이터 등록 갱신 오류도 수신 시스템 연계 프로그램 오류에 해당되어집니다. 다음 인터페이스 오류 처리 방법 인트페이스 오류 처리 절차로서는요 인트페이스 오류가 발생한 경우에 연계 서버와 송수신 시스템에 로그 파일에 로그 기록을 쭉 남기는 거죠.

56:34
로그 파일의 오류 코드와 에러 발생에 관련되어진 상세 내용이 기록되도록요 연계 프로그램을 작성할 필요성이 있습니다. 그리고 오류 발생 시 인터페이스 담당자는 연계 서버와 송수신 시스템에 기록되어진 로그 파일 내용을 확인하고 오류의 원인을 분석하고 해결 방안을 수립해야 합니다. 그리고 오류 유형에 따른 해결 방안으로서는요 연계 데이터 오류인 경우에는 데이터를 보장하고 재전송 처리를 하고요. 송수신 시스템 접속 오류에 대해서는 시스템 담당자를 통해서 접속 오류를 해결한 다음에 재전송하면 되겠습니다. 네 그리고 인트페이스 오류 코드 및 내용과 관련된 내용 부분입니다. 인트페이스 장애 및 오류 처리를 위해서 발생할 수 있는 오류 유형별로 오류 코드를 정의를 하구요.

57:34
시스템이 공통으로 사용할 수 있도록 표준화되어진 오류 코드를 공통 코드로 등록하는 작업이 선행되어야 합니다. 오류 코드는 뭔데 오류 코드는 오류를 식별할 수 있는 코드가 되겠다. 오류 발생지와 오류 유형 그리고 일련번호를 포함해서 오류코드 명령 규칙을 정의합니다. 오류 내용은 오류 발생 내용과 원인을 포함하도록 설명을 기술을 해야 되고요. 오류 내용에는 데이터 에러 네트워크 에러 암호 복호 에러 등 오류 발생 원인을 포함해서 기술합니다. 인터페이스 방법 명세화와 관련해서 퀴즈 풀어보면 다음 중 힌트페이스 연계 기술에 관련되어진 설명 중에 옳지 않은 거 골라라 네 틀린 거 골라라 이렇게 돼 있습니다. 네 연계 기술 7개 있었어요. 구분할 수 있게끔만 익히면 된다. 말씀드렸는데 한번 보도록 하겠습니다. db 링크는요 db 링크는 데이터베이스에서 제공하는 db 링크 객체를 이용해 맞죠.

58:34
db 커넥션은 수신 시스템의 프로그램에서 jdbc 드라이브를 이용을 하여 송신 시스템 db와 연결합니다. 이게 틀렸습니다. jdbc 연계 기술이 별도로 있었어요. jdbc 드라이버를 이용한 경우엔 jdbc 자바 데이터베이스 커넥션이라고 하는 연계 기술 별도로 있습니다. 웹서비스는 wsdl uddr 소프 프로토콜을 이용해서 연계한다. 그리고 소켓은 통신을 위해서 소켓을 생성하고 포트를 할당하고 클라이언트 요청할 때 연결한다. 설명 맞구요. 틀린 것은 2번 자 다음으로요 인터페이스 설계서 작성 파트로 넘어가서 먼저 살펴보고자 하는 부분은 인터페이스 설계서는 뭔데 인터페이스 설계서는 크게 두 가지로 구성되어 있습니다. 첫 번째가 인터페이스 목록 두 번째가 인터페이스 정의서 또는 명세서라는 이름을 같이 사용하거든요.

59:26
인터페이스 목록과 인터페이스 정의서로 구성되어진다 뭐가요 인터페이스 설계서는 자 먼저 살펴볼 건 인트페이스 목록입니다. 인터페이스 목록 개념과 예시인데 인트페이스 목록은 연계 업무와 연계에 참여하는 송수신 시스템에 관련된 정보를 담고 연계 방식과 통신 유형 등에 대한 정보를 포함한다. 인터페이스 시스템 인터페이스 목록의 양식의 예입니다. 보면 인터페이스 아이디 인터페이스 이름 송신기관 송신시스템 수신기관 수신시스템 그리고 대내외냐 대외냐 구분 연계 방식은 뭔데 그리고 통신 유형은 어떤 거야.

1:00:13
요충이 응답 담방양 처리 방식은 실시간적으로 처리야 배치 모아서 처리야 연계 주기는 메일이야 수시야 데이터 형식은 담당자는 누구고 요구 아이디까지 포함이 되어 있습니다. 양식이 이 양식의 구성 요소적인 부분을 더 구체적으로 정리를 하면 인터페이스 목록의 주요 항목으로서 인터페이스 아이디라고 하는 부분은 인터페이스를 구분하기 위한 식별자를 이야기한다. 인터페이스 이름 인터페이스명 인터페이스 목적을 나타내는 이름을 적어주면 되겠고 시스템 그리고 대내외 구분 송신 시스템은 수신 시스템은 그리고 이게 대내냐 대외냐 라는 부분을 표기하고 연계방식은 뭔데 앞서 저희가 연계방식 살펴봤었죠.

1:01:03
웹서비스 방식이냐 db 링크 방식이냐 소켓이냐 api냐 jdbc냐 등등 아키텍처 정의한 인티페이스 방식을 적어주면 되겠고 통신 유형은 단방향이냐 동기식이냐 비동기식이냐 등 그리고 처리 유형은 실시간 바로 처리하느냐 즉시적으로 처리하느냐 지연 처리냐 배치 방식이냐 등 주기는 인터페이스가 발생하는 주기를 적어주면 되겠고 데이터 형식은 고정비리 xml 등 인터페이스 항목에 데이터 포맷을 적어주고 마지막으로, 관련 요구사항 아이디 부분은 해당 인터페이스와 관련된 요구사항 식별 정보를 입력하면 됩니다. 자 다음으로, 인터페이스 정의서 또는 명세서라고도 합니다. 인터페이스 정의서 인터페이스 명세서 개념과 예시입니다.

1:01:52
인터페이스 명세 인터페이스 정의서는 데이터 송신 시스템과 수신 시스템 간의 데이터 저장소 데이터 저장소가 속성 등 상세 내역을 포함합니다. 인터페이스 목록보다 더 구체적으로 자 일례로 양식 시스템 인트페이스 정의선 양식인데요. 작아가지고, 좀 어 화면을 좀 크게 좀 볼 필요성이 좀 있을 것 같은데, 자 인터페이스에 제가 약간 확대해서 보여드리면, 시스템 인터페이스 정의서에 보면 구성요소 한번 양식 가지고 먼저 보고 좀 전에 인터페이스 목록을 세부적으로 살펴봤던 것처럼 그 절차대로 설명을 드리겠습니다. 인터페이스 아이디가 있고요. 그다음에 인터페이스 이름이 있네요.

1:02:39
그리고 설명에 대한 디스크립션 작성일 그리고 처리 이용은 뭔지 그리고 통신 유형 단방향이냐 동기식이냐 그다음에 주기능 처리 유형 통신 유형 주기 이러한 것들은 인터페이스 목록에도 기재가 되었던 항목들입니다. 인터페이스 구분도 되느냐 대외냐 데이터포맷 여기까지도 거의 같고, 최대처리 횟수라는 성능적인 부분에 대한 것이 인터페이스 정의서에 추가됩니다. 목록에는 없던 항목들이에요. 데이터크기는 얼마인데 그리고 밑에 송신 시스템 시스템명 업무 서비스명 그리고 인터페이스 방식 담당자 연락처까지 기재되어졌고 여기는 테이블 형태로 되어 있어요. 데이터 테이블 정의소입니다. 데이터 테이블 시퀀스 일련번호고 필드명 그리고 키라고 하는 부분은 얘가 키로 설정되어 있느냐 프라이머리 키 식별자 이야기하는 겁니다.

1:03:35
타입은 저장할 수 있는 데이터의 유형은 뭔데 그리고 사이즈 크기 값은 얼마 크기로 저장할 수 있느냐 nall 허용이라고 하는 부분 자체는 입력 안 해도 되는지 여부입니다. nol 허용하는 경우에는 y라고 하고요. 그렇지 않은 경우엔 n nll 입력 안 받아 반드시 입력해야 된다. 이 말이고 디스크립션 설명 그리고 컨디션이 이렇게 이렇게 되어 있어요. 네 확대해서 좀 살펴봤습니다. 구체적으로요 인터페이스 정의서의 주요 항목들 정리해 보겠습니다. 인터페이스 이름은 인터페이스를 구분하기 위한 식별자야 명령 표준에 맞게끔 부여를 해야 되고 최대처리 횟수 단위 시간당 처리될 수 있는 해당 인터페이스의 최대 수행 건수를 입력하는 부분이고요.

1:04:28
그리고 데이터 크기 해당 인터페이스 1회 처리할 때 소요되는 데이터의 평균 크기와 최대 크기 시스템정보 송수진 시스템 이름 업무명 서비스명 프로그램 아이디 연계 방식 담당자 연락처 그리고 데이터 정보 송수진 시스템 각각에 대해서 작성하는데 항목 송번 필드 이름 식별자 여부 네 아까 키 여부 데이터 타입 데이터 문자열이야 뭐 숫자를 입력받는 데이터야 이런 것들을 적는 부분이고 구분 그다음에 데이터 크기는 넣을 허용 여부 설명 조건 데이터 전체 길이 등이 데이터 정보에 해당되어집니다. 인터페이스 설계서 작성 파트에 대해서 퀴즈 인터페이스 목록과 인터페이스 정의서 또는 명세서 주요 항목에 공통적으로 포함되지 않은 건 뭔데 라고 묻고 있습니다.

1:05:23
제가 설명하면서 아까 힌트를 드렸죠 이 문제화해서 나오기 때문에 미리 힌트 드린 겁니다. 좀 집중적으로 보시라고 힌트페이스 아이디 다 있었고, 힌트페이스 이름 통신 유형 최대 처리 횟수는 인터페이스 정의서에만 있었어요. 그래서 공통적이지 않은 건 최대 처리 횟수 두 번째 아 모의평가 세 문제 풀어보도록 하겠습니다. 내외부 송수신 연계 방식 중에 두 가지가 있었잖아요. 직접 연계 방식과 간접 연계 방식이 있었습니다.

1:06:03
간접 연계 방식의 장점이 아닌 거 간접 연계 방식의 장점이 아닌 거 첫 번째 서로 상이한 네트워크와 프로토콜 등 다양한 환경을 갖는 시스템들을 연계하고 통합 관리할 수 있어 직접 연계 방식은 이게 힘들었어요. 근데 간접은 장점이었죠. 텐트페이스 변경 시에도 유연하게 대처가 가능하다 네 간접 연계 방식의 장점 보안이나 업무 처리 로직 반영이 용이하다 맞죠. 암호화라든지 네 일반적인 연계처리 속도가 빠르고 구현이 단순하며 개발 비용과 개발 기간이 짧다는 부분은 간접 연계의 장점이 아니었고 직접 연계 방식의 장점이었습니다. 틀린 것은 4번 두 번째입니다.

1:06:58
인터페이스 처리 유형 중에 배치 방식에 대한 설명 중 올바르지 않은 것은 틀린 거 골라라 이렇게 돼 있습니다. 1번 매 건 단위로 처리할 경우에 비용이 많이 발생을 할 때 적합하다 자 아까 처리 유형을 세 가지로 제가 구분을 했었거든요. 실시간 적시적으로 처리 그 다음에 실시간 방식인데 바로 처리하지 않고 약간 연기했다가 즉 지연처리라는 게 있었고, 그 다음에 세 번째가 배치였거든요. 지연처리는 언제 하는데 4건 단위로 처리할 경우 비용이 많이 발생할 때 그래서 1번의 설명문구는 지연처리에 대한 설명입니다. 배치에 대한 설명이 아니고 두 번째 대량의 데이터를 한 번에 처리할 때 적합하던 타이머에 의한 방식 연계 스케줄에 의해 구성되는 이벤트 방식이 있고 통신 유형은 db 파일 거래가 된다. 네 틀린 것은 1번 3번입니다.

1:07:56
다음 중 인트페이스 오류 처리 인트페이스 오류 처리와 관련되어진 설명 중에 틀린 것은 자 문구가 좀 문장이 좀 깁니다. 천천히 보도록 하겠습니다. 1번 인터페이스 오류가 발생한 경우에 연계 서버와 송수신 시스템의 로그 파일의 오류 코드하고 에러 발생에 대한 상세 내용을 기록하도록 연계 프로그램 작성을 먼저 해야 된다. 맞구요. 그리고 오류 코드는 오류를 식별할 수 있는 코드이고 오류 발생지와 오류 유형과 일련번호를 포함하여 오류 코드 명령 규칙을 정의해야 한다. 맞습니다. 연계 데이터 오류는 시스템 담당자를 통해서 접속 오류를 해결한 후에 재전송할 수 있다. 이게 틀렸습니다. 시스템 담당자를 통해서 접속 오류를 해결하고 재전송은 이건 접속 오류예요.

1:08:55
연계 데이터 오류가 아니라 접속과 관련된 오류 그래서 틀린 건 3번 4번 오류 발생할 때 오류 발생 시 인터페이스 담당자는 연계 서버와 송수신 시스템에 기록된 로그파일 내용 확인하고 어떤 오류야 파악한 다음에 해결방안을 수립한다. 맞는 설명입니다. 자 핵심 내용 인터페이스 방법 명세화 부분에서는 개발하고자 하는 응용 소프트웨어의 내부와 외부 인터페이스를 위한 송수신 방법과 필요 데이터 그리고 오류 처리 방안 명세화적인 부분에 대한 내용을 다뤘고요. 인트페이스 설계서 작성 부분에서는 힌트페이스 설계서는 어떤 걸로 구성된다. 인터페이스 목록 그리고 인터페이스 정의서 인터페이스 목록과 인터페이스 정의서 해당 구성 항목들 공통적인 것도 있었고, 더 포괄적인 건 뭐다 인터페이스 정의서 인터페이스 명세서가 더 포괄적이었죠.

1:09:52
해당 데이터와 관련된 정보들도 포함돼 있었고, 자 이상으로 인터페이스 상세 설계에 대한 학습 내용 마치도록 하겠습니다.

https://youtu.be/Ee1DJ3HQjHM?si=muCxbkeFdKa3N0jw

1. 소프트웨어 설계를 위한 공통 모듈 설계

1-1. 공통 모듈 설계의 개요
- 공통 모듈 설계란 시스템 구축 시 공통으로 사용되는 모듈을 묶은 소프트웨어를 의미함
- (중요) 재사용성과 표준화를 위해 공통 모듈 설계를 이용함
- 공통 모듈은 클래스, 라이브러리, 컴포넌트, 프레임워크 네 가지 종류가 있음
- 공통 모듈 설계에는 하향식과 상향식 공통 모듈 도출 방식이 있음

1-2. 공통 모듈 도출의 과정
- 공통 모듈 도출은 요구사항을 중심으로 기능 목록을 선별해 공통 모듈을 도출함
- 이는 요구사항을 기술한 기술서를 바탕으로 모델링을 진행함
- 유즈 케이스 다이어그램을 그린 후 정적 모델링으로 클래스 다이어그램, 컴포넌트 다이어그램, 동적 모델링으로 시퀀스 다이어그램과 액티비티 다이어그램을 만듦
- (중요) 공통 모듈 도출의 핵심은 요구사항 정의와 기능 목록 선별임

1-3. 공통 모듈 도출의 필요성과 적용
- 공통 모듈 도출을 통해 중복 개발을 방지하고 개발비용을 절감 가능함
- 모듈 간의 표준화를 통해 소프트웨어 품질을 높일 수 있음
- (중요) 공통 모듈 도출은 다양한 부서에서 사용하는 기능을 공통으로 사용하는 추세를 반영함
- 이에 따라, 기존의 개발 프레임워크에서 공통 기능을 도출해 사용하는 추세임

2. 유즈 케이스 명세서와 공통 모듈 평가

2-1. 유즈 케이스 명세서의 필요성과 형식
- 유즈 케이스 명세서는 시스템 유즈 케이스를 정의하고 관리하는 도구임
- (중요) 유즈 케이스 명세서의 각 항목은 유즈 케이스의 이름, 목적, 유지 케이스를 이용하는 액터, 필요 조건 등을 포함함
- 유즈 케이스의 정상적인 흐름, 대체 흐름, 예외 흐름 등을 설명하고 있음
- 이 명세서는 유즈 케이스의 특성에 따라 대응하는 시스템이 구성되어야 함

2-2. 클래스 다이어그램과 시퀀스 다이어그램
- 유즈 케이스 명세서에서 클래스 다이어그램과 시퀀스 다이어그램을 활용하여 시스템을 표현함
- 클래스 다이어그램은 클래스의 모양과 동작을 바탕으로, 시퀀스 다이어그램은 시간적 순서에 따라 객체 간의 관계를 나타냄
- 시스템이 생성하는 오류 메시지를 처리하고, 유즈 케이스 명세서를 통해 대응하는 방식을 설명함
- (중요) 각각의 클래스나 인터페이스를 이용하여 클래스 다이어그램을 그려야 함

2-3. 공통 모듈의 응집도와 결합도
- 공통 모듈의 응집도는 클래스 간의 연계 정도를 의미하며, 응집도가 높을수록 설계가 잘 됐다고 판단됨
- (중요) 결합도는 모듈 간의 연계 정도를 의미하며, 결합도가 높을수록 모듈 간에 서로 다시 호출하는 경우가 많음
- 응집도와 결합도는 모듈의 품질을 평가하는 중요한 지표로, 이 두 가지 요소를 고려하여 모듈을 설계하고 평가해야 함

3. 소프트웨어 설계

3-1. 객체 지향 방법론
- 객체 지향 방법은 실 세계의 객체를 속성과 메소드로 나누어 객체로 정의함
- 객체는 클래스로 묶인 꾸러미이고, 클래스 간의 관계는 인스턴스로 표현됨
- 객체 지향 방법의 특징은 객체 인스턴스, 객체 속성, 객체 메소드로 구성됨
- 디자인 패턴은 개발자들의 경험을 추상화, 일반화시킨 템플릿임
- 디자인 패턴을 활용하면 효율성과 재사용성을 높일 수 있음

3-2. 디자인 패턴의 이해
- 디자인 패턴은 객체 지향 방법의 개념과 특징을 정리한 것임
- 디자인 패턴은 개발자들이 프로그램 모델을 경험적으로 체득한 것에서 나온 템플릿임
- 디자인 패턴을 활용하면 효율성과 재사용성을 높일 수 있음
- 디자인 패턴의 종류는 다형, 중첩, 연결, 단순, 복합, 다층, 복합 다형이 있음
- (중요) 디자인 패턴은 객체 지향 방법의 핵심 요소이니 숙지해야 함

3-3. 객체 간 관계와 설계 원칙
- 객체 지향 설계는 객체, 객체, 클래스 간의 관계를 모델링함
- 클래스 간의 관계는 인스턴스로 표현되며, 객체 간의 관계는 클래스 간의 관계로 이어짐
- 객체 지향 설계의 특징은 개별 객체, 객체 간의 관계 모델링, 중첩과 순서 정의임
- 객체 지향 설계의 핵심은 재사용성과 개별 객체의 독립성임
- 객체 지향 설계는 객체, 객체 간의 관계에 대한 다양한 테마를 제공함

4. 객체지향 개념

4-1. 객체와 객체지향 특징
- 객체를 모델링해 클래스와 객체명을 정의함
- 객체의 특징을 나타내 속성과 동작을 추상화, 상속, 다형성, 캡슐화, 정보 은닉으로 정의함
- (중요) 추상화는 객체 모델링 시 필요로 하는 부분만 추출해 속성과 동작을 정의함
- 상속은 부모의 형질을 자식에게 물려주어 코딩이 수월해지고 유지보수가 용이함
- 다형성은 상속을 통해 자식이 부모의 동작을 이용하면서도 각자의 특징을 유지함

4-2. 객체의 관계와 설계 원칙
- 객체는 서로 연관되어 있으며, 이를 관계(어소시에이션)로 표현함
- 관계는 상호 의존적이면서도 별개의 존재로, 타 객체와의 연관을 가짐
- 상호 의존적인 관계는 '집합 연관'이라고도 불림
- 집합 연관은 상위 클래스와 연결할 때 '인터페이스 연결점'을 통해 비어 있는 삼각형을 표시함

4-3. 클래스 간의 관계와 설계 원칙
- 클래스 간의 관계는 연관되거나, 추상화(상속)로 인해 연결될 수 있음
- 연관은 상호 의존적이면서도 별개의 존재로, 일례로 '사람-티비' 관계가 있음
- 추상화(상속)는 관계를 통해 더 높은 계층에서 더 일반적인 개념을 가진 클래스로 관계를 이어가며, 이는 '집합 연관'이라고도 불림
- 상위 클래스와 연결할 때는 인터페이스 연결점을 통해 연결을 명확히 함

5. 객체지향 디자인

5-1. 객체의 관계형성과 관련 패턴
- 객체 관계 형성 시엔 다형제와 복합형제가 존재함
- 다형제는 동일한 클래스에서 구분되며, 복합형제는 객체들이 실제로 같이 연결되어야 함
- 복합연관은 해당 관계가 기능적으로 서로 연관되어야 함
- 집합과 복합의 차이는 연결되어야 하는 클래스가 따로 떼어져도 기능적으로 동작할 수 없을 때 나타남
- (중요) 관계형성 시엔 리스코프 교체의 원칙에 따라 상위 클래스가 하위 클래스로 대체되어야 함

5-2. 클래스 설계 원칙과 디자인 패턴
- 클래스 설계 시 단일 책임, 개방 폐쇄, 상속, 변경 시 안 됨을 원칙으로 함
- (중요) 상속 관계에서는 개방되어야 하고, 변경 시 닫혀 있어야 함
- 의존 관계 역전 원칙에 따라 추상 클래스에 실제 클래스 의존 필요
- (중요) 법령적 목적의 단일 인터페이스보다 다형제를 많이 갖도록 설계
- 디자인 패턴은 다양한 개발자 경험에서 검증된 설계 지식의 추상화로, 객체 지향 설계에서 주목받기 시작함

5-3. 디자인 패턴의 분류와 적용
- 디자인 패턴은 목적에 따라 생성 패턴, 구조 패턴, 행위 패턴으로 나뉨
- 목적에 따라 패턴의 종류를 나누고, 이 중 생성 패턴이 가장 많음
- (중요) 생성 패턴 중 팩토리 메소드, 앱스트랙션, 팩토리 빌드, 프로토타입, 싱글톤 패턴은 기억해야 함
- 구조 패턴은 어댑터 패턴, 브릿지 컴파워지 데코에이션, 페케이드 플라이어 웨이트 프렉시, 7개 패턴으로 기억
- 행위 패턴은 11개 패턴으로 기억, 그중 가장 적은 것이 어댑터 패턴임

6. 객체지향 프로그래밍의 이해

6-1. 객체지향 프로그래밍의 개요
- 객체 지향 프로그래밍은 캡슐화, 다형성, 상호작용, 추상화, 복합관계 등을 활용함
- 객체 지향 프로그래밍을 통해 개발 프로세스가 효율적이고 재사용 가능해짐
- (중요) 객체 지향 프로그래밍을 통해 모델링이 가능해져 시스템의 재사용성이 높아짐
- 객체의 특징은 추상화, 물려받는다, 상수, 다형성, 그리고 묶음이며, 이들을 통해 객체의 특성을 표현함

6-2. 객체지향 프로그래밍의 장점
- 객체지향 프로그래밍을 통해 개발 프로세스가 효율적이고 재사용 가능해짐
- (중요) 이는 소프트웨어의 품질 향상, 개발자 간의 의사소통 원활, 그리고 소프트웨어의 생산성을 높여줌
- 또한, 객체 지향 프로그래밍은 설계 지식의 일반화를 가능하게 함
- 이는 효율성과 재사용성을 높이고, 개발자의 작업 부담을 줄여줌

6-3. 객체지향 설계의 구체적 이해
- 객체 지향 설계는 속성과 메서드를 결합해 하나의 객체를 생성함
- 객체 간의 관계는 모델링을 통해 표현되며, 이는 객체 지향의 주요 특징임
- 디자인 패턴은 객체 지향 설계의 효율성과 재사용성을 높이는 방법임
- (중요) 디자인 패턴은 생성패턴, 구조패턴, 행위패턴 등 5가지로 나뉘며, 각각의 패턴은 목적이 다름

00:02
네 소프트웨어 설계 세 번째 과목인 애플리케이션 설계 애플리케이션 설계는 두 파트로 나눠집니다. 그중에서 첫 번째 공통 모듈 설계하기 살펴보도록 하겠습니다. 학습목표입니다. 공동 모듈의 개념을 설명하고 공통 모듈을 도출하고 분리해낼 수 있다. 둘째, 공통 모듈 설계를 위한 모듈화 원리를 이해할 수 있다. 셋째, 모듈화 지표인 결합도를 이해하고 결합도를 줄일 수 있는 낮출 수 있는 방법을 적용한다. 할 수 있다. 마지막 모듈화 지표인 응집도를 이해하고 응집도를 최대화 높일 수 있는 방법을 적용할 수 있다. 입니다. 학습 내용은 공통 모듈 개요 공통 모듈 도출 설계 평가 순으로 살펴보도록 하겠습니다.

01:01
용어사진입니다. 공통 모듈이란 시스템을 구축할 때 여러 하위 즉 서브 시스템에서 공통으로 사용되는 모듈을 모아놓은 소프트웨어 묶음으로써 소프트웨어의 중복 구현을 줄여주고 재사용성을 높이기 위한 소프트웨어가 되겠습니다. 둘째, 응집도입니다. 응집도는 인터페이스 요청을 처리함에 있어서 공통 모듈 내에 있는 클래스들 간에 얼마나 유기적으로 서로 간에 협업하여 처리하는가에 관한 정도가 되겠고 마지막으로, 결합도는 어떤 모듈이 다른 모듈에 의존하는 정도가 되겠습니다. 공통 모듈 개념입니다. 공통 모듈이란 시스템을 구축할 때 여러 하위 시스템 즉 서브 시스템에서 공통으로 사용하는 공통으로 사용되는 모듈을 뜻한다.

02:02
자 표준 플랫폼이 있고 공통 모듈 이렇게 모아놓은 것들 있죠. 일단 이 공통 모듈은 다른 쪽에서도 같이 사용할 수 있다. 이렇게 이해하시면 될 것 같고요. 다음 공통 모듈의 사용 목적입니다. 공통 모듈을 만드는 이유는 주 목적이 재사용입니다. 재사용 새로운 서버 시스템이 만들어지면 공통 모듈에서 다른 쪽에서도 재활용이 가능하다는 거죠. 같이 사용하니까 한쪽에서 만들면 다른 쪽에서 안 만들어도 돼요. 그러다 보니까 중복 개발을 방지할 수 있어요. 그래서 개발비용 절감에 도움이 되고 또한 이제 이러한 과정을 통해서 모듈 간의 표준화를 추가할 수가 있습니다. 그래서 궁극적으로 소프트웨어의 품질을 높일 수가 있겠습니다. 공통 모듈의 종류입니다. 공통 모듈의 종류는 클래스 라이브러리 컴포넌트 프레임워크 네 가지가 있습니다.

03:02
세부적으로는 클래스는 공통 모듈을 실제로 구현하는 객체인데 공통 모듈이 존재할 수 있는 가장 기본적인 형태가 되겠습니다. 지금 화면에 보이는 부분은 해당 자바 클래스에 대한 소스입니다. 말자바 클래스다 나중에 저희가 프로그램 언어 파트에서는 자바를 주로 살펴볼 거고요. 그리고 특히 실기 파트에서 해당 소스에 대한 분석을 반복해서 저희가 익힐 겁니다. 개괄적인 툴로만 우선은 어 처음 접하는데요. 이거 다 알아야 되나요? 몰라도 됩니다. 퍼블 클래스 익셉션 클래스에 대한 해당 메인 메소드에 대한 정의 등등 넘어가겠습니다. 라이브러리나 라이브러리는 여러 개의 클래스가 합쳐진 묶음을 뜻합니다.

03:54
마이퍼스트 자바 클래스 이렇게 세컨드 서드 이렇게 이름이 안 바뀌어 있는데, 이렇게 여러 개의 클래스를 묶어서 배포 파일이 확장자가 자르 파일이거든요. a.0로 묶어 놓은 거다 하나의 자바 클래스로 쓰이기보다는 여러 개의 자바 클래스가 묶인 형태인 라이브러리 형태로 재사용이 될 수 있다. 컴포넌트입니다. 컴포넌트는 라이브러리가 좀 더 체계화된 형태의 소프트웨어다 규모적인 측면에서 순차적으로 범위 규모가 커진다 이렇게 이해하셔도 될 것 같습니다. 컴포넌트는 독립적으로 동작하고 또 구현할 수 있고 영세와 패키지와 배포가 가능합니다. 내 외부 인터페이스를 통해서만 접근할 수 있다라는 특징이 있습니다. 그림 자체는 uml로 나타낸 해당 컴포넌트 다이어그램이 되겠습니다.

04:51
컴포넌트는 사각형에 이렇게 조그마한 직사각형이 두 개가 붙어 있는 모양을 가집니다. 네 번째 프레임워크입니다. 여러 가지 기능을 하는 클래스들이 서로 유기적 관계를 맺으면서 어떠한 기능을 수행하는 클래스 혹은 컴포넌트들의 집합이 됩니다. 프레임워크의 종류는 스프링 프레임워크라든지 단내 프레임워크라든지 전자 정보 프레임워크 등이 있고요. 라이브러리와 프레임워크는 어떻게 차이가 있나요? 라이브러리는 클라이언트 소프트웨어가 일방적으로 호출만 하고 끝인데 프레임워크는 클라이언트 소프트웨어가 호출을 하기도 하고 또 호출을 당하기도 하고 서로 간의 상호 유기적인 관계 그런 차이점이 있습니다.

05:44
관련되어진 해당 퀴즈 문제 보도록 하면 다음 중 소프트웨어 공통 모듈의 종류가 아닌 것은 클래스 라이브러리 컴포넌트 프레임워크 cpu가 아니죠. 틀린 것은 3번 cpu입니다. 공통모듈도출입니다. 공통 모듈 도출을 하는 기준으로서 방식을 하향식 공통 모듈 도출과 상향식 공통 모듈 도출 살펴보도록 하겠습니다. 하향식이라는 것은 위에서부터 아래로 이미 만들어진 개발 프레임워크에서 제공을 하는 공통 기능을 공통 모듈로 정해서 재사용하는 것을 이야기합니다. 계정관리 로그인 관리 시스템 관리 공통 기능으로 써요 이러한 것들이 있는데, 우리는 개발 프레임워크에 있는 계정관리를 그대로 따와서 우리가 이용할 거야.

06:43
이렇게 위에서부터 아래로 뽑아서 사용하는 방식이고 상향식 공통 모델 도출이라는 부분은 밑에 실제적으로 해당 요구사항들을 중심으로 만들어진 기능 목록 중에서 공통적인 기능을 뽑아가지고, 즉 여러 부서에서 공통으로 사용하는 기능들을 뽑아서 선택하는 방식이다 라고 보면 되겠습니다. 인사부서에서도 또는 영업부서에서도 직원 조회나 이러한 것들을 사용하더라 그런 경우에는 뽑아가지고, 공통 모듈로 선택할 수 있겠습니다. 공통적인 도출과 관련되어진 퀴즈 문제입니다. 다음 중 공통 모듈의 대상으로 적합하지 않은 것은 문제를 잘 보셔야 돼요.

07:31
맞는 거냐 틀린 거냐 라는 부분 아는 거 틀린 거 전 부서 모든 부서에서 사용하는 직원 조회 기능이야 전체적으로 사용하니까 공통으로 뽑는 게 좋겠고 개발 프레임워크에서 공통으로 제공하는 시스템 관리 기능이야 이건 하향식이겠죠. 모든 부서에서 사용하는 전표 정리야 모든 부서 생산부서에서만 사용하는 생산지식 기능이야 특정 부서에서만 사용하니까 얘는 공통 모듈로 대상으로 뽑는 것은 부적합하겠습니다. 공통 모듈 설계입니다. 네 공통 모듈 설계 순서 모델링 제의문에 대한 uml로 어떻게 모델링하는지 그 과정 질문을 설명하고 있는 부분이 되겠고요. 먼저 요구사항들을 뽑아서 나열해놓은 정리해놓은 요구사항 기술서를 베이스로 해서 먼저 유즈 케이스 다이어그램을 그립니다.

08:27
유즈케이스 다이어그램은 시스템이 담당해야 될 기능적인 부분을 정리하는 부분이거든요. 이 유지케이스 다이어그램을 바탕으로 다시 정적 모델링으로서 클래스 다이어그램과 컴포넌트 다이어그램 그리고 동적 모델링으로서 시퀀스 다이어그램과 액티비티 다이어그램을 순차적으로 만들어 갑니다. 유스케이스 다이어그램 작성은 보는 예제처럼 이렇게 그려져 있는데, 막대 인형이 액터입니다. 액터 사용자 사람이 될 수도 있고요. 시스템이 될 수도 있습니다. 그 다음에 동그라미 타원형으로 되어있는 부분들이 유즈 케이스 하나의 유즈 케이스에는 하나의 업무만 담당하도록 설계를 하고요. 그리고 액터는 그 유즈 케이스를 수행하는 당사자가 되겠다. 해당 이 액터가 이용하는 유즈 케이스에 대해서는 이렇게 관계를 설정을 하면 되겠고요.

09:24
유즈 케이스와 유즈 케이스 간의 관계는 다시 포함하는 인클루드 관계와 그러니까 인클루드는 일반적으로 필수관계라고 생각하시면 될 것 같고요. 쉽게 구분할 수 있는 방법은요, 회원가입하기 위해서는 반드시 주소 입력이 필수야 그러면 얘를 이용을 해야 되는 거고, 익스텐드라고 하는 부분은 확장입니다. 얘는 옵션입니다. 주문 결제를 하는데 결제방식으로서 포인트 결제만 해야 되는 게 아니라 현금결제도 할 수 있고 신용카드 결제도 할 수 있죠. 인클루드와 익스텐드 구분할 수 있으면 되겠고 다음 유즈 케이스가 유즈 케이스 다이어그램이 작성되어지면 그다음에 하는 부분은 뭐냐 하면 유즈 케이스 명세서를 기술합니다. 유즈 케이스 명세서 양식의 일반적인 양식인데요. 제일 상단에 유즈 케이스 이름이 들어가지고요.

10:19
그리고 목적 그리고 해당 이 유지 케이스를 이용하는 액터 그리고 이 유지 케이스를 이용하기 위해서는 사전에 어떤 조건이 갖춰져야 돼 일례로 회원가입을 한다고 되어 있으면 시스템이 켜져 있어야 돼요. 시스템은 켜져 있고 로인 대기 상태가 되어져야지 회원 가입을 할 수 있다. 그리고 사후 조건은 회원가입을 하고 난 다음에 해야 되는 반드시 해야 되는 거 여기서는 없음으로 돼 있고 포함 확정 유지 케이스는 없어 정상적인 흐름이 있고요. 일반적인 흐름이 있고 그다음에 이 흐름상에서 선택적으로 해야 되는 경우가 있는 경우를 대체 흐름에 기술을 합니다. 올터너티브 정상적인 회원가입 절차는 이 절차로 쭉 수행을 하는데 그런데 대체어렴에서는 여기 보면 저희 ex적인 부분은 여기 ex라고 되어 있는 부분은 예외어램입니다. 예외어렴이라는 건 어떤 오류라든지 이러한 것들 자 순서상에서요 간단히 살펴보겠습니다.

11:18
너무 깊게 안 들어갈게요 이 파트도 마찬가지로 저희 실기 파트 첫 번째 세부 과목인 요구사항 확인 파트에서요 uml은요, 작성 방법 종류 이런 것들 다 정리할 테니까. 실기에서 좀 더 세부적으로 다루겠습니다. 그래서 개괄적으로 정상 흐름이 있고 대체 얼음이 있고 예외 흐름이 있다. 예외 흐름이라는 건 옳으라는 말입니다. 시스템에 중독번호가 유효한지 확인하는데 중독번호 잘못됐어 그런 경우에 오류 메시지를 띄워라 이 말이고요. 아이디 중복 체크를 했는데 중복된 경우가 생겼어 그럼 이거 사용 못해 다른 거 사용해 라고 알림을 띄운다든지 이렇게 보시면 되겠습니다. 유즈케이스명세서 자 그 다음에 클래스 다이어그램 작성입니다. 네 클래스 다이어그램 설계 클래스 다이어그램을 그려놓은 예시가 되겠는데요. 클래스 타이그램은 종류가 세 가지가 있습니다.

12:14
세 가지를 라디오 타입으로 해서 위에 단에다가 이렇게 표기를 해서 이렇게 꺾쇠 꺾쇠 이렇게 해서 표기를 해서 바운더리 화면 그다음에 컨트롤 그다음에 나중에 테이블로 저장되어지는 엔터티 이렇게 세 가지가 있는데, 표시를 이렇게 해가지고 하고요. 기본적으로는 사각김박스로 그립니다. 그다음에 3등분 해가지고요. 상단이 해당 클래스 이름값 그다음에 여기가 속성 중간단 마지막으로, 여기가 동작적인 부분에 대한 오퍼레이션 또는 메소드를 세 번째로, 메소드는 반드시 갈록 구름을 가집니다. 유즈케이스 명세서에서 사용되어진 명사에서 정리한 문구 중에 명사를 클래스 후보로 선정할 수 있고요. 그리고 유즈케이스에 사용되어진 동사 행위를 나타내는 동사 중에서 클래스의 동작을 나타내는 오퍼레이션으로 선정할 수 있고요.

13:13
그리고 유스케이스에서 사용되는 명사의 특징에서 속성 나중에 변수가 되는 거죠. 속성으로 선정할 수도 있다. 마찬가지 실기파트의 요구사항 분석 uml 파트에서 더 세부적으로 다루겠습니다. 시퀀스 다이어그램을 그립니다. 시퀀스 다이어그램은 시간적 순서에 따라서 해당 객체가 어떤 객체한테 어떤 메시지를 주고요. 순차적으로 어떻게 수행되어지는지 순차적 흐름적인 부분을 그려놓은 다이어그램입니다. 액터 유즈 케이스 다이어그램에 있는 액터를 그대로 사용하고요. 그다음에 시스템은 시스템 클래스에 있는 클래스 다이어그램에 있는 클래스 혹은 인터페이스를 사용하고요. 그리고 시퀀스는 해당 유스켓이 정해져 있는 행위의 흐름을 시퀀스 순차적으로 이렇게 회원가입 고객이요. 로그인 화면이 있고요.

14:12
클래스에 대한 표시 방식은 두 번째 표시 방식은 얘가 화면이에요. 이게 바운더리 화면 그다음에 동그라미에 화살표 되어 있는 부분은 얘가 컨트롤입니다. 제어 그다음에 동그라미 밑줄 그어져 있는 부분이 얘가 엔터티 두 가지 방식이 있습니다. 표현이 해당 순차적으로요 순번에 맞춰가지고 1 회원가입 요청해 로그인하면서요 해당 입력해야 될 회원가입 폼 양식을 작성하겠고 그다음에 로그인 화면에서 회원가입을 요청하게 되면 회원가입 폼이 나타나야 되죠. 회원가입 화면이 나타나고 그다음에 회원가입에 필요한 이름이나 주민번호번호를 입력을 하고 그다음에 실명인증을 요청하게 되면 회원가입을 처리하는 처리 페이지에서 처리를 하고요.

15:09
확인한 다음에 순차적으로 이렇게 진행되어진다 이렇게 보면 되겠습니다. 다음 공통 모듈 평가입니다. 공통 모듈의 평가 지표로서는 크게 똑같이 시험에 자주 나옵니다. 응집도 개념과 결합도 개념 정리하도록 할 건데 응집도라고 하는 부분은 인터페이스의 요청을 철회함에 있어서 공통 모듈 내에 클래스들 간의 인터뷰의 요청을 처리함에 있어서 공통 모듈 내에 있는 안에 있는 클래스들 간에 얼마적으로 내부적으로 이렇게 유기적으로 협업해서 처리하는가를 나타내는 정도가 응집도고요. 응집도는 높아야지 잘 설계되어진 모듈이 됩니다. 그래서 엄집도는 높여야 됩니다. 그리고 결합도는 모듈과 모듈 간에 다시 얘가 a라는 모듈의 b라는 모듈이 많이 종속적이다. 이러면 별로 설계가 바람직하지 못합니다.

16:08
그래서 오히려 결합도는 커플링을 낮춰야 됩니다. 세부적인 언집도 공통 모듈레이의 클래스들이 외부 기능을 수행함에 있어서 얼마나 서로 클래스들끼리 내부적으로 연계되어서 수행하는지를 나타낸다 그림상에서 보게 되면 왼쪽보다 오른쪽이 해당 공통 모듈 내의 엄집도가 훨씬 더 높습니다. 내부에 있는 클래스들 간의 서로 간의 연계 정도가 더 높게 나오죠. 오른쪽이 보다 바람직하게 설계된 부분이다. 이렇게 보면 되겠고요. 응집자의 종류 둘 넷 여섯 일곱 가지 있어요. 일곱 가지 있는데, 세부적으로 물을 때는 간혹 해당 응집자에 대한 설명 문구를 제시해 놓고요.

17:02
여기에 해당되는 응집도는 뭔데 라고 묻는 케이스로 출제가 시험 문제가 출제될 수도 있습니다. 응집도는 7개가 있는데, 7개 중에 기능적 응집도가 응집도가 제일 높아요. 네 기능적 응집도가 응집도가 제일 높습니다. 기능적 응집도라는 부분은 모듈 내부의 모든 기능이 단일한 목적을 위해서 수행하는 경우가 되겠다. 순차적 응집도 모듈 내에 한 활동에서부터 나온 출력값을 다른 활동에 사용하는 경우 통신적 응집도 동일한 입력과 출력을 사용해서 다른 기능을 수행하는 활동들이 모여 있는 경우 절차적 응집도 시간적 응집도 논리적 응집도 우연적 응집도는 모듈 내부의 각 구성요소들이 연관이 없는 경우다 응집도가 제일 낮은 게 우연적 응집도입니다.

17:57
자 해당 정도적인 부분에 대한 문제를 물을 때 조금 복잡하게 변별력적인 부분을 갖고 난이도 있게 하는 경우에는 순서를 따지는 경우도 있단 말이에요. 그런 경우에는 해당 이 머릿걸을 위주로 해서 익혀 놓으시면 네 기순 여러분들이 나름대로 연상할 수 있는 어떠한 문구적인 부분과 매칭시켜가지고, 해당 기순통 절시 노누 네 여기에 해당 나름대로 쉽게 암기할 수 있는 문장을 만들어 가지고 해 놓으시면 나중에 여러분들이 당장은 이제 안 된다 하더라도 시험장 가시기 전에 한번 이렇게 문장을 이렇게 만들어서 정리해 놓으면 혹시나 순서적인 측면으로 난이도 있게 이렇게 이렇게 나오면 풀 수 있게끔 준비를 하시면 좋을 것 같습니다. 결합도입니다. 결합도는 프로세스를 철회함에 있어서 각각의 공통 모듈이 서로 연계되어 있는 정도를 이야기한다.

18:54
근데 이 결합도는 높아야 좋은 게 아니라 낮아야 좋습니다. 낮다 라는 부분은 결합도가 낮다 라는 부분은 모듈 내에서의 응집도가 높다는 말이거든요. 그래서 다른 공통 모드를 호출해야 되는 경우가 많다 그런 경우에는 그 공통 모드는 결합도는 높지만, 품질도는 높지가 않다 라는 부분입니다. 이렇게 정리하겠습니다. 결합도도 종류가 지금 6개씩 쓰여져 있는데요. 내용 결합도 공통 결합도 외부 결합도 제어 결합도 스탠드 결합도 자료 결합도가 제일 높은 것은 내용 결합도가 제일 높습니다. 이 결합도가 높다라는 말은 모듈 간에 서로 다시 호출하는 경우가 많다 이 말입니다. 근데 소프트웨어적인 측면에서는 이게 바람직하냐? 바람직하지 않다 라는 부분입니다. 그래서 결합도는 낮아야 좋습니다.

19:50
자료결합도는 모듈 간 인터페이스로 전달하는 파라미터를 통해서만 모듈 간의 상호작용이 일어나 모듈 간 인터페이스를 통해 전달되는 파라미터를 통해서만 서로 간에 호출의 경우의 수가 많지 않다 이 말입니다. 마찬가지 케이스로요 해당 결합될 정도적인 부분을 묻는 문제가 혹시나 나올 수 있다면 앞에 있는 머릿걸 따내 가지고요. 여러분들이 이렇게 문장화해서 암기해 놓으시면 네 수월할 것 같습니다. 내공이 외제가 스자야 이런 식으로 나름대로의 문장을 만드셔가지고, 정리해 놓으시면 좋을 것 같습니다. 자 마지막으로, 문제 풀이하면서 정리하겠습니다. 첫 번째 다음 중 공통 모듈의 종류가 아닌 건 뭔데 공통 모듈의 종류 클래스 라이브러리 메모리 프레임어 이렇게 돼 있습니다. 공통 모듈의 종류는 클래스 라이브러리 프레임워크는 맞고 메모리는 하드웨어의 장치명이죠.

20:48
메모리가 엉뚱한 보기로 제시되었기 때문에 고를 수 있겠죠. 다음 두 번째 공통 모듈의 품질 기준에 대한 설명으로 틀린 것을 골라라니 맞는 게 아니라 틀린 겁니다. 응집도는 높을수록 품질이 좋다. 맞죠. 결합도는 낮을수록 품질이 좋아 맞습니다. 결합도는 하나의 공통 모듈이 타 모듈과의 연관관계에 관한 정도를 이야기해 그렇죠. 모듈 간에 서로 호출정도 이것도 맞아요. 응집도는 낮아야 결합도는 높아야 품질이 좋아 이게 틀렸습니다. 반대죠 응집도는 높아야 되고요. 결합도는 낮아야 품질이 좋습니다. 다음 세 번째 공통 모듈을 설계할 때 정적 모델링에 활용되는 uml 다이어그램에 해당하는 건 뭔데 정적이라는 말은 시간적 순서에 따라서 크게 바뀌지 않는 걸 이야기하는 거고요.

21:46
동적이라는 건 시간적 흐름에 따라서 변화가 있는 것을 이야기합니다. 유스케이트 다이어그램 클러스 다이어그램 시퀀스 액티비티 중에 정적 다이어그램에 해당되는 것은 대표적으로 클러스 다이어그램에 해당되어집니다. 네 번째 응집도의 종류 중에 서로 간에 어떠한 의미 있는 연관 관계가 지니지 않는 기능 요소로 구성되어 있는 경우에 해당하는 건 뭔데 자 응집자 종류 중에 서로 간에 어떤 의미가 없는 의미가 있는 연관 관계도 없다. 이 말입니다. 연관관계가 서로 없으니까 이 응집도가 제일 낮은 것을 이야기하는 거예요. 함수 순차 논리 우연 그중에서는 우연적 응집이 해당되어지겠습니다.

22:31
다섯 번째 어떤 모듈이 서로 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어 신호를 이용해서 통신의 이용하여 통신에 해당하는 결합도는 뭔데 해당 설명 문구 내에서요 반복적으로 나오는 단어는 제어입니다. 이렇게 유추해서 보기 항목에서 제어 결합도를 이야기하는구나 이렇게 고를 수 있어도 됩니다. 문제의 난이도가요 굉장히 까다롭게 다 어렵게는 나오지 않습니다. 그렇기 때문에 문제가 상중하 이렇게 돼 있기 때문에 웬만하면 1분 30초 내에 쉽게 고를 수 있게끔 사직 쓴답표가 나옵니다. 개념 정리만 잘 하시면 돼요. 마지막으로, 핵심 정리하고 마치겠습니다. 공통 모듈이란 시스템을 구축할 때 여러 하위 시스템에서 공통으로 서로 사용하는 모듈을 모아놓은 소프트웨어 꾸러미를 이야기한다.

23:27
재사용성을 높일 수 있다. 공통 모듈의 종류는 클래스 라이브러리 컴포넌트 프레임워크가 있다. 네 두 번째로, 공통 모듈 도출입니다. 공통 모듈 도출은 하향식 기법은 상단의 상위의 개발 프레임워크에서 공통적인 모듈을 뽑아서 가져오는 게 하향식 기법이고요. 상향식 기법은 기능 목록을 기준으로 여러 부서에서 똑같이 사용하는 기능들 중에서 뽑는 게 상향식 기법입니다. 세번째 공통 모듈 설계입니다. 공통 모듈 설계는 요구사항을 분석할 때는 유지케이스 다이어그램 정적분석적인 측면의 대표는 클래스 다이어그램 그리고 동적분석의 대표는 시퀀스 다이어그램이 있습니다. 말로 공통 모듈 평가입니다.

24:15
공통 모듈 평가 기준으로서는 응집도 응집도는 모듈 내에 있는 클래스들 간의 상호 유기적인 관계 정도를 나타내는데 상호 유기적 관계가 높아야지 품질도가 높습니다. 반대로 결합도는 모듈과 모듈 간에 서로 간의 연관 관계인데 이 연관 관계는 오히려 낮아야지 품질도가 높다 이렇게 정리를 했고요. 이상으로 공통 모듈 설계 마치도록 하겠습니다. 소프트웨어 설계 세 번째 과목인 애플리케이션 설계 두 번째 파트 시험 출제 기준에서는 객체 지향 설계를 네 다루고 있는데, 저희 ncs 학습 모듈에서는 약간 혼동스러울 수 있는데, ncs 학습 모듈에서는 타 시스템 연동 설계로 되어 있습니다. 그래서 내용이 상이한 부분입니다. 시험 출제 기준에 맞춰서 제가 별도로 정리한 부분이니까.

25:06
고려하셔 가지고 수강하시길 권해드리고 이 부분은 시험 출제에서 자주 출제가 되는 파트예요. 학습 목표 객체 지향의 개념과 특징 그리고 클래스 간의 관계 설계 원칙에 대해 이해한다. 두 번째 디자인 패턴의 개념과 활용 목적 및 고프 디자인 패턴 종류를 이해한다. 학습 내용은 객체 지향 개념 특징 그리고 클래스 간 관계와 설계 원칙 마지막으로, 디자인 패턴 순서로 살펴보도록 하겠습니다. 용어 사전으로서 객체 지향 방법은 실 세계의 개체를 엔터티를 속성과 메소드가 서로 결합을 시켜 하나의 어떤 객체로 보고 구현 대상을 객체와 객체 간 관계로 모델링하는 방법이 객체 지향 방법이고요.

26:03
디자인 패턴이라고 하는 부분은 많은 개발자들이 프로그램 모델이 오랜 시간 동안 대가들이 많이 있잖아요. 많은 개발자들이 경험으로 체득한 설계 지식을 검증하고 이를 추상화해서 일반화시킨 템플릿이 디자인 패턴이고 디자인 패턴을 활용하게 되면 효율성과 재사용성을 높일 수가 있습니다. 객체지향의 개념과 특징입니다. 객체지향이란 오브젝트 오리엔티드 실세계의 객체 속성 메소드가 결합된 형태의 객체로 보고 구현 대상을 객체와 객체 간 관계로 모델링한 방법이다. 객체는 공통 객체대로 묶어놓은 꾸러미인 클래스에서 실체화시킨 거 인스턴스 한 게 객체가 됩니다.

26:55
밑에 보면 제가 uml 다이어그램으로 객체를 표현하는 다이어그램 그려놓았는데요. 왼쪽 부분은 얘는 클래스입니다. 클래스이고요. 오른쪽 부분이 객체입니다. 자 사각형 박스로 그려 놓았고요. 3등분을 했고 객체 이름 그리고 여기 속성 그 다음에 동작을 나타내는 메소드들이 이렇게 돼 있고요. 객체는 클래스하고 약간 차이 나는 부분은 해당 밑줄을 이렇게 쫙 그어놨어요. 그리고 오른쪽이 클래스명이고요. 왼쪽이 객체명이 되겠습니다. 객체의 지향은 특징으로서 다섯 가지 특징이 있습니다. 시험에 자주 나옵니다. 추상화상속 다형성 캡슐화 정보 원닉의 특징을 가지는데 이 다섯 가지 특징 세부적으로 살펴보도록 하겠습니다.

27:53
먼저 추상화란 앱스트랙션 뽑아낸단 말이에요. 뭘 뽑아내는데 객체 모델링을 할 때 해당 그 객체에서 필요로 하는 부분만 뽑아요. 속성과 동작을 객체를 모델링할 때 필요한 만큼의 속성과 오퍼레이션을 추출해내는 것을 이야기하는데 모델에서 뭘 이용할 건지에 따라서 포함시킬 거 또는 불필요한 구분이 될 수 있겠죠. 예를 들어 세탁기다 세탁기를 모델링 할 때 세탁기에서 꼭 필요한 것만 세탁기의 이름 브랜드명 모델명 시리얼 넘버 그리고 용량 용량이 얼마짜리 세탁기야 이렇게만 뽑아도 될 것 같아 그 외에 사이즈는 어떻고 크기는 어떻고 무게는 어떻고 이러한 것들은 굳이 필요 없어 그러면 뽑지 않은 거죠. 세탁기의 동작적인 부분 또 네 가지만 이렇게 뽑아가지고요.

28:48
except 클로즈 옷을 넣는다 또는 세제를 넣는다 또 전원기를 켠다 끈다 이 정도로만 해서 표현할 수도 있겠습니다. 두 번째 특징은 상속입니다. 상속은 상위 클래스에 정의해 놓은 속성과 행위 동작을 하위 클래스에서 그대로 이어받아서 이용할 수 있어요. 부모의 형질을 자식들은 그대로 물려받죠. 그리고 자식은 자식만의 또 특징을 가지죠 자 그래서 상속을 이용하게 되면 해당 구현 자체가 코딩이나 이러한 부분들이 좀 많이 수월해지고요. 그리고 유지보수가 용이하다는 특징이 있습니다. 상속을 관계를 그려놓은 다이어그램은 다음과 같습니다.

29:36
상속 간의 관계는요 라인으로 연결하고 이렇게 비어있는 삼각형으로 이렇게 인터페이스 연결점을 이렇게 표시를 합니다. 자동차라는 클래스가 있는데, 자동차 클래스의 종류로서 트럭이나 승용차나 트레일러와 승합차로 이렇게 나눌 수 있겠죠. 자동차의 속성으로 제조사와 시동 골절이라는 게 있다면 해당 트럭도 이 속성의 정의를 제조사라고 별도로 하지 않았지만 자동차 의 속성을 물려받기 때문에 트럭은 제조사라는 속성을 그대로 이용할 수가 있습니다. 시어링 골드라는 동작도 그대로 이용할 수 있고요. 추가적으로 얘가 주차하다 라는 부분을 종이해 가지고 이용할 수도 있고 다음 다형성입니다. 다형성이라고 하는 부분 자체는 상속을 받은 클래스가 상위 클래스에서 선언했던 행위예요.

30:28
동작적인 부분은요, 오퍼레이션을 하위 클래스도 이용할 수 있는데, 똑같은 이름으로 이용할 수가 있다라는 특징입니다. 그런데 똑같은 이름으로 이용을 하되 동작적인 부분은 하위 클래스의 특징에 맞춰가지고 달리 할 수 있다. 그게 메소드 오버 라이딩이라는 기법이고요. 해당 똑같은 동작을 수행하는데 어떤 동작을 수행할 때 소스 상에서 보게 되면 갈록 구름 안에 해당 얘가 메서드예요. 스타트 카 이렇게 돼 있습니다. 스타트 카인데 갈록 구르미 안에 스트링 a라고 하는 매개 변수의 값을 넘겨받아 가지고 저 a라는 값을 받았을 때는 어떤 게 시동이 걸리게끔 해 이런 식으로 달리 하는 부분이 메소드 오브 로딩이 되겠습니다.

31:17
그래서 메소드 오브 라이딩과 메소드 오브 로딩을 구분할 수 있어야 되는데 오버라이딩은요, 똑같은 이름인데 동작만 달리 수행하는 거예요. 로직을 수행했다. 이 말이고요. 오버로딩은요, 갈록꾸러미 안에 추가적인 매개변수를 넘겨받아요. 그 넘겨받는 매개변수의 종류에 따라서 실행 자체가 달라지게끔 그렇게 구현할 수가 있습니다. 다음 캡슐라인입니다. 인캡슐레이션 객체는 자신의 동작 원리를 클래스라고 하는 하나의 껍데기로 캡슐로 묶는다는 말이죠. 묶어가지고요. 처리를 하는데 그렇게 하게 되면 그 객체만이 자신의 operation 내부적인 동작이 어떻게 된다. 라는 것을 알고 외부에서는 알 수 없게 할 수 있죠.

32:15
캡슐화와 특징인 정보 은닉은 관련성이 있습니다. 정보 은닉이라고 하는 부분은 캡슐화되어진 항목의 인터페이스와 구현을 명확하게 분리해서 각 클래스의 내부 항목에 대한 부분을 오픈 안 시키는 거예요. 내부 항목에 대한 정보를 다른 객체로부터 숨긴다 메시지 전달을 통해서요. 메시지 전달에 의해서 다른 클래스에서 메소드를 호출해서 그냥 사용만 할 수 있게끔 그렇게 한 부분을 이야기합니다. 이렇게 해서 5가지 특징 살펴봤었고요. 관련해서요. 퀴즈 문제 한번 풀어보도록 하겠습니다. 네 시험 문제 요렇게 유형으로 나올 수 있습니다. 다음 중 다양성의 설명이 틀린 것을 골라라 이렇게 요구하고 있습니다. 자 다양성은요, 첫 번째 보기 상위 클래스에서 정의한 메소드를 하위 클래스에서 재정의할 수 있어 네 맞죠.

33:11
이게 밑에 메소드 오버라이딩 구체적으로는 뜻합니다. 다양성의 종류는 메소드 오버라이딩이 있고 메소드 오브 로딩이 있어 맞고요. 다양성은 상속을 기본으로 해 네 다양성은 상속을 기본으로 합니다. 상속관계 다양성은 상속을 전혀 사용하지 않아 엉뚱한 보기입니다. 4번이 틀렸습니다. 다음 클래스 간의 관계와 설계 원칙에서 클래스 관계 자 클래스는요 다른 클래스와 어떤 의미에서요 서로 간의 관계를 가질 수 있어요. 연관되어 있다라고 이야기를 하고요. 어소시에이션으로 표현을 합니다. 일례로 사람이요. 행위자가요 티비로 본다 사람이 티비로 본다 그런 경우에 사람과 티비 간의 관계 그래서 일단 이 사람이 tv를 일례로 켜다라고 하는 행위를 해당 이 tv에 유발한다. 그런 경우에 관계에 대한 부분에 대한 세부 내용을 여기다 표시할 수 있습니다.

34:02
여러분의 tv를 켜면 여러분의 tv와 단방향 관계를 가진다 사람이 tv를 볼 때만 tv를 켜니까 자 하나의 객체는 다른 객체와 두 개 이상의 연관을 가질 수도 있습니다. a라는 사람이 있고요. b라는 사람이 있는데, a라는 사람과 b라는 사람은요, 사업적인 측면에서 서로 동업자 관계예요. 그렇지만 개인적인 친분으로 서로 간에 친구예요. 그런 경우에는 동업자 관계도 있고 친구라는 관계도 두 개 이상의 연관을 가질 수도 있다. 네 그다음에 일반화와 특수화라는 관계인데 상속관계에서요 관점을 위에서부터 아래로 본다고 한다면, 위에서부터 아래로 본다고 한다면, 특수와 스페셜리제이션 관계라고 볼 수 있고요.

34:54
아래쪽에서 위로 본다면 제너럴리제이션 일반화라고 볼 수가 있습니다. 즉 도형이라고 하는 클래스가 있는데, 도형 클래스의 종류로는 다시 삼각형도 있고 사각형도 있고 원도 있어요. 근데 동일하게 에어리어라고 하는 면적을 구하는 메소드가 근데 해당 수행하는 메스워드의 결과치는 틀려요 삼각형은 면적을 구해 라고 하게 되면 밑변 곱하기 높이를 구하겠죠. 2분의 1 곱하기 밑변 곱하기 높이 곱하기 2분의 1로 이렇게 구하겠죠. 근데 사각형은 밑변 곱하기 높이로만으로도 뚝딱 구해지겠죠. 두 클래스 간의 상습관계가 있을 때 아래에서 위로 추상화하면 일반화고 위에서 아래로 구체화하면 특수화가 된다. 집합관계입니다. 집합연관이라고도 합니다.

35:46
하나의 클래스가 여러 개의 컴포넌트로 구성되어 있는 경우 예를 들어 밑에 보면 다이어그램은 해당 홈컴퓨터라고 하는 클래스가요 우리 이러한 하위에 어 가까이 여러 클래스테롤로 모여가지고 구성이 되어진다 컴퓨터는 스피커도 있죠. cpu 박스도 있고 키보드도 있고 모니터도 있고 마우스 등등이 있다. 집합 연관인 경우에는요 상속인 경우에는 해당 상위 클래스와 연결을 할 때 인터페이스 연결점을 비어있는 삼각형을 표시를 했어요. 상속은 근데 집합 연관은 비어 있는 마름모로 이렇게 표시를 해서 구분합니다.

36:30
그리고 뒤에 마지막에 있는 해당 관계 복합 연관은 컴파짓 릴레이션십으로 되어 있는데, 복합 연관은 해당 기호 자체가 채워있는 마름모로 표시가 되어집니다. 그럼 집합과 복합은 어떤 차이가 있느냐 집합과 복합의 차이는요 같이 연결되어진 해당 클래스가 따로 떼 놓았을 때 전혀 동작적 기능적인 부분을 수행할 수 없는 경우는 복합 연관입니다. 일례로 커피 테이블이 있는데, 커피 테이블은 몸체와 다리로 구성되어 있는데, 다리 4개만 뚝딱 떼내가지고 뭔가 동작을 할 수 있느냐 못해요. 얘는 반드시 몸체하고 이렇게 연결되어 가지고요. 해당 어떤 테이블로서의 역할을 할 수 있어요. 그래서 복합관계와 집합관계 구분할 때는 집합 같은 경우 스피커 마우스 이런 거 별도로 동작을 한단 말이에요.

37:26
어쨌든 나름대로 의미를 가진다 가지지 못한다. 이렇게 구분할 수 있겠습니다. 네 클래스 설계 원칙입니다. 네 5가지 원칙이 있는데, 5가지 원칙을 그냥 구분할 수 있게끔만 익혀 놓을게요 단일 책임이다. 책임이 하나야 이 말입니다. 클래스는 한 가지 책임 한 가지 기능을 갖도록 설계하자 개방 폐쇄 열고 닫는다 이 말이죠. 확장 상속에서는 열려있어야 되구요. 상속에서는 열려있어야 되고요. 그 다음 변경에서는 닫혀 있어야 된다. 해당 상위 클래스가 가지고 있는 속성과 메소드는 하이 클래스에서는 그대로 물려받게끔 오픈 근데 하이 클래스에서 상위 클래스의 뭐를 바꾸려고 해 안 되죠. 그렇게 하면 안 되겠죠. 개방 폐쇄 원칙 그리고 리스코프 교체의 원칙이란 리스코프 교체 원칙은 상속 관계에 있는 상위 클래스가 있는데, 상위 클래스는 하위 클래스로 대체할 수도 있어야 한다.

38:26
라는 개념이 리스코프 교체의 원칙입니다. 자 의존 관계 역전의 원칙이다. 하니 의존 관계 역전은 클라이언트가 구체적인 클래스 클래스가 아닌 추상 추상 클래스 앱스트랙트 클래스에 대해서는 의존해야 한다. 의존 관계 역전 추상 클래스에 부채 클래스는 의존해야 된다. 인터페이스 본리의 원칙 하나의 일반적인 인터페이스보다는 구체적으로 여러 개의 인터페이스가 낫다 자 문제 바로 보도록 하겠습니다. 문제 어떻게 나오냐면요 이렇게 나올 수 있어요. 일례로 리스코프 교체 원칙으로 옳은 걸 골라 이렇게 리스코프 교체 원칙은 상위 클래스를 하위 클래스가 대체할 수 있어야 된다. 라는 개념이었어요. 그 개념을 설명하고 있는 문구를 골라보도록 하겠습니다.

39:22
첫 번째 모듈의 설계는 확장에 대해서는 열려 있어야 하고 수정에 대해서는 닫혀 있어야 해 이거는 개방 폐쇄의 원칙이었습니다. 개방 폐쇄의 원칙 두 번째 b가 클래스 a의 자식이야 a가 그러면 상위라는 거죠. b가 하위 자식이라는 말입니다. a 클래스가 요구되는 곳에서 b 클래스의 인스턴스가 사용될 수 있도록 a가 상위 b가 하위일 때 a를 b가 대체할 수 있어야 돼 라는 설명이니까. 두 번째가 리스코프 교체 원칙을 설명하고 있는 문구입니다.

40:11
세 번째 구체적인 클래스보다 인터페이스나 추상 클래스에 대해서 의존 되도록 설계해야 해 보는 의존 관계 역전의 원칙 마지막으로, 법령적 목적의 단일한 인터베이스보다 클라이언트별 인터베이스를 다수 갖는 게 좋아 라고 하는 부분은 인터베이스 분류의 원칙을 설명하고 있는 문구가 되겠습니다. 자 마지막 파트입니다. 디자인 패턴입니다. 디자인 패턴 개념으로서 디자인 패턴이 뭔데 디자인 패턴은 많은 개발자들이 경험으로 체득한 누적되어진 설계 지식을 검증해서요. 이를 추상화해서 일반화하는 템플릿이다. 나름대로 하나의 모델화시켰다는 말입니다. 그걸 패턴이라는 용어를 사용을 하는데 객체지향 설계에서 해당 패턴이라는 부분 자체가 디자인 패턴이라는 부분 자체가 주목받기 시작한 것은 사람 이름입니다.

41:08
에릭 감마 리처드 헬롬 라이프 존슨 존 블리시지데스가 제안한 고프의 디자인 패턴이라는 책이 95년도에 출간되면서였는데 고프라는 부분은 갱 오브 포의 약어예요. 고프디자인패턴 자 뒤에 세부적으로 고프 디자인 패턴 23가지 23개 3가지 패턴을 제시하는 게 있는데, 살펴보도록 하겠고 디자인 패턴의 장단점입니다. 디자인 패턴을 사용하게 되면 장점적인 부분에서는요 서로 간에 개발자들이 패턴을 알고 있으면요 의사소통이 수월해요. 그래서 개발자 간의 원활한 의사소통 우리는 이 패턴을 이용했어. 아 그래 바로 이해할 수 있으니까 그리고 또 알고 있는 패턴으로 만들었으면 소프트웨어 구조 파악도 용이해요.

41:57
그리고 재사형성 네 재사형성을 통해서 개발 시간도 단축시킬 수 있고 설계 변경 요청에 대한 것도 유연하게 대처할 수가 있다는 게 장점이고요. 단점은 객체 지향 설계 중심적인 구현이어야 가능하고 그리고 초기에 예를 또 적용하기 위해서 시간이라든지. 비용 같은 것들이 투자가 될 수 있다는 게 단점입니다. 고프의 디자인 패턴 분류입니다. 크게 두 가지 목적과 범위에 따라서 분류할 수가 있고요. 목적은 다시 세 가지 생성패턴이냐 구조패턴이냐 행위패턴이냐 생성패턴을 만든다는 말입니다. 객체의 생성과정과 관련 관여 생성 과정에 관여하는 패턴이 생성패턴이 되겠고요. 구조패턴은 클래스나 객체 합성과 관련되어진 패턴이 되겠고 마지막이 행위패턴입니다. 어떤 동작적인 부분이겠죠.

42:56
클래스나 객체들 간의 상호작용이라든지. 책임을 분산하는 방법을 방법과 관련되어진 부분이다. 그래서 이렇게 세 가지로요 생성 패턴 구조 패턴 행위 패턴으로 나누는데 해당 적용되어진 범위에 따라서 클래스에 적용되어지는 패턴 네 개가 있고요. 나머지가 객체에 적용되는 패턴인데 이 클래스하고 객체하고 공통으로 적용되어지는 패턴이 하나 있어요. 어댑터 패턴이라고 자 종류별 이 목적에 따른 분류의 개수를 한번 따져보도록 하겠습니다. 생산패턴은 몇 개인데 생산패턴은 하나 둘 셋 이거는 같이 묶이는 거예요. 두 줄이 그래서 팩토리 메소드 패턴 앱스트랙션 팩토리 패턴 빌드 패턴 프로토타입 패턴 싱글톤 패턴 이렇게 다섯 가지입니다.

43:53
구조 패턴은 몇 개인데 구조 패턴은 어댑터 이거 같은 거예요. 적용 범위가 클래스냐 객체냐로 구분한 거고, 어댑터 패턴 브릿지 컴파워지 데크로에이션 페케이드 플라이어 웨이트 프렉시 7개입니다. 전체 몇 개인데 23개입니다. 23개에서요 네 5개하고요. 7개를 빼게 되면요 남는 것은요, 11개죠 행위패턴이 11개입니다. 제일 개수가 적은 걸 익혀야겠죠. 암기한다면, 많은 걸 암기하기보다는 그래서 생성 패턴 5가지만 알아놓으시면 좋을 것 같아요. 패턴의 목적에 따른 분류 다음 중 패턴의 종류가 틀린 걸 골라 제시되어진 보기 항목 중에 23개 중에 5가지는 쉽게 이해할 수 있겠죠. 그리고 생성이에요. 이름값 자체도 만드는 것과 관련되어져 있어요.

44:50
그래서 5개 팩토리 메서드 그다음에 앱스트랙션 팩터드 팩토리 빌드 프로토타입 그리고 싱글톤 이 5개는 알아놓으시면 좋을 것 같고, 세부 설명들이 쭉 있는데, 생성 팩토리 위주로만 명확하게 좀 익히면 좋을 것 같고요. 제가 색깔로 좀 구분을 했는데 시험에 좀 자주 나왔던 게 5개 정도 범위가 시험에 좀 자주 나오고 있어요.

45:11
생성패턴 앱스트랙트 팩토리 패턴은 공장과 같이 부품을 조합해서 인스턴스 생성을 실행하는 패턴이야 빌더라는 부분 자체는 해당 복잡한 인스턴트를 조립하여 만드는 구조로 객체를 생성하는데 객체를 객체를 생성하는 방법과 객체를 표현하는 방법을 분리하는 패턴이 빌더 그리고 팩토리 메소드 패턴은 상위 클래스에서 인스턴스 작성법의 뼈대를 세우고 구체적 작성은 하위 클래스에서 실행하는 패턴이야 프로토타입 자주 접했던 용어입니다. 모형이 되는 인스턴스를 복사해서 인스턴스를 만드는 패턴 싱글톤 싱글이란 말이에요. 하나란 말이에요. 인스턴스가 하나만 존재하게끔 한다.

46:03
클래스의 객체로서 한 개의 객체만 만들어지게끔 하는 패턴 이렇게 다섯 가지 그다음에 구조 패턴 이름만 빨간 것만 위주로 살펴보고 나머지 이름만 보겠습니다. 어댑터는 서로 다른 인터페이스를 갖는 클래스들을 연결하는 패턴이야 서로 다른 인터페이스를 갖는 클래스들을 연결하는 패턴 빨간 거 패케이드 복잡하게 핀 클래스를 개별적으로 제어하는 게 아니라 창부 역할을 한인 클래스를 하나 배치해서 시스템 전체적인 조작을 좋게 하는 패턴이야 은행에 갔을 때 여러분들이 언행 업무를 수행하기 위해서 지점장 나오세요. 저하고 이야기 좀 합시다. 직접적으로 컨택 안 되죠. 언행에 창고에 있는 언행원하고 내가 뭐 하러 왔어요. 이렇게 되겠죠.

46:50
개념적으로 그래서 팩케이드는 창고 역할을 하는 클래스를 하나 배치해서 시스템 전체 조작을 좋게 하는 패턴이야 나머지는 이름만 브릿지 컴파지 데크로에이션 플라이웨이트 프락시 다음 행위패턴 11개 있습니다. 이 중에서 빨갛게 되어 있는 부분 스트레티지 전략이라는 말이잖아요. 스트레티지의 주 키워드는 알고리즘을 주 키워드로 해서 익혀 놓으실 필요가 있어요. 알고리즘이라는 단어가 들어가면 스트레티지입니다. 스트레치지는 알고리즘을 전부 교체해서 수정하기 쉽도록 하는 패턴이야 나머지는 이름만 체인 오브 리스폰시빌리티 컴맨드 인터프리트 이터레이터 미디어터 네일 메멘토 오브즈 오브 스케이트 네일 템퍼드 메소드 비지트 암기할 필요 없습니다. 제가 말씀드렸죠 빨간 거 위주 그리고 생성 패턴 위주로만 익혀도 문제 푸는데 크게 어려움은 없습니다. 싱글톤 패턴의 규칙의 예입니다.

47:48
패턴을 이용하게 되면 장점은 기존에 해당 이러이러한 패턴을 정의해놨단 말이에요. 이 경우에는 이렇게 사용하는 게 좋아요. 그리고 그때 어떻게 사용하는지 라는 부분에 대한 예시 소스도 제시를 하거든요. 그래서 싱글톤 같은 경우에는 특정 클래스의 객체가 한 개가 존재하도록 제한하는 것을 이야기하는데 경우가 예를 들어 컴퓨터가 프린터를 공유해서 이용할 때 해당 프린터는 공유가 되어 있다 하더라도 a라는 사람이 프린팅 요청한 부분을 다 프린팅하기 전에 b라는 사람이 요청하더라도 얘는 얘는 프린팅되지 않고 a가 다 출력되고 난 다음에 그와 같이 어떠한 작업을 수행하는 특정 클래스의 객체가 하나만 존재하도록 하는 경우 같은 경우에는 어떻게 소스 코딩을 하는 게 낫다고 이렇게 견본 예시가 제시되어 있다 보니까 이들을 활용해 가지고 하면 돼요. 이름값만 바꿔가지고 자바 소스의 코딩 예제이고 uml에 해당하는 클래스 예제입니다.

48:47
넘어가겠습니다. 자 디자인 패턴에 대한 퀴즈입니다. 다음 중 성격이 다른 디자인 패턴은 뭐야? 브릿지 패턴 팩토리 메스워드 패턴 프로타입 패턴 싱글 톤 패턴 생성패턴 다섯 가지 기억만 하라 말씀드렸죠 이 세 개는 생성패턴이고요. 브릿지 패턴은 종류가 다릅니다. 자 모의평가 네 문제 풀어볼게요 객체에 대한 기법에서 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 게 무엇이라고 하는가? 클래스 함수 메소드 메시지 메소드 클래스입니다. 기존에 정보처리기사 기출문제에서 자주 나왔던 문제 유형입니다.

49:36
다음 객체의 제한 시스템에서 자료 부분과 연산 부분 등 정보 처리에 필요한 기능을 하나의 테두리로 묶었다 하나를 꾸러미로 묶었다 이게 뭔데 정보 은닉이라고 생각할 수도 있는데, 정보 은닉은 얘를 숨겼다는 게 포커스를 두고 이야기하는 특징이고요. 묶었다라고 하는 부분은 캡슐레이션 캡슐라를 뜻하는 문제가 되겠습니다. 객체 지향 특성 5개 구분할 수 있어야 됩니다. 디자인 패턴을 이용한 소프트웨어의 재사용으로 얻어지는 장점이 아닌 건 뭔가 틀린 것을 이야기하는 겁니다. 재사용으로 얻어지는 장점이 아닌 거 개발 프로세스를 무시할 수 있어 설명이 아니고요. 소프트웨어 코드의 품질 향상 개발자 간의 의사소통 원활 그리고 소프트웨어 품질 및 생산성을 높일 수 있어 이 세 가지는 장점이 되겠습니다.

50:35
디자인패턴 네 번째 다음 중 전략 패턴요 스트레치지 패턴에 대한 설명으로 올바른 거 골라 아까 제가 스트레치지 할 때는 주 키워드를 하나만 기억하세요. 알고리즘이라고 말씀드렸습니다. 알고리즘이라는 키워드가 들어가 있는 보기 항목을 고르면 되겠습니다. 다양한 알고리즘이 존재할 때 이들 각각을 하나의 클래스로 캡슐화해서 알고리즘 대체가 가능해 1번이 정답입니다. 23개나 되는 패턴을 저희가 다 구분할 수는 없잖아요. 그렇기 때문에 생성패턴 5개 위주 빨갛게 표시되어져 있는 거 정도만 위주로 하시면 되겠습니다. 핵심 정리 정리하고 마치겠습니다. 객체 지향 실생의 개체를 속성과 메서드를 결합해서 하나의 객체라는 단위로 만들고 그 객체와 객체 간의 관계로 모델링하는 방법이다. 객체자의 특징은 다섯 가지가 있다. 뽑아낸다 추상화 물려받는다.

51:32
상수 그다음에 똑같은 이름인데도 다양하게 동작시킬 수 있어 다형성 그다음에 묶는다 캡슐과 그리고 묶어서 안 보이게 해 정보는 클래스 간의 관계 클래스들은 서로 한 개 이상이 서로 관계를 가질 수 있는 그 관계 종류는 서로 연관되어 있어 연관 관계 그리고 일반화 특수와는 상속 관계에 있을 때 위에서 아래로 특수화 아래에서 위로 일반화 그리고 집합관계 복합관계가 있는데, 해당 구성요소들을 따로 떼어 놓았을 때 나름대로 기능을 수행하면 집합관계 그렇지 못하면 복합 연관이라고 말씀드렸습니다. 마지막으로, 디자인 패턴입니다.

52:16
많은 개발자들이 오랫동안 체험으로 경험으로 체득한 설계 지식들을 이제는 어떤 어떤 부분에 대해서는 저 사람이 사용하는 방식을 표준으로 써도 될 것 같아 일반화한 템플릿이고 디자인 패턴을 사용하면 효율성과 재사용성을 높일 수 있다. 고프의 디자인 패턴 종류 생성패턴 목적에 따라서 구조 패턴 행위패턴 그중에 생성패턴 다섯 가지만 기억하시면 좋을 것 같고, 빨갛게 표시했던 부분만 추가적으로 더 알아놓으면 좋을 것 같습니다. 네 이상으로 객체지향 설계하기 살펴봤습니다.

https://youtu.be/Rs3bw0PCyLI?si=umqzXdEXdFXNy_87

1. 소프트웨어 아키텍처와 품질 특성

1-1. 소프트웨어 아키텍처의 이해
- 소프트웨어 아키텍처는 소프트웨어 개발을 쉽게 하기 위한 기본 틀이라고 설명함
- 복잡한 개발을 체계적으로 하기 위한 밑그림이며, 시스템 간의 연동을 원활하게 함
- (중요) 소프트웨어 아키텍처의 중요성과 활용은 소프트웨어의 기능이 복잡하고 다양해짐에 따라 요구 분석과 설계의 필요성을 가르침

1-2. 소프트웨어 품질 특성 이해
- 소프트웨어 품질 특성은 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성으로 나눠짐
- 기능성은 요구된 기능이 제공되어지는 정도를, 신뢰성은 시스템이 의도하는 기능을 제대로 수행하는 정도를 가리킴
- 사용성은 사용자와 컴퓨터 사이에서 어떠한 행위를 정확하고 쉽게 인지 가능한 정도를 나타냄
- (중요) 효율성은 한정된 자원으로 얼마나 빠르게 처리할 수 있는지를 나타냄
- 유지보수성은 요구사항을 개선하고 확장할 때 얼마나 용이한지를 나타냄

1-3. 소프트웨어 아키텍처와 품질 특성의 적용
- 이식성은 다른 플랫폼에서도 쉽게 적용 가능한 정도를 나타냄
- (중요) 품질 관리에서 이식성은 해당 소프트웨어가 검증되어 적용되기 쉽도록 하는 성질을 가짐
- 강의에서는 소프트웨어 아키텍처의 종류와 품질 특성을 이해하는 것이 중요하다고 강조함

2. 소프트웨어 아키텍처 및 인터페이스 설계

2-1. 소프트웨어 아키텍처의 이해
- 소프트웨어 아키텍처의 기본 요소로 디자인, 사용자 인터페이스, 아키텍스 설계가 있음
- (중요) 디자인은 완성된 웹 또는 앱 서비스를 구현하기 위한 전략을 수립하는 단계임
- 사용자 인터페이스 설계는 사용자 경험을 제공하는 웹 또는 앱의 사용자 인터페이스를 설계하는 단계임
- 아키텍스 설계는 디자인, 사용자 인터페이스 설계를 바탕으로 웹 또는 앱 서비스의 구조와 체계를 설계하는 단계임

2-2. 소프트웨어 아키텍처 설계 원칙
- 소프트웨어 아키텍처 설계 원칙은 직관성, 유효성, 학습성, 유연성의 네 가지가 있음
- (중요) 직관성은 사용자가 쉽게 이해하고 사용할 수 있는 환경을 제공하며 실사용자에 대한 이해가 바탕이 되어야 함
- 유효성은 사용자의 목적을 정확하게 달성할 수 있도록 설계하며, 사용자 편의성에 맞춰 쉽고 간편하게 사용 가능해야 함
- 유연성은 사용자의 요구사항을 최대한 수용하며, 오류를 최소화하는 설계임

2-3. 사용자 인터페이스 설계
- 사용자 인터페이스 설계는 사용자 경험을 제공하는 웹 또는 앱의 사용자 인터페이스를 설계하는 단계임
- (중요) 일관성 있게 설계되어야 하며, 실사용자에 대한 이해가 바탕이 되어야 함
- (중요) 사용자의 행동 패턴에 맞춰 설계되어야 함
- 오류 발생에 대한 해결책을 제공하며, 사용자의 요구사항을 최대한 수용해야 함

3. 소프트웨어 아키텍처 및 UI 설계

3-1. 소프트웨어 아키텍처의 정의와 소프트웨어 품질 특성
- 소프트웨어 아키텍처는 소프트웨어 개발을 쉽게 하도록 기본적인 틀을 만드는 것
- 소프트웨어 품질 특성은 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등이 있음
- (중요) 소프트웨어 아키텍처의 품질 특성을 이해하고 적용하는 것이 중요함

3-2. UI 설계의 원칙과 주요 고려사항
- UI 설계는 사용자 인터페이스를 통해 컴퓨터와 사용자 간의 소통을 원활하게 도와줌
- UI 설계의 원칙은 직관성, 유효성, 학습성, 유연성, 표준화, 명확성, 오류 해결 등이 있음
- UI 설계 지침은 사용자 중심, 일관성, 단순성, 예측 가능성, 가시성, 명확성, 오류 발생 해결 등이 있음

3-3. 스토리보드 작성과 UI 설계의 상호작용
- 스토리보드는 UI 설계에 필요한 기반 자료로, 사용자와 컴퓨터, 인터페이스 간의 상호작용을 시각화
- (중요) 스토리보드 작성 순서는 메뉴 구성도 작성, 레이아웃 결정, 실제 설계 순서로 진행됨
- 와이어프레임 앱 개발에서는 사용자 편의성을 고려한 메뉴 구조 설계가 중요함

4. 홈페이지 유저 인터페이스 설계

4-1. 스토리보드 생성 및 배치
- 스토리보드에 공지사항 배치를 논의함
- 로고는 왼쪽 상단, 메뉴 목록 등은 오른쪽 상단에 배치함
- 로그아웃 부분도 오른쪽 상단에 배치할 예정임
- 각 메뉴 항목은 깔끔하게 정리하고, 중요한 항목은 강조함
- 전체적인 시스템 구조를 설계하는 것이 중요함

4-2. 유용성 및 실행차 최소화
- (중요) 유용성은 시스템을 통해 목표를 효과적으로 달성하는 정도임
- 실행차는 사용자 행동과 시스템의 목적이 상이할 때 발생함
- 실행차를 줄이려면, 사용자에게 관심을 갖게 하는 항목을 앞에 배치함
- 행위 순서를 규정하여 중요한 항목부터 제공함
- 사용자의 기존 경험을 고려하여 친숙한 단계부터 제공함

4-3. 평가차 최소화 및 사용자 경험 향상
- 평가차는 시스템 결과를 사용자가 빠르게 인지할 수 있게 함
- 사용자의 의도와 시스템 결과 간의 유사 정도를 보여주는 것이 중요함
- 예약 신청 버튼을 눌렀을 때, 진행 중인지를 보여주는 것이 좋음
- 사용자의 원래 의도와 시스템의 결과를 보여주는 미리보기 기능을 제공함
- (중요) 평가차를 최소화하여 사용자 경험을 향상시킴

5. 서비스 개발과 감성공학의 적용

5-1. 서비스 개발의 주요 고려사항
- 서비스 개발에서는 사용자 경험(Ui)과 상호작용(시나리오)이 중요함
- (중요) 서비스 개발 모듈을 통해 윤곽을 표현하고 상호작용을 기술함
- 상호작용에는 개인화, 보안, 꼼꼼함 등이 포함됨
- 사용자의 니즈와 불편사항을 충족하는 것이 중요함
- 서비스의 목표와 요구사항을 정확하게 설정해야 함

5-2. 서비스 개발의 원칙과 규칙
- (중요) 서비스 개발에는 서비스의 전체 기능과 상호작용 규칙이 중요함
- 모든 기능은 공통 적용 가능한 규칙을 가져야 함
- 화면 레이아웃과 기능이 일관성을 유지해야 함
- 사용자의 조작 반응과 인터랙션 흐름도 상세히 설명해야 함
- 모범적인 시나리오 문서는 의사소통 오류를 줄이고 비용을 절감함

5-3. 서비스 개발 도구와 감성공학의 적용
- 서비스 개발 도구로는 프로토타입과 파워포인트가 있음
- (중요) 프로토타입에서는 아날로그와 디지털 방식이 있음
- 디지털 프로토타입은 상호작용을 더 잘 표현하며, 파워포인트는 UI 설계 기능을 더함
- 감성공학은 제품 설계에 인간의 특성과 감성을 반응하는 공학 기술임
- 감성공학은 사용자의 특성을 고려하여 제품의 경험을 개선함

6. 사용자 인터페이스 설계

6-1. UI 흐름 설계
- UI는 사용자 모형과 개발자 모형 간의 차이인 실행차와 평가차를 최소화해야 함
- UI 요구사항 정의, 시스템 구조, 아키텍처 사이트맵, 프로세스 정의, 화면 설계가 포함됨
- 유용한 시스템은 사용자 모형과 개발자 모형 간의 차이를 줄이는 것이 목표임
- UI 프로토 타입은 확정된 요구 사항을 기반으로 상세화하는 과정임
- UI 디자인은 화면 설계 이전에 미리 이루어져야 함

6-2. 감성공학 기술
- 감성공학은 개인의 경험을 기반으로 제품을 안락하고 쾌적하게 개발하는 기술임
- 감성공학 기술은 생체 측정, 센서 공학, 마이크로 가공 기술, 인간에 대한 적합성 평가, 가상현실 기술로 구성됨
- (중요) 감성공학 기술에서 인간 특성을 파악하는 생체 측정 기술이 중요함
- 사용자 인터페이스를 만드는 기술로 센서 공학, 퍼지뉴럴 네트워크 기술, 신경망 기술 등이 있음
- 인간의 오감을 이용한 센서 및 감성 처리 기술이 중요함

6-3. UI 설계 도구
- UI 설계 도구는 문서 작성, 드로잉, 설계, 개발 전문 도구, 화면 설계 전문 도구로 구성됨
- UI 플랫폼은 생산성 향상과 화면 품질 확보를 위한 도구임
- (중요) UI 설계 전문 도구는 문서 작성, 드로잉, 화면 설계를 위한 도구임
- (중요) UI 흐름 설계에서 용어의 정의, 이력, 개정 사항, 요구사항 등을 포함함
- (중요) 화면 설계 시 사용자 모형과 개발자 모형 간의 차이를 최소화해야 함

00:02
ncs 정보처리기사 chap22 화면 설계 첫 번째로, ui 요구 사항 확인에 대해 살펴보도록 하겠습니다. 학습 목표로서는 소프트웨어 설계의 종류 그리고 소프트웨어 아키텍처의 개념 및 활용도와 소프트웨어 품질 특성을 구분할 수 있다. 둘째, 응용 소프트웨어 개발을 위한 ui 표준 및 지침에 의거하여 개발하고자 하는 응용 소프트웨어에 적용할 ui 요구사항을 확인할 수 있다. 마지막으로, ui 스토리보드의 개념과 스토리보드의 작성 순서를 설명할 수 있다. 내용에 대한 순서는 학습 소프트웨어 아키텍처 그리고 ui 표준과 지침 마지막으로, 스토리보드 순으로 살펴보도록 하겠습니다.

00:55
학습하기 전에 용어 사전으로서 주요 용어 먼저 정리를 해드리면, 소프트웨어 아키텍처는 소프트웨어를 개발하기 쉽도록 하기 위해서 만든 기본 틀을 이야기합니다. 복잡한 개발을 체계적으로 하기 위한 밑그림이라고 보시면 되겠습니다. 둘째로, ui는 유저 인터페이스입니다. 사용자와 컴퓨터 상호 간의 소통을 원활하게 할 수 있도록 도와주는 연계 작업이다. 자 저희가 첫 번째 과목인 소프트웨어 설계에 보면 세부과목이 화면설계도 있고 인터페이스 설계도 있습니다. 네번째 세부과목인 인터페이스설계는 시스템과 시스템 간에 서로 연동이 될 때의 인터페이스 설계가 되고 이 화면설계는 사용자와 컴퓨터 간의 인터페이스라고 보시면 되겠습니다.

01:54
세 번째 ui 스토리 모듈 ux 사용자경험 구현에 수반되는 사용자와 컴퓨터 또는 인터페이스 간 상호작용을 위한 시각화 문서이다. 소프트웨어 아키텍처에 대해 세부적으로 살펴보도록 하겠습니다. 먼저 소프트웨어 아키텍처에 대해 살펴보기에 앞서서 소프트웨어 설계의 종류에 대해 먼저 알아보겠습니다. 소프트웨어 설계는 요구분석 명세서와 설계원리 제약조건에 따라 상위설계와 하위설계로 나눌 수가 있습니다. 상위설계는 먼저 아키텍처 설계 소프트웨어 및 시스템 아키텍처 그리고 데이터설계 데이터 저장할 데이터 관리에 대한 부분이 설계 있고요. 그리고 인터페이스 정의는 전체 시스템을 세분화해서 세분화한 각각의 시스템 간 인터페이스적인 부분을 정의하겠다.

02:50
라는 부분이고 사용자 인터페이스 설계는 화면설계라고 보면 되겠습니다. 하위설계에 해당되는 부분은 모듈설계 그리고 자료구조 설계 알고리즘 설계 순이 되겠습니다. 둘째로, 소프트웨어 아키텍처 개념에 대해 살펴보도록 하겠습니다. 소프트웨어 아키텍처란 용어 정의에서 살펴봤던 것과 같이 개발하고자 하는 소프트웨어의 사전 작업을 통해서 소프트웨어 개발을 쉽게 하도록 기본적인 틀을 만드는 것으로 복잡한 개발을 체계적으로 접근하기 위한 밑그림이 되겠습니다. 소프트웨어를 구성하는 컴포넌트 간의 상호작용 및 관계 각각의 특성을 기반으로 한 컴포넌트들이 어떻게 상호 유기적으로 결합을 하는지 소프트웨어의 진화를 위한 여러 원칙들의 집합이 소프트웨어 아키텍처가 되겠습니다.

03:46
소프트웨어 아키텍처의 중요성과 활용입니다. 소프트웨어 아키텍처의 중요성은요, 소프트웨어의 기능이 점차적으로 복잡하고 다양해짐에 따라 그 기능을 목적에 맞게 정의하여 분류할 필요성이 생겼고 각각의 기능적 특성을 사전에 파악을 하여 요구 분석 단계에서부터 설계 단계까지 분류된 기능과 함께 종합적인 시각으로 판단하는 것이 매우 중요하게 됐습니다. 그래서 소프트웨어 아키텍처는 개발하고자 하는 소프트웨어 시스템을 다양한 시각에서 모형화하고 문제의 특징과 본질을 파악할 수 있도록 활용되어집니다. 소프트웨어 품질 특성에 대해 정리하도록 하겠는데요.

04:35
소프트웨어 품질 특성은 총 6가지 종류 자체를 구분할 수 있게끔 익혀놓을 필요성이 있고 정보처리 기사에서 출제 기준이 바뀌기 전에도 품질 관리 파트에서 매일 한 문제씩은 꼭 나왔던 부분입니다. isoic 국제표준화기구의 국제전기위원회의 구하나26 모델에서 정의한 여섯 가지 요소 첫 번째 기능성입니다. 요구된 기능이 제공되어지는가? 둘째, 신뢰성 믿을만한 소프트웨어인가 셋째, 사용성 사용하기 쉬운 소프트웨어인가 넷째, 효율성 얼마나 효율적인 소프트웨어인가 다섯 번째 유지보수성 수정이 용이한 소프트웨어인가 마지막으로, 이식성 환경전환이 용이한가 세부적으로 살펴보면요 첫번째 기능성입니다.

05:32
기능성이라고 하는 부분은 실제 수행 결과와 품질 요구사항과의 차이를 분석하고 실제 사용 시 정확하지 않은 결과가 발생할 확률 등과 관련해서 시스템의 동작을 관찰하기 위한 품질 기준이 되겠습니다. 기능성의 상세 품질 요구사항으로서는 명칭만 정리하도록 하겠습니다. 적절하냐? 적절성 그리고 에큐러시 정밀성 요구되는 정확도로 올바른 결과를 산출할 수 있느냐 그리고 상호운용성 특정 시스템과 상호작용을 해서 운영할 수 있는가 그리고 보안성 그리고 호환성 비슷한 환경에서 연관된 표준과 관례 및 규정을 준수하는 능력이 되겠습니다. 두 번째로, 신뢰성입니다.

06:23
신뢰성은 시스템이 일정한 시간 또는 작동되는 시간 동안 의도하는 기능을 제대로 수행하는지를 보증하는 부분이라고 보면 되겠고요. 세부 상세품질 요구사항으로서는 성숙성 즉 소프트웨어 결함으로 인한 고장을 회피할 수 있는 소프트웨어 능력과 고장 허용성 그리고 또 고장이 발생했을 때 그에 대한 회복성을 신뢰성의 상세품질 요구사항으로 뽑고있습니다. 다음 사용성입니다. 세 번째 유저빌리티 사용자와 컴퓨터 사이에 발생하는 어떠한 행위를 정확하고 쉽게 인지 가능한지를 뜻하는 용어가 되겠고요.

07:10
사용성의 상세 품질 요구 사항으로서는 이해성 학습성 쉽게 익힐 수 있는가 그리고 운용성 소프트웨어 운용과 운영 통제에 필요한 사용자의 노력 정도에 따른 특성 이 세 가지가 사용성의 상세품질 요구사항이 되겠습니다. 다음으로, 효율성입니다. 할당되어진 시간이 한정된 자원으로 얼마나 빨리 처리할 수 있는가를 의미하고요. 효율성과 관련한 상세품질 요구사항은 두 가지로 시간적인 효율성과 자원적인 효율성 다 명칭상으로 효율성이 들어가니까 시간 자원 효율성 정리하면 되겠고요. 자 그리고 유지보수성입니다. 유지보수성은 요구사항을 개선하고 확장하는 데 있어서 얼마나 용이한가를 뜻하는 단어가 되겠고요.

08:04
유지보수성의 상세품질 요구사항 우선은 4가지 분석성 소프트웨어 고장의 원인이나 진단 또는 수정이 요구되는 부분을 얼마나 빨리 파악할 수 있는가 그리고 변경성 결함 제거라든지 환경 변화에 따른 수정 노력의 관련 특성입니다. 안정성 그리고 시험성은 소프트웨어가 검증되어서 검정에 필요한 노력의 정도가 어느 정도인가를 따지는 부분입니다. 이렇게 6가지에 대한 ioc ic의 9126 모델의 품질 적성 살펴봤고요. 마지막으로, 하나 더 있는데, 이식성입니다. 이식성은 다른 플랫폼에서도 많은 추가 작업 없이 얼마나 쉽게 적용 가능한가 입니다. 관련되어진 품질 요구사항은 적용성 설치성 대체성이 되겠습니다.

09:02
해당 이 6가지 용어 단위별 해당 설명 문구에서 이 용어를 고를 수 있는 정도로 구분할 수 있으면 됩니다. 자 퀴즈 한번 보도록 하겠습니다. 소프트웨어 품질 목표 중에 쉽게 배우고 사용할 수 있는 정도를 의미하는 개념으로 가장 타당한 것 올바른 것은 무엇인가 18년도 2회차 기출문제인데요. 자 설명 문구사에서 주 키워드는 쉽게 배우고 사용할 수 있는 정도 이렇게 되어 있기 때문에 포커스는 사용이라고 파악할 수 있고 용어 중에서는 유저빌리티 2번이 되겠습니다. 사용성 다음 ui 표준과 지침에 대해서 살펴보도록 하겠습니다. 먼저 ur 개념에 대한 이해인데요. ui라는 부분 자체는 사용자와 컴퓨터 상호 간의 소통을 위한 연계 작업을 뜻한다.

09:59
다른 시스템과 시스템 간 인터페이스적인 부분에 대해서는 저희가 나중에 네 번째 과목에서 상세하게 다루도록 하겠습니다. 자 ui는 진화해왔는데요. 1990년대부터 시작해서 초창기에는 사용자와 컴퓨터의 단순한 상호작용적인 부분이 국한되어졌지만 업무가 점차적으로 복잡 다양해지면서 단순한 방법으로는 많은 문제점이 발생을 하기 때문에 그러한 오류를 줄이기 위한 방법으로 ui가 변화되어져 왔고 현재는 작업 수행 내역을 구체적으로 작성을 하는 기능이 아닌 정보의 내용과 그 안에 포함된 뜻을 전달하는 표현 방법으로 변하게 됐습니다. 유아의 세 가지 분야입니다.

10:50
유아의 세 가지 분야는 정보 제공과 기능 전달을 위한 물리적 제어분야 그리고 콘텐츠 상세적 표현과 전체적인 구성에 관한 분야 세 번째는 사용자 편의성에 맞춰서 쉽고 간편하게 사용 가능하도록 하는 기능적 분야 물리적 제어 분야 구성에 관한 분야 기능적 제어 분야로 나눌 수가 있습니다. ui 설계 원칙입니다. ui 설계 원칙은 4가지로 직관성 누구나 쉽게 이해하고 사용 가능한가 바로 봤을 때 이 버튼은 어떤 모양이네 이 버튼을 눌렀을 때 어떤 동작이 이루어지겠네 파악할 수 있는 직관성 그리고 유효성 사용자의 목적을 정확하게 달성을 하는가?

11:40
그리고 세 번째 학습성 누구나 쉽게 익히고 배울 수 있는가 마지막으로, 유연성 사용자의 요구사항을 최대한 수용하며 오류를 최소화할 수 있는가 네 가지 ui 설계 원칙 설명 문구를 보고 해당 단어를 고를 수 있도록 익혀 놓으시면 되겠습니다. 자 그리고 ui설계지침입니다. ui설계지침도 종류는 많지만 해당 용어적인 부분과 설명문구만 이해를 하시면 문제 푸는데 크게 어려움은 없습니다. ui설계지침 사용자중심 자 이 ui 설계 지침이라는 부분 자체는 저희가 지금 현재 학습하고 있는 파트는 화면 설계 부분인데요. 이 화면 설계 부분은 실기 과목에도 포함되어지는 부분입니다. 그래서 실제적으로 다양한 사례 및 실습 베이스 중심적인 설명은 실기 파트에서 설명 드리도록 하겠고요.

12:39
전자정보 웹사이트 같은 경우에 행정안전부 쪽에서 해당 ui 및 ux에 대한 가이드를 배포합니다. 거기에 맞춰서 전자정보 웹사이트 즉 해당 공공 웹사이트를 개발할 때는 어떠한 레이아웃이나 포함 구성 요소에 대한 배치 또는 내용에 대한 표시 방법 이런 부분들이 주어집니다. 그와 같이 ui는 설계를 할 때 이렇게 하라 라고 주어지는 게 설계 지침이라고 보면 되겠고요. 자 사용자 중심적이어야 된다. 즉 사용자가 이해하기 편하고 쉽게 사용할 수 있는 환경을 제공하며 실사용자에 대한 이해가 먼저 바탕이 되어야 되겠죠. 그리고 일관성 버튼이나 조작 방법을 사용자가 기억하기 쉽고 빠르게 습득 가능하게 설계한다. 그리고 단순성 복잡하지 않고요.

13:33
조작 방법은 가장 간단하게 작동 가능하도록 인지적 부담을 줄여야 됩니다. 결과 예측 가능 작동시킬 기능만 보고도 결과가 어떤 게 나올 거야. 라고 예측 가능해야 되고 그리고 가시성 주요 기능을 메인 화면에 노출을 해서 조작이 용이하게 해야 됩니다.

13:55
일반적으로 보면 해당 기관의 로고는 왼쪽 상단 접근성이 제일 마우스를 이용해서 제일 접근성이 좋은 쪽에 해당 기관의 로고가 배치가 되어지죠 그리고 표준성 표준화는 디자인을 표준화해서 기능 구조에 대한 선행학습 이후에 쉽게 사용할 수 있도록 하는 것을 뜻하고 접근성 접근성은 누구든지 이용 가능하게끔 그래서 좀 시각이나 청각이 불편하신 분들도 쉽게 웹사이트에 이용할 수 있게끔 도움을 주는 기능들을 넣어라 사용자의 직무나 연령 성별 등 다양한 계층을 수용할 수 있어야 되고 그리고 명확성 사용자가 개념적으로 쉽게 인지할 수 있도록 하고 그리고 오류 발생에 대한 해결 사용자가 오류에 대한 상황을 정확하게 인지할 수 있도록 오류가 떴다 이런 경우에는 오류 팝업 메시지를 띄운다든지 뭔가 잘못됐어요. 라는 알림이 주어지게끔 하라 이 측면입니다.

14:51
유아의 요구사항 확인은 크게 기능적 요구사항인가 라고 양보를 할 수 있는데, ui의 기능적 요구사항의 종류로는 시스템이 무엇을 해야 하는가를 설명하는 즉 시스템의 입력 내용은 무엇인가 그리고 시스템은 시스템의 출력은 무엇이 포함되어져야 되는지 그리고 시스템은 어떤 데이터를 저장해야 되는가 어떤 연산을 수행해야 되는가와 같은 이러한 요구사항들이 기능적 요구사항이 되겠고요. 그리고 비기능적 요구사항은 개발 과정에서 지켜져야 하는 제약 조건들을 뜻합니다. 사용성 효율성 신뢰성 유지보수 재사용성과 같은 품질에 관한 요구사항이라든지. 플랫폼 사용 기술 등 시스템 환경에 관한 요구사항 그리고 비용이나 일정 등 프로젝트 계획에 관한 요구사항들도 비기능적 요구사항에 해당되어집니다. ui 표준과 지침에 관련되어진 퀴즈입니다.

15:48
ui의 설계 원칙 중에 사용자의 요구사항을 최대한 수용하며 오류를 최소화 오류를 최소화하여야 한다. 와 관련된 것은 무엇인가 유아의 설계 원칙 네 가지가 있었습니다. 그 중에서 사용자 요구사항 최대한 수용 오류 최소화 아닌 유연성이었습니다. 네번째유연성이 정답입니다. 자 마지막 파트로 스토리보드에 대해 살펴보도록 하겠습니다. 스토리보드의 개념입니다. 스토리보드란 사용자 경험 ux 구현에 수반되는 사용자와 컴퓨터 또는 인터페이스 간의 상호작용을 시각화하여 디자이너와 개발자의 의사소통을 돕는 도구이고 완성해야 할 웹이나 앱 서비스와 예상되는 사용자 경험을 미리 보기 위한 방법론이 되겠습니다.

16:46
이 스토리보드는 정책이나 프로세스 및 콘텐츠 구성 그리고 와이어프레임 와이어프레임이라고 하는 부분 자체는 화면 내용물을 이렇게 해보는 부분입니다. 기능에 대한 정의 데이터베이스의 연동 등 구축하는 서비스를 위한 대부분의 정보가 수록되어 있는 문서를 뜻하기도 합니다. 스토리보드에 대한 작성기법으로써 작성순서 자 첫 번째 스토리보드 1단계는 메뉴 구성도를 만드는 단계입니다. 메뉴 구성도는 전체적인 메뉴 구성도이고 어떤 것을 보여주고 결정된 사항을 표현하기 위한 메뉴의 순서와 구성 단계 그리고 용어 정의를 하는 단계가 되겠고요. 두 번째 살 확정 스타일 확정은 레이아웃이나 전체적인 배치나 글자의 모양 크기 색상 그래픽에서의 일관성을 유지하는 작업이 되겠습니다.

17:41
마지막으로, 설계하기 화면에 보여주는 실제 시각적인 디자인 컨셉을 설정하는 단계가 되겠습니다. 해당 챕터 내용을 정리하면서요 모의평가 문제 풀어보도록 하겠습니다. 다음 중 소프트웨어 설계의 종류 중에 상위설계에 해당하지 않는 것은 무엇인가 사용자 인터페이스 설계 모듈 설계 데이터 설계 아키텍스 설계 중에 모듈 설계는 하위 설계에 해당되었던 부분입니다. 두 번째 소프트웨어 아키텍처를 잘 설계하려고 할 때 고려해야 할 것 중에 옳지 않은 것 틀린 것을 골라라 옳지 않은 것입니다. 소프트웨어 아키텍처 설계 의사소통의 도구로 활용할 수 있어야 된다. 소프트웨어 아키텍처는 구현에 대한 제약 사항을 정의할 필요는 없다.

18:38
품질 속성을 결정해야 되고 재사용할 수 있게 설정해야 된다. 틀린 것은 2번입니다. 구현에 대한 제약사항도 정리할 필요가 있습니다. 다음 세 번째로, 넘어가도록 하겠습니다. 다음 중 사용자 인터페이스 설계지침이 아닌 것은 사용자 인터페이스 설계 지침 상식적인 측면에서 한번 천천히 읽어볼게요 내용을 첫 번째 인터페이스는 일관성 있게 설계해야 돼 그렇겠죠. 이쪽은 틀리고 저쪽도 틀리고 그러면 혼란스럽겠죠. 인터페이션을 일관성 있게 설계되어야 되겠고 실사용자에 대한 이해가 바탕이 돼야 된다. 실제 이용하는 이용자들이 편하게 이용할 수 있어야 됩니다. 행동 패턴들 있죠. 어떻게 행동하라 거기에 맞춰가지고요. 자 가장 보편적으로 저희가 어떤 책을 읽는다 내용은 위에서부터 아래로 왼쪽에서 오른쪽으로 이렇게 읽는데 해당 배치를 잘못하면 안 되겠죠.

19:34
그래서 실제 사용하는 사용자에 대한 이해의 바탕 세 번째 행동들 사이에 기억해야 할 정보의 양을 늘려야 한다. 자 기억해야 될 분량들이 많아지게 되면 해당 머리가 많이 복잡해지겠죠. 오히려 쉽게 쉽게 적시적으로 아 이거는 이 버튼은 이거 누르면 이거 하겠네 바로바로 알 수 있게끔 행동들 사이에 기억하는데 정보의 양은 오히려 늘려야 되는 게 아니라 줄여야 됩니다. 틀린 것은 3번 사용자의 직무와 연령 성별 등 다양한 계층을 수용해야 된다. 맞죠. 자 네 번째 다음 중 스토리보드 작성 순서가 올바르게 나열된 것은 스토리보드 작성 순서 저희 1 2 3단계 이렇게 학습을 했었는데요. 첫 번째 단계는 메뉴 구성도 작성이었습니다. 메뉴구성도 작성 두 번째는 레이아웃이라든지.

20:34
어떤 디자인적인 부분에 대한 스타일 확정 그다음 마지막으로, 실제 설계하기 나 다 가 나다가 3번이 되겠습니다. 자 핵심 정리입니다. 세 파트로 나눠서 저희가 학습했던 부분 총괄 정리하겠습니다. 소프트웨어 아키텍처의 정의 소프트웨어 개발을 쉽게 하도록 기본적인 틀을 만든 것을 이야기하고 복잡한 개발을 체계화하기 체계적으로 하기 위한 밑그림을 뜻한다. 국제표준화기구의 isoic의 구하나26 모델에서의 소프트웨어 품질 특성 여섯 가지 중에 해당 고르는 문제 한 문제 객관식 문제로 꼭 나오는 편입니다. 기능성 신뢰성 사용성 효율성 유지보수성 그다음에 마지막으로는 이식성입니다. 이식성 오타가 하나 있네요. 이렇게 정리하도록 하겠고요.

21:30
그다음에 ur표준과 지침 ui는 사용자 인터페이스는 사용자와 컴퓨터 상호 간의 소통을 원활하게 도와줄 수 있는 연계 작업을 뜻한다. ui 설계 원칙은 4가지 직관성 유효성 학습성 유연성 그리고 ui설계지침 사용자 중심이어야 되고 일관성 단순성 예측 가능해야 되고 결과를 그리고 가시성 표준화 접근성 명확성 오류 발생 해결이 있었습니다. 마지막으로, 스토리보드 스토리보드는 ux구현에 수반되는 사용자와 컴퓨터 그리고 인터페이스 간 상호작용을 시각화하여 디자이너와 개발자의 의사소통을 돕는 도구 역할을 담당했고요.

22:24
스토리보드의 작성 순서는 1단계 메뉴 구성도 만들기 2단계 스타일 확정 3단계 설계하기였습니다. 네 이상으로 ui 요구사항 확인하기에 대해 학습을 마치도록 하겠습니다. 챕터2 화면 설계 두 번째 내용으로 ui 설계하기에 대해 살펴보도록 하겠습니다. 학습목표는요 ui 표준지침에 따라 화면과 폼의 흐름을 설계하고 제약사항을 화면과 폼 흐름설계에 반영할 수 있다. 둘째, ui 요구사항과 ui 표준 및 지침에 따라 사용자의 편의성을 고려한 메뉴 구조를 설계할 수 있다. 셋째, ui 요구사항과 ur 표준 및 지침에 따라 하위 시스템 단위의 내 외부 화면과 폼을 설계할 수 있다. 입니다.

23:23
세부 학습 내용은 ur 흐름 설계 ur 상세 설계 감성공학 순으로 살펴보도록 하겠습니다. 우선 세부출제기준에 보면 감성공학과 ur 설계 도구라고 이렇게 나와 있습니다. 그 부분에 포커스를 맞춰가지고 살펴보도록 할 건데 우선은 ncs 학습 모듈에는 ur 흐름 설계와 상세 설계가 포함되어 있어 가지고 이 부분이 또 뒤에 또 이어지는 내용이라서 개괄적으로라도 짚고 넘어가겠습니다. 영어사진입니다. ui 설계서 ui 설계서는 표지 개정 이력 ui 요구사항 정의 시스템 구조 프로세스 정의 화면 설계 등으로 구성되어집니다. 프로토타입이란 무엇인가 자주 언급됐던 용어이죠.

24:15
새로운 소프트웨어의 설계 또는 성능 구현 및 운영 가능성을 평가하거나 요구사항을 좀 더 잘 이해할 수 있도록 하기 위해서 전체적 기능을 간략한 형태로 구현한 시제품이 프로토타입입니다. 마지막으로, 감성공학이라는 용어인데요. 개인의 경험을 통해서 얻어지는 복합적인 감성을 과학적 측면으로 측정하고 분석해서 제품 설계에 최대한 반영하는 공학 기술을 뜻합니다. 첫 번째 ui 흐름 설계에 대해 살펴보겠는데 ui 설계서 구성을 바탕으로 해서 ui 해당 설계의 흐름 자체를 파악해 보도록 할 건데 ui 설계서 구성은 표집 개정 이력 ui 요구사항 정의 그리고 시스템 구조 사이트맵 프로세스 정의 화면 설계로 구성되어집니다.

25:09
설계서 표지에는 해당 이 프로젝트가 어떤 거야. 라고 하는 프로젝트 이름 그리고 시스템명이 표기가 되어지고요. 계정이력이라고 하는 부분 자체는요 이 버전을 표시를 합니다. 이게 최초버전인가 최초 버전에서 해당 업데이트를 한 건가 그래서 최초 버전은요, 첫 번째 초안 작성인 경우에는 그 초안을 초기 버전 1.0으로 설정하고요. 변경 또는 보안이 충분하게 이루어졌을 경우에는 x.0 2.0 버전 3.0 버전 이렇게 설정을 합니다. 네 그리고 ui 요구 사항 정의가 포함되었습니다. ui 요구 사항들을 재확인하고 정리하는 내용이 포함되어지고 그리고 그 요구사항을 기초로 해서 ui 시스템 전체적인 구조를 설계하는데 그게 시스템 구조입니다. 시스템 아키텍처라고 하고요.

26:08
그리고 앱에서는 인포메이션 아키텍쳐라는 용어를 사용을 합니다. 전체적인 측면에서 해당 시스템이 가치화되어지는 공지사항 어떤 기능적인 부분에 대한 메뉴 공지사항 회원 관리 도서 내역 마이페이지 권한 설정을 가지겠다. 그런데 해당 이 메뉴 항목을 누가 이용하느냐 사용자가 이용하는 기능은 어떤 거야. 그리고 그 해당 이용하는 기능에 대해서 관리자 측면에서는 어떤 거를 리스폰스 해야 되느냐 응답을 해야 되느냐라는 부분을 이렇게 개념들로 나타내는 게 시스템 구조가 되겠고요. 이를 바탕으로 실제적으로 웹베이스에서는 홈페이지에서는 홈페이지 주요 메뉴 항목들을 계층 구조 형태로 나타내는 이 홈페이지는 어떠한 페이지들이 포함되어 있는가 라는 부분을 한꺼번에 한 페이지에서 볼 수 있는 사이트맵을 만듭니다. ur 시스템 구조 내용을 사이트맵 형태로 작성하게 되고요.

27:07
사이트맵의 상세 내용은 표 형태로 작성할 수 있습니다. 이 화면 설계는 실기 과목에도 포함되어집니다. 그렇기 때문에 실기 파트에서요 해당 좀 더 세부적인 내용으로 실습 베이스로 익히도록 할 겁니다. 자 그다음에 프로세스 정의입니다. 프로세스 정의는 사용자 관점의 요구 프로세스들을 진행되는 순서에 맞추어서 다시 정리하는 것을 이야기합니다. 자 일례로 로그인 메뉴가 있고 공지사항이 있고 도서 목록이 있고 쭉 있는데, 이 해당 메뉴들을 이용할 때 어떤 순서대로 어떤 처리 과정을 통해서 순서대로 얘를 이용하느냐 예를 들어서 회원제 홈페이지다 라고 하게 되면 공지사항이든 도서 목록을 이용하든 마이페이지를 이용하든 반드시 선행적으로 로그인 부분부터 먼저 요구를 하겠죠.

28:00
그래서 아래쪽에 보면 사용자는 먼저 로그인 과정을 거쳐야되 로그인하고 난 다음에 이용할 수 있는 어떤 대상으로 공지사항을 확인할 수도 있고 도서목록을 조회할 수도 있고 마이페이지를 확인할 수도 있다. 네 전체적인 프로세스적인 부분을 정의하는 부분이 되겠고요. 그다음에 화면 설계입니다. 프로세스를 통해서 어떠어떠한 화면들이 나와야 돼 그래서 ui 프로세스 정의를 참고해서 각 페이지별로 필요한 화면을 도출하고 그것을 설계하는 것이 화면설계가 되겠고요. 화면설계 절차적인 측면에서는 와이어프레임 앱 개발에서는 와이어프레임이라고 해서 스마트폰에 해당 사이즈를 실수로 해서 안에는 어떠한 것들이 들어가야 돼 라는 것을 필기 도구를 이용해서 그려도 되고 또는 디지털 도구를 이용해서 그려도 되고요.

28:55
러프하게 화면을 구성하는 것을 와이어 프레임이라고 하고요. 그다음에 그걸 좀 더 실제적으로 이용해 볼 수 있게끔 프로토타이핑 기법을 활용해서 시연 또는 시제품을 만들 수도 있습니다. 자 밑에 나와 있는 부분 자체는 참고적으로 스토리보드의 한 화면으로서요 홈페이지 홈페이지에 공지사항은 내용 구성을 이렇게 하고 배치적인 부분 로고는 왼쪽 상단 로그아웃은 오른쪽 상단 왼쪽 부분에 메뉴 목록 이런 식으로 배치했고 해당 그 부분에 대한 설명이 기술되어 있는 예입니다.

29:34
자 ui 설계 흐름 설계에서요 ui 유용성이라고 하는 부분에 대한 용어가 나오는데 이 유용성이란 건 뭐냐 자 ui에서 고려해야 될 사항인데 유용성이라고 하는 부분 자체는 사용자가 시스템을 통해서 원하는 목표를 얼마나 효과적으로 달성할 수 있는가에 대한 척도를 뜻합니다. 이 유용성에서는 사용자 측면에서 이용할 때와 개발자 측면에서 제공해야 될 때 그 모형 간의 어떤 차이를 최소화해야 된다. 라는 부분이 고려사항이고요. 그 차이가 발생하는 예로 들어서 두 가지가 있는데, 실행차가 있고 평가차가 있습니다. 개념은요, 실행차라고 하는 부분은 실행 가능한 기능과 사용자의 원래 목적이 서로 상이해서 발생한다.

30:27
이게 무슨 말이냐면 실행차라고 하는 부분은 실행 속도를 포커스에 두고 해당 이용자가 이 홈페이지에서 내가 주로 이용하고자 하는 부분 자체의 서비스를 빨리 이용할 수 있게끔 해당 ui를 설계해야 된다 라고 이해하시면 될 것 같고요. 평가차라고 하는 부분자체는 해당 이용자가 시스템의 어떤 처리 과정을 진행하고 있는데, 이게 제대로 되는지를 알 수 있게끔 그 결과치를 알 수 있게끔 빠르게 결과를 인지할 수 있게끔 서비스를 해야 된다. 라는 부분을 이해를 하시면 됩니다. 그래서 좀 더 세부적으로 살펴보면 실행차를 줄이기 위해서는 ui 설계를 어떻게 해야 되느냐 실행차를 줄이기 위한 ui 설계는 먼저는 포커스가 사용자가 어떻게 행동하는지 어떤 의의를 갖고 있는지 그 사용자에 대한 파악이 먼저 선행이 되어져야 됩니다.

31:20
그래서 그 사용자가 보다 관심을 가지고 가지는 항목을 해당 홈페이지라고 하면 홈페이지 화면 내에 보다 쉽게 눈에 띄게끔 배치를 하고요. 이용하기 쉽게끔 하는 부분이죠. 그리고 행위 순서 규정이라고 해서요. 중요도를 나눕니다. 제일 중요한 거야. 한 중간 정도야 중요도 정도 낮아 그러면 중요도가 제일 높은 곳 중요도가 높은 작업은 단계 수요를 최소화한다. 라는 부분을 한 번만 클릭하더라도 그걸 바로 볼 수 있게끔 하라는 부분이고요. 중도적으로 조금 낮은 거는 몇 단계 선택해서 보여줘도 괜찮다라는 부분입니다. 행위의 순서가 사용자의 기존 경험에 비추어서 가능한 한 빨리 친숙하게 되도록 설계를 하라 그리고 행위의 순서대로 실행이라는 부분은요, 예를 들어서 어떤 폼 양식을 작성한다라고 할 때 해당 폼 양식문 내에 입력란들이 있는가 하면 선택 레디오 버튼이라든지. 체크박스들 있잖아요. 이렇게 기본값 디폴트가 이렇게 선택되어 있는 것들 있죠.

32:20
그런 부분들을 고려해서 굳이 수정 안 하고 일반적으로 선택하는 항목이 미리 체크가 돼 있으면 좀 더 빨리 이용할 수 있겠죠. 올바른 커스 위치나 아니면 해당 회원가입 홈에 페이지가 열었을 때 커스가 딱 첫 번째 입력해야 될 입력란에서 깜빡깜빡하면 마우스를 굳이 클릭해야 되는 그 절차를 생략할 수 있겠죠. 올바른 커스 위치와 디폴트 레디오 버튼이나 체크박스 같은 것들을 적절하게 설정한다. 이게 실행차를 줄이기 위한 ui 설계입니다. 다음 평가차를 주기 위한 ui 설계 원리 평가차는 결과를 빠르게 볼 수 있게끔 실행한 키 조작의 결과와 키 조작으로 변화되어진 시스템 상태를 사용자가 빠르게 지각할 수 있도록 해줘야 된다. 예를 들어서 제가 뭘 어떤 예약 신청을 했어요.

33:14
이거 예약 신청이 진행 중인가 어떻게 됐는가 라는 부분을 알 수 있도록 예약 신청 버튼을 딱 눌렀어요. 그러면 상태가 예약 중 이렇게 버튼이 바뀐다든지 이렇게 해서요. 아 이렇게 지금 진행 중이네 라는 것을 알 수 있도록 하라 이 말입니다. 사용자가 가지는 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악할 수 있도록 하는 것이 좋다. 그리고 결과는 나중에 최종적으로 이렇게 이러한 결과가 나타날 거예요. 라고 하는 미리보기 기능이라든지. 이러한 것들을 제시할 수 있다면 제공해 주는 것이 바람직합니다. 자 해당 파트의 퀴즈 네 문제 한번 풀어보도록 하겠습니다. ui의 설계 단계에서 수행하는 작업의 순서로 올바른 것은 보기 항목 네 가지 제시되어져 있는데, 첫 번째 ui 요구사항 정리한다.

34:10
둘째, 나 화면 설계 다 시스템 구조 다 라 프로세스 정리 제일 먼저 해야 되는 것은 ui 요구상 확인이라고 그랬습니다. 네, 그러면 가가 첫 번째 와야 돼요. 가가 첫 번째 오지 않는 거를 지워요 네, 그러면 1 2 3 중에 다시 좁혀가지고 두 번째 나 다 라 두 번째에서 결과 나오겠습니다. 네 골라지겠네요. ui 요구상 설계하고 난 다음에 그 다음에는 전체적인 틀 전체적인 구조 시스템 구조를 설계한다. 했을 때 다가 되겠습니다. 그러면 가다 다음은 라 프로세스 정의 마지막에 화면 설계 3번이 정답입니다. 두 번째 파트로요 ui 상세 설계에 대해 살펴보도록 하겠는데 저희 ncs 학습 모듈을 보면 갑자기 ui 시나리오라는 용어가 확 튀어나옵니다.

35:00
근데 그 용어적인 부분을 먼저 이해할 필요성이 있을 것 같아서 정리를 추가적으로 해드리는데 ui 시나리오는 뭔데 ui 시나리오란 사용자가 경험하게 될 이야기를 미리 그려봄으로써 서비스 전체의 윤곽을 표현할 수 있다. 표현하는 것이다. 웹이나 앱을 사용하는 모든 단계마다 일어나는 사용자와 서비스의 상호작용을 기술한 것을 뜻합니다. 시냅시스라고 하는 부분은 일례로 해당 이러한 상황이 있을 때 또는 웹이나 앱을 개발하고자 할 때 이 사람이 원하는 게 뭔가 상황적인 부분을 쭉 기술해놓고, 이 사람이 원하는 것을 쭉 정리해 놓았는데요. 시간관계상 제가 개괄적으로만 설명드리고 넘어가도록 하겠습니다.

35:49
홍길동은 어디 어디에 살고 있고 대학을 졸업한 후에 취업을 했지만, 해당 새로 업무에 적응하느라고 스트레스를 많이 받고 있고 야간도 잤다 근데 휴가 한번 길게 가려고 휴가를 모아 하지만 방학 때마다 여행을 다녀온 해당 사진을 올릴 때마다 하고 싶은 마음에 간절했는데 막상 여행사 패키지 상품들을 살펴봤지만 본인이 원하는 걸 잘 못 찾겠더라 이러한 경우에 이 사람한테 맞는 어떠한 서비스 앱이든 개발하는 부분을 목표로 설계를 한다면, 시나리오 ui 작성의 예인데요. 구성 요소적인 측면에서 사용자 그룹을 나눕니다. 이 사람은 여가시간을 활용해서 해외로 여행을 가고 싶어 하는 사람이야 그리고 시냅시스를 간단하게 정리했고 니즈 이 사람이 원하는 니즈는 뭔데 여가 시간을 활용해서 합리적 비용으로 해외에 자유여행을 가고 싶어 한다.

36:45
현재 불편사항들은 이러한 것들이 있더라 그래서 그거를 개선하는 대안으로서요 여행지 인근의 명소를 추가해서 일정을 조절할 수 있고 가격대를 다양하게 제공하고 여행 경로를 상세하게 제공하면 좋겠다. 서비스 구성은 가능한 한 구성 가능한 상세 일정을 프로그래밍화하고 다양한 가격대로 구성을 하고 이동 방법이나 거리 등등 이러한 예시입니다. 감정 요소는 일정별 코스 계획 수립을 유용하게 하고 부가 정보 이용에 대한 만족도를 높여주면 좋겠다. 네 시나리오 작성 원칙입니다.

37:24
ui 시나리오 작성 원칙 ui의 전체적 기능과 상호작용 방식을 개발자가 쉽게 이해하도록 구체적으로 작성을 하자 그리고 모든 기능은 공통 적용이 가능한 ui 요소와 interaction 상호작용적인 부분에 대한 일반적 규칙을 정의하자 그리고 대표화면의 레이아웃과 그 화면들 속의 기능을 정의하고 인터랙션의 흐름을 정의할 때 화면 내와 화면 간의 인터랙션의 순서적인 측면 순차적 또는 분기 나눠진다든지 조건에 따라서 어떤 걸로 해야 될까 또는 반복적으로 이루어지는 부분들 이러한 것들을 명시하고요. 예외사항에 대비한 케이스를 정의하고 ur 일반 규칙을 지키면서 기능별 상세 기능 시나리오를 정의합니다. 마지막으로, ur 시나리오 규칙을 지정한다.

38:24
이게 ur 시나리오 작성 원칙이 되겠습니다. 네 다음으로, ur 시나리오 문서 작성의 요건으로서는요 완전성이다. 누락된 게 없이 상세하게 다 기술을 해야 돼 일관성이 유지되어야 된다. 서비스에 대한 목표나 시스템 및 사용자 요구사항에 대해서 일관성 있게 돼야 되고 또는 디자인 측면에 대한 어떤 ui 스타일도 플로우나 레이아웃도 일관성 있게 구성해야 된다. 이해성요 처음 접하는 사람도 쉽게 알 수 있도록 구성하고 설명이 필요하겠다. 어려운 용어는 될 수 있으면 사용하지 말자 가독성 읽기 쉽게 작성하자 문서 템플릿과 타이포그래피 문서를 쉽게 읽을 수 있도록 하고 표준화되어진 템플릿을 작성해서 적용하는 것도 좋겠다. 그 외에 세부적인 측면은 개괄적으로만 보고 넘어가겠습니다. 수정이 용이해야 되겠다. 쉽게 변경 가능한 것이 좋겠다.

39:13
수정 또는 개선 사항을 지난해 반영함에 있어서 쉽게 적용을 할 수 있도록 하자 추정 용이성 변경 사항들이 언제 어디서 어떤 부분에 왜 발생했는지라는 부분에 대한 것을 추적할 수 있도록 하자 마지막으로요 모범적인 ui 시나리오 문서는 어떠한 효과가 있을까 요구사항에 대한 오류를 줄여줄 수 있겠고요. 그리고 의사소통의 오류를 감소시켜주고 개발 과정에서의 제작업이 줄어들고 또 혼선도 맞출 수 있고요. 불필요한 기능을 최소화시키고 시나리오 작성과 소프트웨어 개발 비용도 절감시켜줄 수 있고 개발 속도를 빠르게 할 수가 있고 유관부서 만족도도 높일 수가 있겠다. 이게 모범적인 ur 시나리오 문서의 효과가 되겠습니다. 네 ur 프로토타입 제작에 대해 알아보도록 하겠습니다.

40:11
ur 프로토타입 제작에서는요 주요 키의 위치와 기능을 고려해야 됩니다. 화면상에 공통적으로 배치되어지는 주요 키와 위치 기능에 대한 설명이 필요하고 여러 화면 간의 일관성을 보장할 필요성이 있습니다. 그리고 공통적인 요약 요소에 대해서 어떠한 형태로 해야 되는지 라는 부분에 대한 정의가 필요하고요. 사용자 조작에 어떻게 반응하는지 그 흐름에 대해서도 상세하게 설명할 필요가 있겠습니다. 그리고 기본적인 스크린에 대한 레이아웃을 그대로 유지를 해야 되겠습니다. 자 이건 실기 파트에서 좀 더 구체적으로 저희가 설명을 드릴 건데 화면이 이렇게 있다라고 할 때 인디케이트라고 하는 부분 자체는 상단부로 이야기를 합니다. 그리고 타이틀 그리고 내용이 있고 밑에는 보통 푸터가 있죠. 고정적으로 홈페이지 같은 경우에 연락처라든지 사업자 정보라든지 모든 페이지에 고정적으로 노출되어지는 내용들 있죠. 기본적인 스크린 레이아웃을 유지해야 된다.

41:11
각 기능들 간의 화면 레이아웃의 일관성을 보장하는 것이 좋겠다. 그리고 기본적인 interaction에 대한 규칙 대한 기술도 터치 제스처 등 공통적으로 사용되는 조작에 대한 방법 홈키의 동작 방식 이러한 것들에 대해서 프로토타입을 제작할 때 기술하는 게 좋겠다. 그리고 공통적인 단위의 태스크 흐름 많은 기능에 공통적으로 자주 나타나는 어떤 삭제나 검색이나 이러한 부분에 대해서 소리 재생 등의 인터랙션 흐름을 설명하는 것이 좋겠고 마지막으로, 케이스 문서라고 해서 다양한 상황에서의 공통적 시스템 동작에 대한 정의 문서도 작성할 필요성이 있겠습니다. 네 그다음에 ur 설계 도구입니다. 해당 이 파트에서 세세 기준에 보면 ur 설계 도구 시험 출제할 거예요. 이렇게 돼 있거든요.

42:08
개괄적으로 제가 정리를 해서 설명드립니다. 프로토타이핑 방식으로서 크게 두 가지로 아날로그 수작업을 통해서 하느냐 아날로그 프로토타입 즉 손으로 수작업을 하는 거 이 방식으로 이 방식의 얘는 화이트보드를 활용한다든지 출판을 이렇게 가져다 놓고 여기에서 마킹해가면서 설명을 적어놓는다든지 또는 펜 또는 종이를 이용해가지고 또는 포스트잇을 붙여가지고 하는 방법이 아날로그 프로토타이핑이고요. 단점은 수정하기가 좀 어렵겠죠. 이에 비해서 디지털 다양한 툴을 이용한 프로토타이핑 방식 보편적으로 파워포인트를 많이 활용합니다. 파워포인트에 해당 ui 설계적인 기능을 덧붙여서 서비스하는 게 파워 목업이라고 있고요. 그 외에 아크로벳 비지오 인비전 마블 아도브 엑스디 플린토 이런 다양한 툴들이 있습니다.

43:06
키노트 ux핀 html 이건 홈페이지 제작하는 거죠. 디지털 프로토타이핑 그걸 활용하게 되면 장점은 종이 프로토타이핑과 달리 상호작용의 어떤 가능성 상호작용이 실제로 이루어지는 부분들을 좀 더 파악하기가 용이하다 자 해당 파트에 대한 퀴즈입니다. 다음 중 디지털 프로토타이핑 종류로 올바르지 않은 건 어떤 것인가? 간단하게 제시해 보았는데 디지털 프로토 타이핑 종류가 아닌 거 고르라 이 말입니다. 파워포인트 화이트보드 비지오 인비전에서 화이트보드는 수작업이었죠. 이건 아날로그 방식 손으로 직접 하는 거 정답은 2번이고요. 자 마지막 세 번째 파트로 감성공학 내용 정리하도록 하겠습니다.

44:04
감성공학의 개념 감성공학이란 제품 설계에 인간의 특성과 감성을 최대한 반응하는 공학 기술을 이야기합니다. 기본 철학은 인간 중심적인 설계이고요. 1988년도 시드니 국제학회에서 감성공학이라는 이름 자체가 사용되기 시작했다. 개인의 경험을 통해서 얻어지는 복합적인 감성을 과학적 측면으로 측정하고 분석해서 제품이나 환경을 그에 맞게 안락하고 쾌적하게 개발하려고 하는 분야이고요. 크게는 다섯 가지 분야가 있는데, 뒤에 보면 감성공학 관련 기술 다섯 가지 분야 인간공학 인지공학 등 인간 특성을 파악하라는 연구에 기본을 둔 생체 측정 기술이 있고요.

44:51
인간 특성에 적합하도록 사용자 인터페이스를 실현하기 위한 기술로서 센서 공학이나 퍼지뉴럴 네트워크 기술 신경망 기술 등 인간의 오감 5개 시각 청각 촉각 후각과 같은 센서 센서 및 감성 처리 기술이 있고요. 그리고 두 번째입니다. 그 다음에 산업디자인 등과 같은 감성디자인 기술 그리고 마이크로 기구 설계나 극소 작은 기계 응용 등 마이크로 가공기술 있고요. 마지막으로, 사용성 평가 기술 가상현실 기술 등과 같이 인간에 대한 적합성을 판단하고 새로운 감성을 창출하기 위한 기술 이렇게 다섯 가지 분야가 감성공학 관련 기술입니다.

45:43
자 관련해서 퀴즈 문제 한번 풀어볼게요 감성공학 관련 기술로 적절하지 않은 거 골라라 틀린 거 골라라고 요구합니다. 생체 측정 기술 매크로 가공 기술 감성 디자인 기술 신경망 기술 자 좀 전에 작다라고 말씀드렸어요. 해당 이 매크로의 반대가 마이크로죠 감정공학 기술에서는 마이크로 가공 기술이 요구됐고 네 매크로 가공 기술은 아닙니다. 자 해당 ur 설계 전체적인 내용을 정리하면서 평가 문제 풀어보도록 하겠습니다. ur 프로토타입의 장점이 아닌 것은 장점이 아닌 겁니다. 사용자 설득과 이해가 쉬워요 맞죠. 개발 시간이 감소합니다. 맞죠. 정확한 문서 작업이 생략될 수 있다.

46:41
이거는 단점입니다. 단점 장점이 아니고 3번이 장점이 아니고요. 오리올 사진을 발견할 수 있어 모두 장점입니다. 다음 두 번째 실행차를 줄이기 위한 실행차라고 하는 부분 자체는 빠르게 실행시킬 수 있게끔 이라고 말씀드렸죠 실행차를 줄이기 위한 ur설계 원리에 맞지 않은 거 틀린 거 사용자 중심적으로 의도를 잘 파악해야지만 된다. 말씀드렸죠 사용자의 의도 파악이 사용 의도를 파악한다. 맞고요. ui를 제공함으로써 행위를 순서대로 실행할 수 있도록 설계한다.

47:25
행위순서 고려하는 거 수행한 키 조작의 결과를 사용자가 빠르게 지각 빠르게 인식할 수 있는 방향으로 설계한다 라고 하는 부분은 실행차를 줄이기 위한 방법이 아니라 평가차를 줄이기 위한 결과를 빠르게 볼 수 있게끔 그래서 3번이 실행착오를 줄이기 위한 게 아니고요. 마지막 사용자 행위 순서를 규정하여 설계한다. 4번은 맞습니다. 틀린 것은 3번 다음 문제 모범적인 ui 시나리오 문서의 효과로 올바르지 않은 건 무엇인가 여러 가지 아까 저희가 살펴봤을 때 효과들이 쭉 라이얼 리스트 됐었는데 상식선에서 푸셔도 어느 정도 골라낼 수 있는 문제입니다. 유한 시나리오 문서의 효과는 개발 속도를 지연한다. 노출된다는 말이잖아요. 나쁜 거죠. 개발 속도를 좀 더 빨리 알 수 있다.

48:18
그래서 효과로 올바르지 않은 것은 1번이 틀렸고 요구사항 오류를 줄일 수 있고 의사소통의 오류를 줄일 수 있고 또 불필요한 기능을 최소화할 수 있어 라고 하는 부분은 ui 시나리오 문서 효과로 지적 올바른 겁니다. 4번으로 보도록 하겠습니다.

48:37
네 번째 문제 다음에 ui 설계 도구의 유형 중에 ui 패턴과 ui 모델링 ui 디자인 및 소스코드 생성 등 생산성 향상과 화면의 품질 확보를 위한 도구로 올바른 것을 골라라 ui 설계 다양한 도구들 보기 항목으로 제시되어 있는데, 문서 작성 및 드로잉 ui 설계 및 개발 전문 도구 화면 설계를 위한 전문 도구 해당 ur 플랫폼에 포함되어진 도구 다양한 해당 기능들을 지원하고 생산성 향상과 품질도를 높일 수 있는 도구는 두 번째 ur 설계 및 개발 전문 도구가 되겠습니다. 자 마지막으로, 핵심 정리하면서 마치도록 하겠습니다.

49:31
ui의 흐름 설계에서 저희가 다뤘던 내용으로서 ui 설계서에는 어떤 내용들이 포함되어 있느냐 먼저 표지에 해당 ui에 대한 시스템명 이런 것들이 명기되어 있었고, 버전의 어떻게 개정 이력들 그리고 ui 요구사항 정의 시스템 구조 시스템 아키텍처 사이트맵 프로세스 정의 화면 설계 등이 포함되어진다 유용한 시스템은 사용자 모형과 개발자 모형 간의 두 가지 차이 실행차와 평가차를 최소화할 필요성이 있다. ur 상세 설계에서는 ur 시나리오에 대해서 저희가 살펴봤는데 ui 시나리오는 사용자와 경험하게 될 이야기를 미리 그려봄으로써 서비스 전체적인 윤곽을 표현한 것인데 웹이나 앱을 사용하는 모든 단계에서 일어나는 사용자와 서비스의 상호작용을 기술한 것이다.

50:26
그리고 ui 프로토 타입은 확정된 요구 사항을 기반으로 ui 전략을 상세화하는 과정이었고 ui 디자인 작성 이전에 미리 화면을 설계하는 단계였습니다. 마지막으로, 감성공학입니다. 감성공학은 개인의 경험을 통해서 얻어지는 복합적 감성을 과학적 측면으로 측정하고 분석에서 제품 설계에 최대한 반영하는 공학 기술이었고요. 감성공학 기술은 크게 다섯 가지가 있었습니다. 생체 측정 측정 그리고 오감 센서 및 감성 처리 기술 감성 디자인 기술 그리고 마이크로 가공 기술 인간에 대한 적합성을 판단하고 새로운 감성을 창출하기 위한 기술 이렇게 다섯 가지 분야가 있었다. 자 이상으로요 ur 설계에 대해 살펴봤습니다.

https://youtu.be/5DeWAkIdWbM?si=bwPdHJzB7aQI_6NL

1. 현행 시스템 분석을 통한 소프트웨어 설계

1-1. 현행 시스템 분석의 중요성과 목표
- 소프트웨어 설계의 첫 번째 단계인 현행 시스템 분석의 필요성에 대해 강조함
- 현행 시스템 분석을 통해 개발 범위와 향후 개발 시스템의 이용 방향성을 분석하는 것에 대해 설명함
- (중요) 운영 제약, 데이터베이스 관리 시스템 등 요구 사항을 식별하는 것이 중요함
- 향후 개발될 목표 시스템을 명확하고 구체적으로 기술하는 것이 핵심 목표임

1-2. 현행 시스템 파악 절차와 그 세부 내용
- (중요) 현행 시스템 파악 절차의 주요 단계와 각 단계의 세부 내용에 대해 설명함
- 하위 시스템 파악, 시스템 기능 파악, 시스템 인터페이스 현황 파악 등의 세부 내용을 파악해야 함
- 각 파악 단계에서 시스템 구성 현황, 기능 현황, 인터페이스 현황 등을 중점적으로 파악해야 함
- 아키텍처 및 소프트웨어 구성 파악 시, 시스템 아키텍처 구성도를 작성하는 것이 중요함

1-3. 현행 시스템 분석의 실제 적용 예시
- 전자 정보, 행정안전부 등 실제 기관에서 사용한 현행 시스템 아키텍처 구성도 예시를 제시함
- (중요) 소프트웨어 구성도를 작성할 때, 사용자 수와 같은 정보를 고려해야 함
- 네트워크 구성에 대한 파악 시, 네트워크 구조와 통신 규약 등을 명시해야 함
- 파악 과정에서 해당 기관의 업무, 기능, 인터페이스 등을 구체적으로 명시해야 함

2. 현행 시스템 파악

2-1. 시스템 구성도
- 시스템의 주요 사양, 수량, 종류, 이중화 여부 등을 포함한 시스템 구성도 작성이 중요함
- 서버의 용도, 제품명, CPU, 메모리, 하드디스크 용량 등 포함됨
- 시스템 구성도는 인프라 기술 구축 시 고려 사항과 인프라 기술 구축의 난이도 및 비용 가능성을 예측함
- (중요) 현행 시스템 파악 시, 서버와 네트워크의 물리적 위치 관계와 보안 취약성 분석, 네트워크 장애 발생 추적 및 대응 등을 포함함
- 한국전기안전공사와 국립어학원의 네트워크 구성도 예시에서 서버와 네트워크의 연결 방식을 확인할 수 있음

2-2. 개발 기술 환경 정의
- 개발 기술 환경 정의는 운영 체제, DBMS, 미디어웨어, 오픈 소스 등 고려 사항을 포함함
- 운영 체제는 하드웨어와 소프트웨어 리소스를 관리하고, 전 세계 사용자에게 공통 서비스를 제공하는 소프트웨어임
- 시스템 소프트웨어와 응용 소프트웨어로 나뉨
- 윈도우, 유닉스, 리눅스 등 주요 운영체제의 종류와 특징을 이해함
- 운영체제 선택 시, 라이선스 비용, 신뢰도, 성능, 지원 기능 등을 고려함

2-3. 시스템 구축 고려 사항
- 신뢰도는 운영체제의 장기화 시스템 운영에 영향을 미침
- 성능은 대규모 또는 대량 파일 처리와 응용 프로그램 다운로드 시 성능 저하나 재기동이 없는지 확인함
- 지원 기능은 운영체제가 제공하는 메모리 용량과 관련이 있음
- 운영체제의 버그나 팬츠 설치로 인한 제기 동작과 성능 저하를 고려함
- 정보 시스템 구축 시, 운영체제의 신뢰도, 성능, 지원 기능 등을 고려하여 선택해야 함

3. 오픈소스 사용의 장점

3-1. 소프트웨어 오픈소스 도입
- 소프트웨어 도입의 장점으로는 기술 혁신, 사용자 참여, 지원성이 있음
- (중요) 도입 시 기존 비용 대비 효과를 고려해야 함
- 오픈소스 도입으로 기존 개발과 유지보수 비용을 절감할 수 있음
- 오픈소스 사용 시 기술적 지원이 중요함
- (중요) 공급업체의 기술 지원 및 사용자 정보 공유가 필수적임

3-2. 소프트웨어 기능 고려
- 시스템 구축 시 OS 선택이 중요함
- 리눅스 기반 시스템은 하드웨어 및 소프트웨어에서 장점이 있음
- 윈도우 기반은 유지 및 관리 비용 측면에서 강점이 있음
- 유닉스 기반은 신뢰도가 높고, 32비트 4기가 메모리까지 액세스 가능함
- (중요) 시스템 성능과 사용 환경에 따라 적합한 OS 선택이 필요함

3-3. 데이터베이스 관리 시스템
- 데이터베이스 관리 시스템은 사용자 데이터를 저장하고 분석하기 위한 소프트웨어임
- 오라클, DB Q, IBM, 마이크로소프트, SQL 서버 등 다양한 시스템이 있음
- 시스템 선택 시 비용, 용도, 가용성 등을 고려해야 함
- (중요) 대규모 데이터 처리 및 안정적인 서비스 제공을 위해 오라클과 같은 시스템을 사용할 수 있음
- 동적 웹사이트를 구현하기 위한 우수한 라이브러리도 있음

4. 시스템 요구사항 분석

4-1. 요구사항 분석의 개요
- 소프트웨어 공학 기술의 요구사항 분석을 위해 요구공학이 중요함
- 요구공학은 요구사항을 정의하고 문서화, 관리하는 프로세스임
- 요구공학의 목적은 요구사항의 지속적인 중요성과 체계적 관리의 확보임
- 요구사항 분석의 과정은 요구사항 도출, 분석, 명세화, 확인 순으로 진행됨
- (중요) 요구사항 도출은 이해관계자 식별, 효율적 의사소통, 소프트웨어 범위 파악이 중요함

4-2. 요구사항 수집 및 분석
- 요구사항 수집은 기업, 행정, 이해관계자 등 다양한 이해관계자와의 협의를 통해 이루어짐
- 요구사항 분석은 수집된 요구사항을 분류, 모델링, 기술 구조 설계, 요구사항 할당 등을 포함함
- 시스템 요구사항을 정제하고 소프트웨어 요구사항을 도출함
- 소프트웨어 요구사항에 대한 체계적인 검토와 평가가 필요함
- 시스템 정의서, 시스템 요구사항, 소프트웨어 요구사항 정의서를 포함한 문서를 작성함

4-3. 요구사항 확인 및 평가
- 요구사항 확인은 시스템에 존재하는 다양한 요소를 검토하고 평가하는 과정임
- 시스템의 기능적, 안전성, 법적 요구 사항 등을 고려하여 요구사항을 확인함
- 소프트웨어 요구사항의 신뢰성과 타당성을 평가하고, 개발팀과 고객 사이의 의사소통을 강화함
- 시스템 요구사항의 개선 가능성과 새로운 요구사항을 도출함
- (중요) 요구사항을 개선하거나 신규 요구사항을 도출하기 위해서는 적절한 평가가 필요함

5. 소프트웨어 요구사항 분석 기법

5-1. 요구사항 분석의 필요성 및 종류
- 요구사항 분석은 소프트웨어 개발의 핵심 단계로 요구사항의 의미와 중요성을 이해함
- 요구사항 분석 기법은 요구사항의 정확성 검증, 이해관계자 검토, 문제 파악 등 다양한 분석 기법을 포함함
- 분석 기법에는 요구사항 분류, 개념 모델링, 요구사항 할당, 협상, 정형 분석 등이 있음
- 요구사항 분류 기법은 기능적, 비기능적 요구사항을 구분하며, 이는 제품 및 프로세스에 영향을 미침
- (중요) 개념 모델링 기법은 문제 상황에 대한 모델링을 통해 해결책을 설명하고 이해를 돕는 방법임

5-2. 요구사항 할당 및 협상
- 요구사항 할당은 요구사항을 만족시키기 위한 시스템적 필요 사항을 식별함
- 요구사항 협상은 서로 상충되는 요구사항을 조정하고, 협상점을 찾는 과정임
- (중요) 트레이오프 지점에서 합의를 수행하며, 중요한 요구사항을 필터링함
- 협상 과정에서는 요구사항 별 우선순위 부여를 통해 중요성과 효율성을 고려함

5-3. 정량 분석 및 요구사항 확인 기법
- 정량 분석은 요구사항을 명확하게 표현하여 오해를 최소화하는 방법임
- 요구사항 확인 기법은 고객 중심의 프로젝트에서 요구사항을 정확히 검토하는 데 사용됨
- 사용자 인터페이스 요구 사항의 경우, 템플러 예제를 사용하여 개괄적으로 검토함
- (중요) 프로토 타이핑은 새로운 요구 사항 구출에 필요한 수단으로, 분석자의 가정을 파악하고 피드백을 받을 수 있음

6. 요구사항 분석

6-1. 요구사항 도출과 분석
- 요구사항 도출은 시스템의 요구 사항을 정의하는 과정임
- 요구사항 분석 기법에는 요구사항 할당, 정의, 확인, 분류, 모델링 등이 있음
- 요구사항을 만족시키기 위한 아키텍처 구조 요소를 식별하는 요구사항 할당이 중요함
- (중요) 요구 사항을 만족시키기 위한 아키텍처 구조 요소를 식별하는 요구사항 할당은 요구사항 분석 기법의 핵심 중 하나임
- 요구 사항 분류 기법은 요구 사항을 체계적으로 분류하여 우선순위를 정하는 방법임

6-2. 요구사항 모델링과 검증
- 요구 사항을 만족시키기 위한 모델을 생성하고, 그 성능을 검증하는 과정이 필요함
- 프로토타입 생성은 사용자로부터 피드백을 받아 수정 사항을 찾는 과정임
- 프로토타입 생성 비용이 발생할 수 있고, 사용자의 관심이 모델 디자인이나 품질 문제로 이어질 수 있음
- 객체 모델은 객체 사이의 의사소통 경로를 검증하기 위해 정적 분석을 수행함
- 정적 분석은 상세 설계나 코딩을 진행하면서 소스 코드와 모델의 결함을 찾아내는 과정임

6-3. 요구사항 검증과 시스템화 타당성 분석
- 요구사항 확인은 요구 사항을 만족시키는지 확인하는 과정으로, 계획 수립이 필요함
- 요구 사항 정의에 대한 퀴즈를 통해 프로토타입의 장점과 단점을 파악할 수 있음
- 요구 사항의 기술적 타당성 분석은 기술적 적합성, 실현 가능성, 성능 및 용량 산정, 시스템 상호 운용성 등을 포함함
- 기술적 위험 분석은 적용 기술의 복잡성, 검증 여부, 의존성 등 위험 가능성을 파악하는 과정임
- 시스템화 타당성 분석은 요구 사항을 만족시키기 위한 시스템 구축의 타당성을 검토하는 과정임

7. 소프트웨어 설계와 요구사항 정의

7-1. 요구사항 정의와 개발 프로세스
- 요구사항 정의는 고객의 요구사항을 체계적으로 정립하는 과정임
- 요구사항 개발 프로세스는 요구사항 도출, 분석, 명세 확인의 단계로 이루어짐
- (중요) 요구사항 시스템화 타당성 분석에서는 요구사항의 기술적 타당성을 검토함
- 성능 및 용량 산정의 적정성, 시스템 간 상호 응용성, 시장 성취도 및 트렌드 부합성을 고려함

7-2. 소프트웨어 설계 및 분석 모델
- 소프트웨어 공학 기술의 분석 도출 기법 활용이 필요함
- 유스케이스 다이어그램을 통해 시스템 동작에 대한 시나리오 도출 가능함
- (중요) 클러스 다이어그램을 통해 소프트웨어의 정적 요소와 그간의 관계 파악 가능함
- 상호 운영에서 동일 기종 또는 이 기종의 정보 시스템 간의 원활한 통신이 가능함

7-3. 분석 모델 검증과 분석 모델의 시스템화 타당성
- 분석 모델 검증은 유스케이스 모델 검증, 개념 수준 분석 및 클래스 검증으로 이루어짐
- 유스케이스 모델 검증에서는 도출된 유즈 케이스가 논리적으로 연결되어 있는지 확인함
- (중요) 개념 수준 분석 클래스 검증에서는 도출된 클래스의 역할과 관계 메시지의 흐름 등을 확인함
- 분석 클래스 검증에서는 하나의 유즈 케이스를 실현하기 위해 3개 이상의 클래스가 필요함

8. 시스템 클래스 분석

8-1. 경계, 엔터티, 제어 클래스
- 로그인 화면에서 아이디와 비밀번호 입력하는 구조의 예시임
- 아이디와 비밀번호를 입력하고 로그인 요청을 하면, 가입된 회원이 아니면 로그인 요청을 하지 말아야 함
- (중요) 경계 클래스는 화면, 엔터티 클래스는 데이터베이스 테이블, 제어 클래스는 로직 제어 담당 클래스임
- 경계, 엔터티, 제어 클래스의 도출 여부와 상세 정도 확인 필요함
- 유스케이스 명세서를 바탕으로 각 클래스와의 관계를 정의해야 함

8-2. 속성과 연산
- 속성은 데이터베이스에 저장되는 변수임
- 연산은 변수의 동작을 의미하며, 제어 클래스는 동작 중심적임
- 콘텐츠 클래스는 데이터 저장 중심이고, 연산의 매개변수명과 타입이 정의되어야 함
- 속성의 길이가 입력값보다 적게 설정되면 오류가 발생할 수 있음
- 속성과 연산의 일관성을 확인해야 함

8-3. 분석 클래스 다이어그램
- 분석 클래스 다이어그램을 통해 각 클래스의 역할과 기능을 이해할 수 있음
- 분석 클래스명, 스테레오타입 바운더리(화면), 컨트롤 클래스(로그인 제어), 엔터티 클래스(데이터 저장), 제어 클래스(로직 제어)로 구성됨
- 제어 클래스의 연산에 대응하는 엔터티 클래스가 있는지 확인해야 함
- 속성과 연산의 상세와 정도 확인으로 클래스 간 관계를 정의해야 함

9. 소프트웨어 설계의 분석 모델링

9-1. 분석 모델링 검증 절차
- 유즈 케이스 모델을 기반으로 분석 모델을 검증함
- 분석 모델링 검증 절차는 유즈 케이스 모델 개념 수준, 분석 클래스 검증 순서로 진행됨
- 분석 모델 클래스 도출에 필요한 분수 클래스 도출 확인이 포함됨
- 유즈 케이스 실행에 필요한 분수 클래스의 도출 여부 및 상세 상황 확인이 필요함
- 요구 기능 구현을 위해 필요한 유즈 케이스가 도출되었는지 확인함

9-2. 분석 모델 시스템화 타당성 검토
- 유스 케이스 모델의 개별 유스 케이스에 대한 분석 모델을 작성한 후 시스템 개발에 영향을 미치는지 검토함
- 분석 모델을 시스템화하여 시스템 간 상호 정보 및 서비스 교환 가능성 검토함
- 시스템 간 상호 운용성 분석을 통해 시스템 간 정보 교환 가능성과 서비스 제공 가능성 확인함
- 시장 성숙도 및 트렌드 부합성 분석을 통해 분석 모델이 과거 문제 해결에 효과적이었는지 확인함
- (중요) 시스템의 기술 구조, 프레임워크, 하드웨어, 소프트웨어 부합성을 검토하여 기술적 위험을 고려함

9-3. 소프트웨어 설계 요구 사항 확인
- 소프트웨어 설계 요구 사항을 확인하기 위해 분석 모델의 시스템화 타당성 검토 단계를 수행함
- 유즈 케이스 모델과 분석 클래스를 결합하여 시스템을 개발하고 필요한 자원을 식별함
- 불필요한 메모리 자원 요구와 처리 속도 저하를 방지하기 위해 필요한 속성만 포함시킴
- 시스템 간 상호 운용성 분석을 통해 서비스 교환 가능성과 정보 교환 가능성을 검토함
- 시장 성숙도 및 트렌드 부합성 분석을 통해 중요하고 빈번하게 사용되는 클래스의 프로토타입을 적용함

00:03
소프트웨어 설계의 첫 번째 챕터로 요구사항 확인 세부 ncs 능력 단위 요소 3가지가 있는데요. 그 3가지 중에 첫 번째 현행 시스템 분석에 대해 살펴보도록 하겠습니다. 현행 시스템 분석에 대한 학습 목표입니다. 개발하고자 하는 응용 소프트웨어에 대한 이해를 높이기 위해 현행 시스템의 적용 현황을 파악함으로써 개발 범위와 향후 개발될 시스템으로서의 이용 방향성을 분석할 수 있다. 두 번째 개발하고자 하는 응용 소프트웨어와 관련되어진 운영 제재와 데이터베이스 관리 시스템 그리고 미들웨어 등의 요구 사항을 식별할 수 있다. 그리고 현행 시스템을 분석하여 개발하고자 하는 응용 소프트웨어가 이후에 적용되어질 목표 시스템을 명확하고 구체적으로 기술할 수 있다.

01:03
이 세 가지 학습 목표를 갖고 내용 살펴보도록 하겠습니다. 세부 학습 내용은 똑같은데요. 현행 시스템 파악과 개발 기술 환경에 대한 정의 내용입니다. 먼저 용어 자세는 해당 이 챕터를 접할 때 네 꼭 알아야 될 어떤 용어적인 부분을 몇 가지만 좀 미리 추출해서 살펴보도록 하겠는데 하드웨어 구성도 하드웨어 구성도라는 부분은 서버의 주요 사양과 수량 이중화 이중화라고 하는 부분을 두 가지로 했다는 거죠. 저장적인 부분 자체를 하나 그리고 두 번째 백업적인 부분으로 이중화되어 있는지 여부를 명시하는 것을 하드웨어 구성도라고 하고요. 오픈소스 소스 코드를 공개해서 누구나 비용 없이 특별한 제한 없이 그 소스를 그대로 사용할 수 있는 소스 소프트웨어가 오픈 소스가 되겠습니다.

02:00
자 현행 시스템 파악에 있어서요 먼저 현행 시스템 파악에 대한 정의 내용입니다. 현행 시스템 파악이란 무엇인가 현행 시스템 파악은 하위 시스템 파악은 하위 시스템 구성 요소와 제공 기능 그리고 연계 요소를 파악하는 것을 뜻합니다. 어떠한 기술이 적용되어 있는지 적용 기술 요소와 그리고 소프트웨어 웨어 하드웨어 네트워크 구성 요소를 파악하는 것을 뜻합니다. 현행 시스템을 파악하는 주된 목적은요, 향후에 개발하고자 하는 개발 시스템의 개발 범위를 어느 범위까지를 개발 범위로 잡아야 되는가 그리고 어떻게 진행해 가야 되는지 이행 방향 설정에 도움을 얻을 수 있습니다. 현행 시스템 파악 절차입니다.

02:46
첫 번째 단계로서는 구성 기능 인터페이스 파악 세부 내용으로서는 시스템 구성 현황 파악과 시스템 기능 파악 그리고 시스템 인터페이스 현황을 파악을 합니다. 두 번째 단계인 아키텍처 및 소프트웨어 구성을 파악을 하는데요. 세부적으로는 아키텍처는 기본적인 틀입니다. 시스템 아키텍처 소프트웨어 아키텍처 이렇게 세부적으로 분류할 수 있는데, 아키텍처를 파악하고요. 그리고 어떠한 소프트웨어로 구성이 되어 있는지 소프트웨어 구성을 파악을 합니다. 세 번째 단계로서는 하드웨어 및 네트워크 구성에 대한 파악으로서 시스템 하류 현황을 파악하고 그리고 네트워크 구성을 파악합니다. 자 단계별 세부 내용 살펴보도록 하겠는데 첫 번째 단계 요소 구성 기능 및 케이스 파악입니다. 다시 하위로 대상이 현행 시스템 구성 현황 그리고 기능 현황 그리고 인터페이스 현황을 파악할 건데요.

03:44
세부 내용을 살펴보면 현행 시스템 구성 현황이라고 하는 부분은 조직의 주요 업무를 처리하는 기관적인 업무 가장 중요하고 중요 업무가 되겠죠. 기관 업무와 이를 지원하는 서포트 하는 업무로 구분하여 파악할 필요성이 있고 각 업무에 속하는 단위 업무 정보 시스템의 명칭과 주요 기능을 명시해야 합니다. 그리고 세 번째 조직 내에 존재하는 모든 정보 시스템 현황에 대한 파악이 필요합니다. 기본적인 파악이 아니라 전체적인 부분을 파악을 해야 됩니다. 다음 기능현황인데요.

04:23
기능현황은 정보 시스템 내에 하위 단위 업무 시스템별 현재 제공되고 있는 기능이 어떤 것들인지를 파악해서 기출하고 그리고 기능들을 주요 기능과 하부 기능으로 구분해서 결정적으로 표시하는 것이 좀 더 일목요연하게 파악할 수 있고 또 표시가 될 겁니다. 그리고 인터페이스 현황입니다. 인터페이스 현황은 단위 업무 시스템과 주고받는 데이터의 종류는 어떤 건가 그리고 데이터의 형식을 뭐고 통신을 할 때 지켜야 되는 프로토콜 통신 규약이라고 이야기를 합니다. 프로토콜들을 명시하고요. 포맷과 통신 규약 종류 그리고 연계 유형 약어들이 많이 좀 나오는데 ai라고 하는 부분 자체는 엔터프라이저 어플리케이션 인터페이스 약어입니다.

05:13
애플리케이션 응용 프로그램에 대한 인테그러레이션 통합 기업 응용 프로그램 통합 f ep라고 하는 부분은 프론트 앤드 프로세서 약어이거든요. 전이 단말기 이렇게 전이 처리기 이렇게 이야기가 되어지는데 어쨌든 어떤 파트에 해당되는 용언가 전개 유형이다. 각각 부분 자체를 이어준다는 말입니다. 뒷부분에 저희가 연계와 관련해서 통합 구현이라든지. 이러한 부분에 대해서 구체적으로 살펴볼 겁니다. 이상 현행 시스템 파악 절차 두 번째 단계로서 아키텍처 및 소프트웨어 구성 파악입니다. 현행 시스템 아키텍처 구성도를 저희가 다이어그램 그림으로요 그림으로 저희가 그리도록 할 건데 기관 업무 수행 기술 요소를 최상위 수준에서 그림으로 표현한 게 시스템 아키텍처 구성도가 되겠습니다.

06:10
그에 이제 정부 기관의 예라든지 이런 부분들 실제 그림을 보면 이 시스템 아키텍처 어떻게 표현하는지 이해가 되니까. 뒤에서 상세하게 설명드리도록 하겠고요. 단위 업무 시스템별 아키텍처가 상이하다 그 경우에는 어떤 걸 기준으로 하느냐 가장 핵심이 되는 기관 업무를 기준으로 작성을 한다. 그리고 소프트웨어 구성도를 작성하는데 소프트웨어 구성도는 단위 업무 시스템을 처리하는 데 있어서 설치가 되어진 소프트웨어의 제품명은 뭐고 어떤 용도이고 그리고 라이센스 적용 방식은 또 라이센스 수는 몇 카페를 우리가 구매를 했는지 이러한 것들을 명시를 하고요. 시스템 구축을 할 때 인프라 구축에서 하루웨어 비용뿐만 아니라 소프트웨어 비용이 또 차지하는 비중도가 적지 않습니다.

06:58
그렇기 때문에 상용 소프트웨어 경우는 구매를 한 소프트웨어들은 라이센스 적용 방식 기준인 사이트 단위 또는 서브 단위 또는 프로세스 코어 등 이러한 사용자 수와 같은 보유한 라이센스 수량 파악을 구체적으로 할 필요성이 있습니다. 네 아키텍처 및 소프트웨어 구성 파악에서 예시로 제시되어져 있는 부분이 전자 정보 모바일 공통 컴포넌트 적용한 아키텍처의 예시입니다. 보면은 프레젠테이션 타이어 이렇게 돼 있죠. 보여지는 화면적인 부분 그리고 프랜테이션 레이어 비즈니스 레이어 인티브레이션 레이어 또는 데이터 억세스 레이어 그리고 해당 여기 보여지는 부분에 대한 해당 구성적인 부분 시스템 아키텍처적인 부분입니다. 파운데이션 레이어는 이러한 것들이 있어요. 전자 정보 프레임워크 3.0 버전에서 제시한 예제이고요.

07:57
그리고 행정안전부의 국가 지도 db의 소프트웨어 구성도의 예시입니다. 보면요 시도에서는 lmis 서버 1에서부터 16이 있고 해당 그 서버는 다시 tcprp 유닉스 dbms 미들웨어로 구성돼 있다. 이렇게 보시면 될 것 같고, 통합 센터에서는 와스 서버가 네 was라고 하는 용어적인 부분은 뒷단에 저희 미디어 파트에서 저희가 다루도록 할 건데 웹 어플리케이션 서버를 뜻합니다. 해당 구성적인 부분 자체는 tcp ip 유닉스 이렇게 돼 있는데요. 네 이 부분 자체는 보면 이제 네트워크 구성 구조적인 측면에서 뒤에서도 저희가 좀 언급할 부분이 있습니다. 리눅스다 유닉스다라고 하는 부분은 서버 os가 되겠고요. dbms라고 하는 부분은 데이터베이스 매니지먼트 시스템 데이터베이스를 관리하는 시스템을 이야기를 합니다.

08:55
관리자 서버 db 서버 gi 서버는 지리적 정보 시스템 서버가 되겠죠. 개요적인 측면에서 소프트웨어 구성도는 이렇게 나타낸다 이렇게 이해하시면 될 것 같고, 다음 현행 시스템 파악의 3단계는 하류오 및 네트워크 구성에 대한 파악입니다. 하드웨어 구성도는 포함되어져야 될 내용이 서버의 주요 사양 수량 이중화 등에 대한 적용 여부 등이 표시가 되어지고 시스템 하드웨어의 현황 및 작성의 예시는 다음과 같이 구분은 기관 업무가 지원 업무가 그리고 시스템명은 어떤 업무를 단행한 수행하는 시스템이야 그리고 서버 용도는 ap 서버다 데이터베이스 서버다 이렇게 돼 있고 제품명은 어떤 제품명을 사용한다.

09:44
이 하드웨어 사양으로서 cpu 중앙 처리 네 시스템 중앙 처리 플라스틱 중앙 처리 시스템에 대한 종류는 코코아이고 메모리는 몇 기가구 하드디스크 용량은 얼마다 이렇게 수량은 몇 개고 이중화 여부를 포함한 도평태로 해서 정리를 해서 나타냅니다. 네 그리고 하드웨어 구성도 착상할 때 고려 사항인데요. 기관 업무의 서비스 기간 장애 대응 정책에 따라서 이중화가 필요하냐? 그 여부를 반드시 포함을 시켜야 되고 현행 시스템에서 이중화가 적용되어졌다 라고 하게 되면 향후 목표 시스템에서도 이중화가 적용될 필요성이 높겠죠. 그러한 부분들은 인프라 기술 구축 기술에 대한 난이도 및 비용 전가 가능성이 존재한다라고도 미리 파악해 볼 수 있겠습니다. 그리고 네트워크 구성도인데요.

10:39
네트워크 구성도는 업무 처리 시스템의 네트워크 구성 현황을 표현한 것을 이야기를 하고요. 고려 사항으로서는 네트워크 구성도의 작성을 통해서 서버가 어디에 위치해 있고 그리고 서버 간에는 어떠한 네트워크 연결 방식으로 연결되어 있는가라는 부분을 파악할 필요성이 있습니다. 그래서 조직 내의 서버들의 물리적 위치 관계 파악과 조직 내에 보안 취약성 분석 및 대응 그리고 네트워크 장애 발생 추적 및 대응 등 다양한 용도로 네트워크 정도로 활용될 수 있겠습니다. 한국전기안전공사의 시스템 구성도의 예시입니다. 사용자가요 네 해당 왓스가 웹 어플 켜진 서버구요. db가 데이터베이스입니다. 해당 제품은 이러한 것들로 구성돼 있다.

11:29
왓슨은 선타이어 880 모델로 돼 있고 cpu는 4개야 해당 db는 네 cpu가 8개야 이렇게 표시되어 있다라고 보시면 될 것 같고, 트랜잭션 허름도와 성능 데이터의 허름도 빨간색 파란색으로 이렇게 구분돼 있습니다. 국립어학원의 네트워크 구성도의 예시입니다. 해당 인터넷을 이용해서요. 내부망으로 들어갔을 때 스위치 연결돼 있고 검색 서버 그리고 방화벽이 구성돼 있고 네 해당 웹 서버 그리고 저장되어지는 데이터베이스 서버 이러한 것들 전체적인 망 구성입니다. 네트워크 망 구성 관련되어진 네트워크 장비들은 어떠한 것들이 연결되어 있는가라는 부분에 물리적인 어떠한 네트워크 정도를 파악해 볼 수 있겠습니다.

12:24
현행 시스템 파악과 관련되어진 퀴즈 간단하게 점검해 보도록 하겠는데요. 현행 시스템 파악할 때 작성하는 주요 시스템의 구성도로 특정을 하지 않은 것은 무엇일까? 정보 처리 기사는 사지선답형입니다. 객관식 4개 중에 하나 고르는 문제로 구성돼 있습니다. 자 작성 주요 시스템 구성도 적절하지 않은 겁니다. 소프트웨어 구성도 하드웨어 구성도 네트워크 구성도 저희가 각각 살펴봤고요. 인터페이스 구성도는 저희가 살펴보지 않았습니다. 해당 틀린 것은 인터페이스 구성도고 나머지 이 세 개는 현행 시스템 파악 시 파악하는 주요 시스템 구성도에 해당되었습니다. 두 번째 파트입니다. 네 개발 기술 환경 정의입니다.

13:10
세부 내용으로서 개발 기술 환경의 정의 요소 살펴보면 개발 기술 환경 정의할 때 고려 사항으로서는요 네 가지가 있는데, 첫 번째 운영 체제 두 번째 dbms는 데이터베이스 매니지먼트 시스템 데이터베이스 관리 시스템 그리고 미디어웨어 그리고 오픈 소스 단계별로 살펴보도록 하겠습니다. 먼저 운영체제 주요 특징 및 고려 사항인데요. 운영 체제는 무엇인가 운영 체제는 오퍼레이팅 시스템 즉 os 해당 컴퓨터가 어떠한 운영체제 설치돼 있어서 어떤 os야 윈도야 리눅스야 유닉스야 하드웨어와 이 운영체제의 정의 역할적인 부분을 보면 하드웨어 소프트웨어 리소스를 관리하고 컴퓨터 프로그램을 위한 공통 서비스를 제공하는 소프트웨어를 뜻한다.

14:02
소프트웨어 종류는 다시 크게 보면 시스템 소프트웨어 시스템 소프트웨어가 있고 그다음에 일반적인 어떤 작업을 컴퓨터를 이용해 가지고 보다 쉽게 작업할 수 있도록 도와주는 응용 소프트웨어가 있죠. 그중에서 운영 체제는 시스템 소프트웨어에 해당되는 대표입니다. 자 운영체제의 특징 및 종류입니다. 주요 운영체제는 제조사 대표적인 마이크로소프트웨어의 윈도우즈 운영체제가 있고 그리고 유닉스 리눅스 여기까지가 pc 컴퓨터 운영체제이고요. 그리고 근래에는 스마트폰도 많이 보편화돼 있잖아요. 스마트폰도 운영체제별로 종류를 나눌 수 있는데, ios 운영체제 애플에서 만든 네 애플에서 만든 운영체제 아이폰에 적재돼 있죠. 그리고 안드로이드 구글에서 무료로 배포하면서 전 세계적인 점유율은 안드로이드가 지금 60% 이상 점유를 하고 있습니다. 유료 배포를 하고 있죠.

15:02
유료가 아니라 시스템 용도에 따라서 최적화되어진 운영체제 선택해서 적용하면 되겠는데 운영체제의 종류 및 특징을 다시 세부적으로 좀 더 살펴보게 되면 윈도우 운영 체제는 마이크로소프트를 만들었고요. 전 세계 7억 이상의 사용자를 보유하고 있습니다. 네 그리고 라이센스 비용은 유료죠 유료입니다. 구매해야 되고 주요 용도는 중소 규모의 서버나 개인용 pc 등에 사용되어진다 유닉스 유닉스는 ibm hp sum 솔라리스나 이러한 종류들에 대해서 나눠집니다. 비용리 라이센스는 유료 다양한 라이센스 정책이 사용되어지고 대용량 처리 큰 어떤 이제 대규모 서버인 경우에는 주로 이제 안정성적인 측면에서는 유닉스에 대한 선호도가 높습니다. 그래서 안정성이 요구되는 서버 용도로 사용되어지고요.

16:00
리눅스 리눅스는 주 장점이 무료죠 네 무료 중대규모의 중소기업군에서는 리눅스에 대한 선호도가 높습니다. 그리고 ios 애플에서 만들었고요. 안드로이드 구글에서 만들었습니다. 스마트폰 및 해보드 피씨 필요한 용도로 사용되어진다 정보 시스템 구축할 때 os 운영 체제 고려 사항으로서요 5가지가 있는데, 신뢰도 성능 기술 지원 주변 기기 구축 비용이 있습니다. 신뢰도는요 네 장기화 시스템 운영을 할 때 운영체제 고유의 어떤 장애 발생 가능성이 높으냐 낮으냐 장애 발생이 낮아야겠죠.

16:41
네 그리고 특정 응용 프로그램에 대한 메모리 누수로 인한 성능 저하나 재기동 이러한 부분들이 혹시 생겨지지 않는가 운영체제 보완적인 측면에 대한 허점이 있지 않은가 운영체제 버그로 인한 팬츠 설치 등에 따른 제 기동이 있으면 신뢰도 낮은 운영체제일 겁니다. 그리고 성능입니다. 대규모의 경제 사용 요청 처리를 어느 정도 할 수 있느냐 대규모 또는 대량의 파일 처리 작업이 가능한가 그리고 지원 가능한 메모리가 32비트 용인가 64비트 용인가 자 윈도우 운영 체제용 어떤 응용 프로그램을 다운로드 받을 때 인터넷 상에서 보면은 버전별 맞는 걸 다운받으세요. 32비트인가요? 64비트인가요? 이렇게 묻죠 32비트인 경우에는 랩 메모리 4gb 이상을 지원을 못합니다. 근데 64비트 운영 체제는 4기가 이상 랜 메모리를 지원한다.

17:34
이런 특징도 있고 기술 지원적인 부분은 공급 벤더 공급자 업체들이 안정적인 기술 지원이 가능한가 그리고 다수의 사용자들에 대한 정보 공유와 오픈 소스 여부를 측정할 필요성이 있겠고 주변 기기는 설치 가능한 하드웨어 그리고 다수의 주변 기기 지원이 가능한지 구축 비용은요, 지원 가능한 하드웨어의 비용 설치할 응용 프로그램 라이싱 정책 및 비용 그리고 유지 관리 비용 전체 총 소요 비용을 따져볼 필요 등이 있겠다. 다음 운영 체제에 대한 주요 특징 및 고려 사항으로서 정보 시스템 구축할 때 os 고려 사항을 다시 한번 하나의 다이어그램 형태로 분류한 부분인데요. 구축 비용에서는 리눅스 기반 시스템이 하류웨어 및 소프트웨어에서 가장 장점은 소비 비용이 가장 적다라는 부분이고요.

18:24
그리고 윈도우 기반인 유지 및 관리 비용 측면에서의 강점이 있고 유닉스 기반은 반 정도 측면에서는요 가장 신뢰도가 높습니다. 그리고 성능적인 측면으로선 32비트 4기가 메모리까지 액세스 가능하고 32비트 64비트 오닉스드는 4기 이상의 메모리 액세스가 가능하다라는 부분으로 성능적인 측면에서 고려할 수 있겠다. 다음 개발 기술 환경 정리 세 번째 데이터베이스 매니지먼트 시스템 dbms에 대한 주요 기능 및 고려 사항에 대해 살펴보도록 하겠습니다. 데이터베이스 관리 시스템 dbms는 사용자 다른 애플리케이션 데이터베이스와 상호작용하여 데이터를 저장하고 분석하기 위한 컴퓨터 소프트웨어를 뜻합니다.

19:20
주 기능으로서는요 데이터베이스를 생성하거나 조회하거나 변경할 수가 있겠습니다. 데이터베이스 매니지먼트 시스템의 종류로서는요 오라클이나 제품명 오라클사에서 만든 오라클 그리고 dbq나 ibm에서 만든 데이터베이스 매니지먼트 시스템 마이크로소프트를 만든 sql 서버나 그리고 isqm 몽고 db 등이 있습니다. 각각의 특장점에 따라서 비용적인 측면에 대한 유료다 무료다 그리고 사용 용도적인 부분을 대규모에 적합하다 중소 규모에 적합하다 이러한 것들을 고려해서 선택할 수가 있겠는데요. 대규모 데이터의 안정적 처리를 필요로 하는 데이터베이스 관리 시스템으로 예로서는 오라클 은행권의 전산실에서는 주로 오라클을 많이 씁니다. 그리고 ibm의 db2 등이 있겠고 오픈 소스로 비용적인 부분에 대한 단점을 갖고 있는 무료로 이용할 수 있는 isql이라든지. 몽고 db 등을 비용적인 측면에서는 채택을 많이 합니다.

20:19
세부적으로 데이터베이스 관리 시스템의 종류 및 특징 정리한 표인데요. 오라클 ibm의 db2 쭉 참고해 보시면 될 것 같고요. 해당 네 주요 용도적인 부분들 대규모 대규모에 적합하다 중소 규모에 적합하다 해서 분류해 놓은 거니까 오라클은 주로 쌍용이고 오라클 db2 마이크로 소프트웨어 sql 서버는 쌍용 마이에스큐엘은 무료 또는 상용으로 돼 있어요. 마이에스큐엘을 오라클이 인수를 했습니다. 인수를 해서 우선은 무료로 해줄게 라고 되어있는데, 네 어쨌든 이제 유료 버전들도 나올 예정이기는 하고요. 그다음에 에스큘라이트 저작권 완료되어서 퍼블릭 그룹을 이용할 수 있다. 이렇게 돼 있고 몽고 db 그다음에 bsd 네 슬라이 어 레디스라고 해서요.

21:12
얘는 오픈 소스 및 메모리 키 값 뭐 데이터베이스 이러한 용도로 사용이 되어진다 그래서 일반적으로 대기업 같은 경우에는 오라클 많이 쓰구요. 네 그다음 중소기업부는 마이너스크를 많이 쓰는 편입니다. 공급 시스템 구축할 때 데이터베이스의 고려 사항입니다. 가용성 성능 기술 지원 상호 호환성 구축 비용 따져볼 필요성이 있겠고 가용성이라고 하는 분은 장기간 시스템을 운영할 때 장애 발생의 가능성이 낮아야겠죠. dbms의 버그 등으로 인한 재귀동이나 백업 등 복구의 편의성 데이터베이스의 이중화 및 복제 지원이 가용성에 해당되어지고 성능적인 측면 자체는 대규모 데이터 처리 성능이 가능한가 대량의 거래 처리 그리고 다양한 튜닝 옵션 지원 비용 기반의 최적화 및 설정의 최소화가 성능에 해당되어지고요.

22:02
기술 재원은 공급하는 밴드들이 안정적으로 이 기술을 계속적으로 지원해 줄 수 있는가라는 부분을 따져볼 필요성이 있겠고 상호 호환성은 설치 가능한 운영 체제 종류 해당 이제 일례로 마이크로소프트의 스크린 서버는 마이크로소프트 운영체제를 베이스로 해서 지원을 합니다. 리눅스나 유닉스에는 동작이 안 돼요. 그렇기 때문에 해당 설치 가능한 운영체제 종류 다양한 운영 체제에서 지원 가능한지라는 것을 상호 호환성적인 측면에서 따져볼 필요성이 있고 구축 비용으로서는 무료냐 또는 유료냐 유지 관리 어떤 비용적인 부분에 대한 총 소비 비용을 체크해 볼 필요성이 있겠습니다. 자 네 번째 미들웨어 주요 특성 및 고려 사항인데요. 미디오웨어는 뭔지 미들웨어라고 하는 부분은 웨어가 장치잖아요.

23:00
소프트웨어 부드러운 장치 눈으로 만질 수 없는 하드웨어 장치 딱딱한 장치 눈으로 만질 수 있는 장치 미드웨어는 중간이라고 볼 수 있겠는데 운영 체제와 소프트웨어 애플리케이션 사이에 위치하는 미드웨어는 소프트웨어 애플리케이션에서 소프트웨어 애플리케이션에게 운영 체제가 제공하는 서비스를 추가 및 확장해서 제공하는 컴퓨터 소프트웨어입니다. 하드웨어가 아니라 소프트웨어입니다. 주요 사례로서는요 저희가 미디어의 사례로서는 웹 애플리케이션 서버 w as 웹 애플리케이션 서버를 주로 다루도록 할 겁니다.

23:40
ws는 뭔데 동적인 웹사이트 반대는 정적인 웹사이트죠 동적이라고 하는 부분 자체는 사용자와 서버가 상호 작용할 수 있는 정적인 웹사이트는 html로 단순하게 내용만 보여주고 끝이고 동적인 웹사이트라고 하는 부분은 홈페이지 방문한 방문자가 게시판에 뭔가 글을 남긴다든지 이렇게 해서 서버 단으로 전달해서 상호 이제 다이내믹하게 운영되어지는 게 동적 웹사이트입니다. 동적인 웹사이트를 구현하는 언어로서는 php나 jsp나 asp나 이러한 서버 사이드 스크립트 언어들이 있고요. 동적인 웹사이트 웹 애플리케이션 웹 서비스 개발을 지원하기 위해 설계된 소프트웨어를 뜻한다. 데이터에 대한 접근과 세션 관리는 접속하고 난 다음에 일정 시간 동안만 접속을 유지하고 일정 시간이 경과되면 끊어요.

24:37
로그인하고 난 다음에 무한대로 로그인을 유지하게 되면 보완적인 측면이나 이런 것들이 문제가 생길 수도 있겠죠. 세션 관리나 트랜잭션 처리 관리 이러한 것들을 위한 라이브러리를 제공을 합니다. 웹 애플리케이션 서버의 종류 및 특징 제시되어지는 교 참고해 보시면 종류 글래스 피시 제이보스 제티 제우스 레진 웹로직 웹스피어 이러한 부분 부분들이 있고 해당 제공되어지는 밴더의 종류 그리고 비용 및 라이센스적인 측면 주요 용도적인 부분으로 정리를 해 놓았는데 대량의 안정적인 어떤 서비스를 제공하는 경우에는 오라클의 웹 로직이나 ibm의 웹 스페어 많이 사용하는 편이고요. 그다음에 저희 국내 제품인데 제우스 같은 경우에는 티맥 소프트웨어라고 국내인데 대량이 안정적인 거래처를 요구하는 적시에 기술 지원이 필요한 경우에도 추천되어집니다.

25:38
정보 시스템 구축을 할 때 왓스에 대한 고려 사항입니다. 가용성 성능 기술 지원 구축 비용 4가지 검토할 필요 중이 있겠다. 가용성은 장애 없이 잘 이용할 수 있느냐 이 측면이고요. 장기간 시스템 운영할 때 장애 발생에 대한 가능성 안정적인 트렌즈 정책 처리가 가능한가 기준화 지원 여부 성능적인 측면은 대규모의 거리 처리가 가능한가 그리고 기술 지원적인 측면에서 안정된 기술 지원을 공급 밴드로부터 받을 수 있는가 그리고 구축 비용 비용에 대한 부분을 따질 필요가 있겠다. 자 개발환경 정의 다섯 번째 오픈 소스 사용에 대한 고려사항입니다. 오픈소스라고 하는 부분 자체는 소스를 공개를 해서요.

26:23
누구나 제한사항 없이 해당 그 소스를 또 가공 처리해서 새롭게 뚝딱 이렇게 만들 수도 있게끔 네 오픈한 소스 소프트웨어가 오픈소스이고 oss라고 하는 약어는 오픈소스 소프트웨어의 약어입니다. 자유로운 사용이 가능하다 시스템 구축할 때 적용 의무를 단 신중하게 결정할 필요성은 있다. 어떤 부분이냐면은 이제 저작권의 범위나 이러한 것들 네 뒤에 보도록 하겠습니다. 콘서스 사용할 때 고려사항으로서는요 라이센스의 종류 사용자 수 기술의 지속 가능성 그리고 라이센스 문제에 대한 판단이 어렵다면 전자 정부의 표준 프레임 oss 사이트를 참조해서요. 조회해 볼 수 있겠습니다.

27:19
개발 기술 환경 정의와 관련되어진 퀴즈 한 문제 예시로 한번 보도록 하겠습니다. 데이터베이스 관리 시스템 dbms 관련되어진 요구사항 식별 시 고려 사항으로 적절하지 않은 거 틀린 거 골라라 첫 번째 장기간 시스템을 장애 없이 사용 가능한지 가용성을 고려해야 한다. 맞죠. 그다음 대규모 데이터 처리가 가능한지 성능을 고려해야 되겠다. 네 성능 따져야 되죠. 데이터베이스 매니지먼트 시스템 dbms에 설치 가능한 운영체제는 고려하지 않아도 돼 자 앞서서 dbms 종류 중에 운영 체제의 윈도우에서만 지원된다라고 말씀드렸던 게 마이크로소프트의 sql 서버는 리눅스나 유닉스는 지원을 안 합니다. 그리고 이런 걸 고려해야겠죠.

28:10
틀린 것은 3번이고 4번 라이센스 및 유지 보조 비용 등에 대한 구축 비용도 고려할 필요성이 있겠습니다. 자 해당 이 ncs 모듈 현행 시스템 분석을 총괄 정리하면서요 두 파트로 저희가 나눠서 살펴봤는데 모의평가 세 문제 한번 정리 문제로 살펴보도록 하겠습니다. 첫 번째 서버의 주요 사항 수량 이중화 등이 적용 요구와 명시되어진 정도는 뭔가 저희 한 4가지 정도 구성도라는 명칭으로 살펴봤었는데 하드웨어 구성도 네트워크 정도 아키텍트 구성도 업무 구성도 해서 서버의 주요 사용 수요량 이중하는 하드웨어 구성도입니다. 그래서 정답은 1번입니다. 맞는 걸 골라라는 거죠.

29:02
다음 두 번째 다음 정의에 대한 기술 요소는 무엇인가 소프트웨어 애플리케이션에게 운영 체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 소프트웨어 살펴봤던 내용 중에서요 해당 정의 문구는 미들웨어에 해당되었습니다. 정답은 2번입니다. 미들웨어 네 3번입니다. 하드웨어와 스페어 리소스를 관리를 하고 컴퓨터 프로그램을 위한 공통 서비스를 제공하는 것은 무엇인가 정의 문구 해당되어지는 정답은 운영체제가 되겠습니다. 오퍼레이팅 시스템 하드웨어와 소피어 리소스 관리 와슨은 웹 애플리케이션 서버였고 데이터베이스 매니지먼트 시스템 tbms 해당 차부터 정리하도록 하겠습니다. 핵심 정리인데요.

29:54
현행 시스템 파악 부분에서는요 다뤘던 내용이 응용 소프트웨어 엔지니어링의 현행 시스템 파악 절차 및 세부 시스템의 구성 요소를 저희가 도출해 봤고요. 구성 요소로서는 쉐어링 시스템 아키텍처 구성도 소프트웨어 구성도 하드웨어 구성도 네트워크 구성도가 있었습니다. 그리고 두 번째로, 개발 기술 환경 정의 부분으로 살펴봤던 주요 내용으로서는 기술 개발 환경에 대한 정의 및 기술 요소별 특징 그리고 오류 사항을 저희가 살펴봤었고요. 기술 환경 요소 4가지 운영 체제 오프레인딩 시스템 os 그리고 dbms 데이터베이스 관리 시스템 그리고 미디어웨어 세부 종류는 왓스에 대해서 살펴봤습니다. 웹 애플리케이션 서버 그리고 오픈 소스 소프트웨어까지 살펴봤습니다. 이상으로 현행 시스템 분석에 대한 내용 마치도록 하겠습니다.

30:55
세척 설계의 세척 요구 사항 확인 두 번째 요구 사항 확인하기에 대해 살펴보도록 하겠습니다. 학습 목표입니다. 세 가지 학습 목표인데요. 소프트웨어 공학 기술의 요구사항 분석 기법을 활용을 하여 업무 분석가가 정의한 공용 소프트웨어의 요구 사항을 확인할 수 있다. 두 번째 업무 분석가가 분석한 요구 사항에 대해 정의되어진 검증 기준과 절차에 따라서 요구 사항을 확인할 수 있다. 세 번째 업무 분석가가 수집하고 분석한 요구 사항을 개발하고자 하는 공용 속도에 미칠 영향에 대해서 검토하고 확인할 수 있다. 학습 내용은 똑같습니다.

31:41
요구사항 정의 그리고 두 번째 요구사항의 시스템화 타당성 분석 용어 사전으로서요 먼저 요구공학이라는 용어 살펴보면 요구 공학 요구사항을 정의하고 문서화하고 관리하는 프로세스를 이야기합니다. 요구에도 뒤에 공학이 있네요. 공학은 뭔데요. 공학은 과학적 경제학적 사회적 원리와 실용적 지식을 활용하여 새로운 제품과 도구를 만드는 것을 이야기합니다.

32:13
이 요구 공학이 중요하게 된 이유는 내용상에서 저희가 살펴보도록 하겠는데 요구적인 부분 자체를 제대로 확인하지 않으면 나중에 완성된 결과가 다시 피드백해서 다시 만들어질 때 시간 비용 이러한 부분들이 훨씬 더 많이 요구될 수 있기 때문에 적인 측면에 대한 처리가 굉장히 중요해졌죠 통합 모델링 워너 세 번째 용어인데요. 유니파이드 모델링 랭귀지라고 해서요. uml unifid modeling language uml을 이야기합니다. 소프트웨어 공학에서 사용되는 표준화되어진 범용 모델링 언어로 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다. 객제지향 모델링 언어다 라고도 이야기를 합니다. 객제지향모델링언어 라고도 합니다. 자 세부 내용 살펴보도록 하겠습니다. 첫 번째 요구사항 정의에서 요구공학의 출현입니다.

33:11
요구공학이라고 하는 부분은 요구사항을 정의 문서와 관리하는 프로세스인데 요구사항의 지속적인 중요성이 증대하면서 요구사항에 대한 체계적 관리에 대한 필요성이 궤도에서 출연한 게 요고공학이다. 요구사항 개발 프로세스입니다.

33:32
요구사항 프로세스는 4단계로 도출 분석 명세 확인 도출에서는 요구사항 소스 그리고 요구사항 도출 기법을 저희가 세부적으로 살펴보겠고 분석 버날로시스에서는 요구사항에 대한 분류 개념 모델링 기술 구조 설계 및 요구사항 할당 그리고 요구사항 협상에 대해 살펴보도록 하겠고 그리고 명세에서는 시스템 정의서 시스템 요구사항 명세서 그리고 소프트웨어 요구사항 명세서와 같은 분석화 결과치가 만들어지겠고 확인해서는 검토 프로토타이핑 실험적 원형 모형을 만들어내겠고요. 모델 검정 인수 테스트가 되겠고 해당 이 개발 프로세스는 속도공학 지식 체계 출처로 정리한 내용이 되겠습니다. 자 요구사항 개별 프로세스를 세부적으로 살펴보겠습니다.

34:28
첫 번째 요구사항 도출 요구사항이 어디에 있고 어떻게 요구사항을 수집할 건가와 관련된 내용으로서 이해관계자가 식별되어져야 됩니다. 이해관계자라고 하는 부분 자체는 기업이나 행정 등에 직 간접적인 이해를 갖는 개인도 되고 그룹도 되고 주주 고객 노동자 하청업체 등을 통칭하여 뜻하는 게 이해관계자이구요. 개발팀과 고객 사이의 관계 형성이 중요하고요. 요구사항을 도출할 때 그리고 다양한 이해관계자와 효율적인 의사소통이 중요합니다. 그래서 일반적으로 해당 팀장의 주요 역할도 보면 커뮤니케이션 능력 기술적인 부분뿐만 아니라 네 요구사항을 해당 업무 분석가에 따라서 요구사항을 잘 뽑아내는 케이스가 있고 그렇지 못한 경우도 있거든요.

35:21
그런 이제 이해관계적인 부분에 대한 커뮤니케이션 의사소통 능력도 굉장히 중요하다 네 두 번째 요구 사항 분석입니다. 요구 사항 분석은 뽑아진 요구 사항들 간에 상충 충돌이 발생하는 것들이 있는지라는 부분을 보고 그걸 또 조율을 할 수 있어야 되겠고 그다음에 소프트웨어의 범위 파악 그리고 소프트웨어가 환경과 상호 작용하는지를 이해하고요. 시스템 요구 사항을 정제한 후에 소프트웨어 요구 사항들을 도출을 합니다. 그리고 소프트웨어 요구 사항에 대한 명세입니다. 체계적으로 검토 평가 승인될 수 있는 문서를 작성하는데 그 예시가 되어지는 문서가 시스템 정의서 시스템 요구 사항 그리고 소프트웨어 요구 사항 정의서가 되겠습니다. 마지막으로, 요구사항 확인입니다. validation이요.

36:16
분석가가 요구사항을 이해했는지를 확인할 필요성이 있는데, 요구사항 문서가 일관성 있고 완전한지를 검증하고요. 그리고 이해관계자들이 문서 검토 및 형상 관리를 수행할 수가 있겠습니다. 실제 내용을 아는 사람한테 어 우리가 이렇게 요구사항 뽑았는데 다시 한번 컨펌해 달라 맞는지 그 실제 담당자가 그 내용을 잘 알겠죠. 그리고 리소스가 요구사항이 할당되기 전에 문제 파악을 위한 검증을 수행을 합니다. 다음으로, 요구사항 분석 기법입니다. 요구사항 분석 기법이라는 부분은 요구사항에 대해서 정확한 분석을 위한 다양한 기법 적용이 되는데 요구사항에 대한 명확화가 가능합니다. 분석기법의 종류는 요구사항 분류 개념 모델링 요구사항 할당 요구사항 협상 정형 분석이 있습니다.

37:10
세부 내용으로서요 요구사항 분석 기법 첫 번째 요구사항 분류라고 하는 부분은 자 요구사항이 기능적이냐 비기능적인가 라는 부분으로 나눕니다. 기능적인 부분에 대한 거는 이제 기술적인 측면으로 구현을 하면 되는데 비기능적이라는 부분 자체는 어떤 조직적인 측면에서의 어떤 네 제한들이 제약들이 있어요. 어 우리는 우리 기업은 이러한 제품은 특정 기업하고는 거래해 이런 것도 있겠구요. 또는 제도적 측면에 대한 내용도 있겠고 뭐 경제적 측면에 대한 내용도 있겠고 요구 사항이 하나의 사항이 고수준 요구 사항으로부터 도출된 건지 또는 이해관계자나 다른 원천으로부터 발생한 건지로 나누겠고 그리고 요구 사항이 제품 및 프로세스에 관한 것인지 분류합니다. 우선순위를 부여를 해서요. 우선순위별로 요구사항들을 분류할 필요성이 있겠고요.

38:09
그리고 소프트웨어에 미치는 영향 범위에 따라서도 분류할 수 있겠고 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부도 체킹할 필요성이 있습니다. 소프트웨어 생명주기라고 하는 부분 자체는요 소프트웨어 라이프 사이클을요 소프트웨어 개발 sdlc라고 소프트웨어 디벨먼트 라이프 사이클 계획 분석 설계 구현 테스트 유지 보수 이렇게 자 비계정적 우수상에 대한 분류 예시입니다. 비계정적인 부분은 네 제품에 대한 사용성이나 효율성이나 신뢰성이나 이식승 또는 조직적인 측면에서의 어떤 나쁜 구현 표준 외부적인 측면에 대한 상호 운용성이나 윤리 준법 법적인 측면에 대한 이러한 것들도 네 고려하는데 이게 이 기능적 요구사항에 해당되어집니다. 다음 요구사항 분석의 두 번째 개념 모델링에 대한 내용인데요.

39:07
자 이해관계자와 철저한 검증을 위한 상호 이해가 필요한데 개념 모델의 역할은 실 세계 문제에 대한 모델링이 소프트웨어 요구사항 분석에 대한 핵심이 됩니다. 그래서 모델은요, 문제가 발생하는 상황에 대한 이해를 정지시키고 해결책을 설명하기가 좋다. 무슨 말이냐 해당 이 내용을 요구사항들을 쭉 파악을 했어요. 파악을 했는데 해당 그 실 담당자하고 커뮤니케이션 할려면 전문적인 용어로 구성되어져 있는 문서를 제시하고 우리가 파악한 거 이것도 검토해 주세요. 잘 몰라요. 네 이해가 잘 안 되니까. 그래서 쉽게 이해할 수 있도록 모델링 언어들을 이용을 하는데 대표적인 게 통합 모델링 언어인 uml입니다. 뒤에 나오는 내용인데요.

40:00
문제 도메인의 액티비티와 그의 관계 및 종속성을 반영한다. 이렇게 돼 있고 개념 모델의 종류 표기법입니다. 개념 모델의 종류와 종류 및 표기법으로서는 종류는 다양한데요. 유스케이스 다이어그램 데이터 호름 모델 상태 모델 목표 기반 모델 사용자 인트랙션 모델 백제 모델 데이터 모델 등이 있는데, 주로 많이 사용하는 표기법은 통합 모델링 블랭귀지인 uml을 많이 사용한다 그러면 통합 모델링 랭귀지인 이 uml은 뭔데 소프트웨어 공학에서 사용되는 표준화되어진 범용 모델링 언어입니다. 이건 프로그래밍 언어가 아니고 표현 언어라고 보시면 돼요. 네 해당 um에는 다양한 다이어그램들이 있는데요. 총 세부적으로 15개가 있습니다.

40:53
15개 있는데, 저희 정보 처리 기사 파트에서는 한 5개 정도만 실습적인 측면에서는 저희가 살펴보도록 할 겁니다. 실기 파트에서요 자 크게 양분하해서요. uml은 구조 다이어그램과 행위 다이어그램으로 나눠지는데 구조 다이어그램이라고 하는 부분은 시스템의 정적인 구조를 표현을 하고 있는데, 또는 시스템의 구성 요소나 구성 요소들 간의 관계를 나타내는 것으로서 다이어그램의 종류는 클래스 다이어그램 오브젝트 다이어그램 객체 그리고 컴포넌트 다이어그램 컴파지 다이어그린 디플로잉먼트 배포 다이어그램 이러한 것들이 해당되어지고 대표가 뭐다 클래스 다이어그램 그다음 행위 다이어그램은 어떤 시간적 흐름에 따라서요 우리가요 부정적이지 않고 바뀌는 걸 이야기합니다.

41:42
그래서 시스템 내 객체들이 동적인 행위 표현이 해당되어지고 행위 다이어그램에 해당되어지는 다이어그램 종류는 유즈 케이스 다이어그램 시퀀스 다이어그램 액티비티 다이어그램 커뮤니케이션 다이어그램 인트랙션 다이어그램 등이 있습니다. 문제 내기 쉽겠죠. 객관식 문제대로 그다음에 uml의 다이어그램의 종류가 다른 거 하나 골라 이런 형태로 다음 요구사항 할당입니다. 요구사항 할당은 요구사항을 만족시키기 위한 악색적 구성요소를 식별하는 것이다. 요구사항을 만족시키기 위한 타 시스템적인 필요 사항도 확인합니다. 다른 구성 요소와 어떻게 상호 작용하는지도 분석하고요. 이러한 분석을 통해서 추가적인 요구 사항을 발견할 수도 있겠죠. 네 번째로는 요구사항 협상입니다. 자 2명 이상의 이해관계자가 서로 요구사항이 상충돼요. 이렇게 해줬으면 좋겠다.

42:37
이렇게 해주게 되면 b라는 사람은 이렇게 해줬으면 좋겠다라고 하는데 그렇게 하게 되면 b라는 사항이 충족되지 못하는 반하는 급 케이스 같은 경우에는 2명의 이해관계자가 서로 상충되는 내용을 요구하거나 또는 요구사항과 있을 수 또는 기능과 비기능 요구 사항들이 서로 상충될 때 적절하게 협상할 수 있어야 됩니다. 네 협상점을 찾아야 돼요. 트레이오프 지점에서 합의를 수행한다. 그리고 요구사항별 우선순위 부여로 중요한 요구사항은 필터링할 수 있도록 하고 요구사항들 간에 상충되는 문제를 해결하는 게 요구사항 협상 과정이 되겠습니다. 네 마지막으로, 정량 분석입니다. funal aleacyis 형식적으로 정의되어진 시멘틱을 지닌 언어로 요구 사항을 표현한다.

43:25
정확하고 명확하게 표현해서 오해를 최소화시키고 그리고 이 정량 분석은 요구 사항 분석의 마지막 단계에 수행이 되어지고요. 요구사항 확인 기법입니다. 네 요구사항 확인 기법 첫 번째 요구사항 검토입니다. 요구사항 검토는요 요구사항 검증이 가장 일반적인 방법이고요. 에러나 잘못되어진 가정이나 불명확한 불명확성 표준과의 차이 등에서 찾아내서 작업을 수행할 수 있고 이 요구사항 검토에서는요 고객 중심의 프로젝트인 경우에는 반드시 검토자 그룹에 고객 대표자가 한 명 이상 포함이 되어야 정확한 요구 사항을 뽑아낼 수 있겠죠.

44:14
또 피드백 받을 수도 있겠고 요구사항 검토는 시스템 정의서나 시스템 사양서 요구사항 소프트웨어 요구사항 명세서가 완성된 시점에서요 진행을 합니다. 뽑아진 요구사항에 대해서 확인해 달라는 거죠. 검토 i 트리플 e ie2 st 스탠더드 80 830-1998의 사용자 클래스 기준으로 조직화되어진 소프트웨어 리카인먼트 스페시피테이션의 템플리스 예제입니다. 상세 요구 사항에는 외부 인터페이스 요구 사항과 기능 요구 사항이 있는데, 외부 인터페이스 요구 사항에서 체킹해야 될 사항으로서는 사용자 인터페이스 하드웨어 인터페이스 소프트웨어 인터페이스 등 견본 템플러 예제이니까. 개괄적으로 살펴보고 스킵하겠습니다. 요구 사항 확인 분포 두 번째는 프로토 타이핑입니다.

45:09
뽑아진 요구 사항이 제대로 됐는지를 검토하는 측면에서요 프로토 타이핑은 새로운 요구 사항 구출에 대한 수단 및 소프트 엔지니어의 해당 내용이 맞는지를 확인하는 수단이 되겠고요. 장점은 분석자의 가정을 파악하고 잘못된 경우에 이거 잘못됐어요라고 피드백을 받을 수가 있겠고 사용자 인터페이스에 대한 동적인 행위에 대한 용이성을 제공합니다. 프로트라이케어라는 부분 자체는 예시로 만들어 보는 만들어서 맞느냐라고 결과치가 있다 보니까 눈으로 보이는 결과치가 있거든요. 네, 그러다 보니까 그냥 사용자로부터 피드백 받기가 용이해요. 그리고 용상의 가변성이 프로토타임핑 이후에 급격히 감소할 수 있다. 네 요구 사항에 대해서 프로토타이핑 베이스로 해서 파악을 하니까 수정 사항 이런 이런 부분은 수정 사항이 있고 이거는 괜찮아요.

46:07
근데 단점은요, 사용자의 관심이 해당 프로토타입 디자인이나 또는 품질 문제로 측정될 수 있고 네 프로토타이핑을 만드는 데 수행하는 비용이 발생할 수 있다. 요구사항 확인법 세 번째 모델 검증입니다. 분석 단계에서 개발되어진 모델에 대한 품질을 검증할 필요성이 있는데, 객체 모델의 경우는 객체 사이에 존재하는 의사소통 경로 검증을 위한 정적 분석을 수행을 합니다. 이 정적 분석이라고 하는 부분 자체는요 상세한 세부 설계나 코딩을 진행하면서 프로그램을 수행하지 않는 상태에서요 상세 설계나 코딩을 진행하면서 저희는 지금 현재 단계가 코딩까지는 아니죠. 설계 단계인데 상세 설계에서요 실제 프로그램을 실행하지 않은 상태에서 소스 코드와 모델에 대한 결함을 찾아내는 방법이 정적 분석입니다.

47:07
그래서 비교적 초기에 개발 초기에 결함을 찾아내면 전체적인 개발 수명 주기의 효율성을 높여서 개발 비용을 낮출 수 있는 도움을 얻을 수가 있겠습니다. 네 esc 테스트입니다. es는 요구 사항의 중요 속성으로서 제품 최종 제품이 요구 사항을 만족시키는지 확인이 가능하고요. 각각의 요구 사항이 어떻게 확인할 것인가에 대한 계획 수립이 필요합니다. 자 요구사항 정의에 대한 퀴즈입니다. 프로토타이핑이 가지고 있는 장점이 아닌 걸 골라라 첫 번째 잘못된 요구사항 사전에 도출 및 향후 발생 장비 낭비를 제거할 수 있어 맞죠. 프로타이밍은 그냥 얘를 실험적으로 만들어 가지고 보여주는 거예요.

48:02
요구사항을 제대로 반영했는지 분석 간의 과정을 파악하여 두 번째 잘못된 경우는 유용한 피드백을 제공할 수 있어 사용자로부터 잘못된 거 이거 잘못됐다라는 부분을 명확하게 제공받을 수 있다. 세 번째 사용자 인테이스에 동적인 행위 용이성을 제공한다. 네 번째 프로토타입 수행 비용이 발생할 수 있어 장점이 아닌 걸 골라라 얘는 단점이죠. 그래서 4번이 장점이 아닙니다. 비용 발생 다음 두 번째 파트로서요 네 요구사항의 시스템화 타당성 분석입니다. 요구사항 확인하기에 두 번째 파트입니다.

48:36
첫 번째 내용으로서요 요구사항의 기술적 타당성 검토 자 타당성이라고 하는 부분 자체는 해당 이게 제대로 될 건가 라는 부분에 대한 내용인데 분석인데 타당성 분석의 종류는 기술적 타당성 분석 조직적 타당성 분석 경제적 타당성 분석 법률적 타당성 분석 다양하게 있습니다. 그중에서 이제 저희 이 ncs 능력 단위에서는 기술적 타당성 분석에 포커스가 맞춰져 있습니다. 기술적 타당성 분석에서는 적용 기술의 적합 그리고 실현 기술 실현의 가능성 이 분석의 핵심 내용이 되겠고요. 성능 및 용량 산정이 제대로 되느냐 시스템 간의 상호 운용성에 문제는 없느냐 it 시장의 성숙도 및 트렌드에 부합하냐?

49:28
기술적인 위험 분석 기술적으로 너무 위험하지 않느냐 장애물 볼게요 성능 및 용량 산정의 적정성에서는 목표 시스템에 대한 용량 산정이 과거의 유사 프로젝트 경험치를 적용해서 필요하면 재조정할 필요성이 있고요. 그리고 성능과 관련한 비기능적 사항과 비교해서 또 적정한지 여부를 또 판단을 합니다. 시스템 간 상호 운용성 이 시스템 간 상호 운용성이란 건 뭔데 다른 목적을 지닌 2개 이상의 시스템들이 상호 간에 해당 연결을 할 때 상호 간 정보 및 서비스를 교환하면서 효율적으로 운영될 수 있는 시스템의 능력이 상호 운용성입니다.

50:19
요구 사항 중에 목표 시스템이 조직 내외의 타 시스템과 연동을 요구하는 경우에 상호 운영성이 가능한지 여부를 중점적으로 파악해 볼 필요성이 있습니다. 세 번째 it 성숙도 및 트렌드 부합 속도 영역별로 정보 기술의 시장 성숙도 및 발전 방향을 파악을 해서요. 요구 사항에 부합한지 여부를 판단하고 시장 성숙도가 미약하다든지 트렌드에 미부합한 기술들은 나중에 사용되지 않을 가능성이 높으니까 시스템 유지 보조가 어려운 상황이 발생할 수 있다. 그렇기 때문에 해당 기술적인 측면에 대해서 이 해당 이 기술이 it 시장 성숙도가 트렌드 오브에 부합한가라는 부분을 파악할 필요성이 있습니다. 기술적인 위험 분석인데요.

51:10
요구 사항을 만족시키기 위해서 적용하는 기술에 대한 복잡성이나 검증 여부 그리고 의존성 등에 대한 위험 발생 가능성 영향도를 파악하는 것을 뜻합니다. 기술적 위험 분석의 기술 특성과 내용 3가지 기술 특성으로서 복잡성은 기술의 안정성이나 시장성 개방성을 저해하는 낮추는 모든 요소 그리고 하료 요소케어 솔루션 적용이 앞으로 불일치한다든지 이러한 것들을 복잡성 부분에서 따져볼 필요성이 있고 그리고 검증 여부는 적용 기술에 대한 조직 내에 어 이 기술은 우리가 전혀 사용 안 해본 건데요. 어디 그런 경우 이제 그다음 경험하지 않았던 기술이냐 외부 지원이 혹시 불가능한 거 아니냐 그런 경우에는 적용할 수가 없잖아요.

52:02
그렇기 때문에 검증 여부 기술적 위험 분석에서 따질 필요가 있고 의존성은 특허나 라이센스에 따른 문제가 발생하는 경우 또는 특정 업체 기술에 너무 의존적이지 않느냐 이런 것들을 따지는 것을 이야기합니다. 네 해당 내용 정리하면서 모의평가 세 문제 한번 풀어보도록 하겠습니다. 첫 번째 다음 중 요구공학 개발 프로세스를 순서대로 나열한 것은 올바른 거 도출 분석 명세 확인 1번이 정답이죠. 요구사항 도출 분석 문서 작성하는 스페시피테이션 명제 그리고 확인하는 밸러데이션 정답은 1번 두 번째 요구 사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것을 요구사항 할당이라고 하는데 요구사항 개발 언어 분석 기법에 해당되어지는가?

53:02
요구 사항 분석 기법 요구 사항 분류 개념 모델링 요구사항 할당 정형 분석 다 요구사항 분석 기법인데 문제에서 답이 있어요. 네 요구사항 할당이라고 합니다. 네 요구사항 할당입니다. 요구 사항을 만족시키기 위한 아피틱 구조 요소를 식별하는 거 다음 기술적 타당성 검토할 때 유의사항으로 적절하지 않은 겁니다. 틀린 거 골라라 첫 번째 요구되는 성능과 용량이 시스템 용량 산정 결과 비교해서 적합하냐? 네 맞죠. 차 시스템 연계 및 인터넷에 대한 요구 사항 확인의 경우에는 상호 운용이 가능한지 검토한다. 맞죠. 기술이 시장 성숙도 및 트렌드와 무관하게 무조건 기술적 난이도가 높고 특별한 기술을 선택을 하여 시스템을 구축하는지 확인하고 검토한다. 1가 틀린 보기 항목입니다.

54:03
네 번째 시스템을 구축하기 위한 인력 자원 및 기간이 계획을 초과하여 추가적 비용이 발생하지 않는지 여부도 검토해야겠죠. 자 핵심 내용 정리하고 마무리하도록 하겠습니다. 첫 번째 요구사항 정의 섹션에서 저희가 살펴봤던 내용 중에 중요 내용은 요구사항에 대한 개념을 정확하게 파악하고 이를 기반으로 고객의 요구사항을 체계적으로 정립할 필요성이 있더라 요구사항 개발 프로세스 단계는 요구사항 도출 분석 명세 확인 단계였습니다. 두 번째 요구사항 시스템화 타당성 분석 섹션에서 살펴봤던 내용 중에 요구사항이 시스템으로 구축되어졌을 때 타당하냐? 제대로 되겠냐 기술적 타당성을 위주로 저희가 살펴봤었죠.

54:54
요구사항 기술적 타당성 검토 요소로서는 성능 및 용량 산정의 적정성 시스템 간 상호 응용성 it 시장 성취도 및 트렌드 부합성 그리고 기술적 유형 분석 내용에 대해 살펴봤습니다. 네 이상으로 요구사항 확인에 대해 마치도록 하겠습니다. 네 소프트웨어 설계 첫 번째 요구사항 확인에 대한 세부 내용 중에 세 번째 분석 모델 확인하기 살펴보도록 하겠습니다. 학습 목표 3가지 소프트웨어 공학 기술의 영상 도출 기법을 활용하여 업무 분석가가 제시한 분석 모드에 대해서 확인할 수 있다. 두 번째 업무 분석가가 제시한 분석 모델에 대하여 응용 소프트웨어를 개발하기 위한 추가적 의견을 제시할 수 있다.

55:48
세 번째 업무 분석가가 제시한 분석 모델이 개발할 응용 소프트웨어에 미칠 영향을 검토하여 기술적 타당성 조사를 할 수 있다. 학습 내용은 두 카트로 분석 모델 검증과 분석 모델의 시스템화 타당성 분석으로 나눠서 살펴보도록 하겠습니다. 연구 사정에서는 첫 번째 유스케이트 다이어그램은 사용자 입장에서 시스템의 동작에 대한 시나리오다 즉 해당 시스템에서 제공하는 기능이라고 보시면 됩니다. 두 번째 클러스 다이어그램 소프트웨어의 정적 요소 클러스들 간의 관계를 보여주는 구조적 다이어그램이 되겠고요. 상호 운영상은 앞 챕터에서 저희가 살펴봤었는데 동일 기종 또는 이 기종의 정보 시스템 기기 및 서비스 간 상호 원활한 통신이 가능하고 정보 교환이나 일련의 처리를 정확하게 실행할 수 있는 특성을 뜻합니다.

56:48
분석 모델 검정 세부 내용으로서요 분석 모델링 검증 순차적으로는 유스 케이스 모델 검증 개념 수준 분석 클래스 검증 그리고 분석 클래스 검증 세부 유스케이스 모델 검증은 액터 도출 유스케이스 도출 유스케이스 명세서 작성이 되겠고 개념 수준 분석 및 개념 수준 분석 클래스 검정은 클래스 도출 클래스 이론과 속성 부여 클래스 간의 관계 설정 분석 클래스 검증은 스테레오 타입 부여 경계 및 제어 클래스 도출 관계 및 상세화 정도가 되겠는데 해당 이 체계는 한국정보화진흥원 정보 시스템 감리 지침을 베이스로 정리한 내용입니다. 유스케이스 모델 검증부터 살펴보면 첫 번째 액터 행위자죠 네 이 행위자는 사람이 될 수도 있고요. 다른 시스템이 될 수도 있습니다.

57:48
자 액터를 제대로 뽑았는가라는 네 검토사항으로 저는요 기능 구형에 관계되는 액터가 모두 노출됐는가라는 부분을 고려해야 되겠고 액터 목록에서 액터 이름이 어떻게 중심으로 부여가 되어졌느냐 요구사항 정의서 요구사항 기술서에 외부 및 내부 액터가 모두 뽑아졌는가 그리고 액터 목록과 액터 명세서에 기록되어진 액터가 타당한지를 확인합니다. 뮤직 케이스와 관련해서요. 도출되어진 고려 사항 도출 고려 사항으로는요 요구 기능 구현에 필요로 하는 뮤직 케이스가 모두 다 뽑아졌는가 그리고 도출되어진 유즈 케이스를 논리적으로 연결하여 누락된 기능이 있는지 여부를 파악하고요.

58:38
도출되어진 유즈 케이스가 유즈 케이스 명세서에 잘 반영되어 있는지 확인하고 도출된 유즈 케이스의 논리적인 합이 과업 범위와 일치하는지를 비교합니다. 그리고 도출된 유지 케이스들이 논리적으로 그룹화되어 있는지 이 그룹화는 팩터 기준 연관 관계 기준 동지성 기준으로 체킹해 볼 수 있겠고요. 마지막으로, 유지 케이스 기능 범위와 중복되지는 않는지 확인합니다.

59:12
세 번째로, 유스케이스트 명세서 작성과 관련되어진 고려 사항인데 유스케이션 명세서 형식이 중요 항목이 누락되지 않았는지 확인하는데 유즈 케이스 명세서의 양식 내에 포함되어지는 구성 요소로서는 사전 조건 사후 조건 주요 정상적인 포멀 흐름과 그다음에 어떤 객체 흐름 올터너티브 또는 예외 흐름 이러한 것들이 포함되어집니다. 실기 파트에서요 저희가 유스 케이스 명세서 작성 살펴보도록 할 겁니다. 유스 케이스의 주요 이벤트 흐름이 모두 도출되고 논리적으로 타당한지를 확인합니다. 유스 케이스를 구현하기 위해 필요로 하는 입력 및 출력 항목이 모두 도출됐는지 확인합니다.

1:00:00
다음으로, 개념 수준의 분석 클래스 검정으로서요 분석 클래스 검정은 뭔데 분석 클래스 검정은 시스템의 주요 도메인 개념을 분석 클래스로 도출해서 유직 베이스 분석에 활용할 수가 있습니다. 개념 수준의 주요 분석 클래스를 적절히 도출했는지 그리고 관련 정보가 명확한지 점검합니다. 분석 클래스 검증이 주요 점검 항목 세부적으로 살펴보면 개별 유스케이스 단위로 작성하지 않고요. 시스템 전체적인 측면을 대상으로 작성이 되어 있는지를 체킹하고 그리고 중요도가 높은 요구사항 또는 유스 케이스가 필요로 하는 엔터티 클래스가 도출되었는지를 체킹합니다. 이 클래스의 종류는 뒷단에 저희가 살펴보도록 하겠는데 엔터티 클래스가 있고요. 그리고 바운드리 클래스가 있고요. 그리고 제어 클래스가 있습니다.

1:00:54
기능적인 부분에 뒤에서 살펴보도록 할게요 자 도출되어진 클래스 이름이 클래스명과 클래스 이름과 설명이 이해관계자 간의 의견이 발생하지 않도록 명확한가 그리고 클래스의 속성 클래스는 클래스 속성 자 uml 다이어그램 저희가 뒤에 예제로 나오는데 이렇게 세 등분으로 사각형으로 클래스를 표출합니다. 클래스 이름이 들어가고요. 중간 단위 클래스 속성 그다음에 마지막 단위 operation operation이 들어갑니다.

1:01:36
세파트로 돼 있는데, 해당 이 두 번째 속성이 도출됐는가 제대로 그리고 도출되어진 속성의 이름과 설명이 명확한가 그리고 클래스 간에 순환적 관계가 불필요하게 정해져 있지는 않는가 그리고 클래스와 클래스 간의 관계 설정이 이렇게 되는데 해당 그 관계 다중성이 정의가 제대로 됐는지 다중성에 대한 부분은 저희가 바로 살펴보는데 클래스 간의 다중성이라는 부분은 클래스 간의 관계에서 연관관계를 표현한 걸 나타내고요. 이 연관관계를 그냥 실선으로 띄어주면 돼요. 자 클래스를 나타내는 예인데 고객 클래스가 있고요. 주문 클래스가 있어요. 이렇게 그리고 서로 경관 관계를 가집니다. 고객 클래스의 속성으로서는 이름 성별 주소가 있구요. 그리고 주문 클래스에서 속성은 일시 일련번호 수량 가격이 있네요. 각 클래스는 네 해당 연관 관계가 고객은 한 사람이 주문을 안 할 수도 있어요.

1:02:33
해당 물건 이 주문 테이블 나중에 저희가 9년에 내년 테이블 단위로 구현이 되어질 건데 이 클래스는 엔터티 클래스가 됩니다. 엔터티 클래스는 데이터베이스 내에 테이블로 구현이 되어집니다. 구현 파트에서 주문 테이블 내에 언제 그리고 해당 부분 네 주문 번호 그리고 몇 개 그다음에 뭐 가격 이러한 정보가 저장이 되어질 건데 고객은 해당 그 상품을 주문할 수도 있고 안 할 수도 있는데, 안 하는 경우엔 영업이구요. 하는 경우에는 여러 건을 할 수도 있죠. 그래서 용돈은 무한대로 표시한 네 해당 다중성의 예이고 요 다중성의 표기법은 0.1은 0 또는 1개 발생할 수 있다. 이 말입니다. 안 할 수도 있고 하는 경우에는 하나 0.0 별표 또는 별표는 0을 포함한 모형계 인스턴스 발생할 수 있다.

1:03:30
그다음에 1은 1개 1.0 별표는 1개 이상 다중성 표기법 방법입니다. 분석 클래스 검증입니다. 이 분석 클래스에 대한 검증은 분석 클래스가 적절하게 도출되었었는가 그리고 제어 클래스의 도출 등이 충분하고 상세하게 도출되어서 클래스의 역할과 클래스의 관계 메시지 흐름 등을 확인할 수 있는지를 검토합니다. 분석 클래스 검증에서요 유즈 케이스 실행에 실현에 필요한 분석 클래스 검증 세부 내용에서는 하나의 유즈 케이스를 실현하기 위해서는 3개 이상의 클래스가 역할 기준으로 도출되어 주면 좋다. 유스 케이스별로 실현에 필요한 클래스가 추적 가능해야 하고 클래스의 누락 여부를 확인할 수 있어야 합니다.

1:04:31
유스케이스별로 도출되어진 분수 클래스의 역할 기준으로는 세 가지가 있다. 첫 번째 경계 이 경계 바운더리는요 실제 사용자가 화면으로 보는 구분이 됩니다. 그래서 이제 화면이 있죠. 로그인을 한다라고 하게 되면 로그인 화면이 있죠. 네 아이디 비밀번호 입력하세요. 로그인 버튼 있죠. 그다음에 엔터티 클래스가 있는데, 이 엔터티 클래스는 로그인을 수행하기 전에 선행적으로 그 사용자는 해당 홈페이지라고 가정하면 홈페이지에 회원 가입이 먼저 돼야 됩니다. 그렇지 않으면 로그인 아이디 비밀번호를 입력하고 로그인 요청을 하게 되면 가입되지 않은 사용자 아이디다 이런 메시지가 뜨겠죠. 그래서 선행적으로 회원 가입 폼 양식을 통해서 입력한 개인 정보 값들이 어디에 저장되어지느냐 데이터베이스 매니지먼트 시스템 내에 테이블로 저장되어지는데 그 테이블이 엔터피 클래스가 됩니다.

1:05:30
그다음에 제어 클래스라고 하는 부분 자체는 로그인 페이지에서 아이디하고 비밀번호를 입력을 하고 로그인 버튼을 눌렀을 때 처리가 진행되어지는 네, 뭐 jsp든 bhp든 asp든 서브 단에서 입력한 아이디와 비밀번호를 받고 그다음에 데이터베이스하고 연결을 해요. 회원 가입한 테이블인 멤버 테이블 내에 해당 이 아이디 사용자가 있느냐를 따져서 있어 그러면 두 번째는 비밀번호가 맞느냐 맞아 그러면 로그인 시켜주고 그렇지 않으면 에러 메시지를 띄워주는 거죠. 그와 관련해서 세 가지 클래스 경계 클래스는 화면 엔트 클래스는 데이터베이 스테이블 제어 클래스는 해당 컨트롤하는 네 웹페이지 서버 페이지가 되겠습니다. 그리고 스테레오 타입으로 표시를 한다. 이렇게 돼 있는데요. 양쪽 끝에 이렇게 껍새껍새 이렇게 묶어 가지고 표현하는 것을 스테레오타입이라고 이야기를 합니다. 분석 클래스의 스테로타입 표현 방식은 두 가지가 있는데, 일단 클래스 필름에 꺾쇠 꺾쇠 바운더리 이렇게 해도 되구요.

1:06:30
네 모양적인 측면에서 요렇게 또 다이어그램 형태로 해가지고 이렇게 표시를 해도 됩니다. 두 가지 표기 방법이 있습니다. 경계 다이어그램은 시스템과 외부 액터의 상호작용을 담당하는 클래스라 즉 화면이라고 보면 되겠구요. 네 화면 네 그다음에 엔터티는 데이터가 저장되어지는 테이블이라고 보면 되겠고 제어는 해당 로직 제어를 담당하는 클래스가 되겠습니다. 네 동그라미의 꺾쇠 이렇게 화살표 모양 또는 동그라미 밑에 네 선음 표기 엔터티 바운더리는 화면 이렇게 돼 있습니다. 세부적으로는 경계와 제어 클래스의 도출 여부 및 상세한 정도 확인으로서 경계 클래스는 유지 클래스와 연결되어진 액터가 있고 이 유드 케이스가 해당 시스템에 제공하는 기능이라고요.

1:07:25
이 기능을 이용하는 액터 행위자가 있고 액체의 유형이 시스템 또는 장비인 경우는 해당 액체를 위한 경계 클래스가 도출되었는지 확인한다. 이렇게 돼 있습니다. 해당 액터가 꼭 사람만이 아니다라고 말씀드렸죠 다른 시스템이나 다른 장비가 될 수도 있어요. 네 그런 경우에 해당 액터를 위한 경계 클래스도 주셨는지 확인 뉴스 케이스 명세서에 이벤트 흐름을 확인을 하여 조직 케이스에서 필요로 하는 ui는 유저 인터페이스예요. 사용자 인터페이스 두 아이를 위한 경계 클래스가 도출되는지 확인한다. 다음 ui를 위한 경계 클래스인 경우는 사용 벤트페이스 화면이라는 말입니다. 화면의 경우는 사용자에게 제공할 항목이 속정으로 노출되었는지 확인하고 화명 보고서장의 데이터 타입 길이가 경계 클래스 속성 동의와 일치하는지 확인합니다.

1:08:26
제어 클래스입니다. 제어 클래스는 유즈 케이스별로 제어 클래스가 1개 이상 노출했는지 확인하고 제어 클래스의 연산에 대응하는 엔터틱 클래스가 있는지 확인한다. 제어 클래스에서 로그인이라고 말씀을 드렸잖아요. 아까 예제로 아이디 비밀번호를 입력하고 로그인 버튼 눌렀을 때 철회하는 게 제어 클래스인데 얘가요 해당 회원 가입한 정보값을 가지고 와야 돼요. 가지고 오는 대상은 데이터베이스 테이블인데 그게 엔터티 클래스입니다. 유스케이스 명세에서 기술되어진 이벤트 흐름을 처리하기 위한 연산이 제어 클래스에 정의되어 있는지 확인합니다. 클래스 간의 관계입니다.

1:09:08
클래스 간 관계 클래스 정보의 상세와 정도 확인으로서요 먼저 관계는 유스케이스 명세서를 기반으로 각 클래스와의 관계를 정의하는지 확인하는데 관계의 다중성이 정확하고 모순이 없는지 확인하자 그리고 2개의 클래스 간에 1개 이상의 관계가 존재하며 그 관계 이름 또는 역할이 정의되어 있는지 확인합니다. 연산 및 속성의 상세와 뉴스 케이스 명세서를 바탕으로 해서요. 클래스의 속성 클래스가 가지는 변수라고 보면 돼요. 회원 가입 테이블이야 이름 연락처 주소 이런 것들이 속성입니다. 속성과 연산이 도출되느냐 연산은 동작입니다. 동작 배출되어진 그러니까 연산 같은 경우에는 핸터티 클래스는 연산이 없어요. 제어 클래스는 연산 중심적입니다. 제어 클래스는 동작 중심적이죠.

1:10:06
콘텐츠 클래스는 데이터 저장 중심도이고 도출되어진 연산의 매개변수명 매개변수 타입 매개변수 길이와 return 타입이 정의되어 있는지 확인합니다. 도출되어진 클래스의 속성평과 속성의 타입 속성의 길이가 이해관계자 간에 이견이 없도록 명확하게 정의되어 있는지 확인합니다. 자 속성의 길이라고 하는 부분은 해당 어 회원가입 테이블에 입력하는 입력값 중에 데이터베이스에 저장되어질 때 이 길이 있죠. 네 고정적인 문자열을 가지는 것들도 있지만 가변적인 것들도 있잖아요. 어쨌든 최대 크기 값이 입력한 값보다 적게 설정됐으면 입력을 못하는 오류가 발생할 수 있거든요. 정규 클래스의 속성과 화면 보고의 항목 엔터티 클래스의 속성 정보가 일관성을 가지는지 확인합니다. 분석 클래스 다이어그램의 예시입니다. 여기서는 이제 이게 분석 클래스의 이름이고요.

1:11:05
분석 클래스명이고 그 위에 해당 스테레오 타입으로 바운더리라고 돼 있으면 얘는 화면이에요. 공인 인증서로 로그인한 화면이야 해당 속성은 공인 인증 성공 여부고 해당 오퍼레이션은 로그인이다. 이렇게 돼 있고요. 컨트롤 클래스 같은 경우에는 로그인 제어를 한 뒤 입력한 값을 받아가지고, 여기서는 이제 오퍼레이션이 컨트롤은 지금 보면 밑에 세 번째 네 갈록 꼬르미를 가지는 오퍼레이션만 가져요 근데 엔터티는 3개의 구분값 중에 마지막 건 안 가지고 중간에 속성만 가져요 네 엔터티 이름과 다 서로 간에 연결되어 있다. 이 부분도 있고 로그인 과정을 예로 하고 있습니다.

1:11:51
여기서는 이제 공인인증서를 통해서 로그인하는 부분을 해놨는데 네 어 로그인 제어에서는 네 회원 테이블에서 이 사람이 회원 가입한 사람이 마저 혹시 아니면 비회원인 경우에는 비회원에 대한 로그인할 때 뭐 이러한 것들을 저장할 거야. 네 그와 관련되어서 필요한 해당 클래스가 정의돼 있고 연관되어 있습니다. 자 분석 모델 검정 퀴즈입니다. 유스 케이스 모델 검증 수행할 때 적절하지 않은 건 뭐야? 유즈 케이스 모델 검증입니다. 유즈 케이스 모델에서는 팩터 도출 유즈 케이스 도출 유스 케이스 명세서 uml의 스테레오타입은 클래스 클래스 다이어그램과 관련된 부분입니다. 그래서 4번이 틀렸어요. 자 두 번째 섹션으로서 분석 모델의 시스템화 타당성 분석에 대해 살펴보도록 하겠는데요.

1:12:45
먼저 분석 모델의 기술적 타당성 검토로서 분석 모델의 기술 타당성 검토는 성능 및 용량 산정의 적정성 시스템 간 상호 운용성 시장 성숙도 및 트렌드 부합성 마지막으로, 기술적 위험 분석 순으로 살펴보도록 하겠는데 구축 타당성 여부를 최종적으로 검토하는 단계에서 수행을 합니다. 성능 및 용량은 요구 사항을 만족시키기 위한 분석 모델에 따라서 시스템을 구현할 때 요구되는 시스템 자원을 식별할 수 있겠고 분석 클래스에서 불필요하고 지나치게 많은 속성을 포함시키게 되면 오히려 객체를 생성할 때 시스템 내에 메모리 자원을 너무 많이 요구를 하고 해당 처리 속도가 높아지는 게 아니라 떨어질 수 있다.

1:13:39
이로 인해서 jvm 자바 보트롤 머신에서 아도한 가비즈 쓰레기 컬렉션 가비즈 컬렉션이 발생해서 전체 시스템 성능 저하가 발생할 수 있기 때문에 필요로 한 꼭 필요로 한 클래스 내의 속성들만 포함시켜라 이 말입니다. 두 번째 시스템 간 상호 운용성 분석 모델을 이용을 해서 보다 구체적으로 시스템 간의 상호 정보 및 서비스를 교환 가능한지 검토하고요. 분석 모델에서 정의한 구체적 정보의 존재 여부 생성 가능성 교환 방식 지원 등에 대해서 확인하는 단계입니다.

1:14:22
시장 성숙도 및 트렌드 부합성 분석 모델이 과거의 문제를 해결하고 많이 사용되는 트렌드에 부합한지 확인하자 시스템에 중요하고 빈번하게 사용되는 클래스는 해당 프로토타입 빈으로 적용을 해서 이용하는 게 효과적이다. 네 번째 기술적 위험 분석입니다. 분석 모델이 시스템의 기술 구조와 프레임워크 그리고 하드웨어 및 소프트웨어와 부합한지 여부를 확인하는 과정이고요. 분석 모델이 검증되지 않은 기술을 사용한다 라고 할 때는 추가적으로 비용 발생이 가능하겠다라는 부분을 고려해야 되겠고 분석 모델을 구현하기 위해서 특정 업체 기술이나 토커 라이센스에 너무 의존하는 건 아닌지 토 체킹할 필요성이 있겠습니다.

1:15:15
분석 모델 시스템화 타당성에 대한 퀴즈 한 문제 풀어보면 분석 모델의 기술적인 부합성 검토 사항이 아닌 것은 무엇일까? 첫 번째 성능 및 용량 두 번째 시장 성취도 및 트렌드 부합성 그리고 세 번째 시스템과 상호 운용성 네 번째 분석 클래스 검정 네 번째가 아니죠. 성능 및 용량 시장 성적 및 트렌드 부합성 실생과 상호 운용성 그리고 기술 위험성 자 해당 이 챕터를 정리하면서요 네 평가 문제 세 문제 풀어보고 정리하도록 하겠습니다. 첫 번째 분석 모델링 검증 절차가 맞게 나열되어진 것은 첫번째 유지캐스트 모델 검증 개념 수준 분석 클래스 검증 분석 클래스 검증 첫 번째가 정답입니다.

1:16:10
네 분석 모델링 검증 절차는 유스케이스 모델 개념 수준 분석 클래스 분석 클래스 검증 순으로 검증합니다. 두 번째 분석 클래스 검증을 위한 요소로서 거리가 먼 것은 첫 번째 유즈 케이스 실행에 필요한 분수 클래스의 도출 확인 두 번째 경계 클래스의 도출 여부 및 상세와 정도 확인 세 번째 제어 클래스의 도출 여부 및 상세와 정도 확인 네 번째 요구 기능 구현을 필요로 하는 유즈 케이스가 모두 도출되어졌는지를 확인한다. 분석 클래스 검증을 위한 요소입니다. 네 정답은 네 번째 요구 기능 구현을 위한 뉴스 케이스가 뭐 들렸는지 확인한다. 앞부분에 저희가 분수 클래스 검정에서 단계별로 살펴봤던 것 중에 아닌 걸 고르면 되겠습니다.

1:17:10
세 번째 분석 모델의 기술적 검토 요소 중에 분석 모델을 통한 시스템 간 상호 정보 및 서비스 교환 가능성을 검토하는 것은 어떤 검토 요소인가 시스템 간 상호 정보 및 서비스 교환 가능성 검토는 시스템 간 상호 운영성에 해당되어지겠죠. 정답은 2번이 되겠습니다. 핵심 내용으로 첫 번째 섹션 살펴봤던 분석 모델 검증에서 중요 사항은 분석 모델링 검증은 도출되어진 요구 사항에 대해서 분석 모델을 확인하고 이에 대한 추가적 필요 의견을 제시하는 단계다 분석모델검증은 유스캐스모델검증 개념 수준의 분석 클래스 검증 마지막으로, 분석 클래스 검증 순으로 진행이 되어졌었습니다.

1:18:02
두 번째 섹션인 분석 모델 시스템화 타당성 분석은 유스케이스 모델의 개별 유스케이스에 대한 분석 모델을 작성한 이후에 해당 분석 모델로 시스템을 개발하는 경우 어떠한 영향을 미치는지 성능 및 용량 등 필요 자원에 대한 적정성과 상호 운용성 시장 성숙도 및 트렌드 보합도 기술적 위험 분석 측면에서 타당성을 조사했습니다. 분석 모델의 시스템으로서의 구축 타당성 여부를 최종적으로 검토하는 단계에서 진행이 됐죠 네 이상으로 소프트웨어 설계 요구 사항 확인의 세 번째 섹션이었던 분석 모델 확인하기에 대해 살펴봤습니다.