Рубрика «Анализ и проектирование систем» - 83

Что такое DFDВ комментариях к одной из моих прошлых статей, посвященной IDEF0, один из пользователей высказал просьбу рассказать подробнее о том, что такое DFD. Понятие это несколько запутанное, многие мои клиенты также задают вопросы о потоках данных и стандартах построения диаграмм. А потому я решил эту статью посвятить DFD.

DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия

По моему мнению, определение из русскоязычной Википедии, несколько перегружено информацией и, в результате, излишне сложно для понимания. Кроме того, лично я считаю, что DFD и UML — это разные инструменты, а потому некорректно утверждать, что DFD — это просто предшественник UML.Читать полностью »

Перевод книги Кристиана Посты (Christian Posta) Microservices for Java Developers. A Hands-On Introduction to Frameworks & Containers.

ГЛАВА 1. Микросервисы для Java программистов

Чего Вы можете ожидать от этой книги?

Эта книга ориентирована на программистов и архитекторов Java, интересующихся разработкой микросервисов. Мы начнем книгу с высокоуровнего обзора общих принципов и фундаментальных требований, которые должны быть выполнены для успешной реализации микросервисной архитектуры. К сожалению, простое применение современных технологий не решает магическим образом всех проблем присущих распределенным системам. Мы рассмотрим основных игроков и то, что успешные компании сделали, чтобы микросервисы на них работали, включая культуру, организационную структуру и факторы рынка. Затем мы совершим глубокое погружение в несколько Java-фреймворков, используемых в реализации микросервисов. Репозиторий примеров исходных кодов из данной книги расположен на GitHub. Испачкав руки в коде, мы вернемся на воздух и обсудим проблемы развертывания, кластеризации, отказоустойчивости и то, какие решения предлагают Docker и Kubernetes в этих областях. Затем мы снова вернемся к деталям нескольких практических примеров с применением Docker, Kubernetes и NetflixOSS для демонстрации возможностей, которые они придают облачной микросервисной архитектуре. Закончим мы некоторыми положениями, которые мы не можем раскрыть в такой небольшой книге, но которые от этого не становятся менее важными: конфигурирование, протоколирование и непрерывная поставка (CD).
Читать полностью »

Сегодня в 19:00 по московскому времени в офисе SuperJob состоится IT-meetup «Системный бизнес-анализ». Присоединяйтесь к прямой трансляции!

Читать полностью »

Такты для разработчиков - 1

Если у вас есть опыт создания ПО и вы хотите познакомиться с проектированием цифровых логических схем (digital design), то одна из первых вещей, которые вам нужно понять, — это концепция тактов. Она раздражает многих программных инженеров, начинающих HDL-проектирование. Без использования тактов они могут превратить HDL в язык программирования с $display, if и циклами for, как в любом другом языке. Но при этом такты, которые новички игнорируют, — зачастую один из основополагающих элементов при проектировании любых цифровых логических схем.

Ярче всего эта проблема проявляется именно при рассмотрении первых схем, созданных начинающими HDL-разработчиками. Я недавно общался с некоторыми из них. Новички опубликовали свои вопросы на форумах, которые я читаю. Когда я проанализировал то, что они делают, от увиденного волосы встали дыбом.

Читать полностью »

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

Понятия: множество, тип, атрибут
Как запутать аналитика. Часть первая
Как запутать аналитика. Часть вторая: что такое моделирование предметной области?
Как запутать аналитика. Часть третья. Глаголы и числительные

Вкратце мы затронули жизненный цикл объекта с точки зрения его трансформации и трансформации наших представлений о нем.

Как запутать аналитика — 4. Вероятность и точность

Далее я начал рассмотрение моделирования операций, функций и объектов с единой точки зрения.

Как запутать аналитика — 5. Понятийный аппарат

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

Для создания адаптера нам надо научиться моделировать одно и то же разными способами: как объект и как действие. Для философской мысли это не ново, потому что объекты не существуют вне времени, и действия не могут быть совершены без объектов. Фактически, нам предстоит посмотреть на мир так, как смотрят на него буддисты: объект и действие – одно и то же. Необходимость такого мировоззрения проистекает из необходимости объединения разных точек зрения на одно и то же происходящее. в данной статье я рассмотрю возможные представления реальности и мереологические отношения (отношения часть-целое) между ними.
Читать полностью »

Платформа обмена знаниями и управления авторскими правами. Посмотрим на госзаказ? - 1

Давеча отечественный государственный заказчик разместил интересный заказ. (Документация)

Суть заказа: создание блокчейна и сопутствующей инфраструктуры для управления авторскими правами и обмена знаниями. Под знаниями в данном случае понимаются тексты научных и образовательных материалов, схемы, чертежи, формулы 2D- и 3D-модели и прочий образовательный и научный информационный контент.

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

  • Целесообразность проекта
  • Необходимость в этом проекте технологии типа "блокчейн"
  • Варианты архитектуры и способы реализации проекта
  • Прочие мысли по этому поводу

На чём можно ставить кат, под коим я оставлю некоторые свои мысли и интересные выдержки из текста.

Читать полностью »

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

Сегодня расскажу про понятие нижнего концентрационного предела распространения пламени, попытку сделать датчик вибрации на акселерометре, покажу фотографии с испытаний, ну и чуть-чуть по мелочам… В конце статьи будет видеоролик по теме, с демонстрацией работы прибора стороннего производителя и даже небольшим взрывом банкомата. Прибор-то в итоге получился, но слишком поздно: конкуренты, профессионально работающие в этой области, оказались проворнее и дешевле, да и тенденция взрывов, кажется, идет на спад.
Читать полностью »

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

Определение

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

Пример

Lazy<T> — обертка для объекта, чье создание откладывается до первого обращения к нему.

Антипример

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

Еще антипример

Локатор сервисов — позволяет получить доступ к любому сервису приложения. Это описание без исчерпывающего списка сервисов заведомо неполное.

Назначение

Упрощение создания, анализа и модификации программных систем.

Читать полностью »

В 2016/2017 годах мы обнаружили, что на каждой из наших конференций есть 1-3 доклада о Big Data, нейросетях, искусственном интеллекте или машинном обучении. Стало понятно, что под эту тему можно собрать хорошую конференцию, о чём я сегодня вам и расскажу.

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

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

Учёные строят нейросети в теории, архитекторы делают распределённые системы для корпораций с целью обработки огромных потоков данных в реальном времени, без конечной цели унифицировать к ним доступ, инженеры-практики пишут под это всё софт для сугубо узких задач, которые потом нереально перенести на что-то другое. В общем, каждый копает свою грядку и не лезет к соседу… Так? Да нет же!

На деле: Все занимаются частью общего. Как сама Smart Data (а «умные данные» — это очень узкий перевод) по природе своей, так и те, кто с ней работает, по сути, делают распределённую сеть различных наработок, которые могут создавать порой неожиданные сочетания. Это и формирует фундамент Умных данных в своей красоте и практической значимости.

Итак, что это за кусочки паззла и кто их создает, можно будет посмотреть и даже обсудить с создателями на конференции SmartData 2017 Piter 21 октября 2017. Подробности под катом.

image

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

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

Что я подразумеваю под «сложным»: это несколько сотен бизнес-приложений с довольно внушительной дисперсией атрибутов — технологии, разнородность функциональности, связанность с другим приложениями, критичность, возраст, размер и так далее. Добавьте сюда динамику, поскольку ландшафт неустанно меняют несколько десятков внутренних и внешних команд. Иными словами — самый отпетый, или, на устойчивом жаргоне, «кровавый» энтерпрайз.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js