[소프트웨어 공학] 06&07. Architecture Design / Design and Implementation

Architectural design(아키텍쳐 설계)

• 아키텍쳐 설계는 소프트웨어 시스템의 구성을 이해하고,
  • 그 시스템의 전체 구조를 설계하는 것과 관련이 있습니다(designing the overall structure of that system).
• 아키텍쳐 설계는 설계와 요구 사항 공학 간의 중요한 연결 고리로서,
  • 시스템의 주요 구조적 요소와 그들 간의 관계를 식별합니다.
• 애자일 프로세스의 초기 단계에서 전체 시스템 아키텍쳐를 설계하는 것이 일반적으로 받아들여집니다.
• 시스템 아키텍쳐을 리팩터링하는 것은 일반적으로 비용이 많이 듭니다. 왜냐하면 이것은 시스템의 많은 구성 요소에 영향을 미치기 때문입니다.

Architectural abstraction(아키텍쳐 추상화)

• 소규모에서의 아키텍쳐는 개별 프로그램의 아키텍쳐(the architecture of individual programs)와 관련이 있습니다.
  • 이 수준에서 우리는 개별 프로그램이 구성 요소로 어떻게 분해되는지에 대해 관심을 가집니다.
• 대규모에서의 아키텍쳐는 복잡한 기업 시스템의 아키텍쳐(the architecture of complex enterprise systems)와 관련이 있습니다.
  • 이는 다른 시스템, 프로그램 및 프로그램 구성 요소를 포함합니다.
  • 이러한 기업 시스템은 다른 회사가 소유하고 관리할 수 있는 다른 컴퓨터들에 분산되어 있습니다.

Advantages of explicit architecture(명시적 아키텍쳐의 이점)

• 이해 관계자 커뮤니케이션(Stakeholder communication)
  • 아키텍쳐는 시스템 이해 관계자들에 의한 토론의 초점으로 사용될 수 있습니다.
• 시스템 분석(System analysis)
  • 시스템이 비기능적 요구 사항을 충족시킬 수 있는지 여부의 분석이 가능함을 의미합니다.
• 대규모 재사용(Large-scale reuse)
  • 아키텍쳐는 시스템 범위에 걸쳐 재사용될 수 있습니다.
  • 제품 라인 아키텍쳐가 개발될 수 있습니다.

Architectural design decisions(아키텍쳐 설계 결정)

• 아키텍쳐 설계는 창의적인 과정이므로 개발되는 시스템의 유형에 따라 프로세스가 다릅니다(the process differs depending on the type of system being developed).
• 그러나, 모든 설계 과정에 걸쳐 일반적인 결정들이 있으며, 이러한 결정들은 시스템의 비기능적 특성에 영향을 미칩니다.
  • 예를 들어, 일반적인 애플리케이션 아키텍쳐가 템플릿으로 사용되나요?
  • 어떤 아키텍쳐 패턴이나 스타일이 사용될 수 있나요?
  • 시스템 내의 구조적 구성 요소들은 어떻게 하위 구성 요소들로 분해될까요?

Architecture reuse(아키텍쳐 재사용)

• 같은 도메인의 시스템들은 종종 도메인 개념을 반영하는 유사한 아키텍쳐를 가지고 있습니다.
• 애플리케이션 제품 라인은 특정 고객 요구 사항을 만족시키는 변형을 포함한 핵심 아키텍쳐를 중심으로 구축됩니다.
• 시스템의 아키텍쳐는 하나 이상의 아키텍쳐 패턴 또는 '스타일'을 중심으로 설계될 수 있습니다.
  • 이들은 아키텍쳐의 본질을 포착하고 다양한 방식으로 구현될 수 있습니다.

Application architectures(애플리케이션 아키텍쳐)

• 애플리케이션 시스템은 조직의 필요를 충족시키기 위해 설계됩니다.
• 비즈니스가 많은 공통점을 가지고 있기 때문에, 그들의 애플리케이션 시스템들도 애플리케이션 요구 사항을 반영하는 공통의 아키텍쳐(a common architecture that reflects the application requirements)를 가지고 있는 경향이 있습니다.
• 일반적인 애플리케이션 아키텍쳐(generic application architecture)는 특정 요구 사항을 충족하는 시스템을 만들기 위해 구성 및 적응될 수 있는 소프트웨어 시스템 유형의 아키텍쳐입니다.

 

Architecture and system characteristics(아키텍쳐 및 시스템 특성)

• 성능(Performance): 중요한 작업을 지역화하고 통신을 최소화하십시오. 세밀한 구성 요소보다는 큰 구성 요소를 사용하세요.
• 보안(Security): 중요 자산이 내부 레이어에 있는 레이어드 아키텍쳐를 사용하세요.
• 안전(Safety): 안전 관련 중요 기능을 소수의 하위 시스템에 지역화하십시오.
• 가용성(Availability): 중복 구성 요소와 결함 허용 메커니즘을 포함하세요.
• 유지보수성(Maintanability): 세밀하고 교체 가능한 구성 요소를 사용하세요.

Architectural patterns(아키텍쳐 패턴)

• 패턴은 지식을 나타내고, 공유하고, 재사용하는 수단입니다.
• 아키텍쳐 패턴은 좋은 설계 관행의 스타일화된 설명이며(An architectural pattern is a stylized description of good design practice), 다양한 환경에서 시험되고 검증되었습니다.
• 패턴에는 언제 유용하고 언제 그렇지 않은지에 대한 정보(information about when they are useful or not)가 포함되어야 합니다.
• 패턴은 표와 그래픽 설명을 사용하여 표현될 수 있습니다.
• 패턴이 언제 어떻게 사용되는지(when and how a pattern is used, 그리고 그 장단점(advantages and disadvantages)이 무엇인지 이해하는 것이 중요합니다.

The organiztion of the Model-View-Controller(모델-뷰-컨트롤러의 구조)

• 컨트롤러: 사용자 작업을 모델 업데이트로 매핑하고 뷰를 선택합니다.
• 뷰: 모델을 렌더링하고, 모델 업데이트를 요청하며, 사용자 이벤트를 컨트롤러로 보냅니다.
• 모델: 애플리케이션 상태를 캡슐화하고 상태 변경을 뷰에 통지합니다.

Web application architecture using the MVC pattern(웹 애플리케이션 아키텍쳐 - MVC 패턴 사용)

• 컨트롤러: HTTP 요청 처리, 애플리케이션 특정 로직, 데이터 유효성 검사.
• 뷰: 동적 페이지 생성, 폼 관리.
• 모델: 비즈니스 로직, 데이터베이스.

Layered architecture(레이어드 아키텍쳐)

• 하위 시스템 간의 인터페이싱을 모델링하는 데 사용됩니다.
• 시스템을 서비스 세트를 제공하는 일련의 레이어(또는 추상 기계)로 구성합니다.
• 하위 시스템의 점진적 개발을 지원합니다.
  • 레이어 인터페이스가 변경될 때, 인접 레이어만 영향을 받습니다.
• 그러나 종종 시스템을 이런 식으로 구조화하는 것은 인위적입니다.

A generic layered architecture(일반적인 레이어드 아키텍쳐)

• 사용자 인터페이스
• 사용자 인터페이스 관리, 인증 및 권한 부여
• 핵심 비즈니스 로직/애플리케이션 기능성, 시스템 유틸리티
• 시스템 지원(운영 체제, 데이터베이스 등)
• 장점 : security

 

 

Repository architecture(저장소 아키텍처)

• 하위 시스템 간에 데이터 교환 필요. 이는 두 가지 방법으로 가능:
  • 모든 하위 시스템이 접근할 수 있는 중앙 데이터베이스 또는 저장소에 데이터를 공유;
  • 각 하위 시스템이 자체 데이터베이스를 유지하며 다른 하위 시스템에 명시적으로 데이터 전달.
• 많은 양의 데이터를 공유해야 할 때, 저장소 모델이 자주 사용되며, 이는 효율적인 데이터 공유 메커니즘입니다.

A repository architecture for an IDE(IDE를 위한 저장소 아키텍처)

 

Client-server architecture(클라이언트-서버 아키텍처)

• 분산 시스템 모델로서, 데이터와 처리가 여러 컴포넌트에 걸쳐 분산되는 방식을 보여줌.
  • 단일 컴퓨터에서 구현 가능.
• 프린팅, 데이터 관리 등 특정 서비스를 제공하는 독립 서버 세트.
• 이러한 서비스를 요청하는 클라이언트 세트.
• 클라이언트가 서버에 접근할 수 있게 하는 네트워크.

A client-server architecture for a film library(영화 라이브러리를 위한 클라이언트-서버 아키텍처)

• 은행 같은 application 의 경우 Catalog server를 잘 관리해줘야 한다(보안 등등)

Pipe and filter architecture(파이프와 필터 아키텍처)

• 함수적 변환을 통해 입력을 처리하여 출력을 생성.
• UNIX 셸에서처럼 파이프와 필터 모델이라고도 함.
  • 예) cat 2021-03-31.log | grep "error" | wc -l
• 이 접근 방식의 변형은 매우 흔함.
• 변환 작업이 순차적일 때, 이는 데이터 처리 시스템에서 광범위하게 사용되는 배치 순차 모델.
• 대화형 시스템에는 적합하지 않음.

An example of the pipe and filter architecture used in a payments system(결제 시스템에서 사용된 파이프와 필터 아키텍처의 예)

• 데이터를 자유롭게 가공할 수 있다.

• 시험 보기 전에 어떤 상황에 어떤 architecture로 적용할 건지 고민해보자

 

Design and implementation(설계 및 구현)

• 소프트웨어 설계 및 구현은 실행 가능한 소프트웨어 시스템이 개발되는 소프트웨어 엔지니어링 과정의 단계입니다.
• 소프트웨어 설계 및 구현 활동은 필연적으로 서로 연계됩니다.
  • 소프트웨어 설계는 고객의 요구 사항을 바탕으로 소프트웨어 구성 요소와 그 관계를 식별하는 창의적 활동입니다.
  • 구현은 설계를 프로그램으로 실현하는 과정입니다.

 

Build or buy(제작 혹은 구매)

• 다양한 분야에서 사용자의 요구 사항에 맞게 조정 및 맞춤화할 수 있는 시장에 나와 있는 시스템(buy off-the-shelf systems, COTS)을 구매하는 것이 가능합니다.
• 예를 들어, 고객 서비스를 위한 챗봇을 구현하고 싶다면, 서비스를 제공하는 패키지나 솔루션을 구입할 수 있습니다.
  • 이 방식을 사용하는 것이 시스템을 전통적인 프로그래밍 언어로 개발하는 것보다 저렴하고 빠를 수 있습니다.
  • 요즘 소프트웨어는 종종 데이터를 포함하고 있는데, 이는 많은 시간을 필요로 하는 경우가 있습니다.
• 이런 식으로 애플리케이션을 개발할 때, 설계 과정은 시스템의 구성 기능을 어떻게 사용할 것인지에 대해 관심을 가지게 됩니다.
• reuse 할 수 있으면 하자

An object-oriented design process(객체 지향 디자인 프로세스)

• 구조화된 객체 지향 설계 프로세스는 여러 가지 다른 시스템 모델을 개발하는 것을 포함합니다.
• 이 모델들은 개발 및 유지 관리를 위해 많은 노력을 필요로 하며, 소규모 시스템의 경우 비용 효과적이지 않을 수 있습니다.
• 하지만, 다양한 그룹에 의해 개발된 대규모 시스템의 경우, 설계 모델은 중요한 의사소통 메커니즘입니다.
• 통합 모델링 언어(Unified Modeling Language, UML)는 그래픽 표기법을 사용하여 시스템 모델을 표현하는 방법입니다.
  • UML은 Agile스럽지 않음

Process stages(프로세스 단계)

• 다양한 객체 지향 설계 프로세스가 있으며, 이는 프로세스를 사용하는 조직에 따라 달라집니다.
• 이러한 프로세스에서의 일반적인 활동에는 다음이 포함됩니다:
  • 시스템의 사용 맥락과 모드를 정의하기;
  • 시스템 아키텍처 설계하기;
  • 주요 시스템 객체 식별하기; (domain knowledge)
  • 설계 모델 개발하기;
  • 객체 인터페이스 명세하기.
    • ex) 결제 정보(수단, 금액, user) 관리할 때 결제 manger로 따로 관리
• 교과서는 예시로 날씨 관측 시스템을 사용합니다.

System context and interactions(시스템 맥락 및 상호작용)

• 설계되고 있는 소프트웨어와 그 외부 환경 사이의 관계를 이해하는 것은 필수적입니다(Understanding the relationships between SW that is being designed and its external enviorment),
  • 필요한 시스템 기능을 제공하는 방법과 그 시스템을 환경과 소통할 수 있게 구조화하는 방법을 결정하기 위해.
• 맥락의 이해는 시스템의 경계를 설정하는 데 도움을 줍니다.
  • 시스템 경계를 설정하면 어떤 기능이 설계 중(what feautres are implemented)인 시스템 내에 구현될지, 어떤 기능이 다른 관련 시스템에 있을지(what features are in other associated systems) 결정하는 데 도움이 됩니다.

Architecture Design(아키텍처 디자인)

• 시스템과 그 환경과의 상호작용을 이해하고 나면,
  • 이 정보를 사용하여 시스템 아키텍처를 설계합니다.
• 시스템을 구성하는 주요 컴포넌트와 그 상호작용을 식별하고,
  • 아키텍처 패턴을 사용하여 컴포넌트를 조직할 수 있습니다.

Object class identification(객체 클래스 식별)

• 객체 클래스를 식별하는 것은 종종 객체 지향 디자인에서 어려운 부분입니다.
• 객체 식별을 위한 '마법의 공식'은 없습니다.
  • 이는 시스템 디자이너의 기술, 경험 및 도메인 지식에 의존합니다.
• 객체 식별은 반복적인 과정입니다.
  • 처음부터 올바르게 하는 것은 어렵습니다.
  • 지속적인 리팩토링은 항상 좋은 아이디어입니다.

 

Approaches to identification(식별 접근법)

• 시스템의 자연어 설명에 기반한 문법적 접근법(grammatical approach)을 사용하세요.
• 실질적인 것들에 기반하여(Base the identification on tangible things) 식별을 진행하세요.
• 행동적 접근법(behavioural approach)을 사용하여 객체가 어떤 행동에 참여하는지를 기반으로 객체를 식별하세요.
• 시나리오 기반 분석(scenario-based analysis)을 사용하세요. 각 시나리오에서 객체, 속성 및 메소드를 식별합니다.
• 도메인 주도 설계(DDD)를 사용하세요.
  • 도메인 지식(domain knowledge)을 깊이 이해하여 모델을 설계하고, 모델이 비즈니스 도메인을 반영하도록 만드세요.
  • 실제로, 어떤 판에 대해 잘 이해하고 있는 사람인 Domain expert가 설계 후 개발을 시작하기도 함

Weather station object classes(기상 관측소 객체 클래스)

클래스 다이어그램

 

 

Design Activities w/ LLMS (디자인 활동 w/ LLMs)

할 일 앱 예제

• 할 일 앱의 요구 사항입니다.
  • 사용자는 버튼을 클릭하여 할 일 항목을 등록할 수 있습니다.
  • 각 할 일 항목은 제목, 설명, 마감 기한이 있으며, 추가 정보를 위한 태그 목록도 있습니다.
  • 할 일 항목은 특정 사용자에게 할당될 수 있습니다.
  • 사용자는 할 일 항목에 하위 항목 목록을 등록할 수 있습니다.
  • 할 일 항목은 리스트로 표시되며, 사용자는 제목, 마감 기한 또는 담당자에 따라 정렬할 수 있습니다.
  • 할 일 항목은 태그를 기반으로 필터링될 수도 있습니다.
• 요구 사항을 바탕으로 객체와 그 구조를 식별할 수 있나요?

Design patterns(디자인 패턴)

• 디자인 패턴은 문제와 그 해결책에 대한 추상적 지식을 재사용하는 방법입니다.
• 패턴은 문제와 그 본질의 해결책을 기술합니다.
• 다양한 설정에서 재사용할 수 있도록 충분히 추상적이어야 합니다.
• 패턴은 상속 및 다형성과 같은 객체 지향적 특성을 이용하는 경우가 많습니다.
• Gang of Four의 디자인 패턴 책으로 공부해보자

Pattern elements(패턴 요소)

• 이름: 의미 있는 패턴 식별자.
• 문제 설명
• 해결책 설명
  • 구체적인 디자인이 아니라 다양한 방식으로 구현될 수 있는 디자인 솔루션을 위한 템플릿입니다.
• 결과: 패턴 적용의 결과와 트레이드 오프.

The Observer pattern(옵서버 패턴)

• 이름: Observer.
• 설명: 객체의 상태 표시를 객체 자체로부터 분리합니다.
• 문제 설명: 여러 상태 표시가 필요할 때 사용됩니다.
• 해결책 설명: UML 설명이 있는 슬라이드를 참조하세요.
• 결과: 디스플레이 성능을 향상시키기 위한 최적화는 비현실적일 수 있습니다.

 

Multiple displays using the Observer pattern

 

 

Design problems(디자인 문제들)

• 디자인에 패턴을 사용하기 위해서는, 당신이 직면한 디자인 문제가 적용될 수 있는 연관된 패턴을 인식할 필요가 있습니다.
  • Observer 패턴을 사용하여 다른 객체의 상태 변화를 여러 객체에 알림.(WITH MVC)
  • Façade 패턴을 통해 관련 객체들의 인터페이스를 정리하고, 종종 점진적으로 개발됨.(간판같이 identity를 표현)
  • Iterator 패턴을 통해 컬렉션 내의 요소에 대한 표준적인 접근 방식 제공, 컬렉션이 어떻게 구현되었는지에 관계없이.(it.hasNext() -> it.Next())
  • Decorator 패턴을 통해 실행 중에 기존 클래스의 기능을 확장할 수 있는 가능성 허용.
• Adaptor, Visitor, Strategy 및 Factory method(싱글턴이랑 같이 쓰면 유용) 패턴도 확인해 볼 가치가 있습니다.

Implementation issues(구현 문제들)

• 여기서 중점은 프로그래밍 자체가 아니라, 종종 프로그래밍 텍스트에서 다루지 않는 다른 구현 문제들에 있습니다:
  • 재사용(Reuse): 대부분의 현대 소프트웨어는 기존의 구성 요소나 시스템을 재사용하여 구축됩니다.
  • 구성 관리(Configuration management): 개발 과정 중에 여러 다른 버전을 추적해야 합니다.
    • ex) git
    • 이걸 잘못관리하면 누가 오픈소스에 백도어를 심어버릴 수도 있다
  • 호스트-타깃 개발(Host-target development): 생산 소프트웨어는 보통 한 컴퓨터(호스트 시스템)에서 개발되고, 별도의 컴퓨터(타깃 시스템)에서 실행됩니다.

Reuse(재사용)

• 과거에는 대부분의 새로운 소프트웨어가 고급 프로그래밍 언어로 처음부터 개발되었습니다.
  • 유의미한 재사용은 프로그래밍 언어 라이브러리의 함수와 객체 재사용이 전부였습니다.
• 비용과 일정 압박으로 인해 이 방법은 점점 실현 가능하지 않게 되었고, 특히 상업 및 인터넷 기반 시스템에서 그러합니다.
• 기존 소프트웨어의 재사용을 중심으로 한 개발 방법론이 등장하여 이제는 일반적으로 비즈니스 및 과학 소프트웨어에 사용됩니다.

 

Software reuse

• component는 사실 library에 포함되긴 함
  • ex) swing, javafx, java stl
• framework
  • ex) react

 

 

Reuse costs(재사용 비용)

• 재사용할 소프트웨어를 찾고(looking for software) 그것이 당신의 요구 사항을 충족하는지 평가하는 데(assessing whether or not it meets your needs) 드는 시간의 비용.
• 적용 가능한 경우, 재사용 가능한 소프트웨어 구매 비용(bying the reusable software).
  • 요즘에는 종종 거래 크기에 기반하여 비용을 지불해야 합니다.
• 개발 중인 시스템의 요구 사항을 반영하도록 재사용 가능한 구성 요소나 시스템을 적용하고 설정(adapting and configuring하는 데 드는 비용.
• 재사용 가능한 소프트웨어 요소들(서로 다른 출처의 소프트웨어를 사용하는 경우)을 통합(integrating resuable software elements)하는 데 드는 비용 및 새로 개발한 코드와의 통합 비용.

 

Configuration management(구성 관리)

• 구성 관리는 변경되는 소프트웨어 시스템을 관리하는 과정의 이름입니다.
• 구성 관리의 목적은 시스템 통합 과정을 지원하는 것으로,
  • 모든 개발자가 프로젝트 코드와 문서에 제어된 방식으로 접근하고, 어떤 변경 사항이 있었는지 알아내고, 컴포넌트를 컴파일 및 링크하여 시스템을 생성할 수 있도록 하는 것입니다.
• 이미 5주차에 이것에 대해 논의했습니다.

 

Host-target development(호스트-대상 개발)

• 대부분의 소프트웨어는 한 컴퓨터(호스트, 개발하는 환경)에서 개발되지만 다른 기계(대상, 코드를 돌릴 환경)에서 실행됩니다.
• 일반적으로, 우리는 개발 플랫폼과 실행 플랫폼에 대해 이야기할 수 있습니다.
  • 플랫폼은 하드웨어 이상의 것입니다.
  • 운영 체제 및 데이터베이스 관리 시스템 또는 대화형 개발 환경과 같은 지원 소프트웨어가 설치된 것을 포함합니다.
• 개발 플랫폼은 일반적으로 실행 플랫폼과 다른 소프트웨어가 설치되어 있으며, 이러한 플랫폼은 다른 아키텍처를 가질 수 있습니다.

 

 

 

Development platform tools(개발 플랫폼 도구)

• 코드 생성, 편집 및 컴파일을 가능하게 하는 통합 컴파일러 및 문법 지향 편집 시스템.
• 언어 디버깅 시스템.
• UML 모델을 편집하는 도구와 같은 그래픽 편집 도구.
• Junit과 같이 프로그램의 새 버전에 대한 일련의 테스트를 자동으로 실행할 수 있는 테스팅 도구.
• 다양한 개발 프로젝트를 구성하는 데 도움이 되는 프로젝트 지원 도구.

 

Integrated development environments(IDEs)(통합 개발 환경(IDE))

• 소프트웨어 개발 도구는 종종 통합 개발 환경(IDE)을 만들기 위해 그룹화됩니다.
• IDE는 소프트웨어 개발의 다양한 측면을 지원하는 소프트웨어 도구 모음이며, 일부 공통 프레임워크 및 사용자 인터페이스 내에 있습니다.
• IDE는 Java와 같은 특정 프로그래밍 언어 개발을 지원하기 위해 만들어졌습니다.
  • 언어 IDE는 특별히 개발되거나 특정 언어 지원 도구가 있는 일반적인 목적의 IDE의 인스턴스일 수 있습니다.

 

Component/system deployment factors(구성 요소/시스템 배포 요인)

• 특정 하드웨어 아키텍처를 위해 설계된 구성 요소나 다른 소프트웨어 시스템에 의존하는 경우,
  • 필요한 하드웨어 및 소프트웨어 지원을 제공하는 플랫폼에 배치되어야 합니다.
• 이는 AWS나 Docker와 같은 새로운 도구 및 기술로 지원될 수 있습니다.
• 고가용성 시스템은 구성 요소가 여러 플랫폼에 배포될 수 있습니다.
  • 이는 플랫폼 오류가 발생하는 경우 구성 요소의 대체 구현이 사용 가능하다는 것을 의미합니다.

• 구성 요소 간에 상당한 통신 트래픽이 있는 경우, 일반적으로 그것들을 서로 물리적으로 가까운 같은 플랫폼 또는 플랫폼에 배치하는 것이 합리적입니다.
  • 이는 한 구성 요소가 메시지를 보내고 다른 구성 요소가 받는 시간 사이의 지연을 줄입니다.
• 확장성을 위해, 같은 버전의 소프트웨어는 여러 플랫폼의 인스턴스에 배포될 수 있습니다.
  • 사용자 트래픽은 약간 다른 구성을 가진 인스턴스에서 균형을 맞출 것입니다.
  • 요즘은 위 과정들이 자동화되어가고 있다

 

Open source development(오픈 소스 개발)

• 오픈 소스 개발은 소프트웨어 시스템의 소스 코드를 공개하고 자원봉사자들이 개발 과정에 참여하도록 초대하는 소프트웨어 개발 방식입니다.
• 이것의 기원은 자유 소프트웨어 재단(www.fsf.org)에 있으며, 소스 코드는 소유권을 가지지 않고 사용자가 원하는 대로 검토하고 수정할 수 있어야 한다고 주장합니다.
• 오픈 소스 소프트웨어는 인터넷을 사용하여 훨씬 더 많은 자원봉사 개발자 인구를 모집하는 이 아이디어를 확장했습니다.
• 이들 중 많은 사람들은 또한 코드의 사용자입니다.

 

 

Open source systems(오픈 소스 시스템)

• 가장 잘 알려진 오픈 소스 제품은 물론 Linux 운영 체제로, 서버 시스템으로 널리 사용되며 점점 데스크톱 환경에서도 증가하고 있습니다.
• Java, Apache 웹 서버 및 MySQL 데이터베이스 관리 시스템과 같은 다른 중요한 오픈 소스 제품도 있습니다.
  • TensorFlow, NumPy, Pandas 등도 있습니다.
• 오늘날 오픈 소스 개발은 매우 흔하며 상업 소프트웨어 개발도 오픈 소스 소프트웨어와 연관되어 있습니다.
  • 예를 들어 Amazon과 Elastic 사이의 분쟁.
• 바람직하지 않은 추세: 오픈 소스 프로젝트로 성장하여 제한된 상업용 라이선스로 전환.

 

License models(라이선스 모델)

• The GNU General Public License(GPL)
  • 이것은 '상호' 라이선스라고 불리며, GPL에 따라 오픈 소스 소프트웨어를 사용하는 경우 해당 소프트웨어를 오픈 소스로 만들어야 합니다.
• The GNU Lessser General Public License(LGPL)
  
  • 이것은 GPL 라이선스의 변형으로, 이를 통해 구성 요소의 소스를 공개하지 않고도 오픈 소스 코드와 연결할 수 있습니다.
• MIT 라이선스.(제일 범용적임)
  • 이것은 비상호 라이선스로, 라이선스 사본을 포함하는 한 거의 제한 없이 상업적 사용을 포함한 모든 것을 허용합니다.
  • 판매되는 독점 시스템에서 코드를 포함할 수 있습니다.

---

Summary

• 우리는 설계 및 구현 문제에 대해 논의했습니다.
• 아키텍처 설계는 전체 시스템 구조에 관한 것으로 리팩토링에 많은 비용이 듭니다.
• 소프트웨어 설계 및 구현 활동은 필연적으로 서로 얽혀 있습니다.
• 아키텍처 및 소프트웨어 설계에 대해서는 디자인 패턴을 고려할 수 있습니다.
• 중요한 구현 문제에는 재사용, 구성 관리 및 호스트-대상 개발이 포함됩니다.