ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.04.2024
Просмотров: 178
Скачиваний: 1
Пример ERD в нотации Чена. |
|
||
Имеет |
1 |
Клиент |
Банк |
|
|||
|
|
|
|
|
|
=1 |
=1 |
|
|
|
|
0 v более |
|
|
Имеет |
|
|
|
|
Клиент |
|
Может владеть |
|
=1 |
|
0 v более |
–1v более |
|
|
||
|
|
Кредитная карта |
0 v более |
|
|
|
|
Имеет
Банковский счет
=1
=1
определяет Никаких атрибутов на этой схеме не обозначать! Для этого есть диаграмма атрибутов.
Диаграмма атрибутов
Кредитная карта
пароль |
|
Лимит |
||
|
|
|
|
денег |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Номер счета |
|
Код банковской |
клиента |
|
сортировки |
|
|
|
Пароли |
Пароли |
Номера счетов |
Коды сортировки |
Домены (множество значений атрибутов)
Атрибут – это характеристики. Но Чен ввел математическое понятие атрибута.
Атрибут – это математическая функция, отражающая набор сущностей во множество значений этих сущностей. Либо функция, отражающая набор связей в набор значений связей или даже их декартовых произведений.
f : Ei→Vi≈ f : Ri →Vi(V1× V2× V3× …).
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 17 |
Диаграмма потоков данных (ДПД, DFD)
ДВД, регулирующая потоки данных фирмы по нотации Йордон/Де Марко
Дополнить |
|
|
|
|
|
|
Дополнить |
|
данных о |
Вновь нанятые |
|
Вновь нанятые |
данных о |
||||
служащих |
сотрудники, уволенные, |
|
служащих |
|||||
сотрудники, уволенные, |
||||||||
|
|
адреса |
|
|||||
|
|
|
|
адреса |
|
|||
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
||
|
|
Данные о персонале |
|
|
|
|
||
|
|
|
|
|
|
История |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
занятости |
|
|
|
|
Адреса |
|
|
|
|
|
|
Составить списки |
сотрудников |
Сведения о |
|
Представить данные |
||||
|
|
|
||||||
|
|
з/п |
|
|
||||
для журнала |
|
|
|
|
об отдельных |
|||
|
|
|
|
|
||||
адресов |
|
|
|
|
|
|
служащих |
|
Составить ведомости для зарплаты
Презентация «Принцип управления распределенной информацией».
Дейт выставил 12 признаков распределенной системы. Среди них есть те, которые практически могут быть реализованы в веке так 25-м
Например: идеальный вывод.
Фирма IBM выставила 4 основные операции, которые реально сейчас можно реализовать и реализовываются:
Удаленный запрос
Удаленная единица работы (транзакция)
Распределнная единица работы
Распределнный запрос.
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 18 |
15.03.2011.
Сегодня рассмотрим:
Языки моделирования при использования ООПарадигмы. История развития.
Язык «Унифицированный язык моделирования (UML)».
Методология RUP (Rational unified Process), Unified Modeling Language (UML).
1989 – 1994. Смутные времена в программной инженерии – не было единого языка моделирования. Каждый разработчик предлагал свой синтаксис, семантику и изобразительные средства. Поэтому исторически сложились три поколения языка моделирования. Первое забыто (10 языков насчитывало). Второе насчитывало 50 нотаций. Очевидно, что была война методов. Групповая разработка – это вообще жопа была.
OMG. ER – диаграммы – надо ознакомиться.
Джекопсон ввел диаграммы Use-case. Буч предложил методологию структуры. Нотация Буча вошла в UML. Рамбо предложил диаграммы последовательностей действий, диаграммы взаимодействия внутри объектов, внутри классов.
UML – это не визуальный язык программирования, это язык позволяет генерировать коды на многих популярных языках программирования (C++, oPascal, ADA95, Java etc).
Методология RUP и пример ее использования на простом примере о торговой фирме.
«Методология» - это некая совокупность приемов, которые обозначают и регламентируют, как и что надо сделать, чтобы разработать качественный программный продукт в отведенные сроки с отведенным бюджетом.
Методология RUP отвечает на следующие вопросы: Какие шаги следует предпринять, чтобы уложиться в отведенные сроки с отведенным бюджетом, построить необходимый программный продукт с заявленными требованиями, удовлетворяющими заказчика. Вот, какие это шаги?:
1.Описание предметной области.
Пример. Есть торговая фирма, несколько торговых точек, администратор (работающий с поставщиками)
Работает с поставщиками использует
администратор
Поставщики
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 19 |
Это была модель предметной области.
1.2.Сценарий работы данной торговой точки.
Прописываем теперь все четко словами (то, что нарисовали). С высокой степень детализации:
У оптовых поставщиков закупается товар.
Закупленный товар помещается на склад торговой точки.
Продавец отпускает товар с торговой точки, принимает деньги, выдает товары со склада.
Продавец фиксирует все продажи в журнале продаж и сдает в конце дня администратору вместе с выручкой.
Прибыль от работы торговой точки формируется за счет разницы между закупочными и продажными ценами на все товары.
1.3.Что следует автоматизировать в данной коммерческой структуре.
Накопление журналов продаж, получаемых от продавцов.
Хранение информации о текущем состоянии на складе (фиксация расходов и приходов).
Получение отчетов о приходе, расходе, прибыли и выручке.
2.Глоссарий. Это спецификация терминов и понятий предметной области, которые потенциально могут быть затронуты при написании этого проекта. Требования: описать словами основные понятия предметной области развернуто, однозначно и очень точно. Он вводится для того, чтобы закрепить определенный смысл определенных понятий.
!Глоссарий создается еще в тот момент, когда система еще только начинает проектироваться, поэтому глоссарий не должен содержать тех понятий, которые касаются реализации. Напр., «метод, который делает то-то и то-то».
Глоссарий (в рамках примера):
Название |
Описание термина |
термина |
|
Товар |
Материальная единица, подлежащая продаже на торговой точке. Товар |
|
поступает на торговую точку от поставщиков по закупочной цене и |
|
продается продавцами по продажной цене. |
Журнал продаж |
Формируется продавцами в течение всего рабочего дня. Содержит в себе |
|
информацию о том, сколько, какого товара было продано в течение |
|
рабочего дня на торговой точке. |
Выручка |
Суммарная стоимость всех товаров, проданных за день на торговой точке. |
|
Присутствует выручка двух типов: фактическая и прогнозируемая. |
Прогнозируемая |
|
выручка |
|
Фактическая |
В идеале совпадают. При их несовпадении получается недостача |
выручка |
|
Недостача |
|
Закупочная цена |
|
Продажная |
|
цена |
|
И т.д. |
|
3.Совладельцы системы (роли).
Совладелец – такой персонаж, который имеет прямое или косвенное отношение к проектируемой системе. В нашей системе – продавец и администратор.
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 20 |
Совладельцем в данной системе является администратор торговой точке. Он же – единственный пользователь автоматизированной системы, принимает товары, смотрит отчеты и т.д.
Вторая роль – продавец. Он не взаимодействует с системой, а значит, не является его пользователем. Он фиксирует в журнале.
4. Границы системы.
Система «продажи»
5.Функциональные требования к системе. Т.е. что должна делать система. «Система должна …». FR = functional Rub. Нумерация идет через 10, чтобы можно было вписать детализацию.
Номер |
Текст |
FR010 |
Система должна позволять просматривать информацию о продавцах, |
|
зарегистрированных в системе |
FR013 |
Система должна позволять вводить информацию о новых продавцах. (13 – это мы |
|
решили сразу детализировать) |
FR016 |
Система должна позволять удалять уволенных продавцов из системы. |
FR017 |
Система должна отображать информацию о состоянии склада (кол-во, список, |
|
цены) |
FR020 |
Поиск, Различия товаров, возможность сделать пересчет (напр., скидка и т.п.). |
|
Отчет-приход должен содержать следующую информацию: дата, код, |
|
наименование, кол-во, закупочная цена за единицу, отпускная цена. |
6.Технические требования.
TR – technical Rub.
Номер |
Текст |
|
TR010 |
Система должна обеспечить хранение информации о следующих объектах: |
|
|
|
Товар |
|
|
Продавец |
|
|
Журнал продаж |
TR020 |
Хранение данной информации должно осуществляться под управлением СУБД: |
|
|
(пишу, какой). |
|
|
И т.д.: какая СУБД, какой язык, какая ОС, какая платформа. |
|
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 21 |