Скачать презентацию Datum Sidnummer Författare Architecture Design Rules in Скачать презентацию Datum Sidnummer Författare Architecture Design Rules in

b1b111fef29bc2745c6fa4007748d3af.ppt

  • Количество слайдов: 14

Datum , Sidnummer, Författare Architecture Design Rules in Ledsyst. T • How it started Datum , Sidnummer, Författare Architecture Design Rules in Ledsyst. T • How it started • To be followed by a presentation of current status • Per-Georg Jönsson, Swedish Defence Materiel Administration, • Capabilities, Strategies and Future Systems • Competence area for Systems Engineering, Architecture and Configuration Management • Per-Georg. [email protected] se

2000 -2001 FMA Version 1. 0 milestone (M 3) 2002 Financed by Ledsyst. T 2000 -2001 FMA Version 1. 0 milestone (M 3) 2002 Financed by Ledsyst. T Phase 1, 1+ developing FMA version 2. 0 milestone (M 4, M 5) 2003 Working with information and presentation materia based on FMA version 2. 0 M 5, evaluate Test, adapt and implement FM A based concepts in Ledsyst. T 2004 2005 -07 established NATO-NAF-FM AR analysis FM A developing and implementation project FMV/FM FMA Datum , Sidnummer, Författare Short history (main objectives)

Datum , Sidnummer, Författare The long and winding road Architecture Program FM Ledsyst Preparations Datum , Sidnummer, Författare The long and winding road Architecture Program FM Ledsyst Preparations and research 2000 Goal: 2010 Clarification FM Ledsyst 2003 w vie Re ic 2001 2002 Further development and practical usage outside Architecture development program Other programs r sto Hi Delivery M 5 FM Ledsyst Phase 0 FM Ledsyst Phase 1 1999 Architecture Program Delivery M 3 Framework investigation The NAF v 3 era FM Ledsyst Phase 2 2004 2005 2006

424 4 main concepts 24 presentations 454 4 lots Whitepapers of reference matrl Datum 424 4 main concepts 24 presentations 454 4 lots Whitepapers of reference matrl Datum , Sidnummer, Författare Enterprise old FM A The rsion 2. 0 ecture ve Archit

 • • • System description view (system hierarchy) – What system elements are • • • System description view (system hierarchy) – What system elements are present at this system level in the internal information exchange model (IER)? Organisation description view (Actor model) – What system elements are able to act and what roles do they act upon? Business description view (Procedures) – How do actors in the system act (activities of the system) and the internal information exchange model (IER = Information Exchange Requirements) Personnel description view – Rules diagram that controls the acting within the system Information description view – Conceptual model (CM), Information model (IM), Information exchange model (IEM), Data model (DM), Data exchange model (DEM) and Storage model (SM) for each use case instance and additional models for each domain (CD = Cognitive behavioural domain, RD = Representation domain (Information domain), PD = Physical domain (technical models) Technology description view – Technical component descriptions Datum , Sidnummer, Författare Holistic Architecture Description Perspectives (models (aspects) of the architecture)

Viewpoint Knowledge base S Doctrine O Organization Role Business Capability P Process K Competence Viewpoint Knowledge base S Doctrine O Organization Role Business Capability P Process K Competence I T Spec Information Products People The material (real) world Datum , Sidnummer, Författare The Pyramid Model

 • • Service Concept Service Tiers (LOVNETP) System Concept – System as a • • Service Concept Service Tiers (LOVNETP) System Concept – System as a black box, with coupling to other systems – System as a white box containing other system (seamless break down in system of systems) – Systems of Systems Concept Network centric concept Design Rule Concept Information Concepts Modelling of systems using UML Datum , Sidnummer, Författare Ledsyst. T Most important used Concepts

Datum , Sidnummer, Författare Ex System view, White box Datum , Sidnummer, Författare Ex System view, White box

Designrules Ver 2. 0 MMI sit syst builder Time Geodata Sea Radar Torö Nynäshamn Designrules Ver 2. 0 MMI sit syst builder Time Geodata Sea Radar Torö Nynäshamn MMI presentation Und. E AA Radar Gothenburg Fusion mode Land info SLB Netcorrelation SIM Federation SIM Air FSR 890 SIM NBD SIM Air Sea Strics Datum , Sidnummer, Författare Service demonstrator 03 Autom/04 Spring

 • Based on standards • Accounts for industry best practices • Derived by • Based on standards • Accounts for industry best practices • Derived by exploiting key competencies from Boeing, Ericsson, IBM and SAAB as well as Swedish and international research bodies • Will be open/public – exception information security implementation Datum , Sidnummer, Författare Design rules

Design rule characteristics: • Packages knowledge in a reuseable form • Ensures that the Design rule characteristics: • Packages knowledge in a reuseable form • Ensures that the requested properties are achieved (flexibility, interop…) • Provides value for a re-user, i. e. by – proposing a solution to a difficult problem – improving the quality of the resulting product – proposing a way of enabling the exploration of opportunities • May solve both high and low level problems. Value to the re-user is the most importand aspect. • The key differentiator between a design rule and a requirement is that the design rules defines a solution • Can satisfy one or more requirements • Can be part of a design rule package – DRP - for a problem domain Datum , Sidnummer, Författare The characteristics give a better understandig of what a design rule is

The holy Franciscus, Il Poverollo, 1182 -1226 • “ A rule excludes permanent wiggling The holy Franciscus, Il Poverollo, 1182 -1226 • “ A rule excludes permanent wiggling between different alternatives. It makes it possible to follow a defined line. It is not the amount of details, but abeyance to a few directives that is of importance. The directives shall be so short and clear that you immediately can recall them in your memory • “The rule should be practical, addressed directly to the sense and shall be personal. Not until you thoroughly have considered the rule, elaborated it carefully, have allowed it to mature and hardened it you should train yourself in being fateful to it” Datum , Sidnummer, Författare Nothing new…Designrules 1200, The holy Franciscus

Design rules are grouped in a number of categories and levels of detail. One Design rules are grouped in a number of categories and levels of detail. One initial detailed structure is the following: NBD Rules – Method Rules – Framework Rules – Design Development Governance Verification and validation System concept Services concept System description Service description System Design Service Design Business Application Information Technical Datum , Sidnummer, Författare Design rules are organized in a hierarchic structure

 • • Good start among designers for demonstrators – System and service thinking • • Good start among designers for demonstrators – System and service thinking quickly adopted – Fairly good experience from model based approach and modeling – Very successful demonstrators Slow start among architects – Architectural work suffered from front end problems of placing contracts and starting up the organization – Windows of opportunity for controlling with architecture is at the beginning – Uneven skills for architecture and modeling at the beginning, eg few with appropriate skills in modeling – Architects without sufficient power to control the development – Required input from mission domain largely lacking – Supporting Sw AFEA project was not financed 2003 -2004 – Understanding of how to use Design Rules took time to established A lot of work was done without proper correlation and control Restart based on NAF v 2 summer 2005 – Top down approach – To late to influence the rest of the project – Still a valid experience for the future and for the creation of principles and design rules Datum , Sidnummer, Författare Architecture experiences