Design Model Lecture p6 T120B029 200 4 pavasario sem

Preview:

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

Design Model Design Model LectureLecture

p6p6T120B029T120B029

20020044 pavasario sem. 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

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.

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

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

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

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

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

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

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

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

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

13

Class Notation

Name

Attributes

Operations

T120B029

14

Alternative Class Notations

Name

Attributes

Operations

Responsibilities

Name

Attributes

OperationsName

italics abstract

T120B029

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

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

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

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

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

20

Relationships

connections between classes• dependency• generalization• association

T120B029

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

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

23

Association Classes

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

CompanyPerson

JobdescriptiondateHired

salary

T120B029

24

Association Adornments

• name• role• multiplicity• aggregation• composition

T120B029

25

Association Name

describes nature of relationship:

can also show direction to read name:

CompanyPerson works for

CompanyPerson works for

T120B029

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

27

Association Roles(2) • Roles clarify participation of each

class in association

T120B029

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

29

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

T120B029

Association Multiplicity(2)

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

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

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

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

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

35

Composition

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

Frame

Window

T120B029

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

37

T120B029

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)

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)

40

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

InputStream{abstract}

OrderReader

DataInputStream Realization

DependencyGeneralization

<<interface>>

DataInput

close()

T120B029

41

Interfaces in UML (4)

OrderReader

DataInputStream Dependency

DataInput

Interface

Lollipops (“short-hand notation”)

T120B029

42

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

Observer

Tracker

PeriodicObserver

Observation

T120B029

Recommended