카테고리 없음

소프트웨어 설계

원2 2023. 2. 1. 21:45
728x90
반응형

소프트웨어 설계 유형

상위 설계 - 자료 구조, 아키텍처, 인터페이스, 프로시저, 협약

* 시스템 수준에서의 소프트웨어 구성 컴포너트들 간의 관계로 구성된 시스템의 전체적인 설계

하위 설계 - 모듈

* 시스템의 각 구성요소들의 내부 구조, 동적 행위 등을 결정하는 설계

 

3. 소프트웨어 설계 원리

 

상향식

- 하위기능들로부터 시작하여 제일 사우이에 있는 기능 main

- 인터페이스가 성립되어 있어야 기능 추가가 쉬움

ex) 기존 컴포넌트들을 조합하여 시스템을 개발하는 경우 

 

하향식

- 소프트웨어 설계 시 제일 사위에 있는 기능에서 시작, 기능을 하위 기능들로 분할해 가면  설계

- 레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필

- 통합 검사 시 인터페이스가 이미 정의되어 통합이 간단

ex) 시스템 명세가 명확한 경우와 모든 것을 새로 개발하는 작업에 적합

 

4. 코드 설계

개념 - 데이터의 분류나 조합을 쉽게 하기 위하여 사물을 표현

기능 - 표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출

 

표준화 - 정보의 종류, 모양, 크기 등의 일정한 기준에 따라 통일적으로 표현

분류 - 정보들을 동일한 틍성을 가진 데이터로 그룹화하여 나누는 기능

식별 - 다른 것과 구별

배열 - 일련의 순서로 나열

간소화 - 정보의 표현을 간소화

연상 - 정보를 표현하고자 하는 대상체 뜻과 의미가 코드에 내포

암호화 - 정보의 외부 표현을 감춤

오류 검출 - 정보 입력이나 관리 시 잘못된 정보를 찾음

 

종류- 연상, 블록, 순차, 표의 숫자, 십진, 그룹 분류

 

연상 코드 - 코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호 형태로 넣어 구성 (KR, US)

블록 코드 - 공통성이 있는 것끼리 블록으로 구분, 각 블록 내에서 일련번호를 부여 ( 010 - 0000 - 0000)

순차 코드 - 일정한 기준에 따라 순서대로 일련번호를 부여

표의 숫자 코드 - 대상 자료의 물리적인 수치, 길이 넓이, 용량 표시

십진 코드 - 10진수 형태

그룹 분류식 코드 - 대상을 기준에 따라 대, 중, 소분류로 구분 (학번 20XX - XXXXX)

 

설계 절차

항목 선정 -> 목적 설정 -> 대상 확인 -> 범위 결정 -> 사용 기간 설정 -> 항목의 특성 분석 -> 방식 결정 -> 문서화

 

오류 종류 - 사본, 전위ㅡ 생략, 첨가, 이중 전위

사본(필사, 오자) 오류 - 한 자리를 잘못 표기한 경우

전위 오류 - 연속된 두 글자가 서로 바뀌어 표기

생략 오류 - 한 글자를 빼먹고 기술

첨가 오류 - 한 글자를 추가되어 기술

이중 전위 오류 - 전위 오류가 중복 발생

 

8.HIPO

 - 시스템의 분석 및 설계, 문서화할 때 사용, 하향식 소프트웨어 개발을 위한 문서화 도구

 

특징

- 체계적인 문서 관리 가능

- 기호, 도표 등을 사용해서 보기가 쉽고 이해가 쉬움

- 기능과 자료의 의존 관계를 동시에 표현

- 변경, 유지보수가 용이

- 시스템의 기능을 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것이 HIPO chart

 

종류

가시적 도표 - 시스템의 전체적인 기능과 흐름을 보여주는 계층구조도

총체적 도표 - 입력, 처리, 출력에 대한 정보를 제공

세부적 도표 - 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술

 

// 소프트웨어 아키텍처

1. 개념

- 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성,

- 구성요소 간의 관계를 표현하는 시스템의 구조

- 소프트웨어를 설계하고 전개하기 위한 지침과 원칙

 

2. 필요성

- 소프트웨어 아키텍처를 활용, 주요 이해관계자들 간의 관점 조율을 통해 시스템 최적화

- 시스템의 비기능적인 요소에 중해서 만들어지지만 기능적인 요소도 고려

 

 

3. 소프트웨어 아키텍처 4 + 1 뷰

 

개념

- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근방법

- 4개의 분리 구조로 구성되는 아키텍처 개념을 제시, 4개의 구조가 서로 충돌되지 않는지,

 시스템의 요구사항을 충족 시키는지 증명하기 위해 체크 방법으로 유스케이스를 사용

 

구성

4 + 1 에서 1은 유스케이스 뷰, 4는 논리, 구현, 프로세스, 배포 뷰

유스케이스 뷰 - 유스케이스 또는 아키텍처를 도출, 설계하며 다른 뷰를 검증

                        - 외부 행위자에 의해 인식되는 시스템의 기능 요구사항을 보여주는데 초점

                        - 사용자, 설계자, 개발자, 테스트 관점

논리 뷰 - 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명

             - 설계자 개발자 관점

프로세스 뷰 - 시스템의 비그능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등

                    - 개발자, 시스템 통합자 관점

구현 뷰 - 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰

             - 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보를 정의

배포 뷰 - 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

             - 물리적 시스템을 구성하고 있는 각 부분들의 분산 형태와 설치에 초점

 

4. 소프트웨어 아키텍처 비용 평가 모델

개념

- 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가

종류

SAAM - 변경 용이성기능성에 집중, 평가가 용이, 경험이 없는 조직에서도 활용 가능한 비용 평가 모델

ATAM - 아키텍처 품질 속성을 만족 시키는지 판단 및 품질 속성들의 이해 상충까지 평가 ★

CBAM - ATAM 바탕, 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델

ADR - 소프트웨어 아키텍처 구성요소 간 응집도 평가

ARID - 특정 부분에 대한 품질요소에 집중

 

// 소프트웨어 아키텍처 패턴

개념

- 외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조

- 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식

- 주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션

 

유형 - 계층화, 클라이언트-서버, 파이프-필터, 브로커, 모델-뷰-컨트롤러, 마스터-슬레이브

계층화 패턴

  • 시스템을 계층(Layer)으로 구분
  • 각 하위 모듈들은 특정한 수준의 추상화를 제공, 각 계층은 다음 상위 계층에 서비스를 제공
  • 서로 마주 보는 두 개의 계층 사이에서만 상호 작용이 이루어짐

클라이언트-서버 패턴

  • 하나의 서버와 다수의 클라이언트로 구성
  • 사용자가 클라이언트를 통해서 서버에 서비스를 요청, 서버는 클라에게 서비스 제공
  • 서버는 계속 클라의 요청을 대기

파이프-필터 패턴

  • 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 단방향 패턴
  • 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
  • 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장이 용이하나, 필터 간 데이터 이동에서                                데이터 변환 오버헤드 발생

브로커 패턴

  • 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들은 원격 서비스 실행을 통해 상호작용이 가능
  • 컴포넌트 간의 통신을 조정하는 역할
  • 서버는 자신의 기능들을 브로커에 넘겨주며(Publish) 클라가 브로커에게 서비스를 요청하면 브로커는 클라를 자신의 레제스트리에 있는 적합한 서비스로 리다이렉션(Redirection)

모델-뷰-컨트롤러 패턴

  • 대화형 애플리케이션을 모델, 뷰, 컨트롤러 4개의 서브 시스템으로 구조화
  • 모델: 핵심 기능과 데이터 보관
  • 뷰 : 사용자에게 정보 표시(하나 이상의 뷰가 정의될수 있음)
  • 컨트롤러 : 사용자로부터 요청을 받아 처리/ 모델과 뷰 사이에서 전달자 역할을 수행
  • MVC 패턴은 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발가능
  • 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 하고, 여러 개의 뷰가 있어야 하는 대화형 어플에 적합

마스터-슬레이브 패턴

  • 연산, 통신, 조정을 책임지는 마스터 // 제어되고 동기화되는 대상 슬레이브
  • 일반적으로 실시간 시스템에 적용

6. 소프트웨어 아키텍처 품질 속성

  • 아키텍처 비용 평가를 위해 필요한 사항으로 특정 품질에 대한 요구사항을 명세한 내역, 최적의 아키텍처를 선택하기 위한 핵심 요소
  • 이해 관계자들의 품질 요구사항을 반영하여 결정

시스템 품질 속성 - 가용성, 변경 용이성, 성능, 보안성, 사용 편의성, 시험 용이성

비즈니스 품질 속성 - 시장 적시성, 비용과 이이그 시스템 프로젝트 생명주기, 목표 시장, 신규 발매 일정, 노후 시스템 통합

아키텍처 품질 속성 - 개념적 무결성, 정확성과 안정성

 

 

 

 

 

 

 

728x90
반응형