47272 (588473), страница 4

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

Текст из файла (страница 4)

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

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

Таблица 1. Системная архитектура

Слои	Анализ	Проектирование	Реализация
Документы	Поток работ	Поток форм	Формы
Правила бизнеса	Поток процессов	Модель компонентов	Программы
База данных	Модель данных	Схема базы данных	Таблицы и т.п.

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

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

Реализация. На данном этапе проект преобразуется в систему.

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

Спецификация процесса (СП) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD (т.е. если он достаточно невелик, и его описание может занимать до одной страницы текста). Фактически СП представляют собой алгоритмы описания задач, выполняемых процессами: множество всех СП является полной спецификацией системы. СП содержат номер и / или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков.

Независимо от используемой нотации спецификация процесса должна начинаться с ключевого слова (например, @СПЕЦПРОЦ). Требуемые входные и выходные данные должны быть специфицированы следующим образом:

@ВХОД =

@ВЫХОД =

@ВХОДВЫХОД = ,

где – соответствующее имя из словаря данных.

Эти ключевые слова должны использоваться перед определением СП, например,

@ВХОД = СЛОВА ПАМЯТИ

@ВЫХОД = ХРАНИМЫЕ ЗНАЧЕНИЯ

@СПЕЦПРОЦ

Для всех СЛОВ ПАМЯТИ выполнить:

Распечатать ХРАНИМЫЕ ЗНАЧЕНИЯ

@

Ситуация, когда символ данных является одновременно входным и выходным, может быть описана двумя способами: либо символ описывается два раза с помощью @ВХОД и @ВЫХОД, либо один раз с помощью @ВХОДВЫХОД.

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

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

• для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;

• спецификация должна определять способ преобразования входных потоков в выходные;

• нет необходимости (на данном этапе) определять метод реализации этого преобразования;

• спецификация должна стремиться к ограничению избыточности – не следует переопределять то, что уже было определено на диаграмме или в словаре данных;

• набор конструкций для построения спецификации должен быть простым и стандартным.

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

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

В состав языка входят следующие основные символы:

• глаголы, ориентированные на действие и применяемые к объектам;

• термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.п.);

• предлоги и союзы, используемые в логических отношениях;

• общеупотребительные математические, физические и технические термины;

• арифметические уравнения;

• таблицы, диаграммы, графы и т.п.;

• комментарии.

Управляющие структуры языка имеют один вход и один выход. К ним относятся:

1) последовательная конструкция:

ВЫПОЛНИТЬ функция 1

ВЫПОЛНИТЬ функция 2

ВЫПОЛНИТЬ функция 3

2) конструкция выбора:

ЕСЛИ ТО

ВЫПОЛНИТЬ функция 1

ИНАЧЕ

ВЫПОЛНИТЬ функция 2

КОНЕЦЕСЛИ

3) итерация:

ДЛЯ

ВЫПОЛНИТЬ функция

КОНЕЦДЛЯ

Или

ПОКА

ВЫПОЛНИТЬ функция

КОНЕЦПОКА

При использовании структурированного естественного языка приняты следующие соглашения:

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

2. Ключевые слова ЕСЛИ, ВЫПОЛНИТЬ, ИНАЧЕ и т.д. должны быть написаны заглавными буквами.

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

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

5. Логика процесса должна быть выражена четко и недвусмысленно.

@ВХОД = ВВЕДЕННЫЙ ПАРОЛЬ

@ВХОД = ПАРОЛЬ

@ВЫХОД = СООБЩЕНИЕ

@ВЫХОД = КОРРЕКТНЫЙ ПАРОЛЬ

@СПЕЦПРОЦ 1.1 ПОЛУЧИТЬ ПАРОЛЬ

ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту,

запрашивающее ввод пароля

принять ВВЕДЕННЫЙ ПАРОЛЬ

ДОТЕХПОРПОКА ВВЕДЕННЫЙ ПАРОЛЬ = ПАРОЛЬ

или были сделаны три попытки ввода

КОНЕЦВЫПОЛНИТЬ

ВЫПОЛНИТЬ установить флаг КОРРЕКТНЫЙ

ПАРОЛЬ в случае равенства

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.1

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

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

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа «да-нет». Однако иногда в условии может присутствовать и ограниченное множество значений, например, ЯВЛЯЕТСЯ ЛИ ДЛИНА СТРОКИ БОЛЬШЕЙ, МЕНЬШЕЙ ИЛИ РАВНОЙ ГРАНИЧНОМУ ЗНАЧЕНИЮ?

Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Так, в конструкции

ЕСЛИ ИДЕТ ДОЖДЬ ТО РАСКРЫТЬ ЗОНТ

ИДЕТ ДОЖДЬ является условием, а РАСКРЫТЬ ЗОНТ – действием.

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

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

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

2) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;

3) если очередной символ не находится в заданном диапазоне, то подать звуковой сигнал и вернуть код ошибки;

4) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.

Таблица решений для данного примера выглядит следующим образом (таблица 2):

Таблица 2. Таблица решений по условиям

	УСЛОВИЯ	1	2	3	4	5	6	7	8
C1	isctrl(c)	Д	Д	Д	Д	Н	Н	Н	Н
C2	I > max_lenght	Д	Д	Н	Н	Д	Д	Н	Н
C3	out_of_range(c)	Д	Н	Д	Н	Д	Н	Д	Н
	ДЕЙСТВИЯ
D1	beep()	1	1	1	1	1	1	1
D2	return(ERROR)	2	2	2	2	2	2	2
D3	return(++i)								2
D4	putchar(c)								1

Заметим, что если выполняется условие C1, то нет необходимости в проверке условий C2 и C3. Поэтому комбинации условий 1, 2, 3, 4 могут быть заменены обобщающей комбинацией (Д,-,–), где «–» означает любую из возможных альтернатив (в данном случае, Д или Н). Аналогично, комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (Н, Д,–). Редуцированная таким образом таблица решений будет иметь следующий вид (таблица 3):

Характеристики

Список файлов ВКР