Методология и технологии проектирования АИС

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

Рис. 1.4. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

технология должна поддерживать полный ЖЦ ПО;

технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

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

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

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

технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.

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

стандарт проектирования;

стандарт оформления проектной документации;

стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

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

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

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

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

требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

правила использования клавиатуры и мыши;

правила оформления текстов помощи;

перечень стандартных сообщений;

правила обработки реакции пользователя.

 

9. Методы проектирования АИС

Целью анализа требований является трансформация функциональных требований к ПО в предварительный системный проект и создание стабильной основы архитектуры системы. В процессе проектирования системный проект "погружается" в среду реализации с учетом всех нефункциональных требований.

Все современные ТС ПО реализуют ту или иную методику анализа и проектирования ПО. Одна из типичных методик ООАП реализована в технологии RAD. Согласно этой методике, объектно-ориентированный анализ включает два вида деятельности: архитектурный анализ и анализ вариантов использования. Архитектурный анализ выполняется архитектором системы и включает в себя:

· утверждение общих стандартов (соглашений) моделирования и документирования системы;

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

· формирование набора основных абстракций предметной области (классов анализа);

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

Анализ вариантов использования выполняется проектировщиками и включает в себя:

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

· распределение поведения, реализуемого вариантом использования, между классами (определение обязанностей классов);

· определение атрибутов и ассоциаций классов.

В потоках событий варианта использования выявляются классы трех типов:

· Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

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

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

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

Наиболее важной частью объектно-ориентированного анализа является распределение обязанностей между классами (в виде операций классов). Оно выполняется с помощью диаграмм взаимодействия. При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов [14].

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

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

Объектно-ориентированное проектирование включает два вида деятельности:

· проектирование архитектуры системы;

· проектирование элементов системы.

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

· идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;

· анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

· формирование архитектурных уровней;

· проектирование конфигурации системы.

Проектирование элементов системы включает в себя:

· проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);

· проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД - объектной или реляционной).