Software Engineering and The Unified Modeling Language UML Part II

1
Software Engineering and The Unified Modeling
Language (UML) Part II
2

• The examples, and most of the facts, used in this
  presentation were taken from the book
• Using UML Software Engineering With Objects
  and Components
• by Rob Pooley and Perdita Stevens

3
The Development Process

• A development process is a set of rules which
  define how a development project should generally
  be carried out. This may include a description of
  what documents, design models and other artifacts
  should be produced and in what order.

4
The Development Process

• What are some characteristics of a Good
  Development Process?
• It takes risk management as a central concept
• It uses iteration as a means of controlling risk
• It is architecture-centric and component-based
• It should have, as high-priority activities, the
  following and making of good architectural
  decisions
• It should use and develop good components

5
The Development Process

• The final characteristic that any Good
  development process should have
• It should be use case driven.

6
UML is a Modeling Language, not a Development
Process

• What is the Difference?
• A development process is a methodology, one of
  many. It uses a modeling language to express the
  models produced during its use.

7
Definition of Terms

• A Model is an abstract representation of a
  specification, a design or a system, from a
  particular point of view. It is often
  represented visually by one or more diagrams.
• A Modeling Language is a way of expressing the
  various models produced during the development
  process. A modeling language defines a collection
  model elements, which are similar to the
  utterances in a spoken language. UML is an
  example of a modeling language.

8
Definition of Terms

• Syntax in a diagram-based modeling language,
  the rules that determine which diagrams are legal
• Semantics -- the rules that determine what a
  legal diagram means

9
Examples of Processes

• Waterfall Process
• Spiral Process

10
The Waterfall Process

• This process is broken into five parts, the
  phases of the lifecycle. The process is divided
  on the basis of the activity that is being
  performed. This process implies that the phases
  are being finished, one after the other, and that
  once a phase is completed, it is never re-entered.

11
The Waterfall Process
12
The Waterfall Process

• This process has been, at least partially
  discredited.
• Why?
• What are some of the problems that this process
  could cause?

13
The Waterfall Process

• Given its obvious disadvantages, why is the
  Waterfall Process so hard to give up?
• What advantages does it have, and to whom?
• Under what circumstances might you be right to
  decide to live with the disadvantages?

14
The Spiral Process

• Starting from the center, a project following
  this process goes through successive risk
  analysis and planning, requirements analysis,
  engineering and evaluation phases. The
  engineering phase involves design, implementation
  and testing.

15
The Spiral Process
16
The Spiral Process

• There is some ambiguity concerning this process.
• It doesnt tell how each phase is done
• It doesnt tell what the outcome of an
  implementation phase is
• Is it a running system with more functionality
  each time?
• Is it a more detailed set of models of a system,
  which becomes a running system only in the final
  iteration?

17
Risk Management

• Any time you make a decision, you run the risk
  that it is wrong. More importantly, the later an
  error is discovered, the harder it is likely to
  be to put right. Therefore, we may try to control
  risk by discovering errors as soon as possible.
  One way is to have evaluation steps frequently
  and explicitly defined by the process.
• A major risk is that the developers may
  misunderstand the requirements. Anything which
  increases confidence that the stated requirements
  are correct reduces risk. It is often easier to
  criticize a system than to describe it, so
  prototyping a system may be a good way to firm up
  the requirements.

18
Class Models
19
What kind of things are Classes?

• Tangible or real-world things book, copy,
  course
• Roles library member, student, director of
  studies
• Events arrival, leaving, request
• Interactions meeting, intersection

20
Class Identification

• Two methods of class identification will be
  introduced
• Noun Identification
• CRC Cards

21
Noun Identification

• Identify candidate classes by picking out all of
  the noun and noun phrases from a requirement
  specification of the system.
• Discard candidates which are inappropriate for
  any reason, renaming the remaining classes if
  necessary.

22
Reasons for Removal

• Redundant The same class is given more than one
  name.
• Vague You are unable to determine the meaning
  of a noun.
• An Event or an Operation The noun refers to
  something which is done to, by or in the system.
• Meta-language the noun forms part of the way we
  define things.
• Outside the Scope of the System The noun is
  relevant to describing how the system works, but
  does not refer to something inside the system.
• An Attribute A noun refers to something simple
  with no interesting behavior, which is an
  attribute of another class.

23
CRC Cards

• Use CRC cards to walk through use cases, working
  out how the class model provides the
  functionality required by the uses cases.
• First pick a scenario from a use case.
• Find the CRC card which represents the class
  which is responsible for realizing the scenario.
  This situation represents an object of that class
  receiving a message from the initiator of the
  scenario.
• If the object needs assistance from one of its
  collaborators, it will send a message requesting
  that the collaborator perform an operation.
• Each operation which an object is asked to
  perform should form part of the responsibility of
  that objects class.
• The responsibility of a class can be seen as a
  summary of the operations that it can perform.

24
CRC Cards

• An alternative method of using CRC Cards is to
  arrange the cards to represent relationships
  between them think of it as drafting a class
  model.
• Try putting cards together that are related by
  generalization, with the most abstract on top, so
  that you use the specialized class only when the
  particular specialization is relevant.

25
Associations

• Classes correspond to nouns, associations
  correspond to verbs.
• There are instances of associations, just as
  there are instances of classes. An instance of an
  association relates a pair of objects.

26
Associations

• Class A and class B are associated if
• An object of class A sends a message to an object
  of class B
• An object of class A creates an object of class B
• An object of class A has an attribute whose
  values are objects of class B or collections of
  objects of class B.
• An object of class A receives a message with an
  object of class B as an argument

27
Associations

• Class A and Class B are associated if some object
  of class A has to know about some object of class
  B. Each link (each instance of the association)
  relates an object of class A and an object of
  class B.

28
Multiplicities

• The number at each end of an Association is the
  multiplicity.
• Multiplicity can be specified as
• An exact number (1)
• A range of numbers (1..5)
• An arbitrary, unspecified number ()

29
Attributes and Operations

• The system that is built will consist of a
  collection of objects, which interact to fulfill
  the requirements of the system.
• We need to identify the operations and attributes
  each class will have.

30
Attributes

• The attributes of a class describe the data
  contained in an object of the class. They are
  listed in the middle compartment of a class icon.

31
Operations

• The operations of a class define the ways in
  which objects may interact. When one object sends
  a message to another, it is asking the receiver
  to perform an operation. The receiver will invoke
  a method to perform the operation. Operations are
  listed in the bottom compartment of a class icon.

32
Generalization

• What is meant by the term Generalization?
• An object of a specialized class can be
  substituted for a object of a more general class
  in any context which expects a member of the more
  general class, but not the other way around.

33
Generalization

• How can Generalization be implemented?
• Inheritance
• What problems can inheritance cause?
• A subclass is dependent on its superclasses
• Fragile base class problem
• If a superclass is changed, even in ways which do
  not affect its behavior, the recompilation of
  subclasses may be forced, or changes to the
  subclass code could even be necessary.

34
Generalization

• How can Generalization be implemented?
• Composition
• if you want to implement a class such as
  AddressBook using a List class, rather that have
  AddressBook inherit from List, let AddressBook
  own a List (have an attribute -- addresses
  List)

35
Conclusions, Class Models

• One secret of good object oriented design is to
  end up with a class model which does not distort
  the conceptual reality of the domain, but which
  also permits a sensible implementation of the
  required functionality.

36
Advanced Topics

• In the course of these presentations, only the
  most basic of concepts from UML have been
  introduced.

37
Advanced Topics

• In order to be successful as a Software Engineer,
  you will need to immediately become familiar with
  these basic concepts, and, over the course of
  time, learn to use advanced UML constructs.
• In these presentations, we have only scratched
  the surface

38
Advanced Topics

• These concepts include, but are not limited to
• Advanced Class Model issues
• Aggregation and Composition
• Roles
• Navigability
• Qualified Associations
• Derived Associations
• Constraints
• Association Classes
• Interfaces

39
Advanced Topics

• These concepts include, but are not limited to
• Advanced Use Case issues
• System Boundary
• Problems with Use Cases
• Relationships between Use Cases
• Relationships between Actors

40
Advanced Topics

• These concepts include, but are not limited to
• Interaction Diagram issues
• Collaborations
• Sequence Diagrams
• Timing
• Iteration
• Concurrency

41
Advanced Topics

• These concepts include, but are not limited to
• Advanced State diagram issues
• Levels of Abstraction
• States, transitions and events
• Actions
• Guards
• Activity Diagrams

42
Advanced Topics

• As well as a host of other, more interesting (and
  complicated!) issues!

43
This and that
44
Use Cases

• Do not invent requirements!
• Use cases are about the users requirements, not
  about what you, as the designer might think that
  the system could usefully do!

45
Persistence

• Objects which must last longer than the lifetime
  of a running instance of the program are called
  persistent.