Informatics 43 Introduction to Software Engineering

1. Informatics 43Introduction to Software Engineering Lecture 2 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. Today’s lecture • Programming versus software engineering • Complexity, conformity, changeability, intangibility • Software architecture • Examples • Some slides adopted and adopted from “Software Architecture: Foundations, Theory, & Practice” by Taylor, Medvidovic, and Dashofy

3. Today’s lecture • Programming versus software engineering • Complexity, conformity, changeability, intangibility • Software architecture • Examples

4. Essential characteristics • Software engineering concerns the development of large programs • The central theme is mastering complexity • The efficiency with which software is developed is of crucial importance • Software evolves • Regular cooperation between people is an integral part of programming-in-the-large • The software has to support its users effectively • Software engineering is a field in which members of one culture create artifacts on behalf of members of another culture • Software engineering is a balancing act

5. Programming versus software engineering Programming Software engineering

6. From programming to software engineering • People • who else would do the work? • range from novice to very experienced • Processes • to organize and manage the efforts of individuals • range from informal to very formal • Tools • to support the people and the processes • range from simple to very advanced

7. People • The single most important factor in the success/failure of a product • Scarce resource • quality • suitability • cost • Many different kinds of people • managers • programmers • technical writers

8. Processes • Essential to achieve a quality product • Scarce resource • quality • suitability • cost • Many different kinds of processes • bug tracking • change approval • quality assurance

9. Tools • Needed to support people and processes • Scarce resource • quality • suitability • cost • Many different kinds of tools • drawing • analysis • project management • source code management

10. Today’s lecture • Programming versus software engineering • Complexity, conformity, changeability, intangibility • Software architecture • Example #1: Linux • Example #2: iRADS • Example #3: HADOOP • Architectural styles • Principles of software engineering

11. Brooks – Mythical Man Month • Accidental versus essential difficulties • Accidental difficulties • people shortage • not using the right tools • wrong design choice • … • Essential difficulties • complexity • conformity • changeability • intangibility

12. Complexity • No two software parts are alike • if they are, they are abstracted away into one • Complexity grows non-linearly with size • e.g., it is impossible to enumerate all states of a program • except perhaps “toy” programs

13. Conformity • Software is required to conform to its • operating environment • hardware • Often “last kid on block” • Perceived as most conformable

14. Changeability • Change originates with • new applications, users, machines, standards, laws • hardware problems • Software is viewed as infinitely malleable

15. Intangibility • Software is not embedded in space • often no constraining physical laws • No obvious representation • e.g., familiar geometric shapes

16. Drastic consequences • Deceased patients • x-ray machine delivered very high doses because of a timing problem in its control software • Crashed planes • software prevented pilots from performing emergency maneuvers • software had similar codes for different airports • Decreased national security • NSA computers down for four days due to a “software problem” Peter Neumann’s Risks Digest: http://catless.ncl.ac.uk/Risks

17. Today’s lecture • Programming versus software engineering • Complexity, conformity, changeability, intangibility • Software architecture • Examples

18. Software architecture Requirements Code

19. Software architecture Requirements Code

20. 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

21. 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

22. 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

23. 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

24. But still very real power of architecture • Giving preeminence to architecture offers the potential for • intellectual control • conceptual integrity • effective basis for knowledge reuse • realizing experience, designs, and code • effective project communication • management of a set of variant systems • Limited-term focus on architecture will not yield significant benefits!

25. Defining software architecture • 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 facet of the system under development • structure • behavior • interaction • non-functional properties

26. “Principal” • “Principal” implies a degree of importance that grants a design decision “architectural status” • it implies that not all design decisions are architectural • that is, they do not necessarily impact a system’s architecture • How one defines “principal” will depend on what the stakeholders define as the system goals

27. Architecture in action: WWW • This is the Web

28. Architecture in action: WWW • So is this

29. Architecture in action: WWW • And this

30. WWW in a (Big) Nutshell • The Web is a collection of resources, each of which has a unique name known as a uniform resource locator, or “URL” • Each resource denotes, informally, some information • URI’s can be used to determine the identity of a machine on the Internet, known as an origin server, where the value of the resource may be ascertained • Communication is initiated by clients, known as user agents, who make requests of servers. • Web browsers are common instances of user agents

31. WWW in a (big) nutshell (continued) • Resources can be manipulated through their representations • HTML is a very common representation language used on the Web • All communication between user agents and origin servers must be performed by a simple, generic protocol (HTTP), which offers the command methods GET, POST, etc. • All communication between user agents and origin servers must be fully self-contained (so-called “stateless interactions”)

32. WWW’s architecture • Architecture of the Web is wholly separate from the code • 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

33. WWW’s architecture (continued) • Stylistic constraints of the Web’s architectural style are not apparent in the code • the effects of the constraints are evident in the Web • One of the world’s most successful applications is only understood adequately from an architectural vantage point

34. Today’s lecture • Programming versus software engineering • Complexity, conformity, changeability, intangibility • Software architecture • Examples

35. Prescriptive versus descriptive architecture • A system’s prescriptive architecture captures the design decisions made prior to the system’s construction • it is the as-conceived 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

36. Linux – prescriptive architecture

37. Linux – descriptive architecture

38. iRODS – prescriptive architecture

39. iRODS – descriptive architecture

40. HADOOP – prescriptive architecture

41. HADOOP – descriptive architecture

42. HADOOP + MapReduce

43. HADOOP – complete architecture

44. Gap • A gap remains between the prescriptive architecture, which concerns decisions, and the descriptive architecture, which concerns programmatic elements

45. Assignment 2 • Will be out on Wednesday