Логическое моделирование

CASE – технологии

Логическое моделирование – исходя из логики приложения любой результат ЛМ – субъективен, ориентирован на конкретного пользователя.

В основе любой модели лежит классификация

BPMP (Business Process Modeling Programming)

case – система, имеет связь в DELPHI

Классы:

Процесс

Накопитель (реальное физ. явление, место)

Поток (между накопителями организовываются потоки)

Абонент (то что есть при выполнении данного процесса; не идентифицируются)

С помощью только этих 4 классов можно смоделировать бизнес-процесс. Для объектов класса определяются компоненты, дается поле и инструментальная панель с этими компонентами. Т.е. на логич. уровне можно оперировать бизнес-процессом.

Чтобы автоматизировать процесс, case-технология предусматревает 4 осн. этапа:

1. моделирование процессов
2. моделирование сущностей – связей (ER – моделирование): на модель накладывается смысловое содержание взаимодействующих ресурсов

- простая аннотация Чена: описывается одна связь между 2-мя сущностями

- единица моделирования – одна сущность и все её связи

Все системы используют протоколы диаграммы сущностей – связей

1. Проктирование БД

В накопителе указываются мин. список атрибутов. Объектный подход к содержимому накопителя. Дальше автоматически генерируется script – последовательность SQL –команд, которые и формируют таблицы БД.

4. Разработка форм

- формы ввода данных. Необходимо оптимизировать ввод данных

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

- пользовательские формы (свободные): запрещено организовывать ввод и коррекцию данных

- формы, которые определяются типом приложения

5. Отладка, тестирование, обновление, разработка новых версий.

1976 г. – начало case – технологии, Питер Чен опубликовал свою работу (семант. модель)

Основное назначение case – технологии анализ и оптимизация БД и SQL – серверов.

Принципы унифицированного процесса разработки для проектирования АСОИУ. Основные виды моделей процесса разработки. Язык визуального моделирования UML. CASE-системы для автоматизации процесса разработки.

Источник: Филипп Крачтен «Введение в Rational Unified Process»

Rational Unified Process как технология

Rational Unified Process - это процесс разработки программного обеспечения.

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

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

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

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

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

■ Rational Unified Process - это управляемый процесс. Итерационный подход предполагает управление требованиями и управление изменениями, чтобы по всем пунктам вовремя гарантировать общее понимание ожидаемых функциональных возможностей, ожидаемый уровень качества и гарантировать наилучшее управление связанными затратами и графиками выполнения.

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

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

■ Действия при выполнении Rational Unified Process управляются прецедентами. Понятия прецедентов и сценария управляют технологическим маршрутом от делового моделирования и требований до испытаний, и обеспечивают связанные и доступные для анализа маршруты разработки и поставки системы.

■ Rational Unified Process поддерживает объектно-ориентированную технологию. Некоторые из моделей являются объектно-ориентированными моделями, которые базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), используют Унифицированный язык моделирования (UML) как общую систему обозначений.

■ Rational Unified Process поддерживает компонентно-ориентированное программирование.

Компоненты - это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть смонтированы в строго очерченной архитектуре, специальной или некоторой общедоступной инфраструктуре компонентов, типа Internet, CORBA, COM/DCOM, для которых появляется индустрия многократно используемых компонентов.

■ Rational Unified Process - это процесс с перестраиваемой конфигурацией. Никакой одиночный процесс не подходит для всех случаев разработки программного обеспечения.

Прецеденты

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

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

Подойдя к банкомату, клиент может, например, снять деньги со счета, добавить деньги на счет

или проверить состояние счета. Эти действия соответствуют потокам событий в системе,

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

Объекты

Объект - это абстракция чего-либо в прикладной области или в выполняемой системе. Вы помните, что объектами могут быть, например, счет в банковской системе или служащий в системе управления персоналом.