СПАСОИ (10) - Лекция №6 - Этап логического проектирования: различия между версиями
ILobster (обсуждение | вклад) (Новая страница: «{{Tabli4ka warning undone summary|text= - диаграмм DFD и FHD<br> - пример…») |
ILobster (обсуждение | вклад) м (→Пример для естественного языка: очепятка) |
||
(не показано 5 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
{{Tabli4ka warning undone summary|text= - диаграмм [[#Построение DFD и FHD | DFD и FHD]]<br> - примера для [[#Разработка даталогической схемы БД и приложений | даталогической схемы]]}} | {{Tabli4ka warning undone summary|text= - диаграмм [[#Построение DFD и FHD | DFD и FHD]]<br> - примера для [[#Разработка даталогической схемы БД и приложений | даталогической схемы]]}} | ||
<br> | <br> | ||
{{Backward|l=СПАСОИ (10) - Лекция №5 - Спецификации прикладных программ}} | |||
__TOC__ | __TOC__ | ||
== Этап концептуального проектирования == | == Этап концептуального проектирования == | ||
Строка 18: | Строка 17: | ||
@Выход: Признак разрешения для банкомата (0 - нет, 1 - да, 2 - ожидание) | @Выход: Признак разрешения для банкомата (0 - нет, 1 - да, 2 - ожидание) | ||
@Спецификация | @Спецификация процесса: Проверка разрешения ПЦ-Б | ||
ЕСЛИ разрешение/отказ ПЦ-Б = true ТО | ЕСЛИ разрешение/отказ ПЦ-Б = true ТО | ||
Строка 69: | Строка 68: | ||
CASE-средства для проектирования всей системы. | CASE-средства для проектирования всей системы. | ||
Рассмотрим на | Рассмотрим на примере [http://www.oracle.com/technetwork/developer-tools/designer/overview/index-082236.html Oracle Designer]. | ||
=== Разработка контекстных диаграмм потоков данных === | === Разработка контекстных диаграмм потоков данных === | ||
Строка 88: | Строка 87: | ||
=== Построение DFD и FHD === | === Построение DFD и FHD === | ||
В DFD можно осуществить привязку потоков к именам и атрибутам сущностей, определённых на | В DFD можно осуществить привязку потоков к именам и атрибутам сущностей, определённых на [[#Разработка диаграммы сущность-связь | предыдущем]] шаге. | ||
FHD - Function Hierarchy Diagram, формируется на основе DFD. В неё можно включать новые процессы, и они автоматически появятся в DFD (но без связей). | FHD - Function Hierarchy Diagram, формируется на основе DFD. В неё можно включать новые процессы, и они автоматически появятся в DFD (но без связей). | ||
Строка 127: | Строка 126: | ||
# в <code>i</code> раздел индекса помещается <code>q</code> (без изменений) и <code>p</code> (указатель на запись в БД). | # в <code>i</code> раздел индекса помещается <code>q</code> (без изменений) и <code>p</code> (указатель на запись в БД). | ||
Предположим, что выполняется запрос, и по значению ключа <code>a = q</code> необходимо считать запись. Доступ к записи можно описать с помощью следующей цепочки: {{Формула|f=q\rightarrow h(q) = i\rightarrow}} чтение <code>i</code> раздела хэш-индекса {{Формула|f=\rightarrow (q, p)\rightarrow}} чтение по <code>p</code> записи из таблицы БД. В среднем, чтобы найти и читать запись, требуется две операции чтения (двух блоков) с внешнего диска. | Предположим, что выполняется запрос, и по значению ключа <code>a = q</code> необходимо считать запись. | ||
Доступ к записи можно описать с помощью следующей цепочки: {{Формула|f=q\rightarrow h(q) = i\rightarrow}} чтение <code>i</code> раздела хэш-индекса {{Формула|f=\rightarrow (q, p)\rightarrow}} чтение по <code>p</code> записи из таблицы БД. | |||
В среднем, чтобы найти и читать запись, требуется две операции чтения (двух блоков) с внешнего диска. | |||
Размер хэш-раздела ограничен, и поэтому в процессе работы БД возможно его переполнение. В этом случае образуются разделы перегруженных цепочек. При поиске запись ищется сначала в основном разделе, а потом в перегруженных. | Размер хэш-раздела ограничен, и поэтому в процессе работы БД возможно его переполнение. В этом случае образуются разделы перегруженных цепочек. При поиске запись ищется сначала в основном разделе, а потом в перегруженных. |
Текущая версия от 10:58, 16 июня 2013
Этот конспект ещё не дописан. Здесь не хватает: - диаграмм DFD и FHD - примера для даталогической схемы |
...начало
Этап концептуального проектирования
Разработка спецификация будущих приложений
Структурированный естественный язык
Пример для естественного языка
Спецификация процесса 1.1.2а из DFD "банкомат".
@Вход: Разрешение/отказ ПЦ-Б
@Выход: Признак разрешения для банкомата (0 - нет, 1 - да, 2 - ожидание)
@Спецификация процесса: Проверка разрешения ПЦ-Б
ЕСЛИ разрешение/отказ ПЦ-Б = true ТО
выйти(0)
ИНАЧЕ
выдать сообщение об ошибке
ЕСЛИ ошибка в пароле ТО
проверить счётчик1 на максимум,
запросить пароль,
увеличить счётчик1,
обновить данные транзакции,
повторить функцию "предварительная проверка карты, составление запроса в ПЦ",
выйти(2)
ИНАЧЕ
ЕСЛИ ошибка в сумме ТО
проверить счётчик2 на максимум,
запросить сумму,
увеличить счётчик2,
обновить данные транзакции
ИНАЧЕ
удалить карту из банкомата,
выйти(1)
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
@Конец спецификации
Визуальные языки разработки спецификаций
Они же FlowForm.
Конструкция - это:
- один элемент "выполнить действие" или просто "действие";
- последовательность конструкций;
- выбор между конструкциями;
- итерация конструкций.
Пример для FlowForm
Описать спецификацию процесса 1.1.2а из DFD "банкомат".
Средства для разработки всех этапов проектирования
CASE-средства для проектирования всей системы.
Рассмотрим на примере Oracle Designer.
Разработка контекстных диаграмм потоков данных
Process Modeler.
К каждому процессу может быть прикреплён мультимедиа-контент, показывающий, что там происходит.
Процессы:
- изготовление;
- доставка;
- приёмы хранения и доставка потребителю.
Разработка диаграммы сущность-связь
Построение DFD и FHD
В DFD можно осуществить привязку потоков к именам и атрибутам сущностей, определённых на предыдущем шаге.
FHD - Function Hierarchy Diagram, формируется на основе DFD. В неё можно включать новые процессы, и они автоматически появятся в DFD (но без связей).
Разработка даталогической схемы БД и приложений
Design Editor.
На этом этапе происходит:
- генерация даталогической схемы БД на основе инфологической. Строится Data Diagrams;
- генерация модулей. Строится Module Diagrams.
Сгенерированные формы затем можно изменять в Module Logic Navigator и писать скрипты для обработки событий.
Этап логического проектирования
Задачи этапа:
- оптимизация схемы БД и генерация даталогической схемы с помощью CASE-средств;
- на основании разработанных ранее спецификаций пишется код программы.
Методы индексации данных в реляционных БД
Индекс - некоторая структура, обеспечивающая быстрый поиск данных в БД.
Типы индексов:
- хэш-индекс;
- B-индекс.
Хэш-индекс
Имеет следующую структуру:
Описание:
- запись данных помещается в таблицу БД;
- значение ключа
q
хэшируется, и, тем самым, вычисляется номер разделаi
; - в
i
раздел индекса помещаетсяq
(без изменений) иp
(указатель на запись в БД).
Предположим, что выполняется запрос, и по значению ключа a = q
необходимо считать запись.
Доступ к записи можно описать с помощью следующей цепочки: $$q\rightarrow h(q) = i\rightarrow$$ чтение i
раздела хэш-индекса $$\rightarrow (q, p)\rightarrow$$ чтение по p
записи из таблицы БД.
В среднем, чтобы найти и читать запись, требуется две операции чтения (двух блоков) с внешнего диска.
Размер хэш-раздела ограничен, и поэтому в процессе работы БД возможно его переполнение. В этом случае образуются разделы перегруженных цепочек. При поиске запись ищется сначала в основном разделе, а потом в перегруженных.