pattern - mathunipdconte/lezioni/pattern_p2(x4).pdfcustomer profile order management shopping cart...

© Renato Conte - Pattern II- 1/48 -

Pattern seconda parte

Università di Padova

Facoltà di Scienze MM.FF.NN

Informatica - anno 2008-09

Corso di Ingegneria del Software

rel. 1.7


Types of software patterns

• design patterns (software design) – architectural (systems design) [POSA]*– design (micro-architectures) [Gamma-GoF]– idioms (low level)

➢ analysis patterns (recurring & reusable analysis models) [Flower]➢ organization patterns (structure of organizations/projects) ➢ process patterns (software process design)

➢ domain-specific patterns➢ ...

* Pattern Oriented Software Architecture


Types of patterns• Architectural Patterns

Expresses a fundamental structural organization or schema for software systems

• Design Patterns Provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context.

• Idioms

An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. An Idiom is a low-level pattern specific to a programming language.


...other good guidance ...

some GRASP


GRASPGeneral Responsibility Assignment Software Patterns

(Pattern generali per l’assegnamento delle responsabilità nel software)

Which class, in the general case is responsible?• You want to assign a responsibility to a class• You want to avoid or minimize additional dependencies• You want to maximise cohesion and minimise coupling• You want to increase reuse and decrease maintenance• You want to maximise understandability• …..etc.


Low Coupling

Problem:To support low dependency and increased reuse?

Solution:Assign responsibilities so that coupling remains low.


In object oriented languages, common form of coupling from TypeX to TypeY include:

• TypeX has an attribute (data member or instance variable) that refers to a TypeY instance, or TypeY itself.

• TypeX has a method which references an instance of TypeY, or TypeY itself, by any means. These typically include a parameter or local variable of type TypeY, or the object returned from a message being an instance of TypeY.

• TypeX is a direct or indirect subclass of TypeY.• TypeY is an interface, and TypeX implements

that interface.

Coupling?

TypeYTypeY

TypeXTypeX

??


• Coupling is a measure of how strongly one class is connected to, has knowledge of, or relies upon other classes.

• A class with high coupling relies upon many other classes; this is undesirable because:– Changes in related classes force local changes;– Harder to understand in isolation;– Harder to reuse because its use requires the

additional presence of classes it is dependent upon

Coupling?


Low coupling

How can we make classes independent of other classes?

• Classes are easier to maintain • Easier to reuse• Changes are localized


High Cohesion

Problem:To keep complexity manageable?

Solution:Assign responsibilities so that cohesionremains high.


Cohesion

• Cohesion is a measure of how strongly related and focused the responsibilities of a class are.

• A class with low cohesion does many unrelated things or does too much work.

• Low cohesion brings the following problems:– hard to comprehend– hard to reuse– hard to maintain– delicate; constantly effected by change


Some examples:

• Very Low Cohesion: A Class is solely responsible for many things in very different functional areas

• Low Cohesion: A class has sole responsibility for a complex task in one functional area.

• High Cohesion. A class has moderate responsibilities in one functional area and collaborates with classes to fulfil tasks.


High cohesion

• Classes are easier to maintain • Easier to understand• Often support low coupling• Supports reuse because of fine grained

responsibility



Architectural Patterns

Architectural patters represent the highest-level patterns in our pattern system. They help you to specify the fundamental structure of an application.

Every development activity that follows is governedby this structure-for example, the detailed design of subsystems, the communication and collaboration between different parts of the system, and its later extension.

Each architectural pattern helps you to achieve a specific global system property, such as the adaptability of the user interface.


Architecture defined

Architecture establishes the context for design and implementation

CODE

implementation

design

architecture

Architectural decisions are the most fundamental decisions; changing them will have significant ripple effects.


pattern architetturale [Buschmann+al., 1996]

Un pattern architetturale esprimeun'organizzazione fondamentale dellastruttura o lo schema di un sistema software.

Definisce un insieme di sotto-sistemipredefiniti, specifica le loro responsabilità, einclude regole e linee guida per organizzarele relazioni tra di loro.


Architectural Patterns

high-level system subdivisions• Layers pattern

• Pipes and Filters• Blackboard pattern

adaptable systems

• Microkernel pattern

• Reflection

interactive systems

• Presentation-Abstraction-Control

• Model View Controller

distributed systems

• Broker Pattern


Layers pattern

• The Layers pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction

• Apart from the usual advantages of modular software with well defined interfaces, the tier architecture is intended to allow any of the tiers to be upgraded or replaced independently as requirements or technology change.


Layers examples

networking protocols


multi-layer (multi-tier)

GUI

Vendita

Presentazione Logica Applicativa

Pagamenti

Memorizzazione Dati

DatabaseBroker

SecurityManager

Oggetti deiservizi

per l’accessoai dati

Oggetti deldominio

del problema

Database

Application TierLogic TierBusiness Logic Tier

Data TierPresentation Tier


Layered System Architecture ( & reusable objectsreusable objects)

ComponentSystem

ComponentSystem

ComponentSystem

ApplicationSystem

ApplicationSystem

ApplicationSystem

ComponentSystem

ComponentSystem

Car Sales Management

Customer profileOrder management

Shopping cartCredit card

authorization

Object persistency Object persistency mechanismmechanism

Application-general layer

Middleware layer

Application-specificlayer

System-softwarelayer

ComponentSystem

ComponentSystem


Model-View-Controller pattern

The Model-View-Controller pattern (MVC) divides an interactive application into three components:

• The model contains the core functionality and data.

• Views display information to the user

• Controllers handle user input

Views and controllers together comprise the user interface.

A change-propagation mechanism ensures consistency between the user interface and the model


MVC: diagramma delle classi


Model-View-Controller

Get DataState Change Notification

• Model– Encapsulates Data

presented by view• View

– Renders Model Data• Controller

– Model Controller– View Controller– Responds to user actions

Model is loosely coupled from view– State change communicated

through notification. – Multiple views can be

implemented for same model

:View

:Controller

:Model

Call Model Action

User ActionsUser Actions

User Event

© Renato Conte - Pattern II- 27/48 - © Renato Conte - Pattern II- 28/48 -

Esempio di diagramma di comunicazione per un MVC


Presentation-Abstraction-Control pattern

The Presentation-Abstraction-Control pattern (PAC) defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.


PAC

hierarchical structure of agents


Presentation-Abstraction-Control


PAC


pac


Broker pattern

The Broker pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions.

CORBA

Browser Web

© Renato Conte - Pattern II- 35/48 - © Renato Conte - Pattern II- 36/48 -

Blackboard pattern

The Blackboard pattern is useful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution.


blackboard


blackboard


Reflection pattern

The Reflection pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.


reflection


Microkernel pattern

The Microkernel pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.


microkernel


Pipes and Filters pattern

The Pipes and Filters pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems.


pipe


pipe


Bibliografia

Craig LarmanApplying UML and Patterns An Introduction to Object-Oriented Analysis and Design and Iterative DevelopmentEdition 3 2004 0-13-148906-2

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.Design Patterns: Elements of Reusable Object-Oriented SoftwareAddison-Wesley Professional Computing Series - 1994

F. Buschmann,R. Meunier,H. Rohnert,P. Sornmerlad,M. StalPATTERN-ORIENTED SOFTWARE ARCHITECTUREJohn Willey & sons- 1996


Web reference•http://www.cetus-links.org/oo_patterns.htmlhttp://www.cetus-links.org/oo_patterns.html

• The Patterns Home Page - hillside.net/patterns/Hosted by The Hillside Group provides information about patterns, links to online patterns, papers and books dealing with patterns, and patterns-related mailing lists.

• The Patterns-Discussion - g.oswego.edu/dl/pd-FAQ/pd-FAQ.htmlFAQ maintained by Doug Lea provides a very thorough and highly readable FAQ about patterns.

• Patterns and Software -www.enteract.com/~bradapp/docs/patterns-intro.html Essential Concepts and Terminology by Brad Appleton provides another thorough and readable account of the patterns field.

•Patterns - home.earthlink.net/~huston2/dp/patterns.htmlDozens of 1-page examples in C++ and Java. Before-and-After refactoring examples. Book summaries.

pattern - mathunipdconte/lezioni/pattern_p2(x4).pdfcustomer profile order management shopping cart...

Documents