Базовые информационные технологии и процессы. И процессы
 Скачать 2.47 Mb.
|
|
4.5 Моделирование потоков данных (процессов) Рассмотрим методологию Гейна – Сарсона. В ее основе лежит построение модели анализируемой ИС – проектируемой или реально существующей. В со- ответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобра- зования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные про- цессы или подсистемы ИС с внешними входами и выходами. Они детализиру- ются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достиг- нут такой уровень декомпозиции, на котором процессы становятся элементар- ными и детализировать их далее невозможно. Источники информации (внешние сущности) порождают информацион- ные потоки (потоки данных), переносящие информацию к подсистемам или про- цессам. Те в свою очередь преобразуют информацию и порождают новые пото- ки, которые переносят информацию к другим процессам или подсистемам, нако- пителям данных или внешним сущностям – потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: внеш- ние сущности; системы/подсистемы; процессы; накопители данных; потоки дан- ных. Внешняя сущность представляет собой материальный предмет или физи- ческое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение неко- торого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа не- 100 которые внешние сущности могут быть перенесены внутрь диаграммы анализи- руемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рис. 4.5), расположенным как бы над диаграммой и бросающим на нее тень для того, чтобы можно было выде- лить этот символ среди других обозначений: Заказчик Рис. 4.5 – Внешняя сущность Система и подсистема. При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диа- грамме в виде одной системы как единого целого либо может быть декомпози- рована на ряд подсистем. Подсистема (или система) на контекстной диаграмме изображается следующим образом (рис. 4.6). Подсистема обслуживания клиентов 1 Поле номера Поле имени Поле имени проектировщика Рис. 4.6 – Изображение подсистемы Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствую- щими определениями и дополнениями. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс мо- жет быть реализован различными способами: это может быть подразделение ор- ганизации (отдел), выполняющее обработку входных документов и выпуск отче- тов, программа, аппаратно реализованное логическое устройство и т. д. Процесс на диаграмме потоков данных изображается, как показано на рисунке 4.7. 101 Рассчитать остаток средств 1.1 Поле номера Поле имени Поле физической реализации Рис. 4.7 – Изображение процесса Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным гла- голом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном па- деже, например: «Ввести сведения о клиентах»; «Выдать информацию о текущих расходах»; «Проверить кредитоспособность клиента». Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать» означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа. Информация в поле физиче- ской реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс. Накопитель данных представляет собой абстрактное устройство для хра- нения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на маг- нитном носителе и т. д. Накопитель данных на диаграмме потоков данных изоб- ражается, как показано на рисунке 4.8. D 1 Получаемые счета Рис. 4.8 – Накопитель данных Накопитель данных идентифицируется буквой D и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информа- ционной моделью. 102 Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть ин- формацией, передаваемой по кабелю между двумя устройствами, пересылае- мыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой. Поток данных на диаграмме изображается линией, оканчивающейся стрел- кой, которая показывает направление потока (рис. 4.9). Каждый поток данных имеет имя, отражающее его содержание. Руководство Вывести отчет о продажах Отчет о продажах Бухгалтерия 1.5 Рис. 4.9 – Поток данных Первым шагом при построении иерархии ДПД является построение кон- текстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с при- емниками и источниками информации, посредством которых с системой взаимо- действуют пользователи и другие внешние системы. Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нор- мального формата, и, кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контек- ста) могут быть: наличие большого количества внешних сущностей (десять и более); распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом кон- текстная диаграмма верхнего уровня содержит не единственный главный про- цесс, а набор подсистем, соединенных потоками данных. Контекстные диа- граммы следующего уровня детализируют контекст и структуру подсистем. 103 Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внеш- ними входными и выходными потоками данных и внешними объектами (источ- никами и приемниками информации), с которыми взаимодействует ИС. Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке кото- рых участвуют разные организации и коллективы разработчиков. После построения контекстных диаграмм полученную модель следует про- верить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД в свою очередь может быть детализирован при помощи ДПД или мини-спецификации. При детализации должны выполняться следующие правила: правило балансировки означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источни- ков/приемников данных может иметь только те компоненты (подси- стемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; правило нумерации означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, де- тализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т. д. Мини-спецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выпол- няющий реализацию проекта, смог выполнить их или разработать соответству- ющую программу. Мини-спецификация является конечной вершиной иерархии ДПД. Реше- ние о завершении детализации процесса и использовании мини-спецификации принимается аналитиком исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); возможности описания преобразования данных процессом в виде по- следовательного алгоритма; 104 выполнения процессом единственной логической функции преобразо- вания входной информации в выходную; возможности описания логики процесса при помощи мини-специфика- ции небольшого объема (не более 20-30 строк). При построении иерархии ДПД переходить к детализации процессов сле- дует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных констру- ируются из элементов данных и могут содержать альтернативы, условные вхож- дения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может вхо- дить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т. п.), диапазон значе- ний, точность представления и форма физического кодирования. Для дискрет- ных данных может указываться таблица допустимых значений. После построения законченной модели системы ее необходимо верифици- ровать (проверить на полноту и согласованность). В полной модели все ее объ- екты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные не детализированные объекты следует детализи- ровать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть счи- таны, а все считываемые данные должны быть записаны. 4.6 Моделирование данных Цель моделирования данных состоит в обеспечении разработчика ИС кон- цептуальной схемой базы данных в форме одной модели или нескольких локаль- ных моделей, которые относительно легко могут быть отображены в любую си- стему баз данных. Логическая структура данных СУБД, иерархическая, сетевая или реляци- онная, не может полностью удовлетворять требованиям к концептуальному определению данных, поскольку она имеет ограниченные рамки и обусловлива- ется стратегией реализации СУБД. Необходимость определения данных с кон- цептуальной точки зрения привела к разработке методологии моделирования данных, основанной на семантике, то есть к трактовке данных в контексте их 105 взаимосвязей с другими данными. Семантическая модель данных является аб- страктной схемой, доказывающей, как хранящиеся символы соотносятся с реаль- ным миром, т. е. такая модель должна быть верным отражением реального мира. Семантическая модель данных может применяться в различных целях. Укажем важнейшие из них: 1. Планирование ресурсов данных. Предварительная модель данных по- могает при выработке широкого взгляда на данные, необходимые для деятельности предприятия. Затем эта модель может быть исследована для построения совместно используемых ресурсов данных. 2. Построение совместно используемых баз данных. Полностью разрабо- танная модель может применяться для представления данных незави- симо от их конкретного использования. Это представление может быть проверено пользователями и затем преобразовано в физический проект базы данных для любой из различных технологий СУБД. Помимо того что разработанные базы данных будут непротиворечивыми и сов- местно используемыми, моделирование данных существенно сократит затраты на разработку. 3. Оценка покупаемого программного обеспечения. Модель данных, отра- жающая действительную инфраструктуру организации, позволяет оце- нить, насколько покупаемое программное обеспечение соответствует модели данных компании и не противоречит ли инфраструктура, нала- гаемая программным обеспечением, способу ведения дел компании. 4. Объединение существующих баз данных. Определив содержание су- ществующих баз данных через семантические модели данных, можно получить интегрированное определение данных. Концептуальная схе- ма может использоваться для управления обработкой запросов в среде распределенной базы данных. Наиболее распространенным средством моделирования данных являются диаграммы «сущность – связь» (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. Нотация ERD была впервые введена П. Ченом (Chen) и получила дальней- шее развитие в работах Баркера. Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на под- ходе П. Чена и позволяет построить модель данных, эквивалентную реляционной 106 модели в третьей нормальной форме. В настоящее время на основе совершен- ствования методологии IDEF1 создана ее новая версия – методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и воз- можность автоматизации. IDEF1X-диаграммы используются рядом распростра- ненных CASE-средств (в частности, ERwin, Design/IDEF). 4.7 Общая характеристика и классификация CASE-средств Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном мас- штабе времени, использование многообразной цветовой палитры, сквозную про- верку синтаксических правил. Графические средства моделирования предмет- ной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и до- рогостоящие системы для неоднородных вычислительных платформ и операци- онных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе ис- пользуются практически всеми ведущими западными фирмами. Обычно к CASE-средствам относят любое программное средство, автома- тизирующее ту или иную совокупность процессов жизненного цикла ПО и обла- дающее следующими основными характерными особенностями: мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС; 107 использование специальным образом организованного хранилища про- ектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживаю- щих полный ЖЦ ПО) содержит следующие компоненты: репозиторий, являющийся основой CASE-средства. Он должен обеспе- чивать хранение версий проекта и его отдельных компонентов, синхро- низацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиво- речивость; графические средства анализа и проектирования, обеспечивающие со- здание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС; средства разработки приложений, включая языки 4GL и генераторы ко- дов; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга. Все современные CASE-средства могут быть классифицированы в основ- ном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по ка- тегориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные за- дачи (tools), набор частично интегрированных средств, охватывающих большин- ство этапов жизненного цикла ИС (toolkit) и полностью интегрированные сред- ства, поддерживающие весь жизненный цикл ИС и связанные общим репозито- рием. Помимо этого CASE-средства можно классифицировать по следующим признакам: применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы: 108 средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works)); средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использу- ющиеся для создания проектных спецификаций. Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE); средства разработки приложений; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. В области анализа программных кодов наи- большее распространение получают объектно-ориентированные CASE- средства, обеспечивающие реинжиниринг программ на языке С++ (Ra- tional Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают: средства планирования и управления проектом (SE Companion, Micro- soft Project и др.); средства конфигурационного управления; средства тестирования; средства документирования. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · Контрольные вопросы по главе 4 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 1. Какие основные задачи призваны решать CASE-технологии? 2. В чем сущность структурного подхода к проектированию ИС? 3. Вспомните основные элементы методологии SADT. 4. Из чего состоит функциональная модель в методологии SADT? 5. Приведите основные положения методологии моделирования потоков данных Гейна – Сарсона. |