Software Architecture - PowerPoint PPT Presentation

1 / 26
About This Presentation
Title:

Software Architecture

Description:

Software Architecture By Nick V. Scherbakov Technical University of St. Petersburg What is Software Architecture? A set of significant decisions about the ... – PowerPoint PPT presentation

Number of Views:116
Avg rating:3.0/5.0
Slides: 27
Provided by: Robe113
Learn more at: https://www.ecs.csun.edu
Category:

less

Transcript and Presenter's Notes

Title: Software Architecture


1
Software Architecture
  • By Nick V. Scherbakov
  • Technical University of St. Petersburg

2
What is Software Architecture?
  • A set of significant decisions about the
    organization of a software system,
  • The selection of the structural elements and
    their interfaces by which the system is composed,
  • The behavior of the structural elements as
    specified in the collaborations among those
    elements,
  • Composition of these structural and behavioral
    elements into progressively larger subsystems,
  • The architectural style that guides this
    organization (i.e. these elements and their
    interfaces, their collaborations, and their
    composition).

3
Note on the Definition
  • In the definition above, we assume that
    components can make up a component.
  • The intent of this definition is that a software
    architecture must abstract away some information
    from the system (otherwise there is no point
    looking at the architecture, we are simply
    viewing the entire system) and yet provide enough
    information to be a basis for analysis, decision
    making, and hence risk reduction.
  • First, architecture defines components. The
    architecture embodies information about how the
    components interact with each other. This means
    that architecture specifically omits content
    information about components that does not
    pertain to their interaction.

4
Note on the Definition (Contd)
  • Second, the definition makes clear that systems
    can comprise more than one structure, and that no
    one structure holds the irrefutable claim to
    being the architecture.
  • By intention, the definition does not specify
    what architectural components and relationships
    are. Is a software component an object? A
    process? A library? A database? A commercial
    product? It can be any of these things and more.
  • Third, the definition implies that every software
    system has an architecture, because every system
    can be shown to be composed of components and
    relations among them.

5
Note on the Definition (Contd)
  • Fourth, the behavior of each component is part of
    the architecture, insofar as that behavior can be
    observed or discerned from the point of view of
    another component. This behavior is what allows
    components to interact with each other, which is
    clearly part of the architecture.
  • Hence, most of the box-and-line drawings that are
    passed off as architectures are in fact not
    architectures at all. They are simply
    box-and-line drawing

6
System Quality Attributes
  • The architecture essentially defines "externally
    visible" properties also known as system quality
    attributes for the whole software project, we are
    referring to such properties as its provided
    services, performance characteristics, fault
    handling, shared resource usage, and so on.
  • Evaluation of an architecture's properties is
    critical to successful system development.
    However, reasoning about a system's intended
    architecture must be recognized as distinct from
    reasoning about its realized architecture. As
    design and eventually implementation of an
    architecture proceed, faithfulness to the
    principles of the intended architecture is not
    always easy to achieve.

7
Run-Time Quality Attributes
  • Performance refers to the responsiveness of the
    system, the 'time required to respond to stimuli
    (events) or the number of events processed in
    some interval of time.
  • Performance qualities are often expressed by the
    number of transactions per unit time or by the
    amount of time it takes a transaction with the
    system to complete.
  • Since communication usually takes longer than
    computation, performance is often a function of
    how much communication and interaction there is
    between the components of the system-clearly an
    architectural issue.
  • Security is a measure of the system's ability to
    resist unauthorized attempts at usage and denial
    of service while still providing its services to
    legitimate users.
  • It is categorized in terms of the types of
    threats that might be made to system

8
Run-Time Quality Attributes (Contd)
  • Availability measures the proportion of time the
    system is up and running.
  • It is measured by the length of time between
    failures as well as by how quickly the system is
    able to resume operation in the event of failure.
    The steady state availability of a system is the
    proportion of time that the system is functioning
    correctly and is typically seen as follows
  • time to failure/(time to failure time to
    repair)
  • Availability comes from both "time to failure"
    and "time to repair" both are addressed through
    architectural means.

9
Run-Time Quality Attributes (Contd)
  • Reliability is closely related to availability,
    the ability of the system to keep operating over
    time. Reliability is usually measured with "time
    to failure". This is a quality attribute that is
    tied to the architecture
  • Careful attention to error reporting and handling
    (which involves constraining the interaction
    patterns among the components), and special kinds
    of components such as time-out monitors.
  • Mean time to failure is lengthened primarily by
    making an architecture fault tolerant.
  • Fault tolerance, in turn, is achieved by the
    replication of critical processing elements and
    connections within the architecture. Mean time to
    failure can also be lengthened by gelding a less
    error-prone system, which is addressed
    architecturally by careful separation of
    concerns, which leads to better inerrability and
    testability.

10
Run-Time Quality Attributes (Contd)
  • Functionality is the ability of the system to do
    the work for which it was intended.
  • Performing a task requires that many or most of
    the system's components work in a coordinated
    manner to complete the job, just as framers,
    electricians, plumbers, drywall hangers,
    painters, and finish carpenters all come together
    to cooperatively perform the task of getting a
    house built.
  • Therefore, if the components have not been
    assigned the correct responsibilities or have not
    been endowed with the correct facilities for
    coordinating with other components (so that, for
    instance, they know when it is time for them to
    begin their portion of the task), the system will
    be unable to perform the required functionality.

11
Run-Time Quality Attributes (Contd)
  • Usability can be broken down into the following
    areas
  • Learnability How quick and easy is it for a user
    to learn to use the system's interface?
  • Efficiency Does the system respond with
    appropriate speed to a user's requests?
  • Memorability Can the user remember how to do
    system operations between uses of the system?
  • Error avoidance Does the system anticipate and
    prevent common user errors?
  • Error handling Does the system help the user
    recover from errors?
  • Satisfaction Does the system make the user's job
    easy?

12
Engineering Quality Attributes
  • Modifiability, in all its forms, may be the
    quality attribute most closely aligned to the
    architecture of a system.
  • The ability to make changes quickly and cost
    effectively follows directly from the
    architecture Modifiability is largely a function
    of the locality of any change.
  • Making a widespread change to the system is more
    costly than making a change to a single
    component, all other things being equal.
  • There are exceptions, of course.
  • A single component, if excessively large and
    complex, may be more costly to change than five
    simple ones.
  • It's also easy to imagine a global change that in
    each place is simple and systematic changing the
    value of a constant that appears everywhere, for
    instance.

13
Engineering Quality Attributes (Contd)
  • Modifiability (contd)
  • However, in large systems, making a change is
    much more costly than just, well, making the
    change. Development process costs start to
    dominate, such as maintaining version control,
    approving the change across many change control
    boards, coordinating the change time across many
    large teams, retesting all the units, perhaps
    assuring backward compatibility, and so forth. We
    take as a general principle that local is better.
  • Since the architecture defines the components and
    the responsibilities of each, it also defines the
    circumstances under which each component will
    have to change. An architecture effectively
    classifies all possible changes into four
    categories

14
The Four Categories of Change
  • Extending or changing capabilities. Adding new
    functionality, enhancing existing functionality,
    or repairing bugs. The ability to acquire new
    features is called extensibility. Adding new
    capabilities is important to remain competitive
    against other products in the same market.
  • Deleting unwanted capabilities. To streamline or
    simplify the functionality of an existing
    application, perhaps to deliver a less-capable
    (and therefore less expensive) version of a
    product to a wider customer base.
  • Adapting to new operating environments. For
    example, processor hardware, input/output
    devices, and logical devices. This kind of
    modification occurs so often that the quality of
    being amenable to it has a special name,
    portability, which we will discuss separately.
    Portability makes a product more flexible in how
    it can be fielded, appealing to a broader
    customer base.
  • Restructuring. For example, rationalizing system
    services, modularising, . optimising, or creating
    reusable components that may serve to give the
    organization a head start on future systems.

15
Engineering Quality Attributes (Contd)
  • Portability is the ability of the system to run
    under different computing environments.
  • These environments can be hardware, software, or
    a combination of the two. A system is portable to
    the extent that all of the assumptions about any
    particular computing environment are confined to
    one component (or at worst, a small number of
    easily changed components).
  • The encapsulation of platform-specific
    considerations in an architecture typically takes
    the form of a portability layer, a set of
    software services that gives application software
    an abstract interface to its environment. This
    interface remains constant (thus insulating the
    application software from change) even though the
    implementation of that layer changes as the
    system is ported from environment to environment.

16
Engineering Quality Attributes (Contd)
  • Reusability is usually taken to mean designing a
    system so that the system's structure or some of
    its components can be reused again in future
    applications.
  • Designing for reusability means that the system
    has been structured so that its components can be
    chosen from previously built products, in which
    case it is a synonym for integrability . In
    either case, reusability can be conceived of as
    another special case of modifiability.

17
Engineering Quality Attributes (Contd)
  • Integrability is the ability to make the
    separately developed components of the system
    work correctly together. This in turn depends on
    the external complexity of the components, their
    interaction mechanisms and protocols, and the
    degree to which responsibilities have been
    cleanly partitioned, all architecture-level
    issues.
  • Inerrability also depends upon how well and
    completely the interfaces to the components have
    been specified. Integrating a component depends
    not only on the interaction mechanisms used
    (e.g., procedure call versus process spawning)
    but also on the functionality assigned to the
    component to be integrated and how that
    functionality is related to the functionality of
    this new component's environment.

18
Engineering Quality Attributes (Contd)
  • Interoperability is a special kind of
    integrability.
  • lntegrability measures the ability of parts of a
    system to work together interoperability
    measures the ability of a group of parts
    (constituting a system) to work with another
    system.

19
Engineering Quality Attributes (Contd)
  • Software testability refers to the ease with
    which software can be made to demonstrate its
    faults through (typically execution-based)
    testing.
  • In particular, testability refers to the
    probability that, assuming that the software does
    have at least one fault, the software will fail
    on its next test execution.
  • Testability is related to the concepts of
    absorbability and coagulability. For a system to
    be properly testable, it must be possible to
    control each component's internal state and
    inputs and then to observe its outputs.
  • A system's testability relates to several
    structural or architectural issues its level of
    architectural documentation, its separation of
    concerns, and the degree to which the system uses
    information hiding. Incremental development also
    benefits testability in the same way it enhances
    interoperability.

20
Business Quality Attributes
  • In addition to the preceding qualities that apply
    directly to a system, there are a number of
    business quality goals that frequently shape a
    system's architecture.
  • We (briefly) distinguish two kinds of business
    goals.
  • The first concerns cost and schedule
    considerations
  • The other business goal deals with market and
    marketing considerations

21
Business Quality Attributes (Contd)
  • Time to market. If there is competitive pressure
    or if there is a short window of opportunity for
    a system or product, development time becomes
    important.
  • This in turn leads to pressure to buy or
    otherwise reuse existing components. Time to
    market is often reduced by using prebuilt
    components such as commercial off-the-shelf
    (COTS) products or components reused from
    previous projects. The ability to insert a
    component into a system depends on the
    decomposition of the system into components, one
    or more of which are prebuilt.

22
Business Quality Attributes (Contd)
  • Cost. The development effort will naturally have
    a budget that must not be exceeded.
  • Different architectures will yield different
    development costs for instance, an architecture
    that relies on technology (or expertise with a
    technology) that is not resident within the
    developing organization will be more expensive to
    realize than one that takes advantage of assets
    already in-house.

23
Business Quality Attributes (Contd)
  • Projected lifetime of the system. lf the system
    is intended to have a long lifetime,
    modifiability and portability across different
    platforms become important. But building in the
    additional infrastructure (such as a portability
    layer) to support modifiability and portability
    will usually compromise time to market.
  • On the other hand, a modifiable, extensible
    product is more likely to survive longer in the
    marketplace, extending its lifetime.

24
Business Quality Attributes (Contd)
  • Targeted market. For general-purpose
    (mass-market) software, the platforms on which a
    system runs as well as its feature set will
    determine the size of the potential market. Thus,
    portability and functionality are key to market
    share. Other qualities such as performance,
    reliability, and usability also play a role.
  • For a large but specific market, a product-line
    approach should be considered, in which a core of
    the system is common (frequently including
    provisions for portability) and around which
    layers of software of increasing specificity are
    constructed.

25
Business Quality Attributes (Contd)
  • Rollout schedule. lf a product is to be
    introduced as base functionality with many
    options, flexibility and customizability are
    important. Particularly, the system must be
    constructed with ease of expansion and
    contraction in mind.

26
Business Quality Attributes (Contd)
  • Extensive use of legacy systems. If the new
    system must integrate with existing systems, care
    must be taken to define appropriate integration
    mechanisms.
  • This is a property that is clearly of marketing
    importance but which has substantial
    architectural implications.
  • For example, the ability to integrate a legacy
    system with an HTTP server to make it accessible
    from the World Wide Web is currently a marketing
    goal in many corporations. The architectural
    constraints implied by this integration must be
    analyzed.
Write a Comment
User Comments (0)
About PowerShow.com