авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 3 | 4 || 6 |

«УДК 002.52/.54(075.8) ББК 32.973.202я73 МИНОБРНАУКИ РОССИИ ...»

-- [ Страница 5 ] --

Время устранения отказа должно быть следующим:

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

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

- при выходе из строя АПК ХД - не более Z часов.

Система должна соответствовать следующим параметрам:

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

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

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

Средняя наработка на отказ АПК не должна быть меньше G часов.

4. 1. 4. 2. Перечень аварийных ситуаций, по которым регламентируются требования к надежности Например:

Под аварийной ситуацией понимается аварийное завершение процесса, выполняемого той или иной подсистемой КХД, а также «зависание» этого процесса.

При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:

- сбой в электроснабжении сервера;

- сбои программного обеспечения сервера.

-… 4. 1. 4. 3. Требования к надежности технических средств и программного обеспечения Например:

К надежности оборудования предъявляются следующие требования:

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

-… К надежности электроснабжения предъявляются следующие требования:

- система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;

-… Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:

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

-… Надежность программного обеспечения подсистем должна обеспечиваться за счет:

- надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;

-… 4. 1. 4. 4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации по методике Разработчика, согласованной с Заказчиком.

4. 1. 5. Требования к эргономике и технической эстетике Например:

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

В части внешнего оформления:

- должен использоваться шрифт:...

-… В части диалога с пользователем:

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

-… В части процедур ввода-вывода данных:

- должна быть возможность многомерного анализа данных в табличном и графическом видах.

-… К другим подсистемам предъявляются следующие требования к эргономике и технической эстетике.

В части внешнего оформления:

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

В части диалога с пользователем:

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

-… В части процедур ввода-вывода данных:

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

4. 1. 6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы Например:

Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.

Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия… Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).

Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

4. 1. 7. Требования к защите информации от несанкционированного доступа 4. 1. 7. 1. Требования к информационной безопасности Например:

Обеспечение информационное безопасности Системы КХД должно удовлетворять следующим требованиям:

- Защита Системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.

-...

4. 1. 7. 2. Требования к антивирусной защите Например:

Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов Системы КХД. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:

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

-...

4. 1. 7. 3. Разграничения ответственности ролей при доступе к указать объект ограничения (например, отчет, показатель, измерение) Требования по разграничению доступа приводятся в виде матрицы разграничения прав.

Матрица должна раскрывать следующую информацию:

- код ответственности: Ф - формирует, О – отвечает, И – использует и т. п. ;

-...

4. 1. 8. Требования по сохранности информации при авариях Приводится перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе.

В Системе должно быть обеспечено резервное копирование данных.

Выход из строя трех жестких дисков дискового массива не должен сказываться на работоспособности подсистемы хранения данных.

4. 1. 9. Требования к защите от влияния внешних воздействий Приводятся требования к радиоэлектронной защите и требования по стойкости, устойчивости и прочности к внешним воздействиям применительно к программно аппаратному окружению, на котором будет эксплуатироваться система.

Применительно к программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий.

Требования к радиоэлектронной защите:

-… Требования по стойкости, устойчивости и прочности к внешним воздействиям:

- Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % - 30 %);

-… 4. 1. 10. Требования по стандартизации и унификации В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6. 10. 1, общесоюзных классификаторов технико экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50. 1. 028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».

Для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий) должны использоваться встроенные возможности ПО указывается название BI приложения, а также, в случае необходимости, языки программирования указываются языки программирования и их версии.

… 4. 1. 11. Дополнительные требования Приводятся требования к оснащению системы устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения) и документацией на них.

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

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

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

4. 1. 12. Требования безопасности В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п. ) по допустимым уровням освещенности, вибрационных и шумовых нагрузок.

-Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12. 1. 004-91. «ССБТ. Пожарная безопасность. Общие требования».

-… 4. 1. 13. Требования к транспортабельности для подвижных АИС КСА системы являются стационарными и после монтажа и проведения пуско наладочных работ транспортировке не подлежат.

4. 2. Требования к функциям, выполняемым системой В данном подразделе приводят:

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

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

-… 4. 2. 1. Подсистема сбора, обработки и загрузки данных 4. 2. 1. 1 Перечень функций, задач подлежащей автоматизации Функция Задача Создание, редактирование и удаление процессов сбора, обработки и загрузки данных Управляет процессами сбора, Формирование последовательности выполнения процессов сбора, обработки и загрузки данных обработки и загрузки данных (регламентов загрузки данных) Определение и изменение расписания процессов сбора, обработки и загрузки данных Запуск процедур сбора данных из систем источников, загрузка Выполнение процессов сбора, данных в область временного, постоянного хранения обработки и загрузки данных из Обработка и преобразование извлечённых данных источников в ХД Поддержка медленно меняющихся измерений Ведение журналов результатов сбора, обработки и загрузки данных Протоколирует результаты сбора, Оперативное извещение пользователей о всех нештатных обработки и загрузки данных ситуациях в процессе работы подсистемы 4. 2. 1. 2 Временной регламент реализации каждой функции, задачи Задача Требования к временному регламенту Весь период функционирования системы, при Создание, редактирование и удаление возникновении необходимости изменения процессов процессов сбора, обработки и загрузки данных сбора, обработки и загрузки данных Формирование последовательности Весь период функционирования системы, при выполнения процессов сбора, обработки и возникновении необходимости модификации регламента загрузки данных (регламентов загрузки загрузки данных данных) Весь период функционирования системы, при Определение и изменение расписания возникновении необходимости изменения расписания процессов сбора, обработки и загрузки данных процессов Запуск процедур сбора данных из систем После готовности данных в системах источниках, источников, загрузка данных в область ежедневно во временном интервале 00:00 – 03: временного, постоянного хранения Обработка и преобразование извлечённых Ежедневно, после появления всех извлечённых данных во данных временном интервале 00:00 – 06: Регулярно, при работе подсистемы для измерений Поддержка медленно меняющихся измерений соответствующего типа Ведение журналов результатов сбора, Регулярно, при работе подсистемы обработки и загрузки данных Оперативное извещение пользователей о всех Регулярно, при возникновении нештатной ситуации в нештатных ситуациях в процессе работы процессе работы подсистемы подсистемы 4. 2. 1. 3 Требования к качеству реализации функций, задач Задача Форма представления Характеристики точности и выходной информации времени выполнения Создание, редактирование и удаление В стандарте интерфейса Определяется регламентом процессов сбора, обработки и загрузки ETL средства эксплуатации данных Формирование последовательности выполнения процессов сбора, обработки и В стандарте интерфейса Определяется регламентом загрузки данных (регламентов загрузки ETL средства эксплуатации данных) Определение и изменение расписания В стандарте интерфейса Определяется регламентом процессов сбора, обработки и загрузки ETL средства эксплуатации данных Запуск процедур сбора данных из систем Запуск должен производится источников, загрузка данных в область Текстовый файл точно по установленному временного, постоянного хранения расписанию Данные должны быть преобразованы для загрузки в Обработка и преобразование извлечённых Текстовый файл.

Данные в данных структурах БД структуры модели ХД. Не более 2 часов Данные должны быть сохранены по правилам Поддержка медленно меняющихся Данные в структурах БД поддержки медленно измерений меняющихся измерений соответствующего типа Ведение журналов результатов сбора, В момент выполнения сбора, Текстовые файлы обработки и загрузки данных обработки и загрузки данных Оперативное извещение пользователей о Не позднее 15 минут после Текстовый файл, оконное всех нештатных ситуациях в процессе возникновения нештатной сообщение, email работы подсистемы ситуации 4. 2. 1. 4 Перечень критериев отказа для каждой функции Функция Критерии отказа Время Коэффициент восстановления готовности Не выполняется одна из задач: перечисляются Управляет процессами сбора, задачи, в случае не 8 часов 0. обработки и загрузки данных выполнения которых не выполняется функция:

Запускает процессы сбора, Не выполняется одна из 12 часов 0. обработки и загрузки данных из задач функции.

источников в ХД Протоколирует результаты сбора, Не выполняется одна из 12 часов 0. обработки и загрузки данных задач функции.

Аналогично для каждой подсистемы, определенной в пункте "6. 1. 1 Требования к структуре и функционированию системы" настоящего технического задания.

4. 3. Требования к видам обеспечения 4. 3. 1 Требования к математическому обеспечению Для математического обеспечения системы приводятся требования к составу, области применения (ограничения) и способам использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке.

-… 4. 3. 2. Требования к информационному обеспечению Приводятся требования:

1) к составу, структуре и способам организации данных в системе;

-… 4. 3. 2. 1. Требования к составу, структуре и способам организации данных в системе Структура хранения данных в КХД должна состоять из следующих основных областей:

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

-… 4. 3. 2. 2. Требования к информационному обмену между компонентами системы Информационный обмен между компонентами системы КХД должен быть реализован следующим образом:

Подсистема Подсистема сбора, Подсистема формирования и обработки и загрузки хранения визуализации данных данных отчетности Подсистема сбора, обработки и X загрузки данных Подсистема хранения данных X X Подсистема формирования и X визуализации отчетности 4. 3. 2. 3. Требования к информационной совместимости со смежными системами -Система не должна быть закрытой для смежных систем и должна поддерживать возможность экспорта данных в смежные системы через интерфейсные таблицы или файлы данных.

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

-… 4. 3. 2. 5. Требования по применению систем управления базами данных Для реализации подсистемы хранения данных должна использоваться промышленная СУБД указывается название и версия СУБД.

4. 3. 2. 6. Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных Процесс сбора, обработки и передачи данных в системе определяется регламентом процессов сбора … 4. 3. 2. 7. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы - Информация в базе данных системы должна сохраняться при возникновении аварийных ситуаций, связанных со сбоями электропитания.

-… 4. 3. 2. 8. Требования к контролю, хранению, обновлению и восстановлению данных К контролю данных предъявляются следующие требования:

- система должна протоколировать все события, связанные … К хранению данных предъявляются следующие требования:

- хранение исторических данных в системе должно производиться не более чем за (пять) предыдущих лет.

-… К обновлению и восстановлению данных предъявляются следующие требования:

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

-… 4. 3. 2. 9. Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы -… 4. 3. 3. Требования к лингвистическому обеспечению Для лингвистического обеспечения системы приводятся требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога.

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

SQL, Java и д. р.

-… 4. 3. 4. Требования к программному обеспечению Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

к независимости программных средств от используемых СВТ и операционной среды;

-… 4. 3. 5. Требования к техническому обеспечению Приводятся требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

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

Система должна быть реализована с использованием специально выделенных серверов Заказчика.

-… 4. 3. 6. Требования к метрологическому обеспечению В требованиях к метрологическому обеспечению приводят:

1) предварительный перечень измерительных каналов;

-… 4. 3. 7. Требования к организационному обеспечению Приводятся:

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

-… 4. 3. 8. Требования к методическому обеспечению Приводятся требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.

).

-… 4. 3. 9. Требования к патентной чистоте В требованиях по патентной чистоте указывают перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей.

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

Работы по созданию системы выполняются в три этапа:

Проектирование. Разработка эскизного проекта. Разработка технического проекта (продолжительность — X месяца).

-… 6. Порядок контроля и приёмки системы В разделе указывают:

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;

З) статус приемочной комиссии (государственная, межведомственная, ведомственная).

6. 1. Виды и объем испытаний системы Система подвергается испытаниям следующих видов:

1. Предварительные испытания.

-… 6. 2. Требования к приемке работ по стадиям Требования к приемке работ по стадиям приведены в таблице.

Стадия Участники Место и срок Порядок согласования документации Статус испытаний испытаний проведения приемочной комиссии Проведение предварительных испытаний.

Фиксирование выявленных неполадок в На Протоколе испытаний.

территории Устранение выявленных неполадок.

Предварител Организации Заказчика, с Проверка устранения выявленных Экспертная ьные Заказчика и dd. mm. yyyy неполадок. группа испытания Разработчика по dd. mm. Принятие решения о возможности передачи yyyy АИС в опытную эксплуатацию.

Составление и подписание Акта приёмки АИС в опытную эксплуатацию.

Проведение опытной эксплуатации.

Фиксирование выявленных неполадок в На Протоколе испытаний.

территории Устранение выявленных неполадок.

Организации Опытная Заказчика, с Проверка устранения выявленных Группа Заказчика и dd. mm. yyyy эксплуатация неполадок. тестирования Разработчика по dd. mm. Принятие решения о готовности АИС к yyyy приемочным испытаниям.

Составление и подписание Акта о завершении опытной эксплуатации АИС.

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

Фиксирование выявленных неполадок в Протоколе испытаний.

Устранение выявленных неполадок.

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

Приемочные Заказчика, с Приемочная Заказчика и Принятие решения о возможности передачи испытания dd. mm. yyyy комиссия Разработчика АИС в промышленную эксплуатацию.

по dd. mm.

Составление и подписание Акта о yyyy завершении приемочных испытаний и передаче АИС в промышленную эксплуатацию.

Оформление Акта завершения работ.

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

В перечень основных мероприятий включают:

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

-… 7. 1. Технические мероприятия Силами Заказчика в срок до начала этапа «Разработка рабочей документации. Адаптация программ» должны быть выполнены следующие работы:

- осуществлена подготовка помещения для размещения АТК системы в соответствии с требованиями, приведенными в настоящем техническом задании;

-… 7. 2. Организационные мероприятия Силами Заказчика в срок до начала этапа работ «Разработка рабочей документации.

Адаптация программ» должны быть решены организационные вопросы по взаимодействию с системами-источниками данных. К данным организационным вопросам относятся:

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

-… 7. 3. Изменения в информационном обеспечении Для организации информационного обеспечения системы должен быть разработан и утвержден регламент подготовки и публикации данных из систем-источников.

-… 8. Требования к документированию В данном разделе приводят:

1) согласованный Разработчиком и Заказчиком перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34. 201-89 и НТД отрасли Заказчика;

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

требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

Этап Документ Ведомость эскизного проекта Пояснительная записка к эскизному проекту Проектирование. Разработка эскизного проекта. Разработка Ведомость технического проекта технического проекта.

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

- Модель хранилища данных.

-… 9. Источники разработки Перечисляются документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др. ), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

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

Таблица Задание на работу 1. Проект информационной системы проката аудио- и видеокассет (дисков).

2. Проект информационной системы проката автомобилей.

3. Проект информационной системы учета продаж автомобилей.

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

5. Проект информационной системы учета книжного фонда в библиотеке.

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

7. Проект информационной системы учета промежуточной аттестации и тестирования в деканате.

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

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

10. Проект информационной системы регистрации пациентов в поликлинике.

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

12. Проект информационной системы составления расписания в учебном отделе ВУЗа.

13. Проект информационной системы для работы с вкладами в банке.

14. Проект информационной системы выдачи кредитов в банке.

15. Проект информационной системы по обслуживанию клиентов в ресторане.

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

17. Проект информационной системы учета текущей и итоговой успеваемости в школе.

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

19. Проект информационной системы учета гастролей детского коллектива танца и песни.

20. Проект информационной системы продажи билетов в театре.

21. Проект информационной системы продажи билетов на самолеты.

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

23. Проект информационной системы продажи билетов и абонементов в бассейн.

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

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

26. Проект информационной системы учета заказов такси.

27. Проект информационной системы учета ремонта и обслуживания вычислительной техники.

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

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

30. Проект информационной системы учета продажи книг в магазине.

31. Проект информационной системы учета вызовов скорой помощи.

32. Проект информационной системы учета вызовов пожарной службе.

33. Проект информационной системы учета безработных и вакансий в службе занятости.

34. Проект информационной системы учета горюче-смазочных материалов в автобусном парке.

35. Проект информационной системы регистрации рейсов в автобусном парке.

2. Проверить требования к разрабатываемой системе.

3. Оформить ТЗ в соотвествии с примером.

4. Представить работу к защите.

Требования к оформлению отчета В отчет по лабораторной работе включить краткое изложение порядка выполнения практической работы и выводы по полученным результатам 4 ЛАБОРАТОРНЫЙ ПРАКТИКУМ ПО ДИСЦИПЛИНЕ Оборуд Литера № Тема лекции Тема лаб. зан. Часы ование тура 1. Методология 1. Разработка 16 ЭВМ [2];

[3] ;

проектирования диаграмм вариантов [4] ;

[6] информационных систем использования по ;

[7] ;

деятельности [8] ;

[9] организации по учету ;

[11] заданной информации.

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

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

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

2. Современные подходы к 1. Установка и 16 ЭВМ [2];

[3] ;

разработке настройка среды для [4] ;

[6] информационных систем выполнения ;

[7] ;

проектирования [8] ;

[9] информационной ;

[11] системы на основе MDA подхода.

2. Создание информационной системы по заданной области с помощью MDA подхода.

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

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

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература [1];

[2] ;

[6] ;

[7] ;

[8].

Краткое изложение основных теоретических и методических аспектов работы UML (Universal Modeling Language) - универсальный язык моделирования, который был разработан компанией Rational Software с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании.

Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями).

В UML определено восемь видов диаграмм:

диаграмма вариантов использования (прецедентов) (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношения между ними;

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

диаграмма классов (Class diagram) - структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношения между ними;

диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий;

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

диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения;

диаграмма компонентов (Component diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий диаграмма развертывания (Deployment diagram) - структурная диаграмма, на которой показаны узлы и отношения между ними.

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

Рассмотрим основные элементы диаграммы прецедентов.

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

Стандартным графическим обозначением субъекта на диаграммах является фигурка "человечка", под которой записывается конкретное имя субъекта, однако субъектом может быть не только человек, но и техническое устройств о, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик.

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

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

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

Фрагмент внешне наблюдаемых функций (отличных от внутренних функций).

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

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

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

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

Отношение ассоциации (association) - определяет наличие канала связи между экземплярами субъекта и прецедента (или между экземплярами двумх субъектов).

Обозначается сплошной линией, возможно наличие стрелки и указание мощности связи.

Отношение расширения (extend) - определяет взаимосвязь экземпляров отдельного прецедента с более общим прецедентом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Обозначается пунктирной линией со стрелкой, направленной от того прецедента, который является расширением для исходного прецедента, и помечается ключевым словом "extend" ("расширяет").

Отношение включения (include) - указывает, что некоторое заданное поведение для одного прецедента включает в качестве составного компонента поведение другого прецедента. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров прецедентов всегда упорядочена в отношении включения.

Обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому, и помечается ключевым словом "include" ("включает").

Отношение обобщения (generalization) - служит для указания того факта, что некоторый прецедент А может быть обобщен до прецедента В. В этом случае прецедент А будет являться специализацией прецедента В. При этом В называется предком или родителем по отношению к А, а прецедент А - потомком по отношению к прецеденту В.

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

Пример. Магазин видеопродукции.

Магазин продает видеокассеты, DVD-диски, аудио-кассеты, CD-диски и т. д., а также предлагает широкой публике прокат видеокассет и DVD-дисков.

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

Видеоносители выдаются в прокат на срок от 1 до 7 дней. При прокате с клиента взимается залоговая стоимость видеоносителя. При возврате видеоносителя возвращается залоговая стоимость минус сумма за прокат. Если возврат задержан менее чем на 2 дня, взимается штраф в размере суммы за прокат за 1 день* кол-во дней задержки. При задержке возврата более чем на 2 дня - залоговая сумма не возвращается. Клиент может взять одновременно до 4 видеоносителей (прокат-заказ ). На каждый видеоноситель оформляется квитанция.

Клиенты могут стать членами видео-клуба и получить пластиковые карточки. С членов клуба не берется залог (за исключением случая описанного ниже), устанавливается скидка на ставку проката и покупку товаров. Члены клуба могут делать предварительные заказы на подбор видеоматериалов для проката или покупки.

Каждый член клуба имеет некоторый стутус. Первоначально - "новичок". При возврате всрок 5 прокат-заказов, статус меняется на "надежный". При задержке хотя бы одного видеоносителя более чем на 2 дня, статус "новичок" или "надежный" меняется на "ненадежный" и клиенту высылается предупреждение. При повторном нарушении правил статус меняется на "нарушитель". Члены клуба со статусом "надежный" могут брать до видеоносителей единовременно, все остальные - 4. С членов клуба со статусом "нарушитель" берется залоговая сумма.

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

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

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

В этом примере можно выделить следующие субъекты и соответствующие им прецеденты:

Менеджер - изучает рынок видеопродукции, анализирует продажи (прецедент "Запрос сведений"), работает с поставщиками: составляет заявки на поставки товара (прецедент "Оформление заказа" ), оплачивает и принимает товар (прецедент "Прием товара"), списывает товар (прецедент "Списание товара").

Продавец - работает с клиентами: продает товар (прецедент "Продажа видео"), оформляет членство в клубе (прецедент "Сопровождение клиентов"), резервирует (прецедент "Резервирование видио"), выдает в прокат (прецедент "Прокат видео") и принимает назад видеоносители (прецедент "Возврат видео"), отвечает на вопросы клиента (прецедент "Запрос сведений").

Поставщик - оформляет документы для оплаты товара (прецедент "Оформление заказа"), поставляет товар (прецедент "Прием товара")) Клиент - покупает(прецедент "Продажа видео"), берет на прокат и возвращает видеоносители (прецеденты "Прокат видео" и "Возврат видео"), вступает в клуб (прецедент "Сопровождение клиентов"), задает вопросы (прецедент "Запрос сведений").

Последние два субъекта Поставщик и Клиент не будут иметь непосредственного доступа к разрабатываемой системе (второстепенные субъекты), однако именно они являются основным источником событий, инициализирующих прецеденты, и получателями результата работы прецедентов От прецедента "Прокат видео" к прецеденту "Предупреждения" установлено отношение включения на том основании, что каждый выданный видеоноситель должен быть проверен на своевременный возврат и, в случае необходимости, выдано предупреждение клиенту.

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

Краткое описание Участвующие субъекты Предусловия, необходимые для инициирования прецедента Поток событий (основной и, возможно, подпотоки, альтернативный Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.

Таблица Описательная спецификация прецедента "Прокат видео" Раздел Описание Краткое описание Клиент желает взять на прокат видеокассету или диск, которые снимаются с полки магазина или были предварительно зарезервированы клиентом.

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

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

Субъекты Продавец, Клиент.

Предусловия В наличие имеются видеокассеты или диски, которые можно взять напрокат. У клиентов есть клубные карточки. Устройство сканирования работает правильно. Работники за прилавком знают, как обращаться с системой.

Клиент может назвать номер заказа или взять видеоноситель с полки.

Основной поток Видеоноситель и членская карточка сканируются и продавцу не сообщается никаких сведений о задержках, так, что он не задает клиенту соответствующих вопросов.

Если клиент имеет статус надежный, он может взять до видеоносителей, во всех остальных случаях - до 4-х.

Если статус клиента определен как нарушитель, его просят внести задаток.

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

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

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

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

У клиента нет членской карточки. В этом случае прецедент Альтернативный поток Сопровождение клиента может быть активизирован для выдачи новой карточки.

Видеофильмы не выдаются, поскольку у клиента есть невозвращенные в срок видеоносители.

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

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

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

1. Ознакомиться с методологией моделирования прецедентовна основе языка UML.

2. Ознакомиться с выполненным во 2 практической работе отчетом, содержащем техническое задание.

3. Описать несколько (2-3) прецедентов.

4. Построить диаграмму прецедентов для данного ТЗ.

4. Оформить отчет.

Требования к оформлению отчета В отчет по лабораторной работе включить краткое изложение порядка выполнения лабораторной работы и выводы по полученным результатам 4.2 Лабораторная работа. Разработка диаграмм классов по деятельности организации по учету заданной информации с использованием.

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

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература [1];

[2] ;

[6] ;

[7] ;

[8].

Краткое изложение основных теоретических и методических аспектов работы Основные понятия диаграмм классов UML Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов, а также связей между этими классами. Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке объектных ограничений OCL (Object Constraints Language).

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

Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута). Свойство, выражаемое атрибутом, является свойством моделируемой сущности, общим для всех объектов данного класса. Любой атрибут любого объекта класса должен иметь некоторое значение.

Знак «+» означает, что атрибут является публичным (public).

Знак «#» означает, что атрибут является защищенным(protected).

После имени следует указание типа атрибута.

Операцией класса называется именованная услуга, которую можно запросить у любого объекта этого класса. Операция – это абстракция того, что можно делать с объектом. Класс может содержать любое число операций (в частности, не содержать ни одной операции). Набор операций класса является общим для всех объектов данного класса.

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

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

Кроме классов, важным элементом диаграмм классов являются интерфейсы.

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

Категории связей. Связь-зависимость В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоциация (association). При проектировании реляционных БД наиболее важны вторая и третья категории связей, поэтому о связях зависимостях будет сказано только самое основное.

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

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

Связью-обобщением называется связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями «is a», имея в виду, что класс-потомок является частным случаем класса-предка.

Одиночное наследование является достаточным в большинстве случаев применения связи-обобщения. Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов.

Но, конечно, сложность проблемы именования атрибутов и операций несопоставимо меньше сложности реализации множественного наследования в реляционных БД. Поэтому при использовании UML для проектирования реляционных БД нужно очень осторожно использовать наследование классов вообще и стараться избегать множественного наследования.

Ассоциацией называется структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса.

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

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

Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации. Роль класса, как и имя конца связи в ER-модели, задается именем, помещаемым под линией ассоциации ближе к данному классу.

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


Кратностью (multiplicity) роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации (в UML экземпляр ассоциации называется соединением – link, но мы не будем здесь использовать этот термин, чтобы не создавать путаницу – все-таки трудно одновременно говорить про связи, ассоциации и соединения, имея в виду разные понятия). Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Например, указание «1» говорит о том, что каждый объект класса с данной ролью должен участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать ровно один объект класса с данной ролью.

В более сложных (но крайне редко встречающихся на практике) случаях определения кратности можно использовать списки диапазонов. Например, список «2, 4.. 6, 8.. *»

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

Для большей наглядности кроме стандартного значка класса, есть также дополнительные значки, которые применяются для некоторых типов классов. Я привел здесь три наиболее часто используемых обозначения, которые применяются для работы с шаблоном «Модель-Представление-Контроллер»

1. Класс-сущность (Entity) – обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах. Обозначается:

2. Класс-контроллер (Controller) – обычно используется для классов, которые используются для выполнения некоторых операций над объектами. Обозначается:

3. Класс-Разграничитель (Boundary) – обычно используется для классов, отделяющих внутреннюю структуру системы от внешней среды. Это могут быть WebServices, пользовательский интерфейс и пр.

Обозначается:

Пример диаграммы классов представлен на рисунке ниже:

Рис. 4.2 Диаграмма классов Последовательность выполнения лабораторной работы (диаграмма классов):

1. Ознакомиться с методологией моделирования классов на основе языка UML.

2. Ознакомиться с выполненным во 2 практической работе отчетом, содержащем техническое задание.

3. Выделить, описать и установить иерархию классов.

4. Построить диаграмму классов для данного ТЗ.

4. Оформить отчет.

Требования к оформлению отчета В отчет по лабораторной работе включить краткое изложение порядка выполнения лабораторной работы и выводы по полученным результатам 4.3 Лабораторная работа. Разработка диаграмм последовательности (заданных процессов) по деятельности организации по учету заданной.

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

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература [1];

[2] ;

[6] ;

[7] ;

[8].

Краткое изложение основных теоретических и методических аспектов работы Диаграммы деятельности (Activity diagram) Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения.

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

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

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

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

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

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

Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия или состояния деятельности, а дугами переходы от одного состояния действия/деятельности к другому. Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния (на практике иногда можно видеть несколько конечных состояний на одной диаграмме, но это одно и тоже состояние, изображенное несколько раз для лучшей читабельности диаграммы). Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз.

Рассмотрим основные элементы диаграммы деятельности.

Состояние деятельности (Activity, Process) - это продолжающийся во времени неатомарный шаг вычислений в автомате.

Состояния действия (action state) - состояние, которое представляет вычисление атомарного действия, как правило - вызов операции.

Состояния деятельности и состояния действия имеют одинаковое стандартное графическое обозначение - прямоугольник с закругленными краями. Внутри такого символа записывают произвольное выражение (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

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

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

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

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

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

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

Дорожки. При моделировании течения бизнес-процессов иногда бывает полезно разбить состояния деятельности на диаграммах деятельности на группы, каждая из которых представляет отдел компании, отвечающий за ту или иную работу. В UML такие группы называются дорожками (Swimlanes), поскольку визуально каждая группа отделяется от соседних вертикальной чертой, как плавательные дорожки в бассейне.

Дорожки - это разновидность пакетов, описывающие связанную совокупность работ.

Каждой присутствующей на диаграмме дорожке присваивается уникальное имя.

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

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

Рис. 4.4 Пример диаграммы деятельности На следующем рисунке приведена диаграмма деятельности прецедента "Прокат видео" для примера "Магазин видеопродукции" Рис. 4.5 диаграмма деятельности прецедента "Прокат видео" Последовательность выполнения лабораторной работы :

1. Ознакомиться с методологией моделирования деятельности на основе языка UML.

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

3. Оформить отчет.

Требования к оформлению отчета В отчет по лабораторной работе включить краткое изложение порядка выполнения лабораторной работы и выводы по полученным результатам 4.4 Лабораторная работа. Разработка диаграмм деятельности (заданного алгоритма) по организации по учету заданной информации.

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

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература [1];

[2] ;

[6] ;

[7] ;

[8].

Краткое изложение основных теоретических и методических аспектов работы Диаграммы взаимодействия Диаграммы взаимодействия (interaction diagrams) описывают взаимодействие групп объектов в различных условиях их поведения. Обычно диаграмма последовательности описывает один сценарий. На диаграмме показаны экземпляры объектов и сообщения, которыми обмениваются объекты в рамках одного прецедента (use case).

На диаграмме последовательности, каждый участник представлен вместе со своей линией жизни (lifeline), это вертикальная линия под объектом, вертикально упорядочивающая сообщения на странице. Важно: все сообщения на диаграмме следует читать сверху вниз. Каждая линия жизни имеет полосу активности (прямоугольники), которая показывает интервал активности каждого участника при взаимодействии.

Участники диаграммы именуются сделующим образом: имя : Класс, где и имя, и класс являются не обязательными, но если используется класс, то присутствие двоеточия обязательно.

Сообщения Сообщения можно разделить на 2 вида: синхронные (synchronous message) – требующие возврата ответа и асинхронные (asynchronous message) – ответ не тебуется и вызывающий объект может продолжать работу. На диаграмме синхронные вызовы обозначаются закрашенными стрелочками. Асинхронные – незакрашенными или половинными стрелочками.


Обратной пунктирной стрелкой показан возврат ответа на сообщение message (т. к.

сообщение message является синхронным). Лучше применять изображение возврата только в тех случаях, когда это поможет лучше понять устройство взаимодействия. Во всех остальных случаях, стоит опускать изображения возвратов, т. к. они будут вносить некоторую неразбериху. Просто, при использовании синхронного сообщения, стоит помнить, что у него всегда есть возврат.

Если в сообщении требуется передать параметры, то они указываются в скобках через запятую, с указанием типа параметра (см. сообшение messageText(text : string) ).

Подведем итог знаний о сообщениях в виде небольшой картинки-памятки:

Создание нового объекта – это сообщение create. Создаваемый объект находится всегда ниже объекта из которого он был создан. Если при создании применяется конструктор то имя сообщения не обязательно, но для ясности все же лучше писать new.

Удаление участника обохначается крестом. Стрелка сообщения идущая к такому кресту, означает, что один участник, явным образом удаляет другого участника. Если же крестик стоит в конце линии жизни участника, и к нему не идет никаких сообщений – это означает, что участник удаляет сам себя, т. е. срабатывает деконструктор Рис. 4.6 Различные графические примитивы диаграммы последовательности Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. ). Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом.

Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".

Линия жизни объекта Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.

Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней (объекты 1 и 2 на рис. ).

Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X" (объект 3 на рис. ). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

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

Рис. 4.7 Графическое изображение различных вариантов линий жизни и фокусов управления объектов Фокус управления В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 1), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона - окончание фокуса управления (окончание активности).

Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект 4 на рис. 2), если на всем ее протяжении он является активным.

С другой стороны, периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления (объект 5 на рис. 2). Важно понимать, что получить фокус управления может только существующий объект, у которого в этот момент имеется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который, строго говоря, будет являться другим объектом.

В отдельных случаях инициатором взаимодействия в системе может быть актер или внешний пользователь. В этом случае актер изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления (рис. 3).

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

Иногда некоторый объект может инициировать рекурсивное взаимодействие с самим собой. Речь идет о том, что наличие во многих языках программирования специальных средств построения рекурсивных процедур требует визуализации соответствующих понятий в форме графических примитивов. На диаграмме последовательности рекурсия обозначается небольшим прямоугольником, присоединенным к правой стороне фокуса управления того объекта, для которого изображается это рекурсивное взаимодействие (объект 7 на рис. 3).

Рис. 4.8 Графическое изображение актера, рекурсии и рефлексивного сообщения на диаграмме последовательности Сообщения Каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. В этом смысле сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено.

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

Рис. 4.9 Графическое изображение различных видов сообщений между объектами на диаграмме последовательности В языке UML могут встречаться несколько разновидностей сообщений, каждое из которых имеет свое графическое изображение (Рис. 4.9).

Первая разновидность сообщения (Рис. 4.9, а) является наиболее распространенной и используется для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления. Начало этой стрелки всегда соприкасается с фокусом управления или линией жизни того объекта-клиента, который инициирует это сообщение. Конец стрелки соприкасается с линией жизни того объекта, который принимает это сообщение и выполняет в ответ определенные действия. При этом принимающий объект зачастую получает и фокус управления, становясь активным.

Вторая разновидность сообщения (Рис. 4.9 б) используется для обозначения простого (невложенного) потока управления. Каждая такая стрелка указывает на прогресс одного шага потока. При этом соответствующие сообщения обычно являются асинхронными, т. е. могут возникать в произвольные моменты времени. Передача такого сообщения обычно сопровождается получением фокуса управления объектом, его принявшим.

Третья разновидность (Рис. 4.9, в) явно обозначает асинхронное сообщение между двумя объектами в некоторой процедурной последовательности. Примером такого сообщения может служить прерывание операции при возникновении исключительной ситуации. В этом случае информация о такой ситуации передается вызывающему объекту для продолжения процесса дальнейшего взаимодействия.

Наконец, последняя разновидность сообщения (Рис. 4.9, г) используется для возврата из вызова процедуры. Примером может служить простое сообщение о завершении некоторых вычислений без предоставления результата расчетов объекту-клиенту. В процедурных потоках управления эта стрелка может быть опущена, поскольку ее наличие неявно предполагается в конце активизации объекта. В то же время считается, что каждый вызов процедуры имеет свою пару - возврат вызова. Для непроцедурных потоков управления, включая параллельные и асинхронные сообщения, стрелка возврата должна указываться явным образом.

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

При этом неявно предполагается, что время передачи сообщения достаточно мало по сравнению с процессами выполнения действий объектами. Считается также, что за время передачи сообщения с соответствующими объектами не может произойти никаких событий. Другими словами, состояния объектов остаются без изменения. Если же это предположение не может быть признано справедливым, то стрелка сообщения изображается под некоторым наклоном, так чтобы конец стрелки располагался ниже ее начала.

Ветвление потока управления Для изображения ветвления рисуются две или более стрелки, выходящие из одной точки фокуса управления объекта (фокус управления объекта 1 на Рис. 4.9). Как нетрудно представить, если условие записано в форме булевского выражения, то ветвление будет содержать только две ветви. В любом случае условия должны взаимно исключать одновременную передачу альтернативных сообщений.

С помощью ветвления можно изобразить и более сложную логику взаимодействия объектов между собой (фокус управления объекта 1 на Рис. 4.10). Если условий более двух, то для каждого из них необходимо предусмотреть ситуацию единственного выполнения.

Рассматриваемый пример относится к моделированию взаимодействия программной системы обслуживания клиентов в банке. На этом примере диаграммы последовательности объект 1 передает управление одному из трех других объектов.

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

"call" (вызвать) - сообщение, требующее вызова операции или процедуры принимающего объекта. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у самого пославшего это сообщение объекта;

"return" (возвратить) - сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления;

"create" (создать) - сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может получить фокус управления, а может и не получить его;

"destroy" (уничтожить) - сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы;

"send" (послать) - обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается (перехватывается) другим.

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

Ниже представлена диаграмма последовательности для рассмотренного выше случая ветвления, дополненная стереотипными значениями (Рис. 4.11).

Кроме стереотипов, сообщения могут иметь собственное обозначение операции, вызов которой они инициируют у принимающего объекта. В этом случае рядом со стрелкой записывается имя операции с круглыми скобками, в которых могут указываться параметры или аргументы соответствующей операции. Если параметры отсутствуют, то скобки все равно должны присутствовать после имени операции. Примерами таких операций могут служить следующие: "выдать клиенту наличными сумму (п)", "установить соединение между абонентами (а, Ь)", "сделать вводимый текст невидимым ()", "подать звуковой сигнал тревоги ()".

Рис. 4.11 Диаграмма последовательности со стереотипными значениями сообщений Временные ограничения на диаграммах последовательности В отдельных случаях выполнение тех или иных действий на диаграмме последовательности может потребовать явной спецификации временных ограничений, накладываемых на сам интервал выполнения операций или передачу сообщений. В языке UML для записи временных ограничений используются фигурные скобки. Временные ограничения могут относиться как к выполнению определенных действий объектами, так и к самим сообщениям, явно специфицируя условия их передачи или приема. Важно понимать, что в отличие от условий ветвления, которые должны выполняться альтернативно, временные ограничения имеют обязательный или директивный характер для ассоциированных с ними объектов.

Временные ограничения могут записываться рядом с началом стрелки соответствующего сообщения. Но наиболее часто они записываются слева от этой стрелки на одном уровне с ней. Если временная характеристика относится к конкретному объекту, то имя этого объекта записывается перед именем характеристики и отделяется от нее точкой.

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

{время_приема_сообщения время_отправки_сообщения 1 сек. } {время_ожидания_ответа 5 сек. } {время_передачи_пакета 10 сек. } {объект_1. время_подачи_сигнала_тревоги 30 сек. } Комментарии или примечания Комментарии или примечания уже рассматривались ранее при изучении других видов диаграмм. Они могут включаться и в диаграммы последовательности, ассоциируясь с отдельными объектами или сообщениями. При этом используется стандартное обозначение для комментария - прямоугольник с "заломленным" правым верхним углом. Внутри этого прямоугольника записывается текст комментария на естественном языке.

Пример построения диаграммы последовательности В качестве примера рассмотрим построение диаграммы последовательности для моделирования процесса телефонного разговора с использованием обычной телефонной сети. Объектами в этом примере являются: два абонента а и Ь, два телефонных аппарата end, коммутатор и сам разговор как объект моделирования. При этом как коммутатор, так и разговор являются анонимными объектами.

На первом этапе располагаем выбранные объекты на предполагаемой диаграмме (Рис.

4.12). Заметим, что абонентов мы будем рассматривать как актеров, причем первый из них - а - играет активную роль, а второй - b - пассивную роль. Поэтому первый получает фокус управления сразу после своего появления в системе, а второй имеет только линию жизни.

Коммутатор также имеет постоянную активность, что изображается его фокусом управления. Разговор как объект появляется только после установки соединения и уничтожается с его прекращением. Поэтому он будет изображен позже на этой же диаграмме последовательности.

Рис. 4.12 Начальный фрагмент диаграммы последовательности для моделирования телефонного разговора Процесс взаимодействия в этой системе начинается с поднятия трубки телефонного аппарата первым абонентом. Тем самым он посылает сообщение телефонному аппарату с, которое переводит этот аппарат в активное состояние и вызывает действие - подачу тонового сигнала в телефонную трубку для первого абонента. Следующее действие также инициируется первым абонентом - набор цифр телефонного номера. Это представлено в форме итеративного сообщения со знаком "*" слева от его имени.

Заметим, что поднятие телефонной трубки и набор цифр номера являются физическими действиями и поэтому изображаются в форме простых асинхронных сообщений. После набора цифр'номера телефона аппарат с рекурсивно вызывает процедуру посылки коммутационных импульсов на коммутатор. Последний инициирует создание нового объекта в моделируемой системе - телефонного разговора. Дополненный фрагмент диаграммы последовательности изображен на Рис. 4.13.

После создания анонимный объект "разговор" сразу получает фокус активности и посылает сообщение телефонному аппарату d на выполнение действия - звонка вызова.

При этом второй абонент снимает трубку (асинхронное сообщение), тем самым устанавливается прямое соединение между абонентами а и Ь. После того как абоненты опустят трубки, разговор заканчивается. Тем самым объект "разговор" уничтожается.

Окончательный вариант диаграммы последовательности может содержать некоторые временные ограничения и комментарии (Рис. 4.14). Назначение отдельных сообщений соответствуют рассмотренным действиям.

Рис. 4.13 Дополненный фрагмент диаграммы последовательности для моделирования телефонного разговора Рис. 4.14 Окончательный вариант диаграммы последовательности для моделирования телефонного разговора Последовательность выполнения лабораторной работы (диаграмма последовательностей):

1. Ознакомиться с методологией моделирования диаграмм последовательностей на основе языка UML.

2. Ознакомиться с выполненным во 2 практической работе отчетом, содержащем техническое задание.

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

4. Нанести все объекты на диаграмму с соблюдением некоторого порядка инициализации сообщений.

5. Установить, какие объекты будут существовать постоянно, а какие временно только на период выполнения ими требуемых действий.

6. Выполнить спецификацию сообщений. При необходимости уточнения этих ролей надо использовать их разновидности и стереотипы. Для уничтожения объектов, которые создаются на время выполнения своих действий, нужно предусмотреть явное сообщение.



Pages:     | 1 |   ...   | 3 | 4 || 6 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.