Home > A Practical Guide using UML > What is Software Architecture?

What is Software Architecture?


The many web pages and books on software architecture have provided  dozens, if not hundreds, of definitions of software architecture and related  terms. Given this plethora of definitions, we must settle on a set of key  definitions for the purposes of communicating software architecture concepts. What follows are some key definitions required for a discussion of software  architecture. Additional definitions can be found in the recommended readings  located at the end of this chapter.
The Institute of Electrical and Electronic Engineers (IEEE) recently issued a  recommended practice regarding Software Architecture: IEEE 1471. The  definitions we provide in this book are closely aligned with IEEE 1471. These  include definitions of system, stakeholder, architect, architecture, architectural  views, and architectural viewpoints. IEEE 1471 defines the following key  terms:

  • System is a set of components that accomplishes a specific function or set
    of functions.
  • ‘Architecture is the fundamental organization of a system embodied in its
    components, their relationships to each other, and to the environment,
    and the principles guiding its design and evolution’.
  • Architectural Description is a set of products that document the architecture.
  • Architectural View is a representation of a particular system or part of a
    system from a particular perspective.
  • Architectural Viewpoint is a template that describes how to create and
    use an architectural view. A viewpoint includes a name, stakeholders,
    concerns addressed by the viewpoint, and the modeling and analytic
    conventions.

The IEEE definitions are intentionally general, to cover many types of  software architecture, and are not specific enough to provide detailed guidance  to architects and developers of large-scale systems. As such, a large  portion of the book is devoted to the description of specific architectural  viewpoints, defined in the UML, which can be applied to many different largescale  development projects. In addition, most of these viewpoints can also  be applied to smaller development efforts. In this book, these viewpoints  are illustrated as architectural views for an example system.  The System Architecture is the set of entities, the properties of those entities,  and relationships among them that define structure of the system. The Software
Architecture is the set of software components, subsystems, relationships,  interactions, the properties of each of these elements, and the set of  guiding principles that together constitute the fundamental properties and  constraints of a software system or set of systems.
Software Architecting refers to the analysis, design, documentation, review,  approval, and other related activities concerned with the definition and  management of the software architecture. Architectural Views provide representations  of the architecture that can be used to guide construction, manage,  explore, train personnel, test, and perform other engineering tasks related to  creation and maintenance of the software system. Some uses for views  include:

  • Capturing the design decisions both early on, and as enhancements are
    made
  • Capturing information about the runtime environment for the software
  • Providing constraints on the lower-level design and implementation
  • Architectural Description is a set of products that document the architecture.
  • Architectural View is a representation of a particular system or part of a
    system from a particular perspective.
  • Architectural Viewpoint is a template that describes how to create and
    use an architectural view. A viewpoint includes a name, stakeholders,
    concerns addressed by the viewpoint, and the modeling and analytic
    conventions.

For each of these views there is a group of associated Stakeholders. The  stakeholders may include project and program managers, development team  managers and technical leads, system engineers, the test organization, and  individual developers. This group of stakeholders may be building the early  versions of the software, or may be making maintenance modifications to  software that has existed for some time. The architectural views are used to  communicate with the stakeholders and, as such, must be carefully crafted
to communicate the appropriate information at the appropriate level of detail  to the set of associated stakeholders for that view.  While the definition of software architecture terminology provided above is
useful, the definitions are still somewhat fuzzy since some of the terms used in  the definitions are not themselves clearly defined. The following sections of  this chapter will help refine and clarify these definitions.  Architecting software is primarily about software design – design in the  large. Thus, the focus of architecture is on the arrangement of the larger  aspects of software systems such as subsystems and components rather than  classes and objects. To model software systems in the large requires examining
both the static or build-time view and the dynamic or runtime behaviors of  the software.  Another way of thinking about software architecture is to think about some  of the typical questions that can be answered by views of the architecture:

• What are the subsystems or components of the software?
• What are the responsibilities of the components?
• What are the interfaces provided/consumed by these subsystems or components?
• What subsystems or components are impacted by a change to the software?
• How much retesting is required if we change this component?

• What components are involved in installing this change?
• How are parts of the system to be physically distributed?
• How will a change impact the performance of the system?
• What development teams are impacted by a change to this interface?
• How much effort is involved in the development of this functionality?

Since the software architecture being defined is often part of an even larger  system, it is often useful to concentrate on the subset of the system for which a  particular architecture is being defined. Examples of this type of system subset  include a set of components being developed by a particular development team
or a set of components that will be developed rather than purchased. This  subset of the system can be referred to as the system under design. This means  that even though only part of a larger system is being designed, any external  entities can be considered external to the system under design. This approach

allows architectural definition to focus on the parts of the system that are  critical and delay concerns about parts of the system which are not yet defined.

What software architecture is not

The software architecture does not include the hardware, network, or physical  plant architecture. As such, the software architecture description is not  intended to convey the complete description of the system, only the software within that system and any context needed to create the software. As an  example, information such as hardware model number, hardware configuration  information, routers, or LAN cards is not the focus in software architecture  views. Other views, tables, or documents may be used to specify this type  of information. However, this type of information should be included or  referenced if it influences the software design. In general, the software architecture description should not duplicate  information found in other sources, such as requirements documents or  marketing information. Duplication causes extra rework when these other  documents change.  The software architecture description must be kept at the appropriate level

of detail. The team that defines the architecture must keep each view at the  right level of detail and avoid showing more than one level of detail in a  particular view, unless the reasons for doing so are clear and agreed upon in  advance. Low-level implementation details should not be included in the software  architecture description. For example, a context or subsystem view should not  include details about the implementation mechanism for a particular interface.  In addition, descriptions of specific implementation mechanisms such as  compiler optimizations, shared versus static libraries, COTS class or method  names, or file format should not be included in the software architecture  views.

Attributes of software architecture

Many different attributes or qualities are of interest in software architecture.  These qualities are important because they impact the design and development  of many different parts of the software. Some of these qualities include:

• Cultural adaptability – support for multiple languages and cultural  differences
• Security – prevent unauthorized access
• Data integrity – does not corrupt or provide bad data
• Maintainability characteristics
Portability – can software be ported to other platformss, Changeability – ability to add new functions and change existing functions, Fragility – changes to fragile software tend to break existing functions, Rigidity – software is difficult to change even in simple ways, Duplication – software with duplication strewn throughout ismore difficult to maintain because it is larger and because change is not localized, Understandability – can the software be understood so that changes can be mades Debugging support – support for multiple levels of online debugging.

• Testability – software can be tested effectively (impacts changeability)
• Usability – a measure of the effectiveness of the human interface

• Operational system aspects:
Availability – percentage of the time system is functioning, Manageability – ability to inspect and manage executing components, Upgradeability – can system be upgraded while running, how difficult are upgrade procedures, Reliability – ability to perform required functions over specified period of time and Recoverability – time required to recover from a failure.
• Performance
Response – is the response fast enough for normal and extreme usage scenarios, Scalability – system capacity/throughput can be increased or decreased as necessary, Capacity/Throughput – handle heavy loads and still maintain response
• Safety – system does not create hazards in the real world

All of these attributes of the architecture are typical concerns for the  architecture team. Members of the architecture team need to constantly  evaluate the software architecture to determine if it meets the desired goals with  respect to these characteristics. At first blush, this evaluation seems straightforward,  but it is not. Increasing one attribute often results in a non-linear decrease  in a different attribute. For example, an increase in modifiability might reduce  performance. An increase in changeability might negatively impact testability.  In addition, the requirements with respect to these properties are not easy to  specify. Many of these attributes can only be assessed qualitatively given  current tools and practice. Architects must constantly prioritize and manage  the trade-offs between these attributes for a given project.  Some of these properties also imply that architects are concerned with  implementation mechanisms. For example, mechanisms involving data persistence,  transactions, and component error handling often need consistent
approaches in order to meet the architectural goals. This often means coping  with how to integrate legacy components alongside new components.   To a large extent, the practice of software architecture is the attempt to  balance a series of fuzzy trade-offs for the system stakeholders over what are often immensely complex systems. Looking at the whole system at once is simply not possible. Architects need tools to break down problems and reason  about the parts, the interaction of the parts, and how the entire system fits  together.

Definitions of other key architecture-related terms

The following are a few other definitions that are required for understanding the discussions in the remainder of the book. We recommend the reader rely  on the recommended readings for a complete set of architecture-related  definitions. Terms that are associated with a particular aspect of software architecture, for example terms associated with the analysis and design  process, are defined in the appropriate sections later in this book.  The following terms will provide a clearer understanding of concepts key to  large-scale software architecture:
Architectural Patterns – define a general set of element types and their  interactions. Examples of Architectural Patterns include Pipes and Filters,  Model–View–Controller, and Reflection.  Architectural Style – As the term coined by Garlan and Shaw, it is an  idiomatic pattern of system organization. For example, a client–server system  is an architectural style. Many of the original architectural styles have been
reformulated as patterns.  Build Systems – Development teams typically employ a set of tools that  facilitate the translation of a large source code base into a set of libraries and  executables in an orderly manner. This usually involves interacting with  configuration management tools as well as tools such as the ‘Make’ utility that  utilizes software dependencies to perform incremental builds.  Commercial Off-the-Shelf (COTS) Products – These include software components  that are purchased from software vendors or obtained from open  source. Some authors use the term ‘common’ in place of the term commercial  to prevent confusion with using the term ‘commercial’ for open source  software.

Component – A construct that groups implementation constructs and provides/consumes a set of interfaces. A component is a modular and easily replaceable implementation construct. The UML definition includes executable processes, applets, EJB, and code libraries as part of the componentdefinition. Some authors further categorize components to include conceptual  or logical components. However, we define views only in terms of the runtime  aspects of components.
Domain – A domain is an area of concern. For example, the ‘problem domain’ defines the ‘what’ aspect of the system under design. The ‘solution domain’ is the ‘how’ aspect. A large complex problem is often broken into sub-domains that address only one aspect of the larger problem.

Model – A representation used to understand or document one or more aspects of a problem or solution. With the UML, the model is often kept in a tool that  will support the creation of multiple views. In this case, the tool can provide the ability to keep a series of partial views of a complex model consistent.

Top-Level Software Architecture Description – The set of views of the system  that encompass the highest-level perspective of the software. This perspective  tends to focus on subsystems and components as documented in the top-levelsoftware design document.

Subsystem – A collection of classes and components that are grouped to form a development package. These subsystems need to be defined in such a way as  to facilitate having them assigned to different, possibly geographically diverse,  development teams.

Other types of architectures

Architecture is used in conjunction with many adjunct terms such as technical architecture, business architecture, enterprise architecture, reference architecture, product line architecture, and information architecture. To some extent, all these ‘architectures’ have confused and obscured the definition of software
architecture. The following list will briefly describe some of these in order to clarify how they relate to software architecture:

Enterprise Architecture is generally defined in terms of its constituent architectures. These include the business architecture, application architecture, technology architecture, software infrastructure architecture, and information  architecture. The enterprise architecture provides the vision and consistent principles that cross all the constituent architecture types and addresses objectives such as security, flexibility, make versus buy decisions, and reuse.

The Business Architecture defines the key business strategies, organization, goals, and related business processes. The software architecture should be  complementary with the business architecture. We must remember that the final goal of most software is to make the business successful, not simply to produce an elegant software design.

At the enterprise level, the Application Architecture may be more of a set of guidelines on how the various software architectures should be constructed  consistently across the enterprise. For a specific product, the application  architecture is the software architecture for that product.
The Technology/Infrastructure Architecture refers to the network connectivity,  hardware upon which the software runs, network routers, operating  systems, and other technologies that facilitate the communication among the  distributed software components and support the execution environment of
the software.
The Data Architecture, sometimes referred to as the Information Architecture,  refers to how the data is structured, stored, and handled either in the  enterprise or for a particular project. The definition of the data architecture  involves the specification of the number and type of databases, the logical and  physical database design, the allocation of data to servers, the strategy for  data replication and archival, as well as the strategy and design of a data  warehouse.

The U.S. Army’s Joint Technical Architecture – Army (JTA-Army) provides  the following definition:

A Technical Architecture is the minimal set of rules governing the  arrangement, interaction, and interdependence of the parts or elements that together may be used to form an information system. Its purpose is to ensure that a conformant system satisfies a specified set of requirements.  It is the build code for the Systems Architecture being constructed  to satisfy Operational Architecture requirements.

A Product-line Architecture is used to define a set of products that are  developed by a company or organization within the company. The similarities  within that set of products allow for sharing of design and implementation information among the various teams developing the products. In this way,  the products can be more consistent in the way they are designed, developed,  tested, supported, and in their appearance to the end user. In addition, these  products can be developed in a more cost-effective manner, due to the design  and implementation reuse potential.
The term Reference Architecture refers to the definition of an architecture for a  particular application domain. An example domain might be satellite ground  control systems or telecommunications switch network management. The  reference architecture describes the high-level set of elements involved in applications  from a particular domain along with their interactions. These elements  must intentionally be left at a high level to apply to a large number of systems for  that particular domain. Reference architectures are often used to focus on  subsystem definition rather than application process level definition. Reference
architecture definitions also provide an excellent framework for development of  a specific system in that application domain and can save the software architects  a significant amount of time rediscovering these elements. In addition, the  naming conventions used in the reference architecture provide a common
language for architects and application developers to communicate. The functional  and interface definitions provided in the reference architecture also  provide an opportunity for third-party COTS products to be developed that can  be used by software architects for significant portions of the final system.  The techniques and many of the architectural views described in this book  can also be used for developing product-line, data, and reference architectures.

  1. January 25, 2012 at 11:39 am

    Contoh Makalah Jurnal Skripsi Tesis Contoh Makalah Jurnal Skripsi Tesis – Download Kumpulan Contoh Makalah Jurnal Skripsi Tesis

  2. January 25, 2012 at 2:17 pm

    niche for share gan , terima kasih

  3. January 25, 2012 at 4:18 pm

    Download Kumpulan Contoh Makalah Gratis

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: