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

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

Содержание:

Введение

В эпоху внедрения компьютеров ни для кого не секрет, что без компьютерной техники и специализированного программного обеспечения практически не обойтись. Использование специализированных программ дает возможность улучшить качество выполняемой работы, упростить человеческий труд, ускорить выполнение технологического процесса, облегчает синхронизацию и передачу информации и многое другое. В большинстве случаев используемые программные комплексы хранят производственную информацию, которая должна быть доступна некоторому количеству пользователей и, зачастую, пользователи работают с данными одновременно. Эти идеи послужили основой концепции, согласно которой данные должны быть организованны в базы данных, для управления ими, широко используются системы управления базами данных (СУБД). Проектирование экономических информационных систем (ЭИС) - логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов. В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это проявлялось в том, что крупные проекты стали выполнятся не в срок или превышали смету расходов. Разработанный продукт не соответствовал функциональным возможностям, производительность его была не высока, качество получаемого программного обеспечения не устраивало потребителей. Аналитические исследования и обзоры, выполняемые в начале XXI века, головными зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, в 1995г. компания StandishGroup проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы: только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет. В числе причин неудач представлены нечеткая и неполная формулировка требований к ПО, недостаточное вовлечение пользователей в работу над проектом, неудовлетворительное планирование и т.п. На этом фоне, выгодно отличается объектно-ориентированный подход к проектированию ПО. Он устраняет эти и другие недостатки, он обладает богатым набором изобразительных средств.

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

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

1.Объектно-ориентированные методы анализа и проектирования

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

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

Главное в разработке UML было следующее:

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

Стандарт UML версии 1.1, принятый OMG в 1997 г., содержит следующий набор диаграмм:

1.Структурные (structural) модели:

диаграммы классов (class diagrams) – для моделирования статической

структуры классов системы и связей между ними;

диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

2.Модели поведения (behavioral):

диаграммы вариантов использования (use case diagrams) – для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей и системы);
диаграммы взаимодействия (interaction diagrams);
диаграммы последовательности (sequence diagrams) и кооперативные;
диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;
диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе в другое состояние;
диаграммы деятельности (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.

1.1.Основные принципы построения модели

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

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

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

Анализ вариации использования проводится проектантами и включает в себя:

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

1.2.Оновные элементы объектной модели

К основным понятиям объектной модели относятся:

объект;
класс;
атрибут;
операция;
интерфейс;
компонент;
связи.

Объект определяется как ощутимая субстанция (tangible entity) — предмет или явление, имеющее конкретное определяемое поведение.

Объект может представлять собой абстракцию некой сущности предметной области или программной системы. Любой объект обладает состоянием (state), поведением (behavior) и уникальностью (unikum).

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

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

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

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

Каждый объект обладает уникальной особенностью. Что отличает данный объект от другого.

Структура и поведение похожих объектов определяют общий класс для них.

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

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

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

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

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

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

компонентом исходного кода;
компонентом времени выполнения (run time);
исполняемым компонентом.

Компонент обеспечивает физическое совершение набора интерфейсов.

Ассоциация (association) — это семантическая связь между классами.

2.Методология объектно-проектирования на языке UML

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

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

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

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

Язык UML находится в процессе унификации, проводимом OMG (Object Management Group) – организацией по унификации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве типичного языка моделирования и получил неограниченную поддержку в индустрии ПО.

Язык UML взят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.

Главными в разработке UML ставили цели:

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

2.2.Диаграмма вариантов использования USE CASE DIAGRAM

Диаграмму вариантов использования имеет смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на последующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно, ее можно использовать для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).

На диаграмме использования изображаются:

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

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

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

Дополнить прецеденты словесным описанием (сценарием):

для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»;
при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.

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

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

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

use-case-example

Пример диаграммы использования

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

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

2.3.Диаграмма классов USE CASE DIAGRAMS

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

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

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

Ключевым элементом диаграммы классов является класс.

Обозначается значком:

[image[88].png]

Класс состоит из двух частей – заголовка с именем класса и тела с описанием его полей (Атрибуты – в терминах UML) и методов (Операции - в терминах UML).

Абстрактные классы отличаются наклонным написанием заголовка:

Под атрибутами класса в терминологии UML понимают его поля.

Атрибуты записываются с указанием доступности, имени и типа.

Знак минус означает, что атрибут приватный (private).

Знак плюс означает, что атрибут публичный (public).

Знак решетка означает, что атрибут защищенный(protected).

После имени следует указание типа атрибута.

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

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

Абстрактные методы записываются наклонным курсивом

Кроме классов, не мало важным элементом диаграмм классов считаются интерфейсы.

Интерфейс обозначается так:

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

Перечисление обозначается так:

Обычно перечисление указывается с росписью возможных значений

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

Взаимосвязи бывают различных типов и отображаются, соответственно, по-разному.

Генерализация или наследование (Generalize) обозначается так:

На примере показано, что два класса являются наследниками обобщенного класса.

Реализация (Realize) – означает, что данный класс реализует данный интерфейс:

Ассоциация (Associate). Самая востребованная взаимосвязь между классами. У нее достаточно широкое значение и может пояснять следующее:

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

2.Один класс включает в себя субъект другого класса.

Видим, что перечисление Status включено в класс User, при этом имя поля Status, с областью видимости public.

3.Один класс включает в себя несколько субъектов другого класса.

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

[image[143].png]

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

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

Кроме стандартного значка класса, есть дополнительные, которые применяются для некоторых типов классов. Здесь приведены три чаще всего используемых обозначения, которые применяются для работы с шаблоном «Модель-Представление-Контроллер»:

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

2. Класс-контроллер (Controller) – как правило, используется для классов, которыми пользуются для выполнения неких операций над объектами.

3. Класс - Разграничитель (Boundary) – обычно используется для классов, разделяющих внутреннюю структуру системы от внешней среды. Это могут быть как WebServices, так пользовательский интерфейс и др.

2.4.Диаграмма взаимосвязи INTERACTION DIAGRAMS

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

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

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

Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-адресате.

Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-адресата выполнение некоторых действий.

Имеется два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

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

3.1. IBM RATIONALROSE

Все продукции Rational Rose поддерживают язык Unified Modeling Language (UML), но при этом, эти продукции различаются технологиями реализации, которые они поддерживают. Rational Rose - среда моделирования, которая поддерживает генерацию кода из моделей, написанных на языке Ada, ANSI C++, C++, CORBA, Java/J2EE, Visual C++ и Visual Basic.

IBM Rational Rose - доступное средство визуального моделирования, как правило, считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite (для виртуализации десктопов). Предназначен для моделирования ПС с использованием крупного спектра инструментальных средств и платформ. Инструментальное средство IBM Rational Rose увеличивает шансы моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

3.2. SPORX SYSTEMS ENTERPRASE ARCHITECT

Enterprise Architect - это платфора для UML-моделирования и проектирования нового поколения.

Enterprise Architect bvttncz в вариантах для Windows и Linux и служит неплохим средством для UML-моделирования, с имеющейся возможностью многопользовательской работы и доверительным интерфейсом. В этой программе изобилие функций, которые обычно распределены между несколькими приложениями, включая объективные возможности по генерации документации, поддержку плагинов, генерацию XSD-схем, HTML и поддержку для таких языков программирования, как C++, Java, PHP, Visual Basic, VB.Net, Delphi или C#.

Возможности Enterprise Architect весьма многообещающие. Существует в трех редакциях:

EA Desktop Edition

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

EA Professional Edition

Полномасштабная среда UML-моделирования, ориентированная на групповую разработку, поддерживает объединенный доступ к созданным моделям, Active X, XMI, импорт/экспорт кода и DDL, извлечение схем БД Oracle, SQL Server и MS Access.

EA Corporate Edition

Полноценная редакция, охватывающая все возможные средства настольной и профессиональной версий, с реальной вероятностью соединения с MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere и Oracle9i. Также эта редакция поддерживает авторизацию пользователей, группы пользователей, блокировку субъектов. Эта версия предназначена для больших команд.

3.3.СOMPONENT MODELER семейства продуктов ALLFUSION

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

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

Component Modeler гарантирует полноценную поддержку методов разработки компонентов и неограниченные возможности моделирования, которые позволяют компаниям:

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

3.4. MICROSOFT VISUAL MODELER

Visual Modeler - это инструмент, оказывающий помощь в создании сложных программных систем. История развития программного обеспечения и, в частности, вопросов, связанных с его проектированием, особенно на уровне компонент, показала, что без наличия стандарта для описания моделей и без наличия инструмента, поддерживающего такой стандарт и позволяющего визуально отображать модели, процесс проектирование становится практически невозможным. Многие компании занялись разработкой подобного стандарта и инструментов. В результате появился на UML - Unified Modeling Language и изобилие поддерживающих его инструментов, одним из которых является Visual Modeler.

Заключение

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

В качестве CASE-средства проектирования рассматриваются такие инструмент, как Ibm Rational Rose, Sporx Systems Enterpise Architect, Micr osoft Visual Modeler c хорошо известной системой объектно-ориентированного программирования.

Подробно описаны приемы построения таких основных диаграмм моделирования ИС, как диаграммы вариантов использования (диаграммы прецендентов), диаграммы последовательностей и диаграммы классов.

Цели курсовой работы были достигнуты, задачи решены.

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

Бендронов А.Н. Проектирование программного обеспечения экономических информационных систем: Учебник. – 3-е изд. перераб. и доп. – М.: Финансы и статистика, 20015. – 544 с.
Бендронов А.Н. Практикум по проектированию программного обеспечения экономических информационных систем: Учебн. пособие. – 3-е изд. перераб. и доп. – М.: Финансы и статистика, 2016. – 192 с.
Проектирование информационных систем на основе современных CASE – технологий: Учебное пособие. – М.: МГИУ, 2017. – 287 с.
Программирование на языке высокого уровня: Учебник для вузов / В.В. Фамонюк. – Питер, 2014. – 640 с.
Дж. Рамбо, М. Плаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 4-е изд. – СПб.: 2017. – 544 с.
Структурное проектирование информационных систем: Методические указания к лабораторным и расчетно-графическим работам / Сост. А.В. Михеев. Красноярск, КГТУ, 2016. – 52 с.
Железнов М. Д. Проектирование информационных систем на основе современных CASE- технологий : Учебное пособие. – М.: МГИУ 2015. – 287.
Калякин Е.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 2015.
Лонстантайн Л., Локвуд Л. Разработка программного обеспечения. Питер, 2014.
Мрейн Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2016. 450 – 490 с.
Ниго К.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2015. – 592 с.
Информационные системы: Учебник для вузов. 3-е изд. СПб: "Питер", 2018. - 656 стр.
Родан Бринзаре, Филипп Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2016.
Разработка программного обеспечения - СПб : 2014. - 592 стр.
Реляционные базы данных: практические приемы оптимальных решений. –БХВ-Петербург, 2014 – 400с.:ил;
Симоненко Ю.Ф., Доромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2016, 250с., ил.