курсовая. СОДЕРЖАНИЕ. Инструментальное программное обеспечение. История
 Скачать 1.22 Mb.
|
|
ТЕМА:Методология RUP. Rational Unified Process (RUP) - методология разработки программного обеспечения, созданная и поддерживаемая компанией Rational Software. Это: - новый подход к разработке ПС, основанный на использовании лучших практических методов, успешно зарекомендовавших себя во многих проектах разработки ПС по всему миру; - четко определенный процесс (технологическая процедура), описывающий структуру жизненного цикла проекта, роли и ответственности отдельных исполнителей, выполняемые ими задачи и используемые в процессе разработки модели, отчеты и т.д.; - готовый продукт, предоставляемый в виде веб-сайта, содержащего все необходимые модели и документы с описанием процесса. В основе методологии лежат 6 основных принципов: - Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков. - Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов). - Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. - Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. - Постоянное обеспечение качества на всех этапах разработки проекта (продукта). - Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам. Использование методологии RUP направлено на итеративную модель разработки. Особенность методологии состоит в том, что степень формализации может меняться в зависимости от потребностей проекта. Можно по окончании каждого этапа и каждой итерации создавать все требуемые документы и достигнуть максимального уровня формализации, а можно создавать только необходимые для работы документы, вплоть до полного их отсутствия. За счет такого подхода к формализации процессов методология является достаточно гибкой и широко популярной. Данная методология применима как в небольших и быстрых проектах, где за счет отсутствия формализации требуется сократить время выполнения проекта и расходы, так и в больших и сложных проектах, где требуется высокий уровень формализма, например, с целью дальнейшей сертификации продукта. Это преимущество дает возможность использовать одну и ту же команду разработчиков для реализации различных по объему и требованиям проектов. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. IBM Rational Unified Process — процесс, управляемый на основе прецедентов. Это означает, что в качестве метода описания функциональных требований к системе, а также в качестве естественной единицы для дальнейшего планирования и оценки выполнения работ используются сценарии использования. Сценарии использования позволяют легко выявлять реальные потребности будущих пользователей системы и отслеживать полноту описания этих требований. Они гарантируют выполнения требований заказчика к ПС. Кроме того, использование завершенных сценариев в качестве единицы измерения прогресса помогает избежать неадекватной оценки степени выполнения проекта исполнителем. IBM Rational Unified Process предполагает разработку, реализацию и тестирование архитектуры на самых ранних стадиях выполнения проекта. Такой подход позволяет устранять самые опасные риски, связанные с архитектурой, на ранних стадиях разработки. Благодаря ему удается избежать существенных переработок в последний момент, если вдруг выяснится, что выбранное решение не обеспечивает, к примеру, выполнение требований к производительности системы. RUP- Четко определенный процесс RUP создавался по методике, используемой при проектировании ПС. В частности, моделирование производилось с помощью Software Process Engineering Metamodel (SPEM) -стандартамоделированияпроцессов, основанногона Unified Modeling Language (UML). Особенностью RUP является то, что в результате работы над проектом создаются и совершенствуются модели. Вместо создания громадного количества бумажных документов, RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. RUP – это руководство по тому, как эффективно использовать UML. Стандартный язык моделирования, используемый всеми членами группы, делает понятными для всех описания требований, проектирование и архитектуру системы. У процесса есть два измерения: Динамическая структура. Горизонтальное измерение представляет собой динамическую структуру или временное измерение процесса. Оно показывает, как процесс, выраженный в форме циклов, фаз, итераций и вех, развертывается в ходе жизненного цикла проекта. Статическая структура. Вертикальное измерение представляет собой статическую структуру процесса. Оно описывает, как элементы процесса - задачи, дисциплины, артефакты и роли - логически группируются в дисциплины или рабочие процессы. Моделирование бизнес-процессов применяется с тем, чтобы разобраться в структуре исследуемой предметной области, обеспечить единство понимания основных автоматизируемых процессов среди всех участников проекта и определить высокоуровневые требования, которые должны быть реализованы в ходе проекта. Управление требованиями позволяет прийти к соглашению с заказчиками и конечными пользователями, определить, что должна уметь делать создаваемая система, предоставить более четкие инструкции участникам проекта о возможностях системы, создать базу для успешного планирования работ в проекте и оценки его статуса в любой момент жизненного цикла. Анализ и проектирование служат для последовательного преобразования выявленных требований к системе в спецификации особого вида, которые описывают, как следует конкретно реализовать конечный продукт. Следует при этом делать различия между анализом и проектированием. Основное из них состоит в том, что спецификации анализа не зависят от конкретной платформы и технологии, для которой осуществляется создание ИС. А спецификации проектирования являются точным представлением проектируемой системы, часто позволяя автоматизировать процесс генерации на их основе программного кода. Реализация необходима для выявления порядка организации программного кода в терминах отдельных подсистем, преобразования исходного кода в выполняемые компоненты, тестирования созданных компонентов и интеграции отдельных компонентов в подсистемы и системы. Тестирование позволяет определять и контролировать качество создаваемых продуктов, следить за тем, насколько качественно осуществлена интеграция компонентов и подсистем, все ли требования к системе реализованы и все ли выявленные ошибки устранены до того, как система будет развернута на оборудовании конечного пользователя. Развертывание является процессом, в ходе которого осуществляется доставка разрабатываемого продукта к конечному пользователю. В ходе данного процесса производится новый выпуск системы, распространение ПО, его установка на стороне конечного пользователя, обучение последнего навыкам эффективной работы с поставленным ПО, предоставление услуг по технической поддержке, бета-тестирование и т. п. Конфигурационное управление и управление изменениями позволяет организовать эффективную работу с артефактами проекта, контролировать и управлять доступом к ним, вести историю изменений, обеспечить эффективное взаимодействие участников проекта, как в простых командах, так и в распределенных, находящихся на большом удалении друг от друга. Управление проектом включает в себя непосредственное формирование условий для эффективного хода всего проекта, определение руководств и руководящих принципов для планирования, формирования команды и мониторинга проекта, выявление и управление рисками, организацию работы участников проекта, формирование бюджета, планирование фаз и итераций. Управление средой позволяет осуществить поддержку всех участников проекта. В эту поддержку входят выбор инструментария и его приобретение, настройка и установка, конфигурирование процесса, доработка и адаптация методологии, используемой для ведения проекта, обучение Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций: Рис. 4. Графическое представление процесса разработки по RUP Переход с фазы на фазу возможен только после выполнения задач фазы ипредставляет собой контрольную точку процесса. Внедрение (Transition) В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета- тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта и завершение полного цикла разработки. IBM Rational Unified Process представляет собой готовый продукт. Он состоит из нескольких частей. Это: - размещаемая на Web база знаний, которая состоит из руководств, шаблонов, наставлений по использованию инструментальных средств, и которая может быть разбита на: · обширные руководства для всех членов коллектива разработчиков, для каждого временного интервала жизненного цикла ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне, и в виде подробных наставлений по повседневной деятельности. Руководства опубликованы в HTML формате; · наставления по пользованию инструментальными средствами, которые автоматизируют большие разделы процесса создания ПО. Наставления опубликованы в HTML формате. · примеры и шаблоны для Rational Rose, которые служат руководствами по тому, как структурировать информацию в Rational Rose при следовании указаниям RUP; · шаблоны для SoDa – более десятка шаблонов для SoDa, которые помогают автоматизировать документирование ПО; · Microsoft Word шаблоны – более 30 шаблонов, которые предназначены для поддержки документации по всем последовательностям действий и интервалам жизненного цикла ПО; · планы в формате Microsoft Project – для тех, кому трудно сразу перейти к созданию планов - отражают итерационную разработку. Данные документы помогают произвести такой переход; · Книга Ph. Kruchten - Rational Unified Process-An Introduction. Книга содержит 277 страниц и является хорошим вступлением и обзором к процессу и базе знаний. - веб сайт, содержащий описание процесса и интегрированный со многими инструментальными средствами; - Development Kit – описывает то, каким образом можно конфигурировать и расширить RUP для специфических нужд проекта, и обеспечивает инструменты и шаблоны, помогающие это выполнить; - средства кастомизации, позволяющие создавать собственные процессы (IBM Rational Workbench); - доступ к Resource Center, который содержит последние публикации, обновления, подсказки, методики, а также ссылки на add-on и сервисы. - сообщество пользователей RUP, участие в котором поможет вам обмениваться опытом (в том числе и готовыми описаниями процессов) с другими разработчиками. Пользователи RUP могут либо выбрать одно из типовых представлений процесса, либо создать свое собственное. Продукт RUP позволяет настраивать процесс под нужды конкретной организации-разработчика и конкретного проекта, включая в него различные готовые компоненты (plug-in), а также разрабатывать и включать в состав процесса собственные компоненты. Продукт содержит также представления (view), которые позволяют участникам разработки получать доступ к необходимой им информации в зависимости от ролевых или персональных настроек. Использование инструментальных средств Для обеспечения инструментальной поддержки всех процессов жизненного цикла разработки и сопровождения ПС RUP рекомендует использование специализированных инструментальных средств IBM Rational: — управление требованиями – IBM Rational RequisitePro; — визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE; — разработка — IBM Rational RapidDeveloper — конфигурационное управление – IBM Rational ClearCase; — управление изменениями – IBM Rational ClearQuest; — автоматизированное документирование – IBM Rational SoDA; — автоматизированное тестирование – IBM Rational TeamTest, IBM Rational TestFactory, IBM Rational Robot, IBM Rational PurifyPlus, Rational Visual Quantify, Rational Visual PureCoverage, Rational PerformanceStudio, IBM Rational SiteCheck и IBM Rational SiteLoad. · Rational Requisite Pro - поддерживает обновления и отслеживает изменения в требованиях для всего коллектива разработчиков, представляя их в удобном виде для чтения, обсуждения и изменений. Rational ClearQuest - Windows и Web-размещаемый продукт, который помогает коллективу разработчиков отслеживать и управлять всеми действиями по изменению ПО в течение его жизненного цикла. Rational Rose - мировой лидер среди средств визуального моделирования для бизнес процессов, анализа требований, и проектирования на основе архитектуры компонентов. Rational SoDA - автоматизирует создание документации для всего процесса разработки ПО, значительно сокращая стоимость документации и время на ее создание. Rational Purify - средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++; помогает находить ошибки утечки памяти. Rational Visual Quantify - средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО. Rational Visual PureCoverage - автоматически определяет области кода, которые не подвергаются тестированию; разработчики могут учесть это и более тщательно выполнять проверку. SQA TeamTest - создает, обслуживает и выполняет автоматизированные функциональные тесты, позволяя тщательно протестировать код и проверить, соответствует ли ПО предъявляемым к нему требованиям. Rational PerformanceStudio - простое в использовании, точное и масштабируемое средство, которое измеряет и предсказывает характеристики клиент/серверных и Web систем. Rational ClearCase - лидирующее на рынке средство конфигурационного управления, позволяющее менеджерам проекта отслеживать эволюцию каждого разрабатываемого проекта. Лекция 4 ТЕМА:Этап логического проектирования ИС. Основные подходы при создании концептуальной модели. Рассмотрим такие понятии, как «Предметная область» и «Бизнес- моделирование». Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область. Бизнес-моделирование (деловое моделирование) - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования. Бизнес-моделирование является отдельным подпроцессом в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе, т.е. те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе. Моделью бизнес-процесса называется его формализованное (графическое, табличное, текстовое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия. Модель, как правило, содержит следующие сведения о бизнес-процессе: · набор составляющих процесс шагов - бизнес-функций; · порядок выполнения бизнес-функций; · механизмы контроля и управления в рамках бизнес-процесса; · исполнителей каждой бизнес-функции; · входящие документы/информацию, исходящие документы/информацию; · ресурсы, необходимые для выполнения каждой бизнес-функции; · документацию/условия, регламентирующие выполнение каждой бизнес-функции; · параметры, характеризующие выполнение бизнес-функций и процесса в целом. Модели бизнес-процессов применяются предприятиями для различных целей, что определяет тип разрабатываемой модели. Графическая модель бизнес-процесса в виде наглядной, общепонятной диаграммы может служить для обучения новых сотрудников их должностным обязанностям, согласования действий между структурными единицами компании, подбора или разработки компонентов информационной системы и т. д. Описание с помощью моделей такого типа существующих и целевых бизнес-процессов используется для оптимизации и совершенствования деятельности компании путем устранения узких мест, дублирования функций и прочего. Имитационные модели бизнес-процессов позволяют оценить их эффективность и посмотреть, как будет выполняться процесс с входными данными, не встречавшимися до сих пор в реальной работе предприятия. Исполняемые модели бизнес-процессов могут быть запущены на специальном программном обеспечении для автоматизации процесса непосредственно по модели. Поскольку модели бизнес-процессов предназначены для широкого круга пользователей (бизнес-аналитиков, рядовых сотрудников и руководства компании), а их построением часто занимаются неспециалисты в области информационных технологий, наиболее широко используются модели графического типа, в которых в соответствии с определенной методологией бизнес-процесс представляется в виде наглядного графического изображения - диаграммы, состоящей в основном из прямоугольников и стрелок. Такое представление обладает высокой, многомерной информативностью, которая выражается в различных свойствах (цвет, фон, начертание и т.д.) и атрибутах (вес, размер, стоимость, время и т.д.) каждого объекта и связи. В последние годы разработчики программных средств моделирования бизнес-процессов уделяют большое внимание преобразованию графических моделей в модели других видов, в частности в исполняемые, назначением которых является обеспечение автоматизации бизнес-процесса и интеграция работы задействованных в его исполнении информационных систем. Согласно еще одной классификации, пришедшей из моделирования сложных систем, выделяют следующие виды моделей бизнес-процессов: · функциональные, описывающие совокупность выполняемых системой функций и их входы и выходы; · поведенческие, показывающие, когда и/или при каких условиях выполняются бизнес- функции, с помощью таких категорий, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий; · структурные, характеризующие морфологию системы - состав подсистем, их взаимосвязи; · информационные, отражающие структуры данных - их состав и взаимосвязи. Проблема сложности является главной проблемой, которую приходится решать при создании больших систем любой природы, в том числе и ЭИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять все систему в целом. Единственно эффективный подход к решению этой проблемы заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем. Понятие «правильная» по отношению к декомпозиции означает следующее: 1. Количество связей между отдельными подсистемами должно быть минимальным. 2. Связность отдельных частей внутри каждой подсистемы должна быть максимальной. Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки: 1. Каждая подсистема должна инкапсулировать свою содержимое (скрывать его от других подсистем). 2. Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами. На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие которых обусловлено разными способами декомпозиции систем: 1. Функционально-модульный или структурный 2. Объектно-ориентированный. Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе. Методы моделирования бизнес процессов На сегодняшний день существует достаточно большое количество методов моделирования бизнес процессов. Эти методы относятся к разным видам моделирования и позволяют сфокусировать внимание на различных аспектах. Они содержат как графические, так и текстовые средства, за счет которых можно наглядно представить основные компоненты процесса и дать точные определения параметров и связей элементов. Наиболее часто моделирование бизнес-процессов выполняют с помощью следующих методов: · Flow Chart Diagram (диаграмма потока работ) – это графический метод представления процесса в котором операции, данные, оборудование процесса и пр. изображаются специальными символами. Метод применяется для отображения логической последовательности действий процесса. Главным достоинством метода является его гибкость. Процесс может быть представлен множеством способов. · Data Flow Diagram (диаграмма потока данных). Диаграмма потока данных или DFD применяется для отображения передачи информации (данных) от одной операции процесса к другой. DFD описывает взаимосвязь операций за счет информации и данных. Этот метод является основой структурного анализа процессов, т.к. позволяет разложить процесс на логические уровни. Каждый процесс может быть разбит на подпроцессы с более высоким уровнем детализации. Применение DFD позволяет отразить только поток информации, но не поток материалов. Диаграмма потока данных показывает, как информация входит и выходит из процесса, какие действия изменяют информацию, где информация хранится в процессе и прочее. · RoleActivityDiagram (диаграммаролей). Она применяется для моделирования процесса с точки зрения отдельных ролей, групп ролей и взаимодействия ролей в процессе. Роль представляет собой абстрактный элемент процесса, выполняющий какую-либо организационную функцию. Диаграмма ролей показывает степень «ответственности» за процесс и его операции, а также взаимодействие ролей. · IDEF (Integrated Definition for Function Modeling) – представляет собой целый набор методов для описания различных аспектов бизнес- процессов (IDEF0, IDEF1, IDEF1X , IDEF2, IDEF3, IDEF4, IDEF5). ЭтиметодыстроятсянабаземетодологииSADT (StructuredAnalysisandDesignTechnique). Для моделирования бизнес процессов наиболее часто применяют методы IDEF0 и IDEF3. - IDEF0 – позволяет создать модель функций процесса. На диаграмме IDEF0 отображаются основные функции процесса, входы, выходы, управляющие воздействия и устройства, взаимосвязанные с основными функциями. Процесс может быть декомпозирован на более низкий уровень. - IDEF3 – этот метод позволяет создать «поведенческую» модель процесса. IDEF3 состоит из двух видов моделей. Первый вид представляет описание потока работ. Второй – описание состояний перехода объектов. · ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь». С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД). ER-диаграммы моделируют данные и их отношения. Ключевыми понятиями в них являются сущность, атрибуты сущности и связи между сущностями. · Цветные сети Петри – этот метод представляет модель процесса в виде графа, где вершинами являются действия процесса, а дугами события, за счет которых осуществляется переход процесса из одного состояния в другое. Сети Петри применяют для динамического моделирования поведения процесса. · UnifiedModeling Language (UML) - представляет собой объектно- ориентированный метод моделирования процессов. Он состоит из 8-ти различных диаграмм, каждая из которых позволяет моделировать отдельные статические или динамические аспекты процесса. Большинство из указанных методов реализованы в виде программного обеспечения. Оно позволяет осуществлять поддержку бизнес-процессов или проводить их анализ. Примерами такого ПО являются различные CASE средства моделирования процессов. Структурный подход Итак, сущность структурного подхода к разработке ПО ЭИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов. Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов: 1. Принцип «разделяй и властвуй»; 2. Принцип иерархического упорядочения- принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, т.к. игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта»). Основными из этих принципов являются: 1. Принцип абстрагирования- выделение существенных аспектов системы и отвлечение от несущественных. 2. Принцип непротиворечивости,обоснованность и согласованность элементов системы. 3. Принцип структурирования данных- данные должны быть структурированы и иерархически организованы. В структурном подходе в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди них являются: · DFD (Data Flow Diagrams) - диаграммы потоков данных; · SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы: нотации IDEF0 (функциональное моделирование систем), IDEF1х (концептуальное моделирование баз данных), IDEF3х (построение систем оценки качества работы объекта; графическое описание потока процессов, взаимодействия процессов и объектов, которые изменяются этими процессами); · ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь». Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования: 1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0). 2. Диаграммы, моделирующие данные и их отношения (ERD). Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО. На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей , как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД). На стадии проектирования DFD используются для описания структуры проектируемой системы. Перечисленные модели в совокупности дают полное описание ПО ЭИС независимо от того, является ли система существующей или вновь разрабатываемой. Объектно-ориентированный подход Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектно- ориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение бизнес-модели организации, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации бизнес-функций. Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов: · абстрагирование; · инкапсуляция; · модульность; · иерархия; · типизация; · параллелизм; · устойчивость. Основными понятиями объектно-ориентированного подхода являются объект и класс. Определение: Объект -предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Определение: Класс –это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы. Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования. В нотации языка UML определены следующие виды канонических диаграмм: · вариантов использования (use case diagram) классов (class diagram) кооперации (collaboration diagram) последовательности (sequence diagram) состояний (statechart diagram) деятельности (activity diagram) компонентов (component diagram) · развертывания (deployment diagram) Перечень этих диаграмм и их названия являются каноническими в том смысле, что представляют собой неотъемлемую часть графической нотации языка UML. Более того, процесс ООАП неразрывно связан с процессом построения этих диаграмм. При этом совокупность построенных таким образом диаграмм является самодостаточной в том смысле, что в них содержится вся информация, которая необходима для реализации проекта сложной системы. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. При этом диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов, по своей сути, логическая модель, отражающая статические аспекты структурного построения сложной системы. Диаграммы кооперации и последовательностей представляют собой разновидности логической модели, которые отражают динамические аспекты функционирования сложной системы. Диаграммы состояний и деятельности предназначены для моделирования поведения системы. И, наконец, диаграммы компонентов и развертывания служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели. В целом интегрированная модель сложной системы в нотации UML может быть представлена в виде совокупности указанных выше диаграмм (рис. 2). Рис. 2. Интегрированная модель сложной системы в нотации UML На этапе постановки задачи и анализа требований к системе используют диаграммы прецедентов, диаграммы деятельностей для расшифровки содержания прецедентов, диаграммы состояний для моделирования поведения объектов со сложным состоянием, диаграммы классов для выделения концептуальных сущностей предметной области задачи и диаграммы последовательностей действий. Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: логическую, использования, реализации, процессов, развертывания. Модель использования содержит описание функций программного обеспечения с точки зрения пользователя. Логическая модель описывает ключевые понятия моделируемого программного обеспечения (классы, интерфейсы и т. п.), т. е. средства, обеспечивающие его функциональность. Модель реализации определяет реальную организацию программных модулей в среде разработки. Модель процессов отображает организацию вычислений и позволяет оценить производительность, масштабируемость и надежность программного обеспечения. Модель развертывания показывает, каким образом программные компоненты размещаются на конкретном оборудовании. Все вместе указанные модели, каждая из которых характеризует определенную сторону проектируемого продукта, составляют относительно полную модель разрабатываемого программного обеспечения. Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы. Объектно-ориентированный подход обладает следующими преимуществами: · Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей. · Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем. · Объектная модель естественна, поскольку ориентирована на человеческое восприятие мира. К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны. Лекция 5 |