Case Study In OOAD and UML: Case Studies in Software Architecture & Design, #1

By Ramki

It is of great value for every Programmer / Developer-Designer / DevOps Professional to be conversant with Object Oriented Analysis and Design. The widely accepted standard for it is UML, Unified Modelling Language. Such a knowledge enhances the value of every software professional by getting into a reasonable depth of these two – OOAD and UML. This book presents the same almost like a story, with a popular Case Study. You will reach a degree of good understanding as you finish this book. Many illustrations make the reading process to be a fun sport.

• Language: English
• Publisher: Ramki
• Release date: Dec 25, 2023
• ISBN: 9798223059080

Ramki

Author :   Ramakrishnan N  (Ramki)   Near 50 years of experience in Software Architecture, Enterprise Architecture Design (UML, others) and Patterns (GOF, Microservices and many more), SOA to Microservices to Cloud Native and few State-of-Art technologies.    Consultant and High-end Trainer to many prestigious International Enterprises   Certified in TOGAF 9 and TOGAF 10   Based at Bangalore, India.       Reachable through : [e-mail]

Book preview

Basic idea of Object Orientation and UML

Girl playing football vector image OOAD – Object Oriented Analysis and Design is based on the principle of Object Orientation.

––––––––

Bunch of random numbers AN OBJECT IS A SET OF

related

Data (Field Attributes)

and

Functions (methods)

A yellow rectangular sign with blue text Description automatically generated

––––––––

Vector image of billiard ball Every Object has IDENTITY

Every object is unique, in that it is distinctly identified by an object identifier

––––––––

Connect the dots mouse vector An object has Field Attributes

(the Data Members of Object)

A close-up of a card Description automatically generatedA close-up of a card Description automatically generated

Vector graphics of black and white leaf ornament Every object has Behavior

(the Functionality of each Object)   

A yellow rectangle with pink text Description automatically generated

The points above indicate that :

Objects occupy data area of memory. This is where they hold individual values of each of their Field Attributes.

Objects would expose methods, (say functions) which are invoked by other objects, so that their behavior is exhibited. The behavior may be to return a value, to do some processing with the fields of the object and so on.

Vector image of blue and gray database symbol Sometimes such a state change is also written into the database, as a reaction of the method making such a change. In more complex design, the method of an object would invoke another method on another object during some part of its logic. In distributed programming, the other object may not even be in the same machine’s RAM.

––––––––

Can objects work alone in a System ?

No. they need to co-operate.

Computer users

A System is a society of co-operating objects.

People in a car It is our attempt to control the behavior

of one object from another  

that makes us prepare  

applications out of OOPS

– Object Oriented Programming Systems

SOFTWARE OBJECT

It is a small piece of software.

Not the whole Application

A software object contains

values and functions.

which only relate to

an unit of Representation

A software object represents just

one ROLE

played by the system

Many such ROLEs (Objects)

make a System.

In simple situations :

UI object would invoke method on some worker object on the server side 

If it is a reporting or querying kind of scenario,

some data will come back to the UI as return value.

If it is state change and transaction processing scenario, values of a one or more objects will change, and some or all may get persisted in a data store.

If the UI object is part of a Web application, it may be of HTML flavor and be on the client side.

The worker object will be on the server side

And could of a flavor like Servlet / ASP Page / other Web application on the server and so on.

You should extend the OO imagination to scenarios other than Web applications.

It would be a client – server – database with Thick client

It could be an embedded scenario, but as a OO Project

For example mobile applications have many objects in them.

When we get into molding such projects, we need an OO methodology approach

We will look into such a methodology, that too with a Case Study

––––––––

Every complex system can best be approached for

understanding,

modeling and

refinement purposes, 

through a small set of nearly independent views of a model.

UML – Unified Modeling Language is a unification of : OMT – James Rambaugh, methodology of Booch and OOSE – Iver Jacobson and many more inputs beyond the three amigos. It is a specification that will lead us to modelling as per a suitable methodology chosen by us.

It may not be possible to understand a system, especially a software system, through a single View. No single View is sufficient. So UML comes with many Views (many Diagrams) so that we can choose the ones necessary to model and depict our software system.

The best models are connected to reality. Since software is a run-time version of some (say business) scenario, we need to model it as close to the real (business) system as possible. Hence the need for a Modeling Language, which can describe the design solution based on due analysis.  

United world icons The Unified Modeling Language (UML) is a

language for specifying, constructing, visualizing,

and documenting the artifacts of a

software intensive system.

Specifying : How should design be structured ? Say a Class Diagram is one among a few which render help in this direction.

Constructing : How to convert the design into language code, such that when it is run, the objects are created and start invoking methods as per described flow. Dynamic and Flow Diagrams such as Sequence Diagram are examples of this.

Visualizing : A Diagram based approach, where careful examination of a Diagram and analyzing the same would lead to validation of some facts and possible assumptions such that it is dry run of the execution itself.

Documenting : With UML, as we proceed though OOAD – Object Oriented Analysis and Design phases, the documentation automatically evolves. There is no need to carryout analysis separately, design separately and then get into documenting the same.

People sketch in a circle The key point to note : UML is appreciated in software intensive systems.  Sometimes developers only look into their own limited role in the project and try to apply a complete UML based process over the same. If my job is only to design the HTML and front end portion of a Web project, I am only part of a software intensive project. The UML should be applied to the whole project and it will make sense to me. If I try to isolate UML only for my UI portion, there will be no charm with it.

––––––––

Modeling Language

A model is a description of a physical system with a certain purpose, such as to describe logical or behavioral aspects of the physical system to a certain category of readers. 

In general the term model would apply to outcome of various UML Diagrams, which are listed below. At least one or more of such Diagrams would describe the software project model. Every Diagram may not be needed for every project.  

UML defines the following graphical Diagrams :

(Less important ones are left out in this list )

Two widely Uses ones  :

• Use Case Diagram 

• Class Diagram

• Behavior Diagrams :

• State Chart Diagram

• Activity Diagram

• Interaction Diagrams :

• Sequence Diagram

• Communication Diagram

( Known earlier as Collaboration Diagram)

• Implementation Diagrams :

• Component Diagram

• Deployment Diagram

––––––––

Why so many Diagrams ? These Diagrams provide multiple perspectives of the system under analysis or development.

Gears in head Good models are essential for communication among project teams and to assure architectural soundness. So a model may needed to made from Static Views (Structural Views), Dynamic Views, Detailed Views and so on.

For example :

Class Diagram, Deployment Diagram etc.,  provide a Static View

Use Cases provide scenarios based and User oriented flow View

Sequence Diagram and Communication ( Collaboration) Diagram are ideas for object oriented Dynamic Flow View

And so on.

We step into building models of complex systems because in the absence of a real system which is yet to be built. It is not easy to comprehend any such system. Just as a building needs Plan, Elevation, Interior Diagram, Wiring Diagram etc., to understand it, the software is complex enough to demand many Views in its modeling.

UML version 2.x is based on OMG’s Model Driven Architecture (MDA) :

MDA is a large subject by itself. We quote from WIKI here :

Model  Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model Driven Architecture is a kind of domain engineering, and supports model driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

OMG focUses Model Driven Architecture on forward engineering, i.e. producing code from abstract, human-elaborated modelling Diagrams (e.g. Class Diagrams).

MDA envisages that the Platform Independent Model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.

The Platform Independent Model (PIM) is translated to one or more Platform Specific Models (PSMs) that computers can run.

A yellow rectangular sign with black text Description automatically generated

Case Study : Requirement

Airline Enterprise Grade Reservation System (ARS)  :

The Requirement Summary is :

African pilot ARS Project :

Drawing of Airbus A320 plane This requirement is for a Airline Company and it is a requirement of Enterprise software.

Vector drawing of yellow hand waving smiley The Airline Reservation System (ARS) as detailed here will have to be integrated at least with the following systems :

Flight Schedule System

Financial System

Loyalty Reward System

Partner Services

Robot with hands up These systems are currently existing, but may evolve and may undergo improvements during the same time when ARS is under formulation. Also note that there could be a few more systems which will be brought to the integration list as ARS progresses. So the Application Architecture should make enough future-proofing for this.

Boy with toy You must be convinced that it is an Enterprise Grade Software Requirement as you engage yourself with this Case Study. You, the OOAD expert, will get the ownership of their Enterprise from this company, at least as far as IT area is concerned.

Vector image of blue Mr Wind cloud The operational system of running flights is already in place.

The need now is to move into an online Enterprise grade Reservation System.

Teacher / Manager vector image The Reservation facility is to be Used by

Hand waving smiley 1) Those who visit the Airline offices in the city and in the airports and take advantage of the services of the person there (Booking Clerk) for Ticketing operations

The Architecture and the design behind it is to involve Counter based Clients communicating with a Central Server 

Counter activity includes :

Booking a Fresh Regular Ticket : One to many Passengers  

Booking Premium ticket – specially marketed for Frequent Flier Customer  

Booking Concession Ticket based on eligibility criterion and on production of suitable document

Canceling a previously Booked ticket – in full

Canceling a previously Booked Ticket – in part, a particular leg of the multi-leg journey, or for one among a few travelers booked therein and so on. 

Changing simple parameter of a booked ticket

say Change of seat number

Changing major parameter of a booked ticket

say Change of date of travel  which amounts to one Booking

followed by a Cancellation

African programmer 2) Those who Use internet – known broadly as Web Clients  

The Architecture and the design behind it is to involve Browser based Clients or mobile App based clients communicating with the same Central Server 

Internet based Booking involves :

Prior registration as a Customer

Capture basic info including Credit Card Gateway

Or other alternate payment mode details

Booking on line – Passing on travel request from Browser

Response about availability

Booking activity on concurrence

Ticket Status through e-ticket

Suitcase with travel stickers vector drawing 3) Travel  Agencies who will have compatible software

The Architecture and the design behind it is to involve third party Clients communicating with the same Central Server 

What is involved here ?

Booking Requests : Always  many requests in one bunch

All may not result in Ticket availability

Carry-out booking on availability

Not-booked status for other requests

Man searcing files vector image 4) Officers of the Airlines who may need to change System entries such as New Flights, new rules etc.,

The Architecture and the design behind it is to involve internal Clients communicating with the Central Server but for a different purpose (MIS) - Management Information System 

Many things are involved here :

Charting : Preparing a Chart. Executed as manifest for the particular flight               

Should be kept off the on-line reservation at this manifesting time : no more booking or cancelling or check-in etc.,

At this stage the necessary number of copies of chart is prepared.

Many more Officer activities which will be detailed alter on.

Boy and girl holding boxes vector image 5) Potential  Passengers who may Use the kiosks kept at various public places or even their telephone (tone) system to enquire about a specific flight for timings or availability. Also the Passengers who have booked a ticket with Waiting List status may like to enquire about the change in status through the same facilities.

The Architecture and the design behind it is to involve enquiry-only Clients communicating with the Central Server but with different technologies. May range from simple IVR to sophisticated mobile and social media interfaces. We do not know yet, but must be prepared for all.

Aeroplane vector art The Airline Company also has an ambitious requirement of exposing the system to any ‘discrete client". The client may not be predictable one like Web Client or Travel Agency software, but can be any software which follows an accepted mechanism to consume the exposed services.

Universal Access. No platform restrictions. This is the in-thing now a days.

Can we foresee some of them at least now ?  

Use Case View

§  This is essentially a View which depicts the usage scenarios. The Diagram herein may describe the behavior of the system from the Viewpoint of its end Users and other external stakeholders

Diagrams in Use Case View :

Use Case Diagram -

Class Diagram for Analysis Classes (Robustness Diagram)  

Package Diagram for Use Case

BUC : Business Use Case and SUC – Software Use Case :

But software Use Cases are covered in this Book and as part of this Case Study

Software Use Case, or what is normally referred to Use Case : Is covered first here, with the Author’s idea of Ranks. Our industry follows by and large a similar Rank based approach.

It is normally said that an Use Case should add business value to the software project.

A yellow rectangle with red text Description automatically generated

––––––––

From the definition above, we understand that Use Cases which are to be drawn by us as SUC will be something about the functionality of the proposed software system.

An Use Case is a kind of usage

of the system

in which external objects (called Actors)

interact with the system.

––––––––

Even though we are focusing on the software portion in the Use Cases, it will still be written from the view point of an external element, the Actor.

––––––––

Knowledge transfer heads IDENTIFY ACTORS

(AS MANY AS POSSIBLE)

BE  CLEAR ABOUT

THE OVERALL  SCOPE

Actors  are outside the scope of design, but do interact with boundaries of the design, such as UI Screen.

––––––––

So our task now is to identify Actors and then look for some measurable value that the system provides for them. We also know that most software system are passive in the sense that first the Actor may have to make a request and then get the value as the response. The focus in preparing such Use Cases must be on automation and its resulting value. The Analyst should not loose focus on the interaction part, forgetting the value derived.

Charlie Chaplin with a stick vector illustration After all, any Actor will interact with a software system. So there will be set of interactive steps. We can no doubt express them in the