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.

Object Oriented Programming (OOP)

Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance.OOP was developed to increase the reusability and maintainability of source code.Transparent representation of the control flow had no priority and was meant to be handled by a compiler. With the increasing relevance of parallel hardware and multithreaded coding, developer transparent control flow becomes more important, something hard to achieve with OOP. Many modern programming languages now support OOP, at least as an option.

The OOP programming style in most object-oriented languages:

• Dynamic dispatch – when a method is invoked on an object, the object itself determines what code gets executed by looking up the method at run time in a table associated with the object. This feature distinguishes an object from an abstract data type (or module), which has a fixed (static) implementation of the operations for all instances. It is a programming methodology that gives modular component development while at the same time being very efficient.
• Encapsulation (or multi-methods, in which case the state is kept separate)
• Subtype polymorphism
• Object inheritance (or delegation)
• Open recursion – a special variable (syntactically it may be a keyword), usually called this or self, that allows a method body to invoke another method body of the same object. This variable is late-bound; it allows a method defined in one class to invoke another method that is defined later, in some subclass thereof.

Additional concepts used in object-oriented programming include:

• Classes of objects
• Instances of classes
• Methods which act on the attached objects.
• Message passing
• Abstraction

Decoupling

Decoupling refers to careful controls that separate code modules from particular use cases, which increases code re-usability. A common use of decoupling in OOP is to polymorphically decouple the encapsulation (see Bridge pattern and Adapter pattern) - for example, using a method interface which an encapsulated object must satisfy, as opposed to using the object's class.

Object-orientation and databases

Both object-oriented programming and relational database management systems (RDBMSs) are extremely common in software today. Since relational databases don't store objects directly (though some RDBMSs have object-oriented features to approximate this), there is a general need to bridge the two worlds. The problem of bridging object-oriented programming accesses and data patterns with relational databases is known as Object-Relational impedance mismatch. There are a number of approaches to cope with this problem, but no general solution without downsides.One of the most common approaches is object-relational mapping, as found in libraries like Java Data Objects and Ruby on Rails' ActiveRecord.

There are also object databases that can be used to replace RDBMSs, but these have not been as technically and commercially successful as RDBMSs.

Notational representation between objects

The relationships between classes are building blocks of object oriented programming and very basic stuff. They are:

1. Association

Association is a relationship between two objects. In other words, association defines the multiplicity between objects. You may be aware of one-to-one, one-to-many, many-to-one, many-to-many all these words define an association between objects. Aggregation is a special form of association. Composition is a special form of aggregation.

Example: A Student and a Faculty are having an association.

2. Aggregation

Aggregation is a special case of association. A directional association between objects. When an object ‘has-a’ another object, then you have got an aggregation between them. Direction between them specified which object contains the other object. Aggregation is also called a “Has-a” relationship.

3. Composition

Composition is a special case of aggregation. In a more specific manner, a restricted aggregation is called composition. When an object contains the other object, if the contained object cannot exist without the existence of container object, then it is called composition.

Example: A class contains students. A student cannot exist without a class. There exists composition between class and students.

Difference between aggregation and composition

Composition is more restrictive. When there is a composition between two objects, the composed object cannot exist without the other object. This restriction is not there in aggregation. Though one object can contain the other object, there is no condition that the composed object must exist. The existence of the composed object is entirely optional. In both aggregation and composition, direction is must. The direction specifies, which object contains the other object.

Example: A Library contains students and books. Relationship between library and student is aggregation. Relationship between library and book is composition. A student can exist without a library and therefore it is aggregation. A book cannot exist without a library and therefore its a composition. For easy understanding I am picking this example. Don’t go deeper into example and justify relationships!

4. Abstraction

Abstraction is specifying the framework and hiding the implementation level information. Concreteness will be built on top of the abstraction. It gives you a blueprint to follow to while implementing the details. Abstraction reduces the complexity by hiding low level details.

Example: A wire frame model of a car.

5. Generalization

Generalization uses a “is-a” relationship from a specialization to the generalization class. Common structure and behavior are used from the specialization to the generalized class. At a very broader level you can understand this as inheritance. Why I take the term inheritance is, you can relate this term very well. Generalization is also called a “Is-a” relationship.

Example: Consider there exists a class named Person. A student is a person. A faculty is a person. Therefore here the relationship between student and person, similarly faculty and person is generalization.

6. Realization

Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.

Example: A particular model of a mobile ‘Samsung Galaxy’ that implements the blueprint of a mobile realizes the abstraction.

7. Dependency

Change in structure or behavior of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other class it this happens.

Example: Relationship between shape and circle is dependency.

IT Architects : Type and their Role

In this blog we're going to cover the type, layer and role of the IT architects by keeping about the various types of architecture that the IASA maintains and follows. IASA is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world. As we already know the role of architects, i.e., architect defines the architecture. It applies to various aspects of IT systems development and base platform designs methodology. 

Consider the various types of architecture lists:

The term "technical architecture" is a common first attempt to describe architecture but without the need to be specific about what type of architecture you're referring to. Therein lies a failing when using this term: it is too unspecific to be particularly meaningful when discussing a responsibility or project and business requirement.The technical architects are broadly divided into:

• Enterprise Architect
• Software Architect
• Infrastructure Architect
• Information Architect
• Business Architect

In addition, we do have others architects in queue which plays important role into the IT operations.They are:

• System/Product architect
• Domain Architect
• Solution Architect
• Applied Architect

Based on the above architects list and their respective characteristics, the types of architects shall be divided broadly into the business and technical architects (Please refer below diagram). But, before that we would discuss about the summary of above listed architects:

System Architect: "System architect" refers to the way in which desired functionality is met by hardware and software components as well as how these components relate to each other and the intended users of the system. The term "architecture" is often generically used to refer to the system architecture, at least within the context of software systems development. They have equal strength in the both technical and business area. Plays a vital role to bring all the stake holders together and ensure all the stake holders concern’s are captured methodologically, formally documented and validated. Assist the project manager to make the management decision and makes key technical decision for the project/system/product. Brings all the technical architects, development teams, system analyst, and support teams together to ensure the cohesive architecture is defined to meet the stake holders concern and ensures the defined architecture is implemented. The system architecture validation is done by using the user case scenarios. +1 view of the architecture. The architecture verification is done through reviews.

Domain Architect: "Domain architect" responsible for the architecture solution for that domain which comes under generic, organizational structure or design for software systems. The domain architecture contains the designs that are intended to satisfy requirements specified in the domain model. A domain architecture can be adapted to create designs for software systems within a domain and also provides a framework for configuring assets within individual software systems. The domain architect is an abstract  definition and there are various domain architects. The domain architects specific to the web

development projects are

• Application architect
• Data architect
• Information architect
• Integration architect
• Security architect
• IT Process architect
• Infrastructure architect
  • Network architect
  • Server architect
  • Web run time architect

Solution Architect: A "Solutions architect" in Information Technology Enterprise Architecture is a practitioner in the field of Solution Architecture. Solution architecture team is the set of specialist working together to research and seek solutions for a specific problem.The role title has a wider meaning in relation to solving problems, but is more often used in the narrower domain of Technical architecture - the context for the remainder of this definition. In this context, the Solutions Architect is a very experienced architect with cross-domain, cross-functional and cross-industry expertise. He/she outlines solution architecture descriptions, then monitors and governs their implementation.The role of "Solutions Architect" requires the knowledge and skills that are both broad and deep. To be effective the Solutions Architect must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments.

Applied Architect: "Applied architect" provides practical guidelines and techniques for producing quality software designs. It gives an overview of software architecture basics and a detailed guide to architecture design tasks.The applied architects have the known set of problems, solution and context. The architectural patterns are applied to the system or product. The architectural patterns includes to the process solution or methodology for the implementation and its style.

Software Architect: "Software architect" mainly focused for developers is aimed at software developers that want to learn more about software architecture as well as those that are new to the role. It fills the gap between software development and high-level architecture that probably seems a little "enterprisingly" for most developers.

Information Architect: "Information architect (IA)" is the art and science of organizing and labelling websites, intranets, online communities and software to support usability. It is an emerging discipline and community of practice focused on bringing together principles of design and architecture to the digital landscape. Typically it involves a model or concept of information which is used and applied to activities that require explicit details of complex information systems. These activities include library systems and database development. Information architecture is a specialized skill set that interprets information and expresses distinctions between signs and systems of signs. More concretely, it involves the categorization of information into a coherent structure. Typically this is required in activities such as library systems, Content Management Systems, web development, user interactions, database development, programming, technical writing, enterprise architecture, and critical system software design. Information architecture originates, to some degree, in the library sciences.

Application Architect: "Application architect" is really a subset of the system architecture. The scope of the application architecture, as opposed to the system architecture, is often determined by business function. It is typical for the application architecture to be defined to a lower level than the system architecture, particularly as it needs to refine the system architecture to provide the design decisions that relate specifically to the business function rather than to the system as a whole.

Enterprise Architect: The term "Enterprise architecture (EA)" is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. EA are responsible for defining the holistic architecture solution for the entire enterprise. However, enterprise architecture is more concerned with mapping the business processes and needs to the technical capabilities of the organization, including personnel, strategy, distribution and how the business' changing needs will be met. The enterprise architect role is therefore extremely wide-reaching, being enterprise-wide, and requires careful inspection of all the business' functions and their strategic requirements. Many people may contribute to the enterprise architecture, but that doesn't make them responsible for it and thus doesn't make them enterprise architects.