conceptual model

34
Conceptual Model

Upload: duer

Post on 25-Feb-2016

46 views

Category:

Documents


1 download

DESCRIPTION

Conceptual Model. UML overview, where are we now? Understands what concept model is. Concepts. Attributes. Associations. Knowing how to draw a concept model either from the problem domain or the use case. . Overview. UML Process Overview. 1) Use Cases - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Conceptual Model

Conceptual Model

Page 2: Conceptual Model

2

Overview

UML overview, where are we now?

Understands what concept model is. Concepts. Attributes. Associations.

Knowing how to draw a concept model either from the problem domain or the use case.

Page 3: Conceptual Model

3

1) Use Cases

Define user interaction with the system.

2) Conceptual Model

Underline nouns to identify concepts in the problem domain.

Use the underlined nouns from the use cases to create the concepts in the conceptual model.

Some of the nouns, if they identify simple data types, are used to create attributes of these concepts.

Create associations between the concepts.

3) Sequence Diagram Create system sequence diagrams for each use case scenario.

Each sequence event in the diagram corresponds to a user interaction with the system specified by the expanded use case.

UML Process Overview

Page 4: Conceptual Model

4

4) System Contracts Specify post-conditions for each system event in the system sequence diagrams.

Use the conceptual model to identify objects created, associations formed, and attributes modified.

Collaboration Diagram Create a collaboration diagram for each system event & Apply patterns.

6) Class Diagram Add methods and additional attributes which were discovered in the collaboration

diagrams to the classes in the conceptual model.

7) Code Create classes with their names, attributes and method signatures taken from the class

diagram.

For each method on a class, use the collaboration diagrams to find the sequence of messages generated when the method is called and create at least one line of code for each message.

UML Process Overview

Page 5: Conceptual Model

5

Conceptual (Domain) Model

Is also named domain model and is considered an analysis-level activity. A model of real-world objects and NOT an attempt to design the actual

software. It’s a representation of real-world things, not software components. It’s a set of static structure diagrams; no operations are defined.

It may show:

Concepts

Attributes of concepts.

Associations between concepts.

Page 6: Conceptual Model

6

Page 7: Conceptual Model

7

Patron

Loan

Librarian

Book

Library

Page 8: Conceptual Model

8

Conceptual (Domain) Model

A domain model is a description of things in the real world.

A domain model is NOT a description of the software design.

A concept is an idea, thing, or object.

Conceptual (Domain) Model

Page 9: Conceptual Model

9

Page 10: Conceptual Model

10

Cashier

customer

Items

Sale

Sale line item

POS

Store

Page 11: Conceptual Model

11

Conceptual Classes in the Sale Domain

A central distinction between object-oriented and structured analysis: division by concepts (objects) rather than division by functions.

Page 12: Conceptual Model

12

Strategies to Identify Conceptual Classes

Use a conceptual class category list.

Make a list of candidate concepts.

Use noun phrase identification.

Identify noun (and noun phrases) in textual descriptions of the problem domain, and consider them as concepts or attributes.

Use cases are excellent description to draw for this analysis.

Page 13: Conceptual Model

13

Use a Conceptual Class Category List

Example Concept Category

POS, Airplane Physical or tangible objects.

Product Specification,Flight Description

Specifications, designs, or descriptions of things.

Store, Airport Places.

Sale, Payment, Reservation Transactions.

Sales Line Item Transaction line items.

Cashier, Pilot Roles of people.

Store, Bin, Airplane Containers of other things.

* See complete list in Larman 2nd edition, P.G. 134 - 135.

Page 14: Conceptual Model

14

Finding a Conceptual Classes with Noun Phrase Identification

The fully addressed use cases are an excellent description to draw for this analysis.

Some of these noun phrases are candidate concepts; some may be attributes of concepts.

A mechanical noun-to-concept mapping is not possible, as words in a natural language are (sometimes) ambiguous.

Process Sale Use Case (Buy Items)1. This use case begins when a Customer

arrives at a POS checkout with items to purchase.

2. The Cashier starts a new sale.

3. Cashier enters item identifier.

Page 15: Conceptual Model

15

Disadvantages of Noun Phrase Identification

The imprecision of natural language. Different noun phrases may represent the same conceptual class or attribute, among

other ambiguities.

Nouns do not always result in classes, or objects in the problem domain. Many sentences in a functional specification may be in the wrong form for easy

identification of the objects and classes. For example, ”roll back the transaction” or “the software will compute the average salary”.

In many cases, the nouns, especially subjects to sentences, refer to:

1) An entire assembly or a computer software configuration, 2) A sub assembly or a software component, 3) An attribute,4) Service.

Page 16: Conceptual Model

16

The Need for Specification or Description Conceptual Classes

What is wrong with this picture?

Consider the case where all items are sold, and thus deleted from the computer memory.

How much does an item cost?

Page 17: Conceptual Model

17

The Need for Specification or Description Conceptual Classes

The memory of the item’s price was attached to inventoried instances, which were deleted.

Notice also that in this model there is duplicated data (description, price, itemID).

Page 18: Conceptual Model

18

The Need for Specification or Description Conceptual Classes

Add a specification or description concept when:

Deleting instances of things they describe results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing.

It reduces redundant or duplicated information.

Page 19: Conceptual Model

19

The NextGen POS (Partial) Domain Model

Page 20: Conceptual Model

20

Adding Associations

Page 21: Conceptual Model

21

Finding Associations Common Associations List

Example Category

Drawer - POS A is a physical part of B

SalesLineItem - Sale A is a logical part of B

POS - Store A is physically contained in/on B

ItemDescription - Catalog A is logically contained in B

ItemDescription - Item A is a description for B

SalesLineItem - Sale A is a line item of a transaction or report B

Sale - POS A is known/logged/recorded/captured in B

Cashier - Store A is a member of B

* See complete list in Larman 2nd edition, P.G. 156 - 157.

Page 22: Conceptual Model

22

Multiplicity

Multiplicity defines how many instances of a type A can be associated with one instance of a type B, at a particular moment in time.

For example: a single instance of a Store can be associated with “many” (zero or more) Item instances.

Page 23: Conceptual Model

23

Multiplicity

Page 24: Conceptual Model

24

Naming Associations

Name an association based on a TypeName-VerbPhrase-TypeName format.

Association names should start with a capital letter.

A verb phrase should be constructed with hyphens.

The default direction to read an association name is left to right, or top to bottom.

Page 25: Conceptual Model

25

Multiple Associations Between Two Types

It’s not uncommon to have multiple associations between two types.

In the example, not every flight is guaranteed to land at an airport.

Page 26: Conceptual Model

26

Adding Attributes

An attribute is a logical data value of an object.

Include the following attributes: those for which the requirements suggest or imply a need to remember information.

For example, a Sales receipt normally includes a date and time. The Sale concept would need a

date and time attribute.

Page 27: Conceptual Model

27

Valid Attributes Types

Keep attributes simple.

The type of an attribute should NOT normally be a complex domain concept, such as Sale or Airport.

Attributes in a Domain Model should preferably be: Pure data values: Boolean, Date, Number, String,...

Simple attributes: color, phone number, zip code, universal product code (UPC),...

Page 28: Conceptual Model

28

Domain Model Conclusion

Page 29: Conceptual Model

29

University Case Study

We need to write an application supporting us in managing the information about university operation. Right now, at Stockholm University we have a substantial amount of students - 35 000 students. To manually manage all information about students is simply impossible. Hence, SU needs some automated support. In addition to this, we need handle information on courses and lecturers giving these courses.

Recently, SU has taken over the library and book shops. They want to provide better service to their students, and they want to better integrate the management of course literature with all other courses given at SU. Hence, they wish to automate the book management as well.

This gives them better insight into the education on the course level, and provides a solid basis for evaluating the courses and a basis for establishing the incremental educational programme. The knowledge of which books are utilised on which course helps them identify the overlapping in the educational material.

To be able to provide high quality education, SU must have highly competent lecturers. SU wishes to store information about their lecturers and their state of competence and its development. By competence, SU means professional, pedagogical and administrative competence.

Underline concepts (or maybe attributes), Red means association or transaction category concept.

Page 30: Conceptual Model

30

University Case Study: Conceptual Classes

Student

Book

Lecturer

Course

Book shop

Library

University Do we need a class called University?

CourseEvaluation

CourseOverlapping Competence

CompetenceEvaluation

Page 31: Conceptual Model

31

University Case Study: Attributes

Student

pnr: Integerstudent_name: Stringaddress: Stringnationality: Stringdegree_level: Stringgrade: IntegerIQ Integer$average_age: Integer

Teacher

pnr: Integerteacher_name: Stringrole: Stringped_competence: Stringadmin_competence: Stringprof_competence: Stringpercentage_of_full_time: Integersalary: Integermartial_state: Stringresearch_engagement: String

Course

course_number: Integercourse_name: Stringcourse_description: Stringno_of_students: Integerteacher_name: Stringequipment_type: String

Book

book_number: IntegerISBN_number: Stringtitle: Stringprice: Real

Page 32: Conceptual Model

32

University Case Study Associations

Students at SU may take many different courses. The students however, should not take more than five courses during one semester. A course may only start if there are at least 15 students registered. Otherwise, the course has to be cancelled. Teaching for less than 15 students would be too expensive.

The courses are taught by lecturers. The fact that you are a lecturer does not hinder you from taking courses at university. There may be cases that a lecturer takes and teaches on one and the same course simultaneously. This is in cases when the lecturer is a PhD student. The work he has put into developing and teaching on a course will give him credit point within his PhD studies.

So lecturers may take courses as well. Each university course is based on some book. One course may be based on at least one book. However, many books may be read on one and the same course.

Blue means constraint, many to many will be implemented by adding a transaction class.

Page 33: Conceptual Model

33

University Case Study: Associations

Page 34: Conceptual Model

34

University Case StudyAssociations

We do not need these any more!