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

Содержание:

Введение

От структур и подпрограмм к объектам.

Целями структурного программирования являлись структуризация данных и

декомпозиция кода. Объединение данных в структуры позволяло, с одной стороны, более

естественно описывать сущности реального мира, имеющие самые разнотипные наборы

атрибутов. А, с другой стороны, делало процесс разработки программ более простым,

поскольку однородные данные были сгруппированы в одном месте и под одним общим

именем.

Декомпозиция кода заключалась в разделении исходного кода программы на

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

отдельными операторами (локализация кода) и, кроме того, позволяли устанавливать

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

(локализация данных). Локализация кода не позволяла произвольно переходить от одного

оператора в одной подпрограмме к любому оператору в другой подпрограмме. Вызов

подпрограммы приводил к передаче управления только в определенную точку входа, хотя

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

Такое решение не только повышало надежность программ, но и позволяло

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

следствие, стали появляться библиотеки подпрограмм, как самостоятельные программные

продукты. Часть библиотек поставлялась вместе с компиляторами с языков

программирования и операционными системами, другая часть распространялась свободно

или на коммерческой основе. Применение библиотек существенно ускоряло процесс

разработки программного обеспечения, так как подпрограммы, применяемые

многократно, требовалось отлаживать только единожды.

Локализация данных имела ничуть не меньшее значение, чем локализация кода. Три

вида данных в подпрограмме:

Локальные данные подпрограммы, которые автоматически создавались при ее

вызове и уничтожались при возврате из подпрограммы;

Локальные данные, сохраняемые между несколькими вызовами одной

подпрограммы;

Глобальные данные, доступные нескольким или всем подпрограммам, и доступ

к которым осуществлялся прямо из подпрограммы;

Фактические параметры, передаваемые подпрограммам, замещающие

объявленные формальные параметры.

Глобальные данные применялись в основном для организации связей между

подпрограммами, но они существенно ограничивали гибкость подпрограмм.

Действительно, если подпрограмма работала с какими-то глобальными данными, то эти

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

использовали данную подпрограмму.

В отличие от этого, локальные данные, наоборот, позволяли подпрограмме быть

независимой от программ, использующих ее. Но они не обеспечивали передачу данных

между различными подпрограммами. Для передачи данных или ссылок на них

использовался механизм формальных/фактических параметров. При описании

подпрограммы объявляются формальные параметры, которые она принимает при вызове.

Когда реально происходит вызов подпрограммы, на место формальных параметров

подставляются фактические параметры того же типа

Глава 1. Теоретические основы объектно-ориентированного подхода.

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

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

  Рис. 1-Семантика

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

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

уменьшение сложности программного обеспечения;

повышение надежности программного обеспечения;

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

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

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

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

Рис.2- Жизненный цикл программной системы 

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

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

Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования:

На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход «сущность – связь».

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

1-абстрагирование (abstraction)

2-инкапсуляция (encapsulation)

3-модульность (modularity)

4-иерархия (hierarchy)

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

5-типизация (typing)

6-параллелизм (concurrency)

7-устойчивость (persistence).

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

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

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

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

Три дополнительных элемента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

осознавать выгоды такого подхода;

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

заниматься поиском подходящих для повторного использования программ;

стремиться непременно найти такие программы;

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

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

Естественность описания. Объектно-ориентированный подход позволяет описывать как статические, так и динамические отношения между объектами модели. По описанию предметной области, выполненному на естественном языке, легко выделить объекты и статические связи между ними. Объекты соответствуют существительным, а связи - глаголам и отглагольным формам. Например, фраза "фирмы выполняют заказы" позволяет выделить классы объектов "фирма" и "заказ" и отношение "выполнять" между ними типа M:N (многие к многим), так как фирма может выполнять много заказов, а заказ может быть выполнен разными фирмами.

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

Недостатки объектно-ориентированного подхода лежат в области программирования. Динамическое связывание, предполагающее поиск метода в классе, которому принадлежит получающий сообщение объект, приводит к тому, что обращение к методу занимает в 1,75 -2,5 раза больше времени, чем в обычной подпрограмме. Это, конечно, замедляет работу приложения. Однако, как указывает Г. Буч, динамическое связывание при использовании строго типизированных языков применяется примерно в 20% случаев от общего числа вызовов методов. Это позволяет снизить непроизводительные потери времени. В приложениях, где такие потери критичны, приходится прибегать к специальным программистским приемам.

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

Рис.3-Рост эффективности разработок по отношению к затратам при традиционном и объектно-ориентированном программировании

Глава 2. Анализ деятельности предприятия.

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

Портфельный анализ необходим для: 

1-оценки и правильного анализа деятельности компании

2-для построения маркетингового плана стратегий

3-для правильного распределения денег в компании

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

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

Ещё в прошлом веке Игорь Ансофф создал матрицу в двух измерениях «рынок — продукты», обещающую управленцам при ее использовании в планировании получать стабильные доходы с проекта диверсификации уже после 3–5 лет.

Рис.4-(Нет Называние)

Матрицы портфельного анализа: Первая известная матрица, которую создали специалисты из Бостона 1960-м г. Так и назвали «бостонской», её система прогнозирования основывается на двух гипотезах:

выявление наличия преимуществ рентабельности от продаж производимого продукта у крупных конкурентов;

изучение непосредственно рынка (стагнация или зрелость) и уже из этого делается вывод, нуждается ли товар в обновлении, следует ли расширять производство того или иного продукта или нет.
Вторая матрица "McKincey" строилась на системе уже известной «бостонской» матрицы, с помощью которой можно сделать выводы относительно показателя роста на рынке. Несмотря на это между двумя двумерными матрицами есть колоссальные различия:

 отсутствие связи между такими показателями, как прибыль и конкурентность;

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

Спустя время Абель немного усовершенствовал модель матрицы, дополнив её третьим показателем технологией.
Матрица направленной политики (Shell) используется для промышленных компаний. Уникальность этой матрицы заключается в том, что путём стратегического планирования в бизнесе можно создать баланс между недостатком товара и его переизбытком.
Из недочётов всех матричных способов стратегического анализа можно отметить: неправильность сравнения отдельных стратегических единиц в бизнесе, которые относятся к области индустрии, а также некорректность в выявлении количественной оценки.

Параграф-2.1. Обоснование необходимости проектирование ИС.

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

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

1-обследование объекта и обоснование необходимости создания ИС;

2-формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

1-изучение объекта автоматизации;

2-проведение необходимых научно-исследовательских работ;

3-разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

4-оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

1-разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

2-разработка предварительных проектных решений по системе и ее частям;

3-разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

1-разработка проектных решений по системе и ее частям;

2-разработка документации на ИС и ее части;

3-разработка и оформление документации на поставку комплектующих

изделий;

4-разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

1-разработка рабочей документации на ИС и ее части;

2-разработка и адаптация программ.

Стадия 7. Ввод в действие.

1-подготовка объекта автоматизации;

2-подготовка персонала;

комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

строительно-монтажные работы;

пусконаладочные работы;

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

проведение опытной эксплуатации ;

проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

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

обоснования разработки и поэтапного внедрения систем;

составления технического задания на разработку систем;

разработки технического и рабочего проектов систем.

На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.

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

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

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

Ориентировочное содержание этого документа:

ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;

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

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

описание выполняемых системой функций;

возможности развития системы;

информационные объекты системы;

интерфейсы и распределение функций между человеком и системой;

требования к программным и информационным компонентам ПО, требования к СУБД;

что не будет реализовано в рамках проекта.

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

инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;

возможности применения новых методов решения задач.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

функции - информация о событиях и процессах, которые происходят в бизнесе;

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

При изучении каждой функциональной задачи управления определяются:

наименование задачи; сроки и периодичность ее решения;

степень формализуемости задачи;

источники информации, необходимые для решения задачи;

показатели и их количественные характеристики;

порядок корректировки информации;

действующие алгоритмы расчета показателей и возможные методы контроля;

действующие средства сбора, передачи и обработки информации;

действующие средства связи;

принятая точность решения задачи;

трудоемкость решения задачи;

действующие формы представления исходных данных и результатов их обработки в виде документов;

потребители результатной информации по задаче.

Глава 3. Реализация объектно-ориентированного подхода при проектировании ИС

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

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

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

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

Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектно-ориентированного проектирования лежит методология объектно-ориентированного программирования.

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

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

Введение объектов преследует две цели:
1- понимание прикладной задачи (проблемы);
2-введение основы для реализации на компьютере.

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

После этого возникает вопрос: «Что же такое объектно-ориентированное программирование (object-oriented programming, OOP)»?

Мы определяем его следующим образом: «Объектно-ориентированное программирование — это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования».

Можно выделить три части требований к ООП:
1. OOП использует в качестве базовых элементов объекты.
2. Каждый объект является экземпляром определенного класса.
3. Классы организованы иерархически.

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

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

Основные принципы ООП: абстракция, наследование, инкапсуляция и полиморфизм.

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

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

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

Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) — технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). К первым CASE-средствам отнеслись с определенной настороженностью. Со временем появились как восторженные отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над системой управления базами данных (СУБД). Визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, тем не менее, она не решает проблем создания приложений других типов.

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

В рамках ООП исторически рассматривались три графические нотации:
1. Диаграммы «сущность–связь» (Entity-Relationship Diagrams, ERD).
2. Диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT).
3. Диаграммы потоков данных (Data Flow Diagrams, DFD).

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

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

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

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

Так как любая программа является системой в том или ином виде, то в ней можно выделить составные части и определить их взаимосвязи. Для таких описаний используется общепринятый язык UML (Unified Modeling Language) или унифицированный язык моделирования. В самых общих чертах, любая информация, записанная на этом языке, представляет собой набор диаграмм, которые довольно легко читаются.

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

Рис.5-При разработке рейтинговых данных студентов у нас есть такой класс:

Рис.6-Диаграмма этого класса будет иметь следующий вид:

На диаграмме можно выделить три блока:
1- Название;
2-Поля;
3- Методы.

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

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

Глава-4. Объектно-ориентированная структура моделей

Объектно-ориентированный подход как основа для сочетания математического и имитационного моделирования

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

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

1) большое количество неизвестных исходных данных, приводящее к огромным затратам на отладочные вычислительные эксперименты;

2) проблема верификации моделей, связанная с тем, что выходные данные моделей не соответствуют структуре предметной области;

3) недостаточный учёт нелинейных взаимодействий в системе, для которых известны лишь эмпирические оценки;

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

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

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

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

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

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

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

1) как имитационные модели, наглядны, пригодны к быстрому расширению и учёту большого числа разнородных закономерностей;

2) как математические модели, могут эффективно решать сложные, в том числе пространственно-распределённые задачи.

После того, как будут обоснованы эти утверждения и будет построена объектно-ориентированная структура обобщённой модели, получает смысл проведённая в главе 3 адаптация численных методов для работы с такими структурами и исследование их свойств.

Заключение

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

Литература

1. Буч Г. Объектно-ориентированное проектирование с примерами применения.Пер с англ. - М.: Конкорд, 1992. - 519 с.

2. Дункан Р. Замещение операторов и функций в Си и Си++//PC Magazine /USSR/. - 1991. - №3. - С. 89 - 92.

3. Дункан Р. Инкапсуляция данных и наследование свойств в Си++//PC Magazine /USSR/. - 1991. - №3. - С. 99 - 104.

4. Дункан Р. Си++ - новое мышление в программировании//PC Magazine /USSR/.- l991. - №3. - С. 93 - 97.

5.Как внедрить объектно-ориентированный подход.The OOP Survial Guide./Agila C.A.//Computerworld-Moscow. - 1995. - №15. - С. 31.

6. Липаев В.В., Позин Б.А., Штрик А.А. Технология сборочного программирования./Под ред. В.В.Липаева. - М.: Радио и связь, 1992 - 272 с.

7. Метод "по спирали" быстро ведет к цели//Деловой мир. - 1995. - № 23 - 24.

8. Программы многократного использования становятся реальностью. Making reuse a reality./Tibbetts J.,Bernstein В.//Компьютеруик. - 1995. - № 18. - С. 21, 30.

9. Новоженов Ю.В. Объектно-ориентированный подход к разработке прикладных программных систем//PC magazine. - 1995. - № 12.

10. Boehm В. A spiral model of software development and enhancement//IEEE Computer. - 1988. - № 25(5). - P. 61 - 72.

11. Booch G. Object-Oriented Analysis and Design with Applications// Bengamin/Cummings, Redword City, CA, USA, 1994.

12. Mood J. Object Methods Tame Reengeneering Madness.- Datamation. - 1995, May. - P. 43, 44, 48.

13. А. М. Вендров //Проектирование программного обеспечения экономических

информационных систем// Москва 2000 г.

14. О. Ефимова // Курс компьютерных технологий//Москва1998г.

15. Всемирная сеть Интернет

16.Г. Буч, Язык UML для пользователя: Пер. с англ [Текст]/Г. Буч, Д. Рамбо, А. Джекобсон. — М.: ДМК, 2000. — 432 с., ил. (Серия «для программистов»).