테일러링(Tailoring) 이란?

Tailoring 종류

Tailoring 절차

Tailoring 효과

프로그래밍 – 구현

설계작업들이 끝나면 시작되는 소프트웨어 프로그래밍은 요구사항에 대한 실질적인 구현행위이다. 특히 분리하여 구현할 수 있는 작은 단위로 나눠 작업을 한다. 프로그래밍의 수행이 상세 설계나 사용자 지침에 기술된 내용과 일치되도록 작업하여야 한다. 이 작업에서 가장 중요한 것은 표준을 정하고 준수하고 이에 따라 정확하게 작성하는 것이다. 소프트웨어의 품질은 결국 이를 얼마나 잘 수행하여 원시 코드에 반영하느냐이다. 따라서 프로그래밍에서는 소프트웨어의 기능구현이 급급한 것이 아니라 요구되는 품질에 얼마나 부합하도록 작업하는가에 대한 관심과 끊임없는 노력이 매우 중요하다. 

※ 코딩과 프로그래밍?
이 용어는 모두 컴퓨터와 상호 작용하고 컴퓨터 시스템을 생성하고 유지 관리하는 데 중요한 기술로 종종 같은 의미로 사용되지만, 프로그래밍 과정 중 코드를 작성하는 구체적인 단계를 가리키며, 프로그래밍은 문제 해결을 위한 전체적인 과정을 의미하기에 사실은 서로 다르다.

• 코딩(coding): 프로그래밍의 하위 세트 중 하나로 구체적으로 언어의 문법을 따라 컴퓨터가 이해할 수 있는 명령어를 작성(원시 코드)하는 작업으로, 프로그램 로직을 작성하고 알고리즘을 구현하며 문제를 해결하기 위한 코드를 작성하는 활동
• 프로그래밍(programming): 문제 해결을 위해 컴퓨터에 명령을 전달하는 전체적인 과정으로 문제를 이해, 정의하고 요구사항을 분석하며 그에 따라 적절한 알고리즘과 데이터 구조를 선택한 후 코드를 작성하는 단계와 함께 디버깅, 테스트, 최적화 등의 소프트웨어 개발 과정을 포괄하는 개념으로 컴퓨터 시스템을 생성하고 유지관리하는 프로세스

프로그래밍 원리

앞서 용어 정의와 같이 코딩은 프로그래밍 작업이다. 이러한 구현단계의 목표는 설계 명세에 나타난 대로 사용자 요구를 만족할 수 있도록 프로그래밍을 하는 것이다. 이렇게 하기 위해서는 코딩 단계에서는 전 단계의 문서들을 잘 참조하여야 한다. 특히 무엇보다도 오류가 적은 품질 좋은 프로그램을 작성하는데 그 목표가 있다. 신속성도 중요하지만 견고한 코드를 만들어내는 것에는 많은 연습과 경험이 필요하다. 이를 위하여 수많은 원리와 가이드를 만들고 잘 참고해야 한다.

일반적인 객체지향 코딩에는 다음과 같은 단계가 있다.

• 원시 코드 스타일의 코딩표준 작성
• 아키텍처 설계 결과 프레임워크 패키지와 응용 패키지 결정
• 패키지 내 각 클래스에 대해 요구사항과 상세설계를 반영한 메소드 코딩
• 클래스 구현 후 인스펙션 실시
• 클래스 단위 테스트 진행
• 클래스/패키지를 배포, 통합

이러한 작업을 진행하면서 오류는 프로그래머가 가장 신경 써야 할 부분 중 하나다. 개발과정에서는 특히 많은 시간이 오류를 찾고 해결하는 데 쓰이는데 일정 부분 이상은 흔히 발견되는 오류로 이를 알고 접근한다면 많은 부분의 비용을 절감할 수 있다. 아래는 여러 오류 중 중요한 몇 가지의 예이다.

• 메모리 누수: 이는 메모리가 풀리지 않고 계속 할당하는 현상으로 보통 가비지 컬렉션이 자동으로 되지 않은 언어에서 이러한 오류가 자주 발생한다. 메모리 누수는 규모가 작은 프로그램에서는 영향이 적지만 대규모 환경에서는 시스템에 매우 치명적인 영향을 줄 수 있으므로 반드시 잡아야 한다.
• 중복된 해제 선언: 프로그램 내에서는 자원할당 후 사용 후 해제해야 한다. 그런데 해제된 자원을 또다시 해제하는 경우도 매우 심각할 수 있다. 만약 두 개의 해제문장 사이에 메모리 할당 호출이 있다면 이런 오류의 영향은 예측할 수 없다.
• NULL: null을 포인트하고 있는 곳의 내용에 접근하려고 하면 오류가 난다. 이는 시스템을 다운시키기에 충분하다. 그런데 찾기도 어려운 것이 이것이다.
• 배열 인덱스 오류: 배열 인덱스의 한도를 벗어나면 예외 오류가 발생한다. 그러므로 인덱스가 음수 또는 한도를 벗어나지 않는지 항시 확인하여야 한다.
• 수식 예외: 0으로 나눈다거나 변동 소수점 예외 오류 등이다. 
• 사용자 정의 자료형: 오버플로우나 언더플로우가 특히 많다. 
• 버퍼 오류: 보안결함에서 많이 발견되는 유형으로 해커들의 잠입 루트가 되기도 한다. 
• 동기화: 공통된 자원에 접근하는 다수의 스레드가 있는 병렬 프로그램에서 흔하게 발견된다. 이 또한 쉽게 발견되기가 어려운데 시스템에는 막대한 지장을 줄 수 있다. 흔히 deadlock이 여기에 속한다.

구조적 프로그래밍, 이를 위해서 많이 사용하는 제어구조가 있는데 순차, 선택, 반복이다. 이 또한 제대로 된 흐름제어 기준을 정해놔야 한다. 무조건적인 제어의 흐름을 막고 알고리즘을 명확하게 구현할 수 있는 가이드를 제시하고 공유한다. 물론 근래의 프로그래밍 언어들은 이를 고려하여 여러 명령어나 제약을 두고 있으며 필요하다면 비구조적 문형으로 개발을 할 수도 있다.

또한 모든 프로그램에는 항상 도메인에 관한 정보를 다루기 때문에 자료구조가 항시 존재한다. 그래서 특정 정보에 대해서는 정해진 오퍼레이션만 적용된다. 즉 문제 도메인에 있는 아주 작은 정보가 제한된 방법으로만 사용된다는 것이다. 이를 앞서 다뤄본 정보은닉의 원리 적용이다. 정보은닉이란 모듈 사이의 결합을 줄이고 시스템의 유지보수를 쉽게 만드는 장점을 가지고 있고 데이터를 관리하려는 관점과 데이터를 사용하는 관점을 분리할 수 있는 것이다.

코딩 스타일

프로그래밍 스타일이다. 같은 작업을 위하여 여러 사람이 작성한 프로그램들은 문장의 패턴이나 그 구성 등 여러 면에서 다른 스타일을 보인다. 각자의 개성이다. 하지만 이를 방치할 경우 프로젝트는 원하는 목표를 달성하기 어렵다. 그래서 가르치고 학습할 수 있는 공통된 스타일을 만들어야 한다. 물론 여기에서도 기준을 구하기 어려울 수도 있지만 가장 근본은 간결하고 읽기 쉬워야 한다는 것이다. 이를 기준 삼아 코딩 스타일을 만든다.

• 명명 규칙 예
  • 패키지: 타 사용자들을 위해 패키지 이름 앞에 도메인명을 붙인다. 이를 통해 패키지의 용도와 목적을 잘 나타낼 수 있다.
  • 타입: 클래스(명사)와 인터페이스(명사, 형용사) 등의 명칭 첫 글자를 대문자로 한다. 이는 일반 변수와 구별할 수 있다.
  • 메소드: 타입과 달리 첫 글자를 소문자(동사)로 하고 연속되는 단어의 첫 글자는 대문자로 한다. 이는 메소드 호출과 생성자 호출과 구별할 수 있게 해준다.
  • 변수: 메소드와 같은 형식이다.
  • 상수: 보통 대문자로 구성하며 단어 사이는 밑줄로 연결한다.
• 포인터와 레퍼런스: 포인터를 매개변수로 사용하지 않고 레퍼런스 타입으로 한다.
• 자료형: 오브젝트 타임을 돌려보내는 클래스는 특정 타입의 객체를 배출하도록 캐스트 한다.
• 문장과 수식: 반복 문장이나 수식은 메소드나 클래스로 패키지화하여 사용한다.
• 오류처리: 오류 데이터 타입 제한, 입력 처리 전 데이터 소스와 인터페이스 하여 사전 확인 등의 방법이 필요하다.
• 들여쓰기: 코드 블록의 계층 구조를 명확하게 표현할 수 있게 공백 문자나 탭을 사용한다.
• 주석: 코드 설명을 부가적으로 추가한다. 양의 문제보다는 내용을 정확히 전달하는 것이 중요하다.
• 코드 문서화: 다른 사람들이 정확하게 사용할 수 있도록 주석을 명확히 하고 문서화도 병행한다.
• 포맷 도구 사용: 개발 환경 편집기에 있는 기능으로 스타일가이드를 바탕으로 세팅하여 사용할 수 있다. 이를 통해 일관된 스타일 유지가 가능하다.

프로그램 설계

프로그램 설계(Programming Design)는 소프트웨어 공학의 개발 과정 중 하나로, 시스템의 각 모듈 안에서 일어나는 일들과 모듈 안에서의 자료구조에 관하여 설계하는 단계이다. 각 모듈 안에 사용될 알고리즘을 고안하는데 이는 소프트웨어 개발에서 설계 도면과 같은 역할을 한다. 이런 프로그램 설계는 시스템 구조설계와 분리하여 별도의 단계로 추진하기도 하지만 때로는 병행 진행하기도 한다. 프로그램 설계는 효율적이고 유지보수가 가능한 소프트웨어 시스템을 만들기 위해 필수적인 활동이며 요구사항 분석을 바탕으로 시스템의 목표를 이루기 위한 적절한 아키텍처와 구조를 결정하는 것으로서 잘 설계된 소프트웨어 시스템은 확장성, 유지보수성, 재사용성 등을 갖추어 복잡한 프로젝트의 성공을 보장하는 데 도움을 준다. 이에 프로그램 설계는 크게 두 가지 측면에서 이루어진다.

• 구조적 설계: 시스템을 하위 모듈로 분할하고 각 모듈 간의 인터페이스와 관계를 정의한다. 모듈은 기능적으로 관련된 작업을 수행하는 코드 블록으로 소프트웨어 시스템을 조직화하는 데 사용되며 시스템 전체적인 레이아웃을 계획하고 모듈 간의 데이터 및 제어 흐름을 결정하는 역할이다.
• 상세 설계: 구조적 설계 완료 후, 각 모듈의 내부 동작 및 구현 세부 사항을 정의하는 단계로 모듈 내부의 변수, 함수, 알고리즘 등을 설계하며 코드의 실제 구현 방식을 결정한다. 이는 실제 프로그래밍 단계에 진입하기 전에 개발자들이 따라야 할 로드맵을 제공한다.

구조적 설계에 이어 상세설계 단계는 모듈을 하나씩 다룬다. 각 모듈을 구현하기 위한 알고리즘을 선택하고 기술하는 것이다. 시스템 구조설계가 잘 이루어진 상태라면 각 모듈 안의 설계는 어렵지 않다. 각 모듈의 역할이 분명하고 모듈 사이의 결합도가 낮게 구성되기 기 때문이다. 설계의 원리들을 따 잘 설계하였다면 모듈을 어떻게 구현할 것인가를 결정하는 일은 알고리즘 선택으로 국한된다.

알고리즘 선택

알고리즘 선택의 3가지 원칙은 다음과 같다.

• 정확성: 알고리즘은 기본적으로 정확해야 한다. 기술된 알고리즘은 제공된 자료를 정확하게 처리하여야 하며 정의된 기능 또한 정확하게 수행하여야 한다. 이런 상황에서 모듈이 수행하여야 할 기능이 새로운 것이 아니라면 기존의 프로그램이나 알고리즘 모음집 등의 자료를 참고하는 것도 좋은 방법이다. 프로그램을 처음부터 새로 구현하는 것보다 증명된 알고리즘을 사용하거나 이미 수행된 프로그램을 사용하면 개발비용과 시간을 절약할 수 있다.
• 효율성: 알고리즘의 수행에 필요한 컴퓨터 자원의 양을 말한다. 이는 기억장치의 소요량과 수행시간이다. 특히 수행시간은 알고리즘과 밀접한 관계가 있다. 알고리즘의 기본 동작 수는 알고리즘에 따라 선형적일 수도 있고 비선형적일 수도 있다. 같은 문제에 대해서 접근법이 다르다면 그 결과는 천차만별이다. 즉 효율성을 높이면 처리 속도는 매우 크게 개선되며 모듈 안에서의 효율성과 전체 시스템의 효율성을 같이 고려하여 알고리즘을 구현해야 한다.
• 적합성: 알고리즘은 목표 시스템의 하드웨어와 소프트웨어에 맞아야 한다. 이는 시스템의 특성, 목표, 제약조건 등을 충분히 감안하여 그 방향성에 맞춰 알고리즘을 구사하여야 한다. 설계단계의 모든 것이 고려되어야 하며 필요시 보다 맞는 알고리즘으로 대체할 수 있는 계획을 가지고 있어야 한다.

알고리즘 표현

설계단계에서 사용되는 모든 표현법은 매우 중요하다. 이는 의도하는 바를 정확하게 나타낼 수 있고 의사소통을 원활하게 해준다. 모듈 안 알고리즘을 기술하는 방법도 여러 가지가 있다.

• 나씨-슈나이더만도표(Nassi-Shneiderman Diagram): 제어 구조를 시각적으로 표현하는 것으로 제어 흐름을 명확하게 표현하여 프로그램의 논리를 이해하고 분석하는데 순차, 선택, 반복과 같은 기본적인 제어 구조를 사용하여 알고리즘을 표현
• 자연어: 일반적인 언어를 사용하여 알고리즘을 설명하는 것으로 비기술적인 사람들도 쉽게 이해할 수 있으나 그 모호성이나 해석 차이로 인해 정확한 이해를 보장하지 않을 수 있음
• 순서도(Flowchart): 도형과 화살표를 사용하여 알고리즘의 흐름을 시각적으로 나타내는 것으로 시작과 종료 점, 결정, 처리, 입출력 등의 기호로 표현하여 알고리즘의 논리 구조를 표현
• 의사 코드(Pseudo code): 일반 언어와 프로그래밍 언어의 중간 형태로 인간이 이해하기 쉬운 형태의 코드이며 실제 프로그래밍 언어가 아니므로 특정 구문이나 규칙에 얽매이지 않고 알고리즘의 논리적 흐름을 설명 가능
• 프로그래밍 언어: 알고리즘을 실제 프로그래밍 언어로 구현하여 나타내는 방법으로 컴퓨터가 직접 실행할 수 있도록 하며 알고리즘의 구현 세부 사항을 정확히 표현 가능
• 통합 모델링 언어(UML: Unified Modeling Language): 주로 소프트웨어 설계와 모델링에 사용되며 다이어그램을 사용하여 시스템의 구조와 동작을 표현하고 클래스 다이어그램, 시퀀스 다이어그램, 상태 다이어그램 등을 활용
• 스토리보드: 주로 사용자 인터페이스 설계에서 활용되며 그림과 텍스트를 사용하여 사용자와 시스템 간의 상호작용 흐름을 시각적으로 표현

사용자 인터페이스 설계

사용자 인터페이스 설계(User Interface Design)는 소프트웨어 공학에서 사용자와 소프트웨어 시스템 간의 상호작용을 디자인하는 과정으로 사용자가 시스템과 소통하는 방식을 결정하고 설계한다. 사용자 인터페이스는 시스템의 기능을 사용자가 이해하고 조작할 수 있도록 돕는 중요한 요소이며 사용자 만족을 전제로 한다. 이에 사용자 인터페이스에 대한 평가 요소가 중요하며 특히 배우기 쉬워야 하고 반응속도가 좋고 사용 중 오류의 빈도가 낮아야 하며 사용자를 만족시키고 사용법을 계속 유지해야 하는 점이 강조된다. 이를 모두 만족시키는 것이 이상적이기는 하나 중요한 사항을 선택적으로 충족시키는 경우도 많다. 이에 사용자 요구사항에 대한 우선순위를 고려하여 높은 우선순위부터 사용자 만족을 충족시키는 형태로 개발해야 한다. 이에 사용자 인터페이스 설계는 다음과 같은 목표를 갖는다.

• 사용자 친화성: 인터페이스는 사용자가 직관적으로 이해하고 사용할 수 있도록 설계되어야 하며 사용자가 복잡한 기능을 쉽게 찾고 사용할 수 있도록 지원
• 효율성: 인터페이스는 사용자가 작업을 빠르게 수행하고 목표를 달성해야 하며 불필요한 클릭이나 탐색을 최소화하여 작업의 효율성 보장
• 일관성: 인터페이스 요소들은 일관된 디자인과 동작을 가져야 하며 사용자가 유사한 기능을 다양한 부분에서 일관되게 경험할 수 있도록 작업 
• 피드백과 가시성: 사용자의 작업에 대한 적절한 피드백과 시각적인 표시를 제공하여 사용자가 자신의 작업을 추적하고 이해할 수 있도록 작업
• 유연성: 다양한 사용자 요구와 환경을 고려하여 다양한 장치와 환경에서 작동할 수 있는 인터페이스 고려

좋은 사용자 인터페이스 설계는 소프트웨어 제품의 성공과 사용자 만족도에 큰 영향을 미치며 사용자들의 요구와 행동을 고려하여 개발되어야 하는데 보통은 다음과 같은 단계로 진행된다.

• 요구사항 분석
  • 사용자의 요구사항과 기대를 이해하고 문서화
  • 사용자 그룹을 식별하고, 사용자의 특성, 선호도, 작업 환경 등 파악
  • 시스템의 목적과 기능, 사용자의 목표 정의
• 설계 및 기획
  • 사용자 경험(UX)을 중심으로 설계
  • 인터페이스의 레이아웃, 구조, 흐름 계획
  • 기능적 요구사항을 각각의 화면 또는 모듈 매핑
  • 정보 구조를 설계하고, 사용자가 쉽게 찾아서 사용할 수 있도록 계획

• 프로토타이핑
  • 초기 디자인 아이디어를 실제로 시뮬레이션하는 프로토타입 개발
  • 프로토타입을 사용하여 사용자의 피드백을 수집하고, 문제점이나 개선 사항 확인
  • 프로토타입을 통해 디자인과 기능을 검증하며, 수정과 보완 진행

• 디자인
  • 프로토타입을 기반으로 시각적인 디자인 수행
  • 색상, 아이콘, 글꼴 등을 선택하여 사용자가 시각적으로 쉽게 인터페이스를 이해할 수 있도록 가이드
  • 일관성 있는 디자인 가이드라인을 따르면서 사용자가 헷갈리지 않도록 지침제시

• 개발
  • 디자인된 인터페이스를 실제 코드 구현
    사용자 인터페이스 요소들을 프로그래밍 언어와 기술을 사용하여 구현

• 테스트
  • 인터페이스의 기능, 사용성, 성능 테스트
  • 버그, 오작동, 일관성 문제 등을 식별하고 수정
  • 다양한 시나리오와 테스트 케이스를 사용하여 인터페이스 검증

• 사용자 피드백 수집
  • 완성된 인터페이스를 실제 사용자들에게 제공하고 피드백 수집
  • 사용자의 의견을 수렴하여 인터페이스를 개선 보완

• 배포 및 유지보수
  • 최종적으로 개발된 사용자 인터페이스 배포
  • 사용자들의 피드백을 기반으로 지속해서 개선과 보완 작업 수행

소프트웨어 공학에서 구조적 설계는 소프트웨어 시스템을 개발할 때 전체 시스템의 구조와 구성 요소 간의 상호작용을 계획하고 설계하는 단계이다. 이는 소프트웨어 개발 프로세스의 중요한 부분으로 시스템의 복잡성을 다루며 유지보수할 수 있고 확장할 수 있는 소프트웨어 시스템을 만들기 위한 첫 번째 큰 단계 중 하나다. 이러한 구조적 설계는 앞서와 같이 모듈화와 추상화, 모듈 간 인터페이스 설계, 데이터 구조 설계, 제어구조 설계, 자료구조 설계 및 모듈의 응집도와 결합도 등으로 구성되어 있다. 특히 구조적 프로그래밍을 통해 GOTO 문을 최소화하고 대신 조건문과 반복문 등을 사용하여 프로그램 흐름을 명확하게 구조화한다. 이는 코드의 가독성과 디버깅 효율을 높이는 좋은 방법이다. 또한 일반적인 소프트웨어 설계 문제에 대한 해결책으로 사용되는 디자인 패턴을 활용하여 설계의 일관성과 재사용성을 향상한다.

구조적 설계는 소프트웨어의 크기와 복잡성을 관리하고 효율적인 개발 및 유지보수를 가능하게 해주는 중요 단계다. 이를 통해 개발자는 요구사항을 충족하면서도 확장 가능하고 품질 좋은 소프트웨어 시스템을 개발할 수 있다.

구조적 설계

구조적 분석은 설계 결과를 구조도로 나타낸다. 구조도는 시스템의 모든 모듈을 사각형의 박스로 표현하며 모듈의 호출 관계를 화살표로 나타내는 계층적 트리 형식의 표이다. 결국 소프트웨어 구조도는 시스템을 어떤 모듈들로 나누었는가를 명시적으로 나타내며 모듈들의 계층구조와 모듈 간 입출력, 인터페이스, 기능을 나타내는 이름들을 보여준다. 이러한 시스템 구조는 전체적으로 치우침 없는 균형을 이뤄야 한다. 그렇지 못한 경우 처리에 병목현상이 발생한다. 균형은 구조도의 폭과 깊이, 입출력 또는 처리 편중, 영향 범위 등에 의해서 결정된다. 시스템 구조도가 불균형인 경우 모듈의 역할이나 규모를 다시 나누어 균형을 이루도록 해야 한다.

구조의 깊이는 시스템 구조도의 레벨 수다. 깊이는 모듈 사이에서 호출하고 반환하는 과정이 길게 이어진다는 뜻이다. 따라서 깊이가 깊어지면 최하위 모듈까지 통신에 대한 부하가 늘어난다. 또한 구조의 넓이는 상위 모듈이 호출하는 모듈의 개수이다. 이를 보통 Fan-out이라 하며 한 모듈에서 호출하는 하위 모듈이 너무 많으면 호출하는 모듈이 제어할 때 병목 현상이 생길 수 있다. 제어의 범위를 너무 크지 않게 하는 것이 운용의 묘를 살리는 것이며 이 또한 매직넘버 7 내외를 유지하는 것이 좋고 이것이 Fan-out 수다. 여기서 호출하는 모듈수를 줄이려면 중간층의 모듈을 몇 개 두어 중간 모듈이 하위 모듈을 호출하도록 한다. 또한 하위 모듈 중 그룹화할 수 있는 모듈이 있거나 다른 모듈 등이 있다면 이를 분리한다.

구조적 설계는 분석 단계에서 생성된 자료 흐름도를 활용하여 소프트웨어 구조를 추출한다. 이에 두 가지 방법으로서 변환분석과 처리분석으로 구조를 추출한다. 

• 변환분석(Transformation Analysis): 소프트웨어 시스템 내 데이터 변환과 이동을 분석하는 과정으로 시스템 모듈 간 어떻게 데이터가 전달되고 가공되는지를 파악하여 시스템의 데이터 흐름을 이해한다. 이를 통해 시스템의 기능과 동작을 정확하게 파악하고 데이터 변환 과정에서 발생할 수 있는 오류나 문제를 사전에 예측하고 방지할 수 있다. 
  • 데이터 흐름 다이어그램(DFD) 작성: 시스템 내의 데이터 흐름을 그래픽으로 표현하는 도구인 데이터 흐름 다이어그램을 작성한다. 다이어그램은 프로세스, 데이터 저장소, 데이터 흐름 등을 나타내어 시스템의 데이터 흐름을 시각화한다.
  • 프로세스 식별과 정의: 시스템 내의 각각의 프로세스(기능 또는 서비스)를 식별하고, 그들이 어떤 데이터를 입력으로 받고 어떤 데이터를 출력으로 생성하는지를 정의합니다.
  • 데이터 변환 및 가공 분석: 각 프로세스 내에서 데이터가 어떻게 변환되고 가공되는지를 분석합니다. 데이터의 가공 단계에서 발생할 수 있는 오류나 일관성 문제를 식별하고 이에 대한 대비책을 마련합니다.
  • 데이터 저장소 식별과 정의: 데이터 흐름 중간에 위치하는 데이터 저장소(파일, 데이터베이스 등)를 식별하고, 이들이 어떤 데이터를 저장하고 어떤 프로세스에 의해 엑세스되는지를 정의합니다.

• 처리분석(Transaction Analysis): 소프트웨어 시스템 내에서 발생하는 트랜잭션을 분석하는 과정으로 시스템 사용자와 시스템 간의 상호작용을 이해하고 각각의 트랜잭션이 어떤 데이터와 기능을 요구하며 어떤 결과를 반환하는지를 파악한다. 이로써 시스템의 기능 요구사항을 정확히 파악하고 시스템의 응답 시간과 성능을 평가할 수 있다.
  • 트랜잭션 식별과 정의: 시스템 사용자의 작업 또는 요청을 트랜잭션으로 식별하고 각 트랜잭션이 어떤 데이터와 기능을 요구하는지 정의
  • 트랜잭션의 처리 흐름 분석: 각 트랜잭션이 어떤 프로세스나 모듈을 통해 처리되는지를 분석하며 트랜잭션의 처리 흐름을 파악하여 성능 병목 현상이나 오류 발생 가능성을 예측하고 대비책을 마련
  • 트랜잭션의 성능 분석: 각 트랜잭션의 응답 시간, 처리량 등의 성능을 분석하여 사용자 요구사항을 충족시킬 수 있는지 평가

소프트웨어 구조

흔히 스타일이라고 하면 설계와 시공을 위한 큰 밑그림을 그리는데 여기서 일관된 모양과 조화를 뜻한다. 이 스타일을 소프트웨어 구조에서도 사용할 수 있다. 소프트웨어 시스템이 복잡해지면서 시스템의 구조 문제는 더욱 중요해졌는데 왜냐면 일단 개발이 시작되면 이후 잘못된 부분을 바로잡기가 쉬지 않기 때문이다. 이런 문제의 중요성을 인식하여 소프트웨어 구조 개념이 나타났다. 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류처리 방침, 서브 시스템 간 통신 프로토콜을 포함한다. 이에 몇 가지 주요 스타일이 무엇이 있는지 살펴볼 필요가 있다.

• 저장소 (Repository) 구조: 소스 코드, 문서, 데이터 등의 자원을 중앙 집중화하여 관리하는 구조로 팀원들은 동시에 작업하거나 버전을 관리하며 변경 사항을 추적할 수 있다. 버전 관리 시스템(VCS)인 Git과 같은 도구가 이 구조의 핵심 역할을 수행하며 이를 통해 협업과 코드 품질을 개선하며 변경 내역을 추적하여 문제를 해결하는 데 도움을 준다.
• MVC (Model-View-Controller) 구조: 소프트웨어를 세 가지 주요 컴포넌트로 분리하여 구조화하는 패턴으로 코드의 재사용성, 유지보수성 및 확장성을 향상하며 시스템의 구성 요소 간의 결합 도를 낮추는 데 도움을 준다. 
  • Model: 데이터와 비즈니스 로직을 관리한다. 데이터의 상태와 조작 방법을 정의하고 시스템의 핵심 기능을 담당한다.
  • View: 데이터를 시각적으로 표현하는 역할을 한다. 데이터를 사용자에게 표시하거나 입력을 받을 수 있는 인터페이스를 제공한다.
  • Controller: 사용자의 입력을 처리하고 Model과 View 사이의 상호 작용을 조정한다. 사용자 요청을 해석하고 적절한 Model 업데이트 및 View 업데이트를 수행한다.
• Client/Server 구조: 소프트웨어 시스템을 두 부분으로 분할하는 구조로 클라이언트는 사용자 인터페이스와 관련된 작업을 수행하고 서버는 데이터 처리 및 비즈니스 로직과 같은 작업을 수행한다. 클라이언트는 서버에 요청을 보내고 서버는 해당 요청을 처리하여 결과를 반환한다. 이 구조는 분산 처리 및 확장성을 가능하게 하며 다양한 플랫폼과 기기 간의 상호작용을 지원하는 가장 기초적인 구조이다.
• 계층 (Layered) 구조: 시스템을 여러 계층으로 나누어 각 계층이 특정 기능을 수행하도록 하는 구조로 각 계층은 자신 바로 아래 계층과 상호작용하며 상위 계층은 하위 계층을 직접적으로 몰라도 된다. 이 구조는 코드의 모듈화와 재사용을 촉진하며 시스템의 유지보수 및 확장성을 개선하는 데 도움을 준다.
• 파이프-필터 (Pipe-Filter) 구조: 데이터 처리를 여러 단계로 나누어 각 단계를 필터로 생각하고 각 단계 간 데이터를 파이프로 연결하여 처리하는 구조로 각 필터는 특정 작업을 수행하며 데이터를 받아 처리한 후 결과를 다음 필터로 전달한다. 이 구조는 시스템의 기능을 모듈화하고 데이터 처리를 효율적으로 관리하는 데 도움을 준다.

무엇을 개발할 것인가에 대한 요구분석이 끝나면 다음 단계로서 소프트웨어 내부 구조와 자료구조를 설계해야 하는 일이 있다. 소프트웨어는 그 품질을 인정받기 위해서는 요구분석 산출물에 기술된 기능을 잘 수행하도록 설계되어야 하는 중요성을 가지고 있다. 소프트웨어 구조는 소프트웨어 시스템의 골격과 조직이며 이를 설계하는 것은 모든 구성요소인 모듈들을 정의하고 모듈 사이 인터페이스를 정하는 것이다. 이것들이 제대로 설계되지 않는다면 이후 개발, 테스트 및 유지보수 등에 있어서 큰 어려움이 뒤따른다고 봐야 한다. 소프트웨어 설계 작업의 결과는 여러 원리를 토대로 다양한 결과물을 만들어낸다. 구조와 알고리즘, 프로그래밍, 데이터베이스 등 요구분석서와 설계서 사이 설계단계는 구현으로 가기 위한 징검다리이다.

이러한 설계는 창조적인 작업이다. 하지만 원리적 접근이나 체계적 개념이 없는 것은 아니다. 다른 창작 작업도 일정한 틀과 원리가 적용된다. 소프트웨어를 설계하는 과정에서도 설계 기법과 많은 도구가 쓰인다. 특정한 설계기법의 선택이 품질 좋은 소프트웨어를 만드는 데 필수 요건은 아니다. 다만 설계 기법을 잘 적용하면 소프트웨어 설계는 더 개선된다. 

설계

앞선 요구분석서는 시스템 문제를 해결하기 위한 기술서이다. 설계는 분석서에 기술된 문제를 해결 방안으로 변경하는 작업이다. 분석과 설계. 완성된 설계는 요구를 만족시키는 특정한 솔루션이다. 문제를 정의하기 위해서 요구명세서를 작성하고 문제에 대한 솔루션을 만드는 설계 방안은 이에 제한받지 않는다. 즉 설계는 여러 가지 대안 중 여러 가지 제약 조건을 잘 만족시킬만한 하나의 솔루션을 선택하는 것이다. 이런 설계는 사용자와 개발자를 동시에 만족시켜야 하는 책임과 의무가 있다. 사용자는 설계를 보고 시스템이 어떤 기능을 하는지 이해하고 개발자는 시스템이 어떻게 동작하는지 이해하여야 한다. 

일정 규모 이상의 소프트웨어 설계는 다음과 같은 분류를 해볼 수 있다.

• 소프트웨어 구조설계: 전체 시스템을 구성하는 서브 시스템과 관계를 파악
• 인터페이스 설계: 서브 시스템 사이 인터페이스 설계 및 정의
• 자료저장소 설계: 파일, 데이터베이스 설계
• 프로그램 설계: 시스템 컴포넌트인 모듈, 알고리즘 설계
• 사용자 인터페이스 설계: 메뉴, 화면, 입출력 양식 등 설계

설계 원리

소프트웨어 개발 방법의 근간인 개념과 원리로서 방법은 상황에 맞는 것을 적절하게 적용해야 한다. 구조적 설계는 구조적 분석의 ‘형식은 기능을 따른다’는 원리를 일관되게 적용한다. 자료흐름도에서 프로세스들의 패턴은 시스템의 구조를 결정한다. 여기서 분할과 정복이 사용되고 반복한다. 이러한 설계의 중심이 되는 원리들이 몇 가지가 있다.

✔️ 추상화(Abstraction)

추상화는 자세한 사항보다는 근본적 본질에 집중하는 것을 말한다. 다시 말해 자세한 사항은 처음부터 다루지 않고 전체적이고 포괄적인 개념부터 차례대로 세세하게 세분화함으로써 구체화해 나가는 것이다. 이러한 추상화는 어떤 결과가 얻어져야 하느냐는 명세화 관점을 어떻게 달성할 것인가라는 구현관점과는 별개로 하여 설계 작업에 좀 더 집중할 수 있게 만든다. 소프트웨어 설계에서의 대표적 추상화는 기능 추상화, 자료 추상화 및 제어 추상화가 있다.

• 기능 추상화: 입력자료를 출력자료로 변환하는 과정의 추상화
• 자료 추상화: 자료와 자료에 적용할 수 있는 기능을 함께 정의하여 자료 객체를 구성
• 제어추상화: 프로그램의 제어 흐름을 추상화하여 코드의 모듈화와 구조화를 촉진 

✔️ 정보은닉(Information Hiding)

설계된 각 모듈은 자세한 처리 내용이 시스템의 다른 부분으로부터 감춰져야 한다는 것이 정보은닉이다. 즉 모듈 안의 내용을 보여주지 않고 잘 정의된 인터페이스를 통해 메시지를 전달하는 개념인데 설계상 모든 결정 사항들이 모듈 안에 감춰져서 다른 모듈이 접근하거나 변경하지 못하도록 하는 것이다. 이는 모듈화의 기준으로도 사용이 가능하며 이에 따른 모듈의 구현은 독립적이며 설계 과정에서 하나의 모듈이 변경되어도 다른 모듈 설계에는 영향을 주지 않는 장점이 있으며 모듈의 이해도도 높일 수 있다.

✔️ 단계적 분해

문제를 상위 개념부터 더 구체적인 단계로 하향식 분할하는 개념으로 보통 4가지 과정을 거친다. 먼저 문제를 기본 단위로 나누고 이를 독립된 문제로 구별한다. 이후 구분된 문제의 자세한 내용은 가능한 뒤로 미뤄두고 구체화 작업이 계속 점증적으로 일어난다는 것을 보여준다. 이러한 단계적 분해는 소프트웨어를 이루는 모듈에 대한 구체적 설계를 수행할 때 주로 사용된다. 단계적 분해는 문제를 해결할 만한 작은 문제로 나누고 구체화의 정도를 작게 하여 점증적으로 문제를 다루어 나가는 것이다. 구체적인 설계 결정을 뒤로 미룰 수 있고 조금씩 변경되므로 일관성을 유지 할 수 있는 장점이 있다.

✔️ 모듈화

소프트웨어 구조를 이루는 기본적인 블록이 모듈이다. 이 모듈이 구체적으로 어떤 단위를 말하는 것인가에 대해서는 일치되는 정의는 딱히 없다. 그러나 여러 개의 독립적인 프로그램으로 구성된 복합 시스템의 경우에는 시스템 설계 단계에서 모듈은 기능적으로 관련된 여러 개의 프로그램, 함수, 부프로그램의 묶음이기도 하고 추상화된 자료나 병행 처리 프로세스도 모듈로 불린다. 이 모듈의 공통 개념은 수행 가능 명령어, 자료 구조 또는 다른 모듈을 포함하고 있는 독립 단위이다. 모듈은 이름을 가지고 있으며 독립적으로 컴파일이 되고 다른 모듈을 사용할 수도 있으며 다른 프로그램에서 사용될 수도 있다. 

모듈의 크기는 다양하다. 일반적으로 쉽게 이해될 수 있을 정도로 작아야 한다는 데 동의한다. 이런 모듈은 모듈을 이루는 각 요소가 공통의 목적을 달성하기 위해 얼마나 관련이 있는가를 나타내는 응집력을 갖는다. 즉, 응집력은 모듈 안의 요소들이 서로 관련된 정도를 말하며 모듈 설계의 목표는 강력한 응집력을 갖는 모듈을 만드는 것이다. 이러한 모듈 안에서 응집력의 정도를 마이어스는 일곱 가지 단계로 구분했는데 응집력이 강한 것부터 약한 것까지 ‘기능적 – 순차적 – 교환적 – 절차적 – 시간적 – 논리적 – 우연적’ 으로 나열할 수 있다.

모듈의 응집도와 같이 이야기되는 것이 결합도 이다. 결합도는 모듈 간 상호 의존하는 정도를 말하는데 모듈은 하나의 블랙박스로 다른 모듈과의 독립성이 높아야 한다. 이런 독립적 모듈이 되기 위해서는 다른 모듈과의 결합도가 약해야 하며 의존하는 모듈 또한 적어야 한다. 모듈 사이 의존하는 정도는 결합도가 강한 것부터 약한 것까지 ‘내용 – 공통 – 제어 – 스탬프 – 자료’ 결합으로 나열할 수 있다.