pdf viewer in c# code project : Paste picture into pdf application software utility azure windows wpf visual studio software-architecture-practice121-part1351

DOCUMENTING INTERFACES
An 
interface
is a boundary across which two independent entities meet and interact or communicate with
each other. Our definition of software architecture in Chapter 2
made it clear that elements' interfaces
—carriers of the properties externally visible to other elements—are architectural. Since you cannot
perform analyses or system building without them, documenting interfaces is an important part of
documenting architecture.
Documenting an interface consists of naming and identifying it and documenting its syntactic and
semantic information. The first two parts constitute an interface's "signature." When an interface's
resources are invokable programs, the signature names the programs and defines their parameters.
Parameters are defined by their order, data type, and (sometimes) whether or not their value is changed
by the program. A signature is the information that you would find about the program, for instance, in an
element's C or C++ header file or in a Java interface.
Signatures are useful (for example, they can enable automatic build checking), but are only part of the
story. Signature matching will guarantee that a system will compile and/or link successfully. However, it
guarantees nothing about whether the system will operate successfully, which is after all the ultimate
goal. That information is bound up in the semantics to the interface, or what happens when resources are
brought into play.
An interface is documented with an interface specification, which is a statement of element properties the
architect chooses to make known. The architect should expose only what is needed to interact with the
interface. Put another way, the architect chooses what information is permissible and appropriate for
people to assume about the element, and what is unlikely to change. Documenting an interface is a
matter of striking a balance between disclosing too little information and disclosing too much. Too little
information will prevent developers from successfully interacting with the element. Too much will make
future changes to the system more difficult and widespread and make the interface too complicated for
people to understand. A rule of thumb is to focus on how elements interact with their operational
environments, not on how they are implemented. Restrict the documentation to phenomena that are
externally visible.
Elements that occur as modules often correspond directly to one or more elements in a component-and-
connector view. The module and component-and-connector elements are likely to have similar, if not
identical, interfaces and documenting them in both places would produce needless duplication. To avoid
that, the interface specification in the component-and-connector view can point to the interface
specification in the module view, and only contain the information specific to its view. Similarly, a module
may appear in more than one module view—such as the module decomposition or uses view. Again,
choose one view to hold the interface specification and refer to it in the others.
A Template for Documenting Interfaces
Here is a suggested standard organization for interface documentation. You may wish to modify it to
remove items not relevant to your situation, or add items unique to it. More important than which standard
organization you use is the practice of using one. Use what you need to present an accurate picture of
the element's externally visible interactions for the interfaces in your project.
1. 
Interface identity.
When an element has multiple interfaces, identify the individual interfaces to
distinguish them. This usually means naming them. You may also need to provide a version number.
2. 
Resources provided.
The heart of an interface document is the resources that the element provides.
Define them by giving their syntax, their semantics (what happens when they are used), and any
restrictions on their usage. Several notations exist for documenting an interface's syntax. One is the
OMG's Interface Definition Language (IDL), used in the CORBA community. It provides language
constructs to describe data types, operations, attributes, and exceptions. The only language support
for semantic information is a comment mechanism. Most programming languages have built-in ways
to specify the signature of an element. C header (.h) files and Ada package specifications are two
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
210 / 463
Paste picture 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
how to cut and paste image from pdf; how to copy picture from pdf to word
Paste picture 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
how to copy images from pdf to word; paste image into pdf acrobat
examples. Finally, using the <<interface>> stereotype in UML (as shown in Figure 9.4
) provides
the means for conveying syntactic information about an interface. At a minimum, the interface is
named; the architect can also specify signature information.
Resource syntax.
This is the resource's signature. The signature includes any information
another program will need to write a syntactically correct program that uses the resource. The
signature includes the resource name, names and logical data types of arguments (if any), and
so forth.
Resource semantics.
This describes the result of invoking the resource. It might include
- assignment of values to data that the actor invoking the resource can access. It might be
as simple as setting the value of a return argument or as far-reaching as updating a
central database.
- events that will be signaled or messages that will be sent as a result of using the
resource.
- how other resources will behave in the future as the result of using this resource. For
example, if you ask a resource to destroy an object, trying to access that object in the
future through other resources will produce quite a different outcome (an error).
- humanly observable results. These are prevalent in embedded systems; for example,
calling a program that turns on a display in a cockpit has a very observable effect: The
display comes on.
In addition, the statement of semantics should make it clear whether the resource
execution will be atomic or may be suspended or interrupted. The most widespread
notation for conveying semantic information is natural language. Boolean algebra is often
used to write down preconditions and postconditions, which provide a relatively simple and
effective method for expressing semantics. Traces are also used to convey semantic
information by writing down sequences of activities or interactions that describe the
element's response to a specific use.
Resource usage restrictions.
Under what circumstances may this resource be used? Perhaps
data must be initialized before it can be read, or a particular method cannot be invoked unless
another is invoked first. Perhaps there is a limit on the number of actors that can interact via
this resource at any instant. Perhaps only one actor can have ownership and be able to modify
the element whereas others have only read access. Perhaps only certain resources or
interfaces are accessible to certain actors to support a multi-level security scheme. If the
resource requires that other resources be present, or makes other assumptions about its
environment, these should be documented.
Figure 9.4. Interfaces in UML
3. 
Data type definitions.
If any interface resources employ a data type other than one provided by 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
211 / 463
C# PDF insert image Library: insert images into PDF in C#.net, ASP
vector images to PDF file. Import graphic picture, digital photo, signature and logo into PDF document. Ability to put image into
copying a pdf image to word; how to copy and paste an image from a pdf
VB.NET PDF insert image library: insert images into PDF in vb.net
project. Import graphic picture, digital photo, signature and logo into PDF document. Add images to any selected PDF page in VB.NET.
copy image from pdf preview; copy image from pdf
underlying programming language, the architect needs to communicate the definition of that data
type. If it is defined by another element, then a reference to the definition in that element's
documentation is sufficient. In any case, programmers writing elements using such a resource need
to know (a) how to declare variables and constants of the data type; (b) how to write literal values in
the data type; (c) what operations and comparisons may be performed on members of the data type;
and (d) how to convert values of the data type into other data types, where appropriate.
4. 
Exception definitions.
These describe exceptions that can be raised by the resources on the
interface. Since the same exception might be raised by more than one resource, it is often
convenient to simply list each resource's exceptions but define them in a dictionary collected
separately. This section is that dictionary. Common exception-handling behavior can also be defined
here.
5. 
Variability provided by the interface.
Does the interface allow the element to be configured in some
way? These 
configuration parameters
and how they affect the semantics of the interface must be
documented. Examples of variability include the capacities of visible data structures and the
performance characteristics of underlying algorithms. Name and provide a range of values for each
configuration parameter and specify the time when its actual value is bound.
6. 
Quality attribute characteristics of the interface.
The architect needs to document what quality
attribute characteristics (such as performance or reliability) the interface makes known to the
element's users. This information may be in the form of constraints on implementations of elements
that will realize the interface. Which qualities you choose to concentrate on and make promises
about will depend on context.
7. 
Element requirements.
What the element requires may be specific, named resources provided by
other elements. The documentation obligation is the same as for resources provided: syntax,
semantics, and any usage restrictions. Often it is convenient to document information like this as a
set of assumptions that the element's designer has made about the system. In this form, they can be
reviewed by experts who can confirm or repudiate the assumptions before design has progressed
too far.
8. 
Rationale and design issues.
As with rationale for the architecture (or architectural views) at large,
the architect should record the reasons for an element's interface design. The rationale should
explain the motivation behind the design, constraints and compromises, what alternative designs
were considered and rejected (and why), and any insight the architect has about how to change the
interface in the future.
9. 
Usage guide.
Item 2 and item 7 document an element's semantic information on a per resource
basis. This sometimes falls short of what is needed. In some cases semantics need to be reasoned
about in terms of how a broad number of individual interactions interrelate. Essentially, a 
protocol
is
involved that is documented by considering a sequence of interactions. Protocols can represent the
complete behavior of the interaction or patterns of usage that the element designer expects to come
up repeatedly. If interacting with the element via its interface is complex, the interface documentation
should include a static behavioral model such as a statechart, or examples of carrying out specific
interactions in the form of sequence diagrams. This is similar to the view-level behaviors presented
in the previous section, but focused on a single element.
Figure 9.2
summarizes this template which is an expansion of section 2.C from Figure 9.1
.
Figure 9.2. The nine parts of interface documentation
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
212 / 463
C# PDF remove image library: remove, delete images from PDF in C#.
Support removing vector image, graphic picture, digital photo, scanned signature, logo, etc. Able to cut and paste image into another PDF file.
copy picture to pdf; how to copy pdf image into word
VB.NET PDF remove image library: remove, delete images from PDF in
PDF Image Extract; VB.NET Write: Insert text into PDF; C#.NET PDF pages extract, copy, paste, C#.NET Support removing vector image, graphic picture, digital photo
how to copy an image from a pdf to powerpoint; copy image from pdf reader
[ 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
213 / 463
C# HTML5 Viewer: Deployment on ASP.NET MVC
the size of SDK package, all dlls are put into RasterEdge.DocImagSDK a Home folder under Views according to config in picture above. RasterEdge.XDoc.PDF.dll.
copy images from pdf file; how to cut a picture from a pdf document
C# HTML5 Viewer: Deployment on IIS
reduce the size of SDK package, dlls are not put into Xdoc.HTML5 dll files listed below under RasterEdge.DocImagSDK/Bin directory and paste to Xdoc see picture).
how to paste a picture into a pdf document; how to paste a picture in a pdf
[ Team LiB ]
9.5 Documentation across Views
We now turn to the complement of view documentation, which is capturing the information that applies to
more than one view or to the documentation package as a whole. Cross-view documentation consists of
just three major aspects, which we can summarize as how-what-why:
1. 
How
the documentation is laid out and organized so that a stakeholder of the architecture can find
the information he or she needs efficiently and reliably. This part consists of a view catalog and a
view template.
2. 
What
the architecture is. Here, the information that remains to be captured beyond the views
themselves is a short system overview to ground any reader as to the purpose of the system; the
way the views are related to each other; a list of elements and where they appear; and a glossary
that applies to the entire architecture.
3. 
Why
the architecture is the way it is: the context for the system, external constraints that have been
imposed to shape the architecture in certain ways, and the rationale for coarse-grained large-scale
decisions.
Figure 9.3
summarizes these points.
Figure 9.3. Summary of cross-view documentation
HOW THE DOCUMENTATION IS ORGANIZED TO SERVE A STAKEHOLDER
Every suite of architectural documentation needs an introductory piece to explain its organization to a
novice stakeholder and to help that stakeholder access the information he or she she is most interested
in. There are two kinds of "how" information:
A view catalog
A view template
View Catalog
A view catalog is the reader's introduction to the views that the architect has chosen to include in the
suite of documentation.
When using the documentation suite as a basis for communication, it is necessary for a new reader to
determine where particular information can be found. A catalog contains this information. When using the
documentation suite as a basis for analysis, it is necessary to know which views contain the information
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
214 / 463
C# Raster - Modify Image Palette in C#.NET
Read: PDF Image Extract; VB.NET Write: Insert text into PDF; edit, C#.NET PDF pages extract, copy, paste, C#.NET to reduce the size of the picture, especially in
paste image in pdf preview; paste picture pdf
C# Word - Document Processing in C#.NET
Open(docFilePath); //Get the main ducument IDocument doc = document.GetDocument(); //Document clone IDocument doc0 = doc.Clone(); //Get all picture in document
how to copy pictures from pdf in; how to copy picture from pdf to powerpoint
necessary for a particular analysis. In a performance analysis, for example, resource consumption is an
important piece of information, A catalog enables the analyst to determine which views contain properties
relevant to resource consumption.
There is one entry in the view catalog for each view given in the documentation suite. Each entry should
give the following:
1.  The name of the view and what style it instantiates
2.  A description of the view's element types, relation types, and properties
3.  A description of what the view is for
4.  Management information about the view document, such as the latest version, the location of the
view document, and the owner of the view document
The view catalog is intended to describe the documentation suite, not the system being documented.
Specifics of the system belong in the individual views, not in the view catalog. For instance, the actual
elements contained in a view are listed in the view's element catalog.
View Template
A view template is the standard organization for a view. Figure 9.1
and the material surrounding it provide
a basis for a view template by defining the standard parts of a view document and the contents and rules
for each. The purpose of a view template is that of any standard organization: It helps a reader navigate
quickly to a section of interest, and it helps a writer organize the information and establish criteria for
knowing how much work is left to do.
WHAT THE ARCHITECTURE IS
This section provides information about the system whose architecure is being documented, the relation
of the views to each other, and an index of architectural elements.
System Overview
This is a short prose description of what the system's function is, who its users are, and any important
background or constraints. The intent is to provide readers with a consistent mental model of the system
and its purpose. Sometimes the project at large will have a system overview, in which case this section of
the architectural documentation simply points to that.
Mapping between Views
Since all of the views of an architecture describe the same system, it stands to reason that any two views
will have much in common. Helping a reader of the documentation understand the relationships among
views will give him a powerful insight into how the architecture works as a unified conceptual whole.
Being clear about the relationship by providing mappings between views is the key to increased
understanding and decreased confusion.
For instance, each module may map to multiple runtime elements, such as when classes map to objects.
Complications arise when the mappings are not one to one, or when runtime elements of the system do
not exist as code elements at all, such as when they are imported at runtime or incorporated at build or
load time. These are relatively simple one- (or none-) to-many mappings. In general, though, 
parts
of
elements in one view can map to 
parts
of elements in another view.
It is not necessary to provide mappings between every pair of views. Choose the ones that provide the
most insight.
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
215 / 463
Element List
The element list is simply an index of all of the elements that appear in any of the views, along with a
pointer to where each one is defined. This will help stakeholders look up items of interest quickly.
Project Glossary
The glossary lists and defines terms unique to the system that have special meaning. A list of acronyms,
and the meaning of each, will also be appreciated by stakeholders. If an appropriate glossary already
exists, a pointer to it will suffice here.
WHY THE ARCHITECTURE IS THE WAY IT IS: RATIONALE
Similar in purpose to the rationale for a view or the rationale for an interface design, cross-view rationale
explains how the overall architecture is in fact a solution to its requirements. One might use the rationale
to explain
the implications of system-wide design choices on meeting the requirements or satisfying
constraints.
the effect on the architecture when adding a foreseen new requirement or changing an existing one.
the constraints on the developer in implementing a solution.
decision alternatives that were rejected.
In general, the rationale explains why a decision was made and what the implications are in changing it.
[ 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
216 / 463
[ Team LiB ]
9.6 Unified Modeling Language
We have concentrated on the kind of information that should be included in architecture documentation.
Architecture in some sense expresses what is essential about a software system, and that essence is
independent of languages and notations to capture it. Nevertheless, today the Unified Modeling
Language (UML) has emerged as the de facto standard notation for documenting a software architecture.
However, it must be said that UML makes its main contribution in a view's primary presentation, and its
secondary contribution in the behavior of an element or group of elements. It is up to the architect to
augment the UML pictures with the necessary supporting documentation (the element catalog, the
rationale, and so forth) that a responsible job requires. UML provides no direct support for components,
connectors, layers, interface semantics, or many other aspects of a system that are supremely
architectural.
Still, in most cases we can use the constructs that UML does offer to achieve satisfactory effects, at least
in crafting the primary presentations of architectural views. We begin by discussing module views.
MODULE VIEWS
Recall that a module is a code or implementation unit and a module view is an enumeration of modules
together with their interfaces and their relations.
Interfaces
Figure 9.4
shows how module interfaces can be represented in UML. UML uses a "lollipop" to denote an
interface, which can be appended to classes and subsystems, among other things.
UML also allows a class symbol (box) to be stereotyped as an interface; the open-headed dashed arrow
shows that an element realizes an interface. The bottom of the class symbol can be annotated with the
interface's signature information: method names, arguments, argument types, and so forth. The lollipop
notation is normally used to show dependencies from elements to the interface, while the box notation
allows a more detailed description of the interface's syntax, such as the operations it provides.
Modules
UML provides a variety of constructs to represent different kinds of modules. Figure 9.5
shows some
examples. UML has a class construct, which is the object-oriented specialization of a module. Packages
can be used in cases where grouping of functionality is important, such as to represent layers and
classes. The subsystem construct can be used if a specification of interface and behavior is required.
Figure 9.5. Examples of module notations in UML
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
217 / 463
Figure 9.6
shows how the relations native to module views are denoted using UML. Module
decomposition relies on the "is-part-of" relation. The module uses view relies on the dependency relation,
and the module class view relies on the generalization, or "is-a" relation (also called "inheritance").
Figure 9.6. Examples of relation notations in UML. Module B is part of module A, module D
depends on module C, and module F is a type of module E.
Aggregation
In UML, the subsystem construct can be used to represent modules that contain other modules; the class
box is normally used for the leaves of the decomposition. Subsystems are used both as packages and as
classifiers. As packages, they can be decomposed and hence are suitable for module aggregation. As
classifiers, they encapsulate their contents and can provide an explicit interface. Aggregation is depicted
in one of three ways in UML:
Modules may be nested (see Figure 9.7
left
).
Figure 9.7. Decomposition in UML with nesting. The aggregate module is shown as a
package (
left
); decomposition in UML with arcs (
right
).
A succession of two diagrams (possibly linked) can be shown, where the second is a depiction of
the contents of a module shown in the first.
An arc denoting composition is drawn between the parent and the children (see Figure 9.7
right
).
In UML, composition is a form of aggregation with implied strong ownership—that is, parts live and die
with the whole. If module A is composed of modules B and C, then B or C cannot exist without A, and if A
is destroyed at runtime, so are B and C. Thus, UML's composition relation has implications beyond the
structuring of the implementation units; the relation also endows the elements with a runtime property. As
an architect, you should make sure you are comfortable with this property before using UML's
composition relation.
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
218 / 463
Generalization
Expressing generalization is at the heart of UML in which modules are shown as classes (although they
may also be shown as subsystems). Figure 9.8
shows the basic notation available in UML.
Figure 9.8. Documenting generalization in UML with two line styles
The two diagrams in Figure 9.8
are semantically identical. UML allows an ellipsis (…) in place of a
submodule, indicating that a module can have more children than shown and that additional ones are
likely. Module Shape is the parent of modules Polygon, Circle, and Spline, each of which is a subclass,
child, or descendant of Shape. Shape is more general, while its children are specialized versions.
Dependency
The basic notation for dependency was shown in Figure 9.6
. The most architecturally significant
manifestation of dependency is found in layers. Sadly, UML has no built-in primitive corresponding to a
layer. However, it can represent simple layers using 
packages
, as shown in Figure 9.9
. These are
general-purpose mechanisms for organizing elements into groups. UML has predefined packages for
systems and subsystems. We can introduce an additional package for layers by defining it as a package
stereotype. A layer can be shown as a UML package with the constraints that it groups modules together
and that the dependency between packages is "allowed to use." We can designate a layer using the
package notation with the stereotype name <<layer>> preceding the layer name, or introduce a new
visual form, such as a shaded rectangle.
Figure 9.9. A simple representation of layers in UML
COMPONENT-AND-CONNECTOR VIEWS
There is no single preferred strategy to document component-and-connector (C&C) views in UML, but a
number of alternatives. Each alternative has its advantages and disadvantages. One natural candidate
for representing component-and-connector types begins with the UML class concept.
Figure 9.10
illustrates the general idea using a simple pipe-and-filter system. Here, the filter architectural
type is represented as the UML class Filter. Instances of filters, such as Splitter, are represented
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
219 / 463
Documents you may be interested
Documents you may be interested