Topics covered

• The reuse landscape
• Application frameworks
• Software product lines
• Application system reuse
• RESTful services
• Software reuse with LLM

Software reuse

• In most engineering disciplines, systems are designed by composing existing components that have been used in other systems.
• Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need a design process that is based on systematic software reuse.
• There has been a major switch to reuse-based development over the past 10 years and the change is on-going.

소프트웨어 재사용
많은 공학 분야에서 시스템을 설계할 때 다른 시스템에서 사용되었던 기존의 구성요소를 조합하여 사용하는 것이 일반적입니다. 이는 그 구성요소들이 검증되어 작동하는 것으로 알려져 있기 때문에 이를 활용하면 시간을 절약하고 오류나 문제 발생 가능성을 줄일 수 있습니다.

그러나 소프트웨어 공학 분야에서는 새로운, 독창적인 소프트웨어를 생성하는데 초점을 맞추는 경향이 있었습니다. 이는 소프트웨어 재사용이 더 나은 품질의 소프트웨어를 빠르고 저렴하게 만드는 데 도움이 됨을 인식하면서 변하고 있습니다.

재사용 기반 개발로의 전환은 지난 10년 동안 크게 두드러졌고, 이러한 변화는 현재도 계속되고 있습니다. 이는 효율성 증대, 신뢰성 향상, 개발 비용 절감 등의 이점 때문입니다.

Reuse-based software engineering

• System reuse
  • Complete systems, which may include several application programs may be reused.
• Application reuse
  • An application may be reused either by incorporating it without change into other or by developing application families.
• Component reuse
  • Components of an application from sub-systems to single objects may be reused.
• Object and function reuse
  • Small-scale software components that implement a single well-defined object or function may be reused.

재사용 기반 소프트웨어 공학
이는 새로운 시스템에서 소프트웨어 구성요소의 재사용을 강조하는 소프트웨어 공학의 방법론입니다. 소프트웨어가 재사용될 수 있는 여러 단계가 있습니다:

1. 시스템 재사용: 이는 여러 응용 프로그램을 포함할 수 있는 전체 시스템의 재사용입니다. 동일한 소프트웨어 세트를 다른 기기 간에 사용하는 것부터, 다른 기계 간에 전체 운영 체제를 재사용하는 것까지 다양합니다.

2. 응용 프로그램 재사용: 여기서는 전체 응용 프로그램이 재사용되며, 변경 없이 다른 시스템에 통합되거나 응용 프로그램 패밀리를 개발하는 방식으로 재사용될 수 있습니다. 응용 프로그램 패밀리란 공통 기능을 공유하지만 특정 사용 사례에 맞게 맞춤화된 응용 프로그램 그룹을 의미합니다.

3. 구성요소 재사용: 이는 응용 프로그램의 일부를 재사용하는 것을 말합니다. 전체 서브시스템부터 개별 객체까지 응용 프로그램의 구성요소를 재사용할 수 있습니다. 이미 검증된 기존 소프트웨어를 활용하여 모든 것을 처음부터 작성하는 대신 새로운 응용 프로그램을 구축하는데 효율적일 수 있습니다.

4. 객체와 함수 재사용: 가장 작은 단위에서는 개별 객체나 함수를 재사용할 수 있습니다. 이는 객체 지향 프로그래밍에서 일반적인 방법으로, 클래스와 메소드를 다른 프로그램 간에 재사용할 수 있습니다. "잘 정의된" 객체나 함수란 명확하고 특정한 목적을 가진 것으로, 새로운 소프트웨어 시스템에 쉽게 통합될 수 있는 것을 말합니다.

재사용의 수준은 특정 프로젝트, 그 요구사항, 그리고 사용 가능한 기존 소프트웨어에 따라 달라집니다. 재사용 기반 소프트웨어 공학의 주요 도전 과제는 프로젝트의 목표와 제약 조건을 충족하는 방식으로 적합한 구성요소를 찾고 통합하는 것입니다. 이는 좋은 디자인과 아키텍처 실무, 그리고 재사용된 구성요소가 새로운 상황에서 올바르게 작동하는지 확인하기 위한 엄격한 테스트가 필요합니다.

Benefits of software reuse

Benefits	Explanation
Accelerated development	Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time may be reduced.
Effective use of specialists	Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge.
Increased dependability	Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed.
Lower development costs	Development costs are proportional to the size of the software being developed. Reusing software means that fewer lines of code have to be written.
Reduced process risk	The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused.
Standards compliance	Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface.

1. 개발 속도 향상: 종종 전체 개발 비용보다 시스템을 시장에 최대한 빨리 출시하는 것이 더 중요합니다. 소프트웨어를 재사용하면 개발 및 검증 시간이 줄어들 수 있으므로 시스템 생산 속도가 빨라질 수 있습니다.

2. 전문가의 효과적인 활용: 응용 전문가들이 반복적으로 같은 작업을 수행하는 대신, 그들의 지식을 캡슐화하는 재사용 가능한 소프트웨어를 개발할 수 있습니다. 이렇게 하면 전문 지식을 최대한 활용하면서도 효율적으로 작업할 수 있습니다.

3. 신뢰성 향상: 실제 시스템에서 시험되고 검증된 소프트웨어를 재사용하면, 새로운 소프트웨어보다 더욱 신뢰할 수 있습니다. 재사용되는 소프트웨어는 그 설계와 구현에서 나올 수 있는 결함이 이미 발견되고 수정되었을 가능성이 높기 때문입니다.

4. 개발 비용 절감: 개발 비용은 개발되는 소프트웨어의 크기에 비례합니다. 소프트웨어를 재사용하면 작성해야 하는 코드의 줄 수가 줄어들므로 개발 비용을 절감할 수 있습니다.

5. 프로세스 위험 감소: 기존 소프트웨어의 비용은 이미 알려져 있지만, 개발 비용은 항상 판단의 문제입니다. 이는 프로젝트 비용 추정에서의 오차 범위를 줄이는 데 중요한 요소로, 특히 서브시스템과 같은 상대적으로 큰 소프트웨어 구성 요소를 재사용할 때 그러합니다.

6. 표준 준수: 사용자 인터페이스 표준과 같은 일부 표준은 재사용 가능한 컴포넌트의 세트로 구현될 수 있습니다. 예를 들어, 사용자 인터페이스의 메뉴가 재사용 가능한 컴포넌트를 사용하여 구현되면, 모든 응용 프로그램이 사용자에게 동일한 메뉴 형식을 제공합니다. 표준 사용자 인터페이스를 사용하면 사용자가 익숙한 인터페이스를 제공할 때 실수를 줄일 수 있으므로 신뢰성이 향상됩니다.

재사용 가능한 소프트웨어 개발의 이점은 매우 다양하며, 기업이 소프트웨어를 더 빠르게, 더 효과적으로, 더 신뢰성 있게 개발하고 유지할 수 있게 합니다. 그러나 재사용 가능한 설계를 위해서는 추가적인 계획과 투자가 필요하며, 재사용 가능한 소프트웨어를 효과적으로 관리하고 통합하기 위한 전략이 필요합니다.

Problems with reuse

Problem	Explanation
Creating, maintaining, and using a component library	Populating a reusable component library and ensuring the software developers can use this library can be expensive. Development processes have to be adapted to ensure that the library is used.
Finding, understanding, and adapting reusable components	Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they include a component search as part of their normal development process.
Increased maintenance costs	If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes.
Lack of tool support	Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools.
Not-invented-here syndrome	Some software engineers prefer to rewrite components because they believe they can improve on them. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people’s software.

１. 컴포넌트 라이브러리 생성, 유지, 사용: 재사용 가능한 컴포넌트 라이브러리를 구축하고 소프트웨어 개발자가 이 라이브러리를 사용할 수 있도록 보장하는 것은 비용이 많이 들 수 있습니다. 라이브러리가 사용되도록 개발 과정을 적응시켜야 합니다.

2. 재사용 가능한 컴포넌트 찾기, 이해하기, 적응하기: 소프트웨어 컴포넌트는 라이브러리에서 발견되어야 하며, 이해되고, 때때로는 새로운 환경에서 작동하도록 적응시켜야 합니다. 엔지니어들은 일반적인 개발 과정의 일부로 컴포넌트 검색을 포함하기 전에 라이브러리에서 컴포넌트를 찾을 수 있을 것이라는 합리적인 확신이 필요합니다.

3. 유지보수 비용 증가: 재사용된 소프트웨어 시스템이나 컴포넌트의 소스 코드가 사용할 수 없다면 유지보수 비용이 더 높아질 수 있습니다. 왜냐하면 시스템의 변경에 따라 재사용된 요소가 점점 더 호환성이 없어질 수 있기 때문입니다.

4. 도구 지원 부족: 일부 소프트웨어 도구는 재사용을 지원하지 않습니다. 이런 도구들을 컴포넌트 라이브러리 시스템과 통합하는 것이 어렵거나 불가능할 수 있습니다. 이러한 도구가 가정하는 소프트웨어 프로세스는 재사용을 고려하지 않을 수 있습니다. 이는 특히 내장 시스템 엔지니어링을 지원하는 도구에 대해 맞는 말이며, 객체 지향 개발 도구에 대해서는 그렇지 않을 수 있습니다.

5. 여기서 발명되지 않은 증후군: 일부 소프트웨어 엔지니어들은 그들이 그것들을 개선할 수 있다고 믿기 때문에 컴포넌트를 다시 작성하는 것을 선호합니다. 이것은 부분적으로는 신뢰와 관련이 있고, 부분적으로는 다른 사람들의 소프트웨어를 재사용하는 것보다 원래의 소프트웨어를 작성하는 것이 더 도전적이라는 인식과 관련이 있습니다. 이 문제는 개발자의 심리적 요인과 관련이 있으며, 때로는 이것이 재사용을 방해하는 주요 요인이 될 수 있습니다.

따라서, 재사용 가능한 소프트웨어 구조를 만드는 것은 많은 이점을 가질 수 있지만, 관련된 몇 가지 중요한 문제와 도전 과제들이 존재합니다. 이러한 문제들은 설계, 개발, 유지보수 프로세스에 대한 깊은 이해와 함께 적절한 도구와 절차를 사용함으로써 극복될 수 있습니다. 이러한 문제들을 이해하고 해결하는 것은 소프트웨어 재사용 전략의 중요한 부분이며, 이는 효율적이고 효과적인 소프트웨어 개발을 위한 핵심적인 요소입니다.

Reuse Perspective

• Once you get familiar with software reuse, you can have a certain perspective to solve a problem.
• Instead of tackling the problem from scratch, you can think of a solution based on components you've already known.
  • Top-down vs. Bottom-up
  • Divide and Conquer
• You may reuse simple algorithms, components, more complex applications, frameworks, technologies, or even an entire system.
  • You can view a problem in many different abstraction levels.

1.기존 컴포넌트를 기반으로 문제 해결: 처음부터 문제를 해결하는 대신, 이미 알고 있는 컴포넌트를 기반으로 솔루션을 생각해볼 수 있습니다. 이 접근법은 상향식(Bottom-up) 방법과 하향식(Top-down) 방법, 그리고 '분할하여 정복하라(Divide and Conquer)' 원칙을 적용하는 데 있어 중요한 부분입니다.

• 하향식 접근법(Top-down): 큰 문제를 작은 부분으로 나누어 이해하고 해결하는 접근법입니다. 상위 레벨의 설계를 먼저 수행하고, 그 다음에 점점 세부적인 설계를 진행합니다.
• 상향식 접근법(Bottom-up): 문제의 세부적인 부분에서 시작하여 전체를 구성하는 방식입니다. 이 방식은 이미 잘 정의된 하위 컴포넌트가 있을 때 효과적입니다.
• 분할하여 정복하라(Divide and Conquer): 큰 문제를 작은, 쉽게 해결할 수 있는 부분으로 나누어 해결하는 전략입니다. 각 부분은 독립적으로 해결할 수 있으며, 이러한 부분들을 다시 결합하여 전체 문제를 해결합니다.

2.다양한 수준에서의 재사용: 당신은 간단한 알고리즘부터, 컴포넌트, 더 복잡한 응용 프로그램, 프레임워크, 기술, 심지어 전체 시스템까지 재사용할 수 있습니다. 이렇게 문제를 여러 다른 추상화 수준에서 볼 수 있습니다. 이는 '소프트웨어 재사용' 개념을 넓게 적용하는 것을 의미하며, 이러한 재사용의 범위는 프로젝트의 특정 요구 사항과 상황에 따라 달라집니다.

위의 그림은 소프트웨어 개발의 다양한 단계에서 재사용 가능한 요소들을 나타냅니다. 이는 소프트웨어 재사용이 단순히 코드 또는 컴포넌트 수준에서만 이루어지는 것이 아니라, 더 높은 추상화 수준에서도 이루어질 수 있음을 보여줍니다.

• 알고리즘(Algorithms): 이는 문제를 해결하기 위한 단계적인 절차입니다. 이미 알려진 알고리즘이 있고, 이를 현재의 문제에 적용할 수 있다면, 코드를 재작성하는 것보다 시간을 절약할 수 있습니다.

• 컴포넌트(Component): 이는 소프트웨어 시스템의 독립적인 부분으로, 특정 기능을 수행합니다. 재사용 가능한 컴포넌트를 사용하면 시스템을 빠르게 구축하고 코드의 품질을 향상시킬 수 있습니다.

• 응용 프로그램(Application): 이미 개발된 응용 프로그램은 특정 문제를 해결하거나 기능을 제공하는데 사용될 수 있습니다. 이는 새로운 응용 프로그램을 개발하는 데 걸리는 시간과 노력을 절약할 수 있습니다.

• 프레임워크(Frameworks): 이는 재사용 가능한 클래스나 컴포넌트의 집합으로, 소프트웨어를 빠르게 개발하고, 코드의 품질을 향상시키며, 유지보수를 용이하게 합니다.

• 기술(Technologies): 기술은 특정 작업을 수행하거나 문제를 해결하는데 도움이 되는 방법이나 프로세스입니다. 이미 존재하는 기술을 재사용하면 시간과 노력을 절약할 수 있습니다.

• 시스템(System): 전체 시스템을 재사용하는 것은 더 큰 규모의 시스템을 빠르게 구축할 수 있게 해줍니다.

따라서 '재사용 관점'은 소프트웨어 개발의 여러 단계와 요소에서 재사용을 가능하게 하는 넓은 관점을 제공합니다.

The reuse landscape

The reuse landscape

• Although reuse is often simply thought of as the reuse of system components, there are many different approaches to reuse that may be used.
• Reuse is possible at a range of levels from simple functions to complete application systems.
• The reuse landscape covers the range of possible reuse techniques.

"재사용 지표(The Reuse Landscape)"는 시스템 구성요소의 재사용을 넘어서 다양한 재사용 접근법이 가능함을 나타냅니다. 재사용은 단순한 기능부터 전체 애플리케이션 시스템에 이르기까지 다양한 수준에서 가능하며, 재사용 지표는 가능한 재사용 기술의 범위를 보여줍니다.

그림은 이러한 재사용 지표를 시각화한 것으로, 구성요소의 크기와 복잡성에 따라 재사용의 범위를 나타냅니다. X축은 재사용 대상의 크기를 나타내며, Y축은 그 복잡성을 나타냅니다. 이를 통해 어떤 요소가 재사용될 수 있는지, 그리고 그 복잡성이 어떻게 영향을 미치는지를 파악할 수 있습니다.

"재사용 계획 요인(Reuse Planning Factors)"은 소프트웨어 재사용을 결정하는 데 영향을 미치는 여러 요인을 강조합니다.

Reuse planning factors

• The development schedule for the software.
  • If the software has to be developed quickly, you may consider to reuse complete system rather than individual component.
• The expected software lifetime.
  • If you're developing a system with long-lifetime, you need to focus on maintainability rather than immediate benefit of reuse.
• The background, skills and experience of the development team.
  • Reuse technologies are fairly complex, and requires quite a lot of time to understand and use them effectively.
• The criticality of the software and its non-functional requirements.
  • For a critical system, software reuse may cause some difficulties to satisfy various requirements.
• The application domain.
  • In many application domain, there are generic products that may be reused by configuring them to a local environment.
• The execution platform for the software will run.
  • Some reusable components or applications are platform specific.

1. 소프트웨어 개발 일정: 소프트웨어를 빠르게 개발해야 할 경우, 개별 컴포넌트보다는 전체 시스템을 재사용할 수 있습니다.
2. 예상 소프트웨어 수명: 장기 수명의 시스템을 개발하는 경우, 재사용의 즉각적인 이점보다는 유지 관리성에 초점을 맞춰야 합니다.
3. 개발 팀의 배경, 기술 및 경험: 재사용 기술은 상당히 복잡하며, 이를 효과적으로 이해하고 사용하려면 많은 시간이 필요합니다.
4. 소프트웨어의 중요성 및 비기능적 요구사항: 중요한 시스템에 대해 소프트웨어 재사용은 다양한 요구사항을 만족시키는 데 어려움을 겪을 수 있습니다.
   5.응용 도메인: 많은 응용 도메인에서는 로컬 환경에 맞게 구성할 수 있는 일반적인 제품이 있습니다.
5. 소프트웨어가 실행될 실행 플랫폼: 일부 재사용 가능한 컴포넌트 또는 응용 프로그램은 플랫폼에 종속적일 수 있습니다. 이는 해당 컴포넌트나 응용 프로그램이 특정 운영체제나 하드웨어에서만 작동하도록 설계되었을 수 있음을 의미합니다. 따라서 소프트웨어가 실행될 플랫폼은 재사용 가능한 요소를 결정하는 중요한 요인이 됩니다. 플랫폼에 종속적인 컴포넌트를 재사용하려면 해당 플랫폼에서 소프트웨어를 실행해야 합니다. 반대로, 플랫폼에 독립적인 컴포넌트를 재사용하면 다양한 플랫폼에서 소프트웨어를 실행할 수 있습니다.

Application frameworks

Framework definition

“..an integrated set of software artifacts (such as classes, objects and components) that collaborate to provide a reusable architecture for a family of related applications.”

프레임워크 정의
프레임워크는 "관련된 일련의 응용 프로그램을 위한 재사용 가능한 아키텍처를 제공하는 소프트웨어 아티팩트(클래스, 객체, 컴포넌트 등)의 통합된 집합"으로 정의됩니다.

Application frameworks

• Frameworks are moderately large entities that can be reused.
  • They are somewhere between system and component reuse.
• Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them.
• The sub-system is implemented by adding components to fill in parts of the design and by instantiating the abstract classes in the framework.

응용 프로그램 프레임워크

• 프레임워크는 재사용 가능한 중간 크기의 엔티티입니다.
  • 이는 시스템 재사용과 컴포넌트 재사용 사이에 위치합니다.
• 프레임워크는 추상 클래스와 구체 클래스의 모음과 그들 사이의 인터페이스로 구성된 서브시스템 디자인입니다.
• 이 서브시스템은 디자인의 일부를 채우기 위해 컴포넌트를 추가하고 프레임워크의 추상 클래스를 인스턴스화함으로써 구현됩니다.

응용 프로그램 프레임워크는 소프트워어 개발 시 특정 종류의 문제를 해결하기 위해 재사용 가능한 구조를 제공합니다. 예를 들어, 웹 애플리케이션 프레임워크는 웹 페이지 라우팅, 데이터베이스 연결, 보안, 등과 같은 기본적인 웹 애플리케이션 기능을 제공합니다. 이로써 개발자는 프레임워크가 제공하는 이러한 기능들을 재사용하고, 특정 애플리케이션의 요구사항에 맞게 커스터마이징함으로써 개발 시간을 단축하고 코드의 품질을 향상시킬 수 있습니다.

또한, 프레임워크는 코드의 구조와 흐름을 정의함으로써 개발 프로세스를 안내하며, 이를 통해 코드의 일관성과 가독성이 향상되고 유지 보수가 용이해집니다. 따라서 프레임워크는 소프트웨어 재사용의 중요한 도구입니다.

Web application frameworks

• Support the construction of dynamic websites as a front-end for web applications.
• WAFs are now available for all of the commonly used web programming languages
  • e.g.) JavaScript, Java, Python, Ruby, etc.
• Interaction model is based on the Model-View-Controller composite pattern.
  • System infrastructure framework for GUI design.
  • Allows for multiple presentations of an object and separate interactions with these presentations.

웹 애플리케이션 프레임워크
웹 애플리케이션 프레임워크(WAF)는 웹 애플리케이션의 프론트엔드로서 동적 웹사이트의 구축을 지원합니다. 현재 자바스크립트, 자바, 파이썬, 루비 등 일반적으로 사용되는 모든 웹 프로그래밍 언어에 대한 WAF들이 제공되고 있습니다.

상호작용 모델은 Model-View-Controller (MVC) 복합 패턴에 기반합니다. 이 패턴은 GUI 디자인을 위한 시스템 인프라 프레임워크로, 객체의 여러 표현을 가능하게 하고 이러한 표현들과의 분리된 상호작용을 가능하게 합니다.

The Model-View-Controller pattern

Model-View-Controller 패턴
MVC 패턴은 사용자 인터페이스를 가진 소프트웨어 설계에 널리 사용되는 디자인 패턴입니다. 이 패턴은 애플리케이션을 세 가지 구성 요소로 분리하는데, 이 요소들은 다음과 같습니다.

• Model (모델): 데이터와 비즈니스 로직, 즉 애플리케이션의 정보와 그 정보를 처리하는 규칙을 담당합니다. 모델은 보통 데이터베이스와 상호 작용하여 데이터를 읽고 쓰며, 필요한 데이터 조작이나 처리를 수행합니다.
• View (뷰): 사용자 인터페이스 요소를 표현하는 부분으로, 사용자에게 보여지는 데이터의 시각적 표현을 담당합니다. 뷰는 사용자의 입력을 컨트롤러에 전달하고, 모델의 변화를 사용자에게 보여주는 역할을 합니다.
• Controller (컨트롤러): 사용자의 입력에 응답하고, 모델과 뷰 사이의 인터페이스 역할을 합니다. 컨트롤러는 사용자의 입력을 해석하여 모델의 상태를 변경하거나, 모델의 변경을 뷰에 반영하도록 지시합니다.

웹 애플리케이션 프레임워크에서 MVC 패턴을 사용하면 애플리케이션의 로직과 사용자 인터페이스를 분리할 수 있어, 코드의 재사용성과 유지보수성이 향상됩니다. 또한, 팀에서의 협업이 용이해집니다.

WAF features

• Security
  • WAFs may include classes to help implement user authentication (login) and access.
• Dynamic web pages
  • Classes are provided to help you define web page templates and to populate these dynamically from the system database.
• Database support
  • The framework may provide classes that provide an abstract interface to different databases.
• Session management
  • Classes to create and manage sessions (a number of interactions with the system by a user) are usually part of a WAF.
• User interaction
  • Most web frameworks now provide AJAX support (Holdener, 2008), which allows more interactive web pages to be created.

WAF 기능
웹 애플리케이션 프레임워크(WAF)는 웹 애플리케이션 개발에 필요한 다양한 기능을 제공합니다:

• 보안: WAF는 사용자 인증(로그인) 및 접근 제어를 돕는 클래스를 포함할 수 있습니다.
• 동적 웹 페이지: WAF는 웹 페이지 템플릿을 정의하고 이를 시스템 데이터베이스에서 동적으로 채우는 데 도움이 되는 클래스를 제공합니다.
• 데이터베이스 지원: 프레임워크는 다양한 데이터베이스에 대한 추상 인터페이스를 제공하는 클래스를 제공할 수 있습니다.
• 세션 관리: 사용자에 의한 시스템과의 여러 상호 작용을 생성하고 관리하는 클래스는 보통 WAF의 일부입니다.
  사용자 상호작용: 대부분의 웹 프레임워크는 AJAX 지원을 제공합니다. 이를 통해 보다 상호 작용적인 웹 페이지를 생성할 수 있습니다.

Extending frameworks

• Frameworks are generic and are extended to create a more specific application or sub-system.
  • They provide a skeleton architecture for the system.
• Extending the framework involves
  • Adding concrete classes that inherit operations from abstract classes in the framework;
  • Adding methods that are called in response to events that are recognised by the framework.
• Problem with frameworks is their complexity which means that it takes a long time to use them effectively.

프레임워크 확장
프레임워크는 일반적인 구조를 제공하며, 이를 확장하여 보다 특화된 애플리케이션 또는 하위 시스템을 만들 수 있습니다. 그들은 시스템의 골격 구조를 제공합니다.

프레임워크를 확장하는 것은 다음을 포함합니다:

• 프레임워크의 추상 클래스에서 연산을 상속받는 구체 클래스를 추가합니다.
• 프레임워크에서 인식하는 이벤트에 대응하여 호출되는 메소드를 추가합니다.

프레임워크의 문제점 중 하나는 그 복잡성으로 인해 효과적으로 사용하는데 시간이 꽤 걸린다는 것입니다. 그러나, 이는 프레임워크를 제대로 이해하고 활용하면 매우 강력한 도구가 될 수 있음을 의미합니다.

Inversion of control in frameworks

프레임워크에서의 제어 역전
프레임워크에서 제어의 역전(Inversion of Control, IoC)은 프로그래밍의 흐름을 프레임워크가 주도하도록 구조화하는 설계 원칙입니다. 기존의 전통적인 프로그래밍 방식에서는 개발자가 작성한 코드가 어플리케이션의 흐름을 제어하였습니다. 하지만 제어의 역전 원칙을 사용하면, 이러한 흐름 제어는 프레임워크에 위임되며 개발자는 필요한 부분만을 구현하게 됩니다.

제공된 그림에서 볼 수 있듯이, 제어의 역전이 적용되면 프레임워크가 프로그램의 흐름을 제어하고, 사용자가 정의한 코드는 필요한 동작을 수행하는 데 필요한 부분만 정의하게 됩니다. 이를 통해 코드의 재사용성과 유지보수성이 향상되며, 개발자는 프로그램의 전체적인 흐름이 아닌 비즈니스 로직에 더 집중할 수 있게 됩니다.

Software product lines

Software product lines

• Software product lines or application families are applications with generic functionality that can be adapted and configured for use in a 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;
  • Adding new components to the system;
  • Selecting from a library of existing components;
  • Modifying components to meet new requirements.

소프트웨어 제품 라인
소프트웨어 제품 라인 또는 애플리케이션 패밀리는 특정 컨텍스트에서 사용될 수 있도록 적응하고 구성할 수 있는 일반적인 기능을 가진 애플리케이션입니다.

소프트웨어 제품 라인은 공통 아키텍처와 공유 컴포넌트를 가진 일련의 애플리케이션 세트이며, 각 애플리케이션은 다른 요구 사항을 반영하여 특화되어 있습니다.

적응은 다음을 포함할 수 있습니다:

컴포넌트와 시스템 구성;

• 시스템에 새로운 컴포넌트 추가;
• 기존 컴포넌트 라이브러리에서 선택;
• 새로운 요구 사항을 충족하기 위해 컴포넌트 수정.

소프트웨어 제품 라인 접근법은 유사한 애플리케이션을 개발할 때 중복 작업을 줄이고 코드 재사용성을 높이는 데 도움이 됩니다. 이 접근법은 특히 같은 기능을 가진 여러 애플리케이션을 만들어야 할 때 유용합니다.

Base systems for a software product line

기본 시스템들은 특정 소프트웨어 제품 라인을 구성하는 기반을 제공합니다. 이 그림은 기본 애플리케이션의 구조를 보여주는데, 이 애플리케이션은 주로 세 가지 유형의 컴포넌트로 구성됩니다.

Base applications

• Core components that provide infrastructure support.
  • These are not usually modified when developing a new instance of the product line.
• Configurable components that may be modified and configured to specialize them to a new application.
  • Sometimes, it is possible to reconfigure these components without changing their code by using a built-in component configuration language.
• Specialized, domain-specific components some or all of which may be replaced when a new instance of a product line is created.

핵심 컴포넌트(Core components): 이 컴포넌트들은 인프라 지원을 제공합니다. 예를 들어, 데이터베이스 접근, 네트워킹, 보안, 로깅 등의 기능을 제공하는 컴포넌트들이 여기에 해당할 수 있습니다. 이 컴포넌트들은 일반적으로 제품 라인의 새로운 인스턴스를 개발할 때 수정되지 않습니다.

설정 가능한 컴포넌트(Configurable components): 이 컴포넌트들은 특정 애플리케이션에 맞게 수정하거나 설정할 수 있습니다. 때로는 내장된 컴포넌트 설정 언어를 사용하여 코드를 변경하지 않고 이 컴포넌트들을 재구성할 수 있는 경우도 있습니다.

특수화된, 도메인 특정 컴포넌트(Specialized, domain-specific components): 제품 라인의 새로운 인스턴스가 만들어질 때 일부 또는 전부를 교체할 수 있는 컴포넌트들입니다. 이 컴포넌트들은 특정 업무나 기능에 대한 처리를 담당하며, 제품 라인의 다른 버전에 따라 내용이 변경될 수 있습니다.

이러한 구조를 통해, 기본 애플리케이션은 각 제품이나 프로젝트의 요구 사항에 따라 쉽게 조정하거나 확장할 수 있는 유연성을 제공합니다. 한편, 공통의 기능이나 구조는 재사용되므로 개발 시간과 비용을 절약하고 일관성을 유지할 수 있습니다.

Application frameworks and product lines

• Application frameworks rely on object-oriented features such as polymorphism to implement extensions.
  • Product lines need not be object-oriented (e.g., embedded software for a mobile phone).
• Application frameworks focus on providing technical rather than domain-specific support.
  • Product lines embed domain and platform information.
• Product lines often control applications for equipment.
• Software product lines are made up of a family of applications, usually owned by the same organization.

애플리케이션 프레임워크와 제품 라인의 차이점

1. 애플리케이션 프레임워크: 애플리케이션 프레임워크는 주로 객체 지향 기능(예: 다형성)을 활용하여 확장을 구현합니다. 이는 기술 지원에 중점을 두는데, 프레임워크는 일반적으로 애플리케이션 구조와 인프라를 제공하면서 도메인 특정 기능보다는 일반적인 기능에 초점을 맞춥니다.

2. 제품 라인: 제품 라인은 반드시 객체 지향적일 필요는 없습니다. 예를 들어, 모바일 전화용 임베디드 소프트웨어와 같은 경우가 있습니다. 제품 라인은 도메인 및 플랫폼 정보를 내장하며, 일반적으로 장비를 제어하는 애플리케이션을 포함합니다. 제품 라인은 관련 애플리케이션의 가족으로 구성되며, 주로 같은 조직이 소유합니다.

Product line architectures

• Architectures must be structured in such a way to separate different sub-systems and to allow them to be modified.
• The architecture should also separate entities and their descriptions,
  • and the higher levels in the system access entities through descriptions rather than directly.

제품 라인 아키텍처

제품 라인 아키텍처는 다른 하위 시스템을 분리하고 수정할 수 있도록 구조화되어야 합니다. 이렇게 하면 각 제품 라인의 변형이나 확장이 용이해집니다. 또한, 아키텍처는 엔티티와 그들의 설명을 분리해야 하는데, 이는 시스템의 상위 수준에서 엔티티에 직접 접근하는 대신 설명을 통해 엔티티에 접근하게 함으로써 모듈성과 확장성을 높입니다. 이는 제품 라인이 변경되거나 새로운 제품 라인이 추가될 때, 시스템 전체를 재설계하지 않고도 유연하게 대응할 수 있게 해줍니다.

Product line specialisation

• Platform specialization
  • Different versions of the application are developed for different platforms.
• Environment specialization
  • Different versions of the application are created to handle different operating environments.
• Functional specialization
  • Different versions of the application are created for customers with different requirements.
• Process specialization
  • Different versions of the application are created to support different business processes.

제품 라인 특수화

제품 라인 특수화는 특정 상황이나 요구사항에 맞춰 제품 라인을 맞춤화하는 과정을 의미합니다. 제품 라인 특수화에는 다음과 같은 네 가지 유형이 있습니다:

1. 플랫폼 특수화: 다양한 플랫폼에 대응하기 위해 애플리케이션의 다른 버전을 개발하는 것을 말합니다. 예를 들어, Windows, Mac OS, Linux 등의 다양한 운영 체제에서 작동하는 버전이 만들어질 수 있습니다.
2. 환경 특수화: 다양한 운영 환경에 대응하기 위해 애플리케이션의 다른 버전을 만드는 것입니다. 예를 들어, 클라우드 환경, 온-프레미스 환경, 모바일 환경 등에 적합한 버전이 만들어질 수 있습니다.
3. 기능 특수화: 고객의 다양한 요구사항을 충족시키기 위해 애플리케이션의 다른 버전을 만드는 것입니다. 예를 들어, 다른 기능을 요구하는 다양한 고객 세그먼트에 대응하기 위해 서로 다른 기능 세트를 갖는 버전이 만들어질 수 있습니다.
4. 프로세스 특수화: 다양한 비즈니스 프로세스를 지원하기 위해 애플리케이션의 다른 버전을 만드는 것입니다. 예를 들어, 제조, 판매, 서비스 등의 다양한 비즈니스 프로세스를 지원하기 위해 특화된 버전이 만들어질 수 있습니다.

Product instance development

제품 인스턴스 개발

제품 인스턴스 개발은 특정한 요구사항에 맞춰 제품 라인을 개선하거나 확장하는 과정을 의미합니다.

이 과정은 일반적으로 다음 단계를 포함합니다:

1. 요구사항 분석: 이 단계에서는 특정 제품 인스턴스에 대한 요구사항이 결정됩니다.
2. 추가 개발: 요구사항에 따라 필요한 추가 기능을 개발합니다. 이는 기존 제품 라인의 컴포넌트를 확장하거나 새로운 컴포넌트를 개발하는 것을 포함할 수 있습니다.
3. 시스템 구성: 이 단계에서는 제품 라인의 기존 컴포넌트와 새로 개발된 컴포넌트를 조합하여 새로운 제품 인스턴스를 구성합니다.
4. 테스트: 새로운 제품 인스턴스가 요구사항을 충족하고 제대로 작동하는지 확인하기 위해 테스트를 수행합니다.
5. 배포: 테스트가 성공적으로 완료되면, 제품 인스턴스는 사용자에게 배포됩니다.

이런 방식으로, 제품 라인 방식은 다양한 요구사항에 맞춰 소프트웨어를 빠르게 개발하고 배포하는 데 유용합니다. 그러나, 각 제품 인스턴스가 제대로 작동하도록 하려면, 제품 라인의 각 컴포넌트를 신중하게 설계하고 관리해야 합니다.

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.
• Application systems have generic features and so can be used reused in different environments.
• Application system products are often adapted by using built-in configuration mechanisms that allow the functionality of the system to be tailored to specific customer needs.
  • For example, in a hospital patient record system, separate input forms and output reports might be defined for different types of patient.

애플리케이션 시스템 재사용
애플리케이션 시스템 제품은 시스템의 소스 코드를 변경하지 않고도 다양한 고객에게 적응시킬 수 있는 소프트웨어 시스템입니다. 이들 시스템에는 일반적인 기능이 있어서 다양한 환경에서 재사용될 수 있습니다.

애플리케이션 시스템 제품은 종종 내장 구성 메커니즘을 사용하여 시스템의 기능을 특정 고객의 요구에 맞게 조정하도록 조정합니다. 예를 들어, 병원 환자 기록 시스템에서는 다른 유형의 환자에 대해 별도의 입력 양식과 출력 보고서를 정의할 수 있습니다.

Benefits of application system reuse

• As with other types of reuse, more rapid deployment of a reliable system may be possible.
• It is possible to see what functionality is provided by the applications and so it is easier to judge whether or not they are likely to be suitable.
• 'Some' development risks are avoided by using existing software.
• Businesses can focus on their core activity without having to devote a lot of resources to IT systems development.
• As operating platforms evolve, technology updates may be simplified as these are the responsibility of the COTS product vendor rather than the customer.

애플리케이션 시스템 재사용의 이점
다른 유형의 재사용과 마찬가지로, 신뢰할 수 있는 시스템을 더 빠르게 배포할 수 있을 수 있습니다. 애플리케이션에서 제공하는 기능을 확인할 수 있으므로, 이들이 적합한지 판단하는 것이 더 쉬울 수 있습니다.

일부 개발 위험을 피할 수 있습니다. 기존의 소프트웨어를 사용함으로써, 이런 이점이 생깁니다.

기업들은 핵심 활동에 초점을 맞출 수 있습니다. 대량의 리소스를 IT 시스템 개발에 투자할 필요가 없습니다.

운영 플랫폼이 발전함에 따라, 기술 업데이트를 단순화할 수 있습니다. 이 업데이트는 COTS 제품 벤더의 책임이므로 고객의 부담을 덜 수 있습니다.

Problems of application system reuse

• Requirements usually have to be adapted to reflect the functionality and mode of operation of the COTS product.
• The COTS product may be based on assumptions that are practically impossible to change.
• Choosing the right COTS system for an enterprise can be a difficult process, especially as many COTS products are not well documented.
• There may be a lack of local expertise to support systems development.
• The COTS product vendor controls system support and evolution.

애플리케이션 시스템 재사용의 문제점
애플리케이션 시스템 재사용은 다음과 같은 문제점이 있을 수 있습니다.

• 요구사항은 일반적으로 COTS 제품의 기능성과 작동 방식을 반영하도록 조정되어야 합니다.
  • 기존 시스템을 그대로 사용하는 대신, 이를 사용자의 요구사항에 맞게 변경하거나 조정해야 할 수 있습니다. 이는 추가적인 작업과 노력이 필요하게 만듭니다.
• COTS 제품은 실질적으로 변경이 불가능한 가정에 기반을 두고 있을 수 있습니다.
  • 이는 제품이 특정 방식으로 작동하도록 설계되었기 때문에, 제품을 사용자의 특정 요구사항에 완벽하게 맞출 수 없을 수 있다는 것을 의미합니다.
• 기업에 적합한 COTS 시스템을 선택하는 것은 어려운 과정일 수 있습니다, 특히 많은 COTS 제품이 제대로 문서화되어 있지 않을 때입니다.
  • 적절한 시스템을 선택하기 위해서는 해당 제품의 기능, 성능, 호환성 등을 충분히 이해하고 평가해야 하는데, 제품 문서가 부족하면 이 과정이 어려워질 수 있습니다.
• 시스템 개발을 지원하기 위한 지역 전문가가 부족할 수 있습니다.
  • 특히 복잡한 시스템이나 특수한 기술을 요구하는 경우, 필요한 전문가를 찾기 어려울 수 있습니다.
• COTS 제품 벤더가 시스템 지원과 발전을 통제합니다.
  • 이는 사용자가 시스템 업데이트나 개선에 대한 직접적인 통제권을 가지지 못하게 만들 수 있습니다. 또한 벤더가 제품 지원을 중단하면 사용자는 큰 문제에 직면하게 될 수도 있습니다.

Configurable application systems

• Configurable application systems are generic application systems that may be designed to support a particular business type, business activity or, sometimes, a complete business enterprise.
• For example, an application system may be produced for dentists that handles appointments, dental records, patient recall, etc.
• Domain-specific systems, such as systems to support a business function (e.g. document management) provide functionality that is likely to be required by a range of potential users.

구성 가능한 애플리케이션 시스템

• 구성 가능한 애플리케이션 시스템은 특정 비즈니스 유형, 비즈니스 활동 또는 경우에 따라 전체 비즈니스 기업을 지원하도록 설계된 일반적인 애플리케이션 시스템입니다.
  • 예를 들어, 치과 의사를 위한 애플리케이션 시스템은 예약, 치과 기록, 환자 재발 등을 처리할 수 있습니다.
• 도메인 특화 시스템, 예를 들면 비즈니스 기능(예: 문서 관리)을 지원하는 시스템은 잠재 사용자 범위에 필요할 것으로 예상되는 기능을 제공합니다.

ERP systems

• An Enterprise Resource Planning (ERP) system is a generic system that supports common business processes such as ordering and invoicing, manufacturing, etc.
• These are very widely used in large companies - they represent probably the most common form of software reuse.
  • This may not be true any more, due to rapid growth of cloud services (especially for data analysis and machine learning).
• The generic core is adapted by including modules and by incorporating knowledge of business processes and rules.

ERP 시스템

• Enterprise Resource Planning(ERP) 시스템은 주문 및 송장, 제조 등과 같은 일반적인 비즈니스 프로세스를 지원하는 일반적인 시스템입니다.
• 이들은 대형 회사에서 매우 널리 사용되며, 아마도 가장 일반적인 형태의 소프트웨어 재사용을 나타냅니다.
  • 그러나 클라우드 서비스(특히 데이터 분석과 머신 러닝)의 빠른 성장으로 인해 이것이 더 이상 사실이 아닐 수 있습니다.
• 일반적인 핵심은 모듈을 포함시키고 비즈니스 프로세스와 규칙에 대한 지식을 통합함으로써 조정됩니다.

이런 시스템들은 사용자의 특정 요구사항에 맞게 맞춤화될 수 있으며, 이는 기업이 자신의 비즈니스 프로세스에 가장 적합한 시스템을 구축할 수 있게 해줍니다. 또한, 이러한 시스템을 사용함으로써 기업은 표준화된 프로세스와 툴을 통해 효율성과 생산성을 향상시킬 수 있습니다.

Integrated application systems

• Integrated application systems are applications that include two or more application system products and/or legacy application systems.
• You may use this approach when there is no single application system that meets all of your needs or when you wish to integrate a new application system with systems that you already use.

통합 애플리케이션 시스템

• 통합 애플리케이션 시스템은 두 개 이상의 애플리케이션 시스템 제품 및/또는 레거시 애플리케이션 시스템을 포함하는 애플리케이션입니다.
• 당신의 모든 요구를 충족시키는 단일 애플리케이션 시스템이 없거나, 이미 사용하는 시스템에 새로운 애플리케이션 시스템을 통합하려고 할 때 이 방법을 사용할 수 있습니다.

Design choices

• Which individual application systems offer the most appropriate functionality?
  • Typically, there will be several application system products available, which can be combined in different ways.
• How will data be exchanged?
  • Different products normally use unique data structures and formats. You have to write adaptors that convert from one representation to another.
• What features of a product will actually be used?
  • Individual application systems may include more functionality than you need and functionality may be duplicated across different products.

설계 선택 사항

• 어떤 개별 애플리케이션 시스템이 가장 적절한 기능을 제공하나요?
  • 일반적으로, 서로 다른 방식으로 결합될 수 있는 여러 애플리케이션 시스템 제품이 사용 가능할 것입니다.
• 데이터는 어떻게 교환될 것인가요?
  • 다른 제품들은 일반적으로 고유한 데이터 구조와 형식을 사용합니다. 한 표현에서 다른 표현으로 변환하는 적응자를 작성해야 합니다.
• 제품의 어떤 기능이 실제로 사용될 것인가요?
  • 개별 애플리케이션 시스템은 필요한 것보다 더 많은 기능을 포함하고 있을 수 있으며, 기능이 다른 제품 간에 중복될 수 있습니다.

이러한 선택 사항들은 통합 애플리케이션 시스템을 설계하고 개발할 때 중요한 고려사항들입니다. 각 제품의 기능, 데이터 교환 방법, 실제 사용되는 기능들을 고려해야 효과적인 통합 시스템을 만들 수 있습니다. 이러한 선택은 종종 복잡하고 상당한 엔지니어링 노력이 필요합니다. 이는 다양한 시스템 간에 데이터를 교환하고, 필요한 기능을 제공하며, 중복을 최소화하는 방법을 찾는 것을 의미합니다.

Service-oriented interfaces

• Application system integration can be simplified if a serviceoriented approach is used.
• A service-oriented approach means allowing access to the application system’s functionality through a standard service interface, with a service for each discrete unit of functionality.
• Some applications may offer a service interface but, sometimes, this service interface has to be implemented by the system integrator.
  • You have to program a wrapper that hides the application and provides externally visible services.

서비스 지향 인터페이스

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

Application wrapping

• 애플리케이션 래핑은 기존 애플리케이션에 서비스 지향 인터페이스를 제공하는 방법입니다.
• 이 방식은 "래퍼"라고 하는 새로운 소프트웨어 계층을 사용하여 기존 애플리케이션을 "감싸"서 이를 수행합니다. 래퍼는 기본적으로 애플리케이션의 기능을 숨기고, 이를 보다 표준화된 서비스 지향 인터페이스로 제공합니다.
• 이를 통해 다른 시스템이나 애플리케이션에서 해당 기능을 편리하게 사용할 수 있게 되어, 전체적인 시스템 통합을 용이하게 합니다. 이는 특히 표준 서비스 인터페이스가 없는 레거시 애플리케이션에 유용합니다.
• 그러나 애플리케이션 래핑에는 추가적인 개발 노력이 필요하고, 이는 종종 복잡할 수 있습니다. 이는 특히 래퍼가 애플리케이션의 복잡성을 숨기는 데 성공하려면 애플리케이션의 내부 작동 방식에 대한 깊은 이해가 필요하기 때문입니다.

Application system integration problems

• Lack of control over functionality and performance
  • Application systems may be less effective than they appear
• Problems with application system inter-operability
  • Different application systems may make different assumptions that means integration is difficult
• No control over system evolution
  • Application system vendors not system users control evolution
• Support from system vendors
  • Application system vendors may not offer support over the lifetime of the product

애플리케이션 시스템 통합 문제

• 기능성과 성능에 대한 제어 부족
  • 애플리케이션 시스템은 보이는 것보다 효율성이 떨어질 수 있습니다. 기능과 성능은 애플리케이션의 개발자나 공급자에 의해 결정되며, 사용자는 이들을 제어할 수 없을 수 있습니다. 이로 인해 특정 요구사항을 충족시키는 데 어려움이 발생할 수 있습니다.
• 애플리케이션 시스템 간 상호 운용성 문제
  • 서로 다른 애플리케이션 시스템은 다른 가정을 할 수 있어 통합이 어려울 수 있습니다. 예를 들어, 데이터 형식, 통신 프로토콜, 인터페이스 등에 대한 가정이 서로 다를 수 있고, 이로 인해 애플리케이션 간에 데이터를 교환하거나 상호 작용하는 데 문제가 발생할 수 있습니다.
• 시스템 발전에 대한 제어 부족
  • 애플리케이션 시스템의 발전은 그 시스템의 사용자가 아닌 공급자에 의해 제어됩니다. 이로 인해 공급자가 제품을 업데이트하거나 새로운 기능을 추가하는 데 있어 사용자의 요구사항이 충족되지 않을 수 있습니다. 또한, 공급자가 제품의 지원을 중단하면 사용자는 대체할 수 있는 다른 옵션이 없을 수 있습니다.
• 시스템 공급자로부터의 지원
  • 애플리케이션 시스템의 공급자는 제품의 수명 주기 동안 지원을 제공하지 않을 수 있습니다. 이는 특히 소프트웨어가 오래되거나 특정 공급자가 사업을 폐업한 경우에 문제가 될 수 있습니다. 이런 상황에서는 사용자가 자체적으로 문제를 해결하거나 다른 솔루션을 찾아야 할 수 있습니다.

RESTful services

RESTful web services

• Past web services standards have been criticized as ‘heavyweight’ standards that are over-general and inefficient.
• REST (REpresentational State Transfer) is an architectural style based on transferring representations of resources from a server to a client.
• This style underlies the web as a whole and is simpler than SOAP/WSDL for implementing web services.
• RESTful services involve a lower overhead than so-called ‘big web services’ and are used by many organizations implementing service-based systems.

RESTful 웹 서비스

• 과거의 웹 서비스 표준은 '무거운' 표준이라는 비판을 받았습니다. 이는 과도하게 일반화되어 있고 비효율적이라는 의미입니다.
• REST(REpresentational State Transfer)는 서버에서 클라이언트로 리소스의 표현을 전송하는 것에 기반한 아키텍처 스타일입니다.
• 이 스타일은 웹 전체를 근간으로 하며, 웹 서비스를 구현하는 데 있어 SOAP/WSDL보다 단순합니다.
• RESTful 서비스는 소위 '큰 웹 서비스'보다 오버헤드가 적으며, 많은 조직에서 서비스 기반 시스템을 구현할 때 사용됩니다.

Resources

• The fundamental element in a RESTful architecture is a resource.
• Essentially, a resource is simply a data element such as a catalog, a medical record, or a document, such as this book chapter.
• In general, resources may have multiple representations.
  • i.e., they can exist in different formats.
  • RTF, DOCX, PDF, HWP?
  • JSON is a popular format which replaces the position of XML recently (and maybe YAML?).

리소스

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

Resource operations

• Create – bring the resource into existence.
• Read – return a representation of the resource.
• Update – change the value of the resource.
• Delete – make the resource inaccessible.
• These operations are often simply called CRUD operations.
  • Also basic operations in database management systems.

리소스 작업

• 리소스에 대해 수행할 수 있는 기본적인 작업들은 다음과 같습니다:
  • 생성(Create) - 리소스를 생성합니다.
  • 읽기(Read) - 리소스의 표현을 반환합니다.
  • 업데이트(Update) - 리소스의 값을 변경합니다.
  • 삭제(Delete) - 리소스에 접근할 수 없게 만듭니다.
• 이러한 작업들은 일반적으로 CRUD 작업이라고 불립니다.
  • 또한 데이터베이스 관리 시스템에서의 기본 작업들입니다.

Resources and actions

리소스와 행동

• RESTful 웹 서비스에서 리소스는 HTTP 메서드를 사용하여 조작됩니다.
• 다음 이미지는 리소스와 작업에 대한 기본적인 매핑을 보여줍니다.
• 위의 이미지에서 볼 수 있듯이, 각 HTTP 메서드는 특정 CRUD 작업에 매핑됩니다:
  • POST는 Create에 매핑되어, 새로운 리소스를 생성하는데 사용됩니다.
  • GET은 Read에 매핑되어, 기존 리소스를 조회하는데 사용됩니다.
  • PUT은 Update에 매핑되어, 기존 리소스를 업데이트하는데 사용됩니다.
  • DELETE는 Delete에 매핑되어, 기존 리소스를 삭제하는데 사용됩니다.

이러한 매핑 방식은 클라이언트와 서버 간의 통신을 단순화하고 표준화하는 데 도움이 됩니다. 이는 각각의 HTTP 메서드가 특정 작업을 명확하게 나타내기 때문에, 개발자가 이해하기 쉽고 디버깅이 용이합니다. 또한, 이러한 메서드는 웹의 핵심 구성 요소인 HTTP 프로토콜을 기반으로 하므로, 웹 기반 애플리케이션에서 널리 지원됩니다.

Operation functionality

• POST is used to create a resource. It has associated data that defines the resource.
• 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 is used to update the value of a resource.
• DELETE is used to delete the resource.

작업 기능
POST는 리소스를 생성하는 데 사용됩니다. 이는 리소스를 정의하는 관련 데이터를 가지고 있습니다.
GET은 리소스의 값을 읽고 요청자에게 지정된 표현(예: 웹 브라우저에서 렌더링할 수 있는 XHTML)으로 반환하는 데 사용됩니다.
PUT은 리소스의 값을 업데이트하는 데 사용됩니다.
DELETE는 리소스를 삭제하는 데 사용됩니다.

Resource access

• When a RESTful approach is used, the data is exposed and is accessed using its URL.
• Therefore, the issue data for a repository in GitHub, might be accessed using URLs such as:
  • https://api.github.com/repos/microsoft/vscode/issues/123928
  • https://api.github.com/repos/microsoft/vscode/issues/123926
• Invokes the GET operation and returns a list of issues.
• To request only open issues, a URL query is used:
  • https://api.github.com/repos/microsoft/vscode/issues?state=open

리소스 접근

• RESTful 방식을 사용하면 데이터가 노출되고 그 URL을 사용하여 접근됩니다.
• 예를 들어, GitHub의 저장소에서 이슈 데이터는 다음과 같은 URL을 사용하여 접근할 수 있습니다:
  • https://api.github.com/repos/microsoft/vscode/issues/123928
  • https://api.github.com/repos/microsoft/vscode/issues/123926
• 이 URL은 GET 작업을 호출하고 이슈 목록을 반환합니다.
• 열린 이슈만 요청하려면 URL 쿼리를 사용합니다:
  • https://api.github.com/repos/microsoft/vscode/issues?state=open

이렇게 URL을 통해 리소스에 직접 접근하면, 클라이언트는 리소스의 상태와 표현에 대한 직접적인 제어를 할 수 있습니다. 또한, 리소스를 유일하게 식별하는 URL을 사용하면 여러 사용자나 클라이언트 사이에서 리소스를 쉽게 공유할 수 있습니다. 이러한 방식은 웹의 주요 장점 중 하나인 상태를 공유하고 링크를 통해 정보를 전파하는 능력을 강화합니다.

Query results

• The response to a GET request in a RESTful service may include URLs.
• If the response to a request is a set of resources, then the URL of each of these may be included.
  • "repository_url": "https://api.github.com/repos/microsoft/vscode",
    "labels_url": "https://api.github.com/repos/microsoft/vscode/issues/
    123928/labels{/name}",
    "comments_url": "https://api.github.com/repos/microsoft/vscode/issues/
    123928/comments",
    "events_url": "https://api.github.com/repos/microsoft/vscode/issues/
    123928/events",
    "html_url": "https://github.com/microsoft/vscode/issues/123928"

쿼리 결과

• RESTful 서비스에서 GET 요청에 대한 응답은 URL을 포함할 수 있습니다.
• 요청에 대한 응답이 리소스 세트인 경우, 각 리소스의 URL이 포함될 수 있습니다.
  • "repository_url": "https://api.github.com/repos/microsoft/vscode",
  • "labels_url": "https://api.github.com/repos/microsoft/vscode/issues/123928/labels{/name}",
  • "comments_url": "https://api.github.com/repos/microsoft/vscode/issues/123928/comments",
  • "events_url": "https://api.github.com/repos/microsoft/vscode/issues/123928/events",
  • "html_url": "https://github.com/microsoft/vscode/issues/123928"

이는 클라이언트가 각 리소스에 대한 추가 정보를 가져오는 데 필요한 URL을 얻을 수 있게 하여, 클라이언트가 리소스를 더 깊게 탐색할 수 있게 합니다. 이 방식은 '하이퍼미디어(Hypermedia) as the Engine of Application State (HATEOAS)'라는 원칙을 따르는데, 이는 RESTful 서비스가 자신의 가능한 상태 전환을 설명해야 함을 의미합니다.

Disadvantages of RESTful approach

• When a service has a complex interface and is not a simple resource, it can be difficult to design a set of RESTful services to represent this.
• There are no standards for RESTful interface description so service users must rely on informal documentation to understand the interface.
• When you use RESTful services, you have to implement your own infrastructure for monitoring and managing the quality of service and the service reliability.

RESTful 접근법의 단점

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

이런 단점들에도 불구하고 RESTful 접근법은 그 단순성, 확장성, 및 웹 기반의 표준에 대한 완벽한 지원으로 인해 많은 개발자들에게 인기가 있습니다.

Software reuse with LLM

Software Reuse and Large Language Model

• Large Language Model (LLM) is a machine learning model trained with enormous size of data and parameters.
• Using such models, services providing code generation functionalities have been developed.
  • e.g.) Copilot, ChatGPT, Bing, Bard, etc.
• These services can convert natural language description to working code.
  • Since they were trained from existing code and descriptions, it can be also considered as reuse in broad perspective.
• Also, supporting other development activities with such services are being tested.
  • e.g.) requirement engineering, design, testing, etc.

Advantages of using LLM

• Unlike other software reuse methods, LLM can directly generate working code fits to your own purpose.
  • This way of reuse saves time for software discovery and evaluation, as well as requirement refinement.
• Reuse-oriented development can be done with requirements specification + component adaptation + verification.
• We can focus on "what" rather than "how" for software development.
  • If you know what to do, it will greatly save your time to write code, especially components with a lot of boiler-plate code.

Issues on using LLM

• LLM simply generates contents (text, code, even images) based on probability.
  • Although generated contents are incredibly well-written, there is no rationale behind it.
  • Unlike human, it cannot actually 'think'.
• Hence, you must alway consider the possibility that given contents are incorrect.
  • You don't want to use it without proper inspection.
• Also, you should understand that all data you enter to prompt could be exposed to public and might not be revoked.
  • Never enter specific, sensitive data or code.

Summary

• Reuse is one of the most important concept in software engineering.
  • It ranges from a single software component to entire application system and infrastructure.
• A software framework is a set of software artifacts to provide reusable architecture for similar kinds of applications.
• A software product line is a set of applications sharing common architecture and components, yet specialized to satisfy different requirements.
• An application system product is configurable software which can be reused for general functionality as well as for customized requirements.
• RESTful services provide reusable web services which can be more easily integrated into a software system.
• Reuse with LLM has great potential, but you need to use it with caution.