Short Description Download Exam Preparation Software Engineering TFH Berlin…
Description
Exam preparation Software Engineering I @ TFH Berlin
Part 1 – Introduction to Software Engineering Definition: What is Software Engineering?? Software engineering (SE) is the systematic, disciplined, and estimable approach to developing, operating, and maintaining software (IEEE). One understands by it however also the goal-oriented supply and systematic use of principles, methods, concepts, notations and tools for the work-divided, engineer-like development and application of extensive software systems. (H. Balzert, Textbook of Software Engineering). Goal-oriented Æ Consideration of z.B. Cost, time, quality. In summary, SE – Allows the development of complex software – Means the use of tools and methods – Saves (can save) time and costs – Increases (can increase) quality and productivity Note: The definition of the IEEE is freely translated from English by me. There it reads, "The systematic, disciplined, quantifiable approach to the development, operation and maintenance of software.". I assume that one can understand this English sentence, but only with difficulty translate and advise to the use of the German-language definition. The devil's square according to Sneed The devil's square according to Sneed shows the four most important factors in the development of software projects. Here, the individual factors depend on each other, resulting in the two inner squares (actually, the red distorted square and the square in the middle are the same, just in different situations). In the example you can see that an increase in quality with a reduction in development time is inevitably accompanied by a reduction in quantity and an increase in development costs. The quadrilateral, which is formed from the four factors, shows the productivity, which can be reached with the given factors. The area of the square always remains the same. Shifts in one factor result in further shifts, so that shapes such as the square shown here in red are formed. Clearly, without direct connection to the devil's square: If one increases the requirements on a software (z.B. The quantity of the implemented functions), then either the quality must suffer from it, or however development duration and/or costs rise. Exactly this fact represents the devil's square. Note: In today's lecture (16.01.07) it was said that the perpendicular sides of the productivity quadrilateral must always be perpendicular…This would mean, however, that one can only endow a software project with higher quality if one reduces the development time – and that makes little sense in my eyes…
Knowledge areas of software engineering according to IEEE Software Requirements
Æ What should a software do?
Software Design Æ How the software is built (architecture)?
Software Construction
Æ realization of the software according to the design
Software Testing Æ Systematic error detection and correction
Software Maintenance
Æ Maintenance and further development after delivery
Software Configuration Management Æ Management of software versions and configurations
Software Engineering Management
Æ Project management of people, organizations, time, etc. Part 2 – Procedure models Procedure model in the software engineering are called also software life cycle. Provide different approaches to software development. They are subdivided into phases, which are delimited from each other either in terms of content or in terms of time. With the procedural models it is possible to control complex projects. For every project. Must be the right one or. The right model can be found, because there are different levels of detail. Process models can be very complex, but help to manage complex projects. Often they are internal to the company or specified by the respective client. The more experience a developer or a team of developers has with such a model, the more efficiently time and costs can be saved. The waterfall model This model originates from the year 1970. Is also known as phase model. It is divided into the following phases: – Requirements definition – System and software design – Implementation (programming) and module testing – Integration and system testing – Installation and maintenance These phases build on each other (with the exception of the top one, of course), as a cascade. You can go back from one stage to its predecessor, but you cannot skip a stage. It is important that each phase must be completely finished before the next phase can be started. Completed and approved documents.
Each phase provides one or more
Advantages – Documentation at the end of each phase – Compatible with other process models – Suitable for use in projects with clear requirements Disadvantages – Requirements are frozen early – Inflexible (subsequent changes are not planned for) – Cost and resource estimation is inaccurate
The spiral model (Boehm, 1988) With the spiral model after Boehm it concerns a combination of existing models under consideration of management aspects. It contains two axes: 1. The timeline 2. The cost axis In the windings you find the activities, in the angles the progress of the individual project cycles.
The individual turns are divided into four sectors: – Setting goals, assessing alternatives – Risk analysis – Planning the next cycle – Development and testing In the spiral model, the life cycle of a project starts at the center of the spiral and proceeds outward on it. Advantages – Early recognition of risks and errors – Alternative solutions – Prototype-based – Continuous maintenance and extension – Iterative and incremental Disadvantages – Not suitable for short-term, small projects
The V-model (1986) The V-model is an extension of the waterfall model, but without strict time sequences and without acceptance at the end of the individual phases. V-Modell XT is the development standard for IT systems of the Federal Government. It was released in February 2005 in version 1.2 presented. Activities and products of the development and planning process are defined. Quality assurance is integrated. This is how the individual phases are verified ("Is a correct product developed?") and validated ("Is the right product developed?").
Advantages – The V-model is standardized and yet flexible – Software quality is ensured – Costs are reduced – Communication between the individual employees/teams is increased – Client and contractor have a common language Disadvantages – Coordination processes are necessary in the beginning
Further procedure models (not in detail relevant for the exam) RUP
Rational Unified Process
RUP is a process model and product of IBM Rational. It offers static, dynamic and practical perspectives. XP
Extreme Programming
With XP the development takes place in small steps. Thus, communication. Tests especially important. MMD
Æ
Model Driven Development
Based on UML 2.0 a model is developed first, from which the code is generated later (many UML tools can do this automatically).
Part 2 – UML 2.1 – Phases of object-oriented development Object-oriented development is divided into three stages, respectively. Phases:
OOA, OOD and OOP.
At the beginning there is the OOA, the object-oriented analysis. Business requirements are recorded and described here. The second phase, the OOD, the object-oriented design, deals with the technical design and architecture of the project. At the end, OOP, object-oriented programming, is used to create the design in an object-oriented language (z.B. Java, C#, …) implemented. 2.1.1 – The phases of object-oriented analysis (OOA) The individual phases are realized with UML. 1. 2. 3. 4. 5.
Description of use cases with use case diagrams Modeling of processes with activity diagrams Representation of state changes with state diagrams Data modeling with object and class diagrams Textual description of requirements
As a result one receives a detailed requirement specification. 2.1.2 – Difference between requirements and specifications A requirement specification is defined as a customer's requirements, which should also include a rough description of the concept. A functional specification, on the other hand, is usually created by the contractor. It emerges from the specifications. Contains detailed requirements.
2.2 – What is UML? UML (Unified Modeling Language) is a modeling language that is published as a specification by OMG (Object Management Group), a consortium of the computer industry that develops integration standards for companies, and has been in use since 2004 in version 2 of the UML.0 located. UML is used as a visual resp. Graphical programming language is used and has like all other programming languages a fixed syntax resp. A uniform notation. By xUML is meant the executable variant of UML. This allows to execute a created analysis model as a prototype (then it is called executable specification).
2.3 – The different types of UML diagrams In UML 2.0 there are first of all two different types of diagrams: 1. 2.
Structure diagrams (static) Behavior diagrams (dynamic)
2.3.1 – Structural diagrams – – – – –
Class diagram Object diagram Package diagram Component diagram Composition structure diagram Deployment and distribution diagram (Deployment)
2.3.2 – Behavioral diagrams – – –
Use case diagram (Use Case) Activity diagram (Activity) State machines diagram (State Machines) Interaction diagram o Sequence diagram o Communication diagram o Interaction overview diagram o Timing diagram
2.4 – The Use Case Diagram In the use case diagram in UML, business processes are represented. Likewise, the behavior of the system is described from the user's point of view. 2.4.1 – The notation business processes are represented as an oval and contain a description of itself, which must always consist of a noun and verb.
Actors are represented as stick figures. They are a person or a subsystem that triggers a business process.
Associations Use case diagrams distinguish six types of associations that represent the relationships between business processes and actors among themselves. Simple association Æ both are involved, bidirectional information flow Directed association Æ source triggers target, information flow unidirectional Generalization Æ source is specialization of target Dependence Æ source is dependent on target, target is independent Include relationship Æ source contains functionality of target
Extend relationship Æ source extends the functionality of the target
Other associations can be labeled by labeling. Notes are also possible and can be linked to business processes and/or actors.
Example of a use case diagram
Explanations The imagined company has both private and business customers. These are grouped under the term "customer" but have different characteristics. The generalizations among the actors on the left side show this circumstance. The "customer" actor can trigger the "reserve car" business process, which also has an integrated email confirmation (include). Of course, both customer and employee are involved in the business process "Rent a car", which is extended in its functionality by the business process "Rent a car accessory". The motor vehicle employee is involved in the business process "reserve motor vehicle" (clear). Below right is an example of a note linked to the actor "motor vehicle employee". Signs about label were not made here. These appear as text at the associations. Finding the use cases To find the use cases, proceed as follows: Business processes are triggered by an event and end with a result. For example, in this case, a customer's request for a reservation would be the triggering event and the reservation would be the result. Both the trigger and the result must be clearly defined! Use cases are abstract. They are therefore independent of concrete possibilities and technical implementation. In the use cases, it doesn't matter if the customer wants to reserve a VW Golf or a space glider – these limitations are only considered later on.
Exam preparation Software Engineering I @ TFH Berlin
Stefan Matyba
Textual description A textual description in tabular form also belongs to a use case diagram. This supplements the diagram, provides a detailed description and offers additional options.