Defining an Architecture with a COTS-Aware
Software Engineering Process
Lawrence Chung
The University of Texas at Dallas
P.O. Box 830688
Richardson, Texas, USA 75083
chung@utdallas.edu
Kendra Cooper
The University of Texas at Dallas
P.O. Box 830688
Richardson, Texas, USA 75083
kcooper@utdallas.edu
Ruediger Kaffenberger
Marconi Communications GmbH
D-71522 Backnang, Germany
Ruediger.Kaffenberger@marconi.com
Abstract. The goals of developing systems better, faster, and cheaper continue to drive software
engineering practitioners and researchers to investigate software engineering methodologies that
are novel, yet practical. As the size and complexity of systems continues to grow, there has been
a growing interest in the investigation of social paradigms (e.g., agent- and goal-oriented
approaches) and the use of COTS components. These are being viewed more and more as
promising, and also perhaps inevitable, solutions to this problem. The effective application of
social paradigms and use of COTS components, however, requires a systematic approach that
provides a set of concepts for modeling the subject matter, a set of guidelines for using such
concepts, and tool support to assist the developer.
In this paper, we present part of a COTS-Aware Requirements Engineering and Architecting
(CAREA) approach that explicitly supports the use of COTS components. Our CAREA
approach, an extension of our previous work in system and software requirements engineering, is
agent- and goal-oriented, knowledge based, and has a defined process. In particular, we present
part of the process that supports the formal definition of a software architecture. Our CAREA
approach is validated using a Digital Library System example; a prototype of the CAREA
Assistant tool is used to present some of our preliminary results.
Introduction
Engineering practitioners and researchers continue to investigate software engineering
methodologies that offer novel, yet practical solutions to the on-going problem of developing
systems better, faster, and cheaper. As the size and complexity of systems continues to grow,
there has been a growing interest in the investigation of social paradigms (e.g., agent- and goaloriented approaches) and the use of commercial off-the-shelf (COTS) components. These are
being viewed more and more as promising, and also perhaps inevitable, solutions to this
problem. The effective application of social paradigms and use of COTS components, however,
requires a systematic approach that provides a set of concepts for modeling the subject matter, a
set of guidelines for using such concepts, and tool support to assist the developer.
Our work is focused on creating, modeling, and analyzing a goal- and agent-oriented
requirements engineering and architecting approach that explicitly supports the use of COTS
components. Our approach is called the COTS-Aware Requirements Engineering and
Architecting (CAREA) approach. It is agent-oriented as in (Yu 1994)(Wooldridge 2001), goaloriented as in (Anton 1998)(Chung 2000)(van Lamsweerde 2000), has a defined process as in
(Maiden 2002), and is knowledge-based as in (Liu 1995)(Rolland 1994). The CAREA approach
is intended to provide a framework for integrating and extending existing work in agent-oriented,
goal-oriented, requirements engineering (RE), architecture, conceptual modeling, and COTS
research. Due to this integrative approach, there are a number of related techniques that we draw
upon including the Rational Unified Process model (Jacobson 1999)(Krutchen 1998), Model
Based Architecting and Software Engineering framework (Boehm 1998)(Boehm 2000), and the
Procurement Oriented Requirements Engineering technique (Maiden 2002)(Ncube 1999). Due to
space constraints, we refer the reader to (Chung 2002a)(Chung 2002b) for surveys on these
techniques. The CAREA approach is intended to assist the engineer in developing high quality
specifications, not to replace their intelligence and experience. This work may be of interest to
researchers and practitioners involved in developing large-scale, complex systems.
We recognize that developing the CAREA approach is an ambitious project. To accomplish
the work, we are using an iterative approach to define, refine, and validate the CAREA models
and tool support. This iteration is focused on developing the models and tool support for defining
a system architecture. Here, we define a process model to support the definition of a software
architecture. The prototype of the CAREA Assistant Tool is also extended to support the
architecture definition. The approach is validated by applying it to (part of) a Digital Library
System (DLS). This example is selected because it is a complex, non-proprietary system with a
rich set of functional and non-functional requirements. A detailed description of the CAREA
approach (including the process model, product model, meta-model, and ontology) is available in
the complimentary technical report (Chung 2002b).
This paper is organized as follows. Following the introduction, we present an overview of the
CAREA approach from an activity-oriented perspective. This is followed by a description of the
process model that supports the definition of an architecture. Part of the process is illustrated
using a Digital Library System (DLS) example; the architecture is formalized and presented
using a prototype of the CAREA Assistant Tool. We also present some of our lessons learned,
conclusions, and areas for future work.
Overview of CAREA
The CAREA approach is characterized as agent-oriented, goal-oriented, knowledge based,
and has a defined process (refer to Figure 1). On the right side of Figure 1, the early artifacts for
the system under development are accounted for including the agents, softgoals (non-functional
goals that are achieved not absolutely but in a “good-enough” sense), hardgoals (functional
goals), system requirements, software requirements, and architectural elements. The traceability
relationships among the artifacts are also established and maintained (e.g., a softgoal is refined
and traced to specific system requirements). On the left side of Figure 1 the descriptions of the
COTS components are stored and maintained in a knowledge base, or repository. For each COTS
component, the high-level goals (softgoals and hardgoals) and the chosen product specifications
which meet the goals are stored and maintained. The goals provide high-level descriptions of the
capabilities of a COTS component; they contain information like that found on marketing
brochures for existing products. These general descriptions provide enough information, at least
initially, for a RE to determine if the product appears to be potentially useful and, as a result,
warrants further investigation. A product specification is the detailed description of the
functional and non-functional characteristics of the projected system, including its components
and relationships between the components, which, as a means/solution, meets the (potentially
conflicting) goals and constraints of the various stakeholders, technical constraints, laws, etc.
(Davis, 1993) (Loucopolos, 1995); they contain information like that found on the technical
product specifications or data sheets for an existing product. When using the CARE approach,
the RE identifies possibly matching COTS components for the goals and subsequently, the
requirements and architectural elements of the system under development; these mapping
relationships are also established and maintained.
Component Repository
(Component Goals, Specifications, …)
System Under Development
(System Goals, Requirements, Architecture…)
Softgoal2
…
Goaln
Goal1
Goals
Goals
Specification
Specification
Component 2
Component 1
Goals
Specification
System
Requirement
System
Requirement
System
Architecture
…
Hardware
Requirement
Interface
Requirement
Software
Requirement
Subsystem
Architecture
Subsystem
Architecture
Architecture
Elements
Architecture
Elements
Component n
Legend
Mapping System Goals to Component Goals
Mapping Requirements to Component Specification
Mapping Architectures to Component Specifications
Agent
Figure 1. Mapping System Goals, Requirements, and Architectures to Components
In this section, we present an overview of the CAREA process model; a detailed description
is available in (Chung 2002b). An overview of the CAREA process is illustrated in Figure 2
using the IDEF0 notation (FIPS 1993). The IDEF0 notation is activity oriented, and is suitable
for describing a process. Activities in the IDEF0 notation have inputs, mechanisms, controls, and
outputs. An activity transforms inputs into outputs and is represented with a labeled rectangle.
Inputs and outputs are represented with arrows arriving at the left-hand side of the activity and
leaving the right-hand side respectively. Mechanisms are the people or tools that perform the
activity; these are represented with labeled arrows arriving at the bottom of the activity. Controls
are used to constrain when or how the activity can be done; these are represented as labeled
arrows arriving at the top.
At this high level, the activities of the CAREA approach include Define System Agents,
Define System Goals (with COTS), Define System Requirements (with COTS), Define Software
Requirements (with COTS), Maintain COTS Repository, and Define Architecture (with COTS)
(refer to Figure 2). Each of these is described in more detail by decomposing the activity.
The CAREA process defines the goals, requirements, and architecture with an iterative and
interleaving approach; this approach supports the use of COTS components. In CAREA the
selection of possible COTS components begins very early in the development lifecycle when the
goals are being defined (Chung 2002a). The requirements engineer (RE) maps goals and
requirements to possible matches of COTS components by searching, matching, and selecting
from the components in the repository. The RE, with the assistance of the component engineer
(CE) and the system or software architect (SA), considers the functional and non-functional
capabilities and the impact of using a component on the software architecture. If a match is not
found, then the RE has a number of options. The RE may ask the CE to find another component
in the marketplace and add it to the repository. The RE may try bridge the gap between the
customer's needs and the capabilities available in the components by asking the vendor to change
a component or asking the customer to change a goal or requirement. Using this process, the
goals and requirements are negotiated and refined while considering the constraints imposed by
COTS components.
As the goals and requirements are being developed, the SA outlines the system architecture.
When system goals, system requirements, software requirements become available, the SA uses
them to refine the architecture model. With the assistance of the CE, the SA evaluates COTS
components already mapped from goals and requirements and may search, match, and select
additional COTS components in the repository. Again, if a COTS component is not available the
SA has several options. The SA may ask the CE to find another component in the marketplace
and add it to the repository, ask a vendor to change a component, or ask the RE to negotiate a
change to a goal or requirement with the customer. As a result, the goals, requirements, and
system architecture are negotiated and refined while considering the constraints imposed by
COTS components. The artifacts relating the co-definition of the goals and requirements with the
RE and CE Expertise
Initial System Concept,
System Goals
(WIP, Baselined, Corrections),
System Requirements
(WIP, Baselined, Corrections),
Software Requirements
(WIP, Baselined, Corrections),
Component Repository
Architecture (WIP, Baselined , Corrections),
SA Decisions
Define
Architecture
(with COTS)
5
System Goals
(WIP, Baselined, Corrections),
System Requirements
(WIP, Baselined, Corrections),
Software Requirements
(WIP, Baselined, Corrections)
Architecture
(WIP, Baselined, Corrections),
Component Repository
SA
Elicitation Tech.
Initial System Concept,
Enterprise Goals
Define
WIP System Agents,
System
RE Decisions
Agents 1 Baselined System Agents
RE
Initial System Concept,
WIP Architecture,
Component Goals,
Enterprise Goals
Corrections to
System Goals
Update Component Goals,
Update Component Specs.
RE and SA Expertise
Maintain
Component
Repository
CE
Updated Component
6 Repository,
CE Decisions
Elicitation Tech., COTS Decision Tech., SA and CE Expertise
Update Component Goals
WIP System Goals, RE Decisions
Baselined System Goals (with COTS)
Define
System
Goals
2
RE
Component Specs.,
WIP Architecture
Elicitation Technique, COTS Decision Technique
Define
Update Component Specs.
System
WIP System Requirements, RE Decisions
Reqs.
Baselined System Requirements (with COTS)
3
RE
Corrections to System Reqs.
Component Specs.,
WIP Architecture
Elicitation Tech., COTS Decision Tech., SA and CE Expertise
Define
Software
Reqs.
RE
4
Update Component Specs.
WIP Software Requirements,
Baselined Software
Requirements (with COTS),
RE Decisions
Corrections to Software Reqs.
Figure 2. A High Level Activity-oriented View of CAREA
architecture are highlighted in blue in Figure 2.
Defining an Architecture with the CAREA Process
In the overview of the CAREA process (refer to Figure 2), one of the steps is to Define the
Architecture (activity 5). CAREA is concerned with both systems architecture and software
architecture. Since systems engineering is a predecessor to software engineering, we believe it is
of paramount importance to detect model mismatches at the earliest possible moment,
concerning both the context in which the projected software system is to function and the
software system functionality. Here, we focus on defining and validating the activities used to
define the software architecture; we plan to extend CAREA to support the system architecture
definition in the next step of the work. Defining the software architecture is decomposed into
activities to select architectural styles, define, establish traceability from the requirements to the
architecture, analyze, correct, verify, integrate, and baseline subsystems. We (partially) illustrate
the process using a Digital Library System (DLS) example. Due to space constraints, only part of
the example is presented. In each step, the SA documents the decisions and the rationale for the
decisions performing the task.
Select Architectural Style(s). The SA selects one or more architectural styles to define the
overall structure of the software solution. Architectural styles capture a recurring solution to a
recurring problem (Clements 2002). Examples of styles in (Bass 2002) include independent
components (e.g., client server), data flow (e.g., pipe and filter), data-centred (e.g., repository),
virtual machine (e.g. rule based), and call/return (e.g. layered). The SA uses the initial concept of
the system, goals, and requirements to select the style(s); they can overlap or can contain one
another hierarchically.
For the DLS, the SA examines the initial concept of the system to identify the (initial)
architectural styles used; the SA selects client-server, layered, and repository. The overall
structure of the architecture is illustrated in Figure 3.
…
Client
Client
(maximum 500 clients)
Server
CHI Layer
CHI Layer
Loadsharing Configuration
Server
Server Manager Layer (web)
Client Manager Layer
Client Manager Layer
Proxy
Server Manager Layer (web)
Library Repository
Security Layer
Security Layer
Library Repository
Communication Layer
Communication Layer
Communication Layer
Communication Layer
Real Time O/S Layer (Utilities)
Real Time O/S Layer (Utilities)
Real Time O/S Layer (Utilities)
Real Time O/S Layer (Utilities)
Logical Communication
Figure 3. Initial DLS Architecture
Outline
Define Subsystem Architecture. Once the architectural styles are selected, the SA defines the
subsystems. For example, if a layered style is used, then each layer is a subsystem that needs to
be defined in terms of its capabilities (i.e., meets specific functional requirements), interfaces,
and constraints (i.e., meets specific non-functional requirements). As the subsystems are defined,
the SA may update the architectural styles used and/or update the topology (e.g., three layers
may be redefined as two layers). For the DLS, the SA defines the CHI layer as:
Capabilities. The CHI layer manages the presentation of audio, video, and images, a graphical user
interface, supports the extensible markup language (XML), type and range error checking on user
inputs, and builds and decodes requests going to/arriving from Client Manager layer.
Interfaces. The CHI Layer uses the Client Layer to process the following request/responses: log-on,
log-off, add library object, search for library object, modify library object, delete library object, add
user account, modify user account, search for user account, delete user account, …
Constraints. 1) Complies with the following standards: Extensible Markup Language (XML), MPEG,
JPEG, … 2) Non-COTS code is implemented with JAVA.
Establish Traceability. The SA establishes the traceability between the requirements and the
subsystems. For the DLS, the SA traces system requirement 023, which states that the DLS shall
provide the capability to present files in the motion picture expert group 3 standard (MPEG-3), to
the CHI Layer.
Analyze, Correct, and Verify Subsystem Architecture. The SA analyzes each subsystem
description to identify errors of commission (e.g., conflicting, incorrect, or redundant
capabilities, interfaces, or constraints) and omission (e.g., missing capabilities, interfaces, or
constraints). The SA corrects the definitions of the subsystems based on the analysis results.
Once the subsystem is corrected, the SA verifies it with respect to the system goals, system
requirements, and software requirements. The SA identifies errors of commission and omission.
For the DLS, the SA analyzes the subsystem architecture; a number of errors are detected and
corrected. Typical errors include descriptions of capabilities, interfaces, and constraints that are
marked as "TBD" and incomplete references to standards. For example, in the CHI Layer
description the specific version of XML standard not specified and needs to be corrected. The
current version of this standard is 1.0, October 2000. Once the subsystem is corrected the SA
verifies it with respect to the system and software requirements. Using the traceability, a number
of errors are detected in this step. For example, the traceability report indicates the CHI layer
supports the requirement to present audio-video using MPEG-3; this is not included in the layer’s
description and is added.
Define COTS Subsystem Architecture. Once the subsystems are verified, the SA determines if
COTS components are available that may provide the capabilities, match the interfaces, and
match the constraints. Earlier in the CAREA process, potential matches are identified when the
goals and the requirements for the system under development are defined. If components are
already identified, then the SA determines if one or more of the components are a match for the
current definition of the architecture. If one or more components are a good match, then the SA
selects a component. Currently, selection technique in CAREA is ad-hoc (i.e., relies solely on the
experience of the SA). In the future, CAREA will be extended with multi-criteria decision
making techniques. If there is not a good COTS match, then the SA has several options. The SA
may a) determine the impact of selecting one of the possible components on the architecture b)
consult with the CE and request a search for additional components c) consult with the RE and
determine if the requirements can be modified d) develop the subsystem from scratch.
For the DLS, when the SA begins to define the COTS components used in the CHI Layer,
the JAVA Media Framework (JMF) components have already been identified by the RE. After
investigating (reviewing the RE's rationale for selecting the components, searching the
repository, matching and analyzing additional components), the SA determines the JMF is the
best COTS component available to deliver the capabilities needed.
Integration and Baselining. Once subsystems are defined, they need to be iteratively integrated,
analysed, corrected, and verified. The integration may proceed top down, bottom up, or middle
out. This large activity is described in (Chung 2002b). Ultimately, the SA and CM baseline the
verified, integrated architecture and place it under configuration management.
The DLS example is further illustrated using the prototype of the CAREA Assistant Tool.
The prototype supports a subset of the constructs in the meta-model, including the agents, goals,
system requirements, software requirements, COTS components, architecture, and a set of basic
queries. The tool uses the deductive object management database tool called ConceptBase
(ConceptBase 2002), which supports the O-Telos language (Mylopoulos 1990). O-Telos is a
descendant of RML (Greenspan 1994) - an object-oriented requirements modeling language for
functional requirements. O-Telos provides a formal, object-oriented notation with classification,
generalization, aggregation, attribution, and time. Using the semi-formal CAREA architecture,
the classes for the architecture and instances for the DLS example are defined in O-Telos and
included in the knowledge base of the CAREA Assistant Tool. Examples are available in (Chung
2002b). Part of the DLS architecture is presented graphically in Figure 4.
Figure 4. Partial Illustration of the Formalized Architecture
We have already learned a number of lessons in developing this phase of the work. The
formalization into O-Telos class definitions has encouraged the development of a more
complete, consistent, and correct process model. As the model was being developed, it became
an iterative process to define, validate, and correct the definitions. In particular, when
formalizing the subsystem architectures in O-Telos, the following problem arose: How do we
translate parts of the architecture that are defined with overlapping styles? For example, the
client server style defines specific interface types for the process communication; these types
need to be related to layers within the client and sever. After several iterations, this problem is
addressed by refining the definitions, for example, of an interface as a class, not a simple
attribute. With this approach, instances can be related across "chunks", or overlapping styles, of
the architecture. When displaying all the relationships, however, the graphical representation of
the architecture became difficult to read. The GraphicBrowser tool that is available with
ConceptBase currently does not support moving the relationships or the labels on the
relationships. ConceptBase does provide an API; we propose to use the API to build a more
flexible interface for displaying the architecture model.
CONCLUSIONS AND FUTURE WORK
In this paper, our contribution is to present our preliminary work in the CAREA approach
that supports the definition of a software architecture as the goals and requirements are being
defined. We present part of the process model and illustrate it with an example from a Digital
Library System. A more detailed description of CAREA is available in (Chung 2002b). The
activity step to define the architecture is refined into steps to select architectural styles, define
subsystem architectures, establish traceability from the requirements to the subsystem
architectures, analyze, correct, verify, define COTS, and integrate subsystems, and baseline an
architecture. Classes and instances of agents for part of a Digital Library System are formalized
in the O-Telos notation and presented using a prototype of our CAREA Assistant Tool.
As we have only used one example system to validate the work, we recognize that additional
validation with different systems is needed. The next example system we intend to use is a
telepresence system. We also plan to extend and refine the CAREA approach's process, product,
and meta-model and tool support. More specifically, we propose to a) extend the prototype to
support reasoning about contradictory, non-functional goals as in (Chung 2000), b) develop a
better user interface using the API in ConceptBase for the CAREA Assistant Tool, c) extend the
knowledge base with additional architectural styles, and d) extend the approach to support the
definition of a system architecture.
REFERENCES
Antón, A., Potts, C., “The Use of Goals to Surface Requirements for Evolving Systems”, Int.
Conf. on Software Engineering, Kyoto, Japan, 19-25 April 1998, pp. 157-166.
Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice, Addison Wesley
Longman, Inc., 1998.
Boehm, B., Port, D., Abi-Antoun, M., and Egyed, A., “Guidelines for the Life Cycle Objectives
(LCO) and the Life Cycle Architecture (LCA) deliverables for Model-Based Architecting
and Software Engineering (MBASE)”, TR USC-CSE-98-519, USC-Center for Software Eng.
Boehm, B. “Requirements that handle IKIWISI, COTS, and Rapid Change", IEEE Computer,
Vol. 33 Issue: 7, July 2000, pp. 99 –102.
Brownsword, L., Oberndorf, T., and Sledge, C., “Developing New Processes for COTS-Based
Systems”, IEEE Software, July/August 2000, pp. 48-55.
Chung, L., Nixon, B., Yu, E., and Mylopoulos, J., Non-Functional Requirements in Software
Engineering, Kluwer Academic Publishing, 2000.
Chung, L. and Cooper, K., "A COTS-Aware Requirements Engineering Process: a Goal-and
Agent Oriented Approach", Proc. of the Int. Council on Systems Engineering Symposium,
2002 (INCOSE '02), Las Vegas, Nevada.
Chung, L. and Cooper, K., "A COTS-Aware Requirements Engineering and Architecting
Approach: Defining System Level Agents, Goals, Requirements, and Architecture", TR
UTDCS-20-02, The University of Texas at Dallas, 2002.
Clements, P., Kazman, R., and Klein, M. Evaluating Software Architectures Methods and Case
Studies, Addison-Wesley, USA, 2002.
ConceptBase, A deductive object manager for meta databases, Aachen University of Technology
(RWTH), Germany, version 5.2, 2002.
Davis, A. M., Software Requirements: Objects, Functions, States. Prentice Hall: Englewood
Cliffs, 1993.
Federal Information Processing Standard (FIPS) Publication 183, Integration Definition for
Function Modeling (IDEF0), December 21, 1993.
Greenspan, S., Mylopolous, J., and Borgida, A., “On formal requirements modeling languages:
RML revisited”, 16th Int. Conf. on Software Eng., 1994, pp. 135-147.
Jacobson, I., Booch, G., and Rumbaugh, J., The Unified Software Development Process, Addison
Wesley Longman, Inc., USA, 1999.
Kruchten, P., “Modeling Component Systems with the Unified Modeling Language”, Int.
Workshop
on
Component-Based
Software
Eng.,
1998,http://www.sei.cmu.edu/cbs/icse98/papers/p1.html.
Liu, A. and Tsai, J.J.P., "A knowledge-based approach to requirements analysis", 7th Int. Conf.
on Tools with Artificial Intelligence, 1995, pp. 26 - 33.
Loucopoulos, P. and Karakostas, P., System Requirements Engineering, McGraw-Hill, 1995.
Maiden, N.A.M., Kuim, H. and Ncube, C. “Rethinking Process Guideance for Software
Component Selection", Proc. of the 1st Int. Conf. of Component Based Eng., 2002, pp. 151164.
Mylopoulos, J., Borgida, A., Jarke, M., and Koubarakis, M., “Telos: Representing Knowledge
about Information Systems”, ACM Trans. Info. Sys., 8 (4), October 1990, pp. 325-362.
Ncube, C. and Maiden, N., “Guiding parallel requirements acquisition and COTS software
selection”, Proc. of the IEEE Int. Symp. on Requirements Eng. 1999, pp. 133-140.
Rolland, C. and Grosz, G., "A general framework for describing the requirements engineering
process", IEEE Int. Conf. on Systems, Man, and Cybernetics, 1994, vol. 1, pp. 818 - 823.
Yu, E., “Modelling Strategic Relationships For Process Reengineering”, DKBS-TR-94-6, Univ.
of Toronto, Canada, Dec. 1994.
van Lamsweerde, A. and Letier, E., “Handling Obstacles in Goal-Oriented Requirements
Engineering”, IEEE Trans. on Software Eng., Vol. 26, September 2000, pp. 978-1005.
Wooldridge, M. and Ciancarini, P., "Agent-Oriented Software Engineering: The State of the
Art," Handbook of Software Engineering and Knowledge Engineering, World Scientific
Publishing Co., 2001, pp 1-28.
BIOGRAPHIES
Lawrence Chung is an Associate Professor in the department of Computer Science at The
University of Texas at Dallas. He received a Ph.D. in Computer Science from The University of
Toronto, is on the editorial board of Requirements Engineering Journal, and is the principal
author of "Non-Functional Requirements in Software Engineering".
Kendra Cooper is an Assistant Professor in the department of Computer Science at The
University of Texas at Dallas. She received a Ph.D. in Electrical and Computer Engineering from
The University of British Columbia. Her research interests include requirements engineering,
system and software architecture, formal methods, and the empirical assessment of software
engineering methodologies.
Ruediger Kaffenberger has worked as a systems engineer for more than eight years. He is now
with the Access Networks Division of Marconi Communications. Ruediger Kaffenberger
received a M.S. degree in Electrical Engineering from the Univeritat Stuttgart. He is a founding
member of INCOSE German Chapter, and a member of the IEEE and the IEEE Computer
Society.