1. 소프트웨어 엔지니어링 개요
1. 선택
소프트웨어 가 실행 가능 하고 제어할 수 없는지 여부
소프트웨어 엔지니어링은 엔지니어링 분야 입니다
일반적인 소프트웨어 수명 주기 모델: 나선형 모델, 증분 모델, 폭포수 모델, 프로토타입 모델, 융합 모델, 신속한 애플리케이션 개발 모델, 민첩한 모델
소프트웨어 수명 주기에서 가장 긴 단계는 유지 관리 단계 입니다.
폭포수 모델은 소프트웨어 수명 주기 모델 입니다.
특징적인 패싯으로 인해 일반적으로 폭포수 모델 이라고 하는 구조화된 수명 주기 접근 방식을 취합니다 .
구조화된 폭포수 모델에서 요구 사항 분석 단계 에서 정의된 기준은 소프트웨어 테스트에서 시스템 테스트 단계의 목표가 됩니다.
2. 단답형 질문
소프트웨어 위기란? 소프트웨어 위기의 징후는 무엇입니까?
답변: 구체적으로 소프트웨어 위기 의 원인은 다음과 같이 요약할 수 있습니다.
- 소프트웨어 개발 초기 단계에서 요구 사항 분석을 무시하십시오.
- 개발 프로세스에는 통일되고 표준화된 방법론적 지침이 부족합니다.
- 불완전하거나 부정확한 문서.
- 사용자 및 개발 팀원과의 커뮤니케이션 무시
- 테스트의 중요성을 무시하십시오.
- 위와 같은 이유로 유지관리에 소홀하거나 작업이 어려운 경우
- 소프트웨어 개발에 종사하는 전문가는 업계에 대한 지식과 경험이 부족합니다.
- 완벽한 품질 보증 시스템은 없습니다
구체적으로 소프트웨어 위기의 발현 양상은 다음과 같이 요약할 수 있다.
- 소프트웨어 개발 비용과 일정은 통제할 수 없습니다.
- 소프트웨어 시스템이 구현한 기능이 실제 요구 사항과 일치하지 않음
- 열악한 소프트웨어 안정성
- 소프트웨어 유지보수가 어렵다
- 소프트웨어가 제대로 문서화되지 않는 경우가 많습니다.
- 컴퓨터 시스템의 총 비용에서 소프트웨어 비용이 차지하는 비율은 여전히 높으며 해마다 증가하고 있습니다.
- 소프트웨어 생산성 향상 속도는 컴퓨터 응용 프로그램의 급속한 대중화 및 심화 추세에 훨씬 뒤떨어져 있습니다.
(4) 소프트웨어 수명주기는 무엇입니까? 몇 개의 기간으로 나뉩니까? 몇 단계?
대답: 소프트웨어 수명 주기는 제품 설계의 구상부터 소프트웨어 요구 사항 결정, 소프트웨어 설계, 소프트웨어 구현, 제품 테스트 및 승인, 사용, 제품 버전의 지속적인 업데이트, 시장에 의한 제품의 최종 제거 전체 프로세스. 소프트웨어 수명 주기는 소프트웨어 정의, 소프트웨어 개발, 운영 및 유지 관리의 세 가지 기간으로 구성되며 문제 정의, 타당성 조사, 수요 분석, 일반 설계, 세부 설계, 소프트웨어 구현 및 단위 테스트, 종합 테스트의 8단계로 나뉩니다. , 및 운영 및 유지 보수 .
(5) 소프트웨어 수명 주기 모델이란 무엇이며 주요 소프트웨어 프로세스 모델은 무엇입니까?
답변: 소프트웨어 프로세스 모델이라고도 하는 소프트웨어 수명 주기 모델은 소프트웨어 프로젝트 요구 사항 정의에서 소프트웨어 운영 및 유지. 일반적인 모델로는 폭포수 모델, 신속한 프로토타이핑 모델, 증분 모델, 나선형 모델, 통합 프로세스, 애자일 프로세스 등이 있습니다.
2. 소프트웨어 문제 정의 및 타당성 분석
1. 빈칸 채우기
타당성 조사의 목적은 문제가 최소 비용으로 최단 시간 내에 해결될 수 있는지 여부를 결정하는 것입니다.
경제적 타당성 조사의 범위에는 투자 이익 분석 , 회사 운영의 장기 전략, 개발에 필요한 비용 및 자원, 잠재적 시장 전망이 포함됩니다.
타당성 분석의 목적은 소프트웨어 프로젝트가 개발할 가치가 있는지 여부를 연구하는 것입니다.
타당성 분석은 기본적으로 요구 사항 분석 및 설계 프로세스를 압축하는 추가 단순화입니다.
비용 편익 분석은 개발할 시스템의 개발 비용을 추정하는 것으로 시작하여 가능한 편익과 비교 및 평가합니다.
비용 편익 분석의 목적은 소프트웨어 프로젝트가 경제적 관점 에서 실현 가능한지 여부를 평가하는 것입니다.
타당성 분석의 구체적인 단계 마지막 단계는 타당성 보고서를 준비하는 것 입니다.
타당성 조사는 주로 기술적 타당성 , 경제적 타당성 , 사회적 요인 타당성 및 운영 타당성 과 같은 측면에 중점을 둡니다 .
타당성 분석 비용에는 직접 비용 과 간접 비용이 포함되며 편익에는 유형 및 무형 편익이 포함됩니다 .
시스템 경제학은 새 시스템을 사용하여 얻은 수익 증가 와 새 시스템을 사용하여 얻은 운영 비용 절감액을 더한 것과 같습니다.
시스템의 경제적 이익은 화폐의 시간 가치 , 투자 회수 기간 및 순이익 과 같은 지표로 측정 할 수 있습니다.
순이익은 시스템의 누적 경제적 이익 과 소프트웨어 수명 주기 동안의 투자 간의 차이를 의미합니다.
투자 회수 기간은 누적된 경제적 이익이 초기 투자와 같아지는 데 필요한 시간 입니다.
소프트웨어 계획을 수립하는 프로세스는 소프트웨어 작업 범위 결정 , 개발에 필요한 리소스 추정 , 소프트웨어 비용 및 일정 추정을 필요로 합니다.
소프트웨어의 범위는 소프트웨어 시스템의 기능 , 소프트웨어 시스템의 성능 , 인터페이스 , 신뢰성을 포함합니다.
데이터 흐름 다이어그램은 "데이터 흐름 다이어그램" 또는 버블 다이어그램 이라고도 합니다.
데이터 흐름도의 일부 보조 다이어그램에서 기호 *는 한 쌍의 인접한 데이터 스트림이 동시에 나타남을 나타내고 +는 인접한 데이터 스트림 A 또는 B 또는 A와 B가 동시에 나타남을 나타내고 +는 원은 두 개의 데이터 스트림이 다음 중 하나만 사용함을 나타냅니다.
데이터 흐름도를 그릴 때 각 프로세스에는 최소한 하나의 입력 데이터 흐름과 하나의 출력 데이터 흐름이 있습니다.
데이터 흐름 그래프를 그릴 때 데이터 흐름 하위 그래프는 상위 계층의 프로세스 에 해당해야 합니다 . 데이터 흐름 다이어그램의 각 요소에는 이름이 있어야 합니다.
데이터 사전에는 데이터 흐름, 데이터 항목, 데이터 저장소 , 기본 처리, 데이터 소스 및 데이터 대상의 5가지 유형의 항목이 있습니다.
2. 선택
타당성은 시스템 솔루션 구현의 가능성 입니다.
타당성 조사는 경제, 기술, 운영, 법률 , 사회적 혜택 등 의 측면에서 수행됩니다.
소프트웨어를 개발할 때 소프트웨어 개발자의 생산성에 중요한 것은 프로그래머의 수 입니다.
소프트웨어 타당성 분석에서 소프트웨어 기능의 관점에서 타당성을 고려하는 것이 기술적 타당성 이며 기술적 위험의 문제를 해결해야 합니다.
타당성 조사에서 수행할 요구사항 분석 및 설계는 단순화되고 압축 되어야 합니다.
소프트웨어 시스템의 타당성 조사에는 경제적 타당성 , 기술적 타당성 및 사회적 타당성이 포함됩니다.
하드웨어 리소스의 가용성을 연구하는 것은 운영 타당성 조사를 수행하는 한 측면 입니다.
데이터 흐름 그래프, 컴퓨터에서 처리되는 구성 요소는 제어 흐름, 데이터 흐름, 노드 입니다.
구조화 분석법에서 사용하는 기술 도구 데이터 사전은 데이터 흐름도의 각 그래픽 요소를 정의합니다.
계층 적 DFD는 기술 방법이며 최상위 그래프는 시스템의 입력 및 출력을 설명합니다.
데이터 저장소와 데이터 흐름은 모두 다른 상태에서만 데이터 입니다.
데이터 사전에서 다음 옵션의 소스 및 대상 항목은 일반적으로 포함되지 않습니다.
데이터 필드는 데이터 정의 정보의 모음이며 여기에서 정의된 개체는 모두 데이터 흐름도를 포함합니다.
3. 단답형 질문
타당성 조사의 주요 쟁점은 무엇입니까?
타당성 조사의 업무는 소프트웨어 프로젝트의 수행 여부를 결정하고 기술적 타당성, 경제적 타당성, 사회적 타당성, 개발 계획의 타당성 및 운영 타당성을 분석하는 것입니다.
3. 수요 분석
1. 선택
수요 분석을 위한 다양한 도구를 사용할 수 있지만 PAD 는 해당되지 않습니다 .
ER 다이어그램에는 엔터티, 속성 및 관계 와 같은 기본 구성 요소가 포함됩니다.
소프트웨어 사양의 내용에는 알고리즘에 대한 자세한 설명이 포함되어서 는 안 됩니다.
구조화된 요구 사항 분석 방법의 기본 아이디어는 위에서 아래로 점진적으로 분해하는 것 입니다.
소프트웨어의 문제는 요구 사항 분석 단계 에서 보내어 수리 비용이 가장 저렴합니다.
2. 단답형
니즈 분석 단계
요구 사항 분석에는 획득, 모델링, 설명 및 검증의 4단계가 필요합니다. 요구사항을 얻는 것은 본질적으로 요구사항을 수집하는 과정으로 충분한 조사와 연구가 필요합니다. 일반적으로 현재 시스템에 포함된 데이터 분석, 정보 처리에서 현재 시스템의 결함 분석, 사용자가 개선하고자 하는 주요 문제 및 시급성 등을 분석하는 것으로 시작합니다. 일반적인 요구사항 수집 방법으로는 설문지, 인터뷰, 현장 운영, 시제품 제작 등이 있으며 수집된 요구사항은 주로 기능 요구사항, 성능 요구사항, 신뢰성 요구사항, 사용성, 인간-기계 인터페이스 요구사항, 제약 조건, 오류 처리 등입니다. 수요분석의 핵심업무는 분석모형의 수립, 즉 사용자의 수요정보를 분석, 추출, 유도, 추상화하여 대상시스템을 기술하는 모형을 수립하는 것이다. 전통적인 프로세스 지향 소프트웨어 엔지니어링 방법론은 주로 데이터 흐름 다이어그램을 사용하여 대상 시스템의 논리적 모델을 설정합니다. 요구사항 설명은 요구사항 분석 단계에서 각종 문서를 작성하는 것을 말합니다. 일반적으로 크고 복잡한 소프트웨어 시스템의 경우 요구 사항 분석 단계에서 시스템 정의 문서(사용자 요구 사항을 설명하는 데 사용되는 보고서), 시스템 요구 사항 사양 및 소프트웨어 요구 사항 사양의 세 가지 문서가 각각 다른 관점과 수준에서 생성됩니다. 프로젝트 개발을 위한 요구 사항. 간단한 소규모 소프트웨어 시스템의 경우 SRS를 컴파일하기만 하면 됩니다. 요구사항 분석 결과는 후속 개발의 중요한 근거이자 기반이기 때문에 소프트웨어 제품의 최종 품질을 향상시키고 개발 비용을 절감하기 위해서는 요구사항 분석 결과를 완전성, 일관성, 유효성 및 현실성이라는 네 가지 측면에서 분석해야 합니다. 오류의 원인을 추적할 수 없어 발생하는 혼란을 피하기 위해 정확성 확인 및 요구 사항 변경 소급 관리.
4. 전체적인 디자인
선택하다
데이터 흐름 중심 소프트웨어 설계 방법에서 정보 흐름은 일반적으로 변환 흐름과 트랜잭션 흐름으로 구분됩니다.
모듈식 기술을 사용하는 이점은 테스트 및 디버그가 쉽고, 소프트웨어 안정성 향상에 도움이 되고, 유지 관리 가능성이 향상되고, 소프트웨어 개발 공장을 구성 및 관리하는 데 도움이 된다는 것입니다(모두 선택).
소프트웨어 설계의 기본 원칙은 모듈 크기가 적당하고 정보 은폐 및 현지화라는 것입니다.
데이터 흐름 중심 설계 방법은 정보 흐름을 소프트웨어 구조로 매핑하는 것입니다.
소프트웨어의 전체 구조 설계, 최상위 팬아웃의 상한은 5-9 입니다.
5. 상세설계
1. 빈칸 채우기
구조적 프로그래밍 접근 방식의 약국은 시퀀스, 선택 및 루프 구조를 사용하는 것입니다.
구조화된 순서도를 생성하기 위해서는 순차적으로 결합되거나 완전히 중첩된 3개의 기본 제어 구조로 구성되어야 합니다.
PAD는 오른쪽으로 확장되는 2차원 트리 구조로 그림의 수직선은 프로그램의 계층적 선 입니다.
세부 설계 단계에서 프로그램의 논리적 구조를 설명하는 도구는 프로그램 흐름도
그래픽, 언어 및 표의 세 가지 도구가 일반적으로 프로세스를 자세히 설명하는 데 사용됩니다.
PDL에는 제어 구조, 데이터 구조 및 모듈 인터페이스 설계를 정의하기 위한 엄격한 키워드 외부 구문이 있습니다.
모듈에서 알고리즘을 설계하는 것 외에도 모듈에서 데이터 구조 도 설계 해야 합니다.
프로세스 설계에서 가장 대표적인 방법은 구조화된 설계, 하향식, 단계별 개선
SP 로 불리는 구조화된 프로그래밍 방식 , 문제 분석 다이어그램
NS 다이어그램은 구조화된 프로그램 논리 만 표현할 수 있습니다.
시스템의 상세 설계 단계에서 생성되는 문서가 상세 설계 사양서 입니다.
2. 선택
프로그래밍의 효율성과 품질을 높이기 위해 사용되는 방법은 구조화된 프로그래밍 입니다.
PAD의 제어 실행 흐름은 위에서 아래로, 왼쪽에서 오른쪽으로
소프트웨어 상세 설계에 사용되는 주요 방법은 구조화 설계 입니다.
PDL은 다음 언어로 된 의사 코드 입니다.
데이터 흐름 중심 설계 방법은 데이터 흐름을 소프트웨어 구조에 매핑합니다.
SC_ _
세부 설계의 과제는 각 모듈의 알고리즘을 결정하는 것입니다.
세부 설계 과정에서 사용되지 않는 설명 도구는 DFD 입니다.
PDL은 세부 설계를 위한 소프트웨어 개발 프로세스에 사용됩니다.
소프트웨어 복잡성 메트릭에 대한 매개변수에는 크기가 포함됩니다.
세부 설계 단계에서 자주 사용되는 도구는 PAD
Jackson 그래프의 상위 레이어와 하위 레이어의 관계는 구성 관계 입니다.
Jackson 방식은 데이터 구조를 기반으로 프로그램 구조를 도출하는 것입니다.
6. 소프트웨어 코딩 및 테스트
1. 선택
테스트 효율성을 높이기 위해서는 오류 발견 가능성이 높은 데이터를 테스트 데이터로 선택해야 합니다.
소프트웨어 테스트의 목적은 소프트웨어 오류를 찾는 것 입니다.
단위 테스트는 일반적으로 화이트 박스를 기반으로 하며 테스트 기반은 모듈 기능 사양 입니다.
소프트웨어의 통합 테스트는 소프트웨어 개발 그룹에 속하지 않은 소프트웨어 설계자가 가장 잘 수행합니다.
테스트에는 사용자 대표가 참여해야 합니다.
소프트웨어 테스트 케이스는 주로 입력 데이터와 예상 출력 결과 로 구성됩니다 .
블랙박스 테스트에서 입력 조건의 조합을 확인하는 데 중점을 둔 방법은 인과 그래프 방법 입니다.
블랙박스 테스팅은 사용자의 관점 에서 테스트하는 것이고 , 화이트박스 테스팅은 개발자 의 관점에서 테스트하는 것입니다.
로직 커버리지 방법이라고도 하는 화이트 박스 테스트 방법은 주로 단위 테스트 에 사용됩니다.
경계값 분석 테스트는 화이트 박스 테스트 기술이 아닙니다.
화이트 박스 테스트는 프로그램의 내부 로직을 기반으로 테스트 케이스를 설계하는 방법 입니다.
소프트웨어 디버깅의 목적은 오류가 발생한 위치를 찾아 수정하는 것 입니다.
2. 단답형 질문
소프트웨어 테스팅은 여러 단계로 나누어야 하는데 각 단계의 핵심 테스트 내용은 무엇인가?
소프트웨어 테스팅은 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅의 네 단계로 나눌 수 있습니다.
모듈 테스트 , 논리 테스트 또는 구조 테스트라고도 하는 단위 테스트는 프로그램 모듈 또는 기능 모듈과 같은 소프트웨어 설계의 가장 작은 단위의 정확성에 대한 테스트입니다. 그 목적은 각 프로그램 단위가 모듈 기능의 요구 사항, 성능, 인터페이스 및 세부 설계 사양의 설계 제약 조건을 올바르게 구현할 수 있는지 확인하고 각 모듈 내부에 존재할 수 있는 오류를 찾는 것입니다.
통합 테스트 는 어셈블리 테스트, 종합 테스트 또는 공동 테스트라고도 합니다. 일반적으로 모든 프로그램 모듈은 단위 테스트를 기반으로 순차적으로 점진적으로 테스트됩니다. 통합 테스트는 프로그램 단위 또는 구성 요소의 인터페이스 관계를 확인하고 점차적으로 개요 디자인의 요구 사항을 충족하는 프로그램 구성 요소 또는 전체 시스템에 통합합니다.
시스템 테스트 는 통합 하드웨어 및 소프트웨어 시스템을 테스트하여 시스템이 원래 목표를 달성하는지 확인하고 확인하는 것입니다. 시스템 테스트는 전체 프로그램 시스템이 올바르게 구성되고 시스템(컴퓨터 하드웨어, 주변 장치, 네트워크 및 시스템 소프트웨어, 지원 플랫폼 등 포함)과 연결될 수 있는지 여부를 확인하고 실제 또는 시뮬레이션 시스템 작동 환경에서 사용자 요구를 충족시키는 것입니다. . 시스템 테스팅의 주요 기반은 "시스템 요구 사양" 문서입니다.
전달 테스트 라고도 하는 인수 테스트는 소프트웨어가 단위 테스트, 통합 테스트 및 시스템 테스트를 완료한 후 제품 출시 전에 수행되는 소프트웨어 테스트 활동입니다. 인수 테스트는 다시 알파 테스트(A 테스트)와 베타 테스트(B 테스트)로 나뉘며, 알파 테스트는 개발 환경에서 사용자가 수행하는 테스트 또는 모의 실제 운영 환경에서 회사 내 사용자가 수행하는 제어 테스트입니다. , 베타 테스트는 한 명 이상의 사용자가 실제 사용 환경에서 소프트웨어의 여러 사용자가 수행하는 테스트입니다.
일곱, 객체지향 기술과 UML
1. 선택
액터가 잘못 말한 것은 액터가 유스 케이스 다이어그램의 필수 부분이므로 대상 시스템의 일부라는 것입니다 . (실제로 행위자는 대상 시스템의 필수 부분이 아니라 대상 시스템과 상호 작용하는 외부 엔터티입니다. 행위자는 대상 시스템과 상호 작용하여 충족하는 사람, 조직, 장치 또는 기타 시스템 등이 될 수 있습니다. 필요 또는 목표 달성)
상태 다이어그램에서 표현할 수 없는 개념은 클래스 입니다.
컴퓨터와 컴퓨터에 있는 cpu, ram 등의 관계는 aggregation 관계입니다 Aggregation
클래스 다이어그램은 객체지향 설계의 핵심인 시스템 클래스와 그 상호관계를 표현한 다이어그램이다.
상속은 클래스 간의 계층적 관계를 반영하는 반면 구성은 전체 부분 관계를 반영합니다.
UML 구조 의 일부가 아닌 개체는 대화식 입니다.
객체 지향 기능: 추상화, 캡슐화 라인. 상속, 다형성
실현 관계는 UML 다이어그램에서 점선으로 표시되고 흰색 삼각형은 다음을 가리킵니다.
구성도는 분산 시스템을 구성하는 노드 집합과 노드 간의 연결을 나타내는 다이어그램입니다.
유스 케이스와 클래스의 비교에서 클래스는 시스템의 내부 구조를 설명하고 유스 케이스는 시스템의 내부 구조가 잘못 되었음을 설명할 수도 있습니다 (유스 케이스는 시스템의 동적 동작 보기를 설명함).
인스턴스 링크는 개체 간의 정적 관계를 설명합니다.
2. 신청 관련 질문
항공기는 날개, 동체, 조종석으로 구성되어 있으며, 이는 결합관계로 관계도는 다음과 같다.
아래 클래스 다이어그램에서 Service 인터페이스에 세 가지 메서드가 정의되어 있습니다. 그 중 ClientA는 methodA 방식만, ClientB는 methodB 방식만, ClientC는 methodC 방식만 사용합니다. 인터페이스 분리 원칙에 따라 클래스 다이어그램 재설계
집합(Aggregation)과 조합(Composition)의 관계를 간략히 설명하고 예를 들어 설명한다.
거위 형성은 야생 거위로 구성되며 집합 관계에 속합니다.
1마리의 기러기는 2개의 날개를 가지고 있으며 결합 관계에 속합니다.
여덟, 객체 지향 분석
선택하다
캡슐화는 개체의 속성과 작업을 결합하여 독립적인 개체를 형성하는 것 입니다.
UML에는 종속성, 일반화, 연관 및 실현 의 4가지 관계가 있습니다.
유스케이스 모델 다이어그램은 사용자와 반복적으로 소통하고 확인해야 합니다.
사용 사례 간의 관계가 종속성이 아닙니다.
전자 상거래 사이트의 사용 사례로 적합하지 않은 옵션은 장바구니 입니다.
사용 사례 모델링은 사용자 와 반복적으로 통신하고 검증 되어야 합니다.
사용 사례에 대한 자세한 설명을 위해 활동 다이어그램을 사용해야 합니다.
UML의 시스템 분석에서 추가로 설정되는 세 가지 시스템 모델은 객체 정적 모델 , 객체 동적 모델 및 시스템 기능 모델입니다.
클래스와 개체 모두 속성이 있으며 클래스는 속성의 유형을 설명하고 개체의 속성에는 특정 값이 있어야 합니다.
시퀀스 다이어그램 및 협업 다이어그램은 주로 유스 케이스 다이어그램의 제어 흐름을 모델링 하고 유스 케이스 다이어그램의 동작을 설명하는 데 사용됩니다.
시퀀스 다이어그램의 모델링 요소에는 객체 , 메시지, 체인 등이 포함됩니다.
시퀀스 다이어그램은 개체 집합 간에 메시지가 전달되는 순서를 설명합니다.
시퀀스 다이어그램에서 반환 메시지의 기호는 점선 화살표 입니다.
상태 다이어그램은 수명 동안 개체 의 동작 , 경험한 상태 시퀀스 및 상태 전환을 유발하는 이벤트를 나타낼 수 있습니다.
상태 다이어그램은 다양한 이벤트 에 의해 구동되는 객체가 보낸 상태 전환을 설명합니다.
아홉, 객체지향 설계
선택하다
시스템 아키텍처는 부품의 구조, 인터페이스 및 통신에 사용하는 메커니즘을 설명하는 데 사용됩니다.
UML은 하드웨어와 하드웨어 단위의 소프트웨어 시스템 배포 간의 상호 연결을 설명할 수 있습니다.
소프트웨어 시스템 아키텍처는 시스템 사용 사례 클래스 개체 인터페이스와 상호 작용 및 협력에 대한 설명입니다.
하드웨어 시스템 아키텍처는 시스템 구성, 노드 및 구성에 대한 설명입니다.
구성 요소 는 소프트웨어 시스템 아키텍처에서 정의된 개념과 기능을 물리적 시스템에 구현한 것입니다.
배포 다이어그램은 프로세서, 장치 및 소프트웨어 빌드 런타임의 아키텍처를 설명하는 노드와 노드 간의 연결로 구성됩니다.
배치 다이어그램의 기본 요소는 노드입니다. 회원. 물체. 연결하다. 의지하다
패키지는 요소를 그룹으로 구성하기 위한 일반적인 메커니즘입니다.
UML 시스템 분석 단계에서 생성된 패키지 다이어그램은 시스템의 시스템 아키텍처 계층 구조를 설명합니다.