Emdedded Assign

8/8/2019 Emdedded Assign

1/19

UML

The Unified Modeling Language (UML) is a standard language for specifying,visualizing, constructing, and documenting the artifacts of software systems,

as well as for business modeling and other non-software systems. The UML

represents a collection of best engineering practices that have proven

successful in the modeling of large and complex systems. The UML is a very

important part of developing object oriented software and the software

development process. The UML uses mostly graphical notations to express

the design of software projects. Using the UML helps project teams

communicate, explore potential designs, and validate the architectural

design of the software.

Unified Modeling Language (UML) is a standardized general-purpose modeling

language in the field ofsoftware engineering. The standard is managed, and was

created by, the Object Management Group.

UML includes a set of graphic notation techniques to create visual models of software-

intensive systems.

Goals of UML

The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive visual

modeling language so they can develop and exchange

meaningful models.

2. Provide extensibility and specialization mechanisms to

extend the core concepts.

3. Be independent of particular programming languages and

development processes.

4. Provide a formal basis for understanding the modeling

language.

5. Encourage the growth of the OO tools market.

6. Support higher-level development concepts such as

collaborations, frameworks, patterns and components.

7. Integrate best practices.
http://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Visual_modelinghttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Object_Management_Grouphttp://en.wikipedia.org/wiki/Visual_modeling


2/19

Use of UML

As the strategic value of software increases for many companies, theindustry looks for techniques to automate the production of software and to

improve quality and reduce cost and time-to-market. These techniques

include component technology, visual programming, patterns and

frameworks. Businesses also seek techniques to manage the complexity of

systems as they increase in scope and scale. In particular, they recognize the

need to solve recurring architectural problems, such as physical distribution,


3/19

concurrency, replication, security, load balancing and fault tolerance.

Additionally, the development for the World Wide Web, while making some

things simpler, has exacerbated these architectural problems. The Unified

Modeling Language (UML) was designed to respond to these needs.

UML Use Case Diagram

Use case diagrams model the functionality of a system using actors and use

cases. Use cases are services or functions provided by the system to its

users.

Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases.

Place actors outside the system's boundaries.

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the

system's functions.

Actors

Actors are the users of a system. When one system is the actor of another

system, label the actor system with the actor stereotype.


4/19

Relationships

Illustrate relationships between an actor and a use case with a simple line.

For relationships among use cases, use arrows labeled either "uses" or

"extends." A "uses" relationship indicates that one use case is needed by

another in order to perform a task. An "extends" relationship indicates

alternative options under a certain use case.

Ause case diagramis a diagram that shows the relationships amongactors and use cases within a system. Use case diagrams are often usedto:

Provide an overview of all or part of the usage requirements for a

system or organization in the form of anessentialmodel or abusiness model

Communicate the scope of a development project

Model your analysis of your usage requirements in the form ofasystem use casemodel
http://www.agilemodeling.com/artifacts/useCaseDiagram.htmhttp://www.agilemodeling.com/artifacts/useCaseDiagram.htmhttp://www.agilemodeling.com/artifacts/essentialUseCase.htmhttp://www.agilemodeling.com/artifacts/essentialUseCase.htmhttp://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/useCaseDiagram.htmhttp://www.agilemodeling.com/artifacts/essentialUseCase.htmhttp://www.agilemodeling.com/artifacts/systemUseCase.htm


5/19

A use case model is comprised of one or more use case diagrams and anysupporting documentation such as use case specifications and actordefinitions. Within most use case models the use case specifications tend tobe the primary artifact with use case diagrams filling a supporting role as theglue that keeps your requirements model together. Use case models

should be developed from the point of view of your project stakeholders andnot from the (often technical) point of view of developers.There areguidelines for:

1. Use Cases2. Actors3. Relationships4. System Boundary Boxes

1.Use CasesA use case describes a sequence of actions that provide a measurable valueto an actor. A use case is drawn as a horizontal ellipse on a UML use casediagram, as you see inFigure 1.

1. Use Case Names Begin With a Strong Verb2. Name Use Cases Using Domain Terminology3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram4. Imply Timing Considerations By Stacking Use Cases. As you see

inFigure 1, the use cases that typically occur first are shown above

those that appear later.

Figure 1. Implying timing considerations between use cases.
http://www.agilemodeling.com/style/useCaseDiagram.htm#UseCaseshttp://www.agilemodeling.com/style/useCaseDiagram.htm#Actorshttp://www.agilemodeling.com/style/useCaseDiagram.htm#Relationshipshttp://www.agilemodeling.com/style/useCaseDiagram.htm#SystemBoundaryBoxeshttp://www.agilemodeling.com/style/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/style/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/style/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/style/useCaseDiagram.htm#UseCaseshttp://www.agilemodeling.com/style/useCaseDiagram.htm#Actorshttp://www.agilemodeling.com/style/useCaseDiagram.htm#Relationshipshttp://www.agilemodeling.com/style/useCaseDiagram.htm#SystemBoundaryBoxeshttp://www.agilemodeling.com/style/useCaseDiagram.htm#Figure1http://www.agilemodeling.com/style/useCaseDiagram.htm#Figure1


6/19

2. Actors

An actor is a person, organization, or external system that plays a role in oneor more interactions with your system (actors are typically drawn as stickfigures on UML Use Case diagrams).Figure 2. Online Shopping.

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram


7/19

2. Draw Actors To The Outside Of A Use Case Diagram3. Name Actors With Singular, Business-Relevant Nouns4. Associate Each Actor With One Or More Use Cases5. Actors Model Roles, Not Positions6. Use to Indicate System Actors

7. Actors Dont Interact With One Another8. Introduce an Actor Called Time to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use casediagram:

An association between an actor and a use case

An association between two use cases A generalization between two actors A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with anoptional open-headed arrowhead on one end of the line indicating thedirection of the initial invocation of the relationship. Generalizations aredepicted as a close-headed arrow with the arrow pointing towards the moregeneral modeling element.

Figure 3. Enrolling students in a university.


8/19

1. Indicate An Association Between An Actor And A Use Case If The ActorAppears Within The Use Case Logic

2. Avoid Arrowheads On Actor-Use Case Relationships3. Apply When You Know Exactly When To Invoke The Use

Case

4. Apply When A Use Case May Be Invoked Across SeveralUse Case Steps5. Introduce associations sparingly6. Generalize Use Cases When a Single Condition Results In Significantly

New Business Logic7. Do Not Apply , , or 8. Avoid More Than Two Levels Of Use Case Associations9. Place An Included Use Case To The Right Of The Invoking Use Case10.Place An Extending Use Case Below The Parent Use Case11. Apply the Is Like Rule to Use Case Generalization12. Place an Inheriting Use Case Below The Base Use Case

13. Apply the Is Like Rule to Actor Inheritance14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box andas the name suggests it indicates the scope of your system the use cases

inside the rectangle represent the functionality that you intend toimplement.

1. Indicate Release Scope with a System Boundary Box. InFigure 2yousee that three system boundary boxes are included, each of which hasa label indicating which release the various use cases have beenassigned to.

2. Avoid Meaningless System Boundary Boxes
http://www.agilemodeling.com/style/useCaseDiagram.htm#Figure2http://www.agilemodeling.com/style/useCaseDiagram.htm#Figure2


9/19

UML Activity DiagramAn activity diagram illustrates the dynamic nature of a system by modeling

the flow of control from activity to activity. An activity represents an

operation on some class in the system that results in a change in the state of

the system. Typically, activity diagrams are used to model workflow or

business processes and internal operation. Because an activity diagram is a

special kind of statechart diagram, it uses some of the same modeling

conventions.

Basic Activity Diagram Symbols and Notations

Action States

Action states represent the non interruptible actions of objects. You can draw

an action state in SmartDraw using a rectangle with rounded corners.


10/19

Action Flow

Action flow arrows illustrate the relationships among action states.

Object Flow

Object flow refers to the creation and modification of objects by activities. An

object flow arrow from an action to an object means that the action creates

or influences the object. An object flow arrow from an object to an action

indicates that the action state uses the

Object.

Initial State

A filled circle followed by an arrow represents the initial action state.

Final State


11/19

An arrow pointing to a filled circle nested inside another circle represents the

final action state.

Branching

A diamond represents a decision with alternate paths. The outgoing

alternates should be labeled with a condition or guard expression. You can

also label one of the paths "else."

Synchronization

A synchronization bar helps illustrate parallel transitions. Synchronization is

also called forking and joining.


12/19

Swimlanes

Swimlanes group related activities into one column.

In many waysUML Activity diagramsare the object-oriented equivalentofflow chartsanddata-flow diagrams (DFDs).They are used to explorethe logic of:

A complex operation A complex business rule A single use case Several use cases A business process Software processes

Guidelines:

1. General Guidelines2. Activities3. Decision Points4. Guards5. Parallel Activities6. Swimlanes7. Action Objects

1. General Guidelines

Figure1. Modeling a business process with a UML Activity Diagram.
http://www.agilemodeling.com/artifacts/activityDiagram.htmhttp://www.agilemodeling.com/artifacts/activityDiagram.htmhttp://www.agilemodeling.com/artifacts/flowChart.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/style/activityDiagram.htm#Generalhttp://www.agilemodeling.com/style/activityDiagram.htm#Activitieshttp://www.agilemodeling.com/style/activityDiagram.htm#DecisionPointshttp://www.agilemodeling.com/style/activityDiagram.htm#Guardshttp://www.agilemodeling.com/style/activityDiagram.htm#ParallelActivitieshttp://www.agilemodeling.com/style/activityDiagram.htm#Swimlaneshttp://www.agilemodeling.com/style/activityDiagram.htm#ActionObjectGuidelineshttp://www.agilemodeling.com/artifacts/activityDiagram.htmhttp://www.agilemodeling.com/artifacts/flowChart.htmhttp://www.agilemodeling.com/artifacts/dataFlowDiagram.htmhttp://www.agilemodeling.com/style/activityDiagram.htm#Generalhttp://www.agilemodeling.com/style/activityDiagram.htm#Activitieshttp://www.agilemodeling.com/style/activityDiagram.htm#DecisionPointshttp://www.agilemodeling.com/style/activityDiagram.htm#Guardshttp://www.agilemodeling.com/style/activityDiagram.htm#ParallelActivitieshttp://www.agilemodeling.com/style/activityDiagram.htm#Swimlaneshttp://www.agilemodeling.com/style/activityDiagram.htm#ActionObjectGuidelines


13/19

1. Place The Start Point In The Top-Left Corner. A start point is modeledwith a filled in circle, using the same notation that UML State Chartdiagrams use. Every UML Activity Diagram should have a startingpoint, and placing it in the top-left corner reflects the way that peoplein Western cultures begin reading. Figure 1, which models thebusiness process of enrolling in a university, takes this approach.

2. Always Include an Ending Point. An ending point is modeled with afilled in circle with a border around it, using the same notation thatUML State Chart diagrams use. Figure 2is interesting because it doesnot include an end point because it describes a continuous process sometimes the guidelines dont apply.

3. Flowcharting Operations Implies the Need to Simplify. A good rule ofthumb is that if an operation is so complex you need to develop a UMLActivity diagram to understand it that you should consider refactoringit.

2.Activities

An activity, also known as an activity state, on a UML Activity diagramtypically represents the invocation of an operation, a step in a businessprocess, or an entire business process.
http://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure2http://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure2


14/19

1. Question Black Hole Activities. A black hole activity is one that hastransitions into it but none out, typically indicating that you have eithermissed one or more transitions.

2. Question Miracle Activities. A miracle activity is one that hastransitions out of it but none into it, something that should be true only

of start points.

3. Decision Points

A decision point is modeled as a diamond on a UML Activity diagram.

1. Decision Points Should Reflect the Previous Activity. InFigure 1you

see that there is no label on the decision point, unlike traditionalflowcharts which would include text describing the actual decisionbeing made, you need to imply that the decision concerns whether theperson was enrolled in the university based on the activity that thedecision point follows.The guards, depicted using theformat[description], on the transitions leaving the decision point alsohelp to describe the decision point.

2. Avoid Superfluous Decision Points.TheFill Out EnrollmentFormsactivity inFigure 1includes an implied decision point, a checkto see that the forms are filled out properly, which simplified thediagram by avoiding an additional diamond.

4. Guards

A guard is a condition that must be true in order to traverse a transition.

1. Each Transition Leaving a Decision Point Must Have a Guard2. Guards Should Not Overlap. For example guards such as x 0 are consistent whereas guard such as x = 0are not consistent because they overlap it isnt clear what shouldhappen when x is 0.

3. Guards on Decision Points Must Form a Complete Set. For example,guards such as x < 0 and x >0 are not complete because it isnt clearwhat happens when x is 0.
http://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure1


15/19

4. Exit Transition Guards and Activity Invariants Must Form a CompleteSet. An activity invariant is a condition that is always true when yoursystem is processing an activity.

5. Apply a [Otherwise] Guard for Fall Through Logic.6. Guards Are Optional.It is very common for a transition to not include a

guard, even when an activity includes several exittransitions. FollowAgile Modeling (AM)s principle ofDepictModels Simply and only indicate a guard on a transition if it addsvalue.

5. Parallel Activities

It is possible to show that activities can occur in parallel, as you seeinFigure 1depicted using two parallel bars.The first bar is called a fork, ithas one transition entering it and two or more transitions leaving it.Thesecond bar is a join, with two or more transitions entering it and only oneleaving it.

1. A Fork Should Have a Corresponding Join. In general, for every start(fork) there is an end (join). In UML 2 it is not required to have a join,but it usually makes sense.

2. Forks Have One Entry Transition.3. Joins Have One Exit Transition4. Avoid Superfluous Forks. Figure 2depicts a simplified description of

the software process of enterprise architectural modeling, a part of

theEnterprise Unified Process (EUP).There is significantopportunity for parallelism in this process, in fact all of these activitiescould happen in parallel, but forks were not introduced because theywould only have cluttered the diagram.

6. Swimlane Guidelines

A swimlane is a way to group activities performed by the same actor on anactivity diagram or to group activities in a single thread.Figure 2includesthree swimlanes, one for each actor.Figure2. A UML activity diagram for the enterprise architecturalmodeling (simplified).
http://www.agilemodeling.com/http://www.agilemodeling.com/practices.htm#DepictModelsSimplyhttp://www.agilemodeling.com/practices.htm#DepictModelsSimplyhttp://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure2http://www.enterpriseunifiedprocess.com/http://www.agilemodeling.com/style/activityDiagram.htm#Figure2http://www.agilemodeling.com/style/activityDiagram.htm#Figure2http://www.agilemodeling.com/http://www.agilemodeling.com/practices.htm#DepictModelsSimplyhttp://www.agilemodeling.com/practices.htm#DepictModelsSimplyhttp://www.agilemodeling.com/style/activityDiagram.htm#Figure1http://www.agilemodeling.com/style/activityDiagram.htm#Figure2http://www.enterpriseunifiedprocess.com/http://www.agilemodeling.com/style/activityDiagram.htm#Figure2


16/19

Figure3. Submitting expenses.

1. Order Swimlanesin a Logical Manner.

2. Apply Swim LanesTo Linear Processes. A good rule of thumb is thatswimlanes are best applied to linear processes, unlike the one depictedinFigure 2.

3. Have Less Than Five Swimlanes.4. Consider SwimareasFor Complex Diagrams.5. Swimareas Suggest The Need to ReorganizeInto Smaller Activity

Diagrams.
http://www.agilemodeling.com/style/activityDiagram.htm#Figure2http://www.agilemodeling.com/style/activityDiagram.htm#Figure2


17/19

6. Consider Horizontal Swimlanesfor Business Processes. InFigure3you see that the swimlanes are drawn horizontally, going againstcommon convention of drawing them vertically.

7Action-Object GuidelinesActivities act on objects, In the strict object-oriented sense of the term anaction object is a system object, a software construct.In the looser, andmuch more useful for business application modeling, sense of the term anaction object is any sort of item. For example inFigure3theExpenseFormaction object is likely a paper form.

1. Place Shared Action Objects on Swimlane Separators2. When An Object Appears Several Time Apply State Names

3. State Names Should Reflect the Lifecycle Stage of an Action Object4. Show Only Critical Inputs and Outputs5. Depict Action Objects As Smaller Than Activities

UML Statechart Diagram

A statechart diagram shows the behavior of classes in response to external

stimuli. This diagram models the dynamic flow of control from state to state

within a system.
http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3http://www.agilemodeling.com/style/activityDiagram.htm#Figure3


18/19

Basic Statechart Diagram Symbols and Notations

States

States represent situations during the life of an object. You can easily

illustrate a state in SmartDraw by using a rectangle with rounded corners.

Transition

A solid arrow represents the path between different states of an object. Label

the transition with the event that triggered it and the action that results from

it.

Initial State

A filled circle followed by an arrow represents the object's initial state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the

object's final state.

Synchronization and Splitting of Control


19/19

A short heavy bar with two transitions entering it represents a

synchronization of control. A short heavy bar with two transitions leaving it

represents a splitting of control that creates multiple states.

Emdedded Assign

Documents

Transcript of Emdedded Assign