Concepts :
1) Use Case Diagram
2) Class Diagram
3) Object Diagram
4) Sequence Diagram
5) State Diagram
6) Activity Diagram
7) Package Diagram
8) Component Diagram
9) Deployment Diagram
In this post we'll discuss about Use Case Diagram and Class Diagram
1) Use Case Diagram
The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.
A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. As you discuss the functionality and processes of the system, you discover significant characteristics of the system that you model in the use case diagram. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system.
Elements of a Use Case Diagram:
A use case diagram is quite simple in nature and depicts two types of elements: one representing the business roles and the other representing the business processes. Let us take a closer look at use at what elements constitute a use case diagram.
Actors: An actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure 1.1.
To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.
Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. The key term here is "distinct business functionality." To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. As the first step in identifying use cases, you should list the discrete business functions in your problem statement. Each of these business functions can be classified as a potential use case. Remember that identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident. A use case is shown as an ellipse in a use case diagram (see Figure 1.2).
System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system
The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case. For large and complex systems, each of the modules may be the system boundary. For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. The entire system can span all of these modules depicting the overall system boundary.
Relationships in Use Cases:
Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. This reuse of an existing use case using different types of relationships reduces the overall effort required in defining use cases in a system. A similar reuse established using relationships, will be apparent in the other UML diagrams as well. Use case relationships can be one of the following:
Include: When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship. Literally speaking, in an include relationship, a use case includes the functionality described in the another use case as a part of its business process flow. An include relationship is depicted with a directed arrow having a dotted shaft. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<
For example, in Figure 1.4, you can see that the functionality defined by the "Validate patient records" usecase is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" usecase executes, the business steps defined in the "Validate patient records" use case are also executed.
Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<>" identifies as extend .
Above figure shows an example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use case.
• Generalizations: A generalization relationship is also a parent-child relationship between use cases. The child use case in the generalization relationship has the underlying business process meaning, but is an enhancement of the parent use case. In a use case diagram, generalization is shown as a directed arrow with a triangle arrowhead (see Figure 3.6). The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case.
On the face of it, both generalizations and extends appear to be more or less similar. But there is a subtle difference between a generalization relationship and an extend relationship. When you establish a generalization relationship between use cases, this implies that the parent use case can be replaced by the child use case without breaking the business flow. On the other hand, an extend relationship between use cases implies that the child use case enhances the functionality of the parent use case into a specialized functionality. The parent use case in an extend relationship cannot be replaced by the child use case.
Let us see if we understand things better with an example. From the diagram of a generalization relationship (refer to Figure 1.6), you can see that "Store patient records (paper file)" (parent) use case is depicted as a generalized version of the "Store patient records (computerized file)" (child) use case. Defining a generalization relationship between the two implies that you can replace any occurrence of the "Store patient records (paper file)" use case in the business flow of your system with the "Store patient records (computerized file)" use case without impacting any business flow. This would mean that in future you might choose to store patient records in a computerized file instead of as paper documents without impacting other business actions.
Now, if we had defined this as an extend relationship between the two use cases, this would imply that the "Store patient records (computerized file)" use case is a specialized version of the "Store patient records (paper file)" use case. Hence, you would not be able to seamlessly replace the occurrence of the "Store patient records (paper file)" use case with the "Store patient records (computerized file)" use case.
Significance:
• A set of use cases and actors and their relationships.
• Important for organizing and modeling system behaviors.
• Cruicial for requirements management and communication with end users using their own domain terminology.
• Uses very few symbols, all software independent
2) The Class Diagram
So, what is a class diagram? Imagine you were given a task of drawing a family tree. The steps you would take would be:
• Identify the main members of the family
• Determine how they are related to each other
• Identify the characteristics of each family member
• Find relations among family members
• Decide the inheritance of personal traits and characters
A class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes.Similarly, a software application is comprised of classes and a diagram depicting the relationship between each of these classes would be the class diagram.By definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces.
A class diagram is a pictorial representation of the detailed system design. Design experts who understand the rules of modeling and designing systems design the system's class diagrams. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system.When you designed the use cases, you must have realized that the use cases talk about "what are the requirements" of a system. The aim of designing classes is to convert this "what" to a "how" for each requirement. Each use case is further analyzed and broken up into atomic components that form the basis for the classes that need to be designed.
Elements of a Class Diagram:
A class diagram is composed primarily of the following elements that represent the system's business entities.
Class: A class represents an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. Apart from business functionality, a class also has properties that reflect unique features of a class. The properties of a class are called attributes. Simply put, individual members of a family of our family tree example are analogous to classes in a class diagram.
As an example, let us take a class named Student. A Student class represents student entities in a system. The Student class encapsulates student information such as student id #, student name, and so forth. Student id, student name, and so on are the attributes of the Student class. The Student class also exposes functionality to other classes by using methods such as getStudentName(), getStudentId(), and the like. Let us take a look at how a class is represented in a class diagram.
A class is represented by a rectangle. The following diagram shows a typical class in a class diagram:
If you are familiar with object-oriented concepts, you will be aware of the concept of access modifiers. You can apply access modifiers such as public access, protected access, and private access applied to methods and attributes of a class—even to a class as well, if required. These access modifiers determine the scope of visibility of the class and its methods and attributes.
You also can add documentation information to a class. Notes and constraints can be added to a list of attributes. Notes contain additional information for reference while developing the system, whereas constraints are the business rules that the class must follow, and are text included in curly brace brackets.
During the early phase of the system design conception, classes called Analysis classes are created. Analysis classes are also called stereotypes. In the UML context, stereotypes are UML models that represent an existing UML element, while showing additional characteristics that are common across the classes to be used for that application. Only one stereotype can be created for any UML element in the same system.
Analysis classes are of the following types as per their behavior, as shown in the following table:
Class Behavior:
Boundary :In an ideal multi tier system, the user interacts only with the boundary classes. For example, JSPs in a typical MVC architecture form the boundary classes.
Control: These classes typically don't contain any business functionality. However, their main task is to transfer control to the appropriate business logic class, depending on a few inputs received from the boundary classes.
Entity :These classes are those that contain the business functionality. Any interactions with back-end systems are generally done through these classes.
Interface: An interface is a variation of a class. As we saw from the previous point, a class provides an encapsulated implementation of certain business functionality of a system. An interface on the other hand provides only a definition of business functionality of a system. A separate class implements the actual business functionality.
So, why would a class not suffice? You can define an abstract class that declares business functionality as abstract methods. A child class can provide the actual implementation of the business functionality. The problem with such an approach is that your design elements get tied together in a hierarchy of classes. So, even though you may not have intended to connect your design elements representing drastically different business entities, that is what might result. Hence, the use of the interface design construct in class diagrams. Different classes belonging to different and discrete hierarchies can maintain their distinct hierarchies and still realize the functionality defined in the methods of the interface.
An interface shares the same features as a class; in other words, it contains attributes and methods. The only difference is that that the methods are only declared in the interface and will be implemented by the class implementing the interface.
In addition to the above, there is one more element used in class diagrams:
Package: A package provides the ability to group together classes and/or interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of class diagrams, especially complex class diagrams.
Relationships between Classes:
In a class diagram, obviously you can't have classes just floating around; you need to see the relationship between them. The following table shows the kinds of relationships between classes, their notation, and what they mean.
1 Association
When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:
1 a. Multiplicity
An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).
1 b. Directed Association
Association between classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.
1 c. Reflexive Association:
No separate symbol. However, the relation will point back at the same class. An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.
2 Aggregation
When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.
2 a. Composition
Composition is a variation of the aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.
3 Inheritance/Generalization
Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.
4 Realization
In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.
Significance:
• A set of classes, interfaces, collaborations, and relationships
• Reflects the static design of a system.
• Can be confusing if used to explain system dynamics; use less abstract Object Diagrams instead.
Watch out here for interesting continuation on other types of UML diagrams
No comments:
Post a Comment