소프트웨어 시스템 모델링과 코드에서 모두 수행하는 것의 이점은 무엇입니까?

대부분의 IT 직원은 아니지만 코딩하기 전에 UML 또는 다른 유형의 다이어그램으로 소프트웨어를 모델링하는 것이 유리하다고 생각합니다. (제 질문은 UML에 관한 것이 아니며 소프트웨어 디자인에 대한 그래픽 또는 텍스트 설명 일 수 있습니다.)

확실하지 않습니다. 주된 이유는 다음과 같습니다. 코드가 거짓말을하지 않습니다. 컴파일러 또는 인터프리터에서 확인합니다. 자동화 된 테스트가 있기를 바라며 정적 코드 분석을 통과해야합니다. 모듈이 다른 모듈과 올바르게 인터페이스하지 않으면 일반적으로 오류 메시지가 표시되므로 코드에서 분명합니다.

이 모든 것은 다이어그램 및 기타 문서로는 수행 할 수 없습니다. 예, UML을 검사하는 도구가 있지만 지금까지 본 모든 것은 매우 제한적입니다. 따라서 이러한 문서는 불완전하거나 일관성이 없거나 단순하지 않은 경향이 있습니다.

다이어그램 자체가 일관성이 있어도 코드가 실제로이를 구현하는지 확신 할 수 없습니다. 예. 코드 생성기는 있지만 모든 코드를 생성하지는 않습니다.

필자는 때로는 코드가 필연적으로 건축가, 디자이너 또는 큰 그림을 얻는 다른 보수가 많은 사람들이 다룰 필요가 없다는 이해할 수없는 혼란이 있어야한다는 가정에서 모델링 결과에 대한 집착과 같은 느낌을받습니다. 그렇지 않으면 너무 비쌀 것입니다. 따라서 모든 설계 결정은 코드에서 멀어져 야합니다. 코드 자체는 코드를 작성할 수 있지만 읽을 수는있는 전문가 (코드 원숭이)에게 맡겨야합니다. 아마도 어셈블러가 유일한 옵션 일 때 이치에 맞았지만 현대 언어에서는 매우 높은 수준의 추상화로 코딩 할 수 있습니다. 따라서 더 이상 모델링이 필요하지 않습니다.

소프트웨어 시스템 모델링에 대한 어떤 주장이 빠져 있습니까?

그건 그렇고, 다이어그램은 소프트웨어 디자인의 특정 측면을 문서화하고 의사 소통하는 좋은 방법이라고 생각하지만 소프트웨어 디자인을 기반으로 해야한다는 것을 의미하지는 않습니다 .

설명:

그 질문은 불분명 한 것으로 보류되었다. 따라서 몇 가지 설명을 추가하겠습니다.

소프트웨어를 소프트웨어 설계에 대한 기본 진리의 원천으로 소프트웨어를 모델링하는 비 코드 문서를 사용하는 것이 타당한 지 묻고 있습니다. 이 문서에서 코드의 상당 부분이 자동으로 생성되는 경우를 염두에 두지 않습니다. 이 경우 문서 자체를 모델이 아닌 소스 코드로 간주합니다.

이 절차의 몇 가지 단점을 나열한 이유는 (많은 사람들이 내 경험에 따라) 소프트웨어 설계를 선호하는 방법으로 생각하는 이유입니다.

소프트웨어 시스템과 코드의 모델링의 이점은 다음과 같습니다. 모델을 화이트 보드에 맞출 수 있습니다.

나는 한 장의 종이에 의사 소통하는 마법을 믿는다. 우리 시스템을 새로운 코더에게 가르 칠 때 화이트 보드에 코드를 넣으려고한다면 화이트 보드에 맞는 추상화 수준의 코드는 없습니다.

나는 당신이 말하는 모델링에 대한 집착을 알고 있습니다. 사람들이 일을하는 이유에 대해 생각하지 않고 이전에 수행 한 방식이기 때문에 일을하는 사람들. 나는 그것을 형식주의라고 부릅니다. 나는 전통 뒤에 숨어있는 것을 어려워하기 때문에 비공식적으로 일하는 것을 선호합니다.

그렇다고 지금 UML 스케치를 작성하지 않는다는 의미는 아닙니다. 하지만 난 당신이 코딩하기 전에 UML 문서를 돌려달라고 요구하는 사람이되지 않을 것입니다. 한 사람 만 이해하는 코드의 존재를 참을 수 없기 때문에 5 분이 걸리고 수행중인 작업을 설명하는 몇 가지 방법을 찾아야 할 수도 있습니다.

Fowler는 사람들이 UML 모드 라고하는 UML을 사용하는 다양한 방법을 식별했습니다 . 그들 모두에게 위험한 것은 그들이 유용한 일을하는 것을 숨길 수 있다는 것입니다. 마우스를 사용하여 코드를 작성하는 경우 많은 시도를 보았습니다. 아무도 실제로 작동하는 것을 보지 못했습니다. 의사 소통을하기 위해 다른 사람이 당신을 이해하도록하는 것이 좋습니다. 디자인하기 위해 작업을 수행하는 경우 작업하면서 문제를 찾고 수정하는 것이 좋습니다. 모든 것이 매끄럽게 진행되고 대부분의 시간이 화살표를 멋지게 보이게하는 데 쓰인다면, 그것을 두드리고 다시 일을 시작하십시오.

가장 중요한 것은 하루 이상 유효 할 것으로 예상되는 다이어그램을 생성하지 마십시오. 어떻게 든 할 수 있다면 실패한 것입니다. 소프트웨어는 부드럽습니다. 다이어그램을 올바르게 얻는 데 몇 주를 소비하지 마십시오. 무슨 일인지 말해줘 필요한 경우 냅킨을 사용하십시오.

즉, UML과 디자인 패턴을 알고있는 코더를 선호합니다. 의사 소통하기가 더 쉽습니다. 그들이 다이어그램을 만드는 것이 전일제 직업이 아니라는 것을 알고있는 한.

소프트웨어를 소프트웨어 설계에 대한 기본 진리의 원천으로 소프트웨어를 모델링하는 (비 코드) 문서를 사용하는 것이 타당한 지 묻습니다.

아닙니다. 이건 말이되지 않습니다. 코드는 기본 디자인 문서, 즉 "소프트웨어 디자인에 대한 주요 진실 소스"입니다. 컴파일러는 해당 디자인을 가져 와서 응용 프로그램을 만들 때 코드 만 응용 프로그램의 기능을 정확하게 설명합니다.

코드를 자동 생성하지 않는 경우 다이어그램을 보충 설계 문서로 사용하는 것이 좋습니다. 실제 설계와는 다른 이야기를하도록주의하십시오. UML이 보트를 떠 다니면 사용하십시오. 그렇지 않은 경우 다른 것을 사용하십시오.

일부 사람들은 코드 작성을 시작하기 전에 자신의 생각을 다이어그램 형식으로 스케치하는 것이 유용하다고 생각합니다. 그러나 밥 삼촌이이 문제에 대해 말한 것을 기억하십시오.

" 그래, 다이어그램은 때때로 부적절 할 수 있습니다. 부적절한시기는 언제입니까? 코드를 검증하지 않고 다이어그램을 만들 때 따라 가려고 할 때, 아이디어를 탐구하기 위해 다이어그램을 그리는 것은 아무 문제가 없습니다. "

UML을 사용하여 디자인을 탐색하는 경우 코딩을 시작할 때 디자인을 버리십시오. 테스트를 작성한 다음 통과시킬 코드를 작성하십시오. 반복. 이렇게하면 검증 된 디자인이됩니다. UML은 동일한 수준의 설계 검증을 제공 할 수 없습니다.

대부분의 IT 직원은 아니지만 코딩하기 전에 UML 또는 다른 유형의 다이어그램으로 소프트웨어를 모델링하는 것이 유리하다고 생각합니다.

나는 당신이 아는 모든 사람들이 이것을 믿는다는 것에 동의하지 않지만, 그것이 그것이 전반적으로 공통적이라고 생각하지는 않습니다. 1970 년에 Winston Royce는 소프트웨어 개발에 디자인과 코드 활동간에 일정한 수준의 반복이 있음을 알고있었습니다. 1992 년에 Jack Reeves는 코딩이 실제 디자인 활동 인 것에 대해 썼습니다 ( C2 Wiki 에서도 논의 됨 ).

그렇다고 사람들이 모델 중심 개발 도구를 만들려고 한 것은 아닙니다. 클래스 다이어그램뿐만 아니라 다양한 다이어그램 유형을 서로 연결하고 이들로부터 코드를 생성하는 UML 모델에서 코드를 생성하려는 도구가 있습니다. 그러나 이것들은 적어도 내가 본 것에서 널리 사용되는 도구는 아닙니다.

그렇다고 요구 사항에서 코드 작성으로 바로 이동해야한다는 의미는 아닙니다. 조기에 결정하는 데 중요한 특정 설계 결정이 있으며 일부 수준의 모델링은 모든 사람이 옵션, 영향 및 의사 소통을 이해하도록하는 데 유용 할 수 있습니다. 자신을 포함한 일부 사람들은 이것을 "소프트웨어 아키텍처"라고 부릅니다 .

코드는 거짓말하지 않습니다. 컴파일러 또는 인터프리터에서 확인합니다. 자동화 된 테스트가 있기를 바라며 정적 코드 분석을 통과해야합니다. 모듈이 다른 모듈과 올바르게 인터페이스하지 않으면 일반적으로 오류 메시지가 표시되므로 코드에서 분명합니다.

이것이 실제로 애자일 모델링의 일부 측면, 특히 실행 가능한 사양 및 단일 정보 소스의 핵심입니다 . 나는 반드시 TDD에 동의하지는 않지만 코드와 관련 테스트 (단위에서 승인 테스트, 바람직하게는 자동화 테스트로 캡처 됨)를 단일 소스로 만드는 아이디어는 좋은 생각입니다.

다이어그램 자체가 일관성이 있어도 코드가 실제로이를 구현하는지 확신 할 수 없습니다. 예. 코드 생성기는 있지만 모든 코드를 생성하지는 않습니다.

나는 일반적으로 모델-> 코드에서 오는 것이 잘못된 방법이라고 생각합니다. 대신 코드는 모델을 생성해야합니다. 즉, 도구는 코드를 검사하고 엔지니어가 텍스트를 작성할 때 더욱 향상 될 수있는 그래픽 및 표 형식의 표현을 생성 할 수 있어야합니다. 그리고 코드에서 생성 된이 모델 모델은 빌드 및 릴리스 프로세스의 완벽한 부분이어야합니다.

다양한 언어로이를 지원하는 도구가 있습니다. 언어와 패러다임의 본질을 감안할 때 다른 사람들보다 더 쉽습니다.

이 절차의 몇 가지 단점을 나열한 이유는 (많은 사람들이 내 경험에 따라) 소프트웨어 설계를 선호하는 방법으로 생각하는 이유입니다.

나는이 사람들이 반드시 소프트웨어 엔지니어링과 소프트웨어 디자인을 이해한다고 생각하지 않습니다. 저는이 사람들이 다른 엔지니어링 분야가 무엇을하고 있는지, 소프트웨어 엔지니어가해야 할 것으로 생각하는 것에 매핑하고 있다고 생각합니다. 그러나 그들은 한 가지 큰 차이점을 무시하고 있습니다. 다른 엔지니어링 분야는 모델과 시뮬레이션을 먼저 생성합니다. 실제 제품을 구축하는 데 비용이 많이 들고 시간이 많이 걸리기 때문입니다. 소프트웨어 엔지니어링에서 우리는 디자인 조각을 가져 와서 아주 적은 시간과 비용으로 실제 환경에서 테스트 할 수있는 것을 생산할 수 있습니다. 경제는 매우 다릅니다.

소프트웨어 시스템 모델링과 코드에서 모두 수행하는 것의 이점은 무엇입니까?

매우 복잡한 소프트웨어 시스템을 사용하는 경우 모델이 있다는 것은 이해하기 쉬운 것을 의미합니다. 다른 수준의 추상화로 사람들이 시스템의 다양한 측면을 이해하도록 도와줍니다. 여러 모델링 언어와 각 모델링 언어 또는 표기법에 의해 허용되는 다양한 유형의 모델이있는 이유 중 하나입니다. 다른 이해 관계자가 개념적으로 소프트웨어 시스템을 빠르고 쉽게 이해할 수 있도록하기 때문입니다.

소프트웨어를 소프트웨어 설계에 대한 기본 진리의 원천으로 소프트웨어를 모델링하는 비 코드 문서를 사용하는 것이 타당한 지 묻고 있습니다. 이 문서에서 코드의 상당 부분이 자동으로 생성되는 경우를 염두에 두지 않습니다. 이 경우 문서 자체를 모델이 아닌 소스 코드로 간주합니다.

코드가 아닌 많은 문서가 청사진 으로 유용합니다 . 즉, 디자인의 "진실"이이 방향을 따라야합니다. 디자인이 충족해야하는 요소를 모델링하는 방법입니다. 그것들을 요구 사항 문서라고 부를 수는 있지만, 내가 줄 수있는 모든 예제에서 너무 강할 수 있습니다. 나는 PlantText.com을 통해 PlantUML 을 사용하여 이것을 생산했습니다.

• 사용 사례 다이어그램은 의도 한 기능과 사용자 또는 외부 시스템과의 상호 작용을 보여줍니다.

• 활동 다이어그램은 소프트웨어가 지원해야하는 비즈니스 프로세스를 보여줄 수 있습니다.

• 상태 다이어그램은 웹 사이트에서 의도 된 동적을 표시 할 수 있습니다.

• Gang of Four 디자인 패턴은 정적 및 동적 모델로 표시됩니다. 예를 들어, Memento :
  
  

이 절차의 몇 가지 단점을 나열한 이유는 (많은 사람들이 내 경험에 따라) 소프트웨어 설계를 선호하는 방법으로 생각하는 이유입니다.

경험 이외의 UML 사용에 대한 실제 정보에 관심이 있다면 몇 가지 연구가 수행되었습니다 (비 월페이퍼 기사에 대한 링크를 찾으려고 시도 함).

• Petre, Marian (2013). 실제로 UML . 에서 : 35 번째 국제 소프트웨어 공학 회의 (ICSE 2013), 2013 년 5 월 18-26 일, 미국 캘리포니아 주 샌프란시스코, 722–731 쪽.
• N. Mangano, TD LaToza, M. Petre 및 A. van der Hoek (2015). 어떻게 화이트 보드에 스케치와 소프트웨어 디자이너 상호 작용 . 에서 : 소프트웨어 공학에 관한 IEEE 거래, vol. 41 번 2, 135-156 쪽.
• Andrew Forward와 Timothy C. Lethbridge. 2008 년 코드 중심 소프트웨어 개발 대 모델 중심에 대한 문제와 기회 : 소프트웨어 전문가의 조사 . 소프트웨어 엔지니어링 모델에 관한 2008 국제 워크숍 진행 (MiSE '08). ACM, 뉴욕, 뉴욕, 미국, 27-32

우리 개발자들은 세계를 설명하기 위해 이미지를 사용하는 것을 좋아하므로 자동차 생산과 관련이 있습니다.

• 자동차는 코드와 동일하게 프로덕션 체인의 결과입니다 (물론 배포 프로세스 추가).
• 자동차의 디자인 문서는 소프트웨어의 디자인 문서와 동일합니다.

우리 세계에서는 디자인 문서를 고안하고 만드는 사람들이 코드를 만드는 사람과 동일한 사람보다 종종 발생합니다. 다른 분야에서는 그렇지 않습니다. 그렇다고해서 모두 함께함으로써 동일한 수준의 품질을 얻을 수있는 것은 아닙니다.

코딩하지 않고 문서를 먼저 작성함으로써 (fasability에 대한 개념 증명과 같은 것을 제외하고 ...) :

• 해야 할 일을 알면 코딩하기 전에 코딩하기가 쉬워야합니다.
• 보다 숙련 된 사람들이 소프트웨어의 가장 어려운 부분에 집중할 수 있습니다. 디자인, 알고리즘 / 수학은 매우 특정한 목적 (임베디드, 실시간, 어셈블리)을 제외한 모든 것입니다.
• 경험이 적은 사람들에게 코딩 과정의 좋은 부분을 위임 할 수있는 반면, 경험이 많은 사람들은 자신의 기술 수준이 필요한 가장 중요한 부분에만 집중할 수 있습니다. 경험이 적은 사람들은 그것에 대해 많은 것을 배울 것입니다.
• 디자인 문서의 이미지를 통해 IT 전문가가 아닌 사람과 논의 할 수 있지만, 코드 만 있으면 수행 한 작업의 이미지를 추출해야하며 무언가를 잊어 버릴 위험이 있습니다 (어딘가 잊혀진 청취자 ...). 통신에 대한 자세한 내용은 CandiedOrange의 답변을 참조하십시오.
• 소프트웨어를 발전시켜야 할 때 영향이 더 큰 것을 기대할 수 있습니다.
• 디자인은 소프트웨어 조각을 쉽게 자르고 소프트웨어 조각을 동시에 개발할 수있게합니다.
• 코드를 작성하기 전에 테스트를 코딩하는 TDD 접근 방식에서 코드를 작성하는 동안 모든 케이스를 처리해야하는 문제를 겪을 필요가없는 경우이 잔향 단위 테스트를 훨씬 쉽게 수행 할 수 있습니다.
• ...

참고 : 그 확인은 코드가 실제로 디자인의 반영이며 둘 다 최신 상태라고 가정합니다 ...