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

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

Содержание:

Введение

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

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

В последние годы, ведущими зарубежными аналитиками были проведены аналитические исследования и обзоры, которые, показали не очень обнадеживающие результаты. Так, в 1995 году Standish-Group провели анализ работ 364 американских корпораций и результатов более 23 тысяч проектов, которые были связанны с разработкой программного обеспечения, и пришла к следующим, не утешительным выводам: Из общего числа, лишь 16% проектов были выполнены вовремя, 52,7% - с большим опозданием, а расходы в разы превысили запланированный на разработку бюджет.

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

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

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

  • рассмотрение сущности и преимуществ объектно-ориентированного подхода;
  • анализ предметной области;
  • применение объектно-ориентированного подхода при проектировании ИС.

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

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

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

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

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

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

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

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

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

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

  • унифицированный процесс (Unified Process, UP);
  • экстремальное программирование (eXtreme Programming, XP);
  • гибкое моделирование (Agile Modeling, AM).

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

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

  • архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);
  • объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);
  • объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);
  • теории баз данных (модели «сущность-связь»);
  • систем искусственного интеллекта (фреймы).

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

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

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

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

Индивидуальность-это свойство существа, по которому вы можете отличить его от других. То есть, когда я говорю об объекте "производственная линия", я имею в виду не обобщенное понятие, как состоящего из конвеера, АСУ и прочих составляющих, а конкретную производственную линию N 15 для печатных плат.

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

Класс-это совокупность объектов с общей структурой и поведением [7, С. 39]. Таким образом, класс-это шаблон, из которого генерируются (создаются) аналогичные объекты. Термин "экземпляр класса "часто используется как синоним слова"объект".

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

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

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

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

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

Полиморфизм - это принцип построения элементов модели таким образом, чтобы они могли принимать различные внешние формы или функции (поведение) в зависимости от обстоятельств. Например, методы draw () или calculateS () для классов круга и ромба, которые определены путем наследования атрибутов и методов родительского класса фигур, должны быть реализованы по-другому.

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

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

  • единый процесс;
  • единый язык моделирования;
  • шаблоны проектирования.

Единый процесс-это процесс разработки программного обеспечения, обеспечивающий дисциплинированный подход к распределению задач и обязанностей в организациях [5, С. 67], данный процесс охватывает весь жизненный цикл определения требований вплоть до универсальной структуры (шаблона, каркаса), которая использует специализированную структуру для разработки и поддержки широкого спектра приложений.

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

Предпосылки возникновения языка моделирования UML были выявлены в связи с бурным развитием объектно-ориентированных языков программирования (Simula 67, Smalltalk, Objective C, C++ и др.) Во второй половине XX века. В результате постоянно возрастающей сложности программных продуктов возникает необходимость учитывать все больше особенностей языков и средств разработки при анализе, формулировании требований и разработке программных приложений. Например, за короткий период с 1989 по 1994 год количество объектно-ориентированных инструментов выросло с десятка до более чем пятидесяти. Однако многим разработчикам было трудно найти язык моделирования, который отвечал бы их потребностям. В результате появилось новое поколение методов разработки, среди которых особую популярность приобрел метод Бутча, созданный компанией Jacobson Object-Oriented Software Engineering (OOSE) и разработанный компанией Rambo Object Modeling Technique (OMT). Помимо них существовали и другие завершенные технологии, такие как термоядерный синтез, Шлаер-Меллор и Коад-Юдон, но все они имели не только преимущества, но и существенные недостатки.

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

На этапах анализа и проектирования часто используются так называемые шаблоны проектирования. Паттерн-это именованная пара проблема / решение, содержащая полное общее решение типичной задачи [4].

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

Шаблоны разрабатываются опытными специалистами и являются проверенными, эффективными (иногда оптимальными) решениями. Использование шаблонов снижает затраты и повышает качество разработки программного обеспечения. 

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

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

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

Это облегчает решение проблем:

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

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

Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД.

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

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

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

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

САДТ

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

DFD (диаграммы потоков данных);

ERD (диаграммы сущностей-отношений).

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

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

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

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

CASE-инструменты классифицируются по типу и категории.

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

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

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

Типичные инструменты CASE:

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

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

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

2.1. Характеристика предприятия

Space exploration Technology Corporation (SpaceX) - американская аэрокосмическая компания со штаб-квартирой в Хоторне, штат Калифорния. Она была основана в 2002 году Илоном Маском с целью снижения стоимости космических перевозок для обеспечения колонизации Марса. SpaceX разработала несколько ракет-носителей, спутниковую группировку Starlink, грузовой космический корабль Dragon и доставила людей на Международную космическую станцию в составе экипажа Dragon Demo-2.

Достижения SpaceX включают первую финансируемую из частных источников жидкостную ракету, достигшую орбиты (Сокол-1 в 2008 году), первую частную компанию, успешно запустившую, выведшую на орбиту и восстановившую космический аппарат (Dragon в 2010 году), первую частную компанию, отправившую космический аппарат на Международную космическую станцию (Dragon в 2012 году), первый вертикальный взлет и вертикальную пропульсивную посадку на орбитальную ракету (Falcon 9 в 2015 году) и первую орбитальную ракету повторного использования (Falcon 9 в 2017 году), первую частную компанию, запустившую объект на орбиту вокруг Солнца (Falcon Heavy-duty Tesla Roadster в 2018 году), а также первая частная компания, отправившая астронавтов на орбиту и на Международную космическую станцию (миссия SpaceX Crew Dragon Demo-2 в 2020 году) SpaceX выполнила 20 грузовых космических полетов на Международную космическую станцию (МКС) в партнерстве с НАСА, а также демонстрационный полет беспилотного космического аппарата dragon 2 с человеческим рейтингом (экипаж demo-1) 2 марта 2019 года и первый полет экипажа dragon 2 30 мая 2020 года включительно.

В декабре 2015 года Falcon 9 совершил аварийную вертикальную посадку. Это было первое такое достижение ракеты для орбитального космического полета. В апреле 2016 года с запуском SpaceX CRS-8 компания SpaceX успешно вертикально посадила первую ступень на посадочную платформу океанского беспилотного космического аппарата.[18] в мае 2016 года, в другом первом, SpaceX снова приземлился на первой ступени, но на этот раз во время гораздо более энергичной миссии по переводу на геостационарную орбиту. В марте 2017 года SpaceX стала первой компанией, успешно осуществившей повторный запуск и посадку первой ступени орбитальной ракеты. В январе 2020 года, с третьим запуском проекта Starlink, SpaceX стала крупнейшим коммерческим спутниковым оператором в мире.

В сентябре 2016 года Маск представил межпланетную транспортную систему-позже переименованную в Starship-финансируемую из частных источников систему запуска для разработки технологии космических полетов для использования в межпланетных миссиях с экипажем. В 2017 году Маск представил обновленную конфигурацию системы, которая предназначена для обработки межпланетных миссий плюс станет основной ступенью орбитального аппарата после начала 2020-х годов, так как SpaceX объявила, что в конечном итоге намерена заменить существующую ракету-носитель Falcon 9 и флот космических капсул Dragon кораблем, даже на рынке доставки спутников на околоземную орбиту.

Из выше сказанного, видно, что основной деятельностью компании SpaceX является разработка передовых технологий для полета в космос. Для обеспечения постоянной и бесперебойной работы столь масштабной организации используется большое количество компьютерного оборудования и программного обеспечения. Обслуживание всей компьютерной техники производит отдельный филиал кампании – Главный Вычислительный Центр. Так как территория, которую обслуживает компания, покрывает огромную территорию нескольких штатов (Brownsville, TX; Cape Canaveral, FL; Hawthorne (Los Angeles); Irvine, CA; McGregor (Waco), Redmond (Seattle), WA), то для улучшения управляемости, филиал разделен на структурные подразделения – информационно-вычислительные центры каждого направления. Информационно-Вычислительный Центр, который расположен на головной территории зоны SpaceX, производит полное обслуживание основного центра и контроль всего комплекса вычислительных систем всех подразделений, сетей и программного обеспечения всего комплекса в целом.

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

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

2.2. Обоснование необходимости проектирование ИС

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

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

Диаграмма представлена на рис 1.

Рис. 1. Диаграмма вариантов использования модуля «Резерв»

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

Диаграмма представлена на рис. 2.

Рис. 2. Диаграмма вариантов использования модуля «ЗРМ»

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

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

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

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

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

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

Списки позволяют установить права с точностью до пользователя. Здесь нетрудно добавить права или явным образом запретить доступ. Списки используются в подсистемах безопасности операционных систем и систем управления базами данных.

Разграничение доступа по уровням секретности и категориям заключается в разделении ресурсов информационной системы по уровням секретности и категориям.

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

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

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

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

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

3.1. Выбор средств объектно-ориентированного подхода

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

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

UML-диаграммы представляют собой два различных представления модели системы:

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

Модели UML можно обмениваться между инструментами UML с помощью формата XML Metadata Interchange (XMI).

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

Инструмент Case (от Computer Aided Software / System engineering) сообщества Jude был использован для разработки UML-диаграмм для этого приложения. Инструмент Case позволяет моделировать бизнес-процессы, программные компоненты, а также структуру и деятельность организаций. Использование кейс - инструментов оптимизирует эффективность проектирования и снижает вероятность возникновения затрат и ошибок.

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

Преимущества от использования:

  • унифицированное средство общения между разработчиками;
  • ускорение разработки;
  • увеличение продуктивности.

Поскольку проектируемый АРМ будет состоять из программного обеспечения и базы данных, целесообразным является разработать диаграмму вариантов использования, диаграммы последовательностей и кооперативную диаграмму средствами JUDE. Разработка базы данных будет производится специализированным case-средством ERWIN.

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

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

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

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

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams).

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

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

Рис.5. Диаграмма последовательности: составление заявки на ЗРМ

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

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

Для построения диаграммы сотрудничества выполяются следующие действия:

1)Отображаются объекты, участвующие во взаимодействии;

2)Отображаются ссылки, которые соединяют эти объекты;

3)Ссылки помечаются сообщениями, которые отправляются и принимаются выбранным пользователем.

На рисунке 6 показан данный вид диаграммы.

Рис. 6. Диаграмма сотрудничества

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

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

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

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

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

Диаграммы деятельности состоят из ограниченного числа фигур, соединенных стрелками.

Основные формы (узлы): округлые

Прямоугольники-это действия (операции).

На рисунке 7 показан данный вид диаграммы.

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

Узел управления-это абстрактный узел деятельности, который координирует поток действий.

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

Широкие полосы-это начало (ветвление) и конец (конвергенция) ветвящихся действий. Узел соединения имеет два или более входящих соединения и один исходящий узел.

Черный круг- это начало процесса (начальный узел). Начальный узел действия-это управляющий узел, где поток (или потоки) запускается при вызове действия извне.

Черный круг с контуром-это конец процесса (конечный узел). Конечный узел действия (или конечное состояние действия) - это управляющий узел, который останавливает все потоки этой диаграммы действий.

Заключение

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

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

Список использованной литературы

  1. Введение в системы баз данных – СПб: Издательский дом "Вильямс", 200. - 848 с.;
  2. Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2011 – 400с.:ил;
  3. Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2006.
  4. Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.
  5. Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2006. 450 – 490 с.
  6. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
  7. Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2010. - 656 стр.
  8. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 2009.
  9. Разработка программного обеспечения - СПб : "Питер", 20100. - 592 стр.
  10. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. // М.: «Финансы и статистика», 2011.
  11. Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2006, 250с., ил.
  12. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 1992. – 233 с.
  13. Вэнс, Эшли Илон Маск. Tesla, SpaceX и дорога в будущее / Эшли Вэнс. - М.: Олимп-Бизнес, 2015. - 416 c.