Современные технологии проектирования ИС

Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции

проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.

проектирование.
Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов

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

с использованием специального программного инструментария (например, SAP Business Engineering Workbench

(BEW), BAAN Enterprise Modeler).
Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

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

основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.
Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации.

задание структуры объекта автоматизации;
определение структуры основных данных;
задание перечня

реализуемых функций и процессов;
описание интерфейсов;
описание отчетов;
настройку авторизации доступа;
настройку системы архивирования.

компонентов ИС важно осуществлять совместное моделирование всех компонентов, особенно с

содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач.
Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – «разделяй и властвуй» и принципе иерархической упорядоченности.

выполняемое на одном рабочем месте.
Функция – совокупность операций, сгруппированных по

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

выделить функционально-ориентированные и объектно-ориентированные методологии.
Объектные методики рассматривают моделируемую организацию как

набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.
Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

анализа и проектирования систем SADT (Structured Analysis and Design Teqnique).

Методика IDEF0 входит в семейство стандартов IDEF по программе автоматизации промышленных предприятий. Семейство стандартов унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition). Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.

рамках рассматриваемой системы.
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип

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

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

рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint) пользователя.
Цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.

систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся

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

по отношению к дочерней диаграмме, а диаграмма, к которой он

принадлежит – родительской диаграммой. Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы.

в виде диаграммы потоков данных (Data Flow Diagram — DFD),

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

физических компонент) из одной части системы в другую. Потоки на

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

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

DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полным описание системы.

потоки информации внутри и вне системы;
возможность проектирования сверху вниз,

что облегчает построение модели «как должно быть»;
наличие спецификаций процессов нижнего уровня, что позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы.
К недостаткам модели отнесем: необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения DFD ничем не отличаются от обычных; отсутствие понятия времени, т.е. отсутствие анализа временных промежутков при преобразовании данных (все ограничения по времени должны быть введены в спецификациях процессов).
 

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

и объектов, являющихся частью этих процессов.
IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.

которые в дальнейшем могут быть использованы для имитационного анализа.
Методология IDEF3

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

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

одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD документируются информационные аспекты бизнес-системы, включая идентификацию объектов, - сущностей, свойств этих объектов - атрибутов и их связей с другими объектами (отношений).

объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими

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

экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым)

количеством экземпляров второй сущности, и наоборот.
Атрибут (Attribute) представляет тип характеристики или свойств, ассоциированных с множеством реальных или абстрактных сущностей - объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. Экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.

метод Баркера и метод IDEFI.
Метод Баркера основан на нотации, предложенной

автором, и используется в CASE -средстве Oracle Designer.
Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).
В методе IDEFIX сущность является независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя).

представления модели — логический и физический.
Логический уровень — это абстрактный

взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

содержится информация обо всех объектах БД. Следовательно, одной и той

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

эффективности автоматизируемых процессов.
Метод функционального моделирования позволяет оптимизировать существующие на предприятии

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

выполнения операций, и обеспечивающий наиболее полные средства анализа динамики бизнес-процессов.

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

преобразования модели процессов в имитационную модель.
Имитационная модель дает больше

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

дает возможность экспортировать модель IDEF3 в специализированное средство создания таких

моделей.
Функциональные и имитационные модели тесно взаимосвязаны и эффективно дополняют друг друга. Имитационные модели дают больше информации для анализа системы, результаты которого могут быть причиной модификации модели процессов. Целесообразно сначала строить функциональную модель, а на ее основе — имитационную.

способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом

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

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

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

процесса моделирования.
Процесс – это описание шагов, которые необходимо выполнить

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

классы объектов, а далее в зависимости от возможных состояний объектов

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

исследуемой системы, построить модель «как есть» и «как должно быть».

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

объединяющей различные этапы отдельных методик.
Идея обобщенной методики заключается в

последовательном применении функционального и объектного подхода с учетом возможности реинжиниринга существующей ситуации.

ПО в рамках спиральной модели ЖЦ является получившая в последнее

время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development).
Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств.

фаза анализа и планирования требований;
фаза проектирования;
фаза построения;
фаза

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

системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих

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

системы и принимается решение о разделении ИС на подсистемы, поддающиеся

реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель).

данной фазе разработчики производят итеративное построение реальной системы на основе

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

с внедрением новой системы осуществляется работа с существующей системой (до

полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы.
Методология RAD хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика.
Средства разработки, основанные на RAD, очень популярны
за счет использования таких программных сред разработки: IBM Lotus Domino Designer, Borland Delphi, Borland C++ Builder, Microsoft Visual Studio,Macromedia Flash и др.

Language) предоставляет объектно-ориентированный метод проектирования сложных программных систем.
Язык UML

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

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

унифицированный язык для разработки и документирования объектных моделей сложных систем различного целевого назначения.
UML - формальный язык со встроенными возможностями расширения для более точного моделирования систем конкретной предметной области.
UML не является языком программирования, но обладает возможностью реализации своих конструкций на различных языках программирования, поддерживающие концепцию ООП.
Для программной поддержки конструкций языка UML разработаны специальные инструментальные CASE-средства, в частности Rational Rose, Rational Software Architect? Paradigm Plus и другие.