A diagram image.
11 | 12 | -------------------------------------------------------------------------------- /docs/hints/model.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Archimate Model.
11 | 12 | -------------------------------------------------------------------------------- /docs/hints/sketch_sticky.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A "Sticky" figure for your Sketch.
10 | 11 | -------------------------------------------------------------------------------- /docs/hints/sketch_actor.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An "Actor" figure for your Sketch.
11 | 12 | -------------------------------------------------------------------------------- /docs/hints/connection.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A plain connection between two objects with no explicit semantic meaning.
11 | 12 | -------------------------------------------------------------------------------- /docs/hints/folder.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A folder to contain elements.
11 |Note that the root folders cannot be deleted.
12 | 13 | -------------------------------------------------------------------------------- /model/folder.xml: -------------------------------------------------------------------------------- 1 |A Note is simply a place to add user annotations to a diagram.
11 |A Note has no semantic meaning in the ArchiMate language.
12 | 13 | -------------------------------------------------------------------------------- /docs/hints/view_ref.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A View Reference is simply a shortcut to another View in the same model.
11 |Add a View Reference to a View if you wish to create a link to another View of the model. Double-click on it to jump to the View it references.
12 | 13 | -------------------------------------------------------------------------------- /docs/hints/view.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A View is a viewpoint on a model.
11 |Create different Views for different stakeholders addressing particular sets of concerns.
12 |The same elements from the Model Tree can be re-used multiple times in the same or different View.
13 | 14 | -------------------------------------------------------------------------------- /model/relations/ServingRelationship_0792913b-a71e-4275-9c14-8e84b53baab6.xml: -------------------------------------------------------------------------------- 1 |The Group box denotes a collection of objects that belong together but are not aggregated or composed as with the Grouping element.
11 | 12 |The Group provides a convenient visual collection of elements, without any semantic relationships.
13 | 14 |Group Roles and Actors, Business Layers, Application Layers.
16 | 17 | -------------------------------------------------------------------------------- /model/relations/RealizationRelationship_03d3c93e-8adb-4d21-b992-5e67c4ed6dc7.xml: -------------------------------------------------------------------------------- 1 |A Plateau represents a relatively stable state of the architecture that exists during a limited period of time.
13 | 14 | 15 | 16 |Implementation and Migration
18 | 19 |Baseline, Transition 1, Strategic Plan complete, Services in place.
21 | 22 | -------------------------------------------------------------------------------- /model/relations/SpecializationRelationship_4ad03281-110b-438b-be69-bb9d0d57e634.xml: -------------------------------------------------------------------------------- 1 |A free Sketch area in which to map out your ideas.
11 |You can add new "Stickies" to the View, an "Actor" figure and connections.
12 |There are no rules as to what the relationships or stickies mean. All elements can be edited in the Properties Window.
13 |You are free to capture a sketch of your model and then later convert it into a fully realized ArchiMate model and View.
14 | 15 | -------------------------------------------------------------------------------- /docs/hints/resource.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Resource represents an asset owned or controlled by an individual or organization.
11 | 12 |The name of a Resource should preferably be a noun.
13 | 14 |Strategy. Structure.
16 | 17 |Cash, Securities, Plant, Equipment, Land, Mineral Reserves, Patents, Copyrights, Reputation, Brand, Skills/know-how.
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/triggering.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Triggering relationship describes the temporal or causal relations between processes, functions, interactions, and events.
11 | 12 |Used to model the causal relationships between behavioural concepts in a process.
13 | 14 |Dynamic.
16 | 17 |A "Request Insurance" event triggers a series of Business Processes, "Receive request", and "Process request".
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/gap.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Gap represents a statement of difference between two Plateaus
11 | 12 |The Gap element is associated with two Plateaus (e.g., Baseline and Target Architectures, or two subsequent Transition Architectures), and represents the differences between these Plateaus.
13 | 14 |Implementation and Migration
16 | 17 |"Gap between the Baseline and Target infrastructure", "Knowledge of how to address customer needs".
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/assignment.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Assignment relationship links active elements (e.g., Business Roles or Application Components) with units of behaviour that are performed by them, or Business Actors with Business Roles that are fulfilled by them.
11 | 12 |Structural.
14 | 15 |A Business Actor assigned to a Business Role. A Business Role assigned to a Business Process or Function. An Application Component assigned to an Application Function.
17 | 18 | -------------------------------------------------------------------------------- /docs/hints/goal.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Goal is defined as an end state that a Stakeholder intends to achieve.
11 | 12 |An end can represent anything a stakeholder may desire, such as a state of affairs, or a produced value.
13 | 14 |Goals are generally expressed using qualitative words.
15 | 16 |Motivation
18 | 19 |Increase profit, reduce waiting times at the helpdesk, introduce on-line portfolio management, more sales
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/vp_outcome_realization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Outcome Realization viewpoint is used to show how the highest-level, business-oriented results are produced by the capabilities and underlying core elements.
11 | 12 |Business managers, enterprise and business architects
14 | 15 |Business-oriented results
17 | 18 |Designing, deciding
20 | 21 |Strategy
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/composition.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Composition relationship indicates that an object consists of a number of other objects.
11 | 12 |In contrast to the Aggregation relationship, an object can be part of only one composition.
13 | 14 |A Composition relationship is always allowed between two instances of the same element type.
15 | 16 |Structural.
18 | 19 |An Application Component may be composed of two or more sub-components.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/aggregation.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Aggregation relationship indicates that a concept groups a number of other concepts.
11 | 12 |In contrast to the Composition relationship, an object can be part of more than one Aggregation.
13 | 14 |Aggregation is always possible between two instances of the same concept.
15 | 16 |Structural.
18 | 19 |A Car Insurance Business Product aggregates a Business Contract and some Business Services.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/constraint.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Constraint is defined as a restriction on the way in which a system is realized.
11 | 12 |This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), or a restriction on the implementation process (e.g., time or budget constraints).
13 | 14 |Motivation
16 | 17 |"Application should be realised in Java", "Cost should be below budget", "iPad only version", "Must use MIT license"
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/requirement.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Requirement represents a statement of need that must be met by the architecture.
11 | 12 |Requirements model the properties of these elements that are needed to achieve the "ends" that are modelled by the goals. In this respect, requirements represent the "means" to realize goals.
13 | 14 |Motivation
16 | 17 |"Assign personal assistant", "Provide on-line portfolio service", "Provide on-line information service", "Use open source software"
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/course_of_action.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Course of Action is an approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve a goal.
11 | 12 |A Course of Action represents what an enterprise has decided to do. Courses of action can be categorized as strategies (long-term) and tactics (short-term).
13 | 14 | 15 |Strategy. Behaviour.
17 | 18 |Acquire company, Merge organizations, Provide repository support.
20 | 21 | -------------------------------------------------------------------------------- /docs/hints/deliverable.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Deliverable represents a precisely-defined outcome of a Work Package.
11 | 12 |Work Packages produce Deliverables. These may be results of any kind; e.g., reports, papers, services, software, physical products, etc., or intangible results such as organizational change. A Deliverable may also be the implementation of (a part of) an architecture.
13 | 14 |Implementation and Migration
16 | 17 |Software, Hardware, CRM System, Report, Paper
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/style.css: -------------------------------------------------------------------------------- 1 | body, table { 2 | font-family: Arial, Helvetica, sans-serif; 3 | font-size: 13px; 4 | } 5 | 6 | h1 { 7 | font-size: 16px; 8 | } 9 | 10 | h2 { 11 | font-size: 14px; 12 | } 13 | 14 | h3 { 15 | font-size: 13px; 16 | } 17 | 18 | a { 19 | text-decoration:none; 20 | } 21 | a:link { 22 | color:#0033CC; 23 | } 24 | a:visited { 25 | color:#025999; 26 | } 27 | a:hover { 28 | color:#ff9900; 29 | } 30 | 31 | table.border { 32 | border-collapse: collapse; 33 | border-spacing: 0; 34 | } 35 | 36 | td.border { 37 | border: 1px solid black; 38 | padding: 4px; 39 | } 40 | 41 | .caption { 42 | font-style: italic; 43 | font-size: 9pt; 44 | margin-left: 5px; 45 | line-height: 1.5; 46 | } 47 | 48 | .boxout { 49 | border: 1px solid #000; 50 | background-color: #CBDBF8; 51 | padding: 12px; 52 | margin-left: 15%; 53 | margin-right: 15%; 54 | } 55 | -------------------------------------------------------------------------------- /docs/hints/vp_strategy.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Strategy viewpoint allows the business architect to model a high-level, strategic overview of the strategies (courses of action) of the enterprise, the capabilities and resources supporting those, and the envisaged outcomes.
11 | 12 |CxOs, business managers, enterprise and business architects
14 | 15 |Strategy development
17 | 18 |Designing, deciding
20 | 21 |Strategy
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/flow.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Flow relationship describes the exchange or transfer of information or value between processes, function, interactions, and events.
11 | 12 |Used to model the flow of information between behavioural concepts in a process.
13 | 14 |A Flow relationship does not imply a causal or temporal relationship.
15 | 16 |Dynamic.
18 | 19 |A "Claim assessment" Business Function forwards decisions about the claim to the "Claim settlement" Business Function.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/grouping.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Grouping element aggregates or composes concepts that belong together based on some common characteristic.
11 | 12 |The Grouping element is used to aggregate or compose an arbitrary group of concepts, which can be elements and/or relationships of the same or of different types. An Aggregation or Composition relationship is used to link the Grouping element to the grouped concepts.
13 | 14 |Other. Composite.
16 | 17 |Aggregate two Processes and an Object that together Realize a Service
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/material.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |Material represents tangible physical matter or physical elements.
11 | 12 |Material can have attributes such as size and weight. It is typically used to model raw materials and physical products, and also energy sources such as fuel. Material can be accessed by physical processes.
13 | 14 |The name of Material should be a noun. Pieces of Material may be composed of other pieces of Material.
15 | 16 |Physical. Behavioural.
18 | 19 |Plastic Case, Internal Antenna, Speedometer.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/specialization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Specialization relationship indicates that an object is a specialisation of another object.
11 | 12 |The Specialization relationship can relate any instance of a concept with another instance of the same concept.
13 | 14 |Specialization is always possible between two instances of the same concept.
15 | 16 |Other.
18 | 19 |A "Take out travel insurance" and a "Take out luggage insurance" process are a specialization of a more generic "Take out insurance" process.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/vp_technology.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Technology viewpoint contains the software and hardware technology elements supporting the Application Layer, such as physical devices, networks, or system software (e.g., operating systems, databases, and middleware).
11 | 12 |Infrastructure architects, operational managers
14 | 15 |Stability, security, dependencies, costs of the infrastructure
17 | 18 |Designing
20 | 21 |Single layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/serving.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Serving relationship models that an element provides its functionality to another element.
11 | 12 |The Serving relationship describes how the services or interfaces offered by a behavioural or active structure element serve entities in their environment. This relationship is applied for both the behaviour aspect and the active structure aspect.
13 | 14 |Dependency.
16 | 17 |A Payment Interface serves the Customer, while the Payment Service serves the Pay Invoices Process of that customer.
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/location.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Location is a place or position where structure elements can be located or behaviour can be performed.
11 | 12 |The Location concept is used to model the distribution of structural elements such as Business Actors, Application Components, and Devices. This is modelled by means of an Aggregation relationship from location to structural element. A Location can also aggregate a behaviour element, to indicate where the behaviour is performed.
13 | 14 |Other. Composite.
16 | 17 |Main Office, Local Office, Room.
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/stakeholder.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Stakeholder is defined as the role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.
11 | 12 |A Stakeholder has one or more interests in, or concerns about, the organization and its enterprise architecture.
13 | 14 |The name of a Stakeholder should preferably be a noun.
15 | 16 |Motivation
18 | 19 |CEO, the board of directors, shareholders, customers, business, and application architects
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/path.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Path represents a link between two or more Nodes, through which these nodes can exchange data or material.
11 | 12 |A Path is used to model the logical communication (or distribution) relations between Nodes. It is realized by one or more Networks, which represent the physical communication (or distribution) links.
13 | 14 |A Path connects two or more Nodes. A Path is realized by one or more Networks. A Path can aggregate Nodes.
15 | 16 |Technology. Active Structure.
18 | 19 |Message Queuing, Data Replication Path.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/driver.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Driver is an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them.
11 | 12 |Drivers may be internal, in which case they are usually associated with a Stakeholder. They may also be external, e.g., economic changes or changing legislation.
13 | 14 |The name of a Driver should preferably be a noun.
15 | 16 |Motivation
18 | 19 |"Customer satisfaction", "Compliance to legislation", "Profitability", "Economic changes", "Changing legislation"
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/assessment.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Assessment is defined as the outcome of some analysis of some driver.
11 | 12 |An Assessment may reveal strengths, weaknesses, opportunities, or threats for some area of interest. These outcomes need to be addressed by adjusting existing goals or setting new ones, which may trigger changes to the enterprise architecture.
13 | 14 |The name of an Assessment should preferably be a noun or a very short sentence.
15 | 16 |Motivation
18 | 19 |"Complaining customers", "Leaving customers", "Long waiting queues", "High service times", "Changing legislation"
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/vp_physical.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Physical viewpoint contains equipment (one or more physical machines, tools, or instruments) that can create, use, store, move, or transform materials, how the equipment is connected via the distribution network, and what other active elements are assigned to the equipment.
11 | 12 |Infrastructure architects, operational managers
14 | 15 |Relationships and dependencies of the physical environment and how this relates to IT infrastructure
17 | 18 |Designing
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/distribution_network.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Distribution Network represents a physical network used to transport materials or energy.
11 | 12 |A Distribution Network represents the physical distribution or transportation infrastructure. It embodies the physical realization of the logical paths between Nodes.
13 | 14 |A Distribution Network connects two or more Nodes. A Distribution Network may realize one or more Paths. A Distribution Network can consist of sub-networks and can aggregate Facilities and Equipment.
15 | 16 |Physical. Active Structure.
18 | 19 |Local Trucking, Overseas Shipping.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/principle.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Principle represents a qualitative statement of intent that should be met by the architecture.
11 | 12 |Principles define intended properties of systems. A Principle defines a general property that applies to any system in a certain context. A Principle is motivated by some goal or driver. Organizational values, best practices, and design knowledge may be reflected and made applicable in terms of principles.
13 | 14 |Motivation
16 | 17 |"Systems should be customer facing", "Customers should have a great experience", "Colleagues should be informed", "Open Source Software should be used"
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/vp_implementation_deployment.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Implementation and Deployment viewpoint shows how one or more applications are realized on the infrastructure. This comprises the mapping of applications and components onto artifacts, and the mapping of the information used by these applications and components onto the underlying storage infrastructure.
11 | 12 |Application and domain architects
14 | 15 |Structure of application platforms and how they relate to supporting technology
17 | 18 |Designing, deciding
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/workpackage.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Work Package represents a series of actions identified and designed to achieve specific results within specified time and resource constraints.
11 | 12 |The central behavioural element is a Work Package. A Work Package is a behaviour element that has a clearly defined start and end date, and realizes a well-defined set of Goals or Deliverables. The Work Package element can be used to model sub-projects or tasks within a project, complete projects, programs, or project portfolios.
13 | 14 |Implementation and Migration
16 | 17 |"Program to sustain implementation", "Project to secure funding", "Project for CRM system integration"
19 | 20 | -------------------------------------------------------------------------------- /docs/hints/vp_capability.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Capability map viewpoint allows the business architect to create a structured overview of the capabilities of the enterprise. A capability map typically shows two or three levels of capabilities across the entire enterprise. It can, for example, be used as a heat map to identify areas of investment. In some cases, a capability map may also show specific outcomes delivered by these capabilities.
11 | 12 |Business managers, enterprise and business architects
14 | 15 |Architecture strategy and tactics, motivation
17 | 18 |Designing, deciding
20 | 21 |Strategy
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/realization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Realization relationship links a logical entity with a more concrete entity that realizes it.
11 | 12 |The Realization relationship indicates how logical entities ("what" or "logical"), such as services, are realized by means of more concrete entities ("how" or "physical").
13 | 14 |A Business Process or Function may realize a Service. A Data Object may realize a Business Object. An Artifact may realize an Application Component.
15 | 16 |Structural.
18 | 19 | An Application Component, "Financial Application", realizes a "Billing" Service.
21 | A "Billing" Data Object realizes the Business Object, "Invoice".
The Access relationship models the access of behavioural concepts to Business or Data Objects.
11 | 12 |The Access relationship indicates that a process, function, interaction, service, or event "does something" with a passive structure element; e.g., create a new object, read data from the object, write or modify the object data, or delete the object. The relationship can also be used to indicate that the object is just associated with the behaviour.
13 | 14 |The arrow indicates the flow of information.
15 | 16 |Structural.
18 | 19 |Create a new object, Read data from an object, Write or modify object data, Delete an object.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/vp_resource.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Resource map viewpoint allows the business architect to create a structured overview of the resources of the enterprise. A resource map typically shows two or three levels of resources across the entire enterprise. It can, for example, be used as a heat map to identify areas of investment. In some cases, a resource map may also show relationships between resources and the capabilities they are assigned to.
11 | 12 |Business managers, enterprise and business architects
14 | 15 |Architecture strategy and tactics, motivation
17 | 18 |Designing, deciding
20 | 21 |Strategy
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_service_realization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Service Realization viewpoint is used to show how one or more business services are realized by the underlying processes (and sometimes by application components). Thus, it forms the bridge between the business products viewpoint and the business process view. It provides a "view from the outside" on one or more business processes.
11 | 12 |Process and domain architects, product and operational managers
14 | 15 |Added-value of business processes, consistency and completeness, responsibilities
17 | 18 |Designing, deciding
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/node.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Node represents a computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources.
11 | 12 |Nodes are elements that perform technology behaviour and execute, store, and process technology objects such as Artifacts. For instance, Nodes are used to model application platforms. 13 | 14 |
Nodes can be interconnected by Paths. A node may be assigned to an Artifact to model that the Artifact is deployed on the Node.
15 | 16 |The name of a Node should preferably be a noun. A node may consist of sub-nodes.
17 | 18 |Technology. Active Structure.
20 | 21 |Mainframe, Unix Server Farm, Application Server, Firewall.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_migration.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture. Since the plateau and gap elements have been quite extensively presented in Section 13.2, here the migration viewpoint is only briefly described and positioned by means of the table below.
11 | 12 |Enterprise architects, process architects, application architects, infrastructure architects and domain architects, employees, shareholders
14 | 15 |History of models
17 | 18 |Designing, deciding, informing
20 | 21 |Implementation and Migration
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/business_process.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Process is defined as a unit of internal behaviour or collection of causally-related units of internal behaviour intended to produce a defined set of products and services.
11 | 12 |A Business Process describes the internal behaviour performed by a Business Role that is required to produce a set of products and services. For a consumer the required behaviour is not of interest so a process is designated "Internal".
13 | 14 |The name of a Business Process should preferably be or contain a verb in the simple present tense.
15 | 16 |Business. Behavioural.
18 | 19 |Receive request, Register, Pay, Create contract, Sign agreement.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/vp_motivation.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Motivation viewpoint allows the designer or analyst to model the motivation aspect, without focusing on certain elements within this aspect. For example, this viewpoint can be used to present a complete or partial overview of the motivation aspect by relating stakeholders, their primary goals, the principles that are applied, and the main requirements on services, processes, applications, and objects.
11 | 12 |Enterprise and ICT architects, business analysts, requirements managers
14 | 15 |Architecture strategy and tactics, motivation
17 | 18 |Designing, deciding, informing
20 | 21 |Motivation
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/meaning.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Meaning represents the knowledge or expertise present in, or the interpretation given to, a core element in a particular context.
11 | 12 |A Meaning represents the interpretation of an element of the architecture. It is a description that expresses the intent of that element; i.e., how it informs the external user.
13 | 14 |A Meaning can be associated with any core element. To denote that a Meaning is specific to a particular Stakeholder, this Stakeholder can also be associated to the Meaning.
15 | 16 |The name of a Meaning should preferably be a noun or noun phrase.
17 | 18 |Motivation
20 | 21 |Policy explanation, Insurance Policy notification.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/contract.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Contract is defined as a formal or informal specification of an agreement that specifies the rights and obligations associated with a Product.
11 | 12 |A Contract may also be or include a Service Level Agreement (SLA), describing an agreement about the functionality and quality of the services that are part of a Product.
13 | 14 |A Contract is a specialization of a Business Object.
15 | 16 |The relationships that apply to a Business Object also apply to a Contract. A Contract may have an Aggregation relationship with a Product.
17 | 18 |The name of a Contract should preferably be a noun.
19 | 20 |Business. Passive Structure.
22 | 23 |Travel Insurance Policy.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/representation.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Representation is defined as the perceptible form of the information carried by a Business Object.
11 | 12 |Representations (for example, messages or documents) are the perceptible carriers of information that are related to Business Objects.
13 | 14 |A single Business Object can have a number of different Representations, but a Representation always belongs to one specific Business Object. A Representation may realize one or more Business Objects. A Meaning can be associated with a Representation that carries this Meaning.
15 | 16 |The name of a Representation is preferably a noun.
17 | 18 |Business. Passive Structure.
20 | 21 |Paper Bill, Request Form, Claim Form, Online Form.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_organization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Organization viewpoint focuses on the (internal) organization of a company, department, network of companies, or of another organizational entity. It is possible to present models in this viewpoint as nested block diagrams, but also in a more traditional way, such as organizational charts. The Organization viewpoint is very useful in identifying competencies, authority, and responsibilities in an organization.
11 | 12 |Enterprise, process and domain architects, managers, employees, shareholders
14 | 15 |Identification of competencies, authority, and responsibilities
17 | 18 |Designing, deciding, informing
20 | 21 |Single layer/Single aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/influence.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Influence relationship is used to describe that some motivational element may influence (the realization of) another motivational element.
11 | 12 |An influence by some other motivational element may affect this degree positively or negatively
13 | 14 |Attributes can be used to indicate the sign and/or strength of the influence. The choice of possible attribute values is left to the modeler; e.g., {++, +, 0, -, --} or [0..10]. By default, the Influence relationship models a contribution with unspecified sign and strength.
15 | 16 |Dependency.
18 | 19 |The degree in which the goal to increase customer satisfaction is realized may be represented by the percentage of satisfied customers that participate in a market interview.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/application_interface.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Interface represents a point of access where Application Services are made available to a user, another Application Component, or a Node.
11 | 12 |An Application Interface specifies how the functionality of a Component can be accessed by other elements. An Application Interface exposes Application Services to the environment.
13 | 14 |An Application Interface may be part of an Application Component. An Application Interface can be assigned to Application Services, which means that the interface exposes these services to the environment.
15 | 16 |The name of an Application Interface should preferably be a noun.
17 | 18 |Application. Active Structure.
20 | 21 |Transaction data exchange, Web services
23 | 24 | -------------------------------------------------------------------------------- /docs/elements/empty-element.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 |A Technology Process represents a sequence of technology behaviours that achieves a specific outcome.
11 | 12 |A Technology Process describes internal behaviour of a Node. If its behaviour is exposed externally, this is done through one or more Technology Services. A Technology Process abstracts from the way it is implemented.
13 | 14 |A Technology Process may realize Technology Services. Other Technology Services may serve (be used by) a Technology Process. A Node may be assigned to a Technology Process, which means that this Node performs the process.
15 | 16 |The name of a Technology Process should clearly identify a series of technology behaviours.
17 | 18 |Technology. Behavioural.
20 | 21 |System boot sequence, Replicate database
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_requirements_realization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Requirements Realization viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.
11 | 12 |In addition, this viewpoint can be used to refine requirements into more detailed requirements. The aggregation relationship is used for this purpose.
13 | 14 |Enterprise and ICT architects, business analysts, requirements managers
16 | 17 |Architecture strategy and tactics, motivation
19 | 20 |Designing, deciding, informing
22 | 23 |Motivation
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/business_actor.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Actor is defined as an entity that performs behaviour in an organisation such as business processes or functions.
11 | 12 |Typically, a Business Actor performs the behaviour assigned to one or more Business Roles. It's important to separate the actor from the role because a Business Actor can perform more than one Business Role, and a Business Role can be performed by more than one Business Actor.
13 | 14 |Business Actors are humans, departments, and business units. They may be individuals or groups.
15 | 16 |The name of a Business Actor should preferably be a noun.
17 | 18 |Business. Active Structure.
20 | 21 |A Customer, Marketing & Communications department, Director of Finance, Secretary, Admissions Department, Product Development.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/application_process.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Process represents a sequence of application behaviours that achieves a specific outcome.
11 | 12 |An Application Process describes the internal behaviour performed by an Application Component that is required to realize a set of services.
13 | 14 |An Application Process may realize Application Services. Other Application Services may serve (be used by) an Application Process. An Application Process may access Data Objects. An Application Component may be assigned to an Application Process (which means that this component performs the process).
15 | 16 |The name of an Application Process should clearly identify a series of application behaviours.
17 | 18 |Application. Behavioural.
20 | 21 |Claims adjudication process, General ledger update job.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_technology_usage.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Technology Usage viewpoint shows how applications are supported by the software and hardware technology: the technology services are delivered by the devices; system software and networks are provided to the applications. This viewpoint plays an important role in the analysis of performance and scalability, since it relates the physical infrastructure to the logical world of applications. It is very useful in determining the performance and quality requirements on the infrastructure based on the demands of the various applications that use it.
11 | 12 |Application, infrastructure architects, operational managers
14 | 15 |Dependencies, performance, scalability
17 | 18 |Designing
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/communication_network.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Communication Network represents a set of structures and behaviours that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video.
11 | 12 |A Communication Network connects two or more Devices. The most basic Communication Network is a single link between two Devices. A Communication Network realizes one or more Paths. It embodies the physical realization of the logical path between Nodes.
13 | 14 |A Communication Network can consist of sub-networks. It can aggregate Devices and System Software, for example, to model the routers, switches, and firewalls that are part of the network infrastructure.
15 | 16 |Technology. Active Structure.
18 | 19 |LAN. Wireless. Wide Area Network.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/vp_application_usage.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Application Usage viewpoint describes how applications are used to support one or more business processes, and how they are used by other applications. It can be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Furthermore, since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes.
11 | 12 |Enterprise, process, and application architects, operational managers
14 | 15 |Consistency and completeness, reduction of complexity
17 | 18 |Designing, deciding
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_application_cooperation.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Application Cooperation viewpoint describes the relationships between applications components in terms of the information flows between them, or in terms of the services they offer and use. This viewpoint is typically used to create an overview of the application landscape of an organization. This viewpoint is also used to express the (internal) cooperation or orchestration of services that together support the execution of a business process.
11 | 12 |Enterprise, process, application, and domain architects
14 | 15 |Relationships and dependencies between applications, orchestration/choreography of services, consistency and completeness, reduction of complexity
17 | 18 |Designing
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_stakeholder.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Stakeholder viewpoint allows the analyst to model the stakeholders, the internal and external drivers for change, and the assessments (in terms of strengths, weaknesses, opportunities, and threats) of these drivers. Also, the links to the initial (high-level) goals that address these concerns and assessments may be described. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.
11 | 12 |Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers
14 | 15 |Architecture mission and strategy, motivation
17 | 18 |Designing, deciding, informing
20 | 21 |Motivation
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/artifact.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Artifact represents a piece of data that is used or produced in a software development process, or by deployment and operation of an IT system.
11 | 12 |An Artifact represents a tangible element in the IT world. It is typically used to model (software) products such as source files, executables, scripts, database tables, messages, documents, specifications, and model files.
13 | 14 |An Application Component or System Software may be realized by one or more Artifacts. A Data Object may be realized by one or more Artifacts. A Node may be assigned to an Artifact to model that the Artifact is deployed on the Node.
15 | 16 |The name of an Artifact should preferably be the name of the file it represents.
17 | 18 |Technology. Passive Structure.
20 | 21 |Risk Management EJB, Jar file, Widget, Plug-in.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/association.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Association relationship models a relationship between objects that is not covered by another, more specific relationship.
11 | 12 |Used to model relationships between Business Objects or Data Objects that are not modelled by the standard relationships.
13 | 14 |The Association relationship is also used to link the informational concepts with the other concepts: a Business Object with a Representation, a Representation with a Meaning, and a Business Service with a Purpose.
15 | 16 |The Association relationship can be used when drawing a first high-level model where relationships are initially denoted in a generic way, and later refined to show more specific relationship types.
17 | 18 |Structural.
20 | 21 |Some Business Objects and a Business Contract are all associated with each other.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/outcome.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Outcome represents an end result that has been achieved.
11 | 12 |Outcomes are high-level, business-oriented results produced by capabilities of an organization
13 | 14 |Outcomes are closely related to requirements, goals, and other intentions. Outcomes are the end results, and goals or requirements are often formulated in terms of outcomes that should be realized. Capabilities are designed to achieve such outcomes.
15 | 16 |Outcome names should identify end results that have been achieved in order to avoid confusion with actions or goals. At a minimum, outcome names should consist of a noun identifying the end result followed by a past-tense verb or adjective indicating that the result has been achieved.
17 | 18 |Motivation
20 | 21 |"First-place ranking achieved", "Key supplier partnerships in place", "2015 quarterly profits rose 10%"
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_goal_realization.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Goal Realization viewpoint allows a designer to model the refinement of (high-level) goals into more tangible goals, and the refinement of tangible goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship.
11 | 12 |In addition, the principles may be modeled that guide the refinement of goals into requirements.
13 | 14 |Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers
16 | 17 |Architecture mission, strategy and tactics, motivation
19 | 20 |Designing, deciding
22 | 23 |Motivation
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/device.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Device is a physical IT resource upon which system software and Artifacts may be stored or deployed for execution.
11 | 12 |A Device is a specialization of a Node that represents a physical IT resource with processing capability. It is typically used to model hardware systems such as mainframes, PCs, or routers. Usually, they are part of a node together with system software. Devices may be composite; i.e., consist of sub-devices.
13 | 14 |Devices can be interconnected by Networks. Devices can be assigned to Artifacts and to System Software, to model that Artifacts and System Software are deployed on that Device. A Node can contain one or more Devices.
15 | 16 |The name of a Device should preferably be a noun referring to the type of hardware.
17 | 18 |Technology. Active Structure.
20 | 21 |File Server, Router, Mainframe, Desktop PC, IBM System Z.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/technology_event.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Technology Event is a technology behaviour element that denotes a state change.
11 | 12 |Technology Functions and other technology behaviour may be triggered or interrupted by a Technology Event. Also, Technology Functions may raise events that trigger other infrastructure behaviour. An event is instantaneous: it does not have duration. Events may originate from the environment of the organization, but also internal events may occur generated by, for example, other devices within the organization.
13 | 14 |A Technology Event may trigger or be triggered (raised) by a Technology Function, Process, or Interaction. A Technology Event may access a Data Object and may be composed of other Technology Events. The name of a Technology Event should preferably be a verb in the perfect tense.
15 | 16 |Technology. Behavioural.
18 | 19 |Message received, Database update.
21 | 22 | -------------------------------------------------------------------------------- /docs/hints/technology_interaction.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Technology Interaction represents a unit of collective technology behaviour performed by (a collaboration of) two or more Nodes.
11 | 12 |A Technology Interaction describes the collective behaviour that is performed by the Nodes that participate in a Technology Collaboration. A Technology Interaction can also specify the externally visible behaviour needed to realize a Technology Service.
13 | 14 |A Technology Collaboration may be assigned to a Technology Interaction. A Technology Interaction may realize a Technology Service. Technology Services may serve a Technology Interaction. A Technology Interaction may access Artifacts.
15 | 16 |The name of a technology interaction should clearly identify a series of technology behaviours.
17 | 18 |Technology. Behavioural.
20 | 21 |Client profile creation, Update customer records.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_information_structure.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Information Structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may show how the information at the business level is represented at the application level in the form of the data structures used there, and how these are then mapped onto the underlying technology infrastructure; e.g., by means of a database schema.
11 | 12 |Domain and information architects
14 | 15 |Structure and dependencies of the used data and information, consistency and completeness
17 | 18 |Designing
20 | 21 |Multiple layer/Single aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/technology_interface.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Technology Interface represents a point of access where technology services offered by a Node can be accessed.
11 | 12 |A Technology Interface specifies how the technology services of a Node can be accessed by other Nodes. A Technology Interface exposes a Technology Service to the environment.
13 | 14 |A Technology Interface specifies a kind of contract that a component realizing this interface must fulfil.
15 | 16 |A Technology Interface may be part of a Node through composition, which means that these interfaces are provided by that Node, and can serve other Nodes. A Technology Interface can be assigned to a Technology Service, to expose that service to the environment. 17 | 18 |
The name of a Technology Interface should preferably be a noun.
19 | 20 |Technology. Active Structure.
22 | 23 |Client software, Management Interface.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/business_object.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Object is defined as a unit of information that has relevance from a business perspective.
11 | 12 |A Business Object is used to model an object type of which several instances may exist within the organization. In this case, it may be realised as a Data Object or Representation. It may also be specialised by another Business Object.
13 | 14 |Business objects are passive. They do not trigger or perform processes.
15 | 16 |Business Objects may be accessed by a Business Process, Function, Interaction, Event, or Service. A Business Object may have Association, Specialization, Aggregation, or Composition relationships with other Business Objects.
17 | 18 |The name of a Business Object should preferably be a noun.
19 | 20 |Business. Passive Structure.
22 | 23 |Invoice, Customer file, Student record, Attendance record, Ledger.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/product.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Product represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
11 | 12 |A Product consists of a collection of Services, and a Contract that specifies the characteristics, rights, and requirements associated with the Product.
13 | 14 |A Product may aggregate Business Services or Application Services, as well as a Contract.
15 | 16 |A Product may be offered both internally to the organisation and externally to customers.
17 | 18 |A Value may be associated with a Product.
19 | 20 |The name of a Product is usually the name which is used in the communication with customers, or possibly a more generic noun (e.g., "travel insurance").
21 | 22 |Business. Composite.
24 | 25 |A Travel Insurance Product consisting of Insurance Services and a Contract.
27 | 28 | -------------------------------------------------------------------------------- /docs/hints/technology_function.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Technology Function represents a collection of technology behaviour that can be performed by a Node.
11 | 12 |A Technology Function describes the internal behaviour of a Node; for the user of a Node that performs a Technology Function, this function is invisible. If its behaviour is exposed externally, this is done through one or more Technology Services. A Technology Function abstracts from the way it is implemented.
13 | 14 |A Technology Function may realize Technology Services. Technology Services of other Technology Functions may serve Technology Functions. A Technology Function may access Technology Objects. A Node may be assigned to a Technology Function (which means that the Node performs the Technology Function).
15 | 16 |The name of a Technology Function should preferably be a verb ending with "ing".
17 | 18 |Technology. Behavioural.
20 | 21 |Providing Data Access, Managing Data.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/application_function.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Function represents automated behaviour that can be performed by an Application Component.
11 | 12 |An Application Function describes the internal behaviour of an Application Component. If this behaviour is exposed externally, this is done through one or more services.
13 | 14 |An Application Function may realize one or more Application Services. Application Services of other Application Functions and Technology Services may serve an Application Function. An Application Function may access Data Objects. An Application Component may be assigned to an Application Function (which means that the Application Component performs the Application Function).
15 | 16 |The name of an Application Function should preferably be a verb ending with "ing"; e.g., "accounting".
17 | 18 |Application. Behavioural.
20 | 21 |Accounting, Billing, Policy Creation, Calculate Premium, Financial Administration.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/facility.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Facility represents a physical structure or environment.
11 | 12 |A Facility is a specialization of a Node. It represents a physical resource that has the capability of facilitating (e.g., housing or locating) the use of equipment. It is typically used to model factories, buildings, or outdoor constructions that have an important role in production or distribution processes.
13 | 14 |Facilities can be interconnected by Distribution Networks. Material can be accessed (e.g., created, used, stored, moved, or transformed) by Equipment. A Facility can serve other Facilities, and also Business Roles and Actors. Locations can be assigned to Facilities. A Facility can be composed of other Facilities and can be aggregated in a Location.
15 | 16 |The name of a Facility should preferably be a noun referring to the type of Facility.
17 | 18 |Physical. Active Structure.
20 | 21 |Oil refinery, Factory, Laboratory, Warehouse, Shopping Mall, Office.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/technology_service.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Technology Service represents an explicitly defined exposed technology behaviour.
11 | 12 |A Technology Service exposes the functionality of a Node to its environment. This functionality is accessed through one or more Technology Interfaces. It may require, use, and produce Artifacts.
13 | 14 |Typical Technology Services may, for example, include messaging, storage, naming, and directory services. It may access Artifacts; e.g., a file containing a message.
15 | 16 |A Technology Service may serve Application Components or Nodes. A Technology Service is realized by a Technology Function or Process. A Technology Service is exposed by a Node by assigning Technology Interfaces to it. A Technology Service may access Artifacts.
17 | 18 |The name of a Technology Service should preferably be a verb ending with "ing".
19 | 20 |Technology. Behavioural.
22 | 23 |Messaging Service, Customer File Service, Claim Files Service.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/junction.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Junction is used to connect relationships of the same type. A Junction may have multiple incoming relationships and one outgoing relationship, one incoming relationship and multiple outgoing relationships, or multiple incoming and outgoing relationships.
11 | 12 |The relationships that can be used in combination with a Junction are all the dynamic relationships, as well as Assignment, Realization, and Association. A Junction is used to explicitly express that several elements together participate in the relationship (and Junction) or that one of the elements participates in the relationship (or Junction).
13 | 14 |Ensure that only relationships of the same type are used to connect elements and Junctions.
15 | 16 |There are two types - And and Or.
17 | 18 |Other.
20 | 21 |An "assess application" Business Process can lead to a choice Junction (split) to accept or reject the client application and route to alternative processes for each case.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/application_interaction.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Interaction represents a unit of collective application behaviour performed by (a collaboration of) two or more Application Components.
12 | 13 |An Application Interaction describes the collective behaviour that is performed by the components that participate in an Application Collaboration. An Application Interaction can also specify the externally visible behaviour needed to realize an Application Service.
14 | 15 |An Application Collaboration may be assigned to an Application Interaction. An Application Interaction may realize an Application Service. Application Services and tTechnology Services may serve an Application Interaction. An Application Interaction may access Data Objects.
16 | 17 |The name of an Application Interaction should clearly identify a series of application behaviours.
18 | 19 |Application. Behavioural.
21 | 22 |Administrate transactions, Client profile creation, Update customer records
24 | 25 | -------------------------------------------------------------------------------- /docs/hints/business_interface.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Interface is a point of access where a Business Service is made available to the environment.
11 | 12 |The functionality provided by a Business Role is exposed to its environment by means of one or more Business Interfaces. Conversely, a Business Role may consume the functionality provided by other Business Roles via a Business Interface.
13 | 14 |A Business Interface specifies how the functionality of a Business Role can be used by other Business Roles, or which functionality the Business Roles requires from its environment.
15 | 16 |A Business Interface exposes a Business Service provided by a Business Role or Business Collaboration to its environment. A Business Service may also be exposed through different interfaces.
17 | 18 |The name of a Business Interface should preferably be a noun.
19 | 20 |Business. Active Structure.
22 | 23 |Telephone, Email, Call centre, Web Chat, Help Desk.
25 | 26 | 27 | -------------------------------------------------------------------------------- /docs/hints/business_role.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Role is defined as a named specific behaviour of a Business Actor participating in a given context. The actor performs the behaviour of the role.
11 | 12 |A Business Role can be fulfilled by more than one Business Actor. Conversely, a Business Actor may fulfil more than one Business Role. For example, given a named teacher, their roles may include those in the domains.
13 | 14 |A Business Role will usually exist in an organisation whether or not a given actor fulfils it or not.
15 | 16 |A Business Role may be assigned to one or more Business Processes or Business Functions. A Business Interface or an Application Interface may be used by a Business Role, while a Business Interface may be part of a Business Role (Composition relationship).
17 | 18 |The name of a Business Role should preferably be a noun.
19 | 20 |Business. Active Structure.
22 | 23 |Customer, Insurer, Supplier, Lecturer, Administrator, Buyer.
25 | 26 | 27 | -------------------------------------------------------------------------------- /docs/hints/system_software.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |System Software represents software that provides or contributes to an environment for storing, executing, and using software or data deployed within it.
11 | 12 |System Software is a specialization of a Node that is used to model the software environment in which Artifacts run. Usually, System Software is combined with a Device representing the hardware environment to form a general Node.
13 | 14 |A Device or System Software can be assigned to other System Software; e.g., to model different layers of software running on top of each other. System Software can be assigned to Artifacts, to model that these Artifacts are deployed on that software. System Software can realize other System Software. A Node can be composed of System Software.
15 | 16 |The name of System Software should preferably be a noun referring to the type of execution environment.
17 | 18 |Technology. Active Structure.
20 | 21 |DBMS, DB2 System Software, Message Queuing, Operating System, J2EE Application Server
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/data_object.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Data Object represents data structured for automated processing.
11 | 12 |A Data Object should be a self-contained piece of information with a clear meaning to the business, not just to the application level.
13 | 14 |A Data Object typically models an object type of which multiple instances may exist in operational applications.
15 | 16 |An Application Function or process can operate on Data Objects. A Data Object may be communicated via interactions and used or produced by Application Services. A Data Object can be accessed by an Application Function, Application Interaction, or Application Service. A Data Object may realize a Business Object, and may be realized by an Artifact. A Data Object may have Association, Specialization, Aggregation, or Composition relationships with other Data Objects.
17 | 18 |The name of a Data Object should preferably be a noun.
19 | 20 |Application. Passive Structure.
22 | 23 |Customer File Data, Insurance Policy Data, Insurance Request Data, Client Database.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/technology_collaboration.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Technology Collaboration represents an aggregate of two or more Nodes that work together to perform collective technology behaviour.
11 | 12 |A Technology Collaboration specifies which Nodes cooperate to perform some task. The collaborative behaviouris modeled by a Technology Interaction. A Technology Collaboration typically models a logical or temporary collaboration of Nodes, and does not exist as a separate entity in the enterprise.
13 | 14 |Technology Collaboration is a specialization of Node, and aggregates two or more (cooperating) Nodes. A Technology Collaboration may be assigned to one or more Technology Interactions or other technology internal behaviour elements, which model the associated behaviour. A technology interface may serve a Technology Collaboration, and a Technology Collaboration may be composed of Technology Interfaces.
15 | 16 |The name of a Technology Collaboration should preferably be a noun.
17 | 18 |Technology. Active Structure.
20 | 21 |E-Commerce Hosting.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/application_collaboration.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Collaboration represents an aggregate of two or more Application Components that work together to perform collective application behaviour.
11 | 12 |An Application Collaboration specifies which components cooperate to perform some task. The collaborative behavior, including, for example, the communication pattern of these components, is modeled by an Application Interaction. An Application Collaboration typically models a logical or temporary collaboration of Application Components, and does not exist as a separate entity in the enterprise.
13 | 14 |Application Collaboration is a specialization of Component, and aggregates two or more (cooperating) Application Components.
15 | 16 |The name of an Application Collaboration should preferably be a noun.
17 | 18 |Application. Active Structure.
20 | 21 |Two Application Components collaborate in transaction administration: an Accounting component and a Billing component. This collaboration performs the task "Administrate transactions".
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/application_component.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Component represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behaviour and data, exposes services, and makes them available through interfaces.
11 | 12 |An Application Component is a self-contained unit. As such, it is independently deployable, re-usable, and replaceable. An Application Component performs one or more Application Functions. It encapsulates its contents: its functionality is only accessible through a set of Application Interfaces. Cooperating Application Components are connected via Application Collaborations.
13 | 14 |An Application Component may be assigned to one or more Application Functions. An Application Component has one or more Application Interfaces, which expose its functionality.
15 | 16 |The name of an Application Component should preferably be a noun.
17 | 18 |Application. Active Structure.
20 | 21 |CRM System, Web portal, Financial Application, Customer Data Access.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/value.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |Value represents the relative worth, utility, or importance of a core element or an outcome.
11 | 12 |Value may apply to what a party gets by selling or making available some product or service, or it may apply to what a party gets by buying or obtaining access to it.
13 | 14 |Value may be expressed in terms of money, but non-monetary value is also essential to business - for example, practical/functional value (including the right to use a service), and the value of information or knowledge. Though Value can hold internally for some system or organisational unit, it is most typically applied to external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship.
15 | 16 |It is recommended to try and express the name of a Value as an action or state that can be performed or reached as a result of the corresponding service being available.
17 | 18 |Motivation
20 | 21 |Be insured, Improve relationship, Improve knowledge, Experience benefit of a product.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/capability.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Capability represents an ability that an active structure element, such as an organization, person, or system, possesses.
11 | 12 |A Capability focuses on business outcomes. It provides a high-level view of the current and desired abilities of an organization, in relation to its strategy and its environment. They are realized by various elements (people, processes, systems). Capabilities may also have serving relationships; for example, to denote that one capability contributes to another.
13 | 14 |Capabilities are expressed in general and high-level terms and are typically realized by a combination of organization, people, processes, information, and technology.
15 | 16 |Capabilities are typically aimed at achieving some goal or delivering value by realizing an outcome. Capabilities are themselves realized by core elements. To denote that a set of core elements together realizes a capability, Grouping can be used.
17 | 18 |Strategy. Behaviour.
20 | 21 |Digital Customer Management, Data Analysis, Product Management, Productise Open Source Software.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/vp_product.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Product viewpoint depicts the value that these products offer to the customers or other external parties involved and shows the composition of one or more products in terms of the constituting (business, application, or technology) services, and the associated contract(s) or other agreements. It may also be used to show the interfaces (channels) through which this product is offered, and the events associated with the product. A product viewpoint is typically used in product development to design a product by composing existing services or by identifying which new services have to be created for this product, given the value a customer expects from it. It may then serve as input for business process architects and others that need to design the processes and ICT realizing these products.
11 | 12 |Product developers, product managers, process and domain architects
14 | 15 |Product development, value offered by the products of the enterprise
17 | 18 |Designing, deciding
20 | 21 |Multiple layer/Multiple aspect
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/business_collaboration.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Collaboration is defined as a (possibly temporary) configuration of two or more Business Roles resulting in specific collective behaviour in a particular context.
11 | 12 |Unlike a single Business Role, a Business Collaboration does not necessarily have a permanent status in an organisation. Thus it may be a temporary collaboration. It may not require a special name and can be regarded as a "virtual" role.
13 | 14 |A Business Collaboration can occur when two or more Business Roles need to fulfil specific interaction requirements. Business Collaborations represent the collective effort of combined Business Roles.
15 | 16 |The name of a Business Collaboration should preferably be a noun.
17 | 18 |Business. Active Structure.
20 | 21 |The Business Roles of Sales Department and Advertising may form a temporary Business Collaboration in order to push a product to market.
23 | 24 |The Business Roles of Home Insurance Seller and Travel Insurance Seller may form a temporary Business Collaboration in order to form combined Insurance Selling service.
25 | 26 | 27 | -------------------------------------------------------------------------------- /docs/hints/business_interaction.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Interaction is defined as a unit of behaviour performed as a collaboration between two or more 11 | Business Roles.
12 | 13 |A Business Interaction is similar to a Business Process or Business Function, but while a process/function may be performed by a single role, an interaction is performed by multiple roles in collaboration.
14 | 15 |A Business Interaction may be triggered by, or trigger, any other business behaviour element (Business Event, Business Process, Business Function, or Business Interaction).
16 | 17 |A Business Interaction may access Business Objects.
18 | 19 |A Business Interaction may realize one or more Business Services and may use (internal) Business Services or Application Services.
20 | 21 |A Business Collaboration or an Application Collaboration may be assigned to a Business Interaction.
22 | 23 |The name of a Business Interaction should preferably be a verb in the simple present tense.
24 | 25 |Business. Behavioural.
27 | 28 |Formalise Request, Check and Sign Contract, Take out Combined Insurance.
30 | 31 | 32 | -------------------------------------------------------------------------------- /docs/hints/equipment.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |Equipment represents one or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
11 | 12 |Equipment comprises all active processing elements that carry out physical processes in which materials are used or transformed. Equipment is a specialization of the Node element. Therefore, it is possible to model nodes that are formed by a combination of IT infrastructure (devices, system software) and physical infrastructure (equipment); e.g., an MRI scanner at a hospital, a production plant with its control systems, etc.
13 | 14 |Material can be accessed (e.g., created, used, stored, moved, or transformed) by equipment. Equipment can serve other Equipment, and also Business Roles and Actors, and Facilities can be assigned to Equipment. A piece of Equipment can be composed of other pieces of Equipment. Equipment can be assigned to (i.e., installed and used in or on) a Facility and can be aggregated in a Location.
15 | 16 |The name of a piece of Equipment should preferably be a noun.
17 | 18 |Physical. Active Structure.
20 | 21 |MRI scanner, Assembly line.
23 | 24 | -------------------------------------------------------------------------------- /docs/hints/business_service.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Service exposes the functionality of Business Roles or Collaborations to their environment. This functionality is accessed through one or more Business Interfaces. It may access Business Objects.
10 | 11 |A Business Service is defined as the externally visible ("logical") functionality, which is meaningful to the environment and is realized by business behaviour (Business Process, Business Function, or Business Interaction).
12 | 13 |A Business Service exposes the functionality of Business Roles or Collaborations to their environment. This functionality is accessed through one or more business interfaces. A Business Service is realized by one or more Business Processes, Business Functions, or Business Interactions that are performed by the Business Roles or Business Collaborations, respectively.
14 | 15 |The name of a Business Service should preferably be a verb ending with "-ing"; e.g., "transaction processing". Also, a name containing the word "service" may be used.
16 | 17 |Business. Behavioural.
19 | 20 |Customer Information Service, Claims Payment Service, Enrolment Service.
22 | 23 | -------------------------------------------------------------------------------- /docs/hints/implementation_event.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Implementation Event is a behaviour element that denotes a state change related to implementation or migration.
11 | 12 |Work Packages may be triggered or interrupted by an Implementation Event. Also, work packages may raise events that trigger other behaviour. Unlike a Work Package, an event is instantaneous: it does not have duration.
13 | 14 |An Implementation Event may have a time attribute that denotes the moment or moments at which the event happens.
15 | 16 |Implementation Events access Deliverables to fulfil project objectives.
17 | 18 |An Implementation Event may trigger or be triggered (raised) by a Work Package or a Plateau. An Implementation Event may access a Deliverable and may be composed of other Implementation Events.
19 | 20 |An Implementation Event may be associated with any core element; e.g., to indicate a lifecycle state change.
21 | 22 |The name of an Implementation Event should preferably be a verb in the perfect tense.
23 | 24 |Implementation and Migration
26 | 27 |"Release to production", "Project initiation phase completed".
29 | 30 | -------------------------------------------------------------------------------- /docs/hints/business_function.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Function describes internal behaviour performed by a Business Role that is required to produce a set of products and services. It is performed by a single role within an organisation.
11 | 12 |Business Processes describe a flow of activities. Business Functions group activities according to their required skills, knowledge, and resources. A Business Process forms a string of Business Functions.
13 | 14 |A Business Function may be triggered by, or trigger, any other business behaviour element (Business Event, Business Process, Business Function, or Business Interaction).
15 | 16 |A Business Function may access Business Objects. A Business Function may realize one or more BusinessServices and may use (internal) Business Services or Application Services. A Business role or an Application Component may be assigned to a Business Function.
17 | 18 |The name of a business function should clearly indicate a well-defined behaviour.
19 | 20 |Business. Behavioural.
22 | 23 |Customer Management, Member Services, Recycling, Payment Processing, Financial Handling, Claims Processing, Asset Management, Maintaining Customer Relations.
25 | 26 | 27 | -------------------------------------------------------------------------------- /docs/css/model.css: -------------------------------------------------------------------------------- 1 | /* Setup html pages */ 2 | html { 3 | height: 100%; /* Needed for 'empty-element.html' */ 4 | } 5 | 6 | html.model > body { 7 | background:#ddd; 8 | padding: 10px; 9 | } 10 | 11 | html.frame > body { 12 | height: 100%; 13 | background:#ddd; 14 | /* padding: 15px; */ 15 | } 16 | 17 | /* ModelTree */ 18 | ul, li { 19 | list-style-type: none; 20 | cursor: default; 21 | } 22 | li.tree-element, ul{ 23 | padding-left: 20px; 24 | } 25 | 26 | /* jQuery UI Layout style */ 27 | .ui-layout-pane { 28 | padding: 0px; 29 | overflow: hidden; 30 | border: 0px solid #ddd; 31 | background: #ddd; 32 | } 33 | .ui-layout-resizer { 34 | border: 2px solid #ddd; 35 | } 36 | 37 | /* Force panels width/height */ 38 | .root-panel { 39 | height: 100%; 40 | overflow: hidden; 41 | background: #FFF; 42 | } 43 | .root-panel-body { 44 | /* height will be set though jQuery */ 45 | overflow: auto; 46 | } 47 | .no-padding { 48 | padding: 0px; 49 | } 50 | .no-margin { 51 | margin: 0px; 52 | } 53 | #doctgt { 54 | margin-top: 15px; 55 | margin-bottom: 15px; 56 | } 57 | .navbar { 58 | height: 100%; 59 | } 60 | 61 | /* iFrames are inside panel-body */ 62 | iframe { 63 | margin: 0px; 64 | padding: 0px; 65 | border: none; 66 | width: 100%; 67 | height: 100%; 68 | } 69 | 70 | p.centered { 71 | position: relative; 72 | top: 50%; 73 | transform: translateY(-50%); 74 | text-align: center; 75 | } 76 | 77 | .table-condensed th,td { 78 | font-size: 14px; 79 | } 80 | 81 | img.diagram { 82 | max-width: 100%; 83 | } 84 | 85 | xmp { 86 | font-family: "Helvetica Neue",Helvetica,Arial,sans-serif; 87 | } 88 | -------------------------------------------------------------------------------- /docs/hints/application_event.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Event is an application behaviour element that denotes a state change.
11 | 12 |Application Functions and other application behaviour may be triggered or interrupted by an Application Event. Also, application behaviour may raise events that trigger other application behaviour. An event is instantaneous; it does not have duration. Events may originate from the environment of the organization (e.g., from an external application), but also internal events may occur generated by, for example, other applications within the organization.
13 | 14 |An Application Event may have a time attribute that denotes the moment or moments at which the event happens. For example, this can be used to model time schedules; e.g., an event that triggers a daily batch process.
15 | 16 |An Application Event may trigger or be triggered (raised) by an Application Function, Process, or Interaction. An Application Event may access a Data Object and may be composed of other Application Events.
17 | 18 |The name of an Application Event should preferably be a verb in the perfect tense.
19 | 20 |Application. Behavioural.
22 | 23 |Claim received, Request for quotation.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/vp_business_process_cooperation.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Business Process Cooperation viewpoint is used to show the relationships of one or more business processes with each other and/or with their environment. It can both be used to create a high-level design of business processes within their context and to provide an operational manager responsible for one or more such processes with insight into their dependencies. Important aspects of business process cooperation are:
11 |Each of these can be regarded as a "sub-viewpoint" of the business process cooperation viewpoint.
18 | 19 |Process and domain architects, operational managers
21 | 22 |Dependencies between business processes, consistency and completeness, responsibilities
24 | 25 |Designing, deciding
27 | 28 |Multiple layer/Multiple aspect
30 | 31 | -------------------------------------------------------------------------------- /docs/hints/application_service.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |An Application Service represents an explicitly defined exposed application behaviour.
11 | 12 |An Application Service exposes the functionality of components to their environment. This functionality is accessed through one or more Application Interfaces. An Application Service is realized by one or more Application Functions that are performed by the component. It may require, use, and produce Data Objects.
13 | 14 |An Application Service should provide a unit of behaviour that is, in itself, useful to its users. It has a purpose, which states this utility to the environment.
15 | 16 |A Purpose may be associated with an Application Service. An Application Service may serve Business Processes, Business Functions, Business Interactions, or Application Functions. An Application Function may realize an Application Service. An Application Interface may be assigned to an Application Service. An Application Service may access Data Objects.
17 | 18 |
The name of an Application Service should preferably be a verb ending with "ing". Also, a name explicitly containing the word "service" may be used.
19 | 20 |Application. Behavioural.
22 | 23 |Transaction Processing, Payment Service, Customer Admin Service.
25 | 26 | -------------------------------------------------------------------------------- /docs/hints/business_event.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |A Business Event is defined as something that happens (internally or externally) and influences behaviour (Business Process, Business Function, Business Interaction).
11 | 12 |Business Processes and other business behaviour may be triggered or interrupted by a Business Event.
13 | 14 |Also, Business Processes may raise events that trigger other Business Processes, Functions, or Interactions. A Business Event is most commonly used to model something that triggers behaviour.
15 | 16 |Unlike Business Processes, Functions, and Interactions, a Business Event is instantaneous: it does not have duration. A Business Event may have a time attribute that denotes the moment or moments at which the event happens.
17 | 18 |Events may originate from the environment of the organization (e.g., from a customer), but also internal events may occur generated by, for example, other processes within the organization.
19 | 20 |A Business Event may trigger or be triggered (raised) by a Business Process, Business Function, or Business Interaction.
21 | 22 |A Business Event may access a Business Object and may be composed of other Business Events.
23 | 24 |The name of a Business Event should preferably be a verb in the perfect tense; e.g., "claim received".
25 | 26 |Business. Behavioural.
28 | 29 |Request for Insurance, Claim Received, Application Form Received, Send Product Portfolio.
31 | 32 | -------------------------------------------------------------------------------- /docs/hints/vp_layered.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 |The Layered viewpoint pictures several layers and aspects of an Enterprise Architecture in one diagram.
11 | 12 |There are two categories of layers, namely dedicated layers and service layers. The layers are the result of the use of the "grouping" relationship for a natural partitioning of the entire set of objects and relationships that belong to a model. The technology, application, process, and actor/role layers belong to the first category. The structural principle behind a fully layered viewpoint is that each dedicated layer exposes, by means of the "realization" relationship, a layer of services, which are further on "serving" the next dedicated layer.
13 | 14 |Thus, we can easily separate the internal structure and organization of a dedicated layer from its externally observable behavior expressed as the service layer that the dedicated layer realizes.
15 | 16 |The main goal of the layered viewpoint is to provide an overview in one diagram. Furthermore, this viewpoint can be used as support for impact of change analysis and performance analysis or for extending the service portfolio.
17 | 18 |Enterprise, process, application, infrastructure, and domain architects
20 | 21 |Consistency, reduction of complexity, impact of change, flexibility
23 | 24 |Designing, deciding, informing
26 | 27 |Multiple layer/Multiple aspect
29 | 30 | -------------------------------------------------------------------------------- /docs/js/imageMapResizer.min.js: -------------------------------------------------------------------------------- 1 | /*! Image Map Resizer (imageMapResizer.min.js ) - v1.0.3 - 2016-06-16 2 | * Desc: Resize HTML imageMap to scaled image. 3 | * Copyright: (c) 2016 David J. Bradshaw - dave@bradshaw.net 4 | * License: MIT 5 | */ 6 | 7 | !function(){"use strict";function a(){function a(){function a(a,c){function d(a){var c=1===(e=1-e)?"width":"height";return Math.floor(Number(a)*b[c])}var e=0;i[c].coords=a.split(",").map(d).join(",")}var b={width:k.width/k.naturalWidth,height:k.height/k.naturalHeight};j.forEach(a)}function b(a){return a.coords.replace(/ *, */g,",").replace(/ +/g,",")}function c(){clearTimeout(l),l=setTimeout(a,250)}function d(){(k.width!==k.naturalWidth||k.height!==k.naturalHeight)&&a()}function e(){k.addEventListener("load",a,!1),window.addEventListener("focus",a,!1),window.addEventListener("resize",c,!1),window.addEventListener("readystatechange",a,!1),document.addEventListener("fullscreenchange",a,!1)}function f(){return"function"==typeof h._resize}function g(){i=h.getElementsByTagName("area"),j=Array.prototype.map.call(i,b),k=document.querySelector('img[usemap="#'+h.name+'"]'),h._resize=a}var h=this,i=null,j=null,k=null,l=null;f()?h._resize():(g(),e(),d())}function b(){function b(a){if(!a.tagName)throw new TypeError("Object is not a valid DOM element");if("MAP"!==a.tagName.toUpperCase())throw new TypeError("Expected