Описание унифицированного процесса разработки программного обеспечения

         2. После устранения ошибки заново выполняется запрос на формирование отчета.

     3а.  Отчет сформирован с ошибкой.

1. Бухгалтер проверяет правильность отображения первичной информации в системе.

             2а. Вводятся корректировки в аналитику счетов и субсчетов.

             2б. Вводятся корректировки в отражения данных по синтетическому субсчету.

     4а.  Документ не выводится на печать.

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

         1б. Проблема с оргтехникой. Бухгалтер выполняет устранение неполадок (кончилась бумага в лотке принтера, принтер не подключен к компьютеру и пр.). Если самостоятельно устранить неполадки не получается, бухгалтер обращается к сотрудникам ИТ-отдела.

         2. Документ повторно  выводится на печать.

     Список  технологий и типов  данных:

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

     Специальные требования:

     - Отклик системы (выполнение запроса)  приходит в течение минуты.

     - Быстрое восстановление информации в случае сбоя системы.

     Частота использования: равна числу запросов в сутки + раз в четыре недели (по регламенту).

 

       3.2. Объектно-ориентированное  проектирование

     Объектно-ориентированное  проектирование (Object-Oriented Design - OOD) - это поступательный итеративный процесс. Построение проекта программного продукта состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование, по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.

     Процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:

     - определение классов и объектов  на определенном уровне абстракции.

     - Определение семантики классов.

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

     - Реализация классов.

     На  каждом повторении этого цикла уточняются описания классов и

перерабатываются  проектные документы. 

          3.2.1. Диаграмма концептуальных  классов

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

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

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

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

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

     Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями в языке UML являются:

     зависимости (dependency relationship);

     ассоциации (association relationship);

     обобщения (generalization relationship).

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

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

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

     Хорошо  структурированная диаграмма классов обладает следующими свойствами:

     - заостряет внимание только на  одном аспекте статического вида  системы с точки зрения проектирования;

     - содержит лишь элементы, существенные  для понимания данного аспекта;

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

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

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

     - диаграмме дается имя, связанное  с ее назначением;

     - элементы располагаются так, чтобы  свести к минимуму число пересекающихся  линий;

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

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

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

     Диаграмма концептуальных классов представлена на Рисунке 4. 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Рис. 4. Диаграмма концептуальных классов.

 

     

          3.2.2. Диаграмма программных классов

      Диаграмма программных классов (Рис. 5) является расширением диаграммы концептуальных классов. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Рис. 5. Диаграмма программных классов

 

     

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

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

 
 

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

 

3.3. Проектирование схемы  базы данных

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

     Логическая  схема базы данных описывает словарь хранимых данных системы, а также семантику связей между ними. Физически все это хранится в базе данных - реляционной, объектно-ориентированной или гибридной объектно-реляционной. UML пригоден для моделирования физических баз данных, равно как и их логических схем.

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

     Моделирование схемы БД производится следующим образом:

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

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

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

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

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

     6) В своей работе следует использовать инструментальные средства, позволяющие

преобразовать логический проект в физический.

      Схема базы данных представлена на Рисунке 7: