George Blank University Lecturer. CS 602 Java and the Web Domain Models.

Slides:



Advertisements
Similar presentations
Week 2 The Object-Oriented Approach to Requirements
Advertisements

Can you plan without understanding what is it that you are planning for? e.g. - what is it we are doing? - what do we need to do?
The System Development Life Cycle
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Object Oriented Analysis and Design
NJIT Use Case Model Operation Contracts Prepared By: Sumit Sharma.
SYSTEMS DEVELOPMENT Phases, Tools, and Techniques
Managing International IS9.200 Information Systems for Management1 Chapter 15 International Information Systems (IIS)
Object Oriented Analysis and Design Chapter 1 Applying UML and Patterns -Craig Larman.
Systems Development Life Cycle
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software Life Cycle Model
The chapter will address the following questions:
Get More Value from Your Reference Data—Make it Meaningful with TopBraid RDM Bob DuCharme Data Governance and Information Quality Conference June 9.
Petter Nielsen Information Systems/IFI/UiO 1 Software Prototyping.
Lecture # 04 & 05 CS314 Introduction To Software Development Software Development Process (SDP) Instructor :Muhammad Janas khan
Software Engineering CS B Prof. George Heineman.
111 Subsystems CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 7)
ITEC224 Database Programming
Establishing Group Norms/Guidelines
1 Introduction to Database Systems. 2 Database and Database System / A database is a shared collection of logically related data designed to meet the.
Artificial, Composite and Secondary UIDs
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Chapter 7 Applying UML and Patterns -Craig Larman
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Copyright 2002 Prentice-Hall, Inc. 1.1 Modern Systems Analysis and Design Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 1 The Systems Development.
© 2008 Prentice Hall2-1 Introduction to Project Management Chapter 2 The Project Management Life Cycle Information Systems Project Management: A Process.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
1 COMP 350: Object Oriented Analysis and Design Lecture 1Introduction References: Craig Larman Chapter 1.
240 3/30/98 CSE 143 Object-Oriented Design [Chapter 10]
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
NJIT UML Class Diagrams Chapter 16 Applying UML and Patterns Craig Larman.
 What is Modeling What is Modeling  Why do we Model Why do we Model  Models in OMT Models in OMT  Principles of Modeling Principles of Modeling 
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns - Architectural Architectural Patterns:
Use Cases CS 6961 – Lecture 4 Nathan Dykman. Neumont UniversityCS Lecture 102 Administration Homework 1 is due –Still reviewing the proposal, but.
CASE Cases are descriptions of real-life situations, that may (a) include problems, solutions attempted, results and conclusions (research cases) or (b)
Object Oriented Analysis and Design Chapter 1 Applying UML and Patterns -Craig Larman.
111 Subsystems CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 7)
INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
The collection of phases that are performed in completing a project. Each project phase is marked by completion of one or more deliverables. The conclusion.
TECHNICAL WRITING 2013 UNIT 3: DESIGNING FOR CHANGE.
1 ECM APPLICATIONS AND SOLUTIONS - PART 1 MODULE 8 ECM SPECIALIST COURSE 1 Copyright AIIM.
The System Development Life Cycle
Systems Development Life Cycle
SDLC and Related Methodologies
Elaboration popo.
Use Cases and Scenarios
GRASP: Visibility and Design
DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS
Methodology Overview 2 basics in user studies Lecture /slide deck produced by Saul Greenberg, University of Calgary, Canada Notice: some material in this.
The System Development Life Cycle
Introduction to Project Management Chapter 2 The Project Management Life Cycle Information Systems Project Management: A Process and Team Approach, 1e.
Introduction to Design Patterns Part 1
Object Oriented Analysis and Design
Business Modeling - Domain Analysis
SDLC and Related Methodologies
Introduction – Identification of Basic Bindings in the Company
Systems Development Life Cycle
Simulation-driven Enterprise Modelling: WHY ?
Trend Mapping Template
Presentation transcript:

George Blank University Lecturer

CS 602 Java and the Web Domain Models

Introduction There are two different kinds of class models used at different phases of object oriented design. During the Inception Phase, Domain Modeling is used to discover real world objects that will become candidates for system objects. During the Elaboration and Construction Phases, a Class Model is developed, usually being created automatically by a diagramming tool as part of creating Interaction Diagrams.

What is a Domain? A body of knowledge, or information about a particular area of application. Typically software developers think about two different kinds of domains; horizontal and vertical domains. A Vertical Domain is information about a particular industry, such as Telecommunication or Banking. A Horizontal Domain is information that crosses different industries, such as Marketing, Accounting, or Inventory.

Software Development Domains Most software development focuses on the intersection between a horizontal and a vertical domain, such as an Accounting Application for the Insurance Industry. Often corporate software developers develop expertise in one or more horizontal domains as well as their own industry.

Example During my software development career as part of AT&T’s Bell Labs, I was part of the Marketing and Financial Analysis district of the Business Operations Analysis division. I developed expertise in the Telecommunications vertical domain and the Marketing and Finance horizontal domains. When I transferred to Billing, AT&T sent me to school to learn the Telecommunications Billing domain.

Domain Analysis Domain analysis is a modeling task that is used to identify real world objects in the domains of interest for a particular application, and some of the most important relationships between some of those objects. This is an exploratory activity. Not all of the objects found will be used. A Glossary is often developed during domain analysis to define terms in the domains.

Rudimentary Class Diagrams A Domain Model is a simpler form of Class Model. Usually, a Class model includes three types of information about a class; it’s Name, Attributes, and Methods. Domain Models concentrate on object Names. A few Attributes and Methods may be documented, but they are secondary considerations.

System Objects A major difference between Domain Models and Class Models is that Domain Models concentrate on real world objects, while Class Models include system objects such as controllers, views, facades and menus that systems use to manage real world objects.

Object Names Object names are very important in object oriented development. Since naming occurs early, names have a strong influence on the structure and development of an application. Since the primary activity in design is assigning behavior to objects, getting the right objects is necessary before design.

White Boarding Domain modeling is often a White Board activity, where a small group of software analysts and subject matter experts brainstorm in a conference room, drawing the Domain Model on a white board with colored markers. A copy is created and distributed to participants and others who may be interested.

Prototyping Sometimes the Domain Model is entered into a modeling tool and used as an evolutionary prototype, being expanded into the Class model. This is not recommended. Best practices suggest a clear separation between thinking about the problem domain (analyzing the problem) and the solution domain (designing a solution). For this reason, it is better to think of the Domain Model as a throwaway prototype.