Главная
Коллекция "Revolution"
Программирование, компьютеры и кибернетика
Разработка и эксплуатация информационных систем
Разработка и эксплуатация информационных систем
Понятие жизненного цикла программного обеспечения. Методы и инструментальные средства проектирования. Проблема сложности больших систем. Типы связей между функциями. Моделирование потоков данных. Концептуальная основа объектно-ориентированного подхода.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | учебное пособие |
| Язык | русский |
| Дата добавления | 07.04.2014 |
| Размер файла | 5,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами.
На рис. 3.2 изображена типичная диаграмма классов.
Перед тем как приступить к описанию диаграмм классов, следует обратить внимание на один важный момент, связанный с характером использования этих диаграмм разработчиками. Этот момент обычно никак не документируется, однако оказывает существенное воздействие на способ интерпретации диаграмм и поэтому имеет важное отношению к тому, что описывается с помощью модели.
Построение диаграмм классов можно рассматривать в различных аспектах:
концептуальный аспект - диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как не зависимую от средств реализации (языка программирования);
аспект спецификации - модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);
аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.
Понимание аспекта имеет большое значение как для построения, так и для чтения диаграмм классов. К сожалению, различия между аспектами не столь отчетливы, и большинство разработчиков при построении диаграмм допускают их смешение.
При построении диаграммы необходимо выбрать единственный аспект. При чтении диаграммы следует выяснить, в соответствии с каким аспектом она строилась. Если нужно интерпретировать эту диаграмму правильным образом, то без такого знания не обойтись
Tочка зрения на диаграммы классов, не будучи собственно формальной частью UML, однако при построении и анализе моделей является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают аспект реализации. С другой стороны очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.
3.4.2 АССОЦИАЦИИ
На рис. 3.2 изображена простая модель классов, связанная с обработкой заказов клиентов. Опишем каждый фрагмент модели и рассмотрим его возможную интерпретацию с различных точек зрения.
Ассоциации представляют собой связи между экземплярами. С концептуальной точки зрения ассоциации представляют собой концептуальные связи между классами. На диаграмме показано, что Заказ должен поступить от единственного Клиента, а Клиент в течение некоторого времени может сделать несколько Заказов. Каждый из этих Заказов содержит несколько Строк заказа, каждая из которых соответствует единственному Продукту.
Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.
Роль может быть явно поименована с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется "позиции заказа". Если такая метка отсутствует, роли присваивается имя класса-цели - таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).
Роль также обладает множественностью, которая показывает, сколько объектов может участвовать в данной связи. На рис. 3.2 символ "*" над ассоциацией между Клиентом и Заказом означает, что с одним Клиентом может быть связано много Заказов; символ "1" показывает, что любой Заказ может поступить только от одного Клиента.
В общем случае множественность указывает нижнюю и верхнюю границы количества объектов, которые могут участвовать в связи. Символ "*" в действительности выражает диапазон "ноль-бесконечность": Клиент может и не сделать ни одного Заказа, а может сделать неограниченное количество Заказов (теоретически). Единица означает диапазон "один-один": Заказ должен быть сделан одним и только одним Клиентом.
На практике наиболее распространенными вариантами множественности являются "1", "*" и "0..1" (либо ноль, либо единица). В общем случае может использоваться единственное число (например, 11 для количества игроков в команде), диапазон (например, 2..4 для игроков в карты) или дискретная комбинация из чисел и диапазонов - (например, 2,4 для количества дверей в автомобиле).
Ассоциации в аспекте спецификации представляют собой ответственности классов.
На рис. 3.2 подразумевается, что существуют методы (один или более), связанные с Клиентом, с помощью которых можно узнать, какие заказы сделал данный Клиент. Аналогично в классе Заказ существуют методы, с помощью которых можно узнать, какой Клиент сделал данный Заказ и какие Позиции Заказа строки входят в Заказ.
Если допустить, что имеются стандартные соглашения по именованию методов запросов, то можно извлечь из диаграммы наименования этих методов. Например, можно принять соглашение, в соответствии с которым однозначные связи реализуются посредством метода, который возвращает связанный объект, а многозначные связи реализуются посредством перечисления (enumeration) или итератора, указывающего на совокупность связанных объектов.
Диаграмма классов (см. рис. 3.2) также предполагает, что существуют некоторые механизмы обновления связей. Например, должен существовать некоторый способ связи конкретного Заказа с конкретным Клиентом. Детали этого способа на диаграмме отсутствуют.
Если же модель отражает аспект реализации, можно исходить из предположения, что между связанными классами существуют указатели в обоих направлениях. Диаграмма может теперь сообщить, что Заказ содержит поле, представляющее собой совокупность указателей на Строки заказа, а также содержит указатель на Клиента.
Рассмотрим теперь рис. 3.3. В основном он совпадает с рис. 3.2, за исключением того, что к ассоциациям добавлены стрелки. Эти стрелки показывают направление навигации.
На модели спецификаций таким образом можно показать, что Заказ обязан ответить на вопрос, к какому Клиенту он относится, а у Клиента соответствующая ответственность отсутствует. Вместо симметричных ответственностей показываются только односторонние. На диаграмме реализации это может означать, что Заказ содержит указатель на Клиента, но Клиент не указывает на Заказ.
Как можно увидеть, направление навигации является важной частью диаграмм спецификации и реализации. На концептуальных же диаграммах, как правило, направления навигации отсутствуют. Они появляются по мере того, как аспект меняется в сторону спецификации и реализации.
Если навигация указана только в одном направлении, то такая ассоциация называется однонаправленной. У двунаправленной ассоциации навигация указана в обоих направлениях. В языке UML отсутствие стрелок у ассоциации трактуется следующим образом: направление навигации неизвестно, или ассоциация является двунаправленной. Для моделей спецификации и реализации предпочтительнее трактовать отсутствие стрелок как неопределенное направление навигации.
Двунаправленные ассоциации содержат дополнительное ограничение, которое заключается в следующем: две их роли являются инверсными (обратными) по отношению друг к другу. Это утверждение подобно понятию обратных функций в математике. По отношению к рис. 3.3 это означает, что каждая Строка заказа, связанная с некоторым Заказом, должна быть связана с конкретным Заказом-источником (в смысле направления навигации). Аналогично если взять какую-либо Строку заказа и взглянуть на Позиции Строки, соответствующие связанному с ними Заказу, то можно обнаружить Строку заказа - источник данной совокупности элементов. Указанное свойство остается справедливым для любой из трех точек зрения.
3.4.3 АТРИБУТЫ
На концептуальном уровне наличие атрибута "имя Клиента" указывает на то, что Клиенты обладают именами. На уровне спецификаций этот атрибут указывает на то, что объект Клиент может сообщить свое имя и обладает некоторым механизмом его определения. На уровне реализации Клиент содержит поле (называемое также переменной или элементом данных), соответствующее его имени.
В зависимости от степени детальности диаграммы обозначение атрибута может включать имя атрибута, тип и значение, присваиваемое по умолчанию (в синтаксисе UML это выглядит следующим образом: <признак видимости> <имя>: <тип> = <значение по умолчанию>, где признак видимости имеет такое же значение, как и для операций, описываемых в следующем подразделе).
Атрибуты всегда имеют единственное значение. Обычно на диаграмме не показывается, является атрибут обязательным или необязательным.
3.4.4 ОПЕРАЦИИ
Операции представляют собой процессы, реализуемые классом. Наиболее очевидное соответствие существует между операциями и методами над классом. На уровне спецификаций операции соответствуют общим методам над типом. На диаграмме обычно не показывают простые операции манипулирования атрибутами, поскольку они и так подразумеваются. Иногда все же бывает необходимо показать, предназначен ли данный атрибут только для чтения (readonly) или его значение является постоянным (immutable), т.е. никогда не изменяется. В модели реализации может также потребоваться отражение уровней секретности и защиты операций.
Полный синтаксис UML для операций выглядит следующим образом:
<признак-видимости> <имя> (<список-параметров>): <тип-выражения-возвращающего-значение> {<строка-свойств>},
где признак-видимости может принимать одно из трех значений: "+" (общий), "#" (защищенный) или "-" (секретный); имя представляет собой символьную строку; список-параметров содержит необязательные аргументы, синтаксис которых совпадает с синтаксисом атрибутов; тип-выражения-возвращающего-значение является необязательной спецификацией и зависит от конкретного языка программирования; строка-свойств показывает значения свойств, которые применяются к данной операции.
Пример записи операции: кредитныйРейтинг(): Строка.
Полезно проводить границу между операциями, изменяющими состояние класса, и операциями, которые этого не делают. Операция, не изменяющая наблюдаемого состояния класса, результатом которой является некоторое значение, извлекаемое из класса, называется запросом. Наблюдаемым состоянием объекта является состояние, которое можно определить посредством связанных с ним запросов.
Рассмотрим объект Счет, который рассчитывает свой баланс исходя из перечня статей. Чтобы повысить производительность, Счет может помещать результат расчета баланса в специальное поле - кэш для будущих запросов. Таким образом, если кэш пуст, операция "баланс" при первом вызове помещает свой результат в кэш. Операция "баланс", следовательно, изменяет текущее состояние объекта Счет, но не изменяет его наблюдаемое состояние, поскольку любой запрос к объекту возвращает одно и то же значение независимо от того, пуст кэш или полон. Операции, изменяющие наблюдаемое состояние объекта, называются модификаторами.
Следует четко понимать разницу между запросами и модификаторами. Запросы могут выполняться в любом порядке, однако последовательность выполнения модификаторов имеет более существенное значение.
3.4.5 ОБОБЩЕНИЕ
Типичный пример обобщения включает частного и корпоративного клиентов (см. рис. 3.2). Они обладают некоторыми различиями, однако у них также много общего. Одинаковые характеристики можно поместить в обобщенный класс Клиент (супертип), при этом Частный клиент и Корпоративный клиент будут выступать в качестве подтипов.
Этот феномен служит объектом разнообразных интерпретаций в моделях различных уровней. На концептуальном уровне, например, можно утверждать, что Корпоративный клиент является подтипом Клиента, если все экземпляры Корпоративного клиента являются также (по определению) экземплярами Клиента. Корпоративный клиент, таким образом, является особым видом Клиента. Основная идея заключается в следующем: все, что известно о Клиенте (ассоциации, атрибуты, операции), справедливо также и для Корпоративного клиента.
В рамках модели спецификации смысл обобщения заключается в том, что интерфейс подтипа должен включать все элементы интерфейса супертипа. Говорят, что интерфейс подтипа согласован с интерфейсом супертипа.
Другая сторона обобщения связана с принципом подстановочное определение. Можно подставить определение Корпоративного клиента в любой код, требующий определения Клиента, и при этом все должно нормально работать. По существу, это означает, что, разрабатывая код, предполагающий использование Клиента, можно свободно использовать экземпляр любого подтипа Клиента. Корпоративный клиент может реагировать на некоторые команды отличным от другого Клиента образом (в соответствии с принципом полиморфизма), но вызывающий объект это отличие не должно беспокоить.
Обобщение в аспекте реализации связано с понятием наследования в языках программирования. Подкласс наследует все методы и поля суперкласса и может переопределять наследуемые методы.
3.4.6 ОГРАНИЧЕНИЯ
При построении диаграмм классов на них отображаются различные ограничения.
На рис. 3.3 показано, что Заказ может быть сделан одним-единственным Клиентом. Диаграмма также подразумевает, что каждая Позиция Заказа рассматривается отдельно: можно заказать 40 коричневых штук, 40 голубых штук и 40 красных штук, а не 40 коричневых, голубых и красных штук. Далее, диаграмма говорит, что Корпоративный клиент располагает кредитным лимитом, а Частный клиент - нет.
С помощью конструкций ассоциации, атрибута и обобщения можно специфицировать наиболее важные ограничения, но невозможно выразить все ограничения. Эти ограничения отображаются произвольным образом, поскольку в UML отсутствует строгий синтаксис описания ограничений, за исключением помещения их в фигурные скобки. Можно использовать неформальную запись ограничений на естественном языке, чтобы их было проще понимать, или использовать более формальные выражения, такие, как исчисление предикатов или производные функции. Другая возможность -- это использование фрагментов программного кода.
3.4.7 БОЛЕЕ СЛОЖНЫЕ ПОНЯТИЯ
Понятия, описанные выше, соответствуют основным нотациям на диаграмме классов. Эти понятия являются самыми первыми, с которыми следует познакомиться и которые необходимо освоить, поскольку с ними связаны 90% деятельности по построению диаграмм классов.
С другой стороны, диаграммы классов содержат множество нотаций, соответствующих различным вспомогательным понятиям. Они используются не столь часто, но в отдельных случаях оказываются весьма удобными.
Стереотипы. В объектно-ориентированных проектах нередко можно столкнуться с такой ситуацией, когда один класс выполняет практически все функции системы, зачастую посредством одного огромного метода, а другие классы не делают в основном ничего, кроме инкапсуляции данных. Такое решение никак нельзя назвать удачным, поскольку при этом данный класс (условно можно назвать его "регулятором") слишком сложен и работать с ним трудно.
Чтобы улучшить такой проект, следует перенести поведение "регулятора" к другим, сравнительно незанятым объектам, благодаря чему эти объекты становятся более интеллектуальными и функционально нагруженными. "Регулятор" при этом превращается в "координатора". "Координатор" отвечает за выполнение задач в определенной последовательности, а другие объекты знают, как выполнять эти задачи.
Сущность стереотипа заключается в том, что он характеризует принципиальное назначение класса. Оригинальная идея стереотипа заключается в классификации объектов на высоком уровне, дающей некоторое представление о типе каждого объекта. Примером может служить различие между "регулятором" и "координатором". UML заимствовал эту идею и трансформировал ее в общий механизм расширения самого языка.
Стереотипы обычно изображаются с помощью текста, заключенного в кавычки ("управляющий объект"), однако они могут также изображаться с помощью пиктограммы.
Многие расширения ядра UML можно описать в виде совокупности стереотипов. В рамках диаграмм классов могут существовать стереотипы классов, ассоциаций или обобщений.
Множественная и динамическая классификация. Понятие "классификация" касается связи между объектом и его типом.
Однозначная классификация подразумевает, что любой объект принадлежит единственному типу, который может наследовать свойства от супертипов. Согласно множественной классификации объект может быть описан несколькими типами, которые не обязательно должны быть связаны наследованием.
Отметим, что множественная классификация отличается от множественного наследования. При множественном наследовании тип может иметь много супертипов, но для каждого объекта должен быть определен только один тип. Множественная классификация допускает принадлежность объекта многим типам без определения для этих целей какого-либо специального типа.
В качестве примера рассмотрим диаграмму на рис. 3.4: подтипом личности является мужчина или женщина, доктор или медсестра, пациент или вообще никто. Множественная классификация допускает, чтобы объект принадлежал любым из этих типов в любом допустимом сочетании, при этом нет необходимости определять типы для всех допустимых сочетаний.
Если используется множественная классификация, то необходимо четко определить, какие сочетания являются допустимыми. Это делается с помощью дискриминатора, который помечает ассоциацию-обобщение и характеризует сущность подтипов. Несколько подтипов могут характеризоваться одним и тем же дискриминатором. Все подтипы с одним и тем же дискриминатором являются непересекающимися. Это означает, что любой экземпляр супертипа может быть экземпляром только одного из подтипов, описываемых данным дискриминатором. Удачный способ изобразить такое обобщение графически - это свести ассоциации всех подклассов к одной треугольной стрелке с одним дискриминатором, как показано на рис. 3.4. Альтернативный способ - изобразить несколько стрелок с одинаковыми текстовыми метками.
Дискриминатор может быть помечен как {полный} (что является дополнительным ограничением). Это означает, что любой экземпляр суперкласса должен быть экземпляром одного из подклассов в данной группе. (Суперкласс в этом случае является абстрактным.)
В качестве иллюстрации отметим следующие допустимые сочетания подтипов на диаграмме: (Женщина, Пациент, Медсестра); (Мужчина, Физиотерапевт); (Женщина, Пациент) и (Женщина, Доктор, Хирург). Отметим также, что такие сочетания, как (Пациент, Доктор) и (Мужчина, Доктор, Медсестра), являются недопустимыми: первое не включает типа, определенного {полным} дискриминатором "Пол", а второе включает сразу два типа, определенных одним и тем же дискриминатором "Роль". Однозначной классификации соответствует (по определению) единственный, непомеченный дискриминатор.
Еще одна проблема связана с возможностью изменения типа объекта. Хорошим примером такой ситуации является банковский счет. Когда счет остается пустым, он существенно меняет свое поведение - в частности, переопределяются некоторые операции (включая "снять со счета" и "закрыть счет").
Динамическая классификация допускает изменение типа объектов в рамках структуры подтипов, а статическая классификация этого не допускает. Статическая классификация проводит границу между типами и состояниями, а динамическая классификация объединяет эти понятия.
На рис. 3.5 показан пример использования динамической классификации в отношении работы, выполняемой личностью, которая, естественно, может меняться. При этом для подтипов требуется определить дополнительное поведение, а не только одни метки. В таких случаях зачастую имеет смысл создать отдельный класс для выполняемой работы и связать этот класс с личностью посредством некоторой ассоциации.
Агрегация и композиция. Агрегация представляет собой связь "часть-целое" и является одним из наиболее часто используемых приемов моделирования (например, можно сказать, что двигатель и колеса являются частями автомобиля).
В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции объект-часть может принадлежать только единственному целому и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).
На рис. 3.6 показаны примеры агрегации и композиции. Согласно данной диаграмме Многоугольник состоит из упорядоченной совокупности Вершин. Эти Вершины могут изменяться при изменении Многоугольника, вследствие чего применяется агрегация. Композиция применяется для связи между Многоугольником и Графическим объектом.
Графический объект содержит такие атрибуты, как цвет и текстура. Он рассматривается отдельно от Многоугольника, поскольку многие графические элементы могут использовать такой набор атрибутов. Связь между Многоугольником и Графическим объектом определяется как композиция. Таким образом, показывается, что данный Графический объект создается и уничтожается вместе с данным Многоугольником и не может быть изменен. Разумеется, можно изменить атрибуты Графического объекта, но невозможно заменить один Графический объект другим.
Класс ассоциаций. Он позволяет определять для ассоциаций атрибуты, операции и другие свойства, как это показано на рис. 3.7.
Из данной диаграммы видно, что Личность может работать только в одной Компании. При этом необходимо каким-то образом хранить информацию относительно периода времени, в течение которого каждый служащий работает в каждой Компании.
Это можно сделать, дополнив ассоциацию атрибутом типа "интервал Времени". Можно включить этот атрибут в класс Личность, однако на самом деле он характеризует не Личность, а ее связь с Компанией, которая будет меняться при смене работодателя.
На рис. 3.8 показан другой способ представления данной информации: преобразование Работы в обычный класс (множественность при этом также подвергается соответствующему преобразованию). В данном примере каждый из классов в первоначальной ассоциации обладал однозначной ролью по отношению к классу Работа.
Таким образом, класс ассоциаций дает возможность определить дополнительное ограничение, согласно которому двум участвующим в ассоциации объектам может соответствовать только один экземпляр класса ассоциаций. Диаграмма на рис. 3.7 не допускает, чтобы Личность могла более чем один раз работать в одной и той же Компании. Если необходимо, чтобы такое допускалось, то Работу следует преобразовать в обычный класс, как это сделано на рис. 3.8.
3.4.8 МЕХАНИЗМ ПАКЕТОВ
Один из подходов к решению проблемы сложности систем ПО, о которой говорилось в начале главы 2, заключается в группировке классов в компоненты более высокого уровня. Эта идея проявляется во многих объектно-ориентированных методах. В UML такой способ группировки носит название механизма пакетов (package).
Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится весьма произвольной. Одна из них, которая в основном используется в UML, - это зависимость. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т.е. диаграмма пакетов - это всего лишь форма диаграммы классов.
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменения в другом. Что касается классов, то причины для зависимостей могут быть самыми разными: один класс посылает сообщение другому; один класс включает часть данных другого класса; один класс использует другой в качестве параметра операции. Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу.
В идеальном случае только изменения в интерфейсе класса должны воздействовать на другие классы. Искусство проектирования больших систем включает в себя минимизацию зависимостей - таким способом снижается воздействие изменений и требуется меньше усилий на их внесение.
На рис. 3.9 показаны классы предметной области, сгруппированные в два пакета: Заказы и Клиенты. Оба пакета, в свою очередь, являются частью общего пакета предметной области. Приложение Сбора Заказов имеет зависимости с обоими пакетами предметной области. Пользовательский интерфейс Сбора Заказов имеет зависимости с Приложением Сбора Заказов и AWT (средством разработки графического интерфейса пользователя (GUI) в языке Java).
Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Например, если любой класс в пакете Список Рассылки зависит от какого-либо класса в пакете Клиенты, то между соответствующими пакетами существует зависимость.
Существует очевидное сходство между зависимостями пакетов и составными зависимостями. Однако между ними имеется принципиальное различие: зависимости пакетов не являются транзитивными. Чтобы понять, почему это так важно для зависимостей, обратимся снова к рис. 3.9. Если какой-либо класс в пакете Заказы изменяется, то это совсем не означает, что должен измениться пакет Пользовательский интерфейс Сбора Заказов. Это означает всего лишь, что может измениться пакет Приложение Сбора Заказов. Пакет Пользовательский интерфейс Сбора Заказов должен измениться только в том случае, если меняется интерфейс пакета Приложение Сбора Заказов. В данной ситуации Приложение Сбора Заказов защищает Пользовательский интерфейс Сбора Заказов от изменений в заказах.
Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости, а после того, как они все окажутся на виду, остается только поработать над снижением их количества. Диаграммы пакетов можно считать основным средством управления общей структурой системы.
На рис. 3.10 представлена более сложная диаграмма пакетов, содержащая ряд дополнительных конструкций. Добавлен пакет Предметная область, включающий пакеты Заказы и Клиенты. Это нужно для того, чтобы можно было заменить множество отдельных зависимостей на более общие зависимости с пакетом в целом.
Если показывается содержимое пакета, то имя пакета помещается в "этикетку", а содержимое - внутрь основного прямоугольника. Это содержимое может быть перечнем классов (как в пакете Общий), другой диаграммой пакетов (как в пакете Предметная область) или диаграммой классов (этот вариант не показан, однако идея вполне очевидна).
В большинстве случаев достаточно перечисления основных классов, однако иногда дополнительная диаграмма оказывается полезной. В данном случае (см. рис. 3.10) показано, что, в то время как Приложение Сбора Заказов связано зависимостью со всем пакетом Предметная область, Приложение Списка Рассылки зависит только от пакета Клиенты.
На рис. 3.10 имеется пакет Общий, помеченный как {глобальный}. Это означает, что все пакеты в системе связаны зависимостью с данным пакетом. Разумеется, такую конструкцию следует применять очень расчетливо, однако общие классы (такие, как Деньги) используются во всей системе.
По отношению к пакетам можно использовать механизм обобщения. Это означает, что конкретный пакет должен соответствовать интерфейсу общего пакета. Такое определение можно сравнить с аспектом спецификации относительно механизма подклассов в диаграммах классов. Следовательно, в соответствии с рис. 3.10 Интерфейс Базы данных может использовать либо Интерфейс Oracle, либо Интерфейс Sybase. Когда обобщение применяется таким образом, общий пакет может быть помечен как {абстрактный}, чтобы показать, что он всего лишь определяет интерфейс, реализуемый конкретным пакетом.
Обобщение подразумевает наличие зависимости подтипа от супертипа. (Нет необходимости показывать дополнительную зависимость; достаточно наличия самого обобщения.) Помещение абстрактных классов в пакет-супертип - это хороший способ ликвидации циклов в структуре зависимостей. В данном случае пакеты интерфейса с базой данных отвечают за загрузку объектов предметной области в базу данных и их хранение. Следовательно, им необходимо располагать информацией относительно объектов предметной области. С другой стороны, объекты предметной области должны инициировать загрузку и хранение, т. е. необходим соответствующий триггер.
Механизм обобщения позволяет поместить необходимый интерфейс триггера (различные операции загрузки и сохранения) в пакет интерфейса с базой данных. Эти операции впоследствии реализуются классами в рамках пакетов-подтипов. Нам не нужна какая-либо зависимость между пакетом интерфейса с базой данных и пакетом интерфейса с Oracle, поскольку во время выполнения и так будет вызываться именно тот пакет-подтип, который необходим. При этом пакет Предметная область имеет дело только с простым пакетом интерфейса с базой данных.
В существующей системе зависимости могут быть выведены на основании анализа классов. Эта задача является крайне полезной для реализации с помощью любого инструментального средства. В качестве самого первого шага желательно разделить классы на пакеты и проанализировать зависимости между пакетами. Затем следует уменьшить количество зависимостей.
Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится нечитаемой.
Стремление свести к минимуму количество зависимостей обусловлено снижением степени связности пакетов системы. С другой стороны, эвристический подход к этому процессу далек от идеала.
Пакеты особенно полезны при тестировании. Каждый пакет при этом может содержать один или несколько тестовых классов, с помощью которых проверяется поведение пакета.
СПИСОК ЛИТЕРАТУРЫ
ЛИТЕРАТУРА ОСНОВНАЯ
1. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник. -М.:Финансы и статистика, 2003. -505 с.
2. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.:пер. с англ.: Уч.пос. - М.: Изд.дом «Вильямс», 2000. - 1120 с.
ДОПОЛНИТЕЛЬНАЯ ЛИТЕРАТУРА
1. Кузнецов С.Д. Проектирование и разработки корпоративных информационных систем: Курс лекций.- \\www.citforum.ru
2. Бучек Г. ASP.NET. Учебный курс. Пер с англ. - М.; СПБ.: «Питер», 2002. - 505 с.
Размещено на Allbest.ru
...Подобные документы
Основные методологии проектирования, модели жизненного цикла локальных систем, сущность структурного подхода. Моделирование потоков процессов и программные средства поддержки их жизненного цикла. Характеристика и технология внедрения CASE средств.
курсовая работа [686,9 K], добавлен 13.12.2010Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
курсовая работа [262,5 K], добавлен 10.07.2014Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.
реферат [36,1 K], добавлен 29.04.2010Методология структурного анализа и проектирования информационных систем. Базовый стандарт процессов жизненного цикла программного обеспечения. Цели и принципы формирования профилей информационных систем. Разработка идеальной модели бизнес-процессов.
презентация [152,1 K], добавлен 07.12.2013Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
курсовая работа [1,8 M], добавлен 20.11.2010Основы методологии проектирования информационных систем, понятие их жизненного цикла. Основные модели жизненного цикла. Методология функционального моделирования SADT. Состав функциональной модели. Моделирование данных, характеристика case-средств.
реферат [327,5 K], добавлен 28.05.2015Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).
курсовая работа [1,1 M], добавлен 13.05.2014Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа [355,8 K], добавлен 26.09.2014Создание функциональной структуры фирмы. Методологии проектирования информационных систем. Состав стандарта IDEF. Средства структурного системного анализа. Метод функционального моделирования SADT. Стратегии декомпозиции. Диаграмма потоков данных DFD.
презентация [324,1 K], добавлен 27.12.2013Развитие информационных систем. Современный рынок финансово-экономического прикладного программного обеспечения. Преимущества и недостатки внедрения автоматизированных информационных систем. Методы проектирования автоматизированных информационных систем.
дипломная работа [1,5 M], добавлен 22.11.2015Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
презентация [874,4 K], добавлен 19.09.2016Создание программного обеспечения - системы имитационного моделирования на тему "Производственная линия с пунктами технического контроля". Описание входных и выходных данных. Объектно-ориентированное программирование. Диаграммы модулей и процессов.
курсовая работа [1,2 M], добавлен 09.01.2014Общая характеристика объектно-ориентированного подхода в программировании, его основные свойства и принципы. Разработка программы для автоматизация деятельности кафе на основе объектно-ориентированного подхода, проектирования и реализации схемы данных.
курсовая работа [1,2 M], добавлен 22.01.2012Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.
курсовая работа [2,7 M], добавлен 23.06.2011Разработка программного обеспечения для управления базой данных. Место задачи в системе автоматизации. Семантическое моделирование данных. Разработка программного обеспечения и базы данных. Расчет трудоемкости и себестоимости этапов проектирования.
дипломная работа [2,9 M], добавлен 04.02.2016Общая характеристика структурного программирования. Использование конструкций цикла и условного оператора. Методология функционального моделирования SADT, ее основные элементы. Типы связей между функциями. Моделирование потоков данных (процессов).
дипломная работа [704,7 K], добавлен 20.10.2009История развития информационных технологий. Классификация, виды программного обеспечения. Методологии и технологии проектирования информационных систем. Требования к методологии и технологии. Структурный подход к проектированию информационных систем.
дипломная работа [1,3 M], добавлен 07.02.2009Задачи системы электронного документооборота. Анализ существующих информационных систем. Методы и средства инженерии программного обеспечения. Концептуальная модель данных в BPWin. Построение инфологической модели системы документооборота "Doc_Univer".
курсовая работа [56,1 K], добавлен 25.03.2014Анализ тенденций развития информационных технологий. Назначение и цели применения систем автоматизированного проектирования на основе системного подхода. Методы обеспечения автоматизации выполнения проектных работ на примере ЗАО "ПКП "Теплый дом".
курсовая работа [210,0 K], добавлен 11.09.2010Цель инфологического моделирования предметной области. Источники данных, базы данных и система управления, разработка модели. Принципы проектирования базы данных, концептуальная, логическая, материальная разработка. Типы сущностей, атрибутов и связей.
курсовая работа [188,6 K], добавлен 15.07.2012
