Файл: Применение объектно -ориентированного подхода при проектировании информационной системы.pdf
Добавлен: 04.04.2023
Просмотров: 63
Скачиваний: 1
СОДЕРЖАНИЕ
1.1. Основные понятия объектно-ориентированного проектирования
1.2. Методы объектно-ориентированного анализа и проектирования ПО. Язык UML
1.3. Преимущества и недостатки объектно-ориентированного подхода к проектированию
1.4. Основные принципы построения объектной модели. Основные элементы объектной модели
Наличие этих свойств у объекта позволяет в объектно-ориентированном подходе добиться параллельности и автономности разработки отдельных компонент системы, т.е. возможно создание прототипов с дальнейшей интеграцией отдельных прототипов в единую систему и использование итерационного подхода к разработке ИС.
Другое достоинство объектно-ориентированного подхода состоит в упрощении скопления типовых проектных решений с тем, чтоб в последующих разработках новых ИС выполнить сбор новой системы из готовых элемент. Эта особенность связана с тем, что классы объектов повторяются в определенной мере при переходе от одной ИС к другой, а для повторяющихся классов уже запрограммированы методы, разработаны и описаны структуры объектов данных.
Модель проектирования ИС на основе объектно-ориентированного подхода представлена на рис. 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