Formal UML을 얼마나 자주 사용하십니까?

시스템을 상당히 자주 디자인하고 설명하기 위해 임시 MUML (메이킹 모델링 언어)을 사용했습니다. UML과 비슷해 보이며 꽤 잘 이해되는 경향이 있습니다.

그러나 가능한 한 사양에 가까운 엄격한 공식 UML을 사용하는 교수 한두 명을 가지고 있습니다. 나는 항상 엄격한 UML이 그들이 주장한 것만 큼 흔하지 않다고 생각했다. 그렇다면 어떻게해야할까요? 모든 적절한 줄 끝, 다중도, 멤버 유형 기호 등을 사용하는 완전한 다이어그램을 실제로 얼마나 자주 그리는가?

못.

내가 마지막으로 생성 된 이후 지옥, 그것은 년이 지났 어떤 UML을. 화이트 보드 및 종이 조각의 선 다이어그램은 계산되지 않습니다.

실제로 우리는 인터뷰 중에 사용하는 가이드에서 유일한 UML 질문을 제거했습니다. 왜냐하면 아무도 대답에 관심이 없었기 때문입니다.

본인이나 다른 사람이 시스템이나 하위 시스템을 구현할 수 있도록 충분한 UML (다이어그램 유형과 다이어그램의 정보 내용 모두)을 사용합니다. 그리고 UML을 사용하는 유일한 이유는 각각 매우 구체적인 기호를 의미하는 널리 알려진 기호 세트이기 때문에 모호성이 없습니다. 모든 소프트웨어 엔지니어는 다이어그램을보고 내가 말하려는 내용을 이해할 수 있어야합니다. 체계.

아이러니하게도 UML은 유연해야합니다.

현실 세계에서, 그것에게 일의 현학적 인 운동으로 생각하지 않는 한 올바른 방법. 시스템 / 프로세스 / 아이디어를 효과적으로 전달하고 문서화하는 것입니다.

귀하의 질문에 대답하기 위해 나는 다른 사람들과 함께 있습니다. 나는 공식적인 UML을 완전히 활용 한 적이 없다.

Rational Rose에서 모든 코드 스켈레톤을 생성 한 제품에 대해 약 4 년 동안 UML을 매우 정기적으로 사용했습니다.

지난 5 년 동안 대부분 그 자리에서 발명 된 "상자와 화살표"가 많았으며 일반적으로 일반적인 아이디어를 얻을 수있을 정도로 충분했습니다. 이 시간 동안 UML을 공식적으로 몇 번만 수정하십시오.

그러나 가능한 한 사양에 가까운 엄격한 공식 UML을 사용하는 교수 한두 명을 가지고 있습니다.

교수가 실제 시스템에서 마지막으로이 방법을 사용한 시간을 물어보십시오. 진심으로.

UML에 관해서는 가능한 한 공식적으로 노력하지만, 그것이 합리적 일 때만 가능합니다. 스펙트럼의 양쪽에있는 열성 (카우보이부터 격렬한 형식 주의자까지)는이를 이해하지 못합니다.

덜 개인적인 접근 방식 (예 : 개인적으로 사용하는 접근 방식)이 따르는 최선의 접근 방식이 있습니다. 요구 사항이 작고 완전히 정의되지 않은 소규모 시스템 또는 변경에 대한 좋은 예입니다. 담당 그룹은 효율적이고 효과적입니다. 그것을 얻는 것보다 그것을 얻는 것이 더 중요합니다. 반복적으로 수행되며 일부 결함이 허용됩니다.

또는 전체 공식 모델링 단계와는 반대로 손님 화 및 스케치를 수행하는 단계에있을 수 있습니다. 그것들은 생각 나게 될 예입니다.

다른 경우에는 엄격한 공식 UML 방식이 필요합니다. 예를 들어, 계약 상 구속 될 수 있습니다. 여러 팀에 매우 많은 수의 개발자가 있습니다 (아마도 분산되어 있음). 프로젝트의 범위는 몇 년이 될 수 있습니다. 매우 큰 시스템 (소프트웨어 및 하드웨어 구성 요소 포함)입니다. 실패 비용 등

다른 경우 에는 UML (페트리 넷, CSP 또는 시간 논리와 같은 실제 수학 공식 모델) 외에 다른 것을 대신 사용해야합니다. 예를 들어 실시간 시스템, 장애가 치명적인 시스템 (의료 기기) 또는 계약 상 구속되는 곳 (즉, 운송 시스템을 개발할 때 유럽에서와 같이)

그것은 모두 상황과 우리가 각 접근법에서 얻을 것으로 기대하는 것에 달려 있습니다. 형식을 고수하는 교수는 단순히 맹인 열광 자입니다. 공학의 세계는 흑백, 오른쪽 / 잘못된 이분법이 아닙니다. 지능적인 절충의 세계입니다.

비공식적이며 비공식적 인 모델을 사용하여 효과적이고 적절하게 작업을 수행 할 수있을 정도로 지능적이라면 그렇게하십시오. 마찬가지로, 비공식적 접근 방식 을 사용 하지 않을 때 및 / 또는 공식적인 접근 방식을 사용 하지 않을 때를 인식 해야합니다.

말했듯이 교수님과 함께 귀로 연주해야합니다. 그들에게 뼈를 줘서 당신에게 성적을 주면, 마침내 그들의 열성 만트라에 절을하는 것이 좋다면 괜찮습니다. 당신은 당신을 위해 무엇이 효과가 있는지 알고, 현실 세계에서 무엇을 어떻게 사용해야하는지 알게 될 것입니다.

박사 연구의 일환으로, 숙련 된 디자이너가 인공 지능 환경에서도 디자인 협업에 UML을 사용하는 방법을 연구했습니다.

내 발견은 UML 은유와 표기법이 차용되었지만 도구의 엄격성에 대한 준수는 거의 없다는 것입니다.

나중에 일부 모델은 코드 생성 목적으로 까다로운 CASE 도구가 포함 된 경우보다 엄격한 UML로 반복 변환 될 수 있습니다.

학술 연구의 일반적인주의 사항은 물론 적용됩니다 :)

논문 초록 및 논문 자체에 대한 링크 (AMC 액세스 권한이없는 경우) .

그 외에도 Ambler의 "Agile Modeling"을 적극 권장합니다.

우리는 동면 ORM의 코드 생성을 위해 공식 UML을 사용합니다. 대부분의 다른 것들은 비공식적이거나 화이트 보드입니다. 형식이 결여되면 코드 생성에 문제가 생길 수 있습니다.

그것은 당신이 속한 산업에 달려 있습니다. 빈번한 기술 검토 (예 : PDR, CDR 등)를 필요로하는 고객을 위해 일하는 경우 임시 표기법 시스템보다는 일종의 표준화를 선호합니다. 특히 정부의 일. 그것은 잘못된 의사 소통과 당신이 발명 한 표기법의 초기 15 분 설명을 방지합니다.

또한 UML을 사용한다고해서 표준에 따라 모든 i를 점으로 찍고 t를 교차해야한다는 의미는 아닙니다. 자동 코드 생성 / 실행을 원하는 경우에만 해당됩니다. 나는 하나 이상의 프로젝트를 위해 그것을 한 사람을 모른다.

반면에, 자신의 개발자 팀과 함께 회사를 위해 일하는 경우에는 어떤 표기법을 사용하는지 관심이 있습니다. 그러나 올바른 도구를 선택하면 실시간으로 절약 할 수 있습니다.

그러나 모든 산업 분야에서는 UML을 사용하여 설계 할 수없는 일부 산업에서는 어려움을 겪을 수 있습니다. 다른 산업에서는 결코 볼 수 없습니다.

또한, 수정 비용이 UML을 많이 사용하는 사용자에 비해 높기 때문에 설계가 옳 아야하는 산업간에 상관 관계가 있다고 생각합니다. UML을 사용하지 않은 장소로 설계 수정 비용이 문서 / 코드 변경에 지나지 않는 산업과 비교할 때.

원래 질문과 관련하여. 대부분의 대학은 학생들을 가장 많이 모집하는 회사를 위해 학생들의 훈련을 준비하는 경향이 있습니다. 교수가 UML이 중요하다고 생각한다면 학교에서 모집하는 많은 비즈니스가 UML을 사용한다는 것은 놀라운 일이 아닙니다. 따라서 사용 방법을 배워야합니다.

UML에 대해 읽을 때 C ++ 과정에서 해결해야 할 모든 문제에 대해 이것을 시도했습니다. 불행히도 내가 시도한 첫 번째 예제 중 하나는 연결된 목록을 설명하는 것이 었습니다.
작동하지 않았다.
즉, 좋은 모델링 프로세스 UML과 함께 유용합니다. 그것이 표준을 위해 나쁘게하기 때문입니다.
템플릿 메타 프로그래밍의 기술 언어를보고 싶습니다. <<<>>> -land에서 무슨 일이 일어나고 있는지 이해하는 데 많은 도움이 될 것이라고 생각합니다

UML은 모델 중심 개발도 시도하면 고통 스럽습니다. UML은 매우 유용한 그래픽 표기법이며 다른 모든 것은 쓸모가 없습니다. 모델링에 소비하지는 않지만 프로젝트 구조를 만들기 위해 매일 UML을 사용합니다. 내가하는 일은 요구 사항 수준에서 기본 유스 케이스 다이어그램을 빠르게 그린 다음 즉시 클래스 다이어그램으로 전환하는 것입니다. 유스 케이스와 클래스 다이어그램 사이에 요구 사항 추적 성을 추가합니다. 내 클래스 다이어그램은 실시간 동기화되기 때문에 코드를 만듭니다. 코드에 모든 모델이 Java 프로젝트에 맵핑 된 UML 모델에 저장되는 태그는 없습니다.

클래스 다이어그램을 거의 사용하지 않고 응용 프로그램의 골격을 만든 다음 코드로 전환합니다. 코드를 완성하면 모델과 병합합니다. 코드가 모델을 실행하는 코드와 모델 간의 반복입니다. 따라서 클래스 다이어그램은 더 높은 수준의 추상화와 코드를 제공하는 반면 코드는 비즈니스 로직 구현 (예 : 메소드)을 제공합니다.

UML 모델링에는 하루에 10 분 미만이 소요되며, 개발해야 할 사항과 방법을 생각할 시간이 필요할 때 수행됩니다.

UML은 훌륭하고 환상적이며 실제로 유용하지만 모델 중심 개발은 쓸모가 없습니다!

우리가 구현 한 시스템을 문서화하고 있다면 완전한 UML로 시스템을 내려 놓으려고합니다. 그러나 나머지 시간에는 아이디어를 얻는 데 필요한만큼만 사용합니다. 또한 UML보다 많은 DFD를 사용하고 있습니다. 요즘 설계하는 시스템에 더 적합한 것으로 보입니다.

나는 시간이 많이 걸리는 시각 모델링 활동, 포럼 집안일, 컴퓨터 주변에서 자랐거나 사려 깊게 지친 사람이 너무 많은 여분의 소프트 스킬을 강하게 주장하여 최고의 대학에서 (최소한 일시적으로) 탈락했습니다. 사용자 인터페이스를 향한 빚은 빚에 깊이 빠져 있다는 생각이 완전히 좌절에 빠질 수 있기에 충분할 것입니다.

나는 엔트리 레벨과 주니어 레벨의 직업이 요구하는 것을 배우고 CES가 대학의 ABET 인증을 위해 설정 한 것을 배우는 것을 선택해야했다. PERT 평가 결과가 드러날 것입니다. 대학은 가르치는 것을 연습하지 않습니다.

제 생각에는 통합 프로세스에는 많은 장점이 있지만 모델링 언어가 약간 어리석은 시각적 인공물을 만드는 모든 관행이 있습니다. Word, Workflowy, Evernote, OpenOffice로 생성되거나 워드 프로세서와 같은 세리 화 된 목록을 포함하는 반복적으로 정제 된 문서는 통합 프로세스에 필요한 것을 완벽하게 문서화 할 수 있습니다. 이 일반 제인은 여러 사용자가 쉽게 버전을 제어하여 작업 할 수 있으며, 올바른 도구를 선택하면 팀이 동시에 작업 할 수도 있습니다. 이것은 UML이 무리들을 통합하는 데 필요한 모드처럼 보일 때보 다 훨씬 쉽게 수행됩니다.