Пример: ООA, OOD и структуры хранения. Стек
Постановка задачи:
Необходимо разработать структуру хранения Стек.
Примечания:
- Не учитывать необходимость перераспределения памяти.
- Считать, что элементы целого типа.
Анализ и проектирование.
Данные:
- MemSize – максимальное количество элементов.
- DataCount – количество элементов в стеке.
- pMem – указатель на память для хранения значений.
Рис. 4 - Принцип организации стека
Операции:
- IsFull – проверка на полноту.
- IsEmpty – проверка на пустоту.
- Get – взять элемент с вершины.
- Put – положить элемент в стек.
Финальный результат нашего проектирования представлен на рис. 5 (используется нотация UML).
Рис. 5 - Разработанный класс для организации работы стека
Повторное использование
Идея повторного использования. Важность повторного использования
Повторное использование – применение уже существующих наработок в разрабатываемом ПО.
Повторное использование – важный элемент проектирования. Необходимо проектировать новые элементы системы с тем, чтобы их в последствии можно было применять при разработке других систем. Кроме того, при проектировании системы необходимо рассматривать возможность использования того, что уже есть и работает.
Девиз: не надо изобретать велосипед, если он уже изобретен.
Достоинства повторного использования. Виды повторного использования
Достоинства повторного использования (по Соммервилю):
|
|
|
- Повышение надежности.
- Уменьшение проектных рисков.
- Эффективное использование специалистов.
- Соблюдение стандартов (пример: пользовательский интерфейс).
- Ускорение разработки.
Повторное использование достигается за счет следующих приемов (видов использования):
- Компонентная разработка. Часть компонентов уже разработаны ранее, имеют четко описанный интерфейс. Они используются в качестве «кирпичиков» в новой системе.
- Использование паттернов (шаблонов) проектирования. Применяются известные подходы к решению некоторых встречавшихся ранее проблем.
- Использование стандартных прикладных (MKL, MFC…) и системных (API) библиотек.
Визуальное моделирование. Язык UML
Идея визуального моделирования
Вспомним, в чем состоит основная проблема в разработке ПО? Проекты не укладываются в сроки, бюджет, не удовлетворяют требованиям.
Как решать эту проблему? На помощь приходитмоделирование. Под моделью обычно понимают упрощенное представление объектов и явлений реального мира.
Ответим на вопрос, зачем строят модели? Модели строят для того, чтобы лучше понять исследуемую систему.
Классики проклассифицировали задачи и принципы моделирования. Приведем здесь эту, несомненно, важную, классификацию.
|
|
|
Задачи моделирования:
- Визуализация системы в ее некотором состоянии.
- Определение структуры и поведения системы.
- Получение шаблона для создания системы.
- Документирование принятых решений.
Принципы моделирования:
- Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
- Каждая модель может быть воплощена с разной степенью абстракции.
- Лучшие модели – те, что ближе к реальности.
- Наилучший подход при разработке сложной системы – использовать несколько почти независимых моделей.
Как уже упоминалось ранее, одним из наиболее популярных подходов к моделированию является объектный подход. В соответствии с этим подходом в результате OOA и OOD мы получаем «хороший» проект программной системы, прозрачный, удовлетворяющий требованиям, удобный для тестирования и отладки, коллективной разработки, развиваемый, допускающий повторное использование компонентов.
К сожалению, даже использование таких мощных средств, как объектный подход, не гарантирует нам успех. К сожалению, в больших проектах сложность моделируемого объекта (и, соответственно, сложность проекта) такова, что проект слишком велик для адекватного восприятия одним человеком, по крайней мере, в уме.
|
|
|
Это и означает необходимость визуального моделирования.
Идея визуального моделирования состоит в графическом отображении обсуждаемых и принимаемых проектных решений. При этом достигаются следующие цели:
- Визуализация упрощает понимание проекта в целом.
- Визуализация помогает согласовать терминологию и убедиться, что все одинаково понимают термины.
- Визуализация делает обсуждение конструктивным и понятным.
Для визуального моделирования нужна специальная нотация или язык.
UML (unified modeling language) – это язык для визуализации, специфицирования, конструирования, документирования элементов программных систем. UML – язык общего назначения, предназначенный для объектного моделирования.
Основы UML
Краткая история
В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка они взяли методы моделирования, разработанные ими при работе над OMT (Object-Modeling Technique). В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (Unified Method) Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.
|
|
|
К разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года.
Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2
Общая структура UML показана на рис. 6.
Рис. 6 - Структура UML
Семантика и синтаксис UML
Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний.
Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста.
Модели UML имеют, по крайней мере, два измерения: графическое, позволяющее визуализировать модель с помощью диаграмм и пиктограмм, и текстовое, состоящее из спецификаций различных элементов модели. Спецификации – это текстовые описания семантики элемента.
Набор спецификаций – это суть модели. Спецификации формируют семантический задний план (semantic backplane), который объединяетмодель и наполняет ее смыслом. Различные диаграммы – это простопредставления или визуальные проекции этого плана.
Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.
Семантический задний план обычно сопровождается инструментом моделирования UML, предоставляющим доступ, просмотр и изменение спецификаций каждого элемента модели.
UML обеспечивает большую гибкость при создании моделей. В частности, модели могут быть:
• сокращенными – некоторые элементы присутствуют в заднем плане, но скрыты в той или иной диаграмме для упрощения представления;
• неполными – некоторые элементы модели могут быть полностью пропущены;
• несогласованными – модель может содержать противоречия.
Здесь важен сам факт ослабления требований к полноте и согласованности, поскольку со временем модель эволюционирует и неоднократно подвергается изменениям. Однако развитие всегда происходит по направлению к согласованным моделям, достаточно полным для создания программной системы.
Разработку моделей с помощью UML, как правило, начинают с графической модели, которая позволяет визуализировать систему, а затем по мере ее развития добавляют в задний план все больше и больше семантики. Однако модель можно считать полезной или полной, только если семантика модели присутствует в семантическом заднем плане. В противном случае модели не существует, есть просто бессмысленный набор блоков и пятен, соединенных линиями. Общую ошибку, совершаемую новичками в разработке моделей, можно назвать «смерть от диаграмм»: модель переполнена диаграммами, но недоопределена.
Нотация UML
Нотация представляет собой графическую интерпретацию семантики для ее визуального представления.
В UML определено три типа сущностей:
- структурная – абстракция, являющаяся отражением концептуального или физического объекта;
- группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
- поясняющая (аннотационная) – комментарий к элементу диаграммы.
В табл. 1 приведено краткое описание сущностей, используемых в графической нотации.
Таблица 1 - Сущности UML
| Тип | Наименование | Обозначение | Определение (семантика) |
| Структурная | Класс (class) | 
| Множество объектов, имеющих общую структуру и поведение |
| Объект (object) | 
| абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности) | |
| интерфейс (interface) |  iРасчет
| совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом | |
| актер (actor) |  Инженер службы пути
| внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации | |
| вариант использования (use case) | 
| описание последовательности выполняемых системой действий, которая приводит к значимому для актера результату | |
| состояние (state) | 
| описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события | |
| кооперация (collaboration) | 
| описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи | |
| компонент (component) | 
| физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов | |
| узел (node) | 
| физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи | |
| Группирующая | Пакет (packages) | 
| Общий механизм группировки элементов. В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель |
| Поясняющая | Примечание (comment) | 
| Комментарий к элементу |
В табл. 2 приведено описание всех видов отношений UML, используемых на диаграммах для указания связей между сущностями.
Таблица 2 - Отношения UML
| Наименование | Обозначение | Определение (семантика) |
| Ассоциация (association) | 
| Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения |
| Агрегация (aggregation) | 
| Подвид ассоциации, описывающей связь "часть"–"целое", в котором "часть" может существовать отдельно от "целого". Ромб указывается со стороны "целого". Отношение указывается только между сущностями одного типа |
| Композиция (composition) | 
| Подвид агрегации, в которой "части" не могут существовать отдельно от "целого". Как правило, "части" создаются и уничтожаются одновременно с "целым" |
| Зависимость (dependency) | 
| Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность |
| Обобщение (generalization) | 
| Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа |
| Реализация (realization) | 
| Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования) |
Для ассоциации, агрегации и композиции может указываться кратность (англ. multiplicity), характеризующая общее количество экземпляров сущностей, участвующих в отношении. Она, как правило, указывается с каждой стороны отношения около соответствующей сущности. Кратность может указываться следующими способами:
- * – любое количество экземпляров, в том числе и ни одного;
- целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);
- диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5);
- диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*);
- перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).
Если кратность не указана, то принимается ее значение, равное 1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается равной 1.
В табл. 3 приведено описание механизмов расширения, применяемых для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки.
Таблица 3 - Механизмы расширения UML
| Наименование | Обозначение | Определение (семантика) |
| Стереотип (stereotype) | " " | Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом "include" рассматривается, как отношение включения, а класс со стереотипом "boundary" – граничный класс) |
| Сторожевое условие (guard condition) | [ ] | Логическое условие (например: [A > B] или [идентификация выполнена]) |
| Ограничение (constraint) | { } | Правило, ограничивающее семантику элемента модели (например, {время выполнения менее 10 мс}) |
| Помеченное значение (tagged value) | { } | Новое или уточняющее свойство элемента нотации (например: {version = 3.2}) |
Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой модели программной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. Диаграммы обеспечивают графические представления семантического заднего плана модели. Структура диаграмм UML представлена на рис. 3.
Рис. 7 - Типы UML диаграмм
В следующей таблице дана краткая характеристика основных диаграмм UML.
Таблица 4 - Основные диаграммы UML
| Диаграмма | Назначение | Тип диаграммы (модели ПС) | ||||
| по степени физической реализации | по отображению динамики | по отображаемому аспекту | ||||
| Вариантов использования | Отображает функции системы, взаимодействие между актерами и функциями | Логическая | Статическая | Функциональная | ||
| Классов | Отображает набор классов, интерфейсов и отношений между ними | Логическая или физическая | Статическая | Функционально-информационная | ||
| Поведения | Состояний | Отображает состояния сущности и переходы между ними в процессе ее жизненного цикла | Логическая | Динамическая | Поведенческая | |
| Деятельности | Отображает бизнес-процессы в системе (описание алгоритмов поведения) | |||||
| Взаимодействия | Последова-тельности (sequence) | Отображает последовательность передачи сообщений между объектами и актерами | ||||
| Кооперации (collaboration) | Аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами | |||||
| Реализации | Компонентов | Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними | Физическая | Статическая | Компонентная | |
| Развертывания | Отображает размещение компонентов по узлам сети, а также ее конфигурацию | |||||
Связь моделей и диаграмм
При создании отдельной модели системы в различных методологиях разработки ПО строят несколько видов диаграмм. Более того, при разработке модели сложной системы, как правило, строят несколько диаграмм одного и того же вида. В то же время можно не создавать отдельные виды диаграмм, если в этом нет необходимости. Например, диаграммы последовательности и кооперации являются взаимозаменяемыми, диаграммы состояний строятся только для объектов, обладающих сложным поведением. В табл. 5 приведены рекомендации о необходимости разработки (уточнении) диаграмм по моделям системы, разрабатываемым согласно Унифицированному процессу.
Таблица 5 - Связь моделей и диаграмм
| Модель | Диаграмма | ||||||||
| Вариантов | Состояний | Классов | Кооперации | Последовательности | Деятельности | Компонентов | Развертывания | ||
| Вариантов использования | + | + | + | + | + | ||||
| Анализа | + | + | + | + | + | ||||
| Проектирования | + | + | + | + | + | ||||
| Реализации |
| + | + | + | |||||
Часть диаграмм после их построения требует развития и уточнения в рамках разработки следующей модели. Так, например, диаграммы вариантов использования должны быть уточнены при разработке модели анализа. В моделях вариантов использования и анализа разрабатывается и уточняется диаграмма классов анализа, а в модели проектирования – итоговая детализированная диаграмма классов.
Дата добавления: 2019-02-22; просмотров: 355; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!