Requirements – advanced use case modelling Chapter 5 1 5.1 More relationships… • We have studied basic use case analysis, but there are relationships that we have still to explore: • • • • Actor generalisation Use case generalisation «include» – between use cases «extend» – between use cases 2 5.2 Actor generalization - example • The Customer and the Sales Agent actors are very similar • They both interact with List products, Order products, Accept payment • Additionally, the Sales Agent Customer interacts with Calculate commission • Our diagram is a mess – can we simplify it? Sales system ListProducts OrderProducts AcceptPayment CalculateCommission SalesAgent 3 5.2 Actor generalisation • If two actors communicate with the same set of use cases in the same way, then we can express this as a generalisation to another (possibly abstract) actor • The descendent actors inherit the roles and relationships to use cases held by the ancestor actor • We can substitute a descendent actor anywhere the ancestor actor is expected. This is the substitutability principle abstract actor Sales system ancestor or parent generalisation ListProducts Purchaser OrderProducts AcceptPayment CalculateCommission Customer SalesAgent descendents or children Use actor generalization when it simplifies the model 4 5.3 Use case generalisation • The ancestor use case must be a more general case of one or more descendant use cases • Child use cases are more specific forms of their parent • They can inherit, add and override features of their parent Sales system Use case generalization semantics Use case element Inherit Add Override Relationship Yes Yes No Extension point Yes Yes No Precondition Yes Yes Yes Postcondition Yes Yes Yes Step in main flow Yes Yes Yes Alternative flow Yes Yes Yes FindProduct Customer FindBook FindCD 5 5.4 «include» • The client use case executes until the point of inclusion: include(SupplierUseCase) Personnel System client stereotype ChangeEmployeeDetails «include» • Control passes to the supplier use case which executes • When the supplier is finished, control passes back to the client use case which finishes execution • Note: • Client use cases are not complete without the included supplier use cases • Supplier use cases may be complete use cases, or they may just specify a fragment of behaviour for inclusion elsewhere «include» ViewEmployeeDetails Manager FindEmployeeDetails «include» DeleteEmployeeDetails supplier dependency relationship When use cases share common behaviour we can factor this out into a separate supplier use case and «include» it in the clients 6 5.4 «include» example Use case: ChangeEmployeeDetails Use case: FindEmployeeDetails ID: 1 ID: 4 Brief description: The Manager changes the employee details. Brief description: The Manager finds the employee details. Primary actors: Manager Seconday actors: None Primary actors: Manager Seconday actors: None Preconditions: 1. The Manager is logged on to the system. Preconditions: 1. The Manager is logged on to the system. Main flow: 1. include( FindEmployeeDetails ). 2. The system displays the employee details. 3. The Manager changes the employee details. … Main flow: 1. The Manager enters the employee's ID. 2. The system finds the employee details. Postconditions: 1. The employee details have been changed. Alternative flows: None. Alternative flows: None. Postconditions: 1. The system has found the employee details. 7 5.5 «extend» • «extend» is a way of adding new behaviour into the base use case by inserting behaviour from one or more extension use cases Library system base use case Return book • The base use case specifies one or more extension points in its flow of events • The extension use case may contain several insertion segments • The «extend» relationship may specify which of the base use case extension points it is extending stereotype «extend» Borrow book Librarian Find book Issue fine dependency relationship extension use case The client use case inserts behaviour into the base use case. The base use case provides extension points, but does not know about the extensions. 8 5.5 Base use case Use case: ReturnBook ID: 9 Brief description: The Librarian returns a borrowed book. base use case Primary actors: Librarian ReturnBook extension points overdueBook Secondary actors: None. Preconditions: 1. The Librarian is logged on to the system. extension point: overdueBook «extend» extension point name IssueFine extension use case extension point Main flow: 1. The Librarian enters the borrower's ID number. 2. The system displays the borrower's details including the list of borrowed books. 3. The Librarian finds the book to be returned in the list of books. extension point: overdueBook 4. The Librarian returns the book. … Postconditions: 1. The book has been returned. Alternative flows: None. • There is an extension point overdueBook just before step 4 of the flow of events • Extension points are not numbered, as they are not part of the flow 9 5.5.1 Extension use case Extension Use case: IssueFine ReturnBook extension points overdueBook ID: 10 Brief description: Segment 1: The Librarian records and prints out a fine. Primary actors: Librarian Secondary actors: None. extension point: overdueBook «extend» the single insertion segment in IssueFine is inserted at the overdueBook insertion point in the ReturnBook use case Segment 1 preconditions: 1. The returned book is overdue. Segment 1 flow: 1. The Librarian enters details of the fine into the system. 2. The system prints out the fine. IssueFine Segment 1 postconditions: 1. The fine has been recorded in the system. 2. The system has printed out the fine. • Extension use cases have one or more insertion segments which are behaviour fragments that will be inserted at the specified extension points in the base use case 10 5.5.2 Multiple insertion points Extension Use case: IssueFine ReturnBook extension points overdueBook payFine extension points: overdueBook, payFine «extend» the first segment in IssueFine is inserted at overdueBook and the second segment at payFine ID: 10 Brief description: Segment 1: The Librarian records and prints out a fine. Segment 2: The Librarian accepts payment for a fine. Primary actors: Librarian Secondary actors: None. Segment 1 preconditions: 1. The returned book is overdue. Segment 1 flow: 1. The Librarian enters details of the fine into the system. 2. The system prints out the fine. IssueFine Segment 1 postconditions: 1. The fine has been recorded in the system. 2. The system has printed out the fine. Segment 2 preconditions: 1. A fine is due from the borrower. • If more than one extension point is specified in the «extend» relationship then the extension use case must have the same number of insertion segments Segment 2 flow: 1. The Librarian accepts payment for the fine from the borrower. 2. The Librarian enters the paid fine in the system. 3. The system prints out a receipt for the paid fine. Segment 2 postconditions: 1. The fine is recorded as paid. 2. The system has printed a receipt for the fine. 11 5.5.3 Conditional extensions ReturnBook extension points overdueBook payFine condition: {first offence} extension points: overdueBook «extend» IssueWarning condition «extend» condition: {!first offence} extension points: overdueBook, payFine IssueFine • We can specify conditions on «extend» relationships • Conditions are Boolean expressions • The insertion is made if and only if the condition evaluates to true 12 5.6 Summary • We have learned about techniques for advanced use case modelling: • • • • Actor generalisation Use case generalisation «include» «extend» • Use advanced features with discretion only where they simplify the model! 13 Analysis - introduction Chapter 6 14 6.2 Analysis - purpose • Produce an Analysis Model of the system’s desired behaviour: • This model should be a statement of what the system does not how it does it– verify, clarify, validate, confirm.. • We can think of the analysis model as a “first-cut” or “high level” design model • It is in the language of the business • Essential requirements and characteristics of the desired system Inception Elaboration Construction Transition • In the Analysis Model we identify: • Analysis classes • Use-case realizations 15 6.3 Analysis – meta-model Chapter 11 • Packages contain UML modelling elements and diagrams (we only show the elements here) • Each element or diagram is owned by exactly one package packages P3 P1 P4 Analysis Model P2 Chapter 8 analysis class Chapter 12 use case realization Analysis Classes– model the key concepts in the business domain Use Case Realizations – illustrate how instances of the analysis classes can interact to realize the systems behavior 16 6.4 Workflow - Analysis • Analysis guidelines: Architectural analysis Architect Use Case Engineer Component Engineer 6.5 • 50 to 100 classes in the analysis model of a moderately complex system • Only include classes which are part of the vocabulary of the problem domain • Don’t worry about classes which define how something is implemented – we will address these in Design • Focus on classes and associations • Don’t worry about class inheritance too much • Keep it simple!!! Analyze a use case Analyze a class Analyze a package 17 18 Nobel Prize Winners – Chemistry 2016 19 Analysis - objects and classes Chapter 7 20 1.9 UML common mechanisms • UML has four common mechanisms that apply consistently throughout the language: • • • • Specifications Adornments Common divisions Extensibility mechanisms 21 1.9.1 Specifications BankAccount icon or modeling element name accountNumber deposit() withdraw() calculateInterest() Deposit semantic backplane Class specification Use case specification Dependency specification • Behind every UML modelling element is a specification which provides a textual statement of the syntax and semantics of that element • These specifications form the semantic backplane of the model 22 1.9.2 Adornments • Every UML modelling element starts with a basic symbol to which can be added a number of adornments specific to that symbol • We only show adornments to increase the clarity of the diagram or to highlight a specific feature of the model Window Window {author = Jim, status = tested} +size : Area=(100,100) #visibility : Boolean = false +defaultSize: Rectangle #maximumSize : Rectangle -xptr : XWindow* +create() +hide() +display( location : Point ) -attachXWindow( xwin : XWindow*) 23 1.9.3 Common divisions • Classifier and instance • A classifier is an abstraction, an instance is a concrete manifestation of that abstraction • The most common form is class/object e.g. a classifier might be a BankAccount class, and an instance might be an object representing my bank account • Generally instances have the same notation as classes, but the instance name is underlined • Interface and implementation • An interface declares a contract and an implementation represents a concrete realization of that contract BankAccount balance getBalance() «instantiate» myAccount:BankAccount balance = 100.0 Borrowable LibraryItem 24 1.9.4 Extensibility mechanisms constraint note { each Ticket has a unique id } «entity» Ticket {version = 1.1} stereotype tagged value id • Stereotypes • A stereotype allows us to define a new UML modelling element based on an existing one • We define the semantics of the stereotype ourselves • Stereotypes add new elements to the UML metamodel • Written as «stereotypeName» • Constraints • Extends the semantics of an element by allowing us to add new rules about the element • Written as { some constraint } • Tagged values are attached to a stereotype • Allows us to add new, ad-hoc information to an element’s specification • Written as { tag1 = value1, tag2 = value2 … } 25 1.9.4.2 Stereotype syntax options stereotype name in guillemets «entity» Ticket stereotype icon Ticket stereotype name and icon stereotyped relationship stereotype preferred icon preferred «entity» Ticket «control» JobManager «call» Scheduler • A stereotype introduces a new modelling element and so we must always define semantics for our stereotypes • Each model element can have many stereotypes 26 1.8.2 Relationships relationship UML syntax brief semantics dependency The source element depends on the target element and may be affected by changes to it. association The description of a set of links between objects. aggregation The target element is a part of the source element. composition A strong (more constrained) form of aggregation. containment The source element contains the target element. generalization The source element is a specialization of the more general target element and may be substituted for it. realization The source element guarantees to carry out the contract specified by the target element 27 7.2 What are objects? • Objects consist of data and function packaged together in a reusable unit. Objects encapsulate data • Every object is an instance of some class which defines the common set of features (attributes and operations) shared by all of its instances. Objects have: • Attribute values – the data part • Operations – the behaviour part • All objects have: • Identity: Each object has its own unique identity and can be accessed by a unique handle • State: This is the actual data values stored in an object at any point in time • Behaviour: The set of operations that an object can perform 28 7.2.1 Encapsulation • Data is hidden inside the object. The only way to access the data is via one of the operations • This is encapsulation or data hiding and it is a very powerful idea. It leads to more robust software and reusable code. operations attribute values deposit() number = "1243" withdraw() owner = "Jim Arlow" balance = 300.00 getOwner() setOwner() An Account Object 29 7.2.2 Messaging • In OO systems, objects send messages to each other over links • These messages cause an object to invoke an operation Bank Object Account Object message withdraw( 150.00 ) the Bank object sends the message “withdraw 150.00” to an Account object. the Account object responds by invoking its withdraw operation. This operation decrements the account balance by 150.00. 30 7.3 UML Object Syntax variants object identifier (must be underlined) object name class name name compartment jimsAccount : Account attribute compartment accountNumber : String = "1234567" owner : String = "Jim Arlow" balance : double = 300.00 attribute name attribute type (N.B. we've omitted the attribute compartment) attribute value object and class name jimsAccount : Account object name only jimsAccount class name only : Account an anonymous object • All objects of a particular class have the same set of operations. They are not shown on the object diagram, they are shown on the class diagram (see later) • Attribute types are often omitted to simplify the diagram • Naming: • object and attribute names in lowerCamelCase • class names in UpperCamelCase 31 7.4 What are classes? • Every object is an instance of one class - the class describes the "type" of the object • Classes allow us to model sets of objects that have the same set of features - a class acts as a template for objects: • The class determines the structure (set of features) of all objects of that class • All objects of a class must have the same set of operations, must have the same attributes, but may have different attribute values • Classification is one of the most important ways we have of organising our view of the world • Think of classes as being like: • Rubber stamps • Cookie cutters class object 32 7.4 Exercise - how many classes? 33 7.4.1 Classes and objects Account • Objects are instances of classes • UML defines instantiation as, “The creation of new instances of model elements” • Most classes provide special operations called constructors to create instances of that class. These operations have class-scope i.e. they belong to the class itself rather than to objects of the class • We will see instantiation used with other modelling elements later on class accountNumber : String owner : String balance : double withdraw() deposit() «instantiate» «instantiate» «instantiate» JimsAccount:Account fabsAccount:Account ilasAccount:Account accountNumber : "801" owner : "Jim" balance : 300.00 accountNumber : "802" owner : "Fab" balance : 1000.00 accountNumber : "803" owner : "Ila" balance : 310.00 objects objects are instances of classes 34 7.5 UML class notation class name name compartment attribute compartment visibility adornment operation compartment tagged values Window {author = Jim, status = tested} +size : Area=(100,100) #visibility : Boolean = false +defaultSize: Rectangle #maximumSize : Rectangle -xptr : XWindow* +create() +hide() +display( location : Point ) -attachXWindow( xwin : XWindow*) initialisation values class scope operation • Classes are named in UpperCamelCase • Use descriptive names that are nouns or noun phrases • Avoid abbreviations! 35 7.5.2 Attribute compartment visibility name : type [multiplicity] = initialValue mandatory • Everything is optional except name • initialValue is the value the attribute gets when objects of the class are instantiated • Attributes are named in lowerCamelCase • Use descriptive names that are nouns or noun phrases • Avoid abbreviations • Attributes may be prefixed with a stereotype and postfixed with a list of tagged values 36 7.5.2.1 Visibility Symbol Name Semantics + public Any element that can access the class can access any of its features with public visibility - private Only operations within the class can access features with private visibility # protected Only operations within the class, or within children of the class, can access features with protected visibility ~ package Any element that is in the same package as the class, or in a nested subpackage, can access any of its features with package visibility PersonDetails -name : String [2..*] -address : String [3] -emailAddress : String [0..1] • You may ignore visibility in analysis • In design, attributes usually have private visibility (encapsulation) 37 7.5.2.3 Multiplicity • Multiplicity allows you to model collections of things • [0..1] means that the attribute may have the value null PersonDetails -name : String [2..*] -address : String [3] -emailAddress : String [0..1] name is composed of 2 or more Strings address is composed of 3 Strings emailAddress is composed of 1 String or null multiplicity expression 38 Operations Compartment • name • parameter list • return type 39 7.5.3 Operation compartment operation signature visibility name( direction parameterName: parameterType = default, …) : returnType parameter list • Operations are named lowerCamelCase • Special symbols and abbreviations are avoided • Operation names are usually a verb or verb phrase there may be a comma delimited list of return types r1, r2,… rn • Operations may have more than one returnType • They can return multiple objects (see next slide) • Operations may be prefixed with a stereotype and postfixed with a list of tagged values 40 7.5.3.1 Parameter direction parameter direction semantics in the parameter is an input to the operation. It is not changed by the operation. This is the default out the parameter serves as a repository for output from the operation inout the parameter is an input to the operation and it may be changed by the operation return the parameter is one of the return values of the operation. An alternative way of specifying return values example of multiple return values: maxMin( in a: int, in b:int, return maxValue:int return minValue:int ) … max, min = maxMin( 5, 10 ) 41 7.6.1 Instance scope vs. class scope • There are two kinds of scope for attributes and operations: instance scope class scope attributes operations By default, attributes have instance scope Attributes may be defined as class scope Every object of the class gets its own copy of the instance scope attributes Every object of the class shares the same, single copy of the class scope attributes Each object may therefore have different instance scope attribute values Each object will therefore have the same class scope attribute values By default, operations have instance scope Operations may be defined as class scope Every invocation of an instance scope operation applies to a specific instance of the class Invocation of a class scope operation does not apply to any specific instance of the class – instead, you can think of class scope operations as applying to the class itself You can’t invoke an instance scope operation unless you have an instance of the class available. You can’t use an instance scope operation of a class to create objects of that class, as you could never create the first object You can invoke a class scope operation even if there is no instance of the class available – this is ideal for object creation operations scope determines access 42 7.6 Scope • There are two kinds of scope for attributes and operations: BankAccount -accountNumber : int -count : int = 0 class scope (underlined) +create( aNumber : int) +getNumber() : int -incrementCount() +getCount() : int instance scope (the default) 43 7.7 Object construction/destruction • How do we create instances of classes? • Each class defines one or more class scope operations which are constructors. These operations create new instances of the class • Destructors are used to destroy objects of a class… BankAccount BankAccount +create( aNumber : int ) +BankAccount( aNumber : int ) generic constructor name Java/C++ standard 44 7.7.1 ClubMember class example • Each ClubMember object has its own copy of the attribute membershipNumber • The numberOfMembers attribute exists only once and is shared by all instances of the ClubMember class • Suppose that in the create operation we increment numberOfMembers: ClubMember -membershipNumber : String -memberName : String -numberOfMembers : int = 0 +create( number : String, name : String ) +getMembershipNumber() : String +getMemberName() : String -incrementNumberOfMembers() +decrementNumberOfMembers() +getNumberOfMembers() : int • What is the value of count when we have created 3 account objects? 45 7.8 Summary • We have looked at objects and classes and examined the relationship between them • We have explored the UML syntax for modelling classes including: • Attributes • Operations • We have seen that scope controls access • Attributes and operations are normally instance scope • We can use class scope operations for constructor and destructors • Class scope attributes are shared by all objects of the class and are useful as counters 46 Analysis - finding analysis classes Chapter 8 47 8.2 Analyse a use case Business model [or domain model] Requirements model Use case engineer Analysis class Analyse a use case Use case model Use case realization Architecture description 48 8.3 What are Analysis classes? • Analysis classes represent a crisp abstraction in the problem domain • They may ultimately be refined into one or more design classes • All classes in the Analysis model should be Analysis classes class name attributes name address balance operations deposit() withdraw() calculateInterest() • Analysis classes have: • A very “high level” set of attributes. They indicate the attributes that the design classes might have. • Operations that specify at a high level the key services that the class must offer. In Design, they will become actual, implementable, operations. BankAccount • Analysis classes must map onto real-world business concepts 49 8.3.2 What makes a good analysis class? • Its name reflects its intent • It is a crisp abstraction that models one specific element of the problem domain • It maps onto a clearly identifiable feature of the problem domain • It has high cohesion • Cohesion is the degree to which a class models a single abstraction • Cohesion is the degree to which the responsibilities of the class are semantically related • It has low coupling • Coupling is the degree to which one class depends on others • Rules of thumb: • • • • • • • 3 to 5 responsibilities per class Each class collaborates with others Beware many very small classes Beware few but very large classes Beware of “functoids” Beware of “omnipotent” classes Avoid deep inheritance trees A responsibility is a contract or obligation of a class - it resolves into operations and attributes 50 8.4 Finding classes • Perform noun/verb analysis on documents: • Nouns are candidate classes • Verbs are candidate responsibilities • Perform CRC card analysis • A brainstorming technique using sticky notes • Useful for brainstorming, Joint Application Development (JAD) and Rapid Application development (RAD) • With both techniques, beware of spurious classes: • Look for synonyms - different words that mean the same • Look for homonyms - the same word meaning different things • Look for "hidden" classes! • Classes that don't appear as nouns or as cards 51 8.4.1 Noun/verb analysis procedure • Collect all of the relevant documentation • • • • Requirements document Use cases Project Glossary Anything else! • Make a list of nouns and noun phrases • These are candidate classes or attributes • Make a list of verbs and verb phrases • These are candidate responsibilities • Tentatively assign attributes and responsibilities to classes 52 8.4.2 CRC card procedure Class Name: BankAccount Responsibilities: things the class does Maintain balance Collaborators: Bank things the class works with • Class, Responsibilities and Collaborators • Separate information collection from information analysis • Part 1: Brainstorm • All ideas are good ideas in CRC analysis • Never argue about something – write it down and analyse it later! • Part 2: Analyse information - consolidate with noun/verb 53 8.4.4 Other sources of classes • Physical objects– car, people, hotels • Paperwork, forms etc. (invoices, orders) • Be careful with this one – if the existing business process is very poor, then the paperwork that supports it might be irrelevant • Known interfaces to the outside world (screens, keyboard, peripherals) • Conceptual entities that form a cohesive abstraction e.g. LoyaltyProgramme (reward card) 54 8.6 Summary • We’ve looked at what constitutes a well-formed analysis class • We have looked at two analysis techniques for finding analysis classes: • Noun verb analysis of use cases, requirements, glossary and other relevant documentation • CRC analysis 55 56 Analysis - relationships Chapter 9 57 9.2 What is a relationship? • A relationship is a connection between modelling elements • In this section we’ll look at: • Links between objects • Associations between classes • aggregation • composition • association classes 58 9.3 Links • Links are connections between objects • Think of a link as a telephone line connecting you and a friend. You can send messages back and forth using this link • Links are the way that objects communicate • Objects send messages to each other via links • Messages invoke operations • OO programming languages implement links as object references or pointers. These are unique handles that refer to specific objects • When an object has a reference to another object, we say that there is a link between the objects 59 9.3.1 Object diagrams • Paths in UML diagrams (lines to you and me!) can be drawn as orthogonal, oblique or curved lines • We can combine paths into a tree if each path has the same properties BookClub role name oblique path style bookClub:Club object link BookClub orthogonal path style bookClub:Club preferred chairperson secretary member chairperson secretary member ila:Person erica:Person naomi:Person ila:Person erica:Person naomi:Person 60 9.4 Associations association Club Person «instantiate» «instantiate» «instantiate» link bookClub:Club links instantiate associations chairman jim:Person • Associations are relationships between classes • Associations between classes indicate that there are links between objects of those classes • A link is an instantiation of an association just as an object is an instantiation of a class 61 9.4.1 Association syntax Company employs 1 association name * multiplicity Person navigability Company employer 1 role names employee * Person • An association can have role names or an association name. It’s bad style to have both. The black triangle indicates the direction in which the • association name is read: “Company employs many Person(s)” 62 9.4.2 Multiplicity A Company employs many People Company employer employee 1 * Person Each Person works for one Company • Multiplicity is a constraint that specifies the number of objects that can participate in a relationship at any point in time • If multiplicity is not explicitly stated in the model then it is undecided – there is no default multiplicity multiplicity syntax: minimum..maximum 0..1 zero or 1 1 exactly 1 0..* zero or more * zero or more 1..* 1 or more 1..6 1 to 6 1..3,7..10,15 1 to 3 OR 7 to 10 OR 15 exactly 63 Multiplicity exercise • How many • • • • • • Employees can a Company have? Employers can a Person have? Owners can a BankAccount have? Operators can a BankAccount have? BankAccounts can a Person have? BankAccounts can a Person operate? Company 1 employer 7 employee Person owner 1 1..* operator 0..* 0..* BankAccount 64 9.4.2.1 Exercise • Model a computer file system. Here are the minimal facts you need: • The basic unit of storage is the file • Files live in directories • Directories can contain other directories • Use your own knowledge of a specific file system (e.g. Windows 95 or UNIX) to build a model Hint: a class can have an association to itself! 65 9.4.2.1 Reflexive associations subdirectory 0..* Directory 1 0..* File 0..1 parent reflexive association autoexec C Windows My Documents config Corel To John Command directories files 66 9.4.2.2 Hierarchies and networks hierarchy network 0..* A 0..* B 0..1 0..* a1:A c1:B b1:B b1:A e1:A c1:A d1:A f1:A e1:B g1:A an an association hierarchy, each object has zero or one object directly above it f1:B d1:B a1:B g1:B in an association network, each object has zero or many objects directly above it 67 9.4.3 Navigability An Order object stores a list of Products • Navigability indicates that it is Navigable possible to traverse from an object source of the source class to objects of Order * the target class • Objects of the source class may reference objects of the target class using the role name • Even if there is no navigability it might still be possible to traverse the relationship via some indirect means. However the computational cost of the traversal might be very high target * Product navigability Not navigable A Product object does not store a list of Orders A B A to B is navigable B to A is navigable A B A to B is navigable B to A is not navigable A B A to B is navigable B to A is undefined A B A to B is undefined B to A is undefined 68 9.2 Navigability - standard practice • Strict UML 2 navigability can clutter diagrams so the UML standard suggests three possible modeling idioms: • • • Show navigability explicitly on diagrams Omit all navigability from diagrams Omit crosses from diagrams • • • bi-directional associations have no arrows unidirectional associations have a single arrow you can't show associations that are not navigable in either direction (not useful anyway!) standard practice A A B A to B is navigable B to A is not navigable B A to B is navigable B to A is navigable 69 9.4.4 Associations and attributes address House 1 House Address 1 pseudo-attribute = House address:Address attribute address:Address • If a navigable relationship has a role name, it is as though the source class has a pseudo-attribute whose attribute name is the role name and whose attribute type is the target class • Objects of the source class can refer to objects of the target class using this pseudo-attribute • Use associations when: • The target class is an important part of the model • The target class is a class that you have designed yourself and which must be shown on the model • Use attributes when: • The target class is not an important part of the model e.g. a primitive type such as number, string etc. • The target class is just an implementation detail such as a bought-in component or a library component e.g. Java.util.Vector (from the Java standard libraries) 70 9.4.5 Association classes Company * employment * Person Each Person object can work for many Company objects. Each Company object can employ many Person objects. When a Person object is employed by a Company object, the Person has a salary. But where do we record the Person’s salary? • Not on the Person class - there is a different salary for each employment • Not on the Company class - different Person objects have different salaries • The salary is a property of the employment relationship itself • every time a Person object is employed by a Company object, there is a salary 71 9.4.5 Association class syntax Company * * Person Job association class salary:double the association class consists of the class, the association and the dashed line • We model the association itself as an association class. One instance of this class exists for each link between a Person object and a Company object • Instances of the association class are links that have attributes and operations • Can only use association classes when there is one unique link between two specific objects. This is because the identity of links is determined exclusively by the identities of the objects on the ends of the link • We can place the salary and any other attributes or operations which are really features of the association into this class 72 9.4.5 Using association classes If we use an association class, then a particular Person can have only one Job with a particular Company If, however a particular Person can have multiple jobs with the same Company, then we must use a reified Company Company * * Person Job salary:double 1 * Job salary:double * 1 Person association 73 9.4.6 Qualified associations • Qualified associations reduce an n to many association to an n to 1 association by specifying a unique object (or group of objects) from the set • They are useful to show how we can look up or navigate to specific objects • Qualifiers usually refer to an attribute on the target class the combination (Club, memberId) specifies a unique target object Club Club 1 qualifier memberId 1 0..1 * Member Member memberId:String memberId:String 74 9.6 Summary • In this section we have looked at: • Links – relationships between objects • Associations – relationships between classes • • • • • role names multiplicity navigability association classes qualified associations 75 Analysiing - dependencies 76 9.5 What is a dependency? • "A dependency is a relationship between two elements where a change to one element (the supplier) may affect or supply information needed by the other element (the client)". In other words, the client depends in some way on the supplier • Dependency is really a catch-all that is used to model several different types of relationship. We’ve already seen one type of dependency, the «instantiate» relationship • Three types of dependency: • Usage - the client uses some of the services made available by the supplier to implement its own behavior – this is the most commonly used type of dependency • Abstraction - a shift in the level of abstraction. The supplier is more abstract than the client • Permission - the supplier grants some sort of permission for the client to access its contents – this is a way for the supplier to control and limit access to its contents 77 9.5.1 Usage dependencies • «use» - the client makes use of the supplier to implement its behaviour • «call» - the client operation invokes the supplier operation • «parameter» - the supplier is a parameter of the client operation • «send» - the client sends the supplier (which must be a signal) to some unspecified target • «instantiate» - the client is an instance of the supplier 78 9.5.1.1 «use» - example the stereotype is often omitted A foo( b : B ) bar() : B doSomething() «use» B A «use» dependency is generated between class A and B when: 1) An operation of class A needs a parameter of class B A :: doSomething() { B myB = new B(); … } 2) An operation of class A returns a value of class B 3) An operation of class A uses an object of class B somewhere in its implementation 79 9.5.2 Abstraction dependencies • «trace» - the client and the supplier represent the same concept but at different points in development • «substitute» - the client may be substituted for the supplier at runtime. The client and supplier must realize a common contract. Use in environments that don't support specialization/generalization • «refine» - the client represents a fuller specification of the supplier • «derive» - the client may be derived from the supplier. The client is logically redundant, but may appear for implementation reasons 80 9.5.2.4 «derive» - example BankAccount 1 0..* Transaction BankAccount 1 0..* Transaction 1 «derive» balance 1 1 1 1 Quantity This example shows three possible ways to express a «derive» dependency /balance 1 BankAccount /balance:Quantity 1 Quantity 0..* Transaction 1 1 Quantity 81 9.5.3 Permission dependencies • «access» • The public contents of the supplier package are accessible to the contents of the client package - items in the client package must use pathnames to refer to items in the supplier package • «import» • The public contents of the supplier package are added to the namespace of the client package - items in the client package can refer to items in the supplier package without using pathnames • «permit» • The client element has access to the supplier element despite the declared visibility of the supplier 82 9.6 Summary • Dependency • The weakest type of association • A catch-all • There are three types of dependency: • Usage • Abstraction • Permission 83 Analysis – inheritance and polymorphism Chapter 10 84 10.2 Generalisation • A relationship between a more general element and a more specific element • The more specific element is entirely consistent with the more general element but contains more information • An instance of the more specific element may be used where an instance of the more general element is expected Substitutability Principle 85 10.2.1 Example: class generalisation Shape parent superclass base class ancestor Circle child subclass descendent more general element specialisation generalisation “is kind of” Square Triangle more specific elements A generalisation hierarchy 86 10.3 Class inheritance • Subclasses inherit all features of their superclasses: • • • • attributes operations relationships stereotypes, tags, constraints • Subclasses can add new features • Subclasses can override superclass operations • We can use a subclass instance anywhere a superclass instance is expected Substitutability Principle Shape origin : Point = (0,0) width : int {>0} height : int {>0} draw( g : Graphics ) getArea() : int getBoundingArea() : int Square {width = height} Circle radius: int = width/2 But what’s wrong with these subclasses 87 10.3.1 Overriding Shape draw( g : Graphics ) getArea() : int getBoundingArea() : int width x height Square Circle draw( g : Graphics ) getArea() : int draw( g : Graphics ) getArea() : int p x radius2 • Subclasses often need to override superclass behaviour • To override a superclass operation, a subclass must provide an operation with the same signature • The operation signature is the operation name, return type and types of all the parameters • The names of the parameters don’t count as part of the signature 88 10.3.2 Abstract operations & classes Shape abstract class draw( g : Graphics ) getArea() : int abstract class and operation names must be in italics concrete classes getBoundingArea() : int abstract operations concrete operations Square Circle draw( g : Graphics ) getArea() : int draw( g : Graphics ) getArea() : int • We can’t provide an implementation for Shape :: draw( g : Graphics ) or for Shape :: getArea() : int because we don’t know how to draw or calculate the area for a "shape"! • Operations that lack an implementation are abstract operations • A class with any abstract operations can’t be instantiated and is therefore an abstract class 89 10.3.3 Exercise Vehicle what’s wrong with this model? JaguarXJS Truck 90 10.4 Polymorphism • Polymorphism = "many forms" • A polymorphic operation has many implementations • Square and Circle provide implementations for the polymorphic operations Shape::draw() and Shape::getArea() • All concrete subclasses of Shape must provide concrete draw() and getArea() operations because they are abstract in the superclass • For draw() and getArea() we can treat all subclasses of Shape in a similar way - we have defined a contract for Shape subclasses A Canvas object has a collection of Shape objects where each Shape may be a Square or a Circle Canvas 1 shapes * Shape polymorphic operations draw( g : Graphics ) getArea() : int abstract superclass getBoundingArea() : int Square Circle draw( g : Graphics ) getArea() : int draw( g : Graphics ) getArea() : int concrete subclasses 91 10.4.1 What happens? • Each class of object has its own implementation of the draw() operation • On receipt of the draw() message, each object invokes the draw() operation specified by its class • We can say that each object "decides" how to interpret the draw() message based on its class 1.draw() 2.draw() :Canvas s1:Circle s2:Square 3.draw() 4.draw() s3:Circle s4:Circle 92 10.4.1 BankAccount example BankAccount Bank 1 * withdraw() calculateInterest() deposit() ShareAccount CheckingAccount DepositAccount withdraw() calculateInterest() deposit() withdraw() calculateInterest() withdraw() calculateInterest() • We have overridden the deposit() operation even though it is not abstract. This is perfectly legal, and quite common, although it is generally considered to be bad style and should be avoided if possible 93 10.6 Summary • Subclasses: • inherit all features from their parents including constraints and relationships • may add new features, constraints and relationships • may override superclass operations • A class that can’t be instantiated is an abstract class 94 Analysis - packages Chapter 11 95 11.2 Analysis packages • A package is a general purpose mechanism for organising model elements into groups • • • • Group semantically related elements Define a “semantic boundary” in the model Provide units for parallel working and configuration management Each package defines an encapsulated namespace i.e. all names must be unique within the package • In UML 2 a package is a purely logical grouping mechanism • Use components for physical grouping • Every model element is owned by exactly one package • A hierarchy rooted in a top level package that can be stereotyped «topLevel» • Analysis packages contain: • Use cases, analysis classes, use case realizations, analysis packages 96 11.2 Package syntax Membership Membership «access» MemberDetails Membership public (exported) elements private element +ClubMembership +Benefits +MembershipRules +MemberDetails:Member -JoiningRules qualified package name Membership:MemberDetails see later! Member JoiningRules ClubMembership Benefits MembershipRules standard UML 2 package stereotypes «framework» A package that contains model elements that specify a reusable architecture «modelLibrary» A package that contains elements that are intended to be reused by other packages 97 11.4 Nested packages ◼ ◼ ◼ If an element is visible within a package then it is visible within all nested packages ◼ e.g. Benefits is visible within MemberDetails Show containment using nesting or the containment relationship Use «access» or «import» to merge the namespace of nested packages with the parent namespace Membership «import» MemberDetails Member JoiningRules ClubMembership Benefits MembershipRules Membership MembershipRules JoiningRules ClubMembership Benefits «import» MemberDetails containment relationship Member anchor icon 98 11.5 Package dependencies dependency «use» Supplier Supplier Supplier «import» «access» not transitive «trace» Analysis Model «merge» Supplier C y B semantics An element in the client uses an element in the supplier in some way. The client depends on the supplier. Transitive. Client Client Public elements of the supplier namespace are added as public elements to the client namespace. Elements in the client can access all public elements in the supplier using unqualified names. Client Public elements of the supplier namespace are added as private elements to the client namespace. Elements in the client can access all public elements in the supplier using unqualified names. Design Model «trace» usually represents an historical development of one element into another more refined version. It is an extra-model relationship. Transitive. Client The client package merges the public contents of its supplier packages. This is a complex relationship only used for metamodeling - you can ignore it. x A transitivity - if dependencies x and y are transitive, there is an implicit dependency between A and C 99 11.6 Package generalisation • The more specialised child packages inherit the public and protected elements in their parent package • Child packages may override elements in the parent package. Both Hotels and CarHire packages override Product::Item • Child packages may add new elements. Hotels adds Hotel and RoomType, CarHire adds Car Product parent +Price +Market +Item -MicroMarket Hotels CarHire +Product::Price +Product::Market +Item +Hotel +RoomType +Product::Price +Product::Market +Item +Car children 100 11.7 Architectural analysis application specific layer application general layer Sales Products Account Management Inventory Management partitions • This involves organising the analysis classes into a set of cohesive packages • The architecture should be layered and partitioned to separate concerns • It’s useful to layer analysis models into application specific and application general layers • Coupling between packages should be minimised • Each package should have the minimum number of public or protected elements 101 11.7.1 Finding analysis packages • These are often discovered as the model matures • We can use the natural groupings in the use case model to help identify analysis packages: • One or more use cases that support a particular business process or actor • Related use cases • Analysis classes that realise these groupings will often be part of the same analysis package • Be careful, as it is common for use cases to cut across analysis packages! • One class may realise several use cases that are allocated to different packages 102 11.7.2 Analysis packages: guidelines • A cohesive group of closely related classes or a class hierarchy and supporting classes • Minimise dependencies between packages • Localise business processes in packages where possible • Minimise nesting of packages • Don’t worry about dependency stereotypes • Don’t worry about package generalisation • Refine package structure as analysis progresses • 5 to 10 classes per package • Avoid cyclic dependencies! C A merge A B split A B 103 11.8 Summary • Packages are the UML way of grouping modeling elements • There are dependency and generalisation relationships between packages • The package structure of the analysis model defines the logical system architecture 104 Analysis - use case realization Chapter 12 105 12.2 Analyse a use case Business model [or domain model] Requirements model Use case engineer Analysis class Analyse a use case Use case model Use case realization Architecture description 106 12.3 What are use case realizations? use case realization use case Place Order 1 «trace» 1 «use case realization» Place Order dependency • Each use case has a use case realization • parts of the model that show how analysis classes collaborate together to realise the behaviour specified by the use case • they model how the use case is realised by the analysis classes we have identified • They are rarely modelled explicitly • they form an implicit part of the backplane of the model • they can be drawn as a stereotyped collaboration 107 12.4 UC realization - elements • Use case realizations consist of the following elements: • Analysis class diagrams • These show relationships between the analysis classes that interact to realise the UC • Interaction diagrams • These show collaborations between specific objects that realise the UC. They are “snapshots” of the running system • Special requirements • UC realization may well uncover new requirements specific to the use case. These must be captured • Use case refinement • We may discover new information during realization that means that we have to update the original UC 108 12.5 Interactions • Interactions are units of behavior of a context classifier • In use case realization, the context classifier is a use case • The interaction shows how the behavior specified by the use case is realized by instances of analysis classes • Interaction diagrams capture an interaction as: • Lifelines – participants in the interaction • Messages – communications between lifelines 109 12.6 Lifelines jimsAccount [ id = "1234" ] : Account name selector type • A lifeline represents a single participant in an interaction • Shows how a classifier instance may participate in the interaction • Lifelines have: • name - the name used to refer to the lifeline in the interaction • selector - a boolean condition that selects a specific instance • type - the classifier that the lifeline represents an instance of • They must be uniquely identifiable within an interaction by name, type or both • The lifeline has the same icon as the classifier that it represents • The lifeline jimsAccount represents an instance of the Account class • The selector [ id = "1234" ] selects a specific Account instance with the id "1234" 110 12.7 Messages • A message represents a communication between two lifelines sender receiver/ target type of message synchronous message semantics calling an operation synchronously the sender waits for the receiver to complete asynchronous calling an operation asynchronously, sending a signal send the sender does not wait for the receiver to complete :A message return returning from a synchronous operation call the receiver returns focus of control to the sender creation the sender creates the target destruction the sender destroys the receiver found message the message is sent from outside the scope of the interaction lost message the message fails to reach its destination 111 12.8 Interaction diagrams • Sequence diagrams • • • • Emphasize time-ordered sequence of message sends Show interactions arranged in a time sequence Are the richest and most expressive interaction diagram Do not show object relationships explicitly - these can be inferred from message sends • Communication diagrams • Emphasize the structural relationships between lifelines • Use communication diagrams to make object relationships explicit • Interaction overview diagrams • Show how complex behavior is realized by a set of simpler interactions • Timing diagrams • Emphasize the real-time aspects of an interaction 112 12.9 Sequence diagram syntax sd AddCourse synchronous message :Registrar The Registrar selects "add course". lifeline :RegistrationManager addCourse( "UML" ) «create» The system creates the new Course. notes can form a "script" describing the flow object creation message activation message return uml:Course object is created at this point • All interaction diagrams may be prefixed sd to indicate their type • You can generally infer diagram types from diagram syntax • Activations indicate when a lifeline has focus of control - they are often omitted from sequence diagrams 113 12.9 Deletion and self-delegation sd DeleteCourse :RegistrationManager :Registrar deleteCourse( "UML" ) uml:Course self delegation findCourse( "UML" ) nested activation «destroy» object is deleted at this point • Self delegation is when a lifeline sends a message to itself • Generates a nested activation • Object deletion is shown by terminating the lifeline's tail at the point of deletion by a large X 114 12.9.3 State invariants and constraints sd ProcessAnOrder :Customer :OrderManager :DeliveryManager raiseOrder() «create» :Order state invariant label constraint unpaid acceptPayment() A acceptPayment() paid deliver() {B – A
Purchase answer to see full attachment