I studied how to draw dependency graph from the
website. I translated it below to understand correctly.
my own example is on
another post.
python 파일들의 dependency graph를 그리기 위해서 인터넷 검색을 통해
잘 설명해 준 싸이트를 찾았고, 해 보았습니다. 아래는 이해를 제대로 하기 위해 번역해 놓은 글 입니다. 제가 직접 구현한 간단한 예제는
다른 포스트에 기록 했습니다.
Controlling physical dependencies is an important part of any software architecture. We noticed a shortage of tools for analyzing Python program when we started work on 'Tintag Explorer', and the tools described here were created as a result.
물리적인 의존관계를 파악하고 제어하는 것은 소프트웨어 구조에서 중요한 부분입니다. 우리는 Python 에서 이런 의존관계를 분석하는 툴이 부족한 것을 인지하여 Tintag Explorer 의 의존관계 분석하는 툴을 직접 만들어 보았습니다.
Below is a shrunken version of the dependency graph from several subsystems of the current development version of Tinytag Explorer; 4.3. The __main__ module is the small dark blue circle at the top. Other circles are other modules. The lines are arrows (although you cant see the arrow-heads in this shrunken version) that indicate that one module imports another. All arrows point down, unless there are cyclic imports.
아래는 Tinytag Explorer 4.3버전에 대한 의존그래프 입니다. __main__ 모듈은 위쪽에 작은 어두운 파란 동그라미 입니다. 보이는 선들은 화살표이며(비록 이 작은 그림들에서는 화살의 머리가 보이지 않아도) import 된 관계를 나타 냅니다.
모든 화살표는 아래를 향하게 됩니다. 단 cycle 관계여서 서로 import 하는게 아니라면...
We have obtained enormous value from studying automatically generated diagrams such as this. It often highlights:
우리는 자동 다이어그램 생성을 찾아 보면서 많은 것들을 얻었습니다. 이 dependency graph를 통해서 강조해서 알 수 있었던 것은.
● Ill-advised module iorts, as obtrusive diagonal lines across large distances of the diagram.
문제가 될만한 먼 거리에 보기싫게 사선으로 연결된 관계.
● Modules that might be in the wrong package, as solitary circles on one color surrounded by those of another color.
잘못된 패키지 안에 있는 모듈들, 예를 들어 혼자 연결되어 있는 것.
● Subsystems that are ideal for reuse in other systems because they have few dependencies. For example, the island of pink on the bottom left of the diagram above has already been reused from another project. [Hi Lawrence.... That's TSG!]
의존 관계가 적어, 재 사용하기에 좋은 하위시스템들, 예를 들어 아래에서 왼쪽에 핑크색으로 표시된 것처럼.
● Close clusters of modules are often a suitable unit for code review.
구분되어 져 있는 무리들은 코드 리뷰하기에 적당함
This diagram was generated from a three-step process:
이 다이어그램은 3개의 단계로 나누어 진행 되었습니다.
Step 1: Compute The Dependency Graph
Python's modulefinder module does all the heavy lifting here. modulefinder use bytecode inspection to find dependencies, and therefore is free from any side-effects that may be caused by importing the modules being studied.
파이썬의 modulefinder 모듈이 어려운 일들을 해 줍니다. modulefinder 는 바이트코드 단위에서 의존관계를 확인해 주었고, import 된 것을 확인하는 과정에서 부작용이 없도록 하였습니다.
This
py2depgraph.py script will write to stdout the dependency graph raw data for the script named in its first parameter.
이
py2depgraph.py 스크립트 첫번째 파라미터가 된 파일에 대한 의존 관계를 간단한 text 버전으로 보여 줍니다.
Step 2: Format The Dependency Graph
In step 3 we will be passing our data into dot, part of
graphviz In step 2 we need to convert the raw dependency data generated in step 1 into the correct format, and apply any presentation logic.
2번째 단계에서는 1단계에서 나온 의존관계를 그래프 그리기 알맞는 dot형태로 변경하고, 3번째 단계에서 dot 형태의 그래프를
graphviz로 보내 그림으로 보여질 수 있도록 합니다.
In simple cases you can use
depgraph2dot.py as-is. It receives the raw data in standard input, and provides the generated dot file on standard output.
간단한 관계에선
depgraph2dot.py를 그대로 사용하면 됩니다. 입력값으로 기본 text 포맷을 받아들이며 dot파일의 형태로 아웃풋을 만들어 줍니다.
For the best presentation you will need a little programming. Create a subclass of the class defined in this module, override some methods that apply presentation logic, then call the main() method of one of those objects. The following aspects of the presentation can be customised:
최적으로 보여주기 위하여 약간의 프로그래밍이 필요 합니다. 여기서 만들어진 클래스에 대한 하위 클래스를 만들어서, 프레젠테이션 로직을 오버라이드 해 주고 main 함수를 부르면 됩니다. 프레젠테이션은 수정될 수도 있습니다.
1. Change which modules will be used on the diagram. By default it omits a number of very common modules such as sys that would add uninteresting clutter. It also omits packages (but not the modules within the package). The diagram above has been customized to show a group of application-specific packages.
어떤 모듈을 그릴 것인지 선택 합니다. 정말 기본적인 모듈들 이나 package 들은 생략합니다(예를 들어 sys). 위의 다이어그램은 application 에 사용되는 것들만 보이도록 손 본 것입니다.
2. Pairs of modules that have a specially close relationship. These relationships are drawn with particularly short straight lines. By default any reference to a module whose name starts with an underscore carries this extra weight, because that usually indicates a special relationship (for example, as between
random and
_random)
관계가 밀접한 모듈들은 짧은 라인으로 연결되게 됩니다. 모듈 이름에 밑줄이 그어져 잇는 것들은 특별히 중요한 것들입니다. 특별한 관계이기 때문 입니다.(예를 들어
random 과
_random)
3. Pairs of modules whose relationship should be drawn with an extra long line. This is a good way of separating subsystems - for example the module highlighted in red in the diagram above has extra space above.
특별히 긴 라인으로 연결되어 있는 모듈들도 있습니다. 이 방법은 하위 시스템들을 구분하는 데 사용됩니다 - 빨간색으로 강조 되어 있는 부분이 그렇습니다.
4. A color. By default the color is assigned automatically with all modules in one package assigned the same color.
색을 입힙니다. 기본 색은 자동으로 생성되며 같은 패키지것을 사용한 것은 같은 색이 됩니다.
5. A text label, by default the module name.
텍스트를 모듈의 이름에 근거해서 생성합니다.
Step 3: Generate The Image
You need the dot tool from graphviz. This can generate most image formats. It can also generate postscript ideal for printing. If printing to a black and white printer the --mono switch to depgraph2dot.py will be helpful.
image를 만들기 위해서는 graphviz에 있는 dot 툴이 필요 합니다. 흑백의 출력이 필요하다면 --mono option 을 depgraph2dot.py 명령에 추가하면 됩니다.
Putting those three steps together gives something like:
위에 설명한 3개의 단계는 아래의 명령으로 구현 됩니다.
$ python py2depgraph.py path/to/my/script.py | python depgraph2dot.py | dot -T png -o depgraph.png
$
(Created 2004. Updated December 2009 with python 2.6 fixes)
