УЗНАЙ ЦЕНУ

(pdf, doc, docx, rtf, zip, rar, bmp, jpeg) не более 4-х файлов (макс. размер 15 Мб)


↑ вверх
Тема/ВариантСоздание автоматизированной системы для расчета себестоимости продукции промышленного предприятия
ПредметПрограммирование
Тип работыкурсовая работа
Объем работы35
Дата поступления12.12.2012
1500 ₽

Содержание

СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И КЛАССИФИКАЦИЯ СУЩНОСТЕЙ 4
2 ПОСТАНОВКА ЗАДАЧИ 6
3 ОБОСНОВАНИЕ РЕШЕНИЙ ПО ИСПОЛЬЗОВАНИЮ ТЕХНИЧЕСКИХ И ПРОГРАМНЫХ СРЕДСТВ РЕАЛИЗАЦИИ 7
4 ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ 10
5 ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ 14
6 ПРОЕКТИРОВАНИЕ И ПРОГРАММИРОВАНИЕ ИНТЕРФЕЙСОВ СИСТЕМЫ 17
7 ОПИСАНИЕ АЛГОРИТМОВ РАБОТЫ БЛОК-СХЕМ 19
8 ОПИСАНИЕ РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ 21
9 ТЕСТИРОВКА СИСТЕМЫ И ОПИСАНИЕ ПОЛУЧЕНЫХ РЕЗУЛЬТАТОВ 29
ЗАКЛЮЧЕНИЕ 33
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 34
ПРИЛОЖЕНИЕ А. 35


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



1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И КЛАССИФИКАЦИЯ СУЩНОСТЕЙ
Себестоимость продукции представляет собой часть стоимости выра-жающую в денежной форме затраты на потребленные средства производства и оплату труда работников. Транспортная продукция так же, как и продукция любой другой отрасли материального производства, имеет стоимость и себе-стоимость. Себестоимость и стоимость продукции представляют собой диалек-тическое единство. Без себестоимости нет стоимости. Себестоимость есть ос-нова стоимости и наоборот, если не создается стоимость, то нет и себестоимо-сти. Эти две экономические категории устанавливают различные условия про-стого и расширенного производства. Если реализуемая продукция больше се-бестоимости, то имеет место расширенное производство. Если же реализуемая продукция меньше себестоимости, то не обеспечивается даже простое воспро-изводство. Себестоимость продукции составляет лишь часть стоимости, так как в нее не включаются накопления предприятий, прибавочный продукт (за ис-ключением расходов по отчислениям на социальное страхование).
В практике работы предприятий применяются различные виды себестоимости в зависимости от объективных условий и признаков:
1. по общественной значимости, характеру формирования раз-личают индивидуальную (расходы конкретных предприятий по выпус-ку продукции) и общественную себестоимость;
2. по экономическому характеру она делится на производствен-ную, характеризующую затраты предприятия по производству продук-ции, и полную, которая включает в себя также и расходы по реализации (непроизводственные расходы тара, упаковка и т, д.);
3. по объекту затрат различают себестоимость всей продукции (расходы предприятия по выпуску всей массы продукции) и различных видов продукции или единицы продукции, которая представляет собой часть расходов, связанных с выпуском данной единицы (данного вида) продукции;
4. по периоду определения классифицируют плановую себе-стоимость, которая рассчитывается на плановый период исходя из пла-на, нормативов и норм, действующих на предприятиях (используется для оценки качества составления плана), и отчетную, характеризующую действительные, реализованные затраты по выпуску продукции на предприятии.
На основе сопоставления плановой и отчетной себестоимостей совер-шенствуется производственно-хозяйственная деятельность предприятий. Се-бестоимость на каждом конкретном предприятии одной отрасли производства определяется степенью технической вооруженности, совершенством, средств производства, эффективностью их использования, уровнем производительно-сти труда, совершенствованием организации, труда, производства, управления, уровнем цен на средства производства и рядом других факторов.

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

Задачей данного курсового проекта является разработка «клиент-серверного» приложение по управлению расчета себестоимости производст-венной продукции.
Основные задачи, которые должны быть выполнены в процессе создания курсового проекта:
1. Провести анализ изучаемой проблемы;
2. создать информационную модель для визуального представления решаемой задачи;
3. Использование в качестве целевой СУБД Sybase SQL Anywhere в которую переноситься полученная информационная модель.
4. Проектирование наглядного и удобного в использовании интерфей-са.
5. Создать для пользователя все условия по работе с информацией о клиенте.
6. Разработать руководство пользователю.


3 ОБОСНОВАНИЕ РЕШЕНИЙ ПО ИСПОЛЬЗОВАНИЮ ТЕХНИЧЕСКИХ И ПРОГРАМНЫХ СРЕДСТВ РЕАЛИЗАЦИИ

В данном разделе рассматриваются использованные в курсовой работе программные и технические средства с точки зрения эффективности и удобства их использования.
Среда ERwin предоставляет для работы удобный интерфейс и средства для определения сущностей, создания логических и физических моделей. Erwin также является одним из case-средств для формационного моделирования и дальнейшей генерации баз данных.
Миграция ключей в ERwin происходит автоматически в зависимости от выбранной связи (по умолчанию со своими именами). Что обеспечивает на-глядность и доступность в работе с сущностями и связями между ними.
В ERwin связи предоставляют следующие элементы информации: тип связи (идентифицирующая/неидентифицирующая, полная/неполная категория, спе-цифическая связь), родительская сущность, дочерняя сущность, мощность свя-зи, допустимость пустых значений.
Пакет BPwin является специализированным средством для создания и раз-работки функциональных моделей систем.
Модель в BPwin представляет собой совокупность SADT-диаграмм, каж-дая из которых описывает отдельный процесс в виде разбиения его на шаги и подпроцессы. С помощью соединяющих дуг описываются объекты, данные и ресурсы, необходимые для выполнения функции.
В BPwin диаграммы – это главные компоненты модели, все функции и ин-терфейсы на них представлены как блоки и дуги. Диаграммы строятся при по-мощи блоков. Каждый блок описывает какое-либо законченное действие. Че-тыре стороны блока имеют различное предназначение:
В качестве целевой СУБД в данном курсовом проекте был взят Sybase SQL Anywhere версии 9.0. Следует в первую очередь отметить, что
для обеспечения возможности работы с БД из любых других программных приложений, созданных средствами разработки других фирм используется свойство СУБД, позволяющее ей служить в качестве поставщика данных для этих приложений. Для этого используется некоторый стандарт обращения к СУБД – интерфейс ODBC.
ODBC (Open Data Base Connectivity) представляет собой стандарт интер-фейса прикладных программ, и позволяет программам, работающим в среде Microsoft Windows взаимодействовать посредством SQL с различными СУБД в различных операционных системах
Соответственно имеется возможность быстрого и бесперебойного осуществления соединения стакими средами как NetBeans 4.1. и ERWin, кото-рые также как и Sybase SQL Anywhere 9.0 используются в данном курсовом проекте.
Отметим также и общие достоинства стандарта SQL, которые имели зна-чение при выборе среды в качестве целевой СУБД. Возможно, наиболее важ-ными достижениями стандарта SQL являются четкая стандартизация синтакси-са и семантики операторов выборки и манипулирования данными, и фиксация средств ограничения целостности БД, включающих возможности определения первичного и внешних ключей отношений и так называемых проверочных ог-раничений целостности. Средства определения внешних ключей позволяют легко формулировать требования так называемой целостности БД по ссылкам. Этот стандарт охватывает практически все необходимые для реализации БД аспекты: манипулирование схемой БД, управление транзакциями (опять появи-лись точки сохранения) и сессиями (сессия - это последовательность транзак-ций, в пределах которой сохраняются временные отношения), подключение к БД, динамический SQL.
Среда IntelliJ IDEA – это интегрированная среда для разработчиков, сред-ство для программистов, помогающее писать, компилировать и отлаживать программы. Она написана на языке программирования Java, однако может под-держивать разработку на любом языке. Существует также большое количество модулей, расширяющих её функциональность. Среда разработки IntelliJ IDEA по умолчанию поддерживает разработку для платформ J2SE и J2EE. Для разра-ботки программ в среде IntelliJ IDEA и для успешной инсталляции и работы самой среды IntelliJ IDEA должен быть предварительно установлен Sun JDK или J2EE SDK подходящей версии.
По качеству и возможностям последние версии IntelliJ IDEA не уступают интегрированным средам разработки для языка Java, поддерживая рефакто-ринг, профилирование, выделение синтаксических конструкций цветом, авто-дополнение набираемых конструкций на лету, множество предопределённых шаблонов кода и др.
IntelliJ IDEA поддерживает плагины, позволяя разработчикам расширять возможности среды.
.

4 ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ

В работе проводится моделирование с использование IDEF0(BPWin), UML (Rational Rose 2000), IDEF1x (ErWin).
1. Важная роль отводится процессу функционального проектирования.
Для регламентирования создания функциональных моделей ПС предна-значен стандарт IDEF0 (Integrated Definition Function Modeling), который и реа-лизован в пакете BpWin.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принци-пиальной - функции системы анализируются независимо от объектов, которы-ми они оперируют. Это позволяет более четко смоделировать логику и взаимо-действие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графиче-ское), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно оп-ределяем, будет ли некий объект компонентом системы, или мы будем его рас-сматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселен-ной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности систе-мы), управление (стратегии и процедуры, под управлением которых произво-дится работа) и механизм (ресурсы, необходимые для проведения работы). На-ходясь под управлением, система преобразует входы в выходы, используя ме-ханизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с опре-деления контекста, т. е. наиболее абстрактного уровня описания системы в це-лом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно ус-тановить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компо-ненты системы, а что как внешнее воздействие. На определение субъекта сис-темы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее ком-понентов является основой построения модели. Хотя предполагается, что в те-чение моделирования область может корректироваться, она должна быть в ос-новном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При фор-мулировании области необходимо учитывать два компонента - широту и глу-бину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудо-емкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объек-ты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвя-зи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").

Введение

UML разработан таким образом, чтобы удовлетворять потребности при моделировании любых систем: от информационных систем масштаба предпри-ятия до распределенных Web-приложений и даже встроенных систем реально-го времени. Это выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему раз-вертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования.
Моделирование необходимо для понимания системы. Обычно, при этом единственной модели никогда не бывает достаточно. Наоборот, для понимания практически любой нетривиальной системы приходится разрабатывать боль-шое количество взаимосвязанных моделей. В применении к программным сис-темам это означает, что необходим язык, с помощью которого можно с различ-ных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки.
В приложении продемонстрированы диаграммы последовательности, диаграмм классов, кооперирования, состояния и использования (приложения).
3. С помощью инструментальной среды ERwin значительно уменьшается время разработки информационной системы, кроме того, данное средство достаточно гибко к изменяющимся требованиям.


5 ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ

IDEF1X является методом для разработки реляционных баз данных и ис-пользует условный синтаксис, специально разработанный для удобного по-строения концептуальной схемы. Концептуальной схемой мы называем уни-версальное представление структуры данных в рамках коммерческого пред-приятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Ис-пользование метода IDEF1X наиболее целесообразно для построения логиче-ской структуры базы данных после того, как все информационные ресурсы ис-следованы (скажем с помощью метода IDEF1) и решение о внедрении реляци-онной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X спе-циально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объ-ектно-ориентированной, то лучше избрать другие методы моделирования.
Существует несколько очевидных причин, по которым IDEF1X не следу-ет применять в случае построения нереляционных систем. Во-первых, IDEF1X требует от проектировщика определить ключевые атрибуты, для того чтобы отличить одну сущность от другой, в то время как объектно-ориентированные системы не требуют задания ключевых ключей, в целях идентифицирования объектов. Во-вторых, в тех случаях, когда более чем один атрибут является од-нозначно идентифицирующим сущность, проектировщик должен определить один из этих атрибутов первичным ключом, а все остальные вторичными. И, таким образом, построенная проектировщиком IDEF1X-модель и переданная для окончательной реализации программисту является некорректной для при-менения методов объектно-ориентированной реализации, и предназначена для построения реляционной системы.
Хотя терминология IDEF1X практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Сущность в IDEF1X описывает собой совокупность или на-бор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реа-лизацией сущности. Таким образом, сущность в IDEF1X описывает конкрет-ный набор экземпляров реального мира, в отличие от сущности в IDEF1, кото-рая представляет собой абстрактный набор информационных отображений ре-ального мира. В IDEF1X модели эти свойства называются атрибутами сущно-сти. Каждый атрибут содержит только часть информации о сущности.
В ERwin существуют два уровня представления и моделирования — ло-гический и физический. Логический уровень означает прямое отображение фактов из реальной жизни
Целевая СУБД, имена объектов и тины данных, индексы составляют вто-рой (физический уровень модели Erwin).
Процесс построения информационной модели состоит из следующих ша-гов:
• определение сущностей;
• определение зависимостей между сущностями;
• задание первичных и альтернативных ключей;
• определение атрибутов сущностей;
• приведение модели к требуемому уровню нормальной формы;
• переход к физическому описанию модели - назначение соответст-вий: имя сущности — имя таблицы, атрибут сущности — атрибут таблицы; за-дание триггеров, процедур и ограничений;
• генерация базы данных.
Рассмотрим процесс моделирования сущностей предметной области при помощи ErWin, который выполнялся в ходе курсовой работы.

Литература

П.Ноутан, Г.Шилд «Java 2» Питер;2005-1000с.
2. X.M.Дейтел, П.Дж.Дейтел, С.И.Сантри «Технологии программирова-ния на Java 2» Бином;BHV,2003-в 3-х томах.
3. «Секреты программирования для Internet» Питер;2005-400с.
4. J.Knudsen, P.Niemeyer «Learning Java™, 2nd Edition», O'Reilly; July 2002-700с.
5. Andrew Mulholland ,Glen Murphy «Java 1.4 Game Programming», Wordware Publishing;2003-647с.
6. J. Gehtland, B.A. Tate «Better, Faster, Lighter Java» O'Reilly;2004-250
Уточнение информации

+7 913 789-74-90
info@zauchka.ru
группа вконтакте