Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering Lecture 3 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.
Informatics 43 Introduction to Software Engineering
Feb 26, 2016
Informatics 43 Introduction to Software Engineering. Lecture 3 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. Today’s lecture. Evolution Architectural styles Principles of software engineering. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 1
Informatics 43Introduction to Software Engineering
Lecture 3
Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 2
Today’s lecture
• Evolution• Architectural styles• Principles of software engineering
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 3
Today’s lecture
• Evolution• Architectural styles• Principles of software engineering
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 4
Facebook (2005)
From: http://mashable.com/2011/09/22/facebook-profile-evolution/
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 5
Facebook (2006)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 6
Facebook (2007)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 7
Facebook (2008)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 8
Facebook (2009)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 9
Facebook (2010)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 10
Facebook (2011)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 11
Facebook (2011)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 12
Facebook evolution
• User interface– http://www.grosocial.com/blogposts/Evolution-Facebook-Features
– http://www.youtube.com/watch?v=Nl7igMfeOvo
• Architecture– http://www.infoq.com/presentations/Facebook-Software-Stack
– http://www.infoq.com/presentations/Evolution-of-Code-Design-at-Facebook
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 13
Airplane cockpit (Boeing 787)
From: http://www.boeing.com/commercial/aeromagazine/articles/2012_q1/3/
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 14
Airplane cockpit (Boeing 787)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 15
Airline cockpit (Boeing 747)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 16
Airline cockpit (Boeing 747)
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 17
Angry Birds
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 18
Evolution
• Essential part of software development
• Must be accommodated as much as possible
• Must be planned as much as possible
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 19
Today’s lecture
• Evolution • Architectural styles• Principles of software engineering
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 20
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
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 21
“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
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 22
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
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 23
Components
• Elements that encapsulate processing and data in a system’s architecture are referred to as software components
• A software component is an architectural entity that – encapsulates a subset of the system’s functionality and/or data– restricts access to that subset via an explicitly defined interface– has explicitly defined dependencies on its required execution context
• Components typically provide application-specific services
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 24
Connectors
• In complex systems interaction may become more important and challenging than the functionality of the individual components
• A software connector is an architectural building block tasked with effecting and regulating interactions among components
• In many software systems connectors are usually simple procedure calls or shared data accesses– much more sophisticated and complex connectors are possible
• Connectors typically provide application-independent interaction facilities
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 25
Examples of connectors
• Procedure call connectors • Shared memory connectors • Message passing connectors • Streaming connectors • Distribution connectors• Wrapper/adaptor connectors
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 26
Configuration
• Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective
• An architectural configuration, or topology, is a set of specific associations between the components and connectors of a software system’s architecture
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 27
Example configuration
ship course
ship radar GPS unit
procedure call procedure call procedure call
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 28
Architectural style
• 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
• 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
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 29
Style 1: object-oriented
ship course
ship radar GPS unit
procedure call procedure call procedure call
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 30
Style 2: model-view-controller
teller
procedure call
procedure call
procedure callrules
back account
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 31
Style 3: client-server
game client 2
game server
remote call remote call remote call
game client 1 game client 3
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 32
Style 4: blackboard
viewer
document
data access
autosave spell checker
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 33
Style 5: peer-to-peer
skype 1
skype 3skype 2
stream stream
stream
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 34
Style 6: pipe-and-filter
print records stream sort stream remove duplicates
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 35
Style 7: pub-sub
stock market
remote callremote call stream remote call
trader 1 trader 2 trader 3
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 36
Mixing styles is often necessary
stock market server
remote callremote call stream remote call
trader 1 trader 2 trader 3
procedure call
procedure call
procedure callpurchasing rules
stock database
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 37
Mixing styles of often necessary
spotify server
spotify clientspotify client
stream stream
remote call
spotify master
stream
spotify client
stream
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 38
Back to evolution
• Essential part of software development
• Must be accommodated as much as possible
• Must be planned as much as possible
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 39
Accommodating change
teller
procedure call
procedure call
procedure callrules
back account
New overdraft rule?
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 40
Accommodating change
skype 1
skype 3skype 2
stream stream
stream
Another user?
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 41
Accommodating change?
list records stream sort stream remove duplicates
Only records names starting with a letter from the first half of the alphabet?
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 42
Accommodating change
stock market server
remote callremote call stream remote call
trader 1 trader 2 trader 3
procedure call
procedure call
procedure callpurchasing rules
stock databaseAnother stock?
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 43
Accommodating change
stock market server
remote callremote call stream remote call
trader 1 trader 2 trader 3
procedure call
procedure call
procedure callpurchasing rules
stock databaseAnother trader?
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 44
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 IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 45
Today’s lecture
• Evolution • Architectural styles• Principles of software engineering
Department of Informatics, UC IrvineSDCL Collaboration LaboratorySoftware Design and
sdcl.ics.uci.edu 46
Recurring, fundamental principles
• Rigor and formality• Separation of concerns
– modularity– abstraction
• Anticipation of change• Generality• Incrementality
Related Documents
