Рекомендации по разработке схем документооборота

Описание схем

Схема данных отображает путь данных при решении задач и определяет этапы обработки, а так же различные применяемые носители данных.

Схема данных состоит из:

- символов данных (символы данных могут так же указывать вид носителя данных);

- символов процесса, который следует выполнить над данными, могут указывать функции, выполняемые вычислительной машиной;

- символов линий, указывающих потоки данных между процессами и носителями данных;

- специальных символов, используемых для облегчения написания и чтения схемы.

Символы данных предшествуют и следуют за символами процесса. Схема данных предшествует и следует за символами данных.

Схема программы отображает последовательность операций в программе.

Схема программ состоит из:

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

- линейных символов, указывающих поток управления;

- специальных символов, используемых для облегчения написания и чтения схемы.

Схема работы системы отображает управление операциями и поток данных в системе.

Схема работы состоит из:

- символов данных, указывающих на наличие данных (могут указывать вид носителя данных);

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

- линейных символов, указывающих потоки данных между процессами и носителями данных, а также поток управления между процессами;

- специальных символов, используемых для облегчения написания, чтения блок-схемы.

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

Схема взаимодействия программ состоит из:

- символов данных, указывающих на наличие данных;

- символов процесса, указывающих операции, которые следует выполнить над данными;

- линейных символов, отображающих поток между процессами и данными, а также инициации процессов;

- специальных символов, используемых для облегчения написания и чтения схемы.

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

Схема ресурсов системы состоит из:

- символов данных, отображающих входные, выходные и запоминающие устройства вычислительной машины;

- символов процесса, отображающих процессы;

- линейных символов, отображающих передачу данных между устройствами ввода-вывода и процессорами, а также передачу управления между процессорами;

- специальных символов, используемых для облегчения написания и чтения схемы.

Для иллюстрирования разрабатываемых проектов в настоящее время предназначается Универсальный язык моделирования (UML). Наиболее важным средством UML является набор различных видов диаграмм.

Чертежи выполняют на листах бумаги определённого формата в соот­ветствии с ГОСТ 2.301, который устанавливает форматы листов чертежей и других документов, предусмотренных стандартами на конструкторскую документацию всех отраслей промышленности и строительства, основная надпись в которых выполняется по форме 1 ГОСТ 2.104.

Форматы листов определяются размерами внешней рамки (выполненной тонкой линией) оригиналов, подлинников, дубликатов, копий, в соответствии с рисунком 1.

Формат с размерами сторон 1189Х841 мм, площадь которого равна 1 м², и другие форматы, полученные путём последовательного деления его на две равные части параллельно меньшей стороне соответствующего формата, принимаются за основные.

22 5

5 Внешняя рамка

Рисунок 5 – Формат размеров графической части

Основные надписи графических учебных документов должны соответствовать формам 1 и 2а ГОСТ 2.104–2006, при этом:

1 в графе 2 записывается обозначение документа в соответствии со стандартом учебного заведения;

2 в графе 4 записывается обозначение «У» – учебный;

3 в графе 9 заполняются две строки:

3.1 в первой строке указывается наименование учреждения образования. Для УО «Гомельский государственный машиностроительный колледж» аббревиатурой «ГГМК» и номер учебной группы (например: Пк – 42);

3.2 во второй строке записывается номер специальности или специализации в зависимости от принадлежности дисциплины, для которой разрабатывается документ;

3.3 остальные графы заполняются в соответствии с ГОСТ 2.104–68.

					ДП 12345.02.00.000
					Диаграмма вариантов использования	Литера	Масса	Масштаб
Изм	Лист	№ докум	Подп.	Дата		У
				Лист 1	Лист 1
					ГГМК; Пк-41 2-40 01 01 31

Документооборот - движение документов в организации с момента их получения или создания до завершения исполнения или отправки (сдачи в архив). Документы являются основными носителями информации на предприятии.

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

Рисунок 6 – Пример схемы документооборота

Рекомендации по разработке диаграмм вариантов использования

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

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

1. Определить главных (первичных) и второстепенных актеров.

2. Определить цели главных актеров по отношению к системе.

3. Сформулировать базовые (стратегические) варианты использования.

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

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

6. Выделить участников, интересы, предусловия и постусловия выбранного варианта использования.

7. Написать успешный сценарий выполнения выбранного варианта использования.

8. Определить исключения (неуспех) в сценарии варианта использования.

9. Написать сценарии для всех исключений.

10. Выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом <<include>>.

11. Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом <<extend>>.

12. Проверить диаграмму на отсутствие дублирования вариантов использования и актеров.

Рисунок 7 – Исходная диаграмма вариантов использования для примера разработки системы продажи товаров по каталогу

Рисунок 8 – Структурные элементы диаграммы вариантов использования

Рекомендации по построению диаграмм классов

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

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

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

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

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

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

Рисунок 9 – Пример диаграммы классов

Дата добавления: 2017-01-13