Case Study #1
Library System
Arry Akhmad Arman
School of Electrical Engineering and Informatics
Institut Teknologi Bandung, Indonesia
Email: arman@kupalima.com
Website: http://www.kupalima.com
Blog: http://kupalima.wordpress.com
Download Center: http://slideshare.net/kupalima
Course milist: arman_course_se@yahoogroups.com
Last update: April 22, 2010
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
High Level Requirements
•
•
•
•
•
•
•
•
It is a support system for a library.
The library lends books and magazines to borrowers, who are registered in the system, as
are the books and magazines.
The library handles the purchase of new titles for the library. Popular titles are bought in
multiple copies. Old books and magazines are removed when they are out of date or in
poor condition.
The librarian is an employee of the library who interacts with the customers (borrowers)
and whose work is supported by the system.
A borrower can reserve a book or magazine that is not currently available in the library, so
that when it’s returned or purchased by the library, that borrower is notified. The
reservation is canceled when the borrower checks out the book or magazine or through
an explicit canceling procedure.
The librarian can easily create, update, and delete information about the titles, borrowers,
loans, and reservations in the system.
The system can run on all popular Web browser platforms (Internet Explorer 5.1+,
Netscape 4.0+, and so on).
The system is easy to extend with new functionality.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Find the Actors and Use-Case
• The first step in use-case modeling is to define the actors that represent those
who interact with the system and the use cases that describe what the library
system provides in terms of functionality to those actors—the functional
requirements of the system.
• While identifying the use cases, you must read and analyze all specifications, as
well as discuss the system with potential users of the system and all
stakeholders.
• The actors in the library are identified as the librarians and the borrowers,
because both are users of the system.
–
–
The librarians have management capability to add borrowers, titles, and items.
The borrowers are people who check out and reserve books and magazines. Occasionally a
librarian or another library can be a borrower.
• Finally, we have a Master Librarian actor—this role is capable of managing the
librarians as well. It is possible to add a title to the system before the library has
a copy (an item), to enable borrowers to make reservations.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Indetified Use-Cases
•
•
•
•
•
•
•
•
•
•
•
•
Login
Search
Browse
Make Reservation
Remove Reservation
Checkout Item
Return Item
Manage Titles
Manage Items
Manage Borrowers
Manage Librarians
Assume Identity of Borrower
Arry Akhmad Arman
• Note the difference in concepts
between “title” and “item.”
• Because a library often has several
copies of a popular title, the system
must separate the concept of the
title—the name of a book and the
book’s author—and a separate
physical copy of the same title, which
is an item.
School of Electrical Engineering and Informatics | ITB | 2010
Use Case Diagram
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Domain Modeling
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
State Machine Diagram for Title Class
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Use-Case Analysis
• Assuming that you have done some domain analysis, you
have a simple set of classes that begin to demonstrate the
analysis classes involved in your system.
• That is a good start, but to really enrich your model you
perform use-case analysis to
– refine the classes,
– add additional classes, and
– add operations and attributes to these classes,
so that each helps to represent what goes on during the
execution of the various paths through your use cases.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Use-Case Analysis
You use static diagrams (for example, class
diagrams) and dynamic diagrams (for
example, sequence diagrams) to illustrate how
classes and their instances collaborate to
perform the actions required
by the use cases.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Typical Classes Category
Analysis classes are typically organized as one of the following:
•
•
•
<<entity>>. As you have already seen, entity classes represent those classes that have meaning in the
domain and are likely have long lifetimes in your system. The reality of long lifetime is that they require
some form of persistence so that they can exist beyond the execution of a single use case or session
with a user. In the majority of applications today, you can infer that some form of database is used to
support the persistence of entities.
<<boundary>>. Boundary classes are used to represent those things that are necessary to provide a
means for actors to communicate with the system. In the case of an interactive user, boundary classes
represent their user interface mechanisms (for example, a form or page). In the case of non interactive
users, like an external system or device, you can typically expect some protocol-based interface to
shuttle communication between the system and the nonhuman actor. During use-case analysis, you
generally create a single boundary class for every actor system relationship found in the use-case
model.
<<control>>. Control classes are used as the placeholder of the coarse grained logic of a use case. You
usually start out by creating a single control class for each use case you are analyzing.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Create Sequence Diagram
for each Use Case
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
VOPC
• VOPC (View of Participating Class) is partial classes
(part of complete class) that only show related
classes to a specific use case.
• VOPC need to simplify the analysis process of the
system
• Create VOPC for each use case and sequence
diagram, and update classes in VOPC if needed.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
VOPC for Use Case Checkout Item
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Communication Diagram
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Repeat this process for all use case
Use
case #1
Use
case #2
Use
case #3
Use
case #4
Use
case #5
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Design
• Architectural design.
• Detailed design.
This is the high-level design
where you define the packages
(subsystems), including the
dependencies and primary
communication mechanisms
between the packages.
• Naturally, a clear and simple
architecture is the goal, where
the dependencies are few and
bi-directional dependencies are
avoided if at all possible.
This part details the contents in
the packages, so that all classes
are described in enough detail
to give clear specifications to
the programmer who codes the
class.
• Use dynamic models from the
UML to demonstrate how
objects of the classes behave in
specific situations.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
System Structure (1)
• presentation.
•
•
• controller.
This contains classes for the entire user
interface, to enable the user to view
data from the system and to enter new
data.
The standard for presenting this
information to the user in a Java Web
application is to use JSP. This package
cooperates with the business objects
(via the Value Objects) and the
controller packages.
The user interface package uses the
Value Objects and posts data so that it
can be sent to the Controller package.
The classes in this package are
responsible for most of the application
control and also provide “traffic cop”
mechanisms to help delegate
dependencies to and separate them
between the presentation and domain
packages.
presentation
controller
dao
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
business
vo
System Structure (2)
• business. This includes the domain
classes from the analysis model such as
Borrower, Title, Item, Loan, and so on.
These classes are detailed in the design
so that their operations are completely
defined. The business object package
cooperates with the database package
via an associative relationship.
• vo. The vo package is so named as it
•
contains simple Value Objects, which are
lightweight representations of domainrelated things.
The Value Object (VO) is yet another
common pattern used to limit the
passing of heavyweight objects and
traffic across enterprise systems.
• dao. Named dao because it contains a
Data Access Object (DAO) that
represents a commonly used design
pattern that encapsulates all data
related activity into discrete classes. This
is the means to firewall or limit the
knowledge of how things are persisted.
presentation
controller
dao
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
business
vo
Architectural View of
“Package of Class Diagram”
presentation
controller
dao
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
business
vo
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Rebuild Sequence Diagram
Business logic
oriented
Sequence diagram in design
Sequence diagram from analysis
Implementation
oriented
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
References for Coding
For coding, the specifications are collected from the
following diagrams in the design model:
• Class diagrams. The class diagrams in which the class is
present, showing its static structure and relationship to
other classes.
• State machine diagram. A state machine diagram for
the class, showing the possible states and the
transitions that need to be handled (along with the
operations that trigger the transitions).
• Dynamic diagrams (sequence, communication, and
activity) in which objects of the class are involved.
Diagrams showing the implementation of a specific
method in the class or how other objects are using
objects of the class.
• Use-case diagrams and specifications. Diagrams that
show the result of the system give the developer more
information on how the system is to be used when he or
she might be getting lost in details—losing sight of the
overall context.
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Development Steps
• Requirement
– Vision (High Level
Requirements)
– Use Case Model
– Domain Model
• Implementation
• Test and Deployment
• Analysis
– Use Case Analysis
• Design
– Architecture Design
– Detail Design
– User Interface Design
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010
Thank you
THIS SLIDES CAN BE DOWNLOADED IN
http://www.slideshare.net/kupalima
Arry, Farid, Armein
Jembatan Golden Gate, San-Francisco, 2001
Dalam rangka Comparative Study
Untuk Pengembangan Industri Software di Indonesia
Arry Akhmad Arman
School of Electrical Engineering and Informatics | ITB | 2010