CSCI 3428: Software Engineering Tami Meredith Chapter 5 Designing the Architecture

Software Design A highly creative activity No right or wrong solutions – BUT there are good and poor ones Routine design reuses existing solutions for similar problems Innovative design create novel solutions for new and unique problems Reference model: A pre-existing design upon which we base our current design (e.g., for a compiler) Architectural styles: high-level abstract reference models Design patterns: low-level abstract sub-models

Developing the Architecture AnalysisDocumentation Review (Validation) Software Architecture Document (SAD) 1.Develop a set of possible models 2.Figure out which is most suitable 3.Document your decision, rationale, choices 4.Check the design satisfies the requirements specification Modelling

Why? Create a blue-print for development Evaluate evolution, performance, cost, maintenance Support management decisions Understand the system Identify prototyping opportunities Identify dependencies Identify reuse, both internal and external Identify risk

Decomposition Can assist in refinement and abstraction of complex systems Break down into: components, subsystems, process, modules, packages, libraries, classes, ADTs, tables, procedures, routines, Functional: system behaviour or requirements 2. Feature-oriented: user-oriented activities 3. Data-oriented 4. Process-oriented: threads and tasks 5. Event-oriented 6. Object-oriented

Views Decomposition: a break-down of the system in sub- components Dependencies: data (type, subtype, table), execution, development Generalizations & specialisations: type hierarchies Execution: static, dynamic, event Implementation: PL constructs Deployment: Configuration, CPU assignment, memory allocation Work-assignment: teams and tasks

Architecture vs. Specifications Specifications describe how the system will work and what it will do in an abstract manner generally use domain terminology used to communicate to clients/users An Architecture describes how the system will work and be implemented in a concrete manner begins to make decisions among options generally uses technical (software) terminology used to communicate to programmers/developers

Architectural Styles Pipe and filter: e.g., compilers, image processing Client-server: WWW, WoW Peer-to-peer (P2P): File-sharing Publish-Subscribe: broadcast & react Repositories: Google, DB, Blackboard (reactive clients) Layered: Network stacks Hybrid/Combined: Various combinations

Coupling and Cohesion Coupling: The amount of connectivity between components >> Minimise Cohesion: The amount of connectivity within components >> Maximise Goal: Loose Coupling and Tight Cohesion

Architectural Concerns Modifiability: Ability to adapt to change Generality/Flexibility, cohesion, coupling, interfaces Performance Response time, through-put, load Security Immunity, resilience (recovery), detection Usability Accessibility Internationalisation Ease of use, efficiency Business Concerns Costs, development time, cutting-edge

Reliability Difference Between Actual And Planned Use Reliable: performs correctly with valid data Robust: performs "correctly" with invalid data Passive fault detection: identify when a fault has occurred Active fault detection: identify when a fault will occur and prevent it from occurring Recovery Undoing a transaction Roll-back to a previous (valid) state Backup Graceful degradation of service (partial service) Correction and continuation Report and monitoring!

Design Breakdown Lack of a process: no "plan" for doing the design Lack of specialised data schemas: data is complex and not fully understood/described Uncertain priorities leading to poor choices Too many constraints to a problem Problems are just too complicated Remembering what hasn't been figured out Difficulty in combining sub-solutions/components

Agile Methodologies Tend to avoid explicit design Focus on code with design evolving out of necessity Avoid many design problems Lead to poor design for very complex systems Scalability failures – work best for small and modestly complex systems

Outsourcing Bring experts in to assist on-site development Sub-contracting components to off-site developers (local or foreign) Purchasing pre-developed/generic products that can be adapted or wrapped Purchasing a complete custom implementation of the specification Communication Failures: Culture, language (intention, nuance), distance, time- zone/delay, motivation, team stability

Evaluation and Refinement Measure the design quality (e.g., metrics) Safety analysis (e.g., fault tree analysis) Trade-off analysis: pros vs. cons of alternatives Cost-Benefit analysis Security analysis 1. Understand the system 2. Determine threats 3. Assess vulnerability to threats 4. Assess risk/likelihood 5. Assess impact if threat occurs 6. Mitigation and avoidance

Prototyping May by necessary to actually solve the problem Often reveals more than abstract approaches Can be of value to client Helps developers gain understanding/practice Evolutionary vs. Throw-away Can yield huge savings (e.g., 45% less effort, 40% fewer LOC from prototyping) Does not scale to large problems

The Software Design Doc. (SAD) System Overview Various views of the system Catalog of software "units" Analysis data and results of any analysis Design rationale – the "why" for decisions Definitions, Glossary, Acronyms, Units References to specification, standards, etc.

Design Review Validation: Are we actually going to build something that matches the specs and that the customer will want? Verification: Is the design implementable? Can it be improved? What are its limitations? Who? Analysts, Architects, Designers (lower-level), Implementers, Testers, Maintainers, Review Administrators (Moderator, recorder)

Software Product Lines A family of related products (e.g., cell phones) Uses a "core asset base" Specifications vary for each product Common architecture and design Planned "Reuse" among various products Madden Football Demo (limited feature) version Platform: Versions for PC, Xbox, PS3, Wii Temporal: 2010, 2011, League: Used as core of NCAA Football

Scud Thud Famous Moments in Software Engineering On February 25, 1991, an Iraqi Scud Missile hit the barracks in Dhahran, Saudi Arabia, killing 28 US Army soldiers. A Patriot Anti-Missile Missile failed to intercept because of a software error in the system's clock. The Patriot battery had been in operation for 100 hours, by which time the system's internal clock had drifted by one third of a second. Due to the closure speed of the interceptor and the target, this resulted in a miss distance of 600 meters.

The radar system had successfully detected the Scud and predicted where to look for it next, but because of the time error, looked in the wrong part of the sky and found no missile. With no missile, the initial detection was assumed to be a spurious track and the missile was removed from the system. No interception was attempted, and the missile impacted on a barracks killing 28 soldiers. On Feb 11 th (2 weeks earlier), the Israelis had already identified the problem and informed the US Army and the PATRIOT Project Office (the software manufacturer), but no upgrade was present at the time. As a stopgap measure, the Israelis recommended rebooting the system's computers regularly, however, Army officials did not understand how often they needed to do so. The manufacturer supplied updated software to the Army on February 26, the day after the Scud struck the Army barracks.