Диаграммы потоков данных (DFD-диаграммы), их использование при моделировании предметной области.

Диаграммы потоков данных

· Эти диаграммы (Data flow diagramming, DFD) хорошо дополняют функциональные диаграммы модели, описывая потоки данных.

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

· Используются для описания документооборота, обработки информации

Преимущества DFD-диаграмм:

· DFD-диаграммы создавались как средство проектирования программных систем, тогда как IDEF0 - как средство проектирования систем вообще.

· DFD имеют более богатый набор элементов, адекватно отражающих специфику программных систем (например, хранилища данных являются прообразами файлов или баз данных).

· С помощью DFD-диаграмм требования к проектируемой ИС разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных.

· Главная цель декомпозиции DFD-функций - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

На DFD-диаграммах могут присутствовать следующие cинтаксические элементы:

Цели и задачи этапа проектирования. Стадии проектирования, их краткая характеристика.

· Цель этапа проектирования - построение модели разрабатываемого программного продукта, удовлетворяющей спецификации требований.

· В процессе проектирования разрабатывается логика решения проблем, выявленных на этапе системного анализа.

Результатом этапа проектирования является проект – набор документов, описывающих модель, а также ряд сопутствующих документов (детальные планы работ, экономические расчеты и т.д.).

Стадии проектирования

· Проектирование может выполняться как «вручную», так и с использованием различных средствами автоматизации

· Обычно выделяют три стадии проектирования:

1. Эскизное проектирование

· Разрабатываемый программный продукт рассматривается как часть системы обработки информации, включающей аппаратную и программную составляющие;набор взаимодействующих подсистем

· на этой стадии определяется архитектура системы;

· Обеспечивает:

- -идентификацию подсистем

- -определение характера взаимодействия подсистем и принципов управления ими

· Включает три типа деятельности:

- -структурирование системы

- -моделирование управления

- -декомпозиция подсистем на модули

· Результаты эскизного проектирования представляются в виде эскизного проекта (Software Architecture Document).

· Стадия эскизного проектирования не является строго обязательной и может быть исключена, если основные проектные решения определены ранее или достаточно очевидны.

2. Детальное проектирование

· На стадии детального проектирования конкретизируются решения архитектурного уровня и производится:

- -разработка иерархии классов и структуры базы данных;

- -построение алгоритмов для отдельных подзадач;

- -поиск и подбор готовых компонентов для реализации некоторых функций системы

3. Интерфейсное проектирование

· Целью интерфейсного проектирование является формирование интерфейса пользователя

· Пользовательский интерфейс объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на его взаимодействие с программным обеспечением.

Задачи, решаемые на стадии эскизного проектирования.

· Разрабатываемый программный продукт рассматривается как:

- -часть системы обработки информации, включающей аппаратную и программную составляющие

- -набор взаимодействующих подсистем

· На этой стадии определяется архитектура системы.

Под архитектурой ПСпонимают набор ее внутренних структур, которые видны с различных точек зрения и состоят из:

- -компонентов (достаточно произвольный структурный элемент ПС, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает)

- -связей и возможных взаимодействий между компонентами,

- доступных извне свойств этих компонентов

Эскизное проектирование обеспечивает:

- -идентификацию подсистем

- -определение характера взаимодействия подсистем и принципов управления ими

Включает три типа деятельности:

- -структурирование системы

- -моделирование управления

- -декомпозиция подсистем на модули

Результаты эскизного проектирования представляются в виде эскизного проекта (Software Architecture Document).

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

Понятие архитектуры ПС. Проблема выбора архитектуры. Влияние архитектуры на качественные характеристики ПС.

Под архитектурой ПСпонимают набор ее внутренних структур, которые видны с различных точек зрения и состоят из

- -компонентов,

- -связей и возможных взаимодействий между компонентами,

- -доступных извне свойств этих компонентов.

Под компонентом понимается достаточно произвольный структурный элемент ПС, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает.

Роль архитектуры:

· Выбор архитектуры ПС задает способ реализации требований на высоком уровне абстракции.

· Архитектура ПС почти полностью определяет его:

- -надежность,

- -переносимость,

- -удобство сопровождения.

· Архитектура ПС значительно влияет на:

- -удобство использования (эргономичность),

- -эффективность.

· Эти характеристики, однако, сильно зависят и от реализации отдельных компонентов.

· Значительно меньшее влияние архитектура оказываетна функциональность – заданную функциональность можно реализовать, использовав совершенно различные архитектуры.

· Выбор архитектурного решения основан на компромиссе между требованиями к различным характеристикам ПС.

Модели системного структурирования, их характеристики.

Структурирование системы

· Система структурируется на несколько подсистем, являющихся относительно независимыми программными компонентами.

Модели структурирования:

· Наиболее часто используются 3 модели системного структурирования (архитектуры):

- -модель хранилища данных

- -модель клиент-сервер

- -многоуровневая модель.

Модель хранилища данных:

· Подсистемы разделяют данные, находящиеся в общей памяти и, как правило, представляющие собой базу данных.

· Модель применима, если основные функции системы связаны с хранением, обработкой и представлением больших объемов данных.

Модель клиент-сервер:

· Решаемые задачи естественно распределяются между инициаторами и обработчиками запросов; возможно изменение внешнего представления данных и способов их обработки.

· Используется для распределенных систем и в большинстве бизнес-приложений.

Многоуровневая модель:

· Имеется естественное расслоение задач системы на наборы подзадач, которые можно решать последовательно

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

Понятие модуля и модульного программирования. Преимущества модульного подхода к разработке ПО.

Модульные компоненты

· Одним из основных способов разбиения системы на компоненты являетсямодульная декомпозиция.

· Программное средство представляется как набор программных модулей.

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

Обычно модули проектируются таким образом, чтобы предоставлять программистам удобную для многократного использования функциональность (интерфейс) в виде набора функций, классов, констант.

Модули могут объединяться в пакеты и, далее, в библиотеки.

Модульная декомпозиция

· может осуществляться на основе:

· -модели потока данных

· -модели объектов

· В основе модели потока данных лежит разбиение по функциям.

· Модель объектов основана на сущностях, имеющих собственные наборы данных, состояния и наборы операций.