InterPARES 2 Project

Similar documents
SADT Structured Analysis & Design Technique

We move from a general information system to a Computer Based Information System

Requirements Engineering

System Analysis & design

CHAPTER 5 MODELING ENGINEERING SYSTEMS

Data Flow Diagrams System Analysis ( (

IDEF* - A comprehensive Modelling Methodology for the Development of Manufacturing Enterprise Systems

Database Systems: Design, Implementation, and Management Tenth Edition. Chapter 4 Entity Relationship (ER) Modeling

Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition. Chapter 7 Data Modeling with Entity Relationship Diagrams

APPENDIX M INTRODUCTION TO THE UML

Tecniche di Progettazione: Design Patterns

Unit-3 Software Design (Lecture Notes)

Cisco Accessibility Conformance Report VPAT Version 2.0

BUSINESS REQUIREMENTS SPECIFICATION (BRS) Documentation Template

1. The narratives, diagrams, charts, and other written materials that explain how a system works are collectively called

Experiment no 4 Study of Class Diagram in Rational Rose

A Conceptual Model of the UML

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

(Team Name) (Project Title) Software Design Document. Student Name (s):

AllFusion Process Modeler

Cisco Accessibility Conformance Report VPAT Version 2.1

Interaction Modelling: Use Cases

Chapter 6 Structuring System Requirements: Process Modeling 6.1

Cisco Accessibility Conformance Report VPAT Version 2.1

IDEF3 Process Modeling

Lecture 4, Task Analysis, HTA

Database Systems: Design, Implementation, and Management Tenth Edition. Chapter 4 Entity Relationship (ER) Modeling

Overview. What is system analysis and design? Tools and models Methodologies

Unit 6 - Software Design and Development LESSON 10 DESIGN TOOLS, INPUTS, OUTPUTS, STORYBOARDS

A MODULARIZED APPROACH TO THE INTEGRATED ENVIRONMENT

ISO/IEC/ IEEE

Cisco Accessibility Conformance Report VPAT Version 2.1

Lecture Notes. Structured Systems Analysis

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

A Software Safety Argument Pattern Catalogue

System Analysis and Design. Data Flow Diagram. System Analysis and Design

System Analysis and Design

TEL2813/IS2820 Security Management

Cisco Accessibility Conformance Report VPAT Version 2.1

Object-Interaction Diagrams: Sequence Diagrams UML

Challenges and Benefits of a Methodology for Scoring Web Content Accessibility Guidelines (WCAG) 2.0 Conformance

Contemporary Design. Traditional Hardware Design. Traditional Hardware Design. HDL Based Hardware Design User Inputs. Requirements.

Topics. Overview- The UML Functional Model. Structural Model. Behavioral Models. Use Case Diagram (essential and system)

Basic Structural Modeling. Copyright Joey Paquet,

User Interface Design: The WHO, the WHAT, and the HOW Revisited

FUNCTIONAL MODELLING

An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs)

CORE 8 Architecture Definition Guide CORE 8. Architecture Definition Guide

Process Modelling. Data flow Diagrams. Process Modelling Data Flow Diagrams. CSE Information Systems 1

Collaborative Refinery: A Collaborative Information Workspace for the World Wide Web

Chapter 10. Object-Oriented Analysis and Modeling Using the UML. McGraw-Hill/Irwin

Cisco Accessibility Conformance Report VPAT Version 2.0

1: Specifying Requirements with Use Case Diagrams

Non-overlappingoverlapping. Final outcome of the worked example On pages R&C pages R&C page 157 Fig 3.52

Cisco Accessibility Conformance Report VPAT Version 2.0

Software Design Document (SDD) Template (summarized from IEEE STD 1016)

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model.

Interactions A link message

Full file at

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

COSC 3351 Software Design. An Introduction to UML (I)

ISO/IEC TR TECHNICAL REPORT. Software and systems engineering Life cycle management Guidelines for process description

Unique Object Identifiers

06. Analysis Modeling

Module 5. Function-Oriented Software Design. Version 2 CSE IIT, Kharagpur

Towards Integration of Slice Networking in NFV

Lab Manual. Object Oriented Analysis And Design. TE(Computer) VI semester

Software Service Engineering

Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs)

Chapter 2 Overview of the Design Methodology

Chapter 5. Systems Analysis. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

An Intelligent System for Archiving and Retrieval of Audiovisual Material Based on the MPEG-7 Description Schemes

Stateflow Best Practices By Michael Burke

PROPOSED DOCUMENT. International Medical Device Regulators Forum

ETSI ETR 046 TECHNICAL July 1992 REPORT

Oracle. SCM Cloud Configurator Modeling Guide. Release 13 (update 17D)

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Cisco Accessibility Conformance Report VPAT Version 2.1

Chapter 2. Information System Building Blocks. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

Natural Language Requirements

Complexity. Object Orientated Analysis and Design. Benjamin Kenwright

DATA MODELS FOR SEMISTRUCTURED DATA

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.

Darshan Institute of Engineering & Technology for Diploma Studies

Architecture Definition Guide

Software Design. Software design is a blueprint or a plan for a computerbased solution for system

Organizing Spatial Data

Essentials of Database Management (Hoffer et al.) Chapter 2 Modeling Data in the Organization

Teiid Designer User Guide 7.5.0

DISTRIBUTED TRANSACTION PROCESSING STANDARDS AND THEIR APPLICATIONS

Cisco Accessibility Conformance Report VPAT Version 2.0

Cisco Accessibility Conformance Report VPAT Version 2.0

Security Management Models And Practices Feb 5, 2008

Creating Post(s) In WordPress

Unified Modeling Language - UML

3. UML Class Diagrams Page 1 of 15

Software life cycle. Purpose of an SDD

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Gane-Sarson Notation. This is Lecture d.

White Paper on RFP II: Abstract Syntax Tree Meta-Model

Transcription:

International Research on Permanent Authentic Records in Electronic Systems Integrated Definition Function Modeling (IDEFØ): A Primer InterPARES Project Coordinator 04 August 2007 1 of 13

Integrated Definition Modeling (IDEFØ) IDEFØ is a modeling technique based on combined graphics and text that are presented in an organized and systematic way to gain understanding, support analysis, provide logic for potential changes, specify requirements, or support systems level design and integration activities. Source: US Secretary of Commerce. Draft Federal Information Processing Standards Publication 183, 21 Dec 1993. 2 of 13

General Characteristics IDEFØ modeling process creates a functions model composed of a hierarchical series of diagrams that gradually display increasing levels of detail describing functions/activities and their interfaces within the context of a system. Models the decisions, actions and activities of a system or an organisation. Provides a type of "blueprint" of activities and their interfaces. Reflects how system activities interrelate and operate just as the blueprint of a product reflects how the different pieces of a product fit together. 3 of 13

IDEFØ Modeling Process Top-down, general-to specific modeling approach. The most general features come first in the hierarchy, as the whole top-level activity is decomposed into sub-activities that compose it, and those sub-activities, in turn, are further decomposed until all of the relevant detail of the model s whole viewpoint is adequately exposed or described. Representation of activities is non-temporal. 4 of 13

IDEFØ Strengths Useful for establishing the overall scope on an analysis. Provides a graphic, structured representation of the activities in a system, supplemented with textual description. Provides a comprehensive and expressive analysis to any level of detail required. Helps isolate and describe what activities are performed and what is needed to perform them. 5 of 13

IDEFØ Weaknesses IDEFØ models are often so concise that they are understandable only if the reader is a domain expert or has participated in the model development. Because of the box & arrow interface, activity sequencing can, without intent, be imbedded into the model. Tendency of IDEFØ models to be interpreted temporally as representing a sequence of activities. 6 of 13

Top-Level Context Diagram Each IDEFØ model has a top-level context diagram (A-0), on which the subject of the model is represented by a single box with its bounding arrows (i.e., inputs, controls, outputs, and mechanisms = ICOMS). The arrows on the A-0 diagram interface with activities outside the subject area to establish the model s focus. 7 of 13

Top-Level Context Diagram A-0 diagram establishes the overall context for the model's viewpoint and purpose, which in turn helps to guide and constrain the creation of the model. The viewpoint determines what can be "seen" within the model context, and from what perspective. The statement of purpose expresses the reason why the model is created and actually determines the structure of the model. 8 of 13

Key Definitions Activity: A function, process, or transformation identified by a verb or verb phrase that describes what must be accomplished. Box: A rectangle, containing a name and number; used to represent an activity. Parent diagram: A diagram that contains 3-5 parent boxes. Child diagram: A diagram with 3-5 child boxes that provide additional detail about a parent box. Every parent diagram (except A-0) is also a child diagram, since by definition each details a parent box. Hence, the primary hierarchical relationship is between a parent box and the child diagram that details it. 9 of 13

Key Definitions (cont.) Arrows: Directed lines, composed of one or more segments, that model conduits conveying data or objects from a source (no arrowhead) to a use (with arrowhead). There are 4 arrow classes: Inputs, Controls, Outputs, and Mechanisms. Inputs: Data or objects that are transformed by activities into outputs. Controls: The conditions required to produce correct outputs. Outputs: Data or objects produced by activities. Mechanisms: The means used to perform activities. 10 of 13

ICOM Arrow Positions and Roles Controls Inputs Register Received Records A2.2.3 Outputs Mechanisms 11 of 13

Decomposition Structure 12 of 13

Boundary Arrow Correspondence 13 of 13