Скачать презентацию Программная инженерия Лекция 5 МОДЕЛИ СИСТЕМ 2 Скачать презентацию Программная инженерия Лекция 5 МОДЕЛИ СИСТЕМ 2

Лекция-5Программная инженерия.ppt

  • Количество слайдов: 30

Программная инженерия Лекция 5 МОДЕЛИ СИСТЕМ (2) Программная инженерия Лекция 5 МОДЕЛИ СИСТЕМ (2)

Цели лекции Читать: Соммервил, стр. 149 - 164 Цели лекции Читать: Соммервил, стр. 149 - 164

Темы лекции Темы лекции

Системные требования к ИС – это ответы на вопросы: КТО (взаимодействуетдействует) КОГДА (взаимодействуетдействует) ГДЕ Системные требования к ИС – это ответы на вопросы: КТО (взаимодействуетдействует) КОГДА (взаимодействуетдействует) ГДЕ (…. ) ДЛЯ ЧЕГО (цель действия) ПОЧЕМУ (так, а не иначе) ЧТО (получается в результате взаимодействиядействия)

Для документирования системных требований строят модели системы Детализированное описание системы удобнее представлять Графическими моделями Для документирования системных требований строят модели системы Детализированное описание системы удобнее представлять Графическими моделями в виде схем, диаграмм, рисунков, условных обозначений и т. п. Важным свойством системного моделирования является то, что оно опускает детали (т. е. НЕ ВКЛЮЧАЕТ «мелкие» детали в системную модель, «абстрагируется» от деталей) Это делает анализ модели более простым

Различные подходы к «абстрагированию» приводят к разным типам моделей: Различные подходы к «абстрагированию» приводят к разным типам моделей:

1. Модели системного окружения Первый шаг в построении модели системного окружения – определить ГРАНИЦЫ 1. Модели системного окружения Первый шаг в построении модели системного окружения – определить ГРАНИЦЫ СИСТЕМЫ Второй шаг – специфицируется (т. е. строго определяются) само рабочее окружение и связи между ним и системой

1. Модели системного окружения 1. Модели системного окружения

2. Поведенческие модели 2. 1 Модели потоков данных 2. Поведенческие модели 2. 1 Модели потоков данных

2. Поведенческие модели 2. 1 Модели потоков данных 2. Поведенческие модели 2. 1 Модели потоков данных

2. 2 Модели конечных автоматов Пример микроволновой печи, модель которой определяет фунции: 2. 2 Модели конечных автоматов Пример микроволновой печи, модель которой определяет фунции:

2. 2 Модели конечных автоматов 2. 2 Модели конечных автоматов

2. 2 Модели конечных автоматов. Агрегирование состояний 2. 2 Модели конечных автоматов. Агрегирование состояний

3. Модели данных 3. Модели данных

4. Объектные модели 4. Объектные модели

4. Объектные модели (модели наследования свойств) 4. Объектные модели (модели наследования свойств)

4. Объектные модели (модели агрегирования объектов) 4. Объектные модели (модели агрегирования объектов)

Objects Don’t Accept Arbitrary Calls Acceptable calls are defined by object “methods” (a. k. Objects Don’t Accept Arbitrary Calls Acceptable calls are defined by object “methods” (a. k. a. Operations, Procedures, Subroutines, Functions) Object: ATM machine method-1: Accept card method-2: Read code method-3: Take selection

Object Interface defines method “signatures” Method signature: name, parameters, parameter types, return type Interface Object Interface defines method “signatures” Method signature: name, parameters, parameter types, return type Interface method-1 method-2 method-3 Object hides its state (attributes). The attributes are accessible only through the interface.

Clients, Servers, Messages • Objects send messages by calling methods • Client object: sends Clients, Servers, Messages • Objects send messages by calling methods • Client object: sends message and asks for service • Server object: provides service” and returns result

Interfaces • An interface is a set of functional properties (services) that a software Interfaces • An interface is a set of functional properties (services) that a software object provides or requires. • Methods define the “services” the server object implementing the interface will offer • The methods (services) should be created and named based on the needs of client objects that will use the services • “On-demand” design—we “pull” interfaces and their implementations into existence from the needs of the client, rather than “pushing” out the features that we think a class should provide

Object-Oriented versus Process-Oriented Approaches Object-Oriented versus Process-Oriented Approaches