Roles and Responsibilities Jahangheer Shaik. Service Specification Specification requires development of three inter-related documents CIM, PIM and PSM.

Slides:



Advertisements
Similar presentations
1 Aspects of IEEE P1471 Viewpoints in Unified Modeling Language (UML) Manzur Ashraf, BRAC University Humayra Binte Ali, Dhaka University Md.Mahfuz Ashraf,
Advertisements

2/11/2014 8:44 AM The CDA Release 3 Specification Stack September 2009 HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
Copyright © 2006 Data Access Technologies, Inc. Open Source eGovernment Reference Architecture Approach to Semantic Interoperability Cory Casanave, President.
Ch 3 System Development Environment
Analysis Modeling.
Modeling with the ECCF SS ● UML Profile for ECCF ● UML Redefinition Semantics ● Compliance ● Consistency ● Conformance ● Validation ● Transformation ●
Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße 14, Augsburg Tel.: (+49) 821/ , Fax:
Knowledge, Skills, and Abilities Working Group Hua Min Jahangheer Shaik Natasha Sefcovic Kahn Aleksey.
1 SWE Introduction to Software Engineering Lecture 15 – System Modeling Using UML.
Using Architecture Frameworks
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Web Service Architecture Part I- Overview and Models (based on W3C Working Group Note Frank.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
David Harrison Senior Consultant, Popkin Software 22 April 2004
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
One-release-per-year One-approval-per-year One-standard-per-year Leveraging rigorous process to accelerate standard development and approval through predictable.
Object Oriented Analysis and Design Using the UML
Object-Oriented Analysis and Design
ARCH-6: UML Modeling with Enterprise Architect Phillip Magnay Technical Architect.
International Telecommunication Union ITU-T Study Group 17, Moscow, 30 March – 8 April 2005 New Recommendations on ODP Arve Meisingset Rapporteur Q15.
Initial slides for Layered Service Architecture
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
1 ECCF Training 2.0 Platform Specific Model (PSM) ECCF Training Working Group January 2011.
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Systems.
Chapter 8 Architecture Analysis. 8 – Architecture Analysis 8.1 Analysis Techniques 8.2 Quantitative Analysis  Performance Views  Performance.
Rational Unified Process Fundamentals Module 4: Disciplines II.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
 Explain the role of a system analyst.  Identify the important parts of SRS document.  Identify the important problems that an organization would face.
Introduction to MDA (Model Driven Architecture) CYT.
1 MFI-5: Metamodel for Process models registration HE Keqing, WANG Chong State Key Lab. Of Software Engineering, Wuhan University
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
INTRODUCTION to SAIF and Sound: Fast Track to Standard Development Leveraging rigorous process to accelerate standard development and approval through.
1 Introduction to Software Engineering Lecture 1.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group March 2011.
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Class Diagrams.
1 SAIF-Effects on Data Service Specifications Baris Suzek Georgetown University Architecture/VCDE Joint Face-to-Face June,3, 2010 St. Louis, Missouri.
1 ECCF Training 2.0 Implemental Perspective (IP) ECCF Training Working Group January 2011.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
© 2005 Prentice Hall1-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Kemal Baykal Rasim Ismayilov
1 ECCF Training 2.0 Guidance for the Platform Independent Model (PIM) ECCF Training Working Group January 2011.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
EbXML Business Process Dept of Computer Engineering Khon Kaen University.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Behavioral Framework Background & Terminology. Behavioral Framework: Introduction  Background..  What was the goal..
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group January 2011.
March 24, 2007 SOA CoP Demo Model Driven Enterprise SOA GSA Financial Management Enterprise Architecture Cory Casanave cory-c (at) modeldriven.com Oct.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group March 2011.
Model Driven Architecture MDA SE-548 Lale Doğan
Chapter 5 – System Modeling Lecture 1 1Chapter 5 System modeling.
CHESS Methodology and Tool Federico Ciccozzi MBEES Meeting Sälen, January 2011 January 2011.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms.
Enterprise Data Model Enterprise Architecture approach Insights on application for through-life collaboration 2018 – E. Jesson.
Unified Modeling Language
Goal Platform Independent Specific Topic Specification
UML profiles.
Constructing MDA-based Application Using Rational XDE for .NET
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Software Development Process Using UML Recap
Presentation transcript:

Roles and Responsibilities Jahangheer Shaik

Service Specification Specification requires development of three inter-related documents CIM, PIM and PSM These three documents are generated in an iterative process Project architect is responsible for authoring specifications Business analysts contribute more to the CIM and software engineers to the PSM

ECCF Specification stack

CIM- Computation Independent model CIM captures the service capabilities, traceability to requirements, the service behavioral semantics, and the service information model It is developed primarily by the project architects, with extensive contributions from the business analysts

CIM- Enterprise viewpoint Enterprise Viewpoint captures the business objectives, the core functional and nonfunctional requirements, and the analysis models that relate the service capabilities to the business requirements The project architect is responsible for the CIM Enterprise Viewpoint and should work collaboratively with the individuals in the information architect and business analyst roles

CIM-Information view point CIM Information Viewpoint is concerned with all the entities used by the service, and captures and expresses the entities in an information model The project architect is responsible for the CIM Information Viewpoint and should work collaboratively with the individuals in the information architect and business analyst roles

CIM-Computational or Behavioral Viewpoint Computational or Behavioral Viewpoint captures the behavioral semantics of the service. Behavioral semantics refer to the service capabilities and constraints, but especially to interactions and dependencies of this service with other services The project architect is responsible for the CIM Computational Viewpoint and should work collaboratively with the individuals in the project software developer role

CIM- Engineering or Information viewpoint Engineering Viewpoint describes the mechanisms and functions required to support the interactions of the computational components The project architect is responsible for the Computation-independent Model (CIM) Engineering Viewpoint and should work collaboratively with the individual(s) in the project software engineering role

PIM- Platform independent model specification The Platform-independent Model (PIM) specification addresses the business functionality and behavior of a service, independent of the technology that implements it Its purpose is to transform the CIM analysis model into a logical model without binding to a technology stack

PIM- Enterprise viewpoint Enterprise Viewpoint (EVP) at the PIM level is optional, and in most cases, this cell just provides traceability to the Computation- independent Model (CIM)-level artifacts The project architect is responsible for the PIM Enterprise Viewpoint and informs the business analyst of any changes required in the CIM-level artifacts

PIM- Information viewpoint Refines information viewpoint of CIM model by – Remove any unnecessary attributes and classes – Add new attributes – Add Additional classes – Change class type to subclass of a main class – Change cardinality of association The project architect is responsible for the PIM Information Viewpoint artifacts

PIM- Computational or behavioral viewpoint It is concerned with further details of system descriptions to provide a sufficient level of detail to support computable working interoperability The technical architect is responsible for the PIM Computational Viewpoint artifacts

PIM- Engineering or Implementation view point Engineering Viewpoint defines the non- functional aspects of the service, such as availability and reliability Technical architect is responsible for the PIM Engineering Viewpoint artifacts

PSM- Platform specific model specification The PSM specification is the platform specific view of the service. The PSM specification is a technology binding of the PIM interface specification The PSM specification is developed primarily by the technical architects and provides details of the technology which will be used to provide the service capabilities and information exchange

PSM- Enterprise viewpoint The Enterprise Viewpoint defines the technology platforms that are available for realization of the service in the PSM specification The project analysts have primary responsibility for the analysis work and artifacts required to populate the PSM specification Enterprise Viewpoint, working with the technical architects. The project architects are responsible for working with the project analysts to ensure that the service adheres to the PIM specifications. The project analysts are also responsible for working with the software engineers to identify and evaluate the best technology platform by which the service can be realized

PSM- Information viewpoint The information model in the PSM specification defines the actual wire format in which the service data will be exchanged The project architect has primary responsibility for the analysis work and artifacts required to populate the PSM Information Viewpoint

PSM- Computational or behavioral viewpoint Platform-specific Model (PSM) Computational or Behavioral Viewpoint is represented by the actual interface which the service will expose The interface specification provides the exact method signatures, the input and output parameters defined in the PSM-level information model, and the exception conditions The project architect has primary responsibility for the PSM specification Computational Viewpoint artifacts, including generating the physical interface

PSM- Engineering viewpoint Defines actual working of the physical interface Focuses on the non-functional aspects of the service such as interacting with a service, binding to a service and authentication to a service The project architect has primary responsibility for the PSM specification Engineering Viewpoint artifact

PSM- Technology viewpoint Technology Viewpoint ensures that the service developers adhere to various technology standards that are enforced at the enterprise level by providing detailed implementation considerations The project architect has primary responsibility for the PSM specification Technology Viewpoint