소프트웨어 요구사항 분석은 "무엇을 할 것인가"의 문제를 해결하는 반면, 소프트웨어 설계 프로세스는 "어떻게 할 것인가"의 문제를 해결합니다.

소프트웨어 설계는 소프트웨어 요구 사항을 소프트웨어 표현으로 변환하는 프로세스로, 주로 소프트웨어 아키텍처 설계 단계와 구성 요소 수준 설계의 두 단계로 구성됩니다.

디자인 접근법을 사용하면 소프트웨어 분석 모델에서 데이터, 기능 및 행동 모델로 표현되는 소프트웨어 요구 사항에 대한 정보가 디자인 단계로 전달되어 데이터/클래스 디자인, 아키텍처 디자인, 인터페이스 디자인, 컴포넌트 레벨 디자인이 됩니다.

데이터/클래스 설계: 분석 클래스 모델을 소프트웨어 구현에 필요한 클래스 구현 및 데이터 구조로 변환

아키텍처 디자인: 아키텍처 디자인은 소프트웨어의 전체 구조를 정의합니다.

인터페이스 디자인: 인터페이스 디자인은 소프트웨어 내, 소프트웨어와 협업 시스템 간, 소프트웨어 동료 간 통신 방법을 설명합니다.

구성 요소 수준 설계: 구성 요소 수준 설계는 소프트웨어 아키텍처의 구조적 요소를 소프트웨어 구성 요소의 절차적 설명으로 변환합니다.

소프트웨어 설계 과정에서 우리는 소프트웨어의 품질 요소에 세심한 주의를 기울여야 합니다.

McGlanghlin 소프트웨어 설계 프로세스의 목표는 다음과 같습니다.

1) 설계된 구조는 소프트웨어 구성요소 간의 제어를 확립하기 위한 계층적 구조이어야 한다.

2) 설계는 모듈식이어야 하며 소프트웨어를 특정 기능이나 하위 기능을 완성하는 구성 요소로 논리적으로 나누어야 합니다.

3) 설계에는 데이터 추상화와 프로세스 추상화가 모두 포함되어야 합니다.

4) 디자인은 독립적인 기능적 특성을 지닌 모듈을 구축해야 한다.

5) 모듈과 외부 환경 사이의 복잡한 연결을 줄이는 인터페이스를 설계해야 합니다.

6) 설계는 소프트웨어 요구사항 분석을 통해 얻은 정보를 기반으로 구동 가능하고 반복 가능한 방법을 수립할 수 있어야 합니다.

1) 사양 개발

2) 아키텍처 및 인터페이스 디자인

3) 데이터/클래스 설계

4) 컴포넌트 레벨(프로세스) 설계

5) 디자인 문서 작성

6) 설계 검토

추상화는 소프트웨어 설계 규모가 점차 증가함에 따라 복잡성을 제어하기 위한 기본 전략입니다.

점차적으로 세련됨을 구하라

모듈화, 즉 규정된 원칙에 따라 소프트웨어를 더 작고 독립적이지만 상호 연관된 구성 요소로 나누는 것은 실제로 시스템 분해 및 추상화 프로세스입니다.

모듈은 데이터 설명 및 실행 가능한 명령문과 같은 프로그램 개체의 모음입니다. 개별적으로 이름이 지정되고 이름으로 액세스할 수 있습니다.

예를 들어, 프로세스. 함수, 서브루틴, 매크로 등

각 모듈의 구현 세부정보는 다른 모듈에서 숨겨져야 합니다.

블록에 포함된 정보(데이터 및 프로시저 포함)는 이 정보가 필요하지 않은 다른 모듈에서 사용할 수 없습니다.

정보 은닉을 통해 모듈의 프로세스 세부 사항 및 로컬 데이터 구조에 대한 액세스 제한을 정의하고 시행할 수 있습니다.

기능적 독립성: 기능적 독립성은 모듈화, 추상화, 정보 은닉, 지역화와 같은 개념의 직접적인 결과입니다. 기능적으로 특정한 모듈을 개발하고 다른 모듈과의 과도한 상호 작용을 피함으로써 기능적 독립성을 달성할 수 있습니다.

기능적 독립성의 중요성

기능적 독립성은 응집성과 결합이라는 두 가지 지표로 측정할 수 있습니다.

① 이해관계자 커뮤니케이션 활성화

②시스템 설계 초기 의사결정에 도움

③전송 가능한 시스템 수준 추상화

공통 소프트웨어 아키텍처

대다수는 비교적 소수의 건축 스타일 중 하나로 분류될 수 있습니다.

각 스타일은 다음을 포함하는 시스템 범주를 설명합니다.

일부 데이터(예: 파일 또는 데이터베이스)는 구조의 중앙에 저장되며 다른 구성 요소에 의해 자주 사용, 추가, 삭제 또는 수정됩니다.

이 구조는 일련의 계산 또는 처리 구성요소에 의해 입력 데이터가 출력 데이터로 변환되는 데 적합합니다.

이 스타일을 사용하면 소프트웨어 디자이너는 수정 및 확장이 매우 쉬운 아키텍처를 설계할 수 있습니다.

포함: 메인 프로그램/서브 프로그램 스타일 아키텍처 및 원격 프로시저 호출 스타일 아키텍처

여기서 이해해야 할 몇 가지 개념이 있습니다.

시스템 구성 요소가 데이터를 캡슐화하고 데이터를 조작하는 방법

구성 요소 간의 상호 작용 및 조정은 메시지를 통해 전달됩니다.

이 구조에서는 서로 다른 레벨이 정의되며 각 레벨은 외부 레벨보다 기계 명령에 더 가까운 작업을 완료합니다.

동일한 소프트웨어 요구 사항에 대해 다양한 설계 방법의 서로 다른 원칙으로 인해 서로 다른 소프트웨어 구조가 파생됩니다.

동일한 문제에 대한 다른 소프트웨어 구조

1) 응용 시나리오(시나리오) 정의: 유스 케이스 다이어그램을 통해 사용자 관점에서 시스템을 표현합니다.

2) 요구 사항, 제약 조건 및 환경 설명 도출: 이는 모든 고객 우려 사항이 나열되어 있는지 확인하기 위한 요구 사항 엔지니어링의 일부입니다.

3) 위의 상황과 요구사항을 처리할 수 있는 아키텍처 스타일을 설명하세요.

4) 시스템의 각 성능을 개별적으로 평가합니다. 아키텍처 설계 성능에는 신뢰성, 성능, 보안, 유지 관리 가능성, 유연성, 테스트 가능성, 이식성, 재사용성 및 상호 운용성 등이 포함됩니다.

5) 다양한 건축 형태에 대해 4단계에서 언급한 성능의 민감도를 평가합니다. 전체 아키텍처에 약간의 변화를 주고, 어필 성능에 민감한 변화가 있는지 분석하고 판단하는 방식으로 평가할 수 있습니다. 아키텍처 변경에 의해 크게 영향을 받는 성능을 민감한 지점이라고 합니다.

6) 5단계의 민감도 분석을 통해 3단계에서 제안된 아키텍처를 평가합니다. SEI에서 설명하는 방법은 다음과 같습니다. 아키텍처의 민감한 지점이 결정되면 시스템에서 가장 많은 trade-off 지점(trade-off points)이 필요한 요소를 찾아야 합니다. 절충 요소는 아키텍처에서 이 내용을 변경하면 시스템 성능에 민감한 변화가 발생한다는 것을 의미합니다. 예를 들어, 클라이언트-서버 구조를 갖는 시스템의 성능은 시스템의 서버 수와 ​​밀접한 관련이 있습니다(예를 들어 서버 수를 늘리면 시스템 성능이 어느 정도 향상됩니다)... 에 이 경우 서버 수는 아키텍처의 균형점입니다.

(1) 소프트웨어 구조 개선 및 모듈 독립성 향상

(2) 모듈의 적절한 깊이, 너비, 팬아웃 및 팬인

(3) 모듈의 판단 범위는 제어 범위 내에 있어야 합니다.

(4) 모듈 인터페이스의 복잡성을 줄이기 위해 노력하십시오.

(5) 출입구가 1개인 모듈을 설계한다.

(6) 모듈 기능은 예측 가능해야 하며 모듈 크기는 적당해야 합니다.

(7) 일반적으로 모듈에는 30~50개 정도의 명령문이 포함되는 것이 좋습니다.

(8) 잘 설계된 소프트웨어 구조는 일반적으로 최상위 계층에서 팬아웃이 더 높고, 중간 계층에서 팬아웃이 적으며, 최하위 계층에서 팬인이 높습니다.

각 구성 요소에 사용되는 알고리즘을 결정하고, 알고리즘 프로세스를 표현하는 데 적합한 도구를 선택하고, 구성 요소에 대한 자세한 절차 설명을 작성합니다.

각 구성 요소에서 내부적으로 사용되는 데이터 구조를 결정합니다.

컴포넌트 레벨 설계가 끝나면 위의 결과를 컴포넌트 레벨 설계 사양에 기록하고 검토를 거쳐 정식 문서로 작성해야 하며, 이는 다음 단계(코딩 단계)의 기초가 됩니다.

더 대중적인 정의는 다음과 같습니다. "프로그램의 코드 블록이 시퀀스, 선택 및 루프의 세 가지 기본 제어 구조를 통해서만 연결되고 각 코드 블록에 하나의 항목과 하나의 종료만 있는 경우 프로그램은 구조화되었다고 합니다. . 의"

객체지향, 소프트웨어 재사용 등 새로운 소프트웨어 개발 방식과 기술이 발전함에 따라, 하향식 방식과 상향식 방식을 유기적으로 결합하는 것이 보다 현실적이고 효과적인 개발 접근 방식이 될 수 있습니다.

프로그램 흐름도

N-S 다이어그램

인주

알고리즘에 여러 중첩 조건 선택이 포함되어 있으면 프로그램 흐름도, N-S 다이어그램 또는 PAD를 사용하여 명확하게 설명하기가 어렵습니다.

그러나 의사결정 테이블은 조건의 복잡한 조합과 취해야 하는 조치 사이의 일치성을 명확하게 표현할 수 있습니다.

의사결정 테이블의 장점은 모든 처리 규칙을 간결하고 명확하게 설명할 수 있다는 것입니다.

그러나 의사결정 테이블은 특정 조건 값의 조합에서 가능한 결과인 정적 논리를 나타냅니다. 이는 처리 순서를 표현할 수 없고 루프 구조를 표현할 수도 없습니다.

PDL(Program Design Language)은 알고리즘 설계와 기능적 구성 요소의 처리 세부 사항을 기술하는 데 사용되는 언어로, 설계 언어라고 합니다.

일종의 의사코드이다. 일반적으로 의사 코드의 문법 규칙은 "외부 문법"과 "내부 문법"으로 구분됩니다.

PDL 사용 예

PDL 기능

소프트웨어 설계의 궁극적인 목표는 최상의 솔루션을 얻는 것입니다.

"Best"는 모든 후보 솔루션 중에서 개발 비용 절감, 리소스 소비 감소, 개발 시간 단축이라는 조건에 따라 더 높은 생산성, 더 높은 신뢰성 및 유지 관리성을 달성할 수 있는 솔루션을 선택하는 것을 의미합니다.

디자인 리뷰 내용

검토에는 공식 검토와 비공식 검토의 두 가지 유형이 있습니다.