습관처럼

소프트웨어는 크게 두 가지로 분류할 수 있다.

• 시스템 소프트웨어(System software)
• 응용 소프트웨어(Application software)

시스템 소프트웨어는 하드웨어를 컨트롤할 수 있는 소프트웨어로, 대표적으로 운영체제(OS)가 있다. 

예를 들어, 곰플레이어로 영상을 보고 싶다고 가정해보자. 곰플레이어는 모니터에게 '영상을 출력해'라고 말할 권한이 없기 때문에 운영체제에게 요청해야 한다. 곰플레이어가 운영체제에게 '운영체제야, 모니터에 영상을 출력해주면 안될까?'라고 요청하면 운영체제는 받아들인다. 그제야 하드웨어는 운영체제의 명령을 받아 모니터에 영상을 출력한다. 

이렇게 하드웨어를 컨트롤할 수 있는 소프트웨어가 '시스템 소프트웨어'이다. 즉, 장치를 움직이게 하는 소프트웨어다. 그리고 시스템 소프트웨어의 도움을 받아 사용자가 원하는 작업을 처리해주는 소프트웨어를 '응용 소프트웨어'라고 한다. 다른 말로 애플리케이션, 솔루션이라고 한다. 파워포인트, 인터넷, 게임 등 다양한 응용 소프트웨어는 운영체제의 도움을 받아 실행된다. 

시스템 소프트웨어의 종류

• 운영체제(OS, operating system)
• 링커(linker)
• 로더(loader)
• 컴파일러(compiler)
• 어셈블러(assembler)
• 유틸리티(utility)

운영체제

하드웨어를 움직이게 할 수 있는 권한은 운영체제만 가질 수 있다. 운영체제는 CPU 메모리, 하드디스크 등의 하드웨어를 관리해주고, 내 컴퓨터와 다른 컴퓨터들이 대화할 수 있도록 도와주는 등 많은 일들을 해주는 소프트웨어다.

운영체제가 있기 때문에 마우스가 어떻게 컴퓨터에서 인식되는지, 마우스 움직임이 모니터 화면에 어떻게 표시되는지, 카톡에서 보낸 메시지가 저 멀리 떨어진 다른 컴퓨터로 어떻게 보내지는지, 모니터에 사진이 어떻게 나타나는 지 신경 쓸 필요가 없다. 운영체제는 상용 소프트웨어인 윈도우(Window), 프리웨어인 리눅스(Linux) 등이 있다.

링커(linker) 

하나의 결과를 출력하기 위해 작성된 서로 다른 작은 프로그램들을 연결하여 실행 가능한 하나의 프로그램으로 만들어준다.

로더(loader) 

하드디스크와 같은 보조기억장치에 저장되어 있는 특정 프로그램을 CPU가 실행하기 위해 주기억장치에 적재하는 과정을 담당한다.

참고사항.....

펌웨어(firmware)

응용 소프트웨어처럼 별도의 설치 과정을 거치는 것이 아니라 하드웨어의 롬(ROM)에 저장되어 하드웨어를 제어하는 역할을 수행하는 소프트웨어 

미들웨어(middleware) 

서로 다른 기종의 하드웨어나 프로토콜, 통신 환경 등을 연결하여 응용 프로그램과 그 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있게 하는 소프트웨어

플러그 앤드 플레이 
컴퓨터를 구입하면 함께 주는 드라이버 CD를 본 적이 있을 것이다. 프린터와 컴퓨터를 케이블로 연결해도 프린터가 곧바로 동작하지 않는다. 그 이유는 컴퓨터와 프린터가 서로 대화를 나누도록 도와주는 소프트웨어가 설치되지 않았기 때문이다. 프린터로 "100장 인쇄해"라고 명령을 보내려면, 운영체제에 드라이버(driver)라는 작은 소프트웨어가 설치되어 있어야 한다. 프린터를 살 때 항상 '드라이버 CD'를 제공하는 이유가 바로 이런 이유이다.

화이트 박스 테스트란~

화이트박스 검사(White Box Test) 기법은 소프트웨어 내부 소스 코드를 테스트하는 기법이다. 소프트웨어를 테스트하는 방법은 크게 블랙박스 검사(Black-Box Test) 기법과 화이트박스 검사(White-Box Test) 기법이 있다. 블랙박스 검사 기법은 소프트웨어의 내부를 보지 않고, 입력과 출력값을 확인하여,기능의 유효성을 판단하는 테스트 기법이며,

화이트박스 검사 기법은 소프트웨어 내부 소스코드를 확인하는 기법이다. 화이트박스 테스트를 하는 이유는 내부 소스코드의 동작을 개발자가 추적 할 수 있기 때문에, 동작의 유효성 뿐만아니라 실행 되는 과정을 살펴봄으로써, 코드가 어떤경로로 실행되며, 불필요한 코드 혹은 테스트 되지 못한 부분을 살펴볼 수 있다. 화이트박스 테스트을 하는 부분은 대개 코드의 실행 경로를 확인해야 하기때문에 시중에 나와 있는 커버리지 분석도구를 많이 활용한다.

화이트박스 검사 기법은 블랙박스 검사 기법에 비해 많은 시간과 분석을 필요로 하지만 오류가 발생 되는 결함의 위치 등을 파악하는데 매우 유용하게 사용 할 수 있다. 일반적으로 화이트박스 테스트를 수행하는 도구는 커버리지 분석 도구와 많이 연관되며, Junit과 같은 무료도구가 있는 반면에 크리티컬한 마켓에 사용되는 VectorCAST와 같은 상용 도구 또한 있습니다.

화이트박스 검사(클래스 상속, White-box testing)

• 응용 프로그램의 내부 구조와 동작을 검사하는 테스팅 방식이다.
• 소프트웨어 내부 소스 코드를 테스트 하는 기법이다.
• 개발자 관점의 단위 테스팅 방법이라 볼 수 있다.
• 구현 기반의 테스팅이다.
• 동작의 유효성 뿐만 아니라 코드를 꼼꼼하게 검사할 수 있다.

테스트 종류

• 제어 흐름 테스트 : 프로그램의 제어구조(if, case, loop)를 테스트 함

• 데이터 흐름 테스트: 제어 흐름 그래프에 데이터 사용 현황(정의, 소멸, 사용)을 테스트 함

• 분기 테스트

• 경로 테스트

장점

• 컴파일 시점에 정적으로 정의되고 프로그래밍 언어가 직접 지원하므로 그대로 사용
• 부모 클래스의 속성 및 함수를 재사용, 자식 클래스에서 재정의로 수정이 쉽다.

단점

• 런타임 시점에 상속받은 부모 클래스의 구현을 변경할 수 없다.
• 부모 클래스에 종속되므로, 부모 클래스 구현에 변경이 생기면 자식 클래스도 변경해야 한다.
• 상속 시 부모 클래스의 내부가 보이므로 캡슐화에 위반된다는 의견도 있다.

해결책

• 추상 클래스를 상속받는다. 구현이 아닌 인터페이스를 상속받는 것이므로 유연하다.

블랙 박스 테스트란~ 

블랙박스 검사(Black-box testing)는 소프트웨어 검사 방법 중 하나로 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법을 이르는 말입니다.

주로 올바른 입력과 올바르지 않은 입력을 일일이 다 동원하여 올바른 출력을 판별하는 방식으로 검사가 이루어지기 때문에 검사의 진행에 있어 대상이 되는 소프트웨어의 코드나 내부 구조 및 개발 노하우에 대한 정보는 기본적으로 필요로 하지 않습니다.

필요한 것은 특징, 요구 사항, 검사를 위해 공개된 설계도 등 대외적으로 공개된 사항들이며 '이 소프트웨어는 무슨 역할을 수행해야 되는가'와 같이 대상이 되는 소프트웨어의 특징이나 요구 사항 등에 초점을 맞춰 검사가 이루어진다. 검사 자체는 기능에 관한 것일 수도 있고 기능 외의 것에 관한 것일 수도 있습니다.

블랙박스 재사용 (객체 합성, Black-box testing)

• 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식
• 올바른 입력과 올바르지 않은 입력을 입력하여 올바른 출력이 나오는지 검사한다.
• 사용자 관점의 테스트 방법이라고 볼 수 있다. 명세 기반 테스트 방법이라 볼 수 있다.
• 필요한 것은 특징, 요구사항, 설계도 등이다.
• 한 객체가 다른 객체에 대한 참조자를 얻는 방식으로 런타임에 동적으로 정의됨
• 인터페이스 정의에 주의
• 객체는 인터페이스에서만 접근하므로 캡슐화 유지, 종속성 감소

테스트 종류

• 동등 분할 기법 : 입력 데이터를 특성에 따라 클래스로 분류, 경험에 의존
  • ex) x값이 0~100인 경우 x<0, x=50, x>100
• 경계값 분석 기법 : 경계값에서 에러가 발생될 확률이 높다는 점을 이용.
  • ex) x값이 0~100인 경우 x=0, x=100, x=-1, x=101
• 오류 예측 기법 : 각 시험 기법들이 놓치기 쉬운 오류들을 감각, 경험으로 테스트
• 원인 결과 그래프 기법 : 입력 데이터간 관계가 출력에 미치는 영향을 그래프로 표현
• 요구사항 추적 매트릭스 : 고객의 요구사항 중 빠진 사항은 없는지 추적하는 매트릭스
• 상태 전이 테스팅 : 시스템의 상태(모드)가 변화함에 따른 테스트
• 의사결정 테이블 테스팅 : 논리적인 조건이나 상황을 구현하는 시스템 요구사항을 도출하거나

요약을 하자면, 블랙박스 테스트의 경우 보이는 부분만 보고 문제점을 찾는 방법이고 화이트박스 테스팅의경우 보이지 않는 소스의 내부적인 로직구조의 문제점까지 찾아내는 방법이다.

출처 : http://justin-log.blogspot.com/2016/02/blog-post.html

6. 컴포넌트 기반 소프트웨어공학

■ 배경
- 객체지향 개발 방법이 광범위한 재사용을 유도하지 못했다.
- 클래스 단위는 효과적으로 재사용하기에는 너무 크기가 작고 상세하고 구체적이었기 때문에 어려움이 있었다.
- 컴포넌트가 클래스보다 훨씬 추상적이었으며 개별적으로 재사용하기가 용이했다.
- CBSE는 느슨히 연결된 독립적 컴포넌트들을 정의하고 구현한 다음 통합하거나 조합함으로써 시스템을 만드는 프로세스로 중요한 소프트웨어 개발 방법이 되었다.

(1) 컴포넌트와 컴포넌트 모델

■ 컴포넌트란?

•  컴포넌트 모델을 따르는 소프트웨어 요소로서, 독립적으로 배포될 수 있고 컴포넌트 조합(composition) 표준에 따라 수정 없이 조합될 수 있는 것(Council & Heineman)
• 계약으로(contractually) 명세된 인터페이스와 분명한 컨텍스트 종속성만을 가지는 조합의 단위. 컴포넌트는 독립적으로 배포될 수 있고 제3자에 의해 조합되는 것을 가정한다. (Szyperski)

■ 서비자 제공자로서의 컴포넌트 특성

• 컴포넌트는 객체 클래스에 비해 훨씬 추상적(abstract)이며, 독립적으로 서비스를 제공한다고 볼 수 있다.
  
• 시스템이 서비스가 필요한 경우 컴포넌트를 호출한다. 이때, 호출자는 컴포넌트가 어떻게 구현되었고, 어떠한 식으로 동작하는지에 대해서는 알 필요가 없다.
  
• 독립적인 실행가능 개체로 하나 또는 여러 개의 클래스로 구현되어 있다. : 소스 코드가 제공되지 않기 때문에 다른 컴포넌트와 함께 사용되지 전에 컴파일될 수 없다.
  
• 모든 상호작용은 공개된 컴포넌트의 인터페이스를 통해 이루어진다.

■ 컴포넌트 인터페이스

□ 제공 인터페이스(Provides interface) - 해당 컴포넌트가 다른 컴포넌트들에게 제공하는 서비스들을 정의

□ 요구 인터페이스(Requires interface)
- 컴포넌트가 필요로하며 다른 컴포넌트에 의해 제공되어야 하는 서비스들을 정의
- 만약 요구 인터페이스가 제공되지 않으면 컴포넌트가 동작하지 않는다.

■ 컴포넌트와 객체의 비교

□ 유사점

- 메시지 기반 통신을 함 : 객체는 메시지, 컴포넌트는 이벤트와 메시지
- 인터페이스가 잘 정의됨
- 캡슐화, 정보은닉, 다형성, 특수화 등을 사용

□ 차이점
- 컴포넌트는 영속적 저장소를 사용하지만, 객체는 그렇지 않을 수도 있음.
- 컴포넌트가 일반 객체보다 큼.
- 컴포넌트는 제공 및 요구 인터페이스를 포함하지만 객체는 그렇지 않을 수도 있음.
- 컴포넌트는 아키텍처에 의존적임 : 객체는 동적인 경향이 있으며, 컴포넌트는 정적인 경향이 있음.
- 컴포넌트는 배포 가능한 개체임.
- 컴포넌트는 타입을 정의하지 않음.
- 컴포넌트의 구현은 감추어져 있음
- 컴포넌트는 언어 독립적임.
- 컴포넌트는 표준화되어 있음.

■ 컴포넌트 모델 - 컴포넌트 구현, 문서화 및 배포에 대한 표준을 정의해 놓은 것

□ 컴포넌트 모델의 예
- Sun의 EJB(Enterprise Java Beans)
- 마이크로소프트의 COM+ (.NET)
- OMG의 CORBA

□ 컴포넌트 모델의 기본 구성요소

• interfaces
  • 인터페이스의 정의 방법을 명세함. 인터페이스 정의에서 오퍼레이션 이름, 매개 변수,예외가 포함되어야 함.
    
  • 인터페이스를 정의하는데 사용하는 언어(IDL)을 명세해야 함
    
  • 보안과 트랜잭션 관리와 같은 표준화된 서비스를 제공하는 컴포넌트 모델 하부구조에 컴포넌트를 결합하기 위해 특정 인터페이스가 필요하기도 함
•  Usage Information
  
  • 분산 환경에서 컴포넌트의 원격 접근을 위한 컴포넌트의 고유 이름이 필요함
    
  • 메타데이터는 인터페이스 정보나 속성 정보와 같은 컴포넌트 자체에 관한 데이터로 사용자가 어떤 서비스가 제공되고 요구되는지를 찾기 위해 필요함
    
  • 컴포넌트는 일반적인 개체이므로 특정 환경에 맞게 어떻게 설정되는지 명세해야 함
•  Deployment and use
  
  • 독립적 실행가능한 개체로 배치하기 위해 컴포넌트들을 어떻게 묶는가를 정의해야 함

■ 미들웨어

- 컴포넌트 모델은 컴포넌트의 실행을 지원하는 미들웨어의 기초가 된다.
- 컴포넌트 모델의 구현을 통해 다음을 제공한다.
- 모델에 따라 작성된 컴포넌트는 서로 통신할 수 있도록 해준다. (플랫폼 서비스)
- 다양한 컴포넌트들이 공통적으로 사용하는 애플리케이션 독립적 서비스 ( 공통 서비스 또는 Horizontal Services)

■ 재사용성을 높이기 위한 작업 - 컴포넌트의 재사용성을 높이기 위해 컴포넌트 문서화, 컴포넌트 검증, 컴포넌트의 일반화 작업이 필요함

- 특정 애플리케이션에만 사용되는 메소드는 제거
- 일반적인 이름으로 명칭 변환
- 처리할 수 있는 범위를 넓힐수 있는 메소드 추가
- 예외 처리를 일관성이 있도록 통일
- 컴포넌트 적응(adaptation)을 위해 환경 설정(configuration) 인터페이스를 추가
- 독립성을 증가시키기 위해 필요한 컴포넌트들을 통합 ( 종속성 감소 )

(2) CBSE 프로세스

■ CBSE의 기초 - 규모가 커지고 복잡해지는 시스템 ... 그러나 신뢰성 있는 소프트웨어의 빠른 개발을 요구하는 고객을 생각할 때, 유일한 대처 방법은 재사용이다.

CBSE가 가능하려면 다음의 것들이 필요하다.
- 독립적 컴포넌트
- 컴포넌트 표준
- 미들웨어: 컴포넌트 통합을 위한 소프트웨어 지원, 분산된 컴포넌트들의 상호 작동을 위해 컴포넌트 통신을 담당하는 미들웨어 지원
- 개발 프로세스 : 컴포넌트 기반의 소프트웨어공학을 지원하는 프로세스

■ CBSE 프로세스 : 컴포넌트를 재사용할 때 요구사항과 컴포넌트가 실제로 제공하는 서비스 간에는 trade-offs가 생길 수 있다.

□ CBSE 프로세스의 특징
- 프로세스에 재사용 활동을 포함시킨다.
- 컴포넌트에 맞도록 요구사항이 수정되는 경우도 있다.
- 프로토타이핑 프로세스나 점진적 개발 프로세스가 포함된다.
- 프로토타이핑을 위해 컴포넌트 조합용 스크립트 언어를 사용하기도 한다.

■ CBSE의 문제점 : CBSE는 건전한 설계 원리에 기초하고 있고 소프트웨어 개발 방법의 주류가 되고 있으나 여러 문제점들이 남아 있다.

- 컴포넌트 신뢰성 : 소스코드가 제공되지 않는 컴포넌트를 어떻게 신뢰할 것인가?
- 컴포넌트 인증 : 컴포넌트의 품질은 누가 보증해주는가?
- 창발적 속성의 예측 : 컴포넌트를 조합했을 경우 발생하는 창발적 속성에 대해서는 어떻게 알 수 있는가?
- 요구사항들의 trade-offs : 컴포넌트가 제공하는 기능과 요구사항의 차이는 어떻게 처리할 것인가?

■ 컴포넌트의 재사용 단계

- 검색(Qualification): 재사용할 수 있는 적합한 컴포넌트를 찾아냄

- 적응(Adaptation): 실제 구현하여 재사용할 수 있도록 찾아낸 컴포넌트를 수정

- 조합(Composition): 컴포넌트를 조합하여 전체 시스템을 구축

□ 효율적 재사용을 위해 해결되어야 할 문제점

- 검색 단계
다양한 컴포넌트들의 집합(또는 저장소)으로부터 원하는 컴포넌트를 검색함에 있어서 의미론(Semantics)을 다루어야 하는 문제가 있다.
시멘틱 웹이나 온톨로지 등의 기술이 있으나, 컴포넌트 명세에 최적화된 형태로 의미를 찾을 수 있는 방법이 필요하다.

- 적응 단계
원하는 서비스를 찾았다고 하더라도, 시그너처의 차이, 플랫폼의 차이, 프로토콜의 차이 등으로 바로 재사용하여 조합시킬 수 있는 것은 아니다. 이질적인 여러 환경을 동일하게 맞추어 주거나 중개자 등을 통해 서로 의미적으로나 문법적으로 조합이 가능하도록 변경시켜 적응할 수 있어야 한다.

- 조합 단계
적응이 되었다면, 조합을 할 수 있다. 하지만, 이러한 작업이 동적으로 이루어지려면 서비스들이 자동적으로 환경을 설정할 수 있도록 기반 플랫폼과 연계되어야 한다.

정리하기
- 재사용의 장점은 비용 절감 및 위험 감소에 있다.
- 설계 패턴은 고수준으로 추상화된 지식을 재사용하기 위한 잘 정리된 문서이다.
- 애플리케이션 프레임워크는 구체 또는 추상 객체들을 모아놓은 것으로 특성화를 통해 재사용이 가능하다.
- COTS 재사용의 문제점은 기능, 성능 및 유지보수, 상호 연동 등에 대한 제어를 함에 있어서 제약이 있다는 것이다.
- 소프트웨어 제품 라인은 공유할 수 있는 공통적인 부분과 변경될 수 있는 부분을 구분하여 이를 독립적인 자산으로 관리하는 것이 핵심이다.
- 컴포넌트가 클래스보다 훨씬 추상적이고, 개별적이기 때문에 재사용이 용이하다.
- 컴포넌트는 제공 및 요구 인터페이스를 가진다.
- 컴포넌트 모델은 컴포넌트의 실행을 지원하는 미들웨어의 기초가 된다.
- 컴포넌트 재사용은 검색, 적응, 조합의 3단계를 거치게 된다.

출처 : http://i-bada.blogspot.com/2014/05/blog-post_3255.html