Диаграмма последовательности (Sequence Diagram)

К У Р С О В А Я Р А Б О Т А

по дисциплине: Участие в интеграции программных модулей

 

на тему: Разработка системы закупок компьютерных комплектующих

 

 

Выполнил: студент 4 курса группы

Специальность: Программирование в компьютерных системах

                                                                                      Гусева

                            Дмитрия

                                                                                           Игоревича

                                                                                       (ФИО полностью)

 

   Руководитель                                                                                      Круглов__А.А.

                  (ФИО, ученая степень, звание)

 

Отметка о допуске (не допуске) к защите_____________

 

«____»________2015г.            ___________________

                                                                             (подпись руководителя)

 

Дмитров, 2015

ОГЛАВЛЕНИЕ

Оглавление

Введение. 3

Диаграммы DFD.. 3

Диаграммы IDEF0. 3

Диаграммы UML. 3

Class diagram Диаграмма классов. 3

Описание интерфейса разрабатываемой системы. 3

Функциональность: 3

Заключение. 3

Список литературы.. 3

 

Введение

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

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

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

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

Цель проекта

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

· Выявление метода премирования сотрудников больницы

· Определение функционала системы

· Проектирование системы используя язык UML

· Разработка интерфейса

Исходные данные

Существует готовая БД премирования сотрудников больницы. Также есть в наличии программное обеспечение такое как:

· BP Win;

· Microsoft;

· Visio;

· StarUML;

 Ожидаемый результат .

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

 

Диаграммы DFD

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях, смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации, по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).

Кроме того, нотация DFD поддерживает понятие подсистемы — структурного компонента разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, Диаграмма вариантов использования.

External Entity (внешняя сущность) представляет собой материальный предмет или физическое лицо, являющиеся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рис. 1), расположенным как бы «над» диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.

Process (системы и подсистемы) — при построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т. д.

 

Диаграммы IDEF0

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).

Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны:

· стрелка входа приходит всегда в левую кромку активности,

· стрелка управления — в верхнюю кромку,

· стрелка механизма — нижняя кромка,

· стрелка выхода — правая кромка.

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

Также отображаются все сигналы управления, которые на DFD (диаграмме потоков данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

 

 

Диаграммы

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

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

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

Вариант использования ( USE CASE )

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

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

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

Включение указывает, что вариант использования встраивается в другой вариант использования. В данном примере вариант использования Part включается в вариант использования Base. Добавление указывает, что в определённых ситуациях или в некоторой точке (называемой точкой расширения) вариант использования будет расширен другим. В данном примере вариант использования Base расширяется вариантом использования Another.

Обобщение указывает, что вариант использования наследует характеристики «родительского» варианта использования и может переопределить некоторые из них или добавить новые, подобно наследованию в классах. В данном примере вариант использования Child обобщает вариант использования Base.

Действующее лицо (actor)

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

Действующие лица представляют не физических людей или системы, а их роли. Эти означает, что когда человек взаимодействует с системой различными способами (предполагая различные роли), он отображается несколькими действующими лицами. Например, человек, работающий в службе поддержки и принимающий от клиентов заказы, будет отображаться в системе как «участник отдела поддержки» и «участник отдела продаж».

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

Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования.

Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

Описание варианта использования

Описания вариантов использования являются текстовыми пояснениями. Они обычно принимают форму заметки или документа, который каким-то образом прикрепляется к варианту использования и описывает процесс или активность.
Диаграмма деятельности (ACTIVITY DIAGRAM)

Диаграмма деятельности (англ. activity diagram) — UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. Action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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

    Диаграммы деятельности состоят из ограниченного количества фигур, соединённых стрелками. Основные фигуры:

· Прямоугольники с закруглениями — действия

· Ромбы — решения

· Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий

· Чёрный круг — начало процесса (начальное состояние)

· Чёрный круг с обводкой — окончание процесса (конечное состояние)

· Стрелки идут от начала к концу процесса и показывают последовательность переходов.

Линия жизни (Life Line)

Линия, идущая вниз от участника, обозначающая отведенное объекту время жизни. Обозначается пунктирной линией.

Уничтожение объекта

 

Обозначается диагональным крестом на линии жизни. Обозначает конец жизни объекта.

 Диаграмма классов (CLASS DIAGRAM)

 

Диаграмма классов (англ. Static Structure diagram) — диаграмма, демонстрирующая классы системы,их атрибуты, методы и взаимосвязи между ними. Входит в UML.

Существует два вида:

Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;

Аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов, входящих в систему.

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

Концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

Точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

Точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Взаимосвязи

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

Ассоциации

Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности.

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

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

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

Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде. Указывая кратность на одном конце ассоциации, вы тем самым говорите, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), можно указать диапазон: "ноль или единица" (0..1), "много" (0..*), "единица или больше" (1..*). Разрешается также указывать определенное число (например, 3). С помощью списка можно задать и более сложные кратности, например 0 . . 1, 3..4, 6..*, что означает "любое число объектов, кроме 2 и 5".

Агрегация

Агрегация. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого".

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

Композиция

Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.

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

Графически представляется как и агрегация, но с закрашенным ромбиком.

Обобщение (наследование)

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

Обобщение (Generalization) показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называется обобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Например: животные — супертип млекопитающих, которые, в свою очередь, — супертип приматов, и так далее. Эта взаимосвязь легче всего описывается фразой «А — это Б» (приматы — это млекопитающие, млекопитающие — это животные).

Графически обобщение представляется линией с пустым треугольником у супертипа.

Обобщение также известно как наследование или «is a» взаимосвязь (или отношение "является").

Реализация

Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.

Зависимость

Зависимость (dependency) — это слабая форма отношения использования, при котором изменение в спецификации одного влечёт за собой изменение другого, причём обратное не обязательно. Возникает, когда объект выступает, например, в форме параметра или локальной переменной.

Графически представляется штриховой стрелкой, идущей от зависимого элемента к тому, от которого он зависит.

Существует несколько именованных вариантов.

Зависимость может быть между экземплярами, классами или экземпляром и классом.

Уточнения отношений

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

Мощность отношений (Кратность)

Мощность отношения (мультипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в её конце. Различают следующие типичные случаи:

 

Таблица 1

нотация	объяснение	пример
0..1	Ноль или один экземпляр	кошка имеет или не имеет хозяина
1	Обязательно один экземпляр	у кошки одна мать
0..* или *	Ноль или более экземпляров	у кошки может быть, а может и не быть котят
1..*	Один или более экземпляров	у кошки есть хотя бы одно место, где она спит

 

 

ПК - компьютеры, с помощью которых ведется учёт.

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

 

Statechart

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

 

Erd-диаграмма

При создании моделей данных используется метод семантического моделирования. Семантическое моделирование основывается на значении структурных компонентов или характеристик данных, что способствует правильности их интерпретации (понимания, разъяснения). В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship) — ERD.

Существуют различные варианты отображения ERD, но все варианты диаграмм сущность-связь исходят из одной идеи — рисунок всегда нагляднее текстового описания. ER -диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

Базовые понятия ERD

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

Можно сказать, что Сущности представляют собой множество реальных или абстрактных вещей (людей, объектов, событий, идей и т. д.), которые имеют общие атрибуты или характеристики.

Экземпляр сущности (запись, кортеж)- это конкретный представитель данной сущности.

Атрибут сущности (поле, домен) — это именованная характеристика, являющаяся некоторым свойством сущности.

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

Каждая связь может иметь один из следующих типов связи:

Один-к-одному, многое-ко-многим, один-ко-многим.

Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности(правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») — дочерней.

 

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

 

Рисунок 1 IDFO-1

 

 

 

Рисунок 2 IDFO-1

 

 

Рисунок 3 IDFO-2

 

 

Рисунок 4 IDFO-2

 

 

Рисунок 5 IDF0-3

 

 

Рисунок 6 IDF0-3

Рисунок 7 DFD-1

 

Рисунок 8 DFD-2

 

Рисунок 9 USE CASE

 

Рисунок 10 ACTIVITY

 

Рисунок 11 SEQUENCE

.

 

Рисунок 12 STATECHART

 

Рисунок 13 CLASS

 

 

Рисунок 14 ERD

 

Заключение.

 

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

 

 

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

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

 

 

Список литературы

 

1. Грачев, А. Создаем свой сайт на WorldPress : работа с CMS WorldPress 3 / А. Грачев. - Санкт-Петербург [и др.] : Питер, 2011. - 282 с.

 

2. Вин, Ч. Как спроектировать современный сайт : профессиональный веб-дизайн на основе сетки / Ч. Вин. - Москва [и др.] : Питер, 2011. - 192 с.

3.

4. Никсон, Р. Создаем динамические веб-сайты с помощью PHP, MySQL и JavaScript / Р. Никсон ; [пер. с англ. Н. Вильчинский]. - Санкт-Петербург [и др.] : Питер, 2013. - 496 с.

5.

6. Профессиональная разработка сайтов на Drupal 7 / Б. Мелансон [и др.; пер. с англ. И. Размайкина]. - Москва [и др.] : Питер, 2013. - 687 с.

 

7. Халворсон, К. Контентная стратегия управления сайтом / К. Халворсон, М. Рэч ; [пер. с англ. Е. Матвеева]. - 2-е изд. - Санкт-Петербург [и др.] : Питер, 2013. - 224 с.

 

8. Андерсон, С. Приманка для пользователей : создаем привлекательный сайт / С. Андерсон ; [пер. с англ. С. Силинский]. - Москва : Питер, 2013. - 234 с.

 

9. Фрэйн, Б. HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств / Б. Фрэйн ; [перевод с английского В. Черник]. - Санкт-Петербург [и др.] : Питер, 2014. - 298 с.

 

 

10. Титоров, Д. Ю. Технология создания интерактивных сайтов / Д. Ю. Титоров

11. // Информатика : [газ. Изд. дома "Первое сентября"]. - 2010. - № 3 (февр.). - С. 13-18.

12. О создании структуры сайта.

 

13. Хворостьянова, С. В. Веб-сайт: требования к информационной структуре и наполнению / С. В. Хворостьянова // Современная библиотека. - 2011. - № 1. - С. 68-73.

14. Требования к содержанию библиотечных веб-сайтов.

 

15. Суслова, О. А. Как создать качественный сайт учреждения культуры / О. А. Суслова // Справочник руководителя учреждения культуры. - 2011. - № 9. - С. 67-74.

16. Назначение сайта для каждого конкретного учреждения. Последовательность работы над сайтом. Правила составления технического задания на создание сайта.

 

17. Как сделать идеальный сайт // Фотомастерская. - 2012. - № 12. - С. 58-60.

18. Даются советы по созданию успешного сайта.

 

К У Р С О В А Я Р А Б О Т А

по дисциплине: Участие в интеграции программных модулей

 

на тему: Разработка системы закупок компьютерных комплектующих

 

 

Выполнил: студент 4 курса группы

Специальность: Программирование в компьютерных системах

                                                                                      Гусева

                            Дмитрия

                                                                                           Игоревича

                                                                                       (ФИО полностью)

 

   Руководитель                                                                                      Круглов__А.А.

                  (ФИО, ученая степень, звание)

 

Отметка о допуске (не допуске) к защите_____________

 

«____»________2015г.            ___________________

                                                                             (подпись руководителя)

 

Дмитров, 2015

ОГЛАВЛЕНИЕ

Оглавление

Введение. 3

Диаграммы DFD.. 3

Диаграммы IDEF0. 3

Диаграммы UML. 3

Class diagram Диаграмма классов. 3

Описание интерфейса разрабатываемой системы. 3

Функциональность: 3

Заключение. 3

Список литературы.. 3

 

Введение

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

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

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

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

Цель проекта

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

· Выявление метода премирования сотрудников больницы

· Определение функционала системы

· Проектирование системы используя язык UML

· Разработка интерфейса

Исходные данные

Существует готовая БД премирования сотрудников больницы. Также есть в наличии программное обеспечение такое как:

· BP Win;

· Microsoft;

· Visio;

· StarUML;

 Ожидаемый результат .

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

 

Диаграммы DFD

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях, смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации, по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).

Кроме того, нотация DFD поддерживает понятие подсистемы — структурного компонента разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, Диаграмма вариантов использования.

External Entity (внешняя сущность) представляет собой материальный предмет или физическое лицо, являющиеся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рис. 1), расположенным как бы «над» диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.

Process (системы и подсистемы) — при построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т. д.

 

Диаграммы IDEF0

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).

Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны:

· стрелка входа приходит всегда в левую кромку активности,

· стрелка управления — в верхнюю кромку,

· стрелка механизма — нижняя кромка,

· стрелка выхода — правая кромка.

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

Также отображаются все сигналы управления, которые на DFD (диаграмме потоков данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

 

 

Диаграммы

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

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

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

Вариант использования ( USE CASE )

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

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

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

Включение указывает, что вариант использования встраивается в другой вариант использования. В данном примере вариант использования Part включается в вариант использования Base. Добавление указывает, что в определённых ситуациях или в некоторой точке (называемой точкой расширения) вариант использования будет расширен другим. В данном примере вариант использования Base расширяется вариантом использования Another.

Обобщение указывает, что вариант использования наследует характеристики «родительского» варианта использования и может переопределить некоторые из них или добавить новые, подобно наследованию в классах. В данном примере вариант использования Child обобщает вариант использования Base.

Действующее лицо (actor)

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

Действующие лица представляют не физических людей или системы, а их роли. Эти означает, что когда человек взаимодействует с системой различными способами (предполагая различные роли), он отображается несколькими действующими лицами. Например, человек, работающий в службе поддержки и принимающий от клиентов заказы, будет отображаться в системе как «участник отдела поддержки» и «участник отдела продаж».

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

Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования.

Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

Описание варианта использования

Описания вариантов использования являются текстовыми пояснениями. Они обычно принимают форму заметки или документа, который каким-то образом прикрепляется к варианту использования и описывает процесс или активность.
Диаграмма деятельности (ACTIVITY DIAGRAM)

Диаграмма деятельности (англ. activity diagram) — UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. Action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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

    Диаграммы деятельности состоят из ограниченного количества фигур, соединённых стрелками. Основные фигуры:

· Прямоугольники с закруглениями — действия

· Ромбы — решения

· Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий

· Чёрный круг — начало процесса (начальное состояние)

· Чёрный круг с обводкой — окончание процесса (конечное состояние)

· Стрелки идут от начала к концу процесса и показывают последовательность переходов.

Диаграмма последовательности (Sequence Diagram)

Удобное средство для обозначения очередности следования друг за другом различных стимулов (сообщений), с помощью которых объекты взаимодействуют между собой.

Например, когда нужно проработать буквально по шагам какой-то очень важный участок выполнения программы.

Главный акцент - порядок и динамика поведения, т.е. как и в каком порядке происходят события.

Отличие от диаграммы классов:

Диаграмма классов дает статическую картинку, т.е. описание которое не меняется во время выполнения программы.

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

Обычно нормальные люди стараются описывать одной диаграммой только один определенный кейс (UseCase, вариант использования), например: "оставить коммент к сообщению в блоге", "стать постоянным читателем" и т.д...

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

Итак, предлагаю рассмотреть простенькую диаграмму последовательности.

Возьмем банальный пример:

Эта диаграмма показывает как приготовить яичницу.

Когда мы смотрим на такую диаграмму последовательности, мы сразу понимаем что:

· нужно не забыть включить плиту

·  перед жаркой нужно хорошо разогреть масло

·  первым нужно положить масло, а потом яйца, а не наоборот.

·  cоль можно добавить асинхронно, в процессе жарки.

Разберем каждый элемент диаграммы, по отдельности:

123Следующая ⇒

Поделиться: