UML 대신 기능 프로그래머는 무엇입니까?

저는 CS 학생입니다. 저는 현재 객관적인 분석 및 디자인을 가르치는 강의에 참석하고 있습니다. 주로 사용 사례 작성, 클라이언트를위한 일부 응용 프로그램 작성시 직면 할 수있는 문제 분석, 확장 가능하고 개발자에게 명확하고 클라이언트가 일부에 대해 논쟁 할 때 문제를 일으키지 않도록 프로젝트를 설계하는 방법으로 구성됩니다. 풍모. 그것은 객관적이므로 OOP 관점 (클래스 등)에서 배우고 있습니다.

이제 UML을 도우미 도구로 사용하고 있습니다. 나는 OOP에 대해 잘 알고 있다고 생각하지만 기능적 패러다임을 배웠고 소규모 프로젝트에서 성공적으로 사용했습니다.

우리 교사는 "기능적 패러다임은 어떻습니까?" 질문, 그는 더 큰 프로젝트를 기능적 언어로 프로그래밍하지 않았으며 기능적 프로그램이 어떤 도구를 사용하고 있는지 알지 못한다고 대답했습니다.

그래서 그들은 무엇을 사용할 것입니까? 이에 대한 몇 가지 방법론이 있습니까? 아니면 그런 일이 필요 없을까요?

모든 함수형 프로그래머를 위해 말할 수는 없지만 내가 아는 사람들은 최상위 함수의 형식 서명을 작성하여 시작한 다음 더 자세하게 필요하면 도우미 함수의 형식 서명을 작성합니다.

이것은 함수형 프로그래밍에서 부작용이 없기 때문에 작동하므로 함수는 모두 입력 및 출력 측면에서만 지정됩니다. 이것은 타입 시그니처가 명령형 프로그래밍보다 디자인 툴로 훨씬 유용합니다. 이것이 컴파일러가 유추 할 수있는 경우에도 사용 된 이유 중 하나입니다.

교수님을 존중하면서 다이어그램 도구를 사용하는 한, 나는 학교를 떠난 이후 로 어떤 패러다임 에서도 그 도구를 많이 사용하지 않았습니다 .

이 편리한 차트에 표시된대로 UML 표준은 12 가지가 넘는 다이어그램 유형을 정의합니다.

출처 : https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

그림 A.5 UML 2.5 스펙에서 구조 및 행동 다이어그램의 분류를 참조하십시오 .

^{이것은 다이어그램 유형과 이탤릭체로 된 추상 다이어그램 유형 간의 하위 유형 관계가있는 클래스 다이어그램의 예입니다. 이러한 다이어그램 유형은 실제로 UML 메타 모델 내의 클래스이지만이 클래스 다이어그램은 OOP에 연결하지 않고 계층을 설명하는 데 여전히 유용합니다.}

OOP에만 명확하게 적용되는 몇 가지 유형 (예 : 클래스 다이어그램 또는 객체 다이어그램)이 있습니다. 그러나 나머지는 객체 지향 시스템보다 더 광범위하게 적용 가능합니다.

• 상태 머신 다이어그램 – FP는 상태를 피하지 않고 단지 명시 적으로 만듭니다. 상태 머신 다이어그램은 프로그램의 제어 흐름 또는 다양한 상태 전환을 설명하는 데 유용 할 수 있습니다.

• 활동 다이어그램 – 상태 머신 다이어그램과 유사한 경우에 유용하지만 더 높은 수준에 있습니다. 다양한 서브 시스템 간의 데이터 흐름을 설명하거나 외부 비즈니스 프로세스를 모델링하는 데 사용될 수 있습니다.

• 상호 작용 다이어그램 – 여러 상태 저장 프로세스 간의 상호 작용을 모델링합니다. 분명히 이것은 순수 기능 프로그램의 내부를 모델링하는 데 유용하지 않습니다. 그러나 UML은 코드 구조 모델링뿐만 아니라 주로 범용 모델링 언어 제공에 관한 것입니다. 상호 작용 다이어그램을 사용하면 상호 작용 다이어그램을 사용하여 FP 기술을 사용하여 시스템을 작성할 때도 브라우저와 웹 서버 간의 시스템 간의 외부 행동을 모델링 할 수 있습니다.

• 사용 사례 다이어그램 – 사용 사례 및 요구 사항은이를 충족시키는 데 사용되는 기술과 무관합니다. OOP 또는 FP는 여기와 전혀 관련이 없습니다.

• 배포 다이어그램 –이 다이어그램 유형은 실행 가능한 소프트웨어와 하드웨어 리소스 간의 관계를 설명하는 데 사용됩니다. 해당 소프트웨어가 FP 언어로 작성되었는지 여부는 중요하지 않습니다.

• 컴포넌트 다이어그램 – 대부분의 기능적 언어는 요즘 모듈 식 프로그래밍을 명시 적으로 지원합니다. 구성 요소 다이어그램은 구성 요소 / 모듈 및 해당 제공 및 필수 인터페이스를 설명합니다. 이것은 많은 OCaml의 Functor 모듈을 생각 나게합니다.

• 프로필 다이어그램 – UML 자체의 확장을 설명하며 실제로 사용되지는 않습니다.

• 복합 구조 다이어그램 – 복합 구조를 설명합니다. 데이터 구조 또는 함수의 상호 작용 지점을 설명하는 데 사용할 수 있습니다. Wikipedia는 피보나치 함수에 대한 다이어그램을 예로 보여줍니다.

  

  출처 : https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

  어떤면에서 이것은 클래스 다이어그램이 아닌 기능적인 프로그래머의 선택이 될 것입니다. 그러나 이것은 엄청나게 과장된 것 같습니다….

• 패키지 다이어그램 – 패키지는 네임 스페이스와 동등한 UML입니다. 이 다이어그램 유형은 별도의 다이어그램 유형보다 UML 언어 인프라의 일부입니다. 예를 들어 패키지를 사용하여 큰 사용 사례 다이어그램을 분류 할 수 있습니다.

지금까지 살펴본 것처럼 기능 프로그래밍을 수행 할 때 다양한 UML 다이어그램 유형이 여전히 유용 할 수 있습니다.

시스템을 설계 할 때 UML을 사용하고 싶은 과제를 거의 느끼지 않았으며 주로 UML을 사용하여 할당 된 숙제를하거나 아키텍처 개요를 빠른 스케치로 전달하려고합니다. OOP 시스템의 경우에도 UML은 항상 사용하기에 충분한 가치를 제공하지 못합니다. 실제 코드는 수천 개 이상의 다이어그램을 말합니다. FP 프로그램에서 다양한 기능과 데이터 구조 간의 종속성을 설명하기 위해 UML과 같은 다이어그램을 사용하는 것을 상상할 수는 있지만 아직 그렇게하지 않았습니다. 내 개인 스타일은 FP 기술이 로컬 규모로 사용되는 OOP와 FP의 혼합을 선호합니다. 전체 아키텍처에는 영향을 미치지 않습니다.