Что такое артефакты в программировании
На этом шаге рассмотрим понятие артефакта.
Артефакты живут в материальном мире битов и потому являются важнейшими строительными блоками при моделировании физических аспектов системы. Артефакт – это физическая и заменяемая часть системы.
Артефакты используются для моделирования таких физических сущностей, которые могут располагаться на узле, – например, исполняемых программ, библиотек, таблиц, файлов и документов. Обычно артефакт представляет собой физическую группировку таких логических элементов, как классы, интерфейсы и кооперации.
Вы осуществляете логическое моделирование для визуализации, специфицирования и документирования решений относительно словаря предметной области, а также структурных и поведенческих способов кооперации сущностей. Физическое же моделирование требуется для построения исполняемой системы. Если логические сущности «живут» в концептуальном мире, то физические пребывают в мире битов, то есть в конечном счете располагаются на физических узлах и могут быть исполнены непосредственно либо каким-то косвенным образом участвовать в работе исполняемой системы.
В UML все физические сущности моделируются как артефакты. Артефакт – это физическая сущность на уровне платформы реализации.
Многие операционные системы и языки программирования непосредственно поддерживают концепцию артефакта. Объектные библиотеки, исполняемые программы, компоненты .NET и Enterprise Java Beans, – все это примеры артефактов, которые могут быть представлены на UML. Но артефакты могут быть использованы и для представления других сущностей, которые принимают участие в работе исполняемых программ, – таких, как таблицы, файлы и документы.
В UML артефакты изображаются так, как показано на рис. 1.
Эта каноническая нотация позволяет визуализировать артефакт независимо от операционной системы и языка программирования. Используя стереотипы – один из механизмов расширения UML, можно приспособить эту нотацию для представления специфических разновидностей артефактов.
Артефакт – это физическая часть системы, которая существует на уровне платформы реализации. Изображается в форме прямоугольника с ключевым словом «artifact» внутри.
На следующем шаге рассмотрим имена артефактов в UML.
#2. Что такое артефакт проекта и зачем они нужны?
Артефакт – это искуственно созданный объект, который наделяется каким-то смыслом тем, кто его создал. Например: схема, документ, прототип – это все артефакты. По сути артефакт это сжатое, емкое понятие единственная цель которого – оптимизация. Оптимизация времени на объяснение того, что нужно, оптимизация текста, затрачиваемого на описание чего-то и так далее.
Для процесса разработки программного обеспечения был выведен следующий общий набор артефактов (картинки второстепенны – я просто их люблю):
Кол-во трактовок каждого из этих артефактов пропорционально кол-ву проект менеджеров. О каждом из этих артефактов написаны сотни книг и тысячи статей, но я просто опишу суть.
EPIC (Эпик)
Эпиком является большой компонент разрабатываемой программы. В каждом проекте есть несколько эпиков, которые, в сумме, показывают нам что мы ожидаем по окончанию проекта.
Эпики составляются Бизнес Аналитиками (Business Analyst), Менеджерами Продукта (Product Manager) а иногда (редко) Владельцами Продукта (Product Owner).
Проект: «Мобильное приложение UBER».
Эпики: «Система регистрации», «Интерактивная карта», «Платежная система», «Рейтинговая система» и так далее.
Обычное описание эпика (так делает большинство):
Система регистрации – необходимо имплементировать возможность регистрации посредством социальных сетей, с обязательной верификацией номера мобильного телефона.
В идеале же, эпик должен содержать бизнес-информацию, чтобы команда работающая над эпиком понимала не только то, что нужно разработать, но и то – зачем это нужно. Здесь могут содержаться результаты исследований, краткие выжимки статистических данных и прочее.
Пример:
Система регистрации.
Целевая аудитория состоит из мужчин и женщин в пропорции (65% / 35%). Возраст 18 – 45.
Ввиду того, что в наших стратегических планах присутствует расширение и запуск в Китае, необходимо учесть, что Facebook там запрещен, но присутствуют локальные соц. сети Webo и Wechat.
Для аналитики нам потребуется собирать любую информацию которая помогла бы выявить специфику в группе пользователей, а также облегчить процесс регистрации для пользователей целевой аудитории.
И так далее.
Грамотный управленец в чьи обязанности входит составление эпиков обязательно снабдит их общей информацией по поводу того, что нужно учитывать при работе с компонентом. При необходимости могут быть добавлены детали связанные с юридической, экономической, стратегической и другой информацией.
О ужас – скажете вы – неужели программисту действительно нужна эта информация?
О ужас – скажет среднестатистический программист – зачем мне все это нужно? Отмените ланч, мне срочно нужно писать код!
Однако, если мы говорим о настоящем качестве, где команда действительно действует как команда, а компания является живым организмом в котором эта команда живет и на благо которого процветает – тогда альтернативы нет.
Мы должны быть настолько прозрачны с командой, насколько нам позволяет бизнес. Я не говорю, что в эпиках или вообще где бы то ни было нужно выписывать информацию представляющую коммерческую тайну. Однако единственный риск изложения наших мотивов – это получение ценного совета от одного или нескольких коллег. Если же у нас нет проблем с эго, тогда это не риск а успех.
User Story (Пользовательская история)
Данный артефакт вмещает в себе требования к разрабатываемому компоненту.
Один Эпик может содержать в себе десятки пользовательских историй.
Пользовательская история составляется Владельцем Продукта (Product Owner), Менеджером Продукта (Product Manager)-ом или Менеджером Проекта(Project Manager) (Хотя в идеале, проект менеджер, конечно, этим заниматься не должен, но мир не идеален).
В отличие от Эпика, в Историях находится именно та информация, которая напрямую необходима программисту для разработки компонента.
Обычно, пользовательские истории пишутся от первого лица, в формате «Как пользователь . я бы хотел . чтобы. » , однако, опять же, по обоюдной договоренности с командой разработчиков, может быть применен и другой формат.
Для эпика «Платежная Система» могут быть выведены следующие Истории:
«Страница платежных методов», «Прикрепление банковской карты», «Прикрепление PayPal аккаунта», «Страница оформления заказа» и далее.
Пример пользовательской истории «Страница платежных методов»:
«Как пользователь UBER, я бы хотел иметь возможность доступа к странице «Платежные Методы» из левого меню.
На этой странице я бы хотел видеть две кнопки:
Добавить новую карту
На этой странице я бы хотел видеть две кнопки:
«Добавить новую карту»
«Добавить PayPal аккаунт»
Если у меня уже есть добавленные методы платежа, я бы хотел видеть их в списке, с указанной датой добавления.
Напротив добавленных методов я бы хотел видеть кнопку удаления платежного метода, которая, при нажатии, открывала бы окно подтверждения действия с вариантами «Да/Нет».»
Для примера этого хватит. Структура пользовательской истории – это вопрос опыта, который приходит со временем, но необходимо понимать, что здесь важно совершенно все. Любая деталь, которая будет упущена – это минус несколько минут/часов/десятков часов для программистов работающих над историей.
Так, если вышеуказанная история доберется до программистов, один из первых вопросов который у них возникнет будет «А могу ли я прикрепить несколько банковских карт и/или PayPal аккаунтов?», дальше пойдет «А в какой поочередности мы должны их расставить? По дате добавления? По названию? Если по дате добавления – то могут ли карты и PayPal аккаунты чередоваться, или сперва мы должны показывать карты, а затем – PayPal аккаунты?».
Все это и еще десятки других вопросов совершенно справедливо возникнут у разработчиков, потому что ничего не было написано в истории. В свою очередь на выяснение каждого из этих вопросов может понадобиться разное кол-во времени и вовлеченных лиц, и так, история, которая была оценена в «5 часов работы» может затянуться на дни, недели а то и месяцы.
Таким образом, для написания идеальной пользовательской истории, менеджеру нужно понять:
- Как этот компонент системы должен работать?
- Какие вопросы могут возникнуть у программистов?
- Какие вопросы могут возникнуть у дизайнеров?
- Какие вопросы могут возникнуть у тестировщиков?
- Какие вопросы могут возникнуть у конечных пользователей этого компонента?
Кстати, последний вопрос менеджеру необходимо задавать себе так много раз. Если менеджер не понимает ожиданий пользователей, это значит что история не созрела для написания, и нужно собрать больше данных.
Task (Задача)
Задачи – это то, на что раздробляется пользовательская история. Так, для разработки истории «Страница платежных методов» могут понадобиться десятки задач, в которых будут вовлечены дизайнеры, программисты и тестировщики.
Обычно, задачи составляются техническими специалистами (разработчиками) при участии Project Manger-а, либо Product Owner-а (по необходимости). В идеале, если история написана так, что ни у кого не возникает никаких вопросов – все задачи могут быть написаны разработчиками.
Разработчиком ответственным за раздробление задач обычно является Ведущий Разработчик (Team Lead).
Sub-Task (Подзадача)
Подзадача – это результат дробления задачи на более мелкие составляющие. Используется по необходимости, на усмотрение Team Lead-а.
Bug (Баг)
Ошибка, возникшая в программе. Результат, не соответствующий описанию того, как должен работать компонент. Например мы нажимаем на «Прикрепить PayPal», но в открывшемся меню мы видим приглашение прикрепить банковскую карту. Грусть.
Поиском ошибок занимаются тестировщики, являющиеся одним из звеньев в разработке ПО.
Помимо тестировщиков, баги выявляются самими пользователями, которые в свою очередь обращаются в службу поддержки с вопросами а-ля «У меня открылось не то окно, что делать?».
Вне зависимости от того, кто обнаружил баг, он должен быть задокументирован, чтобы в порядке некой согласованной очереди команда разработчиков его исправила.
Вот и все. Каждый год появляются какие-то новые «артефакты-обозначения», которые набирают группы фанатов свято верующих что Эпики устарели, и что единственно-верным подходом является использование «Goal/Experience/Initiative/Feature» (нужное подчеркнуть). На самом же деле совершенно не важно как ты назовешь то, что делаешь, если ты понимаешь что делаешь. Единственно правильное во всем этом – чтобы структура была простой и понятной настолько, насколько это возможно.
В следующей статье мы бегло пройдем по онлайн системам управления проектами и увидим, где и как используется все то, о чем мы поговорили в этой статье.
Copyright © 2019 — 2023 Wolf Alexanyan. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation.
Что такое артефакт в разработке ПО?
Артефакт — это любой созданный искусственно элемент программной системы.
К элементам программной системы, а, следовательно, и к артефактам, могут относиться исполняемые файлы, исходные тексты, веб страницы, справочные файлы, сопроводительные документы, файлы с данными, модели и многое другое, являющееся физическим носителем информации. Другими словами, артефактами являются те информационные элементы, которые тем или иным способом используются при работе программной системы и входят в ее состав.
С понятием «компонент» часто ассоциируют компонентное или сборочного программирование, однако это не верно с точки зрения UML. В терминах UML компонентное или сборочное программирование манипулирует артефактами!
Компонент (в UML) — это частью модели, описывающая логическую сущность, которая существует только во время проектирования (design time), хотя в дальнейшем ее можно связать с физической реализацией (артефактом) времени исполнения (run time).
Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
gezgrouvingus progreszive ombusgrander greyderzux
артефакт — любой элемент, или можно сказать объект в ПО (системе), очень просто если
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Компьютерные сети
- +2 ещё
Как подключиться к Windscribe с российского wifi?
- 1 подписчик
- 16 часов назад
- 57 просмотров
Что такое артефакты в программировании
В контексте данного руководства под артефактом понимается файл (обычно JAR или ZIP), содержащий исполняемый или другой код, получившийся в результате сборки проекта. Артефакт имеет версию и имя, соответствующее определённым правилам, и может храниться в репозитории артефактов.
Базовые проекты
То же самое что компоненты приложения. Данный термин был принят в предыдущих версиях платформы и документации.
БД
Реляционная база данных.
Браузер сущностей
Экранная форма, на которой размещается таблица со списком сущностей, а также кнопки создания, редактирования, удаления сущности.
Внедрение зависимости
Известно также как принцип Inversion Of Control (IoC). Механизм для получения ссылок на используемые объекты, при котором объект только декларирует, от каких объектов он зависит, а контейнер создает нужные объекты и инжектирует в зависимый объект.
Главный пакет сообщений
Жадная загрузка
Загрузка данных подклассов и связанных объектов одновременно с основной запрашиваемой сущностью.
Загрузка по требованию
Контейнер
Контейнер управляет жизненным циклом и конфигурацией программных объектов. Является базовым компонентом технологии Dependency Injection (или Inversion of Control).
В платформе CUBA используется контейнер Spring Framework.
Контроллер экрана
Java класс, содержащий логику инициализации и обработки событий экрана. Связан с XML-дескриптором экрана.
Локальный атрибут
Атрибут сущности, не являющийся ссылкой или коллекцией ссылок на другую сущность. Значения всех локальных атрибутов сущности, как правило, хранятся в одной таблице (исключение составляют некоторые стратегии наследования сущностей).
Пакет локализованных сообщений
Персистентный контекст
Набор экземпляров сущностей, загруженных из базы данных или только что созданных. Персистентный контекст является кэшем данных в рамках текущей транзакции. При коммите транзакции все изменения сущностей в персистентном контексте сохраняются в БД.
Представление
Репозиторий артефактов
Сервер, осуществляющий хранение артефактов в определенной структуре. В процессе сборки некоторого проекта из репозитория загружаются артефакты, от которых зависит данный проект.
Сущность
Основной элемент модели данных, см. Модель данных.
Application Tiers
Application Properties
Свойства приложения − именованные данные различных типов, определяющие всевозможные аспекты конфигурации и функционирования приложения.
Application Units
Eager Fetching
EntityManager
Программный компонент среднего слоя, служащий для работы с персистентными сущностями.
Groovy
Groovy — объектно-ориентированный язык программирования, разработанный для платформы Java как дополнение к языку Java с возможностями Python, Ruby и Smalltalk.
Interceptor
Элемент AOP (Aspect Oriented Programming), позволяющий изменить или расширить обычный вызов метода объекта.
JMX
Java Management Extensions − технология, которая предоставляет инструменты для управления приложениями, объектами системы, устройствами. Определяет стандарт для написания JMX-компонентов − MBeans.
JPA
Java Persistence API — стандартная спецификация технологии объектно-реляционного отображения (ORM). В платформе CUBA используется фреймворк EclipseLink, реализующий эту спецификацию.
JPQL
Независимый от БД объектно-ориентированный язык запросов, определенный как часть спецификации JPA. См. https://en.wikibooks.org/wiki/Java_Persistence/JPQL.
Lazy loading
Managed Beans
Программные компоненты, управляемые контейнером и содержащие бизнес-логику приложения.
MBeans
Managed Beans, имеющие JMX-интерфейс. Как правило, имеют внутреннее состояние (например, кэш, конфигурационные данные или статистику), к которому нужно обеспечить доступ через JMX.
Middleware
Средний слой − уровень приложения, содержащий бизнес-логику, работающий с базой данных, и предоставляющий общий интерфейс для верхних (клиентских) уровней приложения.
Optimistic locking
Оптимистичная блокировка — способ управления совместным доступом к данным различными пользователями, при котором предполагается, что возможность одновременного изменения ими одного и того же экземпляра сущности мала. В этом случае блокировка как таковая отсутствует, вместо нее в момент сохранения изменений производится проверка, нет ли в БД более новой версии данных, сохраненной другим пользователем. Если есть, выбрасывается исключение, и текущий пользователь должен снова загрузить данный экземпляр сущности.
ORM
Object-Relational Mapping — объектно-реляционное отображение — технология связывания таблиц реляционной базы данных с объектами языка программирования.
Services
Сервисы среднего слоя предоставляют интерфейс для вызова бизнес-логики клиентами и образуют границу Middleware. Сервисы могут содержать бизнес-логику внутри себя, либо делегировать выполнение Managed Beans.
Single Sign-On, SSO
Технология, при использовании которой пользователь переходит от одного приложения к другому без повторной аутентификации. Интеграция CUBA-приложения с Active Directory позволяет пользователям Windows входить в приложение без ввода имени и пароля.
Soft deletion
UI
User Interface — пользовательский интерфейс.
View
XML-дескриптор
Файл в формате XML, содержащий описание компонентов данных и расположения визуальных компонентов экрана.