Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Similar documents
Domain Model and Domain Modeling

Domain Modeling: Associations and Attributes

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Domain Modeling. CSSE 574: Week 1, Part 3. Steve Chenoweth Phone: Office (812) Cell (937)

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D

Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD

Object-Oriented Functional Analysis and Design for POS Example

Constantinos Constantinides Computer Science and Software Engineering Concordia University Montreal, Canada

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Information Expert (or Expert)

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Modeling Dynamic Behavior

Äriprotsesside modelleerimine ja automatiseerimine Loeng 7 Valdkonna mudel

COMP 354: INTRODUCTION TO SOFTWARE ENGINEERING

On to Object-oriented Design

Modeling Dynamic Behavior

Domain Modeling- 2. Generalization

System Analysis & design

ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP

Object-Oriented Software Engineering Practical Software Development using UML and Java

Principles of Software Construction: Objects, Design, and Concurrency

Software Modeling & Analysis

A - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models

Responsibilities. Using several specific design principles to guide OO design decisions.

References: Applying UML and patterns Craig Larman

Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)

SE 1: Software Requirements Specification and Analysis

Class Diagrams in Analysis

Object Oriented Software Development CIS Today: Object Oriented Analysis

On to Object-oriented Design

COMP 6471 Software Design Methodologies

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

OO Design2. Design Artifacts

OBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS

Software Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II)

MSO Lecture 3. Wouter Swierstra. September 14, 2015

IMS1002/CSE1205 Lectures 1

CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD

System Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes

Principles of Software Construction: Objects, Design and Concurrency. Just enough UML. toad

VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS

user.book Page 45 Friday, April 8, :05 AM Part 2 BASIC STRUCTURAL MODELING

Principles of Software Construction: Objects, Design, and Concurrency

UML Modeling I. Instructor: Yongjie Zheng September 3, CS 490MT/5555 Software Methods and Tools

S T R U C T U R A L M O D E L I N G ( M O D E L I N G A S Y S T E M ' S L O G I C A L S T R U C T U R E U S I N G C L A S S E S A N D C L A S S D I A

Lesson 11. W.C.Udwela Department of Mathematics & Computer Science

Principles of Software Construction: Objects, Design, and Concurrency. Assigning Responsibilities to Objects. toad. Jonathan Aldrich Charlie Garrod

Object-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 5: Modelling with Classes

Principles of Software Construction: Objects, Design and Concurrency. Object-Oriented Design: Assigning Responsibilities.

Object-Oriented Design. Module UFC016QM. and Programming. Objects and Classes. O-O Design Unit 2: Faculty of Computing, Engineering

Operations Contracts and Preliminaries on Design

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

Software Modeling & Analysis

Premium POS Pizza Order Entry Module. Introduction and Tutorial

Principles of Software Construction: Objects, Design, and Concurrency

Object-Oriented Analysis and Design

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

Final Exam CISC 475/675 Fall 2004

A Conceptual Model of the UML

Lecture 8: Use Case -Driven Design. Where UML fits in

17. GRASP: Designing Objects with Responsibilities

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

ROEVER ENGINEERING COLLEGE DEPARTMENT OF INFORMATION TECHNOLOGY CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD

Mapping Designs to Code

Object Design II: Design Patterns

22/09/2012 INFO2110. Copyright Warning. Revision of class diagram. Overview. Purpose of class diagram. Generalization Relationship

What is a Model? Copyright hebley & Associates

COMP 6471 Software Design Methodologies

Object Analysis & Design in the textbook. Introduction to GRASP: Assigning Responsibilities to Objects. Responsibility-Driven Design

THE UNIVERSITY OF THE WEST INDIES. Answer ALL questions. Marks for each question are given in the margin. This exam is worth 60 marks

SIF8035. Events and System Requirements

Software Engineering I (02161)

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD

CSSE 374: UML Activity Diagrams. Shawn Bohner Office: Moench Room F212 Phone: (812)

Domain-Driven Development with Ontologies and Aspects

Design First ITS Instructor Tool

On to Iteration 3, and Activity Diagrams CSSE 574: Session 6, Part 1

Domain Analysis. SWEN-261 Introduction to Software Engineering. Department of Software Engineering Rochester Institute of Technology.

21. Document Component Design

The Zachman Framework

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

INTRODUCTION TO UNIFIED MODELING MODEL (UML) & DFD. Slides by: Shree Jaswal

MIS2502: Data Analytics Relational Data Modeling - 1. JaeHwuen Jung

Interaction Modelling: Use Cases

Introduction to UML. (Unified Modeling Language)

MIS2502: Data Analytics Relational Data Modeling. Jing Gong

Information Technology Audit & Cyber Security

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

User Guide. Document Version: 1.0. Solution Version: 365_102017_3_4

MIS2502: Data Analytics Relational Data Modeling. Jing Gong

From Analysis to Design. LTOOD/OOAD Verified Software Systems

Assigning Responsibilities by Larman

From designing to coding

2 GRASP Patterns and basic OO Design. Roel Wuyts OASS

Requirements Engineering

Chapter 6 Structuring System Requirements: Process Modeling 6.1

The Object-Oriented Design Process

Basic Structural Modeling. Copyright Joey Paquet,

(Murlidhar Group of Institutions,Bhavnagar Road, Rajkot) by:-assit. Prof. Vijay Vora (SOOADM) MCA-III

Transcription:

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt

Dr. Michael Eichberg Fachgebiet Software Engineering Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering Domain Model and

Domain Model 3 A Handbook of Software and Systems Engineering Curtis law: [ ] Good designs require deep application knowledge. Albert Endres and Dieter Rombach; Addison Wesley, 2003

The Domain Model illustrates noteworthy concepts in a domain. Domain Model =dt. Analysemodell (Konzeptmodell) Domain Model 4 It is the basis for the design of the software The domain model is created during object-oriented analysis to decompose the domain into concepts or objects in the real world The model should identify the set of conceptual classes (The domain model is iteratively completed.) The domain model is also called conceptual model, domain object models or analysis object models.

Domain Model 5 Conceptual Classes Conceptual classes are ideas, things or objects in the domain. A conceptual class has a symbol representing the class, an intension and an extension that defines the set of examples to which the conceptual class applies. Domain concepts / conceptual classes are not software objects as e.g. in Java, C# or.net! intension =dt.(hier) Bedeutung extension =dt.(hier) Ausprägung

To visualize domain models the UML class diagram notation is used. Visualization of the Domain Model using UML Class Diagrams 6 However, no operations are defined only: domain objects or conceptual classes associations between them and attributes of conceptual classes are shown The result is a conceptual perspective model.

A class describes a set of objects with the same semantics, properties and behavior. When used for domain modeling, it is a visualization of a real world concept. UML Class Diagrams 7 Sale Shop Payment...

Attributes are logical data values of an object. UML Class Diagrams 8 attributes Sale date / total : Money derived attribute ("/") It is useful to identify those attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.

Attributes are logical data values of an object. UML Class Diagrams 9 Full syntax for an attribute in the UML: visibility name : type multiplicity = default {property string} Math + pi: Real = 3.14 {readonly} Person firstname middlename : [0..1] lastname

An association is a relationship between classes. The ends of an association are called roles. Roles optionally have a multiplicity, name and navigability. UML Class Diagrams 10 name multiplicity Payment amount 1 PaysFor! 1 Sale date time association

The multiplicity defines how many instances of a class A can be associated with one instance of a class B at any particular moment. multiplicity =dt. Vielheit / Vielfachheit UML Class Diagrams 11 * T zero or more 1..* T one or more 5,10 T exactly 5 or 10

Two classes can have multiple associations. UML Class Diagrams 12 multiplicity =dt. Vielheit / Vielfachheit Flight * Flies-from 1 Airport * Flies-to 1

Excerpt Of the Domain Model For the POS System 13? Which are noteworthy domain concepts / domain objects?

How to create the domain model? 14 1. Find the conceptual classes Strategies: a. Reuse or modify an existing model explained b. Use a category list in the }following c. Identify noun phrases 2. Draw them as classes in a UML class diagram 3. Add associations and attributes Use the domain vocabulary; e.g. a model for a library should use names like Borrower instead of customer.

How to create the domain model? Find the conceptual classes - Strategy: reuse or modify an existing model. 15 Example: existing model for bank accounts and associated entries. {balance = sum(entries.amount)} Acount balance: Quantity 1 0..* Entry amount: Quantity whenchanged: Timepoint A possible source: Analysis Patterns - Reusable Object Models; Martin Fowler; Addison-Wesley, 1997

How to create the domain model? Find the conceptual classes - Strategy: use a category list. 16 Business transactions... Conceptual Class Category Classes (for the POS system) Sale, Payment Transaction line items... Product or service related to a transaction or transaction line item. Where is the transaction recorded? Roles of people or organizations related to the transaction; actors in use cases. Place of transactions. Noteworthy events, often with a time or place that need to be remembered. SalesLineItem Item Register Cashier, Customer, Store Store Sale, Payment...... line item =dt. Einzelposten transaction =dt. Abwicklung / Durchführung; Geschäftsvorfall

How to create the domain model? Find the conceptual classes - Strategy: identify noun phrases (linguistic analysis). 17 Identify the nouns and noun phrases in textual descriptions of a domain and consider them as candidate conceptual classes or attributes. A mechanical noun-to-class mapping isn t possible; words in natural languages are ambiguous; i.e. the same noun can mean multiple things and multiple nouns can actually mean the same thing.

How to create the domain model? Find the conceptual classes - Strategy: identify noun phrases. Example: Using the Process Sale use case as the source for identification. 18 Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each item. The system present a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates the inventory. The customer receives a receipt from the system and then leaves the store with the items.

How to create the domain model? Find the conceptual classes - Strategy: identify noun phrases. Example: Using the Process Sale use case as the source for identification. 19 Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each item. The system present a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates the inventory. The customer receives a receipt from the system and then leaves the store with the items.

Strategy: identify noun phrases. 20 Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each item. The system present a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates the inventory. The customer receives a receipt from the system and then leaves the store with the items. Identified candidate conceptual classes: Customer, Item, Cashier, Store, Payment, Sales Line Item, Inventory, Receipt, Sale. Should Receipt be in the domain model?

Guidelines when to include a candidate conceptual class that reports Information into the domain model 21 In general, it is not useful since all information is derived or duplicated from other sources. If it has a specific semantics w.r.t. the business, then it should be included. Should Receipt be in the domain model? A receipt is just a report of a sale and a payment...

Guidelines when to include a candidate conceptual class that reports information into the domain model 22 Should Receipt be in the domain model? A receipt is just a report of a sale and a payment... Well, it depends. if we just consider the Process Sale use case then receipt should not be part of the domain model; a receipt is just a report if we consider a Handle Return use case then a receipt represents an important concept on its own BTW, how about legal restrictions...? Domain Requirements

Guidelines when to include a description class into the domain model 23 A description class contains information that describes something else Examples: a product description records the price, picture and text of an item a flight description contains information about the flight (number) and the source and target destinations.

Guidelines when to include a description class into the domain model 24 A description class should be added to the domain mode when: There needs to be a description about an item or service, independent of the current existence of any examples of those items or services Deleting instances of things they describe results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing It reduces redundant or duplicated information

When should I model something as an attribute or a class? 25 Rule of Thumb: If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute. class attribute Sale date time

When should I model something as an attribute or a class? 26 Let s assume that we develop an airline reservation system. Should destination be an attribute of flight, or a conceptual class airport? A destination airport is building at a specific place, it is not just a number or some text. Hence, it should be a conceptual class. How about the name of the airport?

When should I add an association to the domain model? 27 Rule of Thumb: Include associations in the domain model for which knowledge of the relationship needs to be preserved for some duration. We are working on the conceptual model; we are not modeling associations at the software level.

When should I add an association to the domain model? 28 When an association is among the common associations list: A is a transaction related to another transaction B A is a line item of a transaction B A is a product or service for a transaction B A is a role related to a transaction B A is physical or logical part of B...

When should I add an association to the domain model? 29 E.g. the relation between a Sale and a SalesLineItem needs to be remembered However, it is not necessary to store the relation between a Cashier and a ProductDescription that he looks up

Name an association based on a ClassName- VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful. 30 Good examples: Player Is-on Square Sale Paid-by CashPayment Bad examples: Sale Uses CashPayment (Uses is usually generic and doesn t tell us anything.) Player Has Square (Has is usually generic and doesn t tell us anything)

The attributes in a domain model should preferably be primitive data types. 31 Very common data types include: Boolean, Date, Number, Character, String, Address, Color, Phone Number, avoid: recommended: Cashier name currentregister Cashier name Consider modeling quantities as classes to associated units; e.g. the data type of the amount attribute of payment should indicate the currency Register number Use associations to model dependencies between conceptual classes; do not use attributes.

Consider defining a new data type class for something that is initially considered a string. 32 If the string is composed of separate sections e.g., phone number, name of person,... Different operations are associated with the string e.g., social security number The string has other attributes The string is a quantity with a unit e.g., money has a unit for currency avoid: recommended: ProductDescription itemid : ItemId ProductDescription 1 1 ItemId id countrycode

Excerpt Of the Domain Model For the POS System 33? Which are noteworthy domain concepts / domain objects?

Excerpt Of the Domain Model For the POS System 34 Sales LineItem quantity 1..* Contained-in Records-sale-of 0..1 1 Item * Stocked-in Sale date time Paid-by 1 0..1 Captured-on! 1 Store address name Houses Payment amount 1 Register

The domain model serves as a source of inspiration for the design model. Purpose of 35 Domain Model Payment amount 1 1 Sale date time inspiration / basis Design Model Payment amount: Money getbalance():money 1 1 Sale date: Date starttime: Time gettotal(): Money By using the domain model as a direct inspiration for software classes the representational gap between the domain concepts and the program is (relatively) small.