pdf viewer in c# code project : Paste jpeg into pdf application SDK tool html winforms wpf online software-architecture-practice15-part1378

Whether a system will be able to exhibit its desired (or required) quality attributes is substantially
determined by its architecture. Chapter 5
will delve into the relationship between architectures and quality
in more detail, but for now keep the following in mind:
If your system requires high performance, you need to manage the time-based behavior of elements
and the frequency and volume of inter-element communication.
If modifiability is important, you need to assign responsibilities to elements such that changes to the
system do not have far-reaching consequences.
If your system must be highly secure, you need to manage and protect inter-element communication
and which elements are allowed to access which information. You may also need to introduce
specialized elements (such as a trusted kernel) into the architecture.
If you believe scalability will be needed in your system, you have to carefully localize the use of
resources to facilitate the introduction of higher-capacity replacements.
If your project needs to deliver incremental subsets of the system, you must carefully manage inter-
component usage.
If you want the elements of your system to be re-usable in other systems, you need to restrict inter-
element coupling so that when you extract an element it does not come out with too many
attachments to its current environment to be useful.
The strategies for these and other quality attributes are supremely architectural. It is important to
understand, however, that architecture alone cannot guarantee functionality or quality. Poor downstream
design or implementation decisions can always undermine an adequate architectural design. Decisions at
all stages of the life cycle—from high-level design to coding and implementation—affect system quality.
Therefore, quality is not completely a function of architectural design. To ensure quality, a good
architecture is necessary, but not sufficient.
Predicting System Qualities by Studying the Architecture
Is it possible to tell that the appropriate architectural decisions have been made (i.e., if the system will
exhibit its required quality attributes) without waiting until the system is developed and deployed? If the
answer were no, choosing an architecture would be a hopeless task—random selection would perform as
well as any other method. Fortunately, it 
is
possible to make quality predictions about a system based
solely on an evaluation of its architecture. Architecture evaluation techniques such as the Architecture
Tradeoff Analysis Method of Chapter 11
support top-down insight into the attributes of software product
quality that is made possible (and constrained) by software architectures.
The Architecture Makes It Easier to Reason about and Manage Change
The software development community is coming to grips with the fact that roughly 80 percent of a typical
software system's cost occurs 
after
initial deployment. A corollary of this statistic is that most systems that
people work on are in this phase. Many if not most programmers and designers never work on new
development—they work under the constraints of the existing body of code. Software systems change
over their lifetimes; they do so often and often with difficulty.
Every architecture partitions possible changes into three categories: local, nonlocal, and architectural. A
local change can be accomplished by modifying a single element. A nonlocal change requires multiple
element modifications but leaves the underlying architectural approach intact. An architectural change
affects the fundamental ways in which the elements interact with each other—the pattern of the
architecture—and will probably require changes all over the system. Obviously, local changes are the
most desirable, and so an effective architecture is one in which the most likely changes are also the
easiest to make.
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
50 / 463
Paste jpeg into pdf - copy, paste, cut PDF images in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Detailed tutorial for copying, pasting, and cutting image in PDF page using C# class code
copy and paste image from pdf to word; copy and paste image from pdf
Paste jpeg into pdf - VB.NET PDF copy, paste image library: copy, paste, cut PDF images in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Tutorial for How to Cut or Copy an Image from One Page and Paste to Another
paste image into pdf in preview; paste image into pdf acrobat
Deciding when changes are essential, determining which change paths have the least risk, assessing the
consequences of proposed changes, and arbitrating sequences and priorities for requested changes all
require broad insight into relationships, performance, and behaviors of system software elements. These
are in the job description for an architect. Reasoning about the architecture can provide the insight
necessary to make decisions about proposed changes.
The Architecture Helps in Evolutionary Prototyping
Once an architecture has been defined, it can be analyzed and prototyped as a skeletal system. This aids
the development process in two ways.
1. The system is executable early in the product's life cycle. Its fidelity increases as prototype parts are
replaced by complete versions of the software. These prototype parts can be a lower-fidelity version
of the final functionality, or they can be surrogates that consume and produce data at the
appropriate rates.
2. A special case of having the system executable early is that potential performance problems can be
identified early in the product's life cycle.
Each of these benefits reduces the risk in the project. If the architecture is part of a family of related
systems, the cost of creating a framework for prototyping can be distributed over the development of
many systems.
The Architecture Enables More Accurate Cost and Schedule Estimates
Cost and schedule estimates are an important management tool to enable the manager to acquire the
necessary resources and to understand whether a project is in trouble. Cost estimations based on an
understanding of the system pieces are, inherently, more accurate than those based on overall system
knowledge. As we have said, the organizational structure of a project is based on its architecture. Each
team will be able to make more accurate estimates for its piece than a project manager will and will feel
more ownership in making the estimates come true. Second, the initial definition of an architecture means
that the requirements for a system have been reviewed and, in some sense, validated. The more
knowledge about the scope of a system, the more accurate the estimates.
ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL
The earlier in the life cycle re-use is applied, the greater the benefit that can be achieved. While code re-
use is beneficial, re-use at the architectural level provides tremendous leverage for systems with similar
requirements. Not only code can be re-used but so can the requirements that led to the architecture in the
first place, as well as the experience of building the re-used architecture. When architectural decisions
can be re-used across multiple systems, all of the early decision consequences we just described are
also transferred.
Software Product Lines Share a Common Architecture
A software product line or family is a set of software-intensive systems sharing a common, managed set
of features that satisfy the specific needs of a particular market segment or mission and that are
developed from a common set of core assets in a prescribed way. Chief among these core assets is the
architecture that was designed to handle the needs of the entire family. Product line architects choose an
architecture (or a family of closely related architectures) that will serve all envisioned members of the
product line by making design decisions that apply across the family early and by making other decisions
that apply only to individual members late. The architecture defines what is fixed for all members of the
product line and what is variable. Software product lines represent a powerful approach to multi-system
development that shows order-of-magnitude payoffs in time to market, cost, productivity, and product
quality. The power of architecture lies at the heart of the paradigm. Similar to other capital investments,
the architecture for a product line becomes a developing organization's core asset. Software product lines
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
51 / 463
VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.
edit, C#.NET PDF pages extract, copy, paste, C#.NET Export high quality jpeg file from PDF in .NET Turn multiple pages PDF into multiple jpg files in VB.NET
how to cut image from pdf; how to copy a pdf image into a word document
C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
Ability to copy selected PDF pages and paste into another PDF file. Copy three pages from test1.pdf and paste into test2.pdf.
copy image from pdf to; extract images from pdf files without using copy and paste
are explained in Chapter 14
, and case studies of product lines are given in Chapters 15
and 17
.
Systems Can Be Built Using Large, Externally Developed Elements
Whereas earlier software paradigms focused on 
programming
as the prime activity, with progress
measured in lines of code, architecture-based development often focuses on 
composing
or 
assembling
elements
that are likely to have been developed separately, even independently, from each other. This
composition is possible because the architecture defines the elements that can be incorporated into the
system. It constrains possible replacements (or additions) according to how they interact with their
environment, how they receive and relinquish control, what data they consume and produce, how they
access data, and what protocols they use for communication and resource sharing.
One key aspect of architecture is its organization of element structure, interfaces, and operating
concepts. The most significant principle of this organization is 
interchangeability
. In 1793, Eli Whitney's
mass production of muskets, based on the principle of interchangeable parts, signaled the dawn of the
Industrial Age. In the days before reliable physical measurements, this was a daunting notion. Today in
software, until abstractions can be reliably delimited, the notion of structural interchangeability is just as
daunting and just as significant.
Commercial off-the-shelf components, subsystems, and compatible communications interfaces all depend
on the principle of interchangeability. However, there is much about software development through
composition that remains unresolved. When the components that are candidates for importation and re-
use are distinct subsystems that have been built with conflicting architectural assumptions, unanticipated
complications can increase the effort required to integrate their functions. David Garlan and his
colleagues coined the term 
architectural mismatch
to describe this situation.
Less Is More: It Pays to Restrict the Vocabulary of Design Alternatives
As useful architectural patterns and design patterns are collected, it becomes clear that, although
computer programs can be combined in more or less infinite ways, there is something to be gained by
voluntarily restricting ourselves to a relatively small number of choices when it comes to program
cooperation and interaction. That is, we wish to minimize the design complexity of the system we are
building. Advantages to this approach include enhanced re-use, more regular and simpler designs that
are more easily understood and communicated, more capable analysis, shorter selection time, and
greater interoperability.
Properties of software design follow from the choice of architectural pattern. Patterns that are more
desirable for a particular problem should improve the implementation of the resulting design solution,
perhaps by making it easier to arbitrate conflicting design constraints, by increasing insight into poorly
understood design contexts, and/or by helping to surface inconsistencies in requirements specifications.
System Architecture versus Software Architecture
Over the past 5 to 10 years, we have had many occasions to give talks on software
architecture. Invariably, a question comes from the audience along the lines of "Why are you
talking about software architecture? Isn't system architecture just as important?" or "What is
the difference between software architecture and system architecture?"
In fact, there is little difference, as we will see. But we mostly talk about 
software
architecture
because we want to stress the crucial nature of the software decisions that an architect makes
concerning overall product quality.
In creating a software architecture, system considerations are seldom absent. For example, if
you want an architecture to be high performance, you need to have some idea of the physical
characteristics of the hardware platforms that it will run on (CPU speed, amount of memory,
disk access speed) and the characteristics of any devices that the system interfaces with
(traditional I/O devices, sensors, actuators), and you will also typically be concerned with the
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
52 / 463
VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.
Ability to copy PDF pages and paste into another PDF file. Support ' Copy three pages from test1.pdf and paste into test2.pdf. Dim
how to cut a picture from a pdf document; copy image from pdf to word
C# PDF Image Extract Library: Select, copy, paste PDF images in C#
DotNetNuke), SharePoint. Get JPG, JPEG and other high quality image files from PDF document. Able to extract vector images from PDF. Extract
how to cut pdf image; how to copy pictures from a pdf file
characteristics of the network (primarily bandwidth). If you want an architecture that is highly
reliable, again you will be concerned with the hardware, in this case with its failure rates and
the availability of redundant processing or network devices. On it goes. Considerations of
hardware are seldom far from the mind of the architect.
So, when you design a software architecture, you will probably need to think about the entire
system—the hardware as well as the software. To do otherwise would be foolhardy. No
engineer can be expected to make predictions about the characteristics of a system when only
part of that system is specified.
But still we persist in speaking about 
software
architecture primarily, and not system
architecture. Why is this? Because most of the architect's freedom is in the software choices,
not in the hardware choices. It is not that there are no hardware choices to be made, but these
may be out of the architect's control (for example, when creating a system that needs to work
on arbitrary client machines on the Internet) or specified by others (for reasons of economics,
legal issues, or compliance with standards); or they will likely change over time.
For this reason, we feel justified in focusing on the software portion of architecture, for this is
where the most fundamental decisions are made, where the greatest freedoms reside, and
where there are the greatest opportunities for success (or disaster!).
— RK
An Architecture Permits Template-Based Development
An architecture embodies design decisions about how elements interact that, while reflected in each
element's implementation, can be localized and written just once. Templates can be used to capture in
one place the inter-element interaction mechanisms. For instance, a template can encode the
declarations for an element's public area where results will be left, or can encode the protocols that the
element uses to engage with the system executive. An example of a set of firm architectural decisions
enabling template-based development will be discussed in Chapter 8
.
An Architecture Can Be the Basis for Training
The architecture, including a description of how elements interact to carry out the required behavior, can
serve as the introduction to the system for new project members. This reinforces our point that one of the
important uses of software architecture is to support and encourage communication among the various
stakeholders. The architecture is a common reference point.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
53 / 463
VB.NET PDF Image Extract Library: Select, copy, paste PDF images
DotNetNuke), SharePoint. Scan high quality image to PDF, tiff and various image formats, including JPG, JPEG, PNG, GIF, TIFF, etc. Able to
paste image in pdf preview; paste jpg into pdf preview
C# PDF insert text Library: insert text into PDF content in C#.net
Parameters: Name, Description, Valid Value. value, The char wil be added into PDF page, 0
copy picture from pdf reader; how to copy picture from pdf and paste in word
[ Team LiB ]
2.5 Architectural Structures and Views
The neurologist, the orthopedist, the hematologist, and the dermatologist all have a different view of the
structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems.
The kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement's
behavior. Although these views are pictured differently and have very different properties, all are
inherently related: Together they describe the architecture of the human body.
So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all
at once. Instead, we restrict our attention at any one moment to one (or a small number) of the software
system's structures. To communicate meaningfully about an architecture, we must make clear which
structure or structures we are discussing at the moment—which 
view
we are taking of the architecture.
We will be using the related terms 
structure
and 
view
when discussing architecture representation. A
view is a representation of a coherent set of architectural elements, as written by and read by system
stakeholders. It consists of a representation of a set of elements and the relations among them. A
structure is the set of elements itself, as they exist in software or hardware. For example, a module
structure is the set of the system's modules and their organization. A module view is the representation of
that structure, as documented by and used by some system stakeholders. These terms are often used
interchangeably, but we will adhere to these definitions.
Architectural structures can by and large be divided into three groups, depending on the broad nature of
the elements they show.
Module structures.
Here the elements are modules, which are units of implementation. Modules
represent a code-based way of considering the system. They are assigned areas of functional
responsibility. There is less emphasis on how the resulting software manifests itself at runtime.
Module structures allow us to answer questions such as What is the primary functional responsibility
assigned to each module? What other software elements is a module allowed to use? What other
software does it actually use? What modules are related to other modules by generalization or
specialization (i.e., inheritance) relationships?
Component-and-connector structures.
Here the elements are runtime components (which are the
principal units of computation) and connectors (which are the communication vehicles among
components). Component-and-connector structures help answer questions such as What are the
major executing components and how do they interact? What are the major shared data stores?
Which parts of the system are replicated? How does data progress through the system? What parts
of the system can run in parallel? How can the system's structure change as it executes?
Allocation structures.
Allocation structures show the relationship between the software elements and
the elements in one or more external environments in which the software is created and executed.
They answer questions such as What processor does each software element execute on? In what
files is each element stored during development, testing, and system building? What is the
assignment of software elements to development teams?
These three structures correspond to the three broad types of decision that architectural design involves:
How is the system to be structured as a set of code units (modules)?
How is the system to be structured as a set of elements that have runtime behavior (components)
and interactions (connectors)?
How is the system to relate to nonsoftware structures in its environment (i.e., CPUs, file systems,
networks, development teams, etc.)?
SOFTWARE STRUCTURES
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
54 / 463
C# PDF Convert to Jpeg SDK: Convert PDF to JPEG images in C#.net
High quality jpeg file can be exported from PDF in .NET framework. Turn multiple pages PDF into single jpg files respectively online.
how to copy text from pdf image to word; copying image from pdf to powerpoint
VB.NET PDF insert image library: insert images into PDF in vb.net
Support various image formats, like Jpeg or Jpg, Png, Gif, Bmp, Tiff and other Import graphic picture, digital photo, signature and logo into PDF document.
how to copy pictures from pdf file; paste image on pdf preview
Some of the most common and useful software structures are shown in Figure 2.3
. These are described
in the following sections.
Figure 2-3. Common software architecture structures
Module
Module-based structures include the following.
Decomposition.
The units are modules related to each other by the "is a submodule of " relation,
showing how larger modules are decomposed into smaller ones recursively until they are small
enough to be easily understood. Modules in this structure represent a common starting point for
design, as the architect enumerates what the units of software will have to do and assigns each item
to a module for subsequent (more detailed) design and eventual implementation. Modules often
have associated products (i.e., interface specifications, code, test plans, etc.). The decomposition
structure provides a large part of the system's modifiability, by ensuring that likely changes fall within
the purview of at most a few small modules. It is often used as the basis for the development
project's organization, including the structure of the documentation, and its integration and test
plans. The units in this structure often have organization-specific names. Certain U.S. Department of
Defense standards, for instance, define Computer Software Configuration Items (CSCIs) and
Computer Software Components (CSCs), which are units of modular decomposition. In Chapter 15
,
we will see system function groups and system functions as the units of decomposition.
Uses.
The units of this important but overlooked structure are also modules, or (in circumstances
where a finer grain is warranted) procedures or resources on the interfaces of modules. The units
are related by the 
uses
relation. One unit uses another if the correctness of the first requires the
presence of a correct version (as opposed to a stub) of the second. The uses structure is used to
engineer systems that can be easily extended to add functionality or from which useful functional
subsets can be easily extracted. The ability to easily subset a working system allows for incremental
development, a powerful build discipline that will be discussed further in Chapter 7
.
Layered.
When the uses relations in this structure are carefully controlled in a particular way, a
system of layers emerges, in which a layer is a coherent set of related functionality. In a strictly
layered structure, layer 
n
may only use the services of layer 
n
– 1. Many variations of this (and a
lessening of this structural restriction) occur in practice, however. Layers are often designed as
abstractions (virtual machines) that hide implementation specifics below from the layers above,
engendering portability. We will see layers in the case studies of Chapters 3
13
and 15
.
Class
, or 
generalization
. The module units in this structure are called classes. The relation is
"inherits-from" or "is-an-instance-of." This view supports reasoning about collections of similar
behavior or capability (i.e., the classes that other classes inherit from) and parameterized differences
which are captured by subclassing. The class structure allows us to reason about re-use and the
incremental addition of functionality.
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
55 / 463
Component-and-Connector
These structures include the following.
Process
, or 
communicating processes
. Like all component-and-connector structures, this one is
orthogonal to the module-based structures and deals with the dynamic aspects of a running system.
The units here are processes or threads that are connected with each other by communication,
synchronization, and/or exclusion operations. The relation in this (and in all component-and-
connector structures) is 
attachment
, showing how the components and connectors are hooked
together. The process structure is important in helping to engineer a system's execution performance
and availability.
Concurrency.
This component-and-connector structure allows the architect to determine
opportunities for parallelism and the locations where resource contention may occur. The units are
components and the connectors are "logical threads." A logical thread is a sequence of computation
that can be allocated to a separate physical thread later in the design process. The concurrency
structure is used early in design to identify the requirements for managing the issues associated with
concurrent execution.
Shared data
, or 
repository.
This structure comprises components and connectors that create, store,
and access persistent data. If the system is in fact structured around one or more shared data
repositories, this structure is a good one to illuminate. It shows how data is produced and consumed
by runtime software elements, and it can be used to ensure good performance and data integrity.
Client-server.
If the system is built as a group of cooperating clients and servers, this is a good
component-and-connector structure to illuminate. The components are the clients and servers, and
the connectors are protocols and messages they share to carry out the system's work. This is useful
for separation of concerns (supporting modifiability), for physical distribution, and for load balancing
(supporting runtime performance).
Allocation
Allocation structures include the following.
Deployment.
The deployment structure shows how software is assigned to hardware-processing
and communication elements. The elements are software (usually a process from a component-and-
connector view), hardware entities (processors), and communication pathways. Relations are
"allocated-to," showing on which physical units the software elements reside, and "migrates-to," if
the allocation is dynamic. This view allows an engineer to reason about performance, data integrity,
availability, and security. It is of particular interest in distributed or parallel systems.
Implementation.
This structure shows how software elements (usually modules) are mapped to the
file structure(s) in the system's development, integration, or configuration control environments. This
is critical for the management of development activities and build processes.
Work assignment.
This structure assigns responsibility for implementing and integrating the modules
to the appropriate development teams. Having a work assignment structure as part of the
architecture makes it clear that the decision about who does the work has architectural as well as
management implications. The architect will know the expertise required on each team. Also, on
large multi-sourced distributed development projects, the work assignment structure is the means for
calling out units of functional commonality and assigning them to a single team, rather than having
them implemented by everyone who needs them.
Table 2.1
summarizes the software structures. The table lists the meaning of the elements and relations
in each structure and tells what each structure might be used for.
Table 2.1. Architectural Structures of a System
Software
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
56 / 463
Structure
Relations
Useful for
Decomposition Is a submodule of; shares secret
with
Resource allocation and project structuring and
planning; information hiding, encapsulation;
configuration control
Uses
Requires the correct presence of Engineering subsets; engineering extensions
Layered
Requires the correct presence of;
uses the services of; provides
abstraction to
Incremental development; implementing systems
on top of "virtual machines" portability
Class
Is an instance of; shares access
methods of
In object-oriented design systems, producing rapid
almost-alike implementations from a common
template
Client-Server Communicates with; depends on
Distributed operation; separation of concerns;
performance analysis; load balancing
Process
Runs concurrently with; may run
concurrently with; excludes;
precedes; etc.
Scheduling analysis; performance analysis
Concurrency Runs on the same logical thread
Identifying locations where resource contention
exists, where threads may fork, join, be created or
be killed
Shared Data
Produces data; consumes data
Performance; data integrity; modifiability
Deployment
Allocated to; migrates to
Performance, availability, security analysis
Implementation Stored in
Configuration control, integration, test activities
Work
Assignment
Assigned to
Project management, best use of expertise,
management of commonality
Although we often think about a system's structure in terms of its functionality, there are system properties
in addition to functionality, such as physical distribution, process communication, and synchronization,
that must be considered at an architectural level. Each structure provides a method for reasoning about
some of the relevant quality attributes. The uses structure, for instance, must be 
engineered
(not merely
recorded) to build a system that can be easily extended or contracted. The process structure is
engineered
to eliminate deadlock and reduce bottlenecks. The module decomposition structure is
engineered
to produce modifiable systems, and so forth. Each structure provides the architect with a
different view into the system and a different leverage point for design.
RELATING STRUCTURES TO EACH OTHER
Each of these structures provides a different perspective and design handle on a system, and each is
valid and useful in its own right. Although the structures give different system perspectives, they are not
independent. Elements of one will be related to elements of others, and we need to reason about these
relations. For example, a module in a decomposition structure may be manifested as one, as part of one,
or as several components in one of the component-and-connector structures, reflecting its runtime alter
ego. In general, mappings between structures are many to many.
Individual projects sometimes consider one structure dominant and cast other structures, when possible,
in terms of it. Often, but not always, the dominant structure is module decomposition. This is for a good
reason: It tends to spawn the project structure. Scenarios, described in Chapter 4
, are useful for
exercising a given structure as well as its connections to other structures. For example, a software
engineer wanting to make a change to the client-server structure of a system would need to consider the
process and deployment views because client-server mechanisms typically involve processes and
threads, and physical distribution might involve different control mechanisms than would be used if the
processes were colocated on a single machine. If control mechanisms need to be changed, the module
decomposition or layered view would need to be considered to determine the extent of the changes.
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
57 / 463
Not all systems warrant consideration of many architectural structures. The larger the system, the more
dramatic the differences between these structures tend to be; however, for small systems we can often
get by with less. Instead of working with each of several component-and-connector structures, a single
one will do. If there is only one process, then the process structure collapses to a single node and need
not be carried through the design. If there is to be no distribution (that is, if there is just one processor),
then the deployment structure is trivial and need not be considered further.
Structures represent the primary engineering leverage points of an architecture. Individual structures
bring with them the power to manipulate one or more quality attributes. They represent a powerful
separation-of-concerns approach for creating the architecture (and, later, for analyzing it and explaining it
to stakeholders). And, as we will see in Chapter 9
, the structures that the architect has chosen as
engineering leverage points are also the primary candidates for the basis for architecture documentation.
WHICH STRUCTURES TO CHOOSE?
We have briefly described a number of useful architectural structures, and there are many more. Which
ones should an architect work on? Which ones should the architect document? Surely not all of them.
There is no shortage of advice. In 1995, Philippe Kruchten [Kruchten 95
] published a very influential
paper in which he described the concept of architecture comprising separate structures and advised
concentrating on four. To validate that the structures were not in conflict with each other and together did
in fact describe a system meeting its requirements, Kruchten advised using key use cases as a check.
This so-called "Four Plus One" approach became popular and has now been institutionalized as the
conceptual basis of the Rational Unified Process. Kruchten's four views follow:
Logical.
The elements are "key abstractions," which are manifested in the object-oriented world as
objects or object classes. This is a module view.
Process.
This view addresses concurrency and distribution of functionality. It is a component-and-
connector view.
Development.
This view shows the organization of software modules, libraries, subsystems, and
units of development. It is an allocation view, mapping software to the development environment.
Physical.
This view maps other elements onto processing and communication nodes and is also an
allocation view (which others call the deployment view).
At essentially the same time that Kruchten published his work, Soni, Nord, and Hofmeister [Soni 95
]
published an influential paper in which they reported the structures put into use across many projects by
the software architects in their organization. Their views were conceptual, module interconnection,
execution, and code. Once again, these map clearly to the module, component-and-connector, and
allocation models.
Other authors followed, and the list of available structures grows ever more rich. Of course, you should
not use them all even though most of them will in fact exist in the system you are building. Instead,
consider that one of the obligations of the architect is to understand how the various structures lead to
quality attributes, and then choose the ones that will best deliver those attributes. This point will be
treated at greater length in Chapter 9
, on architectural representation.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
58 / 463
[ Team LiB ]
2.6 Summary
This chapter defined software architecture and also introduced the related concepts of reference model,
reference architecture, and architectural pattern. We have explained why architecture is a fundamentally
useful concept in software engineering, in terms of the early insights it provides into the system, the
communication it enables among stakeholders, and the value it provides as a re-usable asset. All of these
themes will be expanded in subsequent chapters.
Our definition of architecture makes clear that systems comprise many structures. We showed several of
the most commonly used structures and explained how each serves as an engineering leverage point into
the design process.
The next chapter is the first case study of the book. Its purpose is to show the utility of different
architectural structures in the design of a complex system.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
59 / 463
Documents you may be interested
Documents you may be interested