UML. Диаграммы вариантов использования (стр. 16 )

Стадия проектирования делится на:
1) Этап технического проектирования – формируются проектные решения по обеспечивающей и функциональной частям информационной системы, моделирование производственных, хозяйственных, финансовых ситуаций, осуществляется постановка задачи и блок-схемы и их решение.
2) Этап рабочего проектирования – осуществляется разработка и доводка системы, корректировка структуры, создание различной документации: на поставку, на установку технических средств, инструкции по эксплуатации, должностные инструкции.

Стадия внедрения информационной системы предполагает:
1) Подготовку к вводу в эксплуатацию – на этом этапе производится установка технически средств, настройка системы, обучение персонала, пробное использование.
2) Проведение опытных испытаний всех компонентов системы перед запуском.
3) Сдача в промышленную эксплуатацию, которая оформляется актом сдачи-приемки работ.

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

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

Информационная система – ресурсы, которые позволяют выполнить сбор, корректировку и распространение информации. Типичная информационная система (ИС) состоит из БД, ПО БД, прикладного ПО, аппаратное обеспечение и персонал.

Жизненный цикл ИС.

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

Неудачи при создании ПО обычно вызваны следующими причинами: отсутствие полной спецификации требований; отсутствие правильной методологии разработки; недостаточная степень разделения проекта на составные части для осуществления эффективного контроля за исполнением.

Для разрешения этих проблем предложен структурный подход к разработке ПО, называемый жизненным циклом. ЖЦ ИС выглядит следующим образом как показано на рисунке.

1 – Планирование разработки ИС;

2 – Определение требований к системе;

14 – сбор и анализ требований к с-ме;

3 – Концептуальное планирование БД;

4 – Логическое проектирование БД;

5 – Физическое проектирование БД;

6 – Проектирование БД;

7 – Выбор целевой СУБД;

8 – Разработка приложений;

9 – Реализация;

10 – Создание прототипов;

11 – Конвертирование и загрузка существующих

данных;

12 – Тестирование

13 – Эксплуатация и сопровождение

Разработка приложений выполняется параллельно с

проектированием БД и включает в себя проектирование транзакций,

диалога пользователя с ИС и разработку основных алгоритмов работы системы.

Создание прототипов. Прототип – рабочая модель ИС, к-ая обычно

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

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

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

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

Стратегии тестирования:

1.  нисходящая. Она начинается на уровне подсистемы, в которой модули более низкого уровня заменены заглушками. После того, как оттестировано взаимодействие между модулями, каждый из них разбивается на части аналогично;

2.  восходящая. Тестирование начинается с модуля самого нижнего уровня.

3.  тестирование потоков. Эта стратегия предназначена для с-м с большим количеством взаимодействующих потоков.

4.   интенсивное тестирование. В этом случае определяется способность функционирования системы в условиях максимальных и минимальных нагрузок.

Эксплуатация и сопровождение включает в себя:

1.  контроль производительности системы. Если система не удовлетворяет пользователя, то может потребоваться дополнительная настройка и реорганизация БД (в лучшем случае – перестройка индексов и процедур; в худшем – перестройка БД и приложений);

2.  сопровождение и модернизация приложения. Это может включать в себя как консультации по работе приложения, так и доработку ИС.

30.  Проектирование диалога с пользователем. Структура пользовательского интерфейса

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

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

Модуль логики диалога взаимодействует с прикладным интерфейсом. В качестве прикладного интерфейса для систем БД могут выступать ODBC или DBE. А в качестве команд выступают update, delete, create и т. п. В ответ на команду прикладной интерфейс генерирует ответный сигнал. Одной из разновидностей этого сигнала является сообщение об ошибке.

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

Формы и объекты могут взаимодействовать с прикладным интерфейсом, минуя модуль логики диалога, если это взаимодействие не должно изменять состояние системы, например, объект класса TDbGrid представляет данные, используя прикладной интерфейс, но не затрагивает модуль логики диалога.

Для описания диалога с пользователем используются 2 базовые нотации – графическая и текстовая. В 1ом случае логика диалога представляется в виде диаграмм, во 2ом – на специальном языке.

Транзитивная сеть

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

Среди состояний выделяют начальное (или стартовое), в к-ом система находится в начале работы. Это состояние обозначается входной дугой, не имеющей источника. Начальное состояние в с-ме м. б. одно. Кроме того, в транзитивной сети выделяются финальные состояния, попадая в которые система завершает свою работу. Таких состояний м. б. несколько. Финальные состояния выделяются двойной обводкой.

Реализовать транзитивную сеть можно с использованием конечного автомата, к-ый описывается семёркой: H(Q,∑,P,δ,γ,q0,F), где Q – множество состояний; ∑ - множество входных сигналов; P – множество команд; δ – ф-ция переходов опре деляет в какое состояние должна перейти с-ма из текущего при определенном входном сигнале; γ – ф-ция прикладных действий (какое действие необходимо осуществить); q0 – начальное состояние с-мы (q0Q); F – множество конечных состояний (FQ).

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

Достоинства простой транзитивной сети:

1.     Точное формальное описание диалога

2.     Диалог реализуется в простой табличной форме

3.     Такая реализация диалога легко редактируется и дополняется

Недостатки простой транзитивной сети:

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

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

Рекурсивно-транзитивная сеть

Основным признаком необходимости построения такой сети является: 1 Выделение подсети, обладающей всеми характеристиками основной сети; 2 Переход в подсеть из основной сети может осуществляться из нескольких состояний, а выход из подсети в основную сеть должен производиться в состояние, явившееся точкой входа в подсеть.