Original text:
Http://www.microsoft.com/china/msdn/library/architecture/architecture/architectureTopy /usdnmajgreatarchitect.mspx
The secret of great architect
Release Date: 10/13/2004
| Update Date: 10/13/2004
By Don Awalt and Rick McumberRda Corporation
Abstract: All great architects have mastered the skills of conceptualization solutions at different levels of abstraction. The architect can focus on the single aspect of the solution to ignore all remaining complexities in a single aspect of the solution. Shows the technology to apply abstract hierarchies to IT solutions and compare them with other engineering subjects.
This page
Apply an abstract level to an IT solution Abstract level: All engineers' powerful weapons application abstract hierarchy applied to IT systems simple frame: four abstract hierarchies Re-visited abstract hierarchical core principles Extended hierarchical Support enterprise solutions Advantage Summary Self-assessment
Apply abstract hierarchy to IT solution
Enterprise Architects are being challenged by the large number of complexities they face. Develop an independent department app that automatically handles business tasks is a matter. Designed and form a IT laboratory global network that supports Unshanti IT users is an IT laboratory of applications, servers, and databases (all support multiple corporate activities), which is exactly another thing. To combine these complexity, IT networks must be available at any time, respond quickly and protect corporate valuable information assets. In addition to all of this, IT networks must also be flexible to support the needs of enterprises, and adopt new technologies.
Some architects are significantly excellent in this complexity and are constantly progressing. In our career, it is very fortunate to work with some truly great analysts and architects. Reflections these experiences, we have analyzed what made outstanding architects.
None exceptions, all great architects have mastered the skills of conceptualization solutions at the completely different levels of abstraction. By organizing solutions to discrete levels, architects can focus on all remaining complexities in a single aspect of the solution. Once they stabilize some part of the solution, they will continue to handle other aspects, thereby constantly developing hierarchical development and improving the adhesive model that can eventually be implemented.
Most software developers know that the solution should be decomposed to an abstract level. But in the actual project, this is very difficult to practice. When you encounter the first difficulty, it is easy to abandon these levels when you are eager to start coding. The great architect will experience these challenges and strictly maintain these levels throughout the life cycle of the project. They realized that if not doing so, it will eventually be submerged in complexity.
This article shows the technique of applying abstract hierarchy to IT solutions. First, we will demonstrate this method through a simple example, then propose a structure of system products based on formal abstract hierarchies.
Back to top
Abstract level: powerful weapons of all engineers
Other engineering disciplines, such as civil engineers, have been using abstract hierarchical complexity in centuries. Let us learn how other more mature engineering disciplines apply abstract hierarchy, starting with electronics engineers, they are designed to make more complex computer systems.
hardware engineer
System designers use abstract levels to model computer systems. Each level is well defined and provides a different angle of the system. Many systems are designed at three main levels: systems, subsystems, and components, as shown in Figure 1.
The layering enables engineers to integrate huge amounts of complexity into a single working computer system. It is impossible to understand a computer at the level of its atomic part. About 25,000,000 transistors on a single Intel Itanium_ chip.
For IT-related disciplines, this method of decomposes complexity to abstract layers is of course not only unique. A similar approach is used to use numerous other disciplines from aviation engineering to microbiology. Back to top
Core principle when using abstract hierarchy
All engineers follow this core principle when applying an abstract level. These principles are equally applicable when applying the abstract level to the software.
The quantity and scope of these levels are well defined so that engineers can collaborate on complex systems, and all team members must share the same understanding of the level. As long as the designer makes design decisions, they must file those who decide to the corresponding detail.
The three abstractions are defined as follows:
Figure I. Three abstractions defined
Figure II. A simple frame of abstract hierarchy
Multiple views per hierarchy
The complexity within a single level can become very much, so that people cannot master all once. In this case, the engineer will design in a single level through multiple views. Each view shows a separate aspect of the design, but remains at the same abstraction level. For example, the motherboard engineer creates a view for each layer of the board to model the design of the connection path of each layer.
Figure 1. Abstract level of computer system
Must maintain consistency between hierarchy
In order to allow the system to operate as expected, each subsequent layer must be an appropriate improvement in its parent layer. If the computer system designer switches from the IDE bus to the SCSI bus, the interface specification of all devices must also switch to SCSI. If the level is not synchronized, then the system will not be executed on the top floor as expected.
Back to top
Apply abstract level to IT system
Since we have analyzed how other disciplines apply abstract levels, let us apply this technology to IT solutions 1. The following sections show the application of the application of the abstract level for a typical IT application, design and implement modeling techniques. These technologies are shown by a simple, guided online order system example for imaginary retailers. In our example, we not only include architecture, but also extend the scope to include system requirements and business environments - as defined by the retail industry.
Back to top
Simple frame: four abstractions
Our simple example defines the following four abstractions of the IT solution:
• Domain • Business Processing • Logic • Physics
Within each hierarchy, we showcase the dynamic view of this particular hierarchy, but also show its static view. The dynamic view is the message modeling between the object, and the static view is the structure and relationship between the objects.
Domain abstract level
The above range rules are applied, and the retailers will be actors in the centers of the domain hierarchy. Customer as an external actor. The domain hierarchy is modeled from the perspective of the customer. Just modeling interaction. The communication form used to complete the purchase is not included in this level, but will be introduced at the service processing level.
Figure 2. Dynamic view of the domain hierarchy of items from the retailer
Figure 3. Static view of the domain hierarchy of items from the retailer
Dynamic view
Dynamic views in the domain hierarchy are interactive modeling between customers and retailers. The figure below summarizes the domain environment and includes a simple business interaction case description.
Figure 4. Dynamic view of business handling level on purchasing items from retailers
Static view
The static view of the domain hierarchy is the class structure and the relationship modeling of their objects that appear in the case. In other words, it illustrates what objects need to understand at this abstract level. Figure 5 shows the relationship diagram of the domain hierarchical static view.
Figure 5. Static view of business handling hierarchy about purchasing items from retailers
The customer is the instance of Person. The relationship between customers and retailers is embodied as Account. All Purchase is related to the customer's Account. Purchase is related to each purchased Item. Each Item is associated with a specific product, where produter follows the meta mode. The example of Product is actually itself is class. Adding other Product Add to Catalog is completely a data driver, and does not affect the class model, so it will make our model more flexible to a Class model. Focusing on these classes, each Payment is related to its purchase. As you may see, this level model is representative for most retailers (regardless of type online or traditional, large or small). This shows why [Industry] domain model does define companies to define the actors in the centers of black boxes. Companies in the same industry tend to support the same business interaction with its external actors. In addition, the domain model excludes the company's specific business processing because they will have considerable changes between companies in the same industry.
The domain hierarchy is strictly interacting in the business interaction seen from the perspective of external actors. We must pay attention to this, do not include implementation mechanisms for completing interactions. These details belong to the next abstract level. Therefore, in this example, we only model it for browsing, selection, purchase, and payment. We don't model how to complete these interactions (via telephone, US Post, email, web applications, personally travel, check, credit card or cash).
Business handling abstract level
The next abstract level is modeling the company's business processing to achieve interaction capture in the domain hierarchy. The system level "internal zoom" company's black box and identifies all employees and systems collaborated to complete business transactions. At this level, the system to be developed as an actor of the black box center.
The scope rules of the system level are applied, and the online ordering system is used as an actor as a black box center. Customers and employees are external actors. The system level is modeled from the perspective of customers and employees. Customers are purchased online. Payment is done by credit card. By transporting the item to the customer's receipt address fulfillment order. The shipping notice is sent by an email.
Dynamic view
Dynamic view repeated domain hierarchical transactions, which discloses the retailer's internal business processing. Figure 4 summarizes a business processing environment and includes a simple use case description regarding interaction between the system and its actors.
Static view
This level of static view has improved the class model to capture the object that appears in the business handling hierarchy. In other words, "In order to create a set of orders online and perform this order, which objects and employees need to understand which objects?" Figure 5 shows the class diagram of the business handling hierarchy static view. We modify the domain model to capture the angle at this abstract level. Abstract in Person, Account and Company are the same, Catalog and Products. However, with the ORDER replaces an abstract Purchase event from the domain model.
ORDER includes lineItem, which is associated with Product in Catalog. Because this level is modeling the company's internal business processing, we need to get an existing inventory (minimum inventory unit (SKU), which represents the inventory of items in a particular location). We also model our customers' UserAccount, which provides access to online systems. Payment is done by using CreditCardAcCount. Location represents a geographic location in the United States, as a bill mailing address, and also as the shipping address of the ORDER. Shipment contains Items included in ShipMent.
We create methods in the system abstract hierarchy to simplify business processing, so this level usually requires a lot of creativity. To this end, a single domain hierarchy transaction is usually implemented using several different forms of business processing hierarchy. For example, a purchase can be done by online, telephone, email, fax a fixed list or personally go to retail stores. For each form, it is necessary to model its business processing level. Please note that despite the retailer Credit Authorizer is an external actor, it is still introduced at this level because it only needs to implement business processing in this level. Finally, please note that the system is technically independent. Our online purchase system can be implemented in any Web technology. Selection technology in the system black box is an architecture decision.
Logic abstract level
The logical layer is scaled within the system black box to disclose high-level system design. Architect selection technology and defines a senior system structure. In our simple example, the system is composed of Microsoft IIS / Microsoft ASP.NET servers that carries represent layers, business layers, and data access layers, and Microsoft SQL Server database servers carrying persistent data.
Dynamic view
The dynamic view on the logical layer tracks the message stream through the system's main components. As shown in the example, Figure 6 traces this message stream when submitting the CONFIRMORDER Web form.
Figure 6. Dynamic view of logical hierarchical dynamic view from the retailer online purchase item
Static view
This level of static view also switches our view to the inside of the system. Although the business handling level is established in the real abstraction in business processing, this level will be like this to be represented in the system. In actual systems, architects are designed for each software layer (representation layer, business layer, and data access layer). In order to maintain the simplicity of this article, Figure 7 shows only the static design of the business layer to illustrate how the system layer is improved for design.
Figure 7. Logical hierarchical static view of purchasing items online from the retailer
Architects improve system layers to design business layer interfaces.
Because all accounts and customers in the system are retailers, create a single COMPANY instance and make it unrealistic to all accounts, so the level is omitted. We just store the credit card number and bill mailing address of Payment, which is not created a separate instance for each CreditCardAccount. In addition, for the system, creating an instance for each sale of Item is unrealistic, so Item is deleted from the model, and it is changed to the number of items subscribed by the model tracking LINEITEM and attached in the new SHIPPedItems class. number of the stuffs.
Architect also defines the service interval disclosed in the business layer. For this example, the business layer exports Create, Read, Update, and Delete (CRUD) services for Account, Useraccount, Order, Shipment, and Catalog. The ellipse pointed out the Crudacity.
Note that even if the class of this level is not the appropriate supercoming business processing class, the architect can also change the viewing angle to the system inside the system by directly improvement of the business processing class.
Physical abstract level
Structure of physical abstract hierarchy capture system. The system is implemented as a network of a node, and each node is configured with hardware and software. The three software layers in the logical view (indicating layers, business layers, and data layers) are physically implemented in code form and deploy them on these nodes. The persistent class in the logical view is stored in the relational table of the SQL Server database.
Dynamic view
Dynamic view tracks the message stream that passes through the physical configuration node. Confirmorder HTTP POST flows from the customer's browser flows through the retailer's firewall to the web server, where Microsoft Windows forwarded it to IIS, IIS passed it to Microsoft ASP.NET, then ASP.NET scheduling confirmorder.aspx. Fortunately, modern development tools will be separated from most physics networks. However, architects need to understand the physical layer to avoid network bottlenecks and safety exposure. Static view
Static view (Figure 8) Improves the persistent classes in the logical view to its physical representation. In our retail example, the business layer is stored in the following SQL Server table.
Figure 8. Physical hierarchical static view of purchasing items online from the retailer
A class that maps to the relationship table and attributes as a column implementation. One-on-one relationship and a pair of multi-relations use a foreign key. Open concurrent is implemented by assigning a DateTime field to each parent class that is "condensed".
When designing logic level, architects are mainly focused on implementing system functions. After confident that the system is included, the architect can focus on the optimization of physical hierarchies.
Back to top
Through iterative development level
After the establishment of this framework, architects developed several iterations. Each iteration merges additional function - invoice, disposal, order, phone order, etc. In each case, architects update the appropriate abstract hierarchy, then improve these updates to physical implementation layers.
Back to top
Re-talking about the core principles of abstract hierarchies
Let us test our examples against the principle of core abstraction.
• The quantity and scope of these levels are well defined: we have four different levels: company black box, system black box, logic design in the system, and physical implementation. • Multiple views per hierarchy: In this simple example, we show a dynamic view and static view at each level. • The consistency between hierarchies must be maintained: If you make changes to the domain model, the change must also affect the lower level. For example, if the retailer decides to provide maintenance contracts for its products, analysts add maintenanceContract to domain models and improve them to their physical performance form. For maintenance large systems, all levels of synchronization are important. Since the enhancement request is submitted, the analyst performs the impact assessment of the corresponding detail level. Some enhanced requests affect domain hierarchy (and thus affect all subsequent levels). Other requests only affect the physical level.
Back to top
Extended level to support enterprise solutions
Since we have shown a simple example with four abstract hierarchies, we will now extend this method to support IT companies' solutions. Figure 9 shows an Rational Unified Process (RUP) configuration that organizes project product products to define a perfect abstract level.
The layers in the table are described below.
Figure 9. Configuration of project product organization to define a perfect abstract level
• area. Domain hierarchy capture project business environment. • Project insight. Project insights communicate with the system's business impact on the system. It analyzes this impact in investment returns. The project insight indicates the highest abstraction level of the project. • Business processing. The system level is modeling in the company's business processing. For extremely complex units, this level can be subdivided into sub-level: department, departmental room, and within the department. • UI specification. The UI specification is designed to implement the user interface for business processing. It consists of a UI design document and a function UI prototype. • Detailed requirements. The minimum level of abstraction required for system requirements is required in detail. 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 execution system function. • Concurrent. In parallel with the system, including trading, farms, and resource disputes. • safety. Define methods for authentication, authorization, protection confidentiality, and logging. • Deploy. Define a network topology and system deployment configuration. • Components. Define system components, their interfaces, and dependencies. • Data. Define the design structure of persistent data. Back to top
advantage
There are several advantages to discrete abstract levels:
• It uses system requirements to three different abstract levels: business processing, UI specification, and detailed requirements. We will not use a single overall functional specification that makes business users feel unknown. Instead, we communicate system requirements in three improvement details. • Analysts and architects can control complexity in a single, integrated system model. • Architects can focus on a single aspect of the system and integrate those decisions into the entire solution. • Abstract hierarchy forms the structure of the system product. For example, a software architecture document has a section for each view. • Abstract hierarchy provides direct tracking capabilities from request to design. Trackable capability enables the team to perform an accurate impact assessment when evaluating changes. • After using the same frame to develop several systems, mode is formed at each abstract hierarchy. Units can catalog these modes and other best practices within every abstract level. This best practice is the basis for the process improvement plan.
Back to top
summary
In order to handle complexity, all engineering disciplines apply formal abstract hierarchy. Software is no exception. In order to achieve the advantages of the abstract level, the project must:
• Formal identity hierarchy, each level has a well-defined range. • Separate complexity within a hierarchy to multiple views. • Keep consistency between levels.
Through a simple example, this article demonstrates how to apply abstract hierarchy, then extending this method to supporting a business IT solution. It provides a RUP configuration framework that organizes system product organization to define a perfect abstract level.
Back to top
self assessment
• Does your current project apply an abstract level? • Is the hierarchy defined perfect? • Does the project team understand these levels well? • If the complexity has become too large in one level, is the team split into the view? • Does the team maintain consistency between levels? • Does your project benefit from abstract hierarchies?
Great architects can follow these principles. Our remaining people must consciously apply abstract levels and use rules to maintain these levels throughout the project lifecycle.
Resource
Cockburn, Alistair. Writing Effective Use Cases. New Jersey: Addison-Wesley, 2001
Kroll, Per And Kruchten, Philippe. The Rational Unified Process Made Easy: a Practitioner's Guide To The Rup. Boston MA: Pearson Education And Addison-Wesley, 2003
Demarco, Tom and Plauger, P J Structure. Prentice Hall PTR, 1979
To get a Copy of the DOD Standard 2167A, visit http://www2.umassd.edu/swpi/dod/mil-std-2167a/dod2167a.html.
footnote
1 Many people have successfully applied abstract hierarchy to software. Ed Yourdon and Tom Demarco proposed structural analysis and structured system design in 1979. Many of the US government's branches standardize the 2167A standard of the DOD, which requires the system consisting of hierarchical hardware and software configuration items. The DBA community often applies the detail level to the relational database modeling. In particular, the Bachman toolset and the information engineering methodology of James Martin (IEM) are modeled for database logic, and then their physical modeling. Type "Software Levels of Abstract" on Google to search for several results, but most of them come from academic communities, and their content looks concentrated in formal computer language. About author
Don Awalt is the founder and CEO of RDA Corporation, which is a custom software engineering company, founded in 1988, in Washington, DC, Baltimore, Atlanta, Philadelphia and Chicago have offices. As a Microsoft Gold Certified Partner, the company focuses on using the .NET Framework development enterprise web and rich client systems. Don is currently the regional director of the Washington DC, which once served as the first regional director of Philadelphia. DON often speakers in industry activities, including Tech Ed, Developer Days, MSDN activities, and a variety of SQL Server and Windows events. He is the special editor of SQL Server Magazine and PC Tech Journal Magazine and also writes manuscripts for other publications. The technical field known as Don includes the development of web services, SQL Server, modern programming languages, and many architectures and processing works in Microsoft's Prescriptive Architecture Group (PAG). You can contact DON via AWALT@rdacorp.com.
Rick Mcumber is the quality and best practices of RDA. He has worked for IBM and Rational Software Corporation for 11 years and is committed to the US Department of Transport, Ministry of Defense, NASA and Canada National Defense Development System. Since 1994, he has been working in RDA and is committed to developing business solutions for its customers. You can contact Rick with Mcumber@rdacorp.com.
Go to the original English page
