[소프트웨어공학] - 6주차 : 설계 (1)

요구분석 vs 설계

: 요구분석은 사용자의 요구 사항을 토대로 요구분석 명세서를 작성하는 것으로, 상대적으로 개념적/추상적이다. 이는 사용자의 요구를 'What' 관점에서 바라본다. 설계는 상대적으로 구체적이며, 분석 단계에서 고려하지 않은 상세 내용을 반영하여 구현할 수 있는 수준으로 준비한다. 요구분석 단계에서 파악한 비기능적 요구 사항, 제약 사항을 고려하고, 운영체제 등의 플랫폼을 결정하는 등 구체적인 설계서를 작성한다. 이는 'How' 관점에서 바라본다.

 

: 설계자는 다양한 제약 조건을 만족시킬 수 있는 최적의 설계안을 만들고, 설계를 평가할 기준도 정량적으로 명시해야 한다. 좋은 설계를 위해선, 설계서는 요구분석명세서의 내용을 모두 포함해야 하며, 유지보수가 용이하도록 추적이 가능해야 하고, 변화에 쉽게 적응할 수 있어야 하며, 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 한다. 또한 설계서는 읽기 쉽고 이해하기 쉽게 작성해야 한다. 

 

 

설계의 종류

: 먼저 상위 설계(예비 설계)로, 구조 설계, DB 설계, 인터페이스 설계 등이 있다. 다음 하위 설계는 각 모듈의 실제 내부를 알고리즘(pseudo-code) 형태로 표현하며, 인터페이스에 대한 설명, 자료구조, 변수 등에 대한 상세한 정보를 작성한다. 

 

 

설계의 방식

: 프로세스 지향 설계는, 업무의 처리절차를 중심으로 설계의 구성 요소들을 구분한다. 어떠한 절차를 걸쳐서 작업을 수행하는가, 어떠한 입출력 자료를 생성하는가에 초점을 맞추며, 기능과 데이터가 노드를 이루고 이들 간의 관계를 형성한다. 객체 지향 설계는, 시스템의 실제 객체 요소를 중심으로 설계한다. 객체를 정의하고 이들이 상호작용의 기본이 되도록 설계하며, 객체들이 노드를 이루고 이들 간의 관계를 형성한다. 

 

 

설계의 원리 - 분할과 정복

: 규모가 큰 문제를 작은 규모의 모듈로 분할하는 것이다. 모듈로 나누면 모듈끼리 소통하는 방법이 필요하므로, 무작정 작게만 쪼개면 소통으로 인해 오히려 복잡도가 증가할 수 있다. 따라서 설계자는 복잡도와 처리의 용이성을 고려하여, 어느 수준으로 쪼갤지를 결정해야 한다. 

 

 

설계의 원리 - 추상화

: 필수 정보만 추출하여 강조하고, 관련없는 세부 사항을 생략함으로써 본질적인 문제에 집중하는 작업이다. 복잡한 현상을 간단히 이해할 수 있게 하며, 문제의 핵심 및 본질을 이해할 수 있다. 추상화는 과정 추상화, 데이터 추상화, 제어 추상화가 있다. 과정 추상화는 주어진 문제에 대해 프로그래밍하기 전에 상세 부분은 생략하고, 전체 흐름만 파악할 수 있는 알고리즘 형태로 작성한다. 데이터 추상화는 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법으로, 예시는 클래스가 있다. 제어 추상화는 프로그래밍 언어에서 쓰는 제어구조를 추상화 하는 것이다. 기계어, 어셈블리어, 고급 언어 순으로 추상화 수준이 높아진다. 

 

 

설계의 원리 - 캡슐화

: 사용자에게 해당 객체의 기능(서비스)과 사용법만 제공하고, 내부는 함부로 변경할 수 없게 감추는 개념이다. 캡슐화는 추상화를 통해 문제를 쉽게 개념화할 수 있으며, 메서드의 기능만 알면 객체를 쉽게 사용할 수 있다. 또한, 객체 내부의 자료구조를 변경해도, 사용자에게 영향을 주지 않는다. 다른 모듈의 구현 내용은 자세히 알 필요가 없으므로 사용자가 모듈을 이해하기 쉬우며, 모듈 내의 알고리즘을 변경하기 쉬워 기능 추가가 쉽다.

 

 

설계의 원리 - 정보은닉 & 상속

: 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법이다. 다른 객체가 한 객체 내의 데이터 값을 직접 참조하거나 접근할 수 없어서 친구끼리 대화를 하듯 메서드를 통해 객체에 요청해서 값을 넘겨받아야 한다. 대표적으로 접근 제어자가 있다. 공개(+, public)는 같은 시스템에 있는 모든 클래스가 접근할 수 있으며, 은닉(-, private)은 같은 시스템 내의 다른 클래스가 직접 접근할 수 없고, 해당 클래스의 메서드를 통해서만 접근할 수 있다. 부분 공개(#, protected)는 다른 클래스가 접근할 수 없고, 해당 클래스의 메서드와 클래스를 상속받은 하위 클래스만 접근 가능하다. 

 

 

설계의 원리 - 다형성

: 어떤 객체의 속성이나 기능이 상황에 따라 여러 가지 형태를 가질 수 있는 성질로, 오버로딩과 오버라이딩이 있다. 오버로딩은 연산자 오버로딩(+, -, ... )과 매서드 오버로딩(같은 매서드명, 다른 매개변수 타입 등)이 있다. 오버라이딩은 상위 클래스에서 정의한 메서드는 무시하고, 하위 클래스에서 다시 정의해 사용한다. (리스코프 교체 원칙)

 

 

UML (Unified Modeling Language) & Modeling

: UML은 객체 지향 프로그램 설계를 표현하기 위해 사용하는 표기법으로, 설계단계 뿐만 아니라 요구분석, 구현 단계에서도 사용 가능하다. 개발자간 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어로, 시스템 가시화, 명세화, 문서화를 목적으로 한다. Modeling은 요구사항에서 발생한 도메인을 체계화하는 과정으로, 중요한 개념과 특성, 개념들 사이의 관계를 파악해 다이어그램으로 정형화 하는 것이다. 참고로 절치 지향 모델링은 시스템의 처리 과정을 자료의 흐름에 중점을 두어 기술하는 것으로, 유지 보수가 어려우며, 코드의 순서가 바뀌면 동일한 결과를 보장하기 어렵다.

 

 

UML Modeling의 필요성

: (1) 개발자가 자신의 설계 결과물을 다른 사람과 효과적으로 주고 받으며 공유 할 수 있는 메커니즘을 제공한다. (2) 개발자가 자신의 Vision을 구축하고 반영하는 데에 있어서 표준화되고 이해하기 쉬운 방법으로 할 수 있도록 도와준다. (3) 즉, 시스템을 가시화 하고, 설계 단계에서 일관된 해석을 유지하기 위함이다.

 

 

UML Modeling의 구성요소

: (1) 사물로, 다이어그램 안에서 관계가 형성될 수 있는 대상이다. 구조 사물은 모델의 정적인 부분들을 정의하고, 시스템의 개념적 요소를 표현하며, 클래스, 유스케이스, 컴포넌트, 노드 등이 있다. 행동 사물은 모델의 동적인 부분들을 정의하고, 시간과 공간에 따른 요소들의 행위를 표현하며, 상호작용, 상태머신 등이 있다. 그룹 사물은 요소들을 그룹으로 묶어서 표현하며, 패키지 등이 있다. 주해 사물은 부가적인 설명이나 제약조건 등을 표현한다. 

 

: (2) 관계로, 사물과 사물 사이의 연관성을 표현한다. 의존 관계는 두 사물 간의 의미적 관계로, 한 사물의 명세가 바뀌면 다른 사물 에 영향을 준다. 연관 관계는 객체 사이의 연결관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있다. 일반화 관계는 일반화된 사물과 더 특수화된 사물(한가지 종류) 사이의 관계이다. 실체화 관계는 사물이 할 수 있거나 해야하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계이다. 

 

: (3) 다이어그램으로, 사물과 관계를 도형으로 나타낸 것이다. 구조적 다이어그램은 정적 모델링으로, 여기에는 클래스 다이어그램, 오브젝트 다이어그램, 컴포넌트 다이어그램 등이 있다. 클래스 다이어그램은 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 나타내며, 오브젝트 다이어그램은 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현한다. 행위 다이어그램은 동적 모델링으로, 시퀀스 다이어그램, 상태 다이어그램, 활동 다이어그램 등이 있다. 실제 프로젝트에서는 개발할 소프트웨어 특성에 맞게 3~5개의 다이어그램을 작성한다. 

 

 

UML Modeling의 장단점

: 장점으로 (1) 추상화하여 표현하기 때문에 중요한 측면에 집중할 수 있으며 (2) 재사용성과 유지보수성이 좋으며 (3) 오류 감소 및 품질 향상 (4) 협업과 커뮤니케이션이 있다. 단점으로 (1) 과도한 상세성으로 인한 복잡도 증가 (2) 다양한 다이어그램이 존재하므로 선택지가 혼란될 수 있으며 (3) 특정 UML 도구나 소프트웨어를 사용하면 비용이 발생하고 도구 의존성 문제가 있다.

 

 

UML Modeling 과정

: (1) 유스케이스 다이어그램 작성 (2) 클래스 후보 선정 및 개념적 초기 클래스 다이어그램 작성 (3) 유스케이스 다이어그램과 초기 클래스 다이어그램을 기초하여 시퀀스 다이어그램 작성 (4) 클래스 사이의 관계를 찾아 객체 모형 완성 (5) 상태 다이어그램이나 액티비티 다이어그램을 추가해 UML 모델 완성한다.

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 클래스 다이어그램 정의 및 기초

 

: 분석되거나 설계되는 모든 클래스를 다이어그램으로 나타낸 것으로, 클래스의 정적인 정의와 관계를 표현한다. 요구 분석 단계에서 도출한 유스케이스 다이어그램을 기초로 하여 클래스를 찾고, 해당 클래스의 속성 및 클래스 간의 관계를 찾은 뒤, 최종적으로 클래스 다이어그램을 작성한다. 하나의 클래스는 오른쪽 사진과 같이 박스 형태로 그리며, 가장 위에는 클래스명, 중간에는 속성, 아래에는 메서드를 작성한다. 속성은 (+, #, -, /) (변수명) : (타입)으로 작성한다. 이때, +는 public, #은 protected, -는 private, /는 derived를 의미한다. 참고로 언더바 표시는 정적 변수를 의미한다. 메서드는 (+, #, ...) (매서드명) (매개변수명: 타입): (리턴타입) 형식으로 작성한다. 리턴 타입이 void면 생략 가능하다. 

 

: 장점으로는 유스케이스 다이어그램 보다 설계관점에서 더욱 구체적이며, 클래스 간 인터 페이스를 빠르게 명확하게 알 수 있고, 클래스, 인터페이스, 관계 등이 표시가 되어있어 향후 개발 단계에서 중요한 도구로 사용된다는 것이다. 단점으로는 너무 상세한 내용을 기입하면 구현단계에서 할 일이 미리 이루어지는 오류를 범할 수 있고, 동적인 관점에 대한 해석이 불가능하다.

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 클래스 다이어그램 관계

: (1) 상속 관계는 한 클래스가 다른 클래스의 포함하는 상위 개념인 경우에 사용하며, 클래스인 경우에는 일반화 관계, 인터페이스인 경우에는 실체화 관계로 표현한다. 일반화 관계는 클래스와 클래스 간의 관계로, 속성과 기능을 공유하며, 'is-a' 관계이다. 실체화 관계는 인터페이스와 클래스 간의 관계로, 인터페이스에서 행동만 정의하고, 클래스에서 직접 구현하며, 'can-do' 관계이다.

 

: (2) 연관 관계는 한 클래스가 다른 클래스를 참조하거나, 양쪽이 서로를 참조하는 등 두 클래스가 서로 개념상 연결이 된 경우에 사용한다. 즉, 서로 독립적인 개체지만 관계가 있을 때 사용한다.

 

(3) 집합 관계는 연관 관계의 한 종류로, '부분-전체' 관계이며, 부분은 독립적으로 존재할 수 있다. (4) 합성 관계는 '부분-전체' 관계지만, 부분이 전체에 종속된다. 사용자의 요구에 따라 부분을 전체와 독립적이게 할 것인지, 종속적이게 할 것인지 달라질 수 있다. 

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 클래스 다이어그램 다중성

1	정확히 1개	무조건 하나 있어야 함
0..1	0개 또는 1개	있어도 되고, 없어도 됨
* 또는 0..*	0개 이상 (제한 없음)	아무 것도 없어도 되고, 여러 개도 가능
1..*	1개 이상	최소 하나는 있어야 함
n..m	최소 n개 ~ 최대 m개	정해진 범위 내에서 가질 수 있음

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 클래스 다이어그램 예시

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 클래스 다이어그램 예시

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 클래스 다이어그램 예시

 

 

UML Modeling - 구조적 다이어그램(정적 모델링) - 오브젝트 다이어그램

: