Software Engineering from a

Transcription

1 Software Engineering from a modeling perspective Robert B. France Dept. of Computer Science Colorado State University USA france@cs.colostate.edu

2 Softwaredevelopment problems Little or no prior planning and analysis! Robert B. France 2

3 Quality assurance Business value concerns Security, safety, concerns robustness concerns Regulatory concerns Why is software development difficult? Developers need to balance multiple, interdependent design concerns such as availability, performance, survivability, fault tolerance, and security. Robert B. France 3

4 Problem solving view of SE SE is the discipline of resolving problems with software solutions. (B.Blum). Blum). Focus is on solving complex problems. Problem solving involves analyzing problems and synthesizing solutions. Analysis of complex problems involves decomposing the problem into subproblems that can be understood on their own Solutions for the subproblems can be developed in a relatively independent manner and then composed (synthesized) to create a complete solution. Robert B. France 4

5 Complexity Fred Brooks: The Mythical Man Month Essential complexity: inherent in the problem and cannot be eliminated by technological or methodological means E.g., making airplanes fly Accidental complexity: unnecessary difficulty introduced by a technology or method E.g., building construction without using power tools or, translating designs (models) into programs without the help of computers Robert B. France 5

6 The software problem implementation gap A problem-implementation gap exists when software is implemented using abstractions that are different than those used to conceptualize the problem when the gap is wide significant effort is required to implement solutions bridging a wide gap using manual techniques introduces significant accidental complexities Robert B. France 6

7 If software developers built pyramids Robert B. France 7

8 Model Driven Engineering (MDE) is concerned with ih reducing accidental complexities associated with bridging wide problem implementation gaps through use of technologies that support systematic transformation of abstractions to software implementations MDE is concerned with developing software to support the work of software developers Robert B. France 8

9 Why modeling techniques? Software development is a modeling activity Programmers build and evolve (mentallyheld) models of problems and solutions as they develop code Programmers express solutions in terms of abstractions provided d by a programming language How can we better leverage modeling techniques? Robert B. France 9

10 What is a model? A description of an aspect of a softwarebased system that may or may not yet exist. A model is created to serve one or more purposes. p Robert B. France 10

11 Engineering models Engineering model: A reduced representation of some system that highlights the properties of interest from a given viewpoint Modeled system Functional Model We don t see everything at once We use a representation (notation) that is easily understood for the purpose on hand

12 Key SE principles p supported by MDE Formality and rigor Separation of concerns Incrementality Robert B. France Intro-12

13 Why is modeling difficult? Or why modeling seems to add accidental complexity Tools Many existing modeling tools do introduce significant accidental complexity Dissatisfaction with current toolset is sometimes the basis for dismissing MDE Education is the key (not tools!) Learning a modeling language is not enough Software developers need to develop ability to identify the right abstractions Robert B. France 13

14 Why model? Modeling should be purpose driven Using models as a means to explore a problem or solution Models as sketches (informal) Models as analyzable artifacts (formal) Using models to communicate aspects of a problem or solution Models as documentation artifacts Using models to generate implementations Robert B. France 14

15 Modeling challenges How do we decompose a problem or solution? What information should be in a model and at what level of abstraction should it be expressed? How can we determine if the abstractions we use are fit for purpose? There is a need for software engineering methodologies that explicitly address these and other modeling issues Robert B. France 15

16 Modeling aptitude Hypothesis: A good modeler is a good programmer; a good programmer is not always a good modeler Modeling requires programming and abstraction skills Abstraction skills amplify development skills programs produced by developers with good abstraction skills should be of significantly better quality Robert B. France 16

17 INTRODUCTION TO THE UML Slightly modified versions of slides provided by Arlow and Neustadt Robert B. France 17

18 1.2 What is UML? Unified Modelling Language g (UML) is a general purpose, p mostly graphical, modelling language Can support all existing lifecycles Intended ddto be supported by tools Unifies past modelling techniques and experience Incorporates current best practice in software engineering UML is not a methodology! UML is a language Unified Process (UP) is a methodology Clear View Training 2010 v2.6 18

19 1.3 UML history Prehistory Schlaer/ Mellor Booch Fusion 1 st unification attempt OMT, Booch, CRC UML work begins Object Management Group RFP UML proposal accepted by OMG UML 1.x UML 2.0 Rumbaugh (OMT) Jacobson (Objectory) Coad/ Yourdon Booch & Rumbaugh (OMT) join Rational Jacobson (Objectory) joins Rational UML becomes an industry standard Ongoing UML development A major upgrade to UML at the end of 2003: Greater consistency More precisely defined semantics New diagram types Backwards compatible Clear View Training 2010 v2.6 19

20 1.4 UML and MDA Development of UML is linked to the OMG MDE initiative called Model Driven Architecture (MDA) MDA Platform Independent Model map Platform Specific Model generate Code deploy Clear View Training 2010 v2.6 20

21 1.6 Objects and the UML UML models systems as collections of objects that interact to deliver benefit to outside users Static structure What kinds of objects are important What are their hirelationships Dynamic behaviour Lifecycles of objects Object interactions to achieve goals Clear View Training 2010 v2.6 21

22 1.8 UML building blocks Things Modelling elements (e.g., class, state, activity) Relationships Tie things together (e.g., association, transition, control flow) Diagrams Views showing interesting collections of things Provide views of the modeled system Clear View Training 2010 v2.6 22

23 1.8.1 Things Structural things nouns of a UML model Class, interface, collaboration, use case, active class, component, node Behavioural things verbs of a UML model Interactions, state machine Grouping things Package Models, frameworks, subsystems Annotational things Notes Tagged values package Some Information about a thing Clear View Training 2010 v2.6 23

24 1.8.2 Relationships relationship UML syntax brief semantics dependency association The source element depends on the target element and may be affected by changes to it. The description of a set of links between objects. aggregation The target element is a part of the source element. composition A strong (more constrained) form of aggregation. containment generalization realization The source element contains the target element. The source element is a specialization of the more general target element and may be substituted for it. The source element guarantees to carry out the contract specified by the target element Clear View Training 2010 v2.6 24

25 1.8.3 italics indicates an abstract category of diagram types UML has 13 types of diagram normal font indicates an actual type of diagram that you can create Structure diagrams model the structure of the system (the static model) Behavior diagrams model the dynamic behavior of the system (the dynamic model) Each type of diagram gives a different type of view of the model Clear View Training 2010 v2.6 25

26 1.8.3 UML 2 diagram syntax heading frame contents area heading syntax: <kind> <name> <parameters> N.B. <kind> and <parameters> are optional The heading specifies the kind of diagram, it s name and any information (parameters) needed by elements in the diagram The frame may be implied by a diagram area in the UML tool implied frame Clear View Training 2010 v2.6 26

27 1.9 UML common mechanisms UML has four common mechanisms that apply consistently throughout the language: Specifications Adornments Common divisions Extensibility mechanisms Clear View Training 2010 v2.6 27

28 1.9.1 icon or modeling element BankAccount name accountnumber deposit() withdraw() calculateinterest() Specifications semantic backplane Class specification Deposit Use case specification Dependency specification Behind every UML modelling element is a specification which provides a textual statement ofthe syntax andsemantics ofthat element These specifications form the semantic backplane of the model Clear View Training 2010 v2.6 28

29 1.9.2 Adornments Every UML modelling element starts with a basic symbol to which can be added a number of adornments specific to that symbol We only show adornments to increase the clarity of the diagram or to highlight a specific feature of the model Window Window {author = Jim, status = tested} +size : Area=(100,100) #visibility : Boolean = false +defaultsize: Rectangle #maximumsize : Rectangle -xptr : XWindow* +create() +hide() +display( location : Point ) -attachxwindow( xwin : XWindow*) Clear View Training 2010 v2.6 29

30 1.9.3 Common divisions Classifier and instance A classifier is an abstraction, an instance is a concrete manifestation of that abstraction BankAccount balance The most common form is class/object eg e.g. a classifier getbalance() might be a BankAccount class, and an instance might be an object representing my bank account «instantiate» Generally instanceshavethesamenotationasclasses the same notation as classes, but the instance name is underlined myaccount:bankaccount balance = Interface and implementation An interface declares a contract and an implementation represents a concrete realization of that contract Borrowable LibraryItem Clear View Training 2010 v2.6 30

31 1.9.4 Extensibility mechanisms constraint note { each Ticket has a unique id } «entity» Ticket {version = 1.1} id stereotype tagged value Stereotypes A stereotype allows us to define a new UML modelling element based on an existing one We define the semantics of the stereotype ourselves Stereotypes add new elements to the UML metamodel Written as «stereotypename» Constraints Extends the semantics of an element by allowing us to add new rules about the element Written as { some constraint } Tagged values Allows us to add new, ad hoc information to an element s specification Written as { tag1 = value1, tag2 = value2 } are attached to a stereotype Clear View Training 2010 v2.6 31

32 Stereotype syntax options stereotype t name «entity» stereotype t in guillemets Ticket preferred stereotype t icon Ticket icon preferred stereotype t name and icon «entity» Ticket stereotyped relationship «control» JobManager «call» Scheduler A stereotype introduces a new modelling element and so we must always define semantics for our stereotypes Each model element can have many stereotypes Clear View Training 2010 v2.6 32

33 UML profiles A profile customizes UML for a specific purposes A UML profile is a collection of stereotypes, tagged values and constraints The tagged values and constraints are associated with stereotypes Stereotypes extend one of the UML meta model elements (e.g. Class, Association) Any element that gets the stereotype also gets the associated tagged values and constraints Clear View Training 2010 v2.6 33

34 1.10 Architecture "The organisational structure of a software system" UML specification & IEEE Std RUP has a 4+1 view of architecture vocabulary functionality behaviour Design view Process view Implementation view Use case view Deployment view system assembly configuration management The 4+1 View of Architecture, Philippe Kruchten, IEEE Software, 12(6) Nov. 1995, p performance scalability throughput system topology distribution ib i delivery installation Clear View Training 2010 v2.6 34

35 1.11 Summary The UML is composed of building blocks: Things Relationships Diagrams The UML has four common mechanisms: Specifications Adornments Common divisions Extensibility mechanisms The UML is based on a 4+1 view of system architecture Clear View Training 2010 v2.6 35