Dev.log

Design Pattern?

소프트웨어 공학론에서, 좋은 코드를 설계하기 위한 일종의 설계 디자인 방법론이다.

실무적으로 프로그래머들 사이에서 대중적으로 인정받는 일반화된 효율적인 설계 방식이다.

좋은 코드

좋은 코드란, 프로그램 개발 시에 맞닥뜨리는 여러 문제나 애로 사항들을 해결하고 만족할 수 있는 적절하게 짜여진 코드라고 볼 수 있다.

확장과 수정에 용이하며, 설계 이후 추가적인 유지 보수에 비용이 적게 들어가며

코드가 명확하고 단순하며

재사용성이 높고

리소스의 낭비가 없는 효율적인.

객체지향적 관점에서 이러한 부분을 구체적으로 명시하여 5가지 원칙으로 제시한 것이 SOLID이다.

SOLID

SOLID 원칙은 워낙에 유명하고, 알고 있으면 처음엔 와닿지 않더라도 개발하다보면 체감이 확 되는 내용이라 객체지향적 개발을 하는 프로그래머라면 두고두고 봐야하는 내용같다.

S

Single Responsibility Principle (SRP) : 단일 책임 원칙. 하나의 클래스는 하나의 책임만 가져야 한다.

O

Open/Closed PRinciple (OCP) : 개방 폐쇄 원칙. 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

L

Liskov Substitution Principle(LSP) : 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

I

Interface segregation Principle(ISP) : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

D

Dependency Inversion Principle(DIP) : 프로그래머는 추상화에 의존하며 구체화에 의존하면 안된다.

GoF 디자인 패턴

Gang of Fout는 유명한 개발자 4명인데, 디자인 패턴을 체계화한 사람들이다.

GoF 디자인 패턴은 생성(Creational) 패턴, 구조(Structural) 패턴, 행위(Behavioral) 패턴으로 구분된다.

SOLID 철학이 녹아있다.

생성 패턴

객체 생성과 관련한다.

추상 팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글턴

구조 패턴

클래스 및 객체를 조합해 더 큰 구조를 만드는 것과 관련한다.

어댑터, 브리지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프록시

행위 패턴

클래스 및 객체 간의 알고리즘이나 책임 분배와 관련한다.

책임 연쇄, 커맨드, 인터프리터, 반복자, 메멘토, 옵서버, 상태, 전략, 템플릿 메소드, 비지터

Requirement Engineering(요구공학)이란?

Requirements engineering(요구공학)은 고객이 시스템에 요구하는 서비스가 무엇인지 확립하고 시스템을 개발하고 운영하는 동안 충족해야하는 제약사항(constraint)이 무엇인가를 정립하는 과정이다.

실질적인 개발 과정에서 가장 먼저 진행되는 작업이다. 이 작업의 결과를 바탕으로 이후의 설계(design), 구현(implementation), 테스트(test)가 진행되기 때문에 굉장히 중요한 단계라고 볼 수 있다.

요구사항(requirements)으로서 정립되는 것에는 개발하고자 하는 시스템이 제공하는 기능, 서비스, 시스템이 반드시 충족해야하는 제약사항(constraint) 등이 있다. 이러한 요구사항을 도출, 정리, 분석, 검증해나가는 일련의 과정을 Requirement Engineering이라고 한다.

시스템에 대한 요구사항을 완전하게(complete), 그리고 요구사항 간의 충돌이 없도록 일관성 있게(consistent) 정립하는 것을 추구한다.

User and System Requirements

User requirements

시스템이 제공하는 서비스와 운영에 있어서의 제약사항들을 우리가 쓰는 언어인 자연어(natural language)와 추가적으로 이해를 높이기 위한 그림이나 표와 같은 diagram을 통해 보완하여 서술한다. 기술적 배경지식이 없어도 이해하기 쉽도록 하며, 주로 고객을 위해 쓰여진다. 

System requirements

User requirements보다 더 상세하며, 구조화된 기술적인 정보를 포함하는 문서이다. 무엇이 구현되어야 하는지 정의한다. 주로 클라이언트(client)와 계약자(contractor) 사이의 계약 또는 개발자를 위해서 쓰여진다. 

Functional, non-functional and domain requirements

functional requirements

시스템이 제공해야하는 서비스에 대한 기능, 시스템이 특정 입력값(input)에 대해서 어떻게 반응해야 하는지, 특정 상황에서 어떻게 동작해야 하는지 기능적인 요구사항을 기술한다. 이에 추가하여 시스템이 하지 말하야 하는 것에 대해서도 기술할 수 있다.

non-functional requirements

시스템에 의해 제공되어지는 서비스 및 기능들에 대한 각종 제약사항들(constraints)과 시스템 전체로서의 특성 및 안정성(safety), 성능(performance)에 대한 System Properties(+ emergent property) 대해 기술한다.

process requirements(개발 환경 - IDE, Programming Language, Framework, Development Method)도 이에 포함된다.

전반적인 시스템 구조에 치명적인 영향을 줄 수 있으므로 중요하다. 또한, 하나의 non-functional requirements로부터 여러 개의 functional requirements가 파생될 수 있다. (ex. security -> 각종 보안을 위한 functional requirements)

domain requirements

시스템의 운영 환경에서 사용되는 도메인의 여러 가지 속성들, 주제, 방법, 절차들에 대해 기술한 것으로, 개발자가 해당 시스템의 도메인에 대해 학습하고 내재되어있는 해당 requirements를 도출하도록 노력해야 한다. 전문성이 요구된다.

Requirement Imprecision

요구사항에 대한 유저의 이해와 개발자의 해석은 다를 수 있다.

고객은 보다 크게 생각하고, 개발자는 이를 작게 나누어 생각한다는 특성이 있다.

이러한 부분을 명확히 하지 않으면 갈등의 소지가 존재하게 된다.

Software Requirement Document

소프트웨어 개발자를 위해서 시스템이 무엇을 해야하는지 기술한 공식 문서이다.

User Requirements의 정의와 System Requirements의 명세를 모두 포함해야 한다.

Design Document가 아니기 때문에 How(How System should do)가 아닌 What(What System should do)에 초점을 둔다.

Agile Methods and requirements

많은 애자일 방법론에서 요구 문서(requirements document)를 작성하는 것은 시간 낭비라고 여기기도 한다. requirements는 끊임없이 변화하기 때문이다. 따라서 XP(Extreme Programming)와 같은 메소드에선 incremental requirement engineering 또는 requirements를 user stories로써 기술하기도 한다.

이러한 관점은 실질적인 비즈니스 시스템에서 충분히 제기될 수 있는 관점이지만, 여러 팀에서 함께 개발하는 대규모 시스템 또는 충분한 사전 분석이 필요한 핵심적인 시스템을 개발할 때는 문제가 될 수 있다.