Reference Architecture Representation Environment (RARE)
A Tool to Support Object-Oriented Software Architecture
Derivation and Evaluation
K. S. Barber and T. Graser
The Laboratory for Intelligent Processes and Systems
Electrical and Computer Engineering
The University of Texas at Austin
Austin, TX 78712
https://www.doczj.com/doc/1313317855.html,
barber@https://www.doczj.com/doc/1313317855.html,
phone: (512) 471-6152
fax: (512) 471-3316
Abstract
Software architectures have received considerable attention in both research and practice for representing system stakeholder concerns during the software development process. While a number of architecture representations have been proposed to facilitate analysis at different levels of abstraction, tool support for deriving and evaluating these architectures is only just beginning to appear. This paper describes a research tool under development, Reference Architecture Representation Environment (RARE), designed to systematically guide the architect through derivation by applying object-oriented and software architecture heuristics associated with quality goals and evaluate the resulting architecture based on relevant static metrics. As a member of the Systems Engineering Process Activities (SEPA) tool suite, RARE helps address a number of challenges typically faced during the derivation process, including (1) developing an architecture that reflects quality goals identified by the architect (e.g., reusability, extensibility, comprehensibility, performance), (2) capturing and sharing architect expertise and rationale for a particular architecture, and (3) interpreting domain functionality and data requirements collected from many different stakeholder perspectives. The product is both a high-level software architecture designed to capture domain functionality and data requirements and a derivation log intended to document the derivation process and the architect’s rationale.
Keywords
Information Systems Development, Management Information Systems, Software Architecture Derivation, Software Architecture Evaluation, Object-Oriented Analysis, Domain-Specific Software Architectures
1 Introduction1
Software Architectures have been used to represent a variety of concerns in the software development process, including requirements, domain-specific knowledge, implementation structure, and component connectivity [1] [2]. These various concerns can be expressed in a software architecture as abstract, high-level views of a software system. While a significant amount of research has focused on representing these architectures and incorporating architectural analysis into the development cycle, research has only recently emphasized formalizing the derivation and concurrent evaluation of these architectures [3]. The objective 1 This research was supported in part by the Texas Higher Education Coordinating Board Advanced Technology Program (ATP #003658-188-1999) and the Defense Advanced Research Projects Agency (501325 and N66001-99-1-8903).
of a formal derivation and analysis process is to generate an architecture capable of fulfilling a set of quality attributes (goals), such as reusability, reliability, performance, and comprehensibility. As with other software development activities where managing multiple concerns is an issue, software architecture derivation is an appropriate candidate for tool support.
One of the fundamental reasons why improving the effectiveness of software engineering processes presents such a challenge is that software development activities (e.g., requirements capture, domain analysis, system design) are not always guided by hard and fast rules. This fuzziness is particularly evident during class derivation in object-oriented analysis, and similarly, architecture class derivation. Given an identical set of domain functionality, data, and timing requirements (i.e., domain requirements), it is highly probable that two architects will arrive at a completely different set of architecture classes. While this can be attributed to a number of reasons, this paper focuses on three considerations. First, different architects may deem different quality goals as important, and the architecture may take on different forms depending upon which goals are emphasized. One architect may have the opinion that reusability should strongly influence class definition, while another may place greater emphasis on the comprehensibility of the overall class model. A second significant factor dictating architecture derivation is the expertise and skill level of the architect. A more experienced architect will be able to draw upon successes and failures from prior projects, while the inexperienced architect is forced to work from gut feel and a weak understanding of the literature. Still another factor that may explain variations between architectures is an architect’s interpretation of domain requirements. Whether working from a single functional requirements document or a series of software modeling diagrams (e.g., task decompositions, data flow diagrams, entity-relationship diagrams, organizational charts), there is always the possibility two architects will interpret domain functionality and data differently. While no requirements analysis technique can guarantee to eliminate multiple interpretations, they are often a symptom of incomplete or inconsistent requirements. Reference Architecture Representation Environment (RARE), a process and supporting tool component of the Systems Engineering Process Activities (SEPA) tool suite under research at the University of Texas at Austin, seeks to systematically guide the architect in deriving a reference architecture designed to capture domain requirements (functionality, data, and timing). As part of comprehensive support for architecture derivation, the RARE approach seeks to address the considerations discussed above.
?=Different quality goals emphasized by different architects: RARE incorporates a knowledge base of derivation heuristics associated with common quality goals, such as reusability, extensibility, comprehensibility, and performance. The architect selects and prioritizes goals for a particular architecture, and RARE adheres to these priorities assigned when suggesting architecture refinements. A significant aspect of RARE research is building, testing, and fine tuning this knowledge base.
?=Varying levels of expertise among architects: Via the RARE knowledge base, RARE research captures the expertise of skilled architects and helps non-experienced architects apply this expertise. Knowledge base heuristics are derived from (1) object-oriented and software architecture literature, (2) project objectives from a variety of domains to which RARE is being applied2, and (3) extensive fine tuning and empirical analysis. In addition to providing a set of goals and heuristics generalized over many projects, RARE logs every refinement and captures associated rationale from the architect throughout the architecture derivation process. Thus, the decisions and expertise of the architect are captured for a specific project.
?=Multiple interpretations of domain functionality and data requirements: As an activity in the SEPA process, the RARE tool and architecture derivation process has the benefit of a consistent computational domain model captured and refined during upstream SEPA activities [4]. A key feature of the SEPA methodology is its emphasis on the separation of concerns, including explicitly separating different types of requirements and isolating their analysis and refinement.
2 The Systems Engineering Process Activities (SEPA) is being applied in a number of domains, including cancer treatment protocol development, emergency incident response, and joint military forces command and control [4][5][6].
The following section introduces the SEPA Domain Reference Architecture (DRA), one in a series of separate but interrelated architectures used in the SEPA methodology. Having described the DRA, Section
3 discusses the derivation approach used in RARE and outlines the steps performed for each derivation iteration. This discussion is interleaved with illustrations of selected screens from the RARE tool. Section
4 discusses related work, and Section
5 offers concluding remarks and comments on future work.
2 Systems Engineering Process Activities Domain
Reference Architecture
To support the representation of multiple types of requirements, encourage reuse, and promote separation
of concerns, The Systems Engineering Process Activities (SEPA) methodology suggests a comprehensive approach to represent yet separate different types of requirements and the architectures used to capture those requirements. These classes of requirements include (i) domain requirements (business process/functionality, data, and timing), (ii) application requirements (e.g., application look-and-feel, runtime performance requirements), and (iii) site requirements (e.g., available site hardware platforms, middleware and communications software). The Reference Architecture captures those requirements inherent to the domain that dictate WHAT processes, data and timing are required for operation but not HOW the system should be implemented or which technology should be deployed to deliver those domain requirements. The application and site requirements dictate design and implementation related concerns and drive the specification of Application and Implementation Architectures, respectively.
This paper focuses on the derivation of the Domain Reference Architecture (DRA), an architecture designed to facilitate the analysis of domain requirements. The source of requirements represented in the DRA is the SEPA Domain Model (DM), a computational model which represents the requirements gathered from a variety of system stakeholders and synthesized into a series of graphical and textual models (e.g., data flow diagrams, task decompositions, concept maps, entity relationship diagrams).3 The DRA is derived by allocating DM functionality and data into architectural classes. These classes will become the blueprint that guides the development effort in terms of architectural structure as well as those functional, data, and timing requirements to be satisfied. Since it is likely classes will be instantiated by different implementation solutions each time the blueprint is reused for a new system development effort (e.g., computer programs, hardware devices, personnel), the DRA representation is highly implementation independent. Architecture evaluation at this level employs static metrics relevant to selected goals (e.g., reusability, maintainability, comprehensibility) to measure architectural content and structure (e.g., coupling between classes, size of classes, completeness of architecture as a percentage of DM content).
Figure 1 - Domain Reference Architecture Class Representation
The DRA is a collection of Domain Reference Architecture Classes (DRACs) that declare “what” domain functionality, data, and timing an instantiation of the class must satisfy without specifying a particular
3 For a more complete description of the SEPA process, the reader is referred to [4].
implementation. Each DRAC is assigned responsibility for some portion of domain functionality and data. This assignment and the relationships between DRACs are represented in three sub-models (Figure 1): the Declarative Model (D-M) defines the data and event attributes and services that should be offered by an instance of the DRAC; the Behavioral Model (B-M) describes the behavior expected from an instance of the DRAC through a high-level state chart; and the Integration Model (I-M) defines the constraints and dependencies between DRAC instances resulting from the distribution of dependent functions across DRACs. These dependencies are based on input and output of data and events as well as the clustering of classes into subsystems to represent domain functionality typically co-located. All elements of the DRAC model are directly traceable to elements of the Domain Model. Given such a representation of domain requirements and a set of known applications associated with each class, stakeholders can answer questions regarding the specifications for intended applications as well as the suitability of existing applications in satisfying domain functionality.
The remainder of this paper focuses on the approach used in RARE to guide the architect in deriving a Domain Reference Architecture that satisfies quality goals and capture the architect’s rationale as derivation proceeds.
3 Domain Reference Architecture Derivation in RARE DRA derivation is an iterative process, where successive iterations represent increasing coverage of domain information and greater refinement of the DRA based on architectural quality goals. Since goals such as maintainability, reusability, extensibility, performance, comprehensibility, and reliability describe overall architectural qualities, their presence is not easily verified by direct observation. On the other hand, low-level architecture characteristics (e.g., class size, depth of inheritance tree, class coupling) that are easily measured do not always have a direct relationship to the high-level goals. In fact, there is often a many-to-many relationship between the high-level qualities and the low-level characteristics, such that no single metric provides conclusive evidence that a quality goal has been satisfied.
By correlating high-level goals and low-level metrics through heuristics and strategies, RARE attempts to bridge the gap between high-level qualities and low-level characteristics. Each of these elements can be described as follows:
?=Heuristic: A "rule of thumb" compiled from expert experience on past projects which assists the architect in making rational decisions in defining DRACs. For example, a well-known object-oriented heuristic recommends reducing coupling among classes to encourage reuse [7]. A goal is typically associated with multiple heuristics.
?=Strategy: An architecture transformation procedure (sequence of actions) used to apply a given heuristic. Following the "reduce coupling" example, a strategy might explicitly state, "move service S1 from DRAC D1 to DRAC D2" to eliminate the need to exchange data between DRACs D1 and D2. More than one strategy may contribute to a heuristic, and a strategy may apply to more than one heuristic.
?=Metric: A measurement of a particular characteristic of the architecture which provides an indication as to whether the architect adhered to a given heuristic. Continuing with the previous example, the DRAC inheritance hierarchy and/or number of data/event dependencies passed between DRACs (e.g., one service in one DRAC required as input data held by another DRAC) would provide some evidence as to the degree of coupling in the RA. Typically, multiple metrics are used in combination to evaluate an architecture in the context of a heuristic and its parent goal.
Figure 2 - Sample Set of Goals, Heuristics, and Strategies from the RARE Knowledge Base
Figure 2 illustrates a sample set of goals, heuristics, and strategies represented in the RARE knowledge base. The quality goals depicted have been prioritized based on the architect’s understanding of the needs of the particular architecture: (1) “Reusability,” (2) “Implementation Performance and Scalability,” (3) “Usability and Comprehensibility,” and (4) “Maintainability and Extensibility.” Examining the “Reusability” goal more closely, four contributing heuristics have been defined, each associated with corresponding strategies. Metrics applicable to the “Reduce class coupling...” heuristic may include familiar object-oriented metrics such as “Coupling Between Objects” and “Degree of Cohesion” [8]. Since strategies and metrics may apply to more than one heuristic under more than one goal, the “Redistribute services...” strategy is an appropriate technique for both reducing coupling under the “Reduce class coupling...” heuristic and reducing message passing under the “Reduce I/O performance bottlenecks…” heuristic. Strategies are triggered by relevant preconditions detected in the reference architecture, including
conditions measured by related metrics. For example, “Redistribute services...” under the “Reduce class coupling…” heuristic could be triggered, in part, by an unsatisfactory value for metric “Coupling Between Objects.”
Figure 3 - DRA Derivation among SEPA Activities
The RARE architecture derivation process is positioned among SEPA activities as shown in Figure 3. As output from requirements acquisition, modeling, and refinement activities, the SEPA Domain Model provides RARE with a computational representation of domain functionality, data, and timing. To accurately reflect domain requirements, the SEPA methodology encourages acquiring requirements from multiple stakeholder viewpoints. SEPA requirements refinement activities include unifying these viewpoints into a single consistent picture of domain requirements, the Domain Model. RARE then restructures the information in the Domain Model by defining a collection of object-oriented classes (DRACs discussed in Section 2) to which domain functionality and data are assigned. Thus, the derivation process boils down to two essential questions: (1) what information must be extracted from the Domain Model (i.e., what functions, data concepts, events, resources, etc.) and (2) where this information should be placed (i.e., in what classes). The resulting classes and their relationships provide a specification for developers to implement new applications or identify existing solutions to satisfy domain requirements. Subsequent SEPA tools provide assistance in creating system designs that employ these solutions.
Figure 4 outlines the steps associated with the each iteration of the architecture derivation process in RARE. These steps are described in the following subsections.
Figure 4 - Process Flow for Reference Architecture Derivation
1. Establish Goals: The architect identifies the quality goals targeted for the architecture. Goals are
typically chosen in accordance with characteristics of the domain (e.g., if applications must be modified often, “extensibility” may be an emphasis) and unique requirements of the development effort.
2. Prioritize Goals: The goals selected determine which heuristics guide the derivation process and
which metrics will be used to evaluate the architecture. It is possible, however, that two or more goals may be in conflict with regard to the “derivation direction” of the RA, based their associated strategies and heuristics. For example, comprehensibility might suggest collecting classes to reduce the total number of classes needed to be understood by the reader, while maintainability might recommend a contrary approach, dividing class responsibility whenever possible. Assigned goal priorities assist conflict resolution between strategies in the event that different strategies lead the derivation in opposite directions. Figure 5 depicts the RARE screen used to establish and prioritize goals. The goals selected are Increase Class Reusability, Increase Class Extensibility, Enhance Implementation Performance, and Increase Model Comprehensibility. Each goal is associated with relevant heuristics
and respective strategies and metrics. For example, Increase Class Reusability suggests one heuristic, Reduce DRAC Coupling.
Figure 5 - RARE Goal Selection Screen
3. Prune Metrics and Strategies under Selected Goals: A goal stored in the RARE knowledge base may
be associated with many heuristics that in turn refer to any number of strategies and metrics. The architect has the option of pruning heuristics, strategies, and metrics from the goals selected for the derivation iteration.
4. Determine the Acceptable Ranges for Each Metric: Each metric identified under a goal is associated
with an acceptable value range. Where a metric value falls in this range helps determine (1) how well the architecture meets selected goals and (2) what subsequent refinements should be applied to better satisfy selected goals.
5. Identify Applicable Strategies for This Iteration: RARE determines which strategies to “fire” for a
particular iteration. Each strategy has an associated precondition that defines under what conditions the strategy applies. Conditions can involve the current state of the architecture (e.g., a strategy which runs only during the initial iteration when the architecture is empty) and characteristics of the Domain Model (e.g., certain data concepts are present which contain sub-concepts).
6. Resolve Strategy Conflicts: The applicable strategies identified in Step 5 may be totally compatible.
On the other hand, if analysis determines that the anticipated characteristics of the resulting Reference Architecture contradict, it becomes necessary to resolve strategy conflicts. Resolution may be as simple as ordering the sequence of strategy execution based on goal priorities, or it may involve modifying or removing one or more strategies. A collection of documented rules advise the architect on how to resolve conflicts given certain situations.
7. Apply Strategies: RARE modifies the current Reference Architecture by applying the strategies from
Step 6. Each strategy results in one or more “actions” which can be reviewed by the architect as they are applied. All actions are recorded in the derivation log. Figure 6 shows the RARE strategy selection window, where all pending strategies are displayed for review by the architect.
Figure 6 - RARE Pending Strategy Verification Screen
8. Calculate Metrics: Calculate the values for all metrics under selected goals. Figure 7 depicts the
RARE metric calculation window. Based on the allowable metric deviations (set in Step 4), RARE indicates whether metrics are in or out of range. These indicators are rolled up to corresponding goals and help the architect determine how well goals have been satisfied (Step 9 below). The red, yellow, and green indicators signify that the corresponding metric or goal is out of range, near acceptable, or acceptable, respectively.
Figure 7 - RARE Metric and Goal Index Calculation Screen
9. Determine if Goals Have Been Satisfied: RARE combines metric values under each goal into a
“quality index” for that goal. The weighted average quality index shown in Figure 7 is calculated as a weighted average across all metrics under a goal, yielding a number from 0-10, where 10 represents maximum satisfaction.
10. Determine the Next Action: After reviewing the metrics and goal indices calculated in the previous
steps, the architect selects one of the following actions:
?=End the derivation process if the current state of the Reference Architecture is satisfactory based on goal indices and observation.
?=Run the next iteration using the new architecture as a starting point, if the architecture does not yet meet goals but is closer to those goals than the architecture from the previous iteration.
?=Readjust goals before proceeding, if the new architecture is further from meeting selected goals than the architecture from the previous iteration. Readjusting goals can entail
?=eliminating one or more selected goals (Step 1),
?=rearranging goal priorities (Step 2),
?=pruning strategies and metrics in a different manner (Step 3), and/or
?=adjusting the manner in which strategies are merged (Step 6).
Figure 8 shows the RARE message log window that displays all messages generated from actions executed during a single derivation iteration. This window provides the architect with the option of “committing” (marking as satisfactory) the results of the current iteration after reviewing the goal and metric values. The activity log shown becomes one portion of the architect’s rationale retained.
Figure 8 - RARE Derivation Log Display Screen
The steps described above represent a single iteration. Typically, a number of iterations are run before a satisfactory reference architecture is reached (partly dependent on the size of the domain model). The graph in Figure 9 depicts a sample derivation run, showing the goal evaluation indices over 20 iterations for four goals, (1) “Reusability,” (2) “Maintainability and Extensibility,” (3) “Implementation Performance and
Scalability,” and (4) “Usability and Comprehensibility.” It is evident that the highest priority goal, “Reusability,” received the most emphasis throughout the derivation process.
Figure 9 - RARE Derivation based on Four Goals
4 Related Work
As the architecture discipline has matured, a variety of Architectural Description Languages (ADLs) have been introduced, supporting different levels of abstraction and analysis [9]. As with the ADLs designed to capture low-level component details, SEPA’s Implementation Architecture contains a broad range of implementation-related information (e.g., component installation specifications, component interconnections, architectural styles) and is capable of supporting dynamic analysis of architectural qualities through simulation. On the other hand, the DRA is considerably more abstract, as it is intended to capture domain requirements independent of specific implementation details. The SEPA Reference Architecture compares similarly with the Domain Specific Software Architectures (DSSA) approach [10, 11]. As with DSSA, SEPA emphasizes the development of a reusable reference architecture by separating information related to the problem domain from that concerned with the solution space. SEPA extends the DSSA approach through enhanced representations of problem space and solution space architectures and a formal process and tool suite to support derivation, analysis, and tradeoff evaluation at each step.
While systematic architectural derivation has received little attention in the past, recent research has begun to focus on this issue starting from a requirements specification with ongoing evaluation against quality attributes. A comprehensive approach to architecture derivation and analysis is discussed in [3], and a corresponding case study is presented in [12]. This research suggests the need for many of the features designed into the SEPA approach, including distinct recognition of domain-related functional requirements and quality requirements (architectural properties), emphasis on a wide range of quality requirements, quantitative assessment, architectural transformation approaches, and experience-based reasoning. As a member of the overall SEPA methodology and tool suite, RARE is able to offer a systematic approach to initial architectural derivation from a requirements “specification,” using the unified, verified SEPA Domain Model as the source for domain requirements. In addition, RARE extends this research by providing tool features to manage conflicts at different levels. RARE research has identified static metrics from a number of sources, although many do not apply since they focus on implementation-level concerns. Sources include architectural analysis efforts such as [13] and more traditional object-oriented analysis metrics [8] [14] and heuristics [7].
The research community has introduced a number of tools to complement software architecture research efforts. A large share of these tools focus on architectural representation, usually in the context of specific ADLs [15]. Tools have also been developed to support scenario-based analysis [16].
In addition to language and evaluation support, tools are also available to assist architecture derivation, many of which are rooted in research into object-oriented analysis and design. In [17], Robbins et al discuss Argo, a tool that provides suggestions to the architect during derivation based on “critics” that continually monitor the architecture regarding qualities such as completeness, correctness, optimization, and evolvability. Metrics based analysis and evolution of object-oriented designs can be found in [18] [19]. In [18] the authors discuss an approach for metric data interpretation to generate more meaningful feedback information, employing the concept of “alarmers” that trigger when metric values trigger certain conditions. In [19], the authors describe a tool that integrates heuristics, metrics, and transformation rules to improve object-oriented designs. RARE combines features from these derivation tools by incorporating architecture transformation based on static metrics concerning object-oriented and architectural principles. RARE has the added benefit of drawing domain requirements from the unified Domain Model, allowing RARE to enhance evaluation to include such concerns as completeness.
5 Conclusion
While software architectures have demonstrated to be an effective means for capturing stakeholder requirements and prescribing software system structure, the derivation of software architectures starting from requirements elicitation is a significant challenge. This paper presents a process and supporting tool, Reference Architecture Representation Environment (RARE), designed to guide the software architect in deriving a high-level reference architecture capturing domain requirements (e.g, functionality, data, timing). Many of the challenges encountered during architecture derivation are similar to those associated with class derivation during object-oriented analysis. Most notably, there is no specific formula to arrive at the “right” set of classes – architects may apply different rationale to arrive at completely different class arrangements. Differences in architect decisions may be the result of (1) emphasis on a different set of quality goals (e.g., reusability over extensibility vs. extensibility over reusability), (2) expertise of the architect, and (3) different interpretations of domain functional and data requirements acquired from domain experts. To avoid coercing a particular architecture approach, RARE does not dictate a set of architecture classes but systematically suggests strategies associated with object-oriented and architecture heuristics to help guide the architect in meeting selected quality goals. A quantitative evaluation of goal satisfaction is achieved through the use of acceptable ranges for associated metrics. Quality goals and associated heuristics commonly emphasized in research and practice are defined in the RARE knowledge base, thereby bottling the expertise of experienced architects and allowing less experienced architects to make full use of their knowledge. RARE also records the architect’s decisions and rationale by logging all transformations to the architecture and their justifications as derivation proceeds.
As an integral activity of the System Engineering Process Activities (SEPA) methodology and tool suite being developed at the University of Texas at Austin, RARE benefits from upstream processes designed to aid requirements capture and analysis. The product of this effort is a single, consistent domain model that unifies the perspectives of multiple stakeholders. These upstream processes encourage the resolution of ambiguity, inconsistency, and incompleteness, thereby reducing the risk of multiple interpretations during architecture derivation.
As SEPA architecture research and RARE development proceed, the RARE knowledge base continues to be extended and refined based on research and experimentation. Particular emphasis is being placed on defining the criteria for selecting robust metrics that represent accurate indicators of high-level quality goals in any domain. Initial experiments conducted using requirements from actual domains have exhibited anticipated tradeoffs between goals and heuristics. As experimentation continues, various conflict management approaches are being tested and results from these tests are helping to fine tune the RARE knowledge base.
References
[1] W. Tracz, "An Outline for a Domain-Specific Software Architecture Engineering Process," presented
at Fourth Annual Workshop on Software Reuse, Reston, VA, 1991.
[2] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice. Reading, Mass.: Addison
Wesley, 1998.
[3] J. Bosch and P. Molin, "Software Architecture Design: Evaluation and Transformation," presented at
Engineering of Computer-Based Systems (EBCS), IEEE Conference and Workshop on, 1999.
[4] K. S. Barber, T. J. Graser, P. S. Grisham, and S. R. Jernigan, "Requirements Evolution and Reuse
Using the Systems Engineering Process Activities (SEPA)," Australian Journal of Information Systems (AJIS)- Special Issue on Requirements Engineering, vol. 7, pp. 75-97, 1999.
[5] K. S. Barber, T. J. Graser, and S. R. Jernigan, "Application of the SEPA Methodology and Tool Suite
to the National Cancer Institute," presented at Hawai'i International Conference on System Sciences, Maui, HI., 1999.
[6] Defense Advanced Research Projects Agency (DARPA), "JFACC Solicitation BAA99-18," 1999.
[7] A. J. Riel, Object-Oriented Design Heuristics. Reading, MA: Addison-Wesley, 1997.
[8] S. R. Chidamber and C. F. Kemerer, "A Metrics Suite for Object-Oriented Design," Software
Engineering, IEEE Transactions on, vol. 20, pp. 476-493, 1994.
[9] P. C. Clements, "A Survey of Architecture Description Languages," presented at Software
Specfication and Design, 8th International Workshop on, 1996.
[10] L. Coglianese, R. Smith, and W. Tracz, "DSSA Case Study: Navigation, Guidance, and Flight
Director Design and Development," presented at Computer-Aided Control System Design (CASD), IEEE Symposium on, 1992.
[11] C. Gacek, "Exploiting Domain Architectures in Software Reuse," presented at ACM SIGSOFT
Symposium on Software Reusability, Seattle, WA, 1995.
[12] P. Bengtsson and J. Bosch, "Haemo Dialysis Software Architecture Design Experiences," presented at
Software Engineering, International Conference on, 1999.
[13] S. Kalyanasundaram, K. Ponnambalam, A. Singh, B. J. Stacey, and R. Munikoti, "Metrics for
Software Architecture: A Case Study in the Telecommunications Domain," presented at Electrical and Computer Engineering, IEEE Canadian Conference on, 1998.
[14] L. H. Rosenberg and L. E. Hyatt, "Software Quality Metrics for Object-Oriented Environments,"
Crosstalk, vol. 10, 1997.
[15] N. Medvidovic and R. N. Taylor, "A Framework for Classifying and Comparing Architecture
Description Languages," presented at 5th ACM SIGSOFT Symposium on Foundations of Software Engineering, Zurich, Switzerland, 1997.
[16] R. Kazman, "Tool Support for Architecture Analysis and Design," presented at SIGSOFT Workshop,
1996.
[17] J. E. Robbins, D. M. Hilbert, and D. F. Redmiles, "Software Architecture Critics in Argo," presented
at Intelligent User Interfaces, International Conference on, 1998.
[18] P. Li-Thiao-Te, J. Kennedy, and J. Owens, "Mechanisms for Interpretation of OO Systems Design
Metrics," presented at Technology of Object-Oriented Languages (TOOLS), 1997.
[19] T. Grotehen and K. R. Dittrich, "The MeTHOOD Approach: Measures, Transformation Rules, and
Heuristics for Object-Oriented Design,", vol. 1999, 1997.
哈佛_论文引用格式! 1 A brief guide to the Harvard System The University of Greenwich as with all universities requires that students give credit to the authors of the evidence they use to support the arguments within their essays and other assignments. Most schools within the University require that students use the Harvard system of referencing citation. This is a guide to that system giving some useful examples to which you can refer when referencing yourself. Function A bibliographical reference should contain sufficient information for you or someone else to trace the information sources you have used. It indicates that you have considered appropriate authorities and evidence in your work It acknowledges the work of others in contributing to your work. The same set of rules and grammar colons and commas should be followed every time you cite a reference consistency. Note – you ought to follow the convention of referencing dictated by your school or tutor normally the Harvard system. The components of the Harvard system The Harvard system has two main components. Firstly there is the in-text reference. Fore each item of evidence that you use from an external source a book a journal article etc. there is an entry that includes the author?s family name and the year of the publication source that the information comes from. Note that
XXX 联系电话：#### 邮箱：globalxiaonizi@https://www.doczj.com/doc/1313317855.html, 家庭地址：******* 求职目标 银行业 教育背景 2005.9～2009.6 上海对外贸易学院法学（国际经济法方向）本科 主修课程：国际金融、基础会计、市场营销、国际贸易实务、国际经济法、国际贸易法 实习经历 2008.1～2008.2 中国银行上海正大广场支行见习柜员 ?负责本行开户企业对账单的整理及反馈，记录每天的晨会概要，协调柜台与大堂经理的沟通，接受客户关于存贷业务的咨询，录入信用卡申请资料等 ?积极学习个人理财业务知识，协助客户经理完成指定基金的销售业绩 2007.7～2007.8 联合证券有限责任公司长江西路营业部投资经理助理 ?指导客户开户流程，在投资经理的指导下学习大盘趋势的判断，以及优质股票的推荐 ?负责与潜在客户沟通，分享理财知识，在时机成熟的情况下把投资经理推荐给客户，以其更专业的知识完成客户营销，期间团队营销业绩为8户，个人直接参与5户 2006.7～2006.8 上海零点市场调查有限公司数据采集员 ?参加过3个大型项目，根据项目要求进行电话访问、拦截访问和定点访问，克服被拒绝的心理障碍，不断尝试新的方法与客户沟通，从而赢得客户的信任 ?认真完成问卷填写，及时追问客户真实意见，经督导回访，信息准确率达到95% 实践活动 2006.9～2008.6 上海对外贸易学院励勤人才服务公司市场部业务经理 ?积极联系校外企业，拓展学生的就业市场，并参与项目管理 ?累计为学生提供20个校外工作岗位（包括促销、翻译等）、联系过8家企业来我校做招聘会（包括民生银行、中银国际等）、提出建立学生人才库的构想并录入第一批名单2007.7～2007.8 2007世界特殊奥林匹克运动会志愿者 ?在豫园进行印有Q版刘翔、姚明形象T恤衫的义卖，用双语进行解说和吆喝 ?在三天的义卖中，团队业绩20件，个人直接贡献15件 2006.9～2007.6 英语俱乐部副社长 ?负责社团日常事务的布置协调，包括校外赞助商的邀请、品牌活动英语沙龙的组织和策划、学术讲座组织、校外拓展活动的联系（例如组织社员去人民公园练口语）等 ?使英语俱乐部从一个10+的社团扩充到50+，并整理出学术类社团活动举办活动的思路2006.3～2006.12 上海对外贸易学院学生创业中心管理服务中心市场部助理 ?搜集关于创业的各种比赛、成果、政策性文件等资料，积极参与中心市场战略的制定 ?邀请钱峰明先生参加第一次创业沙龙，并为市场部确定了工作方向 获奖情况 ?学术类：国家奖学金一等奖（1次，1人/学期）、校优秀学生奖学金三等奖（2次，专业前10%） 2006-2007学年度暑期实践先进个人、暑期实践征文二等奖（3人/学期） ?实践类：上海对外贸易学院励勤人才服务公司优秀业务经理（3人/学期，公司共30人） 2007-2008学年度勤工助学先进个人（1人/学期） 2007-2008学年度法学院体育标兵（1人/学期） 技能与培训 ?语言水平：中级口译证书英语六级525 ?计算机水平：上海市电脑中级证书熟练办公软件操作
References/Bibliography Harvard Style Based on Style manual for authors, editors and printers / revised by Snooks & Co. 2002 Quick guide - How to USE IT ?There are various ways of setting out references / bibliographies for an assignment. NOTE ?Before you write your list of references/bibliography check with your lecturer/tutor for the bibliographic style preferred by the Academic Department. ?The following are examples of one style previously known as the Harvard style based on AGPS style but now revised by Snooks & Co, 2002. The style is based on the author-date system for books, articles and “non-books”. ?Your bibliography should identify an item (e.g. book, journal article, cassette tape, film, or internet site) in sufficient detail so that others may identify it and consult it. ?Your bibliography should appear at the end of your essay/report with entries listed alphabetically. ?If you have used sources from the Internet, these should be listed in your bibliography. n FOR A BOOK The details required in order are: 1. name/s of author/s, editor/s, compiler/s or the institution responsible 2. year of publication 3. title of publication and subtitle if any (all titles must be underlined or italicised) 4. series title and individual volume if any 5. edition, if other than first 6. publisher 7. place of publication 8. page number(s) if applicable ? One author Berkman, RI 1994, Find it fast: how to uncover expert information on any subject, HarperPerennial, New York. Explanation of above citation ? Two or more authors Cengel, YA & Boles, MA 1994, Thermodynamics: an engineering approach, 2nd edn, McGraw Hill, London. Cheek, J, Doskatsch, I, Hill, P & Walsh, L 1995, Finding out: information literacy for the 21st century, MacMillan Education Australia, South Melbourne.
哈佛参考文献注明方法Referencing using the Harvard method 当你为申报学位而撰写文章、项目、作业、博士论文或硕士论文时，你需要经常参考读过的文献，以证明一个论点、说明一个要点、概括某一理论、报告资料或数据、或是证明你的推论。你必须通过列出参考信息的方式来说明你所参考的这些作品的出处。应该在行文中标注，在最后详细列出。重要的一点是，不可以陈述了其他人的材料或观点但不用列明参考信息的方式说明出处。若有这样的行为，便是抄袭，一旦发现，将按学院的不轨行为程序执行。出于以下的原因，提供参考信息是必要的： ●证明你对主题进行了研究，你的观点是基于已出版的材料而提出的。 ●使你的观点和论点充实； ●承认你采用的资料的出处，以及你的观点是由此发展而来； ●区别哪些观点是你自己的，哪些是别人的； ●让你的读者能找到你的观点的出处，能让他们自行研究这些材料。 哈佛参考文献注明方法的主要方面 哈佛参考文献注明方法（即“名称和日期”法）受到广泛应用。这一体系有两个方面。首先，在文章主体中借用他人作品之处，用括号标出引用标记。其二，在作品最后，以“参考文献”为标题按字母顺序列出文中引用的详细情况。本方法的目的在于确保你的文章正文不会因为有大量的目录信息而给读者造成干扰。引用标记含有最基本的信息，让读者在参考文献表中找到其位置。 请注意： 请各位学生注意，本校学术委员会要求所有学生了解哈佛参考文献注明体系，同时，学生也应注意，有些专业可使用不同的参考文献注明体系。如果有这种情况，教员将告知学生。如果有疑问，请询问教员。 在文中标注参考标记 参考标记通常是以下的形式： ◆用一对括号括起你所参考内容的作者的姓氏，其后是文献的出版年份。例如： 最初结论（Williams，1990）已遭到质疑（Reynolds，1994）。 ◆如果作者的名字随着行文出现了，则在括号中只添加年份。例如： 最初结论已遭到Reynolds（1995）和Roberts（1994）的质疑。 ◆若有两名作者，应同时出现在括号中。例如： 一份最近的研究（Williams及Reynolds，1996）推翻了先前的发现。 ◆若有3个或以上的作者，只列出第一个，其余人员用“等”表示。例如： 在最新的一份报告中，Smith等（1996）提供了另一种方案。
英国留学的小伙伴们都知道大部分学校都是使用Harvard（哈佛）Reference格式，今天hansedu就为你整理了最全的哈佛（Harvard）格式引用指南，接下去看吧！ 哈佛reference格式引用：参考List是创建工作时使用的所有资源的完整列表。这份清单包括作者的来源，出版日期，来源的标题等信息。哈佛参考Reference必须： 在文件末尾的单独一页上，作者按字母顺序排列，除非没有作者，则按照源标题排序，如果同一作者有多个作品按日期排序，如果作品在同一年，则标题按字母顺序排列，并在日期之后分配一个字母（a，b，c等）双重间隔：每行文本之间应该有一个完整的空白行，包含所有使用的文本引用的完整引用。 哈佛（Harvard）Reference格式引用：正文在使用来自另一件作品的引用或释义之后，必须包含正文引用。文本中的引用是在文本正文中的引用或释义，它们比完整的参考文献短得多。在参考文献列表中显示了文中引文的完整参考文献。在哈佛大学的引用中，正文引用包含作者或编辑的姓氏，出版年份和页码。 两三个作者：当引用两三位作者的来源时，请列出所有的姓氏； 四个或更多作者：在这种情况下，第一作者的姓氏应该用“et al”来表示； 没有作者：如果可能，请使用负责该职位的组织来代替作者。如果不是，请使用斜体标题：（引文指南，2017，pp。189-201） 同一作者的多件作品：如果引用同一年发行的一位作者的多部作品，那么在一年之后，作品会被分配一封信（a，b，c等）。这个分配是在参考清单中完成的，所以根据作者的姓氏和来源标题按字母顺序完成； 一个括号中引用多个作品：以正常方式列出文本内引用，但在不同引用之间使用分号； 在一个圆括号中引用不同版本的相同工作：包括作者的名字只有一次，后面跟着用分号隔开的所有适当的日期； 引用没有日期的：在这种情况下，只需简单说出“无日期”来代替年份：（Mitchell，无日期，第189页）。 如何引用不同的来源类型，除非明确规定，否则文本内引用使用上述规定；参考文献列表的参考文献在不同来源之间差异很大。
For art，for audiences： How do audiences hide configuring drama and building subjects’ habits Abstract: Bourdieu's practice theory has been widely accepted by more and more scholars and used in interpreting different social life and inequality phenomena. I also try to show my interpretation and application of the theory with peer scholars, especially discuss Bourdieu's "field, habits,capital" concepts with different specific performance in different countries of Italy and Germany. The structures and changes of human society can be fully reflected from people’s activities in arts(Bourdieu, 1984). In this paper, first take the British Shakespeare drama as an example, with the famous French cultural sociologist Bourdieu view: in the field of cultural production,there is also full of interests (although the interests often exist in the "upside down" economic interests manner) field struggling to explain. Then,elaborating the Bourdieu's view through different styles between Italian audiences and Germany audiences in theaters. The former Italian audiences have clear commercial logic thinking, the latter Germany audiences tend to sacred, pure, and aesthetic logic(Parker, 1994). This paper tries to seek the original differences by means of field cultural production framework of Bourdieu. The two countries’ drama audiences rating occupying is not same, this is closely related to audience's different Opera habits. We found that the two "anonymous" processes -- the audiences change identity from craftsmen to a free artist -- have greatly affected the drama production field grade distribution and exposure the main habit differences. Through the full text analysis, we find that commercial always pushes the evolution and development of drama art. The author further reflects a simple "commercial" art as an opposition to elegant culture, and presents there is no essential distinctions between them. It largely depend on the theory of Bourdieu segmentation plays results. In the era of consumption society, in the field of power for legitimate interest of ruling, class definition will be resisted and hegemony digested more and more, it will be followed by the boundary between elegance and vulgarity tends to blur. We can use Bourdieu's theory to describe the drama field production of these two countries, analysis the two national theaters, the power relations between the reproduction of cultural capital and cultural habits of different subjects, locate the different opera styles.
Diversity and global manager Introduction In today’s hyper-complex marketplace, every organization confronts the challenge on how to take the most advantage of the international trends to promote the overall efficiency and effect of businesses and maximize profitability. In fact, diversity has become an overwhelmingly important trend that attracts global attention, especially the human resource diversity. Generally speaking, it is a crucially important fact on organizational performance that weather the employees at all levels are well-trained, dedicated and loyal at their works. The first section demonstrates the key benefits and drawbacks of diversity, which are important for the decision-making of all companies. In the second section, the traits of global managers and their significance are discussed, which are professional background, profound management experiences, global insights and extraordinary leadership. In the last part, the link between diversity and global managers is analyzed from two aspects, and several recommendations are proposed accordingly. Diversity Diversity can be seen everywhere and the processes of most operations have a close relationship with diversity. From the very beginning, materials and manufacturing devices are outsourced from foreign regions to make commodity, advanced technology and inventions are bought to production in many ways, then, multinational workforce take their works in teams and solve problems together, in addition, attentions are paid to specific cultures to attract consumers in different countries and promotions are designed in accordance with habits of the target consumers of different nationalities. Diversity is so significant in resent days that any company can do nothing but come up with great ideas to manage diversity and take the most use of the trend. Diversity management emerges as a result of the rapid process of globalization, especially in the human resource sector such as age, religion, race, gender, culture and specialty,
Harvard referencing - Library quick guide Updated: 19 October 2012 In-text references- examples Single author Two or three authors Four or more authors Edited book More than one citation is provided in your sentence List all citations alphabetically, with a semi-colon (;) to separate them. Secondary citation This is when you refer to the work of one author cited by another. In the Reference List, refer to the author of the book, not the cited work. For instance, in the example below, Hosany & Martin 2012 would be in the Reference List.
Encyclopedia or dictionary These are only cited in the text, and are NOT included in the Reference List. Website documents Many electronic sources do not provide page numbers, unless they are in PDF format. If quoting or paraphrasing from a website that is NOT a PDF, then the in-text reference is either: ? a section heading (e.g. Better Health Channel 2012, Body image problems in Australian men section) ? a paragraph number (e.g. Better Health Channel 2012, para. 5). Reference List - examples Book – single author Carroll, AB 2012, Business & society: ethics, sustainability, and stakeholder management, 8th edn, South-Western/Cengage Learning, Mason, OH. Book – more than one author Note: List all authors, in order of appearance on the title page of the book, and use an ampersand (&) to separate the last two authors. Chalkley, T, Brown, A, Goodman, M, Cinque, T, Warren, B, Hobbs, M & Finn, M 2012, Communication, new media and everyday life, Oxford University Press, South Melbourne, Vic. Book – no author Style manual for authors, editors and printers 2002, 6th edn, John Wiley & Sons, Milton, Qld. Edited book Lubkin, IM & Larsen, PD (eds) 2013, Chronic illness: impact and interventions, 8th edn, Jones & Bartlett Learning, Burlington, MA. E-book from a database Benavides, EM 2012, Advanced engineering design: an integrated approach, Woodhead Publishing, Cambridge, UK, viewed 1 October 2012, Knovel database. Journal article Taylor, CM, Karunaratne, CV & Xie, N 2012, …Glycosides of hydroxyproline: some recent, unusual discoveries?, Glycobiology, vol. 22, no. 6, pp. 757-767. E-journal article from a database Hosany, S & Martin, D 2012, …Self-image congruence in consumer behavior?, Journal of Business Research, vol. 65, no. 5, pp. 685-691, viewed 27 May 2012, Elsevier SD Freedom Collection. Newspaper article from a database Carney, S 2012, …Gillard paying price for gamble on the numbers?, The Age, 26 May, viewed 29 May 2012, Factiva database. Website documents Better Health Channel 2012, Body image and diets, Better Health Channel, viewed 16 July 2012,
The University of Glamorgan Guide to Harvard Referencing e d e r , C . W . a n d N a k a s h i m a , M . (2006) ‘A d v a n c e d s t e i n c i v i l e n g i n e e r i n g ’, i n W u , C . H . (e d .) A d v a n c e d c r a s t r u c t u r e m a t e r i a l s : s c i e n c e , m e c h a n i s m s a n d p p l i c a t i o n s .N e t L i b r a r y [O n l i n e ]. A v a i l a b l e a t :t t p ://w w w .n e t l i b r a r y .c o m (A c c e s s e d : 20 J u l y 2010).
Information and data are available from various sources: from printed documents, and increasingly in electronic form: from the Internet, CD-ROM, film, television or radio. This guide sets out to provide examples of how to reference (cite) all sources of information using the Harvard Style. This is one of the most widely used systems based on the British Standard BS5605 (1990). When writing a piece of academic work you must always indicate in your text (reference) when you have used factual information, data, opinion, direct quotation, or have made a summary in your own words (paraphrased) from another source. References (also known as citations) serve to acknowledge the origins of the ideas and information used, provide support for the line of argument that you advance in your essay, and allow readers to trace your claims and check them for themselves. Where in your text you do this is the first component of the referencing system. The second component is the full details of all references you have used given in a list at the end of your assignment. Both components have to be included in any submitted piece of work. Introduction
Harvard Style Instructions Names: Author’s initials are used for their first name. If an author has more than one initial do not put any spaces between initials. Where a resource has multiple authors, all authors are listed by last name and then first initial separated by commas. Titles: Use sentence-like capitalization; only the first word and proper nouns. Include article or chapter titles in single quotation marks. Book and journal titles are fully capitalized. Dates: Use on the year of the publication. For viewed dates use the format date month year with no punctuation between. Journal or Magazine Article Pattern: [Author last name], [Author first initial] [Year], ‘[Title of article]’, [Journal Name], [Volume number], [issue number], pp. [page number start]-[end], [URL or Database Name], [EBSCO host], viewed [day month year]. Example: Maynard, W 1999 'Thoreau's House at Walden', Art Bulletin, 81, 2, pp. 303, Academic Search Premier, EBSCO host, viiewed 6 December 2010 Journal or Magazine Article w/No Author Pattern: ‘[Title of article]’ [Year], [Journal Name], [Volume number], [issue number], pp. [page number start]-end], [URL or Database Name], [EBSCO host], viewed [day month year]. Example: 'Royal Dogfight' 2004, People, 61, 1, p. 28, Academic Search Premier, EBSCO host, viewed 6 December 2010. Online Newspaper Article
哈佛文献标注方法（Harvard referencing system） 外国的老师很看重学生参考文献的引用，这个也是占分数的。很多欧洲和澳洲的大学一般要求哈佛大学文献参考系统。操作方法如下： 一、正文中 国外的文献引用方法和中文有很大的差异性，中文引用喜欢照搬别人的原话，但英文一般不这样，要自己归纳别人的观点，或者说别人做了什么研究，结论如何，总之最好不要原文照搬。 （一）文中不出现作者姓名 如果引用作者的某句话或者某个观点，就在这句话的末尾加（），（）内要标注作者的姓名和该文章出版的年份，如(Author2005)。反是有引用的，不管是从报纸上来的、还是书本、论文都要标。 如：Makingreference to published work appears to be characteristic ofwriting for aprofessional audience (Cormack1994). 如：(Jones1946;Smith 1948) 如：Recentresearch has found that the majority of……(Green et al 1995) Meeloun微信公众号 （二）文中出现作者姓名 如果正文中出现了作者的姓名，如xxx said/ concluded/ suggests….则在姓名后面加（），（）内只要标注年份即可，如（2005）。 如：Cormack(1994, p.32-33) statesthat 'whenwriting for a professional readership, writers invariably makereference toalready published works'. 如：Jones (1946)and Smith (1948)have both shown…… 如：Green et al(1995) found that themajority …… (三) 其他情况 如果一个作者同年出版了两本书，如2005年，要这样标：(Author 2005a) 或(Author2005b)；如果在一篇文章中引用多篇报纸文章，要表明这篇报纸文章的具体日期，如(TheGuardian, October 18, 2005)。 二、文末 在文末还要列个参考文献列表。英文不用像中文那样标1234等，只要按照正文中的引用次序依次排列就可以了。 （一）一个作者 1、引用书籍： 姓氏，名字的首个大写字母., 年份. 书本名称（斜体）.第几版. 出版社地点：出版社.页码. 如: Redman,P., 2006. Good essay writing: a social sciences guide.3rd ed. London: OpenUniversity in assoc. with Sage. 2、期刊 姓氏，名字的首个大写字母., 年份. 文章名.期刊名（斜体）,第几卷（Volume）第几期（number）,页码. Perry,C., 2001. What health care assistants know about cleanhands. Nursing Times,97(22),p.63-64.
哈佛参考文献格式[编辑] 维基百科，自由的百科全书 哈佛参考文献格式[1]是一种罗列引用的方式，它将引用文献的其中一部分用括号包含起来，放在正文之内。与之相对的是传统的将参考文献标注于文末（尾注）。[2][3] 目录 ? 1 参考文献 o1.1 引用 o1.2 书目 ? 2 延伸阅读 ? 3 参见 参考文献[编辑] 引用[编辑] 1. ^Harvard System of Referencing Guide. Anglia Ruskin University. 21 May 2012 [4 September 2012]. 2. ^"Author-date system, Chicago Manual of Style, Williams College Libraries, accessed 25 October 2010. 3. ^ Pears, R and Shields, G Cite them right : the essential referencing guide (2008) ISBN 978-0-9551216-1-6 书目[编辑] ?American Psychological Association (2001). Citations in Text of Electronic Material, APA Style. ?British Standards Institution (1990). Recommendations for citing and referencing published material, 2nd ed., London: British Standards Institution. ?Chernin, Eli (1988). "The 'Harvard system': a mystery dispelled", British Medical Journal. October 22, 1988, pp. 1062–1063. ?The Chicago Manual of Style (2003), 15th ed. Chicago: University of Chicago Press. ISBN