MetaProg

[dyvniy]

Лукоморье, маты, но столько мыслей!
https://lurkmore.co/Копипаста:Программирование#mws_W9I6veV

[dyvniy]

IDE web, android
https://www.sourcelair.com/home

[dyvniy]

Чистая архитектура
http://habrahabr.ru/post/269589/

Спойлер

За последние несколько лет мы видели целый ряд идей относительно архитектуры систем. Каждая из них на выходе давала:

Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.


Диаграмма в начале этой статьи — попытка объединить все эти идеи в единую эффективную схему.

Правило Зависимостей

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

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

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

Сущности

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

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

Сценарии

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

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

Мы, однако, ожидаем, что изменения в работе приложения повлияет на Cценарии. Если будут какие-либо изменения в поведении приложения, то они несомненно затронут код в данном слое.

Интерфейс-Адаптеры

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

Точно так же, данные преобразуются, в этом слое, из формы наиболее удобным для Сценариев и Сущностей, в форму, наиболее удобной для постоянного хранения, например в базе данных. Код, находящийся внутри этого круга не должен знать что-либо о БД. Если БД — это SQL база данных, то любые SQL-инструкции не должны быть использованы на этом уровне.

Фреймворки и драйверы.

Наружный слой обычно состоит из фреймворков, БД, UI и т.д. Как правило, в этом слое не пишется много кода, за исключением кода, который общается с внутренними кругами.

Это слой скопления деталей. Интернет — деталь, БД — деталь, мы держим эти штуки снаружи для уменьшения их влияния.

Только четыре круга?

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

Пересечение границ.

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

Обычно мы решаем это кажущееся противоречие с помощью Принципа Инверсии Зависимостей.

Например, предположим, что из Сценария нужно обратиться к Представлению. Однако, этот вызов обязан быть не прямым, чтобы не нарушать Правило Зависимостей — внутренний круг не знает ничего о внешнем. Таким образом Сценарий вызывает интерфейс (на схеме показан как Выходной Порт) во внутреннем круге, а Представление из внешнего круга реализует его.

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

Как данные пересекает границы.

Обычно данные, которые пересекают границы — это просто структуры данных. Вы можете использовать базовые структуры или, если хотите, Data Transfer Objects (DTO — один из шаблонов проектирования, используется для передачи данных между подсистемами приложения). Или данные могут быть просто аргументами вызова функций. Или вы можете упаковать его в хэш-таблицу или в объект. Важно, чтобы передаваемые структуры данных были изолированными при передаче через границы. Мы не хотим жульничать и передавать Сущность или строки БД. Мы не хотим, чтобы структуры данных имели какие-либо зависимости, нарушающие Правило Зависимостей.

Например, многие фреймворки (ORM) в ответ на запрос к БД возвращают данные в удобном формате. Мы могли бы назвать это RowStructure. Мы не хотим передавать эту структуру через границу. Это было бы нарушением Правила Зависимостей поскольку в этом случае внутренний круг получает информацию о внешнем круге.

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

Заключение

Следовать этим простым правилам не трудно и они сохранят вам много времени в будущем. Разделяя ПО на слои и следуя Правилу Зависимостей вы будете создавать систему тестируемой, со всеми вытекающими преимуществами. Когда любая из внешних подсистем устареет, будь то БД или веб-фреймворк, вы легко сможете заменить их.

P.S. Данная статья переведена как подготовка к более поздней и чуть более практически ориентированной статье о чистой архитектуре на Go. Интересно?
uncle bob, чистая архитектура, архитектура по
—

4622

85


@trong карма3,0 рейтинг5,6
Похожие публикации

Гексагональная архитектура (9)
Аккордеон про архитектуру и локализацию (3)
Экосистема российского ПО. Термины и классификация (6)
Экосистема российского ПО. Вступление (132)
Шпаргалка по шаблонам проектирования (59)
Комментарии (3)

+1 andrewnester27 октября 2015 в 10:09#
Вашему предложению написать статью про чистую архитектуру для приложений на Go однозначно да, было бы лично мне интересно
0 nelson27 октября 2015 в 13:31#
Очень интересует данная тема.
Никак не могу сообразить, как решить одну задачку в рамках правильной архитектуры. Есть допустим в проекте пользователи и две такие сущности: «Друзья пользователя» и «Кто онлайн». Отдельно работают замечательно, ничего друг про друга не знают. Хранятся и те и другие данные в mysql. Но если надо вывести тех друзей, которые сейчас онлайн — самое простое и быстрое решение это сделать выборку по двум таблицам (friends join users_online). Но её сделать нельзя, ибо «Друзья» ничего не знают про формат хранения онлайн-юзеров, онлайн-юзеры не знают про формат хранения друзей, а все остальные не знают ни того ни другого. Как быть?
0 FractalizeR27 октября 2015 в 14:32#↵↑
Разве «друзья пользователя» — это сущность? По-моему, это коллекция объектов «Пользователь». Как и «Кто онлайн», кстати. Даже если у вас друзья имеют какие-то дополнительные атрибуты, это все равно только характеристика связи. Или нет?

[dyvniy]

Visual Paradigm for UML
http://analyst.by/articles/vpforuml8
говорят хорошая прога для моделирования взаимодействия классов.

Спойлер

Чуть более месяца назад (16 августа 2010 года) компания Visual Paradigm представила новую версию своего «флагманского» продукта – Visual Paradigm Suite 5.0 (VP Suite 5.0). Visual Paradigm Suite — это набор средств для моделирования информационных систем и бизнес-процессов, генерации кода на базе построенных моделей, проектирования БД и решения многих других задач.
В пакет Visual Paradigm Suite 5.0 входят следующие инструменты:
• Visual Paradigm for UML 8.0
• Business Process Visual Architect 4.0
• Visual Paradigm SDE
• Agilian 3.0
• Database Visual Architect 6.0
В данном обзоре мы остановимся на наиболее интересном из перечисленных выше инструментов – Visual Paradigm for UML 8.0 (VP for UML). Об остальных продуктах компании Visual Paradigm можно подробнее узнать на официальном сайте компании – http://www.visual-paradigm.com/
Что же представляет собой VP for UML?
VPUMLlogVP for UML – это система управления требованиями, поддерживающая полный цикл разработки программного продукта – анализ, дизайн архитектуры, разработка программного кода, тестирование и размещение продукта на стороне заказчика. VP также обеспечивает поддержку версионности и одновременной работы команды пользователей над одним проектом.
В целом, VP for UML является прямым конкурентом небезызвестного Enterprise Architect от компании Sparx Systems.
VP for UML предоставляет широкие возможности для создания и организации требований. Для создания моделей аналитик в рамках одного проекта может описывать требования, одновременно используя такие стандарты и нотации моделирования, как UML, BMPN, OMG, Mind Maps и ArchiMate (стандарт моделирования структуры и процессов предприятия - http://www.archimate.org/). Это является большим плюсом, так как, используя VP for UML, не нужно переключаться между большим количеством программ для создания моделей в различных нотациях, а описание требований различными методами и нотациями должно лишь облегчить понимание проекта.
Перейдем непосредственно к функциональным возможностям системы.
1. Построение диаграмм
Моделирование диаграмм реализовано на довольно высоком уровне, и все элементы интуитивно находятся под рукой. Имеется панель инструментов, на которой располагаются элементы для выбранного типа диаграммы (Use Case, Activity, Mind Map и т.д.). Добавление новых элементов можно осуществлять из «всплывающего» меню, которое становится доступным при выборе любого элемента, уже добавленного на диаграмму, что значительно сокращает время, затрачиваемое на создание диаграммы.
UseCase










Также отметим две дополнительных функции, которых не хватает в большинстве других системах для Use Case моделирования – Magnet и Sweeper.
Sweeper
Sweeper раздвигает элементы, создавая тем самым больше рабочего пространства для добавления новых элементов на диаграмму. Magnet позволяет сократить пространство между элементами диаграммы, что является весьма удобным при экспорте диаграммы в текстовый документ.
Добавление спецификации к элементам диаграммы существенно напоминает Enterprise Architect, правда у актеров, выполняющих действие, отсутствует разделение по типам (Actor, System).
USDescr



2. Текстовый анализ
Один из видов поддерживаемых диаграмм — «Текстовый анализ». В режиме текстового анализа предполагается ввод User Stories в определенную область программы, после чего пользователь имеет возможность добавления различных элементов диаграммы путем выделения соответствующего слова/фразы из User Story и определения типа элемента (Use Case, Class, Activity, User и т.д.).
UserStiry



После добавления информации в режиме текстового анализа все элементы доступны для добавления в диаграммы любого другого вида при условии, что добавление этих элементов не противоречит нотации. Чтобы просмотреть элементы, определенные в режиме текстового анализа, необходимо нажать иконку «Model Explorer» в браузере проекта.
3. Моделирование бизнес процессов с помощью BPMN
В VP for UML предусмотрена возможность построения диаграмм с помощью нотации BPMN. В целом, построение BPD (Business Process Diagram) ничем не отличается от построения UML-диаграмм. Следует отметить приятное оформление самой нотации:
VPBPMN


Также следует выделить возможность генерации кода из BPD в следующие языки определения и исполнения бизнес-процессов:
• BPEL – Business Process Execution Language
• WSDL – Web Services Description Language
• XPDL – XML Process Definition Language
• JPDL – jBPM Process Definition Language
4. Пользовательский интерфейс
Для тех, кто знаком с предыдущими версиями VP for UML, станет заметно упрощение интерфейса путем добавления элемента «Ribbon» в верхней части экрана, который предоставляет быстрый доступ к созданию новыx диаграмм и простейшим операциям над ними.
Ribbon


Также в новой версии добавлена возможность выбора шрифта в самом приложении.
В целом, интерфейс VP for UML не вызывает путаницы и недопонимания. Единственным потенциальным минусом (а возможно и плюсом) является огромное количество настроек для каждого элемента диаграммы и приложения в целом – поначалу в них довольно просто запутаться.
5. Командная работа
VP for UML предоставляет широкие возможности для совместной работы пользователей над одним проектом. При этом используются различные «ветки», изменения в которых впоследствии объединяются в главной «ветви» — «trunk». VP for UML позволяет различным членам команды работать над одной диаграммой и сравнивать изменения, внесенные пользователями на разных этапах проекта. При обнаружении конфликта (например, если два пользователя сделают изменения в одной и той же диаграмме, которые будут конфликтовать между собой) программа покажет соответствующее сообщение и не даст внести изменения до тех пор, пока конфликт не будет разрешен.
При совместной работе имеется возможность определения различных ролей на проекте и их прав доступа к проекту. Также можно ограничить доступ к определенным диаграммам путем задания пароля.
Еще одним важным моментом является возможность создание «тэгов» — «снэпшотов» системы. При создании «тэга» фактически создается копия проекта, в которую нельзя вносить изменения. Эта функциональность может быть полезна для проведения «sign-off» с клиентами и для определения объемов работ для каждого конкретного релиза.
Поддерживаются следующие режимы совместной работы:
• VP Teamwork Server
• Subversion (SVN)
• Perforce
• CVS
6. Генерация отчетов
Генерация отчетов возможна в форматах PDF, HTML и MS Word, с возможностью публикации отчетов на сервере.
Генерируемые отчеты получаются довольно громоздкими, так как VP for UML добавляет спецификацию для каждого элемента диаграммы. В итоге у нас получился отчет размером в более чем 400 страниц, хотя моделей и диаграмм в проекте было порядка 20. Возможно, существует функциональность по заданию глубины отчета, при которой не будут описываться все элементы проекта, но нам этой опции найти не удалось.
7. Impact Analysis (анализ воздействий)
Impact Analysis подразумевает то, что вы можете оценить последствия изменений, вносимых в уже созданные модели. Делается данный анализ при помощи построения «матрицы связей», которая отображает связи между выбранными элементами.
На примере ниже представлены матрицы со следующими связями: Use Cases со связью типа «Includes», Use Cases и Actors со связью типа «Association» и Classes со связью «Association»:
IMpact


8. Animatian and Simulatian
Отдельно хотелось бы выделить функции “Animatian” и “Simulatian”, предназначенные для моделирования и симулирования процессов.
Animatian позволяет «пробежаться» по одному из выбранных потоков диаграммы. Результат можно экспортировать в формат FLV и демонстрировать заказчикам или членам проектной команды.
Также при помощи данного функционала можно выявить неверные потоки и внести соответствующие изменения, что может в итоге сохранить большое количество времени при проектировании.
Animatian

Simulatian – еще более интересная опция, с помощью которой можно моделировать бизнес-процессы и наблюдать за их течением.
К примеру, известно, что работу А выполняют два человека за 3 часа, после чего задача/предмет, над которым происходит действие, переходит к другому специалисту, которому необходимо 20 минут для выполнения работы над некой сущностью. Весь этот процесс можно смоделировать, указав количество сущностей над которыми необходимо проделать действия и количество ресурсов, выполняющих действия над сущностями. Таким образом, можно смоделировать выполнения процесса в реальном времени и выявить его недостатки.
Simulation


В дополнение к описанному выше, далее приведен сравнительный анализ менее существенных положительных и отрицательных сторон VP for UML:
Понравилось:
- Для каждого элемента диаграммы можно записать аудиофайл в дополнение к документации.
- Visual Paradigm Suite разработан на Java и является кросс-платформенной системой.
- Большое количество обучающих материалов на сайте компании и возможность записаться на платные семинары.
- Наличие глоссария и постоянно-работающей проверки орфографии.
- Возможность проектирования баз данных, генерации кода запросов и хранимых процедур.
Не понравилось:
- Для Visual Paradigm Suite существует целый набор различных лицензий и, для того, чтобы определиться, какая конкретно подойдет Вам, придется внимательно прочитать 20 страниц текста.
- Отсутствие возможности открыть проект, созданный в более новой версии, даже если обновление системы произошло с версии 4.1 до 4.2 и никаких принципиальных изменений между версиями не наблюдается.
- Экспорт диаграммы в изображение по необъяснимым причинам потребляет огромное количество ресурсов системы.
- При передвижении элементов в BPD-диаграммах наблюдалась задержка между реальным движением мыши и смещением элемента диаграммы.

Вердикт:
Visual Paradigm Suite 5.0 – достаточно неплохой продукт для управления требованиями и построения визуальных моделей, способный составить конкуренцию даже самым передовым и популярным инструментам для UML-моделирования.
Оценка по пятибалльной шкале: 4.5

http://rutracker.org/forum/viewtopic.php?t=2980896

[dyvniy]

O(x)
Constand difference
http://stackoverflow.com/questions/20512642/big-o-confusion-log2n-vs-log3n

Спойлер

Big O confusion: log2(n) vs log3(n)

up vote
8
down vote
favorite
2
why is the statement true : Log2(n) is O(log3(n))

I don't understand this, does big O not mean upper bond of something?.

Isn't log2(n) bigger than log3(n) ? When I graph them, log2(n) is above log3(n)

algorithm math big-o logarithm
shareimprove this question
edited Jan 28 at 0:51

templatetypedef
184k41462705
asked Dec 11 '13 at 7:03

Daver Muzaffar
103110

Hint: Try converting to base 3, and remember that constants don't matter. – msgambel Dec 11 '13 at 7:06
add a comment
4 Answers
active oldest votes
up vote
14
down vote
accepted
Big O doesn't deal with constant factors, and the difference between Logx(n) and Logy(n) is a constant factor.

To put it a little differently, the base of the logarithm basically just modifies the slope of a line/curve on the graph. Big-O isn't concerned with the slope of the curve on the graph, only with the shape of the curve. If you can get one curve to match another by shifting its slope up or down, then as far as Big-O notation cares, they're the same function and the same curve.

To try to put this in perspective, perhaps a drawing of some of the more common curve shapes would be useful:

enter image description here

As noted above, only the shape of a line matters though, not its slope. In the following figure:

enter image description here

...all the lines are straight, so even though their slopes differ radically, they're still all identical as far as big-O cares--they're all just O(N), regardless of the slope. With logarithms, we get roughly the same effect--each line will be curved like the O(log N) line in the previous picture, but changing the base of the logarithm will rotate that curve around the origin so you'll (again) have he same shape of line, but at different slopes (so, again, as far as big-O cares, they're all identical). So, getting to the original question, if we change bases of logarithms, we get curves that look something like this:

enter image description here

Here it may be a little less obvious that all that's happening is a constant change in the slope, but that's exactly the difference here, just like with the straight lines above.

shareimprove this answer
edited Jan 28 at 0:45
answered Dec 11 '13 at 7:08

Jerry Coffin
304k28324699
2
Thanks got it now – Daver Muzaffar Dec 11 '13 at 7:12

I would also note that it's not just shifting that doesn't matter, as we disregard multiplication by constants as well. f is O(n) whether f = n or f = 2n, even though 2n is not a shift upwards of n. In fact, I'd say that disregarding constant factors is a more important feature of big O. – Sean Dec 11 '13 at 18:02

@Sean: Good point. Reworded to be more accurate. Thanks. – Jerry Coffin Dec 11 '13 at 18:06

[dyvniy]

sysinternals
https://technet.microsoft.com/en-us/sysinternals/bb963901.aspx

\accepteula - чтоб не вылезало окно с лицензией
https://stackoverflow.com/questions/5151034/psexe ... when-running-non-interactively