3. Common Questions
What, if anything, makes architecture different from
design?
Does object oriented analysis and design have anything to
do with architecture?
What goes on in the environment in which architecture is
created and turned into a product? Why does the architect
care?
What documents does architect produce, and what’s the
purpose of those documents?
Is it important for the architect to be technology expert?
What are patterns, and why they are relevant?
5. Difference is !!!
Architect
Abstract
Deliverables
Area of Focus
Design
High / broad focus on
few details
System and sub
system plans,
architecture prototypes
Non-functional
requirements, and risk
management
Low / specific focus on
many details
Component design,
code specification
Functional
requirements
6. Common Principals
Common characteristics of architecture
and design
Abstraction
Encapsulation
Cohesion
Coupling
Its same as of design and implementation,
where refactor is required to incorporate
changes
7. Architectural Principals
Separation of Concerns
Dependency Inversion Principal
Separate Unstable from Stable
components
Use component and container frameworks
Keep component interfaces simple and
clear
Keep remote component interface coarsegrained
8. Architecture Patterns and
Design Patterns
Standard solution to recurring problem
To identify problems, and trade-offs with
respect to service level requirements
Split problem, one pattern is not a
solution to all
Synthesize system by combining all
patterns into aggregate construct
We typically have this question, which is more important, architecture or design? Can a good architecture make up for a bad design or can a good design overcome a bad architecture? We have typically the question "Did you say the system's architecture was nice and clean? Yes, you just cannot see it because it is hidden behind the codes. Here, we are looking at how architecture looks at the high level and design looks at a low level.
Did not you say this system's Architecture was nice and clean. Yes You just cannot see it because it is hidden behind the code.
Here, we see the difference between architecture and design. So, looking at the architecture, at the abstraction level, typically an architect focuses on the high/broad focus only few details. On the other hand, a designer focuses on the low/specific details of your components. In terms of deliverables, the architect typically has system and subsystem plans architecture prototype that is the delivery before an architect. For a designer, it is a component design and code specification. In terms of the area of focus, the architect focuses more on the nonfunctional requirements, which are the quality of services and risk management. On the other hand, the designer focuses more on the functional requirements, the detailed code of your different components.
Looking at common principles between architecture and design. When we develop the architecture of a system, we focus on planning sub-systems. Therefore, the basis for the architecture is components rather than individual objects. However, these components are essentially high-level object and the principles of good object-oriented design also apply at the architecture level. So, the common characteristics of architecture and design are abstraction, encapsulation, cohesion, and coupling. <br>Abstraction it focuses more on the architecture significant with details of a component. Encapsulation supports abstraction by hiding the details that were ignored at the time the abstraction was defined. Cohesion supports abstraction and encapsulation by ensuring that all of the details hidden by the encapsulation boundary contribute to the definition of the abstraction. Coupling measures the connectedness of components. Inside an encapsulation boundary, coupling can be helpful because it adds to the cohesion of the abstraction. Like design and implementation, the architecture also requires refactoring to incorporate changes.
Let us look now at the architectural principles. Architectural principles are axioms or assumptions that suggest good practices when constructing system architecture. So, we need to focus on the separation of concerns- the principle tells the architect to separate components into different functional or infrastructure purposes. Dependency inversion - depend upon abstractions and do not depend upon concretions. Separate volatile from stable components - as a system changes, you want to reduce the changes to a small number of packages.
The use of component and container frameworks - a component is a software component that is managed by a container, for example Servlet, which is managed by the Web container. Keep component interfaces simple and clear - the more complex the component interface is the harder it is for the software developers to understand how to use the component. And keep remote component interfaces coarse-grained so when you are communicating through the network, use the coarse-grained calls rather than fine-grained calls.
Architecture principles are axioms or assumptions that suggest good practices when constructing a system architecture Separation of Concerns Dependency Inversion Principle Separate volatile from stable components Use component and container frameworks Keep component interfaces simple and clear Keep remote component interfaces coarse grained
Let us look now at introduction to architecture patterns. Patterns are standard solutions to commonly recurring problems in a particular context. By using a pattern-based reasoning process to plan systems, the architect can analyze systems to identify problems and of course trade-offs with respect to service-level requirements. And every one of these problems might be solved by applying a particular pattern or it might require further analysis and decomposition. So, the architect can then synthesize the system by combining the pattern solutions into aggregate constructs. The idea here is making use of these solutions of common recurring problems that happened again and again.
Looking at the Layers pattern. The Layers pattern structures applications so that they can be decomposed into groups of subtasks and every group represents a particular level of abstraction. So, we can look at it as the low level, which is the hardware level or the hardware platform. Then, we get into the lower platform, which is the OS with installed JVM on it. Then, the upper platform represented by the application server and then the next level would the virtual platform representing the specifications and APIs and frameworks that the application server uses based on the specification. For example, if it is Java A6, then it would be all the APIs inspects related to the Java EE 6 the current Java EE specification, which is the Java EE6. And the application level and that is the in-house application that you typically implement.
The Layers pattern structures applications so they can be decomposed into groups of subtasks, and each group represents a particular level of abstraction. A graphic depicting the Layers pattern is displayed.
Looking at the MVC pattern. The MVC pattern enhances the flexibility and maintainability of application by separating the application into three distinct modules. First is the model and that represents the data model. The view are the components for viewing the representation of the data model. Controller are the components for allowing interaction. <br>We can use the MVC pattern to design a data model with clearly specified interfaces that allow the model to be manipulated and queried. You can use the MVC pattern to ensure proper decoupling among components within a particular tier, which helps with the separation of concerns in developing application components.
Looking at the Tiers pattern. The Tiers pattern is made of the client tier and then after that we have the Web tier, which typically handles the presentation application and usually the view components can be used to handle that. We can make use of servlets, JSPs, JSF components, and helpers. <br>The business tier handles the business logic that is where you have your Enterprise Java Bean, like session bean, stateless, stateful or singleton session beans. Also, they can handle the messaging system, can consume messages asynchronously through a message through a bean. You also can handle Web services that interacting with Web service client through either SOAP, JAX-WS Web service or REST, which is JAX-RX Web service. <br>And then you have the integration tier that contains all the components that allow you to integrate to external systems. For example, domain stores, like hibernate or top link accessing the database, JDBC, JMS, JPA, connectors, and so forth to access outside system, external systems, which are the resources tier, which could be database or an EIS system like an Enterprise Information System.
Let us look now at architecture model. Let us look at Model 1 architecture. In the Model 1 architecture, the JSP page alone is responsible for processing the incoming request and relying back to the client. There is still separation of presentation from content because all data access is performed using beans. Obviously, at the JSP access the beans, which access in this case the business tier and/or those Java beans would be representing a business tier or business processes and JSPs can actually contain some code or embed some Java in it to access your business components or your data component. This is typically used for simple small applications. <br>Model 1 suffers from the hard-coded navigation and of the responsibility of the controller model and view. This is not normally used any longer in favor of Model 2 architecture.
In the architecture Model 2, we have servlets, JSF components, and helpers. This is typically used for highly dynamic enterprise applications or particularly presentation tier enterprise applications. <br>So, the Model 2 architecture is actually the way to go and it is a hybrid approach for serving dynamic content. Since it combines the use of both servlets and JSPs, where the servlet act as the controller and it is the in charge of the request processing and the creation of any beans or object by the JSP as well as deciding depending on the user's actions. The JSP is responsible for building the view so that will go back to the client or the browser. The clients do show all the information that the client needs.
Now looking the PAC architecture pattern. Sometimes we use this Presentation Abstraction Control (PAC) pattern. It actually introduce a level of decoupling between the tiers to further define the separation of concerns that was initiated with the MVC pattern. So here we have the abstraction, which is representing data and represents the presentation or the view and control represents all the services or all the controllers that are part of the architecture. <br>So, it separates in a sense that it treats the presentation tier as one level and then the controller would be moved to the business tier and the abstraction represents the data model.
![Tech Talk – Enterprise Architect
[Fundamentals of Architecture - 3]](https://image.slidesharecdn.com/entarch-02-140127234524-phpapp02/85/Tech-Talk-Enterprise-Architect-02-1-320.jpg)
