[객체지향개발론] OOAS와 SSAD의 차이

이번 포스팅은 OOAD와 SSAD에 대한 정리 글이 될 것이다.

OOAD는 Object-Oriented Analysis & Design(객체 지향 분석 및 설계)란 뜻으로 

객체 지향 프로그램을 위한 소프트웨어 개발 방법론이다.

간단히 OOA(객체 지향 분석)와 OOD(객체 지향 설계)가 합쳐진 형태라고 생각하면 된다.

OOA : 사물이나 컨셉을 설명하거나 찾아내는 것. 

즉, 요구사항을 찾아내고, 그 속의 객체들의 목록을 찾아내는 것이다.

OOD :  소프트웨어 오브젝트(* 데이터와 함수로 구성된 것)를 정의하고, 

이들이 어떻게 협력하며 요구사항을 만족시키는지 정의하는 것. 

즉, OOA를 통해 찾아진 객체들 간의 관계를 설정하는 것이다.

이 OOA와 OOD가 합쳐진 방식이 OOAD 이다.

핵심은 소프트웨어를 구성하는데 있어서 필요한 기능, 그 기능에 따른 클래스, 클래스들 간의 관계 설정 등의 요소를 파악해 

실수나 시행착오를 줄이고 최단시간에 성공적으로 소프트웨어를 완성하려는 것이다. 

더 간단히 표현하자면 어떤 클래스를 어떻게 사용해서 소프트웨어를 구성할 것인지를 기술해내는 것이 객체지향 분석설계의 주된 내용이다.

OOAD의 과정은 다음과 같다. 

[Define use cases] - [Define domain model] - [Define interaction diagrams] - [Define design class diagrams]

1) Define use cases 는 한마디로 '사용법 정의'를 의미한다.

개발자의 입장이 아닌 사용자의 입장에서 사용법을 기술하는 것으로 만들고자 하는 프로그램의 기능이 드러나도록 하는 단계다.

사용자와 시스템간의 상호작용을 순서대로 상세하게 기술하되 겉으로 보여지는 것만을 쓴다.

이 단계에서 시스템 내부의 상태나 개발자의 입장이 포함되지 않도록 하는 이유는

분석단계에서 개발자의 의도가 요구사항에 반영된다면 분석결과가 잘못된 방향으로 오도될 수 있기 때문이다.

  개발자의 의도가 아니라 요구사항이 충실히 반영되도록 작성되어야 하니 주의하자.

2) Define domain model 은 한마디로 '문제영역의 시각화'를 의미한다.

구현에 들어가기 전 개념적 클래스(domain)을 시각화 하는 단계다. 

내가 어떤 클래스를 사용하고, 그 클래스에 무슨 속성을 두고, 각 클래스들 간의 연관 관계를 시각화하는 것이다.

거기에 이런 소프트웨어 내부적인 관계 뿐만아니라 외부, 즉 하드웨어나 사용자간의 관계도 시각화할 수 있다.

시각화 단계는 다음과 같다.

1. 개념 클래스 카테고리 리스트와 현재 요구사항에 관련한 명사 식별 테크닉을 이용하여 후보 개념 클래스를 나열한다.

2. 도메인 모델을 후보 개념 클래스를 그린다.

3. 메모리를 유지해야 할 필요가 있는 관계를 나타내기 위해 필요한 연관관계를 추가한다.

4. 자료 요구사항을 만족시키기 위해 필요한 속성을 추가한다.

이때 클래스에서 정보가 겹치지 않도록 주의해야 한다.

그 이유는 아래 예시와 같다.

[출처 : https://jhkang-tech.tistory.com/48 ]

위 예시처럼 한 클래스가 삭제되면 모든 데이터가 삭제되는데, 이를 막기 위해 클래스를 분할해야한다.

여기(1~2)까지가 OOA에 해당하는 단계다.

아래(3~4)는 OOD에 해당하는 단계다.

3) Define interaction diagrams 는 한마디로 '오브젝트 커뮤니케이션 시각화' 이다.

오브젝트(객체)간에 주고받는 메시지의 교환(메시지 파싱)을 모델화하는 것이다. 

즉, 앞서 OOA 단계에서 구상한 것을 바탕으로 Body(몸체)를 만드는 것이다.

상호작용 다이어그램(interaction diagram)에는 협력 다이어그램과 시퀀스 다이어그램이 있다.

협력 다이어그램은 아래 링크를

https://t1.daumcdn.net/cfile/tistory/126433114BE7623211

시퀀스 다이어그램은 아래 주소를

https://thinking-jmini.tistory.com/29

참고하면 좋다.

4) Define design class diagrams 는 한마디로 '본격적인 클래스 디자인'을 말한다.

그동안 시각화 해온 클래스 관계를 통해 실제로 사용될 클래스를 정의한다.

클래스에 무슨 객체를 두고, 어떤 함수를 둘 것인지를 설정하는 것이다.

관련 내용은 https://jisunglab.tistory.com/170 이 링크를 참고하는 것이 좋다.

OOAD 의 장점과 단점은 다음과 같다.

 장점 

1. 정교한 디자인 가능. 

2. 유지보수와 재사용성이 뛰어남. 

3. 기능 확장이 용이함. 

4. 상세한 구현법의 명시가 가능. 

단점 

1. 복잡성 (전체적인 맥락 파악 힘듦) 

2. 명시할 유스케이스 범위 정의에 따른 어려움. 

3. 디자인에 많은 시간 소요. 

복잡하고 대형화되는 소프트웨어를 정교하게 개발하기에 적합한 방법이라 생각된다. 

***

객체 지향 프로그래밍에 사용되는 OOAD와 반대로 SASD는 절차적 프로그래밍(Procedual Programming)에 사용된다.

Structured Analysis & Structured Design(정형 분석 및 정형 디자인)의 약자로 절차적 프로그래밍의 기본형이다.

SASD 는 자료의 기본적인 특성이나 자료구조를 먼저 정의하고, 나중에 프로그램 절차를 유도하 는 방법으로써 변환되는 작업에 크게 영향을 받지 않고 시스템 설계가 가능한 기법이다. 

자료흐름도(DFD)와 자료사전을 바탕으로 구조도를 유도하는 기능 지향적 개발론 이라고도 표현. 

OOAD와 달리 큰 틀에서 작은 틀로의 기능을 나누며 설계를 하는 Top-Down*)의 형태로 진행되어 보다 직관적인 설계가 가능하다는 것이 장점이다. 

* Divide & Conquer(분할 후 정복) 방식 : 어떠한 문제를 작은 단위로 나누고 그것이 해결하기에 충분히 작으면 풀고, 아니면 더 쪼개는 방식 -> 재귀방식으로 알고리즘을 풀기에 Top-Down 접근이라고도 한다.

하지만 OOAD 와는 달리 모듈들간의 상호 독립성이 강하지 못하여 시스템의 수정이 요구될 때 에 대대적인 수정을 해야 하는 등의 어려움이 크기 때문에 부서 단위 정도의 프로그램은 가능하지만 대규모 응용 프로그램의 개발엔 적합하지 않다고 볼 수 있습니다. 

[설계 절차 -데이터흐름도 작성 -구조도표 작성 -모듈 설계 -데이터베이스 설계 -설계의 통합화 ]의 단계로 이루어져 있으며.

아직까지도 직관성에 의해 많이 사용되고 있는 개발방법으로 

주로 임베디드 시스템이나 로봇제어 등 하드웨어와 연동되는 프로젝트에 적합하다. 

 SASD 의 장점과 단점은 다음과 같다. 

장점 

1. 직관적인 설계 방법. 

2. Input 과 Output, 그리고 기능의 명확한 정의에 따른 쉬운 이해. 

3. 일괄처리 방식의 자료변환용 소프트웨어 개발에 적합. 

단점 

1. 데이터가 정보 은닉되지 않음. 

2. 유지보수 및 재사용 성이 낮음. 

3. 대규모, 복잡한 소프트웨어 개발에 비효율적.