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  ► 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 
MODELS  comprehensive, but descriptions (elements) are stationary; inventory of what 
Meta Model – Defines concepts of Class, Attribute, Operation..etc.  exists in the system and attributes and methods contained within those 
  elements. 
Model – Defines the language to use to describe the domain   
e.g.: Defines the concepts of Order, Shipment, Product, ProductID, Buy()  Class Diagram – models the rules about types of objects (classes), the source 
  for code generation and system and sub‐system auditing. 
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   
 
 
Object Diagram – illustrates facts in the form of objects to model examples 
► Functional View – functions are expresses initially as goals, then fleshed 
and test data. 
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)   
   
 
 
 
1 
 
► Dynamic View – represents how objects work together and interact and  2) Constraints ‐  are limitations/boundaries around what you can do 
respond to the environment  to develop a solution for the system; it limits the options you have 
Sequence Diagram/Collaboration Diagrams – describe how object talk to  at every phase of development. Type of constraints: user limits 
each other  like client skills; limitations imposed by policies, procedures, laws, 
Statechart Diagrams – looks at how an object reacts to external stimuli and  contracts; technical limits like protocols, legacy, data conversions, 
manages internal changes; how and why object changes over time  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 
 
   
4 REQUIREMENT CATEGORIES:  †  USE CASE 
1) Business Process – To use a system, you need to know how to  Use Case Model includes: 1) diagram, 2) narrative & 3) scenarios. 
interact with it and why; describe your relationship with the  Use Cases focuses on critical success factors of the system. Features can be 
system in terms of interactions; look beyond the process into the  tested, modeled, designed and implemented 
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 
 
 • 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 
 

 
 
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)   

3 
 
  
 

 
 

 
 
   
 
 

 
Basic Association Notations: 
 

 
 

 
 

4 
 
ASSOCIATION, AGGREGATION and COMPOSITION  An Aggregation and Composition Relationship 
  Aggregation is special type of association 
 
 

 
 
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) 
 
 
 
 
 
 
 
 
 

5 
 
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. 
 

 
 
 
Message Stimulus (call, signal, response) 

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

 
 

 
 
 
 
6 
 
Message Stimulus (call, signal, response)   
  Diamond icon is also used to model a merge point, the place 
  where two alternative paths can come together. 
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.  Use Fork to show concurrency (synchronization or merging) 
  of concurrent threads or processes. 

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

 
 
Decisions are placed with guard conditions 

 
 

 
7 
 
 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) 
REQUIREMENTS ANALYSIS:  ƒ Classes and Class Attributes (Class Diagrams) 
   
ƒ Identify sources of requirements (elicitation)  Verb: 
ƒ Record business rules  Actions, things a user can do, or events that can take place 
ƒ Specify quality attributes   
ƒ Identify risks and constraints  ƒ Processes (DFD) 
ƒ Identify system events and responses  ƒ Use‐Cases (UCD) 
ƒ Draw context diagrams  ƒ Relationships (ERD – Entity Relationship Diagram) 
ƒ Create prototypes  Transitions (STD – State Transition Diagram) 
ƒ Analyze Feasibility  ƒ Activities (Activity Diagram) 
ƒ Prioritize requirements   
ƒ Allocate and organize requirements to subsystems   
ƒ Apply quality function deployment (test requirements)  Guideline Writing Requirements: 
ƒ Inspect requirement documents   
ƒ Perform change impact analysis  ƒ Write short and direct sentences. 
ƒ Baseline and control requirement versions  ƒ Use the active voice (The system shall do  <function>) 
ƒ Maintain change history  ƒ Use terms consistently; defined in glossary; watch for 
ƒ Create requirements traceability matrix  synonyms 
  ƒ Decompose vague and insufficient detail to clarify and 
ELICITATION TECHNIQUES  remove ambiguity 
  ƒ Use : The user shall or the system shall in a consistent 
ƒ Identify user classes (partition users based on features  fashion 
used, frequency, privilege levels and skill levels)  ƒ Specify trigger condition or action that cuase the system 
ƒ Establish focus groups  to perform the specified behavior 
ƒ Select product champions (act as the voice of the  ƒ You may use word “must” ; avoid “should, must, might”  
customer)  ƒ Specify the specific actor instead of “The user shall…” 
ƒ Hold facilitated elicitation workshops   
ƒ Observer workers in jobs (shadow)   
ƒ Examine problem reports and bugs 
ƒ Reuse and salvage viable requirements 
 
 
 
 
 
 
 
 
 

8