New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Topics in Software Development

by: Dorothy Bahringer DVM

Topics in Software Development CS 5382

Marketplace > University of Texas at El Paso > ComputerScienence > CS 5382 > Topics in Software Development
Dorothy Bahringer DVM
GPA 3.85

Yoonsik Cheon

Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Yoonsik Cheon
Class Notes
25 ?




Popular in Course

Popular in ComputerScienence

This 79 page Class Notes was uploaded by Dorothy Bahringer DVM on Thursday October 29, 2015. The Class Notes belongs to CS 5382 at University of Texas at El Paso taught by Yoonsik Cheon in Fall. Since its upload, it has received 12 views. For similar materials see /class/231283/cs-5382-university-of-texas-at-el-paso in ComputerScienence at University of Texas at El Paso.

Similar to CS 5382 at UTEP

Popular in ComputerScienence


Reviews for Topics in Software Development


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 10/29/15
An Introduction to UML Profiles Lidia Fuentes Ferndndez and Antonio Vallecillo Moreno 1 Introduction 13 0 Model description of a system written in a well defined language 0 Object Management Group OMG defines several modeling languages among which UML is the one most Widely accepted and used 0 UML Visual language for specifying constructing and documenting the artifacts of systems 1 Introduction 23 0 a general purpose modeling language that can be applied to all application domains 0 Situations however in which a general language may not be appropriate for modeling applications of some specific domains 0 OMG defines two possible approaches for defining domain specific languages 1 Introduction 33 0 First definition of a new language using the mechanisms provided by OMG for defining object based Visual languages 0 Second UML provides a set of extension mechanisms for specializing its elements allowing customized extensions of UML for particular application domains 2 OMG S Metamodel Architecture 12 0 Metamodeling mechanism used to define graphical languages 0 OMG defines a four layered architecture 0 Layer M0 Instances 0 Layer M1 The model of the system 2 OMG s Metamodel Architecture 22 0 Layer M2 The model of the model the metamodel 0 Layer M3 The model of M2 the metametamodel 0 The modeling language defined for describing the M3 elements is called MOF Meta Object Facility 3 UML Profiles 14 0 UML can easily be customized by using a set of extension mechanisms that UML itself provides 0 UML Profiles defines a set of UML artifacts that allows the specification of an MOF model 0 UML Profile package is included in UML 20 3 UML Profiles 24 0 Why customize a metamodel 0 To add semantics left unspecified in the metamodel such as how to deal with priority when receiving signals in a state machine 0 To add semantics that do not eXist in the metamodel such as defining a timer clock or continuous time 0 To add constraints that restrict the way you can use the metamodel and its constructs 3 UML Profiles 24 0 UML Profiles are defined in terms of three basic mechanisms 0 Stereotypes is defined by a name and by the set of metamodel elements it can be attached to 0 Constraints can be associated to stereotypes imposing restrictions on elements 0 Tagged values is an additional meta attributes that is attached to a Stereotype It has a name and a type 3 UML Profiles 44 0 Two StereotypesWeighed and Colored 0 Classes and associations can be Colored 0 Notation for extension is an arrow pointing from a stereatype to the extended Class profile Wei ghtsAndCol ours meiaclass Class stereotype Coiou red colour Colour metaclass stereotype Association Weighed weight integer enumeration Colour green yellow red blue Figure 1 Example of UML Profilei 4 Definition of UM L Profiles 0 Brief guidelines for the definition and use of UML Profiles 0 1 First define the set of elements that will comprise the system and the relationships between them 0 2 Once you have your metamodel you are ready to define the UML Profile 0 3 Define the attributes that appear in the metamodel as tagged values 5 MDA and UML Profiles 12 0 MDA Model Driven Architecture initiative that supports the definition of models as first class elements for the design and implementation of systems 0 MDA defines three conceptual levels 0 Computational Independent ModelCIM 0 Platform Independent ModelPIM 0 Platform Specific ModelPSM 5 MDA and UML Profiles 22 0 MDA advantage It allows software engineers to define automatic transformations from PIMs to PSMs 0 PIM PSMl Transformation rules Automated System 0 UML Profiles can be used to describe the platform model and the transformation rules between models 0 If UML Profiles is used to specify the model of specific platforms it will guarantee that the derived models will be consistent with UML On the Precise Meaning of OCL Constraints Rolf Hennicker Heinrich Hussmann and Michel Bidoit Outline gt Introduction gt Invariants gt Checkpoints gt Pre and Post conditions gt Splitting of Constraints gt Inheritance of Constraints gt Abstract Semantics gt Conclusion X 1 Introduction gt OCL is a part of the UML standard gt One key application is to provide precise information in the definition of standards gt OCL can be used for precise specification of constraints on the model level gt OCL has a strong potential to improve software quality and software correctness amp 1 Introduction gt The rules expressed in OCL can be used by advanced support tools for instance in the following ways 0 To check the validity of constraints at system runtime 0 To experiment with symbolic representations of possible object configurations as a means to check consistency and correctness of the rule set 0 To statically prove that the code never violates the constraints 1 Introduction List of issues which need to be clarified gt At which point in the execution of the program is the validity of an invariant enforced gt What is the meanin of a precondition attached to an operation wit out a post condition gt What happens if the precondition of an operation is violated gt In how far do the constraints of a su er class have an impact on the constraints 0 its subclasses gt Is it possible to specify potentially non terminatin operations with OCL What is the meaning 0 a constraint in non termination case 2 Invariants gt An invariant is a very declarative way to specify precise constraints for a class diagram It defines additional rules which have to be obeyed in any object configuration object diagram which is constructed for the actual class diagram amp 2 Invariants iAccount Attributes private int bal p riVat e at untN i SavingsAccoum CheckingAccount Aztribmes Aftribuies private int interestRate private intlimit Operations geerations 39 C m d Withdraw 39i context CheckingAccount inv bal gt limit 21 Checkpoints gt Book definition 0 An invariant is a constraint that states a condition that must always be met by all instances of the class type or interface gt More recent definition 0 Invariants must be true upon completion of a constructor and every public method but not necessarily during the execution of methods gt A property named volatile with a Boolean value such that the tagged value volatileztrue can be attached to a non public operation 22 Proposed Informal Semantics gt Informal semantics of invariants An invariant is a predicate on object configurations Any constructor deliver an object configuration in which the invariant is valid Moreover if a public operation or a non public operation with property volatile false is applied to an object configuration where the invariant holds and delivers a defined result then the invariant also holds for the resulting object configuration amp 3 Pre and post conditions gt Pre and post conditions specify operations in a descriptive non operational way by comparing the states before and after the execution of the operation amp 3J Unde nedness gt Exception undefinedness The undefined result can just be considered as a special value different from all defined results gt Non termination undefinedness The program goes into an infinite loop and refuses to deliver a result amp 3J Unde nedness OCL The language was explicitly designed in such a way that the evaluation of an OCL query on a snapshot always terminates OCL uses a three valued propositional logic AgtB AvB X 32 Semantic Variations context Accountdepositninteger pre ngt 0 post bal balpre n The central idea of a prepost condition is a contract between the operation and its context amp 32 Semantic Variations gt Partial Correctness c If the precondition PRE is valid for a given snapshot o of the system and if additionally the application of op to 0 leads to a defined result then the post condition POST is valid for the resulting system state x 32 Semantic Variations gt Total Correctness c If the precondition PRE is valid for a given snapshot o of the system then the application of op to 0 leads to a defined result and the post condition POST is valid for the resulting system state X 32 Semantic Variations gt What s the difference between the two semantic variations gt Example 0 Lets assume we have an object a of Account with balance O 0 We apply the operation deposit5 to a gt Now we apply the operation deposit 5 to a o Admitted implementations are among others adeposit 5 may raise an exception adeposit 5 may go into an infinite loop adeposit 5 mayjust leave the balance untouched adeposit 5 may subtract 5 units from the balance adeposit 5 may subtract an arbitrary number of units from the balance 32 Semantic Variations gt The UML standard says that a precondition must hold for the invocation of an operation and that a post condition must hold after the invocation of the operation The preconditions is not the operation under which the operation is called the post conditions is the condition under which the operation guarantees that the post condition will be true gt If the precondition of an operation has not held at invocation time the result of the invocation is unde ned amp V 32 Semantic Variations gt Partial Exception Correctness An operation opx is called partially exception correct with respect to a pair of a precondition PRE and a post condition POST if the following two properties hold 0 The operation op is partially correct with respect to PRE and POST o If the application of op to 0 leads to a defined result then the precondition PRE has held at invocation time A 32 Semantic Variations gt Total Exception Correctness An operation opx is called totally exception correct with respect to a pair of a precondition PRE and a post condition POST if the following two properties hold 0 The operation op is totally correct with respect to PRE and POST o The application of op to 0 leads to a defined result if and only if the precondition PRE has held at invocation time A 4 Splitting of Constraints gt Splitting of constraints means to specify several pre and post condition constraints to the same operation context CheckingAccountwithdrawninteger pre ngt0 post true context CheckingAccountwithdrawninteger pre bal n gt2 limit post bal balpre n context CheckingAccountwithdrawninteger pre n gt2 O and bal n gt2 limit post bal balpre n 41 Splitting and Partial Correctness gt Transformation Rule for Partial Correctness context CopxT context CopxT Pre PREl postPOSTl prePRE2 postPOSTZ context CopxT pretrue postPREipre implies POSTl and PRE2pre implies POST2 A 42 Splitting and Total Correctness gt Transformation Rule for Total Correctness context CopxT context CopxT pre PREl post POSTl pre PRE2 post POST2 context CopxT prePREl or PRE2 postPRElpre implies POSTl and PRE2pre implies POST2 43 Splitting and Partial Exception Correctness gt Transformation Rule or Partial Exception Correctness context CopxT context CopxT pre PREl post POSTl pre PRE2 post POST2 context CopxT prePREl and PRE2 postPOSTi and POST2 A 44 Splitting and Total Exception Correctness gt In this case the combination of two OCL constraints only works if the two preconditions are equivalent A 5 Inheritance of Constraints gt Liskov s Substitution Principle Wherever an instance of a class is expected one can always substitute an instance of any of its subclasses There are two possible approaches to deal with this requirement 0 One possibility is to put the responsibility on the system engineer who has to guarantee that the constraints used in hisher model satisfy the substitution principle 0 To consider all constraints imposed on super classes as implicit constraints for all of its subclasses 5 Inheritance of Constraints gt Example Let A be a super class of a class B context A invNV context B invNVZ context AopxT context BopxT pre PRE pre PRE2 post POST post POST2 The complete set of explicit constraints for B is computed as follows context B invNV context B invNV2 context BopxT context BopxT pre PRE pre PRE2 post POST post POST2 According to the transformation rules we have context B inv INV and NV2 context BopxT pre PRE and PRE2 post POST and POST2 6 Abstract Semantics gt Provide and abstract semantics based on set theory which is as simple as possible to capture our intuition about the precise meaning of OCL constraints gt Q denotes a UML class diagram and if C is a class occurring in Q we write C E Q X 6 Object Configurations V StateQ set of possible object configurations snapshots of Q gt For each C E Q dC countany infinite set of potential object identifiers of type C gt For each C E Q and o E stateQ Instances 90 finite subset of dC consisting of the existing objects of type C in the state I x 62 Interpretation of Operations gt An interpretation of op is a partial state transformation function CopxTStateQ x dC X dT gt StateQ where StateQ x dC X dT o i j o E StateD i E dCj E dT such that i E nstancesC o and E nstancesT 0 A 63 Semantics of Class iagrams gt Let OpnsD set of all operations occurring in class of C Then OpnsD gt StateTransFunct Where StateTransFunc denotes the set of partial state transformation functions on StateC The semantic of a class diagram Q is given by the pair SemQ State OpnsQ gtStateTransFunct 64 Satisfaction of OCL constraints Definition 1 Let IOpnsD gt StateTransFunct be an interpretation function I Satisfaction wrt partial correctness I Be context C opX T pre PRE post POST if for all oij E StateC X l 10 gtlt llT the following holds PREMJ true and lopo iw is de ned thon POSTUJtOp0141111 true when 1sclf i Mir j I A 64 Satisfaction of OCL constraints Satisfaction wrt total correctness I Iztc context C opx T pre PRE post POST if for all a ij E StateC gtlt IclC7 gtlt IlT the following holds if PREGJ J true then Iopoglj de ned and PCtS39Tg10paZ j11 true where U is as above Satisfaction wrt partial emception correctness I Izpec context C opx T pre PRE post PUST if for all 0 id 6 StateC gtlt IdC gtlt IlT the following holds Iop0 ij is de ned then PHEmLKI true and POSVTo IOPad ijrI true where o is as above Satisfaction wrt total emception correctness I Itec context C opx T pre PRE post POST if for all 039 lj E StatelC gtlt IdC gtlt IlT the following holds I 010 3923 j is de ned if and only PREGr39LLI true and in this case POSTGI Opxg i j1 I true where U is as above 64 Satisfaction of OCL constraints Definition 2 Let IOpnsD gt StateTransFunct be an interpretation function 1 Satisfaction of invariants I i context C inv INV if I izm contextC op pre INV post INV forquot all public operations and all non public operations op of the class C which have the property volatile false Satisfaction of a set of constraints Let Cons be a set of OCL constvaints I 0 Cons if I inv for each invariant constraint inv E Cons and I i6 prepost forquot each pr39e postcondition constraint prepost E Cons where C E C tapec tee 65 Semantics of Class iagrams with Constraints S39eir7zcC Cons SiamC I OpnsC gt SfateT39I39ansFtmct I ic Caiizpl00ns Where C E 36 ta p60 tee A Towards General Purpose High Level Software Languages Anneke Kleppe PreSenter lairne Nava A Hartman and D Kreische Eds ECMDAFA 2005 LNCS 3748 pp 220 238 2005 SpringerVerlag Berlin Heidelberg 2005 1 Introduction 1 Introduction How the Analyst How the Prugrammer designed it wrate 39rt 1 Introduction 0 UML Too little expressive power to be able to specify a system completely Level of abstraction of PLs same as 10 15 years ago 0 Transformation tools do part ofthe job developer still has to do both modeling and programming 1ntroduction MDA claims the following benefits portability interoperability and productivity Hard to realize In reality only MDA benefit is raising the level of abstraction 1 Introduction 0 Need general purpose high level language to get MDA adopted 0 Nice to include concepts UML OCL design patterns aspect orientation Developer can focus on the problem at hand while supporting tools transformation tools take care ofthe details 1 Introduction UML design patterns aspect oriented languages OCL Offer new high level concepts Associations patterns aspects collection iterators Aim incorporate these concepts to a single language very powerful Add to the developer s ability to create complex systems that customers demand 1 Introduction Dream Language Alan A LANguage Aims to bring power to software developer and realize one of the claimed benefits of MDA productivity Can used to develop software at maturity level 4 or 5 Level4 modelprogram is a consistent set of text andor diagrams with a very specific and well defined meaning Level5 the programmodel contains enough info that it can be generated completely 2 Rationale Why create this new type of language Explore the various parts of the term high level general purpose software language 21 Software Language Traditionally modeling and programming are viewed to be different Table 1 Peweived diffciences between modeling mid proglmuming languages Gap between design phase and implementation phase supposedly bridged by object orientation Expressive power of modeling languages stops somewhere in the line of the development process 21 Software Language If the language offers high level constructs call it modeling language If textual of executable programming language What should Alan be called Bridge the divide combines both software language What should the end product be called Model OR Program Precise model and executable call the end result a program 22 General Purpose Language Why a general purpose language Can a general purpose language be used instead of domain specific languages Domain specific languages Developed by domain experts themselves If each expert defines hisher own language then none of the experts would be able to understand each others language even in the same domain Line between domain specific and general blurred GUI regarded as part of separate domain contains buttons and windows On the other hand GUI part of almost every software system 23 High Level Languages Why a highlevel language Productivity of a software developer is constant in terms of the number of statements heshe produces per time unit Programming productivity increased as much as five times when a suitable high level language is used High level language increased productivity OCL Java 23 High Level Languages parmers del iveredsarvices forAll polntsEarned 0 Iterator it Collect5iterator Whlle t 1thasNeXt Service i servi e Servlce itnext 1iserv1cegetPomtsEarn d 0 J retu n false prlvate List collect5 Li C Sernce resul new ArrayListl Servlce It rater e thlsgetPartnersUiteratoro7 hile ithasNex ProgramPartner ijrogramparmer P ogramParcuery 1tnextHr resul addA ljrogramyarmer getDeliveredServlces return result 1 23 High Level Languages OCL can increase productivity largely 1 line OCL code 17 lines Java code Why include OCL UML offers a high level of abstraction however it does not have enough expressive power to create a system UML has no concrete syntax 24 Additional Reasons Important aspect of MDA Models shall be transformed automatically Manual manipulation shall be an exception Just as manual manipulation of compiler generated byte code is an exception Transformation tools are the compilers of the next decade Consequence Language of the source model must be as powerful as language of target model or transformation tools must add the missing info Do both Gap will no be magically filled Another reason Design patterns 3 Requirements on General Purpose High Level Software Languages Combine positive aspects of both modeling and programming languages Cross out negative aspects of Modeling languages 39I whl 9 l t 39I39 u Hiuhl 39I In early stages of development model may be imprecise at later stages it should be precise and executable clear semantics Visual syntax positive not all details can be shown visually therefore have a textual alternative for program details Several views from more to less detailed zoom Don t forget modeling language should provide more abstract constructs 9 N9 P PPUN 3 Requirements Summary Concrete syntax Clear semantics Program complete functional description of the system Imprecision at early stages allowed Precise at most stages Executable Different views overview more detailed zoom More abstract constructs than current day programming languages 4 ALAN A Software Language Goal is to gather well known concepts and make them usable for a developer Not create new software development concepts Sources UML two directional association OCL collection operations powerful design patterns programming languages Java C Python Language fully implemented Alan IDE and compiler available as an Eclipse plug in reserved for comparisons for assignments 41 UML Constructs in Alan Alan borrowed syntax of the UML class diagram for the Alan visual syntax and UML constructs 411 Associations Associations always twodirectional uni directional association is simply an attribute Adam Eve example ABACUS rules for associations Awareness Both objects are aware of the fact that the link exists Boolean existence If the objects agree to end the link it is dissolved at both ends Agreement Both objects have to agree with the link Cascaded deletion If one of the objects is deleted the link is dissolved as well USe of rolenames An object may refer to its partner using the role name provided with the association 411 Associations class Man ublic woman wife otherside husband public EagWoman girlfrlend5l10 otherside boyfriends class Woman public Man husband otherslde wife public EagMan boyfriends otherside glrlfriends Fig I An Alan assodnlion example 412 Enumerations May not seem like a powerful language construct but in practice they come in very handy enum my39jolmr red white blue 413 Composite or Aggregate Objects Part of UML but not part of any programming language Alan provides deletion semantics when the container is deleted so are its parts class Elke public part SetWheel wheels2r 2 Frame frame public pa l class wheel public Dar Tlre tire Fig 2 An Alan composile object example 413 Composite or Aggregate Objects Composite object may seem like a more specialized version of association Enables to specify the Visitor pattern vstlCancmeEkmzm 0mm Enables delegation Bike myBike new Bike myBiketurn delegates the call to the Wheel class 42 OCL Constructs in Alan OCL Constructs incorporated in Alan completely Primitive types same as UMLOCL Integer Real String and Boolean Abstract nature of Alan No need to differentiate between float and double char and String Collection types and iterators Set Ordered Set Sequence and Bag Select collect exists isUnique Investigating SortedSet and SortedBag 423 Invariants and Pre and Post Conditions Alan supports OCL Invariants and pre and postconditions completely Integrated In the class definition e 7 1 d 1ned otherside husband g1r1friends110 othersida boyfriends ubnc Integer age o med O lt 16 implies Wlfe oclUndefined m gt 14 post moneyEarned moneyEamedapre 100 and nocassertg1r1friendsr mult notassert takes as parameters the names of invariants that should not be c ec e 424 Derivation Rules Derivation rules can be expressed in Alan class Bike public Dart sequencemheel wheels public derived Wheel frontwheel wheelsrgtfirsti public derived Real epe frontwheelsize frontwheelrevolutlonsPerSec 43 Design Patterns in Alan Only most popular patterns incorporated into Alan Visitor Singleton Observer List expected to grow in the future 44 Programming Language Constructs in Alan Most constructs present in programming languages are also present in Alan Generic types visibility and set and get operations loops Some discarded because of low level of abstraction Loops OCL iterators available for many of the cases However still need loop construct for some cases forll somelnt whilelaame ooleani Conclusions and Future Work This paper describes an early version of Alan Future work Inclusion of constructs from aspect oriented languages the support for association classes and support for other patterns What remains is a check to see whether the requirements we defined in section 3 are met by Alan Table 3 The reallsmlon of he i39equimnems by Alan Conclusions and Future Work Alan s merits lie in the fact that it incorporates higher level concepts and makes them available to the programmer in a way he or she is likely to understand Please note that the creation of general purpose high level software languages will not make informal models obsolete it will just raise the level of abstraction This is a normal phenomenon in the history of any technology or culture


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Anthony Lee UC Santa Barbara

"I bought an awesome study guide, which helped me get an A in my Math 34B class this quarter!"

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.