МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Кафедра "Математическое обеспечение и применение эвм" Отчет по учебной практике

Выполнил: студент гр. 11ВП1

Ручкин А.Д.

Проверил: к.т.н., доцент

Гурьянов Л.В.

Денисова И.Ю.

Пенза 2012 Содержание

1. Раздел…………………………………………………………………………………………………………………………….3

   1. Введение. Информационная структура предприятия …………………………………………..3

   2. Раздел анализа………………………………………………………………………………………………………….4

   3. Раздел проектирования…………………………………………………………………………………………..7

   4. Раздел реализации…………………………………………………………………………………………………..9

   5. Раздел тестирования………………………………………………………………………………………………10

   6. Заключение …………………………………………………………………………………………………………….10

   7. Список использованных источников и приложения…………………………………………….11

2. Раздел…………………………………………………………………………………………………………………………..12

   1. Задания…………………………………………………………………………………………………………………….12

   2. Листинг…………………………………………………………………………………………………………………….13

      1. Одномерные массивы………………………………………………………………………………….13

      2. Двумерные массивы…………………………………………………………………………………....18

I раздел.

1.1 Введение. Информационная структура предприятия

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

Рисунок 4.1 – Информационная структура кафедры

1.2 Раздел анализа

Раздел анализа должен содержать анализ предметной области и анализ требований.

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

• определение циклического списка (краткое описание и графическое изображение);

• структуру приложения в Delphi (отсюда следует архитектура создаваемого приложения);

• краткую характеристику графических средств среды разработки программных средств (в случае «графического» приложения).

Анализ требований целесообразно разделить на следующие подразделы:

• требования к интерфейсу пользователя;

• требования к структуре данных;

• требования к программным средствам.

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

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

• файла;

• информационной части элемента списка;

• данных об объекте разработки (сведения о студентах в случае разработки информационной системы «Учебная группа»);

• классов приложения (рисунок 4.2)

Рисунок 4.2 – Иерархия классов для построения геометрической фигуры

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

При разработке диаграммы вариантов использования следует обратить особое внимание на отношения вариантов – Use Case (рисунок 4.3).

Рисунок 4.3 – Пример диаграммы вариантов использования

На данном рисунке Вариант1 является базовым вариантом использования. При этом один или много пользователей одновременно могут использовать данный вариант – на диаграмме отношение: 1.. – 1.

Между элементами Use Case определены отношение обобщения и две разновидности отношения зависимости – включения и расширения (рисунок 4.4).

Рисунок 4.4 – Отношения элементов диаграммы использования

Отношение обобщения (рисунок 4.4a) фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы.

Отношение включения – «include/uses» (рисунки 4.3, 4.4b) – между элементами Use Case означает, что базовый элемент Use Case явно включает поведение другого элемента Use Case в точке, которая определена в базе. Включаемый элемент Use Case никогда не используется самостоятельно – его конкретизация может быть только частью другого, большего элемента Use Case. Отношение включения является примером отношения делегации. При этом в отдельное место (включаемый элемент Use Case) помещается определенный набор обязанностей системы. Далее остальные части системы могут агрегировать в себя эти обязанности (при необходимости)

Отношение расширения – «extended/extends»(рисунки 4.3, 4.4c) – между элементами Use Case означает, что базовый элемент Use Case неявно включает поведение другого элемента Use Case в точке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках – точках расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязательного поведения.

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