Программисты часто привыкли приступать к кодированию сразу после получения запроса. Причина просто в том, что необходимость срочная, задача тяжелая, и начальник внимательно за ней следит. Но в реальных сценариях разработки мы часто обнаруживаем, что после написания кода требования изменились; рабочей силы стало больше, но качество писать плохо; В современной системе разработки программного обеспечения, которая предполагает сотрудничество нескольких человек, предварительным решением этих проблем фактически является проектирование и моделирование. Эта статья познакомит вас с началом разработки программного обеспечения и поймет несколько вещей, которые необходимо сделать перед написанием кода.

01. Текущее состояние и практические дилеммы потребностей в разработке программного обеспечения

На заре разработки программного обеспечения я писал код с помощью челнока Ctr C+V. Что такое одиночный тест? Выйдите в Интернет напрямую! Если есть проблема, мы исправим ее в следующей версии. Бизнесу не нужно никого ждать, поэтому нет времени планировать.

Благодаря постоянному развитию Интернета разработка программного обеспечения в нынешнюю эпоху сформировала формальный подход к групповым армейским операциям, систематическому планированию спроса, инженерной реализации и автоматизированному тестированию. —— Постоянно оптимизируйте процесс разработки требований, реализации кода, тестирования и выпуска, а также используйте CICD для ускорения итераций.

Даже широко уважаемая в отрасли «Команда двух пицц», помимо 2-3 сотрудников, занимающихся исследованиями и разработками, также будет иметь определенное количество менеджеров по продуктам, не говоря уже о тестировании, эксплуатации и техническом обслуживании, эксплуатации и другом персонале. . Требования становятся все более и более сложными, а увеличение численности персонала становится неизбежным. Хотите выйти в Интернет? Сначала получите свой номер и расписание!

Однако процесс НИОКР действительно стандартизирован и скорость действительно выросла, но изменения спроса по-прежнему вызывают головную боль у разработчиков, а качество проектов продолжает ухудшаться. Босс все еще находится в невозможном треугольнике «скорость, качество, стоимость», подчеркивая и то, и, и еще раз и снова...

что делать? Структурные проблемы часто неразрешимы, но прежде чем писать код бизнес-требований, действительно можно проделать дополнительную работу для повышения эффективности — проектирование и моделирование.

02. Зачем нам нужно проектировать и моделировать?

Так называемые архитекторы — это те, кто лучше всего справляется с бизнес-абстракцией при разработке программного обеспечения. По мере повышения уровня требования, с которыми сталкиваются инженеры, становятся все более и более абстрактными. Принятие абстрактных требований и создание абстрактной архитектуры — единственный способ для архитекторов достичь совершенства.

Это чем-то похоже на строительную отрасль. Достройка небоскреба часто требует особо точных предварительных расчетов и чертежного проекта. После анализа проекта строительство планируется по чертежам — то же самое следует сделать и при написании кода.

Эффективность моделирования дизайна обусловлена: во-первых, возвращением на взлетно-посадочную полосу бизнеса и соответствием бизнесу; во-вторых, моделирование дизайна может сделать сотрудничество реальным и эффективным;

Суть разногласий между НИОКР и потребностями бизнеса заключается в том, что реализация НИОКР не соответствует реальным потребностям. Если НИОКР сбиваются с пути, потребности не понимаются или сами потребности не могут удовлетворить интересы заинтересованных сторон, функции, которые в итоге будут запущены, потребуют. быть перестроен, что станет пыткой для участников группы. С точки зрения языка дизайна уровни проектирования различаются. Существуют не только проекты в деталях кода, но и проекты высокого уровня в бизнесе. Проекты высокого уровня выражаются в бизнес-терминах, которые наиболее близки к реальной бизнес-ситуации. а также Это может помочь студентам, занимающимся исследованиями и разработками, обнаружить необоснованные моменты в бизнесе.

Моделирование дизайна может сделать сотрудничество эффективным. С одной стороны, на ранней стадии моделирования дизайна происходит согласование коммуникации и информации, а содержание совместной работы расширяется. С другой стороны, стоимость проверки относительно невелика при использовании соответствующих графических инструментов.

03. Три ключевых момента в проектировании и моделировании

3.1 Бизнес-моделирование

Бизнес-моделирование в основном фокусируется на анализе интересов заинтересованных сторон и разъяснении бизнес-процессов. С точки зрения инструментов это в основном диаграммы вариантов использования и блок-схемы; с точки зрения содержания речь в основном идет о поиске людей (заинтересованных сторон, исполнителей системы) и бизнес-субъектов (других систем, связанных важных объектов).

Анализ интересов заинтересованных сторон:

1. Найдите видение программного продукта. Видение выражает основной смысл программного продукта.
2. Найдите соответствующих заинтересованных сторон и их интересы.

Содержание пьесы определяется не актерами, а вкусами различных зрителей. Аудитория сидит в порядке важности, отдавая приоритет вкусам первого ряда, затем второго ряда, третьего ряда... Точно так же программная система должна заботиться об интересах каждого ряда заинтересованных сторон в повернуть. Конфликт и баланс интересов заинтересованных сторон определяют требования системы. Перед теми, кто в заднем ряду, о ком действительно нельзя позаботиться, мне часто приходится извиняться. Эта система может нанести вред вашим интересам.

Диаграмма вариантов использования в бизнесе:

Зная интересы заинтересованных сторон, необходимо проанализировать бизнес-процесс и улучшить существующий процесс. Как велся бизнес до появления программных продуктов? Если вы узнаете, как велся первоначальный бизнес, вы сможете разобраться в сценариях его использования в бизнесе?

В качестве примера возьмем систему покупки и доставки в торговом центре:

Логистические компании и дистрибьюторы оборудования являются исполнителями закупки вспомогательного оборудования, поэтому располагаются справа. Стоит отметить, что варианты использования в бизнесе должны отражать ценность. Хотя в реальном бизнес-процессе продавцы делают много вещей одновременно, например, подписывают контракт на оборудование, подписание контракта на оборудование не может отражать ценность бизнеса, поэтому существует только один вариант использования. приобретение оборудования.

3.2 Анализ бизнес-процессов

Полная схема бизнес-процесса может быть огромной, и вам необходимо обратить внимание на те фрагменты процесса, которые с наибольшей вероятностью затрагивают интересы заинтересованных сторон. Ниже приводится фрагмент процесса поставки оборудования в бизнес-процессе закупки оборудования:

Проблема бизнес-процесса здесь заключается в том, что процесс распределения оборудования является одним из наиболее трудоемких процессов во всем бизнес-процессе и предполагает большую рабочую нагрузку, что не в интересах заинтересованных сторон. Следовательно, системе необходимо улучшить процесс и заменить часть работы людей, как показано ниже.

На диаграмме бизнес-последовательности каждая стрелка представляет собой ответственность. На диаграмме бизнес-последовательности необходимо учитывать иерархию обязанностей. Включение слишком мелких обязанностей в блок-схему приведет к информационной перегрузке и игнорированию наиболее ценных обязанностей.

Анализ бизнес-процессов — очень сложный вопрос. Студенты, занимающиеся исследованиями и разработками, могут использовать информацию, содержащуюся в требованиях, и в то же время добавлять к ним свои собственные ежедневные коммуникации и исследования с заинтересованными сторонами, чтобы понять основные интересы заинтересованных сторон, варианты использования в бизнесе и бизнес-процессы, а затем они может решить серьезные проблемы. Частично проблема заключается в неправильном понимании требований.

3.3 Системное моделирование

Моделирование системы фокусируется на границах между системой и внешним миром, а также на обязанностях самой системы. Оно в основном фокусируется на двух вещах: 1. Рисовании вариантов использования системы. 2. Написание спецификаций вариантов использования.

Диаграмма вариантов использования системы

Диаграмма вариантов использования системы – это ценное взаимодействие между исполнителями системы и системой в бизнес-процессе. система Исполнителем может быть человек, может быть внешняя система или даже время. Сценарии использования системы должны отражать ценность системы, система будет делать много вещей для достижения бизнес-ценности, мы должны сосредоточиться Ценность бизнеса. Некоторые из них относятся к низкоуровневым обязанностям и не имеют особой системной ценности. Например: «Получение информации о заказе торгового центра» происходит с целью доставки оборудования в заказе, и должно выполняться таким образом. на"распределительное оборудование".

Ниже представлена ​​схема вариантов использования складской распределительной системы:

Спецификация варианта использования системы

Со схемой бизнес-процесса и диаграммой. вариантов использования системы,Ограничения на границы необходимо дополнительно уточнить на основе,Обеспечьте стабильность системы. Взаимодействие исполнителя системы с системой уточняет подробные ограничения,Стабильность системы может быть улучшена,Если ограничения не перечислены тщательно,Можно игнорировать некоторые граничные условия,Сбой, который вызывает система, например: система складской дистрибуции не учитывает ограничение на количество доставляемых устройств для заказов из сторонних торговых центров;,будет из-за ошибок в сторонних торговых центрах,что приводит к потерям активов.

Системные ограничения исходят из вариантов использования системы, которые подробно описывают основные пути, расширенные пути и ограничения в бизнес-процессе в соответствии с бизнес-правилами. Стоит отметить, что ограничения не говорят студентам, занимающимся исследованиями и разработками, как реализовывать функции. Ограничения относятся к бизнес-правилам, которые уточняют границу между системным исполнителем и системой, а также ограничения на границе. Во время проверки проекта вы можете обратить внимание на то, соблюдаются ли правила безопасности на критическом пути. Это значительно поможет повысить безопасность и стабильность системы.

3.4 Анализ и проектирование классов

Класс идентификации

Обычно существует три общих класса — граничные классы, классы управления и классы сущностей. Граничные классы — это отображение внешних систем внутри системы. Через граничные классы система взаимодействует с внешними системами. Некоторые запросы интерфейса, ввод и вывод являются обязанностью граничных классов. Классы управления часто отражают процесс варианта использования. Обычно вариант использования представляет собой класс управления. Классы сущностей являются ядром системы. Хороший дизайн классов сущностей может улучшить повторное использование системы и снизить ее сложность.

Найдите существительные сущности

Чтобы идентифицировать конкретные классы, нужно искать существительные, которые часто встречаются в бизнес-процессах, системных процессах и системных спецификациях. На предыдущей блок-схеме заказы, торговые центры, оборудование, логистика и пользователи имеют повторяющиеся имена, что указывает на то, что это бизнес-сущности класса.

Найти атрибуты

Атрибуты класса не создаются из воздуха и должны быть ценными для бизнес-реализации. Найдите те атрибуты, которые необходимы для реализации системы, и поместите их в правильные классы. Например, заказы в системе складского распределения включают номера заказов, продукты и пользователей. У пользователя есть адрес доставки.

Найдите обязанности

В бизнес-правилах и ограничениях вы можете найти обязанности, которые должны иметь некоторые сущности. Взяв в качестве примера заказ, он несет ответственность за проверку законности.

государственная машина

Для некоторых основных классов сущностей также необходимо спроектировать его государственную машина,Четкая государственная машина может эффективно прояснить некоторые события и состояния в системе.,Повышение общей надежности системы.

В качестве примера возьмем заказ в системе складской дистрибуции.,Статус ожидания доставки приобретен у пользователя,Уведомленная логистическая доставка,до фактической доставки,Логистическое получение имеет ряд изменений статуса.,Это все отражено в государственной машине.

04. Резюме

В различных теориях моделирования упоминается множество концепций-существительных. Каждую концепцию можно написать как главу или книгу, если рассматривать ее отдельно. Рекомендуется вначале не увлекаться пониманием и запутанностью различных сложных концепций. Сначала полностью поймите, что такое объектно-ориентированное моделирование, а затем вернитесь назад и прочтите множество приемов, объясненных в различных источниках. книги по моделированию, т. к. все эти методы вращаются вокруг поиска людей, вещей, объектов и правил в мире программных объектов. Также настоятельно рекомендуется всем прочитать классические книги, такие как «Методы программного обеспечения» и «Моделирование и проектирование программного обеспечения».

Написание хорошего кода — это всего лишь инженерный метод реализации программного обеспечения. Без хорошего проектирования и моделирования, каким бы хорошим ни был код, это может оказаться напрасной тратой. Что вы думаете?

-End-

Автор оригинала ｜Борис