Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.
login Register forgot password or username?
Search:         

Welcome to 3SL Reference Section

Modelling

Modelling provides graphical techniques to represent the complexity of systems, ideally in separate domains for implementation independent analysis and implementation dependent design. You can use either or both of these domains. In each domain, you would 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 FFBD 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 FFBD, and then consider the data exchanges and functions required for each component task. These enabling functions and data can be shown as FFBD or IDEF0 or DFD diagrams. Each use shown in a FFBD 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 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 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 FFBDs. 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 FFBD 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 FFBD 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 an 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 FFBDs, 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 allows you to 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.

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 FFBD). 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. Tools should 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 your tool'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 a single tool 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 like the models to the risk register held in the single tool database, the hazard and issues lists, and to the Cost Breakdown Structure (CBS) and Work Breakdown Structure (WBS).