Разработка приложения для работы с датами

Введение

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

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

Современный персональный компьютер теперь имеет производительность большой электронно-вычислительной машины 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю программного обеспечения.

Чрезвычайно актуальными стали следующие проблемы:

1) аппаратная сложность опережает наше умение строить программное обеспечение, использующее потенциальные возможности аппаратуры;

2) наше умение строить программы отстаёт от требований к новым программам;

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

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

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

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

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

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

У этой программы есть подраздел, который содержит «Информацию о программе». В этом подразделе указанна информация о версии программы, её наименовании, авторе программы, а также сведения о правах на эту программу.

2. Теоретическая часть.

2.1 Объектный подход к разработке программных средств Сущность объектного подхода к разработке программных средств.

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

Отношение связывает некоторые объекты: можно считать, что объединение этих объектов обладает некоторым свойством. Если отношение связывает «n» объектов, то такое отношение называется n-местным. На каждом месте объединения объектов, которые могут быть связаны каким-либо конкретным отношением, могут находиться разные объекты, но вполне определенные (в этом случае говорят: объекты определенного класса). Одноместное отношение называется простым свойством объекта соответствующего класса. Многоместное отношение объектов будем называть ассоциативным свойством объекта, если этот объект участвует в этом отношении. Состояние объекта может быть изучено по значению простых или ассоциативных свойств этого объекта. Множество всех объектов, которые обладают каким-то общим набором свойств, называется классом объектов.

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

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

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

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

объекты модельного (вещественного или умственного) мира;

информационные модели объектов реального мира;

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

объекты процесса разработки программных средств.

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

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

использование системы понятий, позволяющих описывать объекты и их классы;

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

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

предпочтение разработки структуры данных перед реализацией функций.

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

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

2.2 Визуальная среда программирования С++ Builder.

Borland C++ Builder — выпущенное компанией Borland средство быстрой разработки приложений, позволяющее создавать приложения на языке C++, используя при этом среду разработки и библиотеку компонентов Delphi.

Среда разработки C++ Builder. C++ Builder представляет собой SDI-приложение, главное окно которого содержит настраиваемую инструментальную панель (слева) и палитру компонентов (справа). Помимо этого, по умолчанию при запуске C++ Builder появляются окно инспектора объектов (слева) и форма нового приложения (справа). Под окном формы приложения находится окно редактора кода, рисунок 1.

Рисунок 1 — Среда разработки C++ Builder.

Формы являются основой приложений C++ Builder. Создание пользовательского интерфейса приложения заключается в добавлении в окно формы элементов объектов C++ Builder, называемых компонентами. Компоненты C++ Builder располагаются на палитре компонентов, выполненной в виде многостраничного блокнота. Важная особенность C++ Builder состоит в том, что он позволяет создавать собственные компоненты и настраивать палитру компонентов, а также создавать различные версии палитры компонентов для разных проектов.

Компоненты C++ Builder разделяются на видимые (визуальные) и невидимые (невизуальные). Визуальные компоненты появляются во время выполнения точно так же, как и во время проектирования. Примерами являются кнопки и редактируемые поля. Невизуальные компоненты появляются во время проектирования как пиктограммы на форме. Они никогда не видны во время выполнения, но обладают определенной функциональностью (например, обеспечивают доступ к данным, вызывают стандартные диалоги Windows 95 и др.). Они показаны на рисунке 2.

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

Каждый компонент C++ Builder имеет три разновидности характеристик: свойства, события и методы.

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

Рисунок 3 — Инспектор объектов Свойства компонентов являются атрибутами компонента, определяющими его внешний вид и поведение. Многие свойства компонента в колонке свойств имеют значение, устанав иваемое по умолчанию (например, высота кнопок). Свойства компонента отображаются, а странице свойств (Properties). Инспектор объектов отображает опубликованные (published) свойства компонентов. Помимо published-свойств, компоненты могут и чаще всего имеют общие (public), опубликованные свойства, которые доступны только во время выполнения приложения. Инспектор объектов используется для установки свойств во время проектирования. Список свойств располагается на странице свойств инспектора объектов. Можно определить свойства во время проектирования или написать код для видоизменения свойств компонента во время выполнения приложения.

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

Страница событий (Events) инспектора объектов показывает список событий, распознаваемых компонентом (программирование для операционных систем с графическим пользовательским интерфейсом, в частности, для Windows Vista или Windows 7 предполагает описание реакции приложения на те или иные события, а сама операционная система занимается постоянным опросом компьютера с целью выявления наступления какого-либо события). Каждый компонент имеет свой собственный набор обработчиков событий. В C++ Builder следует писать функции, называемые обработчиками событий, и связывать события с этими функциями. Создавая обработчик того или и ого события, вы поручаете программе выполнить написанную функцию, если это событие произойдет.

Для того чтобы добавить обработчик событий, нужно выбрать на форме с помощью мыши компонент, которому необходим обработчик событий, затем открыть страницу событий инспектора объектов и дважды щелкнуть левой клавишей мыши на колонке значений рядом с событием, чтобы заставить C++ Builder сгенерировать прототип обработчика событий и показать его в редакторе кода. При этом автоматически генерируется текст пустой функции, и редактор открывается в том месте, где следует вводить код. Курсор позиционируется внутри операторных скобок { … }. Далее нужно ввести код, который должен выполняться при наступлении события. Обработчик событий может иметь параметры, которые указываются после имени функции в круглых скобках. Данное действие показано на рисунке 4.

Рисунок 4 — Прототип обработчика событий Метод является функцией, которая связана с компонентом, и которая объявляется как часть объекта. Создавая обработчики событий, можно вызывать методы, используя следующую нотацию: ->, например:

Edit1->Show ();

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

Файлы, образующие приложение — формы и модули — собраны в проект. Менеджер проектов показывает списки файлов и модулей приложения и позволяет осуществлять навигацию между ними. Можно вызвать менеджер проектов, выбрав пункт меню View/Project Manager, показанный на рисунке 5. По умолчанию вновь созданный проект получает имя Project1.cpp.

программный средство вычисление нерабочий день Рисунок 5 — Менеджер проектов По умолчанию проект первоначально содержит файлы для одной формы и исходного кода одного модуля. Однако большинство проектов содержат несколько форм и модулей. Чтобы добавить модуль или форму к проекту, нужно щелкнуть правой кнопкой мыши и выбрать пункт New Form из контекстного меню. Можно также добавлять существующие формы и модули к проекту, используя кнопку Add контекстного меню менеджера проектов и выбирая модуль или форму, которую нужно добавить. Формы и модули можно удалить в любой момент в течение разработки проекта. Однако, из-за того, что форма связаны всегда с модулем, нельзя удалить одно без удаления другого, за исключением случая, когда модуль не имеет связи с формой. Удалить модуль из проекта можно, используя кнопку Remove менеджера проектов.

Если выбрать кнопку Options в менеджере проектов, откроется диалоговая панель опций проекта, в которой можно выбрать главную форму приложения, определить, какие формы будут создаваться динамически, каковы параметры компиляции модулей (в том числе созданных в Delphi 2.0, так как C++ Builder может включать их в проекты) и компоновки. Эти действия показаны на рисунке 6.

Рисунок 6 — Установка опций проекта Важным элементом среды разработки C++ Builder является контекстное меню, появляющееся при нажатии на правую клавишу мыши и предлагающее быстрый доступ к наиболее часто используемым командам.

Разумеется, C++ Builder обладает встроенной системой контекстно-зависимой помощи, доступной для любого элемента интерфейса и являющейся обширным источником справочной информации о C++ Builder.

Первым шагом в разработке приложения C++ Builder является создание проекта. Файлы проекта содержат сгенерированный автоматически исходный текст, который становится частью приложения, когда оно скомпилировано и подготовлено к выполнению. Чтобы создать новый проект, нужно выбрать пункт меню File/New Application.

C++ Builder создает файл проекта с именем по умолчанию Project1. cpp, а также make-файл с именем по умолчанию Project1.mak. При внесении изменений в проект, таких, как добавление новой формы, C++ Builder обновляет файл проекта, это показано на рисунке 7.

Рисунок 7 — Файл проекта Проект или приложение обычно имеют несколько форм. Добавление формы к проекту создает следующие дополнительные файлы:

1) Файл формы с расширением DFM, содержащий информацию о ресурсах окон для конструирования формы.

2) Файл модуля с расширением CPP, содержащий код на C++.

3) Заголовочный файл с расширением .H, содержащий описание класса формы.

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

Для того чтобы добавить одну или более форм к проекту, показанных на рисунке 8, выберите пункт меню File/New Form. Появится пустая форма, которая будет добавлена к проекту. Можно воспользоваться пунктом меню File/New, выбрать страницу Forms и выбрать подходящий шаблон из репозитория объектов.

Рисунок 8 — Шаблоны форм Для того, чтобы просто откомпилировать текущий проект, из меню Compile нужно выбрать пункт меню Compile. Для того, чтобы откомпилировать проект и создать исполняемый файл для текущего проекта, из меню Run нужно выбрать пункт меню Run. Компоновка проекта является инкрементной (перекомпилируются только изменившиеся модули).

Если при выполнении приложения возникает ошибка времени выполнения, C++ Builder делает паузу в выполнении программы и показывает редактор кода с курсором, установленным на операторе, являющемся источником ошибки. Прежде чем делать необходимую коррекцию, следует перезапустить приложение, выбирая пункт меню Run из контекстного меню или из меню Run, закрыть приложение и, лишь затем вносить изменения в проект. В этом случае уменьшится вероятность потери ресурсов Windows.

3. Техническое задание Введение.

Программа называется «Вычисление нерабочих дней». Данная программа применяется в учебном процессе и наглядно демонстрирует учащимся возможности визуальной среды программирования С++ Builder.

Основание для разработки.

1) Основанием для разработки является задание на курсовую работу по дисциплине «Технология разработки программных продуктов».

2) Утвердил документ «Новороссийский колледж строительства и экономики» от 28.02.2011 г.

3) Темой разработки является «Разработка приложения для работы с датами».

Функциональное назначение программы.

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

1) Требования к функциональным характеристикам программы:

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

3) Программа при нажатии кнопки «Вычисление нерабочих дней» должна производить вычисления нерабочих дней в выбранном пользователем месяце.

4) Программа при нажатии кнопки «Информация о программе» должна скрывать предыдущее окно и открывать окно «Информация о программе».

5) Программа при нажатии на кнопку «ОК» должна закрывать окно «Информация о программе» и раскрывать окно «Вычисление нерабочих дней».

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

7) Входные данные программы должны быть выбраны пользователем от «января» до «декабря».

8) Выходные данные должны выводиться в виде целочисленного значения.

Требования к надежности программы:

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

2) Программа при сбое работы персонального компьютера не должна сохранять результат работы.

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

Условия эксплуатации программы:

1) Условия эксплуатации данной программы не требует специальной подготовки и не требует особых температурных показателей.

2) Данная программа работает на минимальной комплектации технических средств.

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

1) Операционная система: Windows 2000/XP/Vista/7.

2) Процессор: Pentium 4/ AMD Athlon XP (1800 МГц).

3) Оперативная память: 512 мегабайт.

4) Видеоадаптер класса nVIDIA Geforce или ATI Radeon с 64 мегабайтами памяти.

5) Свободная память на жёстком диске 40 килобайт.

Требования к информационной и программной совместимости программы:

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

Требования к транспортированию и хранению программы.

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

Требования к программной документации программы.

В состав программной документации входят:

1) Руководство пользования программой.

2) Руководство администратору.

Стадии и этапы разработки программы.

Программа и вся сопроводительная документация должна быть создана в течении времени с 28.02.11 до 6.03.11. Программу должен написать Голиков И. А. студент группы.

П-41у.

4. Диаграммы UML.

4.1 Краткая история UML.

Объектно-ориентированные языки моделирования появились в период с середины 70-х до конца 80-х годов, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектно ориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию. С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее многие пользователи испытывали затруднения при выборе языка моделирования, который бы полностью соответствовал их потребностям, что послужило причиной так называемой «войны методов» .

Критическая масса новых идей начала формироваться к середине 90-х годов, когда Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ, партнеры попытались создать новый, унифицированный язык моделирования и руководствовались при этом тремя соображениями. Во-первых, все три метода, независимо от желания разработчиков, уже развивались во встречном направлении. Разумно было продолжать эту эволюцию вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей. Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточиться на более продуктивной деятельности. Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден.

Начав унификацию, авторы поставили перед собой три главные цели:

1) моделировать системы целиком, от концепции до исполняемого артефакта, с помощью объектно-ориентированных методов;

2) решить проблему масштабируемости, которая присуща сложным системам, предназначенным для выполнения ответственных задач;

3) создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.

Изобретение языка для объектно-ориентированного анализа и проектирования не слишком отличается от разработки языка программирования.

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

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

Официально создание UML началось в октябре 1994 года, когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и ОМТ. Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области конструирования программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был основан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полного определения UML.

Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, OMG) на конкурс по созданию стандартного языка моделирования.

Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG, а именно: Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйкхолта (Ed Eykholt) из Rational была организована семантическая группа. Пересмотренная версия UML (1.1) была снова представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях Группы по анализу и проектированию и Комитета по архитектуре OMG, a 14 ноября 1997 года принята в качестве стандарта на общем собрании всех членов OMG.

Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 — UML 1.3. Данное руководство пользователя описывает именно эту версию языка.

4.2 Сведения о диаграмме вариантов использования Диаграммы вариантов использования описывают функциональное назначение системы или то, что система должна делать. Разработка диаграммы преследует следующие цели:

1) определить общие границы и контекст моделируемой предметной области;

2) сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

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

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

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

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

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

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

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

4.3 Диаграмма вариантов использования «Вычисления нерабочих дней».

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

Рисунок 9 — Диаграмма вариантов использования программ.

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

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

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

Для каждого атрибута класса можно задать видимость (visibility). Эта характеристика показывает, доступен ли атрибут для других классов. В UML определены следующие уровни видимости атрибутов:

1) Открытый (public) — атрибут виден для любого другого класса (объекта).

2) Защищенный (protected) — атрибут виден для потомков данного класса.

3) Закрытый (private) — атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

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

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

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

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

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

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

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

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

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

При создании диаграмм классов часто пользуются понятием «стереотип». В дальнейшем речь пойдет о стереотипах классов. Стереотип класса — это элемент расширения словаря UML, который обозначает отличительные особенности в использовании класса. Стереотип имеет название, которое задается в виде текстовой строки. При изображении класса на диаграмме стереотип показывается в верхней части класса в двойных угловых скобках. Есть четыре стандартных стереотипа классов, для которых предусмотрены специальные графические изображения.

Стереотип используется для обозначения классов-сущностей (классов данных), стреотип описывает пограничные классы, которые являются посредниками между ПС и внешними по отношению к ней сущностями — актерами, обозначаемыми стереотипом «<>». Наконец, стереотип описывает классы и объекты, которые управляют взаимодействиями. Применение стереотипов позволяет, в частности, изменить вид диаграмм классов.

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

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

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

Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки — как операции и отношения.

4.5 Диаграмма классов программы «Вычисления нерабочих дней».

Диаграмма классов программы «Вычисления нерабочих дней» представлена на рисунке 10.

Рисунок 10 — Диаграмма классов программы «Вычисления нерабочих дней».

5 Алгоритм работы программы Блок-схема алгоритма обработки компонента Button1 представлена на рисунке 11.

Рисунок 11 — Блок-схема алгоритма обработки компонента Button1.

Блок-схема обработки компонента Button1 состоит из следующих блоков:

1) начало обработки;

2) объявление переменных;

3) присваивание значения переменной j;

4) присваивание значения переменной k;

5) блок условия;

6) если условие не выполняется, то производятся вычисления и производится возврат к условию.

7) если условие выполняется, то производятся вычисления выражений;

8) вывод результата;

9) конец обработки.

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

Свойства алгоритма:

1) Дискретность, то есть алгоритм представлен в виде конечной последовательности шагов, при этом каждое действие выполняется только после выполнения предыдущего.

2) Определённость — алгоритм должен единственным образом толковать правила и порядок выполнения действий.

3) Результативность — алгоритм должен обеспечивать такую последовательность действий, которая приводит к результату.

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

5) Конечность — результат достигается за конечное число шагов.

6) Массовость — один и тот же алгоритм дожжен быть применим для решения множества схожих задач.

7) Компактность — алгоритм должен быть лаконично изложен.

6 Ход работы Ход работы по созданию программы состоит из нескольких шагов:

1) Создаём проект в C++ Builder.

2) Создаём форму.

3) Наносим на форму необходимые компоненты.

4) Прописываем код компонента в файле с расширением *.cpp.

5) Производим компиляцию программы (на вкладке RUN нажимаем подпункт RUN).

6) Производится проверка синтаксиса кода программы.

7) Информация о ошибках выводится в окно Messages с указанием номера строки с ошибкой и краткое её описание.

8) Если нет ошибок, то производится компиляция программы.

9) Если есть ошибки, то они исправляются, и снова запускается проверка и компиляция программы.

10) Далее создаётся программа с расширением файла *.ехе.

11) Созданная программа проверяется на соответствие техническому заданию.

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

Дизайн форм программы указан в Приложении А.

Код программы указан в Приложении Б.

Руководство пользователя указано в Приложении В.

Руководство администратора персонального компьютера, локальной сети указано в Приложении Г.

Заключение

Главной задачей в данном проекте является разработка программы и проверка её работоспособности, пользуясь методами тестирования С++Builder. Также необходимо подготовить комплект программной и эксплуатационной документации на программу. Эта документация отображает все сведения о разработанной программе, а также все сведения, необходимые для работы с программой и ее обслуживания. Процесс составления программной и эксплуатационной документации является очень трудоемким и требует большого количества времени на ее оформление. Выполненное приложение может быть использовано на практических работах по дисциплине «ТРПП», для демонстрации возможности визуальной среды по работе с датами.

В ходе курсовой работы были закреплены теоретические знания, полученные по предмету «Технология разработки программных продуктов» и приобретены практические навыки по составлению и оформлению комплекта программной и эксплуатационной документации на программное изделие.

1 Галявов И. Р., Borland C++5 для себя, ДМК, М., 2001 г., — 12 с.

2 С. А. Орлов. Технологии разработки программного обеспечения, С.-Петербург, Питер, 2003 г., — 148 с.

3 Л. Г. Гагарина, Б. Д. Виснадул, А. В. Игошин. Основы технологии разработки программных продуктов, М., Форум-Инфра-М, 2006 г., — 156 с.

4 Руководство по составлению и оформлению курсового проекта (работы), НТГЭ, 2003 г.

5 Методические указания к выполнению курсовой работы, НТГЭ, 2003 г. — 17 c.

6 Е. Кондратюк. С++ .Трюки и эффекты. СПб., Питер, 2006 г., — 431 c.

7 Архангельский А. Я. С++Builder 6. Справочное пособие в 2 книгах. М., — Бином, 2002., — 350 с.

8 Б. Пахомов. С/С++ Borland C++ Builder для начинающих. СПб., — БХВ Петербург, 2006 г., — 810 с.

9 С. Бобровский. Технологии C++ Builder. Разработка приложений для бизнеса. СПб. -Питер, 2007 г., — 212 с.

ПРИЛОЖЕНИЕ, А Дизайн программы Дизайн формы 1 представлены на рисунке А1.

Рисунок А1 — Дизайн формы 1.

Дизайн формы 2 представлены на рисунке А2.

Рисунок А2 — Дизайн формы 2.

ПРИЛОЖЕНИЕ Б Программный код приложения.

// Код формы 1, срр файл.

//—————————————————————————————————————;

#include.

#pragma hdrstop.

#define MaxNerDn 9.

#include «Unit1.h» .

#include «Unit2.h» .

//—————————————————————————————————————;

#pragma package (smart_init).

#pragma resource «*.dfm» .

TForm1 *Form1;

TDateTime d[2];

int i;

double dd;

OutOfWork (TDateTime dt1, TDateTime dt2).

{.

int VixPr[12][MaxNerDn]={1,2,5,7,8,9,16,23,30,.

6,13,20,27,0,0,0,0,0,.

6,13,20,27,0,0,0,0,0,.

3,10,17,24,0,0,0,0,0,.

1,8,9,15,22,29,0,0,0,.

5,12,19,26,0,0,0,0,0,.

3,10,17,24,31,0,0,0,0,.

7,14,21,28,0,0,0,0,0,.

4,11,18,25,0,0,0,0,0,.

2,9,16,23,30,0,0,0,0,.

6,13,20,27,0,0,0,0,0,.

4,11,18,25,0,0,0,0,0,}; //Календарь на 2011 г.

int LastDaysOfMonth[]={31,28,31,30,31,30,31,31,30,31,30,31};

Word y1, m1,d1,y2,m2,d2;

DecodeDate (dt1,y1,m1,d1);

DecodeDate (dt2,y2,m2,d2);

int i=0, ii=0,jj=0,p, j=0;

if (m1==m2).

{.

for (i=0,ii=0,jj=0;i.

{.

p=VixPr[m1−1][i];

if (p>0 && p>=d1 && p<=d2).

ii++;

}.

}.

else.

{.

for (i=0,ii=0;i.

{.

p=VixPr[m1−1][i];

if (p>0 && p>=d1 && p <= LastDaysOfMonth[m1−1]).

ii++;

}.

for (j=0,jj=0;j.

{.

p=VixPr[m2−1][j];

if (p>0 && p>=1 && p<=d2).

jj++;

}.

}.

return (ii+jj);

}.

//—————————————————————————————————————;

__fastcall TForm1: TForm1(TComponent* Owner).

: TForm (Owner).

{.

}.

//————————————————————————————————————-;

//—————————————————————————————————————;

void __fastcall TForm1: Button1Click (TObject *Sender).

{.

static int j=0;

if (j≠100).

{.

Edit1->Text="" ;

j=100;

return;

}.

int k=OutOfWork (d[0], d[1]);

Edit1->Text=IntToStr (k);

j=101;

i=0;

}.

//—————————————————————————————————————;

void __fastcall TForm1: Button2Click (TObject *Sender).

{.

i=0;

}.

//—————————————————————————————————————;

void __fastcall TForm1: DateTimePicker1CloseUp (TObject *Sender).

{.

d[i]=DateTimePicker1->Date;

i++;

d[i]=dd;

}.

//—————————————————————————————————————;

void __fastcall TForm1: Button3Click (TObject *Sender).

{.

Form1->Hide ();

Form2->Show ();

}.

//—————————————————————————————————————;

// Код формы 1, h файл.

//—————————————————————————————————————;

#ifndef Unit1H.

#define Unit1H.

//—————————————————————————————————————;

#include.

#include.

#include.

#include.

#include.

//—————————————————————————————————————;

class TForm1: public TForm.

{.

__published: // IDE-managed Components.

TEdit *Edit1;

TDateTimePicker *DateTimePicker1;

TButton *Button3;

void __fastcall DateTimePicker1CloseUp (TObject *Sender);

void __fastcall Button1Click (TObject *Sender);

void __fastcall Button2Click (TObject *Sender);

void __fastcall Button3Click (TObject *Sender);

private: // User declarations.

public: // User declarations.

__fastcall TForm1(TComponent* Owner);

};

//—————————————————————————————————————;

extern PACKAGE TForm1 *Form1;

//—————————————————————————————————————;

#endif.

// Код формы 2, cpp файл.

//—————————————————————————————————————;

#include.

#pragma hdrstop.

#include «Unit1.h» .

#include «Unit2.h» .

//—————————————————————————————————————;

#pragma package (smart_init).

#pragma resource «*.dfm» .

TForm2 *Form2;

//—————————————————————————————————————;

__fastcall TForm2: TForm2(TComponent* Owner).

: TForm (Owner).

{.

}.

//—————————————————————————————————————;

void __fastcall TForm2: OKButtonClick (TObject *Sender).

{.

Form2->Close ();

Form1->Show ();

}.

//—————————————————————————————————————;

// Код формы 2, h файл.

//—————————————————————————————————————;

#ifndef Unit2H.

#define Unit2H.

//—————————————————————————————————————;

#include.

#include.

#include.

#include.

#include.

#include.

//—————————————————————————————————————;

class TForm2: public TForm.

{.

__published: // IDE-managed Components.

TButton *OKButton;

TPanel *Panel1;

TImage *ProgramIcon;

TLabel *ProductName;

TLabel *Version;

TLabel *Comments;

TLabel *Label1;

TLabel *Label2;

TLabel *Label3;

void __fastcall OKButtonClick (TObject *Sender);

private: // User declarations.

public: // User declarations.

__fastcall TForm2(TComponent* Owner);

};

//—————————————————————————————————————;

extern PACKAGE TForm2 *Form2;

//—————————————————————————————————————;

#endif.

ПРИЛОЖЕНИЕ В Руководство пользователя Для начала работы в данной программе необходимо её запустить двойным щелчком правой кнопки мыши по её ярлыку.

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

ПРИЛОЖЕНИЕ Г Руководство администратора Данная программа не требует специальных устройств в составе персонального компьютера. Программа корректно функционирует при следующей конфигурации персонального компьютера: монитор, системных блок, клавиатура, оптический манипулятор «мышь».

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