Introduction to Software

Design
• One of the most distinctive of human characteristics is the making of, and
the use of, tools.
• A second distinguishing characteristic of human beings that provides an
underpinning for any form of design activity is that of communication.
Translating a ‘design’ into a ‘product’.
• Communication also plays another, rather different, role in design
activities. This is to act as the vehicle by which experience and expertise
are transferred from ‘expert’ to ‘novice’, as well as shared amongst a
community of experts.
• Our perception of the importance of the roles that design may play in
producing these different artifacts will vary, although it may not always be
correct.
• Communication plays an important role for good design. However, an
equally important channel of communication is with the source of the
‘requirements’ specification that a designer is being asked to address.
• Software designer may need to acquire some degree of ‘domain
knowledge’ as a routine part of the input needed for undertaking any
particular design task.
• The static structure of the system, including any subprograms to be
used and their hierarchy.
• Any data objects to be used in the system.
• The algorithms to be used.
• The packaging of the system, in terms of how components are
grouped in compilation units.
• Interactions between components, including the form these should
take, and the nature of any causal links.
• These are all concerned with specifying the form of the design
product itself. But as was observed above, the overall design task may
also involve producing process oriented plans too.
• Software designers produce plans that specify how the final product
is to be assembled in terms of the items listed earlier.
• For designing software consists of designing a process; and so it
becomes necessary to model and describe its behaviour as well as its
structure, and also the functions that it will perform.
Design as a problem-solving process
• The purpose of design is simply to produce a solution to a problem.
• The problem will typically be summarized by means of some form of
requirements specification, and it is the designer’s task to provide a
description of how that requirement is to be met.
• Design methods and patterns can provide strategies that will help to
determine which choice may be most appropriate in a given situation.
• Representations can also help with the process of building models of the
intended system and with evaluating its behaviour.
• Abstraction enables the designer to concentrate effort on building a logical
model of a system, which is translated into a physical model at a relatively
late stage in the design process.
Design as a ‘wicked’ problem
• There is no definitive formulation of a wicked problem.
• Wicked problems have no stopping rule.
• Solutions to wicked problems are not true or false, but good or bad.
• There is no immediate and no ultimate test of a solution to a wicked
problem.
• Every solution to a wicked problem is a ‘one-shot operation’, because
there is no opportunity to learn by trial-and-error, every attempt
counts significantly.
• Wicked problems do not have an enumerable set of potential
solutions.
• Every wicked problem is essentially unique.
• Every wicked problem can be considered to be a symptom of another
problem.
Building models
• The difficulties involved in creating software-based systems have long
been recognized. While apparently related technology such as
hardware design and production has raced along gaining orders of
magnitude in performance, and similarly reducing price and size,
software development techniques seem to have inched along in a
series of relatively small steps.
• Brooks cites the following properties of software as major factors
affecting its development.
• Complexity
• Conformity
• Changeability
• Invisibility
• The use of abstract ‘mental models’ by the designer to simulate the
dynamic behaviour of the eventual system that will be derived from
the design.
• Expanding the detail of a model in a systematic manner by keeping all
elements of the design at the same level of detail as they are
developed. This then aids the task of simulation.
• The need to make any constraints affecting the design as explicit as
possible when handling an unfamiliar problem.
• Reuse of previous design plans.
• Making notes about future (detailed) intentions
Transferring design knowledge
Exceptional designers were observed to possess three significant
characteristics:
• Familiarity with the application domain
• Skill in communicating technical vision to other project members
• Identification with project performance
When we look at how successful designers work, there are other
factors to consider:
• to postpone a decision, if the information required is not yet available
at this design level;
or
• to process information that is readily to hand, and which can be used
for defining modules in anticipation of further developments in the
design.
opportunistic
• Software design method can be considered as providing a supportive
framework that consists of two major components:
• The representation part provides a set of descriptive forms that the designer
can use for building both black box and white box models of the problem and
their ideas for its solution, and for describing the structural features of the
solution to the eventual implementors.
• The process part is concerned with describing how the necessary
transformations between the representation forms are to be organized, as
well as with any elaboration of their detail that might be required.
A set of heuristics that can be used to provide guidelines for specific classes of
problem.
Design Qualities
• In order to achieve high standards of quality in products, one needs
to seek high standards of quality in the design process.
• Unfortunately, quality is a concept that can rarely be related to any
absolutes, and even for manufactured items ideas about quality
usually cannot be usefully measured on any absolute scale. The best
that we can usually do is to rank items on an ordinal scale.
• Since software is such an abstract product that the concept of quality
is equally difficult to define for software. Few quality attributes can be
quantified in any way, and those measures that we do possess are of
uneven value.
• We also encounter once again the dual nature of software in thinking
about how we can identify its quality. Software has both static and
dynamic attributes, and so any set of measures that we can develop
should seek to assess both of these, and should recognize the
potential for conflict between them.
Assessing design quality
“When you can measure what you are speaking about, and express it in
numbers, you know something about it, but when you cannot measure
it, when you cannot express it in numbers, your knowledge is of a
meagre and unsatisfactory kind.”
• Quality concepts
• Design attributes
• Counts
The ‘ilities’
• The ‘ilities’ form a group of quality factors that need to be considered
when making any attempt to assess design quality:
• Reliability: concerned with the dynamic characteristics of the eventual system
• Complete
• Consistent
• Robust
• Efficiency
• Maintainability
• Usability
Cognitive dimensions
• Premature commitment
• Hidden dependencies
• Secondary notation
• Viscosity
Quality attributes of the design product
• Simplicity
• Modularity
• Information-hiding
Assessing design quality
• well structured: consistent with chosen properties such as information-
hiding
• simple: to the extent of being ‘as simple as possible, but no simpler’
• efficient: providing functions that can be computed using the available
resources
• adequate: meeting the stated requirements
• practical: module interfaces should provide the required facilities, neither
more nor less
• implementable: using current and available software and hardware
technology
• standardized: using well-defined and familiar notation for any
documentation
Assessing the design process
• There are three widely adopted ways of providing these inputs to the
design process
• Technical reviews
• Management reviews
• Prototyping
Representing abstract ideas
• A representation is used to provide a particular abstraction of the
characteristics of a system, and is typically needed for such purposes
as:
• capturing the designer’s ideas for a solution
• explaining the designer’s ideas to others
• checking for consistency and completeness in a solution
Design viewpoints for software
• Software is not only an abstraction, it is also the description of a
process.
• In order to describe system-oriented properties, the designer usually
needs forms that describe the dynamic behaviour of the system.
• For more detailed solution-oriented design needs, which are often
concerned with describing ‘constructional’ issues such as packaging,
procedure hierarchy, and data organization, the chosen forms will
generally focus on static design attributes.
• constructional forms, in which the viewpoint is concerned with
essentially static aspects of the system
• behavioural forms, a set of viewpoints that seek to describe the
causal links between events and system responses during execution
• functional forms, viewpoints that seek to describe what the system
does in terms of its tasks
• data-modelling forms, concerned with the data objects used within
the system, and the relationships between these
• Constructional forms
• data specification
• threads of execution
• packaging constructs
• Behavioural forms
• sequencing aspects can be described fairly well
• fixed-interval descriptions are also fairly tractable, although their use is
mainly restricted to particular features of real-time systems
• constraint
• Functional forms
• One of the hardest tasks for the designer is to describe exactly what it is that
a system does. This is essentially a problem-driven issue and hence is difficult
to describe in any general form.
• Data-modelling forms
• While the description of data structures need not be a very significant issue in
architectural design terms, it is often a critical aspect of a detailed design.
Again, there are a number of relationships that may need to be captured.
• These include: type and sequence
Forms of notation
• Text
• Diagrams
• Mathematical expressions
The DFD viewpoint
The Entity–Relationship Diagram
The Jackson Structure Diagram
• It is basically concerned with describing sequential structure, in terms
of the three ‘classical’ structuring forms:
• Sequence
• Selection
• Iteration
• A white box notation can be viewed as one that is largely concerned
with describing some aspect of the detailed realization of a design
element. It tends to be associated with the constructional and
functional viewpoints.
The Structure Chart
Class and object diagrams
Sequence Diagrams
• We need to consider design processes and strategies in rather more
detail. This is because each of the procedural steps of any design
method, regardless of the strategy employed, can usually be classified
as being one of those two forms.
• transformation step: the designer modifies the structuring for their model of
the ‘system’ in some way.
• elaboration step: does not usually involve any change of viewpoint, but is
more concerned with restructuring or reorganizing the design model within
the current viewpoint.
D-Matrix
• The D-Matrix (short for ‘Design Matrix’) notation, is intended to
provide an abstract description of the state of the ‘design model’ at
any point in its evolution.
• The D-Matrix is totally independent of any specific methods; indeed it
can be used to describe not only method processes but also to record
quite opportunistic sequences of design activities.
• The basic assumption for this notation is that any design (or
requirements) specification can be composed from the specifications
for a set of ‘design elements’ (or ‘requirements elements’), where
each element can itself be described in terms of a set of attributes
that describe the properties associated with the four major
viewpoints.
• function
• behaviour
• data model
• construction
• Example:

where the column represents the attributes that describe the

properties of the ith design element.
Top-down and Bottom-up design approach
Stepwise Refinement
• The designer of software has been faced with the need to address
complex problems using a medium that is enormously powerful and
flexible, and yet is also ill-defined in terms of the way in which its
detailed form is organized.
• Stepwise refinement is about the question of how such a mapping
could be created through a process of gradual decomposition of the
problem into smaller problems.
• Five lessons about this process:
• Program construction consists of a sequence of refinement steps, in each of which a
task is divided into a number of subtasks, accompanied where appropriate by a
further refinement of any data structures involved.
• The degree of modularity resulting from this process will determine the ease with
which a program can be adapted to meet changes in the requirement or context.
• The need for a notation that relates to the problem in hand.
• Each refinement embodies a set of design decisions that are based upon specific
criteria. This lesson reflects the recognition that designing is not an analytical
process, and that there is a need to assess (and re-assess) the influences of a range
of factors at each design step.
• The last lesson observes the difficulty of describing even such a relatively small
problem without needing to create a ‘long story’ for the purpose.
Strengths and weaknesses of the stepwise
strategy
• Undoubtedly one of the strengths is the relative simplicity of the
design process, although even that can be partially illusory.
• A second strength is the emphasis upon the stepwise nature of the
process.
• Weaknesses include the instability that can arise from making key
decisions at early stages.
• The lack of a stopping rule which does not render the process invalid
in any way.
• The problem of duplication of lower-level units.
Structured Systems Analysis and Structured
Design
• The SSA/SD design process essentially make use of a refinement of
the top-down strategy for design, with the choices that are usually
involved in the functional decomposition process being moderated
and constrained by considerations of information flow and, to a lesser
degree, of data structure.
Representation forms for SSA/SD
• Representations for Structured Systems Analysis
• The functional viewpoint provided through the use of DFDs can be augmented by
means of more detailed descriptions in the form of ‘process specifications’, or ‘P-
Specs’.
• A P-Spec is a textual description of the primitive process that is represented by a
bubble in a DFD, and so can be regarded as a subsidiary functional viewpoint. A
typical P-Spec will summarize the process in terms of its title, a description of the
input/output data flow relating to the process, and the procedural tasks that it
performs, couched in terms of the basic concepts of sequence, selection and
iteration.
• A data dictionary can also be used to record the information content of data flows.
This typically includes descriptions of all of the data forms that are mentioned in the
DFDs, P-Specs and any other forms of description that might be used.
• Data dictionary
The SSA/SD process
Steps 1 and 2: Structured Systems Analysis
• Structured Systems Analysis is essentially problem-driven in nature,
while Structured Design is concerned with the form of the solution.
• For that reason, each process makes use of those diagrammatical
forms that best support its particular purpose and provide for the
necessary levels of abstraction.
• This ‘single-bubble’ description is termed the ‘context diagram’, and it
is basically the ‘level zero’ diagram that encapsulates the whole
system with a single bubble; the only data flows described in it are
those that are external to the system.
• In producing the DFDs that form a major output from this step, the
analyst is encouraged to use them for two purposes:
• drawing physical DFDs to describe the initial system model in terms of
relatively concrete items.
• constructing logical DFDs, which use more abstract terms to describe the
operations and data flow.
• There are many aspects of a problem that cannot be captured easily
by using the DFD as the sole basis for the designer’s model. Among
other things, DFDs are concerned only with describing the flow of
information, and not with its form or its persistence.
• Other information about the problem may also need to be captured if
the designer is to produce a complete model, such as
• frequency of information flow
• volume of data flow
• size of messages
• lifetime of an item of information
Step 3: Transaction Analysis
• A transaction is usually considered to have five basic components:
• the event in the system’s environment that causes the transaction to occur;
• the stimulus that is applied to the system to inform it about the event;
• the activity that is performed by the system as a result of the stimulus;
• the response that this generates in terms of output from the system;
• the effect that this has upon the environment.
Transform Analysis
• It is in this step that the designer takes the non-hierarchical model
constructed to describe the problem, modelled around the flow of
data between operations, and transforms this to create a description
of the structure of a computer program.
• The first action of the designer is to identify the operation or ‘bubble’
that acts as the central transform in the DFD. The central transform is
the bubble that lies at the centre of input and output data flow –
where these are considered to have their most abstract form.
• A feature of this process that sometimes gives conceptual difficulty is
that the flow arrows on the arcs seem to change direction when this
transformation is made. This is because the arc in a DFD depicts data
flow, while that in a Structure Chart depicts control flow.
Jackson Structured Programming
• JSP is one of the two design methods described in this book that have
emerged from ideas and experiences of Michael Jackson.
• It has limited and well-defined applications, which make it possible to
describe it more concisely yet fully than most other design methods.
• Ever since its development in the early 1970s it has been widely used, and
therefore has a historical claim to be discussed in depth.
• It is an excellent example of the use of a compositional design strategy.
• It is well documented and widely used.
• However, some of the attributes that make JSP so valuable for
developing ideas about design also have the potential to mislead.
Because of its limited domain of application, JSP provides more
prescriptive forms of design transformation than almost any other
systematic design method, and this makes it possible to incorporate a
greater degree of verification than is generally practicable with other
methods.
• JSP is essentially a program design method. It is concerned with the design
of systems that
• are realizable as a single sequential process;
• have well-defined input and output data streams.

JSP is therefore particularly well-suited to developing systems that employ a

pipe-and-filter architectural style.
Because JSP is concerned with program design, it places a strong emphasis
on the development of algorithms, and the detailed forms for these are
usually better described through the use of text. So JSP also makes use of
pseudocode forms for the later stages of design, with these being derived
from the diagrammatical forms as a part of the design transformation
process.
The JSP process
1. Draw a Structure Diagram that describes each of the input and
output data streams.
2. Merge these to form the program Structure Diagram.
3. List the operations that need to be performed by the program, and
allocate each operation to an element in the program Structure
Diagram.
4. Convert the program to text without specific conditions for any of
the decision points.
5. Add the conditions used for each iteration and selection operation.
JSP representation forms
Step 1: Draw the input/output Structure
Diagrams
Step 2: Create the program Structure Diagram
Step 3: List the operations and allocate to
program elements
For the filling-station system, the operations involved are the following:
Outputs
(1) write pump identity
(2) write volume of fuel
(3) write cost to customer
Inputs
(4) obtain pump identity
(5) obtain volume of fuel
(6) obtain type of fuel
(7) multiply type price per unit by volume dispensed
Steps 4 and 5: Convert program to text and
add conditions
Object-Oriented Design
• The object-oriented paradigm considers:
• abstraction
• encapsulation
• modularity
• Hierarchy
• Reusability
How large should an object be?
• An empirical study by El Emam et al. (2002) has examined the theory
of ‘optimal size’ for objects. This theory, arising from a number of
sources, suggests that there is a U-shaped curve that relates the
number (or density) of defects likely to occur in an object to its size,
and hence deduces that the ‘optimal’ size for an object will be at the
base of the ‘U’.
• On this basis, objects that are too large or too small are likely to be
more error prone and, for a given implementation form, there will be
a size of object that is ‘just right’. However, their findings do not
support this hypothesis, and show that there is a simple continuous
relation between the size of a class and the number of faults it is likely
to contain.
The case for reuse
The choice of HOOD
• HOOD recognizes the existence of both ‘passive’ and ‘active’ objects
in a system. A passive object essentially provides a service, in that it
provides a set of operations and associated abstract data types. The
operations of a passive object can be activated only when control is
passed to them directly, as occurs during the invocation (calling) of a
method.
• An active object can provide a parallel thread of execution that can
respond to synchronous and asynchronous ‘events’ (or timeouts)
needed for handling real-time features. Active objects may interact
with both passive and active objects, but passive objects may make
use only of other passive objects, and so cannot be used to activate
active objects.
Software Architecture
The general notion of architecture:
• Architecture is an abstract model
• Architecture is a structural model
• Architecture is a model with a certain engineering purpose
Architecture is an abstract representation, or model, of a complicated
system in terms of its structure that consists of a collection of
components together with some relations among them to achieve
certain engineering purposes and to manifest a certain set of
properties of interest on the system. The details of the components
and their relationships are hidden and replaced with abstract entities
The structure of WWW client-server pair
Prescriptive models
Software Architecture = {Elements, Form, Rationale}
• Data elements The data elements are those that contain the information that is used and
transformed
• Processing elements They are those components that supply the transformation on the data
elements
• Connecting elements They are the ‘glue’ that holds the different pieces of the architecture
together. For example, procedure calls, accesses to shared data, and messages are examples of
connecting elements that serve to ‘glue’ architectural elements together.
The architectural form consists of weighted properties and
relationships:
• Relationships Relationships are used to constrain the ‘placement’ of
architectural elements – that is, they constrain how the different
elements may interact and how they are organised with respect to
each other in the architecture.
• Properties Properties are used to constrain the choice of architectural
elements – that is, the properties are used to define constraints on
the elements to the degree desired by the architecture.
• Weight Properties and relationships together define the minimum
desired constraints on the software architecture.
Descriptive models
• approach is the descriptive point of view, which considers
architecture as a description of the high level structure in terms of
architectural elements and the interactions between them.

‘abstractly, software architecture involves the description of elements from

which systems are built, interactions among those elements, patterns that
guide their composition, and constraints on these patterns’.
• Components: A component is a unit of software that performs some
function at run-time.
• Connectors: A connector is a mechanism that mediates
communication, coordination, or cooperation among components.
Connectors describe the interactions among these components.
Multiple view models
• The structure of a software system is not unique. It can be viewed
from different perspectives and results in a number of different
structural models of the same system. For example, a software
system can be analysed according to the modules and their
interrelationships. It can also be analysed according to the processes
at the run-time and their interrelationships. These two structures are
usually different.
• Components
• Externally visible properties
• Structures
Pipe and Filter Architecture
• The pipe-and-filter architectural style is a sub-type of data flow style.
Therefore, the computational model of data flow is also the model for
pipes-and-filters style.
• The components in a pipes-and-filters architecture are called filters.
• The connectors in pipe-and-filter systems are called pipes.
• There are three important constraints on the components and the
connectors of pipe and filter architecture.
• Independence Filters must be independent entities. In particular, they should not
share state with each other. There should be no global state variables as well.
• Anonymity Filters do not know the identity of their upstream and downstream
filters. Their specifications might restrict what appears on the input pipes or make
guarantees about what appears on the output pipes, but they may not identify the
components at the ends of those pipes.
• Concurrency The correctness of the output of a pipe-and-filter network should not
depend on the order in which the filters perform their incremental processing
although fair scheduling can be assumed.
• There is no structure restriction in addition to that of the restrictions
of data flow architectural style.
Properties derived from the architecture
• Pipe and filter architecture allow the designer to understand the
overall input/output behaviour of a system as a simple composition of
the behaviours of the individual filters.
• It supports reuse. Any two filters can be hooked together, provided
they agree on the data that are being transmitted between them.
• Systems are easy to maintain and enhance. New filters can be added
to existing systems, and old filters can be replaced by improved ones.
• Each filter can be implemented as a separate task and potentially
executed in parallel with other filters.
• Pipe and filter architecture has its own disadvantage also. It often
leads to a batch organisation of processing.
• Although filters can process data incrementally, they are inherently
independent, so the designer must think of each filter as providing a
complete transformation of input data to output data.
• They may be hampered by having to maintain correspondence
between two separate but related streams.
Simplified architecture of compilers
Layered architecture
• It is also known as the n-tier architecture pattern. This pattern is the
de facto standard for most Java EE applications and therefore is
widely known by most architects, designers, and developers.
• Components within the layered architecture pattern are organized
into horizontal layers, each layer performing a specific role within the
application.
• In some cases, the business layer and persistence layer are combined
into a single business layer, particularly when the persistence logic
(e.g., SQL) is embedded within the business layer components.
• The presentation tier is the user interface and communication layer of
the application, where the end user interacts with the application.
• The business layer is where you put the models and logic that is
specific to the business problem you are trying to solve.
• The persistence layer, also called the data access layer, acts as a
protective layer. It contains the code that's necessary to access the
database layer.
• The database layer is where the system stores all the data. It's the
lowest tier in the software architecture and houses not only data but
indexes and tables as well. Search, insert, update and delete
operations occur here frequently.
• One of the powerful features of the layered architecture pattern is
the separation of concerns among components.
• Each of the layers in the architecture is marked as being closed. This is
a very important concept in the layered architecture pattern. A closed
layer means that as a request moves from layer to layer, it must go
through the layer right below it to get to the next layer below that
one.
Repositories in architecture
• In data-centered architecture, the data is centralized and accessed
frequently by other components, which modify data. The main
purpose of this style is to achieve integrality of data.
• Data-centered architecture consists of different components that
communicate through shared data repositories. The components
access a shared data structure and are relatively independent, in that,
they interact only through the data store.
• The most well-known examples of the data-centered architecture is a
database architecture, in which the common database schema is
created with data definition protocol – for example, a set of related
tables with fields and data types in an RDBMS.
There are two types of components
• A central data structure or data store or data repository, which is
responsible for providing permanent data storage. It represents the
current state.
• A data accessor or a collection of independent components that
operate on the central data store, perform computations, and might
put back the results.
• The flow of control differentiates the architecture into two categories
• Repository Architecture Style
• Blackboard Architecture Style
Repository Architecture Style
• The client sends a request to the system to perform actions
• The computational processes are independent and triggered by incoming
requests
• This approach is widely used in DBMS
Advantages
• Provides data integrity, backup and restore features
• Provides scalability and reusability of agents as they do not have direct
communication with each other.
• Reduces overhead of transient data between software components
Disadvantages
• It is more vulnerable to failure and data replication or duplication is possible
• High dependency between data structure of data store and its agents
• Changes in data structure highly affect the clients
• Evolution of data is difficult and expensive
• Cost of moving data on network for distributed data
• Blackboard Architecture Style
• In Blackboard architecture style, the data store is active and its clients are
passive. Therefore the logical flow is determined by the current data status in
data store.
• A number of components that act independently on the common data
structure are stored in the blackboard.
• In this style, the components interact only through the blackboard. The data-
store alerts the clients whenever there is a data-store change.
• The current state of the solution is stored in the blackboard and processing is
triggered by the state of the blackboard.
• The system sends notifications known as trigger and data to the clients when
changes occur in the data.
Call and return architectures
This architecture style allows to achieve a program structure which is
easy to modify.
• Main program or subprogram architecture
• Remote procedure call architecture
• Object-oriented architectures
Heterogeneous Architecture
• Most software systems are not built from a single style. Instead, the
design of a software system at architectural level often needs to
combine different styles to solve the design problem. Software
systems that are not in a single style are called heterogeneous styles.
• Hierarchical heterogeneous styles
• Simultaneously heterogeneous styles
• In many cases, the architecture of a software system can be aptly described as
in a number of different architectural styles.
• An architecture in the data centred style consists of a number of clients that
access and update the data in the shared data component. In many cases, the
system can also be viewed as in the independent component style, especially
when the shared data is an active repository and the clients have their own
thread of controls.
• In the design of a software system, due to the overlapping between different
architectural styles, several designs in different styles can be merged into one
design that shares all the advantages of different styles and avoids the
disadvantages.
• Locationally heterogeneous styles
• A software system seldom appears in the exact form of an architectural style
as theoretically defined.
• A software system’s architecture is in a locationally heterogeneous
style if it can be considered as in one style when taking a subset of its
components and connectors, meanwhile it can also be viewed as in
another style when taking a different subset of the components and
connectors.
• Software systems’ architectures in locationally heterogeneous styles
exist for the following reasons:
• the theoretical definitions of architectural styles are abstractions of
collections of software systems that have common features in their
architecture structures and behaviours.
• the architectural styles that we have recognised are still far away from a
complete catalogue. In fact, it is doubtful if such a complete catalogue could
even be developed. Therefore, it is inevitable that sometimes we can only
partially recognise the architectural style of a system and have several
different such partial understandings of a software system’s architectural
style.
• Locationally heterogeneous styles also often occur as a result of software
evolution process. When components and connectors are added into an
existing system and existing ones are modified or deleted to enhance its
functionality or fix bugs, the style of the system’s architecture may change as
well.
• Alternative view of the JVM architecture
Architecture and requirements
• Requirements for a system come in a variety of forms: textual
requirements, mock-ups, existing systems, use cases, user stories, and
more.
• Functional requirements.
• Quality attribute requirements
• Constraints
What is the “response” of architecture to each of these kinds of
requirements?
• Functional requirements are satisfied by assigning an appropriate
sequence of responsibilities throughout the design. Assigning
responsibilities to architectural elements is a fundamental
architectural design decision.
• Quality attribute requirements are satisfied by the various structures
designed into the architecture, and the behaviours and interactions of
the elements that populate those structures.
• Constraints are satisfied by accepting the design decision and
reconciling it with other affected design decisions.
Functionality
• Functionality does not determine architecture. That is, given a set of
required functionality, there is no end to the architectures you could
create to satisfy that functionality. At the very least, you could divide
up the functionality in any number of ways and assign the sub-pieces
to different architectural elements.
Specifying Quality Attribute Requirements

• A quality attribute requirement should be unambiguous and testable.

• Functional requirements
• Quality attribute requirements
• Constraints
• https://aws.amazon.com/what-is/service-oriented-architecture/
• https://www.differencebetween.com/difference-between-soa-and-
vs-web-services/
• https://www.oracle.com/technical-resources/articles/javase/soa.html