USE CLASS DIAGRAM BLOG

How to Create Class Diagrams

To create and evolve a conceptual class diagram, you need to iteratively model:

Classes

Responsibilities

Associations

Inheritance relationships

Composition associations

Vocabularies

 

Class diagram : are the best design tool for development teams. This Diagram helps developers get the structure of the system before the code is written, and helps to ensure that the system is the best design.

Clas diagram used  : to display classes and packages in the system. Class a diagram give you a static system and relation between them. Usually, make some single class diagram to systems. Some will diagram showing a subset of classes and relatives. Can be made some diagram according to desirable to get a complete picture against system built.

 

 

 

Interfaces

The purpose of a class diagram is to depict the classes within a model. In an object oriented application,

classes have attributes (member variables), operations (member functions) and relation-ships with other classes. The UML class diagram can depict all these things quite easily. The

fundamental element of the class diagram is an icon the represents a class. This icon is shown in.

Classes are interrelated to each other in specific ways. In particular, relationships in class diagrams include different types of logical connections. The following are such types of logical connections that are possible in UML: 

• Association
• Directed Association
• Reflexive Association
• Multiplicity
• Aggregation
• Composition
• Inheritance/Generalization
• Realization

Association

is a broad term that encompasses just about any logical connection or relationship between classes

Directed Association

refers to a directional relationship represented by a line with an arrowhead.

Reflexive Association

occurs when a class may have multiple functions or responsibilities

Multiplicity

is the active logical association when the cardinality of a class in relation to another is being depicted

Aggregation

refers to the formation of a particular class as a result of one class being aggregated or built as a collection

Composition

is very similar to the aggregation relationship, with the only difference being its key purpose of emphasizing the dependence of the contained class to the life cycle of the container class.

Inheritance

refers to a type of relationship wherein one associated class is a child of another by virtue of assuming the same functionalities of the parent class

Realization

denotes the implementation of the functionality defined in one class by another class.

Simple class diagram with attributes and operations

In the example, a class called “loan account” is depicted. Classes in class diagrams are represented by boxes that are partitioned into three:

The top partition contains the name of the class.

The middle part contains the class’s attributes.

The bottom partition shows the possible operations that are associated with the class.

Those should be pretty easy to see in the example: the class being described is a loan account, some of whose attributes include the type of loan, the name of the borrower/loaner, the specific date the loan was released and the loan amount. As in the real world, various transactions or operations may be implemented on existing loans such as renew and extend.  The example shows how class diagrams can encapsulate all the relevant data in a particular scenario in a very systematic and clear way.

In object-oriented modeling, class diagrams are considered the key building blocks that enable information architects, designers, and developers to show a given system’s classes, their attributes, the functions or operations that are associated with them, and the relationships among the different classes that make up a system.

UseCase Diagram Blog

          Use case diagrams describe the expected functionality of a system. The emphasis is on " what " is done for the system , and not the " how ". A use case represents an interaction between the actors in the system. Use case is a specific job , such as logging into the system , clicking -create a shopping list , and sebagainya.Seorang / an actor is a human or a machine entity that interacts with the system to perform certain tasks. Use case diagrams can be very helpful when we are putting together a system of requirements , design communicate with clients , and designing test cases for all the features that exist on the system. A use case can either include another use case functionality as part of a process in itself. It is generally assumed that the use case will be invoked every time include use cases include the clicking - executed normally. A use case can be include by more than one other use case , so that duplication of functionality can be avoided by pulling out the common functionality. A use case can also be extended another use case with its own behavior.While the relationship between use case generalization shows that one use case is a specialization of the other.

Relations in the Use Case

• There are some relationships that are in use case diagram :

1. Association, the connecting link between the elements.
2. Generalization , also called inheritance ( inheritance ) , an element can be a specialization of another element.
3. Dependency , an element depends in some way to every other element.
4. Aggregation , Association forms in which an element contains other elements.

• Types of relationships / stereotypes that may occur in the Use Case diagram :

1. << include >>, behavior that must be met so that an event can occur , where the condition is a use case is part of another use case.
2. << extends >>, behavior that runs only under certain conditions such as moving the alarm.
3. Communicates << >>, may be added to the association that showed association was Communicates association.This is the association of choice for the type of relationship that allowed only between actor and use case.

• Use case diagrams consist of :

1. Use case

Use case purpose made ​​based actor , is " what " the system worked , not " how " the system do it . Use case is named that states what is achieved from the interaction with the actors . Use case denoted with images ( horizontal ellipse ) Use case usually use the verb use case name should consist of a few words and there should be no two use cases that have the same name .

      2.  Actors

• Actor describe people , systems or external entities / stakeholders who provide or receive information from the system
• Actor describe a task / role and position rather than a position
• Actor giving input or receive information from the system
• Actor normally use nouns
• There should be no direct communication between actors
• Indication << system >> to an actor that is a system
• The actor is named " Time " which indicate scheduled events ( an event that occurs periodically / monthly )
•  Put your main actor in the top left corner of the diagram

in this case, I made ​​a usecase diagram on the blog.

you are a blogger / user, when the user will manage profile, manage comment or post an article she must log in first. A user will manage its profile by inputting personal data that can be read by the viewer, users can also edit your profile or if there error can also delete a user profile. Before its users post an article, the user will make his first article. When there was a post already in less then he can edit his article. The article was also posted by the user can delete. The viewer who opened his blog can read the article that was in the post and can also leave comments on the blog. Once the viewer to give comments on his blog, users can reply to comments of the viewer to be more close to the viewer, especially if the user can answer the question her directly through the reply comments.

Actor :

• User

• Viewer

Use Case :

• Log On

• Manage Profile

• Input New Profile

• Edit

• Delete Profile

• Posting Article

• Create Article

• Edit Article

• Delete Article

• Article Reply

• Manage Comment

• View Article

• Comment Articel