UML1

1

27/09/2011 11111111 / 160/ 160/ 160/ 160/ 160/ 160/ 160/ 160Dr. Farhana Jabeen

Software Engineering-1

Lecture 10-14

Dr. Farhana Jabeen


UML

The UML is a graphical language for

• visualizing

• specifying

• constructing

• documenting

artifacts of a software-intensive system.Artifacts include:

• deliverables, such as requirements documents, functional specifications, and test plans

• materials that are critical in controlling, measuring, and communicating about a system during development and after deployment

2


� It is a industry-standard graphical language for specifying, visualizing, constructing, and documenting the artifacts of software systems

� The UML uses mostly graphical notations to express the OO analysis and design of software projects.

� Simplifies the complex process of software design

� Use graphical notation: more clearly than natural language (imprecise) and code (too detailed).

UML


• UML can be used in all phases of software development

– specification of requirements, architectural design, detailed design and implementation

• There are different types of UML diagrams for specifying different aspects of software:

• Functionality, requirements• Use-case diagrams

– Architecture, modularization, decomposition• Class diagrams (class structure)

• Component diagrams, Package diagrams, Deployment diagrams (architecture)

– Behavior• State diagrams, Activity diagrams

– Communication, interaction• Sequence diagrams, Collaboration diagrams

UML

3


• There are tools which support UML– Can be used for developing UML models and analyzing them

• IBM’s Rational Rose is a software development tool based on UML.It has code generation capability, configuration management etc.

– http://www.rational.com/

• Microsoft Visio has support for UML shapes and can be used for basic UML diagram drawing.

– http://www.visual-paradigm.com/

• ArgoUML (http://argouml.tigris.org/), open source tool for developing UML models

• USE (http://www.db.informatik.uni-bremen.de/projects/USE/) an open source tool which supports UML class diagrams and Object Constraint Language

UML


Modelling

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

ScenarioDiagramsScenario

DiagramsCommunication(Collaboration)

Diagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

ScenarioDiagramsScenario

DiagramsState MachineDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

ActivityDiagrams

A model is a complete

description of a system

from a particular

perspective

Models

StateDiagramsState

DiagramsClassDiagrams

4


• Modeling consists of building an abstraction of reality.

• Abstractions are simplifications because:

– They ignore irrelevant details and

– They only represent the relevant details.

• What is relevant or irrelevant depends on the purpose of the model.

Modelling


Structural Diagrams

• Used to visualize, specify, construct, document static aspects of system

– class diagram

– package diagram [not standard UML]

– object diagram

– component diagram

– deployment diagram

5


Behavioral Diagrams

• Used to visualize, specify, construct, document dynamic aspects of system

– use case diagram (usually)

– sequence diagram

– communication (collaboration) diagram

– state machine diagram

– activity diagram


UML (USE CASE Diagram)

• A full set of use case diagrams shows all the procedures available for interaction with the system. It is a summary of system functionality.

• Use Cases specify the behavior of the system

• Helps visualize the system

6



• The two main components of a use case diagram are use cases and actors.

• An actor represent roles that humans, hardware devices, or external systems play while interacting with a given system

– They are not part of the system and are situated outside of the system boundary

– Actors may be both at input and output ends of a use case

• A use case is an external view of the system that represents some action the user might perform in order to complete a task.



• The use case model is the set of all use cases. It is a complete description of the functionality of the system

and its environment

• Use Case

– A set of scenarios related by a common actor and a goal

– A description of sequences of actions performed by a given

system to produce a result for an actor

– Use cases specify the expected behavior [what], and not the

exact method of making it happen [how]

– To name the use cases, give it a verb name to show the action

that must be performed

– Describe a transaction completely

7



• For example a user placing an order

with a sales company might follow

these steps.

– Browse catalog and select items.

– Call sales representative.

– Supply shipping information.

– Supply payment information.

– Receive conformation number from

salesperson.



• It is important to define the basic flow of a use case

before building the structure of the several flows that are part of it.

• If the speed with which the use case is completed by the

actor is important, then it must be optimized to be as

efficient as possible for the user.

8



• A good use case is also:

– Easy to understand

– Unambiguous

– Complete including all alternate flows

– Specified in a document separate from the use case

diagram

– Agreed with the users of the system

– Mapped to a prototype screen or system interface

prototype



• "X uses Y" indicates

that the task "X" has a

subtask "Y"; that is, in the

process of completing task

"X", task "Y" will be

completed at least once.

• The included use case is a

mandatory part of the

including one

9



• "X extends Y" indicates that "X" is a task for the same type as "Y", but "X" is a special, more specific case of doing "Y". That is, doing X is a lot like doing Y, but X has a few extra processes to it that go above and beyond the things that must be done in order to complete Y.

• extend relationship where you have one Use Case which adds functionality to another Use Case

– any Use Case can have more than one extend

– use when describing a variation on or in addition to normal behavior

– OPTIONAL BEHAVIOUR


UML: USE CASE - CD Player

10


UML USE CASE Diagram - Courseware System Description

• For this case study, the task is of constructing the design elements for a system that can be used to manage courses and classes for an organization that specializes in providing training.

• The name of the system is Courseware System.


UML USE CASE Diagram - Courseware System Description

• The organization offers courses in a variety of areas such as learning management techniques and understanding different software languages and technologies.

• Each course is made up of a set of topics.

• Tutors in the organization are assigned courses to teach according to the area that they specialize in and their availability.

• The organization publishes and maintains a calendar of the different courses and the assigns tutors every year.

• There is a group of course administrators in the organization who manage the courses including course content, assigning courses to tutors, and defining the course schedule.

• The training organization aims to use the Courseware System to get a better control and visibility to the course management and to also streamline the process of generating and managing schedulesfor different courses.

11


USE CASE Diagram

• The following terms and entities are specific to the system:– Courses and Topics that make up courses

– Tutors that teach courses

– Course Administrators who manage the assignment of courses to tutors

– Calendars and Course Schedules that are generated as a result of the work performed by the course administrators

– Students who refer to Calendars and Course Schedules to decide which courses they wish to take up for study


USE CASE Diagram

Courseware Actors and Use Cases

• � Actors:

– Tutor, Student, Course Administrator (main actor)

• � Use Cases

– Manage courses: View courses, Manage topics for a

course, and Manage course information

– Manage tutors: View course calendar, View tutors,

Manage tutor information, and Assign courses to tutors

12


USE CASE Diagram


USE CASE Diagram

13


USE CASE Diagram : ATM requirements Capture

• A simplified Automatic Teller Machine

• Which requirements are to be captured?

• The activities in Requirement capture– Identification of system boundaries: actors and use cases

– Diagramming use cases

– Elaborating scenarios

– Diagramming scenarios


USE CASE Diagram :A Simplified Automatic Teller

Machine

• The ATM is associated with only one bank

– It gives access to all the accounts the customer owns in

the bank

• Several types of transactions can be chained in a

single session

– Withdrawal, deposit, transfer between the customer’s

own accounts, consulting an account

– The customer may obtain a printed receipt for each

transaction

14


• The card contains– an ID number

– an expiration date

– a secret code

• The card must be verified by the ATM– The customer cannot make more than 3 attempts to enter the

correct code, otherwise the card is swallowed

• Interface– Keyboard and screen, with menus

– The customer may cancel the current transaction at meaningful points


Machine


• The connections with the bank are kept to a minimum– When a session is opened, a connection makes it possible to

known all the accounts the customer owns

– Every night, the information about the current day transactions are transferred to the bank

• From time to time an employee manually – empties the machine and/or fills it with bank notes

– supplies consumables and does any maintenance that may be needed


Machine

15



Machine

• ATM example– Customer using the

teller machine

– Bank

– Maintenance technician

– What about the card itself?

Customer

Bank

Technician


Use Cases

Handle Session

Transfer Daily

Maintain

Bank

Technician

Customer

associationsystem boundary

16


Use Cases

Handle

Session

« include »

Verify

Card

« include »

Authentify

Customer

« include »

Get Customer

Information

Handle

Transaction

« include »

Deliver

Receipt

« extend »


Diagramming Use CasesGeneralization

Handle

Transaction

Handle

Deposit

Handle

Withdrawal

Handle

Consult

Handle

Transfer

17


Diagramming Use Cases

Generalization

• The specialized and generalized use

cases are in a “sort of” relationship

Generalized

Specialized


Diagramming Use CasesGeneralization

18


Use Case and Scenarios

• Use cases classify the ways of using the system

• To each use case correspond many possible usage scenarios

• Thus scenarios– are instances of use cases

– specify use cases

• Each use case has generally– a primary scenario, possibly several (a few)

– several secondary (more exceptional) scenarios


A use case consists of:– Unique name

– Participating actors

– Entry conditions

– Flow of events

– Exit conditions

– Special requirements

Use Case and Scenarios

19


• Name: Purchase ticket

• Participating actor: Passenger

• Entry condition:

• Passenger standing in front of

ticket distributor.

• Passenger has sufficient

money to purchase ticket.

• Exit condition:

• Passenger has ticket.

Event flow:

1. Passenger selects the

number of zones to be

traveled.

2. Distributor displays the

amount due.

3. Passenger inserts

money, of at least the

amount due.

4. Distributor returns

change.

5. Distributor issues ticket.

Scenarios for Use Cases



20



Use Case: Handle Session

Precondition: the ATM is free

Primary Scenario

1. The Customer inserts the card into the ATM.

2. The ATM verifies the cardvalidity.

3. The Customer authentifieswith the ATM.

4. The ATM gets the Customer information from the Bank.

5. The Customer selects a transaction.

6. The Customer quits.

7. The ATM ejects the card.

Postcondition: the ATM is free

Variants

2a The card is invalid; the ATM swallows it; this ends the session.

3a The Customer fails to authentify; the ATM swallows the card; this ends the session.

4a The connection with the Bank is impossible or interrupted; the ATM ejects the card; this ends the session.

5a The Customer may quit immediately.

6a The Customer chooses to perform another transaction; goto step 5.

* The Customer may cancel the session; the ATM ejects the card.


Example of Secondary Scenarios

Use Case: Handle Session

Scenario: Secondary (customer

interrupt)

Precondition: the ATM is free

1. The scenario starts when

the customer inserts the

card

2. The card is accepted

3. The customer enters the

secret code correctly

4. The customer cancel the

session

5. The card is ejected and the

scenario is finished

Postcondition: the ATM is free

21


Use Case : Class Assignment

• We are currently facing a crisis in grading your midterms. We know the steps to do this, but can’t somehow figure out how it all works together.

• The TA’s create sample answers to the midterm. They also create a grading rubric. The professor then goes through both of them, and approves or makes necessary modifications.

• The reader then takes the approved sample answers and the grading rubric and grades the midterm. The

• TA’s finally collect the grades from the reader and enter them on the Glookup system.


Use Case : Example of Secondary Scenarios

22


Class Diagram

• Class diagram describes

– Types of objects in the system

– Static relationships among them

• Two principal kinds of static relationships

– Associations between classes

– Subtype relationships between classes

• Class diagrams represent the structure of the system.

• Used

– during requirements analysis to model problem domain concepts

– during system design to model subsystems and interfaces

– during object design to model classes.


• design: specifying the structure of how a software system will be written and function, without actually writing the complete implementation

• a transition from "what" the system must do, to "how" the system will do it– What classes will we need to implement a system that

meets our requirements?

– What fields and methods will each class have?

– How will the classes interact with each other?

Class Diagram

23


• What is a UML class diagram?

• What are some things that are not

represented in a UML class diagram?

ERROR: undefinedOFFENDING COMMAND: Pscript_WinNT_Min

STACK:

UML1

Documents

Transcript of UML1