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

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

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

Модель проектирования ИС на основе объектно-ориентированного подхода представлена на рис. 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

---