Применение объектно-ориентированного подхода при проектировании информационной системы
Содержание:
Введение
Мы живем в поистине необычном времени. Так как совершенно недавно, наши родители и в грезах не имели возможность помыслить о том, что когда-нибудь настанет то время, когда компьютер будет неотделимой частью нашей жизни, и действительно начнет приносить гигантскую выгоду. Будет генератором мыслей и их осуществлением, раскроет новейшие горизонты в знаниях населения земли. Однако компьютер не смотря ни на что, в отсутствии человека пока мало на что способны. Вот почему так принципиально донести до машины человеческую идею, а подсобляет нам в этом разные методы по проектированию ПО.
Проектирование финансовых информативных систем (ЭИС) – логически непростая, труд затратная и долгая работа, требующая высочайшей квалификации участвующих в ней профессионалов.
В начале 70-х гг. в USA был отмечен упадок программирования (software crisis). Это замечалось в том, что огромные планы стали выполнятся с отставанием от графика либо с превышением сметы затрат, разработанный продукт не владел спрашиваемыми функциональными способностями, деятельность его была мала, свойство обретаемого программного обеспечения не устраивало покупателей.
Аналитические исследования и обзоры, исполняемые в течение ряда последних лет ведущими зарубежными специалистами, демонстрировали не очень обезнадёживающие итоги. Так, к примеру, в 1995г. фирма StandishGroup изучила работу 364 американских компаний и результаты выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали последующие выводы:
Лишь 16% проектов закончились в срок, 52,7% закончились с опозданием, расходы перевалили запланированный бюджет.
В числе причин крахов бытуют: алогическая и не полная формулировка требований к ПО, недостающее втягивание юзеров в работу над проектом, недостаточное планирование и т.п.
На данном фоне, рентабельно различается объектно – ориентированный подход к конструированию ПО устраняет эти и остальные недочеты, он владеет состоятельным комплектом выразительных средств. Вот отчего, целью моей курсовой работы является раскрытие передовых способов и средств проектирования, в частности в объектно-ориентированном подходе к проектированию ПО.
Глава I Структура объектно-ориентированного программирования.
1.1 СУЩНОСТЬ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
Базисное отличие меж структурным и объектно-ориентированным подходом содержится в методе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая конструкция системы описывается в определениях объектов и взаимосвязей меж ними, а поведение системы описывается в определениях обмена сообщениями между объектами. Любой объект системы обладает собственным своим поведением, имитирующим поведение объекта настоящего мира. Понятие "объект" в первый раз было применено примерно 30 лет назад в промышленных средствах при попытках отступить от классической архитектуры фон Неймана и преодолеть препятствие меж высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой еще тесно соединены объектно-ориентированные операционные системы. Но более значимый вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход проявили воздействие также развивавшиеся довольно самостоятельно методы моделирования баз данных, в особенности подход "сущность-связь".
Мировозренческой базой объектно-ориентированного подхода является объектная модель. Главными её элементами считаются:
• абстрагирование (abstraction);
• инкапсуляция (encapsulation);
• модульность (modularity);
• иерархия (hierarchy).
Не считая главных есть ещё три дополнительных элемента, не являющихся в отличие от основных строго неотъемлемыми:
• типизация (typing)',
• параллелизм (concurrency)',
• устойчивость (persistence).
Абстрагирование — это различение немаловажных черт некоторого объекта, которые различают его от всех остальных разрядов объектов и, таковым образом, верно характеризуют его концептуальные границы относительно дальнейшего обсуждения и разбора. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор верного комплекта абстракций для данной объектной области представляет собой основную задачу объектно-ориентированного проектирования.
Инкапсуляция — это процесс отделения друг от друга единичных элементов объекта, характеризующих его приспособление и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход подразумевает, что личные ресурсы, которыми могут манипулировать лишь методы самого класса, укрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодобавляющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (либо, по другому, ограничение доступа) не дозволяет объектам-пользователям распознавать внутреннее устройство объекта.
Объектно-ориентированный подход
Модульность — это свойство системы, связанное с вероятностью её декомпозиции на разряд внутренне логичных, но слабо связанных меж собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.
Иерархия — это ранжированная либо упорядоченная система абстракций, размещение их по уровням. Главными видами иерархических структур употребительно к сложным системам считаются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Образцами иерархии классов являются простое и множественное наследование (один класс использует структурную либо функциональную часть соответственно 1-го либо нескольких других классов), а иерархии объектов - агрегация.
Стандартизация — это лимитирование, накладываемое на класс объектов и препятствующее взаимозаменяемости разных классов (либо сильно суживающее её возможность). Стандартизация позволяет защититься от применения объектов 1-го класса за место иного или по крайней мере управлять таковым использованием.
Параллелизм — свойство объектов пребывать в функциональном либо инертном положенье и распознавать функциональные и инертные объекты меж собой.
Устойчивость — качество объекта существовать во времени (вне зависимости от процесса, породившего данный объект) либо в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).
Основные понятия объектно-ориентированного подхода - объект и класс.
Объект определяется как осязаемая действительность (tangible entity) — объект либо действо, располагающие четко характеризуемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение похожих объектов характеризуют совместный для них класс. Определения "экземпляр класса" и "объект'' считаются равносильными. Положение объекта характеризуется перечнем всех вероятных (статических) параметров данного объекта и нынешними значениями (динамическими) каждого из данных параметров. Поведение охарактеризовывает действие объекта на другие объекты и напротив условные конфигурации состояния этих объектов и передачи сообщений. По другому говоря, поведение объекта полностью определяется его действиями. Индивидуальность — это характеристики объекта, различающие его от всех других объектов.
Конкретное действие 1-го объекта на иной с целью начать соответствующую реакцию именуется операцией. Как правило, в объектных и объектно-ориентированных языках операции, исполняемые над этим объектом, именуются методами и являются составной долею определения класса.
Класс — это множество объектов, связанных общностью структуры и поведения. Хоть какой объект считается экземпляром класса. Определение классов и объектов — одна из самых трудных задач объектно-ориентированного проектирования.
Последующую группу принципиальных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизма может быть интерпретировано как способность класса иметь более чем одни тип. Наследование значит возведение новых классов на базе имеющихся с возможностью прибавления либо переопределения данных и методов.
Объектно-ориентированная система вначале основывается с учетом её эволюции. Наследование и полиморфизм гарантируют вероятность определения новой функциональности классов с помощью создания производных классов — потомков базисных классов. Потомки наследуют свойства материнских классов без конфигурации их начального описания и прибавляют при необходимости личные структуры данных и методы. Определение производных классов, при котором задаются лишь отличия либо уточнения, в большой степени бережет время и усилия при созданье и применении спецификаций и программного кода.
Принципиальным свойством объектного подхода считается согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации. Требование согласованности моделей производится благодаря способности внедрения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели ранних стадий могут быть непосредственно подвергнуты сопоставлению с моделями осуществления. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.
1.2 УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML
Большая часть имеющихся методов объектно-ориентированного разбора и конструирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования — это нотация (в основном графическая), которая употребляется методом для отображения проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она считается синтаксисом языка моделирования. К примеру, нотация диаграммы классов описывает, каким образом изображаются такие элементы и понятия, как класс, ассоциация и множественность. Процесс —это отображение шагов, которые нужно выполнить при разработке проекта.
Стандартизированный язык моделирования UML (Unified Modeling Language)—это наследник того поколения методов ООАП, которые возникли в конце 80-х и начале 90-х гг. Создание UML практически стартовало в конце 1994 г., когда Гради Буч и Джеймс Рамбо инициировали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой фирмы Rational Software. К концу 1995 г. они сотворили первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-oriented Software Engineering) Ивар Якобсон. Таким образом, UML считается прямым объединением и стандартизацией методов Буча, Рамбо и Якобсона, но дополняет их новыми возможностями. Главными в разработке UML были следующие цели:
• дать юзерам готовый к применению выразительный язык визуального моделирования, позволяющий разрабатывать осознанные модели и обмениваться ими;
• предугадать механизмы расширяемости и квалификации для расширения базисных теорий;
• снабдить самостоятельность от определенных языков программирования и процессов разработки;
• снабдить внешнюю базу для осмысливания данного языка моделирования (язык обязан быть сразу точным и доступным для осмысливания, без излишнего формализма);
Определенное воздействие 1-го объекта на иной с целью начать соответствующую реакцию называется операцией. Как правило, в объектных и объектно-ориентированных языках операции, исполняемые над данным объектом, называются методами, являются составной частью определения класса.
Класс —это множество объектов, связанных общностью структуры и поведения. Любой объект считается экземпляром класса. Определение классов и объектов — одна из самых трудных задач объектно-ориентированного проектирования.
Последующую группу принципиальных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизма может быть интерпретировано как способность класса иметь более чем одн тип. Наследование означает построение новых классов на основе имеющихся с возможностью добавления либо переопределения данных и методов.
Объектно-ориентированная система вначале основывается с учетом её эволюции. Наследование и полиморфизм гарантируют вероятность определения новой функциональности классов с помощью создания производных классов - потомков базисных классов. Потомки наследуют характеристики материнских классов без изменения их первоначального описания и добавляют при необходимости личные структуры данных и методы. Определение производных классов, при котором задаются лишь отличия либо уточнения, в большой степени бережет время и усилия при производстве и использовании спецификаций и программного кода.
Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации. Заявочное пожелание слаженности моделей выполняется благодаря способности внедрения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели ранних стадий могут быть непосредственно подвергнуты сопоставлению с моделями реализации. По объектным моделям может быть изучено отображение настоящих сущностей моделируемой предметном области (организации) в объекты и классы информационной системы.
1.3 ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ
В течение довольно долгого периода времени в процессе как объектно-ориентированного, так и обычного структурного проектирования разработчики использовали обычные сценарии, помогающие лучше понять запросы к системе. Эти сценарии трактовались очень неофициально - они практически постоянно применялись и очень редко протоколировались. И вар Якобсон в первый раз использовал понятие "вариант использования" (use case) и дал ему такую значимость, что он превратился в главный элемент разработки и планирования проекта.
Вариант использования представляет собой очередность действий (транзакций), исполняемых системой в ответ на явление, стимулируемое некоторым внешним объектом (действующим лицом). Вариант применения описывает обычное взаимодействие меж пользователем и системой. К примеру, два обычных варианта использования обыденного текстового процессора — "создаьб некий текст полужирным" и "создать индекс". Даже на этом элементарном примере можно отметить разряд параметров варианта применения: он охватывает некую явную для пользователей функцию, может быть как маленьким, так и довольно большим и постановляет для пользователя некую дискретную задачу В простом варианте применения ориентируется в процессе дискуссии с пользователем тех функций, которые он желал бы воплотить.
Когда Якобсон в 1994 г. предложил варианты применения в качестве главных частей процесса разработки ПО, он еще внес предложение использовать для их приятного понятия диаграммы разновидностей применения. На рис.1 представлены некоторые варианты применения для системы торговой фирмы; человеческие фигуры тут означают действующих лиц, эллипсы - варианты применения, а линии и стрелки — разные взаимосвязи меж действующими лицами и вариациями применения.
Рис.1 Диаграмма вариантов использования
Действующее лицо(actor) —это роль, которую юзер играет сообразно отношению к системе. На рис.1 4 действующих лица: Клерк по продажам, Оптовый купец, Торговец и Система учета. Действующие лица представляют собой роли, а не конкретных людей либо названия дел. Несмотря на то, что на диаграммах разновидностей применения они представляются в облике стилизованных человеческих фигурок, действующее лицо имеет возможность также быть внешней системой, которой нужна некая информация от предоставленной системы (к примеру, Система учета). Демонстрировать на диаграмме действующих лиц системы надлежит лишь в том варианте, когда им вправду нужны некие варианты применения.
Все варианты применения так либо иначе соединены с наружными требованиями к работоспособности системы. Ежели Системе учета требуется файл, то это заявочное пожелание обязано быть удовлетворено. Варианты применения постоянно надлежит разбирать вкупе с действующими лицами системы, характеризуя при данном настоящие задачи пользователей и рассматривая другие методы заключения данных задач.
Действующие лица могут играть разные роли по отношению к варианту применения. Они могут воспользоваться его результатами либо могут сами непосредственно в нем принять участие. Значимость различных ролей действующего лица находится в зависимости от того, каким образом употребляются его взаимосвязи.
Неплохим источником для идентификации разновидностей использования служат внешние события. Надлежит приступить с перечисления всех явлений, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо определенное явление имеет возможность вызвать за собой реакцию системы, не спрашивающую вмешательства пользователей, либо, напротив, побудить чисто пользовательскую реакцию. Идентификация явлений, на которые необходимо реагировать, помогает отметить варианты применения.
В добавление к взаимосвязям меж действующими лицами и вариациями применения есть 2 других вида связей(см.рис.1): "использование" (uses) и "расширение" (extends) меж вариациями использования. Ассоциация вида "расширение" используется тогда, когда один вариант применения сходственнее иному, однако несет некоторое количество большей нагрузку
В предоставленном образце главным вариантом применения считается Заключить сделку В этом варианте ожидается обычный ход процесса. Но в варианте превышения некого предела — к примеру, наибольшей суммы торговой аферы, поставленной для конкретного клиента, процесс, соединенный с этим вариантом применения, есть исключения, то это действующее лицо не имеет отношения к осуществления остальных разновидностей применения.
Выбор использующейся взаимосвязи ориентируется последующими правилами:
• связь "расширение" надлежит использовать при отображенье конфигураций в нормальном поведении системы;
• связь "использование" надлежит использовать для предотвращения повторов в 2-ух (либо более) вариантах применения. Варианты применения считаются необходимым средством на стадии созиданья притязаний к ПО. Любой вариант применения — это возможное требование к системе, и пока оно не обнаружено, невозможно запланировать его осуществление.
Разные разработчики подходят к отображению разновидностей применения с различной степенью детализации. К примеру, Ивар Якобсон заявляет, что для плана с трудозатратностью в 10 человеко-лет количество разновидностей использования может составлять около 20 (не считая связей "использование" и "расширение"). Надлежит выбирать небольшие и детализированные варианты использования, так как они упрощают составление и осуществление слаженного плана проекта.
Глава II ДИАГРАММЫ
2.1 Диаграммы классов
Диаграммы классов считаются основным звеном объектно-ориентированных методов. Диаграмма классов определяет разновидности объектов системы и различного рода статические связи, которые есть меж ними. Есть два главных вида статических связей:
•ассоциации(к примеру, клиент имеет возможность свершить заявку);
•подтипы(частный клиент является типом клиент
Рис. 2 Диаграмма классов
На диаграммах классов представляются также принадлежности классов, операции классов и лимитирования, которые накладываются на связи меж объектами.
На рис.2 обрисована обычная диаграмма классов. Перед тем как приступить к отображению диаграмм классов, следует направить интерес на один важный эпизод, связанный с характером применения данных диаграмм разработчиками. Данный эпизод традиционно никоим образом не протоколируется, но оказывает существенное воздействие на метод интерпретации диаграмм и потому имеет важное положение к тому, что описывается при помощи модели.
Построение диаграмм классов можно рассматривать в разных качествах:
концептуальный аспект —диаграммы классов показывают понятия изучаемой предметной области (имитируемой организации). Эти понятия, естественно, станут подходить реализующим их классам, но это непосредственное соотношение часто отсутствует. В действительности концептуальная модель может обладать очень слабым отношением либо в общем не обладать никаким отношения к реализующему её программному обеспечению, потому её можно рассматривать как не зависимую от средств осуществления (языка программирования);
•аспект спецификации —модель опускается на уровень ПО, однако рассматриваются лишь интерфейсы, а не программная осуществление классов (под интерфейсом тут понимается комплект операций класса, заметных извне);
•аспект реализации -модель вправду описывает реализацию классов ПО. Данный аспект более важен для программистов.
Сознание аспекта имеет огромное значение как для построения, так и для чтения диаграмм классов. К сожалению, отличия меж аспектами не настолько отчетливы, и большая часть разработчиков при возведенье диаграмм допускают их слияние.
При возведенье диаграммы нужно избрать единый аспект. При чтении диаграммы надлежит узнать, в согласовании с каким аспектом она выстраивалась. Ежели необходимо разъяснять эту диаграмму безошибочным образом, то без такового познания не обойтись.
Точка зрения на диаграммы классов, не будучи фактически формальной частью UML, но при возведенье и разборе моделей считается очень важной. Системы UML можно применять с хоть какой из трех точек зрения. Большая часть опытных разработчиков-программистов выбирают аспект реализации. С другой стороны, разумеется, что возведение диаграмм классов на стадии формирования притязаний к ПО обязано проделываться с концептуальной точки зрения.
На рис.2 изображена обычная модель классов, связанная с обработкой заказов клиентов. Обрисуем любой отрывок модели и рассмотрим его вероятную интерпретацию с разных точек зрения.
Ассоциации представляют собой взаимосвязи меж экземплярами классов (личность действует в фирме, фирма владеет рядом кабинетов).
С концептуальной точки зрения связи представляют собой концептуальные связи меж классами. На диаграмме представлено, что Заявка обязана поступить от единого Клиента, а Клиент в течение некого времени имеет возможность свершить некоторое количество Заявок. Любая из этих Заявок охватывает некоторое количество Строк заявки, любая из которых подходит единому Продукту.
Любая связь обладает 2-мя ролями; любая роль представляет собой направленность связи. Таковым образом, связь меж Клиентом и Заявкой охватывает 2 роли: 1 от Клиента к Заявке, иная - от Заявки к Клиенту.
Роль может быть очевидно поименованная с помощью метки. К примеру, роль связи в направленности от Заявки к Строчкам заявки именуется «позиция заявки». Ежели таковая метка отсутствует, роли присваивается имя класс – цели – таким образом, роль связи от Заказа к Клиенту может быть названа Клиент (термины «начало» (source) и «цель» (target) используются для обозначения классов, проявляющихся соответственно исходным и окончательным для ассоциации).
2.2 ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ
Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.
Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображаются ряд объектов и те сообщения, которыми они обмениваются между собой.
Проиллюстрируем данный подход на примере достаточно простого варианта использования, который описывает следующее поведение:
• Окно Ввода Заказа посылает Заказу сообщение "приготовиться".
• Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.
• Каждая Строка заказа проверяет состояние определенного Запаса товара:
Если данная проверка удовлетворяется (результат - true), то Строка заказа удаляет соответствующее количество товара из Запаса.
В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.
Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).
На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис.3).
Эта вертикальная линия называется линией жизни(lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.
Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице - сверху вниз. Каждое сообщение помечается, как минимум, именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, можно показать само делегирование.
Рис. 3 Диаграмма последовательности
(self-delegation) — сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
Из всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нужен Повторный Заказ="true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер - это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться).
Диаграммы последовательности очень просты и наглядны (в этом заключается самое большое их достоинство) и существенно помогают разобраться в процессе поведения системы.
Диаграмма (см. рис. 3) содержит возврат, означающий не новое сообщение, а возврат из сообщения. На диаграмме возврат отличается от обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий.
Диаграммы последовательности можно также использовать для представления параллельных процессов.
На рис. 4 изображен ряд объектов, участвующих в проверке банковской транзакции. В момент создания Транзакции она порождает Координатор Транзакции в целях координации проверок, выполненных Транзакцией. Этот координатор создает несколько объектов Транзакционного Контролера (в данном случае два объекта), каждый из которых отвечает за определенную проверку. Такой процесс облегчает создание различных дополнительных процессов проверки, поскольку каждая проверка вызывается асинхронно и выполняется параллельно с другими.
рис.4 Параллельные процессы и активизации
Когда Проверка Транзакции завершается, она посылает соответствующее сообщение Координатору Транзакции. Координатор проверяет, все ли проверки сообщили о своем выполнении. Если нет, то координатор не выполняет никаких действий. Если же все проверки завершились успешно, как в данном случае, то координатор сообщает Транзакции о нормальном завершении.
В диаграмму последовательности на рис. 4 введен ряд новых элементов. Во-первых, это активизации, появляющиеся явно в том случае, когда метод становится активным либо во время его выполнения, либо при ожидании результата выполнения какой-либо процедуры. Во-вторых, половинные стрелки обозначают асинхронные сообщения. Асинхронное сообщение не блокирует работу вызывающего объекта. Таким образом, он может продолжать свой собственный процесс. Асинхронное сообщение может выполнять одну из трех функций:
• создавать новую ветвь процесса (в этом случае оно связано с самой верхней частью активизации);
• создавать новый объект;
• устанавливать связь с уже выполняющейся ветвью процесса.
Удаление объекта показано с помощью большого знака "X". Объекты могут выполнить самоуничтожение или могут быть уничтожены посредством еще одного сообщения.
Используя механизм активизации, можно более четко показать смысл само делегирования. Без них, или без такого обозначения с помощью столбиков, которое здесь используется, довольно трудно определить, где же выполняются следующие после само делегирования вызовы — то ли в вызывающем методе, то ли в вызываемом методе. Активизации вносят ясность в этот вопрос.
Глава III ПРИМЕР ИСПОЛЬЗОВАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
На начальной стадии(или стадии формирования требований) строится начальная диаграмма вариантов использования (рис.5).
Рис.5 Начальная диаграмма вариантов использования
При построении диаграммы вариантов использования в первую Очередь составляется список всех основных действующих лиц (физических лиц или внешних систем, которые будут взаимодействовать с создаваемой системой). Их можно идентифицировать, задавая следующие вопросы:
• Кто использует систему непосредственно?
• Кто отвечает за эксплуатацию системы?
• Какое внешнее оборудование используется системой?
• Какие другие системы взаимодействуют с данной системой?
Варианты использования идентифицируются исходя из следующих соображений: каждый вариант использования представляет собой некоторую функцию, выполняемую системой в ответ на воздействие действующего лица, и характеризует конкретный способ применения системы, диалог между действующим лицом и системой. Нужно также иметь в виду, что впоследствии варианты использования будут служить для описания требований к системе, общения с конечными пользователями и экспериментами предметной области, а также для тестирования системы.
На стадии проектирования уточняется диаграмма вариантов использования и строится архитектура системы, основой которой являются диаграммы классов. В данном примере ограничимся построением диаграммы классов и диаграммы взаимодействия. Диаграммы взаимодействия строятся для уточнения диаграммы вариантов использования и перехода к диаграммам классов. Так, диаграмма последовательности (рис. 6) иллюстрирует один из возможных сценариев развития событий в рамках варианта использования "Зарегистрировать налогоплательщика". Предполагается, что налогоплательщик ставится на учет впервые и все его документы в полном порядке.
Структура программной системы описывается с помощью нескольких диаграмм классов, главная из которых представляет собой диаграмму пакетов (подобную диаграммам, представленным в приложении рис. 8 и 9), а остальные диаграммы раскрывают содержимое каждого из пакетов. При построении диаграммы классов предметной области выделение этих классов (классов-сущностей) может быть аналогично выделению сущностей в процессе моделирования данных. Данные классы должны иметь концептуальный характер и отвечать на вопрос "что?", а не "как?". Начальный список может быть составлен следующим образом:
• в описании исходных данных выделяются кандидаты в классы-существительные, которые потенциально могут соответствовать классам (при этом следует помнить, что существительные могут также относиться к объектам, ассоциациям или атрибутам классов);
Рис. 6 Диаграмма последовательности для варианта использования "Зарегистрировать налогоплательщика"
• анализируются роли кандидатов в системе. Каждый класс должен выполнять некоторые действия и взаимодействовать с другими классами. Каждый класс должен иметь уникальное имя, отражающее характер абстракции, представляемой данным классом. Если классу трудно придумать краткое и содержательное имя, то это является характерным признаком неудачного выделения класса. Рассматривается каждая возможная пара классов и устанавливается существование ассоциации между ними (по аналогии с установлением связей между сущностями в процессе моделирования данных). Присваиваются наименования ролям ассоциаций, и определяется их множественность.
Далее составляется список атрибутов каждого класса (по аналогии с определением атрибутов сущностей при моделировании данных). Процесс определения атрибутов должен быть непродолжительным, поскольку существенные атрибуты могут быть добавлены впоследствии. При этом следует убедиться, что не пропущены существенные характеристики, представленные в исходных данных.
Рис. 7 Диаграмма классов предметной области
Определяются действия (операции), выполняемые каждым классом. При определении операций нужно учитывать следующие рекомендации:
• каждая операция должна выполнять одну простую функцию;
• название операции должно отражать результат функции, а не то,
как она выполняется.
Примерами простых операций могут быть: получить значение атрибута, установить значение атрибута, добавить или исключить связь с другим объектом, удалить данный объект.
Полученная в результате диаграмма классов предметной области показана на рис. 7
Заключение
.
Я хоте лбы отметить, что на примере налоговой инспекции мы воочию убедились в целесообразности использования объектно – ориентированного подход. Но это не предел и перспектива развития объектно – ориентированного метода проектирования велика. Его отличает следующее: « объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований. » К недостаткам относятся: некоторое снижение производительности функционирования ПО и высокие начальные затраты, эти недостатки не столь существенны в целом и на чаше весов перевес будет в сторону плюсов.
Список литературы
- Грекул В.И. Проектирование информационных систем. www.intuit.ru, 2005
- Мацяшек Л.А. Анализ требований и проектирование систем. — М: Вильямс, 2002
- Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. Проектирование экономических информационных систем — М: Финансы и статистика, 2003
- С. В. Маклаков. Создание информационных систем с All Fusion Modeling Suite. — М: Диалог-МИФИ, 2003
- А. М. Вендров. Практикум по проектированию программного обеспечения экономических информационных систем. — М: Финансы и статистика, 2004
- С. В. Черемных, И. О. Семенов, В. С. Ручкин. Моделирование и анализ систем. IDEF-технологии: практикум — М: Финансы и статистика, 2002
- Л.Г. Гагарина, Д.В. Киселёва, Е.Л. Федотова. Разработка и эксплуатация автоматизированных информационных систем — М: ИД «Форум» - ИНФРА-М, 2007
- Н.З. Емельянова, Т.П. Партыка, И.И. Попов Проектирование информационных систем — М: ИД «Форум», 2009
- Применение объектно-ориентированного подхода при проектировании информационной системы (Основы унифицированного языка моделирования UML)
- Управление формированием специальных фондов предприятия
- Эволюция антимонопольного законодательства в разных странах (Проблемы развития антимонопольного законодательства в Российской Федерации)
- Анализ движения денежных средств. Структура движения денежных средств. Взаимосвязь чистой прибыли и движения денежных средств
- Управление оборотными средствами на предприятии
- Сетевая форма организации бизнеса (Теоретические основы сетевой формы организации бизнеса).
- Анализ организационной культуры (в ООО «СПОРТИВНАЯ АМУНИЦИЯ»)
- «Общие особенности кадровой стратегии малых предприятий.»
- Модель клиент-сервер (Основные принципы построения распределённых информационных систем)
- Применение объектно-ориентированного подхода при проектировании информационной системы (Структура объектно-ориентированного программирования)
- Определение сервера и клиента
- Домеханический период