crud приложение что это

Алгоритм CRUD

API должен выполнять четыре типа функций. Он должен иметь возможность создавать новые данные, а также читать, обновлять и удалять существующие. В информатике мы называем эти параметры CRUD.

Метод CRUD необходим при создании веб-приложений, поскольку он позволяет структурировать модели, которые вы создаёте для своих API. Но как работает CRUD? Как вы взаимодействуете с API с помощью CRUD?

В этой статье мы отвечаем на эти вопросы. Мы начнём с обсуждения основ CRUD, а затем рассмотрим несколько примеров того, как взаимодействовать с API с помощью CRUD.

Зачем нам нужен CRUD

Допустим, мы создаём API, в котором хранится кофе, продаваемый в нашем кафе. Этот API должен иметь возможность хранить различные объекты кофе. Кофейный объект может включать:

Мы хотим убедиться, что пользователи могут взаимодействовать и изменять данные, хранящиеся в нашем API. Вот почему нам нужно следовать структуре CRUD. В конце концов, для чего нужен API, в котором хранится кофе, если компания не может изменить цену на свой кофе? Зачем компании использовать API, который не позволяет удалять записи?

Что такое CRUD

CRUD — это аббревиатура от Create, Read, Update и Delete.

Когда вы работаете с веб-службами, CRUD соответствует следующим HTTP-методам, которые используются, чтобы сообщить веб-серверу, как вы хотите взаимодействовать с веб-сайтом:

Давайте рассмотрим каждого в отдельности.

Мы собираемся использовать утилиту командной строки cURL для создания примеров запросов к API кофе, чтобы вы могли увидеть, как работают эти операции. Прежде чем мы начнём, запустите следующую команду в терминале на вашем компьютере, чтобы убедиться, что cURL установлен:

Если в вашем терминале появляется ошибка «curl: command not found», вам необходимо установить cURL. В противном случае вы готовы приступить к работе!

Создать

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

Чтобы добавить новый кофе в меню, мы можем использовать запрос POST, который позволяет нам отправлять данные в наш API, которые будут храниться в базе данных.

Вот информация о кофейном элементе, который мы хотим добавить:

Следующая команда cURL позволяет нам создать кофе с этими деталями с помощью нашего API:

Эта команда создаёт новый кофе в нашей базе данных с именем «Эспрессо» и ценой «1,95».

Читать

Наш API должен позволять нам видеть список всех сортов кофе в нашем меню. Чтобы увидеть эти данные, мы можем использовать запрос GET. Это позволяет нам видеть список кофе в нашем меню, не внося изменений в данные, хранящиеся в нашем API.

Эта команда позволяет нам получить список кофе из нашего API:

Источник

Что такое CRUD-операции

Если вы когда-либо работали с базами данных, вы, вероятно, использовали операции CRUD. CREATE, READ, UPDATE и DELETE — это четыре основные операции программирования РСУБД. Операции CRUD используются для управления, чтения, вставки, удаления и редактирования данных таблицы.

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

Что такое операции CRUD?

Любые организации, отслеживающие данные (например, учетные записи, платежную информацию или другие записи), нуждаются в системах, обеспечивающих постоянное хранение, которое обычно организовано в базу данных. Реляционная база данных состоит из данных, организованных по строкам и столбцам. Их можно подключить к другим таблицам с помощью первичных и внешних ключей.

CRUD (создание, чтение, обновление, удаление) — это аббревиатура, обозначающая четыре функции, которые мы используем для реализации приложений постоянного хранения и приложений реляционных баз данных, включая Oracle Database, Microsoft SQL Server и MySQL.

В таблице ниже показано, что означает каждая операция CRUD.

Письмо Операция Функция
C Создавать Вставлять
р Читать Выбирать
U Обновлять Редактировать
D Удалить Удалить

Для SQL карты CRUD для вставки, выбора, обновления и удаления соответственно. Такие операции, как управление безопасностью, управление транзакциями, доступ и разрешение, а также оптимизация производительности, основаны на CRUD.

Почему CRUD так важен?

CRUD постоянно используется для всего, что связано с базами данных и проектированием баз данных. Разработчики программного обеспечения ничего не могут сделать без операций CRUD. Например, при разработке веб-сайтов используется REST (передача репрезентативного состояния), который является надмножеством CRUD, используемого для ресурсов HTTP.

С другой стороны, CRUD не менее важен для конечных пользователей. Без него такие вещи, как регистрация на веб-сайтах, создание блогов или закладок, были бы невозможны. Большинство приложений, которые мы используем, позволяют нам добавлять или создавать новые записи, искать существующие, вносить в них изменения или удалять их.

CRUD предлагает множество преимуществ, в том числе:

CREATE

Create позволяет добавлять новые строки в вашу таблицу. Вы можете сделать это с помощью команды INSERT INTO. Команда начинается с INSERT INTOключевого слова, за которым следует имя таблицы, имена столбцов и значения, которые нужно вставить.

При использовании у INSERT INTOвас есть два варианта:

В приведенном ниже примере мы добавим данные в нашу таблицу пекарни.

Это добавит новые строки в таблицу меню, и каждая запись будет иметь уникальный id.

Функция чтения похожа на функцию поиска, поскольку позволяет извлекать определенные записи и считывать их значения. Читать относится кSELECT

Например, давайте посмотрим на товары, которые мы продаем в нашей пекарне. Для этого мы должны отобразить все данные в нашей таблице меню, используя:

Это не внесет никаких изменений в таблицу меню, а просто отобразит все записи в этой таблице.

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

UPDATE

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

Рекомендуется ограничить количество строк, так как это помогает избежать проблем с параллелизмом.

Чтобы обновить существующую запись, используйте следующее:

Допустим, мы хотим обновить название и цену товара. Мы бы использовали:

Это обновит таблицу, так что предыдущая запись с id 1теперь будет заменена шоколадным круассаном с price 2.5.

DELETE

Удалить используется для удаления записи из таблицы. SQL и имеет встроенную функцию удаления для одновременного удаления одной или нескольких записей из базы данных. Некоторые приложения реляционных баз данных могут разрешать жесткое удаление (безвозвратное удаление) или мягкое удаление (обновление статуса строки).

Команда удаления выглядит следующим образом:

Если мы хотим удалить один элемент из таблицы, мы используем:

Это приведет к удалению строки с хлебным предметом из таблицы. Если вы хотите удалить все записи из таблицы, вы можете использовать:

Следующие шаги для вашего обучения

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

Если вы хотите узнать больше о SQL, вы можете начать со следующих тем:

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

Источник

Быстрое создание CRUD-основы приложения на Entity Framework/ASP.Net MVC

Предыстория

База данных

Такой общий подход сильно упростит нам жизнь в будущем, скоро увидите почему. Далее садимся и аккуратно и внимательно создаем таблицы в базе данных. Здесь и далее я буду показывать все на примере двух из них:


Остальные таблицы не отличаются чем-либо существенным.

public partial class HomeWorkUnitType : IDataObject
<
public string DisplayName
<
get < return Name; >
>
>

Свойство DisplayName пригодится нам, когда дело дойдет до UI.

Контроллеры

public abstract class DataObjectController : Controller
where T : EntityObject, IDataObject
<
>

private DataModelEntities m_DataContext;
protected DataModelEntities DataContext
<
get
<
if (m_DataContext == null )
<
m_DataContext = new DataModelEntities();
>
return m_DataContext;
>
>

protected abstract IQueryable Table < get ; >
protected abstract Action AddObject

public abstract class DataObjectController : Controller
where T : EntityObject, IDataObject
<
private DataModelEntities m_DataContext;
protected DataModelEntities DataContext
<
get
<
if (m_DataContext == null )
<
m_DataContext = new DataModelEntities();
>
return m_DataContext;
>
>

protected abstract IQueryable Table < get ; >
protected abstract Action AddObject

protected virtual IEnumerable GetAll()
<
foreach ( var t in Table.AsEnumerable())
<
LoadAllDependedObjects(t);
yield return t;
>
>

protected virtual T GetById( int id)
<
var t = Table.First(obj => obj.Id == id);
LoadAllDependedObjects(t);
return t;
>

protected virtual void CreateItem(T data)
<
AddObject(data);
>

protected virtual T EditItem(T data)
<
T existing = GetById(data.Id);
DataContext.ApplyPropertyChanges(existing.EntityKey.EntitySetName, data);
return existing;
>

protected virtual void DeleteItem( int id)
<
DataContext.DeleteObject(GetById(id));
>

public virtual ActionResult Index()
<
return View(GetAll());
>

public virtual ActionResult Details( int id)
<
return View(GetById(id));
>

public virtual ActionResult Create()
<
LoadAllDependedCollections();
return View();
>

[AcceptVerbs(HttpVerbs.Post)]
public virtual ActionResult Create(T data)
<
try
<
ValidateIdOnCreate();
ValidateModel();
CreateItem(data);
DataContext.SaveChanges();
return RedirectToAction( «Index» );
>
catch (Exception ex)
<
LoadAllDependedCollections();
ViewData[ «Error» ] = ex.JoinMessages();
return View(data);
>
>

public virtual ActionResult Edit( int id)
<
LoadAllDependedCollections();
return View(GetById(id));
>

[AcceptVerbs(HttpVerbs.Post)]
public virtual ActionResult Edit(T data)
<
try
<
ValidateModel();
data = EditItem(data);
DataContext.SaveChanges();
return RedirectToAction( «Index» );
>
catch (Exception ex)
<
LoadAllDependedCollections();
ViewData[ «Error» ] = ex.JoinMessages();
return View(data);
>
>

public virtual ActionResult Delete( int id)
<
try
<
ValidateModel();
DeleteItem(id);
DataContext.SaveChanges();
>
catch (Exception ex)
<
ViewData[ «Error» ] = ex.JoinMessages();
>
return RedirectToAction( «Index» );
>

protected void ValidateModel()
<
if (!ModelState.IsValid)
<
throw new Exception( «Model contains errors.» );
>
>

protected virtual void LoadAllDependedCollections()
<
>

protected virtual void LoadAllDependedObjects(T obj)
<
>

protected virtual void ValidateIdOnCreate()
<
ModelState[ «Id» ].Errors.Clear();
>
>

Контроллеры простых объектов

public class HomeWorkUnitTypeController : DataObjectController
<
protected override IQueryable Table
<
get < return DataContext.HomeWorkUnitType; >
>

Контроллеры сложных объектов

protected virtual void LoadAllDependedCollections()
<
>

protected virtual void LoadAllDependedObjects(T obj)
<
>

public class HomeWorkUnitController : DataObjectController
<
protected override IQueryable Table
<
get < return DataContext.HomeWorkUnit; >
>

Источник

Микросервисы: от CRUD до Native Image. Часть первая

Слово «микросервисы» на слуху последние несколько лет. Технология активно развивается, на онлайн-конференциях о ней говорят, да и сами мы пишем их каждый день. Когда-то новый подход уже стал рутиной. Но мне как Java-архитектору интересно то, каким код был раньше, как он менялся, какие способы исполнения популярны сейчас и будут использоваться в 2021 году: асинхронность, контейнеры, FaaS.

Так родился этот пост в двух частях, который я подготовил для Хабра на основе своих статей в блоге компании BellSoft и круглого стола Joker 2020, где мы обсуждали будущее джавы. Актуальное сегодня улучшение экосистемы для бэкендов не может существовать без понимания того, как создавать микросервисы: писать с нуля или вырезать скальпелем из монолитов? Предлагаю в первой части поговорить об их сущности, а во второй — разложить микросервисный контейнер на слои и посмотреть на вклад каждого слоя.

Главное преимущество — в структуре

Абсолютное большинство материалов о микросервисной архитектуре сравнивает её с монолитами с точки зрения строения. Того, каким образом работают компоненты, как единое целое или изолированно. Микросервисы не зависят друг от друга и могут обмениваться данными по сети через произвольные протоколы, например, REST API. Что это нам дает? Как минимум, свободу выбирать любые тулы, не оглядываясь на ESB, ограничения схем и тонкости совместимости. Виртуализация и контейнеризация тоже развиваются, и вот уже крошечные контейнеры с Alpine Linux позволяют запускать на прежде выделенном железе много компонент сразу.

Возьмём простой сервис, такой как бронирование билета или пополнение счёта. Ещё до появления микросервисов для управления жизненным циклом объекта данных в таких системах использовали подход CRUD. Но вся функциональность, которая обеспечивает CRUD операции для какой-то сущности, легко вычленяется. После чего можно отдельно заниматься масштабированием, управлением доступом и взаимодействием в целом, например, через REST.

Вроде, всё отлично, в чём подвох?

Проблемы и решения

Разные части монолитного приложения работают в общей памяти, а все запросы отправляются на один и тот же физический сервер. Микросервисы же связываются между собой через протоколы, а это порождает, например:

сложность в управлении сетевым трафиком и задержки;

сбои запросов и другие ошибки;

необходимость сериализовать данные и шифровать соединения.

Пожалуй, сегодня программист сервиса решит эти проблемы через готовые API Kafka/Redis/RabbitMQ и снимет с себя головную боль, отчасти забыв о сетевом уровне. А задача настройки Kafka уже пойдёт как активность DevOps.

Кроме того, управление микросервисами может стать проблемой, если их много. Поведение приложения становится сложно предсказать. Представьте сеть из сотен виртуальных хранилищ, каждое из которых обращается к другому, а иногда — одновременно. Где-то наверняка произойдёт сбой.

Есть ряд очевидных подходов к решению этой проблемы:

Декомпозиция сервиса с помощью брокеров сообщений и систем управления потоковыми данными (Kafka, Kinesis);

Взаимодействие между сервисами с помощью сервисной сетки, или service mesh (Istio, OSM);

В идеале задача — избежать такой картины:

превратив её, скажем, в такую:

Видим, что современные системы стриминга сообщений предоставляют готовые коннекторы для баз данных и других хранилищ. Здесь streaming platform (допустим, Kafka) позволяет больше не думать, как связать базы со всем остальным приложением.

Если мы взглянем отдельно на первый уровень прямо под пользователем, то он тоже довольно сложный. Редкий сервис работает с одной копией приложения, их могут быть сотни. А значит, нужно понимать, куда полетят запросы.

Service mesh («cервисная сетка») как раз помогает наладить отправку и обработку запросов. При этом возникает задача построения архитектуры, в которой уже есть свои шаблоны проектирования, такие как Sidecar.

Рантаймы, такие как JVM, вместе с языками и фреймворками поддерживают всю эту конструкцию, вывозя на себе исполнение кода.

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

Выбор инструментов

При исполнении бизнес-логики, конечно же, задействовано само приложение и операционная система. Обратимся к недавней истории и посмотрим, что же ещё нужно для сборки контейнера.

Для начала уместно будет вспомнить о сервис-ориентированной архитектуре. На фоне монолитов это первая успешная попытка решить проблемы в работе всего приложения за счёт слабой связности его частей. Можно сказать, что микросервисы — это усовершенствованная интерпретация SOA.

До поры до времени она справлялась с горизонтальным масштабированием сервисов. Но методы программирования не прекращали развиваться. Железо становилось лучше, сети — быстрее. Появлялись новые, легковесные способы коммуникации между приложениями, например REST.

Как обстояли дела с Java? Здесь всё началось с систем, основанных на наследовании и конфигах. Java EE еще лет 20 назад представила сервлеты. Далее история известна: конфигурация прямо в коде, когда XML и сам код генерировались из javadoc аннотаций; затем появились настоящие аннотации; следом и дженерики в Java 5. А вот сериализация уже была с самого начала. Появляющиеся фичи языка использовались в новых версиях Java EE.

Да, в спецификации Java EE прописаны протоколы (например, JNDI), но разработчикам реально помогло то, она описывает простые декларации того, что фактически контролируется сервером приложений. Когда мир перешел с Web 1.0 на Web 2.0, ответственность за представление перешла от бэкенда к фронтенду. И разница между внешними запросами и запросами от другой части системы исчезла.

Container dependency injection

Или «контейнерное внедрение зависимостей». Время идёт, за долгие годы индустрия освоила фичи языка и сформировала набор производственных практик. «Метапрограммирование при помощи аннотаций» — так теперь джависты могут описать свои будни. И в разработке фреймворков применяются те же подходы. Хотя стоит отметить, что другие языки предлагают достойные альтернативы: trailing lambdas в Kotlin для описания маршрутизации в Ktor; или же data-классы в разных языках, которые наконец догнала Java в 14 версии с её новыми record-ами (хотя и для старых версий давно есть Lombok).

С помощью аннотаций или внешних конфигов можно помечать обычные поля классов. А после построения необходимых объектов их внедрением занимаются контейнеры или фреймворки, контролирующие жизненный цикл класса/бина. Это может быть сложно устроено, однако исходный код не заметит этой сложности, либо подмены, которую внедрили для тестирования, или смены способа коммуникации. Этот метод широко поддерживается современными IDE, а значит можно писать код, состоящий из более мелких компонентов. Все эти действия — шаги на пути к надёжному ПО.

Собственно такой шаблон построения компонентных моделей называется Contexts and Dependency Injection (CDI). CDI как спецификация Java EE была принята в JSR 299/365 и получила эталонную реализацию в Weld, которая до сих пор используется в контейнерах вроде WildFly. Основной принцип подобной архитектуры — инверсия управления (Inversion of Control, IoC).

Не все задачи предполагают строгие стандарты: например, модули, которые подключаются к базам данных (как Spring Data) или участвуют в создании интерактивного HTML. Но для них существуют фреймворки. В каждом — ограниченный набор таких модулей, что позволяет вести разработку продуктивно. Внедрение зависимостей и инверсия управления, наряду с еще одной полезной парадигмой Convention over Configuration (также известной как «кодирование по соглашению»), реализованы в IoC-контейнерах во фреймворках, например BeanFactory в Spring. Но о них поговорим в следующий раз.

Заключение

Как я и обещал во вступлении, этот пост стал небольшим экскурсом в историю микросервисной архитектуры — ведь без этого никуда. Мы работаем с отличными технологиями, которым уже 20 с лишним лет, но они по-прежнему ощущаются современными. Всё потому, что методы востребованные и живые, а не превращаются в legacy.

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

Источник

Технология CRUD-матрицы. Практический опыт


Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин.

Немного теории: описание методики

IIBA в компетенцию бизнес-аналитика в области Agile (далее Agile-аналитик) относит следующие технологии:
— Определение критериев оценки и приёмки;
— Мозговой штурм;
— Различные методы оценки (метод Delphi, параметрический метод, метод аналогий, трёхточечный метод и т.п.);
— Прототипирование;
— Разработка сценариев и описание прецедентов;
— Моделирование областей для анализа или поставки решений;
— Пользовательские истории.

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

Практическая часть: разработка CRUD-матрицы

Разработка CRUD-матрицы помогает Agile-команде сконцентрироваться на существенных прецедентах, описывающих бизнес-процесс. CRUD-матрица формируется в виде таблицы, в которой в верхней части перечисляются все классы из диаграммы классов, а в левой части отражается список прецедентов. Задача Agile-аналитика заполнить пересечения между прецедентами и классами следующими комбинациями доступа к экземплярам классов: создание (Create), чтение (Read), обновление (Update) или удаление (Delete).
Таким образом описываются все прецеденты, которые выполняют создание, чтение, обновление или удаление одного или нескольких экземпляров класса.
В качестве примера приведу опыт построение CRUD-матрицы в 2007-2008гг. при планировании разработки автоматизированной библиотечной информационной системы для научно-технической библиотеки (далее АБИС НТБ).

Анализ CRUD-матрицы производится в семь шагов:
1.Проверка полноты построения модели
2.Определение зависимостей
3.Определение пакета типовых работ для разработки
4.Оценка времени, необходимого для разработки
5.Проверка модели на непротиворечивость
6.Определение последующей работы и дополнений функционала
7.Определение приоритетов для разработки и поставки

Шаг 1. Проверка полноты построения модели

На основе CRUD-матрицы проверяется полнота построения модели на предмет целесообразности использования классов или прецедентов в разрабатываемой системе.
К примеру, в рамках перечисленных прецедентов не описано создание или удаление класса “Книжный формуляр”. Данный факт может конечно говорить о том, что “Книжный формуляр” создается и удаляется вне разрабатываемой системы или же о том, что Agile-аналитик не описал прецедент “регистрация книги” или “списание книги”, а для этого нужно ввести еще один класс “инвентарная книга”.

Шаг 2. Определение зависимостей

При планировании процесса разработки системы CRUD-матрица помогает определить перечень классов, которые разрабатываются в первую очередь, чтобы покрыть максимальное количество прецедентов. Например, для разработки АБИС НТБ прецедент “регистрация читателя” будет реализован первым, потому что класс читатель согласно CRUD-матрицы используется в 8 прецедентах, в отличие от класса “бронь”. Таким образом определяются нужные и актуальные данные.

Шаг 3. Определение пакета типовых работ для разработки

CRUD-матрица помогает определить типовую реализацию и выявить дублирование функционала в системе. К примеру, класс “книжный формуляр” реализуется по типу класса “библиотекарь” и соответственно времени на реализацию класса “книжный формуляр” потребуется меньше. Таким образом, сокращается время разработки системы.

Шаг 4. Оценка времени, необходимого для разработки

CRUD-матрица предоставляет Agile-команде простой механизм для оценки времени, необходимого для разработки и тестирования определенной части функциональности.
В первом приближении производится оценка каждой комбинации доступа, а затем производится оценка каждого прецедента. К примеру, создание нового экземпляра класса требуется в 4 прецедентах, чтение информации об экземпляре класса в 7 случаях, в 16 случаях требуется обновлять информацию экземпляра класса, а в 6 случаях необходимо удалять экземпляр класса. Используя плановое время на разработку каждой комбинации доступа формируется таблица сложности реализации каждого класса, а также системы в целом:

В случае необходимости, аналитик может ранжировать не только сложность реализации каждого класса, но и каждого прецедента.
Что касается 53 дней, то этот срок уменьшается за счет типовых работ, а именно реализации классов “библиотекарь” и “книжный формуляр”. Для обеспечения более реалистичной оценки на будущее можно использовать фактические значения собранные на основе статистического анализа процессов реализации подобного функционала в предыдущих проектах. В любом случае, последнее слово должно быть за Agile-командой, ведь никакая статистика не поможет в разработке системы, а иногда даже мешает Agile-команде корректно оценить свои возможности.

Шаг 5. Проверка модели на непротиворечивость

В процессе итеративного развития CRUD-матрицы обеспечивается согласованность между прецедентами и теми моделями, которые являются основой разработки и поставки решений. Например, в рамках модели могут быть классы, которые не используются ни в одном прецеденте, что может являться снижением производительности системы, а следовательно это может напрямую повлиять на удовлетворённость клиента. Таким образом, решение, при разработке которого использовалась технология CRUD-матрицы, будет максимально непротиворечивым, что является хорошей основой для разработки.

Шаг 6. Определение последующей работы и дополнений функционала

В CRUD-матрице описываются все ответные действия системы по каждому прецеденту, что позволяет разработчику увидеть работу всей системы в целом. На базе CRUD-матрицы Agile-аналитик, в случае необходимости, может проводить уточнение модели и строить диаграммы последовательности, диаграммы коммуникации, диаграммы обзора взаимодействия или диаграммы синхронизации. Также CRUD-матрица может использоваться дизайнером при проектировании интерфейсов или архитектором решений для разработки продуктовой спецификации. Таким образом CRUD-матрица служит хорошим инструментом для каждого члена Agile-команды на протяжении всего жизненного цикла продукта.

Шаг 7. Определение приоритетов для разработки и поставки

CRUD-матрица позволяет клиентам адекватно оценить приоритеты в реализации какой-либо функциональности, и не позволит переместить её реализацию на следующую итерацию. Например, прецеденты “выдача читательского билета” и “перерегистрация читателя” не могут быть поставлены полностью до тех пор пока не будут разработаны классы: читатель, читательский билет и библиотекарь.

Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом (заказчиком) и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин. Что касается комбинаций доступа к экземплярам класса, то тут не обязательно использовать именно CRUD-комбинацию, возможны и другие комбинации, например такие: REST, RESTful, GET-PUT-POST-DELETE и др.

Источник

Поделиться с друзьями
Компьютеры и приложения