В некоторых сферах программирования нормально хотеть написать такую структуру данных или алгоритм, которые могут работать с элементами разных типов. Например, список дженериков или алгоритм сортировки, которому нужна только функция сравнения. В разных языках предложены всевозможные способы решения этой задачи: от простого указания программистам на подходящие общие функции (С, Go) до таких мощных систем дженериков, что они стали полными по Тьюрингу (Rust, C++). В этой статье я расскажу о системах дженериков из разных языков и их реализации. Начну с решения задачи в языках без подобной системы (вроде С), а затем покажу, как постепенное добавление расширений приводит к системам из других языков.
Читать полностью »
Рубрика «Анализ и проектирование систем» - 34
Модели дженериков и метапрограммирования: Go, Rust, Swift, D и другие
2019-07-25 в 17:41, admin, рубрики: D, generics, Go, Rust, swift, Анализ и проектирование систем, Блог компании Mail.Ru Group, никто не читает теги, ПрограммированиеБизнес-аналитика. ИТ-объекты, компоненты, инструменты
2019-07-24 в 11:13, admin, рубрики: Анализ и проектирование систем, бизнес-модели, декомпозитор, интерпретатор формул, компаратор, показатель, ряд, симулятор сценариев, сценарийБизнес-аналитика. ИТ-объекты, компоненты, инструменты
Я имел счастье (творчество) и несчастье (признание и внедрение) разрабатывать проект банковской аналитики. Разрабатывать от идеи до реализации и непосредственно участвовать во всех стадиях разработки. Больше всего мне нравилась стадия постановки и проектирования. Превращать хаос представлений в четкую постановку – это немалое удовольствие. Потом трансформировать описательность постановки в конструктивность проекта – это тоже удовольствие. Ну и, кроме того, разрабатывал архитектуру ПО и программировал. В этом тоже находились свои маленькие прелести, хотя на этой стадии каждый программист имел свое мнение и разрулить противоречивости воззрений оказывалось не просто.
Пришлось много прочитать по банковскому делу, по финансовым инструментам, по бухгалтерскому, управленческому и натуральному учету, по хозяйственным операциям… И, конечно, по проектированию и программированию.
Вот и захотелось поделиться своими воззрениями на бизнес-аналитику.
Есть, конечно, еще более важный предмет – бизнес-синтез, имеющий дело с интеграцией данных анализа и принятием решений. “Но это уже совсем другая история”.
Читать полностью »
Модельно ориентированное проектирование. Электропривод с бесколлекторным двигателем постоянного тока
2019-07-22 в 5:14, admin, рубрики: Matlab, SimInTech, Simulink, автоматическое управление, Алгоритмы, Анализ и проектирование систем, генерация кода, математика, математическое моделирование, проектирование, Промышленное программирование, электроприводыВ предыдущей статье про модельно ориентированное проектирование было показано, что не все методики одинаково полезны. И объясняется как делать правильно, что бы не было потом мучительно больно. Но в конце статье был поставлен вопрос, провокационный как Шарон Стоун на допросе у следователей:
Модельно ориентированное проектирование это конечно хорошо, но как доказать, что модель соответствует объекту? Какие ваши доказательства?
Общий ответ на данный вопрос еще готовится, но про частный зато реальный и свежий пример могу привести прямо сейчас. Оказался тут у меня в руках, как всегда случайно, текст от ведущего специалиста нашей страны по электроприводу Калачева Юрия Николаевича, вместе с его любезным согласием на публикацию. Данный текст еще готовится к публикации в специализированных издания, но читатели хабра увидят его первые.
Далее под катом
Калачев Ю. Н., Ланцев В.Ю., Окулов Е.В.
Электропривод с бесколлекторным двигателем постоянного тока
(практика применения моделирования и кодогенерации в АО «Аэроэлектромаш»)
Читать полностью »
Часть 4. Модель вычисления логических функций по графу для асинхронных параллельных процессов
2019-07-21 в 22:50, admin, рубрики: fpga, Анализ и проектирование систем, самосинхронные схемыПерейдем к вычислению логических функций по графу для более широкого класса поведений. Будем рассматривать циклические автономные поведения, не содержащие кратных сигналов (или по другому: не содержащие индексированных событий). Еще одно ограничение: для удобства не будем рассматривать соединение параллельных ветвей по ИЛИ. Рассматриваем только соединение по И, то есть событие инициируется только тогда, когда сработают все его события-предшественники.
Для описания поведения будем использовать STG, но с дополнительными ограничениями. Для каждого плэйса количество входящих в него и выходящих из него дуг равно строго по одной. Соответственно, плэйс с входящей и выходящей дугами можно рассматривать как одну дугу, соединяющую два события (перехода). Соответственно маркировка перемещается по дугам. Так как поведения с кратными сигналами сейчас не рассматриваются, индексы при событиях запрещены, они не нужны. Пустые события запрещены. Также запрещена ситуация, когда две дуги, входящие в одно событие, выходят из событий, которые не параллельны друг другу (частный случай — из одного и того же события). Цель этого — избавиться от дуг, не несущих смысловой нагрузки. В остальном рассматривается корректное (нормальное, живое, безопасное) с точки зрения STG поведение с учетом вышеизложенных ограничений. Поведение не содержит CSC конфликтов.
«Killer apps» для ПК из 80-х: VisiCalc и WordStar
2019-07-18 в 7:12, admin, рубрики: ITGLOBAL.COM, VisiCalc, wordstar, Анализ и проектирование систем, Биографии гиков, Блог компании ITGLOBAL.COM, ПК, СофтКак в 80-х предки Microsoft Office и Google Docs обеспечили популярность ПК, привели к массовым сокращениям штата бухгалтеров и на долгие годы завоевали сердца некоторых писателей.
TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development
2019-07-18 в 6:44, admin, рубрики: bdd, DDD, tdd, Анализ и проектирование систем, ооп, Программирование, Проектирование и рефакторинг, разработка программного обеспечения, Совершенный кодПросматривая статьи по проектированию ПО, я постоянно встречал тучу невиданных сокращений и вскользь упоминаемых практик разработки.
- TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
- BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
- TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
- DDD — bound contexts, ubiquitous language, domain...
- FDD — да сколько можно?
- MDD — cерьезно, на основе диаграмм?
- PDD — ...
Подходы к разработке делятся по сложности, областям применения и целям.
Думаю, настало время разобраться, зачем же они нужны, почему их так много, и как они могут быть нам полезны.
Мы начнем знакомиться с ними от самых простых до довольно сложных, рассмотрим примеры использования и плюсы и минусы каждого из них.
Разбор задач с конференции Hydra — балансировка нагрузки и in-memory хранилища
2019-07-15 в 9:49, admin, рубрики: hydraconf, JUG.ru Group, Алгоритмы, Анализ и проектирование систем, Блог компании Контур, задачи, конференции, распределенные системыНесколько дней назад случилась конференция Hydra. Ребята из JUG.ru Group пригласили спикеров мечты (Лесли Лэмпорт! Клифф Клик! Мартин Клеппманн!) и посвятили два дня распределённым системам и вычислениям. Контур был одним из трёх партнёров конференции. Мы общались на стенде, рассказывали про наши распределённые хранилки, играли в бинго, решали задачки.
Это пост с разбором задач на стенде Контура от автора их текста. Кто был на Гидре — это ваш повод вспомнить приятные впечатления, кто не был — шанс размять мозги big O-нотацией.
Были даже участники, которые разобрали флипчарт на слайды, чтобы записать своё решение. Я не шучу — они сдали на проверку вот такую пачку бумаги:
Всего было три задачи:
- о выборе реплик по весам для балансировки нагрузки
- о сортировке результатов запроса к in-memory базе данных
- о передаче состояния в распределённой системе с кольцевой топологией
ГОСТ Р 57100-2016. Что это было?
2019-07-14 в 18:58, admin, рубрики: ISO/IEC/IEEE 42010:2011, Анализ и проектирование систем, ГОСТ Р 57100-2016, описание архитектуры, системная архитектураВ сентябре 2017 года был введён Национальный стандарт Российской Федерации, получивший обозначение ГОСТ Р 57100-2016 (статус указан здесь: http://www.gostinfo.ru/catalog/Details/?id=6257845, текст можно посмотреть тут: https://standartgost.ru/g/ГОСТ_Р_57100-2016) (я по простоте буду называть его «соткой», осознавая риск быть закиданным помидорами за такую отсебятину). Поскольку теперь приходится сталкиваться с реальными требованиями заказчиков относительно следования этому стандарту даже при описании концепции информационной системы, видимо, настала пора посмотреть на этот стандарт пристальнее.
Пример Model-View-Update архитектуры на F#
2019-07-13 в 12:35, admin, рубрики: .net, elm, Elmish, F#, redux, Анализ и проектирование систем, Проектирование и рефакторингКому-то не нравился Redux в React из-за его имплементации на JS?
Мне он не нравился корявыми switch-case в reducer'ах, есть языки с более удобным pattern matching, и типы лучше моделирующие события и модель. Например, F#.
Эта статья — разъяснение устройства обмена сообщениями в Elmish.
Инженерный подход к разработке ПО
2019-07-11 в 8:20, admin, рубрики: alloy, model-driven engineering, Анализ и проектирование систем, Блог компании Яндекс, Проектирование и рефакторинг, разработка под windows, управление разработкойКак проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?
Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.
Это первая моя статья из цикла, призванного привлечь внимание разработчиков и менеджеров к инженерному подходу к разработке ПО. В последнее время он незаслуженно обойдён вниманием, несмотря на революционные изменения в подходе и инструментах поддержки.
Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.