Scribd
Upload
110 views

Class Diagram

The document discusses class diagrams and how to identify classes, attributes, associations, and other elements of class diagrams. It provides guidance on how to analyze problems and requirements to identify relevant classes and relationships between classes.

Uploaded by

Muhammad Anwaar
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
110 views

Class Diagram

The document discusses class diagrams and how to identify classes, attributes, associations, and other elements of class diagrams. It provides guidance on how to analyze problems and requirements to identify relevant classes and relationships between classes.

Uploaded by

Muhammad Anwaar
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 24

LECTURE Class Diagram

Waris Ali

Class Diagrams

A class diagram shows:


Classes
Attributes Methods

Interfaces
Collaborations Dependency,

Generalization, Relationships

A class diagram is a STATIC view of system

Basic Class Diagrams


Class Name Class Attributes

Class Methods

Basic Class Diagrams


+ # / $ public protected private derived static

Abstract <<abstract>>
<<constructor>> <<query>> <<update>>

Class Scope Variable

Visibility Attribute Name [Multiplicity]:Type = Initial Value

Visibility Method Name (Parameter List) : Return-List

Basic Class Diagrams


Superclass Class with parts

Note

Subclass

Assembly Class

name

Inheritance (Generalization) (is-a, kind-of)

Composition (Part-Of)

Association (relationship)

Basic Class Diagram (Example)


Brain Person

Money Student takes

Class

Basic Class Diagram (Example)


Person + name : String - ssn : String # birthday : Date / age : int

+getName : String -calculateAge : int

Class Diagrams (Advanced)


Cardinality (Multiplicity) 1 0..1 0..n 1..n * Student takes
0..n

Class

Class Diagrams (Advanced)


Library
Book

Checks Out Association Class

Class Diagram Hints


Provide abstraction of problem domain Embodies small set of well-defined responsibilities Clear separation between specification and implementation Understandable and simple Show only important properties

Class Hints

Organize similar classes into packages Beware of cyclical generalization Use associations where there are structural relationships Associations are NOT comm pipes!!!!!!! Start with Analysis, then refine details

Identifying Associations

Association Relationship between two or more classes One-to-many association An example of association between the EmergencyReport and the FieldOfficer classes.
EmergencyReport writes *

FieldOfficer 1

author

document

Identifying Aggregation

Models "part of" hierarchy Useful for modeling the breakdown of a product into its component parts UML notation: uses a small diamond to indicate the assembly end of the relationship.

Identifying Aggregation
Engine 1 horsepower volume on off

Automobile serial number year manufacturer model color weight drive purchase
* Brakelight on off 2,4 Door open close 1 Battery amps volts charge discharge

3,4,5
Wheel diameter number of bolts

Identifying Aggregation

Aggregation

Special types of associations; whole-part relationship

Composition Aggregation
Existence

of the parts depends on the whole

Shared Aggregation
State FireStation

County FireFighter FireEngine Township LeadCar Ambulance

Identifying Attribute

Attributes Proprieties of individual objects Attributes


Name A brief description Type; legal values

EmergencyReport emergencyType:{fire,traffic,other} location:String description:String

Class Diagram
Main goal: Find the important abstractions What happens if we find the wrong abstractions?

Iterate and correct the model

Steps
1. Class identification Based on the fundamental assumption that we can find abstractions 2. Find the attributes 3. Find the methods 4. Find the associations between classes

Pieces

Classes Associations (Relations)


Part of- Hierarchy (Aggregation) Kind of-Hierarchy (Generalization)

Attributes

Detection of attributes Application specific Attributes in one system can be classes in another system Turning attributes to classes Detection of operations Generic operations: Get/Set, General world knowledge, design patterns Domain operations: Dynamic model, Functional model

Operations

How to find classes?

Finding Classes is the main theme


Learn about problem domain: Observe your client Apply general world knowledge and intuition Take the flow of events and find participating objects in use cases Try to establish a taxonomy Do a syntactic analysis of problem statement, scenario or flow of events Abbott Textual Analysis, 1983, also called noun-verb analysis Nouns are good candidates for classes Verbs are good candidates for operations

Example

Ahmad enters a store with the intention of buying a toy for his 6 year old child. He has to buy a toy which her daughter likes. The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. Ahmad selects a toy which is unsuitable for the child. The store owner recommends a safer doll. Note: Help must be available within less than one minute.

Abbots Heuristics
Part of speech Proper noun Improper noun Doing verb being verb having verb modal verb adjective transitive verb intransitive verb Model component object class method inheritance aggregation constraint attribute method method (event) Example
Ahmad

Toy, doll Buy, recommend is-a (kind-of) has an must be 6 years old enter depends on

Class-diagrams have different types of users

According to the development activity, the developer plays different roles.


Analyst System-Designer, DetailedDesigner Implementor.

In small systems some of the roles do not exist or are played by the same person. Each of these roles has a different view about the models. Types of classes that appear in class diagrams.

Application domain classes Solution domain classes

Requirements Analysis Document Template

1. Introduction 2. Current system 3. Proposed system 3.1 Overview 3.2 Functional requirements 3.3 Nonfunctional requirements 3.4 Constraints (Pseudo requirements) 3.5 System models 3.5.1 Scenarios 3.5.2 Use case model 3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams 3.5.4 User interface 4. Glossary

24

QUESTIONS ?

You might also like