소프트웨어 공학/Theorem

[소프트웨어 공학] 13. Software Reuse

lumana 2024. 5. 24. 15:27

Software reuse

  • 대부분의 공학 분야에서 시스템은 다른 시스템에서 사용된 기존 구성 요소를 조합하여 설계됩니다.
  • 소프트웨어 공학은 원래 개발에 더 집중했지만, 이제는 더 나은 소프트웨어를 더 빠르게, 더 저렴하게 달성하기 위해 체계적인 소프트웨어 재사용(systematic software reuse)에 기반한 설계 프로세스가 필요하다는 것을 인식하게 되었습니다.
    • 과거에는 커스텀 소프트웨어를 만들었지만, 현재 에자일 환경에서는 온라인 서비스 환경속에서 소프트웨어 재사용이 중요하게 되었다.
  • 지난 10년 동안 재사용 기반 개발로의 큰 전환이 있었고, 변화는 계속 진행 중입니다.

(교수님이 캡디할 때 Reuse 해서 좋은 작품을 만드는게 좋다고 합니다)

Reuse-based software engineering

  • System reuse
    • 여러 응용 프로그램을 포함할 수 있는 완전한 시스템이 재사용될 수 있습니다.
  • Application reuse
    • 응용 프로그램은 다른 응용 프로그램에 변경 없이 통합되거나 응용 프로그램 계열을 개발함으로써 재사용될 수 있습니다.
  • Component reuse
    • 하위 시스템에서 단일 객체에 이르는 응용 프로그램의 구성 요소가 재사용될 수 있습니다.
  • Object and function reuse
    • 단일 명확하게 정의된 객체나 기능을 구현하는 소규모 소프트웨어 구성 요소가 재사용될 수 있습니다.

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를 따르고 인증 받은 것을 가져다가 사용하면 된다.

Problems with reuse

Problem Explanation
Creating, maintaining, and using a component library 재사용 가능한 구성 요소 라이브러리를 채우고 소프트웨어 개발자가 이 라이브러리를 사용할 수 있도록 하는 것은 비용이 많이 듭니다. 개발 프로세스는 라이브러리를 사용하도록 조정되어야 합니다.

컴포넌트를 재사용 가능하게 만들기 위해 추가적인 노력이 들어간다.
Finding, understanding, and adapting reusable
components		 소프트웨어 구성 요소는 라이브러리에서 발견되고 이해되어야 하며, 때로는 새로운 환경에서 작동하도록 조정되어야 합니다. 엔지니어는 구성 요소 검색을 정상적인 개발 프로세스의 일부로 포함하기 전에 라이브러리에서 구성 요소를 찾을 수 있다는 합리적인 확신을 가져야 합니다.

reuse base로 할 때, requirement에 있어서 compromise가 있을 수 있다.
+ reuse component를 찾는 것 자체가 cost가 드는 것임. LLM을 사용하면 cost가 줄어들지만, Verification을 해야하기 때문에 dependability가 낮아짐
Increased maintenance
costs		 재사용된 소프트웨어 시스템이나 구성 요소의 소스 코드가 없으면 유지 보수 비용이 높아질 수 있습니다. 시스템의 재사용된 요소가 시스템 변경과 점점 더 호환되지 않을 수 있기 때문입니다.

resuable component를 가져다 쓸 때, 소유한 컴포넌트나 서비스가 아니기 때문에, 만드는 사람들이 뭔가를 바꾸는 것에 대해 우리가 컨트롤 할 수가 없어서, 바뀐 것에 맞춰서 따라야 하는 추가적인 Cost가 발생

 

Lack of tool support 일부 소프트웨어 도구는 재사용을 지원하지 않습니다. 이러한 도구를 구성 요소 라이브러리 시스템과 통합하기 어렵거나 불가능할 수 있습니다. 이 도구들이 가정하는 소프트웨어 프로세스는 재사용을 고려하지 않을 수 있습니다. 이는 임베디드 시스템 공학을 지원하는 도구에 특히 해당되며, 객체 지향 개발 도구에는 덜 해당됩니다.

요즘은 이 부분은 잘 커버됨(ex. maven의 외부 라이브러리 빌드 자동화). LLM은 이쪽 지원이 아직 부족함
Not-invented-here
syndrome		 일부 소프트웨어 엔지니어는 구성 요소를 다시 작성하는 것을 선호합니다(rewrite components). 이는 부분적으로 신뢰와 관련이 있으며, 부분적으로는 다른 사람의 소프트웨어를 재사용하는 것보다 원래 소프트웨어를 작성하는 것이 더 도전적인 것으로 여겨지기 때문입니다.

SW 엔지니어가 동일한 일을 하더라도 내가 작성한 코드를 더 신뢰하는 경향이 있다.

Reuse Perspective

Reuse Perspective(관점)을 가지고 SW 개발을 하자

내가 잘 알고 있고 이미 만들어져 있는 것들은 필요한 부분만 수정해서 가져다 사용하자

  • 소프트웨어 재사용에 익숙해지면 문제를 해결할 수 있는 특정 관점을 가질 수 있습니다.
  • 처음부터 문제를 해결하는 대신, 이미 알고 있는 구성 요소를 기반으로 솔루션을 생각할 수 있습니다.
    • Top-down vs. Bottom-up
      • Top-down : 커다란 목표를 부분으로 쪼개는 것. 이렇게 하면 from scratch로 해결해야 하는 부분이 얼마 안된다는 장점이 있음
      • Bottom-up : 부분 부분 문제를 끌어 모아서 큰 문제를 해결하는 것
    • Divide and Conquer
  • 간단한 알고리즘, 구성 요소, 더 복잡한 응용 프로그램, 프레임워크, 기술 또는 전체 시스템을 재사용할 수 있습니다.
    • 문제를 여러 가지 다른 추상화 수준에서 볼 수 있습니다.

 

레고에서 이미 조립되있는 걸 가져다가 사용하면 훨씬 더 크고 높은 건물을 지을 수 있다.

The reuse landscape

  • 재사용은 종종 시스템 구성 요소의 재사용으로만 생각되지만, 재사용에는 여러 가지 접근 방식이 있습니다.
  • 재사용은 간단한 기능에서 전체 응용 프로그램 시스템까지 다양한 수준에서 가능합니다. (Reuse is possible at a range of levels from simple functions to complete application systems)
    • low level 부터 high level까지 reuse가 가능하다
  • 재사용 지형은 가능한 재사용 기술의 범위를 다룹니다.

The reuse landscape

 

Architectural patterns 이나 Design patterns 처럼 abstract 한 것도 reuse이고, System Integration과 같이 종합적인 것도 reuse이다.

  • Figure 15.3
    • Design patterns
    • Architectural patterns
    • ERP systems
    • Application system integration
    • Application frameworks
    • Systems of systems
    • Component-based software engineering
    • Aspect-oriented software engineering
    • Software product lines
    • Configurable application systems
    • Model-driven engineering
    • Program generators
    • Program libraries
    • Service-oriented systems
    • Legacy system wrapping

Reuse planning factors

Reuse 할 때 어떤 것들을 고려해야 하는가?

  • The development schedule for the software(소프트웨어 개발 일정)
    • 소프트웨어를 빨리 개발해야 하는 경우, 개별 구성 요소보다 전체 시스템을 재사용하는 것을 고려할 수 있습니다.
  • The expected software lifetime(예상 소프트웨어 수명)
    • 장기간 사용될 시스템을 개발하는 경우, 즉각적인 재사용의 이점보다는 유지 보수성에 중점을 두어야 합니다.
    • lifetime이 길어지면 maintainability를 무시할 수 없음
  • The background, skills and experience of the development team(개발팀의 배경, 기술 및 경험)
    • 재사용 기술은 상당히 복잡하며, 이를 이해하고 효과적으로 사용하는 데 많은 시간이 필요합니다.
  • The criticality of the software and its non-functional requirements(소프트웨어의 중요성과 비기능적 요구사항)
    • 중요한 시스템의 경우, 소프트웨어 재사용이 다양한 요구사항을 충족시키는 데 어려움을 초래할 수 있습니다.
    • critical SW의 경우 NFR을 지켜야 하기 때문에 reuse가 어려울 수 있다
  • The application domain(응용 도메인)
    • 많은 응용 도메인에서는 로컬 환경에 맞추어 구성함으로써 재사용할 수 있는 일반 제품이 존재합니다.
  • The execution platform for the software will run(소프트웨어가 실행될 플랫폼)
    • 일부 재사용 가능한 구성 요소나 응용 프로그램은 플랫폼에 종속적입니다.
    • ex) Windows, Linux, .. 어디에서 SW를 돌릴 것인가 / 앱으로 만들 것인가, Web으로 만들 것인가... 등등

Framework Definition

  • "..소프트웨어 아티팩트 (classes, objects, components 등)의 통합 세트(set of software artifacts)로, 관련 응용 프로그램 패밀리(family of related applications)를 위한 재사용 가능한 아키텍처를 제공합니다."
  • 코드를 모아뒀는데, 이것들이 합쳐져서 유사한 형태의 다양한 것들을 만들 수 있는 reusable architecture를 제공한다
    • ex) Web application framework에서 html, http request 등 유사한 부분의 처리

Application Frameworks

틀이 굉장히 커서 공부할 양이 많지만, 그만큼 작업량 또한 줄어듬

  • 프레임워크는 재사용 가능한 중간 크기의 엔티티입니다 (Frameworks are moderately large entities that can be reused).
    • 시스템과 구성 요소 재사용의 중간 정도입니다.
  • 프레임워크는 추상 클래스와 구상 클래스, 그리고 이들 간의 인터페이스로 구성된 서브 시스템 설계입니다 (Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them).
    • 정말로 뻔한 것들은 concrete class(구상 클래스)로 구현해두고, 아닌 것들은 abstract class 나 interface 형태로 제공하여, 디테일 한 부분은 원하는 대로 작동하도록 코드를 작성함
    • ex) 채팅 기능에서 메시지 업로드 call-back : 서버에서 메시지를 받고 모두에게 보낸 후, 송신자에게 잘 보냈다고 응답을 받는 구조 --> 프레임워크에서 어떻게 처리해야하는지에 대한 틀을 다 만들어 둠. 이런 서브 시스템들이 다 구현이 되어있다.
  • 서브 시스템은 설계의 일부를 채우고 프레임워크 내 추상 클래스를 인스턴스화하여 구성 요소를 추가함으로써 구현됩니다.

Web Application Frameworks(WAF)

  • 동적 웹사이트 구축을 지원합니다 (Support the construction of dynamic websites).
  • 모든 일반적으로 사용되는 웹 프로그래밍 언어에 대해 사용할 수 있습니다 (e.g., JavaScript, Java, Python, Ruby 등).
  • 상호작용 모델은 Model-View-Controller 복합 패턴에 기반합니다 (Interaction model is based on the Model-View-Controller composite pattern).
    • GUI 디자인을 위한 System infrastructure 프레임워크입니다.
    • 객체의 여러 표현과 이러한 표현과의 별도 상호작용을 허용합니다.
      • model 하나로 여러 View에 뿌릴 수 있다.

The Model-View-Controller Pattern

  • Model-View-Controller 패턴

WAF Features

  • 보안 (Security)
    • 사용자 인증(로그인) 및 접근을 구현하는 클래스를 포함할 수 있습니다.
  • 동적 웹 페이지 (Dynamic web pages)
    • 웹 페이지 템플릿을 정의하고 시스템 데이터베이스에서 이를 동적으로 채울 수 있도록 도와주는 클래스를 제공합니다.
  • 데이터베이스 지원 (Database support)
    • 다양한 데이터베이스에 대한 추상 인터페이스를 제공하는 클래스를 프레임워크가 제공할 수 있습니다.
    • ex) NoSQL에서 Json으로 받고 파싱한 후 출력해주는 것
  • 세션 관리 (Session management)
    • 시스템과 사용자의 여러 상호작용(= 세션)을 생성하고 관리하는 클래스를 포함할 수 있습니다.
  • 사용자 상호작용 (User interaction)
    • 대부분의 웹 프레임워크는 이제 AJAX 지원을 제공하여 보다 인터랙티브(interactive)한 웹 페이지를 생성할 수 있습니다.

Extending Frameworks

generic 한 걸 확장해서 Skeleton architecture를 제공함으로써 틀에 맞게 채워 넣으면 작동하도록 함. (Concrete class를 추가하거나, 기존 operation을 override 하는 등)

 

ex) 부동산 관련 스타트업 CTO라고 해보자. 이 서비스에서 지도는 공통적으로 보여지기 때문에, 내부적으로 concrete class를 구현하고 돌려 쓴다.(이런 것들을 만드는 팀이 따로 존재하는 경우도 있음)

  • 프레임워크는 일반적이며 특정 응용 프로그램 또는 서브 시스템을 만들기 위해 확장됩니다 (Frameworks are generic and are extended to create a more specific application or sub-system).
    • 시스템에 대한 기본 아키텍처를 제공합니다.
  • 프레임워크 확장에는 다음이 포함됩니다 (Extending the framework involves):
    • 프레임워크 내 추상 클래스에서 작업을 상속하는 구체 클래스를 추가합니다.
    • 프레임워크에서 인식하는 이벤트에 반응하는 메서드를 추가합니다.
  •  프레임워크의 문제는 복잡성 때문에 이를 효과적으로 사용하는 데 시간이 많이 걸린다는 점입니다.
    • architecture level로 진행되기 때문에 상당히 복잡함 --> 공부해야할 내용이 많다

Inversion of Control in Frameworks

  • 프레임워크에서 제어의 역전 (Inversion of control in frameworks)

예를 들면 테트리스의 GUI나 웹을 생각해볼 수 있다.

메인 함수에서 쭈루룩 실행되는게 아니라, 각자 기능에 대해 Event Loop이 돌아가면서 떠있는 상태이다.

이런 구조에서 보통 Callback을 한다

application specific class들이 event loop에 대해서 요청을 하는데, 이런 event 가 발생하면 이 함수를 실행하게 해주는 것을 Call back 이라고 함 (ex. Tetris Listener : 이 이벤트가 발생하면 이 함수를 불러줘. 사용자가 이 마우스를 클릭하면 이 함수를 불러줘)

즉 Control이 반대로 뒤집어 지는것을 말함

Software Product Lines

유사한 application이지만 디테일이 다른 것들을 모아두거나 관리하기 위한 방식을 말함

  • 소프트웨어 제품 라인 또는 응용 프로그램 패밀리는 특정 컨텍스트에서 사용하기 위해 적응되고 구성될 수 있는 일반적인 기능을 가진 응용 프로그램입니다 (Software product lines or application families are applications with generic functionality that can be adapted and configured for use in a specific context).
    • generic + specific context
  • 소프트웨어 제품 라인은 공통 아키텍처 및 공유 구성 요소를 가진 응용 프로그램 집합으로, 각 응용 프로그램은 다른 요구 사항을 반영하여 전문화됩니다 (A software product line is a set of applications with a common architecture and shared components, with each application specialized to reflect different requirements).
  • 적응에는 다음이 포함될 수 있습니다 (Adaptation may involve):
    • 구성 요소 및 시스템 구성(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를 해주는 것

Base Systems for a Software Product Line

소프트웨어 제품 라인을 위한 기본 시스템

  • 핵심 구성 요소 (Core components)
  • 구성 가능한 응용 프로그램 구성 요소 (Configurable application components)
    • 기존과 유사하지만 살짝 다른 것
  • 전문화된 응용 프로그램 구성 요소 (Specialized application components)
    • 완전히 새로운 기능을 추가하는 경우

Base Applications

기본 응용 프로그램 (Base applications)

 

휴대폰과 같은 임베디드 시스템을 예로 들어보자. 

Core component - 전화기 통신 기능

Configurable component - 국가별 인터페이스 번호

Specialized domain specific - 국가 종교에 맞춘 기능. ex) 중동 지역에서 절하는 시간과 방향에 대한 알림

  • 핵심 구성 요소 (Core components): 인프라 지원을 제공합니다.
    • 제품 라인의 새로운 인스턴스를 개발할 때 일반적으로 수정되지 않습니다.
  • 구성 가능한 구성 요소 (Configurable components): 새로운 응용 프로그램에 맞게 수정되고 구성될 수 있습니다.
    • 내장된 구성 언어를 사용하여 코드 변경 없이 이러한 구성 요소를 재구성할 수 있는 경우도 있습니다.
  • 전문화된 도메인 특정 구성 요소 (Specialized, domain-specific components): 제품 라인의 새 인스턴스를 생성할 때 일부 또는 전체가 교체될 수 있습니다.

Application Frameworks and Product Lines

응용 프로그램 프레임워크와 제품 라인 (Application frameworks and product lines)

 

Application frameworks 는 resuable한 아키텍쳐를 제공해줌. 각 application은 다르지만 공통된 특성은 유지된다는 점에서 product line과 유사함. 하지만 따로 다룬다. Application frameworks는 object-oriented feature에 의존하는 경향이 있음. Product line은 그렇지 않음. 빌드할 때 공통된 부분은 그대로 두고, Special 한 것만 추가함

  • 응용 프로그램 프레임워크는 다형성(polymorphism)과 같은 객체 지향 기능을 활용하여 확장을 구현합니다.
    • 제품 라인은 반드시 객체 지향일 필요는 없습니다.
  • 응용 프로그램 프레임워크는 도메인 특정 지원보다는 기술적 지원 제공에 중점을 둡니다.
    • 제품 라인은 도메인 및 플랫폼 정보를 포함합니다.
  • 제품 라인은 종종 장비의 응용 프로그램을 제어합니다.
  • 소프트웨어 제품 라인은 일반적으로 동일한 조직이 소유한 응용 프로그램 패밀리로 구성됩니다.
    • ex) 판매하는 나라에 따라서 조금씩 변경해서 판매

Product Line Architectures

제품 라인 아키텍처 (Product line architectures)

 

 

Configurable 한 부분이 A 또는 B를 선택할 수 있도록 해야 한다.

  • 아키텍처는 서로 다른 서브 시스템을 분리하고 이를 수정할 수 있도록 구조화되어야 합니다.
  • 아키텍처는 엔티티와 description을 분리해야 하며,
    • 시스템의 상위 레벨은 직접적으로가 아닌 description을 통해 엔티티에 접근해야 합니다.

Product Line Specialization

제품 라인 특성화 (Product line specialization)

  • 플랫폼 특성화 (Platform specialization): 응용 프로그램의 다양한 버전이 다른 플랫폼용으로 개발됩니다.
  • 환경 특성화 (Environment specialization): 응용 프로그램의 다양한 버전이 다른 운영 환경을 처리하기 위해 생성됩니다.
  • 기능 특성화 (Functional specialization): 고객의 다양한 요구 사항을 반영하여 응용 프로그램의 다양한 버전이 생성됩니다.
  • 프로세스 특성화 (Process specialization): 다양한 비즈니스 프로세스를 지원하기 위해 응용 프로그램의 다양한 버전이 생성됩니다.
    • ex) 규제 방식 : 오후 6시 이후에 시스템을 shutdown해서 업무를 못하게 만듬

Product Instance Development

제품 인스턴스 개발 (Product instance development)

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

 

강의 예시)

 

 

A - Z 인스턴스를 골랐더니(Choose closest-fit system instance) 50개중 45개를 만족함

나머지 5개 중에서 2개는 어려운 부분이니 포기하고(Renegotiate requirements), 나머지 3개는 adaptation을 통해서 처리한다.(Adapt existing system) --> 빠른 시간에 Deliver new system instance

 

만약 처음에 잘못 고르면 50개 중에서 30개만 만족해서 20개를 만들어야 할 수도 있다.

최선이 30개라도, 나머지 20개 중에서 기존 회사에서 만든 게 있으면 빠르게 처리할 수 있다.

Application System Reuse

응용 시스템 재사용 (Application system reuse)

  • 응용 시스템 제품은 소스 코드를 변경하지 않고도 다른 고객에게 맞게 조정할 수 있는 소프트웨어 시스템입니다(An application system product is a software system that can be adapted for different customers without changing the source code of the system).
    • 코드를 수정하지 않고, 개별적인 사용자에 맞춰서 설정만 조금 바꿔서 사용하는 것
  • 응용 시스템은 일반적인 기능을 가지며 다양한 환경에서 사용/재사용될 수 있습니다.
    • ex) 노트북 구매 시 OS 설정(사용자 이름, 나라, 언어 등등)
  • 응용 시스템 제품은 종종 특정 고객 요구에 맞게 시스템 기능을 조정할 수 있는 내장된 구성 메커니즘(built-in configuration mechanism)을 사용하여 조정됩니다.
    • 설정하는 과정을 거쳐서 적용해 사용하게 된다 
    • 예를 들어, 병원 환자 기록 시스템에서는 서로 다른 환자 유형을 위해 별도의 입력 양식 및 출력 보고서를 정의할 수 있습니다.
    • ex) 설정만을 가지고 application 기능을 특정 기관에 맞춰서 충분히 사용 가능함

Benefits of Application System Reuse

응용 시스템 재사용의 이점 (Benefits of application system reuse)

 

개발 과정이 코드를 짜는 과정이 아니라, 시스템에서 설정값만 바꾸기 때문에 훨씬 빠르게 deployment가 가능하다

  • 다른 유형의 재사용과 마찬가지로, 신뢰할 수 있는 시스템의 더 빠른 배포(more rapid development of a reliable system)가 가능할 수 있습니다.
  • 응용 프로그램이 제공하는 기능을 볼 수 있기 때문에 이들이 적합한지 여부를 판단하기 더 쉽습니다(it is easier to judge whether or not they are likey to be suitable).
  • 기존 소프트웨어를 사용함으로써 '일부' 개발 리스크를 피할 수 있습니다('Some' development risks are avoided).
    • dependability를 일정 수준 이상으로 쉽게 확보할 수 있다. configuration으로 끝나기 때문에 개발 기간이 길어지거나 cost가 많이 드는 일이 적게 발생한다
  • 비즈니스는 IT 시스템 개발에 많은 자원을 할애하지 않고 핵심 활동에 집중(can focus on their core activity)할 수 있습니다.
    • 기존에 존재하는 system의 configuration을 통해서 사용하기 때문에, maintenance와 같은 요소를 신경 쓸 필요가 없다. Vendor하고 계약 관계를 잘 유지하면 된다.
  • 플랫폼이 발전함에 따라 기술 업데이트(technology updates)가 단순화될 수 있습니다. 이는 고객이 아닌 COTS 제품 공급업체의 책임(the responsibility of the COTS product vendor)입니다.
    • ex)어디에든 다 AI를 추가하는 현대 산업 트랜드를 생각해보자. application system 전체를 reuse 하는 상황에서 AI를 도입한다는 것은 application system을 개발하는 회사의 책임이다. 어떻게 도입하고 어떻게 개발할 지 고민할 필요가 없다. COTS product vendor가 알아서 개발, 광고, 판매할거다.

Problems of Application System Reuse

응용 시스템 재사용의 문제점 (Problems of application system reuse)

  • 요구 사항은 COTS 제품의 기능 및 운영 모드를 반영하도록 일반적으로 조정되어야 합니다(Requirements usually have to be adapted).
    • configuration의 범위를 넘어서면 Requirement는 타협을 해야 한다. 결국 Application system에 사람이 맞춰야 한다.
  • COTS 제품은 변경이 사실상 불가능한 가정에 기반할 수 있습니다.
  • 기업에 적합한 COTS 시스템을 선택(Chossing the right COTS system)하는 것은 특히 많은 COTS 제품이 잘 문서화되어 있지 않기 때문에 어려운 과정이 될 수 있습니다.(can be a difficult process)
    • 시스템을 구매하는 담당자가 전문가가 아니라, 시스템 적합성 평가가 쉽지 않은 문제임
  • 시스템 개발을 지원할 현지 전문 지식이 부족할 수 있습니다(a lack of local expertise to support systems development).
    • 우리가 사용하는 환경에 맞춰진 전문성이 떨어질 수 있다.
  • COTS 제품 공급업체가 시스템 지원 및 진화를 제어합니다.

Configurable Application Systems

구성 가능한 응용 시스템 (Configurable application systems)

 

어떤 특정 종류의 buisness process를 지원해준다(공통된 경우가 많기 때문)

  • 구성 가능한 응용 시스템은 특정 비즈니스 유형, 비즈니스 활동 또는 때로는 전체 비즈니스 엔터프라이즈를 지원하도록 설계될 수 있는 일반 응용 시스템입니다.
    • 예를 들어, 약속, 치과 기록, 환자 회상 등을 처리하는 치과 의사를 위한 응용 시스템이 제작될 수 있습니다.
    • ex) 식당 테이블 오더 시스템 : 메뉴만 설정해주면 됨
  • 비즈니스 기능(예: 문서 관리)을 지원하기 위한 도메인 특정 시스템은 잠재적 사용자 범위에 필요한 기능을 제공합니다.

ERP systems

  • ERP 시스템 (ERP systems)
    • 전사적 자원 관리 시스템 (Enterprise Resource Planning, ERP system)은 주문 및 송장 발행, 제조 등의 일반적인 비즈니스 프로세스를 지원하는 범용 시스템입니다.
    • 이러한 시스템은 대기업에서 매우 널리 사용되며, 소프트웨어 재사용의 가장 일반적인 형태를 나타냅니다.
      • 이는 더 이상 사실이 아닐 수 있습니다. 데이터 분석 및 머신러닝을 위한 클라우드 서비스의 급속한 성장 때문입니다.
    • 일반적인 코어는 모듈을 포함하고 비즈니스 프로세스 및 규칙에 대한 지식을 통합하여 적응됩니다.

여담)

독일의 SAP 사 : ERP 시스템을 개발하는 회사

SAP나 Salesforce 같은 회사는 재사용 가능한 SW를 판매한다.

Integrated application systems

통합 애플리케이션 시스템 (Integrated application systems)  

 

System Integration 여러 개를 모은 하나의 Application system이 원하는 기능을 모두 제공하지 않는다면 Application system을 재사용, 통합해서 거대한 시스템을 만들수 있다.

  • 통합 애플리케이션 시스템은 두 개 이상의 애플리케이션 시스템 제품 및/또는 레거시 애플리케이션 시스템을 포함하는 애플리케이션입니다.
  • 단일 애플리케이션 시스템이 모든 요구를 충족하지 못하거나, 이미 사용 중인 시스템과 새 애플리케이션 시스템을 통합하고자 할 때 이 접근 방식을 사용할 수 있습니다.

 

ex) 우리학교 통합정보 시스템을 생각해보자.

강의 계획서를 보여주거나 pdf로 보여주는 application system

학교 이메일 application system, 보고서 시스템, 통계 시스템, 프로파일 시스템, authentication 시스템

이런 application 시스템을 다 통합한다

Design choices

  • 디자인 선택 (Design choices)
    • 어떤 개별 애플리케이션 시스템이 가장 적합한 기능성을 제공하는가?
      • 일반적으로 여러 애플리케이션 시스템 제품이 제공되며, 이를 다양한 방식으로 결합할 수 있습니다.
    • 데이터는 어떻게 교환될 것인가?
      • 서로 다른 제품은 일반적으로 고유한 데이터 구조 및 형식을 사용합니다. 한 표현에서 다른 표현으로 변환하는 어댑터를 작성해야 합니다.
      • ex) 사용자 정보, 사용자가 작상한 게시글의 Data format이 조금씩 다를 수 있다. 시스템 간에 데이터 전송에 형식 변환을 해줘야 함
    • 제품의 어떤 기능이 실제로 사용될 것인가?
      • 개별 애플리케이션 시스템에는 필요 이상으로 더 많은 기능이 포함될 수 있으며, 기능성이 다양한 제품에 걸쳐 중복될 수 있습니다.
      • 전체 application system이 제공하는 기능의 전부를 사용하지 않고 70%만 사용한다고 해보자. 나머지를 다른 시스템에서 가져온다고 해도, 기존 시스템이랑 겹치기도 하고, 100%를 채우지 못하는 등 딱 맞아 떨어지는 시스템이 없을 수 있다. 조합을 할 때 최소 비용으로 최대 효과를 내야 한다. 일종의 knapsack problem 같은 것

Service-oriented interfaces

서비스 지향 인터페이스 (Service-oriented interfaces) 

 

ex) 프론트엔드와 백엔드를 생각해보자. 보통 프론트는 백엔드의 떠있는 형태로, api call을 통해서 화면을 구성한다

어떤 쇼핑몰에서 카카오페이, 네이버 페이를 사용하겠다는 것은, 페이가 떠있는 형태이다.

코드를 가져와서 쓸 수 있지만, 외부 서비스를 불러다가 사용할 수 있다. (ex. 지도, 페이)

또한 반대로 내가 직접 서비스를 만들어서 제공해줄 수 있따.

  • 서비스 지향 접근 방식을 사용하면 애플리케이션 시스템 통합이 단순화될 수 있습니다.
  • 서비스 지향 접근 방식은 표준 서비스 인터페이스를 통해 애플리케이션 시스템의 기능에 접근을 허용하며, 각 개별 기능 단위에 대한 서비스를 제공합니다.
    • 각각의 단위 기능을 제공해주는 서비스들을 호출하는 방식으로 연결해서 접근하는 형태
  • 일부 애플리케이션은 서비스 인터페이스를 제공할 수 있지만, 때로는 이 서비스 인터페이스를 시스템 통합자가 구현해야 합니다.
    • 애플리케이션을 숨기고 외부에서 볼 수 있는 서비스를 제공하는 래퍼를 프로그래밍해야 합니다.

Application wrapping

Application system이 legacy system인 경우 Service wrapper를 구성한다. Application System을 그대로 나두고, Service를 이용할 수 있는 새로운 Component를 붙이는 형태로 legacy system을 확장할 수 있다.

앱 개발의 경우에도, 네이티브로 처리해야 하는 부분은 남겨두고, 서버에서 처리할 수 있는 부분은 Application System을 두고 App에서 Application System을 부르는 형태로(클라이언트 서버 구조) 처리할 수 있다.

이런 식으로 Service-oriented가 구현된다.

  • 애플리케이션 래핑 (Application wrapping) 
    • (서비스 래퍼 (Service wrapper)가 애플리케이션 시스템을 둘러싸고 있습니다.)
    • (애플리케이션 시스템과 서비스 사이에 상호 작용이 있습니다.)

Application system integration problems

  • 애플리케이션 시스템 통합 문제 (Application system integration problems)
    • 기능 및 성능에 대한 제어 부족(Lack of control over functionality and performance)
      • 애플리케이션 시스템이 생각보다 덜 효과적일 수 있습니다.
    • 애플리케이션 시스템 상호 운용성 문제(Problems with application system inter-operability)
      • 서로 다른 애플리케이션 시스템이 통합을 어렵게 만드는 다른 가정을 할 수 있습니다.
      • 쉽게 말하면, 우리가 원하는 기능을 제공해주는 시스템 두 개를 선정했는데, 두 개가 호환이 안되서 상호작용을 제대로 못할 수 있다.
    • 시스템 진화에 대한 제어 부족(No control over system evolution)
      • 애플리케이션 시스템 벤더가 아닌 시스템 사용자가 시스템 진화를 제어합니다.
      • System vendor에서 evolution control을 하니까, 우리는 손 댈수가 없다.
    • 시스템 벤더의 지원(Support from system vendors)
      • 애플리케이션 시스템 벤더는 제품의 수명 동안 지원을 제공하지 않을 수 있습니다.
      • 단순히 AS 기간이라고 생각하면 됨

RESTful web services

RESTful 웹 서비스 (RESTful web services)

 

과거 웹 서비스에는 SOAP/WSDL을 사용했는데, heavyweight 해서 아무도 사용하지 않았다.

--> 요즘 REST라는 아키텍쳐 스타일로 서비스를 호출하고 접근한다.

  • 과거의 웹 서비스 표준은 '무거운(heavyweight)' 표준으로 비판받았으며, 이는 과도하게 일반적(over-general)이고 비효율적입니다.
  • REST (Representational State Transfer)는 클라이언트로부터 서버로 자원 표현을 전달하는 아키텍처 스타일입니다.
  • 이 스타일은 웹 전체를 기반으로 하며, 웹 서비스를 구현하는 데 SOAP/WSDL보다 단순합니다.
  • RESTful 서비스는 소위 '대규모 웹 서비스'보다 낮은 오버헤드를 가지며(+ 사용하기도 쉬움), 많은 조직에서 서비스 기반 시스템을 구현할 때 사용됩니다.

Resources

자원 (Resources)

== Data element

  • RESTful 아키텍처의 기본 요소는 자원입니다.
  • 본질적으로, 자원은 카탈로그, 의료 기록, 문서(예: 이 책 장)와 같은 데이터 요소일 뿐입니다.
  • 일반적으로, 자원은 여러 표현을 가질 수 있습니다.
    • 즉, 서로 다른 형식으로 존재할 수 있습니다.
    • RTF, DOCX, PDF, HWP?
    • JSON은 최근에 XML의 위치를 대체하는 인기 있는 형식입니다 (아마도 YAML?).

Resource operations

  • 자원 작업 (Resource operations)
    • 생성 (Create) – 자원을 생성합니다.
    • 읽기 (Read) – 자원의 표현을 반환합니다.
    • 업데이트 (Update) – 자원의 값을 변경합니다.
    • 삭제 (Delete) – 자원을 접근할 수 없게 만듭니다.
    • 이러한 작업은 종종 CRUD 작업이라고 불립니다.
      • 데이터베이스 관리 시스템의 기본 작업이기도 합니다.

Resources and actions

  • 자원과 동작 (Resources and actions)

READ : GET

UPDATE : PUT(자바 collection에 있는 map에 put 하는 것을 생각해보자)

CREATE : POST

DELETE : DELETE

 

위 4개는 반드시 알아야 하는 상식이라

Operation functionality(작업 기능)

  • POST는 자원을 생성하는 데 사용됩니다. 자원을 정의하는 관련 데이터가 포함되어 있습니다.
    • POST is used to create a resource. It has associated data that defines the resource.
  • GET는 자원의 값을 읽고 이를 XHTML과 같이 웹 브라우저에서 렌더링할 수 있는 지정된 표현으로 요청자에게 반환하는 데 사용됩니다.
    • GET is used to read the value of a resource and return that to the requestor in the specified representation, such as XHTML, that can be rendered in a web browser.
  • PUT는 자원의 값을 업데이트하는 데 사용됩니다.
    • PUT is used to update the value of a resource.
  • DELETE는 자원을 삭제하는 데 사용됩니다.
    • DELETE is used to delete the resource.

Resource access

Query results

Disadvantages of RESTful approach

WSAP나 SOAP는 Standard를 잘 작성해뒀기 때문에, 오히려 사용하기 어려웠다.

RESTful은 표준을 잘 따른다는 보장이 없기 때문에 인터에피스를 신경써야 한다.

ex) Request에 돌아오는 응답에 대해 Exception handling을 잘 처리해줘야 한다(Reliabiltiy Programming 관점에서 신경쓰자)

  • 서비스가 복잡한 인터페이스를 가지고 단순한 자원이 아닐 때, 이 RESTful 서비스를 설계하는 것은 어려울 수 있습니다.
  • RESTful 인터페이스 설명에 대한 표준이 없어서 서비스 사용자가 인터페이스를 이해하기 위해 비공식 문서에 의존해야 합니다.
    • There are no standards for RESTful interface description so service users must rely on informal documentation to understand the interface.
  • RESTful 서비스를 사용할 때, 서비스의 품질과 신뢰성을 관리하기 위한 자체 인프라를 구현해야 합니다.
    • When you use RESTful services, you have to implement your own infrastructure for monitoring and managing the quality of the service and the service reliability.

'소프트웨어 공학 > Theorem' 카테고리의 다른 글

[소프트웨어 공학] 12. Safety Engineering  (0) 2024.05.17
[소프트웨어 공학] 11. Reliability Engineering  (0) 2024.05.17
[소프트웨어 공학] 10. Dependable Systems  (0) 2024.05.14
[소프트웨어 공학] 09. Software Evolution  (0) 2024.05.10
[소프트웨어 공학] 08. Software Testing  (0) 2024.05.09

'소프트웨어 공학/Theorem'의 다른글

  • 현재글[소프트웨어 공학] 13. Software Reuse

관련글

티스토리툴바