Лекции Проектирование информационных систем |
Проектирование информационных систем
Основы методологии проектирования ИС
2.Жизненный цикл ИС 3. Модели жизненного цикла ПО 4. Общие требования к методолошии и технологии 5.Методология RAD Структурный подход к проектированию ИС 6.Сущность структурного подхода 7.Методология фунционального моделирования SADT 7.1.Состав функциональной модели 7.2.Иерархия диаграмм 7.3.Типы связей сежду функциями 8.Моделирование потоков данных(процессов) 8.1.Внешние сущности 8.2.Системы и подсистемы 8.3.Процессы 8.4.Накопители данных 8.5.Потоки данных 8.6.Построение иерархии диаграмм потоков данных 9.Моделирование данных. Case-метод Баркера 10.Моделирование данных. Методология IDEF 1 Характеристики CASE-средств 11.Silverrun 12.JAM 13.Vantage Team Builder (Westmount I-CASE) 14.Unifase 15.Designer/2000+Developer/2000 16.Локальные средства(ERwin, BPwin,S-Designor,CASE.Аналитик) 17.Объектно-ориентированные CASE-средства (Rational Rose) Вспомогательные средства поддержки жизненного цикла ПО 18.Средства конфигурационного управления 19.Средства документирования 20.Средства тестирования Заключение 21.Примеры комплексов CASE-средств |
Структурный
подход к проектированию ИС 8.6.Построение иерархии диаграмм потоков данных. Первым шагом при построении иерархии ДПД является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: · наличие большого количества внешних сущностей (десять и более); · распределенная природа системы; · многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС. Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков. После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или миниспецификации. При детализации должны выполняться следующие правила: · правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; · правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д. Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев: · наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); · возможности описания преобразования данных процессом в виде последовательного алгоритма; · выполнения процессом единственной логической функции преобразования входной информации в выходную; · возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк). При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений. После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны. |
| Contact Us | ©2005 StudentCompany |