Конспект лекций, страница 22

Описание файла

PDF-файл из архива "Конспект лекций", который расположен в категории "лекции и семинары". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 22 страницы из PDF

Обязанностимогут быть добавлены или0..1удаленывовремяDecoratorConcreteComponentвыполненияпрограммы.component->defaultMethod()Применениенескольких+ defaultMethod()+ defaultMethod()декораторов обеспечиваетсочетаниедобавляемыхобязанностей.ConcreteDecoratorAConcreteDecoratorB- addedState : int• Хотядекорированный - addedState : intобъект и обычный имеют + defaultMethod()+ defaultMethod()общийинтерфейс,они + addedBehaviour()Decorator::defaultMethod(); + addedBehaviour()+ setState()+ setState()addedBehaviour();различны.+ getState()+ getState()• Получаемаясистемасостоит из множества мелких объектов, которые похожи друг на друга. Проектировщик,разбирающийся в устройстве системы, может легко настроить ее, но постороннемуизучать и отлаживать ее тяжело.Рассмотрим пример, в котором для класса Ticket применены две обертки для печатис верхним и нижним колонтитулом.

Диаграмма классов:13Диаграмма кооперации, демонстрирующая цепочку объектов, задействованных припечати:Литература к лекции 101.2.Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированногопроектирования. Паттерны проектирования. – СПб.: Питер, 2001.Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином.Лаборатория знаний. 200714Лекция 12. Технология создания программного обеспечения.Rational Unified Process (RUP)Основные определения:Технология создания ПО (ТС ПО) – это упорядоченная совокупностьвзаимосвязанных технологических процессов в рамках ЖЦ ПО.Технологический процесс – это совокупность взаимосвязанных технологическихопераций.Технологическая операция – это основная единица работы, выполняемаяопределенной ролью, которая:• подразумевает четко определенную ответственность роли;• дает четко определенный результат (набор рабочих продуктов), базирующийся наопределенных исходных данных (другом наборе рабочих продуктов);• представляет собой единицу работы с жестко определенными границами, которыеустанавливаются при планировании проекта.Рабочий продукт – информационная или материальная сущность, которая создается,модифицируется или используется в некоторой технологической операции (модель,документ, код, тест и т.п.).Роль – определение поведения и обязанностей отдельного лица или группы лиц всреде организации-разработчика ПО, осуществляющих деятельность в рамках некотороготехнологического процесса и ответственных за определенные рабочие продукты.Руководство – практическое руководство по выполнению одной или совокупноститехнологических операций.

Руководства включают методические материалы, инструкции,нормативы, стандарты и критерии оценки качества рабочих продуктов.Инструментальное средство (CASE-средство) – программное средство,обеспечивающее автоматизированную поддержку деятельности, выполняемой в рамкахтехнологических операций.Исходныеданныев стандартномпредставлении(документы,рабочиематериалы,результатыпредыдущейоперации)Методическиематериалы,инструкции,нормативыи стандарты,критерииоценкирезультатовТехнологическаяоперацияРезультаты встандартномпредставленииИсполнители,программные итехническиесредстваОсновным требованием, предъявляемым к современным ТС ПО, является ихсоответствие стандартам жизненного цикла (ЖЦ) ПО и оценкой технологическойзрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно этимнормативам, ТС ПО должна поддерживать полный набор процессов ЖЦ, к которымотносятся:• управление требованиями;• анализ и проектирование ПО;1•••••••разработка ПО;эксплуатация;сопровождение;документирование;управление конфигурацией и изменениями;тестирование;управление проектом.Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексоминструментальных средств (CASE-средств).

Также есть ряд других требований:• адаптируемость к условиям применения;• поддержка поставщика;• простота использования;• удовлетворительные стоимостные характеристики.В качестве примера ТС ПО рассмотрим Rational Unified Process (RUP).RUP является развитием процесса разработки, принятого в компании Ericsson в 70х–80-х годах XX века. Эта модель была создана Джекобсоном (Ivar Jacobson),впоследствии, в 1987, основавшим собственную компанию Objectory AB именно дляразвития технологического процесса разработки ПО как отдельного продукта, которыйможно было бы переносить в другие организации. После вливания Objectory в Rational в1995 разработки Джекобсона были интегрированы с работами Ройса (Walker Royce),Крачтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимся параллельноуниверсальным языком моделирования (Unified Modeling Language, UML).Rational UnifiedProcess 2000 …Rational UnifiedProcess 5.5RealtimeROOM1999UML 1.3Project managementPerformancetestingBusinessEngineeringConfiguration& change MgmtRequirementsCollegeOMTBooch2000 …RationalApproachRational UnifiedProcess 5.0ObjectoryUI design1998Data EngineeringRational ObjectoryProcess 4.1Rational ObjectoryProcess 4.010/1997SQAProcess12/1996ObjectoryProcess 3.8UML 0.8UML 1.11995RUP в значительной степени соответствует указанным выше требованиям.

Ееосновными принципами являются:2•Раннее определение рисков и выработка ответных мер. В начале каждой стадии ЖЦсоставляется список рисков (примеры: неосвоенная СП, интеграция с унаследованнымкодом, орг. проблемы). По каждому риску из списка составляется перечень ответныхмер. RUP учитывает изменчивость рисков – на разных этапах проекта списки рисковразные.• Выполнение требований заказчиков. Требования описываются вариантамииспользования. Варианты использования – это отправная точка создания для моделианализа и проектной модели.

Планирование и управление проектом ведется на основевариантов использования. Варианты использования являются «сырьем» для тестов ипользовательской документации.• Концентрация на работающем коде. Прогресс проекта оценивается по тому, какаячасть системы готова и работает. Практика – лучший критерий проверки правильноститого или иного решения. Все рабочие продукты проекта за исключением работающегокода являются вспомогательными, поэтому не следует слепо их создавать лишь из-затого, что они указаны в руководствах по RUP.• Готовность к изменениям с самого начала проекта и управление ими. Системаслишком сложна, чтобы с самого начала получить верное и окончательное проектноерешение.

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

Стоимость разработкисистемы может быть снижена за счет использования компонентных платформ(J2EE, .NET).• Визуальное моделирование. Графические модели более наглядны, удобны чем текстына естественных и формальных языках. UML – стандартный язык, так что моделипонятны большой аудитории (состоящей не только из людей, но и из CASE-средств),по той же причине имеется больше возможностей для повторного использованиямоделей.• Обеспечение качества в течение всего ЖЦ. Используется упреждающее тестирование,лозунг которого: «Тесты раньше программ!» Регрессионное тестирование ипервоочередная реализация приоритетных вариантов использования обеспечиваютнадежность ключевой функциональности системы. Качество создается в течение всегожизненного цикла за счет того, что все рабочие продукты критически оцениваютсяпри рецензировании.На рисунке показано общее представление RUP в двух измерениях:• горизонтальное измерение представляет время, отражает динамические аспектыпроцессов и оперирует такими понятиями, как стадии, итерации и контрольные точки;• вертикальное измерение отражает статические аспекты процессов и оперирует такимипонятиями, как виды деятельности, рабочие продукты, исполнители и дисциплины.Динамический аспектСогласно технологии RUP, ЖЦ ПО разбивается на отдельные циклы, в каждомиз которых создается новое поколение продукта.

Каждый цикл, в свою очередь,разбивается на четыре последовательные стадии:начальная стадия (inception);стадия разработки (elaboration);стадия конструирования (construction);стадия ввода в действие (transition).3СтадииНачальная РазработкаОсновные процессыстадияКонструированиеВвод вдействиеМоделирование бизнес-процессовОпределение требованийАнализ и проектированиеРеализацияТестированиеРазвертываниеВспомогательные процессыУправление конфигурацией и изм.Управление проектомСоздание инфраструктурыПредварит.итерацияИтер.

Итер. Итер. Итер. Итер.#1#2#n#n+1 #n+2Итер.#mИтер.#m+1ИтерацииРис. Общее представление RUPКаждая стадия завершается в четко определенной контрольной точке (milestone).В этот момент времени должны достигаться важные результаты и приниматьсякритически важные решения о дальнейшей разработке.Первыми двумя стадиями являются начальная стадия проекта и разработка.

Свежие статьи
Популярно сейчас