Document 873128

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Институт математики и компьютерных наук
Кафедра математики и информатики
Григорьев М. В.
СИСТЕМЫ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ
Учебно-методический комплекс. Рабочая программа
для студентов направления 02.03.01 «Математика и компьютерные науки»
очной формы обучения
Тюменский государственный университет
2014
21
Григорьев М.В. Системы автоматизированного проектирования. Учебнометодический комплекс. Рабочая программа для студентов направления
02.03.01 «Математика и компьютерные науки» очной формы обучения.
Тюмень, 2014, 24 стр.
Рабочая программа составлена в соответствии с требованиями ФГОС ВО с
учетом рекомендаций и ПрОП ВО по направлению и профилю подготовки.
Рабочая программа дисциплины (модуля) опубликована на сайте ТюмГУ:
Системы автоматизированного проектирования [электронный ресурс] / Режим
доступа: http://www.umk3plus.utmn.ru,, свободный.
Рекомендовано к изданию кафедрой математики и информатики. Утверждено
директором Института математики и компьютерных наук.
ОТВЕТСТВЕННЫЙ РЕДАКТОР: Григорьев М.В., к.т.н., и.о. заведующего
кафедрой
© Тюменский государственный университет, 2014.
© Григорьев М.В., 2014.
1.
Пояснительная записка
1.1.
Цели и задачи дисциплины (модуля)
Целью изучения дисциплины «Системы автоматизированного проектирования» является
освоение обучающихся профессиональными компетенциями, включающими в себя
способность:
•
оценить уровень развития современных способов разработки программных систем;
•
понимать основные принципы проектирования и моделирования приложений;
•
понимать возможности эффективного использования объектных технологий
профессиональной деятельности;
•
использовать базовые возможности языка UML и понимать специфику работы в
команде;
•
работать с основными типами диаграмм, включённых в программу обучения;
•
понимать структуру и взаимосвязь проектных моделей и исходного кода
программных систем.
1.2.Место дисциплины в структуре образовательной программы
Дисциплина относится к дисциплинам по выбору вариативной части блока 1
программы бакалавриата.
Учебная дисциплина «Системы автоматизированного проектирования» базируется на
знаниях и умениях, полученных при изучении дисциплин: Основы компьютерных наук,
Технологии программирования, Объектно-ориентированное программирование и Базы
данных.
Данная дисциплина является предшествующей для следующих дисциплин:
Современные Web-технологии, .Разработка Web-приложений.
Для изучения дисциплины студенты должны обладать начальными знаниями
компьютерных наук, полученными при изучении дисциплины «Основы компьютерных
наук», знаниями технологий программирования, навыками объектно-ориентированной
разработки программного обеспечения, приобретенными в рамках дисциплин «Технологии
программирования», «Объектно-ориентированное программирование» и основ обработки и
хранения больших объемов данных, полученных при изучении дисциплины «Базы данных»,
а также умениями применять полученные знания на практике.
По
результатам
изучения
дисциплины
«Системы
автоматизированного
проектирования» студенты приобретают знания, умения и навыки проектирования и
моделирования программных систем с применением объектных технологий, что позволит
перейти к изучению дисциплин «Современные Web-технологии», «Разработка Webприложений», выполнять курсовые работы по направлению и ВКР.
Таблица 1.
Разделы дисциплины и междисциплинарные связи с обеспечиваемыми
(последующими) дисциплинами
№
Наименование
Темы дисциплины необходимые для изучения
п/п
обеспечиваемых
обеспечиваемых (последующих) дисциплин
(последующих) дисциплин
1.1
1.2
2.1
2.1
3.1
3.2
1.
2.
3.
4.
Современные Webтехнологии
Разработка Web-приложений
Курсовые работы по
направлению
ВКР
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
1.3. Компетенции обучающегося, формируемые в результате освоения данной
образовательной программы.
В результате освоения ОП выпускник должен обладать следующими компетенциями:
3
общепрофессиональными:
 способностью решать стандартные задачи профессиональной деятельности на основе
информационной и библиографической культуры с применением информационнокоммуникационных технологий и с учетом основных требований информационной
безопасности (ОПК-2);
профессиональными:
 способностью публично представлять собственные и известные научные результаты
(ПК-4).
1.4. Перечень планируемых результатов обучения по дисциплине (модулю):
знать:
•
основные
подходы,
понятия,
связанные
с
объектно-ориентированным
проектированием программного обеспечения;
•
понятие и составные части архитектуры программных систем;
•
ключевые диаграммы языка UML для описания моделей программных систем;
•
основные принципы моделирования ПО, правила построения и документирования
программного кода, лучшие практики разработки ПО;
уметь:
•
описывать архитектуру программных систем;
•
разрабатывать и специфицировать диаграммы прецедентов, объектов, классов,
последовательностей, состояний;
•
руководствоваться отраслевыми стандартами и иными регламентирующими
документами в сфере разработки программного обеспечения;
•
создавать проектную документацию;
владеть:
•
основными навыками работы с CASE-инструментарием;
•
навыками построения типов диаграмм, включённых в программу обучения;
•
навыками представления архитектуры программных систем и проектной
документации;
•
терминологией используемой при проектировании программных систем.
2. Структура и трудоемкость дисциплины.
Семестр 6. Форма промежуточной аттестации (зачет, экзамен) экзамен. Общая
трудоемкость дисциплины составляет 3 зачетных единицы, 108 академических часов, из них
57,75 часа, выделенных на контактную работу с преподавателем, 50,25 часов, выделенных на
самостоятельную работу.
3. Тематический план
Таблица 3.
4
Самостоятельная
работа
Лабораторные
занятия
2
Модуль 1
Семинарские
(практические)
занятия
1
Виды учебной работы и
самостоятельная работа, в
час.
Лекции
Тема
недели семестра
№
Итого
часов
по
теме
Из них в
интерак
тивной
форме, в
часах
Итого
количес
тво
баллов
1.1
1.2
2.1
2.2
3.1
3.2
Объектное
проектирование
Процесс и
унифицированный
язык
проектирования
Всего
Модуль 2
Моделирование
требований
Объекты и классы
Всего
Модуль 3
Наследование и
полиморфизм.
Отношения
Реализация
прецедентов
Всего
Итого (часов,
баллов) *:
Из них в интеракт.
форме
1
2
6
8
16
0-15
3
4
6
8
18
6
12
16
34
7
4
6
8
18
4
0-15
11
2
6
6
12
8
16
16
34
2
0-15
0-30
13
2
6
12
20
2
0-20
15
4
6
10
20
4
0-20
6
18
12
36
22
54
40
14
0-40
0-100
4
10
2
0-15
0-30
14
* с учетом иных видов работ
4. Виды и формы оценочных средств в период текущего контроля
Таблица 4.
контрольная
работа
тест
реферат
эссе
программы
компьютерног
о тестирования
комплексные
ситуационные
задания
электронные
практикумы
другие формы
Итого количество баллов
Информа
ции
онные
системы и
технологи
и
лабораторная
работа
Технические
формы
контроля
ответ на
семинаре
Модуль 1
1.1
1.2
Всего
Модуль 2
2.1
2.2
Всего
Модуль 3
3.1
3.2
Всего
Итого
Письменные работы
собеседование
Устный опрос
коллоквиумы
№
Темы
-
0-2
0-2
0-4
-
-
-
-
-
0-3
0-3
0-6
-
0-10
0-10
0-20
-
0-15
0-15
0-30
-
0-2
0-2
0-4
-
-
-
-
-
0-3
0-3
0-6
-
0-10
0-10
0-20
-
0-15
0-15
0-30
-
0-2
0-2
0-4
0-12
-
0-2
0-2
0-4
0-4
-
-
-
0-3
0-3
0-6
0-18
0-3
0-3
0-6
0-6
0-10
0-10
0-20
0-60
-
0-20
0-20
0-40
0100
5
5. Содержание дисциплины.
ТЕМА 1.1 Объектное проектирование
Лучшие практики разработки ПО. Итеративный подход к разработке. Планирование
проекта.
ТЕМА 1.2 Процесс и унифицированный язык проектирования
Унифицированные
процессы.
Основные
принципы
моделирования.
Унифицированный язык моделирования UML.
ТЕМА 2.1 Моделирование требований
Моделирование прецедентов. Спецификации прецедентов. Моделирование потока
действий прецедента. Моделирование альтернативных потоков. Уточнение диаграммы
прецедентов.
ТЕМА 2.2 Объекты и классы
Объекты. Сообщения. Классы. Моделирование классов в UML. Область действия.
Выявление классов.
ТЕМА 3.1 Наследование и полиморфизм. Отношения
Обобщение. Наследование. Переопределение. Отношение. Ассоциация. Зависимость.
ТЕМА 3.2 Реализация прецедентов
Взаимодействия. Линии жизни. Сообщения. Диаграммы последовательностей.
Комбинированные фрагменты и операторы.
6. Планы семинарских занятий.
Не планируется
7. Темы лабораторных работ (Лабораторный практикум).
Тема 1.2. Процесс и унифицированный язык проектирования
Объект исследования: разработка макета информационной системы.
Инструментарий: Microsoft Office Visio, Microsoft Office Word, Software Ideas Modeler.
Исследование: Планирование требований к информационной системе; сбор
пользовательской
информации;
детализированное
проектирование,
построение
(прототипирование) информационной системы
Тема 2.1. Моделирование требований
Объект исследования: разработка макета информационной системы.
Инструментарий: Microsoft Office Visio, Microsoft Office Word, Software Ideas Modeler.
Исследование: Знакомство с CASE-средствами, создание структуры модели
программного обеспечения
Тема 2.2. Объекты и классы
Объект исследования: разработка макета информационной системы.
Инструментарий: Microsoft Office Visio, Microsoft Office Word, Software Ideas Modeler.
Исследование: Ознакомление с формами исходных документов предметной области,
выделение всех атрибутов документов; определение количества возможных значений
атрибутов и доменов атрибутов; выделение составных, производных атрибутов;
идентификация типов сущностей и типов связей, представляющих интерес для
проектируемой базы данных; определение ограничения кратности каждого типа связи в
модели; определение выделенных атрибутов у типов сущностей и типов связей, и выделение
атрибутов первичных ключей; анализ исходных документов и принятие решения об
использовании специализации/генерализация и категоризации типов сущностей; на основе
диаграммы «сущность-связь» разработка схемы реляционной базы данных; разработка
приложения; реализация формирования отчетов в соответствии с формами исходной
документации
Тема 3.1. Наследование и полиморфизм. Отношения
Объект исследования: разработка макета информационной системы.
Инструментарий: Microsoft Office Visio, Microsoft Office Word, Software Ideas Modeler.
Исследование: Разработка диаграммы потоков данных; разработка словаря данных;
представление содержимого словаря данных; описание БНФ – нотации
6
Тема 3.2. Реализация прецедентов
Объект исследования: разработка макета информационной системы.
Инструментарий: Microsoft Office Visio, Microsoft Office Word, Software Ideas Modeler.
Исследование: Разработка спецификаций процессов; имитация проектных
спецификаций.
8. Примерная тематика курсовых работ
Не предусмотрены.
9. Учебно-методическое обеспечение и планирование самостоятельной работы
студентов.
Таблица5 .
№
Модули и темы
Модуль 1
1.1 Объектное
проектирование
1.2 Процесс и
унифицированный
язык
проектирования
Всего
Модуль 2
2.1 Моделирование
требований
Виды СРС
обязательные
дополнительные
запись лекций,
проработка
лекций,
выполнение
заданий по
программам
практик и
практикумов
чтение
обязательной и
дополнительной
литературы,
знакомство с
содержанием
электронных
источников,
самостоятельное
изучение
заданного
материала
чтение
обязательной и
дополнительной
литературы,
знакомство с
содержанием
электронных
источников,
самостоятельное
изучение
заданного
материала
запись лекций,
проработка
лекций,
выполнение
заданий по
программам
практик и
практикумов
запись лекций,
проработка
лекций,
выполнение
заданий по
программам
практик и
практикумов
чтение
обязательной и
дополнительной
литературы,
знакомство с
содержанием
электронных
источников,
самостоятельное
изучение
заданного
материала
7
Неделя
семестра
Объем
часов *
Кол-во
баллов
1
8
0-15
3
8
0-15
16
0-30
8
0-15
7
2.2 Объекты и классы
Всего
Модуль 3
3.1 Наследование и
полиморфизм.
Отношения
3.2 Реализация
прецедентов
запись лекций,
проработка
лекций,
выполнение
заданий по
программам
практик и
практикумов
запись лекций,
проработка
лекций,
выполнение
заданий по
программам
практик и
практикумов,
анализ
ситуаций;
упражнения на
решение
проблем
запись лекций,
проработка
лекций,
выполнение
заданий по
программам
практик и
практикумов,
анализ
ситуаций;
упражнения на
решение
проблем
чтение
обязательной и
дополнительной
литературы,
знакомство с
содержанием
электронных
источников,
самостоятельное
изучение
заданного
материала
11
8
0-15
16
0-30
чтение
обязательной и
дополнительной
литературы,
знакомство с
содержанием
электронных
источников,
самостоятельное
изучение
заданного
материала
13
12
0-20
чтение
обязательной и
дополнительной
литературы,
знакомство с
содержанием
электронных
источников,
самостоятельное
изучение
заданного
материала
15
10
0-20
22
54
0-40
0-100
Всего
Итого
* с учетом иных видов работ
10.Фонд оценочных средств для проведения промежуточной аттестации по итогам
освоения дисциплины (модуля).
10.1 Перечень компетенций с указанием этапов их формирования в процессе освоения
образовательной программы (выдержка из матрицы компетенций):
8
2 семестр
3 семестр
* Фундаментальная и компьютерная алгебра
* Фундаментальная и компьютерная алгебра
Системы компьютерной математики
Инструментальные средства компьютерного моделирования
Системы автоматизированного проектирования
Системы автоматизированного проектирования
Информационные системы в нефтегазовом комплексе
Информационные системы в экономике
Современные Web-технологии
Разработка Web-приложений
+
+
+
+
+
+
+
+
+
+
+
+
+
Б.2.3 Преддипломная практика
ВКР
+
Б.2.2 Курсовые работы по направлению
8
семест
р
Б.2.1 Учебная практика
7 семестр
Методологические основы обучения математике
Б.1. Дисциплины (модули)
4
семест
5 семестр
6 семестр
р
История развития математической науки
Проектирование и разработка Web-приложений
Индекс
компетенции
Общекультурные, общепрофессиональные компетенции
ОПК-2
+
+
+
+ + + +
Профессиональные, профессионально-специализированные компетенции
ПК-4
+ +
+ +
+ +
+
+
9
Инструментальные средства компьютерного моделирования
Системы компьютерной математики
Мультимедиа технологии
Базы данных
Объектно-ориентированное программирование
* Дифференциальные уравнения
Объектно-ориентированное программирование
* Дифференциальные уравнения
Технологии программирования
* Аналитическая геометрия
* Основы компьютерных наук
* Аналитическая геометрия
1 семестр
* Фундаментальная и компьютерная алгебра
Циклы,
дисциплины
учебного
плана ОП
Б.2.
Практики
/ НИР
Б.3
.
ГИ
А
+
+
+
+
+
+
+
+
Код
компетенции
10.2 Описание показателей и критериев оценивания компетенций на различных этапах
их формирования, описание шкал оценивания:
Таблица 6.
Карта критериев оценивания компетенций
ОПК-2
Критерии в соответствии с уровнем
освоения ОП
пороговый
(удовл.)
61-75 баллов
базовый
(хор.)
76-90 баллов
Знает:
•
основные
принципы
моделирован
ия ПО;
Умеет:
•
разрабатыват
ь
и
специфициро
вать
диаграммы
прецедентов,
классов,
последовател
ьностей,
состояний;
Владеет:
• основными
навыками
работы
с
CASEинструментар
ием.
Знает:
• понятие и
составные
части
архитектуры
программных
систем;
•
основные
принципы
моделирован
ия ПО;
Умеет:
•
разрабатыват
ь
и
специфициро
вать
диаграммы
прецедентов,
классов,
последовател
ьностей,
состояний;
•
руководствов
аться
регламентиру
ющими
документами
в
сфере
разработки
программног
о
обеспечения;
Владеет:
• основными
навыками
работы
с
CASEинструментар
ием;
•
терминологи
ей
Виды занятий
(лекции, семинар
ские, практические,
лабораторные)
повышенны
й
(отл.)
91-100
баллов
Знает:
Лекции,
• понятие и лабораторные
составные
занятия
части
архитектуры
программных
систем;
•
основные
принципы
моделирован
ия
ПО,
правила
построения и
документиро
вания
программног
о
кода,
лучшие
практики
разработки
ПО;
Умеет:
•
разрабатыват
ь
и
специфициро
вать
диаграммы
прецедентов,
объектов,
классов,
последовател
ьностей,
состояний;
•
руководствов
аться
отраслевыми
стандартами
и
иными
регламентиру
ющими
документами
в
сфере
10
Оценочные
средства (тесты,
творческие
работы, проекты
и др.)
Ответ
на
семинаре,
программы
компьютерного
тестирования,
электронные
практикумы
используемо
й
при
проектирован
ии
программных
систем.
ПК-4
Знает:
• диаграммы
объектов,
классов,
прецедентов,
последовател
ьностей
языка UML
для описания
моделей
программных
систем;
Умеет:
• описывать
архитектуру
программных
систем;
Владеет:
• навыками
построения
диаграмм
классов,
прецедентов,
последовател
ьностей.
Знает:
•
основные
подходы,
понятия,
связанные с
объектноориентирован
ным
проектирован
ием
программног
о
обеспечения;
• ключевые
диаграммы
языка UML
для описания
моделей
программных
систем;
Умеет:
• описывать
архитектуру
программных
систем;
Владеет:
• навыками
построения
типов
диаграмм,
включённых
в программу
обучения.
разработки
программног
о
обеспечения;
Владеет:
• основными
навыками
работы
с
CASEинструментар
ием;
•
терминологие
й
используемо
й
при
проектирован
ии
программных
систем.
Знает:
Лекции,
•
основные лабораторные
подходы,
занятия
понятия,
связанные с
объектноориентирован
ным
проектирован
ием
программног
о
обеспечения;
• ключевые
диаграммы
языка UML
для описания
моделей
программных
систем;
Умеет:
• описывать
архитектуру
программных
систем;
•
создавать
проектную
документаци
ю;
Владеет:
• навыками
построения
типов
диаграмм,
включённых
в программу
11
Контрольная
работа,
программы
компьютерного
тестирования,
электронные
практикумы
обучения;
• навыками
представлени
я
архитектуры
программных
систем
и
проектной
документаци
и.
10.3 Типовые контрольные задания или иные материалы, необходимые для оценки
знаний, умений, навыков и (или) опыта деятельности, характеризующей этапы
формирования компетенций в процессе освоения образовательной программы.
Учебно-методическое обеспечение выполнения обучающимися самостоятельных
заданий лабораторного практикума включает методические указания к выполнению каждого
задания (выдаются обучающимся в электронном виде).
Контрольные тестовые вопросы для проведения текущего контроля и промежуточной
аттестации:
1. Полиморфизм означает:
1) много форм
2) общая сущность
3) наследование
4) несколько реализаций
2. Отношение агрегации (незакрашенный ромб) описывается утверждением:
1)
2)
3)
4)
3.
имеет
является
использует
является частью
Элемент диаграммы, представленный на рисунке – это:
1)
2)
3)
4)
4.
прецедент
класс
объект
интерфейс
Элемент диаграммы Sequence, помеченный на рисунке, это:
12
1)
2)
3)
4)
5.
1)
2)
3)
4)
6.
1)
2)
3)
4)
7.
линия активации
объект
сообщение
линия жизни
Диаграмма деятельности (Activity) может иметь:
только одно начальное и одно конечное состояние
одно начальное и несколько конечных состояний
несколько начальных и одно конечное состояние
несколько начальных и несколько конечных состояний
Диаграмма ______ наиболее удобная для моделирования динамической части
задачи.
последовательности (Sequenсe)
деятельности (Activity)
прецедентов (Use Case)
развертывания (Deployment)
Элемент UML, представленный на изображении:
прецедент
объект
актер
класс
При построении диаграммы Use Case:
необходимо моделировать связи между действующими лицами
необходимо соединять стрелкой два варианта использования непосредственно
каждый вариант использования должен быть инициирован действующим лицом
каждому прецеденту соответствует только один Actor
Стандарт,
который
использует
общую
методологию
визуального
моделирования:
1) OMT
2) UML
3) Analysis
4) Booch
10. Диаграмма взаимодействий, в которой основной акцент сделан на структурной
организации объектов, посылающих и получающих сообщения – это диаграмма:
1) кооперации (Collaboration)
1)
2)
3)
4)
8.
1)
2)
3)
4)
9.
13
2) последовательности (Sequence)
3) развертывания (Deployment)
4) компонентов (Components)
10.4 Методические материалы, определяющие процедуры оценивания знаний, умений,
навыков и (или) опыта деятельности характеризующих этапы формирования
компетенций.
Текущий контроль представляет собой проверку усвоения учебного материала,
регулярно осуществляемую на протяжении семестра. Таким образом реализуется
непрерывный мониторинг качества обучения, а также возможность балльно-рейтинговой
оценки успеваемости студента.
Собеседование (УО-1) – специальная беседа преподавателя со студентом на темы,
связанные с изучаемой дисциплиной, рассчитанная на выяснение объема знаний студента по
определенному разделу, теме, проблеме и т.п.
Зачет (УО-3) и экзамен (УО-4) представляют собой формы периодической
отчетности студента, определяемые учебным планом подготовки по направлению ВПО.
Зачеты служат формой проверки качества выполнения студентами лабораторных работ,
усвоения учебного материала практических и семинарских занятий, успешного прохождения
производственной и преддипломной практик и выполнения в процессе этих практик всех
учебных поручений в соответствии с утвержденной программой. Оценка, выставляемая за
зачет, может быть как квалитативного типа (по шкале наименований «зачтено» / «не
зачтено»), так и квантитативного (т.н. дифференцированный зачет с выставлением отметки
по шкале порядка – «отлично», «хорошо» и т.д.).
Экзамен по дисциплине (модулю) служит для оценки работы студента в течение
семестра (года, всего срока обучения и др.) и призван выявить уровень, прочность и
систематичность полученных им теоретических и практических знаний, приобретения
навыков самостоятельной работы, развития творческого мышления, умение синтезировать
полученные знания и применять их в решении практических задач. По итогам экзамена, как
правило,
выставляется
оценка
по
шкале
порядка:
«отлично»,
«хорошо»,
«удовлетворительно», «неудовлетворительно».
Тест (ПР-1) является простейшей формой контроля, направ ленной на проверку
владения терминологическим аппаратом, современными информационными технологиями и
конкретными знаниями в области фундаментальных и прикладных дисциплин. Тест состоит
из небольшого количества элементарных задач; может предоставлять возможность выбора из
перечня ответов; занимает часть учебного занятия (10–30 минут); правильные решения
разбираются на том же или следующем занятии; частота тестирования определяется
преподавателем.
Контрольная работа (ПР-2) является более сложной формой проверки; она может
применяться для оценки знаний по базовым и вариативным дисциплинам циклов ГСЭ, МЭН
и профессионального. Контрольная работа, как правило, состоит из небольшого количества
средних по трудности вопросов, задач или заданий, требующих поиска обоснованного
ответа. Контрольная работа может занимать часть или полное учебное занятие с разбором
правильных решений на следующем занятии. Рекомендуемая частота проведения – не менее
одной при каждой текущей и промежуточной аттестации.
Электронные тесты являются эффективным средством контроля результатов
образования на уровне знаний и понимания. Во время тестирования студенту
последовательно предъявляются тест-кадры. К базовой группе тест-кадров относятся:
информационный кадр, задание закрытого типа, задание открытого типа, задание на
установление правильной последовательности и задание на установление соответствия.
Согласно «Положению о рейтинговой системе оценки успеваемости студентов
Федерального государственного бюджетного образовательного учреждения высшего
профессионального образования «Тюменский государственный университет» (приложение 1
14
к приказу ректора № 190 от 04.04.2014г.) всех формы текущего контроля, предусмотренные
рабочей программой, оцениваются в баллах. Дисциплинарные модули, формы текущего
контроля и шкала баллов, по которым они оцениваются, отражены в разделе «Тематический
план».
Студенты, набравшие по дисциплине в период проведения текущего контроля от 35
до 60 баллов допускаются к зачету или экзамену. Если в период проведения текущей
аттестации студент набрал 61 балл и более, то он автоматически получает зачет или
экзаменационную оценку в соответствии со шкалой перевода, но в то же время он имеет
право повысить оценку, полученную по итогам рейтинга (удовлетворительно, хорошо),
путем сдачи экзамена.
Шкала перевода баллов в оценки:
от 0 до 60 баллов – «не зачтено»;
от 61 до 100 баллов – «зачтено»;
60 баллов и менее – «неудовлетворительно»;
от 61 до 75 баллов – «удовлетворительно»;
от 76 до 90 баллов – «хорошо»;
от 91 до 100 баллов – «отлично».
Преподаватель может использовать систему штрафов, уменьшая набранные баллы за
пропуски занятий без уважительных причин, за нарушение сроков выполнения учебных
заданий, за систематический отказ отвечать на занятиях и т.д. Возможно также начисление
премиальных баллов за работы, выполненные студентом на высоком уровне.
Студенты, набравшие по дисциплине менее 35 баллов к экзамену (зачету) не
допускаются. Необходимое количество баллов (до 35) для получения допуска к экзамену
(зачету), студенты набирают после третьей контрольной недели.
11. Образовательные технологии.
В рамках учебного курса предусматривается разбор конкретных ситуаций (метод
кейсов). Технология концентрированного обучения. Технология обучения как учебного
исследования. Традиционная технология с использованием таких элементов как лекции и
практические задания.
Предусмотрены интерактивные формы проведения занятий:
 анализ результатов;
 организация дискуссий и круглых столов;
 проведение семинаров в диалоговом режиме.
12. Учебно-методическое и информационное обеспечение дисциплины (модуля).
12.1 Основная литература:
1.
Коваленко, В. В. Проектирование информационных систем [Электронный ресурс]:
Учебное пособие / В.В. Коваленко. - М.: Форум: НИЦ ИНФРА-М, 2014. Гриф
УМО. Режим доступа: http://znanium.com/bookread.php?book=473097 (Дата
обращения: 23.12.2014)
2.
Мацяшек, Л. А. Практическая программная инженерия на основе учебного
примера [Электронный ресурс] / Л. А. Мацяшек, Б. Л. Лионг ; пер. с англ. - 2-е изд.
(эл.). - М.: БИНОМ. Лаборатория знаний, 2012. Режим доступа:
http://znanium.com/bookread.php?book=477694 (Дата обращения: 23.12.2014)
3.
Приемы объектно-ориентированного проектирования: паттерны проектирования :
перевод с английского = Design Patterns: Elements of Reusable Object-Oriented
Software/ Э. Гамма [и др.]. - Санкт-Петербург: Питер, 2013. - 368 с.
12.2 Дополнительная литература:
15
1.
2.
3.
4.
Заботина, Н. Н. Проектирование информационных систем [Электронный ресурс]:
Учебное пособие / Н.Н. Заботина. - М.: НИЦ ИНФРА-М, 2014. Режим доступа:
http://znanium.com/bookread.php?book=454282 (Дата обращения: 23.12.2014)
Гагарина, Л. Г. Технология разработки программного обеспечения [Электронный
ресурс]: Учеб. пос. / Л.Г.Гагарина, Е.В.Кокорева, Б.Д.Виснадул; Под ред. проф.
Л.Г.Гагариной - М.: ИД ФОРУМ: НИЦ Инфра-М, 2013. Режим доступа:
http://znanium.com/bookread.php?book=389963 (Дата обращения: 23.12.2014)
Гвоздева, В. А. Информатика, автоматизированные информационные технологии
и системы [Электронный ресурс]: Учебник / В.А. Гвоздева. - М.: ИД ФОРУМ:
НИЦ
ИНФРА-М,
2015.
Режим
доступа:
http://znanium.com/bookread.php?book=492670 (Дата обращения: 23.12.2014)
Эванс, Э. Предметно-ориентированное проектирование: структуризация сложных
программных систем : пер. с англ. = Domain-Driven Design: tackling complexity in
the heard of software/ Э. Эванс. - Москва: Вильямс, 2012
12.3 Интернет-ресурсы:
1. Software Engineering Conference (Russia) 2005, 2006, 2007 http://www.secr.ru/
2. Перевод SWEBOK 2004 с замечаниями и комментариями, подготовленный Сергеем
Орликом при участии Юрия Булуя http://swebok.sorlik.ru/
3. Capability Maturity Model Integration (CMMI) http://cmmiinstitute.com/
13. Перечень информационных технологий, используемых при осуществлении
образовательного процесса по дисциплине (модулю), включая перечень программного
обеспечения и информационных справочных систем (при необходимости).
При выполнении практических работ, ведении лекций в качестве информационных
технологий используется программное обеспечение Microsoft Office, Software Ideas Modeler.
14. Технические средства и материально-техническое обеспечение дисциплины
(модуля).
Компьютерный класс с установленным программным обеспечением Microsoft Office,
Software Ideas Modeler и доступом в сеть Интернет, рекомендовано наличие проекционного
оборудования (проектор и проекционный экран). Для проведения лекционных занятий
требуется аудитория, оборудованная проектором и проекционным экраном, либо
интерактивной доской, либо whiteboard с набором маркеров.
15. Методические указания для обучающихся по освоению дисциплины (модуля).
Моделирование прецедентов
НАЗНАЧЕНИЕ РАБОТЫ
Сформировать у студентов представление о пользователях и функциях проектируемой
системы.
ЦЕЛЬ РАБОТЫ
В результате выполнения работы студенты должны научиться строить модель вариантов
использования (прецедентов), выявлять пользователей и функции системы, а также отражать
требования пользователей к системе, определять элементы модели и связи между ними:
• Actor
• Use Case
• Use-Case Package
ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ОТЧЕТА
Оформление отчета по лабораторной работе должно соответствовать шаблону, для
форматирования должны использоваться стандартные стили.
Отчет должен иметь следующую структуру:
• титульный лист;
16
• содержание;
• основная часть.
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ОТЧЕТА
Основная часть отчета должна содержать следующие разделы:
1) Графические диаграммы
2) Спецификация варианта использования (прецедента):
1.
НАЗВАНИЕ ПРЕЦЕДЕНТА
1.1
Краткое описание
Данное описание должно кратко отражать роль и назначение прецедента. Одного абзаца
должно быть достаточно.
2.
ПОТОКИ СОБЫТИЙ
2.1
Основной поток
Прецедент начинается тогда, когда актор начинает производить какие-либо действия.
Именно актор всегда инициирует прецеденты. Прецедент должен описывать, что делает
актор и что система делает в ответ. Описание должно быть сформулировано в форме диалога
между актором и системой.
Прецедент должен описывать что происходит внутри системы, но не как и не почему это
происходит. Если происходит обмен информацией, то должны быть указаны входные и
выходные данные. Например, будет недостаточно сказать, что актор вводит информацию о
клиенте; лучше сказать, что актор вводит имя и адрес клиента. При этом Глоссарий терминов
часто может оказаться полезным для управления сложностью прецедента. Вы можете также
определить здесь и информацию о клиенте, но помните, что не стоит перегружать прецедент
деталями.
Простые альтернативные потоки могут быть представлены прямо в тексте описания
прецедента. Если описание альтернативного потока занимает всего несколько предложений,
приведите его прямо в этом разделе. Если альтернативный поток более сложный,
используйте для его описания специальный раздел настоящего документа.
Порой рисунок «стоит тысячи слов», хотя полностью и не заменяет собой четкого, понятного
описания. Поэтому если необходимо, вставьте в описание прецедента графические
представления пользовательских интерфейсов, технологических маршрутов и т.д. Если блоксхема полезна для представления сложного процесса принятия решений, обязательно
используйте её! Подобным же образом диаграмма состояний отражает поведение системы
лучше, чем множество страниц текста. Используйте правильный способ представления
информации о вашей проблеме, но будьте осторожны при использовании терминологии,
графических нотаций и фигур, которые ваша аудитория может не понять. Помните, что ваша
цель не затуманить, а прояснить.
2.2
Альтернативные потоки
2.2.1 <Альтернативный поток 1>
Более сложные альтернативные потоки событий должны быть описаны в отдельном разделе,
ссылки на который содержатся в разделе с основным потоком. Каждый альтернативный
поток представляет собой сценарий некоторого альтернативного поведения. Таких потоков
может быть несколько – по числу исключительных ситуаций в основном потоке. Потоки
могут быть длинны настолько, насколько это необходимо для описания событий связанных с
альтернативным поведением. Когда альтернативный поток заканчивается, события
основного потока возобновляются до тех пор, пока не произойдёт другая исключительная
ситуация.
2.2.1.1 <Альтернативный подпоток>
В случае необходимости описание альтернативных потоков может быть разбито на
подразделы.
2.2.2 <Альтернативный поток 2>
Скорее всего, прецедент будет содержать несколько альтернативных потоков. Храните
описание каждого альтернативного потока отдельно. Использование альтернативных
17
потоков повышает читаемость прецедента, а также не допускает его декомпозицию в
иерархию прецедентов. Помните, что прецеденты – это всего лишь набор текстовых
спецификаций, главная цель которых ясно, кратко и понятно документировать поведение
системы.
3.
СПЕЦИАЛЬНЫЕ ТРЕБОВАНИЯ
Специальные требования – это типичные нефункциональные требования, характерные для
прецедента, которые не могут быть легко специфицированы в тексте потока событий.
Примером таких требований могут быть юридические и регулятивные требования,
применяемые стандарты, а также параметры качества создаваемой системы, включая
практичность, надежность, производительность и поддержку. Здесь могут быть приведены и
прочие требования, например: требования к операционным системам и окружению,
требования к совместимости, ограничения проектирования.
3.1
<Специальное требование 1>
4.
ПРЕДУСЛОВИЯ
Предусловие (прецедента) – это состояние, в котором должна находиться система перед
началом выполнения прецедента.
4.1
<Предусловие 1>
5.
ПОСТУСЛОВИЯ
Постусловие (прецедента) – это список состояний, в котором может оказаться система сразу
после завершения прецедента.
5.1
<Постусловие 1>
6.
ТОЧКИ РАСШИРЕНИЯ
Точки расширения прецедента.
6.1
<Название точки расширения 1>
Определение позиции точки расширения в потоке событий.
ПРИМЕР
Мобильный телефон
Позвонит ь
<<extend>>
System
Организоват ь
конференц-связь
Сот овая
сет ь
Использоват ь
т елефонную
книгу
Пользоват ель
Принят ь
звонок
<<extend>>
Принят ь
д ополнит ельный
звонок
Рисунок 3 – Пример диаграммы прецедентов
Моделирование деятельности
НАЗНАЧЕНИЕ РАБОТЫ
Сформировать у студентов представление о выполнении вариантов использования
(прецедентов).
18
ЦЕЛЬ РАБОТЫ
В результате выполнения работы студенты должны научиться выявлять узкие места в работе
вариантов использования (прецедентов), определять процессы в системе (внутренние или
внешние), которые можно усовершенствовать, получать информацию по требованиям
конкретного варианта использования (прецедента), определять элементы модели и связи
между ними:
• Activity states
• Transitions
• Decisions
• Alternative threads
• Synchronization bars
• Guard conditions
• Concurrent threads
ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ОТЧЕТА
Оформление отчета по проделанной работе должно соответствовать шаблону, для
форматирования должны использоваться стандартные стили.
Отчет должен иметь следующую структуру:
• титульный лист;
• содержание;
• основная часть.
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ОТЧЕТА
Основная часть отчета должна содержать следующие разделы:
1) Графические диаграммы
2) Документ «Архитектура программного обеспечения»:
1.
ВВЕДЕНИЕ
Введение представляет собой обзор содержимого данного документа. Оно включает в себя:
•
цели создания документа;
•
область применения;
•
используемые в тексте определения, сокращений и аббревиатуры;
•
ссылки на другие документы или иные источники информации;
•
сведения об организации настоящего документа.
1.1
Цели
Определите цель создания настоящего документа.
1.2
Область применения
Краткое определение области применения данного документа; список проектов, связанных с
ним, и всё остальное, на что оказывает влияние данный документ.
1.3
Определения, сокращения и аббревиатуры
Данный подраздел содержит определения всех терминов, сокращений и аббревиатур,
необходимых для правильной интерпретации документа. Эта информация может быть
представлена в виде ссылок на статьи Глоссария проекта.
1.4
Ссылки
Данный подраздел содержит полный перечень всех документов, на которые содержится
ссылка в данном документе. Для каждого документа указывается название, номер
публикации (если это необходимо), дата и организация-издатель. Укажите источники, из
которых были получены данные ссылки. Эта информация может быть представлена ссылкой
на приложение или другой документ.
1.5
Общие сведения
В данном подразделе даётся краткое описание содержимого настоящего документа,
объясняется его организация.
2.
ПРЕДСТАВЛЕНИЕ АРХИТЕКТУРЫ
19
Этот раздел описывает программную архитектуру текущей системы и способ ее
представления. Необходимы прецедентное, логическое, процессное, а также представления
развертывания и выполнения с описание для каждого представления.
3.
АРХИТЕКТУРНЫЕ ЦЕЛИ И ОГРАНИЧЕНИЯ
Этот раздел описывает цели и требования к программному обеспечению, которые оказывают
существенное
влияние
на
архитектуру;
например,
безопасность,
защита,
конфиденциальность, использование готовых продуктов, мобильность, распределенность, а
также повторное использование. В этом разделе также фиксируются специальные
ограничения: стратегии проектирования и разработки, средства разработки, структура
команды, расписание, существующий код и так далее.
4.
ПРЕЦЕДЕНТНОЕ ПРЕДСТАВЛЕНИЕ
В этом разделе перечисляются прецеденты или сценарии модели прецедентов, если они
представляют существенные, функциональные возможности системы, если же они
представляют несколько архитектурных элементов, то необходимо разделять на отдельные
пункты.
5.
ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ
Этот раздел описывает архитектурно важные части проекта, такие как декомпозиция
подсистем и пакетов. Для каждого существенного пакета – декомпозицию классов и
компонентов. Необходимо также выделить существенные архитектурные классы и описать
их цели, важные отношения, операции и атрибуты.
5.1
Краткий обзор
Этот подраздел описывает полную декомпозицию модели проектирования в теминах
иерархии пакетов и уровней.
5.2
Архитектурно-значимые пакеты модели проектирования
Для каждого существенного пакета, включайте подраздел с его названием, его кратким
описанием, и диаграммой со всеми существенными классами и пакетами, содержавшимися в
пределах пакета.
Для каждого существенного класса в пакете, включайте его название, краткое описание, и,
возможно, описание его основных целей, операций, и атрибутов.
5.3
Реализации прецедента
Этот раздел описывает, как фактически работает программное обеспечение, давая описание
реализации выбранным прецедентам (или сценариям), и объясняет, как различные элементы
модели дизайна способствуют их функциональным возможностям.
6.
ПРОЦЕССНОЕ ПРЕДСТАВЛЕНИЕ
Этот раздел описывает декомпозицию системы на элементарные процессы (единственные
потоки управления) и составные процессы (группировки элементарных процессов).
Организуйте раздел группами взаимодействующих процессов. Опишите основные режимы
коммуникации между процессами, такими как передача сообщений, прерывания, и
взаимодействие между параллельными процессами.
7.
ПРЕДСТАВЛЕНИЕ РАЗВЕРТЫВАНИЯ
Этот раздел описывает одну или более физических сетевых (аппаратных) конфигураций, на
которых программное обеспечение развернуто и выполняется. Это - представление Модели
Развертывания. Как минимум для каждой конфигурации необходимо указать физические
узлы (компьютеры, центральные процессоры), на которых выполняется программное
обеспечение и их соединения (шина, локальная сеть, point-to-point, и так далее). Также
включайте отображение процессов процессного представления на физические узлы.
8.
ПРЕДСТАВЛЕНИЕ РЕАЛИЗАЦИИ
Этот раздел описывает полную структуру модели реализации, декомпозицию программного
обеспечения на уровни и подсистемы в модели реализации, а также любых архитектурносущественные компоненты.
8.1
Краткий обзор
20
Этот подраздел называет и определяет различные уровни и их информационное наполнение,
правила, которые управляют включением в данный уровень, и границами между уровнями.
Включайте диаграмму компонентов, которая показывает отношениям между уровнями.
8.2
Уровни
Для каждого уровня, включайте подраздел с его названием, перечислением подсистем,
расположенных в уровне, и диаграмму компонентов.
9.
ПРЕДСТАВЛЕНИЕ ДАННЫХ (ДОПОЛНИТЕЛЬНО)
Описание постоянного хранилища данных системы. Этот раздел является дополнительным,
если хранимые данные небольшие или отсутствуют, или отличия между моделью
проектирования и моделью данных минимальны.
10.
РАЗМЕР И ПРОИЗВОДИТЕЛЬНОСТЬ
Описание главных характеристик размеров программного обеспечения, которые
воздействуют на архитектуру, а так же целевые ограничения производительности.
11.
КАЧЕСТВО
Описание того, как программная архитектура способствует всем возможностям (кроме
функциональных возможностей) системы: расширяемость, надежность, мобильность, и так
далее. Если у этих характеристик есть специальное значение, такое как безопасность, защита
или конфиденциальность, они должны быть четко очерчены.
ПРИМЕР
Отдел обслуживания клиентов
Отдел продаж
Склад
Заказать
товар
Обработать
заказ
Подобрать
товар
Отгрузить
товар
Получить
заказ
Выставить
счет клиенту
Оплатить
счет
Закрыть
заказ
Рисунок 4 – Пример диаграммы деятельности
Моделирование реализации
НАЗНАЧЕНИЕ РАБОТЫ
Сформировать у студентов представление о концептуальных сущностях системы.
21
ЦЕЛЬ РАБОТЫ
В результате выполнения работы студенты должны научиться выявлять группы объектов с
общими свойствами (атрибутами), поведением (операциями), отношениями с другими
объектами и семантикой.
ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ОТЧЕТА
Оформление отчета по лабораторной работе должно соответствовать шаблону, для
форматирования должны использоваться стандартные стили.
Отчет должен иметь следующую структуру:
• титульный лист;
• содержание;
• основная часть.
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ОТЧЕТА
Основная часть отчета должна содержать следующие разделы:
1) Графические диаграммы
2) Описание построенных диаграмм включается в соответствующий раздел отчета
предыдущей лабораторной работы.
ПРИМЕР
Window
iForm
-Height
-Width
+open()
+close()
+move()
+handleEvent()
ConsoleWindow
Event
DialogBox
Control
Рисунок 5 – Пример диаграммы классов
Моделирование последовательностей
НАЗНАЧЕНИЕ РАБОТЫ
Сформировать у студентов представление о реализациях вариантов использования
(прецедентов) в логическом представлении системы.
ЦЕЛЬ РАБОТЫ
В результате выполнения работы студенты должны научиться выявлять объекты и классы,
используемые в сценарии, и последовательность сообщений, которыми обмениваются
объекты для выполнения сценария.
ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ОТЧЕТА
Оформление отчета по выполненной работе должно соответствовать шаблону, для
форматирования должны использоваться стандартные стили.
Отчет должен иметь следующую структуру:
• титульный лист;
• содержание;
• основная часть.
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ОТЧЕТА
Основная часть отчета должна содержать следующие разделы:
1) Графические диаграммы
2) Описание построенных диаграмм включается в соответствующий раздел отчета
предыдущей работы.
22
ПРИМЕР
Client
Database
create()
Transaction
setActions(a,d,o)
setValues(d, 3.4)
setValues(a, "hello")
(commited)
destroy()
Рисунок 6 – Пример диаграммы последовательности
23