software architecture with soa modeling flavor
TRANSCRIPT
SOFTWARE ARCHITECTUREWITH SOA MODELING FLAVOR
SUBMITTED BY : MOHAMED ZAKARYASUBMITTED TO : EEAKSA
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
• Separate each factory elements (Assets : dept.)• Show dependency between (Assets : depts.)
Execute
• Show execution of production flow• Show production element relations
Allocate
• Mapping between HR , Assets• Show deployment of assets
SOFTWARE ARCHITECTURE IN REAL WORLD - HUMAN
Separate
• Separate each system (Systems : Nervous, Digestive)• Show dependency between Systems
Execute
• Show execution of each System flow• Show execution elements relations
Allocate
• Mapping between Army(red blood cells), Systems• Show deployment of Systems• Install location of each system
WHY SOFTWARE ARCHITECTURE
Ensure satisfaction of
Business Goals
System Quality
Stakeholders Satisfaction
Behavioral Requirements
SOFTWARE ARCHITECTURE VIEWS
Module ComponentConnector Allocation
SOFTWARE ARCHITECTURE VIEWS
Separate
• Separate each module of your system• Show dependency modules
Execute
• Show execution components of your system• Show execution components relations
Allocate
• Mapping between modules and working team• Show deployment technique
MODULE VIEW
Module
• Implementation unit of software, provide coherent units of software
• Module view represented by modules and submodules
• Software system decomposed into manageable units
• 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
Decomposition Uses Generalization Layered Data Model
Module View Have set of Styles for representation
1 2 3 45
MODULE VIEW – DECOMPOSITION STYLE
Module Architect tend to attach a problem by use of divide and
conquer technique ( divide complex problem to smaller ones )
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
Module
Decomposition
Content Description
Elements Modules Submodules, 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
MODULE VIEW – DECOMPOSITION STYLE DESIGN CRITERIA
Module
Decomposition
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: 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
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
DecompositionSupport the learning
process about a system for newcomers to the
project
input for the work assignment view of a
system
Show effects of change in addition to uses style
MODULE VIEW – DECOMPOSITION STYLE IN PRACTICE
Module
Decomposition
UML Diagram List Catalog
MODULE VIEW – USES STYLE
Module
Uses
The uses style shows how modules depend on each other helpful for planning because it helps define subsets and
increments of 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 their portion of the system to work correctly.
MODULE VIEW – USES STYLE - CONTENT
Module
Uses
Content Description
Elements Module
Relations Uses relation(form of the depends-on relation)
constraints Don’t make dependency loops | long dependency chains otherwise ability of architecture to be delivered in incremental subsets will be impaired.
MODULE VIEW – USES STYLE USAGE
Module
Debugging & testing
Message the effect of change
Planning incremental development and
subsets
Uses
MODULE VIEW – USES STYLE - IN PRACTICE
Module
Uses
UML DiagramDSM
( dependency structure matrix)
MODULE VIEW – GENERALIZATION STYLE
Module
The generalization style results when the is-a relation is employed
The parent module is a more general version of the child modules (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
ModuleContent Description
Elements Module. A module can have the “abstract” property to indicate it does 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 allowedGeneralization
MODULE VIEW – GENERALIZATION STYLE USAGE
Module
GeneralizationReusable Modules
enableincremental
Extension
Capturing commonalitieswith variations
as children
Expressing inheritance
In Object oriented
MODULE VIEW – GENERALIZATION STYLE – IN PRACTICE
Module
Generalization
Inheritance Realization(implementation)
MODULE VIEW – LAYERED STYLE
Module
Layered
The layered style, like all module styles, reflects a division of the software into units
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 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
Module
Layered
Content Description
Elements Layer. The description of a layer should define what modules the 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 lower layer cannot use a layer above)
There are at least two layers (typically three or more).
MODULE VIEW – LAYERED STYLE USAGE
Module
Promoting reuse
Managing complexity & facilitating
code structure communication
to developers
modifiability &
portability
Achieving separation of concerns
Layered
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
Module
Data Model
Content Description
Elements Data entitywhich is an object that holds information that needs to be 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 entitiesGeneralization/specialization, which indicate an is-a relation between entities
Properties include name, data attributes, primary key, and rules to grant users permission to access the entity.
MODULE VIEW – DATA MODEL STYLE - STAGES
Module
Data Model
Conceptual data model• First draft • abstracts implementation
details and focuses on the entities and their relationships
Logical data model• evolution of the conceptual
data model• data management technology(such as relational databases)
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
Generalization
Enforcing data quality & avoiding
redundancy & inconsistency
Performing impact analysis of changes to
data model
structure of data used in the system
extensibility analysis
Guiding implementation of modules that access the data
MODULE VIEW – DATA MODEL STYLE – IN PRACTICE
Module
Data Model
COMPONENT – CONNECTOR VIEW
ComponentConnector
A C&C view : execution part of architecture ( runtime behavior )
Component :
Shows elements that have some runtime presence, Has set of ports through which interacts other components
(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
ComponentConnector
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
• Any thing in enterprise represents a service
ComponentConnector
SOA ESB - INTEGRATION LAYER
ComponentConnector
COMPONENT – CONNECTOR VIEW – SOA STYLE
ComponentConnector
Content Description
Elements Service providers,Service consumers,ESB, Registry of services,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 ?
ComponentConnector
WHY SOA ?
ComponentConnectorIntegrating legacy systems
Allowing interoperability of distributedcomponents running on different platforms or across the Internet
Allowing dynamic reconfiguration
SOA MODELING IN PRACTICE
Service Identification
ServiceDesign
Service Specification
ComponentConnector
SOAMLMETHODOLOGY
UML profile & Meta-modelfor the specification and design of services within a service-oriented architecture
SOA DESIGN PHASES – SERVICE IDENTIFICATION
Service Identification
• Define service Capability uses Model• Define Service Interface Capability Model• Define Participant Capability Model
ComponentConnector
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
• Allows architects to analyze how services are related and how they might be combined to form some larger capability prior to allocation to a particular Participant
Service Identification
SERVICE IDENTIFICATION – SERVICE CAPABILITY - REAL WORLD
Capabilities :
1. Key card for power
2. Temperature sensor
3. Light starter
4. Ballast ( trans)
Lighting service Sadad service
Capabilities :
1. Absher bills
2. Electric bills
3. Airport ticket
Service Identification
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
Existing asset analysis [existing]
Discover capabilities from existing applications
Service Identification
SERVICE IDENTIFICATION - MODELS
In Service Identification Phase Main Purpose is to Identify Services by identify capabilities Model Description
Capability Uses Diagram 1. Identify Capabilities2. Relations between capabilities3. Exposing appropriate capabilities as services
Participant Capability Diagram 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 Interface realized by a Capability
Service Identification
SERVICE IDENTIFICATION – IN PRACTICE
Participant realizes the Shipping Capability Participant with two parts specified by Capabilities
SOA DESIGN PHASES – SERVICE SPECIFICATION
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• Define Message Centric Model
SERVICE SPECIFICATION – SERVICE ARCHITECTURE
Service Specification
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?• How do we evaluate whether the requirements were met?
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
and/or Service Interfaces. 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
Service Specification
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 playsin 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
The realized interfaces specify value provided
The used interfaces define value required
Service Specification
SERVICE SPECIFICATION - MODELS
Model Description
Services architecture 1. Review business process2. Define participant participate in service
architecture3. Define contracts between participants
Service contract Model 1. Define consumer and provider2. Show provider consumer dependency3. Show provider consumer sequence flow
Service Interface Model 1. provided and required Interfaces (UML interfaces)2. Define ServiceInterface class3. protocol Behavior (activity, sequence or state
diagram)
Message Centric 1. Show MessageType and its operations
Service Specification
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
ServiceDesign
• Define Participant Dependency Model• Define Participant Component Model
SERVICE DESIGN - MODELS
ServiceDesign
Model Description
Participant Dependency diagram
1. Define participants 2. Define participants provided services3. Define participants required services
Participant Component Diagram
1. Define internal component of participants2. Show dependencies between components
SERVICE DESIGN – IN PRACTICE
ServiceDesign
SERVICE DESIGN – IN PRACTICE
ServiceDesign
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
Participant Type of a provider and/or consumer of services.
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
SOATerms
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• Type of a role in a service contract and the type of a port on a participant.
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 Architecture
Architectural paradigm for defining how people, organizations and systems 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)
SOATerms
SOAML – IN PRACTICE – FULL PICTURE
ALLOCATION VIEW
Allocation
Software elements in a software architecture interaction with non software elements in the environment in which the software is developed, deployed, and executed.
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
Allocation
Deploy
Content Description
Elements Software element: elements from a C&C viewEnvironmental elements: hardware of the computing platform—processor, memory, disk, network
Relations Allocated-to. Physical units on which the software elements reside during executionMigrates-to, copy-migrates-to, and/or execution migrates-to if the allocation is dynamic Properties include the trigger that causes the migration
Constraints required properties of the software must be satisfied
by the provided properties of the hardware
ALLOCATION VIEW – DEPLOYMENT STYLE - RELATIONSHIP
Allocation
Deploy
relation Description
Migrates-to • A relation from a software element on one processor to the same software element on a different processor
• 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.
Execution-migrates-to
• indicates that execution moves from processor 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
Allocation
Install
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 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 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
Allocation
Install
Content Description
Elements Software element: a C&C component
Relations Allocated-to. A component is allocated to a configuration item.Containment. One configuration item is contained in another.
Constraints Files and folders are organized in a tree structure, following an is-contained-in relation.
ALLOCATION VIEW – INSTALL STYLE – IN PRACTICE
Allocation
Install
ALLOCATION VIEW – WORK ASSIGNMENT STYLE
Allocation The work assignment style allocates modules of a module style to 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
Allocation
Content Description
Elements • Software element: a module. Properties include the required skill set and available capacity (effort, time) needed.
• Environmental element: an organizational unitsuch 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
Constraints In general, the allocation is unrestricted;
in practice, it is usually restricted so that one module is allocated to one organizational unit
Work assignment
ALLOCATION VIEW – WORK ASSIGNMENT STYLE – IN PRACTICE
Allocation
Work assignment
MAPPING VIEWS
STAKEHOLDER SATISFACTION
ANY QUESTIONS
REFERENCES
http://training-course-material.com/training/Category:SoaMLhttp://www.amazon.com/Documenting-Software-Architectures-Views-Beyond/dp/0321552687https://wiki.sei.cmu.edu/sad/index.php/Main_Pagehttp://www.omg.org/spec/SoaML/1.0.1/
