Elements Of Modeling. 1.Data Modeling  Data modeling answers a set of specific questions that are relevant to any data processing application. e.g. ◦

Slides:



Advertisements
Similar presentations
Entity Relationship Diagrams
Advertisements

Alternative Approach to Systems Analysis Structured analysis
Chapters 7 & 9 System Scope
Analysis Concepts, Principles, and Modeling
Lecture 8- Analysis Modeling The Elements of Anaylsis Model The Elements of Anaylsis Model Data Modeling, Functional Modeling and Information Flow Data.
Chapter : Analysis Modeling
Analysis Modeling.
Software Requirements Engineering Elaboration Process Lecture-13.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Analysis Modeling Over view of today’s lesson T he analysis model is the first technical representation of a system. Analysis modeling uses a combination.
Chapter 8 Analysis Modeling
CS /31 Illinois Institute of Technology CS487 Software Engineering Analysis Modeling Instructor David Lash.
Chapter 6 Requirements Modeling: Scenarios, Information, and Analysis Classes Slide Set to accompany Software Engineering: A Practitioner’s Approach,
CS /47 Illinois Institute of Technology CS487 Software Engineering Requirements II- part B Instructor David Lash.
APPENDIX C DESIGNING DATABASES
Trisha Cummings.  Most people involved in application development follow some kind of methodology.  A methodology is a prescribed set of processes through.
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
IT 244 Database Management System Data Modeling 1 Ref: A First Course in Database System Jeffrey D Ullman & Jennifer Widom.
Computer System Analysis Chapter 10 Structuring System Requirements: Conceptual Data Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 5 Entity Relationship (ER) Modelling
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
DATABASEMODELSDATABASEMODELS  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data.
Concepts and Terminology Introduction to Database.
Database Design Principles – Lecture 3
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Developed by Reneta Barneva, SUNY Fredonia for CSIT 425 Requirements Modeling.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
Chapter 8 Analysis & Modeling. Data Modeling examines data objects independently of processing focuses attention on the data domain creates a model at.
Class-based Modeling.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 24. Review ANALYSIS Level Class Diagram – Identifying Entities – Identifying Attributes – Identifying Operations.
Object Oriented Analysis
IFS310: Module 6 3/1/2007 Data Modeling and Entity-Relationship Diagrams.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Database Design – Lecture 4 Conceptual Data Modeling.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 10 요구사항 모델링 : 클래스 기반 방법론 Requirements Modeling: Class-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for.
 Building Block Building Block  Things in the UML Things in the UML  Structural Things Structural Things  Behavioral Things Behavioral Things  Grouping.
Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 12 Analysis Modeling. Analysis Modeling ä Two primary methods today ä Structured Analysis ä Object-oriented analysis ä Some important considerations.
Building analysis model  Analysis modeling uses a combination of text and diagrammatic forms to depict requirements for data function and behavior in.
UML - Development Process 1 Software Development Process Using UML.
EntityRelationshipDiagrams. Entity Relationship Models The E-R (entity-relationship) data model views the real world as a set of basic objects (entities)
OBJECT-ORIENTED TESTING. TESTING OOA AND OOD MODELS Analysis and design models cannot be tested in the conventional sense. However, formal technical reviews.
Department of Mathematics Computer and Information Science1 CS 351: Database Management Systems Christopher I. G. Lanclos Chapter 4.
Course Instructor: Kashif I hsan 1. Chapter # 6 2.
Database Systems: Design, Implementation, and Management Tenth Edition
Cmpe 589 Spring 2006.
UML Diagrams By Daniel Damaris Novarianto S..
© The McGraw-Hill Companies, All Rights Reserved APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
Chapter 8 Analysis & Modeling
Chapter 8 Building the Analysis Model (2) Analysis Modeling
Requirements Engineering
Data Dictionaries ER Diagram.
UML Diagrams Jung Woo.
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Object-Oriented Analysis
Chapter 10 Requirements Modeling: Class-Based Methods
Chapter 12 Analysis Modeling
Requirement Analysis using
Entity-Relationship Diagram (ERD)
Software Modelling and Design
Lecture 10 Structuring System Requirements: Conceptual Data Modeling
Presentation transcript:

Elements Of Modeling

1.Data Modeling  Data modeling answers a set of specific questions that are relevant to any data processing application. e.g. ◦ What are the primary data objects to be processed by the system? ◦ What is the composition of each data object and what attributes describe the object? ◦ Where do the objects currently reside? ◦ What are the relationships between each object and other objects? ◦ What are the relationships between the objects and the processes that transform them?

1.Data Modeling  To answer these questions, data modeling methods make use of the entity relationship diagram.  The ERD, enables a software engineer to identify data objects and their relationships using a graphical notation.  In the context of structured analysis, the ERD defines all data that are entered, stored, transformed, and produced within an application.  The entity relationship diagram focuses solely on data, representing a "data network" that exists for a given system.  The ERD is especially useful for applications in which data and the relationships that govern data are complex.  Unlike the data flow diagram, data modeling considers data independent of the processing that transforms the data

1.Data Modeling Data model consists of three interrelated pieces of information: – the data object, – the attributes that describe the data object, – & the relationships that connect data objects to one another.

1.a Data Object A data object is a representation of almost any composite information that must be understood by software. Composite information means something that has a number of different properties or attributes. Therefore, width (a single value) would not be a valid data object, but dimensions (incorporating height, width, and depth) could be defined as an object.

1.a Data Object  A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file).  The data object description incorporates the data object and all of its attributes. Data objects are related to one another.  For e.g. person can own car, where the relationship own connotes a specific "connection‖ between person and car. The relationships are always defined by the context of the problem that is being analyzed.

1.b Attributes  Attributes define the properties of a data object and take on one of three different characteristics. They can be used to ◦ (1) name an instance of the data object, ◦ (2) describe the instance, or ◦ (3) make reference to another instance in another table.  In addition, one or more of the attributes must be defined as an identifier—that is, the identifier attribute becomes a "key" when we want to find an instance of the data object.  In some cases, values for the identifier(s) are unique, although this is not a requirement. Referring to the data object car, a reasonable identifier might be the ID number.

1.c Relationship Data objects are connected to one another in different ways. Consider two data objects, book and bookstore. A connection is established between book and bookstore because the two objects are related. We can define a set of object/relationship pairs that define the relevant relationships.

2.Object Oriented Modeling The elements of an object model comprise of classes and objects, attributes, operations, and messages.

2.a Classes and Objects  Objects can be ◦ External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. ◦ Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problem. ◦ Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. ◦ Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. ◦ Organizational units (e.g., division, group, team) that are relevant to an application. ◦ Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. ◦ Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or in the extreme, related classes of objects.

2.b Attributes  Attributes describe an object that has been selected for inclusion in the analysis model.  In essence, it is the attributes that define the object—that clarify what is meant by the object in the context of the problem space.  For example, if we were to build a system that tracks baseball statistics for professional baseball players, the attributes of the object player would be quite different than the attributes of the same object when it is used in the context of the professional baseball pension system. In the former, attributes such as name, position, batting average, fielding percentage, years played, and games played might be relevant. ◦ For the latter, some of these attributes would be meaningful, but others would be replaced (or augmented) by attributes like average salary, credit toward full vesting, pension plan options chosen, mailing address, and the like.

2.c Operations  Operations define the behavior of an object and change the object‘s attributes in some way. More specifically, an operation changes one or more attribute values that are contained within the object.  Therefore, an operation must have "knowledge" of the nature of the object's attributes and must be implemented in a manner that enables it to manipulate the data structures that have been derived from the attributes.  Although many different types of operations exist, they can generally be divided into three broad categories: ◦ (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting), ◦ (2) operations that perform a computation, and ◦ (3) operations that monitor an object for the occurrence of a controlling event.