SOFTWARE ARCHITECTURE

WITH SOA MODELING FLAVOR

SUBMITTED TO : EEAKSA SUBMITTED BY : MOHAMED ZAKARYA

AGENDA
• What/Why Software Architecture
• Software Architecture in Real World
• Software Architecture Views
• Module View
• Component – Connector View
• SOA Modeling in practice
• Service Identification
• Service Specification
• Service Design
• Allocation View
• Mapping between views
WHAT IS SOFTWARE ARCHITECTURE

Depiction of the system

that aids in the understanding of how the system will behave.

System Blueprint
that composed of elements , relations between them and
properties of both

Set of design decisions

that if made incorrect , may cause your project to be cancelled

Separate Execute Allocate

SOFTWARE ARCHITECTURE IN REAL WORLD - FACTORY

• Separate each factory elements (Assets : dept.)

• Show dependency between (Assets : depts.)
Separate

• Show execution of production flow

• Show production element relations
Execute

• Mapping between HR , Assets

• Show deployment of assets
Allocate
SOFTWARE ARCHITECTURE IN REAL WORLD - HUMAN

• Separate each system (Systems : Nervous, Digestive)

• Show dependency between Systems
Separate

• Show execution of each System flow

• Show execution elements relations
Execute

• Mapping between Army(red blood cells), Systems

• Show deployment of Systems
• Install location of each system
Allocate
 WHY SOFTWARE ARCHITECTURE

Ensure satisfaction of

Business Behavioral System Stakeholders

Goals Requirements Quality Satisfaction
SOFTWARE ARCHITECTURE VIEWS

Module Component
Allocation
Connector
SOFTWARE ARCHITECTURE VIEWS

• Separate each module of your system

• Show dependency modules
Separate

• Show execution components of your system

• Show execution components relations
Execute

• Mapping between modules and working team

• Show deployment technique
Allocate
MODULE VIEW

• Implementation unit of software, provide coherent units of software

• Module view represented by modules and submodules
• Software system decomposed into manageable units
Module
• Map how source code decomposed into units
• Show change impact between implementation units, so explain ability
for modification, reuse.
• No software architecture without at least one style of module view
• Blueprint of source code , data store
MODULE VIEW STYLES

Module View Have set of Styles for representation

Module

Decomposition Uses Generalization Layered Data Model

1 2 3 4 5
MODULE VIEW – DECOMPOSITION STYLE

 Architect tend to attach a problem by use of divide and conquer

technique ( divide complex problem to smaller ones ) Module
 Show the structure of modules and submodules
 divide responsibilities into manageable pieces (implementation units)
 Code organization into modules and show how system responsibilities
Are partitioned across them
 Decomposition defined modules that may appear in other styles like
uses, generalization, layered, other module based views
 Usually decomposition is first step architect start with to model their
system (First step towards details architecture)
MODULE VIEW – DECOMPOSITION STYLE - CONTENT

Content Description
Elements Modules
Submodules, Module
subsystem (aggregate of modules)
Relations is-part-of relation (containment relation)
Properties Element name: Module-Name indicate role in name
Element responsibility: in details what responsibility of
modules in whole system
Decomposition
MODULE VIEW – DECOMPOSITION STYLE DESIGN CRITERIA

Build versus buy decisions

Some modules may be bought from market place, or reuse of old
projects or obtained as open source.

Achievement of certain quality attributes

For example, to support Modifiability:
Module
 Information hiding design principle will reduce side effects.
 Limit global impact of local design changes.
 Eg. Remote control with TV or Air Conditioner
Product line implementation
 make products of product family, make some sort of separation Decomposition
 Separate common modules from variable modules that differ
across products
Team Allocation
 make responsibilities done in parallel, separate modules that can be
allocated to different team should be defined
 Skills of development team may change decomposition,
MODULE VIEW – DECOMPOSITION STYLE USAGE

Module

Support the learning input for the work
process about a system assignment view of a
for newcomers to the system
project
Show effects of change in
addition to uses style
Decomposition
MODULE VIEW – DECOMPOSITION STYLE IN PRACTICE

Module

Decomposition

UML Diagram List Catalog

MODULE VIEW – USES STYLE

 The uses style shows how modules depend on each other

 helpful for planning because it helps define subsets and increments of
Module
the system being developed
 module uses another module if its correctness depends on the
correctness of the other
 Goes one step further to reveal which modules use which other
modules. This style tells developers what other modules must exist for
Uses their portion of the system to work correctly.
MODULE VIEW – USES STYLE - CONTENT

Content Description
Elements Module
Relations Uses relation(form of the depends-on relation)
Module
constraints Don’t make dependency loops | long dependency chains
otherwise ability of architecture to be delivered in incremental
subsets will be impaired.

Uses
MODULE VIEW – USES STYLE USAGE

Module

Planning incremental Debugging Message the effect

development and & testing of change Uses
subsets
MODULE VIEW – USES STYLE - IN PRACTICE

Module

Uses

DSM
UML Diagram ( dependency structure matrix)
MODULE VIEW – GENERALIZATION STYLE

 The generalization style results when the is-a relation is employed

 The parent module is a more general version of the child modules
Module
(The parent module owns the commonalities, and the variations are
manifested in the children)
 Extensions can be made by adding, removing, or changing children
 A change to the parent will automatically change all the children that
inherit from it
 Generalization may represent inheritance of either interface,
implementation, or both
MODULE VIEW – GENERALIZATION STYLE - CONTENT

Content Description
Elements Module.
A module can have the “abstract” property to indicate it does Module
not contain a complete implementation
Relations Generalization relation (specialization of the is-a relation)
constraints A module can have multiple parents , although multiple
inheritance is often considered a dangerous design approach
Cycles in the generalization relation are not allowed
Generalization
MODULE VIEW – GENERALIZATION STYLE USAGE

Module

Generalization
Reusable enable Capturing Expressing
Modules incremental commonalities inheritance
Extension with variations In Object
as children oriented
MODULE VIEW – GENERALIZATION STYLE – IN PRACTICE

Module

Generalization

Inheritance Realization(implementation)
MODULE VIEW – LAYERED STYLE

 The layered style, like all module styles, reflects a division of the
software into units Module
 Each layer represents a grouping of modules that offers a cohesive set
of services
 The layered view of architecture, shown with a layer diagram, is one of
the most commonly used views in software architecture
 Layering has one more fundamental property: The layers are created
Layered to interact according to a strict ordering relation
 unidirectional allowed-to-use relation with each other.
 n-tier architecture is a physical structuring mechanism, while a n-layer
architecture is a logical structuring mechanism.
MODULE VIEW – LAYERED STYLE - CONTENT

Content Description
Elements Layer.
The description of a layer should define what modules the Module
layer contains
Relations Allowed to use relation (specialization of the depends-on)
The design should define the layer usage rules (for example, “A
layer is allowed to use any lower layer.”)
constraints The allowed-to-use relations should not be circular (that is, a Layered
lower layer cannot use a layer above)
There are at least two layers (typically three or more).
MODULE VIEW – LAYERED STYLE USAGE

Module

Achieving modifiability Managing Layered

Promoting
separation & complexity
reuse
of concerns portability & facilitating
code structure
communication
to developers
MODULE VIEW – LAYERED STYLE – IN PRACTICE

Module

Layered
MODULE VIEW – DATA MODEL STYLE

Module
 The Data modeling is a common activity in the software development
process of information systems
 describes the static information structure in terms of data entities and
their relationships
 The data model is often represented graphically in entity-relationship
diagrams (ERDs) or UML class diagrams.
MODULE VIEW – DATA MODEL STYLE - CONTENT

Content Description
Elements Data entity
which is an object that holds information that needs to be Module
stored or somehow represented in the system
Relations One-to-one, one-to-many, and many-to-many relationships,
which are logical associations between data entities
Generalization/specialization, which indicate an is-a relation
between entities
Data Model
Properties include name, data attributes, primary key, and rules to grant
users permission to access the entity.
MODULE VIEW – DATA MODEL STYLE - STAGES

Conceptual data model

• First draft
• abstracts implementation
details and focuses on the
entities and their relationships Module
Logical data model
• evolution of the conceptual
data model
• data management technology
(such as relational databases)
Data Model

Physical data model

• implementation of the data
entities
• partitioning or merging
entities, duplicating data, and
creating identification keys and
indexes.
MODULE VIEW – DATA MODEL STYLE USAGE

Module

Performing structure of data

impact analysis used in the system Enforcing Guiding
of changes to extensibility data quality implementation
data model analysis & avoiding of modules that
Generalization
redundancy access the data
& inconsistency
MODULE VIEW – DATA MODEL STYLE – IN PRACTICE

Module

Data Model
COMPONENT – CONNECTOR VIEW
A C&C view : execution part of architecture ( runtime behavior )

Component :

 Shows elements that have some runtime presence, Component

 Has set of ports through which interacts other components Connector
(via connectors)
 such as processes, objects, clients, servers, and data stores

Connectors :

 other elements the pathways of interaction,

 such as communication links and protocols, information flows, and
access to shared storage

 Showing how the system works

 Guiding development by specifying the structure & behavior of runtime elements
COMPONENT – CONNECTOR VIEW STYLES

Component
Connector
WHAT IS A SERVICE

• A value delivered to another through a well defined interface

• A Business or capability that exposed by its provider
• Set of capabilities that collaborate to make specific purpose Component
• Any thing in enterprise represents a service Connector
SOA ESB - INTEGRATION LAYER

Component
Connector
COMPONENT – CONNECTOR VIEW – SOA STYLE

Content Description
Elements Service providers,
Service consumers,
ESB, Component
Registry of services, Connector
Orchestration server,
SOAP connector,
REST connector,
Messaging connector, ( publish – subscriber)
Others ,,
constraints Provider connect to consumer but middleware component can
be used like ESB
Service providers may also be service consumers
WHY SOA ?

Component
Connector
WHY SOA ?

Component
Integrating legacy systems
Connector

Allowing interoperability of distributed

components running on different platforms
or across the Internet

Allowing dynamic reconfiguration

SOA MODELING IN PRACTICE

Component
Connector

Service Service Service

Identification Specification Design
SOAML
METHODOLOGY

UML profile & Meta-model

for the specification and
design of services within a
service-oriented
architecture
SOA DESIGN PHASES – SERVICE IDENTIFICATION

Component
Connector
• Define service Capability uses Model
• Define Service Interface Capability Model
• Define Participant Capability Model

Service
Identification
SERVICE IDENTIFICATION – SERVICE CAPABILITY
• The ability to do something
• Identifies a cohesive set of functions or resources provided by one or more
participants
• Ability to act and produce an outcome that achieves a result
• Capabilities are used to identify candidate services
• Can specify a general capability of a participant as well as the specific ability
to provide a service
Service
• Allows architects to analyze how services are related and how they might be Identification
combined to form some larger capability prior to allocation to a particular
Participant
SERVICE IDENTIFICATION – SERVICE CAPABILITY - REAL WORLD

Lighting service Sadad service

Capabilities : Capabilities :
1. Key card for power
Service
1. Absher bills
Identification
2. Temperature sensor 2. Electric bills
3. Light starter 3. Airport ticket
4. Ballast ( trans)
SERVICE IDENTIFICATION – SERVICE CAPABILITY
Capability can be identified using the following techniques
Goal-service modeling [strategies and goals]
Identifies capabilities needed to realize business requirements

Domain decomposition [Business Process]

Uses activities in business processes and other descriptions
of business functions to identify needed capabilities
Service
Existing asset analysis [existing]
Identification
Discover capabilities from existing applications
SERVICE IDENTIFICATION - MODELS
In Service Identification Phase Main Purpose is to Identify Services by identify capabilities

Model
Capability Uses Diagram
Participant Capability Diagram
Description
1. Identify Capabilities
2. Relations between capabilities
3. Exposing appropriate capabilities as services
1. Define participant that provide capabilities

Service
Identification
SERVICE IDENTIFICATION – IN PRACTICE

Service Capabilities Uses Model Service Capabilities Uses Model

with exposed Service Interface
SERVICE IDENTIFICATION – IN PRACTICE

Service
Identification

Service Interface realized by a Capability

SERVICE IDENTIFICATION – IN PRACTICE

Participant realizes the Shipping Capability Participant with two parts specified by Capabilities
SOA DESIGN PHASES – SERVICE SPECIFICATION

• Define Service Architecture Model

• Define Service Contract Model
• Define Service Interface Model
• Define Provider-Consumer Dependency Model
• Define Provider-Consumer Sequence Flow Model
Service • Define Message Centric Model
Specification
SERVICE SPECIFICATION – SERVICE ARCHITECTURE

Service architecture is Formal specification of the business requirements that are

performed by interacting service participants. Contains the same information as the
original business process and can be treated as a specification for how to realize that
business process.

Service architecture answers the following questions:

• What effect is the requirement intended to accomplish?

• Who participates to get it done?
• What are the roles responsible for?
• What roles interact?
• What are the rules for how the roles interact? Service
• How do we evaluate whether the requirements were met? Specification
 SERVICE SPECIFICATION – SERVICE CONTRACT
A Service Contract defines:

• Terms
• conditions
• choreography

 A ServiceContract is binding on all participating parties

 A Participant plays a role as provider or user of services specified by Service Contracts
 Each role is defined by an Interface or Service Interface
 It defines the relationships between a set of roles defined by Interfaces Service
and/or Service Interfaces. Specification
 Participants can engage in a variety of contracts
 Each time a ServiceContract is used in a Services Architecture;
there must also be a compliant port on a participant
 Usually includes nonfunctional aspects such as SLAs
SOA MUST SATISFY SLA

A service-level agreement (SLA) is a formal contract between a service provider

and a consumer that focus on :

 Service availability
 Performance
 Traffic levels
 Messages / queries per hour / minute / second
 Response time
 Rejected transactions
 Errors
Service
Specification
SERVICE SPECIFICATION – SERVICE INTERFACE
 A Service Interface :

• Type of a service port

• Can be bi-directional ( require , provide )
• Can have a protocol

 A ServiceInterface is a UML Class and defines specific roles each participant plays
in the service interaction (valid interactions between the provider and consumer)

 The provided and required Interfaces

are standard UML interfaces that are realized or used by the ServiceInterface Service
Specification
The realized interfaces specify value provided

The used interfaces define value required

SERVICE SPECIFICATION - MODELS

Model Description
Services architecture 1. Review business process
2. Define participant participate in service
architecture
3. Define contracts between participants
Service contract Model 1. Define consumer and provider
2. Show provider consumer dependency
3. Show provider consumer sequence flow
Service Interface Model 1. provided and required Interfaces (UML interfaces)
2. Define ServiceInterface class
3. protocol Behavior (activity, sequence or state Service
diagram) Specification
Message Centric 1. Show MessageType and its operations
SERVICE SPECIFICATION – IN PRACTICE – SERVICES ARCHITECTURE

Service
Specification
SERVICE SPECIFICATION – IN PRACTICE – SERVICE CONTRACT

Service
Specification

‫صاحب الكورس‬ ‫المستفيد بالكورس‬

SERVICE SPECIFICATION – IN PRACTICE – SERVICE CONTRACT

Service
Specification
SERVICE SPECIFICATION – IN PRACTICE – SERVICE INTERFACE

Service
Specification
SOA DESIGN PHASES – SERVICE DESIGN

• Define Participant Dependency Model

• Define Participant Component Model

Service
Design
SERVICE DESIGN - MODELS

Model Description
Participant Dependency 1. Define participants
diagram 2. Define participants provided services
3. Define participants required services
Participant Component 1. Define internal component of participants
Diagram 2. Show dependencies between components

Service
Design
SERVICE DESIGN – IN PRACTICE

Service
Design
SERVICE DESIGN – IN PRACTICE

Service
Design
 SOA MODELING TERMS :
Term Description
Capability The ability to act and produce an outcome that achieves a result
Service A resource that enable access to one or more capabilities (Set of capabilities)
logical representation of repeatable business activity that has a specified outcome SOA
Participant Type of a provider and/or consumer of services. Terms
participant may be a person, organization, system or component
Service Interface • specifying how to interact with a Service.
• used as the type of a Service or Request Port
• Define interface & responsibilities of participant to provide || consume service.
• Defines the way in which other elements can interact and exchange information
with a service
Service Contract • A service contract defines the terms, conditions, and interaction rules that
interacting participants must agree
• represents an agreement by two or more parties
• agreement between providers and consumers of a service as to what
information, products, assets, value, and obligations will flow between the
providers and consumers of that service
 SOA MODELING TERMS :

Term Description
Consumer • Receives the results of the service interaction
• Type of a role in a service contract and the type of a port on a participant.
Provider • Models the interface provided by the provider of a service SOA
• Type of a role in a service contract and the type of a port on a participant. Terms
Request port Defines port through which Participant makes requests to consumes services
Service port Point of interaction on Participant where service actually provided | consumed
MessageType Specification of information exchanged between service consumer & provider
Consists of data passed into, and/or returned from, the invocation of an
operation or event signal defined in a service interface
Service Oriented Architectural paradigm for defining how people, organizations and systems
Architecture provide and use services to achieve results
Service Architecture The high-level view of SOA that defines how a set of participants works
together for some purpose by providing and using service
ServiceChannel communication path between consumer Requests (ports) and provider
services (ports)
SOAML – IN PRACTICE – FULL PICTURE
ALLOCATION VIEW

Software elements in a software architecture interaction with non software

elements in the environment in which the software is developed, deployed, and
executed.

Allocation
Three allocation styles are
• deployment
(mapping software architecture to the hardware of the computing platform),
• Install
(mapping it to a file system in the production environment)
• work assignment
(mapping it to the teams in the development organization)
ALLOCATION VIEW STYLES

Allocation
ALLOCATION VIEW – DEPLOYMENT STYLE

Allocation
 Mapping of C&C in the software architecture to the hardware of the
computing platform
 A valid allocation ensures that requirements expressed by
software elements are satisfied by the characteristics of the
hardware element(s)
ALLOCATION VIEW – DEPLOYMENT STYLE - CONTENT

Content Description
Elements Software element: elements from a C&C view
Environmental elements: hardware of the computing Allocation
platform—processor, memory, disk, network
Relations Allocated-to. Physical units on which the software
elements reside during execution
Migrates-to, copy-migrates-to, and/or execution migrates-
to if the allocation is dynamic Properties include the trigger
that causes the migration Deploy
Constraints required properties of the software must be satisfied
by the provided properties of the hardware
ALLOCATION VIEW – DEPLOYMENT STYLE - RELATIONSHIP

relation Description
Migrates-to • A relation from a software element on one processor to
the same software element on a different processor Allocation
• software element can move from processor to processor
but does not simultaneously exist on both processors.
Copy-migrates-to • similar to the migrates-to relation, except that the
software element sends a copy of itself to the new
processor while retaining a copy on the original
processing element. Deploy
Execution- • indicates that execution moves from processor to
migrates-to processor but that the code residency does not change
• A copy of a process exists on more than one processor,
but only one is active at any particular time
ALLOCATION VIEW – DEPLOYMENT STYLE – IN PRACTICE

Allocation

Deploy
ALLOCATION VIEW – INSTALL STYLE

 Alocates components of a C&C style to a file management system in

the production environment.
 When software system is implemented, the resulting files have to be Allocation
packaged to be installed on the target production platform
 These files include libraries, executable files, data files, log files,
configuration and version control files, license files, help files,
deployment descriptors, scripts, and static content
 Files need to be organized so as to retain control over and maintain
the integrity of the system build and package process, as well as to Install
help deplorers and operators locate and manipulate the files when
necessary
 Configuration management techniques, build tools, and installation
tools usually help to get this job done
ALLOCATION VIEW – INSTALL STYLE - CONTENT

Content Description
Elements Software element: a C&C component
Relations Allocated-to. A component is allocated to a configuration item. Allocation
Containment. One configuration item is contained in another.
Constraints Files and folders are organized in a tree structure, following an
is-contained-in relation.

Install
ALLOCATION VIEW – INSTALL STYLE – IN PRACTICE

Allocation

Install
ALLOCATION VIEW – WORK ASSIGNMENT STYLE

 The work assignment style allocates modules of a module style to Allocation

the groups and individuals who are responsible for the realization of
a system
 defines the responsibility for implementing and integrating the
modules to the appropriate development teams
 Typically used to link activities to resources to ensure that the modules
are each assigned to an individual or team
 Basic for work breakdown structures and for budget and schedule
estimates
ALLOCATION VIEW – WORK ASSIGNMENT STYLE - CONTENT

Content Description
Elements • Software element: a module.
Properties include the required skill set and available Allocation
capacity (effort, time) needed.
• Environmental element: an organizational unit
such as a person, a team, a department, a subcontractor,
Properties include the provided skill set and the capacity
in terms of labor and calendar time available
Relations Allocated-to.
A software element is allocated to an organizational unit Work
assignment
Constraints In general, the allocation is unrestricted;
in practice, it is usually restricted so that one module is
allocated to one organizational unit
ALLOCATION VIEW – WORK ASSIGNMENT STYLE – IN PRACTICE

Allocation

Work
assignment
MAPPING VIEWS
STAKEHOLDER SATISFACTION
ANY QUESTIONS
REFERENCES

http://training-course-material.com/training/Category:SoaML
http://www.amazon.com/Documenting-Software-Architectures-Views-Beyond/dp/0321552687
https://wiki.sei.cmu.edu/sad/index.php/Main_Page
http://www.omg.org/spec/SoaML/1.0.1/
THANKS
ENJOY ARCHITECTURE .. WITH SOA FLAVOR

MAIL: ENG.MOHAMEDZAKARYA@GMAIL.COM