Описание процессов/прецеденты.



Прецедент – это описание происходящих в предметной области. Он позволяет формировать требования к ИС.

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

Прецеденты бывают:

- верхнего уровня или бизнес – прецеденты.

- развернутые прецеденты.

Прецеденты высокого уровня описывают наиболее важные глобальные процессы объекта (2-3 предложения).

Развернутые – подробное описание, включает типичный ход событий.

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

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

Для формирования прецедентов необходимо иметь описание:

1. название

2. исполнители

3. тип прецедента

4. описание прецедента

Выбор границы системы определяется целями исследования. Если рассматриваются проблемы изменения стратегии ОУ, т.е повышение конкурентоспособности, то рассматривается вариант 2. После определения границ системы осуществляется ранжирование прецедентов.

Выделяют 3 типа прецедентов:

1. Основные, описывающие общие процессы (покупка товара).

2. Вторичные, описывают уточняющие редкие процессы (запрос на ассортимент товара).

3. Дополнительные, описывающие процессы не реализуемые в системе.

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

- четко моделировать предметную область.

- осуществлять взаимосвязи между субъектами на едином языке.

Этапы та стадии SSADM.

SSADM регламентирует и поддерживает все этапы ЖЦ ИС.

Входом в технологию являются документы, инициирующие проект, а выходом являются проектные решения.

Структура ЖЦ ИС в SSADM реализуется каскадной моделью.

В SSADM выделяют 5 этапов проектирования и 7 стадий.

К – концепция

ТЭО – технико-экономическое обоснование

КП – каталог пользователей

КТ – каталог требований

КЗ – каталог задач

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

2 – выбор вариантов автоматизации

3 – ТЗ

4 – выбор вариантов технической реализации

5 – логический проект

6 – физический проект

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

Основной задачей анализа реализуемости является разработка ТЭО.

Анализ требований реализует 2 стадии: предпроектное обследование и выбор вариантов автоматизации.

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

- определение границ исследования;

- изучение существующих информационных потоков и системы обработки данных;

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

- обобщение результатов.

Итерационный процесс RUP.

Rational Unified Process — это:

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

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

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

Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.

IBM Rational Unified Process — процесс, управляемый на основе прецедентов. Это означает, что в качестве метода описания функциональных требований к системе, а также в качестве естественной единицы для дальнейшего планирования и оценки выполнения работ используются сценарии использования. Сценарии использования позволяют легко выявлять реальные потребности будущих пользователей системы и отслеживать полноту описания этих требований. Они гарантируют выполнения требований заказчика к ПС. Кроме того, использование завершенных сценариев в качестве единицы измерения прогресса помогает избежать неадекватной оценки степени выполнения проекта исполнителем.

IBM Rational Unified Process предполагает разработку, реализацию и тестирование архитектуры на самых ранних стадиях выполнения проекта. Такой подход позволяет устранять самые опасные риски, связанные с архитектурой, на ранних стадиях разработки. Благодаря ему удается избежать существенных переработок в последний момент, если вдруг выяснится, что выбранное решение не обеспечивает, к примеру, выполнение требований к производительности системы.

Моделирование классов UML

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

                   ДК иллюстрирует спецификацию программных классов и интерфейсов в приложении.

                   На ДК выносится:

1.Классы, ассоциации и атрибуты

2.Интерфейсы с операциями и константами

3.Методы (операции)

4.Информацияя о типах атрибутов

5.Способы навигации

6.Зависимости

                   Для построения диаграммы необходимо выполнить работы по след. этапам:

1.Проанализировать диагр. взаимодействий и определить все классы, задействованные в конкретном проектном решении

2.Перенесение на д-му классов атрибуты, соответствующие понятиям из концептуальной модели (КМ)

3.Добавить имена методов на основе д-мы взаимодействия

4.Добавить информацию о типах атрибутов и методах.

                   Некоторые понятия из КМ (кассир, менеджер, товар) на ДК отсутствуют, т.к. на данной итерации нет необходимости разрабатывать их программное описание.

                   На последующих итерациях при появлении новых требований и новых прецедентов они вносятся в ДК.Определениее методов для каждого класса осуществляется на основании диаграммы кооперации. Например: если сообщение make line iteаm передается классу sale (говорят о методах), то в этом классе должен быть метод make line iteаm.

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

                   Если генерация кода осуществляется автоматически case-средством, то должна быть полная информация.

5. На д-ме классов ассоциации указываются стрелками (навигациями). Информация о навигации связана с видимостью объектов.

Модели SSADM.

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

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

Под моделью в SSADM понимается процесс описания проектирования ИС от инициирующего документа до получения проектных решений.

Выделяют 5 модулей ЖЦ ИС:

АР (анализ реализуемости),

АТ(анализ требований),

СТ(спецификация требований),

СЛС(спецификация логической стр-ры),

ФП(физическое проектирование).

Диаграмма состояний.

Модель взаимодействий (interaction model) является источником детализированной спецификации прецедента. Модель состояний (statechart model) служит детализированным описанием класса, т.е. описание динамического изменения состояний классов.

Состояние (state) объекта обозначается текущими значениями его атрибутов. Модель состояний (statechart model) фиксирует "жизненный путь" класса.

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

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

Изменение состояний объекта осуществляется по схеме событие / условие / действие.

Событие может быть защищено ограждающим условием.

Действие (action) - короткое вычисление, выполняемое при срабатывании перехода. Действие — это отклик объекта на обнаруженное событие.

Состояние может состоять из вложенных (nested state). Составное состояние (composite state) является абстрактным. Переход может сработать от любого из вложенных состояний. Это делает диаграмму более ясной и лаконичной.


Дата добавления: 2018-02-15; просмотров: 1309; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!