Cradle Modules – DASH

Cradle DASH Module

The Cradle DASH module provides the means to define Key Performance Indicators (KPIs) . It also provides the means to define their presentation as dashboards in web UIs, non-web UIs and reports.

Every project uses a process to create, review and publish its objectives, operational concept, sets of requirements, architecture and design models, and other systems engineering data. These processes will include:

  • Management reporting
  • Quality checks
  • Routine audits

of the volume of work completed, and the completeness and quality of this work.

Key Performance Indicators (KPIs)

KPIs are measures of the maturity of the information managed in the process, and therefore of the process itself.

Cradle supports KPIs as a convenient means to provide an overview of the status of an entire project, or any phase.

Any number of KPIs can be defined. Each KPI is a calculation based on one or more elements of one or more metrics:

  • Product
  • Sum
  • Difference
  • Deduction
  • Proportion
  • Percentage

combined to produce a single numerical value. The component values are derived from user-defined queries, that are searches of database items, or searches of the links between these items, or both. The component metrics can:

  • Count the values or calculate the total, mean, average, range or variance of the values from the items found by the queries
  • Use values held in attributes or the results from user-defined calculation attributes
  • These calculation attributes can use other attributes of the same item (this includes other calculations) and also attributes from linked items, such as calculating the total cost from the individual costs of a parent and its children.

Any number of colour-coded range bands can be defined for each KPI so that its value can be shown in a block with an appropriate background colour.

Using colours for the KPIs allows the overall project status to be seen at a glance. Typically, anything shown in green is good, anything shown in red will need urgent attention, and anything yellow needs to be monitored carefully. It is easy to apply such traffic light conventions in a KPI’s colour bands.

Dashboard in WorkBench
Dashboard in WorkBench

Dashboards

A collection of KPIs is held in a dashboard. Any number of dashboards can be defined, either personal to you, shared with other members of your team, or shared with everyone in the project, or available to all projects.

Each dashboard presents its KPIs as a column with the KPI shown either as a name and colour-coded number:

Dashboard in table view
Dashboard in table view

or as a dial:

Dashboard in dial view
Dashboard in dial view

The size and display styles of the dials can be controlled for each KPI.

The dashboard can be published as a report, either as a table or as a set of dials. As for all reports, output can be to a file, a printer or the UI. Such dashboard reports are fully supported in web UIs, and non-web UIs.

Dashboard Output
Dashboard output to a report

The value shown in each KPI is a link. Selecting this value will display the list of items that have been used to create the KPI’s value.

Dashboards are shown in a separate sidebar in both web UIs and non-web UIs. One dashboard can be set as the default and can be shown automatically when the UI starts.

Dashboard showing dashboard sidebar
Dashboard showing dashboard sidebar

Custom web UIs could be created to show a collection of dashboards, for example to provide a simple overview of the project and more detailed analyses of the status of each work area.

Dashboards can be published to RTF, HTML and CSV files.

Feature Summary

Feature Summary - DASH
Feature Summary – DASH

Please contact 3SL for further information about adding a Cradle DASH licence to your existing system.

Cradle Modules – MET

Cradle MET Module

The Cradle MET module provides the means to define metrics on the:

  • Needs
  • Requirements
  • User stories
  • Features
  • Models
  • Tests

It also defines metrics on all other systems engineering data in your project. Metrics are ran to monitor your progress.

Metric example
Metric example

Each project uses a process to create, review and publish its: objectives, operational concept, sets of requirements, architecture and design models, and other systems engineering data. These processes include management reporting, quality checks and routine audits of the volume of work that has been completed, and the completeness and quality of this work.

Metrics are a means to measure characteristics of your project data by collecting information about the materials created at each stage in the process. For agile projects, these characteristics will be analysed at the start and end of each iteration or sprint, and in phase based processes, the analyses are likely to be weekly or monthly as part of normal project management activities.

Metrics are user-defined sets of calculations that can be run from the user-defined phase hierarchy and start pages, from the metrics tool’s own UI, as a report, or from a command-line utility.

You can collect metrics on any of your project data. This includes requirements, use cases, functions, architecture components, models, interfaces, issues, risks, features, test specifications, test results, verifications and any other information generated by the systems engineering process.

Metric Elements

Each metric contains any number of elements, each of which is the combination of a query that finds the information in the database to be analysed, and an analysis to be performed on this set of items found by the query.

Metric Details dialog
Metric Details dialog

Each metric element can use a simple query, or a complex query that nests one query inside another. The items found by the query can be counted, or the metric can perform a coverage analysis of the values of all of their category codes, or it can perform a calculation on the values of one or more attributes, including those attributes that are the results of other user-defined calculations. The results of these operations can be grouped in up to two levels based on the values of other attributes. You can also calculate weighted totals and means of a set of values. This can be used to calculate compliance of responses to a RTF or ITT. Basic calculations can be performed which are based on the results of other metric elements.

Pivot Tables

Metrics can also include pivot tables, which are a special tabular display using two of the items’ attributes’ values as rows and columns where the cells show the number of items from those found by the query that have each pair of values for these attributes.

If a pivot table is shown in the UI, the cells in the pivot table become links. Selecting a link displays the items that have that pair of attribute values. Thus, users can decompose the totals shown in the pivot table’s cells into lists of items with corresponding attribute values.

Running Metrics

The results of running a metric can be shown in Cradle web UIs and in the WorkBench UI. They can also be generated to RTF, HTML and CSV files and loaded directly into a variety of tools including web browsers, Word and Excel.

Metric Output
Metric displayed in WorkBench

Access to the metrics facility can be controlled, to ensure reliable metrics are produced only in project-approve contents.

This mechanism allows projects to monitor:

  • The completeness of sets of needs or requirements
  • The completeness of their cross reference linkage
  • The volume of data generated by specific project groups.

Metrics can be generated from any project baseline(s), allowing cumulative statistics to be created as the project develops. You can view the database as it was at the time of any historic baseline, and generate metrics from that baseline.

Metrics can be referenced from within KPIs in dashboards using the Cradle DASH module.

Feature Summary

Feature Summary - MET
Feature Summary – MET

Please contact 3SL for further information about adding a Cradle MET licence to your existing system.

Using PDUIDs

This is the third in a short series of posts that explain Project Database Unique IDs (PDUIDs). This post explains how PDUIDs can be used in Cradle. The next and final post in the series will explain how PDUIDs can be controlled when information is moved between databases.

Opening Items

You can open an item by simply specifying its PDUID. You do not need to specify the type of the item using the Item Type Chooser dialogs in the WorkBench and web UIs. For items in models, you do not need to choose the correct domain and then locate the model inside that domain.

You simply specify the PDUID:

3SL Cradle PDUID Open Item by PDUID
Open Item by PDUID

The latest instance of the item will be opened.

Queries

You can find items based on their PDUIDs, or components of the PDUIDs, in addition to any other criteria that you may have set inside the query. Select the PUIDs tab in the Query Details dialog:

3SL Cradle PDUIDs in Queries
PDUIDs in Queries

The selection of items by PDUID will return all instances that you can access RO or RW.

Specific PID

If you choose Specific PID then you can enter a PID and an optional UID range. If you only enter a PID, then the query will return all items whose PDUIDs contain that PID. This could be useful if you have been importing data from other databases and so the items in your database have PDUIDs with different PIDs.

For example, if you have separate databases that have different PIDs for:

  • Different missions in a programme, or
  • Different vessels in a class of vessels

and you have combined the data from several of these databases into one database, then this option will allow you to find only the items with a single PID, such as for a single mission or for a single vessel. You can optionally filter the items further by specifying a UID range. You can omit the leading zeroes from the UIDs.

Specific PUID

If you choose Specific PUID then you can enter a PUID (the PID and UID) and the query will return all instances of the item with that specific PUID that you can access RO or RW and subject to the other constraints in the query (such as returning only the latest instance that you may have specified in the ID tab).

PUID From

If you choose PUID from then you can enter a PUID (the PID and UID) and the query will return all instances of all items whose PUIDs are greater than the value you specified which will be the combination of:

  • All items with the same PID and whose UIDs are greater than your specified value
  • All items with PIDs greater than your specified value and any UID

that you can access RO or RW and subject to the other constraints in the query (such as returning only the latest instance that you may have set in the ID tab).

Referencing Data in Other Items

Items in a Cradle database can hold their information in any number of frames. Each frame is of a user-defined frame type that defines the characteristics of the frame. The data in frames of a frame type is normally stored in the Cradle database, but this can be controlled by the storage mechanism of the frame’s frame type:

In PDB:The frame’s data is stored in the Cradle database
As File:The frame’s data is stored in an external file whose pathname, size, last access and modified times are stored in the Cradle database
By Command:The frame’s data is held in an external environment under an identity, the database stores this identity, and uses Get and Set commands in the frame type to move the data between the environment (specified by the $IDENTITY Command Directive) and a temporary file (specified by the $PATH Command Directive) where it can be operated on. For example:

Get: {unix cp}{win copy} “$PATH” “$IDENTITY”
Set: {unix cp}{win copy} “$IDENTITY” “$PATH”

This example exports the frame’s contents and sends to the application supplied in the frame type’s View or Edit command and saves the contents from the application back into the frame.

As Reference:The frame’s data is stored at a location outside Cradle and the frame stores this external location (such as a pathname or a URL). The data’s location is given to the frame type’s View command, which does not wait for this processing to complete – unlike in the other storage mechanisms.
Referenced File From Item:The frame’s data is held in a frame of a different item. The frame stores the PDUID of the other item whose data is being referenced (latest instance), and the name of the frame in this other item that contains the data. When the frame is accessed via a View command, Cradle opens the other item using its PDUID and copies the data from the referenced frame into a temporary file. This mechanism allows data in one item to reference data in another item, sharing the data between them.

Cradle URLs

Cradle URLs are URLs that can start a Cradle WorkBench client and either open an item or run a query. The action specified in a Cradle URL is executed by the c_url utility shipped in the Cradle clients. It can be run from a command line, an application, or a web browser that has been told about Cradle URLs (an option when Cradle clients are installed).

Cradle URLs are a way for another application to interface to Cradle. The other application can store Cradle URLs as, in effect, pointers to items in the Cradle database. When the user wants to access the Cradle item, the external application can either run c_url on the specified Cradle URL, or route it through a web browser that, in turn, will launch c_url.

Cradle URI Scheme

A URI scheme defines the structure of a URL. The Cradle URI scheme is:

cradle:[username][:password][;AUTH=authentication]@project[:access][?action&params…]

3SL Cradle URI Scheme
Cradle URI Scheme

by specifying a Cradle URL with the PDUID and instance details of the item to be opened.

Creating Cradle URLs

Cradle URLs can be created from the Tools tab WorkBench UI or any web UI. Once an item is selected:

3SL Create Cradle URL
Create Cradle URL

The Cradle URL shown in the dialog can be copied and pasted:

  • Into another application to provide a link to the selected item in Cradle
  • Into the c_url utility to execute the action in the URL
  • Into a web browser that understands the Cradle scheme, when it will launch the c_url utility to perform the requested action

API

Cradle has an Application Programming Interface (API) that supports both C/C++ and VB.NET. You can create any number of applications using the API. All of these applications will connect to the CDS in the same way as any non-web-based Cradle client supplied by 3SL (such as WorkBench or Document Publisher). Each of your applications can service one or many users. You need one API/WSI connection licence for every application that you want to concurrently connect to Cradle.

The API contains many routines. Collectively these routines provide facilities to create, read, update and delete both items and the cross references between them. The main data type for items is CAPI_ITEM_T which has components for both item identities and PDUIDs. The main data type for cross references is CAPI_XREF_T which contains the details of the cross reference but not the items that it connects. This is because cross references are not retrieved by themselves, rather the API returns a list of linked items each of which is a structure containing the CAPI_ITEM_T for the linked item and the CAPI_XREF_T for the cross reference by which it is linked. As such, the “from” and “to” items for a cross reference are implicit in the data structures.

A PDUID can be used to open an existing item using CAPI_Item_Open().

WSI

Cradle has a Web Services Interface (WSI) that supports a RESTful message protocol. You can create any number of applications using the WSI. All of these applications will connect to the Cradle Web Server (CWS) in the same way as any web-based Cradle client supplied by 3SL. Each of your applications can service one or many users. You need one API/WSI connection licence for every application that you want to concurrently connect to Cradle. Each of these connections can either be session-based or it can use message-by-message connections.

The WSI contains many operations. Collectively, these operations provide facilities to create, read, update and delete both items and the cross references between items. The data sent and received in these operations is packaged in JSON. These JSON packets contain full details of items and cross references and include both item identities and PDUIDs.

The WSI predominately uses PDUIDs as a means to specify items of information, and for links between items. For example using the curl command to send a HTTP message to a Cradle WSI session whose details are in the file cookies.txt to the CWS running on port 8015 at server myserver to get the contents of a database item into a local JSON file:

curl -X GET -b cookies.txt “http://myserver:8015/rest/projects/DEMO/items/16EC668D4ADEMO010000000907?fields=all” > myItem.json

and to update the same item in Cradle with new information added into the same local JSON file:

curl -X PUT -b cookies.txt “http://myserver:8015/rest/projects/DEMO/items/16EC668D4ADEMO010000000907” -d @myItem.json

Cradle Modules – DOC

Cradle DOC Module

The Cradle DOC module generates documents by combining user-defined templates with items in the database. A document register and a correlation between documents and database items provides full traceability.

Document Generation
Cradle DOC Module

Projects use documents:

  • As sources of information (such as user requirements or regulations, codes and standards)
  • As confirmation of agreement (such as a CONOPS or RTM or SRD)
  • To define interfaces between project teams or organisations (such as a SDS or SSDS).

Often, a project’s progress can be expressed as the issue states of its key documents.

User Defined Reports

Cradle can generate user-defined reports that will satisfy all internal project needs for information, including:

  • Simple lists
  • Compliance tables
  • Change logs
  • Traceability
  • Coverage matrices

These outputs are produced from the report, view, query and matrix facilities of the Cradle-PDM module.

The Cradle Document Generation module exists to produce complete, high quality, documents directly from the database. It can publish documents that include cover pages, Table of Contents, List of Figures, sections with mixtures of hierarchical paragraphs, bullet lists, figures and tables.

Defining Documents

Any number of documents can be defined. Each starts as a Microsoft Word document that has all of the internal structure, page layouts, styles and formats required. The Document Publisher tool is used to insert tags into this template everywhere that data is to be reported from the database. Each tag defines both the information to be published, and the high-level formatting to be used for this information, for example if it is to be published as a hierarchy of sections, a bullet list, or as rows in a table. The tags can follow cross references in any manner required, so complex relationships can easily be included in the document. The tags are defined through a UI, so that complex scripts are not needed.

Arbitrarily complex tables, hierarchies of sections and subsections, embedded diagrams, paragraph and section numbering and self-referencing within the document are supported, all specified within these tags and their associated descriptions.

At runtime, the Document Publisher uses the tags to query the database for information that is to be loaded into Word and formatted according to the styles, contents lists and indexes of that Word template. Embedded binary data can be loaded into the document, including any other Word documents and other binary content, including figures, spreadsheet and drawings.

Document templates can include user-defined variables that are specified at runtime so that a single template can be used to produce many different documents.

Any number of these templates can be defined and each used to generate many documents. Each document publishing operation will report either the current work-in-progress information or the contents of project baselines created with Cradle’s built-in Configuration Management System.

Publishing Documents

Documents can be published from the Document Publisher tool’s UI, Start Page drop downs, from nodes in a user-defined phase hierarchy UI, or the command line. This allows Document Publisher to be run in batch mode, for example to publish standard project documents overnight.

When Document Publisher is used to publish a document from a template and the database, the resulting document can be marked as a formal document by specifying an issue, issue date and reference. In this case:

  • A copy of the published document is held in the database so it can be provided in the future
  • A record of the document is added into a formal document register, and
  • Cradle records which instances of database items were used to produce the document

This means that when anything changes in the database, you know which formal documents contain the items that have changed, so you know which formal documents need to be re-issued. The new version of these formal documents are also recorded in the register.

Comparison of the contents of different issues of project documentation and the items published within them, are fully supported.

Published documents can be provided to customers and suppliers. They can also be captured using the Document Loader tool, after an external group has made change. So cyclical processing of external documents is supported. When combined with the register of the issue states of project documents, this facility means that all document-orientated processes are supported. The tools therefore fully support all customer-supplier and supply chain management contexts.

Feature Summary

Feature Summary - DOC
Feature Summary – DOC

Please contact 3SL for further information about adding a Cradle DOC module to your existing system.

Cradle Modules – REQ

Cradle-REQ Module

The Cradle REQ module provides a complete requirements capture and engineering solution with built-in CM. It can manage needs, risks, products, features, tests, validations and any other data. It is easily applied to both agile and phase-based processes.

REQ Requirements Management Module
REQ Requirements Management Module

Requirements management is part of every agile and phase process. Stakeholder needs are captured, analysed and engineered. Changes are tracked in a CM system. All needs will be linked to design, build, test and acceptance information. In agile, this is in every sprint. In phase-based processes, it is less frequent. But the techniques are the same, and the same tool needs apply that only Cradle provides:

Requirement types can be defined (user, business, system, product, functional or non-functional), user stories and use cases. Link to codes, standards, regulations, knowledge or assumptions. You define other item types to be managed, such as functions, issues, tests, risks, SBS, PBS, WBS or defects. Attributes in these items are controlled, how they will be linked to each other, and their workflows.

Item Attributes

Items have user-definable attributes, each storing or linking to up to 1 TByte of data. Attribute types are user-defined, including dates, numbers, plain and rich text, single or multi-value lists, Office and other documents, and calculations.

The text in requirements, tests, verifications and other items can be quality checked against project-specific rules.

Items can be in hierarchies, groups and many:many relationships. You can create projects using a common library. Product ranges, models, variants and builds are supported. Items can be shared and reused in any of these structures.

Capturing Items

Items can be captured from external documents by Document Loader. It reproduces the document structure in a hierarchy of items. Each item is linked to its origin in the document. Figures are loaded automatically. Tables can be captured into items, images, Word objects or rich text.

Document Loader finds differences in new versions of documents. Loading the new version will update items and their links. Coverage analysis between documents and database items are provided.

Full version management of source documents is provided. Regression to previous versions is supported, with reversal of all changes.

Requirements and other items can be loaded from Word, Excel or other tools using plug-ins, data exchange or direct interfaces.

Analyses

Coverage, traceability and impact analyses are easily run, then viewed as trees, lists, tables, matrices, or in dynamic Hierarchy Diagrams with user-defined attributes. Items can be filtered, sorted, split and merged. All changes to items can be logged. Users can be alerted to changes by Cradle, email or both.

Discussions

Users collaborate by adding discussions to items and adding threads to items and adding threads of comments to these discussions.

Reviews

Once stable, items can be progressed through a series of formal reviews that log comments from all reviewers. You define the workflows. Once in a baseline, items can be subject to formal change control using change request (proposals) and change tasks (actions). You can view the database as it was in any previous baseline.

Multiple generations of requirements can be maintained and compared. Multiple sets of variants can be managed to reflect different products in a common family.

Items can be progressed within their lifecycles. The lifecycle of an item represents the series of stages that it can pass through between being created and reaching a final, rest, condition.

User-defined tree, table and matrix views can be defined from a point-and-click UI to show traceability, coverage and compliance. This includes RTMs, VCRMs and PVMs.

Linking Items

Cradle provides transitive cross referencing, in which it follows chains of multiple links between indirectly linked items, so you can see cross-lifecycle traceability in one step. For example, you can view user requirements to tests, where Cradle transparently follows intermediate links via system requirements, functions, architecture components and so on.

Requirements can be linked to test data, safety and other critical issues, risks or any project data. When used with the Cradle-SYS module, user stories and requirements can be linked to functional, behavioural, UML, analysis, architecture and design models organised into any number of model hierarchies in both analysis and design domains.

Publish Information

All information can be published in user-defined reports and formal documents.

Feature Summary

Feature Summary - REQ
Feature Summary – REQ

Please contact 3SL for further information about adding a Cradle REQ module to your existing system.

Cradle Modules – PDM

The Cradle PDM module provides the infrastructure for all other Cradle modules. Its scalability and flexibility create an industrial strength, proven, shared data environment for even the largest projects:

Cradle PDM Module
Cradle PDM Module

Databases

Cradle supports any number of databases, each with its own schema, CM system and users. Each database supports many projects. Use the Project Manager tool to organise this environment by user-defined criteria, for example as hierarchies.

Each database stores any number of items, of any number of types (requirements, risks, classes, user stories, functions) defined by a UI. Items have any number of attributes, each of a user-defined type, that manage up to 1 TByte of any type of data, held in Cradle, or referenced in external files, URLs or another tool or environment.

Calculations

User-defined calculations are supported in all parts of Cradle and can be displayed as graphs, in views and user-defined reports. User-defined rules can be applied to automatically set attribute values or perform calculations, to maintain the integrity within and between items.

Cross References

Items can be cross referenced, with optional user-defined link types and groups. Links have user-defined attributes to justify, parametrise, explain or characterise them. You control which links are used to navigate or report traceability, based on link type or group, direction and link attribute values. Links are both direct and indirect, for full lifecycle traceability, impact and coverage analyses.

Process Tailored Environment

You use start pages and a phase hierarchy to build an environment tailored to your process. End users only need to be trained in your interface, reducing training time and costs:

  • Start pages are text and graphics controls that perform your choice of operations simply and easily
  • The phase hierarchy shows the process as a hierarchy in which an agile or phase activity, task, sprint, report or document is run by a mouse click. Different parts of the phase hierarchy can be shown to each user or stakeholder group.

Traceability and coverage views are available as trees, nested and pivot tables, matrices and Hierarchy Diagrams. Unique transitive links give traceability across the full system lifecycle.

Configuration Management

Items evolve through versions that are managed in baselines and controlled by a built-in CM system, with mechanisms for review, baseline and version control, full change control, and audit trails.

Cradle can track all changes. Edits can be reversed selectively or by group. Items can be compared across edits and in baselines. Edits can raise alerts to users, and mark related items as suspect. All edits are permanently available, for change logs.

Adaptations

Cradle provides adaptations to allow variants of items. This mechanism is ideal for databases that contain a library of standard items and projects that use the library, and contribute to it.

Access Controls

Access controls apply to all items based on user roles, privileges, security clearances and skills. Users can be grouped in a hierarchy of teams, to create any access control scheme, such as for customers, subcontractors and IV&V. The creation and manipulation of links can be controlled, by item or user.

Cradle is multi-user. It locks information at item level, with automatic database commit after an edit. This maximises users’ interaction with the database and guarantees all data s up-to-date.

Alerts

Cradle’s alert mechanism sends messages by email (SMTP or IMAP), Cradle or both. Alerts can be selectively enabled and disabled. Alerts track events on items, including edit, review and formal change.

Discussions

The Cradle discussion mechanism allows even read-only users to add comments to items. Four other commenting mechanisms are provided.

Project Planning

Cradle can manage project plans and WBS. User task lists are maintained. WBS structures and progress data can be exchanged bidirectionally with external PM tools. Cradle can generate burn-down and earned-value graphs on any user-defined criterion to monitor progress.

API

Cradle is open and extensible. It provides multiple import/export formats, an API, a user-definable event-driven command interface, interfaces with other tools and bidirectional interfaces to Microsoft Office.

Query and Report Data

Cradle provides uniquely powerful data query and visualisation facilities. Each user’s environment can be tailored by defining custom queries, views, forms, navigations, matrices, reports and other facilities. All customisations have a scope, to be specific to the end user, or shared with other users of the same type (such as all customers or all managers), the user’s team, the entire project, or all projects.

Any desired compliance, coverage or traceability report can be created quickly/easily using Cradle’s queries, multi-row views/nested table view, and saved for later use.

Licensing

Cradle has floating, dynamic licensing and low cost read-only users. Open and named user licences are available. Everything described here is free of charge.

Licences, databases and schemas are interchangeable across Linux and Windows 8.1, 10, 11, Server 2012 R2, 2016 and 2019.

Optional support for Oracle and MySQL.

Feature Summary

Feature Summary - PDM
Feature Summary – PDM

Please contact 3SL for further information about Cradle PDM licences.

August Newsletter 2023

Welcome to the August 2023 newsletter from 3SL!

This newsletter contains a mixture of news and technical information about us, and our requirements management and systems engineering tool “Cradle”. We would especially like to welcome everyone who has purchased Cradle in the past month and those who are currently evaluating Cradle for their projects and processes.

We hope that 3SL and Cradle can deliver real and measurable benefits that help you to improve the information flow within, the quality and timeliness of, and the traceability, compliance and governance for, all of your current and future projects.

If you have any questions about your use of Cradle, please do not hesitate to contact 3SL Support.

Latest Updates

The latest technical and related topics in our blog are:

Follow these links to see the latest blog updates and then use the blog’s search to find other topics of interest! With over 500 posts in the blog, we are sure that you will find lots to interest you in the details of Cradle and 3SL!

We would also like to thank all attendees on both our Project Administration course and Cradle Introduction course which we provided in July.

Displaying PDUIDs and their Components

Here we explain how to view PDUIDs and their components.

Viewing PDUIDs

You can show PDUIDs and their parts anywhere that you can show any other item attributes, especially in views and forms. Use views to control how the results of queries will be shown. You use forms to show single items. In both cases, you decide which of the items’ attributes to show. You can show either PDUIDs or any of their parts. All of these values will be displayed read-only.

Views

A view specifies which of an item’s attributes will be shown, and the order and position of the values of these attributes.

Display Styles

You can display a view in one of four display styles:

List:Lists show each item in a row of read-only text. Lists cannot contain colour, images or linked items. You use a list to show the maximum number of items on screen at the same time.
Table:Each item is shown in one or more rows, each of one or more columns, which creates a grid of display cells. Each of these cells can contain text or graphics. You can specify colour and text styles for the cells. The cells also allow linked items to be shown. Some cells are editable. You can also create display menus of user-defined commands. Table style is the most common display style.
Document:This is the same as Table style except that row and column borders are not shown and different font sizes are used to display the first row of each item. The size of the text is based on the identity or other alphanumeric attribute, so that the effect is similar to the headings and subheadings of text in a document.
Tree:Each item is displayed as a node in a tree and a single row of values similar to List style. You can control the format of the tree nodes by a separate view. These tree nodes can be expanded and collapsed to show or hide sets of linked items.

Views are Tables

Most views have one row of cells, each containing one of the item’s attributes. So if a query returns 200 items, then the view will contain 200 rows, one per item. Items can be shown over more than one row. For example, if the same query is displayed with a view that uses 3 rows to show each item, then the result will be a table with 600 rows of the form:

3SL Cradle, items as rows in a table in a view
Items as Table Rows in a View

View Cells

Each cell in a view can contain fixed text, an attribute, linked items, or several attributes combined into a single value with some optional separating characters.

PDUIDs in Views

All of the components of PDUIDs are available to be shown in cells in a view.

Further Details

To continue reading, please see the full blog entry here.

Joscar

We are pleased to announce that following the submission of our renewal, our compliance information has now been published for buying organisations using JOSCAR (the Joint Supply Chain Accreditation Register).

JOSCAR registered logo
JOSCAR

Social Media

Still to Come this Month

This course is a 2 day course split over 4 half days. It provides the following modules:

  1. Introduction to Cradle
  2. Cradle Training Environment
  3. Document Loader Introduction
  4. Office Tools Introduction
  5. Engineering Data
  6. Hierarchies in Cradle
  7. Traceability
  8. Customising WorkBench
  9. Configuration Management
  10. WorkBench Output
  11. Document Publisher Output
  12. Customising your Environment
  13. Tool Support

Your Highlights

If you have any company news or achievements that you would like 3SL to share in any of our newsletters then please let us know.

Displaying PDUIDs and their Components

This is the second in a short series of posts that explain Project Database Unique IDs (PDUIDs). This post explains how to view PDUIDs and their components. Later posts will explain:

  • How they can be used in operations in Cradle tools, API and WSI
  • How PDUIDs can be changed or preserved when information is moved between databases

Viewing PDUIDs

You can show PDUIDs and their parts anywhere that you can show any other item attributes, especially in views and forms. Use views to control how the results of queries will be shown. You use forms to show single items. In both cases, you decide which of the items’ attributes to show. You can show either PDUIDs or any of their parts. All of these values will be displayed read-only.

Views

A view specifies which of an item’s attributes will be shown, and the order and position of the values of these attributes.

Display Styles

You can display a view in one of four display styles:

List:Lists show each item in a row of read-only text. Lists cannot contain colour, images or linked items. You use a list to show the maximum number of items on screen at the same time.
Table:Each item is shown in one or more rows, each of one or more columns, which creates a grid of display cells. Each of these cells can contain text or graphics. You can specify colour and text styles for the cells. The cells also allow linked items to be shown. Some cells are editable. You can also create display menus of user-defined commands. Table style is the most common display style.
Document:This is the same as Table style except that row and column borders are not shown and different font sizes are used to display the first row of each item. The size of the text is based on the identity or other alphanumeric attribute, so that the effect is similar to the headings and subheadings of text in a document.
Tree:Each item is displayed as a node in a tree and a single row of values similar to List style. You can control the format of the tree nodes by a separate view. These tree nodes can be expanded and collapsed to show or hide sets of linked items.

Views are Tables

Most views have one row of cells, each containing one of the item’s attributes. So if a query returns 200 items, then the view will contain 200 rows, one per item. Items can be shown over more than one row. For example, if the same query is displayed with a view that uses 3 rows to show each item, then the result will be a table with 600 rows of the form:

3SL Cradle, items as rows in a table in a view
Items as Table Rows in a View

View Cells

Each cell in a view can contain fixed text, an attribute, linked items, or several attributes combined into a single value with some optional separating characters.

PDUIDs in Views

All of the components of PDUIDs are available to be shown in cells in a view. For example:

3SL Cradle DID PID UID and PDUID in View in Table Style
DID PID UID and PDUID in View in Table Style

The DID column contains the Database ID component from the items’ PDUIDs:

3SL Cradle View PDUIDs DID in a View
DID in a View

The PID column contains the Project ID component from the items’ PDUIDs:

3SL Cradle View PDUIDs PID in a View
PID in a View

The UID column contains the Unique ID component from the items’ PDUIDs:

3SL Cradle View PDUIDs UID in a View
UID in a View

The PDUID column contains the items’ entire PDUIDs:

3SL Cradle view PDUIDs PDUID in a View
PDUID in a View

There is no component to show the items’ Project Unique IDs (PUIDs). The PUID is the combination of the PID and UID, so we can easily output this in a view cell using the data type Multiple and concatenating these attributes with no separators:

3SL Cradle View PDUIDs PUID in a View
PUID in a View
3SL Cradle View PDUIDs PUID Component Attributes
PUID Component Attributes

All of these cells will be read-only in all display styles since PDUIDs are not user-modifiable attributes.

Forms

A form is a collection of fields, grouped into rows and columns, that display information for a single item. You can arrange the fields in a form in any way that you wish, to create any layout of information that you wish. Regions of forms can be made collapsible inside panels. Each field in a form can contain fixed text, an attribute or a collection of linked items. If an attribute is editable, then the form will allow it to be edited, subject to the user’s access rights to the item and that specific attribute. In addition, a field can be set to prevent editing of an attribute that would otherwise be editable.

All of the components of PDUIDs are available to be shown in fields in a form. For example:

3SL Cradle View PDUIDs and Components in a Form
PDUID and Components in a Form

The DID field contains the Database ID component from the item’s PDUID:

3SL Cradle View PDUIDs DID in a Form
DID in a Form

The PID field contains the Project ID component from the item’s PDUID:

3SL Cradle View PDUIDs PID in a Form
PID in a Form

The UID field contains the Unique ID component from the item’s PDUID:

3SL Cradle View PDUIDs UID in a Form
UID in a Form

The PDUID field contains the item’s entire PDUID:

3SL Cradle PDUID in a Form
PDUID in a Form