Design patterns and Unified Modeling Language (UML)

Hi, 

 Here, I am going to discuss about the overview of design patterns and also about the modelling concepts (i.e., UML), which helps to design and development of the software life-cycle during HLD and LLD architecture creations. 

“Pattern” as the name suggests, means series of events occurring in a definite order. The patterns can be found in Java and J2ee technologies also. Many a times, we find that there is a particular way of tackling a problem. This way is easy and has been used many times successfully by a number of people earlier also. This method becomes a pattern.

Learning the design patterns is a multiple step process:
1. Acceptance
2. Recognition
3. Internalization

Patterns Defined: The patterns can be defined in many ways. You can find the definitions of patterns in many good books.

“Design patterns are recurring solutions to design problems.”

Patterns: According to commonly known practices, there are 23 design patterns in Java. Design Patterns: Elements of Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, often referred to humorously as the "Gang of Four (GoF)". Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them. These patterns are grouped under three heads: 

1. Creational patterns (5): Factory method pattern, Abstract factory pattern, Singleton pattern, Builder pattern, Prototype pattern 

2. Structural patterns (7): Adapter pattern, Bridge pattern, Composite pattern, Decorator pattern, Facade pattern, Flyweight pattern, Proxy pattern 

3. Behavioral patterns (11): Chain-of-responsibility pattern, Command pattern, Interpreter pattern, Iterator pattern, Mediator pattern, Memento pattern, Observer pattern, State pattern, Strategy pattern, Template method pattern, Visitor pattern

 

Java Design Patterns Reference and Examples

GoF Creational Patterns
Abstract Factory	Sets of methods to make various objects.
Builder	Make and return one object various ways.
Factory Method	Methods to make and return components of one object various ways.
Prototype	Make new objects by cloning the objects which you set as prototypes.
Singleton	A class distributes the only instance of itself.
GoF Structural Patterns
Adapter	A class extends another class, takes in an object, and makes the taken object behave like the extended class.
Bridge	An abstraction and implementation are in different class hierarchies.
Composite	Assemble groups of objects with the same signature.
Decorator	One class takes in another class, both of which extend the same abstract class, and adds functionality.
Facade	One class has a method that performs a complex process calling several other classes.
Flyweight	The reusable and variable parts of a class are broken into two classes to save resources.
Proxy	One class controls the creation of and access to objects in another class.
GoF Behavorial Patterns
Chain Of Responsibility	A method called in one class can move up a hierarchy to find an object that can properly execute the method.
Command	An object encapsulates everything needed to execute a method in another object.
Interpreter	Define a macro language and syntax, parsing input into objects which perform the correct operations.
Iterator	One object can traverse the elements of another object.
Mediator	An object distributes communication between two or more objects.
Memento	One object stores another objects state.
Observer	An object notifies other object(s) if it changes.
State	An object appears to change its` class when the class it passes calls through to switches itself for a related class.
Strategy	An object controls which of a family of methods is called. Each method is in its` own class that extends a common base class.
Template	An abstract class defines various methods, and has one non-overridden method which calls the various methods.
Visitor	One or more related classes have the same method, which calls a method specific for themselves in another class.

Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML).

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group. UML includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems.

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development. UML offers a standard way to visualize a system's architectural blueprints, including elements such as:

• activities - represents user-defined behavior coordinating actions
• actors - specifies a role played by a user or any other system that interacts with the subject.
• business processes - is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.
• database schemas - applied to the data and their supporting data structures, and not to the database management system (DBMS)
• (logical) components - represents a modular part of a system, that encapsulates its content and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces
• programming language statements - an artificial language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely.
• reusable software components.

UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.

UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language.UML aims to be a standard modeling language which can model concurrent and distributed systems.

Modeling

It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains documentation that drives the model elements and diagrams (such as written use cases).

UML diagrams represent two different views of a system model:

• Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
• Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.

UML models can be exchanged among UML tools by using the XMI interchange format.

Diagrams overview

UML 2.2 has 14 types of diagrams divided into two categories. Seven diagram types represent structural information, and the other seven represent general types of behavior, including four that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram:

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams; this flexibility has been partially restricted in UML 2.0. UML profiles may define additional diagram types or extend existing diagrams with additional notations.

Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.

• Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
• Component diagram: describes how a software system is split up into components and shows the dependencies among these components.
• Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
• Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
• Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.
• Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings.
• Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates what metamodel element a given stereotype is extending.

Behavior diagrams

Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.

• Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
• UML state machine diagram: describes the states and state transitions of the system.
• Use Case Diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.

Interaction diagrams

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

• Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
• Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.
• Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
• Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

The list of UML tools you can get here.