Разработка и стандартизация программных средств

Содержание:

 

1.Разработка  моделей бизнес процессов……………………………….............. 2

    1.1.Разработка целей бизнес процессов…………………………………. …..2

    1.2.Изображение бизнес процессов…………………………………………..3

2.Построение  модели потока работ бизнес  процессов в EA…………………...4

     2.1.Построение диаграммы отображающей основные виды деятельности..4

    2.2. Построение диаграммы детализирующих основные виды

       деятельности……………………………………………………………........ 5

     2.3. Построение ссылки из диаграммы процессов на диаграмму потоков

       работ……………………………………………………………………...........6

3.Создание  моделей сущностей, ролей и  правил в среде ЕА ………………….7

    3.1.Разрабатывать  модели бизнес сущностей и  их состояний………………7

    3.2. Разрабатывать модели ролей бизнес процессов и их автоматизируемых

           видов  деятельности…………………………………………………….....8

4.Создание  диаграммы функции системы……………………………………..12

5.Создание  диаграммы последовательности…………………………………..14

6.Создание  интерфейса………………………………………………………….15

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

 

 

 

 

1.Разрабатка моделей бизнес процессов

1.1. Разработка целей бизнес процессов.

 

Целью модели «Цели системы» является отображение требуемых значений технических, технологических, производственно-экономических  или других показателей объекта  автоматизации, которые должны быть достигнуты в результате создания автоматизированной системы (АС).

Для разработки модели «Цели системы» используется диаграмма классов (class diagram или custom diagram).

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

 

 

 

Рисунок 1. Цели системы

 

 

 

 

1.2. Изображение бизнес процессов

 

Модель бизнес процессов строится как иерархия диаграмм в пакете «Бизнес процессы». Пакет «Бизнес процессы» должен считаться моделью первого уровня.

На последнем уровне иерархии модели бизнес процессов должны быть представлены изображения бизнес процессов, ролей, целей. Для отображения связи между ролью и бизнес процессом используется связь ассоциация (Associaton). Связь между бизнес процессом и целью должна отображаться с использованием связи зависимость (Dependency) со стереотипом поддерживает. Данный вид связи выбираем на панели Toolbox в закладке Custom

 

 

 

 

Рисунок 2 . Пример диаграммы функций с изображением процесса ведения автоматизированного учета видеопроката.

 

 

 

 

 

 

 

 

2. Построение модели потока работ бизнес процессов в EA.

2.1. Построение диаграммы, отображающей основные виды деятельности.

 

Для разработки модели потока работ или, модели описания бизнес процессов используется диаграмма деятельности языка UML (activity diagram).

При построении модели потока работ используется нотация  диаграммы деятельности (activity diagram), поддерживаемая EA.

Диаграмма деятельности (activity diagram) должна иметь  только одно начальное состояние. Конечных же состояний может существовать множество.

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

 

 

 

 

Рисунок 3. Макрошаги  процесса ведения автоматизированного  учета видеопроката

 

2.2. Построение диаграммы детализирующих основные виды деятельности

 

Диаграмма деятельности (activity diagram) с  детальным описанием каждого  основного шага процесса строится как  поддиаграмма соответствующего основного  шага. На рисунке 4 показано, что в окне просмотра элементов модели в Enterprise Architect диаграмма деятельности (activity diagram), отображающая детальное описание основного шага процесса «Предварительное ознакомление с клиентом», находиться под соответствующим шагом «Предварительное ознакомление ». Деятельности на этой диаграмме, которые подлежат автоматизации, отмечены красным цветом.

 

 

Рисунок 4. Пример изображения диаграммы с детальным описанием шага Предварительное ознакомление с клиентом в Enterprise Architect

 

 

 

 

 

 

 

 

 

 

2.3.Построение ссылки из диаграммы процессов на диаграмму потока работ.

Для построения ссылки на диаграмму деятельности (activity diagram) с изображением основных шагов  бизнес процесса следует курсором мыши выбрать диаграмму в окне Project View Кредитования юридических лиц в валюте и перетащить ее на диаграмму функций (use case diagram) рядом с изображением бизнес процесса.

 

 

 

 

Рисунок 5. Пример диаграммы функций с изображением процесса ведения автоматизированного учета видеопроката и ссылкой на диаграмму деятельности

 

 

 

 

 

 

 

 

 

 

 

3. Создание моделей сущностей, ролей и правил в среде Enterprise Architect

3.1. Разработать модели бизнес сущностей и их состояний

 

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

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

 

 

Рисунок 6. Пример модели «Заявка клиента»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.2. Разработать модели ролей бизнес процесса и их автоматизируемых видов деятельности.

 

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

Для разработки модели ролей и их автоматизируемых функций  в Enterprise Architect следует использовать диаграмму классов (class diagram) или диаграмму функций (use case diagram). Роль представляет абстракцию субъектов и объектов, участвующих в бизнес процессе. Примерами ролей могут являться клиент, продавец, банк и т.д.

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

Связь между  ролью и функцией может иметь  стереотип, например, «communicates» (взаимодействует).

Между функцией и сущностью также устанавливается  связь «ассоциация». Сущность, которая является для данной функции входной, соединяется с функцией связью «ассоциация», имеющей направление от сущности к функции. Сущность, которая является для данной функции выходной, соединяется с функцией  связью «ассоциация», имеющей направление от функции к сущности (рисунок 7).

 

Рисунок 7.Связь  между ролью, функцией и сущностями

Между ролями может существовать связь  «наследование». Наследование (generalization) между бизнес ролями это такое отношение, когда одна роль имеет все функции другой роли (одиночное наследование) или других ролей (множественное наследование) и возможно другие функции специфические для данной роли. Пример связи наследования представлен на рисунке 8

 

 

 

Рисунок 8. Связь  наследования между бизнес работниками

 

Иерархия  пакетов с описанием ролей  должна повторять иерархию бизнес процессов.

На предпоследнем уровне иерархии следует размещать пакеты с наименованием  ролей по конкретному процессу и на самом последнем уровне собственно модель роли.

 

 

Рисунок 9. Модель роли по поиску фильмов

 

 

3.3.Разработать  модели бизнес правил

 

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

В общем  случае бизнес правила можно разделить  на три группы:

• правила – ограничения;
• правила – выводы;
• правила – утверждения.

Правила – ограничения определяют условия  поведения и структуру объекта  или субъекта.

Правила – выводы определяют условия вывода фактов на основе других фактов или  вычисления результатов на основе других результатов.

Правила – утверждения определяют определенные факты.

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

Каждому правилу должна быть поставлена в  соответствие одна диаграмма деятельности (activity diagram). На поле диаграммы деятельности (activity diagram), описывающей правило, указывается его название.

Диаграмма деятельности (activity diagram), описывающая  правило, должна иметь начало и конец.

Наименование  элементов диаграммы деятельность (activity diagram) должно отображать суть описываемых  частей правил.

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

• разработку моделей бизнес правил;
• построение ссылки из диаграммы процессов на диаграмму бизнес правил.

 

 

Рисунок 10. Модель правила возврата продукции

 

 

 

4.Создание  диаграммы функций системы.

 

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

В диаграммах Use Case используются отношения показанные в таблице 2.

 

Отношения	Функции	Обозначение
ассоциация	Связь между пользователем и Use Case, в котором он участвует
расширение	Включение дополнительного поведения в базовый Use Case
обобщение	Отношения между главным Use Case и более специфичным Use Case, который наследует и добавляет описание к нему
включение	Вставка дополнительного поведения  в базовый Use Case, который явно описывает вставку

 

Таблица 1. Отношения используемые в диаграммах Use Case.

 

Рисунок 11.  Диаграмма функций  системы

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

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

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

 

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

 

 

 

 

 

 

 

 

 

 

 

6. Создание интерфейса

 

EA поддерживает создание пользовательских  экранов интерфейса. Ниже приведены  примеры на диаграммах классов, где определены дизайны пользовательских интерфейсов для системы в стадии разработки (рисунок 13,14,15,16,17). Для создания экранной формы необходимо выбрать в Toolbox закладку User Interface. В нем выберите элемент Screen для создания экранной формы, и элемент GUI Element для создания остальных элементов формы как показано на рисунках.

 

 

Рисунок 13. Главное  меню

 

Рисунок 14. Выбор  жанра

Рисунок 15.Выбор  актера

 

 

 

Рисунок 16.Выбор  режиссера

 

Рисунок 17. Выбор  сериала

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

1. Карл Вигерс. Разработка требований к программному обеспечению. М.: Издательско-торговый дом «Русская Редакция», 2004. – 576.
2. ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла программных средств.
3. ГОСТ 28195-89 Оценка качества программных средств.
4. ГОСТИСО/МЭК9126-93 
   Оценка программной продукции. Характеристики качества и руководства по их применению.