[소공 시험공부] Software Reuse

Software Reuse를 왜 하나요?

더 나은 SW를 빠르고 저렴하게 달성하기 위해서 하는 것.

System부터 Application, component, Object and function 까지 모두 가능

 

Benefits of software reuse (외워야 하나..?)

Benefit	Explanation
Accelerated development	시스템을 가능한 한 빨리 시장에 출시하는 것이 전체 개발 비용보다 중요한 경우가 많습니다. 소프트웨어 재사용은 개발 및 검증 시간의 단축(both development and validation time may be reduced)으로 시스템 생산을 가속화할 수 있습니다.
Effective use of specialists	동일한 작업을 반복해서 수행하는 대신, 응용 프로그램 전문가들은 자신의 지식을 캡슐화(encapsulate their knowledge)한 재사용 가능한 소프트웨어를 개발할 수 있습니다. 무언가를 가져다가 사용할 때, 잘 아는 사람이 작성한 소프트웨어를 가져다가 사용할 수 있다 ex) 머신러닝 라이브러리
Increased dependability	재사용된 소프트웨어는 이미 작동하는 시스템에서 시험되고 테스트되었기 때문에 새로운 소프트웨어보다 더 신뢰할 수 있습니다. 그 설계 및 구현의 결함이 발견되고 수정되었어야(faults shoud have been found and fixed)합니다. 오랜기간 동안 개발한 것들을 사용하기 때문에 훨씬 더 믿고 사용할 수 있다.

 

Lower development costs	개발 비용은 개발되는 소프트웨어의 크기에 비례합니다. 소프트웨어를 재사용하면 작성해야 하는 코드 라인이 줄어듭니다.(즉, 개발 기간 자체가 줄어듬)
Reduced process risk	기존 소프트웨어의 비용은 이미 알려져 있는 반면, 개발 비용은 항상 판단의 문제입니다. 이것은 프로젝트 관리에 중요한 요소이며, 특히 하위 시스템과 같은 비교적 큰 소프트웨어 구성 요소가 재사용될 때 프로젝트 비용 추정의 오류 범위를 줄입니다. (이미 개발된 걸 가져다가 사용하니)
Standards compliance	일부 표준, 예를 들어 사용자 인터페이스 표준은 재사용 가능한 구성 요소 집합으로 구현될 수 있습니다. 예를 들어, 사용자 인터페이스의 메뉴가 재사용 가능한 구성 요소를 사용하여 구현되면, 모든 응용 프로그램이 동일한 메뉴 형식을 사용자에게 제공할 수 있습니다. 표준 사용자 인터페이스의 사용은 사용자들이 익숙한 인터페이스를 제공받기 때문에 실수를 줄여 신뢰성을 향상시킵니다. ex) safety critical system 처럼 standard를 따라야 하는 경우 이미 Standard를 따르고 인증 받은 것을 가져다가 사용하면 된다.

 

Software Reuse의 문제점은 뭐가 있을까요?

• 컴포넌트를 재사용 가능하게 만들기 위해 비용이 많이 든다
• 요구사항에 일치하는 reusable component를 찾고 이해하는데 cost가 필요하다
• 소스 코드가 없으면 유지보수 비용이 높아지고, 소유한 컴포넌트서비스가 아니라서 만드는 사람들이 뭔가 바꾸는 것에 대한 컨트롤이 불가능함
• 일부 SW tool이 재사용 지원을 안할 수 있따
• 일부 엔지니어들이 컴포넌트를 본인이 다시 작성하는 것을 선호함

Reuse planning factor : Reuse할 때 어떤 것들을 고려해야 하나요?

• 개발 일정
• expected software lifetime
• 개발팀의 background, skill, experience
• The Criticality of the SW and it's NFR
  • critical SW의 경우 NFR을 지켜야 해서 reuse가 어려울 수 있음
• The application domain(병원용, 은행용... 이런식으로 사용하려는 domain에 맞춰진 제품들이 존재함)
• The execution platform : 어떤 OS? 웹?앱?

Framework란?

소프트웨어 아티팩트의 통합 세트, application family를 위한 재사용 가능한 아키텍처를 제공해준다 (유사한 형태의 다양한 것들을 만들 수 있는 재사용 가능 아키텍처)

Application Architecure란?

시스템과 Component 중간정도. 뻔한 것은 concrete class로 구현, 아닌 것들은 Abstract class나 Interface로 제공한다

대표적으로 WAF가 있다.(동적 웹사이트 구축 지원, MVC, Security, Dynamic web page, db support, session 관리, User interaction)

 

Extending Framework

generic한 프레임워크를 확장해서 기본 아키텍쳐 틀에 맞게 채워 넣으면 작동하게 만든다.

 

Inversion of Control in Framework

Event loop가 떠있는 call-back 구조라, Control이 반대로 뒤집어 져있다

 

Software Product Line(중요!! 정의 보고 Software Product Line 적을 수 있어야 함)

특정 Context에서 사용하기 위해 적응되고 구성될 수 있는 일반적인 기능을 가진 응용 프로그램. generic + specific context

요구사항을 반영해서 전문화된다. Adaption은 다음과 같다.

• 구성 요소 및 시스템 구성(Component and System configuration)
  • ex) 언어(한국어, 영어)를 바꾸는 것
• 시스템에 새로운 구성 요소 추가(Adding new components to the system)
  • ex) 특수 기능을 더해주는 것
• 기존 구성 요소 라이브러리에서 선택(Selecting from a library of existing components)
• 새로운 요구 사항을 충족하기 위해 구성 요소 수정(Modifying components to meet new requirements)
  • --> customize를 해주는 것

 

Software Product Line의 Base System(외우기!!!)

• Core Components
• Configurable application components
• Specialized application components

 

Application Framework vs Product Line

공통 : 공통된 특성은 유지한다

AF : reusable한 architecture 제공, 객체 지향 기능에 의존하는 경향. 기술적 지원 제공에 중점

Product Line : 빌드할 때 공통된 부분은 그대로 두고 Special한 것만 추가. 도메인 플랫폼 정보 포함. 일반적으로 동일한 조직이 소유한 application family로 구성된다.

 

Product line의 아키텍처

configurable한 부분이 A또는 B를 선택하도록 해야 한다(조립식이라고 보면 될듯). 서브시스템을 분리하고 이를 수정할 수 있도록 한다. entity와 Description을 분리하고, 상위레벨에서는 description을 통해 엔티티에 접근한다

 

Product Line Specialization(PPEF)

Platform / Environment / Functional / Process Specialization

 

Product Instance 개발 (과정 외우기)!!

• 이해관계자 요구사항 도출 (Elicit stakeholder requirements)
• 가장 적합한 시스템 인스턴스 선택 (Choose closest-fit system instance)
• 요구사항 재협상 (Renegotiate requirements)
• 기존 시스템 적응 (Adapt existing system)
• 새 시스템 인스턴스 제공 (Deliver new system instance)

Application System Reuse란?

코드 수정 없이 개별적인 사용자에 맞춰서 설정만 조금 조정하여 사용하는 것. 휴대폰 언어 바꾸기 이런 것들

built-in configuration 메커니즘을 사용한다. 사용자의 관점으로 보는듯

 

Application System Reuse 장점은?

빠른 개발, 시스템 적합성 판단이 쉬움. dependability 확보. 개발 리스크 줄어듬. 유지보수 신경X(vendor가 해줌)

 

Application System Reuse 문제점은?

Configuration 범위를 넘어서면 Requirement를 조정해야 함

COTS 시스템 선택이 문서화 부족으로 어려울 수 있다

사용하려는 환경에 맞춰진 전문성이 부족할 수 있다COTS 벤더가 시스템 지원, evolution을 제어한다.

 

Application System의 종류에는 Configurable Application System, Integrated application system이 있다.

Configurable Application System이란?

공통된 경우가 많은 general Application. 어떤 특정 종류의 비즈니스 프로세스를 지원해줌 잠재적 사용자 범위에 필요한 기능을 제공대표적 예시가 ERP 시스템. 일반적인 비즈니스 프로세스를 지원해줌

 

Integrated Application System이란?

시스템을 통합해서 모은 하나의 Application이 원하는 기능을 제공X --> Application System 자체를 통합해 거대한 시스템 만든다

 

Integrated Application System의 디자인 기준?

• 적합한 기능성을 제공하는지
• 데이터는 어떻게 교환되는지? (포맷에 따라 변환 필요)
• 제품의 어떤 기능이 실제로 사용되는가?(70%, 80%)

 

Integrated Application System 구현?

인터페이스를 통해 Application System에 접근을 하는데, 일부 application은 서비스 인터페이스를 제공해주기도 하고, 아니면 통합하는 사람이 직접 구현해야 한다. 이 경우 Application Wrapping이 필요하다. Service wrapper를 만들어서 Service 할 수 있는 새로운 컴포넌트를 붙이는 형태로 확장한다

 

Integrated Application System 문제점?

기능/성능 제어 부족(비효과적), 상호 운용성 문제(호환이 잘 안되서 통합이 어려움), 시스템 Evolution에 대한 제어를 vendor가 하고, vendor가 지원을 오랫동안 안할 수 있음

 

RESTful webservice란?

클라이언트에서 서버로 resource representation을 전달하는 아키텍쳐 스타일이다. 과거 SOAP/WSDL에서 이 스타일로 서비스 호출을 한다.

 

Resource Operation / Access (반드시 Operation을 외우자)

Resource는 RESTful 아키텍쳐의 기본 component고, 여러가지 format으로 표현된다

CREATE(POST) / READ(GET) / UPDATE(PUT) / DELETE(DELETE)

URL을 통해서 엑세스하고, URL 쿼리를 사용할 수 있다.

 

RESTful 단점

• 서비스가 복잡한 인터페이스를 가지고 단순한 자원이 아닐 때, 이 RESTful 서비스를 설계하는 것은 어려울 수 있습니다.
• RESTful 인터페이스 설명에 대한 표준이 없어서 서비스 사용자가 인터페이스를 이해하기 위해 비공식 문서에 의존해야 합니다.
• RESTful 서비스를 사용할 때, 서비스의 품질과 신뢰성을 관리하기 위한 자체 인프라를 구현해야 합니다.
  •