Bouwkundige Informatiesystemen ADMS 2004 UML part 1

1
Bouwkundige InformatiesystemenADMS 2004UML part
1
Jan Dijkstra - 2 augustus 2004
2
Subjects

• Software Engineering
• UML General
• UML Use Case Diagram
• Exercise UCD
• UML Activity Diagram
• Microsoft Visio
• Task UML-part 1

3
Software Engineering

• Sommerville, Ian (2001)
• Software Engineering, 6th edition
• Ch.1-3, 5
• http//www.software-engin.com

4
What is software engineering?

• Software engineering is an engineering discipline
  which is concerned with all aspects of software
  production
• Software engineers should adopt a systematic and
  organised approach to their work and use
  appropriate tools and techniques depending on the
  problem to be solved, the development constraints
  and the resources available

5
What is the difference between software
engineering and system engineering?

• System engineering is concerned with all aspects
  of computer-based systems development including
  hardware, software and process engineering.
  Software engineering is part of this process
• System engineers are involved in system
  specification, architectural design, integration
  and deployment

6
What is software?

• Computer programs and associated documentation
• Software products may be developed for a
  particular customer or may be developed for a
  general market

7
The software process

• A structured set of activities required to
  develop a software system
• Generic activities in all software processes are
• Specification
• Design
• Validation
• Evolution

8
Generic software process models

• The waterfall model
• Separate and distinct phases of specification and
  development
• Evolutionary development
• Specification and development are interleaved

9
Waterfall model
10
Waterfall model problems

• Inflexible partitioning of the project into
  distinct stages
• This makes it difficult to respond to changing
  customer requirements
• Therefore, this model is only appropriate when
  the requirements are well-understood

11
Evolutionary development

• Exploratory development
• Objective is to work with customers and to evolve
  a final system from an initial outline
  specification. Should start with well-understood
  requirements
• Throw-away prototyping
• Objective is to understand the system
  requirements. Should start with poorly understood
  requirements

12
Evolutionary development
13
Evolutionary development

• Problems
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid
  prototyping) may be required
• Applicability
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
  interface)
• For short-lifetime systems

14
Incremental development
15
Software Requirements

• Descriptions and specifications of a system

16
Functional and non-functional requirements

• Functional requirements
• Statements of services the system should provide,
  how the system should react to particular inputs
  and how the system should behave in particular
  situations.
• Non-functional requirements
• constraints on the services or functions offered
  by the system such as timing constraints,
  constraints on the development process,
  standards, etc.

17
Functional requirements

• Describe functionality or system services
• Depend on the type of software, expected users
  and the type of system where the software is used
• Functional user requirements may be high-level
  statements of what the system should do but
  functional system requirements should describe
  the system services in detail

18
Non-functional classifications

• Product requirements
• Requirements which specify that the delivered
  product must behave in a particular way e.g.
  execution speed, reliability, etc.
• Organisational requirements
• Requirements which are a consequence of
  organisational policies and procedures e.g.
  process standards used, implementation
  requirements, etc.
• External requirements
• Requirements which arise from factors which are
  external to the system and its development
  process e.g. interoperability requirements,
  legislative requirements, etc.

19
Requirements and design

• In principle, requirements should state what the
  system should do and the design should describe
  how it does this
• In practice, requirements and design are
  inseparable
• A system architecture may be designed to
  structure the requirements
• The system may inter-operate with other systems
  that generate design requirements
• The use of a specific design may be a domain
  requirement

20
UML General
21
Study Matter

• Books
• Fowler Scott UML distilled 2nd ed
• Fowler Scott UML beknopt
• Booch, Rumbauch Jacobson The Unified Modeling
  Language User Guide
• Sander Hoogendoorn Pragmatisch modelleren met
  UML 2.0
• Leffingwell Widrig Managing Sofdtware
  Requirements a use case approach
• Web
• www.omg.org
• www.popkin.com

22
About UML 1 of 2

• UML is the successor to the wave of
  object-oriented analysis and design (OOAD)
  methods. The methods of Booch, Rumbaugh and
  Jacobson (de 3 amigos) are merged. UML
  represents the culmination of best practices in
  practical object-oriented modelling.
• UML offers a standard way to write a systems
  blueprints, including conceptual things such as
  business processes and system functions as well
  as database schemas.

23
About UML 2 of 2

• UML is a modelling language, a notation used to
  express and document designs.
• UML proposes a standard for technical exchange of
  models and designs.
• UML also defines a meta-model, a diagram that
  defines the syntax of the UML notation

24
UML Model Views

• Use Case Modelling
• Requirements
• Use Case diagrams
• Structural Modelling
• Static structure diagrams
• Class diagrams
• Object diagrams
• Behaviour Modelling
• State diagrams
• Interaction diagrams
• Sequence diagrams
• Collaboration diagrams
• Activity diagrams
• Implementation diagrams

25
UML what we will cover

• Use case diagrams
• Documenting the systems behaviour from the
  users viewpoint, requirements capture
• Class diagrams
• Describing the type of objects in a system and
  the static relationships between them
• Activity diagrams
• Describing the sequencing of activities with
  support for both conditional and parallel
  behaviour

26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
UML steps

• Examine the necessities of the information system
  ? use cases
• Object-oriented domain analysis ? decomposition
  of the problem field in concepts, attributes and
  associations that may be of relevance to the
  information system

30
Use Case Modelling
31
Use Case Diagram Example
32
Use Case Modelling

• A use case is a modelling technique used to
  describe what a new system should do or what an
  existing system already does.
• System developers and customers/end-users discuss
  a use case model. In an iterative process, this
  lead to a requirement specification on which all
  agree.
• A use case diagram describes the interaction
  between a set of use cases and the actors
  involved in these use cases.

33
Use Case definition

• Fowler
• A use case is a typical interaction that a user
  has with a system in order to achieve some goals.
• A use case is a description of a set of sequence
  of actions, including variants, that a system
  performs to yield an observable result of value
  to an actor.
• Cockburn
• A use case describes a systems behavior.

34
Actor

• An actor is someone or something that interacts
  with the system. It is who or what uses the
  system.
• An actor communicates with the system by sending
  and receiving messages.
• An actor is a role that a user plays with respect
  to the system.
• Actors what exists outside the system
  (Rumbaugh) external participants/roles

35
Use cases

• A use-case is a set of sequences of actions a
  system performs that yield an observable result
  of value to a particular actor.
• A use-case describes a requirement for the
  system, that is, what it should do, but not how
  it should do it.
• A use-case is a set of scenarios tied together by
  a common user goal.

36
Use Case Diagram Example
37
Example Date2date Basic UCD
Ontleend aan Sander Hoogendoorn
38
Example Date2date Secondary UCD
Ontleend aan Sander Hoogendoorn
39
Scenario

• A scenario is a sequence of steps describing an
  interaction between a user and a system.
• A scenario is an instance of a use-case.
• A scenario describes a possible interaction with
  the system.

40
Scenario Example

• Consider a Web-based on-line store, we might have
  a Buy a Product scenario that would say this
• The customer browses the catalogue and adds
  desired items to the shopping basket. When the
  customer describes the shipping and credit card
  information and confirms the sale. The system
  checks the authorization on the credit card and
  confirms he sale both immediately and with a
  follow-up mail.

41
Example of a Use Case Text
42
Example Date2date use case text
Ontleend aan Sander Hoogendoorn
43
Example Date2date use case text with scenarios
Ontleend aan Sander Hoogendoorn
44
Template of an Use Case Text
45
Steps

• Define the system boundaries
• Define actors
• Define use cases
• Define scenarios
• Describe each use case
• Identify communal sub-cases

46
Use Case relationships

• Generalization
• Include relation
• Extend relation

47
Generalization

• Generalization is used when there is one use case
  similar to another.
• Inheriting parent behaviour, adding and
  overriding with the childs behaviour.
• Sub use case inherits behaviour and semantics
  from super use cases.

48
Use Case Diagram Example
49
Example Date2date Generalization
Ontleend aan Sander Hoogendoorn
50
Example Date2date Include
Ontleend aan Sander Hoogendoorn
51
Include / Uses

• Uses / Include this relationship is used when
  there is a common chunck of behaviour across more
  than one use case.
• Base use case includes the functionality of
  included use case.

52
Use Case Diagram Example
53
Extend

• Extend is similar to genralization but is used
  to add behaviour to the base use case at certain
  extension points.
• A use case is optionally extended by
  functionality of another use case.

54
Example Date2date Extend
Ontleend aan Sander Hoogendoorn
55
Relationships between use cases
56
Example Date2date System boundary Secondary
actor
Ontleend aan Sander Hoogendoorn
57
Short Summary
58
What is Use Case modeling?

• Use Case model a view of a system that
  emphasizes the behavior as it appears to outside
  users. A use case model partitions system
  functionality into transactions(use cases) that
  are meaningful to users (actors)
• A Use Case Diagram visualizes a use case model.

59
Core Elements
60
Core Relationships
61
Core Relationships
62
Use Case Diagram Example
63
NS Ticket service
Destination

• Define a use case diagram of NS Ticket service
• Describe an use case.

Take ticket
64
Use Case diagram NS Ticket service
65
 
 
66
Exercise UCD

• Starting point is the MKW casus
• Make a Use Case Diagram of the MKW system and
  describe the use cases with an use case text.