News

1
(No Transcript)
2
News

• I am going to Holland Monday/Tuesday next week...
• No lecture on Monday (moved to Thursday 16.40 OR
  the week after if you prefer...).
• You may use the booked class rooms on Tuesday if
  you need them.
• Groups that need people or people that need
  groups, meet at the desk in the pause.

3
Recap

• Goals and what is required
• On time predictable process/milestones
• Within budget predictable process/cost analysis
  
• Meet changing, competing and contradictory
  requirements risk/requirement analysis
• How and with what
• Design code as atomic entities OO
• Use models to break down complexity UML
• Reuse schemas Design Patterns

4
An evolutionary development process
User Group
Black BoxRequirements
FunctionalSpecification
SystemDesign
SystemTest
SystemExperts
User Group
SystemDevelopment
SystemValidation
On time, within budget and meet requirements!
5
SMD136 Content

• Software Engineering
• Processes
• Requirement specification
• Use cases
• Code Design
• Design Patterns
• Code Review
• Modeling in UML
• Tools and documentation
• Revision control
• Metrics Inspection
• Test
• Plans

6
Todays lecture

• Unified Modeling Language (UML)
• Conventions
• A software engineering process in UML
• Class Diagrams
• Actors, Use Cases and Use Case Diagrams
• Sequence Diagrams
• Statechart Diagrams
• Activity Diagrams
• Project ToDos

7
Modeling complex systems
We need to describe the architecture and
behaviour of complex systems!
8
Modeling using UML

• UML, the Unified Modeling Language
• DeFacto standard for modeling object-oriented
  systems.
• Resulted from the convergence of notations from
  three leading object-oriented methods
• OMT (James Rumbaugh)
• OOSE (Ivar Jacobson)
• Booch (Grady Booch)

9
Modeling using UML

• Modeling is a central part of all the activities
  that
• lead up to the deployment of good software.
• We use models to
• Understand the system as a whole and in parts
• Communicate desired system structures and
  behavior
• Visualize and control the systems architecture
• To identify cases of abstraction and reuse
• Manage risks

You can model 80 of most problems by using 20
UML!
10
A model gives the illusion of simplicity!
KISS Keep It Simple and Stupid
11
Modeling using UML

• Models abstracts the complexity of systems so
  they become understandable.
• The models are often expressed as
• Text
• Diagrams
• Structured Data

• The four basic principles of modeling
• The choice of what models to create has a
  profound influence on how a problem is attacked
  and how a solution is shaped.
• Every model may be expressed at different levels
  of precision.
• The best models are connected to reality (models
  an abstracted reality).
• No single model is sufficient, as every
  nontrivial system is best approached through a
  small set of nearly independent models.

12
Modeling using UML

• Diagrams are the main artefacts of UML.
• (These are not a sequence of steps!!!!)
• Use case diagrams
• Functional behavior of the system as seen by the
  user.
• Sequence diagrams
• Dynamic behavior between actors and system
  objects.
• Class diagrams
• Static structure of the system Objects,
  Attributes, and Associations.
• Statechart diagrams
• Dynamic behavior of an individual object.
• Activity diagrams
• Dynamic behavior of a system expressed as a
  flowchart.
• ...

13
UML Conventions

• Rectangles are classes or instances
• Ovals are states, functions or use cases
• Types are denoted with non-underlined names
• SimpleWatch
• Firefighter
• Instances are denoted with an underlined names
• myWatchSimpleWatch
• JoeFirefighter
• Diagrams are graphs
• Nodes are entities (e.g. classes, states)
• Arcs are relationships among entities (e.g.
  sender/receiver)
• Containment represents belonging (e.g. use cases
  in package)

14
Models, Views, and Systems

• A model is an abstraction describing system or a
  subset of a system
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules
  for representing views
• Views and models of a single system may overlap
  each other!

15
Models, Views, and Systems
16
Concepts and Phenomena

• Phenomenon - An object in a domain
• The lecture you are attending (part of College
  Life)
• Concept - Describes the properties of phenomena
  that are common, for example
• Lectures on software engineering, things to do
  Monday morning
• A concept is a 3-tuple
• Name distinguishes it from others.
• Purpose properties that determine if a
  phenomenon is a member of a concept.
• Members the phenomena which are part of the
  concept.

17
Concepts and Phenomena
Purpose

• Modeling Development of abstractions to
• answer specific questions about a set of
• phenomena while ignoring irrelevant details.

18
Classes

• A class represent a concept.
• A class encapsulates state (attributes) and
  behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory information.

19
Class Diagrams
TariffSchedule
Trip
Enumeration getZones() Price getPrice(Zone)
zoneZone pricePrice

• Class diagrams represent the structure of the
  system.
• Class diagrams are used
• during requirements analysis to model problem
  domain
• during system design to model subsystems and
  interfaces
• during object design to model classes.

20
Instances
tariff_1974TarifSchedule
zone2price 1, .20,2, .40, 3, .60

• An instance represents a phenomenon (object).
• The name of an instance is underlined and can
  contain the class of the instance.
• The attributes are represented with their values.

21
Associations
TarifSchedule
Enumeration getZones() Price getPrice(Zone)

• Associations denote relationships between
  classes.
• The multiplicity of an association end denotes
  how many objects the source object can
  legitimately reference.

22
1-to-1 and 1-to-Many Associations
1-to-1 association
1-to-many association
23
Aggregation

• An aggregation is a special case of association
  denoting a consists of hierarchy.
• The aggregate is the class containing the
  component classes.

1
0..2
24
Composition

• A solid diamond denotes composition, a strong
  form of aggregation, where components cannot
  exist without the aggregate.

25
Generalization

• Generalization relationships denote inheritance
  between classes.
• The children classes inherit the attributes and
  operations of the parent class.
• Generalization simplifies the model by
  eliminating system redundancy (while adding
  structural complexity).

26
From Problem Statement to Code
Problem Statement
A stock exchange lists many companies. Each
company is identified by a ticker symbol.
Class Diagram
lists
Java Code
public class StockExchange public Vector
companies new Vector() public class Company
public int tickerSymbol public Vector
stockExchanges new Vector()
27
Class Diagrams
SimpleWatch
1
1
1
1
1
1
2
2
Battery level
Time now()
PushButton state push()release()
LCDDisplay
blinkIdx blinkSeconds() blinkMinutes() blinkHours(
) stopBlinking() referesh()
Class diagrams represent the structure of the
domain or system
28
5 minutes of oxygen
29
Actors

• An actor models an external entity which
  communicates with the system
• User
• External system
• Physical environment
• An actor has a unique name and an optional
  description.
• Examples
• Passenger A person in the train
• GPS satellite Provides the system with GPS
  coordinates

30
Use Case

• A use case represents a class of
• functionality provided by the system
• as an event flow.
• A use case consists of
• Unique name
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements

31
Use Case Diagrams
SimpleWatch
ReadTime
SetTime
WatchUser
WatchRepairPerson
ChangeBattery
Use case diagrams represent the functionality of
the system from users point of view.
32
Use Case Example

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

33
The ltltextendgtgt Relationship

• ltltextendgtgt relationships represent exceptional or
  seldom invoked cases.
• The exceptional event flows are factored out of
  the main event flow for clarity.
• Use cases representing exceptional flows can
  extend more than one use case.
• The direction of a ltltextendgtgt relationship is to
  the extended use case

ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
34
The ltltincludegtgt Relationship

• ltltincludegtgt represents behavior that is factored
  out of the use case for reuse (not because it is
  an exception)
• Direction of ltltincludegtgt is to the using use case
  (unlike ltltextendgtgt relationships).

ltltincludegtgt
ltltincludegtgt
ltltextendgtgt
ltltextendgtgt
35
UML Sequence Diagrams

• In requirements analysis
• To refine use case descriptions
• to find additional objects (participating
  objects)
• In system design
• to refine subsystem interfaces
• Columns classes
• Arrows messages
• Narrow rectangles activations
• Dashed lines lifelines

selectZone()
insertCoins()
pickupChange()
pickUpTicket()
36
UML Sequence Diagrams Nested Messages
ZoneCheckbox
to be continued...

• The source of an arrow indicates the activation
  which sent the message
• An activation is as long as all nested activations

37
Sequence Diagram Observations

• UML sequence diagram represent behavior in terms
  of interactions.
• They complement class diagrams, which represent
  structure.
• Useful for finding participating objects.
• Time-consuming to build but worth the investment
  where interactions are complex.

38
Sequence Diagram
Sequence diagrams represent the behavior as
interactions
39
Statechart Diagrams
button12Pressed
40
Activity Diagrams

• An activity diagram shows flow control within a
  system
• An activity diagram is a special case of a state
  chart diagram in which states are activities
  (aggregated functions)
• These are related to use cases!

41
Activity Diagram Modeling Decisions
42
Activity Diagrams Modeling Concurrency

• Synchronization of multiple activities
• Splitting the flow of control into multiple
  threads

43
Activity Diagrams Swimlanes

• Actions may be grouped into swimlanes to denote
  the object or subsystem that implements the
  actions.

44
Summary

• UML provides a wide variety of notations for
  representing many aspects of software development
• Powerful, but complex language (keep it simple!)
• Can be misused to generate unreadable models
  (automatic generators)
• Can be misunderstood when using too many exotic
  features (KISS!)
• We concentrate only on a few notations
• Functional model use case diagram
• Object model class diagram
• Dynamic model sequence, statechart and activity
  diagrams
• UML is not a methodology, but the textbook
  describes a methodology that uses UML

45
UML artefacts
Actors Use Cases Use Case Diagrams Storyboards
Black BoxRequirements
FunctionalSpecification
Diagrams ClassSequenceStatechartActivity
SystemTest
SystemDesign
Test Cases
SystemDevelopment
SystemValidation
Notes Details Signatures
46
SMD136 Until next week

• Form groups
• 6 students
• Attach roles (1 per group member)
• PrjMgr, CM, ReqEng, SysArch, Q, TstEng
• The project manager should not do all work
  himself!
• Define a problem to solve
• Project Name
• Initial Project Description (1 A4)
• E-mail the group info to unicorn_at_cdt.luth.se
• Group name
• Members and roles
• Project site (URL)
• If you need more quota, and if so where! (CMs
  user?)

47
SMD136 Next week

• Start with a minimal set of use cases then
  evolve!!!
• Make simple storyboards on paper for unclear use
  cases it will make these simpler to understand
• Make use case diagrams to view how use cases
  relates to actors
• Draw activity diagrams where activities (use
  cases) are related!

• Develop the A4 description of your system.
• Identify the actors of the system
• Try to find the actors uses of the system and
  express them as use cases.
• Attach values to the use cases
• Cost (Time/Resources)
• Value (Customer)
• Risk (Unknown/Complexity)
• Dependencies on other use cases
• Priority
• Metrics

48
Next Lectures

• Classification
• How to find classes
• Requirement elicitation
• How to find requirements
• Design Patterns
• Reusable schemas
• Lotsa good UML examples!!!
• The process, more on requirements, milestones,
  etc...

49
The End

• Thats all folks!
• Thanks for your attention!

50
Requirements
51
Actor vs. Class vs. Object

• What is the difference between an actor and a
  class and
• an instance?
• Actor
• An entity outside the system to be modeled,
  interacting with the system (Pilot)
• Class
• An abstraction modeling an entity in the problem
  domain, inside the system to be modeled
  (Cockpit)
• Object
• A specific instance of a class (Instrument, the
  altitude meter).

52
UML model of a SE process
53
Development Activities
54
Management Activities
55
Activity Diagrams
Two types of states Action state Cannot be
decomposed any further Happens instantaneously
with respect to level of abstraction used in the
model Activity state Can be decomposed
further Activity is modeled by another activity
diagram