 |
Глава 2. Технический проект
|
|
|
|
Технический проект состоит из целого ряда обеспечений.
Математическое обеспечение содержит описание математических методов, алгоритмов, моделей, реализуемых в программном обеспечении. Анализ точности моделей, погрешности и области допустимых значений применяемых методов.
Информационное обеспечение описывает совокупность стандартов, которым должно соответствовать программное обеспечение. Например, даже при использовании готовых средств для работы с html необходимо задокументировать, что программное обеспечение поддерживает стандарт HTML4.0, CSS 2.0, и т.д. Возможны случаи, кода программное обеспечение, в силу своей практической направленности, будет требовать обязательной сертификации на соответствие определенным стандартам, например, на соответствие строительным нормам и правилам. Все вышеперечисленное описывается в данном разделе технического проекта.
Организационное обеспечение описывает комплекс организационных мероприятий, необходимый для успешного внедрения данного программного продукта на производстве, например, процедуру реорганизации отдела маркетинга в отдел аналитического маркетинга, или процедуру сокращения штата бухгалтерии предприятия.
Программное обеспечение описывает системное и прикладное ПО.
Системное ПО структурирует требования к общесистемному (используемый компилятор, библиотеки функций и т.д.) и специальному системному ПО (операционная система, драйвера сетевых устройств, принтера, и пр.)
Прикладное ПО описывается совокупностью разделов, а именно состоит из следующих подразделов:
– техническое задание
Техническое задание (ТЗ) ¾ это документ, оформляемый в соответствии с ГОСТ 19.201-78 ЕСПД. Техническое задание. – М.; Изд-во стандартов, 1982.
|
|
|
В техническом задание формулируется цель проекта.
Цель ¾ это идеальный образ конечного продукта. Идеальность его заключается в том, что он недостижим в принципе, а реализуем в некотором приближении.
Для формулировки цели необходимо выяснить у заказчика все детали и пожелания, которые он «видит» в желаемом продукте. Для этого с заказчиком проводятся интервью, консультации и уточнения. Может применятся метод мозгового штурма, когда конечный продукт «придумывается» в течении времени не более 1 часа группой «фантазирующих» специалистов. Последний метод считается самым эффективным на сегодняшний день способом генерирования идей.
В техническом задании формулируются основные требования к программному продукту, в том числе и к функциональному составу. Отражаются укрупнено основные функции будущей системы, которые будут уточняться в дальнейшем на стадии разработки функциональной структуры.
Техническое задание согласовывается представителем заказчика и утверждается руководителем организации исполнителя (руководителем проекта).
– функциональная структура
Проработка функциональной структуры ¾ наиболее важный этап разработки, хотя требования к функциям программы формулировались на стадии проработки ТЗ. Их группировка, взаимосвязь отражается на схеме или при использовании UML стандарта проектирования на диаграмме прецедентов (вариантов использования). Обратите внимание, что любая кнопочка на форме в программе, любой пункт меню ¾ это отдельная функция. Поэтому, необходимо выявить все функции (их будет не меньше чем количество элементов управления: кнопочек, полей ввода, радио- и чек-боксов…, пунктов меню, кнопочек на панели инструментов и др) программы. Наиболее распространенной ошибкой является пропуск «очевидных» функций. Например, мы обсуждаем функции работы с электронной библиотекой, функцию добавление книги и изменение данных книги мы записали, а функцию удаления упустили, и, выходит, в системе не будет возможности удалить книгу из электронной библиотеки.
|
|
|
– спецификация пользовательского интерфейса
Это документ, в котором в эскизном варианте «рисуются» все формы и их варианты будущей программы. Иногда, если позволяет ресурс времени, строится пилотное приложение, лишенное функционального наполнения, но иллюстрирующее пользовательский интерфейс будущей программы.
Спецификация пользовательского интерфейса согласовывается представителем заказчика и утверждается руководителем организации исполнителя (руководителем проекта).
– архитектура программы
Выбор архитектуры ¾ очень важный этап разработки. Он требует анализа вопросов обеспечения переносимости системы, способов разворачивания. Можно привести примеры известных архитектур: одиночный загрузочный модуль; двухуровневая система приложение – сервер баз данных; клиент-сервер архитектура; трехуровневая архитектура с сервером приложений; распределенное приложение; многоагентное распределенное приложение; web-приложение, ориентированное на «тонкого» клиента и др..
– система классов
Разработка системы классов демонстрирует умение выполнять декомпозицию задачи на более простые подзадачи в терминах объектно-ориентированного подхода.
Объяснение особенностей объектно-ориентированного метода (ООМ) обычно начинают с определения объекта. И это не случайно, так как представление любой предметной области в виде множества взаимосвязанных, взаимодействующих объектов и является ключом к пониманию ООМ.
Объект – это сущность, выделяемая из словаря предметной области, которая характеризуется набором свойств и событийным поведением. Последнее обычно представляется в виде множества событий, из которых образуется жизненный цикл объекта. В более распространенной терминологии для именования этих двух аспектов описания объекта используют термины атрибут и метод.
Класс - фундаментальное понятие объектно-ориентированного метода. Это абстракция, обозначающее некоторое подмножество объектов, имеющих сходные черты как в наборе свойств, так и в поведении. Из опыта осуществления классификации в различных областях знания мы можем заметить, что абстракции бывают различного уровня и образуют древовидную структуру по отношению включенности одних абстракций в другие.
|
|
|
Система классов проектируется также как и цель проекта в результате совместного обсуждения в формате «мозгового штурма» и, в дальнейшем, корректируется (метод CRC карточек). Претенденты на класс оформляются в виде карточек с формулировкой их назначения (зоны ответственности).
Наиболее применимым методом в рамках работы над проектом является метод вербального анализа, основанный на выявлении потенциальных претендентов на класс, как существительных в кратком тексте описания предметной среды.
При таком подходе проектировщик составляет описание предметной среды (например, учета литературы в электронном каталоге). Он описывает основные операции, которые будут автоматизированы (например, читатель берет по читательскому билету электронную книгу в каталоге, в его читательскую карточку заносится запись …). В этом тексте определяются существительные. Они отражают важные концептуальные сущности рассматриваемой задачи и являются претендентами на оформление в виде класса. Система классов уточняется, пополняется служебными и вспомогательными классами.
После определения основных классов начинается проектирование системы классов, выявление отношений между ними, установка ассоциаций, зависимостей, обобщений, агрегаций. Методом ассоциаций система классов может быть расширена.
Приветствуется, если проектировщик применяет для решения подзадач готовые архитектурные шаблоны. Например, для решения технической задачи покадрового просмотра анимированного изображения применение шаблона Observer, или для решения задачи регистрации фильтров музыкального плеера, участвующих в процессе воспроизведения музыки в потоковой фильтрации звука, применение шаблона Listener, Adapter.
|
|
|
Следующим шагом является конкретизация содержимого классов, их поведенческих и статических аспектов.
Важно помнить, что класс – абстракция, его поведение представлено набором методов. Метод – это действие экземпляра класса.
Система классов должна соответствовать основным принципам. Система в целом должна отвечать принципам ацикличности, правильного формирования пакетов, открытости/закрытости, инвертирования зависимостей, и пр.
Должны быть рассчитаны метрики, подтверждающие правильность формирования пакетов системы классов, устойчивости. Должны быть проанализированы принятые формы зацепления и связности.
Система классов оформляется в соответствии с UML в виде диаграммы классов.
Дополнительно к этому блоку относится проектирование диаграммы компонентов. О данной диаграмме необходимо сказать, что она отражает структуру проекта той, или иной среды разработки. Все папки и файлы проекта представлены на диаграмме в виде соответствующих значков. Показаны зависимости между компонентами.
– модель поведения (типовые последовательности, диаграммы действий, деятельностей)
Модель поведения описывает динамику системы. Ее функционирование во времени! Описанию подлежат основные последовательности вызовов между классами. Язык UML обладает широкими возможностями для моделирования динамики. Особенно это важно при проектировании многопоточных (параллельных приложений) и сетевых многопользовательских приложений, в которых актуальными становятся вопросы синхронизации обращений, формирования критических секций, реализации асинхронных обращений.
Строится модель поведения на диаграммах последовательностей, действий, деятельностей, коопераций и др.
В проекте основные последовательности, например, последовательность вызовов для выполнения добавления книги в электронный каталог, должны быть отображены на диаграммах. По сути, реализация каждой функция, выявленной на стадии разработки функциональной структуры, должна быть описана в динамике вызовов методов объектов участвующих в реализации классов.
Можно придерживаться такого правила: сколько кружков на диаграмме прецедентов (функций), столько диаграмм последовательностей в пояснительной записке.
|
|
|
