Pattern. seconda parte. Types of patterns. ...other good guidance... some GRASP. design patterns (software design) Types of software patterns

Transcription

1 rel. 1.7 Università di Padova Facoltà di Scienze MM.FF.NN Informatica - anno Corso di Ingegneria del Software Pattern seconda parte Renato Conte - Pattern II- 1/48 - 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 Renato Conte - Pattern II- 2/48 - Architectural Patterns Types of 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....other good guidance... some GRASP 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 -

2 GRASP General 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. Renato Conte - Pattern II- 5/48 - Renato Conte - Pattern II- 6/48 - Coupling? TypeX? TypeY 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? 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 Renato Conte - Pattern II- 7/48 - Renato Conte - Pattern II- 8/48 -

3 Low coupling High Cohesion How can we make classes independent of other classes? Classes are easier to maintain Easier to reuse Changes are localized Problem: To keep complexity manageable? Solution: Assign responsibilities so that cohesion remains high. Renato Conte - Pattern II- 9/48 - Renato Conte - Pattern II- 10/48 - 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. Renato Conte - Pattern II- 11/48 - Renato Conte - Pattern II- 12/48 -

4 High cohesion Classes are easier to maintain Easier to understand Often support low coupling Supports reuse because of fine grained responsibility Renato Conte - Pattern II- 13/48 - Renato Conte - Pattern II- 14/48 - Architectural Patterns Architectural patters represent the highest-level patterns in our pattern system. They help you to specify the fundamental structure of an application. Architecture defined Architecture establishes the context for design and implementation Every development activity that follows is governed by 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. CODE design implementation architecture Architectural decisions are the most fundamental decisions; changing them will have significant ripple effects. Renato Conte - Pattern II- 15/48 - Renato Conte - Pattern II- 16/48 -

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

6 multi-layer (multi-tier) Layered Architecture ( & reusable objects) Presentation Tier Application Tier Logic Tier Business Logic Tier Data Tier Application-specific layer Application Application Application Car Sales Management Presentazione GUI Logica Applicativa Oggetti del dominio del problema Vendita Pagamenti Oggetti dei servizi per l accesso ai dati Database Broker Security Manager Memorizzazione Dati Database Application-general layer Middleware layer -software layer Customer profile Order management Shopping cart Credit card authorization Object persistency mechanism Renato Conte - Pattern II- 21/48 - Renato Conte - Pattern II- 22/48 - 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 -

7 Model-View-Controller :View User Actions Get Data State Change Notification :Controller User Event Model Encapsulates Data presented by view View Renders Model Data Controller Model Controller View Controller Responds to user actions :Model Call Model Action Model is loosely coupled from view State change communicated through notification. Multiple views can be implemented for same model Renato Conte - Pattern II- 26/48 - Esempio di diagramma di comunicazione per un MVC Renato Conte - Pattern II- 27/48 - Renato Conte - Pattern II- 28/48 -

8 Presentation-Abstraction-Control pattern PAC 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. hierarchical structure of agents Renato Conte - Pattern II- 29/48 - Renato Conte - Pattern II- 30/48 - Presentation-Abstraction-Control PAC Renato Conte - Pattern II- 31/48 - Renato Conte - Pattern II- 32/48 -

9 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- 33/48 - Renato Conte - Pattern II- 34/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. Renato Conte - Pattern II- 35/48 - Renato Conte - Pattern II- 36/48 -

10 blackboard blackboard Renato Conte - Pattern II- 37/48 - Renato Conte - Pattern II- 38/48 - Reflection pattern reflection 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. Renato Conte - Pattern II- 39/48 - Renato Conte - Pattern II- 40/48 -

11 Microkernel pattern microkernel 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. Renato Conte - Pattern II- 41/48 - Renato Conte - Pattern II- 42/48 - 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. Renato Conte - Pattern II- 44/48 -

12 pipe pipe Renato Conte - Pattern II- 45/48 - Renato Conte - Pattern II- 46/48 - Bibliografia Craig Larman Applying UML and Patterns An Introduction to Object-Oriented Analysis and Design and Iterative Development Edition Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Professional Computing Series F. Buschmann,R. Meunier,H. Rohnert,P. Sornmerlad,M. Stal PATTERN-ORIENTED SOFTWARE ARCHITECTURE John Willey & sons Renato Conte - Pattern II- 47/ Web reference 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.html FAQ maintained by Doug Lea provides a very thorough and highly readable FAQ about patterns. Patterns and Software - Essential Concepts and Terminology by Brad Appleton provides another thorough and readable account of the patterns field. 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- 48/48 -