1
Q
- Conceptual Integrity
- A basis for reuse of knowledge, experience, design, and code
- Effective project communication
- Management of “families” of systems
A
Results of Attention to Architecture
2
Q
Architecture must be considered the “heart” of developing a software system, more so than:
A
- Processes and methodologies
- Programming
- Requirements Analysis
3
Q
?-satisfaction of customer needs
- specialization of labor
- multiple perspectives of the final product
- intermediate points where plans and progress are reviewed
A
Similarities to regular architecture
4
Q
?-Software is much newer, so we know much less about it
- Software does not a have a (physical) “medium” for building and thus is much less “visible” (tangible); this makes it more difficult to measure and analyze than a physical structure
- Software is more malleable than a physical building; thus changes are more frequently requested because they are (technically) possible, though the later a change occurs the bigger the magnitude of disruption
A
Differences from regular architecture
5
Q
Pipe and FIlter Architecture
A
- Design/Architecture: components (filters) and relations (pipes)
- Style: constraint on architecture (flow is “sequential”)
- Used in shell programming/command line
- Pipe is a channel that supports the flow of data
6
Q
Three “Fundamental” Understandings About Architecture
A
- Every software application has an architecture
- Software applications can have more than one architect/architecture (these could conflict!)
- Software architecture is NOT contained in a phase within the development cycle
7
Q
Advantages of Product Family?
A
- Reuse and cost sharing is the big advantage of common components in Product Family.
- think: reused interfaces, assets, architectural style, etc.
- these reused components have already been tested and validated (probably)
8
Q
We can have multiple sets of architecture at different times. What are some reasons for different versions?
A
- Based on modifications as we change our minds
- Based on modifications as we make corrections
- Based on modifications as we know more
- Based on expansion as we evolve an grow, etc
9
Q
-Non-functional requirements are usually done by the solution providers
A
True
10
Q
-The architecture should START at the requirements stage
A
True
11
Q
Connectors may be classified semi-hierarchically by these four attributes: C-T-D-V
A
- Category : primary service the connector fulfills
- Type : how the service category is realized
- Dimensionality : further details of types
- Values : values the dimensionality can take
12
Q
Four categories of connector services? C-C-C-F
A
Communication Services:
• Supports transmission of information among components
Coordination Services:
• Supports transfers of control among components
Conversion Services:
• Transforms the “interactions of control and/or data” required by one
component to that provided by another
Facilitation Services:
• Mediate and streamline (e.g. performance) the component interactions
13
Q
8 connector types? PE SAD LAD
A
- Procedure Call
- Event
- Data Access
- Linkage
- Stream
- Arbitrator
- Adaptor
- Distributor
14
Q
Services provided by procedure call connectors? (3)
A
Coordination Service: flow of control among components (via invocation techniques)
• Communications Service: Transfer of data among interacting components (via
parameters and return values)
• Facilitation Service: Facilitate remote procedure call as a “composite” connector
15
Q
Services provided by Event Connectors? 2
A
• Coordination services: Regulate the flow of control among
components (an event precipitates the flow of control to a component)
• Communication services: transfers data about the event to those
components who are interested or application data
16
Q
Services provided by Data Access Connectors? 2
A
• Communication services: connections to data stores, including
preparation for connection and clean up after access.
• Conversion services: performs any conversion of data formats
and facilitates any access and query mechanisms.
17
Q
Service provided by linkage connector?
A
• Facilitation services: provides the “duct or channel ” to facilitate
communications and coordination of information and enforces the
interaction semantics
18
Q
Service provided by stream connector?
A
• Communication services: provide the transfer of large amounts of
information (data) ; this service combined with data connector can
form a composite connector of database and file storage access.
19
Q
Services provided by arbitrator connector? 2
A
• Facilitation services: resolves any conflict among components and
thus assist and mediate the services among components
• Coordination services: directing and redirecting the control flow
among components
20
Q
Service provided by adaptor connector?
A
• Conversion services: provide facilities to support interactions among
components which were not initially designed to interoperate (e.g.
different operating environment, different languages, etc.).
21
Q
Service provided by distributor connector?
A
• Facilitation services: identifies interaction paths and routing of
communications and coordination information among the
components.
22
Q
“specialized” software components that facilitate
the interactions among “application” software components
A
Software Connectors
23
Q
Composing a software system from “pre-fabricated, heterogeneous”
components may engage in:
A
Complex interactions to Produce complex functionalities
24
Q
Two conceptual building blocks of component interactions?
A
- Flow of Control
2. Flow of Information
25
There must a _____, ______, or _____that is used to link the interacting
components; and through this channel flows the control and data
information.
channel or duct or medium
26
- distinctive role and character in project
- very broad training
- leverages extensive experience
- a keen sense of aesthetics
- deep understanding of the domain
- properties of structures, materials, and environments
- needs of customers
Good Architect
27
- intellectual control
- conceptual integrity
- effective basis for knowledge reuse
- realizing experience, designs, and code
- effective project communication
- management of a set of variant systems
-Giving preeminence to architecture offers potential for:
28
How to describe arch effectively?
- Use Models
| - Describe RULES
29
- Architecture is critical for _________
- The variable components provide, for each product within the_________, the differentiator features by cost, by time, etc.
- Reuse and cost sharing is the big advantage of common components in _________.
- think: reused interfaces, assets, architectural style, etc.
- these reused components have already been tested and validated (probably)
Product Family.
30
When?
- Traditionally: after requirements and during design phase
- In MODERN Practice: Throughout the development activities and not limited only to the “design” phase
- The truth is that software architecture:
a) sometimes starts during the requirements analysis
b) is given main emphasis during design phase
c) continues into implementation
d) is considered during test case analysis and testing
e) is considered during support maintenance and next release
31
Who?
-Mainly architects and designers, but may include multiple stakeholders (customer influence?)
32
How?
-Using various techniques and past experiences
33
Arch during requirements, new vs old view?
- Traditional View: Understand requirements thoroughly before embarking on a solution
- Newer View: During requirements analysis, the solution/previous solutions to similar problems are often considered (mentally modeled, prototyped) …does this limit innovation?
- The architecture should START at the requirements stage
- Beware not all past solutions are applicable
- Need to know what IS and ISNT reusable (does it fit application?)
- Trying out a brand new architecture often causes several “false” starts
34
-Key concept is class/object
1) an abstraction of a main component (with its functionalities and states)
2) the interaction of these classes
-Advantages: mechanisms for reuse (inheritance, polymorphism, etc.)
-Disadvantages: does not model some important concepts, no concurrency, no security and
trust guidance, limited notion of connector, interface, cache, etc.
OO Design
35
-Key concept is capturing the best solution and approaches used successfully in the past within
the same application domain.
-Advantages: re-use, especially useful for product family where the next release or other
components are all within the same application domain
-Disadvantages: there is very little guidance with new industry and/or new application domains
where there is no past experience.
-contains a substantial amount of information based on past experiences within the specific application domain.
-it is a combination of:
1. a reference architecture for a specific domain
2. a library of software components containing reusable chunks of domain expertise
3. a method of choosing and configuring components to work within an instance of the
reference architecture
Domain Specific Architectural Design
36
Identifying, Describing, Constructing, and Considering
What does this describe?
Four most common design decisions
1. Identification of main components (generally from abstracting requirements)
2. Describing these main components
3. Constructing a system configuration
- Identifying the relationship among components
- Identifying the dynamic “flow” of control/data
4. Considering the constraints that need to be placed on the system structure/configuration and possible modifying the system structure/configuration
37
impl techique: _________ directly from a design/architecture tool (may be easiest/best/most faithful way of ensuring architectural accuracy, but limited to special domains)
-Parser Generators
-Code generation
38
software that acts as a bridge between the architectural style and a set of implementation technologies. Provides some major architectural/design elements in code and rest requires hand coding.
Implementation framework
39
tools that support implementation (mostly limited to communications and networking code such as cross-language remote object call)
Middleware
40
the “worst” option, requires most work and has the highest risk of not being faithful
Manual hand coding from scratch
41
need to ensure it fits the design/architecture
Reuse of existing code
42
Two major testing techniques?
- inspection and review (non-executable)
| - running test cases (executables)
43
-Using these testing techniques, we must ensure: (2 things)
-architectural consistency and correctness, architectural satisfaction of requirements, especially
that non-functional requirements architecture (connectors and platforms) is supported by the
actual code.
-architectural model derived from the source code matches the original architecture. (This is
almost never done in reality unless there is a maintenance problem.)
44
During maintenance, the motivation is to fix the problem
as quickly as possible in the easiest fashion
-Very little or no attention is paid to the original design or architectural consistency, eventually
eroding the overall system to non-maintainability.
45
During evolution, of the software in a product family, the architecture and design should be, but are often not,
consulted first to maintain architectural integrity and consistency
- The design document should be modified first and then the code.
- Product evolution should follow an orderly process with consistent architecture
46
Perry & Wolf Definition of Architecture
- Software Architecture = {elements, form, rationale}
- Elements: the key components that may be a processing, data, or connecting element
- Form: describes how the elements are composed or organized
- Rationale: describes the designers’ intent, assumptions, etc.
47
- Two main types
- Architectural Drift and Architectural Erosion
- Product Line and Product Family is a fertile ground for __________
architectural degredation
48
- Processing and States
- Often derived from functional requirements
- It can be seen from the outside only through its interface
- explicitly defined execution context
- other required components
- resources such as data files and directories needed
- required system resources, programming language, etc
- required hardware configuration
- often related to some application domain or considered application specific
- some are common utilities that may be utilized across different application domains
components
49
- Come in many different forms
- Some simple examples:
- Procedure call (sync or async and distributed)
- Shared data access (database or a “global” variable)
- Adaptor (connect pre-existing components)
Connectors
50
Pattern vs Style
| -3 key differences
- Scope: style applies to development context while pattern addresses a specific, concrete problem
- Abstraction: style helps in constraining the decisions but in an abstract way while patterns are parameterized, concrete design decisions
- Relationship: a pattern may be parameterized and used in multiple styles and a style may use multiple patterns
51
Four stages of design? FPDP
- Feasibility: identifying potential design concepts
- Preliminary design: selecting and developing the “best” design concept
- Detail design: Further defining and refining the design concept (providing technical description of the concept)
- Planning: evaluating and altering (or tuning) the design concept to fit the requirements of software development, production, consumption, and retirement
- Just like everything else in software architecture, this is not sequential, but most likely iterative
52
identifying potential design concepts
Feasibility:
53
selecting and developing the “best” design concept
Preliminary design
54
evaluating and altering (or tuning) the design concept to fit the requirements of software development, production, consumption, and retirement
Planning:
55
Further defining and refining the design concept (providing technical description of the concept)
-Detail design
56
- Start-up problem: identifying potential concepts could be a problem, and even the key stumbling block
- People problem: disagreements are more likely as project complexity necessitates multiple architects
- Complexity problem: for a system that is composed of many heterogeneous components or parts, the complexity of finding an overall system becomes very large and sometimes prohibitive
Design Process Concerns
57
1. looking at the key requirements
2. mapping functional requirements to major components
3. relating the components to produce the overall system
4. analyze the relationships in terms of non-functional required properties (performance, security, reliability, etc)
standard design model
58
Cyclical, Parallel, Adaptive, Incremental
Four Modes of Design
59
- often matching some problem component to some abstract model/solution
- there are different levels of abstraction to consider.
- Ignoring the details irrelevant to a given perspective
Abstraction
60
- subdividing or decomposing problem into “independent” parts
- ie functional components and sub-components
- ie connectors that “interconnect” components
Separation of Concern
61
-breaking things down and grouping things up
Decomposition/Composition
62
3 Fundamental Architectural Patterns
- State-Logic-Display (3-tier architecture)
- Model-View-Controller (web application)
- Sense-Compute-Control (sensor-control-actuator / real time)
63
Architectural Pattern:
- resembles the 3-tier but focuses more on management of user-interaction
- model which manages the storage of data
- view which accepts and displays information to the user
- controller which aids in the control and modification of the way information is managed between the view and the model
- some times, esp. in web apps, business logic is placed in the controller
- e.g. web pages
Model-View-Controller MVC
64
Architectural Pattern:
- Familiar architecture in which:
- users access business functionalities through a user “display”
- the business functionalities are provided through the “logic” part
- the data store keeps all the persistent data or “states,” usually in a database
- e.g. business apps, multiplayer games, web-based apps
- the software components may be distributed across hardware
- in some ways this is the precursor to MVC
State-Logic Display
65
Architectural Pattern:
-composed of:
-sensors which send information from various sources
-compute component which receives the information from sensors and performs all the
necessary numerical and logical computations and sends the result as signals to the control
-control which receives the results of the computation from the compute component and
decides how to control the various devices
-e.g. embedded systems
Sense-Compute-Control
66
- Simple
- Traditional programming language influenced style
- Layered
- Dataflow
- Shared Memory (Shared State)
- Interpreter
- Implicit Invocation
- Peer-Peer
- More Complex
- C2 (component and connectors)
- Distributed Object
Architectural Styles
67
Architectural Style:
-based on a “main component” that calls upon functional “sub-components”
-traditional programing paradigm:
-software decomposed into 1) main program and 2) subroutines
-main program calls the subroutine which may in turn call other subroutines
-this gave us the traditional hierarchical style of main and (decomposed) subcomponents
-OO programming paradigm
-software decomposed into objects, one of which may be assumed to play the “main” program
role
-the methods in the objects are invoked much like a procedure call
-the objects are meant to represent the entities in the requirements/application world
Traditional Language-Influenced Style
68
Architectural Style:
- software is decomposed into layers where:
- each layer may request service of the layer below it, usually immediately below
- each layer provides the service for the layer immediately above it
- e.g. OS, virtual machines, client-server (atm)
Layered
69
Architectural Style:
- separate, independent components or programs are executed in some sequential order as data is passed through them to be processed
- batch sequential processing
- e.g. old banking systems
- pipe and filter
- e.g. Unix shell
Dataflow
70
Architectural Style:
- independent components or programs interact through shared “global” data, often to solve complex problems
- backboard: applied in AI, determines order of execution of components
- rule based/expert system: the knowledge base contains facts and rules
- used in many commercial systems that have a “centralized” database
Shared State
71
Architectural Style:
-parse, generate code, execute each command
-dynamic on-the-fly execution of commands maintains the state of the execution
-Basic interpreter: similar to rule-based style, inference engine uses knowledge repository for
parsing the input . e.g. excel formulas, basic interpreter, java interpreter
-Mobile code: transmitting code to remote host for execution
-code on demand
-remote evaluation
-mobile agent (initiator has code and information but lacks resources)
Interpreter
72
Architectural Style:
- Components are invoked indirectly and implicitly as response to some event or notification, (similar to sense-compute-control pattern)
- publish-subscribe: there is a producer and consumer of information.
- popular with internet “special news” such as “paid” financial information by industry sector for investors who subscribe to it
- e.g. online job posting services
- think, only push
- event-based: a general case of publish-subscribe
- independent components communicate solely via sending “events” via an event-bus connector with no designated publisher or subscriber
- components may react to the receipt of an event or just ignore it
- events may be processed via push or pull
Implicit Invocation
73
Architectural Style:
- a network of loosely-coupled autonomous components, each may act as a server and a client
- decentralizes both information and control, unlike client-server
- issue: resource discovery, bandwidth limitation
- this ideal situation is usually modified with some amount of centralized control or a directory
- originally used for sharing files
- instant message or chat is closest to p2p style
- other examples: b2b commerce, sensor network
Peer-Peer
74
Architectural Style:
- This style allows various components to be developed independently, but still communicate, interact, and produce the desired results with the help of “connectors” and has the following set of rules:
- Topological connection rules
- each component and each connector has a defined top and bottom
- a component may be attached to only one connector (up/down)
- arbitrary number of components and connectors may be attached to a connector
- the top of a component may be attached to the bottom of a connector.
- the bottom of a component may be attached to the top of a connector.
- same two rules apply for attaching a set of connectors
- Message based communication rules
- all communications between components are via “messages”
- a message is classified as
a) a request for performing a service
b) a notification of information (e.g. returning information)
- Message flow and Substrate Independence rules
- all request must flow “upward” in topology
- all notifications must flow “downward”
- Interfaces rules
- each component’s top domain specifies
a) the set of requests that it may send upward
b) the set of notifications to which is may react
- each component’s bottom domain specifies
a) the notifications it can emit downward
b) the set of requests to which it responds
C2 (Components and Connectors)
75
Architectural Style:
- an evolution from the C2 style, where components are objects and the connector is much more functionally powerful
- the objects may run on different hosts
- the objects may be programmed in different languages
- the objects provide services through well-defined interfaces
- the connector acts as the registry/repository of services and facilitates the connections among the objects
Distributed Object
76
as problems or infeasible approaches are identified in stages 2-4, the process reverts to an earlier stage
cyclical mode:
77
after stage 1, independent alternatives are explored in parallel; at suitable times selection is made between the identified viable alternatives
-parallel mode:
78
the next design activity is decided at the end of each given stage, based upon insights gained during that stage
adaptive mode:
79
design at each stage of development is treated incrementally
-incremental mode:
80
4 widely used distribution connectors
* Event-based
* Grid-based
* Client server based
* Peer-to-peer based
SWE 6653
flashcards
Decks in class (2)
# Cards
