Kitten은 계속 책임을 맡았는데 이는 그의 경력에서 처음 있는 일이었습니다. 새끼 고양이의 상황에 관심이 있다면 "멱등성 이벤트"와 "캐시 분해 이벤트"에 대해 알아볼 수 있습니다.
오늘 팀장은 새끼 고양이와 함께 회의실에 왔습니다.
짧은 시간 동안 너무 많은 사고가 발생했기 때문에 이것이 쉽지 않은 일이라는 것을 이해합니다. 결국 당신은 이 프로젝트를 맡게 되었습니다. 어쩌면 프로젝트 자체에 문제가 있을 수도 있습니다. 이제 책임은 당신에게 있으니, 낙심하지 마시길 바랍니다..."라고 팀장은 이어갔다.
새끼 고양이는 병아리를 바라보며 안도감을 느끼며 고개를 끄덕였습니다. '팀장님이 내 활약을 비난하지 않으실 것 같다'라고 생각했어요
그러나 문제가 발생했으며 비즈니스, 코드 또는 디자인 측면을 포함하여 시스템에 다른 문제가 있을 수 있습니다. 시간을 내어 프로젝트 문서의 분석을 정리하고 준비하십시오. 다음 월간 회의에서 시스템의 현재 상태를 귀하와 공유할 수 있기를 기대합니다.
꼬마 고양이는 "이건 변장한 모델을 잡는 것 정도라고 봐야지. 그런데 그런 문서는 어떻게 작성해야 하지?"라고 생각하면서 계속 고개를 끄덕였습니다.
이때 새끼 고양이는 다시 불안감을 느끼기 시작했습니다.
새로운 시스템을 인수할 때 어떻게 익숙해지나요? 사실 라오마오는 지난 기사 '캐시 침투 사건' 말미에 모두에게 물었고, 아직도 감상이 있으신지 궁금해요.
이제 늙은 고양이가 새로운 시스템에 익숙해지는 과정에 대해 이야기해 보겠습니다. 이러한 경험이 여러분에게 도움이 되기를 바라며 여러분만의 방법을 공유해 주시기 바랍니다. 주요 단계는 다음과 같습니다:
프로젝트 친숙함
새로운 비즈니스 시스템을 받은 후에는 먼저 현재 시스템이 어떤 역할을 하는지 알아야 하기 때문에 때로는 비즈니스를 이해하기 위해 관련 제품 관리자를 찾는 시간이 필요할 수도 있습니다. 현재 상황에 대해 일부 비즈니스 상태 및 배경에 대해 설명할 수도 있지만 V0-Vn 버전의 제품 요구 사항 계획을 직접 제시할 수도 있으며 해당 직원이 참석할 수 없다고 말할 수도 있습니다. 후자라면, 아직 협력이 시작되지 않았기 때문에 잠시 멈춰서 제품의 얼굴을 모니터로 치지 마십시오. 농담입니다. 본론으로 들어가겠습니다.
먼저 유스 케이스 다이어그램이 무엇인지 이해해 봅시다.
사용 사례 다이어그램에 대한 간략한 분석
사용 사례는 시스템의 기능 단위이며 실행자와 주체 간의 상호 작용으로 설명할 수 있습니다. 행위자는 시스템, 하위 시스템 또는 클래스와 상호 작용하는 외부 사용자, 프로세스 또는 기타 시스템의 이상적인 역할입니다.
목적: 시스템의 유스케이스와 실행자를 나열하고, 어떤 실행자가 어떤 유스케이스의 실행에 참여하는지 표시할 수 있습니다.
마오마오가 이전에 접했던 '주문 및 결제 비즈니스 포인트'에 대해 유스케이스 다이어그램을 그려서 설명하겠습니다. 아래와 같이:
사용 사례
위 사진은 사실 간단한 유스케이스 다이어그램입니다. 우리가 알아내야 할 것은 다양한 선의 의미입니다.
이를 통해 현재 비즈니스 상황을 명확하게 이해할 수 있습니다.
현재 시스템 기능 포인트와 비즈니스 형태를 정리한 후, 기존 시스템 모델, 즉 DB 데이터베이스의 테이블을 살펴보겠습니다. 이를 통해 현재 설계된 시스템이 비즈니스를 어떻게 추상화하는지 알 수 있습니다. 그러면 관련 테이블을 보면 실제로 천천히 ER 다이어그램을 그릴 수 있습니다.
ER 다이어그램이란 무엇입니까
E-R 다이어그램은 엔터티 관계 다이어그램의 전체 이름으로 엔터티 유형, 속성 및 관계를 나타내는 방법을 제공하며 실제 세계의 개념적 모델을 설명하는 데 사용됩니다.
정의를 통해 우리는 실제로 ER 다이어그램에 엔터티 클래스, 속성 및 연결이라는 세 가지 중요한 점이 있다는 것을 알고 있습니다. 우리가 DB 테이블을 구성할 때 실제로는 우리의 테이블, 테이블 필드, 해당 테이블과 테이블 간의 관계에 해당됩니다.
일반 쇼핑몰 시스템의 기본 제품 로직을 예시로 그려보겠습니다.
ER 예시
각 그림의 의미를 설명하세요:
위 그림에서 실제로 현재 시스템에는 상품, 상품 풀, 선반이라는 세 가지 중요한 엔터티 개념이 있다는 것을 더 명확하게 볼 수 있습니다. 그림에서 우리는 그들 사이의 관계를 대략적으로 볼 수도 있습니다.
ER 다이어그램을 정리하고 나면 위에서 언급한 Use Case 비즈니스 다이어그램이 기존 시스템에서 어떻게 추상화되어 있는지 분명해질 것입니다.
이렇게 얘기했는데, 신의 관점에서 살펴보겠습니다. 우리는 현재 시스템에 뼈대를 부여한 다음 심장이 뛰고 혈액이 돌게 하고 전체 시스템에 영혼을 부여해야 합니다. 그런 다음 프로세스를 통해 모델을 하나로 묶습니다.
실제로 Laomao는 흐름도를 정리하는 것이 상대적으로 간단할 수 있다고 생각하지만, 전체 과정에서 링크를 제어하는 방법이 어렵다고 생각합니다. 그림을 그릴 때 좀 더 신중하게 생각한다면 재고의 모든 단계를 기록할 수 있을 것입니다. 이 경우 비즈니스에 대한 집중도가 떨어집니다. 도면이 너무 두꺼우면 모델 간의 해당 관계가 제대로 제어되지 않을 수 있습니다. 따라서 Laomao는 이곳이 프로그래머의 일반화 능력과 비즈니스 이해 능력을 테스트하는 곳이라고 생각합니다.
흐름도
위 그림은 단순히 흐름도를 그린 것입니다. 물론 흐름도에 오류가 있을 수 있으니 너무 심각하게 받아들이지는 마세요. 내부의 비즈니스 프로세스. 위 프로세스에서 다음과 같은 그래픽 콘텐츠를 볼 수 있습니다.
위 프로세스의 표현은 실제로 비교적 간단하며 시스템 경계에 신경 쓸 필요가 없습니다. 그냥 그려보세요.
하지만 현재 개발 시스템은 마이크로서비스 기반인 경우가 많기 때문에 이때는 서로 다른 시스템 간의 상호 작용 프로세스를 고려해야 할 수도 있습니다. 이를 통해 수영 레인의 개념을 소개할 수 있다. 아래를 참조하세요.
수영 레인 프로세스
위 그림에서는 다양한 시스템 애플리케이션 간의 상호 작용을 볼 수 있습니다. 각 수영 레인은 마이크로서비스 시스템 중 하나를 나타냅니다. 이것은 라오마오가 실제로 사업에 익숙해지면서 그린 그림입니다. 꼭 보아야 할 것은 그림의 일부 아이디어이며, 사업에 너무 얽매이지 말라는 점을 다시 한번 강조하고 싶습니다.
좀 더 자세히 살펴보겠습니다. 예를 들어 주문 상태의 흐름을 논의할 때 더 나은 제어를 위해 몇 가지 상태 흐름도를 사용하여 정리하겠습니다.
상태 이전
위 내용은 주로 프로세스의 전체 상태 흐름을 설명합니다. 물론 상태 비트가 상대적으로 단순하면 상태 머신을 그릴 필요가 없는 경우가 많습니다. 복잡하고 다양합니다.
위 내용은 나는 새로운 비즈니스 시스템을 인수하게 되었고 그것에 대해 매우 잘 알고 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
