Читайте также:
|
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектирование ИС
Ключевые особенности технологии типового проектирования
· Причины применения:
o Существенно снижаются затраты на проектирование, разработку и даже на модернизацию ИС;
o Больше возможностей обеспечивать должный научно-технический уровень разработки ИС (в отличие от технологии индивидуального проектирования).
· Область применения: автоматизация деятельности таких объектов, для которых характерны общие правила функционирования и управления. В первую очередь, сюда относятся экономические системы, для которых характерны:
o Схожая структура и правила управления;
o Единые стандарты отчетности;
o Схожие комплексы используемых технических и программных средств;
o Единая цель существования: извлечение прибыли.
· Содержание: Процесс проектирования ИС состоит из следующих основных этапов:
o Разбиение проекта информационной системы на отдельные составляющие (компоненты).
o Выбор и приобретения имеющихся на рынке типовых проектных решений (тиражируемых продуктов) для каждого компонента ИС.
o Настройка и доработка приобретенных типовых проектных решений в соответствии с требованиями конкретной предметной области.
Понятие, виды и особенности типовых проектных решений
Определение. Типовое проектное решение (ТПР) – это представленное в виде комплекта проектной документации и/или набора программных модулей проектное решение, пригодное к многократному использованию.
Основные черты ТПР:
· Типовые проектные решения ориентированы на автоматизацию деятельности множества однородных объектов (путем настройки под конкретные особенности каждого из них).
· Основная цель применения ТПР – уменьшение трудоемкости и стоимости проектирования и/или разработки ИС.
· Создание ТПР возможно только после тщательного и всестороннего изучения предметной области и предполагает обобщение накопленного в частных случаях опыта (путем классификации, типизации, абстрагирования, унификации и т.п.).
· Типовые решения бывают простыми или комбинированными. Простые ТПР охватывают только какой-либо один вид обеспечения ИС, комбинированные – два и более. Примеры простых ТПР: Классификаторы (ИО), прикладные программы общего и специального назначения (ПО), инструктирующие руководства по управлению бизнес-процессами (ОО), рекомендации по составлению ТЗ (МО) и т.п.
Требования, выдвигаемые к типовым проектным решениям:
· Возможность использования для создания новой ИС при минимальном участии разработчиков ТПР;
· Соответствие требованиям положений и стандартов, распространяемых на информационную системы в целом или ее часть.
· Способность удовлетворять максимально возможному числу потребностей в рамках своего функционального назначения.
· Возможность адаптации к конкретным условиям проекта путем изменения параметров.
Методы типового проектирования
· Элементное проектирование
В качестве типового элемента используются простые ТПР, относящиеся к отдельной задаче ИС. В этом случае ИС комплектуется как множество ТПР по отдельным разрозненным задачам. Дополнительные элементы, для которых отсутствуют ТПР, разрабатываются вручную. Обычно рассматривают три группы ТПР:
o Типовые проектные решения, обеспечивающие оптимальный выбор и организацию технических средств;
o Типовые проектные решения, относящиеся к основным задачам ИС (алгоритмы решения задач, описание входных и выходных данных, программные модули общего и специального назначения и т.д.);
o Типовые проектные решения, описывающие должностные инструкции всех категорий работников, связанных с проектированием и функционированием ИС.
Существенный недостаток метода: между отдельными ТПР, как правило, отсутствует информационная/техническая/программная совместимость (проблема «лоскутной автоматизации»).
· Подсистемное проектирование
Типовыми элементами выступают пакеты прикладных программ (ППП), которые применяются для автоматизации отдельных функциональных подсистем ИС. ППП обладают следующими свойствами:
o Функциональная полнота;
o Минимизация внешних информационных связей;
o Параметрическая настраиваемость;
o Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами.
Пример ППП: «1С: Предприятие».
Недостаток: недостаточный уровень совместимости различных ППП в рамках единой корпоративной ИС.
· Объектный метод
Идея метода заключается в создании и повторном использовании законченного (т.е. с полным набором функциональных и обеспечивающих подсистем) типового проекта для автоматизации управления объектом определенной отрасли. Например, ИС школы, ИС больницы, ИС товарного склада и т.п. Сложность применения объектного метода заключается в огромном разнообразии различных объектов, что требует от разработчиков предусматривать все возможные варианты. Современные типовые проекты должны обладать следующими свойствами:
o Ориентированы для применения на объектах с высоким уровнем стабильности;
o Открытость архитектуры (возможность использования на различных программно-технических платформах);
o Высокий уровень масштабируемости;
o Высокий уровень адаптивности (возможность конфигурирования в широких пределах).
Объектный метод по определению обеспечивает полную программную совместимость компонентов системы.
Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.
Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и оценка доступных ППП по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ППП.
Критерии оценки ППП делятся на следующие группы:
· назначение и возможности пакета;
· отличительные признаки и свойства пакета;
· требования к техническим и программным средствам;
· документация пакета;
· факторы финансового порядка;
· особенности установки пакета;
· особенности эксплуатации пакета;
· помощь поставщика по внедрению и поддержанию пакета;
· оценка качества пакета и опыт его использования;
· перспективы развития пакета.
Модельно-ориентированный подход
Одна из реализаций объектного метода проектирования – это модельно-ориентированный подход. Развивается как результат использования знаний о инжиниринге бизнес-процессов, автоматизации проектирования и методах типового проектирования информационных систем. Суть его заключается в следующем. Сначала строится модель предметной области, а затем по ней выполняется моделирование информационной системы, то есть конфигурирование и связывание между собой типовых модулей. Все это проводится с использованием единой системы CASE-средств.
Инструментарий типового проектирования ИС на основе модельно-ориентированной технологии включает в себя следующие элементы:
· Репозиторий (база метаинформации) содержит:
oМножество типовых моделей, которые поставляются разработчиком системы автоматизированного типового проектирования, и расширяются по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.
oБазовую модель, которая содержит описание всех бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил и элементов организационной структуры, которые поддерживаются программными модулями типовой ИС.
oМодель конкретного объекта автоматизации, которая, возможно, создается с использованием типовых моделей и на основе которой осуществляется конфигурирование программного обеспечения. Строится как структурированное подмножество базовой модели.
Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия.
Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для проверки семантической целостности бизнес-процессов, а также для автоматизации их управления разрабатывается набор бизнес-правил.
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.
· CASE-средства для проектирования модели объекта автоматизации (мы их рассматривали ранее). Эти средства обычно интегрированы в систему автоматизированного типового проектирования.
· Конфигуратор ИС – программа, которая автоматически генерирует конфигурацию информационной системы по построенной модели предметной области.
Примеры систем автоматизации типового проектирования: SAP, BAAN.
Функционально-ориентированный и объективно-ориентированный подходы. Содержание RAD-технологии прототипного создания приложений.
ФО проектирование ЭИС Осн-ыми идеями ФО CASE-технологии явл-ся идеи стр-рного анализа и проектир-я ИС. Они заключ-ся в следующем:
1). декомпозиция всей системы на некот-е множ-во иерархически подчиненных функций;
2). представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
§ BFD (Bussiness Function Diagram) – диаграмма бизнес-функций (функциональные спецификации);
§ DFD (Data Flow Diagram) – диаграмма потоков данных;
§ STD (State Transition Diagram) – диаграмма переходов состояний (матрицы перекрестных ссылок);
§ ERD (Entity Relationship Diagram) – ER-модель данных предметной области (информационно-логические модели «сущность-связь»);
§ SSD (System Structure Diagram) – диаграмма структуры прог-го приложения.
Диаграммы функциональных спецификаций позволяют представить общую структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами BFD являются:
Функция – некоторое действие ИС, необходимое для решения экономической задачи;
Декомпозиция функции – разбиение функции на множество подфункций.
Диаграммы потоков данных (ДПД), как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к др. в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отражаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками задаются имена передаваемых/используемых единиц информации – документов, экранных форм, файлов). ДПД – показывает внешние по отношению к системе источники данных и адресатов, которые принимают информацию от системы, а также идентифицируют хранилища данных (накопители данных), к которым осуществляется доступ системы. Каждая логическая функция системы (бизнес-функция) описывается своей ДПД. Причем эта ДПД м. иерархически детализировать функцию на ее подфункции.
Диаграммы переходов состояний (ДПС) моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.) Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний. Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течение времени она м. изменить свое состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие – условие перехода. Оно м. быть информационным (условие появления информации) или временным. Диаграммы инфологических моделей «сущность-связь» (ER-диаграммы) ориентированы на разработку базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей..ERD-диаграмма «сущность-связь» представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявленных данных, которые в дальнейшем используются функциями проектируемой системы. Диаграмма структуры прог-го приложения (SSD) задает взаимосвязь функций и прог-ных модулей, которые их реализуют (меню, формы, отчеты и т.д.). Структура прогного приложения (SSD)представляет собой иерархическую взаимосвязь прогных модулей, которые реализует ИС. SSD служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах (BFD, DFD, STD, ERD), к реализации ИС.
ОО ЭИС Структурная декомпозиция ЭИС на основе ОО подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. В этом плане модель проблемной области рассматривается как совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных м. рассматриваться как результат одного взаимодействия объектов.
Конечным рез-том процесса ОО проектир-я д. стать множ-во классов объектов с присоединенными методами обраб-ки атрибутов. Если в функциональном подходе модели данных и операций разрабатываются относительно независимо др. от др. и только координир-ся между собой, то ОО подход предп-ет совместное моделир-е данных и процессов. При этом модели проблемной области в репозитории постепенно уточняются. В связи с этим система ОО моделей послед-но разворачивается по направлению от модели общего представления функциональности ЭИС к модели динамического взаимодействия объектов, на основе которой м. быть сгенерированы классы объектов в конкретной прогно-технической среде.
В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML, который разработан группой ведущих компных фирм мира OMG [89] и фактически является стандартом по объектно-ориентированным технологиям. Язык UML реализован многими фирмами – производителями прогного обеспечения в рамках CASE-технологий, например Rational Rose, Natural Engineering Workbench, ARIS Toolset и др.
Система ОО моделей в соотв-и с нотациями UML включает в себя след. диаграммы:
1) диаграмму прецедентов исп-я (Use-case diagram),кот-я отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций;
2) диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;
3) диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;
4) диаграммы взаимодействия объектов (Interaction diagram),каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;
5) диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (м. декомпозироваться на более детальные диаграммы);
6) диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (м. декомпозироваться на более детальные диаграммы);
7) диаграмму компонентов (Component diagram), которая отображает физические модули прогного кода;
8) диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.
В функциональных моделях главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов.
Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ЭИС по принципу «сверху-вниз», когда каждый функциональный блок м. быть декомпозирован на множество подфункций и т.д., выполняя т.о. модульное проектирование ЭИС. Для функциональных моделей характерны процедурная строгость декомпозиции ЭИС и наглядность представления.
Основной недостаток функциональных моделей связан с неясностью условий выполнения процессов обработки информации, которые динамически м. изменяться. Кроме того, возможна повторяемость использования одинаковых функций, а следовательно, и прогных модулей в различных процессах. В последнем случае одни и те же функции в различных иерархиях м. быть либо спроектированы несколько раз, либо общее определение м. содержать не все необходимые данные.
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые м. обращаться к атрибутам этого класса (скрытие данных).
Для классов объектов характерна иерархия обобщения, позволяющая осуществить наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов).
В объектно-ориентированном подходе изменяется и принцип проектирования ЭИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (ЖЦ объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения ИС.
Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области. Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели уступают функциональным моделям.
При выборе формализма для модели проблемной области обычно в качестве критерия выбора выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов) – объектно-ориентированные модели.
RAD-технологии прототипного создания приложений
Одним из возможных подходов к разраб-ке ПО в рамках спиральной модели ЖЦ явл-ся получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:
небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес); повторяющийся цикл, при кот-м разработчики, по мере того, как приложение начинает обретать форму, запраш-ют и реализуют в продукте треб-я, полученные через взаимод-ие с заказчиком.
Команда разработч-ов д. предст-ть из себя группу профессионалов, имеющих опыт в анализе, проектир-и, генерации кода и тестир-и ПО с использ-ем CASE-средств. Члены коллектива д. также уметь трансформир-ть в рабочие прототипы предлож-я конеч. польз-лей.
Дата добавления: 2015-05-05; просмотров: 32 | Поможем написать вашу работу | Нарушение авторских прав |