L12-Design and Implementation (Ch07)

Project support tools that help you organize the code for different development projects.Topics covered

• UML을 이용한 객체지향 설계
• 디자인 패턴
• 구현 이슈
•  오픈소스 개발

 

Design and implementation

1. 정의

: the stage in the software engineering process at which an executable software system is developed.
(실행 가능한 소프트웨어 시스템이 개발되는 소프트웨어 공학 프로세스의 단계)

 

2. 특징

• Software design and implementation activities are invariably interleaved.
  (소프트웨어 설계와 구현은 보통 서로 얽혀서 진행된다.)
  • Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements.
    (소프트웨어 설계 : 고객의 요구사항을 바탕으로 소프트웨어 구성요소와 그 관계를 식별하는 창의적인 활동)
  • Implementation is the process of realizing the design as a program.
    (구현 : 이 설계를 실제 프로그램으로 실현하는 과정)

 

초기 구현 단계의 결정 사항 : Build or Buy

• In a wide range of domains, it is now possible to buy commercial, off-the-shelf systems (COTS) that can be adapted and tailored to the users’ requirements.
  (다양한 분야에서 상용 기성 소프트웨어(COTS)를 구매하여, 사용자 요구 사항에 맞게 수정하거나 설정할 수 있게 되었다.)
  • If you want to implement a medical records system, you can buy a package that is already used in hospitals.
    (예시 : 병원에서 사용하는 의료 기록 시스템을 구현하고자 할 때, 이미 병원에서 사용 중인 패키지를 구매할 수 있다.)
  • It can be cheaper and faster to use this approach rather than developing a system in a conventional programming language.
    (효과 : 일반적인 프로그래밍 언어로 시스템을 개발하는 것보다 더 저렴하고 빠를 수 있다.)
• When you develop an application in this way,
  (이런 방식으로 애플리케이션을 개발할 경우, 
  • the design process becomes concerned with how to use the configuration features of that system to deliver the system requirements.
    설계 프로세스는 시스템 요구사항을 충족시키기 위해, 해당 시스템의 설정을 어떻게 활용할지에 초점이 맞춰진다.)

 

 

 

[1] UML을 이용한 객체지향 설계

객체지향 설계 프로세스

1. 정의

: Structured object-oriented design processes involve developing a number of different system models.
(구조화된 객체지향 설계 프로세스는 다양한 시스템 모델을 개발하는 것을 포함한다.)

 

2. 유의할 점

• They require a lot of effort for development and maintenance of these models
  (이 모델들을 개발하고 유지하는 데 많은 노력이 필요하다.)
• For small systems, this may not be cost-effective.
  (소규모 시스템에서는 이러한 방식이 비용 효율적이지 않을 수 있다.)
• However, for large systems developed by different groups design models are an important communication mechanism.
  (그러나, 서로 다른 그룹이 개발하는 대규모 시스템의 경우, 설계 모델은 중요한 커뮤니케이션 수단이 된다.)

Process stages (프로세스 단계 )

: 객체지향 설계 프로세스는 사용하는 조직에 따라 다양한 방식이 존재한다.

 

1. Common activitie (공통적인 활동)

• Understand and define the context and external interactions with the system
  (시스템의 컨텍스트와 외부 상호작용을 이해하고 정의한다.)
  -> 즉, 시스템이 어떤 환경에서 사용되고, 외부와 어떻게 연결되는지를 파악한다.
• Design the system architecture
  (시스템 아키텍처를 설계한다.)
  -> 즉, 전체 시스템이 어떻게 구성될지 큰 틀을 설계한다.
• Identify the principal system objects
  (주요 시스템 객체를 식별한다.)
  -> 즉, 시스템을 구성하는 핵심적인 객체(예: 사용자, 기능 등)를 찾아낸다.
• Develop design models
  (설계 모델을 개발한다.)
  -> 즉, 시스템의 구조와 동작을 그림이나 다이어그램으로 표현한다.
• Specify object interfaces
  (객체 인터페이스를 명세한다.)
  -> 즉, 객체들이 서로 어떻게 정보를 주고받을지 구체적으로 정의한다.

 

 

<1> Understand and define the context and external interactions with the system
(시스템의 컨텍스트와 외부 상호작용을 이해하고 정의한다.)

 

1. 시스템 컨텍스트와 상호작용
: Understanding  the relationships between the software that is being designed and its external environment is essential for deciding how to provide the required system functionality and how to structure the system to communicate with its environment.

(설계 중인 소프트웨어와 외부 환경 간의 관계를 이해하는 것은, 필요한 시스템을 어떻게 제공할 것인지, 시스템이 환경과 어떻게 통신해야 할지를 결정하는 데 중요하다.)

• Understanding of the context also lets you establish the boundaries of the system. 
  (컨텍스트를 이해하면, 시스템의 경계를 설정할 수 있다.)
• Setting the system boundaries helps you decide what features are implemented in the system being designed and what features are in other associated systems.
  (시스템 경계를 설정하면, 설계 중인 시스템에서 어떤 기능을 구현하고, 어떤 기능을 다른 관련 시스템에 포함될지를 결정할 수 있다.)

 

2. 컨텍스트 및 상호작용 모델

•  A system context model is a structural model that demonstrates the other systems in the environment of the system being developed
  (시스템 컨텍스트 모델은 개발 중인 시스템이 위치한 환경 내의 다른 시스템들을 보여주는 구조적 모델이다.)
•  An interaction model is a dynamic model that shows how the system interacts with its environment as it is used.
  (상호작용 모델은 시스템이 사용되는 동안 외부 환경과 어떻게 상호작용하는지를 보여주는 동적 모델이다.)

 

3. 예시

1) 기상 관측소의 시스템 컨텍스트

 

2) 기상 관측소 유스케이스

• 유스케이스 설명 — Report Weather

유스케이스	날씨 보고
액터	기상 정보 시스템, 기상 관측소
설명 (데이터)	기상 관측소는 수집 주기 동안 장비로부터 수집된 기상 데이터를 요약하여 기상 정보 시스템에 전송한다. 전송되는 데이터는 지면 및 공기의 최고/최저/평균 온도, 최고/최저/평균 기압, 최고/최저/평균 풍속, 총 강우량, 5분 간격으로 측정된 풍향이다.
자극	기상 정보 시스템이 위성 통신 링크를 통해 기상 관측소와 연결을 설정하고 데이터 전송을 요청한다.
응답	요약된 데이터가 기상 정보 시스템에 전송된다.
비고	기상 관측소는 보통 시간당 1회 보고를 요청받지만, 이 빈도는 관측소마다 다를 수 있고 이후 변경될 수 있다.

 

<2> Design the system architecture
(시스템 아키텍처를 설계한다.)

 

1. 아키텍처 설계

• Once interactions between the system and its environment have been understood, you use this information for designing the system architecture.
  (시스템과 그 환경 간의 상호작용이 이해되면, 이 정보를 사용하여 시스템 아키텍처를 설계한다.)
• You identify the major components that make up the system and their interactions, and then may organize the components using an architectural pattern such as a layered or client-server model.
  (시스템을 구성하는 주요 컴포넌트와 그 상호작용을 식별하고, 계층형 모델이나 클라이언트-서버 모델과 같은 아키텍처 패턴을 사용해 컴포넌트를 조직화할 수 있다.)
• The weather station is composed of independent subsystems that communicate by broadcasting messages on a common infrastructure.
  (예시 : 기상 관측소는 공통 인프라를 통해 메세지를 브로드캐스팅하면서 통신하는 독립적인 하위 시스템으로 구성되어 있다.)

 

2. 예시

1) High-level architecture of the weather station
(기상 관측소의 상위 수준 아키텍처)

 

2) 데이터 수집 시스템 아키텍처

 

<3> Identify the principal system objects
(주요 시스템 객체를 식별한다.)

 

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

1) 어려움
: Identifying object classes is often a difficult part of object oriented design.
(객체지향 설계에서 객체 클래스를 식별하는 것)

 

2) 특징 

• There is no 'magic formula' for object identification, It relies on the skill, experience and domain knowledge of system designers.
  객체 식별에는 '마법의 공식'이 없으며, 설계자의 기술/경험/도메인 지식에 의존된다.
• Object identification is an iterative process. 
  (객체 식별은 반복적인 과정이다.)
• You are unlikely to get it right first time.
  (객체 식별을 처음부터 완벽하게 식별하는 것은 드물다.)

 

2. Approaches to identification (식별 방법)

• Use a grammatical approach based on a natural language description of the system. (noun: objects/attributes, verb: operation or services.)
  (시스템에 대한 자연어 설명을 기반으로 한, 문법적 접근 방식 사용 (명사 : 객체/속성, 동사 : 연산/서비스))
• Base the identification on tangible things in the application domain.
  (애플리케이션 도메인 내의 유형적인 것들을 기반으로 식별)
• Use a behavioural approach and identify objects based on what participates in what behaviour.
  (행동 중심 접근법으로 어떤 행동에 어떤 객체가 참여하는지에 따라 객체를 식별)
• Use a scenario-based analysis, The objects, attributes and methods in each scenario are identified.
  (시나리오 기반 분석을 통해 각 시나리오에서 객체, 속성, 메서드를 식별)

 

3. 예시 : 기상 관측소 객체 클래스
: Object class identification in the weather station system may be based on the tangible hardware and data in the system:

(기상 관측소 시스템의 객체 클래스 식별은 시스템 내의 하드웨어 및 데이터에 기반할 수 있다)

 

• Ground thermometer, Anemometer, Barometer
  (지면 온도계, 풍속계, 기압계)
  • Application domain objects that are ‘hardware’ objects related to the instruments in the system.
    (시스템 내 장비와 관련된 ‘하드웨어’ 객체로서 애플리케이션 도메인 객체)
• Weather station
  (기상 관측소)
  
  • The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model.
    (외부 환경과의 기본 인터페이스로, 유스케이스 모델에서 식별된 상호작용을 반영함)
• Weather data
  (기상 데이터)
  
  • Encapsulates the summarized data from the instruments.
    (장비로부터 수집된 요약 데이터를 캡슐화함)

•  

 

 

 

<4> Develop design models
(설계 모델을 개발한다.)

 

1. 설계 모델

1) 역할

• Design models show the objects/object classes and relationships between these entities.
  (설계 모델은 객체 또는 객체 클래스와 이들 간의 관계를 보여준다.)

2) 분류

• Structural models describe the static structure of the system in terms of object classes and relationships.
  구조적 모델: 객체 클래스 및 그 관계의 정적인 구조를 설명
• Dynamic models describe the dynamic interactions between objects.
  동적 모델: 객체 간의 동적인 상호작용을 설명

3) 종류

• Subsystem models : logical groupings of objects into coherent subsystems.
  하위 시스템 모델: 논리적으로 관련된 객체들을 일관성 있는 하위 시스템으로 묶어 보여줌
• Sequence models : the sequence of object interactions.
  시퀀스 모델: 객체 상호작용의 순서를 보여줌
• State machine models : how individual objects change their state in response to events.
  상태 기계 모델: 개별 객체가 이벤트에 따라 상태를 어떻게 변경하는지 보여줌
• Other models : use-case models, aggregation models, generalisation models, etc.
  기타 모델: 유스케이스 모델, 집계 모델, 일반화 모델 등 포함

(1) Subsystem models (하위 시스템 모델)

• Shows how the design is organised into logically related groups of objects.
  설계가 논리적으로 관련된 객체 그룹으로 어떻게 구성되어 있는지를 보여준다.
• 특징
  • In the UML, these are shown using packages - an encapsulation construct.
    (UML에서는 패키지를 사용하여 표현되며, 이는 캡슐화 구조이다.)
  • This is a logical model. The actual organisation of objects in the system may be different.
    (이는 논리적 모델이며, 실제 시스템 내 객체의 구성과는 다를 수 있다.)
    
    • 설계 단계에서 "이렇게 나누면 좋겠다"라고 정리해놓은 것이다.

(2) 시퀀스 모델

• Show the sequence of object interactions that take place
  (객체 간에 발생하는 상호작용의 순서를 보여준다.)
• 시퀀스 모델은 시간 순서에 따라 시각적으로 보여주는 모델이라고 볼 수 있다.
• 표시 방법
  
  • Objects are arranged horizontally across the top.
    (객체는 수평으로 상단에 배열)
  • Time is represented vertically so models are read top to bottom.
    (시간은 수직으로 표현되며 위에서 아래 방향으로 읽음)
  • Interactions are represented by labelled arrows, Different styles of arrow represent different types of interaction.
    (상호작용은 레이블이 달린 화살표로 표현되며, 화살표 스타일에 따라 상호작용 유형이 달라짐)
    • 실선 : 요청 메세지
    • 점선 : 응답 메세지
  • A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system.
    (객체 생명선의 얇은 직사각형은 해당 객체가 시스템 내에서 제어 객체일 때의 시간을 나타냄)
    • 즉, 그 객체가 현재 뭔 작업을 수행 중인 시간을 나태낸다.

• 예시 : 데이터 수집 시퀀스 다이어그램
  • 객체 : User, ScatCommns, WeatherStation, Commslink, WeatherData

 

(3) 상태 다이어그램

• State diagrams are used to show how objects respond to different service requests and the state transitions triggered by these requests.
  (객체가 다양한 서비스 요청에 어떻게 반응하고, 그 요청으로 인해 어떤 상태 전이가 발생하는지를 보여줌)
• 특징
  • useful high-level models of a system or an object’s run-time behavior.
    시스템이나 객체의 런타임 동작을 설명하는 유용한 고수준 모델
  • You don’t usually need a state diagram for all of the objects in the system. 
    시스템 내 모든 객체에 대해 상태 다이어그램이 필요한 것은 아니다.
    • Many of the objects in a system are relatively simple and a state model adds unnecessary detail to the design.
      많은 객체는 단순하기 때문에 상태 모델이 오히려 불필요한 세부사항이 될 수 있음

• 예시 : 기상 관측소 상태 다이어그램
  • 주요 상태 (State) : 관측소의 작업 단계
  • 상태 전이 예시 (Transition)

 

<5> Specify object interfaces
(객체 인터페이스를 명세한다.)

1. Interface specification (인터페이스 명세)

• 객체와 다른 컴포넌트가 병렬적으로 설계될 수 있도록 객체 인터페이스는 명세되어야 한다.
  • 인터페이스는 객체 간 "약속"이기 때문에, 인터페이스만 정해지면 각자 독립적으로 설계를 진행할 수 있다.
• Encapsulation (캡슐화)
  • Designers should avoid designing the data representation but should hide this in the object itself.
    (설계자는 데이터 표현을 설계하지 않고, 이를 객체 내부에 숨겨야 한다.)
  • 내부 구조(예: 배열인지, 리스트인지 등)는 감추고, 인터페이스(기능 메서드)만 외부에 공개해야 한다.
• Objects may have several interfaces which are viewpoints on the methods provided.
  (객체는 여러 인터페이스를 가질 수 있으며, 이는 제공하는 메서드에 대한 다양한 관점을 나타낸다.)
• The UML uses class diagrams for interface specification but Java may also be used
  (UML에서는 클래스 다이어그램을 사용해 인터페이스를 명세하지만, Java 코드로도 명세 가능하다.)

 

2. 예시 : 기상 관측소 인터페이스

• Interface : Reporting (보고 기능 인터페이스)
  : 기상 정보를 보고하는 역할을 담당
  • 관측소가 외부 시스템(예: 기상 정보 시스템)에게 데이터를 제공할 때 사용하는 기능들이 정의되어 있다.
• Interface : Remote Control (원격 제어 인터페이스)
  : 기상 관측소를 외부에서 제어할 때 사용하는 기능들
  • 제어 시스템이 관측소를 원격으로 작동시키거나 멈추거나, 데이터를 수집하거나 요청할 수 있도록 한다.

 

[Summary] 객체지향 설계 프로세스의 5가지 공통 활동 요약표

단계	활동명	설명 요약	주요 요소/도구	예시
1	컨텍스트 및 상호작용 이해 (Understand and define the context and external interactions)	시스템이 어떤 환경에서 사용되며, 외부와 어떻게 연결되는지 파악하고 경계를 설정한다.	- 시스템 컨텍스트 모델 - 상호작용 모델 - 유스케이스	- 기상 관측소 시스템 컨텍스트 - Report Weather 유스케이스
2	시스템 아키텍처 설계 (Design the system architecture)	시스템을 구성하는 주요 컴포넌트와 그들의 상호작용을 정의하고, 아키텍처 패턴으로 구조화한다.	아키텍처 패턴 (계층형, 클라이언트-서버 등)	- 기상 관측소의 상위 수준 아키텍처 - 데이터 수집 시스템 아키텍처
3	주요 객체 식별 (Identify the principal system objects)	시스템에서 중요한 객체 클래스들을 식별하며, 이는 반복적이고 경험 기반의 과정이다.	- 명사/동사 식별 - 도메인 객체 - 행동/시나리오 기반 분석	- Thermometer, Barometer 등 장비 객체 - WeatherStation, WeatherData
4	설계 모델 개발 (Develop design models)	객체들과 그 관계, 상호작용, 상태 변화를 시각적으로 표현하여 구조와 동작을 설명한다.	- 구조적 모델 - 시퀀스 모델 - 상태 다이어그램	- 하위 시스템 모델 (패키지 구조) - 데이터 수집 시퀀스 - 기상 관측소 상태 다이어그램
5	객체 인터페이스 명세 (Specify object interfaces)	객체가 외부와 상호작용하는 기능(메서드)을 명확히 정의하여 병렬 설계를 가능하게 한다.	- 인터페이스 정의 - UML 클래스 다이어그램 - Java 코드	- Reporting 인터페이스 (weatherReport 등) - RemoteControl 인터페이스 (start/stop 등)

 

 

 

 

[2] 디자인 패턴 (Design patterns)

디자인 패턴

1. 정의

: a way of reusing abstract knowledge about a problem and its solution. 
(문제와 그 해결 방법에 대한 추상적 지식을 재사용하는 방식이다.)

 

2. 패턴

• A pattern : a description of the problem and the essence of its solution.
  (패턴은 문제와 그 해결 방법의 본질을 설명한 것이다.)
  • 그냥 코드가 아닌, "이런 상황에서 이렇게 해결하자"라는 전략이다.
• It should be sufficiently abstract to be reused in different settings.
  (다양한 환경에서 재사용할 수 있도록 충분히 추상적이어야 한다.)
  • 즉, 구체적인 언어나 기술에 묶여 있지 않아야 한다.
• Pattern descriptions usually make use of object-oriented characteristics such as inheritance and polymorphism.
  (패턴 설명은 보통 상속이나 다형성과 같은 객체지향 특징을 활용한다.)

패턴

1. 정의

: Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience.
(패턴과 패턴 언어는 최선의 사례, 좋은 설계, 그리고 그동안 쌓인 경험을 다른 사람들이 재사용할 수 있도록 묘사하는 방법이다.)

• 쉽게 말해, "비슷한 문제 상황에서 반복적으로 사용할 수 있는 설계 해법의 템플릿"이다.
• 패턴은 문제 + 해결 방법 + 결과를 묶어 놓은 재사용 가능한 설계 지식이다.
• 패턴 언어(Pattern Language)는 여러 패턴을 상황에 맞게 연결해 사용하는 방식까지 포함하는 더 확장된 개념이다.

 

2. 패턴 요소

• Name (이름)
  • A meanigful pattern identifier (의미 있는 패턴 식별자)
• Problem description (문제 설명)
• Solution description (해결 방법 설명
  • Not a concrete design but a template for a design solution that can be instantiated in different ways.
    (구체적인 설계가 아닌 다양한 방식으로 인스턴스화할 수 있는 설계 템플릿)
• Consequences (결과)
  • The results and trade-offs of applying the pattern.
    (패턴 적용의 결과 및 트레이드오프)

3. 예시 : 옵서버 패턴 (The Observer pattern)

• 이름 : 옵서버 (Observer)
• 설명 : 객체의 상태 표시를 해당 객체로부터 분리
• 문제 설명 : 상태를 여러 곳에서 표시해야 할 때 사용
• 해결 방법 설명 : UML 다이어그램 슬라이드 참조 
• 결과 : 표시 성능을 최적화하기 어려움

패턴 이름 (Pattern name)	옵서버 (Observer)
설명 (Description)	객체의 상태 표시를 해당 객체로부터 분리하고 대체 가능한 여러 표시 방법을 제공할 수 있도록 한다. 객체의 상태가 변경되면 모든 표시가 자동으로 알림을 받고 그 변경사항을 반영하여 업데이트된다.
문제 설명 (Problem description)	상태 정보를 여러 방식으로 표시해야 하는 상황이 자주 있으며, 예를 들어 그래픽 형태나 표 형태로 표시할 수 있다. 이들 표시 방법이 정보가 정의될 당시 모두 알려져 있지는 않을 수 있다. 모든 대체 표시 형식은 상호작용을 지원해야 하며, 상태가 변경되면 모든 표시가 업데이트되어야 한다. 이 패턴은 상태 정보를 여러 형식으로 표시해야 하고, 상태 정보를 관리하는 객체가 각 표시 형식에 대해 알 필요가 없는 모든 상황에서 사용할 수 있다.
해결 방법 설명 (Solution description)	두 개의 추상 객체 Subject와 Observer, 그리고 이를 상속받는 두 개의 구체 객체 ConcreteSubject와 ConcreteObserver로 구성된다. 추상 객체에는 모든 상황에서 적용 가능한 일반적인 연산이 포함된다. 표시할 상태는 ConcreteSubject에 저장되며, Subject로부터 Observer(각 Observer는 하나의 표시 화면을 의미)를 추가하거나 제거하고 상태가 변경되었을 때 알림을 발행할 수 있는 연산을 상속받는다. ConcreteObserver는 ConcreteSubject의 상태 사본을 유지하며, Observer의 Update() 인터페이스를 구현하여 상태 변경을 반영할 수 있도록 한다. ConcreteObserver는 상태를 자동으로 표시하고 상태가 변경될 때마다 이를 반영하여 업데이트한다.
결과 (Consequences)	Subject는 추상적인 Observer만 알고 구체 클래스에 대해서는 알지 못하므로 이들 객체 간 결합도가 낮다. 이로 인해 표시 성능을 향상시키는 최적화를 적용하기 어렵다. Subject의 변경은 Observer들 간 연쇄적인 업데이트를 유발할 수 있는데, 이 중 일부는 불필요할 수도 있다.

 

1) 옵서버 패턴을 사용한 다중 표시

 

2) 옵서버 패턴의 UML 모델

 

설계 문제 (Design problems)

: 패턴을 설계에 활용하려면, 자신이 직면한 설계 문제가 특정 패턴을 적용할 수 있는 문제인지 인식할 수 있어야 한다.

 

1. 종류

• (Observer pattern)
  • Tell several objects that the state of some other object has changed 
    (어떤 객체의 상태가 변경되었음을 여러 객체에게 알리고 싶을 때 (옵서버 패턴)
• (Façade pattern)
  • Tidy up the interfaces to a number of related objects that have often been developed incrementally 
    (점진적으로 개발된 관련 객체들의 인터페이스를 정리하고 싶을 때 (파사드 패턴))
• (Iterator pattern)
  • Provide a standard way of accessing the elements in a collection, irrespective of how that collection is implemented
    (컬렉션 내부 구현 방식과 관계없이 요소를 표준 방식으로 접근하고 싶을 때 (이터레이터 패턴))
• (Decorator pattern)
  • Allow for the possibility of extending the functionality of an existing class at run-time
    (실행 중 기존 클래스의 기능을 확장할 수 있도록 하고 싶을 때 (데코레이터 패턴))

 

 

 

[3] 구현 이슈 (Implementation issues)

Implementation issues (구현 이슈)

: Focus here is not on programming, although this is obviously important, but on other implementation issues that are often not covered in programming texts
(여기서의 초점은 프로그래밍에 있지 않으며, 이는 분명히 중요하지만, 프로그래밍 서적에서는 자주 다루지 않는 다른 구현 이슈들에 중점을 둔다)

 

1. 이슈 종류

• Reuse (재사용) - 기존에 잘 만들어진 코드나 시스템을 다시 사용하는 것
  : Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code.
  (현대 소프트웨어는 대부분 기존의 컴포넌트나 시스템을 재사용하여 구축된다. 소프트웨어를 개발할 때, 가능한 한 기존 코드를 많이 활용해야 한다.)
  • 예시 : 로그인 기능을 직접 만들기 보단, NextAuth와 같은 라이브러리를 활용
• Configuration management (구성 관리) - 버전과 변경 이력을 관리하는 것
  :  During the development process, you have to keep track of the many different versions of each software component in a configuration management system.
  (개발 과정에서는 각 소프트웨어 컴포넌트의 다양한 버전을 구성 관리 시스템에서 추적해야 한다.)
  • 도구 예시:  Git, GitHub, GitLab, SVN 등
• Host-target development (호스트-타겟 개발) - 개발하는 컴퓨터(Host)와 실행하는 컴퓨터(Target)가 다르다는 것
  • Production software does not usually execute on the same computer as the software development environment.
    (실제 소프트웨어는 보통 개발 환경과 동일한 컴퓨터에서 실행되지 않는다.)
  • Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system).
    (대신 한 컴퓨터(호스트 시스템)에서 개발하고 다른 컴퓨터(타겟 시스템)에서 실행한다.)
  • 예시 : 스마트워치용 앱을 맥북에서 개발하고, 실제로는 스마트워치에서 실행

 

<1> 재사용 (Reuse)

1. 등장 배경

• From the 1960s to the 1990s, most new software was developed from scratch, by writing all code in a high-level programming language.
  (1960년대부터 1990년대까지 대부분의 새로운 소프트웨어는 고수준 프로그래밍 언어로 모든 코드를 작성하여 처음부터 개발되었다.)
  • The only significant reuse or software was the reuse of functions and objects in programming language libraries.
    (소프트웨어에서의 유의미한 재사용은 오직 프로그래밍 언어 라이브러리에 있는 함수와 객체의 재사용뿐이었다.)
• Costs and schedule pressure mean that this approach became increasingly unviable, especially for commercial and Internet-based systems.
  (비용과 일정 압박으로 인해 이러한 접근 방식은 점점 실행 불가능해졌고, 특히 상업적이고 인터넷 기반 시스템에서 그 경향이 두드러졌다.)
• An approach to development based around the reuse of existing software emerged and is now generally used for business and scientific software.
  (기존 소프트웨어를 재사용하는 방식의 개발 접근법이 등장했으며, 현재는 비즈니스 및 과학 소프트웨어에서 일반적으로 사용되고 있다.)

 

2. 재사용 수준 (Reuse levels)

(낮은 수준 → 높은 수준)
- 추상화 수준 < 객체 수준 < 컴포넌트 수준 < 시스템 수준
- Abstraction level < Object level < Component level < System level

• The abstraction level (추상화 수준)
  • At this level, you don’t reuse software directly but use knowledge of successful abstractions in the design of your software.
    (이 수준에서는 소프트웨어를 직접 재사용하지 않고, 성공적인 추상화에 대한 지식을 소프트웨어 설계에 활용한다.)
• The object level (객체 수준)
  • At this level, you directly reuse objects from a library rather than writing the code yourself.
    (이 수준에서는 직접 객체를 라이브러리에서 재사용하고, 코드를 새로 작성하는 대신 이를 사용한다.)
• The component level (컴포넌트 수준)
  • Components are collections of objects and object classes that you reuse in application systems.
    (컴포넌트는 객체와 객체 클래스의 모음으로, 이를 애플리케이션 시스템에서 재사용한다.)
• The system level (시스템 수준)
  • At this level, you reuse entire application systems.
    (이 수준에서는 전체 애플리케이션 시스템을 재사용한다.)

3. 예시 : 소프트웨어 재사용

재사용 수준	설명	예시
Abstraction	설계 아이디어나 패턴 재사용	MVC, 디자인 패턴
Object	클래스, 함수 등 코드 단위 재사용	Java 라이브러리
Component	기능 단위 모듈 재사용	React 컴포넌트
System	전체 시스템 재사용	ERP, WordPress

 

4. 재사용 비용 (Reuse costs)

1) 종류

• 찾는 데 드는 시간과 노력의 비용
  The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs.
  (소프트웨어를 재사용할 수 있는 것을 찾고 그것이 요구사항에 맞는지 평가하는 데 드는 시간 비용.)
• 구매 비용
  : Where applicable, the costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high.
  (해당하는 경우, 재사용 가능한 소프트웨어를 구입하는 비용. 대형 기성 시스템의 경우, 이러한 비용은 매우 클 수 있다.)
• 맞춤 설정 비용
  The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that you are developing.
  (재사용 가능한 소프트웨어 컴포넌트나 시스템을 개발하는 시스템 요구 사항에 맞게 조정하고 구성하는 비용.)
• 통합 비용
  The costs of integrating reusable software elements with each other (if you are using software from different sources) and with the new code that you have developed.
  (재사용 소프트웨어 요소들 간의 통합 비용(다양한 출처에서 소프트웨어를 사용하는 경우)과 새로 개발한 코드와의 통합 비용.

항목	쉽게 말하면
찾는 비용	맞는 소프트웨어를 찾고 검토하는 시간
구매 비용	상용 소프트웨어의 라이선스 또는 사용료
수정 비용	우리 시스템에 맞게 고치고 설정하는 비용
통합 비용	재사용한 코드와 새 코드가 잘 맞게 연결하는 작업

 

 

<2> 구성 관리 (Configuration management)

1. 정의

: the name given to the general process of managing a changing software system.
(변화하는 소프트웨어 시스템을 관리하는 일반적인 과정에 대한 명칭이다.)

 

2. 목표

: to support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system. 
(시스템 통합 과정을 지원하는 것으로, 모든 개발자가 프로젝트 코드와 문서에 통제된 방식으로 접근할 수 있도록 하며, 어떤 변화가 있었는지 알아보고, 컴포넌트를 컴파일하고 링크하여 시스템을 생성할 수 있도록 돕는 것이다)

 

3. 구성 관리 활동 (Configuration management activities)

• Version management (버전 관리)
  : is provided to keep track of the different versions of software components. 
  (소프트웨어 컴포넌트의 다양한 버전을 추적할 수 있도록 지원한다.
  • Version management systems include facilities to coordinate development by several programmers.
    버전 관리 시스템은 여러 프로그래머의 개발을 조정하는 기능을 포함한다.)
• System integration (시스템 통합)
  : is provided to help developers define what versions of components are used to create each version of a system. 
  (개발자가 각 시스템 버전을 만들기 위해 어떤 버전의 컴포넌트를 사용해야 하는지 정의할 수 있도록 지원한다. 
  • This description is then used to build a system automatically by compiling and linking the required components.
    이 설명은 필요한 컴포넌트를 컴파일하고 링크하여 자동으로 시스템을 구축하는 데 사용된다.
• Problem tracking (문제 추적)
  : is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed.
  (사용자가 버그 및 다른 문제를 보고할 수 있도록 지원하고, 모든 개발자가 누가 이 문제를 작업하고 있는지, 그리고 그것이 언제 해결되는지를 볼 수 있도록 지원한다.)
• Release management (릴리스 관리)
  : new versions of a software system are released to customers.
  (새 버전의 소프트웨어 시스템을 고객에게 제공한다.)

 

4. 예시 : 구성 관리 도구 상호작용

✅ 요약 흐름

1. 버전 관리는 컴포넌트들의 버전을 추적하고
2. 그것들을 조합하여 시스템 버전을 만듭니다
3. 그 시스템은 빌드되고
4. 릴리즈 관리 과정을 거쳐 최종 사용자에게 배포됩니다
5. 동시에 변경 제안은 변경 관리 과정을 거쳐 시스템에 반영됩니다

✅ 구성 관리 핵심 도구 요약표

도구	역할
Version management	컴포넌트의 버전 관리
System building	시스템을 실제로 조립(컴파일 및 링크)
Change management	변경 요청을 접수하고 승인/거절 결정
Release management	새 버전을 사용자에게 릴리즈
System versions	시스템의 구성 상태를 정의
Component versions	개별 모듈/컴포넌트의 상태 정의
Change proposals	기능 추가, 버그 수정 등 요청

 

 

<3> 호스트-타겟 개발 (Host-target development)

 

1. 특징

• 개발하는 컴퓨터와 실행하는 컴퓨터는 다를 수 있다.
  : Most software is developed on one computer (the host), but runs on a separate machine (the target).
  (대부분의 소프트웨어는 한 컴퓨터(호스트)에서 개발되지만, 별도의 컴퓨터(타겟)에서 실행된다.)
  • 예시 : 게임을 노트북에서 개발하고, 실제로는 닌텐도 스위치에서 실행
• 플랫폼은 단순히 '컴퓨터'가 아니다.
  A platform is more than just hardware.
  (더 일반적으로, 우리는 개발 플랫폼과 실행 플랫폼에 대해 이야기할 수 있다.)
  • It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment.
    (플랫폼은 단순히 하드웨어를 넘어서서, 설치된 운영 체제와 데이터베이스 관리 시스템 같은 지원 소프트웨어, 개발 플랫폼의 경우에는 인터랙티브 개발 환경이 포함된다.)
  • 플랫폼의 예시 
    • 운영 체제 (예: Windows, Linux)
    • 필수 프로그램 (예: DBMS, 웹서버)
    • 개발 도구 (IDE, 컴파일러 등)
      
    • -> 같은 코드라도 플랫폼이 다르면 작동 방식이 달라질 수 있어요.
• 개발 환경과 실행 환경은 다를 수 있다.
  Development platform usually has different installed software than execution platform; these platforms may have different architectures.
  (개발 플랫폼은 실행 플랫폼과 설치된 소프트웨어가 다를 수 있으며, 이들 플랫폼은 서로 다른 아키텍처를 가질 수 있다.

구분	설명	사진 속 예시 항목
Host (호스트)	개발자가 소프트웨어를 작성하고 빌드(컴파일), 테스트하는 컴퓨터	Development platform, IDE, Compilers, Testing tools
Target (타겟)	완성된 소프트웨어가 실제로 실행되는 컴퓨터 또는 장비	Execution platform, Libraries, Related systems, Databases
Download software	호스트에서 개발된 프로그램을 타겟으로 전송하여 실행하도록 하는 과정	가운데 화살표: "Download software"

 

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

• 컴파일러 및 구문 지향 편집 시스템 도구
  An integrated compiler and syntax-directed editing system that allows you to create, edit and compile code.
  (코드 생성, 편집 및 컴파일을 허용하는 통합 컴파일러 및 구문 지향 편집 시스템)
• 디버깅 시스템
  A language debugging system.
  (언어 디버깅 시스템.)
• 그래픽 편집 도구
  Graphical editing tools, such as tools to edit UML models.
  (UML 모델을 편집하는 도구와 같은 그래픽 편집 도구.)
• 테스트 도구
  Testing tools, such as Junit that can automatically run a set of tests on a new version of a program.
  (새 버전의 프로그램에 대해 자동으로 테스트 세트를 실행할 수 있는 Junit과 같은 테스트 도구.)
• 프로젝트 지원 도구
  Project support tools that help you organize the code for different development projects.
  (다양한 개발 프로젝트를 위해 코드를 조직할 수 있도록 돕는 프로젝트 지원 도구.)

 

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

• Software development tools are often grouped to create an integrated development environment (IDE).
  (소프트웨어 개발 도구는 종종 통합 개발 환경(IDE)을 만들기 위해 그룹화된다.)
• IDE란?
  : An IDE is a set of software tools that supports different aspects of software development, within some common framework and user interface.
  (IDE는 공통 프레임워크와 사용자 인터페이스 내에서 소프트웨어 개발의 여러 측면을 지원하는 소프트웨어 도구 집합이다.)
• 특징
  • IDEs are created to support development in a specific programming language such as Java.
    (IDE는 JAVA와 같은 특정 프로그래밍 언어에서 개발을 지원하기 위해 만들어진다.)
  • The language IDE may be developed specially, or may be an instantiation of a general-purpose IDE, with specific language-support tools.
    (언어 IDE는 특별히 개발되거나 일반적인 IDE의 인스턴스로 특정 언어 지원 도구를 포함할 수 있다.)

 

4. Component/system deployment factors (컴포넌트/시스템 배포 요인)

• 호환되는 환경에 설치해야 한다.
  If a component is designed for a specific hardware architecture, or relies on some other software system, it must obviously be deployed on a platform that provides the required hardware and software support.
  (컴포넌트가 특정 하드웨어 아키텍처를 위해 설계되었거나 다른 소프트웨어 시스템에 의존하는 경우, 요구되는 하드웨어와 소프트웨어 지원을 제공하는 플랫폼에 배포되어야 한다.)
• 고장에 대비해 여러 군데 설치할 수 있다.
  High availability systems may require components to be deployed on more than one platform.
  (고가용성 시스템은 컴포넌트가 둘 이상의 플랫폼에 배포되어야 할 수 있다. 
  
  • This means that, in the event of platform failure, an alternative implementation of the component is available.
    (이는 플랫폼 장애 발생 시 대체 구현이 가능하게 한다.)
• 서로 자주 통신하는 컴포넌트는 가까이 두는 게 좋다.
  If there is a high level of communications traffic between components, it usually makes sense to deploy them on the same platform or on platforms that are physically close to one other.
  (컴포넌트 간의 통신 트래픽이 많을 경우, 보통 이들을 동일한 플랫폼이나 물리적으로 가까운 플랫폼에 배포하는 것이 합리적이다.)
  • This reduces the delay between the time a message is sent by one component and received by another.
    (이는 메시지가 한 컴포넌트에서 다른 컴포넌트로 전달될 때의 지연 시간을 줄여준다.)

 

 

 

핵심 사항 (Key points)

• 소프트웨어 설계와 구현은 상호 연관된 활동이다. 설계의 세부 수준은 시스템의 유형과 계획 주도 방식 또는 애자일 방식 사용 여부에 따라 달라진다.
• 객체 지향 설계 과정은 시스템 아키텍처를 설계하고, 시스템 내 객체를 식별하며, 다양한 객체 모델을 사용하여 설계를 설명하고, 컴포넌트 인터페이스를 문서화하는 활동을 포함한다.
• 객체 지향 설계 과정에서 다양한 모델들이 생성될 수 있다. 여기에는 정적 모델(클래스 모델, 일반화 모델, 관계 모델)과 동적 모델(시퀀스 모델, 상태 기계 모델)이 포함된다.
• 컴포넌트 인터페이스는 다른 객체들이 이를 사용할 수 있도록 정확하게 정의되어야 한다. UML 인터페이스 스테레오타입을 사용하여 인터페이스를 정의할 수 있다.
• 소프트웨어를 개발할 때는 기존 소프트웨어를 컴포넌트, 서비스 또는 전체 시스템으로 재사용할 가능성을 항상 고려해야 한다.
• 구성 관리는 발전하는 소프트웨어 시스템에 대한 변경을 관리하는 과정이다. 이는 여러 사람이 협력하여 소프트웨어를 개발할 때 필수적이다.
• 대부분의 소프트웨어 개발은 호스트-타겟 개발이다. 호스트 머신에서 IDE를 사용하여 소프트웨어를 개발하고, 이를 타겟 머신으로 전송하여 실행한다.