Flyer: Technical Architecture Modeling

Class Diagram
Class diagrams show the system’s entities and their
relationships. Use it to explain terms and their relations on
high level (glossary, topic map), or to show the structure of
data to be processed.
Design level
Component / Block Diagram
Additional components and connectors are introduced to
describe the static structure of the system on design level.
Sequence Diagram
Consuming
Application
R
Describe method calls between objects here.
Consuming
Application
Web Service Call
R
Web
Service
Call
R
Activity Diagram
Provide more detailed information on behavior on method
level.
Class Diagram
Show classes and interfaces with their methods and attributes
and their relations, including inheritance.
Package Diagram
Relation to other diagram types: Use Component / Block
diagrams to show where data is stored or transferred in the
system.
Providing
Application
Web Service Enabling
Registered
Services
R
R
Business
Application
R
R
Business
Application
Business Data
SAP ERP
Describe dependencies between packages that include
classes and interfaces.
Use Case Diagrams
Use Case diagrams allow the specification of a system’s
desired functionality on task level. You can show which use
cases exist and who participates in them. Describe all use
cases in an additional detailed text document.
Copyright 2008 SAP AG. All rights reserved
SAP, R/3, mySAP, mySAP.com, SAP NetWeaver, and other SAP products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of
SAP AG in Germany and in several other countries all over the world. All other product and
service names mentioned are the trademarks of their respective companies. Data contained in
this document serves informational purposes only. National product specifications may vary.
Relation to other diagram types: Use Component / Block
diagrams to show which agents will perform which tasks. Use
Activity, Sequence or State Machine diagrams to display the
behavior described by the tasks.
This document is a preliminary version and not subject to your license agreement or any other
agreement with SAP. This document contains only intended strategies, developments, and
functionalities of the SAP® product and is not intended to be binding upon SAP to any
particular course of business, product strategy, and/or development. Please note that this
document is subject to change and may be changed by SAP at any time without notice.
SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant
the accuracy or completeness of the information, text, graphics, links, or other items contained
within this material. This document is provided without a warranty of any kind, either express or
implied, including but not limited to the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement.
SAP shall have no liability for damages of any kind including without limitation direct, special,
indirect, or consequential damages that may result from the use of these materials. This
limitation shall not apply in cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not affected. SAP has no
control over the information that you may access through the use of hot links contained in
these materials and does not endorse your use of third-party Web pages nor provide any
warranty whatsoever relating to third-party Web pages.
Standard for Technical
Architecture Models
What is TAM?
TAM™ stands for Technical Architecture Modeling. TAM
defines a common language and a graphical notation for
communication on model level at SAP. The main target is to
introduce a UML standard-based set of diagram types.
TAM can be used on conceptual and on design level
TAM defines a set of seven UML diagram types
TAM defines the features to be used for each diagram type
TAM extends the UML 2.0 metamodel to incorporate FMC
(www.fmc-modeling.org) block diagrams
Why TAM?
By unifying technical architecture modeling methods, you
benefit in many ways:
TAM improves the quality of architecture models by
eliminating the ambiguity introduced by freestyle modeling.
TAM facilitates knowledge exchange across teams around
the world through unified architecture models.
TAM minimizes the learning effort by reducing the number of
diagram types (UML offers 13) and the variety of elements.
Agents perform operations; they read and write data and
communicate with other agents. (Question: Who does
something?)
Storages are passive; they only hold data that is accessed by
agents. The arrows indicate direction of data flow. (Q: Where is
the data?)
Start of
Activity
Consumer
Action
Send Request
Relation to other diagrams types: Use Class diagrams to
show how data relates that is located in storages or exchanged
via channels. Use Activity or Sequence or State diagrams to
express the behavior of agents and how they interact.
Business
Application
Swimlane
of Agent
Fork
Merge
Channels are used by agents to communicate with each other.
Arrows indicate the direction of data flow, the “R” indicates who
initiates the request and then waits for the response. (Q: Which
agents communicate? What data and which requests do they
exchange?)
Component / Block diagrams show a snapshot view of a
system on instance level; to indicate multiple agents or
storages, use three dots or stack the nodes.
Web Service
Enabling
Do Something
Call Local Service
Process Request
Done
Wait for Response
Send Response
Decision
Join
Process Response
End of
Activity
The Component / Block diagram is UML 2.0 compliant by an
extension of the metamodel.
Relation to other diagram types: Use Component / Block
diagrams to show the connections among the agents via
channels, and their access to storages.
Conceptual Level
Sequence Diagram
State Machine Diagram
Component / Block Diagram
Sequence diagrams show how agents interact and
communicate. They should be used on instance level, that is
they should show one typical sequence.
State Machine diagrams provide an alternative way to
describe behavior. Use them where you obviously need the
description of states and their transitions.
Relation to other diagram types: The connection of the
agents via channels is shown in Component / Block diagrams.
To show more details of processing, use Activity diagrams.
A state transition is performed when the event occurs (given
the guard condition is met). The transition may include an
action that has to be executed as well.
Activity Diagram
Relation to other diagram types: The connection of the
agents via channels is shown in Component / Block diagrams.
To show more details of processing, use Activity diagrams.
The Component / Block diagram is the most important diagram
type to describe architecture. Use it to show the static structure
of the system, and to provide a big picture view.
Activity diagrams show the behavior of one or more agents in
greater detail. In contrast to the Sequence diagram, you can
show loops or concurrency in a more intuitive way. Using
swimlanes, you can assign actions to specific agents.