소프트웨어 모델링이란?

티스토리 메뉴 펼치기 댓글수0

출판

소프트웨어 모델링이란?

Justine
댓글수0
지금까지 소프트웨어 모델이 뭐고 소프트웨어 모델링은 뭐하는거냐라는 질문에 우리는 일반적인 답변을 먼저 해 주고 슬며시 우리의 생각을 말해왔습니다. 사람들은 자신이 알고 있는 것과 다른 이야기를 하면 심하게 공격적이 되는 경우가 있는데 이러한 공격을 받고 대응해야 하는 것이 귀찮았기 때문입니다. '때가 되면 깨닫겠지' 라고 생각하면서 슬며시 발을 빼는 겁니다.

우리의 생각은 일반적인 답변과 많은 부분에서 다르기 때문에 둘 사이에 충돌이 일어나곤 했습니다. 우리는 다양한 사람들과 이에 대해 논해 오면서 오랜 시간 고찰을 해 왔습니다. 이제 우리도 이해할 수 없는 일반적인 이야기를 걷어내고 우리의 생각을 말하려고 합니다.



소프트웨어 모델링과 소프트웨어 모델
모델에는 패션모델이나 회화나 조각의 대상이 되는 사람모델도 있고 자동차나 건축 모형과 같은 모델도 있습니다. 복잡한 현상을 개념적으로 표현하는 과학모델도 있습니다. 소프트웨어 모델은 이러한 모델과 어느 정도 유사한 의미를 갖기도 하지만 많은 부분에서 다르기 때문에 이들과 구분해서 이해할 필요가 있습니다.
소프트웨어는 추상적 형태를 갖고 사고법 모델(메타모델)에 따라 모델링하는 독특한 특징을 갖고 있기 때문입니다.

소프트웨어 개발은 문제해결이다.
고객(도메인)의 문제를 이해하고, 소프트웨어로 해결하는 것이다. 문제를 이해하고, 해결책을 설계하기 위해서는 문제와 해결책을 구성하는 실체를 알아야 합니다.
문제는 트러블의 의미도 있지만 오늘날의 상황에서는 기회, 도전거리의 의미에 더 가깝다.

소프트웨어 개발은 복잡한 문제해결이다.
현대사회의 특징 중 하나는 복잡성이다. 복잡다단하게 얽힌 현대사회의 현상들을 인간들이 한 번에 이해한다는 것은 실로 어려운 일이 되었다. 소프트웨어 개발의 복잡도가 높아지는 이유 또한 여기에 있다. 소프트웨어를 개발하기 위해서는 먼저 현실세계의 문제를 이해해야하기 때문이다.
해결책으로 사용될 소프트웨어 기술 또한 점점 복잡해지고 있다. 

모델링은 모델을 만들어 복잡한 대상을 이해하는 사고법이다.
복잡한 문제해결인 소프트웨어 개발을 성공적으로 이끌기 위해서는 복잡한 현상을 다수의 관점으로 분리하고 각 관점에서 요구하는 필수적인 것에만 초점을 맞추어 생각하는 방법이 필요하다. 이렇게 복잡한 대상을 다수의 관점(view)을 갖고 추상화(abstraction)해서 개념적으로 표현한 것을 모델이라 하고 모델을 만들기 위한 사고법을 모델링이라 한다.

사고법 또한 모델을 가질 수 있다.
복잡한 사고법은 사고법 자체에 대한 모델을 가질 수 있다. 모델을 만들기 위한 사고법 모델을 메타모델이라 한다. 

소프트웨어 개발에있어 최고의 사고법 모델은 객체모델이다.
객체모델은 문제를 이해하고 해결책을 설계하는데 있어 동일한 사고법을 사용한다. 이는 소프트웨어 개발과 같이 문제 영역이 해결책 영역과 상이하고 복잡한 경우에 사고법이 갖추어야 할 필수적인 조건이 된다. 
객체모델링은 객체모델에 따라 소프트웨어를 모델링하는 것이다.

모델은 모델링 언어로 표현된다. 

그래픽 모델은 다이어그램으로 표현된다.

UML은 그래픽 객체모델링 언어이다. 

UML은 객체모델을 구성하는 개념들에 대한 그래픽 표현방법을 제공한다.




무엇을 모델링하는가?

소프트웨어 모델링은 실체를 알아가는 과정이고, 모델은 실체에 대한 이해의 결과이다. 
소프트웨어 모델링은 문제와 해결책을 구성하는 실체를 이해하는 것이다. 이미 존재하는 것에 대한 이해와 앞으로 존재해야 것에 대한 이해다.

소프트웨어 모델은 추상적이다.
소프트웨어 모델은 사고의 결과다. 사고의 본질은 추상적이다. 따라서 그 결과인 모델 또한 추상적이다. 
모델링되는 실체는 추상화된 형태로 도메인 전문가를 통해 언어적으로 설명된다. 도메인 전문가의 입을 통해 전달되는 언어적 실체는 도메인에 존재하는 사실(fact)이다.
소프트웨어는 물리적 장치를 통해 드러나지만 그 자체는 추상적이다.

소프트웨어 개발은 문제해결이다.
문제 이해를 위해 도메인 팩트를 모델링하고 해결책을 설계하기 위해 의사결정을 모델링한다.
객체모델링은 문제 이해와 해결책 설계에 동일한 사고법을 사용함으로 문제 이해의 결과를 해결책을 모델링하는데 그대로 사용할 수 있다. 
객체모델링을 할 경우, 해결책을 구성하는 실체는 문제를 구성하는 실체와 같다. 따라서 해결책을 모델링 할 때는 해결책을 구성하는 실체에 대한 이해 없이 실체를 왜 그렇게 구현할 것인가에 대한 의사결정 만을 모델링하면 된다.

소프트웨어 개발은 추상으로 시작해서 추상으로 끝난다. 소프트웨어 개발이 모델로 시작해서 모델로 끝날 수 있다는 비전이 끝없이 대두되는 이유가 여기에있다.

일반적인 객체 정의에 실세계에 존재하는 tangible한 것을 언급합니다. 그럼 모델링할때 tangible한 것에 신경써야할까요? 아닙니다. 혼란에 빠질뿐입니다. 모델링되는 객체는 추상화된 형태로 도메인 전문가의 입을 통해 전달된다. 실세계 객체는 팩트일 뿐이다.
소프트웨어 객체에 대한 새로운 정의: 소프트웨어 실행시에 존재가능한 독립적으로 식별가능한 사실
도메인 객체에 대한 새로운 정의: 문제영역에 존재하는 독립적으로 식별가능한 사실(fact)



소프트웨어 모델링과 소프트웨어 개발 주기

소프트웨어 개발은 문제해결이다. 고객의 문제를 이해하고 소프트웨어로 해결하는 것이다.
고객의 문제를 이해하기 위해서 문제를 분석하고, 소프트웨어로 해결하기 위해서 해결책을 설계하고 구현한다. 본격적인 구현에 앞서 설계된 해결책이 효과적이고 효율적인지가 검증되어야한다. 검증 결과에 따라 해결책은 대체되거나 보완된다.

설계는 해결책이 가져야하는 구조와 행위에 대한 의사결정이다.
이는 제약사항내에서 문제를 가장 효과적이고 효율적으로 풀기 위한 것이다. 소프트웨어 개발은 대부분의 해결책이 자신만의 독특함을 띄기 때문에 소프트웨어 설계라 했을때 이러한 본연의 설계 의미에 가깝다.
구현된 해결책이 이미 다수 존재하는 경우에 설계는 선택에 대한 의사결정이 된다. 다수의 해결책중에서 문제에 가장적당한 것을 고르기 위해서는 해결책을 분석하고 선택한 해결책에 대한 조합을 설계한다.

의사결정은 기능적 비기능적 요구사항에 직접적으로 관련된 것과 그렇지 않은 것으로 구분된다. 전자는 중요한 의사결정 영역으로 구분되어 아키텍처라 불리고 후자는 설계라 불린다.

오늘날의 대부분 프로그램 언어는 의사결정 수준으로 추상화되어 있고 실제적인 구현은 컴파일러들에 의해 수행된다. 프로그래머들은 프로그래밍 언어를 통해 그들의 설계 결정을 표현한다.
소프트웨어 개발에 있어 해결책은 대부분의 지적작업과 같이 설계 수준의 작업이 대부분이다. 이러한 상황에서 의사결정 수준이 나뉘어 설계 영역이 세분화 되는 것은 당연한 수순이다.

분석가는 분석기술로 모델링을 사용한다. 설계자는 설계기술로 모델링을 사용한다.
모델링은 특정한 개발 주기의 하나가 아니라 복잡한 대상에 대한 사고법이다. 분석가는 분석기술로 모델링을 사용하여 분석모델을 만들고, 설계자는 설계기술로 모델링을 사용하여 설계모델을 만든다. 설계가 세분화되었을 경우 아키텍트는 아키텍처 기술로 모델링을 사용하여 아키텍처모델을 만든다. 모델은 검증이나 구현 기술로도 사용할 수는 있다. 
소프트웨어 모델은 어떻게 고객에게 보여질 것인가(사용, 배치), 어떻게 설계되고 구축될 것인가에 대해 답해야한다. 분석 모델은 개발될 소프트웨어 시스템에 대해서 고객이 궁금해 하는 것이 무엇인지 표현해야 한다. 설계 모델은 고객의 궁금증을 어떻게 풀어줄 수 있은지를 표현해야한다.

맨위로

https://umlcert.tistory.com/489

신고하기