Проектирование информационной системы

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

В объектно-ориентир-м подходе  изменяется и принцип проектир-я  ЭИС. Сначала выделяются классы объектов, а далее в завис-ти от возможных  состояний объектов (ЖЦ объектов) опред-ся методы обраб-ки (ф-ционал-е процедуры), что обеспечивает наилучшую реализ-ю  динамич-го поведения ИС.

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

ООП основан на следующих  понятиях:

Объект предметной области

Свойство объекта

Метод – программа действий над объектом

Класс – объединение объектов по общему методу

Состояние – совокупность объектов в определенный момент времени

Событие – действие, которое меняет состояние

Об-Ориент. моделирование  происходит в 3 этапа:

1. информационное моделирование (графическое отображение объектов)
2. моделирование состояний
3. моделирование процесса

 

16. Технология структурного проектирования. Построение SADT-диаграмм. Стандарты технологии  IDEF0, IDEF1 и др.

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

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

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

SADT – с-ма, к-рую принято  наз-ть активностной моделью,  к-рая предст-т сложную с-му  подроб-тей. Осн-м раб. эл-том  при моделир-и явл-ся диагр-а.  Модель SADT организует и объединяет  диагр-ы иерархич-й и древовид-й  структуры, при этом, чем выше  ур-нь диагр-ы, тем она менее  детализир-на. В состав диагр-ы  вх-т блоки, изображающие активность  моделируемой с-мы и дуги, связывающие  блоки вместе и изображающие  в/д-е и в/связи м/блоками (активностями). SADT требует, чтобы в диагр-е  было от 3 до 6 блоков.

Блоки на диагр-ах изображ-ся прямоуг-ми и сопровожд-ся текстом  на естеств-м языке, описывающим  активность. В отличие от др. методов  структ-го анализа в SADT каждая сторона  блока имеет вполне опред-ое значение. Левая сторона блока предназн-на д/входа, верхняя – д/упр-я, правая – д/выхода, нижняя – д/исполнителей. Такое обознач-е отражает опред-ые принципы активности. Входы преобраз-ся в выходы, упр-я ограничивают (предписывают) усл-я упр-я, исполнители опис-ют то, за счет чего вып-ются преобразования. Дуги SADT представляют наборы предметов  и маркир-ся набором текстов на естественном языке. Предметы м. состоять из 4-х возможных отношений: выход, упр-е, вход и исполнитель.

Каждое из этих отнош-й  изображ-ся дугой, связ-ой с опред-й  стороной блока. Вх-ые дуги изобр-ют предметы, использ-ые преобразуемыми актив-тями. Упр-ющие дуги изобр-ют инфу об упр-и, действующем  на актив-ть. Вых-ые дуги изобр-ют предметы, к-рые преобраз-т входы. Блоки  на диагр-е размещ-ся по ступенчатой  схеме в соотв-и с их доминир-м, они приним-ся как влияние, оказыв-ое одним блоком на др. Блоки д.б. пронумер-ны в соотв-и с их доминир-ем. №№ блоков служат однознач-ми информаторами  д/актив-ти и автоматич-ки организ-т  эти актив-ти в иерархию модели.

В/влияние блоков м. выражаться либо в перестановке выхода в другой активности д/дальнейшего преобраз-я, либо в выработке управляющей  инфы, предписывающей, что именно д. делать др. активность. В SADT технологии треб-ся только 5 видов в/связей м/блоками  д/опис-я их отношений:

1. упр-е,
2. вход,
3. управленческая обратная связь,
4. вх-ая обратная связь,
5. в/связь типовых выходов-исполнителей.

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

 

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

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

IDEF1 (информационная) – методол-ия моделир-я инф. потоков внутри с-мы, позволяющая отображать и анализир-ть их структуру и в/связи. Метод IDEF1 позволяет построить модель д-х, эквивалентную реляц-й модели в 3-ей нормальной форме. Используется для создания информационной модели, представляющей структуру информации. На основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X.

IDEF1X (IDEF1 Extended) – методол-ия построения реляц-х структур. IDEF1X относ-ся к типу методологий “Сущность-в/связь” (ER) и, к.пр., использ-ся д/моделир-я реляц-х БД, имеющих отношение к рассматриваемой с-ме. IDEF1X использует условный синтаксис, спец-но разработанный д/удобного построения концептуал-й схемы (универс-ое представление структуры д-х в рамках коммерч-го пр-ятия).

Использование метода IDEF1X наиб-е  целесообразно д/построения логич-й  структуры БД после того, как все  инф. рес-сы исследованы (скажем с пом. метода IDEF1) и решение о внедрении  реляц-й БД, как части КИС, было принято.

IDEF2 – методол-я динамич-го моделир-я развития с-м. В связи с весьма серьезными сложностями анализа динамич-х с-м от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Но в наст. время присутствуют алгоритмы и их комп-ные реализации, позволяющие превращать набор статич-х диагр IDEF0 в динамич-е модели, построенные на базе “раскрашенных сетей Петри” (Color Petri Nets).

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

IDEF4 – методол-я построения объектно-ориентир-х с-м. Ср-ва IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их в/д-я, тем самым, позволяя анализир-ть и оптимизир-ть сложные объектно-ориентир-ые с-мы.

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

IDEF8 – интерфейс пользователя.

IDEF10 – техническое проектир-е.

IDEF14 – проектир-е вычислит-х сетей.

 

17. Типовое проектирование ИС. Понятие типового элемента. Технологии параметрически-ориентированного и модельно-ориентированного проектирования.

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

Типовое проектирование ИС

Ключевые особенности  технологии типового проектирования

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

Понятие, виды и особенности  типовых проектных решений

Определение. Типовое проектное  решение (ТПР) – это представленное в виде комплекта проектной документации и/или набора программных модулей  проектное решение, пригодное к  многократному использованию.

Основные черты ТПР:

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

Требования, выдвигаемые  к типовым проектным решениям:

• Возможность использования для создания новой ИС при минимальном участии разработчиков ТПР;
• Соответствие требованиям положений и стандартов, распространяемых на информационную системы в целом или ее часть.
• Способность удовлетворять максимально возможному числу потребностей в рамках своего функционального назначения.
• Возможность адаптации к конкретным условиям проекта путем изменения параметров.

Методы типового проектирования

• Элементное проектирование

В качестве типового элемента используются простые ТПР, относящиеся  к отдельной задаче ИС. В этом случае ИС комплектуется как множество  ТПР по отдельным разрозненным задачам. Дополнительные элементы, для которых  отсутствуют ТПР, разрабатываются  вручную. Обычно рассматривают три группы ТПР:

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

Существенный недостаток метода: между отдельными ТПР, как  правило, отсутствует информационная/техническая/программная  совместимость (проблема «лоскутной автоматизации»).

• Подсистемное проектирование

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

• Функциональная полнота;
• Минимизация внешних информационных связей;
• Параметрическая настраиваемость;
• Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами.

Пример ППП: «1С: Предприятие».

Недостаток: недостаточный  уровень совместимости различных  ППП в рамках единой корпоративной ИС.