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

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

Возможно, вам понадобятся диаграммы активности, если в поведении содержится описание parallelism.

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

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

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

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

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

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

Ответ 12

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

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

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

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

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

Ответ 13

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

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

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

Ответ 14

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

Ответ 15

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