41.Этапы проектирования. Стадии и этапы создания (гост 34.601-90)

4. Эскизный проект: 4.1. Разработка предварит-ых проектных решений по системе и её частям, 4.2. Разработка док-ции на АС и её части.

5. Технический проект.: 5.1. Разработка проектных решений по системе и её частям, 5.2. Разработка документации на АС и её части. 5.3. Разраб-ка и оформ-е док-ции на поставку изделий для комп-ния АС и (или) техн-их треб-ий (техн-их заданий) на их разработку. 5.4.Разработка заданий на проект-ие в смежных частях проекта объекта автом-ции.

4.1. Разработка предварительных проектных решений по системе и её частям

1.функции АС; 2.функции подсистем, их цели и эффекты; 3.состав комплексов задач и отдельных задач; 4.концепция инфор-ой базы, её укрупнённая стр-ра; 5.функции СУБД; 6.состав вычислительной системы; 7.функции и параметры основных программных средств.

5.1. Разработка проектных решений по системе и её частям

разработка общих решений: 1.по системе и её частям, 2.функционально-алгоритмической стр-ре системы, 3.по функциям персонала и орг-ной структуре, 4.по структуре технических средств, 5.по алгоритмам решения задач и применяемым языкам, 6.по орг-ции и ведению инфо-ной базы, системе классификации и кодирования инф-ции, 7.по программному обеспечению

Этапы разработки ПО:

Проектирование: формирование моделей данных, процессов. Отображение функций на этапе анализа в модули ИС, разработка архитектуры ИС.

Конечными продуктами этапа проектирования являются: 1.схема БД; 2.набор спецификаций модулей системы (они строятся на базе моделей функций); 3.Проект архитектуры ИС

Разработка архитектуры

1.Выбор типа архитектуры, 2.Выбор типа БД (центра-ная/ распред-ая/ однородная), 3.Ис-ние параллельных серверов БД, 4.Выбор платформы и ОС. 5.Опр-ие характ-ик арх-туры: "файл-сервер" или "клиент-сервер? 3-уровневая арх-ура? БД центр-ная или распред-ная? БД однородная по производителям? Ис-ся парал-ые серверы БД?

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

38,39.Варианты использования. Описание вариантов использования. Диаграмма вариантов использования на UML1 этап. Выявление требований. Множество требований (противоречивые, несогласованные, дублированные, неясные)

2 этап. Классификация и спецификация требований. Регламентированные тексты, классификация, наборы атрибутов, модели, прототипирование. 3 этап. Варианты использования (Use Cases - описание функциональности системы)

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

Актеры – внешние сущности по отношению к ИС.

Функции, реализуемые ИС: 1.Полезные, 2.Позволяющие получать конкретные законченные результаты для пользователей, 3.Не всякая функция является вариантом использования.

Концептуальный анализ «Предметной Области» -> Глоссарий -> Информационная модель ИС (БД)

Спецификация варианта использования:

1.Свободный формат, 2.Полный формат (предложенный А. Коберном), 3.Таблицы в две колонки, в три колонки, 4.Стиль RUP, 5.Псевдокод, 6.Диаграмма вариантов использования UML, 7.Другие графические модели.

Шаблон полного описания Коберном:

1.Название - краткая фраза в виде глагола в неопределённой форме совершенного вида, отражающая цель, 2.Контекст использования - уточнение цели, при необходимости – условия её нормального завершения. 3.Область действия - ссылка на рамки проекта, напр., бух.учет. 4.Уровень требования.5.Основное действующее лицо. 6.Участники и интересы. 7.Предусловие. 8.Минимальные гарантии. – Напр., в случае неудавшейся транзакции все данные, имевшиеся в системе до её начала, сохраняются неизменными.9.Гарантии успеха. 10.Триггер. 11.Основной сценарий - Формат описания: <Номер шага> <Описание действия>. 12.Расширения - альтернативные сценарии,13.Список изменений в технологии и данных. 14.Вспомогательная информация

Табличные представления ВИ

Таблица 1: Актер – Действие

Пользователь - Формирует запрос на поиск УММ

Система - Отображает результаты поиска

Пользователь - Выбирает УММ и отправляет запрос на открытие

Шаблон описания RUP(rational unified process): 1.Наименования и краткое описание, 2. Поток событий: основной и альтернативный, 3. Специальные требования, 4. Предусловия, 5. Постусловия, 6. Точки расширения

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

1.описывает функциональное назначение системы;

2.преследует цели: 1.определение общих границ предметной области; 2.определение общих требований к функц-нию системы; 3.разработка исходной концептуальной модели для ее дальнейшей детализации в форме логической и физической моделей; 4.подготовка исходной документации для взаимодействия разработчиков и заказчиков.

Название граф-го элемента и граф-ое представ-ние: вариант ис-ния – овал внутри буквы «ВИ», актер – человечек, интерфейс – круг, примечание – лист.

Отношения между компонентами ДВИ:

1 .отношения ассоциации - устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. Дополнительные условные обозначения:

1 .Имя2.Кратность: целое неотрицательное число, включая 0; два целых неотрицательных числа, разделенных двумя точками: "первое число...второе число"; два символа, разделенных двумя точками, причем первый из них - целое неотрицательное число, а второй - специальный символ "*"; символ "*" является сокращенной записью "0..*"

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

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

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