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

Применение объектно-ориентированного подхода при проектировании ()

Содержание:

Введение

  В век всеобщей компьютеризации ни для кого не тайна, что без компьютерной техники и спец программного обеспечения фактически нереально обойтись. Применение специализированных программ позволяет улучшить качество выполняемой работы, упростить человеческий труд, ускорить выполнение технологического процесса, облегчает хранение и передачу информации – перечислять все достоинства можно практически до бесконечности. Почти всегда применяемые программные комплексы хранят производственную данные, и такие сведения обязаны быть доступны некому количеству пользователей и, часто, пользователи работают с данными сразу. Эти мысли послужили основой идеи, в соответствии с которой данные должны быть организованны в информационные базы, для управления которыми, обширно употребляются системы управления базами данных (СУБД). Проектирование финансовых информационных систем (ЭИС) - логически непростая, трудозатратная и долгая работа, которая требует высочайшей квалификации принимающих участие в ней профессионалов. Сначала 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что огромные проекты стали выполнятся с отставанием от графика либо с превышением сметы затрат, который был разработан продукт не владел требуемыми многофункциональными возможностями, продуктивность его была мала, качество получаемого программного обеспечения не устраивало потребителей. Аналитические исследования и обзоры, которые выполняются в течение ряда крайних лет ведущими заграничными аналитиками, демонстрировали не очень обнадеживающие показатели. Например, к примеру, в 1995г. компания StandishGroup проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы: Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

Рост спроса на программные системы в наше время является следствием того, что по мере удешевления, увеличения надежности и роста размера производства компов автоматизация труда человека при помощи компа становится все более прибыльной. Из года в год возрастает сложность и разнообразие систем, получивших в международной научно-технической практике название систем, интенсивно использующих программное обеспечение (Software Intensive Systems, SIS). Для разработок SIS типичны крупномасштабные проекты: десятки или сотни разработчиков, месяцы или годы разработки, огромные денежные средства.

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

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

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

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

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

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

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

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

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

2. модель объекта и ее элементы,преимущества и недостатки;

3. Язык UML

4. применение объектно-ориентированного подхода при проектировании ИС.

1. Теоретическая часть

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

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

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

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

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

1.2.    Методы объектно-ориентированного анализа и проектирования ПО. Язык UML

Концептуальной основой объектно-ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.) наиболее четко сформулированы Гради Бучем. ПРИЛОЖЕНИЕ.1 (Рис.1)

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

UML - это преемник того поколения методов ООАП, которые появились в конце 1980-х и начале 1990-х годов. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. ПРИЛОЖЕНИЕ 2 (Рис.2).

Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, ПРИЛОЖЕНИЕ 3 (Рис.3) однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

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

- обеспечить независимость от конкретных языков программирования и процессов разработки.

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

- стимулировать рост рынка объектно-ориентированных инструментальных средств;

-интегрировать лучший практический опыт.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями - производителями ПО (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler и др.). Полное описание UML можно найти на сайтах http://www.omg.org и http://www.rational.com.

Стандарт UML версии 1.1, принятый OMG в 1997 г., содержит следующий набор диаграмм:

Структурные (structural) модели:

-диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними; ПРИЛОЖЕНИЕ 4 (Рис. 4.)

-диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы; ПРИЛОЖЕНИЕ 5 (Рис. 5.)

-диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы. ПРИЛОЖЕНИЕ 6 (Рис. 6.)

Модели поведения (behavioral):

-диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой); ПРИЛОЖЕНИЕ 9 (Рис. 9. )

-диаграммы взаимодействия (interaction diagrams): ПРИЛОЖЕНИЕ 7 (Рис. 7.)

-диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами; ПРИЛОЖЕНИЕ 8 (Рис. 8.)

-диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое; ПРИЛОЖЕНИЕ 10 (Рис. 10.)

-диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления. ПРИЛОЖЕНИЕ 11 (Рис. 11.)

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

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

Диаграмма вариантов использования является самым общим представлением многофункциональных условий к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом "сценарием варианта использования" или "потоком событий" (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования [11]. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

Достоинства модели вариантов использования заключаются в том, что она:

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

-определяет системный интерфейс;

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

-используется для написания тестов;

-является основой для написания пользовательской документации;

-хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

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

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

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

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

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

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

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

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

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

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

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:

-стереотипы;

-тегированные (именованные) значения;

-ограничения.

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

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

Ограничение - это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML.

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

1.3.    Преимущества и недостатки объектно-ориентированного подхода к проектированию

Достоинства ООП:

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

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

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

Недостатки ООП обуславливаются следующим:

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

- Документирование классов – задача более трудная, чем это было в случае процедур и модулей.

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

- Код для обработки сообщения время от времени «размазан» по почти всем способам (по другому говоря, обработка сообщения просит не 1-го, а почти всех способов, которые могут быть описаны в различных классах).

Главной недочет ООП - некое понижение быстродействия за счет более трудной организации программной системы.

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

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

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

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

Преимущества объектной модели:

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

1. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных словно программирование. Страуструп отмечает: "Не всегда очевидно, как в полной мере использовать преимущества такого языка, как С++. Существенно повысить эффективность и качество кода можно просто за счет использования С++ в качестве "улучшившего С" с элементами абстракции данных. Однако намного более значительным достижением является введение иерархии классов в процессе проектирования. Именно это называется объектно-ориентированным проектированием и именно здесь преимущества С++ демонстрируются наилучшим образом". Опыт показал, что при использовании таких языков, как Smalltalk, Object Pascal, С++, CLOS и Аdа, вне объектной модели, их наиболее сильные бока или игнорируются, или применяются неправильно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.  Практическая часть

2.1. Постановка задачи

ПРИМЕР ИСПОЛЬЗОВАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

Рисунок 12.

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

На начальной стадии (или стадии формирования требований) строится начальная диаграмма вариантов использования .

Рис.12 Начальная диаграмма вариантов использования

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

• Кто использует систему непосредственно?

• Кто отвечает за эксплуатацию системы?

• Какое внешнее оборудование используется системой?

• Какие другие системы взаимодействуют с данной системой?

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

Структура программной системы описывается при помощи не­скольких диа­грамм классов, основная из которых представляет из себя диаграмму пакетов , а другие диаграммы открывают содержимое всех пакетов. При построении диаграммы классов предметной области выделение этих классов (классов сущностей) может быть анало­гично выделению сущностей в процессе моделирования данных. Данные классы должны иметь концептуальный характер и отвечать на вопрос "что?", а не "как?". Начальный список может быть составлен следующим образом:

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

Рис. 13 Диаграмма последовательности для варианта использования "Зарегистрировать налогоплательщика"

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

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

Рис. 14 Диаграмма классов предметной области

Определяются действия (операции), выполняемые каждым классом. При определении операций нужно учитывать следующие рекомендации:

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

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

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

Полученная в результате диаграмма классов предметной области показана на рис. 14

Заключение по задачи.

Что хотел бы отметить, что на примере налоговой инспекции мы убедились в целесообразности использования объектно – ориентированного подход. Но это не предел и перспектива развития объектно – ориентированного метода проектирования очень многообразна. Его отличает следующее: « объектно-ориентированные системы более открыты и легче поддаются внесению изменений, по­скольку их конструкция базируется на устойчивых формах. Это дает возмож­ность системе развиваться равномерно и не приводит к полной ее переработке даже в случае значительных изменений начальных условий. » К недочетам относятся: некое понижение продуктивности деятельности ПО и высочайшие начальные затраты, эти недостатки не столь существенны в целом и на чаше весов перевес будет в сторону плюсов.

Заключение

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

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

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

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

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

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

Список использованной литературы

1. Арлоу, Джим UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование / Джим Арлоу , Айла Нейштадт. - Москва: ,2007. - 624 c.2.

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

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

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

6. Вайсфельд, М. Объектно-ориентированное мышление / М. Вайсфельд. - М.: Питер, 2014. - 338

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. Колесов, Ю. Б. Моделирование систем. Объектно-ориентированный подход / Ю.Б. Колесов, Ю.Б. Сениченков. - М.: БХВ-Петербург, 2006. - 192 c.

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

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

ПРИЛОЖЕНИЕ 1

Рисунок 1.

ПРИЛОЖЕНИЕ 2

Рисунок .

ПРИЛОЖЕНИЕ 3

Рисунок 3.

ПРИЛОЖЕНИЕ 4

Рисунок 4.

ПРИЛОЖЕНИЕ 5

Рисунок 5.

ПРИЛОЖЕНИЕ 6

Рисунок 6.

ПРИЛОЖЕНИЕ 7

Рисунок 7.

ПРИЛОЖЕНИЕ 8

Рисунок 8.

ПРИЛОЖЕНИЕ 9

Рисунок 9.

ПРИЛОЖЕНИЕ 10

Рисунок 10.

ПРИЛОЖЕНИЕ 11

Рисунок 11

ПРИЛОЖЕНИЕ 12

Рисунок 12