Secret of great architects from msdn)

ArticleDirectory

• Hardware Engineer
• Multiple Views in each hierarchy
• Consistency between layers must be maintained
• Domain Abstraction Level
• Abstract level of business processing
• Logical Abstraction Level
• Physical Abstraction Level

Author: Don awalt and Rick mcumber ,.

Abstract:All great architects have mastered the skills to conceptual solutions at different levels of abstraction. By organizing a solution to a discrete level, architects can focus on a single aspect of the solution and ignore all the remaining complexity. Demonstrate technologies that apply abstract layers to IT solutions and compare them with other engineering disciplines.

Apply abstract layers to IT solutions

Enterprise Architects are facing a lot of complexity challenges. Develop an independent department application that can automatically Process Enterprise tasksProgramIt is one thing. Designing and forming a global network of IT labs that support tens of thousands of IT users, full of applications, servers, and databases (all supporting a variety of enterprise activities) is totally different. To combine these complexities, IT networks must be available at any time, respond quickly, and protect enterprises' valuable information assets. In addition, IT networks must be flexible enough to support the ever-changing needs of enterprises and adopt new technologies.

Some architects are obviously outstanding in this complexity and are constantly improving. In our career, we were very lucky to work side by side with some really great analysts and architects. Reflecting on these experiences, we have analyzed what makes an outstanding architect.

Without exception, all great architects have mastered the skills to conceptual solutions at a very different abstraction level. By organizing a solution to a discrete level, architects can focus on a single aspect of the solution, ignoring all the remaining complexity. Once they have stabilized a part of the solution, they can continue to process other aspects, so as to constantly develop and complete the layers into the final bond model that can be implemented.

Most software developers understand how to break down the solution into abstract layers. However, in actual projects, this is very difficult to put into practice. When you encounter the first difficulty, it is easy to give up these layers when you are eager to start encoding. Great architects will face these challenges and strictly maintain these levels throughout the project lifecycle. They realized that if they did not, they would eventually be overwhelmed by complexity.

This article demonstrates how to apply abstract layers to IT solutions. First, we will demonstrate this method through a simple example, and then propose a structure of system products based on the formal abstraction level.

Abstract layer: powerful weapons for all engineers

Other engineering disciplines, such as civil engineering engineers, have been exploiting abstract hierarchy replication complexity for centuries. Let's take a look at how other more mature engineering disciplines apply abstract layers, starting with electronic engineers who design computer systems that become more complex every update.

Hardware Engineer

System designers use abstract layers to model computer systems. Each layer is well-defined and provides a different angle for the system. Many systems are designed at three major levels: systems, subsystems, and components, suchFigure1.

Layering enables engineers to integrate a large number of complexities into a single work computer system. It is impossible to understand a computer at the level of its atom. There are about 25,000,000 transistors on an Intel itanium chip.

For IT-related disciplines, this method of decomposing complexity into the abstraction layer is certainly not the only one. Similar methods are used in countless other disciplines from aviation engineering to microbiology.

Back to Top

Core principles of application abstraction layers

All engineers follow this core principle at the application abstraction layer. These principles also apply when an abstract hierarchy is applied to software.

The number and scope of these layers are well defined so that engineers can collaborate on complex systems, and all team members must share the same understanding of the layer. As long as designers make design decisions, they must archive those decisions to the appropriate level of detail.

The three abstract layers are defined as follows:

FigureI.Three levels of abstraction defined

FigureII.A simple framework of abstraction layers

Multiple Views in each hierarchy

The complexity of a single layer can become so much that people cannot grasp it all at once. In this case, the engineer presents the design in a single hierarchy through multiple views. Each view presents a separate aspect of the design, but remains at the same abstract level. For example, the motherboard engineer creates a view for each layer of the board to model the design of the connection path for each layer.

Figure1.Abstract hierarchy of computer systems

Consistency between layers must be maintained

In order for the system to run as expected, each subsequent layer must be an appropriate improvement of its parent layer. If the computer system designer switches from the IDE bus to the SCSI bus, the interface specifications of all devices must also be switched to SCSI. If the layers are not synchronized, the system will not execute them on the top layer as expected.

Back to Top

Apply abstract layers to IT systems

Now that we have analyzed how other disciplines apply abstract layers, let's apply this technology to IT solution 1. The following sections describe the requirements, design, and implementation modeling techniques for typical IT applications at the application abstraction level. These technologies are presented through a simple and guided Online Order System example for hypothetical retailers. In our example, we not only include the architecture, but also extend the scope to include system requirements and business environments-as defined by the retail industry.

Back to Top

Simple framework: Four abstract Layers

Our simple example defines the following four abstract layers of the IT solution:

•	Domain
•	Business Processing
•	Logic
•	Physical

At each layer, we present both the dynamic view of the behavior at the specific layer and its static view. Dynamic Views model messages between objects, while static Views model structures and relationships between objects.

Domain Abstraction Level

With the above range rules applied, the retailer will act as the actors in the black box center at the domain level. The customer acts as an external actor. Domain layers are modeled from the customer's perspective. Only models the purchase interaction. The Communication form used to complete the purchase is not included in this level, but will be introduced at the business processing level.

Figure2.Dynamic View of domain-level items purchased from retailers

Figure3.Static view of domain-level items purchased from retailers

Dynamic View

The dynamic view in the Domain Layer modeling the interaction between customers and retailers. Summarizes the domain environment and contains a brief description of the use cases of business interaction.

Figure4.Dynamic View of business processing layers for purchasing items from retailers

Static View

The static view at the domain level models the relationship between the class structure and the objects they appear in the use case. In other words, it indicates what objects the customer needs to understand in order to complete the purchase transaction at this abstract level.Figure5The class relationship diagram of the static view at the domain level is displayed.

Figure5.Static view of business processing layers for purchasing items from retailers

The customer is an instance of person. The relationship between the customer and the retailer is embodied as an account. All purchase operations are related to the customer's account. Purchase is related to each purchased item. Each item is related to a specific product. Here, the product follows the metadata mode. The product instance is actually a class. Adding other products to catalog is a data-driven process and does not affect the class model. Therefore, modeling a product as a metaclass makes our model more flexible. For these classes, each payment is related to its purchase.

As you may see, this hierarchical model is representative for most retailers (whether online or traditional, large or small. This explains why the [industry] domain model should indeed define the company as an actor in the black box center. Companies in the same industry tend to support the same set of business interactions with their external actors. In addition, the domain model removes the company's specific business processing, because the companies in the same industry will have considerable changes.

The domain layer strictly focuses on the business interaction seen from the perspective of external actors. We must note that the implementation mechanism used to complete interaction should not be included. These details belong to the next abstraction level. Therefore, in this example, we only model browsing, selection, purchasing, and payment. We do not model how to complete these interactions (by phone, US post, email, web application, personal visit, check, credit card, or cash.

Abstract level of business processing

The next abstraction layer is the company's business processing modeling to achieve interaction at the domain level. The system layer scales the company's black box and identifies all employees and systems that collaborate to complete business transactions. At this level, the system to be developed acts as an actor in the black box center.

The range rules at the system level are applied, and the online order system acts as an actor in the black box center. Customers and employees act as external actors. The system layer is modeled from the perspective of customers and employees. The customer executes the purchase online. Payment is done by credit card. Fulfill the order by shipping the item to the customer's receiving address. The shipment notification is sent by email.

Dynamic View

The dynamic view replays the domain-level purchase transaction, which discloses the retailer's internal business processing.Figure4Summarizes the business processing environment and provides a brief description of the interaction between the system and its actors.

Static View

The static view at this level improves the class model to capture the objects that appear in the use cases at the business processing level. In other words, "What do customers and employees need to understand in order to create an order online and fulfill the order ?"Figure5Shows the class relationship diagram of the static view of the business processing layer. We modify the domain class model to capture the angle at this abstract level. The abstract of person, account, and company remains unchanged, and the Catalog and product are the same. However, order is used to replace abstract purchase events from the domain model.

Order includes lineitem, which is associated with the product in catalog. Because this layer models the company's internal business processing, we need to obtain an attribute of the existing inventory (minimum inventory unit (SKU, it indicates the inventory of items in a specific position ). We also model the customer's useraccount, which provides access to the online system. Payment is done by using creditcardaccount. Location represents a geographic location in the United States. It serves as the bill mailing address and the order receiving address. Shipment contains items included in shipment.

We create methods at the System Abstraction Level to simplify business processing, so this level usually requires a lot of creativity. To this end, transactions in a single domain are usually implemented in several different forms at the business processing level. For example, a purchase can be completed through an online, phone, email, fax order form, or in person at a retail store. For each form, you need to model it at the business processing level. Please note that although credit authorizer is an external performer for retailers, it is still introduced at this level because it only needs to implement the first business processing at this level.

Note that the system is technically independent. Our online purchasing system can be implemented using any web technology. Selecting Technology in the black box of the system is an architectural decision.

Logical Abstraction Level

The logic layer scales in the system black box to expose high-level system design. The architect selects the technology and defines the advanced system structure. In our simple example, the system is composed of Microsoft IIS/Microsoft ASP. NET servers that host the presentation layer, business layer, and data access layer, and Microsoft SQL Server database servers that host persistent data.

Dynamic View

The Dynamic View on the logic layer tracks the message streams through the main components of the system. As shown in the example, when submitting a confirmorder web form,Figure6Trace this message stream.

Figure6.Dynamic View of the logical hierarchy of online purchases from retailers

Static View

The static view at this level also switches our perspective to the system. Although the business processing layer creates a model for the real abstraction that appears in the business processing, this layer is abstracted as it is to be represented in the system. In actual systems, the architect designs classes for each software layer (presentation layer, business layer, and data access layer. To keep this article concise,Figure7Only the Static Design of the business layer is displayed to show how the system layer abstraction improves the design.

Figure7.Logical hierarchical static view of online purchases from retailers

The architect makes improvements to the system layer class to design the business layer interface.

Because all accounts and customers in the system are retailers, it is impractical to create a single company instance and associate it with all accounts. Therefore, company is omitted at this level. We only store the credit card number and Bill mailing address provided by the payment, rather than creating a separate instance for each creditcardaccount. In addition, it is impractical for the system to create an instance for each sold item, so the item is deleted from the model, then, the model tracks the number of items ordered in lineitem andShippeditemsThe number of items included in the class.

The architect also defines the service intervals exposed at the business layer. In this example, the CREATE, read, update, and delete (crud) services are exported at the business layer account, useraccount, order, shipment, and catalog. The oval indicates the crud interval.

Please note that, even if the class at this level is not a suitable superset of the business processing class, the architect can directly improve the business processing class and change the perspective from outside the system to inside the system to implement this design.

Physical Abstraction Level

The structure implemented by the system is captured at the physical abstraction level. The system acts as the network implementation of a node. Each node is configured with hardware and software. The three software layers (presentation layer, business layer, and data layer) in the logic view areCodeForm is physically implemented and deployed on these nodes. The persistent classes in the logical view are physically stored in the relational table of the SQL Server database.

Dynamic View

The dynamic view tracks the message streams that pass through the physical configuration node. Confirmorder http post flows from the client's browser to the Web server over the Internet through the retailer's firewall, where Microsoft Windows forwards it to IIS and IIS passes it to Microsoft ASP. and then ASP. net scheduling confirmorder. aspx. Fortunately, modern development tools isolate us from most physical networks. However, architects need to understand the physical layer to avoid network bottlenecks and Security exposure.

Static View

Static view (Figure8Improve the persistent class in the logical view to its physical representation. In our retail example, the business layer class is stored in the following SQL Server table.

Figure8.Physical-level static view of online purchases from retailers

Classes mapped to Relational Tables and properties are implemented as columns. One-to-one and one-to-many relationships are implemented using a foreign key. Open concurrency is implemented by assigning a datetime field to each parent class that is "condensed.

At the design logic level, architects focus primarily on implementing system functions. Once you are confident that the system functions are included, the architect will be able to focus on the physical optimization implementation.

Back to Top

Through iterative development layers

After this framework is established, the architect develops the solution through several iterations. Each iteration combines additional features-invoice, order pending, order in person, telephone order, and so on. In each case, the architect updates the appropriate abstraction layers and then improves these updates to the physical implementation layer.

Back to Top

Core Principles of revisits Abstraction Layer

Let's test our example against the core abstraction hierarchy principle.

•	The quantity and scope of these layers are well defined.: We have four different layers: Company black box, system black box, logical design in the system, and physical implementation.
•	Multiple Views in each hierarchy:In this simple example, a dynamic view and a static view are displayed at each level.
•	Consistency between layers must be maintained:If you make changes to the domain model, the changes will certainly affect the lower level. For example, if a retailer decides to provide a maintenance contract for its product, the analyst adds maintenancecontract to the domain model and improves it to its physical representation. To maintain a large system, it is important to synchronize all layers. Because an enhancement request is submitted, the analyst performs an impact assessment on the corresponding level of detail. Some enhanced requests affect the domain level (and thus affect all subsequent levels ). Other requests only affect the physical level.

Back to Top

Extend the hierarchy to support enterprise solutions

Now that we have shown a simple example with four abstract layers, let's extend this method to support it enterprise solutions.Figure9Shows a Rational Unified Process (RUP) configuration, which organizes the project products to a well-defined abstract level.

The levels in the table are described as follows.

Figure9.Organize the project products to a well-defined abstract levelRUPConfiguration

•	Domain. Capture the business environment of the project at the domain level.
•	Project Insight. Project Insight communicates with the business impact that the system will have on the Enterprise. It quantifies the impact through ROI analysis. Project Insight represents the highest Abstraction Level of the project.
•	Business Processing. The system layer is used to model business processing within the company. For extremely complex units, this level can be further divided into sub-layers: departments, departments, and departments.
•	UISpecifications. Ui specifications design a user interface for business processing. It consists of the UI design document and functional UI prototype.
•	Detailed requirements. Detailed requirements specify the minimum level of abstraction required by the system. It includes details such as data type formats and detailed business rules. It also includes professional requirements, such as performance, availability, security, internationalization, configuration, scalability and flexibility requirements.
•	Architecture. The system architecture is organized into six views: • Logic. Define the main abstraction of the software layer and the execution of system functions. • Concurrency. Capture the parallel aspect of the system, including transactions, server farms and resource contention. • Security. Defines methods for identity authentication, authorization, and protection of confidentiality and logging. • Deployment. Define the network topology and system deployment configuration. • Components. Define system components, interfaces, and dependencies. • Data. Define the design structure of persistent data.

Back to Top

Advantages

Organizing system products to discrete abstraction layers has several advantages:

•	it separates system requirements from three different abstract layers: business processing, UI specifications, and detailed requirements. We will not use a single overall functional specification that makes enterprise users feel overwhelmed. Instead, we communicate system requirements at the three levels of improvement details.
•	analysts and architects can control complexity in a single, integrated system model.
•	architects can focus on individual aspects of the system and integrate those decisions into the entire solution.
•	the abstract level forms the structure of the system product. For example, the software architecture document specifies a section for each view.
•	the abstraction layer provides direct traceability from requirement to design to implementation. The tracking capability enables the team to perform precise impact assessments when evaluating change requests.
•	after several systems are developed using the same framework, the mode is formed at each abstraction layer. Organizations can catalog these patterns and other best practices at each abstraction level. The Directory of this best practice serves as the basis for a process improvement plan.

Back to Top

Summary

To deal with complexity, all engineering disciplines apply formal abstraction layers. The software is no exception. To achieve the advantages of abstract layers, the project must:

•	Formal identification level. Each level has a well-defined range.
•	Separate the complexity of a hierarchy into multiple views.
•	Maintain consistency between layers.

Through a simple example, this article demonstrates how to apply abstract layers and then extend this method to support enterprise IT solutions. It provides a RUP configuration framework that organizes system products to a well-defined abstract level.

Back to Top

Self-evaluation

•	Does your current project have an abstract level applied?
•	Is the hierarchy well defined?
•	Does the project team understand these layers well?
•	If the complexity changes too much in one layer, does the team separate it from the view?
•	Does the team maintain consistency across layers?
•	Will your project benefit from the abstraction layer?

Great architects instinctively follow these principles. The rest of us must consciously apply abstract layers and use rules to maintain these layers throughout the project lifecycle.