소프트웨어 설계 3: UML

22 Jul 2024     #cs

UML (Unified Modeling Language)

소프트웨어 시스템의 구조 및 동작 설계와 명세를 시각적으로 표현하는 데 사용되는 표준화된 객체지향 모델링 언어.

• 시스템 개발 과정에서 개발자 간, 개발자와 사용자 간 의사소통이 원활하도록 도움이 될 수 있음.
• Rumbaugh (OMT), Booch, Jacobson 등 객체지향 방법론의 장점을 통합함.
• 구성 요소: 사물 (Things), 관계 (Relationship), 다이어그램 (Diagram)

*요구 명세 기법과 UML: 요구 명세 기법은 사용자 요구사항을 수집하고 명확히 정의하는 기법 (e.g. 유스케이스 다이어그램(UML 사용 가능)). 한편 UML은 요구사항을 포함한 시스템의 다양한 측면을 시각적으로 표현하는 데 사용되는 표준 모델링 언어.

사물과 클래스

• 클래스: UML에 표현되는 사물의 하나. 객체가 갖는 속성과 동작을 표현. 일반적으로 직사각형으로 표현됨.
• 인터페이스: UML에 표현되는 사물의 하나. 컴포넌트의 동작을 모아놓은 것, 가시화되는 행동. 인터페이스를 구현하는 클래스나 컴포넌트와 함께 사용됨.

관계와 관계의 종류

관계: 사물과 사물 사이의 연관성.

• 연관 (Association): 사물이 서로 관련이 있는 관계.
  • 기호: 양방향 관계는 실선으로 표시. 다중도를 선 위에 표기할 수 있음.
• 집합 (Aggregation): 하나의 사물이 다른 사물에 포함되어 있는 관계.
  • 포함하는 쪽(whole)과 포함되는 쪽(part)은 서로 독립적.
  • 기호: 마름모를 포함하는 쪽으로 향하게 연결.
  • e.g. 프린터(part)는 컴퓨터에 연결해 사용하고, 다른 컴퓨터에 연결할 수도 있다.
• 포함 (Composition): 집합의 특수한 관계, 포함하는 사물의 변화가 포함되는 사물에 영향을 주는 관계.
  • 양쪽은 서로 독립될 수 없고, 생명 주기를 같이함.
  • 기호: 채워진 마름모를 포함하는 쪽으로 향하게 연결.
  • e.g. 열쇠로 문을 열 수 있다. 문(whole)이 없어지면 열쇠(part)가 필요 없어진다.
• 일반화 (Generalization): 어떤 사물이 다른 사물에 비해 일반적 혹은 구체적인 관계.
  • 일반적인 사물을 상위(부모), 구체적인 사물을 하위(자식)라고 함.
  • 기호: 빈 화살표가 일반적인 쪽을 향하게 연결.
  • e.g. 비행기와 자동차(하위)는 탈 것(상위)이다.
• 의존 (Dependency): 필요에 의해 서로 영향을 주는 시간 동안만 연관되는 관계.
  • 한 사물(이용자)의 변화가 다른 사물(제공자)에 영향을 줌.
  • 한 클래스가 다른 클래스를 매개 변수로 사용하는 경우.
  • 기호: 영향을 받는 사물(제공자) 쪽으로 향하게 점선 화살표로 연결.
  • e.g. 등급이 높으면 할인율을 제공하고, 아니면 적용하지 않음.
• 실체화 (Realization): 그룹화되는 관계.
  • 한 객체가 다른 객체에게 연산을 수행하도록 지정하는 의미적 관계.
  • 기호: 사물에서 기능 쪽으로 빈 점선 화살표를 연결.
  • e.g. 비행기와 새는 ‘비행’이라는 기능으로 그룹화 됨.

다이어그램 (Diagram)

사물과 관계를 도형으로 표현한 것.

• 뷰 (View): 시스템을 어떤 관점에서 가시화한 것.
• 분류: 구조적 다이어그램, 행위 다이어그램
  • 구조적 다이어그램은 정적 모델링, 행위 다이어그램은 동적 모델링에 사용함.

구조적 다이어그램의 종류

• 클래스 다이어그램 (Object Diagram): 클래스와 클래스의 속성, 클래스 간 관계를 표현
• 객체 다이어그램 (Object Diagram): 클래스에 속한 객체(사물), 즉 인스턴스 (Instance)를 특정 시점의 객체와 객체 간 관계로서 표현. 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용됨.
• 컴포넌트 다이어그램 (Component Diagram): 실제 구현 모듈인 컴포넌트 간 관계나 인터페이스를 표현. 구현 단계에서 사용.
• 배치 다이어그램 (Deployment Diagram): 물리적 요소(결과물, 프로세스, 컴포넌트 등)의 위치를 표현. 구현 단계에서 사용.
• 복합체 구조 다이어그램 (Composite Structure Diagram): 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현.
• 패키지 다이어그램 (Package Diagram): 모델의 요소(유스케이스, 클래스 등)를 그룹화한 패키지 간 관계를 표현.

행위 다이어그램의 종류

• 유스케이스 다이어그램 (Use Case Diagram): 사용자의 요구를 분석, 기능 모델링에 사용함. 사용자(Actor)와 사용 사레(Use Case)로 구성됨.
• 순차 다이어그램 (Sequence Diagram): 시스템이나 객체 간 주고 받는 메시지를 표현.
• 커뮤니케이션 다이어그램 (Communication Diagram): 객체 간 메시지와 객체 사이의 연관관계를 표현.
• 상태 다이어그램 (State Diagram): 객체의 상태가 자신이 속한 클래스의 변화나 다른 객체와의 상호작용에 따라 어떻게 변하는지를 표현. 럼바우 객체지향 분석 기법에서 동적 모델링에 활용됨.
• 활동 다이어그램 (Activity Diagram): 시스템의 기능, 객체의 로직, 조건에 따른 처리의 흐름을 순서에 딸라 표현.
• 상호작용 개요 다이어그램 (Interactive Overview Diagram): 상호작용 다이어그램 간 제어 흐름을 표현.
• 타이밍 다이어그램 (Timing Diagram): 객체 상태 변화와 시간 제약을 표현.

스테레오 타입 (Stereotype)

UML의 기본 기능 외에 추가적인 기능을 표현하는 것. $« »$(Guilemet) 안에 내용을 기술하여 표현.

소프트웨어 설계 2: 디자인 패턴

22 Jul 2024     #cs

디자인 패턴 (Design Pattern)

모듈 간 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 말합니다. 1995년 Gang of Four (GoF)라 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vissides가 체계화했습니다. 수많은 패턴 중 제일 일반적인 패턴을 분류 및 정리하였으므로, 현업에서 제일 많이 사용되는 패턴들이 포함되어 있습니다.

• 문제, 배경, 실제 적용 사례, 재사용 가능 샘플 코드 등으로 구성되어 있습니다.
• 생성, 구조, 행위 패턴으로 구분됩니다.

생성 패턴 (Creational Pattern)

클래스/객체의 생성과 참조 과정을 정의하는 패턴입니다.

추상 팩토리 (Abstract Factory)

객체 그룹을 인터페이스를 통해 서로 의존하는 것으로 생성하여 추상적으로 표현하는 패턴으로, 연관된 서브클래스를 묶어 한 번에 교체할 수 있습니다.

팩토리 메서드 (Factory Method)

객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴으로, 상위 클래스에서는 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당합니다. 가상 생성자 (Virtual Constructor) 패턴이라고도 합니다.

빌더 (Builder)

인스턴스를 조합하여 객체를 생성하는 패턴입니다. 객체의 생성과 표현을 분리하므로, 동일한 객체를 생성했음에도 표현에 있어 다른 결과를 보일 수 있습니다.

프로토타입 (Prototype)

원본 객체를 복제함으로써 객체를 생성하는 패턴으로, 비용이 큰 경우 유용합니다.

싱글톤 (Singleton)

생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시 참조할 수는 없는 패턴입니다. 클래스 내 인스턴스가 하나뿐음을 보장하고, 불필요하게 메모리를 낭비하지 않게 합니다.

구조 패턴 (Structural Pattern)

클래스나 객체를 조합하여 큰 구조를 만드는 패턴으로, 구조가 복잡한 시스템을 개발이 쉽도록 합니다.

어댑터 (Adapter)

다른 클래스가 특정 클래스를 이용하고자 할 때, 해당 클래스가 호환성이 없는 경우(인터페이스가 일치하지 않는 경우), 그 클래스의 인터페이스를 변환하여 이용 가능하게 만드는 패턴입니다.

브리지 (Bridge)

구현 부분에서 추상층을 분리하여 각각 독립적으로 확장될 수 있게 구성한 패턴으로, 구현과 기능을 별도의 클래스로 취급합니다.

컴포지트 (Composite)

단일 객체와 여러 객체로 구성된 복합 객체를 구분 없이 다루고자 할 때 사용하는 패턴입니다. 객체들을 트리 구조로 구성하여, 복합 객체 내 복합 객체가 포함되는 구조를 구현할 수 있습니다.

데코레이터 (Decorator)

객체 간 결합을 통해 기능을 확장할 수 있는 패턴으로, 특정 객체에 객체를 덧붙여 부가적인 기능을 추가합니다.

퍼싸드 (Facade)

클래스들 상위에 인터페이스를 구성하여 서브 클래스들의 기능을 간편하게 사용할 수 있게 하는 패턴입니다. 이 통합 인터페이스를 제공하는 Wrapper 객체가 필요합니다.

플라이웨이트 (Flyweight)

인스턴스를 매번 생성하지 않고 가능한 공유해서 사용하는 패턴입니다. 많은 유사 객체를 생성, 조작할 때 유용하며, 메모리를 절약할 수 있습니다.

프록시 (Proxy)

클래스/객체를 조합하여 복잡한 시스템을 개발하는 작업을 쉽게 해주는 패턴으로, 대리자라고도 불립니다. 내부에서는 객체 간 관계를 단순화해주고, 외부에서는 객체의 세부 내용을 숨겨주는 역할을 합니다.

행위 패턴 (Behavioral Pattern)

클래스나 객체 간 상호작용이나 책임 분배 방법을 정의하는 패턴입니다.

책임 연쇄 (Chain of Responsibility)

한 객체가 요청을 처리하지 못하면 다음 객체가 그것을 처리하는 형태의 패턴입니다. 요청을 처리할 수 있는 객체가 둘 이상 존재하고, 이 객체들이 고리(chain)로 묶여 있어 요청이 완료될 때까지 고리를 따라 책임이 넘어갑니다.

커맨드 (Command)

요청을 객체 형태로 캡슐화하여, 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴입니다. 요청에 사용되는 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화합니다.

인터프리터 (Interpreter)

언어 문법 표현을 정의하는 패턴으로, SQL이나 통신 프로토콜 등을 개발할 때 사용합니다.

반복자 (Iterator)

접근이 잦은 객체에 대해(자료구조 등) 동일한 인터페이스를 사용하도록 하는 패턴으로, 내부 표현 노출 없이 순차적인 접근을 가능하게 합니다.

중재자 (Mediator)

인터페이스를 객체 형태로 캡슐화하는 패턴입니다. 객체 간 의존성을 줄여 결합도를 감소시킬 수 있습니다.

메멘토 (Memento)

특정 시점의 객체 내부 상태를 객체화하여 이후 해당 시점의 상태로 객체를 돌릴 수 있는 기능을 제공하는 패턴입니다. 대표적으로 취소(Ctrl+Z) 기능이 있습니다.

옵서버 (Observer)

상위 객체의 상태가 변화하면 하위 객체들에게 변화된 상태를 전달하는 패턴으로, 일대다 의존성을 정의합니다. 주로 분산 시스템에서 이벤트를 발행하고 수신할 때 이용합니다.

상태 (State)

객체 상태를 캡슐화하여 이를 참조하는 방식으로 처리하는 패턴으로, 객체의 상태에 따라 동일 동작을 다르게 처리할 때 사용합니다.

전략 (Stretegy)

동일 계열의 알고리즘을 각각 캡슐화하여 상호 교환(대체)될 수 있게 정의하는 패턴입니다. 클라이언트는 독립적으로 알고리즘을 원하는대로 선택할 수 있고, 클라이언트 영향 없이 알고리즘을 변경할 수 있습니다.

템플릿 메소드 (Template Method)

상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 패턴입니다. 유사한 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드 양을 줄이고 유지보수를 용이하게 합니다.

방문자 (Visitor)

각 클래스의 데이터 구조에서 처리 기능을 분리해 별도의 클래스로 구성하는 패턴입니다. 분리된 처리 기능을 각 클래스를 방문함으로써 수행됩니다.

소프트웨어 설계 1: 소프트웨어 아키텍쳐와 객체지향

22 Jul 2024     #cs

소프트웨어 아키텍쳐 (Software Architecture)

SW를 구성하는 요소 간 관계를 표현하는 시스템의 구조 혹은 구조체입니다.

• 소프트웨어 아키텍쳐 설계 기본 원리: 모듈화, 추상화, 단계적 분해, 정보 은닉

모듈화 (Modularity)

시스템의 기능을 모듈 단위로 나누는 것을 말합니다. 모듈화는 SW의 성능 향상 및 시스템의 수정, 재사용, 유지관리 등이 용이하도록 합니다. 결합도(Coupling)를 최소화하고 응집도(Cohesion)의 최대화하는 것을 목표로 합니다.

추상화 (Abstraction)

문제의 포괄적인 개념을 설계한 후 이를 구체화해나가는 것을 말합니다. 유형은 다음과 같습니다:

• 과정 추상화: 수행 과정 설계 시 전반적인 흐름만 파악할 수 있게 설계
• 자료 추상화: 데이터 정의 시 데이터 구조를 대표할 수 있는 표현만 사용
• 제어 추상화: 이벤트 관련 정의 시 절차나 방법을 대표할 수 있는 표현을 사용

단계적 분해 (Stepwise Refinement)

문제를 중요한 상위 개념에서 하위 개념으로 구체화하는 분할 기법으로, Niklaus Wirth가 제안한 하향식 설계 전략입니다. SW의 포괄적 기능에서 점차 알고리즘, 자료 구조 등 상세한 부분으로 설계해나갑니다.

정보 은닉 (Information Hiding)

모듈 내부에 포함된 정보를 감추어 다른 모듈이 접근 및 변경하지 못하게 하는 기법입니다. 이를 통해 모듈을 독립적으로 수행할 수 있고, 모듈이 변경되어도 다른 모듈에 영향을 주지 않아 수정, 테스트, 유지보수가 용이합니다.

협약 (Contract)에 의한 설계

컴포넌트의 정확한 인터페이스를 명세하는 것입니다. 컴포넌트 설계 시 클래스에 대한 가정을 공유할 수 있게 합니다. 명세에 포함될 조건으로는:

• Precondition (선행 조건): 연산이 호출되기 전에 만족되어야 하는 조건
• Postcondition (결과 조건): 연산이 수행된 후 만족되어야 하는 조건
• Invariant (불변 조건): 연산 실행 중 항상 만족되어야 하는 조건

아키텍쳐 패턴 (Pattern)

아키텍쳐 설계 시 참조할 수 있는 해결 방식 혹은 예제로, 시스템 구조의 기본적인 윤곽을 제시합니다. 각 패턴에는 서브 시스템과 각각의 역할이 정의되어 있습니다.

• 레이어 패턴 (Layers Pattern): 시스템을 계층으로 구성하는 고전적인 패턴입니다.
  • 상위 계층은 하위 계층의 클라이언트가, 하위 계층은 서비스 제공자가 됩니다.
  • 상호작용은 마주 보는 두 계층 사이에서만 이뤄집니다.
  • 대표적 사례: OSI 참조 모델
• 클라이언트-서버 패턴 (Client-Server Pattern): 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴입니다.
  • 사용자는 클라이언트에 요청하고, 클라이언트가 서버의 응답을 받아 사용자에게 제공합니다.
• 파이프-필터 패턴 (Pipe-Filter Pattern): 데이터 스트림의 각 단계를 필터로 캡슐화하여, 파이프를 통해 전송하는 패턴입니다.
  • 파이프를 통해 이전 시스템의 결과물을 전달 받아 처리한 후, 그 결과를 다음 시스템에 넘겨주는 것을 반복합니다.
  • 데이터 변환, 버퍼링, 동기화 등에 사용됩니다.
  • 대표적 사례: UNIX의 Shell
• 모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern): 서브시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴입니다.
  • 사용자는 컨트롤러에 요청하고, 컨트롤러는 기능과 데이터가 보관된 모델에서 처리한 후, 뷰에 결과를 출력합니다.
  • 뷰는 여러 개 만들 수 있습니다.
  • 대화형 애플리케이션에 적합합니다.

객체 지향 (Object-Oriented)

SW의 각 요소를 객체(object)로 만들고, 객체를 조립해서 SW를 개발하는 기법입니다.

• 구성 요소: 객체, 클래스, 메시지
• 특징: 캡슐화, 상속, 다형성, 연관성

객체 지향의 구성 요소

객체 (Object)

데이터와 함수를 묶어 놓은 SW 모듈입니다.

• 데이터: 속성, 상태 등 객체가 갖고 있는 정보
• 함수: 객체가 수행하는 기능, 데이터를 처리하는 알고리즘. 객체의 상태를 참조/변경하는 수단

클래스 (Class)

공통된 속성과 연산을 갖는 객체의 집합, 객체들의 속성과 연산을 정의하는 틀입니다.

• 인스턴스 (Instance): 클래스에 속한 각 객체

메시지 (Message)

객체 간 상호작용에 사용되는 수단으로, 객체의 연산을 일으키는 외부의 요구사항입니다. 객체가 메시지를 받으면 그에 맞는 연산을 수행하고 예상된 결과를 반환합니다.

캡슐화 (Encapsulation)

객체의 인터페이스를 제외한 세부 내용을 은닉하는 것으로, 외부로부터 오는 접근을 제한합니다. 캡슐화된 객체는 외부 모듈이 변경되어도 영향을 적게 받습니다. 또한 메시지를 주고 받을 때 상대 객체의 세부 내용은 알 필요가 없으므로, 인터페이스가 단순해지고 결합도가 낮아집니다.

객체 지향의 특징

상속 (Inheritance)

어떤 클래스의 모든 속성과 연산을 물려받는 것으로, 상속 되는 클래스를 상위 클래스, 상속 받는 클래스를 하위 클래스라고 합니다. 하위 클래스는 물려받은 속성과 연산을 즉시 자신의 것으로 사용할 수 있습니다. 또한 상속 받은 것 외의 새로운 속성과 연산을 추가해 사용할 수 있습니다.

다형성 (Polymrphism)

메시지에 대해 각 객체의 고유한 방법으로 응답할 수 있는 능력입니다. 이것으로 인해 같은 클래스를 상속한 여러 하위 객체들이 서로 다른 특성을 갖는 객체로 이용될 수 있습니다.

연관성 (Relationship)

두 개 이상의 객체들이 상호 참조하는 관계를 말합니다. 종류로는:

• 연관화 (Association; is member of): 둘 이상의 객체가 상호 관련되어 있는 관계
• 분류화 (Classification; is instance of): 동일한 형 특성을 갖는 객체들을 모아 구성하는 것
• 집단화 (Aggregation, is part of): 관련 있는 객체들을 묶어 하나의 상위 객체를 구성하는 것
• 일반화 (Generalization, is a): 공통 성질로 추상화한 상위 객체를 구성하는 것
• 특수화 (Specialization, is a): 상위 객체를 구체화하여 하위 객체를 구성하는 것

객체지향 분석 (OOA; Object Oriented Analysis)

요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의해 모델링하는 작업으로, 클래스를 식별하는 것이 주 목적입니다. 개발 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나눠 분석하는 작업입니다.

객체지향 분석 방법론

• Rumbaugh(럼바우): 객체 모델, 동적 모델, 기능 모델로 나눠 분석함.
• Booch: 미시적(micro) 및 거시적(macro) 개발 프로세스를 모두 사용해 클래스와 객체를 분석하고 클래스를 정의함.
• Jacobson: 유스케이스(use case)를 강조하여 사용.
• Coad & Yourdon: E-R 다이어그램을 사용해 객체의 행위를 모델링. 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연ㅅ나과 메시지 연결 정의 등의 과정으로 구성.
• Wirfs-Brock: 고객 명세서를 평가해 설계까지 연속적으로 수행. 분석과 설계를 구분하지 않음.

객체지향 설계 원칙 (SOLID)

객체지향 설계에서 유지보수성과 확장성을 높이기 위한 다섯 가지 기본 원칙을 의미합니다. 각 원칙은 소프트웨어 모듈이 어떻게 설계되어야 하는지를 규정합니다.

단일 책임 원칙 (SRP; Single Responsibility Principle)

클래스는 하나의 책임만 가져야 하며, 클래스가 변경되는 이유는 오직 하나뿐이어야 한다는 원칙입니다.

• 예시: 하나의 클래스가 데이터베이스 접근과 UI 처리를 동시에 하지 않도록 분리.

개방-폐쇄 원칙 (Open/Closed Principle, OCP)

소프트웨어 요소는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다는 원칙입니다. 기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있도록 설계 되어야 합니다.

리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다는 원칙입니다. 자식 클래스는 부모 클래스의 기능은 수행할 수 있어야 하고, 이를 손상시키지 않고 확장만 수행해야 합니다.

인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 클라이언트가 사용하지 않는 메서드가 포함된 거대한 인터페이스 대신, 세분화된 여러 인터페이스를 제공.

의존 역전 원칙 (Dependency Inversion Principle, DIP)

고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다. 구체적인 클래스에 의존하지 않고 인터페이스나 추상 클래스에 의존하여 구현.

소프트웨어 개발 2: 소프트웨어 요구사항 개발

22 Jul 2024     #cs

요구사항 개발 (Requirements Development)

요구공학의 한 요소로, 개발 대상에 대한 요구사항을 체계적으로 도출하고 검증하는 일련의 구조화된 활동입니다.

• 요구공학 (Requirements Engineering): 소프트웨어 시스템의 요구사항을 식별, 문서화, 검증 및 관리하는 프로세스
• 요구사항 개발 과정 이전에 타당성 조사(Feasibility Study)가 진행되어야 합니다.

요구사항 개발 과정

도출 (Elicitation) → 분석 (Analysis) → 명세 (Specification) → 확인 (Validation)

• 요구사항 도출 (Requirements Elicitation): 사용자와 이해관계자로부터 요구사항을 수집하는 단계
• 요구사항 분석 (Requirements Analysis): 수집된 요구사항을 분석하여 중복되거나 충돌하는 요구사항을 해결하고, 우선순위를 정하는 단계
• 요구사항 명세 (Requirements Specification): 분석된 요구사항을 체계적이고 명확하게 문서화하는 단계 요구사항 확인 (Requirements Validation): 명세된 요구사항이 정확하고 완전한지 검토하고, 모든 이해관계자가 동의하는지 확인하는 단계

요구사항의 분류

• 기능 요구사항 (Fuctional Requirements): 시스템의 기능과 수행에 관한 요구사항. 시스템이 반드시 수행해야 하는 기능.
  • e.g. 어떤 것을 입/출력 하는지, 어떤 데이터를 사용하는지 등
• 비기능 요구사항 (Non-functional Requirements): 시스템 품질, 제약사항과 관련된 요구사항.
  • e.g. 장비 구성, 성능, 인터페이스, 테스트, 보안 등
  • 품질 요구사항: 가용성, 정합성, 상호호환성, 대응성, 이식성, 확장성, 보안성 등

요구사항 분석 (Requirement Analysis)

SW 개발의 첫 단계료, 개발 대상에 대한 요구사항을 이해하고 문서화하는 활동.

• 사용자 요구가 타당한지 조사, 비용과 일정에 대해 제약 설정.
• 사용자 요구를 정확히 파악해 목표 설정.

자료 흐름도 (DFD; Data Flow Diagram)

요구사항 분석에서 자료의 흐름, 변환 과정, 기능을 도형 중심으로 기술하는 방법.

• 버블 차트, 자료 흐름 그래프라고도 함.
• 구조적 분석 기법에 사용됨: 자료 흐름과 처리 중심.
• 구성 요소
  • Process (Bubble): 자료를 변환시키는 시스템의 부분(처리 과정). 처리, 기능, 변환, 버블이라고도 함.
  • Data Flow: 자료의 이동(흐름)이나 자료 간 연관관계.
  • Data Store: 자료 저장소(파일, 데이터베이스).
  • Terminator: 시스템과 교신하는 외부개체, 입력 데이터를 주고 출력 데이터를 받는 대상.
• 자료 사전 (DD; Data Dictionary): 자료 흐름도의 자료를 더 자세히 기록한 것.
  • 메타 데이터 (Meta Data)라고도 함: 데이터를 설명하는 데이터.
  • 자료 사전의 기호:
    • $=$: 자료의 정의, is composed of(~로 구성되어 있음)
    • $+$: 자료의 연결, and
    • $()$: 자료의 생략, Optional
    • $[]$: 자료의 선택, or
    • ${}$: 자료의 반복, Iteration of
    • $**$: 자료의 설명, Comment(주석)

요구사항 명세 기법

정형 명세 기법

수학적 원리를 사용해 요구사항을 표현하는 명세 기법.

• 작성 방법: 수학적 기호, 정형화된 표기법.
• 특징:
  • 정확하고 간결한 요구사항 표현.
  • 일관성이 있음 → 완전성 검증이 가능함.
  • 표기법이 어려움 → 사용자가 이해하기 어려움.
• 종류: VDM, Z, Petri-net, CSP 등

비정형 명세 기법

상태, 기능, 객체를 중심으로 자연어로써 요구사항을 표현하는 명세 기법.

• 작성 방법: 자연어나 다이어그램.
• 특징:
  • 자연어로 표현하므로 일관성이 떨어지고 해석이 달라질 수 있음.
  • 내용 이해하기 쉬움 → 의사소통 용이.
• 종류: FSM, Decision Table, E-R Model, SADT (State Chart), HIPO Chart 등

SADT (State Chart)

시스템 정의, 요구사항 분석, SW 설계를 위한 도구. SoftTech에서 개발.

• 블록 다이어그램을 사용해 구조적 요구 분석을 하는 자동화 도구.

HIPO (Hierachy Input Process Output)

시스템 분석, 설계, 문서화 시 시스템의 실행 과정인 입력, 처리, 출력의 기능을 표현한 것.

• 하향식 SW 개발을 위한 명세 도구.
• HIPO Chart: 시스템의 기능을 여러 모듈로 분할하여, 이들 간 인터페이스를 계층구조로 표현한 것.

요구사항 확인 방법

요구사항 검토 (Requirements Review)

요구사항 명세서의 결함(오류나 표준 준수 여부 등) 여부를 검토 담당자들이 일일이 분석하는 방법입니다.

• 동료 검토(Peer Review): 요구사항 명세서 작성자가 직접 내용을 설명하고, 동료들이 이를 들으면서 결함을 발견하는 방법
• 워크 스루 (Walk Through): 요구사항 명세서를 검토 회의 전 배포하여 사전 검토한 후, 짧은 검토 회의를 통해 결함을 발견하는 방법
• 인스펙션 (Inspection): 요구사항 명세서 작성자를 제외한 검토 전문가들이 명세서를 확인하며 결함을 발견하는 방법

프로토타이핑 (Prototyping)

요구사항을 정확히 파악하기 위해 견본품(Prototype)을 만들어 개발될 SW의 결과물을 예측하는 방법입니다.

테스트 설계

요구사항이 테스트 가능한지 여부를 확인하기 위해 테스트 케이스를 생성해 사용하는 방법입니다.

CASE 도구 활용

일관성 분석(Consistency Analysis)를 통해 요구사항 변경 사항 추적, 분석, 관리, 표준 준수 여부를 확인.

• CASE (Computer Aided Software Engineering)

소프트웨어 개발 1: 소프트웨어 개발 방법론과 생명 주기

22 Jul 2024     #cs

소프트웨어 공학 (SE; Software Engineering)

소프트웨어(SW)의 위기를 극복하기 위한 방안으로 연구된 학문입니다. SW의 품질과 생산성 향상을 목적으로 합니다.

• 기본 원칙
  • 현대적인 프로그래밍 기술을 사용해야 함.
  • SW 품질 유지를 위해 지속적으로 검증해야 함.
  • SW 개발 관련 사항 및 결과에 대한 기록을 유지해야 함.

소프트웨어 개발 방법론

SW 개발의 전체 과정을 체계적으로 계획하고 관리하기 위한 일련의 절차와 기법. 요구사항 수집, 설계, 구현, 테스트, 배포, 유지보수 등의 단계로 구성.

• 방식: 구조적 방법론, 객체지향 방법론, 애자일 방법론, 컴포넌트 기반 방법론 등.

구조적 방법론

정형화된 분석 절차에 따라 사용자 요구사항을 파악 및 문서화하는 프로세스(process) 중심의 방법론.

• 자료 흐름도 (DFD), 자료 사전 (DD), 소단위 명세서의 특징을 가짐.
• 목적: 이해가 쉽고 검증 가능한 프로그램을 만드는 것.
• 절차: 타당성 검토 → 계획 → 요구사항 → 설계 → 구현 → 테스트 → 운용/유지보수

컴포넌트 기반 방법론 (CBD; Component Based Design)

기존 시스템이나 SW의 컴포넌트를 조합해 새로운 애플리케이션을 만드는 방법론.

• 컴포넌트의 재사용(reusability)을 통해 시간 및 노력을 절감.
• 절차: 준비 → 분석 → 설계 → 구현 → 테스트 → 전개 → 인도

소프트웨어 개발 생명 주기 (Software Development Life Cycle)

SW 개발 과정을 각 단계별(설계, 운용, 보수 등)로 나눈 것. 개발 단계와 각 단계별 활동, 결과적 산출물로 표현.

폭포수 모형 (Waterfall Model)

각 단계를 확실히 끝내고 그 결과를 검토하여 승인한 뒤 다음 단계를 진행하는 모형.

• 이전 단계로 돌아갈 수 없음을 가정.
• 고전적 생명 주기 모형: 제일 오래되고 많이 사용되어 옴.

나선형 모형 (Spiral Model)

나선을 돌듯 여러 번의 개발 과정을 거쳐 점진적으로 최종 SW를 개발하는 모형.

• Boehm이 제안함.
• 과정: 계획 수립 → 위험 분석 → 개발/검증 → 고객 평가 → 처음부터 반복

애자일 모형 (Agile Model)

요구사항 변화에 유연하게 대응할 수 있게 일정한 주기를 반복하면서 개발하는 모형.

• 고객과 소통하여 빠르고 낭비 없게 개발하기 위한 방법론을 통칭하는 말.
• 핵심 가치: 개인과 상호작용, 실질적인 SW, 고객과의 협업, 변화에 대한 반응
• 대표적 모형: 스크럼(Scrum), XP(eXtreme Programming), Kanban, Lean, FDD(Feature Driven Development; 기능 중심 개발)

스크럼 (Scrum)

애자일 방법론의 일종으로, 팀이 반복적이고 점진적으로 작업을 수행하며 일정한 기간 내에 가치를 전달할 수 있도록 돕는 프레임워크.

• 프로세스:
  • 스프린트 계획 회의 (Sprint Planning Meeting): 제품 백로그 중 이번 스프린트에서 작업할 내용을 가지고 단기 일정을 수립하는 회의
  • 스프린트 (Sprint): 실제 개발 과정. 보통 2-4주 기간에서 진행.
  • 일일 스크럼 회의 (Daily Scrum Meeting): 모든 팀원이 매일 15분 여동안 진행 상황을 점검하는 회의. 남은 작업은 소멸 차트(Burn-down chart)에 표시함.
  • 스프린트 검토 회의 (Sprint Review): 부분/최종 완성 제품이 요구사항에 부합하는지 테스트하는 회의.
  • 스프린트 회고 (Sprint Retrospective): 규칙 준수 여부 및 개선점을 확인하고 기록.

XP (eXtreme Programming)

고객의 요구사항에 수시로 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법.

• 짧고 반복적인 개발 주기, 고객의 적극적 참여로 빠른 SW 개발을 목적으로 함.
• 핵심 가치: 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
• 주요 실천 방법 (Practice):
  • Pair Programming: 함께 프로그래밍함으로써 개발에 대한 책임을 공동으로 가짐.
  • Collective Ownership: 개발 코드에 대한 권한과 책임을 공동으로 소유.
  • Test-Driven Development: 코딩 전 테스트 케이스를 먼저 작성하여 해야할 일을 명확히 파악함. 자동화된 테스트 도구(구조, 프레임워크)를 사용하여 테스트를 지속적으로 실시함.
  • Whole Team: 개발에 참여하는 모든 구성원(+고객)은 각자 역할이 있고, 그에 대한 책임을 가짐.
  • Continuous Integration: 모듈 단위로 개발된 코드는 작업이 마무리될 때마다 지속적으로 통합됨.
  • Refactoring: 프로그램 기능을 변경하지 않고 시스템을 재구성함. 프로그램을 쉽게 이해/수정하여 빠르게 개발하기 위해서.
  • Small Release: 릴리즈 기간을 짧게 반복하여 고객 요구 변화에 신속히 대응.