Преподаватель который помогает студентам и школьникам в учёбе.

Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (Объектно-ориентированный подход)

Содержание:

Введение

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

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

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

1. Структура объектно-ориентированного программирования

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

В основе объектно-ориентированного подхода лежит объектная декомпозиция, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно - ориентированной архитектурой также тесно связаны объектно- ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно - ориентированными языками программирования: Simula , Smalltalk, C++ и языком моделирования UML . На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования данных, в особенности модель «сущность-связь».

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

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

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

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

1.2. Объектно-ориентированный подход

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

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

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

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

1.3. Основные понятия объектно-ориентированного подхода

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

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

Объект - предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Состояние объекта — одно из возможных условий, в которых он может существовать, оно изменяется со временем. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Состояние объекта определяется значениями его свойств (атрибутов) и связями с другими объектами. Поведение определяет действия объекта и его реакцию на запросы от других объектов. Поведение характеризует воздействие объекта на другие объекты, изменяющее их состояние. Иначе говоря, поведение объекта полностью определяется его действиями. Каждый объект обладает уникальной индивидуальностью. Индивидуальность — это свойства объекта, отличающие его от всех других объектов. Структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект» являются эквивалентными. Класс - это множество объектов, связанных общностью структуры и поведения. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.

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

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

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

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

Унифицированный язык моделирования UML1 (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. UML — это преемник того поколения методов объектно-ориентированного анализа и проектирования, которые появились в конце 1980-х и начале 1990-х годов. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

UML предназначены для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. К механизмам расширения UML относятся:

стереотипы;
тегированные (именованные) значения;
ограничения.

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

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

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

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

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

2. Диаграммы

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения.

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

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

В UML выделяют следующие типы диаграмм:

– диаграммы вариантов использования (usecase diagrams) – для моделирования бизнес-процессов организации (требований к системе);

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

– диаграммы поведения системы (behavior diagrams);

– диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга;

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

– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. Это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами;

– диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.

2.1.Диаграммы вариантов использования

В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально - они почти всегда использовались и крайне редко документировались. Идея описания функциональных требований в виде вариантов использования (use case) была сформулирована в 1986 г. Иваром Якобсоном. Эта идея была признана конструктивной и получила широкое одобрение. Впоследствии наиболее значительный вклад в решение проблемы определения сущности вариантов использования и способов их описания внес Алистер Коберн.

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

Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования. На рис.1 показаны некоторые варианты использования для Система проверки кредитных карточек; человеческие фигурки здесь обозначают действующих лиц, овалы - варианты использования, а линии и стрелки — различные связи между действующими лицами и вариантами использования.

Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. На рис.1 действующие лица: клиент, корпоративный клиент, индивидуальный клиент, торговые предприятия, субсидирующие финансовые инфраструктуры. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования.

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

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

extends

user

торговые предприятия

субсидирующие финансовые институты

индивидуальный клиент

корпоративный клиент

клиент

extends

user

торговые предприятия

субсидирующие финансовые институты

индивидуальный клиент

корпоративный клиент

клиент

extends

Рисунок 1 Система проверки кредитных карточек

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

В дополнение к связям между действующими лицами и вариантами использования существуют два других типа связей (см. рис.1): "использование" (uses) и "расширение" (extends) между вариантами использования. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку.

Выбор применяемой связи определяется следующими правилами:

• связь "расширение" следует применять при описании изменений в нормальном поведении системы;

• связь "использование" следует применять для избегания повторов в двух (или более) вариантах использования. Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.

Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей "использование" и "расширение"). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.

2.2. Диаграммы классов

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

ассоциации (например, клиент может сделать заказ);
подтипы (частный клиент является разновидностью клиента).

Рисунок 2 покупки в интернет магазине

На рисунке 2 присутствуют три класса: авторизация, каталог товаров, заявка. Связывающие классы линии отражают взаимодействие между классами.

Построение диаграмм классов можно рассматривать в различных аспектах:

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

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

• аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

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

2.3. Диаграммы деятельности

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

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

товар выбран

поиск по разделу

поиск по ключу

товар не выбран

покупатель

интернет магазин

вход в каталог интернет магазина

переход к разделу каталога

исследование товара

положить товар в корзину

ввод критерии поиска

поиск в каталоге

формирование результатов поиска

выполнить заказ в корзине

подготовка к приему заказа

Рисунок 3 диаграмма деятельности покупателя в интернет магазине

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

2.4. Образцы

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

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

В 1970-х годах Кристофер Александер, профессор архитектуры Калифорнийского университета написал несколько книг, документируя образцы в гражданском строительстве и архитектуре.

В языке UML образец представляется с помощью кооперации со стереотипом «pattern». Кооперация (collaboration) определяется как описание совокупности взаимодействующих объектов, реализующих некоторое поведение (например, в рамках варианта использования или операции класса). Кооперация имеет статическую и динамическую части. В статической части (на диаграмме классов) описываются роли, которые могут играть объекты и связи в экземпляре данной кооперации. Динамическая часть состоит из одной или более диаграмм взаимодействия, показывающих потоки сообщений, которыми обмениваются участники кооперации.

Достоинства применения образцов при проектировании ПО заключаются в следующем:

Возможность многократного использования. Повторное использование решений из уже завершенных успешных проектов позволяет быстро приступить к решению новых проблем и избежать типичных ошибок. Разработчик получает прямую выгоду от использования опыта других разработчиков, избежав необходимости вновь и вновь «изобретать велосипед».
Применение единой терминологии. Профессиональное общение и работа в группе (команде разработчиков) требует наличия единого базового словаря и единой точки зрения на проблему.

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

3. Языки программирования

Практически все современные алгоритмические языки поддерживают принципы объектно-ориентированного программирования. Наибольшее распространение в последнее время получили три объектно-ориентированных языка: С++, Object Pasсal и Visual Basic.

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

Visual Basic — язык программирования, а также интегрированная среда разработки программного обеспечения, разрабатываемые корпорацией Microsoft. Язык Visual Basic унаследовал дух, стиль и отчасти синтаксис своего предка — языка BASIC, у которого есть немало диалектов. В то же время Visual Basic сочетает в себе процедуры и элементы объектно-ориентированных и компонентно-ориентированных языков программирования. Интегрированная среда разработки VB включает инструменты для визуального проектирования пользовательского интерфейса, редактор кода с возможностью IntelliSense и подсветкой синтаксиса, а также инструменты для отладки приложений.

3.1. С++

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

Сегодня идея использования Объектно-ориентированного языка едва ли может удивить кого-либо, но в конце восьмидесятых годов она воспринималась как насмешка, – многим программистам и менеджерам в индустрии и академических кругах Объектно-ориентированный концепции казались привлекательными, но возникали большие сомнения в их применимости. В 1979 году Бьёрн Страструп из Bell Laboratories спроектировал и реализовал язык, изначально названный «С с классами», расширяющий язык С концепциями, которые были заимствованы у языка Simula 67, – первого Объектно-ориентированного языка. Язык вскоре стал хитом и в следующие два десятилетия язык интенсивно развивался за счет введения таких конструкций, как шаблоны (форма универсальности) и множественное наследование.

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

Каждая C++ переменная имеет тип, но, не все типы основаны на классах, и следовательно, не все значения являются объектами. Тип может быть встроенным, производным (с возможными комбинациями механизмов порождения), определенным пользователем.

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

3.2. Java

Язык Java появился в 1995 году в результате внутреннего исследовательского проекта Sun Microsystems, руководимого Джеймсом Гослингом (ключевой вклад в разработку языка внесли также Билл Джой, Гей Стил и Джилард Брачча). Проект Java вначале предполагался для создания апплетов – модулей для сетевых приложений. Как отмечалось ранее, апплеты не стали доминирующей моделью, как провозглашалось изначально, но использование Java быстро расширилось на многие другие области.

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

Тесная связь между языком программирования и платформой, которая основана на виртуальной машине, называемой JVM (Java Virtual Machine).
Акцент на переносимость, отражаемый в лозунге: «Раз напишешь, всюду выполнишь». Компилятор Java транслирует Java-программу в байт-код JVM, который затем на многих платформах интерпретируется или компилируется в машинный код.
Синтаксис, общий стиль языка и базисные операторы заимствованы из семейства языков C – C++.
Строго типизированная Объектно-ориентированная модель, которая включает многие механизмы, изучаемые в этой книге: классы, наследование, полиморфизм, динамическое связывание, универсальность (добавленная в последующих версиях). Некоторыми опущенными элементами являются множественное наследование (допускается множественное наследование интерфейсов, как мы увидим), контракты и агенты. Объектно-ориентированная часть системы типов не включает примитивные типы.
Помимо того, что предлагает язык, разработку поддерживает множество библиотек, ориентированных на различные области приложения.

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

Программы Java состоят из классов, как и в других Объектно-ориентированных языках. Но Java предлагает модульную структуру, стоящую над уровнем классов – пакеты. Пакет – это группа классов.

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

Управляющие структуры Java в основном заимствованы от C и C++. Но Java лишен таких составляющих как указатели шаблоны и множественное наследование, что сделало его менее мощным по сравнению с C++.

3.3. C#

C# был ответом Microsoft в конкурентной борьбе с компаниями, поддерживающими Java, в частности Sun Microsystems и IBM. Язык чрезвычайно близок к Java. Эта характеристика остается во многом справедливой и сегодня, хотя C# эволюционировал своим собственным путем и ввел несколько интересных инноваций, не имеющих аналогов в Java.

При появлении языка C# в 1999 Microsoft представлял язык следующим образом. Идеальное решение для C и C++ программистов, обеспечивающее быструю разработку в сочетании с мощью доступа ко всей функциональности платформы. Программисты получают окружение, полностью синхронизированное с появляющимися Web-стандартами и обеспечивающее простую интеграцию с существующими приложениями. В дополнение появляется возможность при необходимости создавать код на низком уровне. Язык C# – это современный Объектно-ориентированный язык, позволяющий программистам быстро строить широкий круг приложений для новой .NET платформы, предоставляющей полный набор инструментария и сервисов, которые необходимы как для вычислений, так и для коммуникаций. Элегантно спроектированный Объектно-ориентированный язык C# является великолепным выбором при построении архитектуры компонентов – начиная от высокоуровневых бизнес объектов до приложений системного уровня. Используя простые конструкции языка C#, эти компоненты могут быть конвертированы в XML Web-сервисы, вызваны затем в Интернете из любого языка, выполняемого на любой операционной системе.

В то время как виртуальная машина Java – JVM – была спроектирована специально для поддержки этого языка, главная цель проекта платформы .NET состояла с самого начала в поддержке нескольких языков. Это решение отражается как в имени виртуальной машины – Common Language Runtime (CLR) – «Общеязыковая Среда Выполнения», так и в поддержке взаимодействия API, Common Language Infrastructure (CLI) – «Общеязыковой Инфраструктуры», которая теперь является международным стандартом.

Базисными элементами C# программы являются классы и структуры, организованные в виде нескольких программных файлов. C#- классы (ключевое слово class) и структуры (ключевое слово struct) задают описание множества возможных объектов периода выполнения.

Язык C# тесно связана с CLI. VB .NET, который схож с предыдущей версией только синтаксически. CLI-совместимая версия C++ – «управляемый C++» – существенно отличается от обычного C++. Ограничения необходимы, чтобы язык мог принимать участие в играх .NET-взаимодействия. Фактически, семантика C# определялась семантикой CLI, хотя последующие версии ее существенно расширили. Синтаксис языка соответствует традиции C, C++, Java, включая завершение операторов символом точки с запятой и применением фигурных скобок для окаймления блоков программы.

Заключение

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

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

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

Список литературы

Проектирование программного обеспечения экономических информационных систем: Учебник. — 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2005.
Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информ. технологий(В.И.Грекул, Г. Н. Денишенко, Н.Л. Коровкина).
Почувствуй класс / Мейер Б.; пер. с англ. под ред. В.А. Биллига.—М.: Национальный Открытый Университет «ИНТУИТ»: БИНОМ. Лаборатория знаний, 2011.