Моделирование событий и операций

Введение


Допустим, что мы наблюдаем процесс точения детали. Зададимся вопросом: кто точит деталь? Ответом может быть: Иванов, токарь, начальник цеха, друг Петрова. Мы можем сказать, что это один и тот же человек, но потом понимаем, что токарь – не человек, а роль, начальник цеха и друг – тоже. Так кто же точит деталь?

Пусть есть событие «яблоко поспело». До этого события яблоко было зеленым, после этого события яблоко стало красным. Вопрос: каким было яблоко в процессе совершения самого события?

В этой статье я отвечу на эти два вопроса с точки зрения проекционного моделирования.

Как я говорил, две проекции на время и на пространство дают представление о моделируемом пространственно-временном объеме. Существует три способа спроецировать 4-Д объем на время:

  1. в виде события (операции),
  2. конечного множества событий (операций) (сценарий),
  3. бесконечного множества событий (операций) (функция).

Читать дальше →

[Из песочницы] Представления знаний в интеллектуальных системах, экспертные системы

Введение


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


Структура экспертной системы


image

Читать дальше →

Пакос делал просто. Понятная статья о консенсусе в распределенной системе

В данной статье мы разберем алгоритм консенсуса Пакос, обсудим зачем он нужен, почему работает, докажем его корректность и немого поговорим о проблемах практического применения. Во многом это вольный пересказ статьи Лесли Лампорта «Paxos Made Simple»

Зачем нужен распределенный консенсус и что это такое



Читать дальше →

On-Premise vs. Cloud IaaS — преимущества и недостатки

Полагаю, что о преимуществах и недостатках Cloud можно найти достаточно много информации. Чаще всего, информация о преимуществах облачных технологий превалирует над информацией об их недостатках.
Читать дальше →

Настройка Azure Application Insights для диагностики ПО с микросервисной архитектурой

Application Insights — клёвая штука, позволяющяя проводить диагностику, профилирование и анализ использования развернутых систем (в т.ч. в продакшен режиме), и при этом не требующая от разработчика вообще никаких усилий. Конечно, всё это становится возможным ценой мучительной первоначальной настройки. В рекламных видео конечно никакой особой настройки нет, но жизнь — она сложнее, особенно если ваше ПО микросервисное. Почему? А всё очень просто. Что в первую очередь должна делать система диагностики в микросервисной архитектуре? Правильно, коррелировать диагностику от различных микросервисов в рамках одной операции. Тыркнул пользователь в UI кнопочку — надо увидеть диагностику от всех N микросервисов, которые так или иначе обрабатывали этот тырк. Случился где-нибудь exception — надо увидеть не только в каком микросервисе он произошёл, но и в рамках какой операции это случилось. Только вот Application Insights с точки зрения конкретного микросервиса — это в первую очередь SDK. И SDK таких есть несколько — есть для JS, есть для .NET Core, .NET (со своими особенностями настройки для MVC, WebAPI, WCF), есть для Java и т.д. Какие-то из этих SDK — opensource, какие-то — внутренняя разработка MS. И чтобы всё завелось — их надо подружить. В этом и состоит основная сложность.

Не скажу, что я достиг 100% просветления в этом вопросе. Но по крайней мере, я уже собрал несколько граблей и у меня есть рабочий семпл с UI на ASP.NET MVC (не Core) + JS и двумя микросервисами (Asp.Net WebApi, WCF)

...Далее...

Разработчики Гугл о процессе разработки fault-tolerant програмного обеспечиния

Наткнулся на замечательную статью «Paxos Made Live — An Engineering Perspective» рассказывающую о реализации инженерами Гугл алгоритма распределеннго консенсуса Пакос в проекте Chubby (аналог Zookeeper). В статье разбираются большинсво вопросов возникающих у прикладного программиста после озкакомления с алгоритмом. Помимо прочего интересного, в разделе «Unexpected failures» упоминается об одном рабочем эпизоде, который многим из нас покажется чем-то знакомым: Читать дальше →

Моделирование бизнес-функций

Введение

Три проекции одного объекта на три разных плоскости – это не объект. Это его чертеж. Все три проекции позволяют инженеру представить деталь. Для этого надо соотнести точки на чертеже с точками в пространстве. Этому навыку способствует обучение начертательной геометрии. Ровно то же можно сказать про проекционное моделирование. Только обе проекции на пространство и на время позволяют представить то, что хотел сказать модельер. Для этого надо научиться корректно моделировать 4-Д пространство-время, а затем корректно соотносить эти проекции друг с другом. В данной статье я приведу практический пример такого рода моделирования. Для кого-то это будет достаточно непривычно. Кому-то, наоборот, покажется все слишком очевидным.

Моделирование партий товара

Начнем с моделирования привычного нам объекта — попробуем смоделировать лес. Есть 4-Д объем, который Иванов трактует как объект типа лес. Для моделирования этого факта создается информационный объект (ИО), моделирующий этот 4-Д объем. Далее создается ИО, моделирующий представление Иванова об этом 4-Д объеме. Этот объект связан с моделью 4-Д объема связью «что представляет», с моделью Иванова «кто представляет» и с моделью типа объектов – лес «как представляет». Читать дальше →...Далее...

Принцип Анны Карениной в программировании и ИТ


«Принципу Анны Карениной» посвящено немало научных публикаций и даже отдельная статья в Википедии. Применим к ИТ и программированию? А может он уже работает против вашего проекта? Читать дальше →

Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие

Продолжаем популяризацию направления «Архитектура предприятия» и робкие попытки очищения его от алхимии и наукообразия. Начало: «Enterprise Architecture vs алхимия предприятия. Ключевые мифы» Наш подход к изучению — классический: от простого к сложному. Начинаем с самого простого: самого простого фреймворка – таблички Джона Захмана и самого простого предприятия – домохозяйства. Проще некуда. Соответственно, на выходе должна получиться самая простая «Архитектура предприятия». Не так ли? Напоминаю, что главная проблема Enterprise Architecture (ЕА) – это отсутствие конкретных примеров этой самой ЕА в открытом доступе. Алхимики их хранят «как зеницу ока», видимо потому, что если их публиковать, то откроется страшный секрет «платья короля» и все скажут: А король то голый! В первой статье мы проговорили правила участия в «Конкурсе на описание «household architecture» (см. раздел №3). Конкурс задуман как практический шаг к формированию научного архитектурного подхода (архитектурика) к описанию предприятия типа «домохозяйство», т.е. «household architecture» (НА). На мой взгляд, подобная тема – отразить собственную НА по какому-либо существующему «классическому» фреймворку или оригинальной методе описания ЕА, — прекрасная тема как для дипломных работ по специализации Enterprise Architecture специальности «Бизнес-информатика», так и возможность практикующим консультантам показать, насколько они знают толк в консалтинге ЕА. Надеюсь, что URL ссылка на свою НА (или эталонную) станет обязательным реквизитом квалификационной работы и визитки консалтера по данному направлению. ...Далее...

Эмпатическое картирование: когда и как им пользоваться?

Я перевел свежую статью на IDF, авторов Рикке Дама и Тео Сяна. Статья содержит инструментальную полезную и простую методику перехода от наблюдений за пользователем к определению его потребностей при разработке вашей услуги или продукта. image А вы знаете, что пользователи скорее выберут, купят и будут использовать продукты, которые просто отвечают их пожеланиям и потребностям? Эмпатическое картирование помогает понять потребности пользователя, пока вы занимаетесь медитацией над пониманием для кого же все таки вы делаете дизайн продукта? Есть много разных техник, чтобы развить этот способ эмпатии. Эмпатическое картирование одна из таких техник, которая помогает прочувствовать и собрать воедино ваши наблюдения на стадии исследований и выразить неожиданные озарения по поводу потребностей пользователей вашего продукта. Эмпатическое картирование позволяет обобщить изученное в результате встреч с людьми во время исследовательской стадии дизайна. Подобная карта показывает четыре основных области, на которых нужно сосредоточить внимание, таким образом обеспечив обзор опыта пользователя (того самого UX, *прим. перев.). Эмпатические карты это отличный инструмент для создания идеализированных портретов пользователей, которые потом тоже лучше сделать. ...Далее...


Последние посты