5 Architectural Design

• What is Software Architecture?

  A representation that enables a software engineer to:

  • Analyze how effectively the design meets its Functional and non-functional requirements.
  • Consider architectural alternatives at a stage when making design changes is still easy
  • Reduce risks with constructing the software
• Why is Software Architecture Important?

  • It provides a representation that helps communication between stakeholders interested in developing a system.
  • Architecture points out design decisions that will have a big impact on all software engineering work that follows.
  • Architecture makes up a small, easy to understand way of how the system is structured and how its components work together.
• Architectural Descriptions

  • Describes the use of architecture viewpoints, architecture frameworks, and architecture description languages as a way to codify the conventions and common practices for architectural description
  • “a collection of products to document an architecture."
  • identifies the system stakeholders having concerns considered fundamental to the architecture of the system-of-interest
• Architecture Decision Documentation

  1. Determine information items needed for each decision
  2. Define links between each decision and appropriate requirements
  3. Provide ways to change status when alternative decisions need to be evaluated
  4. Define prerequisite relationships between decisions to support traceability
  5. Link significant decisions to architectural views resulting from decisions
  6. Document and communicate all decisions as they are made.
• Agility and Architecture

  • To avoid rework, user stories are used to create and evolve an architectural model (walking skeleton) before any coding
  • Use models (allow software architects to add user stories to the evolving storyboard and works with the product owner to prioritize the architectural stories as “sprints” (work units)) are planned
  • Well run agile projects include delivery of architectural documentation during each sprint.
  • After the sprint is completed, the architect reviews the working prototype for quality before the team present sit to the stakeholders in a formal sprint review.
• Architectural Styles

  1. Set of Components
  2. Set of Connectors
  3. Constraints
  4. Semantic Models
• set of components

  • ex- for example: a database or computational modules
  • Task: perform a function required by a system.
• Set of connectors

  • Task: enable “communication, coordination and cooperation” among components.
• Constraints

  • Task: define how components can be integrated to form the system.
• Semantic Models

  • Task: enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.
• Architectural Organization and Refinement: Control

  • How is control managed within the architecture?
  • Is control synchronized, or do components operate asynchronously?
  • What is the control topology (the geometric form that the control takes)?
  • How is control shared among components?
  • How do components transfer control in the system?
  • Is there a specific control hierarchy, if yes, what is the role of components in this control hierarchy?
• Architectural Organization and Refinement: Data.

  • How are data communicated between components?
  • Is the flow of data continuous, or are data objects passed to the system sporadically?
  • What is the mode of data transfer?
  • Do data components exist, if so, what is their role?
  • How do functional components interact with data components?
  • Are data components passive or active?
  • How do data and control interact within the system?
• Architectural Considerations

  • Economy – software is uncluttered and relies on abstraction to reduce unnecessary detail
  • Visibility – Architectural decisions and their justifications should be obvious to software engineers who review
  • Spacing – Separation of concerns in a design without introducing hidden dependencies
  • Symmetry – System is consistent and balanced in its attributes
  • Emergence – Emergent, self-organized behavior and control are key to creating scalable, efficient, and economic software architectures.
• Architectural Design

  • The software must be placed into context- The design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction
  • A set of architectural archetypes should be identified- An archetype is an abstraction (similar to a class) that represents one element of system behavior
  • The designer specifies the structure of the system by defining and refining software components that implement each archetype.
• Architectural Tradeoff Analysis

  1. Collect scenarios
  2. Elicit requirements, constraints, environment description
  3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements using one of these views: module, process, data flow
  4. Evaluate quality attributes by considering each one in isolation.
  5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style.
  6. Critique candidate architectures (developed in step 3) using the sensitivity analysis (conducted in step 5)
• Architectural Reviews

  • Assess the ability of the software architecture to meet the systems quality requirements and identify potential risks
  • Have the potential to reduce project costs by detecting design problems early.
  • Often make use of experience-based reviews, prototype evaluation, and scenario reviews, and checklists
• Pattern-based Architectural Reviews

  1. Identify and discuss the quality attributes by walking through the use cases.
  2. Discuss a diagram of system’s architecture in relation to its requirements
  3. Identify the architecture patterns used and match the system’s structure to the patterns’ structure.
  4. Use existing documentation and use cases to determine each pattern’s effect on quality attributes
  5. Identify all quality issues raised by architecture patterns used in the design.
  6. Develop a short summary of issues uncovered during the meeting and make revisions to the walking skeleton.