"применение объектно-ориентированного подхода для информационной системы" [курсовая №83207]

2.1 Системное программное обеспечение

Системное программное обеспечение (System Software) — это совокупность
программ, которые служат для эффективной работы аппаратуры компьютера.
Системное ПО подразделяется на базовое и сервисное.

Базовое ПО включает в себя: операционные системы, оболочки.

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

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

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

Сервисное ПО включает в себя программы :утилиты, драйверы, архиваторы,
антивирусные и некоторые другие программы.

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

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

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

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

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

Таким образом, системное ПО — это совокупность программных и языковых
средств.

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

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

Преимущества от изучения предметно-ориентированного программирования:

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

Недостатки от изучения предметно-ориентированного программирования:

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

Предметно-ориентированное проектирование (DDD) и ограниченный контекст

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

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

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

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

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

Область: представляет предметную область деятельности организации. В примере ниже это будет розничная торговля (Retail) и электронная коммерция (eCommerce). Область составляется из нескольких подобластей.

Подобласть: подразделение организации.

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

Рис. 1 Подобласти и ограниченный контекст в области eCommerce

Ограниченный контекст. Предметно-ориентированное проектирование определяет ограниченный контекст так: “Установка, в которой появляется слово или фраза, определяющая её значение”. Говоря коротко, это означает границу, внутри которой модель имеет смысл. В примере выше “Item” принимает различное значение в каждом из вариантов контекста. В контексте Catalog Item означает продаваемый продукт, а в контексте Cart оно означает предмет хранилища, который отправляется клиенту. Каждая из этих моделей своеобразна, имеет различное значение и, скорее всего, содержит разные атрибуты. Разделяя и изолируя эти модели внутри соответствующих им границ, мы можем легко и без двусмысленности выражать модели.

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

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

3.4 Методо-ориентированные ППП

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

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

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

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

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

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

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

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

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

Рисунок 4. Применение ПОЯ при формировании модели предметной области

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

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

Предметно-ориентированные системы научной осведомленности

В национальном стандарте США термин «производство знаний» определяется как:

· разработка и обеспечение новых знаний (JECD 1966:2);

· обстоятельства, при которых люди, группы людей и организации успешно генерируют новые знания и практики (OECD 2000:39).

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

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

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

Общая программная архитектура такой системы показана на Рис. 1.

Рис. 1. Общая программная архитектура предметно-ориентированных систем научной осведомленности.

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

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

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

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

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

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

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

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

Избегайте оркестрации между сервисами, снабжающими потребителей данными

Один из главных антишаблонов в любой сервис-ориентированной архитектуре — ситуация, когда сервисы обслуживают конкретные шаблоны доступа потребителей. Обычно это происходит, когда команды клиентской стороны тесно раюотают с командами сервисов. Если команда работала над монолитным приложением, то могла создать единый API, пресекающий границы различных агрегатов, тем самым тесно сцепляя их. Предположим, что странице Order Details (детали заказа) в веб- и мобильных приложениях нужно показать детали как самого Order, так и детали процесса возврата средств по нему на одной странице. В монолитном приложении Order GET API (предположим, что это REST API) запрашивает Orders и Refunds вместе, консолидирует оба агрегата и отправляет составной ответ вызывающему. Это можно сделать без лишней траты ресурсов, поскольку агрегаты находятся в одной и той же границе процесса. Таким образом, получателям может быть передана вся необходимая информация в одном вызове.

Если Orders и Refunds относятся к разным контекстам, то данные больше не будут присутствовать в одном микросервисе или границах агрегата. Одним из способов сохранить ту же самую функциональность для клиентов будет сделать сервис Order ответственным за вызов сервиса Refunds и создать составной ответ. Такой подход вызывает ряд проблем:

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

Взаимодействия между контекстами

Тип	Описание	Изображается
ПАРТНЕРСТВО	Равные отношения взаимовлияния — две группы разработчиков занимаются отдельно своими ограниченными контекстами, прибегая к взаимодействию с целью достижения общей цели. В таком взаимодействии успеха или провала достигают обе группы.
ОБЩЕЕ ЯДРО (SHARED KERNEL)	ОБЩЕЕ ЯДРО часто представляет собой СМЫСЛОВОЕ ЯДРО предметной области (CORE DOMAIN), набор ЕСТЕСТВЕННЫХ ПОДОБЛАСТЕЙ (GENERIC SUBDOMAINS) или то и другое одновременно. Две команды вместе работают над общей частью.
КЛИЕНТ — ПОСТАВЩИК (CLIENT- SUPPLIER)	Такие отношения между командами, в которых команда-поставщик является вышестоящей, а команда потребитель нижестоящей. Такие отношения выстраиваются между командами с общим руководством, когда поставщик должен учитывать потребности клиента. Можно видеть, что Клиент-Поставщик очень похож на партнёрство, но в работе команд возникает некоторый перекос, который делает одну из них ведущей.
КОНФОРМИСТ (CONFORMIST)	Разновидность поставщик-потребитель, которая требует области подстройки. Возникает в том случае, если вышестоящая команда не имеет мотивации для удолитворения нужд нижестоящей.
ПРЕДОХРАНИТЕЛЬНЫЙ УРОВЕНЬ (ANTICORRUPTION LAYER)	Разновидность отношения конформист, у которой область подстрой выделена в отдельный слой, с полноценной трансляцией для соблюдения правил ограниченного контекста. Возникает в тех случаях, когда разница Единого Языка становится значительной, а синхронизация команд затруднительной.
СЛУЖБА С ОТКРЫТЫМ ПРОТОКОЛОМ (OPEN HOST SERVICE)	Разновидность отношения конформист, которая облегчает многочисленные интеграции с вышестоящим контекстом.
ОБЩЕДОСТУПНЫЙ ЯЗЫК (PUBLISHED LANGUAGE)
ОТДЕЛЬНОЕ СУЩЕСТВОВАНИЕ (SEPARATE WAYS)	Случай когда договорится не получается и команды работают полностью отдельно.

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

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

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

Боггс, У. UML и Rational Rose: Пер. с англ. / У. Боггс, М. Боггс. – М.: Издательство «Лори», 2000.  581 с.
Брукс Ф. Мифический человеко-месяц или как создаются программные системы / пер. с англ. — 2-е изд., доп. и испр. — М. : Символ, 2010. — 304 с.
Брукс, Ф. Проектирование процесса проектирования: записки компьютерного эксперта / пер. с англ. — М. : И. Д. Вильямс, 2013. — 464 с.
Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. – М.:ДМК Пресс, 2001. – 432 с.
Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. «СУБД», 1995, №3.
Грекул В.И. и др. Проектирование информационных систем. Учебное пособие. – М.: Интернет-Университет информационных технологий, 2005. – 303 с.
Игнатьев А.В. Методы и средства проектирования информационных систем и технологий. Учебное пособие. – Волгоград: Волгоградский государственный архитектурно-строительный университет, 2014 – 57 с.
Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование / пер. с англ. – М.: ДМК Пресс, 2001. – 176 с.
Кулябов, Д. С. Введение в формальные методы описания бизнес-процессов. Учеб. пособие / Д. С. Кулябов, А. В. Королькова. — М. : РУДН, 2008. — 173 с.
Ларман, К. применение UML и шаблонов проектирования: Пер. с англ. / К. Ларман – М.: Издательский дом «Вильямс», 2001. – 496 с.
Макарова Н. В., Волков В. Б. Информатика : учеб. для вузов. — СПб. : Питер,2011. — 576 с.
Мацяшек Л. А., Лионг Б. Л. Практическая программная инженерия на основе учебного примера / пер. с англ. — М. : БИНОМ. Лаборатория знаний, 2009. — 956 с.
Новиков, Ф. А. Моделирование на UML. Теория, практика, видеокурс / Ф. А. Новиков, Д. Ю. Иванов. — СПб.: Профессиональная литература. Наука и Техника, 2010. — 640 с.
Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. Киев, «Диалектика», 1993. – 214 с.
Шеер А. В. Бизнес-процессы. Основные понятия. Теория. Методы. – М.: Весть-МетаТехнология, 1999. – 173 с.

Разработка бизнес-плана организации гостеприимства (Разработка бизнес-плана создания гостиницы «Уют» в г. Москва)
Мотивационные программы для сотрудников ресторана на примере ресторана Кимчи
Оценка страхования и его государственного регулирования в России
Россия в системе международных кредитных отношений (Оценка международных кредитных отношений)
Личное страхование и перспективы его развития в РФ (Теоретические аспекты сущности страхования и особенности личного страхования).
«Международный валютный фонд: цели, функции, особенности»
Нотариальные действия (Общие правила совершения нотариальных действий)
«Культура предпринимателя. Деловая этика предпринимателя»
Понимание процессного подхода
«Организация ремонтного хозяйства на предприятии»
Формирование оперативного управления как определяющего фактора развития производства на предприятии.
Современное состояние управления знаниями в компаниях

Заключение

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

Создаём расширение для Chrome
Великолепная десятка библиотек SVG иконок
Пять алиасов Git, без которых мне не прожить

Читайте нас в телеграмме, vk и