Розробка об’єктно-орієнтованої програми “Магазин”

 

2.1.4 Опис користувацького інтерфейсу

Грамотно спроектований інтерфейс користувача дуже важливий для успішної роботи системи. Складний інтерфейс приводить до помилок користувача. В даний час усюди використовується графічний інтерфейс.

Основні елементи графічного інтерфейсу користувача: вікна, піктограми, меню, покажчики, графічні елементи. Зовнішній вигляд вікна з елементами управління приведений на малюнку 3.

 

Малюнок 3. Схема зовнішнього виду головного вікна програми

 

 Принципи проектування інтерфейсів  користувача.

Розробникам необхідно ураховувати фізичні і розумові здібності людей, які працюватимуть з ПО, тому основою принципів проектування інтерфейсів користувача є людські можливості.

Основні принципи проектування інтерфейсів  користувача:

Необхідно використовувати терміни  і поняття, які знайомі і зрозумілі користувачам;

Однотипні операції повинні виконуватися одним і тим же способом;

Не повинно бути несподіванок, поведінка  системи повинна бути прогнозованою, схожі дії повинні справляти  схоже враження;

Повинні бути засоби, що дозволяють користувачам відновити дані після помилкових дій. Для цього використовується підтвердження деструктивних дій і можливість відміни дій.;

Повинна бути обширна довідкова  інформація, надаватися необхідна інформація при помилках користувача і підтримуватися контекстна довідка;

Повинні бути засоби для зручної  взаємодії з користувачами, має  різний рівень кваліфікації.

 Взаємодія з користувачем.

Розробник інтерфейсу повинен вирішити дві головні задачі:

Яким чином користувач вводитиме  дані в систему і Як дані будуть представлені користувачу.

Хороший інтерфейс повинен забезпечувати  і взаємодія з користувачем і  представлення інформації.

Для взаємодії можна використовувати  наступні стилі:

• Безпосереднє маніпулювання. Користувач взаємодіє з об'єктами на екрані, наприклад, для видалення файла перетягує його в корзину.
• Вибір з меню. Часто вибрана команда діє тільки на виділений об'єкт.
• Заповнення форм. Заповнюється екранна форма. На формі можуть бути кнопки, списки, меню і т.д.
• Командна мова. Користувач вводить конкретну команду з параметрами.
• Природна мова. Користувач вводить команду на природній мові.

У принципі необхідно  застосовувати різні стилі для  управління різними об'єктами.

2. Проектування програмної системи

Процес об'єктно-орієнтованого  проектування складається з декількох етапів:

• Визначення робочого оточення системи і розробка моделей її використовування.
• Цей етап полягає у виявленні взаємостосунків між проектованим ПО і його оточенням. Модель оточення системи і модель використовування системи є доповнюючою один одного.
• Модель оточення системи – це статична модель, яка описує інші системи з оточення розробляється ПО.
• Модель використовування системи – динамічна модель, яка показує взаємодію даної системи з своїм оточенням.
• Проектування архітектури системи. Слід розкласти систему на частини так, щоб архітектура була якомога простіше.
• Визначення основних об'єктів системи. На цьому етапі визначаються класи об'єктів. Визначаються класи об'єктів і для кожного класу описуються властивості і методи.
• Розробка моделей архітектури системи. Моделі системної архітектури показують взаємостосунки між класами об'єктів.
• Визначення інтерфейсів об'єкту. Це власне методи об'єктів, що дозволяють взаємодіяти об'єктам один з одним.

Чітка послідовність  етапів не обов'язкова. Фактично всі  етапи можна виконувати паралельно, з взаємним впливом один на одного.

 

Моделі архітектури.

Моделі системної архітектури  показують об'єкти і класи об'єктів, що складають систему і типи взаємостосунків між ними. Такі моделі служать мостом між вимогами до системи і її реалізацією. Тому моделі повинні бути достатньо абстрактними, щоб зайві дані не приховували відношення між моделлю архітектури і вимогами до системи. Проте, щоб програміст міг ухвалювати рішення по реалізації, модель повинна містити достатню кількість інформації. Суперечність. Щоб її обійти можна розробити декілька моделей різного рівня деталізації. Існують два типи об'єктно-орієнтованих моделей системної архітектури:

Статичні моделі, які описують статичну структуру системи в термінах класів об'єктів і взаємостосунків між ними. Основними взаємостосунками, які документуються на даному етапі, є відносини узагальнення, відносини “використовують-використовуються", і структурні відносини.

Динамічні моделі, які описують динамічну структуру системи і показують взаємодії між об'єктами системи (але не класами об'єктів). Документи містять послідовність складених об'єктами запитів до сервісів і описують реакцію системи на взаємодії між об'єктами.

 

1. Визначення і опис класів

Моделі системної архітектури  показують об'єкти і класи об'єктів, що складають систему і типи взаємостосунків  між ними. Такі моделі служать мостом між вимогами до системи і її реалізацією. Тому моделі повинні бути достатньо  абстрактними, щоб зайві дані не приховували відношення між моделлю архітектури і вимогами до системи. Проте, щоб програміст міг ухвалювати рішення по реалізації, модель повинна містити достатню кількість інформації. Суперечність. Щоб її обійти можна розробити декілька моделей різного рівня деталізації.

Статичні моделі, які  описують статичну структуру системи  в термінах класів об'єктів і взаємостосунків  між ними. Основними взаємостосунками, які документуються на даному етапі, є відносини узагальнення, відносини  “використовують-використовуються", і структурні відносини.

 

 

 

 

 

 

 

 

 

 

Малюнок 4. Діаграма класів

Основним засобом представлення  статичних моделей є діаграми класів.

Вершини діаграм є  класами, а дуги – відносини між  ними. Для кожної вершини указується ім'я класу, перелік властивостей і операцій.

Діаграми використовуються :

В ході аналізу – для  вказівки ролей і обов'язків єств, які забезпечують поведінку системи;

В ході проектування –  для фіксації структури класів, які  формують системну архітектуру.

 

Для відносин узагальнення будується ієрархія класів. Ієрархія дозволяє визначити спадкоємство і поліморфізм. Абстрактний клас (тобто клас не має екземплярів) можна записати курсивом.Щоб показати, що клас кореневий – використовується опис root.

 

 

 

 

 

Малюнок 5. Ієрархія класів

 

Опис властивостей класів програми наведений в таблиці 1.

 

Tаблиця 1. Опис властивостей класів

Клас	Ідентифікатор  властивості	тип	Опис
Pram	C	рядковий	Колір заливки
	X	числовий	Координата х вехнього лівого кута
	Y	числовий	Координата у вехнього лівого кута
	H	числовий	Висота
	W	числовий	Довжина
Otdel	Name	рядковий	Назва відділу

 

Продовження таблиці 1

Tovar	N	числовий	Назва товару
	Tip	рядковий	Тип товару

 

Опис методів класів наведений у таблиці 2.

 

Таблиця 2. Опис методів класів

Клас	Заголовок методу	Опис формальних параметрів	Призначення
Pram	public void show(Graphics g1)	g1-об'єкт класу Graphics	Малювання обєкту прямокутника
	public void hide(Graphics g1)	g1-об'єкт класу Graphics	Видалення обєкту
Otdel	public void show(Graphics g1)	g1-об'єкт класу Graphics	Малювання обєкту відділу
Tovar	public void show(Graphics g1)	g1-об'єкт класу Graphics	Малювання обєкту товару
	public void move(Graphics g1, int n, int m)	N- номер відділу, m-номер місця	Переміщення товару до відділу

 

 

 

2. Схеми алгоритмів модулів

 

Алгоритм основної програми наведений на малюнку 6.

 

 

 

 

        Доки не вихід

 

           

 

 

 

    

                                                             

 

 

            

             

     Пункт = Выход

 

 

 

 

Малюнок 6. Алгоритм основної програми

 

 

 

 

 

 

 

 

 

 

 

 

                           так    ні

 

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Малюнок  7. Алгоритм підпрограми продажу товару

 

 

 

 

2.3  Реалізація програмної  системи

 

Засобом представлення  моделей реалізації є діаграми:

• Компонентні діаграми
• Діаграми розміщення

 

Компонентні діаграми

 

Компонентні діаграми показують  організацію набору компонентів  і залежності між компонентами. 

Елементами компонентних діаграм є компоненти і інтерфейси, а також відносини залежності і реалізації.

Компонент – це фізичний фрагмент реалізації системи, який містить  в собі програмний код (початковий, двійковий, виконуваний), командні файли. Компонент є частиною системи, яка  відповідає набору інтерфейсів і  забезпечує реалізацію цього набору інтерфейсів.

Компонент – базисний будівельний  блок фізичного уявлення ПО. Клас –  базисний будівельний блок логічного  уявлення ПО. Компоненти реалізують класи. В одному компоненті може бути реалізовано  декілька класів. Компоненти взаємодіють  між собою за допомогою інтерфейсів.

Інтерфейс – це список операцій, які визначають послуги  класу або компоненту. За допомогою  інтерфейсів компоненти об'єднуються  в систему.

За способом зв'язку компоненту з інтерфейсом розрізняють:

Інтерфейс що експортується  – той, який компонент реалізує і пропонує як послугу компонентам;

Інтерфейс що імпортується – той, який компонент використовує як послугу іншого компоненту..

У одного компоненту можуть бути декілька інтерфейсів що експортуються  і дещо імпортуються.Наявність інтерфейсу у компонент усуває пряму залежність між компонентами.

Компонентні діаграми використовують для моделювання статичного представлення  реалізації системи. Вважається, що для  отримання працюючої системи  існують різні способи збірки компонентів.