프로그래밍1 (소프트웨어 공학)

프로그래밍 – 구현

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

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

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



프로그래밍 원리

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

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

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

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

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

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

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



코딩 스타일

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

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

객체지향 분석설계2 (소프트웨어 공학)



UML

무엇이든지 복잡한 생각이나 아이디어를 간결하고 정확하게 표현하려면 여러 방법이 있지만 이를 통해서 의사소통의 오류를 줄이는 것은 소프트웨어 개발 프로젝트에선 필수사항이다. 정확한 의사소통은 먼저 표현하는 의미를 잘 정의해야 하고 대상을 표현하는 데 적합하고 모든 이해당사자가 이해하기 쉬워야 한다. 그래서 표준이나 규격이 필요한 것이고 이것이 객체지향에서는 UML(Unified Modeling Language)을 사용하는 것이다.

UML은 OMT(Object Modeling Technique)와 Booch, OOSE(Obect Oriented Software Engineering)의 통합으로 만들어진 표현 방법으로 객체지향 분석설계기법으로 매우 유용하고 시스템 개발에선 크게 기능적 모형, 객체 모형 및 동적 모형으로 구성된다. 이 중 중요한 다이어그램이 5가지 있는데 Use Case, Class, Sequence, State, Activity가 그것이다.

  • Use Case Diagram
    : 시스템의 기능적인 측면을 모델링하는 데 사용되고 주로 사용자와 시스템 간의 상호작용을 보여준다. 액터(Actor)는 시스템과 상호작용하는 주체(사용자 또는 외부 시스템)를 나타내며 유스케이스(Use Case)는 시스템이 수행하는 기능을 나타낸다.
  • Class Diagram
    : 시스템의 정적인 구조를 모델링하는 데 사용되며 클래스, 인터페이스, 연관 관계, 상속 관계 등을 시각적으로 표현한다. 클래스 다이어그램은 소프트웨어의 구조를 이해하고 객체 간의 관계를 잘 파악할 수 있다.
  • Sequence Diagram
    : 시스템의 동적인 동작을 시간의 흐름에 따라 나타내며 객체 간의 메시지 교환을 보여주고 객체 간의 상호작용과 시간 순서를 시각화하여 효과적으로 커뮤니케이션 흐름을 이해할 수 있게 한다.
  • State Diagram
    : 객체의 생명주기와 상태 변화를 모델링하는 데 사용되며 주로 객체의 상태가 어떻게 변화하고 이벤트에 응답하는지를 시각적으로 보여준다. 상태 다이어그램은 복잡한 객체의 동작을 이해하는 데 필요하다.
  • Activity Diagram
    : 비즈니스 프로세스나 시스템의 작업 흐름을 시각화하는 데 사용된다. 활동은 작업 단계를 나타내며 화살표로 연결된 동작의 흐름을 보여주고 제어 흐름, 의사 결정, 병렬 처리 등을 표현하여 프로세스를 이해하고 분석하는 데 활용된다.

 

설계/구현 매핑

객체지향 모델링에는 크게 네 가지 관계, 연관, 전체/부분, 상속, 사용 관계가 그것인데 이들의 각각의 관계는 클래스 또는 객체가 관계를 맺고 있는 특별한 유형을 의미한다. 이에 각각 살펴보면 다음과 같다.

  • 연관관계 (Association)
    : 클래스 간의 관계이며 어떤 클래스의 객체가 다른 클래스의 객체와 상호작용하는 것을 나타낸다. 연관은 일반적으로 양방향 또는 단방향으로 설정될 수 있고 연관에는 다중성(multiplicity)과 역할(role)이 포함될 수 있다. 다중성은 연관에 참여하는 객체의 수를 나타내며, 역할은 해당 연관에서 객체가 가지는 역할을 의미한다.
  • 전체/부분관계 (Composition/Aggregation)
    : 한 객체가 다른 객체의 부분이 되는 관계로 Composition은 전체와 부분 사이에 강한 소유관계가 있는 경우를 의미하며 전체 객체가 파괴되면 부분 객체도 함께 파괴된다. Aggregation은 더 느슨한 관계로 전체 객체와 부분 객체는 독립적으로 존재할 수 있다. 전체/부분 관계는 다이어그램 상에서 다이아몬드 형태의 다이어그램 요소로 표현한다.
  • 상속 관계 (Inheritance)
    : 상속은 클래스 간의 계층적인 관계를 나타내며 한 클래스가 다른 클래스로부터 속성과 동작을 물려받는 것을 의미한다. 부모 클래스(상위 클래스 또는 기본 클래스)의 특성과 동작을 자식 클래스(하위 클래스 또는 파생 클래스)가 재사용할 수 있도록 하고 이를 통해 코드 재사용성과 확장성을 증가시킬 수 있다.
  • 사용 관계 (Dependency)
    : 한 클래스가 다른 클래스의 기능을 사용하는 관계로서 이 관계에서는 클래스 간에 직접적인 연결이 없으며 주로 메소드의 매개변수나 반환 값 등을 통해 나타난다. 클래스가 다른 클래스의 인터페이스를 사용하여 기능을 구현하는 경우 사용 관계가 형성된다.



시스템/객체 설계

객체지향 설계는 소프트웨어 시스템을 개발하기 위한 계획과 구조를 만드는 과정으로 시스템 설계와 객체 설계는 객체지향 개발의 두 단계로서 각각 전체적인 아키텍처와 개별 객체의 세부 사항을 다룬다. 이 둘은 서로 밀접하게 연관되어 있으며 시스템 설계 단계에서 결정된 아키텍처와 모듈화는 객체 설계 단계에서 각 객체의 역할과 협력을 결정하는 데 사용된다. 따라서 객체지향 설계는 시스템의 기능, 구조, 동작을 종합적으로 고려하여 효율적이고 확장 가능한 소프트웨어 시스템을 개발하는 데 필요하다.

  • 시스템 설계
    : 소프트웨어 시스템 전체의 아키텍처와 구조를 정의하는 단계로 다양한 컴포넌트 간의 관계, 모듈화, 시스템의 구조적인 레이어 등을 결정한다.

    • 시스템 아키텍처 설계: 전체 시스템 아키텍처, 레이어 구조, 서브 시스템 등을 정의하며 시스템의 큰 틀을 잡아내고 시스템의 기능적 요구사항을 충족시키기 위한 아키텍처를 선택한다.
    • 모듈 설계: 시스템을 여러 개별 모듈로 분리하고 각 모듈의 역할과 책임을 정의한다. 이 모듈 간의 인터페이스와 상호작용 방법을 결정하여 시스템 전체의 유기적인 통합을 보장한다.
    • 데이터베이스 설계: 시스템에서 사용되는 데이터의 구조와 관계를 정의하며 데이터의 저장, 검색, 관리 등을 위한 데이터베이스 구조와 스키마를 설계한다.
  • 객체 설계
    : 객체 설계는 시스템 설계의 결과물을 기반으로 각각의 객체와 클래스의 구조, 속성, 메소드 등을 정의하는 단계로서 시스템 설계에서 정의한 모듈을 실제로 구현 가능한 형태로 변환한다.

    • 클래스 정의: 클래스의 속성과 메소드를 정의하고 클래스의 책임과 역할을 명확히 한다. 클래스의 인터페이스와 구현을 결정하여 다른 클래스와의 협력 관계를 구성한다.
    • 객체 간의 관계: 연관, 전체 부분, 상속, 사용 관계 등을 통해 객체 간의 관계를 설정하며 이를 통해 객체들의 협력과 상호작용을 정의한다.
    • 동적 동작 정의: 시퀀스 다이어그램과 같은 다이어그램을 사용하여 객체 간의 상호작용을 시각화하고 메소드 호출 순서와 결과를 정의한다.

 

디자인 패턴

객체지향 설계작업은 방법론이 있지만 쉬운 작업은 아니다. 이를 위해선 많은 경험과 인사이트가 필요하다. 이에 객체 설계의 경험을 토대로 한 디자인패턴 개념이 등장한다. 디자인패턴은 프로그램 개발에 자주 등장하는 문제를 기술하고 같은 작업을 반복하여 설계하지 않고 여러 번 반복하여 사용할 수 있는 문제에 대한 솔루션을 기술한 것이다. 다만 패턴에서 기술된 솔루션이 특정한 구현을 나타낸 것은 아니며 여러 상황에서 적용될 수 있는 템플릿 성격이라고 보는 것이 맞다. 그래서 문제에 대한 설계를 추상적으로 표현하여 문제를 해결하려는 요소들을 일반화하고 잘 정리한 것이다.

이러한 디자인패턴은 다음과 같은 요소로 구성된다.

  • 패턴 이름/구분: 패턴을 부를 때 사용하는 이름과 패턴 유형
  • 문제/배경: 패턴이 사용되는 분야, 배경 및 해결하려는 문제
  • 솔루션: 패턴을 이루는 요소들, 관계, 협동 과정
  • 사례: 적용 사례
  • 결과: 패턴사용 시 얻게 되는 이점이나 영향
  • 샘플 코드: 패턴이 적용된 원시 코드

패턴을 분류하는 기준은 여러 가지나 보통 23개의 세 가지 유형을 가진 Gamma 분류체계가 일반적인데 아래 간략히 소개한다.

  • 생성 패턴: 객체의 생성 과정을 추상화하고 객체 생성과 조합을 통해 시스템을 유연하고 확장 가능하게 만드는 패턴들이다.
    • Singleton 패턴: 클래스의 인스턴스가 하나만 생성되도록 보장
    • Factory Method 패턴: 객체 생성을 서브 클래스로 분리하여 확장성을 갖춤
    • Abstract Factory 패턴: 관련된 객체들의 팩토리들을 추상화하여 함께 사용
    • Builder 패턴: 복잡한 객체의 생성 과정을 분리하여 객체 생성을 간단하게 구성
    • Prototype 패턴: 객체를 복사하여 새로운 객체를 생성하는 사용
  • 구조 패턴: 클래스나 객체를 조합하여 더 큰 구조를 만들거나, 인터페이스를 결합하여 새로운 기능을 제공하는 패턴들이다. 
    • Adapter 패턴: 서로 호환되지 않는 인터페이스를 함께 동작하도록 변환
    • Bridge 패턴: 추상화와 구현을 분리하여 두 개의 독립적인 클래스 계층 구성
    • Composite 패턴: 개별 객체와 복합 객체를 동일한 방식으로 다루도록 정리
    • Decorator 패턴: 객체에 추가적인 기능을 동적으로 추가
    • Facade 패턴: 복잡한 하위 시스템을 단순화된 인터페이스로 노출
  • 행동 패턴: 객체 간의 상호작용과 책임 분배를 중심으로 다루는 패턴들이다. 
    • Strategy 패턴: 알고리즘을 정의하고 각각을 캡슐화하여 교환 가능 제공
    • Observer 패턴: 한 객체의 상태 변경이 다른 객체에 통지
    • Command 패턴: 요청을 객체의 형태로 캡슐화하여 나중에 실행하거나 취소 가능
    • Chain of Responsibility 패턴: 요청을 처리하는 객체들의 연결을 만들어 책임 위임
    • State 패턴: 객체의 상태에 따라 행동을 변경 가능



객체지향 분석설계1 (소프트웨어 공학)

소프트웨어 개발에서 객체지향 프로그램은 독립 객체들의 묶음이다. 따라 분석과 설계 단계에도 프로그램 모듈 단위인 객체의 정적인 구조와 동적인 변화를 미리 고려해야 한다. 분석 단계에서는 사용자 관점에서 여러 사용 사례를 찾아보고 클래스들의 정적인 관계와 객체들의 인터랙션을 찾아낸다. 설계 단계에선 클래스들의 묶음으로 시스템 구조를 정의하고 클래스 내부를 설계한다. 이러한 분석과 설계과정은 순차적 과정이 아니다. 이는 반복과 점증적 개발 프로세스를 사용하고 있으며 이를 통해 반복적 사이클을 거치면서 점차 확장되고 완성되어 가는 것이다. 

객체지향 분석과 설계과정은 누구나 공통으로 사용하는 프로세스는 없다. 물론 여러 가지 제안 프로세스들이 있으나 모두 상이하다. 이에 모델링은 매우 중요하게 대두된다. 모델은 프로젝트에 참여하는 모든 사람이 목표로 하는 소프트웨어를 잘 이해할 수 있게 하며 이를 사용함으로써 시간과 비용을 절약할 수 있다. 객체지향 분석과 설계에서는 보통 3가지 모델을 사용한다. 이는 기능 모델(Use case Diagram), 객체모델(Class Diagram), 동적모델(State Diagram/Sequence Diagram)이 그것이다.

 





 

Use Case

객체지향을 통해 시스템 개발 시 가장 먼저 할 일은 요구사항을 추출하는 것으로 여기에 Use Case가 사용된다. Use Case는 시스템이 수행할 것으로 기대되는 기능을 말하는데 이는 사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용하는 다이얼로그를 모델링한 것이다. 모든 Use Case는 외부 엔티티들이 시스템과 어떻게 상호작용하는지 가능한 시나리오를 나타내는 것으로 이를 모으면 전체 시스템의 완전한 모습을 보여주는 것이다. 그래서 Use Case는 사용자나 시스템 설계자, 테스터 및 개발자 간 의사소통에 매우 유용하다.

이러한 Use Case는 문제 정의에서 사용사례로 구성된 시스템 명세로 매핑하는 작업이다. Use Case를 작성하고 관계를 찾는 것은 시스템의 요구사항을 명확하게 정의하고 팀 간 의사소통을 원활하게 하며 개발 과정을 체계화하는 것으로 이를 통해 시스템의 기능을 완전하게 이해하고 효과적으로 구현할 수 있다. 이에 대한 작업 과정은 다음과 같다.

  • 액터(Actor) 식별
    • 액터는 시스템과 상호작용하는 외부 역할이나 개체로서 이해관계자, 사용자, 시스템 등이 액터가 될 수 있음
    • 액터를 식별하는 것은 해당 시스템이 상호작용할 주체와 대상을 이해하는 것
  • 시나리오(Scenario) 식별
    • 시나리오는 특정 액터와 시스템 간의 상호작용 과정을 설명하며 시스템의 특정 기능 또는 작업에 대한 흐름 표현
    • 액터마다 여러 시나리오가 있을 수 있음
  • Use Case 작성
    • Use Case는 특정한 기능 또는 작업에 대한 상세한 설명을 담은 문서로 각 Use Case에는 제목, 목적, 참여자(액터), 사전 조건, 후속 조건, 흐름(시나리오), 대안 흐름 등의 정보 포함
    • Use Case를 작성할 때는 해당 기능을 어떻게 사용자가 사용할지를 중심으로 작성
  • Use Case 간 관계 찾기
    • Use Case 간의 관계를 찾는 것은 시스템의 기능적인 흐름을 이해하고 조직화 도움
    • 주요한 두 가지 관계: 일반화 관계(Generalization)와 포함 관계(Inclusion)
      • 일반화 관계: 보다 일반적인 Use Case와 그에 따르는 구체적인 Use Case 간의 상속 관계
      • 포함 관계: 한 Use Case가 다른 Use Case의 일부 기능을 포함하는 관계

 






 

객체 모델링/동적 모델링

Use case를 작성하고 도메인 분석이 어느 정도 마무리되고 나면 객체를 찾고 관계를 정의하는 작업을 시작하게 된다. 이를 객체 모델링이라 부르며, 클래스를 발견하고 난 후 클래스들의 상호작용이나 클래스의 상태 변화 등 시스템 내부의 동작을 구축하는 것을 동적 모델링이라 부르며 UML에서는 Sequence diagram, State diagram, Activity diagram으로 작업한다. 이들은 시스템의 구조와 행동을 모두 고려하여 전체적인 시스템 설계를 돕는 역할을 한다.

  • 객체 모델링 (Object modeling)
    • 객체 모델링은 시스템의 정적인 측면, 즉 시스템 내 객체들의 구조와 관계에 중점
    • 주로 클래스 다이어그램(Class Diagram)과 객체 다이어그램(Object Diagram) 사용
    • 클래스 다이어그램은 시스템 내 클래스(객체의 템플릿)들과 그들 간의 관계를 보여주며 클래스의 속성과 메소드 포함
    • 객체 다이어그램은 특정 시점에서 객체들의 인스턴스와 그들 간의 관계 표현
    • 작업절차
      • 엔티티 클래스 찾기: 시스템의 주요 데이터를 나타내는 클래스로 데이터베이스의 테이블과 유사하며 시스템 내의 중요한 개념이나 사물을 표현
      • 경계 클래스 찾기: 시스템과 외부 환경 간의 상호작용을 처리하는 클래스로 사용자 인터페이스나 외부 시스템과의 통신 담당
      • 제어 클래스 찾기: 시스템의 비즈니스 로직을 처리하고 조정하는 클래스로 엔티티 클래스와 경계 클래스 간의 상호작용 관리
      • 연관관계 찾기: 클래스 간의 상호작용과 관계를 나타내며 엔티티 클래스 사이에 형성되고 방향, 다중성, 역할 등 포함
      • 속성찾기: 클래스나 객체가 가지는 특징이나 데이터를 나타내며 엔티티 클래스의 상태를 설명하는 정보로 사용
  • 동적 모델링 (Dynamic modeling)
    • 동적 모델링은 시스템의 행위나 상호작용을 중심으로 설계
    • 주로 시퀀스 다이어그램(Sequence Diagram)과 상태 다이어그램(State Diagram) 사용
    • 시퀀스 다이어그램은 객체 간의 상호작용 순서를 보여주며 메시지의 흐름을 시각적으로 표현
    • 상태 다이어그램은 객체의 생명주기와 상태 변화를 표현하여 객체의 동적인 행위를 이해하게 지원
    • 작업절차
      • Sequence diagram
        • 객체 간의 상호작용을 시간 순서에 따라 시각적으로 표현
        • 객체 간에 주고받는 메시지와 메시지의 순서를 보여주어 시스템 내부의 상호작용을 이해
        • 시스템의 시간적 흐름을 잘 보여주기 때문에 사용자 스토리나 시나리오를 분석하거나 설계 시 유용
      • State diagram
        • 객체의 생명주기와 상태 변화를 표현
        • 객체가 어떤 상태에서 다른 상태로 전이되는지와 전이가 어떤 조건에서 일어나는지 표현
        • 객체의 행위와 상태 변화를 시각적으로 이해하는 데 도움을 주고 특히 복잡한 객체의 동작을 추적하고 이해하는 데 유용
      • Activity diagram
        • 시스템 내에서 흐름 제어, 동작 및 상호작용을 시각적으로 표현
        • 프로세스나 작업의 흐름을 단계별로 표현하여 시스템의 동작을 더욱 자세히 설명
        • 주로 비즈니스 프로세스, 사용자 시나리오, 시스템 동작 등을 나타내는 데 사용

객체지향 (소프트웨어 공학)




소프트웨어 공학 분야에서 객체지향 기술은 오래전부터 여러 분야에서 연구가 되어 왔던 아이템이다. 특히 1990년대부터 소프트웨어 분야에서는 매우 중요한 기술로 다뤄지며 생산성에 초점을 맞춘 프로그래밍 분야에서는 이제는 빼놓을 수 없는 핵심기술이다. 이는 소프트웨어의 발전이 하드웨어를 따라가지 못한다는 ‘소프트웨어 위기’를 타개할 수 있는 방법으로서 이제는 개발 주류가 된 객체지향은 특수화되고 적절하게 변경이 되며 소프트웨어 부품을 보다 체계적으로 다시 사용할 수 있는 인프라가 되었다.

 

객체지향 특징

객체지향의 특징은 무엇보다도 절차적인 프로그램과의 차이점을 보면 명확해진다.

🚩 모형의 적합성
복잡해지는 문제를 잘 모델링하기 위해서는 부분적인 자세함도 필요하지만 적절하게 자세한 것을 생략할 수 있는 추상화도 가능하여야 한다. 이는 객체지향에서 정보은닉과 메시지 교환이라는 개념을 활용하여 작업이 분산되고 감춰진다. 함수의 집합으로 구성된 절차적인 프로그래밍과 달리 객체지향 프로그램은 내부가 감춰진 객체들의 상호작용으로 구성된다. 그래서 자료를 따로 가진 객체들이 필요할 때만 협력한다. 더불어 개념이나 실체를 이산적인 객체로 모델링하여 독립된 객체로서 구현시킨다.

🚩 재사용 용이
재사용이 쉽다. 객체는 열림 특성과 닫힘 특성을 모두 갖추고 있고 재사용 부품으로서 그 역할을 한다. 닫힘은 변하지 않는 부분은 손대지 않고 그대로 다시 사용하는 것을 말하며 열림은 그 반대로 이를 변경 또는 확장하여 사용할 수 있는 것이다. 이를 가능하게 하는 개념은 바로 상속과 다형성이다. 추상화 클래스를 정의하고 파라미터를 용도에 맞게 사용할 수도 있고 캡슐화된 클래스를 그대로 쓰면서 필요에 따라 확장도 가능한 것이다.

🚩 Time to market
소프트웨어의 효율성 외에도 품질이나 유지보수 용이성, 시장 출하 시점도 소프트웨어 설계에 있어 매우 주요한 설계 기준이다. 시장에 처음 출시된 제품이 나중에 나온 제품보다 기능이 떨어지더라도 시장을 선점하고 점유한 상태를 무시할 수 없기 때문이다. 객체지향은 재사용이 용이하고 재설계가 필요 없기 때문에 개발기간을 단축할 수 있고 필요시 원하는 시점에 맞춰 제품 출하를 가능하게끔 하는 기술이다.

🚩 설계와 프로그래밍 매핑
절차적 방법에 비해 설계단계에서 프로그래밍으로의 전환이 매우 순조롭다. 즉 쉽게 매핑될 수 있다는 것인데 프로그램의 기초 단위인 객체나 클래스 개념을 말하는 것이다. 물론 코딩 자체는 다소 어려울 수 있더라도 분석 설계 단계에서 부분적인 코딩이 자유로운 객체지향은 모델링 기초 개념이 동일하여 이 또한 개발기간을 단축할 수 있는 결과를 가져올 수 있다.

 




기본개념

🚩 객체(Object)
객체는 현실 세계의 개체나 개념을 소프트웨어적으로 모델링한 것이다. 즉 필요한 자료구조와 이에 수행되는 함수들을 가진 하나의 소프트웨어 모듈로 볼 수 있다. 이는 자료구조를 갖고 상태를 가진다는 것인데 데이터와 해당 데이터를 처리하는 메소드(함수)를 함께 포함한다. 예로, 자동차 객체는 브랜드, 모델, 속도 등의 데이터와 가속, 정지와 같은 동작을 수행하는 메소드로 구성된다. 결국 객체는 상태와 행위, 정체성을 갖는, 비슷한 객체의 구조와 행동이 공통 클래스로 선언된다.

🚩 클래스(Class)
클래스는 객체를 생성하기 위한 템플릿이며 객체의 구조와 행동을 정의한다. 즉 객체의 타입이 클래스이다. 클래스는 속성(변수)과 메소드(함수)로 구성되며 객체를 생성할 때 이러한 속성과 메소드가 해당 객체에 포함된다. 자동차 클래스는 자동차 객체들이 가져야 할 속성과 메소드를 정의하는 것이 그 예이며 클래스에 속하는 객체를 이 클래스의 인스턴스라고 한다. 이런 클래스를 정의하기 위해서는 클래스가 가지는 속성을 도출하여야 한다. 다시 말해 클래스는 객체들이 갖는 속성과 적용 연산을 정의하고 있는 템플릿이다.

🚩 캡슐화(Encapsulation)
캡슐화는 객체의 상태(속성)와 행동(메소드)을 하나의 단위로 묶는 것이다. 객체는 외부에서 직접 접근하는 것을 제한하고 객체의 내부 동작을 숨기는 것으로 정보은닉을 지원하는데 이를 통해 객체의 내부 구현 세부 사항을 감추고 외부에서는 필요한 인터페이스를 통해 상호 작용할 수 있다. 캡슐화는 설계나 분석 단계에서 주어진 문제를 간단히 처리할 수 있는 추상화의 수단이 된다.

🚩 상속(Inheritance)
상속은 클래스 간의 계층 구조를 만들어 기존 클래스의 속성과 메소드를 다른 클래스가 상속받아 재사용할 수 있게 해준다. 부모 클래스(상위 클래스 또는 기본 클래스)의 특징을 자식 클래스(하위 클래스 또는 파생 클래스)가 물려받아 확장하거나 수정할 수 있다. 이를 통해 코드 재사용성과 계층적 구조를 갖는 클래스들을 구성할 수 있다. 이런 상속은 슈퍼 클래스, 서브 클래스로 클래스를 세분화하며 객체가 갖는 특유의 속성들을 추가할 수 있다. 참고로 두 개 이상의 슈퍼 클래스에서 상속받는 것을 복수 상속이라 한다.

🚩 다형성(Polymorphism)
다형성은 같은 이름의 메소드를 다양한 객체에서 호출할 때 다른 동작을 수행하도록 하는 개념으로 여러 가지 형태를 가지고 있다는 말이다. 이는 상속과 연결되어 있으며, 자식 클래스는 부모 클래스의 메소드(특정한 클래스를 위해서 오퍼레이션을 구현한 것)를 오버 라이딩(재정의)하여 자신에 맞게 수정할 수 있다. 다형성을 통해 객체 간의 유연하고 일관된 상호작용을 가능하게 한다. 다형성은 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있다.

 




객체지향 프로세스

객체지향 프로세스의 단계들은 선형적인 순서로 진행되는 것이 아니라 실제 개발 과정에서는 반복되거나 중첩되는 경우가 많다. 이는 소프트웨어 개발의 복잡성을 다루기 위해 계획, 설계, 구현, 검증, 유지보수 등을 체계적으로 수행하여 효율적이고 유지보수가 가능한 소프트웨어를 만들기 위한 접근법으로 큰 틀에서는 일반적인 소프트웨어 개발 프로세스와 동일하다.

✔️ 요구사항 분석
프로젝트의 목적과 필요한 기능을 파악하고 문서화한다. 이 단계에서는 사용자와 고객의 요구사항을 파악하고 이를 객체와 클래스로 변환하여 소프트웨어의 주요 기능과 특성을 정의한다. 주요 과정으로는 요구추출 단계에서는 액터, 시나리오, 여러 사례들을 찾고 구체화하며 여러 사례 간의 관계를 바탕으로 비기능적 요구를 명확화한다. 이후 요구분석을 통해 분석모형을 위한 객체, 객체 간 모형화, 연관관계, 속성 등을 찾고 정리한다.

✔️ 시스템 설계
요구사항을 바탕으로 시스템의 구조와 아키텍처를 설계한다. 클래스와 객체의 관계, 데이터베이스 구조, 인터페이스 등을 정의하고 시스템의 전체적인 동작 방식을 계획한다. 즉 설계목표를 정의하고 서브 시스템을 파악하고 여러 저장소를 설계하며 이를 패키지 다이어그램으로 정리한다.

✔️ 클래스 설계
시스템 설계를 바탕으로 클래스와 객체의 세부 사항을 설계한다. 클래스의 속성과 메소드를 식별하고 클래스 간의 관계를 설정하며 적절한 상속 구조를 설계한다. 객체를 정의하고 부품의 선택과 최적화를 통해 설계를 진행하며 상세화된 클래스 다이어그램을 작성한다.

✔️ 구현 및 테스트
클래스 설계를 기반으로 실제 코드를 작성한다. 각 클래스의 메소드를 구현, 데이터를 처리하며 객체들을 생성하고 관리한다. 이 단계에서는 객체지향 프로그래밍 언어를 사용하여 클래스와 메소드를 코드로 표현한다. 그리고 작성한 코드를 검증하여 시스템이 요구사항을 충족하는지 확인한다. 단위 테스트, 통합 테스트, 시스템 테스트 등 다양한 수준의 테스트를 수행하여 버그를 찾고 수정한다.

✔️ 배포 및 유지보수
개발한 소프트웨어를 배포하고, 사용자가 실제로 사용하면서 발생하는 문제를 해결하고 기능을 추가 또는 개선한다. 유지보수 단계에서는 시스템의 변경이나 업데이트가 필요한 경우 이를 수행한다.

✔️ 문서화, 평가와 개선
프로세스의 각 단계에서 만든 문서들을 정리하고 보완하여 개발된 소프트웨어의 설명서를 작성한다. 프로젝트가 완료된 후에는 전체 프로세스를 돌아보고 개발한 시스템의 성능과 사용성을 평가한다. 이를 통해 개선점을 발견하고 다음 프로젝트에 반영하기 위한 교훈(lessons learned)을 얻는다.




설계3 (소프트웨어 공학)

프로그램 설계

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

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

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




알고리즘 선택

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

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

알고리즘 표현

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

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

 




사용자 인터페이스 설계

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

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

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

  • 요구사항 분석
    • 사용자의 요구사항과 기대를 이해하고 문서화
    • 사용자 그룹을 식별하고, 사용자의 특성, 선호도, 작업 환경 등 파악
    • 시스템의 목적과 기능, 사용자의 목표 정의
  • 설계 및 기획
    • 사용자 경험(UX)을 중심으로 설계
    • 인터페이스의 레이아웃, 구조, 흐름 계획
    • 기능적 요구사항을 각각의 화면 또는 모듈 매핑
    • 정보 구조를 설계하고, 사용자가 쉽게 찾아서 사용할 수 있도록 계획
  • 프로토타이핑
    • 초기 디자인 아이디어를 실제로 시뮬레이션하는 프로토타입 개발
    • 프로토타입을 사용하여 사용자의 피드백을 수집하고, 문제점이나 개선 사항 확인
    • 프로토타입을 통해 디자인과 기능을 검증하며, 수정과 보완 진행
  • 디자인
    • 프로토타입을 기반으로 시각적인 디자인 수행
    • 색상, 아이콘, 글꼴 등을 선택하여 사용자가 시각적으로 쉽게 인터페이스를 이해할 수 있도록 가이드
    • 일관성 있는 디자인 가이드라인을 따르면서 사용자가 헷갈리지 않도록 지침제시
  • 개발
    • 디자인된 인터페이스를 실제 코드 구현
      사용자 인터페이스 요소들을 프로그래밍 언어와 기술을 사용하여 구현
  • 테스트
    • 인터페이스의 기능, 사용성, 성능 테스트
    • 버그, 오작동, 일관성 문제 등을 식별하고 수정
    • 다양한 시나리오와 테스트 케이스를 사용하여 인터페이스 검증
  • 사용자 피드백 수집
    • 완성된 인터페이스를 실제 사용자들에게 제공하고 피드백 수집
    • 사용자의 의견을 수렴하여 인터페이스를 개선 보완
  • 배포 및 유지보수
    • 최종적으로 개발된 사용자 인터페이스 배포
    • 사용자들의 피드백을 기반으로 지속해서 개선과 보완 작업 수행

설계2 (소프트웨어 공학)

소프트웨어 공학에서 구조적 설계는 소프트웨어 시스템을 개발할 때 전체 시스템의 구조와 구성 요소 간의 상호작용을 계획하고 설계하는 단계이다. 이는 소프트웨어 개발 프로세스의 중요한 부분으로 시스템의 복잡성을 다루며 유지보수할 수 있고 확장할 수 있는 소프트웨어 시스템을 만들기 위한 첫 번째 큰 단계 중 하나다. 이러한 구조적 설계는 앞서와 같이 모듈화와 추상화, 모듈 간 인터페이스 설계, 데이터 구조 설계, 제어구조 설계, 자료구조 설계 및 모듈의 응집도와 결합도 등으로 구성되어 있다. 특히 구조적 프로그래밍을 통해 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) 구조: 데이터 처리를 여러 단계로 나누어 각 단계를 필터로 생각하고 각 단계 간 데이터를 파이프로 연결하여 처리하는 구조로 각 필터는 특정 작업을 수행하며 데이터를 받아 처리한 후 결과를 다음 필터로 전달한다. 이 구조는 시스템의 기능을 모듈화하고 데이터 처리를 효율적으로 관리하는 데 도움을 준다.

설계1 (소프트웨어 공학)

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

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

 




설계

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

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

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

 




설계 원리

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

✔️ 추상화(Abstraction)

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

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

 

✔️ 정보은닉(Information Hiding)

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

 

✔️ 단계적 분해

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

 

✔️ 모듈화

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

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

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




구조적 분석 (소프트웨어 공학)




구조적 분석

소프트웨어 개발에 있어 요구분석 단계는 중요하고도 어려운 단계이다. 많은 정보가 수집되어야 하며 의사소통의 어려움도 극복해야 하는 숙제 중 하나다. 이러한 작업을 증명하기 위한 방법은 매우 다양하다. 그중 프로세스 사이의 데이터 흐름을 파악하여 요구사항과 시스템을 파악하는 방법으로 구조적 분석이 있다. 구조적 분석(Structural Analysis)은 시스템의 기능적 요구사항을 구조화하고 조직화하는 단계이다. 이를 통해 요구사항 간의 관련성과 의존성을 이해하고 분해된 요구 모듈 간 관계를 분석하여 시스템의 구조를 설계할 수 있다. 구조적 분석은 데이터 흐름 다이어그램(DFD), 상태 전이 다이어그램, 클래스 다이어그램 등의 모델링 기법을 활용하여 수행된다. 전통적 방법으로서 이 단계에서는 요구사항이 어떻게 상호작용하고 구성되는지를 시각화하여 파악한다.

소프트웨어 개발 프로젝트 초기 단계부터 요구사항을 명확하게 이해하고 효과적으로 관리할 수 있는 구조적 분석은 궁극적으로 프로젝트의 성공 확률을 높일 수 있다. 이 방법은 크게 다음과 같은 단계로 수행되고 여기에 쓰이는 도구도 확인한다.

  • 요구사항 분해
  • 요구사항 상호 연계
  • 요구사항 계층 구조화
  • 요구사항 흐름도

 

  • 데이터 흐름도(Data Flow Diagram, DFD):
    • 사용자 요구사항 기반으로 데이터가 시스템 내에서 어떻게 흐르는지 도식화하며 프로세스(원 또는 둥근 사격형), 외부 엔티티(사각형), 저장소(열린 사각형), 데이터 흐름(화살표) 등을 기호로 하여 시스템 데이터 흐름을 구조화
    • 시스템 모델링에 중요한 추상화와 단계적 분해의 원리를 적용하여 하향식 분할을 통해 복잡한 문제를 작고 독립적 문제로 나누어 하나씩 해결할 수 있는 방법으로 접근
    • 서로 다른 단계 사이 자료 흐름은 표현에 일관성이 필요하고 완벽성 검사와 일관성 검사 시행
    • 크기가 너무 커진다면 프로세스를 그룹화하여 단계적으로 표현하며 하나의 분석에서 한 계층의 DFD만 작성하고 프로세스는 7개 전후로 포함되도록 함
  • 자료 사전(Data Dictionary): 시스템 내에서 사용되는 데이터 항목의 정의, 형식, 구조를 문서화하며 자료 사전은 데이터 항목들의 호환성과 일관성을 확인하고 중복을 제거
    • 일반적 언어사전과 형식은 동일
    • 자료요소 이름이 여러 단어 구성 시 자료사전 표제어에 밑줄 연결
    • 수식은 자료요소와 연산자(+, [], |, ”, 등)로 구성
  • 질의-응답 목록(Question and Answer List): 사전에 정해진 항목에 따라 요구사항을 구체화하는 도구로 시스템과 사용자의 상호작용을 정확하게 이해하고 구조화
    • 질문: 이해 관계자에게 특정 요구사항에 관한 질문 포함
    • 답변: 이해 관계자로부터 받은 답변 기록. 이 답변은 해당 요구사항에 대한 정보와 이해 관계자의 의견 표시
    • 질의자: 각 질문에 대한 원래 질문자 또는 요구사항 분석을 수행한 사람의 이름 기록. 의문 사항이 생길 경우 해당 정보의 출처 확인용
    • 날짜: 각 질문이나 답변이 만들어진 날짜 기록. 문서 갱신/추적용
    • 참고: 다른 문서나 자료와의 연결 표시
    • 상태: 질문이나 답변의 상태 표시, 추적
    • 비고: 해당 질문이나 답변에 대한 추가 설명이나 주석 기록
  • 유스케이스(Use Case): 사용자와 시스템 간의 상호작용을 나타내는 시나리오 기반 기술로 특정 목적 달성을 위한 사용자 관점에서 시스템과의 상호작용 과정 기술
    • 액터(Actor): 시스템 내에서 주요 기능을 수행하는 역할 또는 시스템과 상호작용하는 주체로 시스템 사용자, 다른 시스템, 외부 장치 등
    • 유스케이스 명(Use Case Name): 특정 기능 또는 시나리오의 간결하고 명확한 이름으로 유스케이스를 식별
    • 설명(Description): 유스케이스의 목적과 내용을 간단 설명
    • 사전조건(Preconditions): 유스케이스가 시작되기 전에 충족되어야 하는 조건 설명
    • 주요 시나리오(Main Scenario): 유스케이스의 핵심적인 동작과 순서 설명으로 시스템과 액터 간의 상호작용을 순차적으로 나열
    • 대안 시나리오(Alternative Scenarios): 주요 시나리오 이외의 다양한 상황에 대한 시나리오를 설명하며 주로 예외 상황이나 오류 처리 사용
    • 결과(Results): 유스케이스의 완료 후 기대되는 시스템의 상태 변화나 출력물 등 결과 기록

 




분석 과정

구조적 분석의 세부적인 과정은 크게 4단계로 나눠볼 수 있다. 

🚩 단계 1: 요구사항 수집 및 문서화

시스템에 대한 요구사항을 수집하고 구조화 및 문서화한다. 이 요구사항은 고객, 사용자, 도메인 전문가 등과의 인터뷰, 설문조사, 관찰 등 다양한 방법으로 얻을 수 있으며 최종적으로 기능적 요구사항(시스템이 수행해야 하는 작업)과 비기능적 요구사항(성능, 안전성, 보안 등)으로 구분될 수 있다. 이 과정을 통해 모호한 내용을 명확히 하고 요구사항 간의 관련성과 의존성을 파악, 중복되거나 충돌하는 요구사항을 논리적 블록으로 그룹화, 해결한다.

 

🚩단계 2: 데이터 흐름 다이어그램 작성

명세화된 요구사항을 기반으로 소프트웨어의 핵심 문제를 파악하고 분석할 수 있는 구조로 정리한다. 이때 데이터 흐름도(DFD), 자료사전, 프로세스 명세 등의 도구를 활용한다.

  – 주요 프로세스 식별: 수집된 요구사항을 기반으로 시스템 내의 주요 기능적 프로세스 식별하며 DFD로 표현 (시스템의 입력, 출력, 처리 과정 포함)
  – 데이터 흐름 식별: 프로세스 간에 주고받는 데이터(정보) 흐름 식별
  – 데이터 저장소 식별: 시스템 내 사용되는 데이터 저장소를 식별하는데 이는 데이터의 정의, 속성, 구조 등을 포함하고 이를 데이터 요소 간의 관계와 종속성을 파악

 

🚩단계 3: 데이터 흐름 다이어그램 작성 및 분석

분석된 요구사항이 사용자의 기대와 일치하는지 검증하여 문제가 없는지 확인하는 단계로 사용자와 지속적인 의사소통으로 유스케이스 테스트나 프로토타입 방식을 사용하여 실제 사용자의 반응을 수집할 수 있다. 특히 요구사항과 부합하며 일관성 있는 모델을 구축하는 것이 중요한데 이 결과를 바탕으로 소프트웨어의 전체적인 아키텍처를 설계할 수 있다. 특히 모듈화, 계층화, 컴포넌트 구조 등을 고려하여 시스템 구조를 결정한다.

  – 0레벨 DFD 작성: 주요 프로세스, 데이터 흐름, 데이터 저장소 등을 기반으로 0레벨 DFD를 작성하며 이 다이어그램은 시스템의 전체 구조를 보여주고 각 프로세스와 데이터 흐름의 관계를 가시화
  – 상세화: 0레벨 DFD를 기반으로 더 상세한 1레벨 DFD를 작성하여 프로세스를 세분화하고 데이터 흐름을 더욱 구체적으로 표현
  – 유효성 검사: 작성한 DFD를 검토, 논리적 오류나 모순점이 있는지 확인 

 

🚩단계 4: 문서화 및 의사소통

작성한 DFD를 문서화하여 요구사항 명세서나 설계 문서에 포함한다. 이에 개발팀 간 의사소통을 원활하게 하고 시스템 구조를 이해하는 데 도움을 준다. 요구사항이 변경되거나 갱신이 되면 요구사항 관리를 통해 변경된 요구사항에 따른 작업의 우선순위를 조정하고 추적 관리한다. 이 문서들은 개발 및 테스트 과정에서 참고 자료로 활용한다. 다시 말해 문서화와 의사소통의 중요성은 각기 다음과 같다.

  • 명확한 이해: 문서화로 프로젝트팀의 구성원, 고객, 스테이크 홀더 등 모두가 요구사항을 명확하게 이해 가능
  • 기능 및 범위의 정의: 문서화로 시스템의 기능과 범위가 정확하게 정의되며 프로젝트 방향성 보장
  • 변경 관리: 요구사항이 변경될 경우, 문서화로 변경 내역을 추적하고 관리 가능
  • 품질 향상: 문서화된 요구사항은 개발자들이 시스템을 설계하고 구현할 때 일관성 있고 정확한 정보를 참조할 수 있도록 지원

 

  • 이해 관계자 간의 의사소통: 프로젝트 구성원, 고객, 이해당사자 간 이해로 프로젝트 목표를 달성하기 위한 방향을 정하는 중요 기반
  • 오해 방지: 의사소통으로 모든 이해 관계자들이 동일한 의미로 요구사항을 이해할 수 있도록 지원하여 오해나 혼란이 줄어들면서 프로젝트 품질 향상
  • 피드백 수렴: 의사소통을 통해 고객이나 사용자의 피드백을 수렴하고 반영하여 요구사항의 정확성과 적절성 향상
  • 변경 관리: 프로젝트 진행 중 요구사항이 변경 시 이를 이해 관계자들과 공유하여 일관성을 유지하고 변경에 따른 영향을 평가 가능




요구분석 (소프트웨어 공학)

소프트웨어 공학에서 요구분석은 소프트웨어 개발 프로세스의 초기 단계에서 매우 중요하고 가장 어려운 부분 중 하나다. 그 이유는 요구분석 외 다른 작업은 만약 잘못되었을 때 비교적 적은 비용으로 오류를 수정, 보완할 수 있으나 요구분석의 경우에는 처음부터 다시 개발해야 하는 비용이 증가하고 개발기간은 늘며 소프트웨어 품질 저하의 직접적 원인이 되기 때문이다. 요구분석은 사용자 및 이해관계자와의 의사소통을 통해 시스템의 기능, 성능, 제약조건 등을 명확하게 이해하고 시스템이 충족해야 할 기능적 요소와 비기능적 요소를 파악, 정제하여 적절한 시스템 설계와 구현 기초를 다지는 과정이다. 이는 프로젝트의 성패를 좌우하는 결정적 요소로, 보다 정확하고 완전한 요구사항을 수집하고 분석하는 과정을 포함하며 이를 통해 시스템의 목표와 범위를 확실히 하여 성공적인 소프트웨어 개발을 돕는다.

다시 말해 요구분석은 다음과 같은 이유로 소프트웨어 개발에서 매우 중요하며

  • 소프트웨어 시스템의 개발, 구현, 테스트, 유지보수의 모든 단계에서 요구사항 참조
  • 소프트웨어 시스템의 개발 비용 절감 가능
  • 소프트웨어 시스템의 개발 기간 단축 가능
  • 소프트웨어 시스템의 품질 향상 가능

요구분석을 통해 얻을 수 있는 이점은 다음과 같다.

  • 소프트웨어 시스템 개발 목표 및 범위 명확화
  • 소프트웨어 시스템 기능/비기능 요구사항 명확화
  • 소프트웨어 시스템 테스트 사항 명확화
  • 소프트웨어 시스템 개발, 테스트, 유지보수에 드는 시간 및 비용 절약
  • 소프트웨어 시스템 성공적인 개발 보장

이러한 요구분석의 과정은 크게 요구, 요구추출 및 분석, 구조적 분석, 요구분석 명세로 구분할 수 있다. 이 단계들을 철저히 수행하여 프로젝트 초기부터 요구사항에 대한 명확한 이해와 관리가 가능하고 개발 프로세스의 효율성과 최종 제품의 품질 향상에 기여하여 소프트웨어 시스템의 성공적 개발을 보장받는다. 

 




요구(Requirement)

요구는 시스템이 외형적으로 나타내는 기능, 성능, 품질, 인터페이스, 환경, 보안, 유지보수, 제약사항 등의 동작을 말한다. 요구는 사용자, 고객, 시스템 이해관계자들로부터 도출되는데 명시적이고 모호하지 않으며 변하지 않는 특성을 가져야 한다. 이를 통해 소프트웨어 개발팀은 프로젝트의 목표와 범위를 파악할 수 있다. 이런 요구는 기능적 요구와 비기능적 요구로 크게 구분되며 기능적 요구는 시스템의 기능이나 동작에 관련된 것이고 비기능적 요구는 성능, 안전성, 보안 등과 같은 품질 속성에 관련된 것이다.

  • 기능적 요구: 시스템이 수행해야 할 특정 작업이나 기능에 대한 요구로 웹 서비스의 경우 사용자 등록, 로그인, 상품 검색 등의 기능을 말함
    • 시스템이 무엇을 언제 그 일을 하는가?
    • 시스템 운영 시 여러 다른 모드가 존재하는가?
    • 시스템이 언제 어떻게 변경 또는 확장되는가?
  • 비기능적 요구: 시스템이 충족시켜야 할 성능, 안정성, 사용성, 유지보수성 등과 같은 운영적, 환경적 제약 조건들로 응답 시간, 동시 접속자 수, 확장성 등이 포함
    • 시스템의 속도, 반응시간, 처리율, 처리자료 크기
    • 시스템 가동 평균 시간, 중단 후 복구시간
    • 시스템 설계변경 용이성, 용적률

그래서 요구는 매우 잘 정의되어야 하며 충분히 구체적이고 명료하여 개발자들이 이를 이해하고 작업에 착수할 수 있게 도움을 줄 수 있어야 한다.

 




요구추출 및 분석

요구추출은 소프트웨어 개발에서 특히 중요한 작업이다. 사용자가 무엇을 원하는지 결정을 내리는 작업으로서 이해관계자와의 대화, 설문 조사, 브레인스토밍, 워크숍 등의 여러 방법을 사용하여 요구를 도출한다. 요구추출 후에는 요구사항을 분석하고 중복, 모호성, 불일치 등을 식별하고 정제한다. 이 과정에서 중요한 것은 사용자의 실제 기대에 부합하도록 정확하게 요구사항을 파악하는 것이다. 요구추출이 잘못되면 소프트웨어 시스템이 사용자의 요구를 충족하지 못하거나, 개발 비용이 증가하거나, 개발 기간이 늘어나거나, 소프트웨어 시스템의 품질이 저하될 수 있다.

이러한 요구추출은 크게 3가지 우선순위를 따지는데 첫째는 절대적으로 필요한 요구인가? 둘째는 꼭 필요하지 않은 요구인가? 셋째는 요구로 판단되나 제외할 수 있는가? 이다. 그러면서 다음 사항을 고려해야 한다.

  • 사용자 요구의 정확한 이해
  • 요구사항 명확성과 간결성
  • 요구사항 완결성과 일관성
  • 요구사항 실행 가능성

요구추출 후 진행하는 요구분석에 있어 가장 중요한 것은 사용자가 현재 안고 있는 문제점을 이해하는 것이다. 이에 분석가는 사용자의 입장에서 현황을 파악하고 사용자가 원하는 문제 해결이 무엇인지 이해하여야 한다. 즉 수많은 정보를 수집하고 재구성하는 데 있어 ‘육하원칙’에 따라 질문하고 답을 구하는 단계가 요구분석이라고 볼 수 있다. 이러한 질문을 통해서 사용자의 문제를 이해할 수 있고 해결 방법을 찾는 데 도움을 받을 수 있다. 또한 해결 과정에서의 제약점과 이를 사용자가 수용할 수 있는지도 살펴야 한다. 특히 구체화한 목표가 명확해야 한다.

  • 분석 대상 업무에 누가 관계되어 있는가? 그들은 누구인가? 어떤 일을 하는가?
  • 현재의 상태는 어떠한가? 문제가 있는가? 요구 기능은 무엇인가?
  • 신규 시스템은 언제 완료되어야 하는가? 언제 교체하는가? 
  • 신규 시스템을 어떤 환경으로 운영할 것인가? 인력은 어떻게 배치하는가?
  • 왜 신규 시스템을 고려하였는가? 개선하고자 하는 이유는?
  • 신규 시스템은 어떻게 작동되어야 할 것인가? 작동의 제약사항은 무엇인가?

이러한 요구분석에는 구조적 분석, 객체지향 분석, 정보공학 및 정형화 방법 등 여러 기법이 존재한다.

 




구조적 분석

구조적 분석은 시스템의 기능적 요구사항을  분해하고 구조화하여 조직화하는 단계다. 이를 통해 요구사항 간의 관련성과 의존성을 이해하고 시스템의 구조를 설계할 수 있다. 구조적 분석은 문제 영역을 이해하기 위해 데이터 흐름 다이어그램(DFD), 상태 전이 다이어그램, 클래스 다이어그램 등의 모델링 기법을 활용하며 요구사항이 어떻게 상호작용하고 구성되는지를 시각화한다. 구조적 분석은 보통 다음과 같은 단계로 수행한다.

  • 요구사항 분해
  • 요구사항 상호 연관
  • 요구사항 계층 구조화
  • 요구사항 흐름도 작성

이런 단계를 통해 현재 시스템과 목표 시스템의 모형이 만들어진다. 일반적인 모형들은 정보나 아이디어를 추상화하여 집약적으로 나타내며 시스템 구성 요소들의 상호 작용과 기능들을 표현하여 사용자의 이해를 돕는다. 이는 건축과 같이 철저히 양식이 기능을 따르는 원리를 적용한다.

 




요구분석 명세

문제를 명확히 이해하고 목표가 정해지면 문서화가 필요하다. 요구분석 명세는 수집된 요구사항을 정확하게 문서화하는 것을 말하며 이 과정에서는 요구 사항들에 대한 정규화, 우선순위 정하기, 추적 행렬 생성 등이 이뤄진다. 이를 통해 개발자, 테스터 및 다른 이해관계자들이 이를 이해하고 활용할 수 있도록 한다. 이 문서는 요구사항의 상세 내용과 우선순위, 변경 요청 프로세스 등을 포함하고 시스템 설계 및 구현의 입장에서 충분한 정보를 제공, 개발자와 관계자들이 이해할 수 있는 언어로 아주 명료하게 작성하여 이후 개발 및 테스트 단계에서 참조되는 중요한 자료이다.

요구분석 명세(Software Requirement Specification)는 소프트웨어 개발 모든 단계에서 중요한 역할을 수행하며 보통은 다음과 같은 내용을 포함하며

  • 시스템의 목적
  • 시스템의 기능
  • 시스템의 성능과 품질
  • 시스템의 인터페이스
  • 시스템의 환경
  • 시스템의 보안
  • 시스템의 유지보수

그 평가 기준은 아래와 같다.

  • 무결성/완벽성: 사용자의 요구사항을 오류 없이 완벽하게 반영
  • 일관성: 상호 간 모순 없이 존재
  • 명확성: 여러 의미로 해석되지 않음
  • 기능적: ‘어떻게’가 아닌 ‘무엇’에 초점
  • 검증가능성: 사용자 요구 만족과 시스템 일치성
  • 추적 가능성/변경 용이성: 체계적 정리

 

프로젝트 계획 (소프트웨어 공학)

프로젝트 문제와 범위 정의

소프트웨어 개발 시 일정이 지연되거나 비용이 초과고 기대했던 품질에는 못 미치는 산출물, 그에 따라는 여러 유지비용의 증가 등과 같은 문제들은 기본적으로 계획의 부재에서 오는 경우가 많다. 개발 일정을 준수하면서 질 좋은 소프트웨어를 개발 생산하기 위해서는 정밀하고 세심한 계획수립이 필요하다. 소프트웨어 개발 프로젝트 초기 단계에서 프로젝트의 목표를 기반으로 여러 불분명한 사안들을 확인해 가면서 계획을 수립하는 것은 매우 어렵다. 하지만 계획작업을 통해 불분명한 목표, 사용자 요구사항 및 제약사항 등을 명확히 하는 것이 필요하다. 이러한 계획은 보통 문제의 범위를 확인, 정의하고 필요한 활동들을 정하며 세부적인 일정계획과 비용을 추정하고 최종적으로 계획서를 작성하는 절차로 이뤄진다. 

다시 말해 프로젝트 계획은 대상업무와 문제들을 고객이 이해하는 용어로 정확하기 정의하고 기술하는 것으로 시작한다. 문제는 철저하게 고객의 입장에서 정의되어야 하며 기술관련 전문용어 등을 사용해서는 안된다. 문제를 정의하는 것은 범위를 정하는 것이다. 이는 개발대상의 기능, 성능, 제약조건, 인터페이스 등의 프로젝트에 대한 타당성과 신뢰성 및 초기 계획을 작성가능한가에 대한 판단 근거로 쓰인다. 문제 정의는 제일 먼저 그 배경을 이해하여야 한다. 이를 위해선 고객과의 면담, 현장답사 및 실제 업무를 수행하는 실무자의 실제 업무를 관찰하거나 직접 수행을 해보기도 한다. 그러면서 객관적 시각에 문제를 파악한다. 이 모든 것이 끝나면 문제 해결을 위한 준비를 한다.

 




일정 계획

일정은 프로젝트 개발에 있어 모든 프로세스를 구성하는 작업들을 파악하여 그 우선순위와 기간을 산정하며 진행한다. 이에 모든 작업들을 수준별로 나열을 하며 산출물이 있다면 각각 기술해 준다. 프로젝트의 규모가 작다면 큰 일이 아닐 수도 있으나 대규모의 프로젝트에서는 작업도출과 더불어 각 작업들 간의 상관관계를 면밀히 검토하여야 한다. 이때 보통은 PERT/CPM을 활용하며 최종적으로 간트차트 등을 사용하여 거시적 관점에서의 일정을 관리할 수 있도록 한다. 이렇듯 소프트웨어 공학은 엔지니어링 작업으로서 정확하고 현실적인 계획을 수립하고 작업 수행에 소요되는 여러 자원들을 최적화하여야 한다. 이에 따라 프로젝트의 진척도를 실시간으로 점검할 수 있고 계획과 비교하여 문제가 있을 시에 다방면의 조치로 문제해결이 가능하다.

간트차트로 보여지는 프로젝트 작업들, 일정표는 그 수준에 맞춰 분해가 이뤄지고 계층적으로 구성하여야 하는데 이를 위해 WBS(Work Breakdown Structure)를 사용한다. 이는 작업들이 모여 소요 일정이 예측되며 이를 통해 프로젝트 전체 일정을 예측할 수 있다. WBS는 큰 단위의 업무를 관리하기 쉬운 작은 단위의 작업으로 나누기 위한 도구이다. 여기서 관리 가능한 작은 작업들은 업무 지시를 하는 단위가 되며 작업시작일, 종료일, 소요기간, 담당자, 필요 자원 등을 병기하여 관리한다. WBS는 일정계획 작업의 입력값이며 작업 분해는 프로젝트가 어떤 작업으로 구성되었는지를 알아내는 것이고 일정 계획은 이들 작업을 어떤 순서로 할 것인가를 정하는 일이다.

  • 소프트웨어 개발모형 선정, 단계별 작업을 분해 후 작업결과 정의
  • 각 작업간 상호의존관계 정리
  • 각 작업소요기간 정의 및 프로젝트 완료에 필요한 최소기간 산출
  • 프로젝트 규모추정을 통한 M/M 산출
  • 확정 결과 정리 및 공유

 




비용 추정

소프트웨어 개발에 있어 비용을 정확히 예측하기는 매우 어려운 일이다. 특히 계획단계에서는 불분명한 사항들이 많고 여러 환경적인 요소로 비용에 대한 입장차도 존재한다. 그럼에도 불구하고 기준을 바탕으로 수립되는 소프트웨어 개발 비용예측은 특히 투입되는 개발자와 기간에 매우 큰 변수로 작용한다. 이에 과거 프로젝트의 경험이 중요하며 특히 유사 프로젝트가 있다면 규모와 비용, 인력들을 감안하여 예측을 어느 정도 가능하게 한다. 그러므로 정확한 예측은 프로젝트 성공율을 높이는 필수 조건이다. 이에 비용 예측방법도 매우 다양하며 인건비의 경우 소요기간을 기준으로 하거나 프로그램 규모를 기준하는 방법으로 크게 나뉜다.

첫번째 방법은 소요기간 기준이다. 이는 프로젝트 내 작업들에 소요되는 기간을 구하고 여기에 투입인력과 참여도를 반영하여 최종 인건비를 산출한다. 이 방법은 상향식이라 불리우며 단순히 헤드카운팅이라고도 하는데 시스템 개발에 필요한 모든 작업에 대한 노력들을 하나하나 계획할 수 있는 장점이 있으나 객곽적이 못한 추정 가능성이 있을 수 있다. 두번째 방법은 하향식으로 프로그램 규모를 추정하고 과거 경험을 바탕으로 예측 규모에 대한 소요인력과 기간을 추정한다. 프로그램 규모는 원시코드의 라인수(LOC)나 시스템의 기능을 정량화한, 좀더 복잡한 기능점수(Function Point) 등올 산출할 수 있다. 

 




조직 구성

경영관리에서 조직이란 개개인의 역할을 잘 정의하고 할당하여 프로젝트 목표 성취를 하기 위한 것이다. 이는 기업이나 단체 등 다수의 사람이 모여서 하나의 목표를 이루기 위한 방안으로 조직이 생겨난 것이다. 이러한 조직 구성의 목적은 공통된 목표를 위하여 상호 협력을 하는 것으로 프로젝트에서도 동일하게 적용된다. 이런 조직구성은 조직의 생산성과 효율에 얼마나 많은 영향을 미치고 그 결과가 어떻게 나타나냐에 대한 근본 원리를 따진다. 소프트웨어 개발 프로젝트에서 소프트웨어는 타 제품과는 다른 특징들로 인해 어떠한 조직을 구성하여 진행했느냐에 따라 소프트웨어 개발에 많은 영향을 미친다. 즉 소프트웨어의 품질을 향상시킬 수 있는 소프트웨어의 특성을 잘 살린 조직 구성이 필요한 것이다.

조직의 선택에 영향을 주는 요소는 비용 예측에 사용되는 요소와 유사하다. 알맞은 조직 구성은 프로젝트 기간과 매우 밀접하다. 장기 프로젝트의 경우 구성원들의 사기를 높이고 이직과 이탈을 막기 위하여 개개인의 만족도가 중요 시 된다. 경험이 많은 인력과 적은 인력이 적절하게 섞여야 하며 상호 간 배우고 배울 수 있는 관계 설정도 필요하다. 대규모 프로젝트의 경우 요구의 변경과 명세가 어려운 특성으로 인하여 프로젝트 후반에 신규 인력을 투입하면 일정은 그만큼 지연된다. 이는 인력 상호 간 의사소통의 통로 이슈와 기존 업무의 인수인계 등에 따른 시간을 고려한다고 해도 해소되지 않는 난제이다. 다시 말해 작업의 특성과 조직 구성원 사이의 의사소통의 횟수는 조직의 규모에 맞춰야 하며 필요 이상의 결과에 집중하지 않게 적정 선을 지키는 것이 중요하다.

프로젝트 팀 구성에 영향을 주는 다른 요소는 작업의 특성 및 팀 구성원 사이에 의사교류의 횟수이다. 의사소통이 원활할 수 있는 조직규모와 인력수는 매우 밀접하며 프로젝트의 복잡도와도 긴밀하다. 이에 공식적인 모형과 인원수도 산출할 수 있는데 중요한 것은 생산성에 촛점을 맞춘 균일한 규모의 조직을 구성하는 것이다. 이 규모는 소프트웨어의 특성과도 연계가 되며 팀은 원칙적으로 작업 수행에 제일 타당하게끔 조직되어야 한다. 그러기 위해선 관리자의 권한과 더불어 일정, 예산, 품질 등 여러 요소를 고려하여 조직 구성방법을 결정하여야 한다. 특히 소프트웨어 개발 팀구성은 의사결정권이 누구에게 있느냐에 따라 구별되며 리더의 역할, 권한, 의무에 따라 크게 3가지 형태의 구성방식을 갖는다.

  • 중앙집중형: 하나의 관리자의 지휘에 따라 움직인다. 기업 조직 내 일반적인 계층형 조직으로 상하관계가 명확하여 대규모 조직보다는 소규모 조직에 적합하고 이의 모듈화로 규모를 키울 수 있다.
  • 분산형: 의사결정을 민주주의식으로 하며 모든 작업은 공동의 작업이다. 팀 구성원 각자가 서로의 작업을 검토하고 타 구성원의 작업결과에 대하여 책임을 진다. 다만 의사소통 비용이 많이들며 이에 따른 생산성 문제가 있다.
  • 혼합형: 중앙집중형과 분산형의 단점을 보완하기 위해 구성된다.

 




위험분석

위험 분석은 프로젝트에 내재한 위험 요소를 인식하고 그 영향력을 분석하여 관리하는 활동이며 프로젝트를 성공시키기 위하여 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동이 포함된다. 위험 요소에 대해 적절히 관리하지 못하면 프로젝트는 실패할 수 있다. 초기 단계에 위험 요소를 인식하고 그 영향을 분석하였어도 이를 다루는 일관성 있는 계획이 없으면 실패하기 쉽다. 이러한 위험을 줄이는 효과적인 방법은 프로토타이핑이나 점증적 개발 방법 있으며 중간 변경 위험을 대비하기 위한 모듈화도 생각해 볼 수 있다. 

< Boehm(Barry William Boehm, 미국 소프트웨어 엔지니어 및 교수, 나선형 모델 제)이 제시한 10가지 위험 요소와 관리 기법 >

  • 인력부족: 유능한 인력 수급, 팀구성, 교육
  • 비현실적 일정/예산: 구체적 비용/일정 예측, 원가분석, 재사용
  • 잘못된 기능의 SW개발: 프로토타이핑, 조직/직능분석
  • 잘못된 I/F개발: 프로토타이핑, 타스크분석, 시나리오기법
  • 과포장: 프로토타이핑, 원가분석, 비용수익분석
  • 계속적인 요구변경: 최대변경상한선, 점증적 개발
  • 외부 모양 빈약: 벤치마킹, 성숙도분석
  • 외부 기능 빈약: 사전검증, 대조확인
  • 실시간 성능 빈약: 벤치마킹, 튜닝, 시뮬레이션
  • 기술적 취약: 기술분석, 비용수익분석