UML software engineering organization
Beijing Dragon Fruit Software Engineering Technology Center
User mode integrated UML view
Alexander Egyed, Davidqql Translation
Summary
Mode is important to develop reusable designs and architectural configurations during system combination (synthesis). This thesis study on model knowledge, which can also be used in the integrity of systematic analysis inspection system model. In order to support the automatic analysis process, the work introduces a view integration framework. Since each view (for example, block diagram) adds an additional software system viewpoint for the model, information from one view may be used to verify the integrity of other views. This form of integration requires something deeper to view, and what information can be shared (or constraint). Therefore, it is also a valuable source for view integration automation. Introduction
To support software product development, we frequently use General Software Development Models (and Tools), such as unified modeling languages (UML). However, usual software development and specific software design (main focus is the main focus of our work) require not only the content that most general models can provide. The system structure is about: 1) Solving the actual problem full modeling 2) Solution Model Issues and 3) Interpretation The main focus of the model scheme in the real world is placed on the architecture of the architecture (such as block diagram), and there is no match between Identification and adjustment. We often find this situation in this regard, analysis and (architectural) explanation of the explanation in most general languages. Our constructors are not just because we want to build (creation), and because we must understand. In this way, the system constructs have many conceptual integrity, consistency, and thorough work to be completed. It has been fully an emergence of UML in fact OO software development standards, and there is no exception on this issue. This work explains the reasons why the architecture does not match in the UML view, and how the description mode and integrated technology can be applied to identify and solve them in a more automated manner. In order to do this, this work discusses the view integration framework, its primary activity - mapping, transformation, and differentiation (DIFFERENTITION). This paper will study the role of the model, rather than concentrating on a large number of integration techniques (they support the above activities). In this way, we will help the knowledge of the research model help to ensure the consistency of software system models. In such way, we use the mode as much as possible in the past: We use the mode as systematic analysis, rather than use as build materials as system components. View and model
In software development, we use models and view to handle complexity of software systems. Here, the model is a collection or view of the view to see an aspect of the model (or point of view). IEEE Standard (Draft) 1471 [AT & T1993] The view is attributed to "proposing the stakeholders of one or more system interests". For interest related people, we are defined as sharing systems pay attention or interest in individuals or groups (for example, developers, users, consumers, etc.). Applying to our context, the view is a fragment of the model, and it should be fine to us to understand, but also contain association information about a specific relationship. In UML, the view is essentially graphically, and is often implemented by block diagrams. Views (such as class or sequence diagrams) Services: l Abstract and simplified model l makes different interest-related people coordinated work L for different interpretation (different audience / stakeholders) l Extract about specific associations What type of view will be used and when they use them to reluctantly dependence on which person is using and needs to be done. However, the view is not a silver bomb developed by software because they specifically express basic problems; they are interior and they exhibit equal number of modeling element redundancy. To give a simple example, we have a software development case and product implementation (for example, C code) that we have a design (eg, in the form of a UML class). Class diagrams and code expressions different views, express the same or similar information in different methods. Although the code can be automatically generated from the design, this approach is limited, and some information must be added multiple times. Worse, now these redundant information clips must be consistent - most of them are manual activities. In this way, no matter when the design changes, the code will become inconsistent (vice versa), we have to apply some views and activities to find inconsistencies and repeatedly guarantee the integrity of the model concept. View mismatch and redundancy Since the view is the only effective means of processing complexity, we cannot count on some less redundant things to replace them. We need to decompose the total number of information that the software developers have to handle on any given time. "This is not the number of details of complexity itself, but we have to understand the quantity of details." [Siegfried 1996] However, redundancy is a necessary misfortune. This suggests that we need a way to identify and solve the mismatched automation activities between the views. In this way, what we need is some framework of integration and analysis view. Interestingly, the view mismatch problem may approach the problem based on its unique problem - redundancy. We use redundancy between a set of views means that a view contains information about other views and can be used as constraints. This way, we use redundant information to verify consistency and integrity between views. For example, if we use some architectural modes to construct a system (eg, a layered style), the design must reflect the constraint of the architecture opposite. This means that if the architecture defines a three-layer structure, the architecture implies that the first layer in the process does not use the second layer without using the second layer and is not allowed. If the system uses a UML design (for example, using classes and sequence diagrams), the call reliance within the design element is consistent with the above-described architecture constraint. We will explain one example later. UML view Description VS integration
Enable view integration to determine and adjust the views to require two hierarchical integrated-symbol integration and semantic integration. For symbol integration, it means that the model needs to completely express views. Semantic integration can be exchanged and how to exchange for further refining. Only what and how to establish it, inconsistency can be determined. Unified Modeling Language (UML), like other universal software system development models, just not to meet the above semantic integration. UML provides a model for expressing different block diagrams to handle classes, objects, activities, status, packages, and others (see Figure 1). However, UML is not good at integrating them. The association and dependencies between the UML view are rarely captured. If the latter is not completed, the model is just loosely coupled or completely unrelated views. Although the UML and its meta model define a single view symbol and semantic feature, the acquisition within the view is not enough (there are only some weak forms of dependencies, such as classes, and objects). Figure 1 also shows another aspect of the problem - that is to extend UML to express new and external concepts (eg, style and mode). For example, how can I use more advanced patterns, such as hierarchical architectural modes [[1]] or proxy design mode in UML? In UML, we need to distinguish between just statement patterns and complete integration them again. Figure 1 UML representation method vs. integration
View integrated frame
The main obstacles for view integration are the lack of well-defined (engineering) model foundation. The view often uses a very different representation of information, which makes it easy to determine where they are more difficult. Thus, the tasks of the combination and comparison view are often manually manually and have latent errors. The goal of the integrated framework is to compensate for the deficiencies of differentiation and resolve the architecture without matching automation. As in the short narrative, when doing this, our framework needs to handle what information and how to exchange. What information we wrote there can be exchanged and how it can exchange judgment. In our view integration framework, we mentioned both events of mapping and transform. We also say that only after these activities definitions can be tried to identify inconsistency. The latter we call it differentiation (see Figure 2). Figure 2 Describe our view integration frame on a high level pattern. There, the system model is used to express the knowledge foundation of the software system. Software Developers use views to add new data to the system model and review existing data (view synthesis). For UML, the system model may be considered as a UML model and view integration through the UML design tool (such as Rational Rose). The interaction of both system models and views is a view analysis. Once new information is added, it can verify the system model to ensure its conceptual integrity. Figure 2 shows how the view analyzes can be further subdivided into three main activities described above:
Figure 2 View integration activity
l Mapping: The associated information sheet is determined by using a named dictionary, tracking, and tracking the simulation (eg, the same physical class and method) and some associated / mode form (eg, a common interface). l Transform: Operate the model element in the view so that they (or their segments) can be shared in other views (or in the system model itself). For example, we can use abstract technology to generalize a detailed block diagram, we can use views to exchange information between different types of views, or we can rearrange the model elements (or fragments) in different styles (eg, Splice and segmentation). l Differentiation: Detailed research system model identification system model (potential) mismatch. (Potential) discussed in the form of rules and constraints. In addition, mismatch resolution can be associated with how the mismatch flags will be solved their optional methods. Differentiation is strong dependent on transform and mapping. However, it must be indicated that those activities are not orthogonal to each other. Obviously, we can only make useful transformations only when you know the correct mapping of the model element. This dependency is also established. The information exported by the view transform can clarify the amphibration in many mappings. Thus, a view can be used to clarify the erliness in other views. In addition, as shown in FIG. 2, the view integration is not limited to the mode, however, the mode constitutes a very important basis for view integration. We will discuss this directional view integrated direction in subsequent chartes. Other non-mode-related view integrated directions in [EgyED1999a] and [EgyED1999B]. The above frames are usually applicable outside of UML. Product Order System Case We will use a simple product ordering system to guide throughout the text, which is divided into two major subsystems - order acquisition subsystems and order processing subsystems. The first subsystem acquires orders and payment information from consumers through the sales representative. The latter subsystem acquires the processing of the warehouse administrator to the product order queue. Product ordering system Synthesis two COTS (Commercial Off THELF) Products: Inventory system handling product inventory, and order warehouse as a database (the latter is used both for product ordering systems for inventory systems). Table 1 means that our system architecture uses a hierarchical mode (or layered style). The architecture mode will be made up of design patterns and other design features. Table 1 Discuss the layered architecture mode of product ordering system
Product ordering system
- User interface (order acquisition interface, order processing user interface, inventory user interface) - Order framework (consumer, payment, order, order line, logger) - Inventory System - Network (LAN) - Order Warehouse
How is the pattern helps view integration?
When the article is discussed, we will reveal more details about the product ordering system. Although, due to the limitations of the space, we cannot express the entire system here, and you cannot explain all integrated technologies. Instead, as mentioned earlier, we will focus on the roles of the view integration. The three integration activities corresponding to the brief description of Figure 2, the mode supports the following activities (the following will be described): mapping
Mode supports mapping between views of different abstractions (cross-references). For example, a high-level block diagram indicates the mode that is known to be implemented in a low-level block diagram. Thus, such modes exist in the knowledge of the low-level block diagram and the knowledge of this mode (as defined in [Gamma et al. 1994] and [Buschman et al 1996] help automatically authenticate in the low-level block diagram. Mode also supports mapping of different types of views. For example, a mode description often specifies its structure and its dynamic behavior. Then, you can use these knowledge in our model to cross reference structured and dynamic information. The way the transform mode is applied to the transformation is similar to that of them in the map. For transformation, we can use them as abstraction and transformation. For abstract, we mean simplified views. For example, if we want to know if the high-level view and the low-level view are consistent, we need to refine high-level views or abstract low-level views to make direct comparison. The former cannot be carried out, and the latter can. For abstract views, you need to determine the associated segment, then they are replaced by simpler. In this regard, the mode is perfect for original information because they provide knowledge that belongs together. We can use the pattern knowledge abstract low-level mode to high-level mode (or peer-to-peer components). The mode can also be used for the conversion between static and dynamic structures as we discussed in the map. Since models are often described in two models, we can derive behavior (vice versa). In this way, we can also translate the view using mode. Differentiation
As is briefly described in Figure 2, differentiation strongly depends on mapping and transformation. This means to find inconsistency in the view, we need to determine the relationship between its modeling elements, and you need to find ways from one view to another view transform information. There is no previous step we can't know what information is to be more, there is no step, we don't know how to compare. Once the above steps are completed, we can use two main technical comparison views: L (graphics) comparison: compare the transformation view and the comparison of the original view. This technology suggests that a view can keep a full-complete style transform to another view. l Constraints and rules: We frequently find that the view is unavailable to change to another, but its small partial and fragment can be. In this case, we can use rules and constraints to discuss and analyze these fragments. For differentiation, design mode is not directly useful, however, we can use the information collected by mapping and transform. We have shorted how to help mapping and transform views. In these examples, the comparison view is straightforward because the mapping and transformation are enabled directly (graphic) comparison. In any case, the model is also very useful in constraints and rules. For example, we define natural constraints in Table 1: The user interface only allows dialogue with the order frame, and the order framework can only be dialogue with inventory system. The pattern of the architecture affects the structure of the design and its behavior. Use mode in product ordering system
This section can be applied to an example of integrated activities in our product order system context of this section to supplement the above discussion. Differentiation
Figure 3 shows the high-level design view of our system using the UML package. This figure shows the interaction of the primary order system component (or subsystem). Knowledge regarding the hierarchical architecture now helps us automatically determine the architecture between the architecture in Table 1 and the design of Figure 3. Table 2 summarizes two views of opposing constraints. Architectural view Constraint from Table 1. They define the call dependencies between our system level (for example, the user interface depends on the order frame). Figure 3 is the basis for designing view constraints. This figure illustrates a UML package diagram (package and dependent semantics defined in [Booch-Jacobson-Rambaugh 1997] between [Booch-Jacobson-Rambaugh 1997]. Table 2 architecture and design view Constraint
Architecture [User interface depends on the order frame];
Architecture [Order framework depends on inventory system];
Architecture [inventory system depends on network];
Architecture [network depends on the order warehouse];
Design view constraint
Design [Order Get UI Depending on Order Framework];
Design [Order Processing UI Depending on Order Framework];
Design [inventory UI depends on the inventory system];
Design [Order framework depends on inventory system];
Design [Order Framework Depends on Network];
Design [inventory system depends on the network];
Design [network depends on the order warehouse];
Mapping
Design [Order Get UI] Map to Architecture [User Interface]
Design [Order Processing UI] mapping to architecture [User Interface]
Design [inventory UI] mapped to architecture [user interface]
Design [Order Frame] Map to Architecture [Order Framework]
Design [inventory system] mapping to architecture [inventory system]
Design [Network] Map to Architecture [Network]
Design [Order Warehouse] Map to Architecture [Order Warehouse]
Integrity rules
View view constraints for all architectural view constraints;
E.g:
Architecture [User interface depends on the order frame] =>
Presence: Design [Order Get UI Depending on Order Framework] or
Design [Order Processing UI Depending on Order Framework] or
Design [inventory UI depends on the order frame]
Consistency rule
For the design of the design view constraint;
example:
Design [Order Processing UI Depending on Order Frame] =>
Presence: Architecture [User interface depends on the order frame];
Table 3 describes the layered architecture mode of product ordering system
Product ordering system
User Interface (Order Get UI, Order Processing UI, Subject UI) Order Framework Inventory System Network (LAN) Order Warehouse is established to establish these constraints is the responsibility of the transformation, and can be automatically completed in this case. For example, using our hierarchical mode in Table 1 we can automatically export the interlayer call dependencies. The advantage is that the semantics of the model only need to be defined once and can be reused later. The semantics and symbols of the view can also be seen as a mode. Thus, the package diagram of Figure 3 has a set of predefined correlation constraints. Once defined, the design constraint can be exported to different instances of the package diagram. The mapping section of Table 2 defines the relationship between architectural views (table 1) and design view (Figure 3). In this example, the mode used for mapping is not so obvious. We will discuss their use for mapping. The last two parts of Table 2 are partial differentiation activities. There, two types of rules are defined, one for consistency and another for integrity. If some parts or connectors defined by the architecture are not reflected in the design, it may show potential incomplete. On the other hand, if the design is contrary to the architecture, this may indicate potential inconsistencies. In addition, for each set of views of our comparison, the rules only need to be defined; those rules can then be reused. Determining mismatch between architecture and design implementation is now a matter of assessing rules and constraints. This reveals mismatches without integrity, however, some inconsistent mismatches: 1) Instruction UI components Conflicts to the inventory system, the user interface does not allow direct and inventory systems without order framework Communication. 2) Similarly, the order system requires access to the network using inventory systems. Figure 3 High-level design (chart and dependence) in UML
Identify these mismatches did not give any feedback for their causes. For example, is the architecture or a design error? Table 3 illustrates that all non-match may be solved by lifting inventory systems to the order framework. All mismatches are solved. We don't believe that the actual mismatch solution will completely complete it. This approach is the same as the previous self-error correction source code compiler, and this effort is finally failed because of the complexity of the society and technology. However, we believe that providing designers do not only use (potential) mismatch, but also to solve them with regard to how they are dealing with mismatch and understanding them. In addition, it may be very beneficial to discovering techniques with better choice of conditions. We will discuss this situation in more detail in [EgyED 1996]. Mapping
Figure 4 shows another view of our system, a refining of Figure 3. In addition, this view can be verified on the revised architecture and high-level design, however, no mismatch is found. This view uses additional design patterns such as templates [[2]] (Template) mode (specified by << Template >> Construction type) and proxy [[3]] (Proxy) mode (specified by "Proxy" constructed). We will use them to further explore the value of the model in view integration.
Order processing UI
Order Get UI
Figure 4 High-level design view uses UML classes and packages
Figure 5 Low-level design view Using UML class diagram
Figure 5 depicts the corresponding low-layer implementation, which is not just solving the mode used in Figure 4, and also refines some other modeling elements. Top three classes are enabled by the user interface, the inventory system can be accessed by inventory agents, and the warehouse can be accessed similarly through the warehouse agent. To find out if the view is consistent with the previous view, we can use several integration techniques. First, we need to find out which model elements correspond to each other (map). There are several techniques to be applied, such as similarity of the name, and the like. However, in this example, the extensive use of the example allows us to develop knowledge about them for mapping. Through the high-level design in Figure 4, we understand that several facts: l Template mode For the order line (ORDERLINE) L proxy mode for bridging order line (product) (product) and inventory system L proxy mode for use Oracle Database Bridge Frame subsystem L interface features (for example, consumer classes and orders, payments, and consumer UI interface) Access
Access point
Agent mode structure
Template mode structure
Figure 6 Structured model knowledge (adapted from [Buschman et al. 1996])
Although the last item is not a clearly defined mode, it constitutes a knowledge of classes - thus, the interface feature can be regarded as a model, even if most of them are only domain mode. About the domain model knowledge is like a predefined mode (see Figure 6), so that we can now inject the relationship between modeling information. The task of mapping FIGS. 4 and 5 is thinner to determine the position of the above modes and (interface) features using predefined structured pattern knowledge discussed as shown in FIG. As a guide with Figure 6, we can easily determine the corresponding template mode (product, queue, and product queue corresponding to the order line (OrderLine)). Although it can also be easily found, how can they distinguish they are not clear enough. Note that the goal is to make the computer automatically identify them. To do this later, we can use the interface features (mode) discussed above. The idea is that there are at least some mapping or can be established by name similarities. Use this additional information It can automatically distinguish inventory (inventory) mode from Oracle mode. Unfortunately, the mapping through the mode is still more difficult than the above examples. We make a simplified assumption that the structure and behavior of the model are static. Although, usually is not those precise definitions, and we need them more general description. Figure 5 shows an example, the warehouse agent model looks not as defined. However, since the network is part of the agent class, it can merge into the proxy class, and the agent class inherits all its dependencies (the Rose / Architect of the next section will express this). Another problem with this mapping technology is the mode. When you identify, sometimes it is only roughly pointed out. For example, corresponding to queue, product, and product queues, OrderLine Queue can be found in the low-level block diagram. Although this is also correct, it lost the constituent order line (ORDERLINE) indicated in the low-level block diagram. Transform
Mode and abstraction
A separate map between the high-level views between Figure 4 and the low layer view of FIG. 5 is not sufficient to determine the mismatch. For example, in Figure 4, you can see that payment is part of the consumer, but this relationship is more complicated in Figure 5. To verify the two graphs are discussed in the same way, we can use Rose / Architect concept. Rose / Architect [EgyED-Kruchten 1999] It is considered that the mode group is three classes, and the use and object relationship is used to replace a simpler mode. In the class diagram, the relationship is discussed between the classes that are not directly connected. However, a relationship can exist through other classes (eg helper classes), which form a bridge between them (for example, assume that payment and consumer in the above examples are not directly connected, but it is still through the Helper class transaction The Transaction and Accounts are given a relationship). In this way, if some formulas are found, they can be derived from active precision, then automatic support for simplifying and abstract class graphs can be provided in the form of tool. This will allow the designer to abstract an important class from existing, more detailed models, which will make them more in the intermediate relationship between and analyze the intermediate relationships between existing, more detailed models. Different locations of the model (eg, different block diagrams, or in different packages and namespaces). RA provides this mechanism and [EgyED-Kruchten 1999] discusses this technology in detail. Currently, the RA model consists of approximately 80 abstract rules. For example, rule 4 discusses a class that is generic (inherited antisense) and the parent class is the aggregation (part) of the third class (see Figure 7). This three types of patterns can now delete the middle class to simplify and create a relationship from the first class to the third class (one of the examples). The following RA model discusses these rules and how they must apply them to produce effective results. Figure 7 shows the RA refining step of payment in our low-level design view (Fig. 5) to the consumer relationship case. After the application of two rules (are rule 4 and rule 17), we get a simplified mode with two classes and their dependencies. If this can also be processed for other classes and mode [[4]] discussed in the mapping section, we can automatically generate higher levels of class diagrams (Figure 8). This abstract view produced can now be compared directly to the original higher level class diagram we described in Figure 4. In this way, the use of the mode can be converted to express information in a very similar other view. The comparison view is now simply used in the form of some graphical comparison algorithms (you can also see the differentiated differentiated above). Figure 8 also shows possible inconsistencies. For example, from the payment to the gathering of the order, the inventory system does not use the network component for the call to the Oracle database, and some links are different (for example, using the associated link rather than dependent link). These mismatches can be easily identified after transform (abstraction). It must be noted that abstraction is not completely automated. Although pattern helps to determine mapping and transformations between certain modeling information, they cannot fully automate the process. Therefore, some manual assistance is required to export Fig. 8. Moreover, the RA tool currently only deals with simple three-class modes as discussed in Figure 7 and cannot process more advanced design patterns discussed in Figure 6. Thus, due to the operation, the abstract design mode (e.g., agent) is done by manual. However, once more complex design mode concepts are embodied in RA, this abstraction can be automatic.
In this regard, the design mode needs to be discussed in accordance with their input (source) and purpose and their access points. Use rule 17
Use rule 4
Figure 7 shows the pattern of Rose / Architect
Current, another RA disadvantage is that it can only be used for abstract class diagram information. Although the technology can also be extended to abstract other types of views, it is still helpless when we want to compare the modeling elements of different types of views. This situation will be discussed in the next section. Mode and transformation
In view of the case of abstract processing simplified views, transformation processing shares the modeling information between different types of views. For example, in the above discussion, we have widely used classes and class diagrams that express information in structured form. Since the structure view is usually insufficient in terms of system behavior, the behavior view is, for example, the sequence diagram is used to fill this gap. For example, consider the constraints of the architecture hierarchy mode in Table 1 (together with the constraints of the high-level design view). There is no behavior of all layered architectures. A hierarchical architecture is not only limited to which layers allow mutual conversation, which also limits the direction of interaction. Although structural block diagrams such as class diagrams can describe certain directional dependencies, it may ignore other aspects.
Figure 8 A class diagram of using rose / architect and design pattern
Figure 9 Sequence diagram for new orders (corresponding to low level block diagram)
Figure 9 shows a more complex behavior case. A UML sequence diagram is used here to describe the possible scenes of creating a new consumer order. After some user input is verified, it verifies if the consumer exists. If there is no existence, the new consumer is created. After that, create a new order. This scenario describes a low-level design view (Figure 5). Thus, we can use the call dependencies between the automatic inspection class (or object) of Figure 5, without revealing mismatches in this case. This sequence diagram also conforms to our architecture because all hierarchical constraints are observed (both automatically check). Since the behavioral view of the component has a high degree of unity, we can use our pattern knowledge refining behavior again. Figure 9 uses the order warehouse agent, the network, and the Oracle database, and the classes we discovered in the mapping. As found in [Buschman et al 1996], Figure 10 shows the definition of the proxy mode structure and behavior. Effect, behavior definition is a conversion of the structure. Thus, we can use this knowledge to verify the correctness of Figure 9. Because the abstract levels between the agent definition between Figure 10 and the abstraction levels between the agent instantiation in Figure 9 are different, we need to abstract Figure 9. Basically, we can use Rose / Architect concept to abstract networks from the merged network to the order warehouse agent (this is a part of the network). Thereafter, the direct comparison between definitions and instantiation is possible. There is no mismatch in this case.
Figure 10 Structure and behavior of the agent mode
Due to the limitations of the space, we cannot discuss this process more details. Please refer to [EgyED 1999a] and [EgyED 1999B]. relevant job
The lack of view integration is not new discovery. Instead, many model descriptions are discussed to maintain the consistent needs. Sometimes, the processing model provides additional approaches for improving the integrity of the architecture concept. For example, a case study on using WinWin Spiral Model [Boehm et al 1998] is recommended to use after LCO (Life-Cycle Objectives, Lifecycle Target) and LCA (Life-Cycle Architecture, Lifecycle Architecture) Architecture Review Boards [AT & T 1993] to test and confirm the integrity of analysis and design. A similar point of view can be seen in other research work: L [Sage-Lynch 1998] discusses different aspects of integration (enterprise scope). They repeatedly emphasized the "architecture in system integration." They express demand for three main views: business views, system processes, management views, and technology implementation views - and they emphasize guarantee between these views consistency. l [Rechtin 1991] Very strongly requires and interface definitions to emphasize the effectiveness and consistency of demand. He further promotes the need for problem detection and diagnosis. L [IEEE 1998] Architecture Assessment Speech. "The intent of the assessment is to determine the quality of the architecture, and the quality of the associated architecture. They further stated that the evaluation criterion requirements that determined which architecture can be verified. L [NuseIBeh 1995] Write "Inconsiscies is a complex part of a complex, increasing software development process", and "incremental software system development includes detection and processing of inconsistency". l [Perry0Wolf 1992] I have long learned the importance of the software architecture, and they will state it as one of the four main benefits of the architecture, which is "the basis for dependency and consistent analysis". l [Shaw-Garlan 1996] Very exciting architecture, as "the essential folklore of system design, rarely consistent and accuracy". He further states that "software architecture found its foundation in block diagram and popular prose. Unfortunately, block diagrams and descriptions are highly unity." These and more references, talk to integrated needs (or miss) . However, they usually discuss the contained activities in detail (also some exceptions). Sometimes these jobs are not particularly loved to integrate approximation. On the other hand, sometimes proposed technologies often intend to make people communicate with each other. For example, the architecture review board [AT & T 1993] or inspection process [NASA 1993] is mainly used to make most people work together so they can share information. These techniques may follow the defined procedures (for example, check orders) and possible results, but in fact, determining and solving the activities of the defects still have to be done by manual, and there is not much automatic assistance. in conclusion
This work discusses the reason why the architecture mismatch in the UML view and how integrated technologies can be applied to identify and solve them in a more automated manner. We express our work with the context of unified modeling language (UML) and its view (block diagram), and use an example to guide the main phase of the view. The view integrated framework expressed in this paper is not limited to UML. It can also be applied to other models and views (such as architectural description languages). This work further introduces the mode use in the integrity of the analysis software system model concept. Since the mode is intellirable and documentated, in terms of structure and behavior, we can frequently use these knowledge for view analysis. According to this, we explain the knowledge about the mode can be used for mapping views (cross-references related to modeling information), or from one view to another. Later, we explained the abstract (Rose / Architect) and transform technology. Although the integration framework creation is to support automatic view analysis, manual intervention is often necessary. Since this article is only concentrated in the model, other integration techniques have not discussed (you can also see [EgyED 1999B]). We will publish the contents: l Discovery (or develop) integrated technology L to process the multi-view range to increase more accuracy to UML clarification. l Discussion on the mismatch resolution of automated support (not just without mismatch automatic determination), no matter these problems, we have achieved extensive progress in this field and we feel the benefits of integrated technology, such as discuss this article. It is unlimited. We have shown that mismatch authentication is possible (at least part of), since the computer is undoubtedly more efficient in the comparison view, this means essentially saving artificial labor. Another benefit of our approximation is that mismatch can be determined when they are created. When new data is added to the model, the tool can verify them. references
Ø AT & T (1993) "Best Trend Practice: Software Architecture Confirmation," AT & T, MURRAY HILL, NJ. Ø EgyED, A. (1999) "UML Architecture View Integration," Submit to ESEC / FSE'99, HTTP : //sunset.usc.edu/techrpts/papers/usccse99-511/usccse99-511.pdf. Ø EgyED, A. (1999B) "Integrated Architecture View in UML," Quality Report, Technical Report, Software Engineering Center University of South California, USC-CSE-99-514, http://sunset.usc.edu/techrpts/papers/usccse99-514/USCCSE99-514.PDF. Ø Egyed, A. And Kruchten, P. (1999) "Rose / Designer: Visual Software System Tool", the 32nd System Science Conference Annual Report Ø Booch, G., Jacobson, I., and Rumbaugh, J. (1997) "for the unified construction of object-oriented development Memory, "Collection, Version 1.0, Rui Ge Software Ø Buschman, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996) mode system: mode-oriented software system , "Wiley] Ø Boehm, B., Egyed, A., Kwan, J., And Madachy, R. (1998)," Using Winwin Spiral Model: Case Study, "IEEE Computer, July, PP. 33-44. Ø Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1994) "Design mode: Object-oriented software elements:" Addison-Wesley. Ø NASA (1993) "official software inspection process Standard, "NASA-STD-2202-93. Ø NUSEIBEH, B. (1995)" Computer-assisted non - consistency management in software development, "Technical Report DOC 95/4, Calculation Department, Imperial University, London SW7 2BZ. ØRechtin, E. (1991) "System System, Create and establish complex system," Prentice Hall, Englewood Cliffs, NJ. Ø PERRY, DE AND WOLF, Al (1992) "Software Architecture Research Foundation," ACM Sigsoft Software Engineering Notes , October, Ø SAGE, Andrew P., Lynch, Charles L. (1998) "System Integration and System Construction: Principle Overview, Practice and Vision," System Engineering, International Systems Engineering Conference Journal, Wiley Publishers, Volume 1, Page 3, 176-226. Ø Shaw, M. And Garlan, D. (1996) "Software Architecture: Perspective of Forming Principle," Prentice Hall. Ø SIEGFRIED, S. (1996) "Understanding the Software Engineering," IEEE Press "," IEEE PRESS. [1] In the case of [Bushman et al 1996], we can use the terminology mode and style.
[2] Template hidden source template and class dollar for commonly used
[3] Provide a proxy restriction to other objects to its access [Gamma et al 1994]
[4] Note: We can simplify lower level design patterns with high-level agents
