1 Lecture 4.5: AV-1 and AV-2 (Ch 3.1 and 3.2) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.

Slides:



Advertisements
Similar presentations
Chapter 7 Structuring System Process Requirements
Advertisements

Chapter 7 Other Requirements Good Fast Cheap Pick any two. 1CS John Cole.
Prentice Hall, Database Systems Week 1 Introduction By Zekrullah Popal.
Chapter 4.
SYSTEM ANALYSIS & DESIGN (DCT 2013)
Systems Analysis and Design 9th Edition
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
The Use of Zachman Framework Primitives for Enterprise Modeling
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Systems Analysis and Design in a Changing World, 6th Edition
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
SE 555 Software Requirements & Specification Requirements Analysis.
Modeling and Evaluation. Modeling Information system model –User perspective of data elements and functions –Use case scenarios or diagrams Entity model.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Tool support for Enterprise Architecture in System Architect Architecture Practitioners Conference, Brussels David Harrison Senior Consultant, Popkin.
Chapter 7 Structuring System Process Requirements
6 Systems Analysis and Design in a Changing World, Fourth Edition.
1 Lecture 1.1: Course Overview Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Chapter 6: The Traditional Approach to Requirements
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 6 The Traditional Approach to Requirements
Documenting Software Architectures
1 Lecture 5.3: SEF Ch 4 Requirements Analysis Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Systems Analysis and Design in a Changing World, Fifth Edition
1 Lecture 3.9: RFP, SOW and CDRL (SEF Ch 19) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Chapter 1: The Database Environment and Development Process
DBS201: DBA/DBMS Lecture 13.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
Business Requirements Using Unified Modeling Language Eric H. Castain, SVP Internet Services Group, Architecture Wells Fargo March 2005.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
1 Lecture 3.1: Project Planning: Work Breakdown Structure (WBS) [SEF Ch 9] Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
1 Lecture 5.2a: SEF Ch 8 SE Outputs Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
1 Lecture 5.2.b: Requirements Specifications (IEEE 830) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Software Requirements Engineering CSE 305 Lecture-2.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Chapter 7 Applying UML and Patterns Craig Larman
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Database Management System Prepared by Dr. Ahmed El-Ragal Reviewed & Presented By Mr. Mahmoud Rafeek Alfarra College Of Science & Technology- Khan younis.
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
1 CS Tutorial 5 Frid. Oct 23, 2009 Design Document Tutorial.
TAL7011 – Lecture 4 UML for Architecture Modeling.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
Lecture 2.1b: DoD Acquisition Process (SEF Ch 2)
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
1 Class exercise II: Use Case Implementation Deborah McGuinness and Peter Fox CSCI Week 8, October 20, 2008.
Systems Analysis and Design 8th Edition
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Software Engineering Lecture 10: System Engineering.
1 Lecture 2.4a: SEF SE Planning and the SEP (SEF Ch 16) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Documenting an Architecture 10 pages, half pictures.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Documenting Software Architectures. Outline  Introduction  Uses of Architectural Documentation  Views  Choosing the Relevant Views  Documenting a.
1 Lecture 2.3: SE Process (SEF Ch 3) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
R R R CSE870: UML Component Diagrams Implementation Diagrams.
Business System Development
Software Specification Tools
DATA MODELS.
Documenting an Architecture
Systems Architecture & Design Lecture 3 Architecture Frameworks
Software Development Process Using UML Recap
Information system analysis and design
Presentation transcript:

1 Lecture 4.5: AV-1 and AV-2 (Ch 3.1 and 3.2) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

2 Agenda AV-1 Overview and Summary Information (Overview) AV-2 Integrated Dictionary (Overview) Conclusions

3 AV-1: Overview and Summary Information (3.1) Product Definition: the AV-1 “provides executive-level summary information in a consistent form that allows quick reference an comparison among architectures. AV-1 It includes assumptions, constraints and limitations that may affect high-level decision processes involving the architecture.” Product Purpose: “[It] enable[s] the reader to select one or more architectures from among many to read in detail. … it serves as a planning guide … [and] provides summary textual information concerning the architecture.” Implementation Options Hyperlinks Briefing Text, Tables, Graphics Views Multiplicity: 1/project Critical Artifact Product Detailed Description (Content):

4 Base Product Description (X.Y.1) and UML Representation (X.Y.2) X.1.1 provides a description of the “reference” artifact (generally SA- based) X.1.2 provides one or more UML artifacts that may be used as an alternative to the reference artifact Note there is no UML equivalent to a AV-1

5 AV-1 Data Element Definition (3.1.3) [1]

6 AV-1 Data Element Definition (3.1.3) [2]

7 CADM ER Diagram for the AV-1 (3.1.4)

8 Class Exercise: Develop AV-1

9 AV-2: Integrated Dictionary Product Definition: The AV-2 “contains definitions of terms used in a given architecture.” :Consists of textual definitions in he form of a glossary” “Data repository with definitions of all terms used in all products” All functions, nodes, classes, data entity, data attribute, operations, components, interfaces, etc. Product Purpose: “Provides a central repository for a given architecture’s data and metadata.” Ensures Consistency/Unity in vision Ensures Consistency between Artifacts Implementation Options: Access Database Word Document Architecting Tool Output Multiplicity: 1/project Content: Definitions of Terms used in the Architecture: Activities/Functions/Methods Input/Output/Internal Data Entities Data Attributes (including description, data type, range, units, etc.) Actors Operational Nodes Structural Elements/Mechanisms (Systems, Subsystems, Components, Interfaces, etc.) Classes Performance Metrics Etc. May also include Acronym List Critical Artifact

10 Taxonomies (Types of entities)

11 Base Product Description (3.2.1) and UML Representation (3.2.2) provides a description of the “reference” artifact (generally SA- based) provides one or more UML artifacts that may be used as an alternative to the reference artifact Note there is no UML equivalent to a AV-1

12 Data Element Definitions (3.2.4) and CADM Model (3.2.5) Blah Blah Blah …

13 AV-2: Integrated Dictionary - WBRS Example

14 Example: Integrated Dictionary Legend Entry Types: Operational Node (ON) Operational Element (OE) System (Sys) Subsystem Element (SE) Actor (Actor) External System (ES) External Subsystem Element (ESE) Function/Activity (Fnc) Rule Model (RM) State (State) Data Entity (DE) Data Attribute (DA) Reference ID: Function/Activity: A1.X.y System/Subsystem Element: C1.X.y External System/Subsystem Element: ESX.Y Rule Model: RM1.X.y Data Entity (DE): DEX.y Acronym Term Definitions Functions should indicate I/O Des and Rule Models System/Subsystem Elements should include alllocated Functions DEs should include list of DAs DAs should include data type, visibility, and ranges. RMs should include reference to functions and DEs

15 Conclusions AV-1 and AV-2 are essential products for every architecture AV-1 is usually developed in a Word (or HTML) document and may be hyperlinked to supporting artifacts Initially one may want to develop the AV-2 in Word or Excel until you figure out the desired format or until a CASE Architecture Tool is selected.