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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 25.06.2023

Просмотров: 80

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

ВВЕДЕНИЕ

На заре вычислительной техники с появлением первых программ быстро стала очевидной необходимость средств описания программного обеспечения.

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

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

Со временем сложность программ увеличивалась. Успешное решение сложной задачи потребовало ее разбиения на фрагменты. В языках программирования возникло и закрепилось новое понятие процедуры. Так же, как и алгоритм, процедура представляет собой законченную последовательность действий или операций, направленных на решение отдельной задачи [4].

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

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

При разработке крупной информационной системы возникает совокупность задач.

Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированнного анализа и проектирования (ООАП). В рамках этого подхода возникало много направлений, период конца 80-х и начало 90-х годов принято называть «войной методов», завершение которой (хотя споры продолжаются) связано с появлением языка UML.


Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, он непосредственно унифицирует методы ведущих специалистов в этой области Буча, Рамбо и Джекобсона, однако обладает большими возможностями [1]. Язык UML прошел процесс стандартизации в рамках консорциума OMG (Object Management Group) и с 1997 года является стандартом OMG.

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

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

Обзор UML

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

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

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

UML - это язык

Язык состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования сло­варь и правила ориентированы на концептуальное и физическое представление системы. Язык моделирования, подобный UML, является стандартным средством для составления «чертежей» программного обеспечения.

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


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

UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика (см. "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой. Так решается первая из перечисленных выше проблем.

UML - это язык специфицирования

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

UML - это язык конструирования.

UML не является языком визуального программирования, но модели, создан­ные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

Компания, выпускающая программные средства, помимо исполняемого кода производит и другие артефакты, в том числе следующие:

– требования к системе;

– архитектуру;

– проект;

– исходный код;

– проектные планы;

- тесты;

– прототипы;

– версии, и др.

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

1.1. Строительные блоки UML


Словарь языка UML включает три вида строительных блоков:

– сущности;

– отношения;

– диаграммы.

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

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

Класс (Class) - это описание совокупности объектов е общими атрибутами, опе­рациями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции.

Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представ­лять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации.

Ин­терфейс редко существует сам по себе - обычно он присоединяет­ся к реализующему его классу или компоненту.

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

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

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


Активным классом (Active class) называется класс, объекты ко­торого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздей­ствие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют со­бой элементы, деятельность которых осуществляется одновре­менно с деятельностью других элементов.

Узел (Node) - это элемент реальной (физической) сис­темы, который существует во время функционирования программного комплекса и представляет собой вычисли­тельный ресурс, обычно обладающий как минимум неко­торым объемом памяти, а часто еще и способностью обра­ботки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой.

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

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

Поведенческие сущности (Behavioral things) являются динамическими состав­ляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведен­ческих сущностей.

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

- диаграммы классов

- диаграммы объектов;

- диаграммы прецедентов;

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

- диаграммы кооперации;