GRASP 소프트웨어 개발 모델에 대한 간략한 토론-C#.Net 튜토리얼-php.cn

당신은 좋은 소프트웨어 개발자입니까? 그랩(GRASP)을 아시나요? GRASP 소프트웨어 개발 모델(전체 이름은 General Responsibility Assignment Software Patterns)은 유명한 소프트웨어 모델 GoF(Gang of Four, 우리가 흔히 부르는 23개 소프트웨어 개발 모델)만큼 유명한 소프트웨어 개발 모델입니다. 그러나 GoF와 달리 특정 소프트웨어 조직 구조를 제안하는 것이 아니라, 소프트웨어 개발에서 실제 비즈니스 기능을 특정 객체로 추상화하는 과정에서 우리가 따라야 할 사항을 몇 가지 기본 원칙으로 제안합니다. . 이러한 기본 원칙을 준수해야만 고품질 소프트웨어를 개발할 수 있습니다. 우리가 개발하려는 소프트웨어 프로젝트에는 팩토리 패턴을 사용할 필요가 없고, 싱글턴 패턴을 사용할 필요가 없으며, 사용할 필요도 없습니다. 관찰자 패턴이지만, 소프트웨어 개발에서 실제 비즈니스 기능을 구체적인 객체로 추상화하지 않는 것은 불가능합니다. 이러한 관점에서 우리는 소프트웨어 개발의 품질을 향상시켜야 합니다. GoF에 대한 깊은 이해보다 GRASP에 대한 깊은 이해가 더 중요합니다. 그런데 GoF를 소개하는 글은 많고, GRASP를 소개하는 글은 거의 없는 것 같습니다. 이 때문에 저는 이제 모든 사람에게 GRASP를 소개합니다.
GRASP에는 9가지 기본 원칙인 9가지 모델이 포함되어 있습니다. 이는 소프트웨어 디자인 전문가인 Craig Larman이 쓴 고전 책 "UML and Pattern Application"에 자세히 설명되어 있습니다. GRASP는 일반 책임 할당 소프트웨어 패턴(General Responsibility Assignment Software Pattern)이라고 합니다. GRASP를 이해하기 위해 먼저 이해해야 할 질문은 객체 분석 및 설계 프로세스 중에 책임을 할당해야 하는 이유입니다.

1. 책임 배분과 책임 중심 설계

일반적으로 소프트웨어 프로젝트 초기에는 고객이 어떤 종류의 소프트웨어를 설계해야 하는지, 그 소프트웨어가 어떤 기능을 수행해야 하는지 이해하기 위해 요구 사항 분석을 수행해야 합니다. 있어야합니다. 요구사항 분석은 현실 세계에서 고객이 요구하는 비즈니스 기능을 이해합니다. 각 비즈니스 기능은 비즈니스 프로세스, 즉 고객이 일상 업무에서 계속 완료하는 비즈니스 프로세스인 경우가 많습니다. 동시에, 사용자의 문제 세계에는 서로 연관된 어떤 것, 사물이 있어야 합니다.
소프트웨어 리뷰 관리 시스템을 예로 들어보겠습니다. 리뷰관리 시스템의 업무 요구사항은 다음과 같습니다.
1. 리뷰 주최자는 리뷰 계획을 개발하고 승인을 위해 리더에게 제출한 다음 이메일을 통해 리뷰어에게 알립니다.
2． 리뷰어는 리뷰 대상을 각각 검토하라는 알림을 받고, 리뷰 양식을 작성하며, 리뷰 대상에 대해 질문을 제기할 수 있습니다.
3． 리뷰 주최자는 리뷰어의 질문을 요약하고 리뷰 회의를 열어 이러한 질문에 대해 논의합니다. 회의에서 어떤 질문은 문제가 되었고, 어떤 질문은 문제가 되지 않았으며, 어떤 질문은 아직 확인이 되지 않았습니다.
4． 회의가 끝난 후, 리뷰 주최자는 질문을 정리하고 리뷰 보고서를 작성하며, 리뷰어들은 리뷰의 통과 여부를 투표합니다. 마지막으로 검토 주최자는 투표 결과를 요약하고 검토 결론을 내립니다.
5． 검토 주최자는 문제 해결을 추적합니다.
위 요구사항에 대한 설명을 통해 리뷰 정리자, 리뷰 계획, 리뷰어, 리뷰 대상, 리뷰 양식, 질문, 리뷰 보고서, 리뷰 결론, 그리고 리뷰 정리 등 문제 세계 전체에서 관련된 것들을 찾는 것은 어렵지 않습니다. 질문. 예를 들어 검토 계획과 검토자는 일대다인 반면, 검토 보고서와 검토 결론은 일대일입니다.
RUP에서는 비즈니스 요구 사항이 모델과 해당 설명 문서에서 유스 케이스를 형성하고, 사물과 그 관계는 도메인 모델에서 객체를 형성합니다. 물론 유스 케이스 모델과 도메인을 만드는 방법도 마찬가지입니다. 모델은 이 기사를 벗어납니다. 토론 범위와 관련하여 관심 있는 친구는 관련 기사를 읽을 수 있습니다.
도메인 모델의 객체는 소프트웨어 개발에서 특정 객체를 형성하는 기초가 됩니다(소프트웨어 개발에서 어떤 객체가 형성되는지는 소프트웨어 개발의 특정 요구에 따라 결정되며 반드시 객체와 일치할 필요는 없습니다). 도메인 모델). 유스 케이스 모델의 유스 케이스는 이러한 객체에 동작을 할당하여 구현됩니다. 이제 사용 사례 모델의 기능이나 일련의 동작을 이러한 개체에 어떻게 할당해야 하는지에 대한 질문이 생깁니다. 즉, 동일한 작업을 완료하기 위해 동작 A를 개체 X나 개체 Y에 할당할 수 있습니다. 동작 A에 대한 구체적인 구현은 개체 X에 전달할 때와 개체 Y에 전달할 때 다르지만 둘 다 동작 A의 작업을 완료할 수 있습니다. 그럼 객체 X에게 넘겨주어야 할까요, 아니면 객체 Y에게 넘겨주어야 할까요? 기본 원칙이 있나요? 예, 책임에 따라 업무를 할당하는 것입니다. 이론적으로는 객체를 임의로 정의하거나 객체를 의미 없게 만들거나 어떤 작업을 완료할 수 있지만 일반적으로 우리는 이렇게 디자인하지 않습니다. 일반적으로 검토 계획 개체 및 검토자 개체를 설계하는 등 개체를 실제 개체와 연결합니다. 그리고 객체를 디자인할 때 "낮은 표현 차이"를 달성해야 합니다. 표현 차이가 낮다는 것은 우리가 디자인하는 객체가 실제 객체와 최대한 일치해야 함을 의미합니다. 예를 들어, 현실 세계에는 리뷰어가 있기 때문에 "리뷰어"라는 개체를 디자인합니다. 동시에 리뷰어 개체에 할당하는 동작은 리뷰어 추가, 리뷰어 수정, 리뷰어 정보 획득 등 실제 세계와 최대한 일치해야 합니다. 따라서 이 개체에 어떤 동작을 할당해야 하는지는 책임에 따라 결정되어야 합니다.
실제 세계 분석이나 도메인 모델 분석을 통해 소프트웨어 시스템의 개체를 설계합니다. 이때 각 개체에 책임을 할당해야 합니다. 객체의 책임은 무엇인가? 물론 현실 세계에 대한 분석과 이 객체가 완료해야 하는 작업을 통해 정의됩니다. 예를 들어 리뷰어 개체의 책임은 리뷰어와 관련된 데이터에 액세스하는 것입니다. 물론, 객체의 책임이 반드시 동일할 필요는 없다. 예를 들어 리뷰 계획에는 리뷰 객체와 리뷰어의 하위 항목이 포함되어 있으므로 리뷰 객체와 리뷰어의 정보 접근을 처리할 수 있다. 일이 바쁘지 않을 때 대신합니다. 그러나 객체는 너무 많은 책임(단지 2~3개)을 가져서는 안 되며 관련성이 높아야 합니다. 예를 들어 평가 양식의 개체에 평가 양식을 처리하고 평가 계획의 데이터도 처리하는 책임이 할당된 경우 이를 책임 독립적이라고 합니다.
책임 분배는 이제 우수한 소프트웨어 설계가 따라야 하는 원칙으로 일반적으로 인식됩니다.
1. 표현 차이가 적으면 소프트웨어 개발이 한 사람의 일이 아니기 때문에 소프트웨어가 명확하게 구조화되고 이해하기 쉽습니다. 여러 사람이 개발하는 소프트웨어 프로젝트에서 명확한 소프트웨어 구조는 개발자의 오해로 인한 불필요한 오류를 피할 수 있습니다.
2． 유지 관리 및 변경이 쉽습니다. 검토계획에 문제가 있거나 수정이 필요한 경우에는 검토계획으로 가겠습니다. 검토자에게 문제가 있는 경우 검토자에게 문의할 것이며, 다른 것과는 절대 관련이 없습니다. 파티.
이런 객체, 책임, 협업을 고려한 객체 디자인과 컴포넌트 접근 방식을 '책임추진 디자인(RDD)'이라고 합니다. 책임 중심 설계에는 먼저 유스 케이스 모델, 유스 케이스 모델 설명, 운영 계약, 시스템 시퀀스 다이어그램, 도메인 모델 및 용어집을 설계한 다음 단계별로 분석 모델 및 설계 모델을 만들고 각각에 대한 상호 작용 다이어그램 및 클래스 다이어그램을 작성하는 작업이 포함됩니다. 여기서는 복잡한 프로세스에 대해 자세히 설명하지 않겠습니다. 그러나 매우 중요한 세부 사항에 주의하십시오. 앞서 말했듯이 소프트웨어 시스템의 객체는 현실 세계에서 추상화되어 객체의 정의를 기반으로 하며 몇 가지 관련성이 높은 작업을 할당합니다. 그러나 이러한 원칙을 따른다 하더라도 우리는 여전히 상당한 디자인 유연성을 가지고 있습니다. 사람들은 여전히 자신의 이해를 바탕으로 동일한 기능에 대해 다른 디자인을 가지고 있습니다. GRASP는 중국어로 "일반 책임 할당 소프트웨어 패턴"으로 번역되며 객체 분석 및 설계에서 책임 할당 문제에 대한 몇 가지 기본 원칙을 제시합니다. 동시에 이러한 기본 원칙도 어느 정도 파악해야 합니다. 즉, 모든 상황에 적용할 수 있는 것도 아니고 절대적인 지표도 아닙니다. 예를 들어, 낮은 결합도는 절대적인 비결합을 의미하지 않으며, 결합이 없으면 소프트웨어를 설계할 수 없으며, 그렇지 않으면 시스템이 복잡하고 비정상적일 수 있습니다.