Download the full version and explore a variety of ebooks

or text books at https://ebookball.com

LNCS 2693 Assessing Componen tBased Systems 1st

Edition by Alejandra Cechich, Mario Piattini,
Antonio Vallecillo ISBN 3540450645 9783540450641

_____ Follow the link below to get your download now _____

https://ebookball.com/product/lncs-2693-assessing-componen-
tbased-systems-1st-edition-by-alejandra-cechich-mario-
piattini-antonio-vallecillo-
isbn-3540450645-9783540450641-14094/

Access ebookball.com now to download high-quality

ebooks or textbooks
 We believe these products will be a great fit for you. Click
the link to download now, or visit ebookball.com
to discover even more!

LNCS 2693 STACE Social Technical Approach to COTS

Software Evaluation 1st Edition by Douglas Kunda ISBN
3540450645 9783540450641
https://ebookball.com/product/lncs-2693-stace-social-technical-
approach-to-cots-software-evaluation-1st-edition-by-douglas-kunda-
isbn-3540450645-9783540450641-10986/

LNCS 2693 Domain Based COTS Product Selection Method 1st

Edition by Hareton Leung, Karl Leung ISBN 3540450645
9783540450641
https://ebookball.com/product/lncs-2693-domain-based-cots-product-
selection-method-1st-edition-by-hareton-leung-karl-leung-
isbn-3540450645-9783540450641-9538/

LNCS 2693 Component Integration through Built in Contract

Testing 1st Edition by Hans Gerhard Gross, Colin Atkinson,
Franck Barbier ISBN 3540450645 9783540450641
https://ebookball.com/product/lncs-2693-component-integration-through-
built-in-contract-testing-1st-edition-by-hans-gerhard-gross-colin-
atkinson-franck-barbier-isbn-3540450645-9783540450641-9564/

LNCS 2693 Driving Component Based Software Development

through Quality Modelling 1st Edition by Colin Atkinson,
Christian Bunse, Jürgen Wüst ISBN 3540450645
9783540450641
https://ebookball.com/product/lncs-2693-driving-component-based-
software-development-through-quality-modelling-1st-edition-by-colin-
atkinson-christian-bunse-ja1-4rgen-wa1-4st-
isbn-3540450645-9783540450641-11762/
LNCS 2693 Component Based Software An Overview of Testing
1st Edition by Auri Marcelo Rizzo Vincenzi, José Carlos
Maldonado, Márcio Eduardo Delamaro, Edmundo Sérgio
Spoto, Eric Wong ISBN 3540450645 9783540450641
https://ebookball.com/product/lncs-2693-component-based-software-an-
overview-of-testing-1st-edition-by-auri-marcelo-rizzo-vincenzi-josa-c-
carlos-maldonado-ma-rcio-eduardo-delamaro-edmundo-sa-c-rgio-spoto-
eric-wong-isbn-3540450645/

Advanced Database Technology and Design 1st Edition by

Mario Piattini, Oscar Diaz ISBN 0890063958 9780890063958

https://ebookball.com/product/advanced-database-technology-and-
design-1st-edition-by-mario-piattini-oscar-diaz-
isbn-0890063958-9780890063958-14260/

Fuzzy Databases Modeling Design And Implementation 1st

Edition by Jose Galindo, Angelica Urrutia, Mario Piattini
ISBN 1591403243 9781591403241
https://ebookball.com/product/fuzzy-databases-modeling-design-and-
implementation-1st-edition-by-jose-galindo-angelica-urrutia-mario-
piattini-isbn-1591403243-9781591403241-10132/

Towards a Metrics Based Framework for Assessing

Comprehension of Software Visualization Systems 1st
Edition by Harkirat Kaur Padda, Ahmed Seffah, Sudhir Mudur
ISBN 9783540733454
https://ebookball.com/product/towards-a-metrics-based-framework-for-
assessing-comprehension-of-software-visualization-systems-1st-edition-
by-harkirat-kaur-padda-ahmed-seffah-sudhir-mudur-
isbn-9783540733454-9532/

Machine Learning for Cybersecurity Cookbook Over 80

recipes on how to implement machine learning algorithms
for building security systems using Python 1st edition by
Emmanuel Tsukerman 9781838556341 1838556346
https://ebookball.com/product/machine-learning-for-cybersecurity-
cookbook-over-80-recipes-on-how-to-implement-machine-learning-
algorithms-for-building-security-systems-using-python-1st-edition-by-
emmanuel-tsukerman-9781838556341-1/
 Assessing Component-Based Systems

Alejandra Cechich1 , Mario Piattini2 , and Antonio Vallecillo3

1
Departamento de Ciencias de la Computación
Universidad Nacional del Comahue, Argentina
[email protected]
2
Grupo Alarcos, Escuela Superior de Informática
Universidad de Castilla-La Mancha, Spain
[email protected]
3
Departamento de Lenguajes y Ciencias de la Computación
Universidad de Málaga, Spain
[email protected]

Abstract. The last decade marked the first real attempt to turn soft-
ware development into engineering through the concepts of Component-
Based Software Development (CBSD) and Commercial Off-The-Shelf
(COTS) components. The idea is to create high-quality parts and join
them together to form a functioning system. The problem is that the
combination of such parts does not necessarily result in a high-quality
system. It is clear that CBSD affects software quality in several ways,
ranging from introducing new methods for selecting COTS components,
to defining a wide scope of testing principles and measurements. Today,
software quality staff must rethink the way software is assessed, includ-
ing all life-cycle phases—from requirements to evolution. Based on cu-
mulated research efforts, the goal of this chapter is to introduce the best
practices of current Component-Based Software Assessment (CBSA). We
will develop and describe in detail the concepts involved in CBSA and
its constituent elements, providing a basis for discussing the different
approaches presented later in this book.

1 Introduction
The use of Commercial Off-The-Shelf (COTS) products as elements of larger sys-
tems is becoming increasingly commonplace. Component-Based Software Devel-
opment (CBSD) is focused on assembling previously existing components (COTS
or other non-developmental items) into larger software systems, and migrating
existing applications towards component-based systems.
CBSD changes the focus of software engineering from one of traditional sys-
tem specification and construction, to one requiring simultaneous consideration
of the system’s context and characteristics (such as user requirements, develop-
ment costs and schedule, operating environments, etc.), the available products
in the software marketplace, and viable architectures and designs. Furthermore,
other engineering activities such as evaluation and acquisition processes, as well
as contracting and licensing strategies, should be incorporated into the software
development life-cycle.

A. Cechich et al. (Eds.): Component-Based Software Quality, LNCS 2693, pp. 1–20, 2003.


c Springer-Verlag Berlin Heidelberg 2003
2 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

The acceptance of CBSD carries along several challenges to the techniques

and tools that have to provide support for it. Some of them are known prob-
lems, such as dealing with COTS production and integration, reducing complex-
ity while improving reliability, and creating interaction models and supporting
middleware. However, other challenges are new: the definition of metrics and
quality attributes to measure software components and compositions, the defini-
tion of COTS selection processes, risk analysis, costs and effort estimation, etc.
These are precisely the issues addressed by Component-Based Software Quality
(CBSQ), which is emerging as a cornerstone discipline for a successful CBSD.
Within the last years, software researchers and practitioners have recognized
the importance of quality in CBSD, and have started working on how quality
has to be established, measured, and ensured both at the individual compo-
nent level and at the system level, which constitute the two flips sides of the
CBSQ coin. In the first case, the problems being addressed range from the pre-
cise definition, measurement, analysis, and evolution of COTS components, to
the definition of tools, methods and processes for software component develop-
ment [39, 40, 52, 53]. At the system level, software researchers and practitioners
have started developing procedures, techniques and models for measuring and
ensuring component-based systems quality [60].
During its relatively brief history, the field of CBSQ has experienced signif-
icant progress. However, CBSQ has not yet advanced to the point where there
are standard measurement methods for any of the issues mentioned above, and
few enterprises properly measure COTS component quality, if measured at all.
Some efforts have started to define software metrics to guide quality and risk
management in component-based systems, by identifying and quantifying vari-
ous factors contributing to the overall quality of the system [9, 60, 61].
Based on cumulated research efforts, the goal of this chapter is to introduce
the best practices of current CBSQ, in particular those that focus on Component-
Based Software Assessment (CBSA). The objective is to provide an overview of
the core elements of CBSA, and of its main issues.
The structure of this chapter is as follows. After this introduction, Section 2
introduces some of the issues that currently challenge CBSQ. Then, Section 3
deals with the core elements of CBSA at the individual component level, while
Section 4 focuses on assessing component-based systems. Finally, Section 5 draws
some conclusions.

2 CBSQ Issues
One can argue that ensuring the quality of component-based systems is much
more difficult than is the case with manufactured goods. The problem is that the
raw material—the software components—may well be of uncertain quality and
their uses and behavior may be only partially known, hindering the effectiveness
of possible quality assessment processes.
There are many potential problems that may affect the assessment of the
quality properties of components and of component-based systems. One way of
categorizing these problems is as follows:
 Assessing Component-Based Systems 3

– Issues related to components when considered as individual parts, that sim-

ply provide and require services (through their provided and required inter-
faces).
– Issues related to component interactions, which may have an explicit context
dependencies about the operating systems or middleware platforms required,
performance and other quality of service (QoS) requirements, or on other
components [33].
– Issues related to component compositions (the combination of two or more
software component yielding a new component).
– Other issues related to acquisition risks, such as vendor maturity level and
trust, economic viability, legal issues, product evolution support, etc.

Let us discuss them more in detail. The first factor concerns uncertainty as
to what constitutes the quality of a component when considered as an individual
resource, i.e., a building block for constructing software systems. Unlike hard-
ware components, for which there are catalogues and data-sheet available for
describing their functional and extra-functional characteristics (to enable their
proper re-use), the situation is not so bright when it comes to software com-
ponents. First, there is no general consensus on the quality characteristics that
need to be considered. Different authors (such as McCall [47] or Boehm [10]) and
different organizations (such as ISO or IEEE) propose different (separate) clas-
sifications, but there is no clear agreement on which to use. The next issue is the
lack of information about quality attributes provided by software vendors. The
Web portals of the main COTS vendors show this fact—visit for instance Com-
ponentsource (www.componentsource.com) or Flashline (www.flashline.com).
In addition, there is an almost complete absence of any kind of metrics that
could help measuring components’ quality attributes objectively. Even worse,
the international standards in charge of defining and dealing with the qual-
ity aspects of software products (e.g. ISO 9126 and ISO 14598) are currently
under revision. The SquaRE project [3] has been created specifically to make
them converge, trying to eliminate the gaps, conflicts, and ambiguities that they
currently present. Furthermore, existing international standards provide very
general quality models and guidelines, very difficult to apply in specific domains
such as CBSD and COTS components.
The solution to the problem is not as obvious as counting with an agreed set
of quality features that the component should exhibit, together with a set of as-
sociated metrics. External factors, such as users’ requirements on the global sys-
tem, architectural constraints, or context dependencies, may also have a strong
influence on the component quality when assessed as a potential part of a larger
system. This is why components may be completely satisfactory on most of
their own attributes or features, but inadequate from a compositional viewpoint.
Therefore, certain key quality features of a composition are also required.
The problems with the quality features of the composition rely both on the
quality features of the individual components, the way they are interconnected,
and on the quality features of the interaction media or middleware used. Thus,
too many factors need to be considered, and in most cases the data may come
4 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

from unreliable, external sources. Even if both the components and the middle-
ware deliver the level of quality advertised by their vendors, what happens if
higher levels of quality are required, or when the evolution of the system impose
new levels of quality over time? Should the composer attempt to work together
with the component or middleware vendors to improve the components’ quality?
Another problem is due to the fact of re-using components. In CBSD, re-using
not only means “using more than once”, but also “using in different contexts”,
in order to achieve all the promised advantages of CBSD [34]. For example, most
people would agree that using the components’ clearly defined and documented
interfaces is enough to accomplish error-free compositions. But this is only true if
components remain confined to the domain of origin, and are never re-used across
platforms or in other contexts. However, if the components are made available
across platforms, then something needs to be done to resolve the inconsistencies
and mismatches that happen at all levels: syntactically, semantically, and quality-
wise.
The problem of ensuring component and component composition quality is
exacerbated by the intrinsic nature of COTS components. The disadvantages
associated with COTS-based design include the absence of source code and the
lack of access to the software engineering artefacts originally used in the design of
the components. Furthermore, whether you have built your system using COTS
components from many vendors, or a single vendor has provided you with an
integrated solution, many of the risks associated with system management and
operation are not under your direct control [44].
Managing conflicting quality requirements is another issue specially interest-
ing in the case of component-based systems. It is necessary to have an awareness
of what could lead to inadequate component quality. “Fitness for use” implies
that the appropriate level of system quality is dependent on the context. Deter-
mining the required quality is difficult when different users have different (even
conflicting) needs. One might be tempted to state that the user requiring the
highest component quality should determine the overall level of quality of the
composed system. But in this way we may be over-imposing quality requirements
to the system and to its individual components, which may be rarely required
in most situations (e.g. in case of requirements imposed by occasional users,
which do not represent the average system users). Thus, it is always necessary
to properly balance conflicting requirements.
Finally, an important issue related to CBSA is about trust. Since we are
going to incorporate to our system one part which has been developed elsewhere,
our fears concerning quality could be reduced if we knew, for example, how the
component was developed and who developed it. Furthermore, such a component
would engender more confidence if someone other than the vendor or developer
could certify, for example, that state-of-the-practice development and testing
processes had been properly applied, that the code has no embedded malicious
behavior [65].
As we can see, there are many issues related to establishing and assessing
the quality of component-based systems. Most of them are general problems of
 Assessing Component-Based Systems 5

quality assessment, common to all software systems, and known for years. But
some of them are new problems, caused by the introduction of COTS components
and CBSD. However, CBSD and COTS components not only have introduced
new problems. They have greatly helped software development technology get
mature enough to overcome many of the technical issues involved, putting us now
in a position from where to start effectively tackling many of the quality aspects
of software development. In this sense, CBSD offers an interesting technology
from where many of the quality questions and problems can be formulated, and
properly addressed.

3 Assessing COTS Components

In this Section we will discuss some of the main methods and techniques for the
assessment of COTS components. In particular, we will cover COTS components
evaluation, certification, and testing.

3.1 COTS Components Evaluation

Typically, the evaluation of COTS components consists of two phases: (1) COTS
searching and screening, and (2) COTS analysis.
COTS component search is a process (i.e., a set of activities) that attempts
to identify and find all potential candidate components that satisfy a set of given
requirements, so they can be re-used and integrated into the application. The
search is generally driven by a set of guidelines and selection criteria previously
defined. Some methods propose a separate process for defining the selection
criteria to be used, while others dynamically build a synergy of requirements,
goals, and criteria [2, 13, 31, 37, 40, 42, 46, 52, 53, 54].
For example, the OTSO (Off-The-Shelf Option) method [39, 40] gradually
defines the evaluation criteria as the selection process progresses, essentially
decomposing the requirements for the COTS software into a hierarchical criteria
set. Each branch in this hierarchy ends in an evaluation attribute: a well-defined
measurement or a piece of information that will be determined during evaluation.
This hierarchical decomposition principle has been derived from both Basili’s
GQM [5, 6] and the Analytic Hierarchy Process [59].
In the CAP (COTS Acquisition Process) proposal [52, 53], the first step is
the identification of the criteria used for evaluating candidate alternatives. Re-
quirements are translated into a taxonomy of evaluation criteria (called “Tailor
& Weight Taxonomy”), and prioritized (or weighted) according to the Analytic
Hierarchy Process, which also takes into account the stakeholders’ interests.
COTS screening aims at deciding which alternatives should be selected for a
more detailed evaluation. Decisions are driven by a variety of factors—foremost
are several design constraints that help define the range of components. Some
methods include qualifying thresholds for screening, i.e., defining and document-
ing the criteria and rationale for selecting alternatives. Some other methods
estimate how much effort will be needed to actually apply all evaluation criteria
to all COTS component candidates during the screening phase.
6 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

The results of the evaluation of the COTS alternatives is then used for making
a decision. A COTS analysis phase starts, in general, from a set of ranked COTS
software alternatives where the top-ranked alternative is measured against a
set of final make-or-buy decision criteria, using for instance a weighted scoring
method, which assigns weights to each criteria. However, measuring all applicable
criteria for all COTS software alternatives can be expensive since: (i) there may
be too many COTS software alternatives; (ii) the set of evaluation criteria could
be quite large; and (iii) some of the criteria might be very difficult or expensive
to measure (e.g., reliability).
The effectiveness of a COTS evaluation method depends on the expressive-
ness of the criteria selected for evaluation. A trade-off between the effectiveness of
the evaluation criteria and the cost, time, and resource allocation of the criteria
must be reached.
In COTS selection, both phases—search and screening, and COTS analysis—
are based on statements about the requirements that need to be much more flex-
ible than traditional ones, i.e. the specified requirements should not be so strict
that either exclude all available COTS, or require large product modification in
order to satisfy them. Requirements Elicitation is an activity by which a variety
of stakeholders work together to discover, and increasingly define, requirements.
Creative thinking is used by requirement elicitation teams to re-structure mod-
els, conceptualize, and solve problems. Some COTS evaluation proposals include
processes to acquire and validate customer requirements [14, 42, 46], while oth-
ers build a selection process based on iteratively defining and validating require-
ments [2, 43]. For instance, the proposal by Alves and Finkelstein [2], identifies
first a set of high-level goals using traditional elicitation techniques, such as
use-cases, which are then used for identifying possible COTS candidates in the
marketplace. Then, new goals can be identified from these components, and the
process starts again. The proposal by Franch et al. [14] uses a two-level selection
process: the global level is responsible of combining the selection requirements
from different areas in an organization, while the local level is responsible of
carrying out the individual selection processes.
However, selecting COTS is not all about confronting component’s services
against technical and extra-functional requirements. As we mentioned earlier,
there is also the issue of trust. Then, some selection methods also include a sup-
plier selection process. The idea is to establish a supplier selection criteria, eval-
uate potential suppliers, rank them according to the agreed criteria, and select
the best-fit supplier(s) [42, 44, 46, 71]. For instance, the V RATE method [44]
defines a taxonomy of vendor risk assessment, which produces a vendor-risk pro-
file tied to real-world performance histories. This profile can be used to assess
the risk associated with the use of a product in a particular environment, and
to identify areas for additional risk-mitigation activities.
Finally, selection cannot be based on exact criteria in real applications. Usu-
ally, users’ requirements are expressed in vague terms, such as “acceptable” per-
formance, “small” size, or “high” adaptability. Measuring COTS components’
quality attributes against such vague requirements is difficult. The QUESTA ap-
 Assessing Component-Based Systems 7

proach [31] addresses this issue by defining some mapping functions, that allow
the assignments of values to such vague requirements.

3.2 Component Certification

Certification is the “procedure by which a third-party gives written assurance
that a product, process, or service conforms to specified requirements” [17].
Current certification practices are basically process oriented, and usually require
early life-cycle processes stressing the software product.
The particular nature of COTS components and component-based systems
also present some challenges to traditional certification. Software certification
must determine whether the software delivers all the functionality that is ex-
pected to deliver, and ensures that it does not exhibit any undesirable behavior.
Ideally, the desirable behavior corresponds to specified requirements, although
having to deal with missing requirements is unavoidable [70]. Therefore, certify-
ing a software product, such as a component, is highly dependent on the quality
of its requirements specification as well as on the quality of its documentation.
Documentation is one of the key issues in CBSD, specially at the compo-
nent level. The black-box nature of components forces documentation to contain
all details needed to understand the functionality provided by the component,
describe how to deploy and install it, and how it should be connected to the
rest of the components in the system. Furthermore, documentation should also
describe the component’s context dependencies and architectural constraints.
Certification strongly relies on the component documentation, since it provides
the “contract” with the requirements that the component behavior should con-
form to.
Another important problem related to component certification has to do with
the application context. In practice, it is very difficult to certify that a component
will behave in a correct manner independently from the context in which it will
operate. However, certifying that a component works as expected within a given
context or application can be more easily accomplished, since it is a matter of
testing it in that particular environment.
Applying software testing techniques and conforming to standards on quality
of components appear to be the most recommended approaches for certification.
As a guidance, the ISO WD-12199-V4 standard [37] is directly applicable to
COTS. It establishes: (1) requirements for COTS software products; (2) require-
ments for tests (including recommendations for the documentation of the tests);
and (3) instructions on how to test a COTS against quality requirements (in-
structions for testing, in particular for third party testing).
Thus, in the context of CBSD, testing becomes the cornerstone process for
certification.

3.3 Component Testing

Software component testing techniques focus on the expected behavior of the
component, trying to ensure that its exhibited behavior is correct [8]. Black-box
testing does not require any knowledge of the internals of the part being tested,
8 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

and therefore is very appropriate for testing COTS components, whose source
code is not available. Strategies for black-box testing include test cases generation
by equivalence classes, error guessing and random tests. These three techniques
rely only on some notion of the input space and expected functionality of the
component being tested [8, 30, 50].
Component-based black-box testing techniques are also based on interface
probing [41, 51]. A developer designs a set of test cases, executes a component on
these test cases, and analyzes the outputs produced. There are a number of black-
box methods for evaluating a component: manual evaluation, evaluation with a
test suite, and automated interface probing. They will depend on how much the
process can be automated, and the sort (and amount) of information available
about the component. One of the major disadvantages of interface probing is
that, frequently, a large number of test cases have to be created and analyzed.
In addition, developers may frequently miss major component limitations and
incorrectly assume certain component functionality. This may lead to incorrect
use of the component when it is integrated with the final software system [51].
A different approach can be followed by automatically creating a system
model from these individual requirements, and then automatically generating
the test cases corresponding to them. In other words, from the requirements, a
system model is automatically created with requirement information mapped to
the model. This information can then be used to generate different tests [68].
Reflection and component metadata can also be effectively used for compo-
nent testing. First, reflection enables a program to access its internal structure
and behavior, providing a mechanism for interrogating and manipulating both.
For instance, Sullivan has used reflection to load a class into a testing tool,
extracting information about some its methods, and calling them with the ap-
propriate parameters [55, 67]. Moreover, since the execution of methods in a
class can create and use instances of other different classes, the approach is also
helpful to test the integration of classes. Component metadata available in most
existing component models can also be used to provide generic usage information
about a component, which can be used for testing [15, 32].
CBSD also introduces some additional challenges to testing: components
must fit into the new environment when they are re-used, often requiring real-
time detection, diagnosis, and handling of software faults.
The BIT (Built-in Tests) technology developed within the Component+ Eu-
ropean project [27] proposes embedding self-test functionality into software com-
ponents, producing self-testable components that can help detect dynamic faults
during run-time. This is a significant advance for improving software reliability
and fault-tolerant capabilities in CBSD [36, 74]. There are some variations for
building BIT-based COTS, such as including the complete test suite inside the
components [75], or just embedding a minimal set of information, such as as-
sertions, inside the components, which can be used at a later stage to define
more complex tests [48]. In both cases there are some issues to consider. First,
including complex tests means consuming space, which can be wasted if only a
few number of tests are actually used. But if just a few information is included,
 Assessing Component-Based Systems 9

or a small number of tests is embedded, additional external software need to be

used to complement the provided tests, or to construct the tests from the compo-
nent specifications. Current approaches try to show how built-in tests might be
integrated by using flexible architectures, without requiring additional software,
and hence minimizing the time spent on testing (see, e.g., [36]).
Finally, testing individual components is not enough for guaranteing the
correctness of the final system. The way in which components are connected
and interact introduce new properties to the system. Therefore, defining “good”
stand-alone component tests may not be enough. Developing a foundation for
testing component-based software is also a complicated issue, even though formal
models of test adequacy for component-based software are being developed [58].

4 Assessment of Component-Based Systems

The assembly of an application based on third-party developed components does
not necessarily assure a defect-free system, even if its constituent components
haven been individually tested and certified. Furthermore, a component-based
system needs to be tested on several aspects such as strategic risk analysis; risk-
based process definition (for software components); risk-based design of compo-
nent software (including initialization, fail-safe and fault-tolerant concepts, and
built-in tests); risk-based component software analysis and design testing; soft-
ware testing, including failure-mode and stress testing; documentation review;
and assessment of hardware requirements [23].
In this Section we will concentrate on those quality issues than trespass the
individual COTS components frontiers, and that arise only when the components
are combined to form a functioning system.

4.1 COTS Integration and Software Architecture

In CBSD, most of the application developer’s effort is spent integrating compo-
nents, which provide their services through well-defined interfaces. It is extremely
important that component services are provided through a standard, published
interface to ensure interoperability [33].
Component architectures divide software components into requiring and pro-
viding services: some software components provide services, which are used by
other components. The system’s Software Architecture connects participating
components, regulating component interactions and enforcing interaction rules.
Software architectures and component technologies can be considered as com-
plementary, and there is ample scope for their conceptual integration [73].
Some of the quality properties at the system level must be also enforced by
the system’s software architecture, which have to use the components’ individ-
ual quality properties to deliver the required level of system quality. In addition,
interaction patterns (usually encapsulated into connectors in the architecture)
have also an strong effect on the global system quality, and their quality proper-
ties should also be incorporated into the quality assessment of the final system.
Another important issue when integrating components to build a functioning
system deals with the mismatches that may occur when putting together pieces
10 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

developed by different parties, usually unaware of each other. In this sense, Basili
et al. [77] present a general classification of possible kinds of mismatches between
COTS products and software systems, which includes architectural, functional,
non-functional, and other issues. Incompatibilities are essentially failures of the
components’ interactions, so the authors claim that finding and classifying these
interactions may help finding and classifying the incompatibilities.
Three aspects of inter-component interactions and incompatibilities can be
considered: the kind of interacting components, the interoperability level re-
quired (syntactic, protocol, or semantic), and the number of components par-
ticipating in the interaction. Different incompatibilities have different solutions,
and the classes of problems are specific to the particular development phases. As
another example, the work by Egyed et al. [28] combines architectural modelling
with component-based development, showing how their mismatch-detection ca-
pabilities complement each other. The software architecture provides a high-level
description of the components and their expected interactions. Architectural
mismatches can be caused by inconsistencies between two or more constraints
of different architectural parts being composed.
As important as determining architectural mismatches is calculating the inte-
gration effort. Decisions on component-based systems investments are strongly
influenced by technological diversity: current technology is diverse and brings
with it thousands of choices on components, with their opportunities and risks.
Firms that avoid single technologies, and implement a diverse set of technologies
and/or applications tend to focus their investments on innovative infrastructure,
which might be the basis for new component-based system. Determining the ef-
fort required to integrate components into that infrastructure is essential to make
a decision on migrating to CBSD. However, estimation is not straightforward.
BASIS [4], for example, combines several factors in order to estimate the effort
required to integrate each potential component into an existing architecture—
architectural mismatches, complexity of the identified mismatch, and mismatch
resolution. The final estimate describes the complexity of integrating a COTS
component and is called the difficulty of integration factor. We should note that
the BASIS approach also includes techniques for evaluating the vendor viability
and the COTS component itself, determining a relative recommendation index
for each product based on all factors.
Measuring complexity of the component’s interactions also implies analyzing
interfaces and messages. Some proposals in this direction propose to measure the
complexity of the interactions—and their potential changes—by using metrics
derived from information theory. For instance, the L-metric [18, 64] offers a static
quantitative measure of the entropy caused by how the components interact as
the system performs.
Finally, architectures used to build composite applications provide a design
perspective for addressing interaction problems. Although little attention is paid
to the evolvability of these architectures, it may also be necessary to estimate
the effect on evolution in a system design in order to improve its robustness [24].
 Assessing Component-Based Systems 11

4.2 Cost Estimation

All CBSD projects require a cost estimation before the actual development ac-
tivities can proceed. Most cost estimates for object-based systems are based on
rules of thumb involving some size measure, like adapted lines of code, number
of function points added/updated, or more recently, functional density [1, 26].
Using rules such as the system functional density, the percentage of the overall
system functionality delivered per COTS component can also be determined,
considering that the number of COTS components in a system should also be
kept under a manageable threshold. However, in practical terms, rules such as
functional density imply that (1) there must be a way of comparing one system
design to another in terms of their functionality; (2) there must a way to split
functionality delivered by COTS from that delivered from scratch; and (3) there
must be a way to clearly identify different COTS functionalities.
Cost is not independent but a function of the enterprise itself, its particu-
lar software development process, the chosen solution, and the management and
availability of the resources during the development project. The cost of updating
and/or replacing components is highly situational, and depends on the organiza-
tion’s specific internal and external factors. Cost estimation should include the
cost of project management, direct labor, and identification of affected software,
affected data, and alternative solutions, testing and implementation. The accu-
racy of most cost estimates should improve during a project as the knowledge
of the problem and the resources required for its solution increases. Some cost
models are iterative, indicating change and re-evaluation throughout the solu-
tion stages. The most extended model on COTS integration cost—the COCOTS
model [10, 22]—follows the general form of the COCOMO models, but with an
alternative set of cost drivers addressing the problem of actually predicting the
cost of performing a COTS integration task. Five groups of factors appear to in-
fluence COTS integration cost as indicated by the relatively large set of drivers:
product and vendor maturity (including support services); customization and
installation facilities; usability; portability; and previous product experience. In
addition, COCOMO II model drivers such as architecture/risk resolution, devel-
opment flexibility, team cohesion, database size, required reusability, etc., can
be added to produce an integral COTS cost model. The goal is to provide the
infrastructure for an easy integration of multiple COTS components. However,
a cost model cannot easily put aside each of the problems encountered when
integrating multiple COTS. In the migration to a component-based system, we
would like to exercise the policy Don’t throw anything away, use and re-use as
much as you can. However, integrating existing software and COTS components
as a whole is not a trivial task and may cause too many adaptation conflicts.
The cost model should provide mechanisms for dealing with the more com-
mon and more challenging integration problems, such as the following.
– Problems that happen when two or more components provide the same ser-
vices with different representations.
– Problems that happen when a component has to be modelled by integrating
parts of functionality from different components (or from other sources).
12 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

– Problems that happen when the resulting architecture does not cover the
desired application requirements.
– Problems that happen when two or more integrated components with differ-
ent implementations fail to interoperate.

While these problems might represent mainly one-time costs, the manage-
ment-phase costs of CBSD recur throughout the system life-cycle, including dur-
ing maintenance.
One of the most important problems of the maintenance process is the esti-
mation and prediction of the related efforts. The different maintenance activities
may present several related aspects: re-use, understanding, deletion of existing
parts, development of new parts, re-documentation, etc. These aspects are rel-
evant to all classes of systems, including object-oriented and component-based
systems [29]. However, one of the most important distinguishing factors in CBSD
is the separation of the interface and the implementation. The interface is usually
realized by one or more components. Larger components may have more complex
interfaces and represent more opportunity to be affected by change. Thus, com-
ponents and component-based systems by nature are a source of changes stressed
by potentially incompatible versions of components, which may compete with
themselves.
When adapting a component-based system to changing requirements, in-
variant conditions are usually specified via constraint languages or specifically
defined mechanisms. For instance, the context-based constraint (CoCon) mech-
anism [43] specifies one requirement for a group of indirectly associated compo-
nents that share a context, which refers the state, situation or environment of
each component. The mechanism requires that monitoring points (interception
points between components) be determined for each invocation path. However,
the main problem of this approach is precisely how to determine the context’s
property values of the components involved in this path.
In general, component technologies also impose some design constraints on
software component suppliers and composers. These constraints are expressed as
a component model that specifies required component interfaces and other devel-
opment rules [33]. The focus of actual compositional rules is on syntactic aspects
of composition, as well as on environmental and behavioral ones. For example,
Ralf Reussner et al. [56] deal with the prediction of properties of compositions
based on the properties of their basic components. Parameterized contracts that
depend on the environment are defined, allowing timing behavior (and hence re-
liability) be analyzed by including timing behavior of the environmental services
used by the component.
Reasoning abut behavioral composition is also as important as detecting in-
teraction mismatches. The Predictable Assembly from Certifiable Components
(PACC) [63] is an initiative at the Carnegie Mellon University–Software Engi-
neering Institute (CMU-SEI) that tries to provide support for predicting be-
havioral properties of assemblies before the components are actually developed
or purchased. Prediction-Enabled Component Technology (PECT) is a technol-
ogy that supports composing systems from pre-compiled components in such a
 Assessing Component-Based Systems 13

way that the quality of the system can be predicted before acquiring/building
its constituents [35]. PECT makes analytic assumptions explicitly ensuring that
a component technology satisfies the assumptions through a demonstration of
“theoretical validity”. It also ensures that predictions based on an analysis tech-
nology are repeatable through a demonstration of “empirical validity”. Current
research efforts focus on prediction of assembly properties such as latency and
reliability.
Documentation is also another key to the success of the CBSD. In case of
component-based systems, documentation should contain all the information
about the system’s structure and internal interconnections. For instance, En-
sembles [72] is a conceptual language which enriches the system documentation
by making explicit the links between component properties and component in-
teractions. Ensembles also support graduated and incremental selection of tech-
nologies, products, and components.
In general, the composer does not need to understand all aspects of a com-
ponent-based system, but should be able to identify its constituent components,
and be able to search for components that may provide the functionality required
by the architecture. In addition, it has been suggested that component docu-
mentation should be extensible, allowing the composer to insert details about
component adaptations directly onto a system document library or annotating
components. For example, annotations can be used to perform dependence anal-
ysis over these descriptions [66]. In addition, the system documentation should
be closely tied to the composing tools, so the selected and tailored components
are easily translated into reusable component libraries [16].

4.3 CBSD Risk Analysis

Software development is a quickly changing, knowledge-intensive business in-
volving many people working in different phases and activities. Activities in soft-
ware engineering are diverse, and the proportion of component-based systems is
steadily growing. Organizations have problems identifying the content, location,
and use of diverse components. Component composition requires access to tan-
gible and intangible assets. Tangible assets, which correspond to documented,
explicit information about the component, can vary from different vendors al-
though usually include services, target platforms, information about vendors,
and knowledge for adaptation. Intangible assets, which correspond to tacit and
undocumented explicit information, consist of skills, experience, and knowledge
of an organization’s people.
Although the Risk Management Paradigm [76] continues to be useful as an
overall guide to risk analysis, the majority of risk management studies deal with
normative techniques for managing risk. Software risks may come from different
dimensions: (1) environmental contingencies such as organizational environment,
technologies, and individual characteristics; and (2) risk management practices
such as methods, resources, and period of use [7, 57].
A few studies have classified software risk items, including CBSD risk analy-
sis. These studies consider CBSD risks along several dimensions, providing some
14 Alejandra Cechich, Mario Piattini, and Antonio Vallecillo

empirically-founded insights of typical cases and their variations. For example,

the BASIS technique [4] focuses on reducing risks in CBSD by means of several
integrated processes. One of them, the Component Evaluation Process [54], tries
to reduce the risk of selecting inappropriate COTS components. Another process
aims at reducing the risk of downstream integration problems through early as-
sessment of the compatibility between a chosen COTS product and an existing
system. Finally, a third process tries to reduce risks throughout the develop-
ment life-cycle by defining built-in checkpoints and recommending measurement
techniques. A vendor analysis is carried out along with these three processes.
Software project managers need to make a series of decisions at the begin-
ning of and during projects. Because software development is such a complex
and diverse process, predictive models should guide decision making for future
projects. This requires having a metrics program in place, collecting project data
with a well-defined goal in a metrics repository, and then analyzing and process-
ing data to generate models. It has also been shown how metrics can guide risk
and quality management, helping reduce risks encountered during planning and
execution of CBSD [60, 61]. Risks can include performance issues, reliability,
adaptability, and return on investment. Metrics in this case are used to quantify
the concept of quality, aiming at investigating the tradeoffs between cost and
quality, and using the information gained to guide quality management. The
primary considerations are cost, time to market, and product quality.

4.4 Software Product Lines

In this last Section we will discuss the quality assessment issues of one of the
most promising approaches for developing component-based systems, specially
in some well-defined application domains: software product lines [11, 21, 69].
A software product line is a “set of software-intensive systems sharing a
common, managed set of features that satisfy the specific needs of a particular
market or mission and that are developed from a common set of core assets in
a prescribed way” [21]. So, within the product line, it is necessary to determine
what products are needed, how to develop those products, how to manage the
evolution of them, and how to re-use them. The idea is to achieve high levels
of intra-organizational re-use. Products become “components” in a product line
approach, where product-line architectures are the basis for software component
re-use.
Software product lines not only help developing software applications, but
also help dealing with some quality issues in a controlled way. Of course, dealing
with quality assessment and risk management in product lines involves a whole
world of new methods and techniques—from requirement analysis to testing.
However, the common nature of SPL facilitates the treatment of some of their
quality issues.
For example, Chastek et al. [20] specify requirements for a product line us-
ing a model whose primary goal is to identify and analyze opportunities for
re-use within requirements. The model has two main characteristics: (1) it spec-
ifies the functionality and quality attributes of the products in the product line;
 Assessing Component-Based Systems 15

and (2) its structure shows decisions about commonalities across the product
line. The work products are based on object modelling, use-case modelling, and
feature-modelling techniques. They form the basis of a systematic method for
capturing and modelling the product line requirements, where five types of anal-
ysis are introduced: commonality and variability analysis, model consistency
analysis, feature interaction analysis, model quality analysis, and requirements
priority analysis.
As another example of mastering quality in software product lines, the frame-
work published in [21] describes the essential practice areas for software engi-
neering, technical management, and organizational management. A practice area
is a body of work or a collection of activities that an organization must master
to successfully carry out the essential work of a product line. The software en-
gineering practice areas include those practices needed to apply the appropriate
technology to create and evolve both core assets and products. The framework
seems to have some similarities when compared to CMMI models [38, 62], where
the major organizing element is the process area. Here, a process area is a group of
related activities that are performed collectively to achieve a set of goals. Hence,
the wide acceptance of the “capability models” has turned research into devel-
oping maturity models for product lines [12], which aims at providing guidelines
for dealing with intra-organizational re-use.
On the other hand, testing in product lines environments involves testing
assets as well as products. But a software product line organization must main-
tain a number of complex relationships. There are relationships between the
group that develops the core assets and those who develop products, between
the general product line architecture and specific product architectures, between
versions of these architectures and versions of products. As a general rule, Mc-
Gregor proposes structuring the relationships among test artifacts to mirror the
structure of the relationships among production artifacts, so a more efficient
test implementation can be produced [49]. In this case, the test architect carries
the responsibility for achieving the quality properties defined in the test plan.
The architect defines the structure of the test software and defines the basic
test assets. This test software architecture can then be specialized to the specific
environment, quality properties, and constraints of a given product.
Finally, the use of metrics has proven to be helpful in assessing particular
situations to guide architectural decisions. For product line architectures (PLA),
the work reported by Dincel et al. [25] focuses on PLA-level metrics for system
evolution. In particular, they provide an incremental set of metrics that allows an
architect to make informed decisions about the usage levels of architectural com-
ponents, the cohesiveness of the components, and the validity of product family
architectures. However, the experience with these metrics is limited, requiring
further validation.

5 Conclusions
There are many benefits derived from CBSD, which has become one of the key
technologies for the effective construction of large, complex software systems
Other documents randomly have
different content
The Project Gutenberg eBook of The Origin of
Tyranny
 This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

Title: The Origin of Tyranny

Author: P. N. Ure

Release date: June 10, 2020 [eBook #62364]

Most recently updated: October 18, 2024

Language: English

Credits: E-text prepared by Richard Tonsing, Turgut Dincer, and

the Online Distributed Proofreading Team
(http://www.pgdp.net) from page images generously
made available by Internet Archive
(https://archive.org)

*** START OF THE PROJECT GUTENBERG EBOOK THE ORIGIN OF

TYRANNY ***
The Project Gutenberg eBook, The Origin of Tyranny, by P. N. (Percy
Neville) Ure

Note: Images of the original pages are available through Internet Archive. See
https://archive.org/details/originoftyranny00urepuoft
 THE
ORIGIN OF TYRANNY

CAMBRIDGE UNIVERSITY PRESS

C. F. CLAY, Manager
LONDON: FETTER LANE, E.C. 4

NEW YORK: THE MACMILLAN CO.

BOMBAY }
CALCUTTA } MACMILLAN AND CO., Ltd.
MADRAS }

TORONTO: THE MACMILLAN CO. OF CANADA, Ltd.

TOKYO: MARUZEN-KABUSHIKI-KAISHA

ALL RIGHTS RESERVED

 THE
ORIGIN OF TYRANNY

BY
P. N. URE, M.A.
GONVILLE AND CAIUS COLLEGE, CAMBRIDGE
PROFESSOR OF CLASSICS, UNIVERSITY COLLEGE, READING

CAMBRIDGE
AT THE UNIVERSITY PRESS
1922
PRINTED IN GREAT BRITAIN.
 PREFACE

T he views expressed in the following chapters were first published

in the Journal of Hellenic Studies for 1906 in a short paper
which gave a few pages each to Samos and Athens and a few
sentences each to Lydia, Miletus, Ephesus, Argos, Corinth, and
Megara. The chapters on Argos, Corinth, and Rome are based on
papers read to the Oxford Philological Society in 1913 and to the
Bristol branch of the Classical Association in 1914.
As regards the presentation of my material here, it has been my
endeavour to make the argument intelligible to readers who are not
classical scholars and archaeologists. The classics have ceased to be a
water-tight compartment in the general scheme of study and
research, and my subject forms a chapter in general economic
history which might interest students of that subject who are not
classical scholars. On the other hand classical studies have become
so specialised and the literature in each department has multiplied
so enormously that unless monographs can be made more or less
complete in themselves and capable of being read without referring
to a large number of large and inaccessible books, it will become
impossible for classical scholars to follow the work that is being done
even in their own subject beyond the limits of their own particular
branch. For these reasons ancient authorities have been mainly given
in literal English translations, and when, as happens in almost every
chapter, information has to be sought from vases, coins, or
inscriptions, I have tried to elucidate my point by means of
explanatory descriptions and illustrations.
The work has involved me in numerous obligations which I gladly
take this opportunity of acknowledging. In 1907 I received grants
from the Worts travelling bachelors’ fund of Cambridge University
and from Gonville and Caius College to visit Greece for the purpose
of collecting archaeological evidence upon the history of the early
tyranny. This purpose was partially diverted because shortly after
reaching Greece I became associated with the late Dr R. M. Burrows
in the excavation of the Greek cemetery at Rhitsona in Boeotia and in
the study and publication of the pottery found there. This pottery
dates mainly from the age of the tyrants, and the results of my work
at it appear in several of the succeeding chapters. To Dr Burrows I
owe also the encouragement that led me to start working on the early
tyranny: my main idea on the subject first occurred to me when I was
lecturing on Greek history as his assistant at University College,
Cardiff.
I have also received much assistance at various times and in
various ways from Professor G. A. T. Davies, another former
colleague of mine at Cardiff, and from several of my Reading
colleagues, particularly Professor W. G. de Burgh, Mr D. Atkinson,
and my wife. Many other debts are recorded in the body of the book:
but considering how many and various they have been, I can scarcely
hope that none has been passed over without acknowledgement.
But of all my obligations the earliest and chiefest is to Sir William
Ridgeway. It is to the unique quality of his teaching at Cambridge
that I owe the stimulus that suggested to me the explanation here
offered of the origin of tyranny.
P. N. URE.

University College,
Reading.
October 1920.
CONTENTS
CHAP. PAGE
I INTRODUCTION 1

II ATHENS 33

III SAMOS 68

IV EGYPT 86

V LYDIA 127

VI ARGOS 154

VII CORINTH 184

VIII ROME 215

IX SICYON, MEGARA, MILETUS, EPHESUS,

LEONTINI, AGRIGENTUM, CUMAE 257

X CAPITALIST DESPOTS OF THE AGE OF

ARISTOTLE, THE MONEY POWER OF THE
RULERS OF PERGAMUM, PROTOGENES OF
OLBIA 280

XI CONCLUSION 290

APPENDICES 307

INDEX 339
ILLUSTRATIONS
FIG. PAGE
1 Lophos Loutrou from Daskalio station 42

2 On the road from Daskalio station to Plaka 42

3 Kamaresa 43

4 Kitsovouno from Kamaresa 43

Figs. 1–4 from photographs by the author)

5 Corinthian terra cotta tablet depicting a miner at work 46

Antike Denkmäler, I)

6 Coin of Athens with Athena and owl 53

Macdonald, Evolution of Coinage)

7 Athenian coins: the wreath on the head of Athena 56

Bulletin de Correspondance hellénique, XXX)

8 Persian “archer” 57

9 Samian coin with Samaina and Messanian coin with

hare 75
Hill, Historical Greek Coins)

10 Aiakes, father of Polycrates 82

Athenische Mitteilungen, 1906)

11 Psamtek I 86
Petrie, Hist. Egypt, III)

12 Vase with cartouche of Bocchoris found at Tarquinii 94

Monumenti Antichi della R. Acc. dei Lincei, VIII)

13 Rhodian or (?) Milesian vase found at Naukratis 111

Gardner, Naukratis II. By permission of the Egypt
Exploration Fund)
14 Fikellura or (?) Samian vase found at Daphnae 113
Petrie, Tanis II. By permission of the Egypt
Exploration Fund)

15 Naukratite vase found at Rhitsona in Boeotia 115

Journ. Hellenic Studies, 1909)

16 Perfume vase found at Naukratis 119

Gardner, Naukratis II. By permission of the Egypt
Exploration Fund)

17 Greek wine jar found at Naukratis 120

Petrie, Naukratis I. By permission of the Egypt
Exploration Fund)

18 Corinthian vase with cartouche of Apries 124

Gazette Archéologique, 1880)

19 Coins of (a) Gyges (?), (b) Croesus 127

Macdonald, Evolution of Coinage)

20 Early Aeginetan “tortoises” 154

Babelon, Traité des Monnaies Gr. et Rom.)

21 Bundle of spits found in the Argive Heraeum 163

22 Corinthian vase found at Corinth 185

From a photograph supplied by Miss Walker of the
American School of Archaeology at Athens)

23 Corinthian terra cotta tablet depicting a potter at his

wheel 186
Gazette Archéologique, 1880)

24 Corinthian terra cotta tablet depicting the interior of a

kiln 186
Antike Denkmäler, I)
25 Coins of Corinth 188
Brit. Mus. Cat. Coins Corinth)

26 Coins of Cypsela 200

Abhandl. Bayerische Akad. Phil. Class. 1890)

27, Attic vase paintings, perhaps depicting cypselae

28 202
Saglio, Dict. d. Antiq. figs. 2964, 2965)

29 Attic vase painting, perhaps depicting a cypsele 203

Saglio, Dict. d. Antiq. fig. 937)

30 Vase on stove found at Iasos 205

Jahrb. d. arch. Inst. 1897)

31 Relief, perhaps depicting a small cypsele 206

Revue Archéologique, 1869)

32 Aes signatum 220

Haeberlin, Aes Grave)

33 Aes grave with wheel 232

Hill, Historical Roman Coins)

34 Corinthian vase found at Tarquinii 241

35 Corinthian terra cotta tablet depicting the export of

vases 242
Antike Denkmäler, I)

36 Proto-Corinthian vase found in the Roman Forum 249

Notiz. d. Scavi della R. Acc. dei Lincei, 1903)

37 Ionic terra cotta antefix found in Rome 250

Monumenti Antichi della R. Acc. dei Lincei, XV)
38 Similar antefix found in Samos 251
Boehlau, Aus ion. u. ital. Nekropolen)

39 Terra cotta head found on the Roman Capitol 252

Monumenti Antichi della R. Acc. dei Lincei, XV)

40 Stone head found on the Acropolis at Athens 253

Athenische Mitteilungen, 1879)

41 Vase in Attic black figure style found on the Quirinal 254

Monumenti Antichi della R. Acc. dei Lincei, XV)

42 The Capitoline wolf 254

How and Leigh, Hist. of Rome. By arrangement
with Messrs Longmans Green & Co.)

43 Dipylon vase 314

Companion to Greek Studies, Cambridge)

44 Proto-Corinthian vase 315

Journ. of Hellenic Studies. By permission of the
Council of the Society for the Promotion of Hellenic
Studies)

45 Dipylon Ships 322

Rev. Arch. XXV, 1894; Athenische Mitt. 1876; Arch.
Zeitung, 1885; Perrot and Chipiez, Hist. de l’Art dans
l’Antiquité)

46 Vase painting signed by Aristonothos 323

Walters and Birch, Hist. of Ancient Pottery)

τοῖσι ἐμφανέσι τὰ μὴ γιγνωσκόμενα τεκμαιρόμενος.

Hdt. ii. 33.

 Chapter I. Introduction

Δόξαιεν γὰρ ‹ἂν› οὐδὲν λέγειν δίκαιον οἱ διὰ τὸν πλοῦτον ἀξιοῦντες ἄρχειν.

Aristot. Pol. III. 1283b.

Φαῦλον τὸ τὰς μεγίστας ὠνητὰς εἶναι τῶν ἀρχῶν.

Aristot. Pol. II. 1273a.

The seventh and sixth centuries B.C. The seventh

constitute from many points of view one of century B.C. is
the age
the most momentous periods in the whole
of the world’s history. No doubt the greatest final achievements of
the Greek race belong to the two centuries that followed. But
practically all that is meant by the Greek spirit and the Greek genius
had its birth in the earlier period. Literature and art, philosophy and
science are at this present day largely following the lines that were
then laid down for them, and this is equally the case with commerce.
It was at the opening of this epoch that the (a) of the first
Greeks or their half hellenized neighbours known metal
the Lydians brought about perhaps the coins,
most epoch-making revolution in the whole history of commerce by
the invention of a metal coinage like those that are still in circulation
throughout the civilized world.
It was no accident that the invention was made precisely at this
time. Industry and commerce were simultaneously making
enormous strides. About the beginning of the seventh century the
new Lydian Dynasty of the Mermnadae made Sardis one of the most
important trading centres that have arisen in the world’s history. The
Lydian merchants became middlemen between Greece and the Far
East. Egypt recovered its prosperity and began rapidly to develop
commercial and other relations with its neighbours, including the
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookball.com