Object Oriented Analysis Notes
Unit 2: Object Oriented Analysis (8 Hours)
Chapter Contents
2.1 Building Conceptual Model
Domain Analysis
Domain Model (Conceptual Model)
Domain Model as a Visual Dictionary
Conceptual Class
Creating a Domain Model
Reuse or modifying existing models
Category List
Noun Phrase Analysis
POS (Point of Sale)
Simplified Banking System
Math Trainer
Simplified Library System
2.2 Adding Association and Attributes
Guideline to Name Association
Applying UML
Roles
Multiplicity
Multiple Association Between two classes
Guideline: Finding Association with Common Associations List
Example: Associations in Domain Models
Guideline to add Attributes
Attributes Notation (Syntax for Attribute)
Guideline to record Attribute Requirement
Derived Attributes
Data type attribute on Domain Model
2.3 Representation of System Behavior
System Sequence Diagram (SSD)
Introduction
Use case to SSD
Naming System Events and Operations
Operation Contract
Object Constraint Language (OCL)
Introduction to Model Building
UML (Unified Modeling Language) is a visual modeling language.
"A picture is worth a thousand words."
Unified Modeling Language is a language that provides a vocabulary and the rules for combining words for the purpose of communication.
A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system.
UML is a standard language for software blueprints.
UML is used to:
Document designs, design patterns / frameworks
Represent different views/aspects of design – visualize and construct designs
Provide a next-to-precise, common language – specify visually for the benefit of analysis, discussion, comprehension…
Defining Model
A model is a simplification of reality.
A model provides the blueprints of a system.
A good model includes elements that have broad effort and omits minor elements that are not relevant to the given level of abstraction.
Every system may be described from different aspects using different models.
Type of Modeling
Object modeling
Develops the static structure of the software system in terms of objects.
Identifies the objects, the classes into which the objects can be grouped into, and the relationships between the objects.
Dynamic modeling
Examines behavior with respect to time and external changes.
Describes how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world.
Functional modeling
Shows the processes that are performed within an object and how the data changes as it moves between methods.
Types of Models
Object model
Dynamic model
Functional model
Importance of Model Building
A model is a simplification at some level of abstraction.
Models are built to better understand the systems being developed.
Uses:
To help visualize
To specify structure or behavior
To provide template for building system
To document decisions made
2.1 Building Conceptual Model
A conceptual model is a representation of a system.
It consists of concepts used to help people know, understand, or simulate a subject the model represents.
A physical model focuses on a physical object such as a toy model that may be assembled and made to work like the object it represents.
Conceptual models are abstract, psychological representations of how tasks should be carried out.
A conceptual model is the model of an application that the designers want users to understand.
By using the software and perhaps reading its documentation, users build a model in their minds of how it works.
People use conceptual models as a way of systematizing processes.
In Object oriented data modeling, domain model, use case diagram, sequence diagram are the best examples of conceptual model.
Conceptual Data Modeling
A conceptual data model is a representation of organizational data.
The purpose of a conceptual data model is to show as many rules about the meaning and interrelationships among data as possible, independent of any database management system or other implementation considerations.
In structural data modeling:
Entity-relationship (E-R) data models are commonly used diagrams that show how data are organized in an information system.
Domain Model
A domain model is a visual representation of conceptual classes or real world objects in a domain of interest.
They have also been called conceptual models, domain object models and analysis object models.
A domain model is a package containing class and activity diagrams.
Domain Model representation
Identifying a rich set of objects or conceptual classes is at the heart of object-oriented analysis, and well worth the effort in terms of payoff during the design and implementation work.
Using UML notation, a domain model is illustrated with a set of class diagrams in which no operations are defined.
Domain objects or conceptual classes.
Associations between conceptual classes
Attributes or conceptual classes
How to Create a Domain Model
Bounded by the current iteration requirements under design:
Find the conceptual classes.
Draw them as classes in a UML class diagram.
Add associations and attributes.
Conceptual Classes
The domain model illustrates conceptual classes or vocabulary in the domain.
Informally, a conceptual class is an idea, thing or object.
More formally a conceptual class may be considered in terms of its symbol, intension and extension.
Symbol: words or images representing a conceptual class.
Intension: the definition of a conceptual class.
Extension: the set of examples to which the conceptual class applies.
“Intension” indicates the internal content of a term or concept that constitutes its formal definition.
“Extension” indicates its range of applicability by naming the particular objects that it denotes.
For example, consider the conceptual class for the event of a purchase transaction.
Name it by the (English) symbol Sale.
The intension of a Sale may state that it "represents the event of a purchase transaction, and has a date and time. "
The extension of Sale is all the examples of sales; in other words, the set of all sale instances in the universe.
Three Strategies to Find Conceptual Classes
Reu se or modify existing models
This is the first, best, and usually easiest approach.
There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth.
Reusing existing models is excellent, but outside our scope.
Use a category list
The second method, using a category list, is also useful
Identify noun phrases
Conceptual Class Category Examples
Roles of people or organizations:
Cashier, Customer, Store, Monopoly Player
Actors in the use case:
Passenger, Airline
Place of transaction; place of service:
Airport, Plane, Seat
Noteworthy events:
Sale, Payment, MonopolyGame, Flight
Physical objects:
Item, Register, Board, Piece, Die, Airplane, Stone
Descriptions of things:
Product Description, FlightDescription
Catalogs:
Product Catalog, FlightCatalog
Containers of things:
Store, Bin, Board, Airplane
Things in a container:
Item, Square (in a Board), Passenger
Other collaborating systems:
CreditAuthorizationSystem, AirTrafficControl
Records of finance, work, contracts, legal matters:
Receipt, Ledger, MaintenanceLog
Financial instruments:
Cash, Check, LineOfCredit, TicketCredit
Schedules, manuals, documents that are regularly referred
DailyPriceChangeList, RepairSchedule
Finding Conceptual Classes with Noun Phrase Identification
Another useful technique is linguistic analysis:
Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes.
Nevertheless, linguistic analysis is another source of inspiration. The fully dressed use cases are an excellent description to draw from for this analysis.
For example, the current scenario of the Process Sale use case can be used.
POS (Point of sale) is a place where a customer executes the payment for goods or services and where sales taxes may become payable.
Possible Conceptual Classes List for POS Domain
Sales
Store
Item/Product
Cashier
Customer
Manager
Payment
Product catalog
Product specification
Register
Ledger/Record/Log
Bill
Drawing Conceptual Classes/ Domain model
Customer
CusId Cusname
Cusaddress Cuscontact
Product
pId Pname
Rate
Quantity
Payment
Pay_Id
Time
Date
Method
Pays 1 1..* Buys 1 1..* Related 1 1
Similarly, we can add other classes here.
Domain Model Refinement
Refinement of Domain Model is done with,
Generalization
Specialization
Conceptual Class Hierarchies
1. Generalization:
Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass (specialized concept) relationships.
Identifying a superclass and subclasses is of value in a domain model because their presence allows us to understand concepts in more general, refined and abstract terms.
Generalization is the process of extracting common properties from a set of entities and create a generalized entity from it.
It is a bottom-up approach in which two or more entities can be generalized to a higher level entity if they have some attributes in common.
In the generalization process, the common characteristics of classes are combined to form a class in a higher level of hierarchy, i.e., subclasses are combined to form a generalized super-class. It represents an “is – a – kind – of” relationship. For example, “car is a kind of land vehicle”, or “ship is a kind of water vehicle”.
2. Specialization
Specialization is the reverse process of generalization. Here, the distinguishing features of groups of objects are used to form specialized classes from existing classes.
It can be said that the subclasses are the specialized versions of the super-class.
In specialization, an entity is divided into sub-entities based on their characteristics.
It is a top-down approach where higher level entity is specialized into two or more lower level entities.
Figure: Generalization
Vehicle
Land Water Air
Car Bus Ship Boat Aeroplane Helicopter
Figure: Specialization
PERSON
PNAME PADD
FACULTY STUDENT
S_FEE
is A
Figure: Specialization
EMPLOYEE
ENAME ESALARY
TESTER DEVELOPER
TES_TYPE
is A
Aggregation:
An ER diagram is not capable of representing relationship between an entity and a relationship which may be required in some scenarios.
In those cases, a relationship with its corresponding entities is aggregated into a higher level entity.
Figure: Aggregation example
Lines: link the attributes to entity sets and entity sets to relationship sets. Doubles lines: indicate the total participation of an entity in a relationship set.
3. Conceptual Class Hierarchies
Identify domain super-classes and subclasses relevant to the current iteration, and illustrate them in the Domain Model.
Conceptual Super-classes and Subclasses:
A conceptual super class definition is more general or encompassing than a subclass definition. For example, consider the superclass Payment and its subclasses (CashPayment, and so on).
Assume the definition of Payment is that it represents the transaction of transferring money (not necessarily cash) for a purchase from one party to another, and that all payments have an amount of money transferred.
All members of a conceptual subclass set are members of their superclass set.
For example, in terms of set membership, all instances of the set Credit Payment are also members of the set Payment. In a Venn diagram, this is shown as in following Fig
Subclass Conformance : When a class hierarchy is created, statements about super-classes that apply to subclasses are made.
For example, the following Figure states that all Payments have an amount and are associated with a Sale.
100% Rule
100% of the conceptual superclass's definition should be applicable to the subclass.
The subclass must conform to 100% of the superclass’s:
attributes
associations
Finding Associations
An association is a relationship between instances of classes that indicates some interesting and meaningful connection.
An association is represented as a line between classes with an association name.
The association is inherently bidirectional meaning that form instances of their class, logical traversal to there is possible
The ends of an association may contain a multiplicity expression indicating the numerical relationship between instances of the classes.
If the arrow is not present, the convention is to read the association from left to right or top to bottom, although the UML does not make this a rule.
How to Name an Association in UML
Name an association based on a ClassName-VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful.
Association names should start with a capital letter, since an association represents a classifier of links between instances. Two common and equally legal formats for a compound association name are:
Records-current
RecordsCurrent
Simple association names such as "Has" or "Uses" are usually poor, as they seldom enhance our understanding of the domain.
For example,
Sale Paid-by CashPayment
bad example (doesn't enhance meaning): Sale Uses CashPayment
Player Is-on Square
bad example (doesn't enhance meaning): Player Has Square
Multiple Associations Between Two Classes:
Two classes may have multiple associations between them in a UML class diagram; this is not uncommon.
There is no outstanding example in the POS or Monopoly case study, but an example from the domain of the airline is the relationships between a Flight (or perhaps more precisely, a FlightLeg) and an Airport (see Figure ); the flying-to and flying-from associations are distinctly different relationships, which should be shown separately.
Roles
Each end of an association is called a role.
Roles may optionally have:
multiplicity expression name
navigability
Multiplicity: Multiplicity defines how many instances of a class A can be associated with one instance of a class B
For example, a single instance of a Store can be associated with "many" (zero or more, indicated by the *) Item instances. Some examples of multiplicity expressions are shown in Figure
Cardinalities Notation
*Notation: *Minimum Instances: Maximum Instances
Exactly One: 1: 1
Zero or one: 0: 1
One or more: 1: Many (>1)
Zero or many: 0: Many (>1)
More than one: >1: >1
Exactly One(Mandatory One/One and only One): 1 1: 1 1..: 1..
1: 1..*
Zero or one(Optional or 1): 0: 1
One or more(Mandatory or many): 1: Many (>1)
Zero or many: 0: Many (>1)
Many (>1): >1: >1
Associations in the Domain Models :Case Study: Next-Gen POS
Finding Attributes
An attribute is a logical data value of an object.
Use to identify those attributes of conceptual classes that are needed to satisfy information requirements of the current scenario under development.
Most attributes can be represented by simple data types.
An attributes by part of the state of an object.
Complex concepts should be related through associations, not through attributes.
Attributes are shows in the second component of the class box.
For example, a receipt (which reports the information of a sale) in the Process Sale use case normally includes a date and time, the store name and address, and the cashier ID, among many other things.
Therefore,
Sale needs a dateTime attribute.
Store needs a name and address.
Cashier needs an ID.
Components of Domain Model
An domain model has three main components:
Class
Attributes/characteristics
Relationship
Attributes
An attribute describes the property of an entity.
Example: Class: Student Attributes: (stdId , stdName , faculty , address)
Attribute-ER Diagram
An attribute describes the property of an entity.
It is represented by Oval in an ER diagram.
Example: Student(stdId , stdName , faculty , address)
There are four types of attributes:
a. Multivalued attribute
b. Derived attribute
c. Key attribute
d. Composite attribute
Multivalued attribute
Can hold multiple values .
Represented by double ovals in an ER Diagram.
Example :
An employee can have more than one phone numbers, so the phone number attribute is multivalued. Employee empId empName phoneNo designation
Derived attribute
One whose value is dynamic and derived from another attribute.
*Represented by dashed oval in an ER Diagram.
*For example ―Customer’s age is a derived attribute as it changes over time and can be derived from another attribute (Date of birth). Customer custId custName age DOB
Key /Identifier attribute
*An attribute or group of attributes that can uniquely identifies each entity instance.
*Represented by oval same as other attributes however the text of key attribute is underlined.
*For example, student roll number can uniquely identify a student from a set of students. Student RollNo Name DOB Faculty
Types of key attributes: [Assignment]
*Super key
*Candidate key
Composite/compound/concatenated key
Primary key
Alternate key
Foreign key
Composite Attribute
*An attribute that can be split into components is a composite attribute.
*Example:
The address can be further split into house number, street number, city, state, country, and pin code.
*The name can also be split into first name middle name, and last name.
Relationship
*Relationship defines how entities are related to each other.
*An association between instances of one or more entities .
*Represented by diamond shape in ER Diagram.
*All entities participating in relationship are connected by a line.
*Example: Bank Account has BankId BankName Bank_Branch accountId accountType accountName
2.3 Representation of System Behavior
a)System Sequence Diagram(SSD)
i) Introduction
ii) Use case to SSD
b)Naming System Events and Operations
c) Operation Contract
d) Object Constraint Language (OCL)
Unified Modeling Language(UML)
*A language for specifying ,visualizing and constructing the artifacts of the software system as well as for business modeling.
*Set of modeling conventions that is used t describe a software system in terms of objects.
*The notation is useful for graphically representing the object oriented analysis and design.
*UML diagrams can be categorized into TWO types:
*Structural diagrams
*Behavioral diagrams
Structural diagrams
*Represents static aspect of the system.
*Represents those parts of the diagram which forms the main structure of the system in terms of classes ,objects ,interfaces , components and units.
*Class diagrams ,object digrams,component diagrams and deployment diagram are the example of structural diagrams.
Behavioral diagrams
*Represents dynamic aspect of the system.
*Captures the behavior of the system with respect to time and external changes .
*Use case diagram ,sequence diagram ,collaboration diagram ,activity diagram and state diagram are the examples of behavioral diagram.
*UML was designed by THREE experts:
*Grady Boach - Boach method.
*James Rumbaugh - Object Modeling Technique(OMT)
*Ivan Jacobson
Use case Diagram
*Summarizes the details of a system’s user also known as actors and their interaction with the system.
*focuses on what the system does.
*Captures the requirements of the system ,if the system requirements changes during the life cycle , those changes will be visible in use case model.
*Consisting of use cases and actors.
a. Actors
*An external entity that interacts with the system.
*Represents role which may include human users , external hardware or other system.
*Is usually drawn as a named stick figure or alternatively as a class rectangle with > keyword.
<> Customer Customer or
b. Use cases
*A single unit of meaningful work.
*Provides a high level view of behavior observable someone or something outside the system.
*Can be represented by a ellipse /oval. Withdraw amount
*The notation for using a use case is connecting line with an arrowhead showing direction control.
Bank Management System Withdraw amount Fig: indicates that the actor customer uses the withdraw amount use case
Some Examples
Employee Management System
Hire employee
Manager
Produce management reports
Monitor work progress
Applicant
Librarian
Library Management System
Request for Book
Issue Book
Manage book
Manage members
Member
Relationship Between use cases
*Use cases many participate in relationship with other use cases.
1.Association between actor and use case.
2.Generalization of an actor.
3.Extend between two use cases.
4.Include between two use cases.
5.Generalization of use case.
1.Association between the actor and use case
*An actor must be associated with at least one use case.
*An actor can be associated with multiple use cases.
*Multiple actors can be associated with a single use case.
Customer initiates\nBank Management System
Opens Account
Deposit Amount
Check Balance
withdraw amount
Bank Employee
2.Generalization of an actor
*One actor can inherit the role of other actor.
*The descendant inherits all the use cases of the ancestor.
User Student
<
Teacher
Library Management System
Log in
Issue book
Return book
Manages
Librarian
3.Extend relationship between the use cases
*As the name implies, it extends the base use case and adds more functionality to the system.
*Useful for a complex software system.Customer |
Order
Order Management System
<
Special Order
<
Normal Order
4.Include relationship between two use cases
*Shows that the behavior of the included use cases is part of the including(base) use case.
*Reuses the common actions across the multiple use cases.
*In some situations, this is done to simplify complex behaviors.
Bank Management System
Opens Account
Deposit Amount
Customer
Bank Employee
Calculate Bonus
<
Withdraw Amount
<
Update Amount
<
Few things need to be considered when using the relationship:
*The base use case is incomplete without the included use case.
*The included use case is mandatory and not optional.
Online Web Storeinitiates
Make a purchase
Customer
__
Verify Credit
Card
Admin
Calculate Bonus
<
Withdraw Amount
<
Update Amount
5.Generalization of use case
Similar to generalization of an actor.
The behavior of ancestor is inherited by the descendant.
Used when there is a common behavior between two use cases and also specialized behavior specific to each other.
Online Web Store
Make a
paymentAdmin Online Web Storeinitiates
Customer
Make a payment
Pay via credit cards
Cash On Delivery
Customer Admin
Sequence Diagram/ System sequence diagram
*The most commonly used interaction diagram.
*It depicts interaction between objects in a sequential order i.e. the order in which these interactions take place.
*It describes how and in what order the objects in a system function.
*These diagrams are widely used by businessmen and software developers to document and understand requirements for new and existing systems.
*Purpose of a Sequence Diagram
*To model high-level interaction among active objects within a system.
*To model interaction among objects inside a collaboration realizing a use case.
*It either models generic interactions or some certain instances of interaction.
UML notation in Sequence diagram
1.Actors : – Represents a type of role where it interacts with the system and its objects.
– An actor is always outside the scope of the system .
2.Class roles or participants or objects:
*A named element which depicts an individual participant in a sequence diagram.
Represented by Class roles or participants or objects
Lifeline :
– a vertical dashed line ,indicating the presence of an object over the time.
*each instance in a sequence diagram is represented by a lifeline.
Object name :
Class name
O1 : ORDER Life line
2.Activation or execution occurrence:
*Represents the time period during which an object performs an operations.
Represented by :
O1 : ORDER Activation
2.Messages:
*Communication between objects is depicted using messages.
*The messages appear in a sequential order on the lifeline. We represent messages using arrows.
*Lifelines and messages form the core of a sequence diagram .
*Messages can be broadly classified into the following categories:
*Synchronous
*Asynchronous Messages
*Create message
*Delete Message
*Self Message
*Reply Message
*Found Message
*Lost Message
Synchronous messages :
*A synchronous message waits for a reply before the interaction can move forward.
*We use a solid arrow head to represent a synchronous message.
*The caller continues only when it knows that the receiver has processed the previous message i.e. it receives a reply message.
Asynchronous Messages :
*An asynchronous message does not wait for a reply from the receiver.
*The interaction moves forward irrespective of the receiver processing the previous message or not.
*We use a lined arrow head to represent an asynchronous message.
Create message :
*We use a Create message to instantiate a new object in the sequence diagram.
*There are situations when a particular message call requires the creation of an object.
*It is represented with a dotted arrow and create word labeled on it to specify that it is the create Message symbol.
Delete Message :
*We use a Delete Message to delete an object.
*It destroys the occurrence of the object in the system.
*It is represented by an arrow terminating with a x.
Self Message :
*Certain scenarios might arise where the object needs to send a message to itself.
*Such messages are called Self Messages and are represented with a U shaped arrow.
Reply Message :
*Reply messages are used to show the message being sent from the receiver to the sender.
*We represent a return/reply message using an open arrowhead with a dotted line.
Found Message :
*A Found message is used to represent a scenario where an unknown source sends the message.
*It is represented using an arrow directed towards a lifeline from an end point.
For example: Consider the scenario of a hardware failure.
Lost Message :
*A Lost message is used to represent a scenario where the recipient is not known to the system.
*It is represented using an arrow directed towards an end point from a lifeline.
For example: Consider a scenario where a warning is generated.
Guards :
*To model conditions we use guards in UML.
*They are used when we need to restrict the flow of messages on the pretext of a condition being met.
Figure: A sequence diagram for an emotion based music player.
User
. OpenApplication
Access
Webcam DeviceDatabase
3 Get Photo
4: Detect face
Retrieve Mood
9: Generated Playlist: Playlist
10: Playlist
7: Display Mood
11: Retrieve Music
Figure: Sequence diagram for Online Shopping
Customer Item Purchase
interface interfaceBrowse item query iterm checkout
Normal orderget selected item <>>
authorizationauthorization purchase item get selected item purchase info id online shopping
purchase item
Summary: Notations of a Sequence Diagram
*Lifeline: An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the top of the diagram.
*Actor: A role played by an entity that interacts with the subject is called as an actor.
*Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an operation is performed by an element, such that the top and the bottom of the rectangle is associated with the initiation and the completion time, each respectively.
The messages depict the interaction between the objects and are represented by arrows. They are in the sequential order on the lifeline. The core of the sequence diagram is formed by messages and lifelines.
*Following are types of messages enlisted below:
*Call Message: It defines a particular communication between the lifelines of an interaction, which represents that the target lifeline has invoked an operation.Reply Message: It defines a particular communication between the lifelines of interaction that represent the flow of information from the receiver of the corresponding caller message.
Self Message: It describes a communication, particularly between the lifelines of an interaction that represents a message of the same lifeline, has been invoked.
Recursive Message: A self message sent for recursive purpose is called a recursive message. In other words, it can be said that the recursive message is a special case of the self message as it represents the recursive calls.
Create Message: It describes a communication, particularly between the lifelines of an interaction describing that the target (lifeline) has been instantiated.
Destroy Message: It describes a communication, particularly between the lifelines of an interaction that depicts a request to destroy the lifecycle of the target.
Duration Message: It describes a communication particularly between the lifelines of an interaction, which portrays the time passage of the message while modeling a system.
window: UłaChain: Hotel ChainaHotel
Stopped
1: makeReservation
l.J: makeReservation
loop
[each day]
1 available(roomld, date): isRoomSel
1.12 aReservation: Reservation
aNotice: Confirmation
alt
[isRoom=true]