SYSC 3100 System Analysis and Design Class Diagrams

SYSC 3100 System Analysis and Design Class Diagrams Advanced Features & Guidelines SYSC 3100 - System Analysis and Design 1

Associations Refining the semantics of an association using: o o o Basic features A name Multiplicities A role A navigation Aggregation and composition adornments SYSC 3100 - System Analysis and Design o o o Advanced features Association visibilities Qualifications Interface specifier Arity Association classes Constraints 2

Visibility for association • Want to limit the visibility across an association for objects outside the association? (similar to attribute visibility) • Example: User. Group * * + user User 1 * - key Password – Given a User object, it is possible to identify its corresponding Password. – However, a Password is private to a User (unless, of course, the User explicitly exposes access to the Password) – Given a User. Group object, you can navigate to its User objects (and vice versa), but you cannot in turn see the User object’s Password objects SYSC 3100 - System Analysis and Design 3

Qualifiers • Qualifier: an association attribute whose values partition the set of objects (called the targets) related to a given object (called the source) across an association • The qualifier (drawn in a rectangle) is attached to the source class of an association and determines how objects on the target side of an association are partitioned and identified. – An object of the source class, together with the values of the qualifier, uniquely selects a partition of the target class • A qualifier is composed of attributes of the source/target object SYSC 3100 - System Analysis and Design 4

Qualifier • A qualifier: – Must have a name – May have a multiplicity expression within square brackets that indicates the number of attribute values per instance of the association (the default is 1) – May have a colon followed by a type expression Astronaut Part SYSC 3100 - System Analysis and Design seat-no: Int Mission part_no Catalog 5

Qualifiers & Multiplicity • A qualifier reduces the multiplicity of an association • A board is made of 9 squares – Solution without qualifier Board 1 9 Square – Solution with qualifiers Board row: {1, 2, 3} column: {1, 2, 3} SYSC 3100 - System Analysis and Design 1 1 Square 6

Implementation in Java Scenario simname Scenario -runs: Hashtable +elements() +add. Run(simname, sr: Simulation. Run) +remove. Run(simname, sr: Simulation. Run) SYSC 3100 - System Analysis and Design * 0. . 1 Simulation. Run -scenarios: Vector +elements() +add. Scenario(s: Scenario) +remove. Scenario(s: Scenario) 7

Interface specifier • The role of the class in an association is refined (specified) by an interface name • Example: the self association with class Person and the two roles worker and supervisor – A Person in the role of supervisor presents only the IManager face to the worker – A Person in the role of worker presents only the IEmployee face to the supervisor worker: IEmployee * Person SYSC 3100 - System Analysis and Design 1 supervisor: IManager 8

Association arity • Arity: the number of classes that are involved (connected) in an association • Associations may be binary, ternary, or higher order • Ternary or higher order associations are fairly rare. – And they can be transformed into a set of binary associations (but loss of information) Mission Astronaut_has seat_on_mission ternary association SYSC 3100 - System Analysis and Design Seat Astronaut 9

Meaning of Ternary Associations Mission Astronaut_has_Job on_Mission * Job * Astronaut_has_Job_on_Mission Chapman STS-65 pilot Chapman STS-68 pilot Barker STS-65 commander Barker STS-69 m_specialist Murray STS-69 m_specialist SYSC 3100 - System Analysis and Design an astronaut can only do one job on a mission triplets 10

Association classes • Association class: – In an association between two classes, the association itself may have properties (attributes, operations) – These properties do not belong to any of the classes of the association, but to the pair • An association class is just like another class. It may have: – Attributes – Operations – Relationships with other classes SYSC 3100 - System Analysis and Design 11

Association Classes Person employer * 0. . 1 Company Employment period Astronaut flew-on 0. . * 4. . 6 Medical. Report times-sick performance 0. . * SYSC 3100 - System Analysis and Design Mission stores Database 12

Association Classes • Promoting an association class to a full class Person employer * 0. . 1 Company Employment period Person 1 0. . 1 SYSC 3100 - System Analysis and Design Employment period * 1 Company 13

Constraints • Constraints that may be applied to associations: implicit specifies that the relationship is not manifest but, rather, is only conceptual ordered specifies that the set of objects at one end of the association are in an explicit order xor specifies that, over a set of associations, exactly one is manifest for each associated objects SYSC 3100 - System Analysis and Design 14

Constraints asso Parent. Class. A Child. A {implicit} Parent. Class. B asso Insurance. Contract 0. . * Child. B 1. . * {ordered} 4. . 7 Astronaut {xor} * SYSC 3100 - System Analysis and Design working_on 1 vacationing_in 1 Customer Mission Country 15

Constraints subset when two associations exist between the same two class, one association may be a subset of the other. 1. . * member. Of 1 {subset} Politician 1 SYSC 3100 - System Analysis and Design party. Leader. Of Party 1 16

Constraints changeable addonly frozen links between objects may be added, removed, and changed freely (default) new links may be added from an object on the opposite end of the association a link, once added from an object on the opposite end of the association, may not be modified or deleted SYSC 3100 - System Analysis and Design 17

Example of a genealogy system Person name sex place. Of. Birth date. Of. Birth place. Of. Death date. Of. Death {husband. sex = #male} place. Of. Marriage husband date. Of. Marriage child 0. . 1 date. Of. Divorce * 0. . 1 wife parents 2 {wife. sex = #female} {parent->for. All(p 1, p 2: p 1 <> p 2 implies p 1. sex <> p 2. sex)} – Issues • A person must have two known parents? • A person may have multiple marriages and children with several different partners over the course of his/her life SYSC 3100 - System Analysis and Design 18

Genealogy example: Possible solution • A person is not required to have two parents known in the system • The partner role allows for only zero or one partner to be known Person name place. Of. Birth date. Of. Birth place. Of. Death child date. Of. Death * Woman Man female. Partner 0. . 1 * 0. . 1 childmale. Partner * * Union 0. . 2 place. Of. Marriage parents date. Of. Marriage date. Of. Divorce SYSC 3100 - System Analysis and Design 19

Class Diagram • A class diagram is a diagram that shows a set of classes and interfaces and their relationships for a system/subsystem. • Graphically, a class diagram is a collection of vertices and arcs. – Classes (name, attributes, operations, multiplicities, constraints, …) – Interfaces – Relationships (dependencies, generalization, association, realization) SYSC 3100 - System Analysis and Design 20

Company 1 1. . * * 0. . 1 Department name: Name location * 1. . * Office address: String * voice: Number * * {subset} member 1. . * 1 manager Person name: String title: String get. Photo(): Photo get. Contract. Info() get. Personal. Records() SYSC 3100 - System Analysis and Design Contract. Info address: String Personal. Record employment. History salary Head. Quarters ISecure. Info 21

Object Diagram • An object diagram is a diagram that shows a set of objects and their relationships at a point in time (snapshot). • Graphically, an object diagram is a collection of vertices and arcs. – Objects – Links: paths along which an object can dispatch a message (operation call) to another object. SYSC 3100 - System Analysis and Design 22

c: Company d 1: Department name= “Sales” d 2: Department name= “R&D” d 3: Department name= “US Sales” manager p: Person name: “Erin” title= “VP of Sales” SYSC 3100 - System Analysis and Design : Contact. Info address: “ 1472 Miller St. ” 23

General considerations • Using role names in practice • Choosing the type of associations (plain associations, aggregation, composition) • Modeling primitive types and utility classes SYSC 3100 - System Analysis and Design 24

Use of roles • Role names are necessary to accommodate links between objects of the same class (self-association). Astronaut commander name sin# 1 address leads * 4. . 6 assigned-to crew. Member commandee * Mission number cost Seat seat# Performance perf. Rating SYSC 3100 - System Analysis and Design 25

Use of roles • Roles are also useful to distinguish different associations between the same pair of classes. • Multiple associations: – Does not mean that the same objects have to be linked twice crew. Member Astronaut Mission commander SYSC 3100 - System Analysis and Design 26

Modeling primitive types • Primitive types are modeled as classes with specific stereotypes: <<datatype>> and <<enumeration>> «datatype» Int {values range from -2^31 to +2^31 -1} «enumeration» Boolean false true «enumeration» Status idle working error SYSC 3100 - System Analysis and Design 27

Modeling Class Utilities • Represent a group of global attributes and operations • Cannot be instantiated to create objects • Depicted as a class with the <<utility>> stereotype «utility» Math. Pack random. Seed: long = 0 pi: long = 3. 1415 sin (angle : double) : double cos (angle: double) : double random () : double SYSC 3100 - System Analysis and Design 28

Aggregation and Generalization • It is sometime difficult to choose between a generalization relationship and an aggregation (or composition) Aircraft Radar Aircraft Awacs 1. . * Radar SYSC 3100 - System Analysis and Design 29

Attribute Misuse • Associations should not be modeled by the correspondence of attributes Astronaut Mission assigned_to : string Astronaut Assigned_to SYSC 3100 - System Analysis and Design WRONG full_name : string Mission full_name : string RIGHT 30

Analysis model vs Design model – The Analysis model omits many classes that are needed to build a complete system • Domain model • Can contain less than half the classes of the system. • Should be developed to be used independently of particular sets of – user interface classes – architectural classes (e. g. , design patterns classes) – The complete Design model includes • The system domain model • User interface classes • Architectural classes (e. g. , needed for classes to communicate) • Utility classes SYSC 3100 - System Analysis and Design 31

Suggested sequence of activities • Identify a first set of candidate classes • Add associations and attributes • Find generalizations • List the main responsibilities of each class • Decide on specific operations • Iterate over the entire process until the model is satisfactory – Add or delete classes, associations, attributes, generalizations, or operations – Identify interfaces – Apply design patterns Don’t be too disorganized. Don’t be too rigid either. SYSC 3100 - System Analysis and Design 32

Guidelines for Class Identification • Specific occurrences of a general type – People (‘Jon Doe’), organizations, organization units • Structures inherent to the problem domain – Volunteer team, car sharer • Abstractions such as people and roles, physical artifacts, concepts – ‘Insurance sales advisor’ – ‘car’, ‘insurance policy’ – ‘sale’, ‘skill’ • Enduring relationships between other identified classes – ‘agreement’, ‘registration’ • During design: class needed to solve a particular design problem SYSC 3100 - System Analysis and Design 33

A simple technique for discovering domain classes – Look at a source material such as a description of requirements (use case descriptions) – Extract the nouns and noun phrases – Eliminate nouns that: • are redundant • represent instances • are vague or highly general • not needed in the application – Pay attention to classes in a domain model that represent types of users or other actors SYSC 3100 - System Analysis and Design 34

Example Use case name Assign staff to work on a campaign Actor Campaign Manager Pre-condition 1. Displays list of client names Flow of events 2. 3. 4. 5. 6. Selects the client name Lists the titles of all campaigns for the that client Selects the relevant campaign Displays list of staff members not already allocated to this campaign Highlights the staff members to be assigned to the campaign Post-condition 7. Special requirement None (at this level of refinement) Presents a message confirming that staff have been allocated to campaign SYSC 3100 - System Analysis and Design 35

Identifying associations and attributes • Start with classes you think are most central and important • Decide on the clear and obvious data it must contain (attributes) and its relationships to other classes. • Work outwards towards the classes that are less important. • Avoid adding many associations and attributes to a class unless clearly relevant • A system is simpler if it manipulates less information SYSC 3100 - System Analysis and Design 36

Simple Technique for associations • Verb phrases can indicate associations between classes • Example: – ‘customer holds account’ – ‘volunteers hold particular skills’ – ‘car sharers registers journey’ • An association should exist if a class – possesses – controls – is connected to – is related to – is a part of – has as parts – is a member of – has as members SYSC 3100 - System Analysis and Design 37

Actions versus associations – A common mistake is to represent actions as if they were associations Library. Patron * borrow * * Loan return * * Collection. Item Bad, due to the use of associations that are actions SYSC 3100 - System Analysis and Design * borrowed. Date due. Date * returned. Date Library. Patron Collection. Item Better: The borrow operation creates a Loan, and the return operation sets the returned. Date attribute. 38

Identifying attributes – Look for information that must be maintained about each class – Several nouns rejected as classes, may now become attributes – An attribute should generally contain a simple value or enumerations • string, number • {1, 2, 3} SYSC 3100 - System Analysis and Design 39

Aggregation Guidelines • Four semantics possible – Exclusive. Owns (e. g. Book has Chapter) • Existence-dependency • Transitivity • Asymmetricity • Fixed property – Owns (e. g. Car has Tire) • No Fixed property – Has (e. g. Division has Department) • No Existence Dependency property • No Fixed property – Member (e. g. Meeting has Chairperson) • No special properties except membership SYSC 3100 - System Analysis and Design 40

UML Aggregation and Composition • UML supports – Aggregation (conceptual notion, suggests higher coupling) • Hollow diamond • Corresponds to Has and Member aggregations – Composition (coincident lifetime) • Solid diamond • Corresponds to Exclusive. Owns and Owns aggregations SYSC 3100 - System Analysis and Design 41

Example: University Enrolment Course course_code : String course_name : String credit_points : Integer Student student_id : String student_name : String current_fees : Money has_stud * 0. . * Academic. Record course_code : String year : Date semester : Integer grade : String takes_crsoff * 0. . * Course. Offering year : Date semester : Integer enrolment_quota : Integer 0. . * 0. . 1 SYSC 3100 - System Analysis and Design Academic. In. Charge 42

Identifying generalizations and interfaces – There are two ways to identify generalizations: • bottom-up – Group together similar classes creating a new superclass • top-down – Look for more general classes first, specialize them if needed – Create an interface, instead of a superclass if • The classes are very dissimilar except for having a few operations in common • One or more of the classes already have their own superclasses • Different implementations of the same class might be available SYSC 3100 - System Analysis and Design 43

Bottom-up / Top-down Generalization • Bottom-up: Classes that share properties, responsibilities, and collaborations may become apparent. Common properties are generalized into a suitable superclass. – Care should be taken with this approach that generalization is not introduced simply as a means of graphical tidying of a complex diagram • Top-Down: Generalization is introduced as a way to make the design more resilient to change. – The analyst should ensure that the properties, responsibilities, and collaborations of the superclass apply completely to all subclasses SYSC 3100 - System Analysis and Design 44

Example Class Diagram Employee Passenger name employee. Number job. Function name number Regular. Flight * supervisor time flight. Number * * Booking * * seat. Number SYSC 3100 - System Analysis and Design * Specific. Flight date 45

Example: Generalization Person. Role 0. . 2 It is possible for a person to be both an employee and a passenger. Person name id. Number Employee. Role Passenger. Role job. Function Regular. Flight * supervisor time flight. Number * * Booking * * seat. Number SYSC 3100 - System Analysis and Design * Specific. Flight date 46

Another example: Video Store Movie. Title movie_code : String movie_title : String director : String / is_in_stock : Boolean available 1 Video. Medium video_condition : Byte 0. . * number_currently_available : Integer 1. . * apply 1 Rental. Conditions rental_period_in_days : Integer rental_charge_period : Currency Beta. Tape SYSC 3100 - System Analysis and Design Video. Tape is_taped_over : Boolean VHSTape Video. Disk different_languages : Boolean different_endings : Boolean DVDDisk 47

Allocating responsibilities to classes – Each functional requirement must be attributed to one or several classes as operations (responsibilities) • All the responsibilities of a given class should be clearly related • If a class has too many responsibilities, consider splitting it into distinct classes (Single Responsibility Principle) • If a class has no responsibilities attached to it, then it is probably useless • When a responsibility cannot be attributed to any of the existing classes, then a new class should be created – We will better understand how to do that once we go through interaction diagrams SYSC 3100 - System Analysis and Design 48

Single Responsibility Principle • Rectangle has two responsibilities: mathematical model, render the rectangle on a GUI • If a change to Graphical Application causes the rectangle to change (draw), we may need to rebuild, retest, and redeploy Computational Geometry Application • A class should only “have one reason to change” to avoid fragile designs SYSC 3100 - System Analysis and Design 49

Categories of responsibilities – Setting and getting the values of attributes – Creating and initializing new instances – Loading to and saving from persistent storage – Destroying instances – Adding and deleting links of associations – Copying, converting, transforming, transmitting or outputting – Computing numerical results – Navigating and searching – Other specialized work SYSC 3100 - System Analysis and Design 50

Example of responsibilities • Creating a new regular flight Person. Role • Searching for a flight • Modifying attributes of a Passenger. Role flight • Creating a specific flight * • Booking a Booking * passenger seat. Number • Canceling a booking SYSC 3100 - System Analysis and Design 0. . 2 * Person Airline name id. Number * Employee. Role job. Function Regular. Flight * supervisor time flight. Number * * * Specific. Flight date 51