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   



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


      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)   

► 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     


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





    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   

  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 


• •  

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)   









Basic Association Notations: 





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)     


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. 




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.   

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


    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 




    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…”     

Sign up to vote on this title
UsefulNot useful