Software architecture models in 3 phases module phase , execution phase and allocation phase and focus on execution phase on SOA modeling in practice "Download for better Resolution of presentation"

1. SOFTWARE ARCHITECTURE
WITH SOA MODELING FLAVOR
SUBMITTED BY : MOHAMED ZAKARYASUBMITTED TO : EEAKSA

2. 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

3. 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

4. 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

5. 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

6. WHY SOFTWARE ARCHITECTURE
Ensure satisfaction of
Business
Goals
System
Quality
Stakeholders
Satisfaction
Behavioral
Requirements

7. SOFTWARE ARCHITECTURE VIEWS
Module Component
Connector
Allocation

8. 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

9. 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

10. MODULE VIEW STYLES
Module
Decomposition Uses Generalization Layered Data Model
Module View Have set of Styles for representation
1 2 3 4 5

11. 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)

12. 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

13. 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,

14. MODULE VIEW – DECOMPOSITION STYLE USAGE
Module
Decomposition
Support 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

15. MODULE VIEW – DECOMPOSITION STYLE IN PRACTICE
Module
Decomposition
UML Diagram List Catalog

16. 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.

17. 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.

18. MODULE VIEW – USES STYLE USAGE
Module
Debugging
& testing
Message the effect
of change
Planning incremental
development and
subsets
Uses

19. MODULE VIEW – USES STYLE - IN PRACTICE
Module
Uses
UML Diagram
DSM
( dependency structure matrix)

20. 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

21. MODULE VIEW – GENERALIZATION STYLE - CONTENT
Module
Content 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 allowed
Generalization

22. MODULE VIEW – GENERALIZATION STYLE USAGE
Module
Generalization
Reusable
Modules
enable
incremental
Extension
Capturing
commonalities
with variations
as children
Expressing
inheritance
In Object
oriented

23. MODULE VIEW – GENERALIZATION STYLE – IN PRACTICE
Module
Generalization
Inheritance Realization(implementation)

24. 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.

25. 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).

26. MODULE VIEW – LAYERED STYLE USAGE
Module
Promoting
reuse
Managing
complexity
& facilitating
code structure
communication
to developers
modifiability
&
portability
Achieving
separation
of concerns
Layered

27. MODULE VIEW – LAYERED STYLE – IN PRACTICE
Module
Layered

28. 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.

29. MODULE VIEW – DATA MODEL STYLE - CONTENT
Module
Data Model
Content Description
Elements Data entity
which 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 entities
Generalization/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.

30. 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.

31. 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

32. MODULE VIEW – DATA MODEL STYLE – IN PRACTICE
Module
Data Model

33. COMPONENT – CONNECTOR VIEW
Component
Connector
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

34. COMPONENT – CONNECTOR VIEW STYLES
Component
Connector

35. 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
Component
Connector

36. SOA ESB - INTEGRATION LAYER
Component
Connector

37. COMPONENT – CONNECTOR VIEW – SOA STYLE
Component
Connector
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

38. WHY SOA ?
Component
Connector

39. WHY SOA ?
Component
Connector
Integrating legacy systems
Allowing interoperability of distributed
components running on different platforms
or across the Internet
Allowing dynamic reconfiguration

40. SOA MODELING IN PRACTICE
Service
Identification
Service
Design
Service
Specification
Component
Connector

41. SOAML
METHODOLOGY
UML profile & Meta-model
for the specification and
design of services within a
service-oriented
architecture

42. SOA DESIGN PHASES – SERVICE IDENTIFICATION
Service
Identification
• Define service Capability uses Model
• Define Service Interface Capability Model
• Define Participant Capability Model
Component
Connector

43. 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

44. 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

45. 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

46. SERVICE IDENTIFICATION - MODELS
In Service Identification Phase Main Purpose is to Identify Services by identify capabilities
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

47. SERVICE IDENTIFICATION – IN PRACTICE
Service Capabilities Uses Model Service Capabilities Uses Model
with exposed Service Interface

48. SERVICE IDENTIFICATION – IN PRACTICE
Service Interface realized by a Capability
Service
Identification

49. SERVICE IDENTIFICATION – IN PRACTICE
Participant realizes the Shipping Capability Participant with two parts specified by Capabilities

50. 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

51. 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?

52. 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

53. 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

54. 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
The realized interfaces specify value provided
The used interfaces define value required
Service
Specification

55. 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
diagram)
Message Centric 1. Show MessageType and its operations
Service
Specification

56. SERVICE SPECIFICATION – IN PRACTICE – SERVICES ARCHITECTURE
Service
Specification

57. SERVICE SPECIFICATION – IN PRACTICE – SERVICE CONTRACT
‫بالكورس‬ ‫المستفيد‬‫الكورس‬ ‫صاحب‬
Service
Specification

58. SERVICE SPECIFICATION – IN PRACTICE – SERVICE CONTRACT
Service
Specification

59. SERVICE SPECIFICATION – IN PRACTICE – SERVICE INTERFACE
Service
Specification

60. SOA DESIGN PHASES – SERVICE DESIGN
Service
Design
• Define Participant Dependency Model
• Define Participant Component Model

61. SERVICE DESIGN - MODELS
Service
Design
Model Description
Participant Dependency
diagram
1. Define participants
2. Define participants provided services
3. Define participants required services
Participant Component
Diagram
1. Define internal component of participants
2. Show dependencies between components

62. SERVICE DESIGN – IN PRACTICE
Service
Design

63. SERVICE DESIGN – IN PRACTICE
Service
Design

64. 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
SOA
Terms

65. 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)
SOA
Terms

66. SOAML – IN PRACTICE – FULL PICTURE

67. 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)

68. ALLOCATION VIEW STYLES
Allocation

69. 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)

70. ALLOCATION VIEW – DEPLOYMENT STYLE - CONTENT
Allocation
Deploy
Content Description
Elements Software element: elements from a C&C view
Environmental elements: hardware of the computing
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
Constraints required properties of the software must be satisfied
by the provided properties of the hardware

71. 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

72. ALLOCATION VIEW – DEPLOYMENT STYLE – IN PRACTICE
Allocation
Deploy

73. 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

74. 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.

75. ALLOCATION VIEW – INSTALL STYLE – IN PRACTICE
Allocation
Install

76. 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

77. 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 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
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

78. ALLOCATION VIEW – WORK ASSIGNMENT STYLE – IN PRACTICE
Allocation
Work
assignment

79. MAPPING VIEWS

80. STAKEHOLDER SATISFACTION

81. ANY QUESTIONS

82. 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/

83. THANKS
ENJOY ARCHITECTURE .. WITH SOA FLAVOR
MAIL: ENG.MOHAMEDZAKARYA@GMAIL.COM