Методики описания

SADT (Structured Analysis and Design Technique) — методология структурного анализа и проектирования, интегрирует процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых ср-в и руководство проектом со своим графическим языком. Этапы: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Процесс хорошо отлажен, т.к. при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией.

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

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

1. Получение знаний в процессе опроса – SADT предлагает использовать различные ее источники (читать документы, опрашивать людей, наблюдать за работой системы). Д.б. конкретная цель: должны определить потребности в инф-ии прежде, чем выбрать очередной источник.

2. Документирование полученных знаний – с помощью спец. метода детализации ограниченного субъекта. Автор сначала анализирует объекты, входящие в систему, а затем использует полученные знания д/анализа ф-ий системы. Итог: диаграмма, в которой объединяются сходные объекты и функции.

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

4. Координация процесса рецензирования. Необходим наблюдатель за процессом рецензирования (библиотекарь).

5. Модели используются после их одобрения. Цель (диаграмма А-0) определяет, как будет использоваться модель. Т.о., как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели.

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

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

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

Виды диаграмм:

Типы диаграмм UML:

Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

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

Диаграмма развёртывания (Deployment diagram) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

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

Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

Диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.

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

Диаграммы коммуникации и последовательности.

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

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) — диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

Диаграмма сотрудничества (Collaboration diagram)— Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

RUP (Rational Unified Process) – методология разработки ПО. Принципы:

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

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

1. Начало (Inception)

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

При завершении оценивается достижение вехи целей ЖЦ, которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration) – анализ предметной области, построение исполняемой архитектуры.

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

Итог: достижение вехи архитектуры ЖЦ.

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

Внедрение (Transition) – финальная версия продукта, передача от разработчика к заказчику. Программа бета-тестирования, обучение пользователей, определение качества продукта. Если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется. Итог: веха готового продукта и завершение полного цикла разработки.

В методологии ARIS (Architecture of Integrated Information Systems) для описания различных подсистем организации используется более ста типов моделей, отражающих различные аспекты деятельности и реализующих различные методы моделирования ,в том числе событийная цепочка процесса EPC (Event driven Process Chain), модель «сущность-связь» ERM (Entity Relationship Model), модели методики объектно-ориентированного моделирования OMT (Object Modeling Technique), модели BSC (Balanced Scorecard – система сбалансированных показателей), модели UML и многие другие. Все многообразие типов моделей ARIS подразделяется на пять видов описания в соответствии с основными подсистемами предприятия: организационной, функциональной, подсистемами данных, процессов и продуктов/услуг (остальные подсистемы могут моделироваться с использованием типов объектов, входящих в перечисленные виды описания). В свою очередь типы моделей внутри каждого вида описания подразделяются на три уровня в соответствии с этапами жизненного цикла КИС: определение требований к системе, спецификация проекта и описание реализации. Такая концепция обеспечивает целостное описание системы управления бизнесом, вплоть до ее технической реализации. Взаимосвязь моделей различных типов, образующих модель деятельности организации, обеспечивается за счет использования декомпозиции, а также применения принципа множественности экземпляров структурных объектов ARIS, представленных на моделях разных типов (определение объекта в репозитории ARIS всегда единственно).

Кроме того, в ARIS предусмотрена возможность создания сценариев автоматизации составления различных аналитических отчётов, нормативных документов, новых моделей. Каждый сценарий представляет собой подпрограмму, запускаемую в ARIS Business Architect (либо Toolset - более ранней версии) или непосредственно на сервере ARIS. Сценарии пишутся на специальном языке программирования — SAX Basic. Для автоматизированного формирования того или иного отчёта в ARIS сценарии оперируют данными из базы моделей, вычленяя из неё конкретные объекты и модели.

Типы моделей методологии Aris:

Как правило, в основе описания бизнес-процессов лежат цепочки процессов. Цепочки могут описаны как диаграммой VAD, которая рассматривает процесс со стратегических точек зрения и детальные диаграммы eEPC (от Extended Process Chain - расширенная цепочка процесса). eEPC-диаграммы являются стержнем, который описывает ход каждого процесса на предприятии (конечно, когда рассматривается процессный аспект деятельности).

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

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

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

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

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

ARIS (Architecture of Integrated Information Systems). Точки зрения:

Организационная структура,
Функциональная структура,
Структура данных,
Структура процессов.

Подуровни: описание требований, описание спецификации, описание внедрения.

Возможные методы описания:

EPC (event-driven process chain) – метод описания процессов (система SAP R/3);
ERM (Entity Relationship Model) – модель сущность-связь д/описания структуры данных;
UML (Unified Modeling Language) – объектно-ориентированный язык моделирования.

Скрипт — это инструмент ARIS, с помощью которого автоматизируется составление различных аналитических отчётов, нормативных документов, новых моделей. Подпрограмма, запускаемая в ARIS Toolset или непосредственно на сервере ARIS. Пишутся на спец. языке программирования (SAX Basic). ARIS Script позволяет в автоматическом режиме производить:

Формирование нормативных документов на основании моделей ARIS (паспорт процесса, регламент процесса и т. п.).
Формирование аналитических отчётов на основании моделей ARIS.
Интеграция ARIS Toolset с другими приложениями и базами данных.
Формирование базы моделей ARIS на основании готовых спецификаций.

Методики описания