Abstract--The empirical study described in this paper addresses software reading for construction: how application developers obtain an understanding of a software artifact for use in new system development. This study focuses on the processes that developers would engage in when learning and using object-oriented frameworks. We analyzed 15 student software development projects using both qualitative and quantitative methods to gain insight into what processes occurred during framework usage. The contribution of the study is not to test predefined hypotheses but to generate well-supported hypotheses for further investigation. The main hypotheses we produce are that example-based techniques are well suited to use by beginning learners while hierarchy-based techniques are not because of a larger learning curve. Other more specific hypotheses are proposed and discussed.
Index Terms--object-oriented frameworks, software reading, empirical study
I.I NTRODUCTION
In almost any software development environment, the various work documents used (e.g. requirements documents, code and design plans) require continual review and modification throughout the lifecycle. This is due to the central role such documents play in many software engineering tasks (e.g. verification and validation, maintenance, evolution, and reuse). Software reading, i.e., the individual analysis of textual software work products aimed at achieving whatever degree of understanding is needed to accomplish a particular task, is thus a key technical activity for software development. A number of studies have examined reading techniques applied to a variety of software engineering tasks, such as detecting defects in requirements [3, 4, 41, 44, 49], assessing user interfaces [52], and reading Object-Oriented code [27]. The reading techniques presented in this paper are classified under Reading for Construction, which is aimed at answering the question: Given an existing artifact, how do I understand how to use it as part of my new system? Reading for construction is important for comprehending what a system does, what capabilities exist and do not exist; it helps us abstract the important information in the system. Forrest Shull and Victor Basili are with the Computer Science Department, University of Maryland, College Park, MD 20742. E-mail: {fshull, basili}@https://www.doczj.com/doc/503895502.html,.
Filippo Lanubile is with the Dipartimento di Informatica, University of Bari, Via Orabona 4, 70126 Bari, Italy. E-mail: lanubile@di.uniba.it.It is useful for maintenance as well as for building new systems from reusable components and architectures [4]. We chose to focus on the understanding of object-oriented frameworks as the artifact to be used in system development. An object-oriented framework (hereinafter, simply framework) is "a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact" [22, 24]. From the perspective of the application developer, it is a skeleton application that can be customized to produce specific applications in some domain [14, 24]. Some of the best-known frameworks support the development of graphical user interfaces (e.g. MacApp, ET++, Interviews, MFC and AWT). Frameworks are also spreading into other domains such as communication software [38], manufacturing systems [8, 37], and banking applications [5].
The choice to focus on frameworks was motivated primarily by two reasons:
1.Frameworks are a promising means of reuse. Although
class libraries are often touted as an effective means of building new systems more cheaply or reliably, these
libraries provide only functionality at a low level. This forces the developer to provide the interconnections
both between classes from the library and between the library classes and the system being developed.
Greater benefits, such as faster application
development [28], are expected from reusable, domain specific frameworks that usefully encapsulate these
interconnections themselves.
2.Frameworks have associated learning problems that
affect their usefulness. The effort required to learn
enough about the framework to begin coding is very
high, especially for novices [32, 46]. Developing an
application by using a framework is closer to
maintaining an existing application than to developing
a new application from scratch: in framework-based
development, the static and dynamic structures must
first be understood and then adapted to the specific
requirements of the application. As in maintenance,
for a developer unfamiliar with the system to obtain
this understanding is a non-trivial task. Little work has yet been done on minimizing this learning curve. Recognizing that one study cannot address issues for all types of frameworks, this paper concentrates on white-box frameworks. Frameworks of this type are tailored by deriving new classes through inheritance, and by writing
Investigating Reading Techniques for Object-Oriented Framework Learning
Forrest Shull, Filippo Lanubile, and Victor R. Basili, Fellow, IEEE
application-specific methods. Black-box frameworks, in contrast, provide a set of application-specific components that are plugged together through polymorphic composition [22]. It has been suggested that frameworks evolve towards black-box as the system design for their application domain becomes better understood [22]. Conclusions about white-box frameworks are of interest primarily for two reasons:
1.White-box frameworks are in wide use [14].
2.Not every framework inevitably evolves into a black-
box framework. For example, some frameworks are
retired from use before evolving to black-box stage;
other frameworks are in application domains that are
not understood to a sufficient degree to support black-
box frameworks. [33]
II.R ESEARCH QUESTIONS
Since we approached this study from the viewpoint of software reading, our primary focus was on the processes developers would engage in, as they attempted to discover enough information about the framework to be able to use it effectively. We reasoned that the best approach would be to observe a number of different approaches or techniques and their effects in practice. From this information, we hoped to determine what kinds of strategies could be used, and for which situations they were likely to be particularly well- or ill-suited. Ultimately we hoped to gain an understanding of the deeper principles involved in framework usage by studying the interaction between the different techniques and the specific task undertaken. Since our study took place in the context of a classroom assignment, we felt it necessary to give our students a starting point for using frameworks. In the absence of any empirical evidence or general agreement in the literature on the best way to teach developers how to use a framework, we selected two promising approaches. Each approach was the basis for a set of guidelines that was taught to half of the class, so that the strengths and weaknesses of the approaches could be compared. (We discuss the guidelines themselves and the process of their creation in section V.) At the same time, we did not want to prevent the students from using work practices that they already knew, or discovered during the project, to be effective. Therefore, we allowed the students to modify these guidelines as desired. Our intention was to study the work practices of the students to determine when our guidelines were used, what other work practices were used, and how effective they were for particular tasks. We did not wish to constrain our subjects in any way to an artificial procedure, but to study and understand what they felt the most suitable approaches were for the problem. Our main research questions can be phrased as:
Can strategies for learning frameworks be identified? What are their characteristics?
As it turned out, one of the learning approaches was viewed by subjects as too cumbersome for the environment of this study, and was not used by any subject for the duration of the study. Although aspects of this approach were incorporated into the work practices of the subjects (these practices are described in some detail in section VII.A), a straightforward quantitative comparison of the results of using each approach was not possible. Instead, most of the results presented in this paper come from a quantitative and qualitative analysis of the student experiences with learning and using the framework over the course of the semester. This type of information is useful for giving us a deeper understanding of what is important in learning to use frameworks.
III.R ELATED WORK
A survey of the literature on frameworks shows that relatively little has been written on using frameworks (as opposed to building or designing them). Most of the work on using and learning frameworks tends to concentrate on strategies for framework designers to use in documenting their work. The primary weaknesses of this approach are that, first, the results are only applicable to frameworks for which the prescribed documentation has been constructed (that is, they do not directly contribute to general guidelines that would help developers in approaching any framework) and secondly, that usually very little empirical evidence is presented in order to demonstrate that the prescribed method is as effective as claimed. We present some of the main areas of framework documentation here and discuss representative papers for each. We would like to reiterate that we in no way see our study as competitive with these works. Our aim is not to suggest that these other approaches are right or wrong, or to present an alternative approach which we argue to be superior. Rather, we aim to provide a more low-level indication of what sources of information or types of activities are important in framework use - information which may be used to help identify weaknesses in higher-level techniques and focus them on aspects of the framework which are most important.
1.Patterns and recipes: Beck and Johnson [6, 23]
advocate the use of “patterns” (interlocking
descriptions of problem/solution pairs, similar to
object-oriented design patterns [17] or cookbook
recipes, e.g. [1]) to describe frameworks. Each pattern describes a functionality supported by the framework, demonstrates how to implement the functionality, and discusses the impact of the implementation on the
system. This seems a promising approach, because it
seems capable of both showing the developer only as
much detail as he or she needs for the current task and directing the developer’s attention to only the most
relevant portions of the framework. Patterns have in
fact been used as the sole form of documentation for
the HotDraw framework. However, the only evidence presented as to their effectiveness is an informal study in which subjects were asked to learn HotDraw using
patterns and provide feedback [23]. This study seems to have been very successful at its primary goal of
helping the patterns’ authors debug their work, but
does not provide much detail as to how the learning
process was influenced. Thus the presentation leaves
unanswered questions as to whether the observed
effectiveness was a function of the specific project
undertaken or would be true in any environment.
A related approach is the use of “hooks,” which are
meant to be similar to Beck and Johnson’s patterns,
although more structured, more uniform, and less
narrative in style [16]. Like patterns, each hook
provides only the information necessary to solve a
specific, focused problem. They are produced by the
framework developer to illustrate how the framework
is intended to be used.
Johnson states [23] that it “would probably be
worthwhile to try out the patterns in a controlled setting where it would be possible to watch how people use
the patterns and what aspects of [the framework] are
hard to learn.” We feel that our study examines
framework usage in exactly this way, although as we
did not want to make a priori assumptions about the
effectiveness of one method of documentation over
another we did not work in an environment
documented using patterns.
2.Formal and/or searchable specifications of
behavior: Another tactic has been to formalize
descriptions of the behavior of framework components, which then allows the creation of a search mechanism
for finding useful components given a query. One such example is the prototype framework browser
constructed at the University of Quebec [30], which is
especially promising in that it concentrates on finding a general solution which can be applied to any existing
framework, regardless of the level of documentation
supplied. However, Gangopadhyay and Mitra point
out two major stumbling blocks for query-based
learning of frameworks: first, searching for and reusing one component at a time does not allow the potentially subtle connections between components to be
understood, and second, it is a very difficult problem to match a query which has been specified in a way
meaningful to the developer with the description of the framework components [18].
3.Architectural approaches: Gangopadhyay and Mitra
recommend instead a top-down approach to learning
frameworks, by which they mean a concentration on
the framework architecture rather than on individual
components [18]. They recommend the development
of exemplars, executable visual models that consist of
instances of concrete framework classes along with
explicit representations of their collaborations. An
exemplar should contain at least one concrete subclass for each abstract class in the framework. This
approach might prove difficult to use for frameworks
that do not conform to good design style issues, such as having only a few abstract classes, and using abstract
classes to implement important sites for customization in the framework. It is also unclear how helpful the
exemplar approach would be in cases in which the
developer wants to make a modification the framework designer has not anticipated (i.e. a modification at a
location that is not represented as an abstract class in
the framework).
4.Tutorials: Other work has focused on tutorials created
for users to follow which will presumably guide users
through the most important points of the framework.
(Two examples are [47] for Unidraw and [15] for
ET++.) An interesting example of work in this area is
Rosson et al.’s tutorial for learning Smalltalk [34]
which applies Minimalist instruction techniques [9]
and seems to corroborate the benefits that may result
from a well-designed tutorial course (claiming to allow new users to develop code for interactive applications
after only four hours). Like Johnson, Rosson
undertakes some testing which is aimed not at testing
hypotheses but at helping to debug the documentation.
However, no study has been undertaken to examine the breadth of knowledge achieved, although this becomes an exceptionally pertinent question when the goal is
radical decreases in learning time for a constant
breadth of knowledge.
An important weakness which is shared by all of these approaches is that they assume that the framework developer will be able to anticipate future uses of the framework adequately to provide enough patterns (or exemplars, or tutorial lessons) in sufficient detail. An alternate research approach would be to avoid making any such assumptions about framework usage in order to undertake an empirical study of how developers go about performing the necessary tasks. Such an approach is not new, and has in fact proven useful in understanding how developers perform related tasks such as understanding code [48] or performing maintenance [43]. Similar methods can be used to study the process of learning frameworks, since white-box framework understanding is a specialized kind of program understanding. A framework can be thought of as a set of object classes that collaborate to carry out a set of responsibilities; the developer needs to gain an understanding of what the various classes are and the functionality they provide. Since classes cannot be reused in isolation, it is also necessary to understand how these classes interact with each other. Understanding the dependencies between the components is a difficult task and the source of many complaints about framework complexity [24].
Example applications play a key role in the documentation of frameworks, by showing what the framework is good for and pointing out features that the framework provides. However, examples do not explicitly show how these features are provided [23]. The problem remains that it is difficult to understand the interactions between objects using source code.
Other authors [11] who have applied an empirical approach to studying framework usage in industrial environments agree that, in most cases, framework customization will be more complex than just making modifications at a limited number of predefined spots. Documentation that assumes this is possible will be too constraining and will not provide support for many realistic development problems, which far from requiring isolated changes may sometimes even require changes to the underlying framework architecture. Our study belongs in this category of empirical study of practical framework use. It is similar in type to the study undertaken by Schneider and Repenning [39], which draws conclusions about the process of software development with frameworks from fifty application-building efforts supervised by the authors. The large number of projects followed allowed the authors to examine both successful and unsuccessful projects, and their observation of (and sometime participation in) the process allowed them to both characterize the usual process and to identify some conditions that contribute to situations where the process breaks down and leads to unsuccessful projects. Our results complement and in some cases extend the results from the Schneider and Repenning study, and we consequently discuss them in greater detail later in section VIII.E.
IV.DEFINITIONS
We include the following definitions to clarify and illustrate some terminology that we use often in this discussion. It is our hope that these definitions will help to make clear our model of framework usage and to keep certain concepts distinct throughout the discussion. For example, we should first be careful to differentiate the framework developer (the developer(s) who designed and implemented the framework) from the application developer (the developer(s) who design and implement a new system using the framework to provide certain key functionality), who is usually referred to as simply the “developer” in this discussion.
example application: an application which has been constructed using the framework. Such examples may be created by the framework developer to illustrate how to produce some functionality using the components provided by the framework, or may be a “real-life” application in whose development process the framework happened to be used.
functionality supported by framework: a particular functionality is either provided by an example application, or there is a one-to-one mapping between the functionality and a framework component at some level of granularity (e.g. subsystem, class, method, ...). An example might be the behavior of radio buttons (primitive GUI objects would be likely to be supported by a class in a GUI framework) or a linked list (most frameworks provide classes that encapsulate reusable abstract data types).
functionality provided by examples: an example application exhibits dynamic behavior which corresponds to the required functionality. The functionality may be implemented in one component or a combination of components which contain some code specific to the example (i.e. some but not all of the functionality may be inherited from the framework).
functionality supported by object model: the required functionality can be implemented as part of the system represented by the object model without too much change to the object model. Obviously the phrase “too much change” is unacceptably vague, but we do not yet have a useful way of characterizing the concept of when adjustment to an object model becomes excessive. Although there are some high-level studies of software architecture underway, we look upon the effort to provide guidance as to how much adjustment is possible in a given situation as an important and promising area of future research.
V.INITIAL DESIGN OF FRAMEWORK LEARNING
TECHNIQUES
In the absence of a definitive approach to framework learning, we turned to the literature to identify useful approaches. Our first step was to identify helpful models of the framework, that is, helpful ways of thinking about the framework that would highlight the truly important features and could be used for finding particular functionality. The most common description of a framework uses a class hierarchy to describe the functionality supported by the framework and an object model to describe how the dynamic behavior is implemented. Most of the common descriptions of a framework in the literature (e.g. [28, 46]) present a model of the framework similar to this one. To teach subjects how to use this model, we created a set of guidelines that could be used to gain an understanding of the class hierarchy. The guidelines help developers understand the functionality provided by the framework by concentrating on abstract classes in the hierarchy. The developer is guided first through the broad classes of functionality, then through deeper and deeper levels of concrete classes to find the most specific instantiation. We refer to this procedure as the Hierarchy-Based (HB) procedure, to emphasize that the underlying model of the framework is the class hierarchy.
Figure 1: Producing focused, tailored procedures As an alternative model, we decided to look at the
framework through a set of example applications which, taken together, were meant to illustrate the range of functionality and behavior provided by the framework. Although a detailed examination of learning frameworks by means of examples has not been undertaken, learning by example also seemed a promising approach. Sets of example applications have been used to document some frameworks (the framework we used came with such a set) and the approach has been recommended for similar types of activities, such as learning effective techniques for problem solving [10], or learning how to write programs in a new programming language [26, 34]. It has also been argued that learning by examples is well-suited for “domains where multiple organizational principles and irregularities in interaction exist” [7], which may be a fair assessment of the large hierarchy of classes in a framework. The framework we used in this study came with a set of examples at varying levels of complexity that was constructed to demonstrate the important concepts of the framework. To help subjects use these examples to learn the framework we created a set of guidelines that would guide exploration through the example set, to particular examples, to particular objects in the implementation, to particular lines of code in the object. This procedure is referred to as the Example-Based (EB) procedure.
Once we had identified suitable models, we constructed detailed guidelines for identifying functionality that would be relevant to the system being developed. To do this we concentrated on identifying similarities between the classes that were specified by subjects in their original object models, and the classes in the framework. These guidelines were then also tailored to the models, and integrated with the procedures for understanding the framework (see figure 1). The final guidelines were intended to be step-by-step procedures that could be taught to the students and used to find functionality in the framework.
VI.DESCRIPTION OF THE STUDY
To undertake an exploratory analysis into framework usage, we ran a study as part of a software engineering course at the University of Maryland. Our class of 43 upper-level undergraduates and graduate students was divided into 15 two- and three-person teams. Teams were chosen randomly and then examined to make certain that each team met certain minimum requirements (e.g. no more than one person on the team with low C++ experience) for the class. Each team was asked to develop an application during the course of the semester, going through all stages of the software lifecycle (interpreting customer requirements into object and dynamic models, then implementing the system based on these models). The application to be developed was one that would allow a user to edit OMT-notation diagrams [36]. That is, the user had to be able to graphically represent the classes and different types of relations between them of a system, to be able to perform some operations (e.g. moving, resizing) directly on these representations, and to be able to enter descriptive attributes (class operations, object names, multiplicity of relations, etc.) that would be displayed according to the notational standards. The project was to be built on top of the ET++ framework [50], which assists the development of GUI-based applications. ET++ provides a hierarchy of over 200 classes that provide windowing functionality such as event handling, menu bars, dialog boxes, and the like. ET++ was considered an attractive choice for this study because it possesses an “outstanding design” and is available from the public domain [32]. The design of ET++ is of sufficient quality that it was the source of seventeen of the design patterns in [17].
Before implementation began on the project, the class was randomly divided into two groups and each was taught only one of the two framework models and its corresponding guidelines for use. During the implementation, we then monitored the activities undertaken by the students as much as possible in order to understand if our learning techniques were used, what other learning approaches were applied, and which of these were effective. To do this, we asked the
and level of detail
students to provide records of the activities they undertook so that we could monitor their progress and the effectiveness of the techniques, and augmented this with interviews after the project was completed. (These data collection mechanisms are discussed below.) Although we felt our learning techniques made good starting points, we did not constrain students to use the techniques exactly as they were taught. We wanted to leave the students the flexibility to modify their development methods if the techniques were not well suited to a particular part of the implementation, or if they had personal techniques that would work better for them.
Since the analysis was carried out both for individuals and the teams of which they were part, we were able to treat the study as an embedded case study [51]. Over the course of the semester, we used a number of different methods to collect a wide variety of data, each of which we discuss briefly below. Most of our collection methods are mentioned by Singer and Lethbridge in their discussion of the pros and cons of various methods for studying maintenance activities [43], and we respond to some of their comments where appropriate. We hope this study provides an additional illustration of their conclusion that, in order to obtain an accurate picture of the work involved, a variety of methods must be used at different points of the development cycle in order to balance out the advantages and disadvantages of each method.
1.Questionnaires were used at the beginning (to report
previous programming experience) and end (to report
effort spent during the last week of implementation and the level of completion for each functional requirement for the project) of the semester. Although the
information reported on the beginning questionnaires
could not be verified, the end questionnaires were
verified against the executables submitted for each
team. The unit of analysis for the beginning
questionnaires was the individual student, while the
end questionnaires were filled out for the entire team.
Both were mandatory although self-reported, and did
not impact the students’ grades.
2.Exam grades were recorded for certain questions on the
midterm that could be used by us to gauge the students’level of understanding of framework concepts. These
grades were recorded for the individual students, were assigned by us after evaluating the students’ responses for the level of understanding exhibited, and were
mandatory (as they constituted part of the students’
grades for the course).
3.Progress reports were to be submitted by each team for
each week of the implementation phase. They
consisted of an estimate of the number of hours worked by the team for the week in implementing the project,
and a list of which functional requirements had been
begun and which completed. As the students were told that the progress reports had no bearing on their grades, many teams opted to submit them only sporadically or not at all. (In some ways, these reports were similar to Singer and Lethbridge’s idea of logbooks, which allow the developer to record information at certain times
throughout the development process. Singer and
Lethbridge concentrate on the dangers of making the
report too time-consuming, but we have noticed a quite opposite phenomenon: if the experimenter makes the
report too minimal, the developer may assume that the information to be collected cannot be truly important
and thus make completing the report a very low
priority.)
4.Problem reports were requests for clarification or for
help with ET++ that the students submitted (via email) to the course instructors. A record was kept of the
general subject of each request, and by which team it
had been submitted. In this way we hoped to maintain
a record of the kinds of difficulties encountered by
teams during the course of the project. Problem reports were obviously not mandatory and had no effect on
student grades, but were a resource that the students
knew could be made use of at their discretion. (Singer and Lethbridge focus on the inaccuracies of
retrospective reports, but our problem reports were
actually an excellent way to get an accurate picture of
where teams were having problems at the time they
were having them - which may be, admittedly, unique
to the classroom environment.)
5.Implementation score was assigned by us to each team
at the end of the semester. Projects were graded by
assessing how well the submitted system met each of
the original functional requirements (on a 6 point scale based upon the suggested scale for reporting run-time
defects in the NASA Software Engineering Laboratory
[45]: “required functionality missing”, “program stops
when functionality invoked”, “functionality cannot be
used”, “functionality can only partly be used”, “minor
or cosmetic deviation”, “functionality works well”).
The score for each functional requirement was then
weighted by the subjective importance of the
requirement (assigned by us) and used to compute an
implementation score that reflects the usefulness and
reliability of the delivered system. The weights were
chosen in such a way that if each functionality worked well, an implementation score of 100 would be
obtained. Scores less than 100 provided a rough
indication of what percentage of system functionality
had been implemented. (Because extra credit was
awarded in rare instances that functionality beyond
what was required was implemented, it was also
possible for implementation scores to be slightly
greater than 100.)
6.Final reports were collected from each team at the end
of the semester. These reports consisted of
documentation for the submitted system (object models and use cases) as well as records of the activities
undertaken while implementing the project (object
models of examples that had been studied, lists of
classes that had been examined for some
functionalities). Additionally, in-class presentations
were given by each team in which they could present
interesting details of the functionality available in their system, their experiences and difficulties with the
techniques they used, and/or their general approach to
implementation. The completeness of the final reports counted toward each team’s grade, although their
conformance to any particular technique did not.
7.Self-assessments were mandatory ratings in which each
student was asked to rate the effectiveness of each
member of his or her team (including him- or herself)
as well as the team performance as a whole. Partly this was to detect if every team member had done their
share of the work, and partly it was to ask students to
think about what they had done rightly and wrongly
during the course of the implementation. Although it
was mandatory that each student return a self-
assessment, they did not count directly toward the
student grade (although in some cases, evidence from
the self-assessments and the interviews led to
individual grades being slightly adjusted).
8.Interviews were mandatory “debriefing” sessions at the
end of the semester. Each team would come as a group to the course instructors, to be asked questions about
what kinds of activities they did during the course of
the semester, which of these they found particularly
useful or useless, and what parts of the project were
easiest and hardest. A set of base questions was asked in every interview, although additional questions were conducted in a dynamic manner. That is, the course of the interview was directed in new directions by us as
unforeseen but interesting themes were raised.
Table 1 summarizes the types of data we collected along with the collection methods we used. In the interest of space, we do not present the actual data in this paper, but maintain a website that contains them in a form suitable for downloading [42].
VII.ANALYSIS
We then analyzed this mix of qualitative and quantitative data to gain some insight into what was going on within each team. By comparing and contrasting teams, we began to see implications that addressed our research questions. Since there has not yet been a large amount of work spent on understanding this area of framework use, our focus was on using this information to look for tentative but reasonable hypotheses and not on testing known hypotheses. The process of building theories from empirical research has been first proposed in the social science literature [13, 19] but it is also followed in the software engineering discipline [40].
A.Development Processes
The analysis approach we used was primarily a mix of qualitative and quantitative, in order to understand in detail the development strategies our subjects undertook. Our first step was to get an overview of what development processes teams had used. (By “development processes”we mean how the team had been organized, what techniques they had used to understand the framework and implement the functionality, whether they based their implementation on an example or started from scratch, and what tools they had used to support their techniques.) To this end, we performed a qualitative analysis of the explanations given by members of the teams during the interviews and final reports, and on the self-assessments. We first focused on understanding what went on within each of the teams during the implementation of the project. We identified important concepts by classifying the subjects’ comments under progressively more abstract themes, then looked for themes that might be related to one another (an example is given below). Once we felt we had a good understanding of what teams did, we made comparisons across groups to begin to hypothesize what the relevant variables were in general. This allowed us to look for variations in team effectiveness that might be the result of differences in those key variables, as well as to rule out confounding factors.
In order to illustrate this analysis technique better, let us consider a small example. While trying to categorize the types of remarks students made during the final interviews, we noticed a lot of comments (some made spontaneously, some with prompting by the interviewers) concerning how teams spent most of their time during the implementation phase of the project. We grouped some of these remarks into a general category that deals with what kinds of activities students found useful in implementation; combined with other categories (which deal with, for example, what kinds of tools students found useful or what kinds of examples were helpful to examine) we began to get a better idea of what techniques students developed to help them in implementation. To get an accurate picture of what teams did over the entire course of the semester, however, we needed to look at other categories of remarks, concerning for example which of the two initial procedures (HB or EB) the team was taught, what their experiences were with the technique, and what parts of the technique were found not to be useful and were discarded. By making such abstractions from the students’ comments, we built an understanding of what each separate team did.
With this understanding of the processes at work within teams, we compared experiences across teams to try to identify themes that emerge. For example, we noticed that most teams who began by modifying an example tended to do better than teams who began implementing from scratch. Our next step of the analysis was to test these provisional hypotheses, again by making comparisons across teams to find possible refuting evidence or confounding factors. For example, suppose Team X started their implementation from an example but turned in a very poor implementation in the end. Does this refute our provisional hypothesis? Perhaps it signifies that the trend we thought we had observed was simply a fluke, or perhaps we may notice a confounding factor - say, Team X was also very poorly organized - that may account for the seemingly anomalous results and needs to be taken into account as part of the analysis.
Aspect of Interest Measures Form of Data Unit of Analysis Collection
Methods
Development Processes Techniques used Qualitative team interviews, final
reports
Tools used Qualitative team interviews Team organization Qualitative team interviews, self-
assessments Starting point for
implementation
Qualitative team interviews, final
reports Difficulties encountered
with technique
Qualitative team problem reports,
self assessments,
final reports
Product Degree of
implementation for
each functionality Quantitative team implementation
score, final
reports
Other Factors Influencing Effectiveness Effort Quantitative team progress reports,
questionnaires Level of understanding
of technique taught
Quantitative individual exam grades Previous experience Quantitative individual questionnaires Table 1: Types of measurements and means for collecting.
Category Number of
Teams Number
Originally
Taught EB,
HB
Description
EB55, 0Students in this category used the EB technique as it was
taught, following the guidelines as closely as they could.
EB/HB50, 5This is a hybrid approach that focuses on using examples to
identify classes important in the implementation of a
particular functionality. The main difference from the EB
technique is that, in the hybrid technique, the student does not
always begin tracing the functionality through the code, but
may instead use the example to suggest important classes and
then return to the framework hierarchy to focus on learning
related classes.
ad hoc EB42, 2This was an ad hoc approach that emphasized the importance
of learning the framework via examples, but ignored the
detailed guidelines given. The primary difference between
these techniques and the EB category is that ad hoc EB
techniques are missing a consistent mechanism for selecting
examples and tracing code through them.
EB/scratch11, 0The team used the EB technique to identify basic structure
and useful classes, but implemented the functionality mostly
from scratch.
Table 2: Description of development processes observed in the study.
Although this is not a common method of analysis in
computer science, it is a recommended approach for social sciences and other fields that require the analysis of human
behavior [13, 29]. It is well suited for our purposes here
because our variables of interest are heavily influenced by
human behavior and because we are not attempting to prove
hypotheses about framework usage, but rather to begin
formulating hypotheses about this process, about which we currently know little.
We found that teams used development processes that fell
into 1 of 4 categories (Table 2). While no team used the
HB technique for the entire semester (although these
guidelines were partly incorporated into some of the other techniques that were used), the EB technique did enjoy
consistent use, both as taught and in combination with other
techniques. It can be noted that even teams who were
taught HB and not exposed to EB tended to reinvent a
technique similar to EB on their own. (Some teams were
even contrite about this. “We didn’t realize at the time that this was the technique taught to the other part of the class,
but it seemed the natural thing to do.”)
B.Potentially Confounding Factors
We also undertook quantitative analyses to gauge the
effects of potentially confounding factors in the study. Due to the small sample size and the exploratory nature of this study, we used an α-level of 0.20 for the statistical tests reported in this paper, which is higher than standard levels. Although not common, this α-level has been used in similar hypothesis-building studies, e.g. [2]. We realize that
statistical tests at this significance level do not provide
strong evidence of a relationship, but instead see their
contribution as helping detect patterns in the data that can
be specifically tested in future studies. The relatively high α-level makes it more likely that we err in the direction of finding false correlations than of inadvertently missing significant relationships. However, the low number of data
points in this study means that the second case is still a
possibility.
We noticed that teams that had been taught the HB technique experienced many early difficulties, particularly in tracking flow of control in the framework, and in finding and correctly parameterizing reusable classes from the hierarchy. We wanted to test if the progress of these teams had been adversely affected by the reading technique. We therefore undertook an analysis of the number of person-hours spent by different groups in order to understand if the amount of effort a team spent on implementation was largely dependent upon the technique they had been taught. The test for differences in the two groups could not be conclusive, as only six teams reported their overall effort data. The analysis did, however, show no significant difference between the average amount of effort spent on the project over the course of the semester by teams who had been taught each of the different techniques (t-value of 0.5916 and p-value of 0.5859). Student remarks from the interviews tended to support this. Most teams who had been taught the HB technique reported that they switched their development approach usually after trying to apply HB for the first 1 to 2 weeks. Regardless of the technique a team had been taught, the heaviest investments of effort for almost all teams came toward the end of the implementation phase.
We also wished to examine whether students actually had a different initial understanding of the framework based on the models and procedures we had taught them. We gauged their initial understanding by means of two questions that appeared on their midterm, after they had been taught one or the other of the framework models, but before they had actually had any experience using the ET++ framework. The first question was intended to measure how well the students grasped the concept of the framework hierarchy of classes (Table 3 shows the distribution of grades on this question by procedure taught). The second question measured understanding of the model of interaction (Table 4). We tested whether response rates were independent of the procedure taught by using Wilcoxon rank sum tests. The results of neither test were significant (Z = -0.6933, p = 0.4881 and Z = 0.6343, p = 0.5259 for the first and second questions, respectively) showing that there is no difference in how well the questions are answered with respect to the technique taught. This shows that, although taught different procedures for using the framework, neither group of subjects started out at a disadvantage to the other in terms of their understanding of the framework itself.
Grade Achieved
A B C D
Technique(%
7DXJKW+%
Table 3: Distribution of grades on exam question dealing with the framework class hierarchy.
Grade Achieved
A B C D
Technique(%
7DXJKW+%
Table 4: Distribution of grades on exam question dealing with the framework model of interaction.
A final concern in all studies of this type has to do with the experience of the subjects. We were concerned that the effectiveness of our teams might have more to do with the level of experience the team members had with implementing similar projects than with any of the variables under study in our experiment. We removed one team (which had had extreme organizational difficulties) from our analysis as an extreme outlier (as defined by [31]). We then used the Pearson correlation coefficient [21] to measure the strength of the linear relationship between experience and implementation score (with correlation values close to 1 or -1 representing an exact linear relationship and values close to zero representing no linear
relationship). We found no correlation between the total amount of experience of a team with programming in an academic environment and its effectiveness at the implementation of the project (Pearson’s correlation coefficient of -0.0015), but did uncover a correlation between total experience programming in industry and effectiveness at implementation (Pearson’s correlation coefficient of 0.55, Figure 2). However, an Rsquare value of 0.31 for the model means that industrial experience accounted for only 31% of the observed variation in the implementation score. This low correlation implies that the previous experience of our subjects is not sufficient to
explain the observed results, and thus that the way in which this implementation was undertaken has affected the quality
I m p l e m e n t a t i o n S c o r e
40
5060708090100110-1
01234
5
Team Industrial Experience
Figure 2: The total industrial experience of a team (in years) and its correlation with its effectiveness at implementation of the project (the team with
implementation score of 44 has been removed from analysis as an outlier).
VIII. R ESULTS
In this section we present the hypotheses that result from our study of framework usage. Along with each we present the relevant indications from our study, so that the reader may judge the strength of the evidence which supports these hypotheses.
A. Hypotheses About Our Models of the Framework
In order to understand the process of learning a framework by means of examples, we can generalize not only from the EB procedure itself but from its example-based derivatives as well. From Table 1, it can be seen that all students who were taught EB ended up using this technique (or a close derivative) throughout the implementation phase. Perhaps
more importantly, all students who were taught the other technique ended up employing a less rigorous example-based technique on their own. It seemed, therefore, that not only our EB technique, but example-based learning in general, was a natural way to approach learning such a complicated new system. This leads us to formulate:HYPOTHESIS 1: Example-based techniques are well-suited to use by beginning learners.
In contrast, subjects tried to use the HB procedure but eventually abandoned it. Qualitative analysis was necessary to understand why this happened. What was wrong with the HB procedure that made it not useful in this environment? We analyzed the student remarks from the problem reports, self-assessments, and final reports to see if characteristic difficulties had been reported. A common theme (remarked upon by half of the teams who had been taught HB) was that the technique gave subjects no idea which piece of functionality provided the best starting place for implementation, or where in the massive framework hierarchy to begin looking for such functionality.
Teams also registered complaints about the time-consuming nature of the HB technique - especially compared to an example-based approach where implementation can begin much more rapidly, hierarchy-focused approaches seem to require a much larger investment of effort before any payoff is observed. One team pointed out that they had explicitly compared their progress against other (as it happened, Example-Based) teams: “We talked to other groups, and they seemed to be getting done faster with examples. So after the first week we started going to examples, too.”
Despite these difficulties, students reported that they felt that the HB technique would have been very effective if they had had both sufficient documentation to support it and more time to use it. “The Hierarchy-Based procedure would be helpful if you have the time ,” said one group in the final interviews, “but on a tight schedule it doesn’t help at all.” Another opinion was expressed by the group who said, “It’s the technique I normally use anyway - and it would have been especially good here when the examples are not enough for implementing the functionality.” There seemed to be a consensus that it would have allowed them to escape from the limitations of the example-based approach and engage in greater customization of the
resulting system, but simply wasn’t effective in the current environment. Five teams were able to create effective strategies that were hybrids of the hierarchy-based and example-based methods (EB/HB). However, the lack of guidance as to how to get started, and the time required to learn the necessary information to use it effectively, meant that no development teams used it exclusively for a significant portion of the implementation phase. (By no means was this a completely negative development, as we now have more detail on techniques that minimize that crucial learning curve.)
HYPOTHESIS 2: A hierarchy-focused technique is not
well-suited to use by beginners under a tight schedule.
B.Practical Implications for Using an Example-Based Procedure
The analysis in the last section should not be taken to imply that our EB procedure was without problems. We also undertook a qualitative analysis of subject satisfaction with the Example-Based procedure in order to understand where it could be strengthened for future use. We found that there were also characteristic problems with EB that were encountered by beginners.
Although the teams using this technique usually managed to get the functionality working in the end, almost all (4 out of 5) of the groups in the study who used our EB technique reported difficulties in finding the necessary functionality within the example set. The problems with finding it in the first place seemed especially acute when the functionality needed was a very small part of a much larger example (e.g., a characteristic way of displaying items onscreen, or the dialog boxes discussed under “key functionalities”, below). This indicates a problem with our EB technique –further guidance is required to assist developers in finding and extracting small pieces of functionality embedded within larger examples. As there is currently little guidance available in this regard, more work will be have to be done in this area to enable effective example-based techniques. This study also provides indications that characteristics of the example set can influence the performance of an example-based approach as well. One-fourth of all the teams in our study had trouble making use of the examples because the example set provided did not conform to a consistent organization or structure. Some examples were based on Model-View-Controller interaction [20] while others were not constrained by any such separation of functionality, and different examples seemed to achieve the same functionality by using different classes from the framework hierarchy. As others [35] have pointed out, learning how to implement functionality from existing applications is difficult because the rationales for design choices, which explain why the finished implementation looks the way it does, are usually not included in the documentation. When attempting to reuse functionality from existing applications, developers are implicitly asked to reconstruct the choices that led to the finished implementations they are studying. This situation can actually be made worse in a framework-based environment, where effective reuse requires the developer to understand the rationales behind a number of applications, not just one. This is a problem that will have to be addressed by any example-based technique.
HYPOTHESIS 3: The effectiveness of a technique for adapting framework-based applications depends on breadth of functionality and other characteristics of the existing applications This hypothesis is very high-level, and further work is required to understand better the effect of characteristics of the example set. However, hypotheses 4 through 6 in the next section are concrete applications that may demonstrate the usefulness of this hypothesis.
C.Hypotheses About the Level of Specificity in the Procedures
This study provides us with an excellent opportunity to understand whether the procedure we created was at a useful level of specificity. Because some teams followed the procedure exactly while others followed it only to a certain extent, we can distinguish between the following two types of example-based processes:
?Strictly adopted: The EB technique is considered “strictly adopted” when followed in a step-by-step
fashion. This procedure focuses entirely on guiding the developer to find useful functionality in the example
applications, which can then be tailored to the current
system.
?Ad hoc adopted: The EB/HB, ad hoc EB, and EB/scratch techniques are considered to fall in this
general category. Subjects who used these techniques
are still considered to have adopted the basic approach behind the EB technique (viz. learning from examples).
However, the subjects have augmented this basic
approach to a greater or lesser degree with other
techniques that were found to be effective.
We can compare the experiences of strictly adopted to ad hoc adopted teams to understand if our technique, at its current level of detail, is useful.
To perform this analysis, we focused on certain key functionalities, that is, certain requirements for which there was a large degree of variation between teams in terms of the quality of the implementation. Recall that we had graded each required piece of functionality for each project on a 6-point scale. To select key functionalities we looked for functionalities for which there was enough variation among all 15 of the teams on the rating scale (regardless of what type of technique they used) that teams could be easily divided into at least two groups based on their score. We then analyzed whether the level of detail at which the procedure was followed had any correlation with whether the team was able to implement a particular functionality in a more complete or sophisticated way.
To back up this qualitative analysis, we attempted to use statistical tests to verify the correlation. Since both of the variables in this analysis (technique followed and result from implementation) are on a nominal scale (i.e. expressed as categories) we can organize data into contingency tables where each dimension corresponds to a variable and numbers represent frequencies. We want to test whether the proportion of teams in each type of implementation varies due to the type of technique that was used. Specifically, the null hypothesis is that the proportion of teams who achieved each type of implementation is independent of the technique that was used to perform the
implementation. In order to test this difference we apply the chi-square test of probability1. Due to our small sample sizes and the exploratory nature of this study, we again used an α-level of 0.20. We also present the product moment correlation coefficient, r, as a measure of the effect size [25]. (An r-value of 0 would show no correlation between the variables, whereas a value of 1 shows a perfect correlation.) We realize that these tests do not provide strong statistical evidence of any relationship, but instead see their contribution as helping detect patterns in the data that can be specifically tested in future studies.
We identified 4 such key functionalities: links, dialog boxes, deletion, and multiple views. They illustrate 3 types of situations that may arise when functionality is being sought in examples:
1.The examples don’t provide all of the functionality
desired. Key functionality 1 (links) fits into this
category. OMT notation requires that links be drawn
between classes in the model which interact in some
way with each other. The specifications for our OMT
editor stated certain other specifications for handling
links, such as how they should be entered into the
diagram, and that they should automatically update
when their associated classes are moved. Provided
with the example set was the “er” entity-relation
diagram editor which provided similar functionality
that allowed two linked objects to be represented by
means of a line that connected their centers. Although useful as a starting point, this implementation was not
sophisticated enough for the project, because the same two classes in an OMT diagram may be connected by
multiple links. If these are all represented by lines
drawn from center to center, every link between these
classes will overlap. There is no example provided
with ET++ that shows functionality that explicitly
addresses this concern.
About half of the teams implemented the link
functionality as in the er example. Of the teams that
implemented a more sophisticated version that allowed links to be uniquely represented (i.e. multiple links
between two classes do not overlap), there were a
number of solutions: randomly displacing links by a
small offset, recording the point where the user drew
the link across the boundary of the class, and breaking the line down into a series of line segments which may then be individually positioned.
Almost all (4/5) of the teams who used the EB
technique implemented the less sophisticated version
of the functionality found in the er example. By
comparison, less than half (4/10) of the teams who
used a modified version of EB turned in the less
sophisticated implementation (Table 5). A chi-square
test of independence was undertaken to test whether
1 We base our use of the chi-square test, rather than the adjusted chi-square test, on [12], which argues that the adjusted test “tends to be overly conservative.”
the level of sophistication was dependent on the type of technique used, although we recognize that the small
number of data points involved can lead to some
inaccuracies in the results [31]. The test resulted in a
p-value of 0.143 (χ2 = 2.143), which is statistically
significant at the selected α-level. An r-value of 0.38
confirms that this shows a moderate correlation
between level of sophistication and type of technique
[21]. From this example we hypothesize that:
HYPOTHESIS 4: A detailed Example-Based procedure can cause developers to not go beyond the functionality that is to be found in the example set.
Technique Followed
strictly
adapt.
ad hoc
adapt.
5HVXOW RI6RSKLVWLFDWHG Implementation6LPSOH
7DEOH : Number of teams achieving sophisticated versus simple implementation of links, whether using strictly or ad hoc adopted techniques.
2.The functionality was completely contained in
(perhaps multiple) examples. Key functionalities 2
(dialog boxes)and 3 (deletion) provide evidence that
the EB technique performed about the same as the
variant techniques in this case.
For dialog boxes, examples existed which showed how to create dialog boxes containing graphical devices
(e.g. text fields, radio buttons) and how to use them to
display and store information. The difficulty was that
this functionality was spread piecemeal over multiple
examples and students had a hard time finding and
integrating all of the functionality they needed. About
half of the class (7/15) managed to get the dialog box
functionality working correctly and interfaced with the rest of the system (Table 6). All techniques were
distributed roughly equally between the teams who did and did not get this functionality working correctly.
The chi-square test here yielded a p-value of 0.714 (χ2 = 0.134), for which the related r-value is 0.10. This
confirms that response levels are very likely effectively equal between the two categories.
For deletion, there was at least one example that clearly contained functionality to delete classes and links from
a diagram. All teams were able to implement this
functionality. Getting the functionality to support the
ability to undo or redo a deletion was apparently more
challenging, however, although the examples covered
this as well. Partly, this may have been due to students simply forgetting to implement this part of the
functionality since it was not explicitly mentioned in
the requirements (although adequate testing should
have revealed the need to interface correctly with this
standard ET++ functionality!).
Teams basically implemented deletion in one of three ways:
1. The ability to undo or redo was integrated fully with deletion.
2. The ability to undo or redo was not implemented for deletion, but deletion was implemented in such a way
that a later call to undo or redo would not cause a core dump (this minimally satisfied the requirements for the project, in letter if not in spirit!).
3. The ability to undo or redo was not implemented at
all for deletion; deletion could be used but a later use of undo or redo could cause a core dump if the program
tried to manipulate an object that had been deleted. Again, the different techniques for learning
frameworks seem pretty equally distributed among
these three categories (Table 7). The chi-square test
for this functionality yielded a p-value of 1 (χ2 =
0.000), with an associated r-value of 0, which is not significant and indicates that response rates are exactly equal regardless of the type of technique used.
From these two examples we hypothesize HYPOTHESIS 5: When the functionality sought is contained in the example set, Example-Based techniques will perform about the same, regardless of
the level of detail provided.
Technique Followed
strictly adapt.ad hoc adapt.
Result of)XOO\ FRUUHFW
,PSOHPHQWDWLRQ,QFRPSOHWH
Table 6: Number of teams who achieved fully correct versus incomplete implementations of dialog boxes, whether using strictly or ad hoc adopted techniques.
Technique Followed
strictly adapt.ad hoc adapt.
Result of,PSO
,PSOHPHQWDWLRQ,PSO
,PSO
Table 7: Number of teams achieving each of the three levels of implementation for deletion, whether using strictly or ad hoc adopted techniques.
3.The examples provide a more sophisticated
implementation than is required. Key functionality
4 (views) fits here. The requirements for the OMT
editor stated that the program must provide multiple
views of the currently opened document. Examples
existed which satisfied the project’s requirements about views (that they update automatically, be
independently scrollable, and allow resizing).
However, there were also examples that gave an even
more sophisticated implementation that allowed views
to be dynamically added and deleted.
All but three teams chose the more sophisticated
implementation. Two of these three teams turning in
less functionality used the EB technique (Table 8). The
chi-square test resulted in a p-value of 0.171 (χ2
=1.875), which is significant at the selected α-level. An
r-value of 0.35 shows a moderate correlation between
the variables and allows us to hypothesize:
HYPOTHESIS 6: When the example set contains
functionality beyond what is required for the system, a
sufficiently detailed Example-Based procedure can
help focus developers on just what is necessary.
Technique Followed
strictly
adapt.
ad hoc
adapt.
Result of6RSKLVWLFDWHG
,PSOHPHQWDWLRQ6LPSOH
Table 8: Number of teams achieving sophisticated
versus simple implementation of views, whether using strictly or ad hoc adopted techniques.
The practical consequences of this analysis may be that the level of detail that is appropriate in an Example-Based procedure is strongly dependent on the breadth of the example set provided. We hypothesize that the more
detailed a procedure is, the more it focuses the developer on using only functionality provided by the examples. This
may be because developers become too reliant on the examples and do not understand the system at a sufficient level of detail to implement effectively from scratch when necessary. Alternatively, it may be that integrating functionality written from scratch becomes more and more difficult when more and more of the system is taken from examples that someone else has written.
Of course, there are other benefits to providing additional detail in such procedures. Among the most important may
be packaging experience to guide new developers. For example, in our study we noticed that half of the teams who used a variant of the EB procedure wasted time and effort during the course of the implementation phase by having to
re-implement some functionality that they had implemented previously in a short-sighted way. Since only 1 of the 5 teams who used our EB procedure exactly reported the
same difficulty, we feel that a definite benefit of the procedure was that it helped guide our subjects to focus
more on features which were important to the implementation as a whole, rather than just the portion they happened to be working on at a particular time.
D. Hypotheses About Beginning Implementation
Because we did not constrain the students as to how they went about implementing the functionality, we could also study whether the way in which the implementation was begun had an effect on the rest of the implementation process. Some teams decided to start from scratch,
beginning with no functionality on top of the framework and slowly growing the code as they determined how to implement specific functionalities. Other teams chose to start with an example which seemed to contain some of the functionality they would need in the finished system. They then modified the functionality that was there and added whatever else was required to produce the finished system.We wanted to see if one approach tended to get more functionality working more reliably (as measured by the team’s implementation score).
All teams who started from an example chose the same one,a simple entity-relation diagram editor (known as “er”). It was similar to the OMT editor to be developed, but much simpler: as specified for the OMT editor, the ER diagram editor allowed simple shapes to be added to an editable document, and allowed these shapes to be selected, moved,and associated with one another. However, more
sophisticated functionality, such as entry of attributes via dialog boxes and the maintenance of separate regions within a particular shape, was lacking.
i m p l e m e n t a t i o n s c o r e
40
5060708090100110
example
scratch
starting from...
Figure 3: Team implementation scores for teams starting from scratch versus teams starting by
modifying the “er” example. 90%, 75%, 50%, 25%,and 10% quantiles are shown. The team with
implementation score of 44 has been removed from analysis as an outlier.
We used a t-test to determine whether teams starting from the “er” example tended to perform significantly better than teams starting from scratch (Figure 3). One point,representing a team which experienced severe
organizational difficulties which were primarily responsible for a very low implementation score, must be removed from this analysis as an extreme outlier (according to the definition given in [31]).
The test yielded a p-value of 0.15 (t = 1.538), which is significant at the 0.20-level and provides some evidence that teams who started by modifying an example tended to be more effective than those starting from scratch. This indicates that, overall, the benefits of relying on an existing example as a starting point (which may include being able to exploit an existing file structure and to model new
classes on similar ones which already exist in the example)outweigh the negatives (the extra work involved in
identifying relevant functionality and removing irrelevant code).
HYPOTHESIS 7: For implementing a set of requirements in a framework-based environment, if a suitable example application can be found, then adapting that application is a more effective strategy than starting from scratch.It was especially noteworthy that every one of the teams who started from an example used the “er” editor as a starting point. There was, in fact, a second example application which could conceivably have served as a starting point also. This second important example application was a small drawing editor that seemed to provide most of the functionality needed for the OMT editor, as well as much extraneous functionality. It is very interesting that no teams chose the drawing editor as a starting point. Of the teams who commented on this
decision during the final interviews, most seemed to agree with the reasoning that the drawing editor just had too much “extra functionality and complicated code that we do not need”, and that the large amount of extraneous functionality would be too confusing to enable the code responsible for the functionalities of interest to be easily separated out. If we had been able to compare the performance of teams who had started from each of the examples, we might have been able to draw useful conclusions about what attributes of an example make it a better or worse starting point for
implementation. This is a promising direction for future work.
E. Hypotheses About the Importance of the Object Model From the qualitative analysis of interviews and self-assessments, there were some general indications about the importance of the object model:
? 6 of our development teams mentioned – without being
prompted by us - the importance of their object models as guides to implementation. 3 of these teams reported that they had been able to stay fairly close to their original object model of the system during the course of implementation. All of these teams ranked in the
top half of the class with regards to implementation
score. The remaining 3 teams were reporting
problems; they had strayed from their original model
during implementation. It seems that this inability to
follow the model had some negative effects, as all 3
were ranked in the bottom half of the class. (Since 5 of these 6 teams had all received the same grade on the
original model, it seems unlikely that the variation in
performance could have been caused by factors outside the implementation phase, such as the quality of the
model itself.)
? 2 of the 3 teams who were not able to follow their object model also reported difficulties due to the
inconsistent nature of the examples.
Throughout this study we have observed the central importance of the object models in development. Although we assume that object models are important and necessary parts of any software development effort, their interaction with framework development seems even more noteworthy. When using frameworks, there is the important question of whether to modify the object model of the system, so as to exploit a piece of functionality offered by the framework that might not exactly fit the original plan, or to keep the object model “as is”, even if it makes implementing the application on top of the framework harder.
The general indications from the interviews and self-assessments leads us to:
HYPOTHESIS 8: Overuse of framework functionality can lead to negative effects (e.g., rework) which might overcome the positive ones (e.g., short cycle time).
It seems that one cause of trouble may have been that these teams did not understand the examples well enough to adapt the functionality illustrated by the examples to the system being developed. Teams who implemented incorrect functionality may have been simply too willing to make modifications to their planned system to accommodate the examples more easily.
Schneider and Repenning [39] present an interesting study of framework use that comes to similar conclusions. What we describe as straying from the original object model, they identify as projects for which “the application design process had been driven by features of the framework,” a condition which is described as being present in some development efforts which “ended up with really messy designs, or were cancelled.” As we noticed through observation of our teams, they identify the likelihood that a team will have to reimplement some functionality as one of the major negative consequences arising from this situation:“Premature design decisions made during the feature-driven phase can corrupt application system architecture or require abandonment of much work.” They further point out that the developer’s temptation is to deal with the easier problem of adapting functionality provided by the framework first, leaving more difficult functionality (which is not guaranteed to fit nicely into the framework-based development) for later and making breakdowns all the more devastating when they occur.
Some of the successes of our EB technique may also have come from its treatment of the object model. We noticed in our analysis of problems that a much higher percentage of teams using modified versions of EB reported wasted effort due to incorrect implementations than teams using EB. We attribute this to the EB technique’s focus on the object model as a guide for implementation, which may not have been so evident in ad hoc variants.
These results create an interesting tension with our experiences with example-based techniques, which seem to imply that reuse of framework functionality is always a positive thing. Taken together, our conclusions indicate that, within proper bounds, exploiting functionality from the framework and example set is the most helpful direction - otherwise, it can be very bad indeed. Schneider [39] draws a similar conclusion: although overuse of framework functionality can lead to negative effects, as described above, exploitation of the low-level framework features is a sensible trend that presumably pays off, when used within bounds. Discerning just where these bounds may lie is a crucial question that awaits further study; for now, we conclude only that development difficulties are liable to appear unless the object model of the system is well supported by the framework and its example set (i.e., the framework permits an implementation of the system that does not require major deviations from the object model).
IX.A NSWERS TO R ESEARCH Q UESTIONS
In this section, we relate our observations to our specific research questions for the study.
A.Can strategies for learning frameworks be identified? Hypotheses 1 and 2 address this question.
The example-based technique was identified as an effective strategy in our environment. While we cannot say in all cases that an example-based learning approach would be superior to one based on the class hierarchy and model of interaction, the indication of this study was that for novice users, the examples were a more effective way to learn. Within the category of example-based techniques, we further differentiate “strictly adopted” from “ad hoc adopted.” Although these techniques share many common features, our analysis of their use in practice discovered certain characteristic differences. This leads us to classify them as separate strategies.
Although the hierarchy-based approach cannot be deemed effective in our environment, as it was abandoned and not used to implement any of the semester projects, we cannot assume that a hierarchy-based approach is always inferior.
The most important environmental condition appeared to be the subjects’ familiarity with the particular framework being used. Several of our subjects had recognized benefits of the HB technique but were unable to apply it due to their lack of familiarity. They expressed this in comments during the interviews such as: “The HB procedure was more similar to what I normally do, but…” or “I found the examples limiting in some ways and thought the HB procedure would address this problem, but…” It is possible that, if our subjects had had more experience with the framework, the HB procedure would have proven better suited to their needs. Indications are that hierarchy-based procedure required more experience with the framework to be used effectively.
B.What are the characteristics of these learning strategies?
Since the subjects of our study only had significant experience with the EB technique, we can report only on the characteristics of example-based strategies. (Our observations on this subject were recorded in hypotheses 3 through 8.) We identified two main types of example-based strategies: strictly adopted and ad hoc adopted, each with its own strengths and weaknesses. The relative effectiveness of each seems to be most strongly determined by how closely the object model of the system to be developed corresponds with the existing applications.
Hypothesis 5 expresses our observation that when the functionality called for by the object model is well-contained in the set of existing applications, just about any example-based technique should be helpful. However, as illustrated by hypothesis 4, a strictly adopted technique can’t take the developer far beyond what is provided by the existing applications themselves. In a situation in which the set of applications is sparse and does not contain the necessary functionality, an ad hoc technique may be more appropriate. As hypothesis 6 indicates, if the set of applications is particularly large, then a strict adaptation technique may be most helpful. Despite its weaknesses, such a technique in procedural form was shown to guide the developer toward implementing the object model “as is”and away from “gold-plating,” or spending time providing extra features that seem nice but are not necessary.
From the experiences of our beginning learners, we also have evidence about other characteristics that are required by example-based techniques in order to be successful. Hypothesis 3 indicates that future studies need to be undertaken to determine if we can add better guidance for helping developers find functionality in existing example applications. Hypotheses 7 and 8, respectively, may indicate that example-based techniques should guide developers to begin their implementation from an existing application, if a suitable one can be found, and to stay closely to the original object model once implementation has begun. (It is possible that, as developers get more experience with the framework, it may be possible to synchronize the design of the system more closely to the framework infrastructure from the beginning, thereby minimizing the problem of mismatch between the system design and the framework. Our study did not address this possibility.)
X.T HREATS TO V ALIDITY
There are three tests which can be considered to evaluate the quality of any empirical study: construct validity, internal validity, and external validity [25].
A.Construct Validity
Construct validity aims to assure that the study correctly measures the concepts of interest. The main problem is that variables never measure only the construct of interest but also other extraneous sources of variation. One tactic to enhance construct validity is triangulation: the use of multiple sources aimed at corroborating the same fact or phenomenon [51, pp.90-94].
In our study we applied data triangulation, by including multiple measures for the same aspect of interest and different collection methods for the same measure (Table
1).
B.Internal Validity
Internal validity aims to establish correct causal relationships between variables as distinguished from spurious relationships. Although a case study cannot have the same internal validity as a controlled experiment, because the investigator has little control over events, there are analysis techniques that can strengthen the internal validity, even for exploratory studies like this.
We made inferences using the qualitative analytic technique described in [13]. It consists of performing a within-case analysis, to gain familiarity with each case and find emerging patterns, followed by cross-case analysis, to look for similarities and differences between cases. Although this is not a common method of analysis in computer science, it is a recommended approach for social sciences and other fields that require the analysis of human behavior [13, 29]. It is well suited for our purposes here because our variables of interest are heavily influenced by human behavior and because we are not attempting to prove hypotheses about framework usage, but rather to begin formulating hypotheses about this process, about which we currently know little.
A specific threat to internal validity might be that we have constructed one of the techniques incorrectly, which would explain the differences in performance. As regards the example-based technique we used, EB, we attempted to minimize the odds of making this mistake by basing the specific technique on the example set which is provided by the framework's authors themselves. For the hierarchy-
focused technique, HB, we based our model of the framework on the most important facets of the framework definition. We feel that the use of the inheritance hierarchy means that our model is complete because all functionality provided by the framework must be encapsulated in one of the classes of the class hierarchy, with the inheritance relations showing how the functionalities provided are related to one another. Thus, while there may be other models more adept at supporting framework learning, we feel confident that our model is adequate to the job.
We also undertook quantitative analyses to test the effects of potentially confounding factors (such as differences in effort spent, understanding achieved, or previous experience) which could be rival explanations to our findings. As pointed out in section VII.B, the relatively low number of data points in this study means that these results should be seen, not as providing a definitive list of the important factors, but of identifying potential factors likely to have some impact on framework learning. It remains for further study to verify this impact, a topic we return to in the next section.
C.External Validity
External validity aims to assure that the findings of the study can be generalized beyond the immediate study. Although generalization can be achieved only through replication in multiple studies, we believe that our findings are relevant for a larger population than this single study.
A first threat to external validity might be that professional developers would have behaved differently than the students that we used as the subjects of the study. Certainly, this is always a danger in studies of this sort. However, in this case we feel that this difference would not be a strongly significant one. Although the level of industrial experience in the class was not high, all students had experience both programming in the language used (C++) and in object-oriented techniques. More importantly, even professional developers would almost certainly have been novices in terms of the use of the ET++ framework, so that the most immediately applicable experience would not have significantly varied in either case.
A second threat to external validity might be that our findings are tied to the framework we used, ET++. Although we cannot completely rule out this threat to validity, ET++ has been thoroughly tested and improved from the initial version and it incorporates seventeen of the design patterns in [17]. From this point of view, we consider ET++ representative of the class of sophisticated white-box frameworks that pose learning problems, which can be major inhibitors against their use.
XI.C ONCLUSIONS AND F UTURE R ESEARCH
This paper has formulated a set of well-motivated hypotheses concerning white-box frameworks based upon direct observation of white-box framework use in development. As the research community builds up confidence as to the validity (or falsity) of such hypotheses, a more objective basis can be constructed for activities such as tool support and training for this class of framework. For example, hypotheses 1 and 2 are the result of evidence showing that learning by example (as opposed to gaining familiarity with the framework itself first) is useful for helping beginning learners produce working systems quickly. While the general benefits of example-based approaches may or may not seem intuitive, this study has provided some evidence, based on empiricism rather than intuition, that such approaches can be of use on non-trivial development projects using frameworks. Since an organization that uses frameworks will tend to build up a set of related applications, all based on the same underlying structure, hypotheses 1 and 2 indicate that reuse of components or even whole applications from this set can be especially beneficial in a framework environment. Frameworks that come packaged with a set of example applications can provide an analogous benefit. Hypotheses 4 through 6 (summarized in hypothesis 3) qualify the benefits of example-based learning techniques by pointing out some of their limitations. A direct implication of these hypotheses is that the emphasis placed on adapting examples should vary according to the relation between the example set and the application to be developed. Hypothesis 7 implies that reusing as much previous functionality as possible (even including whole previous applications) is a useful strategy in this kind of application environment. Finally, hypothesis 8 provides more evidence for the benefits of a general software engineering principle (viz. that a system’s design should be closely followed during implementation) by showing that it also applies to development using framework technology. As we have emphasized, the results of this study are hypotheses for further study, not definitive conclusions. This is partly due to a number of factors (which we presented and discussed in section X) that affect the strength of the conclusions that can be drawn from our observations. However, we hope that this paper has made a useful contribution by identifying an initial set of factors that should be controlled, monitored, or tested in later studies.
One lesson learned from this study is the importance of process conformance; subjects are rarely malicious but are almost always loathe to use processes they are uncomfortable with to achieve a result they know can be reached in another manner. This discomfort can be the result of a steep learning curve for the new technique, or the result of the unsuitability of the technique for the current environment (as with the HB technique in this study). The experimenter must make the important decision of whether:?To constrain subjects to use a specific process, in order to draw conclusions about that process, or
?To allow subjects the freedom to use processes they feel are useful, while monitoring the processes
undertaken. (This strategy was the one used in our
study.)
In the latter case, qualitative data collection and analysis are especially important. Without qualitative analysis in this study, we could only have concluded that the HB technique was unsuitable to the environment; through our analysis of interviews and problem reports, we have some confidence that the contributing factor was low subject experience with the framework.
Another result of the qualitative analysis was the identification of another factor influencing framework learning, namely, the level of specificity at which an example-based technique is followed. This factor, which contributes to our hypotheses 4, 5, 6, and 8, seems nearly impossible to assess without the use of qualitative methods. Because our analysis detected distinct differences between subjects using different levels of specificity (in our terminology, between “strictly adopted” and “ad hoc adopted”) this factor should be assessed in future studies as well.
As shown in section VII.B, a third important factor identified by this study was the previous experience of the subjects. The correlation between subject experience and effectiveness at implementation shows that it is necessary to assess the effect of experience on the use of new techniques. In any case, subject experience can be expected to have an effect on the outcome of software engineering practices and it is necessary to check that it does not overshadow other factors, such as the use of the technique under study.
It is our hope that future studies in this area can use our results as a beginning for verifying, bounding and extending these hypotheses. Certainly, studies in the framework domain have the potential for verifying the practical implications of these hypotheses, such as whether training professional developers to concentrate too much on reuse will result in systems of lower quality (as it did for our student subjects, reflected in hypotheses 4 and 8). Studies can bound the hypotheses by discovering contexts in which the techniques are more or less effective, e.g., EB is effective for beginning framework users but HB is more effective for advanced framework users. But it is to be hoped that studies will be undertaken to test the generalizability of our results to other areas as well. For example, the indications from this study have already proven useful for our study of software reading techniques. In this study, we saw that the level of specificity at which a technique is followed can have a distinct effect on the outcome; we have since run experiments on other reading techniques in which the level of specificity was explicitly varied [41]. These experiments have helped us conclude that specificity is an important variable in software reading research, although its specific effects may vary from case to case.
Other potential areas of generalization exist as well. One example (among many) is that hypotheses 1 and 2,concerning the effectiveness of example-based learning, need not be limited to framework-based environments. Evaluations of example-based learning in related areas would be of great interest. For example, could these results be taken to imply that an effective way to learn to program would be to first study existing programs (i.e. that the first step in learning to write good programs is learning how to read them)?
In order to facilitate replication or review of this study we have set up a web site containing as much as possible of our experimental materials and data. This web site may be found at [42].
XII.ACKNOWLEDGEMENTS
Our thanks to Gianluigi Caldiera for his invaluable assistance designing and running this experiment as a part of the course CMSC 435 (Fall 1996) at University of Maryland, College Park. Our thanks also go to the students of CMSC 435 for their cooperation and hard work.
This work has been supported by UMIACS and NSF grant CCR9706151.
XIII.R EFERENCES
[1]MacApp Programmer’s Guide. Apple Computer,
1986.
[2]V. Basili, R. Reiter, Jr, “A Controlled Experiment
Quantitatively Comparing Software Development
Approaches”, IEEE Trans. Software Engineering, vol.
SE-7, pp. 299-320, May 1981.
[3]V. Basili, S. Green , O. Laitenberger , F. Lanubile, F.
Shull, S. Soerumgaard, and M. Zelkowitz, "The
Empirical Investigation of Perspective-Based
Reading”, Empirical Software Engineering: An
International Journal , vol. 1, no. 2, pp. 133-164,
1996.
[4]V. Basili, G. Caldiera, F. Lanubile, and F. Shull,
“Studies on Reading Techniques”, in Proc. of the
Twenty-First Annual Software Engineering Workshop, Dec. 1996, pp. 59-65.
[5] D. Baumer, G. Gryczan, R. Knoll, C. Lilienthal, D.
Riehle, and H. Zullighoven, "Framework
Development for Large Systems", Communications of
the ACM, vol. 40, no. 10, pp.52-59, October 1997. [6]K. Beck, R. Johnson, “Patterns Generate
Architectures”, in Proc. ECOOP’94, 1994.
[7] D. S. Brandt, “Constructivism: Teaching for
Understanding of the Internet”, CACM, vol. 40, pp.
112-117, Oct. 1997.
[8] D. Brugali, G. Menga, and A.Aarsten, “The
Framework Life Span”, Communications of the ACM,
vol. 40, no. 10, pp.65-68, October 1997.
[9]J. Carroll, The Nurnberg Funnel: Designing
Minimalist Instruction for Practical Computer Skill.
Cambridge, MA: MIT Press, 1990.
[10]M. Chi, M. Bassok, M. Lewis, P. Reimann, and R.
Glaser, “Self-Explanations: How Students Study and
Use Examples in Learning to Solve Problems”,
University of Pittsburgh, Technical Report
UPITT/LRDC/ONR/KBC-9, Nov. 1987.
[11]W. Codenie, K. DeHondt, P. Steyaert, A. Vercammen,
“From Custom Applications to Domain-Specific
Frameworks”, CACM, vol. 40, pp. 71-77, Oct. 1997.
[12]Conover, Practical Nonparametric Statistics, 2nd
Edition. NY: John Wiley & Sons, 1980.
[13]K. Eisenhardt, “Building Theories from Case Study
Research”, Academy of Management Review, vol. 14,
no. 4, pp. 532-550, 1989.
[14]M. A. Fayad, and D. C. Schmidt, "Object-Oriented
Application Frameworks", Communications of the
ACM, vol. 40, no. 10, pp.32-38, October 1997. [15] C. Frei and H. Schaudt, ET++ Tutorial: Eine
Einführung in das Application Framework. Software
Schule Schweiz, Bern, 1991.
[16]G. Froehlich, H. Hoover, L. Liu, and P. Sorenson,
“Hooking into Object-Oriented Application
Frameworks”, in Proc. of the 19th International
Conference on Software Engineering, May 1997, pp.
491-501.
[17] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,
Design Patterns: Elements of Reusable Object-
Oriented Software. Reading, MA: Addison-Wesley,
1995.
[18] D. Gangopadhyay, S. Mitra, “Understanding
Frameworks by Exploration of Exemplars”, in Proc.
of 7th International Workshop on CASE, July 1995,
pp. 90-99.
[19]H. G. Glaser, A. L. Strauss. The Discovery of
Grounded Theory: Strategies for Qualitative
Research. Hawthorne, NY: Aldine Publishing
Company, 1967.
[20] A. Goldberg, Smalltalk-80: The Interactive
Programming Environment. Reading, MA: Addison-
Wesley, 1984.
[21]L. Hatcher, E. J. Stepanski, A Step-by-Step Approach
to Using the SAS? System for Univariate and
Multivariate Statistics. Cary, NC: SAS Institute Inc.,
1994.
[22]R.E. Johnson and B. Foote, "Designing Reusable
Classes", Journal of Object-Oriented Programming,
vol.1, no. 5, pp.22-35, June/July 1988.
[23]R. Johnson, “Documenting Frameworks with
Patterns”, in Proc. OOPSLA ‘92, October 1992, pp.
63-76.
[24]R.E. Johnson, "Frameworks = Patterns +
Components", Communications of the ACM, vol. 40,
no. 10, pp.39-42, October 1997.
[25] C.M.Judd, E.R.Smith, and L.H.Kidder, Research
Methods in Social Relations, sixth edition. Forth
Worth: Holt, Rinehart and Winston, Inc., 1991. [26]P. Koltun, L. Deimel Jr., and J. Perry, “Progress
Report on the Study of Program Reading”, ACM
SIGCSE Bulletin, vol. 15, pp. 168-176, Feb. 1983. [27]O. Laitenberger and C. Atkinson, “Generalizing
Perspective-based Inspection to Handle Object-
Oriented Development Artifacts”, in Proc. ICSE’99.
(To appear.)
[28]T. Lewis, L. Rosenstein, W. Pree, A. Weinand, E.
Gamma, P. Calder, G. Andert, J. Vlissides, K.
Schmucker,Object Oriented Application
Frameworks. Greenwich: Mannings Publication Co.,
1995.
[29]M. Miles, “Qualitative Data as an Attractive
Nuisance: The Problem of Analysis”, Administrative
Science Quarterly, vol. 24, no. 4, pp. 590-601, 1979.
[30]H. Mili, H. Sahraoui, I. Benyahia, “Representing and
Querying Reusable Object Frameworks”, in Proc. of
the Symposium on Software Reusability, May 1997. [31]R. Ott. An Introduction to Statistical Methods and
Data Analysis. Belmont, CA: Duxbury Press, 1993. [32]W. Pree, Design Patterns for Object-Oriented
Software Development. Reading, MA: ACM Press &
Addison-Wesley Publishing Co., 1995.
[33] D. Roberts and R. Johnson, "Patterns for Evolving
Frameworks", in Pattern Languages of Program
Design, R.C. Martin et al. (eds.), Software Patterns
Series, Addison Wesley, 1997.
[34]M. B. Rosson, J. M. Carroll, and R. K. E. Bellamy,
“SmallTalk Scaffolding: A Case Study of Minimalist
Instruction”, in Proc. CHI ‘90, April 1990, pp. 423-
429.
[35]S. Rugaber, S. B. Ornburn, and R. J. LeBlanc, Jr.,
“Recognizing design decisions in programs”, IEEE
Software, vol. 7, pp. 46-54, Jan. 1990.
[36]J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and
W Lorensen, Object-Oriented Modeling and Design.
Englewood Cliffs, NJ: Prentice Hall, 1991.
[37] H. A. Schmid, "Creating Applications from
Components: a Manufacturing Framework Design",
IEEE Software, vol. 13, no. 6, pp.67-75, November
1996.
[38] D. C. Schmidt, "Applying Patterns and Frameworks to
Develop Object-Oriented Communication Software",
in P. Salus, ed., Handbook of Programming
Languages, vol.1, MacMillan Computer Publishing,
1997.
[39]K. Schneider, A. Repenning, “Deceived by Ease of
Use: Using Paradigmatic Applications to Build Visual Design Environments”, in. Proc. of the Symposium on Designing Interactive Systems, Aug. 1995.
[40] C. B. Seaman, V. R. Basili, “An Empirical Study of
Communication in Code Inspection”, in Proc.
ICSE’97, May 1997, pp. 96-106.
[41] F. Shull. Developing Techniques for Using Software
Documents: A Series of Empirical Studies. Ph.D.
thesis, University of Maryland, College Park,
December 1998.
[42] F. Shull, “Reading Techniques for Object-Oriented
Frameworks",
https://www.doczj.com/doc/503895502.html,/projects/SoftEng/ESEG/manu
al/sbr_package/manual.html.
[43]J. Singer and T. C. Lethbridge, “Methods for Studying
Maintenance Activities”, in Proc. of 1st International
Workshop on Empirical Studies of Software
Maintenance, Nov. 1996, pp. 105-110.
[44]S. S?rumg?rd. Verification of Process Conformance
in Empirical Studies of Software Development. Ph.D.
thesis, Norwegian University of Science and
Technology, February 1997.
[45]Software Engineering Laboratory, Recommended
Approach to Software Development, Revision 3.
National Aeronautics and Space Administration,
Software Engineering Laboratory, SEL-81-305, 1992.
[46]Taligent, Inc., The Power of Frameworks. New York:
Addison-Wesley, 1995.
[47]J. Vlissides, Unidraw Tutorial I: A Simple Drawing
Editor. Stanford University, 1991.
[48] A. von Mayrhauser and A. M. Vans, “Industrial
Experience with an Integrated Code Comprehension
Model”, IEEE Software Engineering Journal, pp.
171-182, Sept. 1995.
[49] A. Porter, L. Votta Jr., and V. Basili. “Comparing
Detection Methods for Software Requirements
Inspections: A Replicated Experiment”. IEEE
Transactions on Software Engineering, 21(6): 563-
575, June 1995.
[50] A. Weinand, E. Gamma, and R. Marty, “Design and
Implementation of ET++, a Seamless Object-Oriented Application Framework”, Structured Programming,
vol. 10, no. 2, 1989.
[51]R. Yin, Case Study Research: Design and Methods.
London: Sage Publications, 1994.
[52]Z. Zhang, V. Basili, and B. Shneiderman,
"Perspective-based Usability Inspection: An
Empirical Validation of Efficacy", International
Journal of Empirical Software Engineering, special
issue on Human-Computer Interaction. (To appear.)
一文读懂无线通信技术分类 无线技术正在迅速发展，并在人们的生活中发挥越来越大的作用。而随着无线应用的增长，各种技术和设备也会越来越多，也越来越依赖于无线通信技术。本文盘点下物联网中无线通信主要的技术。 无线通信技术分类美国通信委员会（FCC）分类 2015年，美国通信委员会（FCC，Federal Communications Commission）技术咨询委员会（TAC，Technological Advisory Council）网络安全工作组在一份白皮书中提到了将物联网通信技术分成了以下四类： Mobile/WAN，Wide Area Network - 移动广域网络，覆盖范围大 WAN，Wide Area Network - 广域网，覆盖范围大，非移动技术 LAN，Local Area Network - 局域网，覆盖范围相对较小，如住宅、建筑或园区 PAN，Personal Area Network - 个域网，覆盖范围从几厘米到几米不等主要的无线技术及分类如下表所示： 不知为何，FCC TAC将Sigfox归入了LAN，而LoRaWAN归入了WAN。Sigfox与LoRaWAN 都同属于LPWAN领域中的窄带技术，都是可以广域覆盖。Weightless SIG在LPWAN领域中主推的将会是Weightless-P。NB-IoT也没有列入其中。新的技术在不断出现，也在不断地重塑物联网市场的格局。 KEYSIGHT分类 在KEYSIGHT的一份PPT中《Low Power Wide Area Networks，NB-IoT and the Internet of Things》，将IoT无线技术做了比较详细的划分，如下图所示： 相关术语如下： NFC，Near Field CommunicaTIon - 近场通信
】 第一章绪论 填空 1. 局域网城域网广域网 2. LAN MAN WAN 3. ARPAnet 4. 数据链路层网络层 5. ALOHANET 6. 可以让人们摆脱有线的束缚跟便捷更自由地进行沟通 7. 协议分层 8. 协议 — 9. 应用程序、表示层、会话层、传输层、网络层、链路层 10. 应用层、传输层、网络互连层、主机至网络层 11. MAC协议 单选1-3 D A C 多选 1 AC 2 ABC 判断1-4 T F F F 名词解析： 1、无线体域网是由依附于身体的各种传感器构成的网络 2、无线穿戴网是指基于短距离无线通信技术与可穿戴式计算机技术、穿戴在人体上、具有智能收集人体和周围环境信息的一种新型个域网 3、TCP/IP:P12,即传输控制协议/因特网互联协议又名网络通讯协议是Internet最基本的 、 协议、Internet国际互联网络的基础由网络层的IP协议和传输层的TCP协议组成 4、OSI RM:即开放系统互连参考模型。 简答题： 1、答计算机网络发展过程可分为四个阶段。 第一阶段诞生阶段第二阶段形成阶段第三阶段互联互通阶段第四阶段高速网络技术阶段。如果想加具体事例查p1-2 2、答无线网络从覆盖范围可分为如下三类。第一类系统内部互连/无线个域网比如蓝牙技术红外无线传输技术第二类无线局域网比如基本服务区BSA移动Ad Hoc网络第三类无线城域网/广域网比如蜂窝系统等。 …
3、答从无线网络的应用角度看可以划分出 ①无线传感器网络例如能实时监测、感知和采集各种环境或监测对象的信息并通过无线方式发送到用户终端②无线Mesh网络例如Internet中发送E-mail③无线穿戴网络例如能穿戴在人体上并能智能收集人体和周围环境信息④无线体域网例如远程健康监护中有效地收集信息。 4、答P5不确定WLAN,GPRS,CDMA 5、答P9第一段第三句协议是指通信双方关于如何进行通信的一种约定。举例准确地说它是在同等层之间的实体通信时有关通信规则和约定的集合就是该层协议例如物理层协议、传输层协议、应用层协议。 6、答主要有国际电信标准国际ISO标准Internet标准 1.美国国际标准化协会AN SI 2.电气电子工程师协会(IEEE) 3.国际通信联盟 ITU 4.国际标准化组织ISO ￥ 协会(ISOC)和相关的Internt工程任务组IETF 6.电子工业联合会(EIA)和 相关的通信工业联合会TIA 7、答p13无线网络的协议模型显然也是基于分层体系结构的但是对于不同类型的无线网络说重点关注的协议层次是不一样的。 第二章无线传输基础 填空 1、电磁波 2、FCC 3、全向的 4、天线 5、定向 6、地波 7、衍射 8、快速或慢速平面的 9、Christian Doppler 10、数据 11、信号 | 12、传输 13、模拟 14、ASK FSK PSK 15、扩频技术 16、大于 17、DSSS FHSS THSS 单选 1-5 A C C C D 6-7 A B 多选 1 ACD 2 ABCD 3 BCD 4 ABC 5 AB 6 ABC 判断 1-5 F T T T T 6-10 F T T T F 10-14 F T T T 名词解析： 1、微波波长介于红外线和特高频之间的射频电磁波
智能锁采取哪种无线技术好 随着越来越多家庭正在考虑升级生活安全，那么智能门锁无疑是用户的入门产品之一。首先明确指出，目前智能锁的技术水平使用户更轻松，并且具有一定的安全性，例如可以人脸识别开锁，远程来宾访问开锁，门会在用户进门后，自动上锁，其次，在2020年防疫时期，还能在个人防护和安全方面提供一些保障。 为了能让包括手机在内的其他智能家居设备进行通信，智能锁需要利用3种标准通信协议。今天千家小编就和大家简单分析一下各种协议的区别。 蓝牙 带有无钥匙锁的蓝牙的主要优点之一是，与WiFi相比，它的电池寿命更经济。如果用户在正常情况下使用智能锁，且进入和退出的次数合理，则电池使用蓝牙应可使用一年。 另一个关键优势是蓝牙锁与智能手机无缝集成的方式，而无需任何第三方集线器。如果用户的智能家居需求仅限于无钥匙进入，并且不需要任何其他设备的集线器，那么蓝牙将是明智的选择。如云里物里的MS48SF2C蓝牙模块就广泛应用在蓝牙智能锁中。 WiFi 现在，许多智能锁都具有WiFi连接作为可选的附加功能。只需插入设备，就可以从在线的任何地方远程控制锁，缺点就是网络连接有可能容易断开。 Z-Wave 使用兼容Z-Wave的智能锁，可能需要再购买一个集线器，然后可以转换从锁中接收到的信号，以便路由器可以解释该信号并与其进行交互。 Z-Wave限制了连接范围，因此该连接仅适用于100英尺（约30米）以上。如果锁不至少位于集线器附近，则可以使用多达4个扩展器设备将信号增强到500英尺甚至更高。用户需要根据房屋的布局，以便进行Z-Wave配件的预算考虑。 使用某些Z-Wave锁，也可以通过集线器在应用内访问锁界面，而无需专用的APP应用。 除非计划在入口和出口系统之外的智能家居中运行多个设备，否则花钱购买具有Z-Wave功能的智能锁可能不值得。本文来源网络。
生活中的无线通信 （公选课）结课论文 2014 — 2015学年第一学期 题目：超宽带（UWB）技术 专业班级：海洋13-1班 学号：0116 姓名：张然 指导老师：梁娜 日期：2014-12-12 摘要 本文主要对UWB通信技术进行简要的阐释。首先对UWB的技术背景、基本概念和特点进行介绍。技术应用范围脉冲无线电技术技术解决方案无载波脉冲方案单载波DS-CDMA方案 关键词：USB；脉冲；调制；家庭 目录 1 前言 (4) 1 UWB基本概念 (5) 2 UWB的主要特点及其应用 (5) 3 UWB的发展现状 (6) 4 关键技术，研究热点 (7) 4.1脉冲信号的产生 (7) 4.2调制方式 (8) (8) (8) 4.3收发机的设计 (9) 4.4中国对UWB电磁兼容性研究 (9) 5 家庭无线通信是UWB的发展方向之一 (10) 参考文献 (11)
1 前言 目前一种新的无线通信技术引起了人们的广泛关注，这就是所谓"UWB(Ultra WideBand，超宽带无线技术)"技术。正如其名称一样，UWB技术是一种使用1GHz 以上带宽的最先进的无线通信技术，被认为是未来五年电信热门技术之一。但是UWB不是一个全新的技术，它实际上是整合了业界已经成熟的技术如无线USB、无线1394等连接技术，本文就是对UWB做一简单的介绍。 1 UWB基本概念 超宽带（Ultra-wideband,UWB）技术起源于20世纪50年代末，此前主要作 为军事技术在雷达等通信设备中使 对高速无线通信提出了更高的要求， 超宛带技术又被重新提出，并倍受关 注。UWB是指信号带宽大于500MHz或 者是信号带宽与中心频率之比大于 25%。与常见的通信方式使用连续的载波不同，UWB采用极短的脉冲信号来传送信息，通常每个脉冲持续的时间只有几十皮秒到几纳秒的时间。这些脉冲所占用的带宽甚至高达几GHz，因此最大数据传输速率可以达到几百Mbps。在高速通信的同时，UWB设备的发射功率却很小，仅仅是现有设备的几百分之一，对于普通的非UWB接收机来说近似于噪声，因此从理论上讲，UWB可以与现有无线电设备共享带宽。所以，UWB是一种高速而又低功耗的数据通信方式，它有望在无线通信领域得到广泛的应用。目前，Intel、Motorola、Sony等知名大公司正在进行UWB无线设备的开发和推广。 2 UWB的主要特点及其应用 鉴于UWB信号是持续时间非常短的脉冲串，占用带宽大，因此它有一些十分 独特的优点和用途。在通信领域，UWB可以提供高速率的无线通信。在雷达方面，
无线通信技术各自的特点和相互比较 目前使用较广泛的近距无线通信技术是蓝牙(Bluetooth)，无线局域网802.11(Wi-Fi)和红外数据传输(IrDA)。同时还有一些具有发展潜力的近距无线技术标准，它们分别是：Zigbee、超宽频(Ultra WideBand)、短距通信(NFC)、WiMedia、GPS、DECT、无线1394和专用无线系统等。它们都有其立足的特点，或基于传输速度、距离、耗电量的特殊要求;或着眼于功能的扩充性;或符合某些单一应用的特别要求;或建立竞争技术的差异化等。但是没有一种技术可以完美到足以满足所有的需求。 1、蓝牙技术 bluetooth技术是近几年出现的，广受业界关注的近距无线连接技术。它是一种无线数据与语音通信的开放性全球规范，它以低成本的短距离无线连接为基础，可为固定的或移动的终端设备提供廉价的接入服务。 蓝牙技术是一种无线数据与语音通信的开放性全球规范，其实质内容是为固定设备或移动设备之间的通信环境建立通用的近距无线接口，将通信技术与计算机技术进一步结合起来，使各种设备在没有电线或电缆相互连接的情况下，能在近距离范围内实现相互通信或操作。其传输频段为全球公众通用的2.4GHz ISM 频段，提供1Mbps的传输速率和10m的传输距离。 蓝牙技术诞生于1994年，Ericsson当时决定开发一种低功耗、低成本的无线接口，以建立手机及其附件间的通信。该技术还陆续获得PC行业业界巨头的支持。1998年，蓝牙技术协议由Ericsson、IBM、Intel、NOKIA、Toshiba等5家公司达成一致。 蓝牙协议的标准版本为802.15.1，由蓝牙小组(SIG)负责开发。802.15.1的最初标准基于蓝牙1.1实现，后者已构建到现行很多蓝牙设备中。新版802.15.1a 基本等同于蓝牙1.2标准，具备一定的QoS特性，并完整保持后向兼容性。 但蓝牙技术遭遇了最大的障碍是过于昂贵。突出表现在芯片大小和价格难以下调、抗干扰能力不强、传输距离太短、信息安全问题等等。这就使得许多用户不愿意花大价钱来购买这种无线设备。因此，业内专家认为，蓝牙的市场前景取决于蓝牙价格和基于蓝牙的应用是否能达到一定的规模。 2、Wi-Fi技术 Wi-Fi(Wireless Fidelity,无线高保真)也是一种无线通信协议，正式名称是IEEE802.11b，与蓝牙一样，同属于短距离无线通信技术。Wi-Fi速率最高可达11Mb/s。虽然在数据安全性方面比蓝牙技术要差一些，但在电波的覆盖范围方面却略胜一筹，可达100 m左右。 Wi-Fi是以太网的一种无线扩展，理论上只要用户位于一个接入点四周的一定区域内，就能以最高约11Mb/s的速度接入Web。但实际上，如果有多个用户同时通过一个点接入，带宽被多个用户分享，Wi-Fi的连接速度一般将只有几百kb/s的信号不受墙壁阻隔，但在建筑物内的有效传输距离小于户外。 WLAN未来最具潜力的应用将主要在SOHO、家庭无线网络以及不便安装电缆的建筑物或场所。目前这一技术的用户主要来自机场、酒店、商场等公共热点场所。Wi-Fi技术可将Wi-Fi与基于XML或Java的Web服务融合起来，可
【福建信息化局】无线生活零距离—搜赢第三期无线生活零距离，你不可不知道的事。 福建省信息化局的"搜赢"答题有奖活动第三期已出炉。“搜赢”第一期、第二期在大家踊跃的答题后，信息化局不负众望的给予活动最大的支持，活动奖品越来越给力!活动奖品有苹果笔记本、平板电脑、数码相机、打印机、护眼灯、眼部按摩器、计步器、计算器等，3000多份。最终大奖落入谁家，谁“搜赢”，谁知道! 活动时间：2012年5月17日—9月30日 官方网站 http：//https://www.doczj.com/doc/503895502.html,/zhuanti/syhdzt/ 附带问题及答案 1. 无线电对讲机最早在什么时候得到应用?从设计技术上无线对讲机分为哪几类? 无线电对讲机在二十世纪三十年代就开始得到应用。无线电对讲机在设计技术方面，可分为采用模拟通信技术设计的模拟对讲机(也称为传统对讲机)，以及采用数字技术进行设计的数字对讲机。 2. 我国规定从那一年模拟制式的对讲机将推出市场? 根据工信部部署，模拟制式的对讲机已于2010年底停止新型号核准，2015年“模拟机”将全部退出市场。 3. 我国第一个数字对讲机芯片何时、何地诞生? 答：2011年，在福建无线电管理部门的积极推动下，泉州对讲机产业在“模转数”研 发取得的突破，福建联拓科技有限公司成功地开发出一款具有自主知识产权的LT1801A芯片，成为我国第一个数字对讲机芯片。 4.我国何时宣布开放民用对讲机市场?免执照、免费使用的对讲机需要具备什么条件? 中国信产部于2001年12月6日宣布开放民用对讲机市场。凡发射功率不大于0.5瓦，工作于400兆频段的对讲机可以免执照、免费使用。 5. 福建省泉州市作为著名的无线电对讲机产地，提出什么样的发展目标?在所出台的政策意见中将从哪些方面促进产业的发展? 发展目标：力争至2015年，数字对讲机产业产值达100亿元，年均增长38.0%，培育2家以上上市公司。 在《泉州市人民政府关于加快推进泉州数字对讲机产业发展的若干意见》中，提出的发展举措：
心得体会 计算机技术的突飞猛进让我们对现实应用有了更高千兆网络技术刚刚与我们会面，无线网络技术又悄悄地逼近。不可否认，性能与便捷性始终是IT技术发展的两大方向标，而产品在便捷性的突破往往来得更加迟缓，需要攻克的技术难关更多，也因此而更加弥足珍贵。历史的脚印说到无线网络的历史起源，可能比各位想象得还要早。无线网络发展史上的第一块里程碑是1997年6月的 IEEE802.11标准的出台，虽然IEEE802.11标准在当时并没有引起革命性的网络变革，但802.11标准提供的“一点对多点接入”、“点对点中继”等工作模式提供了一种替代有线网络的高效高速的方案，为无线网技术的不断发展奠定了基础，在此后的被称为Wi-Fi的802.11b标准统一无线网络标准更是功不可没。 随着信息技术与信息产业飞速发展,人们对网络通信的要求也不断提高, 无线电技术能实现远距离的通信,即使在室内或相距咫尺的地方, 无线电也可发挥巨大作用。于是无线网络技术随之应运而生, 它克服了传统网络技术的不足, 真正体现了5W的要求。由于网络一般分为局域网和广域网（即因特网）两种,但本文将着重对局域网部分进行阐述。无线网络技术主要包括IEEE802. 11、https://www.doczj.com/doc/503895502.html,N2 、HomeRF、蓝牙等。它使人们彻底摆脱了线缆的束缚,在整个区域内实现随时随地的无线连接。 虽然目前大多数的网络都仍旧是有线的架构，但是近年来无线网络的应用却日渐增加。在学术界、医疗界、制造业、仓储业等，无线网络扮演着越来越重要的角色。特别是当无线网络技术与Internet相结合时，其迸发出的能力是所有人都无法估计的。其实，我们也不能完全认为自己从来没有接触过无线网络。从概念上理解，红外线传输也可以认为是一种无线网络技术，只不过红外线只能进行数据传输，而不能组网罢了。此外，射频无线鼠标、WAP手机上网等都具有无线网络的特征。 无线网络技术的发展最终需要在应用层面上得到用户的充分认可。时至今日，无线传输标准可谓百家争鸣，除了最容易想到的无线局域网，用户也将能在不同的领域应用这些新技术，包括硬件设备与应用软件两方面。目前，有三种方式可供选择。红外线无线传输利用红外线波段的电磁波来传送数据，通讯距离较短，传输速率最快可达16Mbps。目前广泛使用的电视机或VCD机等家电遥控器几乎都采用红外线传输技术，只不过此时是窄带红外技术。蓝牙有着全球开放的自由频段2.4GHz，有效传输速度为721kb/s，数据传输速度1Mbps，2.0版本的蓝牙技术甚至达到3Mbps。WiFi即“无线相容性认证”，目前已出现多个标准。802.11b标准在理想情况下的传输速率为11Mbps，802.11g标准的理论传输速率也达到54Mbps。但在实际使用环境中，它们的传输速率也只有理论速度的一半左右。然而即便如此，用于音频传输也已经绰绰有余，此时可以很好地摆脱对线缆的依赖。但是，有些发烧音响爱好者怀疑无线传输是否能够保证音质。其实，无线传输的表现毫不逊色。现在市场上几款名家无线家庭影院产品，无论是红外线无线、蓝牙无线传输，还是WiFi无线技术方式，都有着很高的无线技术含量，并且都运用了自家的独门技术，无线传输的表现能力相当出色，能够确保连续和及时地传输数字影音讯号，不会出现讯号延迟停顿现象，音质清晰完美。在WiFi
电磁场与无线技术专业职业生涯规划范文 电磁场与无线技术专业毕业生就业实行双向选择，可选择科研机构、工业部门等企事业单位从事设计制造、科技开发、应用研究和科研、教学及行政管理等方面的工作。下面是给大家带来的电磁场与无线技术专业职业生涯规划范文，欢迎阅读。 一、前言当我没进大学之前，我以为上大学就意味着解放，没有家长的束缚，没有老师的逼迫，没有学习的压力，但是不久我发现自己错了。高中的努力是为了考上重点大学，但重点大学的文凭仅仅是进入人才招聘市场基本的条件而已，就像高档写字楼门口写的“衣冠不整者不能入内”一样。我国高校扩招以来，每年都有大批毕业生毕业，再加上往年没有找到工作的大学生，就业形势非常严峻。虽然我们学校在“211”、“985”工程之内，也许同样是重点大学的学生，但企业不一定会选择我，因为我的户口。现实不会和我们想象的一样，它可能会不公，它可能会残酷; 但我相信，能力是重要的，无论我走到哪，我也不会害怕，都可以从新再来，因为我有能力。 不是任何你想得倒的东西就会是你的，没有人会像父母一样那么宠惯自己。能力也是一样的，它的形成必须要有经验，要能忍受，要与人交流，要知道思考和分析，要能把握住自己。刚进大学，我经历很多打击，没有能入选院学生会，没有成为班干部……外表、说话、做事好像什么都不如别人。所以我下定决心好好做自己，用心去把握每一个机会，让自己学会成长，使自己拥有能力。但怎么才能真正做到这些，怎么才能找到一个需要自己努力的方向，我仍然有些迷茫。
直到这学期上了大学生职业生涯规划课以后，我才开始对自己的大学生活、工作方向、人生规划有一些感觉，我才会认真地寻找我的价值与我可以和应该做的事情，我才懂得留意身边的每一个人、每一个细节来得到更多的机会。首先，大学生职业生涯规划课让我看到自己深处危机中，如果还不觉醒、还不给人生增加价值，那未来就将布满荆棘，人生会失去它应有的光彩。其次，大学生职业生涯规划课让我了解到了一些坚持不懈、努力奋斗、用心投入的人，他们能拥有今天的成就和前途的美好是因为他们用脑子思考、用双手实干积累出来的，而不是运气与无目的的忙碌; 也让我相信社会存在着一种向上流动的机制，只要我付出，就一定能有所收获。第三，大学生职业生涯规划课让我明白了社会与企业所需的人才类型，比如有基础知识（专业基础、文化底蕴）、能力（学习新事物的能力、与人交往与沟通的能力、随机应变的能力、知识运用能力）、素质（忠心、诚实、守信、互助、协作、大胆）等。第四，我会根据我掌握的信息来制定我的职业生涯规划，因为它可以使我拥有明确的目标，使我在实现理想的过程中少走弯路，使我比别人更懂得寻找新的机会、增加有用的经验，使我不会因我的无知而后悔。 二、自我分析人的一生在不断的根据他人和已经做过的事情来认识自己，有时会因为做错了事物而讨厌自己，有时会充满理性和勇气去改变自己。我认为自己总的性格具有两面性：在自己平常的生活中，喜欢安静，不太爱说话，总爱做自己应该做的事情; 在需要与人交往的时候，我会很外向、很开朗，总是喜欢笑。曾经做过一个职业测评，它说我的性格是管理者类型，特征是富有责任感、工作效率高、关注结果、性格开朗、善于社交、
1.1如何理解计算机网络在现代社会的作用？ 答：在现代社会生产生活中，网络技术实现信息的互通和流动，高速完善的网络能使信息更快捷、准确的传输，发挥强大的作用。网络已成为信息社会的技术命脉和知识经济的发展基础。 1.2请给出计算机网络的整体结构。 答：参考ISO/OSI模型以及TCP/IP模型。 1.3目前的骨干网络大多为光纤传输，部分城市实现了光纤到户，为此是否可以完全用光纤取代所有其他类型的网络？试分析。 答：不能取代所有其他类型的网络。由于光纤属于有线网络的范畴，无法取代一些只适用于无线网络的应用，如无线传感器网络（WSN）。 1.4 为什么网络协议栈都以分层形式实现？各层主要完成哪些功能？ 答：网络体系结构是一个复杂的系统，所以采用结构化的方法，将其分解为若干层次设置相应的协议，便于维护和修改。 各层次主要功能参考ISO/OSI模型以及TCP/IP模型。 1.6试分析和比较无线网络和有线网络，可以从传输方式、组网结构等方面进行比较。答：有线通信的开通必须架设电缆，或挖掘电缆沟或架设架空明线；而架设无线链路则无需架线挖沟，线路开通速度快，将所有成本和工程周期统筹考虑。无线扩频的投资是相当节省的。 有线通信的质量会随着线路的扩展而急剧下降，如果中间通过电话转接局，则信号质量下降更快，到4、5公里左右已经无法传输高速率数据，或者会产生很高的误码率，速率级别明显降低，而对于无线扩频通信方式，50公里内几乎没有影响，一般可提供从64K到2M 的通信速率。 有线通信铺设时需挖沟架线，成本投入较大，且电缆数量固定，通信容量有限；而无线扩频则可以随时架设，随时增加链路，安装、扩容方便。 1.9为什么现阶段IPv6必须与IPv4共存，而不是直接取代？它们各有什么样的特点？ 答：由于现阶段大部分互联网用户使用IPv4，若直接升级到IPv6，必须将互联网上所有节点都进行修改，实施起来比较困难，所以使用IPv4/IPv6的形式进行过度，不远的将来，IPv6将会得到全面使用，最终取代IPv4。 IP是TCP/IP协议族中网络层的协议，是TCP/IP协议族的核心协议。目前IP协议的版本是IPv4，发展至今已经使用了30多年。IPv4的地址位数为32位，也就是最多有2的32次方的电脑可以联到Internet上。 IPv6是下一版本的互联网协议，也可以说是下一代互联网的协议，IPv6除了一劳永逸地解决了地址短缺问题以外，还考虑了在IPv4中解决不好的其它问题，主要有端到端IP连接、服务质量（QoS）、安全性、多播、移动性、即插即用等。
几种无线通信技术的比较 摘要:随着电子技术、计算机技术的发展,近年来无线通信技术蓬勃发展,出现了各种标准的无线数据传输标准,它们各有其优缺点和不同的应用场合,本文将目前应用的、无线通信方式进行了分析对比,并总结和预见了它们今后的发展方向。 关键词:Zigbee Bluetooth UWB Wi-Fi NFC Several Wireless Communications Technology Comparison Abstract:As the development of electronic technology,computer technology, wireless communication technology have a rapid development in recent years,emerged wireless data transmission standard,they have their advantages and disadvantages,and different applications,the application of various wireless communication were analyzed and compared,and summarized and foresee their future development. 一．几种无线通讯技术 （一）ZigBee 1.简介： Zigbee是基于IEEE802.15.4标准的低功耗个域网协议。根据这个协议规定的技术是一种短距离、低功耗的无线通信技术。其特点是近距离、低复杂度、自组织、低功耗、低数据速率、低成本。主要适合用于自动控制和远程控制领域，可以嵌入各种设备。 ZigBee是一种高可靠的无线数传网络，类似于CDMA和GSM网络。ZigBee数传模块类似于移动网络基站。通讯距离从标准的75m到几百米、几公里，并且支持无限扩展。ZigBee是一个由可多到65000个无线数传模块组成的一个无线数传网络平台，在整个网络范围内，每一个ZigBee网络数传模块之间可以相互通信，每个网络节点间的距离可以从标准的75m无限扩展。与移动通信的CDMA网或GSM网不同的是，ZigBee网络主要是为工业现场自动化控制数据传输而建立，因而，它必须具有简单，使用方便，工作可靠，价格低的特点。而移动通信网主要是为语音通信而建立，每个基站价值一般都在百万元人民币以上，而每个ZigBee―基站‖却不到1000元人民币。每个ZigBee网络节点不仅本身可以作为监控对象，例如其所连接的传感器直接进行数据采集和监控，还可以自动中转别的网络节点传过来的数据资料。除此之外，每一个Zigbee网络节点（FFD）还可在自己信号覆盖的范围内，和多个不承担网络信息中转任务的孤立的子节点（RFD）无线连接。
无线网络技术及发展趋势 一、引言 （一）调查背景 随着中国经济的高速发展和国民生活水平的提到，人们的生活节奏会越走越快，加上无线通信技术的广泛应用，传统局域网络已经越来越不能满足人们的需求，于是无线网络应运而生，且发展迅速。尽管目前无线网还不能完全独立于有线网络，但近年来无线网的产品逐渐走向成熟，正以它优越的灵活性和便捷性在网络应用中发挥日益重要的作用。无线网是无线通信技术与网络技术相结合的产物。从专业角度讲，无线网就是通过无线信道来实现网络设备之间的通信，并实现通信的移动化、个性化和宽带化。通俗地讲，无线就是在不采用网线的情况下，提供网络的互联功能。 广阔的应用前景、广泛的市场需求以及技术上的可实现性，促进了无线局域网技术的完善和产业化。已经商用化的802.11b网络也正在证实这一点。随着802.11a网络的商用和其他无线局域网技术的不断发展，无线局域网将迎来发展的黄金时期。 （二）调查内容 针对无线网是无线通信技术与网络技术相结合的产物、无线网目前在市场上广泛的应用这2点，所以我主要的调查对象为无线网的主要特点、优缺点，以及市场上应用比较广泛的技术做调查。另外由于人们的广泛使用我针对无线网的安全问题和未来的发展趋势作出相应的调查。 (三)调查方法 通过查询专业文献、网络资料以及实际的市场调查报告的方法，尽可能详细、准确的阐述问题。 二、关于无线网特点和常用无线技术以及安全性问题的概述 （一）、无线网的特点及应用 1、无线网络概述 无线网络技术涵盖的范围很广，既包括允许用户建立远距离无线连接的全球语音和数据网络，也包括为近距离无线连接进行优化的红外线技术及射频技术。通常用于无线网络的设备包括便携式计算机、台式计算机、手持计算机、个人数字助理 (PDA)、移动电话、笔式计算机和寻呼机。无线技术用于多种实际用途。例如，手机用户可以使用移动电话查看电子邮件。使用便携式计算机的旅客可以通过安装在机场、火车站和其他公共场所的基站连接到 Internet。在家中，用户可以连接桌面设备来同步数据和发送文件。
无线网络技术导论课后习题 和答案解析 -标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
第一章 名词解释 1、无线体域网：无线局域网是由依附于身体的各种传感器构成的网络。 2、无线穿戴网：是指基于短距离无线通信技术与可穿戴式计算机技术、穿戴在人体上、具有智能收集人体和周围环境信息的一种新型个域网。 3、TCP/IP:P12,即传输控制协议/因特网互联协议，又名网络通讯协议，是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。 4、OSI RM:即开放系统互连参考模型。 第一章简答 1、简述计算机网络发展的过程。 答：计算机网络发展过程可分为四个阶段。 第一阶段：诞生阶段；第二阶段：形成阶段；第三阶段：互联互通阶段；第四阶段：高速网络技术阶段。（如果想加具体事例查p1-2） 2、无线网络从覆盖范围可以分成哪些类？请适当举例说明。 答：无线网络从覆盖范围可分为如下三类。第一类：系统内部互连/无线个域网，比如： 蓝牙技术，红外无线传输技术；第二类：无线局域网，比如：基本服务区BSA，移动Ad Hoc网络；第三类：无线城域网/广域网，比如：蜂窝系统等。3、从应用的角度看，无线网络有哪些？要求举例说明。 答：从无线网络的应用角度看，可以划分出： ①无线传感器网络，例如能实时监测、感知和采集各种环境或监测对象的信息并通过无线方式发送到用户终端； ②无线Mesh网络，例如Internet中发送E-mail； ③无线穿戴网络，例如能穿戴在人体上并能智能收集人体和周围环境信息； ④无线体域网，例如远程健康监护中有效地收集信息。 4、现在主流的无线网络种类有哪些？ 答：P5（不确定）WLAN,GPRS,CDMA ，wifi 5、什么是协议？请举例说明。 答：P9第一段第三句；协议是指通信双方关于如何进行通信的一种约定。举例：准确地说，它是在同等层之间的实体通信时，有关通信规则和约定的集合就是该层协议，例如物理层协议、传输层协议、应用层协议。 6、与网络相关的标准化有哪些？ 答：主要有：国际电信标准，国际ISO标准，Internet标准 1.美国国际标准化协会（ANSI） 2.电气电子工程师协会(IEEE) 3.国际通信联盟（ITU） 4.国际标准化组织（ISO）协会(ISOC)和相关的Internt工程任务组（IETF） 6.电子工业联合会(EIA)和相关的通信工业联合会（TIA） 7、无线网络的协议模型有哪些特点？
几种短距无线通信技术的对比和应用前景 [导读]当我们谈及无线通信的时候，大家可能已经快速的联想到各种各样的无线设备，比如手机、无线路由器、遥控器等。这已经无处不在，很可能你现在看这篇文章用的就是无线设备。但还有更无处不在的，那就是无线信号，这也是经常被大家忽略的。其实如果它能被肉眼看见，你会真觉得简直浸在其中。其实它们已经应用到家居、办公、工业等诸多领域，下面我们通个对比以下几种不同的无线技术谈谈其应用前景。
目前使用较广泛的近距无线通信技术有蓝牙(Bluetooth)、无线局域网802.11(Wi-Fi)和红外数据传输(IrDA)。同时还有一些具有发展潜力的近距无线技术标准，如Zigbee、超宽频(Ultra WideBand)、5G Wi-Fi、433MHz、近场通信(NFC)、DECT等等。 1.蓝牙 蓝牙技术是一种无线数据与语音通信的开放性全球规范，其实质内容是为固定设备或移动设备之间的通信环境建立通用的近距无线接口，将通信技术与计算机技术进一步结合起来，使各种设备在没有电线或电缆相互连接的情况下，能在近距离范围内实现相互通信或操作。其传输频段为全球公众通用的 2.4GHz ISM 频段，提供1Mbps的传输速率和10m的传输距离。
但蓝牙技术遭遇了最大的障碍是过于昂贵。突出表现在芯片大小和价格难以下调、抗干扰能力不强、传输距离太短、信息安全问题等等。这就使得许多用户不愿意花大价钱来购买这种无线设备。因此，业内专家认为，蓝牙的市场前景取决于蓝牙价格和基于蓝牙的应用是否能达到一定的规模。但目前蓝牙在手持移动设备短距离传输上还占很大的市场份额。 2.ZigBee Zigbee是基于IEEE802.15.4标准的低功耗个域网协议。根据这个协议规定的技术是一种短距离、低功耗的无线通信技术。主要特点包括低功耗、低成本、低速率、支持大量节点、支持多种网络拓扑、低复杂度、快速、可靠、安全。ZigBee 网络中的设备可分为协调器(Coordinator)、汇聚节点(Router)、传感器节点(EndDevice)等三种角色。
几种主流无线通信技术 的比较 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]
几种主流无线通信技术的比较 来源：德国易能森有限公司供稿 [导读]近几年，随着面向家庭控制及自动化短距离无线技术的发展，家庭智能化所带来的机遇正成为现实。轻家居相比传统智能家居很明显的两个优势就是在易安装和易交互。在已出现的各种短距离无线通信技术中， EnOcean、Zigbee，Z-Wave和Bluetooth（蓝牙）是当前连接智能家居产品的主要手段。 关键词： 近几年，随着面向家庭控制及自动化短距离无线技术的发展，家庭智能化所带来的机遇正成为现实。轻家居相比传统智能家居很明显的两个优势就是在易安装和易交互。在已出现的各种短距离无线通信技术中， EnOcean、Zigbee，Z-Wave和Bluetooth（蓝牙）是当前连接智能家居产品的主要手段。 EnOcean EnOcean无线通信标准被采纳为国际标准“ISO/IEC 14543-3-10”，这也是世界上唯一使用能量采集技术的无线国际标准。EnOcean能量采集模块能够采集周围环境产生的能量，从光、热、电波、振动、人体动作等获得微弱电力。这些能量经过处理以后，用来供给EnOcean超低功耗的无线通讯模块，实现真正的无数据线，无电源线，无电池的通讯系统。 EnOcean无线标准ISO/IEC14543-3-10使用868MHz，902MHz，928MHz和315MHz 频段，传输距离在室外是300 米，室内为30米。 Zigbee Zigbee是基于标准的低功耗个域网协议。根据这个协议规定的技术是一种短距离、低功耗的无线通信技术。其特点是近距离、低复杂度、自组织、低功耗、低数据速率、低
无线网络技术简述与应用案例
无线网络技术简述与应用案例 年级：11计算机科学与技术2班 姓名：范挺鑫 学号： 201141402204
1.2无线网络分类 无线通信网络根据应用领域可分为： ●无线个域网(WPAN)：在小范围内相互连接数个装置所形成的无线网络，通常是个人可及的范围内。例如蓝牙连接耳机及膝上电脑，ZigBee也提供了无线个人网的应用平台。 ●无线局域网(WLAN)：相当便利的数据传输系统，它利用射频（Radio Frequency； RF）的技术，取代旧式碍手碍脚的双绞铜线（Coaxial）所构成的局域网络，使得无线局域网络能利用简单的存取架构让用户透过它，达到“信息随身化、便利走天下”的理想境界。 ●无线区域网(WRAN)：基于认知无线电技术，IEEE802.22定义了适用于WRAN系统的空中接口。WRAN系统工作在47MHz～910MHz高频段/超高频段的电视频带内的，由于已经有用户(如电视用户) 占用了这个频段，因此802.22设备必须要探测出使用相同频率的系统以避免干扰。 ●无线城域网(WMAN)：主要用于解决城域网的接入问题，覆盖范围为几千米到几十千米，除提供固定的无线接入外，还提供具有移动性的接入能力，包括多信道多点分配系统(Multichannel Multipoint Distribution System，MMDS)、本地多点分配系统(Local Multipoint Distribution System，LMDS)、IEEE 802.16和ETSI HiperMAN(High Performance MAN，高性能城域网)技术。 ●蜂房移动通信网(WWAN)：无线广域网。WWAN技术是使得笔记本电脑或者其他的设备装置在蜂窝网络覆盖范围内可以在任何地方
短距离无线通信技术比较 近年来，各种无线通信技术迅猛发展，极大的提供了人们的工作效率和生活质量。然而，在日常生活中，我们仍然被各种电缆所束缚，能否在近距离范围内实现各种设备之间的无线通信？ 纵观目前发展较成熟的几大无线通信技术主要有ZigBee;蓝牙(Bluetooth)，红外(IrDA)和无线局域网802.11(Wi-Fi)。 同时还有一些具有发展潜力的近距离无线技术标准，它们分别是：超宽频(UltraWideBand)、短距离通信(NFC)、WiMedia、GPS、DECT、无线139和专用无线系统等。它们都有各自立足的特点，或基于传输速度、距离、耗电量的特殊要求; 或着眼于距离的扩充性;或符合某些单一应用的特殊要求;或建立竞争技术的差异优化等。但没有一种技术完美到可以满足所有的要求。 蓝牙技术 蓝牙技术诞生于1994年，Ericsson当时决定开发一种低功耗、低成本的无线接口，以建立手机及其附件间的通信。能在近距离范围内实现相互通信或操作。其传输频段为全球公众通用的2.4GHz ISM频段，提供1Mbps的传输速率和10m的传输距离。该技术还陆续获得PC行业业界巨头的支持。
1998年，蓝牙技术协议由Ericsson、IBM、Intel、NOKIA、Toshiba等五家公司达成一致。蓝牙协议的标准版本为802.15.1，由蓝牙小组(SIG)负责开发。802.15.1的最初标准基于1.1实现，后者以构建到现行很多蓝牙设备中。新版802.15.1a基于等同于蓝牙1.2标准，具备一定的Qos特性，并完整保持后项兼容性。 但蓝牙技术遭遇最大的障碍在于传输范围受限，一般有效的范围在10米左右，抗干扰能力不强、信息安全问题等问题也是制约其进一步发展和大规模应用的主要因素。因此业内专家认为蓝牙的市场前景取决于蓝牙能否有效地解决上述制约难题。 IrDA技术 IrDA是一种利用红外线进行点对点通信的技术，是第一个实现无线个人局域网(PAN)的技术。目前它的软硬件技术都很成熟，在小型移动设备，如：PDA、手机上广泛使用。起初，采用IrDA标准的无线设备仅能在1m范围内以115.2kb/s速率传输数据，很快发展到4Mb/s以及16Mb/s的速率。 IrDA的主要优点是无需申请频率的使用权，因而红外通信成本低廉。并且还具有移动通信所需的体积小、功能低、连接方便、简单易用的特点。此外，红外线发射角度较小，传输上安全性高。 IrDA的不足在于它是一种视距传输，两个相互通信的设备之间必须对准，中间不能被其它物体阻隔，因而该技术只能用于2台设备之间的连接。而蓝牙就没有此限制，且不受
无线技术扫盲贴（连载，从基础到测试） 一：为什么要采用无线 这个问题好比在问人类为什么在不断发展生产力，看过《上帝也疯狂》的人都知道，人类多可笑，为了让生活过的更加惬意，于是去创造更高的科技生产力，去解放更多的体力劳动，殊不知，为了这种惬意，投入了多少精力物力财力，生活也日益的复杂化了（个人牢骚而已），但是不可否认，即使如此，社会仍然一如既往的发展。 为了让计算机器化，人类发明了计算机，为了让计算机能处理更多的事情，于是在计算机的基础上发明了网络，产生了操作系统，产生了各种计算机的衍生类的发明。在今天电脑普及的时代，计算机更是深入到生活的各种场所。但是固定的工作环境已经无法满足为了更高的生活追求，更高的惬意生活的需要。人们需要移动，更需要在移动中与世界联系，为社会发展服务。 移动中打电话，于是手机出现了；移动中扫描超市货品，于是移动扫描终端出现了；移动中上网，于是无线AP就出现了。无线的其他利用还有： l难以布线的场所，或者有线布线成本远高于无线。 l频繁变化的工作环境，银行，公安，军事领域等。 l需要流动工作的区域，除了刚才说的超市，医院，机场等。 l远距离的信息传输：监控，森林防火。 想对于传统的有线来说，无线有一些优势：经济节约。易于扩展。使用便捷。当然也有有线所没有的优势：速率更高，安全性更高，技术更成熟。 本文主要探讨无线AP的技术以及测试AP中应用到的测试方法与测试工具。 二：无线的协议标准 大家在实际享受无线带给我们的便捷的时候，有没有注意到一些细节呢?如笔记本里的无线网卡的型号中，经常会有11b或11g字样。无线路由器上有的也标示支持11b/g甚至有的是11 b/g/n, 有的还支持11a。802.11（11是IEEE组织里的第11小组）是IEEE最初制定的一个无线局域网标准，主要用于解决办公室局域网和校园网中用户与用户终端的无线接入，业务主要限于数据存取，速率最高只能达到2Mbps。由于它在速率和传输距离上都不能满足人们的需要，因此，IEEE小组又相继推出了802.11b和802.11a两个新标准。
无线网络技术导论课后习题和 答案解析 标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
第一章 名词解释 1、无线体域网：无线局域网是由依附于身体的各种传感器构成的网络。 2、无线穿戴网：是指基于短距离无线通信技术与可穿戴式计算机技术、穿戴在人体上、具有智能收集人体和周围环境信息的一种新型个域网。 3、TCP/IP:P12,即传输控制协议/因特网互联协议，又名网络通讯协议，是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。 4、OSI RM:即开放系统互连参考模型。 第一章简答 1、简述计算机网络发展的过程。 答：计算机网络发展过程可分为四个阶段。 第一阶段：诞生阶段；第二阶段：形成阶段；第三阶段：互联互通阶段；第四阶段：高速网络技术阶段。（如果想加具体事例查p1-2） 2、无线网络从覆盖范围可以分成哪些类请适当举例说明。 答：无线网络从覆盖范围可分为如下三类。第一类：系统内部互连/无线个域网，比如： 蓝牙技术，红外无线传输技术；第二类：无线局域网，比如：基本服务区BSA，移动Ad Hoc网络；第三类：无线城域网/广域网，比如：蜂窝系统等。3、从应用的角度看，无线网络有哪些要求举例说明。 答：从无线网络的应用角度看，可以划分出： ①无线传感器网络，例如能实时监测、感知和采集各种环境或监测对象的信息并通过无线方式发送到用户终端； ②无线Mesh网络，例如Internet中发送E-mail； ③无线穿戴网络，例如能穿戴在人体上并能智能收集人体和周围环境信息； ④无线体域网，例如远程健康监护中有效地收集信息。 4、现在主流的无线网络种类有哪些 答：P5（不确定）WLAN,GPRS,CDMA ，wifi 5、什么是协议请举例说明。 答：P9第一段第三句；协议是指通信双方关于如何进行通信的一种约定。举例：准确地说，它是在同等层之间的实体通信时，有关通信规则和约定的集合就是该层协议，例如物理层协议、传输层协议、应用层协议。 6、与网络相关的标准化有哪些 答：主要有：国际电信标准，国际ISO标准，Internet标准 1.美国国际标准化协会（ANSI） 2.电气电子工程师协会(IEEE) 3.国际通信联盟（ITU） 4.国际标准化组织（ISO）协会(ISOC)和相关的Internt工程任务组（IETF） 6.电子工业联合会(EIA)和相关的通信工业联合会（TIA） 7、无线网络的协议模型有哪些特点