OOP Concepts in Banking Systems

• Software Modeling and Analysis (CS 284) is taught at Taibah University in Yanbu, Saudi Arabia

Application and Solution Domain

• Application Domain in requirements analysis refers to the environment where the system operates.
• Solution Domain includes the available technologies to build the system in system and objet design
• UML Package is the Application Domain Model
• System Model consists of SummaryDisplay, TrafficControl, Aircraft, FlightPlanDatabase, FlightPlan, MapDisplay, TrafficController, and Airport

What is UML?

• UML (Unified Modeling Language) is an emerging standard to model object-oriented software.
• UML resulted from the convergence of notations from three leading object-oriented methods: OMT (James Rumbaugh), OOSE (Ivar Jacobson), Booch (Grady Booch)
• UML is supported by several CASE tools such as Rational ROSE and TogetherJ

UML: First Pass

• About 20% of UML can model 80% of problems
• Use case Diagrams describe the system's functional behavior as seen by the user.
• Class diagrams describe the static structure of the system: Objects, Attributes, Associations
• Sequence diagrams describe the dynamic behavior between actors and the system and between objects of the system.
• Statechart diagrams describe the dynamic behavior of an individual object (essentially a finite state automaton)
• Activity Diagrams model the dynamic behavior of a system and workflow.

UML Core Conventions

• Rectangles represent classes or instances.
• Ovals represent functions or use cases.
• Instances are denoted with underlined names, such as myWatch:SimpleWatch or Joe:Firefighter.
• Types are denoted with non underlined names, for example SimpleWatch or Firefighter
• Diagrams are graphs with nodes representing entities and arcs as the relationships between entities.

Use Case Diagrams

• Use during requirements elicitation to represent external behavior
• Actors represent roles, a type of user of the system
• Use cases represent a sequence of interaction for functionality
• A use case model is the set of all use cases providing a complete description of the functionality of a system and its environment.

Actors

• An actor models an external entity communicating with the system: User, External system, and Physical environment
• An actor has a unique name and an optional description.
• Examples include a passenger on a train or a GPS satellite providing the system with GPS coordinates.

Use Case

• A use case represents a class of functionality provided by the system as an event flow.
• A use case consists of a unique name, participating actors, entry conditions, flow of events, exit conditions, and special requirement.

Use Case Diagram: Example

• Name: Purchase ticket
• Participating actor: Passenger
• Entry condition: Passenger standing in front of the ticket distributor
• Entry condition: Passenger has sufficient money to purchase ticket.
• Exit condition: Passenger has ticket.
• Event flow: Passenger selects the number of zones, the distributor displays the amount due, the passenger inserts money, the distributor returns change, and the distributor issues the ticket.
• Use case diagrams represent external behavior
• Use case descriptions provide the details of the model, not the diagrams themselves.
• All use cases need to be described for the model to be useful.

Class Diagrams

• Class diagrams represent the structure of the system.
• Used during requirements analysis to model problem domain concepts such as TarifSchedule which encompasses Enumeration getZones() and Price getPrice(Zone)
• Used during system design to model subsystems and interfaces
• Used during object design to model classes, such as Trip which covers zone:Zone and Price: Price

Classes

• A class represents a concept and encapsulates state (attributes) and behavior (operations).
• An attribute has a type, and an operation has a signature.
• The class name is the only mandatory information. Example shown is TarifSchedule class encompassing zone2price attributes, and getZones() and getPrice() operations

Instances

• An instance represents a phenomenon.
• The name of an instance is underlined and can contain the class of the instance.
• Attributes are represented with their values, for example tarif 1974:TarifSchedule including zone2price

Actor vs Instances

• Actor: An entity outside the system interacting with it, like a "Passenger"
• Class: An abstraction modeling an entity in the problem domain inside the system, like "User"
• Object: A specific instance of a class, such as "Joe, the passenger who is purchasing a ticket".

Associations

• Associations denote relationships between classes regarding TariffSchedule and Enumeration getZones() & Price getPrice(Zone)
• The multiplicity of an association end denotes how many objects the source object can reference, relating TarifSchedule with TripLeg which covers Price and Zone

Associations (multiplicity)

• One-to-one association: A Country has-capital City with respective names
• One-to-many association: Connecting Polygon with Points
• Many-to-Many Associations: Relates StockExchange with Companies

Aggregation

• Aggregation denotes a "consists of" hierarchy where an aggregate is the parent class, and components are the children.
• A solid diamond denotes a composition, a strong form of aggregation where components cannot exist without the aggregate.

Inheritance

• Children classes inherit the attributes and operations of the parent class
• Inheritance simplifies the model by eliminating redundancy, for example Button can inherit from CancelButton & ZoneButton

Object Modeling in Practice: Class Identification

• Naming is important when identifying classes
• Models may include Betrag, CustomerId, Deposit(), Withdraw(),and GetBalance()
• Related classes can be Foo, Dada, Account

Object Modeling in Practice ctd

• Includes related items such as Banks, Account & Customer
• Banks consist of Name
• Accounts Consist of Betrag, AccountId, Deposit(), Withdraw(), GetBalance()
• Customers consist of Name & CustomerId
• Find new object and iterate on names, attributes and methods

Object Modeling in Practice: A Banking System

• Finds new objects, iterates, finds association between objects, labels the associations, and determines the multiplicity of the associations
• Related items may include Banks, Account & Customer
• Banks consist of Name
• Accounts Consist of Betrag, AccountId, Deposit(), Withdraw(), GetBalance()
• Customers consist of Name & CustomerId

Practice Object Modeling: Iterate, Categorize!

• Diagram illustrating connections between Banks, Customer Class Diagram, Savings Account, Checking Account, Withdraw() Mortgage Account, Account Class Diagram

Packages

• Packages are a UML mechanism for organizing elements, mainly not an application domain concept
• Packages are the basic grouping construct to organize UML models for readability such as Notification, DispatcherInterface, and IncidentManagement
• A complex system is decomposed into subsystems, where each subsystem is modeled as a package

UML sequence diagrams

• Used during requirements analysis to refine use case descriptions and discover additional objects
• Used during system design to refine subsystem interfaces.
• Classes are represented by columns, Messages by arrows, Activations by narrow rectangles, and Lifelines by dashed lines.
• UML sequence diagrams represent behavior in terms of interactions, finding missing objects
• They complement class diagrams which represent the structure of classes

Nested messages

• Source of an arrow indicates the activation that sent the message.
• Activation lasts as long as all the nested activations.
• Horizontal dashed arrows indicate data flow.
• Vertical dashed lines indicate lifelines.

Iteration & condition

• Iteration is denoted by a * preceding the message name
• Condition is denoted by a boolean expression in [] before the message name

Creation and destruction

• Creation is denoted by a message arrow pointing to the object.
• Destruction is denoted by an X mark at the end of the destruction activation.
• In garbage collection environments, destruction can denote the end of the useful life of an object.

State Chart Diagrams

• Represents behavior as States with button transitions and states
• Includes Event, initial state, Transition, State, and final state

Activity Diagrams

• Shows flow control within a system with Actions related to handling, documenting and Archiving an incident
• An activity diagram is a special case of a state chart diagram in which states are activities ("functions")
• Includes Action state that cannot be decomposed any further, and happens instantly
• Includes Activity state that can be decomposed further, and is modeled by another activity diagram

Activity Diagrams are the same Incident differently

• Activity Diagram for Incident is similar to Moore
• Statechart Diagram for Incident is similar to Mealy Automaton

Activity Diagram: Modeling Decisions

• Illustrates relationship between opening an incident, which is classified as low or highPriority, and whether the system is notified of Police or Fire Chief

Activity Diagrams: Modeling Concurrency

• Relates to synchronization of multiple activities and splitting of the flow of control into multiple threads
• Includes Splitting and Synchronization
• Covers the flow of Open incident to allocate resources, coordinate resources and document incident, and archive incident

Activity Diagrams: Swimlanes

• Actions can be grouped into swimlanes such as dispatcher and field officers to show which object or subsystem implements the actions.

UML Summary

• UML provides a wide variety of notations for representing many aspects of software development
• UML can be powerful, but complex language
• UML can be improperly used to generate unreadable models due to overuse of exotic features
• For now focus on Functional Model, Object Model, and Dynamic model.

Functional model: use case diagram Object model: class diagram Dynamic model: sequence diagrams, statechart and activity diagrams

Appendix: Additional Slides

• Consisting of UML definitions relating what constitutes a model, and also its relation to reality

This quiz covers object-oriented programming (OOP) concepts within the context of banking systems. It tests understanding of inheritance, encapsulation, and relationships between classes such as Account, SavingsAccount, and IncidentManagement. Key areas include the use of AccountId, packages, and interfaces.