“Role” of Software Architecture
•
3 “fundamental” understandings about
architecture: (not sure how “fundamental”-Tsui)
1. Every software application has an architecture
2. A software application may have more than one
architect/architecture (could the design decisions
conflict?)
3. Software architecture is not contained in a phase (not
performed in a single phase) within a software
engineering development cycle. ---(3 cont.) however -------Architecture is a characterization of the essence and the essentials
of the software system ----- (principal design decisions made about
the system) ------ (key abstractions made about the system)
Software Architecture
1. When are these principal design decisions
made?
– Traditionally --- after requirements & during design
phase
– (text-book authors) Through-out the development
activities and not limited to only the “design” phase
(yes, but ----?)
2. Who makes these decisions?
– Mainly Architects/Designers, but may include multiple
stakeholders ( including customers? )
3. How are these decisions made?
– Using various techniques & past experiences - - - the
major part of this course
Software Development Activities & Architecture
Requirements
Design
Implement
Build /Test
Rel
Maintenance
Architecture is created, established, and maintained through all the activities
Architecture during Requirements ?
• A strong traditionl view --- “understand the
requirements thoroughly before embarking on the
solution.”
• However (newer view), during requirements analysis,
the solution (especially previous solutions to
“similar” problems) is often considered (e.g. mentally
modeled or even physically prototyped).
-The architecture of the solution should “start” at
the requirements analysis stage .
balance
these
• In “architecting,” one often looks to past experiences
(deeper insights)---- but beware that not all past solutions
are applicable.
• Also beware that brand “new” architecture often causes
several “false” starts.
Need to know what is reusable - - - (e.g.) use a ladder to go to the roof
of a house, use a fire-truck ladder to get to the top of a 6 story building,
but one needs something totally different to get to the top of a skyscraper!!
Requirements: “Merge” 2 Application Products with “similar”
Architecture Styles -- (need to consider- design, code & test?)
“Vertical” App Component Design
F1
F2
....
Fn
Fa
Fb
....
Fp
User Interface Design
“Horizontal”
Common
Function
Design
Help/Error Messages
User Interface Design
“Reprocess” Mechanism
Help/Error Messages
Import/Export
Import/Export
data sharing mechanism
Security Mechanism
Company A
Company B
How would cohesion and coupling affect the “merger” ?
2 Main Activities in Requirements Phase
• Requirements Elicitation is an interactive activity with
the users/customers.
– Functional requirements are usually well articulated by the
user/customers because they understand that well. These
main functionalities are often aggregated into “main
components” of the software architecture. (similar to the
“vertical” components)
– Non-functional requirements (integrity, security, performance,
usability, etc.) usually need some prodding from the solution
providers. It is in this area, that the question of architecture
really starts. (similar to the “horizontal” components)
• Requirements Analysis of the gathered requirements
includes the earnest discussion of the underlying
solution architecture and design. (still --- bone of
contention among software engineers)
– Prototyping for requirements and for architecture are also
performed
– Project cost & schedule estimations are initiated based on the
requirements analysis and the assumed architecture.
Architecture during Design
• Software architecture and design, as an activity,
appears “sequentially” after the requirements are
complete and understood and before design and
implementation starts in a software engineering
process diagram.
• Truth is that software architecture:
a) sometimes starts during requirements analysis
b) is given main emphasis during design phase
c) continues into implementation
d) considered during test case analysis and testing
e) considered during support maintenance and next release
Note: Compared to functional requirements, “non-functional” requirements
require considerable design and architectural work from scratch
4 “Most” Common Design Decisions
• Traditional Design Phase includes:
1. Identification of main components (almost directly
from “abstracting” the requirements)
2. Describing these main components
3. Constructing a “system structure/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 possibly
modifying the components &
structure/configuration
Design Techniques
• There are many different techniques employed during
design ---- to be expounded through out this course.
• Mention just 2 here:
– OO Design
• key concept is “class/object” ---- (1) an abstraction of a main
component (with its functionalities and states)and (2) the interaction
of these classes.
• It has advantages: mechanisms for re-use (inheritance,
polymorphism, etc.)
• It has disadvantages (does not model some important concepts): no
concurrency, no security and trust guidance, limited notion of
connector , interface , cache, etc. (addresses only one abstraction –
object )
– Domain Specific Architectural Design
• key concept -- capturing the best solution and approaches used
successfully in the past within the same application domain
• It has advantages: re-use, especially useful for product family where
the next release or other components are all within the same
application domain.
• It has disadvantages: there is very little guidance with new industry
and/or new application domains where there is no past experience
Architecture during Implementation
• During implementation, parts of architecture and
design may be altered, and new “low level design”
changes may affect the architecture
The key point is to ensure that the implementation and any
modifications to the design remains consistent (& “faithful”)
with the envisioned Architecture:
• (r1) (completeness) All the main structural elements (components and
relations) in the architecture exist in the source code and
• (r2) (traceability) All the source code corresponds to the various
components of the architecture
r1
Architecture
r2
Implementation
Implementation Techniques & Architecture
• Different implementation techniques provide different
degrees of “faithful” transformation from design to code.
– Code generation directly from a design/architecture tool (“best” or
most “faithful” but tools limited to special domains --- or state of
the art in 2013/2014 is JML based on formal language)
– Implementation framework (provides some major
design/architectural elements in code and the rest requires handcoding)
– Middleware tools that support implementation (mostly limited to
communications and networking code – e.g cross language remote
object call)
– Reuse of existing code (need to ensure they fit the
design/architecture)
– Manual hand coding from scratch (“worst” - requires the most work
and has high risk of being “non-faithful”)
Architecture during “Testing”
• Testing here includes more than just executing code
and testing ----- (test case design is very important).
• We are not only interested in ensuring that the
functional requirements are all satisfied, but also the
non-functional requirements (many of which are
“designed” into the product ) are also satisfied:
–
–
–
–
–
–
Performance properties
Security properties
Reliability properties
Maintainability properties
Complexity properties
etc.
Testing Techniques and Architecture
• There are 2 major testing techniques:
– Inspection & review (mostly of non-executables)
– Running test cases (executable code)
• Using these techniques we want to ensure:
– architectural consistency and correctness &
architectural satisfaction of requirements --especially non-functional requirements architecture
(its connectors & platforms) is supported by the
actual code
– Architectural model derived from the source code
matches the original architecture. (this is almost
never done – unless there is maintenance problem)
Architecture during Maintenance and Evolution
• 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-maintainable.
• During “evolution” of the software in a product family,
the architecture and design should be, but often not,
consulted first to maintain architectural integrity and
consistency. (See the earlier product merger chart)
– *** The design document should be modified first and then the
code. Product evolution should follow an orderly process with
consistent architecture.***
Conceptual View of Architectural-Centric Process
tn
Testing/Build
Implementation
Architectural
Core
time
Design
t0
Requirements
Relation between Processes and Architecture
• Domain Specific Software Architecture-based
development: If the process is to re-use many of
the existing artifacts and the product is an extension
of an existing product family, then the Core
Architecture will start with a “large” core as the base.
• Agile Development : Requirements are sometimes
given verbally/separately and design is not always
recorded; in this case, the Core Architecture is very
small for each for each of the iteration. “Somehow”
the small pieces of Core Architecture needs to be
merged into one base Core Architecture.