Professional Documents
Culture Documents
SoftwareArchitectureWithSOAModeling PDF
SoftwareArchitectureWithSOAModeling PDF
System Blueprint
that composed of elements , relations between them and
properties of both
Ensure satisfaction of
Module Component
Allocation
Connector
SOFTWARE ARCHITECTURE VIEWS
Module
1 2 3 4 5
MODULE VIEW – DECOMPOSITION STYLE
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
Module
Support the learning input for the work Show effects of change in
process about a system assignment view of a addition to uses style
Decomposition
for newcomers to the system
project
MODULE VIEW – DECOMPOSITION STYLE IN PRACTICE
Module
Decomposition
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
Module
Uses
DSM
UML Diagram ( dependency structure matrix)
MODULE VIEW – GENERALIZATION STYLE
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
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
Module
Module
Data Model
COMPONENT – CONNECTOR VIEW
A C&C view : execution part of architecture ( runtime behavior )
Component :
Connectors :
Component
Connector
WHAT IS A SERVICE
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
Component
Connector
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
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
Model Description
Capability Uses Diagram 1. Identify Capabilities
2. Relations between capabilities
3. Exposing appropriate capabilities as services
Participant Capability Diagram 1. Define participant that provide capabilities
Service
Identification
SERVICE IDENTIFICATION – IN PRACTICE
Service
Identification
Participant realizes the Shipping Capability Participant with two parts specified by Capabilities
SOA DESIGN PHASES – SERVICE SPECIFICATION
• Terms
• conditions
• choreography
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 :
A ServiceInterface is a UML Class and defines specific roles each participant plays
in the service interaction (valid interactions between the provider and consumer)
are standard UML interfaces that are realized or used by the ServiceInterface Service
Specification
The realized interfaces specify value provided
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
SERVICE SPECIFICATION – IN PRACTICE – SERVICE INTERFACE
Service
Specification
SOA DESIGN PHASES – SERVICE DESIGN
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
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
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
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