WCF=SOA 에 대한 고찰

Architect Development 2010.07.21 08:30 Posted by POWERUMC

사실 필자는 SOA(Services Oriented Architectures) 에 대해서 심도 있게 알고 있는 전문가는 아닙니다. 전문가는 아니지만 WCF=SOA 에 대해 제가 알고 있는 작은 부분으로 WCF=SOA 를 오해하거나 잘못 알고 계신 분들이 있는 것 같아, 이 부분을 바로 잡아 보려고 합니다.    

우선 SOA(Services Oriented Architectures) 는 직역하면 "서비스 지향 아키텍처"라고 부릅니다. 서비스 지향 아키텍처는 서비스를 제공하는 벤더(Vender) 또는 프로바이더(Provider) 를 통해 유연한 서비스를 제공하거나 제공 받는 아키텍처를 말합니다. 그리고 이 SOA 와 가장 연관 깊은 것이 바로 XML 웹 서비스(Web Services) 입니다.    

XML 웹 서비스는 특정 벤더나 프로바이더를 통해 서비스를 제공 받고, 표준으로 채택됨으로써(http://www.w3.org/2002/ws/) 플랫폼 간의 상호 운용성을 높인 기술입니다. 어떤 운영체제와 플랫폼이든 이 메시지를 이해할 수 있는 텍스트(Plain Text)로 이루어진 XML 과 WSDL, XSD 스키마를 사용하여 해석되는 것입니다. 이것을 가리켜 SOAP 프로토콜이라고 합니다. (사실 Microsoft 만큼 SOAP 을 잘 구현한 벤더는 없습니다. 유효성 검사를 해 보면 정말 엉망으로 구현하는 곳이 의외로 많습니다)    

 

그리고 .NET Framework 3.0 부터 WCF(Windows Communication Foundation) 이라는 기술이 출연하게 됩니다. 그리고 많은 사람들은 .NET 리모팅, XML 웹 서비스, TCP/UDP(UDP는 .NET 4.0 에 포함됨) 등을 통합한 프레임워크가 WCF 라고 이해하고 있습니다. 더불어 SOAP 뿐만 아니라 JSON, REST 방식의 통신 레이어 행위(Behavior)를 지원함으로써 "서비스 지향 아키텍처"라고 말하기도 합니다.    

필자는 이러한 SOA 에 대해서 작은 지식을 가지고 있지만, WCF 와 SOA 와 연관 관계를 지어 대화를 하게 될 때 매우 서먹하기도 합니다. 왜냐하면 바라보는 기술의 관점이 틀리기 때문에 말입니다.    

일단 용어를 명확히 하자면, SOA 는 어떤 명확한 구현 또는 산출물의 기술이 아닌 이상적인 아키텍처 측면을 의미합니다. 그리고 이상적인 아키텍처를 이야기 할 때 양자간의 관점이 틀릴 경우, 사실 그만큼 대화하기 힘든 것도 없었던 것 같습니다.

   

그렇다면, 여기에서 한 가지 궁금한 것이 생깁니다. XML 웹 서비스, WCF 둘 다 서비스 지향적인 아키텍처인가요?

먼저 일부 WCF 를 가리켜 SOA 라고 인지하는 분들의 경우, REST나 JSON 같은 경량화된 데이터 포멧(Data Format) 을 지원하기 때문에 서비스 지향적이라고 말합니다. 이것은 즉, 클라이언트가 웹 브라우저든 어떤 형태건 간에 선택적인 데이터 통신이 가능하다는 의미입니다. WCF 에서는 아주 간단하게 SOAP 데이터를 REST 방식이나 JSON 방식으로 쉽게 전환할 수 있죠.

또, 어떤 사람들은 여러 가지 통신 프로토콜을 통합하였기 때문에 서비스 지향적이라고 말합니다. .NET 리모팅이나 XML 웹 서비스, MSMQ, COM, COM+ 등을 통합했다는 이유로 말입니다.

   

그럼, 다시 질문하자면, XML 웹 서비스는 JSON 과 REST 를 지원하지 못하는 것일까요?

답변은 XML 웹 서비스는 이 과정을 .NET Framework 에서 기본적으로 제공하지 않을 뿐이지, 충분히 가능합니다. XML 웹 서비스는 통신 레이어 이전에 직렬화 및 역직렬화(Serialization/Unserialization) 과정을 거치는데, 이 과정에서 SOAP 을 REST 또는 JSON 으로 직렬화/역직렬화 하면 가능합니다.    

...

   

그렇다면 도대체 뭐가 서비스 지향적인 아키텍처인가?

일반적으로 일부 사람들이 이해하는 WCF 는 어떠한 방법으로도 서비스 지향적인 아키텍처를 제공하지 않습니다. 왜냐하면 WCF 든 XML 웹 서비스든 그 내부를 이해하지 못하고 사용한다면, 통신 프로토콜만 다를 뿐, 똑같은 XML 웹 서비스에 지나지 않기 때문입니다.    

필자는 서비스 지향 아키텍처에 WCF 에 한 표를 던져 주고 싶습니다. WCF 는 기본적인 환경에서 서비스 지향적인 프로그래밍을 제공해 주지는 않지만, 이미 WCF 프레임워크의 내부는 서비스 지향적인 아키텍처로 설계가 되었기 때문입니다.    

그렇다면 우리는 WCF 의 특징을 다시 한번 살펴볼 필요가 있습니다.

   

이렇듯 WCF 프레임워크는 다양한 기능을 제공합니다. 즉, 이러한 프레임워크를 알지 못하고서는 WCF 는 단지 XML 웹 서비스에 불과하다는 것과 같습니다.

   

SOA 에 좀 더 접근하기. ESB(Enterprise Services Bus)…

사실 SOA 는 아키텍처 측면의 용어로써 그 의미를 해석하는 것에 따라서 서로간의 바로 보는 관점이 다를 수 있습니다. SOA 를 이해함에 있어서 XML 웹 서비스도 WCF 도 SOA 에 해당됩니다.

하지만 SOA 적인 아키텍처를 좀 더 구체화한 것이 바로 ESB(Enterprise Services Bus) 라고 보셔도 좋습니다. SOA 를 적용하고 아키텍처링함에 있어서 최소한의 요구 사항을 충실히 구현한 것이 바로 ESB 입니다.    

ESB(Enterprise Services Bus) 에 대해 잘 설명해 놓은 아래의 글을 참고 하십시오.

제 1부 : 서비스 포트폴리오의 구현
제 2부 : Enterprise Service Bus 를 이용한 서비스의 연결

   

즉, ESB(Enterprise Services Bus) 는 서비스 가상화(Services Virtualization) 을 통해 중앙 집약적인 정책을 수립하여 적용하는 것입니다. 서비스의 제공자와 서비스의 소유자간의 명확한 계약(Contracts) 을 통해서 정책적, 중앙 집약적인 서비스가 가능한 것이 ESB 의 모티브이기도 합니다. 바로 서비스 가상화는 이 두 사이의 명확한 계약 관계가 성립됨으로써 가능한 것입니다.    

또한, 서비스 가상화를 통해서 서비스를 재조합(Recomposition) 이 가능한 것 또한 ESB 의 특징이기도 합니다. 서비스의 제공자와 서비스의 소유자 간의 명확한 계약 관계가 성립됨으로써 서비스의 제공자를 다른 서비스로의 전이, 신규 서비스 창출, 서비스의 조합이라는 것이 가능합니다.    

필자는 이러한 ESB 에 좀 더 가까운 개발 프레임워크를 만들기 위해 아래와 같은 프레임워크를 개발한 적이 있습니다. (아래는 관련 업계에 재직 당시에 개발했던 프레임워크입니다)

DxEF.Proxy.Dynamic 프레임워크 개발
DxEF.Proxy.Dynamic.SoaServices 프레임워크 개발

 

첫 번째로, 명확하게 서비스(Services) 와 서비스의 계약(Services Contracts or Interface) 를 구분함으로써 서비스의 소유자와 서비스의 제공자를 구분하였고, Dynamic Proxy 기법을 통해서 동적인 서비스적인 측면을 지향하였습니다.    

다시 말하면, WCF 는 SOA 를 위한 인프라스트럭처(Infrastructure) 를 제공할 뿐이지, XML 웹 서비스와 같이 '서비스 참조' 기능만 이용한다면 그것은 그냥 XML 웹 서비스와 크게 다를 바가 없다는 의미입니다.    

   

좀 더 서비스 지향적인 서비스를 위해...

이미 .NET Framework 는 더 이상 연습하고 학습하는 것만으로 습득할 수 있는 기술이 아닙니다. 마치 수십 수백 권의 "백과 사전" 수천 페이지가 바로 .NET Framework 입니다. 그 백과 사전이 바로 MSDN Documents Library 입니다.    

.NET 기술을 올바르게 사용하는 것은 매우 쉽습니다. 왜냐하면 MSDN 은 너무나도 자세한 부분과 샘플까지 제공하기 때문입니다. 더 중요한 것은 기술을 올바르게 이해하고 활용하는 것이지, 남용을 한다면 .NET 기술은 그저 그런 기술 밖에 되지 않습니다. 마치 .NET vs Java 를 도마 위에 올려 놓고 100분 토론을 하는 것처럼 말이죠.   

필자는 아마도 "서비스 지향적인 아키텍처"가 아니라 "서비스 지향적인 서비스"에 좀 더 초점을 맞추고 .NET 기술이 나아갈 방향을 고민해야 할 시점이 아닌가 생각합니다.

저작자 표시 비영리 동일 조건 변경 허락
신고

때는 바야흐로 2009년 7월이네요. Velocity 를 공부하면서 메모해 놓은 것을 이제서야 발견하여 포스팅을 하고 있습니다. ^^;

현재는 Windows Server AppFabric 이라는 이름으로 공개가 되고 있으며, 코드명은 바로 "Velocity" 라는 이름입니다. 현재 AppFabric Beta 1 까지 출시되었고 이제는 거의 모습을 찾아가고 있는 것 같습니다. 차후에 Velocity 의 현재 제품이름인 AppFabric 을 자세히 살펴보기로 하며, Velocity CTP 3 기준으로 설치와 사용 방법을 간단히 알아보고자 합니다.

   

Why Windows Server AppFabric (Codename "Velocity") ?

Velocity 는 분산 캐싱 프레임워크입니다. 우선 분산 캐싱이 왜 필요한지 이해가 필요합니다. 기존에는 캐싱이라고 함은 in-proc 캐싱을 의미했으며 즉 메모리 상에서 객체를 캐싱(Caching)하거나 풀링(Pooling)하기 위해 시스템의 리소스(Resource) 를 사용했습니다.

하지만 점차 엔터프라이즈 솔루션은 대규모, 대용량화 되어감에 따라 in-proc 캐싱은 시스템 리소스나 성능에 영향을 받게 되었습니다. 기존의 엔터프라이즈 솔루션은 데이터베이스의 대용량 아키텍처에 민감했고, 즉 데이터 중심의 아키텍처링을 할 수 밖에 없었습니다. 데이터의 정합성, 안정성, 성능은 기업에서 돈(Money) 와 직결되는 문제이기 때문이죠.

하지만 이미 데이터와 관련된 기술과 노하우는 이미 포화 상태이고, 엔터프라이즈 전체적인 아키텍처를 보았을때 단지 병목은 데이터에서만 존재하는 것이 아니었다는 것입니다. Middleware 나 Application Server 의 아키텍처링도 이미 포화 상태이고, 이것을 극복하기 위해서는 바로 캐싱(Caching) 이라는 기술이 필요했습니다.

위에서도 언급하였듯이 in-proc 캐싱은 굉장히 단순한 아키텍처입니다. 서버의 리소스가 받쳐 주느냐 그렇지 않느냐의 문제였고 in-proc 그리고 더 나아가 out-proc 를 이용하여 서버 자원을 최대한 활용하고자 합니다. 하지만 여기에서 또 문제가 발생합니다. 분산 out-proc 캐싱을 하자니 분산된 캐싱 데이터의 정합성을 어떻게 보장하느냐 입니다. 즉, out-proc 로 인해 캐싱은 중앙 집중화가 될 수 밖에 없으며 이것은 서버의 리소스에 의존하는 문제의 원점으로 돌아간다는 것이죠.

   

About Windows Server AppFabric (Codename "Velocity")

이러한 엔터프라이즈 환경의 서비스 확장에 대해서 고질적인 문제였던, 그리고 성능을 극대화 할 수 있는 캐싱이라는 기술을 어떻게 활용하느냐에 관심을 갖게 되었습니다. 현재 이런 문제를 해결할 수 있는 솔루션이 Windows Server AppFabric(Codename "Velocity") 입니다.

데이터의 정합성, 안정성, 성능은 기존의 아키텍처를 버리고 전용 Repository 를 통해 해결할 수 있습니다. 그것은 데이터베이스가 될 수 있고, 그 밖에 다른 Repository 가 될 수 도 있겠죠. 바로 이러한 컨셉은 캐싱을 어떤 분산 시스템간이라도 공유한다는 의미입니다. 이러한 캐싱을 클러스터링한다는 것은 흔히 Caching Dependency 를 해결할 수 있는 아주 좋은 해결 방법이기도 합니다. 어떤 로컬 시스템이건, 어떤 원격 시스템이건 캐싱 정책을 적용받게 되는 것입니다.

   

   

   

Install Windows Server AppFabric (Codename "Velocity")

아래는 필자는 게으름으로 Velocity CTP 3 기준으로 설치하는 방법입니다. (지금이라도 포스팅 하는걸 보면 대견스럽습니다만;;;)

기본적으로 캐싱 데이터는 데이터베이스를 사용합니다. 데이터베이스의 파일이 저장이 될 경로를 입력하거나 Storage 타입을 정하시면 됩니다.

 

   

저작자 표시 비영리 동일 조건 변경 허락
신고

 

안녕하세요. ^^

 

그 동안 바쁘다는 핑계로.. 소원 했던 글쓰기를 다시 합니다. 제가 이 글을 쓰는 시점에서는 Visual Studio 2010 버전이 드디어 베타 2를 기준으로 합니다.

 

첫번째로 드디어 모델링에 대한 것을 이야기 하게 되었습니다.

모델링.. 기존에 사용하고 계시는 모델링 도구는?? 어떤것이였나요? 저는 대 부분 Visio로 UML을 하거나, XP화면을 직접 그리는 것을 했습니다. 여러분들은 그 외 다른 도구들을 사용하실거나, 저와 비슷할 거라 생각합니다. 또는 더 오래되신 분들은 별도의 프로그램등을 이용하여 S/W 모델링을 하실거라 생각합니다.(대 부분 별도의 프로그램이 많을 것이란 예상을 합니다^^)

 

모델링은 정확히 우리가 만들고자 하는 플랫폼을 정확히 그림을 그린 다음, 사용자의 요구사항에 맞는 부분을 글이 아닌 그림을 이용하여 표시하고, 개발자들에게는 그 사항에 맞는 부분을 그림으로 표현하여 실제 만들고자 하는 솔루션으로 한눈에 알아보기 쉽게 그리는 것입니다.

 

Microsoft의 VS 2005의 아키텍쳐 버전은 사실 이 부분을 충실히(?) 지켰고 실제 응용 프로그램 개발에 필요한 부분일 모델링 할 수 있었지만, 그것을 대중적으로 하기에는 조금 부족했다 할 수 있습니다.

여기서 대중적이란 실제 프로젝트에서 사용하는 것은 UML로 그리고 문서화하고, 개발자는 클래스 다이어그램을 그리거나 이미 그린것을 참고로 개발하는 환경이였습니다.

그렇다고 실제 문서화한 UML 처럼 응용 프로그램들이 개발되었다고 장담은? 네 저 역시 실제 프로젝트를 해보면 절대 하지 말라고 하는 코딩 부터 하고 난 다음 설계를 하는 방법을 쓰거나 설계는 하지 않고 넘어 경우, 또는 설계는 설계, 개발은 개발로 설계와 다른 산출물(응용 프로그램)이 나오는 일을 많이 헀습니다.(조금 부끄럽습니다 ㅠ.ㅠ)

 

이제 VS 2010 에서는 모델링에서 일반적으로 사용한 UML을 지원하게 됩니다. 기존의 모델링은 대중적인 것이 부족했다면 이번 Visual Studio은 현재 우리가 하고 있는 업무에 도움이 되는 것을 지원하고 있습니다.

 

Visual Studio 2010에서 모델링을 위하여 이제 VS 2010을 실행하여 프로젝트를 만듭니다.

프로젝트는 File-> New -> Project  선택합니다.

 

선택하면 프로젝트를 만들 수 있는 창이 뜨며 이곳에서 왼쪽 메뉴에의 "Rectnt Templates" 에서 "Modeling Prjects"를 선택합니다.



 

선택하면 프로젝트를 만들 수 있는 창이 뜨며 이곳에서 왼쪽 메뉴에의 "Rectnt Templates" 에서 "Modeling Prjects"를 선택합니다.

 

이 화면에서 각각의 정보를 입력합니다. 

 

이름 : BookshoppingMallUML

Location : 특정위치

Solution :  Default

Solution Name : BookshoppingMall 

 

이제 여기에서 새로운 UML 모델을 그릴 것을 추가합니다. 추가는 첫번째는 Use Case를 추가하여 사용자의 요구사항에 맞는 그림을 그립니다.

그 다음이 중요 포인트 입니다. 무엇인지?? 한번 보시죠.



이제 여기에서 새로운 UML 모델을 그릴 것을 추가합니다. 추가는 첫번째는 Use Case를 추가하여 사용자의 요구사항에 맞는 그림을 그립니다.
그 다음이 중요 포인트 입니다. 무엇인지?? 한번 보시죠.


 

네 바로 유스케이스 다이어그램으로 통해 제가 그려 보았는데 잠시 힌트를 드리자면..

다이어그램을 그린 것을 작업항목에 바로 연결할 수 있다면 어떻게 될까요??

네 Architect 개발에서 그림을 그린것을 작업항목에 연결하여 TFS 서버와 연결할 수 있고, 이 작업항목은 기존에 알고 있는 TFS의 작업항목이라면??? 이것이 Architect 개발의 시작점 입니다. 뭐?

바로 UML로 그린 다음 이것을 작업 항목으로 연결하는 것이 시작점 입니다.

 

정말 그런지는 바로 다음 화면에서 확인 가능합니다.



 

액터를 그려서 그 액터에 해당하는 작업항목을 생성할 수 있습니다. 앞에서 제가 설명한 그대로 인거죠?

(액터가 졸라맨이 아닌... 이쁘장한 그림으로 ㅎㅎㅎ 옛날엔 졸라맨 이였는뎅 ㅋㅋㅋ)

 

그렇다면 이게 시작점 이라고 했습니다. 네 여기서 제가 몇가지 더 그린다음 이제 TFS와 연결하고 이것을 작업항목으로 연결하려 합니다.

연결하여 작업하는 것은 2번째에 하기로 하고, UML 설계를 것을 TFS 저장한다는 것은 이제 문서화하기 설계된 것도 TFS 저장소에 저장하고 이를 언제든지 활용할 있으며, UML이라는 대중적인 지원으로 이제 Visual Studio 에서도 모델링을 이용한 설계를 하고 바로 개발 까지 이여야 있습니다. 그럼 이제 다음으로 넘어가 2번째 부분을 하는데.. 이건 .Soon 입니다.^^

바로 올리겠습니다. TFS 연동한 모습을. ㅎㅎㅎ 금주에 다시~~


 

신고
Architect Development 의 시작은 무엇일까 생각하다가 우선 모델링 관련 부분부터 해야 겠다는 마음으로 이글을 작성하게 되었습니다. 이 글을 시작하기 전 우선 글의 성격은 Architect Development 개발의 시작으로 모델링 기반의 개발이 좋을 것 같고, 제 나름대로 프로젝트를 해 보니 문서를 기반으로 프로젝트를 시작하고 개발자들과 문서를 보면서 개발 회의를 하는 것과 또는 강의 할 때 실제 프로그램이 돌아가는 것을 보고 난 다음에 모델링 도구를 이용하여 프로그램이 운영되고 있는 영억이나 구조를 설명하면 개발자분이나 교육을 듣는 분들이 이해를 빠르게 했기 때문입니다.

그럼. 첫 시작으로 모델링을 선택하고 UML 기반의 모델링을 소개하는 것은 일반적으로 학교에서 UML은 어느 정도 접하고 졸업한 개발자분들도 있고, 개발을 오래 하다보면 UML 로 그린 다어이그램들을 보신 경우가 많기 때문입니다. 처음 발표된 VSTS 2005 는 UML이 아니라 다른 기반의 모델 기반 개발을 지원 했습니다. 저는 Visual Studio 2005에 처음 접하였지만, 그 전에는 UML을 Visio로 그리고 실 개발을 Visual Stduio 2003으로 했습니다. 개발할 때 설계를 봤을 까요? 제가 솔직히 이야기 하면 저도 100% 다 보지 않고 요구사항이 변경되거나 구조가 변경되면 먼저 코드를 작성하고 추후 Visio로 변경해야지 하는 마음만 먹고 하지 않았습니다.

VSTS의 새로운 제품은 이제 그렇지 않지 않아도 됩니다.

VSTS 2010의 Architect 부분에서는 UML을 지원하고 이 모든것이 TFS 제품과 연관이 됩니다. 개발자는 이를 확인하고 실 개발에 반영하거나 반영된 것을 아키텍처가 변경하거나 개발자가 바로 변경할 수도 있다는 것입니다.

이런 이유로 제가 첫번째 모델링을 이야기 하고 모델 기반 개발에 대하여 소개하도록 하겠습니다.

PS. 전 모델 기반 개발이 선택이 아닌 필수로 생각합니다. 그렇지 않으면?? ㅎㅎ 추후 글로..
이제 시작입니다.
신고

Architect Development ?

Architect Development 2009.07.21 18:04 Posted by 비회원


Architect Development 을 위하여 무엇을 해야 할가요?
아니 Architect Development 이란 영역은?

우리가 흔히 개발을 한다고 하면 보통 요구사항 분석, 설계, 개발, 테스트 및 디버깅, 배포를 끝으로 그 다음 유지보수를 합니다. 유지보수에서는 개발, 테스트 및 디버깅 재배포 등의 단계를 거치게 됩니다.
그렇다면 여기서 앞 부분은 요구사항 분석, 설계 부분은 유지보수에서 빠지는 것일까요?

답은 " 아닙니다 " 겠죠? 그렇다면 요구사항 분석, 설계 부분이 빠지는 이유는 개발이 완료되고 배포되어 사용자가 사용하고 있는 중에 문제가 오류가 발생하여 개발자 분들이 수정하고 다시 테스팅 및 디버깅 후 배포하는 것입니다. 프로그램이 사용중에 오류가 발생하지 않고 고객 또는 사용자가 새로운 기능을 요구하였을 경우에는 어떻게 할까요?

여기서 옛날에 했던 요구사항 분석, 설계 부분을 돌아보게 됩니다. 그러면, 제가 지금까지 보아온 회사 중에서는 설계가 잘되어 있고, 요구사항 분석도 잘 되어 있어 모든 것이 일사 천리로 일이 진행 된것을 볼 수 있었습니다. 그렇지 않은 회사를 보면 어떻게 될지는 이 글을 읽는 개발자 분들이 더 잘 아실거라 생각합니다. 그럼 아키텍쳐 개발은?

아키텍처란 용어는 영한 사전에서보면  일반적으로 "건축, 천축술, 천축 양식, 구조"라고 번역합니다. 그렇다면국어사전은? 기능 면에서 본 컴퓨터의 구성방식이라고 설명합니다.(네이버 국어사전 참조) 여기서 아키텍쳐란 구조, 구성이라는 용어로 한번 보겠습니다.

구조, 저희가 개발하는 시스템에 대한 정확인 요구사항에 맞는 분석과 이를 기반으로 정확한 구조, 구성이 된 설계가 있다면 어떨까요? 이 설계의 기본적인 구조는 Windows 플랫폼에 PHP 개발, 아니면 ASP.NET 개발등으로 예를 들어 보고, 기본적인 구조를 정확히 정의하고 이를 표현할 수 있으며, 많이 사용하는 방법으로 표시하여 개발자들과 협업, 의사 소통이 이루어 질 수 있다면 어떨까요?

전 이 해답을 Visual Studio Team System(VSTS) 에서 찾았다고 생각합니다. 제가 MS 쪽 제품 중에 VSTS를 좋아하는 이유 중에 바로 Architect Development이 가능하게 해준다는 것입니다. 다른 제품 쪽도 있고 저 역시 다른 사이트에서 많은 자료를 봅니다.(다른 사이트의 Meet the Experts등 여러 사이트가 있습니다. 단 영어 입니다 ㅠ.ㅠ)

옛날 VSTS는 업계가 많이 사용하는 UML를 지원하지 않고 다른 모델링 도구등을 이용한 설계를 할 수 있도록 했습니다. 기능은 매우 훌륭했지만... 많은 사용자가 이것을 사용했을까 하는 것입니다. 지금은?

VSTS 에서도 이제 UML도 지원한다..

그럼? 네 Visio 같은 도구로 그림을 그리는 것이 줄어들었다는 것입니다. 그리고 VSTS에 통합되므로써 개발자들과의 의사소통, 협업이 가능하다는 것이 매우 좋아졌다는 겁니다. 프로젝트에서 대부분 아키텍쳐는 무시되고 요구사항이 수시로 바뀌는 등등 매우 많은 일들이 생겨나는데 이것을 대응할 수 있다는 것입니다.
업계에서 많이 사용하는 UML은 학교에서 S/W를 전공한 사람은 모두 한번씩 배웠던 것이고, 이를 이용하여 개발자들과 협업을 통해 고객의 요구사항을 능동적으로 대처할 수 있고, 실제 설계에 반영할 수 있습니다.

이런 매우 좋아진 이 VSTS 2010에 대하여 이제 부터 제가 하나씩 하나씩 알아보고 여러 분들에게 소개를 하겠습니다. ^^ 다음 은 그럼?? VSTS 2010의 모델링 개발에 대하여 이야기 하겠습니다.

신고