1.2.8. Результаты экспериментальной проверки

Результаты тестирования показали:

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

2) Некорректного поведения или аварийного завершения работы модуля не удалось добиться ни некорректными действиями пользовательского кода, ни ошибками доступа к хранилищам.

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

4) Утечек памяти зафиксировано не было, механизм «сборки мусора» функционирует должным образом.

2.1. Проектирование на языке uml

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

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

С повсеместным распространением ООП проектировщики всё чаще стали обращаться к понятию «класс» как к универсальной единице структуры программы и как к актеру поведения. Одновременно несколько видных исследователей – Буч, Джекобсон, Румбах и другие – начали разрабатывать концепции языков, которые могли бы описать все аспекты работы программы, и были бы столь же эффективными, как языки программирования. Их работа вылилась в принятый консорциумом OMG стандарт Unified Modeling Language, который на сегодняшний день используется множеством разработчиков по всему миру и продолжает совершенствоваться.

2.1.1. Концепция Unified Modeling Language

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

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

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

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

UML предназначен для описания двух основных видов моделей: статических (модели, описывающие структуру) и динамических (модели, описывающие поведение). Нотация UML, как языка визуального проектирования, включает в себя большое количество компонентов графической нотации. Основными понятиями UML являются «класс», «атрибут», «операция» и «отношение». Основное представление понятий – диаграмма.

2.1.2. Виды диаграмм uml

Диаграммы UML, как и было сказано выше, являются основным способом представления моделей. Последовательность рассмотрения диаграмм в данном подразделе обусловлена рекомендациями Rational Unified Process и наглядно показывает последовательность моделирования системы.

Диаграмма прецедентов (use case diagram)

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

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

1) ассоциация – указание на семантическую связь актера и прецедента (например, актер инициирует прецедент);

2) включение – указание на то, что заданное поведение одного прецедента включается как составная часть в поведение другого;

3) расширение – указание на то, что заданное поведение прецедента может использоваться другим в случае выполнения неких условий;

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

Рис. 2.1. Диаграмма прецедентов

Диаграмма классов (class diagram)

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

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

Между классами могут быть следующие отношения:

1) ассоциация – произвольная семантическая связь классов, может иметь кратность (аналогично ER-диаграммам);

2) обобщение – отношение между предком и потомком, интерпретация наследования;

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

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

5) зависимость – семантическая связь, не являющаяся какой-либо из вышеперечисленных.

Интерфейс в UML – это специальный случай класса, когда специфицируется только его поведение.

Рис. 2.2. Диаграмма классов

Диаграмма кооперации (collaboration diagram)

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

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

Рис. 2.3. Диаграмма коопераций уровня спецификации

Рис. 2.4. Диаграмма коопераций уровня экземпляров

Диаграмма последовательности (sequence diagram)

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

Рис. 2.5. Диаграмма последовательности

Диаграмма состояний (statechart diagram)

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

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

Рис. 2.6. Диаграмма состояний

Диаграмма деятельности (activity diagram)

Диаграмма деятельности является самым низкоуровневым видом диаграмм UML. Её семантика сродни многократно стандартизованным правилам записи блок-схем алгоритмов.

Рис. 2.7. Диаграмма активностей

Диаграмма компонентов (component diagram)

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

Диаграмма развертывания (deployment diagram)

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