Class Diagram

CONCEPTUAL DESIGN: UML CLASS DIAGRAM RELATIONSHIPS : 

214 CONCEPTUAL DESIGN: UML CLASS DIAGRAM RELATIONSHIPS

Slide 2: 

215 Identify the information system’s purpose Identify the information system’s actors and features Identify Use Cases and create a Use Case Diagram Identify Objects and their Classes and create a Class Diagram Create Interaction/Scenario Diagrams Create Detail Logic for Operations Repeat activities 1-6 as required to refine the “blueprints” A Simplified Object-Oriented Systems Analysis & Conceptual Design Methodology Activities

Slide 3: 

216 Objects have three responsibilities: What they know about themselves – (e.g., Attributes) What they do – (e.g., Operations) What they know about other objects – (e.g., Relationships) Objects

Slide 4: 

217 Defining Class A CLASS is a template (specification, blueprint) for a collection of objects that share a common set of attributes and operations. HealthClubMember Class Objects attributes operations

Slide 5: 

218 UML Class Diagram Notation Class 1 of 2

UML Class Diagram Notation : 

219 UML Class Diagram Notation

Analysis Classes : 

220 Analysis Classes A technique for finding analysis classes which uses three different perspectives of the system: The boundary between the system and its actors The information the system uses The control logic of the system

Boundary Classes : 

221 Boundary Classes coordinating the actor's behavior with the "internals" of the system; receiving input from the actor to the system, e.g., information or requests; providing output from the system to the actor, e.g., stored information or derived results.

Boundary Classes : 

222 Boundary Classes Boundary classes are used to model the interaction between a system and its surroundings, i.e., its actors. User interface classes Concentrate on what information is presented to the user Don’t concentrate on user interface details Example: ReportDetailsForm ConfirmationDialog System / Device interface classes Concentrate on what protocols must be defined. Don’t concentrate on how the protocols are implemented

Entity Classes : 

223 Entity Classes Models the key concepts of the system Usually models information that is persistent Contains the logic that solves the system problem Can be used in multiple behaviors Example: Violation, Report, Offender.

Control Classes : 

224 Control Classes Controls and coordinates the behavior of the system Delegates the work to other classes A control class should tell other classes to do something and should never do anything except for directing Control classes decouple boundary and entity classes Example: EditReportController AddViolationController

Class Diagram Relationships : 

225 Class Diagram Relationships Class Generalization Object Association Aggregation Composition

Slide 13: 

226 Class Generalization Relationship 2 of 2 Will always be “1”

Generalization (Class-to-Class) (superclass – subclass; supertype – subtype) : 

227 Generalization (Class-to-Class) (superclass – subclass; supertype – subtype) A Generalization follows a “is a” or “is a kind of” heuristic from a specialization class to the generalization class. (e.g., student “is a” person, video “is a kind of” inventory). Common attributes, operations and relationships are located in the generalization class and are inherited by the specialization classes Unique attributes, operations and relationships are located in the specialization classes. Inherited attributes and operations may be overridden or enhanced in the specialization class depending on programming language support. Inherited operations in the specialization classes may be polymorphic. Only use when objects do NOT “transmute” (add, copy, delete) Multiple inheritance is allowed in the UML but can complicate the class model’s understanding and implementation (e.g., C++ supports but Java and Smalltalk do not).

Slide 15: 

228 <<abstract>> Role attributes operations Generalization Example Faculty attributes operations Student attributes operations Staff attributes operations Visitor attributes operations Note: <<abstract>> = no objects Others: Transactions Things Places Etc...

Slide 16: 

229 Person attributes operations Poor Generalization Example (violates the “is a” or “is a kind of” heuristic) Arm attributes operations Leg attributes operations Head attributes operations

Slide 17: 

230 Generalization Inheritance Generalization a1 a2 a3 o1 o2 o3 Specialization a4 a5 a6 o4 o5 o6 One-Way Inheritance from the Generalization to the Specialization Specialization a1 a2 a3 a4 a5 a6 o1 o2 o3 o4 o5 o6 (a = attribute; o = operation) Common Unique Generalization a1 a2 a3 o1 o2 o3

Slide 18: 

231 Generalization - Multiple Inheritance Generalization1 a1 a2 a3 o3 o4 o5 Specialization a6 a7 a8 o6 o7 o8 Generalization2 a2 a4 a5 o1 o2 o3 inherited attributes a1 a2 (which one?) a3 a4 a5 inherited operations o1 o2 o3 o4 o5 (which one?)

Slide 19: 

232 UML Generalization Notation Supertype Subtype 2 Subtype 1 discriminator Useful text Note Note: Supertype = Superclass; Subtype = Subclass

Slide 20: 

233

Slide 21: 

234 Generalization - Multiple Classification <<abstract>> Person Female Male Physical- therapist Nurse Doctor role Patient patient Gender {complete} Discriminator #1 #2 #3

Example : 

235 Example

Slide 23: 

236 Rational Rose Class Diagram Example

Slide 24: 

237 Associations Relationships between instances (objects) of classes Conceptual: associations can have two roles (bi-directional): source --> target target --> source roles have multiplicity (e.g., cardinality, constraints) To restrict navigation to one direction only, an arrowhead is used to indicate the navigation direction No inheritance as in generalizations

Slide 25: 

238 x x x x x x 1 y 1 y 1 y x x x x Object Association Relationship Patterns a) Object Associations b) Object Aggregation Associations c) Object Composition Associations (y may not be “1”)

Slide 26: 

239 Associations Class A Class B role A role B Company Person Employer Employee Example:

Slide 27: 

240 Multiplicities Class Class Class Class 1 0..* 0..1 m..n exactly one many (zero or more) optional (zero or one) numerically specified Course CourseOffering 1 0..* Example:

Examples : 

241 Examples

Aggregation & Composition : 

242 Aggregation & Composition Aggregation (shared aggregation): is a specialized form of ASSOCIATION in which a whole is related to its part(s). is known as a “part of” or containment relationship and follows the “has a” heuristic three ways to think about aggregations: whole-parts container-contents group-members Composition (composite aggregation): is a stronger version of AGGREGATION the “part(s)” may belong to only ONE whole the part(s) are usually expected to “live” and “die” with the whole (“cascading delete”) Aggregation vs. Composition vs. Association???

Slide 30: 

243 Aggregation Composition 0..* 1..* Faculty CourseTeaching 1..* 1 SalesOrder SalesOrderLineItem (another: hand --> finger) (another: assembly --> part) (team-teaching is possible)

Slide 31: 

244 Composition Person {abstract} Faculty Student FacultyStudent Person Note: Attributes may need to be considered to more-fully understand FacultyRole StudentRole 1 1 0..1 0..1 Composition is often used in place of Generalization (inheritance) to avoid “transmuting” (adding, copying, and deleting of objects)

Example : 

245 Example

Slide 33: 

246 Association, Aggregation and Composition Whole Part Whole Part 0..* 0..* w 1 w 2 w 3 w 4 p 6 p 4 p 5 p 3 p 1 p 2 Template/Pattern Example (association, aggregation & composition look the same)

Slide 34: 

247 Whole 5 1 2 3 Multiplicity Example #1 One Whole is associated with 5 Part1 One Part1 is associated with 1 Whole W P W P P W P W W One Whole is associated with 2 PartN One PartN is associated with 3 Whole Part1 PartN

Slide 35: 

248 Multiplicity Example #2 1..n 1 0..* 2..5 C1 C2 C2 C2 C2 C2 etc... min. max. C1 C3 C3 C3 C3 C3 etc... C3 C1 C1 C1 C1 C1 1..n * 2..5 Class1 Class2 Class3 C2 C1 1

Slide 36: 

249 FacultyInformation 1 0..* 1 1 1 1..* 0..* 0..* 0..* Multiplicity Example #3 StudentInformation DegreeHeld CommitteeAssign CourseTeach ClubMember CourseCompleted 0..*

Slide 37: 

250 Reflexive Association Relationships Objects within the same class have a relationship with each other. Course 0..* 0..* has pre-requisite of is pre-requisite for

Case study—Courseware Management SystemProblem Statement : 

251 Case study—Courseware Management SystemProblem Statement Courses and Topics that make up a course Tutors who teach courses Course administrators who mange the assignment of the courses to tutors Calendar or Course Schedule is generated as a result of the Students who refer to the Course schedule or Calendar to decide which courses for which they wish to sign up

The potential actors of the system : 

252 The potential actors of the system Tutors Course administrators Students

use cases of the system were: : 

253 use cases of the system were: View courses Manage topics for a course Manage course information View course calendar View tutors Manage tutor information Assign courses to tutors

First Identify the "active" entities in the system : 

254 First Identify the "active" entities in the system Course administrators Tutors Students

Identify business domain ("passive") entities in the system : 

255 Identify business domain ("passive") entities in the system Courses Topics that make up a course Course calendar generated

Identify : 

256 Identify Boundary class - Course Administrator

Next : 

257 Next Identify Attributes and methods for the class. Refine

Then : 

258 Then Identify relationship between the classes.

Class Diagram : 

259 Class Diagram

UML Class Diagram : 

260 UML Class Diagram

Slide 48: 

261 Inventory Video Store – UML Class Diagram SaleItem RentalItem Video Game ConcessionItem VCR Transaction Employee StoreLocation SaleTransaction RentalTransaction Suplier Member PurchaseOrder SaleRentalLineItem PurchaseOrderLineItem 1 0..* 0..* 0..1 1 0..* 1..* 1 1 1..* 1 0..* 1 0..* 1 1..* 1 0..* 0..* 1

Slide 49: 

262

Slide 50: 

263

Slide 51: 

264

Slide 52: 

265 QUITTING TIME