Docstoc

sofware architecture

Document Sample
sofware architecture Powered By Docstoc
					Patterns
•What is a Pattern and Design Patterns •What makes a Pattern •Describing Design Patterns •Pattern categories and relationship between patterns •Organizing the catalog •Patterns and software architecture

Study of Design Patterns •Creational Patterns •Structural Patterns •Behavioral Patterns •GRASP(General Responsibility assignment software patterns) patterns for assigning responsibilities •Expert, creator etc.

Problems faced while Designing Object Oriented Systems Analysis phase Creation of conceptual model - important artifact conceptual model Captures the vocabulary of the system It decomposes the problem space into comprehensible units called concepts Conceptual model describes real-world problem domain Conceptual model can be developed in parallel with use-case model

In UML, conceptual model is illustrated with a set of static structure diagram which shows, concepts, attributes of concepts and association between concepts ( no responsibilities or methods) Finding Concepts – Using concept category list (physical objects, places, specifications,, roles, containers, events, processes etc.) Using noun-phrase identification from a domain statement Describe concepts - Remove irrelevant, resolve similar

Add associations and attributes- use common association list or verb phrase identification Remove irrelevant , redundant or derived associations Add attributes- pure data values or primitive data types , composite data It is perfectly valid to have attributeless concepts or concepts having a purely behavioural role Analysis Artifacts Use cases- Use case Model Conceptual Model Sequence diagrams

Design phase Creation of interaction diagrams and class diagrams – vocabulary of solution domain Interaction diagrams describes how objects communicate in order to fulfill requirements Sequence diagram –captures dynamic behaviour ( time-oriented) Collabaration diagram- captures dynamic behaviour( message-oriented) Class diagrams summarize the definitions of classes and interfaces

The skillful assignment of responsibilities occurs while creating interaction diagrams Granularity- objects can vary tremendously in size and number. Complete application can be a single object performing all responsibilities or there can be many small objects forming the system Some objects have very few responsibilities may be just one while some having several responsibilities Responsibilities should be assigned to the class that has information needed to fulfill it

Who should be assigned the responsibility of Creation of objects ? Conceptual models differs from Design model Design model need to have many more low level classes such as arrays , lists for performance reasons, high level abstractions for grouping odd objects

Design level classes may not have counterparts in real-world domain
Interfaces are operations or methods hence cannot be objects is a mis-conception. A process or algorithm or behavior can be a object

Experienced object-oriented designers make good designs New designers are overwhelmed by options available and fail to come up with good design Experienced designers use their experience They reuse something that had proved good They record and share their experience as a design pattern Each design pattern systematically names , explains and evaluates an important and recurring design in Object-Oriented Systems

Sound Design principles
Encapsulation- Information hiding Interface is exposed . Implementation is hidden Client need not know the implementation complexity – black-box Implementation can be changed without braking the client Client object invokes interfaces exposed by server object and get the work done

Sound Design principles

Use Dynamic binding – the association between a request and operation is established at run-time Dynamic binding lets you substitute objects that have identical interfaces for each other at run time- Interchangeable objects known as polymorphism
Gives flexibility-implementation can changeinterfaces remains the same

New implementations can be added without the client –the requestor getting affected

An abstract class defines a common interface to its subclasses The operations that an abstract class declares but doesn’t implement are called abstract operations

Subclasses can override(refine and redefine) an operation defined by its parent class
Separate interface from implementation Interface class as the abstract base class Implementation class as the derived class Reduces implementation dependencies increases reusability

Implementation can evolve without affecting the client who is using the interface class InterfaceMemory { public: InterfaceMemory virtual int Store(char*)=0; //virtual char * Restore(void)=0; virtual int Restore(char *)=0; }; InterfaceMemory * CreateInstanceComp();
Implementation Memory

#include "Interface.h" class ImplementationMemory: public InterfaceMemory {private: char *mstr; int scnt; public: ImplementationMemory(void){scnt=0;}; ~ImplementationMemory (void) { if (scnt>0 ) delete[]mstr;}; int Store( char * ); int Restore(char *); };

// implementation.cpp #include <stdio.h> #include <string.h> #include "Implementation.h" int ImplementationMemory::Restore(char * str) { if ( scnt > 0) { strcpy(str, mstr); return 0;} return -1; }

int ImplementationMemory::Store(char * str) { if ( scnt > strlen(str) ) strcpy(mstr, str); else { if( scnt > 0) delete[]mstr; scnt = strlen(str) +1; mstr= new char[scnt ]; strcpy(mstr, str); } return 0; }

CreateInstanceComp(void) { return new Implementation; } Memory layout in C++
vptr
mstr scnt

Implementation::Store Implementation:: Restore

int main() { InterfaceMemory *memory= CreateInstancecomp(); mymemory->Store("xyz"); mymemory->Restore(a); }

#include "Interface.h" class ImplementationMemory:public InterfaceMemory {private: char *mstr[40]; int scnt[40];

int topcnt;
public:ImplementationMemory(void); ~ImplementationMemory(void); int Store( char * ); int Restore(char *); };

Program to an interface, not an implementation Always declare variables of an abstract supertype than concrete subtype. Assign the concrete subtype at run time The two most common techniques of reusing functionality i.e creating new objects from existing objects is Inheritance Composition

Favor composition over Inheritance

Reuse by subclassing is called white-box reuse. The implementation of parent class is visible to subclasses. Inheritance breaks encapsulation Inheritance is defined at compile-time A change in parent’s implementation will force the subclass to change

Inherit from abstract classes, since they usually provide little or no implementation
public class x extends z {

// override methods….}

Reuse by composition is called black-box reuse. Object composition is defined dynamically at compile time by objects acquiring references to other objects

Objects are accessed only through their interfaces, thus safeguarding composition
Any object can be replaced at run-time by any other as long as it is of same type public class x { object z; …………………..}

The “Open/Closed” principle Classes should be: – open for extension – closed for modification When requirements change, extend the classes with new behavior Classes should be extensible without modifying existing code Use of Open-closed principle usually introduces new levels of abstraction which makes code complex It makes designs resilient to change and flexible enough to take on new functionalities to meet changing requirements

Violation of Open/Closed Principle struct Shape { enum Type { CIRCLE, SQUARE } shape_type; /* . . . */ }; void draw_square (const Square &); void draw_circle (const Circle &); void draw_shape (const Shape &shape) { switch (shape.shape_type) { case SQUARE: draw_square ((const Square &) shape);break; case CIRCLE: draw_circle ((const Circle &) shape);break; // etc.

Application of Open/Closed Principle class Shape { public: virtual void draw () const = 0; }; class Square : public Shape { /* . . . */ }; class Circle : public Shape { /* . . . */ }; typedef vector<Shape> Shape_Vector; void draw_all (const Shape_Vector &shapes) { for (Shape_Vector::iterator i = shapes.begin(); i != shapes.end ();i++) (*iterator).draw (); }

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” By an architect Christopher Alexander around 1970 Patterns are devices that allow programs to share knowledge about their design. Documenting patterns is one way that you can reuse and possibly share the experience of solving specific program design problem.

It solves a problem: Patterns capture solutions, not just abstract principles or strategies. It is a proven concept: Patterns capture solutions with a track record, not theories or speculation. The solution isn't obvious: Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. The best patterns generate a solution to a problem indirectly -a necessary approach for the most difficult problems of design. It describes a relationship: Patterns don't just describe modules, but describe deeper system structures and mechanisms. The pattern has a significant human component .... All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility.

Design patterns represent solutions to problems that arise when developing software within a particular context –i.e., “Pattern == problem/solution pair in a context” Patterns facilitate reuse of successful software Architectures and designs Pattern has four essential elements Pattern Name-describe in a word or two- easy communication-additions to design vocabulary Problem-describes when to apply pattern Solution-describes the elements that make up design, their relationships, responsibilities, collaborations Consequences- trade-offs of applying the pattern

Design patterns are classified or categorized so that one can refer to families of related patterns. They are classified in two ways Classification based on purpose Creational patterns – Deal with creation of classes and objects Ex. Singleton Structural patterns – Deal with composition of classes and Objects Ex. Adapter Behavioral patterns – Deal with dynamic interactions among classes and objects and how they distribute responsibility Ex. Command

Classification based on scope It categorizes based on whether the pattern applies primarily to classes or to objects Class pattern -deals with relationship between classes and their subclasses Ex. Factory Method Object Pattern -deals with object relationships, which can be changed at run-time and are more dynamic Ex. Abstract Factory

Pattern is a named Problem solution pair which can be reapplied with certain trade-offs (Pattern=Name+Problem+Solution+ consequence) Patterns are described using thirteen templates

Pattern name
Intent – short statement or definition Also known as - Aliases Motivation- a scenario illustrating design problem and how it is solved

Applicability-situation where it can be applied and how they can be recognized

Structure-class diagram Participants- classes and their responsibilities Collaborations- how they collaborate to carry out their responsibilities Consequences- trade-offs ,benefits and drawbacks Implementations- implementation level issues and variations Sample code – code fragments Known uses – Real systems where pattern is used Related Patterns


				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:18
posted:1/30/2009
language:English
pages:33