ПКС / Лекции все

- сервис (service) представляет собой:

1)средства доставки пользовательского контента (means of delivering value for the customer);

2)выполнение рабочих процессов (performance of acitivities);

3)интерактивно переключаемый режим управления информацией (behavior, triggered by an interaction).

-сервисный компонент (service component) представляет собой единственный модуль сервиса (single unit of a service), предназначенный для взаимодействия с другими модулями сервиса;

-дескриптор (handle) означает идентификатор, используемый для доступа к объекту; обработчик (handler) означает программу оработки особых ситуаций или событий;

-инициировать (invoke) значит активировать программу, процедуру или процесс;

-инициатор (invoker) означает объект, который может быть вызван (that caller can execute it);

-назначение вызовов (invoking) означает создание инициатора и соответствующих инициируемых действий.

-выполнять (execute) значит производить запуск программы или команды (процесса или процедуры); исполнитель / исполнительное устройство (executor) означает объект, который выполняет действие самостоятельно либо от имени другого объекта (в результате делегирования); выполнение программы/команды (executing) означает запуск процесса или процедуры исполнителем / исполнительным устройством.

-ставить “ловушку” (hook) означает определять специальную процедуру, которая отслеживает появление некоторого события;

-устанавливать соответствие (map) значит преобразовывать данные (mapping) из одной формы в другую; преобразование данных (mapping) означает назначенное соответствие между двумя сущностями, которые представлены в виде набора упорядоченных пар объектов (assigned correspondence between two things that is represented as a set of ordered pairs); также мэппинг является ассоциативным массивом, соотношение “один-к-одному”;

-разделять объекты (decouple) значит сделать объекты более независимыми один от другого, чтобы уменьшить влияние изменений и ошибок в соответствующих модулях; разделение объекты (decoupling) процесс разделения объектов (decouple);

-связывать объекты (bind) – назначить значение идентификатору; связывание (binding) означает объединение и/или синхронизацию данных различных объектов;

--статическое связывание (static binding) означает связывание данных (binding) до выполнения приложения (computer program) без последующего изменения этих данных во время работы приложения (также называют “раннее связывание”: “early binding”); динамическое -- связывание (dynamic binding) означает связывание данных (binding) во время выполнения приложения (“на лету”: “on the fly”; также называют “позднее связывание”: “late binding”);

--группирование объектов (bundle) означает объединение объектов в группу; наоборот: разгруппирование объектов

(unbundle);

-- развертывание (deploy) означает приведение объекта в рабочее состояние и принятие решений о необходимых переключениях при ошибках (is put into operation and cutover issues are resolved).

Объектный подход в методологии Bottom-Up

Подход к проектированию/разработке “снизу-вверх” (bottom-up) означает выполнение рабочих процессов (activity),

начиная с базовых компонентов самого нижнего уровня (lowest-level component) и последовательно переходя к компонентам верхнего уровня (highest level);

Подход к проектированию “снизу-вверх” (bottom-up design) – то же, что bottom-up – только для процессов проектирования. Примеры применения bottom-up (bottom-up approach):

--Создание приложения по технологии WPF: первичной является XAML-разметка (расширение XML), тогда как сами компоненты создаются/размещаются, основываясь на данных XAML-разметки (на основе XAML-скрипта);

--Создание приложения на основе WinAPI32: соответствующие ресурсы собираются с помощью скриптов, например, используется сквозная нумерация внутренних файлов приложения (иконки, группы иконок, текстовые строки, диалоговые окна, информация о версии содержимого, бинарные файлы): по умолчанию, 100, 101, 102..;

--Создание набора скриптов для моделирования расчетной конструкции: задаются исходные данные конструкций и параметры расчетов;

--Развертывание (deployment) БД из скрипта: выполняются первоначальные настройки, создаются таблицы, включая взаимосвязи между ними, происходит заполнение данными;

-оценивание «снизу-вверх» (bottom-up estimating) – методика оценивания стоимости и длительности проекта (project duration and cost) путем агрегирования (aggregating) компонентов нижнего уровня (lower-level components) при декомпозиции работ в прикладных системах автоматизированного проектирования (WBS, work breakdown structure).

Сценарный подход (методология Bottom-Up)

-Сценарный подход (scenario-based design) – набор методик, с помощью которых проектируемая система подробно представлена с точки зрения пользователя до выполнения разработки системы.

-Рабочий сценарий (operational scenario) – описание представимой последовательности событий, которое включает взаимодействие продукта или сервисного компонента с рабочим окружением (environment) и пользователями.

-Скрипт сценария (scenario script) – пошаговое описание (step-by-step description) последовательности событий, которые происходят параллельно или последовательно; сценарий может быть представлен в виде:

--- рассказа пользователя (user story);

--- UML-диаграммы вариантов использования (use case);

--- рабочего решения (operational concept);

--- UML-диаграммы последовательности (sequence of events).

-Примеры:

--- создание ресурсной dll в WinAPI32: агрегирует (объединяет путем создания «гибких» взаимосвязей) разные объекты исходных данных внутри одного файла;

--- создание сценария ресурсов в WinForms: агрегирует разные файлы в одном проекте;

-Тестирование по сценарию (scenario testing) – методика создания тестов по индивидуальным сценариям.

system boundary

actor

usecase

роль (actor)–типовой активный объект, поведение которого является внешним по отношению к проектируемой системе; прецедент (usecase; также называют «вариант использования») – «набор сценариев, связанных общей целью»;

предметная область прецедентов («рамки системы» (system boundary)) определяет границы системы, внутри которых взаимодействие с ролевыми объектами приводит к рассматриваемым результатам;

UML-диаграмма прецедентов (Use case): вариантов представления (использования)

Пример последовательности составления UML-диаграммы прецедентов

1) выполняют текстовое описание задачи в виде сценария, выделяя типовые действия для основных ролей;

2)упорядочивают сценарий, группируя роли и определяя принадлежность типовых действий к категории <<include>>, <<extend>> или

<<inherit>>;

3)выполняют графическое описание задачи, определяя рамки проектируемой системы.

Пример выполнения этапа 1:

-Пользователь желает воспользоваться сервисом, в котором представлены его данные; И ТАКЖЕ получает доступ к своим данным после авторизации.

-Разработчик сервисов изучает инструкции по доступу к критически важным данным;

А ТАКЖЕ создает компонент для доступа к сервису, руководствуясь инструкциями по доступу к этим данным; А ТАКЖЕ создает страницу авторизации для того, чтобы Пользователь получил доступ к своим данным; А ТАКЖЕ может выполнять действия, определенные для

Пользователя.

-Разработчик сервера приложений конфигурирует развертывание создаваемых сервисов; А ТАКЖЕ создает скрипт управления сервисом на основе настроек по развертыванию сервисов, чтобы Разработчик сервисов получил доступ к созданию сервисных компонентов; А ТАКЖЕ может выполнять действия, определенные для Разработчика сервисов.

-Пользователь желает воспользоваться сервисом, в котором представлены его данные;

И ТАКЖЕ получает доступ к своим данным после авторизации.

- Разработчик сервисов изучает инструкции по доступу к критически важным данным; А ТАКЖЕ создает компонент для доступа к сервису, руководствуясь инструкциями по доступу к этим данным; А ТАКЖЕ создает страницу

авторизации для того, чтобы Пользователь получил доступ к своим данным; А ТАКЖЕ может выполнять действия, определенные для

Пользователя.

- Разработчик сервера приложений конфигурирует развертывание создаваемых сервисов; А ТАКЖЕ создает скрипт управления сервисом на основе настроек по развертыванию сервисов, чтобы Разработчик сервисов получил доступ к созданию сервисных компонентов; А ТАКЖЕ может выполнять действия, определенные для Разработчика сервисов.

Пример последовательности составления UML-диаграммы прецедентов

Пользователь сервиса желает воспользоваться сервисом, в котором представлены его персональные данные. Пользователь сервиса получает доступ к своим данным после авторизации через номер телефона или почтовый адрес (в качестве логина) и пароль.

Ролевой объект Telegram BotFather предоставляет доступ к своему интерфейсу, выступая в качестве посредника между Frontend-

разработчиком сервиса и Пользователем сервиса.

Frontend-разработчик сервиса изучает инструкции по доступу к персональным данным. Frontend-разработчик сервиса разрабатывает

программный интерфейс для работы пользователя с сервисом.

Backend-разработчик сервиса создает программный интерфейс для работы с логикой сервиса. Backend-разработчик сервиса также может выполнять действия, определенные для Frontend-разработчика сервиса.