[Software Design] Structural Modeling

이전까진 functional modeling에 대해 봤다. 이번엔 structural modeling에 대해 배운다.

실제 코드로 옮겨지는 상당 부분이 이 structural modeling때 결정된다. 구현할때 나머지 functional/behavioral modeling도 도움을 준다.

 

Functional models는 system behavior에 초점을 맞췄었다.

Structural models는 System Objects와 그들의 relationships에 초점을 맞춘다. 이것이 디자인을 거쳐 코드까지 연결된다.

Functional modeling은 외부 관점에서 시스템을 바라보지만,

Structural model은 시스템 내부에서 "System Object(세부 사항 포함)"와 "그들 사이 관계"를 기술한다.(정보를 중심으로 기술한다.)

Problem Domain의 "중요 data"를 발견하고 "구조"를 표현하는 모델을 만드는 것이 목표이다.

마찬가지로 structural modeling을 할 때도 requirements는 당연히 기반으로 하고, use case라던가 functional의 기능을 참고/update 할 수 있다.

 

모든 OOAD 과정이 그렇지만, 반복적으로 작성된다, 한번에 작성하긴 쉽지않다.

또한 Use case와 같이 개발자와 architects, clients 간의 의사소통을 돕는 수단이다.

 

class diagram이 주된 개념이다.

각 class 간에는 세가지 relationship이 있다.

1. Generalization

2. Aggregation (+ composition)

3. Association

 

<class diagram 그리는 법>

class는 requirement를 기반으로해서 분석한다. 명사는 모두 class의 후보로 올린다. 이때 유의할 것이, object로 명시돼있다면 class로 추상화시켜서 만들어주는게 좋다. 예를들어, "Java Programming is a prerequisite of Software Design Class"라는 예시가 있다면, Java와 SD는 class 이름이 아니다. 교과목이라는 class의 object가 requirements에 표현됐다는걸 catch해야한다.(다시 한번 말하지만 requirements는 완벽하지 않음. 정보를 잘 빼와야한다. 없는 정보는 잘 추론해내야하고..)

일단은 세부사항말고 class들의 이름만 먼저 적고, 각 class 간에 관계가 있는지 확인한다. 있다면 연결하고, (상속 등의) 특정 관계라고 결론지어지면 그에 맞게 표시한다. 몇대몇 관계인지도 파악해서 숫자를 작성한다.

attribute나 operation 같은 세부사항은 나중에 작성한다.(물론 세부사항 작성도 중요함)

초기에 Class diagrams을 그릴땐 requirements의 모든 명사를 class의 후보로 올린다.

이후 정리해나가는 과정을 거쳐 class가 아닌건 쳐내고 간단하게 만드는 것이다. concrete class만 보이도록 한다. 모든 명사가 후보에 있으니 attribute 같은 것도 걸러내야한다. class가 되려면 복합 자료형이여야 한다. attribute같이 변수로 넣을 수 있는건 그냥 class로 따로 안빼는게 맞다.

중요 데이터를 뽑아내서 구조화하는 과정이기때문에, actor랑 혼동해선 안된다. 예를들어 환자 정보를 담는 환자라는 class가 있다고 해도, 이는 use-case의 actor와는 다르다는 것을 주의해야한다. class는 그 actor의 정보를 담는 자료형일 뿐이다.

그리는 자세한 방법 등 세부사항은 ppt ch5 참고..(여긴 그냥 맥만 짚었으니 ppt도 꼭 보기)

 

어떤 관계가 aggregation인지 composition인지 절대적인건 없다. requirements에 따라 둘의 관계가 정해지니, 상대적이다. 자동차-바퀴 관계가 꼭 aggregation으로 정해진건 아니다..

참고로 aggregation/composition을 사용하게 되면, 해당 system의 모~든 object가 속하게 된다는 뜻이니 주의하자.(예를들어 user가 예약이 aggregation돼서 들어가는 예약목록 class와 연결돼있다면, 이 user는 다른 사람 예약 정보도 볼 수 있게 돼버린다.)

두 classes 간에 多대多 관계일 경우 중간에서 연결해주는 Association Class라는게 중간에 있을 수 있으니 잘 생각해봐야한다.

그 이유는 구현시 多대多 관계를 표현하기 힘들기도하고, 보통 그 사이에 관계가 더 있기 때문이다. requirement만 보고 분석하는건 자연어를 분석하는 것이기 때문에 모든 사항이 반영되지 않았을 수 있다.

association class란 두 class 간의 관계에 정보를 나타낸다. 관계에도 정보가 필요하다고 판단되면, 특히 다대다 관계일때, association class가 삽입될 수 있다.

 

참고1  참고2  참고3

를 보면 각 class간 관계들이 정확히 무엇이고 실제로 구현될땐 어떻게 표현되는지 볼 수 있다.

사실 "우리가 설계할때 쓰는 이런 개념을 각 언어에서 지원해준다"가 순서상 맞지

 

 

class diagram을 이용해 실제 object를 만드는 것처럼 object diagram을 그려볼 수도 있다.

이때 각 object간의 관계는 특별한 관계 표시나 다수 표시 없이 그냥 선(link)만으로 연결된다.

이를 통해 class diagram을 검증하고, 추가 내용 등을 식별할 수 있다.

 

 

이렇게 분석할때 쓰인 Class Diagram이 나중에 Design을 할때 Design model로 진화한다.

Design된 Class D만 보고서 바로 코드를 짤 수 있을 정도로 바뀐다.(바꿔야한다.ㅋ.ㅋ)