Применение объектно-ориентированного подхода при проектировании информационной системы (Теоретические основы объектно-ориентированного подхода).

Содержание:

Введение

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

Развитие современных информационных систем приводит к увеличению сложности информационных систем. Главной задачей во время разработки сложных систем является проектирование адекватных моделей систем. Для этого применяются CASE-средства (Computer Aided Software/ System Engineering) – специальные программно-технологические средства.

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

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

В данной курсовой работе будут решаться следующие задачи:

1. Изучить теоретические основы объектно-ориентированного подхода проектирования;

2. Провести краткий анализ методов объектно-ориентированных методологий;

3. Проанализировать технологии разработки;

4. Рассмотреть инструментальную среду IBM Rational Rose.

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

В первой главе рассматриваются основные понятия и характеристики объектно-ориентированного подхода.

Вторая глава содержит информацию о методах объектно-ориентированного проектирования.

Третья глава посвящена технологиям проектирования информационных систем.

В четвертой главе раскрывается сущность инструментального средства объектно-ориентированного проектирования IBM Rational Rose.

1. Теоретические основы объектно-ориентированного подхода

1.1. понятие объектно-ориентированного проектирования.

Объектно-ориентированное проектирование – это метод проектирования, сочетающий в себе процесс объектно-ориентированной декомпозиции и систему обозначения для представления логической и физической, а также статической и динамической моделей проектируемой системы»^[[1]]. Отличие объектно-ориентированного проектирования от структурного заключается именно в объектно-ориентированной декомпозиции.

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

«Объектно-ориентированная декомпозиция уменьшает размер систем за счет повторного использования общих механизмов, обеспечивая значительную экономию выразительных средств. Объектно-ориентированные системы являются более гибкими и легче эволюционируют со временем, поскольку их проектирование основано на устойчивых промежуточных формах»^[[2]].

Объектно-ориентированный подход к проектированию ИС не был создан спонтанно, а наоборот, развивался постепенно, перенимая идеи ранних методологий.

Основные предпосылки создания объектно-ориентированного подхода:

1. прогресс в области архитектуры ЭВМ (включая системную и аппаратную часть);
2. развитие языков программирования, таких как Simula, Smalltalk, CLU, Ada;
3. развитие методологии программирования, включая принципы модульности и защиты информации (сокрытия данных);

1.2. Свойства объектов в объектно-ориентированном подходе следующие:

• Абстрагирование – выделение существенных признаков объект, которые отличают его от других видов объектов. Основные абстракции предметной области – объекты и классы.
• Модульность - возможность декомпозиции системы на внутренние подсистемы (модули), тем самым снижая сложность системы и позволяя осуществлять разработку отдельных модулей независимо от других.
• «Инкапсуляция – физическая локализация свойств и поведения в рамках единственной абстракции»^[[3]]. Смысл этого свойства в том, что состав и структура атрибутов объекта не зависят от сообщений, поступающих извне.
• Иерархия – упорядоченная систем абстракций, расположение их по уровням.

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

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

«Объектно-ориентированная система изначально строится с учетом эволюции. Наследование и полиморфизм обеспечивают возможность определения новой функциональности классов с помощью создания производных классов – потомков базовых классов»^{[ [4]]}.

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

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

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

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

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

«Можно назвать пять преимуществ, которые дает объектная модель:

• 1. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
  2. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что в итоге ведет к созданию среды разработки. Объектно-ориентированные системы часто получаются более компактными, чем их не объектно-ориентированные эквиваленты. А это означает не только уменьшение объема кода программ, но и удешевление проекта за счет использования предыдущих разработок, - что, в свою очередь, дает выигрыш в стоимости и времени.
  3. Использование объектной модели приводит к построению системы на основе стабильных промежуточных описаний, что упрощает процесс внесения в нее изменений. Это дает системе возможность развиваться постепенно и не приводит к полной ее переработки даже в случае существенных изменений исходных требований.
  4. Объектная модель уменьшает риск разработки сложных систем – прежде всего потому, что процесс интеграции растягивается на все время разработки, а не превращается в единовременное событие. Объектный подход состоит из ряда хорошо продуманных этапов проектирования, что также уменьшает степень риска и повышает уверенность в правильности принимаемых решений»^[[5]].

«Применяя объектно-ориентированное проектирование, можно создавать гибкие программы, написанные экономными средствами. При разумном разделении пространства состояний можно добиться большей уверенности в правильности разработанного программного обеспечения. В итоге уменьшается риск, характерный для разработки сложных программных систем»^[[6]].

2. Методы объектно-ориентированного проектирования

2.1. Методология OMT

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

Впервые Метод OMT (Object Modeling Techniques) был описан в работе Майкла Блага (Michael Blaha), Билла Премерлани (Bill Premelani), Джеймса Румбаха (James Rumbaugh) и их коллег из компании Generak Electric. Он стал одним из наиболее популярных методов объектно-ориентированного анализ. «Этот подход в значительной мере основан на традиционных структурных методах и предусматривает использование мощной системы обозначения, которая вместе с тем является достаточно сложной и подробной. Сложность нотации отчасти объясняется тем, что из поддерживаемых ею средств представлена для автоматической генерации исходного кода»^[[7]].

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

Проектируемая программная система в технологии OMT представляется в виде трех взаимосвязанных моделей:

• Объектная модель. Представляет статические, структурные аспекты системы, связанные с данными. Объектные модели описывают объекты, классы объектов, а также связи между объектами.
• Динамическая модель. В ней описывается работа отдельных частей системы, поведение системы.
• Функциональная модель. Рассматривает взаимодействие отдельных частей системы по данным и по управлению в процессе ее работы.

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

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

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

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

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

2.2. Методология BOOCH

«В 1980-х годах Гради Буч (Grady Booch) опубликовал статью под пророческим заголовком: Object-Oriented Design (Объектно-ориентированное проектирование), в которой были изложены вопросы проектирования для языка Ада. К 1991 году Буч смог расширить свои идеи до подлинно объектно-ориентированного метода проектирования, который он описал в своей одноименной книге, переработанной в 1993 году»^[[8]].

Наибольшее применение метод Booch'93 нашел на этапах проектирования и разработки различных программных систем. В нем предусматривается постепенное и многократное уточнение архитектуры системы.

Метод Booch использует графическую нотацию для проектирования. Нотация имеет расширения для реализации классов и объектов, а также сервисов предоставляемых ими. Другой важной особенностью применяемой нотации является наличие диаграмм переходов состояний (state transition diagrams) и временных диаграмм (timing diagrams).

2.3. Методология ARIS

«Методология построения интегрированных информационных систем (Architecture of Integrated Information Systems, ARIS) предполагает определенный подход к формализации информации о деятельности организации и представление ее в виде графических модулей, удобных для понимания и анализа»^[[9]].

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

«Методология ARIS включает в себя несколько различных нотаций для описания деятельности организации с различных точек зрения. В методологию интегрированы существующие стандарты и спецификации описания процессов и данных, например IDEF3, ERD, DFD, UML и т.д.»^[[10]].

Методология ARIS рассматривает деятельность организации с четырех сторон:

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

«В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами»^[[11]].

К наиболее значимым и практически используемым нотациям ARIS относятся:

• VAD (Value-added Chain Diagram) – процесс или группа функций организации, служащие для получения добавленной стоимости;
• eEPC (Extended Event-driven Process Chain) – расширение нотации IDEF3;
• PCD – разновидность eEPC;
• Organization Chart – построение схем организационной структуры предприятия;
• Function Tree – формирование моделей дерева функций;
• Product Tree – формирование моделей дерева продуктов;
• Information Flow – построение схем потоков или документов между функциями бизнес-процессов предприятия.

2.4 Методология OOSE

Среди самых популярных в 1990-е годы нотаций, поддерживающих объектно-ориентированную методологию проектирования, находится методология OOSE (Object-Oriented Software Engineering), разработанная И. Якобсоном (I. Jacobson). «В методике OOSE основное внимание уделено развитым средствам поведенческого анализа»^[[12]].

Данный метод основан на проектировании, центральное звено которого – это понимание, каким образом фактически используется система. Организуя модели анализа и проектирования на основе последовательных взаимодействиях пользователя и системы, методология OOSE позволяет создавать более удобные, прочные системы, легче приспосабливаемые к изменениям. Модели, разрабатываемые в процессе анализа, ориентированы именно на приложения, а не на среду реализации. Они не зависят от операционной системы, СУБД, языка программирования, конфигурации аппаратуры или распределения процессов. Задача методологии заключается в построении моделей, которые могут решить сформулированную проблему при идеальных условия.

«Метод OOSE содержал средства представления вариантов использования, которые имеют существенное значение на этапе анализа требований в процессе проектирования бизнес-приложений»^[[13]].

3. Технологии разработки ИС

3.1. Rational Unified Process (RUP)

RUP (Rational unified Process, Целесообразный Унифицированный Процесс), одна из наиболее совершенных технологий, была разработана компанией Rational Software. Данная технология включает четыре фазы, которые могут быть разбиты на итерации (этапы):

1. Начало (Inception): происходит выделение границ проекта, оценка реальности его выполнения (сроки, планы, деньги, люди, риски).
2. Исследование (Elaboration): происходит создание архитектурного прототипа системы, определяются требования к проекту, его цена, срок исполнения, составляется подробный план работы.
3. Построение (Construction): реализуется проект.
4. Внедрение (Transition): система передается заказчику.

Цикл разработки представляет собой прохождение через четыре фазы. Каждый цикл завершается созданием версии системы. При необходимости процесс разработки продолжается на новом уровне и завершается выпуском очередной версии системы.

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

• Ранняя идентификация и устранение рисков;
• Концентрация на выполнении требований заказчиков;
• Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки;
• Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта:
• Постоянное обеспечение качества на всех этапах разработки проекта (продукта);
• Работа над проектом в сплоченной команде, ключевая роль в которой принадлежит архитекторам»^[[14]].

Основные принципы методологии RUP:

1. Итерационный и инкрементный подход к созданию ПО.
2. Планирование и управление проектом на основе функциональных требований к системе – вариантов использования.
3. Построение системы на базе архитектуры ПО.

В соответствии с принципом итерационного и инкрементного подхода к созданию ПО разработка системы осуществляется в виде нескольких мини-проектов, длительностью 2-6 недель. Эти мини-проекты называются итерациями. Они включают в себя собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции. Итерации завершаются созданием работающей системы.

«Сущность планирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемы на каждой итерации»^[[15]].

RUP представляет собой Web-сайт, где описаны все его элементы, глоссарий, руководства для участников проектной команды и т.п. Для его адаптации к потребностям определенной организации или проекта используется Rational Process Workbench (RPW) – специальный набор инструментов и шаблонов.

«Методика моделирования Rational Unified Process обладает следующими достоинствами:

• модель бизнес-процессов строится вокруг участников процессов (заинтересованных лиц) и их целей, помогая выявить все потребности клиентов организации. Нетрудно заметить, что такой подход в наибольшей степени применим для организаций, работающих в сфере оказания услуг (торговые организации, банки, страховые компании и т.д.);
• моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков»^[[16]].

3.2. Microsoft Solution Framework (MSF)

Microsoft Solution Framework (Шаблон Решения от Microsoft, MSF) – методология, предложенная в 1994 году корпорацией Microsoft, описывающая управление людьми и рабочими процессами в процессе разработки решений. Данную методологию могут применять при разработки достаточно широкого круга IT-проектов в силу отсутствия жестко навязываем процедур. MSF сочетает свойства как каскадной производственной модели, так и спиральной. Методология предоставляет методики для планирования, проектирования, разработки и внедрения IT-решений.

Основные концепции MSF заключаются в следующем:

• Единое видение проекта. Все участники проекта должны иметь информацию о проекте, его целях, параметрах будущей информационной системы.
• Управление компромиссами. Нахождение заранее компромиссов между ресурсами, графиком выполнения работ, реализуемыми возможностями системы.
• Готовность к переменам. Важная особенность методологии MSF – принцип изменяющихся проектных условий. Изначально в проект закладывается возможность изменения условий, чтобы участника проекта были готовы к этому.
• Концентрация на бизнес-приоритетах. «При создании любого решения необходимо сосредоточится на той отдаче и выгоде, которую ожидает получить потребитель решения»^[[17]].
• Свободное общение. В определенные промежутки времени проводится анализ хода работы над проектом, документируются результаты, тем самым, предоставляя полную информацию всем участникам проекта о его выполнении, а также позволяя выявить риски и ошибки на ранних стадиях.
• Создание базовых версий. Любой проектный артефакт, будь то программный код, руководство пользователя, настройки серверов и т.д., фиксируется, чтобы иметь возможность при необходимости вносить изменения, возвращаться на шаг назад.

3.3. Технология CDM (Custom Development Method)

Custom Development Method (CDM) – разработанная корпорацией Oracle методология разработки, которая ориентирована на пользователя. Методология представляет собой руководство по разработке прикладного программного обеспечения с использованием Oracle Developer.

Жизненный цикл информационной системы, в соответствии с методологией CDM, состоит из 6 этапов:

1. Стратегия. На этом этапе модулируются и анализируются процессы, которые описывают деятельность организации, технологические особенности работы.
2. Анализ. Данный этап заключается в определении требований к прикладной системе, описывающие информационные потребности организации.
3. Проектирование. Этап связан с преобразованием требований, определенных на стадии анализа, в детальные спецификации прикладной системы (определяются структура и состав базы данных, определяется набор программных модулей).
4. Реализация. На четвертом этапе создаются программы, отвечающие всем требования проекта, пишутся и тестируются приложения.
5. Внедрение. Новая прикладная система устанавливается заказчику, осуществляется подготовка к эксплуатации.
6. Эксплуатация. На последнем этапе жизненного цикла заказчик использует созданную прикладную систему.

В процессе разработки информационной системы выделятся следующие процессы:

• Определение бизнес-требований (Business Requirements Definition). Суть этого процесса заключается в определении целей и требований, предъявляемых к разрабатываемой ИС;
• «Исследование существующих систем (Existing Systems Examination). Выполнение этого процесса должно обеспечить понимание состояния существующего технического и программного обеспечения для планирования необходимых изменений»^[[18]];
• Определение технической архитектуры (Technical Architecture);
• Проектирование и реализация базы данных (Database Design and Build). Выполнение этого процесса предусматривает проектирование и реализацию реляционной базы данных, включая создание индексов и других объектов БД;
• Проектирование и реализация модулей (Module Design and Build). Будучи основным процессом в проекте, он заключается в непосредственном проектировании приложения и создании кода прикладной программы;
• Конвертирование данных (Data Conversation). Выполнение этого процесс обеспечивает преобразование, перенос и проверку согласованности и непротиворечивость данных, оставшихся в наследство от «старой» системы и необходимых для работы в новой системе;
• Документирование (Documentation);
• Тестирование (Testing);
• Обучение (Training);
• Внедрение, или переход к новой системе (Transition). Этот процесс решает задачи установки, ввода новой системы в эксплуатацию, прекращение эксплуатации старых систем;
• Поддержка и сопровождение (Post-System Support).

«Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:

• классическая— предусматривает все этапы;
• быстрая разработка — ориентирована на использование инструментов моделирования и программирования Oracle;
• облегчённый подход — рекомендуется в случае малых проектов и возможности быстро прототипировать приложения»^[[19]].

3.4. Методология RAD

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

Методология Rapid Application Development (Быстрая Разработка Приложений, RAD) предусматривает три элемента:

• небольшая группа разработчиков, обычно состоящая из 3-7 человек. Разработчики проектируют отдельные системы ПО;
• производственный график тщательно проработан и длится до трех месяцев;
• повторяющийся цикл. По мере того, как приложение обретает форму, разработчики запрашивают и реализуют требования заказчика. Таким образом, заказчик принимает участник во всех фазах жизненного цикла проекта.

«Модель RAD включает следующие фазы:

• планирование требований – структурный анализ и обсуждение с заказчиком реализуемых коммерческих затрат;
• пользовательское описание – выполняются сбор пользовательской информации и построение моделей процессов предметной области с использованием автоматизированных инструментальных средств при активном участии заказчиков;
• конструирование – выполняется детализированное проектирование, включающее разработку (кодирование и тестирование) системы, а также поставку программного продукта;
• перевод на новую систему эксплуатации – проведение совместно с заказчиком приемочных испытаний, установка системы и обучение пользователей»^[[21]].

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

«RAD наиболее хорошо подходит для относительно небольших проектов, разрабатываемых для конкретного заказчика, и не применим для построения сложных расчетных программ, операционных систем или программ управления сложными объектами в реальном масштабе времени, т.е. программ, содержащих большой объем (сотни тысяч строк) уникального кода, а также систем, от которых зависит безопасностью людей (например, управление самолетом или атомной электростанцией)»^[[22]].

3.5. Extreme Programming

Extreme Programming (Экстремальное Программирование, XP) был создан Кентом Беконом в конце 1990-х годах.

«По замыслу авторов подходы, реализуемые в экстремальном программировании, должны являться альтернативой формальным подходам и призваны вернуть в разработку дух творчества»^[[23]]. Методология XP преследует цели сокращения сроков разработки продукта, а также повышение доверия заказчика к продукту посредством предоставления доказательств успешности развития проекта. Можно сказать, что XP является упрощенной методологией, где небольшая группа разработчиков создает программный продукт в условиях неясных и быстро меняющихся требований.

«Модель процесса по XP выглядит как частая последовательность выпусков (releases) продукта, столь частых, сколь это возможно. Но при этом обязательно, чтобы в выпуск входила новая целиковая функциональность»^[[24]].

Принципы экстремального программирования:

• Экстремальный цикл. Технология XP основана на очень коротком и повторяющемся цикле, в конце которого проект должен быть полностью реализован.
• Позднее принятие решений. Решения должны принимать только тогда, когда получена вся информация.
• Кодирование в глубину. В течение цикла полностью разрабатывается и тестируется отдельная функциональность, при этом игнорируется соединение с ней области.
• Идеальный день разработчика, фактор загрузки. Под идеальным днем понимается день, в который разработчик может выполнить заданный объем работы при максимальной загрузке. Отношение реальных календарных дней к идеальным дням разработчика является фактором загрузки.
• Скорость проекта – скорость реализации частей программы, определенных для заданного цикла.
• История пользователя. Представляет собой короткий, около 3 предложений, документ, в котором пользователь описывает одну отдельную операцию для данного пользователя.
• План релиза. Дает точный ответ на вопрос, какие истории пользователь будут реализованы в данном релизе.
• План итераций. Производится выборка заданий, которые будут выполнены в данной итерации.
• Тесты приемки. Без их прохождения история не считается реализованной.
• Представители заказчиков. Они должны быть в непосредственной близости и работать в команде разработчиков, являются источником историй пользователей и тестовых наборов данных, принимают участие в составлении плана релизов.
• Структура группы разработчиков. Все разработчики должны быть доступны друг для друга организационно и физически. В группе отсутствует административное деление.
• Простота и эффективность используемого кода. Выбираются технологии, которыми владеют все или большинство членов команды.
• Рефакторинг. Заключается в переработке уже работающего кода для его усовершенствования.
• Тестирование модулей. Технологическая проверка кода на основании готовой или созданной для этих целей автоматизированной системы.
• Групповое авторство. Устранение зависимости коллектива от какого-либо одного разработчика.

«Базис первой версии XP (1999-го года) формировали двенадцать методик, во второй версии (2004-го года) их количество возросло до двадцати четырех. Перечислим наиболее характерные из XP-методик»^[[25]].

Игра планирования (Planning game). Возможность изменения планов учитывается в самом начале метода. Частое общение с заказчиком помогает точнее оценить сроки выполнения задач и при необходимости внести требуемые изменения.

Частая смена версий (small release). Простая система быстро запускается в производство, обеспечивая возможность корректировать ее. Новые версии реализуются в двухнедельном цикле.

Инкрементное проектирование (Incremental design). Сначала разрабатывается программный код, чтобы получить комментарии заказчика и улучшить систему, а потом уже начинается подробное проектирование системы.

Простое проектирование (Simple design). Программный код разрабатывается максимально простой.

Тестируй, а затем кодируй (Test-first-coding). Сначала создаются тесты для модулей, а потом пишется программный код модулей.

Рефакторинг (Refactoring). Для устранения дублирования, улучшения взаимодействия, упрощения системы производится ее реструктуризация.

Парное программирование (Pair programming). Код пишется двумя программистами на одном компьютере.

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

Непрерывная интеграция (Continuous integration). По мере завершении задачи система интегрируется (до нескольких раз в день).

Локальный заказчик (On-site customer). Заказчик или его представитель должен постоянно находиться в группе разработчиков.

3.6. Методология Захмана

«Определение модели согласно Захману (Zachman Framework for Enterprise Architecture). Модель представляет собой общий словарь, набор перспектив или структур для описания современных сложных, корпоративных систем и преследует две основные цели: с одной стороны, логическое разбиение поставленной задачи на отдельные блоки для упрощения формирования и восприятия итогового решения, с другой – обеспечение возможности рассмотрения целостной архитектуры решения с выделенных точек зрения или соответствующих уровней абстракции»^[[26]].

Отличительной чертой данной методологии является то, что Дж. Захман (John A. Zachman) предложил рассматривать систему с различных перспектив, вместо традиционного рассмотрения отдельных элементов работы системы в различные моменты времени.

Сама модель представляет собой таблицу (см. Рис.1), в которой 5 перспектив (строк) и 6 областей (столбцов).

Рис. 1. Модель Захмана

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

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

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

4. Инструментальные средства: IBM Rational Rose

4.1. Общая характеристика IBM Rational Rose

В середине 90-х годов на рынке инструментальных CASE средств поддержки CBD-моделирования (Component Based Development) доминировало 4 фирмы:

• Rational Software,
• Cayenne
• Platinum
• Select

Rational Software, начиная с 1995 года, вырвалась вперед по объему продаж и остается лидером на рынке CASE продуктов в настоящее время. «Основной продукт фирмы – визуальное средство разработки Rational Rose. Это средство позволяет графически построить диаграммы, провести связи между ними и задать свойства диаграмм и связей. Заетм Rational Rose может откомпилировать проект в один из нескольких объектно-ориентированных языков программирования, в том числе и в язык Java»^[[27]].

IBM Rational Rose является CASE средством анализа и разработки объектно-ориентированных программ для управления предприятиями. Он позволяет создавать целостную архитектуру процессов предприятия, анализировать и моделировать бизнес процессы. Работа этого средства основана на языке UML (Unified Modeling Language), благодаря чему, Rational Rose способен решать практически любые задачи в проектировании ИС: от анализа бизнес процессов до кодогенерации на определенном языке программирования (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

«Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы»^[[28]].

Важной особенностью Rational Rose является то, что все участники проекта общаются на одном языке и используют единый инструмент.

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

Разработчики. Rational Rose поддерживает прямое и обратное проектирование. В режиме прямого проектирования разработчик создает диаграммы классов и их взаимодействия, а на выходе получает сгенерированный код на определенном языке программирования. В режиме обратного проектирования моделя строится на базе имеющегося исходного кода. Также Rose дает возможность повторного проектирование (Round-trip): разработчик описывает классы в Rose, генерирует код, дописывает необходимую полнофункциональную часть и снова закачивает в Rose, для представления того, что же система получила в результате его действий.

Специалисты по БД и аналитики данных. Rational Rose используется в качестве единого инструмента, языка и нотации для всей команды. Rational Rose Data Modeler обеспечивает поддержку БД, включая объектно-ориентированное отображение (mapping), генерацию схем и итерационную разработку.

4.2. Структура IBM Rational Rose

В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, которые определяют архитектуру системы, ее динамические и статистические аспекты.

Структура Rational Rose состоит из следующих элементов:

• Репозиторий (объектно-ориентированная база данных);
• Графический интерфейс пользователя;
• Браузер – средство просмотра проекта;
• Средства контроля проекта, сбора статистики (дают возможность обнаруживать и исправлять ошибки по мере развития проекта);
• Генератор документов – формирует выходные документы на основе информации, которая находится в репозитории;
• Средства автоматической генерации кодов программ – формируют на основе информации в диаграммах классов и компонентов файлы заголовков и файлы описаний классов и объектов;
• Анализатор кодов C++ (в виде отдельного программного модуля) - создает модули проектов Rational Rose на основе исходных текстов, определяемых пользователем.

В процессе разработки проекта при помощь Rational Rose могут быть сформированы следующие документы:

• Диаграммы UML, представляющие собой модель разрабатываемого ПО;
• Спецификации классов, объектов, атрибутов, операций;
• Заготовки текстов программ.

4.3. Работа в среде IBM Rational Rose

«Процесс работы над проектом состоит в последовательной разработке канонических диаграмм, которые в совокупности представляют интегрированную модель разрабатываемой программной системы»^[[29]]. Разработка канонических диаграмм представляет собой процесс размещения на диаграммах соответствующих графических элементов и установлении отношений между ними, их спецификации и документирование. После построения модели, проверки ее правильности генерируется программный код на одном из выбранных языков программирования. Сам же процесс разработки диаграмм схож с процессом работы в популярных средах визуального программирования. Разработчик выбирает графический элемент на панели инструментов и редактирует его набор свойств в соответствии с нотацией языка UML.

«Модель Rose – это картина системы. Она содержит все диаграммы UML, действующих лиц, варианты использования, объекты, классы, компоненты и узлы системы. Она детально описывает, что система содержит и как функционирует, поэтому разработчики могут использовать ее в качестве эскиза или чертежа создаваемой системы»^[[30]].

Основным элементом разработки и планирования проекта в IBM Rational Rose является вариант использования, или прецедент (Use Case). Он представляет собой последовательность действий (транзакций), которые системы выполняет в ответ на событие, инициируемое действующим лицом. Rational Rose поддерживает четыре представления:

• представление вариантов использования
• логическое представление
• представление компонентов
• представление размещения

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

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

В представление компонентов входят:

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

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

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

4.4. Преимущества IBM Rational Rose

«Rational Rose – мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат»^[[31]].

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

К другим преимуществам относятся:

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

Заключение

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

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

Рассмотрев в данной курсовой работе объектно-ориентированное проектирование, можно прийти к выводу, что оно имеет ряд преимуществ.

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

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

Цель курсового проекта была достигнута.

Список используемых источников

1. Антамошкин О.А. Программная инженерия. Теория и практика: учебник / О.А. Антамошкин. – Красноярск: Сиб. федер. ун-т, 2012. – 247 с.
2. Боггс У., Боггс М. UML и Rational Rose: пер. с англ. / У. Боггс, М. Боггс. – М.: Лори, 2004. – 582 с.
3. Буч, Гради, Максимчук, Роберт А., Энгл, Майкл У., Янг, Бобби Дж., Коналлен, Джим, Хъюстон, Келли А. – Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008. – 720 с.: ил. – Парал. тит. англ.
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и статистика,2006. – 544 с.: ил.
5. Вендеров А.М. Современные тхнологии создания программного обеспечения (обзор) // Jet Info – 2004. - №4 – 32 с.
6. Всяких Е.И., Зуева А.Г., Носков Б.В., Киселев С.П., Сидоренко Е.В., Слюсаренко А.И., Треско И.А. (общая редакция). Практика и проблематика моделирования бизнес-процессов. – М.: ДМК Пресс; М.: Компания АйТи, 2008. – 246 с. : ил. (Серия «ИТ-Экономика»).
7. Грэхем, Иан. Объектно-ориентированные методы. Принципы и практика. 3-е издание. : Пер. С англ. – М.: Издательский дом «Вильямс», 2004. – 880 с.: ил. – Парал. тит. Англ.
8. Давыдова Н.А., Боровская Е.В. Программирование [Электронный ресурс] : учебное пособие / Н.А. Давыдова, Е.В. Боровская. – 2 (эл.). – М.: БИНОМ. Лаборатория знаний, 2012. – 238 с. : ил. – (Педагогическое образование)
9. Избачков Ю.С., Петров В.Н., Васильева А.А., Телина И.С. – Информационные системы: Учебник для вузов. 3-е изд. – СПб.: Питер, 2011. – 544 с.: ил.
10. Ипатова Э.Р., Ипатов Ю.В. Методологии и технологии системного проектирования информационных систем: учебник / Э.Р. Ипатова, Ю.В. Ипатов. – М.: Флинта: МПСИ, 2008. – 256 с.
11. Кулябов Д.С., Королькова А.В. – Введение в формальные методы описания бизнес-процессов: Учеб. пособие. – М.: РУДН, 2008. – 173 с.: ил.
12. Леоненков А.В. Самоучитель UML. – 2-у изд., перераб. и доп. – СПб.: БХВ-Петебург, 2004. – 432 с.: ил.
13. Орлов С.А, Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с.: ил.
14. Пирогов В.Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие. – СПб.: БХВ-Петербург, 2009. – 528 с.: ил. – (Учебная литература для вызов)
15. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов – М.: Манн, Иванов и Фербер, 2013. – 544 с.
16. Сатунина А.Е., Сысоева Л.А. Управление проектом корпоративной информационной системы предприятия: учеб. пособие / А.Е. Сатунина, Л.А. Сысоева. – М.: Финансы и статистика; ИНФРА-М, 2009. – 352 с.: ил.
17. Хабибулин И.Ш. – Создание распределенных приложений на Java 2. – СПб.: БХВ-Петербург, 2002. – 704 с.: ил.

1. Буч, Гради, Максимчук, Роберт А., Энгл, Майкл У., Янг, Бобби Дж., Коналлен, Джим, Хъюстон, Келли А. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008. – 72 с.: ил. – Парал. тит. англ. ↑

2. Буч, Гради, Максимчук, Роберт А., Энгл, Майкл У., Янг, Бобби Дж., Коналлен, Джим, Хъюстон, Келли А. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008. – 51 с.: ил. – Парал. тит. англ. ↑

3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и статистика,2006. – 164 с.: ил. ↑

4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и статистика,2006. – 170 с.: ил. ↑

5. Давыдова Н.А., Боровская Е.В. Программирование [Электронный ресурс] : учебное пособие / Н.А. Давыдова, Е.В. Боровская. – 2 (эл.). – М.: БИНОМ. Лаборатория знаний, 2012. – 138 с. : ил. – (Педагогическое образование) ↑

6. Буч, Гради, Максимчук, Роберт А., Энгл, Майкл У., Янг, Бобби Дж., Коналлен, Джим, Хъюстон, Келли А. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008. – 57-58 с.: ил. – Парал. тит. англ. ↑

7. Грэхем, Иан. Объектно-ориентированные методы. Принципы и практика. 3-е издание. : Пер. С англ. – М.: Издательский дом «Вильямс», 2004. – 730 с.: ил. – Парал. тит. Англ. ↑

8. Грэхем, Иан. Объектно-ориентированные методы. Принципы и практика. 3-е издание. : Пер. С англ. – М.: Издательский дом «Вильямс», 2004. – 274 с.: ил. – Парал. тит. Англ. ↑

9. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. пособие. – М.: РУДН, 2008. – 137 с.: ил. ↑

10. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов – М.: Манн, Иванов и Фербер, 2013. – 113 с. ↑

11. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и статистика,2006. – 228 с.: ил. ↑

12. Ипатова Э.Р., Ипатов Ю.В. Методологии и технологии системного проектирования информационных систем: учебник / Э.Р. Ипатова, Ю.В. Ипатов. – М.: Флинта: МПСИ, 2008. – 79 с. ↑

13. Леоненков А.В. Самоучитель UML. – 2-у изд., перераб. и доп. – СПб.: БХВ-Петебург, 2004. – 63 с.: ил. ↑

14. Пирогов В.Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие. – СПб.: БХВ-Петербург, 2009. – 178-179 с.: ил. – (Учебная литература для вызов) ↑

15. Вендеров А.М. Современные тхнологии создания программного обеспечения (обзор) // Jet Info – 2004. - №4 – 22 с. ↑

16. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и статистика,2006. – 255 с.: ил. ↑

17. Пирогов В.Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие. – СПб.: БХВ-Петербург, 2009. – 179 с.: ил. – (Учебная литература для вызов) ↑

18. Пирогов В.Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие. – СПб.: БХВ-Петербург, 2009. – 179 с.: ил. – (Учебная литература для вызов) ↑

19. Избачков Ю.С., Петров В.Н., Васильева А.А., Телина И.С. Информационные системы: Учебник для вузов. 3-е изд. – СПб.: Питер, 2011. – 82 с.: ил. ↑

20. Избачков Ю.С., Петров В.Н., Васильева А.А., Телина И.С. Информационные системы: Учебник для вузов. 3-е изд. – СПб.: Питер, 2011. – 63 с.: ил. ↑

21. Управление проектом корпоративной информационной системы предприятия: учеб. пособие / А.Е. Сатунина, Л.А. Сысоева. М.: Финансы и статистика; ИНФРА-М, 2009. – 68-69 с.: ил. ↑

22. ? Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – М.: Финансы и статистика,2006. – 72 с.: ил. ↑

23. Пирогов В.Ю. Информационные системы и базы данных: организация и проектирование: учеб. пособие. – СПб.: БХВ-Петербург, 2009. – 182 с.: ил. – (Учебная литература для вызов) ↑

24. Антамошкин О.А. Программная инженерия. Теория и практика: учебник / О.А. Антамошкин. – Красноярск: Сиб. федер. ун-т, 2012. – 32 с. ↑

25. Орлов С.А, Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 40 с.: ил. ↑

26. Всяких Е.И., Зуева А.Г., Носков Б.В., Киселев С.П., Сидоренко Е.В., Слюсаренко А.И., Треско И.А. (общая редакция). Практика и проблематика моделирования бизнес-процессов. – М.: ДМК Пресс; М.: Компания АйТи, 2008. – 53 с. : ил. (Серия «ИТ-Экономика»). ↑

27. Хабибулин И.Ш. Создание распределенных приложений на Java 2. – СПб.: БХВ-Петербург, 2002. – 48 с.: ил. ↑

28. Боггс У., Боггс М. UML и Rational Rose: пер. с англ. / У. Боггс, М. Боггс. – М.: Лори, 2004. – 22 с. ↑

29. Леоненков А.В. Самоучитель UML. – 2-у изд., перераб. и доп. – СПб.: БХВ-Петебург, 2004. – 310 с.: ил. ↑

30. Боггс У., Боггс М. UML и Rational Rose: пер. с англ. / У. Боггс, М. Боггс. – М.: Лори, 2004. – 22 с. ↑

31. Боггс У., Боггс М. UML и Rational Rose: пер. с англ. / У. Боггс, М. Боггс. – М.: Лори, 2004. – 22 с. ↑