Смирнов Н.В. Проектирование информационных систем

Подождите немного. Документ загружается.

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

В результате может оказаться, что штат увеличен, производительность

упала, производство требует инвестиций, соответственно возникает по-

требность в увеличении оборотного капитала, что может потребовать новых

кредитов и уменьшить плановую прибыль.

В итоге предприятие перестает расти интенсивно и дальнейшее расшире-

ние происходит чисто экстенсивным путем за счет ранее созданной прибыли.

Почему же сегодня, когда для организации документооборота (в дальней-

шем под этим термином мы будем понимать документооборот любых документов:

конструкторских, технологических, финансовых, организационных и т.п.) предла-

гается множество самых различных средств автоматизации, документооборот

часто организован плохо, даже на относительно небольших предприятиях? Ответ,

независимо от степени автоматизации предприятия и его типа, может быть один -

отсутствие или игнорирование модели организации документооборота

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

этом, если по состоянию делопроизводства в организации был "ручной" хаос, то

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

Без должной оценки возможностей пользователя, исследования биз-

нес - процессов его предприятия трудно ожидать эффекта от внедрения

как систем документооборота класса docflow так и, тем более, workflow.

При этом совсем неважно, как планируется или уже реализован документооборот:

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

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

ленная на упорядочение бизнес - процессов. Иначе говоря, прежде чем что-то де-

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

иные процессы, имеющие место на предприятии. Проводя в жизнь программу

модернизации делопроизводства, важно представлять, уровень дости-

жений предприятия, и какое место ему отводится в модельном про-

странстве системы документооборота

Полный конспект ©БГТУ \ ИИУС \ И3 \ 61-146

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

6. Моделирование информационных систем

6.1 Общие положения

В разделе 2 при описании признаков объекта проектирования отмечалось, что

объектом проектирования является информация об объекте проектирования, ин-

формационная модель объекта. В случае проектирования ИС это информацион-

ная модель информационной системы. В общем случае модели проектируемых

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

ны с помощью следующих теоретических схем: функциональных, поточных и

структурных. С помощью этих схем обычно раскрываются теоретические (мыс-

лимые) аспекты научно-технические знания. Рассмотрим подробнее эти схемы.

Функциональная схема фиксирует общее представление о технической систе-

ме, независимо от способа ее реализации, и является результатом идеализации

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

Функциональные схемы совпадают для целого класса технических систем. Блоки

этой схемы фиксируют только те свойства элементов технической системы, ради

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

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

смотренных обособлено от тех нежелательных свойств, которые привносит с со-

бой элемент в систему, и определяют блоки (или функциональные элементы) та-

ких схем. Как правило, они выражают обобщенные математические операции, а

функциональные связи, или отношения, между ними - определенные математиче-

ские зависимости.

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

ют собой графическую форму математического описания состояния электриче-

ской цепи. Каждому функциональному элементу такой схемы соответствует опре-

деленное математическое соотношение, - скажем, между силой тока и напряже-

нием на некотором участке цепи или вполне определенная математическая опе-

рация (дифференцирование, интегрирование и т.п.). Порядок расположения и ха-

рактеристики функциональных элементов адекватны электрической схеме.

Полный конспект ©БГТУ \ ИИУС \ И3 \ 62-146

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

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

определенному типу физического процесса, т.е. к определенному режиму функ-

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

кой-либо математической схемой или уравнением. Однако, они могут быть и не

замкнуты на конкретный математический аппарат. В этом случае они выражаются

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

полнение общей цели, предписанной данной технической системе. С помощью

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

выбирается ее конфигурация (внутренняя структура).

Поточная схема, или схема функционирования, описывает процессы, проте-

кающие в технической системе и связывающие ее элементы в единое целое. Бло-

ки таких схем отражают различные действия, выполняемые над естественным

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

Для каждого вида процесса применяется наиболее адекватный ему математи-

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

технической системы в данном режиме ее функционирования. Заметим, что для

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

несколько поточных и функциональных схем.

Поточные схемы в общем случае отображают не обязательно только физиче-

ские процессы (электрические, механические, гидравлические и т.д.), но и хими-

ческие, если речь идет о теоретических основах химической технологии и вообще

любые (например, информационные) процессы. В предельно общем случае по-

точные схемы отображают не только естественные процессы, но и вообще любые

потоки субстанции (вещества, энергии, информации). Причем в частном случае

эти процессы могут быть редуцированы к стационарным состояниям, но послед-

ние могут рассматриваться как вырожденный частный случай процесса.

Структурная схема технической системы фиксирует те узловые точки, на ко-

торые замыкаются потоки (процессы функционирования). Это могут быть единицы

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

собой конструктивные элементы различного уровня, входящие в данную техниче-

Полный конспект ©БГТУ \ ИИУС \ И3 \ 63-146

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

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

полнению и ряду других характеристик. Такие элементы обладают, кроме функ-

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

собой в систему определенным образом реализованные элементы, в том числе и

нежелательными (например, усилитель - искажения усиливаемого сигнала).

Структурная схема фиксирует конструктивное расположение элементов и связей

(т.е. структуру) данной технической системы и уже предполагает определенный

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

которой идеализации, отображают структуру технической системы, но не являют-

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

проектом, по которому может быть построена такая система. Такая схема пока

еще теоретический набросок структуры будущей технической системы, который

может помочь разработать ее проект, то есть продуцированный технической тео-

рией исходный пункт для последующей инженерной деятельности, или исходное

теоретическое описание, теоретическая схема уже существующей технической

системы с целью ее теоретического расчета и поиска возможностей для усовер-

шенствования (или разработки на ее основе новой системы). Кроме того, часто

эти схемы строятся на основе представлений более специализированных научно-

технических дисциплин и решают теоретическими средствами возникшие в них

задачи.

Таким образом, в технической теории на материале одной и той же технической

системы строится несколько оперативных пространств, которым соответствуют

различные теоретические схемы. В каждом таком "пространстве" используются

разные абстрактные объекты и средства оперирования с ними, решаются особые

задачи. В то же время их четкая адекватность друг другу и структуре реальной

технической системы позволяет "транспортировать" полученные решения с одно-

го уровня на другой, а также в сферу инженерной деятельности. Механизмы (ме-

тоды) взаимодействия этих оперативных пространств могут быть раскрыты в ре-

зультате методологического анализа функционирования технической теории (на-

пример, программной инженерии).

Полный конспект ©БГТУ \ ИИУС \ И3 \ 64-146

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

В случае, когда технической системой является информационная система,

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

следующие методы программной инженерии: метод структурного программирова-

ния (СП) или метод объектно-ориентированного программирования (ООП).

Структурные методы появились раньше и на сегодняшний день имеют

большую историю применения и инструментальную поддержку. Объектно - ориен-

тированные методы появились позже, однако, они стремительно завоевывают

признание среди разработчиков программных систем и вытесняют из этой облас-

ти структурные методы.

Несмотря на существенную разницу в принципах и системе понятий, суще-

ствующую в методах рассмотренных подходов, между ними нет прямого противо-

речия. Часто объектно-ориентированные методы содержат элементы структурно-

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

ООП. Например, диаграммы потоков данных, будучи классическим элементом

структурного подхода, применяются также и при объектно – ориентированном

подходе. Например, диаграммы активности в UML (язык, применяемый в ООП) по-

зволяют моделировать структуру деятельности (бизнес-процессов). Другой при-

мер – классы (диаграммы классов), являются одним из основных понятий ООП и,

в тоже время, представляют собой развитие диаграмм «сущность-связь» (ERD),

предложенных П.Ченом и широко используемых в структурных методах. Таким

образом, оба подхода и СП и ООП обязательно рассматривают функциональное

представление системы, структурное представление системы и конечно же пото-

ковое (представление функционирования). Весь вопрос насколько прост и удобен

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

проектирования ИС, как уже отмечалось выше, ООП становиться белее популя-

рен и уже имеет мощную инструментальную поддержки в виде линейки CASE-

средств, которые в свою очередь обеспечивают простой переход от проектных

решений по ИС к программным решениям.

Полный конспект ©БГТУ \ ИИУС \ И3 \ 65-146

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

6.2 Методы структурного моделирования

Основу методов структурного моделирования составляют принципы струк-

турного подхода, основными из которых являются:

а). Принцип «разделяй и властвую» - принцип решения сложных проблем

путем их разбиения на множество меньших, независимых задач;

б). Принцип иерархического упорядочивания – принцип организации со-

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

в). Принцип абстрагирования – выделение существенных аспектов систе-

мы и отвлечение от несущественных;

г). Принцип формализации – необходимость строго методического подхода

к решению проблемы;

д). Принцип непротиворечивости – обоснованность и согласованность эле-

ментов;

е). Принцип независимости данных – модели данных должны быть спроек-

тированы и проанализированы независимо от процессов их логической

обработки;

ж). Использование графических нотаций.

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

ды графических нотаций:

• DFD (Data Flow Diagrams) – диаграммы потоков данных (ДПД) совместно со сло-

варями данных и спецификациями процессов;

• ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь»;

• STD (State Transition Diagrams) – диаграммы переходов состояний

Методологической основой структурного моделирования является методо-

логия SADT (Structured Analysis and Design Technique). Несмотря на то, что полная

методология подразумевает моделирование как функциональной (модели актив-

ности), так и информационной составляющей (модели данных), наибольшее рас-

пространение получила функциональная часть данной методологии. На основе

Полный конспект ©БГТУ \ ИИУС \ И3 \ 66-146

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

функциональной составляющей SADT разработана методология IDEF0, ставшая

промышленным для предприятий многих стран мира. Используемые в ней нота-

ции и техника функционального моделирования являются альтернативой DFD,

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

из важнейших особенностей методологии SADT является строгая типизация свя-

зей между функциями.

6.3 Методы объектно- ориентированного моделирования

Основу методов объектно-ориентированного моделирования составляют

принципы объектно-ориентированного подхода, основными из которых являются:

а). Принцип онтологизации системы декларирует представление системы

посредством системы классов, отражающих понятийную структуру

предметной области в виде моделей (например, модель здания, модель

уровневой системы образования и т.п.). Классы определяются атрибу-

тами (свойствами) и операциями (методами). Все множество экземпля-

ров класса (объекты) также определяются через атрибуты и операции

класса;

б). Принцип декомпозиции декларирует представление системы (пред-

метной области или ИС) совокупностью взаимодействующих между со-

бой объектов. Объекты являются экземплярами классов и взаимодейст-

вуют посредством передачи сообщений;

в). Принцип инкапсуляции – декларирует запрещение любого доступа к

атрибутам объекта, кроме как через его операции (методы); в соответ-

ствии с этим принципом внутренняя структура объекта скрыта от поль-

зователя, а любое его действие инициируется внешним сообщением,

вызывающим выполнение соответствующей операции;

г). Принцип наследования - декларирует создание новых классов от об-

щего к частному; новые классы сохраняют все свойства классов-

родителей, а также содержат дополнительные атрибуты и операции,

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

характеризующие их специфику;

д). Принцип полиморфизма - декларирует возможность работы с объек-

том без информации о конкретном классе, экземпляром которого он яв-

ляется.

Информационные системы, разработанные на основе объектно - ориенти-

рованного подхода обладают следующими ключевыми преимуществами:

а). возможность повторного использования (объектно - ориентированные

системы могут быть легко собраны из ранее разработанных программ-

ных компонентов)

б). расширяемость, (системы будут легко расширяться без какой либо мо-

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

В процессе становления объектно - ориентированного программирования

интерес сместился к объектно - ориентированным методам проектирования и ана-

лиза (или описания). Преимущества повторного использования и расширяемости

можно рассматривать в рамках анализа и проектирования, а не только програм-

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

инженерии, чем выше уровень повторного использования, тем лучше. Это приво-

дит к возникновению важных вопросов. Должно ли объектно - ориентированное

проектирование реализовываться в объектно – ориентированном языке? Должны

ли методы проектирования быть связаны с определенными языками? Одним из

ответов на эти вопросы явилась разработка языка моделирования UML (Unified

Modeling Language – Унифицированный Язык Моделирования). В методах объект-

но-ориентированного анализа в настоящее время международным стандартом

(версия 1.4 стандарт ISO) и стандартом «де-факто» стал язык UML. В ходе при-

нятия проектных решений, на практических занятиях, являющихся составной ча-

стью данного лекционного курса, рассматриваются вопросы более детально при-

менения элементов языка UML и методов моделирования с его помощью.

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

7. Архитектура информационной системы

Нормативное понятие архитектуры информационной системы по ГОСТ Р 34.320-96. Архи-

тектура клиент – сервер

Нормативное понятие архитектуры информационной системы

(по ГОСТ Р 34.320-96)

В стандарте ГОСТ Р 15288-2005 не только особо выделен процесс создания

архитектуры целевой системы (информационной системы или автоматизирован-

ной системы), но появились прямые указания на то, что архитектурные продукты

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

только стадий создания ("концепция", "разработка") системы. Эти архитектуры

должны сопровождаться и развиваться на протяжении всего жизненного

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

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

решений о дальнейшем развитии системы.

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

архитектуры приведено в стандарте ANSI \ IEEE Std 1471 - 2000 Института инже-

неров-электриков и электронщиков, который предоставляет метамодель для оп-

ределения архитектуры. Этот стандарт определяет такие абстрактные элементы

архитектуры, как представления, системы, среды, обоснования, заинтересован-

ные стороны и т.д. в соответствии со схемой, показанной Рисунок 4

\\ Проектирование информационных систем\ Конспект лекций \ Смирнов Н.В.\ Версия 0.3.3\*.

Рисунок 4 Рамочная модель разработки архитектуры по IEEE 1471

В соответствии с этим представлением система обладает некоторой архи-

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

зрения в зависимости от интереса тех людей (заинтересованных лиц), которые

рассматривают архитектуру системы. Каждой точке зрения на архитектуру систе-

мы соответствует определенное представление, основу которого составляет не-

который набор моделей. Однако этот стандарт не определяет структуру собст-

венно архитектуры предприятия. Например, говорится о том, что необходимо

иметь различные представления архитектуры, но при этом не указывается, какие

это должны быть представления.

Рассматривая архитектуру ИС можно рассмотреть различные аспекты поня-

тия архитектуры ИС. В частности, можно выделять такие подмножества, как сис-

темная архитектура (архитектура систем – System Architecture) и программная ар-

хитектура (архитектура программного обеспечения – Software Architecture). Вспом-

ним, что мы уже отмечали неоднозначность трактовки терминов. На практике, в

зависимости от контекста, термин "системная архитектура" может относиться ли-

бо к архитектуре ИС предприятия (в дополнение к бизнес-архитектуре) или даже в