this material is approved for public release. distribution is limited by the software engineering...
TRANSCRIPT
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees.
Sponsored by the U.S. Department of Defense© 2002 by Carnegie Mellon University
Version 1.5 page 1
Pittsburgh, PA 15213-3890
1
Software Architecture Software Architecture in Practicein PracticePaul C. Clements
Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890
Sponsored by the U.S. Department of Defense© 2002 by Carnegie Mellon University
Carnegie Mellon University
Software Engineering Institute
© 2002 by Carnegie Mellon University Version 1.5 page 2
The SEI: Who we are -1
The Software Engineering Institute (SEI) is
• a federally funded research and development center
• sponsored by the U. S. Department of Defense
• hosted by Carnegie Mellon University in Pittsburgh
• staffed by about 200 people
The SEI’s core purpose is to help others make measured improvements in their software engineering capabilities.
© 2002 by Carnegie Mellon University Version 1.5 page 3
The SEI: Who we are - 2
First objective:
• Accelerate the introduction and widespread use of high-payoff software engineering practices and technology by identifying, evaluating, and maturing promising or underused technology and practices.
We are a small organization. We have to pick these practices carefully.
One we have chosen isSoftware architecture
© 2002 by Carnegie Mellon University Version 1.5 page 4
The Ascendance of Software ArchitectureOver the past 10 years, software architecture has emerged as the prominent paradigm in large-system development.
There are:
• worldwide conferences devoted to it
• books devoted to it
• defined “architect” roles in organizations
• courses and training for it
© 2002 by Carnegie Mellon University Version 1.5 page 5
And yet...
It is still not well understood in some circles.
Some organizations have no “architect” position. Others have the position but it is informally defined.
Some organizations are still proceeding to development without an architecture in place.
The tools of the trade -- styles and patterns, views, evaluation -- are used sparingly if at all.
© 2002 by Carnegie Mellon University Version 1.5 page 6
Today’s talk
What is software architecture and why is it important?
A benefit of architecture: Software product lines
Evaluating software architectures
Documenting software architectures
© 2002 by Carnegie Mellon University Version 1.5 page 7
Today’s talk
What is software architecture and why is it important?
A benefit of architecture: Software product lines
Evaluating software architectures
Documenting software architectures
© 2002 by Carnegie Mellon University Version 1.5 page 8
What Is Software Architecture?
Software architecture is the structure or structures of
the system, which comprise software elements, the
externally visible properties of these elements, and
the relationships among them.
The exact structures to consider
and the ways to represent
them vary according to
engineering goals.
© 2002 by Carnegie Mellon University Version 1.5 page 9
Implications of this Definition – 1
A software architecture is an abstraction of a system.
• Architecture defines elements and how they interact.
• Architecture suppresses purely local information about elements; private details are not architectural.
Externally-visible properties of elements are assumptions that one elements can make about another:
• provided services, required services, performance characteristics, fault handling, resource usage
© 2002 by Carnegie Mellon University Version 1.5 page 10
Implications of this Definition – 2
Every system has an architecture.
• Every system is composed of elements and there are relationships among them.
• In the simplest case, a system is composed of a single elements, related only to itself.
Just having an architecture is different from having an architecture that is known to everyone:
• The architecture versus specification of the architecture
If you don’t explicitly develop an architecture, you will get one anyway – and you might not like what you get.
© 2002 by Carnegie Mellon University Version 1.5 page 11
Implications of this Definition – 3
This means that box-and-line drawings alone are not architectures; but they are just a starting point.
• You might imagine the behavior of a box labeled “database” or “executive” -- but that’s all
• You need to add specifications and properties.
Systems have many structures (views).
• No single structure can be the architecture.
• The set of candidate structures is not fixed or prescribed: choose whatever is useful for analysis, communication, or understanding.
© 2002 by Carnegie Mellon University Version 1.5 page 12
Example of Multiple ViewsSoftware Architecture for A-7E Corsair II Aircraft • U. S. carrier-based, light attack aircraft• Used from the 1960s through the 1980s• Small computer on board for navigation, weapons
delivery
© 2002 by Carnegie Mellon University Version 1.5 page 13
Module View (2 Levels)
Har
dw
are-
Hid
ing
Mo
du
le
Deviceinterfacemodule
Extendedcomputermodule
Beh
avio
r-H
idin
g M
od
ule
Functiondrivermodule
Sharedservicesmodule
Data bankermodule
Physicalmodels module
Applicationdata types mod.
Filterbehavior module
Softwareutilities module
Systemgeneration mod.S
oft
war
e -D
ecis
ion
-Hid
ing
Mo
du
le
© 2002 by Carnegie Mellon University Version 1.5 page 14
Data Flow View
Device interfaces
Data banker
Shared services
Function drivers Filter behaviors
Physical models
sensor inputs
computed values stored values
computed values
storedvalues
valuesto display
filteredvalues
sensorvalues
calculatedcalculatedreal-worldreal-world
valuesvalues
Pilot, external world
© 2002 by Carnegie Mellon University Version 1.5 page 15
Layers View
Function drivers
Extended computer
Application data types
Device interfaces
Databanker
Physicalmodels
Filterbehaviors
Shared services
Softwareutilities
© 2002 by Carnegie Mellon University Version 1.5 page 16
Views -1
An architecture is a very complicated construct -- too complicated to be seen all at once.
Views are a way to manage complexity.• 1974: Parnas observed that software is composed of
many structures• 1992: Perry and Wolf recognize that, similar to
buildings (with plumbing and electrical and wall diagrams), different views of a system are required.
• 1995: Kruchten defined the “4+1 views” approach to software architecture.
• 2000: Hofmeister, Nord, and Soni defined the “Siemens Four Views” approach to software.
© 2002 by Carnegie Mellon University Version 1.5 page 17
Views -2
A view is a representation
of a set of architectural
elements and therelations associatedwith them.
Not all architectural
elements -- some of them.
A view binds element
types and relation types
of interest, and shows
those.
All information
Some information
© 2002 by Carnegie Mellon University Version 1.5 page 18
Views -3
In box-and-line diagrams, a way of asking what the boxes and lines mean is:
“What element types and relation types are you showing?
In other words,“What view are you showing?”
Which view shows “the” architecture?• None of them.• All of them.
© 2002 by Carnegie Mellon University Version 1.5 page 19
Architecture As Communication VehicleArchitecture provides a common frame of reference in which competing interests may be exposed and negotiated.
• negotiating requirements with users and other stakeholders
• keeping the customer informed of progress and cost
• implementing management decisions and allocations
© 2002 by Carnegie Mellon University Version 1.5 page 20
Architecture Constrains Implementation
An architecture defines constraints on an implementation.
• Architectures are descriptive and prescriptive
- descriptive for communication
- prescriptive for design and implementation
• Global resource allocation decisions constrain implementations of individual components
• System tradeoffs regarding quality attributes are in the architectural realm.
© 2002 by Carnegie Mellon University Version 1.5 page 21
Architecture Organizes the Development Project
The architecture influences the organizational structure for development/maintenance efforts. Examples include• division into teams• units for budgeting, planning• basis of work breakdown structure• organization of documentation• organization of CM libraries• basis of integration• basis of test plans, testing• basis of maintenance• Incremental deployment
© 2002 by Carnegie Mellon University Version 1.5 page 22
Architecture Permits/Precludes Achievement of Quality Attributes
For example
If you desire Examineperformance inter-component communicationmodifiability component responsibilitiessecurity inter-component communication,
specialized components (e. g., kernels)scalability localization of resourcesability to subset inter-component usagereusability inter-component coupling
© 2002 by Carnegie Mellon University Version 1.5 page 23
Architecture is Key to Managing Change
An architecture helps reason about and manage change.
• important since 80% of effort in systems occurs after deployment
Architecture divides all changes into three classes:
• local: modifying a single component
• non-local: modifying several components
• architectural: modifying the gross system topology, communication, and coordination mechanisms
A “good” architecture is one in which the most likely changes are also the easiest to make.
© 2002 by Carnegie Mellon University Version 1.5 page 24
Architecture is Basis for Incremental Development
An architecture helps with evolutionary prototyping and incremental delivery.
• Architecture serves as a skeletal framework into which components can be plugged.
• By segregating functionality into appropriate components, experimentation is easier.
• Risky elements of the system can be identified via the architecture and mitigated with targeted prototypes.
© 2002 by Carnegie Mellon University Version 1.5 page 25
Architecture is a Reusable Model
An architecture is an abstraction: enables a one-to-many mapping (one architecture, many systems).
Systems can be built from large, externally developed components that are tied together via architecture.
Architecture is the basis for product (system) commonality.
Entire software product lines can share a single architecture.
© 2002 by Carnegie Mellon University Version 1.5 page 26
Today’s talk
What is software architecture and why is it important?
A benefit of architecture: Software product lines
Evaluating software architectures
Documenting software architectures
© 2002 by Carnegie Mellon University Version 1.5 page 27
What is a Software Product Line?
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 segment or mission and that are developed from a
common set of core assets in a prescribed way.
© 2002 by Carnegie Mellon University Version 1.5 page 28
Software Product Lines
Market strategy/ Application domain
Architecture
Components
pertain to
share an
are built from
is satisfied by
used to structureProducts
COREASSETS
Product lines • take economic advantage of commonality • bound variability
Product lines • take economic advantage of commonality • bound variability
© 2002 by Carnegie Mellon University Version 1.5 page 29
How Do Product Lines Help?
Product lines amortize the investment in these and other core assets:
• requirements and requirements analysis
•domain model
•software architecture and design
•performance engineering
•documentation
• test plans, test cases, and data
• people: their knowledge and skills
•processes, methods, and tools
•budgets, schedules, and work plans
•components
earlier life- cycle
reuse
more benefit
© 2002 by Carnegie Mellon University Version 1.5 page 30
The Key Concepts
Use of a common asset base
in production
of a related set of products
© 2002 by Carnegie Mellon University Version 1.5 page 31
Economics of Product Lines
Derived from data supplied byLucent Technologies
Bell Laboratories Innovations
With Product Line Approach
CurrentPractice
CumulativeCost
Number of Products
© 2002 by Carnegie Mellon University Version 1.5 page 32
Example: Cummins, Inc.
World’s largest manufacturer of large diesel engines
(over 200 hp)
25,000 employees
350 controls and
electronics engineers
$7B annual sales
© 2002 by Carnegie Mellon University Version 1.5 page 33
Complex Domain Of Variation
Today’s diesel engines are driven by software.
• Micro-control of ignition timing to achieve optimum mix of power, economy, emissions.
• Conditions change dynamically as function of road incline, temperature, load, etc.
• Must also respond to statutory regulations that often change.
• Reliability is critical! Multi-million dollar fleets can be put out of commission by a single bug.
• 130KSLOC -- C, assembler, microcode.• Different sensors, platforms, requirements.
© 2002 by Carnegie Mellon University Version 1.5 page 34
Changing the Way to Do Business
In 1994, with six engine projects under way and 12 more planned, Cummins
• realized that it could not continue to do business the old way
• realized hiring to fill the need was out of the question
• launched a software product line
• built a core asset base from the most successful of its projects
• turned the other projects into product development projects using the core assets
© 2002 by Carnegie Mellon University Version 1.5 page 35
Cummins’ Results
In early 1995, the first product was launched on time (relative to re-vamped schedule) with high quality. Others followed -- on time and with high quality.
Cummins achieved a product family capability with a breathtaking capacity for variation, or customization• 9 basic engine types• 4-18 cylinders• 3.9 - 164 liter displacement• 12 kinds of electronic control modules• 5 kinds of microprocessors• 10 kinds of fuel systems• diesel fuel or natural gas
© 2002 by Carnegie Mellon University Version 1.5 page 36
Quantitative Results - 1
20 product groups launched, which account for over 1000 separate engine applications
75% of all software, on average, comes from core assets
Product cycle time has plummeted. Time to first engine start went from 250 person-months to a few person-months. One prototype was built over a weekend.
Software quality is at an all-time high, which Cummins attributes to product line approach.
© 2002 by Carnegie Mellon University Version 1.5 page 37
• Customer satisfaction is high. Productivity gains enable new features to be developed (more than 200 to date).
• Projects are more successful. Before product line approach, 3 of 10 were on track, 4 were failing, and 3 were on the edge. Now, 15 of 15 are on track.
• Widespread feeling that developers are more portable, and hence more valuable.
Quantitative Results - 2
© 2002 by Carnegie Mellon University Version 1.5 page 38
Quantitative Results - 3
Achieving this flexibility without the product line approach would have required 3.6 times the current staff.
Supported Components
1992 1993 1994 1995 1996 1997 1998
Electronic control modules (ECMs)
3 3 4 5 5 11 12
Fuel Systems
2 2 3 5 5 10 11
Engines
3 3 5 5 12 16 17
Features * ECM 60 80 180 370 1100 2200 2400
© 2002 by Carnegie Mellon University Version 1.5 page 39
Today’s largest teams are smaller than yesterday’s smallest teams. Two-person teams are not unusual.
Cummins management has a history of embracing change, but carefully targeted change.
• They estimate that process improvement alone has brought a benefit/cost ratio of 2:1 to 3:1.
• They estimate that the product line approach has brought a benefit/cost ratio of 10:1.
Product line approach let them quickly enter and then dominate the industrial diesel engine market.
Quantitative Results - 4
© 2002 by Carnegie Mellon University Version 1.5 page 40
Lessons Learned
Cummins story echoes product line success themes seen on other successful efforts, namely• a compelling business case• deep domain expertise• a rich legacy base• a dedicated champion• organizational cohesion• courage to try new engineering approaches
© 2002 by Carnegie Mellon University Version 1.5 page 41
Examples of Product Line Practice - 1
CelsiusTech - large shipboard command/control systems• hardware-to-software cost ratio switched from 35:65 to 80:20• staff decreased from over 200 to about 40
Motorola - FLEXworks Project (family of one-way pagers)• 4x cycle time improvement• 80% reuse
Hewlett Packard - printer systems• 2-7x cycle time improvement• Sample Project
–shipped 5x number of products–that were 4x as complex–and had 3x the number of features–with 4x products shipped/person
© 2002 by Carnegie Mellon University Version 1.5 page 42
Examples of Product Line Practice - 2
Nokia - mobile phones• went from 4 different phones produced per year to 25-30
per year• 58 languages, multiple platforms, wide range of features
National Reconnaissance Office’s Control Channel Toolkit - ground-based satellite systems• first product using core assets requiring 1/10 the normal number of developers
Market Maker - website stock market software• each product uniquely configured for customer• three days to put up a customized system
© 2002 by Carnegie Mellon University Version 1.5 page 43
Today’s talk
What is software architecture and why is it important?
A benefit of architecture: Software product lines
Evaluating software architectures
Documenting software architectures
© 2002 by Carnegie Mellon University Version 1.5 page 44
Architecture Evaluation
A software architecture is the earliest life-cycle artifact that
embodies significant design decisions. Analyzing for system qualities early in the life cycle allows for a comparison of architectural options.
With the advent of cost-effective, repeatable architecture evaluation methods, architecture evaluation should be a standard part of every architecture-based development methodology.
© 2002 by Carnegie Mellon University Version 1.5 page 45
When and Why To Evaluate an Architecture
When building a system• Evaluation should be done when deciding on
architecture.
When acquiring a system• Architectural evaluation is useful if the system will
have a long lifetime within organization.• Evaluation provides a mechanism for understanding
how the system will evolve.• Evaluation can also provide insight into other visual
qualities.
© 2002 by Carnegie Mellon University Version 1.5 page 46
Forces Preparation for Review
Documentation/specifications must be provided, hence they must exist or be created.
Some evaluations use standard questions, and the architect can prepare ahead to ensure that the architecture scores well.
Evaluations make the criteria for evaluation explicit by prioritizing requirements or quality goals.
© 2002 by Carnegie Mellon University Version 1.5 page 47
Early Detection of Problems
The problems that can be found by an architecture evaluation include
• unreasonable requirements
• performance problems
• problems associated with potential future modifications
The earlier in the life cycle that problems are found, the easier it is to fix them.
© 2002 by Carnegie Mellon University Version 1.5 page 48
Validation of Requirements
Evaluations put stakeholders in the same room with each other, often for the first time.
• uncovers conflicts and tradeoffs
• provides a forum for negotiated resolution of problems
It often results in the generation of new requirements or the clarification of existing requirements.
© 2002 by Carnegie Mellon University Version 1.5 page 49
Improved Architectures
Development organizations anticipate types of questions raised at evaluations and
• design architectures with questions in mind
• prepare documentation of the type needed at evaluation
• give explicit consideration to qualities to be evaluated
© 2002 by Carnegie Mellon University Version 1.5 page 50
The ATAMSM
The SEI has developed the Architecture Tradeoff Analysis MethodSM (ATAMSM).
The purpose of ATAMSM is: to assess the consequences of architectural decisions
in light of quality attribute requirements and business goals.
© 2002 by Carnegie Mellon University Version 1.5 page 51
ATAMSM Steps
1. Present the ATAMSM
2. Present business drivers
3. Present architectural views
4. Identify architectural approaches
5. Generate quality attribute utility tree
6. Analyze architectural approaches
7. Brainstorm and prioritize scenarios
8. Analyze architectural approaches
9. Present results
Phase 1: Evaluation team,key decision-makers
Phase 2:Evaluation team, stakeholders
© 2002 by Carnegie Mellon University Version 1.5 page 52
Conceptual Flow of ATAMSM
ArchitecturalDecisions
ScenariosQuality
Attributes
ArchitecturalApproaches
BusinessDrivers
Software Architecture
impacts
Risk Themes
distilledinto
Analysis
Risks
Sensitivity Points
Tradeoffs
Non-Risks
© 2002 by Carnegie Mellon University Version 1.5 page 53
Today’s talk
What is software architecture and why is it important?
A benefit of architecture: Software product lines
Evaluating software architectures
Documenting software architectures
© 2002 by Carnegie Mellon University Version 1.5 page 54
Documenting an architecture
Architecture serves as the blueprint for the system, and the project that develops it.• It defines the work assignments.• It is the primary carrier of quality attributes.• It is the best artifact for early analysis.• It is the key to post-deployment maintenance and
mining.
Documenting the architecture is the crowning step to creating it.
Documentation speaks for the architect, today and 20 years from today.
© 2002 by Carnegie Mellon University Version 1.5 page 55
“Views and Beyond” approach to documentation
Views give us our first principle of architecture documentation:
Document the relevant views,
and then add information
that applies to more than one view.
© 2002 by Carnegie Mellon University Version 1.5 page 56
Which views are relevant? -1
Kruchten’s 4+1 views• Logical view: supports behavioral requirements. Key
abstractions, which are objects or object classes• Process view: addresses concurrency and distribution.
Maps threads to objects. • Development view: organization of software modules,
libraries, subsystems, units of development.• Physical view: maps other elements onto processing
and communication nodes.• “Plus one” view: Maps the other views onto important
use cases to show how they work.
© 2002 by Carnegie Mellon University Version 1.5 page 57
Which views are relevant? -2
Siemens Four-Views (Hofmeister, Nord, Soni, Applied Software Architecture, 2000):• Conceptual view• Module interconnection view• Execution view• Code view
Herzum & Sims (Business Component Factory, 1999):• Technical architecture• Application architecture• Project management architecture• Functional architecture
© 2002 by Carnegie Mellon University Version 1.5 page 58
Which views are relevant? -3
Software Cost Reduction method (Parnas, et al., 1980s)• Module view: shows modules as units of
encapsulation; used to isolate changes and achieve modifiability
• Process view: shows processes and how they synchronize and communicate at run-time; used to achieve performance
• Uses view: shows programs and how they depend on each other; used to achieve incremental development and the ability to quickly field subsets
© 2002 by Carnegie Mellon University Version 1.5 page 59
Which views are relevant? -4
Which views are relevant? It depends on:
• who the stakeholders are
• how they will use the documentation.
Three primary uses for architecture documentation:
• Education -- introducing people to the project
• Communication -- among stakeholders
• Analysis -- assuring quality attributes
© 2002 by Carnegie Mellon University Version 1.5 page 60
What views are available? -1
Plenty! Too many!
Already, we’ve seen 15 different views, and many more are available, based on examining the literature.
An architect needs a way to choosethe useful ones.
One thing that would help is to organize the views into broad categories.
© 2002 by Carnegie Mellon University Version 1.5 page 61
What views are available? -2
An architect must consider the system in three ways:
• How is it structured as a set of code units?
• How is it structured as a set of elements that have run-time behavior and interactions?
• How does it relate to non-software structures in its environment?
© 2002 by Carnegie Mellon University Version 1.5 page 62
What views are available? -3
This suggests looking for three kinds of views that help:
• How is it structured as a set of code units?Module views (module viewtype)
• How is it structured as a set of elements that have run-time behavior and interactions?Component-and-connector views (C&C viewtype)
• How does it relate to non-software structures in its environment?Allocation views (allocation viewtype)
© 2002 by Carnegie Mellon University Version 1.5 page 63
How many views do we need in our documentation package?Each view comes with a cost.
Each view comes with a benefit.
Planning a view setrequires understandingthe needs of the
stakeholders, andthe resources available.
© 2002 by Carnegie Mellon University Version 1.5 page 64
How to proceed?
1. Build a table.
• ROWS: Enumerate the stakeholders
• COLUMNS: Enumerate the set of styles that could apply to the architecture being documented. This is our potential set of views.
• Check box (x,y) if stakeholder x would like view y.
2. Combine views appropriately to reduce number.
3. Prioritize views based on need. (Some stakeholders may have extra weight.)
© 2002 by Carnegie Mellon University Version 1.5 page 65
Documenting a view -1
1. A primary presentation
• Usually graphical (we call this a cartoon)• May be textual -- e.g., a table• If graphical, includes a key explaining the notation (or
pointing to explanation)• Shows elements and relationships among them• Shows information you wish to convey about the view
(view packet) first
Many times, the primary presentation is all you get. It’s not enough!
© 2002 by Carnegie Mellon University Version 1.5 page 66
Documenting a view -2
2. An element catalog• Explains the elements depicted in the primary
presentation• Lists elements and their properties (as defined by the
relevant style guide)• Explains relations, and any exceptions or additions to
the relations shown in the primary presentatio• Interfaces of elements
3. A context diagram• Shows how system (or portion shown in this view
packet) relates to its environment.
© 2002 by Carnegie Mellon University Version 1.5 page 67
Documenting a view -3
4. A variability guide• Shows the architectural mechanisms available to
change the element
5. Architecture background• Rationale for design decisions that apply to the entire
view (or to that portion of the view being shown), including rejected alternatives and factors that constrained the design
• Analysis results validating the design decisions• Assumptions about the environment and about the
need that the system is fulfilling
© 2002 by Carnegie Mellon University Version 1.5 page 68
Documenting a view -4
6. Other information
• System- and project-specific.
• CM information, ownership information
• Mapping to requirements
• Not architectural, strictly speaking. But useful to capture alongside the architecture anyway.
7. Related view packets
• Pointers to sibling, child, and parent view packets
© 2002 by Carnegie Mellon University Version 1.5 page 69
Documentation beyond views - 1
1. Documentation roadmap
• How the documentation is organized to serve a stakeholder
• List of views, with the elements/relations of each, and a statement of what the view is for
• Scenarios for using the documentation, showing which parts should be consulted
2. View template
• Explanation of how each view is documented
• The standard organization for each view
© 2002 by Carnegie Mellon University Version 1.5 page 70
Documentation beyond views -2
3. System overview
• An informal, prose description of the system and its purpose and functionality
• Goal is to provide context for new member
• Perfectly OK to point to overview elsewhere if one exists in overall system documentation
4. Mapping between views
• Establishes useful/insightful correspondence between various views
• Tabular
© 2002 by Carnegie Mellon University Version 1.5 page 71
Documentation beyond views -3
5. Directory
• An index showing where every element, relation, and property is defined and used.
6. Architecture glossary and acronym list
• May be subset of overall system glossary and acronym list. OK to point to larger document if so.
7. Background, design constraints, and rationale
• As in views, but applied to cross-view design decisions.
© 2002 by Carnegie Mellon University Version 1.5 page 72
Source of material - 1
General overview
1998 (second edition 2003)
Software product lines
2001
© 2002 by Carnegie Mellon University Version 1.5 page 73
Source of material - 2
Architecture evaluation
2001
Architecture documentation
2002
© 2002 by Carnegie Mellon University Version 1.5 page 74
For more information
SEI’s software architecture work:
• www.sei.cmu.edu/architecture
SEI’s software product line work:
• www.sei.cmu.edu/plp/plp_init
Contact information:Paul ClementsSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA [email protected]