CS 5150 Software Engineering Lecture 12 Software Architecture 1

CS Administrivia You should have received comments on your reports Presentation room TBD (today)

CS First Presentation Preparation Who is your audience? Primary: Client(s), instructor Secondary: TA Practice! Presenter should stand, others should sit A team member should take notes When asked a question, the presenter should answer Refer to other team members if necessary It is unprofessional to interrupt your colleagues

CS SE in the News LinkedIn mobile redesign Fast, easy, reliable House metaphor Mix of native and web Microsoft just announced TypeScript Dart, GWT, Script#

CS Software Architecture Lots of pieces of the puzzle Operational definition: Technical decisions made early in a project that are expensive to change Equal parts experience and engineering creativity, with a sprinkling of science A Pattern Language. Ishikawa, Alexander, Silverstein

CS Components of Software Architecture Computers and networks (e.g., monolithic, distributed) Interfaces and protocols (e.g., http, ODBC) Databases (e.g., relational, distributed) Security (e.g., smart card authentication) Operations (e.g., backup, archiving, audit trails) Software environments (e.g., languages, source control tools) Testing frameworks

CS Language and Framework Choice If you are working in an established application domain, go with a popular choice If you are trying to define a new niche, unusual choices might be appropriate Long-lived projects tend to become multi- lingual No necessarily bad, but carries a high cost

CS Machine-Level Concurrency (Distribution) Can/Do components of your application run on different computers? Inherent in application domain: , big scientific simulations Isolation: security-sensitive data lives on a different machine Convenience: Use an application locally or remotely

CS Distribution Has Big Costs Moving data from one machine to another More special cases to handle Testing is much harder Installation and maintenance can be more complex Conclusion: do not split your application into pieces that can run on different computers unless there is a compelling reason

CS Modules and Interfaces Architecture is all about Modules (sub-components, classes, pieces,...) Interfaces (methods, protocols, languages, data types,...) Goal: Module interactions are strictly governed by interfaces Cognitive burden Replacement Human work parallelization

CS Architectural Pattern: Pipes Chain or pipe of components

CS Architectural Pattern: Three Tiers Popular in web design Many variations on the theme exist How much logic belongs in Presentation versus Application?

CS Architectural Pattern: Repository Advantage: Flexible pattern for data-intensive applications Disadvantage: Repository can be a bottleneck and an artificial block to code evolution

CS Improvement on Repository Pattern

CS Architectural Patterns for Distributed Data Mirrors Caches Single-owner Consistency and performance are hard to balance properly in distributed data schemes

CS Good Software Architecture How do you know if an architecture is good? Experience always plays an important role Do the module boundaries (interfaces) correlate well with actual interactions in the application? Direct invocation Data send/receive Indirect invocation Indirect data paths Leaky abstractions!