software-engineering

Software Engineering (소프트웨어 공학)

작성자 : 장주섭, 이세명

Table of Contents

• 명령형 프로그래밍 vs 선언형 프로그래밍
• 함수형 프로그래밍
• 객체지향 프로그래밍
• 애자일 개발 프로세스

---

프로그래밍 패러다임

명령형 프로그래밍 vs 선언형 프로그래밍

함수형 프로그래밍은 선언형 프로그래밍이다.

• 명령형 프로그래밍 :

  명령형 프로그래밍은 어떻게(HOW) 목적을 달성 할 지에 초점이 맞추어져 있고 프로그래밍의 상태와 그것을 변경시키는 구문의 관점에서 연산을 설명하는 프로그래밍 패러다임이다. 그래서 프로그래밍에 사용된 알고리즘에 대해서는 명시되어 있고 목표에 대해서는 명시되어 있지 않다. 일반적으로 컴퓨터가 수행할 명령들을 순서대로 써내려가는데 일반적인 예시로는 C, C++, Java, Paskal, Ruby 등 우리가 아는 웬만한 절차형, 객체지향 언어들은 명령형 프로그래밍 언어이다.

• 선언형 프로그래밍 :

  선언형 프로그래밍은 일반적으로 두 가지 정의로 나뉜다.

  1. 선언형 프로그래밍은 무엇을(WHAT) 할지에 초점이 맞추어져 있는 프로그래밍 패러다임이다. 알고리즘은 명시하지 않고 목표에 대해서만 명시 한다. 예를들어 HTML 과 같이 무엇을 웹에 나타낼지에 대해 고민하는 것이지 어떤 방법으로 나타낼지를 고민 하는 것이 아니다.
  2. 함수형, 논리형, 제한형 프로그래밍 언어로 쓰인 경우 선언형 프로그래밍이라고 한다. 명령형 언어와 대비되는 프로그래밍 언어들을 선언형으로 통칭한다. 하지만 이 중 논리형, 제한형 프로그래밍 언어 같은 경우 명백히 알고리즘을 설명할 수 있고 구현도 가능하기 때문에 첫번째 정의를 따르는 엄밀한 의미의 선언형 프로그래밍은 아니다.

함수형 프로그래밍

함수형 프로그래밍을 배워야 하는 이유

"일반적인 프로그래밍은 그냥 생각하면 되는 것이고, 함수형 프로그래밍은 기존과 다르게 생각하는 방법을 알려줄 것이다. 그러므로 당신은 아마도 예전 방식으로 절대 돌아가지 않을 것이다."

함수형 프로그래밍은 프로그래밍 언어나 방식을 배우는 것이 아니라 함수로 프로그래밍 하는 사고를 배우는 것이다. 즉 기존의 사고방식을 전환하여 사고를 유연하게 문제 해결에 접근 하는 것이다.

함수형 프로그래밍이란?

함수형 프로그래밍이란 자료처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나이다. 명령형 프로그래밍에서 상태를 바꾸는 것을 강조하는 것과는 달리 함수형프로그래밍은 함수의 응용을 강조한다. 따라서 프로그래밍이 식이나 선언으로 수행되는 선언형 프로그래밍 패러다임을 따르고 있다.

• 명령형 프로그래밍의 함수와 수학적 함수의 차이

  명령형 프로그래밍의 함수 : 프로그램의 상태의 값을 바꿀 수 있다. 이 때문에 참조 투명성이 없고 같은 코드라 해도 실행되는 프로그램의 상태에 따라 다른 결과값을 낼 수 있다.

  함수형 프로그래밍 (수학적) 함수 : 이 함수의 출력값은 함수에 입력된 인수에만 의존하므로 인수 x에 대해 함수 f 를 호출 하면 f(x) 라는 결과가 나온다. 이것은 프로그램의 동작을 예측하기 훨씬 쉬워진다. (함수형 프로그래밍 개발 핵심 동기)

  함수형 프로그래밍은 순수함수(pure function) 을 조합하고 공유상태(shared state), 변경 가능한 데이터(mutable data) 및 부작용(side-effects) 을 피하여 소프트웨어를 만드는 프로세스이다.

함수형 프로그래밍 주요 개념

1. 순수 함수(pure function) : 무조건 같은 입력이 주어지면 같은 출력을 반환한다. 또한 부작용이 없는 함수 이다.
2. 합성 함수(function composition) : 새로운 함수를 만들기 위해 둘 이상의 함수를 조합하는 과정이다. f(g(x))로 이해하면 된다. 합성 함수는 함수형 프로그래밍을 이용하여 소프트웨어를 구성하는 중요한 방법이다.
3. 공유 상태(shared state) : 공유 범위(shared scope) 내에 있는 변수, 객체 또는 메모리 공간이거나 범위 간에 전달되는 객체의 속성입니다.
4. 불변성(Immutability) : 변경할 수 없는 객체란 생성한 후에 수정할 수 없는 객체이다. 불변성은 함수형 프로그래밍의 핵심 개념이다. 불변성을 빼면 프로그램의 데이터 흐름이 손실되기 때문이다.
5. 부작용(side effects) : 반환값 이외에 호출된 함수 외부에 영향을 끼치지는 것이다. 따라서 부작용이 없는 순수한 함수는 스레드 측면에서 안전하고 병렬적인 계산이 가능하다.
   • 외부 변수 또는 객체 속성 수정
   • 콘솔에서 로깅
   • 화면에 쓰기 작업
   • 파일에 쓰기 작업
   • 네트워크에 쓰기 작업
   • 외부 프로세스를 트리거
   • 부작용을 동반한 다른 함수 호출
6. 고차함수(high order function) : 함수를 인수로 취급하거나, 함수를 반환하거나 또는 둘 다인 함수이다.
   • 콜백 함수, 프로미스, 모나드 등을 사용하여 액션, 효과 또는 비동기 흐름을 추상화하거나 분리
   • 다양한 데이터 타입에 대해 동작할 수 있는 유틸리티 만듬
   • 합성 함수나 재사용의 목적으로 커링 함수를 만들거나 인수를 함수에 부분적으로 적용
   • 함수 목록을 가져오고, 입력 함수의 합성을 반환

객체지향 프로그래밍

객체지향 프로그래밍 이전 패러다임

1. 순차적, 비구조적 프로그래밍 : 말그대로 순차적으로 코딩해 나가는 것, 필요한 것이 있으면 순서를 추가해가면서 구현하는 방식이다. 직관적이지만 goto문을 활용하므로서 규모가 매우 커지게 되고 나중엔 코드가 어떻게 연결되었는지 구분하기 매우 어렵다.
2. 절차적, 구조적 프로그래밍 : 위 프로그래밍 방식을 개선하기 위해 나온 패러다임이다. 반복될 가능성이 높은 함수(프로시저)들을 따로 만들어 사용하는 방식이다. 하나의 큰기능을 처리하기 위해 작은 단위의 기능들으로 나누어 처리하고 비교적 작은 규모의 작업을 수행하는 함수를 생성한다. 하지만 이러한 절차적, 구조적 프로그래밍은 함수(논리적 단위)는 표현이 되지만 실제 데이터에 대한 변수 나 상수(물리적 단위)의 표현에는 어려움이 있다. 이러한 단점은 프로그램을 비효율적으로 코딩하게 되고 결국은 유지보수와 디버깅에 어려움을 가져온다. 즉 큰 규모의 작업으로 갈 수 록 더 효율적인 모듈화와 데이터 관리가 필요하다 그렇기에 나온게 데이터와 함수를 동시에 관리 할 수 있는 객체지향 프로그래밍이 각광받게 된다.

객체 지향 프로그래밍이란?

객체 지향 프로그래밍은 특정한 개념의 함수와 자료형을 함께 묶어서 관리하기 위해 탄생한 것이다. 즉 객체 내부에 자료형(필드)와 함수(메소드) 가 같이 존재 한다. 객체지향 프로그래밍을 하면 객체간의 독립성이 생기고 중복코드의 양이 줄어드는 장점이 있다. 또한 독립성이 확립되면서 유지보수에도 큰 도움을 주게 된다.

또한 이러한 객체들 끼리 서로 상호작용하면서 어떠한 문제를 해결해 나가는 것이 객체지향 프로그램이다.

객체 지향 프로그래밍의 특성

1. 추상화(Abstraction)

   어떤 영역에서 필요로 하는 속성이나 행동을 추출하는 작업 , 즉 모델화

   • 사물들의 공통된 특징, 즉 추상적 특징을 파악해 인식의 대상으로 삼는 행위
   • 구체적인 사물들의 공통적인 특징을 파악해서 이를 하나의 개념(집합)으로 다루는 수단

   구체적인 개념에 의존

   switch(동물의 종류){
    case 사자 : //somthing
    case 호랑이 : // something
    case 토끼 : // someting
   }

   새로운 종이 추가 되면 코드를 새로 추가 해야함

   추상적인 개념에 의존

   void something(Animal a){
    a.something();
   }

   새로운 종이 나와도 코드를 변경 할 필요가 없다. 뒤에서 다형성에 의한 오버라이드로 처리

2. 캡슐화(Encapsulation)

   높은 응집도(Cohesion) 과 낮은 결합도(Coupling) 를 유지해야 요구사항에 맞춰 유연하게 대처 할 수 있다.

   • 응집도 : 모듈(클래서) 내에서 요소들이 얼마나 밀접하게 관련이 있는지, 응집도는 정보 은닉을 통해 높일 수 있다. 즉, 내부에서만 사용하는 정보는 외부에서 접근하지 못하도록 제한하는 것이다. Ex) private
   • 결합도 : 어떠한 기능을 수행하는데 다른 모듈(클래스)에 얼마나 의존적인지

3. 일반화(Generalization) : 상속

   이미 정의된 상위클래스의 모든 속성과 연산을 하위클래스가 물려 받는 것을 의미한다.

   • 일반화를 이용 하면 상위 클래스로 부터 상속받은 하위 클래스는 모든 속성(필드)과 연산(메소드)을 다시 정의하지 않고 자신의 것으로 사용 할 수있다.
   • 상속받은 속성과 연산 외에 새로운 속성과 연산을 추가하여 사용 가능하다.
   • 클래스를 재사용 하므로서 소프트웨어 재사용성을 증대시키는 중요한 개념이다.

4. 다형성(Polymorphism)

   1. Pure Polymorphism : 서로 다른 클래스의 객체가 같은 메세지를 받았을때 각자의 방식으로 동작하는 능력이다.

      • 일반화와 함께 프로그램을 변화에 유연하게 만든다.
      • 다형성을 사용할 경우 어떤 클래스가 참조 되었는지 무관하게 프로그래밍 할 수 있다.

   2. Ad hoc polymorphism : Overridng & Overloading

   3. Generics (parameter type) : T (type parameter, 어떤 타입이 와도 무관)

객체지향 설계 원칙 SOLID

1. SRP(단일 책임의 원칙 : Single Responsibility Principle) : 작성된 클래스는 하나의 기능만 가지며 클래스가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어 있어야 한다는 원칙

2. OCP(개방폐쇄의 원칙 : Open Close Principle) : 소프트웨어의 구성요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙. 변경은 최소화 하고 확장을 최대화

3. LSP(리스코브 치환의 원칙 : The Liskov Substitution Principle) : 서브타입은 언제나 기반 타입으로 교체할 수 있어야 한다는 원칙, 즉 항상 하위 클래스는 상위 클래스를 대신할 수 있다. 상위클래스가 할 수 있는 일들에 대해선 하위클래스는 당연히 할 수 있다는 원칙이다.

4. ISP(인터페이스 분리의 원칙 : Interface Segregation Principle) : 인터페이스 분리 원칙은 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 인터페이스 분리 원칙은 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 이용할 수 있게 한다. SRP 는 클래스의 단일 책임이라면 ISP는 인터페이스의 단일 책임을 강조하는 것이다.

5. DIP(의존성 역전의 원칙 : Dependency Inversion Principle) : 자주 변화하는 구체적인 클래스 보다는 변화하기 어려운 인터페이스나 상위(추상) 클래스와 관계를 맺으라는 원칙

---

애자일 개발 프로세스

아래의 자료에서 자세한 설명과 코드를 볼 수 있다.

• 작성자 이세명 | Agile Software Development
• 작성자 정희재 | eXtreme Programming(XP)

---

질의응답

질문에 대한 답을 말해보며 공부한 내용을 점검할 수 있으며, 클릭하면 답변 내용을 확인할 수 있습니다.

애자일처럼 소프트웨어 공학에서의 개발 프로세스를 적용하여 프로젝트를 진행한 경험이 있으신가요? 어떻게 진행했나요?

지원자의 경험을 스크럼, XP, 폭포수 모델 개발 방법 등의 진행 과정을 설명하면 됩니다. 아래는 답안의 한 예시로 참조하시면 되겠습니다.

매일매일 짧게라도 회의를 진행하여 계획하고, 리팩토링을 두려워하지않고 프로토타입을 만드는 것을 먼저 생각했다.
사용할 기능에 대한 우선순위를 두어 개발 주기마다 적용할 기능의 목록을 만들어보았고 적용시킨 후 팀원들의 리뷰를 통하여 제품을 학습하고 이해하였다. 이 후 또 다음 백로그를 준비하는 스크럼 방법을 사용했다.

애자일 개발 방법이 생겨나게 된 배경에 대해서 설명 해주실 수 있나요?

전통적인 프로그램 개발 방법론에서는 대규모 프로젝트를 진행할 때 개발보다는 문서화, 회의, 설계 등의 업무에 더 많은 시간을 소비했다.
또한 전통적인 개발 방법론은 소비자의 요구사항이 변동되었을 때 그에 대해 빠르게 대응하지 못하는 단점이 있었다.
애자일은 이러한 전통적인 방법론보다 더 나은 방법을 찾고자 하는 데에서 시작되었다.

요즘 많은 기업들이 애자일 프로세스를 따르고 있습니다. 왜 그럴까요?

• 변화에 대해 신속하고 능동적인 대응이 가능합니다.
• 이해관계자들과 효과적인 소통이 가능합니다.
• 개발자들이 개발에 좀 더 집중할 수 있습니다.

개발 단계를 기획-설계-구현-테스트 이렇게 네 가지 단계로 분류한다고 했을 때 본인이 생각하기에 가장 시간과 비용이 많이 요구되는 단계는 어디라고 생각 하시나요? 그 이유와 함께 답변 부탁드립니다.

2021년 현재 소프트웨어 생명 주기 단계 중 시간과 비용이 가장 많이 요구되는 단계는 '테스트' 단계입니다.
이해하기 쉽게 예시를 들어 설명하겠습니다.

자동차에 관한 소프트웨어라면 처음부터 안전을 우선순위로 설계하여 구현함에도 실제 테스트단계에서 일어나는 예외사항에 많은 시간과 비용이 들어갑니다. 이상이 일어날 시에 불가피한 리팩토링은 많은 시간과 비용을 사용하여야 합니다. 또한 자동차 뿐만 아니라 스마트폰 및 게임에서도 테스트가 시간과 비용이 가장 많이 요구되었습니다.

Validation과 Verification 이라는게 있습니다. 한국어로 풀이하면 둘다 검증, 확인이라는 뜻으로 똑같이 해석이 되는데 소프트웨어공학의 입장에서 보면 이 두 단어는 서로 비슷하지만 다른 뜻을 가지고 있습니다. 이 둘의 차이점에 대해서 설명해주실 수 있나요?

• Validation : 소프트웨어의 기능과 목적이 요구사항을 반영하는가, 일치하는가, 누락된 요구사항은 없는가
• Verification : 소프트웨어의 입력에 대해 출력 값이 요구사항에서 원하는 바와 일치하는가 즉, 버그가 없는가

요구사항 명세서란 무엇인가요? 왜 필요한가요?

개발할 소프트웨어의 기능적, 비기능적 요구사항을 서술해 놓은 것을 의미합니다. 이해 관계자와 소프트웨어 개발자들의 의사소통 도구로 사용됩니다.

• 제품의 기능에 대한 기본적인 합의를 수월하게 도출해낼 수 있습니다.
• 각 기능을 개발하기 위한 비용과 스케줄을 예측할 수 있는 지표가 되기도 합니다.
• 효율적인 개발 계획을 세울 수 있고 제품 테스트, 검증을 위한 베이스를 제공해줍니다.
• 제품의 성능 향상을 위한 기반이 되는 자료 입니다.