Cradle SYS

Modelling complements requirements management by extending the definition of functional, behavioural, architectural and process requirements in a three dimensional graphical structure.

Using interlocking diagram styles conveys information more easily than linear sets of requirements. Clearly defined semantics and syntax allows automated checking, to ensure consistency and completeness.

Cradle has analysis and design domains, with multiple models in each. The domains are cross referenced.

Cradle has a range of notations and allows them to be combined in project specific model topologies.

Users can start with eFFBDs for mission scenarios and continue with eFFBDs, DFDs or IDEF0 for functional analysis. A set of distinct UML models can be developed in the same framework. Such models can be allocated into an architecture defining the system configuration and interfaces, that can be allocated into physical casings, cabinets, airframes, ship hulls, or buildings, that house the system for zonal analysis and product breakdown structures.

State-of-the-art consistency, comparison and animation tools ensure that models are complete, consistent and rigorous. Powerful renaming, renumbering and reordering features manipulate even the largest models with ease. Automated checkers ensure that models are correct as you create them.

Models can be linked to test data, safety, risk and other critical issues or any project data. Combined with the Cradle-REQ module, they can be linked to engineered requirements and original customer needs.

All model elements are composite, containing graphics, video, figures, tables, equations, URLs and integrate with desktop tools such as Word and Excel.

SYS Applications

Cradle provides separate domains for implementation independent analysis and implementation dependent design. You can use either or both of these domains. In each domain, you can create any number of models. Each model can combine one or more notations, in a manner appropriate to your project.

The initial modelling task is often to define the system environment, to identify the boundary around the system under study. This environment can contain physical or human elements, and other systems. In such a system-of-systems context you would normally create a hierarchy of models, one for the system-of-systems, and lower-level models for each system.

Depending on the nature of the system, you can use hierarchies of UML use cases to model the classes of interactions, and the component scenarios within each. UML use case diagrams can be decomposed into UML sequence diagrams and collaboration diagrams to define the sequences, and can also be decomposed into eFFBD diagrams to depict functional sequences and parallelisms.

Alternatively, you can build an event set, where each event is an environmental stimulus, a system response, and a definition of when the event can occur. Analysis of these events produces a functional model that can be rationalised into a function hierarchy.

Alternatively, if the system is not well understood, but its intended uses are understood, then you can build usage scenarios or mission profiles that divide a given use into phases and activities, depict each as a time-sequenced eFFBD, and then consider the data exchanges and functions required for each component task. These enabling functions and data can be shown as eFFBD or IDEF0 or DFD diagrams. Each use shown in a eFFBD can be embedded within a UML use case.

Once the environment has been defined, you can define the system context and develop it using any combination of UML and non-UML (functional or behavioural) techniques. Fundamentally, the objective is to create cross references between all functional requirements and elements of one or more system models. The allocation of requirements to functions effectively asserts that the functions and classes are the solution to the requirement.

You can conduct structured analysis using Cradle’s data flow diagrams (DFDs) and state transition diagrams (STDs), and model data with Entity Relationship Diagrams (ERDs) and Data Structure Diagrams (DSDs). You can conduct purely UML analysis using Cradle’s UML use case diagrams (UCDs), UML sequence diagrams (SQDs), UML collaboration diagrams (CODs), UML class diagrams (CDs), UML package diagrams (PDs), UML activity diagrams (ACDs) and UML statecharts (SCDs). You can also undertake functional analysis using IDEF0 diagrams. You can conduct behavioural modelling using eFFBDs. All of these notations can be combined (with a couple of small restrictions). In particular, you can build a functional model using the DFD and IDEF0 and eFFBD notations (any combination) and use each function as the context for a separate UML model.

Business process modelling and process modelling in general also starts from a context, but in this case it is an organisational context that represents business goals, organisational boundaries, and information exchanges. The context for each business process can be shown in a UML use case diagram, and the current and desired operational sequences can be shown with UML sequence diagrams, activity charts and statecharts, and can also be shown with IDEF0 and eFFBD diagrams. The choice of the appropriate notation is yours, and is made on the relative significance being placed on the activities in the process, or the information manipulated by the process.

Business process modelling in particular benefits from Cradle’s ability to replace diagram symbols with pictures and images, allowing these diagrams to graphically display current and intended processes. It also benefits from the ability to group operations and functions and classes into groups, shown within coloured swimlanes on the diagrams.

Operational analysis on a functional and UML model is achieved using Process Flow Diagrams (PFDs) which, like eFFBDs, are time sequenced. These diagrams depict the operational sequence of a process. Their unique characteristic is that they point to other functions, classes etc. in the main model. Thus, a cohesive UML model, functional model, or business process model can be built that represents the entire system or business unit. The system or business unit modelled is performing many tasks concurrently. It may be that the organisation of the model is such that the components of a given task are distributed across a number of diagrams. You can build a PFD for this task, that depicts all of the operations in a single time sequence, where each operation points to the appropriate function, class or activity in the main model. If a function, class or activity appears more than once in a process flow, then your PFD will have multiple operations, each referencing the same function, class or activity in the main model.

The PFDs consequently allow you have any number of orthogonal views on the main system model. The flexibility that this provides for operational analysis, transaction analysis and business process modelling is enormous.

Modelling continues until a sufficient level of detail has been reached. If the modelling is in the analysis domain, then modelling continues until sufficient detail has been reached to allow the allocation of functions and classes to be allocated into a system architecture. Cradle-SYS provides visual feedback of where and how the model elements have been linked back to the requirements, and shows how requirements have been allocated into the model.

The mapping of requirements into the models is of crucial importance to ensuring that not only is the model complete, but also that the requirements sets are complete. By building a model, you are working in a different engineering context. In this context, you will need classes or functions or business processes to make the model cohesive and consistent. If you cannot allocate all of the resulting functions, classes and processes to the requirements, you have found missing requirements.

Use of the design domain normally begins by the construction of one or more candidate system architectures using Physical Architecture Diagrams (PADs). These diagrams depict purely physical entities, such as subsystems, equipments, components, buses, connections, sensors, vehicles, power trains, hulls or casings, building and power supplies. The diagrams are hierarchical, allowing you to decompose the architecture to whatever level is appropriate. Typically this decomposition continues to a level consistent with the COTS components being used, or the development subcontracts to be let.

If you have several candidate architectures (such as single bus and dual bus configurations), then you build multiple architecture models. Each PAD hierarchy can correspond to a PBS (Product Breakdown Structure) or a SBS (System Breakdown Structure) for that candidate architecture.

Within and between these models, there will be many instances where components are common. The PAD allows for sharing or reuse of components. You can define a standard component and use it on any number of diagrams. Each of these shared components can itself be shown in its own PAD, each of which can be referenced from wherever the shared component is used. The shared components’ PADs can be decomposed, both into lower level PADs (to show the internal structure) and into their own functional models (using the DFD and IDEF0 notations), UML model and behavioural model (using the eFFBD). Within these shared hierarchies, you can use lower-level shared components.

As a result, the architecture model can be a complex assembly of architectures and multiple levels of shared, reused, components.

These architectures are linked back to the non-functional requirements, and the system requirements in particular, such that performance, availability, environmental requirements are linked to the architecture components. Cradle will show, in reports, hierarchies, trees and visually in the diagrams, which requirements are allocated to each component, and will show which parts of each architecture are allocated to each requirement. Exception reports of unallocated requirements and components can be extracted, both graphically and as tabular reports.

The design domain is used to allocate functions, classes and processes from the analysis domain into one or more of the architectures. This allocation is normally by copy and paste from the analysis domain, a process which automatically creates the links between the two domains. If you have several architectures, then you can share the function allocations between appropriate parts of them.

If you have chosen not to use the analysis domain, then you would create the functions, classes and business process models directly in the design domain and allocate them to the architectures.

Design modelling continues to whatever level is appropriate for your project. This is either to a level where the allocation of functions, business processes and/or classes to hardware and software can occur, or to the level of a subcontract, or to the level where a system specification document (SSD) or subsystem specification document (SSDD) can be produced.

Once a hardware-software allocation has occurred, you can continue in both engineering sub-domains using Cradle’s facilities to not simply conduct the software engineering design, but also to encapsulate the hardware design by storing circuit diagrams, VHDL descriptions and so on within the Cradle database, referencing external specialist tools to operate on this data as needed.

All elements of both modelling domains can be referenced to the evolving sets of test objectives, specifications and descriptions. Similarly, you would link the models to the risk register held in Cradle, the hazard and issues lists, and to the Cost Breakdown Structure (CBS) and Work Breakdown Structure (WBS).