OOAD
OOAD
OOAD
Cont
During object-oriented design there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, a Plane software object may have a tailNumber attribute and a getFlightHistory method. Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system.
Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.
Cont
Object-Oriented Analysis and Design course will familiarize us with all phases of Object-Oriented Analysis and Design (OOAD) using the Unified Modeling Language (UML). We will learn how to consider any subject matter and identify all its concepts and relationships to express and model them using UML Analysis, and then design them in preparation for the programming phase. Furthermore, we will learn advanced Analysis and Design strategies based upon the most important Object-Oriented Patterns. This course will set us up to master the fundamental aspects of Analysis and Design a developer needs to succeed.
Why We Model
Modeling is a central part of all the activities that lead up to the deployment of good software. We build models to communicate the desired structure and behavior of our system. We build models to visualize and control the system's architecture. We build models to better understand the system we are building, often exposing opportunities for simplification and reuse. We build models to manage risk.
Cont
If you really want to build the software equivalent of a house or a high rise, the problem is more than just a matter of writing lots of softwarein fact, the trick is in creating the right software and in figuring out how to write less software. This makes quality software development an issue of architecture and process and tools. Modeling is not just a part of the building industry. It would be inconceivable to deploy a new aircraft or an automobile without first building modelsfrom computer models to physical wind tunnel models to full-scale prototypes. What, then, is a model?
Cont
To deploy software that satisfies its intended purpose, you have to meet and engage users in a disciplined fashion, to expose the real requirements of your system. To develop software of lasting quality, you have to craft a solid architectural foundation that's resilient to change. To develop software rapidly, efficiently, and effectively, with a minimum of software scrap and rework, you have to have the right people, the right tools, and the right focus.
Principles of Modeling
The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Every model may be expressed at different levels of precision.
Relationships
Diagrams
Things are the abstractions that are first-class citizens in a model. Relationships tie these things together. Diagrams group interesting collections of things.
Structural Things
Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. In all, there are seven kinds of structural things. 1. Class: A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations
Window origin size open() close() move()
Interface, Collaborations
An interface is a collection of operations that specify a service of a class or component. An interface might represent the complete behavior of a class or component or only a part of that behavior. Graphically, an interface is rendered as a circle together with its name. An interface rarely stands alone. It is typically attached to the class or component that realizes the interface.
Ispelling A collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements.
Chain of Responsibilities
a use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor.
Place Order
an active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. a component is a physical and replaceable part of a system that conform to and provides the realization of a set of interfaces. node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, processing capabilities to provides the realization of a set of interfaces.
BEHAVIORAL THINGS
Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. an interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. a state machine is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. The behavior of an individual class or a collaboration of classes may be specified with a state machine.
an association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. a generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). a realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.
DIAGRAMS
In modeling real systems, no matter what the problem domain, you'll find yourself creating the same kinds of diagrams, because they represent common views into common models. Typically, you'll view the static parts of a system using one of the four following diagrams. Class diagram Object diagram Component diagram Deployment diagram Five diagrams to view the dynamic parts of a system. Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram
Stereotype
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building blocks that are derived from existing ones but are specific to your problem. A tagged value extends the properties of a UML building block, allowing you to create new information in that element's specification. A constraint extends the semantics of a UML building block, allowing you to add new rules or modify existing ones.
Extend is used when a use case conditionally adds steps to another first class use case. For example, imagine "Withdraw Cash" is a use case of an ATM machine. "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is instantiated when the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw Cash" use case stands on its own, without the extension. Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. For example, the flow of events that occurs at the beginning of every ATM use case (when the user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for an include.
CRC Cards
Class ATM Responsibilities Start up when switch is turned on Collaborators OperatorPanel CashDispenser NetworkToBank Shut down when switch is turned off NetworkToBank Start a new session when card is inserted by CustomerConsole customer Session Provide access to component parts for sessions and transactions Class CardReader Responsibilities Collaborators Tell ATM when card is inserted ATM Read information from card Card Eject card Retain card
CRC Cards
Class CashDispenser Responsibilities Collaborators Keep track of cash on hand, starting with initial amount Report whether enough cash is available Dispense cash Log Class CustomerConsole Responsibilities Collaborators Display a message Display a prompt, accept a PIN from keyboard Display a prompt and menu, accept a choice from keyboard Display a prompt, accept a dollar amount from keyboard Respond to cancel key being pressed by customer Class EnvelopeAcceptor Responsibilities Collaborators Accept envelope from customer; report if timed out or cancelled Log
CRC Cards
Class Log Responsibilities Log messages sent to bank Log responses from bank Log dispensing of cash Log receiving an envelope Class NetworkToBank Responsibilities Initiate connection to bank at startup Send message to bank and wait for response Collaborators
Collaborators
Terminate connection to bank at shutdown Class OperatorPanel Responsibilities Inform ATM of changes to state of switch Allow operator to specify amount of initial cash
Collaborators ATM
CRC Cards
Class ReceiptPrinter Responsibilities Print receipt Class Session Responsibilities Perform session use case Collaborators Receipt Collaborators ATM CardReader Card CustomerConsole Transaction
Update PIN value if customer has to re-enter it Abstract Class Transaction Responsibilities Allow customer to choose a type of transaction
CRC Cards
Perform Transaction Use Case ATM CustomerConsole Withdrawal Deposit Transfer Inquiry Message NetworkToBank Receipt
Class Withdrawal Responsibilities Perform operations peculiar to withdrawal transaction use case
CRC Cards
Class Deposit Responsibilities Collaborators Perform operations peculiar to deposit transaction use case CustomerConsole Message EnvelopeAcceptor Receipt Class Transfer Responsibilities Collaborators Perform operations peculiar to transfer transaction use case CustomerConsole Message Receipt Class Inquiry Responsibilities Collaborators Perform operations peculiar to inquiry transaction use caseCustomerConsole Message Receipt Class Balances Responsibilities Collaborators Represent account balance information returned by bank
CRC Cards
Class Card Responsibilities Collaborators Represent information encoded on customer's ATM card Class Message Responsibilities Collaborators Represent information to be sent over network to bank Class Receipt Responsibilities Collaborators Represent information to be printed on a receipt Class Status Responsibilities Collaborators Represent transaction status information returned by bank
Instance
An instance is a concrete manifestation of an abstraction to which a set of operations can be applied and which has a state that stores the effects of the operations. Instance and object are largely synonymous. Graphically, an instance is rendered by underlining its name. Instances don't stand alone; they are almost always tied to an abstraction. Most instances you'll model with the UML will be instances of classes (and these things are called objects), although you can have instances of other things, such as components, nodes, use cases, and associations. In the UML, an instance is easily distinguishable from an abstraction. To indicate an instance, you underline its name. In a general sense, an object is something that takes up space in the real or conceptual world, and you can do things to it. For example, an instance of a node is typically a computer that physically sits in a room;. an instance of a component takes up some space on the file system; an instance of a customer record consumes some amount of physical memory. Similarly, an instance of a flight envelope for an aircraft is something you can manipulate mathematically.
Activity Diagrams
An activity diagram is essentially a flowchart that emphasizes the activity that takes place over time. You can think of an activity diagram as an interaction diagram turned inside out. An interaction diagram looks at the objects that pass messages; an activity diagram looks at the operations that are passed among objects. An activity diagram shows the flow from activity to activity. An activity is an ongoing nonatomic execution within a state machine. Activities ultimately result in some action, which is made up of executable atomic computations that result in a change in state of the system or the return of a value. Actions encompass calling another operation, sending a signal, creating or destroying an object, or some pure computation, such as evaluating an expression. Graphically, an activity diagram is a collection of vertices and arcs.
Activity Diagrams
Activity diagrams commonly contain Activity states and action states Transitions Objects
Transitions
Triggerless transitions may have guard conditions, meaning that such a transition will fire only if that condition is met; When the action or activity of a state completes, flow of control passes immediately to the next action or activity state. You specify this flow by using transitions to show the path from one action or activity state to the next action or activity state.
Branching
Branches are a notational convenience, semantically equivalent to multiple transitions with guards. Sequential transitions are common, but they aren't the only kind of path you'll need to model a flow of control. As in a flowchart, you can include a branch, which specifies alternate paths taken based on some Boolean expression. A branch may have one incoming transition and two or more outgoing ones. On each outgoing transition, you place a Boolean expression, which is evaluated only once on entering the branch. Across all these outgoing transitions, guards should not overlap (otherwise, the flow of control would be ambiguous), but they should cover all possibilities.
Swimlanes
When you are modeling workflows of business processes, to partition the activity states on an activity diagram into groups, each group representing the business organization responsible for those activities. In the UML, each group is called a swimlane because, visually, each group is divided from its neighbor by a vertical solid line. Each swimlane has a name unique within its diagram. A swimlane really has no deep semantics, except that it may represent some realworld entity. Each swimlane represents a high-level responsibility for part of the overall activity of an activity diagram, and each swimlane may eventually be implemented by one or more classes. In an activity diagram partitioned into swimlanes, every activity belongs to exactly one swimlane, but transitions may cross lanes.
Modelling an operation
Collect the abstractions that are involved in this operation. This includes the operation's parameters (including its return type, if any), the attributes of the enclosing class, and certain neighboring classes. Identify the preconditions at the operation's initial state and the postconditions at the operation's final state. Also identify any invariants of the enclosing class that must hold during the execution of the operation. Beginning at the operation's initial state, specify the activities and actions that take place over time and render them in the activity diagram as either activity states or action states. Use branching as necessary to specify conditional paths and iteration. Only if this operation is owned by an active class, use forking and joining as necessary to specify parallel flows of control.
THANK YOU!!