Schedule(2/2) March. 4th 13:00 Unified Process and Usecase-Driven Approach Case Study: Elevator Control System 14:30 UML2.0, Contribution of OO in SE

Transcription

1 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, Koichiro Ochimizu Japan Advanced Institute of Science and technologies School of Information Science UML2.0 1

2 MDA and CBSD MDA ( Model Driven Architecture) CBSD (Component Based Software Development) MDA(1/2) M3 MetaMetaModel MOF (Meta Object Facility) M2 MetaModel UML Class, UML Association, CWM Table M1 Model Class Customer, Class Account M0 objects and data Customer Jane Smith, Account 2989 UML2.0 2

3 MDA(2/2) is-described-by Meta Language is-described-by Mapping Language 1 Definition Language 2 is-described-by PIM (Platform Independent Model) Translator is-used-by PIM (Platform Specific Model) is-described-by 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

4 Structured Control constructs in a Sequence Diagram sd ticketing kiosk Kiosk request(count, performance) box of office Box Office Credit card service: Credit Card Service loop show availability (seat-list) select(seat) lifeline demand payment (cost) insert card (card number) message charge (card number, cost) alt print tickets ( performance,seats ) authorized reject unauthorized eject card Activity View (Activity Diagram) initial node propose show produce? decision activity schedule show activity final node fork publicize show buy scripts and music hire artists build sets design lighting make costumes rehearse perform dress rehearsal join completion transition 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 UML2.0 4

5 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) selltickets Box Office seller: TicketSeller guide: PerformanceGuide 1 * 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

6 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. applycharges Component Definition required interface component definition provides interface manage port delegation connector CreditCardAgency :CreditCardChargers component use : Tickets provided interface required interface supplier client :TicketSeller purchase groupsales status : ManagerInterface subscriptionsales IndividualSales : KioskInterface : ClerkInterface customeraccess clerkaccess UML2.0 6

7 Component Diagram (is a kind of structured classifier) applycharges applycharges CreditCardAgency port provided interface on port manage customeraccess clerkacsess compatible interface CreditCardCharges purchase provided interface charge purchase charge required interface groupsales TicketSeller Tickets status manage ManagerInterface component definition status subscriptionsales IndividualSales subscriptionsales individualsales subscriptionsales individualsales groupsales KioskInterface ClerkInterface customeraccess clerkaccess Views of UML1.5 Component View Deployment View Use-Case View Logical View Concurrency View H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. UML2.0 7

8 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

9 Use Case View ( Use case diagram) subject Box Office actor Kiosk buy tickets <<include>> relationship make charges <<include>> buy subscription Clerk Credit card Service survey sales use case Supervisor visibility optional named compartment Class Content <<stereotypename>> Cname +attrname:cname = expression #attrname:cname -attrname: Cname[*] +opname(p:c1, q:c2): C3 <<constructor>> opname(v:cname = value) Responsibility text description <<stereotypename>> tagname = value stereotype application tagged 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 J.Rumbaugh, I.Jacobson, G.Booch, The Unified Modeling Language Reference Manual, Second Edition Addison-Wesley 2005 UML2.0 9

10 Static View ( class diagram) generalization Customer name: String phone: String add (name, phone) 1 owner association * purchased Reservation date:date attribute static operation rolenames (association end names) Show name: String Subscription Series series:integer Individual Reservation 0..1 constraint {xor} 0..1 multiplicity 1 show 3..6 Ticket available: Boolean sell(c:customer) exchange 1 qualifier seat:string operations performance 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

11 Relationship Aname association generalization realization <<kind>> 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 1 * kiosk: Kiosk[*] :BoxOffice terminal: SalesTerminal[*] * UML2.0 11

12 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. sd ticketing loop kiosk Kiosk Interaction View ( Sequence Diagram ) request(count, performance) show availability (seat-list) select(seat) box of office Box Office Credit card service: Credit Card Service lifeline demand payment (cost) insert card (card number) message charge (card number, cost) alt print tickets ( performance,seats ) authorized reject eject card unauthorized UML2.0 12

13 Interaction View ( communication diagram) kiosk role bound to active objects link 1: request(count, performance) 4: offer(seat-list) 5: buy(seats) 8: comfirm(seats, cost) guide: DBCluster connector bound to transitive links ticketseller 3: seat-list:=lock(count) 6: claim(seats) message 7:unlock(seat-list) 2: db := finddb( performance) db db: PerformanceDB[*] guide performanceguide connector bound to persistent links State Machine View (state machine diagram) subscribe/assign() timed out/unlock() state initial state accept/buy() select/lock() Available Locked Sold reject/unlock() transition exchange(other)/assign();reset(other) trigger event event parameter effect UML2.0 13

14 node Deployment View ( deployment diagram descriptor level ) CreditCardAgency actor Manager TicketServer <<artifact>> CreditCardCharges.jar <<artifact>> TicketSeller.jar <<artifact>> ManagerInterface.jar <<artifact>> TicketDB artifact dependency 1 1 communication * association * Kiosk <<artifact>> CustomerInterface.c <<artifact>> ClerkInterface.c SalesTerminal <<manifest>> <<manifest>> KioskInterface Customer Clerk ClerkInterface Deployment View (deployment diagram instance level) Main St. kiosk: Kiosk communication link node instance node name node type headquarters: TicketServer River St. box office: SalesTerminal Telesales office: SalesTerminal Valley Mail kiosk: Kiosk UML2.0 14

15 Model Management View ( package diagram) Planning package package Publicity Scheduling Box Office dependency Customer Records Ticket Sales Ticket Records Operations Purchasing Accounting Payroll 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 <<database>> TicketDB stereotype application TicketDB stereotype icon <<database>> Scheduling <<authorship>> author = Frank Martin Due = Dec.31,2009 tagged values UML2.0 15

16 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

17 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. 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 % of the development costs of the software/hardware systems are software costs. (Manfred Broy, Challenges in Automotive Software Engineering, ICSE2006, pp33-42,2006) UML2.0 17

18 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

19 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

20 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 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) UML2.0 20

21 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

22 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

23 Advantages of OOT localize Complexity Conformity Changeability Invisibility Rigor and Formality Separation of Concerns cross-cutting concerns primary concerns separation of what Modularity from how data abstraction Abstraction Anticipation of Change Generality Aspect orientation complement Object-Orientation extension to product lines Feature-Orientation & Product Line Engineering Incrementality UP, Agile UML (4+1 views) SawSanda Aye and K. Ochimizu, Defining Ontology for Complexity Issues in Software Engineering, Natnl Conf. of JSSST, UML2.0 23

24 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 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. UML2.0 24

25 Feature Modeling and Product Line Engineering New technology for Anticipation of Change Common features and Product Specific features are arranged by Variation Point Analysis Techniques UML2.0 25