Software engineering and GUI design UML Behavioral diagrams

Software engineering and. GUI design UML Behavioral diagrams, Implementation diagrams Non-UML diagrams http: //users. nik. uni-obuda. hu/prog 4/ 1

UML • Predecessor : RUP (Rational Unified Process) 2

UML • Sources – Diagrams from Eszter Cseri for the „Car. Shop” demo project – University of Miskolc, Open Book (in Hungarian) https: //www. tankonyvtar. hu/hu/tartalom/tamop 425/0046_szoftverfejlesztes/index. html – https: //docs. microsoft. com/en-us/visualstudio/modeling/create-models-for-your-app – https: //sparxsystems. com. au/resources/tutorials/uml/part 1. html – https: //www. uml-diagrams. org/ • UML "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components. " 3

UML • UML basic principles – Establish a self-explaining visual modeling language – Possibility to extend the basic concept any time in the future – Should be independent from programming language and methodology – Should give a formal basis for understanding the modeling language – Should support the OO development – Should integrate the already existing best practices 4

UML alternatives • "UML is the worst possible notation. . . except for all the others" (Source: C 2 Wiki) • How about making your own? UML is strict (it should be…) – Discard of everything you don't need (make it agile) – Make it fit better to your own requirements – Raise the level of abstraction beyond coding concepts. – The tighter fit between modeling language and problem domain creates better possibilities for true code generation • Various other approaches https: //en. wikipedia. org/wiki/Modeling_language – Flowcharts (…) – Domain-Specific Modeling, Domain-Specific Languages – Jackson Structured Programming – Sys. ML 5

UML tool • Many different tools – Microsoft Visio – Visual Paradigm for UML (ask for access!) – Rational Rose • Enterprise Architect – Maybe the most widespread, but expensive (or: Trial version) – /technology/ has a version… ; ) • DIA (dia-installer. de ) – dia-setup-0. 97. 2 -2 -unsigned. exe /S – cd "c: Program Files (x 86)Diabin" – SET LANG=en – diaw --integrated • https: //en. wikipedia. org/wiki/List_of_Unified_Modeling_Language_tools 6

UML Diagram Types 7

Behavioral diagrams • Use case diagram • Activity diagram • (Finite) state machine diagram • Interaction diagrams: Sequence, Communication, Timing Non-UML diagram, but describes the look and the behavior of the final product : • Design (look) and layout planning (Wireframe) 8

Use case diagram • Actor, Use Case • Connections – Simple (between actor and use case) – Generalization/specification (Inherits) (Between two actors OR two use cases) – Numerical definition (between an actor and a use case) – Composition (Includes, only between use cases) – Extension (Extends, only between use cases) • With the exception of very complex systems, this diagram might be too complex (personal opinion : unnecessarily way too big ) – Many times it’s simpler to describe with a table – Supports hierarchic and role-based authorization, but both can be described with a table 9

Use case diagram 10

Activity diagram • Describes the internal processes of the individual use cases, or the processing order of the use cases after each other – Starting point: 1 use case = 1 activity diagram – In a given diagram, other use cases can appear as well • Elements – Processes (rounded rectangle) – Transitions (arrow) – Decision (rhomboid) – Starting state: this is the state of the system/module/use case when it’s created; there are no incoming transitions (filled circle) – Final state: this is the state of the system/module/use case when it’s completed; there are no outgoing transitions (dot in an empty circle) 11

Activity diagram 12

13

Activity diagram 14

State diagram • Description of state transitions – Can be used for system- and object-states as well • Elements – State (rounded rectangle, name is obligatory) – Starting state: this is the state of the system/object when it’s created; there are no incoming transitions (filled circle) – Final state: this is the state of the system/object at the end; there are no outgoing transitions (dot in an empty circle) • Not the only representations for „Finite state machine” – State transition table (first column: states; first row: events; cells: conditions + new state) – Petri nets (event-driven state transitions with conditions and numerical constraints) – SDL state machine, etc… 15

State diagram • With states, the “handle all possibilities” can be problematic (e. g. what to do with the ’=’ button in states different than operand 2? ) 16

Interaction diagrams • All interaction diagrams (sequence, communication, timing) can be used for the same purpose – Introduce the participants of a process (actors, modules, layers) – Describe the communication connections between the participants – Timing: also show timing information, restrictions and states – Sequence: also allow loops, conditions, and lifespan – Communication: only show connections & message order – All interaction diagrams can be converted to sequence diagram, but it is not true reversed (only for the most simple sequence diagrams) 17

Interaction diagrams • Communication diagram – Nodes (actors / layers / modules (actors or rectangles)) – Edges between nodes = communication – It is possible to mark an order of communication on the edges • Timing diagram – In the rows, we have the communicating entities (actors/modules/subsystems) – Every row is one timeline – We can signal the state changes and the sent messages • Sequence diagram – In the columns, we have the communicating entities – Every column signals the lifespan of the entity – Between the columns we have horizontal, directed arrows to signal the communication, from the top, moving downwards 18

Communication diagram 19

Timing diagram 20

Sequence diagram 21

Sequence diagram 22

Sequence diagram 23

Wireframe • When defining UML, they did not think that the look of an application can be part of the model – In practice, this is an unskippable step – This is the first prototype the user will see • Creation – With a concrete development tool, by assembling windows without any event handlers and functionalities – Dedicated wireframe tool (placeholders instead of controls) – Drawing program (Concept Art; the artist can „go wild”) • Must always predict processes – Determine the use case/activity user interface relations – Determine transition points between user interfaces (exactly which control should be used, otherwise the project can get confusing very easily) 24

Wireframe 25

UML Diagram Types 26

Structural UML diagrams • Deployment diagram • Component diagram • Package diagram • Composite structure diagram (only to review internal associations, rarely used ) • Class/object diagram • Non-UML, but important i mplementation diagrams: – Table structure diagram – Entity-relationship diagram – Development schedule (gantt diagram) 27

Deployment diagram • Diagram that displays the elements/environment of the system • Software elements – Program modules to be executed – Settings, configuration files – Data, database • Environmental elements – Computers – Network nodes / active components – Executing environments (virtual machine, app server, etc. ) • Can be the VERY FIRST diagram to be created – Can be useful even before the behavioral diagrams – It is good to see clearly at the beginning of the development process, to know the executing/usage environment 28

Deployment diagram 29

Internal structure • Component diagram vs Package diagram almost the same – „In UML, components are groups of classes that are deployed together and packages are a general grouping device for model elements. – Packages can group any model elements, even things like use cases, but in practice they usually group classes, so components and packages tend to be synonymous. ” (Michael Feathers; "Working Effectively with Legacy Code”) • One possible difference – Package: structure, composition, dependencies (Packageable elements: Type, Class, Use Case, Component, Package, Constraint, Dependency, Event) – Component: connections/interfaces (Subsystems, Service-Oriented-Architecture, SOA) (For the component diagram, the component can be either local or remote, it’s equal) 30

Package diagram 31

Component diagram 32

Component diagram 33

Class/Object diagram • About classes or specific instances – Class diagram: class members, methods – We don’t need an exact image now about the classes to be developed a lot later – For the earlier phases of development, the interfaces of the package diagram should be enough – During pregroom, the architect might be responsible for: dividing the tasks to modules/classes, so the other developers will have concrete classes to create • Object diagram – Relations of instances created during execution – UML 1. 4. 2. : „a class diagram with objects and no classes. ” – UML 2. 4 & 2. 5: Mentioned briefly, but „UML 2. 5 specification simply provides no definition of object diagram. ” 34

Inheritance / Specialization (recap) 35

OO relations • Dependency: Direct/Indirect reference to the type • Association: “Random”, completely separated objects • Aggregation : Whole-part , separated lifetimes • Composition : Whole-part , dependent lifetimes 36

Class diagram 37

38

Class diagram (Visual Studio) 39

Code map (VS) • Solution explorer / right click / Show on code map • Every node and edge is clickable, zoomable, extendable • We can locate the classes that violate layers • In this project : UI Data connection • Model connection : not ideal, but also in Prog 3, we allowed the usage of Data classes in upper layer (only the data entity classes !) 40

Spagetthi code • The model classes can be more-or-less clearly used, but there is also a reference for the Db. Context subclass • This is a huge problem, this means unlimited access to the DB from the GUI (the Logic can be bypassed) • To create the Logic, we need that instance Factory pattern 41

Table structure diagram • The next three are not UML diagrams • But they are used in almost every software development project 42

Entity-relationship diagram • This is usually created before the table structure diagram • The fields are usually not important • Relation + Entities • Attribute • Relation-attribute • Primary key 43

ER diagram 44

Gantt diagram 45

(One possible) process of software design 1. Deployment diagram – The system will be used in what environment 2. Behavioral diagrams – What operational tasks are needed to be performed – Use Case Activity Wireframes 3. Structural diagrams – This operation is doable using what modules/structure – Component Sequence (behavioral!) – Class diagram (this can also be postponed to the development) (List Relations Attributes, Methods Inheritance) 4. Implementation diagrams – How can we implement the system Gantt – Database: ER Table structure 5. Write code 46

Game Project Diagrams • Use Case Diagram (Who will access what functions ) • Activity diagram (Minimum one process from the user’s perspective) • Component diagram (What parts will the system have ) • Sequence diagram (Minimum one process from the code perspective) • Interfaces (IGame. Model, IGame. Logic, IStorage. Repository ) • Class Diagram (at the end, auto-generated + class relations) 47

Components of the game project • Components with separated responsibilities – Model: all data (meaning: property), that is required for one state of the game (NOT View. Model!!!) – Logic: it must modify the Model using methods (timed and user interaction-based modifications) – Renderer: it must display the Model (practices 6 -8) – Repository: it must handle the highscore table + save/load operations of the model (game state; into DB or XML) – Tests: AAA unit tests of the logic, with mocked dependencies • Separated development tasks – Master+Develop git branch; feature-branch suggested – A: interfaces (IModel, ILogic) + Logic + Tests – B: Model + Repository + Renderer – In case of a single-person project, no Tests+Repo needed 48

What’s next? ? ? • • Programming 1: C# syntax, Class basics , composition 2: Collections , Inheritance 3: GIT, LINQ, ORM, Layering 4: Class & architectural design patterns • https: //github. com/Moien. Tajik/Asp. Net. Core-Developer. Roadmap 49

50

Thank you for your attention UML Behavioral diagrams, Implementation diagrams Non-UML diagrams http: //users. nik. uni-obuda. hu/prog 4/ 51