Advance System analysis

Agile Model–Driven Development (AMDD), Usage

Modeling

1
What Is Agile Modeling (AM)?
 practice-based methodology for effective
modeling and documentation of software-
based systems.
 The AM methodology is a collection of
practices, guided by principles and values

2
The Values of AM
 Communication. It is critical to have effective
communication within your development team as well
as with and among all project stakeholders.

 Simplicity. Strive to develop the simplest solution

possible that meets all of your needs.

 Feedback. Obtain feedback regarding your efforts

often and early.

 Courage. Have the courage to try new techniques and

to make and then stick to your decisions.

 Humility. You need to have the humility to admit that

you may not know everything, that others have value
to add to your project efforts.
3
Agile Methodologies
 Dynamic system development method
(DSDM)
 Extreme programming (XP)
 Feature-driven development (FDD)
 ICONIX
 Rational unified process (RUP)

4
Usage Modeling
 You need to understand how people will work
with your system.

 Usage modeling explores how people work

with a system, vital information that you
require if you are going to successfully build
something that meets their actual needs

5
 Usage Modeling Techniques
Technique Description
Essential use cases A use case describes something of value to an actor (often a person or organization). An
essential use case is a use case that is technology independent—it describes the fundamental
business task without bringing technological issues into account. Essential use cases are often
used to explore usage-based requirements.

System use cases System use cases are use cases that bring technological concerns into account. System use
cases are the primary requirements artifact for the rational unified process (RUP) (Kruchten
2000), although they are arguably analysis and perhaps even design artifacts.

UML use case diagram UML use case diagrams provide an overview of the use cases and actors pertinent to your
business domain.
User story User story is a fine-grained requirement that provides just enough information from which
developers can estimate the effort to implement it and project stakeholders can prioritize it.
User stories are a primary development artifact of extreme programming (XP) (Beck 2000).

Feature Features are very fine-grained requirements that can often be implemented in several hours.
Features are the primary requirements artifact for feature-driven development (FDD) (Palmer
and Felsing 2002).

6
Use Case Modeling
 Use case diagrams are one of the standard Unified
Modeling Language (UML)

 There are two basic flavors of use case models:

 essential use case models
 often referred to an abstract use case model, independent
view of your behavioral requirements

 system use case models.

 detailed use case models model your analysis of your
behavioral requirements, describing in detail how users will
work with your system, including references to its user-
interface aspects

7
Essential Use Case Diagrams
 Use case diagrams depict , figure1:
 Use cases. A use case describes a sequence of actions and is
drawn as a horizontal ellipse.

 Actors. An actor is a person, organization, or external system

that plays a role in one or more interactions with your system.
Actors are drawn as stick figures.

 Associations. Associations between actors and use cases are

indicated in use case diagrams by solid lines.

 System boundary boxes (optional). You can draw a

rectangle around the use cases, called the system boundary
box, to indicate the scope of your system.

 Packages (optional). Packages are UML constructs that

enable you to organize model elements (such as use cases) into
groups. Figure 1 doesn’t have package but figure 2 has one

8
Figure 1, simple use case diagram for a
university.

9
The Manage Seminar Registration
package.

10
Explaining Figure 1
 students are enrolling in courses with the potential help of registrars.

 Professors input the marks students earn on assignments and

registrars authorize the distribution of transcripts (report cards) to
students

 Note how for some use cases there is more than one actor involved.

 Moreover, note how some associations have arrowheads—any given

use case association will have a zero or one arrowhead.

 The line between the Enroll in Seminar use case and the Registrar
actor has no arrowhead in figure 1, indicating it is not clear how the
interaction between the system and registrars start. Perhaps a
registrar may notice a student needs help and offers assistance,
whereas other times, the student may request help from the
registrar

11
More complex university Use Case

12
Identifying Actors
 An actor represents anything or anyone that
interfaces with your system
 This may include people
 external systems
 Actors are always external to the system
being modeled

13
System Use Case Diagrams
 A system use case model is similar to an
essential use case model.
 The main difference between an essential use
case and a system use case is that in the
system use case you include high-level
implementation decisions.
 For example, a system use case refers to specific
user- interface components—such as screens,
HTML pages, or reports—something you would not
do in an essential use case

14
Figure 4 , system use case for figure 3
essential use case

15
 system use case diagram in figure 4 .
 There are several interesting changes
 First, deployment decisions are now reflected in
the diagram. For example, you see that the post
office is used to distribute information to students
 You also see that student marks are input, instead
of "recorded.
 Similarly teaching schedules are printed now
instead of produced.
 Relationships between some use cases have been
introduced “Extend ”

16
Reuse in Use Case Models:
<<extend>>, <<include>>,
and Inheritance
 One of goals during analysis is to identify
potential opportunities for reuse.
 Potential reuse can be modeled through four
generalization relationships :
 extend relationships between use cases,
 include relationships between use cases,
 inheritance between use cases,
 and inheritance between actors

17
 extend relationships between use cases:
 Extending use case continues the behavior of a base use
case .The extending use case accomplishes the extened
by conceptually inserting additional action sequences into
the base use case sequence. This allows an extending use
case to continue the activity sequence of a base use case
when the appropriate extension point is reached in the
base use case and the extension condition is fulfilled
 When the extending use case activity sequence is
completed, the base use case continues.
 Perform Security Check extends the use case Enroll in
University, the notation for doing so being simply a normal
use case association with <<extend>>.
 We say that Enroll in University is the base use case and
Perform Security Check is the extending use case

18
Figure 5, The opportunities for reuse in
use case models

19
 An include association within use case
models.
 denoting the inclusion of the behavior
described by another use case
 In figure 5 you see the Enroll in the university
including in seminar.

20
 Use cases can inherit from other use cases
 depicts an example of this, showing that Enroll
Family Member in University inherits from the
Enroll in University use case
 Inheritance between use cases is not as
common as the use of either extend or include
associations

21
 Inheritance between use cases is not as
common as the use of either extend or include
associations.
 An example of this is shown in the International
Student actor inherits from Student
 An international student is a student, the only
difference being is he or she is subject to different
rules and policies
 The standard UML notation for inheritance,
the open-headed arrow, is used and the
advice presented about the appropriate use of
inheritance still applies
22
 Use Case Description
Use Case Student enrolled in seminar
Name:
Successful end Student is registered in seminar
condition
Failed end condition The application for registered new student is rejected
Primary Actor Registrar
Main Flow Step Action
1 The registrar open the registration system
2 The registrar enter the student number
3 The system view the student information
4 The registrar enter the course to be registered
5 The student eligibility is authorized to take the course
6 The student is registered in the course
7 A notification of registration is appear
Extensions Step Action
5.1 The student is not eligible to take the course
5.2 The student registration is rejected
23