Lecture 4 OBJECT ORIENTED ANALYSIS PB007  So(ware  Engineering  I   Faculty  of  Informa:cs,  Masaryk  University   Fall  2015   1  ©  Barbora  Bühnová   Outline ² UML Objects and classes [Lecture 3] ² Finding analysis classes [Lecture 3] ² Relationships between objects and classes §  Links §  Associations §  Dependencies ² Inheritance and polymorphism ² UML State diagram 2  ©  Clear  View  Training  2010  v2.6   Relationships Between Objects and Classes Lecture  4/Part  1   3  ©  Clear  View  Training  2010  v2.6   ©  Clear  View  Training  2010  v2.6   4   What is a link? ² 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 §  When an object has a stored reference to another object, we say that there is a link between the objects ©  Clear  View  Training  2010  v2.6   5   Object diagrams ²  Paths in UML diagrams can be drawn as orthogonal, oblique or curved lines ²  We can combine paths into a tree if each path has the same properties bookClub:Club ila:Person erica:Person naomi:Person chairperson secretary member role name link BookClub bookClub:Club ila:Person erica:Person naomi:Person chairperson secretary member BookClub oblique path style orthogonal path style preferred object Shape Square Circle Triangle ©  Clear  View  Training  2010  v2.6   6   What is an association? ²  Associations are relationships between classes ²  Associations between classes indicate that there may be links between objects of those classes, while links indicates that there must be associations ²  Can there be a communication between objects of two classes that have no association between them? bookClub:Club jim:Person chairman Club Person «instantiate» «instantiate» «instantiate» link association links instantiate associations ©  Clear  View  Training  2010  v2.6   7   Association syntax ²  An association can have role names OR an association name ²  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 Company Person 1 0..* employs navigability association name multiplicity Company Person employer employee 1 0..* role names multiplicity: min..max 0..1 zero or 1 1 exactly 1 0..* zero or more 1..* 1 or more 1..6 1 to 6 reading direction ©  Clear  View  Training  2010  v2.6   8   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 Person employee 1 7 employer BankAccount 0..* 1owner 0..* 1..* operator ©  Clear  View  Training  2010  v2.6   9   Reflexive associations: file system example Directory File 0..*10..* 0..1 C Windows My Documents Corel Command autoexec config To John directories files parent subdirectory reflexive association ²  If ToJohn was a directory, would it still conform to the class diagram? ©  Clear  View  Training  2010  v2.6   10   Hierarchies and networks A 0..* 0..1 a1:A b1:A c1:A d1:A e1:A f1:A g1:A B 0..* 0..* a1:B b1:B c1:B d1:Be1:B f1:B g1:B hierarchy network In an association hierarchy, each object has zero or one object directly above it. In an association network, each object has zero or many objects directly above it. ©  Clear  View  Training  2010  v2.6   11   Navigability ²  Navigability indicates that it is possible to traverse from an object of the source class to objects of the target class ²  Can there be a communication in a direction not supported by the navigability? ²  Are some of the cases on the right equivalent? Order Product 0..* 0..* Not navigable A Product object does not store a list of Orders An Order object stores a list of Products Navigable source target navigability A B A B A B A B A to B is navigable B to A is navigable A to B is navigable B to A is not navigable A to B is navigable B to A is undefined A to B is undefined B to A is undefined ©  Clear  View  Training  2010  v2.6   12   Associations and attributes ²  An association is (through its role name) a representation of an 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 ²  Use attributes when: §  The target class is not important, e.g. a primitive type such as number, string §  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) address:Address House House Address 1 1 address House address:Address pseudo-attribute attribute = ©  Clear  View  Training  2010  v2.6   13   Association classes Company Person 0..* 0..*employment ²  Where do we record the Person’s salary? ²  We model the association itself as an association class. Exactly one instance of this class exists for each link between a Person and a Company. ²  We can place the salary and any other attributes or operations which are really features of the association into this class Company Person 0..* 0..* Job salary:double the association class consists of the class, the association and the dashed line association class ©  Clear  View  Training  2010  v2.6   14   Using association classes Company Person 0..* 0..* Job salary:double 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 association Company Person Job salary:double 0..*0..* 11 ©  Clear  View  Training  2010  v2.6   15   Dependencies ²  "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 §  Weaker type of relationship than association §  Can there be both association and dependency between two classes? ²  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 ©  Clear  View  Training  2010  v2.6   16   Usage dependencies ²  Stereotypes §  «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 (an operation) sends the supplier (a signal) to some unspecified target §  «instantiate» - the client is an instance of the supplier A foo( b : B ) bar() : B doSomething() B A :: doSomething() { B myB = new B(); } «use» A «use» dependency is generated between A and B when B is used in A as a parameter, return value or inside method body the stereotype is often omitted ©  Clear  View  Training  2010  v2.6   17   Abstraction and permission dependencies ²  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 ²  Permission dependencies §  «access» the public contents of the supplier package are added as private elements to the namespace of the client package §  «import» the public contents of the supplier package are added as public elements to the namespace of the client package §  «permit» the client element has access to the supplier element despite the declared visibility of the supplier ©  Clear  View  Training  2010  v2.6   18   Key points ² Links – relationships between objects ² Associations – relationships between classes §  role names §  multiplicity §  navigability §  association classes ² Dependencies – relationships between model elements §  usage §  abstraction §  permission ©  Clear  View  Training  2010  v2.6   19   Inheritance and polymorphism Lecture  4/Part  2   ©  Clear  View  Training  2010  v2.6   20   Generalisation Shape Square Circle Triangle more general element more specific elements parent superclass base class ancestor child subclass descendent generalisation specialisation A generalisation hierarchy “is kind of” A  rela:onship  between  a  more  general  element  and  a  more   specific  element  (with  more  informa:on)     ©  Clear  View  Training  2010  v2.6   21   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 Circle radius : int = width/2 What’s wrong with these subclasses? ©  Clear  View  Training  2010  v2.6   22   Overriding ²  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 Shape draw( g : Graphics ) getArea() : int getBoundingArea() : int Square Circle draw( g : Graphics ) getArea() : int draw( g : Graphics ) getArea() : intwidth x height π x radius2 What’s wrong with the superclass? ©  Clear  View  Training  2010  v2.6   23   Abstract operations & classes ²  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 concrete operations Shape draw( g : Graphics ) getArea() : int getBoundingArea() : int Square Circle draw( g : Graphics ) getArea() : int draw( g : Graphics ) getArea() : int abstract class concrete classes abstract operations Abstract class and operation names must be in italics ©  Clear  View  Training  2010  v2.6   24   Exercise Vehicle JaguarXJS Truck what’s wrong with this model? ©  Clear  View  Training  2010  v2.6   25   Polymorphism ²  Polymorphism = "many forms" §  A polymorphic operation has many implementations §  Square and Circle provide implementations for the polymorphic operations Shape::draw() and Shape::getArea() ²  The operation in Shape superclass defines a contract for the subclasses. Shape draw( g : Graphics ) getArea() : int getBoundingArea() : int Square Circle draw( g : Graphics ) getArea() : int draw( g : Graphics ) getArea() : int polymorphic operations concrete subclasses abstract superclass Canvas 0..* 1 A Canvas object has a collection of Shape objects where each Shape may be a Square or a Circle shapes ©  Clear  View  Training  2010  v2.6   26   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 :Canvas s1:Circle s2:Square s3:Circle s4:Circle 1.draw() 2.draw() 3.draw() 4.draw() ©  Clear  View  Training  2010  v2.6   27   BankAccount example ²  We have overridden the deposit() operation even though it is not abstract. BankAccount withdraw() calculateInterest() deposit() CheckingAccount DepositAccount withdraw() calculateInterest() withdraw() calculateInterest() Bank 0..*1 ShareAccount withdraw() calculateInterest() deposit() ©  Clear  View  Training  2010  v2.6   28   Key points ² Generalisation, specialisation, inheritance ² 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 ©  Clear  View  Training  2010  v2.6   29   UML State Diagram Lecture  4/Part  3   ©  Clear  View  Training  2010  v2.6   30   State machines ²  Models life stages of a single model element – e.g. object, use case, module ²  Every state machine exists in the context of a particular model element that: §  Has a clear life history modelled as a progression of states, transitions and events §  Responds to events dispatched from outside of the element ²  There are two types of state machines: §  Behavioural state machines - define the behaviour of a model element §  Protocol state machines - model the protocol of a classifier •  E.g. call conditions and call ordering of an interface that itself has no behaviour Off On Off On turnOff burnOut light bulb turnOn ©  Clear  View  Training  2010  v2.6   31   Basic state machine syntax ²  State = a situation or condition during the life of an object §  Determined at any point in time by the values of its attributes, the relationships to other objects, or the activities it is performing. ²  Every state machine should have one initial state which indicates the first state of the sequence ²  Unless the states cycle endlessly, state machines should have a final state which terminates its lifecycle A B anEvent initial state transition event state final state Color red : int green : int blue : int How many states? ©  Clear  View  Training  2010  v2.6   32   State syntax ²  Actions are instantaneous and uninterruptible §  Entry actions occur immediately on state entry §  Exit actions occur immediately on state leaving ²  Internal transitions occur within the state. They do not fire transition to a new state ²  Activities take a finite amount of time and are interruptible EnteringPassword entry/display passwd dialog exit/validate password keypress/ echo "*" help/display help do/get password entry and exit actions internal transitions internal activity Action syntax: eventTrigger / action Activity syntax: do / activity state name ©  Clear  View  Training  2010  v2.6   33   Transitions A B event1, event2 [guard condition] / act1, act2 behavioral state machine C D [precondition] event1, event2 / [postcondition] protocol state machine {protocol} Protocol state machine Specifies legal sequences of events. Behavioral state machine Specifies object’s reactions to events. events guard condition actions precondition events postcondition ©  Clear  View  Training  2010  v2.6   34   ²  Choice pseudo state directs its single incoming transition to one of its outgoing transitions §  Each outgoing transition must have a mutually exclusive guard condition §  Equivalent to two outgoing transitions from one state ²  Junction pseudo state connects multiple incoming transitions into one (or more) transitions. §  When there are more outgoing transitions, they must have guard conditions Unpaid FullyPaid PartiallyPaidOverPaid [payment == balance] [payment > balance] [payment < balance] acceptPayment acceptPayment makeRefund BankLoan choice pseudo-state Choice and junction pseudo states junction pseudo state ©  Clear  View  Training  2010  v2.6   35   Events ²  "The specification of a noteworthy occurrence that has location in time and space" ²  Events trigger transitions in state machines ²  Events can be shown externally, on transitions, or internally within states (internal transitions) ²  There are four types of event: §  Call event §  Signal event §  Change event §  Time event Off On turnOff turnOn event ©  Clear  View  Training  2010  v2.6   36   close() Call event ²  A call for an operation execution ²  The event should have the same signature as an operation of the context class ²  A sequence of actions may be specified for a call event - they may use attributes and operations of the context class ²  The return value must match the return type of the operation InCredit deposit(m)/ balance = balance + m AcceptingWithdrawal entry/ balance = balance - m RejectingWithdrawal entry/ logRejectedWithdrawal() withdraw(m) [balance < m] withdraw(m) [balance >= m] internal call event action conditionexternal call event entry action SimpleBankAccount ©  Clear  View  Training  2010  v2.6   37   close() Signal events ²  A signal is a package of information that is sent asynchronously between objects InCredit deposit(m)/ balance = balance + m AcceptingWithdrawal entry/ balance = balance - m RejectingWithdrawal entry/ logRejectedWithdrawal() withdraw(m) [balance < m] withdraw(m) [balance >= m] SimpleBankAccount OverdrawnAccount send a signal «signal» OverdrawnAccount date : Date accountNumber : long amountOverdrawn : long Calling borrowerOverdrawnAccount signal receipt ©  Clear  View  Training  2010  v2.6   38   close() Change events ²  The action is performed when the Boolean expression transitions from false to true §  The event is edge triggered on a false to true transition §  The values in the Boolean expression must be constants, globals or attributes of the context class ²  A change event implies continually testing the condition whilst in the state InCredit deposit(m)/ balance = balance + m balance >= 5000 / notifyManager() AcceptingWithdrawal entry/ balance = balance - m RejectingWithdrawal entry/ logRejectedWithdrawal() withdraw(m) [balance < m] withdraw(m) [balance >= m] SimpleBankAccount OverdrawnAccount Boolean expression ©  Clear  View  Training  2010  v2.6   39   Time events ² Time events occur when a time expression becomes true ² There are two keywords, after and when ² Elapsed time: §  after( 3 months ) ² Absolute time: §  when( date =20/3/2000) Overdrawn balance < overdraftLimit / notifyManager Frozen after( 3 months ) Context: CreditAccount class ©  Clear  View  Training  2010  v2.6   40   Composite states ²  Have one or more regions that each contain a nested submachine §  Simple composite state •  exactly one region §  Orthogonal composite state •  two or more regions ²  The final state terminates its enclosing region – all other regions continue to execute ²  The terminate pseudo-state terminates the whole state machine A composite state A B C region 1 region 2 submachines Another composite state D E F terminate pseudo-state ©  Clear  View  Training  2010  v2.6   41   [dialtone] after(20 seconds)/ noDialtone after(20 seconds)/ noCarrier [carrier] cancel Simple composite states do/ dialISP DialingISP entry/ offHook WaitingForDialtone Dialing WaitingForCarrier entry pseudo state notConnected dial connectedexit pseudo-state NotConnected Connected entry/ onHook exit/ onHook do/ useConnection ISPDialer the nested states inherit the cancel transition ©  Clear  View  Training  2010  v2.6   42   Orthogonal composite states ² Has two or more regions ² When we enter the superstate, both submachines start executing concurrently - this is an implicit fork do/ initializeSecuritySensor Initializing InitializingFireSensors do/ initializeFireSensor InitializingSecuritySensors Initializing composite state details do/ monitorSecuritySensor Monitoring MonitoringFireSensors do/ monitorFireSensor MonitoringSecuritySensors fire intruder Monitoring composite state details Synchronized exit - exit the superstate when both regions have terminated Unsynchronized exit - exit the superstate when either region terminates. The other region continues ©  Clear  View  Training  2010  v2.6   43   Key points ² Behavioral and protocol state machines ² States §  Initial and final §  Exit and entry actions, activities ² Transitions §  Guard conditions, actions ² Events §  Call, signal, change and time ² Composite states §  Simple and orthogonal composite states