Содержание:

ВВЕДЕНИЕ

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

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

В большинстве случаев используемые программные комплексы хранят производственную информацию, и эта информация должна быть доступна некоторому количеству пользователей и, зачастую, пользователи работают с данными одновременно. Эти идеи послужили основой концепции, согласно которой данные должны быть организованны в базы данных, для управления которыми, широко используются системы управления базами данных (СУБД).

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты.

В числе причин неудач фигурируют: нечеткая и неполная формулировка требований к программному обеспечению, недостаточное вовлечение пользователей в работу над проектом, неудовлетворительное планирование.

Актуальность выбранной темы исследования связана с тем, что на фоне неудач, выгодно отличается объектно-ориентированный подход к проектированию программного обеспечения. Он устраняет эти и другие недостатки, он обладает богатым набором изобразительных средств.

Вот почему, целью моей курсовой работы является раскрытие современных методов и средств проектирования, в частности в объектно-ориентированном подходе к проектированию информационной системы.

В ходе выполнения курсовой работы должны быть решены следующие задачи:

• рассмотреть сущности и преимущества объектно-ориентированного подхода;
• выбрать средства объектно-ориентированного подхода;
• изучить результаты применения объектно-ориентированного подхода при проектировании информационной системы.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

1.1. Сущность объектно-ориентированного подхода

Объектно-ориентированное программирование (ООП) – это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.

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

Тогда и было введено понятие класса, параметры которого задавались единожды, а после в коде оставлялись только ссылки на класс, чтобы код самостоятельно «собрал» объект.

Существуют два основных подхода к декомпозиции систем.

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

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

Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы.

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными принципами ее построения являются:

• абстрагирование (abstraction);
• инкапсуляция (encapsulation);
• модульность (modularity);
• иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

• типизация (typing);
• параллелизм (concurrency);
• устойчивость (persistence).

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

Выбор правильного набора абстракций для заданной предмет­ной области представляет собой главную задачу объектно-ориентированного проектирования.

Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение.

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

Абстрагирование фокусирует внимание на внешних особенностях объекта инкапсуляция (или, иначе, огра­ничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта.

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барье­ры между абстракциями.

Иерархия — это ранжированная или упорядоченная система аб­стракций, расположение их по уровням.

Основными видами иерар­хических структур применительно к сложным системам являются: структура классов (иерархия по номенклатуре) и структура объек­тов (иерархия по составу).

Типизация — это ограничение, накладываемое на класс объектов и препятствующее взаимозаменяемости различных классов (или сильно сужающее ее возможность).

Параллелизм - свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.

Устойчивость - свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся:

• объект;
• класс;
• атрибут;
• операция;
• полиморфизм (интерфейс);
• компонент;
• связи.

1. Объект определяется как осязаемая сущность (tangible entity) предмет или явление (процесс), имеющие четко определяемое поведение.

Объект может представлять собой абстракцию некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект).

Объект обладает:

• состоянием;
• поведением;
• индивидуаль­ностью.

Состояние объекта — одно из возможных условий, в которых он может существовать, оно изменяется со временем. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств.

Состояние объекта определяется значениями его свойств (атрибутов) и связями с другими объектами.

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

Каждый объект обладает уникальной индивидуальностью.

Индивидуальность — это свойства объекта, отличающие его от всех других объектов.

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

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

2. Класс —это множество объектов, связанных общностью свойств, поведения, связей и семантики.

Класс инкапсулирует(объединяет) в себе данные (атрибуты) и поведение (операции). Класс является абстрактным определением объекта и служит в качестве шаблона для создания объектов. Класс изображается в виде прямоугольника, разделенного на три части.

В первой содержится имя класса, во второй — его атрибуты. В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом).

Любой объект является экземпляром (instance) класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.

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

Атрибут — это элемент информации, связанный с классом. Например, у класса Company могут быть атрибуты Name, Address и Number Of Employees.

Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).

У атрибута можно определить три возможных значения этого параметра. Рассмотрим каждый из них. Пусть имеется класс Employee с атрибутом Address и класс Company:

Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В таком случае класс Company может изменить значение атрибута Address класса Employee. В соответствии с нотацией UML общему атрибуту предшествует знак «+».

Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Класс Employee будет знать значение атрибута Address и сможет изменять его, но класс Company не сможет его ни увидеть, ни редактировать.

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

Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам в иерархии наследования.

Допустим, имеется два различных типа сотрудников — с почасовой оплатой и на окладе. Таким образом, потомками класса Employee будут два класса — HourlyEmp и SalariedEmp.

Защищенный атрибут Address можно просмотреть или изменить из классов Employee, HourlyEmp и SalariedEmp, но не из класса Company. Нотация UML для защищенного атрибута — это знак «#».

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

4. Операция — это реализация услуги, которую можно запросить у любого объекта данного класса.

Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией.

В объектных и объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и являются составной частью определения класса.

Операции отражают поведение объекта. Операция-запрос не изменяет состояния объекта. Операция-команда может изменить состояние объекта. Результат операции зависит от текущего состояния объекта.

Операции реализуют связанное с классом поведение (иначе говоря, реализуют обязанности класса — responsibilities). В широком смысле обязанности класса делятся на две категории:

Знание (определяется атрибутами класса):

• наличие информации о данных или вычисляемых величинах;
• наличие информации о связанных объектах.

Действие (определяется операциями класса):

• выполнение некоторых действий самим объектом;
• инициация действий других объектов;
• координация действий других объектов.

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

5. Полиморфизм - способность класса принадлежать более чем одному типу.

Полиморфизм — это способность скрывать множество различных реализаций под единственным общим интерфейсом.

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

Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения свойств (атрибутов) и поведения (операций).

Объектно-ориентированная система изначально строится с учетом ее эволюции. Наследование и полиморфизм обеспечивают возможность определения новой функциональности классов с помощью создания производных классов - потомков базовых классов.

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

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

6. Компонент— относительно независимая и замещаемая часть системы, выполняющая четко определенную функцию в контексте заданной архитектуры. Компонент представляет собой физическую реализацию проектной абстракции и может быть:

• компонентом исходного кода;
• компонентом времени выполнения (run time);
• исполняемым компонентом.

Компонент обеспечивает физическую реализацию набора интерфейсов.

7. Связи. Между элементами объектной модели существуют различные виды связей. К основным типам связей относятся:

• связи ассоциации,
• зависимости
• обобщения.

Ассоциация (association)— это семантическая связь между классами. Ее изображают на диаграмме классов в виде обыкновенной линии.

Ассоциация отражает структурные связи между объектами различных классов.

Зависимость (dependency)— связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе.

Зависимость — слабая форма связи между клиентом и сервером (клиент зависит от сервера и не имеет знаний о сервере). Зависимость изображается пунктирной линией, направленной от клиента к серверу.

Обобщение (generalization)— связь «тип-подтип» реализует механизм наследования (inheritance). Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования.

Она позволяет одному классу наследовать все атрибуты, операции и связи другого. В языке UML связи наследования называют обобщениями и изображают в виде стрелок от класса-потомка к классу-предку.

1.2. Преимущества и недостатки объектно-ориентированного подхода

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

Преимуществами объектно-ориентированного подхода являются следующие:

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

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

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

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

К недостаткам объектно-ориентированного подхода относятся:

• Усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа.

Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов.

Для небольших проектов более эффективным может оказаться применение классических методов разработки.

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

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

ГЛАВА 2. РЕАЛИЗАЦИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1. Унифицированный язык моделирования UML

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

Язык моделирования — это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования.

Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс — это описание шагов, которые необходимо выполнить при разработке проекта.

Унифицированный язык моделирования UML (Unified Modeling Language) — это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг.

Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8.

Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

В UML используются следующие виды диаграмм (структура диаграмм изображена в приложении А):

Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

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

Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.

В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств) и артефактов, развёрнутых на них.

В UML 2 на узлах разворачиваются артефакты, в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними.

Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах).

Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части.

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

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

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

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

Диаграмма вариантов использования (Use case diagram, диаграмма прецедентов) — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.

Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации.

В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.

В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

Диаграмма сотрудничества — Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений.

На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.

Диаграмма обзора взаимодействия — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

2.2. Выбор средств объектно-ориентированного подхода

Для построения диаграмм на языке UML существует большое количество программных продуктов. Рассмотрим несколько примеров таких программных продуктов.

IBM Rational Rose

IBM Rational Rose - популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ.

Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

Любые участники проекта - аналитики, специалисты по моделированию, разработчики и другие - могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта.

Rational Rose позволяет визуализировать, понять и уточнить требования и архитектуру перед началом создания кода. Обладая способностью представлять пользовательский интерфейс отдельно от бизнес-логики и данных, Rational Rose позволяет держать контроль над разработкой программного обеспечения.

Это дает возможность исключить затраты сил на ненужные переделки. Использование одного инструмента на протяжении всего жизненного цикла разработки помогает строить «правильную» систему для заказчика.

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

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

• интеграция с MS Visual Studio, которая включает поддержку на уровне прямой и обратной генерации кодов и диаграмм Visual Basic и Visual С++ с использованием ATL (Microsoft Active Template Library), Web-Классов, DHTML и протоколов доступа к различным базам данных;
• непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX.
• поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов технологии Microsoft - COM+ (DCOM);
• полная поддержка компонентов CORBA и J2EE, включая реализацию технологии компонентной разработки приложений CBD (Component-Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language);
• полная поддержка среды разработки Java-приложений, включая прямую и обратную генерацию классов Java формата JAR, а также работу с файлами формата CAB и ZIP.

Visual Paradigm

Visual Paradigm для UML — это редактор UML и UML CASE среды, а также инструмент, разработанный для помощи в разработке программного обеспечения.

VP-UML поддерживает все известные стандарты моделирования, такие как унифицированный язык моделирования (UML) 2.4, SysML, ERD, DFD, BPMN 2.0, ArchiMate 2.0 и т. д.

Он разработан для поддержки разработчиков программного обеспечения в сфере сбора информации, планирования разработки программного обеспечения (анализа вариантов использования), разработки кода, моделирования типа программы, моделирования данных и т. д.

Версия «Community Edition» доступна бесплатно для некоммерческого использования.

Возможности программы:

• UML-моделирование, разработка программного обеспечения с использованием UML, поддержка различных видов UML, поддержка различных структур дизайна.
• Моделирование вариантов использования, инфографика, лог действий, создание диаграммы последовательности, генерация отчетов.
• Поддержка PDF, HTML и MS Word форматов, программа, полностью настраиваемая под любого пользователя, и позволяет публикацию ваших разработок в интернете.
• Разработка собственного кода
• Доступна «схема последовательности» Java
• Доступен Java перевод туда и обратно и C++ перевод туда и обратно (round trip).

Visual Paradigm обеспечивает очень неплохую интеграцию со средствами разработки, такими как Visual Studio, Eclipse, Borland JBuilder, NetBeans/Sun ONE, IntelliJ IDEA, Oracle JDeveloper, BEA WebLogic Workshop.

Также умеет генерировать код для: Java, C++, CORBA IDL, PHP, XML Schema, Ada, Python, C#, VB .NET, Object Definition Language (ODL), Flash ActionScript, Delphi, Perl, Objective-C, and Ruby.

Реверсировать умеет: Java, C++, CORBA IDL, PHP, XML Schema, Ada, Python, C#, Java class, .NET dll and exe, JDBC.

В стандартной установке Visual Paradigm можно получить БД: MySQL, MS SQL Server, Oracle, HSQL, Sybase ASE, Sybase SQL Anywhere, PostgreSQL, CloudScape/Derby, DB2, Ingres, OpenEdge, Informix, Firebird, FrontBase, Cache, SQLite.

Diagram Designer

Diagram Designer — бесплатный создатель диаграмм. Очень доступный для понимания и управления, бесплатный инструмент для создания диаграмм, представляет собой редактор векторной графики, специально оптимизированный под создание диаграмм, построения различных схем, с возможностью организовать слайд шоу.

Все действия в программе Diagram Designer выполняются довольно просто, поэтому создание редактирование объектов не вызовет затруднений.

Diagram Designer поддерживает форматы BMP, EMF, GIF, PCX, ICO, JPEG, MNG, PNG и WMF, имеет встроенный просмотрщик для слайд-шоу и калькулятор с поддержкой уравнений.

Создавая диаграммы и графики в этой программе, можно использовать множество графических элементов - геометрические примитивы, линии, надписи, цветные заливки, соединительные стрелки и т.д. Готовые проекты сохраняются в сжатом виде и занимают совсем немного места.

Интерфейс программы представляет окно для диаграммы в центре, панель элементов справа и текущие элементы слева.

Для ввода текста для всех элементов используется один и тот же диалог. С его помощью можно задать не только текст, но и форматирование.

Программа не требовательна к ресурсам и может нормально работать даже на слабых компьютерах.

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

2.3. Результаты применения объектно-ориентированного подхода

В настоящее время объектно-ориентированный подход к программированию является стандартом де-факто. 

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

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

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

• небольшой команде программистов (обычно от 2 до 10 человек);
• тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);
• итерационная модель разработки, основанная на тесном взаимодействии с за­казчиком — по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.

При использовании методологии RAD большое значение имеют опыт и профессио­нализм разработчиков.

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

Основные принципы методологии RAD можно свести к следующему:

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

Возможность использования подобного подхода в значительной степени является результатом применения принципов объектно-ориентированного проектирования.

Применение объектно-ориентированных методов позволяет преодолеть одну из главных трудностей, возникающих при разработке сложных систем — колоссаль­ный разрыв между реальным миром (предметной областью описываемой пробле­мы) и имитирующей средой.

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

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

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

Объектно-ориентированные системы предъявляют повышенные требования к аппаратуре. При этом время получения готовой программы может сократиться в 2-3 раза, программы будут выглядеть яснее, лучше приспособлены для повторного использования.

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

ЗАКЛЮЧЕНИЕ

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

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

В соответствии с различными представлениями об организации методики проектирования информационной системы принято делить на объектные и функциональные (структурные).

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

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

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

Наибольшую популярность в создании проектов информационных систем, основанных на объектно-ориентированном подходе, получило моделирование с помощью UML.

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных средств, организационно-экономических, технических систем и других систем различной природы.

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

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

Во второй главе курсовой работы рассмотрен язык моделирования UML, описаны средства для объектно-ориентированного проектирования и описаны результаты применения объектно-ориентированного подхода.

Таким образом, считаю, что цель курсовой работы выполнена, поставленные задачи решены.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения. 2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.

3. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.

4. ГОСТ Р ИСО/МЭК 15271–02. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств).

5. Коваленко В.В. Проектирование информационных систем, учебник - М.: Форум - 2018, 320 с.

6. Советов Б.Я. Методы и средства проектирования информационных систем и технологий (1-е изд.) учебник – Академия – 2018, 320 с.

7. Григорьев М. В., Григорьева И. И. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ. Учебное пособие для вузов – Юрайт – 2019, 318 с.

8. CyberForum.ru - форум программистов и системных администраторов. [Электронный ресурс]. - Режим доступа: http://www.cyberforum.ru/.

9. it-black.ru – Компьютер – это просто!. [Электронный ресурс]. - Режим доступа: https://www.it-black.ru/.

10. Сайт компании IBM, раздел, посвященный продуктам Rational. [Электронный ресурс]. - Режим доступа: http://www-01.ibm.com/software/ru/rational/.

11. Стандарты проектной документации. [Электронный ресурс]. - Режим доступа: http://www.rugost.com/.

ПРИЛОЖЕНИЯ

Приложение А

Рисунок 1. Структура диаграмм UML

Приложение Б

Рисунок 2. Интерфейс IBM Rational Rose

Приложение В

Рисунок 3. Интерфейс Visual Paradigm

Приложение Г

Рисунок 4. Интерфейс Diagram Designer