서론
소프트웨어 설계와 구현
- 설계와 구현은 밀접하게 연결되며, 종종 병행하여 진행.
- 상용 패키지를 구매해 재사용하고, 패키지를 요구사항에 맞게 구성하는 데 집중.
- Agile 방법론을 사용할 때에는 비공식 스케치를 사용하고, 설계 결정을 프로그래머에게 맡김.
구현 시 고려사항
- 소프트웨어 재사용, 구성 관리, 오픈소스 개발 등을 고려함.
- UML 사용은 객체 지향 언어(Java, C# 등)에 적합하지만, Python 같은 동적 언어에는 덜 유용.
원.
7.1 Object-oriented design using the UML
객체 지향 시스템
객체 지향 시스템 특징
- 객체는 자체 상태와 이를 조작하는 연산을 가짐.
- 상태는 캡슐화되어 외부 접근 불가.
- 객체 변경이 다른 객체에 영향 주지 않음.
- 실세계 엔터티와 매핑으로 이해와 유지보수 용이.
객체 지향 설계 과정
- 맥락 및 외부 상호작용 정의: 시스템이 외부와 어떻게 연결되고 동작하는지 이해.
- 시스템 아키텍처 설계: 시스템의 전체 구조를 정의.
- 주요 객체 식별: 시스템에서 중요한 객체와 이들 간의 관계 정의.
- 설계 모델 개발: 객체 간 상호작용을 나타내는 모델 작성.
- 인터페이스 명세: 객체가 제공하는 기능과 인터페이스를 명확히 정의.
설계 특징
- 설계는 순차적이지 않음: 아이디어를 제안하고 수정, 문제 해결을 반복하며 진행.
- 세부 사항에 대한 탐색과 무시가 상황에 따라 병행됨.
- UML 같은 표기법은 상황에 따라 정확하게 사용하거나 비공식적으로 논의를 촉진하는 도구로 사용.
사례: 기상 관측소 설계
- 기상 관측소는 지역 날씨 데이터를 기록하고 이를 위성 링크를 통해 전송.
- 하드웨어와 객체 간 매핑으로 설계 이해도 및 유지보수성 향상.
시스템 컨텍스트와 상호작용
시스템 컨텍스트와 경계 설정
- 목적: 시스템과 외부 환경의 관계를 이해하여 기능 제공 방식과 구조 설계 결정.
- 시스템 경계: 구현할 기능과 외부 시스템에 할당할 기능을 구분.
모델 유형
- 컨텍스트 모델: 시스템 환경 내 다른 시스템과의 구조적 관계를 표현하고 블록 다이어그램을 활용해 엔티티와 연관성 간단히 표시.
- 상호작용 모델: 시스템과 외부 환경 간 동적 상호작용을 표현 유스 케이스 모델로 상호작용을 추상화해 표현.
유스 케이스 모델
- 시스템과 환경 간 가능한 상호작용을 타원으로 표시.
- 외부 엔티티는 스틱 피겨로 나타냄.
- 유스 케이스는 구조화된 자연어로 기술: 정보 교환, 상호작용 시작 조건, 자극과 응답 등 명시.
아키텍처 디자인
시스템 아키텍처 설계
- 시스템과 환경 간의 상호작용 정보를 기반으로 주요 구성 요소와 상호작용 설계.
- 아키텍처 패턴 활용:
- 레이어드 패턴: 계층적 구조.
- 클라이언트-서버 모델: 분산 구조.
기상 관측소 소프트웨어 아키텍처
-
구성
- 독립적인 서브시스템이 공통 통신 링크를 통해 메시지 브로드캐스트로 상호작용.
- 리스너 모델: 메시지를 감지하고 각 서브시스템에 해당하는 메시지만 처리.
-
동작 방식
- 제어 명령(예: 종료)이 수신되면, 각 서브시스템이 올바른 방식으로 자체 종료.
-
장점
- 유연성: 특정 서브시스템에 메시지를 직접 주소 지정할 필요 없음.
- 다양한 서브시스템 구성 지원.
데이터 수집 서브시스템 아키텍처
- 구성
- Transmitter: 데이터 송신 관리.
- Receiver: 데이터 수신 관리.
- WeatherData: 수집된 날씨 데이터를 캡슐화.
- 패턴
- 생산자-소비자 패턴 적용: 데이터 수집(생산)과 전송(소비)을 분리.
객체 클래스 식별
시스템 객체 식별
- 용어 분석: 명사(객체), 동사(연산자)로 객체 및 연산자 식별.
- 실제 도메인 엔티티: 예: 기기, 역할, 이벤트 등.
- 시나리오 기반 분석: 각 시나리오에서 필요한 객체, 속성, 연산자 식별.
객체 클래스 식별 과정
- 기본 객체 클래스: 시스템 인터페이스를 제공하는
WeatherStation, 데이터를 처리하는WeatherData. - 도메인 객체:
Ground thermometer,Anemometer,Barometer는 실제 기기와 연결.
추가적인 객체와 속성:
- 기기 오류 보고: 기기의 상태 점검을 위한 속성과 연산자 필요.
- 고유 식별자: 각 기기 및 기상 관측소의 고유 식별자 필요.
- 기기 데이터베이스: 설치 시기와 기기 종류를 관리하는 정보 유지.
객체 설계 및 상속 구조
- 공통 속성을 가진
Instrument슈퍼클래스 정의. - 슈퍼클래스는 ID, 데이터 수집 주기, 상태 테스트 연산 포함.
- 필요 시 새로운 속성과 연산자 추가.
디자인 모델
설계 방식에 따른 모델 세부 수준:
- 애자일 개발
- 추상적인 모델(화이트보드 수준)로 충분.
- 계획 기반 개발
- 상세한 모델 필요, 특히 요구사항 엔지니어와 개발팀 간 간접적 연결 시.
UML 모델 종류:
- 구조적 모델
- 시스템의 정적 구조(객체 클래스 및 관계)를 설명
- 일반화(상속), 사용/사용됨 관계, 컴포지션 관계 포함.
- 동적 모델
- 런타임 객체 간 상호작용 및 상태 변화를 설명.
효과적인 UML 모델 설계
1. 서브시스템 모델
- 정의: 객체를 논리적으로 관련된 그룹으로 묶어 시스템의 정적 구조를 표현.
- 사용 목적:
- 객체 간의 관계(상속, 일반화, 집합 등)를 명확히 정의.
- 설계의 전반적인 조직과 구조를 시각화.
- 주의점:
- 구현 세부사항을 과도하게 설계하지 말 것.
- 예시: 날씨 정보 시스템에서
WeatherStation,SatComms,WeatherData와 같은 객체들을 서브시스템 단위로 그룹화.
2. 시퀀스 모델
- 정의: 특정 상호작용 모드에서 객체 간 서비스 요청의 순서와 흐름을 동적으로 표현.
- 사용 목적:
- 여러 객체가 협력하여 특정 작업을 수행하는 과정을 시각화.
- 각 유스 케이스마다 시퀀스 모델을 생성하여 구체적인 상호작용을 정의.
- UML 시퀀스 다이어그램:
- 상호작용을 위에서 아래로 읽음.
- Stick 화살표: 메시지 보낸 객체가 응답을 기다리지 않음.
- Squared-off 화살표: 메시지 보낸 객체가 응답을 기다림.
- 예시:
SatComms가 외부 시스템으로부터 날씨 요약 요청을 받아WeatherStation에 전달.WeatherStation은Commslink와WeatherData객체를 통해 데이터를 요약 후 전송.
3. 상태 기계 모델
- 정의: 객체나 시스템이 메시지나 이벤트에 반응하여 상태를 어떻게 전환하는지 설명.
- 사용 목적:
- 시스템 동작의 고수준 모델링.
- 객체가 특정 상태에서 어떤 작업을 수행하며, 어떤 조건에서 상태가 전환되는지 명확히 표현.
- UML 상태 다이어그램:
- 초기 상태는 검은 점으로 표시.
- 상태 간의 전환은 이벤트에 의해 트리거.
- 예시 (WeatherStation 시스템):
- Shutdown 상태:
restart()→ Running,reconfigure()→ 재구성 상태. - Running 상태: - shutdown(): 다시 Shutdown 상태로 전환.
- reportWeather(): Summarizing → Transmitting → Running 순으로 전환.
- 시계 신호: Collecting 상태로 전환하여 데이터를 수집.
- remoteControl(): 원격 제어 상태로 전환.
- Shutdown 상태:
- 활용:
- 고수준 시스템 동작 모델링에 유용.
- 단순한 객체에는 상태 다이어그램이 필요하지 않을 수 있음.
인터페이스 정의
인터페이스 정의의 중요성
- 목표: 객체가 제공하는 서비스의 세부 사항(메서드의 시그니처 및 의미)을 정의하여 다른 객체들이 그 서비스에 접근하고 사용할 수 있도록 함.
- 설계의 독립성: 인터페이스를 명확히 정의하면, 객체의 데이터 표현 방식을 숨길 수 있어 객체 내부 구현이 변경되더라도 이를 사용하는 다른 객체에는 영향을 미치지 않음.
UML에서의 인터페이스 설계
- UML 사용: UML에서 인터페이스는 클래스 다이어그램처럼 정의되며, 속성 섹션 없이
«interface»스테레오타입을 사용해 구별함. - OCL을 통한 의미 정의: OCL(Object Constraint Language)을 사용하여 인터페이스의 의미를 명확하게 정의할 수 있음.
예시: 날씨 측정 시스템의 인터페이스
- 보고서 인터페이스: 날씨 및 상태 보고서를 생성하는 작업 이름들을 정의하며,
WeatherStation객체에서 매핑됨. - 원격 제어 인터페이스:
WeatherStation의remoteControl메서드로 매핑되는 4개의 작업을 정의.
설계 시 유의점
- 속성 포함 금지: 인터페이스 설계에서 데이터 표현 방식을 노출하지 않고, 대신 데이터를 액세스하고 수정하는 작업만 정의해야 함.
- 유연성 및 유지 보수: 인터페이스 설계는 시스템의 유연성과 유지 보수성을 높임.
- 1:1 관계 아님: 하나의 객체는 여러 인터페이스를 가질 수 있으며, 여러 객체가 하나의 인터페이스를 통해 접근될 수 있음.
7.2 Design patterns
디자인 패턴의 4가지 필수 요소 (Gang of Four 기준)
- 이름: 패턴을 의미 있게 지칭하는 이름.
- 문제 설명: 패턴이 적용될 문제 영역을 설명.
- 해결책 설명: 설계 솔루션의 구성 요소, 그들의 관계, 책임을 설명. 이는 템플릿 형식으로 제공되며, 다양한 방식으로 구체화 가능.
- 결과 및 트레이드오프: 패턴 적용의 결과와 선택 사항을 설명하여, 상황에 맞게 적용 가능 여부를 이해하도록 도움.
디자인 문제와 패턴 적용
1. 객체 상태 변화가 여러 객체에 통지되어야 할 때 (Observer 패턴)
2. 여러 관련 객체들의 인터페이스를 정리해야 할 때 (Façade 패턴)
3. 컬렉션 요소에 표준화된 방법으로 접근해야 할 때 (Iterator 패턴)
4. 기존 클래스의 기능을 실행 시간에 확장해야 할 때 (Decorator 패턴)
디자인 패턴의 장점
- 패턴은 고수준의 개념 재사용을 지원. 이를 통해 시스템 개발에 맞게 구현을 조정할 수 있음.
- 패턴 사용: 시스템 설계를 시작하고 문제를 경험한 후, 적절한 패턴을 찾아서 문제를 해결.
- 경험 필요: 패턴을 효과적으로 사용하려면 경험이 필요. 초보자는 패턴을 적용할 수 있는 상황을 식별하기 어려울 수 있음.
7.3 Implementation issues
소프트웨어 구현에서 중요한 요소
- 재사용: 현대 소프트웨어는 기존의 컴포넌트나 시스템을 재사용하여 구축.
- 구성 관리: 개발 과정에서 소프트웨어 구성 요소의 여러 버전이 생성.
- 호스트-타겟 개발: 생산 소프트웨어는 일반적으로 개발 환경과 동일한 컴퓨터에서 실행되지 않는 대신, 개발은 하나의 컴퓨터(호스트 시스템)에서 이루어지고, 실행은 별도의 컴퓨터(타겟 시스템)에서 이루어짐.
재사용
소프트웨어 재사용의 수준
- 추상화 수준
- 직접적으로 소프트웨어를 재사용하지 않고, 성공적인 추상화 지식을 소프트웨어 설계에 사용.
- 예: 디자인 패턴, 아키텍처 패턴.
- 객체 수준
- 라이브러리에서 객체를 직접 재사용하는 방식
- 예: JavaMail 라이브러리에서 이메일 처리 기능을 제공하는 객체와 메서드.
- 컴포넌트 수준
- 객체와 객체 클래스들이 모여 관련된 기능을 제공하는 컴포넌트 수준의 재사용.
- 예: 사용자 인터페이스를 프레임워크를 사용하여 구축하고, 데이터를 표시하는 코드와 화면 레이아웃 등을 추가하는 방식.
- 시스템 수준
- 전체 애플리케이션 시스템을 재사용하는 방식.
- 기존 소프트웨어 제품 라인을 재사용하거나, 시스템의 구성 인터페이스를 사용하여 재사용.
- 때때로 여러 시스템을 통합하여 새로운 시스템을 만들기도 함.
소프트웨어 재사용의 장점과 비용
-
장점:
- 기존 소프트웨어를 재사용하면 새로운 시스템을 더 빠르고 저렴하게 개발할 수 있음.
- 재사용된 소프트웨어는 다른 애플리케이션에서 테스트되었기 때문에 신뢰성이 높음.
-
비용:
- 재사용 소프트웨어 탐색 비용: 소프트웨어를 찾아서 평가하고, 환경에 맞게 테스트하는 데 시간이 소요된다.
- 구매 비용: 대형 소프트웨어 시스템의 경우 매우 높은 비용이 발생할 수 있다.
- 적응 및 구성 비용: 재사용 소프트웨어를 시스템 요구 사항에 맞게 조정하는 데 드는 비용.
- 통합 비용: 다양한 출처에서 온 재사용 가능한 소프트웨어 요소를 서로 통합하거나 새로운 코드와 통합하는 데 드는 비용. 제공업체 간의 소프트웨어 재사용 가정이 충돌할 수 있어 어려움이 있을 수 있다.
구성 관리
구성 관리의 네 가지 핵심 활동
-
버전 관리
- 다양한 소프트웨어 컴포넌트의 버전을 추적하는 지원을 제공.
- 버전 관리 시스템은 여러 개발자들이 작업을 조정할 수 있도록 도와주며, 한 개발자가 다른 개발자의 코드를 덮어쓰지 않도록 함.
-
시스템 통합
- 각 시스템 버전을 생성하는 데 사용되는 컴포넌트의 버전을 정의하고, 이를 통해 자동으로 시스템을 빌드할 수 있도록 지원.
-
문제 추적
- 사용자들이 버그와 문제를 보고할 수 있게 하고, 모든 개발자가 이 문제를 언제 누구가 해결하는지 알 수 있도록 함.
-
배포 관리
- 새로운 버전의 소프트웨어 시스템이 고객에게 배포되는 과정에 관한 계획을 수립하고 소프트웨어 배포를 조직.
호스트-타겟 개발
소프트웨어 개발 도구
- 컴파일러 및 편집 시스템
- 디버깅 도구
- 그래픽 편집 도구 (UML)
- 테스트 도구 (JUnit 등)
- 구성 관리 도구
통합 개발 환경(IDE)
- Eclipse
- Visual Studio Code
배포 플랫폼 결정 시 고려사항
- 하드웨어/소프트웨어 요구 사항
- 시스템 가용성 요구 사항
- 컴포넌트 간 통신 지연
- (임베디드 시스템) 타겟의 크기, 전력, 실시간 응답 등
7.4 Open-source development
오픈소스 개발
주요 오픈소스 소프트웨어
- 리눅스 운영체제
- Apache 웹 서버
- Java
- Eclipse IDE
- MySQL 데이터베이스 관리 시스템
- Android 운영체제
오픈소스 소프트웨어의 장점
- 저렴하거나 무료: 오픈소스 소프트웨어는 일반적으로 비용이 적거나 없음.
- 신뢰성: 많은 사용자들이 문제를 신속하게 수정하고, 버그를 빨리 발견하여 해결.
- 빠른 개발: 많은 기여자들이 버그를 수정하고 기능을 추가함으로써 소프트웨어 개발이 가속화됨.
오픈소스를 사용 시 주요 문제
- 오픈소스 구성 요소 사용 여부: 판매용 소프트웨어를 개발하는 경우, 오픈소스 시스템을 사용하여 비용과 시간을 절감할 수 있지만, 특정 조직 요구사항에 맞는 시스템을 개발하는 경우, 오픈소스를 사용할 수 없을 수도 있음.
- 자체 소프트웨어 개발에 오픈소스 접근법 사용 여부: 오픈소스를 사용하면 개발이 더 빠르고 저렴해질 수 있지만, 기업 비밀이 노출될 수 있다는 우려가 있을 수 있음.
오픈소스 라이선스
주요 오픈소스 라이선스 유형
-
GNU General Public License (GPL)
- 상호적 라이선스: GPL 라이선스로 배포된 오픈소스를 사용하면, 그 소프트웨어를 포함하는 새로운 시스템도 오픈소스로 공개해야 함.
-
GNU Lesser General Public License (LGPL)
- GPL의 변형으로, 오픈소스 코드와 연결된 컴포넌트를 공개하지 않아도 되지만, 오픈소스 코드 자체를 변경하면 그 변경 사항을 오픈소스로 공개해야 함.
-
Berkley Standard Distribution (BSD) License
- 비상호적 라이선스: 오픈소스를 수정하거나 배포할 의무가 없으며, 상용 소프트웨어에 포함할 수 있음. 다만, 오픈소스 코드의 원작자를 명시해야 함. MIT 라이선스는 BSD 라이선스와 유사한 조건을 가짐.
오픈소스 관리 절차(Bayersdorfer(2007))
- 오픈소스 구성 요소 관리: 다운로드한 오픈소스 컴포넌트의 라이선스를 추적하고, 각 컴포넌트가 사용될 당시 유효한 라이선스를 보관.
- 라이선스 종류 파악: 오픈소스를 사용하기 전에 라이선스 조건을 이해하고, 각각의 시스템에서 사용할 수 있는지 여부를 결정.
- 컴포넌트 발전 경로 파악: 사용 중인 오픈소스 컴포넌트가 향후 어떻게 변화할지에 대해 인지.
- 오픈소스 교육: 개발자들에게 오픈소스 라이선스와 관련된 교육을 제공.
- 감사 시스템 구축: 개발자가 마감일에 맞추기 위해 라이선스 조건을 위반할 가능성이 있으므로, 이를 탐지하고 방지할 수 있는 시스템을 마련.
- 오픈소스 커뮤니티 참여: 오픈소스 제품을 의존하는 경우, 해당 커뮤니티에 참여하여 개발을 지원.
출처: Ian Sommerville - Software Engineering
