Конспект лекций, страница 15

PDF-файл Конспект лекций, страница 15, который располагается в категории "лекции и семинары" в предмете "объектно-ориентированный анализ и проектирование" изседьмого семестра. Конспект лекций, страница 15 - СтудИзба 2019-09-18 СтудИзба

Описание файла

PDF-файл из архива "Конспект лекций", который расположен в категории "лекции и семинары". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 15 страницы из PDF

Пример:Класс анализаМеханизм(ы) анализаStudentPersistency, SecuritySchedulePersistency, SecurityCourseOfferingPersistency, Legacy InterfaceCoursePersistency, Legacy InterfaceRegistrationControllerDistributionВ описания классов, сопоставленных с архитектурными механизмами, добавляютсядополнительные характеристики, например:Характеристики класса Schedule: Объем: до 2000 графиков. Частота доступа:14o Создание: 500 в день.o Чтение: 2,000 обращений в час.o Обновление: 1,000 в день.o Удаление: 50 в день.Унификация классов анализа заключается в изменении модели анализа такимобразом, чтобы соблюдалось выполнение следующих условий: имя и описание каждого класса анализа должно отражать сущность его роли всистеме; классы с одинаковым поведением, или представляющие одно и то же явление, должныобъединяться; классы-сущности с одинаковыми атрибутами должны объединяться (даже если ихповедение отличается).По результатам унификации классов должны быть модифицированы описаниявариантов использования.По окончании модель анализа должна быть подвергнута проверке:1.

Все ли классы обоснованы надлежащим образом?2. Отражает ли имя каждого класса его роль?3. Представляет ли класс единственную, четко определенную абстракцию?4. Являются ли все атрибуты и обязанности класса функционально связанными?5. Отражают ли классы всю функциональность вариантов использованию, заключеннуюв основных, подчиненных и альтернативных потоках событий?6. Однозначно ли распределено поведение по классам?Упоминаемые в лекции образцы подробно описаны в книгах [4] и [5].Литература к лекции 61.

Вендров А. М. Проектирование программного обеспечения экономическихинформационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.2. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделированиеи разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Главы 12-13.3.

Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином.Лаборатория знаний. 2007. Лекция 4.4. Ларман Крэг. Применение UML 2.0 и шаблонов проектирования. 3-е изд. Пер. с англ. –М.: Вильямс, 2007.5. Фаулер М. Архитектура корпоративных программных приложений. – М.: Вильямс,2007.15Лекция 7. Проектирование программного обеспеченияПроектирование системы является поиском ответа на вопрос как следует сделать то,что следует сделать.Этапы проектирования:1. Проектирование архитектуры системы.1.1. Идентификация архитектурных решений и механизмов проектирования;1.2. Анализ взаимодействий между классами анализа, выявление проектных классов,подсистем и интерфейсов;1.3.

Формирование архитектурных уровней;1.4. Проектирование структуры потоков управления;1.5. Проектирование конфигурации системы.2. Проектирование элементов системы.2.1. Уточнение реализаций вариантов использования.2.2. Проектирование подсистем.2.3. Проектирование классов.2.4. Проектирование баз данных.Проектирование архитектуры системы выполняется архитектором системы.В процессе проектирования определяются детали реализации архитектурныхмеханизмов, обозначенных в процессе анализа.

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

В них также объединялись структурные модели (диаграммы классов) смоделями поведения (диаграммами взаимодействия).Проектные механизмы являются переходным этапом от механизмов анализа кмеханизмам реализации. Механизм реализации – решение, имеющее конкретногопоставщика, проектный механизм – каркас, максимально приближенный к реализации,имеющий конкретное наполнение, чем отличается от механизма анализа, являющегосялишь своеобразной меткой.МеханизманализаPersistencyМеханизмпроектированияRDBMSМеханизмреализацииJDBCLegacy DataPersistencyOODBMSObjectStoreNew DataDistributionRemote MethodInvocation (RMI)JavaВ качестве примера рассмотрим механизм Persistency – хранение экземпляровустойчивых классов в БД.

Предположим, что в проекте системы регистрации в качествеязыка программирования используется Java. Поскольку существующая система каталогакурсов функционирует на основе реляционной СУБД, механизмом проектирования,обеспечивающим доступ к этой внешней базе данных, будет RDBMS (Relational DatabaseManagement System), реализовать который можно решением от Sun – JDBC (Java Database1Connectivity).Рис. Диаграмма классов,отображающаямеханизм JDBC и роли внем<<role>>DBClass<<role>>PersistencyClientPersistency - RDBMS - JDBC<<role>>PersistentClassList<<role>>PersistentClassСтереотип <<role>> используется для элементов модели, являющихся меткамизаполнителями (placeholders), – своего рода гнезд, в которые при проектировании будутподставлены реальные элементы, созданные разработчиком системы.

Роли являютсясвоего рода параметрами механизма, при подстановке на их место конкретных классовопределяется экземпляр механизма, используемый при проектировании системы.«mechanism»RDBMS - JDBCDBClassPersistentClassPersistentClassListPersistencyClientРис. Изображение механизма JDBC в виде параметризованной кооперации.Классы-участники механизма JDBC: DBClass – роль, которая отвечает за чтение и запись данных, реализует все услуги похранению устойчивых объектов в реляционной БД. DriverManager, Connection, Statement, ResultSet – библиотечные классы, которыеотвечают за реализацию запроса к БД (выполнение оператора SQL) – пакет java.sql. PersistentClass – роль, представляющая любой устойчивый класс. PersistentClassList – роль, представляющая список объектов, которые являютсярезультатом запроса к БД –DBClass.read(). PersistencyClient – роль, представляющая любой клиентский класс.Рис.

Диаграмма классов, отображающая структурные связи классов-участников JDBC2Взаимодействие экземпляров классов,диаграммами взаимодействия, например::PersistencyClient: DBClass1: create( )врамках:PersistentClassмеханизма: Connectionописывается: Statement2: new( )3: getData( )4: createStatement( )5: executeUpdate(string)Из диаграммы видно, что для создания новых данных (нового экземпляраустойчивого класса) экземпляр клиентского класса PersistencyClient запрашивает DBClass.DBClass создает новый экземпляр PersistentClass, запрашивает начальные значения егоатрибутов (записанные конструктором).

Затем DBClass создает новый оператор SQL,используя операцию createStatement() класса Connection. Этот запрос должен добавитьновую запись в таблицу. В результате выполнения этого оператора SQL данные новогоэкземпляра устойчивого класса помещаются в БД.Следующим этапом является выявление подсистем и интерфейсов. Декомпозициясистемы на подсистемы реализует принцип модульности. Первым действием архитекторапри выявлении подсистем является преобразование классов анализа в проектные классы.Классы анализаПроектные элементы<<boundary>><<control>><<entity>><<boundary>>По каждому классу анализа принимается одно из двух решений:3класс анализа отображается в проектный класс, если он простой или представляетединственную логическую абстракцию; сложный класс анализа может быть разбит на несколько классов, преобразован в пакетили в подсистему.Совокупности классов объединяются в пакеты и подсистемы.

При объединенииклассов в пакеты учитывается, что: Пакеты – это единицы управления конфигурацией, поэтому члены пакета должныбыть одинаково стабильны. Пакеты – средство распределения ресурсов между командами разработчиков. Разные пакеты могут соответствовать разным типам пользователей. Как пакет можно оформить повторно используемый код, встроенный в систему.Например, если пользовательский интерфейс нестабилен, имеет смысл объединитьвсе классы, его реализующие, в отдельный пакет. Если UI не будет подвергатьсясущественным изменениям, можно объединить в отдельные пакеты классы,взаимодействующие при реализации разных вариантов использования.Распределяя классы по пакетам желательно добиться ситуации, когда через границыпакетов проходит значительно меньшее количество связей, чем находится внутри пакетов.После выделения пакетов устанавливаются зависимости между ними и видимостьчленов пакета.

К закрытым членам пакета доступ извне запрещен. Это позволяет скрытьвнутреннее устройство пакета.AClass A1AClass A2Class A3BBPublic visibility+Class B1-Class B2Private visibilityНесколько классов могут быть объединены в подсистему если:классы имеют функциональную связь (участвуют в реализации вариантаиспользования и взаимодействуют только друг с другом);совокупность классов реализует функциональность, которая может быть удаленаиз системы или заменена на альтернативную;классы сильно связаны;4классы размещены на одном узле вычислительной сети.ПодсистемыПакетыИмеют собственноеповедение.Полностьюинкапсулируют своесодержимое.Могут быть легкозаменены.Client ClassНе реализуютповедение.Не полностьюинкапсулируютсодержимое.Не могут быть легкозаменены.Package BClassB1<<subsystem>>Subsystem AClassB2Заметим, что связь клиентского класса с подсистемой более гибкая, чем с пакетом, втом смысле, что изменения внутри подсистемы не затрагивают клиентский класс.

Вовтором случае изменения из пакета могут распространиться на клиента вдользависимости. Обратной стороной гибкости является такой неприятный факт – интерфейсдолжен быть стабильным. Любое изменение в интерфейсе затронет реализующую егоподсистему (вдоль связи реализации), а также клиентский класс, которому требуетсяданный интерфейс (вдоль зависимости). Очень желательно сразу правильно описатьинтерфейсы!Примеры возможных подсистем: подсистема безопасности, защиты данных,архивирования; подсистема пользовательского интерфейса или интерфейса с внешнимисистемами; коммуникационное ПО, доступ к базам данных.При создании подсистем в модели выполняются следующие преобразования: объединяемые классы помещаются в специальный пакет с именем подсистемы истереотипом <<subsystem>>; спецификации операций классов, образующих подсистему, выносятся в интерфейсподсистемы – класс со стереотипом <<interface>>; характер использования операций интерфейса и порядок их выполнениядокументируется с помощью диаграмм взаимодействия, которые вместе с диаграммойклассов подсистемы объединяются в кооперацию с именем интерфейса и стереотипом<<interface realization>>; в подсистеме создается класс-посредник со стереотипом <<subsystem proxy>>,управляющий реализацией операций интерфейса.Принятие решения опреобразованиикласса в подсистемуопределяется опытом5Все интерфейсы подсистем должны быть полностью определены в процессепроектирования архитектуры, поскольку они будут служить в качестве точексинхронизации при параллельной разработке системы.

Описание интерфейса включает: Имя интерфейса: короткое (одно-два слова), отражающее его роль в системе. Описание интерфейса: должно отражать его ответственности (размер – небольшойабзац). Описание операций: имя, отражающее результат операции, ключевые алгоритмы,возвращаемое значение, параметры с типами. Документирование интерфейса: характер использования операций и порядок ихвыполнения (показывается с помощью диаграмм последовательности), тестовые планыи сценарии и т.д. Вся эта информация объединяется в специальный пакет.В качестве примера (для системы регистрации) приведем подсистему BillingSystem,которая создана вместо граничного класса BillingSystem.

Свежие статьи
Популярно сейчас