ice rabbit programming

[소공] 클래스 모델링 본문

Development/Software Architecture

[소공] 클래스 모델링

판교토끼 2023. 10. 14. 12:54

OOP로 프로그래밍할 때에는 코드 작성 전에 클래스 모델링을 진행하는 편이 좋다. 학부생 때 다들 그려봤을 클래스 다이어그램을 이용할 수 있다.

클래스 다이어그램의 구성 요소는 아래와 같다.

  • 클래스 : 자료 타입 그 자체를 나타냄
  • 연관 관계 : 클래스 인스턴스 사이의 관계를 나타냄
  • 속성 : 클래스와 그 인스턴스 내에서 발견되는 단순 자료
  • 오퍼레이션 : 클래스와 그 인스턴스에 의해 수행될 함수
  • 일반화 : 클래스를 상속 구조로 그루핑

첨언하자면 클래스와 인스턴스는 붕어빵 틀과 붕어빵의 관계인데, 여기서는 더 자세히 다루지는 않겠다.

클래스 다이어그램에서 클래스는 박스로 표현하며 그 안에 이름을 적는다. 그 아래에 속성과 타입을 적고, 그 아래에 오퍼레이션을 적는다.

예시로 보면 아래와 같다.

위 이미지에 더하여 접근 지정자도 나타낼 수 있는데, public은 +, protected는 #, private는 -로 표시한다.

클래스는 혼자 존재하는 것이 아니고 상속, 참조 등 연관 관계를 지니게 되는데, 이 또한 다이어그램으로 표시할 수 있다. 예시는 아래와 같다.

연관 관계에는 아래와 같은 관계가 있다.

  • One-to-one : 일대일 관계
  • Many-top-may : 다대다 관계

일반화 관계의 경우 두 가지 이상의 서브 클래스로 구체화시키는 것이다. 즉, 공통되는 부분을 상속으로 가진다. 필자는 코딩할 때 중복을 제거하는 것이 가장 근본적인 자세라고 생각하는 편이라, 상당히 적용하기에 중요한 스킬이다.

다만 이것에 매몰되어 인스턴스 등으로 해결할 수 있는 부분을 무리하게 상속 구조로 바꾸는 것은 주의하여야 한다.

마지막으로 일련의 과정을 정리해보면 아래와 같이 진행할 수 있다.

클래스 후보 선정 -> 연관 관계/속성 추가, 일반화 관계 파악, 클래스의 의존성 파악 -> 오퍼레이션 파악 -> 설계 패턴 적용

이 때, 위 과정을 한 번만 하고 끝나는 것이 아니라 추후 필요할 경우에는 과정을 반복하여 모델링하여 패턴 적용이 필요하다.

'Development > Software Architecture' 카테고리의 다른 글

[소공] 요구분석  (0) 2021.03.27
[소공] 객체지향의 개념  (0) 2021.01.24
[소공] 소프트웨어 공학의 개요  (0) 2020.04.19