Бизнес-правила

Cтраница 3

Важная часть процесса разработки, которая выполняется на фазе построения и занимает большую часть времени разработчика - заполнение описаний прикладного программного текста. Хотя генераторы Oracle Designer облегчают труд разработчика, делая все возможное при выполнении стандартных операций и компоновки, тем не менее необходимость в написании программ для реализации бизнес-правил остается. Как правило, подавляющее большинство программных конструкций создается на сервере с использованием хранимых пакетов ( процедур, функций и переменных) PL / SQL и вызывающего их триггерного программного текста. При этом разработчику остается написать небольшой программный текст для выполнения действий, специфичных для данного инструментального средства. Так, в модуле формы Oracle Developer может понадобиться прикладная программная конструкция для перемещения по блоку и для установления свойств записи на основании значения конкретного элемента. Такую конструкцию нежелательно ( а может быть и невозможно) применять в качестве серверной, поэтому нужно создать прикладную логическую схему для выполнения операции в библиотеке или форме. В любом случае создается программный текст ( протестированный или нет), который заносится в репозиторий. [31]

Как видно из предшествующей главы, для успешной разработки системы нужно фиксировать огромный объем информации. Отсутствие информации может вызвать крах проекта или, по крайней мере, невыполнение некоторого предназначения системы. Кроме того, игнорирование информации о требованиях или неучтенные бизнес-правила вызовут неточности в работе системы, которые могут серьезно повлиять на применение системы на практике. Следовательно, для успешной разработки системы нужно хранить информацию о ней там, откуда ее легко извлечь или где ее легко модифицировать. [32]

Аналитическая ERD - это компактное представление большинства ( часто сотен) связанных с данными бизнес-требований. Аналитическая ERD не должна рассматривать быстродействие системы или ее производительность. Цель ее создания состоит в фиксации наибольшего количества бизнес-правил: чем больше их отражено, тем лучше. Аналитическая ERD является основой документа о требованиях. [33]

Распределенные приложения, построенные с использованием Web Services, обеспечивают интеграцию приложений различных участников единого бизнес-процесса. Например, имеется компания, производящая некоторый продукт, компании, являющиеся ее поставщиками и компании-клиенты. Все эти компании имеют свои информационные системы, свои базы данных, свои бизнес-правила. Для организации эффективной совместной работы необходимо интегрировать приложения различных компаний в единую систему. [34]

В идеале ERD должна отразить все бизнес-правила для данных. Однако некоторые правила могут быть выражены только в текстовой форме. Следовательно, аналитическая ERD не будет полной, если к ней не прилагается текстовое описание явных бизнес-правил, не отраженных на диаграмме. [35]

Диаграммы взаимосвязи объектов служат для общения с пользователями разрабатываемой системы и для анализа этой системы. Поэтому нужно четко представлять себе правила чтения таких диаграмм. Большинство людей легко понимают концепцию элементов диаграммы, поэтому основной акцент при объяснениях нужно делать на связях, которые могут иногда представлять очень сложные бизнес-правила. [36]

Панель трансформации таблиц ( Transforms. [37]

Денормализация, как правило, проводится на физическом уровне модели. ERwin позволяет сохранить на логическом уровне нормализованную структуру, при этом построить на уровне физическом структуру ( возможно, денормализованную), которая обеспечивает лучшую производительность, используя особенности конкретной СУБД и бизнес-правил предметной области. [38]

Трудно вообразить, почему разработчик в добром здравии и здравом уме хотел бы создать невидимый класс. Настраиваемые пользовательские классы состоят из кодов, а не визуальных компонентов. Они обычно используются для определения бизнес-правил или некоторых других стандартных методов обработки. [39]

Бизнес-правила, которые не могут быть зафиксированы внутри модели, обсуждаются отдельно. Нужно определить все ошибочные места в модели. В процессе моделирования всегда появляются интересные решения. Часто на ранних стадиях работы принимается решение не включать в модель данных некоторые бизнес-правила из-за чрезмерной сложности, которую они добавили бы к модели. Все такие решения должны быть рассмотрены повторно и защищены во время аудита модели. [40]

Адреса теперь не пишутся от руки, а печатаются на клавиатуре, поэтому неправильная доставка практически исключена. Взаимодействие с поставщиками полностью документируется, расходы известны заранее, так что неприятные неожиданности исключаются. Кроме того, оплата поставщикам поступает быстрее, и это стимулирует их более оперативно доставлять заказы. Бизнес-правила встраиваются в систему еще при разработке, так что, например, заказ с неправильным ко-дом татьи расходов просто не будет принят. Это позволяет нашей финансовой группе избавиться от многочасового поиска ошибок в учетных записях. [41]

Ограничения, создаваемые с использованием выражений SQL, могут быть назначены либо в отношении всего набора данных, либо в отношении отдельных полей. Провайдер передает ограничения клиенту вместе с данными, и клиент применяет эти ограничения перед тем, как отправить модифицированные данные обратно на сервер. Благодаря этому снижается общий объем сетевого трафика: если бы клиент не выполнял проверку ограничений, модифицированные пользователем данные передавались бы среднему звену, а затем SQL-серверу, и только на SQL-сервере обнаруживалось бы, что данные не удовлетворяют ограничениям. Таким образом, хранить ограничения следует на стороне сервера, однако обработка ограничений должна выполняться не только на стороне сервера, но и на стороне клиента. Если информация об ограничениях хранится на сервере, то в случае изменения бизнес-правил вам потребуется модифицировать код только на сервере. [42]

По открытой статистике в среднем в организации только 20 % времени тратится на выполнение операций, а 80 % - на передачу результатов из подразделения в подразделение или между сотрудниками внутри. Таким образом, организация больше времени тратит на клей при передаче промежуточных результатов, нежели на сами результаты. Проблемы, как правило, решаются по мере возникновения, что само по себе не эффективно. Иными словами, на достижение целей сильно влияет уровень организации и характер исполнения работ. Возможен, конечно, способ постоянного личного контроля со стороны руководителя работы исполнителей, но он очень трудоемок, да и негативные последствия даже после вмешательства руководителя не всегда удается свести к нулю. Гораздо предпочтительнее смотрится системное упорядочивание отдельных действий в бизнес-процессы и выработка единых бизнес-правил, что вместе реализуется технологией процессного управления. Процессное управление имеет целый ряд преимуществ: заставляет думать всех в терминах конечных результатовлзсей организации, повышает предсказуемость и устойчивость бизнеса, точность планирования, сокращает операционные издержки, оптимизирует использование ресурсов, повышает производительность труда, уменьшает зависимость от персонала. [43]

Объекты в ERD не являются простыми описаниями. Они представляют собой важные и интересные для организации специфические единицы, сведения о которых предстоит хранить в системе. Например, не является объектом демографическая информация. Хорошие имена объектов облегчают связывание с бизнес-требованиями. Нужны точные и аккуратные определения объектов. Хорошие определения взаимосвязей между объектами не менее важны, поскольку они отражают бизнес-правила. [44]

Страницы: 1 2 3