1 / 51

SYSC 3100 System Analysis and Design

SYSC 3100 System Analysis and Design. Class Diagrams Advanced Features & Guidelines . Associations. Refining the semantics of an association using:. Basic features A name Multiplicities A role A navigation Aggregation and composition adornments. Advanced features

maxima
Download Presentation

SYSC 3100 System Analysis and Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. * * 1 * UserGroup User Password + user - key Visibility for association • Want to limit the visibility across an association for objects outside the association? (similar to attribute visibility) • Example: • 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 UserGroup object, you can navigate to its User objects (and vice versa), but you cannot in turn see the User object’s Password objects SYSC3100 - System Analysis and Design

  4. 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 SYSC3100 - System Analysis and Design

  5. 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 seat-no: Int Mission Catalog Part part_no SYSC3100 - System Analysis and Design

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

  7. SimulationRun Scenario simname Scenario -runs:Hashtable -scenarios:Vector +elements() +elements() +addRun(simname,sr:SimulationRun) +addScenario(s:Scenario) +removeRun(simname,sr:SimulationRun) +removeScenario(s:Scenario) Implementation in Java * 0..1 SimulationRun SYSC3100 - System Analysis and Design

  8. worker: IEmployee * Person 1 supervisor: IManager 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 SYSC3100 - System Analysis and Design

  9. Astronaut_has seat_on_mission Mission Seat ternary association Astronaut 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) SYSC3100 - System Analysis and Design

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

  11. 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 SYSC3100 - System Analysis and Design

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

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

  14. 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 SYSC3100 - System Analysis and Design

  15. 0..* 1..* asso InsuranceContract Customer ParentClassA ParentClassB {ordered} 1 4..7 working_on Mission Astronaut {xor} vacationing_in 1 {implicit} asso ChildA ChildB Country * Constraints SYSC3100 - System Analysis and Design

  16. {subset} partyLeaderOf 1 1 memberOf 1..* 1 Constraints subset when two associations exist between the same two class, one association may be a subset of the other. Politician Party SYSC3100 - System Analysis and Design

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

  18. Example of a genealogy system Person • 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 name sex placeOfBirth dateOfBirth placeOfDeath dateOfDeath {husband.sex = #male} placeOfMarriage child husband dateOfMarriage 0..1 * dateOfDivorce parents 0..1 wife 2 {parent->forAll(p1,p2: {wife.sex = #female} p1 <> p2 implies p1.sex <> p2.sex)} SYSC3100 - System Analysis and Design

  19. Person name placeOfBirth dateOfBirth child placeOfDeath * dateOfDeath Woman Man femalePartner 0..1 * * * * 0..1 malePartner child child * * Union 0..2 placeOfMarriage parents dateOfMarriage dateOfDivorce 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 SYSC3100 - System Analysis and Design

  20. Class Diagram • A class diagram is a diagram that shows a set of classes and interfacesand 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) SYSC3100 - System Analysis and Design

  21. Company Person 1 1..* 1..* * name: String title: String getPhoto(): Photo getContractInfo() getPersonalRecords() * * 0..1 Department Office member 1..* 1 manager ContractInfo name: Name address: String voice: Number PersonalRecord address: String employmentHistory salary location * * {subset} HeadQuarters ISecureInfo SYSC3100 - System Analysis and Design

  22. 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. SYSC3100 - System Analysis and Design

  23. d2: Department name= “R&D” d1: Department manager : ContactInfo name= “Sales” d3: Department p: Person address: “1472 Miller St.” name= “US Sales” name: “Erin” title= “VP of Sales” c: Company SYSC3100 - System Analysis and Design

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

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

  26. crewMember Astronaut Mission commander 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 SYSC3100 - System Analysis and Design

  27. «enumeration» Boolean false true «enumeration» Status idle working error 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} SYSC3100 - System Analysis and Design

  28. «utility» MathPack randomSeed: long = 0 pi:long = 3.1415 sin (angle : double) : double cos (angle: double) : double random () : double 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 SYSC3100 - System Analysis and Design

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

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

  31. 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 SYSC3100 - System Analysis and Design

  32. 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. SYSC3100 - System Analysis and Design

  33. 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 SYSC3100 - System Analysis and Design

  34. 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 SYSC3100 - System Analysis and Design

  35. Example SYSC3100 - System Analysis and Design

  36. 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 SYSC3100 - System Analysis and Design

  37. 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 SYSC3100 - System Analysis and Design

  38. LibraryPatron LibraryPatron Loan borrowedDate dueDate CollectionItem returnedDate CollectionItem Better: The operation creates a , and Loan borrow the operation sets the return returnedDate attribute. Actions versus associations • A common mistake is to represent actions as if they were associations * * * * * * * borrow return * * * Bad, due to the use of associations that are actions SYSC3100 - System Analysis and Design

  39. 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} SYSC3100 - System Analysis and Design

  40. Aggregation Guidelines • Four semantics possible • ExclusiveOwns (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 SYSC3100 - System Analysis and Design

  41. 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 ExclusiveOwns and Owns aggregations SYSC3100 - System Analysis and Design

  42. Example: University Enrolment Course Student course_code : String student_id : String course_name : String student_name : String credit_points : Integer current_fees : Money has_stud * * takes takes_crsoff 0..* 0..* 0..* 0..* CourseOffering AcademicRecord * * year : Date course_code : String semester : Integer year : Date enrolment_quota : Integer semester : Integer grade : String 0..* 0..* 0..1 0..1 AcademicInCharge SYSC3100 - System Analysis and Design

  43. 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 SYSC3100 - System Analysis and Design

  44. 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 SYSC3100 - System Analysis and Design

  45. Example Class Diagram Employee RegularFlight Passenger * name time name employeeNumber flightNumber number jobFunction supervisor * * * * * * * * * * * * * * * * * * * Booking * * * * * * SpecificFlight seatNumber date SYSC3100 - System Analysis and Design

  46. Example: Generalization It is possible for a person to be both an employee and a passenger. Person 0..2 0..2 0..2 0..2 0..2 0..2 PersonRole name idNumber RegularFlight * EmployeeRole time PassengerRole flightNumber jobFunction supervisor * * * * * * * * * * * * * * * * * * * Booking * * * * * * SpecificFlight seatNumber date SYSC3100 - System Analysis and Design

  47. Another example: Video Store MovieTitle VideoMedium movie_code : String available movie_title : String video_condition : Byte director : String number_currently_available : Integer 1 1 0..* 0..* / is_in_stock : Boolean 1..* 1..* apply 1 1 VideoDisk RentalConditions VideoTape different_languages : Boolean rental_period_in_days : Integer is_taped_over : Boolean rental_charge_per_period : Currency different_endings : Boolean BetaTape VHSTape DVDDisk SYSC3100 - System Analysis and Design

  48. 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 SYSC3100 - System Analysis and Design

  49. 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 SYSC3100 - System Analysis and Design

  50. 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 SYSC3100 - System Analysis and Design

More Related