#систематика #инфоарх /// Архитектура
Архитектура описывает систему в части самых важных решений:
- Какие модули за какие функции будут отвечать.
- Какими интерфейсами будут связаны эти модули.
- Как и чем будут обмениваться эти модули через интерфесы — какие сервисы будут "течь" через порты, воплощенные интерфейсами.
Можно сказать, что модули есть существительные, а функции (выполняемые модулями) есть глаголы, так как функции есть действия, дающие на выходе результат и как следствие сервис.
Архитектура — это всегда прозрачный ящик!
Необходимо следить за связностью модулей — чем меньше связей, интерфейсов, тем меньше шансов на неотслежываемые соеднения (они — источник ошибок) и тем проще управлять модулями в составе системы.
Архитектура есть всё самое важное про функции, всё самое важное про модули и всё самое важное про размещение, а также всё самое важное в других рассмотрениях системы.
Архитектура может быть и у процесса, а следовательно — архитектура может быть у проекта.
____
#архитектура #интерфейс #модуль #прозрачный_ящик #проект
Архитектура описывает систему в части самых важных решений:
- Какие модули за какие функции будут отвечать.
- Какими интерфейсами будут связаны эти модули.
- Как и чем будут обмениваться эти модули через интерфесы — какие сервисы будут "течь" через порты, воплощенные интерфейсами.
Можно сказать, что модули есть существительные, а функции (выполняемые модулями) есть глаголы, так как функции есть действия, дающие на выходе результат и как следствие сервис.
Архитектура — это всегда прозрачный ящик!
Необходимо следить за связностью модулей — чем меньше связей, интерфейсов, тем меньше шансов на неотслежываемые соеднения (они — источник ошибок) и тем проще управлять модулями в составе системы.
Архитектура есть всё самое важное про функции, всё самое важное про модули и всё самое важное про размещение, а также всё самое важное в других рассмотрениях системы.
Архитектура может быть и у процесса, а следовательно — архитектура может быть у проекта.
____
#архитектура #интерфейс #модуль #прозрачный_ящик #проект
#систематика /// Описание системы, разбиения
Описание — это то, как мы говорим о системе. Описание необходимо для обсуждения будущей системы, чтобы обсуждать модели-описания и договариваться для достижения непротиворечий.
Описание делается через рассмотрения, а их три основных:
- функциональное — по роли/функции: что части делают для реализации эмержентности / сервиса – это описание чёрного ящика – аналитиеская работа.
- модульное / конструктивное — по частям: из каких частей состоит система – это описание прозрачного ящика! – синтетическая работа.
- пространственное — по размещению в пространстве-времени: где-когда части физически находятся – тоже описание прозрачного ящика.
(вот эти три первых — это костяк архитектуры системы)
и множество дополнительных:
- финансы
- право
- этика
- етс
Важно: функциональное разбиения принято считать самым важным, и его можно назвать системным разбиением. Возникающий парадокс между системным разбиением по функциям и системным разбиением по часть-целое убирается с помощью трассировки функций к частям. Сделав такую трассировку вявляются уровни разбиения функционального и модульного, которые скорее всего не будут совпадать, и это нормально. Разбиения, как физические, так и функциональные, делаются вниманием.
Системы описываются частично в будущем — когда они воплощены / run-time. То есть описываются воплощения систем, всё остальное по сути и есть описание / design-time: от идеи - через описание - к воплощению. Поэтому в описаниях часто что-то отсутствует, так как это ещё не случилось, это в будущем, это ещё не выявлено.
Описываются требования и архитектура; они всегда есть, но могут быть еще не описаны и/или не выявлены.
Описание проявляется только в виде документации, то есть записанное, задокументированное на каком-то физическом носителе.
Каждая проектная роль делает своё описание системы — ролевое описание системы (viewpoint).
Система, пока она не воплощена, имеет лишь описание. Как только система выделена вниманием, то есть кто-то о ней думает, то эта система (она может ещё только появиться в будущем) имеет описание, то есть образ того, как она работает в виде воплощения. То есть описание системы возникает до воплощения. Чтобы работать над системаой, воплощать её, необходимо задокументировать описание. Исключение — когда система создаётся НЕ коллективно, и описание системы достаточно для одного человека, который мыслит и воплощает систему.
____
#описание #функция #модуль #размещение #трассировка #эмерджентность
Описание — это то, как мы говорим о системе. Описание необходимо для обсуждения будущей системы, чтобы обсуждать модели-описания и договариваться для достижения непротиворечий.
Описание делается через рассмотрения, а их три основных:
- функциональное — по роли/функции: что части делают для реализации эмержентности / сервиса – это описание чёрного ящика – аналитиеская работа.
- модульное / конструктивное — по частям: из каких частей состоит система – это описание прозрачного ящика! – синтетическая работа.
- пространственное — по размещению в пространстве-времени: где-когда части физически находятся – тоже описание прозрачного ящика.
(вот эти три первых — это костяк архитектуры системы)
и множество дополнительных:
- финансы
- право
- этика
- етс
Важно: функциональное разбиения принято считать самым важным, и его можно назвать системным разбиением. Возникающий парадокс между системным разбиением по функциям и системным разбиением по часть-целое убирается с помощью трассировки функций к частям. Сделав такую трассировку вявляются уровни разбиения функционального и модульного, которые скорее всего не будут совпадать, и это нормально. Разбиения, как физические, так и функциональные, делаются вниманием.
Системы описываются частично в будущем — когда они воплощены / run-time. То есть описываются воплощения систем, всё остальное по сути и есть описание / design-time: от идеи - через описание - к воплощению. Поэтому в описаниях часто что-то отсутствует, так как это ещё не случилось, это в будущем, это ещё не выявлено.
Описываются требования и архитектура; они всегда есть, но могут быть еще не описаны и/или не выявлены.
Описание проявляется только в виде документации, то есть записанное, задокументированное на каком-то физическом носителе.
Каждая проектная роль делает своё описание системы — ролевое описание системы (viewpoint).
Система, пока она не воплощена, имеет лишь описание. Как только система выделена вниманием, то есть кто-то о ней думает, то эта система (она может ещё только появиться в будущем) имеет описание, то есть образ того, как она работает в виде воплощения. То есть описание системы возникает до воплощения. Чтобы работать над системаой, воплощать её, необходимо задокументировать описание. Исключение — когда система создаётся НЕ коллективно, и описание системы достаточно для одного человека, который мыслит и воплощает систему.
____
#описание #функция #модуль #размещение #трассировка #эмерджентность
#систематика /// Порт, интерфейс, соединение
Порт — это канал обмена функциональностью между функциональными частями в системе. Также сама система имеет порт, через который она отдаёт свой сервис наружу в надсистему. Порты не имеют физического воплощения, физически порты воплощены модулями.
Интерфейс — это обмен между модулями. Сам по себе интерфейс не имеет физического воплощения, он воплощается через интерфейсные модули. При этом интерфейсный модуль имеет не один интерфейс: помимо целевого интерфейса для подключения надмодуля (частью которого является интерфейсный модуль) к другому надмодулю есть также интерфейс между интерфейсным модулем и смежным модулем в рамках системы.
Интерфейс и модули ничего не знают про то, что именно они будут передавать: потоки каких сервисов и данных они будут обеспечивать.
Соединения — это физические соединения между модулями при размещении. Например, винтовое крепление, или физическая сцепка USB-модулей.
Когда рассматриваются два (или более) модуля, которые взаимодействуют между собой, необходимо сразу же рассматривать их интерфейсы — то есть каким образом модули будут взаимодействовать между собой, как физически будут осуществлён обмен между портами.
Есть несколько вариантов связи модулей между собой:
- унификация — использование общих стандартов в индустрии/отрасли (220 вольт, USB, XML, 2НДФЛ) — просто и дешево, лучший вариант.
- интеграция — разработка этих модулей с учетом того как они будут связаны, то есть проектирование модулей и их интерфейсов для взаимодействия — редкий кейс, дорого, сложно, "закрытая" разработка.
- федерирование — применение "прослоек" и адаптеров в случае отсутствия стандартов, несовпадения интерфейсов — довольно частый случай
Когда реализуют стандарт интерфейса и портов, содержащих / предоставляющих / воплощающих этот интерфейс — этого стандарта стоит придерживаться маскимально строго и полно (в отличие от стандарта практики, при реализации которого стоит брать только самое необходимое).
____
#порт #интерфейс #соединение #унификаци #федерирование #интеграция #модуль
Порт — это канал обмена функциональностью между функциональными частями в системе. Также сама система имеет порт, через который она отдаёт свой сервис наружу в надсистему. Порты не имеют физического воплощения, физически порты воплощены модулями.
Интерфейс — это обмен между модулями. Сам по себе интерфейс не имеет физического воплощения, он воплощается через интерфейсные модули. При этом интерфейсный модуль имеет не один интерфейс: помимо целевого интерфейса для подключения надмодуля (частью которого является интерфейсный модуль) к другому надмодулю есть также интерфейс между интерфейсным модулем и смежным модулем в рамках системы.
Интерфейс и модули ничего не знают про то, что именно они будут передавать: потоки каких сервисов и данных они будут обеспечивать.
Соединения — это физические соединения между модулями при размещении. Например, винтовое крепление, или физическая сцепка USB-модулей.
Когда рассматриваются два (или более) модуля, которые взаимодействуют между собой, необходимо сразу же рассматривать их интерфейсы — то есть каким образом модули будут взаимодействовать между собой, как физически будут осуществлён обмен между портами.
Есть несколько вариантов связи модулей между собой:
- унификация — использование общих стандартов в индустрии/отрасли (220 вольт, USB, XML, 2НДФЛ) — просто и дешево, лучший вариант.
- интеграция — разработка этих модулей с учетом того как они будут связаны, то есть проектирование модулей и их интерфейсов для взаимодействия — редкий кейс, дорого, сложно, "закрытая" разработка.
- федерирование — применение "прослоек" и адаптеров в случае отсутствия стандартов, несовпадения интерфейсов — довольно частый случай
Когда реализуют стандарт интерфейса и портов, содержащих / предоставляющих / воплощающих этот интерфейс — этого стандарта стоит придерживаться маскимально строго и полно (в отличие от стандарта практики, при реализации которого стоит брать только самое необходимое).
____
#порт #интерфейс #соединение #унификаци #федерирование #интеграция #модуль
#дизайн /// UX-марафон 26-5 — Проектирование сложных систем
Объектно-ориентированный UX
Алексей Сорокин, Мой склад
(Метод, применяемый для проектирования сложных продуктов и систем, основанный на ОО-практиках)
1. Есть дизайн “по-быстрому” — понять задачу > применить интуицию, опыт, здравый смысл, насмотренность > макет/гипотеза
2. Во втором шаге происходит “магия”
3. При применении JTBD, CJM, etc — задача уточняется, но “магия” остается
4. Статистика с прода, тестирования, etc — это все равно обвес вокруг “магии”, лишь уточняющий данные на вход
5. Макет/гипотеза — подчиняется циклу гипотеза > эксперимент > сбор данных > анализ и вывод; цикл стоит денег
6. Чем точнее гипотеза, тем меньше циклов
7. Сложный продукт — где много сценариев; аналогия: сам интернет-магазин это поезд, он едет по рельсам, а админка интернет-магазина это самолет, он летает как хочет
8. В сложном продукте тем более цикл выглядит так: гипотеза > эксперимент > сбор данных > “магия”
9. “Попробуем без сценариев” (без сценариев? Интересно как это…)
10. Три вопроса про пользователя: каков его опыт? в каком состоянии/контексте пользователь? использует систему чтобы что?
⁃ На первые два вопроса отвечает метод персон, на третий отвечает jtbd
⁃ Задачи в персонах — это job в jtbd
11. Пользователь работает с объектами; работа = действие + объект + контекст
12. Далее про связь объектов и их обозначений
13. Объект в системе: у него есть свойства, методы, представления
⁃ Свойства — атрибуты объекта, то, как его можно охарактеризовать
⁃ Методы — действия, которые можно сделать с объектом
⁃ Представления объекта — проекция объекта из ментальной модели пользователя на интерфейс; полное представление есть перечисление всех его свойств и методов; например, в навигации используются краткие представления объектов
14. Принципы работы с представлениями:
⁃ Нужно полное представление объекта — вся информация для создания проекций; пример: карточка объекта
⁃ Нужен полный набор допустимых действий над объектом
⁃ Нужно дать пользователю контроль над “его” объектами
⁃ Если связь между объектами есть, то ее необходимо показать в интерфейсе
15. Далее про сценарии:
⁃ На основе сценариев выбираем представления объектов в контекстах
⁃ Также на основе сценариев строим порядок представления объектов
⁃ На основе сценариев понимаем необходимый набор представлений
⁃ И также на основе сценариев …не успел записать…
16. Для работы с объектами помогает ER-диаграмма, отражающая набор объектов, их свойства и методы, и связи объектов
17. Заключение — что дает OOUX:
⁃ Доп. инструмент проектирования
⁃ Меньше “магии” и больше аргументировать
⁃ “Меньше интуиции, больше логики”
⁃ Можно не держать в голове сложные объекты
Доклад на важную тему — о том как превратить интуицию и “магию” проектирования в объясняемые паттерны.
Что хорошо — доклад вызывает интерес к моделированию на концептуальном уровне.
Что плохо — не звучало убедительно: да, есть объекты и у них есть свойства и представления; но как связаны объекты и функции (операции пользователя, поддерживаемые интерфейсом)? Методы и функции? Непонятно, почему на первое место выносится то, что можно делать с объектом, а не то, что делает пользователь (та самая Job из jtbd).
Я ожидал развитие доклада с Profsoux-2020, но показалось даже более смазанным.
На январском UX-марафоне про ИА был доклад на почти эту же тему, мне он показался более цельным.
Системно:
⁃ Сделана попытка рассмотреть моделирование сценариев через модули системы — названы объектами, — обеспечивающие операции — названы методами, но в пассивном рассмотрении: действия “над объектом” вместо “модуль выполняет функцию F”.
⁃ Показалось, что есть попытка рассмотреть метод вне сценарной парадигмы, но я не понял, как от неё отказаться, так как про цели-операции-действия пользователя не было сказано.
———
#проектирование #UX #мероприятия #функция #модуль #сервис
Объектно-ориентированный UX
Алексей Сорокин, Мой склад
(Метод, применяемый для проектирования сложных продуктов и систем, основанный на ОО-практиках)
1. Есть дизайн “по-быстрому” — понять задачу > применить интуицию, опыт, здравый смысл, насмотренность > макет/гипотеза
2. Во втором шаге происходит “магия”
3. При применении JTBD, CJM, etc — задача уточняется, но “магия” остается
4. Статистика с прода, тестирования, etc — это все равно обвес вокруг “магии”, лишь уточняющий данные на вход
5. Макет/гипотеза — подчиняется циклу гипотеза > эксперимент > сбор данных > анализ и вывод; цикл стоит денег
6. Чем точнее гипотеза, тем меньше циклов
7. Сложный продукт — где много сценариев; аналогия: сам интернет-магазин это поезд, он едет по рельсам, а админка интернет-магазина это самолет, он летает как хочет
8. В сложном продукте тем более цикл выглядит так: гипотеза > эксперимент > сбор данных > “магия”
9. “Попробуем без сценариев” (без сценариев? Интересно как это…)
10. Три вопроса про пользователя: каков его опыт? в каком состоянии/контексте пользователь? использует систему чтобы что?
⁃ На первые два вопроса отвечает метод персон, на третий отвечает jtbd
⁃ Задачи в персонах — это job в jtbd
11. Пользователь работает с объектами; работа = действие + объект + контекст
12. Далее про связь объектов и их обозначений
13. Объект в системе: у него есть свойства, методы, представления
⁃ Свойства — атрибуты объекта, то, как его можно охарактеризовать
⁃ Методы — действия, которые можно сделать с объектом
⁃ Представления объекта — проекция объекта из ментальной модели пользователя на интерфейс; полное представление есть перечисление всех его свойств и методов; например, в навигации используются краткие представления объектов
14. Принципы работы с представлениями:
⁃ Нужно полное представление объекта — вся информация для создания проекций; пример: карточка объекта
⁃ Нужен полный набор допустимых действий над объектом
⁃ Нужно дать пользователю контроль над “его” объектами
⁃ Если связь между объектами есть, то ее необходимо показать в интерфейсе
15. Далее про сценарии:
⁃ На основе сценариев выбираем представления объектов в контекстах
⁃ Также на основе сценариев строим порядок представления объектов
⁃ На основе сценариев понимаем необходимый набор представлений
⁃ И также на основе сценариев …не успел записать…
16. Для работы с объектами помогает ER-диаграмма, отражающая набор объектов, их свойства и методы, и связи объектов
17. Заключение — что дает OOUX:
⁃ Доп. инструмент проектирования
⁃ Меньше “магии” и больше аргументировать
⁃ “Меньше интуиции, больше логики”
⁃ Можно не держать в голове сложные объекты
Доклад на важную тему — о том как превратить интуицию и “магию” проектирования в объясняемые паттерны.
Что хорошо — доклад вызывает интерес к моделированию на концептуальном уровне.
Что плохо — не звучало убедительно: да, есть объекты и у них есть свойства и представления; но как связаны объекты и функции (операции пользователя, поддерживаемые интерфейсом)? Методы и функции? Непонятно, почему на первое место выносится то, что можно делать с объектом, а не то, что делает пользователь (та самая Job из jtbd).
Я ожидал развитие доклада с Profsoux-2020, но показалось даже более смазанным.
На январском UX-марафоне про ИА был доклад на почти эту же тему, мне он показался более цельным.
Системно:
⁃ Сделана попытка рассмотреть моделирование сценариев через модули системы — названы объектами, — обеспечивающие операции — названы методами, но в пассивном рассмотрении: действия “над объектом” вместо “модуль выполняет функцию F”.
⁃ Показалось, что есть попытка рассмотреть метод вне сценарной парадигмы, но я не понял, как от неё отказаться, так как про цели-операции-действия пользователя не было сказано.
———
#проектирование #UX #мероприятия #функция #модуль #сервис