Конспект лекций по дисциплине «Проектирование ис»
Лекция 1. Понятие и структура проекта информационной системы(ИС). Требования к эффективности и надежности проектных решений. (2 час).
Цель: Изучить понятие проекта информационной системы и основные составляющие его структуры. Определить требования к эффективности и надежности проектных решений.
Осваиваемые компетенции: ПК-16, ПК-21
Проект ИС представляет собой совокупность проектной документации, в которой представлено описание проектных решений по созданию и эксплуатации ИС.
Объектами проектирования могут быть как отдельные элементы, так и комплексы, относящиеся к функциональной части ИС.
Функциональные подсистемы информационно обслуживают определенные виды деятельности организации, характерные для структурных подразделений или функций управления.
Организационное обеспечение регламентирует структуру управления объектом в условиях применения ИС и распределение должностных обязанностей между пользователями системы.
Информационное обеспечение состоит из внемашинного и внутримашинного. К внемашинному ИО относятся системы классификации и кодирования информации, а также система документации. К внутримашинному ИО относят БД, базы знаний, пользовательский интерфейс и т.д.
Программное обеспечение включает в себя общие и специализированные программы информации, реализующие принятые экономико –математические методы и представляющие пользователю определенные лингвистические средства для программирования и диалога с информационной системой.
К техническому обеспечению относится средства вычислительной и телекоммуникационной техники.
В состав проектной документации по созданию ИС входят следующие основные док-ты:
1. «технико –экономическое обоснование»(ТЭО). Целью разработки данного проекта является :
Обоснование состава функциональных задач
Требования к обеспечивающим подсистемам
Технологии проектирования
Ориентировочный расчет экономической эффективности
2. «техническое задание на создание автоматизированной системы». Составляется на основе ТЭО и включает задания на проектирование функциональной части и обеспечивающих подсистем.
3. «Технический проект». При разработке данного документа осуществляется алгоритмизация экономических задач, проектирование организационного, информационного и технического обеспечения, а также уточненные расчеты экономической эффективности.
4. «Рабочий проект». Включает документацию, касающуюся формирования программного обеспечения, монтажа технических средств, а также технологические инструкции, предназначенные для использования специалистами в своей деятельности на каждом АРМ(Автоматизированном рабочем месте).
Структура проекта информационной системы характеризуется составом и взаимосвязью проектной документации, входящей в проект (рис. 1.1).
Рис. 1.1. Структура проекта информационной системы
Требования к эффективности и надежности проектных решений
Эффективность системы – это степень ее соответствия своему назначению. Различают экономическую и функциональную эффективность.
Критерий эффективности – не число как показатель, а тенденция например, свести к минимуму затраты – это критерий).
Критерий и показатели, характеризующие систему в целом, определяют собой критерий и показатели ее подсистем.
Оценка экономической эффективности основана на сопоставлении затрат и результатов, выраженных в денежной форме.
Основным требованием к экономической эффективности является требование, чтобы результаты превосходили затраты и соотношение результатов и затрат соответствовало бы требуемой рентабельности.
Требования, предъявляемые к надежности информационной системы, весьма высоки.
Современные информационные системы должны работать в режиме «24х365», то есть двадцать четыре часа в сутки без выходных дней.
Надежность системы характеризуется потоком отказов и сбоев (самоустраняющихся отказов) в работе системы. Отказы выявляются тестированием технических и программных средств и устраняются во время проведения ремонтно-профилактических работ. Устранение отказов достигается путем восстановления работоспособности неисправных элементов системы (ремонта) или замены их резервными элементами.
Лекция 2. Методы и средства проектирования ИС. (2 час)
Цель: рассмотреть основные методы и средства проектирования информационных систем.
Осваиваемые компетенции: ПК-16, ПК-21
На рис. 2.1 представлена классификация методов проектирования информационной системы.
По степени автоматизации методы проектирования подразделяются на методы с универсальной и специальной компьютерной поддержкой.
По степени использования типовых проектных решений методы классифицируются на оригинальные (индивидуальные) и типовые. Оригинальное (индивидуальное) проектирование предполагает новую разработку системы без использования готовых проектных решений. Типовое проектирование базируется на типовых проектных решениях, полученных из прошлого опыта. Различаются методы проектирования и по характеру адаптации проектных решений.
Методы перепрограммирования предполагают необходимость разрабатывать изменяемые программные модули заново. Методы параметризации обеспечивают настройку (конфигурирование) проектных решений путем изменения параметров в программных модулях.
Рисунок 2.1 - Классификация методов проектирования информационной системы
Модельные методы предполагают наличие модели предметной области, в которую могут быть внесены необходимые изменения с последующей кодогенерацией программных модулей.
Методы проектирования тесно связаны со средствами проектирования.
Технология проектирования
Технология проектирования характеризуется, как было сказано ранее, методологией, методами и средствами проектирования. Среди всех перечисленных компонентов технологии проектирования определяющим компонентом является метод проектирования. Сочетание классифицированных признаков методов проектирования позволяет выделить класс технологий проектирования. На рис. 2.2 представлена классификация технологий проектирования.
В зависимости от степени компьютерной поддержки процесса проектирования принято разделять технологии проектирования на канонические и индустриальные.
Каноническое (классическое, традиционное) проектирование предполагает использование инструментальных средств универсальной компьютерной поддержки и предназначено для создания индивидуальных (оригинальных) проектов с учетом особенностей объекта применения ИС.
Адаптация проектных решений затруднительна и возможна лишь путем перепрограммирования соответствующих программных модулей.
Обычно каноническое проектирование используется для создания небольших локальных информационных систем, не предназначенных для тиражирования.
Технологии индустриального проектирования используют специальную компьютерную поддержку процесса проектирования, оправданную при разработке сложных интегрированных информационных систем. В этом случае процесс проектирования можно назвать программостроением.
Технологии индустриального проектирования подразделяются на типовые и автоматизированные.
Рисунок 2.2 - Классификация технологий проектирования
По характеру адаптации проектных решений технологии типового проектирования классифицируются на параметрически – ориентированные и модельно – ориентированные.
Индивидуальный подход к проектированию, сокращение сроков и стоимости проектирования, обеспечиваются за счет применения методов автоматизированного проектирования.
Методы автоматизированного проектирования подразделяются на функционально- и обьектно-ориентированные в зависимости от метода декомпозиции информационной системы, выбранного при построении ее модели.
Наконец, важным требованием к технологии проектирования является требование адаптивности проектных решений в процессе эксплуатации информационной системы.
Лекция 3. Основные компоненты технологии проектирования ИС. (2 час).
Цель: изучить основные компоненты технологии проектирования ИС.
Осваиваемые компетенции: ПК-19, ПК-24
Технология проектирования характеризуется рядом компонентов, определяющих подход к созданию информационной системы.
Компоненты технологии проектирования выстраиваются в следующую парадигму проектирования:
1). Методология предлагает принципы проектирования, определяет общие подходы к оценке и выбору варианта системы, последовательность стадий и этапов проектирования, и, в конечном итоге, позволяет выбрать метод проектирования.
2). Метод проектирования конкретизирует порядок разработки отдельных элементов, комплексов задач, подсистем и системы в целом.
3). Метод проектирования неразрывно связан с инструментальными средствами проектирования, которые его поддерживают.
Основные принципы проектирования информационной системы представлены на рис 3.1.
Рисунок 3.1 - Принципы проектирования информационных систем
Лекция 4. Выбор технологии проектирования ИС. (2 час).
Цель: определить требования, предъявляемые при выборе технологии проектирования ИС.
Осваиваемые компетенции: ПК-19, ПК-24
Назовем ряд основных требований, предъявляемых при выборе технологии проектирования:
Технология проектирования должна обеспечивать требования заказчика к информационной системе в части функциональной полноты, достоверности и оперативности при минимизации стоимостных затрат на создание и эксплуатацию системы. Эти требования отражены в концептуальной модели проектирования информационной системы.
Выбираемая технология проектирования должна позволить проектировщикам разработать проект в установленные сроки.
Должна быть обеспечена экономическая эффективность проектной деятельности, то есть затраты на разработку проекта должны окупаться за счет доходов от его реализации.
Технология проектирования должна отвечать требованиям надежности функционирования информационной системы.
Наконец, важным требованием к технологии проектирования является требование адаптивности проектных решений в процессе эксплуатации информационной системы.
Для конкретных классов технологии проектирования свойственно применение соответствующих средств проектирования информационных систем. Так, использование технологии канонического проектирования предполагает применение различных средств на традиционных носителях, в том числе нормативно-правовых документов (положений о структурном подразделении, должностных инструкций и т. п.), нормативно-технических документов (стандартов, руководящих документов и т. п.), систем классификации и кодирования информации, систем документации, моделей входных и выходных потоков информации и методик их анализа и др. При автоматизированном проектировании наряду с вышеназванными средствами могут быть использованы разнообразные программные средства, которые подразделяют на четыре группы: операционные средства (алгоритмические языки, макрогенераторы, генераторы программ типовых операций обработки данных, утилиты, библиотеки стандартных подпрограмм и классов объектов и др.); прикладные программные средства общего назначения (СУБД, текстовые и графические редакторы, табличные процессоры, методо-ориентированные пакеты прикладных программ, оболочки экспертных систем, интегрированные пакеты прикладных программ); функциональные средства проектирования (функциональные пакеты прикладных программ, типовые проекты и проектные решения); средства автоматизации проектирования (CASE-средства).
Лекция 5. Каноническое проектирование. (2 час).
Цель: ознакомиться с основными составляющими канонического проектирования.
Осваиваемые компетенции: ПК-12
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС, которая подразумевает полное завершение некоторого типа работ перед переходом к следующему этапу на котором выполняется другой тип работ. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
Каноническое проектирование ИС характеризуется следующими особенностями:
1. Отражает особенности ручной технологии проектирование;
2. Предполагает выполнение индивидуального (оригинального) проектирования;
3. Не предполагает использования средств интеграции;
4. Соответствует каскадной модели ЖЦ ИС.
На сегодняшний день технологию канонического проектирования используют при разработке сравнительно небольших ИС.
Лекция 6. Стадии и этапы процесса проектирования ИС (2 час).
Цель: изучить стадии и этапы процесса проектирования ИС
Осваиваемые компетенции: ПК-12
Процесс проектирования рекомендуется проводить в соответствии с ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» [6], действие которого продлено до настоящего времени (Указатель Государственных стандартов 2003 г.).
Указанный ГОСТ предлагает следующие 8 стадий процесса проектирования информационной системы:
1). Формирование требований к автоматизированной системе.
2). Разработка концепции автоматизированной системы.
3). Техническое задание.
4). Эскизный проект.
5). Технический проект.
6). Рабочая документация.
7). Ввод в действие.
8). Сопровождение автоматизированной системы.
Имеется возможность установить состав стадий и этапов в зависимости от сложности объекта автоматизации, поскольку этот документ носит рекомендательный характер.
Заметим, что этап — это часть стадии. В каноническом проектировании используется каскадная или итерационная модели создания информационной системы (рис. 6.1). Итерационная модель – это каскадная модель с промежуточным контролем. Ошибки или недоработки предыдущих стадий, обнаруженные на последующих стадиях, устраняются путем возврата к предыдущим стадиям, то есть итерационным путем.
Рис. 6.1. Итерационная модель проектирования информационной системы
Следует обратить внимание на необходимость тщательной проработки начальных стадий проектирования. Известно, что устранение ошибок при создании системы на стадии технического проекта стоит в два раза дороже, чем на предпроектной стадии, а на последующих стадиях – в десять раз и более.
Можно выделить три укрупненные стадии проектирования информационной системы:
- Предпроектную, включающую стадии 1, 2, 3.
- Проектную стадию, включающую стадии 4, 5,6.
- Послепроектную стадию, включающую стадии 7,8.
Лекция 7. Состав работ на предпроектной стадии, стадии технического и рабочего проектирования, стадии ввода в действие ИС. (2 час).
Цель: рассмотреть состав работ на предпроектной стадии, ознакомиться со стадиями технического и рабочего проектирования и стадиями ввода в действие ИС.
Осваиваемые компетенции: ПК-10
Рассмотрим состав и содержание работ на различных стадиях.
Состав работ на предпроектных стадиях
Стадия 1. Формирование требований к автоматизированной системе
Главное на этой стадии – провести предпроектное обследование и дать технико-экономическое обоснование целесообразности создания системы. Формируются требования к функциональной части, обеспечивающим подсистемам, методу проектирования.
Стадия 2. Разработка концепции автоматизированной системы.
Включает научно – исследовательские работы, разработку нескольких вариантов системы и выбор оптимального. Выполняется ориентировочный расчет ожидаемой экономической эффективности и дается оценка научно – технического уровня системы на основании сбора данных об отечественных и зарубежных системах. Если первая и вторая стадии делались Исполнителем для Заказчика как рекомендации по системе, то следующая третья стадия направлена от Заказчика к Исполнителю как задание.
Стадия 3. Техническое задание.
Техническое задание – итог предпроектной работы по созданию информационной системы. Это документ, обращенный к Исполнителю. Главным здесь является состав функциональных задач будущей системы и требования к обеспечивающим подсистемам. Этот документ формируется по материалам первых двух стадий и состовляется в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
Состав работ на стадиях технического и рабочего проектирования
Стадия 4. Эскизный проект
Выполняется применительно к информационной системы в экономике редко. Цель – разработка предварительных решений.
Стадия 5. Технический проект.
Это – основная стадия. Здесь уточняется состав и количество технических средств системы с привязкой к узлам обработки данных. В части организационного обеспечения предлагаются изменения в организационной структуре управления (например, сливаются подразделения). В части информационного обеспечения выбирается система кодирования, и на этом основании Заказчиком (или Исполнителем) разрабатывается кодификатор технико – экономической информации. Проектируется база данных. Но главное здесь – алгоритмизация функциональных задач (не программирование). Разрабатываются формы документов. Составляется план мероприятий по подготовке объекта к внедрению системы. Проводится уточненный расчет ожидаемой экономической эффективности.
Стадия 6. Рабочая документация.
Эта стадия иногда называется рабочим проектом. Главное назначение: программирование или адаптация готовых программных средств. Кроме того, здесь составляются технологические инструкции, которые соответствуют должностным инструкциям, уточненным на стадии технического проектирования. В должностных инструкциях указывается, что нужно сделать, а в технологических – как это сделать.
При наличии прототипа системы стадии технического проекта и рабочей документации объединяются в одну проектную стадию.
Состав работ на стадиях ввода в действие и сопровождения информационной системы
Стадия 7. Ввод в действие
Осуществляется проведение опытной эксплуатации и сдача системы комиссии в постоянную эксплуатацию в соответствии с требованиями технического задания (ТЗ).
Стадия 8. Сопровождение автоматизированной системы
Цель сопровождения системы – поддержание эксплуатационных характеристик на проектном уровне. Сопровождение осуществляется Исполнителем (консультативная помощь, устранение недостатков, разработка предложений по развитию системы).
Лекция 8. Эксплуатация и сопровождение ИС (2 час).
Цель:
Осваиваемые компетенции: ПК-10
Основные требования при передаче ИС в эксплуатацию
1.«Передача ИС в промышленную эксплуатацию должна осуществляться после 3-х месячной опытной эксплуатации без сбоев и замечаний».
Решение:
- тщательное протоколирование службой эксплуатации всех инцидентов;
- еженедельный анализ причин сбоев и составление плана мероприятий по их устранению.
2.«В систему, сданную в промышленную эксплуатацию, не должны вноситься изменения».
Решение:
- тщательное предпроектное обследование,
- обоснованная постановка задачи.
3.«Разработчик не должен иметь доступа ни к данным, ни к коду систем, находящихся в промышленной эксплуатации».
Решение:
- При необходимости разработчик запрашивает диагностическую информацию в службе эксплуатации;
- Все изменения осуществляются специалистами службы эксплуатации.
4.«Специалисты службы эксплуатации должны быть полностью подготовлены к обслуживанию системы».
Решение:
Подготовка и передача в службу эксплуатации полного комплекса программных средств администрирования (средства по управлению пользователями, инструменты сбора статистики и оперативного мониторинга) с соответствующей эксплуатационной документацией.
Стадия сопровождения ИС
- Software Engineering Body of Knowledge (SWEBOK) –Свод знаний по программной инженерии
- SWEBOK:Сопровождение ПО –вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем.
- IEEE 1219 (Standard for Software Maintenance):Сопровождение ПО –модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении.
- ГОСТ Р ИСО/МЭК 12207:Сопровождение –процесс модификации программного продукта в части его кода и документации для решения возникающих проблем при эксплуатации или реализации потребностей в улучшениях тех или иных характеристик продукта.
Лекция 9. Состав, содержание и принципы организации информационного обеспечения ИС. (2 час).
Цель: изучить состав, содержание и принципы организации информационного обеспечения ИС
Осваиваемые компетенции: ОПК-1, ПК-20
Информационное обеспечение (ИО) - важнейшая обеспечивающая подсистема АИС - предназначена для снабжения пользователей информацией, характеризующей состояние управляемого объекта и являющейся основой для принятия управленческих решений.
ИО - это совокупность средств и методов построения информационной системы экономического объекта.
Информационное обеспечение можно разделить на внемашинное и внутримашинное. Внемашинное ИО — это системы показателей, классификаторов, кодов и документации. Внутримашинное ИО — это различные файлы на машинных носителях, автоматизированные банки данных (АБД).
Проектирования ИО, выполняется совместно с пользователями АИС, ведется с системных позиций параллельно с проектированием технологического, программного и математического обеспечения.
Состав информационного обеспечения:
- Базовые пространственные данные
- Метаданные
- Нормативно правовое обеспечение
- Классификаторы пространственных объектов
- Реестры.
Основным принципами при создании ИС являются стандартизация и совместимость. Суть принципа совместимости заключается в том, что при создании ИС должны быть реализованы информационные интерфейсы, благодаря которым она может взаимодействовать с другими ИС в соответствии с установленными правилами. Символы, коды, информационные и технические характеристики структурных связей между подсистемами и компонентами ИС должны быть согласованы так, чтобы обеспечивалось совместное функционирование всех подсистем ИС. В ИС должны использоваться единые термины, символы, условные обозначения и способы представления информации во всех автоматизированных задачах, комплексах задач, подсистемах. Этот принцип требует использования в ИС единой системы классификации и кодирования информации, единых правил сопоставления всех взаимосвязанных информационных показателей.
Принцип стандартизации (унификации) состоит в том, что подсистемы и компоненты системы должны быть по возможности типовыми. Этот принцип должен реализовываться путем:
- создания единой базы данных;
- использования единого информационного обеспечения;
- унификации алгоритмов решения задач, программных модулей, программ и т.п.
Очевидно, что реализация этих основных принципов создания ИС не возможно без системного подхода к разработке информационного обеспечения ИС. Напомним, что информационная система состоит их набора элементов (подсистем), находящихся в определенных отношениях друг с другом. Множество этих отношений совместно с каждым элементом системы образуют структуру ИС.
Лекция 10. Состав проектной документации (2 час).
Цель:
Осваиваемые компетенции: ОПК-1, ПК-20
Результатом этапа определения стратегии является документ ( технико-экономическое обоснование проекта ), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
Ориентировочное содержание этого документа:
- ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
- совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
- сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
- описание выполняемых системой функций;
- возможности развития системы;
- информационные объекты системы;
- интерфейсы и распределение функций между человеком и системой;
- требования к программным и информационным компонентам ПО, требования к СУБД;
- что не будет реализовано в рамках проекта.
Лекция 11. Проектирование документальных и фактографических ИС. (2 час).
Цель:
Осваиваемые компетенции: ПК-15
Документальные системы служат для работы с документами, в которых информация хранится в виде текстовых документов (статьи, книги, рефераты, тексты законов) и графических объектов, снабженная тем или иным формализованным аппаратом поиска. Цель системы, как правило, – выдать в ответ на запрос пользователя список документов или объектов, в какой-то мере удовлетворяющих сформулированным в запросе условиям.
Документальный поиск – информационный поиск, цель которого нахождение в хранилище ИПС документов, соответствующих полученному запросу. В реальных условиях документальный поиск осуществляется в два этапа: в хранилище вторичных документов, в хранилище первичных документов. Соответственно выделяют два вида документального поиска: библиографический и библиотечный.
Библиографический поиск – документальный поиск, осуществляемый с целью нахождения данных о первичных документах и их адресах. ИПС, обеспечивающая хранение вторичных документов и библиографический поиск называется библиографической информационно – поисковой системой.
Библиотечный поиск – документальный поиск, осуществляемый с целью нахождения первичных документов в их собрании. Соответствующая ИПС называется библиотечной.
При документальном поиске потребитель сам извлекает из документа интересующие его факты и идеи.
Автоматизация процесса информационного поиска потребовала формализации представления основного смыслового содержания документов в виде поискового предписания (ПП) и поисковых образов документов (ПОД). В процессе информационного поиска определяется степень соответствия содержания документов и запроса пользователя путем сопоставления ПОД и ПП. Решение о выдаче или не выдаче документа в ответ на запрос принимается на основе некоторого набора правил, по которому данная ИПС определяет степень смысловой близости между ПОД и ПП. Такой набор правил получил название критерия смыслового соответствия (КСС). Критерий может быть задан явно или неявно и базируется на понятии формальной релевантности ПОД и ПП.
Фактографические информационные системы оперируют фактическими сведениями, представляемыми в виде специальным образом организованных совокупностей формализованных записей данных. В фактографических ИС регистрируются факты – конкретные значения данных (атрибутов) об объектах реального мира. Основная идея таких систем заключается в том, что все сведения об объектах (фамилии людей и названия предметов, числа, даты) сообщаются компьютеру в каком-то заранее обусловленном формате (например, дата – в виде комбинации ДД.ММ.ГГГГ). Информация, с которой работает фактографическая ИС, имеет четкую структуру, позволяющую машине отличать одно данное от другого, – например, фамилию от должности человека, дату рождения от роста и т. п.
Центральным функциональным звеном фактографических информационных систем являются системы управления базами данных.
Современные СУБД оперируют огромными массивами информации, объемы которых достигают десятков терабайт. Выполняя запрос пользователя они должны обеспечит время отклика порядка нескольких секунд. Для этого во всех СУБД организован метод ускоренного доступа к данным. В настоящее время в СУБД используется два метода организации прямого доступа: индексирование и хэширование.
Лекция 12. Анализ предметной области, разработка состава и структуры баз данных, проектирование логико-семантического комплекса. (2 час).
Цель:
Осваиваемые компетенции: ПК-15
Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснения смысла высказанных требований, называется анализом предметной области (бизнес-моделированием, если речь идет о потребностях коммерческой организации). Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики должны научиться:
1. понимать язык, на котором говорят заказчики;
2. выявить цели их деятельности;
3.определить набор решаемых ими задач;
4. определить набор сущностей, с которыми приходится иметь дело при решении этих задач.
База данных (БД) - совокупность определенным образом организованной информации на какую-то тему (в рамках некоторой предметной области).
Документальные ИС обслуживают принципиально иной класс задач, которые не предполагают однозначного ответа на поставленный вопрос. Они оперируют неструктурированными текстовыми документами (статьи, книги, тексты законов и т.п.) и снабжены тем или иным формализованным аппаратом поиска. Цель такой системы, как правило, - выдать в ответ на запрос пользователя список документов, в какой-то мере удовлетворяющих сформулированным в запросе условиям. Например, выдать список всех статей, в которых встречается слово «СУБД».
Проектирование документальных баз данных - это итерационный, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной области, требований к данным со стороны прикладных программистов и пользователей, синтеза логических и физических структур данных, анализа и обоснования выбора программных и аппаратных средств.
Этапы проектирования баз данных связаны с многоуровневой организацией данных. Рассматривая вопрос проектирования баз данных, будем придерживаться такого многоуровневого представления данных: внешнего, инфологического, логического (даталогического) и внутреннего.
Внешний уровень в этом случае выступает как отдельный этап проектирования, на котором изучается все внемашинное информационное обеспечение, то есть формы документирования и представления данных, а также внешняя среда, в которой будет функционировать банк данных с точки зрения методов фиксации, сбора и передачи информации в базу данных.
Инфологический уровень представляет собой информационно-логическую модель (ИЛМ) предметной области, из которой исключена избыточность данных и отображены информационные особенности объекта управление без учета особенностей и специфики конкретной СУБД. То есть инфологическое представление данных ориентировано преимущественно на человека, который проектирует или использует базу данных.
Логический (концептуальный) уровень построен с учетом специфики и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической.
Внутренний уровень связан с физическим размещением данных в памяти ЭВМ. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, порядок их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным.
Целью проектирования на внешнем уровне является разработка внемашинного информационного обеспечения, которое включает систему входной (первичной) документации, характеризующую определенную предметную область, систему классификации и кодирования технико-экономической информации, а также перечень соответствующих выходных сообщений, которые нужно формировать с помощью БД.
Существуют два подхода к проектированию баз данных на внешнем уровне: «от предметной области» и «от запроса».
Подход «от предметной области» состоит в том, что формируется внешнее информационное обеспечение всей предметной области без учета потребностей пользователей и прикладных программ. Иногда этот подход называют еще объектным или непроцессным.
Однако взятый в отдельности любой из этих методов не может дать достаточно информации для проектирования рациональной структуры БД. Поэтому при проектировании БД целесообразно совместно использовать эти два подхода. Если схематично представить процесс проектирования БД на внешнем уровне, то он состоит из таких работ:
1) Определение функциональных задач предметной области, которые подлежат автоматизированному решению.
2) Изучение и анализ оперативных первичных документов.
3) Изучение нормативно-справочных документов.
4) Изучение процессов преобразования входных сообщений в выходные.
Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.
Лекция 13. Технология проектирования ИС по архитектуре файл-сервер. Особенности проектирования ИС по технологии файл-сервер. (2 час).
Цель:
Осваиваемые компетенции: ПК-10
По всей видимости, организация информационных систем на основе использования выделенных файл-серверов все еще является наиболее распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети. Чем привлекает такая организация не очень опытных в области системного программирования разработчиков информационных систем? Скорее всего, тем, что при опоре на файл-серверные архитектуры сохраняется автономность прикладного (и большей части системного) программного обеспечения, работающего на каждой PC сети. Фактически, компоненты информационной системы, выполняемые на разных PC, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждой PC дублируются не только прикладные программы, но и средства управления базами данных. Файл-сервер представляет собой разделяемое всеми PC комплекса расширение дисковой памяти (рисунок 13.1).
Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. (Как гласит русская пословица, "Простота хуже воровства", а здесь мы, как правило, имеем простоту на основе воровства программных продуктов для PC.)
Рис. 13.1. Классическое представление информационной системы в архитектуре "файл-сервер"
Во-первых, информационной системе предстоит работать с базой данных. Следовательно, эта база данных должна быть спроектирована. Почему-то часто разработчики файл-серверных приложений считают, что по причине простоты средств управления базами данных проблемой проектирования базы данных можно пренебречь. Конечно, это неправильно. База данных есть база данных. Чем качественнее она спроектирована, тем больше шансов впоследствии эффективно использовать информационную систему. Естественно, сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области.
Во-вторых, как мы неоднократно подчеркивали в первой части курса, необходимыми требованиями к базе данных информационной системы являются поддержание ее целостного состояния и гарантированная надежность хранения информации. Минимальными условиями, при соблюдении которых можно удовлетворить эти требования, являются:
наличие транзакционного управления,
хранение избыточных данных (например, с применением методов журнализации),
возможность формулировать ограничения целостности и проверять их соблюдение.
В принципе, файл-серверная организация, как она показана на рисунке 13.1, не противоречит соблюдению отмеченных условий. В качестве примера системы, соблюдающей выполнение этих условий, но основанной на файл-серверной архитектуре, можно привести популярный в прошлом "сервер баз данных" Informix SE.
Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Конечно, и в этом случае требуется большая аккуратность конечных пользователей (или администраторов, наличие которых в этом случае сомнительно) для надежного хранения и поддержания целостного состояния данных. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными.
Лекция 14. Оптимизация и администрирование ИС. (2 час).
Цель:
Осваиваемые компетенции: ПК-10
Очень часто купленное программное обеспечение работает не так как хотелось бы или постоянно сбоит. Связано это может быть с неверно выбранной архитектурой построения информационных систем на предприятии – настройкой локальных сетей и серверов, связи между офисами, используемыми платформами.
Наличие в нашей компании нескольких разнопрофильных отделов и инженеров высокой квалификации, которые выступают системными архитекторами, позволяет нам выполнять сложные проекты и добиваться от максимальной отдачи от используемого программного обеспечения.
Грамотно продуманная архитектура построения информационных систем позволяет:
- Получить высокую скорость работы программного обеспечения.
- Выбрать оптимальную аппаратную платформу для работы.
- Обеспечить он-лайн и просто стабильную связь со всеми подразделениями.
- Сконфигурировать программное обеспечение под нужды предприятия.
Для большинства предметных областей внедрения информационных технологий характерны высокие требования к качеству их работы и надёжности эксплуатации, от которых во многом зависит эффективность использования и возврата вложенных средств. Эти требования относятся к проблемам, связанным с администрированием ИС, которые представляют собой сетевой программно-аппаратный и информационный ресурс.
Администрирование (административные механизмы) – это процедуры управления, регламентирующие некоторые процессы или их часть.
В большинстве случаев оно входит в полномочия администратора ИС, который фиксирует и руководит соответствующими его полномочиям процессами и ситуациями, нуждающимися в целевом управлении и ограничениях.
Лекция 15. Технология проектирования ИС по архитектуре клиент-сервер (2 час).
Цель:
Осваиваемые компетенции: ПК-10
Применительно к системам баз данных архитектура "клиент-сервер" интересна и актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети. В некотором роде системы баз данных, основанные на архитектуре "клиент-сервер", являются приближением к распределенным системам баз данных, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно распределенных баз данных.
Реальное распространение архитектуры "клиент-сервер" стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем. Поэтому мы начнем с краткого введения в открытые системы.
Основным смыслом подхода открытых систем является упрощение комплексирования вычислительных систем за счет международной и национальной стандартизации аппаратных и программных интерфейсов. Главной побудительной причиной развития концепции открытых систем явились повсеместный переход к использованию локальных компьютерных сетей и необходимость решения проблем комплексирования аппаратно-программных средств, которые вызвал этот переход. В связи с бурным развитием технологий глобальных коммуникаций открытые системы приобретают еще большее значение и масштабность.
Ключевой фразой открытых систем, направленной в сторону пользователей, является независимость от конкретного поставщика. Ориентируясь на продукцию компаний, придерживающихся стандартов открытых систем, потребитель, который приобретает любой продукт такой компании, не попадает к ней в рабство. Он может продолжить наращивание мощности своей системы путем приобретения продуктов любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных, так и программных средств и не является необоснованной декларацией. Реальная возможность независимости от поставщика проверена в отечественных условиях.
Практической опорой системных и прикладных программных средств открытых систем является стандартизованная операционная система. В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось придти к соглашению об основных стандартах этой операционной системы. Сейчас все распространенные версии UNIX в основном совместимы по части интерфейсов, предоставляемых прикладным (а в большинстве случаев и системным) программистам. Как кажется, несмотря на появление претендующей на стандарт системы Windows NT, именно UNIX останется основой открытых систем в ближайшие годы.
Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту переноса программной системы в широком спектре аппаратно-программных средств, соответствующих стандартам. Интероперабельность означает возможность упрощения комплексирования новых программных систем на основе использования готовых компонентов со стандартными интерфейсами.
Использование подхода открытых систем выгодно и производителям, и пользователям. Прежде всего открытые системы обеспечивают естественное решение проблемы поколений аппаратных и программных средств. Производители таких средств не вынуждаются решать все проблемы заново; они могут, по крайней мере, временно продолжать комплексировать системы, используя существующие компоненты.
Заметим, что при этом возникает новый уровень конкуренции. Все производители обязаны обеспечить некоторую стандартную среду, но вынуждены добиваться как можно лучшей ее реализации. Конечно, через какое-то время существующие стандарты начнут играть роль сдерживания прогресса, и тогда их придется пересматривать.
Преимуществом для пользователей является то, что они могут постепенно заменять компоненты системы на более совершенные, не утрачивая работоспособности системы. В частности, в этом кроется решение проблемы постепенного наращивания вычислительных, информационных и других мощностей компьютерной системы.
Лекция 16. Особенности проектирования ИС по технологии клиент-сервер (2 час).
Цель:
Осваиваемые компетенции: ПК-10
Одна из моделей взаимодействия компьютеров в сети получила название «клиент-сервер» (Рис. 1.). Каждый из составляющих эту архитектуру элементов играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность воспользоваться ими.
Сервер базы данных представляет собой мультипользовательскую версию СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. В его задачу входит реализация логики обработки транзакций с применением необходимой техники синхронизации - поддержки протоколов блокирования ресурсов, обеспечение, предотвращение и/или устранения тупиковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (Front - end) централизованной системы управления данными. Это позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить рабочие станции и при достаточно мощной центральной машине использовать для них более дешевое оборудование.
Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они входят в состав или образуют систему распределенной обработки данных.
Для современных СУБД архитектура «клиент-сервер» стала фактически стандартом. Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т. е. часть функций приложений будет реализована в программе-клиенте, другая - в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:
- функции ввода и отображения данных;
- прикладные функции, характерные для предметной области;
- фундаментальные функции хранения и управления ресурсами (базами данных);
- служебные функции.
Исходя из этого деления любое приложение может состоять из следующих компонентов:
- компонент представления (функции 1-й группы);
- прикладной компонент (функции 2-й группы);
- компонент доступа к информационным ресурсам (функции 3-ей группы и протокол их взаимодействия).
Различия определяются четырьмя факторами:
- какие виды программного обеспечения в логических компонентах;
- какие механизмы программного обеспечения используются для реализации функций трех групп;
- как логические компоненты распределяются компьютерами в сети;
- какие механизмы используются для связи компонент между собой.
Лекция 17. Автоматизированное проектирование ИС с использованием CASE технологий. Основные понятия и содержание автоматизированного проектирования ИС. Обзор CASE средств (2 час).
Цель:
Осваиваемые компетенции: ПК-23
Проектирование ИС с применением компьютерной поддержки, называется CASE – технологии проектирования. CASE – технологии применяются не только для автоматизации проектирования ИС, но и для разработки моделей бизнес-процессов при проведении бизнес-анализа. CASE – технологии применяются в ситуациях, когда проблематика предметной области отличается большой сложностью.
Можно выделить следующие основные принципы создания ИС на основе CASE – технологий:
1. принцип всесторонней компьютерной поддержки проектирования.
2. принцип модельного подхода. CASE – система может поддерживать методологию функционально –ориентированного или объектно-ориентированного подхода
3. принцип иерархического представления модели предметной области. Данный принцип выражается в возможности последовательной детализации (декомпозиции) описания системы в соответствии с нисходящим подходом проектирования.
4. принцип наглядности представления модели –означает наличие в составе CASE –технологий визуальных средств проектирования. Система графических изображения и правила, предназначенные для описания структуры системы, элементов данных и т.д., называются нотацией Case – средства.
5. принцип декомпозиции процесса ПИС с применением CASE –технологий на стадии и этапы.
Можно привести много примеров различных классификаций CASE-средств, встречающихся в литературе. Остановимся на двух наиболее распространенных вариантах: по типам и категориям. Классификация по т и п а м отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и включает следующие типы:
- средства анализа, предназначенные для построения и анализа моделей предметной области (Designer/IDEF; BP-win и ARIS).
- средства анализа и проектирования, поддерживающие наиболее распространенные методологии проектирования, которые используются для создания проектных спецификаций, в частности проектных компонентов интерфейсов системы, архитектуры системы, алгоритмов и структур данных: Vantage Team Builder, Designer/2000, Silverran, PRO-4, CASE-аналитик, ARIS.
- средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL — Structured Query Language — структурированном языке запросов) для наиболее распространенных СУБД: ER-win, S-Designer/2000, Data Base Designer, ARIS Tooleset.
- Средства разработки приложений и генераторы кода, входящая в состав Uniface, Jam, Power Builder, Developer/2000, Delphi и т.д.
- Средства реинжиниринга, обеспечивающие анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций: ER-win, Vantage.Team Builder, Silverran, PRO-4, ARIS Tooleset, Designer/2000 и т.д. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программы на языке C++, Rational Rose, Object Team.
Вспомогательные типы включают:
1) Средства планирования и управления проектом (Microsoft Project, SE Companion)
2) Средства конфигурационного управления (PVCS)
3) Средства тестирования (Quality Works)
4) Средства документирования (SoDa)
По степени интегрированности выделяют:
1) Локальные CASE-средства – применяются для анализа системы и разработки автоматизированных рабочих мест, поддерживают 1, 2 типа моделей и методов (CASE-аналитик, Design/IDEF)
2) Малые интегрированные CASE-средства, используются для создания небольших ИС, поддерживают несколько типов моделей и методов (ER-win, BP-win, , Silverran)
3) Средние интегрированные CASE-средства – поддерживают от 4-15 моделей и методов. В этой категории Rational Rose, Designer/2000.
4) Крупные интегрированные CASE-средства, поддерживаются свыше 15 типов моделей и методов. Пр-р: семейство программных продуктов ARIS.
Лекция 18. Функционально ориентированный подход проектирования ИС. Применение структурного (функционального) подхода к проектированию ИС (2 час).
Цель:
Осваиваемые компетенции: ПК-20, ПК-23
Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.
Методологию IDEF0O можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис. 1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
верхняя сторона имеет значение «Управление» (Control);
левая сторона имеет значение «Вход» (Input);
правая сторона имеет значение «Выход» (Output);
нижняя сторона имеет значение «Механизм» (Mechanism).
Рис.1.
Функциональный блок
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 - диаграмм, функциональных блоков, интерфейсных дуг - существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.
Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот - отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала «погружаются в туннель», а затем при необходимости «возвращаются из туннеля».
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов:
Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.
Лекция 19. Диаграммы функциональных спецификаций, потоков данных, переходов состояний (2 час).
Цель:
Осваиваемые компетенции: ПК-20, ПК-23
Спецификации процессов.Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов,Flow-форм или диаграмм Насси-Шнейдермана. Поскольку описание процесса должно быть кратким и понятным как разработчику, так и заказчику, для их спецификации чаще всего используют псевдокоды.
Словарь терминов.Словарь терминов представляет собой краткое описание основных понятий, используемых при составлении спецификаций. Он должен включать определение основных понятий предметной области, описание структур элементов данных, их типов и форматов, а также всех сокращений и условных обозначений. Он предназначен для повышения степени понимания предметной области и исключения риска возникновения разногласий при обсуждении моделей между заказчиками и разработчиками.
Обычно описание термина в словаре выполняют по следующей схеме:
• термин; категория (понятие предметной области, элемент данных, условное обозначение и т.д.); краткое описание.
Рисунок – Элементы полной спецификации методологий структурного анализа и проектирования ПО, основанных на потоках данных
Диаграмма переходов состояний является графической формой предоставления конечного автомата – математической абстракции, используемой для моделирования детерминированного поведения технических объектов или объектов реального мира.
На этапе анализа требований и определения спецификаций диаграмма переходов состояний демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий. Подуправляющими воздействиями или сигналами в данном случае понимают управляющую информацию, получаемую системой извне. Например, управляющими воздействиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной системе. Получив такое управляющее воздействие, разрабатываемая система должна выполнить определенные действия и или остаться в том же состоянии, или перейти в другое состояние взаимодействия с внешней средой.
Для построения диаграммы переходов состояний необходимо в соответствии с теорией конечных автоматов определить: основные состояния, управляющие воздействия (или условия перехода), выполняемые действия и возможные варианты переходов из одного состояния в другое. Условные обозначения, используемые при построении диаграмм переходов состояний, показаны на рисунке.
Рисунок – Условные обозначения диаграмм переходов состояний
Если программная система в процессе функционирования активно не взаимодействует с окружающей средой (пользователем или датчиками), например, использует примитивный интерфейс и выполняет некоторые вычисления по заданным исходным данным, то диаграмма переходов состояний обычно интереса не представляет. В этом случае она демонстрирует только последовательно выполняемые переходы: из исходного состояния в состояние ввода данных, затем после выполнения вычислений – в состояние вывода и, наконец, в состояние завершения работы (см. рисунок).
Рисунок – Диаграмма переходов состояний ПО, активно не взаимодействующего с окружающей средой
Для интерактивного программного обеспечения с развитым пользовательским интерфейсом основные управляющие воздействия – команды пользователя, для программного обеспечения реального времени – сигналы от датчиков и/или оператора производственного процесса. Общим для этих типов программного обеспечения является наличие состояния ожидания, когда программное обеспечение приостанавливает работу до получения очередного управляющего воздействия. Для интерактивного программного обеспечения наиболее характерно получение команд различных типов (рис. 4.5), а если это еще и программное обеспечение реального времени – однотипных сигналов (либо от многих датчиков, либо требующих продолжительной обработки).
Функциональныминазывают диаграммы, в первую очередь отражающиевзаимосвязи функцийразрабатываемого программного обеспечения. В качестве примера функциональной модели рассмотрим активностную модель, предложенную Д. Россом в составе методологии функционального моделированияSADT(StructuredAnalysisandDesignTechnique- технология структурного анализа и проектирования) в 1973 г
Лекция 20. Объектно-ориентированный подход проектирования ИС. Применение объектно-ориентированного подхода к проектированию ИС. (2 час).
Цель:
Осваиваемые компетенции: ПК-20, ПК-23
Объектно-ориентированнный подход в проектировании, как и функционально-ориентированный, предполагает декомпозицию ИС. Если в функционально-ориентированном подходе декомпозиции подлежали процессы обработки, то в объектно-ориентированном подходе декомпозиции подлежат объекты, которые характеризуются определенной структурой данных. Здесь декомпозиция идет от данных. В объектно-ориентиро-ванном подходе выделяют классы объектов. Каждый класс содержит однородные объекты. Объектам одного класса присуще одинаковое множество методов реагирования на внешние сообщения. Иерархическая декомпозиция системы представляется в виде иерархии классов объектов, а функционирование системы – в виде взаимодействия объектов, обменивающихся сообщениями.
Среди свойств объектов в объектно-ориентированном подходе отметим следующие:
инкапсуляция, что означает скрытие информации. Смысл этого свойства в том, что состав и структура атрибутов объекта не зависит от сообщений, поступающих извне;
наследование – это свойство, связанное с выделением иерархических классов объектов, то есть существуют родительские и дочерние классы. Оно проявляется в том, что методы реагирования объекта, предусмотренные родительским классом, автоматически присваивают объектам дочерних классов, то есть родительские классы имеют общие методы, а дочерние – как общие, так и частные;
полиморфизм – возможность выбора объектом в ответ на получаемые им сообщения какого-либо метода из множества методов в зависимости от того, какое пришло сообщение.
Наличие этих свойств у объекта позволяет в объектно-ориенти-рованном подходе добиться параллельности и автономности разработки отдельных компонент системы, т.е. возможно создание прототипов с дальнейшей интеграцией отдельных прототипов в единую систему и использование итерационного подхода к разработке ИС.
Другое достоинство объектно-ориентированного подхода состоит в упрощении накопления типовых проектных решений с тем, чтобы в дальнейших разработках новых ИС осуществить сбор новой системы из готовых компонент. Эта особенность связана с тем, что классы объектов повторяются в определенной мере при переходе от одной ИС к другой, а для повторяющихся классов уже запрограммированы методы, разработаны и описаны структуры объектов данных.
Модель проектирования ИС на основе объектно-ориентированного подхода представлена на рисунке1.
Рисунок 1. Модель проектирования информационной системы на основе объектно-ориентированного подхода
На стадии анализа предметной области определяются объекты и их классы и осуществляется объектная декомпозиция системы.
На стадии проектирования детализируется объектно-ориентированная модель системы. Разрабатываются структуры данных, методы реагирования объектов, отношения между классами и сценарии взаимодействия объектов.
На стадии программирования осуществляется разработка программного обеспечения по отдельным компонентам, тестирование и сборка. То есть происходит постепенное создание (эволюция) системы.
Модификация системы не требует полного пересмотра проекта, затрагивая лишь соответствующие классы и объекты.
Отличительной чертой модели объектно-ориентированного проектирования является отсутствие строгой последовательности в выполнении стадий как в прямом, так и в обратном направлениях процесса проектирования по отдельным компонентам.
Основное преимущество объектно-ориентированного подхода состоит в упрощении проектирования ИС при наличии типовых проектных решений по отдельным компонентам, а также легкости модификации, поскольку модификация касается лишь отдельных компонент.
Следует отметить, что объектно-ориентированный подход трудно воспринимается пользователями и руководством предприятия и прежде всего предназначен для программистов. Пользователям понятнее функционально-ориентированный подход. Экономическая эффективность применения объектно-ориентированного подхода возрастает по мере приобретения опыта у разработчиков в большей мере, чем при функционально-ориентированном подходе. Можно сказать, что время разработки также снижается. Эти тенденции иллюстрируются на рисунке 2 .
Рисунок 2 – Зависимость эффективности применения функционально-ориентированного и объектно-ориентированного подходов от количества выполненных проектов
Лекция 21. Основные сведения о языке UML. Диаграммы классов, состояний, компонентов. Инструментальные средства поддержки CASE технологий, реализующие объектно-ориентированный подход. (2 час).
Цель:
Осваиваемые компетенции: ПК-20, ПК-23
Унифицированный язык моделирования (Unified Modeling Language - UML) это язык для специфицирования, визуализации, конструирования и документирования программных систем, а так же бизнес моделей и прочих не программных систем. UML представляет собой объединение инженерных приемов, которые ранее успешно использовались при моделировании больших и сложных систем
Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы. UML определяет нотацию и метамодель. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования.
UML предоставляет выразительные средства для создания визуальных моделей, которые:
единообразно понимаются всеми разработчиками, вовлеченными в проект;
являются средством коммуникации в рамках проекта.
Унифицированный Язык Моделирования (UML):
не зависит от объектно-ориентированных (ОО) языков программирования;
не зависит от используемой методологии разработки проекта;
может поддерживать любой ОО язык программирования.
UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга.