42
Design Model Design Model Lecture Lecture p6 p6 T120B029 T120B029 200 200 4 4 pavasario sem. pavasario sem.

Design Model Lecture p6 T120B029 200 4 pavasario sem

Embed Size (px)

DESCRIPTION

Design Model Lecture p6 T120B029 200 4 pavasario sem. Main processes of the team assignment. requirements analysis. design process. coding. testing. design document. problem description. requirements document. Used technique: UML use case diagrams UML activity diagrams. - PowerPoint PPT Presentation

Citation preview

Page 1: Design Model  Lecture p6 T120B029 200 4  pavasario sem

Design Model Design Model LectureLecture

p6p6T120B029T120B029

20020044 pavasario sem. pavasario sem.

Page 2: Design Model  Lecture p6 T120B029 200 4  pavasario sem

2

Main processes of the team assignment

requirementsanalysis

designprocess

coding testing

Used technique:UML use case diagramsUML activity diagrams

Used technique:UML component diagrams,UML class diagrams, UML state diagramsUML sequence diagrams,UML activity diagrams

Used languages:JavaC++

requirementsdocument

problem description

design document

T120B029T120B029

Page 3: Design Model  Lecture p6 T120B029 200 4  pavasario sem

3

The Design Model

T120B029T120B029

• The analysis model represents the system in terms of objects that domain experts know.

• The design model represents the same system, but at a level of abstraction closer to the source code.

For example, the classes in the design model have a language and model properties assigned, which

define the mapping to code.

Page 4: Design Model  Lecture p6 T120B029 200 4  pavasario sem

4

Structural Diagrams

Used to visualize, specify, construct, document static aspects of system

• class diagram• package diagram [not standard UML]• object diagram• component diagram• deployment diagram

T120B029

Page 5: Design Model  Lecture p6 T120B029 200 4  pavasario sem

5

Common Uses of Class Diagrams

• to model vocabulary of the system, in terms of which abstractions are part of the system and which fall outside its boundaries

• to model simple collaborations (societies of elements that work together to provide cooperative behavior)

• to model logical database schema (blueprint for conceptual design of database)

T120B029

Page 6: Design Model  Lecture p6 T120B029 200 4  pavasario sem

6

Class diagram

• Central for OO modeling• Shows static structure of the system

– Types (!) of objects– Static relationships

• Association(e.g.: a company has many employees)

• Generalization (subtypes)(e.g.: an employee is a kind of person)

• Dependencies(e.g.: a company is using trucks to ship

products)

T120B029

Page 7: Design Model  Lecture p6 T120B029 200 4  pavasario sem

7

Three PerspectivesWe can look at classes from these perspectives:• Conceptual (OOAnalysis)

– Shows concepts of the domain– Should be independent from implementation

• Specification (OODesign)– General structure of the running system – Interfaces of software (types, not classes)– Often: Best perspective

• Implementation (OOProgramming)– Structure of the implementation (classes)– Most often used

Try to draw from a clear, single perspective

T120B029

Page 8: Design Model  Lecture p6 T120B029 200 4  pavasario sem

8

What are classes?

– A class describes a set of objects with an equivalent role or roles in a system

– Sources for objects: tangible real-world things, roles, events, interactions

T120B029

Page 9: Design Model  Lecture p6 T120B029 200 4  pavasario sem

9

Class• A class is a description of a set of objects

that share the same attributes, operations, relationships, and semantics.

• An attribute is a named property of a class that describes a range of values that instances of the property may hold.

• An operation is a service that can be requested from an object to affect behavior.

T120B029

Page 10: Design Model  Lecture p6 T120B029 200 4  pavasario sem

10

? • Why do we need class models? • What is a good class model? • How to identify classes? • What classes consist of? • What are associations and what

types of associations exist? • What are interfaces?

T120B029

Page 11: Design Model  Lecture p6 T120B029 200 4  pavasario sem

11

Identifying Classes

– Identify class candidates by picking all nouns and noun phrases out of system requirements specification

– Use singular form – Discard anything that does not seem

appropriate: redundant, vague, event or operation, outside of scope, attribute

T120B029

Page 12: Design Model  Lecture p6 T120B029 200 4  pavasario sem

12

Identifying Objects – Objective: System must satisfy

current requirements – Solution: Every required behavior

must be provided by some objects – Objective: System must be easy to

maintain and adapt to future requirements

T120B029

Page 13: Design Model  Lecture p6 T120B029 200 4  pavasario sem

13

Class Notation

Name

Attributes

Operations

T120B029

Page 14: Design Model  Lecture p6 T120B029 200 4  pavasario sem

14

Alternative Class Notations

Name

Attributes

Operations

Responsibilities

Name

Attributes

OperationsName

italics abstract

T120B029

Page 15: Design Model  Lecture p6 T120B029 200 4  pavasario sem

15

Attributes and Operations

• Attributes and Operations– Operations define the ways in which objects may

interact • Operation signatures – how are they defined? • Attributes are the data contained in an

object • Both can be public, protected or private

T120B029

Page 16: Design Model  Lecture p6 T120B029 200 4  pavasario sem

16

Attributes

• Conceptual: Indicates that customer have names

• Specification: Customer can tell you the name and set it(short for get/set methods)

• Implementation: An instance variable is available

Customer

nameaddress

creditRating

T120B029

Page 17: Design Model  Lecture p6 T120B029 200 4  pavasario sem

17

Operations• Services that a class knows to carry out• Correspond to messages of the class (or

IF)• Conceptual level

– principal responsibilities

• Specification level– public messages = interface of the class

• Normally: Don’t show operations that manipulate attributes

T120B029

Page 18: Design Model  Lecture p6 T120B029 200 4  pavasario sem

18

UML syntax for operations

visibility name (parameter list) : return-type-expression

+ assignAgent (a : Agent) : Boolean

– visibility: public (+), protected (#), private (-)• Interpretation is language dependent• Not needed on conceptual level

– name: string– parameter list: arguments (syntax as in attributes)– return-type-expression: language-dependent specification

T120B029

Page 19: Design Model  Lecture p6 T120B029 200 4  pavasario sem

19

Operations vs. Responsibilities

• Conceptual: Operations should specify responsibilities, not IF, e.g.:– The Customer specifies the Orders– The Orders list the Customer

*1

OrderdateReceived

isPrepaid

number : String

price : Money

Responsibilities- lists the customer

Customernameaddress

Responsibilities- specifies orders

T120B029

Page 20: Design Model  Lecture p6 T120B029 200 4  pavasario sem

20

Relationships

connections between classes• dependency• generalization• association

T120B029

Page 21: Design Model  Lecture p6 T120B029 200 4  pavasario sem

21

Associations (1)• Associations correspond to verbs, as classes

correspond to nouns • Class A and class B are associated if

– An object of class A sends a message to an object of class B

– An object of class A creates an object of class B – An object of class A has an attribute whose vales are

objects of or collections of objects of class B – An object of class A receives a message with an object

of class B as an argument

T120B029

Page 22: Design Model  Lecture p6 T120B029 200 4  pavasario sem

22

Association(2)

An association is a structural relationship within which classes or objects are connected to each other. (An association between objects is called a link.)

CompanyPerson

T120B029

Page 23: Design Model  Lecture p6 T120B029 200 4  pavasario sem

23

Association Classes

An association class has properties of both an association and a class.

CompanyPerson

JobdescriptiondateHired

salary

T120B029

Page 24: Design Model  Lecture p6 T120B029 200 4  pavasario sem

24

Association Adornments

• name• role• multiplicity• aggregation• composition

T120B029

Page 25: Design Model  Lecture p6 T120B029 200 4  pavasario sem

25

Association Name

describes nature of relationship:

can also show direction to read name:

CompanyPerson works for

CompanyPerson works for

T120B029

Page 26: Design Model  Lecture p6 T120B029 200 4  pavasario sem

26

Association Roles(1)

• describe “faces” that classes present to each other within association

• class can play same or different roles within different associations

CompanyPersonemployee

employer

T120B029

Page 27: Design Model  Lecture p6 T120B029 200 4  pavasario sem

27

Association Roles(2) • Roles clarify participation of each

class in association

T120B029

Page 28: Design Model  Lecture p6 T120B029 200 4  pavasario sem

28

Association Multiplicity(1)

• possible values same as for classes: explicit value, range, or * for “many”

• Example: a Person is employed by one Company; a Company employs one or more Persons

CompanyPerson1..*

1

T120B029

Page 29: Design Model  Lecture p6 T120B029 200 4  pavasario sem

29

• Multiplicity of an association: – An exact number – A range of numbers– An arbitrary, unspecified number (*)

T120B029

Association Multiplicity(2)

Page 30: Design Model  Lecture p6 T120B029 200 4  pavasario sem

30

Generalization and Specialization

• Generalization relationship between two classes indicates that one class in more specific than the other in representing similar objects How to check whether generalization exists: “every Instructor is a Person”

• Inheritance is a way to implement generalization

T120B029

Page 31: Design Model  Lecture p6 T120B029 200 4  pavasario sem

31

Generalization

A generalization is a “kind of” or “is a” relationship between a general thing (superclass or parent) and a more specific thing (subclass or child).

Shape

RectangleCircle

T120B029

Page 32: Design Model  Lecture p6 T120B029 200 4  pavasario sem

32

DependencyA dependency is a “using” relationship within which the change in the specification of one class may affect another class that uses it.Example: one class uses another in operation

Window

handleEvent()

Event

T120B029

Page 33: Design Model  Lecture p6 T120B029 200 4  pavasario sem

33

Aggregation and Composition

• Aggregation: an object of one class is a part of another class

• Composition: a strong form of aggregation – an object of one class is owned by an object of another class

T120B029

Page 34: Design Model  Lecture p6 T120B029 200 4  pavasario sem

34

Aggregation

Aggregation is a “whole/part” or “has a” relationship within which one class represents a larger thing that consists of smaller things.

Department

Company

T120B029

Page 35: Design Model  Lecture p6 T120B029 200 4  pavasario sem

35

Composition

Composition is a special form of aggregation within which the parts are inseparable from the whole.

Frame

Window

T120B029

Page 36: Design Model  Lecture p6 T120B029 200 4  pavasario sem

36

RealizationA realization is a relationship between an interface and the class that provides the interface’s services.

A class may realize many interfaces.

Observer

TargetTracker«interface»Observer

update()

T120B029

Page 37: Design Model  Lecture p6 T120B029 200 4  pavasario sem

37

T120B029

Page 38: Design Model  Lecture p6 T120B029 200 4  pavasario sem

38

An interface is a named collection of operations used to specify a service of a class without dictating its implementation.

Observer

«interface»Observer

update()

T120B029

Interfaces in UML (1)

Page 39: Design Model  Lecture p6 T120B029 200 4  pavasario sem

39

• An interface specifies some operations of a model element (a class) that are visible outside of a class

• An interface class cannot have any attributes

T120B029

Interfaces in UML (2)

Page 40: Design Model  Lecture p6 T120B029 200 4  pavasario sem

40

Interfaces in UML (3)• Stereotype <<interface>>

InputStream{abstract}

OrderReader

DataInputStream Realization

DependencyGeneralization

<<interface>>

DataInput

close()

T120B029

Page 41: Design Model  Lecture p6 T120B029 200 4  pavasario sem

41

Interfaces in UML (4)

OrderReader

DataInputStream Dependency

DataInput

Interface

Lollipops (“short-hand notation”)

T120B029

Page 42: Design Model  Lecture p6 T120B029 200 4  pavasario sem

42

Interface RelationshipsAn interface may participate in generalization, association, and dependency relationships.

Observer

Tracker

PeriodicObserver

Observation

T120B029