PLoP이 드디어 20주년을 맞이 했습니다.

20주년 행사인 만큼, 초기 패턴을 이끌었던 맴버들이 대거 참석한다는 것이고, 가장 먼저 PLoP 이 열렸던 성지인 Allerton Park에서 열립니다. 책에서 본 그곳에서 책에서나 보는 대가들과 만난다니 기쁘네요.

  • Ralph Johnson
  • Ward Cunningham
  • Rebecca Wirfs_Brock
  • Joseph Yoder
  • Richard Gabriel
  • Joshua Kerivsky

계속 읽기

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

아키텍쳐 시각화 패턴 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”

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

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

계속 읽기


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

소프트웨어 시스템에 있어서 아키텍처는 소프트웨어의 개발이 진행 되면서 지속적으로 성장해 나가며, 고객의 다양한 요구 사항들을 수용할 수 있도록 변화에 대응할 수 있어야만 한다.  높은 품질을 가지는 소프트웨어 시스템을 개발하기 위해서는 계속 진화하는 소프트웨어 시스템의 아키텍처를 실시간으로 확인할 수 있어야 한다. 그러나 현재 알려진 기본적인 방법들로는 이러한 아키텍처 파악이 매우 힘든 것이 현실이다. 그래서 이번에는 소프트웨어 시스템의 아키텍처를 시각화 할 수 있는 다양한 방법들을 패턴으로서 이야기 하고자 한다.

소프트웨어 시스템의 아키텍처는 다양한 사람들이 참여하여 개발하게 되면 처음 의도와는 다른 방향으로 바뀌어질 가능성이 존재하며, 이에 따라서 원치 않았던 잠재적인 아키텍처의 문제들이 발생하거나 추후 확장 가능한 유연한 아키텍처에서 멀어지는 상황이 발생하게 된다. 이러한 상황을 방지하려면 개발을 진행하고 있는 소프트웨어 시스템의 아키텍처를 자주 살펴보고 문제가 발생될 수 있는 부분들을 개선해나가야만 한다.

이러한 소프트웨어 시스템의 아키텍처를 파악하기 위한 방법들은 일반적으로 클래스 다이어그램을 분석하거나 소스 코드를 분석하여 파악하는 방법들이 존재한다. 그러나 이러한 방법들은 여러 단점들을 가지고 있는데 클래스 다이어그램을 기반으로 분석하는 방법의 경우 너무 넓은 시점에서 소프트웨어 시스템을 분석하기 때문에 정확한 아키텍처를 파악하기도 힘들며, 아키텍처적인 문제들을 해결하기에는 너무 적은 정보를 제공한다. 그리고 코드 기반 분석은 클래스 다이어그램 기반 분석과는 달리 너무 작은 시점에서 소프트웨어 시스템을 분석하기 때문에 아키텍처를 파악하는 것이 힘들고, 분석하는 것도 너무 많은 시간이 걸리게 된다. 이렇게 기존의 쉽게 접할 수 있는 방법들로는 소프트웨어 시스템의 아키텍처를 파악하기란 매우 어렵다고 할 수 있다.

그래서 여기에서는 소프트웨어 시스템의 아키텍처를 보다 간편하게 분석할 수 있도록 도와주는 아키텍처 시각화 기법들을 패턴으로써 정리하여, 해당 시각화들을 구현하기 위한 기본적인 방법들을 소개하고, 각각의 시각화 패턴을 활용한 분석들의 장점과 단점들을 소개할 것이다.

아키텍처 시각화 패턴을 위한 로드 맵

앞서 이야기 했던 아키텍처 분석 방법들은 소프트웨어 시스템을 너무 넓은 범위에서 보거나, 너무 좁은 범위에서만 보기 때문에 다양한 문제들이 발생 하였다. 그렇기 때문에 적절한 수준에서 소프트웨어 시스템을 바라보게 되면, 앞서 이야기했던 방법들에서는 찾을 수 없었던 문제점들을 바로 확인할 수 있게 된다. 이러한 적절한 수준으로 사용할 수 있는 분석 방법은 바로 소프트웨어 시스템의 다양한 Metric 정보(소프트웨어 시스템에 대한 아키텍처적인 수치 정보)와 구성요소(도메인)들의 의존성을 분석하는 것이다. 이 방법을 이용하게 되면 소프트웨어 시스템의 아키텍처에 대한 정보들과 여러 문제점들을 다양한 수치 정보로서 바로 파악할 수 있게 되며, 의존성 분석을 통해 얻은 정보로는 실제 소프트웨어 시스템의 아키텍처적인 의존성을 보여주기 때문에 아키텍처 분석이 더욱 용이해지고, 상호 참조와 같은 아키텍처적인 문제점을 찾기에 용이해진다.

하지만 이러한 Metric 정보와 소프트웨어 시스템의 도메인들의 의존성을 분석하기만 하여서는 직관적이고 명시적인 분석결과를 얻을 수 없으며, 전체적인 분석 또한 빠른 시간 안에 할 수 없다. 그렇기 때문에 이러한 문제들을 해결하기 위해서는 Metric 정보와 도메인들의 의존성을 분석 정보들을 단순히 제공하는 것이 아닌 정보들을 시각화하여 분석 하고자 하는 사람이 쉽게 이해할 수 있는 다양한 Chart를 활용하는 형태로 분석 결과를 제공 해야만 한다.

이러한 아키텍처 시각화 기법을 사용하게 되면 코드 분석이나 클래스 다이어그램 분석에 비하여, 초기 비용(시각화 환경 구성 등)이 많이 필요하지만, 소프트웨어 시스템의 아키텍처를 보다 빠르게 분석할 수 있게 되며 잠재적인 아키텍처적인 문제점들을 미리 예방할 수 있도록 도와주며, 더 나아가 아키텍처를 확장 가능한 아키텍처로 유지할 수 있도록 도와주어, 고객의 요구 사항에 쉽게 대응할 수 있도록 해주게 된다.

이러한 형태로 아키텍처 시각화를 구축하기 위해서는 다음과 같이 패턴들을 적용해야 한다.

  • 가)   Domain Level Classifier 패턴을 기반으로 소프트웨어 시스템의 도메인들을 분류한다.
  • 나)   Class Relationship Classifier 패턴을 기반으로 분류된 도메인들 간의 객체 지향적인 의존성들을 모두 분류한다.
  • 다)   분류된 도메인들과 객체 지향적인 의존성들을 정보들을 바탕으로 Base Metric Extractor 패턴을 활용하여 소프트웨어 시스템의 품질에 관한 Metric 정보들을 추출한다.
  • 라)   구성된 Metric 정보와 의존성 정보들을 바탕으로 아키텍처 시각화(Dependency Chart 패턴, Size of Component Chart 패턴, Robert C Martin Chart 패턴, Pollution Chart 패턴)를 표현한다.
그림1. 소프트웨어 시각화를 위한 패턴언어

그림1. 소프트웨어 시각화를 위한 패턴언어

<그림 1>은 위에서 소개한 절차를 바탕으로 아키텍처 시각화 패턴을 구성하는 다양한 패턴들간의 관계들을 표현한 패턴 구성도(패턴 맵)이다. 앞으로 시각화 패턴을 구축하는 하위 패턴들부터 시작하여, 구체적인 아키텍처 시각화 방법들이 담긴 패턴들을 소개하는 일종의 하향식 접근을 통해 아키텍처 시각화 패턴에 대해서 이야기 하겠다. 추가적으로 여기에서는 설명을 보다 쉽게 하기 위해서 객체 지향 언어 중 Java을 기반으로 예제들을 설명하겠다.

계속 읽기

NIPA 소프트웨어 공학센터의 지원으로, Android Application Block이라는 안드로이드 참조 아키텍쳐 모델을 만들었습니다 .

컨퍼런스를 통해서 먼저 소개하였고, 프리젠테이션을 통해서 안드로이드의 문제를 해결할때 필요한 여러 오픈소스들을 설명해 드렸습니다.  (재미난 것은 외국에서도 Android Bootstrap이라는 형태로 기존 Android의  문제를 해결하기 위해 여러 오픈소스를 묶어 제공을 했고, 안드로이드 개발자에게는 꽤 인기가 좋은 것으로 알고 있습니다.  )

이 버전보다 더욱 업데이트된 모바일 참조 아키텍처 (안드로이드) 를 발간 하였습니다. (링크를 통해 다운 받으시면 됩니다 – 소프트웨어 공학센터에 이메일 가입이 필요합니다)

안드로이드 어플리케이션 블록 아키텍처 

기존의 안드로이드의 구조(젤리 빈 기준)는 진성주 군과 분석하여  정리해보았습니다 (이 링크를 클릭하시면 됩니다).

그리고 저희가 몇가지 오픈소스들을 더해서 아래와 같이 추가된 모델을 만들었습니다.  새로 추가된 오픈소스가  기존의 어떤 안드로이드 패키지와 연관이 있는지 색깔을 입혀 표현을 하였습니다.

android application block_nipa

계속 읽기

조엘 온 소프트웨어에 나온 하나의 글이 돌아다니기에 생각을 적어봅니다. 정말 오랜만에 개인의 생각을  적어본 글이네요…

더 나은 코딩을 만들기 위한 12단계 라는 주제로 아래와 같은 지침을 제시하고 있습니다.

  • Source Control(소스 컨트롤)을 사용하십니까?
  • 한번에 빌드를 만들어낼 수 있습니까?
  • daily build(일별 빌드)를 만드십니까?
  • 버그 데이타베이스를 가지고 있습니까?
  • 새로운 코드를 작성하기 전에 버그들을 잡습니까?
  • up-to-date(최신) 스케줄을 가지고 있습니까?
  • spec(설계서)를 가지고 있습니까?
  • 프로그래머들이 조용한 작업환경을 가지고 있습니까?
  • 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
  • 테스터들을 고용하고 있습니까?
  • 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
  • hallway usability testing(무작위 사용성 테스팅)을 하십니까?

계속 읽기

아실 분은 아시겠지만, 저랑 저희 스터디에 김지원 군이 PLoP을 이끄는 Hillside Group의 이사회 위원으로 2012년 부터 합류하게 되었습니다.
Hillside-logo

PLoP을 다닌지 5년만에 되었네요.  아시아 학회의 공동 의장이기도 하지만, 이로서 더 넓은 영향력을 얻게 되었습니다.

계속 읽기

지난 토요일 (2012/10/28) 애자일과 패턴의 대가인 Linda Rising(린다 라이징)과  만남을 가졌습니다. 저희가 출간이 눈앞에 있는 Fearless Change의 저자이시구요. Agile 진영에서 이분이 미치는 영향력을 실로 거대하며, 간단히 Infoq에서 찾아보시면 그 해답을 얻으 실수 있습니다. 전세계 열리는  왠만한 agile 컨퍼런스에 메인 speaker로 참여하시고, 많은 agile 서적이 linda rising에게 감사를 하고 있거든요.

만난지 2년 만이였어요. SPLASH와  Agile 컨퍼런스가 겹치면서, PLoP에 못 나오셨거든요. 정말 반가웠습니다.  하루 내내 우리 나라의 문화를 알기위해서 창덕궁 , 전쟁 기념관 등을 돌아다니며, 관심있게 보셨구요.  특히 거북선에 관심을 보이셨답니다.

저녁에 NHN  그린 팩토리 앞 나루 라는 퓨전 레스토랑에서 인터뷰를 하며 저희 EVA 식구들의 궁금중을 푸는 시간을 가졌습니다.  여러분에게 어떠한 이야기가 오고 갔는지 전달해 드리고자 합니다.   사실 모임전에 저희끼리  Google Drive를 통해 저희들의 질문들을 모아 놓았고,  다양한 사람들의 의견을 물을 수 있도록 안배를 해, 각자 우선 순위 높은  자시만의 고민에 대해  물어 볼수 있었습니다

이 질문을 통해 책에서나 세미나에서 듣지 못했던 사람 Linda에 대해서 많은 것을 깨달을수 있었으며, 70세의 나이에도 불구하고 정말 철저한 자기 관리에 놀랐습니다. 특히 롤 모델이 없는 여성 개발자들에겐 Linda Rising이 좋은 롤 모델이 될거라고 믿습니다.

이 글 정리에 큰 도움을 주신 김동현님, 유성우님 에게 깊은 감사를 드립니다. 

인터뷰..

계속 읽기

스터디 그룹을 위한 패턴 언어에는 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs) 으로 나뉜다 .

스터디 그룹을 위한 패턴 언어 – Sprit 편 ‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다.

스터디 그룹을 위한 패턴 언어 – Atmosphere 편 ‘분위기’ 부분에서는 큰 부분에서부터 점차 세부적으로 기술하고 있으며, 6. 스터디의 지역적 장소 설정, 7. 장소의 분위기 설정, 8. 자리배열 방법, 9. 웹 페이지 의 순으로 기술하고 있다.

스터디 그룹을 위한 패턴 언어 – Role 편 ‘역할’ 부분에서는 각 구성원의 역할에 대해 기술하고 있는데 10. 리더는 열정적으로, 11. 사회자는 의욕적으로, 12. 참가자는 적극적으로 임하고, 13. 참가자는 또한 준비를 해 와야 한다. 마지막으로 14. 잘하는 사람을 적극 영입해야 한다는 것으로 설명되고 있다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한은 소프트웨어 마에스트로 멘티였던 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

습관  (Customs) 편

지금까지 스터디를 유지시키는 마음가짐, 여러 가지 분위기 조성, 그리고 규칙들에 대해 알아보았다. <<자조론>>으로 유명한 영국의 저술가인 새뮤얼 스마일스는 “습관은 나무껍질에 글자를 새긴 것과 같다. 그 나무가 커감에 따라 글자가 커진다.”라는 말은 남겼다. 좋은 습관 하나하나가 모여 스터디를 원활하게 돌리는 원동력이 될 수 있는 것이다.

이어지는 글들은 스터디를 위한 7가지 Customs(습관)에 대한 패턴들이다.

15. 토론을 시작하는 질문 (OPENING QUESTION )** 

Joshua Kerievsky는 대학 1학년 여름방학에 일리아드 오디세이를 읽고 독후감을 쓰는 숙제를 받았다고 한다. 밤낮을 가리지 않고 읽고 또 읽어 숙제를 마칠 수 있었는데, 당시 그 책은 전쟁에 관한 소설인줄 알았다고 한다.

학기가 시작한 이후 교수님께서 한 사람의 운명과 그 자신의 의지에 관한 질문을 던지셨다. 이 질문은 양을 치는 양치기가 언덕에 숨어서 전쟁을 보는 책의 장면과 연결이 되었다. 이 수업 이후 저자는 일리아드 오디세이를 운명에 순응하는 것과 개척하는 것에 대한 관점으로 바라볼 수 있었다고 한다.

사람들은 시작질문 없이 책을 읽으면 책의 진정한 내용을 알지 못하고 겉모양만 이해하게 된다. 하지만 이처럼 시작질문을 하게 되면 사람들의 관심을 끌 수 있게 되고 생각하기 어려운 부분들을 쉽게 접근할 수 있도록 해준다. 이 방법은 어려운 내용에 대해 공부할 때 더 유익하게 쓰일 것이다.

계속 읽기

7월 7일 있었던 제2회 대한민국 커뮤니티 데이에 발표한 동영상 강좌가 올라왔습니다.

안드로이드, 오픈소스  그리고 패턴에 대한 강좌입니다.

 

계속 읽기

스터디 그룹을 위한 패턴 언어에는 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs) 으로 나뉜다 .

스터디 그룹을 위한 패턴 언어 – Sprit 편

‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다.

스터디 그룹을 위한 패턴 언어 – Atmosphere 편

‘분위기’ 부분에서는 큰 부분에서부터 점차 세부적으로 기술하고 있으며, 6. 스터디의 지역적 장소 설정, 7. 장소의 분위기 설정, 8. 자리배열 방법, 9. 웹 페이지 의 순으로 기술하고 있다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한은 소프트웨어 마에스트로 멘티였던 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

역할  (Roles) 편

앞서 두  파트를 통해  스터디를 유지시키는 마음가짐, 여러 가지 분위기 조성에 대해서 알아보았다면, 이제는 스터디 팀원들 개 개인의  역할에 대해 설명하는 패턴언어이다.

‘역할’ 부분에서는 각 구성원의 역할에 대해 기술하고 있는데 10. 리더는 열정적으로, 11. 사회자는 의욕적으로, 12. 참가자는 적극적으로 임하고, 13. 참가자는 또한 준비를 해 와야 한다. 마지막으로 14. 잘하는 사람을 적극 영입해야 한다는 것으로 설명되고 있다.

계속 읽기