Object-Oriented Analysis and Design II

Dynamic Analysis Modeling

• Dynamic modeling means that we model things changing over time
• System operations
• System operations are behaviors that are visible from outside the system
• They describe what the system does as a step in a use case
• A system operation is invoked by an actor during a use case scenario
• A system operation is an elementary unit of functionality that is performed by the system, as seen from the outside.
• It can’t be decomposed any further at the requirements level of abstraction.
• The next level of decomposition requires an understanding of what is inside the system to make it work.
• This is the level of abstraction that we are at during analysis.
• State changes
• System operation typically results in a change in state of the system.
• We will specify a system operation in terms of the state of the system before and after the execution of the system operation.
• These changes can be documented as preconditions and postconditions.
• What we mean by system state is the values of all of the information stored within the system.
• The only way to change the state of the system is to invoke a system operation.
• The invocation of the system operation is called a “trigger.”
• The only kinds of system state changes that can occur are these five.
• Creation of an object instance
• Destruction of an object instance
• Creation of a link connecting two object instances together
• Destruction of a link
• Modification of attribute values within an object instance
• model how the system gets from the before state to the after state

UML Activity Diagrams

• Activity diagrams provide us with a notation for describing the dynamic collaborations of the objects graphically.
• Activity diagrams are good at showing the sequence of actions inside the system when a system operation is being executed.
• The actions in the activity diagram correspond to the execution of operations on individual object instances inside the system.
• What activity diagrams do not show is how the objects communicate.
• There are two particular nodes in an activity diagram. They are the start and end nodes.
• The start is represented as a solid circle with a flow coming out of it.
• The end, or activity final, node is a solid circle with a ring around it, and only one flow coming into it.
• There are decision nodes in activity diagrams.
• A decision node has one incoming flow and multiple outgoing flows.
• Each of the outgoing flows is annotated with a Boolean expression, called a guard.
• Guards are enclosed within square brackets and are placed near the flows emanating from the decision node.
• At the point in the flow when the decision is reached, the guards are evaluated.
• The outgoing flow corresponding to the guard that is true is the path that is taken.
• It is generally, then, a good idea for all of the guards to be disjoint.
• It is also a good idea for there to be no gaps in the set of guards.
• Corresponding to a decision node is a merger node.
• The merge is also a diamond shaped node, also with nothing inside it.
• The purpose of the merge node is to merge all of the paths that were created at the decision node back together into a single flow once again.
• A construct that is structurally quite similar to the decision and merger is the fork and join.
• We use the same icon for both the fork and the join.
• It is a straight bold line. The fork has a single flow coming in, and multiple flows coming out.
• The join has multiple flows coming in, and a single flow coming out.
• Unlike with the decision-merge structure, where only one flow is executed, with the fork and join, all of the flows emanating from the fork are executed.
• They are preformed asynchronously.
• This means that they could be executed at the same time, or they could be executed in any order.
• All of the flows that come out of a fork are joined back together again at the join.
• The behavior of the join is that it won’t resume with the outgoing flow until all of the incoming flows have finished executing and control for each flow has arrived at the join.
• A nice feature of activity diagram modeling is the partition, or sometimes called the “swim lane.”
• While keeping all of the flows intact, it is possible to rearrange the actions so that they are in groups based on who performs them.
• The “who” in this case might be actors, or subsystems, or object instances.
• The partitions are labeled with a name indicating who performs the actions in the partitions.

Introduction to object-oriented design

• In design, our focus changes
• When we were doing analysis, we were trying to get an understanding of what classes needed to be built and how the object instances of those classes interacted to carry out the system operations.
• In design, we are concerned about how those classes should be implemented in code.
• The requirements models specify the system as a black box.
• The analysis models specify the classes within the system as smaller black boxes.
• Design, on the other hand, is an abstraction of the code. It models the implementation at a higher level of abstraction.
• Analysis is a more concrete view of the requirements while design is a more abstract view of the code.
• During analysis we weren’t too concerned with control strategy.
• We were more interested in understanding the behavior of the objects themselves.
• In design, control is a big issue because it affects the code.
• In analysis, we only modeled just the domain, or entity classes.
• In the design, we will see that we will need a lot of what I call “helper” classes.
• One thing that we will have to decide on is the control strategy.
• When one object sends a message to another, it must have a reference or pointer to that object.
• Design is when we begin to be concerned about performance.
• Performance can be used as a driver for making design decisions.
• In design, we need to worry about boundary conditions or software faults.
• We begin to be influenced by the programming language and the operating system at design time.

Static Object Orient Design Modeling using UML Class Diagram Notation

• In fact, many of the decisions that we are forced to make in programming are in fact design decisions. 
• Most of the entity classes in the analysis class diagram will appear in the design class diagram as well.
• However, there may be some good reasons why one or more of the analysis classes is not part of the design.

Implementing association

• In design, ALL information, whether it is attributes or link information, all information is stored as attributes inside objects.
• So, linkage information must be stored as attributes in the design model.
• The linkage information is stored as object references or pointers.
• An object reference is a piece of data. It can be stored in a variable.
• The data type of that variable is the class of the object being referenced
• the data type of the variable can be either the class of the object being references, or any of the ancestor classes up the inheritance hierarchy.
• since an object reference is data, it can be passed around as an argument or return result in the invocation of an operation.

Directionality

• when we make the decision about where the object reference is to be stored, we will represent that information by putting an arrow head on one end of the association line.
• This directed association looks like a pointer from the class where the object reference is stored to the class being referenced.
• If the multiplicity on each end of the association is 1, then storing the link is easy. You just put a referential attribute variable in the referencing class.
• But if the multiplicity is greater than one, an object instance of the one class has to be able to point to many object instances of the second class. This means that the object must store a collection of references. This collection is a set, by default. There is no left to right order of the links.
• If you wanted the links to be ordered in some way, then you would have placed a constraint such as {ordered} or {FIFO} on the association.

Aggregations and compositions

• aggregation is just a special kind of association that has the inherent meaning, “contains” or “part of.
• It has a special symbol, an open diamond on the aggregator end of the association.
• So the way we deal with multiplicity is exactly the same as for regular associations.
• If the multiplicity on the far side of the relationship is greater than one, then you’ll need a collection of object references.
• Once again, by default this collection is an unordered set. If you need order, then you can use an ordered collection, such as a list.

Compositions

• Compositions are much more highly constrained than aggregations.
• The composite fully encapsulates the parts.
• The lifetime of the parts is completely controlled by the composite.
• This also means that the directionality of the composite relationship must always be from the composite to the parts.
• The links are stored in he composite.
• Usually the multiplicity on the part end of the relationship has a multiplicity of greater than one.

Object Lookup

• Each object instance of a particular class will have a unique key value associated with it, and stored as an attribute.
• The object instance can then be located by using that unique key.
• We will need an operation to translate a key value into an object reference.
• In order for other objects in the system to be able to invoke this lookup operation, it needs to be visible to all of them
• The best way to accomplish this is to make the lookup operation globally visible.
• One would be to put the lookup operation in a singleton object.
• The other option, and the one we will choose here, is to add the lookup operation as a static operation to the class of the objects we want to look up.

Generalization-specialization

• This use of aggregation rather than generalization is called the state pattern.
• Sometimes we can introduce inheritance at design time.
• During analysis, we identify classes in the problem domain.
• At design time, consider dividing some of the classes into two parts, a general part and a specific part.
• The general part becomes an abstract superclass.
• The specific part becomes a concrete subclass.
• More subclasses can be easily added later if you discover other specializations.

Dynamic Design

• As far as the dynamics are concerned, we are interested in not only what the operations are, and in what order they are executed, but also how they get executed
• We care about an object having a reference to another object when it needs to send a message to that object.
• So we will need to design the access to the object reference in addition to the use of the reference to send the message.
• We will be using the UML Sequence Diagram notation to design these dynamics.
• For each system operation, we need to identify a controller.
• This controller may be one of the existing entity classes, or it may be a made up class, especially constructed for the purpose of controlling the system operation.
• If we choose an existing entity class, it usually is one with the same name as the actor that initiates the system operation.
• It is important to note that the controller is an operation, not an object or a class.
• Thus, if we choose the option of creating a special controller class, it probably would only have just that one operation, and no attributes.
• It would just be a holder for the controller operation.
• There are two main ways the customer actor can communicate with the system.
• One is for the actor to send the actual customer object instance as a serialized object
• This could be done with some kind of remote procedure call or remote method invocation mechanism
• We would need a boundary class to handle communication to and from the actor.
• The boundary class would reconstitute the customer object and then execute the addItem operation.
• More frequently, the communication between the actor and the boundary object is done via text message.
• Sequence diagrams model the code more closely than activity diagrams do.
• If the reference is stored as a referential attribute in an object, it may be used to send a message.
• Frequently the multiplicity of these referential attributes is greater than one.
• This means that there is a collection of referential attributes.

UML Sequence Diagrams

• Sequence diagrams show the object instances that are involved in the system operation.
• Object instances that exist at the start of the system operation are shown along the top of the diagram.
• To represent an object over time, we extend a dashed line, called a lifeline, below it.
• Time goes down the page.
• A message is represented as a solid line with an arrow head from the lifeline of the sender to the lifeline of the receiver.
• The message is annotated with the name of the operation being invoked in the receiver object.
• Optionally, you can include arguments being passed to the operation.
• Usually we show the operation signature on the line, including the formal parameter names and their types.
• Returned results are indicated by a dashed line with an arrow head.
• We can show the creation of an object instance by drawing the constructor message being sent to the object instance box at the point in the timeline when the object is being created.
• We can show the destruction of an object by terminating its lifeline with a large X.
• We can show a message being sent to a class if we realize that a class is technically an object instance of the meta-class, Class.

Structuring Sequence Diagrams

• A frame is a rectangle containing part (or all) of a sequence diagram.
• It has a pentagon in the upper left corner.
• This pentagon is called the heading. It indicates the purpose of the frame.
• There are many kinds of frames. Some of the more popular types are reference, looping, decision, and parallelism.
• The frame with ref in the pentagon is a reference frame.
• It contains the name of another sequence diagram.
• It serves the same purpose as the rake in our activity diagrams.
• To indicate looping, we use a loop frame.
• The top of the frame contains a predicate in square brackets.
• You can use keywords such as for and while in the predicate.
• Whatever messages are inside the frame are repeated based on the predicate.
• The word in the pentagon is alt, for alternative behaviors.
• There may be any number of parts.
• Each part has a predicate
• You use the keyword else on the last one if you want.
• It is a good idea for all of the predicates to be disjoint and to cover the entire domain
• The keyword here is par, for parallel.
• There are multiple parts.
• Each part is executed in parallel with the others.
• The rules for parallel execution here are similar to those in activity diagrams.
• Each of the parallel regions must wait for all of the others to terminate before the frame terminates.
• Frames may be nested to any depth.
• Frame borders may not cross – that is, a frame must be fully contained within another frame.
• This leads to a nice hierarchical structure in the diagrams.