Методы, средства и способы моделирования и проектирования информационных систем

Лекция 1 Методы, средства и способы моделирования и проектирования информационных систем Методы проектирования ИС Методы проектирования ИС можно классифицировать - по уровню автоматизации, - по степени использования типовых проектных решений, - по использованию подхода (методологии) к проектированию. По степени автоматизации методы проектирования разделяются на: ■ методы ручного проектирования, при котором проектирование ИС осуществляется без использования специальных инструментальных средств; ■ методы автоматизированного проектирования, при котором производится генерация или настройка проектных решений на основе использования специальных инструментальных средств. По степени использования типовых проектных решений различают: ■ индивидуальное проектирование, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к ИС; ■ типовое проектирование, предполагающего сборку или конфигурацию ИС из готовых типовых компонентов. По использованию подхода (методологии) к проектированию различают: ■ Структурный подход – раздельное построение модели функций (чаще всего диаграммы потоков данных) и модели данных (чаще всего диаграммы "сущность - связь"). К сожалению, единой нотации и правил построения этих моделей не существует. ■ Объектный подход – содержит набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение. Нередко структурный и объектный подходы противопоставляют друг другу. Во многом это результат конкуренции производителей технологий и инструментальных средств. Однако пользователям продуктов и методик такое противопоставление ничего, кроме вреда, не приносит. Сами по себе наборы моделей не определяют принципов построения систем, являясь лишь средством описания объектов автоматизации. Другая распространенная ошибка – связывание структурного подхода с функциональной декомпозицией программного обеспечения. Диаграмма потоков данных является моделью, использующей декомпозицию функций, но эта декомпозиция является лишь способом разбиения модели на уровни детализации и не влияет на способ структуризации программного обеспечения. Модели структурного подхода к проектированию информационных систем В рамках структурного подхода выделяются следующие средства моделирования [11]: ■ диаграмма потоков данных/модель бизнес-процессов (Data Flow Diagram/Business Process Model) (средство описания процессов обработки информации). Для описания бизнес-процессов организации достойной альтернативы диаграмме потоков данных пока не найдено. Однако эта модель обладает рядом недостатков, самым главным из которых, пожалуй, является невозможность показать последовательность выполнения функций, если они входят в несколько бизнес-процессов; ■ диаграмма «сущность – связь» (Entity Relationship Diagram) (описание информационной модели предметной области, не привязанное к инструментам реализации структур хранения данных в компьютерной системе); ■ диаграмма переходов состояний (State Transition Diagram) (документирование состояний программных конструкций, экранов, каналов связи); ■ структурная карта (Structure Chart) (отображение взаимного вызова функций в процессе выполнения программы); ■ диаграмма вариантов использования (удобна для описания функциональности системы, каждый вариант использования – определенный сервис, который должна обеспечить система); ■ блок-схема (Flow Chart) (алгоритмы выполнения процедур). Модели объектного подхода к проектированию информационных систем В настоящее время наиболее естественным является применение набора моделей, входящих в UML (от англ. Universal Modeling Language –универсальный язык моделирования), так как этот язык стандартизирован, широко используется и постоянно развивается. UML разработан компанией Rational Software с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели системы к логической, а затем и к физической модели соответствующей системы. Любая задача, таким образом, моделируется при помощи некоторого набора иерархических диаграмм, каждая из которых представляет собой некоторую проекцию системы. Диаграмма (Diagram) – это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями). Прекращение "войны методов" и объединение ведущих специалистов привело к открытости и стандартной интерпретации моделей. Стандарт UML открыт для обсуждения и развивается при участии ведущих технологических фирм: Rational Software, Microsoft, Hewlett-Packard, Oracle, IBM, Platinum Technology и других. В UML определено восемь видов диаграмм [1]: • диаграмма видов деятельности (или диаграмма деятельности, диаграмма действий) (Activity diagram) - диаграмма поведения, на которой подчеркнуты переходы потока управления от одной деятельности к другой; • диаграмма классов (Class diagram) - структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношения между ними; • диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношения между ними; • диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показано поведение объектов с точки зрения порядка получения событий; • диаграмма последовательностей (Sequence diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий; • диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения; • диаграмма компонентов (Component diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий • диаграмма развертывания (Deployment diagram) - структурная диаграмма, на которой показаны узлы и отношения между ними. Основное направление объектного подхода – анализ бизнес-операций. Способы моделирования информационных систем - функциональное моделирование (IDEF0); - реляционное моделирование (IDEFI, IDEFIX); - описание бизнес-процессов (IDEF3); - диаграммы потоков данных (DFD); - объектно-ориентированное моделирование. IDEF – от англ. Integrated Computer-Aided Manufacturing – интегрированное автоматизированное производство. IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения (ракурса). Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF). Этапы проектирования информационных систем Проектирование ИС охватывает три основные области: ■ проектирование объектов данных, которые будут реализованы в базе данных; ■ проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным; ■ техническое проектирование с учетом конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных. На этапе проектирования, прежде всего, формируются модели данных. При этом построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных. Типовые проектные решения для информационных систем ■ элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному); ■ подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей; ■ объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС. Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы. Основным достоинством элементарных ТПР, которые используются, в первую очередь, для реализации библиотек методо-ориентированных программ, является обеспечение применения модульного подхода к проектированию и документированию ИС, а недостатки - большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости, а также большие затраты времени на доработку ТПР отдельных элементов. Подсистемные ТПР применяются для реализации пакетов прикладных программ. Их несомненными достоинствами является возможность достижения высокой степени интеграции элементов ИС, осуществления модульного проектирования, параметрической настройки компонентов на различные объекты управления, сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации. Тем не менее, адаптивность ТПР недостаточна с позиции непрерывного инжиниринга деловых процессов, возникают проблемы в комплексировании разных функциональных подсистем, особенно в случае использования решений нескольких производителей программного обеспечения. Для отраслевых проектов ИС используются объектные ТПР. Их достоинства: комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости; открытость архитектуры; масштабируемость и конфигурируемость. Однако существует проблема привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации. Модели данных в информационных системах Существуют два уровня представления модели: ■ логический; ■ физический. Логический уровень – это абстрактный взгляд на данные, но данные представляются так, как выглядят и могут называться так, как они называются в реальном мире, например, "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например, на основе модели процессов. Отметим, что логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Заключение Необходимо совершенствование процесса проектирования ИС и структурирования информационного пространства как объекта автоматизации с целью обеспечения функциональных требований как к самой ИС, так и к характеристикам процесса ее разработки. Основные задачи, решению которых должна способствовать методология проектирования корпоративных ИС: • обеспечение создания корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика; • создание системы с заданным качеством в заданные сроки и в рамках установленного бюджетирования; • поддержка удобных механизмов сопровождения, модификации и наращивания системы; • обеспечение преемственности разработки. Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, повышения качества постановки задачи, а также применения современных методов и технологий создания ИС на всем жизненном ее цикле. Письменное задание к лекции 1 1) Письменно ответить на вопрос: чем структурный подход проектирования ИС отличается от объектно-ориентированного подхода? Привести примеры инструментальных средств обеспечения этих подходов.