UML2.0. 1. Schedule(2/2). • Feb. 25th. – 13:00 Outline of UML: Static Modeling. (
details of class definition). – 14:30 Outline of UML: Dynamic Modeling.
Koichiro Ochimizu, JAIST
Schedule(2/2) • Feb. 25th – 13:00 Outline of UML: Static Modeling (details of class definition) – 14:30 Outline of UML: Dynamic Modeling (state machine, communication diagram, sequence diagram)
• March. 4th – 13:00 Unified Process and Usecase-Driven Approach Case Study: Elevator Control System – 14:30 UML2.0, Contribution of OO in SE
UML2（UML2.0） James Rumbaugh, Ivar Jacobson, Grady Booch, “The Unified Modeling Language Reference Manual, Second Edition”, Addison-Wesley, 2005.
Koichiro Ochimizu Japan Advanced Institute of Science and technologies School of Information Science
UML2.0
1
Koichiro Ochimizu, JAIST
MDA and CBSD • MDA ( Model Driven Architecture) • CBSD (Component Based Software Development)
MDA(1/2) M3 MetaMetaModel
M2
MOF (Meta Object Facility)
UML Class, UML Association, CWM Table
MetaModel M1
Class “Customer”, Class “Account”
Model M0
Customer Jane Smith, Account 2989
objects and data
UML2.0
2
Koichiro Ochimizu, JAIST
MDA(2/2) Meta Language is-described-by
Language 1
is-described-by PIM (Platform Independent Model)
is-described-by
Mapping Definition is-used-by
Translator
Language 2
is-described-by PIM (Platform Specific Model)
New Features of UML2.0 • Sequence Diagram constructs and notation based largely on the ITU（International Telecommunication Union）Message Sequence Chart standard, adapted to make it more objectoriented • Decoupling of activity modeling concepts from state machines and use of notation popular in the business modeling community. • Contextual modeling constructs for the internal composition of classes and collaborations. Theses constructs permit both loose and strict encapsulation and wiring of internal structures from smaller parts. • Repositioning of components as design constructs and artifacts as physical entities that are deployed
UML2.0
3
Koichiro Ochimizu, JAIST
Structured Control constructs in a Sequence Diagram sd ticketing kiosk：Kiosk
Credit card service: Credit Card Service
box of office：Box Office
request(count, performance)
loop
lifeline
show availability (seat-list) select(seat) demand payment (cost) insert card (card number)
message charge (card number, cost)
alt
authorized print tickets ( performance ,seats )
unauthorized reject eject card
Activity View (Activity Diagram) propose show initial node decision
produce?
activity final node activity
schedule show fork
publicize show
buy scripts and music
hire artists
build sets
rehearse •
join
UML2.0
make costumes
completion transition dress rehearsal
perform
design lighting
An activity shows the flow of control among the computational activities involved in performing a calculation or a workflow. Activities are shown on activity diagrams
4
Koichiro Ochimizu, JAIST
Structured Classifier name: Type
port
connector name1:Type
part
• A structured classifier is a classifier with internal structure. • It contains a set of parts connected by connectors. • An part has a type and a multiplicity within its container. • An connector is a contextual relationship between two parts in a structured classifier. • Structured classifiers may be tightly encapsulated by forcing all interactions between external environment and the internal parts to pass through ports. • A port is an interaction point with well-defined interface. • Messages received by a port are automatically forwarded to the part. • Each port has a set of provides interfaces and required interfaces that define its external interactions. J.Rumbaugh, I.Jacobson, G.Booch,”The Unified Modeling Language Reference Manual, Second Edition” Addison-Wesley 2005
Design View (Internal structure diagram) Box Office sellTickets seller: TicketSeller 1 guide: PerformanceGuide
* db:PerformanceDB [*] • Each port has a set of provides interfaces and required interfaces that define its external interactions. A provided interface specifies the services that a message to the port may request. A required interface specifies the services that a message from the port may require from the external environment. J.Rumbaugh, I.Jacobson, G.Booch,”The Unified Modeling Language Reference Manual, Second Edition” Addison-Wesley 2005
UML2.0
5
Koichiro Ochimizu, JAIST
Design View (component diagram) • A component diagram is a kind of structured classifier, so its Internal structure may be defined on an internal structure diagram. • A component diagram shows the components in a system – that is, the software units from which the application is constructed. A small circle attached to a component or a class is a provided interface- a coherent set of services made available by a component or class. • A small semicircle attached to a component or a class is a required interface – a statement that the component or class needs to obtain services from an element that provides them.
Component Definition applyCharges
required interface
provides interface manage
component definition port
CreditCardAgency
delegation connector
:CreditCardChargers
component use
supplier
: Tickets
purchase
provided interface required interface
status
client groupSales
: ManagerInterface
:TicketSeller
subscriptionSales
IndividualSales
: KioskInterface
customerAccess
UML2.0
: ClerkInterface
clerkAccess
6
Koichiro Ochimizu, JAIST
Component Diagram
CreditCardAgency
applyCharges
port
(is a kind of structured classifier) provided interface on port manage
applyCharges
customerAccess clerkAcsess
purchase provided interface
charge compatible interface
status
purchase required interface
charge
component definition
Tickets
CreditCardCharges
status
manage
groupSales TicketSeller subscriptionSales
ManagerInterface IndividualSales groupSales
subscriptionSales
individualSales
subscriptionSales
KioskInterface
individualSales ClerkInterface clerkAccess
customerAccess
Views of UML1.5 Logical View
Component View Use-Case View Deployment View
Concurrency View
H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.
UML2.0
7
Koichiro Ochimizu, JAIST
UML2.0 Views • Major Area, – View • Diagram – Main Concepts
• structural – static view：class diagram – design view：internal structure (connector, interface, part, port, provided interface, role, required interface), collaboration diagram (connector, collaboration use, role), component diagram (component, dependency, port, provided interface, realization, required interface, subsystem) – use case view：usecase diagram
• dynamic – state machine view：state machine diagram – activity view：activity diagram – interaction view：sequence diagram, communication diagram
• physical – deployment view：deployment diagram
• model management – model management view：package diagram – profile：package diagram
Other Modifications
UML2.0
8
Koichiro Ochimizu, JAIST
Use Case View ( Use case diagram) subject actor Box Office buy tickets buy subscription
relationship Kiosk
Clerk
make charges
Credit card Service
use case survey sales
Supervisor
Class Content Cname
visibility
+attrName:Cname = expression #attrName:Cname -attrName: Cname[*] +opName(p:C1, q:C2): C3 opName(v:Cname = value)
optional named compartment
Responsibility text description
tagName = value
stereotype icon stereotype name class name (italics for abstract) public attribute with initial value protected attribute private attribute with multiplicity many public concrete operation with return type stereotype on subsequent operations abstract operation with default value compartment name compartment list element
stereotype application tagged value
J.Rumbaugh, I.Jacobson, G.Booch,”The Unified Modeling Language Reference Manual, Second Edition” Addison-Wesley 2005
UML2.0
9
Koichiro Ochimizu, JAIST
Static View ( class diagram) Customer name: String phone: String add (name, phone) association
1
owner
*
purchased
attribute static operation rolenames (association end names)
Reservation date:Date
Show name: String
generalization
Individual Reservation
Subscription Series series:integer constraint {xor}
0..1
1 multiplicity
0..1 1
3..6
Ticket available: Boolean sell(c:Customer) exchange
show
performance qualifier seat:String
0..1
1
operations
1..*
Performance date: Date time:TOD
Active Class
Cname
Attr: Atype
Op(par:Type):Rtype
J.Rumbaugh, I.Jacobson, G.Booch,”The Unified Modeling Language Reference Manual, Second Edition” Addison-Wesley 2005
UML2.0
10
Koichiro Ochimizu, JAIST
Relationship Aname association generalization
realization
dependency
J.Rumbaugh, I.Jacobson, G.Booch,”The Unified Modeling Language Reference Manual, Second Edition” Addison-Wesley 2005
Design View (collaboration diagram) • A collaboration is a contextual relationship among a set of objects that work together to fullfill some purpose. • It contains a collection of roles ‒ contextual slots within a generic pattern that can be played by, or bound to, individual objects. TheatreSales
1 kiosk: Kiosk[*]
1 :BoxOffice
*
terminal: SalesTerminal[*]
*
UML2.0
11
Koichiro Ochimizu, JAIST
Interaction View • The interaction view describes sequence of message exchanges among the parts of a system. • An interaction is based on a structured classifier or a collaboration. • A role is a slot that may be filled by objects in a particular us of an interaction. • Interaction view shows the flow of control across many objects and is displayed in two diagrams focused on different aspects: sequence diagrams and communication diagrams. The communication diagram is called a collaboration diagram in UML1.5.
Interaction View ( Sequence Diagram ) sd ticketing kiosk：Kiosk
box of office：Box Office
Credit card service: Credit Card Service
request(count, performance)
loop
lifeline
show availability (seat-list) select(seat) demand payment (cost) insert card (card number)
message charge (card number, cost)
alt
authorized print tickets ( performance ,seats )
unauthorized reject eject card
UML2.0
12
Koichiro Ochimizu, JAIST
Interaction View ( communication diagram) kiosk
role bound to active objects 1: request(count, performance) 4: offer(seat-list)
link
guide: DBCluster
5: buy(seats) 8: comfirm(seats, cost) ticketSeller
connector bound to transitive links
db db: PerformanceDB[*]
3: seat-list:=lock(count) 6: claim(seats)
message
7:unlock(seat-list)
guide 2: db := findDB( performance) connector bound to persistent links performanceGuide
State Machine View (state machine diagram)
subscribe/assign()
timed out/unlock() state
initial state
accept/buy() Available
select/lock()
Sold
Locked
reject/unlock() transition exchange(other)/assign();reset(other) trigger event
UML2.0
event parameter
effect
13
Koichiro Ochimizu, JAIST
Deployment View ( deployment diagram – descriptor level ) CreditCardAgency
Manager
actor
node TicketServer
CreditCardCharges.jar
ManagerInterface.jar
artifact
TicketSeller.jar
TicketDB
1 communication
dependency
Kiosk
1 *
association
*
SalesTerminal
CustomerInterface.c
ClerkInterface.c
KioskInterface
ClerkInterface
Customer Clerk
Deployment View (deployment diagram ‒ instance level)
node instance Main St. kiosk: Kiosk
node name
node type
communication link headquarters: TicketServer
River St. box office: SalesTerminal
Telesales office: SalesTerminal
Valley Mail kiosk: Kiosk
UML2.0
14
Koichiro Ochimizu, JAIST
Model Management View ( package diagram) Planning
package package
Publicity
Scheduling
dependency
Box Office
Customer Records
Ticket Sales
Ticket Records
Accounting
Payroll
Operations
Purchasing
Model Management View ( Profile) • The profile mechanism permits limited changes to UML without modifying the underlying metamodel. • UML includes three main extensibility constructs: constraints, stereotypes, and tagged
Show name: String
{names for one season must be unique}
constraint
stereotype icon TicketDB
stereotype application TicketDB
Scheduling
UML2.0
author = “Frank Martin” Due = Dec.31,2009
tagged values
15
Koichiro Ochimizu, JAIST
Schedule(2/2) • Feb. 25th – 13:00 Outline of UML: Static Modeling (details of class definition) – 14:30 Outline of UML: Dynamic Modeling (state machine, communication diagram, sequence diagram)
• March. 4th – 13:00 Unified Process and Usecase-Driven Approach Case Study: Elevator Control System – 14:30 UML2.0, Contribution of OO in SE
OOT in SE Koichiro Ochimizu Japan Advanced Institute of Science and Technologies School of Information Science
UML2.0
16
Koichiro Ochimizu, JAIST
What is Software Engineering?
Software Development is Challenging but Difficult to Achieve! • Software entities are more complex than most things people build like buildings, automobiles or VLSI. •
UML2.0
Within only 30 years the amount of software in cars went from 0 to more than 10,000,000 lines of code. More than 2000 individual functions are realized or controlled by software in premium cars, today. 50-70% of the development costs of the software/hardware systems are software costs. (Manfred Broy, “Challenges in Automotive Software Engineering”, ICSE2006, pp33-42,2006)
17
Koichiro Ochimizu, JAIST
Why is Software Development so difficult ? (F.Brooks,Jr) 1. Complexity • Computer programs are complex by their nature: a huge amount of parts and their relationships.
2. Conformity • Software can not be created in isolation, but must conform to real-world constraints – pre-existing hardware , third party components, government regulations, legacy data formats, and so on.
Why is Software Development so difficult ? (F.Brooks,Jr) 3. Changeability • Software is always evolving, as the outer environments of software change.
4. Invisibility – Software doesn’t exist in a way that can be represented using geometric models, especially for representing the behavior of software.
UML2.0
18
Koichiro Ochimizu, JAIST
Who makes such a complex software? ？ • Human beings • A group of human being should collaborate to complete the work within specified time and cost with producing high quality product. • Difficult to deal with the following problems caused by human beings – Variation – Uncertainty – Contingency
Software Engineering can support their activities • Software Engineering Technologies – Provide us to control the problems specific to software developments – Support the team to proceed the work smoothly
UML2.0
19
Koichiro Ochimizu, JAIST
Major Topics in Software Engineering • Software Process Model (SPM) – SPM provides for the strategy for software development
• Project Management Technologies (PM) – The application of knowledge, skills, tools and techniques to project activities to meet project requirement. Managing a project includes: identifying requirements; establishing clear and achievable objectives; balancing the competing demands for quality, scope, time and cost (PMBOK).
• Software Development Methodologies (SDM) – SDM provides for the desirable structure of software and define the procedure how to form them – Several examples of structures :easy to verify correctness, easy to encapsulate the change impact, easy to divide the whole work into independent parts, easy to reuse, easy to evolve
• Languages and Environments
History of SPM, SDM, PM • • • • • • • • • • • • • • • • • • •
UML2.0
Waterfall model (early in the 1970s) Development of Programming Methodologies (early in the 1970s) Development of Design Methodologies (late in the 1970s) Development of Requirement Engineering Technologies (late in the 1970s) Beginning of Technical Project Management (late in the 1970s to early in the 1980s) Improvement of Waterfall model (V model ) (middle to late in the 1980s) Iterative Waterfall Model (mini waterfall, spiral) (early in the 1980s) Prototyping (early in the 1980s) Executable specifications and Formal Methods (middle in the 1980s) Process Programming (late in the 1980s) SPI (early in the 1990s) CASE tools (early in the 1990s) Architecture centric Development (middle in the 1990s) Object oriented software development technologies (after 1980s) Maturity of Software Assessment technologies (late in the 1990s) UML (late in the 1990s) Iterative Software Process Model(2000s) Agile (2000s) GORE, IR,COTS (middle of 2000s)
20
Koichiro Ochimizu, JAIST
Change of SPM • Waterfall Model – Custom development, Large-scaled software development
• V Model (System Engineering) – Outsourcing
• Iteration by Mini Waterfall Model or Spiral – Risk Management
• Prototyping – User involvement
• Iterative & Incremental SPM – Reduction of uncertainty by studying the project specific features
Development of PM • Various Measures – Cost-estimation – Detection of risky factors (Software complexity measures, V measure, E measure) – Decision support for terminating test activities (software reliability growth model)
• Measurement – Function Points
• CMM – Maturity Levels and Best Practices
• Software Assessment – Benchmark and Baseline
• PMBOK – Knowledge
UML2.0
21
Koichiro Ochimizu, JAIST
History of SDM What structures and How • Structured Programming – easy to verify correctness a program, easy to divide the whole work into independent parts
• Information Hiding Module – Encapsulation of change impact
• Structured Analysis and Design – Encapsulation of change impact
• Requirement Engineering – Requirements definition
• Executable Specifications and Formal Methods – Verifying and proving some properties of a program, Generation of a program,
• Object-Orientation – easy to encapsulate the change impact, easy to reuse and easy to evolve a program
• Goal Oriented Requirement Engineering, Integrated Requirement Engineering, COTS – Shortening the development time
Principles on Software Engineering 1. Rigor and Formality Rigorous approach enables us to produce more reliable products, control their cost, and increase our confidence in their reliability. Formality is a stronger requirement than rigor; it requires the software process to be driven and evaluated by mathematical laws. 2. Separation of Concerns To deal with different individual aspects of a problem and we can concentrate on each separately. 3. Modularity Kind of Separation of Concerns. A complex system may be divided into simpler pieces called modules, allowing details of each module being handled in isolation. 4. Abstraction Kind of Separation of Concerns; Separation of what from how. The we can identify the important aspects of a phenomenon and ignore its details. 5. Anticipation of Change When likely changes are identified, special care must be taken to proceed in a way that will make future changes easy to apply. 6. Generality Generalizing the problem to make the solution more potential one for being reused. 7. Incrementality A process that proceeds in stepwise fashion, in increments, for risk reduction.
UML2.0
22
Koichiro Ochimizu, JAIST
Advantages of OOT
Rigor and Formality Aspect orientation
cross-cutting concerns
localize
Complexity
Separation of Concerns separation of what from how
complement
primary concerns
Modularity data abstraction
Abstraction
Conformity
Object-Orientation process
(class, inheritance, polymorphism)
Changeability extension to product lines
Invisibility
Anticipation of Change
Feature-Orientation & Product Line Engineering
Generality Incrementality
UP, Agile UML (4+1 views)
SawSanda Aye and K. Ochimizu,” Defining Ontology for Complexity Issues in Software Engineering”, Natnl Conf. of JSSST, 2004.
UML2.0
23
Koichiro Ochimizu, JAIST
Object-Oriented Technology •
Mainly deal with Anticipation of Change – – –
Class for change of data structure Inheritance for variation of properties over the several problem domains Polymorphism for common signature of operations with different implementations
Aspect Oriented Programming •
UML2.0
Aspect oriented programming complement the defects of object oriented programming. We can not encapsulate all of the functionality in objects (primary concerns). For an example, Codes related to logging spread over related objects (cross cutting concerns). Aspect can define a cross cutting concerns separately.
24
Koichiro Ochimizu, JAIST
Feature Modeling and Product Line Engineering •
New technology for Anticipation of Change –
UML2.0
Common features and Product Specific features are arranged by Variation Point Analysis Techniques
25
