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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


дипломная работа Построитель графиков на C#

Информация:

Тип работы: дипломная работа. Добавлен: 03.11.2012. Сдан: 2011. Страниц: 30. Уникальность по antiplagiat.ru: < 30%

Описание (план):


АННОТАЦИЯ 

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

СОДЕРЖАНИЕ
    Лист
ПОСТАНОВКА  ЗАДАЧИ                                                                             6                                                        
    ВВЕДЕНИЕ                                                                                                      7 
    1. ОБЩАЯ ЧАСТЬ                                                                                           8           
    1.1. Обзор состояния вопроса                                                                         8              
    1.2. Основные этапы разработки программных продуктов                         11    
    1.2.1. Концептуализация                                                                                 12   
    1.2.2. Анализ разрабатываемого приложения                                               14                                                                           
    1.2.3. Проектирование разрабатываемого приложения                               16                                                      
    1.2.4. Эволюция приложения                                                                        17                         
    1.2.5. Сопровождение приложения                                                              19
1.3. Технологии разработки программных продуктов                               20     
     1.3.1. Объектно-ориентированное программирование                               20
    1.3.2. Технология .NET                                                                                    21     
    1.3.2.1. Компоненты .NET                                                                              23
    1.3.2.2. Двоичный стандарт компонентов                                                  25                         
    2. СПЕЦИАЛЬНАЯ ЧАСТЬ                                                                          27                
    2.1. Разработка программы                                                                          27    
    2.1.1. Анализ разрабатываемого приложения                                             27                                                         
    2.1.2. Проектирование  разрабатываемого приложения                            34                                                         
    2.2. Языки программирования                                                                        35    
    2.3. Выбор языка программирования                                                            37                                            
     2.4. Применение графиков в решении уравнений                                       38     
   3. ЭКОНОМИЧЕСКАЯ  ЧАСТЬ                                                                       41
   3.1. Исходные  данные                                                                                       41
   3.2. Применяемые формулы с расшифровкой условных обозначений        42
   3.3. Расчет  полной себестоимости разработки  программного                              
    продукта  по базовому варианту                                                                      45
   3.4. Расчет  полной себестоимости разработки  программного                     
    продукта по эксплуатационному варианту                                                    46
   3.5. Расчет полной себестоимости разработки программного                     
    продукта  по варианту разработки                                                                   57
     3.6. Расчет экономической эффективности внедрения                                 
   программного продукта                                                                                   48
     3.7. Социально-психологические аспекты                                                     
   использования разработки                                                                       50
     4. ЭКСПЛУАТАЦИЯ ТЕХНИЧЕСКИХ И ПРОГРАММНЫХ
      СРЕДСТВ                                                                                                          51
     4.1. Эксплуатация технических средств                                                         51
   4.2. Эксплуатация  разработанной программы                                               52
    ЗАКЛЮЧЕНИЕ                                                                                                54
    СПИСОК ЛИТЕРАТУРЫ                                                                               55
    ПРИЛОЖЕНИЕ                                                                                                56 
     
     
     
     
     
     
     
     
     
     
     

    ПОСТАНОВКА  ЗАДАЧИ 

      В процессе дипломного проектирования передо мной были поставлены следующие задачи:
1) Ознакомиться с технологиями разработки программных продуктов (Объектно-ориентированное программирование, технология .NET);
2) Разработка программы для построения и исследования математических функций;
3) Программа должны позволять производить следующие функции:
        а) Масштабировать график;
           б) Вращать и перемещать график;
           в) Задавать интервалы и шаг графика;     
           г) Выводить свойства графика на экран;
    4) Получить результат работы программы;
    5) Выполнить экономический расчет; 
     
     
     
     
     
     
     
     
     
     
     
     

ВВЕДЕНИЕ 

      Мир компьютерных и информационных технологий без преувеличения можно назвать  наиболее динамичной областью современных  знаний. Практически каждый год появляются новые модели процессоров и комплектующих, новые версии операционных систем и программного обеспечения. Все это происходит на фоне постоянного усложнения не только отдельных физических и программных компонентов, но и лежащих в их основе концепций и идей. Появилась надобность создавать все более большие сложные программы. Структурный подход по созданию программ начал устаревать. На смену ему пришло объектно-ориентированное программирование(ООП), которое внесло новую методологию в построении программ. С помощью этой методологии стало проще создавать большие программы. У ООП также очень много плюсов, которые описаны ниже. Далее создавалось много различных технологий опять же таки с целью упрощения написания программ и которые были основаны на принципах ООП (MFC, ATL, OLE, COM/DCOM, .NET Framework и много других технологий). Также новые технологии программирования давали новые возможности такие как запуск программы на разных (архитектурно) процессорах и т.д. (некоторые другие возможности описаны ниже).  
 
 
 
 
 
 

                            
               1. ОБЩАЯ ЧАСТЬ 

         1.1. Обзор состояния вопроса 

      Проект  реализован под платформу .NET, его компоненты могут быть использованы в других разработках на любых языках программирования, совместимых с данной технологией. Программа способна работать на любых платформах Windows (включая мобильные).
      Графическая среда предназначена для построения графиков линейных, квадратичных, кубических, степенных, тригонометрических функций, функций заданных в параметрическом виде, также она способна отображать график в разном масштабе, передвигать центр координат, изменять точку наблюдения, размещать несколько графиков на одном рисунке, изменять интервал и шаг интервала графика. Можно изменять цвет графика, координатных осей, использовать виртуальное освещение в функциях вида z=f(x,y) для более выраженного графиком рельефа функции. Также программа способна исследовать функцию на четность/нечетность, определять область значений и область определения функции на различных промежутках. Полученное изображение функции можно сохранить в файл. Графическая часть проекта использует возможности GDI+ MS Windows (Graphic Device Interface – интерфейс графических устройств). Это подсистема Windows, предназначенная для вывода графических изображений на экран и на принтер.
      3D-графика – один из немногих каналов передачи информации, которые сознание студента не блокирует автоматически. С восприятием и обработкой визуальной информации непосредственно связано 20% мозга человека. Благодаря зрению мы получаем по разным оценкам от 70 до 90% сведений об окружающем мире.
      До  половины студентов испытывают затруднения при детальном построении графиков опорных тригонометрических функций. Более половины студентов испытывают значительные затруднения при выборе областей
определения и изменения, построении графиков обратных тригонометрических функций. Применение разработанного приложения при решении задач позволяет наглядно увидеть все этапы решения в динамике, значительно экономит время, затраченное на разбор заданий, а также позволило бы довести знания и умения студентов до высокого уровня. Также программа облегчает изучение графиков функций, обеспечивает наглядность и простоту в использовании. Для преподавателей программа может служить хорошим средством для подготовки к занятиям, для создания наглядных пособий и т. д.
      Визуализация  позволяет представить большой  объем данных в удобной для  анализа форме и широко используется при обработке результатов различных  измерений, анализа сложных процессов. Графический способ является наиболее эффективным при решении некоторых неравенств и уравнений, что позволяет экономить время при решении.
      Применение. Графическая среда позволяет решать уравнения с одной неизвестной вида f(x)=0. Необходимо построить график функции
y=3*x-x -2, абсциссы точек пересечения графика с осью Ox будут корнями данного уравнения. На рис.1.1 видно, что корнями уравнения 3*x-x -2=0 являются x =-2 и x =1.
     

Рис.1.1 Графическое решение уравнения 3*x-x
-2=0
 

        Также графическая среда позволяет решать уравнения вида f(x )=f(x ). Необходимо найти корни уравнения x -2=x-2. Для этого строим сначала один график, потом другой и точки пересечения графиков будут корнями данного уравнения. На рис.1.2 видно, что корнями уравнения x -2=x-2 являются x =0 и x =1.

   Рис.1.2 Графическое решение уравнения x
-2=x-2

      1.2. Основные этапы разработки программных продуктов 

      До  того, как начать программирование классов, их свойств и методов, необходимо определить, чем же являются сами эти классы. Более того, нужно дать ответы на такие вопросы, как: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами.
      Эта совокупность задач не столько связана  с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа.
      Разделение  процесса разработки сложных программных  приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования.
      Как показано на рис.1.3, разработка программных продуктов обычно включает следующие этапы жизненного цикла:
    Выявление сущности требований к программному продукту (концептуализация).
    Разработка модели требуемого поведения системы (анализ).
    Создание архитектуры для реализации (проектирование).
    Итеративное выполнение реализации (эволюция).
    Управление эволюцией продукта в ходе эксплуатации (сопровождение).

                                     
           Рис.1.3 Процесс проектирования 

      Основная  философия разработки программных продуктов состоит в постепенном развитии. Как его определяет Вонк, "при разработке методом [2]
последовательного развития, система выстраивается  шаг за шагом, причем каждая новая  версия содержит функциональность предыдущей, плюс новые функции". Этот подход чрезвычайно хорошо сочетается с объектно-ориентированной парадигмой.
        
      1.2.1. Концептуализация 

      Концептуализация - определение понятий, отношений и механизмов управления, необходимых для описания решения задач в избранной предметной области.
      Концептуализация  должна установить основные требования к системе. Для каждой принципиально новой части программы или даже для нового применения существующей системы найдется такой момент, когда в голову разработчика, архитектора, аналитика или конечного пользователя западет идея о новом приложении. Это может быть новое деловое предприятие, дополнительное изделие на поточной линии или, например, новая функция в существующей программной системе. Цель концептуализации не в том, чтобы полностью определить идею, а в том, чтобы выработать взгляд на нее и мысленно проверить ее.
      Первичными  продуктами концептуализации являются прототипы системы. Определенно, каждой существенно новой программной  системе необходим некоторый  черновой прототип, пусть и выполненный "на скорую руку". Такие прототипы не полны по самой своей природе и разработаны лишь схематически. Однако, нужно сохранять интересные (пусть, возможно, и отвергнутые) прототипы, так как этим организация поддерживает корпоративную память о первоначальном замысле и сохраняет связь с исходными предположениями. При проектировании этот архив дает незаменимый материал для экспериментирования, к которому аналитики и архитекторы могут возвращаться, когда хотят опробовать новые идеи.
      Концептуализация  по самой своей природе - творческая деятельность, и, следовательно, она не должна быть скована жесткими правилами разработки. Возможно, самое важное - создать структуру, которая обеспечивала бы достаточные ресурсы для возникновения и исследования новых идей. Новые идеи могут исходить из самых различных источников: конечных пользователей, групп пользователей, разработчиков, аналитиков, проектировщиков, распространителей и т.д. Важно вести регистрацию этих идей, располагая их по приоритетам и распределяя ограниченные ресурсы так, чтобы исследовать самые многообещающие из них.
      Концептуализация  не содержит ничего специфически объектно-ориентированного. Каждая программная парадигма должна предусматривать опробование концепций. Однако, как часто бывает, разработка прототипов обычно происходит быстрее в тех случаях, когда на лицо зрелая объектно-ориентированная среда.
    
      1.2.2. Анализ разрабатываемого приложения 

      На  этапе анализа предметной области  осуществляется определение функций, которая должна выполнять разрабатываемая программа. Результатом является некая концептуальная схема, содержащая описание основных компонентов и тех функций, которые они должны выполнять.
          Как утверждает Меллор, “цель анализа – дать описание задачи [2]. Описание должно быть полным, непротиворечивым, пригодным для чтения и обозрения всеми заинтересованными сторонами, реально проверяемым.” Говоря простым языком, цель анализа – представить модель поведения системы.
      Надо  подчеркнуть, что анализ сосредоточен не на форме, а на поведении. На этой стадии неуместно заниматься проектированием классов. Анализ должен объяснять, что делает система, а не то, как она это делает. Любое, сделанное на стадии анализа (вопреки этому правилу) утверждение о том "как", может считаться полезным только для демонстрации поведения системы, а не как проверяемое требование к ее проектированию. В этом отношении цели анализа и проектирования весьма различны. В анализе мы ищем модель мира, выявляя абстракции (т.е. классы и объекты их роли, обязанности и взаимодействия), существенные с точки зрения клиента (pис.1.4). В проектировании мы изобретаем искусственные персонажи, которые реализуют поведение, требуемое анализом. В этом смысле, анализ - это деятельность, которая сводит вместе пользователей и разработчиков системы, объединяя их написанием общего словаря предметной области. Нестоит стремиться к исчерпывающему пониманию поведения системы. Также нестоит делать полный анализ до начала проектирования т.к. это не только невозможно, но и нежелательно. Процесс построение системы поднимает вопросы о ее поведении, на которые нельзя дать гарантированный ответ, занимаясь только анализом. Достаточно выполнить анализ всех первичных элементов поведения  

         

           Рис.1.4 Абстракция фокусируется на существенных с точки зрения   наблюдателя характеристиках объекта. 

системы и некоторого количества вторичных, добавляемых для гарантии того, что никакие существенные шаблоны поведения не пропущены.
      ДеШампо считает, что результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов [2]. На этом этапе применяют диаграмму классов для иллюстрации их поведения и взаимодействия между ними.
      Степень совершенства анализа будет измеряться, в частности, его полнотой и простотой.  
 
 

      1.2.3. Проектирование разрабатываемого приложения 

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

      1.2.4. Эволюция приложения 

      Цель  эволюции – наращивать и изменять реализацию, последовательно совершенствуя ее, чтобы в конечном счете создать готовую систему.
      Эволюция  архитектуры в значительной степени  состоит в попытке удовлетворить нескольким взаимоисключающим требованиям ко времени, памяти и т.д. - одно всегда ограничивает другое. Например, если критичен вес компьютера (как при проектировании космических систем), то должен быть учтен вес отдельного чипа памяти. В свою очередь количество памяти, допустимое по весу, ограничивает размер программы, которая может быть загружена. Ослабьте любое ограничение, и станет возможным альтернативное решение; усильте ограничение, и некоторые решения отпадут. Эволюция при реализации программного проекта лучше чем монолитный набор приемов помогает определить, какие ограничения существенны, а какими можно пренебречь. По этой причине эволюционная разработка сосредоточена прежде всего на функциональности и только затем - на локальной эффективности.
      Таким образом, эволюция - это и есть процесс  разработки программы. Как пишет  Андерт, проектирование "есть время  новшеств, усовершенствований, и неограниченной свободы изменять программный 
код, чтобы  достигнуть целей [2]. Производство - управляемый методичный процесс подъема качества изделия к надлежащему уровню".
        Пейдж-Джонс называет ряд преимуществ такой поступательной [2] разработки:
    Обеспечивается обратная связь с пользователями, когда это больше   всего необходимо, полезно и значимо.
    Пользователи получают несколько черновых версий системы для сглаживания перехода от старой системы к новой.
    Менее вероятно, что проект будет снят с финансирования, если он   вдруг выбился из графика.
    Главные интерфейсы системы тестируются в первую очередь и   наиболее часто.
    Более равномерно распределяются ресурсы на тестирование.
    Реализаторы могут быстрее увидеть первые результаты работы системы, что их морально поддерживает.
    Если сроки исполнения сжатые, то можно приступить к написанию и отладке программ до завершения проектирования.
      Основным  результатом эволюции является серия  исполнимых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели. Вторичным продуктом следует признать выявление поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа темных углов системы.
      При эволюции системы на практике ожидаются  следующие типы изменений:
    Добавление нового класса или нового взаимодействия между классами.
    Изменение реализации класса.
    Изменение представления класса.
    Реорганизация структуры классов.
    Изменение интерфейса класса.
      1.2.5. Сопровождение приложения 

      Сопровождение программ — это работы, связанные с обслуживанием программ процессе их эксплуатации.
     Цель  сопровождения – это деятельность по управлению эволюцией продукта в ходе его эксплуатации. Она в значительной степени продолжает предыдущие этапы разработки, за исключением того, что вносит меньше архитектурных новшеств. Вместо этого делаются более локализованные изменения, возникающие по мере учета новых требований и исправления старых ошибок.
      Леман и Белади сделали несколько неоспоримых  наблюдений, рассматривая процесс "созревания" уже внедренной программной системы [2]:
    "Эксплуатируемая программа должна непрерывно изменяться; в противном случае она будет становиться все менее и менее полезной (закон непрерывного изменения).
    Когда эволюционирующая программа изменяется, ее структура становится более сложной, если не прилагаются активные усилия, чтобы этого избежать (закон возрастающей сложности)" .
      Сопровождение связано также с управлением  списком новых заданий. Кроме тех требований, которые по каким-либо причинам не были учтены, вероятно, уже вскоре после выпуска работающей системы, разработчики и конечные пользователи обменяются множеством пожеланий и предложений, которые они хотели бы увидеть воплощенными в следующих версиях системы. Заметим, что когда с системой поработает больше пользователей, выявятся новые ошибки и неожиданные методы использования, которых не смогли предвидеть контролеры качества. В список заносятся обнаруженные дефекты и новые требования, которые будут учтены при планировании новых релизов в соответствии с их приоритетом.
      Сопровождение несколько отличается от эволюции системы. Если первоначальная архитектура удалась, добавление новых функций и изменение существующего поведения происходят естественным образом.
      Кроме обычных действий по эволюции, при  сопровождении нужно определить приоритеты задач, собранных в список замечаний и предложений. Типичный порядок действий таков:
    Упорядочить по приоритетам предложения о крупных изменениях и сообщения об ошибках, связанных с системными проблемами, и оценить стоимость переработки.
    Составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции.
    Если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения.
    Приступить к разработке следующего эволюционного релиза программы.
 
      1.3. Технологии разработки программных продуктов 

      1.3.1. Объектно-ориентированное программирование 

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

      1.3.2. Технология .NET 

      NET - это совершенно новая модель(платформа) для создания приложений под Windows (а в будущем, видимо, и под другими операционными системами). Она представляет собой высокопроизводительную многоязыковую среду, которая позволяет интегрировать существующие приложения с приложениями следующего поколения.
      Перечисление  основных возможностей .NET:
       1)  Полные возможности взаимодействия с существующим кодом.
       2)  Полное и абсолютное межъязыковое взаимодействие.
  3) Общая среда выполнения для любых приложений .NET, вне зависимости от того, на каких языках они были созданы. Один из важных моментов при этом - то, что для всех языков используется один и тот же набор встроенных типов данных.
  4)  Библиотека базовых классов, которая  обеспечивает сокрытие всех сложностей, связанных с непосредственным использованием вызовов API, и предлагает целостную объектную модель для всех языков программирования, поддерживающих .NET.
      .NET Framework является одной из самых совершенных на сегодня платформ разработки ПО. Она предоставляет практически неограниченные возможности для реализации любых задач.
      .NET Framework состоит из трех основных частей – общеязыковой среды выполнения, общая системы типов и общеязыковой спецификации. Главная роль общеязыковой среды выполнения заключается в том, чтобы обнаруживать и загружать типы .NET и производить управление ими в соответствии с пользовательскими командами. Также она берет на себя всю низкоуровневую работу - например, автоматическое управление памятью, межъязыковым взаимодействием, развертывание (с отслеживанием версий) различных двоичных библиотек. Общая системы типов полностью описывает все типы данных, поддерживаемые средой выполнения, определяет, как одни типы данных могут взаимодействовать с другими и как они будут представлены в формате метаданных .NET. Общеязыковая спецификация - это набор правил, определяющих подмножество общих типов данных, в отношении которых гарантируется, что они безопасны при использовании во всех языках .NET. Если, например, создать типы .NET с использованием только тех возможностей, которые совместимы с общеязыковой спецификацией, то тем самым это сделает их пригодными для любых языков .NET.
      Помимо  выше перечисленных спецификаций платформа .NET предоставляет в распоряжение также библиотеку базовых классов, доступную из любого языка программирования .NET. Библиотека базовых классов не только прячет обычные низкоуровневые операции, такие как файловый ввод-вывод, обработка графики и взаимодействие с оборудованием компьютера, но и обеспечивает поддержку большого количества служб, используемых в современных приложениях.
      С концептуальной точки зрения отношения  между уровнем среды выполнения и библиотекой базовых классов .NET выглядят так, как показано на рис.1.5.
     
          Рис.1.5 Отношения между средой выполнения и  
    библиотекой базовых классов .NET
     

      1.3.2.1. Компоненты .NET 

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

    Рис.1.6 Разбиение монолитного приложения (слева) на компоненты(справа) 

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


    Рис.1.7 Замена компонента D на новую, улучшенную версию 

      Для того, чтобы разбить монолитное приложение на компоненты, необходим мощный инструмент. Этот Инструмент называется .NET.
Более пяти лет назад .NET была разработана в Microsoft, чтобы сделать программный продукты фирмы более гибкими, динамичными и настраиваемыми.
      Практически все продаваемые сегодня приложения Microsoft используют .NET.  

      1.3.2.2. Двоичный стандарт компонентов 

      Одной из наиболее важных черт .NET является его способность предоставлять двоичный стандарт для программных компонентов. Этот двоичный стандарт обеспечивает средства, с помощью которых объекты и компоненты, разработанные на разных языках программирования разными поставщиками и работающие в различных операционных системах, могут взаимодействовать без каких-либо изменений в двоичном (исполняемом) коде. Это является основным достижением создателей .NET и отвечает насущным потребностям сообщества разработчиков программ.
      Многоразовое  использование программного обеспечения  является одной из первоочередных задач  при его разработке и обеспечивается составляющими его модулями, которые  должны работать в разнообразных  средах. Обычно программное обеспечение разрабатывается с использованием определенного языка программирования, например C++, и может эффективно применяться только в том случае, если другие разработчики компонентов также применяют C++.
      Например, если мы разрабатываем С++ - класс, предназначенный для манипулирования с данными, то необходимым условием его использования в других приложениях является их разработка на языке C++. Только С++ - компиляторы могут распознать С++ - классы.
Фактически, поскольку средства C++ не поддерживают никакого стандартного способа адаптации вызовов С++ - функций к новой программной среде, использование программного обеспечения в этой новой среде требует применения такого же (или аналогичного) инструментального средства для его обработки. Другими словами, использование класса в другой операционной среде требует обязательного переноса в эту среду исходного текста программы данного класса.
      Применение  двоичного кода позволяет разработчику создавать программные компоненты, которые могут применяться без  использования языков, средств и систем программирования, а только с помощью двоичных компонентов (например, DLL- или ЕХЕ - файлов). Эта возможность является для разработчиков очень привлекательной. Ведь теперь они могут выбирать наиболее удобный для себя язык и средство разработки компонентов, не заботясь о языке и средствах, которые будет использовать другой разработчик. 
 
 
 
 

2. СПЕЦИАЛЬНАЯ ЧАСТЬ 

      2.1. Разработка программы 

      2.1.1. Анализ разрабатываемого приложения 

      Имеет смысл создать два простых класса для работы с векторами и матрицами(class Vector и class Matrix). Для этого надо провести небольшой анализ, в процессе которого надо рассмотреть роли и обязанности данных абстракций (абстракция – это существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя). Класс Vector ответственен за операциями с векторами (сложение, вычитание, умножение, деление). Класс Matrix ответственен за операциями с матрицами (двумерные таблицы чисел). Также он ответственен за операции сложение, умножение, вращения вокруг осей X, Y, Z и операцию переноса. Определив поведение данной абстракции с точки зрения пользователя, нужно четко разделить интерфейс класса и его реализацию. Основная идея состоит в том, чтобы сначала определить внешний интерфейс каждого класса, не задумываясь при этом об особенностях его внутреннего строения.
      Таким образом абстракция классов Vector и Matrix выглядит как показано на рис.2.1:
   Имя:
          Vector
    Ответственность:
           Выполнение операций с векторами.
    Операции:
          operator +  Сложение 
          operator - Вычитание
          operator * Умножение 
          operator / Деление
    Атрибуты:
          x, y, z координаты вектора 

   Имя:
          Matrix
    Ответственность:
           Выполнение операций  с матрицами.
    Операции:
          operator + Сложение 
          operator * Умножение 
          RotateX поворот вокруг оси X
          RotateY  поворот вокруг оси Y
          RotateZ  поворот вокруг оси Z
    Атрибуты:
          X[4][4] таблица чисел 

    Рис.2.1 Абстракция классов Vector и Matrix 

      Введенную функцию необходимо считать с  элемента управления TextBox в строковую переменную. И так как необходимо строковое выражение преобразовать в алгебраическое выражение выделяется новая абстракция. Для этого создается новый класс, который мог бы реализовать данное преобразование. Экземпляр класса должен найти в строке числа и преобразовать их в вещественный тип, также он должен все неизвестные (х или x и y) преобразовать в соответствующие числа из заданного пользователем интервала. Далее он должен распознавать следующие знаки: ‘( )’,  ‘*’,  ‘/’,  ‘+’,  ‘-’,  ‘^’(степень),’| |’(модуль). Также должен выявлять sin(…), cos(…), tg(…), ctg(…).
      Таким образом абстракция класса SintaxAnalyser выглядит как показано на рис.2.2:
    Имя:
          TextAnalyser
    Ответственность:
           Преобразование текстового выражения в алгебраический вид и вычисление полученного выражения
    Операции:
          XorY определяет указывает ли в текущей индекс строки на X или Y и если указывает, то функция возвращает соответствующее значение число, в противном случае код ошибки.
          Number  определяет указывает ли текущей индекс строки на число и если указывает, то функция возвращает это число, в противном случае код ошибки.
      FindMulDel осуществляет поиск  первого знака  ‘*’ или ’/’
      FindSumSub осуществляет поиск  первого знака  ‘+’ или ’-’
      FindBrackets осуществляет поиск  скобок в выражении
      CalculateMulDel осуществляет умножение  и деление
      CalculateSumSub осуществляет сложение  и вычитание
      Function высчитывает все выражение полностью
      Рис.2.2 Абстракция класса SintaxAnalyser 

      Следует создать класс для моделирования  виртуальной камеры. Камера задается с помощью положения в пространстве и углов поворота, задающих ориентацию. Для камеры необходимо задать расстояние до объекта (графика), а также плоскость определенной ширины и высоты, представляющее конечное изображение, которое будет выведено на экран на определенном этапе и указать размеры экрана, представляющее окно растеризации. Все эти данные должны учитываться в модели камеры, поскольку они определяют видимое пространство, прилегающее к камере и задающее свойства.
      Таким образом абстракция класса Camera выглядит как показано на рис.2.3:
   Имя:
          Camera
    Ответственность:
           Для того, чтобы  “увидеть” график.
    Операции:
      InitCamera  инициализируются параметры камеры
      BuildCamera создание матрицы  вида графика и  осей 

      Рис.2.3 Абстракция класса Camera 

      Следует создать класс, который реализовал бы возможность вычисления координат заданной функции. Также этот класс должен отвечать за хранение и преобразования локальных координат в координаты экрана. Он должен хранить следующие характеристики графика: положение в пространстве, максимальное и текущее количество координат, начало, конец и шаг интервала, масштаб графика. Также этот класс должен иметь объект Axes и Camera. Под преобразованием координат имеется ввиду изменение координат врезультате поворотов, вращении, переносов в пространстве, масштабировании. Для описании формы графических объектов, задания расположения объектов в пространстве и их проекций на экран дисплея используются различные системы координат(СК). Локальная СК  представляет собой координата объекта в своей локальной СК. Т.е. центр объекта находится в начале координат. Также в этой СК осуществляется повороты объекта. Мировая СК это реальные координаты объекта в пространстве. В этой СК осуществляется перемещение и масштабирование объектов. Видовая СК(координаты камеры) нужна для того чтобы увидеть объект в мировых координатах. Экранная СК нужны для того чтобы спроецировать объекты на экран.
      Таким образом абстракция класса Object выглядит как на рис.2.4 (cм. Приложение):
   Имя:
          Object
    Ответственность:
           Вычисление локальных и экранных координат.
    Операции:
          Calculate2D вычисление координат функции от одной неизвестной
          Calculate3D вычисление координат функции от двух неизвестных   
          InitGraph  инициализация графика
          Build_XYZ_Rotation  создание матрицы поворота графика и осей
      TransformGraph преобразование координат  для поворота графика
      Local_To_World_Object  преобразование координат в мировые координаты
      World_To_Camera_Object   преобразование координат в координаты камеры
      Camera_To_Screen_Object  преобразование координат в координаты экрана
      MainGraph выполняет полное преобразования
    Атрибуты:
          num_vertices  количество вершин
      world_pos положение графика  в мировой СК
      vlist_local  локальные координаты графика
      vlist_trans  преобразованные  координаты графика
      begin, end, step начало, конец и шаг интервала
      scale масштаб графика 

      Рис.2.4 Абстракция класса Object 

  Для вычисления координат осей координат с метками, с названиями осей, следует создать следующий класс Axes. Этот класс должен иметь следующую функциональность: координатные оси должны вращаться вместе с графиком функции, метки на координатных осях должны масштабироваться вместе с графиком функции. Также он должен уметь вычислять координаты координатной сетки. 
      Таким образом абстракция класса Axes выглядит как на рис.2.5:
   Имя:
          Axes
    Ответственность:
           Вычисления координат  осей координат.
    Операции:
          InitLoopAxisX вычисление вычисление координат меток на оси X при повороте
        InitLoopAxisY вычисление вычисление координат меток на оси Y при повороте
      InitLoopAxisZ вычисление вычисление координат меток на оси Z при повороте
      ChangeScaleLoopAxis вычисление координат меток при масштабировании координатных осей 

      Рис.2.5 Абстракция класса Axes 

      Для определения свойств графика следует создать класс GraphicProperty. Этот класс будет отвечать определение таких свойств как четность/нечетность функции, область определения и область значения функции.
      Таким образом абстракция класса GraphicProperty выглядит как на рис.2.6: 

   Имя:
          GraphicProperty
    Ответственность:
           Определения свойств графика.
    Операции:
          CheckedParity проверка на четность/нечетность функции
        Range определение области значения функции
      Domain_of_function определение области определения функции
      Рис.2.6 Абстракция класса GraphicProperty 

      2.1.2. Проектирование разрабатываемого приложения 

      На  этапе проектирования нужно четко  определить архитектуру проекта. Это даст стабильный фундамент, на основе которого будут строиться функциональные части системы.
      В разделе анализ выявлена несколько абстракций Vector и Matrix, которые отвечают за операции по вычислению координат. Для вывода графика на экран создан класс Object. Этот класс будет наделен такими методами как вычисление, преобразование координат и другими вспомогательными методами для вывода графика на экран.
      Далее создается класс для работы с камерой. Этот класс будет отвечать за преобразование мировых координат в видовые. Также в его обязанности входит присвоить начальные значения параметрам камеры.
      Класс SintaxAnalyser создан для преобразования тестового выражения в алгебраическое и вычислении этого алгебраического выражения
      Ниже  на рис.2.7 приведена диаграмма структуры классов программы построения графиков функций.  

     

    Рис.2.7 Диаграмма структуры классов программы построения графиков функций 

    2.2. Языки программирования 

      В настоящее время насчитывается  более двух тысяч языков
программирования  высокого уровня. Большинство этих языков возникло исходя из конкретных требований некоторой предметной области. Каждый новый язык позволял переходить ко все более и более сложным задачам. На каждом новом приложении разработчики языков что-то открывали для себя и изменяли свои представления о существенном и несущественном в языке. На развитие языков программирования значительное влияние оказали достижения теории вычислении, которые привели к формальному пониманию семантики операторов, модулей, абстрактных типов данных и процедур.
           Язык программирования служит трем целям:
    это инструмент проектирования;
    это средство человеческого восприятия;
    это средство управления компьютером;
           
      Рис.2.8 демонстрирует генеалогию пяти наиболее влиятельных и популярных объектных или объектно-ориентированных языков программирования: Smalltalk. Object Pascal, C++, CLOS и Ada.
      Язык  программирования C++ был разработан Бьерном Страуструпом, сотрудником AT&T Bell Laboratories. Непосредственным предшественником C++ является С with Classes, созданный тем  же автором в 1980 году. Язык С with Classes, в свою очередь, был создан под сильным влиянием С и Simula. C++ - это в значительной степени надстройка над С. В определенном смысле можно назвать C++ улучшенным С, тем С, который обеспечивает контроль типов, перегрузку функций и ряд других удобств. Но главное в том, что C++ добавляет к С объектную ориентированность.
        Одной из главных  целей языка C++ являлось позволить  программистам строить типы, определенные пользователем (user-defined types — UDTs), которые  затем можно было бы использовать вне их исходного контекста. Этот принцип лег в основу идеи создания библиотек классов, или структур, какими мы знаем их сегодня. 

            

    Рис.2.8 Генеалогия объектных и объектно-ориентированных языков. 

      2.3. Выбор языка программирования 

      Общим вопросом при проектировании и разработке распределенного приложения является выбор языка программирования для написания компонентов. Язык обычно выбирают с учетом затрат на разработку, с учетом имеющейся квалификации и необходимого быстродействия. .NET абсолютно не зависит от языка. Теоретически для создания .NET-компонентов может использоваться любой язык и эти компоненты могут использоваться большим числом языков. Java, C++, Basic, Object Pascal - все они хорошо взаимодействуют с .NET.
      Нейтральность .NET по отношению к языку позволяет разработчику приложения выбирать язык и инструменты, с которыми он чувствует себя наиболее свободно. Независимость от языка, кроме того, позволяет выполнять быстрое прототипирование: вначале компоненты могут быть разработаны на языке высокого уровня, таком как Microsoft Visual Basic, а позже - на другом языке, таком как C++ или Java.
      Для реализации проекта выбирается язык программирования С# потому что:
        - C#  разрабатывался специально под платформу .NET;
       - Это объектно-ориентированный язык и соответственно он поддерживает инкапсуляцию внутренних функций данных, перегрузку операторов, также он поддерживает автоматическое управление памятью и автоматическая инициализация переменных;
      - Это мощный, гибкий, выразительный, более высокоуровневый, чем С++ язык программирования;
          -  Предоставляет большой набор интегрированных средств быстрой разработки;
      - Главным плюсом этого языка является высокая производительность, что очень немаловажно для написания серверной части, которая должна быстро обрабатывать запросы и выдавать результат; 

      2.4. Применение графиков в решении уравнений 

      Рассмотрим  графические возможности системы  построения простейших графиков функций  одной переменной вида y=f(x). График таких функций строится на плоскости, то есть в двумерном пространстве. Он представляет собой геометрическое положение точек (х, у) при изменении независимой переменной (абсциссы) в заданных пределах, например от минимального значения Xmin до максимального Xmах с шагом dx. Пример. Решим графически уравнение 3*x-x*x*x-2 = x*x+2*x-3 (рис.2.9). Для этого построим графики двух функций, функцию стоящую слева и функцию стоящую справа от знака равенства Точки пересечения графиков двух функций являются корнями этого уравнения. Таким образом получаем два корня x1 = -1 и x2 = 1. 

 

      Рис.2.9 Графическое решение уравнения 3*x-x*x*x-2 = x*x+2*x-3 

      Программа также умеет строить и исследовать  графики функций от двух переменных вида z=f(x, у). Функция двух переменных z=f(x, у) образует в пространстве некоторую трехмерную поверхность или фигуру. Для их построения желательно использовать координатную систему с тремя осями координат: х, у и z. Поскольку экран дисплея плоский, то на самом деле объемность фигур лишь имитируется — используется хорошо известный способ наглядного представления трехмерных фигур с помощью параллельной проекции. Вместо построения всех точек фигуры обычно строится ее каркасная модель, содержащая линии разреза фигуры по взаимно перпендикулярным плоскостям. В результате фигура представляется в виде совокупности множества криволинейных четырехугольников. Для придания фигуре большей естественности используются алгоритм удаления невидимых линий каркаса и функциональная закраска четырехугольников с целью имитации бокового освещения фигуры.
      На  рис.2.10 показан пример построения поверхности, описываемой функцией двух переменных z=2*sin(x*0,2)*cos(y*0,1) при х и у, меняющихся от -31 до 30 с шагом 1. Поверхность строится в виде каркаса с прямоугольными ячейками с использованием функциональной окраски. 

     

Рис.2.10 Построение графиков трехмерных поверхностей
3. ЭКОНОМИЧЕСКАЯ  ЧАСТЬ   
      

      Исходные данные
                                                                                                        Таблица 3.1
№ п\п Показатели Единица измерения Усл. обозначения Величина
1 2 3 4 5
1. Численность сотрудников, занятых при: – базовом варианте                                                              – эксплуатации                                                 – разработке
 
 
чел. чел.
чел.
 
 
Чбаз Чэкс.
Чразр.
 
 
1 1
1
2. Среднемесячная  заработная плата работников, занятых  непосредственно при разработке и эксплуатации программного продукта – базовый  вариант                                           
– эксплуатация (пользователь)                       
– разработка (программист)    
 
 
 
 
 
руб. руб. 

руб.
 
 
 
 
 
ЗПбаз. ЗПэкс. 

ЗПразр.
 
 
 
 
 
12000 12000 

15000
3. Трудоемкость  решения задачи из расчета на год: – базовый вариант
– эксплуатация (пользователь)                                          
– разработка
 
 
час. час. 

дни
 
 
tбаз. tэкс. 

tразр.
 
 
8 3 

76
                                                                                               Продолжение табл.3.1 

1 2 3 4 5
4. Стоимость покупных изделий и полуфабрикатов – базовый  вариант
– эксплуатация (пользователь)                                          
– разработка
 
 
руб. руб. 

руб.
 
 
Спок. баз. Спок. экс. 

Спок.разр.
 
 
4000      3650 

3000
5. Среднегодовая стоимость оборудования  
Фср.год
 
руб.
 
25000
6. Норма амортизации             На. % 12
7. Единый социальный налог Нсс. % 26
 
 
     3.2.    Применяемые формулы с расшифровкой условных обозначений 

1. Статья 1 Покупные изделия, полуфабрикаты  и услуги кооперированных предприятий.   
     Расчет  производится с учетом транспортно-заготовительных  расходов по формуле 1.1.:                        
     Спок. = Спок.`+(Спок`*Нт.з.р./100%) ,                                    (3.1)
     где Спок` – стоимость покупных изделий и полуфабрикатов по исходным данным,
    Нт.з.р. – норматив транспортно-заготовительных  расходов равный 2,5%. 

2. Статья 2. Фонд заработной платы
     Рассчитывается  по формуле 2.1.
     ФЗП = ЗП*Ч*t,                                                                            (3.2)
    где ЗП – среднемесячная заработная плата 1 человека;
           Ч – количество сотрудников,
           t – трудоемкость решения задачи. 

3. Статья 3.  Расчет отчислений на социальное  страхование.
   Расчет  производится по формуле 3.1.:
    Осс. = ФЗП* Нсс/100%,                                                             (3.3)
   где Нсс. – ставка единого социального налога, равная 26%. 

4. Статья 4. Расходы на содержание и эксплуатацию  оборудования.
   Расчет  данной статьи производится как расчет амортизационных отчислений по следующим этапам:
    4.1. Расчет годовых  амортизационных   отчислений  производится по формуле    4.1.:
    Ао.год. = Фср.год.*На./100%,                                                  (3.4.1)
    где На – норма амортизации за год равна 12%.
   4.2. Расчет амортизационных отчислений за период эксплуатации производится по формуле 4.2.:
           Ао.факт  =  (Ао.год./360) *t,                                                     (3.4.2)                                    где t – трудоемкость решения задачи в днях,                                                                                                                 
       360 – число рабочих дней в году.
         
5. Статья 5. Накладные расходы.             
   Расчет  производится по формуле 5.1.:
     Рн. = ФЗП*Нн.р./100%,                                                            (3.5)                     
   где Нн.р. – норматив накладных расходов, равный 60%. 

6. Себестоимость рабочего места – сумма пяти статей
   С раб.м. =  Спок+ФЗП+Осс.+Ао.факт+Рн.                                  (3.6)
               
7. Статья 7. Общепроизводственные расходы.
   Расчет  производится по формуле 7.1.:                   
    Ро.пр. = С раб.м.*Но.пр./100%,                                                (3.7)
    где Но.пр. – норматив общепроизводственных расходов, равный 100%.
    
8. Статья 8. Внепроизводственные расходы.
   Расчет  производится по формуле 8.1.:
     Рвн.пр. = С  раб.м*Нвн.пр./100%,                                            (3.8)                   
   где Нвн.пр. – норматив внепроизводственных расходов, равный 35%.                 

9. Полная себестоимость – сумма семи статей
    Спол. =  Сраб.м.+Ро.пр.+Рвн.пр.                                               (3.9) 

10.  Расчет экономической эффективности внедрения программного продукта.
   Расчет  ведется по формуле 10.1: 

   Ээфф. = ,                       (3.10)                 
                     
   где Спол.экс. – полная себестоимость эксплуатации за год дипломного прог- раммного продукта,
   Спол.разр. – полная себестоимость разработки дипломного программного продукта,
   Спол.баз. – полная себестоимость эксплуатации по базовой технологии. 
 
 

     3.3.    Расчет полной себестоимости разработки программного продукта по базовому варианту 
 

1. Статья 1. Покупные изделия, полуфабрикаты и услуги кооперированных предприятий.   
    Спок. = 4000+(4000*0,025) = 4100 руб.                                   (3.1) 

2. Статья 2. Фонд заработной платы.
    ФЗП = 12000*12 = 144000 руб.                                                 (3.2) 

3. Статья 3.  Расчет отчислений на социальное  страхование.
    Осс. = 144000*0,26 = 37440 руб.                                              (3.3) 

4. Статья 4. Расходы на содержание и эксплуатацию оборудования.
    4.1. Расчет годовых  амортизационных   отчислений   
       Ао.год. = 25000*0,12 = 3000 руб.                                     (3.4.1)
    4.2. Расчет амортизационных отчислений за период.
       Ао.факт. = (3000/360)*360 = 3000 руб.                              (3.4.2)
         
5. Статья 5. Накладные расходы.             
    Рн. = 144000*0,6 = 86400 руб.                                                    (3.5)                       


и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.