Design Pattern & Practices Interview Questions and Answers (103) - Page 3

1) Business Functions exposed as independent services allows assembling and integration of these services to automate enterprise wide business processes.

2)Allows existing applications and infrastructure to be leveraged by providing means to bridge incompatible technologies.

3)SOA approach accelerates the movement of the system towards standards based policies such as WS-*.This creates new business opportunities as system/software between different organizations based on standard policies could interoperate.

1) Service based applications involving heavy data exchange suffers performance problems as service based communication imposes overhead in terms of data format and packaging.

2) Services are generally consumed by more than one party versioning within or outside the organization. This necessitates versioning and change management infrastructure which might be too costly for some projects.

3) SOA entails information architecture, technical architecture, data architecture, and business process architecture, how ever getting this combination of different facets of an enterprise system makes SOA solution harder to materialize.

SOA is a style of design, development, deployment, and management of applications with suitable infrastructure in which:
- Applications are organized into modular services that are (typically) network accessible
- Service interface definitions are standards based
- Quality of service characteristics are explicitly identified in the design
- Services and business policies are cataloged in a repository
- Protocols are predominantly, but not exclusively, based on Web services

Business Prespective

- Increase Business Flexibility
- Business Functionality Improvements
- Create new Revenue Channels
- Re-engineer/Streamline existing Business Processes
- Cost Efficiency- Lowering TCO
- Improve Customer Satisfaction

IT Prespective

- Eliminate Silos and Spider-Webs
- Architectural Improvements
- Leverage Existing Investments
- Governance & Lifecycle Management
- Extensible Framework that meets ROI Expectations

Standardized Service Contract
Services within the same service inventory are compliance with the same contracts design standards

Loosely coupled services
Service contracts are loosely coupled with consumers as well as from underlying logic

Abstraction
Service contracts contains only necessary information about service

Service Autonomy
Control over their underlying logic enables the Service to run autonomous

Service Discoverability
Allows service descriptions to be discovered – essentially helps to avoid accidental creation of redundant services

Service Reusability
Service that contain agnostic logic then it can be positioned as Reusable service

Service Statelessness
Services that minimizes the state management reduces the resource utilization

Service Composability
Services capable of addressing agnostic or cross-cutting concerns can be composed for different purpose

Completeness: Does the model support all the necessary data?

Nonredundancy : Does the model specify a database in which the same fact could be recorded more than once?

Enforcement of Business Rules : How accurately does the model reflect and enforce the rules that apply to the business data?

Data Reusability: Will the data stored in the database be reusable for purposes beyond those anticipated in the process model?

Stability and Flexibility: How well will the model cope with possible changes to the business requirements? Can any new data required to support such changes be accommodated in existing tables?

Elegance Does the data model provide a reasonably neat and simple classification of the data?

Integration How will the proposed database fit with the organization’s existing and future databases?

Conceptual Data Models
Provide a high-level description of data and relatively technology independent specification of the data to be held in the database , including entities and their relationships

Logical Data Models
Describe a logical solution to a data project. The model includes attributes and the individual pieces of information that will be included

Physical Data Models
Describe the implementation of data presented in terms of tables and columns, together with a specification of physical storage (which may include data distribution) and access mechanisms in a physical database

1) Acts as a vehicle for communication among different stakeholders

2) Aids analysis – allows different concerns to be expressed, negotiated and resolved

3) Assists early design decisions – Most difficult to get correct, Most difficult to change

4) Provides the basis for a work breakdown structure and project plan

5) Sets the basis for development team structure and organization

6) Establishes the possibilities for commercial-off-the-shelf component integration by setting system and component boundaries

Software architecture is the set of significant decisions about the organization of a software system.

It encompasses the following:

- Selection of the structural elements and their interfaces of a system

- Behavior as specified in collaborations among those elements

- Composition of structural and behavioral elements into larger subsystems

-Architectural style that guides this organization

- Functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns

It is a view model developed by Philippe Kruchten that describes the system from the viewpoint of different stakeholders. The various views are as under

Logical view – is concerned with the functionality that the system provides to end-users.

Development view/Implementation view – illustrates a system from a programmer's perspective and is concerned with software management.

Process view – deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focus on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc.

Physical view/Deployment view - depicts the system from a system engineer's point-of-view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components.

Use Case view / Scenario view - The description of architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype.

- Acts as a vehicle for communication among different stakeholders

- Aids analysis – allows different concerns to be expressed, negotiated and resolved

- Assists early design decisions – Most difficult to get correct, Most difficult to change

- Provides the basis for a work breakdown structure and project plan

- Sets the basis for development team structure and organization

- Establishes the possibilities for commercial-off-the-shelf component integration by setting system and component boundaries

- Separation of concerns

- Single responsibility principle

- Principle of statelessness

- Minimize upfront design

- Do not duplicate functionality within an application

- Prefer composition to inheritance

- An architectural style, aka architectural pattern, is a set of principles—a coarse grained pattern that provides an abstract framework for a family of systems.

- An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems.

- It is a family of systems in terms of a pattern of structural organization.

- It determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.

- Creates thin clients at the presentation layer

- Increases system reliability

- Preserves system scalability

- Enhances system performance

Frameworks are semi-complete applications
Complete applications are developed by inheriting from, and instantiating parametrized framework components

Frameworks provide domain-specific functionality
Examples are business applications, telecommunication applications, window systems etc.

Frameworks exhibit inversion of control at run-time
The framework determines which objects and methods to invoke in response to events

Frameworks support reuse of detailed design and code
A framework is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications.

- Together, design patterns and frameworks help to improve software quality and reduce development time. e.g., reuse, extensibility, modularity, performance

A pattern must

Solve a problem
That is it must be useful

Have a context
It must describe where the solution can be used

Recur
It must be relevant in other solutions

Teach
It must be provide sufficient understanding to tailor the solution

Have a name
It must be referred to consistently

In the High Level Design Phase, the architect plays the role of a Participant . He needs to carry out at least the below mentioned activities in this phase

• Formulate the design, logical models and data models to meet the requirements

•Define metaphors, design principles and patterns on which the architecture is based

•Provide inputs for tool, technology, standards & environment selection for design, development and testing

•Create and demonstrate proof-of-concepts (POC)

•Review the high-level documents prepared by the designers & suggest changes required for architecture adoption

•Make decisions on the trade-offs necessary.

•Guide testing teams about the necessary test methodologies, test plans & tools

In the Low Level Design Phase, the architect plays the role of a Facilitator . He needs to carry out at least the below mentioned activities in this phase -

•Manage the creation and delivery of detailed technical designs

•Facilitate designers to create design artifacts

•Resolve technical problems by addressing problems at a conceptual level

•Help designers apply the appropriate design patterns

•Provide assistance to designers in re-factoring the classes

•Educate designers on anti-patterns and other undocumented bad practices

•Review design documents for correctness and effectiveness

•Validate design with client

In the Construction / Development Phase, the architect plays the role of an Observer . He needs to carry out at least the below mentioned activities in this phase

• Define the construction process

•Ensure architecture adoption

•Educate developers on architecture and design

•Mentor the developers

•Reduce waste in development time and cost

•Recommend good coding practices

•Perform random code reviews

•Verify the implementation

•Collect architecturally significant metrics for future use

In the Testing Phase, the architect plays the role of a Advisor . He needs to carry out at least the below mentioned activities in this phase

•Review test cases, test plan, test strategy and acceptance criteria/acceptance test cases randomly

•Help identify issues and prioritize/triage them for resolution

•Mediate between testers & developers

•Perform random testing