소프트웨어 생명주기

  • 알고리즘 설계는 소프트웨어 설계 단계에 해당한다

  • 프로그래밍 언어를 선택하여 알고리즘에 대해 코딩하는 것은 소프트웨어 구현 단계

  • 소프트웨어 생명주기 단계

    1. 개발 타당성 검토
    2. 개발 계획 수립
    3. 요구사항 분석
    4. 소프트웨어 설계
    5. 소프트웨어 구현
    6. 테스트
    7. 운용
    8. 유지보수

소프트웨어 관리

  • 요구 관리
    • 고객 요구를 정확하게 추출 및 문서화
    • 고객과 개발자가 상호 동의하는 과정에 대한 관리
  • 형상 관리
    • 소프트웨어 개발 및 유지보수 과정 중 발생하는 산출물들을 시간 흐름에 따라 시스템 형상을 만들어 가는 것
    • 소프트웨어 버전을 체계적으로 관리
  • 유지 관리
    • 소프트웨어 개발 후 고객이 사용하는 과정 중 변경 사항이 발생할 경우 소프트웨어를 수정하는 것
    • 고객이 소프트웨어를 지속적으로 잘 사용하도록함
  • 품질 관리
    • 개발된 소프트웨어가 원래의 개발 목적에 부합하며 요구를 만족하는지 검증

소프트웨어 품질 관리

  • 기능성(funcionality)
    • 고객이 요구하는 기능을 소프트웨어가 충분히 제공하고 있는가
    • 제공하는 기능이 표준을 잘 지키며 보안이 잘 이루어지는가
  • 사용성(usability)
    • 소프트웨어를 고객이 사용하기에 어렵지 않은가
    • 사용자 인터페이스에 일관성이 있고 기능 확장과 축소가 용이한가
  • 신뢰성(reliability)
    • 소프트웨어를 운용할 때 크고 작은 오류가 발생하지 않는가
    • 오류 발생에서 즉시 회복할 수 있고 서비스 중단이 일어나지 않는가
  • 유지보수성(maintainability)
    • 소프트웨어 운영환경이 일부 변경되어도 지속적인 운영이 가능한가
    • 소프트웨어 업그레이드가 꾸준히 제공되는가
  • 이식성(portability)
    • 기존 시스템에서 제거하여 다른 시스템으로 옮기는 것이 용이한가
    • 시스템 환경을 바꾸어도 소프트웨어는 여전히 운용될 수 있는가
  • 효율성(efficiency)
    • 소프트웨어가 소비하는 컴퓨팅 자원이 효율적인가
    • 소프트웨어의 반응시간이 고객의 예쌍보다 느리지 않은가

알고리즘의 효율성

  • 공간 효율성
    • 알고리즘을 실행하는 동안 알고리즘이 필요로 하는 메모리 공간(컴퓨팅 자원)의 효율성을 말한다
    • 고정공간(알고리즘이 기본적으로 소모하는 공간) + 가변공간(알고리즘 실행 후 입출력 크기에 따라 추가로 늘어가는 공간)
  • 시간 효율성
    • 알고리즘 실행 후 종료까지 걸리는 시간의 효율성
    • 번역 시간 + 실행시간
  • 빅오(Big O) 표기법

소프트웨어 아키텍처

  • 개발하려는 소프트웨어의 전체 골격에 대한 논리적 구조
  • 전체 소프트웨어에 앞으로 적용할 원칙들의 총집합체
  • 소프트웨어 아키텍처는 어플리케이션 개발 모델이라 불림
  • MVC, C/S, 다층 구조, 저장소 ㅗ구조가 있다.

MVC 구조

  • 어플리케이션을 Model, View, Controller로 구분함
  • 사용자 인터페이스와 비즈니스 로직을 상호 분리하여 개발하는 구조

  • Model

    • 자신의 상태가 바뀔 때 마다 컨트롤러와 뷰에게 알려준다

  • View

    • 모델로부터 정보를 얻어 와서 사용자에게 출력물을 보여줌

  • Controller

    • 모델과 뷰에게 명령을 보낼 수 잇음
    • 모델의 경우 모델의 상태가 바뀜
    • 뷰의 경우 모델에 의한 뷰 표시 방법은 변경할 수 있음

  • gui를 사용하는 어플리케이션 개발 모델에서 많이 사용

  • 사용자 인터페이스와 비즈니스 논리를 상호 독립적 구성요소로 변경할 수 잇는 장점을 제공

C/S 구조

  • 서비스를 요구하는 클라이언트
  • 서비스를 제공하는 서버
  • C/S 구조는 네트워크 기반의 분산 소프트웨어 아키텍처에 주로 적용도니다
  • 웹브라이저가 클라이언트, 웹 서버가 서버에 해당
  • 클라이언트는 사용자 요청 수용에 중점
  • 서버는 발생한 요청에 대한 결과물 생성, 사용자 데이터 공유, 네트워크 서비스 제공 담당

다층 구조

  • C/S 구조의 단점을 극복하기 위함
  • 클라이언트 : 최상위 계층, 서버 : 최하위 계층 사이에 비즈니스 로직을 전담하는 중간계층을 둠
    • 비즈니스 로직을 완전히 분리
  • 중간 계층은 데이터베이스 서버의 다단계처리를 지원
  • 다른 어플리케이션 프로그램 실행
  • 클라이언트의 다양한 요구에 대한 분산 처리
  • 보통은 3-계층
    • 프레젠테이션 계층
    • 비즈니스 로직 계층
    • 데이터 계층

저장소 구조

  • 소프트웨어 아키텍처가 다수의 서브 시스템들로 구성되어 있을 때 특정한 서브 시스템에 공유 저장소를 두는 것
    • 공유 저장소를 통해 데이터를 공유하며 효율적으로 관리하고 서비스를 제공하는 구조
  • 저장소 구조는 일종의 수동형 데이터 집중화 구조
    • 이와 비교되는 능동형 데이터 집중화 구조로 블랙보드 구조가 있음
    • 블랙보드 구조는 데이터 보관하는 서브 시스템 내에 보관된 데이터에 변동이 생기면 이와 관련있는 다른 서브 시스템들에게 변경 사실을 알려주는 구조이다

객체지향 설계

  • 객체
    • 현실 세계에 독립적으로 존재하는 사물 또는 대상
  • 속성
    • 객체가 가지고 있는 특징이나 성질
  • 클래스
    • 같은 속성을 갖는 객체들의 집합
    • 클래스 고유 속성과 연산을 가짐
  • 분류화
    • 비슷한 객체들을 묶어내는 작업
  • 캡슐화
    • 정보 은닉
    • 객체의 상세 내용을 객체 외부에 숨기고 필요한 사항만을 인터페이스를 통해 보여줌
  • 추상화
    • 객체가 어떤 기능을 수행할 것인지에 관함
    • 중요 속성이나 연산만 추출하고 복잡한 내부는 감추는 작업
    • Ex. Student.genID
  • 일반화
    • 같은 속성을 가지는 유사한 클래스들을 분류하여 새로운 클래스를 정의하는 작업
  • 상속
    • 상위 클래스의 속성과 연산을 하위클래스에 물려주는 것
    • 단일 상속 vs 다중 상속
    • 반복 상속 vs 선택적 상속
    • 상위 클래스에 public protected가 선언된건만 상속 가능
  • 다형성
    • 여러 클래스에 공통으로 가지고 있는 동일한 이름의 연산이 각 클래스에 따라 다르게 동작하는 것
    • 동일한 이름의 연산을 다른 목적으로 사용할 수 있게 해준다
    • 오버로딩
      • 상위 클래스의 연산과 다른 매개변수 개수와 형태를 추가하여 연산을 다중 정의하는 다형성
    • 오버라이딩
      • 상위클래스의 연산을 하위클래스에서 다시 정의하는 다형성
  • 동적 바인딩
    • 실행시간에 하위클래스의 객체 타입에 따라서 하위 클래스의 적합한 동작이 자동으로 정해지는 것
    • 오버라이딩 다형성을 지원
      • 오버로딩 다형성은 컴파일 시간에 분류되어 처리된다
    • 소프트웨어 디자인 패턴
      • 소프트웨어를 설계할 때 특정 상황에서 자주 사용하는 패턴 또는 반복되는 솔루션을 일정한 양식으로 형식화 한것
      • 소프트웨어의 설계와 품질을 향상시키고 소프트웨어 재사용 가능성을 높임
    • 리팩토링
      • 소프트웨어의 수행 결과를 그대로 유지하면서도 소프트웨어를 구성하는 내부 코드의 구조를 재조정하는 행위
      • 버그 발생 가능성 최소화하기 위함
      • 일종의 유지보수

SOSLD 객체지향 설계의 5대 원칙

  • Single responsibility
    • 하나의 클래스는 하나의 책임을 갖는다
    • 클래스나 모듈은 한 가지 기능만을 가짐
      • 이를 변경하려는 이유도 한가지이어야한다
  • Open closed priciple
    • 소프트웨어의 각 요소는 확장에 열려있고 변경에는 닫혀 있어야한다
    • 변경이 필요한 경우 기존 코드를 수정하지 말고 상속과 확장을 활용하여 변경한다
  • Liskov substituion
    • 서브 타입(subclass, 파생 타입)은 기반타입(super 클래스)으로 교환할 수 있도록 설계뙤어야한다
    • 상속은 다형성을 통하여 확장성을 극대화하려는 목적으로 사용해야한다
  • Inteface segregation
    • 필요한 메서드만 인터페이스로 제공하고 사용하지 않는 메서드와는 연결관계를 제공하지 말아야한다
    • 범용 통합 인터페이스보다는 특정 클라이언트를 위하여 구체적인 인터페이스를 여러 개 만드는 것이 더 낫다.
  • Dependency inversion
    • 구체적인 클래스에 의존하지 말고 추상화된 것에 의존하여 설계
    • 상위 모듈이 하위모듈에 의존적이면 하위모듈의 변경에 상위모듈은 영향을 받게 됨
    • 상위 모듈은 하위 모듈에 의존하지 않도록 하고 모두 별도의 추상황에 의존하돍한다

소프트웨어 테스트 기법