Your SlideShare is downloading. ×
Systematic Identification of Design Classes with LIVE Objects
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Systematic Identification of Design Classes with LIVE Objects

270
views

Published on

Systematic and logical way of using UML Diagrams is NOT very obvious. Examples do not bring out the subtle logic but it can be defined and demonstrated. Working on projects helps. …

Systematic and logical way of using UML Diagrams is NOT very obvious. Examples do not bring out the subtle logic but it can be defined and demonstrated. Working on projects helps.

Unrealistic but imaginative thinking helps. LIVE objects are of that kind. They make software simple and great simultaneously.


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
270
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Mobile: 91 9866071582 Putcha V. Narasimhame-mail putchavn@yahoo.com, kenablersys@yahoo.com Knowledge Enabler SystemsOur Ref: In the footerDate: 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
  • 2. Mobile: 91 9866071582 Putcha V. Narasimhame-mail putchavn@yahoo.com, kenablersys@yahoo.com Knowledge Enabler Systems 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 Systematic Identification of Design Classes with LIVE objects Page No 2 of 4 Copyright © by Putcha V. Narasimham 2003, 2013
  • 3. Mobile: 91 9866071582 Putcha V. Narasimhame-mail putchavn@yahoo.com, kenablersys@yahoo.com Knowledge Enabler Systems 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 Giants 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 Systematic Identification of Design Classes with LIVE objects Page No 3 of 4 Copyright © by Putcha V. Narasimham 2003, 2013
  • 4. Mobile: 91 9866071582 Putcha V. Narasimhame-mail putchavn@yahoo.com, kenablersys@yahoo.com Knowledge Enabler Systems 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 "Id say that the various parts dont 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 Page No 4 of 4 Copyright © by Putcha V. Narasimham 2003, 2013