소프트웨어 프레임워크

Software framework
「프레임워크(컴퓨터 과학)」는, 여기서 리다이렉트 됩니다.그 외의 용도는, 프레임워크(명료화)를 참조해 주세요.

컴퓨터 프로그래밍에서 소프트웨어 프레임워크는 일반적인 기능을 제공하는 소프트웨어가 사용자가 작성한 추가 코드에 의해 선택적으로 변경되어 애플리케이션 고유의 소프트웨어를 제공할 수 있는 추상화입니다.응용 프로그램을 구축 및 도입하는 표준 방법을 제공하며 소프트웨어 응용 프로그램, 제품 및 솔루션 개발을 촉진하는 대규모 소프트웨어 플랫폼의 일부로서 특정 기능을 제공하는 범용 재사용 가능한 소프트웨어 환경입니다.소프트웨어 프레임워크에는 지원 프로그램, 컴파일러, 코드 라이브러리, 도구 세트 및 프로젝트 또는 시스템 개발을 가능하게 하는 다양한 컴포넌트를 하나로 묶는 애플리케이션 프로그래밍 인터페이스(API)가 포함될 수 있습니다.

프레임워크에는 일반 라이브러리와 구별되는 주요 기능이 있습니다.

  • 제어 반전:라이브러리나 표준 사용자 애플리케이션과는 달리, 프레임워크에서 전체 프로그램의 제어 흐름은 호출자에 의해 지시되는 것이 아니라 [1]프레임워크에 의해 지시됩니다.이것은 보통 Template Method Pattern을 사용하여 이루어집니다.
  • 기본 동작:이것은 프레임워크에서 제공하는 추상 클래스의 템플릿 메서드 패턴의 불변 메서드를 사용하여 제공할 수 있습니다.
  • 확장성:사용자는 보통 선택적인 오버라이드를 통해 프레임워크를 확장할 수 있습니다.또한 프로그래머는 특별한 사용자 코드를 추가하여 특정 기능을 제공할 수 있습니다.이것은 보통 슈퍼클래스의 템플릿 메서드를 덮어쓰는 서브클래스의 후크 메서드에 의해 실현됩니다.
  • 수정할 수 없는 프레임워크 코드:일반적으로 프레임워크 코드는 사용자가 구현한 확장을 받아들이면서도 수정해서는 안 됩니다.즉, 사용자는 프레임워크를 확장할 수 있지만 해당 코드를 수정할 수는 없습니다.

근거

소프트웨어 프레임워크의 설계자는 설계자와 프로그래머가 작업 시스템을 제공하는 보다 표준적인 낮은 수준의 세부사항을 처리하는 대신 소프트웨어 요건을 충족시키는 데 시간을 할애하여 전체 개발 시간을 [2]단축하는 것을 목표로 합니다.예를 들어, 웹 프레임워크를 사용하여 은행 웹 사이트를 개발하는 팀은 요청 처리 및 상태 관리 메커니즘보다는 은행 관련 코드 작성에 집중할 수 있습니다.

프레임워크는 종종 "코드 블러트"라고 불리는 현상인 프로그램의 크기를 증가시킵니다.고객 수요 중심의 애플리케이션 요구로 인해 경쟁 프레임워크와 보완 프레임워크가 모두 하나의 제품으로 귀결될 수 있습니다.또한 API가 복잡하기 때문에 프레임워크의 사용법을 학습하는 데 추가 시간을 할애해야 하기 때문에 전체적인 개발 시간을 단축할 수 없을 수 있습니다.이 비판은 개발 [citation needed]스태프가 특별한 프레임워크나 새로운 프레임워크를 처음 접했을 때 분명히 유효합니다.이러한 프레임워크를 이후의 작업 작업에 사용하지 않으면, 프레임워크 학습에 투입되는 시간은 프로젝트 스태프가 잘 알고 있는 목적에 따라 작성된 코드보다 더 많은 비용이 들 수 있습니다.많은 프로그래머는 공통의 요구를 위해 유용한 보일러 플레이트의 복사본을 보관하고 있습니다.

그러나 프레임워크를 학습하면 미래의 프로젝트를 보다 빠르고 쉽게 완료할 수 있습니다.프레임워크의 개념은 만능 솔루션 세트를 만드는 것입니다.또한 익숙한 환경에서 코드 제작이 논리적으로 진행되어야 합니다.출력 제품과 함께 번들되는 코드의 크기나 상대적인 효율성과 일관성에 대한 주장은 없습니다.라이브러리 솔루션을 사용하면 소프트웨어가 컴파일러 오브젝트 링커가 아닌 한 불필요한 자산과 사용되지 않은 외부 자산을 끌어당겨 엄격한(소형, 완전히 제어되고 지정된) 실행 가능 모듈을 만들 수 있습니다.

이 문제는 계속되고 있지만, 10년 이상의 업계 경험에[citation needed] 따르면 가장 효과적인 프레임워크는 제3자가 개발한 일반적인 "만능형" 프레임워크를 사용하는 것이 아니라 기업의 공통 코드를 재작성하는 것으로 나타났습니다.예를 들어 오피스 스위트와 같은 애플리케이션 패키지의 사용자 인터페이스가 한때 서로 다른 번들 애플리케이션으로 인해 공통의 외관, 느낌, 데이터 공유 속성 및 메서드를 갖게 된 경우, 보다 촘촘하고 작은 스위트로 통합될 수 있습니다.새로운/진화된 스위트는 통합 유틸리티 libra를 공유하는 제품이 될 수 있습니다.ries 및 사용자 인터페이스.

논쟁의 이러한 경향은 틀에 대한 중요한 문제를 제기한다.단순히 문제를 해결하는 틀과 달리 우아한 틀을 만드는 것은 여전히 과학이라기보다 공예에 가깝다."소프트웨어의 우아함"은 명확성, 간결성 및 낭비를 최소화합니다(추가 기능 또는 외부 기능, 대부분 사용자 정의 기능).예를 들어 코드를 생성하는 프레임워크에서 "elegance"는 단순히 올바른 코드를 생성하는 것과 달리 합리적으로 지식이 풍부한 프로그래머(따라서 쉽게 수정할 수 있음)가 깨끗하고 이해할 수 있는 코드를 생성하는 것을 의미합니다.우아한 문제는 시간의 테스트를 견뎌낸 소프트웨어 프레임워크가 상대적으로 적은 이유입니다.최고의 프레임워크는, 그 기반이 되는 테크놀로지의 진보에 수반해 우아하게 진화해 왔습니다.비록 진화했지만, 다른 방법으로 대체된 방법들이 새로운 방법과 병행하여 유지되었기 때문에, 그러한 많은 패키지들은 최종 소프트웨어를 부풀리는 레거시 기능을 보유하게 될 것이다.

예

Python Powered.png

소프트웨어 프레임워크에는 일반적으로 사용자 애플리케이션의 부트스트랩을 지원하기 위해 상당한 하우스키핑과 유틸리티 코드가 포함되어 있지만 일반적으로 다음과 같은 특정 문제 도메인에 초점을 맞추고 있습니다.

아키텍처

Pree에 [8]따르면 소프트웨어 프레임워크는 프리즈 스팟과 핫스팟으로 구성됩니다.프리즈 스팟은 소프트웨어 시스템의 전체 아키텍처, 즉 기본 컴포넌트와 그 사이의 관계를 정의합니다.애플리케이션 프레임워크의 인스턴스화에서는, 이러한 설정은 변경되지 않습니다(동결).핫스팟은 프레임워크를 사용하는 프로그래머가 자체 코드를 추가하여 자체 프로젝트에 고유한 기능을 추가하는 부분을 나타냅니다.

객체 지향 환경에서 프레임워크는 추상적이고 구체적인 클래스로 구성됩니다.이러한 프레임워크의 인스턴스화는 기존 [9]클래스를 구성하고 하위 분류하는 것으로 구성됩니다.

필요한 기능을 구현하려면 템플릿 방식 패턴을 사용합니다.템플릿 방식 패턴에서는 프리즈 스팟을 불변 방식, 핫스팟을 바리안트 방식 또는 훅 방식이라고 합니다.슈퍼클래스의 불변 메서드는 기본 동작을 제공하는 반면 각 서브클래스의 후크 메서드는 사용자 지정 동작을 제공합니다.

소프트웨어 프레임워크를 갖춘 구체적인 소프트웨어 시스템을 개발할 때 개발자는 시스템의 특정 요구 및 요건에 따라 핫스팟을 활용합니다.소프트웨어 프레임워크는 할리우드의 원칙에 의존합니다. "전화하지 마세요.[10][11] 전화 드리겠습니다."즉, 사용자 정의 클래스(예를 들어 새로운 서브 클래스)가 미리 정의된 프레임워크클래스로부터 메시지를 수신합니다.개발자들은 보통 슈퍼클래스 추상 메서드를 구현하여 이를 처리합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology
  2. ^ "Framework". DocForge. Archived from the original on 7 October 2018. Retrieved 15 December 2008.
  3. ^ Vlissides, J M; Linton, M A (1990), "Unidraw: a framework for building domain-specific graphical editors", ACM Transactions on Information Systems, 8 (3): 237–268, doi:10.1145/98188.98197, S2CID 11248368
  4. ^ Johnson, R E (1992), "Documenting frameworks using patterns", Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, ACM Press: 63–76
  5. ^ Birrer, A; Eggenschwiler, T (1993), "Proceedings of the European conference on object-oriented programming", Frameworks in the financial engineering domain: an experience report, Springer-Verlag, pp. 21–35
  6. ^ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), "Architecture of the Earth System Modeling Framework (ESMF)", Computing in Science and Engineering, 6: 18–28, doi:10.1109/MCISE.2004.1255817, S2CID 9311752
  7. ^ Gachet, A (2003), "Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools", Journal of Decision Systems, 12 (3): 271–281, doi:10.3166/jds.12.271-280, S2CID 29690836
  8. ^ Pree, W (1994), "Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design", Proceedings of the 8th European Conference on Object-Oriented Programming, Lecture Notes in Computer Science, Springer-Verlag, 821: 150–162, CiteSeerX 10.1.1.74.7935, doi:10.1007/BFb0052181, ISBN 978-3-540-58202-1
  9. ^ Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 978-0-471-95869-7
  10. ^ Larman, C (2001), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd ed.), Prentice Hall, ISBN 978-0-13-092569-5
  11. ^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns. Addison-Wesley. ISBN 0-201-63361-2.

외부 링크