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

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

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

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

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

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

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

• - схемы классов, и
• - схемы последовательностей.

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

хороший ресурс для обучения UML-отличная книга Мартина Фаулера "UML Distilled" (Amazon link - санировано для сценария kiddie link nazis out there ( -:). Эта книга дает вам быстрый взгляд на основные части каждого из компонентов UML.

вы определенно должны взглянуть на код Стива Макконнелла полный- и особенно на его бесплатной главе "проектирование в строительстве"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

назовем это "экстремальным программированием".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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