При описании предметной области на этом этапе проектирования необходимо использовать средства, доступные как конечному пользователю, так и проектировщику ИС. Естественный язык не подходит для подобных описаний в силу размытости формулировок. Формальные языки не понятны пользователям. Поэтому используют структурированные естественные языки.
Наиболее распространенны: IDEF-0 (методология SADT) и UML.
Основные понятия моделей процессов предметной области:
Модель ППО – набор взаимосвязанных описаний, каждое описание представляется диаграммой. Модель ППО объединяет их в иерархические структуры, на вершине ее лежит контекстная диаграмма, она отражает связь системы с внешним миром. Состоит из одного блока и множества дуг. Остальные уровни иерархической структуры получаются путем декомпозиции контекстной диаграммы.
Нумеруются диаграммы следующим образом – контекстная иметь номер А-0, ее декомпозиция А0, а остальные диаграммы нумеруются путем добавления к номеру родительской диаграммы номера декомпозируемого блока. Первый 0 обычно опускается.
Любая модель ППО имеет цель, точку зрения и границы.
Цель модели ППО – совокупность вопросов, на которые должна отвечать модель с заданной точностью, то есть при исследовании предметной области сначала выясняют всю совокупность вопросов моделирования, а затем в одной-двух фразах выражают цель модели.
Пример. Предметная область – механический цех. Вопросы, которые могут возникнуть – каковы обязанности мастера, рабочего; кто контролирует задание; как продвигаются по цеху материалы; когда и какие чертежи и стандарты нужны. Цель – определить обязанности каждого работника механического цеха и понять взаимосвязи между ними. Можно отметить, что в данном случае нас не интересует, каким образом осуществляется контроль задания и не интересует непосредственное содержание стандартов (это позволяет точность системы).
Точка зрения модели ППО – позиция или роль человека или объекта, на которую нужно встать, чтобы увидеть систему в действии. В рассмотренном выше примере можно выделить несколько точек зрения: мастера, рабочий, контролер, начальник цеха, директор завода. Первые три не подходят, так как каждый из них акцентирован на своем участке и не охватывает остальных; точка зрения директора цеха также не подходит, так как цех для него – всего лишь подсистема, и он воспринимает его как единое целое; лучше всего подходит начальник цеха, однако при окончательном утверждении модели необходимо убедиться, что все требования, связанные с каждой из точек зрения учтены в модели или, что этими требованиями можно пренебречь.
Если что-то не может быть описано только с использованием выбранной точки зрения, целесообразно построить дополнительную модель или несколько моделей.
Границы модели ППО – четкое определение, что является, а что нет объектом моделирования. Обычно говорят о границах модели в ширину и в глубину. Глубина модели – количество уровней декомпозиции, ширина – определение границ функциональности.
Элементы модели ППО. Диаграммы состоят из блоков (активностей) и дуг. Блоки изображают процессы, функции или другие активные части системы. Каждый блок имеет название, являющееся глаголом. Процесс обязательно должен иметь время действия. Каждый блок должен иметь хотя бы одну выходную дугу.
При построении модели нужно стремиться, чтобы в каждой диаграмме было от 3 до 6 блоков.
Доминирование блоков. Блоки располагаются на диаграмме в определенной последовательности по степени важности слева направо сверху вниз. Такое расположение называется доминированием, которое понимается как влияние, которое один блок оказывает на другие. Кроме того, доминирование выражается нумерацией блоков, начиная с 1 для главного и т.д.
Изображение объектов и виды дуг. Дуги связывают блоки и отображают взаимодействия между ними, они изображаются одинарными именованными линиями со стрелками. Они представляют множества объектов, поэтому их имена должны быть именами существительными.
Между процессами возможны 4 отношения: вход, управление, выход и механизм.
Стороны диаграммы отвечают за те же аспекты взаимодействия аналогичным образом.
Входные дуги изображают объекты, используемые или преобразуемые функцией, подходят к блоку слева (сырье). Управляющие дуги несут информацию о том, при каких условиях и на основании чего выполняется функция, соответствующая блоку (техпроцесс) - правила, нормативы, стандарты, законодательные акты и т.д. Выходные дуги изображают объекты, являющиеся результатом выполнения процесса, выходят из блока справа (деталь). Дуги механизмов отображают средства, используемые для реализации процесса (снизу).
Процесс под воздействием управления преобразует вход в выход, используя механизмы.
Дуги можно разделить на граничные и внутренние, граничные образуют интерфейс процесса, внутренние не выходят за пределы диаграммы. На диаграмме не должно быть более 6 граничных стрелок одного вида.
Правила именования дуг при их расщеплении и слиянии.
При расщеплении дуг действуют следующие правила:
1. Дуга всегда именуется до расщепления.
2. Непомеченные ветви содержат все объекты, указанные в метке дуги до разветвления.
3. Ветви, помеченные после разветвления, содержат часть объектов исходной дуги и не содержат ничего нового.
При соединении дуг действуют следующие правила:
1. Дуга всегда помечается после соединения.
2. Если дуга не помечена до соединения, то эта ветвь содержит ту же информацию, что и результирующая.
3. Помеченные до соединения дуги соответствуют части информации результирующей дуги.
В методологии SADT выделяется пять видов взаимодействия между процессами:
1. Отношение управления – возникает между процессами, когда выход первого является управлением для другого.
2. Отношение входа – возникает между функциями (активностями), когда выход одной является входом для другой.
3. Отношение обратной связи по управлению – возникает между активностями, когда выход функции является управлением для нее самой через другие функции.
4. Обратная связь по входу возникает, когда выход функции является входом для нее самой через другие функции.
5. Отношение выход – механизм возникает, когда выход процесса является механизмом для другого процесса. Такое отношение встречается крайне редко из-за того, что обычно выходит за цели создания модели.
Отношения 3 и 4 называются рекурсивными, возможна только косвенная рекурсия через другие процессы.
Процесс декомпозиции.
Декомпозиция – процесс создания диаграммы, детализирующей определенный блок и связанные с ним дуги. Декомпозиция – процесс анализа системы, однако, закончив построение какой-либо диаграммы, обычно проверяют, корректно ли она синтезируется в родительский блок. Обычно при построении моделей ППО дуги не появляются из ниоткуда и не исчезают бесследно. То есть при декомпозиции блока они должны появиться на следующей диаграмме.
Однако существуют исключение: вхождение дуги в тоннель между диаграммами. Это происходит, если дуга является граничной и отсутствует на родительской диаграмме, либо она касается блока, но не появляется на детализирующей диаграмме. Дуги, имеющие либо скрытый источник, либо скрытый приемник, заключаются в квадратные скобки, чтобы показать, что они идут либо из другой части модели, либо прямо извне модели. А такое бывает, однако чаще всего тоннели скрывают ошибки моделирования.
В общем случае декомпозиция завершается, когда получены ответы на все вопросы, поставленные в начале моделирования.
Правило завершения декомпозиции.
Декомпозиция завершается, если:
1.Блок содержит достаточно деталей. Если блок содержит ответы на 1 или более вопросов, то дальнейшая композиция не требуется, например: вначале моделирования был поставлен вопрос – кто контролирует выполнение задания. Если получен блок «Контроль задания» с механизмом «Мастер», то дальнейшая декомпозиция не нужна.
2.Для дальнейшей декомпозиции необходимо изменить уровень абстракции, то есть выйти за рамки целей, например: если цель аналогична поставленной в примере выше, а декомпозиция приведет к рассмотрению работы станка, то декомпозицию надо прекратить.
3.Для дальнейшей декомпозиции необходимо изменить точку зрения. Если новая точка зрения рассматривалась в начале моделирования как возможная, то целесообразно разработать еще одну модель процессов предметной области.
4.Получены похожие блоки – два блока не отличаются по производимой функции, составу входов и выходов и один из них уже детализирован, декомпозицию прекращают и преобразуют модель, чтобы учесть совпадение процессов.
5.Получена тривиальная функция, то есть не требующая объяснений. Блок, не имеющий детализирующей диаграммы, обозначается следующим образом – ставится черта в левом верхнем углу блока.
На этапе сбора и анализа требований можно говорить либо о существующей модели – as-is, либо о предлагаемой – as-to be.
