Процессный подход к проектированию

Недостатки структурного подхода:

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

· отсутствие целостного описания технологий выполнения работы, в лучшем случае существует только фрагментарная (на уровне структурных элементов), и то не совсем актуальная документируемость технологий;

· отсутствие ответственного за конечный результат и контроль над технологией в целом, а также ориентации на клиента (внешнего или внутреннего);

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

· неэффективность информационной поддержки, обусловленная наличием «лоскутной» автоматизации деятельности отдельных структурных элементов и неудачными попытками внедрения на предприятиях информационных систем.

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

Процессный подход дает возможность:

· ориентировать деятельность предприятия на бизнес-процессы;

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

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

Стандарт UML и его возможности (визуализации, специфицирования, конструирования, документирования).

Унифицированный язык визуального моделирования UML - стандарт, принятый консорциумом OMG, 1997г.UML является стандартным средством для составления «чертежей» программного обеспечения.

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

UML - это язык конструирования. UML не является языком визуального программирования, но модели UML, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. UML-модель можно отобразить с использованием языков Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных.

UML - это язык документирования. UML помимо исполняемого программного кода позволяет получать:

· требования к системе;

· архитектуру,

· проект,

· исходный код,

· планы проекта,

· тесты,

· прототипы,

· версии и др.

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

Области использования UML:

· информационные системы масштаба предприятия;

· банковские и финансовые услуги,

· телекоммуникации;

· транспорт;

· оборонная промышленность, авиация и космонавтика,

· розничная торговля;

· медицинская электроника;

· наука,

· распределенные Web-системы

Концептуальная модель UML и ее содержание

Основные типы сущностей:

· Структурные - статические элементы модели, соответствующие концептуальным или физическим элементам системы: классы, интерфейсы, кооперации, прецеденты, компоненты, узлы;

· Поведенческие - динамические составляющие модели: взаимодействия и автоматы;

· Группирующие - организующие элементы модели - пакеты;

· Аннотационные - пояснительные части модели - примечания

Структурные сущности:

· Класс (Class) – описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой

· Интерфейс (Interface) – совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или его компонентом.

· Кооперация (Collaboration) – определяет взаимодействие; она представляет собой совокупность ролей и других элементов, которые производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых.

· Прецедент (Use case) – описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного действующего лица / актера (Actor). Прецеденты реализуются посредством кооперации. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя.

· Активный класс (Active class) - класс, объекты ко­торого вовлечены в один или несколько процессов, или нитей (Threads), могут инициировать управляющее воздей­ствие. Его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов;

· Компонент (Component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию;

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

Поведенческие сущности:

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

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

Группирующие сущности:

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

Аннотационные сущности:

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

Типы отношений:

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

· Ассоциация – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами. Разновидностью ассоциации является агрегирование – так называют структурное отношение – между целым и его частями. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например, кратность и имена ролей.

· Обобщение – отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок наследует структуру и поведение своего родителя. Графически отношение обобщения изображается в виде линии с не закрашенной стрелкой, указывающей на родителя.

· Реализация – это семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение. Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с не закрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости.

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

Типы диаграмм в UML:

· диаграммы классов;

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

· диаграммы объектов;

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

· диаграммы прецедентов;

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

· диаграммы последовательностей,

· диаграммы кооперации;

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

· диаграммы состояний;

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

· диаграммы действий,

o Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.

· диаграммы компонентов,

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

· диаграммы развертывания.

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

Основные виды графических конструкций в UML:

· Значки или пиктограммы.

· Графические символы на плоскости.

· Пути.

· Строки текста.