TOPCIT Software | 06. Software Architecture
Summary
TLDRThis script delves into the core components of software architecture, including meta-architecture, guidelines, and policies. It explains the significance of defining views, the role of software architecture in development, and the impact on project organization and system quality. The video also explores various architectural styles, such as dataflow, call-return, data-centered, and event system groups, emphasizing the importance of high-level design for creating modular, scalable, and maintainable software systems.
Takeaways
- 📚 The script discusses the components of software architecture, focusing on meta architecture, software architecture, and guidelines and policies.
- 🔍 Meta architecture provides general guidelines and design patterns for software architecture, including templates for architectural documents.
- 🌐 Software architecture is described through four views: module, component and connector, allocation, and code view, which aid in deriving context diagrams and specifications.
- 👥 Defining views should consider selection criteria and notes, as different people may have varying methods for description, such as diagrams, shapes, boxes, and lines.
- 🛠 The number of views chosen depends on factors like developer competence, domain understanding, previous project experience, and major issues to be addressed.
- 🔑 Architectural design impacts the overall system structure, project organization, and quality attributes such as functionality, availability, changeability, security, and performance.
- 📈 UML 2.0 has adopted architecture definitions from Carnegie Mellon University to simplify the representation of architectural views.
- 🛑 Guidelines and policies are crucial for determining software architecture and conducting projects based on the defined architecture, covering aspects from design to system operation.
- 🔄 The role of software architecture in development includes communication between stakeholders, early decision-making, overall system structure determination, and development project organization.
- 🔍 Types of software architecture are categorized into dataflow, call return, data centered, and event system groups, each with its own advantages and disadvantages.
- 🏗️ High-level design aims to develop a modular software architecture, involving decomposing the system into clear modules and describing their integration and interaction.
- 🔧 Object-oriented methodology involves refining object and behavior analysis models into a design model, considering logical software architecture and client-server architecture.
Q & A
What are the three main components of a software architecture in high-level design?
-The three main components are meta architecture, software architecture, and guidelines and policies.
What is the role of meta architecture in software design?
-Meta architecture serves as a general guideline for designing and architecture, providing a set of general decision trees and design patterns for defining the architecture of the software.
What are the four views that constitute the software architecture?
-The four views are the module view, component and connector view, allocation view, and code view.
Why is it important to derive context diagrams, components specification, and interface specification from architectural design?
-These derivations are important as they provide a clear understanding of the system's structure and behavior, which is essential for effective communication and further development.
How many views are typically defined in a software architecture, and what factors determine the appropriate number?
-Typically, three views are defined: module view, component and connector view, and allocation view, with the code view sometimes added. The appropriate number of views depends on factors such as the competence of developers, understanding of the domain, experience from previous projects, and the major issues to be addressed.
What are the roles of software architecture in system development?
-The roles include facilitating communication between stakeholders, aiding in early decision-making, determining the overall system structure, influencing the organization of the development project, and predicting the system's quality attributes.
How does the software architecture impact the development process?
-The software architecture impacts the development process by guiding the design using patterns and guidelines, providing coding standards, and offering deployment guidelines, which contribute to building a structured and stable software architecture.
What are the types of software architecture grouped into, and what are some examples of each?
-The types are grouped into dataflow, call return, data centered, and event system groups. Examples include batch sequential processing and filter types for dataflow, layers, main programs and subroutines, and object-oriented types for call return, centralized data repository and data-consuming client for data centered, and implicit call and explicit call types for event systems.
What is the purpose of structured high-level design in software development?
-The purpose of structured high-level design is to develop a modular software architecture based on specifications, which involves decomposing the system into clear modules and describing how these modules integrate and interact.
How does the task structure design phase contribute to the development of a software system?
-The task structure design phase contributes by identifying tasks that can be performed simultaneously, describing the dynamic aspects of the system, and integrating tasks within time constraints, which helps in organizing the system's processes effectively.
What are the key activities involved in determining the logical software architecture?
-Key activities include vertical layering, horizontal decomposition, subsystem decomposition, technology environment definition, and subsystem interface design.
Outlines
🛠️ Software Architecture Components
This paragraph introduces the core components of software architecture, emphasizing the importance of meta-architecture, which provides general guidelines and patterns for designing software. It discusses the role of the architect and the necessity of templates for architectural documentation. The paragraph also delves into the four views of software architecture: module view, component and connector view, allocation view, and code view. It highlights the need for deriving context diagrams, component specifications, and interface specifications from architectural design. The discussion points out the variability in defining views and the importance of considering factors such as developer competence, domain understanding, and project experience when determining the number of views. The paragraph concludes by discussing the significance of quality attributes like system functionality, availability, changeability, security, and performance in the architectural design process.
🔄 Evolution of UML and Software Architecture Guidelines
The second paragraph addresses the evolution of UML from version 1.x to 2.0, noting the shift towards a less technology-dependent design, influenced by Carnegie Mellon University's SEI. It discusses how guidelines and policies are crucial for defining software architecture and conducting projects based on that architecture. The paragraph outlines the architect's role in describing development policies, including design, coding, deployment, integration, testing, maintenance, and system operation. It also explains the impact of software architecture on project organization, schedules, and configuration management. The utility programs, prototypes, and frameworks that influence software architecture design are also mentioned. The paragraph concludes by detailing the various roles of software architecture in system development, including communication, decision-making, overall structure determination, development project organization, and quality factor prediction.
🌐 Types of Software Architecture
This paragraph categorizes software architecture into four groups: dataflow, call return, data centered, and event system. It describes the characteristics and examples of each group, such as batch sequential processing and filter types for dataflow, and layers, main programs, and object-oriented types for call return. The paragraph discusses the pros and cons of pipe and filter types, layer types, main program and subroutine, and object-oriented types. It also touches on data centered groups, which handle centralized data repositories and data-consuming clients, and event system groups, which focus on changeability by reducing process dependencies. The paragraph provides a comprehensive overview of the different types of software architecture and their applications in achieving reuse, changeability, scalability, and concurrency.
🔩 Task Structure Design in Software Architecture
The fourth paragraph focuses on the task structure design within the software architecture, particularly in the context of an automobile cruise control system. It outlines the process of task identification, which includes identifying task candidates, allocating remaining processes, and integrating tasks. The paragraph explains the steps involved in each of these procedures, such as identifying asynchronous, periodic, and control patterns as task candidates. It also discusses the allocation of processes to task candidates based on criteria like sequential and control cohesion. The integration of tasks is also covered, with examples of how tasks are selected for integration based on functional cohesion. The paragraph concludes with a description of how the completed task structure is represented, including the flow of information between tasks and the composition of processes within each task.
🏗️ Logical Software Architecture and Client-Server Design
This paragraph delves into the logical software architecture determination activities, emphasizing the importance of minimizing change scope at the logical architecture level for better scalability and maintenance. It discusses vertical layering and horizontal decomposition as methods to reduce inter-layer coupling and increase functional cohesion. The paragraph also covers subsystem decomposition, explaining how client and server architectures can be realized on the same or different hardware platforms. It touches on technology environment definition, highlighting the need for developers to choose the most appropriate implementation technologies. The discussion includes the design of subsystem interfaces, especially in the context of a client-server architecture, and the importance of user interface design in system development. The paragraph concludes with a summary of eight ways to design a great user interface, emphasizing the need for a user-centric design perspective.
🎨 User Interface Design Principles
The final paragraph emphasizes the critical role of user interface (UI) design in system development. It points out that a significant portion of maintenance costs is related to the UI and highlights the potential losses due to poor usability, as estimated by various research studies. The paragraph outlines eight strategies for designing an effective user interface, advocating for a user-centric approach from the outset of system development. It underscores the importance of usability in generating business profits and improving user satisfaction, suggesting that a well-designed UI can significantly impact the success of a system.
Mindmap
Keywords
💡Software Architecture
💡Meta Architecture
💡Views
💡Component
💡Connector
💡Guidelines and Policies
💡Development Process
💡Dataflow
💡Call Return
💡Event System
💡High-Level Design
Highlights
The importance of meta architecture in providing general guidelines and decision trees for software design.
The role of the architect in utilizing templates for architectural documents within meta architecture.
Four key views in software architecture: module view, component and connector view, allocation view, and code view.
The necessity to derive context diagrams, component specifications, and interface specifications from architectural design.
Guidelines for selecting and defining views in software architecture based on various criteria and notes.
The impact of developers' competence, domain understanding, and previous project experience on the selection of architectural views.
The significance of quality attributes such as system functionality, availability, changeability, security, and performance in architecture design.
The challenges of representing views in UML 1.x due to technology-dependent design patterns.
UML 2.0's adoption of architecture definitions from Carnegie Mellon University to ease the description of software architecture.
The role of guidelines and policies in determining software architecture and conducting projects.
The multifaceted roles of software architecture in system development, including communication, decision-making, and system structure determination.
The influence of software architecture on the organization of development projects and quality factor determination.
How software architecture informs the curriculum and training content for system developers.
The process of managing changes to software through architectural descriptions and workflows.
Classification of software architecture types into dataflow, call return, data centered, and event system groups.
Advantages and disadvantages of pipe and filter types in dataflow architecture for system design.
Characteristics and benefits of layer types, main program and subroutine, and object-oriented types in call return group architectures.
The functionality of data centered group types like repository and blackboard in managing centralized data interactions.
The purpose of event system group types in achieving changeability by decoupling process dependencies.
The structured approach to high-level design involving modular software architecture development based on structural analysis and software architecture.
The two main actions in high-level design: decomposing the system into clear functionality modules and describing their integration and interaction.
The development of module interfaces in high-level design to define externally usable components for embedded systems.
The methodology of task structure design, including task identification, remaining process allocation, and task integration.
The importance of subsystem interface design in client-server architectures for effective communication between subsystems.
The significance of user interface design in system development, emphasizing the need for usability and user-centered design.
Eight ways to design a great user interface, highlighting the importance of a user perspective in interface design.
Transcripts
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
[Music]
the components of a software
architecture that is at the heart of the
software high-level design are meta
architecture software architecture
guidelines and policies let's take a
closer look at these three components
first meta architecture is a general
guideline for designing and architecture
it is a set of general decision trees
and design patterns for defining the
architecture of the software the style
the role of the architect and consisting
of templates for the architecture
documents next the software architecture
consists of four views module view
component and connector view allocation
view and code view also as a result of
the architectural design the context
diagram components specification and
interface specification must be derived
let's take a look at what you should
know when defining views there are many
different ways to define views for each
person description method diagram shape
box line etc are all different therefore
we only need to consider the selection
criteria and notes when describing the
view also there are usually three views
such as module view component and
connect review or allocation view
in addition code view can also be added
here when you define each of you you
must describe at least of you and how
many views are appropriate depends on
factors such as the competence of the
developers the understanding of the
domain the experience of the previous
project and the major issues it should
be the basis for judging quality
attributes such as systems big function
availability change ability security and
performance and the functionality of the
key module should be described how they
are related to the inside-outside also
you need to be able to figure out the
size and scope of your system finally
you should be able to describe the
rationale for building the architecture
description in previous versions of UML
1 dot X these views were difficult to
represent this is due to the design of
excessively technology dependent
patterns or components mainly created at
the deployment level when building UML
2.0 oMG has much adopted the
architecture definition from the
Carnegie Mellon University sei so as to
make it easier to describe these areas
next guidelines and policies are that
they are for determining the software
architecture and then conduct the
project based on the defined
architecture architect should describe
and make a decision on a comprehensive
set of development policies with
guidelines and policies for design
coding deployment integration testing
tools maintenance system expansion and
system operation these software
architectures relate to the various
components of system development project
organization project schedules and
configuration management plans are based
on software architecture the utility
programs prototypes and frameworks
affect software architecture design now
I will explain the role the software
architecture and its relationship to the
development process the software
architecture has the following roles and
system development first it becomes a
means of communication between relevant
stakeholders second it is a tool to make
decisions early in the development
project in particular as it determines
the quality factor it has an overall
impact on the project organization third
it determines the overall structure of
the system fourth it affects to
determine the organization of the
development project fifth it determines
the quality factor that the system
should have this allows the architecture
to predict what quality the system will
need and what quality will have through
the architecture sixth you can decide
what curriculum and training content
delivered to system developers through
the architecture finally it informs the
process or workflow how to manage
changes to the software let me explain
how software a architect plays a role in
the overall development process
functional and non-functional
requirements act as inputs to design the
software architecture once the software
architecture is determined you can
design your software using design
patterns and design guidelines once the
software architecture is determined
coding standards and guidelines can be
provided when writing
and the software architecture provides
guidelines for deploying software on the
system with such repetition this allows
you to build a structured stable
software architecture now let's look at
the types of software architecture we
will group each type into dataflow group
call return group data centered group an
event system group first is the data
flow group types included in this group
are types that can achieve reuse and
change ability this includes the batch
sequential processing type and filter
types for the batch sequential
processing types the components are
independent programs each step must end
before starting the next step and data
in each batch step has the entirely
moving characteristic between steps
let's look at the pros and cons of pipe
and filter types first the pros are easy
to understand the data flow control
process having specialized analysis
functions enable filter reuse achieve
concurrency and easy to maintain and
expand in contrast there are cons and
that it is not suitable for highly
interactive systems difficult to
maintain consistency between many
relevant data increases complexity and
can cause the performance issues next is
the call return group types included in
this group can achieve change ability
and scalability this includes layers
main programs and subroutines and
object-oriented types first the pros and
cons of layer types pros include
providing a design based on abstraction
levels improving scalability providing
high reusability and portability the
cons are that it is difficult to apply
to all systems and in some cases it can
be very difficult to find the right
level of abstraction
the following are the main program and
subroutine it has excellent reusability
and ease of system evolution however
components have the cons that they have
to give up control over the calculations
that the system processes and require
careful handling of the data
next is the pros and cons of
object-oriented types implementation is
easy to change and there is an pros that
design of problem area analysis is
intuitive but you have to know the
identifier zuv other objects and you
have to modify other objects when you
change the object identifier next is
data centered group the types contained
in this group are used when data is
concentrated in the system and multiple
clients interact with the system to
obtain the data the components are
centralized data repository and data
consuming client here are the storage
types and blackboard types the
repository is a passive data center a
type that check to see if a client needs
to fetch data a blackboard is an active
data center a type that notified changes
to relevant clients when data changes
next is the event system group the types
contained in this group are aimed at
achieving change ability by eliminating
the dependencies of various parts of the
process through independent processes or
objects this includes implicit call
types and explicit call types for the
implicit call type a component is a
module with an interface that provides a
collection of procedures and a set of
events also it connects to event
registration and procedure call as a
constraint the event provider does not
know which components are affected by
the event in case of the explicit call
type every time a system function is
changed the other module that imports
the module must also be changed in
addition reflection provides a mechanism
to change the system configuration or
behavior at any time of execution MVC
and PA see which allows the system to
respond flexibly to changes by sharing
responsibilities brokers provides
distributed transparency in a
distributed environment microkernel
types
divide the system into core parts and
change parts to accommodate frequently
changing requirements the purpose of
structured high-level design is to
develop a modular software architecture
based on specifications developed
through structural analysis and software
architecture two big actions must be
described first decompose the system
into modules that provide clear
functionality second describe how the
decomposed modules integrate and inter
work together in particular various
items must be organized to describe how
to integrate and inter work first it
develops a module interface that defines
the modules components that can be used
externally for a typical embedded system
using the C language functions that can
be called from other modules global
variables that can be assessed data
structures and macros make up the
modules interface it also determines the
usage criteria for various resources
such as error handling criteria threads
timers interrupts and alarms shared
within the overall modular structure and
technology standards such as the data
types that are shared on the development
platform are determined although various
techniques can be used to describe such
a module structure the structural
high-level design methodology is divided
into a task structure design which shows
dynamic aspects and a module structure
design which describes static aspects
task structure design step identify the
tasks that can be performed
simultaneously on the system based on
the output of analysis and describe the
dynamic aspects of the system module
structure design phase identifies
modules that are development units based
on output of analysis and task structure
and specify technical standards and
module interfaces
we will continue to explain the process
of high-level design based on the
structural analysis results of the
automobile cruise control system
presented on the screen
the task structure design shows all the
processes identified in automobile
cruise control as you can see in the
figure the figure is an example for
describing the task identification
process not the regular output created
in the development methodology process
this figure shows all the processes
identified so far showing that the
patterns are asynchronous periodic and
control let's look at the procedures for
a task structure design in a structural
design methodology the task structure is
designed according to the three steps
task identification procedure proposed
by Hassan Gama the task identification
procedure consists of three steps task
candidate identification is the
identification of processes that require
their own execution remaining process
allocation refers to allocating
processes that have not been assigned
their own tasks to task candidates and
tasks integration means integrating
tasks candidates within a time
constraint let's take a closer look at
each of these three steps of task
identification procedures first let's
look at identifying candidate tasks
according to the technique described
processes according to the asynchronous
periodic and control patterns become
task candidates the table lists the
identified task candidates on the left
are tasks candidates processes in the
middle and criteria for selecting them
on the right next is the allocation of
the remaining process the figure shows
that the process identified as remaining
processes in the automobile cruise
control example are distributed the
figure shows have the four tasks that
were not identified in the previous step
are assigned to some task candidates the
table lists the processes that have been
allocated and their criteria
tasks candidates include task 3 and task
4 and the processes allocated to them
have processes determine the speed and
there are processes related to the
preemption of the expected speed in
addition each process is mapped to task
candidate according to the degree of
sequential cohesion and control cohesion
next is the merging tasks automobile
cruise control example shows the cases
where task integration is possible as
per the table the table shows which
tasks have been integrated how they were
selected and the criteria definition for
example you can see that task 1 and task
to integrate due to functional cohesion
that is mutually exclusive execution
characteristics we will complete the
task structure of the automobile cruise
control system through task candidate
identification remaining process
allocation and task integration the
completed task structure is the same as
the screen in figure the diamond
indicates the identified task and the
line between the tasks indicates the
flow of information required between the
tasks each of these tasks consists of
processes presented in the screen in the
table you can see how each task is
mapped to each process and how they are
composed or connected each other now
let's look at high-level design method
by object oriented methodology in
general the object oriented development
methodology does not have a clear
boundary between object and behavior
analysis an object and behavior design
therefore the object and behavior
analysis models are refined to a more
sophisticated design model that matched
to the selected software description and
detailed implementation description is
established in this case the object and
behavior analysis model evolves into a
design model during the high-level
design phase developers perform
activities to describe the system in
terms of logical software architecture
and
the implementation strategies to
implement the system in terms of
client-server architecture first let's
look at logical software architecture
determination activities this activity
refers to the activities of layering and
decomposing the system to have a low
degree of coupling the main goal of this
software architecture determination is
to minimize the scope of change at the
logical architecture level not at the
unit class level as minimizing the scope
of change is closely related to software
scalability and maintenance the coupling
issue must be solved well in terms of
logical architecture in principle the
lower the degree of coupling the easier
the software is to expand and maintain
and in a software architecture with a
high degree of coupling a change in a
particular part will impact changes in
other parts that depend on it
determining the logical software
architecture to decompose these systems
is executed regardless of the
implementation strategy the following
table summarizes the activities briefly
for determining logical software
architecture I will continue to explain
vertical layering and horizontal
decomposition vertical layering is the
packaging of boundary classes control
classes and object classes shown in
class diagrams and placing them in a
vertical hierarchy I will explain them
through the picture the picture shows a
layered architecture that is packaged
vertically into three groups for the
depositor service system boundary
classes are packaged as GUI groups from
class diagrams created in behavior and
analysis activities control classes are
also packaged into workflow groups you
can see object classes are packaged as
domain groups in this example the
dependency represented by the dotted
arrow indicates that the higher layer
uses the lower layer service next
horizontal decomposition can be
performed to reduce inter layer coupling
when certain layers are complex in
addition the classes in the same layer
can be performed by the developers into
with criteria or a systematic analysis
method
let me explain with the example the
figure is a architecture in which the
domain group hierarchy previously
discussed is decomposed horizontally
again classes with similar
functionalities are grouped together in
other words horizontal decomposition was
performed to increase the functional
cohesion and have the grounds that
customer management and account
management aspects can be functionally
separated this time I will explain
subsystem decomposition like layering
and decomposition client and server
architectures are also logical concepts
in other words from a software
development perspective a client-server
architecture can be realized on the same
hardware platform or on different
hardware platforms the example on the
screen shows the software development
architecture for fat clients and thin
clients assuming the package of vertical
layering architecture as discussed above
are deployed on different hardware
platforms looking at the first fat
client each client consists of GUI group
workflow group and domain group while
thin clients consists of server workflow
group domain group client and GUI group
the figure on the screen is a subsystem
architecture diagram decomposed into
subsystems according to the previous
activities the left side is the
subsystem architecture of fat client and
the right side is the subsystem
architecture of thin client next the
technology environment definition will
determine the technology environments
for the client and server subsystems and
may include technology selection for any
middleware that connects the client and
server
in other words when decomposing a
subsystem into a client-server
architecture developers must choose the
most appropriate implementation
technologies to do this they will
determine the technologies for object
oriented programming language operating
system middleware user interface
development tools and database
management system currently technology
environments that support an
object-oriented paradigm are very broad
and constantly evolving into or friends
of rising new technologies as
technologies to implement
object-oriented methodologies are too
broad the high-level design a specific
development language specific middleware
specific user interface implementation
techniques or a specific database
management system is not willing to be
confined with specific one just like all
object-oriented methodologies therefore
after selecting the technology
environment the design phase should be
dependent on the developers expert
knowledge and specific technologies the
figure on the screen is a client-server
architecture from a software deployment
perspective a client or server has a
separate hardware platform and chose
typical technologies required to
implement software with a client-server
architecture this picture shows a
web-based software architecture deployed
on three-tier hardware platforms it
demonstrate the core skills required to
build a web-based system a web based
system is an extension of a
client-server architecture with a
website where the business logic can
place on the server side or client side
next let's look at subsystem interface
design once the subsystem decomposition
and the technical environment are
established the interface to the derived
subsystems starts to be design first
this example assumes the following
scenarios assume that you have assigned
the workflow group package and the
domain group package to the application
server as shown in the thin client
architecture and the diagram of first
technology environment it is also
assumed that the interface technology
between thin client and application
server
is remote method invocation RMI provided
by java then this will require a
subsystem interface design to use remote
method calls between classes belonging
to GUI group and classes belonging to
workflow group the figure on the screen
defines the interfaces that classes
belonging to workflow group provide to
the classes belonging to the client
subsystem the user interface is defined
as the interface between the person and
the system or the information channel
between the user and each system
therefore to make the system more easier
to use user interface design means to
identify the problem of information
exchange between user and system then
systematically designed to resolve
implement and test them especially in
modern times in an environment in which
a computer directly or indirectly
occupies a large part of our lives the
interface between the computer and human
being is becoming an important issue
than anything else during development of
the system there is a statistics that
80% of the overall maintenance costs are
related to the UI in addition jakob
nielsen author of usability engineering
predicts that if a better navigation
system is not built and a rigid internal
design standard is not enforced the cost
of bad usability of internet usage will
be exponentially increased in worldwide
zona research estimates that ecommerce
companies are losing more than 58
million dollars a month from frustrated
customers due to web pages
therefore the UI process must be applied
from the beginning of system development
and the ideas that shortening the
development cycle meeting the user
requirements increasing the usability
and helps to generate a bigger business
profits are spreading the following is a
summary of eight ways to design a great
user interface it is necessary for the
design of the user perspective so please
refer to them
[Music]
[Music]
you
[Music]
Посмотреть больше похожих видео
Monolithic Architecture In Hindi ( Complete Explanation )
Top 5 Most Used Architecture Patterns
Lesson189 - Architectural Quantum Tradeoffs
SARCH20 V2C 2021 04 15 Module 1 deel 1 van 3
Introduction To Computer System | Beginners Complete Introduction To Computer System
Lecture 1 - Introduction to architecture by Michel Chaudron - Part 1
5.0 / 5 (0 votes)