Технология разработки программного обеспечения. Сивохин А.В - 64 стр.

UptoLike

64
изображается пунктирной линией со стрелкой, направленной к
интерфейсу.
На диаграмме компонентов необходимо указать другие
зависимости, изображаемые также линией со стрелкой, направленной от
зависимого элемента ( клиента ) к независимому элементу ( источнику ).
Такими зависимостями могут быть, например, связи модулей программы
на этапе компиляции и генерации объектного кода. В другом случае
зависимость может отражать
наличие в независимом компоненте
описаний классов, которые используются в зависимом компоненте для
создания соответствующих объектов. Очень важным случаем отношения
зависимости является отношения между различными видами
компонентов, что означает следующее: внесение изменений в исходные
тексты компонент приводят к изменениям компонента-клиента.
Наконец, на диаграмме компонентов могут быть представлены
отношения зависимости между компонентами
и реализованными в них
классами. Для обозначения такого компонента используется
расширенный символ прямоугольника компонента. Он делится на две
части. В верхней секции записывается имя, а в нижней- перечисляются
реализуемые классы. Если компонент использует объекты, то они также
могут быть изображены в виде поименованных прямоугольников в
нижней секции. Подобная вложенность означает,
что выполнение
компонента влечет выполнение соответствующих объектов, т.е.
существование компонента в течение времени исполнения программы
обеспечивает существование, а возможно, и доступ всех вложенных в
него объектов.
Дадим несколько рекомендаций по построению диаграммы
компонентов :
1. Максимально учитывать информацию о логическом
представлении модели системы.
2. Точно знать вычислительные платформы и операционные
системы
, на которых будет реализовываться система.
3. Хорошо представлять возможности выбранного языка
программирования.
4. Определиться с выбором базы данных или знаний.
5. При делении программной системы на физические модули или
файлы следует добиваться такой реализации, которая обеспечила
бы возможность повторного использования кода и создания
объектов только при их необходимости. Для этой
цели необходимо
большую часть описаний классов, их операций и методов вынести
изображается пунктирной линией со стрелкой, направленной к
интерфейсу.
      На диаграмме компонентов необходимо указать другие
зависимости, изображаемые также линией со стрелкой, направленной от
зависимого элемента ( клиента ) к независимому элементу ( источнику ).
Такими зависимостями могут быть, например, связи модулей программы
на этапе компиляции и генерации объектного кода. В другом случае
зависимость может отражать наличие в независимом компоненте
описаний классов, которые используются в зависимом компоненте для
создания соответствующих объектов. Очень важным случаем отношения
зависимости является отношения между различными видами
компонентов, что означает следующее: внесение изменений в исходные
тексты компонент приводят к изменениям компонента-клиента.
      Наконец, на диаграмме компонентов могут быть представлены
отношения зависимости между компонентами и реализованными в них
классами. Для обозначения такого компонента используется
расширенный символ прямоугольника компонента. Он делится на две
части. В верхней секции записывается имя, а в нижней- перечисляются
реализуемые классы. Если компонент использует объекты, то они также
могут быть изображены в виде поименованных прямоугольников в
нижней секции. Подобная вложенность означает, что выполнение
компонента влечет выполнение соответствующих объектов, т.е.
существование компонента в течение времени исполнения программы
обеспечивает существование, а возможно, и доступ всех вложенных в
него объектов.
      Дадим несколько рекомендаций по построению диаграммы
компонентов :
   1. Максимально      учитывать      информацию     о     логическом
      представлении модели системы.
   2. Точно знать вычислительные платформы и операционные
      системы, на которых будет реализовываться система.
   3. Хорошо     представлять     возможности    выбранного     языка
      программирования.
   4. Определиться с выбором базы данных или знаний.
   5. При делении программной системы на физические модули или
      файлы следует добиваться такой реализации, которая обеспечила
      бы возможность повторного использования кода и создания
      объектов только при их необходимости. Для этой цели необходимо
      большую часть описаний классов, их операций и методов вынести

                                    64