Ch07. 설계와 구현

▶6주차 필기 내용

Ch07. 설계와 구현

📌 소프트웨어 공학 10판- 한티미디어

---

[소프트웨어 설계와 구현]

▶SW 설계와 구현 : 실행 가능한 SW 시스템이 개발되는 소프트웨어 공학 프로세스 단계

• 설계(how)는 요구사항(what)을 실현할 소프트웨어 컴포넌트들과 그들 간의 관계 식별 활동
• 구현 : 설계를 프로그램으로 실체화 시키는 활동

▶설계와 구현은 필연적으로 중첩됨(interleaved)

• 설계와 구현은 밀접하게 연결되어 있으며 설계 시 구현 이슈 고려함

▶개발 프로세스에 따른 차이

▸계획 기반 : 설계 단계가 있으며 설계가 모델링되고 문서화됨

▸애자일 : 설계는 대략적인 스케치만 하고 설계 결정은 프로그래머가 함

---

7.1 UML을 이용한 객체 지향 설계

[객체 지향 설계 프로세스]

▶객체지향 시스템

• 시스템은 상호작용하는 객체들로 구성됨
• 객체는 자신의 상태 유지하며 오퍼레이션 제공

▶객체지향 설계 프로세스

• 객체 클래스들을 찾고 클래스 간의 관계 식별(역할, 책임 등)

▶객체지향 설계 프로세스의 일반적인 절차

• 시스템 컨텍스트와 외부 상호작용 식별
• 시스템 아키텍처 설계
• 주요 객체 식별
• 설계 모델 개발
• 객체 인터페이스를 명시

[(1). 시스템 컨텍스트와 상호작용]

▶시스템 컨텍스트 모델

• 개발하는 시스템의 환경에 있는 다른 시스템들과의 관계를 보여줌
• 클래스 다이어그램과 ’연관’을 이용하여 표현 가능

▶상호작용 모델

• 시스템이 사용될 때 다른 시스템들과의 상호작용을 보여줌
• 유스케이스 모델 이용하여 표현 가능
• 각 유스케이스 내용을 기술해야 함 (구조화된 자연어 등)

[(2). 아키텍처 설계]

▶아키텍처 설계

• 시스템 구성 주요 컴포넌트(서브 시스템)들과 그들 간의 상호작용을 식별
• 아키텍처 설계의 일반 지식과 도메인 지식을 활용

[(3). 객체 클래스 식별]

▶객체 클래스 식별 지침

• 관련 문서에서 객체와 속성은 명사. 오퍼레이션이나 서비스는 동사.
• 응용 도메인의 실제 개체를 나타내는 클래스를 만든다
• 시나리오 기반 분석을 사용

▶객체 클래스 식별은 반복적인 과정 -대략적 시스템 설명으로부터 클래스, 속성, 오퍼레이션 식별

• 응용 도메인 지식과 시나리오 분석 이용하여 초기 객체들 정련
• 요구사항 문서, 사용자 인터뷰, 기존 시스템 분석 등으로부터 정보 수집
• 디자인 패턴 ***

결합도 낮게, 응집도 높게

(coupling) (cohesion)

[(4). 설계 모델] Design models ▶설계 프로세스에 따른 상세 수준

• 애자일 프로세스
• 계획 기반 프로세스

▶설계 모델 종류

• 구조 모델 : 시스템 정적 구조를 객체 클래스와 클래스들 간의 관계로 표현
• 동적 모델 : 실행 중에 일어나는 객체 만의 상호작용 표현

▶유용한 UML 설계 모델

• 서브시스템 모델(구조) : 클래스 다이어그램
• 시퀀스 모델(동적) : 시퀀스 다이어그램
• 상태 기계 모델(동적) : 상태 다이어그램

[(5). 인터페이스 명세] Interface specification

▶인터페이스

• 객체 또는 객체 그룹에 의해 제공되는 서비스
• 인터페이스 클래스를 이용하여 서비스의 시그니처 정의
• <<interface>> 스테레오 타입 이용
• 오퍼레이션을 가지며 데이터는 가지지 않음

---

7.2 디자인 패턴

[디자인 패턴] Design patterns

▶패턴

• 어떤 종류의 문제에 대한 해결책

▶디자인 패턴과 재사용

• 패턴은 모범 사례와 바람직한 설계를 기술
• 경험과 추상적 지식을 재사용할 수 있게 함

▶GoF 패턴 (Gang of Four)

▶패턴은 주로 객체지향 설계와 관련됨

• 상속, 다형성, 인터페이스, 추상 클래스

[디자인 패턴 4가지 핵심 요소]

▶이름

• 패턴을 지칭하는 의미 있는 이름

▶문제 서술

• 패턴이 적용될 수 있는 경우를 설명하는 문제 영역 서술

▶해법 서술

• 설계 해법의 구성요소에 대한 서술
• 구체적 설계가 아닌 인스턴스화 될 수 있는 템플릿 형식

▶결과

• 패턴 적용한 결과에 대한 설명

[Observer 패턴] : The Observer pattern

▶이름 : Observer

▶설명

• 객체 상태 표시를 객체 자체로부터 분리하고 상태를 표시하는 대안 제공할 수 있게 함
• 객체 상태가 변경되었을 때 모든 표시에 변경 반영되도록 자동으로 통지되며 표시를 갱신

▶문제 서술

• 상태 정보를 여러 방법으로 표시할 필요가 있다.
• 정보 명시할 때 모든 표시 방법이 알려져 있는 것은 아니다.
• 모든 표시는 상호작용을 지원하고 상태 변경 시 표현이 갱신되어야 한다.
• 상태 정보를 위해 하나 이상의 표시 형식이 필요하고 상태 정보를 유지하는 객체가

특정 표시 형식이 사용되는지 알 필요가 없는 경우에 사용될 수 있다.

▶해법 서술

• 추상 객체 Subject Observer와 추상 객체 상속받는 ConcreteSubject, ConcreteObserver를 사용
• 표시할 상태는 ConcreteSubject 객체에 유지되는데 표시(Observer) 추가. 삭제하는 오퍼레이션과 상태 변경 통지하는 오퍼레이션을 Subject로부터 상속받는다.
• ConcreteObserver 는 상태 표시 갱신하는 오퍼레이션을 Observer로부터 상속받는다.
• ConcreteObserver 는 자동으로 상태를 표시하고 상태 변경될 때마다 이를 반영한다.

▶결과

• Subject는 구체적 클래스의 상세 내역을 모르는 추상 Observer만 알기 때문에 객체 간 결합 최소화 된다. 상세 내역을 모르기 때문에 표시 성능 향상위한 최적화가 실용적이다. Subject에 대한 변경은 모든 Observer들의 갱신을 유발하지만 일부는 불필요할 수 있다.

---

7.3 구현 이슈

[(1). 재사용]

▶재사용(reuse)

• 대부분 최신 SW는 기존 컴포넌트, 시스템을 재사용하여 구축됨
• 가능한 기존 코드 많이 사용하는 것이 바람직

▶형상 관리(configuration management)

• 개발 중 여러 버전 버전이 생성됨 이를 형상관리 시스템(Git) 이용하여 추적해야 함

▶호스트 타겟 개발(host-target development)

• 호스트 시스템에서 SW 개발하여 타겟 시스템에서 실행

[SW 재사용 수준]

▶재사용 수준

▸추상 수준

• 디자인 패턴, 아키텍처 패턴 재사용

▸객체 수준

• 프로그래밍 언어 라이브러리 재사용

▸컴포넌트 수준

• 컴포넌트 :관련 기능, 서비스 제공 객체들 모임
• 컴포넌트 프레임워크 재사용

▸시스템 수준

• 전체 애플리케이션 시스템 (COTS : commercial off-the-shell)

▶재사용 비용

• 평가(access)/구매(buy)/개조(adapt) 및 설정(configure)/통합(integrate) 등

[(2). 형상 관리] : Configuration management

▶[형상 관리 활동]

▸버전 관리

• 소프트웨어 컴포넌트의 서로 다르 버전 저장하고 검색
• 체크아웃(check out) -> 수정 -> 체크인(check-in) -> 버전 생성

▸시스템 통합

• 시스템 구성 컴포넌트들의 버전 선택하여 시스템 빌드

▸문제 추적

• 사용자들이 문제점 보고할 수 있음
• 개발자들은 누가 작업하는지 언제 고쳐졌는지 알 수 있음

▸릴리스 관리

• 새로운 릴리스 기능 계획
• 소프트웨어 배포 구성

[(3). 호스트 타겟 개발] // .. 읽고 넘김

[호스트와 타겟]

호스트 :SW 개발되는 컴퓨터, 개발 플랫폼

타겟: SW 실행되는 컴퓨터, 실행 플랫폼

일반적으로 임베디드와 모바일 시스템은 호스트와 타겟이 다름

7.4 오픈 소스 개발

[오픈 소스 개발]

▶오픈소스 개발 : 소스코드 공개되고 개발에 지원자들이 참여하는 SW 개발 접근법

▶자유 소프트웨어 재단(Free Software Foundation) 으로부터 유래.

• 누구든지 참여 가능하나, 실제로는 핵심 개발 그룹이 주도

▶널리 사용되는 오픈소스 시스템은 안정적이고 버그 수정도 신속

▶대표적 오픈소스 시스템

• Linux, Apache, Eclipse

▶오픈소스 관련 사이트

 **(1). 오픈소스 라이센스**

[오픈소스 라이센스 모델] : License models

▶[GPL] : GNU General Public License

• 프로그램에서 GPL 소스를 (일부라도) 사용.
• 변경한다면 소스 공개해야 하고 프로그램도 GPL 라이센스 따름

▶[LGPL] : GNU Lesser General Public License

• 완화된 GPL로서, LGPL 라이브러리 사용하면 프로그램 소스 공개할 필요 X
• LGPL 라이브러리를 수정한 경우 소스 공개 O

▶[BSD] : Berkley Standard Distribution

• BSD 소스 변경 사용 가능하며, 변경 내역과 프로그램 소스 공개 의무 X
• 저작권자 이름과 라이센스 내용 같이 배포해야 함