Разработка информационной системы в контексте AS-IS и TO-BE - Программирование, компьютеры и кибернетика курсовая работа

Главная

Программирование, компьютеры и кибернетика
Разработка информационной системы в контексте AS-IS и TO-BE

Справочная система как программный продукт, позволяющий пользователю получить точную информацию по теме. Основные особенности построения модели AS-IS. Анализ контекстной диаграммы модели TO-BE. Сущность диаграммы компонентов серверной части проекта.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
справочный система программный диаграмма
Стремительное развитие и повсеместное применение информационных технологий, превращение информации в ценнейший ресурс жизнедеятельности обусловливает движение человечества к информационному обществу. В условиях перехода к информационному обществу ведение эффективного бизнеса и достижение высокого качества жизни возможны только при условии эффективного управления информационными ресурсами. Сегодня потребитель должен иметь возможность получать требуемую информацию в нужном виде, в приемлемые сроки, практически в любом месте и за умеренную плату.[1]
Справочная система предназначена для получения пользователем максимально точной (релевантной) информации по интересующей его (и ограниченной базой статей) теме. Обычно выбор статьи происходит по иерархии разделов справки. Справочные системы часто комбинируются с поисковыми системами, где выборка релевантных статей определяется по заданным ключевым словам или (при полнотекстовом поиске) частью предложения.
Таким образом, справочная система - это, в данном случае, программный продукт, позволяющий пользователю получить точную информацию по теме, либо задав некоторые условия поиска, либо выбрав необходимую информацию из списка.
Так как в данной системе используется большой объем данных, будет целесообразно разместить их в базе данных под управлением некоторой СУБД.
Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно внесение изменений в проект на поздних этапах создания справочной системы - весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям.
Данный курсовой проект посвящен анализу и проектированию к разработке информационной системы «Учет успеваемости». Для этой цели были выбраны инструментальные средства визуального проектирования BPWin и Rational Rose.
1. Предмет разработки в контексте AS-IS и TO-BE
Для построения бизнес-процессов можно использовать Case-средства, BPwin, All Fusion Process, Modeler, графический редактор Vision и другие.
В данном случае предпочтение было отдано BPWin. При этом были использованы диаграммные техники: IDEF0 и DFD для построения декомпозиции.
Построению модели AS-IS предшествовало обследование информационной системы «Учёт успеваемости», а именно управление ведомостями института. Упомянутое включало в себя информацию о названии факультета, названии специальности, о сотрудниках, полная информация о специальности, полная информация о факультете, полная информация об студенте.
На рисунке 1.1 представлена контекстная диаграмма модели AS-IS бизнес-процесса «Учёт успеваемости».
Рисунок 1.1 - Контекстная диаграмма модель AS-IS
Данная контекстная диаграмма изображает функционирование системы в целом. Основная цель - это получения информации об успеваемости студентов на факультете и об студентах, обучающихся на этом факультете. Контекстная диаграмма имеет следующие данные и объекты, связывающие между собой работы: стрелки входа -- название факультета или фамилия студента или специальность студента; стрелка выхода -- полная информация о специальностях или студентах.
Приведем декомпозицию процесса «Учёт успеваемости студентов».
Рисунок 1.3 - Декомпозиция процесса «Получение информации о студенте»
Декомпозиция процесса «Учет успеваемости стедентов», приведенная на рисунке 1.3, была выполнена в виде DFD. Диаграмма типа DFD позволяет увидеть передаваемые процессы:
Рисунок 1.4 - Диаграмма дерева узлов модели AS-IS
На рисунке 1.4 показано дерево узлов модели «AS-IS». Модель трехуровневая, нижние уровни были представлены в виде списков.
Модель TO-BE описывает возможное будущее состояние предметной области, в которое она перейдёт в результате оптимизации существующей системы и внедрения новых технологий.
При этом предмет разработки должен поддерживать такие задачи как:
На рисунке 1.5 представлена контекстная диаграмма модель TO-BE.
Рисунок 1.5 - Контекстная диаграмма модель TO-BE
На рисунке 1.5 представлена контекстная диаграмма модели «TO-BE». Данная модель покажет, насколько эффективнее станет работа информационной системы при внедрении компьютерной информационной системы. Декомпозируем контекстную диаграмму, чтобы представить себе, насколько изменились процессы, которые мы видели в «AS-IS». Декомпозиция контекстной диаграммы модели TO-BE в диаграмму IDEF0 изображена на рисунке 1.6.
Рисунок 1.6 - Декомпозиция модели TO-BE
На рисунке 1.6 мы видим декомпозированную контекстную диаграмму. Процессы остались те же, но теперь управляющую роль для них выполняет не «бумажный» каталог, а компьютерная программа, которая может использоваться как сотрудниками (для добавления, обновления или удаления данных), так и пользователями - клиентами. В результате внедрения КИС мы имеем:
§ Время выполнения операций значительно сократилось. Теперь сотруднику для добавления и поиска данных, достаточно отрыть программу и внести в нее данные или найти необходимые;
§ Время добавления, обновления, удаления данных существенно сокращается при использовании КИС.
Рисунок 1.7 - Диаграмма дерева узлов модели TO-BE
Как видно из рисунка 1.7 количество уровней и узлов существующей модели уменьшилось благодаря автоматизации некоторых процессов.
1. 4 Цели и задачи информационной системы « Учет успеваемости »
В результате анализа существующей ситуации и создания новой модели организации бизнес-процессов, можно сформулировать цель и задачи предмета разработки - «Учет успеваемости».
Преимущества разрабатываемого программного продукта были подробно рассмотрены и проанализированы в разделе 1.2, поэтому мы не будем их повторять.
Задачи информационной системы «Учет успеваемости»:
1) Обеспечить удобный поиск информации (поиск по полному или частичному совпадению);
2) Обеспечить корректный и полный вывод информации о студенте;
3) Обеспечить корректный и полный вывод информации о факультете;
4) Обеспечить удобное редактирование базы данных и корректное её сохранение.
В процессе обследования предметной области была построена и изучена модель AS-IS. На основании модели AS-IS, была построена модель TO-BE, были определены цели и задачи будущего предмета разработки.
2 . Т ехническое задание на предмет разработки
Модель вариантов использования предназначается для определения требований к системе. Она включает в себя актеров, варианты использования и связи между ними. Для отображения этой модели язык UML предлагает использовать диаграммы Use Case (вариант использования) совместно с моделями State Diagram (диаграммы состояний) и Activity Diagram (диаграммы деятельности/активности). Последние используются для конкретизации вариантов использования системы.
2.1 Модель вариантов использования информационной системы «Учет успеваемости»
Модель вариантов использования описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Большинство систем имеет множество категорий пользователей. Поэтому каждая категория пользователей представляется отдельным действующим лицо (актером). Актер -- это любая сущность, взаимодействующая с системой извне.
В данном проекте выделены следующие действующие лица:
Администратор - сотрудник информационной системы, в обязанности которого входит своевременное редактирование базы данных.
Пользователь - любой человек, который может просматривать информацию.
Актеры взаимодействуют с системой с помощью так называемых вариантов использования. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.
Приведем список возможных вариантов использования программного продукта:
2.4 Диаграмма вариантов использования
На диаграмме вариантов использования показывают взаимодействия между всеми действующими лицами и вариантами использования. Диаграмма должна показывать, какие действующие лица инициируют варианты использования, а также должна отображать, когда действующие лица получают информацию от вариантов использования.
Основные взаимодействия между действующими лицами и вариантами использования задаются с помощью связи коммуникации. Задается в виде простой стрелки. Направление стрелки показывает, кто инициирует связь (всегда действующее лицо) и какой вариант использования отправляет информацию внешнему действующему лицу [2].
Диаграмма вариантов использования изображена на рисунке 2.1.
На рисунке 2.2 представлена детализация варианта использования информационной системы «Учет успеваемости».
Рисунок 2.1 - Диаграмма вариантов использования
2.5 Описание вариантов использования
2.5.1 Прецедент « Использование БД »
Назначение: данный вариант использования описывает возможность редактирования данных. Основной поток событий: cистема запрашивает требуемое действие (удаление студента, удаление факультета, изменение данных о студенте, изменение данных о факультете, добавление нового факультета, добавление нового студента).После того, как Администратор указывает действие, выполняется один из подчиненных потоков: удалить студента, удалить факультет, изменить данные о студенте, изменить данные о факультете, добавить новый факультет, добавить нового студента.
-Администратор указывает необходимого студента.
-Система выдает запрос на подтверждение удаления.
-После подтверждения удаления система удаляет из базы данных информацию об студенте.
- Администратор указывает необходимый факультет.
- Система выдает запрос на подтверждение удаления.
- После подтверждения удаления система удаляет из базы данных информацию о факультете.
- Администратор указывает необходимого студента.
- Система дает возможность редактирования.
- После этого Администратор изменяет необходимые поля.
- Администратор указывает необходимый факультет.
- Система дает возможность редактирования.
- После этого Администратор изменяет необходимые поля.
- Система выдает бланк с пустыми полями.
- Администратор заполняет все поля.
- Система выдает бланк с пустыми полями.
- Администратор заполняет все поля.
1) Если данные неверны, то выдается соответствующее сообщение об ошибке и изменений в БД не происходит.
2) Если оператор после изменений нажал кнопку «Отменить изменения», то заново считываются из БД старые данные и новые не сохраняются.
Постсловия.Если изменения в БД прошли успешно, выдается об этом сообщение, в противном случае - сообщение об ошибке.
В ходе работы над частью проекта, представленной в данном разделе выполнено:
- Определение списка действующих лиц с указанием их ролей;
- Определение вариантов использования;
- Построение диаграммы вариантов использования;
- Описание вариантов использования.
3 . М оделирование данных к предмету разработки
Для моделирования данных в данном курсовом проекте в качестве инструментария был выбран CASE-пакет ERwin, наиболее полно отвечающий требованиям проектирования различного типа БД.
3.2 Выбор инструментария, диаграммных техник
Основой для построения моделей данных послужили результаты обследования целевой деятельности с построением модели AS-IS и TO-BE. В качестве инструментария для моделирования данных ERwin.
После выявления отношений между сущностями была построена логическая модель, показанная ниже:
Рисунок 3.3.1 - Модель данных на уровне сущностей
Рисунок 3.3.2 - Модель на уровне определений
Рисунок 3.3.3 - Модель данных на уровне атрибутов
Рисунок 3.3.4 - Модель на уровне первичных ключей
Первым этапом физического проектирования БД является преобразование отношений, созданных на основе логической модели данных, в такую форму, которая может быть реализована в среде целевой СУБД. Для реализации БД данного проекта в качестве целевой СУБД будет выбран Microsoft SQL Server 2000.
Ниже представлена спроектированная физическая модель данных на уровне таблиц и колонок.
Рисунок 3.4.1 - Физическая модель на уровне колонок
В ходе выполнения части курсового проекта, представленной в данном разделе, было выполнено:
-Выделение сущностей и атрибутов модели данных с использованием бизнес-процессов;
- Определение отношений между сущностями;
- Построение логических моделей данных, представленных на различных уровнях;
- Определение в качестве базовой СУБД MS SQL Server 2005, с построением физической модели данных.
4 . Л огическое моделирование предмета разработки
Ниже в разделе представлены результаты дальнейшего развития логической модели ПО, начало создания которой было положено в разделе «Техническое задание на предмет разработки». Разумеется, язык моделирования и инструментария его реализации остались прежними: UML и Rational Rose .
4.2.1 Способы выделения классов анализа
Класс анализа представляет собой абстракцию одного или более классов и/или подсистем в проекте системы. Эта абстракция имеет следующие характеристики:
класс анализа сосредоточен на представлении только функциональных требований (нефункциональные требования рассматриваются на стадиях проектирования и реализации);
класс анализа не обязан поддерживать какие-либо интерфейсы в понятии операций и их сигнатур (поведение должно быть описано в текстовой форме);
классы анализа связаны в основном отношением «ассоциация»;
классы анализа всегда можно отнести к одному из типов: граничный, управляющий или сущность.
4.2.2 Глоссарий предметной области
Глоссарий предназначен для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы. Словарь нужен для того, чтобы обнаружить классы и объекты (или кандидатов на роль классов и объектов) [2].
Для составления глоссария будем использовать классический подход Йордана, в котором кандидаты на роль классов и объектов выбираются из списка осязаемых элементов предметной области (предметы, устройства, события, структуры, роли, места, внешние системы).
В таблице 1 приведены термины глоссария и их значения.
Таблица 1. Глоссарий предметной области
Все пользователи системы имеют возможность просматривать каталог, выполнять поиск, фильтрацию данных.
Сотрудники информационной системы, имеют возможность редактировать БД.
Выбор таких записей из базы данных, которые попадают под заданные пользователем критерии поиска.
Просмотр, добавление, удаление, редактирование, сохранение изменений в записях БД.
1. Совокупность таблиц БД, хранящих информацию о студентах и факультетах.
2. Визуальное представление данных о студентах и факультетах в программе.
Добавление очередной записи в базу данных.
Внесение изменений и дополнений в определенную запись базы данных.
Сохранение внесенных в базу данных изменений.
Выбор таких записей из базы данных, которые попадают под заданные пользователем фамилию или начало фамилии студента.
Выбор таких записей из базы данных, которые попадают под заданную пользователем специальность студента.
User - класс, определяющий пользователя системы, его параметры, роли
LoginForm - класс, представляющий собой форму аутентификации
AdminForm - форма, позволяющая выполнять административные функции, такие как: добавление, редактирование и удаление студентов, факультетов или специальностей
Search - поиск по заданным критериям.
4.3 Поведение предмета разработки
Трактуя все приложение как класс, представим поведение предмета разработки в виде диаграммы состояний (рисунок 4.3.1).
Рисунок 4.3.1- Диаграмма деятельности системы в целом.
Диаграмма состояний описывает возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение предмета разработки как единого целого в течение его жизненного цикла.
4.4 Взаимодействие объектов и экранные формы
4.4.1 Вариант использования « Использование БД »
Класс анализа не обязан поддерживать какие-либо интерфейсы и понятия операций и сигнатур. Вместо этого поведения должно быть описано в текстовом формате в соответствии с особенностями класса (обязанностями).
Классы анализа связаны друг с другом отношением «ассоциация». Направленность ассоциаций не слишком важна в анализе, но существенна в проектировании. Также в процессе анализа могут использоваться отношения «обобщения».
Классы анализа всегда можно отнести к одному из типов: граничный, управляющий или сущность. Эти три стереотипа стандартизированы в UML и используются, чтобы помочь разработчикам различать назначения (действия) различных классов.
В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Это полностью согласуется с принципами объектно-ориентированного анализа и проектирования, когда любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними.
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия: диаграмма последовательности и диаграмма кооперации [3].
4.4.2 Вариант использование «Поиск информации»
Диаграмма последовательности прецедента «Поиск информации» представлена на рисунке 4.4.2.1.
Рисунок 4.4.2. - Диаграмма последовательности прецедента «Поиск информации»
Здесь показано взаимодействие пользователя с интерфейсом и объектами поиска.
На рисунке 4.4.2.3 показана диаграмма кооперации прецедента «Поиск информации».
Рисунок 4.4.2.3 - Диаграмма кооперации прецедента «Поиск информации»
Диаграмма кооперации дублирует диаграмму последовательности. Она выглядит более компактной, но в ней сложнее отследить последовательность действий. На рисунке 4.4.2.4 представлен макет экранной формы страницы поиска. Данный макет разработан в интегрированной среде разработки Borland Delphi 7.
Рисунок 4.4.2.4 - Макет экранной формы для страницы поиска.
4.5. Статическая модель предмета разработки
4.5.1. Диаграмма классов интерфейса предмета разработки
4.5.1 Вариант использования (прецедент) « Поиск информации » - основной поток (подчиненный поток « Поиск информации по ФИО » )
4.5 .1.2 Диаграмма классов к прецеденту « Поиск информации »
Диаграмма последовательности «Поиск информации» - основной поток (подчиненный поток «Поиск информации по ФИО») представлена на рисунке 4.5.1.
Рисунок 4.5.1.2 - Диаграмма последовательности «Поиск информации» - основной поток (подчиненный поток «Поиск информации по ФИО»).
В результате логического моделирования предмета разработки были обследованы и построены следующие диаграммы:
- диаграмма деятельности системы в целом;
- диаграмма деятельности к сервисам предоставляемым администратору и менеджеру системы;
- диаграмма последовательности для описанных прецедентов;
- диаграмма кооперации для описанных прецедентов;
- диаграммы классов для статической модели, описанных прецедентов, клиентской и серверной части проектов.
Так же были спроектированы макеты экранных форм.
5 . Ф изическое моделирование предмета разработки
В качестве инструмента разработки был выбран Borland Delphi 7. Выбранная СУБД - SQL Server 2000.
5.2 Диаграммы последовательности с учётом языка реализации
Диаграмма последовательности прецедента «Поиск информации» показана на рисунке 5.2.1
Рисунок 5.2.1 - Диаграмма последовательности прецедента «Поиск информации»
5.3 Компоненты клиентской части приложения
Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код.
Реализация компонента осуществляется с использованием классов и их взаимодействий, которые отображаются в логическом представлении. В логическом представлении каждый класс реализует, как минимум, один компонент.
Диаграмма компонентов к проекту «Учет успеваемости» приведена на рисунок 5.3..1.
Рисунок 5.3.1 - Диаграмма компонентов серверной части проекта
Здесь показано физическое взаимодействие основных модулей программы.
Диаграмма развертывания применяется для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений -- маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы [3].
Диаграмма развертывания представлена на рисунке 3.6
Рисунок 5.4.1 - Диаграмма развертывания проекта
Здесь представлена фундаментальная структурно-организационная схема программных систем.
В результате физического моделирования предмета разработки была исследована физическая модель проекта и на основании ее были построены диаграммы последовательности ко всем прецедентам (с учетом языка реализации), диаграммы компонентов клиентской и серверной части, а так же диаграмма развертывания проекта.
В данном проекте была создана модель AS-IS. Результаты анализа и улучшения бизнес-процессов были представлены в модели TO-BE. На основе модели TO-BE построена модель данных, проведено как логическое, так и физическое моделирование предмета разработки.
Анализ и проектирование программного обеспечения являются начальными и значительными этапами в жизненном цикле разработки программного продукта. Поэтому очень важно уделить должное внимание этим этапам.
В ходе данной работы были освоены наиболее часто употребляемые на реальных проектах средства автоматизированного проектирования, такие как Rational Rose, BpWin, ErWin, Microsoft Visio. Были изучены возможности, достоинства и недостатки каждой из перечисленных систем. С использованием этих средств был спроектирован программный продукт информационная система «Учет успеваемости». Поставленные в работе цели были выполнены успешно.
1.Коналлен Д. Разработка Web-приложений с использованием UML и его расширения. -- М.: Вильямс, 2001. -- 288 с.: ил.
2.Технология программирования: Моделирование программных систем: Метод. указания и задания к лабораторным работам / Авт.-сост. Л.Ф. Дробушевич. -- Мн.: БГУ, 2003. -- 66 с.
3.Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя: Пер.с англ. -- М.: ДМК, 2000.-- 360 с.: ил.
4.Руководство по программному пакету ERwin. [Режим доступа http://www.emanual.ru/download/www.eManual.ru_510.html]
5.Бугай О.В., Бухвалова И.А., Ковальков А.Т., Разоренов Н.А. Методические указания по выполнению дипломного проекта для студентов специальности Т10.02.00 «Программное обеспечение информационных технологий». Мн., 2003.
Анализ информационной системы "Бурятия.INFO". Построение функциональной модели "Как надо", диаграммы прецедентов, диаграммы последовательности действий, диаграммы классов. Разработка программного приложения в интегрированной среде Intellij IDEA. дипломная работа [1,3 M], добавлен 13.04.2014
Создание контекстной диаграммы информационной системы библиотеки. Основные компоненты и особенности ведения каталогов книг и читателей. Моделирование систем поиска и формирования заказов. Разработка диаграммы дерева узлов и логической модели базы данных. курсовая работа [1,1 M], добавлен 24.06.2013
Краткая характеристика предметной области. Актуальность разработки объектно-ориентированной модели информационной системы для учебной библиотеки. Создание диаграммы вариантов использования, последовательности, кооперативной диаграммы, диаграммы классов. курсовая работа [381,8 K], добавлен 01.06.2009
Построение диаграммы последовательности действий и диаграммы классов при автоматизации процесса выдачи заработной платы. Логическая и физическая реализация базы данных, заполнение таблиц и создание выборок. Мапирование реляционной модели в метамодель. курсовая работа [1,6 M], добавлен 29.11.2011
Сферы применения методологии RAD. Особенности создания программного продукта, предназначенного для редактирования тестов. Рассмотрение моделей жизненного цикла: каскадная, спиральная. Этапы построения начальной контекстной диаграммы. Анализ DFD-диаграммы. курсовая работа [1,9 M], добавлен 19.09.2012
Построение use case диаграммы. Проектирование базы данных. Концептуальная модели 1-уровня (диаграмма последовательности действий). Мапирование реляционной модели в метамодель. Логическая реализация метамодели. Скрипты, заполнение таблиц, создание выборок. курсовая работа [1,4 M], добавлен 28.12.2011
Общая характеристика склада как объекта хозяйственной деятельности. Создание диаграммы прецедентов и последовательности. Построение корпоративной диаграммы сотрудничества. Предназначение диаграммы классов и компонентов. Генерация программного кода C++. курсовая работа [222,0 K], добавлен 23.06.2011
Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д. PPT, PPTX и PDF-файлы представлены только в архивах. Рекомендуем скачать работу .

© 2000 — 2021



Разработка информационной системы в контексте AS-IS и TO-BE курсовая работа. Программирование, компьютеры и кибернетика.
Контрольная Работа По Алгебре 7 Класс Мартышова
Дипломная работа: Сандро Ботичелли
Курсовая работа по теме Инвентаризация, порядок ее проведения и отражение ее результатов в учете
Дипломная работа по теме Применение соляно-кислотной обработки призабойных зон скважин
Реферат: Північно-Кавказький економічний район Росії
Дипломная работа по теме Повышение эффективности использования трудовых ресурсов в условиях рынка
Курсовая работа по теме Разработка программы обработки массива данных с построением диаграммы (предметная область - 'Садовод')
Я Стою В Вестибюле Редакции Сочинение Егэ
Закон Сохранения Механической Энергии Лабораторная Работа
Реферат: Империя. Российская империя. Скачать бесплатно и без регистрации
Курсовая работа по теме Техническое обслуживание и ремонт автомобильного транспорта
Доклад: Гребля
Реферат: "Постиндустриальное общество" - тупиковая ветвь социального развития. Скачать бесплатно и без регистрации
Сочинение по теме Осмислення сутності людського буття в повісті Ольги Кобилянської "Земля"
Реферат по теме Социальная стратификация и мобильность
Требования К Эссе По Госту
Методы Продвижения Товаров На Продовольственном Рынке Реферат
Реферат по теме Математические методы планирования экспериментов
Контрольная работа по теме Развитие личности в подростковом возрасте
Сочинение Про Святых
Социально-политическая сатира в английских главах Дон-Жуана Д.Г. Байрона - Литература реферат
Коммерческие организации - Государство и право контрольная работа
Пропедевтика нарушений письма у старших дошкольников с общим недоразвитием речи - Педагогика дипломная работа