Модель строится для того, чтобы лучше понимать разрабатываемую систему.

Моделирование позволяет решить четыре различные задачи:

1 Визуализировать систему в ее текущем или желательном для нас состоянии;

2 Описать структуру или поведение системы;

3 Получить шаблон, позволяющий сконструировать систему;

4 Документировать принимаемые решения, используя полученные модели.

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

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

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

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

3) Лучшие модели – те, что ближе к реальности (поскольку модель всегда упрощает реальность, задача в том, чтобы это упрощение не повлекло за собой какие-то существенные потери).

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

Унифицированный язык моделирования (Unified Modeling Language – UML) – это стандартный инструмент для разработки «чертежей» программного обеспечения. Его можно использовать для визуализации, спецификации, конструирования и документирования артефактов программных систем. UML подходит для моделирования любых систем – от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени.

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

Язык UML не является языком программирования (он инвариантен к языкам программирования).

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

1) вариантов использования (use case diagram);

2) классов (class diagram);

3) кооперации (collaboration diagram);

4) последовательности (sequence diagram);

5) состояний (statechart diagram);

6) деятельности (activity diagram);

7) компонентов (component diagram);

8) развертывания (deployment diagram).

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

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

Рассмотрим более подробно каждую из перечисленных диаграмм.

Диаграмма вариантов использования

Визуальное моделирование с использованием нотации UML можно представить как процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной бизнес-системы к логической, а затем и к физической модели соответствующей ПС. Вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы и является исходным концептуальным представлением в процессе ее проектирования и разработки. На ней изображаются отношения между актерами и вариантами использования. Создание диаграммы вариантов использования имеет следующие цели:

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

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

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

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

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

Вариант использования ‑ внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами (он определяет набор действий, совершаемый системой при диалоге с актером).

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

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

Комментарии к примеру. На рисунке 7 приведен фрагмент диаграммы вариантов использования для разрабатываемой системы (он соответствует функциональной спецификации, приведенной в таблице 1, и дополняет ее новыми функциями).

 

Рисунок 7 – Диаграмма вариантов использования системы (фрагмент)

 

Любая диаграмма, входящая в Ваш UML-проект должна быть прокомментирована: кратко описаны все основные сервисы, которые приведены на диаграмме. Например, «Перед тем как работать в системе пользователь должен пройти процедуру авторизации (ввести логин и пароль). Система проверит введенные данные и настроит интерфейс пользователя на соответствующую роль. В системе должны быть предусмотрены две роли пользователя: администратор и игрок. Любой пользователь системы должен иметь возможность посмотреть справочную информацию (сведения о разработчиках и сведения о самой системе). Администратор может создавать кроссворд в ручном или автоматическом режиме, для этого он должен подключить словарь понятий и определить параметры кроссворда (выбрать значения, заданные по умолчанию, или изменить параметры); и т.д.»

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

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

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

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

Сценарий состоит из следующих разделов:

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

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

3. Раздел «Исключения» (Альтернативы).

4. Раздел «Примечания».

Комментарии к примеру. Рассмотрим вариант использования «Пройти авторизацию» для автоматизированной системы составления линейного кроссворда (прототип экранной формы приведен на рисунке 8).

Рисунок 8 – Прототип экранной формы авторизации пользователя

Вариант использования: Пройти авторизацию

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

Актант. Пользователь.

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

Основной поток событий.

1) На экране появляется форма ввода имени пользователя и пароля с полями ввода «Логин», «Пароль» и с кнопками ОК и «Выход (Х)».

2) Пользователь вводит имя и пароль и щёлкает кнопку OK.

А1: Щёлкнута кнопка «Выход».

3) Система проверяет имя и пароль.

4) Система закрывает форму ввода имени и пароля и выводит на экран главную форму приложения с пунктами меню. Состав пунктов меню настраивается в соответствии с правами пользователя. Вариант использования завершается успешно.

А2: Имя и/или пароль неверны.

Альтернативы.

А1: Щёлкнута кнопка «Выход».

А1.1. Система закрывает форму ввода имени и пароля и выводит на экран главное окно операционной системы. Вариант использования завершается.

А2: Имя и/или пароль неверны.

А2.1. Система выводит сообщение о неверном вводе имени и/или пароля и просит повторить вход или выйти из приложения. В последнем случае вариант использования завершается.

Постусловия. При успешном завершении на экране – главная форма приложения с меню, настроенном на права пользователя.

Неясные вопросы. Уточнить права пользователей и настройки.

Диаграмма классов

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

На данном этапе для всех информационных объектов, выделенных в системе (см. п.1), разрабатываются классы с указанием полей, методов и свойств, которые регулируют процессы обработки данных (потоки данных заданной структуры) и/или структуры данных.

На рисунке 9 приведен пример диаграммы классов на этапе проектирования. На ней определены основные сущности системы с указанием отношений между ними. В методологии UML приняты следующие обозначения для отношений между классами (см. таблицу 3). На рисунке 10 приведен пример диаграммы классов на этапе реализации.

Таблица 3 – Основные виды отношений между классами

Название отношения	Обозначение
Зависимости (dependency)
Обобщения (generalization)
Ассоциации (association)
Агрегации (association)
Композиции (composition)

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

Отношение обобщения показывает, что некоторые объекты являются потомками базового (родительского) класса.

Отношение ассоциации показывает, что некоторые объекты образуют группу (ассоциацию). Наиболее простая ассоциация ‑ бинарная. Для данного вида отношения может быть указана мощность связи (например, 1..*, один ко многим).

Рисунок 9 – Пример диаграммы классов системы (спецификация)

Рисунок 10 – Пример диаграммы классов системы (реализация)

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

Для того чтобы понять назначение данных сущностей, входящих в диаграмму классов, необходимо представить в табличном виде (см. таблицы 4-5) описание всех классов с указанием типов классов и областей видимости (знаком «+» отмечена область видимости public, знаком «‑» ‑ private, знаком «#» ‑ protected).

Таблица 4 – Описание класса «Базовая сущность»

	Имя поля	Тип	Описание
+	идентификатор	Длинное целое	Идентификатор
+	версия	Длинное целое	Номер версии

Таблица 5 – Описание класса «Узел»

	Имя поля	Тип	Описание
+	координата по вертикали	Целое	Координата узла на карте
+	координата по горизонтали	Целое	Координата узла на карте
-	карта	Объект «Карта ГИС»
-	светофор	Объект «Светофор»
-	полицейский	Объект «Полицейский»
-	начала улиц	Набор объектов «Ребро»
-	окончания улиц	Набор объектов «Ребро»

Существуют различные разновидности классов:

− Абстрактный (abstract) класс не имеет экземпляров или объектов, для обозначения его имени на диаграмме используется наклонный шрифт (курсив);

− Активный класс (active class) – класс, каждый экземпляр которого имеет свою собственную нить управления;

− Пассивный класс (passive class) – класс, каждый экземпляр которого выполняется в контексте некоторого другого объекта;

− Квалифицированное имя (qualified name) используется для того, чтобы явно указать, к какому пакету относится тот или иной класс. Для этого применяется специальный символ в качестве разделителя имени – двойное двоеточие «::»;

− Имя класса без символа разделителя называется простым именем класса.

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

Продолжение следует…

 

ЛАБОРАТОРНАЯ РАБОТА № 8
разработка алгоритмов обработки данных

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

Описание логической модели данных. Если в проекте данные необходимо хранить в базе данных (БД), то на данном этапе должна быть разработана концептуальная и логическая модель БД, выделены и описаны основные сущности, определены между ними отношения. Модели должны быть представлены в соответствующей нотации (ER-модель (сущность - связь), SHM-модель (семантическую иерархическую модель) [3]). Переход к реляционной модели производится в соответствии с правилами, приведенными в [4]. Обязательным условием является нормализация реляционной модели информационной базы системы.

 

Физическое проектирование программной системы - завершающий этап разработки системы. Он включает в себя:

§ разработку пользовательского меню, которое должно быть ориентировано на структуру системы;

§ описание интерфейса с обоснованием выбора того или иного стандарта оформления /1/.

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

Реализация проекта и предъявление ПС (подсистемы) руководителю. Реализация проекта производится строго в соответствии с логическим проектом по технологии быстрой разработки приложений RAD (Rapid Application Development), в основе которой лежит спиральная модель жизненного цикла ПС, в определенной среде разработки, при необходимости используются дополнительные инструментальные средства (например, CASE-инструменты в виде специализированных пакетов и сред проектирования), производится автономная и комплексная отладка и тестирование. Руководитель проверяет полноту и качество реализации функций, соответствие системы техническому заданию и логическому проекту. Для демонстрации работоспособности системы необходимо подготовить нескольких тестовых примеров. При необходимости производится доработка реализации с повторным предъявлением системы, после доработки система выносится на защиту.

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

ОФОРМЛЕНИЕ ОТЧЕТА

Пояснительная записка к проекту оформляется в соответствии со стандартом СГАУ [21] и должна содержать:

− титульный лист (пример оформления титульного листа приведен в приложении В);

− задание на разработку программной системы (пример технического задания приведен в приложении А);

− реферат (пример реферата приведен в приложении Г);

− содержание отчета (структура содержания приведена в приложении Б);

− введение;

− основная часть;

− заключение;

− перечень принятых сокращений (при наличии);

− перечень принятых терминов (при наличии);

− список использованных источников;

− приложения.

Основная часть пояснительной записки делится на разделы:

1) Описание и анализ предметной области;

2) Проектирование системы;

3) Реализация системы;

4) Исследовательская часть (если она оговорена в задании).

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

I. В разделе «Описание и анализ предметной области» отражаются результаты выполнения лабораторной работы №1: даются базовые понятия и определения, описание применяемых методов и математических моделей (при необходимости), описываются системы-аналоги, выделяются объекты системы и их взаимосвязи между ними.

III. В разделе «Проектирование системы» отражаются результаты

1.1 разработка структурной схемы системы, в которой описывается назначение всех подсистем;

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

1.3 разработка схемы функционирования ПС (с необходимой детализацией внутри подсистем);

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

1.5 Производится выбор и обоснование (разработка и описание) алгоритмов, применяемых для обработки данных, описание алгоритмов выполняется с помощью граф-схем;

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

II. В разделе «Реализация системы» обосновываются решения, принятые при реализации логического проекта системы:

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

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

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

2.4 Разрабатывается тестовый пример и приводятся результаты тестирования системы с наглядным отображением результатов тестирования в виде таблиц, диаграмм, экранов с пояснительным текстом. Разрабатываются и описываются в соответствии со стандартами [21, 22].

Термины и определения должны соответствовать ГОСТ 34.003-90 [2].

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

В приложения выносятся:

− листинги программ;

− руководство по эксплуатации системы;

− текст контрольного примера и результаты тестирования системы;

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

Рекомендуемый объем пояснительной записки 30-35 страниц машинописного текста (без приложений).

список использованных источников

1. Вендров, А. М. CASE-технологии. Современные методы и средств проектирования информационных систем. [Текст] / А. М. Вендров – М.: Финансы и статистика, 1999. – 256 с.: ил.

2. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы [Сборник]: //Сборник ГОСТ 34.003-90, РД 50-680-88, РД 50-682-89, ГОСТ 34.201-89 - ГОСТ 34.602.89. - М.: Изд-во стандартов, 1992. -150 с.

3. Зеленко, Л.С. Технологии программирования и программная инженерия (1 часть) [Текст]: учебное пособие / Л.С. Зеленко. – Самара: изд-во СГАУ, 2006. – 96 с.: ил.

4. Леоненков, А. В. Нотация и семантика языка UML [Электронный ресурс]/ А.В. Леоненков. – Интернет-университет информационных технологий. http://www.intuit.ru/department/pl/umlbasics.

5. Определение линейного кроссворда [Электронный ресурс] ‑ http://ru.wikipedia.org/wiki/Линейный_кроссворд.

6. СанПиН 2.2.2/2.4.2198-07. Гигиенические требования к персональным электронно-вычислительным машинам и организации работ. Изменение N 1 к СанПиН 2.2.2/2.4.1340-03 [Текст] – Дата введения c 01.07.07. – М.: Бюллетень нормативных и методических документов Госсанэпиднадзора. ‑ № 3. – 2007.

7. ГОСТ 12.1.005-88. Система стандартов безопасности труда. Общие санитарно-гигиенические требования к воздуху рабочей зоны [Текст] – Дата введения 01.01.1989. – М.: Стандартинформ, 2006. – 49 с.

8. ГОСТ 12.1.007-76. Система стандартов безопасности труда. Вредные вещества. Классификация и общие требования безопасности [Текст] – Дата введения 01.01.1977. ‑ М.: Стандартинформ, 2007. – 7 с.

9. Буч, Г. Язык UML. Руководство пользователя [Текст] /Г. Буч, Д. Рамбо, А. Якобсон. ‑ 2-е изд.: Пер. с англ. Мухина Н. – М.: ДМК Пресс, 2006. – 496 с.: ил.

10. Определение кроссворда [Электронный ресурс] ‑ http://ru.wikipedia.org/
wiki/Кроссворд.

11. Большой Российский энциклопедический словарь [Текст]. ‑ М.: БРЭ, 2003.

12. Вигерс, К. Разработка требований к программному обеспечению [Текст]: Пер. с англ. /К. Вигерс. – М.: Издательский торговый дом «Русская Редакция», 2004. 576с.: ил.

13. Зеленко, Л.С. Программная инженерия. Курс лекций [Текст]: учебное пособие / Л.С. Зеленко. – Самара: изд-во СГАУ, 2012. – 148 с.: ил.

14. Орлик, С. Основы программной инженерии (по SWEBOK). Программные требования [Электронный ресурс] ‑ http://swebok.sorlik.ru/1_software_
requirements.html.

15. Методика составления спецификаций требований к программному обеспечению, рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE-830-1998) [Электронный ресурс] ‑ http://www.webisgroup.ru/services/
programming/srs/ieee-830-1998/.

16. Соммервиль, И. Инженерия программного обеспечения/ Иан Соммервиль. – М., СПб, Киев: Издательский дом «Вильямс», 2002. – 626 с.: ил.

17. Смит, Дж. Принципы концептуального проектирования баз данных [Текст] // Дж. Смит, Д.Смит // Требования и спецификации в разработке программ. - М.: Мир, 1984. - С.165 - 198.

18. Джексон, Г. Проектирование реляционных баз данных для использования с микроЭВМ [Текст]: /Пер.с анг. - М.: Мир, 1991. - 252 с.

19. Леоненков, А.В. Самоучитель UML [Текст]. – СПб: БВХ-Петербург, 2002. -234 с.

20. Липаев, В.В. Программная инженерия. Методологические основы [Текст]. – М.: Издательство «ТЕИС», 2006. – 609 с.

21. СТО СГАУ 02068410-004-2007. Общие требования к учебным текстовым документам [Текст]: методические указания. - Самара: Изд-во Самар. гос. аэрокосм. ун-та, 2007. - 30 с.

22. ГОСТ 19.701-90 (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. – М.: Изд-во стандартов, 1991. - 26 с.

ПРИЛОЖЕНИЕ А
Пример оформления технического задания на разработку ПС

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ
ИМЕНИ АКАДЕМИКА С.П. КОРОЛЕВА
(НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ)» (СГАУ)

Факультет информатики