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

Содержание:

Введение

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

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

В своей работе я опирался на наиболее известные пособия, на труды работы таких авторов, как : Гради Буч, С.Ю. Золотов, А.М. Вендров, Ю.А. Блинков ..

1 Проектирование ИС

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

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

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

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

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

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

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

2 Методологии создания ИС

Основу технологии проектирования ИС составляет методология, которая определяет сущность, основные отличительные технологические особенности. Методология проектирования предполагает наличие некоторой концепции, принципов проектирования, реализуемых наборов методов проектирования, которые, в свою очередь, должны поддерживаться некоторыми средствами проектирования.[1]

Методология - это материальное воплощение логического жизненного цикла, которая объединяет:

- пошаговую деятельность для каждой фазы,

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

- результаты и стандарты качества для каждого вида деятельности ,

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

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

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

-Разработка, основанная на моделировании,

- Быстрая разработка приложений ,

- Приобретение готового ПО ,

- Комбинация упомянутых методологий.

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

- сложности проектируемой системы;

-необходимой полноты ее описания;

- знаний и навыков участников проекта;

- времени, отведенного на проектирование. [2]

Графическая модель процессов является информативным средством взаимодействия специалистов различных направлений и ее полезность подтверждается высказыванием «Если рисунок заменяет 1,000 слов..., то модель процессов заменяет 1,000 рисунков».

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

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

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

- Объектно-ориентированный анализ и проектирование (OOAD). Данный подход в качестве компонентов системы рассматривает объекты – объединение данных и процессов.

На рисунке 1 обозначены наиболее популярные подходы к проектированию информационных систем.[2]

Рисунок 1

2.1 Сравнение существующих методологий, их достоинства и недостатки

Структурный анализ ( SA) и структурное проектирование ( SD) – результат структурного программирования ,который появился в 1970-х ,развивался из классического системного анализа. Методологии структурного анализа используют каскадную (водопадную) модель ЖЦ ИС; наиболее известные и используемые методологии структурно анализа – SADDT, SSADM. Методы структурного анализа дорабатывались и используются на протяжении долгого времени.[2]

Основные преимущества структурных методологий:

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

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

-акцент на командной работе;

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

- допускают использование средств проверки требований;

- SSAD и IDEF0 – классические, широко известные методологии в области проектирования ИС, существующие на протяжении длительного времени и достаточно «зрелые»;

Недостатки структурных методологий:

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

- поскольку SSAD и SSADM не итеративны, то изменение требований может привести к перезапуску всего процесса разработки;

- возможны трудности при определении глубины декомпозиции – момента, когда нужно остановиться и переходить к реализации модели.[5]

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

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

Объектно-ориентированное проектирование разрабатывает аналитические модели для создания спецификаций реализации (к примеру , ТЗ). Концептуальной основой этого проектирования является объектная модель, выстраиваемая с учетом принципов абстрагирования, инкапсуляции, модульности, иерархии, типизации, параллелизма, устойчивости .Другую группу важных понятий объектно-ориентированного подхода составляют полиморфизм (способность класса принадлежать более чем одному типу) и наследование (построение новых классов на основе существующих ,с возможностью добавления или переопределения данных и методов). [2]

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

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

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

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

- Объектная модель естественна, поскольку ориентирована на человеческое восприятие мира;

- упрощение и ускорение программной реализации системы по сравнению со структурными методологиями;

- повторное использование кода в других проектах, благодаря независимости объектов и инкапсуляции, что сокращает стоимость проектирования, программирования и проверки; повторное использование кода может способствовать улучшению качества последующих проектов («Если 90% нового приложения содержит проверенные компоненты, то только 10% кода должна быть проверена с нуля» (Vivek Shah);

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

- аналитики и программисты не связаны ограничениями внедрения системы, поэтому могут формулировать проекты, которые будут соответствовать различным средам исполнения;

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

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

Недостатки объектно-ориентированных методологий:

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

-чрезмерная фокусировка на коде;

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

- определение всех необходимых для системы классов и объектов – это не такая, на самом деле, простая задача;

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

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

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

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

- функциональное описание системы в UML основано на сценариях использования, которые подходят для документирования требований, не основанных на взаимодействии с системой (таких как алгоритм или математические требования) или нефункциональных требований (такие как платформа, производительность, синхронизация, безопасность); следование шаблонам не гарантирует качества сценариев, качество зависит только от навыков создателя сценария;

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

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

Главными достоинствами объектно –ориентированного моделирования по сравнению со структурными методами являются:

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

- применение на стадии анализа моделей ,близких к реальности;

- использование при анализе и проектировании ИС систем реального времени и аппаратно-программных комплексов;

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

- поддержка итеративного, а не лавинообразного процесса проектирования;

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

- создание гораздо более открытых систем;

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

3 Суть объектно-ориентированного подхода в проектировании ИС

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

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

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

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

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

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

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

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

Составными частями ОО методологии (ООМ) являются:

- ОО анализ;

- ОО проектирование;

- ОО программирование.

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

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

В данном определении содержатся две важные части:

- ОО проектирование ведет к ОО декомпозиции. Именно поддержка ОО декомпозиции отличает ОО проектирование от структурного;

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

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

На результатах ОО анализа формируются модели, на которых основывается ОО проектирование , а оно в свою очередь создает основу для окончательной реализации системы с использованием методологии ОО программирования.[4]

Применение ОО подхода не предполагает видимой границы между этапами анализа и проектирования и на этапе проектирования используются те же самые модели, что и на этапе анализа, но описывающие более детально реализации объектов. Для создания объектно-ориентрованных моделей ИС используется унифицированный язык моделирования UML (Unified Modeling Language). UML представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы на основе объектно-ориентированного подхода и содержит стандартный набор диаграмм и нотаций самых разнообразных видов. [2]

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

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

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

3.1 Средства работы с ООП

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

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

Также используются огромное количество языков программирования и моделирования в объектно –ориентированном моделировании и программировании. Два самых популярных стандартных языка объектно-ориентированного моделирования – UML (The Unified Modeling Language) и SysML [4],а самый популярный на сегодняшний день язык программирования SysML ,однако является диалектом языка UML. Часть диаграмм языка UML не вошли в этот язык, но появились две новых. Другие диаграммы UML были дополнены и частично изменены. Базовым элементом модели стал блок, а не класс. [9]

CASE системы тоже не обошли ООП стороной, одна из систем поддерживающей OOM является Rational Rose фирмы Rational Software Corp.

Об этих всех продуктах я и расскажу подробнее.

3.1.1 Унифицированный язык визуального моделирования (UML)

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

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей следующие набор диаграмм: структурные диаграммы (Structure Diagrams); диаграммы поведения (Behavior Diagrams);диаграммы взаимодействия (Interaction Diagrams).

UML фокусируется не трех архитектурных видениях системы:

- функциональном (описывает внешнее поведение системы с точки зрения пользователя с помощью use-case диаграмм);

- статическом (в терминах атрибутов, методов, связей, классов, сообщений с помощью CRC cards, class diagrams, object diagrams);

- динамическом (sequence diagrams, collaboration diagrams, statecharts)

и имеет практическое значение в описании сервисно-ориентированных архитектур (SOAs). Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка уточнялась и была расширена для поддержки методологии Model Driven Development, MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2. Проблематика выбора. Появление новых и все более сложных объектно-ориентированных языков должно было, как представлялось, увеличить потребность в использовании объектного подхода для разработки бизнес приложений. Но так ли это на самом деле, дает ли популярность объектно-ориентированного программирования гарантию преимущества нового объектного подхода к проектированию перед традиционной структурной методологией, остается вопросом. Ниже перечислены преимущества и недостатки структурной и объектно-ориентированных методологий.[4]

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

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

В настоящее время консорциум пользователей UML Partners включает в себя представителей 3таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard,Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

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

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

- содержит механизмы расширения и специализации базовых концепций языка.

UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

UML включает внутренний набор средств моделирования (модулей?) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения.

Пользователям языка предоставлены возможности:

- строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

- добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей[3]

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм.

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

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

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

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

Стандарт UML , принятый Object Management Group (OMG) , предлагает следующий набор диаграмм для моделирования:

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

Диаграммы деятельностей - activity diagrams - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей. Диаграммы классов - class diagrams - моделируют статическую структуру классов системы и связи между классами.

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

Диаграммы последовательности - sequence diagrams – является разновидностью диаграммы взаимодействия, и отражают временную последовательность событий, происходящих в рамках варианта использования.

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

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

Диаграмма развертывания - deployment diagrams - является также разновидностью диаграммы реализации, которая описывает физическую архитектуру аппаратной и программной системы. Они отображают программные компоненты, процессоры и устройства, которые входят в архитектуру.[2]

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

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.

Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).

Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.

Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

На рис.2 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..."(к примеру, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.[3]

Рисунок 2 Взаимосвязи между диаграммами UML

3.1.2 Язык программирования C++

Язык программирования C++ – компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования. В 1990-х годах язык стал одним из наиболее широко применяемых языков программирования общего назначения.

При создании C++ стремились сохранить совместимость с языком C. Большинство программ на C будут исправно работать и с компилятором C++. Язык C++ имеет синтаксис, основанный на синтаксисе C.

Язык возник в начале 1980-х годов, когда сотрудник фирмы «Bell Laboratories» Бьёрн Страуструп придумал ряд усовершенствований к языку C под собственные нужды. До начала официальной стандартизации язык развивался в основном силами Страуструпа в ответ на запросы программистского сообщества. В 1998 году был ратифицирован международный стандарт языка C++: ISO/IEC 14882:1998 «Standard for the C++ Programming Language»; после принятия технических исправлений к стандарту в 2003 году нынешняя версия этого стандарта – ISO/IEC 14882:2003.[5]

Название «C++» происходит от C, в котором оператор «++» обозначает приращение.

Основными дополнениями языка программирования C++ по сравнению с языком C являются:

- поддержка объектно-ориентированного программирования;

- поддержка обобщённого программирования через шаблоны; дополнительные типы данных;

- исключения; пространства имён;

- встраиваемые функции;

- перегрузка операторов;

- перегрузка имён функций; ссылки и операторы управления свободно распределяемой памятью;

- дополнения к стандартной библиотеке.

Рисунок 3 Характеристики С++

В книге Бьёрн Страуструп описывает некоторые правила, которые он использовал при проектировании C++. Знание этих правил может помочь понять, почему C++ такой, каким он стал. Вот некоторые из этих правил :

- Язык C++ разработан как универсальный язык со статическими типами данных, эффективностью и переносимостью языка C;

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

- Язык C++ разработан так, чтобы давать программисту свободу выбора, даже если это даёт ему возможность выбирать неправильно.

- Язык C++ разработан так, чтобы максимально сохранить совместимость с языком программирования C, тем самым делая возможным лёгкий переход от программирования на C.

- Язык C++ избегает таких особенностей, которые зависят от платформы или не являются универсальными.

- Язык C++ не накладывает никакой избыточной нагрузки на программу, не использующую какие-либо возможности.

- Язык C++разработан так, чтобы не требовать слишком усложнённой среды программирования.

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

Кроме того, существует огромное количество библиотек C++, не входящих в стандарт. В программах на C++ можно использовать многие библиотеки C. Алфавит C++ включает:

- прописные и строчные латинские буквы и знак подчеркивания;

- арабские цифры от 0 до 9;

- специальные знаки: {, %, # и т.д.;

- пробельные символы: пробел, символы табуляции, символы перехода на новую строку.[7]

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

Своими корнями он уходит в язык Си, который был разработан в 1969—1973 годах в компании Bell Labs программистом Деннисом Ритчи (Dennis Ritchie). В начале 1980-х годов датский программист Бьерн Страуструп (Bjarne Stroustrup), который в то время работал в компании Bell Labs, разработал С++ как расширение к языку Си. Фактически вначале C++ просто дополнял язык Си некоторыми возможностями объектно-ориентированного программирования. И поэтому сам Страуструп вначале называл его как "C with classes" ("Си с классами").

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

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

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

В отличие от Си язык C++ позволяет писать приложения в объектно-ориентированном стиле, представляя программу как совокупность взаимодействующих между собой классов и объектов. Что упрощает создание крупных приложений. https://metanit.com/cpp/tutorial/1.2.php

3.1.3 Методология построения объектно-ориентированных систем IDEF4

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

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

- уровень проектирования (на уровне системы, на уровне приложений, и базовый (нижний) уровень дизайна);

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

- построение (дизайн) моделей взаимодействия (статические, динамические и модели поведения);

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

IDEF4 предусматривает дизайн моделей в трех отдельных слоях:

-проектирование системы,

-разработка приложений,

-базовый (нижний) уровень дизайна .

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

Статус явлений и объектов: любой созданный объект в IDEF4 может быть отмечен как основной (начальный), переходный или завершенный. Это позволяет проследить процесс создания системы от начала до завершения.

Дизайн Моделей: IDEF4 использует три дизайн-модели и обоснования компонентов в моделях. Статические Модели (SM) определяют неизменяемые во времени отношения между объектами (к примеру, наследование). Динамические Модели (DM) определяют связи между объектами и переходы между состояниями объектов. Модели Поведения (БМ) определяют отношения между соответствующими объектами в процессе их функционирования. Расчетное обоснование компонентов моделей подразумевает представление системы сверху вниз, что позволяет дать представление об охвате этих трех моделей и документах, которые используются для обеспечения процесса основного дизайна системы.

В IDEF4 моделирование начинается с анализа требований и для начала моделируется предметная область объектов (application domain). При дальнейшем исследовании этих объектов они помечаются как «транзитные» и в конце как «финальные». Финал моделирования зависит от индивидуальных требований, заданного уровня детализации, размера объектов. Статические модели, Динамические модели, Модели поведения и расчетное обоснование их компонент ложатся в основу базового (нижнего) уровня дизайна объектов. Вложенные слои могут быть построены в пределах каждого слоя, что позволяет уменьшить сложность систем.

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

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

На основе выявленных недостатков проектировщик может переделать существующие модели и моделировать их до тех пор, пока они не станут корректными. У объектов есть «поведение», которое описывает роль объекта в системе и «статус», которое описывает значение характеристики объекта.

Объекты идентифицируются в описании требований приложения. Они делятся на категории:

- физический объект, к примеру, дерево, автомобиль, самолет, человек;

- объект-роль с особенностями поведения, которая устанавливает его значение, к примеру, медсестра, пожарник или профессор;

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

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

- спецификация процедуры - объект, который представляет собой набор инструкций.

IDEF4 явления и объекты могут существовать в четырех различных абстракциях:

-приложения и предметные области объектов-предметов

-объекты в натуральном выражении

- спецификации объектов

-программные объекты.

В первых трех стадиях объекты отражаются так, как они существуют в природе. Программные объекты – это любые характеристики явлений. К примеру, “пассажирский самолет” становится объектом в предметной области, однако фактически этот объект определяет только «поведение» самолета по отношению к системе бронирования авиабилетов: количество мест, тип самолета, и полет назначения. Предметная область, где используется объект, является «сырьем» для дизайна объекта.[6]

3.1.4 CASE-системы, поддерживающие объектно-ориентированную методологию

В последнее время на мировом рынке программных продуктов появились различные программные средства, называемые CASE-системами, CASE-инструментами или CASE-средствами . Это такие системы, которые позволяют автоматизировать использование новых методов проектирования программного обеспечения для разработки сложных систем на всех этапах разработки (тем более на ранних стадиях разработки). Термин CASE трактуется очень широко. Изначально он расшифровывался как Computer Aided Software Ingeneering (компьютерная поддержка проектирования ПО), это было из-за автоматизации разработки программных систем. Позже понятие CASE приобрело новый смысл, его стали расшифровывать как Computer Aided System Ingeneering (компьютерная поддержка проектирования систем), а CASE-средства все больше стали ориентироваться на создание спецификаций, проектирование и моделирование сложных систем широкого назначения. [4]

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

Самой известной CASE системой, поддерживающей OOM ,является семейство CASE-средств ООП Rational Rose фирмы Rational Software Corp.

Rational Rose предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на разных языках и выпуска проектной документации. Rational Rose использует синтез-методологию ОО анализа и проектирования, основанную на подходах трех ведущих специалистов в этой области: Буча, Рамбо и Джекобсона и поддерживает универсальную нотацию для моделирования объектов UML. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (таким, как C++, Visual C, Java, Smalltalk, Visual Basic, PowerBuilder, Ada, и др.). Основной вариант - Rational Rose позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды. Более того, Rational Rose содержит средства реинжиниринга программ, которые обеспечивают повторное использование программных компонент в новых проектах.

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

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

Средства автоматической генерации кодов программ на языке С++ используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый в итоге скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор создает модули проектов в форме Rational Rose на основе информации, которая содержится в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, получаемая в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. К примеру, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель, и какие элементы выходной модели следует выводить на экран. И в итоге, Rational Rose обеспечивает возможность повторного использования программных компонент.

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

-диаграммы классов;

-диаграммы состояний;

-диаграммы взаимодействия;

-диаграммы модулей;

-диаграммы процессов;

-спецификации классов, объектов, атрибутов и операций

-заготовки текстов программ;

-модель разрабатываемой программной системы.

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

Тексты программ являются заготовками для дальнейшей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp (заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов //##.

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

Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо хранится на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

Для управляемой подмодели предусмотрены следующие операции:

- загрузка подмодели в память;

- выгрузка подмодели из памяти;

- сохранение подмодели на диске в виде отдельного файла;

- установка защиты от модификации;

- замена подмодели в памяти на новую.

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

Rational Rose функционирует на разных платформах ( таких, как IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX)).[8]

3.2 Принципы объектного подхода

Главными понятиями ООП являются объект и класс:

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

- Класс – это большое количество объектов, которые связаны общностью структуры и поведения. Основными понятиями объектно-ориентированного подхода являются объект и класс.[11]

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

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

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

Концептуальной основой ООП является объектная модель, которая строится с учетом следующих принципов:

- абстрагирование;

-инкапсуляция;

- модульность;

- иерархия;

- типизация;

-параллелизм;

- устойчивость.[10]

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

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

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

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

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

Иерархия - ранжированная (упорядоченная) система абстракций. Главными видами иерархических структур, применительно к сложным системам, являются структура классов и структура объектов .

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

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

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

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

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

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

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

- Промежуточные результаты вычисления выражений.

- Локальные переменные вызова процедур.

- Собственные переменные (глобальные).

- Данные, которые сохраняются между вызовами основной программы.

- Данные , которые остаются без изменений в различных версиях программы.

- Данные, которые переживают создавшую их программу.

Обычно языки программирования реализовывают первые три уровня, а последние три связываются с технологией базы данных.[4]

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

Во-первых ,объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования Опыт показал, что при использовании таких языков, как Smalltalk, Object Pascal, C++, CLOS и Ada вне объектной модели, их наиболее сильные стороны либо игнорируются, либо применяются неправильно.

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

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

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

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

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

Заключение

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

Список источников

1. Проектирование информационных систем: учебное пособие / С. Ю. Золотов- Томск: Томский государственный университет систем управления и радиоэлектроники, 2015, 117 с.

2. Проектирование информационных систем: учебное пособие / А.А. Дубаков; Томский политехнический университет. –Томск: Изд-во Томского политехнического университета,2011. – 258 с.

3. Проектирование информационных систем / Ю.А. Блинков -Саратов: Саратовский государственный университет, 2011. 377 с.

4. Объектно-ориентированная методология разработки сложных систем : учебное пособие / Т.В. Глотова -Пенза: Пензенский Государственный Университет,2001 ,49 с.

5.Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина- Екатеринбург: «Форт-Диалог Исеть», 2014. 240 с.

6. Методология и инструментарий моделирования бизнес-процессов: учебное пособие/ О.А. Цуканова – СПб.: Университет ИТМО, 2015. – 100 с.

7. Информатика. Программирование на C++: учебно-методическое пособие / Т.Е. Мамонова; Томский политехнический университет. – Томск: Изд-во Томского политехнического университета, 2011, 118 с.

8. Проектирование программного обеспечения экономических информационных систем: Учебник./ А.М. Вендров -М. Финансы и статистика , 2000 , 352 с

9. Процесс Разработки Программно-Аппаратных Систем на Основе Визуального Моделирования с Использованием SysML/UML / Д. Рыжов, Д. Иванов , 2008 [Электронный ресурс]

10. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. — Интернет-университет информационных технологий - ИНТУИТ.ру, 2005. [Электронный ресурс]

11. Автоматизированные информационные системы :курс лекций /Е.В. Комарова ,Пенза,2013 [Электронный ресурс]

12. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд. , Пер. с англ./ Г. Буч -М.: "Издательство Бином",СПб:"Невский диалект", 1998. -560с. [Электронный ресурс]