Introduction of Rational Rose and UMLUnified Modeling Language (UML) was created in 1995 by merging diagramming conventions used by three software development methodologies: OMT by James Rumbaugh, Objectory by Ivar Jacobson and the Booch Method by Grady Booch. Prior to this time, these three amigos, along with about a dozen other practitioners had promoted competing methodologies for systematic software development, each with its own system of diagramming conventions. The methodologies followed a kind of cookbook style of pushing a software project through a succession of life cycle stages, culminating with a delivered and documented application. One goal of UML was to reduce the proliferation of diagramming techniques by standardizing on a common modeling language, thus facilitating communication between developers. It achieved that goal in 1997 when the (international) Object Management Group (OMG) adopted it as a standard.

Some critics consider that UML is a bloated diagramming language written by a committee. That said, I consider it to be the best means available today for documenting object-oriented software development. It has been and is becoming increasingly used in industry and academia.

It should be stressed that UML is not a methodology, rather it is a language for expressing software models. Conceivably, it can be used with various software methodologies. However, separately from the UML, the three amigos have developed the Rational Unified Process, a methodology that is use case driven, and carried out using UML models.

Rational Rose is a Computer Aided Software Engineering (CASE) tool developed by the Rational Corporation under the direction of Booch, Jacobson and Rumbaugh to support software development using UML. Rational Rose is necessarily complex owing to its mission of fully supporting UML. In addition, Rational Rose has numerous language extensions to Ada, C++, VB, Java, J2EE, etc. Rational Rose supports forward and reverse engineering to and from these languages. On the other hand, Rational Rose does not support some traditional design techniques as data flow diagrams and CRC cards, since these are not part of UML.

Because Rational Rose has so many capabilities it is a daunting task to master it. Fortunately, a lot can be done using just a small subset of these capabilities. These notes are designed to introduce novice developers into making productive use of such a subset. They reflect the author’s bias towards developing software and should not be taken as the last word on the subject.

Rational Rose Views Related to the Software Development Life Cycle

Rational Rose models have these four views:1. Use Case View2. Logical View3. Component View4. Deployment View

I like to use a Software Development Life Cycle with these phases:

0. Project Initiation1. Requirements2. Design

2.1 Architectural Design2.2 Detail Design

3. Implementation 4. Maintenance

0. Project Initiation

The project initiation phase involves identifying a problem that need a software solution, investigating to see if an adequate solution is already available for purchase, if not, working up an informal proposal outlining new software to be built and making the case that the expected benefits justify the cost. Rational rose need not be involved in this phase.

1. Requirements

The requirements phase involves eliciting requirements from the client and presenting them in a formal contractual document that will later serve as the basis for acceptance of the finished project. Getting the requirements right is key to the success of the project. However, the software developers are usually not expert on the client’s business environment, nor are the clients necessarily good at expressing what their real requirements are. The developers need to work with the clients to determine the real requirements.

Use Case Diagram - The best tool I know of for talking about requirements is the use case diagram, developed by Jacobson. The diagrams and the use case technique are so simple that clients instantly relate to them and will readily volunteer usual and exceptional scenarios to go along with each use case. The use cases are recorded in the use case view of rational rose.

Some other diagrams strictly speaking belong to the design phase, but may also be useful in the requirements phase. They are constructed in Rational Rose’s Logical View.

Class Diagram – As part of the requirements process entity classes are identified and described in terms of attributes, operations and associations using the UML class diagram. A class is an entity class if it forms part of the client’s business model. So, for example, if the client is running a hospital, possible entity classes are: Patient, Doctor, Nurse, Therapist, Bed, Treatment, Diagnosis, etc. On the other hand, classes such as Form, Canvas, Button, Socket, etc. are not entity classes. They are classes needed to implement the solution, but are not meaningful in describing the client’s business, hence not part of the requirements phase.

Another way to look at entity classes is from a database point of view. The entity classes are usually the persistent ones, i.e. they describe the objects, which the system will permanently track in a database.

Sequence Diagram (Logical View)– Object-Oriented systems get work done by sending messages between objects, invoking functions to obtain services. Sequence diagrams are designed to help visualize the messaging. Each use case results in one or more sequence diagrams, a main sequence diagram to illustrate the usual scenario for the use case and zero or more additional sequence diagrams to illustrate exceptional scenarios. One or two sequence diagrams are appropriate in the requirements phase; they are helpful in refining and adding to use cases, and discovering entity classes. The bulk of sequence diagrams belong to the design phase.

Component and Deployment diagrams are primarily used in the architectural design phase. They show the division of software responsibilities into software components or modules, and the deployment of modules to various devices. However, for some projects such as web applications, client-server and multi-tiered configurations, etc. these issues are so important that the developer may wish to discuss them with the client during requirements analysis. In Rational Rose, these diagrams properly belong in the Component and Deployment views, respectively.

2.1 Architectural DesignThe architectural design phase is used to divide up system responsibilities into subsystems. The subsystems (modules) are identified, responsibilities assigned to them, and interfaces between modules are specified. A general scheme for the software architecture is chosen. For example: client/server, layered services, model-view-controller, etc. The data model is refined including levels of access for different actors.

The following UML diagrams are useful at this stage: Class Diagram (Logical View) – Classes are grouped into packages representing

subsystems. Component Diagram (Component View) – Components and interfaces are defined. Deployment Diagram (Deployment View) – Software components are mapped to

hardware components.

2.2 Detail DesignThe modules identified in architectural design need to be fully specified prior to implementation.

The following UML diagrams are useful at this stage: Class Diagram (Logical View) – Entity classes were identified by analyzing the problem

space during the requirements phase. These are now supplemented with additional solution classes needed to build interfaces, maintain persistent data, manage communications, etc.

The expanded class diagram is reexamined to take advantage of factoring out common behavior into abstract superclasses, simplify associations and otherwise make the design more cohesive.

Sequence Diagram (Logical View) – A complete set of sequence diagrams is now drawn for each of the use cases identified as requirements. As mentioned earlier, each use case has a usual scenario and perhaps several exceptional scenarios. Rather than attempt to show branching in the sequence diagrams, usually a separate diagram is drawn for each scenario.

State chart Diagram (Logical View) – The state of an object is the current set of values of all its attributes (including inherited ones). Objects may change state in response to messages received. The statechart diagram shows all the states, transitions between states labeled by the messages, which cause them, and guards on transitions.

Activity Diagram (Logical View) – These diagrams are similar to the familiar flowcharts. They show activities (processes) and the flow of control and data between activities.

Together the sequence, statechart and activity diagrams form the dynamic model of the system. In general, the system is at rest until an actor initiates a use case by requesting a system function. This causes a flurry of messages and state changes as predicted by the dynamic model.

3. ImplementationIn the implementation phase the detailed design is actually carried out in program code using a target language. Data definition language is written to create and populate the database tables and grant role-based privileges. Reports and interactive forms are written, as well as help files and exception handling routines.

The implementation phase is characterized by testing, unit tests to see if individual modules work correctly, integration tests to ensure that the modules work together properly to carry out the use cases. Tested modules are deployed to the target hardware and retested on site. Finally, acceptance testing verifies that the system carries out its various functions correctly, i.e. according to their specification in the requirements document.

Rational Rose provides extensive support for implementation:

Model checking. Forward code generation (from model to source code) in a variety of target languages.

5. Maintenance

INTRODUCTION OF USE CASE DIAGRAM

use case diagram is “a diagram that shows the relationships among actors and use cases within a system.”  Use case diagrams are often used to:

Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model or a business model

Communicate the scope of a development project

Model your analysis of your usage requirements in the form of a system use case model

 

 

A use case model is comprised of one or more use case diagrams and any supporting documentation such as use case specifications and actor definitions.  Within most use case models the use case specifications tend to be the primary artifact with use case diagrams filling a supporting role as the “glue” that keeps your requirements model together.  Use case models should be developed from the point of view of your project stakeholders and not from the (often technical) point of view of developers.  There are guidelines for:

1. Use Cases2. Actors3. Relationships4. System Boundary Boxes

1.                Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor.  A use case is drawn as a horizontal ellipse on a UML use case diagram, as you see in Figure 1.

1. Use Case Names Begin With a Strong Verb2. Name Use Cases Using Domain Terminology3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram4. Imply Timing Considerations By Stacking Use Cases.  As you see in Figure 1, the use

cases that typically occur first are shown above those that appear later. 

Figure 1. Implying timing considerations between use cases.  

 

2.                Actors

An actor is a person, organization, or external system that plays a role in one or more interactions with your system (actors are typically drawn as stick figures on UML Use Case diagrams). 

Figure 2. Online shopping.  

 

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram2. Draw Actors To The Outside Of A Use Case Diagram3. Name Actors With Singular, Business-Relevant Nouns4. Associate Each Actor With One Or More Use Cases5. Actors Model Roles, Not Positions6. Use <<system>> to Indicate System Actors

7. Actors Don’t Interact With One Another8. Introduce an Actor Called “Time” to Initiate Scheduled Events

 

3.                Relationships

There are several types of relationships that may appear on a use case diagram:

An association between an actor and a use case An association between two use cases A generalization between two actors A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional open-headed arrowhead on one end of the line indicating the direction of the initial invocation of the relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing towards the more general modeling element.

 

Figure 3. Enrolling students in a university.  

 

1. Indicate An Association Between An Actor And A Use Case If The Actor Appears Within The Use Case Logic

2. Avoid Arrowheads On Actor-Use Case Relationships  3. Apply <<include>> When You Know Exactly When To Invoke The Use Case4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case Steps  5. Introduce <<extend>> associations sparingly6. Generalize Use Cases When a Single Condition Results In Significantly New Business

Logic 

7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>8. Avoid More Than Two Levels Of Use Case Associations9. Place An Included Use Case To The Right Of The Invoking Use Case10. Place An Extending Use Case Below The Parent Use Case  11. Apply the “Is Like” Rule to Use Case Generalization12. Place an Inheriting Use Case Below The Base Use Case13. Apply the “Is Like” Rule to Actor Inheritance 14. Place an Inheriting Actor Below the Parent Actor

4.                System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name suggests it indicates the scope of your system – the use cases inside the rectangle represent the functionality that you intend to implement.  

1. Indicate Release Scope with a System Boundary Box.  In Figure 2 you see that three system boundary boxes are included, each of which has a label indicating which release the various use cases have been assigned to. 

2. Avoid Meaningless System Boundary Boxes.

 A use case typically includes the following information:

Name: The name of the use case Brief Description: A brief description of the role and purpose of the use case Flow of Events: A textual description of what the system does in regard to a use case

scenario (not how specific problems are solved by the system). Write the description so that the customer can understand it. The flows can include a basic flow, alternative flows, and subflows.

Key scenarios: A textual description of the most important or frequently discussed scenarios

Special Requirements: A textual description that collects all of the requirements of the use case that are not considered in the use-case model, but that must be taken care of during design or implementation (for example, non-functional requirements)

Preconditions: A textual description that defines a constraint on the system when the use case starts

Post-conditions: A textual description that defines a constraint on the system when the use case ends

Extension points: A list of locations within the flow of events of the use case at which additional behavior can be inserted by using the extend-relationship

Activity Diagram in the Use-Case Model

The flow of events of a use case describes what needs to be done by the system to provide value to an actor. It consists of a sequence of activities that together produce something for the actor. The flow of events consists of a basic flow, and one or several alternative flows.

The flow of events of a use case can be described graphically with the help of an activity diagram. Such a diagram shows:

Activity states, which represent the performance of an activity or step within the flow of events.

Transitions that show what activity state follows after another. This type of transition is sometimes referred to as a completion transition, since it differs from a transition in that it does not require an explicit trigger event, it is triggered by the completion of the activity the activity state represents.

Decisions for which a set of guard conditions are defined. These guard conditions control which transition (of a set of alternative transitions) follows once the activity has been completed. Decisions and guard conditions allow you to show alternative threads in the flow of events of a use case.

Synchronization bars which you can use to show parallel subflows. Synchronization bars allow you to show concurrent threads in the flow of events of a use case.

A simplified activity diagram for the use case Withdraw Money in the use-case model of an automated teller machine (ATM).

Activity diagram is a special case of a statechart diagram in which all or most of the states are activity states and in which all or most of the of the transitions are triggered by completion of actions in the source states.

Architecture of activity diagrams

Basic Nodes

According to Conrad Bock (2003), there there are three kinds of nodes in activity models:

1. Action nodes operate on control and data values that they receive, and provide control and data to other actions.

2. Control nodes route control and data tokens through the graph. These include constructs for choosing between alternative flows (decision points), for proceeding along multiple flows in parallel (forks), and so on.

3. Object nodes hold data tokens temporarily as they wait to move through the graph. Below, the notation for some of the activity nodes to be discussed. Contrary to the names, control nodes coordinate both data flow and control flow in the graph, and object nodes can hold both objects and data

Action nodes

Represented by a rectangle with rounded corners (drawn in slightly different ways depending on the software used ...)

Action nodes should have a label

Object nodes Represented by a rectangle with a label (i.e. UML class boxes)

Decision and merge control node Represented by a lozange

Fork and join control node Forks and joins are represented by a horizonal or vertical line (and incoming and

outgoing flows) One or more activities can fork. One or more activities can join

Initial node Represented by a fat black dot There can be only one initial (starting) node

Final nodes A fat black dot inside a circle (bull's eye symbol) A circle with an x represents the end of a flow (not the whole activity)

Below is a complete example User eats until he has had enough. Then he both reads a book and listens to some music, until he stops.

Flows

Flows (or edges) describe connections between 2 actions. These edges can be drawn with arrows in various ways.

Usually in activity diagrams, actions are simply connected through an unlabelled arrow. In addition, you also can include an object in the flow. These objects can carry data. Finally, instead of objects one can use "pins".

The control flow is modeled in terms of tokens. The start node will create a token which then goes to next action. After the action executes, the token will go to the next action. When it encounters a fork, the fork will create a token for each of its outbound flows. The opposite happens for joins. It will produce an outbound token once all inbound tokens arrived.

Simple flows Simple flows are represented by an arrow from an activity showing parameters with pins

from a node to another

Simple flows with connectors

An arrow to a connector (a small circle with a letter) and then from a same connector to a activity node does the same job as a simple arrow. (not shown here)

Flows with objects Activity node to object node to activity node (with arrows). Object nodes

Flows with pins These are similar to flows with objects. A pin represents data needed and data produced. The flow is represented by an arrow and a pin is a small rectangle added to an activity

rounded rectangle (no picture here)

Decision flows Outgoing arrows from decision nodes are usually labeled.

Signals

Actions in a diagram also can respond to signals (instead of the flow)

Time signals Represented like an hour glass

Input Accept signal (accept) Represented by a concave pentagon (a smashed-in rectangle)

Output signal (send) Represented by a convex polygon

Partitions and subactivities Subactivities

Activities can be decomposed into subactivities. They can have input or output parameters.

A rake in an action node signals a subactivity The subsidiary activity diagram has an input and an output parameter (object nodes)

Partititions An activity can be partitioned in a swimlanes Each swimlane (partition) typically represents a player or role (e.g. learner A, learner B,

group A, teacher). See below for some examples

UML sequence diagram

UML sequence diagrams are used to represent or model the flow of messages, events and actions between the objects or components of a system. Time is represented in the vertical direction showing the sequence of interactions of the header elements, which are displayed horizontally at the top of the diagram.

Sequence Diagrams are used primarily to design, document and validate the architecture, interfaces and logic of the system by describing the sequence of actions that need to be performed to complete a task or scenario. UML sequence diagrams are useful design tools because they provide a dynamic view of the system behavior which can be difficult to extract from static diagrams or specifications.

Although UML sequence diagrams are typically used to describe object-oriented software systems, they are also extremely useful as system engineering tools to design system architectures, in business process engineering as process flow diagrams, as message sequence charts and call flows for telecom/wireless system design, and for protocol stack design and analysis.

1. Sequence Diagram Drawing Elements

This tutorial describes the basic drawing elements used in sequence diagrams and when they are used. These are the diagram elements that are supported by the Sequence Diagram Editor tool . Some are not part of the UML specification and may not be supported by other UML tools.

Sequence Diagram Header Elements

The header portion of the sequence diagram represents the components or objects of the system being modeled and are laid out horizontally at the top of the diagram. See an example sequence diagram here.

Actor Represents an external person or entity that interacts with the system

Object Represents an object in the system or one of its components

Unit Represents a subsystem, component, unit, or other logical entity in the system (may or may not be implemented by objects)

Separator Represents an interface or boundary between subsystems, components or units (e.g., air interface, Internet, network)

Group Groups related header elements into subsystems or components

Sequence Diagram Body Elements

Action Represents an action taken by an actor, object or unit

Asynchronous Message

An asynchronous message between header elements

Block A block representing a loop or conditional for a particular header element

Call Message A call (procedure) message between header elements

Create Message A "create" message that creates a header element (represented by lifeline going from dashed to solid pattern)

Destroy Element Represents the destruction of a header element

Destroy Message Represents the destruction of a header element as a result of a call from another element

Diagram Link Represents a portion of a diagram being treated as a functional block. Similar to a procedure or function call that abstracts functionality or details not shown at this level. Can optionally be linked to another diagram for elaboration.

Else Block Represents an "else" block portion of a diagram block

Flow Note Documentation note that is automatically formatted to flow after previous elements

Free Note Documentation note that is free-flowing and can be placed anywhere in the diagram (can also be anchored relative to a flow element)

Message A simple message between header elements

Page Break A page break in the diagram

Return Message A return message between header elements

Scenario Start Start of a scenario (set of alternatives)

Scenario Case Start of an alternative or case in a scenario

Scenario End End of a scenario

State A state change for a header element 

Steady State A steady state in the system

Timer Start Start of a timer for a particular header element 

Timer Stop Stop of a timer for a particular header element

Timer Expiration Expiration of a timer for a particular header element

2. What can be modeled using sequence diagrams?

Sequence diagrams are particularly useful for modeling:

Complex interactions between components. Sequence diagrams are often used to design the interactions between components of a system that need to work together to accomplish a task. They are particularly useful when the components are being developed in parallel by different teams (typical in wireless and telephony systems) because they support the design of robust interfaces that cover multiple scenarios and special cases.

Use case elaboration. Usage scenarios describe a way the system may be used by its actors. The UML sequence diagram can be used to flesh out the details of one or more use cases by illustrating visually how the system will behave in a particular scenario. The use cases along with their corresponding sequence diagrams describe the expected behavior of the system and form a strong foundation for the development of system architectures with robust interfaces.

Distributed & web-based systems. When a system consists of distributed components (such as a client communicating with one or more servers over the Internet), sequence diagrams can be used to document and validate the architecture, interfaces and logic of each of these components for a set of usage scenarios.

Complex logic. UML sequence diagrams are often used to model the logic of a complex feature by showing the interactions between the various objects that collaborate to implement each scenario. Modeling multiple scenarios showing different aspects of the feature helps developers take into account special cases during implementation.

State machines. Telecom, wireless and embedded systems make extensive use of state machine based designs where one or more state machines communicate with each other and with external entities to perform their work. For example, each task in the protocol stack of a cellular phone goes through a series of states to perform actions such as setup a call or register with a new base station. Similarly the call processing components of a Mobile Switching Center use state machines to control the registration and transfer of calls to roaming subscribers. Sequence diagrams (or call flows as they are commonly referred to in the telecom and wireless industry) are useful for these types of applications because they can visually depict the messages being exchanged between the components and their associated state transitions.

3. Benefits of using UML sequence diagrams

These are some of the main benefits of using UML sequence diagrams.

1. Help you discover architectural, interface and logic problems early. Because they allow you to flesh out details before having to implement anything, sequence diagrams are useful tools to find architectural, interface and logic problems early on in the design process. You can validate your architecture, interfaces, state machine and logic by seeing how the system architecture would handle different basic scenarios and special cases.

This is particularly true for systems involving the interaction of components that are being implemented in parallel by different teams. In the cell phone example, each task would typically be implemented by a separate team.  Having a set of sequence diagrams describing how the interfaces are actually used and what messages/actions are expected at different times gives each team a consistent and robust implementation plan. You can also document how special cases should be handled across the entire system.

The very act of creating the sequence diagrams and making them work with your architecture is valuable because it forces you to think about details such as interfaces, states, message order, assignment of responsibilities, timers/timeouts and special/error cases ahead of time.

2. Collaboration tool. Sequence diagrams are valuable collaboration tools during design meetings because they allow you to discuss the design in concrete terms. You can see the interactions between entities, various proposed state transitions and alternate courses/special cases on paper as you discuss the design.

In our experience, having a concrete design proposal during design meetings greatly enhances the productivity of these meetings even if the proposed design has problems. You can narrow down the problems and then make corrections to solve them. The proposal serves as a concrete starting point for the discussion and as a place to capture proposed changes.

Sequence diagram editor makes it so easy to edit your sequence diagrams that you could even make the corrections in real time during the meeting and instantly see the result of the changes as you make them.

3. Documentation. Sequence diagrams can be used to document the dynamic view of the system design at various levels of abstraction, which is often difficult to extract from static diagrams or even the complete source code. The diagrams can abstract much of the implementation detail and provide a high level view of system behavior.

One of our colleagues shared this experience of joining the software team for a wireless switching subsystem component:

"Our component was the primary interface between the call processing component of the wireless base station and the Public Switched Telephone Network and had to support several different network protocols including T1, E1 and SS7. The previous lead had developed several dozen call flows describing the basic messaging and state transitions for common operations such as call setups including mobile and land originated, call teardowns and features such as call waiting and three way calling for each of the protocols, since each involved different states and messages with the switching component. I found these diagrams invaluable in helping me learn

the software, interfaces and state machine and would refer to them often, even after working in the project for a couple of years."

UML Class diagram

UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes.  Class diagrams are typically used, although not all at once, to:

Explore domain concepts in the form of a domain model Analyze requirements in the form of a conceptual/analysis model

Depict the detailed design of object-oriented or object-based software

   

A class model is comprised of one or more class diagrams and the supporting specifications that describe model elements including classes, relationships between classes, and interfaces. There are guidelines for:

1. General issues 2. Classes 3. Interfaces 4. Relationships 5. Inheritance 6. Aggregation and Composition

 

1.        General Guidelines

Because class diagrams are used for a variety of purposes – from understanding requirements to describing your detailed design – you will need to apply a different style in each circumstance.  This section describes style guidelines pertaining to different types of class diagrams.

 

Figure 1. Analysis and design versions of a class.

Figure 2. Modeling association classes.

1. Identify Responsibilities on Domain Class Diagrams.2. Indicate Visibility Only On Design Models.  3. Indicate Language-Dependent Visibility With Property Strings.4. Indicate Types Only On Design Models.5. Indicate Types On Analysis Models Only When The Type is an Actual Requirement. 6. Design Class Diagrams Should Reflect Language Naming Conventions. In Figure 1 you

see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDate and calculateTaxes().

7. Model Association Classes On Analysis Diagrams. Figure 2 shows that association classes are depicted as class attached via a dashed line to an association – the association line, the class, and the dashed line are considered one symbol in the UML. 

8. Do Not Name Associations That Have Association Classes. 9. Center The Dashed Line of an Association Class.

 

2.        Class Style Guidelines

A class is effectively a template from which objects are created (instantiated).  Although in the real world Doug, Wayne, John, and Bill are all student objects we would model the class Student instead.  Classes define attributes, information that is pertinent to their instances, and operations, functionality that the objects support.  Classes will also realize interfaces (more on this later).  Note that you may need to soften some of the naming guidelines to reflect your implementation language or software purchased from a third-party vendor.

Figure 3. The OrderItem class with and without scaffolding code.

 

Figure 4. Indicating the exceptions thrown by an operation.

+ findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}

1. Use Common Terminology for Names2. Prefer Complete Singular Nouns for Class Names 3. Name Operations with a Strong Verb4. Name Attributes With a Domain-Based Noun  5. Do Not Model Scaffolding Code.  Scaffolding code refers to the attributes and operations

required to implement basic functionality within your classes, such as the code required to implement relationships with other classes.  Figure 3 depicts the difference between the OrderItem class without scaffolding code and with it. 

6. Never Show Classes With Just Two Compartments 7. Label Uncommon Class Compartments8. Include an Ellipsis ( … ) At The End of Incomplete Lists9. List Static Operations/Attributes Before Instance Operations/Attributes10. List Operations/Attributes in Decreasing Visibility

11. For Parameters That Are Objects, Only List Their Type12. Develop Consistent Method Signatures13. Avoid Stereotypes Implied By Language Naming Conventions14. Indicate Exceptions In An Operation’s Property String.  Exceptions can be indicated with

a UML property string, an example of which is shown in Figure 4.

 

3.        Interfaces

An interface is a collection of operation signature and/or attribute definitions that ideally defines a cohesive set of behaviors.  Interfaces are implemented, “realized” in UML parlance, by classes and components – to realize an interface a class or component must implement the operations and attributes defined by the interface.  Any given class or component may implement zero or more interfaces and one or more classes or components can implement the same interface.

Figure 5. Interfaces on UML class diagrams.

1. Interface Definitions Must Reflect Implementation Language Constraints.  In Figure 5 you see that a standard class box has been used to define the interface PersistentObject (note the use of the <<interface>> stereotype). 

2. Name Interfaces According To Language Naming Conventions3. Apply “Lollipop” Notation To Indicate That A Class Realizes an Interface4. Define Interfaces Separately From Your Classes  5. Do Not Model the Operations and Attributes of an Interface in Your Classes. In Figure 5

you’ll notice that the Shipment class does not include the attributes or operations defined by the two interfaces that it realizes. 

6. Consider an Interface to Be a Contract

 

4.        Relationship Guidelines

For ease of discussion the term relationships shall include all UML concepts such as associations, aggregation, composition, dependencies, inheritance, and realizations – in other words, if it’s a line on a UML class diagram we’ll consider it a relationship.

Figure 6. Shipping an order.

Figure 7. Modeling an order.

Figure 8. Professors and seminars.

Figure 9. Modeling people at a university.

 

 

1. Model Relationships Horizontally2. Collaboration Indicates Need for a Relationship  3. Model a Dependency When The Relationship is Transitory4. Depict Similar Relationships Involving A Common Class As A Tree.  In Figure 6 you see

that both Delivery and Order have a dependency on OIDGenerator.  Note how the two dependencies are drawn in combination in “tree configuration”, instead of as two separate lines, to reduce clutter in the diagram. 

5. Always Indicate the Multiplicity6. Avoid a Multiplicity of “*” 7. Replace Relationships By Indicating Attribute Types.  In Figure 7 you see that Customer

has a shippingAddress attribute of type Address – part of the scaffolding code to maintain the association between customer objects and address objects. 

8. Do Not Model Implied Relationships  9. Do Not Model Every Single Dependency 10. Center Names on Associations11.  Write Concise Association Names In Active Voice12. Indicate Directionality To Clarify An Association Name13. Name Unidirectional Associations In The Same Direction 14.  Word Association Names Left-To-Right15. Indicate Role Names When Multiple Associations Between Two Classes Exist16. Indicate Role Names on Recursive Associations17. Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions.

The lives at association of Figure 9 is uni-directional. 18. Redraw Inherited Associations Only When Something Changes19. Question Multiplicities Involving Minimums And Maximums

 

6.        Inheritance Guidelines

Inheritance models “is a” and “is like” relationships, enabling you to easily reuse existing data and code. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of “A.”  Furthermore, we say that we have “pure inheritance” when “A” inherits all of the attributes and methods of “B.” The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.

1. Apply the Sentence Rule For Inheritance2. Place Subclasses Below Superclasses3. Beware of Data-Based Inheritance 4. A Subclass Should Inherit Everything

 

7.        Aggregation and Composition Guidelines

Sometimes an object is made up of other objects.  For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on.  A delivery shipment contains one or more packages.  A team consists of two or more employees.  These are all examples of the concept of aggregation, which represents “is part of” relationships.  An engine is part of a plane, a package is part of a shipment, and an employee is part of a team.  Aggregation is a specialization of association, specifying a whole-part relationship between two objects.  Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts.  From a stylistic point of view, because aggregation and composition are both specializations of association the guidelines for associations apply.

Figure 10. Examples of aggregation and composition.

1. Apply the Sentence Rule for Aggregation2. You Should Be Interested In Both The Whole And The Part 3. Depict the Whole to the Left of the Part

4. Apply Composition to Aggregates of Physical Items5. Apply Composition When the Parts Share The Persistence Lifecycle With the Whole 6. Don’t Worry About Getting the Diamonds Right

Various levels of Data Flow Diagrams

1) Zero-level DFD or Context-level Data Flow DiagramThis level basically represents the input and output of the entire system.

2) 1-level DFDThe basic/care modules of the system are represented in this phase and how data mane gates through different modules is shown.

3) 2-Level DFDThe module details are represented in this level. Therefore, detailed Data Flow Diagrams can be drawn with regard to the complexity of system.

Notations in DFD’s

Data Flow Diagrams show the passage of data through the system by using fine basic constructs

1) Data Flow

It shows flow of data from a source to a destination. It is shown with an arrowed line with the arrowhead showing the direction of flow.

It can move from an external entity to a process, from a process to another process, into and out of a store from a process, and from a process to an external entity as well.

It should be noted that the ‘Data flow’ cannot occur from external entity to a store or from a store directly to an external entity.

2) Processes:

These are transformations which change incoming data flow into outgoing data flow.They are drawn in circular boxes:

The name of the process should describe what may happen to the data as it passes through the process.

3) Data/Stores

It is repository of data, that is, a file or databaseIt is represented by two parallel lines and between those lines name of data store is mentioned

4) External entities:

They are external data processing units which represent some external process, outside of the regular data flow .They rely outside the system boundaries.

5) Resource store:

It represents process with resource flow. It represents flow of material than data.

Example of Data Flow Diagrams

Data Flow Diagram (Level-0 and Level-1) for an ATM system can be represented as

Advantages of Data Flow Diagrams

It is a simplified but powerful graphic technique It enables representing data with different levels of details. It helps defining boundaries of the system