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.
A technology service should be meaningful from the point of view of the environment; it should provide a unit of behavior that is, in itself, useful to its users, such as application components and nodes.
Typical technology services may, for example, include messaging, storage, naming, and directory services. It may access artifacts; e.g., a file containing a message.
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. A technology service may consist of sub-services.
The name of a technology service should preferably be a verb ending with “ing”; e.g., “messaging”. Also, a name explicitly containing the word “service” may be used.
Template Type: Symbols
Text Annotation
The Text Annotation template in QualiWare permits the user to add an object where any amount of text can be included on the diagram to support what is going on with one Activity, or other BPMN based template. The Text field on the Text Annotation tab in the Object Editor is where the text is entered and upon saving and closing the object editor, the text will appear on the diagram within the Text Annotation object. The Text Annotation is then linked to the applicable Activity or other object using the Association symbol/connector.
Actor
Someone or something that interacts with the system. The Unified Modeling Language (UML) specifies an Actor as a role played by a user or any other system that interacts with the subject.
An Actor is represented by a “stick man” icon with the name of the Actor in the vicinity (usually above or below) the icon.
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems.
An Actor does not necessarily represent a specific physical entity but instead a particular role of some entity that is relevant to the specification of its associated UseCases. Thus, a single physical instance may play the role of several different Actors and, conversely, a given Actor may be played by multiple different instances.
The term “role” is used informally here and does not imply any technical definition of that term found elsewhere in this specification.
When an Actor has an association to a UseCase with a multiplicity that is greater than one at the UseCase end, it means that a given Actor can be involved in multiple UseCases of that type. The specific nature of this multiple involvement depends on the case on hand and is not defined in the UML specification. Thus, an Actor may initiate multiple UseCases in parallel (concurrently) or at different points in time.
Activity State
An activity state is a symbol representing some action to be carried out as part of a process.
Activity
An activity is a work process that is carried out by the organization. Activities can be defined at a high abstraction level where they constitute business guidelines or top-level business structures. Activities can also be working procedures or even work instructions at a low level of abstraction. Using ‘BreaksDownTo’ functionality a total description of the workstructure of an organization can be created, starting from the strategic level, going down through the tactical level to the operational level.
Activies appear among other in WorkFlowDiagrams and BusinessProcessDiagram. In this case the activities are part of a documented workprocess, where different parts of the organization plays different Role.
A BusinessDiagram or a BusinessProcessNetwork will often show the structure of the work, whereas a WorkFlowDiagram will show the flow of the work – sequence of activities, conditions etc., like a flowchart. When activites are used on a WorkFlowDiagram the purpose will often be to simulate the described business process in order to improve it. Therefore, activity information like duration, cost, iteration and uncertainties are essential.
Control Activities
The Activity can, under its risk tab, be defined as a Control or a Key Control. Here, you can also add information about Control type, mode, frequency and monitoring:
The control type of the activity can be set as either preventive (minimize the likelihood of a given risk occurring), or detective (minimize the impact when the risk occurs). A Control Activity is typically created from the Risk template (under its control tab in its properties) as a backwards relation.
The Control Activity may be enriched by linking Control Coverage, Influences (that may consist of Accounts or Financial Statements) Evaluations, Control Deficiencies, Assertions and COSO Categories to it. Below, you can see how the Control Activity relates to the Risk and other relevant templates:
Arrows that point away from the Control Activity are items the Activity link to. Arrows that point towards the Control Activity illustrate that it is the objects that link to the activity. The Control Activity should be inserted into the Workflow Diagram or Business Process Diagram where it belongs. This could be in the workflow where the risk occurs or it could be in a separat Workflow Diagram.
Trend
Convergence toward a certain preference.
User Label
An actual label.