0% found this document useful (0 votes)
12 views

Week 11 Lecture # 1

The document discusses key aspects of software architecture, including breaking a system into modular components, data management, communication between components, and considerations for concurrency, deployment, scalability, and security. It describes how architectural descriptions involve different viewpoints to address the concerns of various stakeholders and how architectural genres dictate specific approaches depending on the system type.

Uploaded by

hs5849377
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views

Week 11 Lecture # 1

The document discusses key aspects of software architecture, including breaking a system into modular components, data management, communication between components, and considerations for concurrency, deployment, scalability, and security. It describes how architectural descriptions involve different viewpoints to address the concerns of various stakeholders and how architectural genres dictate specific approaches depending on the system type.

Uploaded by

hs5849377
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 53

Software Architecture and

Design , Implementation
Lecture # 1,2
Software Architecture

Software architecture refers to the high-level


design and organization of a software system
components.

2
 It involves making fundamental structural
choices and design decisions to ensure that a
software system has the necessary qualities such
as performance, maintainability, scalability, and
security. Software architecture is a crucial aspect
of software development, as it provides a
blueprint for constructing, deploying, and
maintaining a software solution.

3
Key Aspects of Software Architecture
Includes
 Components and Modules: Breaking down the
system into modular components or modules,
each responsible for specific functionalities.
These components communicate with each other
through well-defined interfaces.

4
 Data Management: Defining how data is stored,
accessed, and managed within the system. This
includes database design, data flow, and data
processing mechanisms.

5
 Communication: Determining how different
components or modules in the system
communicate with each other. This involves
choosing appropriate communication protocols,
data formats, and messaging patterns.

6
 Concurrency and Distribution: Handling multiple
tasks or processes concurrently and managing
the distribution of components across different
machines or nodes in a network.

7
 Deployment: Planning how the software will be
deployed in various environments, including
considerations for hardware, network
infrastructure, and system configurations.

8
 Scalability: Designing the system to handle
increased loads gracefully. This involves
considering factors such as load balancing,
horizontal scaling, and efficient resource
utilization.

9
 Maintainability and Extensibility: Ensuring that the
software can be easily maintained, updated, and
extended over time. This includes choosing
appropriate coding practices, design patterns,
and documentation.

10
 Security: Incorporating measures to protect the
software system from unauthorized access, data
breaches, and other security threats.

11
 Performance: Optimizing the system to meet
performance requirements, such as response
time, throughput, and resource utilization.

12
 Bass and his colleagues identify three key
reasons that software architecture is important:

13
 Representations of software architecture are an
enabler for communication between all parties
(stakeholders) interested in the development of a
computer-based system.

14
 The architecture highlights early design decisions
that will have a profound impact on all software
engineering work that follows and, as important,
on the ultimate success of the system as an
operational entity.

15
 Architecture “constitutes a relatively small,
intellectually graspable model of how the system
is structured and how its components work
together”

16
Architectural Descriptions

 Each of us has a mental image of what the word


architecture means. In reality, however, it means
different things to different people. The
implication is that different stakeholders will see
an architecture from different viewpoints that are
driven by different sets of concerns. This implies
that an architectural description is actually a set
of work products that reflect different views of the
system.

17
 For example, the architect of a major office
building must work with a variety of different
stakeholders. The primary concern of the owner
of the building (one stakeholder) is to ensure that
it is aesthetically pleasing and that it provides
sufficient office space and infrastructure to
ensure its profitability.

18
 Therefore, the architect must develop a
description using views of the building that
address the owner’s concerns. The viewpoints
used are a three-dimensional drawings of the
building (to illustrate the aesthetic view) and a set
of two-dimensional floor plans to address this
stakeholder’s concern for office space and
infrastructure.

19
 But the office building has many other
stakeholders, including the structural steel
fabricator who will provide steel for the building
skeleton. The structural steel fabricator needs
detailed architectural information about the
structural steel that will support the building,
including types of I-beams, their dimensions,
connectivity, materials, and many other details.

20
 These concerns are addressed by different work
products that represent different views of the
architecture. Specialized drawings (another
viewpoint) of the structural steel skeleton of the
building focus on only one of many of the
fabricator’s concerns.

21
Architectural Genres

 Although the underlying principles of architectural


design apply to all types of architecture, the
architectural genre will often dictate the specific
architectural approach to the structure that must
be built.

22
 Within each category, you encounter a number of
subcategories. For example, within the genre of
buildings, you would encounter the following
general styles: houses, condos, apartment
buildings, office buildings, industrial building,
warehouses, and so on.

23
 Grady Booch in his evolving Handbook of
Software Architecture
 Artificial intelligence —Systems that simulate or
augment human cognition, locomotion, or other
organic processes.
 •Commercial and nonprofit —Systems that are
fundamental to the operation of a business
enterprise.

24
 Communications—Systems that provide the
infrastructure for transferring and managing data,
for connecting users of that data, or for
presenting data at the edge of an infrastructure.
 Content authoring —Systems that are used to
create or manipulate textual or multimedia
artifacts.

25
 Devices Systems that interact with the physical
world to provide some point service for an
individual.
 Entertainment and sports Systems that
manage public events or that provide a large
group entertainment experience.

26
 Financial Systems that provide the infrastructure
for transferring and managing money and other
securities.
 • Games Systems that provide an entertainment
experience for individuals or groups.

27
 Government Systems that support the conduct
and operations of a local, state, federal, global, or
other political entity.
 Industrial Systems that simulate or control
physical processes.
 Legal Systems that support the legal industry.

28
 Medical Systems that diagnose or heal or that
contribute to medical research.
 Military Systems for consultation,
communications, command, control, and
intelligence (C4I) as well as offensive and
defensive weapons.

29
 Operating systems Systems that sit just above
hardware to provide basic software services.
 Platforms Systems that sit just above operating
systems to provide advanced services.

30
 From the standpoint of architectural design, each
genre represents a unique challenge. As an
example, consider the software architecture for a
game system. Game systems, sometimes called
immersive interactive applications, require the
computation of intensive algorithms,sophisticated
computer graphics, streaming multimedia data
sources, real-time interactivity via conventional
and unconventional inputs, and a variety of other
specialized concerns.
31
ARCHITECTURAL DESIGN

 As architectural design begins, the software to be


developed must be put into context—that is, the
design should define the external entities (other
systems, devices, people) that the software
interacts with and the nature of the interaction.

32
 This information can generally be acquired from
the requirements model and all other information
gathered during requirements engineering. Once
context is modeled and all external software
interfaces have been described, you can identify
a set of architectural archetypes.

33
 An archetype is an abstraction (similar to a class)
that represents one element of system behavior.
The set of archetypes provides a collection of
abstractions that must be modeled architecturally
if the system is to be constructed, but the
archetypes themselves do not provide enough
implementation detail.

34
 Therefore, the designer specifies the structure of
the system by defining and refining software
components that implement each archetype. This
process continues iteratively until a complete
architectural structure has been derived. In the
sections that follow we examine each of these
architectural design tasks in a bit more detail.

35
Representing the System in Context

 At the architectural design level, a software


architect uses an architectural context diagram
(ACD) to model the manner in which software
interacts with entities external to its boundaries.

36
37
 Superordinate systems those systems that use
the target system as part of some higher-level
processing scheme.

 Subordinate systems those systems that are


used by the target system and provide data or
processing that are necessary to complete target
system functionality.

38
 Peer-level systems those systems that interact
on a peer-to-peer basis (i.e., information is either
produced or consumed by the peers and the
target system.

 Actors entities (people, devices) that interact


with the target system by producing or consuming
information that is necessary for requisite
processing.
39
 Each of these external entities communicates
with the target system through an interface (the
small shaded rectangles).

40
 To illustrate the use of the ACD, consider the
home security function of the SafeHome product.
The overall SafeHome product controller and the
Internet-based system are both superordinate to
the security function and are shown above.

41
42
 The surveillance function is a peer system and
uses (is used by) the home security function in
later versions of the product.
 The homeowner and control panels are actors
that are both producers and consumers of
information used/produced by the security
software.

43
 Finally, sensors are used by the security software
and are shown as subordinate to it.

 All data that flow into and out of the target system
must be identified at this stage

44
Defining Archetypes

 An archetype is a class or pattern that represents


a core abstraction that is critical to the design of
an architecture for the target system. In general,
a relatively small set of archetypes is required to
design even relatively complex systems.

45
 The target system architecture is composed of
these archetypes, which represent stable
elements of the architecture but may be
instantiated many different ways based on the
behavior of the system.

46
 Continuing the discussion of the SafeHome home
security function, you might define the following
archetypes:

47
 Node. Represents a cohesive collection of input
and output elements of the home security
function. For example a node might be comprised
of (1) various sensors and (2) a variety of alarm
(output) indicators.

48
 Detector. An abstraction that encompasses all
sensing equipment that feeds information into the
target system.

49
 Indicator. An abstraction that represents all
mechanisms (e.g., alarm siren, flashing lights,
bell) for indicating that an alarm condition is
occurring.

50
 Controller. An abstraction that depicts the
mechanism that allows the arming or disarming of
a node. If controllers reside on a network, they
have the ability to communicate with one another.

51
 Each of these archetypes is depicted using UML
notation as shown in Figure 9.7.
 Recall that the archetypes form the basis for the
architecture but are abstractions that must be
further refined as architectural design proceeds.
For example, Detector might be refined into a
class hierarchy of sensors.

52
53

You might also like