Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

Предметом исследования является унифицированный язык моделирования.

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

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

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

Задачи курсовой работы:

1. Ознакомиться с основными принципами построения объектной модели и этапами проектирования информационных систем

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

3. Изучить методики объектно-ориентированного анализа

4. Сделать выводы о достоинствах и недостатках объектно-ориентированного подхода

1. ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Основные принципы построения объектной модели

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

Проблемы, стимулировавшие развитие ООП:

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

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

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

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

Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula (1967), Smalltalk (1970-е гг.), C++ (1980-е гг.) и языком моделирования UML (1990-е гг.). На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования данных, в особенности модель «сущность—связь».

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

• инкапсуляция (encapsulation);

• наследование (inheritance);

• полиморфизм (polymorphism);

• абстрагирование (abstraction);

• модульность (modularity);

• иерархия (hierarchy).

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

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

Полиморфизм — свойство объектов, при котором действие с одинаковыми именами вызывает различное поведение для различных объектов. Полиморфизм предполагает возможность одинакового именования разных действий. Эта особенность имеет два аспекта:

• возможность одинакового именования статических методов;

• возможность одинакового именования динамических методов.

В UML для описания полиморфизма вводятся понятия операции

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

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

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

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

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

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

1.2 Этапы проектирования ИС.

Выделим следующие этапы проектирования ИС:

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

Исследование предметной области предусматривает следующие шаги:

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

2. Анализ деятельности в предметной области.

2.1. Структурно-логический анализ деятельности.

2.1.1. Анализ путей.

2.1.2. Анализ связности (прочности и сцепления) компонентов предметной области.

2.2. Анализ производительности.

2.3. Экономический анализ.

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

1. Спецификации требований к проектируемой системе.

2. Конструирование концептуальной модели предметной области.

3. Спецификации обработки данных в проектируемой системе.

4. Спецификации пользовательского интерфейса системы.

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

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

Различают виды декомпозиции действий на основе:

• состава выходных данных;

• входных данных;

• представлений о промежуточных результатах;

• представлений о фазах обработки;

• представлений об альтернативных действиях.

Модели потоков отражают движение различных видов носителей (материальных, финансовых, информационных и др.).

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

Модель классов определяет систему классификации информации о предметной области, основанную на семантическом анализе. Среди важных характеристик модели классов можно выделить отношения наследования, включения или использования. В основе лежит объектно-ориентированный подход, основой которого является представление о предметной области как совокупности взаимодействующих друг с другом объектов, рассматриваемых как экземпляр определенного класса. Классы образуют иерархию на основе наследования. Объектно-ориентированный подход содержится в современных языках высокого уровня Smalltalk, Object Pascal, C++, Java.

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

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

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

1. Схемы первичной классификации.

2. Схемы вторичной классификации.

3. Схемы детализации.

4. Схемы спецификации функциональных возможностей.

5. Схемы локальных моделей данных.

6. Схемы потоков.

7. Диаграммы переходов.

8. Схемы спецификации пользовательского интерфейса.

9. Схемы распределенной обработки данных.

10. Структурированные карты объектов.

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

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

• материальных потоков;

• финансовых потоков;

• информационных потоков; • потоков событий;

• отражающие сразу несколько типов потоков.

Правила конструирования схем потоков следующие:

• вся схема строится для одного исходного функционального или организационного элемента;

• каждый функциональный и организационный элементы спецификации должны иметь уникальный идентификатор;

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

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

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

• накопителями финансовых потоков являются счета бухгалтерского учета;

• накопителями материальных потоков являются места постоянного или временного размещения материальных ценностей;

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

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

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

Одиночные ИС реализуются на автономном компьютере (чаще всего ПК), могут содержать несколько простых приложений, рассчитаны на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых «настольных» СУБД или с помощью файловой системы и диалоговой оболочки для ввода, редактирования и обработки данных.

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

Корпоративные ИС ориентированы на использование в масштабе предприятия (организации) для различных рабочих групп, могут поддерживать территориально разнесенные узлы или сети. Отличительная особенность таких систем – обеспечение доступа из подразделений к центральной или распределенной БД предприятия (организации), а также к информационным ресурсам рабочей группы. Такие системы реализуются на основе архитектуры «клиент – сервер» со специализацией серверов. При этом используются корпоративные SQL-серверы и соответствующие инструментальные средства. Групповые и корпоративные информационные системы могут строиться на основе следующих способов:

• многотерминальные централизованные вычислительные системы;

• системы на основе локальной сети ПК;

• системы с архитектурой «клиенет – сервер»:

• системы с распределенными вычислениями;

• офисные системы;

• системы на основе Интернет / интранет-технологий.

Среди средств разработки информационных систем выделяют следующие основные группы: • традиционные системы программирования;

• инструменты для создания файл-серверных приложений;

• средства разработки приложений «клиент – сервер»;

• средства автоматизации делопроизводства и документооборота;

• средства разработки Интернет / интранет-приложений;

•средства автоматизации проектирования (CASE-технологии). Традиционные системы программирования представлены средствами создания приложений на алгоритмических языках программирования (Си, Паскаль, Бейсик и др.). Инструментальные средства программирования могут быть представлены набором утилит (редактор текстов, компилятор, компоновщик и отладчик) или интегрированной программной средой. Развитием традиционных систем программирования является объектноориентированное и визуальное программирование.

Основой разработки файл-серверных приложений для локальных сетей ПК являются инструментальные средства «персональных» СУБД, реализованные в виде диалоговой интегрирующей среды, предоставляющей три уровня доступа:

• программирование и создание приложений;

• создание и ведение структуры БД, а также интерактивная генерация макетного приложения и его компонентов (меню, формы или окна, отчеты, запросы и программные модули);

• использование диалоговой среды и генераторов конечным пользователем для создания, ведения и просмотра БД, а также формирования простых отчетов и запросов. Среди инструментальных средств реализации приложений с архитектурой «клиент – сервер» выделяют следующие:

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

• независимые от СУБД инструменты для создания приложений «клиент – сервер»;

• средства поддержки распределенных информационных приложений.

Среди этой группы следует выделить инструментальные средства быстрой разработки приложений RAD (Rapid Application Development), обеспечивающие реализацию удаленного доступа к СУБД по двухзвенной схеме «клиент – сервер»; связь клиентских приложений с серверами БД с помощью непроцедурного языка структурированных запросов SQL; целостность БД, включая целостность транзакций; поддержку хранимых процедур на серверах БД; реализацию клиентских и серверных триггеровпроцедур; генерацию элементов диалогового интерфейса и отчетов.

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

• средства автоматизации учрежденческой деятельности Office Automation;

• системы управления электронным документооборотом EDMS • EDI – электронный документооборот и UN/EDIFACT – европейский стандарт EDI в задачах логистики; • средства обеспечения коллективной работы Groupware;

• средства автоматизации документооборота Workflow. Данная группа средств включает в свой состав: текстовые редакторы для подготовки и корректировки документов; процессоры электронных таблиц для расчетов, анализа и графического представления данных; программы генерации запросов по образцу из различных БД; сетевые планировщики для назначения рабочих встреч и совещаний; средства разработки и демонстрации иллюстративных материалов для презентаций; словари и системы построчного перевода и др. Эти средства представляют собой отдельные пакеты (Win Word, Word Perfect, Excel, Lotus), интегрированный пакет программ (MS Works) или согласованный набор пакетов (Microsoft Office, Corel Perfect Office).

Средства программирования Интернет/интранет-приложений представлены различными системами программирования на интерпретируемых языках Java, Java Script, Tel и др. Построенные с использованием этих средств приложения могут загружаться с любого webсервера сети и интерпретироваться на клиентском узле. Это обеспечивает платформенную независимость при расширении функциональных возможностей.

Средства автоматизации проектирования приложений (CASEтехнологии) предназначены для анализа предметной области, проектирования и генерации программных реализаций. Новые тенденции в реализации приложений связаны с промышленным характером разработки программного обеспечения.

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

• комплект специальных инструментальных средств быстрой разработки прикладных ИС – RAD (Rapid Application Development);

• технологический комплекс разработки программного обеспечения RUP (Rational Unified Process) фирмы Rational Software;

• технология разработки программного обеспечения Extreme Programming (XP).

Средства RAD базируются на объектно-ориентированном подходе, когда информационные объекты формируются как действующие модели и их функционирование согласовывается с пользователем. Разработка приложений на основе RAD ведется с использованием множества готовых объектов, хранимых в виде базы данных. Объектно-ориентированные инструменты RAD в среде GUI позволяют на основе набора стандартных объектов, для которых инкапсулированы атрибуты и внутренние процедуры, формировать простые приложения без написания кода программы. Использование в RAD визуального программирования позволяет еще более упростить и ускорить процесс создания информационных систем. Логика приложения, реализованного с помощью RAD, является событийноориентированной, что подразумевает наличие определенного набора событий: открытие и закрытие окон, нажатие клавиши клавиатуры, срабатывание системного таймера, получение и передача управления каждым элементом экрана, некоторые элементы управления базой данных. Наиболее полным описанием процесса разработки программного обеспечения, включающим методики выполнения работ на каждой стадии жизненного цикла системы, является Rational Unified Process (RUP), уникальность которого заключается в том, что это стандартизованный процесс разработки программного обеспечения, используемый многими крупными компаниями по всему миру.

RUP обладает следующими преимуществами по сравнению с другими процессами:

• обеспечивает четко организованный подход к назначению задач и требований в рамках организации разработки;

• основан на объектно-ориентированных технологиях разработки программного обеспечения и может использоваться для широкого круга проектов и организаций;

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

• создает описание программного продукта, позволяющего восстановить процесс его разработки;

• осуществляет полную поддержку различными инструментальными средствами, позволяющими автоматизировать работы на всех стадиях жизненного цикла программы и сохранить артефакты разработки в электронном виде; • предоставляет возможность гибкой и перенастраиваемой конфигурации, позволяющей использовать его как для малых групп разработчиков, так и для больших организаций. В качестве графической нотации в RUP используется Unified Modeling Language (UML), являющийся стандартом для представления объектных моделей. В UML артефакты разработки представляются диаграммами, описывающими структуру программы и ее поведение. Другим подходом к разработке программного обеспечения является технология Extreme Programming или ХР.

Основными элементами данного подхода являются:

• быстрая разработка программного продукта на основе стандартных шаблонов проектирования;

• постоянное взаимодействие разработчиков с заказчиками системы;

• минимизация затрат на документирование проекта;

• максимальное использование программных тестов («unittests») для проверки функциональности и корректности исходных кодов программ;

• использование рефакторингов для расширения функциональности системы и устранения ее недостатков.

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

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

Основными задачами реинжиниринга программного обеспечения являются:

• восстановление информации о программной системе, ее документации и спецификаций;

• обнаружение аномалий в архитектуре программной системы, моделях и исходном коде;

• проверка соответствия исходного кода программы решениям, принятым на этапах анализа и проектирования;

• перевод исходных кодов программ с одного языка программирования на другой.

Внедрение системы в действие.

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

• проведение опытной эксплуатации;

• проведение приемочных испытаний.

Сопровождение ИС.

• выполнение работ в соответствии с гарантийными обязательствами

• послегарантийное обслуживание.

1.3 Основные понятия объектно-ориентированного подхода к проектированию информационных систем

Основным понятиям объектно-ориентированного подхода относятся: объект; класс; атрибут; операция; полиморфизм; наследование; компонент; пакет; подсистема; связь.

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

Структура и поведение схожих объектов определяют общий для них класс.

Класс – это множество объектов, связанных общностью свойств, поведения, связей и семантики. Любой объект является экземпляром класса.

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

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

Результат операции зависит от текущего состояния объекта. Виды операций:

a) Операции реализации– реализуют требуемую функциональность.

b) Операции управления -управляют созданием и уничтожением объектов (конструкторы и деструкторы).

c) Операции доступа – дают доступ к закрытым атрибутам.

d) Вспомогательные операции (как правило закрытые)– служат для реализации операций других видов.

Полиморфизм – способность скрывать множество различных реализаций под единственным общим именем или интерфейсом.

Интерфейс – это совокупность операций, определяющих набор услуг класса или компонента.

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

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

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

Между элементами объектной модели существуют различные виды связей.

Соединение (link) – физическая или концептуальная связь между объектами, позволяющая им взаимодействовать.

Виды соединений:

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

• Агрегация – более сильный тип ассоциативной связи между целым и его частями.

• Композиция – усиленная агрегация, когда часть не может существовать без целого (пример: человек и голова).

• Зависимость – связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе.

• Обобщение – это связь «тип – подтип». Оно реализует механизм наследования, позволяет поддерживать полиморфизм.

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

• Реализация – связь между контрактом (либо интерфейс, либо вариант использования) и его исполнением (классом, подсистемой, компонентой и т. д.).

1.4. Базовые составляющие объектно-ориентированного подхода

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

- Унифицированный процесс;

- Унифицированный язык моделирования;

- шаблоны проектирования.

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

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

На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования. Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.

2. МЕТОДОЛОГИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА

2.1 Методики объектно-ориентированного анализа

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

Классические подходы. Они основывается на классическом распределении по категориям. Кандидаты для классов и объектов, предлагаемые С. Шлаером и С. Меллолором:

- материальные предметы

- роли (учитель, телезрители, и т. д.)

- события (прерывание, требование)

- взаимодействие (встреча, пересечение).

При моделировании баз данных Р. Росс прелагает свой список:

-люди;

-места;

-предметы;

-организации;

-концепции;

-события;

Коад и Йордан предложили свой список кандидатов:

- структуры;

- другие системы;

- устройства;

- события;

- роли, в которых находятся пользователи;

- местоположение;

- организационные единицы.

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

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

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

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

CRC карточки. (Class – Responsibilities - Collaborators, Класс Ответственность - Участники). Это простой и эффективный способ анализа

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

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

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

- внешние сущности;

- хранилища данных;

- хранилища управляющих сущностей.

Кандидаты для классов:

- потоки данных;

- потоки управления.

Методология ОМТ (Object Modeling Technique) поддерживает две первые стадии разработки программных систем: стадию анализа требований и предварительной разработки и стадию проектирования (конструирования) [3].

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

Методология SA/SD (Structured Analysis/Structured Design) содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.

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

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

Набор диаграмм состояния процессов играет ту же роль, что и динамическая модель в методологии ОМТ.

Диаграммы зависимостей объектов отражают зависимости между хранилищами данных. Эти диаграммы аналогичны объектной модели методологии ОМТ.

Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы.

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

В то же время методология SA/SD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.

Методология JSD (Jackson Structured Development) предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или ОМТ. Методология JSD, разработанная Майклом Джексоном в середине 80-х гг., особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом ее разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы.

Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и ОМТ.

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

• разработка действий и объектов;

• разработка структуры объектов;

• разработка исходной модели;

• разработка функций;

• разработка временных ограничений;

• реализация системы.

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

На фазе разработки структуры объектов действия каждого объекта частично упорядочиваются во времени.

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

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

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

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

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

Тем не менее методология JSD может успешно применяться для проектирования и реализации следующих типов прикладных программных систем:

• параллельные асинхронные программные системы, в которых процессы могут взаимно синхронизировать друг друга;

• программные системы реального времени; методология JSD ориентирована именно на такие системы;

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

• высокоуровневый анализ — методология JSD не обеспечивает широкого понимания проблемы, она неэффективна для абстракции и упрощения проблем;

• разработка баз данных — это слишком сложная проблема для методологии JSD.

Методология OSA (Object-Oriented System Analysis) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.

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

Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориентированным анализом систем, специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы: OSA реализована в системе программирования C++ на рабочей станции Hewlett-Packard 700 под управлением ОС HP-UX 9.01.

Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления (модели) проектируемой системы:

• модель зависимостей между объектами;

• модель поведения объектов;

• модель взаимодействия объектов.

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

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

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

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

Технология RUP (Rational Unified Process) представляет собой программный продукт, разработанный компанией Rational Software, которая в настоящее время входит в состав IBM.

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, СММ и др.). Ее основными принципами являются:

• итерационный и инкрементный (наращиваемый) подход к созданию ПО;

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

• построение системы на базе архитектуры ПО.

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

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

Методическую основу ТС ПО корпорации Oracle составляет метод Oracle (Oracle Method) — комплекс методов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят:

• CDM (Custom Development Method) — разработка прикладного ПО;

• PJM (Project Management Method) — управление проектом;

• AIM (Application Implementation Method) — внедрение прикладного ПО;

• В PR (Business Process Reengineering) — реинжиниринг бизнес- процессов;

• OCM (Organizational Change Management) — управление изменениями и др.

Метод CDM оформлен в виде консалтингового продукта CDM Advantage — библиотеки стандартов и руководств (включающего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method. По существу, CDM является методическим руководством по разработке прикладного ПО с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.

В соответствии с CDM ЖЦ ПО формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов:

• стратегия (определение требований);

• анализ (формулирование детальных требований к системе);

• проектирование (преобразование требований в детальные спецификации системы);

• реализация (написание и тестирование приложений);

• внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

• эксплуатация.

Компания Borland в результате развития собственных разработок и приобретения целого ряда компаний представила интегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (Application Life Cycle

Management, ALM). В соответствии с технологией Borland процесс создания ПО включает в себя пять основных этапов:

• определение требований;

• анализ и проектирование;

• разработка;

• тестирование и профилирование;

• развертывание.

Выполнение всех этапов координируется процессом управления конфигурацией и изменениями. Определение требований реализуется с помощью системы управления требованиями CaliberRM, которая стала частью семейства продуктов Borland в результате покупки компании Starbase. CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генерации документов MS Word на базе заданных шаблонов. Система обеспечивает экспорт данных в таблицы MS Access и импорт из MS Word. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

Средство анализа и проектирования Together ControlCenter разработано компанией TogetherSoft. В основе его применения лежит один из вариантов подхода «Быстрой разработки ПО» под названием Feature Driven Development (FDD).

Together ControlCenter — интегрированная среда проектирования и разработки, поддерживающая визуальное моделирование на UML с последующим написанием приложений для платформ J2EE (Java) и .Net (С#, C++ и Visual Basic). Кроме базовой версии имеется уменьшенный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere и среды разработки Jbuilder.

В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями — при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменяется текст на языке программирования. Это исключает необходимость вручную модифицировать модель или переписывать код. Контроль версий осуществляется благодаря функциональной интеграции Together и системы StarTeam. Поддерживается также интеграция с системой управления конфигурацией Rational ClearCase.

Инструментальные средства тестирования появились в составе комплекса Borland в результате покупки компании Optimizeit. К ним относятся Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace.

Первые две системы позволяют выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, a Optimizeit Profiler — в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-npH- ложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.

Сущность концепции ALM сосредоточена в системе управления конфигурацией и изменениями: именно она объединяет основные фазы ЖЦ ПО. Такой системой является StarTeam, разработанная компанией Starbase. Она выполняет функции контроля версий, управления изменениями, отслеживания дефектов, управления требованиями (в интеграции с CaliberRM), управления потоком задач и управления проектом.

StarTeam совместима с интерфейсом Microsoft Source Code Control и интегрируется с любой системой разработки, которая поддерживает этот API. Кроме того, в системе реализованы средства интеграции со средствами разработки и моделирования Together, J Builder, Delphi, C++Builder и C#Builder.

В технологии Borland выделяется три уровня интеграции. Функциональная (touch-point) интеграция позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системах Together, C#Builder и Visual Studio .Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечивает единого рабочего пространства, вынуждает пользователя переключать окна и приводит к дублированию процессов управления структурой проекта. Встроенная (embedded) интеграция обеспечивает работу с одной системой непосредственно в среде другой. Например, не выходя из среды разработки Jbuilder, можно просматривать графики производительности, которые создает система Optimizeit. Самый высокий уровень интеграции — синергетический (synergistic), позволяющий сочетать функции двух различных продуктов незаметно для разработчиков. Для большинства продуктов Borland и других поставщиков синергетическая интеграция пока остается делом будущего, однако ее принципы уже начинают реализовываться.

Компания Computer Associates предлагает комплексы инструментальных средств поддержки различных процессов ЖЦ ПО:

1. All Fusion Modeling Suite — интегрированный комплекс CASE- средств, включающий следующие продукты:

• AllFusion Process Modeler (BPwin) — функциональное моделирование;

• AllFusion Erwin Data Modeler (ERwin) — моделирование данных;

• AllFusion Component Modeler (Paradigm Plus) — объектно- ориентированный анализ и проектирование с использованием UML и возможностью генерации кода;

• AllFusion Model Manager (Model Mart) — организация совместной работы команды разработчиков;

• AllFusion Data Model Validator (ERwin Examiner) — проверка структуры и качества моделей данных.

2. AllFusion Change Management Suite — комплекс средств управления конфигурацией и изменениями;

3. AllFusion Process Management Suite — средства управления процессами и проектами для различных типов приложений.

CASE-средства ERwin и BPwin были разработаны фирмой Logic Works, которая в 1998 г. вошла в состав PLATINUM Technology, а затем Computer Associates.

BPwin — средство моделирования бизнес-процессов, реализующее метод IDEF0, а также поддерживающее диаграммы потоков данных и IDEF3. В процессе моделирования BPwin позволяет переключиться с нотации IDEF0 на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. BPwin поддерживает функционально-стоимостный анализ (АВС).

Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Sybase, DB2, Microsoft SQL Server и др.) и реверсный инжиниринг существующей БД. ERwin выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений.

Для управления групповой разработкой используется средство Model Mart, обеспечивающее многопользовательский доступ к моделям, созданным с помощью ERwin и BPwin. Модели хранятся на центральном сервере и доступны для всех участников группы проектирования.

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

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

• создание библиотек решений. Model Mart позволяет формировать библиотеки стандартных решений, включающие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости «сборки» больших систем. На основе существующих баз данных с помощью ERwin возможно восстановление моделей (реверсный инжиниринг), которые в процессе анализа пригодности их для новой системы могут объединяться с типовыми моделями из библиотек моделей;

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

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

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

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

2.2 Достоинства и недостатки объектно-ориентированного подхода

Достоинства ООП заключаются в следующем:

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

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

• объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;

• объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

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

Модель проектирования ИС на основе объектно-ориентированного подхода представлена в Приложении 1.

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

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

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

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

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

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

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

К недостаткам ООП относятся:

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

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

ЗАКЛЮЧЕНИЕ

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

Поставленные цели и задачи для данной курсовой работы выполнены.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения.

2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.

3. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.

4. ГОСТ Р ИСО/МЭК 15271–02. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств).

5. ОРММ ИСЖТ 2.01–00. Требования к составу, содержанию и оформлению документов при создании ИС. – М. : ВНИИАС МПС России, 2000. – 62 с.

6. ОРММ ИСЖТ 5.03–00. Процессы жизненного цикла ИС и программных средств – М. : ВНИИАС МПС России, 2000. – 48 с.

7. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с.

8. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 582 с.

9. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с.

10. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.

11. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2015. – 176 с.

12. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2016. - 240 с.

13. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2014. - 496 с.

14. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с.

15. Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.

16. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с.

17. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 2015. - 672 с.

18. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.

19. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.

20. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose. – www.intuit.ru

21. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru

22. UML спецификация. – www.omg.com

ПРИЛОЖЕНИЕ 1

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

ПРИЛОЖЕНИЕ 2

Зависимость эффективности применения функционально-ориентированного и объектно-ориентированного подходов от количества выполненных проектов