[ 프로젝트 BEP ] 제 3장 : 시스템 설계 ② - UML의 Class Diagram(클래스 다이어그램)에 대해

이제 정말로 본격적인 이야기를 시작해보자.

바로 UML에서 제시해주는 다이어그램 중 하나인 

클래스 다이어그램에 관한 이야기 이다.

이전 글에서 이에 대해 언급했으니 

바로 클래스 다이어그램이 정확히 

어떤 형식으로 이루어져있는지에 대해 이야기를 나눠보자.

간단한 Class Diagram의 예

간단한 예로서 어느 것이 가장 좋을까?

포스팅 중 Django에 대한 포스팅이 

나의 블로그에는 꽤나 있는데,

여기서 사용되었던 Class Diagram을 예로서 살펴보자.

이 다이어그램은 실제 Mozlia 쪽의 튜토리얼에서 제시해줬던 

도서관 앱의 Class Diagram이다.

이에 대한 자세한 설명은 아래와 같다.

먼저 빨간색 박스는 Class의 이름을 표기하는 곳이며

하늘색 박스는 변수명과 변수 타입을 표기한다.

또한 주황색 박스는 클래스 내부의 메소드들의 표기,

그리고 녹색 박스는 클래스 간의 관계를 표시하는데

ER다이어그램에서 사용하는 것과 유사하다.

따라서 실제 해당 클래스가 다른 클래스들과 

DB에서 어떻게 관계가 이루어지는지를 알 수 있다.

변수 가장 왼쪽에 있는 +는 public을 의미하며,

-를 사용할 경우 private를 의미 한다.

다른 설계 도구를 사용할때에도 마찬가지이지만,

언어와 상관없이 이 설계도만 있으면 해당 앱을 작성할 수 있다.

Class Diagram으로 설계 하기

그렇다면 이제 실제로 위의

애플리케이션 설계 보다 더 간단한 것을 설계해보자.

나는 다른 언어를 배울 때마다 

꼭 작성해보는 프로그램이 있는데

바로 계산기 프로그램이다.

왜냐하면 계산기 프로그램만 작성해도

기본적인 함수 작성, 함수 리턴, 변수 선언, 변수 리턴, if문 등의

가장 기본적인 문법을 실제 확인해볼 수 있기 때문이다.

따라서 이 계산기 프로그램을 위한 설계를 

Class Diagram을 활용해 작성해보기로 하겠다.

물론 글에서는 바로 아래에 표시하겠지만

가능하다면 자신 나름대로 

위에서 보여주었던 Class Diagram을 보고 

직접 작성해 보기를 바란다.

매우 간단한 계산기이기 때문에

기능은 두 변수를 입력하면 +, -, *, /를 할 수 있는 

함수 혹은 클래스를 Class Diagram으로 작성해보고 

이를 실제 언어를 통해 구현해보자.

어떤 언어라도 상관없지만, 

나는 Java로 작성하도록 하겠다.

노파심에서 말하지만, 

설계에서 표준은 존재하지만, 매뉴얼은 존재하지 않는다.

가급적 표준을 따르는 것이 좋으나, 

특별히 커뮤니케이션에 문제가 없다고 생각한다면

어떻게 다이어그램을 어떻게 사용하던 상관 없다고 

나는 생각하고 있다. 

왜냐하면, 

이런 도구들은 커뮤니케이션을 위한 도구이지

표준을 따르기 위한 도구는 아니기 때문이다.

따라서 커뮤니케이션이 적절히 이루어 질 수 있는

설계라면, 표준에 따르지 않더라도 큰 문제는 없다고 보고 있으며

나 또한 설계가 필요할 때, 그렇게 하고 있다.

클래스 다이어그램을 사용하는 이유는

서로 커뮤니케이션을 유용하게 함과 동시에

혹시 모를 리스크에 대비해 문서화 하는 것이지

표준에 딱 맞추기 위해 사용하는 것이 아니다.

물론 커뮤니케이션도 훌륭하고, 

표준에도 딱 맞추어서 마치 이쁘게 보이게하는 것이 

다소 완벽에 가까울 수는 있지만

위에서 언급했지만, 문서화에 집착하다 보면은

시간의 효율성도 떨어지기 때문에 

적절한 선에서 끊는 것이 좋다. 

목적을 명확히 하는 것이 좋다.

다시 한번 말하지만 클래스 다이어그램을 사용하는

제1 목적은 커뮤니케이션을 원활히 하기 위함이다.

따라서 표준을 따르되, 

그 외의 필요에 의해 커뮤니케이션에 

혼돈을 주지 않는 선에서는 자유롭게 해도 상관 없다고 생각한다.

물론 표준에 꼭 따라야 직성이 풀리다면 

말리지는 않겠다.

다만, 나는 그런 시간이 있다면, 

시간을 좀 더 중요한 곳에 사용하기를 권유할 뿐이며,

굳이 표준에 꼭 따르지 않더라도 

다른 사람들을 비난하지 말기를 바란다.

어떤 방식이건

유용성에 큰 차이는 없으며, 어떤 방식으로 접근하고 

시간을 어떻게 활용하는지에 차이가 있을 뿐이다.

개인으로서는 이에 대해 큰 문제는 없지만

프로젝트라면 문제가 있을 수 있다.

왜냐하면 어떻게 하던 상관없는 일에 

시간을 소비하게 된다면 

그 만큼 실제 개발과 품질 보증에 할당할 시간은 줄어 들기 때문이다.

이는 분명 생각해볼 만한 가치가 있다.

Class Diagram으로 간단한 계산기 설계하기

익히 알고 있겠지만

프로그램은 가상의 것이고, 추상적이기 때문에

같은 목적의 프로그램을 작성한다하더라도 

내부 구성 코드는 다를 수 밖에 없다.

따라서 여기서 내가 제시해주는 것은 

내가 제시하는 방법론 일 뿐 

이것이 무조건 맞다고는 하기는 힘들다.

하나의 예로서 참고하길 바란다.

우선 나는 최대한 모듈을 

최대한 나누어서 독립적으로 만드는 것을 선호하기 때문에 

다소 모듈이 많을 수도 있다는 사실을 먼저 언급해 두겠다.

자 그럼 이제 각자 생각해보자.

당신이라면 계산기 프로그램을 어떤 방식으로 만들 것인가?

설사 이것이 작동하지 않는다 하더라도 

수정하면 되기 때문에 완벽하지 않아도 좋다.

시작부터 완벽한 프로그램을 

만들 필요도 없고, 만들 수도 없다. 

그렇기에 우선 완벽한 모듈화, 퍼포먼스(성능) 등과 같은 

생각은 잠시 잊어버리는게 좋다.

처음부터 완벽한 알고리즘을 짜내는 것은 불가능에 가깝다.

계산기 정도야 얼마든지 할 수 있겠지만,

엔터프라이즈 급 시스템으로 가면 갈 수록 불가능에 가까워진다. 

그런 사람이 있다고 한다면

그 사람이야 말로 프로그래밍의 화신이라고 할 수 있을 것이다.

물론 나는 한번도 본 적이 없지만 말이다.

다시 한번 언급하자면 

우리가 작성하고자 하는 프로그램은 계산기 프로그램으로서

기능은 +,-,*,/의 기능만을 가지면 된다.

목적을 확실히 하는 것이 

시간을 좀 더 효율적으로 사용할 수 있다.

간단히 생각해서 전체 모듈을 하나로 합치는 

계산기에 해당하는 메인(main) 모듈과

각 +,-,*,/를 계산하고 리턴해주는 모듈을 만들면 될 것이다.

그렇다면 5개의 모듈을 그리고 모듈 이름과 

내부의 변수의 이름을 생각해 그려주면 끝이다.

노트에 그려도 좋고, 파워 포인트로 그려도 좋고

아니면 클라우드 컴퓨팅 서비스를 이용해도 좋다.

각자 생각하고 그려보자.

나는 위와 같이 클래스 다이어그램을 그렸는데,

사실 set이나 resultClear 메소드의 경우 

SimpleCalculator의 3번째 단락에 넣어도 되지만,

이해를 돕기 위해 따로 빼서 

종속 관계로 표현하였다.

작성한 Class Diagram으로 계산기 프로그램 작성 하기

위의 클래스 다이어그램을 기반으로 

나는 아래와 같은 코드를 작성하였다.

import java.util.*;

public class SimpleCalculator {

    private int culResult = 0;
    final private int resetVal = 0;

    public void setCalcuSum(int x, int y){
      culResult = x+y;
    }

    public void setCalcuSub(int x, int y){
      culResult = x-y;
    }

    public void setCalcuMul(int x, int y){
      culResult = x*y;
    }

    public void setCalcuDiv(int x, int y){
      culResult = x/y;
    }

    public void resultValClear(){
      culResult = resetVal;
      System.out.println("result value reset!");
    }

    public int getCulResult(){
        return culResult;
    }


    public static void main(String[] args) throws Exception {
        // Your code here!
        SimpleCalculator sc = new SimpleCalculator();

        sc.setCalcuSub(1,2);
        System.out.println(sc.getCulResult());

        sc.resultValClear();


        sc.setCalcuMul(3,3);
        System.out.println(sc.getCulResult());

        sc.resultValClear();


        sc.setCalcuSum(3,2);
        System.out.println(sc.getCulResult());

        sc.resultValClear();


        sc.setCalcuDiv(3,3);
        System.out.println(sc.getCulResult());

    }

}

또한 정상적으로 작동하는지 실제 컴파일해 작동을 

아래와 같이 확인하였다.

결론

이렇게 해서 간단한 Class Diagram을 그려봤다.

실제 개발 업무의 시스템은 

당연히 이보다 복잡하고 클 것이기 때문에 

더욱 더 복잡할 것 이다.

또한 Class Diagram의 가장 기본적인 구성 요소로만 작성했으며

계산기 프로그램은 다른 기능들과의 관계가 존재하지 않기 때문에

관계 또한 작성하지 않았다.

실제 현장에서 담당하게 될 엔터프라이즈 급 시스템은

각 기능 마다 혹은 화면 마다 더 나아가 

외부 시스템의 관계도 고려해야만 한다.

이외에도 여러가지 표준 표현 방식이 존재 한다.

그럴 경우 지정한 표준대로 적절하게 작성해야만

서로 커뮤니케이션 하는데에 문제가 없을 것이다.

물론 위에서 언급했듯이

주 목적은 커뮤니케이션에 있지, 

표준을 정확히 맞추는데 있는 것이 아님을 잊지 말자.

개인적으로 협업하는데에 있어서 

이러한 사고 방식은 매우 좋지 않다고 생각 한다.

Class Diagram 이외에도 UML 뿐만 아니라

여러가지 설계 도구들이 존재 한다.

이제 낚시 하는 방법을 알려주었으니

자신의 힘으로 낚시를 해보길 바란다.

---

참고 :

https://www.omg.org/spec/UML/

https://en.wikipedia.org/wiki/Unified_Modeling_Language

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/

http://pages.cs.wisc.edu/~hasti/cs302/examples/UMLdiagram.html

---