Методология RAD – быстрой разработки приложений

Вопросы для экзамена по дисциплине

«Информационные системы и технологии» - 3 курс

1. Как конструктивно определить архитектуру ИС. Опишите процесс разработки ИС.

 

Для того чтобы конструктивно определить архитектуру ИС, необходимо ответить на ряд вопросов:

Что делает система?

На какие составные часть она разделена?

Каким образом происходит взаимодействие этих частей?

Как и где эти части размещены?

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

 

Процесс разработки ИС - процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла ИС.

Модели:

организации,

деятельности организации,

требований к ИС,

проекта ИС,

требований к приложениям и т.д

 

2. Технология проектирования RUP.

 

 

 

Среди всех фирм-производителей CASE-средств компания IBM Rational Software Corp одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем.

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

Эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML, как базовая нотация визуального моделирования.

 

Rational Unified Process (RUP) - одна из самых популярных технологий.

В определенном плане эта методология становится международным стандартом. Авторами UML считаются сотрудники этой фирмы Rational Software: Гради Буч, Айвар Якобсон, Джемс Рамбо.

RUP полностью соответствует стандартам, определяющим проектные работы в процессе жизненного цикла информационных систем. В методологии RUP реализуются следующие подходы:

1. Итерационный и инкрементный (наращиваемый).

2. Построение системы на базе архитектуры информационной системы.

3. Планирование и управление проектом на основе функциональных требований к информационной системе.

 

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

Заканчиваются итерации созданием работающей информационной подсистемы.

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

Создаваемая информационная система постепенно растет и совершенствуется.

 

 

3. Методология проектирования SADT.

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

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

Методология SADT (Structured Analysis and Design Technique - методология структурного анализа проектирования), разработанная Дугласом Т. Россом в 1969-1973 годах базируется на структурном анализе систем и графическом представление организации в виде системы функций, которые имеют три класса структурных моделей:

1. Функциональная модель.

2. Информационная модель.

3. Динамическая модель.

Процесс моделирования по методологии SADT состоит из следующих этапов:

1. Сбор информации и анализ информации о предметной области.

2. Документирование полученной информации.

3. Моделирование IDEF.

4. Корректура модели в процессе итеративного рецензирования.

Методология моделирования IDEF, использует формализованный процесс моделирования информационных систем и имеет следующие стадии:

Ø анализ,

Ø проектирование,

Ø реализация,

Ø объединение,

Ø тестирование,

Ø установка,

Ø функционирование.

 

4. Стандарты моделирования IDEF.

 

Ø IDEF0 - методология функционального моделирования. Система отображается в виде набора взаимосвязанных функциональных блоков.

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

Ø IDEF1X – методология построения реляционных структур.

Ø IDEF3 – методология документирования процессов. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса.

Ø IDEF4 – методология построения объектно-ориентированных систем.

 

5. Методология проектирования RAD.

Методология RAD – быстрой   разработки приложений

Принципы RAD сформулированы в 1980 году сотрудником компании IBM Джеймсом Мартином.

В настоящее время методология RAD стала общепринятой схемой для проектирования разработки информационных систем. Средства разработки, основанные на RAD, очень популярны за счет использования таких программных сред разработки: IBM Lotus Domino Designer, Borland Delphi, Borland C++ Builder, Microsoft Visual Studio, Macromedia Flash и др.

• Данная методология охватывает все этапы жизненного цикла современных информационных систем.

• Методология RAD — это комплекс специальных инструментальных средств, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений

• Ограничения методологии RAD. Ее применение наиболее эффективно при создании сравнительно небольших систем, разрабатываемых для конкретного заказчика.

• Методология RAD не подходит для создания сложных расчетных программ, операционных систем и программ управления сложными инженерно-техническими объектами; для разработки приложений, в которых интерфейс пользователя является вторичным, т.е. отсутствует наглядное определение логики работы системы (приложения реального времени, драйверы или службы); для разработки систем, от которых зависит безопасность людей, например систем управления транспортом или атомными электростанциями.

Методология RAD имеет следующие стадии:

1. Моделирование информационных потоков между бизнес-функциями.

2. Моделирование данных.

3. Преобразование объектов данных, обеспечивающих реализацию бизнес-функций.

4. Генерация (сборка) приложений.

5. Тестирование и объединение.

Особенности использования методологии RAD:

Ø Для больших информационных систем требуется большой коллектив высококвалифицированных разработчиков (большой бюджет проекта).

Ø Применима при уверенном знании целевого бизнеса и необходимости срочного производства системы в течении 2-3 месяцев..

 

 

6.  Понятие фреймворка.

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

Фреймворки и паттерны имеют много общего: это подходы к повторному использованию кода.

Различие: фреймворк - это реализация системы паттернов проектирования. Фреймворк - исполняемая программа, паттерн – знание и опыт как решать конкретную задачу.

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

Фреймворки можно классифицировать по месту применения в системе, по способу использования и масштабу применения.

 

7. Классификация фреймворков по месту применения.

1. Инфраструктурные фреймворки упрощают процесс разработки инфраструктурных элементов, применяются внутри организации и не продаются.

2. Фреймворки уровня промежуточного программного обеспечения применяются для встраивания (интеграции) приложений и компонентов.

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

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

 

8. Классификация фреймворков по способу использования.

 

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

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

3. На практике применяют подход серого ящика, являющийся комбинацией обоих подходов.

 

 

9. Классификация фреймворков по масштабу применения.

1. Фреймворки уровня приложений предоставляют функционал по реализации типовых приложений (GUI, базы данных и т.д.).

2. Фреймворки уровня домена применяются для создания приложений в определённой предметной области.

3. Вспомогательные фреймворки применяются для решения частных задач.

 

 

10. Фреймворк Захмана.

Фреймворк Захмана является одним из самых старых архитектурных фреймворков.

Он был создан сотрудником компании IBM Джоном Захманом.

Захман заложил в основу своего фреймворка классификацию (таксономию) артефактов системы.

Среди них можно выделить данные, функциональность, модели, спецификации и документы.

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

Для построения таксономии Захманом предложено ответить на шесть вопросов о функционировании организации: что, как, где, кто, почему.

Данные вопросы относятся к следующим аспектам системы:

• используемые данные (что?);

• процессы и функции (как?);

• места выполнения процессов (где?);

• организации и персоналии (кто?);

• управляющие события (когда?);

• цели и ограничения, определяющие работу

системы (почему?).

Отвечать на эти вопросы необходимо с различной степенью детализации. Описано шесть уровней:

1. уровень контекста;

2. уровень бизнес-описаний;

3. системный уровень;

4. технологический уровень;

5. технический уровень;

6. уровень реальной системы.

Применительно к каждому уровню детализации существует своё заинтересованное лицо, то есть точка зрения:

1. аналитики (уровень контекста);

2. топ-менеджеры (уровень бизнесописаний);

3. архитекторы (системный уровень);

4. разработчики (технологический уровень);

5. администраторы (технический уровень);

6. пользователи (уровень реальной системы).

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

1. Колонки можно менять местами, но нельзя добавлять и удалять.

2. Каждой колонке соответствует собственная модель.

3. Каждая из моделей, соответствующих столбцов, должная быть уникальна.

4. Каждый уровень (строка) представляет собой описание системы с точки зрения группы пользователей (представляет отдельный вид).

5. Каждая из ячеек уникальна.

6. Каждая ячейка содержит описание аспекта реализации системы в виде модели и текстового документа.

7. Заполнение ячеек должно производиться последовательно сверху вниз.

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

Вторая строка описывает функционирование организации в бизнес-терминах.

Третья строка описывает бизнес-процессы в терминах информационных систем.

Четвёртая строка позволяется распределить данные и выполняемые над ними операции по конкретным аппаратным и программным платформам.

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

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

    Столбец используемые данные, в соответствии с

  уровнями, содержит в своих ячейках следующие арте-

   факты:

    1 уровень – список основных сущностей;

   2 уровень – семантическая модель;

   3 уровень – нормализованная модель;

  4 уровень – физическая модель данных или иерархия классов;

  5 уровень – описание модели на языке управления данными;

6 уровень – фактические наборы данных, статистики и т.д.

Столбец процессы и функции описывает порядок

действий для детализации процесса перехода от миссии

организации к описанию конкретных операций:

1 уровень – перечисление ключевых бизнес-процессов;

2 уровень – описание бизнес-процессов;

3 уровень – описание операций над данными и архитектуры приложений;

4 уровень – методы классов;

5 уровень – программный код;

6 уровень – исполняемые модули.

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

Столбец места выполнения процессов определяет

расположение компонент системы и сетевую инфраструктуру:

1 уровень – расположение основных объектов;

2 уровень – модель взаимодействия объектов;

3 уровень – распределение компонентов информационной системы по узлам сети;

4 уровень – физическая реализация на аппаратных и программных платформах;

5 уровень – используемые протоколы и спецификации каналов связи;

6 – описание функционирования сети.

Столбец организации и персоналии определяет участников процесса функционирования:

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

2 уровень – полная организационная диаграмма (могут присутствовать требования к информационной безопасности);

3 уровень – участники бизнес-процессов и их роли;

4 уровень – требования к пользовательским интерфейсам;

5 уровень – правила доступа к объектам;

6 уровень – физическая реализация в коде.

Столбец управляющее событие определяет

временные параметры системы и бизнес-процессов:

1 уровень – список значимых для системы событий;

2 уровень – базовый график работ;

3 уровень – модели работы с событиями;

4 уровень – алгоритмы обработки событий;

5 уровень – программная реализация;

6 уровень – история функционирования системы.

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

1 уровень – бизнес-стратегия;

2 уровень – дерево целей и бизнес-план;

3 уровень – правила и ограничения для бизнес-процессов;

4 уровень – приложения, включаемые в состав системы;

5 уровень – алгоритмы работы приложений;

6 уровень – физическая реализация в коде.

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

Данный фреймворк распространяется на коммерческой основе.

 

 

11. Фреймворк TOGAF.

Фреймворк TOGAF (The Open Group ArchitectureFramework) представляет собой набор средств для разработки архитектур различного назначения.

С его помощью информационная система описывается как совокупность модулей.

В рамках TOGAF даётся особенное определение архитектуры – «формальное описание системы, или детальный план системы на уровне компонентов и методологии их реализации».

Общепринятое же определение архитектуры (в соответствии со стандартом ANSI/IEEE 1471-2000) определяется как «описание организации системы в терминах компонентов, их взаимосвязей между собой и с окружающей средой и принципы управления их разработкой и развитием».