Manual Architect

Tool Manual Architect
Architect BiZZdesign B.V. February 2006
BiZZdesign Architect is ArchiMate compliant, approved by Telematica Instituut. ArchiMate is a registered trademark of Telematica Instituut.
ii
BiZZdesign B.V.
Preface Adapting swiftly and flexibly to changing client needs is a primary goal for many organisations. The impact on product, process, organisation, application and infrastructure can be huge, and needs to be estimated upfront. Increasingly, Enterprise Architecture is seen as a solution for architecting and designing an organisation. Key in such an architecture is the company-wide scope, and the interrelatedness of the various models, instead of isolated, technological architectures. Communication with different stakeholders is important, both from the business perspective, as from the IT-perspective. Moreover, with an architecture one may be able to answer questions like what impact do changes in the business domain have on domain X?. Not only modelling and reporting of separate architectures is important, but adequate presentation and visualisation of relations between different architecture domains is what counts. Architect is a tool environment supported by methodology, consultancy, and training, that supports these requirements. The tool focuses on modelling architectures, and visualising and analysing the relations and coherence between the different architectural domains. This document is the tool manual for BiZZdesign Architect . BiZZdesign B.V. (www.BiZZdesign.com) is an innovative consultancy and tools firm on the area of innovation, analysis, design and realization of business processes. BiZZdesign advises and helps customers to improve and innovate their business processes and organization. BiZZdesign distinguishes itself by designing business processes very clear and accessible despite of the complexity of the processes while still addressing all major aspects (COPAFIJTH-wide). Business processes are designed from a customers' perspective. Future developments are also well accounted for. BiZZdesign follows an integral and well-documented approach to change. Starting from the mission and targets of a company, the processes and organization is being designed and realized. BiZZdesign is a spin-off company of the Telematica Instituut on the basis of the results of the Testbed-project. Between 2002 and 2004, Telematica Instituut has been active in the Archimate-project. BiZZdesign has participated within Archimate as a tool vendor. The project aimed at developing a uniform language for modelling Enterprise Architecture, accompanied with fine-tuned visualisation techniques. The resulting language and innovations are supported by BiZZdesign through its Archimate tool. BiZZdesign continuously innovates its products and services in close collaboration with clients, partners, Telematica Instituut, and Dutch universities.
Architect
BiZZdesign B.V.
iii
Table of contents
Table of contents 1. About this manual
1.1 1.2 Symbols and Styles Remarks, questions and bugs
1 5
5 6
2. Installing Architect
2.1 2.2 2.3 2.4 2.5 System requirements Installation Licence keys Architect editions Support
7
7 7 8 11 12
3. Modelling in Architect
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 The Start Input and Output The model browser and the view browser Drawing and adding objects Drawing relations Generating views Total view Views in views Documentation and references Profiles and Properties
BiZZdesign B.V.
13
13 15 17 20 26 30 31 33 34 37
1
Architect
3.11 Tables 3.11.1 Property table 3.11.2 Cross reference tables 3.11.3 Translation table 3.11.4 Link table 3.12 3.13 3.14 3.15 3.16 Collapsing and expanding objects Graphical Settings Searching Application settings Re-use of BiZZdesigner models
39 39 41 42 43 44 46 47 48 49
4. View filters
4.1 4.2 4.3 4.4 4.5 4.6 Label View Tooltip view Colour view Compare view Hide view Derived relations
51
51 52 53 54 54 55
5. Team-support
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Input and output of shared models Changing a shared model Team properties Check-out Check-in Undo check-out Undo check-out unchanged Synchronize Revisions
59
60 60 63 64 64 66 66 66 67
BiZZdesign B.V.
5.10 5.11 5.12
Collaboration view Team settings Profiles
68 69 70
6. Repository
6.1 6.2 6.3 6.4 6.5 Repository server and repository Creating a repository Opening a repository Repository browser Roles and rights
71
71 71 71 76 78
7. Reporting and printing

7.1 General settings 7.1.1 HTML-settings 7.1.2 RTF settings 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 Report location Contents report Diagrams Profiles Tables Reports to word processors Team Reports to intranet Printing of models
84
84 88 93 95 95 96 96 98 99 99 101 103
Appendix A Profiles
Introduction Necessary files The mpd-file The mps-files
Architect BiZZdesign B.V.
105
105 105 106 112
3
Location of the files Application settings Personal and group profiles Changing the standard profile
114 114 115 115
Appendix B Documentation fields

Introduction Necessary files The mpd-file The mps-files Application Settings Personal- and group profiles Changing the standard profile
117
117 117 118 119 119 120 121
Appendix C Object types and relation types

Domain independent object types Domain specific object types Relation types
123
123 123 124
Appendix D Interface BiZZdesigner - Architect

Domain independent object types Domain specific object types Relation types
125
125 125 127
Index
129
BiZZdesign B.V.
1. About this manual

This tool manual describes the functionality of Architect . Modelling concepts and methods for modelling, analysing, and visualising architecture are described extensively in the BiZZdesign Architect Handbook. BiZZdesign supports both the use of tools and methods with an extensive training program. This manual refers several times to ArchiMate. ArchiMate is a registered trademark of Telematica Instituut. Based on the ArchiMate-project BiZZdesign has developed the tool Architect supporting the concepts and views of ArchiMate. BiZZdesign Architect is ArchiMate compliant, approved by Telematica Instituut. More information on ArchiMate can be found in the documents accompanying the tool and at http://archimate.telin.nl.
1.1 Symbols and Styles

In this manual we use different styles to emphasise specific parts of the content. These styles support you in using this manual and finding certain topics.
Quick identification
For quick identification of important parts of the text we use keywords. These keywords direct you when you are looking for information on a particular subject. Of course the table of contents and the index can also be the startingpoint for your search. Important observations are printed in a grey box:
All important observations can be recognised like this.
This manual shortly describes how to use Architect . We assume that the reader has knowledge on the ArchiMate language and techniques. A short summary of all functions is available in the quick reference to Architect , a short summary of concepts is available in the quick reference on concepts and notation; please contact your application administrator. More information on functions is available through the Architect Handbook. We expect the reader to be familiar with Microsoft Windows. This manual describes several examples from the example model Archisurance. The model and the associated profiles can be found in the folders Examples respectively Examples/LAC2004 within Architect s installation folder. Sections 3.2 and 3.15 describe how to load this model, respectively how to configure the associated profiles in Architect .
Architect
BiZZdesign B.V.
1.2 Remarks, questions and bugs

For support on Architect you can contact the helpdesk via e-mail on helpdesk@BiZZdesign.com. To use this service you should have a support contract with BiZZdesign. If you cannot send e-mail, you can fax of mail your remark or question to BiZZdesign B.V. Helpdesk Architect P.O.Box 321 7500 AH ENSCHEDE The Netherlands Tel: +31 53 4 878 171 Fax: +31 53 4 878 161
BiZZdesign B.V.
2. Installing Architect
2.1 System requirements
Architect can be used in a Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP environment. To install Architect , it is necessary to have administrator rights on the PC. Architect requires the following configuration: - Pentium CPU, minimum 133 Mhz. - 128 MB internal memory - 60 MB available hard disk space - Graphical card with a minimum of 16-bit colour The above mentioned configuration is a minimum configuration. When using the (very) big models, Architect will work more comfortable with 256 MB or more internal memory.
2.2 Installation
To install Architect proceed as follows: 1. Insert the CD in the CD-ROM drive. 2. Open Windows Explorer and select your CD-ROM drive. 3. Start setup.exe. 4. Follow the instructions on your screen. If you downloaded the software from internet, execute the downloaded file. This will extract the files necessary for the installation procedure. Remember where you extracted the files and run setup.exe from that location. The default folder for Architect is C:\Program Files\BiZZdesign\Architect . Another folder can be selected if necessary. The installation includes helpfiles (folder Html), examples (at Examples) and Icons (at Icons). During the installation the following actions are executed: A Program group, with an icon for Architect . This icon will also be placed on the desktop. File association to the file type .xma is created for Architect File association to the file type .sma is created for Architect
Architect
BiZZdesign B.V.
Note that the file association to the file type .sma only applies if you have purchased the license Team-support. Network installation requires the same steps as a local PC installation (see steps above), with the exception that a network drive can be chosen as the destination folder. The files will be placed on the concerning drive (only if they are not already situated there). Without problems, the installation procedure can be executed from the network drive instead of the CD. For the use of Architect , installation of a recent version of Microsoft Common Controls is required. When not installed, Architect signals an error at startup. Run 40comupd.exe from the installation CD under Unsupported\commctrl, to solve this problem An internetbrowser, which supports frames, JavaScript and style sheets, like Internet Explorer version 5 or higher, is required for viewing generated reports. Part of the additional help files are in PDF (Portable Document Format). To access these, you need to have Acrobat Reader version 4 or higher. If necessary you can install it from the folder Unsupported\AcrobatReader.
Language Settings
Under Windows NT it is possible to set the language for Architect by choosing the right language via Settings Control Panel Regional Settings. Architect will now start in the right language (when your licence allows this). Right now English and Dutch are supported. Under Windows 95/98/2000/XP you can only influence the language of Architect specific terms via Settings Control Panel Regional Settings. The language of various dialog screens is dependent on the version of Windows being used. When you use a Dutch version of Windows the dialogs will also appear in Dutch, when you use an English version, the dialogs will be shown in English. After starting Architect it is possible to show tips to the user. The tips which are used, are located in the file tips.txt, in the folder ..\data\nls\nl and ..\data\nls\en (a Dutch version and an English version). You can change this file, e.g. to add tips specific to your organization.
Tips
2.3 Licence keys

Installation of Architect is restricted in the licence agreement. You should have a valid licence key in order to use Architect . This software licence key is specific for the PC on which Architect is installed. One of the following possibilities applies: You make use of an Architect demonstration version. After start-up choose Continue. This version will function for 30 days, and Architect is ready for use immediately. You need to request an individual licence key yourself; this procedure will be described in this manual.
BiZZdesign B.V.
You can join an existing network licence; pleae contact your application administrator. You are working in an organisation in which licence keys are not required or where the licence key is prepared for use; in this case you may skip the rest of this section and start directly using Architect .
First Install
When installing Architect for the first time on a computer, it generates a trial licence. This trial licence is valid for 30 days. First, you will be requested to specify the folder where the licensing information will be stored. You can change this folder if desired. Choose Ok to proceed.
During these 30 days you can use Architect in its full functionality. Every time Architect is started, a reminder will be given notifying the number of days remaining. All next times you start Architect choose Continue.This trial version of Architect can be installed once on a computer. Within these 30 days you should obtain your licence key from BiZZdesign. In some cases the trial period can be extended. If the trial period has expired you will get the following notification.
Licence keys and Reference codes
Licence keys provided by BiZZdesign, are computer-specific. This means that a licence key is valid for just one computer, and cannot be used on a different computer. To create a licence key, BiZZdesign needs a specific code from your computer, the so-called reference code. If you want to change or renew your licence, you should give this reference code to BiZZdesign, for instance by email or via the website of BiZZdesign (www.BiZZdesign.com or www.BiZZdesign.nl).
Architect BiZZdesign B.V. 9
The reference code is generated on the basis of computer-specific information (including hard disk and network card) and time-specific information. An example of a reference code is:
2566-0632-3400-4930-0144-7732
Depending on the generated licence key, the reference code can change. Only the first four sets of digits will be the same for a specific computer. A licence key is generated with the reference code. An example of a generated licence key is:
4106-7574-3447-2310-2171-8181-1349-3969-5226-0644
Given the number of digits it is easier to exchange both reference code and licence key electronically, using e-mail and Copy and Paste
Register new licence
To register a new licence, you should: 1. Send the reference code to BiZZdesign 2. Receive the licence key from BiZZdesign 3. Register the licence key. If you have a trial version of Architect , starting Architect results in the screen as shown on the previous page. After choosing Register you will see the following screen:
Obtain a licence key
If Architect is already started, you can also get to this screen via
Help About Architect More Licence Info... Enter New Licence...
The reference code is shown in this screen. If you have an Internet connection, the hyperlink brings you to the website of BiZZdesign, and your reference code is automatically pasted in the web form. With this form you can request a licence key. This is the fastest method. If you do not have an Internet connection, but
10
BiZZdesign B.V.
only e-mail, you can copy the reference code (using copy and paste) in an e-mail, and sent it to helpdesk@BiZZdesign.nl. If you do not have e-mail, you can send your licence request by fax or mail to BiZZdesign. Since processing your licence request takes some time, you can close this dialog by choosing Cancel. If your trial licence of Architect is still valid, you can continue working with it, while your licence-application is processed at BiZZdesign.
Register licence key
After receiving your licence key, you can open the licence dialog in the same way as before (as during the request of the key). You can enter the licence key (including the hyphens) in the corresponding field. Using copy and paste will prevent type errors.
2.4 Architect editions

The following add-ons are available for Architect:
Add-on (license) Team-support OLEDB Repository Functionality Multi-user support History and labelling Physical storage in file with sma-format Client-access to repositoryserver with OLEDB interface Repositorymanagement, a.o. models structuring Physical storage of shared models in repository Roles and rights Security (*)
Besides the add-ons mentioned above the add-on Extended languages is available. If you would like to make use of this add-on, please contact BiZZdesign. This manual describes all functionality to its full extend. If a specific function only applies if a specific dd-on is available, it will be indicated at the beginning of a section in the following way: ONLY AVAILABLE WITH THE ADD-ON TEAM-SUPPORT It depends on the license purchased by your company which add-ons are available to you. In
Help About Architect
you find which Architect editions you are using. If desired Architect can also be configured to start without certain licensed functions, or to use specific add-ons that you normally do not use (only if it is allowed by the license). This could be useful if you do not offer all functionality in the same way to all users. To start Architect in a custom way you type in the run dialog (start
Architect parameter run). The following parameters can be used:
Architect
BiZZdesign B.V.
11
-team -oledbrepository -alladdons -noaddons
start with team-support start with oledb repository-support start with all add-ons start wihout add-ons
The parameters can be preceded by a slash and a hyphen (for example Architect
team and Architect /team have the same effect).
2.5 Support
Contact BiZZdesign via email (helpdesk@BiZZdesign.nl) for support on using Architect . Your organization must have a support contract in order for you to be able to use this service. On our internetsite http://www.BiZZdesign.nl/support you will find frequently asked questions, a user group and information about product upgrades In the html folder of the installation destination (standard C:\Program Files\BiZZdesign\Architect \html ) you can find the file bugreprt.htm. This is a form to report bugs and productwishes. You can send the form by email to helpdesk@BiZZdesign.nl. When you are not able to send emails, you can also print the form and send it by fax or regular mail.
12
BiZZdesign B.V.
3. Modelling in Architect
Architect is based on the architecture language developed in the ArchiMate project. For backgrounds on models, concepts, and views we refer to the documents accompanied with the tool, and to the BiZZdesign Architect Handbook. These documents can be accessed by means of Help Help overview.
3.1 The Start

When you start Architect a window appears with of a menu at the top, a number of button bars and a status bar at the bottom. In the status bar Architect reports results, such as the progress of processes and errors. Also the objects coordinates are displayed. At the left there are the model browser, the view browser and the property window.
On start-up, a new architecture model including a total view is created automatically. When you open an existing model, the unused new model will be closed.
Button bar
Several toolbars with all kinds of buttons are available. There are buttons for opening and saving models, drawing models, zooming in and out on a diagram,
Architect
BiZZdesign B.V.
13
documentation lay out, toggling the grid on and off, aligning objects and so on. Using the right mouse button you can specify the button bars that have to be shown, and which buttons should be on the bar. You can remove the model browser, the property window, or the documentation window from the screen with the buttons on the button bar. These windows can be placed over or besides each other. All bars, diagrams, and fields can be dragged and resized in the usual way for Windows applications. With the options under Window you can reorganise the diagram windows, for example cascade or tile.
Help function
Under
Help Help Topics
you will find the help documentation of Architect and the complete contents of this tool manual in two formats: pdf and Windows help.
PDF
The tool manual in pdf-format can be viewed using Acrobat Reader. Searching for a keyword can be done by looking up this keyword in the index (using the bookmarks column). Via Cntr-N you can jump to the relevant page. You can also search on keywords using Cntr-F. The tool manual in Window help-format offers an easy search-and-find possibility.
Windows help
14
BiZZdesign B.V.
3.2 Input and Output

Saving a model
You can save a model under a (new) name via the menu
File Save as
Architect saves a model in the so-called XML-format with extension .xma.

Tip: If you do not specify an extension, Architect chooses the default extension .xma, so that you can easily recognise the file as a model made with Architect .
Once you have saved the model, you can resave the (modified) model under the same name via de menu option
Save or through Ctrl+S. Architect saves a version of the model every five minutes (autosave), under the model name with the extension .autosave. This autosave file is placed in the temporary Windows folder, usually C:\Documents and Settings\<user name>\Local Settings\temp or C:\temp, and is deleted when you exit File
Architect . The interval at which an autosave file is made can be determined via Options Application settings.
Tip: When Architect crashes, the latest modifications can be recovered from the autosave file. Choose all files in File Open as file type in that case. Opening a model
A saved file can be re-opened later on in Architect through the menu

File Open or via Ctrl+O. Using the mark Open file as Read-only you indicate that the model
shall be opened for reading; you will not be able to edit the model. When you save a model Architect automatically generates a back-up of the original file, with the extension .bk1. Hence, you can always recover an older model version.
Working directory Empty start Recent models
Under Options Application settings you can enter a default working directory. Architect starts searching for models in this directory. Through this menu you can also arrange that Architect starts empty, i.e., without creating a new model. The models most recently used, can be opened directly from the list at the bottom of the File menu. When you wish to print a model use the menu
Print Preview. Choose whether you wish to print the whole model, only the diagram in use, or a selection of the model. More information on printing is available in section 7.10. File Print... or Ctrl+P. You can preview your print using File
Printing
Team-support
If the add-on Team-support is available models can be saved (and editted) within a file with extension .sma, allowing several users to edit the model simultaneously. Chapter 5 describes this feature in more detail.
Repositorysupport
If the add-on Repository (OLEDB) support is available, you can save models in and open from a repository. You open the models using the Repositorybrowser, instead of the File dialog. Chapter 6 describes this feature in more detail
16
BiZZdesign B.V.
3.3 The model browser and the view browser

Several models at In Architect you can work on several models at the same time. When you open a a time model or create a new model, the name of this model is added to the model
browser. This browser has the same working characteristics as well-known programs such as Windows Explorer or File Manager. The model browser shows the contents of a model, that is, the (semantical) objects that are contained within a model. By clicking on objects in the browser you can, for instance, see the objects that constitute the model, and which properties are available for the object you selected in the Properties window. On the other hand, the view browser shows the view (diagrams) of each model. Each view is, as its name implies, a particular view on the underlying (semantical) model.
The model browser shows a list of all open models. The little red asterisk on a model indicates that this model was changed, but that the modifications have not been saved yet. By clicking a selected view or model in the browser, you can alter its name. Changing names is also possible using the F2 key, through clicking the right mouse button on the selected diagram or model. It is useful to give meaningful names to models and diagrams, for example Organisation Structure Archisurance.
Several schemes and several views
A model consists of different types of objects. These are grouped in the model browser under different types of schemes. Examples are the schemes business processes, business actors, and business products. You can add an arbitrary number of new objects to each scheme using context menu New or New Multiple. In this way, you can also add new schemes.
An object in the model browser is not directly placed in a view, and is not (yet) directly visible in a view. Only after you have placed an object in a view, it becomes visible.
Objects in the model browser may be placed in a view by drag-and-drop of the selected object(s). Doing so creates a reference to the (semantical) object. A
graphical object may thus be dragged onto different views, all creating different references to the same underlying object. Besides various schemes, a model typically contains several views. You create views via the context menu on a model in the view browser. Clicking a view in the view browser opens a diagram for the selected view. You can move from one diagram to another by double-clicking the latter in the model browser, by selecting the appropriate window, or by using the tabs above the diagrams.
Removing schemes/views
You can remove schemes and views from the model by using the Delete-button, or through the right mouse button. If you remove a view, only the view is removed; the (semantical) objects in the model (and in other views) are not removed. If you remove a scheme from the model browser, the objects in that scheme are removed from the model, and all references on views in the model will be removed as well. Using the right mouse button on the model in the model browser or view browser, one can create folders to structure the model. Diagrams can be dragged to a folder. In a folder new folders can be created. Using the model browser you can easily add many model elements in one time, for instance a list of schemes, a list of roles, a number of process blocks, a number of activities, a list of applications, a list of data objects, etc. Click with the right mouse button on a scheme or in a view, and select Create multiple. Select the properties you want to fill besides the name of the element.
Folders
Create multiple elements
You can add names and other properties in the resulting table by copying it from Excel or Word, or by typing these names and properties. Architect generates
18
BiZZdesign B.V.
objects with these properties. With the mark Match names with existing objects on, using the name Architect will determine whether the objects entried within the table already exist within the model; if a tables object already exists, the information entried for this object will be assigned to the existing object within the model, including profiles / profile properties previously not assigned within the model. Using this functionality you can for instance add a list of applications with documentation in one time.
Copy, cut, paste
In the model browser one can copy, cut and paste model parts (diagrams, collapsed blocks, etc.) within the model and between models. One can also drag these model parts with the model (like to a folder in the model) and between models using the left mouse button. Architect offers a set of standard view types. You find these in the view browser using the context menu on a model, under the option New . Each view type defines the following: 1. which object types (concepts) are available in the view; 2. which relation types are available between these concepts; 3. which presentation (form) do object types and relations have. Because the presentation may be different per view, it might happen that an object looks different in different views. Each view is an instance of a view type. View types and their settings can be changed by an application administrator. The current set of view types is based on the results of the Archimate project. More information on these views can be found in the documents supplied with the tool, to be accessed by means of Help Help overview.
View definitions
Architect
BiZZdesign B.V.
19
3.4 Drawing and adding objects

This section explains how you can add and draw new objects. As an example, we take a process view in order to explain the way of working. The general principles are applicable to all types of views and objects. Objects can be added to a model in two ways: by drawing an object in a view, or by adding (one or more) objects in the model browser.
Drawing in a view
In order to draw an object in a view, you need to create such a view in the view browser. When selecting the view, a window opens, and a button bar appears with the elements and relations for the particular view.
An alignment bar is also available, which can help in lining up model elements.
Adding and drawing objects
When you wish to draw in a view, you start with objects, like business processes, business actors and business roles. Click on the desired object and then draw or drop it into the diagram with the mouse. If you draw an object in the wrong place, Architect signals this with a stop sign. For example, it is not allowed to draw an object that overlaps another one.
Tip: When you wish to place more than one process (or other elements) at a time, keep the Shift-button pressed while placing the objects: in that case you do not need to click the desired concept over and over again.
You can also press the Shift-button while clicking the desired concept; in that case this concept stays selected until you click another concept or the selection arrow.
Using existing objects
When drawing in a view two objects are created: a reference object in the view, and a semantical object in the appropriate scheme. The new object automatically gets a unique name. If you want to place an already existing object in a view, just drag it from the model browser into the view. If an object cannot be placed in a particular view, Architect shows its stop sign.
20
BiZZdesign B.V.
Create multiple elements
Using the model browser or in a diagram you can easily add many blocks or activities. Click with the right mouse button on or in a diagram, and select Create multiple. See section 3.3 for more details. After you draw an object, you can directly enter a name like Check report in the above figure. It is also possible to change the name of an object later by selecting it and after that via F2, adjusting the name. If you change an objects name into a name of an already existing object of the same type, you will be asked if the (new) object also should refer to that existing object. Using this, you can prevent that your model contains different equally named objects. You may also change an object reference by selecting the option Change reference from its context menu.
Tip: You can move a selected object between diagrams, from and to other behaviour blocks, and even to other applications (for instance Word or PowerPoint) by using copy (Ctrl+C), cut (Ctrl+X) and paste (Ctrl+V) . In order to paste the objects within another object, you must select this target object.
Names
Groups
The general view bar contains the interactor for a group:
Using this, you can create graphical groupings of objects by drawing a group around them. Groups behave like other compound objects: you can collapse them, so that you can structure your view.
Grid
Objects, like process blocks and actors, are always positioned on the grid when the grid is activated. This makes it easier to line elements, in order to make neat models. The grid can be switched off through the menu:
Options Grid
or by using the buttons on the button bar. There is also a button that snaps every object to the grid.
Tip: When you position the pointer of your mouse on a button in the button bar, a tool description appears. Auto Layout
A view or a selection of objects in a view can be laid out automatically. Architect determines a best fit distribution of the graphical objects in the view. Using the appropriate button on the tool bar, or F6, or Edit Auto Layout, you generate a new layout of the view or the selected objects. Using Undo you can always return to a previous or the original layout. With this function, you can very quickly create a nice presentation by dragging a set of objects from the model browser into a view, and positioning them using Auto Layout.
Architect
BiZZdesign B.V.
21
Colours
With the pencil and paint bucket buttons, you can change the (background) colour of an object.
Tip: You can change colours, fonts and so on of all objects at the same time by selecting all (Ctrl+A) and choose the desired property via the buttons.
The framework of the behaviour is determined by drawing the behaviour elements. The exact place and size of the behaviour objects does not matter yet: objects can easily be moved later. You can also add or remove elements to the diagram in a later stage.
Tip: You can group objects by drawing another object around them. This object cannot overlap another one. You can also remove objects around other objects by using Edit Ungroup, by Ctrl+U or through the right mouse button. The content does not change, only the edge disappears. Collapsing and expanding
You can collapse objects with Collapse, with Ctrl+L or the right mouse button. In such a way layered models can be built and hierarchy can be specified. The content of such an object is invisible, unless you visualise it by View Show contents. The name of a collapsed object is underlined. Section 3.12 describes collapsing and expanding blocks in more detail. Now you have drawn some objects, you can add properties. The easiest way to do this is by means of Alt+Enter or by double-clicking the behaviour elements. A window appears on your screen (see below) that allows you to enter the properties. You can also adjust properties via the menu or the button bar. In that case, select an element by clicking it once, and then choose Properties via the Edit menu, the right mouse button or the button in the button bar.
Filling in properties
22
BiZZdesign B.V.
Tip: You can also add properties using the table input, see section 3.11.
For some properties there is an easier way to set their value, depending on their type of value. For enumerated types, you can double click on the element and choose from a list of values. For boolean types you can toggle the value.
Tip: It is not necessary to close the properties window every time you changed something. When you select another object, you can change its properties in the same window.
A small block with a plus sign in it, like the one in front of applications in the above figure, means that more properties are available by clicking on it. The same holds for lists, for example business functions. In such cases all elements in the list are displayed. An empty position appears at the bottom, at which a new element can be added to the list. By using the button Remove at the bottom of the properties window you can remove an element from a list.
Tip: Double-clicking a text field causes the text editor to open. This helps you to enter texts of more than one line. By clicking twice with intervals you can enter the text into the field directly. Line breaks are added with Ctrl+Enter.
Properties are grouped per profile. By clicking on the plus sign in front of the profile name, you see which properties are included. The basic properties are listed below <Basic profile>. More information on profiles is given in Section 3.5.
Navigation through diagram
You can navigate or scroll through a diagram using the arrow-keys and with Page Up (scroll up), Page Down (scroll down), Home (to the beginning of the diagram) and End (to the end of the diagram). In addition to this, a number of navigation functions is available within the view bar, as depicted below
View bar
The function Full Screen (also to be activated by pressing the button F11) hides all menu bars and so-on, resulting in a maximum drawing space on the computers monitor. You leave this enlarged drawing space by pressing F11 again. By decoupling the drawing bar from the menu space and place it on the drawing space before activating Full screen, you can access these functions within the full screen mode. The function Scale to fit zooms out maximally, and that all objects are shown within the graphical diagram. The Helicoptor selector automatically zooms out maximally such that all objects become visible, and indicates which part was visible within the diagram before the function was activated. Then, you have two options: (1) you can select another part of the graphical diagram, which
consequently will be shown with the same zoom factor as before; (2) by dragging the rectangle you select another part of interest of the graphical diagram, which consequently will be shown zoomed-out. The view bar also contains the option 1:1 showing the diagram at the normal size.
Moving elements
Objects can be moved to any position. Arrows and icons connected to the elements move with it, so the meaning of the model does not change. You can drag elements into or out a block or an actor. Model elements and selections of model elements can be moved using the mouse or the arrow-keys. When pressing the Ctrl-key while using the arrow-keys objects are moved with large moves, when pressing the Shift-key while using the arrow-keys objects are moved with small moves.
Tip: You can move several elements together by selecting them all. Selecting more than one element at a time can be done in one of the following ways: Drag: select the elements within a square area with the mouse Add elements to the selection by clicking on an element while holding the Shift-button. Holding the Ctrl-button toggles the selection on or off. Via an objects context menu you can select all similar objects.
Aligning of elements
You can align objects with the alignment buttons in the button bar. In this way you can for example place processes on the same line. Via an objects context menu, you can first select all similar objects. Labels on arrows and names of objects can be fixed on a certain position with respect to the arrows or the object (left, centre, outside, etc.). The label stays on the same relative position when moving the object.
Positioning labels
Select the label, and choose the right position on the toolbar. You can move the label afterwards; choosing the position on the toolbar repositions the label. You can also select several (name)labels by selecting one specific (name)label, followed by context menu select similar.
Formatting labels
Arrow labels and object name labels can be formatted and rotated. Using vertical text rotation is useful when using vertically rotated triggers.
Scaling of elements
You can also give objects the same height or width, or make equal distances between them. The first object selected (marked with green selection marks) determines the sizes of the other objects (marked with blue selection marks). Therefore you first have to select this object, and add the other objects. You can
24 BiZZdesign B.V.
do this by selecting all similar objects via the right mouse menu. Objects cannot be made smaller than their minimal size; there must be enough space around the objects to successfully scale the objects. Objects can be resized. Select the block, and using the left mouse button the object can be resized independently in both directions (horizontally as well as vertically). The contents of the block remain as it was, and an object can not be made smaller than its contents.
Claim Form Damage Claim
create/ update
read
crud
Handle Claim Damage Occured Register Accept Valuate Pay
create/ update
read
read
update
Customer File
Insurance Policy
Customer File
Text with relations
The figure shows some other possibilities to increase the clearness of a model. It is possible to add a text to relations. Text is added to an arrow by clicking on it and typing text. Also these labels can be positioned with the positioning bar. It is not always possible to draw well-ordered models with each arrow as a straight line. In such cases you can insert break points. Select an arrow and hold the Ctrl-button when clicking on the position of the break point. Break points can be moved afterwards. When arrows are moved, the break points move with it.
Tip: by clicking on a break point while holding the Ctrl-button, the break point disappears.
Break points
Architect
BiZZdesign B.V.
25
3.5 Drawing relations

You can draw various kinds of relations between objects in a view, provided that the specific type of relation is defined in the underlying metamodel, and that the specific type of relation can appear in the view.
Drawing in view
Relations between objects in a view may be drawn by dragging the relation from the model browser into the view, or by drawing a relation between both objects. Relations can have several segments; you create these by clicking the left mouse during creation of a relation.
With a blue border Architect signals if a relation is allowed to start in or end at an object.
When drawing a relation from or to an object, you do not have to start precisely on the objects edge. It is sufficient to click somewhere on the object. With a blue border around the object, Architect signals that the mouse is over the object, and that the relation is valid.
Automatic correct relation
When drawing a relation, you can select the correct relation type yourself by selecting it from the tool bar. You can also use the generic relation symbol, and draw relations with it:
Architect will then determine what type of relation is meaningful between the two objects being related, based on the underlying metamodel. If that is not the correct one, you can adjust it by changing the relation type.
It is also possible to configure the preferred relation type via Options Concepts and relations. For each combination of concepts the preferred relation type that shall be drawn can be specified.
26
BiZZdesign B.V.
Labels and icons on relations
Similar to objects, you can add a text label to a relation, by selecting it and typing the text. This text will be the name of the relation. You can also add icons to relations, in a similar way as you can add icons to objects. Relations can also be created without drawing them explicitly. This is possible using the cross relations table, in which you can check and uncheck relations. In this way, relations are created semantically, without being drawn in a view. Whenever the related objects are placed in a view, such relations will also be made visible. More information on cross relation tables is available in section 3.11.2. Objects with relations in a view can also be laid out automatically using Auto Layout (F6). More information on this function is available in section 3.4. You can remove a relation from a model by deleting it from the model browser. Doing so also removes all references (referring objects) in all views to this relation. You can remove (an appearance of) a relation from a view by selecting it and pressing Delete. This will only remove the relation from the view, and not from the model. If you remove the relation in a view with Ctrl+D, the relation is removed from both the view and the model. In order to see where an object is being used, the option Where used is available via an objects context menu. A list will be presented showing all references to the selected object(s). If necessary, you can reassign these references by selecting Assign in the dialog. The results can also be printed. It is possible to get a quick overview of all objects that are not used within the model. Choose via the right mouse button the option unused objects, for example on a model or on a scheme. The result can be influenced by specifying where to search: in views, in profile attributes, or as start- or endpoint of a relation. You may also show the dependencies of an object within a model. This is helpful in determining if a model contains references to other local models. Use Dependencies from an objects (object, diagram, model as a whole) context menu to open the Dependencies dialog. The results can be sorted by clicking on the column headers.
Relations via cross relation tables
Auto Layout
Remove relation
Where used
Unused objects
Dependencies
Architect
BiZZdesign B.V.
27
Changing references
You may change dependencies by (re)assigning them via Assign . The references you have selected with a checkmark will be reassigned. You can select all references using Ctrl+A. Within a specific view you can determine which specific relations are possible, by means of View Possible relations. An overview is presented showing all relations in the model that can be shown in the active view. The user may distinguish between relations already shown and relations not shown (yet). You can add these relations to the view by selecting the relations of interest and activate them by means of Add to view.
28
BiZZdesign B.V.
Architect
BiZZdesign B.V.
29
3.6 Generating views

Architect enables you to generate views based on objects you select. Locate the objects you want to generate a view for, select them in the model browser or in a view, and choose Generate view for in the context menu. The following dialog appears, in which you can indicate the type of view to be generated.
The choices available in the dialog depend on the type of object you selected, and the types of views that are available. For the objects you selected a view will be generated, including all relations with other objects, provided that these relations may appear in the selected view and these relations satisfy the relation settings. Thus, the results depend on the view type you select. Additionally, for each selected relation type the graphical representation can be specified: by means of graphical relation or by means of graphical composition. The direction of the composition is controlled by means of the option Inverse composition. The option In current view controls whether the newly created view will be added to the current view, or will become a separate view. If you choose for a
30
BiZZdesign B.V.
new view, the view will be added to a dedicated view folder so that you may find these views easily later on. Finally, you can control the range of the view by specifying a value for depth: it specifies the number of successive relations used for the selection of the range, as counted from the objects selected. Within the model depicted below, a business process view is generated for the process Register, specifying only triggering relations within the relation settings. Specifying a value of one for depth will show: Damage occurred, Register and Accept. Specifying a value of two for depth will show: Damage occurred, Register, Accept and Valuate
create/ update
read
crud
create/ update
read
read
update
Customer File
Insurance Policy
Customer File
Generated views can be used like any other view, so you can add your own objects, or relocate the view into another folder.
3.7 Total view

It is possible to generate a view for the complete model with View Total view. You can specify the view type and the relation settings to be shown in the view. In contrast to the function Generate view for in the context menu where the view generated is based on the objects selected, this function displays the entire model in the view. This operation may take some time, when applied to large models.
Architect
BiZZdesign B.V.
31
32
BiZZdesign B.V.
3.8 Views in views

Architect allows you to create views that contain (references to) other views. You can do this by dragging a view from the view browser into another view. This creates a reference to a view that can be opened by double clicking it. Below, an example of this is shown. It illustrates the use of this mechanism to create Overview views, in which different views are placed to show a particular coherence.
Architect
BiZZdesign B.V.
33
3.9 Documentation and references

In Architect you can easily document your process, and refer to other documents or intranet sites.
Documentation window
All objects in the model, but also the diagrams and the model as a whole, can be documented. Select the object in the model that needs to be documented, and type the documentation in the documentation fields of the document window. You can also copy and paste documentation from other Office programs (Word, PowerPoint, Excel, etc.). If the documentation window is not visible, you can activate is via the Options menu or the menu bar. The window can be moved freely within Architect by dragging it with the mouse.
Formatting text
Using the format bar (via the Options menu) the texts in the documentation window can be formatted, for instance fonts, alignment, numbering, bullets. The standard font for documentation can be set via Options Application settings. You can also type hyperlinks, like www.BiZZdesign.com using CTRL+K; you can follow these links both from within Architect and from the intranet report. You can also add e-mail links, like mailto:helpdesk@BiZZdesign.com. These e-mail links become reply- or feedback options in the intranet reports. Using CTRL+F or CTRL+H you can find and / or replace text in a documentation field.
Search and replace
34
BiZZdesign B.V.
Defining documentation fields
You can define your own documentation fields. Default any object in the model has a documentation field Documentation. You can add extra documentation fields per object type by defining an extra documentation profile. A separate instruction on how to do this is given in the related appendix.
References
Hyperlinks can be added to almost all objects. You can use these to refer to documents that have to be used while performing a particular action. You can also refer to intranet or Internet addresses. If you report your model in HTML, your web browser will show these hyperlinks attached to your model elements. The next steps show how a URL can be added to a model element: 1. Select the object to which you want to add a hyperlink, and open its Properties. 2. Open the Basic profile, open References, and then link.
3. Double click on link, and select the document or internet page using the dialog. The name denotes what users will see in the resulting reports, the link denotes the actual file and location. For certain graphical formats (like bitmaps) you can choose to embed these files; this means that the actual picture will be added to the report, and not the link.
Architect
BiZZdesign B.V.
35
4. You can also refer to locations or bookmarks within a document. . Insert bookmarks within your document, and add the name of the bookmark to the URL, preceded by a #. In an example above this results in: Q:/public/data/instructions/scanning.doc#namebookmark In the HTML-report clicking on the resulting hyperlink can open these references. More information is given in paragraph 7.9. Such hyperlinks can be added to almost all graphical objects in Architect . If you want, you can add more than one hyperlink to objects. In a similar way you can also add hyperlinks to documentation fields. Place the cursor in a documentation field, and choose the insert-link-button on the layoutmenu bar. You can also use the command CTRL+K.
36
BiZZdesign B.V.
3.10 Profiles and Properties

Profiles
The properties that are assigned to an element constitute its profile. A basic profile, with general properties like name and documentation, is assigned to every object. Next to this basic profile, you can also assign additional profiles to objects. This allows you to specify properties that are needed for a specific type of analysis. Adding and removing profiles is realised by choosing
Edit Properties
from the menu (or by clicking the right mouse button) and move to the tab sheet Profiles. In this window the profiles that can be assigned are listed. The profiles that are ticked have already been assigned. By ticking the option recursive, a profile is recursively assigned to all objects within the selection. Via the tab sheet Properties the properties in the additional profiles can be read and changed. In the properties window the properties are grouped per profile. By clicking on the plus sign in front of a profile name, the properties of that profile are listed. The basic profile contains all properties that are by default assigned to an object. You do not need to assign the basic profile yourself.
Tip: You can change the profiles or properties of more than one object at the same time by selecting all objects and then modify the required properties, or by using the property table. Using your own profiles
Architect has the possibility to define and use your own profiles, or to define and use profiles within a group. With this possibility you can define and use new properties in a model. Architect will report these self-defined profiles in the same way as the standard profiles, and also views on these profiles are possible. This mechanism can be useful in a project, department or organisation to define and use certain properties not available in the standard profiles. Please refer to the appendix on this subject. Via the menu
Options Application Settings
two directories can be set where Architect will look for these profile definitions, a personal and a workgroup directory. These directories can be network directories, such that all group members use the same profiles. When exchanging models it is important that all users use the same profile definitions, to prevent loss of information. Architect will usually give a warning if the appropriate profile is not available, but mostly it will not detect version differences between profile definitions. When definitions are missing, Architect will ask you if the missing profiles have to be removed. You should do this only when the information in these profiles is not valuable anymore because this information will be lost when removing these profiles. When the information needs to be preserved, the profile definitions need to be restored. The model will remain to be refused by Architect until the unknown attributes have been removed, or the missing profile definitions have been restored. Via Options
Architect
BiZZdesign B.V.
37
Application Settings you can determine that all profile definitions are stored in the
model, which increases the possibility that models can be exchanged between different users. Profile definitions in the working locations are used before definitions in the model. Note that Architect handles missing profiles for shared models differently, see also chapter 5.
Defining your own profiles
Defining your own profiles is not technically complex, but it can have major consequences, for example for compatibility with new releases and possible conflicts with existing profiles. The use of self-defined profiles within an organisation requires mutual agreements within the organisation. Contact your application administrator for these issues.
38
BiZZdesign B.V.
3.11 Tables
Architect enables an easy way of editing, presenting and reporting data using tables. Both predefined and user-defined tables are possible.
Selections
To reduce the size of a table, both the rows and columns of a table can be restricted to the current selection, the active diagram, or the whole model. Also (parts of) hierarchical models can be collapsed or expanded by clicking at the + or sign in the row or column. Tables are sorted by default on number (the first column of the table). By clicking the name of a column (for instance number, name, etc.) the table is sorted on that property. A table can be printed using the Print button. Via the buttons Copy respectively Copy+ the table can be copied to the Windows clipboard, respectively without and with the tables header and fixed row lines. Using Windows Paste, the table can be pasted to any Office application, like Word, Excel, or PowerPoint. A part of the table can be printed or copied by first selecting a part of the table using the mouse. The property table and the cross-reference tables can also be reported directly to Word and HTML. When reporting the model you should select the appropriate table on the tab tables. More information is given in section 7.6.
Sorting
Printing and copying
Reporting
3.11.1 Property table

Property table
With the property table it is possible to show and to edit properties of more objects simultaneously. Choose
Edit Property Table
Selection of properties is via a selection window, as shown in the figure below:
Architect
BiZZdesign B.V.
39
A column in the property table is added or removed by double-clicking an attribute or by using the arrow keys in the selection window. Also the order of the rows can be determined by using the arrow keys.
Save
You can save a table definition for later use, or load a previously defined table. Choose Save table or Load table to do so. More information on saving and loading tables is found in section 7.6. Each table row corresponds to an object, as shown below. You can determine whether the table applies to the whole model, to the active diagram or to the current selection.
Editing of the contents of the table is possible by (double) clicking on the cells. With the key Modify table you can add or remove columns from the table.
40 BiZZdesign B.V.
Landscape colouring
By selecting landscape colours in the table, the table shows value colours for the selected property.
3.11.2 Cross reference tables

Cross reference table based on profiles
Between different elements in a model certain cross references may exist, as defined in the underlying profile definitions. Examples are the application description profile, or cross references between different types of objects (a business function is supported by applications). Cross references like these are noted by Architect , and using a cross reference table one can edit these cross references. Choose
Edit Cross reference tables
and choose the right table. The cross reference table may be chosen for the current selection, the active diagram or for the whole model, both for rows as columns. Parts of rows and columns can be collapsed based on the hierarchical structure of the model. When new cross references are added in profiles, the corresponding table is automatically added.
Cross reference table based on relations
Between different elements of a model there may also be cross references, based on the (graphical) relations that are created when drawing relations in a view. An example is the assignment relation between roles and processes. Such relations can also be shown and edited in a table. Choose
Edit Cross relations table
And choose a relation type. Within the table, you can further specify between which two types of objects you want to edit the relation type. You can create of delete relations by putting check marks in the cells of the table.
You can modify this table. When removing a checkmark, the specific semantical relation will be deleted. When putting a checkmark in the table, a semantical
relation between two objects, if possible, will be created. This relation will not be shown in any view (yet). The relation will become visible in a view as soon as one of its end-points or the relation itself is dragged from the model browser into a view. Within this table Architect can show additional information: o With the checkmark Show why in cells the specific relation-object will be shown: if possible the name is shown, otherwise the relation-type o With the checkmark Landscape colours properties of own choice will be shown in colours o With the checkmark Labels properties of own choice will be shown in labels The title bar indicates which additional information is shown. In the example below, a cross reference table is shown in which is shown as a label the type of access (read / write).
3.11.3 Translation table

ONLY AVAILABLE WITH THE ADD-ON EXTENDED LANGUAGES The translation table offers the possibility to translate all parts of a model that are language dependent in multiple languages (names of objects, documentation, certain properties, foldernames, etc.). By setting the regional settings of Windows in another language the model will be shown and reported in the chosen language. Using
Edit Translation table
results in a table where you can chose the property that has to be translated in multiple languages. For the available languages (depending on you specific
42
BiZZdesign B.V.
licence) you can add the appropriate translation. The current language is denoted with a star (*). The column neutral can be used to fill all not yet filled languages.
3.11.4 Link table

If a model contains references or links to documents, websites, etc., an overview of these references is obtained choosing
Edit Link table
This table contains an overview of all references in the model, diagram or selection, both references in the basic profile property references, and references in documentation fields. Note that links to web pages need to start with http://.
Correcting references
In this table a red cross marks a reference that is not correct, which means that the document or website is not available at the given location. You can correct the reference by double clicking a row with a red cross, and browsing to the correct location. Architect will suggest replacing all similar links.
Architect
BiZZdesign B.V.
43
3.12 Collapsing and expanding objects

Collapsing and expanding objects
Collapsing and expanding objects allow you to build layered models. You can collapse an object with Ctrl+L or with the right mouse button. The content of a collapsed object is invisible and its name is underlined. The picture below shows two business processes, Handle claim is collapsed.
Handle Claim Damage Occured
Close Contract Request for Insurance Formalise Request Create Contract Check and Sign contract Check and Sign Contract
Both existing objects (with contents) and empty objects (without contents) can be collapsed. The content can be adjusted or extended in a later stage.
Always give collapsed objects a name. This makes it easier to keep overview, and to navigate through the model. Printouts and reports are also more meaningful. Navigating
You can enter a collapsed object (for viewing or editing) by double-clicking it, with the right mouse button (Open), or with the key combination Alt+down (provided that the collapsed object has been selected). A simple way to navigate through a layered view is by using the key combinations Alt+down and Alt+up. Minor editing operations are available for collapsed objects. When the content is visible (with the right mouse menu Show contents) properties of the actions within the collapsed object can be altered. The content of a collapsed object can only be modified when you enter it (see above). Within an expanded object other collapsed objects can be inserted. In that case a layered model with more than one level can be constructed. With Show contents you can make the contents of a collapsed object visible. In this way it is possible to select (part of) the contents and look at its properties, perform a specific type of analysis, or apply minor editing operations (such as modifying properties). Contents of collapsed objects within a collapsed object are visible through Show contents. Contents of collapsed objects are scaled to the size of the object at the higher level. It is therefore important not to use small objects at a higher level when you wish to see the content. You can also use the tool tip view to view the contents of collapsed objects, see section 4.2.
Editing
Show contents
44
BiZZdesign B.V.
Handle Claim Damage Occured
Close Contract Request for Insurance Formalise Request Create Contract Check and Sign contract Check and Sign Contract
Undoing collapse
A collapsed object is expanded with the right mouse button or with Ctrl+Shift+L. In this way the collapsed object is replaced by its contents. Ungrouping a collapsed object (via Ungroup) not only undoes the collapsing but also removes the outer object. These operations put the contents of the collapsed object in real size in the diagram. If the size of the contents of the collapsed object is greater than the size of the collapsed object itself, you will have to reorder the model yourself. In those cases it is easier to make room for the collapsed object beforehand. The use of collapsed objects within a model also has consequences for the input and output of other parts of the tool (analyses, documentation). We briefly describe some consequences and refer to Chapter 4 and 7 for more information. The results of a viewfilter (colours or labels) within a collapsed object are visible through expanding the object (for example via Alt+down) or via Show contents. Whenever it is necessary for a view to select an element from the model (for example in case of the display view) it can be done both in the expanded object and via Show contents. When you print a model or diagram, the structure of the model is leading. This means that the diagram on the highest level is printed first, then the contents of collapsed objects on that level are printed, and so on. The same holds for reporting a model.
Consequences of collapsing
Viewfilters
Printing and reporting
Architect
BiZZdesign B.V.
45
3.13 Graphical Settings

Graphical settings
The graphical settings for models can be adjusted. The configuration settings for displaying symbols are located in profile definition files, in the directory Domains\Studio\Component\ArchitectView within the Architect application directory. By editing these files you can change the presentation of symbols. By specifying red being the default colour of application components, all application components within views of this view type become red. It is possible to specify amongst others colours, lines, fonts and symbols. You should contact your application administrator when changing these settings. When setting default values, previously entered default values are overruled. However, manually entered values do not change. When you configure the application components default background colour to yellow, and after that manually assign blue as the background colour to some of the application components, these blue application components will not change colour whenever reconfiguring the default background colour to for instance red. For other profiles this also holds. If you manually changed the graphical settings of an object you can reset these settings to the default settings via Edit Default settings. All graphical settings are restored.
Default and manual
Resetting defaults
46
BiZZdesign B.V.
3.14 Searching
By means of
Edit Find...
or Ctrl+F you can search for elements in a model, a diagram or a selection. In the Find window you can specify what type of objects you are searching, and which profile, attribute or value they should have. You can choose between results to be presented in the form of a view (with a specific colour) or in a message window. If you choose the last option, the search results will be shown in a message box; if you click on a result, Architect will select the corresponding element in the model en show it in the diagram.
If you are searching for a textual attribute, Architect does not distinguish between capitals en regular characters. For example, if you are looking for all objects that contain the word claim in the attribute documentation, then the results also shows those objects where the word Claim or CLAIM occurs in the documentation field.
Architect
BiZZdesign B.V.
47
3.15 Application settings

Architect has general settings that hold for all models. You can find these settings using Options Application settings.
At the tab General you can determine whether or not A new model is created at start-up The order of documentation fields Selecting another view in the view browser requires a single or a double click Search results are shown as message box, as a view, or if each time it is determined by the user A newly created relation-object of the preferred relation type at creating objects in a nested way (also applies for drawing nested graphical objects).
48
BiZZdesign B.V.
Furthermore you can determine your working folder. You can also determine the time interval between autosave operations.. When working with large models it can be useful to increase the time interval. At the tab Profiles you can set the personal and group folders for profiles and table definitions, and determine whether or not profiles should be saved in the model itself. At the tab Graphics you can determine if objects have to be coloured when using a colour view. If so, you have to choose between foreground and background colouring. You can also determine shadow options and the font used for documentation. For collapsed objects you can indicate whether the contents shall be faded out, together with the fade out factor and whether fade out shall take place incrementally at each next collapse level. Finally, for documentation fields you can configure which font type to use by default. At the tab Logging you can configure whether application-logging shall take place and if so which logging configuration file to use. By default logging is deactivated. Only activate application-logging when explicitely requested by BiZZdesign Support.
3.16 Re-use of BiZZdesigner models

THIS SECTION ONLY APPLIES IF YOUR ORGANISATION ALSO USES BIZZDESIGNER
Open BiZZdesigner models
You can open BiZZdesigner models in Architect, using the function

File Open.
You select the file with extension .xmb containing the model to be opened, and consequently this model is shown within the modelbrowser. Only semantical modelinformation is shown, the graphical diagrams are not shown in Architect. An example is shown underneath.
Architect
BiZZdesign B.V.
49
A BiZZdesigner model is similar to an Architect model. In the modelbrowser you see the model-object, together with the modelname. Underneath are shown folders and schemes, containing the BiZZdesigner objects. You can read this semantical modelinformation using the Model browser, the Property window and the Documentation window. You can only read the model and can not edit it. This modelinformation can be dragged-in into an Architect model, similar to copying between normal Architect models. You select one or more schemes and drag them to the Architect model-object of the model to which the information shall be copied. Consequently, Architect creates new objects within the Architect model. Architect translates the BiZZdesigner objects to Architect objects. More information can be found in Appendix Interface BiZZdesigner - Architect.
Profiles
Note that if the BiZZdesigner model uses specific profiles created by your organisation, these profiles need to be available within Architect. If you want this information to be copied into the Architectmodel, you need corresponding (consistent with the BiZZdesigner profiles) profiles for the Architect model as well. Preferrably, consult the application manager.
50
BiZZdesign B.V.
4. View filters
View filters are used to generate feature overviews of the model. For example, colours can be used to emphasize certain aspects of the model. View filters are not persistent: they are not saved with the model. If desired, view filters can be stored using cut and paste to other applications, such as Word. View filters can also be printed or included in reports.
The terms view filter and view are both used as synonyms, if there is no conflict with the view concept from chapter 3. The view filters treated here are available through the View menu. Enabling and disabling
You can enable a view by selecting the view within the View-menu. View filters are disabled by selecting the view filter again within the menu. Shortcuts for toggling views are also available through the Tool bar: for the label view filter for the colour view filter for the difference view filter for the tooltip view filter for the highlight view filter Most view filters include a legend explaining the meaning of the different colours or labels. The legend is included in the diagram and can be moved in the diagram. The legend only shows colours for elements that are present in the diagram, so the legend can differ per diagram. Altering colours is possible through double-clicking on them. You can remove the legend via the view menu or via the legend button on the menu bar. If you edit the model while a view is enabled, it might be necessary to refresh the view in order to see the changes. You can do this by pressing the function key F5, by using the refresh button on the menu bar, or by
View Refresh diagram
Legend
Refresh
When you select some of the objects in an existing model and wish to keep this selection on your screen, it is possible to present the selected objects as a view. To do this choose
View Highlight
By making this choice from the menu again the view is turned off.
4.1 Label View

With label view object properties are printed on the screen below the object. In this way it is possible to show, for example, the applications owner. Select
View Labels
Architect
BiZZdesign B.V.
51
The screen displays a list of properties. From this list you can select the desired properties. You can choose more than one property.
Home & Away Policy Administration
Document Processing SSC
Customer Data Access
Customer File Data
Claim Data Management

Finance
Damage Claim Data
Policy Data Management

Back Off ice
Insurance Policy Data
Home & Away
Product Development
Risk Assessment
1)
Legend
labelviewfilter owner
The labels are numbered. The legend shows the numbers of the properties. The labels for objects can be changed w.r.t. their appearance: font, font size, font colour, and label position can be changed in a similar way as normal text labels.
4.2 Tooltip view

The tooltip view shows properties of objects as tooltips when the mouse hovers over the object. For instance, one can show the documentation as tooltip on a specific object. Select
View Labels
The screen displays a list of properties. From this list you can select the desired properties. You can choose more than one property.
This tooltip view can also be reported to HTML. For this you need to activate the tooltip view before starting the report function.
52
BiZZdesign B.V.
4.3 Colour view

With colour view object properties are visualised with colours. Select
View Colours
The screen displays a list of properties. From this list one or more properties can be selected for colour display. For example, you can present the owner of an application as a colour of the application. Through double-clicking a colour in the legend you can change the colours.
Home & Away Policy Administration
Customer Data Access
Customer File Data
Claim Data Management
Damage Claim Data
Policy Data Management
Insurance Policy Data
Risk Assessment
Legend
owner Back Off ice Finance Document Processing SSC Home & Away Product Development
You can determine whether (nested) objects are coloured as well when using a Colour of collapsed objects colour view. Select
Options Application Settings Graphics
You can choose if collapsed objects (in Application Settings these are referred to as Colour blocks) are coloured at all, and if so, if the foreground or the background is coloured.
Legend
related principles Processing time principle One counter principle
Architect
BiZZdesign B.V.
53
4.4 Compare view

The compare view shows whether or not two different properties have the same value or different values. An example is the comparison of the present to the desired maturity level of organisation departments. This comparison can be shown visually with the comparison view, in which the present and the desired level is shown. If an object has two colours, the present maturity level does not correspond to the desired level.
Select
View Compare
and choose the properties you want to compare.
4.5 Hide view

Using the hide view makes it possible to hide objects of a specific type (concept) completely or partly in a view. When activating the Hide iconmenu, the concepts within the current view are shown. By clicking a specific concept (object type), all objects of this type will first be partly hidden by being greyed; by clicking once again the objects will be hidden completely in the view. When the concept is clicked once again, the objects will be shown normally again in their original colour. This is illustrated in the figures underneath, by hiding business objects partly respectively completely.
54
BiZZdesign B.V.
4.6 Derived relations

In Architect relations between objects can be modelled by means of profiles or by means of drawing relations visually. For both types of relations, the derived relations view provides an overview of indirect, derived relations in a model.
Derived relations via attributes
For deriving derived relations on the basis of profiles, choose

Derived relations and consequently via profile attributes. In the window that follows, it can be View
specified between which attributes the indirect relations shall be presented.
Based on the relations between model elements an overview of derived relations is shown. An example is the relation between business functions and application
services: both business functions and application services can be assigned to application components. Based on this, the relation between business functions and application services is determined.
The resulting table shows the existence of a relation between a specific business function and application by means of a checkmark. In addition, you can show by which application components these relations could be derived (show why).
56
BiZZdesign B.V.
Furthermore, you can construct a landscape map using the option Landscape colours. You can choose the property of the objects in the cells to be shown in colour. An example result is shown below:
You can change the colours of the legend by clicking the corresponding legend item. The table can be compacted using the option Hide empty rows/columns, which will hide the rows and columns that contain no value.
Derived relations via concepts
For deriving derived relations on the basis of graphically assigned relations between concepts, choose
View Derived relations
and consequently via concepts. In the window that follows, it can be specified between which concepts the derived relation shall be presented, and by means of which concept the relation shall be derived.
Architect
BiZZdesign B.V.
57
On the basis of the relations between model elements an overview with derived relations is presented, similar to the derived relations via profile attributes.
58
BiZZdesign B.V.
5. Team-support
ONLY AVAILABLE WITH THE ADD-ON TEAM-SUPPORT With Architect you can create enterprise architecture models. You can store these models in different ways. Dependent on the how the model is stored, additional multi-user and versionmanagement functionality is available. An Architect model contains all modelling information about the subject of modelling: the enterprise architecture. So: all business processes, business actors, infrastructures, etc. together with their mutual relations, and all views. By default this information is stored in xml-files, with extension .xma. Besides this, one can speak about multi-user and revision functionality and multiuser- and revision information. It concerns information as the model changehistory as it evolves in time, and which users have made these changes. Architect makes it the possible to administer this information automatically. At a later stage on the basis of this information you can determine when a specific change has been made.
Shared model
To make use of this additional functionality, you need to store a model as a shared model. A shared model contains the same information as a normal Architectmodel, as well as additional multi-user and revision information. A shared model makes it possible to edit the model with several users simultaneously, with minimal multi-user restrictions and keeping the model consistent. Each final committed change results into a so-called new modelrevision. Architect keeps an administration of when this revision has been created, and who has made the change to the model. A shared model is physically stored in a file with extension .sma. Shared models can also be stored in a repository (a specifically for this need configured database). Amongst others, a repository has additional functionality with respect to structuring shared models and security. The repository-support requires a separate licence. More information on the repository-support can be found in chapter 6.
Architect
BiZZdesign B.V.
59
5.1 Input and output of shared models

Save a model
You store a model as a shared model with a (new) name through the menu
File Save as
You choose the extension .sma. After that the (changed) model can be saved again with the same name through the menu-option
File Save
In this case only your private changes in your private workspace are saved. More information on this is described in section 5.2.
Open a model
A preveously saved shared model can be opened in Architect through the menu
File Open
or through Ctrl+O. You need to select the files with extension .sma.
Recently opened models
The recently used models can be opened directly from the list at the bottom of the File-menu; it does not matter whether the models are opened from an .xma-file or an .sma-file. When a specific modelrevision is opened (through the function Revisions, see also section 5.9), this modelrevision is added to the name within this list, for example EnterpriseArchitecture.sma?revision=114. An opened shared model can be closed through the menu
File Close
Close a model
or through the contextmenu. If you have checked-out objects within the model (see also section 5.2), you will be asked if you would like to check-in these objects. When choosing so, the Check-in dialog is shown automatically (see also section 5.5). If you do not check-in the objects, you need to specify whether the changes shall be saved or ignored.
5.2 Changing a shared model

Changing a model
To change the modelling information within a shared model, you need to open the (shared) model in Architect. Automatically Architect creates a personal workspace for personal changes. Changing a specific model takes place within the so-called personal workspace. This is a personal workspace and is bounded to this specific model. Within this workspace the properties of the objects changed by you are saved. If you change objects, Architect will check-out these objects automatically. As each user has his or her personal workspace, other users are not able to see these changed objects and their changed properties. Only if you make your changes final (which means check-in), other users are able to see these objects with the new property values. A so-called lockingmechanism facilitates that users can make changes in a coordinated way. The exact design of which locking-types to distinguish and how to use these depends on the collaboration starting-points: At all times the model shall be consistent
Workspace
Locking and collaboration starting points
60
BiZZdesign B.V.
Users shall restrict each other as minimal as possible when making changes At all times, it shall be possible make changes final, or to ignore the changes
When you change a specific object for the first time, automatically a shadow object is created in your workspace, with the new property values. With respect to this specific object other users only have the last checked-in revision available, and can not see these changed property values. Besides that, the object gets a specific status: it is under construction by you. In this document we state that the object is checked-out by you. Consequently, other users are not able anymore to change this object. Also, other users are not able anymore to delete an object under which the object checked-out by you resides. You can make your changes final within the model, by checking-in the object. A new modelrevision is created, which is identical to the last model rivision except for the objects you have changed. These objects obtain the properties as assigned in your workspace. The object status is restored: the object is by no-one under construction. Newly created objects, will be checked-out automatically. You can change these objects without any restrictions. These new objects will also be created within the new model revision when checking-in.
Save
If you make a change, first this change will be made within your computers working memory (RAM): this means that the changes are not saved for later use. This is similar to changing a document in Word, and that you have not saved your changes in this document. Saving a shared model implies that the changes (in the computers working memory) are saved within the persistent personal workspace: all your changes are saved. This implies that next time when opening the model these changes are available again. Other users still do not see your changes: you have not check-in these changes (objects). By using the function undo you can undo a change: the properties get their initial values before making the change. By activating this function several times after each other, you can undo a number of changes. When closing a model you will be asked whether the changes shall be saved. If you choose to save the changes, the changes are saved within your own persistent (saved) workspace. If you want to share the changes with other users, you need to check-in the model using the function Check-in. The function Check-in creates a new model revision containing your personal changes. Consequently these changes become visible to other users. Besides that, all locks as a result from your changes will be removed. Other users will not be restricted anymore resulting from your changes. Your workspace will be cleanedup: all shadow objects are removed. As a consequence of the before mentioned collaboration starting-points, Architect distinguishes the following locking-types that can be assigned to an object: Lock for modify: the object is changed by a user Lock for modify and delete: the object is removed by a user
Check-in
Locking types
Architect
BiZZdesign B.V.
61
Lock for keep alive: another object has an existence relationship with this object, and this other object is under construction Note that the lock for keep alive assigned to a specific object always is a result of an action on another object, for example the creation of a new relation: this new relation is dependent for its existence on the objects between it defines the relation. For example, you have created a model containing two business process schemes, both containing a number of business processes. Suppose you move a specific business process from the one business process scheme to the other. In this case the business process that was moved gets a lock for modify. Also, both businesses process schemes get a lock for keep alive. Consequently, due to these locks, other users can still change both business process schemes (for example change the name), but not remove these schemes. Undoing the moveaction, results in moving-back the business proces. However, the locks that were assigned before will not be removed. So, other users are still not able to remove both business process schemes. Only by checking-in the change, or by performing the function Undo check-out (unchanged), the locks that were assigned are removed again.
Object status
In the modelbrowser the object status is shown visually with status-indications: before the objecttype-icon a status-icon is placed, the object-name is shown in a specific colour and an extra sign may be placed before the name: Icon Name Accept Accept Accept * Accept Accept Accept Accept Status description The object is not under construction The object is under construction by you (checked-out by yourself) The saved properties of this object are changed compared to the last modelrevision Related to this object there are unsaved changes The object itself is not changed by you, nd you have removed one or more underlying objects but not checked-in yet The object is under construction by another user (checked-out by another user) A newer modelrevision (than the one currently shown) exists, in which this object has been changed, removed, or new (child) objects have been created underneath this object
Below an example of the modelbrowser is depicted showing several status indications. You can see that status indications may appear in several combinations.
62
BiZZdesign B.V.
The status of views (view objects) in the viewbrowser is shown similar to the way the status is shown of the semantic objects in the modelbrowser. Please note that this status is not updated if you make changes to the graphical diagram that is related to this view object. Only if you remove objects from the diagram, this will possibly result in a status indication that (child) object(s) have been removed. Moreover, the team status of objects on a graphical diagram can be shown, by enabling the collaboration view. A separate section describes this view, see also section 5.10.
5.3 Team properties

For objects part of a shared model you can view team information. This information is available under tab Team in the Property window.
Shown is the following: multi-user information (is the object checked-out, and by whom), the possibilities to edit (is it possible to change, move or delete the
Architect
BiZZdesign B.V.
63
object), whether in your workspace underlying (child) objects were removed, and whether a newer model revision exists in which this object has been changed (indicated by Up-to-date). The possibilities to edit result from the locks Architect has assigned in the model.
5.4 Check-out
Check-out
In some situations you could have the need to claim a specific part of the model. You do not know what you will change exactly, but you do know globally which part of the model you will change. And you want to be sure that you are not restricted (resulting from edit-actions by other users) while making these changes. Also, it could be the case that you would like to change a specific part of the model for a longer period of time, and that you would like to be able to make these changes not restricted by other users. For these purposes, you can use the function
Check-out
This function can be activated on (selections of) folders, semantic objects and view objects. The function is available in the contextmenu, the Team bar and in the menu.
Check-out of semantic objects
Executed on semantic objects, the function Check-out will check-out all selected objects (as well as the all child objects underneath) for being able to change, move (as long as this is possible) and remove. The object status will change correspondingly. Executed on view objects, the function Check-out will check-out all selected view objects (as well as all view objects underneath this view object), together with all graphical objects that reside on the related graphical diagrams. Other users are not able anymore to edit these view objects, as well as the related graphical diagrams. Moreover, other users are not able anymore to change the name of the related semantic objects.
Check-out of view objects
5.5 Check-in
For all changed (and so checked-out) objects the function Check-in will make the changes final within the shared model. The function is available in het models contextmenu, and is enables within de Team bar and within the main menu whenever you have selected the model object. The following dialog is presented:
64
BiZZdesign B.V.
The function presents an overview of all objects that you have changed since the last time you have checked-in. By activating the function a new model revision is created, containing your changes. Besides that, all locks assigned as a result from these changes will be removed. The function Check-in acts on all checked-out objects. So, it is not possible to check-in one specific object, if there is a number of objects checked-out. If you have removed an object, within the check-in overview (of all checked-out objects) the object will be shown underneath which the object is residing. When checking-in you can add a revision description. This description is shown in the revision overview, see also section 5.9.
Architect
BiZZdesign B.V.
65
5.6 Undo check-out

For all objects being checked out the function Undo check-out will ignore the changes, remove the corresponding shadow objects in your workspace made and remove the locks. The function is available within the models contextmenu, and is activated in the Team bar and in the main menu whenever you have selected the model object. In your Architect graphical interface, these objects will represent the object as part of this newly created revision. If you have more than one object checked out, it is not possible to undo check-out one specific object and keep the others checked-out.
5.7 Undo check-out unchanged

The function Undo check-out unchanged removed all locks for all selected objects (as well as the child objects underneath) that were not changed. After that, these objects will not restrict the edit-actions of other users anymore.
5.8 Synchronize
Synchronize status
At start-up Architect reads the model that is centrally stored and presents the contents in the modelbrowser and views-browser. After start-up, other users may have checked-out and checked-in objects within the same shared model. Architect does not present these changes (the new values of the properties and soon) automatically. However, Architect does show the fact that there were changes to the shared model and that these changes are currently not shown in Architect. For each object this is shown by means of status-indications, please refer to section 5.2. Using the function Get latest revision the model presented within Architects graphical user interface is updated with the (checked-in) changes of other users currently not shown. The objects, of which the properties are different in the last modelrevision compared to the modelrevision read at start-up, will be updated: within the graphical user interface these objects get the properties as they have been assigned in the last modelrevision. The function is available in the modelobject contextmenu, and is activated in the Team bar and in the main menu if the model-object is selected. The functionality as described before is Architect default behaviour. This means that periodically Architect will determine whether a newer revision exists than the one currently shown. In the application-settings you specify whether you would like to have this mechanism enabled and if so, how often. Also, through the function Update status you are able to update the status of the objects. This function is available within the model-object contextmenu, and is activated in the Team bar and the main menu if the model-object has been selected.
Get latest revision
Update status
66
BiZZdesign B.V.
5.9 Revisions
You can view the model changehistory by selecting the model-object within the modelbrowser and activate the function Revisions within the contextmenu. The function is also available within the main menu and in the Team bar, if you have selected the model-object. The revision-overview shows all model-revisions, including date/time of creation, the user that has made the changes, and the revision description.
The model-revision read at start-up or the last time Get latest revision has been executed is indicated with an asteric (*).
Label
Using the function Label you can assign a so-called label to a specific modelrevision. The following window is presented.
A label is an additional description that can be assigned to a model-revision beside the description given at Check-in. Labels can be useful for for example assigning an edit-status, like Review version or Final. Using labels you are able to add additional structure to the existing revisions and can make communication about model-revisions easier. One specific label can be assigned to only one specific model-revision. If you would like to assign an existing label to another model-revision, you select this other revision and activate Label.
Architect
BiZZdesign B.V.
67
Architect will ask whether you would like to remove the label from the previous revision and assign it to the revision currently selected. As labels may have a specific meaning to other people (and within other documents), it is advised to use this option with care. If you commit the function Label, the label is shown within the Revision-overview.
Get revision
You can view a specific model-revision by selecting it and activate Get revision. Consequently, the model is shown in the modelbrowser and the viewbrowser. The specific model-revision is added (between brackets) to the modelname. In this way, you can open and view several revisions of the same model. You can only view the model and not edit it. Because in the browsers each model is marked with the specific revision, you can distinguish the different modelrevisions. In the modelbrowser a specific model-revision can be saved as a new (shared) model.
5.10 Collaboration view

To view the team-support properties in views you activate the Collaboration view in the Team-menu or the special icon in the Team bar. The status of the objects is shown as described in the table. Colour of line and name
Pay
The name is green
Description The graphical name object has been changed by me; consequently other users are not able to change the name as well.
68
BiZZdesign B.V.
Claim Form
The graphical object has been changed by me; consequently other users are not able to change this graphical object as well. A newer modelrevision exists than the one currently shown, in which this graphical object has other properties. The object could be checked-out by another user. The graphical object is checked-out by another user.
The lines are green.
Damage occurred
The lines are grey
Register
The lines and name are red
Note that grafical objects can be changed in several ways: You have re-positioned the name: from top-left to centered. You have changed the related semantical object, and consequently the graphical properties are changed. For example: you give the object a longer name. You change the graphical object in the view directly. Examples: resize or move the graphical object on the view. You change another graphical object on the view, and consequently this object changes as well. For example: a relation can be changed, if you you have resized one of the objects between which the relation resides, or one of these objects is moved. An illustration of a view with Collaboration view activated is shown underneath.
create/ update Damage Occured Register
read Accept
5.11 Team settings

You can configure Architects behaviour with respect to team-support functionality. You launch the function Applicatie-settings and choose the tab Team, resulting in the following window:
Architect
BiZZdesign B.V.
69
You can specify whether Architect shall periodically automatically update the objects status, and how often.
5.12 Profiles
When opening shared models Architect verifies whether profile definitions are available for all profile values being assigned in the model. If profile definitions are missing, Architect refuses to open the shared model. In Application-settings you need to specify the correct profile locations; next time Architect is started these profile definitions become available.
70
BiZZdesign B.V.
6. Repository
ONLY AVAILABLE WITH THE ADD-ON OLEDB-REPOSITORY As described earlier, shared models can be physically stored in two ways: in a .sma-file or in a database that has been prepared as repository server. Repository server support enables Architect to connect to a repository server and use it to store shared models. The latter is possible only when such a repository server is available from the workstation on which you run Architect, and you have licences to use a repository server.
6.1 Repository server and repository

Repository server A repository server is a database specially prepared to store exactly one Architect
repository. Architect is able to connect to repository servers.

Repository
A repository is the combination of shared models, personal workspaces, roles and rights, and a table of contents, to the whole of which a name can be assigned. The table of contents is a hierarchy of nested folders that can contain model references. Each model reference refers to a single shared model. Using roles and rights, you decide who has access to certain information. You specify which roles are relevant, which users are assigned what roles, and which privileges a certain role has.
Table of contents
Roles and rights
6.2 Creating a repository

Creating a new repository includes installation and configuration of a new repository server (a specially prepared database) on the server, and the assignment of a name when you connect to this repository server from Architect for the first time. More information about installing and configuring of such a repository server you will find in the Installation Manual Repository server. If applicable you may also contact your application administrator. In one single repository server you can create one single repository. Section 6.3 describes how you connect to a repository server.
6.3 Opening a repository

Models can only be opened from and saved in opened repositories. You can create a new repository and open an existing repository using the Repository Wizard. It will lead you through the process step by step. The wizard will let you
Architect
BiZZdesign B.V.
71
connect to the repository server on which the new repository must be created or where the repository is stored that you want to open. The repository Wizard is available in the main menu under
Team Open repository Open repository
The following dialog is shown:
In this first step you must specify to which type of repository server you want to connect. Currently only the relational databases SQL server (Microsoft) and Oracle are supported, using an OLE DB connection. You choose Next>, and the following dialog appears:
72
BiZZdesign B.V.
In this second step you might select a connection you used before (under 'Connection string'), or create a new connection (using the button Connect to server...). If you activate this button, the next dialog is shown:
Architect
BiZZdesign B.V.
73
In this dialog you must specify the so-called Data Link properties. There are four tabs, of which only the first two are described here. On the first tab (Provider), shown above, you must select the provider to use: SQL Server or Oracle Provider for OLE DB. You then choose Next>>> or activate tab Connection, and the following screen appears:
For SQL Server, on this second tab you must specify the server name (you enter a new name, or select a name that was used before), and choose which method of authentication should be used when connecting. Then you select the correct database; if you do not know which database to choose, you should ask your application administrator. By clicking the button Test connection you can check if the information specified leads to a connection that functions correctly. Finally you must confirm the data entered by clicking OK. This concludes the second step of the Wizard, and the next dialog appears:
74
BiZZdesign B.V.
In this third step, when you are creating a new repository, you provide the name of this repository.
You cannot change the name of the repository afterwards.
Then you choose Next>, after which the entered values are shown once again:
You may change the values by returning to earlier steps (<Previous); if you are content with the values you confirm with Finish, after which the Repository
Architect
BiZZdesign B.V.
75
Wizard closes and the (new) repository is shown in the repository browser. See also section 6.4.
6.4 Repository browser

Repository table of contents
The repository browser shows the contents of a repository, or its table of contents. This table of contents consists of (nested) folders containing references to shared models (model references or model reference objects) that are stored in the repository. The information in a repository's table of contents may be edited by several users at the same time, and therefore has the same properties as a shared model. This means that changes in this table of contents will lead to a check-out of folders and model references that were changed. If you checkin these changed folders and references, this will result in a new revision of the table of contents these changes are part of. The check-out status of folders and model references is shown in the same manner as for shared models in the model browser. Also see section 5.2. A major difference between the model browser and the repository browser is that changes within the repository browser (i.e.: changes in the repository table of contents) are saved automatically. Another difference is that the names of model references cannot be changed in the repository browser. Architect will automatically synchronize the name of these references when the model name is changed within the model browser. Be aware that this will lead to a check-out of these model references by Architect. You must check them in yourself. When the name of a model reference cannot be synchronized due to a collaboration conflict, Architect will issue a warning. You may create a new folder by selecting the repository or a folder within, and then activate the command New folder in the context menu. You must provide a name for the folder, which can be changed again later. You may create a new (shared) model by selecting the repository or a folder within, and then activate the command New model in the context menu. As a result a new (shared) model is created with a default name that is referred to by a new model reference with the same name in the selected location. The new model is also opened in the model browser. Both model and model reference are checked out (by you) and must be checked in later. Shared models that are stored in a repository can be opened by connecting to the repository server, selecting the shared model in the repository browser, and then activating the command
Open model
Team support
Differences between Model browser and Repository browser
New folder
New model
Open a model from a repository
in the context menu. Note that shared models that are opened from a repository are not appended to the list of recently opened models in the File menu.
76
BiZZdesign B.V.
Save an existing model in a repository Copy a model reference
When you want to store an existing model in a repository, you must open this model, select the model object in the model browser (or view browser), and then drag it to the repository browser and drop it on its destination. You may copy model references within the same repository: you just copy the reference and paste it on the folder where you want to the copy reference to appear. Both references will refer to the same shared model. If you drag a shared model into the repository for a second time, again a copy reference will be created. The name of a model reference is synchronized with the model's name by Architect. When you change the name of the model object in the shared model, the names of all associated references automatically change with it. If necessary, Architect will check-out these reference objects. You will have to checkin these objects yourself at the time you think this is appropriate. Folders and model references can be moved within the same repository by dragging them with the mouse and dropping them on the folder you want to move them to. This only changes the table of contents of the repository. Repository objects (folders and model references) can be removed also. When you remove a non-empty folder, Architect will issue a warning. If you proceed, the folder and its contents are removed. Select the folder you want to remove, and activate the command Delete in the context menu. You may also remove reference objects. If you remove the last reference to a certain model, Architect will issue a warning, because deleting all references will render the model unreachable. Note that the model could still be opened by returning to a previous revision of the table of contents, using the command Revisions. You can close an opened repository (i.e.: disconnect from the repository server) by activating the command Close in the context menu when you have selected the repository in the repository browser. Like is the case for shared models, you can retrieve all revisions of the table of contents, and then open a specific previous revision. This, for example, brings back removed model references, after which you may open the associated models and view them.
Moving of folders and model references Removing repository objects
Closing a repository
Revisions
Architect
BiZZdesign B.V.
77
6.5 Roles and rights

To let users work with a repository and the shared models that are stored in it, they must be added to the list of users by the administrator of the (shared models in the) repository. As described om section 6.4, the table of contents has the same characteristics as a shared model. Roles and rights therefore can be assigned both to the table of contents, and to all shared models that are stored in the repository. In the rest of this section, 'shared model' means both 'shared model' and 'table of contents'.
Role Admins
Each shared model always contains the special role admins. All users that were assigned this role, have administrator privileges. This means that these users can administrate a shared model. Members of admins can assign this role to others, and remove it again. The user that creates a shared model is automatically assigned the role 'admins' for that model. The administration of users, roles and rights takes place via the commands User x Role and Roles and rights. These can be found in the context menu of a shared model, and in the main menu.
User x Role and Roles and rights
78
BiZZdesign B.V.
After activating User x Role, the following table opens:
Users are assigned roles. For each role, access rights can be specified. The list of users can be set separately on each shared model, so you can assign different rights in different models. Anonymous is a special role that applies to anyone that is not specificallly made a user. The rights you assign to this role thus apply to all 'anonymous' users. For administration of users and roles you use the options along the rows and columns in the User x Role table. The option New enables you to add a new user or a new role. After entering the name, this user (role), if it does not yet exist, is added to the shared model. You must specify user names that equal the login names of those users. Architect does not check the passwords itself, but relies on the fact that users identify themselves when logging on to Windows. By selecting of rows and columns in the table, existing users or roles can be removed, or names changed. However, an administrator cannot remove him or herself as a user. Also, the role 'admins' can never be removed or renamed. After users and roles have been entered, users can be assigned roles. This takes place the same way as in other cross reference tables in Architect : by clicking the cells, checks are set. A user is allowed take away the role 'admins' from him or herself. Because this might lead to undesirable results, Architect issues a warning.
Roles and rights
After all users have been entered, access rights can be specified. From the context menu of the shared model, choose the option Roles and rights.
The following table opens:
The rows of this table represent the contents of the shared model, the columns represent the roles. In the cells is shown which access rights (CRUD) the role has for which object. You can change these rights by typing the keys c, r, u, and d. Every object in the repository has a so-called Access Control List (ACL), with Access Control Entries (ACE). Every ACE specifies which group has which rights on an object (create, read, update, delete). A right is shown as c, r, u, d, if the right is not removed a is shown. These rights hold for all objects hierarchically under an object, unless some sub-object has its own specific rights. This is visualized by the font in the cell: an italics font denotes that this right is inherited from a parent-object; a non-italics font denotes that this right is specific for this object. If, for instance, you want to specify that users with role Application Architect assigned are only able to view Primary processes, select the row with the object-name Primary processes and remove the rights c, u, and d (using the keyboard). The resulting table looks as follows:
80
BiZZdesign B.V.
The rights for the model (model object) BPA are no longer in italics because a specific value is chosen for the underlying object Primary processes. For Business actors the rights are still in italics since these rights are inherited from the higher level. You can reset the default access rights by clicking the reset button in the table (you can select multiple elements for this operation).
Determine the user rights
To determine which rights a role g has for a certain object o the following rules are applied: 1. The acl of o is determined. This acl can be an inherited one. 2. In the acl the most specific aces that applies to g is searched. If there are no specific aces that apply to g, the hierarchy of roles in which g appears is searched. 3. First, all permitted rights are collected and applied 4. Then, all removed rights are applied. Removed rights overrule permitted rights unless the permitted right is more specific than the removed right. These rules are applied by Architect to determine the effective rights for objects and users. These rights are calculated and shown in the table so that you always have a correct overview over the rights, and you can change these rights to your needs. The resulting list with CRUD-rights determines which rights user g has on object o. The following table gives an overview over these rights: Right C R U Description Add underlying objects to the object, according to metamodel definition Read (view) the object as well as underlying objects: the object itself is visible, and the properties can be viewed Change (update) the object (name, profile properties, documentation)
Architect
BiZZdesign B.V.
81
Remove (delete) the object, as well as the underlying objects
Examples: o A C-right assigned to the repository-object within the repository-table-ofcontents, implies that the creation of folders and modelreferences is permitted. Within the contextmenu the following functons are available: create new model, create new folder. The properties can be assigned during creation (as long as the newly created object is not checked-in). After check-in, it depends on the U-right whether it is permitted to change these properties. o A C-right assigned to a folder-object (visible in the modelbrowser) within a shared model, implies that in this folder it is permitted to create underlying folders and domain schemes of any kind. o A U-right assigned to a view-object within a shared model, implies that it is permitted to change profile properties and documentationfields of the object shown in the viewbrowser. The graphical layouting of the related graphical diagram can be changed, like object positions. On the graphical diagram it is not permitted to place additional semantical objects; however, it is permitted indeed to add new groupings. Please note: A Uright assigned to a view-object does not specify the rights to change the properties of the semantical objects placed on the graphical diagram. These rights are determined by the rights of the related semantical objects. Also, with these rights it is not specified whether it is permitted to create new objects by means of drawing. Additional remarks: o A C-right has only meaning within the context of the metamodel; a Cright does have a meaning for a folder or a business process, but no meaning for a business object. o An R-right is only related to the object on the highest level (model or repository-table-of-contents): if a role has no R-right, the model can not be opened (as well as previous revisions). o To be able to delete an object, you need a D-right for this object as well as for underlying child objects, and a U-right for the object above. Users of role admins can define roles and users. These administration-rights are not related to the CRUD-rights. Depending on the rights certain operations can be executed. If an operation is not permitted due to lacking rights, this is shown in the messages window, as illustrated below.
82
BiZZdesign B.V.
Architect
BiZZdesign B.V.
83
7. Reporting and printing

In Architect , models or model parts with all, or part of the accompanying information can be reported automatically to a word processor, intranet or directly to a printer. The order in which a model is reported can be determined by the user. If viewfilters are active on views, for example a colourview or a tooltipview, these filters will be reported as well.
7.1 General settings

Reporting models Architect supports the reporting of models. To do so, select:
File Report model
By opening and selecting several models in Architect , it is possible to report more than one model in one report. Subsequently you can tailor the report by setting a number of options.
Report format
Under the tab General, you can select which report formats should be generated: Html format: readable by internet browsers like Internet Explorer 5 or higher (the reports require support of JavaScript and frames). The Html report is
84
BiZZdesign B.V.
suitable for intranet publication. The report is generated for easy navigating. For more information see section 7.1.1. Rich Text Format: suitable for use in word processors (like Microsoft Word). For more information see section 7.1.2.
Opening report
At the bottom of the general tab you can indicate that reports should be automatically opened after generation (in the corresponding application). In this way you dont have to search for the report on your computer. Report Settings Template. All report settings are saved in the template. When you change one or more settings in one of the other tabs, the button Save to template will appear. In this way you can save your personal settings and apply them to future reports. A template can be removed from the list via Delete template. The following pre-defined report settings are supplied with Architect : Complete per profile: all information in a model is reported per profile, in html and rtf format Complete per element: all information in a model is reported per element, in html and rtf format Documentation per profile: models are reported in combination with documentation, per profile in html and in rtf format. Documentation per element: models are reported in combination with documentation, per element in html and in rtf format.
Template settings Templates are used for reporting of models. The right template can be chosen in
Note that for read-only models (a file opened as read-only, or a specific revision from a shared model that was opened using Revisions and Get revision) these template settings can not be changed.
Default report settings
The locations for saving templates can be set, if you are authorised, via Defaults... The following window appears:
Architect
BiZZdesign B.V.
85
Personal & workgroup
Templates can be saved in three different locations; a location for personal use, for workgroup use (this must be a shared location, accessible for multiple users) and for the current Architect installation (user independent, but computer related). Architect will use the given order to search for report templates during generation (first within the personal location, subsequently in the workgroup location and finally within the Architect location). Standard, only the Architect location is filled in. When pressing the browse buttons (with three dots), the application settings window is opened. In the bottom part of this window, the options Use the following workgroup location and Use the following personal location can be checked. The directories can be filled in, in the accompanying lines.
86
BiZZdesign B.V.
Language settings
The language for reports can be set via the regional settings of your computer. Choose Settings Control Panel Regional Settings to change the language from Dutch to English or from English to Dutch. After restarting Architect , reports can be generated in the desired language.
Architect
BiZZdesign B.V.
87
7.1.1 HTML-settings
After clicking on HTML format in the general tab, the settings button to the right will become click able. HTML settings can be reached via this button, or via double clicking HTML format.
Legend and help
In the general tab the name of the start page can be set. You can refer in the intranet report to your own help files. Default is a help file that contains instructions on the use of the intranet report, including a legend of symbols and concepts (legenda). You can replace this with your own instructions. In the format tab of the HTML settings, the use of a custom cascading stylesheet can be selected. The total layout of an html report can be adapted to the users likings, or for instance, to an organizations house style. When nothing is filled in here, the standard Architect style sheet will be used. The standard Architect style sheet (ReportStyle.css) can be found in ..\data\reporter\. Style sheets are text files, which can be opened and edited in a program like notepad. ReportStyle.css contains some explanation on the style sheet and the use of it in Architect . When you have some knowledge of the html language, you can use the standard style sheet as a starting point to create and adapt your own style sheet. Standard, the style sheet (and possible accompanying files, like images) is copied to the report folder. In this way, the report folder is independent from other locations (like network drives). The report folder can be moved or send in total,
Cascading stylesheet
88
BiZZdesign B.V.
without losing any of its functionality in the reports. This option (include stylesheet with the report files) can also be switched off. In this case, the reports will contain links to the location of the style sheet. The report cannot function independently.
Image settings
Besides style sheets, there are some other settings on the format tab. The first is scaling of images. Images (of diagrams), which will be part of the report, can be scaled to a maximum size (in pixels). Furthermore it is possible to change the background colour of the images. A suitable colour (e.g. the background colour used in the style sheet) can be chosen via Choose. The last general setting is the use of tabs for documentation. The various documentation fields can be displayed via tabs in the HTML report. When this option is deselected, all documentation fields will be displayed in a table. On the following tab, Browser & Index, various options for the model browser and index in the HTML report can be set. The model browser has the same functionality as the one in Architect , except that both semantic objects and views are contained. It can be used to navigate through the entire model. The index gives an overview of all the elements in a model. By clicking an element in the index, the corresponding model element is displayed. Before generation you can decide to include the model browser and/or index. Also in the report itself (in the internet browser) it is possible to turn the model browser and index on or off.
Documentation tabs
Model browser
Index
Architect
BiZZdesign B.V.
89
You can select two index types; an index based on names and an index based on profiles. The name type will use an alphabetically ordered list of all the model elements. The profile type index will give an overview of the model elements, ordered by the used profiles (e.g. the entry business process description will contain a list of subentries of all the elements using the profile business process description). Both types of index are available in a report (you can switch between the two types in the report). An extra index level is added when the option where used is selected. An index element to which is referred more than once (e.g. an actor) can be expanded to display all model elements, which refer to the specific index entry.
Profile summary
Standard, the frame with browser and index is displayed on the left side of the window. It is possible to have it placed on the right. When the option Clicking indexentry opens profile summary is selected, an extra overview of all the used profiles is displayed (in table form) besides the model diagram, after clicking an index entry. The use of frames and popups can be configured on the frames & popups tab. The model browser, index and profile summary and profile overview can all be displayed in popup windows. Standard they are displayed in frames. It is also possible to change the frames in popup windows in the report itself (only when the option Do not allow users to switch between frames and popups is switched off). The size of the various frames can be adjusted with the four slides. Users can also adjust the size of the frames in the report (only when the option Do not allow users to
90 BiZZdesign B.V.
Frames & popups
resize frames is switched off). Frames will appear and disappear smoothly with the option Show/Hide frames smoothly turned on.
Diagram
On the last tab Diagram you can indicate which diagram should be the starting page of the HTML report. You can have the diagrams profile summary opened in the first page as well (via the option Open the diagrams profile summary). The standard starting page is a title page.
Architect
BiZZdesign B.V.
91
Refresh report
Some settings for Browser & Index and Frames & Popups can be changed in the HTML report itself. However, you can recall the original settings (selected for report generation) at every moment by refreshing the internet browser.
92
BiZZdesign B.V.
7.1.2 RTF settings

The RTF settings can be reached by clicking RTF format in the general tab of the report settings and subsequently choosing settings, or by double clicking RTF format. The RTF format is readable for most word processors, however not by the older Microsoft Word 95. In case you use Word 95 for reading the report you should check the option Word 95 compatible.
The other settings deal with the layout of the report. You can choose to use headers and footers (further adjustable via page setup). You can add a table of contents, with a specified number of levels to the beginning of the report. You can add an index to the end of the report. When the option where used is checked, the index will contain references to page numbers of the places in the report where index-elements are used. Finally you can choose to start each element on a new page and to use page breaks instead of section breaks.
Headers and footers
A window for layout settings appears via the page setup button. Header and footer can be configured in the upper part of this window. There are three places where text and special codes can be filled in. These places represent the locations in the header and footer (left, centre and right). The use of file names, directories, page numbers etc. is made possible with the special codes. The following codes can be used: %m: model name; %f: file name; %F: full path name; %r: directory name;
BiZZdesign B.V. 93
Architect
%t: date/time file; %T: actual date/time; %d: diagram name; %D: full diagram name (handy in a nested diagram structure); %A: application name (Architect ); %n: page number; %N: total number of pages.
These codes can be combined with each other and with free text, as demonstrated in the image below;
Furthermore, the paper size and source can be selected. Other options are the orientation (portrait or landscape) and the margins (left, right, top and bottom).
94
BiZZdesign B.V.
7.2 Report location

Report location
The output location for the report can be set on the location tab. A report folder is created for every report generated. Architect will use the name of the reported model as a standard name for the report folder. This name can be changed. The report folder will be created in the location mentioned at Report Location.
7.3 Contents report

On the tab Contents you can specify the model parts that are included in the report. You can select if the report contains the pictures of the views (Diagram images). Furthermore you can determine whether or not documentation is included in your report, and if so, which documentation fields are included. Besides single documentation fields (for every model element), all documentation fields of the same kind can be reported in one table. E.g. when your report contains four documentation fields, four tables will be part of the report, which show an overview of all elements in the model containing those fields.
Architect
BiZZdesign B.V.
95
7.4 Diagrams
Diagrams
On the diagrams tab you can indicate which diagrams and components should be part of the report. Via the tree structure you can choose diagrams and components one by one. Via the buttons all and none, you can select and deselect all diagrams and components at once.
7.5 Profiles
Profiles
On the tab Profiles you can determine which profiles are included in the report. Profiles that are not assigned will not be reported either. So you only have to exclude the assigned profiles that should not be in the report (for instance because that information is not relevant for the reader of the report). You can choose for an overview per profile, per model element or for both. When you deselect both options, no profile information will be part of the report.
96
BiZZdesign B.V.
Per profile or per element
If you choose the overview per profile, the information for every diagram will be ordered according to the existing profiles. This means that per diagram, for all assigned profiles (like application description, goal, principle, documentation etc.) tables will be created which will contain this information. If you choose for the overview per element, the information for every diagram is ordered according to the model elements (applications, roles, etc.). This means that per diagram, for all model elements, tables will be created which will contain the information.
Architect
BiZZdesign B.V.
97
7.6 Tables
On the Tables tab you have the opportunity to leave out empty columns and rows from tables in the report. You can choose to only report tables for elements with a name (e.g. arrows without conditions will not be reported separately). Furthermore you can choose to have a column with the element types (business process, business actor, etc.).
In the bottom half of the window you can select cross tables and custom defined tables to be part of the report (for an instruction on defining custom tables and using cross tables, see section 3.11). Custom defined tables can be located in three places. There is a difference between application tables, group tables and personal tables. The application tables are located in the standard folder (in the install location). The group- and personal tables are kept in user defined locations. These locations can be set via the General tab of the report settings (default button, see section 7.1), or via Architect : Options -> Application settings. When the group- or personal location are left empty, the options for group tables and personal tables will not be shown on the tables tab. The cross tables can be found under XRefTables. The list of cross tables, which can be chosen for the report, is automatically generated at the start up of Architect . The automatic generation is based on profile definitions (for more information see section 3.10).
98
BiZZdesign B.V.
7.7 Reports to word processors

Architect models can be easily reported to word processors using the rtf-report. This format can be imported in most text editors like Word and WordPerfect. Select the report to rtf, as described in section 7.1.
Automatic updates
When you modify your model after reporting, you can update your report with File Report model again. Then all report files will be generated again. Please take care that none of the files is opened in Word or another program. Otherwise you get an error message and the open files will not be updated.
Table of contents The generated table of contents and index should be updated after being generated. Select all (in Word Ctrl+a) and give the command update fields (in & index
Word function key F9).
Report order
The order in which a model or diagram is reported, and which shows in the order of activities in a (documentation) table, can be determined by the user. You can choose between from left to right (default), from top to bottom, from right to left and from bottom to top, and combinations of these possibilities. The order can be set at the level of the model as a whole, at the level of diagrams, at the level of blocks, and at the level of nested actors, all of these via the property window of the corresponding model element (in the basic profile). If you set the report order of the model (using the basic profile of the model in the model browser), the setting becomes the default for this model. On the lower levels in the model (diagrams, blocks, actors) you can set a different order if necessary, which is the default for the underlying level. In this way you can for instance determine that the report order for the model is from left to right, and for certain blocks from top to bottom. The report uses links to add the diagrams in the report, so diagrams are not physically present in the report file. When you move the report to another computer, or e-mail it to someone else, the diagrams will be missing. You can prevent this by saving the diagrams in the report beforehand. This is done, for example in Word, by first selecting the document (Ctrl+a) and then via Edit Links choosing Save picture in document. If you then save the document, the diagrams will be physically contained in the document, and you can move or e-mail the document. The report is saved in the designated directory in a sub-directory RTF. This directory contains a file <filename>.rtf. This directory also contains the different diagrams from the process model as separate pictures (*.emf).
Links
Files
7.8 Team
ONLY AVAILABLE WITH THE ADD-ON TEAM-SUPPORT
Architect
BiZZdesign B.V.
99
With the add-on Team-support it is possible to report revision information. In tab Team you specify whether you would like to have the modelrevision on the report titlepage. In this case the the reporters workspace, the revision reported and the indication whether changes have been made, are shown. Also, you can specify whether the report shall contain a modelrevision overview (in a separate section).
100
BiZZdesign B.V.
7.9 Reports to intranet

Architect models can be published on intranet or Internet by generating an html report. Users can easily view and browse these models and the accompanying documentation, using their standard browser. Choose the Html format on the report settings general tab.
Intranet use
The html report is written to the designated directory in a sub-directory Html. This directory contains a file AA_ReportStart.html, which is a shortcut to the intranet report. Open this file in your browser, for instance by double clicking on it. If you choose the right option, this report is automatically opened (see section 7.1). The other files in the directory are automatically loaded on selecting a menu or clicking on objects in the diagrams or links in tables. The HTML report is divided in a number of frames, depending on the contents. A toolbar is situated in the upper part of the window. This toolbar contains various icons on the left and a dropdown menu for diagrams on the right (for navigation through diagrams). The icons have the following functionality: With this button the model browser re-appears after it has been closed (the model browser can be closed by clicking the little cross in the corner of the frame). With this button the model index re-appears after it has been closed (the model index can be closed by clicking the little cross in the corner of the frame) Via this button, a link is displayed, in a separate window. The link saves the current state of the report. The current state can be recalled by following the link. With this button a diagram can be displayed over the full width of the screen. Other frames will disappear. The diagram will be brought back to its regular size. Frames, present before, will be displayed again. Instructions on the use of the HTML report, including a legend of the used symbols.
Frame layout
Browser functions
show model browser
show model index
show current hyperlink show diagram full size restore diagram to normal size show help
On the side of the report there is a frame with the menu structure. Underneath this, there is a frame with the index (only when you chose to report these elements). Standard, the menu and index are placed on the left, however you can choose to have them displayed on the right.
Architect
BiZZdesign B.V.
101
Menu
Via the menu you can choose a diagram, or an overview table, belonging to the diagram. Within a diagram, every object is clickable. All relevant information on the selected object (like documentation) will appear after clicking. This information is presented in a table at the bottom of the window. The tables can contain links to attributes and profiles, amongst others. When you follow one of these links, a second frame, with the extra information, will appear at the bottom. Besides this it is also possible to display links to other documents (like work instructions in a word processor). To zoom in on a collapsed behaviour block, click on the underlined name, or browse via the menu. The menu presents an overview comparable to the menu browser in Architect . Another option to browse through the model is using the index. All elements of the model are sorted, either by profile or by name (alphabetically). An overview can be given per role or actor, to show where they are used in the model (only when the option where used is chosen during generation). To update the report after changing your model, it is sufficient to choose File Report model. All relevant files are generated again. Refreshing the image in your browser results in the updated report An html report can be moved to another directory or drive, or sent by e-mail to someone else, by moving or sending the complete directory Html Frames. Especially when e-mailing the report, it is advisable to zip this directory beforehand, using a zip-application like WinZip. If you send the directory as a self-extracting archive, the recipient does not need to have the zip-application on his own computer.
Index
Update report
Sending report
102
BiZZdesign B.V.
7.10 Printing of models

In Architect , process models, or parts of it, can be directly printed on any printer available on your system. Printing can be done using the menu
File Print
or Ctrl+P.
You can choose whether to print to complete model, certain diagrams, or the current selection. The number of copies can be set, and on how many pages the print must be fit. The last option can be very useful when a large printout of the model is needed, for instance to use the printout in a workshop. After choosing Properties you can change the properties of the printer, like which printer, double sided printing, paper size, etc (options depending on your printer).
Print preview
It is possible to make a print preview of the selected diagram. This preview shows the diagram as it will be printed on the selected printer. The preview allows showing several pages at the same time, and zooming in and out. You can print preview via Edit Print preview, or via the button on the menu bar.
Architect
BiZZdesign B.V.
103
Printing order Page set up
When printing the complete model, Architect prints the diagrams in the order in which they appear in the model browser. Using File Page Setup you can set several options for printing and reporting. The settings in this dialog are also used for the rtf reports. For the various options, see section 7.1.2.
104
BiZZdesign B.V.
Appendix A Profiles
Introduction
A profile is formed by all the properties of an element which can be set. Besides the standard profile, which is assigned to all elements (with properties like name), you can add other profiles. This makes it possible to assign specific properties to elements (e.g. properties needed in certain analysis).
Use custom profiles
In Architect it is possible to define and use profiles as a single user or within a group of users. In this way you can add new properties yourself. User defined profiles will appear in reports in the same way as standard profiles do. It is also possible to use a number of various views, based on the new profiles. This can be helpful to lay down properties, which are not defined in the standard profile, within a project, department or organization. This instruction describes how to define profiles. A consistent definition of profiles, in coherence with existing profiles, is not trivial though, and has consequences for the models created based on these profiles. Hence, it is sensible to define custom profiles in consideration with BiZZdesign.
Necessary files
Required files
The definition of a profile requires the creation of three files. These files lay down the structure and names of the profile properties. The first file has the extension .mpd. It contains the definition of the profile. The other two files both have the extension .mps. They contain the names of the profile that Architect will use in presentation to the users. One of the files contains Dutch expressions, the other one English expressions. You are free in naming the files, although it is recommended to use clear names like my profile.mpd, my profile nl.mps and my profile en.mps. In this section, the syntax and use of the various files is discussed. A description on the correct use of the files in Architect will follow next.
Standard profiles
When you start defining profiles you can use the standard profiles of Architect as an example. These can be found in the following folders (provided that the installation was done according to the standard procedure). Location
C:\Program Files\BiZZdesign\Architect \Data C:\Program Files\BiZZdesign\Architect \Domains\Studio\Component ( and all folders below this folder)
Purpose Application profiles Domain-specific folders each domain

105
Architect
BiZZdesign B.V.
folders, each domain under this folder has its own profiles in the folder data. Examples of domains are: Application, BusinessActor, BusinessProcess, etc. The files can be easily viewed with a program like Notepad
Attention: BiZZdesign strongly advises against changing the standard profiles! Architect could stop working. Always add your own profile definitions in separate files, so can always restore the original situation.
The mpd-file
Profiles are defined in the mpd-file. A profile consists of a set of properties (processes, actors, etc.) that can be assigned in Architect . Not only can you lay down the properties of a profile in the mpd-file, but you can also lay down to which objects (processes, actors, applications) this profile can or should be assigned to. A special syntax is used in defining profiles. This syntax will be described next. A profile definiton has the following structure:
PROFILE <profile name> { assignable to <object type list>; <property list>; };
In the example, a profile with the name <profile name> is defined. The profile can be assigned to an <object type list> (process, actor, application, etc.). The profile consists of a list of properties <property list>. The use of brackets {} and semicolons ; is essential.
Profile name
The profile name, declared in the mpd file, is the internal name of the profile. The name that will be presented to the users in Architect , can be declared in the mpsfile (see the related section). The first thing that should be declared in a profile definition (after the profile name) is, if the profile is always assigned to objects, or that a user has to explicitly assign the profile to objects. A user can explicitly assign profiles in the properties window under the Profiles tab. An assignable to profile will be visible in this window. A profile that is always assigned to will not appear in this
106 BiZZdesign B.V.
Assignable to / always assigned to
window. Use always assigned to when the concerned properties should be used in all models.
List of objects
In the object list you can declare to which model objects the profile can be assigned to.
assignable to BusinessProcess, BusinessActor, Application;
In the above-mentioned example, the profile can be assigned to processes, actors and applications. The value that can be used are specified in the chapter on object types.
List of properties
In the properties list you define the various properties, or attributes, contained in the profile. This list consists of attribute types and attribute names, separated by semicolons.
string integer boolean currency product; amount; in stock; price;
In this properties list a product is declared, together with the amount, a status (in stock or not) and the price. Both standard types as well as custom defined types can be used. Amongst others, the following types are standard available types in Architect : Name
string rtf integer real boolean currency date link
Meaning String (regular text) string in Rich Text Format An integer A real number True or False An amount of money (in various currencies) Date Hyperlink
The profile Goal is being defined in the example mentioned below. The profile describes for principles (ArchitectPrinciple) the source, the owner, and the status of this principle.
Type Goals PROFILE Goal { assignable to ArchitectPrinciple; rtf BusinessActor rtf source; owner; status; = set Goal;
};
Architect
BiZZdesign B.V.
107
Subsequently, in Architect this profile can be chosen in the properties window of a principle:
Initial values
Properties can be given initial values. These values can be specified in a properties list. This is illustrated in the following example:
PROFILE Initial { always assigned to BusinessActor; integer real boolean string amount = 1; number = 2.3E2; necessary = false; company = BiZZdesign;
};
Hidden profiles/ properties
A profile or a property can also be hidden. This means that the profile or property is not visible in the properties window. This is specifically useful for properties or profiles that should not be set, changed or seen by users. Examples are information that should be exchangeable with other tools, and results of quantitative analyses. With HIDDEN it can be indicated that a property is hidden.
PROFILE Secret { assignable to BusinessProcess; }; HIDDEN integer pincode = 1234;
This profile can be assigned to business processes, but the property is not visible in the properties window. One profile can contain hidden as wel as non-hidden (visible) properties. Non-hidden properties of a hidden profile appear in the basic profile.
108
BiZZdesign B.V.
Read-only
In a similar way attributes can be declared readonly. This means that the property is visible, but not changeable. A property can be hidden and read-only at the same time. See the next example:
READONLY integer HIDDEN READONLY boolean result; true;
Referred
A property of type referred can be used in reference objects such as BusinessActorRef, DataObject, etc. Using this, one indicates that the property refers to the equally named property of the referred object. The value of the property is shared between reference object (ItemRef) and referred (Item). If the value in the referred object is changed, the value in the reference object is also changed. If, however, you change the value in the reference object, then the values will not be shared any longer, and both objects will have their own value for the property. If you later decide that the values should be coupled again, select the property of the reference object (ItemRef) and choose Standard in the Properties window. A property of type inherited can be used to have an object inherit a value from (one of) its parent object(s). If an object does not have its own value for the property, then all parent objects (hierarchical higher objects) are searched for a value. However, if you change the value for an object itself, then the value will no longer be inherited from the parent objects. Moreover, the child objects of the object that has its own value will now inherit this new value from their parent object. If you want to inherit the value again from a parent object, select the property, and choose Standard in the Properties window. A profile can extend another, existing, profile. When the new profile is assigned to an object, the object will not only be assigned with the new properties, but also with the properties of the existing profile. An example is the profile VerySecret that extends the previous defined profile Secret with the property motivation. This property lays down the motivation for using something very secret.
PROFILE VerySecret extends Secret { assignable to BusinessProcess; HIDDEN integer string pincode = 5678; motivation;
Inherited
Extending existing profile
};
Furthermore the initial background color is changed. Via the extends mechanism you can add new properties and change the initial value of existing properties.
Moving properties
In a profile definition it is possible to define an already existing property again. In this way the property will be part of the new profile, but not anymore of the existing profile. You can use this behaviour to take a property out of the basic profile and into another one. A reason for this could be the desire to change the grouping of existing properties.
Architect
BiZZdesign B.V.
109
Comments
Adding comments in profile definitions is recommended. This way, the meaning and purpose will stay clear for you and for other users. Comments are preceded by //, as demonstrated in the next example:
// Profile for marking very secret processes // The profile extends the marking of secret processes // version 1, 3-6-2005 // author BiZZdesign PROFILE VerySecret extends Secret { assignable to BusinessProcess; // temporarily only for actions HIDDEN integer string pincode = 5678; // this is the pincode, shall not be visible motivation; // motivate why the action is very secret
};
Defining types
You can define custom types in the profile language. To create custom types you have a number of basic types at your disposal: enumeration (enum), structured collection of properties (struct), union (union), list (list), set (set) and alias (alias). Custom defined types can be used in the same way as the predefined types. The enumeration type consists of an enumeration of values. In the following example a new type HairType is defined. Subsequently, this type can be used in a profile to define the property hair color.
type HairType = enum { blond, brown, grey, black, white, red };
enum
PROFILE Secretary { Assignable to BusinessActor; HairType BusinessRole string HairColor; role; characteristics;
};
In the properties window (in Architect ) this will create the following options:
110
BiZZdesign B.V.
struct
With struct you can create structured sets of coherent properties. Examples are an amount, consisting of a number and a currency, or a color consisting of a coding for red, green and blue:
type Color = struct { int R; int G; int B; };
Values are attributed to a struct by lists of pairs name:value, divided by commas and enclosed by brackets:
HIDDEN Color bg = { R:000, G:000, B:245 };
union
A union is similar to a struct. The value of a union is only one of the properties of a struct. An example is the property RealInt, which is either a real or an integer.
type RealInt real int }; = union { realvalue; intvalue;
The value of a union is declared via the name and the value of the property, as in realvalue:2.3.
list
A list is an ordered typed collection, like a list of numbers, a list of colors, etc. Elements can appear more than once in the list.
type RealIntList = list RealInt;
The value of a list are declared via the values of the elements, enclosed by [], as in [ realvalue:2.3 , intvalue:8, intvalue: 12 ].
set
A set is an unordered typed collection, in which an element can appear at most one time: duplicates are not possible (unlike a list).
type strings = set string;
Architect
BiZZdesign B.V.
111
The value of a set is declared via the values of the elements, enclosed by ( ), as in (string1, string2 , string3 ).
alias
The alias-structure makes it possible to define synonyms of types:

type Probability = alias real;
Restrictions
There are some restrictions to the naming of types, profile names and properties: All type definition- and profile definition names should be unique All profile names in all profile definitions should be unique A type definition name cannot be equal to a profile definition name A profile name cannot contain spaces or special punctuation marks Names of profiles and attributes, as defined in the mpd-files will also be saved in the Architect models. It is advised to use short (yet understandable) names in order to limit the size of the Architect files. There is no reason for using longer names, because the end-user will not see these names. For easy reference it is advised to save related profile definitions in one mpd-file. This is not necessary though. All profiles can be saved in one file, but every profile can also be saved in a separate file.
Tips
The mps-files
Two mps-files belong to an mpd-file. The mps-files contain the translations of names of the profiles and attributes in Dutch and in English. The names defined in these files, are the names that are used in Architect and that will re appear in generated reports. An mps-file has a fixed structure like the example mentioned below:
; Translation of the custom extension of the documentation field language = en <profilename>.<property> = <Name property>
In the beginning of the mps-file, the concerned language is indicated, en for English and nl for Dutch. Comment lines can be placed prior to this line. These first comment lines have to start with ; After the language line, comment lines are also allowed to begin with //. Subsequently a translation should be given for every property definition in the mpd-file, according to one of the following rules:
<profilename>.<property> *.<property> <profilename> = = = <name property> <name property> <name profile>
112
BiZZdesign B.V.
In the first line only one property in one profile is translated. In the second line all properties with a given name in every profile are translated. In the third line a profile name is translated. The use of spaces in the translations is allowed, given that the sentence is not distributed over multiple lines. In the hair color example the mps-file could look like this (partly shown):
; translation of the secretary profile language = en // type names HaarType.blond HaarType.grey // property names Secretary Secretary.Haircolor = = Department secretary Her hair color = = Blond Silver grey
In the properties window this has the following result:
Reports
During reporting of models you can choose which profiles should be part of the report. Also the custom defined profiles will be listed as options.
Architect
BiZZdesign B.V.
113
Location of the files

The three files mentioned above have to be placed in directories in the following manner. Place the file my profile.mpd in a folder, for instance the folder Data. Create a sub-folder in this folder with the name nls. In nls, create two subdirectories en and nl. Place the file my profile en.mps (with the English names) in the sub-folder en. Place the file my profile nl.mps (with the Dutch names) in the sub-folder nl.
Subsequently you have to indicate that Architect should use these definitions. You can do this via Options Application Settings. You can decide if the profiles should be used as personal or as workgroup profiles. Now specify the folder where the mpd-file is located (in the example Data).
Application settings
Error reporting
Architect needs to be closed and restarted before the profiles can be used. If you have made errors in the profile definitions, Architect will report the error, indicate what the problem is and close subsequently. You can open the concerned
114
BiZZdesign B.V.
file and repair the error. If you dont succeed in repairing the error, remove the file from the folder, so Architect can start correctly. When you exchange models with other Architect users, it is recommended to use the same profiles, for instance via the workgroup folder. Workgroup profiles and personal profiles can be used at the same time.
Personal and group profiles

In Architect you can define personal as well as group extensions to the standard profiles. Architect gives a priority to group profiles. This means that group profiles are checked, for added profiles, before personal profiles.
Changing the standard profile

Architect presents a so-called basic profile for all objects, with amongst others the objects name. This section describes how to extend this basic profile. The basic profile is a generated profile and can therefore not be found explicitly as a profile in an mpd-file: this basic profile shows all not-hidden properties within all hidden profiles that can be assigned to this object. In Architect each object-type has a hidden profile, with amongst others the nothidden property nm, with English translation name. As a result, within the basic profile the property name is shown. Examples of these hidden profiles are BusinessProcess (defined in BusinessProcess.mpd in the folder Domains\Studio\Component\BusinessProcess\data) and InfrastructureNode (defined in TechnicalInfrastructure.mpd in the folder Domains\Studio\Component\TechnicalInfrastructure\data).
Attention: BiZZdesign strongly advises against changing the standard .mpd-files. Architect could stop working. Use separate files to define additional profile definitions.
For extending the basic profile, new hidden profiles shall be defined with nothidden properties. This new profile can be assigned to all object types, but also to specific object types. In the example below for all objects the basic profile is extended with ID, and processes in particular are extended with owner. The mpd-file contains the following profile definitions:
HIDDEN PROFILE ID { always assigned to } string AbstractElement, AbstractRelation, AbstractContainer, AbstractCompound; ID;
Architect
BiZZdesign B.V.
115

HIDDEN PROFILE MyProcess { always assigned to BusinessProcess; BusinessActor }
owner;
and the accompanying mps-file with the English translations contains:

language = en *.ID = ID *.owner=owner
As an administrator, when configuring Architect with these additional profiles (in other words: these files are placed in the already existing domain folders), all users have these extensions in the standard profile.
116
BiZZdesign B.V.
Appendix B Documentation fields

Introduction
Architect offers extensive possibilities to document objects and to link to other documents or intranet sites from processes. All elements in a model, but also the separate diagrams and the model itself can be provided with documentation. Select the model element you would like to document and type the documentation in the documentation fields at the bottom of the screen (in the documentation window). Besides typing it is also possible to copy and paste documentation from other applications (like Microsoft Office programs).
Standard field
It is possible to define your own documentation fields within your models. Standard every object in a model (objects, relations, diagrams etc.) has one documentation field Documentation. You can add new documentation fields according to your needs by defining additional documentation profiles. This appendix describes how this shell be done. The Architect default configuration is the documentation field Documentation for all objects (objects, relations, diagrams) within the model. It is possible to define new documentation fields, both for personal use and for use in groups. For instance, this makes it possible to register for a business process the starting points, the design choices and the modelling choices. When these documentation fields have been defined separately, they can also be reported separately.
Additional fields
Necessary files
New documentation fields can be defined in a so-called documentation profile. A documentation profile consists of three files, defining structure and names of the fields. One mpd-file for the definition of the documentation fields and two mps files with the names of the fields, as Architect presents them to the users (one with English terms and the other with Dutch terms). The files names are not important, but it is recommended to use meaningful names for these files, like docextension.mpd, docextension nl.mps and docextension en.mps. The files should be placed in directories in the same manner as the other custom profiles. (see the section on profiles).
Architect
BiZZdesign B.V.
117
The mpd-file
The mpd-file has the same fixed structure. The example below shows the contents of the mpd file for a documentation profile.
// Personal extension to the standard documentation field HIDDEN PROFILE MyDocTemplate extends DocumentationTemplate { always assigned to AbstractElement, AbstractRelation, AbstractContainer, AbstractCompound; HIDDEN rtf HIDDEN rtf HIDDEN rtf startingpoints; designch; modellingch; // starting points // design choices // modelling choices
Comment lines (starting with //) can be used to explain the defined fields. The extension to the standard DocumentationTemplate in this example is named MyDocTemplate. It consists of three fields. Every field is formed by the line:
HIDDEN rtf <name field>;
The line is closed by a ;. The name of the field can be freely chosen, but should not contain any spaces or special punctuation marks. It is advised to use short names, because the name appears often in the saved model. You can define as many fields as wanted. The standard documentation field is always present (but of course, you can leave them empty).
Always assigned to
Always assigned to gives you the possibility to define documentation fields per
object type. The example above contains:

always assigned to AbstractElement, AbstractRelation, AbstractContainer, AbstractCompound;
The extra documentation fields in the example are assigned to the mentioned objects. Now you can also use multiple sets of documentation fields. With always assigned to you can point out precisely to which object types the various fields should be assigned. In this way you can define different documentation fields for behaviour elements, actors, data types etc. The next example illustrates this by defining an extra set of documentation fields, only for actors (type BusinessActor).
HIDDEN PROFILE ActorDocTemplate extends DocumentationTemplate { always assigned to BusinessActor; HIDDEN rtf edu; // education HIDDEN rtf exp; // experience }
Combined with the previous profile (on the previous page), all objects will have the extra fields from the profile MyDocTemplate. Above this, actors (BusinessActor) will have the additional fields from the profile ActorDocTemplate.
118
BiZZdesign B.V.
You can define as many extra profiles with documentation fields as you like. Every profile (standard or custom) can be extended (via inheritance) by a new profile. For a specific object, Architect will show all fields, from all the profiles that extend DocumentationTemplate (directly or indirectly), provided that the object is mentioned in the always assigned to set. A separate chapter gives an overview of Architect s object types that can be used for defining and assigning documentation profiles.
The mps-files
Two mps-files belong to an mpd-file. The mps-files contain the translations of the names of the documentation fields in Dutch and in English. An mps-file has a fixed structure, demonstrated in the next example:
; Translation of the custom extension of the documentation field language = en // Comments MyDocTemplate.startingpoints MyDocTemplate.designch MyDocTemplate.modellingch = = = Starting points Design choices Modelling choices
In the beginning of the .mps-file the language to which is translated is specified, nl for Dutch and en for English. Before this line comment lines may be specified, if these start with a ;. After the language specification line a comment line may also start with //. For each field definition from the .mpd-file a translation shall be given using the following syntax:
<Profilename>.<fieldname>= <translation fieldname>
The associated dutch .mps-file looks like this:

; Translation of the custom extension of the documentation field language = nl // Comments MyDocTemplate.startingpoints MyDocTemplate.designch MyDocTemplate.modellingch = = = Uitgangspunten Ontwerpkeuzes Modellingskeuzes
Application Settings
Via Options Application Settings Architect can be configured to use the new profile definitions. There are options for personal use and for workgroup use. Select the folder where the mpd-file is saved (in the example the folder Data). After this,
Architect must be closed and restarted, before the new documentation fields can be used. When you exchange models with other persons, it is recommended to share profiles as well (e.g. via a workgroup folder). Apart from this, it is possible to use both group profiles and personal profiles. The result of the documentation field definition, translation and Architect settings is the following documentation window:
During reporting of models you can choose which documentation fields should be part of the report.
Personal- and group profiles

In Architect you can define personal as well as group extensions to the documentation field. Architect gives a priority to group profiles. This means that group profiles are checked, for added documentation fields, before personal
120
BiZZdesign B.V.
profiles. The standard DocumentationTemplate is extendible multiple times. When using a group profile, together with a personal profile, the mpd-files would look as follows:
// Group profile HIDDEN PROFILE GroupDocTemplate extends DocumentationTemplate {
// Personal profile HIDDEN PROFILE MyDocTemplate extends GroupDocTemplate {
Changing the standard profile

The extension of the standard documentation field is discussed in the previous section. As an administrator for your application, a department or the organization you can also change the standard profile. By doing this you can delete or change the standard documentation field. You can give all users a different standard profile via a workgroup folder. To do so, adapt the standard documentation profile documentation.mpd and the two accompanying mps-files in the folder C:\Program Files\BiZZdesign\Architect \Domains\Studio\Component\Data. The profile documentation.mpd looks as follows:
HIDDEN PROFILE DocumentationTemplate { always assigned to AbstractElement, AbstractRelation, AbstractContainer, AbstractCompound; HIDDEN rtf doc; }
With the accompanying documentation.mps:

language = en *.doc = documentation
You can change the name of this documentation field in the mps-files, or add extra fields by adding lines in the mpd-file as demonstrated in the following example:
HIDDEN PROFILE DocumentationTemplate { always assigned to AbstractElement, AbstractRelation, AbstractContainer, AbstractCompound; HIDDEN rtf startinpoints; // starting points HIDDEN rtf designchoices; // design choices HIDDEN rtf modellingchoices; // modelling choices }
Architect
BiZZdesign B.V.
121
Subsequently the mps-files should be changed as described before. If Architect is configured to use this, changed, documentation profile, all users will be able to use the additional documentation fields.
122
BiZZdesign B.V.
Appendix C Object types and relation types

In Architect the following object types are defined, categorized in domain independent types, and domain specific types. Besides that Architect has a set of relation types.
Domain independent object types

name
AbstractContainer Component AbstractScheme SemanticScheme AbstractView AbstractFolder AbstractElement AbstractCompound AbstractFolder
Meaning Base class for objects containing other objects Model or component Base class for Schemes Base class for Views Folder in a model Base class for elementaire objecten Base class for samengestelde objecten Folder in a model
Domain specific object types

name
ApplicationScheme ApplicationComponent ApplicationCollaboration ApplicationInterface ApplicationService ApplicationFunction ApplicationInteraction ApplicationDataScheme ApplicationDataObject ArchitectPrincipleScheme ArchitectPrinciple ArchitectView GroupingScheme Grouping ViewFolder BusinessActorScheme BusinessActor BusinessRole
Derived from type

AbstractScheme AbstractCompound ApplicationComponent AbstractElement AbstractCompound AbstractCompound AbstractElement AbstractScheme AbstractElement AbstractScheme AbstractCompound AbstractView AbstractScheme AbstractCompound AbstractCompound AbstractScheme AbstractCompound BusinessActor
Architect
BiZZdesign B.V.
123
BusinessCollaboration BusinessInterface BusinessFunctionScheme BusinessFunction BusinessInformationScheme BusinessObject BusinessRepresentation BusinessMeaning BusinessProcessScheme BusinessProcess BusinessEvent BusinessInteraction BusinessProductScheme BusinessProduct BusinessContract BusinessService BusinessValue TechnicalInfrastructureScheme InfrastructureArtifact InfrastructureInterface InfrastructureService InfrastructureNetwork InfrastructureNode InfrastructureSystemSoftware InfrastructureDevice InfrastructureCommunicationPath
BusinessRole AbstractElement AbstractScheme AbstractCompound AbstractScheme AbstractElement AbstractElement AbstractCompound AbstractScheme AbstractCompound AbstractElement AbstractElement AbstractScheme AbstractElement AbstractElement AbstractCompound AbstractCompound AbstractScheme AbstractElement AbstractElement AbstractCompound AbstractCompound AbstractCompound InfrastructureNode InfrastructureNode AbstractElement
All domain specific types are derived (directly of indirectly) of one of the base types SemanticScheme, AbstractCompound of AbstractElement.
Relation types
Name
AbstractRelation SpecializationRelation CompositionRelation AggregationRelation AssignmentRelation RealisationRelation TriggeringRelation FlowRelation UseRelation AccessRelation AssociationRelation
Meaning Base type for all relations Specialization Composition Aggregation Assignment Realisation Causality Flow Used by Access Association
124
BiZZdesign B.V.
Appendix D Interface BiZZdesigner - Architect

This appendix describes the interface between BiZZdesigner and Architect models. First, the BiZZdesigner objecttypes are taken as a starting-point: for each BiZZdesigner objecttype it is specified which Architect objecttype is created while dragging-in. A categorisation is used of domain-independent and domainspecific objecttypes and relation types. After that it is specified how assigned profile values result to new Architect objects.
Domain independent object types

BiZZdesigner
AbstractContainer Component AbstractScheme SemanticScheme AbstractFolder AbstractElement AbstractCompound AbstractFolder AbstractInterface AbstractInterfaceElement AbstractInterfaceEntry AbstractInterfaceExit AbstractFolder AbstractFolder -
Architect
Domain specific object types

All domain-specific types are (directly of indirectly) dreived from one of the basetypes AbstractScheme, AbstractCompound, AbstractElement or AbstractRelation. BiZZdesigner
ActorScheme Actor BusinessFunction Actor with Function profile assigned Role Actor with Role profile assigned System Actor with System profile assigned
Architect
BusinessActorScheme BusinessActor BusinessFunction BusinessRole ApplicationComponent
Architect
BiZZdesign B.V.
125
AbstractInteractionpoint Interactionpoint CrossconnectPoint InteractionpointElement InteractionpointRel ActorInterface BehaviourScheme BehaviourElement Action Trigger EndTrigger AbstractInteraction Interaction Crossconnect EnablingBlock Join AndJoin OrJoin Split AndSplit OrSplit Block EnablingConn Enable Disable Increment InteractionRel InteractionElement BlockInterface Entry Exit DataTypeScheme AbstractDataType BuiltinDataType DataType DataTypeRel GeneralizationRel AggregationRel CompositionRel DataArg DataAttribute DataOperation ItemScheme Item BusinessProcessScheme BusinessProces BusinessEvent BusinessEvent
BusinessProces TriggeringRelation TriggeringRelation ApplicationDataScheme ApplicationDataObject ApplicationDataObject SpecializationRelation AggregationRelation CompositionRelation BusinessInformationScheme BusinessObject
AVAILABLE FROM BIZZDESIGNER PROFESSIONAL-EDITION

UMLNamespace UMLGeneralizableElement UMLPackage * -
126
BiZZdesign B.V.
UMLClassifier UMLClass UMLClassScheme UMLDomainRel UMLAssociation UMLClassRel UMLGeneralizationRel UMLAggregationRel UMLCompositionRel UMLAssociationRel UMLImplementationRel UMLPackageRel * UMLDependencyRel * UMLFeature UMLStructuralFeature UMLAttribute UMLOperation
*
ApplicationDataObject ApplicationDataScheme SpecializationRelation AggregationRelation CompositionRelation AssociationRelation RealizationRelation -
: Available with the add-on Extensive UML Class diagram
Relation types
BiZZdesigner
ActorItemRel BehaviourItemRel AccessRelation AccessRelation
Architect
Assigned profile values

Architect objects are created if specific profile values have been assigned,as described in the table below. BiZZdesigner
Profiel Behaviour ac (actors) ro (roles) bf (business functions) fu (functions) org (organisation departments) pb_sys (systems) ProfielTask rs (system) sm (system) Profiel Role reptor (reports to) reqfnc (required functions) Profiel Function reptof (reports to) frls (possible roles) finorgs (belongs to organisation departments) Profiel Person
Architect
AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation AssignmentRelation
Architect
BiZZdesign B.V.
127
Pfnc (functon) Pinorg (belongs to) Prls (possible roles)
AssignmentRelation AssignmentRelation AssignmentRelation
128
BiZZdesign B.V.
Index
A
actor collapse 45 align 24 analysis 53 Anonymous 81 Architect helpdesk 6 start with parameters 12 assignment of actors 23 Auto layout 21 autosave 15 time interval 50 access rights 83 Connection 76 copy 19, 21 create multiple 18, 21 Create multiple Match names with existing objects 19 cross references 42 Cross relations table Landscape colours 43 Cross relations table labels 43 Cross relations table Show why in cells 43 cut 19, 21
D
default settings 47 Dependencies 28 diagram 13 navigate 23 rename 17 reporting See report scroll 23 difference view 56 documentation adding fields 36, 119 find and replace 35 font size 50 font style 50 hyperlinks 35 order 101 order of fields 49 window 14, 35 documentation profile always assigned to 120 dragging 24
B
back-up 15 basic profile 111 behaviour diagram 13 BiZZdesigner model dragging 51 profiles 51 BiZZdesignervmodel open 50 block resize 25 breaking points 26
C
cascading style sheet See html Check-in 63, 66 Check-out 63, 66 semantic objects 66 view objects 66 Collaboration view 70 collapse 45 and editing 45 and print 46 and viewfilters 46 undo 46 colour 22 colour view 55 objects 55 colourview objects 50 component
E
element remove 22 examples 7 expand 45 undo 46
F
find and replace
Architect
BiZZdesign B.V.
129
in documentation 35 folder in model 18 Formatting labels 25
G
Generate view 31 Get revision 70 grid 21 Groups 21
register 10 link table 44 links 44 Locking 62 Lockingtypes 63 Logging 50
M
menu 13 model folder 18 print 105 model browser 13, 17 cut and paste 19 in html report See html settings Modelpart x Role 82 moving with arrow-keys 24
H
help function 14 html 86, 90 html settings 90 cascading style sheet 90 change background color of images 91 documentation tabs 91 index 91 model browser 91 profile summary 92 scale images 91 start diagram 93 hyperlink to bookmarks 37 within document 37 Hyperlink 36
N
name 21 navigate 23 with collapsed objects 45
O
object collapse 45 drawing 20 input 20 Object status 64 open model 15 order report 101
I
icons 7 images change background color in html report See html settings scale in html report See html settings index 91 in html report 104 where used 92 installation 7, 8 intranet report See report intranet report 86 Inverse composition 31
P
paste 19, 21 personal location 88 positioning labels 25 Possible relations 29 Preferred relation 27 print 15, 105 model 105 order 106 page setup 106 printing tables 40 process collapse 22 profile 23, 38 assign or remove recursively 38 basic profile 23 define your own 39 hidden 110 mpd-file 107, 116 mps-file 107, 114, 116
L
label positioning 25 Label 69 label view 53 language 8 licence reference code 10 licence key obtaining 9
130
BiZZdesign B.V.
remove missing 38 report See report select 110 translations 114 use your own 38 properties 22 property inherited 111 readonly 111 referred 111 standard value 111 property table 40 load 41 save 41
R
Rapporteren team 102 references 44 correcting 44 Relations 27 remove diagram 18 report automatic update 101, 104 contents 97 diagram 98 documentation 97 feedback option 35 files 101 frame layout 103 help 90 html browsing options 103 html format 86, 90, 103 html menu 104 index 104 language settings 89 legend 90 links 101 location 97 model 86 on intranet 103 order 101 per element 99 per profile 99 profiles 98 refresh 94 rtf format 87, 95, 101 sending 101, 104 start page 90 tables 100 template settings 87 updating table of contents 101 where used 92 reporting tables 40 repository access 82 ACE 82 CRUD-rights 82 Repository 73 administrator 80
admins 80 close 79 open 73 Repository-expert 74 Repositorybrowser 78 copy modelreference 79 move 79 new folder 78 new model 78 open shared model 78 remove 79 revisions 79 save existing model 79 table of contents 78 Repositoryserver 73 resize block 25 Revisies 67, 69 Roles and rights 73, 82 rtf 87 rtf settings 95 header and footer 95 page setup 96 word 95 compatible 95
S
save model 15, 62 scaling 25 scoll 23 search 48 select similar objects 24 settings 49 language 8 shadow 50 Shared model 61 changing 62 close 62 file 61 input and output 62 locking See Locking recent models 62 repository 61 save 63 workspace See Workspace similar objects 24 sorting tables 40 standard working directory 15 Studio settings 49 Synchronize 68 Synchronize status 68
T
tabels 40 table selecting 40 sorting 40 table input 40
Architect
BiZZdesign B.V.
131
Table of contents 78 tables copying 40 cross table 100 custom tables 100 printing 40 report See report reporting 40 Team bar 66, 69 Team properties 65 Team settings 71 Team-support 61 report 102 template application 88 personal 88 workgroup 88 text editor 23 tool manual pdf 14 tooltip view 54 Total view 32 translation table 43 trial licence 9 types domain-independent 125, 127 domain-specific 125, 127 relation 126, 129
V
view 53 colour See colour view difference view 56 disable 53 drawing 20 label See label view legend 53 refresh 53 show contents 22, 45 tooltip view 54 View bar 24 1-1 24 Full screen 24 helicoptor selector 24 Scale to fit 24 view browser 18 View definitions 19
W
Where used 28 word 95 in rtf report See rtf settings workgroup location 88 working directory 15, 50 Workspace 62
U
Undo check-out 68 Unused objects 28 Update status 68 URL See hyperlink
X
XML 15
132
BiZZdesign B.V.

Manual Architect

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual Architect

Încărcat de

Drepturi de autor:

Formate disponibile

Tool Manual Architect

Architect BiZZdesign B.V. February 2006

Tool Manual Architect

Tool Manual Architect

Tool Manual Architect

Tool Manual Architect

Tool Manual Architect

5.10 5.11 5.12

Collaboration view Team settings Profiles

7. Reporting and printing

Tool Manual Architect

114 114 115 115

Appendix B Documentation fields

Appendix C Object types and relation types

Appendix D Interface BiZZdesigner - Architect

Tool Manual Architect

1. About this manual

1.1 Symbols and Styles

Tool Manual Architect

1.2 Remarks, questions and bugs

Tool Manual Architect

Tool Manual Architect

2.3 Licence keys

Tool Manual Architect

Licence keys and Reference codes

Tool Manual Architect

Obtain a licence key

Tool Manual Architect

2.4 Architect editions

Tool Manual Architect

-team -oledbrepository -alladdons -noaddons

Tool Manual Architect

3.1 The Start

Tool Manual Architect

Tool Manual Architect

3.2 Input and Output

Architect saves a model in the so-called XML-format with extension .xma.

A saved file can be re-opened later on in Architect through the menu

Tool Manual Architect

Tool Manual Architect

3.3 The model browser and the view browser

Tool Manual Architect

Create multiple elements

Tool Manual Architect

Tool Manual Architect

3.4 Drawing and adding objects

Tool Manual Architect

Create multiple elements

The general view bar contains the interactor for a group:

Tool Manual Architect

Tool Manual Architect

Tool Manual Architect

Tool Manual Architect

Handle Claim Damage Occured Register Accept Valuate Pay

Text with relations

Tool Manual Architect

3.5 Drawing relations

Tool Manual Architect

Labels and icons on relations

Relations via cross relation tables

Tool Manual Architect

Tool Manual Architect

Tool Manual Architect