OOAD with UML.pptx
Object-Oriented Analysis & Design with UML HERY HERYANTO
Overview
UML has become the de facto standard for
modeling object-oriented software. UML has been
adopted by companies throughout the world, and
today more than 50 commercial and academicObjectives
1. Teaching the basic concepts and principles of Object Orientation including Object Oriented Analysis and Design.
UML Modelling
Usecase Diagram
Usecase Diagram cont
- Actor: A role played by a person, system, device, or even an enterprise, that has a stake in the successful operation of the system.
- Use case: Identifes a key behavior of the system.
Usecase Diagram cont.
- Include relationship: Identifes a reusable use case that is unconditionally incorporated into the execution of
another use case. Responsibility for the decision about
Modeling Actors
In UML, the term actor refers to a type of user. Users, in the classic sense, are people who use the system. But users may also be other systems, devices, or even businesses that trade information. In Use Case diagrams, people, systems, devices, and even enterprises are all referred to as actors. The icons to model them may vary, but the concept remains the same
Modeling Actors cont
Any icon may be used to replace these. Picture below ofers some alternatives. A company logo might represent an enterprise. A cartoon image might represent a device. A graphic may be used to represent a system. Often, using
alternative icons in a modeling tool is as simple as importing
Include Relationship
To use the «include» relationship, the use cases must conform to two constraints:
- The calling use case may only depend on the result from the called use case. It can have no knowledge of the internal structure of the use case.
Extend Relationship
The «extend» relationship says that one use case might augment the behavior of another use case. The extension use case provides a discrete behavior that might need to insert itself into the base use case. The arrow is drawn from the extension to the executing use case. Drawing the arrow with the base at the extension use case indicates that the extension, not the executing use case, Use Case Name SelectPerformance Use Case Number
12 Use Case Narrative Author Jane Analyst and Joe Client Last Updated April 1, 2003 Assumptions The actor has the appropriate authority to use this feature. Preconditions None. Use Case Initiation This use case starts on demand. Use Case Dialog The user should be given a default set of information about the shows scheduled within the next 20 days. The user should also be provided with all the events currently scheduled at the venue.
Use Case Scenarios
Summary
Use case diagrams, together with use case narratives and scenarios, defne the goals of a system, or other classifer, such as an enterprise, subsystem, or component. The purpose of the use case approach is to focus the development efort on the essential objectives of the system without getting lost in, or driven by, particular implementations or practices.
Overview
- The Activity diagram is often seen as part of the functional view of a system because it describes logical processes, or functions. Each process describes a sequence of tasks and the decisions that govern when and how they are performed.
Notation
- MODELING ACTIVITIES AND ACTIONS
Activities and actions are the two fundamental units of behavior in an Activity diagram. An activity is the highest-level unit of behavior in an Activity diagram. An activity consists of a set of ActivityNodes and ActivityEdges (connectors).
Notation
- MODELING INITIAL AND ACTIVITY FINAL NODES
A sequence of actions has a beginning and an end. The Activity diagram defnes two ControlNodes: InitialNode, to designate the starting point in a sequence, and ActivityFinalNode, to designate the end of a sequence.
Notation
- MODELING ACTIVITY EDGES
Modeling control fow requires a means to illustrate the movement from one action to the next. The Activity diagram provides two types of ActivityEdge to model fow from one action to the next: a
ControlFlow and an ObjectFlow,
Notation
- MODELING DECISION AND MERGE POINTS
The ControlNode subclass DecisionNode provides the means to specify a point at which the logic must choose between a set of mutually exclusive alternatives. A decision node may have only one incoming activity edge . It may have two or more outgoing
Notation
- MODELING DECISION AND MERGE POINTS
The MergeNode provides a point where a fow of control can return to an existing activity edge to take advantage of the existing fow of control from that point forward. Picture below adds a merge node so that once a user makes one of the provided choices, he is
Notation
- MODELING FORK AND JOIN NODES FOR CONCURRENCY
An Activity diagram may model a process in which parallel processing is available. In fact, any logic sequence that does not require a specifc sequence may potentially be executed in parallel. The Activity diagram uses fork and join notation to model
Notation
- MODELING OBJECT NODES AND OBJECT FLOWS
A fow of control includes two types of fows (activity edges): ControlFlow, discussed earlier in the "Modeling activity edges" section, and ObjectFlow. An ObjectFlow supports passing data (tokens) from one action to another. The data is contained within
Notation
- MODELING ACTION INPUT AND OUTPUT PINS
Actions are behaviors that work with data. Actions create, transform, and delete data, and in doing so, they may pass data produced by one action as input to another action. This process is reminiscent of the classic input-process-
Summary
The UML 1.4 Activity diagram is the UML version of the
classic fowchart . It may be applied to any process, large or
small. Three common applications of Activity diagrams are to explain workfow (a series of Use cases), to explain a single use case, and to explain a method.
Overview
- The Class diagram stands at the center of the object- modeling process. It is the primary diagram for capturing all the rules that govern the defnition and use of objects. As the repository for all the rules it is also the primary source for forward engineering (turning a model into code), and
Class
- A class is very much like a dictionary entry. If our theater application has to manipulate information about events, then we frst need to explain what we mean by the term
event using a class defnition. A UML Class defnition describes a type of object.
Visibility
- Visibility is applied to both attributes and operations in a
class. Since this concept applies equally to attributes and operations, I'll cover the concept here, and then demonstrate how to apply it in the descriptions of attributes and operations that follow.
Class Diagram – Modelling Multiplicity
• Multiplicity , like visibility is a concept used with a number
of UML model elements, most notably with attributes and associations. Multiplicity specifes the number of values that may be associated with a model element.
- Multiplicity is modeled as a value expression. When
Class Diagram – Modelling an Association
- Modeling an association begins by identifying the participating classes. The frst examples we'll discuss use a pair of classes, called a binary association , since this is the most common type of association. We'll cover associations that use more than two participating classes, called n-ary
Class Diagram – Modelling Aggregation
- Aggregation describes a special type of association
designed to help us cope with complexity. In a typical association the participating classes are peers. Each class remains independent of the other and neither class is superior to the other. They simply communicate.
Dependency
• Generalization is the process of organizing the properties
of a set of objects that share the same purpose. You might also hear this type of relationship called inheritance . Many times the terms generalization and inheritance are used synonymously.
Summary
- Regardless of the complexity , class diagram and
each association has to defne its own rules to establish and maintain the integrity of the relationship. Together, these rules defne how the
Sequence Diagram
Tools
References
1. Pender, Tom, UML Bible, John Wiley and Sons, Indianapolis, 2003
Oriented Analysis and Design with UML