CIS224 Software Projects: Software Engineering and Research Methods - PowerPoint PPT Presentation

Loading...

PPT – CIS224 Software Projects: Software Engineering and Research Methods PowerPoint presentation | free to download - id: 1465a0-OTQ3Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CIS224 Software Projects: Software Engineering and Research Methods

Description:

... modeling languages for software development have been around for a long time ... System should produce reminders when a book is overdue ... – PowerPoint PPT presentation

Number of Views:51
Avg rating:3.0/5.0
Slides: 40
Provided by: davidme152
Learn more at: http://www.titanmusic.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CIS224 Software Projects: Software Engineering and Research Methods


1
CIS224Software Projects Software Engineering
and Research Methods
  • Lecture 2b
  • Introducing the Unified Modeling Language (UML)
  • (Based on Fowler (2004, Chapter 1) and Stevens
    and Pooley (2006, Preface Chapter 3))

David Meredith d.meredith_at_gold.ac.uk www.titanmus
ic.com/teaching/cis224-2007-8.html
2
What is UML and why should we bother with it?
  • UML is a graphical notation system for designing
    and describing component-based and
    object-oriented software
  • graphical modeling languages for software
    development have been around for a long time
  • textual programming languages not abstract enough
    for discussing high-level design
  • diagrams good at communicating design without
    lots of detail
  • not a replacement for a textual programming
    language
  • UML is an open standard controlled by the Object
    Management Group (OMG)
  • www.uml.org
  • OMG set up to build standards to support
    interoperability of object-oriented systems
  • This course will focus on the current standard
    which is UML 2.0
  • Familiarity with UML has become a core skill for
    software engineers

3
Modes of using UML
  • Sketch mode
  • most common
  • forward engineering make UML diagram then write
    code
  • reverse engineering derive UML diagram from code
  • focus on important features and leave out detail
  • Blueprint mode
  • emphasis on completeness
  • forward engineering build detailed design for
    programmers to implement
  • like architect designing a building which is
    built by construction company
  • Programming language mode
  • draw UML diagrams that are automatically compiled
    into executable code
  • Model Driven Architecture (MDA) (Kleppe et al.,
    2003)
  • standard approach to using UML as a programming
    language
  • Three stages
  • PIM - platform-independent model (in UML)
  • PSM - platform-specific model (e.g., different
    for .NET or Java, probably also in UML)
  • executable code
  • Executable UML (Mellor and Balcer, 2002)
  • Model compiler compiles UML directly into
    executable code without passing through PSM stage

4
Using UML from two perspectives
  • Software perspective
  • Using UML to model software systems
  • Direct mapping from UML elements to software
    elements
  • Two levels of abstraction (but not clear-cut
    demarcation between them)
  • Interface
  • Specification
  • how an object behaves (i.e., what it does)
  • how we interact with an object
  • Implementation
  • how an object achieves its behaviour (i.e., how
    exactly it does what it does)
  • Conceptual perspective
  • Using UML to represent concepts in some
    non-software domain (e.g., business processes)

5
We will be using UML
  • from a software perspective
  • at the interface level of abstraction
  • in sketch and blueprint mode

6
Views on a design
  • When we want to express a design, we do not try
    to express all aspects of it at once
  • Build different models to describe different
    aspects
  • Express models as diagrams in a modelling
    language like UML

7
Three basic types of model
  • Use case model
  • describes system from the point of view of the
    users
  • Static structural model
  • describes elements of the system and the
    relationships between them
  • Dynamic behavioural model
  • describes behaviour of the system over time

8
UML 2.0 diagrams
  • 13 official diagram types in UML 2.0
  • Box represents a diagram type
  • Open-headed arrow indicates generalization
  • Will only cover a small fraction of the complete
    UML in this course, concentrating on the more
    commonly used diagram types

9
Legal UML
  • normative UML conforms to the standard
    specification
  • conventional UML may not conform to standard
    (i.e., may be non-normative) but commonly used in
    practice
  • UML rules are treated as descriptive, not
    prescriptive
  • but must have well-defined meaning, even if not
    strictly legal UML
  • otherwise the diagrams cannot be interpreted
    reliably

10
Suppression in UML
  • Anything may be suppressed in a UML diagram
  • Therefore cannot assume that something is not in
    the system simply because it is not in the
    diagram!
  • Unless it conflicts with what is in the diagram

11
Using non-UML diagrams
  • Dont need to use UML all the time!
  • Sometimes non-UML diagrams are useful
  • Screen flow diagrams
  • Flow charts
  • Decision tables
  • Class-Responsibility-Collaboration (CRC) cards

12
Using UML in requirements analysis
  • Use case diagram to describe how people interact
    with the system
  • Class diagram for building up vocabulary of
    domain
  • Activity diagram to describe how humans interact
    with software in the organisation
  • State diagram for describing complex life cycle
    of a concept
  • Have to communicate with users and customers who
    may not be experts in software engineering
  • Keep notation to a minimum
  • Avoid implementational details
  • Domain experts (users) must understand your
    diagrams

13
Using UML in design
  • Class diagrams from a software perspective
  • Sequence diagrams and CRC cards for common
    scenarios
  • Package diagrams for large-scale structure of
    software
  • State diagrams for classes with complex
    life-cycles
  • Deployment diagrams to show physical layout of
    software

14
Using UML in documentation
  • Use UML diagrams in sketch mode to highlight and
    illustrate interesting features
  • Remember
  • Comprehensiveness is the enemy of
    comprehensibility

15
Using UML to study other peoples code
  • Use UML in sketch mode to make graphical notes
    about the structure and behaviour of a piece of
    software or code that you are studying

16
Introductory case studyInitial problem statement
  • You have been contracted to develop a computer
    system for a university library. The library
    currently uses a 1960s program, written in an
    obsolete language, for some simple bookkeeping
    tasks, and a card index for user browsing. You
    are asked to build an interactive system which
    handles both of these aspects online. (Stevens
    and Pooley, 2006, p. 27)

17
Clarifying the requirements
  • Initial problem statement is vague
  • Need a more detailed analysis before agreeing to
    tackle the problem
  • Requirements engineering is difficult because
  • Different users have different priorities
  • Users are not good at imagining or expressing
    what an ideal system would be like
  • Managers who talk to developers might not be
    users and so might not have experience of doing
    the jobs that the system is supposed to help with

18
Requirements in more detail
  • Books and journals
  • Library contains books and journals
  • May have several copies of a given book
  • Some books are for short-term loan
  • Other books can be borrowed by any library member
    for 3 weeks
  • Only members of staff may borrow journals
  • Ordinary library members may borrow up to 6 items
    at a time
  • Members of staff may borrow up to 12 items at a
    time
  • New books and journals are added to the library
    and old ones are sometimes disposed of
  • Current years journals are sent away to be bound
    into hardback volumes at the end of each year

19
Requirements in more detail
  • Borrowing
  • System must keep track of when books and journals
    are borrowed and returned
  • System should produce reminders when a book is
    overdue
  • In the future, users may need to be able to
    extend a loan if the item is not reserved

20
Requirements in more detail
  • Browsing
  • Users should be able to search for a book on a
    particular topic, by a particular author, etc. in
    order to
  • Check if a copy of the book is available
  • Reserve a copy if it is not
  • Anyone can browse in the library

21
Users and tasks
  • High quality system must meet its users needs
  • Need to identify users of a system
  • Need to identify tasks each user must carry out
    with the system
  • Need to prioritise tasks in order of importance
  • So that we can plan development

22
Actors and use cases
  • In UML
  • User is modelled by an actor
  • Task is modelled by a use case
  • Actor
  • User of a system in a particular role
  • e.g., library member as book borrower
  • External system which interacts with our system
  • E.g., bar-code reading machine
  • Use case
  • Task that actor needs to perform with the help of
    our system
  • E.g., borrow a copy of a book
  • May involve a complex process
  • E.g.
  • Checking that the library member has not borrowed
    the maximum number of books
  • Checking that the book can be borrowed
  • May include two or more scenarios, each with a
    different type of outcome
  • E.g.
  • User allowed to borrow book
  • User refused permission to borrow book

23
Documenting a use case
  • Document each use case in third person, active
    voice, e.g.
  • Borrow copy of book A BookBorrower presents a
    book. The system checks that the potential
    borrower is a member of the library, and does not
    already have the maximum permitted number of
    books on loan. This maximum is 6 unless the
    member is a staff member, in which case it is 12.
    If both checks succeed, the system records that
    this library member has this copy of the book on
    loan. Otherwise, the system refuses the loan.
  • In use case description, say what system must
    achieve, not exactly how it should achieve it
  • E.g., dont say exactly how system stores
    information about a loan

24
Use case diagram
Avoid adding use cases that the customer or users
havent told you to include!
25
Using use cases to determine goals of iterations
  • Decide what most important use cases are and
    provide these in early iterations
  • For example
  • in library case study, most important use cases
    might be
  • Borrow copy of book
  • Return copy of book
  • Borrow journal
  • Return journal
  • So aim to provide these at end of first iteration

26
Limited use case analysis for first iteration
Books and Journals The library contains books
and journals. It may have several copies of a
given book. Some of the books are for short term
loans only. All other books may be borrowed by
any library member for three weeks. Members of
the library can normally borrow up to six items
at a time, but members of staff may borrow up to
12 items at one time. Only staff members may
borrow journals. Borrowing The system must keep
track of when books and journals are borrowed and
returned, enforcing the rules described above.
27
Identifying classes
  • Classes correspond to key domain abstractions
  • Domain is application area that were working in
    (e.g., the library)
  • Abstraction represents only relevant important
    properties of a domain concept or thing
  • Can use noun identification technique to help
    with identifying appropriate classes

28
Noun identification technique
  • Take a clear concise statement of requirements or
    use case descriptions
  • Underline all nouns and noun phrases
  • This gives us candidate classes
  • Remove inappropriate classes to get initial class
    list for the system

29
Example of noun identification technique
  • Books and Journals The library contains books
    and journals. It may have several copies of a
    given book. Some of the books are for short term
    loans only. All other books may be borrowed by
    any library member for three weeks. Members of
    the library can normally borrow up to six items
    at a time, but members of staff may borrow up to
    12 items at one time. Only members of staff may
    borrow journals.
  • Borrowing The system must keep track of when
    books and journals are borrowed and returned,
    enforcing the rules described above.
  • Initial class list
  • Book, Journal, Copy, LibraryMember, (Item?),
    StaffMember

30
Objects representing actors
  • There isnt always an object in a system
    representing each actor (e.g., StaffMember or
    LibraryMember objects)
  • Can make objects representing actors responsible
    for carrying out actions on behalf of those
    actors
  • E.g., send message borrow(theCopy) to
    LibraryMember object representing Jo Bloggs when
    Jo borrows a copy of a book
  • In library system, need to know how many books
    each member has on loan, so makes sense to have a
    LibraryMember object for each member

31
Associations between classes
  • Having identified initial class list, then
    identify important real-world relationships or
    associations between the classes
  • Clarifies understanding of domain
  • Reveals coupling in the system
  • OK for closely-related domain objects to be
    associated since expect one class to depend on
    the other
  • Examples of real-world associations in the
    library system
  • a copy is a copy of a book
  • a library member borrows or returns a copy
  • a member of staff borrows or returns a copy
  • a member of staff borrows or returns a journal

32
Class model for the library system
33
Class model for library system(improved version)
34
Dynamic behavioral models
  • Class model describes static structure of system
  • Also need to describe dynamic behaviour of system
  • How classes work together to provide the
    behaviour required by the use cases
  • Interaction diagrams show how messages pass
    between objects to realize a use case

35
Library member borrows a book
  • Human library member (BookBorrower actor) comes
    to issue desk with physical copy of book
    (represented by theCopy Copy).
  • Library member (represented by theLibraryMember
    LibraryMember) and copy of book identified
  • borrow(theCopy) message sent to theLibraryMember.
  • theLibraryMember checks that the library member
    is permitted to borrow the book (might send an
    okToBorrow() message to itself).
  • If theLibraryMember can borrow the copy of the
    book, then a beBorrowed(theLibraryMember) message
    is sent to theCopy which updates itself with the
    information that it has been borrowed by
    theLibraryMember.
  • It may also be necessary for the theCopy to send
    a copyBorrowed(theCopy) message to an object,
    theBook Book, which represents the book of which
    theCopy is a copy.

36
Sequence diagram of Borrow copy of book use
case
37
State machine diagram of Book
38
Going further
  • Having worked out sequence diagram and state
    machine diagram, can go back to class model and
    add attributes and operations to some of the
    classes
  • Once identified how all use cases are realized,
    down to level of which messages are passed, can
    then implement the classes and complete the first
    iteration

39
Summary
  • UML is a graphical notation system for designing
    and describing component-based and
    object-oriented software
  • can be used in sketch mode, blueprint mode or
    programming language mode
  • can be used from a software perspective or a
    conceptual perspective
  • three basic types of model
  • use case models
  • static structural models
  • dynamic behavioural models
  • UML standard is descriptive not prescriptive
  • but must be comprehensible with well-defined
    meaning
  • almost anything can be suppressed in a UML
    diagram
  • UML can be used in requirements analysis, design,
    documentation and for studying legacy code
  • considered a simple case study which involved
    designing a library system
  • Requirements analysis using UML use case diagrams
  • Using the use case analysis to determine goals of
    iterations
  • Identifying classes using noun identification
    technique
  • Using class model to represent classes and
    associations between them
  • Using a sequence diagram to represent the dynamic
    behaviour of the system when it realizes a use
    case
  • Using a state machine diagram to represent how
    the state of a class changes when it receives
    messages
About PowerShow.com