Раздел: Документация
0 ... 76 77 78 79 80 81 82 ... 96 системе и ее частям, но эти проверки - к общей пользе. Так же как и контроль, которому подвергают деятельность его самого в независимых экспертизах качества. Решение проблемы по устранению искажений в первую очередь связано с организацией коллектива «строителей АС», сбалансированного по функциям участников. А во вторую очередь в построении системы профессиональных отношений, при которых неизбежные искажения отдельных участников проекта органично, хотя и не без труда, будут исправляться. Затем на эти отношения можно будет «навешивать» ту или иную методику проектирования АС, выбирать инструменты моделирования или отказываться от них. Исходные требования к автоматизированной системе всегда противоречивы, часть из них будет отвергаться кем-то из участников проекта. Но никому из них не стоит «тянуть одеяло на себя», ведь пройдет время - несколько месяцев или лет - и спорное требование будет реализовано, пусть другими людьми, частично или в иной форме. 3.4.6. Типовые подходы и типичные проблемы Методология построения АС содержит три основные составляющие. •Набор моделей (если строго, то типов моделей) для описания требований к АС, проектных и программных решений. Каждая модель обычно содержит средства для определения конструкций (нотацию) и правила их использования (синтаксис). •Методика применения набора моделей для построения АС обычно использует фиксированный набор моделей и определяет последовательность их построения для описания различных аспектов создаваемой автоматизированной системы. •Процесс организации проектных работ включает различные технологии - планирования, управления проектом, контроля качества и т.д. Каждый проект можно рассматривать как реализацию конкретного процесса применения методики. В зависимости от ограничений по срокам и стоимости в конкретную реализацию могут быть включены лишь отдельные части полной методики и процесса. Методики описания АС обычно относят к одному из двух типов: структурному или объектному. Правильнее было бы говорить о структурном и объектном наборах моделей, так как существуют методики построения одних и тех же моделей с несовместимыми синтаксическими правилами. Структурная методика обычно предполагает наличие пяти компонентов. •Диаграмма потоков данных/модель технических - процессов (Data Flow Diagram/Business Process Model) была предложена в конце 1970-х годов как средство описания процессов обработки информации. Основные элементы модели: процесс, поток и хранилище, представляющие соответственно обработку, передачу и хранение данных (или материальных объектов). Контекст работы автоматизированной системы представлен с помощью внешних сущностей. В настоящее время эту модель используют в основном для описания технических процессов (производственной деятельности). •Диаграмма «сущность - связь» (Entity Relationship Diagram) была предложена в середине 1970-х годов как средство описания информационной модели предметной области, не привязанное к инструментам реализации структур хранения данных в автоматизированной системе. Элементы модели: сущность и связь, представляющие типы объектов предметной области и их отношения. •Диаграмма переходов состояний (State Transition Diagram) в основном используется для моделирования автоматизированных систем реального времени. Основными элементами модели являются состояние (объекта или системы) и переход из одного состояния в другое. Можно использовать эту диаграмму для документирования состояний как программных конструкций (экранов, каналов связи), так и объектов реального мира (выполняемых заказов, производимой продукции). •Структурная карта (Structure Chart) показывает, как программные модули (функции) вызывают друг друга в процессе выполнения программы. Основные элементы - программный модуль и вызов. Для вызова могут быть указаны передаваемые и возвращаемые параметры. Также существуют обозначения вызова в цикле, условного вызова и лексического включения модулей. Структурная карта служит основной моделью для описания структуры программного кода на универсальных языках программирования третьего поколения. •Структурные схемы (Flow Chart) содержит вычислительные блоки, используемые дисциплиной структурного программирования. Описывает алгоритмы выполнения процедур. Структурную методику характеризует раздельное построение модели функций (чаще всего диаграммы потоков данных) и модели данных (чаще всего диаграммы «сущность - связь»). К сожалению, авторам различных «школ» так и не удалось договориться об единой нотации и правилах построения этих моделей. Поэтому большинство CASE-систем, обеспечивающих построение моделей согласно структурной методике, являются закрытыми и несовместимыми с другими аналогичными системами. Не удалось также сформировать общепринятый стандарт передачи информации между CASE-репози-тариями. Невозможность переноса моделей между инструментами разных производителей служит препятствием к внедрению технологий повторного использования изделий, созданию библиотек стандартных решений для разных видов деятельности, интеграции средств моделирования со средствами планирования, управления проектами, тестированием и т.д. Объектная методика базируется иа следующих шести компонентах: •Диаграмма вариантов использования (Use Case Diagram) перечисляет требования, которые должна обеспечить система (информационная или производственная). Основные элементы модели - роли (пользователи системы) и вариант использования автоматизированной системы (предоставляемый сервис). Если речь идет о программном обеспечении, то варианты использования с некоторым приближением можно считать автоматизируемыми операциями. •Диаграмма взаимодействия (Interaction Diagram) описывает порядок взаимодействия участников (объектов) в процессе реализации варианта использования системы. Существует две разновидности диаграмм взаимодействия - диаграмма последовательности (Sequence Diagram) и диаграмма сотрудничества (Collaboration Diagram). Эти диаграммы фактически представляют одну и ту же информацию в разном виде и часто могут быть автоматически получены друг из друга в объектных CASE-системах. Диаграмма взаимодействия вместе с диаграммой вариантов использования применяется при описании как программных, так и производственных систем. •Диаграмма классов (Class Diagram) является основной моделью объектной методики. В некотором смысле ее можно считать развитием диаграммы «сущность - связь». Классы также представляют сущности описываемой автоматизированной системы (программной или производственной), но обладают дополнительными свойствами - поведением, абстрактностью, стереотипом. Связи между классами также значительно богаче, имеется наследование свойств, агрегация, реализация и многое другое. Основное применение модели классов - описание программного обеспечения, хотя эта модель подходит и для описания производственных систем. •Диаграмма состояний (Statechart Diagram) немного модифицированная диаграмма переходов состояний. Служит для 0 ... 76 77 78 79 80 81 82 ... 96
|
