Systematic Identification of Design Classes with LIVE Objects

Mobile: 91 9866071582 Putcha V. Narasimham
e-mail putchavn@yahoo.com, kenablersys@yahoo.com Knowledge Enabler Systems

Our Ref: In the footer
Date: January 23, 2008, Rev March 20, 2008, July 22, 2009, Jan 25, 2010, 02FEB13

Systematic Identification of Design Classes with LIVE objects
Putcha V. Narasimham

Unified Process [Ivar Jacobson, ..] claims that use cases drive system design. This is
welcome but the process is not very clear. Craig Larman in his book, “Applying UML and Comment [PVN1]: Third edition, 2005
Patterns” has given excellent explanation of Domain Models (concept classes, Data models and Pearson Education
the richness of OOAD over UML) and named it “a visual dictionary”. He introduced System Comment [PVN2]: Ch 9.1 page 133
Sequence Diagram before jumping to Sequence Diagrams.

Doug Rosenberg, in his book, “Use Case Driven Object Modeling with UML ---A Practical Comment [PVN3]: © Addison-Wesley 1999
Approach”, has also described a comprehensive approach to systematic evolution of UML
diagrams and progress from one type of UML diagram to another. His creation of “dumb
servers” in page 67 comes close to my proposal for “LIVE Objects” in Design Classes.

What these three authors have proposed and described seems to be lost in the more recent
publications. In the process of study and application of OOAD / UML, my students and I have Comment [PVN4]: Not exhaustive enough
independently evolved systematic identification and evolution of “design classes with LIVE
objects” during 2007-2010. I will correlate the detailed concepts in later revisions of this
document.

First of all, mere description of Use Cases is not very helpful in requirement specification.
Use Case is better understood as “SERVICE DIALOG”. The system offers services
through its message and Actor selects one of the services and gives related data. [See
Putcha V. Narasimham Redefining Use Case as SERVICE DIALOG---A Proposal]. After that is
done, use cases are indeed very effective to systematically identify design classes of the
system to be developed. This draws on the SSAD (Structured Systems Analysis and Design)
method of identifying processes of First Level DFD from Context Diagram and Dataflows from
External Entities.

This template describes a step by step process of using Use Case Description (Service
Dialog) and Sequence Diagram of UML to identify the sub-systems and design classes of the
system to be developed. This is a transition of requirements engineering to system design.

1 Actors in Use Case Diagrams

A good Use Case Diagram identifies all the independent Actor Classes external to the
System. Each Actor Class may use one or more Use Cases or System Services. Comment [PVN5]: In UML Actor = ROLE but
most publications including UML standards treat
Actor as an Entity playing many roles. The
2 Use Case is SERVICE DIALOG
same popular mistake is also made here
deliberately.
It is advantageous to view Use Case as a Dialog of Messages from the System to Actor and Actor
to the System to reach Use Case Goal. System offers Services in its messages and asks for
data. Actor’s message consists of “Service selection and related data” . The system
consists of a large number of programs ranging from system software, layered software,
Application software, Interface software etc. The question is how to identify the subsystems and
classes of the system.

Systematic Identification of Design Classes with LIVE objects Page No 1 of 4
Copyright © by Putcha V. Narasimham 2003, 2013


3 eActors:

External Actors need Electronic Assistants or Secretaries or Helpers--- let’s say eActor within the
system---to carry out processing or tracking activities for them (external actors). See the
following examples.

In a computerized movie ticketing system, a human booking clerk does not actually
carry out the allotment or cancellation of seats, printing of tickets etc. He or she would
convey the requests from movie goers and lets a Service Class in the system to carry out
those operations. Let’s call that service Class is eActor. Some eActors may have a lot of work
to do and some may have some simple tasks. So, some essential subsystems or design classes
of the system to be developed are eActors.

In an electronic publishing system, Contributors, Referees and Editors are typical actors.
eContributors would organize the contributions and distribute them to relevant Referees.
eReferee would collect and queue the contributions for each Referee and take care of
notification and distribution of refereed contributions. Similarly eEditors would assist the
Editors. The human Referees and Editors would carry out professional / judgmental
activities and leave the organizational chores to eReferees and eEditors. Many eActors may
be derived from eActor Class having common useful attributes and operations known of the best
human secretaries / assistants.

4 System Sequence Diagram Identify all the Operations

4.1 System Sequence Diagram: The concept of System Sequence Diagram is proposed
and used by Craig Larman and Scott Ambler to first identify all the operations that the
System must carryout before the Control Classes or Design Classes can be conceived
of. The students of AMSSOI MCA batch 2008 have independently discovered the need for
System Sequence Diagram, though not by that name during August 2007- December 2007.

4.2 Systematic Discovery of Operations and Design Classes: Although Sequence
Diagrams are mostly used to show the time-ordering of messages and data flowing form Actors
and objects of the system, they are very effective to identify the operations also. Many
sequence diagrams do not even show specific operations. They merely show the “status
of activation” also called “Focus of Control” of the object through a rectangles on the
lifeline of the object.

In our proposal of viewing Use Case as Service Dialog, we identify the “messages & data” from
the System and Actor. Based on the messages & data it is possible to identify what
operations must be carried out within the system. At this stage it is NOT necessary to
identify which sub-systems or Control Classes or Design Classes will have those operations.
These operations primarily deal with functional requirements. However, soon enough,
they should be able to identify and handle Error and Control Data. They are closely associated
and arise almost immediately after the Data to be processed is generated and
transferred.

4.3 eActors: Since eActors are identified, operations that logically belong to them can be
assigned to them. Since the external actors are referred to as “Actor Classes”, eActors, which
are members of internal classes of the system to be developed, may be treated as a subclass
of “Control Class” or “Design Class”.

4.4 LIVE objects: Normally passive objects of domain remain passive (they do not have any
operations) when they are represented as objects within software. Since they are created within



the computer, it is possible to assign operations to them making them LIVE. Thus a
“resume object” in software will have the capability of looking for “Job Description Object” and
“select” suitable Jobs. Similarly “Job Description Object” will have the capability to examine and
match “qualifications in resume object” to shortlist suitable “resumes”. This concept was
indirectly indicated by Doug Rosenberg. There are more examples particularly on Caroms Game
(similar to pool) which significantly improve modeling using LIVE objects.

4.5 Design Classes: The remaining operations can be grouped into cohesive subsets and
assigned to new Design Class or Control Class to be created. Although it is possible to
identify all the system operations it may not be easy or straight forward to identify the best
sub-sets (having high cohesion and loose coupling) of those operations. Trial and error,
designer judgment / preference have to be used. It may be necessary to iterate to arrive at
cohesive Design Classes with minimal coupling.

Thus it is possible to systematically identify the subsystems / design classes of a system based on
Use Case Descriptions and System Sequence Diagrams.

---III---

Imaginative non-realistic LIVE objects
Object oriented thinking, analysis and design are very profound but too much of real-world orientation
may come in the way of conceiving of imaginative solutions and realizing them within computer
software. I am exploring how to ADD un-real BUT USEFUL attributes and operations to objects within
software. For of a suitable term, I call them LIVE OBJECTS. I do not know if this approach is already in

use somewhere. See the discussion “Is a HOLE a part of an object?” on this group.

Comment [Putcha V.6]: If you like the Idea
LIVE Objects do acts that real objects cannot do in the real-world. So, in our JOB PORTAL with LIVE we can work on the project up to SOLUTION
DESIGN…you have to get software developers
OBJECTS, Live Resumes talk to Live Job Descriptions. Live Job Descriptions actively mill around
who appreciate LIVE objects and are willing to
masses of Resumes and strike friendships and offer appointments. Through this, we EVENLY implement software with them.

distribute PROCESSING intelligence to entity & design classes and minimize the need for control Some concepts of Semantic Web are also
necessary as incorporated in our proposal
classes which manipulate inanimate objects. This cuts down needless accesses, messaging and body- HyperPlex….another proprietary design of
ontologies and knowledge bases with high
less pure processes appearing as pseudo objects. precision query. See the write up on that.

PVN 21APR12
We had always used LIVE objects in fairy tales ---I recall Giant's fascinating Golden Harp singing on its
own and screaming “Master, Master” for the Giant when Jack tried to pick it up and run away--- in
“Jack and the Beanstalk”.

We need Business Analysts, Requirements Engineers and Designers to imagine such business entities
in the IMAGINATIVE UNREAL WORLD OF SOFTWARE to do REAL business and give REAL BENEFITS.

Putcha V. Narasimham



Is HOLE an Object?

Yes Anup---considering a HOLE as object, even in a conceptual world, is a deliberate unrealistic
extension. Its attributes and operations are defined with caution. In fact, it was suggested by one of
my students and I rejected it to start with. Latter I thought about it and evolved the idea without Comment [PVN7]: Not the best a teacher can
do. A good teacher should let the idea evolve.
looking for the logic of her suggestion. It turned out to be very useful though NOT consistent with If it is not feasible we will discover that sooner
or later but if we reject a potentially powerful
physical reality. idea just because it is NOT impressive at first
sight, we are irretrievably throwing away a
gem.
Thanks Jukka and Remy: I am exploring how to ADD un-real BUT USEFUL attributes and operations
I do not remember how I retrieved this one.
to objects within software. For want of a suitable term, I call them LIVE OBJECTS. I am opening
another discussion.

UML Lovers:

I agree with James S on "I'd say that the various parts don't come across as being very Comment [PVN8]: There are more elaborate
related;....". I too have found and posted the following years ago. discussions suggestions from Milan K, not
copied here.

AA: I do not know if there is any published systematic way of proceeding from Use Cases to Comment [PVN9]: I did not read Dough
Sequence Diagrams (UCs and SDs are separate but related), refinement of Analysis Classes, Rosenberg by 20SEP12. It is not obvious but
his “dumb server” is close to our “LIVE object”.
creation of Design Classes, allocation and REallocation of operations to the Analysis and Design
Classes etc.

BB: I have some proposals for that, building on System Sequence Diagrams of Craig Larman.
Here I have added "How to systematically & iteratively create LIVE Design Classes which do not
have real-world counter parts but are needed in the software".---that is a separate document. Comment [PVN10]: 02FEB13

CC: I have shared the details with a few LinkedIn members. Milan K said what I proposed was
"the main stream OOAD method" but I could not get any references. Recently I found that Doug Comment [PVN11]: Jan 2013
Rosenberg was hinting this in his book “UC Driven Object Modeling with UML”

DD: I welcome interaction / exchange of references and non-confidential project documentation.

kenablersys@yahoo.com
20SEP12 (long gaps in revisiting and catching up.)


Systematic Identification of Design Classes with LIVE Objects

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Putcha Narasimham

Mais de Putcha Narasimham (20)

Systematic Identification of Design Classes with LIVE Objects