Как вы планируете архитектуру приложения перед написанием кода?

http://dn.codegear.com/article/31863

Я использую UML и считаю это руководство довольно полезным и легким для чтения. Дайте мне знать, если вам нужно что-то другое.

Если вы разрабатываете для .NET, Microsoft только что опубликовала (как бесплатную электронную книгу!) Руководство по архитектуре приложений 2.0b1. Он предоставляет массу действительно хорошей информации о планировании вашей архитектуры перед написанием любого кода.

Если бы вы были в отчаянии, я думаю, вы могли бы использовать большие куски для архитектур, не основанных на .NET.

UML - это обозначение. Это способ записать ваш дизайн, но не (на мой взгляд) его создание. Если вам нужно что-то записать, я бы порекомендовал UML, но не потому, что он «лучший», а потому, что это стандарт, который другие, вероятно, уже умеют читать, и он лучше, чем изобретение собственного «стандарта».

Я думаю, что лучшим введением в UML по-прежнему остается UML дистиллированный Мартина Фаулера, потому что он краток, дает практическое руководство о том, где его использовать, и дает понять, что вам не нужно принимать во внимание всю историю UML / RUP, чтобы она была полезный

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

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

Но лучший совет - это читать внимательно, хорошо думать и практиковаться. Это не просто навык, которому можно научить, вы должны его действительно делать.

Я действительно считаю, что сначала писать на бумаге или на белой доске очень важно. Затем переходите к UML, если хотите, но ничто не сравнится с гибкостью простого рисования сначала вручную.

Вначале я скажу, что я занимаюсь в основном веб-разработкой, где большая часть архитектуры уже определена заранее (WebForms, теперь MVC), и большинство моих проектов - это относительно небольшие усилия одного человека, которые занимают менее года. Я также знаю, что у меня будет ORM и DAL для обработки моего бизнес-объекта и взаимодействия с данными соответственно. Недавно я переключился на использование LINQ для этого, поэтому большая часть «дизайна» сводится к проектированию базы данных и отображению через конструктор DBML.

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

К этому времени я обычно имею довольно хорошее представление об архитектуре. Если это сложно или есть необычные детали - вещи, которые отличаются от моей обычной практики - или я работаю с кем-то другим (нетипично), я схематически это (снова на доске). То же самое и со сложными взаимодействиями - я могу разработать макет страницы и поток на доске, сохраняя ее (или снимая с камеры), пока не закончу с этим разделом. Когда у меня появится общее представление о том, куда я иду и что нужно сделать в первую очередь, я начну писать тесты для первых историй. Обычно это звучит так: «Хорошо, для этого мне понадобятся эти классы. Я начну с этого, а он должен сделать это». Затем я весело начинаю работать с TDD, и архитектура / дизайн растут в соответствии с потребностями приложения.

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

Считаю следующее:

1. что система должна делать, то есть какую проблему пытается решить система
2. кто заказчик и каковы его пожелания
3. с чем должна интегрироваться система
4. есть ли какие-либо унаследованные аспекты, которые необходимо учитывать
5. каковы взаимодействия пользователей
6. так далее...

Затем я смотрю на систему как на черный ящик и:

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

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

UML очень хорошо отражает такое поведение. Вы можете описать большинство систем, используя только два из множества компонентов UML, а именно:

• диаграммы классов и
• диаграммы последовательности.

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

Хорошим ресурсом для изучения UML является превосходная книга Мартина Фаулера «UML Distilled» (Ссылка на Amazon - дезинфицирована для скриптовых нацистов (-:). Эта книга дает вам быстрый взгляд на основные части каждого из компонентов UML .

Ой. То, что я описал, в значительной степени является подходом Ивара Якобсона. Якобсон - один из Трех Амигосов ОО. Фактически, UML был первоначально разработан двумя другими людьми, которые составляют Three Amigos, Грэди Буч и Джим Рамбо.

Я не уверен, что что-то может будет запланировано заранее до реализации. У меня есть 10-летний опыт работы, но это было только в 4 компаниях (включая 2 сайта в одной компании, которые были почти полярными противоположностями), и почти весь мой опыт был связан с наблюдением за колоссальным кластером ****** ** ы случаются. Я начинаю думать, что такие вещи, как рефакторинг, действительно лучший способ делать что-то, но в то же время я понимаю, что мой опыт ограничен, и я, возможно, просто реагирую на то, что видел. Что я действительно хотел бы знать, так это то, как получить лучший опыт, чтобы я мог прийти к правильным выводам, но похоже, что нет никакого ярлыка, и просто нужно много времени видеть, как люди делают что-то неправильно :(. Я Мне бы очень хотелось попробовать поработать в компании, где люди все делают правильно (о чем свидетельствует успешное развертывание продуктов), чтобы узнать, являюсь ли я просто противным ублюдком или действительно настолько умен, как я думаю Я.

Я хочу сказать, что UML можно использовать для архитектуры приложений, но чаще он используется для технической архитектуры (фреймворки, диаграммы классов или последовательностей, ...), потому что именно здесь эти диаграммы легче всего синхронизировать с разработкой. .

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

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

Поэтому, если вам нужно обработать несколько больших финансовых портфелей (функциональная спецификация), вы можете решить, что вам нужно разделить эту большую спецификацию на:

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

Итак, по сути, думать о архитектура приложения - значит решать, какую «группу файлов» вам нужно разработать согласованным образом (вы не можете разработать в одной и той же группе файлов средство запуска, графический интерфейс, диспетчер, ...: они бы не сможет развиваться в одном темпе)

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

Вам обязательно стоит взглянуть на Полный код Стива МакКоннелла. и особенно в его бесплатной главе "Дизайн в строительстве"

Вы можете скачать его с его сайта:

http://cc2e.com/File.ashx?cid=336

Я пытаюсь разбить свое мышление на две части: представление о вещах, которыми я пытаюсь манипулировать, и о том, что я собираюсь с ними делать.

Когда я пытаюсь смоделировать то, чем пытаюсь манипулировать, я придумываю серию дискретных определений предметов - на сайте электронной торговли будет артикул, продукт, покупатель и т. д. У меня также будут некоторые нематериальные вещи, с которыми я работаю - заказ или категория. Как только у меня будут все «существительные» в системе, я создам модель предметной области, которая показывает, как эти объекты связаны друг с другом - заказ имеет клиента и несколько SKU, многие skus сгруппированы в продукт, и поэтому на.

Эти модели предметной области могут быть представлены в виде моделей предметной области UML, диаграмм классов и SQL ERD.

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

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

Я недостаточно умен, чтобы планировать что-то наперед. Когда я планирую наперед, мои планы всегда сбиваются, но теперь я потратил п дней на плохие планы. Мой лимит составляет около 15 минут на доске.

По сути, я стараюсь как можно меньше работать, чтобы понять, иду ли я в правильном направлении.

Я смотрю на свой дизайн в поисках критических вопросов: когда A переходит от B к C, будет ли это достаточно быстро для D? Если нет, нам нужен другой дизайн. На каждый из этих вопросов можно дать резкий ответ. Если шипы выглядят хорошо, значит, у нас есть дизайн, и пора его расширить.

Я кодирую так, чтобы как можно скорее получить реальную ценность для потребителя, чтобы покупатель мог сказать мне, куда я должен идти.

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

Назовем это «Экстремальное программирование».

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

Одно из решений - просто очень сильно постараться. Пишите UML везде. Пройдите все занятия. Подумайте, как он будет взаимодействовать с другими вашими классами. Это сложно сделать.

Что мне нравится делать, так это сначала делать общий обзор. Мне не нравится UML, но мне нравится рисовать диаграммы, которые передают суть. Потом приступаю к реализации. Даже когда я просто пишу структуру классов с помощью пустых методов, я часто вижу вещи, которые пропустил ранее, поэтому я обновляю свой дизайн. Когда я кодирую, я понимаю, что мне нужно сделать что-то по-другому, поэтому я обновляю свой дизайн. Это итерационный процесс. Концепция «сначала спроектируйте все, а затем все это реализуйте» известна как модель водопада, и я думаю, что другие показали, что это плохой способ создания программного обеспечения.

Попробуйте Archimate.

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

Некоторое время занимаюсь архитектурой. Я использую BPML сначала для уточнения бизнес-процесса, а затем использую UML для сбора различных деталей! Третий шаг - это вообще ERD! К тому времени, когда вы закончите с BPML и UML, ваш ERD будет достаточно стабильным! Ни один план не идеален, и никакая абстракция не будет стопроцентной. Планируйте рефакторинг, цель - максимально уменьшить рефакторинг!