1 / 45

Informatics 43 Introduction to Software Engineering

Informatics 43 Introduction to Software Engineering. Lecture 2 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. Today’s lecture. Programming versus software engineering

moana
Download Presentation

Informatics 43 Introduction to Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related