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

Содержание:

Введение

Ещё совсем недавно, никто и подумать не мог, что наступит то время, когда компьютер будет решать столько задач, что станет важной частью жизни человека, и будет приносить пользу в огромных количествах. Но сам по себе компьютер ничто. Для того что бы он был полезен, нужно поставить перед ним задачу, и что немаловажно сделать это нужно правильно. В этом нам помогают различные способы по проектированию программного обеспечения (ПО). В начале 70-х гг. 20 века был отмечен кризис программирования (software crisis). Выражалось тем, что масштабные проекты стали выполнятся с существенными задержками или с перерасходом средств на разработку. При этом достаточно большое количество программ не обладали требуемыми функциональными возможностями, в следствие чего их качество не устраивало потребителей. Это стимулировало проведение ведущими зарубежными аналитиками множества аналитических исследований, но результаты их были не слишком обнадеживающие. В заданный срок на тот момент были завершены только 16% проектов. Из остальных проектов примерно 53% сданы заказчику с существенным опозданием или разработчике превысили запланированные расходы. Чаще всего причинами неудач являлись нечеткая или неполная формулировка требований к ПО, неудовлетворительное планирование, недостаточное вовлечение пользователей в работу над проектом и т.п. Исходя из этого потребовался существенно новый подход к проектированию ПО. Этим подходом стал объектно–ориентированный, который в короткие сроки завоевал огромную популярность. Объектно-ориентрованный подход полностью устраняет те недостатки, с которыми ранее столкнулись разработчики ПО. Вот почему, целью курсовой работы является раскрытие современных методов и средств проектирования, в частности в объектно-ориентированном подходе к проектированию ПО.

Глава 1: Структура объектно-ориентированного подхода

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

· анализа предметной области,

· проектирования,

· создания программных модулей,

· объединения модулей в единую систему,

· тестирования,

· внедрения.

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

Однако эта технология не лишена некоторых недостатков. В соответствии с классическим подходом основное внимание должно уделяться информации, с которой работает система. Разработчик спрашивает пользователей, какая информация им нужна, проектирует БД для хранения этой информации, создает экранные формы для ее вывода, встраивает возможность распечатывать отчеты. Иначе говоря, разработчик «фокусируется» на самой информации, а тому, что с ней делать, т. е. поведению системы уделяется меньше внимания. Такой подход называется «ориентированным на данные (data centric)», он применялся при разработке тысяч различных систем много лет. Он неоценим при проектировании БД и систем обработки информации, но при разработке бизнес-приложений возникают проблемы, главная из которых состоит в том, что требования к системе могут меняться со временем. Система, ориентированная на данные легко приспосабливается к изменениям БД, однако изменить деловые правила или поведение такой системы значительно труднее.

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

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

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

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

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

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

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

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

Наследование – это механизм, позволяющий создавать новые объекты, основываясь на уже существующих объектах. Наследование позволяет выделить свойства, операции и события одного объекта и приписать их другому объекту, иногда с модификацией. Порождаемый объект-потомок (child) наследует свойства порождающего, родительского объекта (parent). Например: если «Автомобиль» –некий родительский объект, то «Легковой автомобиль» –объект-потомок, которому присущи все свойства объекта «Автомобиль».

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

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

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

Каждый объект имеет три характеристики: состояние, поведение и индивидуальность.

Состояние – одно из условий, в котором объект может находиться, меняется во времени и определяется атрибутами и отношениями между объектами.

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

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

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

· атрибуты – время экзамена, место проведения экзамена;

· операции – получить время экзамена, получить аудиторию для проведения экзамена, сдавать экзамен.

Студент Петров и студент Иванов – это объекты, принадлежащие классу Студенты группы № 1. Каждый из них имеет значения атрибутов и доступ к операциям, определенным классом Студенты группы № 1.

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

1.1 Подходы к проектированию информационных систем

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

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

расширение экономического пространства, на котором функционируют предприятия;

появление нового стратегического ресурса — информации;

необходимость учитывать фактор времени.

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

Два подхода к проектированию

Можно выделить два основных подхода к проектированию систем управления предприятием и информационных систем их поддержки: структурный и процессный.

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

Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения. О важности и структуре Системного проекта авторы уже писали в статье “Реорганизация АСУ промышленных предприятий” (КомпьютерПресс № 7’97) и в статье “Методологический подход проектирования корпоративной информационной системы предприятия” (материалы конференции “Корпоративные системы’96”, компания “СофтСервис”). Хорошо, если на предприятии есть обученные специалисты, способные быстро и качественно актуализировать этот документ. Но это только начало! Ведь актуализировать надо также и саму информационную систему! Как правило, это достаточно трудоемкий, длительный и утомительный процесс.

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

Процессный подход подводит к необходимости перехода на так называемое тощее производство или тощую ресурсосберегающую организационную структуру (Lean production). Основными чертами такой реорганизации являются:

широкое делегирование полномочий и ответственности исполнителям;

сокращение количества уровней принятия решения;

сочетание принципа целевого управления с групповой организацией труда;

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

автоматизация технологий выполнения бизнес-процессов.

Далее мы рассмотрим, каким образом процессный подход был применен при проектировании информационной системы одного из предприятий пищевой промышленности (далее “Компании”).

Применение процессного подхода. Цели проекта

Основными целями проектирования интегрированной системы Компании являлись:

проведение системного анализа бизнес-процессов и моделирование рациональных технологий работы Компании;

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

разработка положения по организации управления Компании (центрального офиса и филиала);

разработка системного проекта интегрированной информационной системы Компании (центрального офиса и филиала).

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

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

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

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

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

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

На основе декомпозиции системы:

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

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

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

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

№5 Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта. По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.

1.3 Базовые составляющие объектно-ориентированного подхода

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

- Унифицированный процесс;

- Унифицированный язык моделирования;

- шаблоны проектирования.

Унифицированный процесс – это процесс разработки программного обеспечения (ПО), который обеспечивает упорядоченный подход к распределению задач и обязанностей в организации-разработчике [29, 30]. Унифицированный процесс охватывает весь жизненный цикл ПО, начиная с определения требований и заканчивая сопровождением, и представляет собой обобщенный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем.

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

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

Глава 2: Объектно-ориентированный анализ и проектирование системы

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

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

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

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

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

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

В рамках ООАП исторически рассматривались три графических нотации:

диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD),

диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT),

диаграммы потоков данных (Data Flow Diagrams, DFD).

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

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

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

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

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

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

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

Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем

Нотация IDEF1 - для документирования информации о производственном окружении систем

Нотация IDEF2 - для документирования поведения системы во времени

Нотация IDEF2 никогда не была полностью реализована. Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X. Методология IDEF нашла применение в правительственных и коммерческих организациях, поскольку в 1993 году появился стандарт FIPSправительства США для  двух технологий IDEF0 и IDEF1X. В течение последующих лет этот стандарт продолжал активно развиваться и послужил основой для реализации в некоторых CASE-средствах, наиболее известным из которых является AllFusion Process Modeler (новое название BPwin ) компании Computer Associates.

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

Одна из наиболее важных особенностей нотации IDEF0 - постепенное введение все более детальных представлений модели системы помере  разработки отдельных диаграмм. Построение модели IDEF0 начинается с представления всей системы в виде простейшей диаграммы, состоящей из одного блока процесса и стрелок ICOM, служащих для изображения основных видов взаимодействия с объектами вне системы. Поскольку исходный процесс представляет всю систему как единое целое, данное представление является наиболее общим и подлежит дальнейшей декомпозиции. Пример представления общей модели процесса оформления кредита в банке, разработанной с помощью CASE-средства AllFusion Process Modeler , изображен на рис. 1.2

Рис. 1.2. Пример исходной диаграммы IDEF0 для процесса оформления кредита в банке

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

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

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

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

2.1 Сущность поставленной задачи

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

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

На программный продукт «Автоматизированная система коменданта общежития» были возложены следующие задачи:

- Ведение базы данных о каждом жителе (номер комнаты, паспортные данные);

- Ведение учета выдачи инвентаря;

- Учёт информации о различных видах оплат (номер квитанции, дата оплаты, сумма)

Основная задача, которую необходимо автоматизировать, - ведение учёта о жителях общежития.

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

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

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

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

-Система должна нормально функционировать на стандартных персональных компьютерах типа IBM.

- Система не должна иметь привязки к аппаратной части для возможности переноса ее на новую платформу из-за старения компьютерной техники.

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

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

- Система должна иметь возможность наращивания как программной, так и аппаратной части.

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

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

2.2 Проектирование модели

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

Для этого мы построим следующие диаграммы:

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Диаграмма классов

Рисунок 2.3 - Диаграмма классов

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

Глава 3. Объектно-ориентированный подход к проектированию информационных систем и средства его реализации. 

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

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

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

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

Защита информации

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

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

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

Организационное обеспечение

-носители информации должны храниться в местах, не доступных для посторонних лиц;

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

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

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

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

Технологическое обеспечение

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

-ограничения, требующие сохранение значений поля показателя в некотором диапазоне;

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

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

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

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

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

Программные меры:

- архивирование:  копирование таблицы FAT, ежедневное ведение архивов измененных файлов. Это самый важный, основной метод защиты от вирусов.

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

- профилактика:  работа с дискетами, защищенными от записи, минимизация периодов доступности дискетки для записи, раздельное хранение вновь полученных и эксплуатировавшихся ранее программ, хранение программ на "винчестере" в архивированном виде.
В процессе работы программы-фаги (например AIDSTEST , ANTIDIR , DOCTOR) "выкусывают" тело вируса и восстанавливают измененную вирусом последовательность команд. 

Организационные меры состоят в следующем: 

обучение персонала;

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

хранение отдельных файлов в шифрованном виде;

создание и отработка плана восстановления "винчестера".

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

3.1Особенности реализации

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

Поля данных

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

Методы

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

Классы могут наследоваться друг от друга. Класс-потомок получает все поля и методы класса-родителя, номожет дополнять их собственными либо переопределять уже имеющиеся. Большинство языковпрограммирования поддерживает только единичное наследование (класс может иметь только один класс-родитель), но в C++ допускается множественное наследование — порождение класса от двух или болееклассов-родителей. Множественное наследование порождает целый ряд проблем, как логических, так ичисто реализацинных, поэтому в полном объёме его поддержка не распространена. Вместо этого в 1990-егоды появилось и стало активно вводиться в объектно-ориентированные языки понятие интерфейса. Интерфейс- это класс без полей и без реализации, включающий только заголовки методов. Если некийкласс наследует (или, как говорят, реализует) интерфейс, он должен реализовать все входящие в негометоды. Использование интерфейсов предоставляет относительно дешёвую альтернативумножественному наследованию.

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

Инкапсуляция обеспечивается следующими средствами

Контроль доступа

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

Методы доступа

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

Свойства объекта

Псевдополя, доступные для чтения и/или записи. Свойства внешне выглядят как поля и используютсяаналогично доступным полям (с некоторыми исключениями), однако фактически при обращении к нимпроисходит вызов методов доступа. Таким образом, свойства можно рассматривать как «умные» поляданных, сопровождающие доступ к внутренним данным объекта какими-либо дополнительными действиями(например, когда изменение координаты объекта сопровождается его перерисовкой на новом месте). Свойства, по сути  не более чем синтаксический сахар, поскольку никаких новых возможностей они недобавляют, а лишь скрывают вызов методов доступа. Конкретная языковая реализация свойств может бытьразной. Например, в C# объявление свойства непосредственно содержит код методов доступа, которыйвызывается только при работе со свойствами, то есть не требует отдельных методов доступа, доступныхдля непосредственного вызова. В Delphi объявление свойства содержит лишь имена методов доступа, которые должны вызываться при обращении к полю. Сами методы доступа представляют собой обычныеметоды с некоторыми дополнительными требованиями к сигнатуре.

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

3.2 Подходы к проектированию программ в целом

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

Объектно-ориентированное проектирование основывается на описании структуры и поведенияпроектируемой системы, то есть, фактически, в ответе на два основных вопроса:

Из каких частей состоит система.

В чём состоит ответственность каждой из частей.

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

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

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

3.3Объектно-ориентированные языки

Основная статья: Объектно-ориентированный язык программирования

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

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

Объявление классов с полями (данными  членами класса) и методами (функциями членами класса).

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

Большинство ООП-языков поддерживают только единичное наследование.

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

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

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

В некоторыхООП-языках все методы классов являются виртуальными.

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

Конструкторы, деструкторы, финализаторы.

Свойства (аксессоры).

Индексаторы.

Интерфейсы — как альтернатива множественному наследованию.

Переопределение операторов для классов.

Часть языков (иногда называемых «чисто объектными») целиком построена вокруг объектных средств вних любые данные (возможно, за небольшим числом исключений в виде встроенных скалярных типовданных) являются объектами, любой код  методом какого-либо класса и невозможно написать программу, в которой не использовались бы объекты. Примеры подобных языков  Java или Ruby. Другие языки (иногдаиспользуется термин «гибридные») включают ООП-подсистему в исходно процедурный язык. В нихсуществует возможность программировать, не обращаясь к объектным средствам. Классические примеры— C++ и Delphi Pascal.

Заключение

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

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

1. Иванов А.Г., Карпова А.В., Семик В.П., Филинов Ю.Е. Объектно-ориентированная среда программирования. Системы и средства информатики. Вып.2. - М.: Наука, 2011.

2. Козырев А.А. Информационные технологии в экономике и управлении – СПб.: Изд-во Михайлова В.А., 2003

3. Уткин В.Б., Балдин К.В. Информационные системы и технологии в экономике. – М.: ЮНИТИ, 2007.

4. Stroustrup D. The C++ Programming Language. Addison-Wesley, 1986.

5. Хотинская Г.И. Информационные технологии управления. – М.: Дело и Сервис (ДИС), 2003.