Недостатки структурного подхода:
· разбиение технологий выполнения работы на отдельные, как правило, не связанные между собой фрагменты, которые выполняются различными элементами организационной структуры;
· отсутствие целостного описания технологий выполнения работы, в лучшем случае существует только фрагментарная (на уровне структурных элементов), и то не совсем актуальная документируемость технологий;
· отсутствие ответственного за конечный результат и контроль над технологией в целом, а также ориентации на клиента (внешнего или внутреннего);
· отсутствие ориентации на внешнего клиента, а также внутренних потребителей промежуточных результатов деятельности;
· неэффективность информационной поддержки, обусловленная наличием «лоскутной» автоматизации деятельности отдельных структурных элементов и неудачными попытками внедрения на предприятиях информационных систем.
Процессный подход в отличие от структурного ориентирован не на организационную структуру предприятия, а на бизнес-процессы, конечными целями выполнения которых является создание продуктов или услуг, представляющих ценность для внешних или внутренних потребителей.
Процессный подход дает возможность:
· ориентировать деятельность предприятия на бизнес-процессы;
· создать систему управления предприятием каждым бизнес-процессом в отдельности и всеми бизнес-процессами компании в целом;
· создать систему качества предприятия в рамках существующей или перспективной организационно-штатной структуры и организационной культуры предприятия.
Стандарт 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:
· Значки или пиктограммы.
· Графические символы на плоскости.
· Пути.
· Строки текста.
