Architecture Governance Logical Architectural – Diagramming Guidelines uml 0 style guide



Download 186.63 Kb.
Page1/11
Date conversion28.11.2017
Size186.63 Kb.
  1   2   3   4   5   6   7   8   9   10   11

Architecture Governance

Logical Architectural – Diagramming Guidelines

UML 2.0 style guide

October 2008


Table of Contents


1

Architecture Governance 1

Logical Architectural – Diagramming Guidelines 1

UML 2.0 style guide 1

Introduction 1

1.1 Overview 1

1.2 Context 1

1.3 UML 2

1.4 Scope and Purpose 3

1.5 Acknowledgements 5

1.6 Diagram Guidelines and Drawing Conventions 6

Telling the (Functional) Architecture “Story” 8

1.7 The Setting – The Perspective View 10

1.8 Outlining the Plot – System View 1 13

1.9 Developing the Characters – System Views 2-n 15

1.10 Organizing the Dialogue - Sequence Diagrams 17

1.11 The Conclusion – Deployment View 19

1.12 Character “Bios” - The Glossary 22

1.13 The Afterward – Deviations from the Ideal 23

1.14 Additional Diagrams 24

1.14.1 Use Case Diagrams 24

1.14.2 Activity Diagrams 24

1.14.3 Data Model Diagram 24


Symbols and Stereotypes 26


1.15 System View Diagram Symbols 26

1.16 Data Flow Diagram Symbols 27

1.17 Deployment View Symbols 30

1.18 Stereotypes 31

1.19 Module Behavior Stereotypes 31

1.20 Architectural Deviations 33

1.21 Interface Descriptors 33

Effective Diagramming 35

1.22 Interface Pattern 35

1.23 Shared Component Library 35

1.24 Controller Pattern 36

Using Visio 37

1.25 Shapes and Stencils 37

1.26 Connections 38

1.27 Zooming 38

1.28 Aligning Objects 38

1.29 pro.Iankoenig.com stencils 38

Table of Figures 45

Bibliography 47

Index 48



Introduction

1.1Overview

These Architecture Diagramming Guidelines are intended to facilitate the communication of technology architecture. This can either be as a part of an Enterprise Architecture Governance process or simply in the flow of information from business requirements to systems architecture to technical design to implementation to operation.

Whatever the reason, communicating architecture is important to any large technology infrastructure and core to any Enterprise Architecture Governance Process. In order to communicate and concept, particularly complicated ones, both the presenter and the audience must speak a common language and that language should be descriptive enough, flexible enough and precise enough to get the point across..

They say “a picture is worth a thousand words” and where technology architecture is concerned, the old adage is pretty much true. As opposed to inventing something brand new, these Guidelines start with an existing, fairly widely used diagramming language called the UML (Unified Modeling Language).

UML is widely used, extensible and flexible. But with flexibility comes a degree of imprecision. In addition, UML is generally used as a language for communicating design rather than architecture and many of its constructs are moving in the direction of “model driven design” or models that are precise enough so that code can be generated directly from the model (or nearly so).

Architecture on the other hand is more abstract than design, which is more abstract than implementation. As such, we intend to use diagrams to draw out larger relationships between systems and reproducible patterns, rather than designs and implementations. We can use the flexibility inherent in UML quite effectively as long as we define which UML constructs we intend to use, how we intend to use them and what they mean in our context.

1.2Context


When we define architecture, whether it is the architecture of a service, an application or a combination thereof, we divide the architecture into four main parts:

  1. Information Architecture – A systems agnostic view of content as it exists across the technology landscape. The scope covers: entities, relationships, data sets, categorization (ontology), content organization, flow, search, navigation, etc.

  2. Functional Architecture – The modules (organized logically not physically) across the technology landscape proving the features and functions. Often this is decomposed into Services and Solutions. But even on a smaller scale there is usually some separation between shared system-level modules and product specific modules and the glue that binds them.

Service – Coarse grained reusable infrastructure that is live and operational and accessed via loosely coupled interfaces. A service is responsible for handling load and scaling itself as appropriate. You don’t build a new one when you run out of capacity

Solution – Application, Product, etc that either monolithically delivers required business benefit (architecturally bad ) or aggregates multiple services together in order to do so, adding the necessary business logic and glue (architecturally good )

  1. Physical Architecture – The systems (e.g. computers, disk arrays, back-up units, etc), networks (switches, routers, Load balancers, DNS, etc) and houses (data centers, power, cooling, etc) that represent the physical manifestation of the production environment.


  2. Business Process Architecture – The processes that support the underlying business model for which the technology was built. This could be related to getting “hits” on a website to support an advertising model or it could be a full blown order processing/shopping cart/authentication/authorization/billing process supporting a paid subscription. Whatever the Business model is, there should be a Business Process Architecture defined to support it (no matter how simple).

In this context, the following diagramming guidelines (UML style guide) apply solely to the aspect of Functional Architecture.



  1   2   3   4   5   6   7   8   9   10   11


The database is protected by copyright ©hestories.info 2017
send message

    Main page