패턴 저자 : 손영수, 오혜성, 양현철, 정승수

아키텍쳐 시각화 패턴 I 회에서는  아키텍처 시각화 패턴의 전체적인 구조와 구성되는 패턴들의 종류들을 간단히 소개하고, 아키텍처 시각화를 하기 전에 소프트웨어 시스템을 분석하기 위한 기본 요소들인 Domain Level Classifier Pattern과 Class Dependency Classifier Pattern에 대해서 살펴보았다. 2회에서는 시간에는 소프트웨어 시스템의 아키텍처적인 분석에 기본이 되는 다양한 Metric 분석과 관련된 패턴에 대해서 설명하고자 한다

Base Metric Extractor Pattern의 정의

소프트웨어 시스템의 아키텍처를 분석하기 위하여 의존성만을 이용하게 되면 분석의 시야가 좁아 보다 다양한 측면에서의 분석이 힘들어진다. 그리고 의존성만을 시각화한 Chart로는 상호 참조와 같은 아키텍처적인 문제만을 바로 확인할 수 있고 그 외의 소스 코드의 크기나 복잡성 등과 관련된 문제들은 확인할 수 있는 방법이 존재 하지 않는다. 의존성 분석만으로는 파악할 수 있는 아키텍처적인 문제들의 한계가 존재한다. 그렇기 때문에 이를 보완할 수 있는 다른 분석 방법들이 필요하다. 또한 이를 보완할 분석 방법도 매우 직관적이고 명시적으로 분석할 수 있어야 하며, 매우 빠른 시간에 아키텍처를 파악할 수 있어야 한다.

이때 소프트웨어 메트릭이라는 소프트웨어 시스템의 품질을 나타내는 지표를 이용하면 이 문제를 해결할 수 있다. 이 지표는 소프트웨어의 측정 기술을 기반으로 소프트웨어 생명 주기 동안에 소프트웨어의 특징 또는 특성을 객관적이고 과학적인 수치로 정량화한 지표이다. 또한, 다양한 문제점들을 정의하고, 관련된 기초 데이터를 수집하고, 문제점들을 객관적이고 과학적인 수치에 의해 분석하여 다양한 문제점들의 연관 관계 및 해결 방법을 탐색하며, 다양한 문제점들을 종합적으로 해결할 수 있는 문제 분석 프로세스 및 소프트웨어에 대한 지표이다.

이러한 지표들 중에서 품질 향상에 많은 도움을 줄 수 있는  소프트웨어 메트릭의 종류를 크게 4가지가 존재한다.

  • 첫번째로 단순히 패키지, 클래스, 메소드, 필드의 갯수,  코드 라인 수를 나타내는 “Count Metric”,
  • 두번째로 코드내의 순환복잡도, 무거움, 엉킴을 나타내는 “Complexity Metric”,
  • 세번째로 코드 간의 의존성을 나타내는 “Robert C. Martin Metric”,
  • 마지막으로 코드간의 상속을 수치로 나타내는 “Chidamber & Kemerer Metric”

이러한 메트릭을 통해 다음과 같은 이점을 얻을수 있다.

  •  소프트웨어 시스템의 코드를 정량적으로 분석이 가능하다.
  • 소프트웨어 시스템의 품질을 수치화 시키기 때문에 객관적인 분석이 가능하다.
  • 소프트웨어 시스템의 문제를 직관적으로 파악할 수 있다.
  • 소프트웨어 시스템을 다양한 시각으로 분석할 수 있게 된다.

계속 읽기

지표란 직접 경험을 하지 않아도 현재의 상황을 알수 있는 도구를 말합니다. 옛날 제주도에서는 식수가 귀해 빗물을 식수로 사용을 했습니다.  빗물의 오염도를 파악하기 위한 지표로, 개구리 (숫놈끼리만 넣거나, 암놈끼리만 넣거나)들을 넣었다고 합니다.

개구리 들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며, 또한 개구리의 생존 여부로 물 오염도를 파악을 할수 있기 때문입니다.

일전에 소프트웨어 품질을 판단하는 지표로,  1000 피트의 뷰 라는 글을 소개해 드렸습니다.    너무 상세하지도 않고, 너무 추상화되어 있지도 않은 그 사이의 뷰를 1000 피트의 뷰라고 불렀습니다.

이러한 지표중 하나로, 예전 저의 포스트에서  Dependency Structure Matrix (DSM) 을 소개해 드렸습니다.

이번 포스트는 이러한 연장선상으로 Clean Code로 유명하신 Robert C. Martin (줄여서 Uncle. Bob)님이  만드신 Instability/Abstractness Graph 하나를 설명해 드리고자 합니다. (이 그래프에 대해 국내에 명확하게 소개된 자료가 없어서,  꼭 여러분에게 공유를 해드릴려고 합니다. )

이 포스트를 읽기 이전에  Bob 삼촌이 발표하신 패키지 구조의 원칙들(Principles of Package Architecture) 을 읽어보시거나, 또는 저의 이전 포스트인 Dependency를 관리하는 방안 을 읽어보시길 바랍니다.

그림 1. Bob 삼촌의 – Instability , Abstractness 그래포

 Uncle Bob의 지표는  Instability와 Abstractness 두 개에 대해 이해를 하셔야 합니다.  물론 여기에 추가적인 지표를 더한 변종(Variant) 들도 있지만, 이 두 가지 개념을 확실히 이해하실 필요가 있습니다.

계속 읽기

이 분은 Object Mentor 의 리더이자,  Clean Code의 저자인 Bob 삼촌 (Uncle Bob – Robert C. Martin) 의 글이 “모든 프로그래머가 알아야할 97가지” 에 실려 있습니다.

저도 사실 뭔가 재미난 이야기를 해 줄거라고 했는데… 저희에게 너무나도 익숙한 객체지향의 중요한 원칙인   SOLID 의 S인 SRP를 이야기를 하셨네요.

익숙하지만 정말 중요한 원칙인 SRP 이야기를 다시 한번 들어보시길 바랍니다.

Single Responsibility Principle written by Uncle Bob

좋은 설계를 위한 가장 기본적인 원칙 중 하나는 다음과 같습니다.

동일한 이유로 변경되는 것들은 함께 모으고, 서로 다른 이유로 변경되는 것들은 분리시킨다.

이 원칙은 종종 단일 책임의 원칙(Single Responsibility Principle, SRP)이라고도 알려져 있습니다.   한마디로 말해서, 하나의 서브시스템, 모듈, 클래스, 또는 심지어 함수에 대해서도 한 가지 이상의 변경 이유가 있어서는 안 된다는 것을 의미합니다.

계속 읽기

일전에 Dependency에 대한 고찰이라는 글로, Dependency의 종류와 xDepend 툴들을 소개한 적이 있습니다.

이번 POST는 윗 글의 연장선상으로 Dependency 를 해결하기 위한 올바른 설계 방법 몇가지를 소개하고자 합니다.

물론 재미난(?) 그래프로 여러분의 시스템의 Depedency를 파악하는 것을 보여드리고 싶지만..  모든 일에는 순서가 있는 법.  여러분이 와 닿는 그림과 코드로 간단히 설명드리도록 하겠습니다.

Dependency가 없는 상태로 시스템을 구축한다는 것은 불가능합니다. 재사용의 미덕이 바로 Dependency의 또다른 이름이기도 하죠.

어떻게 하면 Dependency를 잘 관리할수 있을까?  그 해답을 제시해주신  아키텍트를 소개하고자 합니다.

그 분은 바로 Object Mentor의 Robert C. Martin 입니다.  Clean Code의 저자로써 알려져 있지만, 사실 이것보다  이름을 더 크게 알리게 한 주역은 패턴의 5가지 법칙(OCP, DIP, LIP, ISP, SRP)입니다.

그런데 이 5원칙의 빛에 가려 숨겨진 Principle이 하나 있는데요.  이름하여 패키지 구조의 원칙들 (Principles of Package Architecture) 입니다.

이 논문에서 Dependency를 깨거나 완화하는 방법들을 여러분에게 소개하고자 합니다.

계속 읽기