Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering Lecture 4-1 October 20, 2015 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 2 Today’s lecture Software architecture Guest interview Some slides adopted and adopted from “Software Architecture: Foundations, Theory, & Practice” by Taylor, Medvidovic, and Dashofy

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 3 Today’s lecture Software architecture Guest interview

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 4 Software architecture Requirements Code

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 5 Software architecture Requirements Code

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 6 Software architecture Requirements Code Architecture & Design

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 7 An analogy to building architectures We all live in them (We think) We know how they are built – requirements – design (blueprints) – construction – use This is similar (though not identical) to how we build software

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 8 Parallels Design before build Satisfaction of customers’ needs Specialization of labor Multiple perspectives of the final product Intermediate points where plans and progress are reviewed

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 9 The architect A distinctive role and character in a project Very broad training Amasses and leverages extensive experience A keen sense of aesthetics Deep understanding of the domain – properties of structures, materials, and environments – needs of customers

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 10 Limitations of analogy Software serves a much broader range of purposes We know a lot about buildings, much less about software The nature of software is different from that of building architecture Software is much more malleable than physical materials Software is a machine; a building is not

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 11 But architecture is still a very powerful tool in software engineering Giving preeminence to architecture offers the potential for – intellectual control – conceptual integrity – effective project communication – reusability – maintainability (management of a set of variant systems) Limited-term focus on architecture will not yield significant benefits!

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 12 Defining software architecture A software system’s architecture is the set of principal design decisions about the system Design decisions Architectural decisions “Principal” Structure Behavior Interaction Non-functional properties

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 13 Defining software architecture Software architecture is the blueprint for a software system’s construction and evolution

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 14 Other definitions Clements, Bass, Kazman: The set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Spinellis: how your whole system (in the widest possible sense) will be decomposed into processes or services; how data are stored, communicated, and processed; and how all parts fit together to deliver the required functionality, reliability, capacity, scalability, maintainability, and portability.

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 15 Other definitions Fowler: The highest-level breakdown of a system into its parts; the decisions that are hard to change Natarén: The clear definition of multiple high-level components that, when working together, form your system and solve your problem

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 16 functional specification Send and receive messages Get your own messages, not others’ – Addressing scheme Store messages Electronic Blocks spam

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu Architecture Client

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 18 Architecture in action: WWW This is the Web

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 19 Architecture in action: WWW So is this

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu Architecture in action: WWW And this

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 21 WWW in a (Big) Nutshell The Web is a collection of resources, each of which has a unique name (URL) A URL can be used to determine the identity of a machine on the Internet (origin server), from which the resource may be obtained Clients (user agents/Web browsers) make requests of servers for their resources

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 22 WWW in a (big) nutshell (continued) Clients manipulate representations of resources – e.g., an HTML representation All communication between user agents and origin servers must be performed by a simple, generic protocol (HTTP) All communication between user agents and origin servers must be fully self-contained (so-called “stateless interactions”)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 23 Observations about WWW’s architecture There is no single piece of code that implements the architecture There are multiple pieces of code that implement the various components of the architecture – e.g., different Web browsers Stylistic constraints of the Web’s architectural style are not apparent in the code One of the world’s most successful applications is only understood adequately from an architectural vantage point

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 24 Observations about WWW’s architecture There is no single piece of code that implements the architecture There are multiple pieces of code that implement the various components of the architecture – e.g., different Web browsers Stylistic constraints of the Web’s architectural style are not apparent in the code One of the world’s most successful applications is only understood adequately from an architectural vantage point All of the diagrams and text on the previous several slides = WWW’s architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 25 Facebook Architecture – Functional Requirements Friend lists Status updates News feed Comments Messaging Photos Location services 3 rd party apps …

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 26 Non-Functional Requirements (behind-the-scenes features) Performance: Scalability: Availability: Security: Privacy: Reliability: Portability: Fast. High. Don’t hack my account. Fast even with lots of users. Don’t collect my data? Don't delete my data by accident. Works on different platforms (operating systems, web browsers, phones, etc.)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 27 Client Server Architecture Most common distributed system architecture Clients make requests of servers Centralized – data – security – access

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 28 Does Facebook only have one server?

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 29

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 30 Facebook has LOTS and LOTS of servers. >180,000 servers across multiple data centers.

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 31

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 32 Netflix Architecture Diagram

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 33 Twitter Architecture Diagram

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 34 Software architecture’s elements A software architecture consists of – Components Data Processing – Connectors Interaction E.g., function calls, shared memory, information streams Components and connectors are arranged into configurations

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 35 Example configuration ship course ship radar GPS unit function call component connector

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 36 Example configuration - simplified ship course ship radarGPS unit component connector

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 37 Reminder: Recurring, fundamental principles Rigor and formality Separation of concerns – modularity – divide and conquer – abstraction Anticipation of change Generality Incrementality

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 38 Prescriptive versus 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 – as recovered from its implementation-level artifacts (e.g., source code, executable files, Java.class files, …)

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 39 Linux – prescriptive architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 40 Linux – descriptive architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 41 iRODS – prescriptive architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 42 iRODS – descriptive architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 43 HADOOP – prescriptive architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 44 HADOOP – descriptive architecture

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 45 Gap A gap remains between the prescriptive architecture, which concerns decisions, and the descriptive architecture, which concerns programmatic elements

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 46 Architectural evolution When a system evolves, ideally its prescriptive architecture is modified first In practice, the system – and thus its descriptive architecture – is often directly modified This 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 support

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 47 Next time More on software architecture Homework 1 due Thursday! – No late submissions accepted (seriously) Discussion tomorrow – Use cases

Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 48 Today’s lecture Software architecture Guest interview