• Yourdon Symbols

• CASE Tool Download/Installation EasyCASE Plus is a commercial CASE tool that is no longer in publication. It runs as a DOS application under Windows. I paid full retail price for it when it was one of the best tools available in the late 1980's.
• Components of a Class Diagram. An ``object-oriented specification' of the type that can be developed using Coad and Yourdon's method includes a diagram that shows the ``problem domain' classes the system will include, attributes and services, and various possible connections between classes.

Hello, We are about to develop an embedded real time software to demonstrate a biomedical application. That is why we are seeking a simple CASE tool for modelling of our system using the Yourdon-DeMarco structured analysis method and also for documentation purposes.

I have a table USER with these contents:

I need to add a query inside the procedure for display the User_Name:

Like as I need:

Using this query I am getting the USER_NAME:

but I need the Output like this:

How to get my result in CASE WHEN ELSE statement or any other way?

Please give me an example.

diziaq

4 Answers

You should use a (left) outer join to solve such case. NVL/COALESCE will take care of replacing NULL by some hard coded value. Something like that:

Sylvain LerouxSylvain LerouxAnkit BajpaiAnkit Bajpai

Please check if its worth for you.
select user_id,case when pr_user_id IS NOT NULL then user_name else 'NO PR_USER' end as primary_user_namefrom user_name;

It displays the below result

Hi you try with below query.

select decode(pr_user_id,null,null,user_id),case when pr_user_id IS NOT NULL then user_name else 'NO PR_USER' end as primary_user_namefrom test_2;

101 AAA102 BBBnull NO PR_USER104 FFF

Not the answer you're looking for? Browse other questions tagged sqloraclecase or ask your own question.

Yourdon Symbols

Comparison of DiagrammingMethods

When it comes to recording the results of a system analysis,there are so many diagramming tools and methods available that it can bedifficult deciding which one to use. This paper compares the variousgraphical diagrams used in system analysis, focusing on thosedocumentation models that have become industry standards. It is targetedfor the reader who has an introduction to standard diagramming methodsincluding flowcharts, entity-relationship,>

Methodologies

A methodology is the result of someone having studied a methodof system development. A complete methodology outlines the steps that adeveloper has to go through from the inception of a software product,through its development and implementation life cycle, and terminatingonly when the product becomes obsolete.

The documentation of the activities in these steps is often facilitatedby graphical diagrams which concisely represent various aspects of thesystem that is being modeled. System analysts usually employ at least onemethodology, especially the structured analysis techniques which result indata-flow and entity-relationship diagrams. However, there are someanalysts (and many programmers) who are not familiar with anymethodologies, or they may be unable to commit to a particular one.

Even without the use of a methodology, however, it is possible to use adiagramming method and reap some benefits of a methodology withoutcompletely understanding it - I'm living proof. Some diagramming methodsare even simple enough to learn just by viewing a few examples. Inaddition, inexpensive diagramming tools facilitate diagramming with orwithout a supporting methodology. Some languages (e.g. Microsoft'sVisual series) even provide diagramming tools with barely a hintthat methodology is being implemented (or they pick one you're not using).This just encourages the no-holds-barred, seat-of-the-pants kind ofdevelopment that exists beyond the confines of a methodology, anenvironment that most programmers actually prefer.

Developers such as these may find (as I have) that the diagrammingtools at hand provide a variety of ways to represent the same diagram,with no guide as to which method is best. In some cases, the supportingmethodologies don't help you decide either. So, which one do youchoose?

Unfortunately, to apply the best solution to your problem, youhave to be familiar with all the tools available to you. I don't know whattools you have, but Visio is right at my fingertips. So if you'll pretendyou're me for a moment, I can walk you through the problems I'veencountered and we can both learn something from this exercise. First,let's make sure I haven't lost you already.

Visio

Let's assume that you have a good, powerful, but easy-to-usediagramming tool such as Visio. Visio provides a variety of templates [15] that directly correlate with a particularmethodology (apparently). Each template has 15-30 icons, complete withdescriptions, that you can drag and drop on your diagram to begindocumenting your system. I'm not promoting Visio, or even condoning itsuse - it's just been available at two of my workplaces, so I use it.

Let's further assume that you have an idea about which diagram you wantto create. For some types of diagrams, there's only one template toselect. However, if you're designing (documenting) a database system or anobject-oriented system, you'll have to make a choice. These are two of theareas where the greatest variety of methodologies exist, and where youwill need the most help in deciding which template to use. Unfortunately,these are the areas where most new development is currentlyconcentrated.

Diagramming Principles

Before discussing the details of any template or methodology,there are two principles that are common to all diagramming techniques.First, the context of a diagram must be clear, and second, each diagrammust present a view of the system that is independent of other views.

A diagram's context must be fully understood by its title, title block,a reference to a larger (smaller) context, or some combination thereof.Time and version dependencies should also be considered. Care to wasteyour time writing a new program - from an old database document? A dateand time stamp will resolve any confusion. If you can expect a secondversion to be made (almost always), a version identification will alsohelp. Some media (e.g. the Internet) facilitate keeping a document withincontext, while others (e.g. paper) require extra care.

If there will be more than one type of diagram for a system, eachdiagram type must be Orthogonal to all the others. Orthogonalprojections show aspects of a system from perspectives that are fullyindependent of each other. In the same way that an architect views abuilding plan from front, side and planar elevations (relating to theperpendicular x, y and z axes), we we want to view a system from similarorthogonal views. Given a 3-dimensional system, any 2-dimensional viewwill hide components that occur in the other dimension. The same principleapplies when you move from a physical, 3-dimensional system to a softwaresystem which can have even more independent dimensions. Having multipleperspectives ensures that there aren't any portions of the system thatremain hidden or under-analyzed.

Now that we've established a context for our discussion, let's evaluatesome of the methodologies in which we have overlapping diagrammingtechniques. I've chosen three to discuss in detail: entity-relationshipdiagrams,>

Logic Flow Charts

Flowcharts are no longer considered a modern technology,but it may be the only type of diagram some users have been exposed to.Flowcharts focus mostly on decisions, a special type ofprocess that now appears in>

Language Level Diagrams

This Visio stencil contains shapes useful for creatingfunctional decomposition diagrams and program structure diagrams. Oneparticular icon, flowchart shapes, can be used to createconventional flowcharts. This Visio smart shape can be morphed into any ofthe four shapes used in flowcharts. A summary of conventional flowcharting technique is as follows:

1. Functions, or processses, are represented byrectangles.
2. Decisions are represented by diamonds.
3. Inputs are represented by parallelograms.
4. Outputs are represented by a hardcopy symbol (a rectangle witha wavy bottom edge).

Nassi-Schneiderman Diagrams

Also known as Chapin Charts, Nassi-Schneiderman (N-S) diagrams[16] are a modern alternative to flowcharts for thefollowing reasons:

1. N-S diagrams are an alternative to pseudocode.
2. An N-S diagram can be drawn using text and lines (or completely withASCII characters).
3. N-S diagrams show processing by series, by selection, or by iteration.
4. N-S diagrams are read from top to bottom.
5. N-S diagrams are more structured than flowcharting (one start, oneend).

Entity Relationship Diagrams

As the name describes, an entity-relationship diagram(ERD) is used to model the entities that a computer system recordsinformation about, and the relationships between those entities.The evolution of an ERD typically progresses either from scratch (throughan interview process) or is reverse-engineered from an existing databaseschema. The varieties of ERD's therefore support various stages ofdevelopment, beginning with a user-readable form that allows validation ofa design, and culminating in versions that are used by developers tovalidate a design at detailed and/or summary levels.

Bachman

Many developers and CASE tools still use Bachman's crow-footnotation [10] to indicate the cardinality of arelationship. Where necessary, a relationship type is oftenwritten on or near the line that represents a relationship. Sincethe Bachman notation is unique only in representing therelationship (a line), and Visio allows you to draw a line anywhereand/or change the line-ends anywhere a line is drawn, the Bachmancrow-foot notation can be used with any other template.

Peter Chen

Chen's original method [2] is the basisfor many writings on ERD's [3, 12]. While the traditional aspects of entities andrelationships are represented as boxes and lines (respectively), there area number of unique attributes to his present method [4]:

1. The cloud symbol represents aggregations of smaller ERdiagrams, in the context of a logical design (as opposed to a physicaldesign).
2. The double-box represents a weak entity, which is dependent onits parent entity. Note: Visio does not support this feature.
3. A diamond symbol represents a type of relationship.
4. Relationship adornments are added adjacent to the lines to indicateconnectivity (I, M, N) and cardinality, e.g. '(0,3)'.
5. The>

   James Martin

   Visio's Martin ERD template is based on the symbols used in theMartin notation [9] to draw object-oriented analysisand design diagrams. This notation has the following attributes:

   1. Rectangles and ovals represent entities and attributes(or data items), as with Chen's notation.
   2. Simple lines indicate relationships, and adornments are addedadjacent to the lines to indicate the type of relationship(written) and its connectivity (0, 1, *).
   3. A line with a midpoint arrow indicates a message ordata-flow.
   4. Simple lines connected by a dot indicate a boolean and/orcomputation.
   5. A rounded rectangle represents activity.
   6. A large arrow represents an event.
   7. A triangle with a numeric label represents aconnection.

   A diagram that uses all of these notation elements simultaneously canbe very elaborate and potentially confusing. By conventional techniques,an ERD will only contain entity, data item, andrelationship symbols, while the remaining elements (especiallyactivity and event items) usually appear in an objectdiagram.

   Data Flow Diagrams

   The formal, structured analysis approach employs thedata-flow diagram (DFD) to assist in the functional decomposition process.I learned structured analysis techniques from DeMarco [7], and those techniques are representative of presentconventions. To summarize, DFD's are comprised of four components:

   1. External interactors are represented by a rectangle.
   2. Data stores are represented by an open rectangle (2 or 3sides).
   3. Processes are represented by any rounded object (a circle,oval, or square with rounded corners). A DFD process may represent systemfunction at one of various levels, atomic through aggregate.
   4. Data flows are represented by arrows, with labels indicatingtheir content.

   The following templates are described with respect to theseconventions. These Visio templates include nodes with a sub-paging featurethat facilitates creating subordinate diagrams, and in navigatingmulti-tiered models after a design has been completed.

   Chris Gane / Trish Sarson

   The Gane/Sarson method [8] stressesthe identification of each node to help reference process narratives thatfurther define each component either in plain text or pseudocode.

   1. A data store is represented as an open rectangle (3 sides, openon the right).
   2. Processes are represented by a rounded upright rectangle,subdivided into sections for a reference value, a process description, andan optional location specifier.

   Yourdon and Coad

   This Visio template, based on the Yourdon and Coad method [5], includes components for creating>

   1. A data store is represented as two parallel, horizontallines.
   2. Processes are represented by a circle, and adorned with adouble circle for multiple processes (indicating that furtherdecomposition exists at a lower level). Note: the oval processshould be reserved for object or class diagrams.

   Object Oriented Diagrams

   Given the presence of four Visio object-oriented diagramtemplates, and the fact that many of the diagramming methods contribute toUML emerging as a standard [17], it isinstructive to review each template and note its features.

   Sally Shlaer and Stephen Mellor

   The Shlaer/Mellor method [18] isconsidered an older technique that should be used on existing projectsthat have not migrated to UML [19]. The majorcomponents of this model include:

   • Domain chart - used to partition the system into domains andsubsystems.
   • Information Model - used to build a static analysismodel of a system. This shows objects, relationships, and inheritancestructures, and define class attributes and methods. Designate primarykeys and formalize relationships.
   • State model - used to analyze the object's behavior over time.
   • Process Diagram, or Action Data Flow Diagram, for anaction shown in the State Model.
   • Object Communication Model (OCM) - summarizes theasynchronous event communication between state models in the system.
   • Object Access Model (OAM) - summarizes thesynchronous communication between state models and object instancedata.

   James Rumbaugh

   Rumbaugh's methodology, the Object Modeling Technique (OMT) [11], defines class, object, state, and>

   • Object diagram
   1. Object nodes are subdivided into sections for data andprocesses.
   2. Object attributes are shown as text, not as separatenodes.
   3. Ternary associations between objects are shown as diamonds,with lines connecting the participants.
   4. Inheritance relationships are shown as lines with various lineends.
   5. Cardinality characteristics are shown as relationshipadornments.
   • State-transition diagram (dynamic model)
   1. Processes are shown as ovals.
   2. The initial state process is identified with a filled-in dotand an arrow that points to the first state. Similarly, the finalstate is indicated by an arrow pointing to a circled dot.
   3. State transitions are identified with a notation 'a / b', whereevent a causes action b.
   • Data-flow diagram (functional model)
   1. Processes are shown as ovals.
   2. Data stores are shown as two parallel, horizontal lines(similar to Yourdon and Coad).

   The Object Modeling Technique also allows two different models of datato be displayed in the same diagram. By doing so, one diagram can show twodifferent levels of association.

   Grady Booch

   Booch's notation [1] is generallyregarded as the most complete for representing object-oriented systems [6]. Unfortunately, the notation is also complex andcan lead to fragmented or duplicated information across model diagrams.Booch considers himself more of a developer than a methodologist, so heconcentrates more on the results of system analysis and design than itsprocess. He is a major contributor to UML, and has also made his notationa property of the public domain.

   His notation includes six types of diagrams: class, object, statetransition, interaction, module, and process. The Visio Booch templatesupports all of these except state transition, which is supported with theRumbaugh template.

   Unified Modeling Language

   The Unified Modeling Language (UML) is 'a language forspecifying, constructing, visualizing and documenting the artifacts of asoftware-intensive system' [20]. UML has evolved fromthe work of Grady Booch, James Rumbaugh, and Ivar Jacobsen, associates atRational Corporation. These three assimilated their respectivetechnologies into a single specification that was published in January,1997. With the help of the Object Management Group [21], UML is rapidly becoming an industry standarddocumentation method.

   UML does not mandate a particular development process, although it wasdesigned to support a variety of object-oriented development processes. Itis hoped that the existence of a widely-accepted documentation standardmay contribute to a standardized process.

   A system that has been documented with UML will be comprised of one ormore of the following documents:

   • Use-case diagrams
   • Static structure diagrams (Class diagrams)
   • State diagrams (activity diagrams)
   • Sequence diagrams
   • Collaborations
   • Implementation diagrams (component and deployment diagrams)
   • Stereotypes

   Use-Case diagrams are based on Jacobsen's OOSE methodology [22] and have the following features:

   1. An agent is represented by a human stick-figure.
   2. A use case (or process) is represented by an oval
   3. A use (or interaction) is represented by a double-arrowline.
   4. The system boundary is shown by a large rectangle. Actors areshown outside, use cases are shown inside, and interactions between themcross the system boundary.

   Conclusion

   With at least a basic guide as to their use, diagrammingtools can be wonderful instruments for documenting a system analysis anddesign. Although it is helpful to have a methodology to supportdevelopment activities, there are many instances where they are not used.But even though a diagramming tool was designed to be used with amethodology, the lack of a developer's access to the methodology need notbe a hindrance to the use of the diagramming tool.

   A developer must select a set of diagram templates that serve his orher needs either by relying on a prescribed methodology or by exploringthe capabilities of the diagramming tool and comparing the diagrammingmethods that are available within the tool. As tools become moreversatile, this choice becomes more difficult to make. Fortunately,industry trends such as UML are helping to limit choices and yet retainthe versatility that developers need.

   References

   1. Booch, G. Object-OrientedAnalysis and Design, With Applications, 2^nd ed. RedwoodCity, CA: The Benjamin / Cummings Publishing Co., Inc., 1994.
   2. Chen, Peter. 'The Entity-Relationship Model:Toward a Unified View of Data' ACM Transactions on Database Systems I(I). March 1976, pp 8-46.
   3. Chen, Peter. The Entity-Relationship Approachto Logical Database Design. Wellesley, MA: QED Information Sciences,c1977.
   4. Chen, Peter, et. al. (ed.), Conceptual Modeling: Current Issues andFuture Directions,Berlin, Germany: Springer-Verlag, 1999.
   5. Coad, P. and E. Yourdon, Object-OrientedAnalysis, 2^nd Edition, Englewood Cliffs, NJ: Prentice-Hall,1991.
   6. Coleman, Derek, Object-Oriented Development: The Fusion Method,Englewood Cliffs, NJ: Prentice-Hall, 1999, pp. 191-198.
   7. DeMarco, Tom. Structured Analysis and SystemSpecification / A Yourdon Book, Yourdon Inc., NY, 1979.
   8. Gane, Chris and Trish Sarson. Structured SystemsAnalysis. Englewood Cliffs, NJ.: Prentice-Hall, 1979.
   9. Martin, James and O'Dell, Object-Oriented Methods: AFoundation, Upper Saddle River, NJ: Prentice-Hall, 1998, p. 52.
   10. Rob, Peter and Carlos Coronel. Database Systems. CourseTechnology (Div. of International Thomson Publishing): Cambridge, MA,1997. p 260.
   11. Rumbaugh, J., M. Blaha, W. Premlani, F. Eddy,W. Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, NJ:Prentice Hall International, 1991.
   12. Teory, Tobey J.Database Modeling and Design: The Entity Relationship Approach. SanMateo, CA: Morgan Kaufmann, 1990.

   Web Resources

   13. College of Staten Island, the CityUniversity of New York, 'CaseTool Index',http://unlser1.unl.csi.cuny.edu/faqs/software-enginering/tools.html, lastupdate unknown, last accessed: 11/26/1999.
   14. Excel Software, 'Software Models',http://www.excelsoftware.com/models.html, Last modified: (unknown), lastaccessed: 11/27/1999.
   15. Visio Corporation, Software Diagramming Stencils(Untitled),http://www.visio.com/solutions/directory/software/diagramming/stencils/index.html,ã 1997-99, last accessed:11/26/1999.
   16. Paul R. Seesing, 'Basic Systems AnalysisTools for Computer Users', http://www.open.org/~prslkg/sy_chap.htm,ã 1993, last accessed: 11/26/1999.
   17. Visual Object Modelers, Inc., 'Visual UML ProductInformation', http://www.visualobjectmodelers.com/products.htm, lastupdated: 11/18/1999, last accessed: 11/26/1999.
   18. Dr. John Osmundson, '11.0Software Engineering Related Management Issues',http://www.stl.nps.navy.mil/~josmund/SWmgmt11o/sld033.htm, Last modified:5/19/1999, last accessed: 11/27/1999.
   19. Popkin Software, 'Shlaer/Mellor',http://www.popkin.com/products/sa2001/object/ shlaer.htm, Last updated:11/24/1999, last accessed: 11/27/1999.
   20. Rational Software Corporation, 'UML Resource Center:Unified Modeling Language, Standard Software Notation',http://www.rational.com/uml, ã 1995-99,last accessed: 11/26/1999.
   21. Object Management Group, 'Object Management Group Home Page',http://www.omg.org, ã 1997-1999, lastaccessed: 11/27/1999.
   22. Edward Kenworthy, 'PG toUse Case Modelling', http://www.zoo.co.uk/~z0001039 /PracGuides/pg_use_cases.htm, Last modified: 12/2/1997, last accessed:11/27/1999.

   Author: Keith Stiern

   Source Address: http://www.umsl.edu/~s1028363/DiagrammingMethods.html

   Created: November 28, 1999