Файл: Применение объектно -ориентированного подхода при проектировании информационной системы.pdf

Введение

В век всеобщей компьютеризации ни для кого не тайна, что без компьютерной техники и спец программного обеспечения фактически нереально обойтись. Применение специализированных программ позволяет улучшить качество выполняемой работы, упростить человеческий труд, ускорить выполнение технологического процесса, облегчает хранение и передачу информации – перечислять все достоинства можно практически до бесконечности. Почти всегда применяемые программные комплексы хранят производственную данные, и такие сведения обязаны быть доступны некому количеству пользователей и, часто, пользователи работают с данными сразу. Эти мысли послужили основой идеи, в соответствии с которой данные должны быть организованны в информационные базы, для управления которыми, обширно употребляются системы управления базами данных (СУБД). Проектирование финансовых информационных систем (ЭИС) - логически непростая, трудозатратная и долгая работа, которая требует высочайшей квалификации принимающих участие в ней профессионалов. Сначала 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]. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

---