Cla ss Dia gra m
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.
Relation to other diagram types: Use Component / Block
diagrams to show where data is stored or transferred in the system.
U se Ca se Dia gra m s
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.
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.
De sign le ve l
Com pone nt / Bloc k Dia gra m
Additional components and connectors are introduced to describe the static structure of the system on design level.
Se que nc e Dia gra m
Describe method calls between objects here.
Ac t ivit y Dia gra m
Provide more detailed information on behavior on method level.
Cla ss Dia gra m
Show classes and interfaces with their methods and attributes and their relations, including inheritance.
Pa c k a ge Dia gra m
Describe dependencies between packages that include classes and interfaces.
Copyright 2 0 0 8 SAP AG. All right s re se rve d
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.
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.
SAP ERP Consuming Application
Web Service Enabling Providing Application
R
Registered Services
Business Application
Business Application
R R
Business Data Consuming Application
R
Web Service Call
R R
R
Web Service
Call
Wha t is T AM ?
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 typesTAM
defines the features to be used for each diagram typeTAM
extends the UML 2.0 metamodel to incorporate FMC(www.fmc-modeling.org) block diagrams
Why T AM ?
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.
Conc e pt ua l Le ve l
Com pone nt / Bloc k Dia gra m
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.
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?)
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.
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.
The Component / Block diagram is UML 2.0 compliant by an extension of the metamodel.
Se que nc e Dia gra m
Sequence diagrams show how agents interact and communicate. They should be used on instance level, that is they should show one typical sequence.
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.
Ac t ivit y Dia gra m
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.
Send Request
Do Something Call Local Service
Process Request
Send Response Done
Wait for Response
Process Response
Consumer Web Service
Enabling
Business Application
Swimlane of Agent Start of
Activity
Action
Fork
End of Activity
Join
Merge
Decision
Relation to other diagram types: Use Component / Block
diagrams to show the connections among the agents via channels, and their access to storages.
St a t e M a c hine Dia gra m
State Machine diagrams provide an alternative way to describe behavior. Use them where you obviously need the description of states and their transitions.
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.
Relation to other diagram types: The connection of the
