Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии разработки ПО. Лабораторный практикум
.pdf
Окончание табл. 2.3
Язык программирования SLOC / FP
HTML 34
Java 53
JavaScript 47
Perl 24
SQL 21
Visual Basic 42
VB.NET 52
Оценку срока (T′) и стоимости (C′) разработки кода можно
получить по формулам:
T′ = SLOC′ / PP,
C′ = SLOC′ ⋅ С
уд
,
где PP – производительность работы программиста;
– удельная стоимость.
С
уд
2.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Определить границы приложения и выделить функцио-
нальные элементы.
3. Подсчитать элементы данных и определить ранги функ-
циональных элементов.
4. Рассчитать количество функциональных указателей.
5. Оценить размер программы, сроки и стоимость ее разработки, взяв значения производительности и удельной стоимости из результатов выполнения лабораторной работы № 1.
6. Заполнить табл. 2.4 результатами расчетов и оформить
отчет о выполнении работы.
Таблица 2.4
Название параметра Обозначение Значение
Число функциональных указателей FP
Оценка размера программы SLOC′
Оценка сроков разработки T′
Оценка стоимости разработки C′
21
2.4. Пример выполнения расчетов
Произведем оценку программы «Студенческий офис», функ-
циональными требованиями к которой являются:
– ввод, хранение и вывод данных о студентах (ФИО, пол,
дата рождения, группа, размер стипендии);
– ввод преподавателями ведомостей с оценками;
– хранение и вывод оценок студентов по дисциплинам, вы-
вод среднего балла индивидуально и по группе;
– взаимодействие с бухгалтерской программой для переда-
чи сведений об успеваемости и получения размера стипендии.
2.4.1. Определение границ приложения
и выделение функциональных элементов
Исходя из требований к программе, можно выделить сле-
дующие внешние по отношению к программе сущности:
– пользователь «сотрудник студенческого офиса»;
– пользователь «преподаватель»;
– внешняя программа «бухгалтерия».
Граница приложения будет проходить по графическому интерфейсу взаимодействия с пользователями и программному
интерфейсу взаимодействия с внешней программой (рис. 2.2).
Рис. 2.2. Функциональные элементы программы
«Студенческий офис»
Различимы следующие файлы:
– внутренние логические файлы «студенты», «группы»,
«оценки»;
22
– внешний интерфейсный файл «стипендии».
Различимы следующие транзакции:
– внешние вводы «данные студента» и «ведомости»;
– внешний вывод «успеваемость»;
– внешние запросы «карточка студента», «карточка груп-
пы», «запрос стипендии».
2.4.2. Подсчет элементов данных
и определение рангов функциональных
элементов
Различимыми элементами данных во внутреннем логическом файле «студенты» являются: «идентификатор студента»,
«фамилия», «имя», «отчество», «пол», «дата рождения», «размер стипендии». Эти данные можно логически разделить на две
группы: «персональные данные» и «финансовая информация».
Таким образом, файл «студенты» имеет 7 элементов данных
и 2 записи. Согласно табл. 2.1, такой файл имеет низкий ранг.
Различимыми элементами данных во внутреннем логическом файле «группы» являются: «идентификатор группы»,
«название группы», «идентификатор студента». Все элементы
являются частью одной записи. Таким образом, файл «группы» имеет низкий ранг.
В файле «оценки» различимы элементы данных: «идентификатор записи», «идентификатор студента», «дисциплина»,
«дата», «балл», образующие одну запись. Ранг файла – низкий.
Во внешнем интерфейсном файле «стипендии» различимы
элементы данных: «минимальный балл», «величина стипендии», образующие одну запись. Ранг файла – низкий.
Внешний ввод «данные студента» оперирует элементами
данных: «идентификатор студента», «фамилия», «имя», «отчество», «пол», «дата рождения», «идентификатор группы»,
«название группы» и ссылается на два внутренних логических
файла: «студенты» и «группы». Имеем восемь элементов данных и две ссылки на файлы. Ранг внешнего ввода «данные студента» по табл. 2.1 – средний.
Внешний ввод «ведомости» оперирует четырьмя элементами данных: «идентификатор студента», «дисциплина», «дата»,
23
«балл» и изменяет один внутренний логический файл «оценки». Ранг – низкий.
Внешний вывод «успеваемость» затрагивает три внутренних
логических файла: «студенты», «группы» и «оценки» и оперирует семью элементами данных: «идентификатор студента»,
«фамилия», «имя», «идентификатор группы», «название группы», «балл по дисциплине», «средний балл». Ранг – средний.
Внешний запрос «карточка студента» выводит все данные,
связанные со студентом, его успеваемостью и стипендией из
трех внутренних логических файлов. Ранг – средний.
Ранг внешних запросов «карточка группы» и «запрос стипендии» – низкий.
2.4.3. Расчет количества функциональных
указателей
По табл. 2.2 определяем весовые коэффициенты функцио-
нальных элементов и сводим результаты в табл. 2.5.
Таблица 2.5
Функциональный элемент Тип элемента Ранг Весовой коэффициент
«Студенты» ILF Низкий 7
«Группы» ILF Низкий 7
«Оценки» ILF Низкий 7
«Стипендии» EIF Низкий 5
«Данные студента» EI Средний 4
«Ведомости» EI Низкий 3
«Успеваемость» EO Средний 5
«Карточка студента» EQ Средний 4
«Карточка группы» EQ Низкий 3
«Запрос стипендии» EQ Низкий 3
Сумма транзакций и файлов с учетом весовых коэффици-
ентов
S = 7 ⋅ 3 + 5 ⋅ 2 + 4 ⋅ 2 + 3 ⋅ 3 = 48.
Из таблиц П1.1–П1.14 в прил. 1 выбираем те системные
параметры, влияние которых оценивается выше нуля баллов
и заполняем табл. 2.6.
24
Таблица 2.6
14
1
0,65 0,01 32,16.
i
i
FP S F
=
=⋅ +⋅ =
∑
Системный параметр Оценка Обоснование
Передача данных 1 Требуется обмен данными с бухгалтерией
Эффективность работы
конечного пользователя
1 Подразумевается наличие меню и бумаж-
ной версии пользовательской документации
Определим итоговое количество функциональных указате-
лей:
Оценочный размер программы на языке C#, с учетом коэф-
фициента из табл. 2.3.
SLOC′ = 32,16 ⋅ 54 = 1737 строк.
Для оценки срока и стоимости разработки воспользуемся
значениями производительности и удельной стоимости, полученными в примере к лабораторной работе № 1:
T′ = SLOC′ / PP = 1737 / 56 = 31 ч,
C′ = SLOC′ ⋅ С
2.5. Вопросы для самоконтроля
1. В чем различие функциональных элементов «внешний
вывод» и «внешний запрос»?
2. Где по отношению к границе программы находится вну-
тренний логический файл?
3. Где по отношению к границе программы находится внеш-
ний интерфейсный файл?
4. Как связаны количество функциональных указателей и
количество строк кода?
5. Чем определяется ранг сложности функционального эле-
мента?
= 1737 ⋅ 17,86 = 31 023 руб.
уд
25
Лабораторная работа № 3
«РАЗРАБОТКА ГРАФИЧЕСКИХ
СПЕЦИФИКАЦИЙ»
3.1. Цель работы
Получение практических навыков в оформлении спецификаций этапа анализа требований.
3.2. Теоретический минимум
Анализ требований к разрабатываемому программному
обеспечению завершается разработкой спецификаций – формализованного описания функций и ограничений программы,
отвечающего требованиям полноты и точности.
Под полнотой подразумевается описание всех существенных
для данной стадии проектирования функций и ограничений.
Под точностью подразумевается описание спецификаций
в форме, исключающей неоднозначную трактовку.
Обеспечить соблюдение перечисленных требований позволяет только строго формализованная модель программного обеспечения. В зависимости от подхода к разработке могут быть
использованы различные модели и нотации.
В данной работе рассмотрены следующие виды диаграмм: ва-
риантов использования, переходов состояний, потоков данных.
3.2.1. Диаграмма вариантов использования
Диаграмма вариантов использования (диаграмма прецедентов, Use Case diagram) предназначена для определения
функциональных требований и позволяет наглядно описать
предоставляемые программой сервисы. Основные элементы
диаграммы приведены на рис. 3.1:
а) действующее лицо (actor) – внешняя по отношению к
программе сущность, взаимодействующая с программой, или
использующая ее сервисы;
б) вариант использования (прецедент, Use Case) – очевидная для действующего лица процедура, решающая конкретную
задачу;
26
в) связь (ассоциация, association) – взаимодействие действующего лица с вариантом использования;
г) расширение (extend) – добавление альтернативного функционала в основной вариант использования;
д) включение (include) – задействование функционала как
неотъемлемой части основного варианта использования;
е) наследование (generalization) – копирование потомком
всех атрибутов и поведения предка.
Рис. 3.1. Элементы диаграммы вариантов использования
3.2.2. Диаграмма переходов состояний
Диаграмма переходов состояний (UML state machine) – графическая модель, описывающая возможные состояния программы и переходы из одного состояния в другое.
Для построения диаграмм используются условные обозначения, показанные на рис. 3.2:
а) начальное псевдосостояние (initial pseudostate) – точка
старта (может быть только одна);
б) конечное состояние (final state) – точка завершения (может быть несколько или ни одной);
в) простое состояние (simple state) – состояние, не имею-
щее регионов и вложенных состояний (может иметь внутренние действия);
г) составное состояние (composite state) – состояние, имеющее один или более регионов со вложенными состояниями;
д) переход (transition) – направленная связь между двумя
состояниями, может содержать необязательные элементы:
– триггеры – перечень событий, приводящих к переходу,
– охранное выражение – логическое условие, разрешающее
переход,
27
– действия – операции, совершаемые при переходе;
е) выбор (choice) – псевдосостояние, реализующее услов-
ный переход.
Рис. 3.2. Элементы диаграммы переходов состояний
3.2.3. Диаграмма потоков данных
Диаграмма потоков данных (data flow diagram) – графическая модель системы, описывающая хранение, обработку и
передачу данных.
Для построения диаграмм используются условные обозначения, показанные на рис. 3.3:
а) внешняя сущность (external entity) – объект, не входящий в систему, но являющийся источником и (или) получателем ее данных;
б) процесс (process) – функция обработки данных;
в) хранилище (data storage) – внутреннее хранилище данных в системе;
г) поток (data flow) – направленное движение данных.
Рис. 3.3. Элементы диаграммы потоков данных
Чтобы сделать диаграмму более читаемой, ее разбивают на
несколько уровней. Самым верхним в иерархии уровней является контекстный (нулевой), на котором отражены программа
(одним процессом), внешние сущности и потоки данных между
ними. На следующем (первом) уровне программа декомпозиру-
28
ется на несколько процессов, появляются внутренние потоки
и хранилища данных. На втором уровне процессы могут разбиваться на подпроцессы и т.д., до тех пор, пока не будет достигнут требуемый уровень детализации. Процедуры контекстного
уровня имеют номера 1, 2, 3 и т.д. Процедуры первого уровня
имеют номера, производные от процедур нулевого, например:
1.1, 1.2, 2.1, 2.2, 2.3. Процедуры второго уровня – производные
от первого, например: 1.1.1, 2.3.5, и т.д.
3.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Определить внешние сущности, состояния программы,
выполняемые ею функции и данные, которые она обрабатывает.
3. Построить диаграмму вариантов использования.
4. Построить диаграмму переходов состояний.
5. Построить диаграмму потоков данных.
6. Оформить отчет о выполненной работе.
3.4. Пример выполнения работы
Построение диаграмм рассмотрим на примере программы
клиента корпоративной почты, требования к которой описаны
заказчиком следующим образом:
«Сотрудники организации должны иметь возможность
отправлять друг другу письма, прикреплять документы и
вставлять фотографии. Руководители подразделений могут
делать массовые рассылки в пределах подразделения».
3.4.1. Построение диаграммы вариантов
использования
Действующими лицами являются: «сотрудник» и «руководитель». «Руководитель» имеет доступ ко всем сервисам «сотрудника», а также к дополнительному сервису «массовая рассылка», поэтому он является наследником действующего лица
«сотрудник».
Вариантами использования являются: «проверка почты»,
«чтение письма», «отправка письма», «массовая рассылка».
29
Поскольку почтовая программа должна различать пользователей, добавляется вариант «авторизация».
Вложение документа и вставка фотографии – это дополнительный функционал отправки, поэтому оформляются как
вспомогательные варианты использования со связью «расширение».
Чтение писем включает проверку почты, а массовая рассылка – отправку писем, поэтому между этими вариантами
устанавливается связь «включение».
Результат построения диаграммы приведен на рис. 3.4.
Рис. 3.4. Диаграмма вариантов использования для почтовой
программы
3.4.2. Построение диаграммы переходов
состояний
Различимые пользователем состояния, в которых может на-
ходиться программа начиная с момента ее запуска: «авториза-
30
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]