МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ ИНФРОМАЦИОННЫХ СИСТЕМ

Содержание:

Введение

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

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

Аналитические исследования, выполняемые в течение по­следних лет зарубежными аналитиками, показывали не очень хороший результаты. Так, например, в 1995г. компания StandishGroup проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие вы­воды:

Только 16% проектов завершились в срок, 52,7% завершились с опозда­нием, расходы превысили запланированный бюджет.

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

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

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

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

архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);

- объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);

- объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);

- теории баз данных (модели «сущность-связь»);

- систем искусственного интеллекта (фреймы).

При разработке программного обеспечения термин «объект» впервые был введен Оле-Джоаном Далем, Бьорном Мюрхогом и Кристеном Ныгардом из Норвежского вычислительного центра (г. Осло). Они разработали язык Simula 67, созданный на основе языка Algol-60 и предназначенный для моделирования и описания сложных систем. По-настоящему широкое внедрение произошло при разработке языка SmallTalk в 1990 г. Аланом Кейем из Исследовательского центра фирмы Xerox (г. Пало-Альто). В SmallTalk использовались только объектно-ориентированные модели.

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

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

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других. Т. е., говоря об объекте «поезд», имеется в виду не обобщенное понятие поезд, как нечто состоящее из локомотивов и вагонов, а конкретный грузовой поезд с номером 1025, весом 4600 т, ведомый электровозом переменного тока ВЛ80Т с серийным номером 027, состоящий из четырехосных полувагонов с конкретными номерами и т. д. В то же время степень абстракции с точки зрения решаемой задачи может быть и более высокой. Например, при выполнении тяговых расчетов к графику движения поездов не требуется информация о серийных номерах локомотивов и вагонов, т. е. нет потребности в отличии друг от друга электровозов ВЛ80Т с серийными номерами 027 и 028.

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

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

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

Наследование – применительно к классам, оно дает возможность формировать производные классы (классы наследники), взяв вслед за базой все без исключения методы и компоненты базового класса (класса родителя). При этом в дочернем классе могут быть установлены дополнительные свойства и методы. К примеру, дочерний класс «круг» станет наследовать с родительского класса «геометрическая фигура» все без исключения свойство r – радиус круга, (х, у) координаты центра фигуры, color – цвет и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.).

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

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

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

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

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

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

Но более существенный вклад в объектовый подход был привнесен объектами и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal и другие. В объектный подход оказали воздействие также развивавшиеся довольно независимо методы моделирования баз данных, в особенности подход «сущность-связь».

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

• типизация (typing)',

• параллелизм (concurrency)',

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

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

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

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

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

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

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

Третье отличие двух подходов состоит в структурной организации изнутри модулей системы. В структурном подходе модуль состоит из функций, иерархически сопряженных между собою взаимоотношением композиции (англ. Part of – часть целое), т. е. роль состоит из подфункций, подфункция из под подфункций и т.д. В объектно- ориентированном раскладе иерархичность строится с применением двух взаимоотношений: композиции и наследования (англ. IS A – это есть). При этом в объектно- ориентированном подходе «объект - часть» способен вводиться мгновенно в ряд «объектов - целое». Подобным способом, модуль в структурном подходе является в варианте дерева, а в объектно - ориентированном подходе – в облике ориентированного графа, .е. с поддержкой наиболее единой структуры.

Наиболее популярными методологиями, поддерживающими данный подход, в настоящий момент являются:

- Унифицированный процесс (Unified Process, UP);

- экстремальное программирование (eXtreme Programming, XP);

- гибкое моделирование (Agile Modeling, AM).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Один с более известных стилей моделирования считается UML. Данную система обозначений, которой возможно использовать с целью объектно-ориентированного анализа и проектирования. В немой учтены все исключения нюансы формирования программного обеспечения: анализ, проектирование, разработка. UML установлен в свойстве международного эталона моделирования программных систем. Образец UML удерживается многочисленными крупными изготовителями программного предоставления (Microsoft Visual Modeler for Basic, Rational Rose, Delphi и др.).

3.1. Концептуальная модель UML

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

3.1.1 Строительные блоки UML

Словарь языка UML включает три вида строительных блоков:

• сущности;
• отношения;
• диаграммы.

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

В UML существуют четыре типа сущностей:

• структурные;
• поведенческие;
• группирующие;
• аннотационные.

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

• Класс (Class)
• Интерфейс (Interface)
• Кооперация (Collaboration)
• Прецедент (Use case)
• Активным классом (Active class)
• Компонент (Component)
• Узел (Node)

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

Язык моделирования UML включает в себя следующий набор диаграмм:

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

Диаграмма развёртывания – для моделирования физической архитектуры системы и другие.

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

• • Диаграмма компонентов – постоянная структурная диаграмма, демонстрирует разделение программной системы в структурные компоненты и взаимосвязи (зависимости) среди компонентов
  • Диаграмма коммуникации1 (в UM 1.x  диаграмма  кооперации) – диаграмма, в которой представляются взаимодействия среди элементами композитной структуры либо значениями кооперации

В полном интегрированная модель непростой системы UML может быть показана в варианте совокупности отмеченных выше диаграмм (рис. 1)

Рис. 1. Интегрированная модель сложной системы в нотации UML

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

При разработке ИС, создаются и такие элементы, как:

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

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

3.1.2. Где используется UML

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

• информационные системы масштаба предприятия;
• банковские и финансовые услуги;
• телекоммуникации;
• транспорт;
• оборонная промышленность, авиация и космонавтика;
• розничная торговля;
• медицинская электроника;
• наука;
• распределенные Web-системы.

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

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

3.2. Общие диаграммы

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

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

Диаграмма использования (use case diagram) ‒ это более единое понимание функционального направления системы 

Диаграмма использования вызвана дать ответ в основной вопрос моделирования: то что создает концепция в внешнем мире?

На  иаграмме использования применяют 2 вида ключевых сущностей: варианты использования 1 и действующие лица 2, среди которых формируются последующие основные виды отношений: ассоциация между действующим лицом и видом использования 3; обобщение меж действующими лицами 4; обобщение среди вариациями использования 5; зависимости (разных типов) между вариациями использования 6.

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

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

Рис. Нотация диаграммы вариантов использования

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

Диаграмма классов (class diagram) ‒ главной метод отображения структуры системы.

Данное не удивительно, так как UML в главную очередность объектно-ориентированный язык, и классы считаются основным (если не единственным) "строй материалом"

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

ассоциация между классами 2 (с множеством дополнительных подробностей);

обобщение между классами 3;

зависимости (различных типов) между классами 4 и между классами и интерфейсами.

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

показаны ниже.

Рис. Нотация диаграммы классов

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

Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.

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

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

Рис. Нотация диаграммы деятельности

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

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

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

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

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

Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.

На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ четырехугольник с именем классификатора Пунктирная направление, выходящая с него, именуется чертой существования (lifeline 4. Данное никак не определение взаимоотношения в модификации, а графический комментарий, призванный сосредоточить мнение читателя диаграммы в верном направлении. Фигуры в варианте узких полосок, положенных в черту жизни, того не считаются изображениями имитируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация(activation) объекта. Составные операции взаимодействия(combined fragment) 6 дают возможность в диаграмме последовательности, отображать и алгоритмические аспекты протокола взаимодействия.

Рис. Нотация диаграммы последовательности

Диаграмма коммуникации

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

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

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

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

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

Рис. Нотация диаграммы коммуникации

Диаграмма компонентов

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов ‒ это сами элементы 1, а кроме того интерфейсы 2, с помощью коих указывается связь среди компонентами. В диаграмме частей используются последующие взаимоотношения:

реализации между компонентами и интерфейсами (компонент реализует интерфейс);

зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3.

На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов.

Рис. Нотация диаграммы компонентов

Диаграмма развёртывания

Диаграмма развертывания (deployment diagram) наряду с отражением состава и взаимосвязей компонентов концепции демонстрирует, равно как они на физическом уровне расположены в вычисляемыых ресурсах в период выполнения.

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

На рисунке представлены главные компоненты нотации, используемые в диаграмме размещения. С целью этого чтобы продемонстрировать, то что одна сущность считается частью другой, используется или подход связи «deploy» 5, или личность одной сути располагается вовнутрь формы иной сущности 6.

Рис. Нотация диаграммы развёртывания

3.3. Правила языка UML

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

В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:

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

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

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

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

3.4. Общие механизмы языка UML

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

• спецификации (Specifications);
• дополнения (Adornments);
• принятые деления (Common divisions);
• механизмы расширения (Extensibility mechanisms).

4. Характеристика Case – средств проектирования информационных систем

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

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

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

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

4.1. ModelMaker

Case – средство ModelMaker – это инструмент объектно - ориентированного проектирования информационных систем. Он основан на последних стандартах языка проектирования UML.

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

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

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

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

ModelMaker, как и другие CASE - средства проектирования, позволяет вести удобное документирование проекта

4.2. Rational Unified Process

Рациональный унифицированный процесс (Rational Unified Process, RUP) — использует спиральную методологию разработки программного обеспечения. Методологией занимается компанией Rational Software, обновляют продукт примерно один раз в полгода. Использует язык моделирования в общей базе Unified Modelling Language (UML).

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

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

Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам в ранних стадиях цикла разработки, а далее пересматриваются с течением периода и с развитием проекта в процесс дальнейшихитераций. Новые цели возникают зависимо от ценностей данных рисков. Выпуск версий распределяются таким образом, что наиболее главные ошибки устраняются первыми.

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

4.3 JSD

Методология JSD (Jackson Structured Development) имеет свой стиль создание программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80-х годов, особенно имеет большой спрос в Европе.

В методологии JSD не делают различий между этапами анализа требований к системе и этапами ее разработки; они объединяются в один большой этап разработки спецификаций проектируемой системы. На этом этапе решается такие вопросы "что должно быть сделано"; вопрос "как это должно быть сделано" реализуется на другом этапе - этапе реализации системы. Методология JSD часто применяется для проектирования систем реального времени.

Как и другие методологии, JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT.

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

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

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

5. Архитектура

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

Архитектура — это совокупность существенных решений касательно:

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

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

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

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

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

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

Вид  с  точки   зрения   развертывания (Deployment view) включает участки, создающие топологию аппаратных средств системы, на которой она производится. В главную очередность он связан с распределением, поставкой и установкой элементов, составляющих физическую систему. Его постоянные нюансы описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий

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

6. Этапы реализации объектно-ориентированного подхода

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

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

Рассмотрим эти этапы.

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

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

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

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

Само название этапа подчеркивает поэтапный характер процесса, упрощающий сборку системы.

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

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

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

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

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

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

Заключение

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

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

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд. перераб. и доп. – М.: Финансы и статистика, 2005. – 544 с.
2. Проектирование информационных систем на основе современных CASE – технологий: Учебное пособие. – М.: МГИУ, 2007. – 287 с.
3. Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер. 2007. – 544 с.
4. Методология JSD http://citforum.ru/programming/oop_rsis/glava4_3.shtml
5. ModelMaker http://nazir.pro/article_1
6. Rational Unified Process http://www.interface.ru/rational/rup01_t.htm