소프트웨어 공학(3) - 설계 및 구현

설계와 구현

• 실행 가능한 소프트웨어가 개발되는 단계
• 설계와 구현은 독립적이지 않고 서로 중첩된다.
  • 설계에서 컴포넌트, 관계를 식별하고 이를 바탕으로 구현을 진행한다.

설계 vs 구매

• 구현 결정 초기 단계에서 시스템을 직접 설계할 것인지 구매하여 사용할 것인지 결정해야한다.
• 기존의 소프트웨어를 구매하여 요구사항에 맞게 설정할 수 있다.
  • 이는 새로운 시스템 개발 진행 보다 비용이 적고 시간도 빠르다.

UML 기반의 객체지향 설계

• 프로세스 단계
  • 시스템 컨텍스트와 외부 상호작용을 정의
    • 시스템과 외부 환경 사이의 관계를 이해하는 것
      • 이를 바탕으로 요구 기능 제공과 시스템 통신 방법을 결정한다.
    • 시스템 경계 확립
      • 어떤 기능이 구현되어야 하는지에 대한 개발 범위를 결정한다.
    • 컨텍스트 모델과 상호작용 모델을 통해 시스템과 외부 환경의 관계에 대해 상호 보완한다.
      • 컨텍스트 모델
        • 개발할 시스템의 환경에 있는 다른 시스템들을 보여주는 구조 모델
      • 상호 작용 모델
        • 시스템 사용 시 환경과의 상호 작용을 보여주는 동적 모델
  • 시스템 아키텍처 설계
    • 시스템 모델링-구조 설계와는 다르게 실 사례를 기반으로 한다.
    • 시스템과 환경 간의 상호작용에 대한 이해를 바탕으로 시스템 구조를 설계한다.
    • 주요한 컴포넌트와 컴포넌트 간 상호작용을 식별한다.
    • 계층이나 클라이언트-서버 모델 같은 시스템 구조를 설계한다.
  • 주요 시스템 객체 식별
    • 실제로 어떤 객체가 필요한지 결정하는 것은 어렵다.
    • 설계에 대한 법칙은 없고 경험이나 노하우에 기반하여 설계된다.
      • 그럼에도 어느 정도 기준은 존재할 수 있다.
        • 명사 : 객체나 속성
        • 동사 : 오퍼레이션이나 서비스, 메서드
        • 실제 확인 가능한 것 부터 정의한다.
        • 시나리오 기반의 분석을 사용한다.
          • 이를 바탕으로 객체, 속성, 메서드를 식별한다.
    • 반복 작업을 통해 개선하므로 초안의 설계가 좋지 않을 수 있다.
  • 설계 모델 개발
    • 객체와 객체 클래스 그리고 그 사이의 관계를 보여준다.
    • 구조적 모델
      • 시스템의 객체 클래스와 관계를 보여주는 정적 모델이다.
      • 클래스 다이어그램으로 표현할 수 있다.
    • 동적 모델
      • 실제 상호작용이 어떻게 일어나는지 보여주는 동적 모델이다.
    • 추가 모델
      • 서브시스템 모델
        • 객체 들의 논리적 그룹을 하나의 서브 시스템으로 묶어 보여준다.
        • 이를 내부용으로 사용할지 외부용으로 사용할지 결정한다.
      • 시퀀스 모델
        • 객체 상호작용을 순차적으로 보여준다.
        • 시퀀스 다이어그램을 사용할 수 있다.
      • 상태 머신 모델
        • 객체가 이벤트에 응답하여 어떻게 상태가 변하는지 보여준다.
        • 시스템의 모든 요소가 아닌 필요한 객체만 상태 다이어그램으로 표현한다.
      • 유즈케이스 모델이나 아키텍처 모델이 포함될 수 있다.
        • 이해관계자들의 이해를 돕기 위해 사용한다.
  • 인터페이스 명시
    • 객체들과 서브시스템들은 병행 설계될 수 있으니 인터페이스를 명시해야 한다.
    • 데이터 표현의 세부 사항은 포함하지 않으나 데이터 접근-갱신을 위한 오퍼레이션을 포함해야한다.
    • 객체들은 여러 인터페이스를 가질 수 있다.
    • 자바 같은 경우 이를 언어적으로 구현해놓았다.
      • 오버라이딩을 통해 구현한다.

디자인 패턴

• 문제에 대한 정의와 해결책
  • 추상적 일반화나 규칙을 재사용한다.
  • 상속, 다형성 같은 객체지향적 특성을 이용한다.
• 패턴
  • 팩토리 메서드 패턴
    • 상위 클래스에서 객체를 생성하는 인터페이스를 정의
    • 하위 클래스에서 인스턴스 생성
    • 객체를 생성하는 시점은 알지만 어떤 객체를 생성해야 할 지 알 수 없을 때
      • 하위 클래스에 객체 생성을 위임
    • 다른 코드가 바뀌어도 내 코드에 영향이 없게 하기 위해 사용
    • 더 많은 서브 클래스가 추가 되어도 인스턴스를 제공받는 어플리케이션 코드를 추가할 필요 없다.
  • Singleton 패턴
    • 정확히 하나의 요소만 갖는 집합
    • 특정 클래스의 객체가 오직 한 개만 존재하도록 보장, 제한
    • 동일한 자원이나 데이터 처리 객체가 불필요하게 여러 개 만들어질 필요가 없는 경우
    • 구성 요소가 나 자신 하나이다.
  • Prototype 패턴
    • 생산 비용이 높은 인스턴스를 사용할 때 다시 생성하지 않고 복사하여 사용
      • 인스턴스 생성 시 데이터 접근이 여러 번 일어날 때
      • 인스턴스 생성 시 데이터를 일일이 입력해야 할 때
    • new Object가 아닌 clone으로 기존의 것을 복사하여 일부만 변경
  • Abstract Factory 패턴
    • 여러 개의 Concrete Product를 추상화
    • 구체적 구현은 Concrete Product 클래스에서 이루어짐
    • 추상적 부품을 조합해서 추상적 제품을 만든다.
    • 특정 부품에 종속되는 것을 방지하여 Factory 패턴을 이중화 한다.
  • Composite 패턴
    • 부분-전체의 상속 구조로 표현되는 조립 객체
    • 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한 것
    • 재귀적 구조를 가진다.
  • Adapter 패턴
    • 기존 클래스를 재사용 할 수 있도록 인터페이스를 변환
  • Decorator 패턴
    • 기존에 구현되어 있는 클래스에 그때 그때 필요한 기능을 추가하는 패턴
    • 상속 대신 기능 확장이 필요할 때 사용
  • Facade 패턴
    • 몇 개의 클라이언트 클래스와 서브 시스템의 클라이언트 사이에 파사드 객체를 세움
    • 복잡한 관계를 정리(구조화) 한 것
    • 모든 관계는 파사드 객체를 통해서만 이루어진다.
    • 서브 시스템의 구조가 변경되어도 파사드만 수정하면 된다.
  • Proxy 패턴
    • 시간이 많이 소요되는 불필요한 복잡한 인스턴스 생성 시간을 간단한 객체로 줄인다.
    • 여러 작업이 섞여 있는 경우 이를 분할하고 짧은 시간이 걸리는 것을 먼저 처리.
  • Observer 패턴
    • 한 인스턴스에 의해 영향을 받는 인스턴스들을 정리하는데 사용
    • 어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보
  • Chain of Responsibility 패턴
    • 책임을 연결하여 다음 책임자에게 자동으로 넘기는 구조
    • 작업 수행 인스턴스를 체인처럼 엮어 외부 요청이 있으면 차례로 넘긴다.
  • Command 패턴
    • 명령들을 하나의 객체로 표현
    • 명령어를 각각 구현하지 않고 execute메서드에서 각 명령 별 서브 클래스를 선택하여 실행
    • 단순하게 추상 클래스와 구현 클래스를 구분하지 않고 명령어 취소 기능도 포함
    • Case 추가의 번거로움을 해결
  • State 패턴
    • 동일한 동작을 객체 상태에 따라 다르게 처리해야할 때 사용
    • 객체의 상태를 객체화한다.
    • 변경 또는 신규 상태 추가 시 원시 코드의 수정을 최소화할 수 있고 유지보수가 쉽다.

구현 이슈

• 재사용
  • 기존의 코드나 시스템 등을 재사용 하는 것은 비용이나 개발 속도 적인 면에서 이득이 될 수 있다.
  • 재사용 기반의 개발은 인터넷 기반 시스템에 적합하다.
  • 현재 많은 개발 과정의 표준이다.
  • 재사용 수준
    • 추상 레벨
      • 구조적 패턴이나 설계 패턴 만을 재 사용한다.
    • 객체 레벨
      • 라이브러리, 패키지 등 만을 사용한다.
    • 컴포넌트 레벨
      • 프레임워크를 재사용한다.
    • 시스템 레벨
      • 데이터베이스 같은 완성된 시스템을 재 사용한다.
  • 재사용 비용
    • 재사용 대상 시스템을 탐색하고 적합한 시스템인지 판별(테스트 등)하는 시간 비용이 소모된다.
    • 시스템을 구매해야할 수도 있다.
    • 시스템 채택 이후 재 설정 비용이 발생할 수 있다.
    • 시스템 통합에서 비용이 발생할 수 있다.
• 형상관리
  • 개발 버전들을 형상관리 시스템을 통해 관리하고 유지해야한다.
  • 개발자들의 개발 버전의 변화를 관리한다.
    • 모든 개발자들은 개발 버전이나 문서를 제한된 방법으로 접근해야한다.
  • 모든 변화를 확인할 수 있어야한다.
  • 형상관리 액티비티
    • 버전 관리
      • 버전이 유지되게 한다.
    • 시스템 통합
      • 개발 버전이 아닌 정해진 버전을 통합한다.
    • 문제 추적
      • 문제 발생 시 어떤 부분에서, 누구의 부분에서 발생했는지 추적한다.
      • 언제 해당 문제가 수정되었는지도 제공해야 한다.
• 호스트-타겟 개발
  • 소프트웨어는 개발환경이 아닌 실제 사용환경에서 동작할 수 있도록 개발되어야한다.
  • 하드웨어, 운영체제나 데이터베이스 같은 특정 지원 소프트웨어를 포함해야한다.

개발 도구

• 다음의 도구를 제공한다.
  • 컴파일러, 문법 지향 편집기
  • 디버깅 시스템
  • 시각적 편집기
    • UML
  • 테스트 도구
  • 버전 관리 및 시스템 통합-빌드 도구
• IDE
  • 개발 편의를 위한 여러 도구나 인터페이스를 포함한다.
  • 특정 언어 만을 지원할 수도 있고 여러 언어를 지원할 수도 있다.

시스템 배치(설치) 시 고려사항

• 하드웨어 및 소프트웨어 지원 확인
• 시스템 가용성 요구사항
  • 플랫폼에 상관 없이 동작해야할 수 있다.
• 컴포넌트 통신
  • 컴포넌트 들을 인접하게 배치해야 처리 속도를 향상시킬 수 있다.

오픈소스

• 소프트웨어를 공개하고 자발적인 여러 사람이 개발 과정에 참여한다.
• 오픈 소스 개발과 소스코드 공개 빈도는 늘고 있다.
• 오픈소스의 비즈니스 모델은 제품 지원 및 추가기능을 판매하는 것이다.
• 다만, 기본적으로 사용에 대한 자유 보장하는 것, 임의로 조작할 수 있는 것이 아니다.
  • 소스코드는 개발자의 소유이다.
• 개발 고려 사항
  • 개발 과정에서 오픈 소스 컴포넌트를 사용해야 하는가?
  • 개발 과정에서 오픈 소스 접근법을 사용해야 하는가?
• 라이센스
  • GPL : The GNU General Public License.
    • GPL 라이센스의 오픈소스를 사용하면 그 소프트웨어도 (소스코드)오픈소스여야한다.
    • 내부적인 사용만 할 경우 공개하지 않아도 된다.
  • LGPL : The GNU Lesser General Public License.
    • 오픈소스 단순 사용 시 LGPL 코드 사용만 명시하면 된다.
    • 단, 오픈소스 수정 시 전체 코드를 공개해야 한다.
  • BSD
    • 소스코드 공개 의무가 없다.
    • 상업적 사용이 가능하다.
    • 오픈소스 원작자 만을 알리면 된다.