Object-Oriented Analysis & Design with UMLHERY HERYANTOhery@likmi.ac.id, h3ry.heryanto@gmail.comOeriewUML has become the de facto standard for modeling object-oriented software. UML has been adopted by companies throughout the world, and today more than 50 commercial and academic modeling tools support software and business modeling using UML.UML enables system developers to specify, visualie, and document models in a manner that supports scalability, security, and robust e!ecution. "ecause UML modeling raises the level of abstraction throughout the analysis and design process, it is easier to identify patterns of behavior and thus de#ne opportunities for refactoring and reuse.Objecties$. %eaching the basic concepts and principles of &bject &rientation including &bject &riented 'nalysis and (esign.). *ntroducing the +ynta!, +emantics and ,ragmatics of the Uni#ed Modeling Language.-. +howing how re.uirements can be described informally and how they are modeled using Use /ase (iagrams.0. %eaching how the structural and behavioral aspects of a system can be analyed, speci#ed and designed using /lass, +e.uence and 'ctivity (iagrams.UML M!dellingUsecase Diagra"Usecase Diagra" c!nt# Actor$ ' role played by a person, system, device, or even an enterprise, that has a sta1e in the successful operation of the system. Use case$ *denti#es a 1ey behavior of the system. 2ithout this behavior, the system will not ful#ll the actor3s re.uirements. 4ach use case e!presses a goal that the system must achieve and5or a result that it must produce. Association$ *denti#es an interaction between actors and use cases. 4ach association becomes a dialog that should be e!plained in a use case narrative. 4ach narrative in turn provides a set of scenarios that can help in the development of test cases when evaluating the analysis, design, and implementation artifacts of the use case and the association.Usecase Diagra" c!nt# Include relationship$ *denti#es a reusable use case that is unconditionally incorporated into the e!ecution of another use case. 6esponsibility for the decision about when and why to use the included use case lies with the calling use case. Extend redlationship: *denti#es a reusable use case that conditionally interrupts the e!ecution of another use case to augment its functionality. %he responsibility for deciding when the e!tending use case should be used lies with the e!tending use case. Generalization: *denti#es an inheritance relationship between actors or between use cases.M!deling Act!rs*n UML, the term actor refers to a type of user. Users, in the classic sense, are people who use the system. "ut users may also be other systems, devices, or even businesses that trade information. *n Use /ase diagrams, people, systems, devices, and even enterprises are all referred to as actors. %he icons to model them may vary, but the concept remains the sameM!deling Act!rs c!nt#'ny icon may be used to replace these. ,icture below o7ers some alternatives. ' company logo might represent an enterprise. ' cartoon image might represent a device. ' graphic may be used to represent a system. &ften, using alternative icons in a modeling tool is as simple as importing the graphics to a speci#c directory.%ncl&de Relati!nshi'%o use the (include) relationship, the use cases must conform to two constraints8 %he calling use case may only depend on the result from the called use case. *t can have no 1nowledge of the internal structure of the use case. %he calling use case must always require the e!ecution of the called use case. %he use of the called use case is unconditional.E*tend Relati!nshi'%he extend relationship says that one use case might augment the behavior of another use case. %he e!tension use case provides a discrete behavior that might need to insert itself into the base use case. %he arrow is drawn from the e!tension to the e!ecuting use case. (rawing the arrow with the base at the e!tension use case indicates that the e!tension, not the e!ecuting use case, decides whether to impose itself on the e!ecuting use case. %he e!ecuting use case is unaware of the e!tension.Use +ase NarratieUse +ase Narratie ,!r -elect.er,!r"ance Ele"ent Descri'ti!nUse /ase 9ame +elect,erformanceUse /ase 9umber $)'uthor :ane 'nalyst and :oe /lientLast Updated 'pril $, )00-'ssumptions %he actor has the appropriate authority to use this feature.,reconditions 9one.Use /ase *nitiation %his use case starts on demand.Use /ase (ialog %he user should be given a default set of information about the shows scheduled within the ne!t )0 days. %he user should also be provided with all the events currently scheduled at the venue.2hen the user selects an event, the system should provide the set of shows scheduled for that event ;the event display should remain unchangedUse +ase -cenari!s-&""aryUse case diagrams, together with use case narratives and scenarios, de#ne the goals of a system, or other classi#er, such as an enterprise, subsystem, or component. %he purpose of the use case approach is to focus the development e7ort on the essential objectives of the system without getting lost in, or driven by, particular implementations or practices.%he elements of a Use /ase diagram include8 %he Use Case diagram is complemented by the use case narrative and use case scenarios. Actors de#ne entities outside the system that will use the system in some way. Associations indicate which actors will interact with features ;use cases< of the system. include and extend relationships describe the nature of the interactions between use cases. Generalization de#nes inheritance relationships between use cases or between actors.%he goal of the Use /ase diagram is to de#ne the e!pectations of the e!ternal actors. %hose actors may be people, systems, or devices that need to interact with the system.E*ercisesActiity Diagra" - Oeriew %he 'ctivity diagram is often seen as part of the functional view of a system because it describes logical processes, or functions. 4ach process describes a se.uence of tas1s and the decisions that govern when and how they are performed. %here are at least three places in a model where an 'ctivity diagram provides valuable insight8 Modeling wor1=ow (escribing use cases +pecifying operations 'n 'ctivity diagram for one use case e!plains how the actor interacts with the system to accomplish the goal of the use case, including rules, information e!changed, decisions made, and wor1 products created.Actiity Diagra" N!tati!n MODEL%N/ A+T%0%T%E- AND A+T%ON-'ctivities and actions are the two fundamental units of behavior in an 'ctivity diagram. 'n activity is the highest-level unit of behavior in an 'ctivity diagram. 'n activity consists of a set of ActivityNodes and ActivityEdges ;connectors