What Is Software

Architecture?
IEEE 1471-2000
Software architecture is the fundamental
organization of a system, embodied in its
components, their relationships to each
other and the environment, and the
principles governing its design and
evolution
From:www.rgoarchitects.com

What Is Software
Architecture?
Software architecture encompasses the set
of significant decisions about the
organization of a software system
Selection of the structural elements and their
interfaces by which a system is composed
Behavior as specified in collaborations
among those elements
Composition of these structural and
behavioral elements into larger subsystems
Architectural style that guides this
organization
From:www.rgoarchitects.com

What Is Software
Architecture?
Boehm et al., 1995
A software system architecture comprises
A collection of software and system components, connections, and constraints
A collection of system stakeholders' need statements
A rationale which demonstrates that the components, connections, and
constraints define a system that, if implemented, would satisfy the collection of
system stakeholders' need statements

Clements et al., 1997

The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components, and the
relationships among them

From:www.rgoarchitects.com

What Is Software
Architecture?
The highest-level breakdown of a
system into its parts; the decisions
that are hard to change; there are
multiple architectures in a system;
what is architecturally significant can
change over a system's lifetime; and,
in the end, architecture boils down to
whatever the Important stuff is.
Patterns of Enterprise Application Architecture, Martin Fowler

Architecture First
Architecture represents the set of
earliest design decisions
Hardest to change
Most critical to get right
Architecture is the first design artifact
where a systems quality attributes are
addressed
From:www.rgoarchitects.com

Architecture vs. Design

Architecture: where non-functional decisions are cast,

and functional requirements are partitioned
Design: where functional requirements are
accomplished

non-functional
requirements
(ilities)

functional
requirements
(domains)

architecture

design

Important : this is a general guideline sometimes the borders are

blurred

Software Architectures for

341
For the purposes of this course we will
limit your choice of architectures to
two that are well suited to building
web solutions.
1. Model-View-Controller (MVC)
2. Web Enterprise Architecture (WEA)

MVC

The solid line represents a direct association, the dashed an

indirect association (via an observer for example).
Taken in entirety from: http://en.wikipedia.org/ wiki/Model

MVC
ModelViewController (MVC) is a software
architecture, currently considered an architectural
pattern used in software engineering. The pattern
isolates "domain logic" (the application logic for the
user) from the user interface (input and presentation),
permitting independent development, testing and
maintenance of each (separation of concerns).
The model manages the behavior and data of the
application domain, responds to requests for
information about its state (usually from the view), and
responds to instructions to change state (usually from
the controller). In event-driven systems, the model
notifies observers (usually views) when the
information changes so that they can react.
Taken in entirety from: http://en.wikipedia.org/ wiki/ModelViewController

MVC
The view renders the model into a form suitable
for interaction, typically a user interface
element. Multiple views can exist for a single
model for different purposes. A viewport
typically has a one to one correspondence with
a display surface and knows how to render to it.
The controller receives input and initiates a
response by making calls on model objects. A
controller accepts input from the user and
instructs the model and viewport to perform
actions based on that input.
Taken in entirety from: http://en.wikipedia.org/ wiki/ModelViewController

MVC
An MVC application may be a collection of
model/view/controller triads, each responsible for a
different UI element. The Swing GUI system, for example,
models almost all interface components as individual MVC
systems.
MVC is often seen in web applications where the view is the
HTML or XHTML generated by the app. The controller
receives GET or POST input and decides what to do with it,
handing over to domain objects (i.e. the model) which
contain the business rules and know how to carry out
specific tasks such as processing a new subscription, and
which hand control to (X)HTML-generating components
such as templating engines, XML pipelines, Ajax callbacks,
etc.
Taken in entirety from: http://en.wikipedia.org/ wiki/ModelViewController

MVC
The 'model' in MVC is both the data and the
business/domain logic needed to manipulate the data
in the application. Many applications use a persistent
storage mechanism such as a database to store data.
MVC does not specifically mention the data access
layer because it is understood to be underneath or
encapsulated by the model. Models are not data
access objects; however, in very simple apps that
have little domain logic there is no real distinction to
be made. Active Record is an accepted design pattern
which merges domain logic and data access code - a
model which knows how to persist itself.
Taken in entirety from: http://en.wikipedia.org/ wiki/ModelViewController

MVC
Overview
Though MVC comes in different flavors, control flow is generally as follows:
1. The user interacts with the user interface in some way. (for example,
presses a mouse button).
2. The controller handles the input event from the user interface, often via
a registered handler or callback and converts the event into appropriate
user action, understandable for the model.
3. The controller notifies the model of the user action, possibly resulting in
a change in the model's state. (For example, the controller updates the
user's shopping cart.)
4. A view queries the model in order to generate an appropriate user
interface (for example, the view lists the shopping cart's contents). The
view gets its own data from the model. In some implementations, the
controller may issue a general instruction to the view to render itself. In
others, the view is automatically notified by the model of changes in
state (Observer) which require a screen update.
5. The user interface waits for further user interactions, which restarts the
cycle.
Taken in entirety from: http://en.wikipedia.org/ wiki/ModelViewController

MVC in Java EE
Java: Java Platform, Enterprise Edition (Java EE)
Simple Version implementing Java Servlets and JavaServer Pages from
JavaEE:
Model This is the applications business layer and is usually made up of
the objects that represent the business entities that make up the
application. The model is a collection of Java classes that form a software
application intended to store, and optionally separate, data. A single
front end class that can communicate with any user interface (for
example: a console, a graphical user interface, or a web application).
View The view is represented by a JavaServer Page, with data being
transported to the page in the HttpServletRequest or HttpSession.
Controller The Controller servlet communicates with the front end of the
model and loads the HttpServletRequest or HttpSession with appropriate
data, before forwarding the HttpServletRequest and Response to the JSP
using a RequestDispatcher.
The Servlet is a Java class, and it communicates and interacts with the
model, but does not need to generate HTML or XHTML output; the JSPs do
not have to communicate with the model because the Servlet provides
them with the informationthey can concentrate on creating output.
Taken in entirety from: http://en.wikipedia.org/ wiki/ModelViewController

MVC
MVC architecture is the base for a
number of commercial and open
source frameworks and is included in
the allowable architectures for 341 in
part to permit the use of these
frameworks in developing your
application.

WEA
Web Enterprise Architectures are
designed to handle the large
volumes of traffic expected of a
business in a robust and reliable
manner.
The WEA model is a layered
Architecture composed of 3 main
layers (though each main layer may
be sub-divided into 2 or more sublayers)

WEA
The main layers of a WEA are:
Presentation
Logic (aka Domain or Domain Logic)
Services (aka Technical Services or
even as the Data Access layer where
no other services are contemplated)

WEA
As a Layered Architecture we would
expect any particular layer of a WEA
to communicate only with those
layers directly above or below it.
This is indeed the case. He
presentation layer has direct
communication only with the logic
layer as does the services layer. In
no case should the presentation
layer ever communicate directly

WEA
We see then the same separation of
concerns in the WEA that we saw in
the MVC, but executed over a
layered architectural structure rather
than simply as connected
components.
WEA typically make strong use of
Enterprise Patterns to ensure quality
and maintainabitly.
(see: Patterns of Enterprise Application

Architectures Prevent Spaghetti

Code
Whether you use the MVC or the WEA
we see that in neither case to the
architectural patterns permit the
direct access of the model, let alone
the persistent storage mechanism
(database), by the front end (View or
Presentation Layer).
You should never allow direct access to
your database from the web page
itself.

4+1 View
The 4+1 view comes from the Rational Unified
Process (RUP) and is composed of the logical,
process, development, and deployment view along
with the scenarios.
http://en.wikipedia.org/wiki/File:4%2B1_Architectural_View_Model.jpg

RUP 4+1
From:www.rgoarchitects.com

Logical View
Logical view: The logical view is concerned
with the functionality that the system
provides to end-users. UML Diagrams used
to represent the logical view include Class
diagram, Communication diagram,
Sequence diagram.
For this project we will expect you to use a
truncated version of your Design Class
Diagram (DCD) including only the
architecturally significant classes.

Development View
Development view: The development view
illustrates a system from a programmer's
perspective and is concerned with software
management. This view is also known as the
implementation view. It uses the UML
Component diagram to describe system
components. UML Diagrams used to represent
the development view include the Package
diagram.
For this project we will expect you to use a
component diagram.

Process View
Process view: The process view deals
with the dynamic aspects of the
system, explains the system
processes and how they
communicate, and focuses on the
runtime behavior of the system. The
process view addresses concurrency,
distribution, integrators,
performance, and scalability, etc.
UML Diagrams to represent process

Physical View
Physical view: The physical view
depicts the system from a system
engineer's point-of-view. It is
concerned with the topology of
software components on the physical
layer, as well as communication
between these components. This
view is also known as the
deployment view. UML Diagrams
used to represent physical view

Scenarios
Scenarios: The description of an architecture is
illustrated using a small set of use cases, or
scenarios which become a fifth view. The scenarios
describe sequences of interactions between
objects, and between processes. They are used to
identify architectural elements and to illustrate and
validate the architecture design. They also serve as
a starting point for tests of an architecture
prototype. UML Diagram(s) used to represent the
scenario view include the Use case diagram.
Here you may reuse the UCD you developed as part
of your requirements phase.

Class Diagram and UCD

We will study the correct UML
depiction of the design Class
Diagram (DCD) in a later tutorial.
For the 4+1 view a truncated version
of the DCD that includes only
architecturally significant classes is
used.
The Use Case Diagram has been
covered in a earlier tutorial.

Component Diagram
In the Unified Modeling Language, a
component diagram depicts how
components are wired together to
form larger components and or
software systems. They are used to
illustrate the structure of arbitrarily
complex systems.
From: http://en.wikipedia.org/wiki/Component_diagram

Component Diagram
Component diagrams are composed of
Components and Connectors.
Components are wired together by using an
assembly connector to connect the required
interface of one component with the
provided interface of another component.
This illustrates the service consumer service provider relationship between the
two components.
http://en.wikipedia.org/wiki/Component_diagram

Components
A component in the Unified Modeling Language
"represents a modular part of a system, that
encapsulates its content and whose
manifestation is replaceable within its
environment. A component defines its behavior
in terms of provided and required interfaces".
A component may be replaced by another if and
only if their provided and required interfaces are
identical. This idea is the underpinning for the
plug-and-play capability of component-based
systems and promotes software reuse.
http://en.wikipedia.org/wiki/Component_%28UML%29

Assembly Connectors Show

Interfaces
An assembly connector is a "connector
between two components that defines
that one component provides the
services that another component
requires. An assembly connector is a
connector that is defined from a
required interface or port to a provided
interface or port.
http://en.wikipedia.org/wiki/Component_diagram

Delegation Connector
A delegation connector is a "connector
that links the external contract of a
component (as specified by its ports)
to the internal realization of that
behavior by the components parts.
http://en.wikipedia.org/wiki/Component_diagram

A Component Diagram

http://en.wikipedia.org/wiki/File:Policy_Admin_Component_Diagram.PNG

Component Diagrams
Note
The interfaces defined by the named ball and socket
connectors (assembly connector).
Ball - provides service
Socket uses service
The dashed arrow for delegation connectors.
The named rectangular components

For more information See:

http://www.agilemodeling.com/artifacts/componentDiagram.htm

Activity Diagram
Activity diagrams are graphical
representations of workflows of stepwise
activities and actions with support for
choice, iteration and concurrency.[1] In the
Unified Modeling Language, activity
diagrams can be used to describe the
business and operational step-by-step
workflows of components in a system. An
activity diagram shows the overall flow of
control.
http://en.wikipedia.org/wiki/Activity_diagram

Activity Diagram

http://en.wikipedia.org/wiki/Activity_diagram

Activity Diagram
Activity diagrams are constructed from a limited
repertoire of shapes, connected with arrows. The most
important shape types:
rounded rectangles represent activities;
diamonds represent decisions;
bars represent the start (split) or end (join) of concurrent
activities;
a black circle represents the start (initial state) of the
workflow;
an encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent
the order in which activities happen.
Hence they can be regarded as a form of flowchart (with
added notation for concurrency).
http://en.wikipedia.org/wiki/Activity_diagram

Deployment Diagram
A deployment diagram in the Unified
Modeling Language models the physical
deployment of artifacts on nodes. To describe a
web site, for example, a deployment diagram
would show what hardware components
("nodes") exist (e.g., a web server, an
application server, and a database server), what
software components ("artifacts") run on each
node (e.g., web application, database), and how
the different pieces are connected (e.g. JDBC,
REST, RMI).
http://en.wikipedia.org/wiki/Deployment_diagram

Deployment Diagram
The nodes appear as boxes, and the
artifacts allocated to each node appear
as rectangles within the boxes. Nodes
may have subnodes, which appear as
nested boxes. A single node in a
deployment diagram may conceptually
represent multiple physical nodes,
such as a cluster of database servers.
http://en.wikipedia.org/wiki/Deployment_diagram

Deployment Diagram
http://en.wikipedia.org/wiki/File:Deployment_Diagram.PNG

Deployment Diagram
Note:
That in the previous slides the connecting lines,
the protocols were unnamed. This is incorrect.
All connecting protocols should be named.
The nested components: hardware
components, or nodes, and software
components called artifacts.
Note the UML symbol for artifact in the upper
right hand corner of the artifacts and the loose
and permissive naming conventions for nodes