By Topic

Software, IEEE

Issue 2 • Date March-April 2006

Filter Results

Displaying Results 1 - 25 of 28
  • [Front cover]

    Page(s): c1
    Save to Project icon | Request Permissions | PDF file iconPDF (626 KB)  
    Freely Available from IEEE
  • [Inside front cover]

    Page(s): c2
    Save to Project icon | Request Permissions | PDF file iconPDF (690 KB)  
    Freely Available from IEEE
  • Congratulations to the 2005 CSDPs

    Page(s): 1
    Save to Project icon | Request Permissions | PDF file iconPDF (1260 KB)  
    Freely Available from IEEE
  • Table of contents

    Page(s): 2 - 3
    Save to Project icon | Request Permissions | PDF file iconPDF (503 KB)  
    Freely Available from IEEE
  • Article summaries

    Page(s): 4
    Save to Project icon | Request Permissions | PDF file iconPDF (32 KB)  
    Freely Available from IEEE
  • Building References for the Future

    Page(s): 5 - 7
    Save to Project icon | Request Permissions | PDF file iconPDF (160 KB)  
    Freely Available from IEEE
  • Business Lessons for Software Developers

    Page(s): 8
    Save to Project icon | Request Permissions | PDF file iconPDF (184 KB)  
    Freely Available from IEEE
  • Characterizing classes

    Page(s): 9 - 11
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (352 KB)  

    Class characterization is a key step of object design. It serves two purposes: to clarify at a glance some important aspects of a class's expected behavior and to communicate its design intent to others. Depending on the type of systems we design and build, we naturally find certain characterizations to be more compelling than others. Recognizing and choosing effective characterizations is an essential skill that all class designers should master. In this column, the author introduces several characteristics to classes when trying to understand their nature and purpose. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Improving the predictable assembly of service-oriented architectures

    Page(s): 12 - 15
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (200 KB)  

    Object technology's development and wide adoption has improved software applications' modularity, extensibility, and reusability. An approach that's complementary to OO software reuse entails using "Web services and service-oriented architectures". We propose an intermediate approach to Web service specification. Our technique integrates the use of regular expressions in WSDL specifications to constrain the format of argument and return values to and from Web services. This approach provides the basis for automating the generation of both client- and server-side checking wrappers. The service-oriented paradigm is founded on an assumption of well-specified and well-understood contracts that isn't realized in practice. Our approach extends the WSDL specification language with support for argument- and return-format specification brings us one step closer to realizing the assumptions on which the paradigm is based. This work is important in reducing the adoption barriers that have slowed the acceptance of Web services and SOAs. This is especially important as we closer to realizing the vision of ubiquitous computing that promises transparent integration of widely distributed services. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • On Architecture

    Page(s): 16 - 18
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (904 KB)  

    For the past two years, the author has been working to create a handbook of software architecture (www.booch.com/architecture) and will continue to work on it for another two to three years. The handbook’s primary goal is to codify the architecture of 100 interesting software-intensive systems, presenting them in a manner that exposes their essential patterns and permits comparisons across domains and architectural styles. In this ongoing column, Booch will share some of his experiences as he continues his research. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • 10 small steps to better requirements

    Page(s): 19 - 21
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (288 KB)  

    Project teams can take several small, easy steps to improve requirements to the point where they're good enough. But every project is different. Your team might need to take steps that wouldn't be right in other situations. The author lists 10 basic steps to improve requirements. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Past, Present, and Future for Software Architecture

    Page(s): 22 - 30
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (680 KB)  

    It's been 10 years since David Garlan and Mary Shaw wrote their seminal book Software Architecture Perspective on an Emerging Discipline, since Maarten Boasson edited a special issue of IEEE Software on software architecture, and since the first International Software Architecture Workshop took place. What has happened over these 10 years? What have we learned? Where do we look for information? What's the community around this discipline? And where are we going from here?This article is part of a focus section on software architecture. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The golden age of software architecture

    Page(s): 31 - 39
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (296 KB)  

    Since the late 1980s, software architecture has emerged as the principled understanding of the large-scale structures of software systems. From its roots in qualitative descriptions of empirically observed useful system organizations, software architecture has matured to encompass a broad set of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. It has made the transition from basic research to an essential element of software system design and construction. This retrospective examines software architecture's growth in the context of a technology maturation model, matching its significant accomplishments to the model's stages to gain perspective on where the field stands today. This trajectory has taken architecture to its golden age. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • In practice: UML software architecture and design description

    Page(s): 40 - 46
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (416 KB)  

    The Unified Modeling Language has attracted many organizations and practitioners. UML is now the de facto modeling language for software development. Several features account for its popularity: it's a standardized notation, rich in expressivity; UML 2.0 provides 13 diagram types that enable modeling several different views and abstraction levels. Furthermore, UML supports domain-specific extensions using stereotypes and tagged values. Finally, several case tools integrate UML modeling with other tasks such as generating code and reverse-engineering models from code. Our study focused on UML use and model quality in actual projects rather than on its adequacy as a notation or language. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Software architecture-centric methods and agile development

    Page(s): 47 - 53
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (120 KB)  

    The agile software development paradigm and plan-driven approaches each have their strengths and shortcomings. The former emphasizes rapid, flexible development, while the latter emphasizes project and process infrastructure. Many practitioners, particularly of agile methods, tend-to view software architecture in light of the plan-driven side of the spectrum. They think that architecture-centric methods are too much work, equating them with high-ceremony processes emphasizing document production. But many elements make up a successful development approach, including process, product, technology, people, and tools. Software architecture is part of product quality and isn't tied to a particular process, technology, culture, or tool. This article explores the relationship and synergies between architecture-centric design and analysis methods and the extreme programming framework. We chose to focus on XP because it's one of the most mature and best-known agile practices. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using architectural patterns and blueprints for service-oriented architecture

    Page(s): 54 - 61
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (120 KB)  

    Using software patterns and blueprints to express a service-oriented architecture's fundamental principles supports the efficient use of SOA technologies for application development. Understanding SOA and all of its implications for software applications requires introducing a set of architectural principles that define SOA more concretely. Software patterns and blueprints can accommodate both forward and reverse engineering. Using the core SOA principles, software architects can derive best-practice pattern systems and catalogs that illustrate how to leverage existing SOA technologies. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using architecture models for runtime adaptability

    Page(s): 62 - 70
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (240 KB)  

    Every software system has architecture. The architecture strongly influences the software system's properties, including maintainability and runtime properties such as performance and reliability. By describing the architecture in models, we can make the architecture explicit. Developers typically use software architecture models at design time to capture the significant decisions about a software system's organization and to describe and establish a common understanding about the system's abstract properties. In the MADAM (mobility- and adaptation-enabling middleware) project, we aim to facilitate adaptive application development for mobile computing. We follow an architecture-centric approach where we represent architecture models at runtime to allow generic middleware components to reason about and control adaptation. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Architecture description languages for high-integrity real-time systems

    Page(s): 71 - 79
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (216 KB)  

    Safety-critical systems, such as those in the avionics, automotive, power, space, and medical industries, are predominantly driven by real-time embedded software and are often referred to as high-integrity real-time systems (HIRTS). In these systems, safety is of paramount importance. Safety is broadly defined as freedom from accidents and loss. When no safe alternative to normal service exists, a system must be dependable to be safe, that is, it must have reliable ways to deliver a certain quality of service. Our collaborations with industrial partners have focused on HIRTS modeling techniques. Initially, we explored the potential benefits that the most successful software architecture and modeling approaches could bring to the safety-critical domain. We subsequently designed the architecture information modeling language. AIM lets us exploit the available technologies from the same platform and thus provide stronger support for the safety case. A safety case, a key element in HIRTS certification, typically consists of a high-level argument and supporting evidence. The HLA sets the principles on which the design is based and reasons why the design should satisfy the safety requirements. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A fault-tolerant architectural approach for dependable systems

    Page(s): 80 - 87
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (152 KB)  

    A system's structure enables it to generate its intended behavior from its components' behavior. A well-structured system simplifies relationships among components, which can increase dependability. With software systems, the architecture is an abstraction of the structure. Architectural reasoning about dependability has become increasingly important because emerging applications are increasingly complex. We've developed an architectural approach for effectively representing and analyzing fault-tolerant software systems. The proposed solution relies on exception handling to tolerate faults associated with component and connector failures, architectural mismatches, and configuration faults. Our approach, a specialization of the peer-to-peer architectural style, hides inside the architectural elements the complexities of exception handling and propagation. Our goal is to improve a system's overall reliability and availability by making it tolerant of nonmalicious faults. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using wikis in software development

    Page(s): 88 - 91
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (784 KB)  

    Wikis are especially useful in distributed projects: many teams around the world use them to organize, track, and publish their work. Their flexibility frees a project manager from fretting about getting everything exactly right from the beginning. A wiki can and should change to respond to the project's needs as they arise. While wikis are always easy to change, wiki engines usually incorporate comprehensive versioning and change control for their content. More important than the particular wiki implementation, however, is being sure that a wiki really fits in the culture of the project or organization. It requires tolerance and openness. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Bug busters

    Page(s): 92 - 93
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (144 KB)  

    One way to deal with bugs is to avoid them entirely. The approach would be wasteful because we'd be underutilizing the many automated tools and techniques that can catch bugs for us. Most tools for eliminating bugs work by tightening the specifications of what we build. At the program code level, tighter specifications affect the operations allowed on various data types, our program's behavior, and our code's style. Furthermore, we can use many different approaches to verify that our code is on track: the programming language, its compiler, specialized tools, libraries, and embedded tests are our most obvious friends. We can delegate bug busting to code. Many libraries come with hooks or specialized builds that can catch questionable argument values, resource leaks, and wrong ordering of function calls. Bugs many be a fact of life, but they're not inevitable. We have some powerful tools to find them before they mess with our programs, and the good news is that these tools get better every year. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Emphasizing human capabilities in software development

    Page(s): 94 - 101
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (152 KB)  

    People are a critical software development issue, and the human dimension can be even more important than the technical. An important part of human resources management is assigning people to development roles. This process isn't just crucial for generating productive teams; it can also help software organizations develop systematic long-term competence. Despite the importance of identifying the right people for roles, little is known about doing this properly. Integrating managerial experience with a procedure for identifying the person best suited for each role can help improve human resources management and long-term career development. We've defined a human capability-based procedure to supplement managerial activities for supporting personnel development and human resources management. Along with occupational psychologists and software managers, we've applied our procedure in small and medium-sized enterprises (SMEs). View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Coupling metrics for ontology-based system

    Page(s): 102 - 108
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (136 KB)  

    Measuring system coupling is a commonly accepted software engineering practice associated with producing high-quality software products. Coupling metrics traditionally measure data passed across a module interface to determine couplings between modules in a given system. XML has become common in Internet-based application domains such as business-to-business and business-to-consumer applications, and has formed a basis for service-oriented architectures such as Web services and the Semantic Web. We therefore need new coupling metrics that address these systems' unique requirements. We propose a set of coupling metrics for ontology-based systems represented in OWL: the number of external classes (NEC), reference to external classes (REC), and referenced includes (RI). To collect these metrics, we use a standard XML-based parser. This research reflects a new type of coupling measurement for system development that defines coupling metrics based on ontology data and its structure. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Bookshelf

    Page(s): 109 - 111
    Save to Project icon | Request Permissions | PDF file iconPDF (76 KB)  
    Freely Available from IEEE
  • Software developer profession expanding

    Page(s): 112 - 115
    Save to Project icon | Request Permissions | PDF file iconPDF (62 KB)  
    Freely Available from IEEE

Aims & Scope

IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Forrest Shull
Fraunhofer Center for Experimental Software Engineering