Architectural Patterns Expresses a Fundamental Structural Organization Or Schema for Software Systems

Università di Padova Types of software patterns Facoltà di Scienze MM.FF.NN Informatica - anno 2008-09 • design patterns (software design) Corso di Ingegneria del Software – architectural (systems design) [POSA]* – design (micro-architectures) [Gamma-GoF] – idioms (low level) Pattern

seconda parte ➢ analysis patterns (recurring & reusable analysis models) [Flower] ➢ organization patterns (structure of organizations/projects) ➢ process patterns (software process design) ➢ domain-specific patterns ➢ ... rel. 1.7 * Pattern Oriented Software Architecture

Types of patterns • Architectural Patterns Expresses a fundamental structural organization or schema for software systems

• Design Patterns ...other good guidance ... 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 some GRASP 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.

© Renato Conte - Pattern II- 3/48 - © Renato Conte - Pattern II- 4/48 - GRASP Low Coupling General Responsibility Assignment Software Patterns (Pattern generali per l’assegnamento delle Problem: Which class, in the general case is responsible? To support low dependency and increased reuse? • You want to assign a responsibility to a class • You want to avoid or minimize additionalresponsabilità dependencies Solution: • You want to maximise cohesion and minimise coupling nel software) • You want to increase reuse and decrease maintenance Assign responsibilities so that coupling • You want to maximise understandability remains low. •…..etc.

Coupling? Coupling? In object oriented languages, common form of coupling from TypeX to TypeY include: • Coupling is a measure of how strongly one class is • TypeX has an attribute (data member or instance variable) that refers to a TypeY instance, or connected to, has knowledge of, or relies upon TypeX TypeY itself. other classes. ? • TypeX has a method which references an instance of TypeY, or TypeY itself, by any means. • A class with high coupling relies upon many other These typically include a parameter or local classes; this is undesirable because: variable of type TypeY, or the object returned TypeY – Changes in related classes force local changes; from a message being an instance of TypeY. – Harder to understand in isolation; • TypeX is a direct or indirect subclass of TypeY. – Harder to reuse because its use requires the • TypeY is an interface, and TypeX implements that interface. additional presence of classes it is dependent upon

How can we make classes independent of other classes?

Problem: • Classes are easier to maintain To keep complexity manageable? • Easier to reuse • Changes are localized Solution: Assign responsibilities so that cohesion remains high.

Some examples: Cohesion • Very Low Cohesion: A Class is solely responsible • Cohesion is a measure of how strongly related and for many things in very different functional focused the responsibilities of a class are. areas • A class with low cohesion does many unrelated things or does too much work. • Low Cohesion: A class has sole responsibility for • Low cohesion brings the following problems: a complex task in one functional area. – hard to comprehend – hard to reuse • High Cohesion. A class has moderate responsibilities in one functional area and – hard to maintain collaborates with classes to fulfil tasks. – delicate; constantly effected by change

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

Architectural Patterns Architecture defined

Architectural patters represent the highest-level patterns Architecture establishes the context for design in our pattern system. They help you to specify the and implementation fundamental structure of an application.

Every development activity that follows is governed architecture by this structure-for example, the detailed design of subsystems, the communication and collaboration between design Architectural decisions different parts of the system, and its later extension. implementation are the most CODE Each architectural pattern helps you to achieve a specific fundamental decisions; global system property, such as the adaptability of the user changing them will have interface. significant ripple effects.

© Renato Conte - Pattern II- 15/48 - © Renato Conte - Pattern II- 16/48 - pattern architetturale [Buschmann+al., 1996] Architectural Patterns distributed systems adaptable systems • Reflection Un pattern architetturale esprime • Broker Pattern un'organizzazione fondamentale della • Microkernel pattern struttura o lo schema di un sistema software. high-level system subdivisions • Layers pattern • Pipes and Filters Definisce un insieme di sotto-sistemi • Blackboard pattern predefiniti, specifica le loro responsabilità, e interactive systems include regole e linee guida per organizzare • Model View Controller le relazioni tra di loro. • Presentation-Abstraction-Control

Layers examples 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. networking protocols

Application Tier Presentation Data Tier Application-specific Logic Tier Tier layer Application Application Application Car Sales System Business Logic Tier System System Management

Application-general Component Component Component Customer profile Presentazione Logica Applicativa Memorizzazione Dati layer System System System Order management Oggetti dei Oggetti del servizi dominio per l’accesso del problema Middleware layer Component Component Shopping cart ai dati System System Credit card GUI Database authorization Database Vendita Broker System-software Object persistency Security Component Component mechanism Pagamenti layer System System Manager

Model-View-Controller pattern MVC: diagramma delle classi

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

© Renato Conte - Pattern II- 23/48 - © Renato Conte - Pattern II- 24/48 - • Model Model-View-Controller – Encapsulates Data presented by view User Actions • View :View User Event – Renders Model Data • Controller – Model Controller :Controller – View Controller

Get DataState Change Notification – Responds to user actions

Call Model Action Model is loosely coupled from view – State change communicated :Model through notification. – Multiple views can be implemented for same model

Esempio di diagramma di comunicazione per un MVC

hierarchical structure of The Presentation-Abstraction-Control pattern (PAC) agents 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.

Presentation-Abstraction-Control PAC

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

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.

reflection 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.

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.

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.

Web reference •http://www.cetus-links.org/oo_patterns.html Bibliografia • The Patterns Home Page - hillside.net/patterns/ Hosted by The Hillside Group provides information about patterns, links to Craig Larman online patterns, papers and books dealing with patterns, and patterns-related Applying UML and Patterns An Introduction to Object-Oriented mailing lists. Analysis and Design and Iterative Development Edition 3 2004 0-13-148906-2 • The Patterns-Discussion - g.oswego.edu/dl/pd-FAQ/pd-FAQ.html FAQ maintained by Doug Lea provides a very thorough and highly readable FAQ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. about patterns. Design Patterns: Elements of Reusable Object-Oriented Software • Patterns and Software - Addison-Wesley Professional Computing Series - 1994 www.enteract.com/~bradapp/docs/patterns-intro.html Essential Concepts and Terminology by Brad Appleton provides another F. Buschmann,R. Meunier,H. Rohnert,P. Sornmerlad,M. Stal thorough and readable account of the patterns field. PATTERN-ORIENTED SOFTWARE ARCHITECTURE John Willey & sons- 1996 •Patterns - home.earthlink.net/~huston2/dp/patterns.html Dozens of 1-page examples in C++ and Java. Before-and-After refactoring examples. Book summaries. © Renato Conte - Pattern II- 47/48 - © Renato Conte - Pattern II- 48/48 -