thtk.1mcg.ru · web viewМетодические указания к практическим...

Министерство образования Тверской области

Государственное бюджетное профессиональное

образовательное учреждение

«Тверской химико-технологический колледж»

Цикловая комиссия дисциплин профессионального цикла

УЧЕБНО-МЕТОДИЧЕСКИЙ

КОМПЛЕКС

междисциплинарного курса

МДК.01.02. Методы и средства проектирования

информационных систем

для специальности

09.02.04 Информационные системы (по отраслям)

базовой подготовки

Тверь, 2019

Рассмотрено

цикловой комиссией

дисциплин профессионального цикла

Протокол № ___

от «___» __________ 2019 г.

Председатель ЦК

__________ Н.В. Королёва

Принято

Методическим советом

Протокол № ___

от «___» __________ 2019 г.

Зам. руководителя по УР

__________ И.Н. Горло

Разработчик: Пирогова А.А., преподаватель

СОДЕРЖАНИЕ

1. ПОЯСНИТЕЛЬНАЯ ЗАПИСКА 3

2. ВЫПИСКА ИЗ ФГОС СПО 6

3. РАБОЧАЯ ПРОГРАММА ПРОФЕССИОНАЛЬНОГО МОДУЛЯ 12

4. КУРС ЛЕКЦИЙ ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ 57

5. МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ПРАКТИЧЕСКИМ

ЗАНЯТИЯМ ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ 178

6. МЕТОДИЧЕСКИЕ УКАЗАНИЯ К САМОСТОЯТЕЛЬНОЙ

РАБОТЕ ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ 324

7. КОМПЛЕКТ ОЦЕНОЧНЫХ СРЕДСТВ

ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ 330

8. СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ 337

1. ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

Учебно-методический комплекс (далее – УМК) разработан в качестве учебно-

методического обеспечения междисциплинарного курса МДК.01.02. Методы и средства

проектирования информационных систем (далее – МДК) в рамках освоения студентами

Программы подготовки специалистов среднего звена (далее – ППССЗ) по специальности

09.02.04 Информационные системы (по отраслям) базовой подготовки.

Цель создания УМК – обеспечить качественное методическое оснащение учебно-

воспитательного процесса, способствующее подготовке высококвалифицированных,

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

требуемыми Федеральным государственным образовательным стандартом среднего

профессионального образования (далее – ФГОС СПО) по специальности 09.02.04

Информационные системы (по отраслям) базовой подготовки в части освоения указанного

МДК.

Нормативно-методической основой разработки УМК являются:

- Федеральный государственный образовательный стандарт среднего

профессионального образования по специальности 09.02.04 Информационные системы

(по отраслям), утвержденный приказом Министерства образования и науки РФ № 525 от

14.05.2014;

- «Положение об учебно-методическом комплексе» ГБП ОУ «Тверской химико-

технологический колледж»;

- другие локальные акты колледжа.

УМК представляет собой систематизированный комплект учебных и методических

материалов, а также дидактических средств обучения. УМК имеет следующую структуру:

1) пояснительная записка;

2) выписка из ФГОС СПО;

3) рабочая программа;

4) курс лекций;

5) методические указания к практическим занятиям;

6) методические указания к самостоятельной работе;

7) комплект оценочных средств;

8) список информационных источников.

УМК выполнен в печатном и электронном вариантах.

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

разработки УМК, характеристику его составляющих, требования к материально-

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

Выписка из ФГОС СПО характеризует место МДК в структуре ППССЗ, содержит

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

формируемые общие и профессиональные компетенции.

Рабочая программа МДК разработана в соответствии с «Разъяснениями по

формированию примерных программ учебных дисциплин начального профессионального

и среднего профессионального образования на основе ФГОС НПО и СПО» (утв.

Департаментом государственной политики в образовании Министерства образования и

науки РФ 27.08.2009). Структура рабочей программы (далее – РП):

- паспорт РП (область применения программы, цели и задачи модуля – требования

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

профессионального модуля (далее – ПМ));

- результаты освоения ПМ;

- структура и содержание ПМ (тематический план и содержание обучения по ПМ);

- условия реализации РП (требования к минимальному материально-техническому

обеспечению, информационное обеспечение обучения, общие требования к организации

образовательного процесса, кадровое обеспечение образовательного процесса);

- контроль и оценка результатов освоения ПМ (ВПД).

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

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

дополнен наглядными средствами (таблицы, схемы, диаграммы и др.), заданиями для

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

Методические указания к практическим занятиям предназначены для оказания

помощи студентам в выполнении практических работ по МДК. Основная цель

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

знаний, требуемых ФГОС СПО. Методические указания содержат перечень практических

работ по МДК, подробные (пошаговые) методические указания к каждой практической

работе, инструкцию по технике безопасности, список используемых информационных

источников.

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

помощи студентам в выполнении самостоятельной работы по МДК. Методические

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

применить знания, требуемые ФГОС СПО. По каждому виду деятельности приводится

перечень тем, подробные (пошаговые) методические указания по выполнению задания,

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

Комплект оценочных средств (далее – КОС) предназначен для проведения

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

требованиям ППССЗ (текущий контроль успеваемости и промежуточная аттестация).

КОС позволяет оценить освоенные компетенции, практический опыт, умения, знания.

КОС разработан в соответствии с «Положением о формировании фонда оценочных

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

обучающихся» и имеет следующую структуру:

- паспорт КОС (контроль и оценка результатов обучения по МДК в целом, по

разделам и темам МДК, правила оформления результатов оценивания);

- типовые задания для оценки освоения МДК (текущий контроль, промежуточная

аттестация);

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

Аудиторные занятия по МДК проводятся в лаборатории информационных систем,

имеющей следующий перечень оборудования:

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

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

доступом к сети Интернет;

- программное обеспечение общего и профессионального назначения;

- наглядные пособия;

- информационно-коммуникативные средства;

- экранно-звуковые пособия;

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

инструкции по их использованию и технике безопасности;

- библиотечный фонд;

- доступ к электронным учебным материалам по МДК, имеющимся в свободном

доступе в Интернете (электронным книгам, практикумам, тестам и др.).

Планируемые результаты внедрения УМК:

- обеспечение целостности и системности учебной деятельности при освоении

МДК;

- повышение продуктивности учебной деятельности студентов (как аудиторной,

так и самостоятельной), способствующее эффективному формированию

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

познавательных и созидательных способностей личности;

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

самостоятельную работу студентов;

- совершенствование методики проведения занятий.

2. ВЫПИСКА ИЗ ФГОС СПО

Наименование нормативного документа

Федеральный государственный образовательный стандарт среднего

профессионального образования по специальности 09.02.04 Информационные системы

(по отраслям) (утв. приказом Министерства образования и науки Российской Федерации

№ 525 от 14.05.14).

Индекс и наименование междисциплинарного курса в соответствии с учебным

планом

МДК.01.02. Методы и средства проектирования информационных систем

Характеристика подготовки по специальности (п. 3.2 ФГОС СПО) (таблица 2.1)

Таблица 2.1 – Характеристика подготовки по специальности

Уровень образования, необходимый для приема на

обучение по ППССЗ

Наименование квалификации базовой

подготовки

Срок получения СПО по ППССЗ базовой подготовки в

очной форме обучениясреднее общее образование Техник по

информационным системам

2 года 10 месяцевосновное общее образование 3 года 10 месяцев

Характеристика профессиональной деятельности выпускников (пп. 4.1-4.3 ФГОС

СПО)

1. Область профессиональной деятельности выпускников: создание и эксплуатация

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

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

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

разработки информационных систем и бизнес-приложений; реализация проектных

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

оптимизаций и развития информационных систем.

2. Объектами профессиональной деятельности выпускников являются:

программы и программные компоненты бизнес-приложений;

языки и системы программирования бизнес-приложений;

инструментальные средства для документирования;

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

информационных системах;

инструментальные средства управления проектами;

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

стандарты и методы информационного взаимодействия систем;

первичные трудовые коллективы.

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

деятельности:

3.1. Эксплуатация и модификация информационных систем.

3.2. Участие в разработке информационных систем.

3.3. Выполнение работ по одной или нескольким профессиям рабочих, должностям

служащих (приложение к ФГОС СПО).

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

звена (таблица 3, пп. 5.1-5.2 ФГОС СПО) (таблица 2.2)

Таблица 2.2 – Требования к результатам освоения ППССЗ

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

Индекс и наименование

дисциплин, междисциплинарных

курсов (МДК)

Коды формируем

ых компетенци

йП.00 Профессиональный циклПМ.00 Профессиональные модули

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

МДК.01.02. Методы и средства проектирования информационных систем

ОК 1-9ПК 1.1-1.10

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

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

1. Техник по информационным системам должен обладать общими

компетенциями, включающими в себя способность:

ОК 1. Понимать сущность и социальную значимость своей будущей профессии,

проявлять к ней устойчивый интерес.

ОК 2. Организовывать собственную деятельность, выбирать типовые методы и

способы выполнения профессиональных задач, оценивать их эффективность и качество.

ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за

них ответственность.

ОК 4. Осуществлять поиск и использование информации, необходимой для

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

развития.

ОК 5. Использовать информационно-коммуникационные технологии в

профессиональной деятельности.

ОК 6. Работать в коллективе и команде, эффективно общаться с коллегами,

руководством, потребителями.

ОК 7. Брать на себя ответственность за работу членов команды (подчиненных),

результат выполнения заданий.

ОК 8. Самостоятельно определять задачи профессионального и личностного

развития, заниматься самообразованием, осознанно планировать повышение

квалификации.

ОК 9. Ориентироваться в условиях частой смены технологий в профессиональной

деятельности.

2. Техник по информационным системам должен обладать профессиональными

компетенциями, соответствующими видам деятельности:

2.1. Участие в разработке информационных систем.

ПК 1.1. Собирать данные для анализа использования и функционирования

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

участие в разработке проектной документации на модификацию информационной

системы.

ПК 1.2. Взаимодействовать со специалистами смежного профиля при разработке

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

ПК 1.3. Производить модификацию отдельных модулей информационной системы

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

ПК 1.4. Участвовать в экспериментальном тестировании информационной системы

на этапе опытной эксплуатации, фиксировать выявленные ошибки кодирования в

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

ПК 1.5. Разрабатывать фрагменты документации по эксплуатации информационной

системы.

ПК 1.6. Участвовать в оценке качества и экономической эффективности

информационной системы.

ПК 1.7. Производить инсталляцию и настройку информационной системы в рамках

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

ПК 1.8. Консультировать пользователей информационной системы и разрабатывать

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

ПК 1.9. Выполнять регламенты по обновлению, техническому сопровождению и

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

документацией.

ПК 1.10. Обеспечивать организацию доступа пользователей информационной

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

3. РАБОЧАЯ ПРОГРАММА ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

3.1 Паспорт рабочей программы профессионального модуля

3.1.1 Область применения программы

Рабочая программа профессионального модуля (далее – программа) является

частью программы подготовки специалистов среднего звена (далее – ППССЗ) базовой

подготовки

в соответствии с ФГОС СПО по специальности 09.02.04 Информационные

системы (по отраслям) в части освоения вида деятельности:

ВД 1. Эксплуатация и модификация информационных систем

и соответствующих профессиональных компетенций (ПК):

ПК 1.1. Собирать данные для анализа использования и функционирования

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

участие в разработке проектной документации на модификацию информационной

системы.

ПК 1.2. Взаимодействовать со специалистами смежного профиля при разработке

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

ПК 1.3. Производить модификацию отдельных модулей информационной системы

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

ПК 1.4. Участвовать в экспериментальном тестировании информационной системы

на этапе опытной эксплуатации, фиксировать выявленные ошибки кодирования в

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

ПК 1.5. Разрабатывать фрагменты документации по эксплуатации информационной

системы.

ПК 1.6. Участвовать в оценке качества и экономической эффективности


ПК 1.7. Производить инсталляцию и настройку информационной системы в рамках

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

ПК 1.8. Консультировать пользователей информационной системы и разрабатывать

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

ПК 1.9. Выполнять регламенты по обновлению, техническому сопровождению и

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

документацией.

ПК 1.10. Обеспечивать организацию доступа пользователей информационной

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

в соответствии с Профессиональным стандартом 06.015 Специалист по

информационным системам в части выполнения обобщенной трудовой функции (ОТФ):

А. Техническая поддержка процессов создания (модификации) и

сопровождения ИС, автоматизирующих задачи организационного управления и

бизнес-процессы (уровень квалификации 4)

и соответствующих трудовых функций (ТФ):

А/04.4. Модульное тестирование ИС (верификация) в соответствии с трудовым

заданием.

А/05.4. Интеграционное тестирование ИС (верификация) в соответствии с

трудовым заданием.

А/06.4. Исправление дефектов и несоответствий в коде ИС и документации к ИС

согласно трудовому заданию.

А/07.4. Техническое обеспечение процесса обучения пользователей ИС.

А/08.4. Развертывание рабочих мест ИС у заказчика.

А/09.4. Установка и настройка системного и прикладного ПО, необходимого для

функционирования ИС в соответствии с трудовым заданием.

А/10.4. Настройка оборудования, необходимого для работы ИС в соответствии с


А/11.4. Интеграция ИС с существующими ИС заказчика в соответствии с трудовым

заданием.

А/12.4. Проведение физических аудитов в области качества в соответствии с


А/13.4. Демонстрация заказчику выполнения его требований к ИС в соответствии с


А/14.4. Идентификация конфигурации ИС в соответствии с трудовым заданием.

А/15.4. Представление отчетности по статусу конфигурации в соответствии с


А/16.4. Проведение физических аудитов конфигурации ИС в соответствии с


А/17.4. Инженерно-техническая поддержка заключения договоров на выполняемые

работы, связанные с ИС в соответствии с трудовым заданием.

А/18.4. Регистрация запросов заказчика в соответствии с трудовым заданием.

А/19.4. Инженерно-техническая поддержка заключения договоров сопровождения

ИС в соответствии с трудовым заданием.

А/20.4. Закрытие запросов заказчика в соответствии с трудовым заданием.

А/21.4. Распространение информации о выполненном задании.

Программа профессионального модуля предназначена для изучения в

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

ППССЗ по специальности 09.02.04 Информационные системы (по отраслям).

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

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

переподготовки и при освоении профессий:

- оператор электронно-вычислительных и вычислительных машин, при

наличии среднего общего образования, опыт работы не требуется;

- технический специалист по ИС, при наличии среднего профессионального

образования, опыт работы не требуется;

- кодировщик ИС, при наличии среднего профессионального образования, опыт

работы не требуется;

- техник сервисной службы по ИС, при наличии среднего профессионального

образования, опыт работы не требуется.

Программа профессионального модуля, а также методические материалы,

обеспечивающие ее реализацию, подлежат ежегодному обновлению с учетом запросов

работодателей и особенностей развития региона.

3.1.2 Цели и задачи модуля – требования к результатам освоения модуля

В ходе освоения профессионального модуля обучающийся должен:

в рамках освоения ВД 1. Эксплуатация и модификация информационных

систем

иметь практический опыт:

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

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

восстановлению данных информационной системы;

- сохранения и восстановления базы данных информационной системы;

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

компетенции конкретного пользователя;

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

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

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

информационной системы;

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

системы;

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

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


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

системы;

- участия в оценке качества и экономической эффективности информационной

системы;

- модификации отдельных модулей информационной системы;

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

средств и технологий применения объектов профессиональной деятельности;

уметь:

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

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

- поддерживать документацию в актуальном состоянии;

- принимать решение о расширении функциональности информационной системы,

о прекращении эксплуатации информационной системы или ее реинжиниринге;

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

системы;

- производить документирование на этапе сопровождения;

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

системы;

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

копирования;

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

в рамках своей компетенции;

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

определять ограничения целостности данных;

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

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

определения стратегии развития бизнес-процессов организации;

- строить архитектурную схему организации;

- проводить анализ предметной области;

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

программных средств;

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

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

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

(услуг) и процессов;

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

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

Федерации;

знать:

- основные задачи сопровождения информационной системы;

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


- типы тестирования;

- характеристики и атрибуты качества;

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

- терминологию и методы резервного копирования;

- отказы системы;

- восстановление информации в информационной системе;

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

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

- цели автоматизации организации;

- задачи и функции информационных систем;

- типы организационных структур;

- реинжиниринг бизнес-процессов;

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

особенности и области применения;

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

систем;

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

- основные понятия системного анализа;

- национальную и международную систему стандартизации и сертификации и

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

в рамках освоения ТФ А. Техническая поддержка процессов создания

(модификации) и сопровождения ИС, автоматизирующих задачи организационного

управления и бизнес-процессы

А/04.4. Модульное тестирование ИС (верификация) в соответствии с

трудовым заданием

выполнять трудовые действия:

- проведение тестирования разрабатываемого модуля ИС в соответствии с

трудовым заданием;

- устранение обнаруженных несоответствий;

- фиксирование результатов тестирования в системе учета;

уметь:

- кодировать на языках программирования;

- тестировать результаты собственной работы;

знать:

- языки программирования и работы с базами данных;

- основы современных операционных систем;

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

- устройство и функционирование современных ИС;

- теория баз данных;

- системы хранения и анализа баз данных;

- современные методики тестирования разрабатываемых ИС;

- инструменты и методы модульного тестирования;

- источники информации, необходимой для профессиональной деятельности;

- современный отечественный и зарубежный опыт в профессиональной

деятельности;

- культура речи;

- правила деловой переписки.




- проведение интеграционного тестирования ИС на основе тест-планов в

соответствии с трудовым заданием;

- фиксирование результатов тестирования в системе учета;

уметь:

- тестировать ИС с использованием тест-планов;

- работать с записями по качеству (в том числе с корректирующими действиями,

предупреждающими действиями, запросами на исправление несоответствий);

знать:

- основы управления изменениями;

- архитектура, устройство и функционирование вычислительных систем;

- коммуникационное оборудование;

- сетевые протоколы;






- современные методики тестирования разрабатываемых ИС: основы

интеграционного тестирования;

- современные стандарты информационного взаимодействия систем;

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

технологий организаций;

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

кодов документам и элементам справочников;

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




- основы бухгалтерского учета и отчетности организаций;

- основы налогового законодательства Российской Федерации;



А/06.4. Исправление дефектов и несоответствий в коде ИС и документации к

ИС согласно трудовому заданию.


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

в коде ИС и документации к ИС согласно трудовому заданию;

- установление причин возникновения дефектов и несоответствий;

- устранение дефектов и несоответствий;

уметь:





знать:

- основы управления изменениями;



- основы программирования;

- современные объектно-ориентированные языки программирования;

- современные структурные языки программирования;

- языки современных бизнес-приложений;

- современные методики тестирования разрабатываемых ИС: инструменты и

методы модульного тестирования;




А/07.4. Техническое обеспечение процесса обучения пользователей ИС.


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

- проведение обучения пользователей ИС в рамках рабочего задания;

- фиксирование замечаний и пожеланий пользователей для развития ИС;

уметь:

- устанавливать программное обеспечение;

- проводить презентации;

знать:

- основы системного администрирования;

- возможности ИС;

- технологии межличностной и групповой коммуникации в деловом

взаимодействии, основы конфликтологии;

- технологии подготовки и проведения презентаций;

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

производителем ИС;

- инструменты и методы выявления требований;









А/08.4. Развертывание рабочих мест ИС у заказчика.


- проверка соответствия рабочих мест требованиям ИС к оборудованию и

программному обеспечению;

- инсталляция ИС на рабочих местах заказчика;

- верификация правильности установки ИС на рабочих местах заказчика;

уметь:

- устанавливать программное обеспечение;

знать:


- основы администрирования баз данных;









А/09.4. Установка и настройка системного и прикладного ПО, необходимого

для функционирования ИС в соответствии с трудовым заданием.


- установка операционных систем в соответствии с трудовым заданием;

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


- установка СУБД в соответствии с трудовым заданием;

- настройка СУБД для оптимального функционирования ИС в соответствии с


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


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

ИС, в соответствии с трудовым заданием;

уметь:

- устанавливать операционные системы;

- устанавливать СУБД;

- устанавливать прикладное ПО;

знать:











А/10.4. Настройка оборудования, необходимого для работы ИС в соответствии

с трудовым заданием.


- установка оборудования в соответствии с трудовым заданием;

- настройка оборудования для оптимального функционирования ИС в соответствии

с трудовым заданием;

уметь:

- устанавливать оборудование;

знать:











А/11.4. Интеграция ИС с существующими ИС заказчика в соответствии с



- проектирование интерфейсов обмена данными в соответствии с трудовым

заданием;

- разработка интерфейсов обмена данными в соответствии с трудовым заданием;

- верификация интерфейса обмена данными в соответствии с трудовым заданием;

уметь:

- анализировать входные данные;



знать:

- форматы обмена данными;

- интерфейсы обмена данными;













- современные методики тестирования разрабатываемых ИС: инструменты и

методы модульного тестирования;











- основы налогового законодательства Российской Федерации.




- проведение физического аудита в области качества в соответствии с трудовым

заданием;

- инициирование коррекции (запросов на устранение обнаруженных

несоответствий) по результатам аудитов;

уметь:



знать:

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







А/13.4. Демонстрация заказчику выполнения его требований к ИС в

соответствии с трудовым заданием.


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

выполнения работ, связанных с ИС, с целью проверки соответствия результатов работ

пожеланиям заказчика;

- документальное оформление результатов демонстрации в соответствии с

установленными регламентами;

уметь:


- составлять отчетность;

знать:


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




















А/14.4. Идентификация конфигурации ИС в соответствии с трудовым

заданием.


- определение базовых элементов конфигурации ИС в соответствии с трудовым

заданием;

- присвоение версий базовым элементам конфигурации ИС в соответствии с


уметь:

- использовать систему контроля версий;

знать:

- основы конфигурационного управления;















- ведение истории изменений базовых элементов конфигурации ИС в соответствии

с трудовым заданием;

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

конфигурации в соответствии с трудовым заданием;

уметь:


знать:
















- проведение физического аудита конфигурации ИС в соответствии с трудовым

заданием;

- инициирование коррекции (запросов на устранение обнаруженных

несоответствий) по результатам аудита;

уметь:




знать:













А/17.4. Инженерно-техническая поддержка заключения договоров на

выполняемые работы, связанные с ИС в соответствии с трудовым заданием.


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

работы на основе имеющейся типовой формы в соответствии с трудовым заданием;

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


уметь:


- разрабатывать документацию;

- осуществлять коммуникации;

знать:



- инструменты и методы коммуникаций;

- каналы коммуникаций;

- модели коммуникаций;





























А/18.4. Регистрация запросов заказчика в соответствии с трудовым заданием.


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

заданием;

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

заданием;

уметь:




знать:















А/19.4. Инженерно-техническая поддержка заключения договоров

сопровождения ИС в соответствии с трудовым заданием.


- подготовка технической информации о предмете договора сопровождения ИС на

основе имеющейся типовой формы в соответствии с трудовым заданием;

- согласование договора сопровождения ИС внутри организации в соответствии с


уметь:


- разрабатывать документацию;


знать:


































А/20.4. Закрытие запросов заказчика в соответствии с трудовым заданием.


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

заданием;

- организация выставления счета за выполненные работы в соответствии с


уметь:

- проводить переговоры;

- подготавливать первичные документы;

знать:












- извещение заинтересованных сторон о выполненном задании;

- подготовка и рассылка отчетов о выполнении задания;

- представление результатов выполнения задания заинтересованным сторонам;

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

заинтересованных сторон;

уметь:


- разрабатывать документы;

знать:

- виды отчетности;












3.1.3 Рекомендуемое количество часов на освоение программы

профессионального модуля:

всего – 762 часа, в том числе:

максимальной учебной нагрузки обучающегося – 474 часа, включая:

обязательной аудиторной учебной нагрузки обучающегося – 320 часов;

самостоятельной работы обучающегося – 154 часа;

учебной и производственной практики – 288 часов.

3.2 Результаты освоения профессионального модуля

Результатом освоения программы профессионального модуля является:

- овладение обучающимися видом деятельности ВД 1. Эксплуатация и

модификация информационных систем, в том числе профессиональными (ПК) и

общими (ОК) компетенциями:

Код Наименование результата обученияПК 1.1 Собирать данные для анализа использования и функционирования информационной

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

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

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

ПК 1.4 Участвовать в экспериментальном тестировании информационной системы на этапе опытной эксплуатации, фиксировать выявленные ошибки кодирования в разрабатываемых

модулях информационной системы.ПК 1.5 Разрабатывать фрагменты документации по эксплуатации информационной системы.ПК 1.6 Участвовать в оценке качества и экономической эффективности информационной системы.ПК 1.7 Производить инсталляцию и настройку информационной системы в рамках своей

компетенции, документировать результаты работ.ПК 1.8 Консультировать пользователей информационной системы и разрабатывать фрагменты

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

данных информационной системы, работать с технической документацией.ПК 1.10 Обеспечивать организацию доступа пользователей информационной системы в рамках

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

устойчивый интерес.ОК 2 Организовывать собственную деятельность, выбирать типовые методы и способы

выполнения профессиональных задач, оценивать их эффективность и качество.ОК 3 Принимать решения в стандартных и нестандартных ситуациях и нести за них

ответственность.ОК 4 Осуществлять поиск и использование информации, необходимой для эффективного

выполнения профессиональных задач, профессионального и личностного развития.ОК 5 Использовать информационно-коммуникационные технологии в профессиональной

деятельности.ОК 6 Работать в коллективе и команде, эффективно общаться с коллегами, руководством,

потребителями.ОК 7 Брать на себя ответственность за работу членов команды (подчиненных), результат

выполнения заданий.ОК 8 Самостоятельно определять задачи профессионального и личностного развития, заниматься

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

- освоение трудовых функций

А/04.4. Модульное тестирование ИС (верификация) в соответствии с трудовым

заданием;



А/06.4. Исправление дефектов и несоответствий в коде ИС и документации к ИС

согласно трудовому заданию;

А/07.4. Техническое обеспечение процесса обучения пользователей ИС;

А/08.4. Развертывание рабочих мест ИС у заказчика;

А/09.4. Установка и настройка системного и прикладного ПО, необходимого для

функционирования ИС в соответствии с трудовым заданием;

А/10.4. Настройка оборудования, необходимого для работы ИС в соответствии с


А/11.4. Интеграция ИС с существующими ИС заказчика в соответствии с трудовым

заданием;



А/13.4. Демонстрация заказчику выполнения его требований к ИС в соответствии с


А/14.4. Идентификация конфигурации ИС в соответствии с трудовым заданием;





А/17.4. Инженерно-техническая поддержка заключения договоров на выполняемые

работы, связанные с ИС в соответствии с трудовым заданием;

А/18.4. Регистрация запросов заказчика в соответствии с трудовым заданием;

А/19.4. Инженерно-техническая поддержка заключения договоров сопровождения

ИС в соответствии с трудовым заданием;

А/20.4. Закрытие запросов заказчика в соответствии с трудовым заданием;


3.3 Структура и содержание профессионального модуля

3.3.1 Тематический план профессионального модуляКоды

профессиональных

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

Наименования разделовпрофессионального модуля

Всего часов(макс.

учебная нагрузка и практики)

Объем времени, отведенный на освоение междисциплинарного курса (курсов)

Практика

Обязательная аудиторная учебная нагрузка обучающегося

Самостоятельная работа

обучающегося, часов

Учебная,часов

Производственная,часов(если

предусмотрена рассредоточенная

практика)Всего,часов

в т.ч. лабораторные

работы и практические занятия, часов

в т.ч.курсовая работа

(проект), часов

Всего,часов

в т.ч.курсовая работа

(проект), часов

1 2 3 4 5 6 7 8 9 10ПК 1.6ПК 1.7ПК 1.8ПК 1.9ПК 1.10А/07.4-А/21.4

МДК.01.01Эксплуатация информационной системы.

188 128 30 60

ПК 1.1ПК 1.2ПК 1.3ПК 1.4ПК 1.5А/04.4-А/06.4

МДК.01.02Методы и средства проектирования информационных систем.

286 192 144 94

ПК 1.1-1.10А/04.4-А/21.4

Учебная практика 252 252Производственная практика

36 36

Всего: 762 320 174 154 252 3635

3.2 Содержание обучения по профессиональному модулю (ПМ)Наименование разделов

профессионального модуля (ПМ), междисциплинарных

курсов (МДК) и тем

Содержание учебного материала, лабораторные и практические работы, самостоятельная работа обучающихся, курсовая работа (проект) Объем часов Уровень

освоения

1 2 3 4ПМ.01. Эксплуатация и модификация информационных систем.

474

МДК.01.01. Эксплуатация информационной системы.

188

Раздел 1. Общие положения администрирования ИС.

22

Тема 1.1. Основные понятия администрирования.

Содержание учебного материала 61. Основные понятия администрирования ИС. 1

2-3. Функции администратора ИС. «Золотые правила» администратора. 1Тема 1.2. Составные части ИС. Содержание учебного материала 8

1-2. Аппаратное обеспечение ИС. Кабельное, сетевое оборудование. Развертывание рабочих мест ИС у заказчика. Настройка оборудования, необходимого для работы ИС в соответствии с трудовым заданием.

1

3. Периферийное, дополнительное оборудование. 14. Программное обеспечение ИС. Установка и настройка системного и прикладного ПО,

необходимого для функционирования ИС в соответствии с трудовым заданием. Идентификация конфигурации ИС в соответствии с трудовым заданием. Представление отчетности по статусу конфигурации в соответствии с трудовым заданием. Проведение физических аудитов конфигурации ИС в соответствии с трудовым заданием.

1

Тема 1.3. Администрирование операционной системы.

Содержание учебного материала 81-2. Классификация ОС. Требования к серверной ОС. 13-4. Функции администратора ОС. Службы серверной ОС. 1

Раздел 2. Эксплуатация ИС. 42Тема 2.1. Этапы и виды технологических процессов обработки информации.

Содержание учебного материала 61. Технологический процесс преобразования информации. 1

2-3. Понятие информационной технологии. Информационная технология обработки данных. 1Тема 2.2. Организация операций с данными в ИС.

Содержание учебного материала 121-2. Процессы в ИС, компоненты и структуры. 13-4. Режимы обработки данных. Способы обработки данных. 1

36

5-6. Методы и средства сбора и передачи данных. 1Тема 2.3. Обеспечение достоверности информации в процессе хранения и обработки.

Содержание учебного материала 81-2. Резервное копирование базы данных и последующее восстановление. Резервирование SQL

Server.1

3-4. Планирование и выполнение резервирования. 1Тема 2.4. Экспортирование структур баз данных.

Содержание учебного материала 81-2. Экспорт и импорт данных. Преобразование данных при экспортировании. 13-4. Технологии экспортирования данных. Интеграция ИС с существующими ИС заказчика в

соответствии с трудовым заданием.1

Тема 2.5. Восстановление информации в базах данных.

Содержание учебного материала 81-2. Журнализация и восстановление. 13-4. Восстановление данных и информации. Восстановление резервных копий и полное

восстановление БД.1

Раздел 3. Доступ к базам данных.

32

Тема 3.1. Стандартные системы доступа к базам данных.

Содержание учебного материала 141-2. Технология BDE. 13-4. Механизм ODBC и компоненты доступа к ODBC-источникам. 15-6. Компоненты доступа к различным СУБД: Oracle, InterBase Database, Titan, dBase. 1

7. Универсальный механизм доступа к данным Universal Data Access. 1Тема 3.2. Клиенты удаленного доступа и построение запросов к СУБД.

Содержание учебного материала 121. Классификация приложений для работы с базами данных. 22. Этапы развития серверов баз данных. 2

3-4. Архитектура базы данных. 25-6. Транзакции. Управление запросами. 2

Тема 3.3. Клиентское программное обеспечение.

Содержание учебного материала 61-2. Классификация средств разработки клиентских приложений. 2

3. Интерфейс пользователя. Техническое обеспечение процесса обучения пользователей ИС. 2Раздел 4. Практикум по администрированию баз данных.

32

Тема 4.1. Выполнение операций с базой данных.

Содержание учебного материалаПрактические занятия 4

1. Практическая работа № 1: Требования к современной СУБД. Функции администратора СУБД. СУБД Microsoft Access. Функции администратора СУБД MS Access.

2. Практическая работа № 2: Архивирование, сжатие и восстановление базы данных. Защита информации в БД различными способами.

Тема 4.2. Изучение структуры Содержание учебного материала

37

базы данных. Практические занятия 61. Практическая работа № 3: Сбор сведений об объектах БД. Получение и изучение отчета

Архивариуса. Проведение физических аудитов в области качества в соответствии с трудовым заданием. Демонстрация заказчику выполнения его требований к ИС в соответствии с трудовым заданием.

2. Практическая работа № 4: Изучение таблицы в режиме Конструктора. Просмотр связей между таблицами. Изучение взаимодействия объектов.

3. Практическая работа № 5: Оптимизация базы данных.Тема 4.3. Выполнение операций обмена данными.


1. Практическая работа № 6: Обмен данными между приложениями Access и Word.2. Практическая работа № 7: Обмен данными между приложениями Access и Excel.3. Практическая работа № 8: Обмен данными между БД Access.

Тема 4.4. Сопровождение баз данных.


1. Практическая работа № 9: Создание и подключение справочников.2-3. Практическая работа № 10: Корректировка текущих и создание новых пользовательских

запросов.4-5. Практическая работа № 11: Формирование отчетов.6-7. Практическая работа № 12: Создание пользовательского интерфейса.

Промежуточная аттестация 21. Дифференцированный зачет.

Самостоятельная работа при изучении МДК.01.01Виды овеществленных результатов самостоятельной работы обучающихся:- конспекты лекций;- конспекты глав (параграфов) учебной и специальной литературы по вопросам, составленным преподавателем;- отчеты по практическим работам;- письменные ответы на контрольные вопросы;- выдержки из НД по изученным вопросам (темам).Примерная тематика самостоятельной работы:1. Проработка теоретического материала программы (конспекты лекций).2. «1С: Предприятие» как информационная система (конспект по данным учебной и специальной литературы).3. Оформление практических работ (отчеты).4. Изучение статей периодической печати, интернет-изданий (письменные ответы на контрольные вопросы).5. Самостоятельное изучение темы «Правовое регулирование в области безопасности информации» (выдержки из НД).

60

МДК.01.02. Методы и средства проектирования информационных систем.

286

Раздел 1. Общая Содержание учебного материала 838

характеристика ИС. 1. Состав и структура ИС. Классификация ИС. 22. Архитектуры ИС. 23. Процессы в ИС. Эксплуатация ИС. 24. Показатели эффективности ИС. Безопасность ИС. 2

Практические занятия 161-2. ПР № 1: Работа с иерархическими классификаторами.3-8. ПР № 2: Работа с дескрипторными классификаторами.

Раздел 2. Экспертные системы.

Содержание учебного материала 81. Понятие искусственного интеллекта (ИИ). Информационная технология экспертных систем

(ЭС).2

2. Смысл экспертного анализа. 23. Характеристики ЭС. 24. Функции ЭС. 2

Практические занятия 41-2. ПР № 3: Разработка экспертной системы.

Раздел 3. Жизненный цикл ИС.

Содержание учебного материала 101. Стадии жизненного цикла информационных систем (ЖЦ ИС). 2

2-3. Модели ЖЦ ИС. 24-5. Процессы ЖЦ ИС. 2

Раздел 4. Моделирование ИС. Содержание учебного материала 201. Понятие модели предметной области. 22. Структурный подход к моделированию предметной области, его сущность. 23. Методология функционального моделирования SADT. 24. Диаграммы потоков данных DFD. 25. Диаграмма «сущность-связь». 26. Объектно-ориентированный подход к моделированию предметной области, его сущность. 27. Универсальный язык моделирования UML. 2

8-9. UML-диаграммы. 210. Сравнительный анализ структурного и объектно-ориентированного моделирования. 2

Практические занятия 301-3. ПР № 4: Разработка SADT-диаграммы.4-6. ПР № 5: Разработка DFD-диаграммы.7-9. ПР № 6: Разработка ER-диаграммы.

10-15. ПР № 7: Разработка UML-диаграмм.Раздел 5. Работа с CASE-средствами проектирования.

Практические занятия 941-6. ПР № 8: Разработка и построение диаграммы SADT в среде Visual.

7-12. ПР № 9: Разработка и построение диаграммы DFD в среде Visual.13-18. ПР № 10: Разработка и построение диаграммы ER в среде Visual.

39

19-24. ПР № 11: Разработка и построение диаграммы прецедентов в среде Visual.25-30. ПР № 12: Разработка и построение диаграммы классов в среде Visual.31-36. ПР № 13: Разработка и построение диаграммы последовательностей в среде Visual.37-42. ПР № 14: Разработка и построение диаграммы активностей в среде Visual.43-47. ПР № 15: Оформление альбома диаграмм.Промежуточная аттестация 2

1. Дифференцированный зачет.Самостоятельная работа при изучении МДК.01.02Виды овеществленных результатов самостоятельной работы обучающихся:- конспекты лекций;- конспекты глав (параграфов) учебной и специальной литературы по вопросам, составленным преподавателем;- отчеты по практическим работам;- письменные ответы на контрольные вопросы;- выдержки из НД по изученным вопросам (темам);- проект АСУП.Примерная тематика самостоятельной работы:1. Проработка теоретического материала программы (конспекты лекций).2. «Консультант плюс» как информационная система (конспект по данным литературы).3. Оформление практических работ (отчеты).4. Изучение статей периодической печати, интернет-изданий (письменные ответы на контрольные вопросы).5. Самостоятельное изучение темы «Международная сертификация процесса разработки информационных систем» (выдержки из НД).6. Проект автоматизированной системы управления предприятием (организацией) по выбору обучающегося.

94

Учебная практикаВиды работ:1. Инсталляция, настройка и сопровождение ИС. Выполнение регламентов по техническому сопровождению.2. Выполнение регламентов по обновлению данных ИС.3. Сохранение и восстановление базы данных ИС. Выполнение регламентов по восстановлению данных ИС.4. Организация доступа пользователей к ИС в рамках компетенции конкретного пользователя.5. Обеспечение сбора данных для анализа использования и функционирования ИС и участие в разработке проектной и отчетной документации.6. Участие в экспериментальном тестировании ИС на этапе опытной эксплуатации и нахождение ошибок кодирования в разрабатываемых модулях ИС.7. Участие в оценке качества и экономической эффективности ИС.8. Разработка фрагментов документации по эксплуатации ИС.9. Взаимодействие со специалистами смежного профиля при разработке методов, средств и технологий применения объектов профессиональной деятельности. Определение состава оборудования и программных средств разработки ИС.10. Модификация отдельных модулей ИС. Использование инструментальных средств программирования ИС.11. Инженерно-техническая поддержка заключения договоров на выполняемые работы, связанные с ИС в соответствии с трудовым заданием.

252

40

12. Регистрация запросов заказчика в соответствии с трудовым заданием.13. Инженерно-техническая поддержка заключения договоров сопровождения ИС в соответствии с трудовым заданием.14. Закрытие запросов заказчика в соответствии с трудовым заданием.15. Распространение информации о выполненном задании.Производственная практикаВиды работ:1. Ознакомление с предприятием (организацией): сфера деятельности, структура, функции структурных подразделений, направление информационных потоков.2. Изучение ИС, используемой на предприятии (в организации): предметная область, функциональные возможности, структура базы данных, пользовательский интерфейс.3. Настройка ИС под конкретного пользователя. Экспорт и импорт данных. Выполнение резервного копирования БД.4. Внесение изменений в структуру БД по заданию непосредственного руководителя практики.5. Выполнение тестирования ИС, оформление протокола тестирования.6. Подготовка отчетной документации по результатам выполнения работ.

36

ВСЕГО: 762

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

1 – ознакомительный (узнавание ранее изученных объектов, свойств);

2 – репродуктивный (выполнение деятельности по образцу, инструкции или под руководством);

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

41

3.4 Условия реализации рабочей программы профессионального модуля

3.4.1 Требования к минимальному материально-техническому обеспечению

Реализация рабочей программы модуля требует наличия лаборатории

информационных систем.

Оборудование лаборатории информационных систем:

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

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

доступом к сети Интернет;

- программное обеспечение общего и профессионального назначения;

- наглядные пособия;

- информационно-коммуникативные средства;

- экранно-звуковые пособия;

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

инструкции по их использованию и технике безопасности;

- библиотечный фонд;

- доступ к электронным учебным материалам по МДК, имеющимся в свободном

доступе в Интернете (электронным книгам, практикумам, тестам и др.).

3.4.2 Информационное обеспечение обучения. Перечень рекомендуемых

учебных изданий, дополнительной литературы, Интернет-ресурсов

3.4.2.1 Основные источники:

1. Мезенцев К.Н. Автоматизированные информационные системы. – М.: ОИЦ

«Академия», 2016.

2. Федорова Г.Н. Информационные системы: учебник для студентов учреждений

СПО. – М.: ОИЦ «Академия», 2016.

3. Фуфаев Д.Э., Фуфаева Э.В. Разработка и эксплуатация автоматизированных

информационных систем. – М.: ОИЦ «Академия», 2016.

3.4.2.2 Дополнительные источники:

1. Богатырев В.А. Информационные системы и технологии: теория надежности.

Учебное пособие. – М.: Юрайт, 2017. – 320 с.

2. Волкова В.Н. Теория информационных процессов и систем: учебник и

практикум. – М.: Юрайт, 2017. – 504 с.

42

3. Гагарина Л.Г. Разработка и эксплуатация автоматизированных

информационных систем: учебное пособие. – М.: Форум, Инфра-М, 2015. – 384

с.

4. Игнатьев А.В. Методы и средства проектирования информационных систем и

технологий: учебное пособие. – Волгоград: ВолгГАСУ, 2014. – 57 с.

5. Международный стандарт ISO/IEC 12207 «Жизненный цикл

автоматизированных информационных систем».

6. Шанченко Н.И. Оценка трудоемкости разработки программного продукта:

методические указания. – Ульяновск: УлГТУ, 2015. – 40 с.

3.4.2.3 Интернет-ресурсы:

1. http://www.interface.ru/ - Разработчикам информационных систем.

2. http://citforum.ru/ - Разработчикам информационных систем.

3. http://www.torins.ru/ - Сайт ассоциации разработчиков информационных систем.

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

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

Эксплуатация и модификация информационных систем (далее – модуль) является

предварительное освоение учебных дисциплин: «Элементы математической логики»,

«Устройство и функционирование информационной системы», «Основы проектирования

баз данных».

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

все задания, предусмотренные программой модуля.

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

приступают к учебной практике. Учебная практика проводится на базе образовательной

организации.

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

учебной практики в рамках данного модуля. Производственная практика по модулю

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

специальности 09.02.04 Информационные системы (по отраслям).

По окончании освоения профессионального модуля обучающиеся сдают экзамен

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

вида деятельности ВД 1. Эксплуатация и модификация информационных систем.

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

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

43

уровень профессиональной подготовки (см. п. 4.4), с соблюдением требований охраны

труда, техники безопасности, санитарных и противопожарных норм.

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

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

одним экземпляром по каждому МДК), самостоятельной работы, практики, доступом к

необходимым базам данных и библиотечным фондам, к сети Интернет. Задания на

практических занятиях выполняются с использованием персональных компьютеров. При

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

местом в компьютерном классе.

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

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

учреждениях).

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

государственной итоговой аттестации.

3.4.4 Кадровое обеспечение образовательного процесса

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

имеющими высшее образование, соответствующее профилю модуля ПМ.01.

Эксплуатация и модификация информационных систем и специальности 09.02.04

Информационные системы (по отраслям). Опыт деятельности в организациях

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

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

не реже 1 раза в 3 года.

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

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

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

эффективную самостоятельную работу обучающихся в рамках модуля и управляют ею.

3.5 Контроль и оценка результатов освоения профессионального модуля

(вида профессиональной деятельности)

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

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

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

44

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

учебного года.

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

контроль. По окончании изучения каждого МДК обучающиеся сдают

дифференцированный зачет. По окончании изучения всех МДК обучающиеся приступают

к учебной практике.

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

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

практике, предоставленного обучающимся руководителю практики. Освоение учебной

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

В ходе производственной практики проводится текущий контроль. Аттестация по

итогам производственной практики проводится на основании характеристики с места

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

руководителю практики от образовательной организации.

По окончании освоения профессионального модуля обучающиеся сдают экзамен

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

вида деятельности ВД 1. Эксплуатация и модификация информационных систем.

Для осуществления текущего и промежуточного контроля освоения

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

оценить уровень освоения компетенций.

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

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

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

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

45

Раздел (тема)междисциплинарн

ого курса

Результаты(освоенные профессиональные

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

контроля и оценки


ПК 1.6. Участвовать в оценке качества и экономической эффективности информационной системы.

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

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

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

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

46

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


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

Демонстрация навыков:- инсталляции, настройки и сопровождения одной из информационных систем;- проверка соответствия рабочих мест требованиям ИС к оборудованию и программному обеспечению;- инсталляция ИС на рабочих местах заказчика;- верификация правильности установки ИС на рабочих местах заказчика;- установка операционных систем в соответствии с трудовым заданием;- настройка операционных системы для оптимального функционирования ИС в соответствии с трудовым заданием;- установка СУБД в соответствии с трудовым заданием;- настройка СУБД для оптимального функционирования ИС в соответствии с трудовым заданием;- установка прикладного ПО, необходимого для функционирования ИС в соответствии с трудовым заданием;- настройка прикладного ПО, необходимого для оптимального функционирования ИС, в соответствии с трудовым заданием;- установка оборудования в соответствии с трудовым заданием;- настройка оборудования для оптимального функционирования ИС в соответствии с трудовым заданием;- проектирование интерфейсов обмена данными в соответствии с


47

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

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

Демонстрация знаний:- форматы обмена данными;- интерфейсы обмена данными;- архитектура, устройство и функционирование вычислительных систем;

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

48

- основы системного администрирования;- основы администрирования баз данных;- коммуникационное оборудование;- сетевые протоколы;- основы современных операционных систем;- основы современных систем управления базами данных;- основы конфигурационного управления;- устройство и функционирование современных ИС;- источники информации, необходимой для профессиональной деятельности;- современный отечественный и зарубежный опыт в профессиональной деятельности;- теория баз данных;- системы хранения и анализа баз данных;- основы программирования;- современные объектно-ориентированные языки программирования;- современные структурные языки программирования;- языки современных бизнес-приложений;- современные методики тестирования разрабатываемых ИС: инструменты и методы модульного тестирования;- современные стандарты информационного взаимодействия систем;- программные средства и платформы инфраструктуры информационных технологий организаций;- системы классификации и кодирования информации, в том числе присвоение кодов документам и элементам справочников;- отраслевая нормативная техническая документация;- основы бухгалтерского учета и отчетности организаций;- основы налогового законодательства Российской Федерации.- культура речи;- правила деловой переписки.

- защиты практических работ;- самостоятельной работы обучающихся.


ПК 1.8. Консультировать пользователей информационной системы и разрабатывать фрагменты методики обучения пользователей информационной системы.

Демонстрация навыков:- разработки фрагментов документации по эксплуатации информационной системы;- осуществление технической подготовки мест обучения пользователей ИС;- проведение обучения пользователей ИС в рамках рабочего задания;


49

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



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

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


50

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


Демонстрация знаний: Оценка результатов:

51

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

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

52

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


ПК 1.10. Обеспечивать организацию доступа пользователей информационной системы в рамках своей компетенции.

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


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


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



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

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


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


Демонстрация знаний:- основные задачи сопровождения информационной системы.


53


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

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


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


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



ПК 1.3. Производить модификацию отдельных модулей информационной системы в соответствии с рабочим заданием, документировать

Демонстрация навыков:- модификации отдельных модулей информационной системы.


54

произведенные изменения. Демонстрация умений:- поддерживать документацию в актуальном состоянии;- производить документирование на этапе сопровождения.


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



ПК 1.4. Участвовать в экспериментальном тестировании информационной системы на этапе опытной эксплуатации, фиксировать выявленные ошибки кодирования в разрабатываемых модулях информационной системы.

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


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


Демонстрация знаний:- типы тестирования.



ПК 1.5. Разрабатывать фрагменты документации по эксплуатации информационной системы.

Демонстрация навыков:- разработки фрагментов документации по эксплуатации информационной системы.


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

55

- применять основные правила и документы системы сертификации Российской Федерации.

Раздел (тема)междисциплина

рного курса

Результаты(освоенные общие компетенции) Основные показатели оценки результата Формы и методы

контроля и оценки

МДК.03.01Информационные технологии.

МДК.03.02Пакеты

прикладных программ.

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

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

ОК 2. Организовывать собственную деятельность, выбирать типовые методы решения профессиональных задач, оценивать их эффективность и качество.

Обоснование выбора и применение типовых методов решения профессиональных задач в области эксплуатации и модификации информационных систем.Демонстрация эффективности и качества выполнения профессиональных задач.

ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.

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

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

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

ОК 5. Использовать информационно-коммуникационные технологии в профессиональной деятельности.

Демонстрация навыков:- проведения расчетов и проектирования с помощью персонального компьютера;- использования информационно-коммуникативных средств при решении профессиональных задач.

ОК 6. Работать в коллективе и команде, эффективно общаться с коллегами, руководством, потребителями.

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

ОК 7. Брать на себя ответственность за работу членов команды (подчиненных), результат выполнения заданий.

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

ОК 8. Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.

Планирование обучающимся повышения своего личностного и профессионального уровня.

ОК 9. Ориентироваться в условиях частой смены технологий в Проявление интереса к инновациям в области эксплуатации и 56

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

57

Оценка индивидуальных образовательных достижений по результатам текущего и

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

(таблица).

Процент результативности

(правильных ответов)

Качественная оценка индивидуальных образовательных

достижений

балл (отметка) вербальный аналог

90 ÷ 100 5 Отлично

75 ÷ 89 4 Хорошо

60 ÷ 74 3 Удовлетворительно

менее 60 2 Неудовлетворительно

На этапе промежуточной аттестации по медиане качественных оценок

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

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

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

58

4. КУРС ЛЕКЦИЙ ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ

4.1 Структура курса лекций

№ и тема лекции Объем часов

Раздел 1. Общая характеристика ИС.1. Состав и структура ИС. Классификация ИС. 22. Архитектуры ИС. 23. Процессы в ИС. Эксплуатация ИС. 24. Показатели эффективности ИС. Безопасность ИС. 2

Раздел 2. Экспертные системы.5. Понятие искусственного интеллекта (ИИ). Информационная технология экспертных систем (ЭС).

2

6. Смысл экспертного анализа. 27. Характеристики ЭС. 28. Функции ЭС. 2

Раздел 3. Жизненный цикл ИС.9. Стадии жизненного цикла информационных систем (ЖЦ ИС). 210. Модели ЖЦ ИС. 411. Процессы ЖЦ ИС. 4

Раздел 4. Моделирование ИС.12. Понятие модели предметной области. 213. Структурный подход к моделированию предметной области, его сущность. 214. Методология функционального моделирования SADT. 215. Диаграммы потоков данных DFD. 216. Диаграмма «сущность-связь». 217. Объектно-ориентированный подход к моделированию предметной области, его сущность.

2

18. Универсальный язык моделирования UML. 219. UML-диаграммы. 420. Сравнительный анализ структурного и объектно-ориентированного моделирования.

2

ВСЕГО: 46

59

4.2 Лекционные материалы

Раздел 1. Общая характеристика ИС.

Лекция 1. Состав и структура ИС. Классификация ИС.

1.1 Основные понятия информационных систем.

В общем смысле под системой понимают совокупность объектов, компонентов или

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

образования, пищеварительная система, солнечная система и т.п.). Определяющей

предпосылкой выделения некоторой совокупности как системы является возникновение у

нее новых свойств, которых не имеют составляющие ее элементы. Системы значительно

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

общей моделью системы считают так называемый «черный ящик». В этом случае система

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

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

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

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

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

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

воздействий.

Графическое изображение данной модели приведено на рис. 1.1.

Рисунок 1.1 – Модель информационной системы в виде «черного ящика»

Добавление к понятию «система» слова «информационная» отражает цель ее

создания и функционирования. Назначение информационной системы — своевременное

60

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

Информационные системы обеспечивают сбор, хранение, обработку, поиск, выдачу

информации в задачах из любой области. Они помогают анализировать информацию,

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

Информация — это сведения об объектах, явлениях, процессах, событиях

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

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

своевременной, непротиворечивой, адекватной.

Разные авторы придают различные оттенки определению информационной

системы, расширяя или сужая его смысл. В настоящее время информационные системы

часто связывают с понятием автоматизации и называют автоматизированными

информационными системами. Автоматизацией является процесс внедрения

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

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

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

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

технике.

Необходимо понимать разницу между понятиями «информационная технология» и

«информационная система».

Информационная технология — это приемы, способы и методы применения

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

использования данных. Информационная технология является более емким понятием, чем

информационная система. Информационная технология может существовать вне

информационной системы, тогда как информационная система невозможна без

применения конкретной информационной технологии.

К информационным системам относятся:

— информационно-справочные и информационно-поисковые системы;

— системы, обеспечивающие автоматизацию документооборота и учета (в том

числе бухгалтерского);

— информационные системы управления;

— интеллектуальные (экспертные) системы;

— системы автоматизации научных исследований;

— системы автоматизированного проектирования;

— геоинформационные системы и др.

61

Процессы, обеспечивающие работу информационной системы любого назначения,

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

— ввод информации (сбор информации о состоянии внешней среды и объекта

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

нужном формате);

— база данных (хранилище данных);

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

вывод информации для представления потребителям или передачи в другую систему);

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

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

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

Любая система состоит из подсистем, подсистема любой системы может быть сама

рассмотрена как система. Границы рассматриваемой системы определяются доступными

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

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

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

Структура информационной системы должна быть такой, чтобы взаимодействие

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

— каждая подсистема должна инкапсулировать свое содержимое (скрывать его от

других подсистем);

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

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

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

их в систему более высокого уровня.

Система называется большой, если ее исследование или моделирование затруднено

из-за большой размерности, т. е. множество состояний системы имеет большую

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

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

возможно, разбиением задачи на рад задач меньшей размерности.

62

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

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

параметров или для принятия решений.

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

системного анализа. Системный анализ — это методология решения проблем, основанная

на структуризации систем (социальных, экономических, технических и т.д.). Другими

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

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

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

конкретной проблемы.

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

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

Задача декомпозиции означает представление системы в виде набора подсистем,

состоящих из более мелких элементов.

Задача анализа состоит в нахождении различного рода свойств системы или

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

информации, задающего поведение системы.

Задача синтеза системы противоположна задаче анализа. Необходимо по

описанию закона преобразования информации построить систему, фактически

выполняющую это преобразование по определенному алгоритму.

1.2 История развития ИС.

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

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

Библиотеки, архивы, адресные бюро, телефонные справочники, словари — все это

информационные системы. Однако именно компьютеризация придала информационным

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

расширила сферу их применения. ИС представляют собой системы, основанные на

постоянно развивающихся концепциях использования информации.

Первые автоматизированные информационные системы появились в 50-х годах

прошлого столетия. В эти послевоенные годы сложилась ситуация, когда меры по

созданию новых организационных структур или совершенствованию экономических

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

управлении экономикой и соответствующим ростом потерь.

Принципиальное решение стало возможным только за счет кардинального роста

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

63

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

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

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

бухгалтерских счетных машинах. Это привело к некоторому уменьшению затрат и

сокращению времени на подготовку бумажных документов. В то время был

распространен термин — «электронная обработка данных» (ЭОД).

В 1960-е годы средства вычислительной техники получают дальнейшее развитие:

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

программирования.

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

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

документации. Изменяется отношение к информационным системам. Информацию,

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

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

менеджеров, принимающих решения.

В 1970-е годы развиваются технология баз данных и средства для интерактивной

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

появления систем поддержки принятия решений (СППР). В отличие от систем

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

формам отчетности, СППР предоставляют ее по мере необходимости.

В 1970— 1980-х гг. в офисах начали применять разнообразные компьютерные и

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

информационных систем. ИС начинают широко использоваться в качестве средства

управленческого контроля, поддерживающего и ускоряющего процесс принятия решений.

1980-е годы характеризуются еще и тем, что информационные технологии начали

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

информационные системы являются стратегическим оружием. Информационные системы

этого периода, предоставляя вовремя нужную информацию, помогают организации

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

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

выпуск продукции по низкой цене и многое другое.

Развитие информационных систем управления в России и на Западе проходило

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

социалистическая система жестко регламентировала и распределяла человеческие,

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

64

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

финансовые и материальные потоки.

Совершенно иная картина была присуща капиталистическому обществу. В

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

ресурсами всегда была первоочередной.

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

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

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

предприятий.

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

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

планирования. Так, наиболее востребованные на рынке продукты компании «1C»

появлялись на свет в следующей последовательности: «Бухгалтерия», «Зарплата и

Кадры», «Торговля и Склад», «Предприятие». Аналогичные этапы развития прошли и

программные продукты других отечественных фирм: «БЭСТ», «Парус», «Галактика».

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

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

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

различных программно-аппаратных платформах. До сих пор на многих предприятиях,

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

большое разнообразие программно-аппаратных средств. В результате «лоскутной»

автоматизации подразделения фирмы работают автономно и иногда даже менее

эффективно, чем вообще без автоматизации.

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

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

средств. Это нашло отражение в названиях информационных систем: IC (Inventory Control

– управление запасами), MRP (Material Requirements Planning — планирование

потребности в материалах), MRP II (Manufacturing Resource Planning — планирование

производственных ресурсов), ERP (Enterprise Resource Planning — планирование ресурсов

корпорации).

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

достаточного внимания модулю бухгалтерского учета. Однако задачи учета тесно

увязывались с управленческими задачами.

Сегодня в нашей стране деловая среда стремительно меняется: расширяются

внешние и внутренние связи компаний, увеличивается скорость бизнес-процессов.

65

Требования к информационным технологиям повышаются, что способствует быстрому

развитию систем управления. В итоге информационные системы становятся одним из

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

требующие новых подходов к автоматизации.

1.3 Функциональная часть ИС.

Структура любой информационной системы может быть представлена

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

задач предметной области.

Набор подсистем зависит от специфики предметной области и цели, для которой

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

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

качества в той или иной форме. При разбиении (декомпозиции) общей цели системы на

подцели получаем декомпозицию системы на функциональные подсистемы. Вообще

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

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

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

направленности, уровней управленческой деятельности и т.д.

Для автоматизированных систем научных исследований (АСНИ), например, в

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

проведения экспериментов; обработки результатов экспериментов и др.

Для автоматизированных обучающих систем (АОС) — это подсистемы:

— проведения учебных занятий;

— тестирования учащихся;

— регистрации и обработки результатов обучения и т.д.

Для систем автоматизированного проектирования (САПР) это могут быть

подсистемы:

— функционально-логического и конструкторского проектирования;

— подсистема параметрической оптимизации;

— подсистема конструкторско-технологической документации и т.д.

Для информационной системы управления предприятием (ИСУ) к таким

функциональным подсистемам можно отнести подсистемы:

— технико-экономического планирования;

— технической подготовки производства;

— сбыта и реализации продукции;

— оперативного управления производством;

66

— материально-технического снабжения;

— бухгалтерского учета;

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

— управления кадрами;

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

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

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

Решение каждой такой задачи базируется на некотором математическом

обеспечении, отображающем ее экономико-математическую или информационную

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

результат решения, представленный в определенной форме.

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

устанавливают с учетом достижения стоящей перед экономическим объектом цели

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

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

наличие объекта управления, наличие конкретного набора функций и соответствующих

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

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

ограниченные стандартные рамки.

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

структуры данных и алгоритмов обработки.

Для снижения затрат на проектирование, внедрение и сопровождение

информационных систем, а следовательно, и для повышения их эффективности

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

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

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

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

сокращению сроков проектирования систем. Например, типовая конфигурация системы

«1C:Бухгалтерия» применяется на сотнях тысяч отечественных предприятий и не требует

дополнительных доработок.

1.4 Обеспечивающая часть.

Обеспечивающая часть ИС — это совокупность средств, с использованием

которых решаются задачи функциональных подсистем.

К компонентам обеспечивающей части информационных систем относятся:

— техническое обеспечение;

67

— математическое обеспечение;

— программное обеспечение;

— информационное обеспечение;

— организационное обеспечение;

— правовое обеспечение.

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

качестве отдельных компонентов также:

— эргономическое обеспечение;

— технологическое обеспечение;

— лингвистическое обеспечение;

— кадровое обеспечение и др.

Рассмотрим кратко основное содержание компонентов обеспечивающей части.

Техническое обеспечение. Техническое обеспечение представляет собой комплекс

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

тиражирования информации.

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

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

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

др.

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

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

документация и обслуживающий их персонал. Документацией оформляются

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

технологический процесс обработки данных, технологическое оснащение. Документацию

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

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

техническому обеспечению;

— специализированную, содержащую комплекс методик по всем этапам

разработки технического обеспечения;

— нормативно-справочную, используемую при выполнении расчетов по

техническому обеспечению.

Математическое обеспечение. Математическое обеспечение — это совокупность

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

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

Математическое обеспечение включает в себя средства моделирования процессов

68

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

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

многокритериальной оптимизации, математического программирования, математической

статистики, теории массового обслуживания и т.п.). Техническая документация по этому

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

экономико-математические методы и модели решения задач. Персонал составляют

специалисты в области организации управления объектом, постановщики

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

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

Программное обеспечение. Программное обеспечение — это совокупность

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

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

программного обеспечения представлена на рисунке 1.3.

Рисунок 1.3 – Классификация программного обеспечения

Системное программное обеспечение — это совокупность программ и

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

устройств.

Назначение системного программного обеспечения:

— создание операционной среды функционирования других программ;

— обеспечение надежной и эффективной работы самого компьютера и

вычислительной сети;

— проведение диагностики и профилактики аппаратуры компьютера и

вычислительных сетей;

— выполнение вспомогательных технологических процессов (копирование,

архивация, восстановление файлов программ и баз данных и т.п.).

Базовое программное обеспечение — это минимальный набор программных

средств, обеспечивающих работу компьютера (операционные системы).

69

Сервисное программное обеспечение — это программы и программные комплексы,

которые расширяют возможности базового программного обеспечения и организуют

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

архиваторы и т.п.).

Прикладное программное обеспечение служит программным инструментарием

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

программного обеспечения.

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

информации различных предметных областей. Таким образом, прикладное программное

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

определенного класса предметной области. Данный класс программных средств наиболее

представителен, что обусловлено прежде всего широким применением средств

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

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

Инструментарий разработки программного обеспечения — это программные

продукты поддержки технологии программирования.

Инструментарий включает в себя специализированное программное обеспечение,

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

данного класса поддерживает все технологические этапы процесса проектирования,

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

данного программного обеспечения являются системные и прикладные программисты.

В состав программного обеспечения помимо общесистемных и специальных

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

программного обеспечения.

Информационное обеспечение. Информационное обеспечение — это

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

стандартизирующие процессы ее хранения и обработки. Информационное обеспечение

образует информационную базу системы. Оно включает в себя специально

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

элементов информации, унифицированные системы документации, массивы информации

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

надежность хранения, своевременность и качество технологии обработки информации.

Для создания информационного обеспечения необходимо ясно понимать цели,

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

возникновения и до ее использования на различных уровнях управления. Движение

70

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

информационных потоков.

Информационное обеспечение должно быть достаточным для поддержания всех

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

информационного обеспечения взаимодействующих подсистем (данные одной

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

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

выходной информации, способы обновления данных в информационных массивах,

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

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

этом внемашинная часть также может быть представлена на машинных носителях.

К внемашинной части относят системы классификации и кодирования

информации, нормативно-справочную информацию, методические инструктивные

материалы, унифицированные системы документации (типовые формы, документы,

проекты, решения).

К внемашинной части можно отнести ту информацию, которую используют вне


К машинной части относят ту информацию, которая используется только внутри

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

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

результирующей информации и др.

Организационное обеспечение. Организационное обеспечение — это

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

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

информационной системы. Организационное обеспечение реализуется в различных

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

эксплуатации ИС. Это различного рода документы (приказы, положения, инструкции,

штатные расписания, квалификационные требования и др.), определяющие положение

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

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


Организационное обеспечение реализует следующие функции:

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

использоваться ИС, и выявление задач, подлежащих автоматизации;

71

— подготовку технического задания на проектирование ИС и технико-

экономическое обоснование ее эффективности;

— разработку управленческих решений, направленных на повышение

эффективности системы управления.

Организационное обеспечение создается по результатам предпроектного

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

проектирования ИС, утвержденный и положенный в основу эксплуатации


Правовое обеспечение. Правовое обеспечение представляет собой совокупность

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

эксплуатации ИС.

Главная цель правового обеспечения — укрепление законности. В состав

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

власти, приказы, инструкции и другие нормативные документы. В правовом обеспечении

можно выделить:

— общую часть, регулирующую функционирование любой информационной

системы;

— локальную часть, регулирующую функционирование конкретной


На этапе разработки информационных систем правовое обеспечение включает

нормативные акты, связанные с договорными отношениями разработчика и заказчика, с

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

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

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

включает:

— определение статуса ИС;

— правовое положение в организации;

— права, обязанности и ответственность персонала;

— порядок создания и использования информации в ИС;

— процедуры регистрации, сбора, хранения, передачи и обработки информации;

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

телекоммуникационной техники и других технических средств;

— создание и использование математического и программного обеспечения.

Часть правового обеспечения — защита информационных систем. Она

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

72

обеспечению, документации, защита их от преднамеренного разрушения и хищения, а

также исключение несанкционированного копирования (тиражирования) программного

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

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

Патентная защита устанавливает приоритет в разработке и использовании нового

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

оригинальность.

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

допущенных к эксплуатации, а также определяет меру их ответственности за разглашение

секретов.

Лицензионное соглашение распространяется на все аспекты правовой охраны

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

секреты. Наиболее часто используются лицензионные соглашения (лицензия) на передачу

авторских прав.

Лицензия — договор на передачу одним лицом другому лицу права на

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

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

область распространения программного обеспечения или базы данных. Лицензиат

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

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

Существует несколько типов лицензий на программное обеспечение.

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

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

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

применения или предоставления другим лицам.

Простая лицензия — лицензиар предоставляет лицензиату использовать

программное или информационное обеспечение, оставляя за собой право применять их и

предоставлять на аналогичных условиях неограниченному числу лиц (лицензиат может

лишь продавать копии приобретенного программного или информационного

обеспечения).

Этикеточная лицензия — лицензия на одну копию программного или

информационного обеспечения. Данный тип применяется в розничной продаже.

Лингвистическое обеспечение. Лингвистическое обеспечение представляет собой

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

разработки системы и облегчения общения человека с ЭВМ. В его состав входят:

73

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

базы (документов, показателей, реквизитов и т.п.);

— языки управления и манипулирования данными информационной базы;

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

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

— диалоговые языки специального назначения;

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

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

Эргономическое обеспечение. Эргономическое обеспечение — это совокупность

методов и средств, создающих благоприятные условия для быстрого освоения АИС,

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

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

на разных этапах разработки и функционирования ИС, предназначено для создания

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

при использовании ИС. В состав эргономического обеспечения информационных систем

входят:

— комплекс документации, содержащей эргономические требования к рабочим

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

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

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

— комплекс методов учебно-методической документации и технических средств,

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

персонала, а также формированию системы отбора и подготовки персонала;

— комплекс методов, обеспечивающих высокую эффективность деятельности

персонала.

Обеспечивающие подсистемы ИС в отличие от функциональных подсистем, как

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

объектов.

1.5 Классификация информационных систем.

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

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

всех сферах деятельности.

Разнообразие задач, решаемых с помощью ИС, привело к появлению множества

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

правилами обработки информации.

74

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

признаков.

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

автоматические и автоматизированные.

Рунные системы характеризуются отсутствием современных технических средств

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

В автоматических системах все операции по переработке информации

выполняются без участия человека.

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

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

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

соответствует современному представлению понятия «информационная система».

По типу используемых данных информационные системы можно

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

Фактографические системы предназначены для хранения и обработки

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

— поиск, фильтрацию, сортировку, агрегирование и т.д.

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

состоящих из рефератов, текстов, описаний и пр.

Поиск по неструктурированным данным осуществляется с использованием

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

обработка данных в таких системах практически не производится.

При создании или при классификации информационных систем неизбежно

возникают проблемы, связанные с формальным (математическим и алгоритмическим)

описанием решаемых ими задач. От степени формализации во многом зависят

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

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

Чем точнее математическое описание задачи, тем выше возможности компьютерной

обработки данных и тем меньше степень участия человека в процессе ее решения. Это и

определяет степень автоматизации задачи.

Различают три типа задач, для которых создаются информационные системы:

структурированные (формализованные), неструктурированные (неформализованные) и

частично структурированные.

Структурированная (формализованная) задача — задача, где известны все ее

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

75

содержание в форме математической модели, имеющей точный алгоритм решения.

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

характер. Целью использования информационной системы для решения

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

человека к нулю.

Например, задача расчета заработной платы — структурированная задача, где

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

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

большого числа сотрудников.

Неструктурированная (неформализованная) задача — задача, в которой

невозможно выделить элементы и установить между ними связи. Решение

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

разработки алгоритма связано с большими трудностями. Решение в таких случаях

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

источников.

Заметим, что в практике работы любой организации существует сравнительно

немного полностью структурированных или совершенно неструктурированных задач. О

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

ними. Такие задачи называются частично структурированными.

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

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

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

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

1. Создающие управленческие отчеты и ориентированные главным образом на

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

содержащиеся в этих отчетах, управляющий принимает решение. Информационные

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

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

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

отчеты в различных разрезах за произвольные промежутки времени и т.п.

2. Разрабатывающие возможные альтернативы решения. Принятие решения при

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

могут быть модельными или экспертными.

76

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

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

выработку и оценку альтернатив решения.

Пользователь может получить недостающую ему для принятия решения

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

Основные функции модельной информационной системы:

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

решение основных задач моделирования типа «как сделать, чтобы?» и «что будет, если?»;

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

— оперативная подготовка и корректировка входных параметров и ограничений

модели;

— возможность графического отображения динамики модели;

— возможность объяснения пользователю необходимых шагов формирования и

работы модели.

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

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

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

уровнях.

На первом уровне экспертная поддержка исходит из концепции «типовых

управленческих решений», в соответствии с которой часто возникающие в процессе

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

управленческих решений, т.е. к некоторому типовому набору альтернатив. Для

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

хранения и анализа типовых альтернатив.

Если возникшая проблемная ситуация не ассоциируется с имеющимися классами

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

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

информационном фонде данных и правил преобразования.

Существует классификация информационных систем по характеру обработки

данных (рисунок 1.4).

77

Рисунок 1.4 – Классификация информационных систем по характеру обработки данных

Информационно-поисковые системы производят ввод, систематизацию,

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

данных. Пользователь обращается к системе с информационным запросом — текстом,

отражающим информационную потребность (например, список книг определенного

автора). Поиск информации ведется в поисковом массиве, который формируется (и по

мере необходимости обновляется) администраторами системы или пользователем.

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

естественном (или близком к нему) языке, а затем подвергаются индексированию, т. е.

переводу на формальный информационно-поисковый язык. Информационно-поисковыми

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

билетов, бронирования мест в гостиницах и пр.

Информационно-решающие системы кроме вышеперечисленных операций

осуществляют операции переработки информации по определенному алгоритму. Они

подразделяются на управляющие и советующие.

В управляющих системах результирующая информация непосредственно

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

задачи расчетного характера и обработка больших объемов данных. Например,

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

бухгалтерского учета и т.п.

Советующие системы вырабатывают информацию, которая принимается

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

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

обработки не данных, а знаний. К советующим системам относят экспертные системы.

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

систем по сфере применения. На самом деле области применения информационных

78

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

самыми различными способами. Мы рассмотрим наиболее распространенную

классификацию.

Информационные системы организационного управления предназначены для

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

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

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

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

элементов системы. Информационная система является частью организации (фирмы,

предприятия), а один из ключевых элементов организации — ее структура. Координация

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

разного уровня.

Рисунок 1.5 – Классификация информационных систем по сфере применения

Под управлением предприятием (фирмой, компанией и т.п.) понимают обеспечение

поставленной цели при условии реализации следующих функций: организационной,

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

1. Организационная функция заключается в разработке организационной

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

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

компетенции, прав, обязанностей и т.п. Чаще всего это излагается в положении по отделу,

лаборатории или должностных инструкциях.

2. Планирование (плановая функция) состоит в разработке и реализации планов по

выполнению поставленных задач. Например, бизнес-план для всей фирмы, план

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

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

3. Учетная функция заключается в разработке или использовании уже готовых

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

79

общем случае учет можно определить как получение, регистрацию, накопление,

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

4. Анализ (аналитическая функция) связывается с изучением итогов выполнения

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

тенденций развития и т.д. Выполняется анализ разными специалистами в зависимости от

сложности и уровня анализируемого объекта или процесса.

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

специалисты, а на уровне цеха, отдела — менеджер этого уровня (начальник или его

заместитель) совместно со специалистом-экономистом.

5. Контрольная функция чаще всего осуществляется менеджером: контроль за

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

финансовых средств и т.п.

6. Стимулирование (мотивационная функция) предполагает разработку и

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

— финансовые стимулы (зарплата, премия, акции, повышение в должности и т.п.);

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

почета и т.п.).

Информационные системы управления технологическими процессами служат

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

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

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

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

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

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

числовым программным управлением (ЧПУ), гибкие производственные линии,

автоматизированные линии, промышленные роботы, роботизированные технологические

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

автоматизированной линии начинают с анализа информации о продукции.

Технологический процесс разрабатывают поэтапно. Необходимым элементом перехода от

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

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

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

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

внешними и смежными производственными подразделениями. Такого рода системы

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

80

управления. Подсистемы обработки и обслуживания формируются на основе

технологического оборудования. Подсистема контроля и управления состоит из

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

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

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

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

Системы автоматизированного проектирования (САПР — Computing Aided

Design, CAD) предназначены для автоматизации функций инженеров-проектировщиков,

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

планов, схем, моделирования объектов. Различают САПР конструктора и САПР

технолога. Основные функции систем автоматизированного проектирования —

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

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

сокращение сроков проектирования, повышение качества разработки проектов. Развитие

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

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

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

и оптимизации. Системы автоматизированного проектирования дают возможность на

основе новейших достижений фундаментальных наук отрабатывать и совершенствовать

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

проектирования сложных систем и объектов. К этому же классу систем можно отнести

автоматизированные системы поддержки производства (Computing Aided Manufacturing,

САМ), автоматизированные системы инженерного проектирования (Computing Aided En-

gineering, CAE).

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

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

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

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

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

направлений деятельности.

Лекция 2. Архитектуры ИС.

81

Современные информационные системы характеризуются огромными объемами

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

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

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

Традиционные архитектурные решения информационных систем основаны на

использовании выделенных файл-серверов или серверов баз данных (БД). Существуют

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

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

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

«хранилища данных» (DataWarehouse) — интегрированной информационной среды,

включающей разнородные информационные ресурсы.

И наконец, для построения глобальных распределенных информационных

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

компонентов на основе объектно-ориентированного подхода.

Архитектура файл-сервер.

В архитектуре файл-сервер базы данных хранятся на сервере, клиент обращается к

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

ресурсами находится на компьютере клиента.

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

Сама база данных хранится на сетевом файл-сервере в единственном экземпляре. Для

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

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

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

решаются разработчиками приложений баз данных (каждый раз при обращении к данным

проверяется их доступность).

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

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

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

относится всего к одной записи, обновляются все записи базы данных. Если записей в

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

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

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

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

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

82

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

сервере через низкоскоростные каналы связи.

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

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

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

СУБД. Такие системы, как правило, не отвечают требованиям обеспечения целостности

данных, в частности, они не поддерживают обработки транзакций (завершенных операций

с документами).

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

возлагается на клиентские приложения, что приводит к их усложнению. Если они

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

отразиться на всех пользователях.

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

одним пользователем, не видны другим пользователям. Пока один пользователь

редактирует какую-либо запись, она заблокирована для других клиентов. Возникает

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

записей.

И еще один недостаток — управление базой данных осуществляется с разных

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

соблюдения конфиденциальности, что также усложняет поддержку целостности базы

данных.

Тем не менее файл-серверная архитектура привлекает своей простотой и

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

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

качестве информационных систем в масштабах предприятия.

Архитектура клиент-сервер.

Архитектура клиент-сервер предназначена для разрешения проблем файл-

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

где они будут функционировать наиболее эффективно. Особенностью архитектуры

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

на языке структурированных запросов (Structured Query Language, SQL) и выполняющих

поиск, сортировку и агрегирование информации. Отличительная черта серверов баз

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

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

вызову или по событиям в программе. Объектами разработки в таких приложениях,

83

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

и связанный с ней набор SQL-операторов для типовых запросов к базе данных.

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

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

выполняется специальным компьютером — сервером. Клиент дает задание серверу

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

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

своей работы. Подобная организация работы повышает эффективность выполнения

приложений за счет использования мощности сервера, разгружает сеть, обеспечивает

хороший контроль целостности данных.

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

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

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

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

ускорения работы клиентских приложений с удаленной БД вся логика принятия решений

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

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

параметры и способные выполнять запросы к БД, условные ветвления и циклическую

обработку. Хранимые процедуры пишутся на специальном алгоритмическом языке. В них

программируются часто повторяемые последовательности запросов к БД. Текст процедур

хранится на сервере в откомпилированном виде. Преимущества в использовании

хранимых процедур очевидны:

— отпадает необходимость синтаксической проверки каждого запроса и его

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

— отпадает необходимость реализации в клиентской программе запросов,

определенных в теле хранимых процедур;

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

SQL-запроса по сети передается относительно короткое обращение к хранимой

процедуре.

Хранимые процедуры улучшают целостность приложений и БД, гарантируют

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

Улучшается сопровождение таких процедур, а также безопасность (нет прямого

доступа к данным).

Однако следует помнить, что перегрузка хранимых процедур прикладной логикой

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

84

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

серверу может одновременно обращаться несколько клиентов.

Поэтому в большинстве случаев следует принимать компромиссные решения:

часть логики приложения размещать на стороне сервера, часть — на стороне клиента.

Такие клиент-серверные системы называют системами с разделенной логикой.

Описанная архитектура является двухуровневой и называется «толстым клиентом»

(рисунок 2.1).

Рисунок 2.1 – Двухуровневая архитектура клиент-сервер

Создание архитектуры клиент-сервер возможно и на основе многотерминальной

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

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

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

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

информационных систем корпоративного уровня. Подобная организация повышает

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

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

Повышение безопасности информации связанно с тем, что обработка запросов всех

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

устанавливает общие для всех пользователей правила использования БД, управляет

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

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

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

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

85

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым

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

запутанной логикой.

Решением этих проблем может стать применение многоуровневой архитектуры.

Многоуровневая архитектура.

Многоуровневая архитектура является развитием архитектуры клиент-сервер и в

своей классической форме состоит из трех уровней (рисунок 2.2).

Рисунок 2.2 – Трехуровневая архитектура клиент-сервер

На нижнем уровне на компьютерах пользователей расположены приложения

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

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

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

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

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

распределенными базами данных. Сервер приложений размещается в узле сети доступно

всем клиентам.

На третьем, верхнем, уровне расположен удаленный специализированный сервер

баз данных, принимающий информацию от сервера приложений. Сервер баз данных

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

Достоинства трехуровневой архитектуры:

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

сервер приложений;

— уменьшение размера клиентских приложений за счет разгрузки их от лишнего

кода;

86

— единое поведение всех клиентов;

— упрощение настройки клиентов — при изменении общего кода сервера

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

Трехуровневая архитектура устраняет недостатки двухуровневой модели клиент-

сервер. Она позволяет еще больше сбалансировать нагрузку на сеть. С ростом систем

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

Интернет(интранет)-технологии.

Интернет (Internet, Interconnected Networks) — всемирная система объединенных

компьютерных сетей, построенная на использовании протокола IP (Internet Protocol) и

маршрутизации пакетов данных. Интернет образует единую (всемирную)

информационную среду.

Интранет, в отличие от сети Интернет, — внутренняя частная сеть организации.

Как правило, Интранет — это Интернет в миниатюре, который построен на

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

информации внутри этой организации. В информационную базу могут быть включены

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

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

видимую часть Интранет — внутренний Web-сайт организации, основанный на базовых

протоколах HTTP и HTTPS и организованный по принципу клиент-сервер, интранет-сайт

доступен с любого компьютера через браузер (Mozilla Firefox, Microsoft Internet Explorer,

Opera и др.). Таким образом, Интранет — это что-то вроде частного Интернета,

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

Преимущества использования Интранет очевидны:

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

проектами;

— легкий доступ персонала к данным;

— гибкий уровень взаимодействия: можно менять бизнес-схемы взаимодействия

как по вертикали, так и по горизонтали;

— мгновенная публикация актуальной информации (служебные инструкции,

стандарты, службы рассылки новостей и т.д.);

— не требуется инсталляция программы-клиента на компьютерах пользователей (в

качестве нее используется браузер), соответственно, при изменениях функциональности

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

требуется;

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

87

Интранет, к сожалению, обладает и рядом недостатков. В частности, сеть может

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

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

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

недобросовестных работников.

Кроме того, работоспособность и гибкость Интранета требуют значительных

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

Для создания удобных и простых в использовании и сопровождении

информационных систем, эффективно работающих с базами данных, объединяют

интернет(интранет)-технологии с многоуровневой архитектурой. При этом структура

информационного приложения приобретает следующий вид (рисунок 2.3).

Рисунок 2.3 – Соединение интернет(интранет)-технологий с архитектурой клиент-сервер

Благодаря интеграции интернет(интранет)-технологий с архитектурой клиент-

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

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

совместного использования информации. Любая интеграция предопределяет вполне

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

сетях таких ограничений практически нет, то в корпоративных сетях они явно

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

или участников партнерских объединений.

Лекция 3. Процессы в ИС. Эксплуатация ИС.

3.1 Этапы и виды технологических процессов обработки информации.

Технологический процесс обработки информации представляет собой комплекс

взаимосвязанных операций по преобразованию информации в соответствии с

поставленной целью с момента ее возникновения (входа в систему) до момента

потребления пользователем.

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

этапы и операции.

88

Этапы технологического процесса — это его относительно самостоятельные части,

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

обособленностью.

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

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

первичный и основной этапы. На первичном этапе обеспечивается сбор первичной

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

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

результатов.

На всех этапах выполняется необходимый объем операций для достижения

достоверности и полноты преобразования информации.

При этом объектами особого внимания являются время преобразования и качество

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

информации различают следующие технологические операции: сбор и регистрация

информации, передача, прием, запись на носители, арифметическая и логическая

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

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

По степени механизации и автоматизации операции бывают ручные (выписка

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

преимущественно выполняемые человеком, автоматизированные — в большей степени

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

автоматические — без участия человека. По роли в технологическом процессе различают

рабочие и контрольные операции. Рабочие обеспечивают получение конечного

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

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

структурированных и неструктурированных данных. Наиболее развитыми в настоящее

время (с точки зрения задач обработки и анализа информации) являются программные

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

первичной и наиболее трудно формализуемой обработкой.

Информационный поток — это информация (группа данных), рассматриваемая в

процессе ее движения в пространстве и времени в определенном направлении. У этих

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

структурных элементов, называют сообщением. Действие информации направлено на

уменьшение или снятие неопределенности в какой-либо ситуации. Например, в

89

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

информации, необходимой для определения состояния производства и принятия решения.

При оперировании информацией в процессах ее создания (порождения), сбора,

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

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

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

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

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

обрабатывается, выдается и потребляется в виде управляющих сигналов на

технологическое оборудование). Под документированием информации в широком смысле

слова понимают выделение единичной смысловой части информации (данных) по

некоторой предметной области, обособление этой части с приданием ей самостоятельной

роли (имя, статус, реквизиты и т.п.). Процесс документирования превращает информацию

в информационные ресурсы — отдельные документы или массивы документов в

информационных системах.

Документооборот — последовательность прохождения документов с момента их

составления или получения до момента их обработки и использования. Документооборот

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

исполнения, формирование дел, хранение и повторное использование документации. Для

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

иметь в распоряжении обширную и достоверную информацию. Достичь этого можно в

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

потоков. Для этого необходимо опираться на основные принципы документооборота:

— рациональное и своевременное составление документов;

— однократная регистрация документа, позволяющая однозначно

идентифицировать документ, исключение возможности дублирования документов;

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

организации;

— взаимосвязь и рациональная обработка документов;

— сокращение путей прохождения документов.

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

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

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

непосредственно отражающих входную информацию. Конечные документы (выходные

90

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

объект управления.

Итак, технологическим процессом обработки информации можно назвать

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

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

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

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

пользователей, принятого документооборота и т.д.

3.2 Организация сбора, размещения, хранения, накопления, преобразования и

передачи данных в информационную систему.

Сбор и регистрация информации происходят по-разному на различных

экономических объектах. Особое значение при этом придается достоверности, полноте и

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

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

готовой продукции, отпуск товара, получение и отгрузка материалов и т.п.), в банках —

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

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

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

бракованной продукции и т.д.

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

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

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

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

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

определенным образом. На сегодняшний день объемы хранимой информации в десятки

терабайтов уже стали реальностью. Информационные ресурсы такого объема уже

накоплены в хранилищах данных некоторых крупных корпораций (например, данными

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

цифровой фотосъемки поверхности Земли).

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

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

корректировке или замене.

Процедура поиска информации осуществляется автоматически на основе запроса

пользователя.

91

Обработка информации производится на ПЭВМ, как правило, децентрализованно,

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

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

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

вывести на печатающее устройство.

При проектировании технологических процессов ориентируются на режимы их

реализации. Режим реализации технологии зависит от объемно-временных особенностей

решаемых задач и от режимных возможностей технических средств. Рассмотрим

некоторые режимы обработки данных.

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

доступа пользователя к ЭВМ. Сбор и регистрация информации, ввод и обработка не

совпадают по времени. Вначале пользователь собирает информацию, формирует ее в

пакеты в соответствии с какими-либо признаками или типами задач (задачи

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

После завершения приема происходит ввод информации в ЭВМ и обработка. Этот режим

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

Интерактивный режим предусматривает непосредственное взаимодействие

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

запроса (как правило, регламентированного) или диалога с ЭВМ.

Диалоговый режим открывает пользователю возможность непосредственно

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

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

ЭВМ сама может инициировать диалог, сообщая пользователю последовательность шагов

(представление меню) для получения искомого результата.

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

которого она выдает ответ и отключается, тогда как в диалоговом режиме система выдает

ответ и ждет дальнейших действий пользователя.

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

распределенной.

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

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

центры коллективного пользования, оснащенные большими ЭВМ, позволяющими

обрабатывать большие массивы информации, которая затем передавалась пользователям.

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

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

92

необходимые временные параметры при диалоговой обработке данных в

многопользовательском режиме. Кратковременный выход из строя центральной ЭВМ

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

дублировать функции центральной ЭВМ, значительно увеличивая затраты на создание и

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

Децентрализованная обработка информации связана с появлением в 1980-х

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

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

пользователю широкие возможности при работе с информацией. Появление персональных

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

созданию новых информационных технологий. Возникло логически обоснованное

требование перехода от использования отдельных ЭВМ в системах централизованной

обработки данных к распределенной обработке данных.

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

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

решений и др.

Под распределенной обработкой данных понимают обработку приложений

несколькими территориально разделенными ЭВМ.

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

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

Распределенная обработка данных (Distributed Data Processing, DDP) — это

методика выполнения прикладных программ группой систем. При этом пользователь

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

нескольких взаимосвязанных абонентских системах.

Распределенная обработка данных позволяет повысить эффективность

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

оперативность принимаемых ими решений.

Наиболее часто данные размещаются в БД. Базами обычно управляют локальные

СУБД, т. е. размещенные на том же компьютере.

Когда несколько таких БД удалены друг от друга на большие расстояния,

возникает необходимость решения задач управления ими, т.е. распределенными БД. Для

решения таких задач между ЭВМ с локальными СУБД и БД организуют сеть передачи

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

обмена данными. В этом случае используют ПО, управляющее распределенными базами

данных, которые могут образовывать банки данных.

93

Распределенные базы данных (Distributed DataBase, DDB) — это определенным

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

(локально или регионально) и обеспечивающие свободный обмен информацией и поиск

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

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

процессе выполнения запросов.

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

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

фрагментов одной таблицы на разных компьютерах. Для пользователя или прикладной

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

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

централизованной, т.е. размещение БД должно быть прозрачно.

При распределенной обработке работа с базой (представление данных, их

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

состоянии — на сервере. При этом такие БД обычно располагаются на нескольких

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

дублироваться.

Размещение частей общей БД бывает избыточным или неизбыточным.

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

(фрагментов) единой БД. Чтобы поддерживать целостность БД, необходимо постоянно

корректировать все ее копии. Преимущества дублирования уменьшаются, когда

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

устойчивость системы.

Создание распределенных баз данных (РБД) вызвано попыткой одновременного

решения двух задач: интеграции и децентрализации.

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

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

обрабатываются. При этом снижается стоимость системы и увеличивается степень ее

надежности, а также повышается скорость обработки данных.

Выделяют однородные и неоднородные распределенные базы данных. В

однородных распределенных базах данных применяют одну СУБД. В неоднородных

распределенных базах данных используются несколько различных СУБД. Основная

проблема при этом заключается в сложности их интеграции.

Очень важно обеспечить достоверность информации в процессе хранения и

обработки. Резервное копирование может защитить данные от потери и является

94

практически единственным и самым надежным способом предохранить данные от потери

в результате поломки диска, сбоев электропитания, действий злоумышленников и т.д. Для

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

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

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

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

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

внешние носители.

3.3 Системы классификации информации.

Для того чтобы обеспечить эффективный поиск, обработку на ЭВМ и передачу по

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

цифровом виде. С этой целью ее нужно сначала упорядочить (классифицировать), а затем

формализовать (закодировать) с использованием классификатора.

Классификатор — это систематизированный свод наименований и кодов

классификационных группировок. Классификаторы по сфере действия разделяются на

международные, общегосударственные (общесистемные), отраслевые, локальные.

Международные классификаторы входят в состав Системы международных

экономических стандартов (СМЭС) и обязательны для передачи информации между

организациями разных стран мирового сообщества.

Общегосударственные (общесистемные) классификаторы обязательны для

организации процессов передачи и обработки информации между экономическими

системами государственного уровня внутри страны.

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

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

Локальные классификаторы используют в пределах отдельных предприятий.

Классификация объектов — это процедура группировки на качественном уровне,

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

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

Свойства информационного объекта определяются информационными

параметрами — реквизитами, логически неделимым информационным элементом,

описывающим определенное свойство объекта, явления и т. п. Реквизиты выражаются

либо числовыми данными (масса, стоимость, год), либо признаками (цвет, марка машины,

фамилия).

Классификация предусматривает следующие задачи — выявление общих свойств

информационного объекта; разработку правил (алгоритмов) и процедур обработки

95

информации, представленной совокупностью реквизитов. При классификации объектов

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

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

При классификации применяются понятия классификационный признак и его

значение, которые позволяют установить сходство или различие объектов. Признак

классификации — свойство или характеристика объекта классификации, которое

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

Классификационная группировка — это множество или подмножество,

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

В настоящее время чаще всего применяются два типа систем классификации:

иерархическая и многоаспектная. Эти системы различаются разной стратегией

применения классификационных признаков.

Иерархическая система классификации информации построена следующим

образом.

1. Исходное множество элементов составляет нулевой уровень и делится в

зависимости от выбранного классификационного признака на классы (группировки),

которые образуют первый уровень.

2. Каждый класс первого уровня в соответствии с характерным для него

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

3. Каждый класс второго уровня аналогично делится на группы, которые образуют

третий уровень и т.д.

Достоинства иерархической системы классификации — простота построения;

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

иерархической структуры.

Недостатки иерархической системы классификации — жесткая структура, которая

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

классификационные группировки; невозможность группировать объекты по заранее не

предусмотренным сочетаниям признаков.

Многоаспектная система (фасетная и дескрипторная) — это система

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

(аспектов) в качестве основания классификации.

Фасетная система классификации информации представляет собой

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

группировки по определенному аспекту классификации — фасету. Например,

классифицировать фильмы можно в соответствии со следующими группами — тип

96

(документальный, игровой, анимационный); жанр (боевик, комедия, романтика,

фантастика); продолжительность; год; страна; режиссер; другие параметры (немой,

звуковой, цветной, черно-белый и т.п.). Таким образом, каждый фильм обладает

множеством признаков. При поиске нужного фильма используется пересечение

требуемых атрибутов.

Эта система классификации позволяет (в отличие от иерархической) выбирать

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

содержания классифицируемого объекта. При построении фасетной системы

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

повторялись.

Достоинства фасетной системы классификации — возможность создания

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

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

структуры существующих группировок.

Недостаток фасетной системы классификации — сложность ее построения,

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

Для организации поиска информации, для ведения тезаурусов (словарей)

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

приближается к естественному языку описания информационных объектов. Суть

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

1. Отбирают совокупность ключевых слов (дескрипторов ) или словосочетаний,

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

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

2. Выбранные ключевые слова и словосочетания подвергают нормализации, т.е. из

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

3. Создают словарь дескрипторов, т.е. словарь ключевых слов и словосочетаний,

отобранных в результате процедуры нормализации.

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

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

— синонимические, указывающие на некоторую совокупность ключевых слов как

синонимов («студент — учащийся — обучаемый»);

— родовидовые, отображающие включение некоторого класса объектов в более

представительный класс («университет — факультет — кафедра»);

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

(«студент — экзамен — профессор — аудитория»).

97

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

классификатора, являются выбор методов классификации и кодирования и выбор системы

признаков классификации.

Основой классификатора должны быть наиболее существенные признаки

классификации, соответствующие характеру решаемых с помощью классификатора задач.

При этом данные признаки могут быть или соподчиненными, или несоподчиненными.

При соподчиненных признаках классификации и стабильном комплексе задач, для

решения которых предназначен классификатор, целесообразно использовать

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

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

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

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

3.4 Экспортирование структур баз данных.

При работе с информационной системой могут возникать ситуации, когда

требуется производить перенос данных из одной базы данных в другую. Этот процесс

называется экспортированием.

Экспортирование данных требуется при переводе БД на другой физический

носитель, при создании копии БД, переносе данных между информационными системами.

Задачи переноса данных между ИС возникают при пересечении предметных областей

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

это могут быть системы различного уровня иерархии (информационные системы

министерства и подчиненной организации) либо автоматизированная система

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

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

характеристик источника и получателя данных и их соответствия друг другу.

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

преобразований переносимых данных.

Преобразование данных может быть следующих видов:

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

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

— реструктуризация — изменение структуры БД источника в соответствии со

структурой получателя;

— агрегирование — БД получает не просто данные, а некоторый сводный или

итоговый отчет;

98

— кодирование и декодирование — данные изменяются так, чтобы они

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

— конвертирование — приведение к формату атрибута в БД-получателе;

— согласование — в разных БД могут использоваться разные способы

отображения одной и той же информации (например, в километрах и в метрах),

необходимо обеспечить их согласование;

— проверка на допустимость значений.

Таким образом, преобразование данных при экспортировании — это сложная

задача, требующая создания специального алгоритма запросов (сценария).

Лекция 4. Показатели эффективности ИС. Безопасность ИС.

Эффективность информационной системы — это совокупность свойств системы,

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

потребностей пользователей в соответствии с ее назначением.

Основными показателями эффективности информационных систем являются

надежность, достоверность, безопасность.

Надежность — свойство системы сохранять во времени в установленных

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

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

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

системы.

Достоверность — свойство системы, обусловливающее безошибочность

производимых ею преобразований информации.

Достоверность функционирования информационной системы полностью

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

Безопасность информационной системы — свойство, заключающееся в

способности системы обеспечить конфиденциальность и целостность информации, то есть

защиту информации от несанкционированного доступа.

Показатели эффективности должны отражать количественную оценку степени

достижения системой поставленной цели.

Эффективность системы является сложным, интегральным свойством и зависит

также от ряда простых свойств, таких как:

— прагматическая эффективность — действенность системы, т.е. степень

реализации системой своего предназначения;

99

— техническая эффективность — техническое совершенство системы;

— технологическая эффективность — простота и технологичность разработки и

создания системы;

— эксплуатационная эффективность — удобство использования и обслуживания

системы и др.

Прагматическую эффективность можно представить показателями достоверности

преобразования информации, безопасности информационной системы, точности

вычислений и преобразования информации; полноты формирования системой

результатной информации, оперативности.

Показатели технической эффективности должны оценивать техническое

совершенство информационной системы, научно-технический уровень организации и

функционирования этой системы.

Показатели технологическо-эксплуатационной эффективности весьма

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

функциональные возможности, количество обслуживаемых клиентов,

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

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

Обобщающими показателями эффективности информационной системы являются

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

произведенных на создание и функционирование системы затрат. Расчет затрат обычно не

составляет большого труда, а вот расчет результатов остается сложной, до конца не

решенной проблемой. Часто прибыль определяется путем экспертной оценки и по

аналогии с другими подобными системами, а социальный эффект количественно вообще

не определяется.

Подробно о расчете экономической эффективности информационных систем мы

будем говорить в завершении изучения курса.

А теперь подробнее остановимся на вопросах безопасности информации, так как

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

на достоверность информации в ИС.

Безопасность информационных систем.

Безопасность информационной системы — свойство, заключающееся в

способности системы обеспечить конфиденциальность и целостность информации, т.е.

защиту информации от несанкционированного доступа, обращенного на ее раскрытие,

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

основных информационных проблем XXI века.

100

Действительно, хищение информации, ее сознательное искажение и уничтожение

часто приводят к трагическим для пострадавшей стороны последствиям, ведущим к

разорению и банкротству фирм и даже к человеческим жертвам. Перечень бед от

нарушения безопасности информации огромен — тысячи коммерческих компьютерных

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

хищением конфиденциальной информации. Если раньше для успешного совершения

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

парализовать системы телекоммуникаций.

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

грозить:

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

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

информацией;

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

изнутри сети, их корыстное использование и разглашение;

— целенаправленное искажение, фальсификация или подмена данных при

несанкционированном доступе;

— подмена и искажение информации, предоставленной для свободного доступа

(например Web-страниц);

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

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

инфицированных внешних носителей (сменных дисков, дискет, CD и DVD-дисков) и т.д.

Все угрозы информационным системам можно объединить в три группы:

— угроза раскрытия — возможность того, что информация станет известной тому,

кому не следовало бы ее знать;

— угроза целостности — умышленное несанкционированное изменение

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

передаваемых из одной системы в другую;

— угроза отказа в обслуживании — опасность появления блокировки доступа к

некоторому ресурсу вычислительной системы.

Методы обеспечения информационной безопасности в зависимости от способа их

реализации можно разделить на следующие классы.

Организационные методы подразумевают рациональное конфигурирование,

организацию и администрирование системы.

101

В первую очередь это касается сетевых информационных систем, операционных

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

определяющих порядок доступа и работы в сети.

Технологические методы включают в себя технологии выполнения сетевого

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

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

обработки поступающей информации.

Аппаратные методы реализуют физическую защиту системы от

несанкционированного доступа, аппаратные функции идентификации периферийных

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

Программные методы — самые распространенные методы защиты информации

(например, программы идентификации пользователей, парольной защиты и проверки

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

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

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

защиты, как правило, реализованы быть не могут — все они содержат программный

компонент).

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

системных решений по защите информации существенно превосходит по затратам

аппаратные, технологические и тем более организационные решения (конечно, если

использовать лицензионные, а не «пиратские» программы).

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

время вызывают следующие направления защиты информации и соответствующие им

программно-технические средства защиты:

— от несанкционированного доступа информационных ресурсов автономно

работающих и сетевых компьютеров. Наиболее остро проблема стоит для серверов и

пользователей интернет-иинтранет-сетей. Эта функция реализуется многочисленными

программными, программно-аппаратными и аппаратными средствами;

— секретной, конфиденциальной и личной информации от чтения посторонними

лицами и целенаправленного ее искажения.

Эта функция обеспечивается как средствами защиты от несанкционированного

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

отдельный класс;

102

— информационных систем от многочисленных компьютерных вирусов,

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

компоненты системы (такие, как BIOS).

Активно развиваются также средства защиты от утечки информации по цепям

питания, каналам электромагнитного излучения компьютера или монитора (применяется

экранирование помещений, использование генераторов шумовых излучений, специальный

подбор мониторов и комплектующих компьютера, обладающих наименьшим

излучением), средства защиты от электронных «жучков», устанавливаемых

непосредственно в комплектующие компьютера, и т.д.

Защита от несанкционированного доступа к ресурсам компьютера — это

комплексная проблема, подразумевающая решение следующих вопросов:

— присвоение пользователю, а равно и терминалам, программам, файлам и

каналам связи уникальных имен и кодов (идентификаторов);

— выполнение процедур установления подлинности при обращениях (доступе) к

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

устройство, сообщившее идентификатор, в действительности ему соответствует.

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

идентификации пользователей (мыши и клавиатуры с функцией дактилоскопической

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

том числе по сетчатке и радужной оболочке глаз и т.п.);

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

запрашиваемым данным (на выполнение над ними определенных операций — чтение,

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

— автоматическую регистрацию в специальном журнале всех как

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

идентификатора пользователя, терминала, времени и сущности запроса, то есть ведение

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

хакер, а иногда и определить его IP-адрес и точное местоположение. В литературе

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

информации.

Полномочия (возможности) пользователя в системе определяются набором его

прав. Права пользователей бывают стандартные и расширенные. К стандартным относятся

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

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

выполнять выключение сервера и т.п.

103

Расширенные права во многом являются специфичными для операционной

системы или приложений. Механизмы защиты Windows позволяют гибко ограничивать

права пользователей или предоставлять им доступ к любым ресурсам системы.

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

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

прикладным вопросам защиты информации, на международном и государственном

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

Мировые информационные ресурсы.

К мировым информационным ресурсам относятся информационные системы,

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

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

всех развитых стран, в том числе и для России.

Сектор деловой информации (биржевой, финансовой, коммерческой,

экономической, статистической) включает в себя:

— биржевую и финансовую информацию — информацию о котировках ценных

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

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

информации, брокерскими компаниями, банками;

— экономическую и социальную статистическую информацию;

— числовую экономическую, демографическую, социальную информацию в виде

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

— коммерческую информацию — информацию по компаниям, фирмам,

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

связям, сделкам, руководителям и т.п.;

— деловые новости в области экономики и бизнеса, предоставляемые

специальными информационными службами.

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

охватывает:

— профессиональную информацию — специальные данные и информацию для

юристов, врачей, фармацевтов, преподавателей, инженеров и т.п.;

— научно-техническую информацию — документальную и реферативную,

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

естественных, технических и общественных наук, отраслей производства и сфер

человеческой деятельности;

104

— услуги организации доступа к первоисточникам (в том числе в виде копий

документов) — через библиотеки и специализированные службы.

Сектор массовой и потребительской информации (новости, услуги на основе

современных средств глобальной телекоммуникации) охватывает:

— новости и литературу — информацию служб новостей и агентств прессы,

электронные журналы, справочники, энциклопедии;

— потребительскую и развлекательную информацию, ориентированную на

домашнее, а не служебное использование — местные новости, погоду, расписания

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

отелей и ресторанов, информацию по обмену валюты, аренде машин, турам, дачам для

аренды.

Сектор электронных сделок представлен в основном системами банковских карт,

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

биржевых, банковских и расчетных операций. Интернет привлек в эти области массового

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

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

сохраняющиеся явно недостаточные возможности защиты информации. Поэтому

Интернет быстро превращает данный рынок в массовый, в быстро развивающуюся новую

отрасль электронной торговли. На развитом рынке электронных сделок имеются системы

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

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

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

услуг и т.п.

На рынке электронной глобальной коммуникации можно выделить различные

системы на основе современных средств связи и человеческого общения — коммерческие

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

диалоговые системы, объединяющие владельцев ПК, телеконференции, электронные

сетевые доски объявлений и бюллетени и т.п. Интернет вошел на мировой

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

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

Появление интернет-технологий, позволяющих выстраивать деловые отношения в

среде Интернет, дает возможность говорить о возникновении нового типа экономики,

которая может быть названа «интернет-экономикой».

Контрольные вопросы

105

1. Назовите основные этапы развития ИС.

2. В чем различие между понятиями «информационная технология» и

«информационная система»?

3. Какие процессы обеспечивают работу информационной системы?

4. Что входит в функциональную часть информационных систем?

5. Назовите виды обеспечения информационных систем.

6. По каким признакам можно классифицировать информационные системы?

7. В чем различие между управляющими и советующими информационными

системами?

8. Каковы достоинства архитектуры клиент-сервер по сравнению с файл-серверной

архитектурой?

9. В чем особенность трехуровневой архитектуры информационных систем?

10. Перечислите достоинства и недостатки интранет-технологии.

11. Что включают в себя мировые информационные ресурсы?

12. Назовите показатели эффективности информационных систем.

13. Что может угрожать корпоративной информационной системе?

14. Как обеспечить безопасность информации в информационной системе?

15. Какие существуют средства и методы обеспечения информационной

безопасности корпоративных информационных систем?

Раздел 2. Экспертные системы.

Лекция 5. Понятие искусственного интеллекта (ИИ).

Информационная технология экспертных систем (ЭС).

106

Термин интеллект (intelligence) происходит от латинского intellectus, что означает

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

интеллект ИИ (artificial intelligence, AI) можно толковать как свойство технических систем

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

оптимальные решения на основе ранее полученного опыта и рационального анализа

внешних воздействий.

Большинство из нас уверены, что смогут отличить «разумное» поведение от

«неразумного». Однако вряд ли кто-нибудь сможет дать достаточно полное определение

искусственному интеллекту, отражающее сложность человеческого разума.

Проблема определения искусственного интеллекта сводится к проблеме

определения интеллекта вообще. Является ли он чем-то единым или же этот термин

объединяет набор разрозненных способностей?

Можно ли судить о наличии интеллекта только по наблюдаемому поведению или

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

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

проектировании интеллектуальных устройств? И более того, необходимо ли создавать

интеллектуальную компьютерную программу по образу и подобию человеческого разума

или же достаточно строго инженерного подхода? Возможно ли вообще достичь

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

богатства чувств и опыта, присущего лишь человеку?

На эти вопросы ответа пока не найдено, но все они помогают сформировать задачи

и методологию, составляющие основу современного ИИ. Отчасти привлекательность

искусственного интеллекта в том и состоит, что он является оригинальным и мощным

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

Исторически сложились три основных подхода в моделировании ИИ.

В рамках первого подхода объектом исследований являются структура и

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

мышления. Необходимыми этапами исследований в этом направлении являются

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

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

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

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

помощью ЭВМ. Цель работ в этом направлении — создание алгоритмического и

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

человека.

107

Наконец, третий подход ориентирован на создание смешанных человеко-

машинных, или, как еще говорят, интерактивных интеллектуальных систем, на симбиоз

возможностей естественного и искусственного интеллекта. Важнейшими проблемами в

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

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

В начале 80-х годов прошлого столетия в исследованиях по искусственному

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

экспертные системы (ЭС). Цель исследований по ЭС состоит в разработке программ,

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

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

экспертных систем основаны на знаниях эксперта.

Экспертные системы — это сложные программные комплексы, аккумулирующие

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

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

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

значительное распространение в мире. Технология экспертных систем позволяет

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

специалистов, в недалекой перспективе ЭС будут играть ведущую роль во всех фазах

проектирования, разработки, производства, распределения, продажи, поддержки и

оказания услуг. Технология экспертных систем, получившая коммерческое

распространение, обеспечит революционный прорыв в интеграции приложений из

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

Экспертные системы предназначены для так называемых неформализованных

задач, при этом они не отвергают и не заменяют традиционного подхода к разработке

программ, ориентированного на решение формализованных задач.

Неформализованные задачи обычно обладают следующими особенностями:

— ошибочностью, неоднозначностью, неполнотой и противоречивостью исходных

данных;

— ошибочностью, неоднозначностью, неполнотой и противоречивостью знаний о

проблемной области и решаемой задаче;

— большой размерностью пространства решения, т. е. перебор при поиске решения

весьма велик;

— динамически изменяющимися данными и знаниями.

108

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

очень важный класс задач. Многие специалисты считают, что эти задачи являются

наиболее массовым классом задач, решаемых ЭВМ.

Решение специальных задач требует специальных знаний.

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

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

всякий раз, когда в этом возникнет необходимость. Являясь одним из основных

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

компьютерные программы, трансформирующие опыт экспертов в какой-либо области

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

приобретенное человеком по мере накопления практического опыта решения

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

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

рамках технологии поддержки принятия решений. Однако часто они дают в достаточной

степени приемлемые решения для их практического использования. Все это делает

возможным использовать технологию экспертных систем в качестве советующих систем.

Экспертные системы имеют много особенностей. Они применяются для решения

только трудных практических задач. По качеству и эффективности решения экспертные

системы не уступают (не должны уступать) решениям специалиста. Кроме того, решения

экспертных систем обладают «прозрачностью», т.е. могут быть объяснены пользователю

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

взаимодействия с экспертом. Экспертные системы и системы искусственного интеллекта

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

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

эвристический поиск решения (а не исполнение известного алгоритма).

Экспертное знание — это сочетание теоретического понимания проблемы и набора

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

области.

Большинство экспертных систем были написаны для специализированных

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

определенными стратегиями принятия решений. Несмотря на воодушевляющие

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

технологии. Основные проблемы таковы:

— трудности в передаче «глубоких» знаний предметной области;

109

— недостаток гибкости. Если людей поставить перед задачей, которую они не в

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

вырабатывают какую-то стратегию для перехода к решению проблемы. Экспертным

системам этой способности не хватает;

— трудности в предоставлении аргументированных объяснений. Обычно

ограничиваются описанием шагов, которые были предприняты в поиске решения;

— трудности в тестировании. Хотя обоснование корректности любой большой

компьютерной системы достаточно трудоемко, экспертные системы проверять особенно

тяжело;

— ограниченные возможности обучения на опыте.

Очевидное решение этих проблем — «заставить» программы учиться самим на

опыте, аналогах или примерах. Несмотря на эти ограничения, экспертные системы

доказали свою ценность во многих важных областях.

Типичная экспертная система состоит из следующих основных компонентов:

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

подсистема объяснений (рисунок 5.1).

Рисунок 5.1 – Основные компоненты информационной технологии экспертных систем

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

пользователя с экспертной системой как на стадии ввода информации, так и на стадии

получения результатов.

110

База знаний — ядро экспертной системы, совокупность знаний предметной

области, записанная на машинный носитель в форме, понятной эксперту и пользователю

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

человеческому представлению существует БД в машинном представлении.

Интерпретатор — программа, моделирующая ход рассуждений эксперта на

основании знаний, имеющихся в БЗ (его иногда называют решателем, дедуктивной

машиной или блоком логического вывода).

Модуль создания системы — это программный модуль, предназначенный для

преобразования данных и правил, полученных от инженера по знаниям, в форму,

пригодную для использования их в программе.

Подсистема объяснений — программа, позволяющая пользователю получить

ответы на вопросы: «Как была получена та или иная рекомендация?» и «Почему система

приняла такое решение?»

Ответ на вопрос «как» — это трассировка всего процесса получения решения с

указанием использованных фрагментов БЗ, т.е. всех шагов в цепочке решений. Ответ на

вопрос «почему» — ссылка на решение, непосредственно предшествовавшее

полученному решению, т. е. отход на один шаг назад.

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

специальностей:

— эксперт в проблемной области, задачи которой будет решать экспертная

система;

— инженер по знаниям — специалист по разработке экспертных систем

(используемые им технологию, методы называют технологией (методами) инженерии

знаний);

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

разработки экспертных систем.

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

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

Инженер по знаниям помогает эксперту выявить и структурировать знания,

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

средства, наиболее подходящего для данной проблемной области, определяет способ

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

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

Экспертная система работает в двух режимах: приобретения знаний и решения

задачи (называемом также режимом консультации или режимом использования ЭС).

111

В режиме приобретения знаний общение с экспертной системой осуществляет

эксперт (через посредничество инженера по знаниям). В этом режиме эксперт, используя

модуль создания системы, наполняет систему знаниями, которые позволяют ЭС в режиме

решения самостоятельно (без эксперта) решать задачи из проблемной области. Эксперт

описывает проблемную область в виде совокупности данных и правил. Данные

определяют объекты, их характеристики и значения, существующие в области

экспертизы. Правила определяют способы манипулирования с данными, характерные для

рассматриваемой области.

Отметим, что режиму приобретения знаний в традиционном подходе к разработке

программ соответствуют этапы алгоритмизации, программирования и отладки,

выполняемые программистом. В случае экспертной системы, в отличие от традиционного

подхода, программы разрабатывает не программист, а эксперт, не владеющий

программированием.

В режиме консультации общение с ЭС осуществляет конечный пользователь,

которого интересует результат и (или) способ его получения. Необходимо отметить, что в

зависимости от назначения экспертной системы пользователь может не быть

специалистом в данной проблемной области. В этом случае он обращается к ЭС за

результатом. Если пользователь — специалист, то в этом случае он может сам получить

результат, но он обращается к ЭС с целью либо ускорить процесс получения результата,

либо возложить на ЭС рутинную работу. В режиме консультации данные о задаче

пользователя после обработки их диалоговым компонентом поступают в рабочую память.

Интерпретатор на основе входных данных из рабочей памяти, общих данных о

проблемной области и правил из базы знаний формирует решение задачи.

Необходимо отметить, что в настоящее время технология экспертных систем

используется для решения различных типов задач (интерпретация, предсказание,

диагностика, планирование, конструирование, контроль, отладка, инструктаж,

управление) в самых разнообразных проблемных областях, таких как финансы, нефтяная

и газовая промышленность, энергетика, транспорт, фармацевтическое производство,

космос, металлургия, образование, телекоммуникации и связь и др.

Ниже приведены примеры крупномасштабных экспертных систем.

MICIN — экспертная система для медицинской диагностики.

Разработана группой по инфекционным заболеваниям Стэнфордского

университета. Ставит соответствующий диагноз исходя из представленных ей симптомов

и рекомендует курс медикаментозного лечения любой из диагностированных инфекций.

База данных состоит из нескольких сотен правил.

112

PUFF — анализ нарушения дыхания. Данная система представляет собой MICIN,

из которой удалили данные по инфекциям и вставили данные о легочных заболеваниях.

DENDRAL — распознавание химических структур. Данная система старейшая из

имеющих звание экспертных. Первые версии данной системы появились еще в 1965 г. все

в том же Стэнфордском университете. Пользователь дает системе DENDRAL некоторую

информацию о веществе, а также данные спектрометрии (инфракрасной, ядерного

магнитного резонанса и масс-спектрометрии), и та в свою очередь выдает диагноз в виде

соответствующей химической структуры.

PROSPECTOR — экспертная система, созданная для содействия поиску

коммерчески оправданных месторождений полезных ископаемых.

Лекция 6. Смысл экспертного анализа.

Способность выполнить экспертный анализ — это не только наличие

определенных знаний и уровня квалификации. Для этого нужно обладать и очень

специфическими навыками и умением разобраться в конкретной ситуации в данной

предметной области.

Ранее было сказано, что экспертная система должна обладать знаниями. Просто

способность выполнять некоторый алгоритм, например, производить анализ списка

элементов на наличие какого-либо свойства, явно не отвечает этому требованию. Это все

равно, что дать первому случайному прохожему список вопросов и ответов и ожидать от

него успешного выполнения поиска и устранения неисправностей в системах

определенного типа. Раньше или позже, но он обязательно столкнется с ситуацией, не

предусмотренной в том списке, которым его снабдили. Знания, которыми обладает

программа, должны быть сконцентрированы в определенной предметной области.

Случайный набор имен, дат и мест событий, сентенций из классиков и т. п. — это отнюдь

не те знания, которые могут послужить основой для программы, претендующей на

способность выполнить экспертный анализ. Знания предполагают определенную

организацию и интеграцию, т.е. отдельные сведения должны соотноситься друг с другом

и образовывать нечто вроде цепочки, в которой одно звено «тянет» за собой следующее

(причинно-следственная связь).

Недостаточно получить доступ к оперативной документации — необходимо

получить в свое распоряжение специалиста (или программу), способного справиться с

возникшими проблемами.

113

Экспертная система может полностью взять на себя функции, выполнение которых

обычно требует привлечения опыта специалиста, или играть роль ассистента для

человека, принимающего решение. Другими словами, система (техническая или

социальная), требующая принятия решения, может получить его непосредственно от

программы или через промежуточное звено — человека, который общается с программой.

Тот, кто принимает решение, может быть экспертом со своими собственными правами, и в

этом случае программа может оправдать свое существование, повышая эффективность его

работы. Альтернативный вариант — человек, работающий в сотрудничестве с такой

программой, может добиться с ее помощью результатов более высокого качества.

Правильное распределение функций между человеком и машиной является одним

из ключевых условий высокой эффективности внедрения экспертных систем.

Перечень типовых задач, решаемых экспертными системами, включает:

— извлечение информации из первичных данных (таких, как сигналы,

поступающие от гидролокатора);

— диагностика неисправностей (как в технических системах, так и в человеческом

организме);

— структурный анализ сложных объектов (например, химических соединений);

— выбор конфигурации сложных многокомпонентных систем (например,

распределенных компьютерных систем);

— планирование последовательности выполнения операций, приводящих к

заданной цели (например, выполняемых промышленными роботами).

Хотя известны и «обычные» программы, специализирующиеся на определенных

задачах из представленного перечня (или аналогичных им в смежных областях), далее мы

покажем, в чем состоит существенная разница между «обычным» подходом и

предлагаемым в сфере искусственного интеллекта и почему экспертные системы можно

выделить в отдельный, достаточно хорошо различимый класс программ. Четкого

формального определения экспертной системы, которое всех бы удовлетворило, не

существует — приведенное выше тоже довольно расплывчато. Но тем не менее

существует довольно много важных признаков, присущих в той или иной степени всем

экспертным системам.

Лекция 7. Характеристики ЭС.

Прежде всего нужно отметить, что экспертная система моделирует не столько

физическую (или иную) природу определенной проблемной области, сколько механизм

114

мышления человека применительно к решению задач в этой проблемной области. Это

существенно отличает экспертные системы от систем математического моделирования

или компьютерной анимации. Нельзя, конечно, сказать, что программа полностью

воспроизводит психологическую модель специалиста в этой предметной области

(эксперта), но важно, что основное внимание все-таки уделяется воспроизведению

компьютерными средствами методики решения проблем, применяемой экспертом, т.е.

выполнению некоторой части задач так же (или иногда даже лучше), как это делает

эксперт.

Система помимо выполнения вычислительных операций формирует определенные

соображения и выводы, основываясь на тех знаниях, которыми она располагает. Знания в

системе представлены, как правило, на некотором специальном языке и хранятся отдельно

от собственно программного кода, который и формирует выводы и соображения.

При решении задач экспертными системами основными являются эвристические и

приближенные методы, которые в отличие от алгоритмических не всегда гарантируют

успех. Такие методы являются приблизительными в том смысле, что они не требуют

исчерпывающей исходной информации, и существует определенная степень уверенности

(или неуверенности) в том, что предлагаемое решение является верным.

Одна из основных характеристик экспертной системы — ее производительность,

т.е. скорость получения результата и его достоверность, или надежность. Экспертная

система должна за достаточно короткое время найти решение не хуже того, которое

может предложить специалист данной предметной области.

Экспертная система должна обладать способностью обосновать принятие именно

такого решения и доказать его. ЭС проектируется в расчете на взаимодействие с разными

пользователями, для которых ее работа должна быть по возможности «прозрачной».

Это особенно необходимо в областях, характеризующихся неопределенностью,

неточностью информации (например, в медицинской диагностике). В этих случаях

способность к объяснению нужна для того, чтобы повысить степень доверия пользователя

к советам системы, а также для того, чтобы дать возможность пользователю обнаружить

возможный дефект в рассуждениях системы.

Пользователь должен получить всю необходимую информацию, чтобы быть

уверенным, что решение принято «не с потолка».

В связи с этим в экспертных системах следует предусматривать дружественное

взаимодействие с пользователем. Кроме того, отсутствие достаточной прозрачности

поведения системы не позволит эксперту повлиять на ее производительность или дать

совет, как можно ее повысить. Прослеживание и оценка поведения системы — задача

115

довольно сложная и для ее решения необходимы совместные усилия эксперта и

специалиста по информатике.

Экспертные системы должны решать задачи, требующие экспертных знаний в

некоторой конкретной области. В той или иной форме экспертные системы должны

обладать этими знаниями.

Зачастую термин «система», основанная на знаниях, и используется в качестве

синонима термина «экспертная система», хотя, строго говоря, экспертная система — это

более широкое понятие.

Система, основанная на знаниях, — это любая система, процесс работы которой

основан на применении правил отношений к символическому представлению знаний, а не

на использовании алгоритмических или статистических методов. Таким образом,

программа, способная рассуждать о погоде, будет системой, основанной на знаниях, даже

в том случае, если она не способна выполнить метеорологическую экспертизу. А вот

чтобы иметь право называться метеорологической экспертной системой, программа

должна давать прогноз погоды (достоверность прогноза — это другой вопрос).

От других видов программ из области искусственного интеллекта экспертные

системы отличаются тем, что имеют ярко выраженную практическую направленность в

научной и коммерческой областях.

Суммируя все сказанное, отметим, что экспертная система содержит знания в

определенной предметной области, накопленные в результате практической деятельности

человека, и использует их для решения специфичных для этой области проблем. Этим

экспертные системы отличаются от прочих, «традиционных», систем, в которых

предпочтение отдается более общим и менее связанным с предметной областью

теоретическим методам, чаще всего математическим.

Лекция 8. Функции ЭС.

В самом общем случае, для того чтобы построить ЭС, необходимо разработать

механизмы выполнения следующих функций:

1) приобретение знаний в конкретной предметной области;

2) представление знаний;

3) решение задач с использованием знаний о конкретной предметной области

(управление процессом решения);

4) объяснение намерений и решений системы во время и после окончания процесса

решения задачи (разъяснение принятого решения).

116

Каждая из этих функций может оказаться очень сложной и зависит от прикладной

области, а также от различных практических требований. В процессе разработки и

реализации могут возникать разнообразные проблемы.

Приобретение знаний.

Приобретение знаний — это передача потенциального опыта решения проблемы от

некоторого источника знаний и преобразование его в вид, позволяющий использовать эти

знания в программе.

Передача знаний выполняется в процессе достаточно длительных собеседований

между специалистом по проектированию экспертной системы (инженером по знаниям) и

экспертом в определенной предметной области, способным четко сформулировать

имеющийся у него опыт. Многие исследователи рассматривают функцию приобретения

знаний в качестве одного из главных «узких мест» технологии экспертных систем.

Проблемы могут возникнуть самые разнообразные.

Специалисты в узкой области, как правило, пользуются собственным

профессиональным жаргоном, который трудно перевести на обычный язык. Но смысл

жаргонных слов (профессионализмов) совсем не очевиден, а потому требуется много

дополнительных вопросов для уточнения их логического значения.

Неудовлетворительные результаты собеседований эксперта и инженера по знаниям

ввиду использования первым профессионализмов пробудили у некоторых исследователей

интерес к автоматизации процесса передачи знаний специалистом машине. Одно из

направлений исследований в этой области — автоматизированное извлечение знаний —

появилось как побочный продукт в развитии систем человеко-машинного диалога. Другое

направление — машинное обучение. Идея состоит в том, чтобы машина училась решать

проблемы примерно так же, как учится человек.

Проблемой является еще и то, что факты и принципы, лежащие в основе многих

специфических областей знания эксперта, не могут быть четко сформулированы в

терминах математической теории или детерминированной модели, свойства которой

хорошо понятны. Так, эксперту может быть известно, что определенное событие может

наступить, но он ничего не сможет сказать о механизмах, которые приводят к

наступлению этого события. Для того чтобы решить проблему в определенной области,

эксперту недостаточно просто обладать суммой знаний о фактах и принципах в этой

области. Например, опытный специалист знает, какого рода информацией нужно

располагать для формулировки того или иного суждения, насколько надежны различные

источники информации и как можно расчленить сложную проблему на несколько

простых, которые можно решать более или менее независимо.

117

Выявить в процессе собеседования такого рода знания, основанные на личном

опыте и плохо поддающиеся формализации, значительно сложнее, чем получить простой

перечень каких-то фактов или общих принципов.

Экспертный анализ даже в очень узкой области, выполняемый человеком, очень

часто нужно поместить в довольно обширный контекст, который включает и многие

вещи, кажущиеся эксперту само собой разумеющимися, но для постороннего отнюдь

таковыми не являющиеся.

Представление знаний.

Представление знаний — это отдельная область исследований, тесно связанная с

философией формализма и когнитивной психологией.

Предмет исследования в этой области — методы ассоциативного хранения

информации, подобные тем, которые существуют в мозгу человека. При этом основное

внимание, естественно, уделяется логической, а не биологической стороне процесса,

опуская подробности физических преобразований.

База знаний — наиболее важная компонента экспертной системы, на которой

основаны ее «интеллектуальные способности».

В отличие от всех остальных компонент экспертной системы база знаний —

изменяемая часть системы, которая может пополняться и модифицироваться инженерами

по знаниям. Существует несколько способов представления знаний в экспертной системе,

однако общим для всех них является то, что знания представлены в символьной форме

(элементарными компонентами представления знаний являются тексты, списки и другие

символьные структуры).

Таким образом, в экспертной системе реализуется принцип символьной природы

рассуждений, который заключается в том, что процесс рассуждения представляется как

последовательность символьных преобразований.

Наиболее распространенный способ представления знаний — в виде конкретных

фактов и правил, по которым из имеющихся фактов могут быть выведены новые. Факты

могут быть представлены, например, в виде троек: атрибут, объект, значение.

Такой факт означает, что заданный объект имеет заданный атрибут (свойства) с

заданным значением. Например, тройка (возраст, пациент, 77) представляет факт, что

возраст пациента — 77 лет. В более простых случаях факт выражается не конкретным

значением атрибута, а каким-либо простым утверждением, которое может быть

истинным или ложным, например: «Пациент курит». В таких случаях факт можно

обозначить каким-либо кратким именем (например, курение) или использовать для

представления факта сам текст соответствующей фразы.

118

Правила в базе знаний имеют вид:

ЕСЛИ а TO s,

где а — условие; s — действие.

Действие s исполняется, если а истинно. Наиболее часто действие s, так же, как и

условие, представляет собой утверждение, которое может быть выведено системой (т. е.

становится ей известной), если истинно условие правила а. Правила в базе знаний служат

для представления эвристических знаний (эвристик), т.е. неформальных правил

рассуждения, вырабатываемых экспертом на основе опыта его деятельности. Простой

пример правила:

ЕСЛИ «Пациент курит»

ТО «У пациента больные легкие».

В качестве условия а может выступать либо факт (как в данном примере), либо

несколько фактов аь..., а„, соединенные логическими операциями.

Пример предыдущего правила с более сложным условием (правило 1):

ЕСЛИ

(«Пациент курит») / f («Кровяное давление выше среднего»)

ТО

«Риск высокий» (правило 1)

Действия, входящие в состав правил, могут содержать новые факты. При

применении таких правил эти факты становятся известны системе, т.е. включаются в

множество фактов, которое называется рабочим множеством. Например, если факты

«Пациент курит» и «Кровяное давление выше среднего» уже имеются в рабочем

множестве, то после применения приведенного выше правила в него также включается

факт «Риск высокий».

Если система не может вывести некоторый факт, истинность или ложность

которого требуется установить, то система спрашивает о нем пользователя. Например:

Верно ли, что «Пациент курит»?

При получении положительного ответа от пользователя факт «Пациент курит»

включается в рабочем множество.

Существуют статические и динамические базы знаний. Статические базы данных

не изменяются со временем. Динамические базы знаний изменяются со временем. Новые

факты, добавляемые в базу знаний, являются результатом вывода, который состоит в

применении правил к имеющимся фактам.

Экспертные системы могут иметь монотонный и немонотонный выводы.

119

В системах с монотонным выводом факты, хранимые в базе знаний, статичны, т.е.

не изменяются в процессе решения задачи.

В системах с немонотонным выводом допускается изменение или удаление фактов

из базы знаний. Изменение фактов в свою очередь приводит к необходимости удаления из

базы знаний заключений, полученных с помощью упомянутых правил. Тем самым вывод

выполняется повторно для того, чтобы пересмотреть решения, полученные на основе

подвергшихся изменению фактов.

Решение задач с использованием знаний.

При проектировании экспертной системы серьезное внимание должно быть

уделено и тому, как осуществляется доступ к знаниям и как они используются при поиске

решения. Знание о том, какие знания нужны в той или иной конкретной ситуации, и

умение ими распорядиться — важная часть процесса функционирования экспертной

системы. Такие знания получили наименование метазнаний, т.е. знаний о знаниях.

Решение нетривиальных проблем требует и определенного уровня планирования и

управления при выборе, какой вопрос нужно задать, какой тест выполнить и т.д.

Использование разных стратегий перебора имеющихся знаний, как правило,

довольно существенно влияет на характеристики эффективности программы. Эти

стратегии определяют, каким способом программа отыскивает решение проблемы в

некотором пространстве альтернатив.

Существует такая программная компонента экспертных систем, как подсистема

вывода, реализующая процесс рассуждений системы на основе базы знаний и рабочего

множества. Она выполняет две функции:

1) просмотр существующих фактов из рабочего множества и правил из базы знаний

и добавление (по мере возможности) в рабочее множество новых фактов;

2) определение порядка просмотра и применения правил. Эта подсистема

управляет процессом консультации, сохраняет для пользователя информацию о

полученных заключениях и запрашивает у него информацию, когда для срабатывания

очередного правила в рабочем множестве оказывается недостаточно данных.

Цель экспертной системы — вывести некоторый заданный факт, который

называется целевым утверждением, т.е. в результате применения правил добиться того,

чтобы этот факт был включен в рабочее множество, либо опровергнуть этот факт, т.е.

убедиться, что его вывести невозможно, следовательно, при данном уровне знаний

системы он является ложным. Целевое утверждение либо «заложено» заранее в базу

знаний системы, либо извлекается системой из диалога с пользователем.

120

Работа системы представляет собой последовательность шагов, на каждом из

которых система выбирает из базы некоторое правило, которое можно применить к

текущему содержимому рабочего множества. Цикл заканчивается, когда выведено или

опровергнуто целевое утверждение. Цикл работы экспертной системы иначе называется

логическим выводом. Логический вывод может происходить многими способами, из

которых наиболее распространенные — прямой и обратный порядок вывода.

Прямой порядок вывода — от фактов, которые находятся в рабочем множестве, к

заключению. Если такое заключение удается найти, то оно заносится в рабочее

множество. Прямой вывод часто называют выводом, управляемым данными.

Для иллюстрации добавим к нашему примеру базы знаний о здоровье еще одно

правило (правило 2):

ЕСЛИ

«Риск высокий»

ТО

«Продолжительность жизни менее 60 лет».

Предположим также, что факты «Пациент курит» и «Кровяное давление выше

среднего» имеются в рабочем множестве, а целью системы является определение

наиболее вероятной продолжительности жизни пациента (пользователя).

При прямом выводе работа системы будет протекать следующим образом.

1. Рассматривается правило 1. Его условие истинно, так как оба элемента

конъюнкции имеются в рабочем множестве. Применяем правило 1. Добавляем к рабочему

множеству факт «Риск высокий».

2. Рассматривается правило 2. Его условие истинно, так как утверждение из

условия имеется в рабочем множестве. Применяем правило 2. Добавляем к рабочему

множеству факт «Продолжительность жизни менее 60 лет». Целевое утверждение

выведено.

При обратном порядке вывода заключения просматриваются до тех пор, пока не

будут обнаружены в рабочей памяти или получены от пользователя факты,

подтверждающие одно из них.

В системах с обратным выводом вначале выдвигается некоторая гипотеза, а затем

механизм вывода в процессе работы как бы возвращается назад, переходя от нее к фактам,

и пытается найти среди них те, которые подтверждают эту гипотезу. Если достоверность

доказана, то выбирается следующая гипотеза, детализирующая первую и являющаяся по

отношению к ней подцелью. Далее отыскиваются факты, подтверждающие истинность

подчиненной гипотезы. Вывод такого типа называется управляемым целями.

121

Обратный поиск применяется в тех случаях, когда цели известны и их

сравнительно немного.

Заметим, что для упрощения ситуации мы предположили, что в обоих случаях

факты «Пациент курит» и «Кровяное давление выше среднего» уже известны системе. На

самом деле система выясняет истинность или ложность факта, входящего в условие

некоторого правила, спрашивая об этом пользователя в тот момент, когда она пытается

применить правило.

Приведенный пример сознательно выбран простым и не отражающим многих

проблем, связанных с организацией вывода в экспертной системе. В частности, из

примера может создаться впечатление, что прямая цепочка рассуждений эффективнее,

чем обратная, что на самом деле не так. Эффективность той или иной стратегии вывода

зависит от характера задачи и содержимого базы знаний. В системах диагностики чаще

применяется прямой вывод, в то время как в планирующих системах более эффективным

оказывается обратный вывод. В некоторых системах вывод основывается на сочетании

обратного и ограниченно-прямого. Такой комбинированный метод получил название

циклического.


1. Что такое искусственный интеллект?

2. Перечислите основные направления в моделировании ИИ.

3. Разъясните понятия «данные» и «знания».

4. Что называется экспертной системой?

5. Назовите основные проблемы технологии экспертных систем.

6. Какие особенности имеют экспертные системы?

7. Назовите основные компоненты типичной экспертной системы.

8. Приведите примеры крупномасштабных экспертных систем.

9. В чем смысл экспертного анализа?

10. Перечислите типовые задачи, решаемые экспертными системами.

11. Чем характеризуются экспертные системы?

12. Назовите функции экспертных систем.

13. Как осуществляется передача знаний в экспертной системе?

14. Что представляет собой база знаний? Как осуществляется в ней представление

знаний?

15. Что такое подсистема вывода? Каковы ее функции?

16. Что называется целевым утверждением?

122

17. В чем отличие прямого порядка вывода от обратного?

Раздел 3. Жизненный цикл ИС.

Лекция 9. Стадии жизненного цикла информационных систем (ЖЦ ИС).

Понятие жизненного цикла является одним из базовых понятий методологии

проектирования информационных систем. Жизненный цикл информационной системы

представляет собой непрерывный процесс, начинающийся с момента принятия решения о

создании информационной системы и заканчивающийся в момент полного изъятия ее из

эксплуатации. Существует международный стандарт, регламентирующий жизненный

цикл информационных систем, — ISO/IEC 12207. ISO расшифровывается как International

Organization of Standardization (Международная организация по стандартизации), IEC —

как International Electrotechnical Commission (Международная комиссия по

электротехнике). Стандарт ISO/IEC 12207 определяет структуру жизненного цикла,

включая процессы, действия и задачи, которые должны быть выполнены во время

создания информационной системы.

Жизненный цикл ИС можно представить как ряд событий, происходящих с

системой в процессе ее создания и использования.

Разработка информационной системы, как правило, выполняется для

определенного предприятия. Особенности деятельности предприятия или предметной

области его функционирования, безусловно, влияют на состав информационной системы,

но в то же время структуры разных предприятий в целом похожи между собой.

Каждая организация независимо от рода ее деятельности состоит из ряда

подразделений, непосредственно осуществляющих тот или иной вид деятельности

компании. И эта ситуация справедлива практически для всех организаций, каким бы

видом деятельности они ни занимались. Любую организацию можно рассматривать как

совокупность взаимодействующих элементов (подразделений), каждый из которых может

иметь свою структуру. Взаимосвязи между подразделениями тоже достаточно сложны. В

общем случае можно выделить три вида связей между подразделениями предприятия:

— функциональные связи — каждое подразделение выполняет определенные виды

работ в рамках единого бизнес-процесса;

123

— информационные связи — подразделения обмениваются информацией

(документами, факсами, письменными и устными распоряжениями и т.п.);

— внешние связи — некоторые подразделения взаимодействуют с внешними

системами, причем их взаимодействие также может быть как информационным, так и

функциональным.

Информационная система предприятия разрабатывается как некоторый проект.

Многие особенности управления проектами и фазы разработки проекта (фазы жизненного

цикла) являются общими, не зависящими не только от предметной области, но и от

характера проекта. Каждый проект независимо от сложности и объема работ,

необходимых для его выполнения, проходит в своем развитии определенные состояния.

Совокупность ступеней развития от возникновения идеи до полного завершения проекта

принято разделять на стадии или этапы.

В определении количества стадий и их содержания имеются некоторые отличия,

поскольку эти характеристики во многом зависят от условий осуществления конкретного

проекта и опыта основных участников. Тем не менее логика и основное содержание

процесса разработки информационной системы почти во всех случаях являются общими.

Можно выделить следующие стадии развития информационной системы —

формирование требований (концепции), проектирование, реализация, тестирование, ввод

системы в эксплуатацию, эксплуатация (сопровождение проекта).

Завершается жизненный цикл информационной системы выводом ее из

эксплуатации.

Для каждого этапа определяют состав и последовательность выполняемых работ,

получаемые результаты, методы и средства, необходимые для выполнения работ, роли и

ответственность участников и т.д. Такое формальное описание жизненного цикла

информационной системы позволяет спланировать и организовать процесс коллективной

разработки и обеспечить управление этим процессом. Рассмотрим каждую из стадий

более подробно.

Стадия формирования требований к информационной системе является одной из

важнейших, поскольку определяет успех всего проекта. На начальной стадии

устанавливается область применения системы и определяются граничные условия. Для

этого необходимо идентифицировать все внешние объекты, с которыми должна

взаимодействовать разрабатываемая система, и определить характер этого

взаимодействия на высоком уровне, т.е. идентифицировать все функциональные

возможности системы и произвести описание наиболее существенных из них.

Данная стадия включает в себя следующие этапы:

124

1) планирование работ. Основными задачами этого этапа являются:

— определение целей разработки;

— предварительная экономическая оценка проекта;

— построение плана-графика выполнения работ;

2) проведение обследования деятельности автоматизируемого объекта, в рамках

которого осуществляются:

— предварительное определение требований к будущей системе;

— определение структуры организации;

— определение целевых функций организации;

— анализ распределения функций по подразделениям и сотрудникам;

— выявление функциональных взаимодействий между подразделениями;

— анализ информационных потоков внутри подразделений и между ними;

— анализ информации, поступающей из внешних источников;

— анализ существующих средств автоматизации деятельности организации;

3) построение моделей деятельности организации на основании результатов

обследования:

— модели «как есть» (as-is), отражающей существующее на момент обследования

положение дел в организации и позволяющей выявить узкие места в функционировании и

сформулировать предложения по улучшению ситуации (оптимизации бизнес-процессов);

— модели «как должно быть» (to-be), представляющей наиболее оптимальную

технологию работы предприятия.

Каждая из моделей представляет собой совокупность функциональной и

информационной моделей деятельности организации.

Необходимо определить способы перехода от модели «как есть» к модели «как

должно быть». Переход может быть осуществлен либо путем совершенствования

существующих бизнес-процессов и технологий их обработки на основе оценки их

эффективности, либо радикальным перепроектированием бизнес-процессов и технологий

их обработки (реинжиниринг бизнес-процессов).

Стадия проектирования, как правило, включает определение архитектуры системы,

ее функций, внешних условий функционирования, интерфейсы и распределение функций

между пользователями и системой, требования к программным и информационным

компонентам, состав исполнителей и сроки разработки. Проектирование осуществляется

на основе моделей «как должно быть».

Границы каждой стадии определены некоторыми моментами времени, в которые

необходимо принимать определенные критические решения и, следовательно, достигать

125

определенных ключевых целей. Содержание остальных этапов совпадает с

соответствующими процессами жизненного цикла и будет рассмотрено далее.

Лекция 10. Модели ЖЦ ИС.

Моделью жизненного цикла информационной системы будем называть некоторую

структуру, определяющую последовательность осуществления процессов, действий и

задач, выполняемых на протяжении жизненного цикла информационной системы, а также

взаимосвязи между этими процессами, действиями и задачами.

В стандарте ISO/IEC 12207 не конкретизируются детально методы выполнения

действий и решения задач, входящих в процессы жизненного цикла информационной

системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как

регламенты стандарта являются общими для любых моделей жизненного цикла,

методологий и технологий разработки. Модель же жизненного цикла зависит от

специфики информационной системы и условий, в которых она создается и

функционирует.

К настоящему времени наибольшее распространение получили две основные

модели жизненного цикла — каскадная модель, или модель водопада (waterfall), и

спиральная модель.

Каскадная модель предусматривает последовательное выполнение всех этапов

проекта в строго фиксированном порядке.

Переход на следующий этап означает полное завершение работ на предыдущем

этапе.

В спиральной модели на каждом витке спирали выполняется создание очередной

версии продукта, уточняются требования проекта, определяется его качество и

планируются работы следующего витка. Особое внимание уделяется начальным этапам

разработки — анализу и проектированию, где реализуемость тех или иных технических

решений проверяется и обосновывается посредством создания прототипов

(макетирования).

Каскадная модель жизненного цикла информационной системы.

Каскадная модель демонстрирует классический подход к разработке различных

систем в любых прикладных областях. Для разработки информационных систем данная

модель широко использовалась в 70-х и первой половине 80-х годов XX века. Каскадные

методы проектирования хорошо описаны в зарубежной и отечественной литературе

126

разных направлений: методических монографиях, стандартах, учебниках. Организация

работ по каскадной схеме официально рекомендовалась и широко применялась в

различных отраслях. Таким образом, наличие не только теоретических оснований, но и

промышленных методик и стандартов, а также использование этих методов в течение

десятилетий позволяет называть каскадные методы классическими.

Каскадная модель предусматривает последовательную организацию работ. При

этом основной особенностью является разбиение всей разработки на этапы, причем

переход с одного этапа на следующий происходит только после того, как полностью

завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного

комплекта документации, достаточной для того, чтобы разработка могла быть продолжена

другой командой разработчиков.

За десятилетия существования каскадной модели разбиение работ на стадии и

названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты

избегали жесткого и однозначного приписывания определенных работ к конкретным

этапам. Тем не менее все же можно выделить ряд устойчивых этапов разработки,

практически не зависящих от предметной области (рисунок 10.1).

На первом этапе проводится исследование проблемы, которая должна быть решена,

четко формулируются все требования заказчика.

Результатом, получаемым на данном этапе, является техническое задание

(разработка требований), согласованное со всеми заинтересованными сторонами.

Рисунок 10.1 – Каскадная модель жизненного цикла ИС

На втором этапе разрабатывают проектные решения, удовлетворяющие всем

требованиями, сформулированным в техническом задании. Результатом данного этапа

является комплект проектной документации, содержащей все необходимые данные для

реализации проекта.

127

Третий этап — реализация проекта. Здесь осуществляется разработка

программного обеспечения (кодирование) в соответствии с проектными решениями,

полученными на предыдущем этапе.

Методы, используемые для реализации, не имеют принципиального значения.

Результатом выполнения данного этапа является готовый программный продукт.

На четвертом этапе проводится проверка (тестирования) полученного

программного обеспечения на предмет соответствия требованиям, заявленным в

техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые

недостатки, проявляющиеся в реальных условиях работы информационной системы.

Последний этап — сдача готового проекта, ввод его в действие.

Главная задача этого этапа — документально подтвердить, что все требования

заказчика выполнены в полной мере.

Этапы работ в рамках каскадной модели часто также называют частями

«проектного цикла» системы. Такое название возникло потому, что этапы состоят из

многих итерационных процедур уточнения требований к системе и вариантов проектных

решений. Жизненный цикл самой системы существенно сложнее и длиннее. Он может

включать в себя произвольное число циклов уточнения, изменения и дополнения уже

принятых и реализованных проектных решений. В этих циклах происходят развитие

информационной системы и модернизация отдельных ее компонентов.

Достоинства каскадной модели. Каскадная модель имеет ряд положительных

сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного

рода инженерных разработок и получила широкое распространение. Рассмотрим ее

основные достоинства.

1. На каждом этапе формируется законченный набор проектной документации,

отвечающий критериям полноты и согласованности. На заключительных этапах также

разрабатывается пользовательская документация, охватывающая все предусмотренные

стандартами виды обеспечения информационной системы (организационное,

методическое, информационное, программное, аппаратное).

2. Выполняемые в логичной последовательности этапы работ позволяют

планировать сроки завершения и соответствующие затраты.

Каскадная модель изначально разрабатывалась для решения различного рода

инженерных задач и не потеряла своего значения для прикладной области до настоящего

времени. Кроме того, каскадный подход хорошо зарекомендовал себя при разработке

определенных информационных систем. Имеются в виду системы, для которых в самом

начале разработки можно достаточно точно и полно сформулировать все требования, с

128

тем чтобы предоставить разработчикам свободу выбора реализации, наилучшей с

технической точки зрения. К таким информационным системам, в частности, относятся

сложные расчетные системы, системы реального времени.

Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд

недостатков, ограничивающих ее применение при разработке информационных систем.

Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к

увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи

программных проектов объясняются именно последовательным процессом разработки.

Недостатки каскадной модели. Перечень недостатков каскадной модели при ее

использовании для разработки информационных систем достаточно обширен. Вначале

просто перечислим их, а затем рассмотрим основные из них более подробно:

— существенная задержка в получении результатов;

— ошибки и недоработки на любом из этапов проявляются, как правило, на

последующих этапах работ, что приводит к необходимости возврата назад;

— сложность параллельного ведения работ по проекту;

— чрезмерная информационная перенасыщенность каждого из этапов;

— сложность управления проектом;

— высокий уровень риска и ненадежность инвестиций.

Задержка в получении результатов обычно считается главным недостатком

каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие

последовательного подхода к разработке согласование результатов с заинтересованными

сторонами производится только после завершения очередного этапа работ.

Может оказаться, что разрабатываемая информационная система не соответствует

требованиям пользователей, причем такие несоответствия могут возникать на любом

этапе разработки — искажения могут непреднамеренно вноситься и проектировщиками-

аналитиками, и программистами, так как они могут недостаточно хорошо разбираться в

тех предметных областях, для которых разрабатывают информационную систему.

Кроме того, используемые при разработке информационной системы модели

автоматизируемого объекта, отвечающие критериям внутренней согласованности и

полноты, могут в силу различных причин устареть за время разработки (например, из-за

внесения изменений в законодательство, колебания курса валют и т.п.). Это относится и к

функциональной модели, и к информационной модели, и к проектам интерфейса

пользователя, и к пользовательской документации.

Возврат на более ранние стадии — недостаток каскадной модели, который является

одним из проявлений предыдущего недостатка.

129

Поэтапная и последовательная работа над проектом может быть следствием того,

что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на

последующих стадиях работы над проектом. Поэтому после того как ошибки проявятся,

проект возвращается на предыдущий этап, перерабатывается и снова передается на

следующую стадию. Это может служить причиной срыва графика работ и усложнения

взаимоотношений между группами разработчиков, выполняющих отдельные этапы

работы.

Самым же неприятным является то, что недоработки предыдущего этапа могут

обнаруживаться не сразу на последующем этапе, а позднее (например, на стадии опытной

эксплуатации могут проявиться ошибки в описании предметной области). Это означает,

что часть проекта должна быть возвращена на начальный этап работы. Вообще работа

может быть возвращена с любого этапа на любой предыдущий этап, поэтому в реальности

каскадная схема разработки выгладит так, как показано на рисунке 10.2.

Рисунок 10.2 – Поэтапная модель с промежуточным контролем

Одной из причин данной ситуации является то, что в качестве экспертов,

участвующих в описании предметной области, часто выступают будущие пользователи

системы, которые иногда не могут четко сформулировать то, что они хотели бы получить.

Кроме того, заказчики и исполнители часто неправильно понимают друг друга

вследствие того, что исполнители обычно не являются специалистами в предметной

области решаемой задачи, а заказчики далеки от программирования.

Сложность параллельного ведения работ является также одним из недостатков

каскадной модели. Отмеченные проблемы возникают вследствие того, что работа над

проектом строится в виде цепочки последовательных шагов. Причем даже в том случае,

когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при

использовании каскадной схемы распараллеливание работ весьма затруднительно.

Сложности параллельного ведения работ связаны с необходимостью постоянного

согласования различных частей проекта. Чем сильнее взаимозависимость отдельных

130

частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее

зависят друг от друга группы разработчиков. Поэтому преимущества параллельного

ведения работ просто теряются.

Отсутствие параллелизма негативно сказывается и на организации работы всего

коллектива разработчиков. Работа одних групп сдерживается другими. Пока производится

анализ предметной области, проектировщики, разработчики и те, кто занимается

тестированием и администрированием, почти не загружены. Кроме того, при

последовательной разработке крайне сложно внести изменения в проект после завершения

этапа и передачи проекта на следующую стадию. Например, если после передачи проекта

на следующий этап группа разработчиков нашла более эффективное решение, оно не

может быть использовано. Это связано с тем, что более раннее решение уже, возможно,

реализовано и связано с другими частями проекта. Поэтому исключается (или, по крайней

мере, существенно затрудняется) доработка проекта после его передачи на следующий

этап.

Вследствие сильной зависимости между различными группами разработчиков

возникает проблема информационной перенасыщенности. Данная проблема заключается в

том, что при внесении изменений в одну из частей проекта необходимо оповещать всех

разработчиков, которые использовали или могли бы использовать эту часть в своей

работе. Когда система состоит из большого количества взаимосвязанных подсистем, то

синхронизация внутренней документации становится важной самостоятельной задачей.

Разработчикам необходимо ознакомиться с изменениями и оценить, не сказались ли эти

изменения на уже полученных результатах. Все это может требовать проведения

повторного тестирования и даже внесения изменений в уже готовые части проекта.

Причем эти изменения, в свою очередь, должны быть отражены во внутренней

документации и переданы всем группам разработчиков. Как следствие, объем

документации по мере разработки проекта растет очень быстро, так что требуется все

больше времени для составления документации и ознакомления с ней.

Следует также отметить, что помимо изучения нового материала не отпадает

необходимость в анализе старой информации. Это связано с тем, что вполне вероятна

ситуация, когда в процессе разработки изменяется состав группы разработчиков (этот

процесс носит название ротации кадров). Новым разработчикам необходимы сведения о

том, что было сделано до них. Причем чем сложнее проект, тем больше времени

требуется, чтобы ввести нового разработчика в курс дела.

Сложность управления проектом при использовании каскадной схемы в основном

обусловлена строгой последовательностью стадий разработки и наличием сложных

131

взаимосвязей между различными частями проекта. Последовательность разработки

проекта приводит к тому, что одни группы разработчиков должны ожидать результатов

работы других команд. Поэтому для согласования сроков работы и состава передаваемой

документации требуется административное вмешательство. При обнаружении ошибок в

выполненной работе необходимо вернуться к предыдущим этапам выполнения проекта.

Это приводит к дополнительным сложностям в управлении проектом. Разработчики,

допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым

проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв

сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды

разработчиков ожидания окончания следующей стадии разработки нерационально, так

как приводит к существенным потерям рабочего времени.

Упростить взаимодействие между группами разработчиков и уменьшить

информационную перенасыщенность документации можно, сокращая количество связей

между отдельными частями проекта.

Очевидно, что при использовании каскадного подхода повышается уровень риска

проекта. Чем сложнее проект, тем больше продолжительность каждого из этапов

разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество

которых также увеличивается. Причем результаты разработки можно реально увидеть и

оценить лишь на этапе тестирования, т.е. после завершения анализа, проектирования и

разработки — этапов, выполнение которых требует значительного времени и средств. Как

уже было отмечено, запоздалая оценка порождает серьезные проблемы при выявлении

ошибок анализа и проектирования — требуется возврат проекта на предыдущие стадии и

повторение процесса разработки.

Возврат на предыдущие стадии может быть связан не только с ошибками, но и с

изменениями, произошедшими в предметной области или в требованиях заказчика за

время разработки. Причем возврат проекта на доработку вследствие этих причин не

гарантирует, что предметная область снова не изменится к тому моменту, когда будет

готова следующая версия проекта. Фактически это означает, что существует вероятность

того, что процесс разработки «зациклится», и система никогда не дойдет до сдачи в

эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового

продукта постоянно откладываться. Поэтому можно утверждать, что сложные проекты,

разрабатываемые по каскадной схеме, имеют повышенный уровень риска.

Помимо рассмотренных, существует еще один серьезный недостаток, присущий

каскадной модели разработки, на который также следует обратить внимание. Этот

недостаток связан с конфликтом (не всегда явным) между разработчиками,

132

участвующими в выполнении проекта. Конфликт обусловлен тем, что возврат части

проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А

так как однозначно персонифицировать ответственного за ошибки можно далеко не

всегда, попытки поиска виноватых могут сильно усложнить отношения в коллективе. Как

следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую

квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных,

обеспечить им более удобные условия работы и т.п. В результате появляется опасность

снижения и квалификации, и творческого потенциала всей команды. Соответственно,

техническое руководство проектом начинает в большей степени подменяться

организационным руководством, все более детальной проработкой должностных

инструкций и все более формальным их исполнением.

Каскадный подход хорошо зарекомендовал себя при построении относительно

простых информационных систем, когда в самом начале разработки можно достаточно

точно и полно сформулировать все требования к системе.

Спиральная модель жизненного цикла.

Спиральная модель ЖЦ была предложена для преодоления перечисленных

проблем каскадной модели. На этапах анализа и проектирования реализуемость

технических решений и степень удовлетворения потребностей заказчика проверяется

путем создания прототипов. Каждый виток спирали соответствует созданию

работоспособного фрагмента или версии системы. Это позволяет уточнить требования,

цели и характеристики проекта, определить качество разработки, спланировать работы

следующего витка спирали. Таким образом, углубляются и последовательно

конкретизируются детали проекта, и в результате выбирается обоснованный вариант,

который удовлетворяет действительным требованиям заказчика и доводится до

реализации.

Спиральная модель (рисунок 10.3) в отличие от каскадной предполагает

итерационный процесс разработки информационной системы. При этом возрастает

значение начальных этапов жизненного цикла, таких как анализ и проектирование. На

этих этапах проверяется и обосновывается реализуемость технических решений путем

создания прототипов. Каждая итерация представляет собой законченный цикл разработки,

приводящий к выпуску внутренней или внешней версии изделия (или подмножества

конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать

законченной системой. На каждом витке спирали уточняются цели и характеристики

проекта, определяется его качество, планируются работы на следующем витке. На каждой

итерации углубляются и последовательно конкретизируются детали проекта, в результате

133

чего выбирается обоснованный вариант, который доводится до окончательной

реализации.

Рисунок 10.3 – Спиральная модель жизненного цикла ИС

Использование спиральной модели позволяет перейти на следующий этап

выполнения проекта, не дожидаясь полного завершения текущего — недоделанную

работу можно будет выполнить на следующей итерации. Главная задача каждой итерации

— как можно быстрее создать работоспособный продукт, который можно показать

пользователям системы. Таким образом, существенно упрощается процесс внесения

уточнений и дополнений в проект.

Достоинства спиральной модели. Спиральный подход к разработке

программного обеспечения позволяет преодолеть большинство недостатков каскадной

модели и, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс

разработки более гибким. Рассмотрим преимущества итерационного подхода более

подробно.

1. Итерационная разработка существенно упрощает внесение изменений в проект

при изменении требований заказчика.

2. При использовании спиральной модели отдельные элементы информационной

системы интегрируются в единое целое постепенно.

При итерационном подходе интеграция производится фактически непрерывно.

Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо

меньше проблем при ее проведении (по некоторым оценкам, при использовании

каскадной модели разработки интеграция занимает до 40% всех затрат в конце проекта).

3. Уменьшение уровня рисков. Данное преимущество является следствием

предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому

уровень рисков максимален в начале разработки проекта. По мере продвижения

разработки ожидаемый уровень рисков снижается. Данное утверждение справедливо при

134

любой модели разработки, однако при использовании спиральной модели снижение

уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при

итерационном подходе интеграция выполняется уже на первой итерации, и на начальных

итерациях выявляются многие аспекты проекта, такие как пригодность используемых

инструментальных средств и программного обеспечения, квалификация разработчиков и

т.п. На рисунке 10.4 приведены в сравнении графики зависимости уровня рисков от

времени разработки для каскадного и итерационного подходов.

Рисунок 10.4 – Зависимость рисков от времени разработки

4. Итерационная разработка обеспечивает большую гибкость в управлении

проектом, давая возможность внесения тактических изменений в разрабатываемое

изделие. Например, можно сократить сроки разработки за счет снижения

функциональности системы или использовать в качестве составных частей системы

продукцию сторонних фирм вместо собственных разработок. Это может быть актуальным

в условиях конкурентной борьбы, когда необходимо противостоять продвижению

изделия, предлагаемого конкурентами.

5. Итерационный подход упрощает повторное использование компонентов

(реализует компонентный подход к программированию). Это обусловлено тем, что

гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично

разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после

проведения нескольких начальных итераций позволяет выявить общие многократно

используемые компоненты, которые на последующих итерациях будут

совершенствоваться.

6. Спиральная модель позволяет получить более надежную и устойчивую систему.

Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются

и исправляются на каждой итерации. Одновременно могут корректироваться критические

параметры эффективности, что в случае каскадной модели доступно только перед

внедрением системы.

135

7. Итерационный подход дает возможность совершенствовать процесс разработки

— анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что

должно быть изменено в организации разработки, и улучшить ее на следующей итерации.

Недостатки спиральной модели. Основная проблема спирального цикла —

определение момента перехода на следующий этап. Для ее решения необходимо ввести

временные ограничения на каждый из этапов жизненного цикла. Иначе процесс

разработки может превратиться в бесконечное совершенствование уже сделанного. При

итерационном подходе полезно следовать принципу «лучшее — враг хорошего». Поэтому

завершение итерации необходимо проводить строго в соответствии с планом, даже если

не вся запланированная работа закончена. Планирование работ обычно проводится на

основе статистических данных, полученных в предыдущих проектах, и личного опыта

разработчиков.

Лекция 11. Процессы ЖЦ ИС.

Международный стандарт ISO/IES 12207 определяет действия, которые могут быть

выполнены на протяжении жизненного цикла программного обеспечения. Каждый

процесс разделен на набор действий, каждое действие — на набор задач.

Согласно стандарту структура жизненного цикла основывается на трех группах

процессов:

1) основные процессы жизненного цикла (приобретение, поставка, разработка,

эксплуатация, сопровождение);

2) вспомогательные процессы, обеспечивающие выполнение основных процессов

(документирование, управление конфигурацией, обеспечение качества, верификация,

аттестация, оценка, аудит, разрешение проблем);

3) организационные процессы (управление проектами, создание инфраструктуры

проекта, усовершенствование, обучение).

Рассмотрим каждую из указанных групп более подробно.

Основные процессы жизненного цикла.

Выделяют пять основных процессов жизненного цикла программного обеспечения.

Каждый процесс характеризуется определенными задачами и методами их решения,

исходными данными и результатами. Под основным участником процесса понимается

сторона, которая инициирует или выполняет разработку, эксплуатацию или

сопровождение программного изделия. Это покупатель, поставщик, разработчик,

персонал эксплуатации и персонал сопровождения программных изделий.

136

Процесс приобретения определяет действия предприятия-покупателя, которое

приобретает информационную систему.

Процесс поставки определяет действия предприятия-поставщика, снабжающего

покупателя информационной системой.

Процесс разработки определяет действия предприятия-разработчика, включает в

себя стратегическое планирование, анализ, проектирование и реализацию

(программирование), т.е. все работы по созданию информационного программного

обеспечения и его компонентов в соответствии с заданными требованиями.

Включает также оформление проектной и эксплуатационной документации,

подготовку материалов, необходимых для тестирования разработанных программных

продуктов и для обучения персонала. Разработка является одним из важнейших процессов

жизненного цикла информационной системы.

Процесс эксплуатации определяет действия персонала, обеспечивающие

обслуживание информационной системы в процессе ее функционирования в интересах

пользователей. Основные эксплуатационные работы включают непосредственно

эксплуатацию, локализацию проблем и устранение причин их возникновения,

модификацию программного обеспечения, подготовку предложений по

совершенствованию системы, развитие и модернизацию системы. В процесс эксплуатации

входят также конфигурирование базы данных и рабочих мест пользователей, обеспечение

пользователей эксплуатационной документацией, обучение персонала.

Процесс сопровождения определяет действия персонала, обеспечивающие

сопровождение программного продукта, что представляет собой управление

модификациями программного продукта, поддержку его текущего состояния и

функциональной пригодности и включает в себя инсталляцию и удаление программного

обеспечения системы. Сопровождение — процесс выпуска и внедрения новых версий

программного обеспечения информационной системы. Причинами выпуска новых версий

могут быть:

— необходимость исправления ошибок, выявленных в процессе эксплуатации

предыдущих версий;

— необходимость совершенствования предыдущих версий, например, улучшения

интерфейса или расширения состава выполняемых функций;

— изменение среды функционирования, например, появление новых технических

средств и/или программных продуктов.

В процессе сопровождения в программное обеспечение вносят необходимые

изменения, которые могут потребовать пересмотра проектных решений, принятых на

137

любом этапе жизненного цикла. В спиральной модели жизненного цикла

информационной системы роль этапа сопровождения существенно возросла, так как

продукты теперь создаются итерационно: сначала выпускается сравнительно простая

версия, затем следующая с большими возможностями, затем следующая и т.д. Именно это

и послужило причиной выделения этапа сопровождения в отдельный процесс жизненного

цикла в соответствии со стандартом ISO/IES 12207.

В жизни любой корпоративной информационной системы весьма заметную роль

играют службы технической поддержки.

Наличие квалифицированного технического обслуживания на этапе эксплуатации

информационной системы является необходимым условием решения поставленных перед

ней задач, причем ошибки обслуживающего персонала могут приводить к явным или

скрытым финансовым потерям, сопоставимым со стоимостью самой информационной

системы. Основными предварительными действиями при подготовке к организации

технического обслуживания информационной системы являются:

— выделение наиболее ответственных узлов системы и определение для них

критичности простоя (это позволит выделить наиболее критичные составляющие

информационной системы и оптимизировать распределение ресурсов для технического

обслуживания);

— определение задач технического обслуживания и их разделение на внутренние

задачи, решаемые силами обслуживающего подразделения, и внешние задачи, решаемые

специализированными сервисными организациями (таким образом производится четкое

определение круга исполняемых функций и разделение ответственности);

— проведение анализа имеющихся внутренних и внешних ресурсов, необходимых

для организации технического обслуживания в рамках описанных задач и разделения

компетенции (основные критерии для анализа: наличие гарантии на оборудование,

состояние ремонтного фонда, квалификация персонала);

— подготовка плана организации технического обслуживания, в котором

необходимо определить этапы исполняемых действий, сроки их исполнения, затраты на

этапах, ответственность исполнителей.

Обеспечение качественного технического обслуживания информационной системы

требует привлечения специалистов высокой квалификации, которые в состоянии решать

не только каждодневные задачи администрирования, но и быстро восстанавливать

работоспособность системы при сбоях.

Вспомогательные процессы жизненного цикла.

138

Вспомогательные процессы поддерживают реализацию основных процессов,

будучи неотъемлемой частью всего жизненного цикла информационной системы, с

определенной целью и обеспечивают должное качество информационной системы.

Вспомогательные процессы используются и выполняются по мере необходимости и

инициируются другими процессами.

Процесс документирования определяет действия для записи информации,

являющейся результатом выполнения какого-либо процесса жизненного цикла


Процесс управления конфигурацией определяет действия по управлению

конфигурацией. Это тот вспомогательный процесс, который поддерживает основные

процессы жизненного цикла информационной системы, прежде всего процессы

разработки и сопровождения. При разработке проектов сложных информационных

систем, состоящих из многих компонентов, каждый из которых может разрабатываться

независимо и, следовательно, иметь несколько вариантов реализации и/или несколько

версий одной реализации, возникает проблема учета их связей и функций, создания

единой структуры и обеспечения развития всей системы.

Управление конфигурацией позволяет организовывать, систематически учитывать

и контролировать внесение изменений в различные компоненты информационной

системы на всех стадиях ее жизненного цикла.

Процесс обеспечения качества определяет действия для объективной гарантии,

что информационная система и процессы соответствуют определенным требованиям к

ним и придерживаются установленным замыслам. Совместная оценка, верификация,

проверки, аттестации могут быть использованы как способы гарантии качества.

Процесс верификации определяет действия (для покупателя, поставщика или

независимой стороны) для верификации программного обеспечения информационной

системы с различной глубиной зависимости от проекта.

Процесс аттестации определяет действия (покупателя, поставщика, независимой

стороны) для аттестации программного обеспечения информационной системы.

Процесс совместной оценки определяет действия для оценки состояния и

результатов какого-либо действия. Этот процесс может быть использован любыми двумя

сторонами, где одна сторона (проверяющая, рецензирующая) проверяет (рецензирует)

другую сторону (проверяемую) на совместном форуме.

Процесс проверки определяет деятельность для определения соответствия с

требованиями, замыслами и контрактом. Этот процесс может быть использован любыми

139

двумя сторонами, где одна сторона (проверяющая) проверяет программное обеспечение

информационной системы или деятельность другой стороны (проверяемой).

Процесс решения проблем определяет процесс анализа и устранения проблем

(включая несоответствия), какова бы ни была их природа или источник во время

разработки, эксплуатации, сопровождения или других процессов.

Организационные процессы.

Организационные процессы жизненного цикла выполняются какой-либо

организацией с целью:

— создания и обеспечения деятельности нижестоящей структуры, включающей в

себя связанные процессы жизненного цикла и персонал;

— совершенствования структуры и процессов.

Они, как правило, инвариантны относительно конкретных проектов и контрактов,

однако уроки, извлеченные из таких проектов и контрактов, способствуют

совершенствованию организации.

Управление проектом связано с вопросами планирования и организации работ,

создания коллективов разработчиков и контроля за сроками и качеством выполняемых

работ. Техническое и организационное обеспечение проекта включает в себя:

— выбор методов и инструментальных средств для реализации проекта;

— определение методов описания промежуточных состояний разработки;

— разработку методов и средств испытаний созданного программного

обеспечения;

— обучение персонала.

Обеспечение качества проекта связано с проблемами верификации, проверки и

тестирования компонентов информационной системы. Верификация — это процесс

определения соответствия текущего состояния разработки, достигнутого на данном этапе,

требованиям этого этапа. Проверка — это процесс определения соответствия параметров

разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое

проводится для определения различий между действительными и ожидавшимися

результатами и оценки соответствия характеристик информационной системы исходным

требованиям.

Процесс создания инфраструктуры управления охватывает выбор и поддержку

(сопровождение) технологии, стандартов и инструментальных средств, выбор и установку

аппаратных и программных средств, используемых для разработки, эксплуатации или

сопровождения программного обеспечения ИС. Инфраструктура, в свою очередь,

является одним из объектов управления конфигурацией.

140

Процесс усовершенствования предусматривает оценку, измерение, контроль и

модернизацию процессов жизненного цикла. Последнее направлено на повышение

производительности труда всех участвующих в них специалистов за счет

совершенствования используемой технологии, методов управления, выбора

инструментальных средств и обучения персонала. Усовершенствование основано на

анализе достоинств и недостатков каждого процесса.

Процесс обучения охватывает первоначальное обучение и последующее

постоянное повышение квалификации персонала.


1. Что такое жизненный цикл, из каких стадий он состоит?

2. Чем регламентируется жизненный цикл информационных систем?

3. Какие группы процессов входят в состав жизненного цикла, какие процессы

входят в состав каждой группы?

4. Какие из процессов наиболее часто используются в реальных проектах, какие в

меньшей степени и почему?

5. Что понимают под стадией жизненного цикла?

6. Какие этапы входят в состав жизненного цикла информационных систем?

7. Каковы принципиальные особенности каскадной модели?

8. В чем состоят преимущества и недостатки каскадной модели?

9. Каковы принципиальные особенности спиральной модели?

10. В чем состоят преимущества и недостатки спиральной модели?

141

Раздел 4. Моделирование ИС.

Лекция 12. Понятие модели предметной области.

Под моделью предметной области понимается некоторая система, имитирующая

структуру или функционирование исследуемой предметной области и отвечающая

основному требованию — быть адекватной этой области. Модель должна отражать все

аспекты функционирования предприятия и быть необходимой на всех этапах жизненного

цикла информационной системы. Но особую роль модели предметной области играют на

стадии формирования требований к будущей информационной системе при ее создании.

Предварительное моделирование предметной области позволяет сократить время и

сроки проведения проектировочных работ и получить более эффективный и качественный

проект. Без проведения моделирования предметной области велика вероятность

допущения большого количества ошибок в решении стратегических вопросов,

приводящих к экономическим потерям и высоким затратам на последующее

перепроектирование системы.

К модели предметной области предъявляются следующие требования:

— формализация, обеспечивающая однозначное описание структуры предметной

области;

— понятность для заказчиков и разработчиков на основе применения графических

средств отображения модели;

— реализуемость, подразумевающая наличие средств физической реализации

модели предметной области в ИС;

— обеспечение возможности оценки эффективности реализации модели

предметной области на основе определенных методов и вычисляемых показателей.

Для реализации перечисленных требований необходимо построение системы

моделей:

— объектной модели, отражающей состав взаимодействующих в процессах

материальных и информационных объектов предметной области;

142

— функциональной модели, отражающей взаимосвязь функций (действий) по

преобразованию объектов в процессах;

— модели управления, отражающей события и бизнес-правила, воздействующие на

выполнение процессов;

— организационной модели (структуры), отражающей взаимодействие

организационных единиц предприятия и персонала в процессах;

— технической модели, описывающей топологию расположения и способы

коммуникации комплекса технических средств.

Главный критерий адекватности модели предметной области заключается в

функциональной полноте разрабатываемой ИС.

С моделированием непосредственно связана проблема выбора языка представления

проектных решений. Язык моделирования — это графическая нотация, которая

используется для описания проектов. Нотация представляет собой совокупность

графических объектов, используемых в модели, и является синтаксисом языка

моделирования. Язык моделирования, с одной стороны, должен делать решения

проектировщиков понятными пользователю, с другой стороны, предоставлять

проектировщикам средства достаточно формализованного и однозначного определения

проектных решений, подлежащих реализации в виде программных комплексов,

образующих целостную систему.

Обычно модели строятся на трех уровнях — внешнем (определение требований),

концептуальном (спецификация требований), внутреннем (реализация требований).

Так, на внешнем уровне модель отвечает на вопрос «Что должна делать система?»,

т. е. определяется состав основных компонентов системы: объектов, функций, событий,

организационных единиц, технических средств. На концептуальном уровне модель

отвечает на вопрос «Как должна функционировать система?». Иначе говоря, определяется

характер взаимодействия компонентов системы. На внутреннем уровне модель отвечает

на вопрос: «С помощью каких программно-технических средств реализуются требования

к системе?». С позиции жизненного цикла ИС описанные уровни моделей соответственно

строятся на этапах анализа требований, технического и рабочего проектирования.

При работе с большими и сложными информационными системами проблема

сложности является главной проблемой. Ни один разработчик не в состоянии понять всю

систему в целом, поскольку это выше человеческих возможностей. Единственный

эффективный подход к решению этой проблемы заключается в построении сложной

системы из небольшого количества крупных частей, каждая из которых, в свою очередь,

143

строится из частей меньшего размера. Процесс продолжается до тех пор, пока самые

небольшие части станут доступны для восприятия и понимания.

Это означает, что сложную программную систему нужно разделять

(декомпозировать) на небольшие подсистемы и рассматривать их независимо друг от

друга.

Лекция 13. Структурный подход к моделированию предметной области, его

сущность.

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции

(разбиении) на автоматизируемые функции: система разбивается на функциональные

подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи,

и т.д. Процесс разбиения продолжается вплоть до конкретных процедур. При этом

автоматизируемая система сохраняет целостное представление, в котором все

составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх» от

отдельных задач ко всей системе целостность теряется, возникают проблемы при

информационной стыковке отдельных компонентов.

Структура проектируемой системы должна быть таковой, чтобы все

взаимодействие между ее подсистемами укладывалось в ограниченные стандартные

рамки:

— каждая подсистема должна инкапсулировать свое содержимое (скрывать его от

других подсистем);

— каждая подсистема должна иметь четкий интерфейс с другими подсистемами.

Инкапсуляция дает возможность рассматривать структуру каждой подсистемы

независимо от других подсистем. Интерфейсы позволяют строить систему более высокого

уровня, рассматривая каждую подсистему как единое целое.

Все наиболее распространенные методологии структурного подхода базируются на

следующих принципах:

— принцип «разделяй и властвуй» — решение сложных проблем путем их

разбиения на множество меньших независимых задач, легких для понимания и решения;

144

— принцип иерархического упорядочивания — организация составных частей

проблемы в иерархические древовидные структуры с добавлением новых деталей на

каждом уровне.

В структурном анализе используют группы средств, иллюстрирующих функции,

выполняемые системой, и отношения между данными. Каждой группе средств

соответствуют определенные виды моделей (диаграмм), наиболее распространенными

среди которых являются следующие:

— SADT (Structured Analisis and Design Technique — метод структурного анализа и

проектирования) — модели и соответствующие диаграммы;

— DFD (Data Flow Diagrams) — диаграммы потоков данных;

— ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» (модель

данных).

Перечисленные модели в совокупности дают полное описание ИС независимо от

того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в

каждом конкретном случае зависит от необходимой полноты описания системы.

Лекция 14. Методология функционального моделирования SADT.

Методология SADT является методологией функционального моделирования

бизнес-процессов. Метод SADT поддерживается Министерством обороны США, которое

было инициатором разработки стандарта IDEF01. Метод SADT представляет собой

совокупность правил и процедур, предназначенных для построения функциональной

модели объекта какой-либо предметной области.

IDEF0 — методология функционального моделирования (представление бизнес-

системы в виде взаимосвязанных функций). Фактически это целое семейство методологий

от IDEF0 до IDEF14.

Функциональная модель отображает функциональную структуру объекта, т.е.

производимые им действия и связи между этими действиями. Результатом применения

методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и

глоссария, имеющих ссылки друг на друга.

Методология SADT может использоваться:

— для моделирования широкого круга систем и определения требований и

функций;

— для разработки системы, которая удовлетворяет этим требованиям и реализует

эти функции.

145

SADT может быть использована в существующих системах:

— для анализа функций, выполняемых системой;

— для указания механизмов, посредством которых они осуществляются.

Диаграммы — главные компоненты модели. Функции системы и интерфейсы

представлены на диаграммах как блоки и дуги.

Место соединения дуги с блоком определяет тип интерфейса.

Управляющая информация входит в блок сверху, в то время как информация,

которая подвергается обработке, показана с левой стороны блока, а результаты выхода

показаны с правой стороны.

Механизм (человек или автоматизированная система), который осуществляет

операцию, представлен дугой, входящей в блок снизу (рисунок 14.1).

Рисунок 14.1 – Функциональный блок и интерфейсные дуги

Одна из наиболее важных особенностей методологии SADT — постепенное

введение все больших уровней детализации по мере создания диаграмм, отображающих

модель.

Построение SADT-модели начинается с изображения всей системы в вице

простейшей компоненты — одного блока и дуг, обозначающих интерфейсы с функциями

вне системы. Поскольку единственный блок характеризует всю систему как единое целое,

имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг — они также

представляют полный набор внешних интерфейсов системы в целом.

Затем блок, который характеризует систему как единый модуль, детализируется на

другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами.

Эти блоки отражают основные подфункции исходной функции. Данная декомпозиция

выявляет полный набор подфункций, каждая из которых дана как блок, границы которого

определены интерфейсными дугами.

Каждая из этих подфункций может быть декомпозирована подобным образом для

более детального изображения. Во всех случаях каждая подфункция может содержать

146

только те элементы, которые входят в исходную функцию. Кроме того, модель не может

опустить какие-либо элементы, т.е. как уже отмечалось, родительский блок и его

интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может

быть ничего удалено.

Модель SADT представляет собой серию диаграмм с сопроводительной

документацией, разбивающих сложный объект на составные части в виде блоков. Детали

каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая

детальная диаграмма является декомпозицией блока из более общей диаграммы. На

каждом шаге декомпозиции более общая диаграмма называется родительской для более

детальной диаграммы.

Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня,

являются теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и

выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть

системы.

Стрелки, приходящие с родительской диаграммы или уходящие на нее, нумеруют,

используя символы и числа. Символ обозначает тип связи: I — входные, С —

управляющие, М — механизмы, R — результаты. Число — номер связи по

соответствующей стороне родительского блока, считая сверху вниз и слева направо.

Все диаграммы связывают друг с другом иерархической нумерацией блоков:

первый уровень — А0, следующий — A1, А2,..., A11, А12, А13 и т.д., где «А1» — номер

родительского блока, а «1» — номер конкретного субблока родительского блока.

Детализацию завершают при получении функций, назначение которых хорошо понятно

как заказчику, так и разработчику. Эти функции описывают, используя естественный язык

или псевдокоды. В процессе построения иерархии диаграмм фиксируют всю уточняющую

информацию и строят словарь данных, в котором определяют структуры и элементы

данных, показанных на диаграммах. Таким образом, в результате получают

спецификацию, которая состоит из иерархии функциональных диаграмм, описаний

функций нижнего уровня и словаря, имеющих ссылки друг на друга.

На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные

связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции

могут быть изображены также с помощью дуг. Обратные связи могут выступать в виде

комментариев, замечаний, исправлений и т.д.

Приведем пример построения функциональной диаграммы для информационной

системы приема и зачисления студентов. Диаграмма, показанная на рисунке 14.2, является

147

диаграммой верхнего уровня. На ней хорошо видно, что является исходными данными

для системы, и получения каких результатов мы ожидаем.

Рисунок 14.2 – Функциональная диаграмма начального уровня

На функциональной диаграмме нулевого уровня (рисунок 14.3) родительский блок

АО разбивается на функциональные блоки Al, А2, А3, А4.

Рисунок 14.3 – Функциональная диаграмма нулевого уровня (более подробный вариант)

В свою очередь блок А1 может быть представлен на функциональной диаграмме

первого уровня как четыре дочерних блока A11, А12, А13, А14 (рисунок 14.4).

148

Рисунок 14.4 – Функциональная диаграмма первого уровня —

«Прием и оформление документов»

Лекция 15. Диаграммы потоков данных DFD.

Диаграмма потоков данных (DFD) состоит из узлов обработки данных, средств

хранения данных и внешних по отношению к используемой диаграмме источников или

потребителей данных.

Диаграмма потоков данных является основным средством моделирования

функциональных требований к системе — проектируемой или реально существующей. В

основе модели лежат понятия внешней сущности, процесса, хранилища (накопителя

данных) потока данных. Источники информации (внешние сущности) порождают

информационные потоки (потоки данных), переносящие информацию к подсистемам или

процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки,

которые переносят информацию к другим процессам или подсистемам, накопителям

данных или внешним сущностям — потребителям информации.

Для изображения диаграмм потоков данных традиционно используют два вида

нотаций: нотацию Йордана и нотацию Гейна-Сарсона:

149

Внешняя сущность — это материальный предмет или физическое лицо,

представляющее собой источник или приемник информации, — заказчики, персонал,

поставщики, клиенты, склад.

Определение некоторого объекта или системы в качестве внешней сущности

указывает на то, что она находится за пределами границ анализируемой информационной

системы. В процессе анализа некоторые внешние сущности могут быть перенесены

внутрь, если это необходимо, или, наоборот, часть процессов информационной системы

может быть вынесена за пределы диаграммы и представлена как внешняя сущность.

При построении модели сложной информационной системы она может быть

представлена в самом общем виде на так называемой контекстной диаграмме как одна

система, т.е. единое целое, либо может быть декомпозирована на ряд подсистем.

Номер подсистемы служит для ее идентификации. В поле имени вводится

наименование подсистемы в виде предложения с подлежащим и соответствующими

определениями и дополнениями.

Процесс представляет собой преобразование входных потоков данных в выходные

в соответствии с определенным алгоритмом.

Физически процесс может быть реализован различными способами: это может

быть подразделение организации (отдел), выполняющее обработку входных документов и

формирование отчетов, программа, аппаратно реализованное логическое устройство и т.д.

150

Номер процесса служит для его идентификации. В поле имени вводится наименование

процесса, при этом использование таких глаголов, как «обработать», «модернизировать»

или «отредактировать», означает, как правило, недостаточно глубокое понимание данного

процесса и требует дальнейшего анализа. Информация в поле физической реализации

показывает, какое подразделение организации, программа или аппаратное устройство

выполняет данный процесс.

Накопитель данных представляет собой абстрактное устройство для хранения

информации, которую можно в любой момент поместить в накопитель и через некоторое

время извлечь, причем способы помещения и извлечения могут быть любыми.

Накопитель данных может быть реализован физически в виде ящика в картотеке, таблицы

в оперативной памяти, файла на магнитном носителе и т.д.

Накопитель данных в общем случае является прообразом базы данных, и описание

хранящихся в нем данных должно быть увязано с информационной моделью.

Поток данных определяет информацию, передаваемую через некоторое

соединение от источника к приемнику. Реальный поток данных может быть информацией,

передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами,

магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.

Каждый поток данных имеет имя, отражающее его содержание.

Построение иерархии диаграмм потоков данных начинают с контекстной

диаграммы, которая определяет общий вид системы.

На такой диаграмме описывают интерфейс системы с внешним миром, т.е.

показывают, как разрабатываемая система будет взаимодействовать с потребителями и

источниками информации.

Обычно начальная контекстная диаграмма имеет форму звезды.

Если система содержит большое число внешних сущностей (более 10), имеет

распределенную природу или включает уже существующие подсистемы, то строят

иерархии контекстных диаграмм.

В процессе детализации соблюдают правило балансировки — при детализации

подсистемы могут использоваться компоненты только тех подсистем, с которыми у

анализируемой подсистемы существует информационная связь (т.е. с которыми она

связана потоками данных). На недетализируемые процессы составляют спецификации,

которые должны содержать текстовое описание функций данного процесса.

Приведем пример построения диаграммы потоков данных автоматизированной

информационной системы (АИС) «Склад оптовой торговли». АИС «Склад оптовой

151

торговли» предназначена для получения данных о движении и наличии товаров,

приобретенных для оптовой продажи.

Построение иерархии диаграмм потоков данных начнем с контекстной диаграммы,

т.е. определим, как разрабатываемая система будет взаимодействовать с приемниками и

источниками информации (рисунок 15.1).

Рисунок 15.1 – Начальная контекстная диаграмма (диаграмма нулевого уровня) в нотации

Йордана для АИС «Склад оптовой торговли»

Первичные документы по приходу товаров (приходные документы) фиксируются в

журнале поступления товаров. Оформление и учет реализации товаров зависят от способа

расчета за приобретаемые товары между покупателем и продавцом. Менеджер склада

ведет журнал учета закупок и отпуска товаров. Данные первичных документов

сохраняются в соответствующих накопителях.

Внешними сущностями для разрабатываемой системы являются поставщики,

покупатели, менеджер склада, отдел учета и контроля, отдел приема и оформления

заказов. Сведения о них сохраняются в соответствующих таблицах (справочниках).

Поставщик передает товар на склад. Документы на поставку товара (накладные, счета-

фактуры) вводят в базу данных. Покупатель подает заказ на приобретение товаров. В

отделе приема и оформления заказов проверяется каждая строка поступившего заказа.

При отсутствии на складе какой-либо позиции оформляется заявка поставщику, т.е.

инициируется поставка необходимого товара. На основании заказа заполняются

документы на реализацию товара, которые сохраняются в базе данных, распечатываются

и выдаются покупателю. В конце каждого дня все приходные документы передаются

152

бухгалтеру. На основании сведений о приходе и реализации товара менеджеры склада и

работники отдела учета формируют отчеты по оборотам и остаткам товара на складе.

Диаграмма потоков данных АИС «Склад оптовой торговли» представлена на

рисунке 15.2.

Рисунок 15.2 – Диаграмма потоков данных АИС «Склад оптовой торговли»

Лекция 16. Диаграмма «сущность-связь».

Цель любой информационной системы — обработка данных об объектах реального

мира в какой-либо предметной области.

Создавая базу данных для информационной системы, пользователь стремится

упорядочить информацию по различным признакам, для того чтобы по необходимости

извлекать нужную совокупность данных, получать выборку с желаемым сочетанием

признаков. Сделать это возможно, только если данные структурированы, т.е. отвечают

соглашениям о способах представления данных.

Диаграмма «сущность-связь» (ER-модель данных, ER — Entity-Relationship)

обеспечивает стандартный способ определения данных и отношений между ними в

информационной системе. Она включает сущности и взаимосвязи, отражающие основные

153

бизнес-правила предметной области. Диаграммы «сущность-связь» в отличие от

функциональных диаграмм определяют спецификации структур данных. Первый вариант

модели «сущность-связь» был предложен Питером Ченом. В дальнейшем многими

авторами были разработаны свои варианты подобных моделей. Все варианты диаграмм

«сущность-связь» исходят из одной идеи — графическое изображение нагляднее

текстового описания. Все такие диаграммы используют графическое изображение

сущностей предметной области, их свойств (атрибутов) и взаимосвязей между

сущностями.

Сущность — это класс однотипных объектов, информация о которых имеет

существенное значение для рассматриваемой предметной области. Сущность

представляет собой множество экземпляров реальных или абстрактных объектов (людей,

событий, состояний, предметов и т.п.).

Каждая сущность должна иметь уникальное имя, обладать одним или несколькими

атрибутами, которые либо принадлежат сущности, либо наследуются через связь,

обладать одним или несколькими атрибутами, которые однозначно идентифицируют

каждый экземпляр сущности.

Имя сущности должно отражать тип или класс объекта (студент), а экземпляр

сущности — это конкретный представитель данной сущности (Иванов).

На диаграмме в нотации Баркера, наиболее распространенной, сущность

изображается прямоугольником, иногда с закругленными углами (рисунок 16.1, а).

Рисунок 16.1 – Обозначения сущности в нотации Баркера:

а — без атрибутов; б — с указанием атрибутов; в — с уточнением атрибутов и

их типов: # — ключевой; * — обязательный; о — необязательный

Атрибут — любая характеристика сущности, значимая для рассматриваемой

предметной области и предназначенная для квалификации, идентификации,

классификации, количественной характеристики или выражения состояния сущности

(рисунок 16.1, б).

Атрибут, таким образом, представляет собой некоторый тип характеристик или

свойств, ассоциированных с множеством реальных или абстрактных объектов. Экземпляр

154

атрибута — определенная характеристика конкретного экземпляра сущности, значение

атрибута (например, «цвет» — это атрибут, а «зеленый» — экземпляр атрибута).

Атрибуты делятся на ключевые, т. е. входящие в состав уникального

идентификатора, который называют первичным ключом, и описательные — прочие.

Первичный ключ — это атрибут или совокупность атрибутов и/или связей,

предназначенная для уникальной идентификации каждого экземпляра сущности

(совокупность признаков, позволяющих идентифицировать объект). Ключевые атрибуты

помещают в начало списка и помечают символом «#» (рисунок 16.1, в). Описательные

атрибуты могут быть обязательными или необязательными. Обязательные атрибуты для

каждой сущности всегда имеют конкретное значение, необязательные — могут быть не

определены. Обязательные и необязательные описательные атрибуты помечают

символами «*» и «о» соответственно.

Связь — это отношение одной сущности к другой или к самой себе. Если любой

экземпляр одной сущности связан хотя бы с одним экземпляром другой сущности, то

связь является обязательной (рисунок 16.2, а). Необязательная связь представляет собой

условное отношение между сущностями (рисунок 16.2, б).

Рисунок 16.2 – Модальность связи:

а — обязательная; б — необязательная (пунктир до середины линии)

Связь может иметь разную модальность с разных концов. Каждая связь может быть

прочитана как слева направо, так и справа налево.

Каждая сущность может обладать любым количеством связей с другими

сущностями модели. Различают три типа отношений:

— 1*1 — «один-к-одному»;

— 1*n — «один-ко-многим»;

— n*m — «многие-ко-многим» (рисунок 16.3).

155

Рис. 16.3 – Обозначение отношений в нотации Баркера:

а — «один-к-одному»; б — «один-ко-многим»; в — «многие-ко-многим»

Связь типа «один-к-одному» означает, что один экземпляр первой сущности связан

только с одним экземпляром второй сущности. Такая связь, скорее всего, свидетельствует

о том, что была неверно разделена одна сущность на две (хотя иногда к такому типу связи

прибегают в случае, если есть необходимость «засекретить » часть данных). Связь типа

«один-ко-многим» означает, что каждый экземпляр первой сущности связан с

несколькими экземплярами второй сущности. Связь типа «многие-ко-многим» означает,

что каждый экземпляр первой сущности может быть связан с несколькими экземплярами

второй сущности и наоборот. Такой тип связи является временным типом связи,

допустимым на ранних этапах разработки модели. В дальнейшем такую связь необходимо

заменить двумя связями типа «один-ко-многим» путем выделения еще одной

дополнительной сущности.

Независимая сущность представляет независимые данные, которые всегда

присутствуют в системе. Они могут быть как связаны с другими сущностями, так и не

связаны.

Зависимая сущность представляет данные, зависящие от других сущностей

системы, поэтому она всегда должна быть связана с другими сущностями.

Ассоциированная сущность представляет данные, которые ассоциируются с

отношениями между двумя и более сущностями.

Обычно данный вид сущностей появляется в модели для разрешения отношения

«многие-ко-многим» (рисунок 16.4).

Рисунок 16.4 – Обозначение ассоциированной сущности в нотации Баркера

156

Если экземпляр сущности полностью идентифицируется своими ключевыми

атрибутами, то говорят о полной идентификации сущности. В противном случае

идентификация сущности осуществляется с использованием атрибутов связанной

сущности, что указывается черточкой на линии связи (рисунок 16.5).

Рис. 16.5 – Обозначение идентификации посредством другой сущности в нотации Баркера

Рассмотрим структуру базы данных для АИС «Склад оптовой торговли».

Основными сущностями для решения указанной задачи являются: «поставщик»,

«покупатель», «товар». Сразу возникает очевидная связь между сущностями —

«покупатели могут приобретать много товаров», «товары могут приобретаться многими

покупателями». Отношение между ними относится к типу «многие-ко-многим» (рисунок

16.6).

Рисунок 16.6 – Первый вариант ER-диаграммы

Для разрешения этого отношения введем две ассоциированные сущности

«Приходная накладная» и «Расходная накладная», которые отражают

приобретение/продажу товара покупателем/поставщиком (рисунок 16.7).

Рисунок 16.7 – Промежуточный вариант ER-диаграммы

Проанализируем атрибуты сущностей. Каждый поставщик и покупатель является

юридическим лицом и имеет наименование, адрес, банковские реквизиты. Каждый товар

157

имеет наименование, цену, характеризуется единицей измерения. Каждая накладная имеет

уникальный номер, дату выписи, список товаров с количествами и ценами, а также общую

сумму накладной. Покупатели покупают товары, получая при этом расходные накладные,

в которые внесены данные о количестве и цене приобретенного товара.

Каждый покупатель может получить несколько накладных. Каждую накладную

необходимо выписывать на одного покупателя. Каждая накладная должна содержать не

менее одного товара (не может быть «пустой» накладной). Каждый товар, в свою очередь,

может быть продан нескольким покупателям по нескольким накладным. Аналогичную

цепь рассуждений можно выстроить для определения связей между сущностями «Товар»

и «Поставщик». Покупатель может быть одновременно и поставщиком, поэтому эти две

сущности объединены в одну сущность «Контрагент». Теперь можно все это внести в

диаграмму. Таким образом, после уточнения диаграмма будет выглядеть следующим

образом (рисунок 16.8).

Рисунок 16.8 – Окончательный вариант ER-диаграммы

Данная диаграмма должна быть проверена с точки зрения возможности получения

всех выходных данных, показанных на диаграмме потоков данных разрабатываемой

системы.

Лекция 17. Объектно-ориентированный подход к моделированию предметной

области, его сущность.

Принципиальное различие между структурным и объектно-ориентированным

подходами заключается в способе декомпозиции системы. Объектно-ориентированный

подход использует объектную декомпозицию, при этом структура системы описывается в

терминах объектов и связей между ними, а поведение системы — в терминах обмена

158

сообщениями между объектами. Каждый объект системы обладает своим собственным

поведением, моделирующим поведение объекта реального мира.

Концептуальной основой объектно-ориентированного похода является объектная

модель. Основными ее элементами являются абстрагирование, инкапсуляция,

модульность, иерархия.

Абстрагирование (абстракция) — предписывает включать в модель только те

аспекты проектируемой системы, которые имеют непосредственное отношение к

выполнению системой своих функций или своего целевого назначения. При этом все

второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и

исследования полученной модели (так же, как, например, при проектировании жилого

дома не следует отвлекаться на подбор обоев для оклеивания его внутренних стен).

Инкапсуляция подразумевает скрытие элементов объекта, определяющих его

устройство и поведение. Правило инкапсуляции — для обеспечения надежности

нежелателен прямой доступ к полям объекта, чтение и обновление их содержимого

должно производиться посредством вызова соответствующих методов. Абстракция и

инкапсуляция — взаимодополняющие понятия: абстракция выделяет внешнее поведение

объекта, а инкапсуляция содержит и скрывает реализацию, которая обеспечивает это

поведение. Инкапсуляция достигается с помощью информационной закрытости. Обычно

скрываются структура объектов и реализация их методов.

Модульность — это свойство системы, связанное с возможностью ее

декомпозиции на ряд модулей. Модули служат физическими контейнерами, в которых

объявляются классы и объекты логической обработки. Общая цель декомпозиции на

модули — уменьшение сложности программного обеспечения за счет выделения модулей,

которые проектируются и изменяются независимо друг от друга. Изменение реализации

модулей должно проводиться без знания реализации других модулей и без влияния на их

поведение.

Иерархия (иерархическая организация) — это формирование из абстракций

иерархической структуры, т.е. расположение их по уровням. Основными видами

иерархических структур применительно к сложным системам являются:

— структура классов (один класс использует структурную или функциональную

часть соответственно одного или нескольких других классов);

— структура объектов (агрегация, например структура типа «запись»).

Важное качество объектного подхода — согласованность моделей деятельности

организации и моделей проектируемой информационной системы от стадии

формирования требований до стадии реализации. По объектным моделям может быть

159

прослежено отображение реальных сущностей моделируемой предметной области

(организации) в объекты и классы информационной системы.

Объектно-ориентированный подход обладает следующими преимуществами.

1. Объектная декомпозиция дает возможность создавать модели меньшего размера

путем использования общих механизмов, обеспечивающих необходимую экономию

выразительных средств. Использование объектного подхода существенно повышает

уровень унификации разработки и пригодность для повторного использования, что ведет

к созданию среды разработки и переходу к сборочному созданию моделей.

2. Объектная декомпозиция позволяет избежать создания сложных моделей, так

как она предполагает эволюционный путь развития модели на базе относительно

небольших подсистем.

3. Объектная модель естественна, поскольку ориентирована на человеческое

восприятие мира.

К недостаткам объектно-ориентированного подхода относятся высокие начальные

затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается

после разработки двух-трех проектов и накопления повторно используемых компонентов.

Диаграммы, отражающие специфику объектного подхода, менее наглядны.

Лекция 18. Универсальный язык моделирования UML.

Большинство существующих методов объектно-ориентированного подхода

включают язык моделирования и описание процесса моделирования. В качестве языка

моделирования в объектном подходе используется унифицированный язык

моделирования UML, который содержит стандартный набор диаграмм для

моделирования.

В настоящее время UML является общепринятым стандартом документирования

процесса создания информационных систем и их программного обеспечения.

Разработка универсального языка моделирования UML началась с середины 1990-х

годов на базе нескольких объектно-ориентированных методов и нотаций описания

информационных систем.

Причиной, побудившей к созданию универсального языка описания программного

обеспечения, явилась постоянно возрастающая сложность проектируемых

информационных систем, которая в свою очередь диктуется усложнением решаемых

задач.

160

Когда количество объектов информационной системы не превышает 7-8

(психологический барьер, за которым человек не в состоянии оперировать информацией

без дополнительных записей), сложности, возникающие при проектировании системы,

преодолимы и без специальных средств. Такую информационную систему (для одного

рабочего места или для небольшой компании) способен создать один человек. Когда же

число объектов, состояний и переходов между ними доходит до нескольких тысяч, а то и

миллионов, то ни один специалист, каким бы опытным и образованным он не был, не в

состоянии охватить всю систему в целом.

Такие информационные системы создаются группами разработчиков с разделением

функциональных ролей. Тогда становится необходимым инструмент общения, каковым

является UML. Конструктивное использование языка UML основывается на понимании

общих принципов моделирования сложных систем и особенностей процесса объектно-

ориентированного анализа и проектирования, абстрагирования, многомодельности,

иерархического построения моделей сложных систем. Эти принципы уже упоминались

выше.

Принцип абстрагирования заключается в выделении существенных аспектов

системы и отвлечении их от несущественных.

Принцип многомодельности представляет собой утверждение о том, что никакая

единственная модель не может с достаточной степенью адекватности описывать

различные аспекты сложной системы. Применительно к методологии объектно-

ориентированного анализа это означает, что достаточно полная модель сложной системы

допускает некоторое число взаимосвязанных представлений, каждое из которых

адекватно отражает некоторый аспект поведения или структуры системы.

Принцип иерархического построения предписывает рассматривать процесс

построения модели на разных уровнях абстрагирования или детализации в рамках

фиксированных представлений. При этом исходная, или первоначальная, модель сложной

системы имеет наиболее общее представление (метапредставление). Такая модель

строится на начальном этапе проектирования и может не содержать многих деталей и

аспектов моделируемой системы.

Концептуальная модель UML включает в себя три составные части: основные

строительные блоки языка, правила их сочетания и некоторые общие для всего языка

механизмы.

UML — это язык, состоящий из словаря и правил, позволяющих комбинировать

входящие в него слова и получать осмысленные конструкции. В языке моделирования

словарь и правила ориентированы на концептуальное и физическое представление

161

системы. Словарь языка UML включает три вида строительных блоков: сущности,

отношения, диаграммы.

Сущности — это абстракции, являющиеся основными элементами модели.

Отношения связывают различные сущности. Диаграммы группируют представляющие

интерес совокупности сущностей.

С помощью языка UML можно построить структурные модели и модели

поведения.

Структуру сущностей или компонентов некоторой системы, включая их классы,

интерфейсы, атрибуты и отношения, описывают структурные модели.

Модели поведения описывают поведение или функционирование объектов

системы, включая их методы, взаимодействие и сотрудничество между ними, а также

процесс изменения состояний отдельных компонентов и системы в целом. В рамках языка

UML все представления о модели сложной системы фиксируются в виде специальных

графических конструкций, получивших название диаграмм. В терминах языка UML

определены следующие виды диаграмм:

— диаграмма вариантов использования (use case diagram) — для моделирования

бизнес-процессов организации (требований к системе);

— диаграмма классов (class diagram) — для моделирования статической структуры

классов системы и связей между ними;

— диаграммы поведения системы (behavior diagrams):

1) диаграмма состояний (statechart diagram) — для моделирования поведения

объектов системы при переходе из одного состояния в другое;

2) диаграмма деятельности (activity diagram) — для моделирования поведения

системы в рамках различных вариантов использования или моделирования деятельности;

3) диаграммы взаимодействия (interaction diagrams) — для моделирования процесса

обмена сообщениями между объектами — диаграмма последовательности (sequence

diagram), диаграмма кооперации (collaboration diagram);

— диаграммы реализации (implementation diagrams):

1) диаграмма компонентов (component diagram) — для моделирования иерархии

компонентов (подсистем) системы;

2) диаграмма развертывания (deployment diagram) — для моделирования

физической архитектуры системы.

Создание диаграмм аналогично созданию проекта в строительстве — можно

обойтись и без него, если, например, строить сарай на дачном участке. Но выстроить

большое здание гораздо сложнее.

162

Без использования проекта будет неопределенным конечный результат.

Информационная система, описанная UML-диаграммами, показывает разработчику

результат, который необходимо достичь в процессе проектирования.

Лекция 19. UML-диаграммы.

Диаграммы вариантов использования.

Разработку спецификаций информационной системы начинают с анализа

требований к функциональности, указанных в техническом задании. В процессе этого

анализа выявляют внешних пользователей разрабатываемого программного обеспечения

ИС и перечень отдельных аспектов его поведения в процессе взаимодействия с

конкретными пользователями. Аспекты поведения программного обеспечения были

названы «вариантами использования», или «прецедентами» (use cases).

Вариант использования представляет собой последовательность действий,

выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом

(действующим лицом), в качестве которого могут выступать не только люди, но и другие

системы и устройства. Вариант использования описывает типичное взаимодействие

между пользователем и системой.

Каждый вариант использования связан с некоторой целью, имеющей

самостоятельное значение. Например, для текстового редактора «Формирование

оглавления» — это вариант использования, а «Связывание заголовков со специальными

стилями» — операция, которую необходимо выполнить, чтобы стало возможно

автоматическое построение оглавления.

В зависимости от цели выполнения процедуры различают следующие варианты

использования:

— основные (базовые) — обеспечивают требуемую функциональность

разрабатываемого ПО;

— вспомогательные — обеспечивают выполнение необходимых настроек системы

и ее обслуживание (например, архивирование информации и т.п.);

— дополнительные — обеспечивают дополнительные удобства для пользователя

(как правило, реализуются в том случае, если не требуют серьезных затрат каких-либо

ресурсов ни при разработке, ни при эксплуатации).

Следует отметить, что одним из требований языка UML является

самодостаточность диаграмм для представления информации о моделях проектируемых

систем. Однако изобразительных средств языка UML явно не хватает для того, чтобы

163

учесть на диаграммах вариантов использования особенности функционального поведения

сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми

сценариями, которые уточняют или детализируют последовательность действий,

совершаемых системой при выполнении ее вариантов использования.

В контексте языка UML сценарий используется для дополнительной иллюстрации

взаимодействия актеров и вариантов использования.

Предлагаются различные способы представления или написания подобных

сценариев. Один из таких шаблонов рассматривается ниже и может быть рекомендован

для применения на начальных этапах концептуального моделирования. В зависимости от

уровня абстракции вариант использования может описываться кратко или более

подробно. Краткая форма описания содержит название варианта использования, его цель,

действующих лиц, тип варианта использования (основная, второстепенная или

дополнительная) и его краткое описание. Ниже приводится шаблон для написания

сценария отдельного варианта использования:

При написании сценариев вариантов использования важно понимать, что текст

сценария должен дополнять или уточнять диаграмму вариантов использования, но не

заменять ее полностью.

В противном случае будут потеряны достоинства визуального представления

моделей.

Диаграммы вариантов использования позволяют наглядно представить ожидаемое

поведение системы. Основными понятиями диаграмм вариантов использования являются:

действующее лицо, вариант использования и связь.

Условные обозначения, применяемые при изображении диаграмм вариантов

использования, приведены на рисунке 19.1.

164

Рисунок 19.1 – Основные условные обозначения диаграмм вариантов использования:

а — действующее лицо; б — вариант использования; в — связь

Действующее лицо (актер) — внешняя по отношению к разрабатываемой системе

сущность, которая взаимодействует с ней в целях получения или предоставления какой-

либо информации. Как уже упоминалось выше, действующими лицами могут быть

пользователи, другое ПО или какие-либо технические средства, взаимодействующее с

системой.

Вариант использования в сценарии — некоторая очевидная для действующего

лица процедура, решающая его конкретную задачу. Все варианты использования так или

иначе связаны с требованиями к функциональности разрабатываемой системы и могут

сильно различаться по объему выполняемой работы.

Связь — взаимодействие действующих лиц и соответствующих вариантов

использования.

Варианты использования также могут быть связаны между собой. При этом

фиксируют связи использования и расширения.

Использование (uses/include) подразумевает, что существует некоторый фрагмент

поведения разрабатываемого ПО, который повторяется в нескольких вариантах

использования. Этот фрагмент оформляют как отдельный вариант использования и

указывают связь с ним типа «использование».

Расширение (extends) применяют, если имеются два подобных варианта

использования, различающиеся наличием в одном из них некоторых дополнительных

действий. В этом случае дополнительные действия определяют как отдельный вариант

использования, который связан с основным вариантом связью типа «расширение».

Главное назначение диаграммы вариантов использования заключается в

формализации функциональных требований к системе и возможности согласования

полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов

использования может быть подвергнут дальнейшей декомпозиции на множество

подвариантов использования отдельных элементов, которые образуют исходную

сущность.

Для иллюстрации особенностей спецификации функциональных требований на

диаграмме вариантов использования можно рассмотреть модель системы «Склад оптовой

торговли». Для первоначального понимания структуры программной системы выявляются

действующие лица (люди или системы, между которыми происходит взаимодействие).

165

Рассматриваемая система имеет пять актеров, двое из которых являются контрагентами, а

другие менеджерами склада, осуществляющими выполнение всех операций.

Каждый из этих актеров взаимодействует с системой, хотя главными актерами,

пожалуй, являются поставщики и покупатели (контрагенты), поскольку именно они

инициируют функциональность системы. Далее формулируются варианты использования,

т. е. действия, выполняемые системой для реализации общения действующих лиц

(актеров).

Каждый из актеров преследует определенные цели по отношению к системе:

поставщик — сдать товар на склад, покупатель — приобрести товар, менеджер склада —

принять и отпустить товар, менеджер учетного отдела — определить объемы поступления

и продаж и проанализировать товарный запас. На основании этих целей можно

сформулировать базовые варианты использования и проанализировать взаимосвязи между

ними (рисунок 19.2).

Рисунок 19.2 – Диаграмма вариантов использования для проектирования программного

обеспечения АИС «Склад оптовой торговли»

На самом деле вариантов использования может быть гораздо больше. Например,

проверить платежеспособность клиента, получить информацию о товаре, оценить запасы

товара на складе, получить оплату, вывести информацию на экран и т.д. Однако эта

диаграмма дает понять, что будет делать система, как она будет функционировать.

На следующем этапе разработки модели вариантов использования для

рассматриваемой системы следует дополнить данную диаграмму текстовым сценарием,

написанным на основе предложенного ранее шаблона. Этот сценарий будет дополнять

166

диаграмму, раскрывая содержание и логическую последовательность отдельных действий,

которые выполняются системой и актерами в процессе поступления и реализации товаров.

В этом случае сценарий удобно представить в виде таблиц, каждая из которых описывает

отдельный раздел шаблона.

В главном разделе сценария указываются имя рассматриваемого варианта

использования, имена взаимосвязанных с ним актеров, цель выполнения варианта,

условный тип и ссылки на другие варианты использования.

В следующем разделе сценария изложена последовательность действий,

приводящая к успешному выполнению рассматриваемого варианта использования. При

этом инициатором действий должен выступать актер Покупатель. Для удобства

последующих ссылок каждое действие помечается порядковым номером.

В третьем разделе сценария описывается последовательность действий,

выполняемых при возникновении исключительных ситуаций или исключений.

167

Можно дополнить данный сценарий, аналогичным образом описав не только

варианты использования «Оформление заказа» и «Определение наличия товара», но и

рассмотрев другие исключения, например оформление скидок постоянным покупателям,

и т.п. При этом полнота сценариев и модели вариантов использования будут определяться

теми функциональными требованиями, которые сформулированы в рамках конкретного

проекта.

Отдельные, небольшие по своему объему, сценарии могут быть размещены на

диаграмме в форме примечаний. Примечание (note) предназначено для включения в

модель произвольной текстовой информации, имеющей непосредственное отношение к

контексту разрабатываемого проекта. В качестве такой информации могут быть

комментарии разработчика (например, дата и версия разработки диаграммы или ее

отдельных компонентов), ограничения (например, на значения отдельных связей или

экземпляры сущностей) и помеченные значения. Применительно к диаграммам вариантов

использования примечание может иметь уточняющую информацию, относящуюся к

контексту тех или иных вариантов использования.

Графически примечания на всех типах диаграмм обозначаются прямоугольником с

«загнутым» верхним правым уголком (рисунок 19.3).

Рисунок 19.3 – Пример примечаний на диаграммах вариантов использования

Собственно текст примечания размещается внутри этого прямоугольника.

Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет

пунктирная линия. Если примечание относится к нескольким элементам, то от него

проводят соответственно несколько линий. Как уже отмечалось, примечания могут

168

присутствовать не только на диаграмме вариантов использования, но и на других

канонических диаграммах.

Поскольку одно из главных назначений диаграммы вариантов использования —

формализация функциональных требований к системе, она может служить основой для

согласования с заказчиком этих требований на ранней стадии проектирования. Любой из

базовых вариантов использования в последующем может быть подвергнут декомпозиции

на частные варианты использования.

При этом рекомендуется, чтобы общее количество актеров в модели не превышало

20, а вариантов использования — 50. В противном случае модель теряет свою наглядность

и, возможно, заменяет собой одну из некоторых других диаграмм.

Для разработки диаграммы вариантов использования рекомендуется некоторая

последовательность действий:

— определить главных или первичных и второстепенных актеров;

— определить цели главных актеров по отношению к системе;

— сформулировать основные варианты использования, которые специфицируют

функциональные требования к системе;

— упорядочить варианты использования по степени убывания риска их

реализации;

— рассмотреть все базовые варианты использования в порядке убывания их

степени риска;

— выделить участников, интересы, предусловия и постусловия выполнения

выбранного варианта использования;

— написать успешный сценарий реализации выбранного варианта использования;

— определить исключения или неуспех в выполнении сценария варианта

использования;

— написать сценарии для всех исключений;

— выделить общие варианты использования и изобразить их взаимосвязи с

базовыми со стереотипом uses/include;

— выделить варианты использования для исключений и изобразить их взаимосвязи

с базовыми со стереотипом extend;

— проверить диаграмму на отсутствие дублирования вариантов использования и

актеров.

Семантика построения диаграммы вариантов использования должна определяться

следующими особенностями рассмотренных выше элементов модели. Отдельный

экземпляр варианта использования по своему содержанию является выполнением

169

последовательности действий, которая инициализируется посредством экземпляра

сообщения от экземпляра актера. В качестве отклика или ответной реакции на сообщение

актера выполняется последовательность действий, установленная для данного варианта

использования. При этом актеры могут генерировать новые сообщения для

инициирования вариантов использования. Подобное взаимодействие будет продолжаться

до тех пор, пока не закончится выполнение требуемой последовательности действий

экземпляром варианта использования и указанный в модели экземпляр актера не получит

требуемый экземпляр сервиса. Окончание взаимодействия означает отсутствие

инициализации сообщений от актеров для базовых вариантов использования.

Варианты использования могут быть дополнительно специфицированы

примечаниями с текстом, которые в последующем могут стать прототипами операций и

методов совместно с атрибутами.

Дальнейшая разработка моделей связана с реализацией вариантов использования в

виде графа деятельности, посредством конечного автомата или любого другого механизма

логического представления поведения, включающего предусловия и постусловия.

Взаимодействие между вариантами использования и актерами может уточняться на

диаграмме кооперации, когда описываются взаимосвязи между системой, содержащей эти

варианты использования, и окружением или внешней средой этой системы.

Диаграммы деятельности.

Если диаграмма вариантов использования дает «вид сверху» на функциональность

системы, диаграмма деятельности, напротив, позволяет подробно иллюстрировать

отдельный вариант использования и его сценарии.

Под деятельностью в данном случае понимают задачу (операцию), которую

необходимо выполнить вручную или с помощью средств автоматизации. Каждому

варианту использования соответствует своя последовательность задач. В теоретическом

плане диаграммы деятельности — обобщенное представление алгоритма, реализующего

анализируемый вариант использования.

На диаграмме деятельность обозначается прямоугольником с закругленными

углами (рисунок 19.4, а).

Рисунок 19.4 – Условные обозначения диаграммы деятельностей:

а — деятельность; б — выбор; в — линейки синхронизации; г — начало; д — конец

170

Диаграммы деятельности позволяют описывать альтернативные и параллельные

процессы. Для обозначения альтернативных процессов используют ромб (рисунок 19.4,

б), условие указывают рядом, а альтернативы «да», «нет» — рядом с соответствующими

выходами.

С помощью этого же блока можно построить циклический процесс.

Множественность активации деятельности обозначают символом «*», помещенным рядом

со стрелкой активации деятельности, и при необходимости уточняют надписью вида «для

каждой строки».

Для обозначения параллельных процессов используют линейки синхронизации

(рисунок 19.4, в), причем условие синхронизации можно уточнить, указав его на

диаграмме (рисунок 19.5).

Рисунок 19.5 – Пример диаграммы деятельности с указанием параллельности процессов

Теперь рассмотрим пример построения диаграммы деятельности.

В предыдущем примере для конкретизации описания вариантов использования в

АИС «Склад оптовой торговли» был разработан текстовый сценарий. Этот сценарий

дополняет диаграмму, раскрывая содержание отдельных действий, выполняемых

системой и актерами. Однако вместо описания вариантов использования или в

дополнение к ним можно использовать диаграммы деятельностей. Диаграмма

деятельности позволяет проиллюстрировать вариант использования с требуемой степенью

подробности.

Имеет смысл уточнять только те варианты использования, краткое описание

которых недостаточно для понимания сущности решаемых проблем. Диаграммы

деятельностей можно использовать вместо текстового описания вариантов использования

или в дополнение к ним.

В рамках разрабатываемой модели построим диаграммы деятельности для

реализации вариантов использования «Продажа товара» и «Поставка товара». На рисунке

171

19.6 показан вариант диаграммы деятельности для описания последовательности действий

при поставке товаров.

Рисунок 19.6 – Пример диаграммы деятельности

Однако диаграмма деятельности позволяет проиллюстрировать вариант

использования с различной степенью подробности, и диаграмму деятельности для

варианта использования «Поставка товара» можно представить следующим образом

(рисунок 19.7).

172

Рисунок 19.7 – Диаграмма деятельности для варианта использования «Поставка товара»

Проанализировав вариант использования «Продажа товара», построим диаграмму

деятельности для варианта использования «Продажа товара» (рисунок 19.8).

173

Рисунок 19.8 – Диаграмма деятельности для варианта использования «Продажа товара»

Полная модель системы может содержать несколько диаграмм деятельности,

каждая из которых описывает последовательность реализации либо наиболее важных

вариантов использования (типичный ход событий и все исключения), либо нетривиальных

операций классов.

Помимо стандартного формата описания UML предлагает вариант с

«плавательными дорожками». Этот формат удобен для описания случая, когда в варианте

использования участвуют несколько действующих лиц. При этом все состояния действия

на диаграмме деятельности делятся на отдельные группы, отделяющие друг от друга

вертикальными линиями (рисунок 19.9).

Рисунок 19.9 – Вариант диаграммы деятельности с дорожками

174

Применение дорожек открывает дополнительные возможности для наглядного

представления бизнес-процессов, позволяя специфицировать деятельность подразделений

предприятий (рисунок 19.10).

Рисунок 19.10 – Пример применения диаграммы деятельности с дорожками для варианта

использования «Оформление заказа»

В случае типового проекта большинство деталей реализации действий могут быть

известны заранее на основе анализа существующих систем или предшествующего опыта

разработки систем-прототипов. Использование типовых решений может существенно

сократить время разработки и избежать возможных ошибок при реализации проекта.

Диаграммы последовательности.

Рассмотренные диаграммы деятельности используются для спецификации

динамики поведения систем, время в явном виде в них не присутствует. Однако

временной аспект поведения может иметь существенное значение при моделировании

синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в

языке UML используются диаграммы последовательности — графические модели,

которые для определенного сценария варианта использования показывают динамику

взаимодействия объектов во времени.

175

Для построения диаграммы последовательностей системы необходимо:

— идентифицировать каждое действующее лицо (объект) и изобразить для него

линию жизни;

— из описания варианта использования определить множество системных событий

и их последовательность;

— изобразить системные события в виде линий со стрелкой на конце между

линиями жизни действующих лиц и системы, а также указать имена событий и списки

передаваемых значений.

На диаграмме последовательности изображаются исключительно те объекты,

которые непосредственно участвуют во взаимодействии и не показываются возможные

статические ассоциации с другими объектами. Для диаграммы последовательности

ключевым моментом является именно динамика взаимодействия объектов во времени.

При этом диаграмма последовательности имеет как бы два измерения.

Первое измерение — слева направо в виде вертикальных линий, каждая из которых

изображает линию жизни отдельного объекта, участвующего во взаимодействии.

Графически каждый объект изображается прямоугольником и располагается в верхней

части своей линии жизни. Внутри прямоугольника записывают имя объекта и имя класса,

разделенные двоеточием. При этом вся запись подчеркнута, что является признаком

объекта, который, как известно, представляет собой экземпляр класса (рисунок 19.11).

Рисунок 19.11 – Различные графические примитивы диаграммы последовательности

Не исключается ситуация, когда имя объекта может отсутствовать на диаграмме

последовательности. В этом случае указывается только имя класса, а сам объект считается

анонимным.

Крайним слева на диаграмме изображается объект, который является инициатором

взаимодействия (объект 1). Правее изображается другой объект, который непосредственно

взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности

176

образуют некоторый порядок, определяемый степенью активности этих объектов при

взаимодействии друг с другом.

Второе измерение диаграммы последовательности — вертикальная временная ось,

направленная сверху вниз. Начальному моменту времени соответствует самая верхняя

часть диаграммы.

При этом взаимодействия объектов реализуются посредством сообщений, которые

посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных

стрелок с именем сообщения. Кроме того, их показывают в определенном порядке в

соответствии со временем своего возникновения. Другими словами, сообщения,

расположенные на диаграмме последовательности выше, инициируются раньше тех,

которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку

диаграмма последовательности моделирует лишь временную упорядоченность

взаимодействий типа «раньше-позже».

Линия жизни объекта служит для обозначения периода времени, в течение

которого объект существует в системе и, следовательно, может потенциально участвовать

во всех ее взаимодействиях.

На диаграмме линия жизни изображается пунктирной вертикальной линией,

ассоциированной с единственным объектом.

Если объект существует в системе постоянно, то и его линия жизни должна

продолжаться по всей плоскости диаграммы последовательности.

Построение диаграммы последовательности целесообразно начинать с выделения

из всей совокупности тех и только тех классов, объекты которых участвуют в

моделируемом взаимодействии.

После этого все объекты наносят на диаграмму с соблюдением некоторого порядка

инициализации сообщений. Здесь необходимо установить, какие объекты будут

существовать постоянно, а какие временно — только на период выполнения ими

требуемых действий. Когда объекты определены, можно приступать к спецификации

сообщений. При этом следует учитывать те роли, которые играют сообщения в системе.

В качестве примера построим диаграмму последовательности для реализации

варианта использования «Продажа товара» в АИС «Склад оптовой торговли» (рисунок

19.12).

177

Рисунок 19.12. Вариант диаграммы последовательности для моделирования операции

продажи товара

Данная диаграмма содержит два объекта и одного актера. Объекты не являются

постоянно активными, что показано с помощью соответствующих фокусов управления. В

качестве имен сообщений указаны имена операций, которые специфицированы у

соответствующих классов. Предложения-условия некоторых сообщений записаны

обычным текстом в квадратных скобках. Эти условия отражают возможность ветвления

процесса продажи и выполнения исключительного сценария соответствующего варианта

использования, однако другие варианты использования на данной диаграмме не показаны.

Лекция 20. Сравнительный анализ структурного

и объектно-ориентированного моделирования.

В функциональных моделях (DFD-диаграммах потоков данных, IDEF-диаграммах)

главными структурными компонентами являются функции (операции, действия, работы),

которые на диаграммах связываются между собой потоками информации.

Несомненным достоинством функциональных моделей является реализация

структурного подхода к проектированию информационной системы по принципу «сверху-

вниз», когда каждый функциональный блок может быть декомпозирован на множество

подфункций, задач и т.д., выполняя, таким образом, модульное проектирование

информационной системы. Для функциональных моделей характерны процедурная

строгость декомпозиции ИС и наглядность представления.

При функциональном подходе объектные модели данных в виде ER-диаграмм

«объект — свойство — связь» разрабатываются отдельно.

178

Главный недостаток функциональных моделей заключается в том, что процессы и

данные существуют отдельно друг от друга — помимо функциональной декомпозиции

существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия

выполнения процессов обработки информации, которые динамически могут изменяться.

Перечисленные недостатки функциональных моделей отсутствуют в объектно-

ориентированных моделях, где главным структурообразующим компонентом выступает

класс объектов с набором функций, которые могут обращаться к атрибутам этого класса.

Для классов объектов характерна иерархия обобщения, позволяющая осуществлять

наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к

нижестоящему классу, но и функций (методов).

В случае наследования функций можно абстрагироваться от конкретной

реализации процедур (абстрактные типы данных), которые различаются для

определенных подклассов ситуаций. Это дает возможность обращаться к подобным

программным модулям по общим именам (полиморфизм) и повторно использовать

программный код при модификации программного обеспечения.

Таким образом, адаптивность объектно-ориентированных систем к изменению

предметной области по сравнению с функциональным подходом значительно выше.

При объектно-ориентированном подходе изменяется и принцип проектирования

ИС. Сначала выделяют классы объектов, а далее в зависимости от возможных состояний

объектов (жизненного цикла объектов) определяют методы обработки (функциональные

процедуры), что обеспечивает наилучшую реализацию динамического поведения


Для объектно-ориентированного подхода разработаны графические методы

моделирования предметной области, обобщенные в языке унифицированного

моделирования UML. Однако по наглядности представления модели пользователю-

заказчику объектно-ориентированные модели явно уступают функциональным моделям.

При выборе методики моделирования предметной области обычно в качестве

критерия выступает степень ее динамичности.

Для регламентированных задач больше подходят функциональные модели, для

более адаптивных бизнес-процессов (управления рабочими потоками, реализации

динамических запросов к информационным хранилищам) — объектно-ориентированные.

Однако в рамках одной и той же ИС для различных классов задач могут

требоваться различные виды моделей, описывающих одну и ту же проблемную область. В

таком случае нужно использовать комбинированные модели предметной области.

179

Таким образом, каждая из рассмотренных методик позволяет решить задачу

построения формального описания рабочих процедур исследуемой системы. Все

методики позволяют построить модели «как есть» и «как должно быть». В то же время

каждая из этих методик обладает существенными недостатками. В целом их можно

охарактеризовать следующим образом: недостатки применения отдельной методики

лежат не в области описания реальных процессов, а в неполноте методического подхода.

Функциональные методики нагляднее дают представление о существующих

функциях в организации, о методах их реализации. Причем, чем выше степень

детализации исследуемого процесса, тем лучше они позволяют описать систему. Под

лучшим описанием в данном случае понимается наименьшая ошибка при попытке по

полученной модели предсказать поведение реальной системы. На уровне отдельных

рабочих процедур их описание практически однозначно совпадает с фактической

реализацией в потоке работ.

На уровне общего описания системы функциональные методики допускают

значительную степень свободы в выборе общих интерфейсов системы, ее механизмов и

т.д., т.е. в определении границ системы. Хорошо описать систему на этом уровне

позволяет объектный подход, основанный на понятии сценария использования.

Ключевым является понятие о сценарии использования как о сеансе

взаимодействия действующего лица с системой, в результате которого действующее лицо

получает нечто, имеющее для него ценность. Использование критерия ценности для

пользователя дает возможность отбросить не имеющие значения детали потоков работ и

сосредоточиться на тех функциях системы, которые оправдывают ее существование.

Однако и в этом случае задача определения границ системы, выделения внешних

пользователей является сложной.

Технология потоков данных, исторически возникшая первой, легко решает

проблему границ системы, поскольку дает возможность за счет анализа информационных

потоков выделить внешние сущности и определить основной внутренний процесс. Однако

отсутствие выделенных управляющих процессов, потоков и событийной

ориентированности не позволяет предложить эту методику в качестве единственной.

Наилучшим способом преодоления недостатков рассмотренных методик является

формирование синергетической методики, объединяющей различные этапы отдельных

методик. При этом из каждой методики необходимо взять часть методологии, наиболее

полно и формально изложенную, и обеспечить возможность обмена результатами на

различных этапах применения синергетической методики.

180


1. Каковы цели моделирования предметной области?

2. Назовите три уровня построения моделей предметной области.

3. Какой существует подход к решению проблемы сложных систем?

4. Объясните сущность структурного подхода к разработке ИС.

5. В чем сущность объектно-ориентированного подхода?

6. На каких принципах базируются методологии структурного подхода?

7. Какие требования предъявляют к модели предметной области?

8. Назовите особенности методологии SADT.

9. Какие компоненты составляют диаграмму потоков данных (DFD)?

10. Для чего предназначена диаграмма «сущность-связь»?

11. Назовите базовые понятия ER-модели данных.

12. Что является концептуальной основой объектно-ориентированного похода?

13. Назовите основные элементы объектной модели.

14. В чем заключается принцип абстрагирования?

15. Что представляет собой принцип многомодельности?

16. Что представляет собой принцип иерархического построения систем?

17. Какие виды диаграмм определены в UML?

18. Назовите преимущества объектно-ориентированный подхода.

19. Что представляет собой вариант использования в UML?

20. Почему диаграммы вариантов использования рекомендуется дополнять

текстовыми сценариями?

21. Для чего используют диаграммы деятельности?

22. В чем особенность диаграммы последовательности системы?

23. Дайте сравнительную характеристику структурного и объектно-

ориентированного методов моделирования.

181

5. МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ПРАКТИЧЕСКИМ ЗАНЯТИЯМ

ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ

5.1 Перечень практических занятий

№ и тема практической работы Объем часов

Раздел 1. Общая характеристика ИС.ПР № 1: Работа с иерархическими классификаторами. 4ПР № 2: Работа с дескрипторными классификаторами. 12

Раздел 2. Экспертные системы.ПР № 3: Разработка экспертной системы. 4

Раздел 4. Моделирование ИС.ПР № 4: Разработка SADT-диаграммы. 6ПР № 5: Разработка DFD-диаграммы. 6ПР № 6: Разработка ER-диаграммы. 6ПР № 7: Разработка UML-диаграмм. 12

Раздел 5. Работа с CASE-средствами проектирования.ПР № 8: Разработка и построение диаграммы SADT в среде Visual. 12ПР № 9: Разработка и построение диаграммы DFD в среде Visual. 12ПР № 10: Разработка и построение диаграммы ER в среде Visual. 12ПР № 11: Разработка и построение диаграммы прецедентов в среде Visual. 12ПР № 12: Разработка и построение диаграммы классов в среде Visual. 12ПР № 13: Разработка и построение диаграммы последовательностей в среде Visual.

12

ПР № 14: Разработка и построение диаграммы активностей в среде Visual. 12ПР № 15: Оформление альбома диаграмм. 10

ВСЕГО: 144

182

5.2 Методические указания к практическим занятиям

Практическая работа № 1

РАБОТА С ИЕРАРХИЧЕСКИМИ КЛАССИФИКАТОРАМИ

Цели работы:

- ознакомиться с видами кодов и технологией кодирования информации в

иерархических классификаторах, научиться рассчитывать контрольные числа;

- создать систему кодов для заданной предметной области;

- выполнить кодирование объектов по составленной системе кодов.

Теория к работе:

Решение прикладных задач часто завершается составлением различных сводок,

таблиц, ведомостей, в которых информация сгруппирована по каким-либо реквизитам-

признакам. Группировка осуществляется на основе систем классификации и кодирования,

позволяющих представить технико-экономическую информацию в форме, удобной для

ввода и обработки данных с помощью вычислительной техники.

Информация наиболее часто фиксируется в буквенно-цифровом формате. При этом

количественно-суммовые основания показателей имеют цифровое выражение, а признаки

– буквенно-цифровое. К признакам можно отнести, например, название учреждения,

фамилию работающего, вид операции, которые не всегда удобны для автоматизированной

обработки. Чтобы сделать эту информацию наиболее доступной для восприятия

человеком и машиной, потребовалось создание специальных средств формализованного

описания подобной информации. Эти средства включают целый ряд разработанных

классификаторов, входящих в Единую систему классификации и кодирования (ЕСКК).

Систематизация информации вызывает необходимость применения самых

разнообразных классификаторов:

- общегосударственных, разрабатываемых в централизованном порядке и

являющихся едиными для всей страны;

- отраслевых, единых для какой-либо отрасли деятельности; как правило,

отраслевые классификаторы разрабатываются в типовых проектах автоматизированной

обработки, например, для бухгалтерского учета составлены коды планов счетов, видов

оплат удержаний из заработной платы, видов операций движения материальных

ценностей и др.;

183

- локальных, которые составляются на номенклатуры, характерные для данного

предприятия, организации, банка (коды табельных номеров, подразделений, клиентов и

др.); на данном уровне классификация и кодирование объектов или процессов

осуществляется специалистами предприятия на местах.

Общегосударственные классификаторы (ОК) начали создаваться в стране по

постановлению правительства в 70-х годах прошлого века, и в настоящее время их

создано около четырех десятков. Условно Общегосударственные классификаторы делятся

на 4 группы:

1) Классификаторы трудовых и природных ресурсов, например ОК профессий

рабочих, должностей служащих и тарифных разрядов (ОКПДТР).

2) Классификаторы структуры отраслей (ОК отраслей народного хозяйства –

ОКОНХ), органов управления (система обозначения органов государственного

управления – СООГУ), административно-территориального деления (система

обозначений административно-территориальных объектов – СОАТО), предприятий и

организаций – ОКПО, форм собственности ОКФС.

3) Классификаторы продукции (ОК промышленной и сельскохозяйственной

продукции – ОКП, строительной продукции - ОК).

4) Классификаторы технико-экономических показателей (ОКТЭП), управленческой

документации (ОКУД), системы обозначений единиц измерений и т.д.

Ниже приведены примеры построения некоторых общегосударственных

классификаторов, имеющих наибольшее применение при автоматизированной обработке

информации.

Пример 1. Общегосударственный классификатор.

Идентификационный номер налогоплательщика ИНН – это его индивидуальный

номер. В связи с тем, что все граждане, индивидуальные предприниматели и, естественно,

организации в нашей стране являются налогоплательщиками, он присваивается всем

физическим и юридическим лицам в налоговой инспекции. ИНН – это цифровой код,

состоящий из 12 арабских цифр для физических лиц и 10 для юридических.

Индивидуальные предприниматели используют свой ИНН физического лица, полученный

ранее, или, если такового не было, им присваивается новый при регистрации.

Рассмотрим структуру ИНН:

- 1-я и 2-я цифры ИНН обозначают код субъекта РФ (по большинству регионов

совпадающий с кодом ГИБДД, например 74, 56);

- 3-я и 4-я цифры ИНН обозначают номер отделения ИФНС (например, 45);

184

- цифры с 5-й по 10-ю для физических лиц и с 5-й по 9-ю для юридических лиц –

это номер записи налогоплательщика;

- 11-я и 12-я цифры для физических лиц и 10-я цифра для юридических лиц –

цифры для контроля; контрольное число (контрольная цифра) – разновидность

контрольной суммы, добавляется (обычно в конец) длинных номеров с целью первичной

проверки их правильности, применяется с целью уменьшения вероятности ошибки при

обработке таких номеров: машинном считывании с упаковки товара, записи в документы,

голосовой передаче от человека к человеку; наличие и правильность контрольного числа

не гарантирует достоверность рассматриваемого номера (в том числе не спасает от

действий злоумышленников), но на практике достаточно хорошо оберегает от случайных

ошибок; контрольное число чаще всего – либо последняя цифра суммы всех чисел номера,

либо результат другой математической операции над цифрами.

В компьютерных программах понятие «контрольного числа» обобщено до CRC,

бита четности и кодов Рида-Соломона; а в некоторых архиваторах объем контрольных

данных таков, что позволяет не только обнаружить ошибку, но и исправить ее.

Алгоритм проверки двенадцатизначного ИНН:

1. Вычисляется контрольная сумма исходного двенадцатизначного числа со

следующими весовыми коэффициентами: (7, 2, 4, 10, 3, 5, 9, 4, 6, 8, 0, 0).

2. Вычисляется контрольное число A как остаток от деления контрольной суммы

на 11.

3. Если контрольное число A больше 9, то результирующее контрольное число A

вычисляется как остаток от деления A на 10.

4. Вычисляется контрольная сумма исходного двенадцатизначного числа со

следующими весовыми коэффициентами: (3, 7, 2, 4, 10, 3, 5, 9, 4, 6, 8, 0).

5. Вычисляется контрольное число B как остаток от деления контрольной суммы на

11.

6. Если контрольное число B больше 9, то результирующее контрольное число B

вычисляется как остаток от деления B на 10.

7. Контрольное число A сверяется с одиннадцатым знаком ИНН, а контрольное

число B сверяется с двенадцатым знаком ИНН. В случае их равенства ИНН считается

правильным.

Для 10-значного ИНН:

1. Вычисляется сумма произведений цифр ИНН (с 1-й по 9-ю) на следующие

коэффициенты: 2, 4, 10, 3, 5, 9, 4, 6, 8.

185

2. Вычисляется контрольное число A как остаток от деления контрольной суммы

на 11.

3. Если контрольное число A больше 9, то результирующее контрольное число A

вычисляется как остаток от деления A на 10.

4. Контрольное число A сверяется с десятым знаком ИНН. В случае их равенства

ИНН считается правильным.

Пример 2. Общесоюзный классификатор отраслей народного хозяйства (ОКОНХ).

ОКОНХ предназначен для анализа структуры отрасли. Код – пятизначный,

включает пять группировочных признаков:

- отрасль;

- подотрасль;

- вид;

- группа;

- подгруппа.

В ОКОНХ применена иерархическая классификация. Признаками деления на всех

ступенях является вид деятельности. В классификаторе используется 5-разрядный код.

Каждый из последующих уровней группирует виды деятельности по более глубокой

специализации в общественном разделении труда. Общая схема структуры кода имеет

следующий вид:

X X X X Xотрасль подотрасль вид группа подгруппа

Коды ОКОНХ группируются по первому знаку кода:

Отрасли производственной сферы:

10 000 - промышленность;

20 000 - сельское хозяйство;

30 000 - лесное хозяйство;

50 000 - транспорт и связь;

60 000 - строительство;

70 000 - торговля и общественное питание;

80 000 - материально-техническое снабжение и сбыт;

81 000 - заготовки;

82 000 - информационно-вычислительное обслуживание;

83 000 - операции с недвижимым имуществом;

186

84 000 - общая коммерческая деятельность по обеспечению функционирования

рынка;

85 000 - геология и разведка недр, геодезическая и гидрометеорологическая

службы;

87 000 - прочие виды деятельности сферы материального производства.

Отрасли непроизводственной сферы:

90 000 - жилищно-коммунальное хозяйство;

90 300 - непроизводственные виды бытового обслуживания населения;

91 000 - здравоохранение, физическая культура и социальное обеспечение;

92 000 - народное образование;

93 000 - культура и искусство;

95 000 - наука и научное обслуживание;

96 000 - финансы, кредит, страхование и пенсионное обеспечение;

97 000 - управление;

98 000 - общественные объединения.

С целью сокращения длины кода отрасли, имеющие большое количество

группировок (промышленность, сельское хозяйство, строительство), кодируются с

использованием только первого разряда кода, и для кодирования входящих в отрасли

группировок остается 4 разряда кода. Отрасли с небольшим количеством группировок

(материально-техническое снабжение и сбыт, заготовки и др.) кодируются с

использованием первого и второго разрядов кода, а для кодирования входящих в них

группировок остается только 3 разряда кода.

В соответствии с постановлением Госстандарта России, с 1 января 2003 года введен

в действие Общероссийский классификатор видов экономической деятельности (ОКВЭД).

Данный классификатор вводится взамен ранее действовавшего Общесоюзного

классификатора отраслей народного хозяйства (ОКОНХ).

Пример 3. Общероссийский классификатор предприятий и организаций (ОКПО).

ОКПО – государственный классификатор хозяйствующих субъектов Российской

Федерации. Объектами классификации ОКПО являются юридические лица,

индивидуальные предприниматели, филиалы, представительства, организации,

осуществляющие свою деятельность без образования юридического лица.

Код ОКПО состоит из 8 или 10 цифр, первые 7 или 9 – порядковый номер, а 8-я или

10-я – контрольное число. ОКПО присваивается органами государственной статистики

предприятиям, организациям, фирмам любой собственности.

Пример 4. Общероссийский классификатор продукции (ОКП).

187

ОКП представляет собой древовидную структуру кодов ОКП продукции,

построенных по иерархическому принципу. Классификатор ОКП используется для

решения проблем каталогизации при сертификации однородных групп продукции,

построенных на основе группировок кодов ОКП. Каждый код ОКП продукции содержит 6

цифр группы однородной продукции вида XX XXXX.

Классификатор ОКП имеет пятиступенчатую иерархическую классификацию.

Первую ступень кода ОКП составляют классы продукции XX 0000, затем идут подклассы

классификатора ОКП XX X000, далее однородные группы продукции XX XX00,

подгруппы кода ОКП XX XXX0 и, наконец, виды продукции XX XXXX. К

шестизначному коду ОКП добавляется одна контрольная цифра (контрольное число).

Структура кода по общегосударственному классификатору промышленной и

сельскохозяйственной продукции (ОКП) может быть представлена в виде схемы:

Пример кодирования:

Класс 11. Нефть сырая и газ, услуги по их добыче, кроме изыскательных работ

(1100000).

Подкласс 1. Нефть сырая и природный газ (1110000).

Группа 1. Нефть сырая (1111000).

Подгруппа 1. Нефть сырая необработанная (1111100 – 1111132).

Вид 1. Нефть сырая, обезвоженная и обессоленная (1111210 – 1111320).

Подвид 1. Нефть сырая добытая, материковая и прочая (1111131).

Алгоритм определения контрольного числа для кодов ОКПО, КПО и др. (единый

для многих общероссийских классификаторов):

Одноразрядное контрольное число рассчитывается следующим образом:

1. Начиная со старшего разряда, присваивается набор весов, соответствующий

натуральному ряду чисел от 1 до 10. Если разрядность кода больше 10, то набор весов

повторяется.

188

2. Каждая цифра кода умножается на вес разряда и вычисляется сумма полученных

произведений.

3. Контрольное число для кода представляет собой остаток от деления полученной

суммы на 11.

4. Контрольное число должно иметь один разряд, значение которого находится в

пределах от 0 до 9. Если получается остаток, равный 10, то для обеспечения

одноразрядного контрольного числа необходимо провести повторный расчет, применяя

вторую последовательность весов, сдвинутую на два разряда влево (3, 4, 5,…). Если в

случае повторного расчета остаток от деления вновь сохраняется равным 10, то значение

контрольного числа проставляется равным 0.

Пример 5. Отраслевой классификатор.

Высшие классификационные группировки общесоюзного классификатора

промышленной и сельскохозяйственной продукции (ВКГ ОКП) разработаны на основании

постановления правительства и являются составной частью Единой системы

классификации и кодирования технико-экономической информации. Система,

образующая высшие классификационные группировки (ВКГ), характерна, в частности,

тем, что в нее могут быть вписаны отдельные (локальные) системы цифровых

обозначений, в том числе, например, крепежных деталей и марок сталей и сплавов,

применяемых в машиностроении и смежных отраслях производства. На рисунке приведен

пример кодирования высших классификационных группировок (ВКГ) для

автомобильного бензина:

Приступая к составлению классификаторов, прежде всего, следует выяснить, какие

общегосударственные и отраслевые классификаторы можно использовать при решении

данной задачи, и только после этого приступать к составлению локальных кодов.

Кодированию в документах подлежат те признаки, по которым выполняется группировка

информации в машине. Разработка кодов осуществляется при составлении технического

рабочего проекта.

189

Составление классификаторов выполняется в два этапа: первый этап –

классификация информации, второй – кодирование.

Порядок классификации информации.

Выявляются номенклатуры, подлежащие кодированию. К ним относятся те

реквизиты-признаки, по которым составляется группировка. По каждой номенклатуре

составляется полный перечень всех позиций, подлежащих кодированию. Например, при

кодировании территорий районы располагаются по областям. Упорядоченный список

полного перечня однородных наименований, состоящий из отдельных строк – позиций,

называется номенклатурой. В каждой номенклатуре предусматривается некоторое

количество резервных позиций на случай появления новых объектов. Другими словами,

классификация заключается в распределении элементов множества на подмножества на

основании признаков и зависимости внутри признака.

Этап кодирования.

Кодирование – процесс присвоения условного обозначения различным позициям

номенклатуры. Код – условное обозначение объекта знаком или группой знаков по

определенным правилам, установленным системой кодирования. Коды могут быть

цифровыми, буквенными, буквенно-цифровыми и состоять из одного или нескольких

знаков. При машинной обработке предпочтение отдается информации, закодированной в

цифровой форме, как наиболее удобной для автоматической группировки. После

присвоения кодов создается классификатор – систематизированный свод однородных

наименований и их кодовых обозначений.

Классификаторы применяются в двух случаях.

В первом случае – для ручного проставления в документах. Классификаторы

оформляются в виде справочников и используются для подготовки первичных сводных

документов к машинной обработке. Например, в отчетах в заголовочной части бланка

проставляются коды постоянных признаков отчитывающейся организации:

идентификационный номер налогоплательщика (ИНН), код организации по ОКПО и т.п.

Для проверки правильности проставленных кодов используется «контрольная сумма»,

которая представляет собой искусственный итог по всем кодам. Машинная программа

осуществляет контроль по контрольным суммам и позволяет обнаружить неверно

проставленные коды.

Во втором случае применение кодов предусматривает хранение всех

классификаторов в памяти машины, на машинных носителях в банке данных, в качестве

словаря или условно-постоянной информации. Например, в машине постоянно хранится

справочник для работающих, где имеются такие реквизиты, как фамилия, имя, отчество

190

табельный номер, должность и др. При расчете заработной платы на ЭВМ с первичных

документов вводятся табельные номера и данные о заработной плате. В процессе

обработки данные взятые из справочника, подсоединяются к табельному номеру. В

результате формируется платежная ведомость.

К кодам предъявляется ряд требований:

1) коды должны охватывать все номенклатуры, подлежащие кодированию;

2) коды должны быть едиными для разных задач внутри одного объекта (например,

коды материалов, должны быть одинаковыми для бухгалтерского учета и материально-

технического снабжения);

3) коды должны отличаться стабильностью;

4) коды должны иметь резерв свободных номеров;

5) длина кодового обозначения должна проектироваться минимально возможной;

6) кодирование информации производится по определенной системе –

совокупности правил, определяющих построение кода.

В настоящее время применяется несколько систем кодирования информации, среди

которых наибольшее распространение получили: порядковая, серийная, позиционная и

комбинированная.

В порядковой системе все позиции номенклатуры нумеруются по младшему

признаку, без учета старших признаков. Всем позициям присваиваются порядковые

номера без пропусков. Этот код простой по построению, однако в нем учтен только

младший признак, что затрудняет группировку по старшим признакам. Порядковая

система имеет ограниченное применение и используется при кодировании устойчивых

однопризначных номенклатур.

Серийная система напоминает порядковую, но ею можно закодировать двух- и

более призначные номенклатуры, т.е. имеющие два и более признаков. Каждой группе

старших признаков присваивается серия номеров. В пределах этой серии каждая позиция

младших признаков номенклатуры кодируется порядковым номером. Серийную систему

часто используют для кодирования объектов, характеризуемых двумя признаками. Код

первого признака называется серией, второго признака – номером. Серийная система

выполняется в следующей последовательности: определяется число группировочных

признаков; устанавливается число позиций в каждом группировочном признаке; дается

серия номеров старшим признакам с учетом резерва; производится порядковое

кодирование младших признаков в пределах серийных номеров старших признаков с

учетом резерва; составляется классификатор.

191

В позиционной системе при кодировании четко выделяется каждый признак, и ему

отводится один или несколько разрядов в зависимости от его числа признаков. Затем

каждый признак кодируется отдельно, начиная с 1, 01, 001 и т.п. в зависимости от

значности. Этот код обеспечивает автоматическое формирование в ЭВМ всех

необходимых итогов в соответствии с выделенными признаками.

Комбинированная система так же, как и позиционная, предусматривает четкое

выделение всех признаков номенклатуры. Но при этом каждый признак может

кодироваться в любой системе порядковой, серийной и позиционной. Последовательность

разработки позиционных и комбинированных систем кодирования следующая:

определяется число группировочных признаков; устанавливается число позиций в каждом

группировочном признаке; производится кодирование порядковыми номерами сначала

старшего признака, а затем следующих признаков внутри старших, каждый начиная с 1,

01 и т.п.; составляется классификатор.

Технология применения кодов определяется эксплуатационными возможностями

машин, а также методами программирования, обеспечивающими создание в машине

различных взаимосвязанных массивов информации – банка данных. Новая

информационная технология строится на безбумажной технологии, в которой

производится автоматическое построение документов. Поэтому предусматривается

автоматическое занесение реквизитов в поля кодов. С этой целью в программах

организуются специальные блоки меню: справочники, словари, которые содержат

перечень номенклатур, являющимися постоянными для данного вида деятельности.

Технология применения компьютерных кодов содержит несколько этапов: просмотр и

корректировка программных справочников; составление локальных кодов; загрузка

локальных кодов в машину; использование созданных справочников для заполнения

первичных документов; применение кодов для составления сводных таблиц.

Пример 6. Составление классификатора для ведения операций по балансовому

счету 10 «Материалы».

Предположим, что на предприятии имеются 7 видов материалов и до 99 их

наименований, которые могут располагаться на трех складах. Проводим кодирование в

позиционной системе, где четко выделяем каждый признак. Структура кода будет иметь

вид:

192

Закодируем эти наименования:

Признак Кодовые обозначенияВид материала

сырье и материалы 1полуфабрикаты 2топливо 3запасные части 4прочие материалы 5тара 6строительные материалы 7

Номер складасырья и материалов 1топлива 2строительных материалов 3

Номенклатурный номер материалакраска масляная 01белила цинковые 02гвозди 5 мм 03шурупы 10 мм 04

Код для масляной краски должен быть построен следующим образом: балансовый

счет – 10; строительные материалы – 7; склад строительных материалов – 3;

номенклатурный номер масляной краски – 01. Общий вид кода: 107301.

Задания для самостоятельной работы:

1. Разработать сервис для проверки корректности ИНН по контрольному

числу.

Пользователь вводит ИНН как 12-значное либо 10-значное число, не разбивая на

отдельные цифры.

Сервис выполняет алгоритм проверки ИНН, приведенный в Примере 1, и выдает

сообщения: «Введенный ИНН корректен» либо «Введенный ИНН некорректен».

2. Разработать классификатор продукции на основе выданного вам прайс-

листа.

193

Структуру кода и кодировку конкретных позиций представить аналогично

Примеру 6.


РАБОТА С ДЕСКРИПТОРНЫМИ КЛАССИФИКАТОРАМИ

Цели работы:

- ознакомиться с видами кодов и технологией кодирования информации в

дескрипторных классификаторах;

- создать словарь дескрипторов для заданной предметной области;

- выполнить кодирование объектов по составленной системе кодов.


Дескрипторный метод классификации заключается в следующем:

1) отбирается совокупность ключевых слов или словосочетаний, описывающих

определенную предметную область или совокупность однородных объектов;

2) выбранные ключевые слова и словосочетания подвергаются нормализации, т.е.

из совокупности синонимов выбирается один или несколько наиболее употребляемых;

3) создается словарь дескрипторов, т.е. словарь ключевых слов и словосочетаний,

отобранных в результате процедуры нормализации.

Пример.

Классифицируем учебную деятельность в высшем учебном заведении.

Ключевыми словами могут быть выбраны:

студент

обучаемый

учащийся

преподаватель

учитель

педагог

лектор

ассистент

194

доцент

профессор

коллега

факультет

подразделение университета

аудитория

комната

лекция

практическое занятие

занятие и т.д.

Среди указанных ключевых слов встречаются синонимы, например:

студент, обучаемый, учащийся

преподаватель, учитель, педагог

факультет, подразделение университета и т.д.

После нормализации словарь дескрипторов будет состоять из следующих слов:

студент

преподаватель

лектор

ассистент

доцент

профессор

факультет

аудитория

лекция

практическое занятие и т.д.

Между дескрипторами устанавливаются связи, которые позволяют расширить

область поиска информации. Связи могут быть трех видов:

- синонимические, указывающие некоторую совокупность ключевых слов как

синонимы, например: студент – учащийся – обучаемый;

- родо-видовые, отражающие включение некоторого класса объектов в более

представительный класс, например: университет – факультет – кафедра;

- ассоциативные, соединяющие дескрипторы, обладающие общими свойствами,

например: студент – экзамен – профессор – аудитория.

Задание для самостоятельной работы:

195

1. Получить у преподавателя предметную область для составления дескрипторного

классификатора.

2. Составить словарь дескрипторов: 10-15 ключевых слов.

3. Выявить и записать между выбранными из словаря дескрипторами

синонимические, родо-видовые, ассоциативные связи (чем больше корректных связей

удастся выявить, тем выше будет ваша оценка).

4. Создать дескрипторный классификатор в виде базы данных, обеспечивающей

поиск искомого понятия и понятий, связанных с ним.

Перечень предметных областей:

1. Млекопитающие

2. Металлы и сплавы

3. Живопись

4. Творчество А.С. Пушкина

5. Библиотечная деятельность

6. Злаковые растения

7. Оптика

8. Метеорология

196


РАЗРАБОТКА ЭКСПЕРТНОЙ СИСТЕМЫ

Цель работы: приобретение навыков организации автоматизированного

распознавания ситуации с использованием методологии экспертных систем.


В настоящее время широкое распространение получили системы искусственного

интеллекта, имитирующие на компьютере мышление человека при решении различных

задач. Чтобы воспроизвести на ПК процесс принятия решения человеком, нужно

предварительно отобрать все факты, характеризующие исследуемую человеком область, и

сформулировать правила решения в зависимости от совокупности фактов в момент

принятия решения.

Факты и правила для системы принятия решения должны разрабатываться

экспертом соответствующей предметной области. Они хранятся в компьютере в

специально организованной области памяти, называемой базой знаний. Информация,

которая предъявляется системе для анализа сочетания фактов в данный момент, хранится

в компьютере в специально организованной области памяти, называемой базой данной

(БД).

Экспертная система (система принятия решения) – это система искусственного

интеллекта, объектом управления в которой является база знаний, управляющий объект

содержит человека-пользователя, взаимодействующего с интеллектуальным автоматом

при помощи аппаратного и программного интерфейса, а также программу или

совокупность программ – так называемую машину вывода, которая размещается в памяти

автомата и осуществляет непосредственную обработку знаний. Обработка знаний при

этом заключается в следующем:

197

а) пользователь задает автомату некий факт или совокупность фактов,

выступающих в роли исходной информации для экспертизы. Каждый такой факт

отыскивается в базе знаний или заносится в нее заново;

б) с помощью правил, порядок применения которых задается машиной вывода,

устанавливаются последовательности фактов, связанных с исходными, и определяются

конечные (результирующие) факты;

в) результирующие факты, а иногда и все логические цепочки взаимосвязанных

фактов, снабженные комментариями, выдаются пользователю в виде экспертного

заключения. Тем самым достигается цель управления экспертной системы – получение

пользователем новых знаний.

Общая схема экспертной системы представлена на рисунке:

Пример 1.

Разработать систему принятия решения для предварительной диагностики

неисправности телевизора. Исходная база знаний приведена в таблице 1.

Таблица 1 – База знаний

№ Вид неисправности Порядковый номер атрибута

АтрибутОТСУТСТВУЮТ:

Весовой фактор атрибута

1 Сгорел предохранитель 1.1 Звук 51.2 Изображение 51.3 Световое заполнение

экрана30

2 Неисправна антенна 2.1 Звук 202.2 Изображение 202.3 Световое заполнение

экрана0

3 Неисправен кинескоп 3.1 Звук 03.2 Изображение 203.3 Световое заполнение

экрана10

3.4 Цвет 10

Решение:

198

1. Построим базу данных согласно базе знаний. Для этого сформулируем тестовые

вопросы по фактам, приведенным в таблице 1. Например, для факта «Отсутствует звук»

сформируем вопрос «Отсутствует звук?» и т.д. В базе данных предусмотрим поле для

ввода ответов. Если ответ на вопрос положительный (да), то весовой фактор

соответствующего атрибута сохраняется. Если ответ отрицательный (нет), весовой фактор

берется равным нулю.

2. Предположим, для конкретного телевизора получили такой вариант заполнения

БД (таблица 2).

Таблица 2 – Варианты вопросов

№ Вид неисправности Порядковый номер вопроса

ВопросОТСУТСТВУЮТ:

Ответ Весовой фактор

атрибута1 Сгорел

предохранитель1.1 Звук? Да 51.2 Изображение? Да 51.3 Световое заполнение экрана? Нет 30

Общий весовой фактор неисправности 1 52 Неисправна антенна 2.1 Звук? Да 20

2.2 Изображение? Да 202.3 Световое заполнение экрана? Нет 0

Общий весовой фактор неисправности 2 403 Неисправен

кинескоп3.1 Звук? Да 03.2 Изображение? Да 203.3 Световое заполнение экрана? Нет 103.4 Цвет? Да 10

Общий весовой фактор неисправности 3 30

Для тестового варианта заполнения БД подсчитаем сумму баллов, которые набрала

каждая из неисправностей:

1. Предохранитель: ВФ1=5+5+0=10

2. Антенна: ВФ2=20+20+0=40

3. Кинескоп: ВФ3=0+20+0+10=30

Анализируя полученные результаты, можно сделать вывод, что для данного

варианта ответов, максимальный весовой фактор имеет вариант неисправность

«Неисправна антенна». Следовательно, можно принять решение предварительной

диагностики неисправности этого телевизора: «наиболее вероятно, что неисправна

антенна».

Разрабатываемая система принятия решения должна использоваться многократно

для анализа различных вариантов неисправностей и предусматривать возможность

многократного обновления БД (т.е. для каждого телевизора создается своя БД).

199

При проектировании экспертных систем предварительно составляется алгоритм

принятия решения. Обычно его называют деревом решения (из теории графов).

3. Реализация системы принятия решения в электронной таблице (ЭТ)

Для ее реализации необходимо выполнить следующие действия:

Создайте приведенную выше электронную таблицу самостоятельно. Учтите,

что при вводе новых ответов результат принятия решения должен автоматически

пересчитываться!

Пример 2.

ТЕОРИЯ ИГР изучает задачи, основной целью которых является выбор

оптимальной стратегии для игрока, исходя из некоторых начальных условий. Критерием

при этом может служить наибольшая прибыль, наименьшие затраты и т.п. Обычно игрок

200

располагает некоторым запасом возможных стратегий, каждая из которых сулит

определенный выигрыш, но может не оправдаться и привести к проигрышу.

Разновидность игр – «ИГРЫ С ПРИРОДОЙ». В этих играх в стратегию игрока

вмешиваются независящие от его воли факторы (погода, поломки оборудования и т.п.).

Вероятность наступления каждого из состояний природы известна, и стратегию

приходится определять с учетом этих вероятностей.

Сельскохозяйственное предприятие может реализовать свою продукцию:

- сразу после уборки (стратегия А1);

- в зимние месяцы (стратегия А2);

- в весенние месяцы (стратегия А3).

Прибыль зависит от состояния рынка (S1, S2 или S3), вероятность состояния рынка

обозначена P. Размер прибыли (Х), ожидаемой в зависимости от выбранной стратегии и

состояния рынка, представлен в таблице (млн. руб.):

S1 S2 S3

A1 2 -3 7A2 -1 5 4A3 -7 13 -3P 0,2 0,5 0,3

Определить наиболее выгодную стратегию продажи продукции.

Для определения оптимальной стратегии существует много критериев.

Критерий №1: критерий Байеса (максимального математического ожидания).

По этому критерию рассчитывается величина вероятной прибыли для каждой

стратегии:

W 1=X11 ∙ P1+X12 ∙ P2+X13 ∙ P3=2∙ 0,2+(−3 ) ∙ 0,5+7 ∙0,3=1 , 0

W 2=X21 ∙ P1+ X22 ∙ P2+ X23 ∙ P3=(−1 ) ∙ 0,2+5∙ 0,5+4 ∙ 0,3=3 , 5

W 3=X31 ∙ P1+ X32 ∙ P2+ X33 ∙ P3=(−7 ) ∙ 0,2+13 ∙0,5+ (−3 ) ∙0,3=4 ,2

и выбирается максимальная вероятная прибыль: W max=W 3.

ВЫВОД: по критерию Байеса оптимальной является стратегия А3.

Критерий №2: критерий Лапласа (недостаточного основания).

По этому критерию рассчитывается средняя прибыль по каждой стратегии:

W 1=2−3+7

3=2,0 W 2=

−1+5+43

≈ 2,7 W 3=−7+13−3

3=1,0

и выбирается максимальная прибыль: W max=W 2.

ВЫВОД: по критерию Лапласа оптимальной является стратегия А2.

Критерий №3: максиминный критерий Вальда.

201

По этому критерию в каждой стратегии выбирается наименьшая прибыль:

W min 1=−3 ;W min 2=−1 ;W min3=−7

и выбирается наибольшее из полученных значений: W max=W min2.

ВЫВОД: по критерию Вальда оптимальной является стратегия А2.

Критерий №4: критерий пессимизма-оптимизма Гурвица.

По этому критерию определяется прибыль с учетом «коэффициента пессимизма».

Пусть в данных условиях этот коэффициент равен: С = 0,4.

W 1=C ∙W min1+(1−C ) ∙ W max 1=0,4 ∙ (−3 )+(1−0,4 ) ∙7=3,0

W 2=C ∙W min2+(1−C ) ∙W max 2=0,4 ∙ (−1 )+(1−0,4 ) ∙5=2,6

W 3=C ∙W min3+(1−C ) ∙W max3=0,4 ∙ (−7 )+ (1−0,4 ) ∙13=5,0


ВЫВОД: по критерию пессимизма-оптимизма оптимальной является стратегия А3.

Критерий №5: критерий Ходжа-Лемана.

По этому критерию рассчитывается прибыль с учетом коэффициента

достоверности информации о состоянии рынка.

Пусть в данных условиях этот коэффициент равен: U = 0,6.

W 1=U ∙ ( X11 ∙ P1+ X12 ∙ P2+ X13 ∙ P3 )+(1−U ) ∙ W min 1=0,6 ∙1,0+0,4 ∙ (−3 )=−0,60

W 2=U ∙ ( X 21 ∙P1+X 22 ∙ P2+X 23 ∙ P3 )+ (1−U ) ∙W min2=0,6 ∙3,5+0,4 ∙ (−1 )=1,70

W 3=U ∙ ( X 31 ∙P1+X 32 ∙ P2+X33 ∙ P3 )+ (1−U ) ∙W min3=0,6 ∙ 4,2+0,4 ∙ (−7 )=−0,28


ВЫВОД: по критерию Ходжа-Лемана оптимальной является стратегия А2.

Критерий №6: критерий минимаксного риска Сэвиджа.

По этому критерию сначала составляется матрица рисков. В каждом столбце

находим максимальный элемент и вычитаем из него все элементы столбца. В каждой

строке полученной матрицы рисков определяем максимальный элемент.

Исходная матрицаS1 S2 S3

A1 2 -3 7A2 -1 5 4A3 -7 13 -3

* В исходной матрице жирным шрифтом выделены максимальные элементы

каждого столбца, из которых нужно вычесть все остальные.

Матрица рисковS1 S2 S3

A1 0 16 0

202

A2 3 8 3A3 9 0 10

* При вычитании элемента из самого себя получается 0, поэтому на месте

максимальных элементов в матрице рисков будут нули. Жирным шрифтом выделены

максимальные риски в каждой строке.

Выбираем минимальный из всех выделенных рисков: это 8 (стратегия А2).

ВЫВОД: по критерию Сэвиджа оптимальной является стратегия А2.

Составим сводную таблицу результатов:

Критерий Оптимальная стратегия1. Критерий Байеса А3

2. Критерий Лапласа А2

3. Критерий Вальда А2

4. Критерий Гурвица А3

5. Критерий Ходжа-Лемана А2

6. Критерий Сэвиджа А2

ОБЩИЙ ВЫВОД: оптимальной стратегией продаж является стратегия А2 –

продавать в зимние месяцы (по 4-м критериям из 6-ти).

Задания для самостоятельной работы:

1. Разработать систему принятия решения для оценки целесообразности

повторной эмиссии акций предприятия.

Таблица 3 – База знаний

Факт Атрибут Весовой фактор1. Курс акций предприятия Повышается 25

Стабильно высокий 25Понижается 25Стабильно низкий 25

2. Спрос на продукцию предприятия

Повышается 20Стабильно высокий 20Средний 20Понижается 20Стабильно низкий 20

3. Спрос на аналогичную продукцию других предприятий

Повышается 20Стабильно высокий 20Средний 20Понижается 20Стабильно низкий 20

4. Состояние производственных фондов предприятия

Используются современные технологии 25Оборудование в хорошем состоянии 25Используются устаревшие технологии 25Оборудование устарело 25

203

Если суммарный весовой фактор ниже 80, то нет смысла в эмиссии акций.

Если суммарный весовой фактор 81-90, то есть смысл в небольшой эмиссии акций.

Если суммарный весовой фактор 91-100 и при этом общий весовой фактор раздела

4 ниже 35, то есть смысл в эмиссии акций среднего размера при условии улучшения

состояния производственного фонда.

Если суммарный весовой фактор выше 100 и при этом общий весовой фактор

раздела 4 выше 35, то есть смысл в эмиссии акций крупного размера.

2. Оборудование предприятия после нескольких лет работы может оказаться в

одном из трех состояний:

В1 – оборудование вполне работоспособно и требует лишь небольшого текущего

ремонта;

В2 – требуется серьезный капитальный ремонт;

В3 – дальнейшая эксплуатация оборудования невозможна.

Вероятности этих событий: Q1, Q2 и Q3 соответственно. Для предприятия возможны

стратегии:

А1 – оставить оборудование в работе еще на год, проведя незначительный ремонт;

А2 – провести капитальный ремонт;

А3 – заменить оборудование.

Прибыль, которую получит предприятие при различных стратегиях, дана в

таблице:

В1 В2 В3

А1 X11 X12 X13

А2 X21 X22 X23

А3 X31 X32 X33

Q Q1 Q2 Q3

Коэффициент пессимизма равен 0,4.

Коэффициент достоверности информации равен 0,6.

Выберите и обоснуйте оптимальную стратегию предприятия в данном случае.

204

Вариант 1 2 3 4 5 6 7 8 9 10X11 7 -2 0 10 11 3 0 7 -2 5X12 -2 11 3 4 14 13 -6 -6 11 11X13 14 3 9 14 3 14 10 8 -5 -2X21 0 1 -3 -1 11 -9 5 7 9 2X22 12 14 11 5 0 -6 4 -6 0 -9X23 12 2 -1 -6 2 6 -1 -7 -9 -6X31 3 1 14 6 -4 1 8 1 3 0X32 -5 5 10 2 -2 -6 0 4 13 3X33 13 -5 -5 -7 -9 15 1 9 4 -9Q1 0,33 0,41 0,23 0,37 0,28 0,32 0,30 0,10 0,32 0,19Q2 0,41 0,40 0,14 0,06 0,15 0,28 0,50 0,09 0,09 0,05Q3 0,26 0,19 0,63 0,57 0,57 0,40 0,20 0,81 0,59 0,76


205

РАЗРАБОТКА SADT-ДИАГРАММЫ

Цель работы: приобретение навыков функционального моделирования и

разработки диаграмм SADT в нотации IDEF0.


Методология SADT разработана Дугласом Россом. Методология SADT

представляет собой совокупность методов, правил и процедур, предназначенных для

построения структурно-функциональной модели объекта какой-либо предметной области.

Широко используется в проектировании бизнес-процессов, технических объектов,

организационных систем и т.д. Претендует на роль обязательного инструментального

средства создания любых проектов на ранних стадиях. Позволяет обеспечивать передачу

моделей в системы более позднего проектирования.

Функциональная модель SADT отображает функциональную структуру объекта,

т.е. производимые им действия и связи между этими действиями. Основные элементы

этой методологии основываются на следующих концепциях:

1) Графическое представление блочного моделирования.

Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а

интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и

выходящими из него. Взаимодействие блоков друг с другом описываются посредством

интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют,

когда и каким образом функции выполняются и управляются.

2) Строгость и точность.

Выполнение правил SADT требует достаточной строгости и точности, не

накладывая в то же время чрезмерных ограничений на действия аналитика. Правила

SADT включают:

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6

блоков, ограничение когнитивной сложности, т.к. человек при большем количестве

факторов начинает их интуитивно делить на группы);

- связность диаграмм (композиция в нумерации блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных).

- отделение организации от функции, т.е. исключение влияния организационной

структуры на функциональную модель.

206

Методология SADT может использоваться для моделирования широкого круга

систем и определения требований и функций, а затем для разработки системы, которая

удовлетворяет этим требованиям и реализует эти функции. Для уже существующих

систем SADT может использоваться для анализа функций, выполняемых системой, а

также для указания механизмов, посредством которых они осуществляются. Является

удобным механизмом построения структурных моделей в САПР.

Состав функциональной модели.

Результатом применения методологии SADT является модель, которая состоит из

диаграмм (схем), фрагментов текстов и глоссария, имеющих ссылки друг на друга.

Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них

представлены как блоки и дуги.

Место соединения дуги с блоком определяет тип интерфейса.

Управляющая информация входит в блок сверху.

Информация, которая подвергается обработке (входная), показана с левой стороны

блока.

Результаты (выход) показаны с правой стороны блока.

Механизм (человек или автоматизированная система), который осуществляет

операцию, представляется дугой, входящей в блок снизу. Механизм может быть

человеком, компьютером или любым другим устройством, которое помогает выполнять

данную функцию:

Пример функционального блока:

207

Одной из наиболее важных особенностей методологии SADT является постепенное

введение все больших уровней детализации по мере создания диаграмм, отображающих

модель. На рисунке ниже приведены четыре диаграммы и их взаимосвязи, показана

структура SADT-модели. Каждый компонент модели может быть декомпозирован на

другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на

родительской диаграмме:

Иерархия диаграмм.

Построение SADT-модели начинается с представления всей системы в виде

простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями

вне системы. Поскольку единственный блок представляет всю систему как единое целое,

имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также

представляют полный набор внешних интерфейсов системы в целом.

Затем блок, который представляет систему в качестве единого модуля,

детализируется на другой диаграмме с помощью нескольких блоков, соединенных

интерфейсными дугами.

208

Во всех случаях каждая подфункция может содержать только те элементы, которые

входят в исходную функцию. Кроме того, модель не может опустить какие-либо

элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают

контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.

Другое название SADT – система для передачи понимания.

Модель SADT представляет собой серию диаграмм с сопроводительной

документацией, разбивающих сложный объект на составные части, которые представлены

в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других

диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей

диаграммы. На каждом шаге декомпозиции более общая диаграмма называется

родительской для более детальной диаграммы.

Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня,

являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и

выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть

системы.

Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть

далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее

детализирована с помощью необходимого числа диаграмм. Таким путем формируется

иерархия диаграмм.

Для того чтобы указать положение любой диаграммы или блока в иерархии,

используются номера диаграмм. Например, А21 является диаграммой, которая

детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме

А0, которая является самой верхней диаграммой модели. На рисунке ниже показано

типичное дерево диаграмм:

209

Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же

один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам,

управлениям и выходам родительского блока. Источник или получатель этих

пограничных дуг может быть обнаружен только на родительской диаграмме.

Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все

граничные дуги должны продолжаться на родительской диаграмме, чтобы она была

полной и непротиворечивой.

Типы связей между функциями.

На SADT-диаграммах явно не указаны ни последовательность, ни время. Однако,

обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени)

функции могут быть изображены с помощью дуг. Различают семь типов связывания.

Тип случайной связности.

Связь между функциями мала или полностью отсутствует.

Тип логической связности.

Данные и функции попадают в общий класс или набор элементов, но

функциональных отношений между ними нет.

Тип временной связности.

210

Функции связанны во времени, когда их данные используются одновременно или

функции включаются параллельно, а не последовательно.

Тип процедурной связности.

Функции выполняются в течение одной и той же части цикла или процесса:

Тип коммуникационной связности.

Блоки используют одни и те же входные данные и/или производят одни и те же

выходные данные:

Тип последовательной связности.

Выход одной функции служит входными данными для следующей функции.

Моделирует причинно-следственные зависимости.

Тип функциональной связности.

Отражает наличие полной зависимости одной функции от другой.

211

Функциональная связь в математических терминах может иметь вид:

C = g(B) = g(f(A))

Процесс моделирования в SADT.

Процесс моделирования в SADT является итеративной последовательностью

шагов, приводящих к точному описанию системы.

Высокая эффективность SADT обусловлена разделением функций, выполняемых

участниками создания SADT-проектов:

- эксперты являются источниками информации,

- авторы создают диаграммы и модели,

- библиотекарь координирует обмен письменной информацией,

- читатели рецензируют и утверждают модели,

- комитет технического контроля принимает и утверждает модель.

212

Типы и назначения диаграмм в SADT.

В настоящее время существуют различные типы диаграмм SADT, отличающиеся

назначением. Можно назвать IDEF0, IDEF1, IDEFX, IDEF3 и т.д.


1. Разработать функциональную модель (диаграмму SADT) уровня А0 для

предметной области:

1. Покупка в ювелирном магазине.

2. Учет жилищного фонда.

3. Учету стройматериалов.

213

4. Расчет сырья промышленного предприятия (поставщики, тип сырья,

закупка, фирма-перевозчик, сумма, необходимая для закупки сырья).

5. Расчет прибыли от выполняемых работ по ремонту офисов

многофилиального концерна (с учетом налоговых выплат).

6. Расчет себестоимости изделия (вывод списка деталей, используемых в

данном изделии, расчет суммарной стоимости всех деталей, используемых в

данном изделии).

7. Определение затрат рабочего времени на выполнение строительных

работ.

8. Определение величины таможенных сборов на базе контрактов

коммерческой фирмы.

9. Платный прием в поликлинике.

10. Прокат автомобилей.

11. Оптовая торговля товарами повседневного спроса.

12. Учет нарушений ПДД.

13. Оформление путевки через туристическое агентство.

14. Учет подписки на печатные издания.

15. Учет сделок с недвижимостью.

16. Учет договоров страхования.

17. Штатное расписание.

18. Учет результатов сессии.

19. Ремонт станков.

20. Управление грузовыми перевозками.

21. Продажа железнодорожных билетов.

2. Произвести декомпозицию построенной диаграммы до уровня А1 и

построить декомпозиционную диаграмму.


РАЗРАБОТКА DFD-ДИАГРАММЫ

Цель работы: приобретение навыков построения диаграмм потоков данных (DFD).


Общие особенности методологии DFD.

214

Диаграммы потоков данных (Data Flow Diagramming) являются основным

средством моделирования функциональных требований к проектируемой системе.

Требования представляются в виде иерархии процессов, связанных потоками данных.

Целью методологии является построение модели рассматриваемой системы в виде

диаграммы потоков данных (Data Flow Diagram – DFD). Диаграммы потоков данных

предназначены прежде всего для описания документооборота и обработки информации,

хотя допускают и представление других объектов.

В соответствии с методологией модель системы определяется как иерархия

диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс

преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы

верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или

подсистемы ИС с внешними входами и выходами. Они детализируются при помощи

диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую

иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на

котором процесс становятся элементарными и детализировать их далее невозможно.

Источники информации (внешние сущности) порождают информационные потоки

(потоки данных), переносящие информацию к подсистемам или процессам. Те в свою

очередь преобразуют информацию и порождают новые потоки, которые переносят

информацию к другим процессам или подсистемам, накопителям данных или внешним

сущностям - потребителям информации. Таким образом, основными компонентами

диаграмм потоков данных являются:

- внешние сущности;

- системы/подсистемы;

- процессы;

- накопители данных;

- потоки данных.

Основные отличия DFD от IDEF0:

1. В IDEF0 система рассматривается как взаимосвязанные работы, DFD

рассматривает систему как совокупность предметов.

2. Стрелки IDEF0 представляют собой жесткие взаимосвязи, а стрелки DFD

показывают, как объекты (включая данные) двигаются от одной работы к другой. Это

представление потоков совместно с хранилищами данных и внешними сущностями делает

модели DFD более похожими на физические характеристики системы – движение

объектов, хранение объектов, поставка и распространение объектов.

215

3. В DFD каждая сторона работы не имеет четкого назначения, как в IDEF0,

стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD

также применяются двунаправленные стрелки для описания диалогов типа "команда –

ответ" между работами, между работой и внешней сущностью и между внешними

сущностями.

В методологии DFD используются две нотации: Йодана-Де Марко (Yourdan) и

Гейна-Сарсона (Gane-Sarson).

Рисунок 1 – Элементы методологии DFD

в нотациях Гейна-Сарсона и Йодана-Де Марко

Программы BPWin и Ramus, в которых строятся DFD-диаграммы, поддерживают

нотацию Гейна-Сарсона. В этих программах DFD-диаграммы ограничены: например, в

них отсутствует описание миниспецификаций, присущих диаграммам DFD.

В основе методологии Gane/Sarson лежит построение модели анализируемой

информационной системы (ИС) – проектируемой или реально существующей.

Внешние сущности.

216

Внешняя сущность представляет собой материальный предмет или физическое

лицо, представляющее собой источник или приемник информации, например, заказчики,

персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в

качестве внешней сущности указывает на то, что она находится за пределами границ

анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть

перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот,

часть процессов ИС может быть вынесена за пределы диаграммы и представлена как

внешняя сущность.

Внешняя сущность обозначается квадратом (рисунок 2), расположенным как бы

"над" диаграммой и бросающим на нее тень:

Рисунок 2 – Внешняя сущность

Системы и подсистемы.

При построении модели сложной ИС она может быть представлена в самом общем

виде на так называемой контекстной диаграмме в виде одной системы как единого целого,

либо может быть декомпозирована на ряд подсистем.

Подсистема (или система) на контекстной диаграмме изображается следующим

образом (рисунок 3).

Рисунок 3 – Подсистема

Номер подсистемы служит для ее идентификации. В поле имени вводится

наименование подсистемы в виде предложения с подлежащим и соответствующими

определениями и дополнениями.

Процессы.

Процесс представляет собой преобразование входных потоков данных в выходные

в соответствии с определенным алгоритмом. Физически процесс может быть реализован

217

различными способами: это может быть подразделение организации (отдел),

выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно

реализованное логическое устройство и т.д.

Процесс на диаграмме потоков данных изображается, как показано на рисунке 4.

Рисунок 4 – Процесс

Номер процесса служит для его идентификации. В поле имени вводится

наименование процесса в виде предложения с активным недвусмысленным глаголом в

неопределенной форме (вычислить, рассчитать, проверить, определить, создать,

получить), за которым следуют существительные в винительном падеже, например:

- «Ввести сведения о клиентах»;

- «Выдать информацию о текущих расходах»;

- «Проверить кредитоспособность клиента».

Использование таких глаголов, как «обработать», «модернизировать» или

«отредактировать» означает, как правило, недостаточно глубокое понимание данного

процесса и требует дальнейшего анализа.

Информация в поле физической реализации показывает, какое подразделение

организации, программа или аппаратное устройство выполняет данный процесс.

Накопители данных.

Накопитель данных представляет собой абстрактное устройство для хранения

информации, которую можно в любой момент поместить в накопитель и через некоторое

время извлечь, причем способы помещения и извлечения могут быть любыми.

Накопитель данных может быть реализован физически в виде микрофиши, ящика в

картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д.

Накопитель данных на диаграмме потоков данных изображается, как показано на

рисунке 5.

Рисунок 5 – Накопитель данных

218

Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя

накопителя выбирается из соображения наибольшей информативности для

проектировщика.

Накопитель данных в общем случае является прообразом будущей базы данных и

описание хранящихся в нем данных должно быть увязано с информационной моделью.

Потоки данных.

Поток данных определяет информацию, передаваемую через некоторое соединение

от источника к приемнику. Реальный поток данных может быть информацией,

передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами,

магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.

Поток данных на диаграмме изображается линией, оканчивающейся стрелкой,

которая показывает направление потока (рисунок 6). Каждый поток данных имеет имя,

отражающее его содержание.

Рисунок 6 – Поток данных

Построение иерархии диаграмм потоков данных.

Первым шагом при построении иерархии диаграмм потоков данных (ДПД)

является построение контекстных диаграмм. Обычно при проектировании относительно

простых ИС строится единственная контекстная диаграмма со звездообразной

топологией, в центре которой находится так называемый главный процесс, соединенный с

приемниками и источниками информации, посредством которых с системой

взаимодействуют пользователи и другие внешние системы.

Если же для сложной системы ограничиться единственной контекстной

диаграммой, то она будет содержать слишком большое количество источников и

приемников информации, которые трудно расположить на листе бумаги нормального

формата, и кроме того, единственный главный процесс не раскрывает структуры

распределенной системы. Признаками сложности (в смысле контекста) могут быть:

- наличие большого количества внешних сущностей (десять и более);

219

- распределенная природа системы;

- многофункциональность системы с уже сложившейся или выявленной

группировкой функций в отдельные подсистемы.

Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная

диаграмма верхнего уровня содержит не единственный главный процесс, а набор

подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня

детализируют контекст и структуру подсистем.

Иерархия контекстных диаграмм определяет взаимодействие основных

функциональных подсистем проектируемой ИС как между собой, так и с внешними

входными и выходными потоками данных и внешними объектами (источниками и

приемниками информации), с которыми взаимодействует ИС.

Разработка контекстных диаграмм решает проблему строгого определения

функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно

важно для сложных многофункциональных систем, в разработке которых участвуют

разные организации и коллективы разработчиков.

После построения контекстных диаграмм полученную модель следует проверить

на полноту исходных данных об объектах системы и изолированность объектов

(отсутствие информационных связей с другими объектами).

Для каждой подсистемы, присутствующей на контекстных диаграммах,

выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь,

может быть детализирован при помощи ДПД или миниспецификации. При детализации

должны выполняться следующие правила:

- правило балансировки - означает, что при детализации подсистемы или процесса

детализирующая диаграмма в качестве внешних источников/приемников данных может

иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители

данных), с которыми имеет информационную связь детализируемая подсистема или

процесс на родительской диаграмме;

- правило нумерации - означает, что при детализации процессов должна

поддерживаться их иерархическая нумерация. Например, процессы, детализирующие

процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

Миниспецификация (описание логики процесса) должна формулировать его

основные функции таким образом, чтобы в дальнейшем специалист, выполняющий

реализацию проекта, смог выполнить их или разработать соответствующую программу.

220

Миниспецификация является конечной вершиной иерархии ДПД. Решение о

завершении детализации процесса и использовании миниспецификации принимается

аналитиком исходя из следующих критериев:

- наличия у процесса относительно небольшого количества входных и выходных

потоков данных (2-3 потока);

- возможности описания преобразования данных процессом в виде

последовательного алгоритма;

- выполнения процессом единственной логической функции преобразования

входной информации в выходную;

- возможности описания логики процесса при помощи миниспецификации

небольшого объема (не более 20-30 строк).

При построении иерархии ДПД переходить к детализации процессов следует

только после определения содержания всех потоков и накопителей данных, которое

описывается при помощи структур данных. Структуры данных конструируются из

элементов данных и могут содержать альтернативы, условные вхождения и итерации.

Условное вхождение означает, что данный компонент может отсутствовать в

структуре.

Альтернатива означает, что в структуру может входить один из перечисленных

элементов.

Итерация означает вхождение любого числа элементов в указанном диапазоне. Для

каждого элемента данных может указываться его тип (непрерывные или дискретные

данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.),

диапазон значений, точность представления и форма физического кодирования. Для

дискретных данных может указываться таблица допустимых значений.

После построения законченной модели системы ее необходимо верифицировать

(проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы,

процессы, потоки данных) должны быть подробно описаны и детализированы.

Выявленные недетализированные объекты следует детализировать, вернувшись на

предыдущие шаги разработки. В согласованной модели для всех потоков данных и

накопителей данных должно выполняться правило сохранения информации: все

поступающие куда-либо данные должны быть считаны, а все считываемые данные

должны быть записаны.

Пример построения диаграммы DFD.

Как уже говорилось ранее, диаграммы потоков данных являются основным

средством моделирования функциональных требований к проектируемой системе.

221

Функциональные требования к системе определяют, действия системы, которые

она должна выполнять.

В качестве примера процесса, для которого будет строиться диаграмма DFD, как и

в случае с IDEF0, будет взят процесс написания курсовой работы (КР).

Пусть системой будут пользоваться студент и преподаватель.

Тогда можно выделись следующие функциональные требования, связанные с

написанием курсовой работы:

1. Система должна хранить переработанные фрагменты информации, а также

ссылки на литературу, на основе которой они были сделаны.

2. Система должна хранить замечания преподавателя по КР.

Далее нужно рассмотреть требования к источникам данных, связанные с

функциональными требованиями, то есть определить, какие действия над базой данных

нужно делать для выполнения требований, какие процессы изменяют базу данных и

взаимодействуют с внешними объектами.

Требования к источникам данных будут следующими:

1. В процессе анализа литературы происходит чтение и запись информации о

литературе и переработанным фрагментам в базу данных. Также в процессе изучения

литературы студент получает и использует знания, связанные с литературой (Обмен

информацией).

2. В процессе написания курсовой работы происходит чтение информации о

замечаниях преподавателя из базы данных. В процессе проверки КР происходит запись

замечаний в базу.

В процессе написания курсовой работы студент использует практические навыки

написания курсовой работы (Обмен информацией).

В процессе проверки КР преподаватель выявляет (вырабатывает) информацию об

ошибках.

Далее можно реализовать все вышесказанное в виде диаграммы DFD.

Для именования внешних сущностей и хранилищ были созданы следующие

классификаторы:

1. студент,

2. преподаватель,

3. литература,

4. переработанный материал,

5. замечания преподавателя.

222

Диаграмма DFD строилась «с нуля» с использованием декомпозиции. На

контекстной диаграмме отображен основной процесс «Работать над КР», а также все

внешние сущности и хранилища. Обмен информацией происходит по требованиям к

источникам данных, но в обобщенном виде.

Рисунок 7 – Контекстная диаграмма процесса «Работать над КР»

Далее процесс «Работать над КР» был детализирован на три подпроцесса, которые

фигурируют в требованиях к источникам данных: проанализировать литературу, написать

КР, проверить КР.

223

Рисунок 8 – Детализация процесса «Работать над КР»

Обмен информацией на схеме происходит по требованиям к источником данных,

но с дополнениями: поток данных «Материал по тематике КР» является результатом

анализа литературы и входными данными для процесса «Написать КР», а поток данных

«Черновик КР» является результатом написания КР и входными данными для процесса

проверки КР.


Реализуйте схему DFD для поддержки процесса:

1. Подготовка к Олимпийским играм

2. Выпуск автомобиля

3. Выпуск DVD-плейера

4. Проведение лабораторной работы

5. Построение здания

6. Сборка персонального компьютера

7. Переналадка технологического оборудования

8. Подготовка конструкторской документации

9. Получение прав на управление транспортным средством

10. Организация переезда в новую квартиру

224


РАЗРАБОТКА ER-ДИАГРАММЫ

Цель работы: приобретение навыков построения диаграмм «сущность-связь»

(ERD).


Назначение ER-модели.

Прежде чем приступать к созданию системы автоматизированной обработки

информации, разработчик должен сформировать понятия о предметах, фактах и событиях,

которыми будет оперировать данная система. Для того чтобы привести эти понятия к той

или иной модели данных, необходимо заменить их информационными представлениями.

Одним из наиболее удобных инструментов унифицированного представления данных,

независимого от реализующего его программного обеспечения, является модель

"сущность-связь" (entity-relationship model, ER-model).

Модель "сущность-связь" основывается на некой важной семантической

информации о реальном мире и предназначена для логического представления данных.

Она определяет значения данных в контексте их взаимосвязи с другими данными.

Важным для нас является тот факт, что из модели "сущность-связь" могут быть

порождены все существующие модели данных (иерархическая, сетевая, реляционная,

объектная), поэтому она является наиболее общей.

Отметим, что модель "сущность-связь" не определяет операций над данными и

ограничивается описанием только их логической структуры.

Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом.

Элементы ER-модели.

Любой фрагмент предметной области может быть представлен как множество

сущностей, между которыми существует некоторое множество связей. Дадим

определения:

Сущность (entity) - это объект, который может быть идентифицирован неким

способом, отличающим его от других объектов. Примеры: конкретный человек,

предприятие, событие и т.д.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих

одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы

сущностей не обязательно должны быть непересекающимися. Например, сущность,

принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

225

Сущность фактически представляет из себя множество атрибутов, которые

описывают свойства всех членов данного набора сущностей.

Пример: рассмотрим множество работников некого предприятия. Каждого из них

можно описать с помощью характеристик табельный номер, имя, возраст. Поэтому,

сущность СОТРУДНИК имеет атрибуты ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ.

В дальнейшем для определения сущности и ее атрибутов будем использовать

обозначение вида

СОТРУДНИК (ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ).

Например отделы, на которые подразделяется предприятие, и в которых работают

сотрудники, можно описать как ОТДЕЛ (НОМЕР_ОТДЕЛА, НАИМЕНОВАНИЕ).

Множество значений (область определения) атрибута называется доменом.

Например, для атрибута ВОЗРАСТ домен (назовем его ЧИСЛО_ЛЕТ) задается

интервалом целых чисел больших нуля, поскольку людей с отрицательным возрастом не

бывает.

П. Чен определяет атрибут как функцию, отображающую набор сущностей в

набор значений или в декартово произведение наборов значений. Так, атрибут ВОЗРАСТ

производит отображение в набор значений (домен) ЧИСЛО_ЛЕТ. Атрибут ИМЯ

производит отображение в декартово произведение наборов значений ИМЯ, ФАМИЛИЯ и

ОТЧЕСТВО.

Отсюда определяется ключ сущности - группа атрибутов, такая, что отображение

набора сущностей в соответствующую группу наборов значений является

взаимнооднозначным отображением. Другими словами: ключ сущности - это один или

более атрибутов уникально определяющих данную сущность. В нашем примере ключем

сущности СОТРУДНИК является атрибут ТАБЕЛЬНЫЙ_НОМЕР (конечно, только в том

случае, если все табельные номера на предприятии уникальны).

Связь (relationship) - это ассоциация, установленная между несколькими

сущностями. Примеры:

поскольку каждый сотрудник работает в каком-либо отделе, между

сущностями СОТРУДНИК и ОТДЕЛ существует связь "работает в" или ОТДЕЛ-

РАБОТНИК;

так как один из работников отдела является его руководителем, то между

сущностями СОТРУДНИК и ОТДЕЛ имеется связь "руководит" или ОТДЕЛ-

РУКОВОДИТЕЛЬ;

могут существовать и связи между сущностями одного типа, например связь

РОДИТЕЛЬ - ПОТОМОК между двумя сущностями ЧЕЛОВЕК;

226

(В скобках здесь следует отметить, что в методике проектирования данных есть

своеобразное правило хорошего тона, согласно которому сущности обозначаются с

помощью имен существительных, а связи - глагольными формами. Данное правило,

однако, не является обязательным).

К сожалению, не существует общих правил определения, что считать сущностью, а

что связью. В рассмотренном выше примере мы положили, что "руководит" - это связь.

Однако, можно рассматривать сущность "руководитель", которая имеет связи "руководит"

с сущностью "отдел" и "является" с сущностью "сотрудник".

Связь также может иметь атрибуты. Например, для связи ОТДЕЛ-РАБОТНИК

можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ.

Роль сущности в связи - функция, которую выполняет сущность в данной связи.

Например, в связи РОДИТЕЛЬ-ПОТОМОК сущности ЧЕЛОВЕК могут иметь роли

"родитель" и "потомок". Указание ролей в модели "сущность-связь" не является

обязательным и служит для уточнения семантики связи.

Набор связей (relationship set) - это отношение между n (причем n не меньше 2)

сущностями, каждая из которых относится к некоторому набору сущностей.

Пример:

сущности наборы сущностей

e1 принадлежит E1

e2 принадлежит E2

. . .

en принадлежит En

тогда [e1, e2, ..., en] - набор связей R

Хотя, строго говоря, понятия "связь" и "набор связей" различны (первая является

элементом второго), их, тем не менее, очень часто смешивают. Поэтому, мы в дальнейшем

также будем часто пользоваться терминами "связь" имея в виду "набор связей" и

"сущность" имея в виду "набор сущностей".

В случае n=2, т.е. когда связь объединяет две сущности, она называется бинарной.

Доказано, что n-арный набор связей (n>2) всегда можно заменить множеством бинарных,

однако первые лучше отображают семантику предметной области.

То число сущностей, которое может быть ассоциировано через набор связей с

другой сущностью, называют степенью связи. Рассмотрение степеней особенно полезно

для бинарных связей. Могут существовать следующие степени бинарных связей:

227

один к одному (обозначается 1 : 1). Это означает, что в такой связи

сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. В

рассмотренном нами примере это связь "руководит", поскольку в каждом отделе может

быть только один начальник, а сотрудник может руководить только в одном отделе.

Данный факт представлен на следующем рисунке, где прямоугольники обозначают

сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они

соединяются одной линией.

Другой важной характеристикой связи помимо ее степени является класс

принадлежности входящих в нее сущностей или кардинальность связи. Так как в

каждом отделе обязательно должен быть руководитель, то каждой сущности "ОТДЕЛ"

непременно должна соответствовать сущность "СОТРУДНИК". Однако не каждый

сотрудник является руководителем отдела, следовательно, в данной связи не каждая

сущность "СОТРУДНИК" имеет ассоциированную с ней сущность "ОТДЕЛ".

Таким образом, говорят, что сущность "СОТРУДНИК" имеет обязательный класс

принадлежности (этот факт обозначается также указанием интервала числа возможных

вхождений сущности в связь, в данном случае это 1,1), а сущность "ОТДЕЛ" имеет

необязательный класс принадлежности (0,1). Теперь данную связь мы можем описать как

0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 будем обозначать

следующим образом:

один ко многим (1 : n). В данном случае сущности с одной ролью может

соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-

СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но

сотрудник может работать только в одном отделе. Графически степень связи n

отображается "древообразной" линией, так это сделано на следующем рисунке.

228

Данный рисунок дополнительно иллюстрирует тот факт, что между двумя

сущностями может быть определено несколько наборов связей.

Здесь также необходимо учитывать класс принадлежности сущностей. Каждый

сотрудник должен работать в каком-либо отделе, но не каждый отдел (например, вновь

сформированный) должен включать хотя бы одного сотрудника. Поэтому сущность

"ОТДЕЛ" имеет обязательный, а сущность "СОТРУДНИК" необязательный классы

принадлежности. Кардинальность бинарных связей степени n будем обозначать так:

много к одному (n : 1). Эта связь аналогична отображению 1 : n.

Предположим, что рассматриваемое нами предприятие строит свою деятельность на

основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели

"сущность-связь" с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности

КОНТРАКТ (НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК

(НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более

одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет

иметь степень n : 1.

В данном случае, по совершенно очевидным соображениям (каждый контракт

заключен с конкретным заказчиком, а каждый заказчик имеет хотя бы один контракт,

иначе он не был бы таковым), каждая сущность имеет обязательный класс

принадлежности.

229

многие ко многим (n : n). В этом случае каждая из ассоциированных

сущностей может быть представлена любым количеством экземпляров. Пусть на

рассматриваемом нами предприятии для выполнения каждого контракта создается

рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый

сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая

группа должна включать не менее одного сотрудника, то связь между сущностями

СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень n : n.

Если существование сущности x зависит от существования сущности y, то x

называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность"

y - сильной). В качестве примера рассмотрим связь между ранее описанными сущностями

РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая группа создается только после того, как

будет подписан контракт с заказчиком, и прекращает свое существование по выполнению

контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от

сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным

прямоугольником, а ее связь с сильной сущностью линией со стрелкой:

Заметим, что кардинальность связи для сильной сущности всегда будет (1,1). Класс

принадлежности и степень связи для зависимой сущности могут быть любыми.

Предположим, например, что рассматриваемое нами предприятие пользуется

несколькими банковскими кредитами, которые представляются набором сущностей

КРЕДИТ (НОМЕР_ДОГОВОРА,СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому

кредиту должны осуществляться выплаты процентов и платежи в счет его погашения.

Этот факт представляется набором сущностей ПЛАТЕЖ (ДАТА, СУММА) и набором

связей "осуществляется по". В том случае, когда получение запланированного кредита

отменяется, информация о нем должна быть удалена из базы даных. Соответственно,

должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким

образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ.

230

Диаграмма "сущность-связь".

Очень важным свойством модели "сущность-связь" является то, что она может

быть представлена в виде графической схемы. Это значительно облегчает анализ

предметной области. Существует несколько вариантов обозначения элементов диаграммы

"сущность-связь", каждый из которых имеет свои положительные черты. Здесь мы будем

использовать некий гибрид нотаций Чена (обозначение сущностей, связей и атрибутов) и

Мартина (обозначение степеней и кардинальностей связей). В таблице 1 приводится

список используемых здесь обозначений.

Таблица 1

Обозначение ЗначениеНабор независимых сущностей

Набор зависимых сущностей

Атрибут

Ключевой атрибут

Набор связей

Атрибуты с сущностями и сущности со связями соединяются прямыми линиями.

При этом для указания кардинальностей связей используются обозначения, введенные в

предыдущем параграфе.

В процессе построения диаграммы можно выделить несколько очевидных этапов:

1. Идентификация представляющих интерес сущностей и связей.

2. Идентификация семантической информации в наборах связей (например,

является ли некоторый набор связей отображением 1:n).

3. Определение кардинальностей связей.

4. Определение атрибутов и наборов их значений (доменов).

5. Организация данных в виде отношений "сущность-связь".

В качестве примера построим диаграмму, отображающую связь данных для

подсистемы учета персонала предприятия.

231

Выделим интересующие нас сущности и связи:

1. Прежде всего, предприятие состоит из отделов, в которых работают

сотрудники. Оклад каждого сотрудника зависит от занимаемой им должности (инженер,

ведущий инженер, бухгалтер, уборщик и т.д.). Далее предположим, что на нашем

предприятии допускается совместительство должностей, т.е. каждый сотрудник может

иметь более чем одну должность (и работать более чем в одном отделе), причем может

занимать неполную ставку. В то же время, одну и ту же должность могут занимать

одновременно несколько сотрудников. В результате этих рассуждений мы должны ввести

наборы сущностей

o ОТДЕЛ (ИМЯ_ОТДЕЛА),

o СОТРУДНИК (ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ),

o ДОЛЖНОСТЬ (ИМЯ_ДОЛЖНОСТИ, ОКЛАД),

и набор связей РАБОТАЕТ_В с атрибутом ставка между ними. Атрибут ставка

может принимать значения из интервала [0,1] (больше нуля, но меньше или равен

единице), он определяет какую часть должностного оклада получает данный сотрудник.

Как уже отмечалось выше, каждый n-арный набор связей можно заменить

несколькими бинарными наборами. Сейчас как раз представляется удобный случай, чтобы

оценить преимущества каждого из этих способов представления связей.

o Тренарная связь, показанная здесь, безусловно несет более полную

информацию о предметной области. Действительно, она однозначно отображает тот факт,

что оклад сотрудника зависит от его должности, отдела, где он работает, и ставки. Однако

в этом случае возникают некоторые проблемы с определением степени связи. Хотя, как

было сказано, каждый работник может занимать несколько должностей, а в штате

каждого отдела существуют вакансии с различными должностями, тем не менее, класс

принадлежности сущности ДОЛЖНОСТЬ на приведенном рисунке установлен в (1,1). Это

232

объясняется тем, что ДОЛЖНОСТЬ ассоциируется фактически не с сущностями

СОТРУДНИК и ОТДЕЛ, а со связью между ними. Обозначать этот факт предлагается так,

как это показано на следующей диаграмме:

Здесь сущности СОТРУДНИК, ОТДЕЛ и связь РАБОТАЕТ_В аггрегируются в

некую новую абстрактную сущность, которая ассоциируется с сущностью ДОЛЖНОСТЬ

с помощью связи степени n:1.

o Попытаемся отобразить ассоциации сотрудников, отделов и должностей с

помощью бинарных связей.

В этом случае для адекватного описания семантики предметной области

необходимо ввести еще одну сущность ШТАТНАЯ_ЕДИНИЦА, которая фактически

заменяет собой связь РАБОТАЕТ_В в абстрактной сущности и поэтому имеет атрибут

ставка.

233

Переход от n-арной связи через аггрегацию сущностей к набору бинарных связей

можно рассматривать как последовательные этапы одного процесса, который приводит к

однозначному порождению реляционной модели данных. При построении диаграммы

"сущность- связь" можно использовать любой из этих трех способов представления

данных.

2. Перечислим ряд объектов, которые будут полезны при моделировании

данных рассматриваемого предприятия. Им соответствуют следующие сущности:

ЗАКАЗЧИК (ИМЯ_ЗАКАЗЧИКА,АДРЕС)

КОНТРАКТ (НОМЕР,СРОК_НАЧАЛА,СРОК_ОКОНЧАНИЯ,СУММА)

РАБОЧАЯ ГРУППА(ПРОЦЕНТ_ВОЗНАГРАЖДЕНИЯ)

Атрибут "процент_вознаграждения" отражает ту долю стоимости контракта,

которая предназначена для оплаты труда членов соответствующей рабочей группы.

Смысл остальных атрибутов понятен без дополнительных пояснений. Связи между

перечисленными сущностями также описаны в предыдущем параграфе.

Как правило, один из членов рабочей группы является руководителем по

отношению к другим сотрудникам, входящим в ее состав. Для отражения этого факта мы

должны ввести связь "руководит" с кардинальностью 1,1:0,n между сущностями

СОТРУДНИК и РАБОЧАЯ_ГРУППА (сотрудник может руководить в произвольном

числе рабочих групп, но каждая рабочая группа имеет одного и только одного

руководителя).

3. Рассмотрим теперь более внимательно информационный объект "заказчик". На

практике очень часто возникает необходимость различать национальную прнадлежность

юридических лиц, с которыми предприятие вступает в договорные отношения. Это

связано с тем, что для зарубежных фирм необходимо хранить, например, сведения о

валюте, в которой осуществляются расчеты, языке, на котором подписан контракт и т.д. В

свою очередь, для отечественных компаний необходимо иметь сведения об их форме

собственности (частная или государственная), поскольку от этого может зависеть порядок

налогообложения средств, полученных за выполнение работ по контракту.

Таким образом, мы приходим к выводу, что необходимо ввести в рассмотрение еще

два непересекающихся множества ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ (ВАЛЮТА, ЯЗЫК) и

ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ (ФОРМА_СОБСТВЕННОСТИ), объединение

которых составляет полное множество ЗАКАЗЧИК. Ассоциацию между этими объектами

называют отношением наследования или иерархической связью, так как сущности

234

ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ наследуют

атрибуты сущности ЗАКАЗЧИК (ИМЯ_ЗАКАЗЧИКА, АДРЕС). Для того чтобы

определить к какому подмножеству относится конкретная сущность из набора

ЗАКАЗЧИК (и, соответственно, какой набор атрибутов она имеет) необходимо ввести

атрибут "национальная принадлежность", называемый дискриминантом. Этот тип

связи предлагается отображать на диаграмме следующим образом:

Обобщая все проведенные выше рассуждения, получим диаграмму

"сущность-связь", показанную на следующем рисунке.

235

Подумайте:

1. Как изменится диаграмма "сущность - связь" в том случае, если процент

вознаграждения по всем контрактам будет одинаков?

2. Что изменится в диаграмме, если будет запрещено совместительство

должностей, т.е. каждый сотрудник будет иметь право занимать только одну должность со

ставкой 1?

236

Ответы:

1. В первом случае отпадает необходимость в сущности РАБОЧАЯ_ГРУППА.

Все ее связи перейдут к сущности КОНТРАКТ.

2. Во втором случае связь "занимает" не будет иметь атрибутов. При

декомпозиции ее на бинарные связи получим сущность ШТАТНАЯ_ЕДИНИЦА, также не

имеющую атрибутов.

Целостность данных.

Модель "сущность-связь" также полезна для понимания и спецификации

ограничений, направленных на поддержание целостности данных. В модели имеется три

типа ограничений на значения:

1. Ограничения на допустимые значения в наборе значений (домене). Домен

можно трактовать как область определения атрибута, которая может быть задана либо

непрерывным или дискретным интервалом, либо фиксированным списком значений.

2. Ограничения на разрешенные значения для каждого атрибута. Например,

возраст сотрудников может быть ограничен интервалом от 18 до 65 лет.

3. Ограничения на существующие значения в базе данных. Например, сумма

отчислений с зарплаты сотрудника не должна превышать самой зарплаты.

К сожалению, указанные ограничения невозможно представить на диаграмме

"сущность - связь".

Обзор нотаций, используемых при построении диаграмм "сущность-связь".

Нотация Чена.Элемент диаграммы Обозначает

независимая сущность

зависимая сущность

родительская сущность в иерархической связи

Связь

идентифицирующая связь

Атрибут

237

первичный ключ

внешний ключ (понятие внешнего ключа вводится в реляционной модели данных)

многозначный атрибут

получаемый (наследуемый) атрибут в иерархических связях

Связь соединяется с ассоциируемыми сущностями линиями. Возле каждой

сущности на линии, соединяющей ее со связью, цифрами указывается класс

принадлежности. Пример:

Нотация Мартина.Элемент диаграммы Обозначает

независимая сущность


родительская сущность в иерархической связи

Список атрибутов приводится внутри прямоугольника, обозначающего сущность.

Ключевые атрибуты подчеркиваются. Связи изображаются линиями, соединяющими

сущности, вид линии в месте соединения с сущностью определяет кардинальность связи:

238

Обозначение Кардинальностьнет

1,1

0,1

M,N

0,N

1,N

Имя связи указывается на линии ее обозначающей. Пример:

Нотация IDEF1X.

Обозначения сущностей:

Элемент диаграммы Обозначаетнезависимая сущность


Список атрибутов приводится внутри прямоугольника, обозначающего сущность.

Атрибуты, составляющие ключ сущности, группируются в верхней части прямоугольника

и отделяются горизонтальной чертой.

Обозначения связей:

Элемент диаграммы Обозначаетидентифицирующая связь

неидентифицирующая связь

239

Обозначение кардинальности связей:

Элемент диаграммы Обозначает1,1

0,M

0,1

1,M

точно N (N - произвольное число)

Пример:

Кроме того, в IDEF1X вводится понятие “отношение категоризации”, по смыслу

эквивалентное рассмотренной нами иерархической связи. Отношение полной

категоризации (сущности-категории составляют полное множество потомков

родительской сущности) обозначается:

Также может существовать отношение неполной категоризации (сущности-

категории составляют неполное множество потомков общей сущности):

240

Нотация Баркера.

Сущности обозначаются прямоугольниками, внутри которых приводится список

атрибутов. Ключевые атрибуты отмечаются символом # (решетка). Связи обозначаются

линиями с именами, место соединения связи и сущности определяет кардинальность

связи:

Обозначение Кардинальность0,1

1,1

0,N

1,N

Пример:

Для обозначения отношения категоризации вводится элемент "дуга":

241


Постройте ER-диаграмму для следующей предметной области:

1. Магазин «Товары для детей»

2. Автосалон

3. Книжное издательство

4. Рекламное агентство

5. Оптовый склад

6. Фирма, торгующая компьютерами и периферийной техникой

7. Составление расписания учебных занятий в колледже

8. Киностудия

9. Аптека

10. Мастерская по ремонту телевизоров

11. Система маршрутов городского транспорта

242


РАЗРАБОТКА UML-ДИАГРАММ

Цель работы: приобретение навыков построения UML-диаграмм.


Назначение языка UML.

UML - унифицированный язык моделирования. Из этих трех слов главным

является слово "язык".

Язык - система знаков, служащая:

средством человеческого общения и мыслительной деятельности;

способом выражения самосознания личности;

средством хранения и передачи информации.

Язык включает в себя набор знаков (словарь) и правила их употребления и

интерпретации (грамматику).

К этому достаточно исчерпывающему определению нужно добавить, что языки

бывают естественные и искусственные, формальные и неформальные. UML - язык

формальный и искусственный, хотя, как мы увидим далее, этот ярлык к нему не совсем

подходит. Искусственный он потому, что у него имеются авторы, о которых мы еще не

раз упомянем в дальнейшем (в то же время, развитие UML непрерывно продолжается, что

ставит его в один ряд с естественными языками). Формальным его можно назвать,

поскольку имеются правила его употребления (правда, описание UML содержит и явно

неформальные элементы, как мы, опять-таки, позже увидим). Еще один нюанс: UML -

язык графический, что усложняет ситуацию.

При описании формального искусственного языка, как и при описании языков

программирования, как правило, описываются такие его элементы, как:

1) синтаксис, то есть определение правил построения конструкций языка;

2) семантика, то есть определение правил, в соответствии с которыми конструкции

языка приобретают смысловое значение;

3) прагматика, то есть определение правил использования конструкций языка для

достижения нужных нам целей.

Естественно, UML включает все эти элементы, хотя в их описании наблюдаются

отличия от правил, принятых в языках программирования.

Второе слово в фразе, которой расшифровывается аббревиатура UML - слово

"моделирование". UML - это язык моделирования. Причем объектно-ориентированного

моделирования. Слово это весьма многозначно. В английском языке есть целых два слова

243

- modeling и simulation, которые оба переводятся как "моделирование", хотя означают

разные понятия. Modeling подразумевает создание модели, лишь описывающей объект, а

simulation предполагает получение с помощью созданной модели некоторой

дополнительной информации об объекте. UML в первую очередь - язык моделирования

именно в первом смысле, то есть средство построения описательных моделей. Как

средство симулирования его тоже можно использовать, хотя для этой роли он подходит не

так хорошо.

Третье слово в названии UML - слово "унифицированный". Его можно понимать

тоже неоднозначно. В литературе можно встретить описание эры "до UML" как "войны

методов" моделирования, ни один из которых "не дотягивал" до уровня индустриального

стандарта. UML как раз и стал таким единым универсальным стандартом для объектно-

ориентированного моделирования, которое во времена его создания как раз "вошло в

моду". "Единым" языком моделирования UML можно назвать еще и потому, что в его

создании, как мы увидим далее, объединились усилия авторов трех наиболее популярных

методов моделирования (и не только их).

Подводя итоги, кратко можно сказать, что UML - искусственный язык, который

имеет некоторые черты естественного языка, и формальный язык, который имеет черты

неформального. Это звучит не очень понятно, но это действительно так!

Историческая справка.

Откуда взялся The UML? Если говорить коротко, то UML вобрал в себя черты

нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона

(Ivar Jacobson) и многих других.

В не такие уж и далекие 80-е годы было множество различных методологий

моделирования. Каждая из них имела свои достоинства и недостатки, а также свою

нотацию. То смутное время получило название "войны методов". Проблема в том, что

разные люди использовали разные нотации, и для того чтобы понять, что описывает та

или иная диаграмма, зачастую требовался "переводчик". Один и тот же символ мог

означать в разных нотациях абсолютно разные вещи. На рисунке ниже можно увидеть

лишь малую часть многообразия методов, которые существовали в то время и в какой-то

мере повлияли на UML:

244

К тому же примерно в это же время (начало 80-х) стартовала "объектно-

ориентированная эра". Все началось с появлением семейства языков программирования

SmallTalk, которые применяли некоторые понятия языка Simula-67, использовавшегося в

60-х годах. Появление объектно-ориентированного подхода в первую очередь было

обусловлено увеличением сложности задач. Объектно-ориентированный подход внес

достаточно радикальные изменения в сами принципы создания и функционирования

программ, но, в то же время, позволил существенно повысить производительность труда

программистов, по-иному взглянуть на проблемы и методы их решения, сделать

программы более компактными и легко расширяемыми. Как результат, языки,

первоначально ориентированные на традиционный подход к программированию,

получили ряд объектно-ориентированных расширений. Одной из первых, в середине 80-х,

была фирма Apple со своим проектом Object Pascal. Кроме этого, объектно-

ориентированный подход породил мощную волну и абсолютно новых программных

технологий, вершинами которой стали такие общепризнанные сегодня платформы, как

Microsoft .NET Framework и Sun Java.

Но самое главное, что появление ООП требовало удобного инструмента для

моделирования, единой нотации для описания сложных программных систем. И вот "три

245

https://www.intuit.ru/EDI/23_04_17_1/1492899714-28128/tutorial/356/objects/1/files/01_01.gif

амиго", три крупнейших специалиста, три автора наиболее популярных методов решили

объединить свои разработки. В 1991-м каждый из "трех амиго" начал с написания книги, в

которой изложил свой метод ООАП. Каждая методология была по-своему хороша, но

каждая имела и недостатки. Так, метод Буча был хорош в проектировании, но слабоват в

анализе. OMT Румбаха был, наоборот, отличным средством анализа, но плох в

проектировании. И наконец, Objectory Якобсона был действительно хорош с точки зрения

user experience, на который ни метод Буча, ни OMT не обращали особого внимания.

Основной идеей Objectory было то, что анализ должен начинаться с прецедентов, а не с

диаграммы классов, которые должны быть производными от них.

К 1994-му существовало 72 метода, или частные методики. Многие из них

"перекрывались", т.е. использовали похожие идеи, нотации и т.д. Как уже говорилось

выше, чувствовалась острая потребность, "социальный заказ" - закончить "войну методов"

и объединить в одном унифицированном средстве все лучшее, что было создано в области

моделирования.

А что сейчас? The UML живет и развивается. Сейчас мы имеем UML 2.0 и десятки

CASE-средств, поддерживающих UML. Вопреки популярному мнению, в наши дни

Rational не владеет UML, но продолжает работать над ним. UML же принадлежит OMG, а

сама Rational ныне является одним из подразделений IBM и фигурирует во всех

документах как IBM Rational. UML же получил множество пакетов расширений,

называемых профайлами и позволяющих использовать его для моделирования систем из

специфических предметных областей.

Зачем вообще строить какие-то диаграммы?

Разработка модели любой системы (не только программной) всегда предшествует

ее созданию или обновлению. Это необходимо хотя бы для того, чтобы яснее представить

себе решаемую задачу. Продуманные модели очень важны и для взаимодействия внутри

команды разработчиков, и для взаимопонимания с заказчиком. В конце концов, это

позволяет убедиться в "архитектурной согласованности" проекта до того, как он будет

реализован в коде.

Мы строим модели сложных систем, потому что не можем описать их полностью,

"окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной

задачи свойства системы и строим ее модель, отображающую эти свойства. Метод

объектно-ориентированного анализа позволяет описывать реальные сложные системы

наиболее адекватным образом. Но с увеличением сложности систем возникает

потребность в хорошей технологии моделирования. В качестве такой "стандартной"

технологии используется унифицированный язык моделирования (Unified Modeling

246

Language, UML), который является графическим языком для спецификации,

визуализации, проектирования и документирования систем. С помощью UML можно

разработать подробную модель создаваемой системы, отображающую не только ее

концепцию, но и конкретные особенности реализации. В рамках UML-модели все

представления о системе фиксируются в виде специальных графических конструкций,

получивших название диаграмм.

Примечание. Количество типов диаграмм для конкретной модели приложения

никак не ограничивается. Для простых приложений нет необходимости строить

диаграммы всех без исключения типов. Некоторые из них могут просто отсутствовать, и

этот факт не будет считаться ошибкой. Важно понимать, что наличие диаграмм

определенного вида зависит от специфики конкретного проекта.

Почему нужно несколько видов диаграмм?

Для начала определимся с терминологией.

Система - совокупность взаимосвязанных управляемых подсистем, объединенных

общей целью функционирования.

Подсистема - это совокупность элементов, часть из которых задает спецификацию

поведения других элементов. Ян Соммервилл объясняет это понятие таким образом:

Подсистема - это система, функционирование которой не зависит от сервисов

других подсистем. Программная система структурируется в виде совокупности

относительно независимых подсистем. Также определяются взаимодействия между

подсистемами.

Проще говоря, система представляется в виде набора более простых сущностей,

которые относительно самодостаточны. Это можно сравнить с тем, как в процессе

разработки программы мы строим графический интерфейс из стандартных "кубиков" -

визуальных компонентов, или как сам текст программы тоже разбивается на модули,

которые содержат подпрограммы, объединенные по функциональному признаку, и их

можно использовать повторно, в следующих программах.

В процессе проектирования система рассматривается с разных точек зрения с

помощью моделей, различные представления которых предстают в форме диаграмм.

Модель - это некий (материальный или нет) объект, отображающий лишь наиболее

значимые для данной задачи характеристики системы. Модели бывают разные -

материальные и нематериальные, искусственные и естественные, декоративные и

математические.

Приведем несколько примеров. Знакомые всем нам пластмассовые игрушечные

автомобильчики, которыми мы с таким азартом играли в детстве, это не что иное, как

247

материальная искусственная декоративная модель реального автомобиля. Конечно, в

таком "авто" нет двигателя, мы не заполняем его бак бензином, в нем не работает (более

того, вообще отсутствует) коробка передач, но как модель эта игрушка свои функции

вполне выполняет: она дает ребенку представление об автомобиле, поскольку отображает

его характерные черты - наличие четырех колес, кузова, дверей, окон, способность ехать и

т.д.

В ходе медицинских исследований опыты на животных часто предшествуют

клиническим испытаниям медицинских препаратов на людях. В таком случае животное

выступает в роли материальной естественной модели человека.

Или вот такое уравнение:

Это тоже модель, но модель математическая, и описывает она движение

материальной точки под действием силы тяжести.

Осталось лишь сказать, что такое диаграмма.

Диаграмма - это графическое представление множества элементов. Обычно

изображается в виде графа с вершинами (сущностями) и ребрами (отношениями).

Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных

лет блок-схема, и схемы монтажа различного оборудования, которые мы можем видеть в

руководствах пользователя, и дерево файлов и каталогов на диске, и многое-многое

другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок

воспринимается нами легче, чем текст.

Вернемся к проектированию ИС. В этой отрасли с помощью диаграмм можно

визуализировать систему с различных точек зрения. Одна из диаграмм, например,

может описывать взаимодействие пользователя с системой, другая - изменение состояний

системы в процессе ее работы, третья - взаимодействие между собой элементов системы и

т.д. Сложную систему можно и нужно представить в виде набора небольших и почти

независимых моделей-диаграмм, причем ни одна из них не является достаточной для

описания системы и получения полного представления о ней, поскольку каждая из них

фокусируется на каком-то определенном аспекте функционирования системы и выражает

разный уровень абстракции . Другими словами, каждая модель соответствует некоторой

определенной, частной точке зрения на проектируемую систему.

Ни одна отдельная диаграмма не является моделью. Диаграммы - лишь

средство визуализации модели, и эти два понятия следует различать. Лишь набор

248

диаграмм составляет модель системы и наиболее полно ее описывает, но не одна

диаграмма , вырванная из контекста .

Виды диаграмм.

UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы:

4 типа диаграмм представляют статическую структуру приложения;

5 представляют поведенческие аспекты системы;

3 представляют физические аспекты функционирования системы

(диаграммы реализации).

Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка

изменились внешне (появились фреймы и другие визуальные улучшения), немного

усовершенствовалась нотация, некоторые диаграммы получили новые наименования.

Впрочем, точное число канонических диаграмм неважно, так как мы рассмотрим не

все из них, а лишь некоторые - по той причине, что количество типов диаграмм для

конкретной модели конкретного приложения не является строго фиксированным. Для

простых приложений нет необходимости строить все без исключения диаграммы.

Например, для локального приложения не обязательно строить диаграмму развертывания.

Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта

и определяется самим разработчиком. Те, кто желает узнать обо всех диаграммах UML,

может ознакомиться со стандартом UML:

(http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML).

Рассмотрим такие виды диаграмм, как:

диаграмма прецедентов;

диаграмма классов;

диаграмма объектов;

диаграмма последовательностей;

диаграмма взаимодействия;

диаграмма состояний;

диаграмма активности;

диаграмма развертывания.

Диаграмма прецедентов (use case diagram).

Любые (в том числе и программные) системы проектируются с учетом того, что в

процессе своей работы они будут использоваться людьми и/или взаимодействовать с

другими системами. Сущности, с которыми взаимодействует система в процессе своей

работы, называются экторами (actor), причем каждый эктор ожидает, что система будет

вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое

249

http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

определение эктора. Для этого воспользуемся замечательным визуальным словарем по

UML Zicom Mentor:

Эктор (actor) - это множество логически связанных ролей, исполняемых при

взаимодействии с прецедентами или сущностями (система, подсистема или класс).

Эктором может быть человек или другая система, подсистема или класс, которые

представляют нечто вне сущности.

Графически эктор изображается либо "человечком", либо символом класса с

соответствующим стереотипом, как показано на рисунке. Обе формы представления

имеют один и тот же смысл и могут использоваться в диаграммах. "Стереотипированная"

форма чаще применяется для представления системных экторов или в случаях, когда

эктор имеет свойства и их нужно отобразить:

Почему эктор, а не актер? Слово "эктор" немного режет слух русского человека.

Причина же, почему мы говорим именно так, проста - эктор образовано от слова action,

что в переводе означает действие. Дословный же перевод слова "эктор" - действующее

лицо - слишком длинный и неудобный для употребления. Поэтому мы будем и далее

говорить именно так.

Мы говорим о диаграмме прецедентов. Что такое "прецедент"?

Прецедент (use-case) - описание отдельного аспекта поведения системы с точки

зрения пользователя (Буч).

Определение вполне понятное и исчерпывающее, но его можно еще немного

уточнить, воспользовавшись тем же Zicom Mentor 'ом:

Прецедент (use case) - описание множества последовательных событий (включая

варианты), выполняемых системой, которые приводят к наблюдаемому эктором

результату. Прецедент представляет поведение сущности, описывая взаимодействие

между экторами и системой. Прецедент не показывает, "как" достигается некоторый

результат, а только "что" именно выполняется.

Прецеденты обозначаются очень простым образом - в виде эллипса, внутри

которого указано его название. Прецеденты и экторы соединяются с помощью линий.

Часто на одном из концов линии изображают стрелку, причем направлена она к тому, у

250

кого запрашивают сервис, другими словами, чьими услугами пользуются. Это простое

объяснение иллюстрирует понимание прецедентов как сервисов, пропагандируемое

компанией IBM.

Прецедент:

Прецеденты могут включать другие прецеденты, расширяться ими, наследоваться и

т.д.

Приведем пример диаграммы прецедентов, изображающей пользование

библиотекой.

Обратите внимание на примечание, сопоставленное с одним из прецедентов.

Следует заметить, что иногда на диаграммах прецедентов границы системы обозначают

прямоугольником, в верхней части которого может быть указано название системы. Таким

образом, прецеденты - действия, выполняемые системой в ответ на действия эктора, -

помещаются внутри прямоугольника.

251

Приведенная ниже диаграмма прецедентов – обучение в университете.

Из всего сказанного выше становится понятно, что диаграммы прецедентов

относятся к той группе диаграмм, которые представляют динамические или

поведенческие аспекты системы. Это отличное средство для достижения

взаимопонимания между разработчиками, экспертами и конечными пользователями

продукта. Как мы уже могли убедиться, такие диаграммы очень просты для понимания и

могут восприниматься и, что немаловажно, обсуждаться людьми, не являющимися

специалистами в области разработки ПО.

Подводя итоги, можно выделить такие цели создания диаграмм прецедентов:

определение границы и контекста моделируемой предметной области на

ранних этапах проектирования;

формирование общих требований к поведению проектируемой системы;

252

разработка концептуальной модели системы для ее последующей

детализации;

подготовка документации для взаимодействия с заказчиками и

пользователями системы.

Диаграмма классов (class diagram).

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

Классы - это строительные блоки любой объектно-ориентированной системы.

Они представляют собой описание совокупности объектов с общими атрибутами,

операциями, отношениями и семантикой. При проектировании объектно-

ориентированных систем диаграммы классов обязательны.

Классы используются в процессе анализа предметной области для составления

словаря предметной области разрабатываемой системы. Это могут быть как абстрактные

понятия предметной области, так и классы, на которые опирается разработка и которые

описывают программные или аппаратные сущности.

Диаграмма классов - это набор статических, декларативных элементов модели.

Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе

разработки новой системы, и при обратном проектировании - описании существующих и

используемых систем. Информация с диаграммы классов напрямую отображается в

исходный код приложения - в большинстве существующих инструментов UML-

моделирования возможна кодогенерация для определенного языка программирования

(обычно Java или C++). Таким образом, диаграмма классов - конечный результат

проектирования и отправная точка процесса разработки.

Первый пример весьма прост. Как видим, он, хоть и немного однобоко,

иллюстрирует с помощью операции наследования или генерализации "генеалогическое

древо" бытовой техники:

253

Данная диаграмма описывает предметную область задачи об автоматизации работы

некоего вуза или учебного центра. Обратите внимание на обозначения кратности на

концах связей:

Диаграмма ниже – более сложная, здесь кроме кратности обозначены свойства (и

их типы) и операции, и вообще, эта диаграмма производит впечатление набора классов

для реализации, а не просто описания предметной области, как предыдущие. Но, тем не

менее, все равно все просто и понятно.

254

Более детально о диаграмме классов будет сказано далее. Мы подробно разберем

нотацию этого вида диаграмм и познакомимся с улучшениями, внесенными текущей

версией UML.

Диаграмма объектов (object diagram).

Объект (object) - экземпляр класса.

Zicom Mentor "говорит" об объектах более обстоятельно:

Объект (object) -

конкретная материализация абстракции;

сущность с хорошо определенными границами, в которой инкапсулированы

состояние и поведение;

экземпляр класса (вернее, классификатора - эктор, класс или интерфейс).

Объект уникально идентифицируется значениями атрибутов, определяющими его

состояние в данный момент времени.

К примеру, объектом класса "Микроволновая печь" из примера, приведенного

выше, может быть и простейший прибор фирмы "Saturn" небольшой емкости и с

механическим управлением, и навороченный агрегат с грилем, сенсорным управлением и

системой трехмерного распределения энергии от Samsung или LG.

Еще пример - все мы являемся объектами класса "человек" и различимы между

собой по таким признакам (значениям атрибутов), как имя, цвет волос, глаз, рост, вес,

возраст и т.д. (в зависимости от того, какую задачу мы рассматриваем и какие свойства

человека для нас в ней важны).

В UML объект, как и класс, обозначается прямоугольником, но его имя

подчеркивается. Под словом имя здесь мы понимаем название объекта и наименование

его класса, разделенные двоеточием. Для указания значений атрибутов объекта в его

обозначении может быть предусмотрена специальная секция. Еще один нюанс состоит в

255

том, что объект может быть анонимным: это нужно в том случае, если в данный момент

не важно, какой именно объект данного класса принимает участие во взаимодействии.

Примеры:

Для чего нужны диаграммы объектов? Они показывают множество объектов -

экземпляров классов (изображенных на диаграмме классов) и отношений между ними в

некоторый момент времени. То есть диаграмма объектов - это своего рода снимок

состояния системы в определенный момент времени, показывающий множество

объектов, их состояния и отношения между ними в данный момент.

Таким образом, диаграммы объектов представляют статический вид системы с

точки зрения проектирования и процессов, являясь основой для сценариев, описываемых

диаграммами взаимодействия. Говоря другими словами, диаграмма объектов

используется для пояснения и детализации диаграмм взаимодействия, например,

диаграмм последовательностей. Этот тип диаграмм применяется сравнительно редко.

Приведем простейший пример такой диаграммы:

О чем здесь идет речь, в принципе, понятно: некоторая фирма "раскручивает"

новый товар или услугу. В этом процессе участвуют вице-президент по маркетингу, вице-

президент по продажам, менеджер по продажам, торговый агент, специалист по рекламе,

некое печатное издание и покупатель. Причем даже без указания сообщений, которыми

256

обмениваются эти объекты, отлично видно, кто с кем взаимодействует. Кстати, обратите

внимание, что на этой диаграмме все объекты анонимные!

Другой пример:

Эта диаграмма тоже понятна в общих чертах даже без дополнительных

объяснений. Здесь мы видим взаимосвязь объектов - организационных единиц в

некоторой компании.

Диаграмма последовательностей (sequence diagram).

Если диаграмма объектов показывает отношения между объектами в некоторый

момент времени, т.е. предоставляет нам снимок состояния системы, являясь статической,

то диаграмма последовательностей отображает взаимодействие объектов в динамике.

В UML взаимодействие объектов понимается как обмен информацией между ними.

При этом информация принимает вид сообщений. Кроме того, что сообщение несет

какую-то информацию, оно некоторым образом также влияет на получателя. Как

видим, в этом плане UML полностью соответствует основным принципам ООП, в

соответствии с которыми информационное взаимодействие между объектами сводится к

отправке и приему сообщений.

Диаграмма последовательностей относится к диаграммам взаимодействия UML,

описывающим поведенческие аспекты системы, но рассматривает взаимодействие

объектов во времени. Другими словами, диаграмма последовательностей отображает

временные особенности передачи и приема сообщений объектами.

Заметим, что подобное делает и диаграмма прецедентов. Действительно,

диаграммы последовательностей можно (и нужно!) использовать для уточнения

диаграмм прецедентов, более детального описания логики сценариев использования. Это

отличное средство документирования проекта с точки зрения сценариев использования.

257

Диаграммы последовательностей обычно содержат объекты, которые взаимодействуют в

рамках сценария, сообщения, которыми они обмениваются, и возвращаемые результаты,

связанные с сообщениями. Впрочем, часто возвращаемые результаты обозначают лишь в

том случае, если это не очевидно из контекста.

Рассмотрим обозначения на диаграмме последовательностей. Как и ранее, объекты

обозначаются прямоугольниками с подчеркнутыми именами (чтобы отличить их от

классов), сообщения (вызовы методов) - линиями со стрелками, возвращаемые результаты

- пунктирными линиями со стрелками. Прямоугольники на вертикальных линиях под

каждым из объектов показывают "время жизни" (фокус) объектов. Впрочем, довольно

часто их не изображают на диаграмме, все это зависит от индивидуального стиля

проектирования.

Пример диаграммы последовательностей: студент хочет записаться на некий

семинар, предлагаемый в рамках некоторого учебного курса. С этой целью проводится

проверка подготовленности студента, для чего запрашивается список (история) семинаров

курса, уже пройденных студентом (перейти к следующему семинару можно, лишь

проработав материал предыдущих занятий). После получения истории семинаров объект

класса "Слушатель" получает статус подготовленности, на основе которой студенту

сообщается результат (статус) его попытки записи на семинар. Кстати, обратите внимание

на вызов методов:

Следующая диаграмма описывает работу обычного домового лифта, которым мы

пользуемся каждый день. Кстати, посмотрите на имена объектов - видно, что это уже

несколько иной стиль проектирования, чем в предыдущем примере:

258

А так функционирует мобильный телефон:

Диаграмма взаимодействия (кооперации, collaboration diagram).

Диаграммы последовательностей - это отличное средство документирования

поведения системы, детализации логики сценариев использования; но есть еще один

259

способ - использовать диаграммы взаимодействия. Диаграмма взаимодействия

показывает поток сообщений между объектами системы и основные ассоциации между

ними и по сути, как уже было сказано выше, является альтернативой диаграммы

последовательностей.

Нельзя сказать, что диаграмма объектов делает то же самое. Диаграмма объектов

показывает статику, некий снимок системы, связи между объектами в данный момент

времени, диаграмма же взаимодействия, как и диаграмма последовательностей,

показывает взаимодействие объектов во времени, т.е. в динамике.

Следует отметить, что использование диаграммы последовательностей или

диаграммы взаимодействия - личный выбор каждого проектировщика и зависит от

индивидуального стиля проектирования. Кто-то отдает предпочтение диаграмме

последовательностей, кто-то – диаграмме взаимодействия.

В обозначениях, применяемых на диаграмме взаимодействия, все стандартно:

объекты обозначаются прямоугольниками с подчеркнутыми именами (чтобы отличить их

от классов), ассоциации между объектами указываются в виде соединяющих их линий,

над ними может быть изображена стрелка с указанием названия сообщения и его

порядкового номера.

Необходимость номера сообщения объясняется очень просто - в отличие от

диаграммы последовательностей, время на диаграмме взаимодействия не показывается в

виде отдельного измерения. Поэтому последовательность передачи сообщений можно

указать только с помощью их нумерации. В этом и состоит вероятная причина

пренебрежения этим видом диаграмм многими проектировщиками.

Диаграмма ниже описывает (очень грубо) работу персонала библиотеки по

обслуживанию клиентов: библиотекарь получает заказ от клиента, поручает сотруднику

найти информацию по нужной клиенту книге, а после получения данных поручает еще

одному сотруднику выдать книгу клиенту:

260

Данная диаграмма описывает процесс управления учебными курсами (очевидно,

путем создания их из готовых модулей) для некоего учебного центра:

А вот тот же мобильный телефон, но уже на диаграмме взаимодействия:

Как видим, это просто другая форма представления, к тому же менее удобная. Но

поскольку в команде разработчиков могут работать различные люди, с различными

предпочтениями и особенностями восприятия, такой вид диаграмм тоже можно

261

использовать для описания логики сценариев. Есть выбор: диаграммы

последовательностей или диаграммы кооперации.

Диаграмма состояний (statechart diagram).

Объекты характеризуются поведением и состоянием, в котором находятся.

Например, человек может быть новорожденным, младенцем, ребенком, подростком или

взрослым. Другими словами, объекты что-то делают и что-то "знают". Диаграммы

состояний применяются для того, чтобы объяснить, каким образом работают сложные

объекты. Несмотря на то, что смысл понятия "состояние" интуитивно понятен, все же

приведем его определение в таком виде, в каком его дают классики и Zicom Mentor:

Состояние (state) - ситуация в жизненном цикле объекта, во время которой он

удовлетворяет некоторому условию, выполняет определенную деятельность или ожидает

какого-то события. Состояние объекта определяется значениями некоторых его атрибутов

и присутствием или отсутствием связей с другими объектами.

Диаграмма состояний показывает, как объект переходит из одного состояния в

другое. Очевидно, что диаграммы состояний служат для моделирования динамических

аспектов системы (как и диаграммы последовательностей, кооперации, прецедентов и, как

мы увидим далее, диаграммы деятельности). Часто можно услышать, что диаграмма

состояний показывает автомат, но об этом будет сказано подробнее позже. Диаграмма

состояний полезна при моделировании жизненного цикла объекта (как и ее частная

разновидность - диаграмма деятельности, о которой мы будем говорить далее).

От других диаграмм диаграмма состояний отличается тем, что описывает процесс

изменения состояний только одного экземпляра определенного класса - одного объекта,

причем объекта реактивного , то есть объекта, поведение которого характеризуется его

реакцией на внешние события. Понятие жизненного цикла применимо как раз к

реактивным объектам, настоящее состояние (и поведение) которых обусловлено их

прошлым состоянием. Но диаграммы состояний важны не только для описания динамики

отдельного объекта. Они могут использоваться для конструирования исполняемых систем

путем прямого и обратного проектирования. И они действительно с успехом применяются

в таком качестве, вспомним существующие варианты "исполняемого UML", такие как

UNIMOD, FLORA и др.

Рассмотрим обозначения на диаграммах состояний. Скругленные прямоугольники

представляют состояния, через которые проходит объект в течение своего жизненного

цикла. Стрелками показываются переходы между состояниями, которые вызваны

выполнением методов описываемого диаграммой объекта. Существует также два вида

псевдосостояний: начальное, в котором находится объект сразу после его создания

262

(обозначается сплошным кружком), и конечное, которое объект не может покинуть, если

перешел в него (обозначается кружком, обведенным окружностью).

Приведем пример простейшей диаграммы состояний – данные на DVD-диске.

На примере ниже мы видим составное состояние, включающее другие состояния,

одно из которых содержит также параллельные подсостояния. Это диаграмма

прохождения академического курса студентом. Для того чтобы пройти курс, студент

должен выполнить лабораторные работы, защитить курсовой проект и сдать экзамен:

Рассмотрим диаграмму работы таймера, который может применяться в составе

различных реле, например, для отключения телевизора по истечении указанного

промежутка времени. Основное его назначение - контроль времени (проверка, не истек ли

указанный промежуток), но у него есть еще один режим работы - установка. По истечении

указанного промежутка времени или при "сбросе" устройство отключается:

263

Диаграмма активности (деятельности, activity diagram).

Моделируя поведение проектируемой системы, часто недостаточно изобразить

процесс смены ее состояний, а нужно также раскрыть детали алгоритмической реализации

операций, выполняемых системой. Для этой цели традиционно использовались блок-

схемы или структурные схемы алгоритмов. В UML для этого существуют диаграммы

деятельности, являющиеся частным случаем диаграмм состояний. Диаграммы

деятельности удобно применять для визуализации алгоритмов, по которым работают

операции классов.

Алгоритм - последовательность определенных действий или элементарных

операций, выполнение которых приводит к получению желаемого результата. Чем

сложнее устройство или система, тем важнее строго следовать алгоритму.

Обозначения на диаграмме активности напоминают те, которые применяются в

блок-схемах, хотя есть и некоторые существенные отличия. С другой стороны, нотация

диаграмм активности очень похожа на ту, которая используется в диаграммах состояний.

Диаграмма «начало дня», какое оно у многих из нас. Обратите внимание на то, как

изображено параллельное пение и принятие душа, - на обычной блок-схеме это было бы

невозможно!

264

Оформление заказа в интернет-магазине:

Рассмотрите данную диаграмму и попробуйте определить ее предметную область:

265

Диаграмма развертывания (deployment diagram).

Когда мы пишем программу, мы пишем ее для того, чтобы запускать на

компьютере, который имеет некоторую аппаратную конфигурацию и работает под

управлением некоторой операционной системы. Корпоративные приложения часто

требуют для своей работы некоторой ИТ-инфраструктуры, хранят информацию в базах

данных, расположенных где-то на серверах компании, вызывают веб-сервисы, используют

общие ресурсы и т.д. В таких случаях неплохо бы иметь графическое представление

инфраструктуры, на которую будет развернуто приложение. Вот для этого-то и нужны

диаграммы развертывания, которые иногда называют диаграммами размещения.

Очевидно, что такие диаграммы есть смысл строить только для аппаратно-

программных систем, тогда как UML позволяет строить модели любых систем, не

обязательно компьютерных.

Какую пользу можно извлечь из диаграмм развертывания?

Во-первых, графическое представление ИТ-инфраструктуры может помочь более

рационально распределить компоненты системы по узлам сети, от чего, как известно,

зависит в том числе и производительность системы.

Во-вторых, такая диаграмма может помочь решить множество вспомогательных

задач, связанных, например, с обеспечением безопасности.

266

Диаграмма развертывания показывает топологию системы и распределение

компонентов системы по ее узлам, а также соединения - маршруты передачи информации

между аппаратными узлами. Это единственная диаграмма, на которой применяются

"трехмерные" обозначения: узлы системы обозначаются кубиками. Все остальные

обозначения в UML - плоские фигуры.

Обслуживание клиентов через сервер:

Диаграмма посложнее, с большим количеством узлов. Это инфраструктура некоего

учебного заведения, включающая шлюз, файл-сервер, принт-сервер, принтеры в

лабораториях и холле и т.д. Пользователь (вероятно, студент или преподаватель) может

получить доступ к этим ресурсам либо со своей домашней машины, либо с рабочих

станций, находящихся в лабораториях вуза. Обратите внимание на подписи под линиями,

показывающими линии передачи информации, например, видно, что рабочая станция

получает доступ к файлам, хранящимся на файл-сервере, посредством NFS. Также

хорошая идея - рядом с обозначением узла перечислить программное обеспечение,

установленное на данном узле, как это сделано, например, для рабочей станции.

267

А еще на диаграммах развертывания можно обозначать компоненты системы, т.е.

показывать их распределение по аппаратным узлам.

ООП и последовательность построения диаграмм.

Проанализировав увиденное, можно сделать вывод о том, что язык UML

достаточно прост. Действительно, простые задачи решаются с помощью UML без особого

труда. А вот более сложные системы, получив только общее представление о нем,

адекватно смоделировать не удастся. Читать об UML недостаточно - надо им

пользоваться! Сразу всего не понять, но по мере увеличения опыта использования UML

начинаешь все лучше понимать его конструкции. Так же как и другие языки, UML

требует особого способа мышления, умения рассматривать систему с разных сторон и

точек зрения.

Можно дать множество рекомендаций относительно того, какие же именно

диаграммы строить и как. Прежде всего, вы должны ответить для себя на такие вопросы:

Какие именно виды диаграмм лучше всего отражают архитектуру системы и

возможные технические риски, связанные с проектом?

Какие из диаграмм удобнее всего превратить в инструмент контроля над

процессом (и прогрессом) разработки системы?

И еще одно - никогда не выбрасывайте даже "забракованные" диаграммы: они

могут в дальнейшем оказаться полезными при анализе направления вашей мысли, поиске

ошибок проектирования, да и просто для экспериментов по незначительному изменению

системы.

268

Диаграммы, как уже говорилось выше, можно и нужно строить в некоторой

логической последовательности. Но как выработать эту последовательность, если у вас

нет опыта моделирования? Как научиться этому? Вот несколько простых приемов,

которые помогут вам (или вашей команде) выработать свой стиль проектирования.

В UML-проектировании, как и при создании любых других моделей, важно уметь

абстрагироваться от несущественных свойств системы. В этом плане очень полезными

могут оказаться коллективные упражнения на выявление и анализ прецедентов. Они

помогут отработать навыки выявления четких абстракций.

Неплохой способ начать - моделирование базовых абстракций или поведения одной

из уже имеющихся у вас систем.

Стройте модели предметной области задачи в виде диаграммы классов! Это

хороший способ понять, как визуализировать множества взаимосвязанных абстракций.

Таким же образом стройте модели статической части задач.

Моделируйте динамическую часть задачи с помощью простых диаграмм

последовательностей и кооперации. Хорошо начать с модели взаимодействия

пользователя с системой - так вы сможете легко выделить наиболее важные прецеденты.

Не забываем, что мы говорим, прежде всего, именно об объектно-ориентированных

системах. Поэтому, подытоживая все сказанное ранее, можно предложить такую

последовательность построения диаграмм:

диаграмма прецедентов,

диаграмма классов,

диаграмма объектов,

диаграмма последовательностей,

диаграмма кооперации,

диаграмма состояний,

диаграмма активности,

диаграмма развертывания.

Конечно, это не единственная возможная последовательность. Возможно, вам

будет удобнее начать с диаграммы классов. А может, вам не нужны диаграммы объектов,

а диаграммы последовательностей вы предпочитаете диаграммам кооперации. Это лишь

один из путей, постепенно вы выработаете свой персональный стиль проектирования и

свою последовательность!

И напоследок еще несколько советов относительно использования UML.

1. Хорошее и полезное упражнение - строить модели классов и отношений между

ними для уже созданных вами ИС (тренировка).

269

2. Применяйте UML для того, чтобы прояснить неявные детали реализации

существующей системы или использованные в ней "хитрые механизмы

программирования".

3. Стройте UML-модели, прежде чем начать новый проект. Только когда будете

абсолютно удовлетворены полученным результатом, начинайте использовать их как

основу для кодирования.

4. UML содержит некоторые средства расширения. Подумайте, как можно

приспособить язык к предметной области вашей задачи.

5. Не слишком увлекайтесь обилием средств UML: если вы в каждой диаграмме

будете использовать абсолютно все средства UML, прочесть созданную вами модель

смогут лишь самые опытные пользователи.

6. Кроме прочего, важным моментом здесь является выбор пакета UML-

моделирования (CASE-средства), что тоже может повлиять на ваш индивидуальный стиль


Выводы:

Диаграммы разных видов позволяют взглянуть на систему с разных точек

зрения.

UML содержит диаграммы трех типов - для моделирования статической

структуры, поведенческих аспектов и подробностей реализации приложения.

Недостаточно читать об UML - им надо пользоваться!

Диаграмма классов: подробно.

Как класс изображается на диаграмме UML?

Архитектор программного обеспечения в первую очередь обращает внимание на

объекты предметной области. Программист же концентрируется на поведении этих

объектов, пользуясь классами, к которым они принадлежат. Вот поэтому-то диаграмма

классов и является одной из важнейших диаграмм UML. Она используется для

документирования программных систем, и основным ее компонентом является класс.

Класс на диаграмме изображается в виде прямоугольника, разделенного

горизонтальными линиями на три части. В первой части указывается название класса. Как

правило, имя класса состоит из одного, максимум двух слов. Вторая часть содержит

перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в

модели предметной области. Третья часть содержит перечень операций, отражающих его

поведение в модели предметной области:

270

А что внутри?

Мы узнали, как класс изображается и выглядит "снаружи". А что же внутри

объектов класса? Пользователю об этом знать необязательно, более того, абсолютно не

нужно. Для человека, использующего его, объект выступает в роли черного ящика.

Скрывая от пользователя внутреннее устройство объекта, мы обеспечиваем его надежную

работу. Сейчас мы рассмотрим, как убрать из поля зрения пользователя то, что ему знать

не нужно.

А нужны ли пользователю вообще какие-то объекты и классы? Да, нужны, потому

что программист, использующий в своей программе созданные кем-то компоненты, как

раз и выступает в роли такого пользователя. Зачем ему знать что внутри - он знает, какие

атрибуты надо модифицировать и какие операции использовать, чтобы заставить объект

работать именно так, как ему нужно!

Сокрытие от пользователя внутреннего устройства объектов называется

инкапсуляцией. Если говорить более "научным" языком, то инкапсуляция - это защита

отдельных элементов объекта, не затрагивающих существенных характеристик его как

целого. Инкапсуляция нужна не только для того, чтобы создать иллюзию простоты

объекта для пользователя (по словам Г. Буча).

К примеру, телевизор. Нам этот прибор кажется очень простым только потому, что

при работе с ним мы используем простой и понятный интерфейс - пульт дистанционного

управления. Мы знаем: для того чтобы увеличить громкость звука, надо нажать вот эту

кнопку, а чтобы переключить канал - вот эту. Как телевизор устроен внутри, мы не знаем.

Более того - в отсутствие пульта ДУ такое знание было бы неудобным для нас и весьма

опасным для самого телевизора, вздумай мы увеличить громкость с помощью паяльника.

Поэтому-то пульт ДУ и защищает от нас "внутренности" телевизора! Вот так

инкапсуляция реализуется в реальном мире.

В программировании инкапсуляция обеспечивается немного по-другому - с

помощью т.н. модификаторов видимости. С их помощью можно ограничить доступ к

атрибутам и операциям объекта со стороны других объектов.

271

Если атрибут или операция описаны с модификатором private, то доступ к ним

можно получить только из операции, определенной в том же классе.

Если же атрибут или операция описаны с модификатором видимости public, то к

ним можно получить доступ из любой части программы.

Модификатор protected разрешает доступ только из операций этого же класса и

классов, создаваемых на его основе. В языках программирования могут встречаться

модификаторы видимости, ограничивающие доступ на более высоком уровне, например, к

классам или их группам, однако смысл инкапсуляции от этого не изменяется.

В UML атрибуты и операции с модификаторами доступа обозначаются

специальными символами слева от их имен:

Символ Значение+ public - открытый доступ- private - только из операций того же класса# protected - только из операций этого же класса и классов, создаваемых на его основе

Рассмотренный ранее пример с телевизором средствами UML (конечно,

абстрактно) можно изобразить так:

Зачем, например, пользователю знать числовые значения частот каналов? Он знает,

что достаточно запустить процедуру автоматического поиска каналов, и телевизор все

сделает за него. Инкапсуляция - повсюду вокруг нас.

Как использовать объекты класса?

Итак, мы рассмотрели инкапсуляцию - одно из средств защиты объектов. Все вроде

бы понятно, но как же именно работать с объектом?

Если уж говорить о защите объекта, то чтобы она действительно была

эффективной, надо позаботиться о некоем стандартном и безопасном, не зависящим от

языка программирования способе доступа к объекту. К тому же такой стандартный способ

272

доступа должен быть простым и с точки зрения использования, и с точки зрения

реализации. Вспомните пример с телевизором. Нажимая кнопки на пульте, мы ожидаем,

что телевизор откликнется на это действие каким-то определенным образом - именно так,

как мы ожидаем, а не иначе. То есть, с одной стороны, пульт ДУ является средством

доступа к скрытым операциям, выполняемым телевизором, а с другой стороны - пульт

обеспечивает нужное для нас поведение телевизора. В данном примере именно пульт

является таким стандартным средством доступа к телевизору. Можно даже сказать,

средством доступа, не зависящим от конкретной модели телевизора - вспомните об

универсальных пультах и о том, как отключаете звук надоедливой рекламы на экране в

вагоне поезда, используя КПК!

В том же примере с телевизором у нас впервые промелькнуло слово интерфейс. И

не случайно промелькнуло: именно так называют тот самый стандартный способ доступа

к объекту. Более строго, интерфейс - это логическая группа открытых (public) операций

объекта. Один и тот же объект может иметь несколько интерфейсов. У телевизора,

например, их два - пульт ДУ и кнопки на корпусе. А может и больше - вспомните о

возможности управлять бытовой техникой с помощью КПК или универсального пульта

ДУ.

Кстати, посмотрите внимательнее на пульт ДУ или на экран программы удаленного

контроля. Что вы видите - кнопки? Или кнопки, сгруппированные по функциональному

признаку? Да, именно так: кнопки, переключающие каналы, расположены отдельно,

рядом - группа кнопок, отвечающих за регулировку громкости звука, рядом - группа

программируемых кнопок, и т.д. В принципе, можно сказать, что пульт реализует не один,

а несколько интерфейсов - по числу функциональных групп кнопок. Так выглядит

"логическая группа" в определении интерфейса.

Однако интерфейс - это не только и не столько группа операций объекта.

Интерфейс отражает внешние проявления объекта, показывает, каким образом

осуществляется взаимодействие с ним, скрывая остальные детали, не имеющие

отношения к процессу взаимодействия.

Интерфейс всегда реализуется некоторым классом, который в таком случае

называют классом, поддерживающим интерфейс. Как мы уже говорили ранее, один и тот

же объект может иметь несколько интерфейсов. Это означает, что класс этого объекта

реализует все операции этих интерфейсов. Многие из существующих технологий

программирования (например, COM, CORBA, Java Beans) не только активно используют

механизм интерфейсов, но и, по сути, полностью основаны на нем.

273

Изображаться на диаграммах интерфейс может несколькими способами. Первый и

самый простой из них - это класс со стереотипом <<interface>>:

Этот способ хорош, если нужно показать, какие именно операции предоставляет

интерфейс. Если же такие подробности в данный момент не важны, предоставляемый

интерфейс изображают в виде кружочка или, как говорят, "леденца":

Обратите внимание на маленький значок на закладке папки ConduitSet. Это

обозначение подсистемы, мы могли бы не рисовать его, а просто использовать стереотип

<<subsystem>>.

И наконец, еще один способ изображения интерфейса. Он не является

альтернативой описанным ранее способам, а используется для изображения интерфейсов,

требующихся объекту для выполнения его работы. Обозначается он очень простым и

логичным символом:

Можно заметить, как логически совмещаются символы предоставляемого и

требуемого интерфейсов. Действительно, на диаграммах довольно часто можно увидеть

такую картинку:

274

Вы заметили, что названия интерфейсов начинаются с буквы I? Эта традиция

пошла из языка Java, и, как показывает практика, она весьма облегчает жизнь, если нужно,

например, быстро разобраться в сложной диаграмме, составленной другим человеком.

Всегда ли нужно создавать новые классы?

Начнем с вопроса, казалось бы, не имеющего никакого отношения к

рассматриваемому вопросу, а именно - всегда ли нужно создавать новый класс для каждой

новой задачи? Конечно же, нет. Это было бы странно и неэффективно. "Фишка" состоит в

том, что мы можем использовать уже существующие классы, адаптируя их

функциональность для выполнения новых задач. Таким образом, появляется возможность

не создавать систему классов с нуля, а задействовать уже имеющиеся решения, которые

были созданы ранее, при работе над предыдущими проектами. Впрочем, могут быть

ситуации, когда существующие классы по каким-либо причинам не устраивают

архитектора, и тогда требуется создать новый класс. Следует, однако, избегать ситуаций,

когда созданный класс (а точнее, его набор операций и атрибутов) практически повторяет

существующий, лишь незначительно отличаясь от него. Все-таки лучше стараться

создавать классы на основе уже существующих, и только если подходящих классов не

нашлось - создавать свои, которые, в свою очередь, могут (и должны!) служить основой

для других классов. Мы уже не говорим о том, что создание классов предполагает

значительный объем усилий по кодированию и тестированию. В общем случае, сказанное

выше можно проиллюстрировать такой диаграммой:

В дополнение можно назвать несколько причин, почему стоит использовать уже

существующие классы.

275

Во-первых, идя этим путем, мы пользуемся плодами ранее принятых решений.

Действительно, если когда-то мы уже решили некоторую проблему, зачем начинать все "с

нуля", повторяя уже однажды проделанные действия?

Во-вторых, таким образом мы делаем решение мобильным и расширяемым.

Используя уже существующие классы и создавая на их основе новые, мы можем

развивать решение практически неограниченно, добавляя лишь необходимые нам в

данный момент детали - атрибуты и операции.

В-третьих, существующие классы, как правило, хорошо отлажены и показали себя

в работе. Разработчику не надо тратить время на кодирование, отладку, тестирование и

т.д., - мы работаем с хорошо отлаженным и проверенным временем кодом, который

зарекомендовал себя в других проектах и в котором уже выявлено и исправлено

большинство ошибок.

Как создавать классы на основе уже существующих? Дадим понятие обобщения

или генерализации, которое играет очень важную роль в ООП, являясь одним из его

базовых принципов.

Обобщение - это отношение между более общей сущностью, называемой

суперклассом, и ее конкретным воплощением, называемым подклассом. Иногда

обобщение называют отношениями типа "является", имея в виду, что одни сущности

(например, круг, квадрат, треугольник) являются воплощением более общей сущности

(например, класса "геометрическая фигура"). При этом все атрибуты и операции

суперкласса независимо от модификаторов видимости входят в состав подкласса.

Обобщение (или, как часто говорят, наследование) на диаграммах обозначается

очень просто незакрашенной треугольной стрелкой, направленной на суперкласс:

Для того чтобы научиться эффективно моделировать наследование, обратимся к

классикам, а именно к Г. Бучу. Он советует проводить эту процедуру в такой

последовательности:

276

1. Найдите атрибуты, операции и обязанности, общие для двух или более

классов из данной совокупности. Это позволит избежать ненужного дублирования

структуры и функциональности объектов.

2. Вынесите эти элементы в некоторый общий суперкласс, а если такого не

существует, то создайте новый класс.

3. Отметьте в модели, что подклассы наследуются от суперкласса, установив

между ними отношение обобщения.

Пример применения этого подхода:

На первый взгляд, кажется странным, что класс "точка" не имеет никаких

атрибутов, а круг имеет только радиус. С прямоугольником, вроде бы, все понятно -

ширина и высота, но вот только где он расположен в пространстве, этот прямоугольник?

Давайте попробуем следовать советам Буча. Итак, положение всех трех фигур можно

однозначно определить с помощью пары чисел. Для точки - это вообще единственные ее

характеристики, для круга и прямоугольника - их центры (под центром прямоугольника

мы понимаем точку пересечения его диагоналей). Вот они, общие атрибуты! Таким

образом, мы создали суперкласс "Фигура", имеющий два атрибута - координаты центра.

Все остальные классы на этой диаграмме связаны с классом "Фигура" отношением

обобщения, т. е. в них нужно доопределить только "недостающие" атрибуты - радиус,

ширину и высоту. Атрибуты, описывающие координаты центра, эти классы имеют

изначально как потомки класса "Фигура" - они их наследуют. Заметим, что операции

классов мы тут не рассматриваем: понятно, что с ними была бы та же история.

Классы-потомки наследуют атрибуты и операции суперкласса. Таким образом, они

могут наследовать и их интерфейсы - то есть объекты абсолютно разной природы могут

иметь один и тот же интерфейс. Так как же тогда определить, какого же все-таки класса

объект? Да и нужно ли это вообще?

Действительно, объекты разной природы (или говоря проще, разных классов)

могут поддерживать один и тот же интерфейс именно так, как того ожидает пользователь.

277

Примером тому может служить рассмотренная выше диаграмма с геометрическими

фигурами. Все рассмотренные фигуры имеют, например, операцию рисования на экране.

С точки зрения пользователя в каждом случае это одно и то же действие. Однако

реализованы эти операции по-разному - ведь процедура изображения прямоугольника

сильно отличается от подобной процедуры для круга. Но для пользователя это неважно:

ведь сигнатура-то одна и та же! А возможно это благодаря еще одному из основных

принципов ООП - полиморфизму. Как мы только что упомянули, работа механизма

полиморфизма основана на совпадении сигнатуры метода, объявленного в интерфейсе, и

сигнатуры самого метода. Методы внутри классов-потомков могут быть (и наверняка

будут!) переопределены, их реализации будут различными, а сигнатуры останутся

неизменными. Таким образом (и в этом легко ощутить мощь ООП), выполняя одни и те

же операции, разные объекты могут вести себя по-разному.

Полиморфизм является основой для реализации механизма интерфейсов в языках

программирования. Вот, кстати, и ответ на вопрос, какого класса объект: как только

пользователь обращается к некоторой операции через интерфейс, определяется

фактический класс объекта и вызывается соответствующая операция класса.

Примеры полиморфизма можно увидеть в самых обыденных вещах, которыми мы

пользуемся в повседневной жизни. Мир построен по ООП. Например, всем привычная

кредитная карточка, является интерфейсом для доступа к банковскому счету через

банкомат (и не только), одинаково работает в любой стране, вот только ведет себя чуть-

чуть по-разному, т.к. банкомат выдает деньги в местной валюте.

Инкапсуляция, наследование и полиморфизм являются «тремя китами», на которых

держится ООП.

Отношения между классами.

Ни один из объектов окружающего нас мира не существует сам по себе. Птицы

летают потому, что есть воздух, на который опираются их крылья. Каждый из нас связан с

массой других людей разнообразными родственными, профессиональными и другими

связями, предполагающими различные типы отношений. Точно так же и классы связаны

между собой. И чтобы в полной мере овладеть ООП, нам необходимо понять суть этих

отношений и научиться их идентифицировать.

Мы сказали, что объекты находятся в определенных отношениях друг с другом.

Один из типов таких отношений - это зависимость. Зависимость возникает тогда, когда

реализация класса одного объекта зависит от спецификации операций класса другого

объекта. И если изменится спецификация операций этого класса, нам неминуемо придется

вносить изменения и в зависимый класс .

278

Приведем простой пример: иногда к нам в руки попадают видеофайлы,

воспроизвести которые "с лету" не удается, потому что на компьютере не установлены

соответствующие кодеки. То есть операция "Воспроизведение", реализуемая программой-

медиаплеером, зависит от операции "Декомпрессия", реализуемой кодеком. Если

спецификация операции "Декомпрессия" изменится, придется менять код медиаплеера,

иначе он просто не сможет работать с каким-то кодеком и, в лучшем случае, завершит

свою работу с ошибкой.

А вот так зависимость между классами изображается в UML:

Стоит отметить, что зависимости на диаграммах изображают далеко не всегда, а

только в тех случаях, когда их отображение является важным для понимания модели.

Часто зависимости лишь подразумеваются, т.к. логически следуют из природы классов.

Другой вид отношений между объектами - это ассоциация. Это просто связь

между объектами, по которой можно между ними перемещаться. Ассоциация может

иметь имя, показывающее природу отношений между объектами, при этом в имени может

указываться направление чтения связи при помощи треугольного маркера.

Однонаправленная ассоциация может изображаться стрелкой. Проиллюстрируем

сказанное примерами:

279

Кроме направления ассоциации, мы можем указать на диаграмме роли, которые

каждый класс играет в данном отношении, и кратность, то есть количество объектов,

связанных отношением:

И насчет ролей, и насчет кратности на этой диаграмме все понятно - человек может

вообще не работать, работать в одной или более компаниях, а вот компании в любом

случае нужен хотя бы один сотрудник.

К вопросу о кратности: ассоциация может объединять три и более класса. В этом

случае она называется n-арной и изображается ромбом на пересечении линий, как

показано на этой диаграмме:

Ранее мы говорили, что ассоциация - это "просто связь" между объектами. На

самом деле, в реальности связи бывают "просто связями" крайне редко. Обычно при

ближайшем рассмотрении под ассоциацией понимается более сложное отношение между

классами, например, связь типа "часть-целое". Такой вид ассоциации называется

ассоциацией с агрегированием. В этом случае один класс имеет более высокий статус

(целое) и состоит из низших по статусу классов (частей). При этом выделяют простое и

композитное агрегирование и говорят о собственно агрегации и композиции. Простая

агрегация предполагает, что части, отделенные от целого, могут продолжать свое

280

существование независимо от него. Под композитным же агрегированием понимается

ситуация, когда целое владеет своими частями и их время жизни соответствует времени

жизни целого, т.е. независимо от целого части существовать не могут. Примеры этих

видов ассоциаций и их обозначений в UML можно увидеть на следующей диаграмме:

Винчестер можно вынуть из компьютера и установить в новый компьютер или в

USB-карман, т.е. существование жесткого диска с разборкой системного блока не

заканчивается. А вот кнопки без окон обычно существовать не могут - с закрытием окна

кнопки также исчезают.

И, наконец, еще одна важная вещь, касающаяся ассоциации. В отношении между

двумя классами сама ассоциация тоже может иметь свойства и, следовательно, тоже

может быть представлена в виде класса:

Действительно, перед началом трудовых отношений работник и работодатель

подписывают между собой контракт, который имеет такие атрибуты, как, например,

описание работ, сроки их выполнения, порядок оплаты и т.д.

281

Более сложный пример моделирования отношений между классами:

Выводы

Инкапсуляция защищает внутреннее устройство объекта и реализуется

путем ограничения доступа к атрибутам и операциям класса из других частей программы.

Обобщение позволяет повторно использовать уже существующие решения,

создавая новые классы путем наследования от имеющихся классов.

Полиморфизм позволяет работать с группой разнородных объектов

одинаковым образом, не задумываясь о различиях в реализации.

Инкапсуляция, наследование и полиморфизм – «три кита», на которых

держится ООП.

В любой системе между объектами существуют отношения разных типов.

Отношение зависимости означает, что реализация одного класса зависит от

спецификации операций другого класса.

Ассоциация выражает отношение между несколькими равноправными

объектами и может иметь направление, роли и кратность, а также изображаться в виде

класса ассоциации.

282

Композиция и агрегация используются, если между объектами существуют

отношения типа "часть-целое", причем композиция предполагает, что части не могут

существовать отдельно от целого.

Диаграмма активностей: подробно.

Это не блок-схема.

Как мы уже говорили, диаграммы активностей (Activity Diagrams) являются

представлением алгоритмов неких действий (активностей), выполняющихся в системе.

Мы уже знаем, что нотация UML предлагает пять представлений системы:

Вид системы с точки зрения прецедентов.

Вид с точки зрения проектирования.

Вид с точки зрения процессов.

Вид с точки зрения развертывания.

Вид с точки зрения реализации.

И при этом каждый из перечисленных способов представления системы может

содержать последовательности действий, которые могут быть описаны с помощью

алгоритмов. Вот здесь-то и выходят на сцену диаграммы деятельностей. Вообще говоря,

любой элемент модели, имеющий динамическое поведение, может быть дополнен

диаграммой деятельности - именно для уточнения этой самой динамики.

Можно построить несколько диаграмм деятельности для одной и той же системы,

причем каждая из них будет фокусироваться на разных аспектах системы, показывать

различные действия, выполняющиеся внутри ее. Когда мы говорим о динамике, мы

подразумеваем поведение системы в целом или ее частей. Говоря более формально,

диаграммы активности, в общем-то, не имеют монополии на описание поведенческих

особенностей динамических частей системы. Для этой же цели могут использоваться еще

диаграммы прецедентов, последовательности, кооперации и состояний. Почему же мы

говорим именно о диаграмме активности?

Именно на диаграмме деятельности представлены переходы потока управления от

одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все

или большая часть состояний являются некоторыми деятельностями, а все или большая

часть переходов срабатывают при завершении определенной деятельности и позволяют

перейти к выполнению следующей. Как мы уже говорили, диаграмма деятельности может

быть присоединена к любому элементу модели, имеющему динамическое поведение.

Кстати, исходя из вышесказанного, логичнее говорить не "диаграмма деятельности", а

"диаграмма деятельностей" - во множественном числе.

283

Диаграммы деятельности позволяют моделировать сложный жизненный цикл

объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид

диаграмм может быть использован и для описания динамики совокупности объектов. Они

применимы и для детализации некоторой конкретной операции, причем, как мы увидим

далее, предоставляют для этого больше возможностей, чем "классическая" блок-схема.

Диаграммы деятельности описывают переход от одной деятельности к другой, в отличие

от диаграмм взаимодействия, где акцент делается на переходах потока управления от

объекта к объекту.

Пример:

Эта диаграмма описывает ежеутреннюю последовательность действий человека (до

момента ухода на работу). Действия показаны скругленными прямоугольниками, как в

блок-схеме. Отличия от блок-схемы небольшие и выглядят как логичное расширение

нотации блок-схем. Обратим внимание на то, что начало и конец уже не изображаются

одинаковым безликим кружком. Начало теперь закрашено, а конец изображен в виде

символа, напоминающего кошачий глаз:

284

Без пояснений понятен также смысл символа, предшествующего принятию душа и

пению и следующего за ними - он означает распараллеливание, а затем опять слияние

воедино ( синхронизацию ) потоков управления, т. е. операции "пение" и "душ"

выполняются одновременно. Нотация проста: несколько потоков управления сливаются в

один или один поток разделяется на несколько:

Конечно, это не единственные отличия диаграммы активностей от блок-схемы. На

диаграмме деятельностей можно не только показать параллельно выполняемые действия,

но и указать состояния объектов, также есть возможность показывать распределение

ролей и т.д.

Вот еще пример, подтверждающий, что диаграмма активностей - это нечто

большее, чем блок-схема:

Смысл диаграммы вполне понятен: на ней показана работа с веб-приложением,

которое решает некую задачу в удаленной базе данных. Привлекает внимание странное

285

расположение активностей на этой диаграмме: они как бы разбросаны по трем беговым

дорожкам, каждая из которых соответствует поведению одного из трех объектов -

клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из

объектов выполняется каждая из активностей, и неожиданно приходит понимание того,

что "странность" этой диаграммы, оказывается, очень упрощает ее восприятие.

Аналогия с дорожками действительно очень удачна. Именно таково официальное

название элемента нотации UML, позволяющего указать распределение ролей на

диаграмме активностей. Только дорожки это не беговые, а плавательные - они так и

называются: swimlanes. Более формально, дорожка - часть области диаграммы

деятельности, на которой отображаются только те деятельности, за которые отвечает

конкретный объект.

Предназначены они для разбиения диаграммы в соответствии с распределением

ответственности за действия. Имя дорожки может означать роль или объект, которому она

соответствует. При использовании дорожек нотация слегка изменяется. Вот как, к

примеру, выглядит диаграмма из предыдущего примера, перерисованная с

использованием дорожек:

Кстати, дорожки могут быть не только вертикальными, но, если вам так удобнее,

горизонтальными. Изображаются горизонтальные дорожки аналогично - просто

поверните "обычные" дорожки на 90 градусов против часовой стрелки!

286

Есть еще один нюанс нотации диаграмм активностей, о котором мы пока не

говорили: это так называемая траектория объекта, или поток объекта (object flow). Суть

его состоит в том, что на диаграмме деятельности можно изобразить и объекты,

относящиеся к деятельности. С помощью символа зависимости (пунктирная стрелка) эти

объекты можно соотнести с той деятельностью или переходом, где они создаются,

изменяются или уничтожаются. Представим такую ситуацию из повседневной жизни: вы

приходите в какой-нибудь ресторан быстрого питания и заказываете гамбургер с колой.

Во время приготовления завтрака повар создает новый объект - гамбургер. Пока вы

нетерпеливо выпиваете колу, официант перемещает этот объект (подает ваш заказ).

Естественно, во время завтрака вы уничтожаете этот объект. Вот как это выглядит на

диаграмме:

Мы говорили, что деятельность - это протяженное по времени составное действие.

То есть составленное из более простых действий. Вот эти-то самые простые (атомарные)

действия, а вернее, последовательность их выполнения, частенько изображают внутри

деятельности в виде маленькой диаграммы активностей. Это слегка напоминает матрешку

- одна (а часто и не одна) диаграмма внутри другой. Покажем пример:

287

Диаграмма описывает высадку пассажиров самолета, достигших пункта

назначения, и посадку новых пассажиров. Из нее, например, можно почерпнуть, что

конечных состояний может быть больше одного. Кстати, кроме начального и конечного

состояний есть еще конечное состояние потока (Flow final mode). От конечного состояния

оно отличается вот чем: конечное состояние потока означает завершение одного потока

управления, а конечное состояние говорит о завершении всех потоков управления внутри

деятельности. Обозначается конечное состояние потока простым символом,

напоминающим лампочку накаливания в схемах электрических цепей:

Примеры использования таких диаграмм.

На практике диаграммы деятельности применяются в основном двумя способами:

1. Для моделирования процессов

В этом случае внимание фокусируется на деятельности с точки зрения экторов,

которые работают с системой. В случае такого использования диаграмм деятельности

активно используются траектории объектов. Действительно, вспомним наш пример с

гамбургером: изменив роли и деятельности, легко представить на его месте некий

документ.

2. Для моделирования операций

288

В этом случае диаграммы деятельности играют роль "продвинутых" блок-схем и

применяются для подробного моделирования вычислений. На первое место при таком

использовании выходят конструкции принятия решения, а также разделения и слияния

потоков управления (синхронизации).

Рассмотрим подробнее первый случай. Все мы, конечно, понимаем бизнес-процесс

как последовательность неких действий, ведущую к достижению определенных бизнес-

целей. Когда мы произносим это слово, в голове рождается множество ассоциаций, как то:

люди, занимающие конкретные должности в управленческом аппарате (экторы),

документы, которые они создают (артефакты, объекты), процесс принятия решений и

передачи приказов по организационной цепочке (управляющие сигналы). Причем обычно

все эти сущности связаны друг с другом просто невообразимым количеством явных и

неявных связей, так что охватить взглядом целостную картину всего происходящего на

предприятии обычно не так просто. А как же тогда все это моделируют?

Моделируют бизнес-процессы в несколько этапов, первым из которых является

разбиение их на подпроцессы. Подпроцессы, являющиеся "участками большого

процесса", описать легче. А там, глядишь, и составится целое из частей. Дальше выделяют

ключевые объекты (и создают для них дорожки), определяют предусловия и постусловия

каждого процесса (т.е. его границы), описывают деятельности и переходы, отображают на

диаграммах состояния ключевых объектов, в которые они переходят в ходе процесса. Все

это звучит довольно сложно, а на практике происходит еще сложнее: ведь создается не

какая-то абстрактная диаграмма, а модель реального бизнес-процесса в реальной

компании, занимающейся реальным бизнесом, где цена ошибки может быть очень высока.

Приведем просто пример использования диаграммы активностей для описания процесса

разработки ПО в OpenUP:

289

Выглядит, конечно, не совсем так, как мы привыкли, но все же, сомнений не

остается - да, это именно диаграмма активностей. Нотация слегка отличается, но все

понятно и без дополнительных пояснений.

А теперь перейдем к рассмотрению моделирования операций с помощью диаграмм

активностей. Как мы уже говорили, в этом случае диаграмма активностей превращается в

"продвинутую" блок-схему, предоставляющую дополнительные возможности, например,

отображение параллельно выполняющихся операций. Возникает соблазн попытаться

выполнить кодогенерацию такой диаграммы или даже откомпилировать ее и сразу

получить выполняемый файл. Поспешим отметить, что вы не одиноки в таком желании -

попыток создать пакет для генерации приложений непосредственно из диаграмм UML

было предпринято множество. Некоторые даже оказались более-менее удачными -

вспомним, например, Rational Rose Real Time. Таким образом, при моделировании

операций UML становится языком визуального программирования!

Приведем пример моделирования одной из базовых алгоритмических конструкций,

например, цикла с постусловием:

290


Советы по построению диаграмм активностей.

Процесс построения диаграммы активностей можно описать в виде

последовательности таких действий:

1. Составление перечня деятельностей в системе

Как исходные данные для этой операции хорошо подходит список прецедентов

(или список операций - см. два способа использования диаграмм деятельности).

Дополняться диаграммой активности может каждый сценарий использования. Можно

также попытаться описать связь между ними.

2. Принятие решения о необходимости построения диаграммы

деятельностей

Несмотря на то, что вы уже начали работу в этом направлении, вы все же можете

решить отказаться от продолжения построения диаграммы деятельностей. Причины тому

могут быть различными, например, система одномоментно меняет свои состояния (как

светофор) или ее поведение достаточно очевидно. (зачем моделировать простые и

очевидные вещи?).

3. Определение зависимостей между деятельностями

Для каждой активности нужно найти активности, непосредственно

предшествующие (и следующие за ней тоже), то есть активности, без выполнения

которых поток управления не может перейти к данной деятельности.

4. Выделение параллельных потоков деятельностей

Выделите активности, имеющие общих предшественников. Зачем - думаем, и так

понятно.

5. Определение условий переходов

291

Сформулируйте выражения, которые могут принимать только два значения -

"истинно" или "ложно", соответствующие альтернативным потокам управления. Теперь

вы знаете, что писать рядом с символами принятия решений!

6. Уточните сложные деятельности

Повторите пункты 1-6 для каждой из деятельностей (при необходимости). Помните

пример с посадкой/высадкой пассажиров самолета? Присмотритесь внимательно,

возможно, в проектируемой вами диаграмме тоже будет нелишним применить "принцип

матрешки". А как это работает на практике? Рассмотрим, например, моделирование

пословицы "После драки кулаками не машут":

1. Выделяем деятельности: драться, махать кулаками.

2. Следует ли строить диаграмму в этом случае? Вообще-то нет. Но ведь это

пример!

3. Определяем зависимости между деятельностями: размахивание кулаками не

происходит после драки.

4. Определяем параллельные деятельности: вроде бы тут таких не

наблюдается...

5. Определяем условия переходов: драка состоялась? Если "нет", то машем

кулаками, если "да", то нет.

6. Уточняем сложные деятельности: при драке машут не только кулаками, но и

ногами. А еще можно пинаться головой и использовать подручные средства, мебель,

например. Плюс можно выделить еще подготовительные деятельности (выбор места для

нападения) и завершающие (вынос раненых).

Смешно, но смоделировать вполне можно. Ведь все уже разложено по полочкам,

остается нарисовать.

Угадайте, что это?

292

Шуточная диаграмма - подход к решению разнообразнейших проблем, знакомый

многим из нас, широко известный во всем мире:

293


Выводы:

Диаграммой деятельности можно дополнить любой элемент модели,

имеющий динамическое поведение.

Диаграммы деятельности являются частным случаем диаграммы состояний.

В отличие от блок-схем, диаграммы деятельности могут отображать

одновременно выполняемые действия.

На диаграммах активности можно использовать плавательные дорожки,

распределяющие деятельности в соответствии с ролями (объектами), их выполняющими.

Траектория объекта позволяет показать объекты, относящиеся к

деятельности, и моменты переходов этих объектов из одного состояния в другое.

Сложные деятельности можно дополнительно детализировать, разбив на

действия и изобразив "диаграмму в диаграмме".

Диаграммы деятельностей можно использовать для проектирования

процессов (например, бизнес-процессов) или операций (вычислений). Во втором случае

UML выступает в роли визуального языка программирования.

Диаграммы взаимодействия: подробно.

Диаграмма взаимодействия - это диаграмма, на которой представлено

взаимодействие, состоящее из множества объектов и отношений между ними, включая и

сообщения, которыми они обмениваются. Этот термин применяется к видам диаграмм с

акцентом на взаимодействии объектов (диаграммах кооперации, последовательности и

деятельности).

Диаграмма последовательностей - диаграмма взаимодействия, в которой

основной акцент сделан на упорядочении сообщений во времени.

Диаграмма кооперации - диаграмма взаимодействий, в которой основной акцент

сделан на структурной организации объектов, посылающих и получающих сообщения.

То есть диаграмма последовательности описывает (и именно поэтому так и

называется) последовательность, в которой объекты отправляют и получают сообщения,

а диаграмма кооперации - это аналог диаграммы последовательностей, который тоже

показывает обмен сообщениями между объектами, но акцентирует внимание на ролях,

которые объекты играют во взаимодействии. Эти два типа диаграмм вообще-то

взаимозаменяемы, и решение, какую именно из них использовать в каждом конкретном

случае, каждый проектировщик принимает исходя из личных предпочтений.

Диаграммы последовательностей и их нотация.

Диаграмма последовательностей показывает последовательность, в которой

объекты в процессе взаимодействия обмениваются сообщениями. Объект - это просто

294

прямоугольник, внутри которого указаны подчеркнутые имя объекта и название класса

(не обязательно), разделенные двоеточием. Объекты располагаются в верхней части

диаграммы друг за другом. Вниз от каждого объекта тянется пунктирная линия, которую

называют линией жизни объекта. Линия жизни объекта - это линия, которая изображает

существование объекта на протяжении некоторого промежутка времени, и чем длиннее

линия, тем дольше существует объект. Сообщения, которыми обмениваются объекты,

изображаются в виде стрелок, направленных от линии жизни одного объекта к линии

жизни другого. Линии жизни объектов, тянущиеся вниз, играют роль шкалы времени, так

что сообщения, отправленные ранее, расположены выше, чем отправленные позже. Таким

образом, последовательность сообщений легко читается "сверху вниз". Объект отправляет

сообщение в расчете на то, что оно вызовет некую реакцию и за этим последует некоторая

деятельность.

Еще одна вещь, которую можно увидеть на диаграммах последовательностей - это

длинные прерывистые полосы на линиях жизни. Таким образом обозначаются периоды

времени, когда объект имеет фокус управления, т.е. выполняет некоторое действие

(причем неважно как - непосредственно или путем вызова некоей подчиненной операции).

Фокус управления на диаграммах последовательностей часто не изображают: ведь и так

понятно, где он должен располагаться, достаточно взглянуть на положение стрелок,

изображающих сообщения. Рисовать фокус или нет - дело привычки каждого

проектировщика. Впрочем, многие средства UML-моделирования рисуют фокус

автоматически, так что человеку не нужно заботиться о его изображении. Если объект в

процессе взаимодействия разрушается, этот факт помечают на его линии жизни

крестиком, который эту линию и заканчивает.

Пример:

295

Еще несколько обозначений. Первое из них - это анонимный эктор, которого

изображают, если нужно показать использование объектов системы некоей внешней

сущностью или абстрактным пользователем. Второе - это рефлексивное сообщение.

Рефлексия – это самосозерцание, объект посылает сообщение самому себе. Так рисуют,

если нужно показать действие, выполняемое самим объектом (или внутри него), либо то,

что объект сам себя вводит в некоторое состояние:

И еще одно - мы легко можем представить ситуацию посылки сообщения в

зависимости от истинности некоторого условия. Например, если цена приглянувшейся

нам в магазине вещи меньше ста условных единиц, мы вполне можем приобрести ее за

наличные. Покупку на сумму от 100 до 1000 долларов можно оплатить кредитной картой,

а чтобы купить нечто, стоящее дороже 1000 у. е., придется брать кредит. Например:

Ветвление - конструкция для диаграмм последовательностей непопулярная и

используется она в них очень редко. Считается, что ветвления более присущи диаграммам

деятельностей.

Ранее мы говорили, что сообщение посылается объектом в расчете на

определенную реакцию, на то, что за этим последует некоторая деятельность. Например,

296

посылка ответного сообщения. Ответные сообщения изображают пунктирной линией со

стрелкой, хотя часто они имеют точно такой же вид, как и обычные сообщения, только

направлены в противоположную сторону. Как именно их рисовать - пунктирной линией

или сплошной - решать вам. Это не принципиально:

Есть еще деление сообщений на синхронные и асинхронные.

Синхронные сообщения приостанавливают поток выполнения до тех пор, пока не

будет получен ответ. Все сообщения, которые мы рассматривали в наших примерах, были

именно синхронными. Пусть мы и не везде рисовали ответное сообщение, но оно

подразумевалось: банк выносит решение о предоставлении кредита и сообщает его вам,

терминал кредитных карт подтверждает транзакцию и печатает чек, на котором вы

ставите подпись, кассир выдает вам подтверждение платежа - кассовый чек. Синхронные

сообщения изображаются сплошной линией с треугольной закрашенной стрелкой на

конце.

Другой вид сообщений - асинхронные сообщения. Они не ждут ответа, не

приостанавливают поток выполнения - сразу после их посылки происходит немедленный

переход к следующему шагу, и последовательность продолжается. Входя в офис поутру и

говоря коллегам "Привет, как дела?", вы ведь не ждете, что они остановят вас и начнут в

течение часа рассказывать о своих проблемах? Это просто формальное приветствие, не

предусматривающее ответа (асинхронное). Асинхронные сообщения изображаются

сплошной линией с обычной (составленной из двух отрезков) стрелкой на конце. А как

изображаются ответные сообщения, мы уже знаем:

297

Возможны случаи, когда нам известен адресат сообщения, но неизвестен его

отправитель. Такие сообщения называют найденными. Или обратный случай: отправитель

известен, а получатель - нет. Такие сообщения называют потерянными. На диаграммах

они изображаются так:

Рассмотрим "полный" пример диаграммы последовательностей:

298

Не правда ли, очень жизненный анекдот? А вот еще один пример, показывающий,

что, задав вопрос "сколько будет два плюс два?", вы не всегда услышите в ответ "четыре".

Ответ на любой вопрос всегда сильно зависит от личности, настроения, уровня интеллекта

отвечающего, даже от его профессии. Доказательство:

Диаграммы кооперации и их нотация.

Перейдем к рассмотрению альтернативы диаграммам взаимодействия –

диаграммам кооперации. Собственно, слово "кооперация" значит "совместная

деятельность", "сотрудничество". Такие диаграммы показывают, как объекты работают

вместе для достижения общей цели, акцентируясь на их ролях.

Мы уже говорили, что, подобно диаграммам последовательностей, диаграммы

кооперации предназначены для описания динамических аспектов моделируемой системы.

Обычно они применяются для того, чтобы:

показать набор взаимодействующих объектов в реальном окружении "с

высоты птичьего полета";

распределить функциональность между классами, основываясь на

результатах изучения динамических аспектов системы;

описать логику выполнения сложных операций, особенно в тех случаях,

когда один объект взаимодействует еще с несколькими объектами;

изучить роли, выполняемые объектами внутри системы, а также отношения

между объектами, в которые они вовлекаются, выполняя эти роли.

299


Говоря о диаграммах кооперации, часто упоминают два "уровня" таких диаграмм -

уровень экземпляров (примеров, Instance-Level) и уровень спецификации (Specification-

Level). В чем же разница? Ответ прост: уровень экземпляров отображает взаимодействия

между объектами (экземплярами классов); такая диаграмма обычно создается, чтобы

исследовать внутреннее устройство объектно-ориентированной системы. Уровень же

спецификации используется для изучения ролей, исполняемых в системе основными

классами. В любом случае, диаграмма взаимодействия не отображает процесс. Она

показывает взаимодействие между объектами, которое, как мы уже знаем, осуществляется

путем посылки и приема сообщений. При этом точная последовательность сообщений не

так хорошо видна, как на диаграмме последовательностей, так что если для вас важно

отобразить именно порядок отправки и приемов сообщений, используйте диаграмму

последовательностей.

На диаграммах взаимодействия вы увидите объекты, классы, сообщения, связи и

кооперации.

Кооперация (collaboration). Это статическая конструкция для моделирования

набора сущностей, взаимодействующих друг с другом. Кооперация определяет набор

взаимодействующих ролей, используемых вместе, чтобы показать некую

функциональность. Кооперация часто реализует некоторый паттерн (шаблон

проектирования). Кооперация изображается в виде эллипса с пунктирной границей,

причем символ этот может использоваться двумя способами. Первый способ:

Мы видим, что эта диаграмма буквально иллюстрирует наши слова о кооперации

как наборе ролей, используемых вместе, чтобы показать некую функциональность, в

данном случае - выполнение ежемесячного резервного копирования. Второй способ

показывает прикрепленные к объектам (классам) роли в рамках данной кооперации.

300

Назначение роли изображается пунктирной линией со стрелкой на конце, направленной в

сторону объекта. Имя роли указывается на конце линии, рядом с объектом. Например:

Скорее всего, в реальном моделировании с кооперацией вы будете встречаться

крайне редко. Следующие элементы, которые можно увидеть на диаграмме

взаимодействия - это объекты и классы.

Поскольку диаграмма кооперации - всего лишь альтернативная форма

представления той же информации, которая содержится в диаграмме

последовательностей, то и обозначения объектов (классов) в ней, по сути, такие же, как и

на диаграмме последовательностей (и на других диаграммах). Чтобы проиллюстрировать

это утверждение, приведем пример диаграммы взаимодействия:

Как видите, диаграмма иллюстрирует покупку некоторого товара (вероятно, в

онлайне) и оплату с помощью кредитной карты. Еще одна интересная вещь, которую

можно увидеть на этой диаграмме - это сообщения, вернее, то, как они изображаются.

Сообщения показаны в виде текста (названия метода) со стрелкой. Но есть один нюанс: на

диаграмме последовательностей было легко показать последовательность отправки

301


сообщений, так как линии жизни служили одновременно "осями времени",

направленными вниз, и, естественно, было видно, что нижние сообщения отправлены

позже верхних. В диаграммах взаимодействия проблему отображения очередности

сообщений решили просто - перед названием каждого сообщения просто пишут его

номер. Выглядит эта конструкция так: номер:название_сообщения. Причем часто

используют и составные номера. Например, объект отправил другому объекту сообщение

с номером 1. Когда объект-получатель в свою очередь отправляет сообщения другим

объектам, они получают номера 1.1, 1.2 и т. д. Иногда нужно показать одновременную

отправку сообщений. Чтобы отметить параллельные потоки сообщений, их номера

предваряют буквами A, B, C, D и т. д. Вот пример таких обозначений:

Обратите внимание на мультиобъекты. Мультиобъект показывает, что на

"дальнем" конце ассоциации находится не один, а целый набор объектов. Такая

конструкция используется, чтобы показать операцию, которая нацелена на целый набор

объектов. Мультиобъект изображается как два прямоугольника, смещенных по

отношению друг к другу, что создает впечатление "колоды карт". Сообщение,

отправленное мультиобъекту, означает сообщение к набору объектов, например, операция

выбора - поиска определенного объекта. Пример подобной диаграммы показан на

рисунке:

302

Смысл диаграммы вполне понятен: для печати документа из некоторого

приложения необходимо выбрать из всех доступных некий конкретный принтер. Символ

композиции применен для того, чтобы показать, что принтер входит в состав набора

объектов. Предположим теперь, что у нас доступны несколько сетевых принтеров и один

локальный. Как показать, что выбран именно он? Легко. Для этого используют связи со

стереотипами. Чтобы показать, что выбран локальный принтер, чуть изменим

предыдущую диаграмму:

Следует отметить, что иногда вместо фигурных скобок используются угловые

кавычки (как мы привыкли делать, указывая стереотип в названии компонента или

класса), но чаще все же применяют фигурные скобки. Измененная диаграмма стала еще

более понятной. Приведем еще один пример:

303

Смысл диаграммы вполне понятен. А стереотипы связей позволяют исключить

неоднозначности, которые могли бы быть, если бы мы говорили, например, о

многонациональной распределенной компании.

И еще одна вещь, которая связана с понятием кооперации - композитный объект.

Композитный объект - это высокоуровневый объект, состоящий из нескольких частей-

объектов. Это экземпляр композитного класса, реализующего композитное агрегирование

класса и его частей. Композитный объект - понятие, близкое к понятию кооперации, но

более простое и более ограниченное. Это конструкция, показывающая целое в виде

взаимодействующих частей, но в основном с точки зрения композиции. Изображается

композитный объект в виде прямоугольного символа объекта, но с некоторыми

отличиями:

имя объекта указывается в верхней части прямоугольника, отделенной от

его остальной части горизонтальной линией;

в нижней части прямоугольника размещаются части композитного объекта,

также, естественно, изображаемые символами объектов;

части композитного объекта могут (и даже должны) быть связаны между

собой;

допускается ситуация, когда некоторые части композитного объекта сами

являются композитными объектами.

Посмотрим, как это выглядит на примере:

304

Упрощенная модель графического окна проста и понятна. Окно имеет заголовок,

рабочую область и две полосы прокрутки - горизонтальную и вертикальную, которые ее

перемещают.

Композитный объект лишь близок по значению к кооперации, но не встречается на

диаграммах взаимодействия "в чистом виде". На диаграммах взаимодействия иногда

можно увидеть очень близкую по смыслу конструкцию, а именно активный объект.

Активными называют объекты, которые владеют собственным потоком управления и

могут инициировать выполнение действий. Пассивные объекты содержат данные, но не

могут инициировать выполнение. Конечно, пассивные объекты могут посылать

сообщения в процессе обработки полученных запросов. Активный объект (или, вернее,

его роль) выглядит на диаграмме как прямоугольный символ объекта, но с утолщенными

границами. Часто активный объект изображается как композитный объект, содержащий

объекты-части. Например:

305

Как видите, все объекты, отображенные на диаграмме, являются активными. Таких

объекта три - это робот, печь и менеджер цеха, который изображен как композитный

активный объект.

Вообще же, если говорить о композитных объектах, то следует отметить, что в

UML 2 появился новый тип диаграмм - композитная структурная диаграмма. Она

показывает внутреннюю структуру элемента, включая точки взаимодействия с другими

частями системы. Таким образом, отображается состав и отношения между частями,

которые совместными усилиями реализуют поведение элемента. Пример композитной

диаграммы. Это модель велосипеда через композитные объекты:

306

Кроме внутренних частей, на таких диаграммах можно увидеть еще одно

новшество UML 2 - порты. Порт - это типизированный элемент, который представляет

"видимую снаружи" часть содержащего его элемента. Порт, как это и следует из названия,

определяет взаимодействие элемента модели с окружающей его средой. Порт может

размещаться на границе части, класса или композитной структуры. Порт может описывать

сервисы, предоставляемые элементом модели (и требуемые окружающей его средой).

Изображается порт как именованный (недаром же мы ранее сказали "типизированный")

прямоугольник на границе содержащего его элемента модели (впрочем, иногда можно

увидеть символ порта и внутри символа класса - тогда говорят, что класс имеет скрытый

порт). Так это выглядит на диаграмме:

Рекомендации по построению диаграмм взаимодействия.

Каким же образом и в какой последовательности следует действовать, чтобы

построить качественную диаграмму взаимодействия? Начинать нужно с выделения тех и

только тех классов, объекты которых участвуют в моделируемом вами взаимодействии.

Затем все объекты наносим на диаграмму. Следует также определить те объекты, которые

будут существовать постоянно, и те, которые будут существовать только во время

выполнения ими действий в рамках моделируемого взаимодействия.

307

Так, объекты нарисованы, можно переходить к сообщениям. Возможно, чтобы

лучше передать роли, играемые объектами во взаимодействии, понадобится использовать

различные разновидности сообщений и стереотипы. Для уничтожения объектов, которые

существуют только во время выполнения неких действий, тоже нужно предусмотреть

специальные сообщения.

А если есть ветвления? Самые простые случаи ветвлений процесса взаимодействия

можно показать и на одной диаграмме - помните пример с разными способами платежа в

зависимости от стоимости приглянувшейся вещи? Но при изображении ветвлений

диаграмма становится более сложной для понимания "с лету". Нужно соблюдать баланс

между детализацией и сложностью: лучше каждый альтернативный поток управления

показывать на отдельной диаграмме. В таком случае следует рассматривать такие

"частные" диаграммы в комплексе, как одну модель взаимодействия.

Если же хочется еще больше детализировать диаграмму, можно ввести временные

ограничения на выполнение отдельных действий. Впрочем, для простых асинхронных

сообщений временные ограничения, скорее всего, не нужны. А вот необходимость

синхронизации сложных потоков управления часто требует использования таких

ограничений. Запись их должна следовать правилам языка объектных ограничений (OCL,

Object Constraint Language).

Выводы:

Диаграмма последовательностей - диаграмма взаимодействия, в которой

основной акцент сделан на упорядочении сообщений во времени.

Диаграмма кооперации - альтернативная форма представления информации,

содержащейся в диаграмме последовательностей.

Диаграмма кооперации - диаграмма взаимодействий, в которой основной

акцент сделан на структурной организации объектов, посылающих и получающих

сообщения.

Существуют различные типы сообщений: синхронные, асинхронные и

ответные, потерянные и найденные.

Диаграммы кооперации бывают двух "уровней" - уровня экземпляров и

уровня спецификации.

Кооперация - это статическая конструкция для моделирования набора

сущностей, взаимодействующих друг с другом.

С диаграммами кооперации связаны такие понятия, как мультиобъекты,

композитные объекты и активные объекты.

308

Диаграммы прецедентов: подробно.

Несколько слов о требованиях.

Что такое требования, мы, в общем, понимаем - когда заказчик описывает нам, чего

же именно он хочет, мы всегда слышим фразы типа "хотелось бы, чтобы проверка

обновлений проводилась автоматически, как в антивирусах", "хочу большую зеленую

кнопку в центре окна, которая начинает процесс", "программа должна позволять

просматривать и печатать отчеты", "и чтоб красивенько все было", "при выходе должно

выводиться подтверждение" и т.д. и т.п. Конечно, как настоящие разработчики, мы

понимаем и то, что заказчик никогда не знает, что именно ему нужно, а если понимает, то

объяснить не может. Требования описывают, как заказчик представляет себе систему,

чего заказчик хочет от системы, функциональность, которой он от нее ожидает,

требования, которые к ней предъявляет.

Требование - это желаемая функциональность, свойство или поведение системы.

Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс

разработки ПО в виде "черного ящика", на выходе которого мы получаем программный

продукт, то на вход этого "черного ящика" будет подаваться именно набор требований к

программному продукту:

Этот рисунок напоминает диаграмму активностей. И выбор именно этой

диаграммы тут абсолютно оправдан – именно диаграммы активностей часто используют

для описания бизнес-процессов. Единственный нюанс: обычно процесс разработки не

заканчивается с выпуском программного продукта - грядет новая итерация, новые,

уточненные требования, новая версия и т.д.

Вернемся к требованиям. На вход нашего "черного ящика" подается набор

требований. Но в какой форме? Как их документируют, эти требования? Существует

техническое задание - основной документ, без составления которого не начинается ни

один проект. Это объемный документ с четкой структурой, определяемой ГОСТами,

описывающий очень детально требования к разрабатываемой системе.

Со временем техническое задание уступило место набору, состоящему из

документов двух видов:

диаграммы прецедентов;

309

нефункциональные требования.

Диаграммы прецедентов составляют модель прецедентов (вариантов

использования, use-cases). Прецедент - это функциональность системы, позволяющая

пользователю получить некий значимый для него, ощутимый и измеримый результат.

Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой

системой в ответ на запрос пользователя, т.е. определяет способ использования этой

системы. Именно по этой причине use cases, или прецеденты, часто в русской

терминологии фигурируют как варианты использования. Варианты использования чаще

всего применяются для спецификации внешних требований к проектируемой системе или

для спецификации функционального поведения уже существующей системы. Кроме

этого, варианты использования неявно описывают типичные способы взаимодействия

пользователя с системой, позволяющие корректно работать с предоставляемыми системой

сервисами.

Нефункциональные требования - это описание таких свойств системы, как

особенности среды и реализации, производительность, расширяемость, надежность и т. д.

Часто нефункциональные требования не привязаны к конкретному варианту

использования и потому выносятся в отдельный список дополнительных требований к

системе:

Вернемся к прецедентам (вариантам использования). Идентифицировать

прецеденты и действующие лица - обязанность системного аналитика. Делает он это для

того, чтобы:

четко разграничить систему и ее окружение;

310

определить, какие действующие лица и как именно взаимодействуют с

системой, какой функционал (варианты использования) ожидается от системы;

определить и описать в словаре предметной области (глоссарии) общие

понятия, которые необходимы для детального описания функционала системы

(прецедентов).

Подобный вид деятельности обычно выполняется в такой последовательности:

1. Определение действующих лиц.

2. Определение прецедентов.

3. Составление описания каждого прецедента.

4. Описание модели прецедентов в целом (этот этап включает в себя создание

словаря предметной области).

Вначале требования оформляются в виде обычного текстового документа, который

создается или самим пользователем, или пользователем и разработчиком вместе. Далее

требования оформляют в виде таблицы. В левую колонку помещают прецеденты, а в

правую - действующих лиц, участвующих в прецеденте.

Рассмотрим пример. Секретарь размещает на сервере меню обеденных блюд на

неделю. Сотрудники должны иметь возможность ознакомиться с меню и сделать заказ,

выбрав блюда на каждый день следующей недели. Офис-менеджер должен иметь

возможность сформировать счет и оплатить его. Система должна быть написана на

ASP.NET. Такое вот нехитрое интернет-приложение для автоматизации заказов обедов в

офис.

Таблица с описанием требований может быть, например, такой:

Прецедент Действующее лицоразместить меню секретарьознакомиться с меню сотрудник, секретарь, офис-менеджерсделать заказ сотрудник, секретарь, офис-менеджерсформировать счет офис-менеджероплатить счет офис-менеджер

Здесь нигде не сказано о том, что система должна быть написана на ASP.NET.

Почему - понятно: это ведь нефункциональное требование! И еще, очевидно, что

секретарь и офис-менеджер тоже являются сотрудниками. Создавая модель прецедентов,

говоря о действующих лицах, можно бы применить генерализацию:

311

Диаграммы прецедентов и их нотация.

Какие элементы мы видим на диаграмме? Первое, что бросается в глаза, - большой

прямоугольник, внутри которого размещаются эллипсы, обозначающие, как мы уже

поняли, прецеденты. В верхней части прямоугольника указано название моделируемой

системы, а называют его рамками системы (system boundary, subject boundary),

контекстом или просто системой. Этот элемент диаграммы показывает границу между

тем, что вы как аналитик показали в виде прецедентов (внутри этих рамок), и тем, что вы

изобразили как действующие лица (вне их). Чаще всего таким прямоугольником

показывают границы самой моделируемой системы. То есть внутри границы находятся

прецеденты - тот функционал, который реализует система (и в этом смысле прецеденты

могут рассматриваться как представления подсистем и классов модели), а снаружи -

действующие лица: пользователи и другие внешние сущности, взаимодействующие с

моделируемой системой.

Следует сказать, что рамки системы на диаграммах прецедентов изображают

довольно редко, т.к. они неявно подразумеваются самой диаграммой. По сути, этот

элемент не привносит в диаграмму какой-либо дополнительной значимой информации,

так что его использование - дело вкуса аналитика. Появление рамок системы на

диаграмме прецедентов чаще всего диктуется особенностями персонального стиля


Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида

связанных с ней сущностей - это действующие лица (экторы, actors) и прецеденты.

Начнем с экторов. Довольно часто в русскоязычной литературе по UML для обозначения

действующих лиц можно встретить термин "актер". В принципе, смысл его более-менее

понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна

312

причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите

слово "актер"? Да, конечно же - слово "роль"! Именно о ролях мы вскоре и поговорим,

когда будем пытаться разобраться, что скрывается за понятием "действующее лицо". А

пока, да простит нас читатель, далее мы все же будем пользоваться словом "эктор" -

транскрипцией оригинального термина.

Итак, какой же смысл вкладывают в понятие эктора? Эктор - это набор ролей,

которые исполняет пользователь в ходе взаимодействия с некоторой сущностью

(системой, подсистемой, классом). Эктор может быть человеком, другой системой,

подсистемой или классом, которые представляют нечто за пределами рассматриваемой

сущности. Экторы "общаются" с системой путем обмена сообщениями. Четко выделив

экторов, вы тем самым ясно определяете границу между тем, что внутри системы, и тем,

что снаружи, - рамки системы.

Возможно, слова "роли, исполняемые пользователем" в определении эктора звучат

не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor: роль - это не

конкретный пользователь, а подобие шляпы, которую человек надевает, когда

взаимодействует с сущностью.

Действительно, наденьте шляпу пирата - и вы капитан Джек Воробей, а наденьте

цилиндр и вы - Джек-потрошитель! "Физический" пользователь может играть роль одного

или даже нескольких экторов, выполняя их функции в ходе взаимодействия с системой. И

наоборот, роль одного и того же эктора может выполняться несколькими пользователями.

На диаграммах UML экторы изображаются в виде стилизованных человечков:

Несмотря на "человеческий" вид этого обозначения, не следует забывать, что

экторы - это не обязательно люди. Эктором, как мы уже говорили ранее, может быть

внешняя система, подсистема, класс и т.д. Кстати, человечек ("stick-person") - это не

единственное обозначение эктора, используемое в UML. На диаграммах прецедентов

обычно применяется именно "человекоподобная" форма эктора, но на других диаграммах,

и особенно в случаях, когда эктор имеет атрибуты, которые важно показать,

используется изображение эктора как класса со стереотипом <<actor>>:

313

С системой экторы, как мы уже сказали, общаются через сообщения, но если

говорить на более высоком уровне абстракции, в терминах модели прецедентов, то

взаимодействуют они с системой через прецеденты. Один и тот же эктор может быть

связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с

несколькими разными экторами. Ассоциации между эктором и прецедентом всегда

бинарные - т.е. представляют отношения типа "один к одному", использование кратности

недопустимо. Это не противоречит сказанному выше: действительно, один эктор может

быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций -

по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели

ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого

обозначения вполне понятен: это направленная ассоциация и стрелка (как и на других

диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим

сервисом пользуются и т.д.

Экторы не могут быть связаны друг с другом. Единственное допустимое

отношение между экторами - генерализация ( наследование ). Опять-таки, в нашем

примере с заказом обедов в офис, вы могли увидеть именно такой вид отношений между

экторами. Это не значит, что в реальной жизни офис-менеджер и секретарь (да и вообще

любые два сотрудника) не могут общаться: просто при создании модели прецедентов

такое общение не попадает в область наших интересов, считается несущественным.

Еще один тип элементов, встречающийся на диаграммах прецедентов, более того,

давший им название, - это собственно прецеденты, или варианты использования.

Прецедент - это описание набора последовательных событий (включая возможные

варианты), выполняемых системой, которые приводят к наблюдаемому эктором

результату. Прецеденты описывают сервисы, предоставляемые системой экторам, с

которыми она взаимодействует. Причем прецедент никогда не объясняет, "как" работает

сервис, а только описывает, "что" делается.

Изображаются прецеденты в виде эллипса, внутрь контура которого помещается

имя (описание) прецедента. Имя прецедента обычно намного длиннее имен других

элементов модели. Почему это так, в принципе, понятно: имя прецедента описывает

взаимодействие эктора с системой, говорит о том, какими сообщениями они

обмениваются между собой. В нашем примере с заказом обедов мы видели несколько

прецедентов и наверняка читатель заметил, что имя прецедента - это, скорее, название

314

сценария, воспроизводящегося в ходе взаимодействия эктора с системой. Причем это

всегда описание с точки зрения эктора, описание услуг, предоставляемых системой

пользователю. Приведем пример простейшей диаграммы, иллюстрирующей сказанное

нами об обозначениях прецедента:

В этом примере пассажир может купить в сервисной кассе билет на некоторый вид

транспорта. Покупка билета - это название сценария, по которому эктор (пассажир) может

взаимодействовать с системой (кассой). Заметьте, это не описание сценария, а именно

название - оно говорит нам, что делает эктор в процессе взаимодействия, но не говорит,

как именно! И еще - прецеденты определяют непересекающиеся сценарии поведения.

Выполнение одного прецедента не может быть прервано в результате работы другого

прецедента. Другими словами, выполнение одного прецедента не может быть прервано в

результате событий или действий, вызванных выполнением другого прецедента.

Прецеденты выступают как атомарные транзакции, выполнение которых не может быть

прервано.

Появился термин "сценарий". Сценарий - это конкретная последовательность

действий, иллюстрирующая поведение. Сценарий - это повествовательный рассказ о

совершаемых эктором действиях, история, эпизод, происходящий в данных временных

рамках и данном контексте взаимодействия.

Сценарии (в различных формах представления) широко применяются в процессе

разработки программного обеспечения. Как мы уже только что отметили, написание

сценария напоминает написание художественного рассказа, и этим объясняется тот факт,

что использование сценариев широко распространено среди аналитиков, которые часто

обладают художественными или литературными способностями. Несмотря на

непрерывный повествовательный характер, сценарии можно рассматривать как

последовательности действий (делать раскадровку). При разработке пользовательского

интерфейса сценарии описывают взаимодействие между пользователем (или категорией

пользователей, например, администраторами системы, конечными пользователями) и

315

системой. Такой сценарий состоит из последовательного описания комбинаций отдельных

действий и задач (например, нажатий клавиш, щелчков по элементам управления, ввода

данных в соответствующие поля и т. д.). Вспомните, к примеру, описания

последовательностей действий пользователя (предназначенных для достижения

определенных результатов, решения определенных задач), которые вы находите в справке

к малознакомой программе. То же самое можно сказать о модных сейчас "how-to videos",

в которых такие последовательности отображаются визуально, на конкретных примерах.

В любом случае, цель подобных справочных материалов - предоставить описание

типичных сценариев использования системы, сценариев взаимодействия между

пользователем и системой.

Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их

изображают в виде "листа бумаги", на котором написано имя файла, - прямоугольника с

загнутым нижним левым уголком. В этом случае указанный файл содержит в себе

описание данного сценария. А иногда сценарий записывается в комментарий. Как вы,

наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с

загнутым верхним правым углом и соединяются с элементом, который они поясняют,

пунктирной линией:

Как мы уже упоминали, сценарии могут быть записаны в различных формах. Это

может быть структурированный, но неформализованный текст, формализованный

структурированный текст, псевдокод, таблица, диаграмма активностей. Каждый сценарий

описывает в повествовательной форме завершенное, конкретное взаимодействие,

имеющее с точки зрения пользователя определенную цель. Если рассматривать

табличную форму представления сценария, то линия, разделяющая левый и правый

столбцы таблицы, символизируют собой границу, отделяющую действия пользователя от

ответных действий системы. Табличная форма особо подчеркивает участие пользователя,

что является очень важным аспектом при разработке пользовательского интерфейса.

Вот пример простого (неформализованного) текстового описания сценария.

316

Пользователь вводит логин, пароль, адрес электронной почты и код

подтверждения и нажимает кнопку "Далее". Система запрашивает ввод проверочного

кода. Пользователь вводит код и нажимает кнопку "Далее". Система проверяет

соответствие кода изображенному на картинке.

Это описание регистрации пользователя на некотором сайте. Правда, не совсем

полное: не рассмотрены случаи, когда выбранный пользователем логин уже занят, адрес

электронной почты введен неправильно, пароль не удовлетворяет требованиям или код не

соответствует изображенному на картинке. О таких случаях - альтернативных сценариях

- мы поговорим чуть позже.

А вот тот же сценарий в табличном представлении:

Действия пользователя Реакция системыВвод логина, пароля, адреса электронной почты и нажатие кнопки "Далее"

Запрос ввода проверочного кода

Ввод проверочного кода и нажатие кнопки "Далее" Проверка кода на соответствие изображенному на картинке

Вы, конечно, заметили, что этот сценарий можно детализировать - например,

прежде чем попросить ввести проверочный код, система отображает картинку, на которой

этот самый код изображен. Т.е. запрос на ввод кода включает в себя вывод картинки с

упомянутым кодом. Об этом мы тоже еще поговорим.

Как связаны понятия сценария и прецедента? Прецеденты, как мы уже говорили,

рождаются из требований к системе. Но говорят они о том, что делает система. Как

система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать

путем описания потока действий или событий в текстовой форме - в виде, понятном для

"постороннего" (не занятого в непосредственной разработке системы) читателя. А такое

описание - это и есть сценарий. Таким образом, сценарии специфицируют прецеденты. И

еще. Поскольку сценарии - это, по сути, рассказы, они являются весьма эффективным

средством извлечения информации из бесед с заказчиком и предоставляют превосходное,

понятное непрофессионалу описание создаваемого приложения. Сценарии, да и вообще

диаграммы прецедентов (дополненные сценариями) являются отличным средством

общения между разработчиками и заказчиком, причем, в силу простоты нотации, -

средством, понятным обеим сторонам. В конечном итоге, взаимосвязь между

требованиями, прецедентами и сценариями можно изобразить такой "псевдодиаграммой":

317

Как видите, для каждой ассоциации на диаграмме проставлена кратность и ее

смысл вполне понятен, но все же о кратности следует поговорить отдельно. Один

прецедент определяет несколько сценариев, каждый из которых представляет один из

возможных вариантов определяемого прецедентом потока событий. Сценарии так же

соотносятся с прецедентами, как экземпляры класса, т.е. сценарий - это экземпляр

прецедента, как объект - экземпляр класса. Система может содержать, например,

несколько десятков прецедентов, каждый из которых, в свою очередь, может

разворачиваться в десятки сценариев. Как правило, прецедент описывает не одну

последовательность действий, а множество, и выразить все детали рассматриваемого

прецедента с помощью одной последовательности действий обычно не получается.

Практически для любого прецедента можно выделить основной сценарий, описывающий

"нормальную" последовательность действия, и вспомогательные, описывающие

альтернативные последовательности, которые инициируются в случае возникновения

определенных условий.

Другой вопрос: требуется ли такое уточнение модели прецедентов, оправдано ли

оно для данного уровня приближения, или "подразумевающиеся" альтернативные

сценарии можно опустить? Например, в предыдущем примере с покупкой билета в

сервисной кассе мы не изобразили сценарии (и, соответственно, прецеденты),

соответствующие вариантам, когда билетов на выбранный пассажиром рейс уже не

осталось, пассажир изменил свое решение и хочет взять билет на другой рейс, когда

оплата идет наличными или по кредитной карте и т. д.

318

Отношения между прецедентами весьма многообразны.

Начнем с отношения обобщения (наследования, генерализации). О генерализации

мы уже говорили не раз, когда рассматривали диаграммы классов. Но все же напомним

суть этого понятия. Обобщение - это отношение специализации (обобщения), в котором

объекты специализированного элемента (потомка) могут быть подставлены вместо

объектов обобщенного элемента (родителя, или предка).

Точно так же, как мы обычно поступаем с классами, после того как мы выделили и

описали каждый прецедент, мы должны просмотреть их все на предмет наличия

одинаковых действий - поискать, а не выполняются ли (используются) некоторые

действия совместно несколькими вариантами использования. Этот совместно

используемый фрагмент лучше описать в отдельном прецеденте. Таким образом мы

уменьшим избыточность модели за счет применения обобщения прецедентов (иногда,

правда, говорят не об обобщении, а об использовании прецедентов; почему - сейчас

поймете). Как это и "положено" при наследовании, экземпляры обобщенных прецедентов

(потомков) сохраняют поведение, присущее обобщающему прецеденту (предку). Другими

словами, наличие (использование) в варианте использования X обобщенного варианта

использования Y говорит нам о том, что экземпляр прецедента X включает в себя

поведение прецедента Y. Обобщения применяются, чтобы упростить понимание модели

вариантов использования за счет многократного задействования "заготовок" прецедентов

для создания прецедентов, необходимых заказчику (помните, как мы рассматривали

вопрос о том, всегда ли необходимо создавать новый класс, или лучше воспользоваться

готовым решением, чувствуете аналогию?). Такие "полные" прецеденты называются

конкретными прецедентами. "Заготовки" прецедентов, созданные лишь для

многократного использования в других прецедентах, называют абстрактными

прецедентами. Абстрактный прецедент (как и абстрактный класс) не существует сам по

себе, но экземпляр конкретного прецедента демонстрирует поведение, описываемое

абстрактными прецедентами, которые он (повторно) использует. Прецедент, который

экторы наблюдают при взаимодействии с системой ("полный" прецедент, как мы

называли его ранее), часто называют еще " реальным " прецедентом.

Как мы уже говорили выше, обобщение (наследование) чаще всего используют

между классами и интерфейсами. Однако другие элементы модели также могут

находиться между собой в отношении наследования - например, пакеты (о которых мы

тут не говорим), экторы, прецеденты...

Изображается обобщение линией с "незакрашенной" треугольной стрелкой на

конце. Обобщение - это отношение между предком и потомком, и стрелка всегда

319

указывает на предка. Если вспомнить, что потомки наследуют (используют) свойства

предка, то вполне логично вспоминается наше утверждение о том, что стрелки в UML

всегда направлены в сторону того, от кого что-то требуют, чьими сервисами пользуются:

Как мы уже говорили ранее и видели в нашем первом примере диаграммы

прецедентов, обобщение может использоваться для создания различных разновидностей

экторов. Экторы-потомки наследуют от предка базовые характеристики и дополняют их

своей спецификой. Точно так же прецедент-потомок наследует поведение и семантику

прецедента-родителя и дополняет его поведение.

Следующий вид отношений между прецедентами - включение. Отношение

включения означает, что в некоторой точке базового прецедента содержится поведение

другого прецедента. Включаемый прецедент не существует сам по себе, а является всего

лишь частью объемлющего прецедента. Таким образом, базовый прецедент как бы

заимствует поведение включаемых, раскладываясь на более простые прецеденты.

Например, когда мы покупаем в магазине некоторую вещь, в момент считывания

кассиром штрих-кода обновляется состояние базы данных товаров, имеющихся в

наличии, - количество наличных единиц купленного товара уменьшается. То же самое

действие выполняется и в том случае, если купленный товар оказался бракованным,

непригодным к использованию или попросту нам не понравился: состояние упомянутой

базы данных вновь обновляется - но теперь уже в сторону увеличения количества

наличных единиц определенного товара. Т.е. оба этих действия - и покупка, и возврат -

содержат (включают в себя) такое действие, как обновление содержимого БД.

Включение изображается как зависимость (пунктирная линия со стрелкой,

помните?) со стереотипом <<include>>. При этом стрелка направлена, естественно, в

320

сторону включаемого прецедента. Этот факт легко объяснить, если вспомнить

утверждение, которое мы уже несколько раз использовали в этом курсе: стрелка всегда

направлена в сторону того элемента, от которого что-то требуется, чьими сервисами

пользуются. А если считать, что объемлющий прецедент включает в себя, заимствует

(использует) поведение включаемых прецедентов, становится ясно, что стрелка может

быть направлена только таким образом. Пример:

Как хорошо видно из этого примера, использование включения позволяет избежать

многократного описания одного и того же набора действий - общее поведение можно

просто описать в виде прецедента, включаемого в базовые.

Далее - отношение расширения. Чтобы уяснить себе смысл расширения,

представим себе, что мы говорим об оплате некоторого купленного нами товара. Мы

можем оплатить товар наличными, если сумма не превышает $100. Или оплатить

кредитной картой, если сумма находится в пределах от $100 до $1000. Если же сумма

превышает $1000, нам придется брать кредит. Таким образом, мы расширили понимание

операции оплаты купленного товара и на случаи, когда используются другие средства

оплаты, нежели наличные. Но сами эти случаи возникают только при строго

определенных условиях: когда цена товара попадает в определенные рамки.

Расширение дополняет прецедент другими прецедентами, "срабатывающими" при

некоторых условиях, - просто добавляет в исходный прецедент последовательность

действий, содержащуюся в другом прецеденте. Отношение расширения прецедента А к

прецеденту В означает, что экземпляр прецедента В может включать в себя (при

321


определенных условиях, которые могут быть описаны в расширении; как именно

описаны, мы скажем чуть позже) поведение, описанное в прецеденте А. Пример показан

на следующей диаграмме:

Однако в приведенном примере не видно, при каких именно условиях человек

использует каждый конкретный способ оплаты. В то же время, при моделировании с

использованием расширения можно указать как условия осуществления расширенного

поведения, так и место - точку расширения прецедента, в которой подключаются

действия из расширяющих прецедентов. Вспомните оператор безусловного перехода,

который вы, надеемся, использовали в своих программах не слишком часто. Как только

интерпретатор доходит до этого оператора, он передает управление на строку, которая

помечена меткой, указанной в этом операторе. Правда, в случае расширения речь идет

скорее об операторе условного перехода - когда исходный прецедент (а именно,

последовательность действий, содержащаяся в нем) приходит в точку расширения,

происходит оценка условий расширения. Если условия выполняются, прецедент включает

в себя последовательность действий из расширяющего прецедента.

Точка расширения описывается в дополнительном разделе прецедента, отделенном

от его названия горизонтальной линией - точно так же, как в отдельных разделах

перечисляются атрибуты класса и его операции. Ниже показан пример описания точки

расширения:

322

В этом примере регистрация пассажиров авиарейса включает в себя контроль

службы безопасности, а при условии (указанном в примечании после служебного слова

"Condition:"), что человек часто летает и салон переполнен (обратите внимание на

оператор AND, говорящий об одновременности выполнения условий), класс билета может

быть повышен, например, с "эконом" до "бизнес-класса". Причем такой апгрейд может

произойти только после того, как билет предъявлен на стойку регистрации - это и есть

точка расширения. Она описана (ее имя указано) в дополнительном разделе прецедента

после служебной фразы "Extension points:". Предваряя вопрос читателя, скажем, что

прецедент может иметь сколь угодно много точек расширения. А сопоставить конкретный

расширяющий прецедент с определенной точкой расширения можно, прочитав условия

расширения, указанные в комментариях, - само условие записывается после служебного

слова "Condition:" в фигурных скобках, за которыми идет служебная фраза "Extension

point:", и после нее указывается имя точки расширения.

Некоторое недоумение может вызвать то, что стрелка направлена всегда в сторону

расширяемого прецедента. Но и это легко объяснить с точки зрения нашего тезиса, что

"стрелка всегда указывает на того, от которого что-то требуют": ведь для того, чтобы

прецедент был расширен, нужно, чтобы он попал в точку расширения и проверилась

истинность условий - только тогда действия, содержащиеся в расширяющем прецеденте,

смогут быть добавлены в последовательность действий исходного прецедента. Так что все

правильно - от расширяемого прецедента требуется точка расширения и проверка

условий, потому и стрелка направлена к нему.

Подытоживая все вышесказанное, можно сказать, что расширение позволяет

моделировать необязательное поведение системы (был бы класс билета повышен, если

бы пассажир не налетал нужного количества миль, а салон был бы почти пуст?). Сам факт

расширения зависит от выполнения условий - расширения ведь может и не произойти!

323

Это просто отдельные последовательности действий, выполняемые лишь при

определенных обстоятельствах и включаемые в определенных точках сценария (обычно в

результате явного взаимодействия с эктором).

Организация прецедентов с помощью выделения общего поведения (включение) и

различных вариантов поведения (расширение) - важная составляющая часть процесса

разработки простого, сбалансированного и понятного набора прецедентов. Можно сказать

даже, что использование включения и расширения - признак хорошего стиля в

моделировании прецедентов.

Моделирование при помощи диаграмм прецедентов.

Модель прецедентов, по сути, является концептуальной моделью системы. В ней,

как мы уже не раз отмечали, в общих чертах описывается только поведение

(функциональность) системы, а о деталях реализации речь не идет - на данном этапе

реализация не важна, гораздо важнее собрать требования к системе и оформить их в

наглядном виде, понятном и разработчикам, и заказчику.

Итак, подводя итоги, мы можем сформулировать три причины использования

прецедентов. Или, вернее, три способа использования прецедентов (не случайно в русском

переводе частенько можно встретить словосочетание "вариант использования"!) в ходе

работы над системой:

Прецеденты дают возможность аналитикам, пользователям и

разработчикам говорить на одном языке: используя прецеденты, аналитики (эксперты в

предметной области) могут на основе пожеланий заказчика описать поведение системы с

точки зрения пользователя с такой степенью детализации, что разработчики смогут без

труда сконструировать "внутренности" системы. В то же время, нотация диаграмм

прецедентов настолько проста, что даже неподготовленный пользователь (заказчик)

способен понять их смысл и помочь в их уточнении - ведь картинки (а тем более комиксы,

каковыми, по сути, являются диаграммы UML) воспринимаются намного легче, чем

текст!

Прецеденты позволяют разработчикам понять назначение элемента:

система, подсистема или даже класс могут быть сложными образованиями, состоящими

из большого числа составных частей и имеющими большое число атрибутов и операций.

Моделирование прецедентов позволяет лучше представить себе поведение системы,

понять, какие элементы модели играют какие роли в реализации этого поведения, в какие

кооперации входят, и какой именно прецедент (функционал системы) реализуют.

Прецеденты являются основой для тестирования элемента в течение всей

разработки: модель прецедентов описывает желаемое поведение системы (ее

324

функционал) с точки зрения пользователя. Так что, постоянно сопоставляя

предоставляемый элементом (фактический) функционал с имеющимися прецедентами,

можно надежно контролировать корректность реализации элемента. Вот вам и надежный

источник регрессионных тестов. Кроме этого, появление нового прецедента зачастую

заставляет пересмотреть реализацию элемента, дабы убедиться, что она обладает

достаточной гибкостью, изменяемостью и масштабируемостью.

Прецеденты полезны и для прямого, и для обратного проектирования. При прямом

проектировании мы, по сути, осуществляем "перевод" с UML на некий язык

программирования. И тестировать созданное приложение следует, основываясь именно на

потоках событий, описываемых прецедентами. Обратное проектирование предполагает

перевод с языка программирования на язык UML-диаграмм. Такими вещами приходится

заниматься в силу ряда причин:

С целью поиска ошибок и чтобы убедиться в адекватности дизайна:

отличная идея после первого перевода с UML на язык программирования сделать

обратный перевод и сравнить исходные и восстановленные UML-модели (желательно,

чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что

дизайн системы соответствует модели, никакая информация в ходе перевода не была

утеряна, да и попросту выловить некоторые "баги". Такой подход называется обратной

семантической трассировкой (или RST - Reverse Semantic Traceability) и разрабатывается

компанией INTSPEI (http://www.intspei.com) как одна из базовых техник методологии

INTSPEI P-Modeling Framework, краткие сведения о которой вы можете найти в

приложении к этому курсу.

Когда отсутствует документация: иногда стоит задача модификации

существующей системы, код которой плохо документирован. В таком случае перевод с

языка программирования на язык UML-диаграмм - отличный способ понять назначение

системы и ее частей, функционал, предоставляемый ею, и т. д.

И наконец, следует отметить, что, конечно, только диаграмм прецедентов, как и

сценариев, ими определяемых, недостаточно, чтобы создать модель поведения системы.

Прецеденты говорят, что делает система, но не говорят, как. Об этом говорят сценарии, но

в текстовой форме, что делает их довольно сложными для восприятия. На помощь

приходят диаграммы взаимодействий, которые визуализируют сценарии:

325

http://www.intspei.com/

В заключение приведем пару примеров законченных диаграмм прецедентов.

Первый пример (смысл которого понятен и без дополнительных пояснений)

демонстрирует включение, расширение и наследование прецедентов. Обратите внимание

на стрелки, которые направлены к экторам, изображающим шлюзы. Все правильно - ведь

система пользуется их услугами при отправке сообщений, в то время как маркетолог,

наоборот, пользуется услугами системы, и потому стрелки направлены от него:

Вторая картинка повествует о способах поведения, позволяющих гарантированно

(!) провалить любой экзамен:

326

Выводы:

Модель прецедентов позволяет описать систему на концептуальном уровне.

Диаграммы прецедентов - отличное средство коммуникаций между

экспертами, пользователями и разработчиками, а также основа для тестирования

создаваемой системы.

Прецедент - это описание набора последовательных событий (включая

возможные варианты), выполняемых системой, которые приводят к наблюдаемому

эктором результату.

Эктор - это набор ролей, которые исполняет пользователь в ходе

взаимодействия с некоторой сущностью.

Прецеденты (как и экторы) могут быть генерализованы, т. е. наследовать и

дополнять свойства своих предков.

Прецеденты также могут вступать между собой в отношения включения и

расширения, что позволяет разложить прецеденты на более простые составляющие и

выделить необязательное поведение.

Каждый прецедент реализуется одной или несколькими кооперациями.

Сценарии специфицируют прецеденты, а диаграммы взаимодействий

визуализируют сценарии.


1. Получите у преподавателя «сказочную» предметную область.

Вариант 1. «Курочка Ряба»

Вариант 2. «Репка»

Вариант 3. «Три поросенка»

Вариант 4. «Колобок»

327

Вариант 5. «Красная Шапочка»

Вариант 6. «Золушка»

Вариант 7. «Сказка о рыбаке и рыбке»

Вариант 8. «Маша и медведи»

Вариант 9. «Морозко»

Вариант 10. «Царевна-лягушка»

2. Постройте обязательный комплект UML-диграмм, соблюдая нотацию каждой из

них:

1) диаграмму прецедентов;

2) диаграмму классов;

3) диаграмму активностей.

Практикум

РАБОТА С CASE-СРЕДСТВАМИ ПРОЕКТИРОВАНИЯ

Цель работы: приобретение навыков работы с CASE-средством Visual.


Онлайн-версия CASE-средства Visual расположена по адресу:

https://online.visual-paradigm.com/

С данным средством можно работать без регистрации, но в этом случае сохранять

и распечатывать диаграммы будет невозможно, только снимать скриншоты экрана.

Если зарегистрироваться, будут доступны все функции.

328

https://online.visual-paradigm.com/

При нажатии на кнопку «Get Started for Free» переходим к меню доступных

диаграмм. Выберем, например, диаграмму бизнес-процессов:

Получаем доступ к хранилищу готовых диаграмм, а также к чистому бланку, на

котором можно рисовать свою диаграмму:

Инструменты рисования расположены на панели слева и частично вверху:

329

Интерфейс – интуитивно понятен. Выбираем инструменты рисования и

изображаем то, что необходимо. Текст вставляется на диаграмму двойным кликом мышки

по нужному месту.

330


Смоделировать свою предметную область при помощи CASE-средства Visual в

виде альбома диаграмм со следующим содержанием:

1. Диаграмма SADT (нотация IDEF0):

1.1 Уровень А0



2. Диаграмма DFD (любая нотация из поддерживаемых Visual).

3. Диаграмма ER (любая нотация из поддерживаемых Visual).

4. UML-диаграммы:

4.1 Диаграмма прецедентов

4.2 Диаграмма классов

4.3 Диаграмма последовательностей

4.4 Диаграмма активностей

Предметные области:

№ варианта Предметная область1 Мебельная фабрика2 Риэлтерская фирма3 Рекламное агентство4 Магазин бытовой техники и электроники5 Система продажи железнодорожных билетов6 Оптовый склад7 Страховая компания8 Электронный журнал колледжа9 Интернет-магазин

10 Туристическое агентство11 Ресторан быстрого питания12 Таксопарк13 Отдел кадров организации14 Книжный магазин15 Библиотека16 Сервисный центр17 Санаторий18 Ветеринарная клиника19 Фотоателье20 Система электронных платежей

6. МЕТОДИЧЕСКИЕ УКАЗАНИЯ К САМОСТОЯТЕЛЬНОЙ РАБОТЕ


331

6.1 Перечень видов самостоятельной работы

Тема самостоятельной работы Объем часов

1. Проработка теоретического материала программы (конспекты лекций). 102. «Консультант плюс» как информационная система (конспект по данным литературы).

6

3. Оформление практических работ (отчеты). 204. Изучение статей периодической печати, интернет-изданий (письменные ответы на контрольные вопросы).

8

5. Проект автоматизированной системы управления предприятием (организацией) по выбору обучающегося.

50

ВСЕГО: 94

6.2 Методические указания к самостоятельной работе

6.2.1 Проработка теоретического материала программы (конспекты лекций)

Ценность лекционного материала состоит в том, что он обработан специалистом в

соответствующей области, каждый факт может быть объяснен на достаточно высоком

уровне компетентности, подкреплен конкретными примерами. Чтобы активно слушать

лекцию, к ее восприятию надо готовиться. В качестве методов подготовки может

выступать предварительная проработка материала с предыдущей лекции, уяснение для

себя основных категорий, задач, поставленных преподавателем, осмысление фактического

материала, подборка своих примеров, расшифровка сокращений, которые допускаются

при записывании, проработка справочного материала (в учебнике, учебном пособии,

справочнике), если какие-то моменты оказались неясными и др. На лекции не надо

стараться записывать все, что говорит преподаватель, это невозможно, тем не менее,

необходимо отметить основные моменты лекции. Так, каждая лекция включает план,

который должен стать основой восприятия, в котором выделяются основные понятия,

формируется главная проблема. Обычно лекция строится по следующей логической

схеме: актуальность и история развития проблемы, основные подходы к ее реализации,

основные подходы к ней с позиции разных ученых, высказываются предположения,

догадки, раскрываются методы поиска решения поставленной проблемы,

аргументируются выводы.

Различают лекции по характеру и методу. В проблемной лекции преподаватель

ставит перед вами проблемный вопрос и вместе с вами его решает. Такая лекция дает

332

возможность включить студентов в обсуждение, следить за аргументированностью их

высказываний. Это помогает не только усвоить главную идею, но и записать ее.

Обзорно-проблемная лекция охватывает в целом раздел программного материала

или подведение итогов целого курса (раздела). Преподаватель схематично обосновывает

логику темы, дает понятийный аппарат, разъясняет только самые значительные моменты

и выдвигает проблемы, которые побуждают к самостоятельной работе, поиску нужной

литературы.

Текст лекции, записанный студентом, должен находиться в отдельной тетради. В

тетради должны быть оставлены широкие поля, где можно делать пометки, дополнять

мысли, фиксировать примеры, используя дополнительные символические знаки, цветные

авторучки. Условные обозначении должны быть привычными или понятными хозяину

тетради.

Литературные источники, указанные в лекции, как правило, дифференцируются:

для конспектирования, для чтения и для индивидуальной самостоятельной работы по

теме, расширяющей кругозор.

Помимо подготовки к восприятию лекции, эффективным приемом является

проработка записей лекций в этот же день после посещения. Повторное обращение к

записям, дополнение их сведениями из справочной литературы, учебников, учебных

пособий будет способствовать закреплению информации.

Объем каждой лекции не должен быть меньше 5 страниц рукописноготекста.

Каждая лекция завершается списком вопросов для самоконтроля. Вопросы

составлены таким образом, что студент, прослушавший и законспектировавший текст

лекции, способен дать вразумительные ответы. Вопросы проверяют степень понимания

лекционного материала, если студент не сможет ответить на них, он может обратиться к

специальной литературе.

6.2.2 Конспект по данным литературы

Конспект – это краткое, связное и последовательное изложение констатирующих и

аргументирующих положений текста.

Во всяком учебном материале – будь то устное сообщение или печатный текст –

содержится главная и второстепенная информация. Наиболее важную информацию

(определения, формулировки, теоретические принципы и положения, основные выводы)

необходимо записывать обязательно. На лекции преподаватель ее специально повторяет

или даже диктует. Второстепенная информация (теоретическая аргументация,

333

фактические обоснования, примеры, описания исследовательских методов и процедур,

подробные характеристики отдельных явлений, факты из истории и т.п.) нужна для

понимания главной информации. Основное содержание конспектирования составляет

обобщение и сокращение второстепенной информации. Связующим звеном при

составлении конспекта должна быть внутренняя логика изложения.

Классификация видов конспектов:

1. План-конспект. При создании такого конспекта сначала пишется план текста,

далее на отдельные пункты плана «наращиваются» комментарии. Это могут быть цитаты

или свободно изложенный текст.

2. Тематический конспект. Такой конспект является кратким изложением данной

темы, раскрываемой по нескольким источникам.

3. Текстуальный конспект. Этот конспект представляет собой монтаж цитат

одного текста.

4. Свободный конспект. Данный вид конспекта включает в себя и цитаты, и

собственные формулировки.

Как составлять конспект?

1. Определите цель составления конспекта.

2. Осмыслить основное содержание текста, дважды прочитав его. Читая изучаемый

материал в первый раз, подразделяйте его на основные смысловые части, выделяйте

главные мысли, выводы.

3. Если составляется план-конспект, сформулируйте его пункты и определите, что

именно следует включить в план-конспект для раскрытия каждого из них.

4. Наиболее существенные положения изучаемого материала (тезисы)

последовательно и кратко излагайте своими словами или приводите в виде цитат.

5. В конспект включаются не только основные положения, но и обосновывающие

их выводы, конкретные факты и примеры (без подробного описания).

6. Как оформить конспект?

Материал в конспекте должен читаться легко и быстро. Для этого необходимо

использовать тетради с широким форматом страниц, вести запись достаточно крупными

буквами.

Чтобы форма конспекта как можно более наглядно отражала его содержание,

располагайте абзацы "ступеньками" подобно пунктам и подпунктам плана. Главную

информацию следует выделять в самостоятельные абзацы, фиксируя ее более крупными

буквами или цветными чернилами, а подчиненность тем и заголовков - при помощи

уступов. Основные темы целесообразно пронумеровать римскими цифрами, а

334

подчиненные им разделы – арабскими или буквами. Удобочитаемый конспект содержит

не более семи пунктов на странице.

Применяйте разнообразные способы подчеркивания, используйте карандаши и

ручки разного цвета. У каждого цвета должно быть строго однозначное, заранее

предусмотренное назначение. Например, если вы пользуетесь синими чернилами для

записи конспекта, то: красным цветом – подчеркивайте названия тем, пишите наиболее

важные формулы; черным – подчеркивайте заголовки подтем, параграфов, и т.д.; зеленым

– делайте выписки цитат, нумеруйте формулы и т.д. Для выделения большой части текста

используется отчеркивание.

Для быстрой записи теста можно придумать условные знаки. Таких знаков не

должно быть более 10-15.

Составляя конспект, можно отдельные слова и целые предложения писать

сокращенно, выписывать только ключевые слова, вместо цитирования делать лишь

ссылки на страницы конспектируемой работы, применять условные обозначения.

Больше рисуйте схем. Это дает наглядность, обеспечивает структурирование

материала, лучшее его запоминание.

Конспект должен иметь широкие поля для заметок.

7. Используйте реферативный способ изложения (например: «Автор считает...»,

«раскрывает...»).

8. Собственные комментарии, вопросы, раздумья располагайте на полях.

Критерии оценки конспекта:

- уровень усвоения теоретического материала;

- качество составленного конспекта (оформление, структура, содержание).

6.2.3 Оформление практических работ (отчеты)

ПРАКТИЧЕСКАЯ РАБОТА № …

Тема: …

Цель: …

(создать, решить, произвести, ввести, вывести, выполнить, оформить, применить,

найти ошибки, составить перечень, определить параметры, проверить, определить

программу действий, переложить на язык программирования, применить структуру,

выявить разновидности, составить таблицу, найти, составить протокол, разработать

документ, рассчитать эффективность, провести анализ, сопоставить, продолжить и т.д.)

Оснащение: …

335

(информационные источники: литература, справочники, интернет-ресурсы и др.;

пособия (методические, наглядные, демонстрационные); оборудование (перечень)).

Ход работы (задания):

1.

2.

…

Результаты:

(текст, скриншоты)

6.2.4 Изучение статей периодической печати, интернет-изданий (письменные

ответы на контрольные вопросы)

Конспектирование статей и монографий является одной из основных форм

самостоятельной работы и подготовки к практическим занятиям.

Инструкция

1. Прежде чем начинать писать конспект статьи, вы должны четко понимать,

что конспектирование целостной, законченной работы довольно серьезно отличается от

конспектирования под диктовку в реальном времени, к примеру, на лекции. В этом случае

ставится задача не просто зафиксировать изложение материала автором, а составить на

его основе целостное, логически связанное изложение.

2. Начинайте работу с внимательного прочтения всей статьи целиком. В

процессе чтения отметьте основные части статьи. Как правило, они включают в себя

введение с постановкой проблемы, основную часть работы и заключение, содержащее

выводы. В каждой части выделите основные мысли автора.

3. Уяснив для себя основную суть статьи и выводы, сделанные автором,

переходите к непосредственному написанию конспекта. Обратите внимание, что конспект

предполагает краткое изложение материала и ваша работа по объему должна быть

значительно меньше оригинальной статьи. Это значит, что не нужно переписывать

авторский текст подряд. Выбирайте только самое необходимое.

4. Начинайте конспект с вводной части, содержащей постановку научной

проблемы и основные исходные положения. Прежде чем писать, еще раз перечитайте

первую часть (как правило, несколько абзацев) и выделите в тексте главные мысли,

отбрасывая все сторонние рассуждения. При составлении конспекта не очень желательно

переписывать текст дословно, цитировать его подряд. Будет намного лучше, если вы

сможете переформулировать выделенные мысли своими словами.

336

5. Записав основные положения первой части статьи, переходите к

следующему разделу и повторите с ним весь описанный ранее алгоритм действий. Если в

статье содержатся какие-либо научные выкладки, формулы, постулаты, обратите на них

особое внимание. Это тот фундамент, на котором строится вся доказательная база

научной работы. Постарайтесь зафиксировать эти данные максимально точно.

6. Законспектировав основную часть статьи, особое внимание обратите на ее

заключение и содержащиеся в нем выводы. Обычно в научных работах итоговые выводы

излагаются в виде последовательных списков или тезисов. Но если этого нет, желательно

самостоятельно привести заключительную часть к максимально формализованному виду.

В дальнейшем такое изложение материала очень поможет при его усвоении и обработке.

Полезный совет

Если в конспектируемой статье содержатся какие-либо отсылки к другим авторам

или научным работам, зафиксируйте их также. Это может быть важно для теоретических

построений автора статьи.

6.2.5 Проект автоматизированной системы управления предприятием

(организацией) по выбору обучающегося

Самостоятельная работа по практикуму «Работа с CASE-средствами

моделирования».

7. КОМПЛЕКТ ОЦЕНОЧНЫХ СРЕДСТВ


337

7.1 Паспорт комплекта оценочных средств

Код и формулировка компетенции

Индикаторы достижения компетенцииминимальные требования к практическому опыту, умениям, знаниям

ПК 1.1. Собирать данные для анализа использования и функционирования информационной системы, участвовать в составлении отчетной документации, принимать участие в разработке проектной документации на модификацию информационной системы.

Иметь практический опыт:- обеспечения сбора данных для анализа использования и функционирования информационной системы и участия в разработке проектной и отчетной документации. Уметь:- поддерживать документацию в актуальном состоянии;- принимать решение о расширении функциональности информационной системы, о прекращении эксплуатации информационной системы или ее реинжиниринге;- производить документирование на этапе сопровождения.Знать:- основные задачи сопровождения информационной системы.

ПК 1.2. Взаимодействовать со специалистами смежного профиля при разработке методов, средств и технологий применения объектов профессиональной деятельности.

Иметь практический опыт:- определения состава оборудования и программных средств разработки информационной системы;- использования инструментальных средств программирования информационной системы;- взаимодействия со специалистами смежного профиля при разработке методов, средств и технологий применения объектов профессиональной деятельности.Уметь:- манипулировать данными с использованием языка запросов баз данных, определять ограничения целостности данных;- выделять жизненные циклы проектирования компьютерных систем;- использовать методы и критерии оценивания предметной области и методы определения стратегии развития бизнес-процессов организации;- строить архитектурную схему организации;- проводить анализ предметной области;- осуществлять выбор модели построения информационной системы и программных средств.Знать:- цели автоматизации организации;- задачи и функции ИС;- типы организационных структур;- реинжиниринг бизнес-процессов;- основные модели построения ИС, их структуру, особенности и области применения;- особенности программных средств, используемых в разработке ИС;- методы и средства проектирования информационных систем;- основные понятия системного анализа;- национальную и международную систему обеспечения качества продукции, методы контроля качества.

ПК 1.3. Производить модификацию отдельных модулей информационной системы в соответствии с рабочим заданием, документировать

Иметь практический опыт:- модификации отдельных модулей информационной системы.Уметь:- поддерживать документацию в актуальном состоянии;- производить документирование на этапе сопровождения.Знать:- регламенты по обновлению и техническому сопровождению обслуживаемой информационной системы.

338

Код и формулировка компетенции

Индикаторы достижения компетенцииминимальные требования к практическому опыту, умениям, знаниям

произведенные изменения.ПК 1.4. Участвовать в экспериментальном тестировании информационной системы на этапе опытной эксплуатации, фиксировать выявленные ошибки кодирования в разрабатываемых модулях информационной системы.

Иметь практический опыт:- участия в экспериментальном тестировании информационной системы на этапе опытной эксплуатации и нахождения ошибок кодирования в разрабатываемых модулях информационной системы.Уметь:- идентифицировать технические проблемы, возникающие в процессе эксплуатации системы.Знать:- типы тестирования.

ПК 1.5. Разрабатывать фрагменты документации по эксплуатации информационной системы.

Иметь практический опыт:- разработки фрагментов документации по эксплуатации информационной системы.Уметь:- оформлять программную и техническую документацию, используя стандартов оформления программной документации;- применять требования НТД к основным видам продукции (услуг) и процессов;- применять документацию систем качества;- применять основные правила и документы системы сертификации Российской Федерации.

7.2 Программа контрольно-оценочных мероприятий

Код и наименование профессиональных

компетенций, формируемых в рамках

модуля

Критерии оценки Методы оценки

ПК 1.1. Собирать данные для анализа использования и функционирования информационной системы, участвовать в составлении отчетной документации, принимать участие в разработке проектной документации на модификацию информационной системы.ПК 1.2. Взаимодействовать со специалистами смежного профиля при разработке методов, средств и технологий применения объектов профессиональной деятельности.

Оценка «отлично» - задание проанализировано, алгоритм его выполнения разработан, соответствует заданию и оформлен в соответствии со стандартами, реализован, полученные результаты соответствуют заданию и действующим требованиям.Оценка «хорошо» - алгоритм выполнения задания разработан, соответствует заданию и оформлен в соответствии со стандартами, реализован, имеют место незначительные несоответствия результатов заданию и действующим требованиям.Оценка «удовлетворительно» - алгоритм выполнения задания разработан, имеют место значительные несоответствия заданию и требованиям к оформлению, реализован, имеют место значительные несоответствия результатов заданию и действующим требованиям.Оценка «неудовлетворительно» - не разработан алгоритм выполнения задания, оно не выполнено.

Оценка:- действий обучающихся при выполнении работ учебной и производственной практики, на экзамене (квалификационном);- действий обучающихся в процессе выполнения аудиторных практических работ;- результатов практики, экзамена (квалификационного);- результатов выполнения аудиторных практических работ.Оценка результатов:- устных ответов обучающихся по

339

ПК 1.3. Производить модификацию отдельных модулей информационной системы в соответствии с рабочим заданием, документировать произведенные изменения.ПК 1.4. Участвовать в экспериментальном тестировании информационной системы на этапе опытной эксплуатации, фиксировать выявленные ошибки кодирования в разрабатываемых модулях информационной системы.ПК 1.5. Разрабатывать фрагменты документации по эксплуатации информационной системы.

темам модуля;- письменных работ;- защиты практических работ;- самостоятельной работы обучающихся.

Код и наименование общих компетенций, формируемых

в рамках модуляКритерии оценки Методы оценки

ОК 1. Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.

Демонстрация интереса к будущей профессии. Оценка деятельности и поведения обучающихся:- на практических занятиях;- при выполнении работ учебной и производственной практик;- на экзамене (квалификационном).Оценка результатов самостоятельной работы обучающегося.

ОК 2. Организовывать собственную деятельность, выбирать типовые методы решения профессиональных задач, оценивать их эффективность и качество.

Обоснование выбора и применение типовых методов решения профессиональных задач в области эксплуатации и модификации информационных систем.Демонстрация эффективности и качества выполнения профессиональных задач.

ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.

Демонстрация способности:- решать возникающие проблемы, стандартные и нестандартные профессиональные задачи в области эксплуатации и модификации информационных систем;- нести ответственность за принятые решения.

ОК 4. Осуществлять поиск и использование информации, необходимой для эффективного выполнения профессиональных задач, профессионального и личностного развития.

Демонстрация навыков быстрого и эффективного поиска информации, необходимой для решения профессиональных задач, с использованием широкого спектра источников (включая электронные).

ОК 5. Использовать информационно-коммуникационные технологии в

Демонстрация навыков:- проведения расчетов и проектирования с помощью персонального компьютера;- использования информационно-коммуникативных

340

профессиональной деятельности.

средств при решении профессиональных задач.

ОК 6. Работать в коллективе и команде, эффективно общаться с коллегами, руководством, потребителями.

Взаимодействие с преподавателями, руководителями практики, другими обучающимися в ходе обучения.

ОК 7. Брать на себя ответственность за работу членов команды (подчиненных), результат выполнения заданий.

Проявление ответственности за работу членов команды (подчиненных), результат выполнения заданий.

ОК 8. Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.

Планирование обучающимся повышения своего личностного и профессионального уровня.

ОК 9. Ориентироваться в условиях частой смены технологий в профессиональной деятельности.

Проявление интереса к инновациям в области эксплуатации и модификации информационных систем.

7.3 Типовые задания для проведения текущего контроля по МДК

Практические задания

Задание 1

Разработайте классификатор продукции на основе выданного вам прайс-листа.

Для выполнения задания воспользуйтесь теоретическими положениями и

примерами из Практической работы № 1.

Задание 2

Создайте дескрипторный классификатор в виде базы данных, обеспечивающей

поиск в предметной области искомого понятия и понятий, связанных с ним.

Перечень предметных областей:

1. Млекопитающие

2. Металлы и сплавы

3. Живопись

4. Творчество А.С. Пушкина

5. Библиотечная деятельность

6. Злаковые растения

7. Оптика

341

8. Метеорология



Задание 3

Разработайте экспертную систему подбора товаров в интернет-магазине.



Задание 4

Разработайте функциональную модель (диаграмму SADT) уровня А0 для

предметной области:

1. Подготовка к Олимпийским играм

2. Выпуск автомобиля

3. Выпуск DVD-плейера

4. Проведение лабораторной работы

5. Построение здания

6. Сборка персонального компьютера

7. Переналадка технологического оборудования

8. Подготовка конструкторской документации

9. Получение прав на управление транспортным средством

10. Организация переезда в новую квартиру



Задание 5

Разработайте DFD-диаграмму для предметной области:

1. Покупка в ювелирном магазине.

2. Учет жилищного фонда.

3. Учету стройматериалов.

4. Расчет сырья промышленного предприятия (поставщики, тип сырья,

закупка, фирма-перевозчик, сумма, необходимая для закупки сырья).

5. Расчет прибыли от выполняемых работ по ремонту офисов

многофилиального концерна (с учетом налоговых выплат).

342

6. Расчет себестоимости изделия (вывод списка деталей, используемых в

данном изделии, расчет суммарной стоимости всех деталей, используемых в

данном изделии).

7. Определение затрат рабочего времени на выполнение строительных

работ.

8. Определение величины таможенных сборов на базе контрактов

коммерческой фирмы.

9. Платный прием в поликлинике.

10. Прокат автомобилей.

11. Оптовая торговля товарами повседневного спроса.

12. Учет нарушений ПДД.

13. Оформление путевки через туристическое агентство.

14. Учет подписки на печатные издания.

15. Учет сделок с недвижимостью.

16. Учет договоров страхования.

17. Штатное расписание.

18. Учет результатов сессии.

19. Ремонт станков.

20. Управление грузовыми перевозками.

21. Продажа железнодорожных билетов.



Задание 6

Разработайте ER-диаграмму для следующей предметной области:

1. Магазин «Товары для детей»

2. Автосалон

3. Книжное издательство

4. Рекламное агентство

5. Оптовый склад

6. Фирма, торгующая компьютерами и периферийной техникой

7. Составление расписания учебных занятий в колледже

8. Киностудия

9. Аптека

10. Мастерская по ремонту телевизоров

343

11. Система маршрутов городского транспорта



Задание 7

Постройте обязательный комплект UML-диграмм, соблюдая нотацию каждой из

них:

1) диаграмму прецедентов;

2) диаграмму классов;

3) диаграмму активностей.

Предметную область выберите на свое усмотрение из заданий 4-6.



7.4 Типовые задания для проведения промежуточной аттестации

Практические задания

Смоделировать свою предметную область при помощи CASE-средства Visual в

виде альбома диаграмм со следующим содержанием:

1. Диаграмма SADT (нотация IDEF0):

2. Диаграмма DFD (любая нотация из поддерживаемых Visual).

3. Диаграмма ER (любая нотация из поддерживаемых Visual).

4. UML-диаграммы:

4.1 Диаграмма прецедентов

4.2 Диаграмма классов

4.3 Диаграмма последовательностей

4.4 Диаграмма активностей

Предметные области:

№ варианта Предметная область1 Мебельная фабрика2 Риэлтерская фирма3 Рекламное агентство4 Магазин бытовой техники и электроники5 Система продажи железнодорожных билетов6 Оптовый склад7 Страховая компания

344

8 Электронный журнал колледжа9 Интернет-магазин

10 Туристическое агентство11 Ресторан быстрого питания12 Таксопарк13 Отдел кадров организации14 Книжный магазин15 Библиотека16 Сервисный центр17 Санаторий18 Ветеринарная клиника19 Фотоателье20 Система электронных платежей

8. СПИСОК ИНФОРМАЦИОННЫХ ИСТОЧНИКОВ

8.1 Основные источники:

1. Мезенцев К.Н. Автоматизированные информационные системы. – М.: ОИЦ

«Академия», 2016.

2. Федорова Г.Н. Информационные системы: учебник для студентов учреждений

СПО. – М.: ОИЦ «Академия», 2016.

3. Фуфаев Д.Э., Фуфаева Э.В. Разработка и эксплуатация автоматизированных

информационных систем. – М.: ОИЦ «Академия», 2016.

8.2 Дополнительные источники:

1. Богатырев В.А. Информационные системы и технологии: теория надежности.

Учебное пособие. – М.: Юрайт, 2017. – 320 с.

2. Волкова В.Н. Теория информационных процессов и систем: учебник и

практикум. – М.: Юрайт, 2017. – 504 с.

3. Гагарина Л.Г. Разработка и эксплуатация автоматизированных

информационных систем: учебное пособие. – М.: Форум, Инфра-М, 2015. – 384

с.

4. Игнатьев А.В. Методы и средства проектирования информационных систем и

технологий: учебное пособие. – Волгоград: ВолгГАСУ, 2014. – 57 с.

5. Международный стандарт ISO/IEC 12207 «Жизненный цикл

автоматизированных информационных систем».

6. Шанченко Н.И. Оценка трудоемкости разработки программного продукта:

методические указания. – Ульяновск: УлГТУ, 2015. – 40 с.

8.3 Интернет-ресурсы:

1. http://www.interface.ru/ - Разработчикам информационных систем.

345

2. http://citforum.ru/ - Разработчикам информационных систем.

3. http://www.torins.ru/ - Сайт ассоциации разработчиков информационных систем.

346

thtk.1mcg.ru · web viewМетодические указания к практическим...

Documents