UML 2.0 Cheatsheet

1  

UML 2.0 Reference Card Meta Model = set of definitions 

• It has a precise syntax 

• Describes underlying meaning of each element 

• Draws relationships among elements 

• Model consist of domains / ontology / hierarchies  Class includes:  

• Component parts 

• Attributes 

• Operations  MODELS Meta Model – Defines concepts of Class, Attribute, Operation..etc.  Model – Defines the language to use to describe the domain e.g.: Defines the concepts of Order, Shipment, Product, ProductID, Buy()  User Objects – Defines Order #12322, Shipment #4545,  the product: CD ROM, Price  METHODOLOGIES consist of: 

• Process – A set of activities that accomplish the goals 

• Vocabulary – Used to describe the process and the work products 

• A Set of Rules and Guidelines – Define the quality of the process and work products 

 The vocabulary (expressed as notation) is applicable to many methodologies  3 PRIMARY VIEWS: View is a collection of diagrams that describe a similar aspect of a project: Views the system from the perspective of how external entities (ppl & systems) need to interact with the system  ► Functional View – functions are expresses initially as goals, then fleshed out in narrative to describe what the function is expected to do to achieve the goal;  Models the workflow & business process  

   Use Case Diagram – describes the features that the users expect the system to provide Activity Diagram – describes processes including sequential tasks, conditional logic, and concurrency (flowchart enhanced for use with object modeling)  

                   ► Static View – provide a snapshot of elements of the system; but do not tell you have the elements behave; analogy of a blueprint which are comprehensive, but descriptions (elements) are stationary; inventory of what exists in the system and attributes and methods contained within those elements.  Class Diagram – models the rules about types of objects (classes), the source for code generation and system and sub‐system auditing.  

  Object Diagram – illustrates facts in the form of objects to model examples and test data. 

2  

► Dynamic View – represents how objects work together and interact and respond to the environment Sequence Diagram/Collaboration Diagrams – describe how object talk to each other Statechart Diagrams – looks at how an object reacts to external stimuli and manages internal changes; how and why object changes over time   

4 REQUIREMENT CATEGORIES: 1) Business Process – To use a system, you need to know how to 

interact with it and why; describe your relationship with the system in terms of interactions; look beyond the process into the reason of the process (justification of having the process) 

• What results does the operation/process produce? 

• What would happen to the rest of the system if you didn’t have the process in place? 

• Would another alternative process fail?  Focus on results than processes; quantify the value of the results; allocate resource proportional to the value of results  

2) Constraints ‐  are limitations/boundaries around what you can do to develop a solution for the system; it limits the options you have at every phase of development. Type of constraints: user limits like client skills; limitations imposed by policies, procedures, laws, contracts; technical limits like protocols, legacy, data conversions, data types and sizes; performance limits that conflict with or sabotage business requirements. 

 3) Rules – where constraints are like mandates, rules are 

agreements. Rules should be enforced but if a better way to do something is found, it can be negotiable to the stakeholders; business directives and decisions derived from legislation, regulations are common; rules refocus your attention on why the client is doing the job a particular way. 

 4) Performance – how well the system should perform when you 

use it; questions on how many users will use the system? How many concurrently? How slow can the system be before it interferes with work, operation or transaction? 

Object Orientated Principles (OOP) :  Abstraction is a representation of something; only describes information that you need in order to solve a problem. The rules that define the representation make up a class. (Defintion, template, blueprint) An object is an instance (representation) of the class which created, manufactured or instantiated.  To function properly, every object has to know: 

• Its own current condition (state) 

• Can describe itself 

• Knows what it can do 

• What can be done to it  Encapsulation 

• What you need to know in order to use the object 

• What you need to know to make the object work properly 

• (exposing interfaces)  What needs to be inside the object to work properly: 

• Implementations for each interface 

• Data that describes the structure of the object 

• Data that describes the current state of the object Purpose drives the design and use of the object 

   USE CASE 

Use Case Model includes: 1) diagram, 2) narrative & 3) scenarios. Use Cases focuses on critical success factors of the system. Features can be tested, modeled, designed and implemented 

3  

  Elements of Use Case Diagram:  

• System‐ sets the boundary of the system in relation to the actors who use it (outside the system) and the features it must provide (inside the system) 

• Actor – a role played by a person, system, or device that has a stake in the successful operation of the system 

• Use Case – key feature, without the system will not fulfill the user/actor requirements. 

• Association – identifies an interaction between actors and use cases. Each association becomes a dialog that must be explained in the narrative. 

• Dependency – identifies communication relationship between two use cases. 

• Generalization – defines a relationship between two actors or two use cases where the use case inherits and adds to or overrides the properties of another. 

 Set the context of the target system (frame of reference); problem statement; context defines place of the system within the business, work processes, people, objectives, dependent systems, job duties, constraints impositions. 

• Identify the actors (person or system) 

• Identify the use cases. What does the system produce for the actor (critical outputs)? What does the actor help the system do? What does the system 

do to help the actor. 

• Define associations  Relationship Notations: 

• Association notation – actor communicates with the Use Case Stereotype notation use of << >> on UML classifiers like: classes, Use Case Dependencies, Packages 

• <<include>> ‐ when a use case always asks for help from another use case; need to delegate some duties  

• <<extend>> ‐ when a use case might asks for help from another use case 

 Elements of a Use Case Narrative: 

• Assumptions – state of the system that must be true before needed conditions are met 

• Pre‐conditions – same as assumptions except it is tested by the system 

• Use Case Initiation – trigger to launch use case; what is the triggering mechanism? 

• Process or Dialog – step‐by‐step description of the conversation between use case (system) and the actor; sequence of events (match with activity diagram) 

• Use Case Termination – Normal and Abnormal ( Error Messaging / Cancelling / Rollbacks ) 

• Post‐ Conditions – state of the system that must be true when the use case ends 

Building Attributes in Class Diagram  

4  

 Basic Association Notations:  

5  

ASSOCIATION, AGGREGATION and COMPOSITION  

Player may be a member of no more than one Team, comprised of exactly nine players (9..9). A Player is considered a member of a Team.   

• Each player may or may not be a member of the team  

• Chapter cannot exist independent of the Book, so it must be composition relationship 

  Player class is related to the Team Class  

1. Draw an association between classes 2. Draw a diamond on the end of the association 3. Assign the appropriate multiplicities  ( 1..n) 

An Aggregation and Composition Relationship Aggregation is special type of association 

6  

Activity Diagram • Isolate each task as an activity. Indicate the sequence of 

task by drawing the transition arrow from one activity to another. 

• Multiple processes may take place at the same time, so use a fork and synchronization bar to show completion of multiple processes. 

• Use [ brackets ] to show conditionals 

• End points are designated with the bullseye icon.  

All sequence diagrams are modeled at the object level instead of the class level.  

Message Stimulus (call, signal, response) 

7  

Message Stimulus (call, signal, response)   Messages may be synchronous (requiring a response) or asynchronous (not requiring a response). A simple or synchronous message uses a solid line with a solid arrow.  

  Activity is a step in process where work is getting done. It can be a calculation, manipulation, or verifying the data.  

  A guard is when certain things have happened before continuing on; place conditions in square bracket 

  Decisions are placed with guard conditions 

 Diamond icon is also used to model a merge point, the place where two alternative paths can come together. 

  Use Fork to show concurrency (synchronization or merging) of concurrent threads or processes. 

8  

  REQUIREMENTS ANALYSIS:   Identify sources of requirements (elicitation)  Record business rules  Specify quality attributes  Identify risks and constraints  Identify system events and responses  Draw context diagrams  Create prototypes  Analyze Feasibility  Prioritize requirements  Allocate and organize requirements to subsystems  Apply quality function deployment (test requirements)  Inspect requirement documents  Perform change impact analysis  Baseline and control requirement versions  Maintain change history  Create requirements traceability matrix  ELICITATION TECHNIQUES   Identify user classes (partition users based on features 

used, frequency, privilege levels and skill levels)  Establish focus groups  Select product champions (act as the voice of the 

customer)  Hold facilitated elicitation workshops  Observer workers in jobs (shadow)  Examine problem reports and bugs  Reuse and salvage viable requirements          

Model System Components:  Noun : People, organizations, software subsystems, data items, or objects that exist  

Terminators or data stores (DFD‐ Data Flow Diagrams) 

Actors (Use Cases)  Entities and Attributes (ERD Diagrams)  Classes and Class Attributes (Class Diagrams) 

 Verb: Actions, things a user can do, or events that can take place  

Processes (DFD)  Use‐Cases (UCD)  Relationships (ERD – Entity Relationship Diagram) 

Transitions (STD – State Transition Diagram)  Activities (Activity Diagram) 

Guideline Writing Requirements:   Write short and direct sentences.  Use the active voice (The system shall do  <function>)  Use terms consistently; defined in glossary; watch for 

synonyms  Decompose vague and insufficient detail to clarify and 

remove ambiguity  Use : The user shall or the system shall in a consistent 

fashion  Specify trigger condition or action that cuase the system 

to perform the specified behavior  You may use word “must” ; avoid “should, must, might”   Specify the specific actor instead of “The user shall…”