Documente Academic
Documente Profesional
Documente Cultură
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