Диаграммы потоков данных как инструмент описания требований заказчика

Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD (как было сказано выше) – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).

Цель построения DFD-диаграмм – общение с заказчиком и пользователями, уточнение требований к системе, передача знаний о предметной области от системных аналитиков к разработчикам автоматизированной системы.

На DFD-диаграмме должно быть не меньше двух и не больше шести процессов/подсистем.

Принцип абстракции (отвлечения от деталей). Для подсистем и процессов строится иерархия DFD-диаграмм. На каждой диаграмме должны быть представлены только основные процессы, важные на данном уровне рассмотрения. На диаграммах нужно абстрагироваться от несущественных пока деталей, нюансов работы и т.д.

Материальные процессы, потоки и хранилища на диаграммах DFD не отображаются (только процессы обработки информации, потоки данных и хранилища данных).

Сначала должны быть рассмотрены функции (процессы), затем данные (хранилища), необходимые для выполнения этих функций. Подход «от данных к функциям» запрещен.

Не должно быть связей между внешними сущностями. Во внешних сущностях не должно быть обработки информации.

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

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

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

Элементарные процессы на диаграммах DFD не детализируются.

На диаграммах DFD не должно быть изолированных (несвязанных) объектов (внешних сущностей, подсистем, процессов, хранилищ данных).

WEB-дизайн.

Технология шаблонов (templates) при разработке веб-приложений (подготовка макета веб-сайта и его реализация, основные структурные элементы шаблона, блоки, примеры реализации в cms и framework).

Чтобы создать страницу Plone сайта используется три технологии. На стороне сервера скрипты python и шаблоны страницы создают код HTML, который отсылается браузеру. Там, каскадные стилевые таблицы (CSS) придают окончательный вид странице.

Zope поставляется с двумя системами шаблонов DTML и ZPT (Zope Page Templates). DTML считается устаревающей и в дальнейшем поддерживаться не будет. Шаблоны страниц используют Template Attribute Language (TAL) - язык описания атрибутов, заключающийся в добавлении специальных атрибутов в тэг.

Для примера, заголовок динамической странице выглядит подобно этому:

<title tal:content="here/title">Page Title</title>

Здесь tal:content атрибут является оператором TAL. Он имеет XML пространство имен (часть tal:), большинство инструментов редактирования не считают его ошибочным потому что не знают его, и соответственно не удаляют этот атрибут. Этот атрибут не изменяет структуру или внешний вид шаблона при загрузке его в WYSIWYG редактор или в веб браузер. Имя content указывает на то что данный атрибут устанавливает содержимое тэга title и его значение "here/title" является выражением, предоставляющим текст для вставки внутрь тэга.

Когда эти шаблоны сохраняются в Zope и просматриваются пользователем, Zope превращает этот статический контент в динамический и заменяет "Page Title" каким-либо найденным значением "here/title". В данном случае "here/title" принимает значение title объекта, который обращается к данному шаблону. Эта замена происходит динамически, когда шаблон становиться представлением. Этот пример также демонстрирует второй принцип. Когда вы видите шаблон в редакторе, текст заголовка работает как заменитель динамического текста заголовка. Этот шаблон представляет собой пример генерации документов.

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

Этот язык шаблонов не является самостоятельным языком программирования. Он основывается на использовании внутри каркасов программирования (framework)(таких как Zope), в которых другие объекты обрабатывают бизнес логику и задачи, не имеющие отношения к разметке страницы. Для создания действующего шаблона, его желательно, поместить в custom и вставить объект Page Template. После создания объекта Вы получите почти пустую страницу.