Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf
Добавлен: 29.03.2023
Просмотров: 129
Скачиваний: 1
ВВЕДЕНИЕ
Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности. Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации.
В настоящее время ни одна организация не обходится без электронно-вычислительных машин и информационных систем, автоматизирующих какой-либо важный процесс.
Проектирование – это процесс составления описания объекта. Это важный этап жизненного цикла разработки программного обеспечения. Описание объекта может быть оформлено в виде текста, таблиц и диаграмм.
Проектирование информационных систем охватывает три основные области:
- проектирование объектов данных, которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов;
- учет конкретной среды и технологии, а именно: топологии сети, конфигурации аппаратных средств и т.д.
Целью исследования является анализ материалов об объектно-ориентированном подходе и обзор наиболее популярных программных средств реализации данного подхода.
ГЛАВА 1. ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ
Сущность объектно-ориентированного подхода
Основной идеей объектно-ориентированного проектирования информационных систем является рассмотрение предметной области и логического решения задачи с точки зрения объектов (понятий или сущностей).
В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. Например, в случае информационной системы ВУЗа среди понятий должны присутствовать Преподаватель (Lecturer), Студент (Student) и Заведующий кафедрой (Head Of Chair).
В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы.
В процессе конструирования или объектно-ориентированного программирования обеспечивается реализация разработанных компонентов, таких как класс Lecturer на языке C++, C#, Java, Smalltalk или Visual Basic.
Успешность проектов информационных систем в различных отраслях и эффективность их внедрения обусловлены, прежде всего, достаточно строгим определением объектов управления и оптимизируемых бизнес-процессов. Не случайно создание информационной системы производится в контексте общей оптимизации бизнеса и зачастую предполагает реинжиниринг бизнес-процессов предприятия [1].
Базовым средством фиксации (документирования) результатов проектирования систем посредством этих методологий является унифицированный язык моделирования (Unified Modeling Language, UML).
Объектно-ориентированный подход использует объектную декомпозицию, то есть поведение системы описывается в терминах взаимодействия объектов.
Класс - это абстракция множества сущностей реального мира, объединенных общностью структуры и поведения.
Объект - это элемент класса, то есть абстракция определенной сущности.
Необходимо отметить, что объекты активны, у них есть не только внутренняя структура, но и поведение, которое описывается так называемыми методами объекта. Например, может быть определен класс "пользователь", характеризующий "пользователя вообще", то есть ассоциированные с пользователями данные и их поведение (методы).
После этого может быть создан объект "пользователь Иванов" с соответствующей конкретизацией данных и, возможно, методов.
Следующую группу важнейших понятий объектного подхода составляют инкапсуляция, наследование и полиморфизм.
Основным инструментом борьбы со сложностью в объектно-ориентированном подходе является инкапсуляция - сокрытие реализации объектов (их внутренней структуры и деталей реализации методов) с предоставлением во вне только строго определенных интерфейсов.
Понятие " полиморфизм " может трактоваться как способность объекта принадлежать более чем одному классу. Введение этого понятия отражает необходимость смотреть на объекты под разными углами зрения, выделять при построении абстракций разные аспекты сущностей моделируемой предметной области, не нарушая при этом целостности объекта. (Строго говоря, существуют и другие виды полиморфизма, такие как перегрузка и параметрический полиморфизм, но нас они сейчас не интересуют.)
Наследование означает построение новых классов, на основе существующих, с возможностью добавления или переопределения данных и методов. Наследование является важным инструментом борьбы с размножением сущностей без необходимости. Общая информация не дублируется, указывается только то, что меняется. При этом класс -потомок помнит о своих "корнях". [2]
Базовыми составляющими объектно-ориентированного подхода являются:
а) унифицированный процесс;
б) унифицированный язык моделирования;
в) шаблоны проектирования.
Унифицированный процесс – это процесс разработки программного обеспечения (ПО), который обеспечивает упорядоченный подход к распределению задач и обязанностей в организации-разработчике. Унифицированный процесс охватывает весь жизненный цикл ПО, начиная с определения требований и заканчивая сопровождением, и представляет собой обобщенный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем.
Неотъемлемой частью унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода. Следует отметить, что Унифицированный процесс и UML разрабатывались совместно.
На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования. Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО. [3]
В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:
1) описание системы в виде объектов больше соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;
2) сущности реального мира, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;
3) объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы. Это облегчает решение проблем:
а) адаптации системы к изменению существующих или появлению новых требований;
б) сопровождения системы на разных стадиях жизненного цикла;
в) повторного использования компонентов.
4) объектно-ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться его автономной работы;
5) Case-средства, поддерживающие объектно-ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации кодогенерации. Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая кодогенерация (например, экранов или функций обработки данных) возможна лишь в редких случаях. может резко сократить затраты и повысить качество разработки ПО. [4]
Все диаграммы UML можно условно разбить на две группы, первая из которых ‒ общие диаграммы. Общие диаграммы практически не зависят от предмета моделирования и могут применяться в любом программном проекте без оглядки на предметную область, область решений и т.д.
Диаграмма вариантов использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.
Диаграмма вариантов использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?
На диаграмме вариантов использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2, между которыми устанавливаются следующие основные типы отношений:
- ассоциация между действующим лицом и вариантом использования 3;
- обобщение между действующими лицами 4;
- обобщение между вариантами использования 5;
- зависимости (различных типов) между вариантами использования 6.
На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7. Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм. Основные элементы нотации представлены на рисунке 1.
Рисунок 1 - Нотация диаграммы вариантов использования
Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.
На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:
- ассоциация между классами (с множеством дополнительных подробностей);
- обобщение между классами;
- зависимости (различных типов).
Некоторые элементы нотации, применяемые на диаграмме классов, показаны на рисунке 2.
Рисунок 2 - Нотация диаграммы классов
Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.
В сущности, диаграммы автомата, как это следует из названия, представляют собой граф переходов состояний, нагруженный множеством дополнительных деталей и подробностей.
На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1, и один тип отношений ‒ переходы 2, но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. (см. рисунок 3)
Рисунок 3 - Нотация диаграммы автомата
Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.