Seperation of Concerns (걱정거리들의 분리) 줄여서, SoC 라는 용어를 들어 보셨나요? 걱정 거리또는 관심거리의 분할(분리)라고 부르는 데요 🙂
각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다. N – Tier 기반의 Application이 좋은 예라고 할 수 있을 겁니다. (물론 성능적인 이슈도 있지만요)
하지만 이 철학으로 인해 너무나 잘게 클래스들이 쪼개져서, 실제 프로젝트를 할때 기능 하나를 추가하기 위해 여러개의 객체를 수정해야 하는 엄청난 고통을 가져오는 상황이 발생합니다 발생하기도 합니다.
분산 객체를 개발한신 분이라면 느낌이 바로 오실건데요. 특히 CORBA 와 같은 경우는 HelloWorld 하나를 찍기 위해서 IDL 컴파일러가 생성한 class들이 무려 9개나 됩니다. 그나마 IDL과 같은 컴파일러가 있어서 망정이지 이것까지 없었다면, 하나의 시나리오를 위해 이 9개의 클래스 파일을 만들어야 합니다.
또한 전형적인 Layered Architect를 따르는 SI 프로젝트 같은 경우도 좋은 예 입니다.
모든 Parameter를 통합해 놓은 DTO 객체, Business Logic, Data Access Logic, 그리고 어떤 상황에 따라서는 분산객체나 Networked 기반의 접근 모듈로 구성되기도 합니다.
즉 하나의 시나리오를 구하기 위해 이 모든 객체를 다 생성하고 구현하는 노가다를 할 경우가 종종 있습니다. 자 여러분은 이런 경우 어떻게 대쳐 하시나요? 여러가지 Tip들을 공유하고자 합니다.
1. 코드 생성 라이브러리를 이용해라
.NET에서는 드를 생성을 도와주는 툴로써 CodeDom이라는 것이 있습니다. Reflection으로 Dynamic Class를 만드는 것 처럼 Class를 생성해주는 도구 입니다.
public void CreateCodeDomBriefcase()
{
//Initialize CodeDom Variables
Stream s =
File.Open("c:\\" + m_strFileName + m_Suffix, FileMode.Create);
StreamWriter sw = new StreamWriter(s);
CSharpCodeProvider cscProvider = new CSharpCodeProvider();
ICodeGenerator cscg = cscProvider.CreateGenerator(sw);
CodeGeneratorOptions cop = new CodeGeneratorOptions();
//Create Class Using Statements
CodeSnippetCompileUnit csu1 =
new CodeSnippetCompileUnit("using System");
CodeSnippetCompileUnit csu2 =
new CodeSnippetCompileUnit("using System.IO");
cscg.GenerateCodeFromCompileUnit(csu1, sw, cop);
cscg.GenerateCodeFromCompileUnit(csu2, sw, cop);
sw.WriteLine();
//Create Class Namespaces
CodeNamespace cnsCodeDom = new CodeNamespace("CodeDom");
//Create Class Declaration
CodeTypeDeclaration ctd = new CodeTypeDeclaration();
ctd.IsClass = true;
ctd.Name = "Briefcase";
ctd.TypeAttributes = TypeAttributes.Public;
//Create Class Member Fields
sw.WriteLine();
CodeMemberField cmfBriefcaseName =
new CodeMemberField("string","m_BriefcaseName");
cmfBriefcaseName.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseName);
........
}
자세한 내용은 http://www.15seconds.com/Issue/020917.htm 을 참고하시길 바라며, .NET 기반의 언어에서만 작동하며 어느 정도 정형화된 틀을 가진 Class에서만 재 생성이 가능합니다.
여러분 프로젝트에 맡게 CodeDom을 이용하여 코드를 생성할 수 있는 별도의 툴을 제작해야 됩니다. 하지만 여러개의 Class를 생성하고 이 Class간에 다양한 Relationship을 나타내기에는 약간 부족한 감이 있습니다.
Java는 이와 유사한 기술로 cglib (Code Generation Library)가 있습니다.
2. Code Snippets
Codedom에서 좀더 진화한 툴로써 macro와 같이 코드의 특정 부분을 대치해 나가면서 찍어내는 툴입니다.
현재 VS2005 ~ 2010 까지 지원하며 다양한 .NET의 코드 조각들을 지원합니다. 언어별 (C#, VB.NET) 그리고 각 언어에 속한 프로젝트 타입별로 여러 코드 조각들 (Code Snippets)이 존재하는데요. 도움이 되니 한번 사이트( http://snippeteditor.codeplex.com/)를 방문해 살펴 봐 주시기 바랍니다.
역시 Codedom과 유사하게 Class간에 Relationship을 생성하는 부분과 전체적인 코드들의 파악을 단순히 Title 로 외우고 있어야 해서 저 같이 기억력이 좋지 않은 사람은 힘들죠.
3. 모델링 툴을 이용한 객체 생성 기법 활용
사실 제가 가장 강조하고 싶은 부분은 이부분입니다. 모델링 툴을 이용해서 코드 자동화를 하는게 가장 이상적이라고 생각합니다.
이 정보도 역시 제가 아니라 10년차의 대선배가 전수해 주신 비기죠 🙂 (문기수 책임님 감사합니다. )
많은 분들이 모델링 툴이 생성하는 코드들이 대부분 껍데기 (외부로 노출되는 Interface 정도)만 만들어 줘서, 얼마나 도움이 되겠냐고 물어 보기도 합니다. 하지만 생각 이상의 생산성을 얻을 수 있을 뿐만 아니라, 코드로 생각하는 습관에서 모델(설계)의 입장에서 생각하는 장점까지 얻을 수 있습니다.
여러분이 Java 개발자이며 Java만 하신다면 CodeGear의 JBuilder나 Together를 사용하길 권해드립니다. 강력한 역공학을 지원하기 때문인데요. 여러분이 구현부까지 다 구현한 ConcreteA 클래스가 있다면, 이 클래스를 복사해서 ConcreteB 클래스를 만들면 실제 구현부까지 그대로 복사가 됩니다. 물론 Operation (Method)를 복사해도 그대로 복사가 됩니다. 그렇기 때문에 여러분이 자주 쓰는 코드의 뼈대와 어느 정도의 소스 코드를 구현해 놓으시고 CV 신공으로 찍어내신 다음 코드를 생성하면 아주 높은 생산성을 얻으실 수 있습니다.
그러나 과연 우리가 하는 프로젝트에서 .NET만 Java만 하는 Case가 많을까요? 조금만 덩치가 커져도 하나의 플랫폼으로 가는 경우가 거의 드뭅니다.
그래서 다양한 언어와 플랫폼에서 프로젝트를 하시는분이라면 SparxSystems의 Enterprise Architect(이하 EA)를 추천해 드립니다. EA는 Code Template SDK라는 것을 지원해 정형화된 프로젝트에서는 거의 코드를 Software Factory 수준으로 찍어낼수 있습니다. 특히 SI에서는 최고의 생산성을 보장합니다.
예를 들어 DB에 접근하는 DAO 객체다면, 어떨때는 데이터를 얻어올 것이고 또 다른 때는 데이터를 쓰는 입장일 겁니다. 이때 각 메소드 마다 이러한 특성을 고려해서 객체들을 찍어낼수 있다면 아주 이상적이겠죠. EA는 이것을 StreoType(DA0) 과 Tag(get,set)를 이용해 구축할수 있습니다.
PDF를 다운 받으셔서 한번 보시면 대락적인 흐름은 파악이 될듯 합니다.
제가 지난 포스팅에 언급했던 것과 같이 4월에 있을 .NET 커뮤니티 컨퍼런스에서 패턴과 EA를 이용해서 VS.NET의 코드 생산성 향상법과 몇가지 팁도 부가적으로 언급할 생각입니다. 궁금하신 분은 컨퍼런스에 저의 세션에 방문해 주세요.
Architecture 101 
지금 제가 참여하고 있는 프로젝트에서도 EA를 이용하고 있습니다. 직접써본적은 없고, 팀장님이 프리젠테이션 해주는걸 보고 뷰어로 설계를 확인하는정도만 쓰고 있는데, 확실히 투게더같은 툴보다는 좋아보이긴 하더군요. 물론 제가 써본게 투게더 1.0이긴 하지만요. 아무튼 준비하시는 세미나 기대가 되네요~.
안녕하세요. 위너비님
요즘 EA에 푹 빠져 살고 있습니다. 🙂
EA를 이용해 개발 생산성을 높이는 방법에 대해서 공유하도록 하겠습니다.
그럼 힘내시구요. 도움이 되시는 세미나 만들도록 하겠습니다.
감사합니다.
[…] SoC(Seperation of Concerns)가 가져오는 복잡성을 극복하는 법이라는 글을 읽었다. 이 글을 쓴 사람이 SoC의 개념에 대해서 제대로 […]
안녕하세요 Toby님
복잡성 하나의 단어로 게으른 사람이 되니 ㅎㅎㅎ 저 역시 민망할 따름입니다.
SoC는 전형적인 Layered Architectrure를 따르기 때문에, 분명히 복잡성이 발생합니다.
각각의 Feature 하나만 보면 간단하다고 할 수 있지만, 관리나, 유지 보수 측면에 복잡성이 발생할 수 밖에 없습니다. Change Propagation이지요 🙂
조만간 다시 Posting해서 feedback을 걸도록 하겠습니다. 감사합니다 🙂
.Net은 잘 모르지만
상당히 유용할 것 같네요
다른 부분에서도 차용할 만한 아이디어도 많이보이구
언제나처럼 감사드려요!
4월 세미나 공지는 언제쯤…? ㅎ
안녕하세요 레몬에이드님 🙂
http://www.devdcc.net/Program/Default.aspx 입니다.
ㅎㅎㅎ 그럼 그때 뵙겠습니다. 조촐히 음료수라도 한잔 해요 🙂
EA에 대한 자세한 강좌 기다리겠습니다.
갈망중입니다. ^^!
안녕하세요 황제펭귄님 🙂
이거 잘못 발표하면, 완전히 혼나겠네요.. 😦 부담감이 서서히 증가하고 있습니다.
여튼 … 도움이 될수 있게 🙂 준비하겠습니다.
저의 2세 튼튼이가 일찍 자 주어야 할텐데요. ㅎㅎㅎㅎ 충성~~~
2000년도 무렵에 유행하였던 코드제네레이션을 지금에서야 베스트프랙티스로 포스팅하신 느낌이 있어 좀 당황스러운 글이네요. 닷넷쪽에서는 이런 게 있고 자바쪽에는 저런게 있다고 하셨는데 사실 자바쪽만 보더라도 저 정도 생산성 올려주는 툴은 셀 수 없이 나와있죠. 범람한다고 해도 과언이 아닐 정도로.
투게더가 언제적 투게더인데 이걸 쓰는 게 좋을 거라고 권장하는 것도 좀 의문입니다. 지금 어느 현장에서 투게더 깔고 돌려서 설계합니까? 그리고 투게더로 인해 생산성이 올라간다는 말은 19세기 벤더 광고용 문구에 지나지 않는다는 점이 증명된지 오래인데… 자바 쪽 서적은 읽어보고 있으신지 궁금하네요.
독하게 말하자면, 정보들이 굉장히 오래되었습니다. 이거 읽고 자바 초보들이 투게더깔고 유엠엘 그리고 코드 생성하고 거기다 덧붙이고 깨끗한 코드 짰다라고 할까봐 겁나네요.
안녕하세요
pollinipill 님. 공격적인 Attack 정말로 감사합니다.
저같은 경우는 현재 초기 뼈대 Streo Type을 만드는 작업이 제법 시간이 걸렸지만, 현재 다른 분들과 비교하여 생산성 측면에서 꽤 만족하고 있습니다.
EA에서 CodeTemplate SDK과 Tagging 기능을 이용해서 저희 프로젝트에 만족할 만큼 코드를 찍어내고 있습니다. 🙂
중요한 건 Template Code가 충분히 검증이 된 코드인지? 아닌지가 중요한 것이지요.
UML 툴은 그 코드를 그냥 Template으로 가지고 있을 뿐입니다.
결국 Code Template을 만들때 신중성을 기해야 함은 사실입니다. 저 같은 경우는 검등된 Framework을 기반(Microsoft P&P, Enterprise Library)으로 템플릿을 생성하고 개발했습니다.
생산성 올라가지 않았다고 하시는데, 전 나름 만족할 만한 생산성을 얻고 있습니다. 최소한 프로젝트 의존 관계 생성하느라 보내는 시간을 많이 절약 할수 있습니다. 그 이외의 것들도 많지만요.
저희 스터디팀이나, 대전에 모 업체에 컨설팅을 했는데 그분들도 만족해 하시고 긍정적인 피드백을 얻었습니다.
궁금하시면 직접 세미나에 오셔서 평가해 주시길 바랍니다. 🙂 감사합니다.
ㅎ 코드제너레이션은 2000년 무렵에 유행하기도 했지만, 훨씬 그 이전, 아주 오래전 부터 유행이었고, 지금도 별로 다르지 않습니다. 뭐 이렇게 이야기 하면 구체적인 레퍼런스를 들이대야 하지 않냐고 달라드실테니, 그냥 그러려니 하시고요. 또 하나 투게더 요즘도 쓰는 사람들 많습니다. 심지어 로즈98쓰는 사람도 꽤 됩니다. 뭐.. 무식하면 용감하다고 이 포스팅을 하신 분께서는 타인에 도움이 될까 싶어 없는 시간내서 쓰신거 같은데.. 잘 알지도 못하면서 이렇게 공격하는 댓글을 달다니 무시무시합니다.
“각각의 Feature 하나만 보면 간단하다고 할 수 있지만, 관리나, 유지 보수 측면에 복잡성이 발생할 수 밖에 없습니다. Change Propagation이지요”
Change Propagation은 레이어가 있다 없다와는 관계없는 사상인데요. 레이어가 나뉘어있으므로 변화가 꼬리에 꼬리를 물고 영향을 미친다라고도 말할 수 있지만, 레이어가 나뉘어있지 않기 때문에 변화가 끝도없이 영향을 미친다라고도 말할 수 있습니다. 레이어의 분리와는 전혀 상관이 없는 개념.
용어에 대한 정의와 그 개념들이 왜 어떻게 나오게 되었는지 역사에 대한 공부를 먼저 하시기 바랍니다.
change propagation은 레이어에서 흔히 볼수 있는 사항이라 애기를 했습니다. 깊은 가르침 부탁드립니다.
먼저 역사에 대한 공부나 하라고 하셨는데요. 뭘 해야 되는지요? 혼만 내시지 마시고 가르침을 주셔야 되지 않을까요?
그럼 POSA1 권에 있는 Layer 패턴을 한번 꺼내 보시고 Change Propagation에 대한 애기가 나와 있습니다.
Layer 패턴의 단점으로 Cascades of Chaning Behavior가 있습니다.
원서 기준 49 페이지입니다.
같이 읽고 토론을 나누시지요 🙂
다른 것이 틀린다라는 생각 보다는 왜 이사람이 이렇게 애기 했는지에 대해서 생각해 보시는게 좋을듯 합니다.
ㅎㅎㅎ 역사 공부나 하세요 라고 하는 것은 마치 절 학생처럼 훈계 하시는.. 까칠한 말투 보단 부드러운 말투가 대화를 나누는데 좋을듯 합니다.
SoC를 너무 좁은 의미로 무리하게 글에 연결한 것으로 보입니다. 글 내용으로 보았을 때, 굳이 SoC를 언급할 필요가 있을까라는 생각이 듭니다. 물론 SoC를 언급하든 그 할아버지를 언급하든 상관할 일은 아니지만. 논쟁이 뜨거운 것 같아서 주책이지만 참견해봅니다.
생각과 경험의 차이라고 이해해 주시길 바랍니다.
특히 Iteration (RUP, Milestone) 개발 방식일 경우, 초기 인프라성이나, 중요시 여기는 Concern들이 몇번의 피드백 후 그 다음 Iteration에서 변하게 되는 경우를 종종 경험했습니다.
그런 문제시 빠르게 대응하는 방법을 소개하고 싶었을 뿐입니다. 🙂
나무만 보고 숲을 보지 못한다는 이야기가 생각나는 댓글들입니다.
결국 복잡도를 줄이기 위한 여러 개념중에 하나이며, 이 개념 하나로 복잡도를 완전히 줄일수는 없습니다.
우리가 얼마나 효과적으로 사용할지의 문제는 여전히 남아 있는 것이지요~
그런 개념으로 여러 방안을 제시한 것으로 생각되는데, 생각보다 나무 자체에 너무 치중하시는 듯 합니다.
넓게 바라봐주시는 안목이 중요한듯 합니다.
좋은 글 잘 보았습니다. 🙂
SoC를 함에 있어서 새로운 복잡성은 생기기 쉽습니다. (새로운 복잡성을 최대한 줄이는 것이 설계자의 능력이겠지만요)
예를 들면 우리는 흔히 애플리케이션의 설정정보를 한 곳에 모읍니다. 이는 애플리케이션이 거대화 되면서 분산되어 있는 설정정보들의 복잡성이 증대 되어기 때문입니다. 그래서 한 곳에 (흔히 파일에) SoC하게 됩니다.
분명 기존에 흩어져 있던 설정정보에 대한 복잡성은 제로에 가깝게 낮아졌지만, 프로그램의 흐름에서 보이던 설정정보들이 안보인다는 것은(설정 파일을 참조하고, 수정해야 한다는점에서는) 새로운 복잡성이 생긴것이다.
+보태기+ 재미있는 것은 다시 코드로 설정을 돌려보내주기 위한 어노테이션이 새로운 트렌드가 되어가고 있다는 점이다. (물론 어노테이션의 목적이 이 하나는 아니다.)
저는 만족할 만한 생산성을 얻고 있는데…
CodeTemplate으로 찍으면 일이 반으로 줄어 드는데..
물런 처음 구축 할때 좀 빡시지만………
투게더 는 모르겠고.. 로즈는 써 봤는데..
뭐랄까 좀 ‘엄’ 하다고 해야 하나요.. 좀 융통성도 없는 것 같고… 근데 EA는 경험상 봤을때 굉장이 유연 하다고 생각합니다. 플러그인도 상당 하고요…
사실 현재 코드제네레이션을 해주는 툴은 많습니다.
중요한건 생상성 측면과 효율성을 높일 수 있다면
뭐가 됐던 상관 없지 않을까요..
arload 님의 글은 Seperation of Concerns시 발생하는 복잡성을 줄여 보자는 의도로 EA라는 도구를 애기 하신것 같은데…
완전 복잡해 졌네요..ㅎㅎㅎ
제목이 글의 전체적인 의미를 대변하지 못한다는 피드백이 있으셨고, 저 역시 이걸로 큰 댓가를 치렀습니다.
좀더 명확하게 하기 위해 제목에 in motion을 추가했습니다.
SoC in motion.
그럼 좋은 하루 되세요
Together에 대해 잘못된 피드백이 올라와 공유합니다.
현재 Together는 2008 버젼까지 나왔으며, 별도의 제품으로 판매하지 않고 C++ Builder, J Builder 제품을 구매시 같이 구매할수 있는 형태로 라이센스 정책이 변경되었다고 들었습니다. (2008년도 기준)
together_datasheet.pdf에 액세스하려면 클릭하세요.
단일 제품으로 판매한 버젼은 2005버젼까지 입니다. 제가 염두하고 적었던 기준은 2005 버젼입니다. 🙂
오해 없으시길 바라겠습니다.