Создание автоматизированной системы для расчета себестоимости продукции промышленного предприятия

КурсоваяПомощь в написанииУзнать стоимостьмоей работы

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

Содержание

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

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

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с.
X.M.Дейтел, П.Дж.Дейтел, С. И. Сантри «Технологии программирова-ния на Java 2» Бином;BHV, 2003-в 3-х томах.
«Секреты программирования для Internet» Питер;2005−400с.
J.Knudsen, P. Niemeyer «Learning Java, 2nd Edition», O’Reilly; July 2002−700с.
Andrew Mulholland, Glen Murphy «Java 1.4 Game Programming», Wordware Publishing;2003−647с.
J. Gehtland, B.A. Tate «Better, Faster, Lighter Java» O’Reilly;2004−250

Заполнить форму текущей работой