Графічне та геометричне моделювання та інтерактивні системи

2

Курсова робота

З дисципліни «Графічне та геометричне моделювання та інтерактивні системи»

На тему «Генерація фракталів»

Вступ

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

Постановка задачі

В даній курсовій роботі головним завданням було генерація фракталів.

Інформаційне забезпечення

У сучасних умовах важливою областю стало інформаційне забезпечення, що складається з накопичення і обробітку інформації, необхідної для прийняття обґрунтованих управлінських рішень. Передача інформації про положення і діяльність підприємства на вищий рівень керування і взаємний обмін інформацією між усіма суміжними підрозділами фірми здійснюються на базі сучасної електронно-обчислювальної техніки й інших технічних засобів зв'язку.

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

Зміст кожної конкретної інформації визначається потребами управлінських ланок і вироблюваних управлінських рішень. До інформації пред'являються визначені вимоги:

· По якості -- стислість і чіткість формулювань, своєчасність надходження;

· По цілеспрямованості -- задоволення конкретних потреб;

· По точності і вірогідності -- правильний добір початкових відомостей, оптимальність систематизації і безперервність збору й обробки відомостей.

Вхідна інформація, тобто данні що використовуються як вхідні для прийняття рішень системою:

· Категорії, групи та професії працівників;

· Форми оплати праці та види тарифних ставок;

· Тарифні розряди та розміри тарифних ставок;

· Тарифні коефіцієнти;

· Відпрацьовані години (денні та нічні) у випадку погодинної форми оплати.

Вихідна інформація, тобто данні що з'являються в результаті роботи системи:

· Загальна заробітна плата;

· Фактично отримана заробітна плата (без відрахувань на пенсійний фонд 1%, фонд зайнятості 0,5%, фонд соціального страхування, профспілковий внесок 1% та прибутковий податок 13%).

Алгоритм розв'язання задачі

Диаграмма вариантов использования (use case diagram)

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

Разработка диаграммы вариантов использования преследует цели:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

В даній курсовій роботі розглядається програма для генераціі фрактальніх зображень.

В якості акторів виступають Користувач, Логічний рівень, Інтерфейс користувача. Дивись додаток 1. Розглянемо більш детально користувачів і дії які вони виконують.

Користувач.

Генерація відображення (створення зображення фрактальной функції)

Сохранение відображення (збереження зображення фрак тала у вигляді графічного файлу)

Створення определения (створення опису фрактальной функції і установка параметрів генерації її відображення)

Створення определения по зумовленню.

Завантаження определения

Збереження определения (збереження відображення в xml-файл)

Обновлення определіння (збереження даних в ісходний файл)

Зміна определения ( редагування определения фрактальной функції і зміна параметрів її відображення)

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

Диаграмма компонентов (component diagram)

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

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

Чтобы пояснить отличие логического и физического представлений, рассмотрим в общих чертах процесс разработки некоторой программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой системы необходимо разработать исходный текст программы на некотором языке программирования (C++, Pascal, Basic/VBA, Java). При этом уже в тексте программы предполагается такая организация программного кода, которая предполагает его разбиение на отдельные модули.

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

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

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

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

· Визуализации общей структуры исходного кода программной системы.

· Спецификации исполнимого варианта программной системы.

· Обеспечения многократного использования отдельных фрагментов программного кода.

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

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

В додатку Х приведина головна діаграма компонентів. З малюнку можна побачити, що весь програмний засіб можна представити, як обектя який складается з 3 сущностей.

· Стан

· Логіка

· Інтерфейс користувача

Тільки Інтерфейс користувача може впливати на Стан і Логіку одночасно. Більш детально про логіку в діаграма компонентів. FractalGenerator при запуску поробдуе окремий потік в якому відбувається генерування фракталу. В Логіку же FractalDescription і XmlDocument мають оберненой зв'язок між собою. І можуть вплиати один на одного.

В додатку Х приведина більш детальна діаграма компонентів. Тут присутня як саме середовище виконання програми, так і детальний принцип роботи. За Інтерфейс користувача відповідає .NET Framework.

Логічне представлення

Діаграми послідовностей.

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

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

Схема генерацій зображення така. Дивись додаток Х

1. Пользователь через UI инициирует генерацию отображения

2. Приложение проверяет логическую корректность определения фрактальной функции

А. Если функция не корректна - уведомление пользователя и прекращение действий по генерации отображения

3. Приложение создает начальное изображение и поток для выполнения генерации

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

4. Поток генерирует изображение

А. Пользователь прерывает процесс генерации

5. Приложение обновляет состояние UI

Завантаження відображення

Пользователь через UI инициирует загрузку определения

6. Приложение отображает диалог открытия файла

А. Пользователь отказывается от действий - прекращение процесса загрузки определения

7. Пользователь выбирает файл

8. Приложение загружает файл в xml-документ, отображенный в память

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

9. Приложение извлекает из xml-документа необходимые данные для установки своего состояния

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

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

11. Прецедент "Создание определения" с п. 2

Зміна відображення

12. Пользователь воздействует на элементы UI

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

14. UI отслеживает связанные изменения и производит обновление всех соответствующих элементов интерфейса

Обновлення відображення

Пользователь через UI инициирует сохранение определения в файл

15. Переход к п.5 прецедента «Сохранение определения» с использованием в информации о текущем файле определения из состояния приложения

А. Состояние приложения не содержит информации о файле определения - переход к п.2 прецедента «Сохранение определения»

Обновлення сатну програми

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

Створення определения по замовленню

17. Пользователь запускает приложение либо же инициирует создание определения по умолчанию через UI

18. Приложение устанавливает свое состояние в соответствии с данными по умолчанию

19. Прецедент "Создание определения" с п.2

Створення определения

20. Пользователь через UI инициирует создание определения

21. Приложение получает данные описывающие определение и изменяет своё состояние

22. Приложение использует внутреннее состояние для обновления UI

Збереження відображення

23. Пользователь через UI инициирует сохранение отображения

24. Приложение отображает диалог создания/открытия файла

А. Пользователь отказывается от действий - прекращение процесса сохранения отображения

25. Пользователь выбирает файл

А. Пользователь выбрал уже существующий файл - приложение предлагает заменить его

а. Пользователь отказывается - возврат к п. 2.

26. Приложение сохраняет изображение в формате графического файла (jpg)

А. Приложение не может создать файл - уведомление пользователя и прекращение процесса сохранения отображения

Збереження визначення

27. Пользователь через UI инициирует сохранение определения в определенный файл

28. Приложение отображает диалог создания/открытия файла

А. Пользователь отказывается от действий - прекращение процесса сохранения определения

29. Пользователь выбирает файл

А. Пользователь выбрал уже существующий файл - приложение предлагает заменить его

а. Пользователь отказывается - возврат к п. 2.

30. Приложение преобразует данные определения в xml-документ, отображенный в память

А. Происходит ошибка при создании xml-документа - уведомление пользователя и прекращение процесса сохранения определения

31. Приложение сохраняет xml-документа в соответствующий файл

А. Приложение не может создать файл - уведомление пользователя и прекращение процесса сохранения отображения

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

Діаграми класів

Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация применяется и для объектов -- экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается.

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

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

В даній курсовій роботі вся функціональність зосереджена в класі Application. Цей клас пердставляе основні функції для роботи програми. Нижче наведені ці методи:

· OnStartGenerate()

· OnThreadFinish()

· User_Error()

· Save_View()

· Save_Description()

· App_Error()

· ConvertDescriptionToXml()

· Create()

· LoadDescription()

· GetDescription()

Збереження відображення

Взаємодіе з головнім класом Application. При цюму Інтерфейс користувача здійснює вивід діалогового вікна для збереження файлу. А Стан характеризує формат графічного файлу для зображення.

Збереження опреділення

Взаємодіе з головнім класом Application. При цюму Інтерфейс користувача здійснює вивід діалогового вікна для збереження файлу. А Стан характеризує xml-файл в який будуть записані інструкції по збереженюо пределеню.

Створення опреділення по зумовленню

Опреділення створюється на основі FractalDescription (Опису фракталу).

Генерацій зображення

Головний клас Application виставляє методи які в майбутньому будут використані для герерування. FractalGenerator при запуску створює поток, який і на основі оределенияз дійснюнє створення фракталу.

Програмне забезпечення

Для вирішення поставленої задачі можуть бути використані засоби UML (Unified Modeling Language) - уніфікованої мови моделювання, яка була розроблена для специфікації, конструювання, відображення та документування складних програмних систем. На сьогоднішній день UML знаходить широке застосування в якості неофіційного стандарту при розробках у таких областях, як керування вимогами до інформаційних систем; моделювання бізнес-процесів; аналіз, проектування, кодування і тестування програмного забезпечення. UML може бути використаний не лише для уніфікації представлення даних щодо ІС, але і для їхньої інтеграції, спрямованої на підвищення адекватності багато-модельного дослідження складних систем. Перспективи розвитку UML пов'язані з розвитком нової компонентної розробки додатків (Component-Based Development). У зв'язку з цим провадиться щодо реалізації ефективної підтримки UML об'єктних технологій CORBA і СОМ+.

Опис інформаційних процесів використовуються для опису технології обробки даних в ІС. На основі описаної технології визначаються загрози інформації в ІС.

У рамках розробленої методики при специфікації ІС використовуються наступні графічні діаграми UML:

· Діаграма варіантів використання - дозволяє здійснити аналіз функцій системи. Кожен окремий варіант використання описує поведінку системи відносно зовнішніх об'єктів;

· Діаграма класів - дозволяє описати структуру інформаційних об'єктів ІС. На даній діаграмі зображуються взаємозв'язки структурного характеру, які не залежать від часу та реакції системи на зовнішні події;

· Діаграма станів - дозволяє відобразити зміни станів окремого об'єкта чи суб'єкта ІС представляючи його у вигляді спеціального орієнтованого графа;

· Діаграма діяльності - використовуються для опису інформаційних процесів;

· Діаграма послідовності - служить для моделювання характеристик взаємодії передачі і прийому повідомлень між об'єктами ІС;

· Діаграма кооперації - призначена для специфікації структурних аспектів взаємодії;

· Діаграма компонентів - дозволяє відобразити залежності між суб'єктами програмного середовища ІС;

· Діаграма розгортання - містить інформацію щодо структури програмно-апаратних засобів ІС.

Сукупність вказаних діаграм відображає ієрархічну структуру ІС (вертикальні зв'язки).

Для моделювання правил доступу пропонується використовувати діаграми діяльностей (activity diagram) і діаграми класів (class diagram). Діаграми діяльностей можуть забезпечити моделювання алгоритмів роботи компонентів ІС, діаграми класів - моделювання структури системи.

На сьогодні для UML-моделювання існує широкий вибір програмних засобів. Найбільше розповсюдженими пакетами програм є Rational Rose, Visual UML, BPwin, Silverrun, Process Analyst, Together, System Architect, Objecteering та інші. Для побудови UML-діаграм можна використовувати MS Visio. Оскільки UML призначений для об'єктно-орієнтованого проектування систем, окремі програмні продукти забезпечують розробку структури програми включаючи засоби захисту інформації. Зокрема Rational Rose забезпечує комплексність підходу і інтеграцію з MS Visual Studio на рівні прямої й оберненої генерації кодів, інжиніринг і реінжиніринг модулів і бібліотек форматів EXE, DLL, TLB, OCX, підтримку CORBA, IDL, ADO, COM, Java.

Висновки

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

В частности, для моделирования бизнес-процессов могут быть использованы: применительно к подсистемам -- стереотипы "organization unit" и "work unit", для классов -- стереотипы "worker", "case worker", "internal worker". При этом, например, стереотип "worker" служит для обозначения класса, который представляет абстракцию человека, выполняющего определенную деятельность или работу в бизнес-системе. Работник или сотрудник взаимодействует с другими сотрудниками подсистемы в процессе выполнения отдельных операций, образующих бизнес-логику процесса.

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

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

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

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

Результатом виконання курсового проекту є змодельована система бухгалтерського обліку. Моделювання даної системи дозволяє нам наочно продемонструвати бажану структуру і поведінку системи. Моделювання також необхідно для візуалізації і управління архітектурою системи. Моделі допомагають досягти кращого розуміння системи, яку ми створюємо.

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

· Відрядна форма оплати праці;

· Почасова форма оплати праці;

· Контрактна система оплати праці;

· Безтарифна система оплати праці.

Список використаної літератури

Головатий О.О. Методичні вказівки до оформлення пояснювальних записок із дипломних робіт, літньої практики, курсових робіт та рефератів для студентів спеціальностей “Програмне забезпечення автоматизованих систем” та “Економічна кібернетика”. Жовті Води, ІП “Стратегія”, 2005.

Язык UML. Руководство пользователю / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. 2-е изд., Питер 2004.

http://www.rational.com.

http://www.omg.org.

додаток 2. ЗАГАЛЬНИЙ АЛГОРИТМ РОЗРАХУНКУ ЗАРОБІТНОЇ ПЛАТИ ЗА ТАРИФНИМИ СТАВКАМИ

Додаток 3. Наочне зображення діаграми послідовностей