Методы проектирования 1С (SSADM).
Особенностью методологии SSADM является наличие развернутого метода обеспечения и в частности наличие методов проектирования и методик в отличии от других методологий.
Назначение методов проектирования состоит в структурной поддержке ЖЦ ИС, однако не все методы используются на всех стадиях проектирования (макропроектирование и микропроектирование). Использование методов дает возможность перейти от концептуально-логического к физическому проектированию, более детальному выбору применяемых инструментальных средств.
Методы:
1. Варианты бизнес-структуры (БП, бизнес-цели) – позволяет на ранних стадиях проектирования определить вариант бизнес-системы исходя из Ц, Тр (ТЭО). Применяется на стадиях АР и АТ.
2. Моделирование потоков данных – используется для представления существующих и желаемых данных в виде информационного пространства для обеспечения реализации функциональности. Стадии АР, АТ, СТ.
3. Проектирование диалога для реализации функций ИС исходя из класса задач. АР, АТ, СТ, СЛС.
4. Объекто-событийное моделирование предметной области (организационная и функциональная структура) позволяет определить функции каждого структурного подразделения функциональную структуру ИС. Применяется СТ, СЛС.
5. Метод определения функций – позволяет уточнить окончательный вариант функциональной структуры, применяют с объектно-событийными моделями.
|
|
|
6. Метод логического моделирования данных – дает возможность разработать ЛМД, установить взаимосвязи данных при реализации функциональных задач с целью сокращения оперативной памяти, минимизацией времени запросов, снизить нагрузку на каналы связи. Стадии АР, АТ, СТ.
7. Проектирование логических процессов обработки данных и запросов – позволяет оптимизировать структуру КСА за счет оптимизации режимов обработки данных и запросов. СЛС.
КМ UML. Назначение и особ-ти разраб-ки КМ
Разраб-ка КМ осущ по неск циклам. Напр, в первонач цикле реализ-ции прец-та «Покупка тов» рассматр только прцедура «Оплата только наличн» на следующ стадиях цикла должна быть получена рассшир КМ
Назначен КМ сост в описан основных, с точки зрен моделирующего, понятий (объектов) ПрО
Идентификация понятий – составная часть исслед-я ПрО
КМ на UML опис статич структурн диаграммами
Важным св-вом КМ явл-ся представление понятий ПрО, а не артефактов прогр компонентов
Процесс создан КМ завис от описаний предметов, док-ов, позволяющий идентифицир объекты
Можно осущ проц разраб-ки КМ параллельно с создан прец-тов
КМ может отображ: 1)понятия; 2)ассоциации меду понятиями (связи); 3)атрибуты объекта
|
|
|
КМ не только позвол осущ декомпозицию ПрОна различн мн-во объектов, но и опред терминологию и словарь терминов ПрО
Описан ПрО в рамках КМ отлич от описаний прогр эл-тов, поэтому в КМ ПрО не использ-ся: 1)артефакты прогр средств (окна, БД), но если КМ не явл-ся прогр сис; 2)описан методов.
КМ UML. Добавление атрибутов и ассоциаций
Опр-е ассоциаций КМ ПрО
В проц разраб-ки КМ после опр-я понятий (объектов) необход опр связи между ними.
Ассоц-я – связь между понятиями, отраж-щая некоторое значимое и полезн отнош-е между ними.
В яз UML ассоц-я – это структурн взамосвязи между различн объектами.
Ассоц-я обознач-ся стрелками, иногда двунаправленными. Связь-абстрактна. Ассоц-я имеет имя, кратность. Имя ассоц-глагол, кот устан-ет функц-сть взаимоотнош-й между понятиями.
Поиск ассоц-й осущ-ся по принципу их полезности с точки зрен сохранен инф о взаимоотнош объектов в течен некотор-го врем.
В КМ включ-ся такие ассоц: сохраняемые(важные); производные ассоц от стандартных.
Сущ список станд-ных ассоц: А физически содерж-ся в В; А явл-ся физич-ой частью В (касса-магазин); А явл логич частью В (эл-т продажи-продажа); А логически содерж-ся в В (товар-каталог); А явл описанием В (опис-е товара-товар); А явл эл-том транзакции или отчета В (продажа-магазин); А явл членом В(пилот-самолет); А управляет В (кассир-магазин); А следует за В (в полете город-город); А явл собственностью В(крыло-самолет).
|
|
|
Ассоц бывают не только простые, но и с высоким приоритетом. Ассоц важны, но их детализац не всегда необходима.
При поиске ассоц необход руковод-ся следующим: 1.опр-ть те ассоц, кот сохр-ся длительн время (важные ассоц); 2.важнее опр-е понятий, чем ассоц; 3.большое кол-во ассоц приводит к созданию сложн КМ и их ошибкам; 4.необход избегать излишних ассоц.
Кажд ассоц заканчив-ся ролью, кот имеет имя, кратность.
Использ-е только важных ассоц позвол получить КМ, кот не дает полн представлен об особен-тях ПрО. Хорошей счит-ся та модель, кот наход-ся между моделью с важн ассоц и мод с всевозможными ассоц. (Рис 1. КМ розничной торговли).
Реинженеринг ИС.
Реинжениринг ИС связано с моральным и физическим ее старением. В связи с этим выделяют 2 основные группы факторов, требующих необходимость проведения реинжениринга:
1. Связана с моральным и физическим старением применяемых программных и инструментальных средств в структуре ИС;
2. Связана с использованием в рамках существующей технологии управления объектом использующих новые устройства, приборы, датчики, преобразователи, обеспечивающих современный технологический процесс.
|
|
|
Содержательный анализ структуры, унаследованной ИС дает возможность выделить 3 основных блока УИС:
1. Изменение даннях программого обеспечения
2. Изменение программных средств
3. Изменение ТС
Выделение таких частей и необходимость реинжениринга осуществляется на основании анализа функционирования УИС на конкретних момент времени (на основании экспертных оценок).
Особенност УИС характеризуют степень необходимости проведения реинжениринга:
1. Обработка больших объемов информации, что ведет к дублированию, избыточности, нарушению целостности даннях, а следовательно к высокой вероятности потери даннях
2. Появление за длительный срок эксплуатации различных прикладних программ, разработки с использованием различных инструментальных средств, что приводит к увеличению стоимости сопровождения ПО
3. Неполнота документации на
Для того, чтобы оценить состояние УИС, оценивают следующие внутренние параметры:
- Возраст эксплуатации системы;
- Статистика сбоев
- Наличие полной документации
- Наличие или отсутствие диагностированных средств тестирования
- степень конфигурации систем, ее интегрируемость.
Внешними признаками являются: необходимость взаимодействия с другими ИС, а также наличие на рынке труда соответствующих специалистов
Модель потоков даних.
Модель потоков данных включает организационный, элементный и функциональный аспекты, где организационный и элементный аспекты описываются нормативной моделью. Модель потоков данных определяет перечень укрупненных операций на предприятии и их взаимосвязи по информационным, материальным и финансовым потокам, которые будет использоваться в модели «Как надо», начиная с третьего уровня декомпозиции. Модель потоков данных отвечает на вопрос «Какие ресурсы задействованы при выполнении конкретных работ?». Модель потоков данных базируется на ИС предприятия (ИС класса ERP).
Дата добавления: 2018-02-15; просмотров: 1318; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!