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

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

Анализ задания

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

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

1. 
   Чему посвящена предметная область, какие в ней есть термины и понятия, субъекты и объекты, способы взаимодействия субъектов, способы использования объектов, закономерности. Например, если речь идёт о графических примитивах в трёхмерном пространстве, то следует выявить список возможных примитивов (точка, линия, прямоугольник, параллелепипед, шар и т.п.), способы их описания (так, для точки достаточно указать её координаты, а для шара необходимо знать координаты центра и радиус), возможные способы преобразования (перемещение, масштабирование, поворот и т.п.).
   
2. 
   Что входит в словарь предметной области, отдельно выделив список существительных и список глаголов, которые могут быть связаны с существительными. Для графических примитивов существительными могут быть: «точка», «координата», «шар», «угол», «цвет», «длина», «ширина» и др. А в качестве глаголов можно указать: «нарисовать», «повернуть», «масштабировать», «переместить».
   
3. 
   Каковы функциональные требования к разрабатываемой информационной системе. Основой их служат потребности заказчика, однако разработчик должен оценить возможность реализации требований, исходя из технических возможностей и имеющихся ресурсов.
   

---

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

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

Проектирование системы классов

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

Для приведённого выше примера можно указать следующее соответствие:

• 
  классы: точка, шар;
  
• 
  свойства: координата, угол, цвет, длина, ширина;
  
• 
  методы: нарисовать, повернуть, масштабировать, переместить.
  

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

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

---

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

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

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

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

методов – со строчной;

• 
  перед именем свойства или метода ставится символ, указывающий на режим доступности: закрытый (-), защищённый (#), открытый (+);
  
• 
  после имени метода ставятся круглые скобки, в которых могут быть перечислены параметры метода;
  
• 
  наследование классов обозначается стрелкой с треугольным незакрашенным наконечником;
  
• 
  стрелка при наследовании направляется от класса-наследника к родительскому классу.
  

Пример диаграммы классов приведён на рисунке 1.

Фигура

#абсцисса #ордината #аппликата #цвет

+нарисовать()

---

-видимый_размер_точки

-радиус


Рис. 1. Диаграмма классов трёхмерных графических примитивов

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

5.2.2 Практическая часть

В специальной части должно содержаться: описание структуры информационной системы; краткий процесс разработки информационной системы; описание ролей и пользователей; руководство пользователя.

Выбор средств реализации продукта автоматизации

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

В курсовому проекту набор перечисленных вопросов остаётся, однако от студента требуется обоснование ответа лишь на два из них – о выборе языка программирования и о выборе среды разработки. Рекомендованными в рамках дисциплины языками являются C++ и C#. Рекомендуемой средой разработки является система Microsoft Visual Studio. Тем не менее, студент имеет право остановиться на каком-либо другом объектно-ориентированном языке высокого уровня, позволяющем разрабатывать независимые оконные приложения. Выбор языка требует обязательного обоснования. В случае выбора одного из рекомендованных языков обоснование выбора среды разработки не требуется – достаточно лишь указать на используемый инструментарий.

Обоснование строится на основе выполненного анализа предметной области, исходя из следующих определяющих факторов:

• 
  функциональные требования к системе;
  
• 
  наличие в языке возможностей для реализации функциональных требований;
  
• 
  трудоёмкость разработки.
  

---

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

Разработка программного модуля

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

Следует заметить, что раздел «Практическая часть» пояснительной записки является наиболее объемным и практически важным. Здесь описывается выполнение основной части работы, связанное непосредственно с программированием и формированием структуры программного продукта. Каждое действие в рамках разработки программного модуля (модулей) должно быть обосновано и задокументировано.

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

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

Определение методики тестирования

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

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

---

Смотрите также файлы

• А. Д. Чередов, А. Н. Мальчуков.docx

• Ассортимент, приготовление и способы реализации банкетных горячих блюд из мяса.docx

• Структура боязни женского негатива (3 пласта).docx

• Введение Ангиология.docx

• Комплекс общеразвивающих упражнений.docx