lesson 2 Flashcards by S D

typically refers to the bigger structures of a software
system, and it deals with how multiple software processes cooperate to carry out
their tasks.

Software Architecture

How well did you know this?

Not at all

Perfectly

provides a design plan that describes the elements of a system, how
they fit, and work together to fulfill the requirements of the system.

Software design

How well did you know this?

Not at all

Perfectly

It comes before the detailed design, coding, integration, and testing and after the
domain analysis, requirements analysis, and risk analysis.

Software design

How well did you know this?

Not at all

Perfectly

Components of software architecture (5)

Design
Business Strategy
Quality Attributes
IT Environment
Human Dynamics

How well did you know this?

Not at all

Perfectly

provides a solution that the technical team can create
and design for the entire application.

Software Architect

How well did you know this?

Not at all

Perfectly

A software architect should have expertise in the following areas

• Design Expertise
• Domain Expertise
• Technology Expertise
• Methodological Expertise

How well did you know this?

Not at all

Perfectly

is a measure of excellence or the state of being free
from deficiencies or defects.

Quality

How well did you know this?

Not at all

Perfectly

are the system properties that are separate
from the functionality of the system.

Quality attributes

How well did you know this?

Not at all

Perfectly

Reflect the structure of a system and organization, directly related to
architecture, design, and source code.

Static Quality Attributes

How well did you know this?

Not at all

Perfectly

Reflect the behavior of the system during its execution. They are directly
related to the system’s architecture, design, source code, configuration,
deployment parameters, environment, and platform.

Dynamic Quality Attributes

How well did you know this?

Not at all

Perfectly

specify how to prevent a fault from becoming a failure.

Quality scenarios

How well did you know this?

Not at all

Perfectly

Parts of Quality Scenarios (6)

• Source
• Stimulus
• Environment
• Artifact
• Response
• Response measure

How well did you know this?

Not at all

Perfectly

Defines the consistency and
coherence of the overall design. This
includes the way components or
modules are designed.

Category:
Design Qualities
Quality Attribute: Conceptual Integrity

How well did you know this?

Not at all

Perfectly

Ability of the system to undergo
changes with a degree of ease.

Category: Design Qualities
Quality Attribute: Maintainability

How well did you know this?

Not at all

Perfectly

Defines the capability for
components and subsystems to be
suitable for use in other applications.

Category: Design Qualities
Quality Attribute: Reusability

How well did you know this?

Not at all

Perfectly

Ability of a system or different systems to operate
successfully by communicating and exchanging
information with other external systems written and run by
external parties.

Category: Run-time Qualities
Quality Attribute: Interoperability

How well did you know this?

Not at all

Perfectly

Defines how easy it is for system administrators to manage
the application.

Category: Run-time Qualities
Quality Attribute: Manageability

How well did you know this?

Not at all

Perfectly

Ability of a system to remain operational over time.

Category: Run-time Qualities
Quality Attribute: Reliability

How well did you know this?

Not at all

Perfectly

Ability of a system to either handle the load increase
without impacting the performance of the system or the
ability to be readily enlarged.

Category: Run-time Qualities
Quality Attribute: Scalability

How well did you know this?

Not at all

Perfectly

Capability of a system to prevent malicious or accidental
actions outside of the designed usages.

Category: Run-time Qualities
Quality Attribute: Security

How well did you know this?

Not at all

Perfectly

Indication of the responsiveness of a system to execute
any action within a given time interval.

Category: Run-time Qualities
Quality Attribute: Performance

How well did you know this?

Not at all

Perfectly

Defines the proportion of time that the system is
functional and working. It can be measured as a
percentage of the total system downtime over a
predefined period.

Category: Run-time Qualities
Quality Attribute: Availability

How well did you know this?

Not at all

Perfectly

Ability of the system to provide
information helpful for identifying and
resolving issues when it fails to work
correctly.

Category: System Qualities
Quality Attribute: Supportability

How well did you know this?

Not at all

Perfectly

Measure of how easy it is to create test
criteria for the system and its
components.

Category: System Qualities
Quality Attribute: Testability

How well did you know this?

Not at all

Perfectly

Defines how well the application meets the requirements of the user and consumer by being intuitive.

Category: User Qualities Quality Attribute: Usability

Accountability for satisfying all the requirements of the system.

Category: Architecture Quality Quality Attribute: Correctness

Ability of the system to run under different computing environment.

Category: Non-runtime Quality Quality Attribute: Portability

Ability to make separately developed components of the system work correctly together.

Category: Non-runtime Quality Quality Attribute: Integrality

Ease with which each software system can accommodate changes to its software.

Category: Non-runtime Quality Quality Attribute: Modifiability

Cost of the system with respect to time to market, expected project lifetime & utilization of legacy.

Category: Business quality attributes Quality Attribute: Cost and schedule

Use of systems with respect to market competition.

Category: Business quality attributes Quality Attribute: Marketability

also called an architectural pattern, is a set of principles which shapes an application. It defines an abstract framework for a family of systems in terms of the pattern of structural organization.

Architectural Style

Prescribes use of a software system that can receive and send messages using one or more communication channels.

Category: Communication Architectural Design: Message Bus

Defines the applications that expose and consume functionality as a service using contracts and messages.

Category: Communication Architectural Design : Service-Oriented Architecture (SOA)

Separate the system into two applications, where the client makes requests to the server.

Category: Deployment Architectural Design: Client/Server

Separates the functionality into separate segments with each segment being a tier located on a physically separate computer.

Category: Deployment Architectural Design: 3-tier or N-tier

Focused on modeling a business domain and defining business objects based on entities within the business domain.

Category: Domain Architectural Design: Domain Driven Design

Breakdown the application design into reusable functional or logical components that expose well-defined communication interfaces.

Category: Structure Architectural Design: Component Based

Divide the concerns of the application into stacked groups (layers).

Category: Structure Architectural Design: Layered

Based on the division of responsibilities of an application or system into objects, each containing the data and the behavior relevant to the object.

Category: Structural Architectural Design: Object Oriented

Types of Architecture (4)

•Application (software) architecture •Business architecture •Information architecture •Information technology (IT) architecture

Defines the strategy of business, governance, organization, and key business processes within an enterprise and focuses on the analysis and design of business processes

Business architecture

Serves as the blueprint for individual application systems, their interactions, and their relationships to the business processes of the organization.

Application (software) architecture

Defines the logical and physical data assets and data management resources

Information architecture

Defines the hardware and software building blocks that make up the overall information system of the organization.

Information technology (IT) architecture

Architecture Design Process (4)

• Understand the Problem • Identify Design Elements and their Relationships • Evaluate the Architecture Design • Transform the Architecture Design

Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this

Build to Change Instead of Building to Last

Use design tools, visualizations, modeling systems such as UML to capture requirements and design decisions.

Reduce Risk and Model to Analyze

Efficient communication of the design, the decisions, and ongoing changes to the design is critical to good architecture.

Use Models and Visualizations as a Communication and Collaboration Tool

Start with baseline architecture and then evolve candidate architectures by iterative testing to improve the architecture. Iteratively add details to the design over multiple passes to get the big or right picture and then focus on the details.

Use an Incremental and Iterative Approach

Key Architecture Principles (4)

• Build to Change Instead of Building to Last • Reduce Risk and Model to Analyze • Use Models and Visualizations as a Communication and Collaboration Tool • Use an Incremental and Iterative Approach -

Divide the components of system into specific features so that there is no overlapping among the components functionality.

Separation of Concerns

Each and every module of a system should have one specific responsibility, which helps the user to clearly understand the system.

Single Responsibility Principle

Any component or object should not have the knowledge about internal details of other components.

Principle of Least Knowledge

Minimize large design upfront if the requirements of an application are unclear. If there is a possibility of modifying requirements, then avoid making a large design for whole system.

Minimize Large Design Upfront

Do not repeat functionality specifies that functionality of components should not to be repeated and hence a piece of code should be implemented in one component only.

Do not Repeat the Functionality

Inheritance creates dependency between children and parent classes and hence it blocks the free use of the child classes.

Prefer Composition over Inheritance while Reusing the Functionality

Identity components and the area of concern that are needed in system to satisfy the requirements. Then group these related components in a logical layer, which will help the user to understand the structure of the system at a high level.

Identify Components and Group them in Logical Layers

Understand how components will communicate with each other which requires a complete knowledge of deployment scenarios and the production environment.

Define the Communication Protocol between Layers

Various components will interact with each other through data format.

Define Data Format for a Layer

Code related to security, communications, or system services like logging, profiling, and configuration should be abstracted in the separate components.

System Service Components should be Abstract

Defining exceptions in advance, helps the components to manage errors or unwanted situation in an elegant manner.

Design Exceptions and Exception Handling Mechanism

Naming conventions should be defined in advance. They provide a consistent model that helps the users to understand the system easily.

Naming Conventions

Key Design Principles

• Separation of Concerns • Single Responsibility Principle • Principle of Least Knowledge • Minimize Large Design Upfront • Do not Repeat the Functionality • Prefer Composition over Inheritance while Reusing the Functionality • Identify Components and Group them in Logical Layers • Define the Communication Protocol between Layers • Define Data Format for a Layer • System Service Components should be Abstract • Design Exceptions and Exception Handling Mechanism • Naming Conventions

A software architecture design must conform to the major functionality and performance requirements of the system, as well as satisfy the non-functional requirements such as reliability, scalability, portability, and availability.

Architecture Models

UML is one of object-oriented solutions used in software modeling and design.

UML (Unified Modeling Language)

Architecture view model represents the functional and non-functional requirements of software application.

Architecture View Model (4+1 view model)

ADL defines the software architecture formally and semantically.

ADL (Architecture Description Language)

It is a pictorial language used to make software blueprints.

UML (Unified Modeling Language)

UML stands for

Unified Modeling Language

was created by Object Management Group (OMG).

UML (Unified Modeling Language)

The UML 1.0 specification draft was proposed to the OMG in

January 1997.

It serves as a standard for software requirement analysis and design documents which are the basis for developing a software.

UML (Unified Modeling Language)

can be described as a general purpose visual modeling language to visualize, specify, construct, and document a software system.

UML Unified Modeling Language

is generally used to model software system, it is not limited within this boundary. It is also used to model non software systems such as process flows in a manufacturing unit.

UML Unified Modeling Language

represent the static aspects of a system. These static aspects represent those parts of a diagram which forms the main structure and is therefore stable.

Structural Diagrams

parts of a Structural diagram (6)

• Class diagram • Object diagram • Component diagram • Deployment diagram • Package diagram • Composite structure

capture the dynamic aspect of a system. Dynamic aspects are basically the changing/moving parts of a system.

Behavioral diagrams

parts of a Behavioral diagram (7)

• Use case diagram • Sequence diagram • Communication diagram • State chart diagram • Activity diagram • Interaction overview • Time sequence diagram

was designed by Philippe Kruchten to describe the architecture of a software–intensive system based on the use of multiple and concurrent views.

4+1 View Model or Architecture View Model

It standardizes the software design documents and makes the design easy to understand by all stakeholders.

4+1 View Model or Architecture View Model

It is a __ view model that addresses different features and concerns of the system.

multiple view

The 4+1 View Model was designed by __ to describe the architecture of a software–intensive system based on the use of multiple and concurrent views.

Philippe Kruchten

4+1 View Model provides four essential views

• The logical view or conceptual view • The process view • The physical view • The development view

is a language that provides syntax and semantics for defining a software architecture. It is a notation specification which provides features for modeling a software system’s conceptual architecture, distinguished from the system’s implementation.

Architecture Description Language (ADL)

must support the architecture components, their connections, interfaces, and configurations which are the building block of architecture description.

Architecture Description Languages (ADLs)

It is a form of expression for use in architecture descriptions and provides the ability to decompose components, combine the components, and define the interfaces of components.

Architecture Description Languages (ADLs)

lesson 2 Flashcards

(87 cards)