Лекция Проектирование программного обеспечения



страница1/5
Дата17.12.2017
Размер0.68 Mb.
ТипЛекция
  1   2   3   4   5

Лекция 7. Проектирование программного обеспечения


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

Этапы проектирования:



  1. Проектирование архитектуры системы.

    1. Идентификация архитектурных решений и механизмов проектирования;

    2. Анализ взаимодействий между классами анализа, выявление проектных классов, подсистем и интерфейсов;

    3. Формирование архитектурных уровней;

    4. Проектирование структуры потоков управления;

    5. Проектирование конфигурации системы.

  2. Проектирование элементов системы.

    1. Уточнение реализаций вариантов использования.

    2. Проектирование подсистем.

    3. Проектирование классов.

    4. Проектирование баз данных.

Проектирование архитектуры системы выполняется архитектором.

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



Ранее мы встречались с использованием коопераций для моделирования реализаций вариантов использования. В них объединялись структурные модели (диаграммы классов) с моделями поведения (диаграммами взаимодействия).

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

В качестве примера рассмотрим механизм Persistency – хранение экземпляров устойчивых классов в БД. Предположим, что в проекте системы регистрации в качестве языка программирования используется Java. Поскольку существующая система каталога курсов функционирует на основе реляционной СУБД, механизмом проектирования, обеспечивающим доступ к этой внешней базе данных, будет RDBMS (Relational Database Management System), реализовать который можно решением JDBC (Java Database Connectivity).


Рис. Диаграмма классов, отображающая механизм JDBC и роли в нем

Стереотип <> используется для элементов модели, являющихся метками-заполнителями (placeholders), – своего рода гнезд, в которые при проектировании будут подставлены реальные элементы, созданные разработчиком системы. Роли являются своего рода параметрами механизма, при подстановке на их место конкретных классов определяется экземпляр механизма, используемый при проектировании системы.



Рис. Изображение механизма JDBC в
виде параметризованной кооперации.

Классы-участники механизма JDBC:



  • DBClass – роль, которая отвечает за чтение и запись данных, реализует все услуги по хранению устойчивых объектов в реляционной БД.

  • DriverManager, Connection, Statement, ResultSet – библиотечные классы, которые отвечают за реализацию запроса к БД (выполнение оператора SQL) – пакет java.sql.

  • PersistentClass – роль, представляющая любой устойчивый класс.

  • PersistentClassList – роль, представляющая список объектов, которые являются результатом запроса к БД –DBClass.read().

  • PersistencyClient – роль, представляющая любой клиентский класс.

Р



Поделитесь с Вашими друзьями:
  1   2   3   4   5


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал