Software Quality Engineering BS(SE)-VI
Dr. Assad Abbas
Department of Computer Science
Topics
Architecture Intertwined with QUALITY
n Clearly software quality—in fact, system quality in
general—is a complex concept.
5 requirements can poorly quantify the needs of a software system,
5 architectures and other artifacts can poorly outline
the analysis and design against those requirements,
5 implementation via coding or modeling can poorly execute the design artifacts, and
5 testing can poorly exercise an implementation.
n Clearly, quality testing must take into account design
Architecture Intertwined with QUALITY
n The, architectural quality methodologies (and
indeed quality metrics across the landscape of
software development) are active areas of research, with promising approaches.
n The technical focus of OMG over the past 16 years,
clearly on modeling (of requirements, of design, of analysis, of implementation, and certainly of
architecture) has been at the forefront.
n The software industry—and in fact every industry
these days—is going to increase not only the
Architecture
n Variety of definitions:
5 [An 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 (IEEE Computer Society, 2000).
Fundamental Understanding
n Architecture is a set of principal design decisions
about a software system
5 Example: Architecture of Web is characterized by the set of decisions referred to as the Representational State Transfer (REST) architecture style
5 Unix Shell script has architecture characterized by the pipe-and-filter style
n Three fundamental understandings of software
architecture
5 Every application has an architecture
5 Every application has at least one architect
The Origins
n Software Engineers have always employed software
architectures
5 Very often without realizing it!
n Address issues identified by researchers and
practitioners – (is that a quality concern)?
n Many ideas originated in other (non-computing)
System
n The IEEE 1471-2000 standard also defines the term
system:
n [A system is] a collection of components organized
to accomplish a specific function or set of functions. The term system encompasses individual
applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other
Architectural Scope
n The concept of architecture is prevalent in many
disciplines, but perhaps is best known in civil and structural engineering and building architecture.
n Even in the field of software engineering, we often come
across different forms of architecture.
5 For example, in addition to the concept of software
architecture, we may encounter notions such as enterprise architecture, system architecture, information architecture, hardware architecture, application architecture,
infrastructure architecture, data architecture, and so on.
n Each of these terms defines a specific scope of the
n The analogy between the design and construction of buildings
and design and construction of software is strong indeed.
n We all live in buildings
5 (We think) We know how they are built
g Requirements
g Design (blueprints)
g Construction
g Use
n This is similar (though not identical) to how we build software
n Satisfaction of customers’ needs
n Specialization of labor
n Multiple perspectives of the final product
n Intermediate points where plans and progress are reviewed
Architecture-Centric Design
n Traditional design phase suggests translating the
requirements into algorithms, so a programmer can implement them
n The activities of analysis, design, and implementation proceed
in a more enriched and integrated manner in contrast to the traditional waterfall methods and consequently result in high-quality designs
n From the QA perspective, architecture must deal with:
5 stakeholder issues, e.g. decision about use of proprietary, COTS component, open source tools and licensing
obligations etc.
5 Types of connectors for composing sub-elements
5 package and primary class structure
Architectural Design Decisions
n As stated earlier, architectural design decisions directly impact
software system quality.
n These design decisions further influence system deployment (onto
hardware resources), as well as the human interactions with the system.
n High-quality software deployed and executed on poor quality or
underspecified hardware cannot operate satisfactorily.
n At the same time, high-quality hardware cannot always
compensate for poorly designed and implemented software.
n Given the complexity, scale, and heterogeneity of today’s software
Architectural Design Decisions
n Architecture design is the process of making
strategic architectural decisions.
n Each decision must address one or more concrete
requirements, which should themselves align with the organization’s business goals.
n Clearly, new decisions should not adversely impact
earlier decisions, and one mechanism for helping
State of the Art
n Before software architecture gained broader attention in the 1990s,
commercial software development focused mainly on building software that was tightly coupled with the business domain at which the solution was targeted.
n This often resulted in applications with an ad hoc software architecture
with limited or no potential for reuse of knowledge or artifacts.
n Over the subsequent years, design reuse became more prominent. In
turn, this resulted in emergence of reusable, high-quality design solutions for recurring problems.
n Methodologies and tools supporting architectural patterns, frameworks,
reference architectures, and product lines were developed to support and promote design reuse. Moreover, architecture served as an important
foundation for managing change both at design and runtime.
n The emergence of self-adaptive systems and new approaches such as
State of the Art…
n Software systems are no longer treated as
monolithic systems, and the typical tight coupling between domain- and technology-specific elements of the system has diminished.
n Software architects explicitly and strictly enforce
separation of concerns by introducing layers of abstraction.
n This allows for domain-specific logic to be better
modularized and encapsulated instead of being
State of the Art…
n Designing for reuse
n Challenges associated with reuse are aggravated when considering software and
system quality.
5 For example, generic reusable components that also support a variety of quality requirements are rare.
n Reuse is much more achievable when there is some constraining context within
which reusable elements exist.
5 For example, code reuse is most effective and feasible when components are integrated into a greater context such as a product line platform, implementation framework, or library.
n The software engineering community has learned from failure that software
architecture needs to be designed in a systematic and planned way
5 an architecture should not emerge from an implementation, but an implementation should emerge from an architecture.
State of the Art…
n Functionality is no longer considered to be the only driving
force in design and development of large and complex systems.
n Meeting system QAs such as usability, modifiability,
performance, and security has surfaced as the primary
Quality Assurance in Design Phase
n QA activities during these phases may include:
5 Assuring that the architecture supports all the (non) -functional requirements.
5 Assuring that all important modules are covered and correctly designed in the detailed designs.
5 Assuring that the design documents are under configuration (change) management.
5 Performing (formal) reviews to review the architecture and its documentation.
References
1. Relating System Quality and Software Architecture.
