Uml 2
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Uml 2 as PDF for free.
More details
- Words: 1,908
- Pages: 11
What the heck is UML? UML is the Unified Modeling Language. Personally I don’t know why it’s called a Language, because it’s not really a language persay. The Unified Modeling Language was formed in attempt to unify the best (or most popular in this case) methods in ObjectOriented Analysis and Design. Those concepts come from the leaders in the field of OO: Grady Booch, James Rumbaugh and Ivar Jacobson. The different models are pulled from each of the individual methods and bring in a contribution from each one. For example, the class model is very similar to OMT or the Rumbaugh method. The Use Case Model is brought in from Ivar Jacobson and the implementation model is from Booch. Some models, such as State and Sequence, are a combination of a few methods, taking concepts from each of the methodologies and even adding some new concepts.
Why do I need to use UML when I can just construct all the GUI and classes in my IDE Environment? Probably this is the largest excuse for not using Object Modeling, but the truth is, there is something to be said for modeling your software before you actually code it. Just try it once and see if your design doesn’t come out 100x better. There is always that reluctance to see the big picture up front, but it will make a difference in the long run and probably shorten your development cycle. My project is rushed. I don’t have time to document everything, my boss wants it tommorrow! This UML stuff is a waste of my valuable time! Again, a good up front design will actually shorten the development cycle, give you an idea of the resources you need, and how to break up the project. It will also make the amount of support you do in the long run a little easier (although support is job security ;-) ) Why UML, why not just pad and paper? I often have the whole design in my head anyway. It’s nice to have a standard model to work from. This way if you have a team of developers, everyone on the team now speaks the same language. A design in your head doesn’t do the rest of the people you work with any good. Ok, now that we’ve addressed why you should bother learning UML in the first place, below is an introduction to what UML is all about:
The Class Model
The Unified Modeling language has several models that help you describe the software system you are trying to represent. Each model represents a different aspect of the software description. The Class Model is the static architectural representation of your software and often a good starting point. It allows you to see the overall object structure of the software system. Below is a class represented in UML: Fig 1.
The Account is the name of the class representing the definition of an Account. The Value is an attribute of the Account representing the amount of money in the account. Withdraw and Deposit are methods to Add/Delete money to the account. The – and + signs are visibility indicators used to show encapsulation. The minus says that Value is a private member of class Account and can only be seen by methods of the Account class. The plus represents public members, so WithDraw and Deposit can be accessed outside the Account class. The void after the colon are the return types from the class. UML Can also represent the relationships between classes:
Fig 2.
Inheritance is represented by a triangle and SavingsAccount is a subclass of Account, inheriting all of the Attributes and Operations of the Account Class. Aggregation is represented by a diamond. A Bank has many Accounts. The asterisk near the Accounts represents many and the 1 near the bank represents one.
Anotherwords there is a one to many relationship between Bank and Accounts. Aggregation is a whole-part relationship. A Bank has Accounts, so the diamond is positioned near the container to represent the accounts are the parts of the bank. Noticed we also added another subclass CheckingAccount to represent another type of account in are system. The below diagram shows that our bank has many accounts some of which are savings accounts and some which are checking accounts.
Fig 3. A system which represents a group of related classes can often be placed together in what is called a package. Below is the representation of our Banking System as part of the Banking Package. Packages help us to organize our class diagrams and represent them at a higher level.
Fig 4. Packages can group together libraries, gui objects or other related classes. Note the <<subsystem>> indicator under the banking package. This <<>> indicator is called a stereotype. Stereotypes are used profusely throughout UML and basically are a way to enhance the description of any UML model component. For example Attributes, Operation, and Classes can all have stereotypes to describe further the category they are in. The dotted arrow is called a dependency. It is used to show that one UML Element depends upon another. Dependencies can be used to describe the relationship between classes, packages, or components.
Fig 5.
There is much, much more detail that can be described with the UML model, but we are only giving an introduction here, so we will move on to another useful model called the sequence diagram. The sequence diagram describes the flow of messages being passed from object to object. Unlike the class diagram, the sequence diagram represents dynamic message passing between instances of classes rather than just a static structure of classes. In some ways, a sequence diagram is like a stack trace of object messages. Below is a sample sequence diagram
Fig 6.
The Sequence diagram allows the person reading the documentation to follow the flow of messages from each object. The vertical lines with the boxes on top represent instances of the classes (or objects). The label to the left of the colon is the instance and the label to the right of the colon is the class. The horizontal arrows are the messages passed between the instances and are read from top to bottom. Here we have a customer (user) depositing money into MyAccount which is an instance of Class SavingsAccount. Then MyAccount object Validates the account by asking the Bank object, MyBank to
ValidateAccount. Finally, the Customer Asks the ATM object for a Receipt by calling the ATM’s operation GetReceipt. The white rectangle indicate the scope of a method or set of methods occurring on the Object My Bank. The dotted line is a return from the method ValidateAccount. Another useful model of UML is the Use Case Diagram. So what is a Use Case you may ask? Personally, I feel a use case was a way for UML people to introduce structured design into an object design model, but who am I to judge? Anyway, a use case is a bubble describing a particular an activity that a User Performs. Each Use Case could be thought of as having a sequence scenario behind it. A Use Case is acted upon by a user or actor. Below is a use case for depositing a check
Fig 7. The Ovals represent the different actions of each of the actors. The Customer Deposits a check, the ATM prints the receipt. Note that Use Case don’t represent any sequence or time events, they just tell you the list of cases and how each user acts upon that case. Use cases can be more descriptive by using extend and uses relationships. Below is an example of how the Print Receipt Case is extended. An extended case is a subtype of the existing case. Here we extended case Print Receipt in two ways: (1) Print a Receipt on the screen, (2) print the receipt on a piece of paper. Both cases are still printing a receipt so they are of the same type.
Fig 8. Also we have a “uses” relationship. Below a “Deposit Check” Case consists of the subcases Validate Check and Transfer Check to the Account. These cases are not of the type Deposit Check, but are tasks that compose the entire task of Depositing a Check.
Fig 9.
State Diagrams are another model in UML that allow you to actually describe the timing taking place in your system. State Diagrams have been around a long time in logical design and have proved very useful for concurrent and real-time systems. A state diagram consists mostly of states and transitions. It often represents the different states a class can undergo and the events that effect a change in state in the class
In our ATM machine example the key entry of a users password can be represented as a set of states:
Fig 10. The initial state is represented by a small black circle, wait states are represented by rounded rectangles, and the final state is represented by a small black circle surrounded by a white circle. Transitions are the arrows going from one state to another. A transition is triggered by an event. An event can be a key press, mouse movement or a menu selection for example. The event is an activity either from the user or the system that causes a change of state. In the example above, # pressed and Cancel pressed are examples of events from the user. Usually an event causes some sort of action to occur when the system is changing state. The action is represented by the slash followed by the action, e.g. /Display. Display is most likely an operation in a class to tell the screen to display the key being pressed. Another characteristic of transitions is known as a condition. Conditions can be coupled with an event to determine if a change of state occurs. In our example, in order to go from the ‘Start’ state to the ‘NextNumber’ state a key must be pressed (the event) and the first digit must be greater than 0 (the condition). Conditions are represented in UML surrounded with square brackets [ ].
Another model coming out of UML which I often think of as the brother to the state diagram, is the Activity Diagram. The Activity Diagram in some ways is like a flowchart with states. With the activity diagram you can follow flow of activities in your system in the order that they take place. Below is an activity diagram for making a deposit.
Fig 11. Note the activity diagram looks like a cross between a state diagram, a use case diagram and a flowchart. Activities look similar to states but they are a bit more rounded. They are stateless in that they take place and automatically transition to the next state upon finishing. The diamond is a conditional branch that determines which activity to transition too based on a condition and it is also stateless. In our example, if the deposited check is valid, a receipt is printed. Otherwise, if its not a valid check then the
activity is to reject the deposit. The solid black bar is a synch state. This state simply synchs up existing activities so that they transition to the next activity at the same time.
Well this concludes part one of the beginning of our understanding of UML. In Part II we will describe some more UML models that you can add to your design arsenal.
Why do I need to use UML when I can just construct all the GUI and classes in my IDE Environment? Probably this is the largest excuse for not using Object Modeling, but the truth is, there is something to be said for modeling your software before you actually code it. Just try it once and see if your design doesn’t come out 100x better. There is always that reluctance to see the big picture up front, but it will make a difference in the long run and probably shorten your development cycle. My project is rushed. I don’t have time to document everything, my boss wants it tommorrow! This UML stuff is a waste of my valuable time! Again, a good up front design will actually shorten the development cycle, give you an idea of the resources you need, and how to break up the project. It will also make the amount of support you do in the long run a little easier (although support is job security ;-) ) Why UML, why not just pad and paper? I often have the whole design in my head anyway. It’s nice to have a standard model to work from. This way if you have a team of developers, everyone on the team now speaks the same language. A design in your head doesn’t do the rest of the people you work with any good. Ok, now that we’ve addressed why you should bother learning UML in the first place, below is an introduction to what UML is all about:
The Class Model
The Unified Modeling language has several models that help you describe the software system you are trying to represent. Each model represents a different aspect of the software description. The Class Model is the static architectural representation of your software and often a good starting point. It allows you to see the overall object structure of the software system. Below is a class represented in UML: Fig 1.
The Account is the name of the class representing the definition of an Account. The Value is an attribute of the Account representing the amount of money in the account. Withdraw and Deposit are methods to Add/Delete money to the account. The – and + signs are visibility indicators used to show encapsulation. The minus says that Value is a private member of class Account and can only be seen by methods of the Account class. The plus represents public members, so WithDraw and Deposit can be accessed outside the Account class. The void after the colon are the return types from the class. UML Can also represent the relationships between classes:
Fig 2.
Inheritance is represented by a triangle and SavingsAccount is a subclass of Account, inheriting all of the Attributes and Operations of the Account Class. Aggregation is represented by a diamond. A Bank has many Accounts. The asterisk near the Accounts represents many and the 1 near the bank represents one.
Anotherwords there is a one to many relationship between Bank and Accounts. Aggregation is a whole-part relationship. A Bank has Accounts, so the diamond is positioned near the container to represent the accounts are the parts of the bank. Noticed we also added another subclass CheckingAccount to represent another type of account in are system. The below diagram shows that our bank has many accounts some of which are savings accounts and some which are checking accounts.
Fig 3. A system which represents a group of related classes can often be placed together in what is called a package. Below is the representation of our Banking System as part of the Banking Package. Packages help us to organize our class diagrams and represent them at a higher level.
Fig 4. Packages can group together libraries, gui objects or other related classes. Note the <<subsystem>> indicator under the banking package. This <<>> indicator is called a stereotype. Stereotypes are used profusely throughout UML and basically are a way to enhance the description of any UML model component. For example Attributes, Operation, and Classes can all have stereotypes to describe further the category they are in. The dotted arrow is called a dependency. It is used to show that one UML Element depends upon another. Dependencies can be used to describe the relationship between classes, packages, or components.
Fig 5.
There is much, much more detail that can be described with the UML model, but we are only giving an introduction here, so we will move on to another useful model called the sequence diagram. The sequence diagram describes the flow of messages being passed from object to object. Unlike the class diagram, the sequence diagram represents dynamic message passing between instances of classes rather than just a static structure of classes. In some ways, a sequence diagram is like a stack trace of object messages. Below is a sample sequence diagram
Fig 6.
The Sequence diagram allows the person reading the documentation to follow the flow of messages from each object. The vertical lines with the boxes on top represent instances of the classes (or objects). The label to the left of the colon is the instance and the label to the right of the colon is the class. The horizontal arrows are the messages passed between the instances and are read from top to bottom. Here we have a customer (user) depositing money into MyAccount which is an instance of Class SavingsAccount. Then MyAccount object Validates the account by asking the Bank object, MyBank to
ValidateAccount. Finally, the Customer Asks the ATM object for a Receipt by calling the ATM’s operation GetReceipt. The white rectangle indicate the scope of a method or set of methods occurring on the Object My Bank. The dotted line is a return from the method ValidateAccount. Another useful model of UML is the Use Case Diagram. So what is a Use Case you may ask? Personally, I feel a use case was a way for UML people to introduce structured design into an object design model, but who am I to judge? Anyway, a use case is a bubble describing a particular an activity that a User Performs. Each Use Case could be thought of as having a sequence scenario behind it. A Use Case is acted upon by a user or actor. Below is a use case for depositing a check
Fig 7. The Ovals represent the different actions of each of the actors. The Customer Deposits a check, the ATM prints the receipt. Note that Use Case don’t represent any sequence or time events, they just tell you the list of cases and how each user acts upon that case. Use cases can be more descriptive by using extend and uses relationships. Below is an example of how the Print Receipt Case is extended. An extended case is a subtype of the existing case. Here we extended case Print Receipt in two ways: (1) Print a Receipt on the screen, (2) print the receipt on a piece of paper. Both cases are still printing a receipt so they are of the same type.
Fig 8. Also we have a “uses” relationship. Below a “Deposit Check” Case consists of the subcases Validate Check and Transfer Check to the Account. These cases are not of the type Deposit Check, but are tasks that compose the entire task of Depositing a Check.
Fig 9.
State Diagrams are another model in UML that allow you to actually describe the timing taking place in your system. State Diagrams have been around a long time in logical design and have proved very useful for concurrent and real-time systems. A state diagram consists mostly of states and transitions. It often represents the different states a class can undergo and the events that effect a change in state in the class
In our ATM machine example the key entry of a users password can be represented as a set of states:
Fig 10. The initial state is represented by a small black circle, wait states are represented by rounded rectangles, and the final state is represented by a small black circle surrounded by a white circle. Transitions are the arrows going from one state to another. A transition is triggered by an event. An event can be a key press, mouse movement or a menu selection for example. The event is an activity either from the user or the system that causes a change of state. In the example above, # pressed and Cancel pressed are examples of events from the user. Usually an event causes some sort of action to occur when the system is changing state. The action is represented by the slash followed by the action, e.g. /Display. Display is most likely an operation in a class to tell the screen to display the key being pressed. Another characteristic of transitions is known as a condition. Conditions can be coupled with an event to determine if a change of state occurs. In our example, in order to go from the ‘Start’ state to the ‘NextNumber’ state a key must be pressed (the event) and the first digit must be greater than 0 (the condition). Conditions are represented in UML surrounded with square brackets [ ].
Another model coming out of UML which I often think of as the brother to the state diagram, is the Activity Diagram. The Activity Diagram in some ways is like a flowchart with states. With the activity diagram you can follow flow of activities in your system in the order that they take place. Below is an activity diagram for making a deposit.
Fig 11. Note the activity diagram looks like a cross between a state diagram, a use case diagram and a flowchart. Activities look similar to states but they are a bit more rounded. They are stateless in that they take place and automatically transition to the next state upon finishing. The diamond is a conditional branch that determines which activity to transition too based on a condition and it is also stateless. In our example, if the deposited check is valid, a receipt is printed. Otherwise, if its not a valid check then the
activity is to reject the deposit. The solid black bar is a synch state. This state simply synchs up existing activities so that they transition to the next activity at the same time.
Well this concludes part one of the beginning of our understanding of UML. In Part II we will describe some more UML models that you can add to your design arsenal.
