Identify ways to derive attributes and extend the sequence diagram to support Data access
Identify Ways to discover Attribute Information
Every piece of information used by a system must be defined as an attribute. Every attribute must be owned by an object.
Even if an attribute is derived and is never actually stored, some object has to own the rules for deriving it.
How do you define an Attribute in Object Oriented Analysis?
Derived attribute indicator: optional
Attribute name: required
Data type: required
Assignment operator and default value: optional
Constraints: optional
Visibility: required before code generation
Class attribute: optional
Define an attribute
Object State and Behaviour
Real-world objects share two characteristics:
They all have 1) state and 2) behavior. Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Bicycles also have state (current gear, current pedal cadence, current speed) and behavior
(changing gear, changing pedal cadence, applying brakes)
State: Every object, at any given point of time would have to have a set of attributes defining its State.
Behavior: Every object based on its state and optionally identity will have particular behavior.
How are Attributes used in the object model?
Every piece of information used in an operation has to belong to an object in your model. The search for the sources of the data is one of the fastest ways to confirm whether or not your model is complete. Another benefit of this approach is the explicit justification for each attribute. That is, when you add attributes just becauseyou think that they describe an object. then the only cost justification is your opinion. But when you add attributes only when they are required in an interaction, then the attribute is implicitly justified because it is required to support a use case. Now, consider the fact that every attribute requires a definition, update operations, edit rules, code, testing, and maintenance support. That is a lot of time and money. Justifying the need for attributes has a direct effect on the cost and time needed to deliver an application.
Analysis refers to the translation of a real-world project description into a software project description. Object-oriented analysis is concerned with developing software engineering requirements and specifications as a system's object model, as opposed to the traditional or functional approaches. This chapter describes first the notion of an object, and then discusses the use case view, considered central to UML. The use case view describes the externally visible behaviour of the system. The next important part of the analysis is the domain modelling that records important system concepts.
We shall introduce the notion of object and object-oriented programming by comparing it with the programming of the abstract data types.
The whole idea of software engineering is to identify and write a software program that solves a real-life problem. However, real-life problems are usually unclear. It is necessary to separate important details from unnecessary details: this is called the abstract view of the problem or the model. This process of modeling is called abstraction. The model defines an abstract view to the problem. This implies that the model focuses only on defining properties of the problem. These properties include the affected data and the identified operations of the problem. As an example, consider the renting of bicycles in a kiosk at East Coast Park. The manager of the renting store comes and asks you to create a software program that deals with the rental of bicycles. Bicycles are real things which can be characterized with many properties. Here are some of them:
number,
size,
date of acquisition,
date of renting,
date of returning,
shape,
color,
renting price per hour,
bell sound, and
the number of wheels.
Certainly, not all of these properties are necessary to solve the renting of bicycles problem. Only some of them are problem specific. Consequently we created a model of a bicycle for the problem. This model only implies properties which are needed to fulfill the requirements of the renting of bicycles, such as number, date of renting, date of returning, renting price per hour. These properties are called the data of the bicycle model.
Operation Parameters and returns
Every argument in an operation must have a source. Does the object that initiates the event own the data? If it does not own the data, then where does it get the data? Look in the class diagram and find the class that should own the data. Update the sequence diagram to show how the initiating object obtained the data from the owning object.
Example: Expanding a sequence diagram for a parameter
Below is the class diagram segment for this example project Purchase Seats use case:
Attributes of the Sequence Diagram:**
Actors and Objects:
The diagram likely includes key actors such as Customer, Purchase, ShowSeat, Ticket, Seat, and PriceTier, as seen in the entity-relationship diagram.
These entities interact through various messages.
Messages and Interactions:
Makes Purchase: A Customer initiates a purchase request.
Reserves Seat: The Purchase object interacts with ShowSeat to reserve a seat.
Locates Seat: The ShowSeat object references a Seat location.
Issues Ticket: If the seat is reserved, a Ticket might be issued.
Prices Seat: The PriceTier entity determines the price of a ShowSeat.
Multiplicity and Associations:
1 to Many Relationship: A Customer can make multiple Purchases.
1 to Many Relationship: A Purchase can reserve multiple ShowSeats.
1 to 1 Relationship: A ShowSeat is linked to one Seat but can be priced based on different PriceTiers.
0 to 1 Relationship: A Ticket may or may not be issued for a reserved seat.
Arrows Indicating Messages Flow:
The arrows indicate synchronous or asynchronous messages exchanged between objects.
Some interactions could involve conditions (e.g., a ticket is issued only if a seat is successfully reserved).
Initial sequence diagram for the Purchase Seats use case
The initial sequence diagram for the Purchase Seats use case:
Example of expanding a sequence diagram for a parameter
Operation Returns
The same logic applies to operation returns. Does the responding object own this data? If it does not own the data, then where does the object get it? Does the object derive the data using another of its own operations? Does the object have to look up the value using other objects? Update the sequence diagram to add the object(s) that own the data and show how the original object obtained the data.
An example of expanding a Sequence Diagram for a return
Using the course project as an example, when a customer wants to buy show seats, he or she must provide a price type for each seat in order for the system to know which price to charge, that is, adult, student, senior citizen, or child. For instance, I could buy four tickets, two for adults and two for children:
The Customer is the only object that knows what price type should be used to price each seat.
To find the price for ShowSeat, ShowSeat must ask for the price from PriceTier. When asking for the price, ShowSeat must provide a price type so that PriceTier can decide which price to return.
Example of finding the source of a return value
Each time you add a new interaction, you iterate through the modeling process:
Evaluate the class diagram to find the objects that participate in the interaction.
Add the new object(s).
Identify the new events.
Reevaluate the purpose of the participating objects.
Convert the events to operations.
Convert the information to attributes.
Assign ownership of the attributes.
Repeat until all parameters and returns are accounted for.