Конечный пользователь формирует свои требования к буду­ щей программе на языке требований (L1)



страница1/3
Дата12.01.2018
Размер77 Kb.
Название файла4 вариант.docx
ТипПрограмма
  1   2   3

4 вариант

3.4.Особенности анализа и синтеза процессов в машиностроении при переходе к автоматизированным системам

Конечный пользователь формирует свои требования к буду­ щей программе на языке требований (L1). В них он указывает, для чего нужна программа, ее общие характеристики, свойства, платфор­ му, на которой она будет выполняться и т.д.2.Один из специалистов предметной области, выступающий в качестве заказчика, на основе требований отдельных пользователей и своих знаний создает спецификацию на языке спецификаций (L2)3.Разработчик-аналитикна основе спецификации заказчика со­ ставляет алгоритм решения задачи на языке проектирования (L3). Аналитик пытается построить алгоритм решения задачи таким обра­ зом, чтобы, с одной стороны, полностью решить задачуРазработчик-программистреализует алгоритм решения зада­ чи на языке программирования (L4 - чаще всего универсальный язык высокого уровня) 5. Конечный пользователь общается с полученной программой на языке общения (L5).



3.4. Особенности анализа и синтеза процессов в машиностроении

229

Традиционный подход несет в себе не только указанные выше не­ достатки, но и недостатки традиционных средств создания программ,

аименно


1.Алгоритмичность программы, так как основное внимание в традиционных системах программирования уделяется не описанию предметной области, а написанию правильного алгоритма решения задачи, что приводит к следующим ограничениям:

•жесткому делению переменных на входные и выходные;

•решению задачи, которое представляется в виде строгой после­ довательности процедур;

•отсутствию модульности при построении системы;

•невозможности работы программы с неполностью определен­ ными данными.

2.Сложность взаимодействия с другими программами.

3.Документация на программу и собственно программа являют­ ся абсолютно разными объектами.

Специалист предметной области ориентируется в первую оче­ редь на создание модели объектов реального мира. В машинострое­ нии деление на объекты и действия с ними достаточно хорошо отрабо­ таны внормативно-справочнойдокументации, что дает следующие преимущества:

•деление на объекты обеспечивает модульность системы;

•переменные являются характеристиками объектов предметной области;

•нет жесткого деления переменных на входные и выходные.

2.Исключение из процесса разработки программного обеспече­ ния профессиональных программистов позволяет:

•уменьшить время разработки программного продукта в 10-15раз;

•уменьшить число ошибок и сократить время отладки;

•упростить сопровождение и модификацию программы.

3.Исходная спецификация является одной из основных состав­ ляющих документации на программу.



Объектная методика базируется на следующих шести компо­ нентах:

Диаграмма вариантов использования ( Use Case Diagram) пе­ речисляет требования, которые должна обеспечить система (информационная или производственная). Основные элемен­ ты модели - роли (пользователи системы) и вариант использо­ вания автоматизированной системы (предоставляемый сер­ вис). Если речь идет о программном обеспечении, то варианты использования с некоторым приближением можно считать ав­ томатизируемыми операциями.

Диаграмма взаимодействия (Interaction Diagram) описывает порядок взаимодействия участников (объектов) в процессе ре­ ализации варианта использования системы. Существует две разновидности диаграмм взаимодействия - диаграмма после­ довательности (Sequence Diagram) и диаграмма сотрудничест­ ва (Collaboration Diagram). Эти диаграммы фактически пред­ ставляют одну и ту же информацию в разном виде и часто мо­ гут быть автоматически получены друг из друга в объектныхCASE-системах. Диаграмма взаимодействия вместе с диаграм­ мой вариантов использования применяется при описании как программных, так и производственных систем.

Диаграмма классов (Class Diagram) является основной моде­ лью объектной методики. В некотором смысле ее можно счи­ тать развитием диаграммы «сущность - связь». Классы также представляют сущности описываемой автоматизированной си­ стемы (программной или производственной), но обладают до­ полнительными свойствами - поведением, абстрактностью, стереотипом. Связи между классами также значительно бога­ че, имеется наследование свойств, агрегация, реализация и многое другое. Основное применение модели классов - описа­ ние программного обеспечения, хотя эта модель подходит и для описания производственных систем.

Диаграмма состояний (Statechart Diagram) немного модифи­ цированная диаграмма переходов состояний. Служит для


3.4. Особенности анализа и синтеза процессов в машиностроении

241

спецификации состояний объекта, меняющихся в зависимости от развития событий.

Диаграмма действий (Activity Diagram) представляет собой модель, похожую на структурную схему программы. Показы­ вает последовательность выполнения операций (действий).

Диаграмма реализации (Implementation Diagram) показывает структуру созданного программного обеспечения. Имеется два вида диаграмм реализации: диаграмма компонентов (Compo­ nent Diagram) показывает структуру исходного кода, диаграм­ ма размещения (Deployment Diagram) - структуру исполняе­ мого программного обеспечения.



Поделитесь с Вашими друзьями:
  1   2   3


База данных защищена авторским правом ©coolnew.ru 2017
обратиться к администрации

    Главная страница