Tải bản đầy đủ (.pdf) (30 trang)

Software design: Lecture 44 - Sheraz Pervaiz

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (306.11 KB, 30 trang )

1

Software Design
Lecture : 44


2

Architectural Design Patterns


3

Overview of Architectural Design 
Patterns
Architectural  patterns  express  fundamental 
structural  organization  schemas  for  software 
systems.  They  provide  a  set  of  predefined 
subsystems,  specify  their  responsibilities,  and 
include  rules  and  guidelines  for  organizing  the 
relationships between them.


4

Main Categories
i.

Interactive

ii. Distributed


iii. Broker 


5

Interactive Systems
Today's  systems  allow  a  high  degree  of  user 
Interaction,  mainly  achieved  With  help  of  graphical 
user  Interfaces.  The  objective  is  to  enhance  the 
usability  of  an  application.  Usable  software  systems 
provide  convenient  access  to  their  services,  and 
therefore  allow  users  to  learn  the  application  and 
produce results quickly.


6

Challenge
When  specifying  the  architecture  of  such 
systems,  the  challenge  is  to  keep  the  functional 
core independent of the us
The  core  of  Interactive  systems  is  based  on  the 
functional  requirements  for  the  system,  and 
usually remains stable. User Interfaces, however, 
are  often  subject  to  change  and  adaptation.er 
interface.


7


Interactive Architectural Patterns
i.

Model­View­Controller pattern (MVC)

ii. Presentation­Abstraction­Control pattern 
(PAC)


8

Model View Controller


9


10

Context of the Problem
 Interactive applications with a flexible human­
computer interface.

 One Data with multiple possible representations


11

Problem
i.


User interfaces are especially prone to change requests. 
When  you  extend  the  functionality  of  an  application, 
you must modify menus to access these new functions. 

ii. A  customer  may  call  for  a  specific  user  interface 
adaptation,  or  a  system  may  need  to  be  ported  to 
another  platform  with  a  different  'look  and  feel' 
standard.


12

Problem
 Different users place conflicting requirements on the user 
interface.

 A typist enters information into forms via the keyboard. 
 A  manager  wants  to  use  the  same  system  mainly  by 
clicking icons and buttons.

 Consequently.  support  for  several  user  interface 
paradigms should be easily incorporated.


13

Traditional Approach
 Building  a  system  with  the  required  flexibility  is 
expensive and error prone if the user interface is tightly 

interwoven with the functional core.

 This  can  result  in  the  need  to  develop  and  maintain 
several  substantially  different  software  systems.  one  for 
each  user  interface  implementation.  Ensuing  changes 
spread over many modules.


14

Solution
Basic parts of any application:
i.

Data being manipulated

ii. A user­interface through which this manipulation 
occurs
iii. The data is logically independent from how it is 
displayed to the user
▫Display should be separately designable/evolvable


15

MVC Overview
Model­View­Controller  (MVC) is  a  classic 
design  pattern  often  used  by  applications  that 
need the ability to maintain multiple views of the 
same data.


The MVC pattern hinges on a clean separation of 
objects into one of three categories


16

Components of MVC
The  Model­View­Controller  architectural  pattern 
(MVC)  divides  an  interactive  application  into 
three components mainly:

i.

Model

ii. View 
iii. Controller


17

Components
i.

The model contains the core functionality and 
data.  The  model  is  independent  of  specific 
output representations or input behavior.

ii. View components display information to the 

user. A view obtains the data from the model. 
There can be multiple views of the  model.
• Each view has an associated controller 
component. Controllers receive input, usually 
as events that encode mouse movement, 
activation of mouse buttons, or keyboard 
input. Events are translated to service


18

Controller
Each  view  has  an  associated  controller   
component.  Controllers  receive  input,  usually  as 
events  that  encode  mouse  movement,  activation 
of mouse buttons, or keyboard input. Events are 
translated  to  service  requests  for  the  model  or 
the view. The user interacts with the system
   solely through controllers.


19

Mapping of MVC with Java
View is a Swing widget (like a Jbutton etc)
Controller is an ActionListener (Event Handler)
Model is an ordinary Java class (or database)


20


Alternate Mapping of MVC to 
Java
• View is a Swing widget and includes (inner) 
ActionListener(s) as event handlers

• Controller is an ordinary Java class with “business 
logic”, invoked by event handlers in view

• Model is an ordinary Java class (or database)


21

Pictorial Representation of MVC


22


23


24

Example of MVC


25


i.

Model:



The  HTML  is  the  "skeleton"  of  bedrock  content.  Text 
that communicates information to the reader.

ii. View:


The CSS adds visual style to the content. It is the "skin" 
that  we  use  to  flesh  out  our  skeleton  and  give  it  a 
particular look. We can swap in different skins via CSS 
without altering the original content in any way. They 
are relatively, but not completely, independent.


×