Application | QualiWare Center of Excellence

Component Diagram

Purpose: The purpose of the Component Diagram is to specify the structure of and dependencies among the different components that make up a system.

Core concerns: The Component Diagram template enables you to model a system’s Components, Classes, Interfaces, Packages, Artifacts and Ports. They can be connected by Dependency, Interface Realization, Component Realization, Usage, Generalization or a generic Connector. Below, you can see an example of a simple Component Diagram consisting of Components connected by Dependencies.

Using the properties dialogue, you can identify extensions such as Stereotype, Constraints and Tagged values:

Relation to other templates: The Component Diagram is part of the Application domain and shows how a system is structured. To model how users interact with a system you should use a Use Case Diagram, to model how interactions with the system through processes you should use the Sequence Diagram template. To model the structure of an application landscape you should use the Application Architecture Diagram.

Properties and metadata: The Component Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Component Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Communication Diagram

Purpose: The purpose of the Communication Diagram template is to document interactions between objects or parts, focusing on sequenced messages.

Core concerns: The Communication Diagram template is a simplified UML 2.0 alternative to the UML Collaboration Diagram. It enables you to model Lifelines and Annotation, which can be connected by messages.

Below you can see a simple example of a Communication Diagram:

Relation to other templates: Usually, Communication Diagrams would be modeled using information from Class Diagram, Sequence Diagram, and Use case diagram. It is related to the other UML interaction diagrams: Sequence Diagram, Interaction overview diagram and Timing Diagram.

While the Communication Diagram show much of the same information a Sequence Diagram does, the Communication Diagram conveys which elements each one interacts with better, while sequence diagrams show the order in which the interactions take place more clearly.

Other UML diagrams that QualiWare support include: Activity Diagram, Communication Diagram, Deployment Diagram, , Composite Structure Diagram, State Diagram, Package Diagram, Component Diagram, Composite structure Diagram, and Object Diagram.

Properties and metadata: The Communication Diagram can for example retain the following information:

A description of the diagrams
Link to related sequence diagram
Extensions (Stereotype, Constraints and Tagged values)
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Communication diagram, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: about the UML, please visit the Object Management Group’s Website, where you can find the complete specification.

Class Diagram

Purpose: The primary objective of the Class Diagram template is to visually represent and document the structural components of a system utilizing the Unified Modeling Language (UML). Displayed below is an example of a straightforward Class Diagram:

Core concerns: The Class Diagram effectively captures the various classes within a system, their attributes, operations, and the relationships between classes and other objects, such as packages. This comprehensive representation enables a clear understanding of the system’s structure, promoting efficient communication among stakeholders and facilitating system design and maintenance.

Example: In the Class Diagram below, the relationships between the classes “Customer” and “Internet User” and the packages “WEB-API”, “Reservation Control”, “GUI” (Graphical User Interface), and “Database” are illustrated. This example highlights the connections among different components and provides a visual overview of how they interact within the system:

Relation to other templates: The Class Diagram presents a detailed structural view of information. It can for example be a decomposition of an Information System which typically is presented in an Application Architecture Diagram. If a Class Diagram becomes too complex or large, a Package Diagram, where the classes are grouped into Packages, could be modelled instead.

Properties and metadata: The Class Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the diagram
Audits (auto generated information regarding its current state and access rights)
Extensions regarding constraints and tagged values
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

In the picture below you can see the Class Diagrams properties dialogue window, where the information can be viewed and edited:

Application Usage Viewpoint : Archimate

Purpose: Designing, deciding

Concerns: Consistency and completeness, reduction of complexity

Scope: Multiple layer/Multiple aspect

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.

Abstraction Level
Coherence

Layer
Business and application layers

Aspects
Behavior, active structure, passive structure

Application Platform Viewpoint : ArchiMate

Scope: Multiple layer/Multiple aspect

Shows structure of a typical application platform and how it relates to supporting technology.

Application Functionality Context

Purpose: The purpose of the Application Functionality Context template is to document the in which Activities and/or Business Processes a given Application Functionality is used.

Core concerns: The Application Functionality Context template can be used to create graphical views showing where Application Functionalities are used. The template enables you to model Application Functionalities, Activities and Business Processes. The Business Processes and Activities are connected to Application Functionalities using Functionality Usage.

Below, you can see an example of an Application functionality contest diagram, where the context for the DocCom – Create and Store Document functionality is shown:

The diagram shows which Business Processes use the Application Functionality as well as which Information System delivers it.

Relation to other templates: To map applications hardware, the Application Architecture Diagram or Infrastructure Diagram template should be used. The Application Functionality Context template graphically connects functionalities of Information Systems to the Processes and Activities in which they are used. It offers an additional view to Application Architecture Diagrams, Workflow Diagrams, Business Process Diagrams and Business Process Networks.

Properties and metadata: The Application Functionality Context template can for example retain the following information:

A description of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Application Functionality Context template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Organization Viewpoint : Archimate

Concerns: Identification of competencies, authority, and responsibilities
Purpose: Designing, deciding, informing
Scope: Single layer/Single aspect

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.

Product Viewpoint : Archimate

Concerns: Product development, value offered by the products of the enterprise
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect

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.

Application Cooperation Viewpoint : Archimate

Concerns: Relationships and dependencies between applications, orchestration/choreography of services, consistency and completeness, reduction of complexity
Purpose: Designing
Scope: Multiple layer/Multiple aspect

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.

Abstraction Level
Coherence, details

Layer
Application layer

Aspects
Behavior, active structure, passive structure

Implement Deployment Viewpoint :ArchiMate

Concerns: Structure of application platforms and how they relate to supporting technology
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect

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.