의사 코딩에 의한 소프트웨어 설계?

의사 코드 기반의 방법으로 소프트웨어를 설계 (즉, 기록)하는 좋은 방법을 알고 있습니까?

저는 소프트웨어 디자인을 처음 사용하고 UML에 대한 정보를 읽었습니다. 저의 겸손한 계층 구조는 지금까지는 훌륭하지만, 복잡해지면 "전체를 본다"그림을 통해 미래의 확장 성을 위해 다른 구조를 사용할 수 있습니다. 파이썬은 프로토 타이핑에 좋기 때문에 글을 쓰기 시작했지만 거의 그렇지 않습니다.

그래서 UML 클래스 다이어그램을 시도했지만별로 도움이되지 않는 것 같습니다. 내가 거기에서 해결하는 문제는 내 머리에서 사소하게 할 수 있습니다. 그러나 실제 방법을 의사 코드하기 시작하면 추가 설계 요구 사항에 주목합니다.

의사 코드로 디자인하려면 어떻게 하시겠습니까? 나는 코드와 거의 일대일 방법이 가장 효과적이라고 생각합니다. 그러나 대부분의 UML 소프트웨어는 (예를 들어 GoF의 그림과 달리) 메소드의 코드조차 보여주지 않습니다.

누군가 UML이 문서화 및 프리젠 테이션 전용이며 디자인에는 적합하지 않다고 주장 했습니까? 나도 그 느낌을 얻습니다. 인터넷 검색을 할 때까지 순수한 UML과 간단한 화이트 보드 스케치가 소프트웨어를 디자인하는 방법이라고 생각했습니다.

애자일 개발은 내가 조심해야하거나 애자일이라고 무작위로 부르는 것입니까? 또는 UML로 잘못 설계하고 있습니까? 모든 사람이 의사 코드로 설계합니까? 이를위한 좋은 도구를 어떻게 찾을 수 있습니까?

 I thought agile is about schedule only?

단지 계획이 아닙니다. 애자일 소프트웨어 개발은 ​​제품 소유자가 요청한 변경 사항에 유연하게 대응할 수 있도록 적응 형 계획을 통해 혁신적인 개발 및 시간에 따라 반복되는 전달 방식에 관한 것입니다.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

내 경험상 차트는 고객의 입장에서 이해하기가 훨씬 쉽습니다. 그들은 시각적으로 매력적이며 여러 번 매우 화려하고 따르기 쉽습니다. 그러나 실제 응용 프로그램 코드와의 연결 끊기 특성으로 인해 차트를 유지 관리하는 것은 매우 어렵습니다. 응용 프로그램이 변경 될 때마다 개발자는 차트를 포함한 모든 문서를 업데이트해야합니다. 그러나 팀이나 회사에 BA가 있으면 클라이언트 비즈니스 프로세스를 잘 이해하고 UML 다이어그램을 관리 할 수 ​​있으면 문제를 쉽게 제거 할 수 있습니다.

UML과 같은 도구를 사용하면이 프로세스를보다 쉽게 ​​수행 할 수 있지만 객체 지향 프로그래밍에서만 잘 작동합니다. 의사 코드는 기술 팀에게 훨씬 더 쉽습니다. 이 코드를 작성하면 실제 프로그래밍 언어 개발 단계의 속도가 크게 향상됩니다.

당신이 볼 수도있는 다른 대안이 있습니다 :

• 데이터 흐름 다이어그램
• 상태 다이어그램
• 프로세스 흐름도

보기 좋은 참조 : Software Design Tutorials . 또한 Pseudocode 또는 Code 에 대한 좋은 블로그를 읽으라는 조언을 개인적으로 원 하십니까? 게시자 : Coding Horror- 내가 좋아하는 블로그 :)

대체로 고려해야 할 몇 가지 장단점이 있습니다.

어셈블리 언어로 프로그래밍 할 때는 의사 코드를 작성하는 것이 좋습니다. 알고리즘을 수동으로 어셈블리 언어로 번역 한 다음 번역을 디버깅하기 전에 알고리즘을 검증 할 수 있습니다. FORTRAN IV와 같은 1 세대 컴파일 언어에는 여전히 의미가 있습니다. 유일한 제어 구문은 GOTO이고 모든 변수 (공식 인수 제외)는 전역 변수이며 변수 이름은 6 자로 제한되었습니다.

오늘날 우리는 어셈블리 언어로 프로그래밍을 거의하지 않으며 단지 코드를 작성하는 대신 의사 코드를 작성하는 데 아무런 가치가 없습니다. 괜찮은 언어로 실제 코드는 단어에 대한 의사 코드와 거의 유사하며 의사 코드는 시간 낭비입니다.

그러나 맨 아래에서 코딩을 시작하지 않습니다. TDD를 따르고 테스트를 시작합니다. 그런 다음 상단에서 코딩을 시작하고 필요에 따라 테스트를 통과하기 위해 점차 하단에서 아래쪽으로 작업합니다.

의사 코드의 대안은 1000 줄의 저수준 클래스를 작성하지 않습니다. 대신 도메인에 이상적이지만 존재하지 않는 API를 호출하여 맨 위에서 시작하십시오. 그런 다음 API를 빌드하십시오.

모든 메소드 나열을 건너 뛰고 상속 계층 구조를 간단히 표시하더라도 클래스 다이어그램은 노력의 가치가 거의 없습니다. 시퀀스 다이어그램은 좋지만 그림을 그릴 때 어색합니다 (아마도 나만).

데이터 플로우 다이어그램과 구조 차트가 더 유용하다는 것을 알았습니다 (구조 차트는 일반적으로 BDUF와 연관되어 있으므로 현재 선호되지 않습니다). DFD는 기능 분해에 특히 유용합니다. DFD의 각 "버블"은 원하는 세부 수준에 도달 할 때까지 자체 DFD로 분류 할 수 있습니다.

필자는 그래픽 도구가 의사 코딩보다 낫다고 생각하지만 UML은 너무 복잡하여 이러한 방법의 단점을 결합합니다.

좀 더 명확하게 말하면 : 프로그래밍은 대부분 특정 문제를 분석하고 더 작은 구성 요소와 상호 작용으로 분리하는 방법이라고 생각합니다. 이것은 "목적지가 아닌 여정"입니다. 문제에 대한 지식을 지속적으로 향상 시키므로 구성 요소의 그래프가 변경됩니다. 레이어가 나타나거나 사라지고, 기능 및 데이터 항목이 위아래로 이동하는 등

이 과정을 따르는 자연스러운 도구는 가능한 한 간단한 스케치 보드이지만 빠른 이해 (동일한 색상, 모양, 동일한 논리적 의미의 화살표)를 이해하는 데 도움이 될만큼 복잡합니다. 나는 은색 총알을 찾지 못했을 것이고, 아마도 나는 내 자신의 하루를 쓸 것입니다. 그러나 지금 나는 gliffy를 사용 합니다 ; prezi 의 줌 기능과 결합 하면 거의 완벽합니다.

왜 의사 코딩하지 않습니까? 의사 코딩은 아이디어를 구체화 할 때 구현을위한 한 단계 진보 인 "직렬화 된 구성 요소 그래프"입니다. 좋지 않다, 당신의 머리를 제한합니다. 내 경험에 따르면 나중에 코딩을 시작할수록 더 적은 코드를 버려야합니다.

그러나 아마도 이것은 던져진 코드를 모두 작성했기 때문에 지금 작성할 필요가 없습니다. 시스템을 설계 할 때 얻은 경험은 나와 함께 있습니까? 글쎄, 나는 진술을 수정해야한다.

그래프를 잃어 버리고 가능한 동등한 솔루션을 많이 보더라도 의사 코드로 이동하거나 모의 객체로 해당 코드를 작성하십시오 .Java에서는 거의 차이가 없습니다. 코드를보고 해당 구성 요소의 구조와 유용성을 느끼면 그래프를 수정하고 결정을 내리는 데 도움이됩니다. 그러나 코드가 나쁘다고 생각되면 해당 코드를 버릴 준비가 된 경우에만 작동합니다. 나는 이것이 의사 코드의 장점이라고 생각합니다. 작동 할 때 유지하려는 유혹은 적지 만 구조상 잘못되었습니다 (항상처럼 시간이 충분하지 않습니다). :-)