Agile Modeling with Uml and Visual Studio 2010

1,862
-1

Published on

Presentation from a speech held on 20th May at Microsoft on UML modeling throughout Agile processes using Visual Studio 2010.

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,862
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Lightweight - Only measure of a result is working software.Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planDifferent implementations do not exists as attempts to promote different approach, but when talking about selecting development methodology - there is no silver bullet. It depends on project type, team members, environment.
  • Agile approach and modeling are two totally independent questions that do not exclude each other!RUP even proposes which documents should be created in which development phase (architectural model)
  • UML Profile is a collection of stereotypes that can be applied to individual model elements. Each stereotype defines a set of attributes that extend definition of the model element it is applied to At the end we still have to write code, since there aren’t any modeling languages capable of abstracting all details and related generators to generate efficient and correct code.
  • Visual Studio includes C# Profile that can be used to extend UML classes with attributes specific to C#.T4 - Text Template Transformation Toolkit
  • Agile Modeling with Uml and Visual Studio 2010

    1. 1. Agile Modeling with UML and Visual Studio 2010<br />Ogren Paunović<br />ogrenpaunovic[at]gmail.com<br />www.printecgroup.com<br />
    2. 2. Q: Why is writing correct software so difficult??<br />COMPLEXITY!<br />Modern software is reaching levels of complexity encountered in biological<br />systems; sometimes comprising systems of systems each of which may<br />include tens of millions of lines of code<br />…any one of which may bring down the entire system at great expense<br />
    3. 3. Complexity<br />Essential complexity<br />inherent to the problem<br />cannot be eliminated by technology or technique<br />e.g., solving the traveling salesman problem<br />Accidental complexity<br />due to technology or methods used to solve the problem<br />e.g., building a skyscraper using hand tools only<br />Modern software development suffers from an excess of accidental complexity<br />
    4. 4. A Bit of Modern Software…<br />SC_MODULE(producer)<br />{<br />sc_outmaster<int> out1;<br />sc_in<bool> start; // kick-start<br />void generate_data ()<br />{<br />for(int i =0; i <10; i++) {<br />out1 =i ; //to invoke slave;}<br />}<br />SC_CTOR(producer)<br />{<br />SC_METHOD(generate_data);<br />sensitive << start;}};<br />SC_MODULE(consumer)<br />{<br />sc_inslave<int> in1;<br />int sum; // state variable<br />void accumulate (){<br />sum += in1;<br />cout << “Sum = “ << sum << endl;}<br />SC_CTOR(consumer)<br />{<br />SC_SLAVE(accumulate, in1);<br />sum = 0; // initialize<br />};<br />SC_MODULE(top) // container<br />{<br />producer *A1;<br />consumer *B1;<br />sc_link_mp<int> link1;<br />SC_CTOR(top)<br />{<br />A1 = new producer(“A1”);<br />A1.out1(link1);<br />B1 = new consumer(“B1”);<br />B1.in1(link1);}};<br />Can you see the architecture?!<br />©BrankoSelić<br />
    5. 5. ...and its model<br />
    6. 6. Abstraction, tool for complexity<br />Abstraction is the process or result of generalization by reducing the information content of an observable phenomenon, typically to retain only information which is relevant for a particular purpose.<br />Every system can be described with more than one abstraction, depending on a purpose.<br />Progressive abstractions is way of building new abstractions on top of existing ones.<br />Represented through models<br />Usually, one model is not enough<br />Models can be expressed in different notations<br />
    7. 7. Unified Modeling Language<br />Standardized general-purpose modeling language in the field of software engineering.<br />~150 known notations before UML<br />Models structure and behavior<br />Vide exploitation range (construction, communication, documentation, implementation)<br />UML encapsulates almost all possible elements in software development<br />Why use UML among other notations? It’s the least bad<br />
    8. 8. Agile development<br />Iterative and incremental (evolutionary) development based on frequent inspection and adaption through self-organizing cross-functional teams.<br />Lightweight<br />Different implementations (RUP, Scrum, XP, Crystal…)<br />
    9. 9. Agile + UML?<br />“What UML has to do with Agile? Wasn’t the whole point to cut out the ballast?”<br />Modeling and UML are (funda)mental tools in overriding complexity! By just being agile, we are not overriding the complexity, we are ignoring it and suffering it.<br />Agile manifesto doesn’t specify how any of mentioned goals should be achieved and it certainly doesn’t specify to get rid of the models (even some documentation)<br />
    10. 10. Agile modeling (Scott Ambler)<br />
    11. 11. So, what’s the catch?<br />Having a model without automated relation to end result (functional software) has a cost and someone must explicitly choose to make that investment.<br />Executable models should be considered as standard part of development environment, for others, the benefit of having models (and documentation) must be greater than the cost of creating and maintaining it.<br />
    12. 12. Lifecycle of an agile model<br />Models become permanent when they are stable, clear and provide value (to audience or through code)<br />It is very useful to have modeling tools that support “offline” models that are not in direct relationship with the code all the time.<br />
    13. 13. Models vs. Languages<br />Level of abstraction<br />Human <br />understanding<br />Modeling languages<br />Programming languages<br />Implementation<br /> details<br />
    14. 14. Executable models<br /> Instead of abstract diagrams an executable model is a working prototype<br />It encourages focus on user needs, not technical design considerations<br />Transformation from platform independent to platform specific model<br />UML Profiles as extension mechanism for customizing models for particular domains and platforms<br />At the end we still have to write code<br />
    15. 15. Static models (documents)<br />The fundamental issue should be communication, not documentation<br />Write it only if that's the best way to achieve the relevant goals<br />Should be concise: overviews/roadmaps are generally preferred over details<br />Developers rarely trust static models<br />Create it only when you need it at the appropriate point in the lifecycle<br />Update only when it hurts.<br />
    16. 16. Visual Studio 2010 and UML<br />Microsoft has become OMG member<br />Focus on: Understanding the code, maintaining the control and understanding the domain<br />New project type – Modeling project (VS 2010 Ultimate + VS 2010 SDK + VS 2010 Visualization & Modeling SDK)<br />Model data are not related to diagrams anymore, but stored in model repository related to modeling project<br />Model explorer instead of files<br />Support for code generation through standard extensibility mechanism - UML profiles (T4 based generator)<br />Feature Pack<br />
    17. 17. Demo:<br />UML in Visual Studio 2010<br />
    18. 18. Q&A<br />
    19. 19. Useful links<br />http://www.agilemodeling.com/<br />http://blogs.msdn.com/camerons/<br />http://blogs.msdn.com/jennifer/default.aspx<br />http://www.olegsych.com/articles/<br />http://blogs.msdn.com/timfis/default.aspx<br />

    ×