“Role” of Software Architecture 3 “fundamental” understandings about architecture: (not sure how “fundamental”-Tsui) Every software application has an architecture A software application may have more than one architect/architecture (could the design decisions conflict?) 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 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 ----?) Who makes these decisions? Mainly Architects/Designers, but may include multiple stakeholders ( including customers? ) How are these decisions made? Using various techniques & past experiences - - - the major part of this course

Software Development Activities & Architecture Requirements Design Implement A r c h I t e c t u r e 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 . 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. balance these 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!!

“Reprocess” Mechanism data sharing mechanism 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 User Interface Design “Horizontal” Common Function Design Help/Error Messages Help/Error Messages “Reprocess” Mechanism Import/Export Import/Export Security Mechanism data sharing 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: Identification of main components (almost directly from “abstracting” the requirements) Describing these main components Constructing a “system structure/configuration” Identifying the relationship among components Identifying the dynamic “flow” of control/data 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 Implementation Architecture r1 r2

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 hand-coding) 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 Requirements t0

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.