software architecture design

Architectural Context Diagram(ACD)

• Superordinate systems - that use the target system • Subordinate systems - that are used by the target system • Peer-level systems - that interact on a peer-to-peer basis (i.e., information are either produced or consumed by the peer and target system) • Actors - entities (people or devices) that interact with the target system - Produce or consume information that is necessary for required functionality

Fundamental understanding of architecture

-Architecture is a set of principal design decisions about a software system (they are the blueprint or characterization of the fundamental structure of the application) -Three fundamental understandings of software architecture: 1. Every application has an architecture 2. Every application has at least one architect 3. Architecture is not a phase of development -Architecture refers to the conceptual essence of an application -> principal decisions : regarding its design / key abstractions -> allowing one to characterize the application -Architecture is not a development phase

Spiral

-Customers understand what they want when they see a prototype -engineers understand how to build something once they have done it once determine objectives and constraints of this iteration -> evaluate alternatives and identify and resolve risks -> develop and verify the prototype for this iteration-> plan the next iteration

Waterfall

-The earlier you find an error the cheaper it is to fix -complete a phase before going on, thus eliminating as many errors as possible requirements analysis and specifications -> architectural design -> implementation and integration -> verification -> operation and maintenance

Rational Unified Process

-combined features of waterfall and spiral with standardize diagrams and documentations inception(focuses on schedules and budgets) -> elaboration(work with stakeholders to identify use cases, design a software architecture, and builds initial prototypes)-> construction(codes and test the product) -> transition(moves product from development to production)

Architecture benefits/focus

1. Allows us to evaluate the behavior of the system before implementing it 2. provides a framework for evaluating and reusing strategies and decisions that were used to solve similar problems 3. Helps capture early decisions that impact the overall principles of the system 4. facilitate communication between stakeholders, by mapping requirements to the solution 5. help risk and reduces cost

More about architecture..

1. Architecture refers to: 1. high level structures of a software system 2. discipline of creating structures 3. documentation of structures 2. Each structure is made up: 1. software elements 2. relationships 3. properties of both 3. Architecture captures: 1. early decisions about high level design 2. allows reuse of design components

How to start an architectural design?

1. Place the software in a context - Identify external entities (other systems, devices, people) that interact with and the system - Identify the nature of the interaction 2. Define a set of architectural components - Unit of data or computation 3. Specify the structure of the system in terms of component -Obtained from step-wise refinement (top-down and bottom-up)

Agile development

1. Test driven development -> intended to reduce mistakes, write test before code 2. user stories -> reach agreement, validate customer requirements 3. velocity -> measure project progress, new versions of the software are available every week or two weeks

Software Development Life Cycle

1.Requirements: what the system should do (define the problem, devise a contract with the customer) 2. Architecture/Design: How the product should work (Architecture-> decomposition in terms of modules and their interfaces) (Design-> specify modules .. algorithms, data types) 3. Implementation & integration -> how the product does its tasks. (Implement modules, verify their functionality, integrate modules)

Deployment

A software system cannot fulfill its purpose until it is deployed • Its executable modules are physically placed on the hardware devices on which they are intended to run • The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements. • Possible assessment dimensions • Sufficient memory • Power consumption • Available and required bandwidth

Architecture Structures

Architecture Structures •High level abstraction of software that identifies high-level modules, components& connectors, and allocations •Modules •Consider a static way of looking at the system •Help us reason about how the system can be modified •Components and Connectors •Focuses on the runtime behavior (components) and interaction of the elements (connectors) •Help us understand the system's runtime properties •Allocations •Captures the relationships between the system and non-software structures •Help us understand how the system maps to hardware, teams, file systems

Architecture vs Dersign

Architecture: concerned with the selection of architectural elements, their interactions, and the constrains on those elements. Also, the interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design - Architecture concerns itself with longer-range issues. Competing and often conflicting influences/demands, few of them deal with the correct behavior of system, implicit requirements tied to organizational and technical environment Design: concerned with the modularization, detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture to satisfy the requirements, -design concerns itself with taking the right steps to ensure that the systems performs as expected (provide the right answer, provide expected functionality)

software architecture

Definition: the set of structures needed to reason about the system, which comprises of software elements, relationship among them, and properties of both

Software Engineering

Development of software systems whose size/complexity warrants team of engineers Goal ->development of high quality product - meets the requirements, delivered in time and within budget

Pros and Cons of OOD

Pros ↑Usually taught in the context of programming ↑UML modeling notation ↑Design patterns •Cons ↓Provides only •One software species -object •One level of encapsulation (the object) •One notion of interface •One type of explicit connector (procedure call) •How do you think message passing is implemented? ↓Closely tied to the OO programming language; affecting important design decisions ↓OOD assumes a shared address space •Originally single thread of control •Not accommodating for concurrent, distributed, decentralized architectures •No mechanism to deal with NW failures, latency, domain authority, etc.

Another definition of SOFTWARE ARCHITECTURE

Software architecture [is a level of design that] involves •the description of elementsfrom which systems are built •interactionsamong those elements •patternsthat guide their composition, and •constraintson these patterns •Architecture is a set of software structures •modules; components and connectors; allocations (mapping from software structures to the system's organizational, developmental, installation, and execution environments) •Architecture is an abstraction •Every software system has a software architecture •Architecture includes behavior •Not all architectures are good architectures

Software Design

Software design is concerned with descriptions of programs or design statements 1. strategic statements -> architectural design which are global design properties 2. tactical statements-> detailed design which determine local properties 3. implementation statements -> determine specific properties of the program

Non-functional requirements

Software system qualities attributes -ilities •Fault-tolerance •Backwards compatibility •Extensibility •Reliability •Maintainability •Availability •Security •Usability

Domain Specific Software Architecture

•Appropriate when prior experience and architecture are able to strongly influence new projects •Capture and characterize the best solutions and best practices from past projects within a domain •Focus on the points of novel variation when working on new applications •Reuse of architecture and implementation -Need for good technical foundation and support •Naturally applicable for product lines

Relationship between architecture, design and requirements

•Architecture is design but not all design is architectural •Through the definition of the architecture we identify the characteristics of a design •Software architecture is described as the high-level design or architectural design •Strategic approach and principles for building a solution •Software Design is characterized as detailed-design •Specific approach to building a solution •Requirements define the constraints of the problem that the solution needs to follow •Requirements = "What" •Architecture = Principles for the "How" •Design = Details of the "How"

Drift and Erosion

•Changes applied directly to a system's descriptive architecture may result in: •Architectural drift •When changes are not properly reflectedin the system's prescriptive architecture •Architectural erosion •When changes violate design decisionscaptured by the system's prescriptive architecture

Prescriptive vs. Descriptive Architecture

•Design decisions change, evolve, fork, converge, etc. during system's life span •Architectures evolve hundreds of times there are hundreds of related architectures per system in its lifetime •Architectures are temporal artifacts •Prescriptivearchitecture captures design decisions made prior to the system's construction •Descriptivearchitecture describes how the system has been built

Architectural Recovery

•If drift or erosion are allowed to occur, the development organization is likely to be forced to recover the system's architecture sooner or later. •Architectural recovery: the process of determining a software system's architecture from its implementation-level artifacts. •Implementation-level artifacts can be •Source code, Executable files, Java .class files, ...

Non functional properties (NFPs)

•NFPs are the result of architectural choices •NFP questions are raised as the result of architectural choices •Specification of NFP might require an architectural framework to even enable their statement •An architectural framework will be required for assessment of whether the properties are achievable

Architectural Evolution

•Systems evolve •Ideally the prescriptive architecture is modified first •In practice, often the system (and thus its descriptive architecture) is directly modified •This failure of update happens because of •Lack of documented prescriptive architecture •Developer sloppiness •Perception of short deadlines which prevent thinking through and documenting •Need or desire for code optimizations •Inadequate techniques or tool support

Design Architecture

•Two widely adapted strategies •Object-oriented design •Encapsulations of state with functions for accessing and manipulating that state •Domain-specific software architectures (DSSA)