Software Engineering – Design and Implementation

Design and Implementation

• 소프트웨어의 상세설계와 구현은 소프트웨어를 실제 프로그래밍 언어를 이용하여 만드는 단계로, 실행 가능한 소프트웨어(시스템)을 만들게 된다.
• 상세설계와 구현은 밀결합 되어 있다고 할 수 있는데, 상세설계에서는 소프트웨어의 내부요소들을 정의하고, 이들 간의 상호간계를 정의하게 된다.

Commercial-off-the-shelf(COTS)

• 상용소프트웨어를 구매하는 것이 더 좋다면(금액적 등), 혹은 조금만 바꿔서 사용할 수 있다면 소프트웨어를 구매하는 것이 좋은 선택이 될 수 있다.

Object-oriented design using the UML

• 객체지향개발방법론은 굉장히 넓고 방대한 문서와 복잡한 과정을 포함할 수 있기에, 간단한 시스템이나 Agile한 경우, 객체지향디자인 기법의 일부만 추출해서 사용하는 것이 효율적이다.

우리의 시스템이 사용할 (System) Context와 model를 정의한다.

• Use case와 Table(use case에 대한 상세 설명)을 이용할 수 있습니다.

System Architecture를 정의한다.

• Use case를 보고, 내-외부의 상호작용을, 구현 관점에서 고민한다.

시스템의 내부를 구성할 시스템 오브젝트(객체)를 정의합니다.

• 직간접적인 지식과 경험으로, 반복을 통해 만들어진다.

객체를 식별하는 방법

• 하드웨어가 주어진 경우(센서 등) 하드웨어에 집결된 데이터를 객체로 만드는 방법
• 문법적인 접근 방법(주어나 목적어를 객체로, 동사를 메소드로 만드는 방법)
• 시나리오를 사용해서 등장하는 행동들을 객체로 만든다.
• 행동의 양식을 객체로 만드는 방법

디자인 모델을 개발 (오브젝트 간의 상호관계)

• 서브시스템 모델(정적), 시퀀스(차트) 모델(동적), State machine(동적) 등을 사용할 수 있다.
• 유전의 법칙도 사용할 수 있다.

오브젝트 인터페이스를 정의 (오브젝트와 외부와의 상호관계)

• 시스템과 시스템, 서브시스템 내부 간의 인터페이스

Design patterns (inhertance & polymorphism : 주로 객체지향 특징을 가지고 있다)

• 소프트웨어가 광범위하게 굉장히 많이 짜여왔고, 특정 분야에 대한 소프트웨어도 특정 접근 방법, 검증된 디자인 방법 등이 있었고, 공유되어 왔다.

• 특정 분야에 대한 문제와 해결법에 대한 추상적인 지식(설계)을 재사용한다.

  패턴

  • 특정 분야에 대한 해결법

• 소프트웨어를 설계하는 과정에 패턴이 있다는 뜻으로, 소프트웨어의 유형별 패턴을 기록하고 공유하며, 이를 활용하여 발전된 설계를 가능하게 한다.

• 일반적으로 개발이 완료되고 사용된 패턴을 공유하기에, 코드까지 참고할 수 있는 경우가 있다.

• 소프트웨어를 설계할 때 했던 생각과 고민, 아이디어, 설계 문서를 공유/재사용함으로써, 우리의 소프트웨어의 설계 과정에서의 고민이 줄어들고, 해결해야할 특정 부분에 집중할 수 있어 생산성이 늘어난다 할 수 있다. 또한 우리가 미처 생각하지 못했던 부분에 대한 정보를 얻을 수 있고, 오랫동안 널리 사용되고 검증되어 있어 있는 방법을 참조하고/따른다면 내 소프트웨어의 신뢰성/안정성이 늘어난다.

패턴 구성요소

이름

• 의미있는 패턴을 식별할 수 있다

문제 설명

• 문제/ 분야에 대한 설명

해결법 설명

• 패턴이 동작하는 방식, 적용 방식, 설계모양등을 설명한다.

결과

• 결과와 패턴을 적용할 때 나타나는 trade-off를 설명한다.
  
  

패턴에도 장단점이 존재하고, 동일한 문제에 대해서 여러 개의 패턴이 존재할 수 있다. 따라서, 장단점을 파악하여 조건에 부합하는 패턴을 선택해야 한다.

• 구체적으로 서술할 때에는 Table을 활용할 수 있다.

Observer pattern

Name

• Observer

Description

• object state(data)와 display(view)의 분리

Problem description

• multiple displays of state - 같은 데이터가 다양한 형태로 보여진다.

Solution

• UML로 표현
  
  
• base class인 Observer, Subject. driven class인 ConcreteObserver, ConcreteSubject가 있다. Subject는 has-relationship관계로 Observer을 가진다.
• Update()를 통해 ConcreteSubject가 바뀌면 자동으로 ConcreteObserver도 업데이트 되야 한다.

Consequence

• Optimizations to enhance display performance 부족 (장단점)

Implementation issues

Reuse

• Abstraction Level(아키텍처와 디자인), The Object Level(라이브러리, 함수, class), The component Level(object모임), The system level
• 재사용의 비용적인 측면, 현 개발 역량, 재사용할 소프트웨어(코드)가 우리 목적에 부합하는 지, 수정 여부와 이에 대한 비용 및 시간, 기존 코드와의 통합성과 추가작업 등 많은 것을 고려하여 재사용 여부를 결정해야 한다.

Reuse level

• the abstraction level : 해당 분야의 성공적인 아이디어를 차용한다. (아키텍처, 디자인)
• the object level : function, class를 공유하는 레벨
• the componenet level : 클래스’들’을 공유하는 레벨
• the system level : 전체 어플리케이션을 공유하는 레벨(COTS)

Configuration management

• 소프트웨어가 굉장히 많은 소스파일로 이뤄질 텐데, 이들의 버전을 어떻게 관리할 건지를 고민해야 한다.
• System integration을 고려해서, 버전을 맞춰서 관리해야 한다.
• 버그 tracking과 reporting이 필요하다.

Host-target development

• 특정한 운영환경이나 하드웨어를 사용할 때, 개발환경과 다른 경우가 있다.

Open Source

• 재사용 여부와 개발환경 구축할 때 Open Source를 고려할 수 있다. Open Source business로 오픈소스 기술지원이 있다.
• 오픈소스를 사용할 때, 오픈 소스 라이선스를 잘 살펴보고, 의무사항 수행 여부 등을 확인해야 한다.
• 시간이 지났을 때의 유지보수가 되는지 여부를 따져봐야 한다.
• 오픈 소스에 대한 교육과 기여가 필요하다.

GPL : 사용하면 사용한 것도 모두 공개해야 한다.
LGPL : 소스코드는 바이너리 형태로 저장되어 있는데 링킹하여 통신하여 기능만 활용할때는 공개하지 않아도 된다.
BSD : 모두 공개되어 있지만 고지의무가 있다.