1st Software engineering tutorial

8/7/2019 1st Software engineering tutorial

1/36

SOFTWARE ENGINEERING 1

INTRODUCTION TO UML1ST TUTORIAL

Prepared by : Pakinam hussam , Ezz eldeen shrief


2/36

OUTLINE :

1. Software development life cycle review .

2. What is UML .

3. Why we use UML instead of traditional way.

4. Types of Diagrams used in UML.

5. Use Case diagram.


3/36

Software Development Life Cycle


4/36

What is UML ?

What is UML?

The Unified Modeling Language (UML) is a graphical

language for visualizing, specifying, constructing, and

documenting the artifacts of a software-intensive system. UML offers a standard way to write a system's blueprints,

including conceptual things such as business processes and

system functions as well as concrete things such as

programming language statements, database schemas, andreusable software components.


5/36

Why we use UML ?

Why we use UML instead of traditional way?

UML provides facilities for visualizing, specifying,

constructing, and documenting the software.

this will likely increase the success chances

of the software and possibly

significantly reduces its cost.


6/36

Who needs UML Diagrams ?

Owners

To make sure they are getting

the value they paid for

Developers To make sure they know what

to develop

Testers

To make sure they know what

to test

Managers

To know where the system will

be deployed

Technical Writers

To know how to document the

system

IT Operations/Support To know how to install and

maintain the system

Users

To know how to use the

system


7/36

Types of Diagrams used in UML

Use Case Diagram Displays the relationship among actors and use

cases.

Class Diagram Models class structure and contents using design

elements such as classes, packages and objects. It

also displays relationships such as containment,

inheritance, associations and others.

State Diagram Displays the sequences of states that an object of

an interaction goes through during its life in

response to received stimuli, together with its

responses and actions.


8/36

Use case diagrams


9/36

Class Diagram


10/36

State Diagram


11/36


Collaboration Diagram Displays an interaction organized around the

objects and their links to one another. Numbers

are used to show the sequence of messages.

Activity Diagram Displays a special state diagram where most of

the states are action states and most of the

transitions are triggered by completion of the

actions in the source states. This diagramfocuses on flows driven by internal processing.


12/36

Collaboration Diagram


13/36

Activity diagram


14/36


Component Diagram Displays the high level packaged structure of the

code itself. Dependencies among components are

shown, including source code components, binary

code components, and executable components.Some components exist at compile time, at link

time, at run times well as at more than one time.

Deployment Diagram Displays the configuration of run-time processing

elements and the software components, processes,and objects that live on them. Software component

instances represent run-time manifestations of

code units.


15/36

Component Diagram


16/36

Deployment Diagram


17/36

Thank you

Any Questions

.?


18/36

Use Case Diagrams

A cashier uses the POS system

to scan an item.

A cashier uses the POS system

to total items.


19/36

System Boundary

Marks off the system as

separate from its environment

Actors are outside

When no system boundary is

shown, the system is assumed


20/36

Actor

Someone or something outside

the system that interacts with it

Actors represent roles not

individuals


21/36

Use Case

A use case achieves a goal of

value to an actor

System does these things for

actors

What system is for not how it

does it

Starts with an active verb from

the point of view of the system


22/36

Communications

Lines between Actor and Use Case summarize

interactions graphically

Actors and use cases exchange information to achieve

the goal but the details of interaction are not shown


23/36

Use Case Diagram Summary

Show the system in its environment

Show what a system is used for

From a behavioral perspective: For capturing functional requirements

For enabling incremental specification

To understand who the system is for

Details of interactions are not shown


24/36

Scenarios

Scenario is another name for a

particular flow of events.

A use case covers a range of

situations a scenario is just one. Each use case typically has:

a main flowdescribing the

happy path

alternate flows describing major

exceptions Several alternatives exist for

specifying the use case scenarios.


25/36

Describing Scenarios Textually

Write text to describe theinteraction of the actor(s) andthe system.

Simple and easy approach

May be limiting: Numerous alternate flows

make it hard to understandwhere normal flow canbranch.

Long alternate flows needto be broken out as stepstoo.

Use Case: Checks out item

1. Customer sets item on counter.

2. Sales clerk swipes UPC reader across UPC code onitem.

3. System looks up UPC code in database procuringitem description and price.

4. System emits audible beep.5. System announces item description and price over

voice output.

6. System adds price and item type to current invoice.

7. System adds price to correct tax subtotal.

Error case 1: UPC code unreadable

If after step 2, the UPC code was invalid or was notproperly read, emit an audible bonk sound.

Error case 2: No item in database

If after step 3 no database entry is found for theUPC flash the manual entry button on the terminal.Accept key entry of price and tax code from SalesClerk. Set Item description to Unknown item. Go tostep 4.


26/36

Formal UML Use Case Diagrams


27/36

Association

The line between an actor and ause case is an association.

The association means the actoris participating and/orcommunicating with the systemvia that use case.

The meaning of the associationcan be refined with:

Multiplicity Direction

Labels


28/36

Multiplicity

Typically,

An actor will have up to one interaction with a given use case.

A use case instantiation interacts with one and only one of a given actor. Previous to UML 2.0 this was the default association.

There are cases where we have multiple interactions simultaneously.


29/36

Direction

Indicates who initiates the communication

Warning: does not necessarily indicate flow of

information!


30/36

Labels

UML allows:

Labels for the association

Labels for roles on each end

Usage is uncommon and is not recommended


31/36

Specialization/Generalization of Actors

One actor can be aspecialization of another.

Arrow points to the more

general (base) actor.


32/36

Using Generalization


33/36

How Use Cases are Related to Each

Other

Generalization

One use case is a special case of another

Includes

Included use case embodies common behavior

Extends

Extending use case adds behavior


34/36

Generalization

Shows inheritance and specialization

One use case is simply a special kind of another


35/36

Includes

Factor out of a use case commonly used behavior

Allows reuse of functionality by multiple use cases


36/36

Extends

Indicates that one use case adds or replaces behavior of another

Must have a an associated extension point

May have a condition

Documents

1st Software engineering tutorial