6. периодичность управления (ПУ) – раз/время.

       Расчет  производиться по следующей формуле 

       СФ = СМ * ВФ * ПФ + СУ * ПУ * ВФ.

       Управление  у нас является отдельным блоком. Его стоимость посчитаем отдельно. Поэтому расчет будем проводить по формуле СФ = СМ * ВФ * ПФ.

       0. Спроектировать схему программы:

       2210+9600+2880=14690 р в месяц

       1. Подготовить условия для создания схемы:

       240+1920+50= 2210 р в месяц

       11. Согласовать с заказчиком условия создания схемы:

       60 р/час*2часа* 2раз/месяц=240 р в месяц

       12. Найти программные средства для создания схемы:

                   120р/час*2 дня*1 раз/месяц=1920 р в месяц

       13. Определить вид схемы:

       50р/час*1 час*1 раз/месяц= 50 р в месяц

       2. Разработать структуру схемы:

                   120р/час*2 недели *1 раз/месяц= 9600 р в месяц

       3. Редактировать схему:

                   120р/час*1 день*3 раз/месяц=2880 р в месяц 

       Функционально-стоимостной  анализ (ФСА, Activity Based Costing, АВС) - это технология, позволяющая оценить реальную стоимость продукта или услуги безотносительно к организационной структуре компании.[3]

       По  существу, метод ФСА работает по следующему алгоритму:

1. определяется последовательность функций, необходимых для производства товара или услуги;

2. для каждой функции определяются полные годовые затраты и количество рабочих часов;

3. для каждой функции на основе оценок из пункта 2 определяется количественная характеристика источника издержек;
4. после того как для всех функций будут определены их источники издержек, проводится окончательный расчет затрат на производство конкретного продукта или услуги.

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

       Следующим этапом проектирования системы является построение DFD диаграммы.

       3.3 Диаграмма потоков данных

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

       В данной системе с помощью DFD диаграммы были выявлены связи между некоторыми классами. Было выявлено, что схема доступная для редактирования может проверяться на любом этапе ее проектирования. Таким образом, процедура проверки корректности схем была встроена в класс окна ответственного за редактирование схемы. Было выявлено, что схемы нужно сохранять для последующего редактирования или в файл .jpg. Таким образом, мы выяснили, что вся схема должна быть сохранена в формат, отрывая который можно восстановить схему полностью. На основе полученного требования было принято решение использовать сериализацию объектов, т.е. сохранения всех объектов схемы и их состояний на жесткий диск. Для этого был выбран класс XmlSerializer, который позволяет сохранять состояние объектов в формате XML и затем восстанавливать объекты из этого формата. Для сохранения в .jpg была использована стандартная процедура сохранения изображения в файл. 

     DFD диаграмма представлена на рис. 3.8.

       Рисунок 3.8 – Уровень А0 DFD-диаграммы. 

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

       3.4 Диаграмма прецедентов

       Диаграммы прецедентов представляют собой  один из пяти типов диаграмм, применяемых  в UML для моделирования динамических аспектов системы[4]. Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.

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

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

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

       

       Рисунок 3.9 – Диаграмма прецедентов

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

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

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

       Диаграмма взаимодействия отражает поток событий, происходящих в рамках варианта использования. В верхней части диаграммы показаны действующие лица и объекты, требуемые системе для выполнения варианта использования[5].Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций, связь между ними изображена во времени, т.е. последовательно. Следует отметить, что на диаграмме взаимодействия показаны именно объекты, а не классы. Классы представляют собой типы объектов.

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

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

Рисунок 3.10 – Диаграмма последовательностей 

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

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

     3.6 Диаграмма классов

       Диаграмма классов отражает взаимодействие между  классами системы. Классы можно рассматривать как типы объектов[5]. Классы содержат данные и действия, влияющие на эти данные. На диаграмме изображают связи между классами, реализующие варианты использования. Каждый класс на диаграмме изображается в виде прямоугольника, в котором указывают имя класса, его атрибуты (некоторая информация, характеризующая класс) и операции (действия), выполняемые классом.

       Диаграмма классов приведена на рис. 3.11.

Рисунок 3.11 – Диаграмма классов 

       В данной диаграмме классов не отображены все блоки присутствующие в программе. Класс «Блок определенного типа» представляет любой блок существующий в программе, т.к. все блоки отличаются друг от друга только процедурой отрисовки а все остальные поля и методы они копируют у порождающего их класса «Шаблон блока».

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

       Ниже  приведены интерфейсы классов представленных на диаграмме классов:

       Интерфейс класса Конфигурация Схемы

            public class Configuration

            {

                public List<BlockTemplate> shapes;

                public List<ArrowTemplate> arrows; 

                   public void Save(string fileName);

 public void Open(string fileName);          

       public void Restore();

            }

       Интерфейс класса Шаблон Стрелки

       public abstract class ArrowTemplate

       {      

               public bool isChangeable = false;

               public bool isMovable = false;   

               public bool needEndCap = true;

               public bool needStartCap = false;

               public bool isDashed = false;

               public int thickness = 1;

               public BlockTemplate blockConnectedToFirstNode = null;

               public BlockTemplate blockConnectedToLastNode = null;

               public int slotNumConnectedToFirstNode = -1;

               public int slotNumConnectedToLastNode = -1;

               public ArrowNodePoint[] nodes;

             public Point[] points;

               protected Pen arrowPen;

               protected Pen selectedArrowPen;

               public ArrowTemplate(int thickness)

               public void findNearestBlockToConnectToNode(List<BlockTemplate> blocks, int nodeNum)

              public void deteteConnectionWithBlock()

               public abstract void moveNode(int dx, int dy, int nodeNumber);

               public abstract void arrangeMiddleNodes();

               public abstract bool pointInside(int x, int y);

               public abstract void draw(Graphics g);

               public void moveArrow(int dx, int dy)

               public void changeLineThickness(int thickness)

               public void changeStyle_DashedOrRegular(bool dashed)

               public void changeArrowEndCap(bool endCap, bool startCap)

               public bool arrowInsideRect(int x, int y, int width, int height)    

           }

       Интерфейс класса Шаблон Блока