Спиральная модель

При использовании этой модели ПО создается в несколько итераций (витков спирали)

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

На каждой итерации оцениваются:

§ риск превышения сроков и стоимости проекта;

§ необходимость выполнения ещё одной итерации;

§ степень полноты и точности понимания требований к системе;

§ целесообразность прекращения проекта.

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

Спиральная модель обладает рядом преимуществ:

Модель уделяет специальное внимание раннему анализу возможностей повторного использования.

Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта.

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

Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта

Модель позволяет контролировать источники проектных работ и соответствующих затрат.

Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего

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

 

 

38. Основные этапы программирования (структурный, RAD-технологии, CASE-технологии). Кризис программирования.

 

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

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

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

Второй структурный оператор называется условный оператор. Достаточно часто одна или другая задачи должны исполняться в зависимости от определённого условия, которое зависит от результатов выполнения предыдущей программы или от внешних устройств. Каждая из таких задач называется плечом условного оператора.

Условный оператор может использоваться в неполном варианте, когда одно из плеч алгоритма отсутствует:

Третий структурный оператор - это оператор цикла с проверкой условия после тела цикла. Отличие от условного оператора заключается в том, что передача управления осуществляется не вперёд, а назад. На языках программирования высокого уровня такой оператор входит в состав языка (оператор do..while - C или оператор repeat..until - PASCAL).

Четвёртый структурный оператор - это оператор цикла с проверкой условия до тела цикла. В отличие от предыдущего оператора тело цикла в этом операторе может ни разу не выполниться, если условие цикла сразу же выполнено. Этот оператор как и условный оператор невозможно реализовать на одной машинной команде.

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

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

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

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

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

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

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

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

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

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

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

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

- улучшают качество создаваемого ПО за счет средств автоматического контроля, прежде всего, контроля проекта;

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

- ускоряют процесс проектирования и разработки;

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

- поддерживают развитие и сопровождение разработки (заметим, что этот аспект не затрагивался ни одной из рассмотренных нами технологий проектирования);

- поддерживают технологии повторного использования компонент разработки).

 

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

Сложность решаемой задачи - это субъективное ощущение человека; обычно это ощущение возникает тогда, когда человек не знает способа решения задачи. Чем менее очевиден способ решения, тем сложнее кажется задача. Категорию сложности в программировании можно рассматривать с двух позиций: теоретической и инженерной. Сложность с точки зрения теории обычно связана с поиском эффективных алгоритмов решения вычислительных задач и с построением адекватных информационных моделей. Теоретическая сложность не относится непосредственно к процессу программирования. Сложность с точки зрения инженерной деятельности обычно связана с количеством элементов программы и способностью программиста удержать эти элементы и взаимосвязи между ними в своём уме.

 

39. Методология системного анализа и системного моделирования. Диаграммы IDEFO.

 

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

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

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

Методология IDEF-SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели сиетемы какой-либо предметной области. Функциональная модель SADT отображает структуру процессов функционирования системы и ее отдельных подсистем, т. е. выполняемые ими действия и связи между этими действиями. Для этой цели строятся специальные модели, которые позволяют в наглядной форме представить последовательность определенных действий. Исходными строительными блоками любой модели IDEFO процесса являются деятельность (activity) и стрелки (arrows).

Модели IDEFO отслеживают различные виды деятельности системы, их описание и взаимодействие с другими процессами. На диаграммах деятельность или процесс изображается прямоугольником, который называется блоком. Стрелка служит для обозначения некоторого носителя или воздействия, которые обеспечивают перенос данных или объектов от одной деятельности к другой. Стрелки также необходимы для описания того, что именно производит деятельность и какие ресурсы она потребляет. Это так называемые роли стрелок — ICOM — сокращение первых букв от названий соответствующих стрелок IDEFO. При этом различают стрелки четырех видов:

I (Input) — вход, т. е. все, что поступает в процесс или потребляется процессом.

С (Control) — управление или ограничения на выполнение операций процесса.

О (Output) — выход или результат процесса.

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

Методология IDEFO однозначно определяет, каким образом изображаются на диаграммах стрелки каждого вида ICOM. Стрелка Вход (Input) выходит из левой стороны рамки рабочего поля и входит слева в прямоугольник процесса. Стрелка Управление (Control) входит и выходит сверху. Стрелка Выход (Output) выходит из правой стороны процесса и входит в правую сторону рамки. Стрелка Механизм (Mechanism) входит в прямоугольник процесса снизу. Таким образом, базовое представление процесса на диаграммах IDEFO имеет следующий вид.

Техника построения диаграмм представляет собой главную особенность методологии IDEF-SADT. Место соединения стрелки с блоком определяет тип интерфейса. При этом все функции моделируемой системы и интерфейсы на диаграммах представляются в виде соответствующих блоков процессов и стрелок ICOM. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, изображается с левой стороны блока. Результаты процесса представляются как выходы процесса и показываются с правой стороны блока. В качестве механизма может выступать человек или автоматизированная система, которые реализуют данную операцию. Соответствующий механизм на диаграмме представляется стрелкой, которая входит в блок процесса снизу.

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

 

40. Язык UML. Назначение.

 

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

Принципы построения моделей:

1. Идея иерархичности.

2. Идея «черного ящика».

3. Использование визуализации.

4. Абстрагирование частей системы.

5. Принцип формализации

Язык UML предназначен для решения следующих задач:

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

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

Хотя язык UML является формальным языком — спецификаций, формальность его описания отличается от синтаксиса как традиционных формально-логических языков, так и известных языков программирования. 3. Описание языка UML должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств проектирования программных систем.

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

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

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

5. Поощрять развитие рынка объектных инструментальных средств.

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

6. Способствовать распространению объектных технологий и соответствующих понятий ООАП.

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

7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

 

41. Статические диаграммы UML (варианты использования, классов).

 

Язык UML - это графическая нотация для объектного моделирования в области разработки программного обеспечения. Все диаграммы языка UML делятся на два класса:

1. Статические диаграммы - диаграммы, описывающие статические сущности системы. К ним можно отнести следующие диаграммы:

· Диаграммы классов.

· Диаграммы пакетов

· Диаграммы развертывания.

· Диаграммы компонентов.

2. Динамические диаграммы - диаграммы, описывающие динамические сущности системы. К ним можно отнести следующие диаграммы:

· Диаграммы деятельности.

· Диаграммы вариантов использования.

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

· Диаграммы последовательности.

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

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

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

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

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

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

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

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

Базовые элементы этого пакета — вариант использования и актер.

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

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

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

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

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

42. Диаграммы поведения UML (состояний, последовательности, деятельности).

 

Для моделирования поведения на логическом уровне в языке UML могут использоваться сразу несколько канонических диаграмм: состояний, деятельности, последовательности и кооперации, каждая из которых фиксирует внимание на отдельном аспекте функционирования системы. В отличие от других диаграмм диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее — одного экземпляра определенного класса, т.е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния может быть вызвано внешними воздействиями со стороны других объектов или извне.

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

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

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

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

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

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

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

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

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

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний. При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное — в ее нижней части.

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

Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 8.1). Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом.

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

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

43. Основные принципы организации процесса разработки программного обеспечения по RUP.

 

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

Rational Unified Process — это продукт процесса, разработанный корпорацией Ra­tional Software. Rational Unified Process — это еще и контур процесса, который можно адаптировать и расширить для удовлетворения требований принявшей его организации.

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

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

1. Разрабатывайте итеративно

2. Управляйте требованиями

3. Пользуйтесь модульными архитектурами

4. Используйте визуальное моделирование

5. Не забывайте о проверке качества

6. Следите за изменениями

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

Кроме этих советов Rational Unified Process имеет и многие другие преимущества, позволяющие оптимально реализовать процесс разработки про­граммного обеспечения.