Архитектура информационных систем

Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

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

* приемлемый уровень отдачи от инвестиций в CASE-средства.

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

* улучшение коммуникации между пользователями и разработчиками.

36. Средства, реализующие CASE-технологии

Выделяют следующие группы CASE средств:

* CASE средства верхнего уровня. Эти CASE средства ориентированы на начальные этапы построения информационной системы. Они связаны с анализом и планированием. CASE средства верхнего уровня обеспечивают стратегическое планирование, расстановку целей, задач и приоритетов, а также графическое представление необходимой информации. Все CASE средства верхнего уровня содержат графические инструменты построения диаграмм, таких как диаграммы сущность-связь (ER диаграммы), диаграммы потока данных (DFD), структурные схемы, деревья решений и пр.

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

* Интегрированные CASE средства (I - CASE). Эти CASE средства охватывают полный жизненный цикл разработки информационной системы. Они позволяют обмениваться данными между инструментами верхнего и нижнего уровня и являются своего рода «мостом» между CASE средствами верхнего и нижнего уровней.Для моделирования и оптимизации бизнес-процессов применяются CASE средства верхнего уровня и интегрированные CASE средства. Они позволяют повысить качество моделей бизнес-процессов за счет автоматического контроля, дают возможность оценить ожидаемый результат, ускоряют процесс проектирования, обеспечивают возможности по изменению и обновлению моделей.

37. Характеристика современных CASE-средств

Основными характеристиками CASE средств, важными с точки зрения моделирования и оптимизации бизнес процессов, являются следующие:

* Наличие графического интерфейса. Для представления моделей процессов CASE средства должны обладать возможностью отображать процессы в виде схем. Схемы много проще в использовании, чем различные текстовые и числовые описания. Это позволяет получать легко управляемые компоненты модели, обладающие простой и ясной структурой.

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

* Гибкость применения. Эта характеристика дает возможность представлять бизнес-процессы в различных вариантах, важных с точки зрения анализа. CASE средства должны позволять проводить анализ процессов и создавать модели, сфокусированные на различных аспектах деятельности предприятия.

* Возможность коллективной работы. Анализ и моделирование процессов может требовать совместной работы нескольких человек. Для одновременной работы над моделями процессов CASE средства должны обеспечивать управление изменениями любыми фрагментами моделей и их модификацией при коллективном доступе.

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

* Построение отчетов. CASE средства должны обеспечивать построение отчетов по всем моделям процессов с учетом взаимосвязи элементов. Такие отчеты необходимы для анализа моделей и определения возможностей по оптимизации. За счет отчетов обеспечивается контроль полноты и достаточности моделей, уровень декомпозиции процессов, правильность синтаксиса диаграмм и типов применяемых элементов.

38. Моделирование информационных систем

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

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

39. Виды моделей

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

Структурная модель

Четкого определения структурной модели не существует. Так, под структурной моделью устройства могут подразумевать:

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

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

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

40. Объектно-ориентированный анализ и проектирование

Традиционная техника структурного анализа основана на потоках данных в системе. Объектно-ориентированный анализ (или OOA, objectoriented analysis) направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения. Таким образом: Объектно-ориентированный анализ -- это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области. Границы между стадиями анализа и проектирования размыты, но решаемые ими задачи определяются достаточно четко. В процессе анализа мы моделируем проблему, обнаруживая классы и объекты, которые составляют словарь проблемной области. При объектно-ориентированном проектировании мы изобретаем абстракции и механизмы, обеспечивающие поведение, требуемое моделью.

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

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

1. объектно-ориентированное проектирование основывается на объектно-ориентированной декомпозиции;

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

Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного; в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами. На этапе проектирования осуществляется преобразовании требований, изложенных в ТЗ, в детальные спецификации информационной системы.

41. Технологии, языки и средства моделирования

Диаграммы функционального моделирования SADTВ рамках развития методологии SADT было разработано несколько графических языков моделирования:

* Нотация IDEF0 -- для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем. (методология функционального моделирования)

IDEF0 -- это более четкое представление методики SADT. Описание объектов и процессов в SADT (IDEF0) выполняется в виде совокупности взаимосвязанных блоков Диаграмма потоков данных DFD (Data Flow Diagrams) -методология (стандарт) описания бизнес-процессов верхнего уровня или макропроцессов. На диаграммах потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ. Данные входы и выходы представляют из себя информационные, либо материальные потоки. При этом выходы одной работы могут являться входами для других.

42. Язык унифицированного моделирования UML

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

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

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

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

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

43. Диаграммы языка UML: структурные диаграммы, диаграммы, поведения, диаграммы взаимодействия.

ML (англ. Unified Modeling Language -- унифицированный язык моделирования) -- Объектно-ориентированный графический язык для визуализации, специфицирования, конструирования и документирования систем, где большая роль отводится описанию бизнес-процессов в информационных системах. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, которая называется UML моделью. UML был создан для определения, визуализации, проектирования и документирования по большей части программных систем.

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

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

2. Содержит механизмы расширения и специализации базовых концепций языка.

Преимущества UML

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

-UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

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

-UML получил широкое распространение и динамично развивается.

Инструментальные средства моделирования ИС.

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

- локальные, поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, S-Designor, “CASE. Аналитик”);

- малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);

- средние интегрированные средства моделирования, поддерживающие от 4 до 10-15 типов моделей и методов (Rational Rose, Paradigm Plus,

Designer/2000);

- крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

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

Малые интегрированные средства моделирования, как правило, “исторически выросли” из локальных. Так же, как и последние, они изначально не были ориентированы на комплексный анализ систем. Возможности по интеграции различных моделей в рамках общей модели появились в процессе совершенствования и развития этих программных средств. Характерными особенностями этой категории является наличие в инструментальном средстве независимых компонентов и интеграция моделей путем экспорта и импорта данных.

45. Применение UML при проектировании ИС

Основные типы UML-диаграмм, используемые в проектировании информационных систем. Взаимосвязи между диаграммами. Поддержка UML итеративного процесса проектирования ИС. Этапы проектирования ИС: моделирование бизнес-прецедентов, разработка модели бизнес-объектов, разработка концептуальной модели данных, разработка требований к системе, анализ требований и предварительное проектирование системы, разработка моделей базы данных и приложений, проектирование физической реализации системы.

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

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

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

Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) - это обобщенная модель функционирования системы в окружающей среде.

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) - модель бизнес-процесса или поведения системы в рамках прецедента. Диаграммы взаимодействия (interaction diagrams) - модель процесса обмена сообщениями между объектами, представляется в виде диаграммпоследовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).

Диаграммы состояний (statechart diagrams) - модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое. Диаграммы классов (class diagrams) - логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

Диаграммы базы данных (database diagrams) - модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п. Диаграммы компонентов (component diagrams) - модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

46. Методика разработки функциональных моделей в среде IDEF0

Совокупность схем (IDEF0-диаграмм) образует модель системы. Эта модель носит качественный, описательный, декларативный характер. Она принципиально не может ответить на вопросы о том, как протекают процессы во времени и в пространстве, каковы их характеристики, и в какой мере удовлетворяются требования, предъявляемые к системе. Все эти вопросы с неизбежностью возникают после того, как достигнут нижний уровень декомпозиции.

В этом случае рекомендуется переходить к другим моделям -математическим, имитационным моделям и др. По терминологии, принятой в исследовании операций, IDEF0 - модели относятся к классу концептуальных. Концептуальные модели являются основой построения математических моделей.

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

47. Информационное моделирование в методике IDEF1X

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

Основными элементами модели IDEF1X являются сущности, атрибуты и отношения.

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

* диаграмма "Сущность -- связь" (Entity Relationship Diagram -- ERD);

* модель данных, основанная на ключах (Key Based Model -- КВМ);

* полная атрибутивная модель (Fully Attributed Model -- FAM).

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

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

48. Средства разработки программного обеспечения ИС

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

Необходимые в конкретном случае средства разработки информационных систем определяются в зависимости от:

* целей и задач проектирования и разработки ИС;

* особенностей и параметров моделируемой предметной области;

* применяемой исполнителем методологии.

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

На выбор также могут повлиять:

* уникальность или стандартность проекта;

* итерационность процесса проектирования;

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

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

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

Основными средствами разработки ИС являются две категории продуктов:

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

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

49. Программные платформы, технологии программирования и инструментальные средства разработки

Среда разработки программного обеспечения (ПО) - совокупность программных средств, используемая программистами для разработки программного обеспечения. Простая среда разработки включает в себя редактор текста, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Когда эти компоненты собраны в единый программный комплекс, говорят об интегрированной среде разработки (Integrated development environment- IDE). Такая среда представлена одной программой, не выходя из которой можно производить весь цикл разработки.

В состав комплекса кроме перечисленных выше компонент могут входить средства управления проектами, система управления версиями, разнообразные инструменты для упрощения разработки интерфейса пользователя, стандартные заготовки («мастера»), упрощающие разработку стандартных задач, и др. Современные среды разработки, поддерживающие объектно-ориентированную разработку ПО, также включают браузер классов, инспектор объектов и диаграмму иерархии классов. Хотя существуют среды разработки, предназначенные для нескольких языков - такие как Eclipse или Microsoft Visual Studio, обычно среда разработки предназначается для одного определённого языка программирования. Если IDE включает в себя возможность визуального редактирования интерфейса программы, она называется средой визуальной разработки. Иногда достаточно использовать только одну интегрированную среду разработки, но для больших проектов в среду разработки включаются разнородные продукты разных фирм, разных версий. Пример такого набора: файловый менеджер, набор вспомогательных утилит и пакетных файлов,С++Builder - как IDE, PLSQL Developer - для работы с СУБД Oracle, Cristal Reports - для создания отчетов , StarTeam - для ведения версий и поддержки коллективной работы.

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

50. Интегрированные среды разработки

Интегрированная среда разработки, ИСР (англ. IDE, Integrated Development Environment или Integrated Debugging Environment) - система программных средств, используемая программистами для разработки программного обеспечения (ПО).

Обычно среда разработки включает в себя:

* текстовый редактор;

* компилятор и / или интерпретатор;

* средства автоматизации сборки;

* отладчик.

Интегрированные среды разработки также часто поддерживают пометки в комментариях в исходном тексте программ, отмечающие места, требующие дальнейшего внимания или предполагающие внесение изменений, такие как TODO. В дальнейшем эти пометки могут выделяться редакторами (напр. vim, emacs, встроенный редактор Visual Studio) или использоваться для организации совместной работы с построением тегов и задач (например, в IntelliJ).

Использование комментариев с TODO так же является стандартом оформления кода на Object Pascal, Delphi. Microsoft в руководстве по Visual Studio рекомендует использовать тег TODO (наравне с HACK, UNDONE) для следующих пометок:

* добавление новых функций;

* известных проблем, которые нужно устранить;

* предполагаемых к реализации классов;

* мест размещения кода обработчиков ошибок;

* напоминаний о необходимости переработки участка кода.

При традиционном подходе, начальный этап написания программы строится следующим образом:

1. Исходный текст набирается при помощи какого-либо текстового редактора.

2. По завершении набора, работа с текстовым редактором прекращается и запускается кросс компилятор.

3. Как правило, вновь написанная программа содержит синтаксические ошибки, и компилятор сообщает о них на консоль оператора.

4. Вновь запускается текстовый редактор, и оператор должен найти и устранить выявленные ошибки, при этом сообщения о характере ошибок выведенные компилятором уже не видны, так как экран занят текстовым редактором.

51. Современные средства разработки ПО

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

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

* Понятие прикладного обеспечения

* Основные разновидности и группы прикладного программного обеспечения

* Основные этапы создания прикладного ПО

2 Классические методологии разработки программных средств

* Метод нисходящего проектирования

* Модульное проектирование

* метод нисходящего проектирования

* Структурное программирование

* CASE-технологии

* Технологии RAD

* Data Warehouse

* Система OLAP

3 Пример отечественной операционной системы и набор ее прикладного ПО

* Модули проекта iS-DOS

* Версии операционной системы

* Программное обеспечение iS-DOS

* Базовое программное обеспечение операционной системы iS-DOS

* Прикладное программное обеспечение операционной системы iSDOS

* Распространители данной операционной системы

* Технология запуска iS-DOS

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

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

* небольшую команду программистов (от 2 до 10 человек);

* короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

* фаза анализа и планирования требований;

* фаза проектирования;

* фаза построения;

* фаза внедрения.

53. Технология визуального программирования

Визуальное программирование - способ создания программ путем манипулирования графическими объектами вместо написания кода в текстовом виде.

Визуальное программирование позволяет программировать, используя графические или символьные элементы, которыми можно манипулировать интерактивным образом согласно некоторым правилам, причем пространственное графических объектов использовать в качестве элементов синтаксиса программы. Значительная часть визуальных языков программирования базируется на идее “фигур и линий”, где фигуры (прямоугольники, овалы и др.). рассматриваются как субъекты и соединяются линиями (стрелками, дугами и др.), которые представляют собой отношения.

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

Природно-визуальные языки имеют неотъемлемое визуальное выражение, для которого нет очевидного текстового эквивалента (например, графический язык G в средеLabVIEW ).

Визуально-преобразованный язык является не визуальным языком с наложенным визуальным представлением.

54. Автоматическая генерация программного кода

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

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

Другим примером генераторов могут служить технологии ASP.Net и PHP. Они генерируют HTML-разметку на основе программного кода. В средах Visual Studio и Delphi генерация кода также используется очень часто.

Технологии реализации генератора

При разработке генератора следует различать язык программирования, на котором реализован генератор и язык программирования, на котором генератор осуществляет вывод автоматически созданного кода. Ясно, что они могут как различаться, так и совпадать. Генератор может быть написан на языке C#, а выводить код на PL/SQL, или наоборот. Генератор не является частью программного кода проекта, можно даже сказать, что генератор является другим проектом и выполняет другие задачи, отличные от задач проекта. Поэтому технология его реализации необязательно должна совпадать с технологией, применяемой при разработке программного проекта.

В данном курсе мы будем рассматривать примеры, генерирующие программный код на языках C#, PL/SQL, а также запросы SQL. Большинство из примеров написано на языке C#. Разумеется, что генератор можно реализовывать и с применением других технологий. Наиболее оптимальный выбор будет зависеть от условий проекта. При этом будут использоваться другие шаблоны и техники, но принципы генерации останутся теми же.

Ключевые составляющие генерации кода.

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

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

* шаблоны программного кода (образцы по которым будет создан код);

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

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

55. Применение RAD и визуального программирования для прототипирования клиентских приложений ИС

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

Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:

- небольшой команде программистов (обычно от 2 до 10 человек);

- тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);

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

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

Основные принципы методологии RAD можно свести к следующему:

- используется итерационная (спиральная) модель разработки;

- полное завершение работ на каждом из этапов жизненного цикла не обязательно;

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

- необходимо применение CASE-средств и средств быстрой разработки приложений;

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

- необходимо использование прототипов, позволяющее полнее выяснить и реализовать потребности конечного пользователя;

- тестирование и развитие проекта осуществляются одновременно с разработкой;

- разработка ведется немногочисленной и хорошо управляемой командой профессионалов.

Средства RAD дали возможность реализовывать совершенно иную по сравнению с традиционной технологию создания приложений.

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

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

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

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

Размещено на Allbest.ru

...