우려의 분리

Separation of concerns

컴퓨터 과학에서 우려의 분리(SoC)는 컴퓨터 프로그램을 구별되는 섹션으로 분리하기 위한 설계원리다.각 섹션은 컴퓨터 프로그램의 코드에 영향을 미치는 일련의 정보인 별도의 문제를 다룬다.우려는 "응용프로그램의 하드웨어 세부사항"처럼 일반적이거나 "즉시화할 클래스의 이름"처럼 구체적일 수 있다.SoC를 잘 구현한 프로그램을 모듈형[1] 프로그램이라고 한다.모듈성, 즉 우려의 분리는 잘 정의된 인터페이스를 가진 코드의 한 섹션 안에 정보를 캡슐화함으로써 달성된다.캡슐화는 정보를 숨기는 수단이다.[2]정보시스템에서 레이어드 설계는 관심사 분리의 또 다른 구현이다(예: 프레젠테이션 계층, 비즈니스 논리 계층, 데이터 액세스 계층, 지속성 계층).[3]

우려의 분리는 프로그램의 설계, 배치 또는 사용의 일부 측면에 대해 더 많은 자유도를 초래한다.이 중 공통적으로 코드의 단순화와 유지보수를 위한 자유 증대가 있다.우려가 잘 분리되면 모듈 업그레이드, 재사용, 독자 개발 기회가 많아진다.인터페이스 뒤에 모듈의 구현 세부사항을 숨기면 다른 섹션의 세부사항을 알 필요가 없고 해당 다른 섹션에 상응하는 변경을 하지 않아도 단일 관심사의 코드 섹션을 개선하거나 수정할 수 있다.모듈들은 또한 서로 다른 버전의 인터페이스를 노출시킬 수 있는데, 이것은 기능성의 중간 손실 없이 복잡한 시스템을 단편적으로 업그레이드할 수 있는 자유를 증가시킨다.[citation needed]

우려의 분리는 추상화의 한 형태다.대부분의 추상화와 마찬가지로, 우려를 분리한다는 것은 코드 인터페이스를 추가하는 것을 의미하며, 일반적으로 실행할 코드를 더 많이 만드는 것을 의미한다.그래서 잘 분리된 우려의 많은 이점에도 불구하고, 종종 관련된 집행 벌칙이 있다.[citation needed]

실행

프로그래밍 언어로 제공되는 모듈형 또는 객체 지향 프로그래밍의 메커니즘은 개발자들이 SoC를 제공할 수 있도록 하는 메커니즘이다.[4]예를 들어 C#, C++, 델파이, 자바와 같은 객체 지향 프로그래밍 언어는 우려를 객체로 분리할 수 있고, MVC나 MVP와 같은 건축 설계 패턴은 프리젠테이션과 데이터 처리(모델)를 분리할 수 있다.서비스 지향 설계는 우려를 서비스로 분리할 수 있다.C와 Pascal과 같은 절차 프로그래밍 언어는 우려를 절차나 기능으로 분리할 수 있다.측면 지향 프로그래밍 언어는 관심사를 측면과 객체로 구분할 수 있다.

우려의 분리는 도시 계획, 건축, 정보 설계와 같은 많은 다른 분야에서도 중요한 설계 원칙이다.[5]복합적인 상호의존적 시스템을 보다 효과적으로 이해, 설계 및 관리하여 기능이 재사용되고, 다른 기능과 독립적으로 최적화되며, 다른 기능의 잠재적 장애로부터 절연될 수 있도록 하는 것이 목표다.

흔히 볼 수 있는 예로는 한 방의 활동이 다른 방의 사람들에게 영향을 주지 않도록 공간을 분리하는 것, 그리고 난로에 의한 과부하가 불이 꺼지지 않도록 한 회로와 다른 방의 불을 켜놓는 것 등이 있다.방이 있는 예는 캡슐화를 보여주는데, 한 방 안에 있는 정보가 얼마나 지저분한지 등, 문인 인터페이스를 통해서만 다른 방에서는 이용할 수 없다.회로의 예는 전기 소비 장치가 부착된 회로인 한 모듈 내부의 활동이 다른 모듈에서의 활동에 영향을 주지 않기 때문에 각 모듈은 다른 모듈에서 일어나는 일에 관여하지 않는다는 것을 보여준다.

오리진,

우려의 분리라는 용어는 아마도 Edsger W. Dijkstra가 1974년 논문 "과학적 사고의 역할에 대하여"[6]에서 만들어졌을 것이다.

내가 너에게 설명해줄게, 내 취향에 맞는 것은 모든 지성적인 사고의 특징이야.그것은, 그 자신의 일관성을 위해서, 오직 한 가지 측면만을 가지고 자기 자신을 점령하고 있다는 것을 항상 알고 있는, 자기 주제의 한 측면을 심층적으로 연구하고자 하는 것이다.우리는 프로그램이 정확해야 한다는 것을 알고 있고 우리는 그 관점에서만 그것을 연구할 수 있다; 우리는 또한 그것이 효율적이어야 한다는 것을 알고 있고 말하자면 다른 날에 그것의 효율성을 연구할 수 있다.또 다른 기분으로 우리는 자신에게 왜 프로그램이 바람직한지, 그리고 만약 그렇다면, 그 프로그램이 바람직한지 자문할 수 있다.하지만 얻는 것은 아무것도 없어. 반대로!—이러한 다양한 측면에 동시에 대처함으로써.내가 때때로 "걱정의 분리"라고 불렀던 것인데, 완벽하게 가능하지는 않더라도, 내가 알고 있는 것은 아직 자신의 생각을 효과적으로 정리할 수 있는 유일한 기술이다.이것이 내가 말하는 "어떤 면에 주의를 집중하라"는 것이다: 그것은 다른 면들을 무시하는 것을 의미하는 것이 아니라, 단지 이 면의 관점에서 다른 면은 무관하다는 사실을 정의롭게 하는 것이다.그것은 하나의 트랙과 복수 트랙을 동시에 염두에 두고 있다.

15년이 지난 지금, 우려의 분리라는 용어가 받아들여지고 있는 것이 분명했다.1989년에 Chris Reade는 우려의 분리를 설명하는 기능 프로그래밍의[7] 요소라는 책을 썼다.

프로그래머는 동시에 몇 가지 일을 해야 한다. 즉,

  1. 계산해야 할 사항을 기술한다.
  2. 계산 순서를 작은 단계로 조직한다.
  3. 계산 중에 메모리 관리를 체계화한다.

리드는 계속 이렇게 말한다.

이상적으로는 프로그래머가 다른 두 가지, 더 많은 행정적인 업무 때문에 흐트러지지 않고 세 가지 과제 중 첫 번째 과제(계산 대상 설명)에 집중할 수 있어야 한다.분명히, 행정도 중요하지만, 그것을 주요 업무와 분리함으로써 우리는 더 신뢰할 수 있는 결과를 얻을 수 있고 행정의 많은 부분을 자동화함으로써 프로그래밍 문제를 완화할 수 있다.

우려의 분리는 다른 장점도 있다.예를 들어 프로그램 검증은 시퀀싱과 메모리 관리 세부사항이 프로그램에 없을 때 훨씬 더 실현 가능하다.또한, 계산해야 할 내용에 대한 설명은 다른 기계 구조로 평가해야 하는 경우, 어떻게 계산해야 하는지에 대한 상세한 단계별 설명에서 벗어나야 한다.저장소에 보관된 데이터 객체에 대한 일련의 작은 변경은 전지구적 스토리지 설비가 아닌 기계 전체와 로컬에 분산된 수천 개의 프로세서를 사용하여 고도로 병렬된 기계가 사용될 때 어떤 것을 계산하는 방법에 대한 부적절한 설명일 수 있다.

행정적인 측면을 자동화하는 것은 언어 구현자가 그것들을 다루어야 한다는 것을 의미하지만, 그는 다른 기계 구조로 매우 다른 계산 메커니즘을 사용할 수 있는 훨씬 더 많은 기회를 가진다.

예

인터넷 프로토콜 스택

우려의 분리는 인터넷 설계에 매우 중요하다.Internet Protocol Suite에서는 우려를 잘 정의된 계층으로 분리하기 위해 많은 노력을 기울였다.이것은 프로토콜 설계자들이 한 계층의 관심사에 초점을 맞추고, 다른 계층들은 무시하도록 한다.예를 들어 애플리케이션 계층 프로토콜 SMTP는 신뢰할 수 있는 전송 서비스(일반적으로 TCP)를 통해 전자 메일 세션을 수행하는 모든 세부사항에 대해 염려하지만, 전송 서비스가 어떻게 그 서비스를 신뢰할 수 있게 만드는지에 대해서는 전혀 걱정하지 않는다.마찬가지로, TCP는 인터넷 계층에서 처리되는 데이터 패킷의 라우팅에 대해 걱정하지 않는다.

HTML, CSS, JavaScript

HTML(HyperText Markup Language), CSS(Cascading Style Sheets), JavaScript(JS)는 웹 페이지 및 웹 사이트 개발에 사용되는 보완 언어다.HTML은 주로 웹페이지 콘텐츠의 구성에 사용되고, CSS는 콘텐츠 표시 스타일의 정의에 사용되며, JS는 콘텐츠가 사용자와 상호 작용하고 동작하는 방식을 정의한다.역사적으로, 이것은 그렇지 않았다: CSS가 도입되기 전에, HTML은 의미론과 스타일을 정의하는 두 가지 임무를 모두 수행했다.

주제 지향 프로그래밍

주제 지향 프로그래밍은 개별적인 우려를 각각 다른 사항들과 동등한 입장에서 별도의 소프트웨어 구조로 다룰 수 있도록 한다.각 관심사는 공통의 사물이 조직되는 자체적인 계급 구조를 제공하며, 서로 가로지르는 복합적인 결과에 상태와 방법을 기여한다.대응 규칙은 여러 우려사항의 등급과 방법이 상호작용하는 지점에서 어떻게 서로 연관되어 있는지 기술하며, 여러 우려사항에서 도출되는 방법에 대한 복합적 행동을 허용한다.우려의 다차원적인 분리는 각 우려의 분석과 구성을 적절한 소프트웨어 아티팩트가 점유한 매트릭스의 셀과 함께 서로 다른 선택 지점이 열거되는 차원을 제공하는 다차원 "매트릭스"로 조작할 수 있게 한다.

측면 지향 프로그래밍

측면 지향 프로그래밍은 교차 커팅 우려를 주요 관심사로 다룰 수 있도록 한다.예를 들어, 대부분의 프로그램은 어떤 형태의 보안과 로깅을 요구한다.보안과 로깅은 종종 부차적인 문제인 반면, 주요 관심사는 종종 비즈니스 목표 달성에 있다.그러나, 프로그램을 설계할 때, 그것의 보안은 부차적인 관심사로 취급되는 대신 처음부터 설계에 내장되어야 한다.나중에 보안을 적용하면 향후 공격에 너무 많은 빈틈을 남기는 보안 모델이 불충분해지는 경우가 많다.이것은 양면 위주의 프로그래밍으로 해결될 수도 있다.예를 들어 프로그램의 절차 코드가 예외를 처리하는지 전파하는지 여부에 관계없이 특정 API에 대한 호출을 항상 기록하거나 예외를 발생시킬 때 항상 오류가 기록되도록 하는 측면이 기록될 수 있다.[8]

인공지능의 분석 수준

인지과학과 인공지능에서는 데이비드 마르의 분석 수준을 언급하는 것이 일반적이다.언제든지 연구자는 (1) 계산에 필요한 지능의 일부 측면, (2) 어떤 알고리즘을 채용하는지 또는 (3) 하드웨어에서 그 알고리즘이 구현되는 방법에 초점을 맞출 수 있다.이러한 우려의 분리는 소프트웨어와 하드웨어 엔지니어링의 인터페이스/이행 구분과 유사하다.

정규화된 시스템

정상화된 시스템에서 우려의 분리는 4가지 지침 원칙 중 하나이다.이 원칙을 고수하는 것은 시간이 지남에 따라 유지되고 있는 소프트웨어에 도입되는 결합 효과를 줄이는 데 도움이 되는 도구 중 하나이다.표준화 시스템에서 우려의 분리는 도구에 의해 적극적으로 지원된다.

부분 클래스를 통한 SoC

우려의 분리는 부분적인 계층을 통해 구현되고 시행될 수 있다.[9]

루비 부분수업을 통한 SoC

곰_사냥.rb
계급 곰   반항하다 사냥을 하다     숲의.선발하다(&:음식?)   종지부를 찍다 종지부를 찍다
곰_먹다.rb
계급 곰   반항하다 먹다(음식)     높이다 "#{음식}먹을 수 없다!" ~하지 않는 한 음식.응답하시겠습니까? :영양_값     음식.영양_가치   종지부를 찍다 종지부를 찍다
bear_bear.rb
계급 곰   attr_accessor :hunger   반항하다 monitor_properties     만일 굶주리다 > 50       음식 = 사냥을 하다       굶주리다 -= 먹다(음식)     종지부를 찍다   종지부를 찍다 종지부를 찍다

참고 항목

참조

  1. ^ Laplante, Phillip (2007). What Every Engineer Should Know About Software Engineering. CRC Press. ISBN 978-0849372285.
  2. ^ Mitchell, Dr. R. J. (1990). Managing Complexity in Software Engineering. IEE. p. 5. ISBN 0863411711.
  3. ^ Microsoft Application Architecture Guide. Microsoft Press. 2009. ISBN 978-0-7356-2710-9.
  4. ^ Painter, Robert Richard. "Software Plans: Multi-Dimensional Fine-Grained Separation of Concerns". Penn State. CiteSeerX 10.1.1.110.9227. {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  5. ^ Garofalo, Raffaele (2011). Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern. Microsoft Press. p. 18. ISBN 978-0735650923.
  6. ^ Dijkstra, Edsger W (1982). "On the role of scientific thought". Selected writings on Computing: A Personal Perspective. New York, NY, USA: Springer-Verlag. pp. 60–66. ISBN 0-387-90652-5.
  7. ^ Reade, Chris (1989). Elements of Functional Programming. Boston, MA, USA: Addison-Wesley Longman. ISBN 0-201-12915-9.
  8. ^ Jess Nielsen (June 2006). "Building Secure Applications" (PDF). Retrieved 2012-02-08.
  9. ^ Tiago Dias (October 2006). "Hyper/Net: MDSoC Support for .NET" (PDF). DSOA 2006. Retrieved 2007-09-25.

외부 링크