Реферат Реализация продукции на основе Case-средств
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Содержание
| Введение……………………………………………………………………………………… | |
| Глава 1. Характеристика CASE-средств…………………………………………………… | |
| 1.1. Характеристика BPwin (AllFusion Process Modeler)………………………….. | |
| 1.2. Характеристика Rational Rose………………………………………………….. | |
| Глава 2. Построение функциональной модели деятельности мебельной фабрики «Вернисаж» по методологии IDEF0………………… | |
| 2.1. Построение и описание диаграммы бизнес-процессов………………………. | |
| 2.2 Описание процесса «Учет реализованной продукции по отгрузке»………… | |
| 3. Разработка технического проекта на основе использования стандарта «Унифицированный процесс разработки ПО»……………………………………………. | |
| 3.1. Выявление и анализ требований к программному обеспечению для задачи «Учет реализованной продукции по отгрузке»…………………………………………… | |
| 3.1.1 Концепция……………………………………………………………….. | |
| 3.1.2. Модель прецедентов……………………………………………………. | |
| 3.2. Объектно-ориентированное проектирование…………………………………. | |
| 3.2.1. Диаграмма концептуальных классов………………………………….. | |
| 3.2.2. Диаграмма программных классов……………………………………... | |
| 3.2.3. Диаграмма последовательности……………………………………….. | |
| 3.3. Проектирование схемы базы данных………………………………………….. | |
| Заключение…………………………………………………………………………………… | |
| Список использованной литературы……………………………………………………….. | |
| Приложение………………………………………………………………………………… | |
| | |
Введение
По своему экономическому содержанию объем реализованной продукции характеризует конечный финансовый результат работы предприятия, выполнения своих обязательств перед потребителями, степень участия в удовлетворении потребностей рынка.
Верно учтенные объемы реализованной продукции, своевременный и достоверный учет отгрузки и оплаты продукций – это залог правильно сформированной выручки, а значит и правильно рассчитанных налогов.
Реализация продукции осуществляется в соответствии с заключенными договорами или путем свободной продажи через розничную торговлю.
В договорах на поставку готовой продукции указывают поставщика и покупателя, необходимые показатели по изделиям, цены, скидки, накидки, порядок расчетов, сумму налога на добавленную стоимость и другие реквизиты. В международной практике принято дополнительно указывать непреодолимые обстоятельства (форс-мажор), поручительство, гарантии исполнения договорных условий, порядок возмещения убытков, оговорку о подсудности и арбитраже и другие сведения.
На основании товарно-транспортных накладных и других документов на отпуск продукции на сторону в финансовом отделе или при его отсутствии с бухгалтерии выписывают в нескольких экземплярах платежные требования для расчетов с покупателями через банк.
В бухгалтерии ведётся отчётность по реализации продукции, где рассчитываются натуральные и стоимостные показатели.
В рамках курсового проекта учёт реализованной продукции будет рассмотрен на примере мебельной фабрики «Вернисаж». Деятельность организации заключается в изготовлении мебели и её последующей реализации потребителям.
Клиенты мебельной фабрики – это какие-либо организации (юридические лица), а также физические лица(покупатели).
Целью данного курсового проекта является описание унифицированного процесса разработки программного обеспечения для задачи «Учет реализованной продукции по отгрузке».
Задачи курсового проекта:
- разработать систему «Учет реализованной продукции по отгрузке» для формирования отчета о реализованной продукции по отгрузке за период;
- рассмотреть теоретические аспекты построения моделей бизнес-процессов по методологиям IDEF0 и UML;
- построить модели деятельности предприятия по методологии IDEF0;
- узнать о требованиях по сертификации программных продуктов, приводить программные продукты к требованиям действующих стандартов;
- построить модель прецедентов, описать прецеденты, построить диаграммы программных классов и диаграмму последовательности для конкретного прецедента в рамках языка моделирования UML.
Глава 1. Характеристики
CASE средств.
CASE-средства (от Computer Aided Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASEсредства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат использования CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
· интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:
· репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
· средства разработки приложений, включая языки 4GL и генераторы кодов;
· средства конфигурационного управления;
· средства документирования;
· средства тестирования;
· средства управления проектом;
· средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
· применяемым методологиям и моделям систем и БД;
· степени интегрированности с СУБД;
· доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
· средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
· средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
· средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
· Vantage Team Builder (Westmount I-CASE);
· Designer/2000;
· Silverrun;
· ERwin+BPwin;
· S-Designor;
· CASE.Аналитик.
1.1Характеристика
BPWin или
AUfusion
BPwin - это незаменимый инструмент менеджеров и бизнес-аналитиков, а начиная с версии 1.8, в которую включена поддержка диаграмм потоков данных и методики IDEF3 (BPwin Professional), становится в руках системных аналитиков и разработчиков и мощным средством моделирования процессов при создании корпоративных информационных систем.
BPwin обладает интуитивно-понятным графическим интерфейсом, помогает быстро создавать и анализировать модели с целью оптимизации деловых и производственных процессов. Применение универсального графического языка бизнес-моделирования IDEF0 обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов BPwin позволяет Вам легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами.
BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании. Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа.
BPwin может генерировать отчеты непосредственно в формате MS Excel и Word для последующей обработки и использования в других приложениях. Связь с ERwin (моделирование данных в стандарте IDEF1X) позволяет сократить время проектирования и разработки сложных информационных систем. Для системных аналитиков тесная интеграция BРwin с инструментом проектирования баз данных открывает уникальные возможности по созданию комплексных систем, в которых ERwin служит для описания информационных объектов системы, в то время как BPwin отражает функциональные особенности предметной области. Связывая сущности и атрибуты модели данных с информацией о выполняемых действиях, Вы можете продолжить анализ процессов на новом уровне с одновременной перекрестной проверкой моделей процессов и данных.
Основные характеристики BPwin:
· Развитая методология функционального моделирования на основе IDEF0
· Мощные редакторы для описания операций, связей и вычисления затрат на выполнение работ
· Иерархическая структура диаграмм, облегчающая последовательное уточнение элементов модели
· Контекстные диаграммы для описания границ системы, области действия, назначения объектов
· Декомпозиционные диаграммы для описания особенностей взаимодействия различных процессов
· Расширенные возможности по поддержанию ссылочной целостности
· Поддержка методологии IDEF3
· Экспорт моделей в средства имитационного моделирования
· Интеграция и связь со средством проектирования баз данных ERwin (методология IDEF1X)
· Поддержка свойств, определяемых пользователем. Описание моделей может быть расширено за счет свойств, определяемых пользователем, включая мультимедийные документы.
· Интеграция с ModelMart, поддерживающим мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.
· Удобный интерфейс пользователя. В распоряжении пользователей имеется проводник, ставший привычным в среде Windows 95/NT, позволяющий легко переходить с одной диаграммы на другую простым перемещением по "дереву" проводника.
· Расширенная архитектура. BPwin поддерживает 16- и 32-х разрядные системы, позволяя организовать совместную работу для всех участников проекта.
· Автоматическая поддержка изменения размеров. BPwin поддерживает автоматическую настройку размеров диаграмм и возможность изменения масштабов изображения моделей.
Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.
BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer .
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель.
Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
1.2 Характеристика
Rational Rose
С 1998 года стала набирать силу технология Rational Rose, основанная на объектно-ориентированном подходе и на последовательно уточняющихся графических моделях.
Rational Rose - современное и мощное средство анализа, моделирования и разработки программных систем. Rational Rose пригодится при решении практически любых задач проектирования информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Такой арсенал позволит не только спроектировать новую систему, но и доработать старую, произведя процесс обратного проектирования.
Rational Rose в отличие от подобных средств проектирования способна проектировать системы любой сложности, то есть инструментарий программы допускает как высокоуровневое (абстрактное) представление (например, схема автоматизации предприятия), так и низкоуровневое проектирование (интерфейс программы, схема базы данных, частичное описание классов). Вся мощь программы базируется всего на 7 диаграммах, которые в зависимости от ситуации способны описывать различные действия.
Что может делать Rational Rose
1. Проектировать системы любой сложности
2. Давать развернутое представление о проекте в сочетании со средствами документирования (SoDA)
3. Проводить кодогенерацию
4. Проводить обратное проектирование имеющихся систем
5. Имеет открытый для дополнений интерфейс
6. Интегрируется со средствами разработки (Visual Studio)
7. Поддержка языка UML
8. Наличие средств автоматического контроля, в том числе проверки соответствия двух моделей
9. Удобный для пользователя графический интерфейс
10. Многоплатформенность
11. Интегрируемость с другими инструментальными средствами, поддерживающими жизненный цикл программных систем, в том числе со средством управления требованиями (Requisite Pro), со средствами тестирования (SQA Suite, Performance Studio), со средствами конфигурационного управления (ClearCase, PVCS).
Итак, что умеет делать CASE Rational Rose. Являясь объектно-ориентированным инструментом моделирования, Rose базируется на UML (Universal Modeling Language) - универсальном языке моделирования, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:
1. Activity diagram (диаграммы описаний технологий, процессов, функций).
2. Use case diagram (диаграммы функций).
3. Class diagram (диаграммы классов).
4. State diagram (диаграммы состояний);
5. Sequence diagram (диаграммы последовательностей действий);
6. Collaboration diagram (диаграммы взаимодействий
7. Component diagram (диаграммы компонент);
8. Deployment diagram (диаграммы топологии).
Для того чтобы наиболее полно покрыть весь сегмент рынка средств проектирования и разработки, выпускается несколько версий продукта:
· Rational Rose Modeler
Эта версия позволит аналитикам и проектировщикам проводить анализ бизнес-процессов и проектировать систему. Данная редакция, увы, не поддерживает кодогенерацию.
· Rational Rose Professional
Как видно из названия, это профессиональная редакция продукта. В зависимости от выбранного языка программирования позволяет выполнять прямое и обратное проектирование. Rose Professional заказывается только в определенной конфигурации (например, Rose Professional С++ или Rose Professional С++ DataModeler). Rational Rose Professional, конечно, не создает 100 % исполняемого кода. На выходе разработчик получает каркасный код информационной системы на определенном (заказанном) языке программирования, который впоследствии нужно еще программировать и программировать. Продукт нацелен и на аналитиков, и на разработчиков.
· Rational Rose RealTime
Версия продукта, созданная специально для получения 100 % исполняемого кода в реальном масштабе времени. Конечно, RealTime позволяет проводить прямое и обратное проектирование на языках С или С++. По заверениям разработчиков, на выходе модель автоматически компилируется и собирается в исполняемый файл. Само собой, продукт предназначен именно для разработчиков.
· Rational Rose Enterprise
Абсолютно полная версия. Поддерживаются все функции других редакций, за исключением возможности 100 % кодогенерации. Таким образом, эта версия продукта покрывает весь спектр задач по проектированию, анализу и кодогенерации. Это программный пакет для всех участников проекта.
· Rational Rose DataModeler
Это не конкретный вариант продукта, а функциональность по проектированию баз данных. Функции DataModeler входят в состав Rose Enterprise или Professional.
Глава 2.Постороение функциональной модели деятельности мебельной фабрики ООО «Вернисаж» по методологии
IDEF0
Одной из самых важных целей, при подготовке проекта построения информационной системы является четкая и правильно понимаемая постановка задачи. Для достижения этой цели необходимо исследовать все происходящие финансово-хозяйственные процессы, и соответствующие им потоки информации на предприятии, выявить те из них, которые должны быть реорганизованы в первую очередь.
Наиболее известная и распространенная методика моделирования бизнес-процессов – методология IDEF0, относящаяся к семейству IDEF. Она принята в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ. IDEF0 можно использовать для моделирования широкого класса систем. Для новых систем она применяется с целью определения требований и функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам методология IDEF0 может быть использована для анализа функций, осуществляемых системой, и отображения механизмов, посредством которых эти функции выполняются.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").
Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).
В IDEF0 различают пять типов стрелок:
Вход (input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1.5 - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны, например, на выходе - "Заполненная карта пациента". Очень часто сложно определять, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются (изменяются) ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.
Управление (Control)- правила, стратегии, процедуры или стандарты, которыми руководствуется работа. "Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 1.5 стрелки "Задание" и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.
Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 1.5 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".
Механизм (Mechanism)- ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 1.5 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.
Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. На рис. 1.5 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия" Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Рис.1 Функциональный блок
Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рисунке 2 изображен функциональный блок “Обработать заготовку”.
В реальном процессе рабочему, производящему обработку, выдают заготовку и технологические указания по обработке (или правила техники безопасности при работе со станком). Ошибочно может показаться, что и заготовка и документ с технологическими указаниями являются входящими объектами, однако это не так. На самом деле в этом процессе заготовка обрабатывается по правилам отраженным в технологических указаниях, которые должны соответственно изображаться управляющей интерфейсной дугой.
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логистических цепочек.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
2.1Построение и описание диаграмм бизнес-процессов
Описание TOP-диаграммы (процесса A-0)
Деятельность мебельной фабрики «Вернисаж» по реализации продукции
Входные данные:
· Ранок рабочей силы
· Рынок капитала
· Рынок оборудования
· Рынок сырья и материалов
· Рынок сбыта в широком смысле
Выходные данные:
· Реализованная продукция
· Прибыль от реализации продукции
· Отчётность по деятельности компании
Управление:
Работа мебельной фабрики «Вернисаж» осуществляется на основе Устава предприятия, Положениях об отделах, Инструкций, федеральных законов и нормативно-правовых актов, ГОСТов, Положений по бухгалтерскому учёту, Коллективных договоров.
Механизм:
· Персонал
· Основные фонды
Описание процесса A0
Бизнес-процессы:
А1 : Экономическое и финансовое управление. Обеспечивает контроль за наличием и рациональным распределением денежных средств, необходимых для достижения запланированных технико-экономических показателей работы подразделений и организации в целом: расчёт финансового плана предприятия, учёт всех совершаемых денежно-финансовых операций, контроль выполнения плана реализации и прибыли, анализ и регулирование финансового состояния предприятия. На этом уровне происходит планирование финансового и производственного плана развития предприятия: рассчитывается текущий оптимальный план производства товарной продукции, разработка перспективного плана развития, проводится анализ экономических показателей и состояния предприятия на основе бухгалтерского баланса, происходит планирование цен на продукцию, тарифных ставок по заработной плате.
А2 : Управление производством. Обеспечивает согласованную работу цехов, участков, бригад, рабочих мест по выполнению установленных плановых заданий в номенклатуре, количестве и заданные сроки при наиболее рациональном использовании оборудования, рабочей силы и оборотных средств. Данный блок отвечает полностью за производственный процесс. Продукция изготавливается в соответствии с требованиями ГОСТов. Подразделение реализовывает поставленные задачи в плане производства, снабжается необходимыми оборудованием и материалами. Произведённая продукция идёт на склады сбыта и там учитывается, также информация о готовой продукции для регистрации и учёта отправляется в бухгалтерию.
А3 : Бухгалтерский учёт. Обеспечивает ведение всех видов учёта и отчётности, контроля за сохранностью товарно-материальных ценностей. Руководствуется Положениями по бухгалтерскому учёту, федеральными законами. Бухгалтерия получает различную информацию для учёта: из отдела кадров приказы о приёме на работу и приказы об увольнении, из производственных отделов – информацию о готовой продукции, о расходе сырья и материалов, об изнашивании оборудования, из отдела сбыта – информацию об отгруженной и реализованной продукции, информацию о ценах, тарифных ставках из экономического отдела и т. д. На выходе формируется различная отчётность о деятельности предприятия, бухгалтерский баланс.
А4 : Управление сбытом. Обеспечивает потребителей продукцией в соответствии с принятыми договорами, проводит маркетинговые исследования рынка, набирает «портфель заказов» от потребителей, проводится календарное планирование отгрузки по договорам потребителей, ведётся контроль наличия и движения готовой продукции на складе сбыта, ведётся учёт договорных обязательств. Отдел сбыта формирует данные о реализованной и отгруженной готовой продукции для дальнейшего учёта в бухгалтерии.
А5 : Управление кадрами. Обеспечивает удовлетворение потребностей предприятия в специалистах требуемой квалификации, контролирует рациональное использование трудовых ресурсов. Формирует приказы о приёме и увольнении, табель учёта рабочего времени, передаёт их для отчётности в бухгалтерию.
Описание процесса A3
Бизнес-процессы:
А1 : Учёт основных средств. Ведётся учёт основных фондов предприятия, а именно: оценка основных средств, поступление и ввод в эксплуатацию, переоценка основных средств, амортизация, ремонт, выбытие, налогообложение, инвентаризация основных средств. Руководствуются Положениями о бухгалтерском учёте. Данные необходимы для бухгалтерского баланса и для отчётности по деятельности фабрики.
А2 : Учёт сырья и материалов. Учёт наличия и контроль за движением материалов и сырья на складах снабжения. Учёт отпуска материалов и сырья в производство продукции. Руководствуются Положениями о бухгалтерском учёте. Данные необходимы для бухгалтерского баланса и для отчётности по деятельности фабрики.
А3 : Учёт зарплаты. Учёт отработанного времени из Табеля рабочего времени, контроль за наличием и движением кадров. Руководствуются Положениями о бухгалтерском учёте. Данные необходимы для бухгалтерского баланса и для отчётности по деятельности фабрики.
А4 : Учёт производства продукции. Учёт поступления и наличия инструмента. Контроль качества. Учёт наличия и контроль движения материальных ресурсов. Учёт фактических затрат на производство продукции. Руководствуются Положениями о бухгалтерском учёте. Данные необходимы для бухгалтерского баланса и для отчётности по деятельности фабрики.
А5 : Учёт реализованной продукции. Учёт реализуемой продукции по отгрузке в стоимостном и в натуральном выражениях. Руководствуются Положениями о бухгалтерском учёте. Данные необходимы для бухгалтерского баланса и для отчётности по деятельности фабрики.
Описание процесса A31
Бизнес-процессы:
А1 : Приём и регистрация входных документов. На данном этапе происходит сбор, регистрация и обработка данных о реализуемой продукции (на основе договоров, товарно-транспортных накладных, счёт-фактур, платёжных поручений).
А2 : Расчёт реализованной продукции в натуральном и стоимостном выражениях. На данном этапе происходит обработка данных, расчёт необходимых показателей.
А3 : Формирование отчётных документов. На данном этапе формируется ведомость о реализуемой продукции с итоговыми показателями.
2.2 Описание процесса «Учет реализованной продукции»
Экономико-организационная сущность
Готовая продукция – часть материально-производственных запасов организации, предназначенная для продажи, конечный результат производственного процесса, законченный обработкой, технические и качественные характеристики которого соответствуют условиям договора или требованиям иных документов в случаях, установленных законодательством.
В настоящих условиях основное значение придается реализации продукции (товаров) по договорам-поставкам важнейшему экономическому показателю работы, определяющему эффективность, целесообразность хозяйственной деятельности организации. В объем реализации включаются отгруженная и отпущенная продукция, выполненные работы независимо от того, зачислен или нет платеж на расчетный счет организации или получены векселя, авансы.
Таким образом, процесс реализации завершает кругооборот хозяйственных средств организации, что позволяет ей выполнять обязательства перед государственным бюджетом, банками по ссудам, персоналом, поставщиками и возмещать прочие производственные затраты. Невыполнение плана реализации вызывает замедление оборачиваемости оборотных средств, штрафы за невыполнение договорных обязательств перед покупателями, задерживает платежи, ухудшает финансовое положение организации.
Отпуск готовой продукции и ее отгрузка оформляются приказом-накладной, в который включены два документа: приказ складу и накладная на отпуск. Приказ складу выписывает соответствующая служба, на основе условий договора с покупателями, с указанием наименования покупателя, его кода, количества и ассортимента продукции, срока отгрузки.
Материально ответственное лицо (кладовщик) комплектует продукцию по каждому приказу и передает экспедитору для отправки, записывая количество в графе «Отпущено».
Документ подписывается начальником службы, кладовщиком и экспедитором. Приказ-накладная оформляется в двух экземплярах: первый передается экспедитору для указания количества отправленных мест, массы груза согласно товарно-транспортной накладной и суммы оплаченного железнодорожного тарифа за перевозку продукции до станции покупателя; второй экземпляр остается у кладовщика как основание для отпуска. По нему и карточках складского учета в графе «Расход» проставляется количество отпущенной продукции, и документ передается бухгалтеру. Экспедитор сдает продукцию транспортной организации получает квитанцию о приеме груза. На следующий день после отгрузки продукции экспедитор обязан приказ-накладную и квитанцию транспортной организации передать в бухгалтерию организации для выписки счета типовой формы (или платежного требования-поручения) и счета-фактуры на имя покупателя.
Для того чтобы отразить продукцию или работы, услуги реализованными, бухгалтерия должна иметь документы, подтверждающие исполнение договора и в первую очередь переход прав собственности на них. Кроме указанной ранее приказ-накладной это могут быть железнодорожные, авиа, товарно-транспортные накладные с отметками станции отправления или назначения, коносаменты, акты выполненных работ, и др.
Продажа продукции осуществляется в соответствии с заключениями договорами или путем свободной продажи через розничную торговлю.
В договорах на поставку готовой продукции указывают поставщики и покупатели, необходимые показатели по изделиям, цены, скидки, порядок расчетов, сумму налога на добавленную стоимость и другие реквизиты. В международной практике принято дополнительно указывать непреодолимые обстоятельства (форс-мажор), поручительство, гарантии исполнения договорных условий, порядок возмещения убытков, оговорку о подсудности и арбитраже и другие сведения.
Рассмотрим учёт реализованной продукции по факту отгрузки на примере мебельной фабрики. Отгрузкой и отпуском продукции занимается отдел сбыта (маркетинга) организации. Работники этой службы заключают договоры с покупателями, оформляют документы на отгружаемую продукцию, ведут оперативный учет движения продукции на складе, контролируют выполнение договорных обязательств, полноту и своевременность поступления средств от покупателей.
Отпускаемая со склада продукция оформляется первичными документами. Отдел сбыта (маркетинга) на основании договора поставки и графика отгрузки продукции выписывает приказ - накладную, где указываются покупатель, наименование продукции (изделий), количество продукции, подлежащей отпуску и фактически отпущенной, договорная цена, сумма, стоимость упаковки, оплачиваемой сверх цены на продукцию. После оформления приказ - накладная передается на склад. В ней отпуск продукции со склада подтверждается подписью кладовщика и получателя.
На продукцию, отправляемую специализированными транспортными организациями, выписывается товарно - транспортная накладная. У поставщика она заменяет приказ - накладную, а у покупателя - приходный ордер.
Все первичные документы на отгруженную продукцию передаются в финансовый отдел или бухгалтерию для выписки расчетных документов (платежных требований).
Платежное требование представляет собой требование поставщика к покупателю оплатить на основании направленных в обслуживающий банк плательщика расчетных и отгрузочных документов стоимость поставленной по договору продукции, выполненных работ и оказанных услуг. Платежное требование выписывается поставщиком на основании договора и отгрузочных документов (товарно - транспортной накладной). В нем поставщик указывает наименование плательщика и обслуживающий его банк, наименование поставщика и его банк, сумму к оплате и т.д., подписывает его и заверяет печатью.
Характеристика задачи:
1) Место решения: бухгалтерия.
2) Цель решения: расчёт реализованной продукции в натуральном и стоимостном выражениях.
3) Назначение задачи и потребители результатной информации: предоставление данных по учету реализованной продукции необходимо:
- бухгалтеру – информация о реализованной продукции в натуральном и стоимостном выражениях на конец периода для составления бухгалтерской отчетности;
- работникам отдела сбыта – информация о реализованной продукции в натуральном и стоимостном выражениях для календарного планирования отгрузки по договорам потребителям, для контроля за наличием и движением готовой продукции на складе сбыта, для учёта выполнения договорных обязательств;
- директору филиала – информация о реализованной продукции в натуральном и стоимостном выражениях для контроля над эффективностью работы предприятия.
4) Периодичность решения: каждые четыре недели, ежемесячно к третьему числу, ежедневно (для оперативного учета), по запросу.
5) Входные документы:
- договор (приложение к договору)
- приказ-накладная
- товарно-транспортная накладная;
- счёт-фактура
- платежное требование;
6) Выходные документы:
- Отчёт о реализованной продукции (товаров) на дату .
3. Разработка технического проекта на основе использования стандарта «Унифицированный процесс разработки ПО»
3.1. Выявление и анализ требований к программному обеспечению для задачи «Учет реализованной продукции»
3.1.1 Концепция
Цель создания курсового проекта – собрать, проанализировать и представить формализованное описание высокоуровневых потребностей и возможностей системы учета реализованной продукции. Подробное изложение того, как система учета реализованной продукции выполняет эти потребности, представлено в прецедентах и дополнительных спецификациях.
Потребности пользователя:
· регистрация, накопление, обработка и хранение информации о совершенных хозяйственных операциях (количестве реализованной продукции, её стоимостное выражение);
· учёт реализованной продукции;
· получение отчётов и другой документации по реализации продукции в натуральном и стоимостном выражениях;
· анализ результатов от реализации продукции для планирования прибыли, убытков, плана производства и реализации;
· получение стандартных форм и отчетов для предоставления в органы финансового контроля и налогообложения.
Формулировка проблемы
Существующая система учета реализованной продукции не обладает гибкостью, неустойчива к сбоям, не обеспечивает интеграцию с внешними системами. Это приводит к проблемам несоответствия программного обеспечения экономическим и информационным требованиям фабрики. Это может привести к снижению эффективности и оперативности принимаемых решений, что вызовет существенные потери трудовых, материальных и финансовых ресурсах.
В решении следующих проблем заинтересован главный бухгалтер, работники отдела сбыта и руководитель фабрики.
Характеристика пользователя
Программа предназначена не квалифицированных пользователей. Для ее использования не потребуется дополнительного обучения персонала в области компьютерной техники, хватит навыков простого пользователя. Программа понятна и проста в эксплуатации.
Пользователь должен обладать знаниями в области бухгалтерского учёта, в области сбытовой деятельности, иметь навыки простого пользователя компьютером и навыки работы с офисной техникой.
Предусмотрено два типа пользователей: оператор и бухгалтер по учету реализуемой продукции, возможно их слияние. Работа бухгалтера чаще всего включает множество рутинных операций. Применение программы позволит максимально уменьшить ручной труд. Основные обязанности бухгалтера сводятся к вводу информации с первичных документов в базу данных и формированию выходных документов.
Ввод – узкое место в автоматизированной системе. Он, как правило, осуществляется вручную с клавиатуры. Поэтому работа пользователя очень ответственна. От правильности ввода первичной информации зависит правильность конечного результата. В системе предусмотрен контроль ввода информации, но главное для успешного решения задачи учета реализованной продукции - все же внимательность пользователя.
Характеристика продукта
Предлагаемый программный продукт предназначен для решения задачи «Учет реализованной продукции по отгрузке».
Функции приложения:
- организация ввода достоверной информации в режиме реального времени (включает в себя регистрацию, предварительную обработку, ввод и контроль);
- организация поиска в базе данных;
- расчет реализованной продукции на дату;
- контроль полученных результатов и анализ;
- формирование отчетов для передачи в подразделения филиала (административно-хозяйственный отдел, департамент торговли, директору филиала. Организационная структура управления представлена в Приложении 7);
- настройка системы на конкретного исполнителя;
- взаимодействие в реальном масштабе времени с внешними системами.
3.1.2. Модель прецедентов
Прецеде́нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актёрами . В понятие «актер» входят люди, компьютерные системы и процессы. Прецедент описывает взаимодействие программной системы с актерами в виде последовательности сообщений.
Прецеденты были предложены Иваром Якобсоном и значительно популяризированы Алистером Коберном.
Прецеденты служат для документирования функциональных требований к программным системам. Прецедент описывает некоторый целостный фрагмент поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта. Определение прецедента содержит все свойственные ему виды поведения: основную последовательность, различные варианты стандартного поведения и различные исключительные ситуации с указанием ответной реакции на них. С точки зрения пользователя некоторые из видов поведения выглядят как ошибочные. Однако для системы ошибочная ситуация является одним из вариантов поведения, который должен быть описан и обработан.
При проектировании программной системы производится поиск таких классов для реализации прецедента, которые удачно сочетали бы в себе требуемые роли и не приводящие к излишнему усложнению системы. Реализацию прецедента можно смоделировать в виде одной или нескольких коопераций (реализаций прецедента).
Один и тот же прецедент может быть описан с различной степенью детализации.
В международном стандарте UP модель прецедентов – результат анализа функциональных требований.
На основе языка UML модель прецедентов включает в себя диаграмму прецедентов и описание каждого прецедента в отдельности с соответствующими диаграммами последовательности (в рамках данного курсового проекта будет развернуто описан только один прецедент).
Диаграмма прецедентов– диаграмма, на которой отображаются актеры, прецеденты и связи между ними. Диаграмма прецедентов – основной метод визуализации для модели поведения системы.
Диаграмма прецедентов позволяет пользователю установить отношения межу прецедентами, если они существуют. На диаграммах прецедентов символы актеров и прецедентов отображаются связанными друг с другом. При этом актер, связан с теми прецедентами, в которых он принимает непосредственное участие.
Рис.2 Диаграмма прецедентов
Развернутое описание процесса (прецедента «Расчет реализованной продукции по отгрузке»)
Основной исполнитель: бухгалтер.
Предприятие заинтересовано в максимальном объеме реализации товаров и получении максимальной прибыли от реализации этих товаров.
Предварительные условия:
1) подготовлена первичная информация о совершении хозяйственных операций;
2) в архиве хранятся документы за 3 года (выписки банка с подложенными к ним платежными поручениями, товарно-транспортные накладные и счета-фактуры, договоры, приложения к договорам);
3) организация осуществляет свою деятельность в строгом соответствии с условиями договора;
4) бухгалтер идентифицирован и аутентифицирован.
Результаты: введена первичная информация по реализованной продукции: её количестве, цене, по оплате, налоге.
Основной успешный сценарий:
1. Бухгалтер выбирает и запускает запрос на формирование отчета о реализованной продукции за период.
2. Система проводит расчёт реализованной продукции в натуральном и стоимостном выражениях, формирует отчет.
3. Бухгалтер выполняет процедуру визуального контроля отчета.
4. Бухгалтер выводит документ на печать.
Расширения (альтернативные потоки событий):
2а. Система вышла из строя.
1. Бухгалтер перезагружает систему, регистрируется, инициирует восстановление прерванного состояния.
2. Система восстанавливает прерванное состояние.
2а. Система определяет причину сбоя.
1. Система сообщает об ошибке бухгалтеру, регистрирует ошибку и переходит в начальное состояние.
2. Бухгалтер заново запускает запрос.
2б. Система выдает ошибку, не выполняет запрос.
1. Бухгалтер устраняет ошибку (например, исправляет интервал дат). Если самостоятельно устранить ошибку не получается, обращается к работнику ИТ-отдела.
2. После устранения ошибки заново выполняется запрос на формирование отчета.
3а. Отчет сформирован с ошибкой.
1. Бухгалтер проверяет правильность отображения первичной информации в системе.
2а. Вводятся корректировки в аналитику счетов и субсчетов.
2б. Вводятся корректировки в отражения данных по синтетическому субсчету.
4а. Документ не выводится на печать.
1а. Не настроена форма для печати. Бухгалтер обращается в ИТ-отдел, работники которого осуществляют нужные настройки системы.
1б. Проблема с оргтехникой. Бухгалтер выполняет устранение неполадок (кончилась бумага в лотке принтера, принтер не подключен к компьютеру и пр.). Если самостоятельно устранить неполадки не получается, бухгалтер обращается к сотрудникам ИТ-отдела.
2. Документ повторно выводится на печать.
Список технологий и типов данных:
1а. Параметры запроса: тип отчета (свернутый/развернутый), период, за который будет рассчитана реализованная продукция в натуральном и стоимостном выражениях, степень аналитики (по счету, по субсчету, в разрезе контрагентов, документов, строк документов) - выбираются вручную из выпадающих списков или справочников.
Специальные требования:
- Отклик системы (выполнение запроса) приходит в течение минуты.
- Быстрое восстановление информации в случае сбоя системы.
Частота использования: равна числу запросов в сутки + раз в четыре недели (по регламенту).
3.2.Объектно-ориентированное проектирование
Объектно-ориентированное проектирование (Object-Oriented Design - OOD) - это поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.
Процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:
- Определение классов и объектов на определенном уровне абстракции.
- Определение семантики классов.
- Определение (идентификация) связей между классами и объектами.
- Реализация классов.
На каждом повторении этого цикла уточняются описания классов и перерабатываются проектные документы.
3.2.1. Диаграмма концептуальных классов
Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке OCL (Object Constraints Language), который является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию. Мы затронем эту тему ниже немного более подробно.
Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника. У каждого класса должно иметься имя (текстовая строка), уникально отличающее его ото всех других классов. При формировании имен классов в UML допускается использование произвольной комбинации букв, цифр и даже знаков препинания. Однако на практике рекомендуется использовать в качестве имен классов короткие и осмысленные прилагательные и существительные, каждое из которых начинается с заглавной буквы.
Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута). Свойство, выражаемое атрибутом, является свойством моделируемой сущности, общим для всех объектов данного класса. Так что атрибут является абстракцией состояния объекта. Любой атрибут любого объекта класса должен иметь некоторое значение.
Имена атрибутов представляются в разделе класса, расположенном под именем класса. Хотя UML не накладывает ограничений на способы формирования имен атрибутов (имя атрибута может быть произвольной текстовой строкой), на практике рекомендуется использовать короткие прилагательные и существительные, смысл которых соответствует смыслу соответствующего свойства класса. Первое слово в имени атрибута рекомендуется писать с прописной буквы, а все остальные слова – с заглавной буквы.
Операцией класса называется именованная услуга, которую можно запросить у любого объекта этого класса. Операция – это абстракция того, что можно делать с объектом. Класс может содержать любое число операций (в частности, не содержать ни одной операции). Набор операций класса является общим для всех объектов данного класса.
Операции класса определяются в разделе, расположенном ниже раздела с атрибутами. При этом можно ограничиться только указанием имен операций, оставив более детальную спецификацию выполнения операций на поздние этапы моделирования. Для именования операций рекомендуется использовать глагольные обороты, соответствующие ожидаемому поведению объектов данного класса. Описание операции может также содержать ее сигнатуру, т.е. имена и типы всех параметров, а если операция является функцией, то и тип ее значения.
В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоцирование (association). Для проектирования реляционных БД наиболее важны вторая и третья категории связей. Поэтому по поводу связей-зависимостей мы будет очень кратки.
Связи-зависимости
Зависимостью называют связь по использованию, когда изменение в спецификации одного класса может повлиять на поведение другого, использующего первый класса. Чаще всего зависимости применяются в диаграммах классов, чтобы отразить в сигнатуре операции одного класса тот факт, что параметром этой операции могут быть объекты другого класса. Понятно, что если интерфейс этого второго класса изменяется, то это влияет на поведение объектов первого класса. Зависимость показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость.
Связи-обобщения
Связью-обобщением называется связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями “is a”, имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.
Объекты класса-потомка могут использоваться везде, где могут использоваться объекты класса-предка. Это свойство называют полиморфизмом по включению, имея в виду, что объекты потомка можно считать включаемыми в класс-предок. Графически обобщения изображаются в виде сплошной линии с большой незакрашенной стрелкой, направленной к суперклассу.
Связи-ассоциации
Ассоциацией называется структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Допускается, чтобы оба конца ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями). Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.
Рис.3 Диаграмма концептуальных классов
3.2.2. Диаграмма программных классов
Диаграмма программных классов является расширением диаграммы концептуальных классов.
Рис.4 Диаграмма программных классов
3.2.3. Диаграмма последовательности
Для моделирования взаимодействия объектов во времени в языке UML используется диаграмма последовательности - диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления
На диаграмме последовательности изображаются только те объекты, которые непосредственно участвуют во взаимодействии. Ключевым моментом для диаграмм последовательности является динамика взаимодействия объектов во времени.
Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо.
Рис.5 Диаграмма последовательности
3.3. Проектирование схемы базы данных
Приложения баз данных - одни из самых распространенных программных систем. Электронная форма хранения данных, учет и обработка различной информации стали неотъемлемой частью бизнеса, делопроизводства, библиотечного, музейного дела и т. д. Данные в таких системах хранятся по многу лет, активно используются и изменяются.
История систем автоматизации проектирования баз данных (CASE-средств) начиналась с автоматизации процесса рисования диаграмм, проверки их формальной корректности, обеспечения средств долговременного хранения диаграмм и другой проектной документации. Конечно, компьютерная поддержка работы с диаграммами очень полезна для проектировщика БД. Наличие электронного архива проектной документации помогает при эксплуатации, администрировании и сопровождении базы данных.
Диаграммы классов UML включают в себя, как частный случай, диаграммы "сущность-связь" (ER-диаграммы), которые часто используются для логического проектирования баз данных.
В процессе проектирования схему данных удобно представлять с помощью следующих моделей (см. рис. 8.2):
- концептуальная модель служит средством для извлечения знаний о предметной области, то есть для работы с экспертами, пользователями, заказчиками; эта модель помогает программистам разобраться с той сферой человеческой деятельности, для которой им предстоит создать свое программное приложение, выявив там основные сущности и связи между ними; поскольку концептуальная модель предназначена для обсуждения с непрограммистами, то она не должна содержать конструкций и понятий, которых последним не воспринять;
- логическая модель позволяет полностью задать структуру данных, однако без "привязки" к конкретной платформе реализации; с одной стороны, такое описание получается компактнее, чем физическая модель, позволяя взглянуть на схему данных в целом, без лишних деталей; с другой стороны, такая спецификация может быть в дальнейшем реализована для разных СУБД; логическая модель содержит абстракции, которые уже могут быть непонятны экспертам предметной области - эта модель служит для уточнения информации о предметной области в виде, удобном для последующей реализации;
- физическая модель является описанием структуры данных в терминах платформы реализации - конкретной СУБД; эта модель уже содержит информацию о различных деталях реализации - индексах и ключах, типах атрибутов и т.д., которые определены в терминах целевого языка программирования и т. д.; физическая модель фактически является диаграммным представлением части программного кода, определяющего схему данных.
Рис.6 Схема базы данных
Заключение
В настоящее время в России резко возрос интерес к общепринятым на Западе стандартам менеджмента, однако, в реальной практике управления существует один очень показательный момент. Многих руководителей до сих пор можно поставить в тупик прямым вопросом об организационной структуре компании или о схеме существующих бизнес-процессов.
В курсовой работе была разработана проектная документация на примере проекта создания системы «Учет расчетов с покупателями». Без графического представления сути какого либо действия, которое бы обеспечивает максимальное визуальное восприятие и понимание сути процесса от рядового менеджера до генерального директора и максимальную информативность о компонентах процессов (механизмах (участниках), ресурсах, расходных материалах, информации, документах), любое описание процесса обречено на неудачу.
В результате были смоделированы бизнес-процессы, сформулированы требования к программному продукту, основанные на прецедентах, описаны различные виды архитектуры системы. Адекватные, понятные модели дают возможность анализировать последствия изменений в управлении, улучшать основные показатели деятельности организации путем моделирования и перепроектирования существующих бизнес-процессов.
Список литературы
1. Моделирование бизнеса: средства и методы, Чеботарева В.
2. CASE-технологии. Современные методы и средства проектирования информационных систем, Вендров А.М.
3. CASE-технологии: практическая работа в Rational Rose, Трофимов С.А.
4. http://www.interface.ru/ca/bpwin.htm - описание bpwin.
5. http://www.citforum.ru/
6. http://www.intuit.ru/
7. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование, 2-е издание, Джим Арлоу, Айла Нейштадт
Приложение
Схема декомпозиции:
