Добавлен: 25.10.2018
Просмотров: 4542
Скачиваний: 12
81
3.2.4.2. Диаграмма деятельности варианта использования П.2 «Поиск УММ»
…
3.3. Требования к производительности
[Требования к производительности определяют временные ограничения, которые должны быть вы-
полнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений,
использованию оперативной памяти, объему запоминающих устройств и т. д., если это не было до-
кументировано в другом разделе SRS.]
ИС должна выдавать результаты поиска менее чем за пять секунд.
3.4. Ограничения проектирования
3.5. Атрибуты программной системы
3.5.1. Надежность
[Требования надежности определяют надежность в измеряемых величинах. Требования такого ти-
па предполагают вероятность неидеальной работы программы и ограничивают область ее несо-
вершенства.]
3.5.2. Доступность
3.5.3. Защита
[Перечисляются требования к обеспечению безопасности системы с учетом возможности искаже-
ния данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.]
Возможность добавления и модификации информации в БД ИСС должна предоставляться ав-
торизованным пользователям, обладающим соответствующими правами.
3.5.4. Поддержка
[Задаются требования, касающиеся адаптации системы в случае изменения набора или состава
бизнес правил. Например, необходимость в изменении алгоритма начисления пени, суммы страховки
или поддержка нескольких схем оформления графического интерфейса]
3.6. Дополнительные требования
Нет.
4. Дополнительная информация
Нет.
4.1. Оглавление и индекс
4.2. Приложения
[Приложения могут содержать следующее: пример форматов ввода-вывода; результаты опросов
пользователей; дополнительную информацию, которая может помочь читателям SRS; специальные
инструкции кодирования и способы защиты, экспорта, начальной загрузки и т.д.]
82
ПРИЛОЖЕНИЕ Л
(справочное)
IEEE 1016-1987 ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
(SOFTWARE DESIGN DOCUMENT – SDD)
Утверждаю
Дата
01.03.09 А. Мелихов: первоначальный эскиз
04.04.09 А. Мелихов: составлена общая схема
06.06.09 А. Мелихов: выявление дефектов
07.08.09 А. Мелихов: добавление компонентов, предложенных А. Мелиховым
08.09.09 А. Мелихов: дополнительная разбивка на компоненты согласно вариантам использования и
модели переходов состояний
1. Введение
1.1. Цель
В данном документе представлены результаты проектирования информационно-справочной
системы (ИСС).
1.2. Описание проекта
Этот проект представляет собой прототип ИС, создаваемый с учебной целью, на котором де-
монстрируются приемы разработки архитектуры, детального проектирования и составления доку-
ментации.
1.3. Определения, сокращения и термины
ИС – информационная система.
CMF – (Content Management Framework) – каркасная система управления сайтом (фреймворк).
ORM – (Object Relational Mapping) – объектно-реляционное отображение.
2. Ссылки
Software Engineering: an Objected-Oriented Perspective. E. Braude, Wiley, 2000.
UML: The Unified Modeling Language User Guide. G. Booch, J. Rumbaugh, I. Jacobson, Addison-Wesley,
1998.
Стандарт IEEE 1016-1987 устанавливает основные направления разработки SDD.
3. Описание декомпозиции
Для описания архитектуры ИС могут использоваться любые средства, позволяющие изобра-
зить функциональную или программно-функциональную структурные схемы (см. определения ГОСТ
24.103-84) архитектуры ИС. Однако, в SDD результаты проектирования архитектуры необходимо по
возможности документировать с помощью диаграмм пакетов UML.
3.1. Модульная декомпозиция
[Описываются архитектурные слои: (i) представления (presentation); (ii) предметной области
(domain - домен); (iii) источника данных (data source). Распределение классов по указанным слоям
должно быть выполнено таким образом, чтобы полностью исключить зависимость бизнес-логики и
источника данных от слоя представления.]
С целью выбора платформы для реализации проектируемой системы на страницах ПЗ были
описаны три каркасных системы управления сайтом (Content Management Framework - CMF): Ruby on
Rails, Django, Grails. Как показал анализ наилучшими характеристиками для выполнения данного
проекта обладает CMF Django.
CMF Django построена с использованием распространенной архитектуры (паттерна проекти-
рования) Модель-Представление-Контроллер (Model-View-Controller -- MVC). MVC упрощает разра-
ботку приложений посредством его деления на несколько слоев, каждый из которых имеет соответ-
ствующие роли и возможности. Слой модели отвечает за поддержание состояния приложения. Он
инкапсулирует данные приложения и бизнес логику. Слой представления обеспечивает реализацию
пользовательского интерфейса приложения. Слой управления интерпретирует обращение пользова-
телей и ответ пользователям посредством передачи данных между слоем модели и слоем представле-
ния.
83
Представление MVC-паттерна при реализации web-приложения показано на рис.Л.1. В кон-
тексте web-приложения, слой представления соответствует web-страницам, которые составляют
пользовательский интерфейс web-приложения. Слой управления идентифицирует HTTP-запросы и
взаимодействует со слоем модели. Слой модели взаимодействует с базой данных и выполняет необ-
ходимые запросы бизнес логики к манипулируемым данным.
Рис. Л.1. MVC-паттерн web-приложения
В Django реализован механизм автоматического преобразования между объектами модели и
таблицами БД – Object-Relational Mapping (ORM).
C
программной точки зрения кроме файла представления (views.py), файла модели (model.py)
и файла настройки проекта (settings.py) в состав типичного проекта Django входят: (i) шаблоны (tem-
plates\*.
html), которые позволяют определить управляющую логику и встроенные переменные в
HTML странице; (ii) файл отображения – URL mapping (url.py) - используются для преобразования
запросов от браузера в вызовы функций представления; (iii) файл административного интерфейса
(admin.py) определяет структуру и состав интерфейса администратора сайта.
Содержание и структура каждого из перечисленных выше модулей будут описаны в раздел 6
настоящего документа.
3.2. Декомпозиция на параллельные процессы
[При наличии в системе параллельных процессов выполняется проектирование потоков управления с
целью выявления в системе параллельных процессов, порядка их создания и уничтожения, определе-
ния характера взаимодействия между собой и т.д.]
3.3. Декомпозиция данных
[В этом разделе приводится описание структур данных: исходные данные; результаты функциони-
рования; данные, использующиеся для взаимодействия между подсистемами]
4. Описание зависимостей
[В этом разделе дается описание зависимостей между различными вариантами декомпозиции, на-
пример, зависимости между пакетами или между страницами, составляющими web-сайт.]
Использование CMF Django позволяет фактически полностью исключить необходимость ана-
лиза зависимостей и проектирование системных интерфейсов. Внимание разработчика сосредотачи-
вается исключительно на вопросах обеспечения необходимого функционала. В этой связи для данно-
го проекта описание зависимостей и системных интерфейсов не приводится.
4.1. Межмодульные зависимости (объектная модель)
4.2. Межпроцессные зависимости
4.3. Зависимости внутри данных
4.4. Зависимости между состояниями
4.5. Зависимости между уровнями
5. Описание интерфейса
[В этом разделе описываются интерфейсы объектной модели]
5.1. Межмодульные интерфейсы
[Проблема организации межмодульных интерфейсов играет принципиальную роль для удовлетворе-
ния принципа «слабое внешнее связывание, сильное внутреннее сцепление». Особое значение вопросы
проектирования интерфейсов приобретают при проектировании распределенных приложений.
В настоящем разделе необходимо описать результаты проектирования межмодульных интерфей-
сов с использованием структурных GoF-паттернов (адаптер, заместитель, фасад) и результаты
84
проектирования межслойных интерфейсов (для распределенного приложения) с использованием уда-
ленного вызова процедур или асинхронного обмена сообщениями.]
MVC-структура фреймворка Django строго отделяет архитектурные слои приложения друг от
друга, а правила построения каждого слоя в отдельности исключают необходимость дополнительной
проработки вопросов проектирования межмодульных интерфейсов.
5.2. Интерфейс процессов
Взаимодействие параллельных процессов в проектируемой системе не рассматривается, по-
скольку вопросы возможных взаимоблокировок при одновременной записи информации в БД не-
сколькими пользователями будут решаться средствами СУБД.
6. Детальное проектирование каркаса ИС
6.1. Детальное проектирование модулей
[В этом разделе приводятся все необходимые нетривиальные свойства модулей, описанных в разделе
3.1 SDD для каркаса проекта. При описании слоев проводится детальное проектирование классов,
состоящее в уточнении атрибутов классов (указывается тип, значение по умолчанию, видимость,
инварианты и т.д.), а также операций классов (краткое описание операции, видимость, область
действия, предусловия, постусловия)]
В настоящем разделе приводится описание содержания и структуры каждого из перечислен-
ных в разделе 3.1. модулей.
6.1.1. Слой модели ИС
В настоящем проекте слой модели ИС располагается в файле (models.py). Согласно идеологии
CMF Django файл модели предназначен для реализации объектно-реляционного преобразования
(ORM). В этой связи структура models.py в общем случае представляет собой объявление классов,
относящихся к модели предметной области. На рис. Л.2 приведена диаграмма классов, составляющая
модель предметной области проектируемой системы.
Рис. Л.2. Диаграмма классов модели предметной области
На диаграмме классов (рис. Л.2) в виде комментариев приведены листинги определения клас-
сов (с указанием типа атрибутов) слоя модели ИС в соответствии с синтаксисом языка Python. Следу-
ет отметить, что для создания зависимости между классами типа «многие ко многим» в Django пре-
дусмотрен специальный метод – ManyToManyField, позволяющий сопоставить атрибуты, требующие
использование указанного типа связи. Состав и назначение атрибутов классов, приведенных на ри-
сунке Л.2., определены в задании на КП и в дополнительных комментариях не нуждаются.
6.1.2. Слой представления ИС
…
85
6.2. Детальное проектирование данных
[Описывается структура БД с использованием ERD или UML; перечисляются все запросы, которые
необходимо предусмотреть в системе для ее полноценного функционирования, а также приводят
синтаксис и описание типовых SQL-запросов, хранимых процедур, представлений и триггеров, по-
зволяющих, с одной стороны, осуществлять мониторинг за состоянием БД, с другой стороны, ре-
шить задачу построения сложно-структурированных запросов к БД, тем самым повысив надеж-
ность и расширяемость системы, а также упростив программирование клиентской части прило-
жения.]
Механизм объектно-реляционного преобразования (ORM), реализованный в CMF Django, по-
зволяет полностью абстрагироваться от взаимодействия с БД, работая исключительно и только с объ-
ектной моделью ИС. При этом разработчик web-приложения не привязан к какому-либо диалекту
SQL или СУБД.