건축학
장면
시나리오 아키텍처 평가를 수행할 때 일반적으로 특정 품질 목표를 먼저 정확하게 획득하고 이를 아키텍처 품질을 결정하는 표준으로 사용하는 것이 필요합니다. 이러한 목표를 도출하는 데 사용되는 메커니즘의 시나리오입니다. 시나리오는 이해관계자의 관점에서 시스템과의 상호 작용에 대한 간략한 설명입니다. 건축 평가에서는 일반적으로 자극, 환경, 반응의 세 가지 측면을 사용하여 장면을 설명합니다.
시스템 구조(아키텍처) 평가를 수행할 때 일반적으로 먼저 구체적인 품질 목표를 정확하게 획득하고 이를 아키텍처의 품질을 결정하는 표준으로 활용하는 것이 필요합니다. 우리는 이러한 목표 시나리오에 도달하는 데 사용되는 메커니즘을 호출합니다. 시나리오는 이해관계자의 관점에서 시스템과의 상호 작용에 대한 간략한 설명입니다. 건축 평가에서 장면은 일반적으로 자극, 환경, 반응의 세 가지 측면으로 설명됩니다. 자극은 이해 관계자가 시스템과의 상호 작용을 트리거하는 방법을 설명하거나 설명하는 시나리오의 일부입니다. 예를 들어, 사용자가 특정 기능을 활성화하고, 유지 관리를 통해 특정 변경이 이루어지며, 테스터가 특정 테스트를 수행할 수 있으며, 이러한 것들은 모두 시나리오에 대한 자극입니다. 환경은 자극이 발생하는 상황을 설명합니다. 예를 들어, 시스템의 현재 상태는 무엇입니까? 특별한 제약이 있나요? 시스템에 과부하가 걸리나요? 특정 네트워크 채널의 차단 여부 등 응답은 시스템이 아키텍처를 통해 자극에 어떻게 반응하는지를 의미합니다. 예를 들어 사용자가 요청한 기능이 충족되었는지, 관리자의 수정이 성공했는지, 테스터의 테스트가 성공했는지 등을 말합니다.
소프트웨어
소프트웨어 재사용
수직적 재사용과 수평적 재사용으로 구분됩니다.
- 수직적 재사용이란 전력계통에만 사용되는 부품 등 특정 수직장에 국한된 재사용을 말한다.
- 수평적 재사용이란 표준 함수 라이브러리 등 일반 분야에서 재사용하는 것을 말하며 어떤 소프트웨어에서도 사용할 수 있으므로 수평적 재사용이다.
소프트웨어 재사용
소프트웨어 재사용 프로세스: 생성, 재사용, 지원, 관리의 4가지 프로세스
- 생성: 재사용자의 요구 사항을 충족하기 위해 재사용 가능한 자산을 정의하고 제공합니다.
- 재사용: 재사용 가능한 자산을 사용하여 응용 프로그램 소프트웨어 제품 생산
- 지원: 재사용 가능한 자산의 획득, 관리 및 유지 관리에 대한 포괄적인 지원
- 관리: 계획 실행, 출시, 리소스, 추적 및 기타 프로세스 조정
SDE
소프트웨어 개발 환경(SDE)은 소프트웨어의 엔지니어링 개발 및 유지 관리를 지원하는 데 사용되는 소프트웨어 세트를 말하며, 소프트웨어 도구 세트와 환경 통합 메커니즘으로 구성됩니다.
소프트웨어 개발 환경은 플랫폼 통합, 데이터 통합, 인터페이스 통합, 제어 통합 및 프로세스 통합과 같은 다양한 통합 메커니즘을 지원해야 합니다. 소프트웨어 개발 환경은 팀의 작업 스타일을 지원하고 구성 관리를 제공해야 하며, 환경의 서비스는 분석, 설계, 프로그래밍, 디버깅 및 문서화를 포함한 다양한 소프트웨어 개발 활동을 지원하는 데 사용될 수 있습니다. 보다 완전한 소프트웨어 개발 환경은 일반적으로 소프트웨어 개발의 일관성 및 무결성 유지, 구성 관리 및 버전 제어, 데이터의 다중 표현 및 서로 다른 형식 간의 자동 변환, 정보 자동 변환과 같은 다양한 기능을 갖습니다. 검색 및 업데이트, 프로젝트 제어 및 관리, 개발 방법론 지원. 소프트웨어 개발 환경은 통합성, 개방성, 확장성, 데이터 형식 일관성, 통일된 사용자 인터페이스 스타일 등의 특성을 갖고 있어 소프트웨어 생산성을 크게 향상시킬 수 있습니다.
소프트웨어 개발 환경은 다양한 통합 메커니즘을 지원해야 하며 다양한 기능에 따라 통합 메커니즘은 환경 정보 라이브러리, 프로세스 제어 및 메시지 서버, 환경 사용자 인터페이스의 세 부분으로 나눌 수 있습니다.
- 환경 정보 기반. 환경정보베이스는 소프트웨어 개발 환경의 핵심으로, 시스템 개발과 관련된 정보를 저장하고 정보 교환 및 공유를 지원하는 데 사용됩니다. 환경정보 데이터베이스는 크게 두 가지 정보를 저장하는데, 하나는 개발 과정에서 생성되는 분석문서, 설계문서, 테스트 보고서 등 개발 중인 시스템에 대한 정보이고, 다른 하나는 시스템에서 제공하는 지원정보이다. 문서 템플릿, 시스템 구성, 프로세스 모델 및 재사용 가능한 구성 요소 등과 같은 환경
- 프로세스 제어 및 메시지 서버. 프로세스 제어 및 메시지 서버는 프로세스 통합 및 제어 통합을 실현하기 위한 기반입니다. 프로세스 통합 중에 특정 소프트웨어 개발 프로세스의 요구 사항에 따라 도구가 선택되고 결합되며, 제어 통합을 통해 도구 간의 병렬 통신 및 협업이 가능해집니다.
- 주변 사용자 인터페이스. 환경 사용자 인터페이스에는 전체 환경 인터페이스와 이에 의해 균일하게 제어되는 다양한 환경 구성 요소 및 도구의 인터페이스가 포함됩니다. 통일되고 일관된 사용자 인터페이스는 소프트웨어 개발 환경의 중요한 기능으로, 환경의 장점을 최대한 활용하고 도구를 효율적으로 사용하며 사용자의 학습 부담을 줄이는 것을 보장합니다.
도구
소프트웨어 시스템 도구의 종류는 다양하며 통일된 분류 방법을 갖기가 어렵습니다. 소프트웨어 도구는 일반적으로 소프트웨어 프로세스 활동에 따라 소프트웨어 개발 도구, 소프트웨어 유지 관리 도구, 소프트웨어 관리 및 소프트웨어 지원 도구로 나눌 수 있습니다.
- 소프트웨어 개발 도구: 요구사항 분석 도구, 설계 도구, 코딩 및 디버깅 도구.
- 소프트웨어 유지 관리 도구: 버전 제어 도구, 문서 분석 도구, 개발 정보 기반 도구, 리버스 엔지니어링 도구 및 리엔지니어링 도구.
- 소프트웨어 관리 및 소프트웨어 지원 도구: 프로젝트 관리 도구, 구성 관리 도구, 소프트웨어 평가 도구 및 소프트웨어 개발 도구의 평가 및 선택.
문서
예비 프로젝트 범위 기술서에 문서화된 주요 결과물, 가정 및 제약 조건을 기반으로 상세한 프로젝트 범위 기술서를 준비하는 것은 프로젝트 성공에 매우 중요합니다. 범위 정의에 대한 입력에는 다음이 포함됩니다. ① 프로젝트 헌장. 프로젝트 헌장이나 초기 범위기술서가 프로젝트 실행 조직 내에서 사용되지 않는 경우, 상세한 프로젝트 범위기술서를 생성하기 위해 동일한 정보를 추가로 수집하고 개발해야 합니다. ② 사업범위관리계획. ③ 조직 프로세스 자산. ④ 변경신청을 승인합니다.
문서 관리 규칙 및 방법 정보 시스템 문서의 표준화된 관리는 주로 문서 작성 사양, 차트 번호 매기기 규칙, 문서 카탈로그 작성 표준 및 문서 관리 시스템과 같은 여러 측면에 반영됩니다.
사용자 문서
사용자 문서는 주로 제공되는 시스템의 기능과 사용법을 설명하며 이러한 기능이 어떻게 구현되는지는 중요하지 않습니다. 사용자 문서는 시스템을 이해하는 첫 번째 단계이며 이를 통해 사용자는 시스템에 대한 정확한 초기 인상을 얻을 수 있습니다. 사용자 문서에는 최소한 다음 5가지 측면이 포함되어야 합니다.
기능 설명: 시스템이 수행할 수 있는 작업을 설명합니다.
설치 문서: 시스템을 설치하는 방법과 특정 하드웨어 구성에 시스템을 적용하는 방법을 설명합니다. 사용자
설명서: 시스템 사용을 시작하는 방법을 간략하게 설명합니다. (일반적으로 사용되는 시스템 기능의 사용법, 사용자 조작 오류를 복구하고 다시 시작하는 방법에 대한 예제를 풍부하게 함)
참고 매뉴얼: 사용자가 사용할 수 있는 모든 시스템 기능과 사용법에 대한 자세한 설명, 발생할 수 있는 다양한 문제 설명 시스템에서 오류 메시지의 의미(참조 매뉴얼의 주요 요구 사항은 완전성이므로 일반적으로 형식적인 설명 기술이 사용됩니다.)
운영자 가이드(시스템 운영자가 필요한 경우): 운영 중에 발생하는 다양한 상황을 운영자가 어떻게 처리해야 하는지 설명합니다. . 시스템 문서는 문제 정의, 요구사항 설명, 승인 테스트 계획에 이르기까지 시스템 구현과 관련된 일련의 문서입니다. 시스템의 설계, 구현 및 테스트를 설명하는 문서는 프로그램을 이해하고 유지하는 데 필수적입니다.
시스템 문서
구성 항목
소프트웨어 제품 구성은 라이프사이클의 다양한 단계에서 소프트웨어 제품이 생성한 다양한 형태와 버전 의 문서, 컴퓨터 프로그램, 구성 요소 및 데이터의 집합을 의미합니다. 이 세트의 각 요소를 제품 구성의 구성 항목이라고 합니다.
구성 항목은 제품 구성을 구성하는 주요 요소로, 구성 항목은 크게 다음 두 가지 범주로 나뉩니다.
- 제품의 일부인 작업 결과: 요구 사항 문서, 설계 문서, 소스 코드 및 테스트 사례 등
- 작업 계획, 프로젝트 품질 보고서, 프로젝트 추적 보고서 등 프로젝트 관리 및 조직 지원 프로세스 영역에서 생성된 문서입니다. 이러한 문서는 제품의 일부는 아니지만 보관할 가치가 있습니다.
구성 항목의 상태에는 일반적으로 초안, 공식 출시 및 수정 중이 포함됩니다.
관리 도구
소프트웨어 형상관리 도구란 형상항목 식별, 버전관리, 변경통제, 감사, 상태통계 등의 업무를 지원하는 도구를 말하며 주로 다음과 같은 기능을 갖는다.
- 구성 지원: 구성은 공통 목적을 가진 중간 소프트웨어 제품 그룹으로, 각 제품을 구성 항목이라고 합니다. 소프트웨어 구성 관리는 사용자가 구성 항목 간의 다양한 관계를 설정하고 이러한 관계를 유지하도록 지원합니다. 이러한 관계를 유지하면 특정 작업(예: 빌드)을 완료하고 특정 변경이 전체 시스템 개발에 미치는 영향을 식별하는 데 도움이 됩니다.
- 버전 관리: 버전 관리는 소프트웨어 구성 관리의 기본 요구 사항으로 언제든지 모든 버전을 복원할 수 있습니다. 또한 버전 관리는 각 구성 항목의 개발 내역을 기록하므로 버전 간의 추적성을 보장하고 버그 찾기에 도움이 됩니다. , 버전 제어는 병렬 개발을 지원하는 데 필수적입니다.
- 변경 통제: 소프트웨어 수명 주기 전반에 걸쳐 소프트웨어 변경을 통제하는 것을 말합니다. 변경 관리 시스템은 각 변경에 대한 관련 정보(변경 이유, 변경 실행자, 변경 내용 등)를 기록합니다. 이 정보는 발생하는 다양한 문제를 추적하는 데 도움이 됩니다.
- 구축 지원: 소프트웨어 시스템은 많은 구성 항목으로 구성되는 경우가 많습니다. 전체 시스템을 구축하는 것은 복잡하고 시간이 많이 걸리는 프로세스입니다. 소프트웨어 구성 관리 도구는 각 구성 항목의 정보를 기록하고 추적하여 사용자가 시스템을 자동으로 신속하게 구축할 수 있도록 도와줍니다. 버전 관리와 결합되어 시스템의 여러 버전에 대한 동시 개발을 효율적으로 지원할 수 있습니다.
- 프로세스 지원. 프로세스는 소프트웨어 수명주기 전반에 걸쳐 다양한 사람들이 전체 시스템을 사용하는 방법을 자세히 설명하고 프로세스 제어를 통해 각 단계가 적절한 사람에 의해 올바른 순서로 구현되도록 보장합니다. 프로세스 제어는 원래 소프트웨어 개발 환경의 독립적인 부분이었으며, 소프트웨어 구성 관리도 이 부분의 기능을 제공하기 시작했습니다. 소프트웨어 구성 관리 도구는 프로세스를 완전히 지원하지 않으며 지원 방법도 매우 다양합니다. 많은 관리 도구는 사전 정의된 수명 주기 모델만 제공하고 모든 개발 단계가 이 모델의 조항에 따라 수행되도록 보장합니다.
- 팀 지원. 팀 지원은 여러 개발자가 소프트웨어 시스템을 동시에 개발하는 것을 의미합니다. 대부분의 소프트웨어 시스템에는 여러 개발자의 참여가 필요하며 효과적인 팀 지원은 개발자에게 매우 유용합니다. 팀 지원에는 주로 작업 공간 관리, 병렬 개발 관리 및 원격 개발 관리가 포함됩니다(일부 소프트웨어 구성 관리 도구에는 개발자 지원도 포함됨).
시험
통합 테스트
소프트웨어 통합 테스트는 어셈블리 테스트 및 공동 테스트라고도 합니다(하위 시스템의 경우 구성 요소 테스트라고 함). 단위 테스트를 통과한 모듈을 통합하고, 주로 모듈 간의 협업을 테스트합니다.
조립 전략 측면에서 일회성 조립 테스트와 증분 조립 (하향식, 상향식 및 하이브리드 포함)의 두 가지 유형으로 나눌 수 있습니다. 통합 테스트 계획은 일반적으로 소프트웨어 개요 설계 단계에서 완료되며 통합 테스트는 일반적으로 블랙 박스 테스트 방법을 사용합니다.
예
특정 참가자가 볼 수 있는 가치 결과를 생성하는 시스템에서 수행되는 일련의 작업입니다. 이는 시스템 참가자와 상호 작용하고 시스템에서 실행할 수 있는 일련의 작업을 식별합니다. 유스케이스 모델은 외부 행위자(Actors)가 이해하는 시스템 기능을 설명합니다. 유스케이스 모델은 요구사항 분석 단계에서 사용되며, 요구사항 사양에 대해 개발자와 사용자가 합의한 내용을 나타내는 시스템 개발자와 사용자 간의 반복적인 논의의 결과로 구축됩니다. 두 사용 사례 간의 관계에는 두 가지 주요 상황이 있습니다. 하나는 스테레오타입 include로 표시되는 재사용을 위한 포함 관계이고, 다른 하나는 스테레오타입 확장으로 표시되는 다양한 동작을 분리하는 데 사용되는 확장입니다.
①포함관계: 둘 이상의 원래 유스케이스에서 공통적인 행위를 추출할 수 있거나, 유스케이스 기능의 일부를 구현하기 위해 컴포넌트를 사용하는 것이 중요하다고 판단되는 경우, 이를 표현하기 위해 포함관계를 사용해야 한다.
②확장 관계: 하나의 유스케이스가 두 개 이상의 서로 다른 시나리오를 명백하게 혼합하는 경우, 즉 상황에 따라 여러 가지 일이 발생할 수 있는 경우, 이 유스케이스를 주 유스케이스와 하나 이상의 보조 유스케이스로 구분하는 것이 가능하다고 결론 내릴 수 있다. 더 설명적이고 명확합니다.
소프트웨어 품질
소프트웨어 품질은 특정 또는 묵시적 요구 사항을 충족하는 소프트웨어 시스템 또는 소프트웨어 제품의 능력을 반영하는 전반적인 특성 및 특성을 나타냅니다. 소프트웨어 품질 관리는 소프트웨어 개발 프로세스의 독립적인 검사 활동을 말하며 품질 보증, 품질 계획 및 품질 관리의 세 가지 주요 활동으로 구성됩니다 . 소프트웨어 품질 보증이란 소프트웨어 시스템이나 소프트웨어 제품의 품질이 사용자 요구 사항을 완벽하게 충족하는지 확인하기 위해 수행되는 계획적이고 조직적인 활동을 말하며, 고품질 소프트웨어를 생산하는 것이 목적입니다. 소프트웨어 검토는 소프트웨어 품질 보증의 주요 활동 중 하나입니다.
사용자 인터페이스 디자인
사용자 인터페이스 디자인의 기본 원칙은 실습을 통해 요약된 몇 가지 디자인 규칙입니다. 테오 마이델(Theo Maiidel)은 인터페이스 디자인에 관한 자신의 저서에서 3가지 "황금률"을 제안했습니다.
- 사용자에게 제어권 부여: 사용자는 컴퓨터에 의해 제어되기보다는 컴퓨터를 제어하기를 원하므로 인간-컴퓨터 인터페이스를 설계할 때 다음 원칙을 따라야 합니다. 상호 작용 모드의 정의는 사용자에게 불필요하거나 원치 않는 작업을 강요할 수 없습니다. 유연한 상호 작용 제공, 사용자 상호 작용을 중단하거나 취소할 수 있음, 기술 수준이 높아짐에 따라 상호 작용을 간소화하고 맞춤형 상호 작용 허용, 사용자가 내부 기술 세부 정보를 격리할 수 있음
- 사용자의 메모리 부담 감소: 사용자가 기억해야 할 사항이 많을수록 시스템과 상호 작용할 때 오류가 발생할 가능성이 커지므로 좋은 사용자 인터페이스 디자인은 사용자의 메모리 부담을 증가시키지 않아야 합니다. 사용자 메모리 부하를 줄이기 위한 설계 원칙은 단기 메모리에 대한 요구 사항 감소, 의미 있는 기본값 설정, 직관적인 단축키 정의, 인터페이스의 시각적 레이아웃은 실제 메타포를 기반으로 해야 하며 점진적인 방식으로 정보를 제공하는 것입니다.
- 인터페이스 일관성 유지: 사용자는 일관된 방식으로 정보를 제공하고 액세스해야 합니다. 즉, 모든 시각적 정보는 통일된 디자인 표준에 따라 구성되고 모든 화면 디스플레이는 이 표준을 준수해야 합니다. 입력 메커니즘은 제한된 세트로 제한되어 소프트웨어 시스템 전체에서 일관되게 사용되는 반면, 작업 간 탐색 메커니즘은 일관되게 정의되고 구현됩니다. 인터페이스 일관성을 유지하기 위한 디자인 원칙에는 사용자가 현재 작업을 의미 있는 컨텍스트에 배치할 수 있도록 허용하고, 애플리케이션 제품군 내에서 일관성을 유지하며, 사용자가 이미 익숙한 사용자 상호 작용 모델을 변경하지 않는 것이 포함됩니다.
EJB
EJB는 세션 빈(Session Bean), 엔터티 빈(Entity Bean), 메시지 중심 빈(Message-Driven Bean)으로 구분됩니다. 1. 세션 빈(Session Bean): 비즈니스 로직을 구현하는 데 사용되며 상태 저장형이거나 상태 비저장형일 수 있습니다. 클라이언트가 요청할 때마다 컨테이너는 클라이언트에 서비스를 제공할 세션 Bean을 선택합니다. 세션 Bean은 데이터베이스에 직접 액세스할 수 있지만 엔터티 Bean을 통해 데이터 액세스를 달성하는 경우가 더 많습니다. 2. Entity Bean: 데이터베이스의 테이블 레코드를 메모리의 엔터티 객체에 매핑하는 O/R 매핑을 구현하는 데 사용됩니다. 실제로 엔터티 Bean 객체를 생성하는 것은 새 레코드를 생성하는 것과 같습니다. 엔터티 Bean을 삭제하면 또한 제거됩니다. 데이터베이스의 레코드를 삭제하고 엔터티 빈을 수정하면 컨테이너는 엔터티 빈의 상태를 데이터베이스와 자동으로 동기화합니다. 3. Message-Driven Bean은 EJB3.0에 도입된 새로운 Enterprise Bean으로 JMS 메시지를 기반으로 하며 클라이언트가 보낸 JMS 메시지만 수신하고 처리할 수 있습니다. MDB는 실제로 비동기식 Stateless Session Bean으로, 클라이언트는 MDB 호출 후 기다릴 필요 없이 즉시 반환되며, MDB는 고객 요청을 비동기식으로 처리합니다. 이는 주문 처리와 같이 요청을 비동기적으로 처리해야 하는 상황에 적합합니다. 이를 통해 클라이언트가 메서드 호출이 결과를 반환할 때까지 오랫동안 기다리지 않도록 할 수 있습니다.
안전
재생 공격
재생 공격(Replay Attack), 재생 공격(Replay Attack), 신선도 공격(Freshness Attack)이라고도 알려진 재생 공격(Replay Attack)은 공격자가 시스템을 속이려는 목적을 달성하기 위해 대상 호스트에서 수신한 패킷을 보내는 것을 말하며 주로 신원 인증 과정에서 사용된다. 인증의 정확성을 파괴합니다. Kerberos 시스템에서는 재생 공격을 방지하기 위해 타임스탬프 방식을 사용하는데, 이 방식에서는 전송되는 데이터 패킷에 타임스탬프를 부여하고, 서버는 이를 기반으로 재생 패킷인지 여부를 판단하여 재생 공격을 방지할 수 있습니다.