Architecture Refactoring with NOO [JCO version]

50 %
50 %
Information about Architecture Refactoring with NOO [JCO version]
Technology

Published on February 16, 2014

Author: arload

Source: slideshare.net

Description

Architecture Visualization & NOO를 통한 올바른 Architecture Refactoring의 기준을 설명 합니다.

Architecture  Refactoring   (Nature  of  Order)  

Youngsu Son indigoguru@gmail.com NHN NEXT Professor EVA Member UrQA Committer NEAOSS WG2 Leader Hillside Group Member AsianPLoP Co-Chair

Thanks  to..  

나눌 이야기들..   •  Architecture  Visualiza<on   •  Nature  of  Order  



  

  **

  Architecture

  Visualization

  

소프트웨어

  역시

  

  시각적으로

  

   의미있는

  내부를

  볼수

  보인다면..

  

하늘에서

  볼까?

  

   (30000

  feet)

  



  뭐가

  보이시나요??

  

자세히

  (0

  feet)

  볼까?

  

제한된

  코드로

   프로젝트가

  

   잘되고

  있는지

   판단은?

  

Diagram

  vs.

  Code

   Diagram  (3만 피트) •  다이어그램의 Line의 의미는? •  의존성? •  데이터 흐름? •  버스와 같은 공유자원? Code  (0  피트) •  너무 상세한 정보임. •  전체적인 구조를 보지 못함.

해결책은..

   적절한

  

  1000

  피트의

  뷰

  

지표..

  

지표별

  커버리지

   속성

   지표

   P

  

   C

   M

   Size

   Line

  of

  Code

   O

   O

   O

   Instability

  /

  Abstractness

   O

   Cohesion

   Lack

  of

  Cohesion

  of

  Method

   O

   DSM

   O

   O

   O

   Relation

  Chart

   Dependency

   O

   O

   O

   Tangled

   O

   Component

  Dependency,

  CCD,

  ACD

   O

   Depth

  of

  Inheritance

  Tree

   Response

   O

   Number

  Of

  Children

  in

  Tree

   Branch

  

   F

   O

   Cyclomatic

  Complexity

   O

   Weight

  Method

  for

  Class

   O

   Response

  For

  a

  Class

   O

  

지표 1     Instability/Abstractness  Graph

Instability

   • 패키지의

  움직일

  수

  있는

  여력을

  판단하는

  지표

   • 다른

  패키지에

  영향을

  미치지

  않고,

  

   

  해당

  패키지를

  쉽게

  변경

  할

  수

  있는가?

   • Instability

  I

  =

  Ce

  /

  (Ca+Ce)

   • Ce

  =

  Efferent

  Coupling

  (Ingoing

  Dependencies)

   • Ca

  =

  Afferent

  Coupling

  (Outgoing

  Dependencies

  )

  

Instability

   를

  

   

   키지 다면 의

  패 고

  있 당신 이

  쓰 다.

   많 가

   지

  않 군 누 기

  쉽 꾸 I

  =

  

  Ce

  /

  (Ca+Ce)

   바 Instability

   

   당신의

  패키지가

  다른

  사람이

  많이

  쓴다면,

  

   즉

  Outgoing,

  Ca가

  많다면,

  

  

  여러분의

  패키지는

  변경하기

  어렵다.

  

   

   반대로

  Outgoing하는

  Ca가

  적고,

  Ingoing(다른

  패키지만

  사용만

  하는)

  

  Ce,

   여러분의

  패키지는

  쉽게

  변경해도

  된다.

   

   즉

  

  0.0에서

  0.3이면

  안정적인

  버전,

  

  0.7에서

  1.0이면

  불안정적인

  상태다

  

   

  

  

Abstractness

   Interface(Abstract)

  와

  Concrete

  Class를

  비교

   

   

  A

  =

  (#abstract

  classes

  /

  total

  #

  of

  classes)

   • Abstract

  class

  =

  interface,

  abstract다

  포함

   • Total

  #

  class

  

  =

  abstract

  class

  +

  concrete

  class

   • 0

  이면

  concrete

  class만

  있다.

  

   • 1

  이면

  abstract

  class만

  있다.

  

  

다시

  보는

  그래프

   다른데서

  많이

  쓰는

   녀석이니

  조금

  더

   abstract를

  높여야

   돼!

  

지표

  2

  

  

   DSM

  과

  Relation

  Chart

  

  

간단한

  DSM

  

잘

  계층화된

  DSM

  

엄격한

  계층화를

  유지한

  

   시스템의

  DSM

  

불완전한

  계층구조를

  가진

  시스템

  

지표

  3

  

  

   Size

  of

  Component

  (LOC)

  

지표

  4

  

  

   Cyclomatic

  Complexity

  

지표 5.  WMC(Weighted  Method  per  Class)   WMC  =  ∑Cycloma<c  complexity  

지표

  6

  

  -

  Tangled

   상위

  레이어의

  변화가

   하위

  레이어에도

  

   영향을

  미칠

  위험

  

Tangled

  란?

   역참조 갯수   전체 참조 갯수   * 100(%) 4  /  16 * 100(%)  =  25%  



  역

  참조없이

  레이어가

  잘

  나눠진

  아키텍쳐

   Tangled지표는   0에 가까울수록 좋다.   Frontend Communicator Framework

지표

  7

  

  -

  CD

  ,

  CCD,

  ACD

   3 2 1 0 CD(Component

  dependency)

   

  =

  컴포넌트에

  영향을

  주는

  다른

  컴포넌트의

  갯수

  

CCD(Cumulated  Component  Dependency)  =  ∑CD   5   5   5   CCD

  =

  9

   5   5   5   Maximum

  CCD

  =

  5

  *

  6

  =

  30

  

Average  CD  =  CCD  /  Maximum  CCD  *  100(%)   ACD  =  9  /  30  *  100(%)  =  30%   5   5   5   CCD

  =

  9

   5   5   5   Maximum

  CCD

  =

  5

  *

  6

  =

  30

  

ACD(Average

  Component

  Dependency)

  지표

   

  Empty

  :

  만약

  노드간에

  참조가

  없다면

  ACD는

  0%이다.

   

   

  Chain

  :

  만약

  모든

  노드가

  하나의

  패스를

  형성하면

  ACD는

  50%이다.

   

   

  Cycle

  :

  만약

  모든노드가

  하나의

  순환을

  형성하면

  ACD는

  100%이다.

   Empty   Chain   Cycle  

지표

  7

  -

  LCOM(Lack

  of

  Cohesion

  in

  Methods)

   

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  응집력부족

  지표

   클래스의

  응집력을

  판단하는

  지표

  

M1  =  생성자   M2  =  getFullAddress3   M3  =  getFullAddress   M4  =  getFullAddress1     M1이 접근 가능한 필드     M2이 접근 가능한 필드   M3이 접근 가능한 필드   M4이 접근 가능한 필드   {I1}  =  {∅}   {I2}  =  {aaa}   {I3}  =  {street,  city,  zipCode}   {I4}  =  {zipCode}    

공집합의

  갯수

  |

  P

  |

   공집합이

  아닌

  갯수

  |

  Q

  |

  

   (I1∩I2)

  =

  {∅}

  

   (I1∩I3)

  =

  {∅}

   (I1∩I4)

  =

  {∅}

   (I2∩I3)

  =

  {∅}

   (I2∩I4)

  =

  {∅}

   (I3∩I4)

  =

  {zipCode}

   LCOM  =  |P|  -­‐  |Q|  =  4  

LCOM값이

  작으면:

   

   참조하는

  공통

  Field가

  많음

   응집력이

  있음

   LCOM값이

  크면:

   응집력이

  낮음

   하나의

  클래스를

  2개의

  클래스로

  

   나누는것이

  바람직함

  

지표

  8.

  DIT(Depth

  of

  Inheritance

  Tree)

   2 1 0 DIT

  0은

  Root

  Class

   

   DIT

  크면

   

  -

  Class의

  행동

  예측

  어려움

   

  -

  시스템

  이해가

  어려움

   

   적절한

  DIT

   

  -

  객체지향

  언어에서

  재사용성을

  높임

   

  

지표

  9.

  NOC

   (Number

  of

  Children

  in

  Tree)

   0 1 0 2 상속한

  클래스의

  갯수

   

   NOC가

  클수록

   

  -

  클래스

  변경

  시

  주의하여야

  함

  

지표

  10.

  RFC(Response

  For

  a

  Class)

   클래스와

  연관된

  생성자,

  메소드의

  갯수

  

   classA와

  연관된

  메소드,

  생성자:

   

   classA()

   classA.callB()

   classB()

   classB.function()

   

   RFC

  =

  4

  

어디서

  많이

  본

  MECE..

  

지표별

  커버리지

   속성

   지표

   P

  

   C

   M

   Size

   Line

  of

  Code

   O

   O

   O

   Instability

  /

  Abstractness

   O

   Cohesion

   Lack

  of

  Cohesion

  of

  Method

   O

   DSM

   O

   O

   O

   Relation

  Chart

   Dependency

   O

   O

   O

   Tangled

   O

   Component

  Dependency,

  CCD,

  ACD

   O

   Depth

  of

  Inheritance

  Tree

   Response

   O

   Number

  Of

  Children

  in

  Tree

   Branch

  

   F

   O

   Cyclomatic

  Complexity

   O

   Weight

  Method

  for

  Class

   O

   Response

  For

  a

  Class

   O

  

수

  많은

  시각화

  툴들..

   Free

   Java

   C++

   Commercial

  

왜 안쓰나요?? •  대기업

  (제조업

  ,SI)-

  아키텍트

  팀

   •  중소기업­–

  운영,

  

   

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  개발자,

  

   

   

  

  

  

  

   

  

  

  

  PM

   •  NIPA

  ­–

  중소기업

  소프트웨어

  컨설팅

  지원

  

이해하기

  어려운

  차트&지표들이

  존재하고

  

   무엇이

  문제가

  되는지

  한눈에

  알기

  힘들다

   

   어떻게

  개선을

  해야

  하는지도

  모르겠다!

  

**

  Nature

  of

  Order

  

패턴의

  아버지

   Christopher

  Alexander

  

Published

  in

  1977

   

   3

  Authors

   

   3

  Assistants

   

   253

  Patterns

   

   1171

  Pages

   

   Written

  Over

  8

  Years

  

이미

  구축된

  환경에

  있는

   패턴을

  이야기

  함

   건축,

  사람들의

  사회적

   연결에

  초점이

  맞추어져

   있다.

  

Self-Consciousness

  (자의식이

  강한)

  

이질적인가??

  

  

만약

  

   인디언이

  

   초가집을

  본다면..

   

   

   자연스러울까?

  

자연에서

  답을

  찾자!

  

2007년

  그

  해답을

  가져오다

  

질서의

  본질

  

   (자연의

  설계,

  절차를

  배우다)

   The fifteen properties of things that have life Unfolding processes for creating “lively” things

생명체가

  가지는

  15가지

  속성

  

Levels  of  Scale   Strong  Centers   Good  Shape   Local  Symmetries   Roughness   Echoes   Boundaries   Deep  Interlock   Ambiguity   The  Void   Alterna<ng   Repe<<on   Contrast   Simplicity     Inner  Calm   Posi<ve  Space   Gradients   Not-­‐Separateness  

크기의 단계   좋은 모양   기계적이지 않은   (다듬어지지 않은)   강한 구심점   내부 대칭   되풀이   경계   깊은 연계   다양한 성질   여백   교차적을 일어나는 반복   대조   간결함 내부적인 고요함   양의 공간   점진적인 변화   나뉘어지지 않는  

3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  

*

  Positive

  Space

  

Subject

   Positive

  

   Space

  

   Negative

   Space

  

  

시스템을

  구성하는

  

   각각의

  요소들(elements)은

  

   

   하나의

  목적을

  구성하기

  위해

  완전하고,

  

   잘

  정의되어있어야

  한다.

  

   

   또

  다른

  이름..

  

  응집력..

   

  

3~7세

  어린이

  신발

  살때

  기준은?

   귀여운

  

   기능성

  

Pain

  Point

  

고객의

  

  문제를

  해결하자!

   =

   

  우리

  소프트에어의

  핵심가치

  

비즈니스

  모델

  캔버스는

  창업자들이

  생각한

  가설이고,

   고객

  개발은

  창업자들이

  생각해낸

  해결책을

  검증하기

  보다는

  

   창업자들이

  가정한

  문제가

  진짜

  고객의

  문제인지

  검증하는

   것이다!

   

   

   Steve

  Blank

   

   Lean

  Startup의

  아버지

   Customer

  Development

  Method

  저자

  

2013년

  Play

  마켓

  앱

  개수

  

   전체

  앱

  중

  Bug

  report를

  사용하는

  앱

   Bugsense

   7%

   ACRA

   3%

   Others

   0%

   not

  use

   90%

   새로운

  앱

  중

  Bug

  report를

  사용하는

  앱

   BugSense

   14%

   not

  use

   81%

   버그리포트

  시장

  점유율

   ACRA

   3%

   ACRA

   16%

   Others

   2%

   BugSense

   77%

   Crittercism

   5%

   Others

   2%

  

왜

  안쓰지?

  불편한가?

  

Customer

  

   Validation

   고객의

   요구사항

   Feedback

   Customer

  

   Discovery

  

기존

  경쟁

  제품의

  한계...

   사용자가

  앱을

  어떻게

   사용하다

  버그가

  발생

  

   하였는지

  알

  수

  가

  없어서

  

   버그

   재현에

   많은

   시간이

   걸렸다.

   

  Sleep

  If

  U

  Can

  개발자

   신재명

  BugSense사용

  중

  

기존

  경쟁

  제품의

  한계...

   

  진정

  시급한

  버그가

  무엇인지

  

   

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  알

  수가

  없다.

  

   

   

   알람에서

   가장시급한

   버그는

   알람

   기능에서

   발생한

   버그이다.

   하지만

   버그의

   발생

   수에

   가려

   진짜

   시급한

   버그를

  노치게

  된다.

   말랑스튜디오

  CEO

   김영호

   BugSense사용

  중

  

Customer

  

   Validation

   Feedback

   고객의

   요구사항

   버그의

  위험

  정도를 

  판별

  할

  QA의

  부재

   Customer

  

   Discovery

   QA

  Insight

   가치찾기

  워크샵

  

QA

  Insight

   삼성전자

  소프트웨어QA

   조현길

  책임

  

QA

  Insight

   -

  QA는

  소프트웨어의

  품질을

  향상시키는

  역할

   

   -

  버그가

  발생하게되면

  이슈트레커를

  통해

  개발자에게

  버그에

  대한

  정보

  보고

   

   -

  버그가

  발생했을

  때

  양보다

  질을

  우선

  시

  하기

  위해

  위험도에

  따라

  등급을

   

  

  Crash,

  Critical,

  Major,

  Minor로

  분류

   

   -

  버그를

  재현시키는데

  가장

  많은

  시간을

  들임.

  

   

  

  재현이

  되지

  않는

  버그는

  버그로

  보지

  않음

   

   -

  New

  ->

  Assign

  ->

  Acknowledge

  ->

  Resolve

  ->

  Feedback

  과정으로

  버그를

  관리하 며

  대화형식으로

  기록을

  남겨둔다.

   

   -

  소프트웨어

  평가지표를

  도출한다.

   

   -

  QA는

  소프트웨어개발

  프로세스

  전반에

  관여하게

  된다.

  

핵심

  가치

  찾기

  워크샵

  진행

  

1)

  Purpose

  &

  Goal

  수립

  

2)

  Why

  &

  Why

  not

  Buy?

  

사야

  되는

  이유와

  사지

  않는

  이유를

  

   각자

  30개씩

  적고

  그룹화

  한다

  

3)

  Simple

  Value

  Proposition

  

4)

  User

  Profiling을

  통한

  Opportunity도출

  

작성한

  페르소나

  중

  

   우선순위가

  높은

  페르소나를

  선택하고

   키워드를

  그룹화

  

5)

  Convergence

  

UrQA는

  모바일

  앱

  개발팀에게

  

   VALUE

   크래시를

  빠르게

  대응

   Person-hour

  절약

   차별화된

  기술력

   가치를

  제공하는데

   FEATURE

   실시간으로

  에러를

  

   등급화하여

  리포팅

   사용자

  이벤트

  경로

   시각화

   C/C++

  네이티브

  

   크래시

  리포트

  제공 를

  통해서

  이루어

  진다.

  

판단

  기준

  즉

  목적성이

  정립됨

  

그래서

  나온

  소프트웨어

  

아이콘과

  색을

  

   이용한

  버그의

  등급

  ,

  갯수표시

  

Event

  Path

   버그를

  발생시킨

  사용자

  경로를

  

   시각화해서

  보여줌

   CRASH

  

OS버전

   App

  버전

  대비

  OS버전의

  

   버그

  발생량을

  보여줌

   앱

  버전

  

다양한 통계자료를 기간 별로   한눈에 파악 가능  

Bugsense,

  Acra

  

  

UrQA

  

Positive

  Space

  지표

   속성

   지표

   P

  

   C

   M

   Size

   Line

  of

  Code

   O

   O

   O

   Instability

  /

  Abstractness

   O

   Cohesion

   Lack

  of

  Cohesion

  of

  Method

   O

   DSM

   O

   O

   O

   Relation

  Chart

   Dependency

   O

   O

   O

   Tangled

   O

   Component

  Dependency,

  CCD,

  ACD

   O

   Depth

  of

  Inheritance

  Tree

   Response

   O

   Number

  Of

  Children

  in

  Tree

   Branch

  

   F

   O

   Cyclomatic

  Complexity

   O

   Weight

  Method

  for

  Class

   O

   Response

  For

  a

  Class

   O

  



   Positive

  Space

  

   

   핵심

  가치를

  찾아라..

  



   Good

  Shape와

  함께..

   

   저는

  현재

  전체를

  대변하는

  

   가장

  큰

  원칙이라고

  생각합니다.

  

*    Roughness  

3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  

견고함이란..

  

내가

  만난

  문제들..

  

왜

  이런

  일이..

   직급

   음식

  

   사내

  

   동호회

  

  

이기적인

  감정을

  버릴수

  있는

  

   팀원들이

  구성될수

  있는

  문화가

  중요

  

10  Commandments   of     Egoless   Programming      

비자아적인

  프로그래밍

  10계명

  

   자신도

  실수

  할

  수

  있다는

  것을

  이해하고

  받아

   들일줄

  알아야

  한다.

   

   너의

  프로그램은

  너

  자신이

  아니다.

   

   리뷰의

  중요한

  것은

  문제를

  발견하는

  것이라는

   것을

  기억하라.

  문제가

  발견되어도

  당신

  개인

   문제로

  적용하지는

  않는다.

  

비자아적인

  프로그래밍

  10계명

  

   아무리

  당신이

  그것에

  대해서

  자세히

  알아도

  세상 에는

  당신보다

  많이

  아는

  사람이

  항상

  존재한다.

   

   타인과

  상의

  없이

  코드를

  다시

  쓰지

  마라.

   

   당신보다

  지식이

  없는

  사람이라도,

  존중,

  인내하는

   습관을

  길러라.

Add a comment

Related presentations

Related pages

inventory.data.gov

92973.67. 105952922.95999999. 0. 0. 0. 18936.93. 139080. 9275.44. 0. 18965.36. 168624. 10147.5. 49971. 4821.78. 7472075.7800000003. 10868.97. 3145.28 ...
Read more

Full text of "Electrical Engineering and Applied Computing ...

Full text of "Electrical Engineering and Applied Computing [electronic resource]" See other formats ...
Read more

Full text of "New Software Engineering Paradigm Based on ...

Search the history of over 510 billion pages on the Internet. search Search the Wayback Machine
Read more

[Python-checkins] cpython: initial import of the packaging ...

[Python-checkins] cpython: initial import of the ... I haven't done the +# necessary refactoring to account for the ... for the correct architecture ...
Read more

[Python-checkins] cpython: initial import of the packaging ...

initial import of the packaging package in the standard ... +# necessary refactoring ... + # Use the .lib files for the correct architecture ...
Read more