dr lazic - pregled arhitektura 2

8/3/2019 Dr Lazic - Pregled Arhitektura 2

1/51

Doc. DrLjubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007 1/49

What is Software Architecture ?A Definition of Software Architecture

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 (Bass,

Clements, Kazman)

References:

Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, Addison

Wesley

Larman, Applying UML and Patterns, Ch 30

Deepak Alur, John Crupi, Dan Malks, Core J2EE Patterns


2/51


Evolutionof Enterprise Application Architectures


3/51


What is Software Architecture ?


4/51


Implications of Definition 1Architecture is an abstraction of systems.

Architecture defines components and how they interact.

Architecture suppresses purely local information aboutcomponents; private details are not architectural.

Systems have many structures (views).

No single structure can be thearchitecture.

The set of candidate structures is not fixed orprescribed: whatever is useful for analysis,

communication, or understanding.


5/51


Implications of Definition 2Components have properties

Assumptions that one component can make of

another.Include

provided services (functionality)

required services

performance characteristics

fault handling

shared resource usage


6/51


Implications of Definition 3Components have Relationships

Relationshipsare more general than connectors.

Relationships may be runtime (connectors). sends data to

invokes

signals

Relationships may also be nonruntime. is a submodule of

encapsulates information

inherits from


7/51Doc. DrLjubomir Lazi Kljent Server Sistemi (Softverske Arhitekture) @ 2007 7/49

Implications of Definition 4Every system hasan architecture.

Every system is composed of components and relationships

among them.

In the simplest case, a system is composed of a singlecomponent, related only to itself.

Just having an architecture is different from having

an architecture that is known to everyone. New issues: architecture versus specification of the architecture architecture recovery and conformance

rationale for the architecture



Evolutionof Enterprise Application Architectures Mainstream software practice has evolved from procedural

to object-oriented to component-oriented development

With the increasing adoption of enterprise Java and

Microsoft .Net, component orientation is the next majorparadigm.

In corporate development, most new-start projects areadopting component orientation because it is supported bythe majority of commercial development environments.

Reasons

object orientation has a very weak notion of softwarearchitecture, which leads to serious shortcomings



Component-Oriented Technology

Systems thinking: software processes technologycomponentware (or component

orientation) provides key elements of the solution to

today's critical software problems.

Componentware introduces the generatingbusiness rules. Component infrastructures Software patterns Software architecture Component-based development



Procedural Paradigm and Object-Oriented Paradigm


12/51


Distributed System Software Design

Convergent Component


13/51


Distributed System Software DesignDevelopment Model


14/51


Distributed System Software DesignIntegrated Development Environment

BOM BusinessObject Model -UMLRAS Pattern

RefinementAssistant-UMLREF RefinementAssistant-UMLGEN TranslativeGenerator

IX Implement,Deploy, and TestEnvironment


15/51


Architectural RequirementsQuality attributes

criteria for architecture selection

there are four classes of system qualities

quality is largely dependent on architectural decisions

not all aspects of all qualities are affected by architecture

architecture can only permit, not guarantee, any quality

attribute:"What the architecture give, the implementation can take

away."


16/51


Qualities AttributesFitness of a product for its intended use.

There are four classes of system qualities.

1. Runtime qualities

2. Nonruntime qualities

3. Business qualities

4. Architecture qualities


17/51



18/51



19/51


Business Qualities Cost, schedule

Marketability

Appropriatness

for organization

Architectural QualitiesConceptual integrity: system is constructed from a

small number of architectural structures that interact

in a small number of ways.

achieved via a single architect, or a small, wellcoordinated architecture team.

Correctness/completeness: Architecture should

allow satisfaction of all the (behavioral and quality)

requirements.

Buildability: The system must be buildable withgiven resources.


20/51

CPSC689 20

component componentconnector

rationale

rules, patterns, styles

Stakeholders needs

Framework view

-- look as a whole

Dynamic view

-- change from time to time

Process mode

-- how to build up

Technical

standard

Operational

Rqmts

Properties,

relationships

[Shaw, 1995]

[Boehm, 1995]

[US Army, 1996]

[Perry and Wolf, 1992]


21/51



22/51


Architectural models (views) 1

In a house, there are plans for rooms

electrical wiring

plumbing ventilation

Each of these constitutes a view (model) of the house.

used by different people

used to achieve different qualities in the house servesas a description and prescription

So it is with software architecture.


23/51


Architectural views 2Which structures are used, and why?

Common views include

module

process

uses

calls

data flow class

physical


24/51


Module viewComponents: modules, work assignments

Relations: is a submodule of, shares a

secret withUsed: as a basis of team structure and

resource allocation

Affected attributes include: maintainability,understandability


25/51


Process viewComponents: tasks, processes

Relations: synchronizes with,excludes,

preempts

Used: to tune system runtime performance,

exploit multiprocessing hardware

Affected attributes include: performance


26/51


Uses view

Components: procedures

Relations: assumes the correct presence of

Used: to engineer subsets, supersets

Affected attributes include: reusability,

testability, incremental development


27/51


Calls view

Components: procedures

Relation: invokesUsed: to trace control flow; for debugging

Affected attributes include: buildability,

testability, maintainability, understandability


28/51


Data Flow view

Components: programs, modules

Relation: may send data toUsed: for traceability of functionality

Affected attributes include: performance,

correctness, accuracy


29/51


Class view

Components: objects

Relation: inherits from, is instance of

Used: to exploit similarity among objects

Affected attributes include: development

time, maintainability


30/51


Physical view Components: tasks, processes, processors

Relation: resides on same processor

Used: to manage process to processor

allocation

Affected attributes include: performance,availability


31/51


What Are models Used For?Documentation vehicle for

current development

future development

managers

customersEngineering tool to help achieve qualities


32/51


Architectural views Summary

Views are related to each other in complicated ways.

Offer a separation of concerns useful for managing

large and complex systems.

Some views are combined in small systems (e.g:logical and modular)

Some views are not needed for small systems (e.g:

process view, physical view).Lesson: Choose the views that are useful to the

system being built and to the achievement of qualities

that are important to you.


33/51


Client/Server

Components

Client request information from a serverknows the server identity

Server responds to the requests from

clients

doesn't know the clients' identity


34/51


Client/ServerAdvantagesusers only get information on demand

design addresses presentation details

different ways to view the same dataDisadvantages

need for more sophisticated security, systems

management applications development requires more resources to

implement and support


35/51


Two tier Client/Server architectures

Processing management split between user

system interface environment and database

management server environment.

Tier 1: user system interface

In user's desktop environment

Tier 2: database management services

In a server


36/51


Two tier Client/Server architecturesLimitations

performance deteriorate when number of clients

is large (>100 users) flexibility and choice of DBMS for applications

reduced (by processing management at server level

stored procedures)

limited flexibility in moving (repartitioning)program functionalityfrom one server to another


37/51


Three tier Client/Server architecturesTier 1: user system interface

Tier 2: middletier provides

process management (business logic and rulesexecution) and

functions (e.g: queuing, application execution,

and database staging)Tier 3: database management services


38/51


Three tier architectures middle tierCentralizes process logic

Improve performance, flexibility, maintainability,

reusability, and scalabilitychanges must only be written once and placed on

the middle tier server to be available throughout the

systems

distributed database integrity more easily enforced

access to resourcesbased on names


39/51



40/51


TrendsMoving from single tier or two tier to multitier

architecture

Moving from monolithic model to object based

application model

Moving from fatclient to HTML basedthin Client


41/51


J2EEIn competition with the CORBA standard, Java inherited all the

conquests of the CORBA group in the area of innovative softwareparadigms for distributed system software design and glued them in auniversally used language:

The Java community response to CORBA standards: J2EE


42/51


J2EE Application Server

JND

I

J2SE

JMS

RMI/I

IOP

JDB

C

Database

AppClient

App ClientContainer

HTTP/HTTPS

J2SE

RMI

J2SE

JND

I

JM

S

RMI/IIOP

JDB

C

JTA

JavaMail

JAF JND

I

JMS

RMI/II

OP

JDB

C

JTA

JavaMail

JAF

HTTP/HTTPS

Applet Container

Applet JSP Servlet EJB

Web Container EJB Container

RMI

J2SE


43/51



44/51



45/51



46/51



47/51



48/51



49/51



50/51



51/51

dr lazic - pregled arhitektura 2

Documents