Содержание
1.1 Введение4
1.2 Основания для разработки4
1.3 Назначение разработки4
1.4 Требования к программе или программному изделию4
1.4.1 Требования к функциональным характеристикам4
1.4.2 Требования к надежности4
1.4.3 Условия эксплуатации4
1.4.4 Требования к составу и параметрам технических средств4
1.4.5 Требования к информационной и программной совместимости4
1.5 Требования к программной документации4
1.6 Технико-экономические показатели4
1.7 Стадии и этапы разработки4
2 СОГЛАШЕНИЕ О ТРЕБОВАНИЯХ4
2.1 Описание программного изделия4
2.1.1 Наименования и шифры изделия4
2.1.2 Краткое описание изделия4
2.1.3 Сведения об авторском праве4
2.1.4 Результирующие компоненты изделия4
2.2 Цели4
2.2.1 Согласование заявок на проверку4
2.2.3 Согласование заявок на внесение исправлений4
2.2.4 Согласование планов4
2.2.5 Требования заказчика4
2.2.6 Рассмотренные альтернативы4
2.6.7 Окупаемость капиталовложений4
2.3 Стратегия4
2.3.1 Стратегия относительно предоставляемого материала4
2.3.2 Генерируемое программное обеспечение4
2.3.3 Системное программное обеспечение4
2.4 Используемые материалы4
2.4.1 Справочные документы4
2.5 Передача заказчику и ввод в действие4
2.5.1 Средства защиты прав собственности на изделие4
2.5.2 Ресурсы, обеспечивающие ввод в действие4
2.5.3 Носители информации4
2.6 Тактика4
2.6.1 Взаимосвязи4
2.6.2 Техническая ревизионная комиссия4
2.6.3 Проверка изделия4
2.6.3.1 Уровни испытаний4
2.6.4 Обеспечение поддержки4
3 СПЕЦИФИКАЦИИ4
3.1 Внешние спецификации4
3.2 Внутренние спецификации4
4 ТЕСТИРОВАНИЕ4
4.1 Обоснование уровня испытаний4
4.1.1 Чтение записей из файла и составление списка4
4.1.2 Добавление записи4
4.1.3 Правка полей записи, находящейся под курсором4
4.1.4 Поиск записи по ключу4
4.2 Классы эквивалентности4
4.3 Тесты4
4.3.1Тест для правильных классов эквивалентности4
4.3.2 Тесты для неправильных классов эквивалентности4
4.3.3 Результаты тестирования4
5 РУКОВОДСТВО СИСТЕМНОГО ПРОГРАММИСТА4
5.1 Общие сведения о программе4
5.2 Структура программы4
5.3 Настройка программы4
5.3.1 Установка программы4
5.3.2 Настройка программы4
5.4 Проверка программы4
5.5 Дополнительные возможности4
5.6 Сообщения системному программисту4
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ:4
Выдержка из текста работы
В нынешний век высоких технологий, наука и техника проникли практически во все аспекты современной жизни. В связи с быстрым темпом жизни в современном обществе стоит проблема распределением человеком времени для повышения своей результативности. Чтобы решить эту проблему нужно грамотно распределять свое время.
Для контроля и грамотного распределения времени лучше всего помогают часы-будильник, так как проблема нехватки времени касается всех без исключения начиная от студентов заканчивая всевозможными директорами банков и других крупных предприятий, актуальность разработки программного обеспечения будильника стоит остро и не вызывает сомнений.
Практическая ценность. Создание программы часы-будильник решает следующие задачи:
· Помогает встать по утрам не пропустив работу/учебу
· Напоминает о важных, запланированных на сегодня, мероприятиях
· Составляет четкий распорядок дня
В данной курсовой работе представлен пример объектно-ориентированной разработки программного обеспечения на основе проектирования в case-средстве Rational Rose, используя ее возможности для построения UML-диаграмм, анализа, моделирования и преобразования моделей и генерации кода.
Исходными данными для выполнения курсовой работы является постановка задачи, приведенная в пункте 2, результатом являются диаграммы вариантов использования, классов, состояний, деятельности, последовательностей, коопераций, компонентов и размещения, а так же сгенерированный код.
Функциональность объекта изначально ограничена, но полученные материалы могут быть использованы для программирования реально существующего объекта, то есть, данный способ разработки имеет практическую ценность.
Для достижения поставленной задачи требуется решить ряд конкретизирующих её задач:
? Выявить основные тенденции развития и особенности объектно-ориентированного программирования и проектирования;
? Выделить основные функции системы, объекты, взаимодействующие с ними, и реакции системы на действия этих объектов;
? Проанализировать основные компоненты системы и составить их подробное описание
? На основе полученных данных осуществить проектирование системы при помощи диаграмм на языке UML.
? Составить инструкцию пользователя для того, чтобы обеспечить легкость внедрения её в структуру предприятия и упростить обучение сотрудников работе в данной программе.
В качестве объекта исследования выбраны часы-будильник — в данной работе — это готовая автоматизированная информационная система предназначенная для помощи распределения времени.
1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ
1.1 Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника
Основные принципы и концепции объектной модели в программировании развивались в процессе эволюции множества разных объектных и объектно-ориентированных языков.
Основной идеей объектного подхода является объединение данных и производимых над этими данными операций в одно концептуально замкнутое понятие — класс. Данные класса не должны изменяться извне его, доступ к данным стоит осуществлять только через функции-члены (методы класса).
Класс — группировка объектов, которые имеют те же самые свойства, общее поведение и одинаковые отношения.
Класс определяет характеристики объектов. Однако значения могут быть назначены только после того, как объект будет создан. Только в этом случае появляется фактический образец объекта.
Объект — понятие или вещь с определенными границами, которая является уместной в данной проблеме, с которой мы имеем дело. Объекты позволяют выполнить две цели:
1.Они помогают понимать окружающий мир.
2. Они обеспечивают практическую реализацию для создаваемого нами приложения.
Программа, написанная на объектном языке, представляет собой совокупность объектов, каждый из которых принадлежит к определенному абстрактному типу данных (классу) и имеет интерфейс в виде набора методов для взаимодействия друг с другом (посылки сообщений).
Все объектно-ориентированные языки разбивают программу на части, многократно используемые и расширяемые. Программы представляют собой объекты многократного использования. Эти объекты могут группироваться различными способами, формируя новые программы.
Объектно-ориентированное проектирование — это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.
Объектно-ориентированное проектирование дает возможность создавать расширяемые системы (extensible systems). Расширяемость (extensibility) означает, что существующую систему можно заставить работать с новыми компонентами без внесения в нее каких-либо изменений. . Это уникальное и очень мощное понятие, потому что реальная задача постоянно требует изменений. Это уникальное и очень мощное понятие, потому что реальная задача постоянно требует изменений.
Таким образом, чтобы составить корректную оценку объектно-ориентированной модели программного обеспечения, следует обратиться к описанию объекта исследования, или, иными словами, к постановке задачи, в которой описаны необходимые для реализации функции и устройство банкомата, для которого проектируется информационная система.
Будильник — это программа позволяющая создать задачи и вызов звукового сигнала, если достигло определенное время.
Будильник подключен к базе данных компьютера, где хранятся все задачи когда-либо созданные пользователем.
В проектируемой системе используются названия предметов или явлений, имеющих определенное конкретное значение в контексте рассматриваемого объекта — банкомата. В таблице 1 приведены встречающиеся в работе термины, для облегчения понимания структуры программного обеспечения.
Таблица 1 — Основные понятия в программном обеспечении банкомата (глоссарий)
|
Пользователь |
Любой человек, который пользуется будильником. |
|
|
Задача |
То, что нужно сделать. |
|
|
Звуковой сигнал |
Выбор соответствующего звукового сигнала при достижении определенного времени. |
|
|
База данных |
База со всеми задачами и времени их срабатывания. |
|
|
Часы |
Обыкновенные часы для просмотра текущего времени. |
1.2 Исследование модели программного обеспечения будильника
Модель вариантов использования представляет собой модель взаимодействия пользователей для решения проблем и задач.
Модель вариантов использования описывает цели пользователей, взаимодействие между пользователями и системой и требуемое поведение системы для удовлетворения этих целей.
Модель вариантов использования состоит из ряда модельных элементов (или графических примитивов). К наиболее важным из них относятся варианты использования [use cases], действующие лица или акторы [actors] и отношения (связи) между ними [relationships].
Для того, чтобы описать то, как может использоваться данная проектируемая система, необходимо выявить действующие лица — то есть, все объекты, которые будут взаимодействовать с системой. В данном случае, выделяется один объект и рассматривается его поведение в системе.
Действующее лицо:
Пользователь — Любой человек, пользующееся программным обеспечением будильника.
Варианты использования:
Исходя из потребностей пользователя, выделяются следующие варианты использования:
? Выбор мелодии.
? Выбор даты/времени.
? Просмотр предедущих заданий.
Рисунок 1 — Диаграмма вариантов использования
2. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ БУДИЛЬНИКА
2.1 Проектирование компонентов программного обеспечения будильника
Для того чтобы начать выполнение проектирования системы с точки зрения программного обеспечения, необходимо выделить те компоненты системы, которые будут являться ее «каркасом» — классы и их спецификации.
Описание классов данной информационной системы (иерархия системы приведена в приложении А):
Граничные классы (Boundary) — классы, которые расположены на границе системы и всей окружающей среды. К ним относятся все обработчики взаимодействий пользователя с системой. В программном обеспечении будильника такими классами являются:
? Каталог Мелодий(Catalog) — Граничный класс, обрабатывающий запросы на просмотр перечня мелодий, то есть непосредственно реагирующий на действия пользователя.
? Дата (Data) — Класс, содержащий календарь для выбора даты выполнения задачи.
Классы сущности (Entity) — содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных.
1.Задача
Атрибуты:
Id — Идентификационный номер задачи.
Name — Имя задачи
Melody — Название мелодии сигнала.
Data — Дата/время срабатывания
Операции:
Create() — Создать задачу
Рисунок 2 — Класс Task
2. Мелодия
Атрибуты:
Id — Идентификационный номер песни
Name — Название песни.
Time — Длительность
Операции:
Search() — Поиск песни в базе.
Select() — Выбрать песню
Рисунок 3 — Класс Melody
3. Дата
Атрибуты:
Data — Выбор нужной даты.
Time — Назначение времени.
Операции:
Select() — Продолжить.
Рисунок 4 — Класс Trade
4. База данных
Атрибуты:
Data — Дата интересующего запроса
Name — Имя запроса
Операции:
Search() — Поиск
Listen() — Просмотр
Рисунок 5 — Класс Database
2.2 Диаграммы и генерация кода программного обеспечения будильника
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят от времени. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами.
Рисунок 6 — Диаграмма классов
Диаграмма состояний (Statechart Diagram)
Определение состояний для классов моделируется с помощью диаграмм состояний. Главное назначение диаграммы состояний — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение моделируемой системы в течение всего ее жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Рисунок 7 — Диаграмма состояний
Диаграмма деятельности (Activity diagram)
Диаграмма деятельности — это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ.
При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций.
Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние выполняется только при завершении этой операции.
Рисунок 8 — Диаграмма деятельности
Диаграмма последовательностей (Sequence diagram)
На диаграмме последовательности изображаются только те объекты, которые непосредственно участвуют во взаимодействии. Ключевым моментом для диаграмм последовательности является динамика взаимодействия объектов во времени.
В UML диаграмма последовательности имеет как бы два измерения. Первое слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия. Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый очередностью или степенью активности объектов при взаимодействии друг с другом.
Рисунок 9 — Диаграмма последовательностей
Диаграмма коопераций (Collaboration diagram)
Особенность диаграммы кооперации в том что возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. На этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров.
Рисунок 10 — Диаграмма коопераций
Диаграмма компонентов (Component Diagram)
Диаграмма компонентов служит частью физического представления модели, играет важную роль в процессе ООАП и является необходимой для генерации программного кода. К каждому компоненту присоединяются соответствующие классы, которые впоследствии будут описаны в отдельных сгенерированных файлах.
Рисунок 11 — Диаграмма компонентов
Диаграмма размещения (Deployment Diagram)
Диаграмма размещения является второй составной частью физического представления модели и разрабатывается, как правило, для территориально распределенных систем. В данной схеме представлен торговый автомат, обращающийся через сеть к серверу банка. Несмотря на то, что под «сетью» имеется в виду защищенный канал связи, в контексте данной диаграммы это не указывается; она служит для предоставления общего вида работы системы.
Рисунок 12 — Диаграмма размещения
После построения всех диаграмм можно приступить к генерации кода — шаблону классов, их атрибутов и методов на выбранном языке.
Процесс генерации кода состоит из четырех основных шагов:
1. Проверка корректности модели.
Выполняется при помощи Tools > Check Model; в данной модели ошибок не обнаружено.
2. Установка свойств генерации кода.
Для всех компонентов выбирается язык C++, с помощью команды Assign назначаются классы.
3. Выбор класса, компонента или пакета.
4. Генерация кода.
Сгенерированный код приведен в приложении А.
ЗАКЛЮЧЕНИЕ
В рамках курсового проекта было проведено проектирование системы по методологии UML с использованием программы Rational Rose, и была построена модель программного обеспечения для будильника с использованием диаграмм и с генерацией конечного кода.
В ходе работы было создано восемь диаграмм, описывающих функции, объекты, классы и отношениями между ними, возможные исключения в работе, все возможные состояния и физическое размещение системы. Таким образом, данная информационная система была описана максимально точно и развернуто — то есть, достигнут конечный результат проектирования.
Конечным этапом работы стала генерация программного кода при помощи средств Rational Rose. Было сгенерировано два файла, содержащие в себе структуру программного обеспечения будильника — классы, операции и атрибуты. Такая возможность позволяет значительно упростить процесс разработки программного обеспечения, разделив его на две части: проектирование и программирование. Наличие такого шаблона, предоставленного вместе с диаграммами, позволяет программисту приступить к программированию операций без необходимости обоснования размещения их в определенном классе.
Таким образом, все поставленные задачи были выполнены, и достигнута цель работы. Проектирование системы и последующая генерация кода прошли успешно, все аспекты работы программного обеспечения будильника рассмотрены, проблема построения программного обеспечения изучена.
код диаграмма генерация будильник
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Боггс У. UML и Rational Rose . Пер. с англ. — М.: Лори, 2010. — 266с.
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-еизд.: Пер. с англ. — М.: Издательство Бином, СПб.: Невский диалект, 2008. — 332с.
3. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем.: Интернет-издание — адрес сайта: http://case-tech.h1.ru/library/vendrov/index.htm
4. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. «СУБД», 2009, №3.
5. Избачков Ю. С., Петров В. Н. Информационные системы: учебник для вузов / ООО Питер Принт СПб, 2010 г.
6. Приемы объектно-ориентированного проектирования. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж.: Пер. с англ. — М.: ДМК, 2008. — 354с.
7. Леоненков А.В. Визуальное моделирование в среде IBM Rational Rose 2003: Электронное пособие, 2008.
Приложение А
Приложение Б
Сгенерированный код
Файл Task.cpp
#include «Administrator.h»
//##ModelId=52B4C6B80289
Task::Get request()
//##ModelId=52B4C6B9032D
Task::Check Availability()
//##ModelId=52B4C6BA037E
Task::Take movie()
//##ModelId=52B4C6BC0024
Task::Outstanding films()
//##ModelId=52B4C6BD00B7
Task::Take customer data()
//##ModelId=52B4C6BE01E9
Task::Get confirmation()
Файл Data.cpp
#include «Bid.h»
//##ModelId=52B4C50F0139
Data::Create bid()
Файл Catalog.cpp
#include «Catalog.h»
//##ModelId=52B4C5790030
Catalog::View catalog()
Файл Database.cpp
#include «Database.h»
//##ModelId=52B4C61D0210
Database::Check client()
//##ModelId=52B4C61E0346
Database::Add new client()
Размещено на Allbest.ur
