1. Asst.Prof. Dr. Surasak Mungsing

3. The role of software Our civilization runs on software Innovation to capture new value Improving productivity of resources deployed The privilege and responsibility of the software professional

4. Number of software professional worldwide (Source: Grady Booch, IBM Fellow)

5. SLOC/developer/year

6. New or modified SLOC/year and cumulative (Source: Grady Booch, IBM Fellow)

7. Dimensions of software complexity Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance Lower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performance Higher management complexity - Large scale - Contractual - Many stake holders - “Projects” Lower management complexity - Small scale - Informal - Single stakeholder - “Products” Defense MIS System Defense Weapon System Telecom Switch CASE Tool National Air Traffic Control System Enterprise IS (Family of IS Applications) Commercial Compiler Business Spreadsheet IS Application Distributed Objects (Order Entry) Small Scientific Simulation Large-Scale Organization/Entity Simulation An average software project - 5-10 people - 3-9 month duration - 3-5 external interfaces - Some unknowns & risks Embedded Automotive Software IS Application GUI/RDB (Order Entry) (Source: Grady Booch, IBM Fellow)

8. Creating the illusion of simplicity (Source: Grady Booch, IBM Fellow)

9. Architecting a dog house Can be built by one person Requires Minimal modeling Simple process Simple tools Kruchten

10. Architecting a house Built most efficiently and timely by a team Requires Modeling Well-defined process Power tools Kruchten

11. Architecting a high rise

12. Differences Scale Process Cost Schedule Skills and development teams Materials and technologies Stakeholders Risks

13. Architecture is Early Architecture represents the set of earliest design decisions Hardest to change Most critical to get right Architecture is the first design artifact where a system’s quality attributes are addressed

14. Architecture Drives Architecture serves as the blueprint for the system but also the project: Team structure Documentation organization Work breakdown structure Scheduling, planning, budgeting Unit testing, integration Architecture establishes the communication and coordination mechanisms among components

15. Software Architecture Software architecture is what software architects do Another Go Software architecture encompasses the set of significant decisions about the organization of a software system Selection of the structural elements and their interfaces by which a system is composed Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into larger subsystems Architectural style that guides this organization Beck

16. Formal Definition IEEE 1471-2000 Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution IEEE 1471-2000

17. Software Architecture Definition Definition A software system’s architecture is the set of principal design decisions about the system. Software architecture is the blueprint for a software system’s construction and evolution. Design decisions encompass every aspect of the system under development. This includes design decisions related to Structure Behavior Interaction Non-functional properties

18. Other Definitions of Software Architecture Perry and Wolf Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

19. Prescriptive vs. Descriptive Architecture A system’s prescriptive architecture captures the design decisions made prior to the system’s construction. It is the as-designed or as-intended architecture. A system’s descriptive architecture describes how the system has been built. It is the as-implemented or as-realized architecture. “… about the structure of the system”

20. Why prescriptive architecture? Act as the set of rules by which all stakeholders have to play “rules of the road” for various projects within organization to align well with business goals Act as the technology product blueprint for intranet application: list of products to buy Reduces deployment risk for organization tried and tested models “…architecture is about principles and guidelines”

21. Architectural Evolution When a system evolves, ideally its prescriptive architecture is modified first. Unfortunately often the system and thus its descriptive architecture is often directly modified. This failure of update happens because of Developer sloppiness Perception of short deadlines which prevent thinking through and documenting Lack of documented prescriptive architecture Need or desire for code optimizations Inadequate techniques or tool su pport

22. Architectural Drift and Architectural Erosion Definition. Architectural drift involves architectural design decisions that are applied directly to a system’s descriptive architecture, but are not properly reflected in the system’s prescriptive architecture. Leads to inadaptability; results in lack of coherence Definition. Architectural erosion involves architectural design decisions that are applied directly to a system’s descriptive architecture, and that violate design decisions captured by the system’s prescriptive architecture. E.g., “load bearing walls” Leads to disastrous results

23. Architectural Recovery If drift or erosion are allowed to occur, the development organization is likely to be forced to recover the system’s architecture sooner or later. Definition. Architectural recovery is the process of determining a software system’s architecture from its implementation-level artifacts. Implementation-level artifacts can be Source code Executable files Java.class files

24. Deployment A software system cannot fulfill its purpose until it is deployed, that is, until its executable modules are physically placed on the hardware devices on which they are supposed to run. The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements. Possible assessment dimensions Sufficient memory Power consumption Available and required bandwidth

25. A System’s Deployment Architecture Model

26. Software Architecture’s Elements A software system’s architecture typically is not (and should not be) a uniform monolith. A software system’s architecture should be a composition and interplay of different elements Processing Data, also referred as information or state Interaction

27. Component Elements that encapsulate processing and data in a system’s architecture are referred to as software components. Definition. A software component is an architectural building block that encapsulates a subset of the system’s functionality and/or data, and restricts access to them via an explicitly defined interface.

28. Connector In complex systems interaction might become more important and challenging than the functionality of the individual components. Definition. A software connector is an architectural building block tasked with regulating interactions among components. In traditional, desktop software systems, connectors would have usually manifested themselves as simple procedure calls or shared data accesses.

29. Connector Examples Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors (e.g.. stream music from devices) Distribution connectors (distribute s/w to clients) Wrapper connectors (data, object wrapper) Components provide application-specific services. Connectors are application-independent.

30. Configuration Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective. Definition. Architectural configurations, or topologies, capture architectural structure via graphs whose nodes represent components and connectors, and whose edges represent their interconnectivity that describes architectural structure.

31. An Example Configuration

32. Architectural Style Observation Certain design choices regularly result in solutions with superior properties. Compared to other possible alternatives, solutions such as this are more elegant, effective, efficient, dependable, evolvable, scalable, and so on. Definition. An architectural style is a named collection of architectural design decisions that are applicable in a given development context constrain architectural design decisions that are specific to a particular system within that context elicit beneficial qualities in each resulting system.

33. Architectural Pattern Definition. An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears. An example pattern that is used widely in modern distributed systems is the three-tiered system pattern. Three-tiered system applications science, banking, e-commerce, reservation systems

34. Three-tiered architectural pattern  Front Tier: functionality to access the system’s services  Middle Tier: contains the application’s major functionality  Back Tier: contains the application’s data access and storage functionality.

35. Architectural Models, Views, and Visualizations Architecture Model An artifact documenting some or all of the architectural design decisions about a system (structural, process, interface, and deployment) Architecture Visualization A way of depicting some or all of the architectural design decisions about a system to a stakeholder. E.g. Structure101 Architecture View A set of elements and the relations among them; module, components and connectors, allocation view.

36. Architectural Processes Architectural Analysis encompasses activities such as: Determining whether the set of design decisions comprising an architecture are consistent Determining whether an implemented system conforms to the set of design decisions in the architecture Architectural Evolution: The process of modifying the architectural design decisions for a system.

37. Scope of Software Architecture Every system has an architecture Details of the architecture are a reflection of system requirements and trade-offs made to satisfy them Possible decision factors Performance Compatibility with legacy software Planning for reuse Distribution profile Current and future Safety, security, fault tolerance requirements Evolvability needs Changes to processing algorithms Changes to data representation Modifications to the structure/functionality

38. What Makes a “Good” Architecture? Process observations: Product of architect(s) List of quality attributes and functional requirements Architecture is well-documented Circulated to stakeholders Analyzed for quantitative measure and evaluate for quality attributes Results in a specific set of resource contention areas (e.g. network utilization)

39. Product observations: Well-defined modules with well-defined interface Achieve quality attributes using architectural strategy Should not depend on particular version of a commercial product Allows modifiability Feature well-defined processes or tasks What Makes a “Good” Architecture?

40. Why is SA Important? Communication among stakeholders Early design decisions Transferable abstraction of a system Every interesting software-intensive system has an architecture The most successful software architectures are intentional, manifest, and visible - and beautiful Summary

41. Q & A

42. Commercial Software Architecture

43. Commercial software less commonly, payware, is computer software that is produced for sale or that serves commercial purposes. is most often proprietary software, but free software packages may also be commercial software All or parts of software packages and services that support commerce are increasingly made available as free software Commercial off-the-shelf

44. Selecting off-the shelf components The high-level selection process begins with the practice of locating candidates. Selecting off-the-shelf components that fit well together in a new system requires evaluating each candidate off-the-shelf component to ensure the component not only meets functional and quality requirements but also is compatible with other components in the system. Application integrators manage processes and knowledge to ensure successful component selection, component integration, and component maintenance. For systems designed using off-the-shelf component types, with known cost, reliability, and weight, system design and component selection becomes a combinatorial optimization problem.

45. ERP Enterprise resource planning (ERP) integrates internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc. ERP systems automate this activity with an integrated software application. Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. [ [

46. SAP Solutions

47. Three-Tier ERP Systems Architecture

48. SAP System Architecture Divide into three layers, which make up the basic services of a business application system: Presentation layer enables the user to interact with the relevant application Applications are executed in the application layer Data to be processed is managed by the database layer

49. SAP R/3 : Basis System SAP R/3 ในส่วนของ Basis (คำว่า Basis ใน ระบบ SAP ก็คือส่วน System Administration ในระบบ SAP R/3 ) สิ่งแรกที่ต้องรู้คือ SID ของระบบ SAP ซึ่งใน SID ของระบบ SAP R/3 จะประกอบไปด้วย 3 ส่วน ส่วนแรก คือ Presentation Server ซึ่งก็ คือในส่วนของหน้าจอ GUI ส่วนที่สองคือ Application Server หรือ ส่วนของ SAP R/3 Instance ส่วนนี้คือ Kernel ในระบบ SAP เป็นส่วนที่ทำงานใน ด้าน Application Logic ของโปรแกรม ABAP ส่วนสุดท้ายคือ Database Server ซึ่ง เป็นส่วนที่เก็บข้อมูลทั้งหมดในระบบ SAP R/3

50. Architecture of the SAP Web Application Server Installation Options SAP Web Application Server ABAP System. In the graphic these are the components in the yellow box on the left. SAP Web Application Server Java System. In the graphic these are the components in the green box on the right. SAP Web Application Server ABAP+Java System. These are all the components of the graphic.

52. Q&A